You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bo Berglund <bo...@gmail.com> on 2026/03/25 10:51:33 UTC

How to remove bogus commit from server?

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


Re: How to remove bogus commit from server?

Posted by Bo Berglund <bo...@gmail.com>.
On Thu, 26 Mar 2026 08:03:46 +0100, Bo Berglund <bo...@gmail.com> wrote:

>Do I have to dump the entire repo and load it on the mirror server in a
>different dir (rename the old repo, create a new by the same name and then load
>the full dump)?

No that was not needed!

It turned out that ChatGPT managed to steer me in the right direction and
discover a lingering property in the mirror server.

svn propget svn:sync-currently-copying --revprop -r 0 https://<myrepoaddress>
3536

So there was this blocking other actions. Had to be deleted:

svn propdel svn:sync-currently-copying --revprop -r 0 https://<myrepoaddress>
property 'svn:sync-currently-copying' deleted from repository revision 0

svn propget svn:sync-last-merged-rev --revprop -r 0 <myrepoaddress>
3538

After this action it was possible to return to normal operations.

Case resolved.


-- 
Bo Berglund
Developer in Sweden


Re: How to remove bogus commit from server?

Posted by Bo Berglund <bo...@gmail.com>.
On Wed, 25 Mar 2026 13:22:49 +0100, Daniel Sahlberg
<da...@gmail.com> wrote:

>I suppose you could just `svnadmin dump` the failing revision and then
>`svnadmin load` it to the target repository and carefully `svn propset`
>svn:sync-last-merged-rev to an appropriate value. Make sure you read
>through and understand everything in the SVN book related to svnsync before
>attempting this, test it on a testrepository and make a proper backup
>before you try it for real.
>
>Hope it works out for you!

Yes, it was a sync timeout when trying to synchronize across the Internet when
there was this massive commit. I managed to create the dump file for the commit
and move it to the mirror server and load it there.
So the mirror now also contains the commit of that revision.

But before I had finished the load into the mirror the developer actually
removed the bad project so increasing the revision number again but this time
without any associated committed files! The previously committed project is now
invisible.

I tried to sync again after I saw this and this time the sync process succeeds
in the normal time but the revision on the mirror does not include the removal
revision so it sits at an earlier rev still now.

Do I have to dump the entire repo and load it on the mirror server in a
different dir (rename the old repo, create a new by the same name and then load
the full dump)?

The end result should be that the mirror is exactly the same as the main
repository. It is a backup and is never used actively itself with the exception
of the nightly syncs.


-- 
Bo Berglund
Developer in Sweden


Re: How to remove bogus commit from server?

Posted by Daniel Sahlberg <da...@gmail.com>.
Den ons 25 mars 2026 kl 13:03 skrev Bo Berglund <bo...@gmail.com>:

> On Wed, 25 Mar 2026 12:01:57 +0100, Daniel Sahlberg
> <da...@gmail.com> wrote:
>
> >What are the exact error messages you get?
>
> So I connected to the Windows server via VPN and RDP and in a cmd window I
> started the syncing bat file which showed that all of the other
> repositories (11
> of them) completed within seconds except for this problem one.
>
> The log file for that repo contains a few lines concerning the failed sync:
>
> [2026-03-25_06:36:48] Starting sync for hw
> svnsync sync --sync-username syncuser https://svn.xxxxxxxxxx.com/svn/hw
> https://yyyyyyyyy/svn/hw
> Transmitting file data .. (long time to print 585 dots) ..svnsync: E120106:
> ra_serf: The server sent a truncated HTTP response body.
> [2026-03-25_06:40:15] Sync completed for hw
>
> So there seems to maybe be a timeout and the server side cannot receive
> the data
> completely?
>

Looks like a timeout, yes. It is probably not because of the .git folder
itself but rather because of the size of the revision.


>
> Is it possible to create a "dump" file on the server containing the data
> for the
> last missing revisions and which I can transfer to the Ubuntu sync server
> and
> import there without the overhead of the Internet connection?
> It looks like a timeout to me.
>

If I remember correctly the last merged revision is stored in a revision
property on r0 in the target repository. I keep a local mirror of the SVN
Book on my own server and there seems to be a few revprops here:

[[[
daniel@srv:/data/svn/svnbook$ svn proplist file:///data/svn/svnbook -v
--revprop -r0
Unversioned properties on revision 0:
  svn:date
    2002-07-07T05:08:15.628904Z
  svn:log
    I'll bet I can enter a log message for revision 0, using tweak-log.cgi.

  svn:sync-from-url
    https://svn.code.sf.net/p/svnbook/source/trunk
  svn:sync-from-uuid
    b70f5e92-ccc6-4167-9ab2-d027528d294b
  svn:sync-last-merged-rev
    6069
daniel@srv:/data/svn/svnbook$
]]]

I suppose you could just `svnadmin dump` the failing revision and then
`svnadmin load` it to the target repository and carefully `svn propset`
svn:sync-last-merged-rev to an appropriate value. Make sure you read
through and understand everything in the SVN book related to svnsync before
attempting this, test it on a testrepository and make a proper backup
before you try it for real.

Hope it works out for you!

/Daniel

[3]
https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.replication



>
>
> --
> Bo Berglund
> Developer in Sweden
>
>
Of

Re: How to remove bogus commit from server?

Posted by Bo Berglund <bo...@gmail.com>.
On Wed, 25 Mar 2026 12:01:57 +0100, Daniel Sahlberg
<da...@gmail.com> wrote:

>What are the exact error messages you get?

So I connected to the Windows server via VPN and RDP and in a cmd window I
started the syncing bat file which showed that all of the other repositories (11
of them) completed within seconds except for this problem one.

The log file for that repo contains a few lines concerning the failed sync:

[2026-03-25_06:36:48] Starting sync for hw 
svnsync sync --sync-username syncuser https://svn.xxxxxxxxxx.com/svn/hw
https://yyyyyyyyy/svn/hw
Transmitting file data .. (long time to print 585 dots) ..svnsync: E120106:
ra_serf: The server sent a truncated HTTP response body.
[2026-03-25_06:40:15] Sync completed for hw

So there seems to maybe be a timeout and the server side cannot receive the data
completely?

Is it possible to create a "dump" file on the server containing the data for the
last missing revisions and which I can transfer to the Ubuntu sync server and
import there without the overhead of the Internet connection?
It looks like a timeout to me.


-- 
Bo Berglund
Developer in Sweden


Re: How to remove bogus commit from server?

Posted by Daniel Sahlberg <da...@gmail.com>.
Den ons 25 mars 2026 kl 11:52 skrev Bo Berglund <bo...@gmail.com>:

> 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