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:04:43 2007