[Top][All Lists]

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

Re: Problems branching in CVS

From: Eric Siegerman
Subject: Re: Problems branching in CVS
Date: Fri, 6 Jul 2001 16:27:04 -0400
User-agent: Mutt/1.2.5i

On Thu, Jul 05, 2001 at 05:37:12PM -0400, Larry Jones wrote:
> berry writes:
> > In our shop, we have all components of a source set set
> > to the same revision number. This is how we operate.
> That is not how CVS operates.  You should use tags to identify things
> that belong together and ignore the revision numbers -- they're for
> CVS's internal use only.

To put it slightly differently: your shop presumably does things
this way because it makes it easier to tell which revisions of
the various files go together to make up a revision of the
overall source set.  But it's arguably counterintuitive to check
in a new revision of an unchanged file just so it'll have the
"right" revision number.  A "revision" should signify that the
file was revised, after all...

One of the things CVS does for you is to make this sort of kludge
unnecessary, by providing a better way to link a bunch of
revisions into a snapshot, even if their revision numbers bear no
relation to each other.  That better way is tags, as Larry
mentioned; specifically release tags (as opposed to branch tags).

> > To get the latest branched version, do I need to simply
> > check out -r branch_tag_text???????
> Correct.

Because "cvs {co|update} -r branch_tag_text" explicitly says: for
each file, give me that file's latest revision on branch
"branch_tag_text", whatever its revision number may be.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)

reply via email to

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