[Top][All Lists]

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

Re: CVS: replacing the head with a branch

From: KM
Subject: Re: CVS: replacing the head with a branch
Date: Thu, 23 Mar 2017 18:15:17 +0000 (UTC)

BTW - I just ran the update again with -dP and it seemed to resolve the issue 
of the extra files.  Seems to be working better now. ThanksKM

      From: KM <address@hidden>
 To: "address@hidden" <address@hidden>; "address@hidden" <address@hidden> 
 Sent: Wednesday, March 22, 2017 3:02 PM
 Subject: Re: CVS: replacing the head with a branch
Thanks for the info... not sure if I ever sent anything back.
Well I ran a few tests and diffed the files and all seemed well. .... in my 
I made a copy of the repo and then performed this again as the real operation.  
I committed all of the changes and then my builds failed.  It is because some 
directories (and their old head files) that existed in my old trunk/head still 
existed with the new one even though they did not exist in the branch.   
I expected these directories that did not have files in the branch, to be 
marked for removal, and removed when I committed. So I obviously missed some 
options to one of the update functions.  I did read the notes/comments added at 
these pages.
What did I need to add -dP maybe when I did the cvs update -jHEAD -jmybranch, 
or just -P?
Sorry to be a pain.  I am not sure now if I should copy my repository back and 
start over or if I can recover from here to try and get these files out of my 
new trunk version.
any help would be great.KM

      From: Erik Christiansen <address@hidden>
 To: address@hidden 
 Sent: Wednesday, February 22, 2017 12:40 AM
 Subject: Re: CVS: replacing the head with a branch
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:

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,
> . 
> 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




reply via email to

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