You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rafael Garcia-Suarez <ra...@hexaflux.com> on 2003/08/29 13:37:30 UTC

svndumpfilter --drop-empty-revs

The docs for svndumpfilter seem to be rather terse as of 0.28.
Where can I find explanations for its options ?

I'm not sure what is the actual effect of "--drop-empty-revs".
This options sounds a bit too "internal" for the average svn
administrator...

-- 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svndumpfilter --drop-empty-revs

Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
cmpilato@collab.net wrote:
> Rafael Garcia-Suarez writes:
> 
> > Yes indeed ; what I meant is that, from the user point of view,
> > the sole option "--renumber-revs" seems sufficient. I don't see
> > the point of having "--renumber-revs" _and_ "--drop-empty-revs",
> > and that's why I'm asking if there's something I've missed
> > about those options.
> 
> If you run a dumpfile of revision 50-100 through svndumpfilter
> --renumber-revs, does its output begin with revision 0 or 1?  If so,
> then there's your reason.

Thanks, I understand now ; grepping a dumpfile for /Revision-number/
shows the effect of the renumbering.

> Of course, effectively (at least from 'svnadmin load's current point
> of view) that's a no-op, since it doesn't really care what you *call*
> your revision -- they are sequentially loaded regardless.

I suggest the following minor rephrasing for the help message of
svndumpfilter : (cc:ing dev)

--- subversion/svndumpfilter/main.c.orig
+++ subversion/svndumpfilter/main.c
@@ -663,7 +663,7 @@
     {"drop-empty-revs",   svndumpfilter__drop_empty_revs, 0,
      "Remove revisions emptied by filtering."},
     {"renumber-revs",     svndumpfilter__renumber_revs, 0,
-     "Renumber revisions left after filtering." },
+     "Renumber revisions in resulting dumpfile." },
 
     {NULL}
   };
End of Patch.

That makes clearer that renumbering and filtering are in fact dissociated.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svndumpfilter --drop-empty-revs

Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
cmpilato@collab.net wrote:
> Rafael Garcia-Suarez writes:
> 
> > Yes indeed ; what I meant is that, from the user point of view,
> > the sole option "--renumber-revs" seems sufficient. I don't see
> > the point of having "--renumber-revs" _and_ "--drop-empty-revs",
> > and that's why I'm asking if there's something I've missed
> > about those options.
> 
> If you run a dumpfile of revision 50-100 through svndumpfilter
> --renumber-revs, does its output begin with revision 0 or 1?  If so,
> then there's your reason.

Thanks, I understand now ; grepping a dumpfile for /Revision-number/
shows the effect of the renumbering.

> Of course, effectively (at least from 'svnadmin load's current point
> of view) that's a no-op, since it doesn't really care what you *call*
> your revision -- they are sequentially loaded regardless.

I suggest the following minor rephrasing for the help message of
svndumpfilter : (cc:ing dev)

--- subversion/svndumpfilter/main.c.orig
+++ subversion/svndumpfilter/main.c
@@ -663,7 +663,7 @@
     {"drop-empty-revs",   svndumpfilter__drop_empty_revs, 0,
      "Remove revisions emptied by filtering."},
     {"renumber-revs",     svndumpfilter__renumber_revs, 0,
-     "Renumber revisions left after filtering." },
+     "Renumber revisions in resulting dumpfile." },
 
     {NULL}
   };
End of Patch.

That makes clearer that renumbering and filtering are in fact dissociated.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svndumpfilter --drop-empty-revs

Posted by cm...@collab.net.
Rafael Garcia-Suarez <ra...@hexaflux.com> writes:

> Yes indeed ; what I meant is that, from the user point of view,
> the sole option "--renumber-revs" seems sufficient. I don't see
> the point of having "--renumber-revs" _and_ "--drop-empty-revs",
> and that's why I'm asking if there's something I've missed
> about those options.

If you run a dumpfile of revision 50-100 through svndumpfilter
--renumber-revs, does its output begin with revision 0 or 1?  If so,
then there's your reason.

Of course, effectively (at least from 'svnadmin load's current point
of view) that's a no-op, since it doesn't really care what you *call*
your revision -- they are sequentially loaded regardless.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svndumpfilter --drop-empty-revs

Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Garrett Rooney wrote:
> Rafael Garcia-Suarez wrote:
> > The docs for svndumpfilter seem to be rather terse as of 0.28.
> > Where can I find explanations for its options ?
> > 
> > I'm not sure what is the actual effect of "--drop-empty-revs".
> > This options sounds a bit too "internal" for the average svn
> > administrator...
> > 
> 
> When you use svndumpfilter to move one branch of a repository (say the 
> part of the svn.collab.net repos that held rapidsvn or gsvn), you can 
> either insert empty revisions for commits that occured in other parts of 
> the repository (so that the revision numbers in the new repository are 
> the same as those in the old one, so if people mentioned specific 
> revisions in bug reports, or emails, or whatever they don't become 
> invalid), or you can rip out empty revisions and allow the revision 
> numbers to change if you are bothered by the idea of a lot of empty 
> revisions.

Yes indeed ; what I meant is that, from the user point of view,
the sole option "--renumber-revs" seems sufficient. I don't see
the point of having "--renumber-revs" _and_ "--drop-empty-revs",
and that's why I'm asking if there's something I've missed
about those options.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svndumpfilter --drop-empty-revs

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Rafael Garcia-Suarez wrote:
> The docs for svndumpfilter seem to be rather terse as of 0.28.
> Where can I find explanations for its options ?
> 
> I'm not sure what is the actual effect of "--drop-empty-revs".
> This options sounds a bit too "internal" for the average svn
> administrator...
> 

When you use svndumpfilter to move one branch of a repository (say the 
part of the svn.collab.net repos that held rapidsvn or gsvn), you can 
either insert empty revisions for commits that occured in other parts of 
the repository (so that the revision numbers in the new repository are 
the same as those in the old one, so if people mentioned specific 
revisions in bug reports, or emails, or whatever they don't become 
invalid), or you can rip out empty revisions and allow the revision 
numbers to change if you are bothered by the idea of a lot of empty 
revisions.

-garrett


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org