public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Alex Schuilenburg <alexs@ecoscentric.com>
To: "Øyvind Harboe" <oyvind.harboe@zylin.com>
Cc: eCos Disuss <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Eclipse support for git
Date: Tue, 22 Sep 2009 11:41:00 -0000	[thread overview]
Message-ID: <4AB8B7D9.8080106@ecoscentric.com> (raw)
In-Reply-To: <c09652430909220133o4c776decie1ca3f13f4bc16dc@mail.gmail.com>

Øyvind Harboe wrote on 2009-09-22 09:33:
> I think it is important when choosing the next version control
> system to think about whether we're getting onto the right
> train.
>
> The support today is important, yes, but what happens
> 2-3 years from now?
>
> I'm confident that git will receive *plenty* of attention from
> GUI makers as the user base continues to expand due
> to the killer references that git has.
>
> Eclipse support anyone?
>
> http://www.eclipse.org/proposals/egit/
>   
but just as git closes the gap wrt GUI support, hg will close the gap
wrt functionality...

You cannot make assumptions based on a moving target or what development
is likely to occur in one camp without considering the same for the
others.  Also, just because git is right for linux does not mean it is
right for eCos.  As for killer app, exactly how much of that
functionality will be used by the average Joe? 5%, 10%?  And the average
full time user? 50%, 60%?  From what I can tell wrt git, if Linus wants
to do something that git cannot do with a couple of simple commands,
Linus just goes and writes another command for that. Not that this is a
bad thing, just that for the average Joe it is another command/option
that is thrown into the mix. I believe in the KISS principle when it
comes to considering the needs of the masses and am not a great fan of
feature-bloat.

Of course we could always make a political decision and choose bazaar
because it is a GNU project.  I know of at least one project that was
forced to do so by RMS for that very reason... 

Anyway, the great thing about all of these DRCS systems is that, if
there ever is a clear winner, their designs are so similar, migration
from one to the other in theory should be very simple.  All these
systems have export/import functionality for this specific purpose.

So if we want to move to a DRCS, I suggest we do it sooner rather than
later or wait another year or so to see if there is a new DRCS leader or
someone comes up with a MDDRCS  (multi-dimensional distributed ...) or
new flavour of the month.

FWIW, Mercurial already has Eclipse support for a couple of years now:
  http://www.vectrace.com/mercurialeclipse/

Finally, dont get me wrong.  From my perspective I would like to see the
right technical choice being made for a DRCS for eCos, or for anything
else added to eCos.  If that turns out to be git, then great, I will use
it with pleasure.  If the technical evaluation comes up with little
differences between the choices, the evaluation should then look to
usability, documentation, testing, support, usage, etc.  In my own
evaluation of DRCS, this is where I see differences in many directions. 
Some favour git, some favour hg.

The hard part is deciding which differences really matter, so I am glad
I am not the one actually making the final choice.  I personally agree
with the author of this evaluation's summarising comments:
 
https://ldn.linuxfoundation.org/article/dvcs-roundup-one-system-rule-them-all-part-2

Namely:
If you really want a direct recommendation, it would be thus: download
Git and Mercurial, then throw dice. Personally I like the “it just
works” approach of Mercurial a bit better, and the fact that it is
written in Python. Also for cross-platform projects needing Windows
support Mercurial is (at this moment) probably a tiny bit less
problematic. If you work in a completely UNIX-centered environment, Git
might be the slightly better choice. However, both systems work very
well, are stable and very, very fast. So it's a tie, more or less."

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

  reply	other threads:[~2009-09-22 11:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-22  8:33 Øyvind Harboe
2009-09-22 11:41 ` Alex Schuilenburg [this message]
2009-09-22 11:47   ` Øyvind Harboe
2009-09-22 20:08   ` Jonathan Larmour
2009-09-23 10:09     ` [ECOS] " Sergei Organov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AB8B7D9.8080106@ecoscentric.com \
    --to=alexs@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=oyvind.harboe@zylin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).