Martin J. Stumpf writes:
> 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.
Why not use locks? This is one advantage to checking out directories and
not individual files. The first person to check out the workspace locks the
whole thing and can make changes as necessary. When the changes are
committed (including the file rename) and the lock released, then the second
developer gets to do whatever is needed.
-- a
--------------------------------------------------------------------
Andy Peters devel@latke.net
ASP Digital cell: 520-907-2262
Live Sound Engineering home: 520-791-2716
Digital Circuit Design 5511 E Rosewood St, Tucson, AZ 85711
(note new address!!!)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 13 19:39:00 2006