Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree conflicts)

Julian Foad wrote:
> Enlightenment sought from anybody who can help, on three questions:
>
>
> * Update is smarter than Merge w.r.t. tree changes
>
> "svn update" can detect whether the object in your WC that it's about to
> modify or delete is "the same object" that is the WC BASE object, and
> can raise a conflict if it is not (e.g. if it is locally scheduled for
> replacement).
>
> "svn merge" cannot do this, because it just applies a change to the
> target items that matches by pathname, without regard to its
> object-identity.
>
> This is by design. I just want to check that I understand correctly and
> that we're keeping this current definition of "merge". I assume we are
> not attempting to make "merge" use historical relationships between
> source and target to detect this sort of situation.
>
>
> * Update: permits adding a file already scheduled for add
> subversion/libsvn_wc/update_editor.c: add_file()
>
> /* When adding, there should be nothing with this name unless unversioned
> obstructions are permitted or the obstruction is scheduled for
> addition
> without history. */
>
> Why do we allow "update" to add a file that is locally scheduled for
> add-without-history? (And why not also add-with-history?)

The with/without history inconsistency seems odd. The behavior as it stands
today sounds like it would be useful in one somewhat common scenario:

   * you make local changes which include adding new files
   * send those changes to someone else as a patch
   * the other person applies and commits the patch
   * you update atop your still-modified working copy

But I'm not sure that one use-case justifies the risk of effectively having
your local addition automatically and silently transformed into a
potentially every-line-touching text mod (in the case where the file you've
added is nothing like the one someone else added).

> * Update: silently undeletes a deleted file
> subversion/libsvn_wc/update_editor.c: add_file()
>
> /* sussman sez: If we're trying to add a file that's already in
> `entries' (but not on disk), that's okay. It's probably because
> the user deleted the working version and ran 'svn up' as a means
> of getting the file back.
>
> This sounds like something we do only because CVS users got used to
> doing it. Normally, "update" only applies changes that have happened in
> the repository. It's presumptious to assume that the user didn't
> actually want the file to go away (but maybe just forgot to use "svn
> delete").

Nonsense. It's just as presumptuous to assume that just because a file has
gone missing from a working copy that the user intended to remove that item
from version control. We don't automatically add new files when unversioned
ones show up in a working copy tree, do we? Of course not. By the same
logic, we shouldn't remove files that go missing from disk either.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand