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

dump | dumpfilter | load -- always renumbers?

From: Vineet Kumar <vineet_at_doorstop.net>
Date: 2006-05-31 19:42:42 CEST


I'm moving some projects around from one big massive repository into
multiple smaller repositories, but I want users with checkouts from the
original repository to not have to do fresh checkouts, and I don't want
to break existing revision numbers (as referenced in bug reports, etc.)

I do want to prune out the projects I'm moving from the original
repository, along with taking the opportunity to prune out some botched
cvs2svn imports that some users did at the wrong paths in the

I tried to use these commands:

svnadmin create new
svnadmin dump old | svndumpfilter --drop-empty-revs exclude /trunk
/branches /tags /integration /: /svn | svnadmin load new

I avoided the --renumber-revs option, and based on the output I saw on
the terminal, it looked like svndumpfilter wasn't renumbering the
revisions, but that svnadmin load was renumbering them on the way in.
Here's some excerpted output:

* Dumped revision 541.
Revision 541 committed as 541.
* Dumped revision 542.
Revision 542 skipped.
* Dumped revision 543.
Revision 543 skipped.
* Dumped revision 544.
Revision 544 skipped.
* Dumped revision 545.
Revision 545 skipped.
* Dumped revision 546.
Revision 546 skipped.
* Dumped revision 547.
Revision 547 skipped.
* Dumped revision 548.
Revision 548 skipped.

------- Committed new rev 1 (loaded from original rev 23) >>>

<<< Started new transaction, based on original revision 541
Revision 2383 skipped.
* Dumped revision 2384.
Revision 2384 committed as 2384.
* Dumped revision 2385.
Revision 2385 skipped.
* Dumped revision 2386.
Revision 2386 skipped.
* Dumped revision 2387.
Revision 2387 skipped.
* Dumped revision 2388.
Revision 2388 skipped.
* Dumped revision 2389.
Revision 2389 skipped.

------- Committed new rev 2 (loaded from original rev 541) >>>

<<< Started new transaction, based on original revision 2384
* Dumped revision 2390.
Revision 2390 skipped.
* Dumped revision 2391.

My interpretation is that the "* Dumped" lines are svnadmin dump's
stderr, the "Revision n skipped" lines are dumpfilter's filtering, and
that the "<<<" and "----...>>>" lines are from svnadmin load. So it
appears to me that the dump and dumpfilter are doing the right thing,
but that the revisions are being renumbered when loaded.

I wanted to sanity check with the mailing list whether my process looked
good and whether this is a known issue with a known workaround, or if
I'm just doing something wrong. Should I not be using
--drop-empty-revs? That's what it sounds like based on reading some
entries from the mailing list archives.

In that case, a follow-up question: how is --drop-empty-revs to be used
without --renumber-revs, and what's the difference from with
--renumber-revs? Maybe --renumber-revs should be removed or hidden from
the user, since its existence implies that omitting it enables the usage
I was attempting?

I'm using subversion 1.2.3.



Received on Thu Jun 1 04:36:29 2006

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.