Re: Copy-on-Update Feature

[David Glasser <gl...@davidglasser.net>]

(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 <gs...@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" <su...@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 <gs...@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" <ma...@gmail.com>
> >> wrote:
> >>
> >>> On 8/30/07, Greg Stein <gs...@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@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

Re: Copy-on-Update Feature

[Mark Phippard <ma...@gmail.com>]

On 9/8/07, David Glasser <gl...@davidglasser.net> wrote:
> (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?

As I understand it from previous comments, right now nothing is
different.  He put some infrastructure code in place so that the code
can be made smarter and the API's it needs will be available.

When the code is in place and working, I think the deleted file should
be deleted.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

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