This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eCos submodule support


Ãyvind Harboe wrote:
> I've been tinkering w/git submodules and it really is
> a killer feature for the typical eCos application we
> work on:
>   
hg is no different from git in this regard.

> - 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 :-)
>   
Then why are you using git?  Everything you describe above regarding
interoperability of DRCS with other RCS systems says you should be using
hg.  hg not only plays nicely with all the major RCS, distributed and
centralised, but because git does not, hg has a git interface that not
only allows it to push/pull to git repos, but also makes it look like a
git repo.  Don't believe me? Then go to:
http://mercurial.selenic.com/wiki/HgGit#Using_hg-git_to_interact_with_a_hg_repository_with_git

The more you talk about your requirements, the more convinced I am that
not only eCos should use hg, but you should as well.

> When choosing DVCS I hope that non-trivial operations
> are considered more than trivial ones.
>   
Such as? There is very little difference between hg and git as has been
said time and time again, and not only on this list...

> 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.
>
>   
Eh?  How do you figure that?  Working in a distributed environment with
as many different RCS versions as you claim, updating on a weekly basis
should not require you to download the whole 22MB of eCos every time or
any other RCS (distributed or otherwise), especially if you just want to
see what has changed.  If git is reducing you to downloading tarballs
for the simplest of operations, then you are either not using it
properly or are using the wrong tool.

hg provides incremental updates from CVS, svn, etc, as well as allowing
two-way operations between git, bzr etc.  In fact hg IMHO provides the
widest and strongest RCS interoperability features of all the DRCS
options on the table here.  From what I have seen, most git users are
just so  arrogant that they think everyone should be using git,
regardless of  an individual's actual requirements, so there is no need
to play nicely in the pool that is open source. Everyone should play
nicely with them.  hg-git is a good example that the hg team recognises
that everyone has their own requirements and is entitled to their own
choice, rather than having git rammed down your throat.  So if you want
to use git instead of hg, sure, hg will play nicely.

And if you think that if you have to use git to do Linux development,
think again.  The Linux-HA projects uses hg.  So do a whole host of
other open source projects with more complex requirements than you have
shown. I am *not* saying that git could not do a good job as well, but
when you investigate why each of these projects chose hg over git and
all the other options, the same old recurring theme comes to the fore
time and time again. Simplicity, ease of use, documentation, and "it
just works".

Here are some examples:

Open Office:
  http://blogs.sun.com/GullFOSS/entry/openoffice_org_development_switches_to
FireFox:
  http://hg.mozilla.org/mozilla-central/
Google Code:
  http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html
Python:
  http://mail.python.org/pipermail/python-dev/2009-March/087931.html
Linux-HA:
  http://hg.linux-ha.org/
NetBeans:
  http://wiki.netbeans.org/HgHowTos
OpenSolaris:
  http://opensolaris.org/
XEmacs:
  http://www.xemacs.org/
XEN:
  http://xenbits.xensource.com/

For a bigger list, see http://mercurial.selenic.com/wiki/ProjectsUsingMercurial 

-- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]