[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help with tagging
From: |
Mark E. Hamilton |
Subject: |
Re: Help with tagging |
Date: |
Tue, 19 Jul 2005 10:22:38 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 |
Steve,
S I wrote:
I thought the sneakiest solution would be to get the latest from Main
(1.375) and bring it into my working copy of the branch and just check
it in which will bring the branch now to 1.369 since it'll be just like
as though somebody manually edited the file and checked it in. The
developers are ok with this method but for my own peace of mind...does
this method leave any history?
This is not a sneaky solution; it's normal. When you have bug fixes that
need to be made you have to commit them to both the mainline and to the
branch separately. You could onsider this the first bug fix for the branch.
However, I'd make the developers do this. If it's painful enough they
might pay more attention to deadlines, (or at least informing you that
they need the deadline delayed for a commit or two.)
OR
Should I force the tag on the file on the Mainline and then force the
branch on it? Is this even possible? How? And if so, is this a better
method? Please give me an example.
If it's just the one file, and if no one has started using the branch
yet, what I would is delete the branch and reference tags from just that
file, then re-tag and re-branch the 1.375 revision. This would mean that
the reference tag wouldn't represent a point in time (ie, the day you
tagged it,) but it would represent the desired state of the code at that
time.
So, what I would do is:
cvs tag -B -d branch_tag incorrect_file
cvs tag -d reference_tag incorrect_file
cvs tag -r 1.375 reference_tag incorrect_file
cvs tag -b -r reference_tag incorrect_file
Thank you
Steve
--
----------------
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
505-844-7666