[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is label support in future release?

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2006-11-18 02:37:58 CET

On Fri, 2006-11-17 at 18:48, 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.

The change _does_ exist in the tag. That is, the tag does
not exist until the snapshot of the workspace is committed.
If you want that copy you use the tag and what's in the
trunk is not particularly relevant. As you noted in your
example, someone else can modify the trunk any time so you
can't trust what is there unless you have a revision number
you know happened as a commit from a workspace in exactly
the right state. So why not use the tag committed from
there instead and let the trunk go about its business towards
the next one? If you want the change on the trunk for future
versions, commit it there too, but there is no need for that
step to be atomic with anything.

> >
> > 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.

But that's what you get when you name this tag. What is the
problem with using this tag name anywhere you might have
used a revision number or the label that you'd like to
refer to one?

  Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 18 02:38:59 2006

This is an archived mail posted to the Subversion Users mailing list.