Gerco Ballintijn <mailto:gerco@ballintijn.com> schrieb am Dienstag, 21. November 2006 15:32:
> 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!
This is just wrong. See mixed revision working copies. The restriction is: you cannot modify in your commit any resource (be it file or directory) that was modified after your last update of this resource. The following scenario will work just fine:
Repository contains one directory (D) with two files (F1, F2).
User A checks out D.
User B checks out D.
User A modifies F1 and commits.
User B modifies F2 and commits.
Note that A and B never modified the same resource.
User B now decides that his working copy is a fully working build and decides to tag D. However, there is no revision on trunk that exactly represents his working copy (and unless A's changes to F1 are reverted there will never be any).
This scenario will not work:
Repository contains one directory (D) with two files (F1, F2).
User A checks out D.
User B checks out D.
User A modifies F1 and commits.
User B modifies F1 and commits.
User B gets the notice that he must update F1 before he can commit. Note that A and B modified the same resource (F1)
>
> 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.
>
This is of no help - the version B wants to tag in scenario 1 never existed as a revision on the trunk and thus cannot be specified. Using mucc will not help as it will include A's changes in the tag - something B does probably not want to happen (as he did not test these changes).
> Greetings,
> Gerco.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
regards
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.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:53:52 2006