subversion: initial package

[hgy59]

Description

Synology does not support subversion on DSM 7, so there are some requests for an svn package.

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• New Package
• This change requires a documentation update (e.g. Wiki)

[cpm1]

Hey! Any progress on this? I'm waiting for it to finally be able to update my DSM :D

[hgy59]

This PR depends on #5649.

And I will add a dedicated web ui package (probably usvn)

[matt-hall-zory]

Any progress? I can see the PR you were depending on has been merged.

[hgy59]

Any progress? I can see the PR you were depending on has been merged.

I did some updates now, but see and issue on aarch64

svnadmin: E200029: Couldn't perform atomic initialization
svnadmin: E070023: Can't create fsync thread pool in FSX: This function has not been implemented on this platform

I have to validate other archs...

@matt-hall-zory If you don't mind, you could manually install the package built by github build action.

[hgy59]

Still no web ui added to the package
candidates are websvn and usvn
When possible, dedicated packages for those might be better.

[cpm1]

Almost one more year later without SVN on Diskstation :(

Can we please get this much needWanted package going? IMHO there is no need for a Web UI integrated in this package. I'd actually prefer dedicated server and web ui packages as they would be easier to maintain individually.

Pretty please? :)

[hgy59]

@cpm1 you are lucky, just started yesterday to move the unintended changes on mutt to a dedicated PR #6328.

and yes, subversion package is long overdue...

[hgy59]

@cpm1 do you have some time to test the package created by the github build action?

just navigate to the build action and under artifacts download the zip archive for your model (arch).
then extract the spk file from the zip archive and manually install it in dsm package center.

EDIT:
please regard that the svn server port of this package is 3691. This is to avoid conflicts with default port 3690 (synology svn package on DSM 6).

[cpm1]

@hgy59 Great! I'll install it, give it a spin and report back in one or two days.

Edit: sorry, I'm too dumb. All I can find as artifacts are zip files with the content of the spk's, but no ready to install spk. Where did I turn the wrong way?

[mreid-tt]

Edit: sorry, I'm too dumb. All I can find as artifacts are zip files with the content of the spk's, but no ready to install spk. Where did I turn the wrong way?

If you expand the zip file and don't get an SPK it's because your decompression software is also decompressing the SPK file. You can check your settings or use another decompression software that won't try to also decompress the SPK file.

[cpm1]

If you expand the zip file and don't get an SPK it's because your decompression software is also decompressing the SPK file.

Oops! Of course, you are right as am I with being dumb xD Extracted properly now, installed and first simple tests were successfull. Thank you very much!

Just the custom port is a bit irritating. It really should stay the default port at least on DSM7+. Or even better, allow the port to be specified at install time and/or changed via settings later.

[mreid-tt]

Just the custom port is a bit irritating. It really should stay the default port at least on DSM7+. Or even better, allow the port to be specified at install time and/or changed via settings later.

Synology packages typically do not support dynamic port allocation, as the port needs to be explicitly defined during the build process:

spksrc/spk/subversion/Makefile

Line 17 in 8db6b95

SERVICE_PORT = 3691

For Subversion, we could use the default port (3690). If the port is already in use on DSM, the system will detect the conflict and block the installation. To address this, we could adopt an approach where DSM 6 uses a custom port while DSM 7 retains the default port, reducing the likelihood of conflicts.

@hgy59, what are your thoughts on sticking with the default port? Since SVN is a third-party package, using the same port would align with our approach for Jellyfin, which shares a port with the third-party app Emby. Alternatively, we could implement a version-dependent port allocation, similar to the strategy used for MariaDB.