Re: How to remove bogus commit from server?

--0000000000000a5fa2064dd7334d
Content-Type: text/plain; charset="UTF-8"

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

--0000000000000a5fa2064dd7334d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Den ons 25 mars 2026 kl 11:52 skrev Bo Be=
rglund &lt;<a href=3D"mailto:[email protected]">[email protected]</=
a>&gt;:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Background:<br>
-----------<br>
We have a VisualSVN server running on an oldish Windows 2016 server.<br>
This is structured into a number of main repositories for various<br>
departments/purposes.<br>
Inside each such repository are what we call projects each with a trunk and=
 tags<br>
dir.<br>
<br>
This has worked very well since we moved over from CVS almost a decade ago.=
<br>
I have set up a backup system where I run a Linux Ubuntu server off site an=
d<br>
this server has a subversion system accessible via the Internet.<br>
<br>
On that I have created a mirror of the main repository by using the sync<br=
>
function and in that way the main server is replicated.<br>
<br>
Each night there is a scheduled task on the main Windows2016 server to do a=
n svn<br>
sync on all repositories to keep the two servers alike.<br>
<br>
This has worked fine for many years and was used 2 years ago to restore our=
 data<br>
when we had a ransomware attack in the office network.<br>
<br>
Problem<br>
-------<br>
A couple of days ago I received an alarm email from the nightly sync proces=
s<br>
where it was unable to sync one of the repositories.<br>
At first I thought it was a nightly glitch, but it repeated the next sync<b=
r>
attempt when I got a new alarm email the next day...<br>
<br>
So now there are 3 commits on one repository project which can not be backe=
d up<br>
using our sync system. And it probably blocks other projects on the same<br=
>
repository from sync as well.<br></blockquote><div><br></div><div>What are =
the exact error messages you get?</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
When I look at the commit itself that started this I see that one developer=
 has<br>
seemingly &quot;saved&quot; a github project into svn **without** excluding=
 the .git dir<br>
inside that project. And the .git dir contains tons of admin files which so=
mehow<br>
screws up the sync ability for the repository.<br></blockquote><div><br></d=
iv><div>I doubt that a commit with the &quot;.git&quot; folder would create=
 any problem with svnsync. Of course, the .git folder contains the whole re=
pository (ie, all version data) so it could possibly be large but Subversio=
n is quite good at handling large files/commits.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What can I do in order to fix this?<br>
<br>
Ideally I would like to totally purge the commit done previously but given =
that<br>
this is a versioning system I think that it would not be possible.<br>
Is there some way to completely remove the bogus project or the .git dir in=
side<br>
it so the sync can proceed?<br></blockquote><div><br></div><div>Simple answ=
er is no.</div><div>Slightly more detailed answer is, yes, but you will bre=
ak things for everyone else.</div><div><br></div><div>One way is to restore=
 a backup of the repository. But of course you will loose any newer revisio=
ns.</div><div>Another way is to export the repository and use svndumpfilter=
 to filter out the specific revision and then import everything into a bran=
d new repository. (I&#39;ve heard good things about reposurgeon[2] by Eric =
S. Raymond but I have not used it).</div><div><br></div><div>Both options w=
ill 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 o=
ut a new working copy (possibly in the same folder!) but it will require so=
me work.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
<br>
I don&#39;t really know why the sync does not work since the commit was acc=
epted,<br>
but I suspect that it is because of the .git subdir inside the new project =
he<br>
added.<br></blockquote><div><br></div><div>As I wrote above, we can probabl=
y work this out based on the error messages from svnsync.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Any suggestions are really welcome!<br>
<br>
<br>
-- <br>
Bo Berglund<br>
Developer in Sweden<br>
<br></blockquote><div><br></div><div>Kind regards,</div><div>Daniel</div><d=
iv><br></div><div>[1]=C2=A0<a href=3D"https://svnbook.red-bean.com/en/1.7/s=
vn-book.html#svn.reposadmin.maint.tk.svndumpfilter">https://svnbook.red-bea=
n.com/en/1.7/svn-book.html#svn.reposadmin.maint.tk.svndumpfilter</a></div><=
div>[2]=C2=A0<a href=3D"https://gitlab.com/esr/reposurgeon">https://gitlab.=
com/esr/reposurgeon</a></div><div>=C2=A0</div></div></div>

--0000000000000a5fa2064dd7334d--