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.

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.

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?

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.

Any suggestions are really welcome!


-- 
Bo Berglund
Developer in Sweden

Reply via email to