[Dart] anyone using Mercurial or Darcs?

[Brandon Van Every]

On 7/18/07, Blezek, Daniel J (GE, Research) <blezek at crd.ge.com> wrote:
>
> 1)  GE tends to use ClearCase for all our revision control (opposite
> extreme from hg).  One of the main problems is merging code into the
> baseline.  API's change, code gets fixed twice, etc.  Does hg suffer
> from the same problem?  I know you've mentioned that branches and merges
> are easy, but are they a good thing?  In our CVS/SVN world we tend not
> to branch at all, as everyone knows "branches are evil!".

That value judgment needs some unpacking.  In the centralized version
control world, I believe that statement means:

1) it would introduce substantial administrative overhead to the
version control system to deal with it.

2) it would destabilize the source pool because we don't trust various
people's patches, nor can we test all the permutations.

(1) simply does not exist in the distributed version control world.
Branches, patches, and merges are trivial.  A branch is simply another
fully working repository, and the patch theory defines how they
differ.  (2) always exists in any project no matter what technology
you employ.  The answer to that is to work with better people.

> 2)  In SVN, we tend to have a long checkout cycle, because if you check
> features in without completing them, it breaks everyone else's build.
> What is the hg checkout-commit cycle like?  I would imagine that
> developers commit locally then push changes off to everyone else.

You don't check things out.  You're not taking a lock on someone
else's repository.  You pull the patches you're interested in.  You do
your work locally and commit your changes locally.  Then you push your
patches to someone else's repository.  They could set up an approval
process if they wanted to, to bless your patch.  In practice, on small
projects you don't need to.  People just keep pushing and pulling
things and the patch theory figures out what goes where.  You don't
need to do file level locking, there's no such thing.  A patch defines
a region of code that is changed.  You can have lotsa such regions in
the same file, and 10 different authors working on it simultaneously.
As long as they know not to get in each other's way with the code
they're actually changing, there are no problems.  It's up to your
team to decide what's semantically distinct, what things are
separable.  The way your program is arranged in files has nothing to
do with that.

Merge conflicts are possible.  Can't remember why they happen.  When
they do, you can resolve them same as in any other version control
system.  Things in conflict are demarcated; you can go in and pick the
lines of text you want applied.  Or there are commands to attempt to
resolve the conflict automagically.  I've never used those.  I've
rarely had merge conflicts either.  Mostly all the patches just slide
past each other.

> 2a) Do developers who rarely pull changes have problems?  It would seem
> you could merrily work in your own little world for a long time (harder
> to do in SVN)...

That's a political question.  Does the "official" repository change a
lot?  Do the changes majorly impact the whole system, or are they
minor bugfixes?  Do you *want* to get swept along by someone else's
changes?  It's trivial to analyze the patch differences between 2
repositories.  You can just choose not to incorporate various patches
that people have thrown into a repository.

Not so trivial is whether the people making patches have good sense as
to how much they do at once.  Myself, if something is semantically
distinct, like a specific bugfix, then I make it a separate patch.  I
try not to do 3 things at once, although sometimes that happens.
Often I will check in the changes as distinct entities, rather than
mash them altogether, even though that's a little more work on my
part.  Just in case I've done 2 things that are completely trivial and
non-problematic, and 1 that causes things to explode.  That way, if I
have to "back out" of the bad patch, I've still done the other 2
things and I don't have to redo them.  In fact, a typical approach to
dealing with a big problem, is to dance around it for a bit, fixing
all the little problems, so there's less to contend with when you
sweep in for the kill.

The kind of person you don't want to work with, is the one who sits in
his own little sandbox, makes dozens and dozens and dozens of changes
locally, then pushes them all as one monolithic patch with a comment
like "compatibility fixes."  Jerk!  Patches are only as granular as an
author makes them.

> 3)  How do new developers get changes?  Do you have a master list of
> developers that are willing to coordinate updates?  Do you need to start
> building a network of friends? 8)

Anyone can pull from an "official" repository, if you want to set it
up that way.  This is the repository that presumably you're doing all
the QA testing on, analogous to the HEAD in cvs.

To push to a repository, you grant people permissions via ssh public
key encryption.  In Chicken-land, people who have "push" access to the
official repository have access to everything.  It's a small project
and we don't have systemic trust issues.  There are ways to allocate
trust at a finer grain if you want.

Technologically, there's nothing special about an "official"
repository.  It's just your political decision that *that* repository
will have the QA done on it, and has lists of people with various
amounts of permission to push to it.

Yes if you want to get anything meaningful done in open source, you'd
better have friends.

> 4)  How do you manage a release?  Is someone in charge of the release,
> and coordinates all the changes that go into the release (effectively
> becoming a central repository)?

Again, this is a political decision.  In Chicken-land we have a CMake
script that creates a tarball from a repository.  We have a file that
contains a version number in the source tree.  When Felix feels like
bumping up the version number, he does so.  When he wants to make a
tarball release, he does.

> 5)  One of the central ideas in Dart is that everyone tests the same
> code each night (to ensure cross-platform code).  Since the machines are
> developer-donated, how would we ensure the same code is run everywhere?
> Perhaps it doesn't matter?!?

I guess you'd compare the repositories.  If the result of all patch
applications is an identical repository, then you're testing the same
things.  If the results difffer, then you could compute and offer a
patch that transits one repository to another.  Or offer a log of the
merge conflict if that is not possible.  That's getting fancy though.
A simple "yes they are the same, no they are not" is fine for
starters.  Whether you want to know about people claiming to have a
repository of your code, but that differs in various ways, is a
political question.  Most devs would call that noise, but it might be
a practical way to detect bugfixes, or people becoming disenchanted
with your project.

> hg sounds interesting, but I'm not sure I can wrap my head around it.
> Perhaps we need to start a sandbox project or two.

At a user level, you just pull, edit, record, and push.  It's not
complicated.  It's painfully simple and un-cumbersome.


Cheers,
Brandon Van Every