info-cvs
[Top][All Lists]
Advanced

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

Re: help, doing a CVS import messed up my working dir!?!?!


From: Mark D. Baushke
Subject: Re: help, doing a CVS import messed up my working dir!?!?!
Date: Mon, 22 Aug 2005 10:37:17 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Korn <address@hidden> writes:

> ----Original Message----
> From: Mark D. Baushke
> >Sent: 22 August 2005 18:01
> 
> > Dave Korn writes:
> 
> > All of the conflicts are a result of your commits to the mainline of
> > changes to previously imported KERNEL_ORG files.
> 
>   We're just having a slight semantic disagreement here; 

I am just giving you the point of view of the cvs executable...

> to me, a conflict is what happens when you try to apply a delta to
> something that already has a (non-identical) delta in the same region,
> and it doesn't make sense to talk about a conflict between files on
> separate branches; 

Yes, but the VENDOR branch is the default main trunk until such time as
you introduce local changes. From the vendor branch point of view, your
local changes are conflicts in the main trunk that need to be resolved
before the new VENDOR branch will really be visible on the main trunk.

> I thought I had 1.1 on mainline, and applied a delta that made it 1.2,
> and I thought I had 1.1.1.1 on the vendor branch, and was (by doing
> the import) effectively applying a delta to get 1.1.1.2, and I didn't
> see how there could be a conflict, since both of them were clean
> deltas to the original source file and I never asked it to apply both
> deltas to the same file!

When a new RCS file is created outside of the VENDOR branch, 1.1 is the
first version and the RCS head is 1.1 and there is no 'branch' directive.

When a new RCS file is created using cvs import, the first version is
1.1 as it is always needed, but it is never really used. The 1.1.1.1 is
created as an exact copy of 1.1, the head is 1.1 but a 'branch 1.1.1' is
added to the file. This means that any checkout will pick the 1.1.1.x
version for the largest value of x that is not in the dead state.

A 'cvs commit' of a change to the main trunk of an imported file will
create version 1.2 as head and remove the 'branch 1.1.1' indication.

> 
>   And to tell the truth, that's all just a matter of wording, but what I
> still don't understand is this:  when cvs complained about a conflict, was
> that because it was applying the 1.1.1.1->1.1.1.2 delta to something that
> already contained 1.1->1.2, or was that because it was applying the 1.1->1.2
> delta to something that already contained 1.1.1.1->1.1.1.2?

CVS complained because it saw that the main trun was not using branch 1.1.1
and knows that you must merge the differences of the 1.1.1.1->1.1.1.2 into
the main trunk in order to have a consistent main trunk.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDCg1MCg7APGsDnFERAmFgAKDU9wpkqhz1QFusPig+ljS+FC572gCg7Ye4
A1hSUvFPtIo2hJ81qAk0F+4=
=WFx1
-----END PGP SIGNATURE-----




reply via email to

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