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" <markphip@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
Received on Fri Aug 31 00:55:54 2007