Den tors 16 apr. 2026 kl 09:23 skrev Matthew Turner <[email protected]>:
> Hello: > > I recently came across https://issues.apache.org/jira/browse/SVN-516 and > am wondering if there is still interest in this due to the last commit > being in 2016. > > My interest in this stems from wanting to *archive* older commits that > are unlikely to be accessed to an external disk or other medium, and then > free up the space on the server. That way it still adheres to the principle > of an unmodified history, just with less immediate accessibility. Note that > I want to preserve the UUID and revision numbers so a dump/load cycle is > not as favourable as this feature would be. > > I have an rough idea of how this may be done but I have never touched SVN > source before and struggle to figure out what APIs would be relevant to the > FSFS structure I found ( > https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure) > and am not sure I have room in my life to implement it at this time. My > idea is, when packing a shard to also squash (similar to GIT squash > https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---squash) > the commits together for a smaller delta. Remember that while this history > is "lost" in the squash, it is supposed to have been archived elsewhere > that enables it to be restored. The ability for shards to live on a > different mount and soft-linked seems like a nice workaround for disk > space, but that requires that everything is always mounted. > > Is there still interest? Is my implementation idea worth effort (in the > future)? > > ~Matthew J.Turner > >From my point of view, this is a very desirable feature that has stalled not because of non-interest but because of a lack of developer time. If you are able to help out - I think that would be great! That said, there are some issues to consider as you can see in the Jira issue. Most important it would probably invalidate any existing WCs. You say that you want to keep existing revision numbers and thus a dump/load cycle doesn't help. I just tried the following which seemed to work for me, except that it broke my WC so I had to check out a new one: C:\temp>svnadmin create repo2 .. Create a new repo. My existing one is repo1 C:\temp>svnadmin dump --include NonExistingPath --revision 1:3 repo1 | svnadmin load repo2 ... Dump the existing repo of the revisions I want to exclude, filtering out everything so I basically get three empty revisions. Load them to the new repo C:\temp>svnadmin dump --revision 4:HEAD repo | svnadmin load repo2 ... Load the rest of the revisions. I end up with a repo with the same revision numbers as in the original one, but with everything looking as if it was created in revision 4. I don't really see a big win doing the above. Possibly if I had a repository with a lot of binary files in revisions 1:3, then repo2 would be a lot smaller only storing the state of the repository as in revision 4, however I assume you would still keep repo1 around negating any storage savings. One of Subversion's strong points, in comparison to Git, is that we don't even have to care about these old revisions client-side. If I checkout the project @ revision 4, my WC will only get the files as they were at that revision. Kind regards, Daniel
