[Dart] anyone using Mercurial or Darcs?

[Blezek, Daniel J (GE, Research)]

Hi Brandon,

  Even though this isn't a Mercurial list, I'm curious about this.  A
couple of years ago I insisted that Dart and Slicer3 at least try out
SVN.  It turned out to be a good choice, far better than CVS.  Can you
answer a few questions?  They would also help me to figure out how we
might support distributed CMS's that don't have the concept of a HEAD.

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!".

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.

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)...

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)

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)?

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?!?

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.

BTW: I didn't do the Perforce work.  Must have been Kitware.

Best,
-dan

-----Original Message-----
From: dart-bounces+blezek=crd.ge.com at public.kitware.com
[mailto:dart-bounces+blezek=crd.ge.com at public.kitware.com] On Behalf Of
Brandon Van Every
Sent: Wednesday, July 18, 2007 12:45 PM
To: dart at public.kitware.com
Subject: Re: [Dart] anyone using Mercurial or Darcs?

On 7/18/07, Mathieu Malaterre <mathieu.malaterre at gmail.com> wrote:
> [Taking if of list for now]
>
> > Every repository is a fully working repository.  If there's 1 
> > repository that a group is using as "the official" repository, that 
> > is by convention only.
>
> If you plan to use Dart, then yes you need to quickly define which one

> is the 'official' one.

I don't see why.  I assume that Dart can build multiple repositories on
the same machine.  3rd parties could run their own Dart servers if they
wanted to deal with the hassle of it.

> > You are limiting yourself to a centralized server mode of thinking.

> > I certainly wouldn't want to *test* everyone's private repositories,

> > but tracking the differences between them is trivial.
>
> don't understand. Why in the first place is there so many branches.

Whether there are or aren't is totally up to you.  If you want tons of
'em, you can have 'em.  Branching and merging are cheap.

> Isn't it only during a very short time that you have those local 
> mirrors ?

No, every user always has at least 1 local mirror.  Same as every
Subversion user has a Subversion client.  Otherwise nobody would be able
to do anything.  It's just that in distributed source, the local
repository is a fully working repository.  If they wanted to set it up
as a server, start pushing and pulling from that to other places, they
could.

> In the end if you have a bug fix you want everybody to have it...to 
> push it to everybody.

In principle, that's not essential.  A sufficiently large network of
users could just push and pull patches around at their whim.  You'd have
transmission delays of course.  Not everyone would see a given patch at
the same time.  It would depend totally on how often various parties
wanted to communicate with each other.

In practice, engineering teams do tend to centralize for QA purposes.
But when you look at open source, and people getting huffy about project
priorities, and code forks, you start to see the potential of the fully
distributed model.

>
> > Can't help you there.  Your notion of "good" is strange.  Do you 
> > have any experience with distributed version control at all?  If 
> > not, I
>
> no :) I was just trying to get some notions by comparing to something
I know.
>
> > suggest you suspend judgment until you've tried it.  Or you could 
> > look around for Mercurial and Darcs' major users and see what they 
> > have to say about it.
> > http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercuri
> > al http://wiki.darcs.net/DarcsWiki/ProjectsUsingDarcs
>
> That's the usual bs for upper manangement.

Whatever dude.  I told you about our experience with Chicken, and you'll
notice the 2nd user on the Mercurial list is Mozilla.  If you think
we're all a bunch of dummies then go make your own mistakes.  I can lead
you to water, I can't make you drink.  You've got lists of hundreds of
people you can ask why this is any good.

> From the top of my head KDE
> and gcc are using SVN and it does not add anything ...

What is SVN supposed to add?  As far as I know, it's a cleaned up CVS.
 Which is certainly reason enough to migrate from CVS, but it's nothing
startling.

> Anyway I guess I have grown up too long in the VTK/CMake/ITK/ParaView 
> extreme programing style, where only CVS HEAD is stable.
>
> But seriously I am really missing the point on why you would need a 
> revision system just for a short period of time. Or I guess do you 
> have any example of why maintaining a branch (how much work this is 
> vs. gain) ?

>From Mercurial's standpoint, it is 0 work to maintain a branch.  You
can have them for free, and they all work with each other.  That's the
advantage of a strong patch theory.  From a QA and political standpoint,
branches are as much or as little work as the people you're working with
and your project goals.


Cheers,
Brandon Van Every
_______________________________________________
Dart mailing list
Dart at public.kitware.com
http://public.kitware.com/mailman/listinfo/dart