info-cvs
[Top][All Lists]
Advanced

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

Re: CVS: replacing the head with a branch


From: Erik Christiansen
Subject: Re: CVS: replacing the head with a branch
Date: Wed, 22 Feb 2017 16:40:30 +1100
User-agent: Mutt/1.5.21 (2010-09-15)

On 21.02.17 17:37, KM wrote:
> Hi All,

I'm not sure how many "All" there are on the list these days, and some
of us have not used CVS a lot in the last decade or two, good as it is.

> We have a ton of development on the trunk/HEAD which we've
> never used due to changes in our releases off the branch for a time. 
> The development was done by folks who are no longer with the
> company.  Instead of sorting through all of that and figuring out what
> works and what does not, we want to make the head look like our latest
> branch.

That is normal practice, and often occurs when work on a branch brings
new features to a now outdated head. If you look at "5.6 Merging an
entire branch" in:
http://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/cederqvist-1.12.13.pdf

you'll see that what you describe is basic standard usage; fiddle on a
branch, then bring it back to the head as the next version. You'll then
want to tag the new head version with a useful mnemonic, using:

cvs tag -c Tag_String      # Tag revision last synchronised with working dir.
                           # -c => Check files unmodified. (Recreatable)

And if you think of a better name afterwards, you can:

cvs tag -d Tag_String      # Delete a tag

If you have to fiddle with head afterwards, e.g. a last minute bugfix, and
really want the good mnemonic tag on the new version:

cvs tag -F Tag_String         # Float a tag to head of working dir's branch.
                              # Recursive: Lists files affected.
                              # Note:      Tags newly added files also.

(Years later, there's not much that's more important than still being sure
that you have the right version of every file, thus the tag fetish.)

> For our argument lets say 'branch20'. I found the following post,
> http://stackoverflow.com/questions/115098/cvs-replace-head-with-a-branch . 
> I tried this in a local working directory (without actually committing
> yet).  When I check out the branch and diff it against this it is the
> same..... so it seems that this procedure works. This is probably a
> stupid question, but this is just like replacing files and committing
> as normal right?  meaning I will now be able to use the trunk as I did
> before for my main/major version builds (for next release 3.0), but it
> will just look like my update branch 'branch20' now?

What you're doing is making a new head, which is the current state of
branch20. Release 3.0 will come from head, but be based on branch20.
Whack a release tag onto it once done, though.

> And if we have more incremental updates for 2.0 I can still continue
> along the branch 'branch20' and merge back into the trunk afterward? 

That's how it works. ;-)
See: "5.1 What branches are good for"

> Sorry if this is hard to explain in words. I think it's fine, I just
> wanted to be sure I wasn't going to mess up CVS.
> Thanks in advanceKM

A good strong cup of coffee, a packet of Tim Tams, and a relaxed read of
the Cederqvist is the best cure for the doubt that results from having
forgotten the lost arts.

As a CVS repository is self-contained, you can take a recursive copy of
the whole thing, and punish that until you're happy to twiddle the
original.

Erik



reply via email to

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