You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Josef Wolf <jw...@raven.inka.de> on 2019/12/05 09:56:58 UTC

Remove revision range from repository

Hello,

I need to permanently remove a range of revisions from a repository, which are
not the latest.

None of the working copies have such a revision checked out (I guess, that
might be a show-stopper).


I know, I can do:

# svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
# svnadmin dump /original/repo -r2345:HEAD --incremental > /path/to/dumpfile_2.dmp
# svnadmin create /new/repo
# svnadmin load /new/repo <  /path/to/dumpfile_1.dmp 
# svnadmin load /new/repo <  /path/to/dumpfile_2.dmp

But that would renumber the revisions of the second load command.

Is there any way to insert empty revisions, so that the revision numbers would
be stable?

BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
     don'w want existing working copies to get into trouble?

-- 
Josef Wolf
jw@raven.inka.de

Re: Remove revision range from repository

Posted by Branko Čibej <br...@apache.org>.
On 05.12.2019 13:01, Josef Wolf wrote:
> Thanks for your answer, Branko!
>
> On Thu, Dec 05, 2019 at 12:11:38PM +0100, Branko Čibej wrote:
>> On 05.12.2019 10:56, Josef Wolf wrote:
>>> I need to permanently remove a range of revisions from a repository, which are
>>> not the latest.
>> Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
>> in the output.
> Unfortunately, svndumpfilter can do only path based filtering. Thus, I'd need
> another way to "inject" such empty revisions.

Yes, indeed, you have to do multiple dumps the way you've already
suggested, and for one range of revisions you'd just tell svndumpfilter
to filter all paths. It's not really elegant, but should work.

-- Brane


Re: Remove revision range from repository

Posted by Josef Wolf <jw...@raven.inka.de>.
Thanks for your answer, Branko!

On Thu, Dec 05, 2019 at 12:11:38PM +0100, Branko Čibej wrote:
> On 05.12.2019 10:56, Josef Wolf wrote:

> > I need to permanently remove a range of revisions from a repository, which are
> > not the latest.
> Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
> in the output.

Unfortunately, svndumpfilter can do only path based filtering. Thus, I'd need
another way to "inject" such empty revisions.

> > BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
> >      don'w want existing working copies to get into trouble?
> 
> Any existing working copies may be in trouble in any case. A working
> copy that contains an item from a revision that you'll exclude from the
> repository will no longer be able to commit or update.

I can make sure that no WC has such revisions.

> Other working copies will be fine (if you update the UUID).

OK. Sounds good.

-- 
Josef Wolf
jw@raven.inka.de

Re: Remove revision range from repository

Posted by Branko Čibej <br...@apache.org>.
On 05.12.2019 10:56, Josef Wolf wrote:
> Hello,
>
> I need to permanently remove a range of revisions from a repository, which are
> not the latest.
>
> None of the working copies have such a revision checked out (I guess, that
> might be a show-stopper).
>
>
> I know, I can do:
>
> # svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
> # svnadmin dump /original/repo -r2345:HEAD --incremental > /path/to/dumpfile_2.dmp
> # svnadmin create /new/repo
> # svnadmin load /new/repo <  /path/to/dumpfile_1.dmp 
> # svnadmin load /new/repo <  /path/to/dumpfile_2.dmp
>
> But that would renumber the revisions of the second load command.
>
> Is there any way to insert empty revisions, so that the revision numbers would
> be stable?


Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
in the output.


> BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
>      don'w want existing working copies to get into trouble?

Any existing working copies may be in trouble in any case. A working
copy that contains an item from a revision that you'll exclude from the
repository will no longer be able to commit or update. Other working
copies will be fine (if you update the UUID).

-- Brane

Re: Remove revision range from repository

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Dec 5, 2019 at 5:00 AM Josef Wolf <jw...@raven.inka.de> wrote:
>
> Hello,
>
> I need to permanently remove a range of revisions from a repository, which are
> not the latest.
>
> None of the working copies have such a revision checked out (I guess, that
> might be a show-stopper).

I'd urge you to to lock the old repository, build a new subversion
repository using "svnadmin dump", "svndumpfilter", and "svnadmin
load". Then switch your users to the new repository. Thatwill make
clear to your clients that are, in fact, using a different repository
with a different history and avoid confusion. Subversion is *very
picky* about deleting history, and there are philosophical and
security reasons to hinder the alteration of history as you are
looking for.

It sounds like you really want the "obliterate" feature to delete
accidentally committed sensitive files, which has never been
successfully done.

> I know, I can do:
>
> # svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
> # svnadmin dump /original/repo -r2345:HEAD --incremental > /path/to/dumpfile_2.dmp
> # svnadmin create /new/repo
> # svnadmin load /new/repo <  /path/to/dumpfile_1.dmp
> # svnadmin load /new/repo <  /path/to/dumpfile_2.dmp
>
> But that would renumber the revisions of the second load command.

Why are you using "--incremental" ?

> Is there any way to insert empty revisions, so that the revision numbers would
> be stable?
>
> BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
>      don'w want existing working copies to get into trouble?

The way you fix this is to *not use any* existing working copies. Make
people check out a new copy with the new uuid. You have zero control
over whether a working copy has those deleted revisisions.

I went through this with a bad commit in a source tree for a stock
exchange, and the cleanup when I failed to switch repos wasn't pretty.