This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Replacing CVS - decision time


There has been a _lot_ of discussion over the last couple of years about
replacing CVS with something better now that there are many alternatives.
I know there's been a lot because I've just had to read all of it!

It's time to bring discussion to a close and make a choice of which
version control system (VCS) to use for eCos instead of CVS. This mail is
an attempt to draw a line under previous discussion and provide some
information to help towards a decision. From reviewing previous
discussion, although there are many to choose from, there had been talk of
choosing between Bazaar (bzr), Git, Mercurial (HG), or Subversion (svn).
As you'll see below, I think really it's a case of deciding between git
and mercurial.

As well as reading past discussions, and playing with both tools, I've
been reading some of the many resources out there from people who've done
the same, because it's hard to distinguish all the differences from just
playing. Here's a few notable ones (although I've read more), and I
recommend people have a look, although beware as some cited differences
have been overtaken by subsequent development:

https://ldn.linuxfoundation.org/article/dvcs-roundup-one-system-rule-them-all-part-2
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
http://code.google.com/p/support/wiki/DVCSAnalysis
http://mercurial.selenic.com/wiki/GitConcepts

The conclusion of most of these are that there aren't significant
differences in functionality between hg and git. But that doesn't mean
there are no differences, and the importance of the differences can vary
from person to person. Therefore I'm going to try to avoid giving
prescriptive requirements. Instead in this mail I'm going to try and
highlight the pros/cons as I've seen them. Sorry this is going to be long.
If I've missed any really useful features that one VCS has that the others
don't, please follow up - it wouldn't be possible for my analysis to cover
absolutely everything.

One thing I should be clear about as it was suggested in the past: there
won't be a vote. The people who the decision affects most are the eCos
maintainers, so that's where the final decision rests. That being said, we
still very much welcome comments, in order to inform the decision. In
particular, I would be interested to hear answers to these questions:
- For git advocates, if we chose hg, why would you be upset?
- For hg advocates, if we chose git, why would you be upset?

In both cases, we can take it as read that one reason would be "Because we
know it, and not the other" :-). I'm interested in other reasons.

However the discussion and decision goes, I realise that each VCS has
fervent believers with sometimes very strongly held views. Some proponents
may end up not being satisfied, but sometimes that's just the way it has
to be.


* Subversion + Bazaar

 From reviewing discussion, there seems to be no appetite for subversion
as it is not distributed and has a long list of limitations compared to
the others. It's true a distributed VCS (DVCS) is a more alien model to
the way CVS worked, and intrinsic to that is a step up in the technical
level needed to drive it, regardless of the VCS choice. But the features
of being distributed such as changeset management and tracking, offline
use, ease of dissemination to/by third parties, are just too valuable.

Bazaar also seemed to be a minority choice, and it's considered slow
compared to the others - sometimes 5-10 times slower from what some have
said. There are reports (such as from the linuxfoundation.org link above)
of poor merge workflow. Anecdotally various people who've used both bzr
and hg have considered hg more usable). bzr does not have nearly as much
developer momentum as git/hg. Some said it was not well documented.
Repositories were larger with bzr than hg (factor of two-ish). Richard
Stallman likes bzr and imposed it on some projects, who wanted to use hg
instead, which isn't a good sign.

Therefore I'm eliminating both svn and bzr now. So now looking just at git
and hg....

* Users

I think there are three approximate main user groups to be considering.
These are intentional stereotypes. You, dear reader, may fit one category,
but we have to consider them all.

First are people who just want to get the eCos development tree and use
it. A tarball would almost be good enough, but there are advantages to
being able to update from the master sources. They don't really edit the
sources.

The second group are contributors. They edit and extend the eCos sources,
in a local repository. They need a way to be able to submit patches in
useful formats to make reviewing and applying them easier. Both git and hg
have 'patchbomb' abilities and can generate distinct patch files based on
changesets, which means they're grouped by actual change rather than just
the files. There are advantages (because of SHA1 ids) for patches to have
been generated by the (same) VCS, rather than by hand.

The last group are of course the maintainers. They need everything :-).

As mentioned, it's the maintainers who are the ones who are likely to be
most involved in the areas where git and hg do differ in functionality.
But not all of us will become git or mercurial whizzes, and we shouldn't
need to be - it's important that we can't cock up the repository,
especially in the early days. It's also very possible we will widen
checkin access to prolific contributors (even if it's only after
approval), like many other projects. But that's a different discussion.

* Overview

git and hg are similar, and were even created for the same reason - for
Linux kernel development, although Linus's own git was (unsurprisingly)
chosen by him. Lots of the momentum with git comes from that. And also the
specific requirements of the linux kernel developers, and their
development workflow, is the strong focus of the git developers. That can
be considered as positive or negative!

hg depends on python, git depends on perl and various shell utilities.
Both have speed-critical components compiled from C.

There is one difference which is fundamental but makes far less visible
difference than you might think in practice, which is that mercurial
manages changesets, whereas git takes whole file snapshots. It's been said
that hg manages files wheras git manages the contents of files as it tries
to analyse and compare changes within files (using what can be considered
either clever magic or guesswork).

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.

* Ongoing development

As well as the Linux kernel, many projects use git
(<http://en.wikipedia.org/wiki/Git_%28software%29#Projects_using_Git>)
although there's a very clear slant towards "linux system" projects. hg
also has many major projects using it
(<http://mercurial.selenic.com/wiki/ProjectsUsingMercurial>), and is
definitely here to stay.

Both have continuously been improving, and comparing features is a moving
target (hence lots of stale data in comparisons on the net). That being
said, sourceware runs both mercurial and git, and are both very well used.
I have observed from the sourceware overseers list that git seems to
frequently need updating to deal with bugs and problems :-/. This may mean
that stability can be an issue with git.

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

* 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. I haven't determined if all these can work with msysgit, or
just the slower cygwin-based git.

FAOD, git is bundled with gitk, but that is a repository viewer only, not
a front-end.

A list of front-ends and tools for git can be found here:
<http://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools> As
can be seen in a table at that page, most of them have limited
functionality (which may be a good or a bad thing!).

And for mercurial, here: http://mercurial.selenic.com/wiki/OtherTools

* Ease of use

Clearly the VCS should be a solution, not a problem.

Git is widely considered to have a noticeable learning curve. The general
consensus is that git is more a power user's tool than hg. Not that it can
necessarily do much more than hg, but that the git command set includes a
wide variety of tools, each one catering for a niche task. My
/usr/libexec/git-core lists no less than 138 commands (ok, a few of them
are maybe back-end not front-end commands but only a few). In some cases
you can do things in one line, that would take multiple steps in hg. The
flip side is, of course, increased complexity, with such a potentially
bewildering number of commands available. And within each of those
commands, many options are available. If you type 'git' you do at least
get a list of only the most common commands, but getting help on
individual commands can quickly drown you in pages of jargon.

hg works in IMHO a more tractable way, by using plugins. So the basic 'hg'
has a much cleaner set of commands shown by default, which makes it more
modular and less confusing for users who don't need advanced features. To
be clear, these aren't all third-party addons either, mercurial is bundled
with many of the plugins by default but they aren't enabled until the user
requests it. And as they are plugins, individual commands have fewer
options - they are extended with extra options only when the plugin is
enabled. Of course the flip side is that once you are starting to look for
more advanced operations you need to be aware of what the plugins can
provide. It's slightly easier (than git) to see analogies between hg
operations and good ol' CVS commands.

git gives you a lot of rope to hang yourself. You can even lose history
which is very bad, e.g. git push --force or git reset --hard. You would
think that the --force and to a lesser extent --hard may be a hint not to
do this, but some doc/recipes out there include these, so if a newbie
blindly copied... ouch. It shouldn't be that easy to lose history, and hg
is meant to be stricter about that. For more on this see comments from
Werner Punz (a git fan!) near the bottom of
http://code.google.com/p/support/wiki/DVCSAnalysis posted on Jul 24th 2009
and after. A choice quote:
-=-=-=-=-=-=-=-=-=-=-=-=-=-
Some things [in] git are outright dangerous and even users who have been
using git for some time might fall over it. Here is an example, everyone
and even the semi official git book on the net says that reverting like in
SVN should be done with git reset --hard, while this is somewhat true but
the git reset operation alters history which is a bigger problem once you
have pushed your changes (and the next user pulling your data in or you
yourself having to fight with the revlog if you have done an accidental
reset will agree)!

Better checkout, but then if you checkout the wrong way (by forgetting a
file or directory directive) you will automatically get a floating head
and users suddenly will start to hack into the floating head. Git simply
makes assumptions without telling you and the only way to find out is by
rechecking out the master or finding the line in the man page describing it!
-=-=-=-=-=-=-=-=-=-=-=-=-=-

I think Alex on ecos-discuss in the past had a plausible analogy with
cars: hg is a reliable car that will get you where you're going in
comfort; git is a hot rod that's harder to control and needs more
maintenance, but works really well when you do.... that is until you find
yourself in a ditch.

There will be a learning curve for users regardless of VCS, particularly
with a move to a distributed model. But the risk is that the bar will be
set that much higher for users with a difficult-to-install or
difficult-to-understand VCS. And if that's the case then that means
raising the bar in a negative way for both users and potential future
contributors. Not everyone is a hard-code hacker - many are far from it.
Front-ends like Tortoise or Eclipse plugins sort-of ameliorate the command
line issue, but a lot of the same concepts, and the complexities arising
from them, are exposed still fairly directly in the UIs (and if they
weren't, the UIs would arguably not be exposing enough git functionality).

One thing in favour of git is its use with Linux, which means that some
people will already be familiar with it - there's no learning curve if you
don't have to learn it. (Although of course, the "familiarity" argument
may be able to used nearly as much with hg). But it's not clear to me that
with the odd unusual exception, there are that many people working on both
eCos and linux simultaneously, and for those that are, a smaller
proportion still would be working _directly_ with upstream git repos.
Altogether, I think the number of people who would work on both eCos and
linux kernel git trees may be very small compared to the number of eCos
users as a whole.

A side-effect of git's focus on performance, is that as you use it, it
consumes increasing amounts of disk space. As a result, repositories need
occasional repacking (maybe "need" is overstating it as it keeps on
working, it just consumes more and more disk space). The repacking is a
manual command, and it compresses objects, generating deltas and places
them into a single large file. It's undesirable that user's will need to
have to deal with periodic maintenance.

git can only refer to changsesets by SHA1 key (or a unique substring). hg
can do that but also has a concept of a _local_ incremental change number
which is both shorter and easier to handle mentally. It may seem a minor
thing, but I think referring to things by number is a lot easier than a
hash. On the positive side for git, you can compare against versions
relative to the head e.g. HEAD~4, which mercurial can't do - you need to
find the number first. Of course that assumes you know for sure exactly
the number of changes you want to refer to and being relative to the
latest commit could be a gotcha. Both hg and git can also refer to commits
by dates of course, which is less ambiguous.

My own experience with playing is that I indeed found git's structure and
terminology harder to get to grips with, compared to mercurial (and I
tried it after mercurial, so it wasn't just unfamiliarity with DVCS's). I
can cope, but I'm not sure about others. Just my opinion.

* External interfaces

They both can do repository operations over ssh tunnels, and also over
HTTP. hg also supports HTTPS. git supports rsync.

As well as the front-ends, both hg and git can integrate with bugzilla. hg
has the hg-bugzilla plugin, git can use SCMbug.

Both have bundled repository browsers allowing viewing over the web. They
can also be used to retrieve tarballs/zipfiles of the repo.

When it comes to serving git and hg repositories, hg is straightforward to
serve; just "hg serve". git is more effort.

* 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). It wasn't a gentle introduction, and it was not well
explained. http://progit.org/book/ seemed better but if by only the second
chapter you need to comprehend commands like:
git config --global alias.unstage 'reset HEAD --'
it's not a good sign. It still seems to be catering to a quite technical
audience who are already familiar with other VCS's.

More widely, there seems to be a presumption with git docs that readers
are already technical and experienced with distributed version control
system concepts. I was unimpressed that the official docs recommended
something like
<http://www.kernel.org/pub/software/scm/git/docs/everyday.html> for newbies.

Git's many commands, and their options, are daunting, particularly as
there is little structure to them which appears to have an effect on
documentation. Whereas it makes more sense for functionality of individual
plugins to be documented in isolation. I've also tended to find git
documentation happier to launch rapidly into jargon.

* Performance

git is mostly faster than hg, both directly and, if you're a real power
user, in workflow if you can do something with one (obscure and
complicated!) command, rather than a sequence. On the other hand, hg
allegedly beats git for access over HTTP.

Cygwin-based git is also very slow on windows. msysgit is faster but
allegedly not as fast as hg (or linux git).

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

tags have two forms in git: lightweight and annotated. Lightweight tags
are just direct pointers to a revision (identified by SHA1). Annotated
have more information such as the tagger and date tagged. But as far as I
can tell in both cases, if they are pushed around between repos, tags can
clash in git, which would be bad - I haven't found out how clashes are
resolved (and admittedly haven't had an opportunity to try myself). Any
git user care to comment? If true, it would be poor for a distributed
system. In hg you are given the choice of deciding what to do when merging.

When it comes to branches, there are clear differences between hg and git.
hg has 4 (or possibly 5) different ways to create branches, git has 2 (or 3):
- A repo clone is effectively a heavyweight form of branch, supported by
both hg and git. Although given hard linking with hg, not that heavyweight
if local.
- hg supports anonymous branches, just by having a repository with
multiple heads. You can switch by using specific revision numbers instead;
the heads don't have to be named. Obviously doing this has the risk of
losing track of things especially the larger and more convoluted the tree
gets (although unlike git, history cannot be lost in hg - in git on the
other hand people often garbage collect unreferenced revisions, which docs
recommend as part of regular maintenance).
- hg and git both have lightweight branches (termed "bookmarks" in hg).
The target of the branch always points to its head. In git these are
implemented as git refs. hg doesn't propagate these (they are local to
your repo only). git can be told to push them.
- hg has named branches. These are recorded properly in the metadata of a
change so it's easier to track history associated with development on a
particular branch. They can be pushed between repos. They are probably the
most direct analogue to classic CVS branches. Git doesn't have an
equivalent - branch information is never stored as part of a git
changeset’s metadata.
- Arguably another form of branch, in the general sense, is git's staging
area, and hg's patch queue.

git can't just use remote branches directly - branch names need to be
explicitly mapped by the user between local and remote.

git has the notion of special "tracking branches" for tracking changes in
an upstream remote repo. hg has a different methodology to simplify it by
just pulling all the heads. Then it's up to the user whether and what to
merge.

Neither git nor hg track consider directories as first class objects to be
tracked and versioned. But that's probably not that important.

You can find out more about hg's branch choices from:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

* Merges

Generally both appear to have comparable merge facilities, including the
ability to have different front-end tools to resolve conflicts. They both
also have their own ways to merge across renames.

But there are still some significant differences. hg tries to merge
changesets (as that's what it stores). Since git uses snapshots, it tries
to work stuff out on the fly by guesswork.

This is the way git detects renamed/moved files or directories - not by
the rename but by comparing contents. It even tries to detect the origins
of chunks of files, not just whole files, to try and guess where they were
copied from and consider that section of file (for e.g. 'git blame') as a
parent. This is all considered a feature rather than a bug, so won't
change. I am extremely wary about such functionality. It seems
non-deterministic. I expect many times it works, and especially so with
source bases like the linux kernel. However the lack of precision in
itself seems bad; and what can you do when it gets it wrong? And if there
is something we can do, would it be something we could propagate more
widely into other people's repo clones - it feels to me like each person
would have to fix it themselves. Supporters of the feature say that most
of the time it works (but again what if it doesn't?) and it can
auto-detect both copied chunks of code within files as well as moved
files. It even tries to guess matches from raw patches as well as the repo.

I foresee problems with the eCos code base in particular because large
tracts of code and files *are* identical or near-identical to each other,
and there are a lot of them spread all over the HALs and device drivers. A
lot of code has been copied over time, but the origins are far less clear,
especially as the eCos tree hasn't started off in git. I foresee git
mismatching changes which are unrelated (or if related, they didn't
originate from the particular ones git guesses) with both false positives
and false negatives. I think this property of git is likely to be a
misleading and therefore negative feature. Code like the Linux kernel
probably renames and copies chunks of files rarely, and when it does, git
would be doing the right thing in that case. There is certainly far less
duplication of source file structures. I would also be concerned that
despite git's general performance this ability may not scale well in the
quite large eCos repository, which surely must be hard to chew through if
you're comparing each change not just against files, but contents of files.

You can make hg behave in a similar way to git by using "hg addremove -s"
(and it's worth noting that addremove is a helpful command which doesn't
have a direct equivalent in git). But otherwise it has built-in 'hg
rename' and 'hg copy' commands in order to accurately track file
derivation. (git does have 'git mv' but that's just a shortcut for add
then remove rather than behaving differently).

One facility git has which hg doesn't is octopus merging: being able to
merge more than 2 parents at a time. Mercurial can "only" merge 2 parents.
But I'm not sure at all this is a big deal since it just means for
mercurial you'll have to merge multiple times. This may often make a merge
more tractable in any case. Having to merge lots of heads doesn't seem in
my mind to be something that crops up that often, certainly with the sort
of development eCos is likely to get, and when it does, I think it would
often be better to only deal with 2 at a time rather than all together.

* Repository portability

Even though it's possible to push between git and hg, and for simple stuff
it's fine, there are differences, e.g. with tags and branches. So I think
the maintainers (or any future committers) should agree to only use one
VCS for really interacting with the main repository.

Both hg and git have import and export tools, to/from various other VCS's.
There's a wide choice for one-off conversions (including between hg and
git), and it's also possible for some to keep in sync with remote
heterogenous VCS repos. But in saying that, hg is slighly more
interoperable: you can track git from hg, but, although it is possible,
it's not quite as easy to do it the other way round.

Whatever choice we make, we can provide the other as an exported mirror on
ecos.sourceware.org. This arguably reduces the significance of the choice
greatly, and becomes more: what do the main users (primarily the
maintainers) want to use for themselves.

* Submodules

Both hg and git support submodules, which are a way to nest repositories
inside other repositories. For example, we could consider separating out
the host tree into its own repo, and for those that do need it, they can
integrate it as a submodule so make the "whole" tree again. Or we could
consider separate repos for architecture-specific components, which is
more blue sky. The rationale to splitting things up more is not just
smaller repository downloads, but so that when people are tracking
repository changes they are more likely to be seeing changes relevant to
them, and not for example a plethora of MIPS changes when they'll never
ever be working on MIPS. Or target side developers rarely get heavily
involved in host tool development or vice versa. Submodules have the
potential to be a lot of use I think, but nothing's likely to happen soon
though because we'd have problems with some of our monolithic files like
the top level ecos.db. Also to really separate the host stuff, we should
remove host tools from the package repository (instead having an analogous
host package repository) which would IMHO be a good thing.

It's also desirable eventually for the repository layout to match what we
ship in stable releases. It would be wise to include binaries then so they
can be version controlled, *but* it is unwise to include binaries in the
normal source repository, primarily due to the size. It may be possible to
have them in their own repositories and have them included via submodules.
It's a neater way to solve Oyvind's request to support tagging other
things outside of the normal eCos repo, such as host tools sources or
toolchain sources and binaries, for releases.

But while it's a useful feature that was mentioned several times in ecos
mailing list discussions, and users are free to use it in their own repos,
we may not be able to as changes would need to happen in eCos first
(particularly ecos.db).

hg had a third-party "forest" extension for a while, but some of its
functionality is being adopted into the main hg codebase (now named
submodules instead of forest). It seems that it's not quite all there yet
though, for example an hg diff won't span all the submodules. But this is
an area which has been under active development, so that is likely to
improve, probably before we would have a chance to use it.

* Conclusion-like thing

In fact I haven't made up my mind, so this is not really a conclusion as
such. But taking everything into account, at the present time I am leaning
towards mercurial. I could still be swayed though.

* Migration

It's probably worth saying what will be needed to be done even once a VCS
decision is taken.

Alex Schuilenburg at eCosCentric has already converted eCos CVS to a
public hg repo (<http://hg-pub.ecoscentric.com/>), put together with
considerable hardship given the often inconsistent state of the eCos CVS
repository, with many years of hacks. This means we can keep almost all
our file history. This hg repo is being kept up-to-date. Whichever VCS is
chosen, I suggest that is used as the basis for a new repo - it can be
exported into git if needed. We will also be keeping the CVS repository
around, read-only, for archaelogy should it ever be wanted. FAOD, while
eCosCentric have already chosen hg, it's immaterial to them if we choose
git because they can equivalently import from hg->git entirely automatically.

Alex suggested switching gradually, by providing a public hg repo, still
synced from the CVS repo, but temporarily, the maintainers would still
commit to the CVS repo (where it would end up going to hg). I think that
is a good idea, and better than trying to have a big switchover.

Clearly we will have to replace the website page at
http://ecos.sourceware.org/anoncvs.html which I can do. We will need to
point out what VCS to use, where to get it and its dependencies
(perl/python etc.), front-end clients, links to tutorials, and most
importantly in my mind, a small number of recipes for the most common
operations (we mustn't go overboard - there are better ways to learn a new
VCS than from a few recipes).

As well as the ecos source repository, there is the ecos images tree -
this is effectively obsolete but we may as well keep it around, mostly
because it's already available from eCosCentric.

There is also the ecos.sourceware.org webpages themselves. I suggest
deferring those to be tackled at a future date. There is already enough to
get on with.

We need to make sure we can get commit messages to a new ecos-changes list
(replacing ecos-cvs).

Further out, we should consider some level of bugzilla integration.

If sensible, we should also provide alternative means of access of the
repo. So, a git repository for hg users, or hg repo for git users.

Sourceware's version of hg is oldish - 1.0 era. git is very new: v1.7.0.1.
>From discussion in the past, the old version of hg may not be that
significant unless we are going to be using hg locally on sourceware much
- which we aren't (shell accounts are not generally available). OTOH, we
need newer hg if we want to use the hg-git plugin. Upgrading to newer hg
is easy in itself - it's just that it involves other projects which use hg
on sourceware.



Unfortunately I'm not going to be around to answer mails next week, so
you've got plenty of time to read and digest this mail before commenting
:-). I'll reply to any comments the following week.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]