Den ons 25 mars 2026 kl 11:52 skrev Bo Berglund <[email protected]>:
> Background: > ----------- > We have a VisualSVN server running on an oldish Windows 2016 server. > This is structured into a number of main repositories for various > departments/purposes. > Inside each such repository are what we call projects each with a trunk > and tags > dir. > > This has worked very well since we moved over from CVS almost a decade ago. > I have set up a backup system where I run a Linux Ubuntu server off site > and > this server has a subversion system accessible via the Internet. > > On that I have created a mirror of the main repository by using the sync > function and in that way the main server is replicated. > > Each night there is a scheduled task on the main Windows2016 server to do > an svn > sync on all repositories to keep the two servers alike. > > This has worked fine for many years and was used 2 years ago to restore > our data > when we had a ransomware attack in the office network. > > Problem > ------- > A couple of days ago I received an alarm email from the nightly sync > process > where it was unable to sync one of the repositories. > At first I thought it was a nightly glitch, but it repeated the next sync > attempt when I got a new alarm email the next day... > > So now there are 3 commits on one repository project which can not be > backed up > using our sync system. And it probably blocks other projects on the same > repository from sync as well. > What are the exact error messages you get? > > When I look at the commit itself that started this I see that one > developer has > seemingly "saved" a github project into svn **without** excluding the .git > dir > inside that project. And the .git dir contains tons of admin files which > somehow > screws up the sync ability for the repository. > I doubt that a commit with the ".git" folder would create any problem with svnsync. Of course, the .git folder contains the whole repository (ie, all version data) so it could possibly be large but Subversion is quite good at handling large files/commits. > > What can I do in order to fix this? > > Ideally I would like to totally purge the commit done previously but given > that > this is a versioning system I think that it would not be possible. > Is there some way to completely remove the bogus project or the .git dir > inside > it so the sync can proceed? > Simple answer is no. Slightly more detailed answer is, yes, but you will break things for everyone else. One way is to restore a backup of the repository. But of course you will loose any newer revisions. Another way is to export the repository and use svndumpfilter to filter out the specific revision and then import everything into a brand new repository. (I've heard good things about reposurgeon[2] by Eric S. Raymond but I have not used it). Both options will break existing working copies for your users since those expect HEAD of the repository to look in a certain way at a certain revision and suddenly things look different. They can solve this by deleting .svn and checking out a new working copy (possibly in the same folder!) but it will require some work. > > I don't really know why the sync does not work since the commit was > accepted, > but I suspect that it is because of the .git subdir inside the new project > he > added. > As I wrote above, we can probably work this out based on the error messages from svnsync. > > Any suggestions are really welcome! > > > -- > Bo Berglund > Developer in Sweden > > Kind regards, Daniel [1] https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.tk.svndumpfilter [2] https://gitlab.com/esr/reposurgeon
