Re: [ECOS] Tracking eCos as a hg/git submodule

[Alex Schuilenburg <alexs at ecoscentric dot com>]

Ã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