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