Felix Gilcher wrote:
> 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).
>
>
I tell our developers to only work on a single change set at a time in a
working copy. When it comes time to save changes, they commit the whole
tree. Using this approach, it is extremely rare that we ever need to
commit single files, so we never encounter the problem described above.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 24 14:46:07 2006