Re: [ECOS] eCos submodule support

[Alex Schuilenburg <alexs@ecoscentric.com>]

Ø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