This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Replacing CVS - decision time: part 2
- From: Jonathan Larmour <jifl at jifvik dot org>
- To: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Wed, 28 Apr 2010 14:55:54 +0100
- Subject: [ECOS] Replacing CVS - decision time: part 2
After the previous discussion, I felt the only way to get real clarity
on remaining sticking points, is to actually try out mercurial and git
on Windows - given the past discussion, particularly to exercise git. I
have spent some time now on Windows (for my sins) trying out hg and git,
both in command line form and via some of the GUI interfaces. Again,
personal bandwidth (especially due to easter holidays) intervened and it
took a while to do.
While it's true that the most important thing is for the maintainers to
be comfortable with the VCS, this isn't an overriding consideration - I
also think it's very important for users, and more importantly
(potential) contributors, to be using something that is good quality,
not overly complex, easy to pick up for the most common use-cases, and
fits with their own development requirements. Whatever we choose will be
what most of them will use themselves. And whatever anyone thinks about
*nix versus Windows, it's a known fact that the clear majority of eCos
users use Windows for day-to-day development. That's why this
investigation is important.
In trying them out, I've also been trying out both in rather less
straightforward situations than I did before too.
On Windows, mercurial or git could be cygwin or native; I tried out
cygwin in both cases, but for git I also tried out msysgit which is its
native version (which includes GitGUI as well as gitk). I also tried the
Tortoise interfaces for both. I happened to be using Vista, which is a
complete PITA unsurprisingly, but that affects both equally. All the
versions used, including cygwin, are the latest stable released versions
(not counting the fact that all msysgit releases call themselves "preview").
One of the first things I did, to be representative, was to convert
eCoscentric's public hg mirror to git using hg-git. That way I could
operate on appropriate data reflecting the size of the eCos repository.
I initially tried converting it on windows. That was a mistake. It took
hours and repeatedly failed (whinging about checksum errors). Instead I
was able to do it completely successfully on Linux and copy it over to
the windows machine verbatim, without any problems.
Anyway, here are my resulting impressions after experimentation:
- Cygwin git is indeed fairly slow - subjectively it feels slightly
slower than cygwin hg (perhaps because it tends to move whole blobs and
therefore more data around, and I/O is something cygwin is bad at?). I
wasn't able to quantify this, but suffice to say that they're roughly
comparable for most small operations. That said, a git clone of the
whole ecos repo was 40s faster on my machine, although 40s isn't much
really.
- Cygwin git was occasionally (rarely) unreliable and just crapped out
with an exception, although to be fair that could be cygwin.
- As Alex/Oyvind reported, cygwin git+ssh is broken - appears to xfer
objects but then says "The remote end hung up unexpectedly" and aborts.
I did check, and cygwin hg works fine with ssh, so the problem is
specific to git. This is quite a serious problem if we had any
contributors on windows and we wanted them to be able to push directly.
- Despite what Alex said, msysgit did seem to generally work
(v1.7.0.2-preview20100309 at least). However, you can't really share it
with cygwin.
- In general I found my experience of git on Windows was that I was left
feeling frustrated (not all of that was specific to the fact it was on
Windows!). Some things were far harder than they should have been to
discover. The man pages would definitely be confusing for many - they
are filled with odd terminology, opaque nomenclature and jargon, e.g.
"Porcelain commands" and "alternative porcelains" and many git-specific
concepts which are only understandable once you already know git, like
what it means by "index" or the staging area, refs, etc. The man pages
are the only real form of git documentation directly supplied, and if
they were confusing to me, it's not a good sign for others. Non-native
english speakers would have even more trouble.
So quite often when I was having difficulty, I was having trouble
finding answers. Such as the syntax of git repositories accessed via
git-daemon, if I want to push to them using an absolute path.
I often found other people also had the same difficulties and confusion
as to how to do something, and I was repeatedly finding answers at
StackOverflow fortunately. But if git users have to rely on sites like
StackOverflow to get answers, I don't think that is a good thing :-/.
- To serve on hg, it's just hg serve. With git it's hard to find out how
at first, and then according to
http://stackoverflow.com/questions/377213/git-serve-i-would-like-it-that-simple
it's:
git daemon --reuseaddr --base-path=. --export-all --verbose
then after subsequent mysterious grief I find out it needs to be
git daemon --reuseaddr --base-path=. --export-all --verbose
--enable=receive-pack
otherwise pushes don't work (although I've found out there are security
caveats with this form too, so to do it really properly you have to do
something more complicated than that).
Yes, there is some documentation for git-daemon buried in the man pages,
but under the "internal plumbing" section which I wouldn't have
expected, and it certainly doesn't describe the significance of
--enable=receive-pack or what it means (yes I know now).
- While having 'git cherry' should be useful, showing only the sha1
commit ids as output is a terrible UI choice - I suspect it reflects the
desire of git to be a toolkit which can be munged by shell scripts. 'hg
outgoing' is much better as it's more descriptive.
- TortoiseGit has definite rough edges (signs of it being work in
progress), and some operations such as obtaining log messages take an
unexpectedly long time.
- I could not get TortoiseGit's Stash save and pop to work properly - it
kept claiming the tree was dirty while also claiming there were no
differences, no matter how many times I rescanned.
- Msysgit's Git GUI is not bad if you already happy with git
terminology, concepts, and expected workflow, otherwise it may be confusing.
TortoiseHg has Repository Explorer, which IMHO uses less obtuse terminology.
- TortoiseHg relies more on repository explorer for operations, rather
than being able to choose operations directly in the context menu.
Although the most common operations are there. TortoiseGit has a long
list of operations directly in the context menu. In the context menu is
arguably more efficient, although the list is quite long. In a separate
application is arguably better structured and may lead to better
workflow (as you may be doing more than a single operation), but
slightly less efficient.
- gitk is good, as is the hg repository browser equivalent - no real
difference either way. Repository explorer is essentially equivalent to
a mixture of gitk and git gui, rather than having them as separate tools.
- TortoiseGit does make it straightforward to do dangerous things which
lose history. Maybe for some people this is a glass half full thing.
- TortoiseHg's "annotate" (same as blame) shows you which revision is
associated with which line, and although you can click or hover over a
line to see who did it (rather than just the revision number) you have
to right click the menu headings to see the user in the normal way. Not
a big deal, but they don't make it clear.
- A big issue to me is that msysgit's Git Gui appears to *automatically*
(i.e. without asking) convert an almost random subset of files from LF
to CRLF line endings, even when those files weren't modified by the user.
This may affect either the contributions we get from windows users, or
the ease which windows users can make contributions. Now this probably
came about for me because at installation time you have to set it up
with either:
1) checkout windows line endings, commit unix; or
2) checkout as-is and commit unix; or
3) checkout as-is and commit as-is
For my testing, I chose the default of (1) which is also the
"recommended setting on windows for cross-platform projects". That's
what I assume most people would do because it's the default and it's
recommended for our situation. (2) would probably in fact have been the
better option, but unfortunately, once installed, there seems to be no
way to change things (except by uninstalling and reinstalling which is
rather lame). It's still no excuse really for converting some files
without asking or prompting.
Unlike the equivalent hg extension for crlf/lf management, there are no
per-file or file extension overrides I could see in msysgit.
Cygwin git will treat everything equivalent to (3) above. There's a risk
that CRLFs may get introduced if someone uses an editor which doesn't
treat the file as having only LFs. It's certainly more likely for newly
created files, such as in new ports. Stripping these out would be more
pain for the contributors and/or the handling maintainer (if they even
remembers at the time).
- GitGUI seemed to make a lot of other change noise too, not just CRLF
conversion, but also changing file modes. It would be a pain for people
to have to keep working around this sort of noise.
- I experimented, and unlike what I had been informed before, I could
not reliably make git determine file parents from partial file matches.
Only renames, or renames with relatively minor mods (with high
similarity scores according to git). Doing things like splitting up a
file may lose parentage (whereas in hg, you can do an hg copy first, and
then cut down each file, and then the link to the parent is maintained).
I guess people will now be able to pick up a vibe about my feelings on
git versus hg now that I've finished this experimentation :-/, but I'm
trying to still present my observations straightforwardly.
Nevertheless, once anyone wants to comment on anything above, then the
maintainers should get on and decide. Unless someone suggests something
specific, I doubt I'll be doing any more investigative analysis.
Jifl
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss