Re: [ECOS] Switching to using git on eCosForge

[Alex Schuilenburg <alexs at ecoscentric dot com>]

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

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.

The choice of an alternative RCS should also take into consideration
Windows users, as well as speed and ease of use.  When it came down to
it, I found mercurial only to be marginally slower than git, but far
better documented, easier to learn, and with much better support on
Windows platforms. Bazaar was slower than mercurial and also was not as
well documented, although Windows support was pretty much the same as
mercurial.  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.
Bazaar and mercurial are native windows apps, so speed comparisons
worked in their favour on Windows.

I intend to do a more formal evaluation of all three, also drawing in
user's experiences from the web, which I will be happy to write up here
when complete if people think it is worthwhile.  The topic of ecos
switching to another RCS has already been raised once before and nothing
much came of this so I am offering a proper evaluation of pros and cons
before a choice is made, for a proposal for an anoncvs alternative RCS
solution anyway.

Anyway, I should point out that all three DRCS appear to have tools that
allow for the migration and/or import/export of changesets between them,
so in theory any choice on what anyone uses in-house can be left to
personal preference regardless of what the main repository is. I cannot
speak for these tools, other than to say I have tried to import our
internal CVS repository and anoncvs into all three and not one of them
worked.  git did the worst job, followed by bazaar then mercurial. And
yes, I have tried cvs2svn to go via svn as well :-(

However, more worryingly these attempted imports showed that both our
and the anoncvs CVS respositories are corrupt, which is probably why the
imports failed so badly using the automated tools.  Any attempted
conversion of anoncvs is going to need a fair amount of effort by
someone. That said, I should point out that I am in the process of
developing/converting our own repository using a modified cvsps 2.2beta
that can fix most of the corruption in conjunction with a perl script
which fixes the rest, so may end up with a tool which correctly converts
anoncvs (i.e. preserving all check-in states, tags and history) to
whatever with little human effort.

Don't panic though, checking out current anoncvs always works.  Just do
not rely on tags and branches.  Checkouts made at the same time as tags
were made have shown several files that were missed being tagged, making
what was actually distributed differ from what was tagged, and files
missing from branches.  As an early example, checkout the
ecos-v2_0-branch just after it was made and observe that doc/Changelog
is missing, even though it was present in the trunk when the branch was
made.  This is just one case of 100's

However, I suspect your switch from svn to whatever will be fairly
simple.  The import/export tools do a fine job on most simple repositories.

HTH

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