Re: adding on branch

Stefan Monnier wrote:

>>>I think that's due to your revision 1.2 above.  I'm not sure why you needed
>>>to do that.
>>>      
>>>
>>It is for dealing with merger issues... that is still the hardest
>>problem. Finding the correct greatest common ancestor version.
>>    
>>
>
>Could you expand on it ?
>The more I think about it, the more I feel that when import sees a file
>with no vendor branch yet and with a dead rev 1.1, it should do all the
>same as it currently does plus set the default branch to 1.1.1 (or
>wherever the vendor branch is).
>I think that should do it (modulo issues such as moving the file out of the
>Attic).  And I can't see in which way that would make merging worse than it
>is now.
>  
>

No, because an empty 1.1 with the same timestamp as 1.1.1.1 is how CVS 
currently detects that it should look for a version on the vendor 
branch.  In the case Paul brings up, after import, the RCS archive will 
end up with a 1.1.1.1, a dead 1.1, and a 1.1.2 branch, which should
be a derivative of 1.1.

If we alter CVS as you suggest, and retroactively allow 1.1.1.1 to be 
the magic, base revision for 1.1, then we will have corrupted the 1.1.2 
branch, as CVS only stores the full text of the most recent revision on 
the trunk , to create 1.1.2.X, it must reconstruct its GCA with the 
trunk, in this case 1.1, which will retroactively have been set to the 
text of 1.1.1.1.  It will then attempt to apply the 1.1.2 diffs in the 
RCS file to this text, which will most likely not have the result you or 
Paul were looking for.

I do agree with each of you, that if 1.1 is dead when imported, then no 
file was ever explicitly created on the trunk and an import should 
create a file there without requiring a merge.  Unfortunately, coding 
this behavior is not going to be as easy as Stefan would make it sound.

Mark came closest to an implementation plan with his suggestion, I 
think.  The search for 1.1.1.1 is currently hardcoded into the CVS 
source at the moment, but CVS does set the default branch attribute of 
the RCS archive on import to 1.1.1.  It is possible that this could be 
set to 1.2.1 when necessary and the appropriate default branch value 
loaded from the RCS archive rather than using hardcoded 1.1.1.1's and 
the proprocessor's definition of CVSBRANCH to find the relevant files 
and dates when necessary.

Some of this might be rather invasive.  It looks like add_rcs_file() in 
src/import.c will accept an arbitrary vendor branch as an argument, but 
update_rcs_ile() doesn't.  After that, RCS_getdate() at least, would 
need to stop using a hardcoded CVS_BRANCH & 1.1.1.1.  Then run the test 
suite and see what fails.  :)  I'm not sure if you will need to edit the 
tag code or not.

If anyone would like to submit a patch, I would be happy to review it.  :)

Derek

-- 
                *8^)

Email: [email protected]

Get CVS support at <http://ximbiot.com>!
-- 
151.  H lp!  S m b dy st l   ll th  v w ls fr m my k yb  rd!