Jacques Morel wrote:
>I guess the only thing I can do now is hope for the best ;-) I am just
>very surprised that this wasn't addressed earlier or even talked about
>more. This is a big issue and it dates from pre-1.0!
>Anyway maybe I could offer an incentive to the developer that will fix it ;-)
>
>The situation I am refering is the following:
>1. You and I update our workspace at the same time.
>2. You rename file test.txt to test2.txt.
>3. I edit test.txt
>4. You commit
>5. I try to commit and get a conflict
>6. I update =>
> a. test.txt is now local only (no longer in subversion) and is the
>exact same file as it was just before I updated.
> b. I have a newly created test2.txt from your commit. That file is
>in subversion.
>Conclusion: my changes were not merged in test2.txt and I have now 2
>files instead of one.
>To me the update failed. It did not leave my workspace in stable state
>so it should have failed. I need to work on finishing up merging my
>workspace. But this happened without warnings from subversion!!!
>
>
snip...
I wonder if the veritable concept of a 'watch' could help minimize this
unfortunate chain of events. The svn mv or svn rm commands could make a
server contact and notify watchers of the repository via email when they
take place (prior to commit) and then you would at least NOT continue
working on the file in question. Maybe something as simple as:
%svn watch -m mjs@jhu.edu executed in the working
copy or
%svn watch -m mjs#jhu.edh URL to get email notifications of
activity on a repo that you may not even have checked out.
We could place our email address(es) in our ~/.subversion/config file
and then not even have to specify the address. Obviously, the companion
svn unwatch would also be necessary and the repo would just keep an
unversioned property with all watchers.
It seems to me that copy/modify/merge is always going to have issues
that require timely communication and watches would be a helpful
communication device.
I know watches have been discussed before and dismissed but I think it
fits very well as mentioned as an aid to team communication.
-Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 13 17:43:17 2006