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