Re: cvs2svn, vendor branches, and missing default branch

On 1/5/15 6:46 AM, Michael Haggerty wrote:
> On 01/05/2015 09:11 AM, john hood wrote:
>> On 1/3/15 4:32 PM, Michael Haggerty wrote:
>> [...]
>>> Given your description of the problem and of CVS's behavior, I don't see
>>> how we can justify treating vendor branch revisions as HEAD branch
>>> revisions if there is no 1.2 revision to tell when to switch back to
>>> HEAD (i.e., I think this change would be justified in general, not just
>>> in your special case).
>> I confess to some unease about the simple fix though it seems to work.
>> There was some case I was concerned about when I was looking through the
>> source, but I've forgotten what it was now.
> If you can think of a reason not to make this change, please let me
> know. I can't think of one, but you might very well have more hands-on
> experience with vendor branches than I do.
>
> Michael
>
Sorry to not respond earlier.  I got pulled off this project, and was 
never certain about whether the change was a good one.

We're now back to CVS conversion, but we're going to git this time. 
Reviewing the full output of git --log --graph --stat --dec on our real 
repo, and on my not-destroyed test repo, gives me more confidence that 
this is a good fix.  On our full repo, I'm seeing cvs2git generate some 
revisions for tags with cvs2git comments indicating a sprout from head, 
a cherrypick from one of the vendor branches, and sometimes unique 
changes.  But --stat indicates no actual diffs from their parents, so I 
consider this an annoying but cosmetic issue for us.  So I think you 
should commit your cvs2svn fix.

Another minor issue I'm seeing is that one of our product builds that 
has a small dependency on this repo uses a partial checkout of the tree 
and tags only that.  cvs2git generates a commit with only the tagged 
files, instead of, instead of tagged files + untagged files from trunk 
as I would expect from CVS.  Again, I think this isn't a big issue for 
us, though the cvs2git-generated comments are huge because of the 
thousands of deleted files.

regards,

   --jh

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

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