Should a locally modified, remotely removed file be handled as a conflict in an update? (retry -- with apologies)

[Peter Mb <mb...@yahoo.com>]

[Despite having plain text messages configured in my preferences, somehow some javascript found its way in my previous message. Apologies. I'll try again, hopefully things will go right this time.]

Hello all,


Recently I noticed that when one has modified a file locally and does an update when someone else has removed or moved the file to another directory and commited, the locally modified file is no longer marked is being under svn control but keeps its original filename.


This may lead  to several problems:

- A file may have become obsolete due to a refactoring by one developer. This developer removes the file and commits. A second developer concurrently adds fucncionallity to the file as part of another refactoring. When the latter does an update there are conflicting refactorings. The deleted file is not marked as being a part of the conflict, but it surely is.

- The file is moved remotely, the developer that has a modified copy locally does an update. The subsequent local build fails because of doubly defined symbols.

- A developer removes a file by accident, commits, another developer   does an update, having the removed file modified. The local build succeeds. That the repository is in a non-buildable state goes unnoticed longer than it should.

Note that even trivial changes,.added white space, an added debugging statement, for instance, leads to the last two problems.


My suggestion would be, at he very least, to rename the remotely removed file to <filename>.mine, similar to what a failed merge does. This way, the conflict stands out and the file no longer takes part in the build.


Any thoughts on this, please?


Regards,
Peter





      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Should a locally modified, remotely removed file be handled as a conflict in an update? (retry -- with apologies)

[Dave Lawrence <dl...@ad-holdings.co.uk>]

Peter Mb wrote:
> [Despite having plain text messages configured in my preferences, somehow some javascript found its way in my previous message. Apologies. I'll try again, hopefully things will go right this time.]
> 
> Hello all,
> 
> 
> Recently I noticed that when one has modified a file locally and does an update when someone else has removed or moved the file to another directory and commited, the locally modified file is no longer marked is being under svn control but keeps its original filename.
> 
The same is true for directories that contain modified or unversioned items.

> 
> This may lead  to several problems:
> 
> - A file may have become obsolete due to a refactoring by one developer. This developer removes the file and commits. A second developer concurrently adds fucncionallity to the file as part of another refactoring. When the latter does an update there are conflicting refactorings. The deleted file is not marked as being a part of the conflict, but it surely is.
> 
> - The file is moved remotely, the developer that has a modified copy locally does an update. The subsequent local build fails because of doubly defined symbols.
> 
> - A developer removes a file by accident, commits, another developer   does an update, having the removed file modified. The local build succeeds. That the repository is in a non-buildable state goes unnoticed longer than it should.
> 
> Note that even trivial changes,.added white space, an added debugging statement, for instance, leads to the last two problems.
> 
> 
> My suggestion would be, at he very least, to rename the remotely removed file to <filename>.mine, similar to what a failed merge does. This way, the conflict stands out and the file no longer takes part in the build.
> 
> 
> Any thoughts on this, please?

I agree.  Although what happens when you resolve the conflict, suppose 
you resolve using "mine", does the file's status become added / 
replaced?  Presumably if you resolve using "theirs" then the file is 
deleted, but there must be also a third option to "keep" the file 
unversioned.

If not a conflict then I think there should at least be a warning when 
this happens.  The closest thing I've seen to a warning about this 
situation is that if a file is locally modified and remotely deleted, 
TortoiseSVN will report status info about it in red (which is the colour 
they use for conflicts).

Then there is the question of how to handle directories, presumably the 
same can be done?  I'm not sure about the renaming to .mine though...

> 
> 
> Regards,
> Peter
> 
> 
> 
> 
> 
>       ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org