>>>>> "Jamie" == Jamie Webb <[EMAIL PROTECTED]> writes:
Jamie> On Tue, Nov 08, 2005 at 11:36:06AM +0900, Stephen
Jamie> J. Turnbull wrote:
Jamie> And of course the best approach is to communicate with the
Jamie> rest of the team and avoid the conflicts in the first place
Jamie> :-).
>> I think that's arguable. What's the point of an advanced
>> distributed SCM if you're going to insist that people serialize
>> their work to avoid conflicts?
Jamie> Because conflicts are the Enemy.
"The" Enemy? Conflicts are a PITA and spurious ones slow down work
unnecessarily. It's worthwhile to invest in systems to reduce them,
but it is preferable to have the computer do the work rather than have
humans waiting on each other. Developers should talk to each other,
but about design and defects and fixing. Scutwork and waiting is for
the machines.
If conflicts get elevated to the level of "the" enemy, something's wrong.
Jamie> Darcs gets to call itself 'advanced' precisely because it's
Jamie> better at avoiding conflicts than any onther SCM, due to
Jamie> the patch theory. But once they do occur, it fares no
Jamie> better than CVS (worse, in fact).
That's sad, but it agrees with my own experience. It's the main
reason why I can't recommend darcs to my colleagues yet. Darcs is
wonderful, but I'm not willing to try to completely revolutionize our
workflow. And I have reason to believe that even if we reorganize to
take advantage of Darcs's strong points, we'll still see lots of
conflicts and exponential behavior in merges.
Jamie> So, if a little bit of chat can reduce them further, I
Jamie> think it must be a good thing.
I agree. A little bit of chat goes a long way. But your original
statement was much stronger.
Jamie> It doesn't need to be anything so extreme as re-inventing
Jamie> file checkouts; we've pretty much eliminated conflicts just
Jamie> by maintaining a general idea of what other people are up
Jamie> to.
I doubt you have a Disruptive Genius type working on your project,
then. A "general idea" of what a guy is working on, when he can
produce 100K lines of diffs in three months at an average level of
quality higher than the existing code base, is simply not good enough.
You know you're going to get shelled, you need to know exactly where
the bombs are going to land to sidestep them. I really don't want to
slow him down[1], but I also want other people to be able to get work
done, too.
I don't ask a revision control system to deal with that automagically.
I do want it to deal with conflicts more gracefully than either darcs
or CVS do, because I expect there will be many.
Jamie> Certainly that's easier with a team largely based in a
Jamie> single office, but it doesn't seem impossible to do with
Jamie> distributed projects.
First Principle of Herding Cats: Put the cats in a box, then herd the
box.
It's not impossible to do with distributed projects, but it's harder.
I bet your "general idea" also includes looking at code on colleague's
terminals and stuff like that---at least, every time I'm in the same
room with one of mine, we do some work Zaphod Beeblebrox-style (two
heads, two hands). Often the work itself is trivial (typo fixing,
even), but you do see what files and functions the guy is working on.
This is social and fun! Such implicit communication needs to be made
explicit in a distributed context. That is just tedious!
And to the extent that the project takes a lot of small contributions
from volunteers, it becomes nearly impossible, because they don't
punch the time clock at all.
As I wrote above, I agree---talk is good, a little bit goes a long
way, too. But it's not a panacea, and in my context a lot of work is
still required to adapt us to Darcs, and (I hope) Darcs to us
(specifically, I have hopes for the new work on conflictors, plus I'm
studying Haskell :-).
Footnotes:
[1] Some of my colleagues have proposed exactly that. "Just slow
down; if you don't voluntarily, we'll do it for you."
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
