On Tue, 2006-11-21 at 02:34, Tony Harverson wrote:
> > [2] The ability to create a tag at commit time in one single
> > atomic operation, via some sort of --tag switch to svn
> > commit. This would certainly take care of issue (1) for me
> > and would, I suspect, make
> > (2b) go away for a lot of people. And, yes, I'm aware that
> > this is also a tricky feature to get "right".
>
> This feature, as it has been discussed in this thread in the past,
> was to allow the user to commit their workspace to a Label/Tag without
> worrying what's in HEAD, right? So you commit a copy of foo.c with changes
> that you've made to make the build work, and it commits that file (along
> with all the others in your workspace) to the repository, and labels them
> with the label?
Copying from a workspace to a new tag atomically already works
but since labels aren't properties of the files, existing
ones don't get carried along and you can't track the points
where they were tagged except from within the tag.
> So.. Where does the above commit (commit my workspace to tag PRODUCTION_1_1) go,
> if there are existing changes in the HEAD revision of the files you're
> committing? Does it Merge them in, commit over them (and then revert them
> in the next rev?), or fail completely?
Currently tags are fully equivalently to branches with a convention
that you don't commit additional changes. If you copy from
a working copy, new files are added directly that may not
exist anywhere else. The scenario where they sort-of work is
where you work on the trunk or branch, commit work there, then
copy to a tag to identify a particular set of files. Others
are advocating always copying from a repository revisions but
I've been pointing out that in the presence of concurrent
workers, you may never be able to create the repository revision
that you wanted to tag, even though it exists in your working
copy when you commit.
> Or does Subversion have to support the introduction of non-sequential changes?
> (r 10 -> r 12) with r11 on the side(and not affecting/affecting HEAD?) because
> that's a commit from a user's tagged workspace?
Currently tags are fully equivalent to branches, where the point
of using branches would usually be because you don't want the
commits to appear on the trunk. So, if you make a change and
copy to a tag without committing anywhere else, it won't appear
anywhere else. In some cases that may be what you want - if it
isn't, you can handle it like a branch to merge the change to
the place you did want it.
--
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 Tue Nov 21 15:13:50 2006