[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Copy-on-Update Feature

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-09-08 21:18:48 CEST

(Working my way through the dev@ backlog...) To clarify, Ben, the
changes you're making now don't actually change what we do with the
*deleted* file (other than doing some extra book-keeping); rather,
they change what the contents of the *new* file are, right?

--dave

On 8/30/07, Greg Stein <gstein@gmail.com> wrote:
> 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
>
>

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 8 21:15:28 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.