I see it as "I'm trying to edit <this> file" and "that file no longer
exists (due to move/delete)". That's a conflict in my book.
On Aug 30, 2007, at 6:07 PM, "Ben Collins-Sussman" <sussman@gmail.com>
wrote:
> By that argument, if 'svn update' tries to merge changes into your
> locally-edited file and finds that they're non-conflicting, it could
> also be bad to just 'suddenly and quietly' insert those changes into
> your file, right? We should always mark the file conflicted in that
> scenario, even if there are no conflict markers?
>
> Or, if you think it's fine to quietly merge non-conflicting changes
> into a locally-edited file, then I think "moving the file" qualifies
> as a non-conflicting change too. It's just a different sort of
> non-conflicting change coming from the server.
>
> And it shouldn't be a quiet unnoticed thing either way; just as the
> update prints 'G file' in the first case, it would also print
> something about moving the file in the second case.
>
>
> On 8/30/07, Greg Stein <gstein@gmail.com> wrote:
>> You might be editing the file in the original location for a specific
>> reason. Having it suddenly and quietly move could be bad. Deleting/
>> moving is not "just another edit to merge."
>>
>> On Aug 30, 2007, at 4:09 PM, "Mark Phippard" <markphip@gmail.com>
>> wrote:
>>
>>> On 8/30/07, Greg Stein <gstein@gmail.com> wrote:
>>>> IMO, mark the file as a conflict, leaving behind the appropriate
>>>> bits
>>>> for the user to see the original and their edits. The user then has
>>>> to
>>>> explicitly recognize the problem and run 'svn resolved'
>>>
>>> Why mark the file as conflicts if you can do better? IMO, in the
>>> case
>>> of update, it would work about the same as it would if the file did
>>> not move. If it could contextually merge the incoming changes it
>>> will, if not it will product a conflict.
>>>
>>> The difference here is that today we do neither. Your local edits
>>> become unversioned and the new files comes in as the normal state.
>>>
>>> Mark
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 31 03:23:24 2007