From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 656 invoked by alias); 18 Mar 2010 00:02:36 -0000 Received: (qmail 32750 invoked by uid 22791); 18 Mar 2010 00:02:34 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Mar 2010 00:02:28 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 7A4882F7800D; Thu, 18 Mar 2010 00:02:26 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ0XCMM1KEN5; Thu, 18 Mar 2010 00:02:19 +0000 (GMT) Message-ID: <4BA16D90.1090003@ecoscentric.com> Date: Thu, 18 Mar 2010 00:02:00 -0000 From: Alex Schuilenburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: eCos Discussion CC: eCos Maintainers Subject: Re: [ECOS] Replacing CVS - decision time References: <4B9ACE82.4040805@jifvik.org> In-Reply-To: <4B9ACE82.4040805@jifvik.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2010-03/txt/msg00020.txt.bz2 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 > 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 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 ** ** 27-29 April 2010, Booth 640, San Jose McEnery Convention Center **