Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/14/2004 09:50:35
AM:
> On Oct 14, 2004, at 9:41 AM, Mark Phippard wrote:
> >
> > I just think that we cannot just wush away the conflict. The user
> > needs
> > to know that they have created a conflict and they should review the
> > files
> > before committing there change.
>
> I'm suggesting that the UI be something like this:
>
> $ svn update hijacked-file.c
> WARNING: you have changed this file without locking it, which is bad!
> WARNING: a newer version of the file has been saved in
> 'hijacked-file-backup.c'
> WARNING: please examine the newer file before committing your own
> changes!
>
> How is that "wushing away" the conflict? Isn't that enough information
> to make the user review the newer file?
>
> The alternative is:
>
> $ svn update hijacked-file.c
> C hijacked-file.c
>
> ### "huh? what does C mean?"
>
> $ svn ls
> hijacked-file.c
> hijacked-file.c.r4
> hijacked-file.c.r5
> hijacked-file.c.mine
>
> ### "huh? what are all these extra files?"
>
> $ svn commit hijacked-file.c
> svn: err: 'hijacked-file.c' remains in conflict.
>
> ### "huh? what does that mean?"
> ### calls administrator.
I want to respond in a couple of ways to this:
1) What you propose above, might be OK.
2) In your alternative, you are essentially just criticizing the current
svn behavior. Why not just combine the ideas and try to make this work
better for everyone and in all situations? To me that would be some
variation on your proposal, except that the conflict is marked and needs
to be resolved before a commit.
I have co-workers that are brilliant developers as well as just generally
intelligent people, and they do not understand this that well. They could
learn it if they had to, but we do not have a lot of conflicts so I just
help them when it happens. However, they are smart enough to understand
this themselves if it were just easier and more obvious.
I think the biggest problem with your current proposal is that the user
has to read and understand the warning. Requiring them to run a command,
at least means they have to take some action. So, going back through your
example:
> $ svn update hijacked-file.c
> C hijacked-file.c
>
> ### "huh? what does C mean?"
So, improve the messaging to something like what you had above.
> $ svn ls
> hijacked-file.c
> hijacked-file.c.r4
> hijacked-file.c.r5
> hijacked-file.c.mine
>
> ### "huh? what are all these extra files?"
This one is tougher, but perhaps improve the file names.
> $ svn commit hijacked-file.c
> svn: err: 'hijacked-file.c' remains in conflict.
>
> ### "huh? what does that mean?"
> ### calls administrator.
Again, improve the error message. At a minimum, it would seem like the
message ought to refer to svn resolve in some way. It could even be done
in a round about way like this:
svn: err: 'hijacked-file.c' remains in conflict. Mark the conflict
resolved before committing.
Seeing the word resolve, might be enough for an svn help to solve the
problem.
I am not suggesting that I have just "solved" this or even made it better.
I am just saying that a conflict is a conflict no matter how it happens.
We shouldn't not raise it just because we think the user might not
understand it. If this process is difficult, then lets just generally
make it better.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 16:05:32 2004