From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14174 invoked by alias); 12 Mar 2010 23:30:27 -0000 Received: (qmail 14137 invoked by uid 22791); 12 Mar 2010 23:30:23 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Mar 2010 23:30:16 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id o2CNUCt07342; Fri, 12 Mar 2010 23:30:12 GMT Received: from lert.jifvik.org (lert.jifvik.org [172.31.1.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id A931B3FE1; Fri, 12 Mar 2010 23:30:11 +0000 (GMT) Message-ID: <4B9ACE82.4040805@jifvik.org> Date: Fri, 12 Mar 2010 23:30:00 -0000 From: Jonathan Larmour Reply-To: eCos Discussion User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3 MIME-Version: 1.0 To: eCos Discussion Cc: eCos Maintainers Subject: Replacing CVS - decision time Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/msg00016.txt.bz2 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 () although there's a very clear slant towards "linux system" projects. hg also has many major projects using it (), 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: 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 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 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 (), 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