[ECOS] eCos submodule support

[Ãyvind Harboe <oyvind dot harboe at zylin dot com>]

I've been tinkering w/git submodules and it really is
a killer feature for the typical eCos application we
work on:

- we'll clone eCos repository and keep a modified
version of that repository on our servers. Here we
track various modifications in eCos until those
modifications eventually make it back into the official
eCos tree, or for those modifications that never should
be made part of the main tree we keep it on our
servers. This eCos repository is shared between
clients/projects.

- we'll clone the eCos repository onto *our* server in-house,
yielding super fast checkout times. (git submodule update).
This also does not waste bandwidth of official servers.

- git submodules are also used for other eCos repositories
that e.g. keep a specific HAL or some other feature.

- this also works fine w/projects that use svn as a server,
e.g. libmicrohttpd which is a module we use, but it's
not actually an eCos project.

- when various people work on the same project, we don't
have to write scripts to set up the build environment(e.g.
extract a specific version of eCos snapshot). It's
clone + submodule init + submodule update => voila!

At this point I have no idea what happens when
throwing mercurial into the mix here, but "easy"
isn't the first word that comes to mind :-)

When choosing DVCS I hope that non-trivial operations
are considered more than trivial ones.

Trivial operations, like cloning, is trivial with git & mercurial
both.

For the most trivial operations downloading and
untarring is probably the way to go rather than introducing
version control at all.




--
Ãyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss