RE: The use of CVS Branches???

[Thornley, David]

> -----Original Message-----
> From: Patrice Martin - GRE [mailto:address@hidden
> Sent: Thursday, June 21, 2001 8:22 AM
> To: address@hidden
> Subject: The use of CVS Branches???
> 
> 
> Hello,
> 
> I use CVS V1.10, and i am in confusion with the CVS branches.
> 
If that's 1.10, with no .7 or .8 after it, you should upgrade.
1.10 is not Y2K-compliant, and if you use date specifications
anywhere you're going to have problems.

> First, what is the basic difference between "cvs commit" and "cvs
> import"?
> 
The intention is that "cvs commit" is for changes you make, and
"cvs import" for tracking other people's code.  The main difference
is that "cvs import" is much more sweeping than "cvs commit", and
models what you'd want to do when getting the latest source release.

> I think that my problem came, because i track my source evolutions by
> always doing an "cvs import" from the head directory of my project.

In doing that, you are not making the best use of CVS.  You could do
about the same thing with a collection of dated tarballs.

I'm not going to tell you you're doing the wrong thing here, but
you do need to understand that this is not how CVS was intended to
work.  You can pound in a nail with a wrench, but it's not easy
to pound in a nail and tighten a nut at the same time with the same
wrench.

> I have made this choice, because there is often lot of modifications
> made at the same time in that project.
> So in intent to not do "cvs commit", "cvs add", "cvs remove", 
> and so on
> each time, from file to file, or directory to directory, i do an "cvs
> import" one for all, starting at the head directory of the 
> project, once
> i want to do a version.
> It's work well like this until last month.
> 
Hmmm. Massive changes seem to work with "cvs commit" here, and
everywhere else I've heard of.  What do you do for small changes?
By treating your code as if it were vendor code, you at least
make it harder to use CVS like a real SCM system.

> But recently, i want to make branches for tracking parallel 
> development
> of the project, because one part of the project go in maintenance, and
> the other part stay in development with evolutions and new
> functionalities.
> 
Right.  This is not usually a problem.  However, since you're
doing the wrong thing, you're having problems.  What you need
to do to make this work smoothly is to do your changes on
checked-out copies and commit your work, not make your changes
on external copies and import it.  This will leave you
doing what most of us do, and what CVS was designed for, and
then it's much easier to help you.

So, make sure all the "vendor" changes are merged to head.  Cut
a branch for the maintenance version, using a branch tag, a
start tag, and a merged-up-to tag.  Check out workspaces to do
your development in, and commit from there.

When you commit a bug fix to the maintenance release, merge the
changes from the merged-up-to tag to head, and move the merged-up-to
tag.

> But by doing like this, i cant merge the modifications made in that
> branch, because
> the cvs (in fact rcs) revision number doesn't match the cvs revision
> number of the trunk.
> And then the diff, update and merge commands doesn't work very well...
> 
If you're sweating the revision numbers, you're doing something wrong.
IIRC, multiple vendor branches (and that's what you're proposing)
have always been awkward.

> So now i am completely confused with the used of branches with CVS.
> 
> May i have some explanations and help to understand what's happen, and
> then try to fix my problem,
> and then used correctly CVS branches, for tracking parallel 
> development.
> 
Correct use of CVS branches depends on correct use of CVS.  Once
you are using CVS as it was designed, you will find it far easier
to use CVS features.