Re: [ECOS] Replacing CVS - decision time

[Alex Schuilenburg <alexs@ecoscentric.com>]

Hi Jifl

Thanks for an excellent analysis. Just to add a few of my own and
correct a couple of points:

Jonathan Larmour wrote:
> [...]
>
> One thing people highlight as an advantage of git is that it has a staging
> area (other VCS's hide this), which is an extra place for code changes
> between your working directory and what's properly committed in the
> repository. This way changes can be collated before being pushed. But hg
> has an equally powerful extension to achieve the same thing, which are
> Mercurial Queues (sometimes aka patch queues).
>
> Similarly, git has the much lauded bisect; but hg has that now too. As
> noted in the past, this is an example of good ideas often being copied
> between the two.
>   
Over the years, every useful functionality implemented by one has been
incorporated by the other.  The normal argument between the two is who
thought of it first (e.g. mq/staging area, forest/modules, etc etc),
which is why there is actually little or no CLI functional advantage of
one over the other IMHO.

So the choice really has to come down to ease of use, documentation and
cross-platform support IMO.


> [...]
> * Windows support
>
> git and hg both store in binary form. If you check in with CRLF
> line-endings that's what you get out, irrespective of host OS. Ditto LF
> endings. That said, hg has a win32text plugin to perform line-ending
> transformations on files automatically on checkout/commit.
>
> It is only recently that git has broken free of its cygwin dependency with
> msysgit (based on mingw). But while the cygwin version was direly slow,
> msysgit is reportedly faster, but still not as fast as hg on windows. It's
> clear though that the the main git developers are very much more focussed
> on linux, and hardly at all on windows.
>   
It is the lack of decent and stable Windows support that should be the
killer reason for not chosing git IMO.  Sure, it may get fixed sometime
in the future, but when?  And when it breaks, there usually is very
little impetus to fix it.  I believe if git is chosen by the
maintainers, you will inhibit the ~70% of eCos developers who use
Windows hosts (according to the various official surveys) from
contribution or co-operation.

While most of, if not all, the eCos maintainers use Linux as their
development platform of choice, I would be disappointed if the reason
they chose git was because of their familiarity with it and git's ties
to Linux and Linus. Switching to DRCS is not just about making life
easier for the maintainers.  It is about sharing development and making
life easier for anyone who uses RCS in their work. It is about allowing
eCos to become a proper part (module) of their project so that simple
pulls and updates brings in the latest set of changes into their
projects. It is about making it easy for people to contribute back.  It
is about making it easy for people to maintain their own local changes
which they may never push upstream (although we obviously would want to
encourage them to do so).

But back to Windows support.  The most recent version of msysgit is
broken (at least on my Windows 7 machine), and Oyvind reports 1.7 cygwin
git support for ssh to be broken.  QED IMO.


> * Front-ends
>
> Git has an eclipse plugin (EGit), although it is still in the incubation
> phase and while usable is still under development AFAICT. It isn't mature
> certainly.
>
> Mercurial has an eclipse plugin which has been around a while longer. In
> fact it has multiple ones!
>
> There is TortoiseGit and TortoiseHG for windows users, for Explorer
> integration. Again TortoiseGit is quite new and therefore possibly not so
> mature. Git windows users can also use Git-Cheetah for Explorer
> integration which is definitely work-in-progress at the moment, and Git
> Extensions. 
You are being too kind here IMHO.  TortoiseHg is miles ahead of
TortoiseGit in terms of stability.  I never have had a problem with
TortoiseHg.  I had to reinstall the most current version of TortoiseGit
1.3.6.0 just to get it working.

> I haven't determined if all these can work with msysgit, or
> just the slower cygwin-based git.
>   
TortoiseGit 1.3.6.0 only works with msysgit 1.6.1 and above.

[...]
> * Documentation
>
> Documentation of mercurial is excellent. There's an O'Reilly book, both
> published and online: http://hgbook.red-bean.com/ The interactive help,
> the man pages, and most importantly the online resources are clear and
> copious. There are good newbie guides such as
> <http://hginit.com/index.html> and others. I get the feeling that a better
> structured approach to hg's design has led to a clearer structure for
> documentation.
>
> A frequent criticism of git that keeps on coming up is the quality of its
> documentation. They are fairly sparse and often confusing. Personally I
> found even the recommended tutorials such as http://book.git-scm.com/ to
> be unsatisfactory, at least when putting myself in the mind of a newbie.
> (Note that despite "book" in the URL, AFAIK there is no actual git book,
> not yet anyway).
Actually, there is a git nutshell book: "Version Control with Git:
Powerful tools and techniques for collaborative software development" by
Jon Loeliger
<http://www.amazon.co.uk/exec/obidos/search-handle-url/ref=ntt_athr_dp_sr_1?_encoding=UTF8&search-type=ss&index=books-uk&field-author=Jon%20Loeliger>which
is not too bad. I had a brief skim through a while back.  Fairly
technical though covering some fairly advanced features, many of which
will never be used in most user's lifetimes. It also points out traps
and dangers, which is pretty useful. Even hg has a couple, one of which
I fell into fairly recently ;-)

IMHO the hg book is better though, especially when introducing DRCS and
helping CVS users to switch.

[...]
> * Tags/Branches
>
> Mercurial tags intially sound unsual as they work by storing everything in
> a top level .hgtags file which is treated specially, but the purpose of
> that is so that the tags are clearly versioned, which is a positive thing,
> and I haven't noticed any problems from it. There are only two unexpected
> (but not problematic) effects firstly that sometimes you have to merge the
> .hgtags list, but that's straightforward since you almost always just want
> the union of the sets of tags. Secondly, because the tags list is
> versioned, if you update to a tag, you appear to get a .hgtags which
> doesn't include the tag you updated to (because when that tag was made, it
> moved the head on by one revision, past the tag point). But the output of
> hg tags is unambiguous, so again this doesn't seem an issue.
>   
hg's file approach of storing tags also means that renaming or deleting
tags in hg is pretty darn easy :-)

-- Alex Schuilenburg
Managing Director/CEO                                eCosCentric Limited
  
  ** Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
  ** 27-29 April 2010, Booth 640, San Jose McEnery Convention Center **