Splitting out core and bindings final stages

[Rob Taylor]

John (J5) Palmieri wrote:
> On Sat, 2006-05-06 at 16:46 +0100, Rob Taylor wrote:
>> John (J5) Palmieri wrote:
>>> On Fri, 2006-05-05 at 18:06 +1000, Brad Hards wrote:
>>>> On Friday 05 May 2006 09:17 am, John (J5) Palmieri wrote:
>>>>> NOTE: for the time being the dbus core libraries will continue to be
>>>>> worked on in CVS and the bindings in git once the move happens.  The
>>>>> core, along with its history will also be in git and if we ever decide
>>>>> to move it we can import again from CVS and not duplicate the history.
>>>> Where / when was the decision to move to git made?
>>>>
>>>> Brad
>>> On the dbus irc channel.  Remember the move is only for the bindings
>>> right now and not core.
>>>
>>
>> I should say that the consensus for git isn't absolute 
> 
> I was pretty strong.  In fact if I remember correctly the sentiments
> were (paraphrasing) "anything but SVN" and "git looks like the best
> choice".  

IIRC, we definitely decided on a distributed RCS. I still think its best
to evaluate the options before jumping ship.

>> - One worry I
>> have is that it doesn't work on windows. 
> 
> Except that it does, Cairo devs has been using it since they switched.

Hmm, yes, it seems that I'm mistaken, but it's not without its problems:
http://marc.theaimsgroup.com/?l=git&m=114131099531633

>> I like the idea of using a
>> distributed RCS, but probably bzr would be better for a cross platform
>> library like this. Dafydd Harries is currently having a look at the
>> feasibility of importing and syncing dbus cvs with bzr, so I'll report
>> back on that when he has some results.
> 
> Yay, yet another tool for fd.o admins to look after.  I'm half tempted
> to just replay the git split back into CVS to avoid the controversy that
> this is going to cause.

We've often discussed putting bzr on fd.o. I don't think its a huge
issue and I really don't see any controversy in evaluating our options.

Do remember that Robert McQueen is now also an fd.o admin.

> Carl already went through this and wrote up a nice why git when he went
> through the cairo change
> (http://lists.freedesktop.org/archives/cairo/2006-February/006255.html).
>
> The main points are 
> 
> A) It really doesn't matter which distributed VCS we use because they
> all basically work the same and if at one point one tool turns out to be
> the winner it is easy to go from one to the other
> 
> B) git's layered approach makes it very easy to make it do what you
> want.  I can attest to this fact being that splitting out the repository
> was easier than I thought.
> 
> Also Carl's knowledge with respect to git is nothing to sneeze at.
> Having him as a resource at fd.o is invaluable.  What it comes down to
> is the tide is moving towards git at fd.o.  The general consensus of the
> active d-bus devs was to go to a distributed system (Havoc being the one
> holdout which does hold a lot of weight, but you said you wouldn't be a
> blocker ;-).  I saw no point in going against the tide since the
> advantages of sticking with what the rest of fd.o is doing (with the
> free resources that affords us) far outweighs the differences between
> git, bzr and mercurial.

It's certainly valuable to have expertise in a system to consult! As far
as bzr goes, Dafydd Harries has a lot of experience in it, being an
ex-Canonical employee. Canonical has been using bzr for all their source
code management for quite a long time now, and everything I've heard
from those using it has been good.

You should note that Carl didn't really evaluate bzr in the above post...

> Already the d-bus developers are stretched thin in terms of time
> allotted to developing for it.  My goal and in fact my job as the
> defacto maintainer is to move us forward to a stable 1.0.  If we are
> going to block on this I'm serious about being just as well with
> sticking with CVS.

How bad a block is a few days of evaluating our options? Once we switch
we'll be stuck with our choice, so I would certainly hope we choose one
that's most developer-time efficient going forward. We certainly don't
want to add more work to our stretched roles already ;)

I would suggest that we get both bzr and git repos set up and try them
both out before jumping ship in any direction.

Thanks,
Rob Taylor