Re: CVS: replacing the head with a branch
KM <[email protected]> Thu, 23 Mar 2017 18:15:17 +0000 (UTC)
| Newsgroups | gmane.comp.version-control.cvs.general |
|---|---|
| Message-ID | <[email protected]> |
BTW - I just ran the update again with -dP and it seemed to resolve the iss=
ue of the extra files.=C2=A0 Seems to be working better now. ThanksKM
From: KM <[email protected]>
To: "[email protected]" <[email protected]>; "info-cvs@nongnu.=
org" <[email protected]>=20
Sent: Wednesday, March 22, 2017 3:02 PM
Subject: Re: CVS: replacing the head with a branch
=20
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 operati=
on.=C2=A0 I committed all of the changes and then my builds failed.=C2=A0 I=
t is because some directories (and their old head files)=C2=A0that existed =
in my old trunk/head still existed with the new one even though they did no=
t exist in the branch.=C2=A0=C2=A0=20
I expected these directories that did not have files in the branch, to be m=
arked for removal, and removed when I committed. So I obviously missed some=
options to one of the update functions.=C2=A0 I did read the notes/comment=
s added at these pages.
What did I need to add -dP maybe when I did the cvs update -jHEAD -jmybranc=
h, or just -P?
Sorry to be a pain.=C2=A0 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 file=
s out of my new trunk version.
any help would be great.KM
From: Erik Christiansen <[email protected]>
To: [email protected]=20
Sent: Wednesday, February 22, 2017 12:40 AM
Subject: Re: CVS: replacing the head with a branch
=20
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.=C2=
=A0
> The development was done by folks who are no longer with the
> company.=C2=A0=C2=A0Instead of sorting through all of that and figuring o=
ut 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.pd=
f
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=C2=A0 =C2=A0 =C2=A0 # Tag revision last synchronised =
with working dir.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 # -c =3D> Check files unmodified. (Recreatable)
And if you think of a better name afterwards, you can:
cvs tag -d Tag_String=C2=A0 =C2=A0 =C2=A0 # 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Float a tag to head of w=
orking dir's branch.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Recursive: Lists files affected.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Note:=C2=A0 =C2=A0 =C2=A0 Tags newly adde=
d 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=
=C2=A0.=C2=A0
> I tried this in a local working directory (without actually committing
> yet).=C2=A0 When I check out the branch and diff it against this it is th=
e
> 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?=C2=A0 meaning I will now be able to use the trunk as I d=
id
> 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=C2=A0I can still continue
> along the branch 'branch20' and merge back into the trunk afterward?=C2=
=A0
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
=20
=20