Les Mikesell wrote:
> 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.
>
You CANNOT commit to trunk when others have already committed
their changes, that is, when the BASE revision of your working
copy is no longer the HEAD!
When other can potentially commit after your commit but before
your copy you, unfortunately, need to specify the revision, or
use the (contributed?) "mucc" command to combine them atomically.
Greetings,
Gerco.
---------------------------------------------------------------------
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:31:36 2006