Re: [ECOS] Re: eCos submodule support

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

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]

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

[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

[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

[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