Re: [cdv-devel] more merging stuff (bit long...)

Kevin Smith wrote:

> Bram Cohen wrote:
> >
> > Specifically, in this case:
> >
> > a
> > |\
> > b \
> > |  \
> > a   c
> >
> > The result should be c, since the b is toasted by a revision to a.
>
> As I said, I'm not an experienced merger, but based on my own experience
> and biases, I don't think that should be a clean merge. Or, more
> precisely, I would like to have some kind of option as to whether the
> system would treat that as a clean merge or not.

The experience of people using codeville has been interesting. Some people
(like, umm, me) never manage to hit any edge conditions, ever. These are
people with extremely good code discipline and straightforward development
styles, and are absolutely terrible at shaking out a version control
system, because they never do anything to really test it. Version control
developers tend to be particularly bad, because they tend to be very
careful planning sorts, and frequently think about what their operations
will make the underlying system do, and avoid ones which will strain it.

Then we have another developer (who's completely representative of an
entire class, but is the only one of the handful of people using codeville
for work who is like this). He's quite a good and productive as a coder,
but his code discipline is a lot looser. He's found most of the major
gotchas in codeville, and is the only one to complain regularly about
behavior he doesn't like. It's important to note that the behavior of this
developer while using codeville is *completely reasonable*. He's using the
tool as advertised, with perfectly typical expectations, and sometimes it
acts quirky. He usually doesn't even realize when he's trod on edge
condition territory. He just sends over the history and indicates what
behavior he didn't like.

One of this developer's behaviors is that he'll add a diagnostic
statement, do some development, then delete the diagnostic statement.
He'll similarly do little experiments in various parts of his work, then
revert them manually if he doesn't like them. This plays havoc with the
version control system, because he isn't carefully pulling experiments
from their own branches, so there's no simple way to tweeze them out. But
he is good at manually reverting them if there are problems, so in his
very solo developer model of what's going on in the code, everything is
fixed.

Sometimes, of course, someone else edits a section of code which has been
manually reverted, and we get an unnecessary conflict. Implicit undo is
correct behavior if you are a developer like this or you're on a team
which includes a single developer like this, because their reversions
might conflict with your new development.

I, for one, am unlikely to ever have done an implicit undo, because I try
subconciously to avoid abusing the version control system, and I would
simply assume that implicit undo didn't work properly with any system
unless explicitly told otherwise, and would want to test it myself first
before trusting that such functionality worked at all.

> Perhaps, but I think I would rather it remain explicit, at least for my
> own work. Thus, I question whether "implicit undo" should be the default
> behavior, and even more so whether it should be the only behavior.

Perhaps it could warn you when it's doing an implicit clean merge. I
haven't thought about how to do that though, and honestly its output is
unlikely to be very interesting.

> As I looked through each of your later examples, I didn't see one case
> where implicit undo would clearly benefit me, and several cases where it
> could hurt.

If you could go over the post and point out which examples you dislike,
that would be helpful.

> Perhaps in a perfect world, where all the tools were integrated, the
> graphical merge utility could indicate "implicit undo" conflicts
> differently than other conflicts, offering an easy way for the user to
> take the "recommended" resolution.
>
> Maybe I'm way off base due to inexperience.
>
> Kevin
>