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