Øyvind Harboe wrote on 2009-09-17 11:52: > Does anyone know a reason not to switch to git for eCosForge? > > My thinking is to use http://repo.or.cz/ to host projects. > > www.ecosforge.net uses a version of subversion that is getting > a bit long in the tooth (1.4) and I'm just wondering if > git isn't a better choice anyway.... > > The plan is to leave the current subversion repository as-is and > let migration happen eventually, deleting old repositories(they > are still there in the history) after migration to git. > > The idea is to have one git repository per eCos repository(or > project if you will). > > The first project I would like to switch to git, is nios2ecos. >
Why git in particular? We have started looking at switching to another RCS at eCosCentric as well. In particular I looked at three distributed RCS solutions: git, bazaar and mercurial. While there is no doubt that git is the most powerful of the three solutions and also fastest on linux, it is also the most complex of the three solutions with a very steep initial learning curve, it's support for windows is lacking, and its documentation is sparse and confusing. As a tool for experienced Linux developers, sure, git is the best choice. But for the average eCos developer, I am not convinced. The choice of an alternative RCS should also take into consideration Windows users, as well as speed and ease of use. When it came down to it, I found mercurial only to be marginally slower than git, but far better documented, easier to learn, and with much better support on Windows platforms. Bazaar was slower than mercurial and also was not as well documented, although Windows support was pretty much the same as mercurial. Both bazaar and mercurial were a lot easier to learn and work with than git. git's Windows support is also limited and is mostly restricted to the 100's of cmd apps which make up git under cygwin. Bazaar and mercurial are native windows apps, so speed comparisons worked in their favour on Windows. I intend to do a more formal evaluation of all three, also drawing in user's experiences from the web, which I will be happy to write up here when complete if people think it is worthwhile. The topic of ecos switching to another RCS has already been raised once before and nothing much came of this so I am offering a proper evaluation of pros and cons before a choice is made, for a proposal for an anoncvs alternative RCS solution anyway. Anyway, I should point out that all three DRCS appear to have tools that allow for the migration and/or import/export of changesets between them, so in theory any choice on what anyone uses in-house can be left to personal preference regardless of what the main repository is. I cannot speak for these tools, other than to say I have tried to import our internal CVS repository and anoncvs into all three and not one of them worked. git did the worst job, followed by bazaar then mercurial. And yes, I have tried cvs2svn to go via svn as well :-( However, more worryingly these attempted imports showed that both our and the anoncvs CVS respositories are corrupt, which is probably why the imports failed so badly using the automated tools. Any attempted conversion of anoncvs is going to need a fair amount of effort by someone. That said, I should point out that I am in the process of developing/converting our own repository using a modified cvsps 2.2beta that can fix most of the corruption in conjunction with a perl script which fixes the rest, so may end up with a tool which correctly converts anoncvs (i.e. preserving all check-in states, tags and history) to whatever with little human effort. Don't panic though, checking out current anoncvs always works. Just do not rely on tags and branches. Checkouts made at the same time as tags were made have shown several files that were missed being tagged, making what was actually distributed differ from what was tagged, and files missing from branches. As an early example, checkout the ecos-v2_0-branch just after it was made and observe that doc/Changelog is missing, even though it was present in the trunk when the branch was made. This is just one case of 100's However, I suspect your switch from svn to whatever will be fairly simple. The import/export tools do a fine job on most simple repositories. HTH -- Alex Schuilenburg >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< **** Visit us at ESC-UK http://www.embedded.co.uk **** **** Oct 7-8 on Stand 433 at FIVE ISC, Farnborough **** -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
