Re: Some cvs2bzr thoughts

On Fri, Oct 9, 2009 at 5:23 AM, Max Bowsher <[email protected]> wrote:
> Greg Ward wrote:
>> cvs2hg had exactly the same problem.  (Mercurial really doesn't like
>> repos with many many heads.)  Oddly enough, I came up with and
>> implemented the same solution as you propose.  My code has not yet
>> been merged into the cvs2svn trunk, so you might want to poke around
>> my "branch" of cvs2svn a bit:
>>
>>   http://vc.gerg.ca/hg/cvs2svn/
>>
>> In particular, an explanation of how I handled fixups is in
>>
>>   http://vc.gerg.ca/hg/cvs2svn/raw-file/tip/README.cvs2hg
>>
>> and the code (class HgOutputOption) is in
>>
>>   http://vc.gerg.ca/hg/cvs2svn/raw-file/tip/cvs2svn_lib/hg_output_option.py
>>
>> Follow self.pending_fixups to see how it works.
>
> Interesting... your approach is to add the extra parent on the next
> convenient revision that would happen anyway.
>
> I'm not entirely convinced that's the right thing to do, since it
> ascribes the merge to some author who most likely had nothing to do with it.

True.  But it keeps the number of spurious changesets to a minimum: at
most one per tag.  (And tags that are a "simple copy" [in svn-speak]
don't get a fixup at all.)

The merge commits that close fixup heads aren't *real* merges; they're
just dummy merges to keep the number of heads down.

> I've hacked up an initial implementation that does an immediate
> dedicated fixup commit after each tag commit, which I think is preferable.

So that's potentially 2 dummy changesets for each tag?  I can see your
point, but I'm not that offended by my use of dummy merges.  (If I
was, I would hardly have implemented it that way! ;-)

> What are your thoughts on this difference in design?

I slightly prefer my way, but I'm not dogmatic about it.  As long as
it's possible for me to override default behaviour and use dummy
merges for my conversion, either way is OK by me.

Greg

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2408345

To unsubscribe from this discussion, e-mail: [[email protected]].