Re: Update problem: Tree conflicts vs content conflicts

On Sep 7, 2005, at 3:28 PM, Philip Martin wrote:
>
> I feel you are trying to be too novice-friendly at the expense of more
> convenient behaviour for experienced users.

Hm, perhaps. The common scenario that seems to keep popping up on
the users@ list is:

    * Not-so-clueful user edits 100 files

    * 'svn update' receives a bunch of changes, a few adds, a few
deletes. One of the deletions silently causes a locally-modified
file to become unversioned. User doesn't notice this.

    * User runs 'svn diff/status' (maybe), still doesn't notice one
of the edited files is missing from the list of changed files.

    * User runs 'svn commit', still doesn't notice one of the edited
files is missing.

    * Build (or run-time) breaks. User discovers one of his edited
files isn't in the repository.

    * User comes to mailing list, screams murder:

         "Subversion LOST my data!!!"
         "No it didn't, it's sitting right there in your working
copy, unversioned."
         "Well why the heck didn't it tell me? How was I supposed to
notice?!?"

So yeah, the person is a novice... perhaps a web developer
uncomfortable with version control being forced to use TortoiseSVN.
An "experienced" user would have tried to build and execute before
committing. An experienced user would have looked over the changed-
file list more closely.... (Though, would an experienced user notice
1 missing file out of 100?)

Still, it doesn't seem like a huge stretch to announce that a file is
becoming unversioned. Maybe we don't have to mark it as a conflict,
but rather print a warning during the update?

      U foo.c
      A bar.c
      D baz.c
           WARNING: baz.c has local edits, making file unversioned
      U bop.c
      U blort.h

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 8 00:56:23 2005