Splitting out core and bindings final stages
robtaylor at floopily.org
Sun May 7 16:17:59 PDT 2006
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?
>>> 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
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:
>> 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
> 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.
More information about the dbus