[ECOS] eCos submodule support

[ECOS] eCos submodule support

[Øyvind Harboe]

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

[ECOS] Re: eCos submodule support

[Daniel Néri]

Øyvind Harboe <oyvind.harboe@zylin.com> writes:

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

With hg it's just "clone" and the subrepos are automagically pulled and
updated. How is that harder?


Regards,
Daniel


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

[ECOS] Re: eCos submodule support

[Øyvind Harboe]

To be a bit more clear:

My assumption is that there is no appreciable difference
between hg/git for the case when *all* modules are
either git/hg.

The problem is with heterogeneous projects.

When working with eCos I've only ever encountered
git, cvs and svn as version controls. CVS very rarely
these days. I'm sure there are eCos relevant projects
that use hg, I just haven't encountered them.

Managing svn as a submodule in git is easy enough.

I have never tried to manage hg as a submodule in git.

So, eCos choosing "the other DVCS" would
make my life harder even if that "other DVCS" is
better.

Does anyone have experience managing non-trivial
hg projects as git submodules?

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

Re: [ECOS] eCos submodule support

[Alex Schuilenburg]

Ø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

[ECOS] Re: eCos submodule support

[Sergei Organov]

Øyvind Harboe <oyvind.harboe@zylin.com> writes:
> To be a bit more clear:
>
> My assumption is that there is no appreciable difference
> between hg/git for the case when *all* modules are
> either git/hg.
>
> The problem is with heterogeneous projects.
>
> When working with eCos I've only ever encountered
> git, cvs and svn as version controls. CVS very rarely
> these days. I'm sure there are eCos relevant projects
> that use hg, I just haven't encountered them.
>
> Managing svn as a submodule in git is easy enough.
>
> I have never tried to manage hg as a submodule in git.

Probably the best bet is to keep your own git repository of eCos
(automatically and incrementally) converted from the official hg one,
then use those git repo as a submodule in your project utilizing git.

-- Sergei.


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

Re: [ECOS] eCos submodule support

[Øyvind Harboe]

On Tue, Oct 20, 2009 at 4:37 PM, Alex Schuilenburg
<alexs@ecoscentric.com> wrote:
> Ø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.

Precisely.

> Then why are you using git?

Because, @ work, I have to learn and understand it, as the projects
that I work & interact with use it. That hg is "better" doesn't mean that
much.

I have other projects I work on where e.g. git submodules are used
extensively. There just isn't any way around learning about git in detail.
hg I could potentially not learn, so far.

At home I might have preferred hg.

I've very glad to see that hg provides a good interface to git according
to your description. I haven't tried it yet though. I'd love to hear about it
if someone has taken it for a spin against the eCos hg test repository.



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

Re: [ECOS] eCos submodule support

[Alex Schuilenburg]

Øyvind Harboe wrote:
>> Then why are you using git?
>>     
>
> Because, @ work, I have to learn and understand it, as the projects
> that I work & interact with use it. That hg is "better" doesn't mean that
> much.
>
> I have other projects I work on where e.g. git submodules are used
> extensively. There just isn't any way around learning about git in detail.
> hg I could potentially not learn, so far.
>   
Is it the git application or git format of repos that is mandated, or
both?  Because if your work also mandates you to work with other format
repos, or sources in other formats, I would use whatever application
could interact with them all the best, whether that was git, hg or
whatever.  If the git application is unable to interface with all of
them, then that surely is a reason why I would use something that could
(NB. I am not talking about switching repo format, just the tool that
interacts with them).  Just the same for hg - if hg could not do some
operation I could do with git, I would use git.

I kinda just see git and hg as tools that interact with repos, just as
vim and emacs are editors that allow you to develop code.  The
underlying language of the source is the same, just the tool used to
develop the source different and which one I use depends on what the
requirements are of what I am developing.  e.g. I might use vim to do
merges, but emacs to do builds.

Anyway, it seems that you are more reluctant in having to learn to use a
different tool and would rather put up with the issues in the tools you
know and feel most comfortable with.  And there is nothing wrong with
that.  Whatever gets the job done quickest sometimes is all that is
required.

But if I felt always that way, I might never have switched away from CVS
and converted our own internal repo or the eCos CVS repo. In the long
run I have no doubt that the effort in learning another RCS tool and the
effort in breaking away from CVS, a tool I was comfortable using and
whose foibles I understood, would be worthwhile and will save me stress
and time.

And is already already has.  It took me just under over an hour to
upgrade the ecos bugzilla from 3.0.4 to 3.4.2 using hg, excluding the
bugzilla facelift. And most of that time was spent removing own
improvements that clashed with the same improvements made by bugzilla. 
e.g. removing email addresses from public viewing of bugs, which is now
a feature of bugzilla.  And FWIW, this was all done on XP (shock,
horror!!!) - I wanted to taste my own medicine to see exactly how easy
hg merge work was on Windows.  And I am pleased to report it was easy. 
TortoiseHg on Windows is really neat!

> At home I might have preferred hg.
>
> I've very glad to see that hg provides a good interface to git according
> to your description. I haven't tried it yet though. I'd love to hear about it
> if someone has taken it for a spin against the eCos hg test repository.
>   
Me too! 

Of course it would also be upto the maintainers if they wanted to
provide two interfaces to the same repo on sourceware, but from what I
undertsand, this would also require an upgrade to the version of hg
running on sourceware.  At least hg offers that option.

But then there really also is not much need since you can always run
your own hg-git server locally if you were required or preferred to use git.

Open source - is it not great?

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

Re: [ECOS] eCos submodule support

[Øyvind Harboe]

> Is it the git application or git format of repos that is mandated, or
> both?

It's the git skills. I have to, eventually, become fluent in them.

It's not a matter of choice.



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

Re: [ECOS] Re: eCos submodule support

[Alex Schuilenburg]

Sergei Organov wrote:
> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
>   
>> To be a bit more clear:
>>
>> My assumption is that there is no appreciable difference
>> between hg/git for the case when *all* modules are
>> either git/hg.
>>
>> The problem is with heterogeneous projects.
>>
>> When working with eCos I've only ever encountered
>> git, cvs and svn as version controls. CVS very rarely
>> these days. I'm sure there are eCos relevant projects
>> that use hg, I just haven't encountered them.
>>
>> Managing svn as a submodule in git is easy enough.
>>
>> I have never tried to manage hg as a submodule in git.
>>     
>
> Probably the best bet is to keep your own git repository of eCos
> (automatically and incrementally) converted from the official hg one,
> then use those git repo as a submodule in your project utilizing git.
>   
Or even better, a local hg repository providing a git interface. That
way you could locally push changes upstream from the local hg repo
(since I dont know if git can push to hg) as if it were a git repo, you
would need upstream shell access to the remote hg repo to pull from your
local git repo (since hg can pull and push to git).  You could then
stick to using git locally as mandated by your company, and still
benefit from proper DRCS flow rather than a one-way downstream only flow.

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

Re: [ECOS] Re: eCos submodule support

[Alex Schuilenburg]

Øyvind Harboe wrote:
> [...]
> I have never tried to manage hg as a submodule in git.
>
> So, eCos choosing "the other DVCS" would
> make my life harder even if that "other DVCS" is
> better.
>   
I missed this bit :-/

I dont believe it will be harder - in fact I dont think it will make any
difference if hg were chosen because hg plays nicely with git.  More
like the other way round - if git were chosen it would make proper use
of a DRCS harder on the majority of the eCos community.

git may be mainstream to Linux users, but is IMHO is not as user
friendly as what the majority of eCos users and contributors should
expect from a DRCS.  I believe that it will make life harder than it
ought to be when converting to a DRCS model, and particularly to anyone
who is not familiar with Linux (Windows users, and the average eCos user). 

Think about it.  Most eCos users and developers use Windows for their
development, yet most contributors are Linux power users.  Surely we
want something that would encourage and make it easier for Windows
hosted eCos developers to contribute, yet does not inhibit those Linux
power users and existing regular eCos contributors (and of course the
eCos maintainers) in any way?

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

Re: [ECOS] eCos submodule support

[Jonathan Larmour]

Alex Schuilenburg wrote:
> 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,

Please be civil on this list.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

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

Re: [ECOS] eCos submodule support

[Jonathan Larmour]

Øyvind Harboe wrote:
> On Tue, Oct 20, 2009 at 4:37 PM, Alex Schuilenburg
>>Then why are you using git?
> 
> Because, @ work, I have to learn and understand it, as the projects
> that I work & interact with use it. That hg is "better" doesn't mean that
> much.

That's primarily Linux presumably.

> I have other projects I work on where e.g. git submodules are used
> extensively. There just isn't any way around learning about git in detail.
> hg I could potentially not learn, so far.

Whichever VCS is chosen, we would intend to put up some documentation and 
"recipes" so that people can get going with it. So basic use should be no 
problem.

I would also hope that even if it's not git, we'd be able to show git 
users how to interface with it (although that will require someone to do 
it the first time to write it up!).

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

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

Re: [ECOS] eCos submodule support

[Alex Schuilenburg]

Jonathan Larmour wrote:
> Alex Schuilenburg wrote:
>> 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,
>
> Please be civil on this list.
Sorry, I never meant to imply that anyone on this list was arrogant.

I had just come off a list where I simply seeked clarification what RCS
interoperability support was available in git and was "strongly
criticised" for not simply converting to git and then only using git. My
comment was directed at those on that list where I guess it is OK to
flame those who don't drink their flavour cool-aid.

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

Re: [ECOS] Re: eCos submodule support

[Øyvind Harboe]

> Think about it.  Most eCos users and developers use Windows for their
> development, yet most contributors are Linux power users.  Surely we
> want something that would encourage and make it easier for Windows
> hosted eCos developers to contribute, yet does not inhibit those Linux
> power users and existing regular eCos contributors (and of course the
> eCos maintainers) in any way?

I think we should break out contribution in a separate topic....

Consider:

http://sourceware.org/ml/ecos-patches/2009-10/msg00006.html
http://sourceware.org/ml/ecos-patches/2009-07/msg00002.html

No responses. Patches don't come much simpler than that...

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

Re: [ECOS] Re: eCos submodule support

[Alex Schuilenburg]

Alex Schuilenburg wrote on 2009-10-20 22:37:
> Sergei Organov wrote:
>   
>> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
>>   
>>     
>>> To be a bit more clear:
>>>
>>> My assumption is that there is no appreciable difference
>>> between hg/git for the case when *all* modules are
>>> either git/hg.
>>>
>>> The problem is with heterogeneous projects.
>>>
>>> When working with eCos I've only ever encountered
>>> git, cvs and svn as version controls. CVS very rarely
>>> these days. I'm sure there are eCos relevant projects
>>> that use hg, I just haven't encountered them.
>>>
>>> Managing svn as a submodule in git is easy enough.
>>>
>>> I have never tried to manage hg as a submodule in git.
>>>     
>>>       
>> Probably the best bet is to keep your own git repository of eCos
>> (automatically and incrementally) converted from the official hg one,
>> then use those git repo as a submodule in your project utilizing git.
>>   
>>     
> Or even better, a local hg repository providing a git interface. That
> way you could locally push changes upstream from the local hg repo
> (since I dont know if git can push to hg) as if it were a git repo, you
> would need upstream shell access to the remote hg repo to pull from your
> local git repo (since hg can pull and push to git).  You could then
> stick to using git locally as mandated by your company, and still
> benefit from proper DRCS flow rather than a one-way downstream only flow.
>   
Just to update on this.

It appears you are able to use git to push/pull to/from a hg repo using
the hg-git plugin, it is just a bit convoluted to set up. 

From the author of hg-git at:
http://github.com/blog/439-hg-git-mercurial-plugin#comment_1933

    "technically, you /can/ use this to use Git to collaborate on Hg
    hosted projects - there are 'gimport' and 'gexport' commands that
    will just do the object translations - but it's a bit more
    convoluted. i'll try to write up a guide on how to do that at some
    point after this is all settled down."


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