On Wednesday 07 September 2005 18:55, Ben Collins-Sussman wrote:
> 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?!?"
I've definitely seen this problem creep up a number of times. Personally, I
think of it as a conflict too. There is clearly a breakdown somewhere if
someone else is trying to remove a file that I'm updating. This problem
occurs most often when restructuring our build environment, making these
changes more troublesome than they are already. :-(
>
> 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?)
This depends on whether you have an environment to do a local build. Sadly,
on some projects, we don't have that option. It requires special and costly
software, as well as dedicated equipment to execute. Besides that, it's not
like build systems know not build an unversioned file. It's entirely
possible that everything works on my machine, but won't on everyone
else's. :-)
> 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
I'm not sure that would really catch someone's attention either. One of the
patterns that I've noticed in our shop is that developers rely on 'svn st' to
bring out any issues. Lots of times, there is just too much noise with 'svn
up' to notice it in the output.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 8 01:53:03 2005