You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/10/10 18:19:11 UTC
Re: svn commit: r16350 (svndumpfilter renumber revs changes)
> ------------------------------------------------------------------------
> r16350 | cmpilato | 2005-09-29 13:21:27 -0500 (Thu, 29 Sep 2005) | 16 lines
> Changed paths:
> M /trunk/subversion/svndumpfilter/main.c
>
> Finish issue #1911 -- svndumpfilter not correctly remapping removed
> revisions
>
> Teach svndumpfilter to, when tempted to use as a copy source revision
> a revision that it has previously dropped (--drop-empty-revs
> --renumber-revs), use instead the youngest not-dropped revision
> older than that dropped revision.
This complex but extremely clear comment belongs not in the log
message, but near the new revmap_t data structure, IMHO.
> * subversion/svndumpfilter/main.c
> (struct revmap_t): New.
> (struct parse_baton_t): Add 'last_live_revision' member.
> (new_revision_record): Stop populating the renumbering hash.
> (output_revision): Populate the renumbering hash here, instead.
> (new_node_record): Expect 'struct revmap_t' value in the renumbering
> hash, and stop checking for sentinels that were never present.
> (parse_baton_initialize): Initialize new 'last_live_revision' baton member.
> (do_filter): Expect 'struct revmap_t' value in the renumbering hash.
A general thought about this change: I wonder if the code could be
simplified by doing away with the conditional, and simply always being
in "renumber revs mode", just sometimes we'd remap a rev to the same
value.
[...ponders...]
Hmmm, now that I really think about that, I'm not so sure it's a good
idea. Maybe I should erase it. Or maybe I'll post it, just to see
what you say.
I looked hard for real problems in the changes, and didn't see any.
Should that worry us? :-)
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org