FSFS Logical Addressing: no

Question

I am trying to upgrade subversion server from 1.6 to 1.9, i have installed mod_dav modules and svn binaries.The big feature with svn 1.9 is FSFS filesystem format 7 which has got good amount of features, to enable all these features i am just running the command svnadmin upgrade , which gives me the below output

Path: repo1<br>
UUID: c67fd7ed-3808-3f41-9d25-6d8197ee6fd9<br>
Repository Format: 5<br>
Compatible With Version: 1.9.0<br>
Repository Capability: mergeinfo<br>
Filesystem Type: fsfs<br>
Filesystem Format: 7<br>
FSFS Sharded: yes<br>
FSFS Shard Size: 1000<br>
FSFS Shards Packed: 0/320<br>
FSFS Logical Addressing: no<br>
Configuration File: repo1/db/fsfs.conf<br>

Here as per the release notes, to enable all format 7 feature, FSFS Logical Addressing:Yes (previously it was no), so my question is how to set the above property to Yes

Answer 1

You can change content addressing type in repo1/db/fsfs.conf file. But do you really need to? Most likely, you do not. :)

There are two types of revision content addressing in Subversion repositories: physical addressing and logical addressing.

• Physical addressing is the most robust and reliable approach to address the revision content in Subversion repositories.

• Logical addressing is an optional approach to address the revision content in repositories. Logical addressing was introduced in FSFS format version 7 (new in Subversion 1.9). Logical addressing adds an extra translation layer for features to be implemented in future Subversion versions.

You can find more information about Subversion repo's properties and options in the article KB135: Understanding the Subversion repository types and formats.

Answer 2

you can do it silently, but I hope you have enough disk space for converting. simply, you can create new repository, then you apply new configuration. this can be stored next to original repository. then you configure mirroring from original to new repository, then call svnmirror binary. it is recommended making compression. it can slow down operation, but in my practice it is invisible by users. then you can compact repository, then backup will be much easier, by svnadmin pack . After that you can detaily test new repository, and ...... for very short time switch down repo, swap with new one and switch up. Remember, with switching process, you should copy repo UID from old to new. do it together with copying hooks. If all is ok, you can move old repo elsewhere, and finally destroy. You can do it with all repositories step by step, with very short unavailability.

some thing about logical addressing. I think the same as bahrep, logical addressing is very fresh. It will be better, it will be tested by someone else, not by us :)

I defined some options with my repos in fsfs, like repo sharing as true (reduce duplicates), directory deltification (the same) together with props, and compression. I tested commiting, checkouting, updateing and merging, and time overhead is invisible for me. fortunately I saved a lot of disk space.