2) I need a bit more clarification on the following: >>b) it tags the
revision that is checked out, not the physical copy that is in your sandbox
<<
Let's say I synchronize my local copy with the repository in the morning
and I get the latest revisions of all assets. I then work on
MyRequestController.java. I start wiht a revision 1.3 that I got fresh from
the repository and I make a small change to it but I don't commit it to the
repository because I have not yet fully tested my changes. Meanwhile, my
team lead wants me to TAG the projects at this point in time to mark a
release. I want to make sure that the tag will affect revision 1.3 of the
MyRequestController.java file that resides in the repository and NOT the
modified version that lives in my local copy. It appears from the
description that it will tag revision 1.3 as desired - please confirm.
If
the cvs tag command would tag revision 1.3 in the repository regardless of
what's in my workspace then I think this is what we need...
3) Reading the documentation on rtag command, it looks like it may not be
that useful. The documentation suggests that when Tagging (and NOT
branching), you need to specify a revision number for each file...
Thanks in advance,
James
------------------------------------------------------------------------------------------------------------------------------------------------------------
"Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code 6067"
<address@hidden>
Peter Connolly wrote, On 07/28/2007 12:26 PM:
1) We have three separate projects that together make up the deployment
assets: Commons, Web, and Testing. First question is: can I TAG all
three of
the projects with the same TAG to mark the same mile-stone in all three
of
them?! Guessing that it's not a problem but wanted to confirm.
See 2nd answer...
Yes.
And I _think_ you could even tag all of them with one command:
cvs tag mytag sandbox1 sandbox2 sandbox3
2) Need to TAG the projects while having some uncommited resources
locally
- is this a problem? I seem to recall from the docs that the TAG command
only affects the repository, so any uncommited changes locally should
not be
included. Not sure if cvs will insist that they be checked in first?!
Ideally, whatever is in repository at the time the TAG command is issued
for
each project should be tagged, and all local changes should be
excluded/ignored. Here is the command I plan on using (after navigating
to
each project dir):
The 'cvs tag' command operates on your local sandbox. If the files
that you want tagged are already in the repository, then you want to
use the 'cvs rtag' command which operates directly on the repository.
See the manual for more details.
Lets be clear here,
although 'cvs tag' works on the revisions checked out into your local
sandbox,
a) it only works on files that are under CVS control (added and
committed),
b) it tags the revision that is checked out, not the physical copy that is
in your sandbox,
so you need to commit any thing that you have added|removed|modified before
applying the tag, if you want what is IN your sandbox to be tagged.
http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_17.html#SEC157
There is nothing preventing you from 'cvs rtag'ing three or more
directories in the same command. That would be the best way to answer
#1 above, although there's nothing stopping you from rtag'ing each
directory separately (except the increased possibility that someone
will commit files in one directory while you're tagging another).
Use of a date specification can reduce that possibility, and using normal
'cvs
tag' you can even contrive the set of files/revisions and then apply a tag
against that.
i.e.,
cvs checkout project
cvs update -r1.2 project/FileThatIsAtR1.5.txt
cvs tag mytag project/