[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Is there any way to truncate a subversion repository other than dump/load?

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Tue, 28 Jul 2009 13:24:47 +0100

No, you don't delete the folders, just the last few revision files.
Delete # 72344+, edit the revprop 0 to say last-synced revision is 72344
and off you go.

 

Take a copy of revprop 0 first, you're not going to do any more damage
to the repo by manually deleting files as your mirror is already
screwed. Try to repair it as above, or delete the whole thing and sync
from scratch.

 

Andy

 

 

 

From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Tuesday, July 28, 2009 1:08 PM
To: Bolstridge, Andrew
Subject: Re: Is there any way to truncate a subversion repository other
than dump/load?

 

 

2009/7/28 Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>

I would just delete it and let your svnsync process re-create it from
scratch overnight, just to be sure.

 

You can edit revprop 0 to reflect the last file to be transferred (look
in the revprop file - db\revprops\0 - it's pretty obvious which property
to edit - svn:sync-last-merged-rev), and delete the relevant revision
files from the repo. Svnsync will pick up from that point when you next
run it.

 

I'm not sure you can edit the revprop from svn itself as its rev 0, but
a text editor works ok. Remember to update the V entry if you change the
length of the property value (it's the number of characters of the
value)

 

You'll want to change the revprop on the mirror, not the master.

 

 

 

From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Tuesday, July 28, 2009 10:55 AM
To: users_at_subversion.tigris.org
Subject: Is there any way to truncate a subversion repository other than
dump/load?

 

Hi,

We have a repo with 70+k transactions.

We have a mirror on the other side of the atlantic.

Something went wrong with our svnsync process, and somebody "forced"
things and the nett result is that revision 72345 has been committed
twice, once as 72345 and the second time as 72346. Short of doing a
dump/load, is there any way I can truncate the repo back to 72344 and
then run svnsync from there again? (the reason being that the mirror has
not got enough disk space to hold the dump and the repo at the same
time, and the mirror is 3000 miles away from me, and the WAN link will
be saturated if I try to pull the whole mirror over again)

I was hoping for something like "svnadmin trunc -r 72344
path/to/my/repo"

Thanks in advance,

Oh, Subversion 1.5.5, Apache 2.2.3 on RHEL4

-Stephen

The problem is that svnsync will assume you are no farther than it has
progressed.... and the mirror repo has progressed passed the point
svnsync thinks it has

primary is at r72601
mirror is at r72345, rev prop 0 says it has mirrored transaction
r72344... but this should only be the case if mirror is at r72344... so
svnsync helpfully bales.

If I look at the log, it shows that r72344 from the primary has been
committed twice, first time as r72344 and second time as r72345... so
the mirror is borked... I need to truncate the mirror back to r72343,
set the svnsync properties so that it looks to be in sync upto r72343
and then run svnsync... but there is no svn command to roll a repo back
to a specific transaction.... it would seem to me that this should be
possible, given the on-disk storage... deleting the folders by hand is
most likely to screw up the repo... dump load is noramlly the only
answer, e.g.

svnadmin dump -r 0:72343 repo | svnadmin load new-repo

But I am short on disk space

-Stephen

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2376270

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-28 14:25:59 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.