[ECOS] Re: Switching to using git on eCosForge

[ECOS] Re: Switching to using git on eCosForge

[Alex Schuilenburg]

[Apologies to sergei for repost - grrr]

Sergei Organov wrote on 2009-09-21 14:05:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
>
> [...]
>
>   
>> Both bazaar and mercurial were a lot easier to learn and work with
>> than git. git's Windows support is also limited and is mostly
>> restricted to the 100's of cmd apps which make up git under cygwin.
>>     
>
> Once again, I'm not a Windows user, but is this really true nowadays?
>
> E.g., what about this one:
>
> <http://code.google.com/p/tortoisegit/>
>
> Isn't it good enough for Windows users?
>   
and hg has TortoiseHG <http://tortoisehg.sourceforge.net/>
(http://tortoisehg.sourceforge.net/).  Like I said, feature comparison
between git and hg is pretty much on a par...

Lack of windows support/integration is not my main argument against git
FWIW.

My main argument against git is it has a very steep initial learning
curve, and from experience you can hang yourself if you do not know what
you are doing.  (Yes, there are rollbacks, etc, but sometimes it is a
while down the line before you realise you did something wrong). You
really don't want to force new users on an additional learning curve. 
There are 100's of commands to remember, whereas both bzr and hg have one.

Also, while documentation is improving (http://book.git-scm.com/), it is
not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
in terms of non-power users.  Both have books in print available from
places like Amazon.

For example, I started my evaluation with bzr, then hg then git. bzr and
hg were a lot easiest to pick up and start using than git.  I also have
done most of my eval on Linux, dropping back to Windows to see how easy
it was to use and integrate graphical diff tools, etc.

For other comparisons see:
http://code.google.com/p/support/wiki/DVCSAnalysis
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29
...

but bear in mind that arguments against either git or hg may have
disappeared with more recent versions.  You really need to try both...

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


-- 
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: Switching to using git on eCosForge

[Sergei Organov]

Alex Schuilenburg <alexs@ecoscentric.com> writes:
[...]

> My main argument against git is it has a very steep initial learning
> curve,

Really? Not in my experience. IMHO, those 3 we discuss are roughly the
same, just having raw corners in different places. E.g., there is even a
table of commands equivalence between hg and git somewhere.

> and from experience you can hang yourself if you do not know what
> you are doing.  (Yes, there are rollbacks, etc, but sometimes it is a
> while down the line before you realise you did something wrong).

It's a very nice thing with git that it's virtually impossible to loose
your work as soon as you committed it to git, really, even if you keep
doing something wrong. Even though nowadays git does automatically run
garbage collection, the reflog feature still keeps all unreferenced data
intact for rather long time.

> You really don't want to force new users on an additional learning
> curve. There are 100's of commands to remember, whereas both bzr and
> hg have one.

Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only
one as well: 'git' ;-)

One does need additional learning curve switching from CVS to any of
DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again,
with git you can have gitcvsserver running to keep "CVS forever"
users happy with their favorite clients.

> Also, while documentation is improving (http://book.git-scm.com/), it is
> not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
> in terms of non-power users.  Both have books in print available from
> places like Amazon.

For me git's documentation was more than enough to have a quick-start.

>
> For example, I started my evaluation with bzr, then hg then git. bzr and
> hg were a lot easiest to pick up and start using than git.

I wonder, do you remember what the problem(s) with git was (were)? Care
to give an example where git is harder than any of the other two?

> I also have done most of my eval on Linux, dropping back to Windows to
> see how easy it was to use and integrate graphical diff tools, etc.
>
> For other comparisons see:
> http://code.google.com/p/support/wiki/DVCSAnalysis
> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands
> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29
> ...
>
> but bear in mind that arguments against either git or hg may have
> disappeared with more recent versions.  You really need to try both...

Yes, all 3 are improving and do borrow from each other. However, in my
opinion, git is preferred in the long run as it has very clear, simple
yet powerful model in its core, when hg already outlived its initial
simple design model based on "every branch is a separate repository"
idea (now it has 3(!) different kinds of branches), and bzr is being
built from use-cases down (see how many times they have already changed
format of repository). Yes, sure, me could be entirely wrong ;-)

-- 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] Re: Switching to using git on eCosForge

[Sergei Gavrikov]

On Mon, Sep 21, 2009 at 03:39:09PM +0100, Alex Schuilenburg wrote:
> [Apologies to sergei for repost - grrr]
> 
> Sergei Organov wrote on 2009-09-21 14:05:
> > Alex Schuilenburg <alexs@ecoscentric.com> writes:
> >
> > [...]
> >
> >   
> >> Both bazaar and mercurial were a lot easier to learn and work with
> >> than git. git's Windows support is also limited and is mostly
> >> restricted to the 100's of cmd apps which make up git under cygwin.
> >>     
> >
> > Once again, I'm not a Windows user, but is this really true nowadays?
> >
> > E.g., what about this one:
> >
> > <http://code.google.com/p/tortoisegit/>
> >
> > Isn't it good enough for Windows users?
> >   
> and hg has TortoiseHG <http://tortoisehg.sourceforge.net/>
> (http://tortoisehg.sourceforge.net/).  Like I said, feature comparison
> between git and hg is pretty much on a par...
> 
> Lack of windows support/integration is not my main argument against git
> FWIW.
> 
> My main argument against git is it has a very steep initial learning
> curve, and from experience you can hang yourself if you do not know what
> you are doing.  (Yes, there are rollbacks, etc, but sometimes it is a
> while down the line before you realise you did something wrong). You
> really don't want to force new users on an additional learning curve. 
> There are 100's of commands to remember, whereas both bzr and hg have one.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Excuse, please, my thougths the below. Any *nix CLI environment has
something like the above :-) BUT, with those 100's {text,file}utils
someone is able to do everything (even make world), but, today, *nix
does not make him/her use those 100's. If somebody wants, he/she may
use only `cp' and `mv' + $EDITOR, like `Explorer' + ... well, lets
that will be `Notepad' to make things spin, if he/she wants, they can
use only IDE likes Eclipse to do everything like it he/she did in
Visual Studio.  The most modern IDEs have all VCS modules/plugins,
e.g. Komodo (Git, CVS, Perforce, Bazaar, Mercurial, etc.) and, BTW,
Eclipse has Git plugin, etc.  I'm not Git user, but I think it is
possible to overlap those 100's by N*100 clicks in IDE, if anyone
wants that, they do it for them! I do not belive that maintainers will
suggest then, Use IDE 'A' and do not use IDE 'B' for development with
eCos.

Just now I entered in search box 'CVS refcard', I download it and open
the card. 100's commands? No, there are not. It seems there are a lot
of options. How many CVS options we use(d) every day? I think what
_any_ VC's (git is not exception) _every_day_in_use_ refcard will be
that A4 sheet or half it. Thin things for CLI fans, so, they may `make
world', IMO, others use A4 sheet and it will be enougth, it seems for
me those IDEs implement (A4 on both sides) in GUI and that's enough.

A thougth what Git == 100's CLI is the same myth likes *nix is life
with ksh.

Another issue. Do you really expect to find in a future any
assistances here with _any_ VCS+GUI like the below, for example:

- What IDE do you use?
- Bla-bla-bla
- Hm, that does not like any Tortoise. Test a moment, please... Well,
  Click there, expand that node, turn on that switch, then click [Ok]
- What dialog are you seeing now?
- ...

I guess that this will be type then in the list, e.g., invoke

$ {git,hg,bzr,svn} [option] <command>

or

read, please, for start: ecos.sourceware.org/anyvcs.html and follow
the ref links there for a far reading.

Why I think so? It's the real world. I did not meet here a lot
assistance with configtool, for example, (BTW, CT is official GUI
configuration tool for eCos), n.b. just get the suggests here to
import some CDL options with ecosconfig. This is the real world.

It seems for me that we try to decrease troubles for windows users
because they have it enough, but, unfortunately, they is/will be in
trouble with 10's CLI commands (hg, bzr) as well as with the 100's
CLI commands (git). Of course, if they will be use CLI and not any
Tortoise*. I say 'trouble' == 'remember' :-)

> Also, while documentation is improving (http://book.git-scm.com/), it is
> not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
> in terms of non-power users.  Both have books in print available from
> places like Amazon.
> For example, I started my evaluation with bzr, then hg then git. bzr and
> hg were a lot easiest to pick up and start using than git.  I also have
> done most of my eval on Linux, dropping back to Windows to see how easy
> it was to use and integrate graphical diff tools, etc.

Today I'm mercurial user (my way was from lanchpad (bzr) to bitbucket
(hg), but I have not tried github yet :-) and it was happy that I'm
CLI user. In those days when I read Bryan O'Sullivan HG book I
observed a lot of examples like the below

echo a>a
echo b>b
hg ci -A -m 'add a,b'
echo c>>a
hg diff

AFAIR, HG book in those days was 99.9% of CLI examples. It seems I
must re-read new revision... What a nice thing to get $40.00 from
every reader which could only see in his prev life:

C:\>

Unfortunately, in fact, it is not possible to give a full power for
windows users without CLI, even with very friendly VCS, because, even
eCos on Windows, in fact, it is CLI (Cygwin + GNU). In any case, then
windows users hear here new words: objcopy, readelf, strip, size, etc.
very often. So, what world will be added then (git, hg, bzr), it's no
matter.

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] Re: Switching to using git on eCosForge

[Alex Schuilenburg]

Sergei Organov wrote:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
> [...]
>   
>> My main argument against git is it has a very steep initial learning
>> curve,
>>     
> Really? Not in my experience. 
Yes, really, and not only my experience either. I guess I must be below
the curve on learning new technology, but then it could also be my age ;-)


> IMHO, those 3 we discuss are roughly the
> same, just having raw corners in different places. E.g., there is even a
> table of commands equivalence between hg and git somewhere.
>   
Several places actually.  And yes, functionality on each is roughly the
same.

>   
>> and from experience you can hang yourself if you do not know what
>> you are doing.  (Yes, there are rollbacks, etc, but sometimes it is a
>> while down the line before you realise you did something wrong).
>>     
>
> It's a very nice thing with git that it's virtually impossible to loose
> your work as soon as you committed it to git, really, even if you keep
> doing something wrong. Even though nowadays git does automatically run
> garbage collection, the reflog feature still keeps all unreferenced data
> intact for rather long time.
>
>   
And yes, functionality on each is roughly the same.  I think we should
stop going round in circles.  We appear to agree all three have similar
functionality. If you want a contest on which is the most powerful, I
will save you the trouble. git is currently the most powerful.  If you
want an example of a powerful feature git has that is harder to do in
the others, let me save you the trouble again: git commit --amend (in hg
if the commit is buried you will need to have been using queues and will
have to export changesets, fix and re-import - more painful, but
achievable). 

However, I would point out again that all three borrow from the others,
so evaluating is always going to be a moving target.
>> You really don't want to force new users on an additional learning
>> curve. There are 100's of commands to remember, whereas both bzr and
>> hg have one.
>>     
>
> Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only
> one as well: 'git' ;-)
>
> One does need additional learning curve switching from CVS to any of
> DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again,
> with git you can have gitcvsserver running to keep "CVS forever"
> users happy with their favorite clients.
>   
% ls -l /usr/bin/git-* | wc -l
136
%

and I only have git-core installed on that machine...

FWIW I already had come upto speed with DRCS with bzr and hg before I
played with git. Figuring out which command to use to do a specific task
without resorting to a manual was my initial stumbling block - I just
initially felt somewhat overwhelmed.  bzr and hg seemed easier to pick
up and start using where with git I was never quite sure if I was using
the correct options.  Too many bells and whistles I guess which was
compounded by not easily being able to find pointers to assure me I was
doing the right thing. Hence I never quite felt comfortable using git in
the beginning.  But of course this is a subjective opinion - YMMV.


>> Also, while documentation is improving (http://book.git-scm.com/), it is
>> not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
>> in terms of non-power users.  Both have books in print available from
>> places like Amazon.
>>     
>
> For me git's documentation was more than enough to have a quick-start.
>
>   
>> For example, I started my evaluation with bzr, then hg then git. bzr and
>> hg were a lot easiest to pick up and start using than git.
>>     
>
> I wonder, do you remember what the problem(s) with git was (were)? Care
> to give an example where git is harder than any of the other two?
>   
I never said I had problems doing things in git - I said I had problems
finding out how to do them. Tell me with a straight face that the number
of options in some of the git commands did not overwhelm you the first
time you saw them?

When you want to encourage community development, you really need to
keep it simple for developers to keep abreast of advances and contribute
back. Not have so many bells and whistles that they feel like they
should not touch anything in case it breaks, or worse, have someone who
thinks they know what they are doing but does not.

>   
>> I also have done most of my eval on Linux, dropping back to Windows to
>> see how easy it was to use and integrate graphical diff tools, etc.
>>
>> For other comparisons see:
>> http://code.google.com/p/support/wiki/DVCSAnalysis
>> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
>> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
>> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands
>> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
>> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29
>> ...
>>
>> but bear in mind that arguments against either git or hg may have
>> disappeared with more recent versions.  You really need to try both...
>>     
>
> Yes, all 3 are improving and do borrow from each other. However, in my
> opinion, git is preferred in the long run as it has very clear, simple
> yet powerful model in its core, when hg already outlived its initial
> simple design model based on "every branch is a separate repository"
> idea (now it has 3(!) different kinds of branches), and bzr is being
> built from use-cases down (see how many times they have already changed
> format of repository). Yes, sure, me could be entirely wrong ;-)
>   
Not entirely wrong ;-)   When working with branches ever run "git
submodule update" when you've made and committed changes within a
submodule without checking out the branch first, only to discover later
that the changes were silently overwritten?

However, I strongly disagree with your comment "hg already outlived its
initial simple design..." though.  hg's design is just as simple as git
and there is nothing in hg's design IMHO that limits what it can do. It
is still evolving, just like git and eCos. The forests extension has
been around just as long as sub-modules AFAIKT, but I admit it is taking
a while for hg to make it part of their core functionality.

I am sure we can equally find flaws in the others preferred DRCS just as
we can find features...   

And defintely yes, all three borrow from each other, even documentation
in the case of git ;-)  http://cworth.org/hgbook-git/tour/).  But IMHO
hg still has stronger documentation and is easier for newcomers to start
with.

Anyway, it is good to have an alternative view on what the best choice
of DRCS for eCos is.  I guess you and I can agree to disagree on what
that choice should be though, and let others tell us what they think ;-)

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


-- 
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] JFFS2 Or Compiler Issue.

[Ramgopal Kota]

[-- Attachment #1: Type: text/plain, Size: 9113 bytes --]

Hi,

I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue.
In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below 

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

struct jffs2_unknown_node
{
  /* All start like this */
  jint16_t magic;
  jint16_t nodetype;
  jint32_t totlen; /* So we can skip over nodes we don't grok */
  jint32_t hdr_crc;
} __attribute__((packed));

I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER.

If I change the code to the following it is working fine...

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

marker.magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK);

I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag.
I am attaching the specs for the compiler I am using.
Compiler I am using is gcc version 3.2.1 (eCosCentric)

Thanks & Regards,
Ramgopal Kota

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Alex Schuilenburg
Sent: Tuesday, September 22, 2009 4:12 AM
To: Sergei Organov
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Re: Switching to using git on eCosForge

Sergei Organov wrote:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
> [...]
>   
>> My main argument against git is it has a very steep initial learning
>> curve,
>>     
> Really? Not in my experience. 
Yes, really, and not only my experience either. I guess I must be below
the curve on learning new technology, but then it could also be my age ;-)


> IMHO, those 3 we discuss are roughly the
> same, just having raw corners in different places. E.g., there is even a
> table of commands equivalence between hg and git somewhere.
>   
Several places actually.  And yes, functionality on each is roughly the
same.

>   
>> and from experience you can hang yourself if you do not know what
>> you are doing.  (Yes, there are rollbacks, etc, but sometimes it is a
>> while down the line before you realise you did something wrong).
>>     
>
> It's a very nice thing with git that it's virtually impossible to loose
> your work as soon as you committed it to git, really, even if you keep
> doing something wrong. Even though nowadays git does automatically run
> garbage collection, the reflog feature still keeps all unreferenced data
> intact for rather long time.
>
>   
And yes, functionality on each is roughly the same.  I think we should
stop going round in circles.  We appear to agree all three have similar
functionality. If you want a contest on which is the most powerful, I
will save you the trouble. git is currently the most powerful.  If you
want an example of a powerful feature git has that is harder to do in
the others, let me save you the trouble again: git commit --amend (in hg
if the commit is buried you will need to have been using queues and will
have to export changesets, fix and re-import - more painful, but
achievable). 

However, I would point out again that all three borrow from the others,
so evaluating is always going to be a moving target.
>> You really don't want to force new users on an additional learning
>> curve. There are 100's of commands to remember, whereas both bzr and
>> hg have one.
>>     
>
> Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only
> one as well: 'git' ;-)
>
> One does need additional learning curve switching from CVS to any of
> DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again,
> with git you can have gitcvsserver running to keep "CVS forever"
> users happy with their favorite clients.
>   
% ls -l /usr/bin/git-* | wc -l
136
%

and I only have git-core installed on that machine...

FWIW I already had come upto speed with DRCS with bzr and hg before I
played with git. Figuring out which command to use to do a specific task
without resorting to a manual was my initial stumbling block - I just
initially felt somewhat overwhelmed.  bzr and hg seemed easier to pick
up and start using where with git I was never quite sure if I was using
the correct options.  Too many bells and whistles I guess which was
compounded by not easily being able to find pointers to assure me I was
doing the right thing. Hence I never quite felt comfortable using git in
the beginning.  But of course this is a subjective opinion - YMMV.


>> Also, while documentation is improving (http://book.git-scm.com/), it is
>> not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
>> in terms of non-power users.  Both have books in print available from
>> places like Amazon.
>>     
>
> For me git's documentation was more than enough to have a quick-start.
>
>   
>> For example, I started my evaluation with bzr, then hg then git. bzr and
>> hg were a lot easiest to pick up and start using than git.
>>     
>
> I wonder, do you remember what the problem(s) with git was (were)? Care
> to give an example where git is harder than any of the other two?
>   
I never said I had problems doing things in git - I said I had problems
finding out how to do them. Tell me with a straight face that the number
of options in some of the git commands did not overwhelm you the first
time you saw them?

When you want to encourage community development, you really need to
keep it simple for developers to keep abreast of advances and contribute
back. Not have so many bells and whistles that they feel like they
should not touch anything in case it breaks, or worse, have someone who
thinks they know what they are doing but does not.

>   
>> I also have done most of my eval on Linux, dropping back to Windows to
>> see how easy it was to use and integrate graphical diff tools, etc.
>>
>> For other comparisons see:
>> http://code.google.com/p/support/wiki/DVCSAnalysis
>> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
>> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
>> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands
>> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
>> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29
>> ...
>>
>> but bear in mind that arguments against either git or hg may have
>> disappeared with more recent versions.  You really need to try both...
>>     
>
> Yes, all 3 are improving and do borrow from each other. However, in my
> opinion, git is preferred in the long run as it has very clear, simple
> yet powerful model in its core, when hg already outlived its initial
> simple design model based on "every branch is a separate repository"
> idea (now it has 3(!) different kinds of branches), and bzr is being
> built from use-cases down (see how many times they have already changed
> format of repository). Yes, sure, me could be entirely wrong ;-)
>   
Not entirely wrong ;-)   When working with branches ever run "git
submodule update" when you've made and committed changes within a
submodule without checking out the branch first, only to discover later
that the changes were silently overwritten?

However, I strongly disagree with your comment "hg already outlived its
initial simple design..." though.  hg's design is just as simple as git
and there is nothing in hg's design IMHO that limits what it can do. It
is still evolving, just like git and eCos. The forests extension has
been around just as long as sub-modules AFAIKT, but I admit it is taking
a while for hg to make it part of their core functionality.

I am sure we can equally find flaws in the others preferred DRCS just as
we can find features...   

And defintely yes, all three borrow from each other, even documentation
in the case of git ;-)  http://cworth.org/hgbook-git/tour/).  But IMHO
hg still has stronger documentation and is easier for newcomers to start
with.

Anyway, it is good to have an alternative view on what the best choice
of DRCS for eCos is.  I guess you and I can agree to disagree on what
that choice should be though, and let others tell us what they think ;-)

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


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



[-- Attachment #2: 1.txt --]
[-- Type: text/plain, Size: 8342 bytes --]

*asm:
%{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips64}%{mips16:%{!mno-mips16:-mips16}} %{mno-mips16:-no-mips16} %(subtarget_asm_optimizing_spec) %(subtarget_asm_debugging_spec) %{membedded-pic} %{mabi=32:-32}%{mabi=o32:-32}%{mabi=n32:-n32}%{mabi=64:-64}%{mabi=n64:-64} %(target_asm_spec) %(subtarget_asm_spec)

*asm_debug:
%{gdwarf-2*:--gdwarf2}%{!gdwarf-2*:%{g*:--gstabs}}

*asm_final:
%{mmips-as: %{!mno-mips-tfile: 	
 mips-tfile %{v*: -v} 		%{K: -I %b.o~} 		%{!K: %{save-temps: -I %b.o~}} 		%{c:%W{o*}%{!o*:-o %b.o}}%{!c:-o %U.o} 		%{.s:%i} %{!.s:%g.s}}}

*asm_options:
%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}

*invoke_as:
%{!S:-o %{|!pipe:%g.s} |
 as %(asm_options) %{!pipe:%g.s} %A }

*cpp:
%{.m:	-D__LANGUAGE_OBJECTIVE_C -D_LANGUAGE_OBJECTIVE_C -D__LANGUAGE_C -D_LANGUAGE_C} %{.S|.s: -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY %{!ansi:-DLANGUAGE_ASSEMBLY}} %{!.S: %{!.s: %{!.cc: %{!.cxx: %{!.cpp: %{!.cp: %{!.c++: %{!.C: %{!.m: -D__LANGUAGE_C -D_LANGUAGE_C %{!ansi:-DLANGUAGE_C}}}}}}}}}} %(subtarget_cpp_size_spec) %{mips3:-U__mips -D__mips=3 -D__mips64} %{mips4:-U__mips -D__mips=4 -D__mips64} %{mips32:-U__mips -D__mips=32} %{mips64:-U__mips -D__mips=64 -D__mips64} %{mgp32:-U__mips64} %{mgp64:-D__mips64} %{mfp32:-D__mips_fpr=32} %{mfp64:-D__mips_fpr=64} %{!mfp32: %{!mfp64: %{mgp32:-D__mips_fpr=32} %{!mgp32: %(cpp_fpr_spec)}}} %{msingle-float:%{!msoft-float:-D__mips_single_float}} %{m4650:%{!msoft-float:-D__mips_single_float}} %{msoft-float:-D__mips_soft_float} %{mabi=eabi:-D__mips_eabi} %{mips16:%{!mno-mips16:-D__mips16}} %{EB:-UMIPSEL -U_MIPSEL -U__MIPSEL -U__MIPSEL__ -D_MIPSEB -D__MIPSEB -D__MIPSEB__ %{!ansi:-DMIPSEB}} %{EL:-UMIPSEB -U_MIPSEB -U__MIPSEB -U__MIPSEB__ -D_MIPSEL -D__MIPSEL -D__MIPSEL__ %{!ansi:-DMIPSEL}} %(long_max_spec) %(subtarget_cpp_spec) 

*cpp_options:
%(cpp_unique_options) %{std*} %{d*} %{W*} %{w} %{pedantic*} %{fshow-column} %{fno-show-column} %{fsigned-char&funsigned-char} %{fleading-underscore} %{fno-leading-underscore} %{fno-operator-names} %{ftabstop=*}

*cpp_unique_options:
%{C:%{!E:%eGNU C does not support -C without using -E}} %{nostdinc*} %{C} %{v} %{I*} %{P} %{$} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3 -D__GXX_ABI_VERSION=102} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}} %{fno-inline|O0|!O*:-D__NO_INLINE__} %{ffast-math:-D__FAST_MATH__} %{fshort-wchar:-U__WCHAR_TYPE__ -D__WCHAR_TYPE__=short\ unsigned\ int} %{ffreestanding:-D__STDC_HOSTED__=0} %{fno-hosted:-D__STDC_HOSTED__=0} %{!ffreestanding:%{!fno-hosted:-D__STDC_HOSTED__=1}} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}}

*trad_capable_cpp:
%{traditional|ftraditional|traditional-cpp:trad}cpp0

*cc1:
%{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1}}}}} %{mips1:-mfp32 -mgp32} %{mips2:-mfp32 -mgp32}%{mips3:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mips4:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mips32:-mfp32 -mgp32} %{mips64:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mfp64:%{msingle-float:%emay not use both -mfp64 and -msingle-float}} %{mfp64:%{m4650:%emay not use both -mfp64 and -m4650}} %{mint64|mlong64|mlong32:-mexplicit-type-size }%{mgp32: %{mfp64:%emay not use both -mgp32 and -mfp64} %{!mfp32: -mfp32}} %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %{pic-none:   -mno-half-pic} %{pic-lib:    -mhalf-pic} %{pic-extern: -mhalf-pic} %{pic-calls:  -mhalf-pic} %{save-temps: } %(subtarget_cc1_spec) %(cc1_cpu_spec)

*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{g*} %{O*} %{W*} %{w} %{pedantic*} %{std*} %{ansi} %{traditional} %{v:-version} %{pg:-p} %{p} %{f*} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*}

*cc1plus:


*link_gcc_c_sequence:
%G %L %G

*endfile:
crtend%O%s crtn%O%s

*link:
%(endian_spec) %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips64} %{bestGnum} %{shared} %{non_shared}

*lib:


*libgcc:
-lgcc

*startfile:
crti%O%s crtbegin%O%s %{!mno-crt0: }

*switches_need_spaces:


*predefines:
-Dmips -DMIPSEB -DR3000 -D_mips -D_MIPSEB -D_R3000

*cross_compile:
1

*version:
3.2.1

*multilib:
. !msoft-float !EL !EB !mips32 !mips64;soft-float msoft-float !EL !EB !mips32 !mips64;el !msoft-float EL !EB !mips32 !mips64;eb !msoft-float !EL EB !mips32 !mips64;mips32 !msoft-float !EL !EB mips32 !mips64;mips64 !msoft-float !EL !EB !mips32 mips64;el/mips32 !msoft-float EL !EB mips32 !mips64;el/mips64 !msoft-float EL !EB !mips32 mips64;eb/mips32 !msoft-float !EL EB mips32 !mips64;eb/mips64 !msoft-float !EL EB !mips32 mips64;soft-float/el msoft-float EL !EB !mips32 !mips64;soft-float/eb msoft-float !EL EB !mips32 !mips64;soft-float/mips32 msoft-float !EL !EB mips32 !mips64;soft-float/mips64 msoft-float !EL !EB !mips32 mips64;soft-float/el/mips32 msoft-float EL !EB mips32 !mips64;soft-float/el/mips64 msoft-float EL !EB !mips32 mips64;soft-float/eb/mips32 msoft-float !EL EB mips32 !mips64;soft-float/eb/mips64 msoft-float !EL EB !mips32 mips64;

*multilib_defaults:
EB mips32

*multilib_extra:


*multilib_matches:
msoft-float msoft-float;EL EL;EB EB;mips32 mips32;mips64 mips64;

*multilib_exclusions:


*multilib_options:
msoft-float EL/EB mips32/mips64

*linker:
collect2

*link_libgcc:
%D

*md_exec_prefix:


*md_startfile_prefix:


*md_startfile_prefix_1:


*subtarget_cc1_spec:


*cc1_cpu_spec:
%{!mcpu*: %{m3900:-march=r3900 -mips1 -mfp32 -mgp32 %n`-m3900' is deprecated. Use `-march=r3900' instead.
} %{m4650:-march=r4650 -mmad -msingle-float %n`-m4650' is deprecated. Use `-march=r4650' instead.
}}

*subtarget_cpp_spec:


*subtarget_cpp_size_spec:
%{mabi=eabi:  %{mips1|mips2|mips32|mlong32|mgp32:%{!mips3:%{!mips4:%{!mips5:%{!mips64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}}}}}   %{mlong64:    %{mgp64:-D__SIZE_TYPE__=long\ unsigned\ int -D__PTRDIFF_TYPE__=long\ int}     %{!mgp64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}}  %{mips3|mips4|mips5|mips64:-D__SIZE_TYPE__=long\ unsigned\ int -D__PTRDIFF_TYPE__=long\ int}}   %{!mips1:%{!mips2:%{!mips3:%{!mips4:%{!mips5:%{!mips32:%{!mips64:%{!mlong32:%{!mlong64:%{!mgp32:%{!mgp64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}}}}}}}}}}}%{mabi=o64: %{mlong64:   %{!mgp32:-D__SIZE_TYPE__=long\ unsigned\ int -D__PTRDIFF_TYPE__=long\ int}    %{mgp32:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}}  %{!mlong64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}} %{mabi=32:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}%{mabi=meabi|!mabi=*:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int} 

*long_max_spec:
%{mabi=64:-D__LONG_MAX__=9223372036854775807L}    %{mlong64:-D__LONG_MAX__=9223372036854775807L}    %{mgp64:-D__LONG_MAX__=9223372036854775807L}

*cpp_fpr_spec:
-D__mips_fpr=32

*mips_as_asm_spec:
%{!.s:-nocpp} %{.s: %{cpp} %{nocpp}} %{pipe: %e-pipe is not supported} %{K} %(subtarget_mips_as_asm_spec)

*gas_asm_spec:
%{march=*} %{mtune=*} %{mcpu=*} %{m4650} %{mmad:-m4650} %{m3900} %{v} %{mgp32} %{mgp64} %(abi_gas_asm_spec) %{mabi=32:%{!mips*:-mips1}}

*abi_gas_asm_spec:


*target_asm_spec:
%{mmips-as: %(mips_as_asm_spec)} %{!mmips-as: %(gas_asm_spec)}

*subtarget_mips_as_asm_spec:
%{v}

*subtarget_asm_optimizing_spec:
%{noasmopt:-O0} %{!noasmopt:%{O:-O2} %{O1:-O2} %{O2:-O2} %{O3:-O3}}

*subtarget_asm_debugging_spec:
%{g} %{g0} %{g1} %{g2} %{g3} %{ggdb:-g} %{ggdb0:-g0} %{ggdb1:-g1} %{ggdb2:-g2} %{ggdb3:-g3} %{gstabs:-g} %{gstabs0:-g0} %{gstabs1:-g1} %{gstabs2:-g2} %{gstabs3:-g3} %{gstabs+:-g} %{gstabs+0:-g0} %{gstabs+1:-g1} %{gstabs+2:-g2} %{gstabs+3:-g3} %{gcoff:-g} %{gcoff0:-g0} %{gcoff1:-g1} %{gcoff2:-g2} %{gcoff3:-g3}

*subtarget_asm_spec:


*endian_spec:
%{!EL:%{!mel:-EB}} %{EL|mel:-EL}

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t}    %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}    %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}    %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
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: Switching to using git on eCosForge

[Peter Korsgaard]

>>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes:

Hi,

AS> % ls -l /usr/bin/git-* | wc -l
AS> 136
AS> %

That hasn't been the situation since git 1.6.0, released 13 months
ago. When evaluating something as fast moving as DVCS'es, please use
the latest stable release of the tools.

-- 
Bye, Peter Korsgaard


-- 
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: Switching to using git on eCosForge

[Alex Schuilenburg]

Peter Korsgaard wrote on 2009-09-22 10:55:
>>>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes:
>>>>>>             
>
> Hi,
>
> AS> % ls -l /usr/bin/git-* | wc -l
> AS> 136
> AS> %
>
> That hasn't been the situation since git 1.6.0, released 13 months
> ago. When evaluating something as fast moving as DVCS'es, please use
> the latest stable release of the tools.
>   
Ah, for 1.6.x you mean
# ls -l /usr/libexec/git-core | wc -l
132
# ls -l /usr/bin/git* | wc -l
 4
#

You can run but you cannot hide ;-)

I think if we are going to switch sooner rather than later you need to
evaluate what is available pre-packaged from whatever distro or OS
provider.  i.e. what the regular users are going to be able to access
easily without having to upgrade their system or build the tools
themselves.

Don't get me wrong, git is great and all empowering.  But IMHO that is
the problem - there is enough rope to hang yourself.  For example,
consider the following subtlety:
"If you are staging an updated submodule for commit manually, be careful
to not add a trailing slash when specifying the path. With the slash
appended, Git will assume you are removing the submodule and checking
that directory's contents into the containing repository."

A trailing slash is what my bash completion puts in my path and is
likely to be *my* default behaviour.  IMHO that is broken, but I am sure
someone in git-land thinks it makes perfect sense and is perfectly
acceptable behaviour.  If I was a git expert, maybe I would too.  But
the average Joe is not and not likely to want to be one.

We are not talking here what is the most superior DRCS, we are talking
what is the most suitable for eCos.  You don't need a 10lb hammer to
crack a nut.

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


-- 
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: Switching to using git on eCosForge

[Sergei Gavrikov]

On Tue, Sep 22, 2009 at 12:08:17PM +0100, Alex Schuilenburg wrote:
> Peter Korsgaard wrote on 2009-09-22 10:55:
> >>>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes:
> >>>>>>             
> >
> > Hi,
> >
> > AS> % ls -l /usr/bin/git-* | wc -l
> > AS> 136
> > AS> %
> >
> > That hasn't been the situation since git 1.6.0, released 13 months
> > ago. When evaluating something as fast moving as DVCS'es, please use
> > the latest stable release of the tools.
> >   
> Ah, for 1.6.x you mean
> # ls -l /usr/libexec/git-core | wc -l
> 132
> # ls -l /usr/bin/git* | wc -l
>  4
> #
> 
> You can run but you cannot hide ;-)

Ah, that's poor-poor busybox :-)

and what do you think about Easy Git? Would you like observe these,
please?

http://www.gnome.org/~newren/eg/
http://www.gnome.org/~newren/eg/documentation/

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] Re: Switching to using git on eCosForge

[Peter Korsgaard]

>>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes:

Hi,

AS> Ah, for 1.6.x you mean
AS> # ls -l /usr/libexec/git-core | wc -l
AS> 132
AS> # ls -l /usr/bin/git* | wc -l
AS>  4
AS> #

AS> You can run but you cannot hide ;-)

But that's an implementation detail. I as a user don't care if the
various git subcommands are implemented in seperate binaries or a
single multi-function binary.

Again, the working set (E.G. common commands) are pretty similar:

svn help|wc -l
47

git help|wc -l
26

hg help|wc -l
67

-- 
Bye, Peter Korsgaard


-- 
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: Switching to using git on eCosForge

[Edgar Grimberg]

Hi,

My 2 cents on the topic:

* eCos maintainers need to follow up on patches and bugs. The kernel
and other "common" areas should have priority over specific HALs. This
is a place where things must go without any hiccups. I've been around
the office when Oyvind found the sscanf bug. Imagine the frustration
finding a 2 years old patch just rotting out there... Maybe a clear
procedure must be written and published. Something like in the
emergency rooms: sever bugs - one day to commit, normal bugs in common
areas - 3 days to commit, normal bugs in HAL - 7 days to commit, silly
problems - 14 days to commit.
* no matter what source control to use, it is a must to be easy for
the maintainers to use it. The regular users will be able, with a
command described somewhere on the web, to get all the sources. The
"super-"users to send patches will able to find a way to do so no
matter what source control system will be chosen (also a command or
two on the webpages can help a lot in that regard).

Regards,
Edgar

-- 
Edgar Grimberg
System Developer
Zylin AS
ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html
Phone: (+47) 51 63 25 00

-- 
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: Switching to using git on eCosForge

[Alex Schuilenburg]

Sergei Gavrikov wrote on 2009-09-22 12:24:
> [...]
> and what do you think about Easy Git? Would you like observe these,
> please?
>
> http://www.gnome.org/~newren/eg/
> http://www.gnome.org/~newren/eg/documentation/
>
>   
Looks great and certainly helps simplify things.

It's perl, so should run on most systems, but how well does it really
run on Windows (cygwin or native perl) ;-)

/me ducks and runs

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


-- 
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: Switching to using git on eCosForge

[Sergei Organov]

Alex Schuilenburg <alexs@ecoscentric.com> writes:

> Sergei Organov wrote:
>> Alex Schuilenburg <alexs@ecoscentric.com> writes:
>> [...]

[...]

> However, I would point out again that all three borrow from the others,
> so evaluating is always going to be a moving target.

>>> You really don't want to force new users on an additional learning
>>> curve. There are 100's of commands to remember, whereas both bzr and
>>> hg have one.
>>
>> Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only
>> one as well: 'git' ;-)
>>
>> One does need additional learning curve switching from CVS to any of
>> DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again,
>> with git you can have gitcvsserver running to keep "CVS forever"
>> users happy with their favorite clients.
>>   
> % ls -l /usr/bin/git-* | wc -l
> 136
> %
>
> and I only have git-core installed on that machine...

You shouldn't be running them directly, and anyway now it is already
addressed:

$ git --version
git version 1.6.4.2.254.g99ccf
$ which git
~/git/bin/git
$ ls ~/git/bin
git            git-receive-pack  git-upload-archive  gitk
git-cvsserver  git-shell         git-upload-pack
$ 

Most of the 'git-*'  are now hidden in an out-of-your-path directory.

What I actually wanted to point out is that it was unfair to say that
git has hundreds of commands to remember whereas both bzr and hg have
one. The fact that one was allowed to say 'git-COMMAND' instead of 'git
COMMAND' does not in fact make number of commands different. I suspect
one needs to remember roughly the same amount of commands to perform
similar operations no matter which DVCS of the above is in use.

[...]

>>> Also, while documentation is improving (http://book.git-scm.com/), it is
>>> not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
>>> in terms of non-power users.  Both have books in print available from
>>> places like Amazon.
>>>     
>>
>> For me git's documentation was more than enough to have a quick-start.
>>   
>>> For example, I started my evaluation with bzr, then hg then git. bzr and
>>> hg were a lot easiest to pick up and start using than git.
>>>     
>>
>> I wonder, do you remember what the problem(s) with git was (were)? Care
>> to give an example where git is harder than any of the other two?
>>   
> I never said I had problems doing things in git - I said I had problems
> finding out how to do them. Tell me with a straight face that the number
> of options in some of the git commands did not overwhelm you the first
> time you saw them?

Well, no they did not, as I've already seen tar and diff manpages before
git. BTW, cvs diff has about 60 options and nobody cares.

IMHO, it's git's explicit staging area (aka index, aka cache) that makes
it different from others and maybe somewhat harder to get used to.
Selecting what to commit and actually committing are made to be two
separate actions. If it's worth additional complexity... I don't know.
However, it's not that difficult concept as it's semantically similar to
what one does in a GUI when selecting files to be included into the next
commit, then pushing the commit button.

> When you want to encourage community development, you really need to
> keep it simple for developers to keep abreast of advances and contribute
> back. Not have so many bells and whistles that they feel like they
> should not touch anything in case it breaks, or worse, have someone who
> thinks they know what they are doing but does not.

I just wanted to point out that git is not that hard to use that anybody
looking at it the first time should run away screaming! :-)

[...]

> Not entirely wrong ;-) When working with branches ever run "git
> submodule update" when you've made and committed changes within a
> submodule without checking out the branch first, only to discover
> later that the changes were silently overwritten?

No, I didn't, I didn't try to play with git submodules yet. However, I
doubt the data are actually lost if they were committed to the
submodule, really. One must be rather proficient in git to force it to
loose some data, but then he already knows what he is doing.

[...]

> However, I strongly disagree with your comment "hg already outlived its
> initial simple design..." though.  hg's design is just as simple as git
> and there is nothing in hg's design IMHO that limits what it can do. It
> is still evolving, just like git and eCos. The forests extension has
> been around just as long as sub-modules AFAIKT, but I admit it is taking
> a while for hg to make it part of their core functionality.

To be fair, I think the submodules in git are also rather unpolished
yet, as you've already got a chance to figure out.

And you are definitely right all these comparisons are moving target.

-- 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] JFFS2 Issue.

[Ramgopal Kota]

 Hi,

I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue.
In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below 

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

struct jffs2_unknown_node
{
  /* All start like this */
  jint16_t magic;
  jint16_t nodetype;
  jint32_t totlen; /* So we can skip over nodes we don't grok */
  jint32_t hdr_crc;
} __attribute__((packed));

I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER.

If I change the code to the following it is working fine...

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

marker.magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK);

I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag.
Compiler I am using is gcc version 3.2.1 (eCosCentric)

Thanks & Regards,
Ramgopal Kota

--
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: Switching to using git on eCosForge

[Ilija Kocho]

Edgar Grimberg wrote:
> Hi,
>
> My 2 cents on the topic:
>   
and another one from me
> * no matter what source control to use, it is a must to be easy for
> the maintainers to use it. The regular users will be able, with a
> command described somewhere on the web, to get all the sources.
I agree with this. Maintainers' time is valuable to all of us.

I have no preference over any of the 3 options, but I can note that 
almost all discussion is between git and hg, so as a fist step we can 
narrow choice between these two. Then, when emergency comes, we can 
throw a coin instead of dice.

Regards
Ilija


-- 
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] JFFS2 Issue.

[Ramgopal Kota]

Can some body help me ? I am worried as it may lead so many other issues in future .. 
Please let me know what could be reasons for this kind of behavior ??

Thanks & Regards,
Ramgopal Kota
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Ramgopal Kota
Sent: Tuesday, September 22, 2009 10:33 PM
To: eCos Discussion
Subject: [ECOS] JFFS2 Issue.

 Hi,

I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue.
In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below 

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

struct jffs2_unknown_node
{
  /* All start like this */
  jint16_t magic;
  jint16_t nodetype;
  jint32_t totlen; /* So we can skip over nodes we don't grok */
  jint32_t hdr_crc;
} __attribute__((packed));

I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER.

If I change the code to the following it is working fine...

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

marker.magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK);

I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag.
Compiler I am using is gcc version 3.2.1 (eCosCentric)

Thanks & Regards,
Ramgopal Kota

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




--
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] JFFS2 Issue.

[Jonathan Larmour]

Ramgopal Kota wrote:
>  Hi,
> 
> I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue.
> In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below 
> 
> struct jffs2_unknown_node marker = {
>       .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
>       .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
>       .totlen = cpu_to_je32(c->cleanmarker_size)
>     };
> 
> struct jffs2_unknown_node
> {
>   /* All start like this */
>   jint16_t magic;
>   jint16_t nodetype;
>   jint32_t totlen; /* So we can skip over nodes we don't grok */
>   jint32_t hdr_crc;
> } __attribute__((packed));
> 
> I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER.
> 
> If I change the code to the following it is working fine...
> 
> struct jffs2_unknown_node marker = {
>       .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
>       .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
>       .totlen = cpu_to_je32(c->cleanmarker_size)
>     };
> 
> marker.magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK);
> 
> I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag.
> Compiler I am using is gcc version 3.2.1 (eCosCentric)

I recommend you eCos 3.0 and the updated GNU tools instead (you can't 
really use the updated tools with eCos much before 3.0).

You should have got an error compiling JFFS2 due to this in src/fs-ecos.c:

#if (__GNUC__ == 3) && (__GNUC_MINOR__ == 2) && \
     (defined (__arm__) || defined (_mips))
#error This compiler is known to be broken. Please see:
#error "http://ecos.sourceware.org/ml/ecos-patches/2003-08/msg00006.html"
#endif


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

[ECOS] Re: Switching to using git on eCosForge

[Sergei Organov]

Sergei Gavrikov <sergei.gavrikov@gmail.com> writes:

> On Mon, Sep 21, 2009 at 05:05:20PM +0400, Sergei Organov wrote:
>> Alex Schuilenburg <alexs@ecoscentric.com> writes:
>> 
>> [...]
>> 
>> > Both bazaar and mercurial were a lot easier to learn and work with
>> > than git. git's Windows support is also limited and is mostly
>> > restricted to the 100's of cmd apps which make up git under cygwin.
>> 
>> Once again, I'm not a Windows user, but is this really true nowadays?
>> 
>> E.g., what about this one:
>> 
>> <http://code.google.com/p/tortoisegit/>
>> 
>> Isn't it good enough for Windows users?
>  
> There are many tortoises there: Tortoise{SVN,Hg,Bzr,Git,...}

Yeah, that was my argument: all of them probably have roughly the same
functionality. Isn't it what Windows users actually use? If they do,
then git should be not worse than others in this area.

-- 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] Re: Switching to using git on eCosForge

[Sergei Gavrikov]

On Mon, Sep 21, 2009 at 05:05:20PM +0400, Sergei Organov wrote:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
> 
> [...]
> 
> > Both bazaar and mercurial were a lot easier to learn and work with
> > than git. git's Windows support is also limited and is mostly
> > restricted to the 100's of cmd apps which make up git under cygwin.
> 
> Once again, I'm not a Windows user, but is this really true nowadays?
> 
> E.g., what about this one:
> 
> <http://code.google.com/p/tortoisegit/>
> 
> Isn't it good enough for Windows users?
 
There are many tortoises there: Tortoise{SVN,Hg,Bzr,Git,...}

http://bitbucket.org/tortoisehg/stable/wiki/Home
http://bazaar-vcs.org/TortoiseBzr

In any case they won't use PowerShell :-)

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: Switching to using git on eCosForge

[Sergei Organov]

Alex Schuilenburg <alexs@ecoscentric.com> writes:

[...]

> Both bazaar and mercurial were a lot easier to learn and work with
> than git. git's Windows support is also limited and is mostly
> restricted to the 100's of cmd apps which make up git under cygwin.

Once again, I'm not a Windows user, but is this really true nowadays?

E.g., what about this one:

<http://code.google.com/p/tortoisegit/>

Isn't it good enough for Windows users?

-- 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] Re: Switching to using git on eCosForge

[Patrick Doyle]

On Thu, Sep 17, 2009 at 10:23 AM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
> On 2009-09-17, ??yvind Harboe <oyvind.harboe@zylin.com> wrote:
>> + git is becoming more of a required skill for embedded development
>> as Linux requires it,
>
> Can you explain how "Linux requires it"?  I've been using Linux
> for almost 15 years now (including some embedded Linux stuff),
> and have no clue how to use git.


Why it's quite simple, actually...

Linus Torvalds invented Linux.

Linus Torvalds invented git.

Therefore, git == Linux

:-)

--wpd

--
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: Switching to using git on eCosForge

[Ross Younger]

> On 2009-09-17, ??yvind Harboe <oyvind.harboe@zylin.com> wrote:
>> + git is becoming more of a required skill for embedded development
>> as Linux requires it,

Grant Edwards wrote:
> Can you explain how "Linux requires it"?  

The Linux kernel source tree has been managed with git - pretty exclusively,
I think - for a handful of years now. It really comes into its own with the
various teams working on their own subtrees.

Torvalds himself designed and wrote the initial version of git following the
BitKeeper debacle and given the then-current state of the art; it has then
evolved into a fully-featured DRCS, but with a slightly different world-view
to hg and bzr.


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  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: Switching to using git on eCosForge

[Grant Edwards]

On 2009-09-17, ??yvind Harboe <oyvind.harboe@zylin.com> wrote:

> + git is becoming more of a required skill for embedded development
> as Linux requires it,

Can you explain how "Linux requires it"?  I've been using Linux
for almost 15 years now (including some embedded Linux stuff),
and have no clue how to use git.

-- 
Grant Edwards                   grante             Yow! Now KEN and BARBIE
                                  at               are PERMANENTLY ADDICTED to
                               visi.com            MIND-ALTERING DRUGS ...


-- 
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: Switching to using git on eCosForge

[Sergei Organov]

Alex Schuilenburg <alexs@ecoscentric.com> writes:
> Øyvind Harboe wrote on 2009-09-17 11:52:
>> Does anyone know a reason not to switch to git for eCosForge?
>>
>> My thinking is to use http://repo.or.cz/ to host projects.
>>
>> www.ecosforge.net uses a version of subversion that is getting
>> a bit long in the tooth (1.4) and I'm just wondering if
>> git isn't a better choice anyway....
>>
>> The plan is to leave the current subversion repository as-is and
>> let migration happen  eventually, deleting old repositories(they
>> are still there in the history) after migration to git.
>>
>> The idea is to have one git repository per eCos repository(or
>> project if you will).
>>
>> The first project I would like to switch to git, is nios2ecos.
>
> Why git in particular?

Because it's simply the best? ;-)

> We have started looking at switching to another RCS at eCosCentric as
> well.  In particular I looked at three distributed RCS solutions: git,
> bazaar and mercurial.  While there is no doubt that git is the most
> powerful of the three solutions and also fastest on linux, it is also
> the most complex of the three solutions with a very steep initial
> learning curve, it's support for windows is lacking, and its
> documentation is sparse and confusing.  As a tool for experienced Linux
> developers, sure, git is the best choice.  But for the average eCos
> developer,  I am not convinced.

Did you see this:

<http://code.google.com/p/msysgit/>

(I'm not Windows user, so didn't use it myself).

BTW, git has gitcvsserver:

<http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html>

so those who are used to CVS and don't wish to learn new tool can
continue to use their favorite CVS clients.

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