[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: renaming branches
Re: renaming branches
Thu, 9 Aug 2001 15:41:14 -0500
Mark A. Turner (address@hidden) wrote:
> I've often needed to rename a cvs branch tag, and I think I just came
> up with an acceptable way. I'm sure it's not original, but I haven't
> seen any better answers around. Please let me know if what I propose
> below has any known pitfalls.
> Assuming the branch I want to rename is 1.3.2 with the name "branch1"
> I want to issue the foollowing commands to change the name of 1.3.2
> from "branch1" to "branch2"
> # Create a new name that refers to the 1.3.2 branch.
> # Am I correct that after this command, I can refer to the 1.3.2 branch by
> # of the three names "1.3.2", "branch1" and "branch2" for any cvs
No. That is not correct. Revision numbers are per file.
a branch tag refers to a whole set of revisions on a set
of files. Each file on the branch has a revision number which
is completely independent of the revision numbers of any other
file on the branch.
> cvs rtag -r 1.3.2 branch2 module_name
This creates a non-branch (regular) tag. (the -b option is
necessary to create a branch tag.) Also, it doesn't
make sense to use a revision number with rtag (vs. tag)
and a module_name (vs. a filename) Revision numbers apply
to individual files, not modules, or sets of files.
> # Remove the name "brach1" from the module "module_name"
Do not do this. There is NO way to undo it (that will
work in every case).
> # Doesn't the 1.3.2 branch still exist as it always did?
No. If you have a file on a branch which has no modifications
committed to that branch (extremely common case) then deleting
the branch tag erases _all_ information associating that file
with that branch. (that is, there is now, in the general case,
_no_ way to figure out which revision of that file used to be on
that branch. Specific cases may allow recovery, with help of
additional knowledge not stored in CVS, but not every case.)
(Also I find it weird that you have a revision number 1.3.2
with only 3 components. Should have an even number...probably
it's just a made up example.)
> # However, since it also has the name "branch2", I can still refer to
> it by
> # a name as well as by it's revision number after this command.
> cvs rtag -d branch1 module_name
That's because your "branch1" is not a branch tag. It's just a
regular tag. Had it been a branch tag, you'd be out of luck.
> Most of the questions I see posted about renaming branches focus on
> the names of the branch instead of the revision number (i.e. 1.3.2)
With good reason. Revision numbers are completely independent from
one file to another.
> that refers to the branch. Am I correct that cvs rtag -d branch_name
> module_name only remove the name of the branch. The branch still
> exists as it always did only now you would have to use the revision
> number when refering to it.
Nope. It's irretrievably lost. Specifically, branch tags work like
They associate a symbolic name with a so-called
"magic" revision number. The "magic" is that the
revision number associated with the branch tag is
not a real RCS revision number, but has an
extra zero in it that signifies it's a branch tag..
So if I say:
cvs tag -b -r 1.2 branchtag foo.txt
Then, CVS will associate "branchtag" with revision 188.8.131.52
of foo.txt. (NOte that revision 184.108.40.206 doesn't actually
When I check out using the branch tag:
cvs update -r branchtag foo.txt
Then, cvs transforms (in it's mind, so to speak) the revision
number 220.127.116.11 by removing the zero to get 1.2.2,
and looks for revisions of foo.txt of the form 1.2.2.x.
Finding none, it says, ah, foo.txt must not have any
changes committed to this branch yet, so that means it's
1.2 that's needed. and it checks it out, and notes in the
Sticky Tag inyour sand box that you've used a branch tag
that refers to 18.104.22.168.
If I successively commit foo.txt to the branch, it
will go in as revision 22.214.171.124, then 126.96.36.199,
then 188.8.131.52, 184.108.40.206, etc. Note other files
on the branch may have completely different
When I checkout using branchtag, i get the latest version
of foo.txt that has a revision of the form 1.2.2.x
(220.127.116.11, above) but the Sticky Tag will always
be "branchtag" ( -> 18.104.22.168)
Non-branch tags, by contrast refer to a single
"real" revision number that does not contain the
Note that if I create a second branch tag:
cvs tag -b -r 1.2 branch2 foo.txt
then branch2 points to 22.214.171.124 (the last number
gets incremented by two).
If I had tried instead to do:
cvs tag -b -r branchtag newbranchtag foo.txt
then newbranchttag -> 126.96.36.199. This allows
multiple branches (188.8.131.52, 184.108.40.206,
1.2.0.(n*2 : n=1,2,3,4...) sprouting off
a single revision (1.2. in this case).
A thread I found via google says that "cvs admin"
can do it, sort of, but I haven't tried it myself:
From: Matthias Kranz (address@hidden):
> On Thu, May 11, 2000 at 03:59:51PM -0300, Shane Turner wrote:
> > The only way that I know of to rename a branch tag is using cvs admin.
> > cvs admin -nbranch-name:new-branch-name
> You should permute the tag names to
> cvs admin -n<NEW_NAME>:<OLD_NAME>
> > You'll need to have the files checked out unfortunately.
> And you need also to remove the tag <OLD_NAME>, since otherwise you not
> renamed but only added it.
> cvs admin -n<OLD_NAME>
> > I don't think that there is a way to rename the branch in any file
> > that has been deleted on the branch.
> Of course, that is a problem.
So, choose (and type) your branch names carefully.
Hope that helps.
BTW, if somebody does know a reliable way to
rename a branch tag, I'd like to hear it...
(perhaps "cvs admin" can do it somehow.
- Re: renaming branches,
Cameron, Steve <=