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

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?)

* 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").

I would like to convert this case to a tree conflict. Is there any serious
benefit to not doing so, and keeping this special case?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-18 12:05:29 CEST