On 9/7/05, John Szakmeister <john@szakmeister.net> wrote:
> 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.
>
I agree it's easy for a warning like that to fly past. Why not put it
in a state of
conflict and if it is a tree conflict use the filenames to indicate
the conflict state.
For example if I had deleted a file in my wc and updated to get a new version.
I would have:
<file> - Not there since that is the proposed resolution
file.mine-deleted - tag indicates the tree change (empty file)
file.r102 - prev rev
file.r103 - new rev
and so forth.
If you wanted it to stay deleted, then you just svn resolve the file.
Any thoughts?
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 8 02:32:22 2005