[cvsnt] Re: CVS Use case

Matt Schuckmann matthew_schuckmann at amat.com
Mon Apr 25 22:33:09 BST 2005


Matt Schuckmann Wrote:
> > By using the floating branch tag we almost get the best of both worlds
> > 1. The developers new code is kept issolated on the branch and the
branch is
> > really only those changes made by the developer.
> > 2. The developers get the lastest stable code from the release code line
> > whenever they update thier sandbox.
> > The only thing they don't get is any changes made on the release code
line
> > in files they have modified on the branch, to get those changes they
must do
> > an explicit merge from the parent to the branch.
> >
> > I guess what I really want is a floating branch tag that only floats
when
> > you merge the parent onto the branch, that sounds a little more usefull
than
> > the way it's implimented now, it sort of prevents unexpected breaking
and it
> > helps to keep the task branch to purely task releated changes.   What do
you
> > think?
>
> Glen Starrett Wrote:
> That's essentially what mergepoints do for you, and what makes them so
> valuable.  Then the developer decides when to get the latest -- gives
> them the control (OK, they have control over when they do an update, but
> I often update in order to reset accidental changes or other reasons).
>

I don't quite see your point. Mergepoints just tell you when a revision was
created as a result of a merge and where that merge came from, right?

I'm interested in preventing revisions from occurring on a branch on files
that otherwise wouldn't have branch revisions because that file doesn't have
any changes specific to the Task that branches is associated with. Is that
clear, it's kind of tough to explain, this is a place where a picture would
be worth ....

Say you have a.cpp with a branch tag but no revisions
a.cpp
1.1 - - - BR1
  |
  |
1.2

And you do an explicit merge of HEAD into BR1 (cvs up -kk -j HEAD)
a.cpp
1.1 - - - - - BR1
  |                  |
  |                  |
1.2 -----> 1.1.2.1

Now you have 1.1.2.1 which is just a copy of 1.2.
It would be nice if you had the option for the merge to just move BR1 to 1.2
instead.This is in essence what floating branches are supposed to do except
they do it implicitly and it might be better if they did it explicitly (i.e.
via a merge command with maybe a special option or something)

I suppose that you could infer that a file has no changes associated with a
task if all the revisions on that Task's branch are the result of merges
from the parent (identified by mergepoints) but that could get a little
confusing and would require some sort of special script.

On a side note I've done some testing of floating branches and they sorta
kinda work. They don't seem to quite work right when you apply a floating
branch to a branch or a floating branch to a floating branch.
Also the rtag command doesn't recognize the -M option, although "cvs -H
rtag" says that it should.
I can post a new thread detailing the problems I found.

Plus it also appears that WinCVS, ViewCVS, and CVSGraph all don't know how
to deal with them.

I was testing with CVSNT 2.5.01 (Travis) Build 1927

 Matt S.





More information about the cvsnt mailing list