From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21449 invoked by alias); 14 Oct 2009 13:20:50 -0000 Received: (qmail 21438 invoked by uid 22791); 14 Oct 2009 13:20:48 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Oct 2009 13:20:43 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E16232F7801F; Wed, 14 Oct 2009 14:20:40 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViAiFJTRgUgG; Wed, 14 Oct 2009 14:20:39 +0100 (BST) Message-ID: <4AD5D020.8050207@ecoscentric.com> Date: Wed, 14 Oct 2009 13:20:00 -0000 From: Alex Schuilenburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?w5h5dmluZCBIYXJib2U=?= CC: eCos Disuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Tracking eCos as a hg/git submodule X-SW-Source: 2009-10/txt/msg00088.txt.bz2 Øyvind Harboe wrote on 2009-10-14 12:37: > I'm reading up on git submodules and it looks like just the ticket > to handle a typical eCos application which is pulled together > from specific modified versions of multiple projects and > libraries, therein eCos. > > submodules importantly supports the concept of a modified eCos > repository for a project and a way to track and eventually pushing > those changes back up to the official eCos repository. > > Importantly such a modified eCos repository can be shared > amongst several applications. > > I would like to see that the choice of DVCS in eCos does not > put unnecessary stumbling blocks in the way working in this > fashion. > That rules out bzr then because AFAIK it does not currently support submodules. But then I pretty much have ruled out bzr for other reasons. However, while external developers may want to use submodules and indeed have eCos as a submodule as you suggest, I dont really see that much of a need for them within the public eCos repo myself - unless you really want to break down individual eCos packages into separate submodules but IMHO that is just taking things too far. > I'm sure mercurial supports submodules. > It does, as mentioned in a previous email sometime ago. > Mercurial can probably clone git repositories... http://hg-git.github.com/. > It does, as per my email a couple of days ago ;-) > Vice versa is probably also possible.... > http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#Mercurial > I would be surprised if git could not clone from git, although the tools you list there are conversion tools, not cross DRCS push/pull tools such as the hg-git hg plugin as above. The hg-git plugin allows you to treat a git repo as if it were an hg repo from hg. However, I would not be keen for git to be selected because of a feature it lacked (i.e. being able push/pull to/from an hg repo). As someone pushing for git, maybe you can give me an answer on this since I have not yet found a git equivalent. Does git allow changesets to follow copied files? i.e. if you copy file a to file b, and then modify b, but later someone finds a bug in a and fixes it, does git propogate the fix automatically to b? hg does this and IMHO it is a very useful feature since many device drivers and BSPs in ecos are clones of others. It would cover not only bugs, but changes in APIs and suchlike which means the risk of conflict would be small. So for example if a template device driver or API were provided in hg, updates to the template would be propogated automatically to copies making major API changes a lot easier. FAOD, I am trying to track down a genuine set of useful technical differences between git and hg to help the maintainers make their mind up. For example, git octopus merges have no current equivalent in hg, though somehow I don't see that git super-power user feature will have much, if any, use in eCos. However, changeset tracking copies of files IMHO is very useful. The other difference I have found is that git repos tend to grow in size and become inefficient if left unattended for long periods and require packing, while hg repos dont. I have ruled out speed as a technical measurement since IMHO the differences are negligible and can be ignored. -- Alex Schuilenburg Managing Director/CEO eCosCentric Limited www.ecoscentric.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss