Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> From: cvsnt-bounces at cvsnt.org
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Bo Berglund
> Sent: Monday, 16 January, 2006 13:45
>
> On Mon, 16 Jan 2006 17:39:07 +0000 (GMT), Stephen Hartley
> <stephenhartleyjunk at yahoo.co.uk> wrote:
>
> >I'd be grateful if anyone can clarify my understanding
> >of the following behaviour of CVSNT:
> >
> >My objective is to create a tag which marks the
> >current end of a CVS branch.
This is ambiguous. Are you trying to create a tag which will always
represent then end of the branch when you refer to it, or one which will
represent the end of the branch when you create it?
For example, if file foo current has revision 1.2.2.3 on branch
Somebranch, are you looking to create a tag which will always refer to
revision 1.2.2.3, or to whatever is at the end of the 1.2.2 branch?
Your question could be interpreted either way.
The short answer is that the branch tag ("Somebranch") will refer to the
end of the branch (for most purposes); if you tag the branch (eg using
the command below), that tag will refer to the version that's at the end
of the branch when you run the rtag command ("1.2.2.3").
> >According to
> >http://www.psc.edu/~semke/cvs_branches.html:
> >
> >"In order to name the current end of a branch of a
> >module, use the command
> >
> > cvs rtag -r Branchname Tagname my_module
> >"
> >
> >which would seem to be exactly what I want - the
> >branchname is dynamic in that it reflects any files
> >added/modified on this branch when tagging.
That command tags all the files in my_module which already have the
branch tag Branchname with the tag Tagname; Tagname is associated with
the revision which is at the top of the branch *when you run the
command*.
When you run that command, it will tag all the files in my_module which
are currently on the branch. I'm not sure what you mean by "branchname
is dynamic".
> >However, according to the description of rtag options
> >from cvsnt-Concurrent Versions System 2.5.03.2151
> >(source: http://www.cvsnt.org/manual/), and also
> >Cederqvist,
> >
> >"-r tag Only tag those files that contain existing tag
> >tag."
Branch tags are tags, and this applies to branch tags as well. If a
file is on a branch, that means it contains the branch tag.
> >Which makes me wonder, if I create a branch and then
> >add a file on it, if I pass the branch name as the -r
> >parameter, will the new file get included in the tag?
> >(I want it to be included!)
Yes. It doesn't matter whether the file was on the branch when the
branch was first created, only whether it's on the branch now.
> >In other words, does rtag's -r option expect a tag
> >name (Static) or a branch name (dynamic).
Here you seem to be confused. A branch tag refers to a branch - that
is, to the latest revision in a set of revisions - and a non-branch tag
refers only to a single revision, but aside from that there's little
difference between the two. For most commands that take a -r parameter,
it works as you'd expect: if the tag name refers to a regular tag then
it acts as if you'd specified that revision, and if the tag name refers
to a branch tag it acts as if you'd specified the most recent revision
on that branch.
For rtag (and tag) in particular, -r doesn't care whether you specify a
revision string (eg "1.2", "1.2.2.3"), the name of a regular tag, or the
name of a branch tag. It just uses the argument to determine (for each
file) which version it's tagging.
> It would be so much simpler if you used cvs tag instead of cvs rtag...
I think that's very dubious. I use rtag all the time to tag branches
(for delivery to our automated build system). It saves me from having
to run an update first, and there's no race between when I run an update
and what other developers may be doing; whatever's been committed when
the rtag command gets to a given file is what's tagged. Obviously there
are still potential races, but the window is much smaller, and there's
much less possibility for error because fewer actions are required on my
part.
And with rtag I don't have to worry about sticky tags, etc, in my
sandbox. If I want to tag a branch, I tell rtag to tag that branch.
In fact, I can't think of any situation offhand where cvs tag is
"simpler" than cvs rtag, unless the person running the command knows
that their sandbox contains precisely the versions they want tagged.
Which strikes me as a recipe for all sorts of problems, frankly.
When I want to tag the top of a branch, typically I want to tag several
modules, and only those modules; I have a simple script (Windows command
file, actually, since that's our primary development platform) that
reads a list of modules from a side file and does a "cvs rtag [options]
-l [tagname]" on each of them. (For many repositories, recursive
behavior would be fine; the way our code is organized, it's not what I
generally want.) The tagname and options are specified on the command
line, eg:
tag delivery_tag_name -r Some_branch -F
Of course, the tag script and its side file of modules are in CVS, in
the main source directory for the component I'm tagging. Simple, clean,
tough to screw up. (One possible enhancement would be to have it
remember the most-recently-used branch name and prompt to use it on
subsequent invocations, but since it's trivial to correct the case of
tagging the wrong branch, I haven't bothered.)
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus