info-cvs
[Top][All Lists]
Advanced

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

RE: Branching bug ??? (was Re: Bug is tagging the head of a branch head?


From: Paul Sander
Subject: RE: Branching bug ??? (was Re: Bug is tagging the head of a branch head???)
Date: Wed, 19 May 2004 15:34:40 -0700

>--- Forwarded mail from address@hidden

>> I don't think it's either, I think you're suffering from a fundamental
>misconception=20
>> of some sort about how branches work, but I'm not sure exactly what it
>is.

>Your explanation (and Larry's now) makes sense, but I wish CVS didn't do
>this...

>My problem is I'm trying to use CVS like ClearCase, which is clearly
>not, nor does it
>even start to pretend to be. So to "physically," and not just
>conceptually accomplish
>what I want to do, I'll have to somehow make CVS "think" that I've
>modified the files
>on my first branch "before" I make the second branch. I'll give this a
>shot...

>...or think of another way to accomplish what I want to do, which is to
>have a=20
>development branch, and then individuals' development branches off the
>development
>branch.

If the sequence of commands that to reach the state you mention in
your original post is as follows, then CVS is operating as designed:

cvs rtag -r HEAD -b b_dev_01_03 sample
cvs rtag -r b_dev_01_03 -b b_dev_01_03_cf sample
cvs checkout -r b_dev_01_03 sample
cd sample
<edit file1>
cvs commit
<edit file1>
cvs commit
cvs update -r b_dev_01_03_cf
<edit file1>
cvs commit
<edit file>
cvs commit

On the other hand, there is a bug in CVS if you get to that state using
the following sequence:

cvs rtag -r HEAD -b b_dev_01_03 sample
cvs checkout -r b_dev_01_03 sample
cd sample
<edit file1>
cvs commit
<edit file1>
cvs commit
cvs rtag -r b_dev_01_03 -b b_dev_01_03_cf sample
cvs update -r b_dev_01_03_cf
<edit file1>
cvs commit
<edit file>
cvs commit

It would help if you state which of these scenarios is closer to your
experience.

Keep in mind that CVS implements lazy branching, as ClearCase does
with the following config spec:

element * CHECKEDOUT
element * .../b_dev_01_03_cf/LATEST
element * .../b_dev_01_03/LATEST -mkbranch b_dev_01_03_cf
element * /main/LATEST -mkbranch b_dev_01_03_cf

or this one, if you label your branch sprout points:

element * CHECKEDOUT
element * .../b_dev_01_03_cf/LATEST
element * .../b_dev_01_03/B_DEV_01_03_CF -mkbranch b_dev_01_03_cf
element * /main/B_DEV_01_03_CF -mkbranch b_dev_01_03_cf
element * /main/0 -mkbranch b_dev_01_03_cf

If you're expecting a different behavior, it will take a lot of effort
to get CVS to do it.  You're better off to tolerate CVS' lazy branching
and to document the logical branch tree.

>--- End of forwarded message from address@hidden





reply via email to

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