You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2007/08/30 13:59:00 UTC
Copy-on-Update Feature
Ben,
We (Dan, Mike and myself) were discussing this feature yesterday and
there are some differing thoughts on what you are attempting to do.
When we get clarity, we should probably update your notes file.
Your notes file states this as the problem to solve:
When 'svn up' receives a copy or move (copy+delete), the existing
locally-edited file should be copied (wc -> wc). (The status quo is
to just delete (unversion) the edited file and add a wholly new file
-- which greatly angers users.)
Where your notes file gets confusing is about whether you only plan to
"solve this problem" in certain situations, or always. Based on IRC
conversations, I maintain that you intend to always solve the problem.
This is my recollection:
There are two scenarios to solve:
1) User has local edits in a file. In this scenario, Subversion
never removes the file from disk, it just makes it unversioned. So
even in the scenario where Subversion deletes the file, before sending
the copy, the local file is still going to be on disk and you should
still be able to find it to copy it. Situations where you cannot
ought to be fairly rare, error conditions.
2) User has made edits on a branch. Merge moves the file, causing
the edits on the branch to be lost. Your notes file does not
specifically talk about this scenario, but I assume it is just a
variant of the same scenario. In this case, if the local file is
available we copy it, if it is not available, we have the information
we need to copy it from the server. Meaning, the branch version of
the file is first copied to the new location, and then text deltas are
applied.
I guess now that I have written this out, your doc really only talks
about svn up, and scenario 2 only applies to merge. So maybe you do
not intend to solve this one?
--
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
Re: Copy-on-Update Feature
Posted by Ben Collins-Sussman <su...@gmail.com>.
On 8/30/07, Mark Phippard <ma...@gmail.com> wrote:
> 1) User has local edits in a file. In this scenario, Subversion
> never removes the file from disk, it just makes it unversioned. So
> even in the scenario where Subversion deletes the file, before sending
> the copy, the local file is still going to be on disk and you should
> still be able to find it to copy it. Situations where you cannot
> ought to be fairly rare, error conditions.
Correct.
>
> 2) User has made edits on a branch. Merge moves the file, causing
> the edits on the branch to be lost. Your notes file does not
> specifically talk about this scenario, but I assume it is just a
> variant of the same scenario. In this case, if the local file is
> available we copy it, if it is not available, we have the information
> we need to copy it from the server. Meaning, the branch version of
> the file is first copied to the new location, and then text deltas are
> applied.
Right, this is about merging, whereas the first scenario is about updating.
I *do* intend to solve the problem for both updates and merges, but
they're different codepaths. I'm only working on updates at the
moment -- which mainly involve making the libsvn_wc 'update editor'
vtable smarter about handling copyfrom-data coming from the server.
When it comes to solving the problem for merges, we need to make the
merging-vtable "smart" in the same way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Copy-on-Update Feature
Posted by 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
Re: Copy-on-Update Feature
Posted by 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
Posted by Karl Fogel <kf...@red-bean.com>.
Greg Stein <gs...@gmail.com> writes:
> 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.
When a file "moves", I don't consider as no longer existing, I just
consider it existing in a different location. I'd want my edits
preserved, and the same textual conflict behavior we have today.
We're not talking about deletes at all here, only copies (which at the
moment includes renames, although someday if renames are done
differently, I still don't think they should conflict with text mods).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Copy-on-Update Feature
Posted by Greg Stein <gs...@gmail.com>.
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
Re: Copy-on-Update Feature
Posted by Ben Collins-Sussman <su...@gmail.com>.
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
Re: Copy-on-Update Feature
Posted by Greg Stein <gs...@gmail.com>.
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
Re: Copy-on-Update Feature
Posted by Mark Phippard <ma...@gmail.com>.
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
Re: Copy-on-Update Feature
Posted by Greg Stein <gs...@gmail.com>.
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'
On Aug 30, 2007, at 6:59 AM, "Mark Phippard" <ma...@gmail.com> wrote:
> Ben,
>
> We (Dan, Mike and myself) were discussing this feature yesterday and
> there are some differing thoughts on what you are attempting to do.
> When we get clarity, we should probably update your notes file.
>
> Your notes file states this as the problem to solve:
>
> When 'svn up' receives a copy or move (copy+delete), the existing
> locally-edited file should be copied (wc -> wc). (The status quo is
> to just delete (unversion) the edited file and add a wholly new file
> -- which greatly angers users.)
>
> Where your notes file gets confusing is about whether you only plan to
> "solve this problem" in certain situations, or always. Based on IRC
> conversations, I maintain that you intend to always solve the problem.
> This is my recollection:
>
> There are two scenarios to solve:
>
> 1) User has local edits in a file. In this scenario, Subversion
> never removes the file from disk, it just makes it unversioned. So
> even in the scenario where Subversion deletes the file, before sending
> the copy, the local file is still going to be on disk and you should
> still be able to find it to copy it. Situations where you cannot
> ought to be fairly rare, error conditions.
>
> 2) User has made edits on a branch. Merge moves the file, causing
> the edits on the branch to be lost. Your notes file does not
> specifically talk about this scenario, but I assume it is just a
> variant of the same scenario. In this case, if the local file is
> available we copy it, if it is not available, we have the information
> we need to copy it from the server. Meaning, the branch version of
> the file is first copied to the new location, and then text deltas are
> applied.
>
> I guess now that I have written this out, your doc really only talks
> about svn up, and scenario 2 only applies to merge. So maybe you do
> not intend to solve this one?
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org