CVS: replacing the head with a branch

[KM]

Hi All,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.  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?  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?  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

[Erik Christiansen]

Post by KM
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.

Post by KM
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.)

Post by KM
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.

Post by KM
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"

Post by KM
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

[KM]

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 trial.
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 <***@internode.on.net>
To: info-***@nongnu.org
Sent: Wednesday, February 22, 2017 12:40 AM
Subject: Re: CVS: replacing the head with a branch

Post by KM
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.

Post by KM
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.)

Post by KM
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.

Post by KM
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"

Post by KM
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

[KM]

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 <***@yahoo.com>
To: "***@internode.on.net" <***@internode.on.net>; "info-***@nongnu.org" <info-***@nongnu.org>
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 trial.
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 <***@internode.on.net>
To: info-***@nongnu.org
Sent: Wednesday, February 22, 2017 12:40 AM
Subject: Re: CVS: replacing the head with a branch

Post by KM
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.

Post by KM
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.)

Post by KM
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.

Post by KM
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"

Post by KM
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