On Nov 17, 2006, at 2:24 PM, 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:
>
> 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.
Eh? So I have a tag that claims to reflect a change, but on closer
inspection the change did *not* occur at that commit? Sounds like a
nice confusing mess to me.
>
>> Are you *serious* ??? Have you ever sat down and tried to explain
>> tags to these people. It's not terminology, it's a much more complex
>> concept. Sorry, they can "get" labels, they don't "get" tags. You can
>> _call_ them labels, and they get it then, but once you start
>> explaining the *how*, they just glaze over.
>
> Call them snapshots or whatever you want. If they want to preserve
> an exact duplicate of their workspace, just:
> svn copy -m "my message goes here" . URL:/tags/my_name_for_this
>
> It's not difficult, has no issues with being atomic, and you
> get your choice of ever making the changes that appear here
> also appear in the trunk or not.
It's also not really the point: I want a symbolic identity for a
commit. I don't really see how this helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 18 01:49:56 2006