[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)