On Fri, 2006-11-17 at 23:39, Alan Barrett 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.
Exactly. If you tag a repository revision, you don't really
know that it corresponds to your working copy. How do
you know that's what you want to tag?
> 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.
Yes, that would be a mistake. Or maybe not. If you are the
one creating the content to be tagged together and choosing
when to tag it, you should probably be the best judge of that.
You can, of course, always diff it against the trunk head if
you have any question about what you just did.
> 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.
I don't see how you can atomically tag something and know what
is in the repository at the same time. Back up to the previous
example where it was considered a problem that a user might
commit his change, then someone else might commit before he
copied to a tag, and copying the revision number given by his
commit to a tag was suggested as a solution. What if someone
else did their commit just before this user instead? The tag
still ends up including something he doesn't know about. If
you make the tag from the working copy you know (and perhaps
even have tested...) exactly what is there.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 18 07:03:29 2006