[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: adding on branch

From: Derek Robert Price
Subject: Re: adding on branch
Date: Wed, 28 May 2003 14:46:08 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

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 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, 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 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 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 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'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 & 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.  :)



Email: derek@ximbiot.com

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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]