On Fri, 17 Nov 2006, Les Mikesell wrote:
> On Fri, 2006-11-17 at 13:32 -0800, Tim Hill wrote:
> > My point is I *have* to commit the copy and the fix at the same
> > time, else how can the tag truly reflect the point in time where the
> > fix occurred? If I commit the fix and *then* create the tag I have
> > two distinct commits, and there always exists the possibility of
> > another commit sneaking in between the first and the second:
You can make a note of the revision number from the first commit, and
use that in the second commit, assuming the second commit is an URL to
URL copy. But it's easy to forget to do that, and it's difficult to
explain the necessity of doing that.
> I don't get it. Why wouldn't you commit to the trunk (if you even want
> the change to appear there), then copy your working copy to the tag
> so there is no chance of anything changing that you don't want in the
> tag.
Most people have mixed-revision working copies most of the time. So
if you create a tag by copying your WC, instead of "project/tags/foo
is a copy of project/trunk as of revision N" you get different files
in project/tags/foo being copies of different revisions of the
corresponding files in project/trunk.
If you have any uncommitted changes in your WC, copying your WC to a
tag will copy those changes too. This is likely to be a mistake. Even
if it's deliberate, you are likely to forget to explain it in the log
message.
For both the above reasons, I recommend avoiding WC to URL copies. Use
WC to WC copies for rearranging things before you commit, or URL to URL
copies (with explicit revision number) for creating tags or branches.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 18 06:40:46 2006