There are plans to move Moodle development to git. Are they a result of careful consideration when choosing git among other DVCS like Mercurial or Bazaar etc?
For one thing, it's unfair for Windows using people - Windows support for git is far from perfect. It's also have somewhat steeper learning curve than some alternatives.
There were also some researches from Google and Python projects that claim that git is notoriously slow when serving throught http, it works fine only over it's custom protocol while Mercurial is much better http-optimised.
So I wonder what advantages of git leads Moodle Developers to choose it in spite of those obvious disadvantages...
Newer versions of git support a "smart http" mode that is faster than the older http methods: http://github.com/blog/642-smart-http-support. I don't know how that compares to other systems.
I'd be okay with mercurial, I guess, but I'm more familiar with git. I know Mercurial and git inter-operate pretty good. I don't know about bazaar. I'm guessing it would be pretty simple to have mirrors in any of these regardless of what the moodle folks eventually do.
I just want to see them stop using cvs, just about anything would be better
I'd be okay with mercurial, I guess, but I'm more familiar with git. I know Mercurial and git inter-operate pretty good. I don't know about bazaar. I'm guessing it would be pretty simple to have mirrors in any of these regardless of what the moodle folks eventually do.
I just want to see them stop using cvs, just about anything would be better
this has been discussed a lot:
http://moodle.org/mod/forum/discuss.php?d=99763
http://docs.moodle.org/en/Development:Git_Migration
Windows tools are a lot more stable now so this argument doesn't really have a lot of traction anymore - see:
tortoisegit, smartgit etc, and integration with IDEs is really good and seem to be a lot more stable - see PHPStorm, Eclipse, etc
The maturity of the windows tools has been a reason why Moodle didn't shift to git 2 years ago, but now that the tools seem to be coming in-line it's no longer an issue holding it back.
it's also important to note that the shift really only concerns those with WRITE access to Moodle core code. - those with read-only access will still be able to use a CVS mirror of the Git code. (if they really want.
Mercurial and Bazaar have both been discussed - try google to find out some of the issues.
http://moodle.org/mod/forum/discuss.php?d=99763
http://docs.moodle.org/en/Development:Git_Migration
Windows tools are a lot more stable now so this argument doesn't really have a lot of traction anymore - see:
tortoisegit, smartgit etc, and integration with IDEs is really good and seem to be a lot more stable - see PHPStorm, Eclipse, etc
The maturity of the windows tools has been a reason why Moodle didn't shift to git 2 years ago, but now that the tools seem to be coming in-line it's no longer an issue holding it back.
it's also important to note that the shift really only concerns those with WRITE access to Moodle core code. - those with read-only access will still be able to use a CVS mirror of the Git code. (if they really want.
Mercurial and Bazaar have both been discussed - try google to find out some of the issues.
I have been using git on Windows for the last year with minimal problems.
The minor problems I have had are:
Sometimes, you type a command and it sits there doing nothing for some seconds, and then does what you ask it.
Also, generally, intensive operations like rebase and git grep are slower on Windows - but I think that is a problem with NTFS. Other disc-intensive operations like doing a full text search across the Moodle code are slower on Windows than on Linux/MacOS file systems.
Anyway, even with these performance problems, git is massively faster than CVS.
The minor problems I have had are:
Sometimes, you type a command and it sits there doing nothing for some seconds, and then does what you ask it.
Also, generally, intensive operations like rebase and git grep are slower on Windows - but I think that is a problem with NTFS. Other disc-intensive operations like doing a full text search across the Moodle code are slower on Windows than on Linux/MacOS file systems.
Anyway, even with these performance problems, git is massively faster than CVS.
Dan wrote:
"it's also important to note that the shift really only concerns those with WRITE access to Moodle core code - those with read-only access will still be able to use a CVS mirror"
There is one more group of people: contrib developers with write access to the CVS. Are any thought given about them concerning this migration? I personally can handle any version control system (I hope), but I know well that not all contrib developers are professional programmers and they may have problems with unknown software, while git are not particulary good for newbies, especial without unix/programming experience. Is there extensive docs for them in place? Or contrib will remain in CVS? Or it's considered their problem and they just should adopt as best as they could? I don't tell it's should necessary affect VCS choice but than it should affect migration process. (Was contrib developers at least notified that they should be ready to switch VCS in two months or they just will know that as the fact once it done?)
I also don't like much some things git allows you to do on repository, mercurial 'history is sacred' approach may be better. I hope they will be switched off on Moodle server.
P.S. I totally agree that any conscious choice will be better than CVS!
"it's also important to note that the shift really only concerns those with WRITE access to Moodle core code - those with read-only access will still be able to use a CVS mirror"
There is one more group of people: contrib developers with write access to the CVS. Are any thought given about them concerning this migration? I personally can handle any version control system (I hope), but I know well that not all contrib developers are professional programmers and they may have problems with unknown software, while git are not particulary good for newbies, especial without unix/programming experience. Is there extensive docs for them in place? Or contrib will remain in CVS? Or it's considered their problem and they just should adopt as best as they could? I don't tell it's should necessary affect VCS choice but than it should affect migration process. (Was contrib developers at least notified that they should be ready to switch VCS in two months or they just will know that as the fact once it done?)
I also don't like much some things git allows you to do on repository, mercurial 'history is sacred' approach may be better. I hope they will be switched off on Moodle server.
P.S. I totally agree that any conscious choice will be better than CVS!
there's always a lot of thought put into looking after contrib developers - in fact there's even someone appointed officially by Moodle HQ to work with them (Anthony Borrow) There's also been no "official announcement" of a date for moving to git - I imagine that Core Moodle will be the first to move as most core devs have been using git already or know that it will be happening soon.
I suspect that Contrib CVS devs will be given some time to convert to using git before the Contrib CVS area is changed to read-only and I expect that Anthony/ Moodle HQ will work with the contrib devs to help through this process before it happens.
Devs that want to continue to use CVS would be welcome to find another CVS host to use their code, but I expect they will want to move to git to take advantage of submodules/ability to merge easily etc.
I suspect that Contrib CVS devs will be given some time to convert to using git before the Contrib CVS area is changed to read-only and I expect that Anthony/ Moodle HQ will work with the contrib devs to help through this process before it happens.
Devs that want to continue to use CVS would be welcome to find another CVS host to use their code, but I expect they will want to move to git to take advantage of submodules/ability to merge easily etc.
I need to bring myself up to speed on git and will do my best to help folks assimilate. Since I'll be learning git too I should have an idea of how to explain things to others in simple terms. As much as possible, I want to keep as much code in Moodle CONTRIB as possible. It really helps to be able to correct issues, find others to step in and maintain the code, etc. I'm not sure yet what the time frame will be but once 2.0 is released we can begin having those discussions. Peace - Anthony
Is contrib CVS going to be read-only? The only news I've heard is that core CVS is going that way, but I didn't hear anything like that for contrib[*]
Saludos.
Iñaki.
[*] I'm not a HQ developer nor a Moodle partner, so I may be missing part of the conversation about the switch to git.
Saludos.
Iñaki.
[*] I'm not a HQ developer nor a Moodle partner, so I may be missing part of the conversation about the switch to git.
Hi Inaki!
I think the only "decision" that seems to have been made so far is that we will move to Git for core dev(no dates have been set yet) - and longer term would like to move contrib into Git as well. Git is going to be quite good for contrib stuff - we could use submodules for plugins and branches with custom code will be a lot easier to merge.
This is all stuff that won't really be looked at until 2.0 is actually out so I wouldn't expect any official dates to be set until HQ manage to have a 2.0 final release party.... Then HQ/core devs can spend some time discussing the details - with the move to git I expect there might also be some workflow changes for getting patches into Core to improve the process a bit.
I think the only "decision" that seems to have been made so far is that we will move to Git for core dev(no dates have been set yet) - and longer term would like to move contrib into Git as well. Git is going to be quite good for contrib stuff - we could use submodules for plugins and branches with custom code will be a lot easier to merge.
This is all stuff that won't really be looked at until 2.0 is actually out so I wouldn't expect any official dates to be set until HQ manage to have a 2.0 final release party.... Then HQ/core devs can spend some time discussing the details - with the move to git I expect there might also be some workflow changes for getting patches into Core to improve the process a bit.
I don't see any particular need to turn of write to contrib CVS any time soon.
Please, please, please give us a git-based place where we can share our contrib modules if we choose.
But then I think it makes sense to run contrib CVS and contrib git in parallel for a while (providing the overhead is not too great) and see how many people move of their own accord.
Then only shut-down contrib CVS when only a few poeple still use it.
Please, please, please give us a git-based place where we can share our contrib modules if we choose.
But then I think it makes sense to run contrib CVS and contrib git in parallel for a while (providing the overhead is not too great) and see how many people move of their own accord.
Then only shut-down contrib CVS when only a few poeple still use it.
I agree - it makes sense to leave contrib cvs there for a while, but I do thing we should be actively encouraging a conversion to git - I'm sure Anthony and others in the community will help the process along!
The major reason now is that most of the core developers already use git, many other developers and contributors are working with it happily too.
The only remaining question is when are we going to switch? I personally think the sooner the better.
By the way I was one of the few developers that liked mercurial more, but in the end I came to the conclusion that git is a better choice.
Petr
The only remaining question is when are we going to switch? I personally think the sooner the better.
By the way I was one of the few developers that liked mercurial more, but in the end I came to the conclusion that git is a better choice.
Petr
The plan is to basically spend the whole month of November switching over to Git, developing new processes and training everyone etc.
I was frustrated with git when I first started using it because it took awhile to figure it out. There is a bit of a learning curve. But now that I've been using it for a year or two, I can't imagine living without it. I really think it is the best SCM system for open source development. It makes sharing, collaborating, forking, etc. so much easier. And isn't that what open source is all about?
Hi all,
I've been reading the discussions about Git at various points with interest.
I'm involved with making a web system/application (Cloudworks) open-source at the Open University in the next few weeks. And we're currently trying to decide between Git and Mercurial, and between Github, Bitbucket and Google Code.
Does anyone have any views or useful links? Including experiences with the platforms, not just the SCMs. The often-mentioned bit about Git having a steeper learning curve is a slight concern, given that we'll be small and wanting to attract as many contributors as possible.
Sorry this is slightly off-topic!
Any comments appreciated
Thanks,
Nick
Hi,
I'm currently working with ECLIPSE and CVS. Switching to GIT, does it mean I could keep my ECLIPSE developing environment? Which GIT plugin would I have to use with ECLIPSE if any?
Has anyone done it already... and could provide useful documentation about the transition?
Joseph
I'm currently working with ECLIPSE and CVS. Switching to GIT, does it mean I could keep my ECLIPSE developing environment? Which GIT plugin would I have to use with ECLIPSE if any?
Has anyone done it already... and could provide useful documentation about the transition?
Joseph
There is an Eclipse plugin for git. It is currently at version 0.9.3 or something. It now mostly works. Probably. But there are still some git features that you can't do using it.
However, it works perfectly well to have an project in Eclipse that is a git checkout, and to do all the git operations from the command line (and gitk and git-gui) while using Eclipse to do the development. That is how I have been working for most of the last year. (Of course, that is no good if you have command-line-phobia.)
Basically, if your project is managed by git, you have a single .git folder at the top level (similar to the way that if you use CVS, you have CVS folders everywhere!)
However, it works perfectly well to have an project in Eclipse that is a git checkout, and to do all the git operations from the command line (and gitk and git-gui) while using Eclipse to do the development. That is how I have been working for most of the last year. (Of course, that is no good if you have command-line-phobia.)
Basically, if your project is managed by git, you have a single .git folder at the top level (similar to the way that if you use CVS, you have CVS folders everywhere!)
Thanks for the info Tim.
I do have command-line phobia. To me it's like going back to the Dark Ages of computing.
Jospeh
I do have command-line phobia. To me it's like going back to the Dark Ages of computing.
Jospeh
Hi Joseph,
While I don't have command-line phobia, I've been using TortoiseGit (on Windows) - there have been a couple of quirks, and it's still in development (so getting better all the time), but on the whole it's been quite easy to use.
It can just take a little while to get the hang of Git as a whole - but day-to-day operations come quite easily after a short time, and if you're already familiar with TortoiseSVN or TortoiseCVS, you should find TortoiseGit reasonably similar and easy to move into.
-Paul
While I don't have command-line phobia, I've been using TortoiseGit (on Windows) - there have been a couple of quirks, and it's still in development (so getting better all the time), but on the whole it's been quite easy to use.
It can just take a little while to get the hang of Git as a whole - but day-to-day operations come quite easily after a short time, and if you're already familiar with TortoiseSVN or TortoiseCVS, you should find TortoiseGit reasonably similar and easy to move into.
-Paul
Just a word of caution. I haven't tried TortoiseGit for some time but the last time it messed up my TortoiseCVS and TortoiseSVN installation. Suppose I should give it another chance 
Frank
PS
Speaking of command-lines: For Drupal there's a command-line interface for administration purposes (http://drupal.org/project/drush ). I wonder if such a thing would be nice to have for Moodle, too.
Frank
PS
Speaking of command-lines: For Drupal there's a command-line interface for administration purposes (http://drupal.org/project/drush ). I wonder if such a thing would be nice to have for Moodle, too.
There is a CLI interface for Moodle in 2.0
I just wanted to make an observation, I hope you don't mind ...
You have command-line phobia, but you don't have a problem typing PHP code. Why don't you insist on a programming environment like Scratch for PHP if you are not prepared to type on the command-line?
(That is meant to be a serious question to promote reflection, not an attempt to insult you)
By the way, if you are on Windows, do not on any account try to use the standard 'cmd' shell. That really is the dark-ages of computing. Get console, and probably install cygwin too, so you can use a proper shell like bash.
You have command-line phobia, but you don't have a problem typing PHP code. Why don't you insist on a programming environment like Scratch for PHP if you are not prepared to type on the command-line?
(That is meant to be a serious question to promote reflection, not an attempt to insult you
By the way, if you are on Windows, do not on any account try to use the standard 'cmd' shell. That really is the dark-ages of computing. Get console, and probably install cygwin too, so you can use a proper shell like bash.
The big Eclipse git plugin is egit, which is now an official Eclipse subproject -- http://www.eclipse.org/egit/ . I've been using NetBeans lately but I was checking out egit last week, and at first glance it seemed a lot nicer and more mature than the NetBeans git plugin.
I'll second what Tim said. I'm using a similar setup with NetBeans. I've got the NetBeans git plugin (nbgit) installed, but I only use it to do the equivalent of "git status" and "git diff". For all the other operations (merging, branching, history, remote repositories), I switch over to the command line. NetBeans is fine with this; I just have to remind it to refresh its git status occasionally.
Having used CVS and SVN extensively in Eclipse in the past, I found that it was a little tricky adjusting to git in Eclipse. It was actually a pretty similar experience to when I first started using git at the command-line, just figuring out the different workflow that comes from the basic conceptual differences between the systems.
I'll also add that, when I switched from SVN to git about six months ago, I found that I could scrape out a bare bones basic workflow with "cheat sheets" and some instruction from my co-workers, but I had no idea what the commands were really doing until I spent several hours reading the O'Reilly git book.
Cheers,
Aaron
I'll second what Tim said. I'm using a similar setup with NetBeans. I've got the NetBeans git plugin (nbgit) installed, but I only use it to do the equivalent of "git status" and "git diff". For all the other operations (merging, branching, history, remote repositories), I switch over to the command line. NetBeans is fine with this; I just have to remind it to refresh its git status occasionally.
Having used CVS and SVN extensively in Eclipse in the past, I found that it was a little tricky adjusting to git in Eclipse. It was actually a pretty similar experience to when I first started using git at the command-line, just figuring out the different workflow that comes from the basic conceptual differences between the systems.
I'll also add that, when I switched from SVN to git about six months ago, I found that I could scrape out a bare bones basic workflow with "cheat sheets" and some instruction from my co-workers, but I had no idea what the commands were really doing until I spent several hours reading the O'Reilly git book.
Cheers,
Aaron
Well, any distributed VCS is almost infinitely better than any non-distributed VCS. Compared to that difference, the differences between Mercurial and git are marginal.
I have only used git, and it is fantastic. Things I rate highly are: speed, its facility merging and re-basing, the open-source workflows it enables. (I have no idea if these things work as well in Mercurial, but I assume it is not far off.)
github is a very nice web interface and workflow. I particularly like the ability to comment on patches. However, that infrastructure is not open source, which sucks. gitorius is better from an open-source purist's point of view.
More and more projects are moving to git (or Mercurial) so it will become one of those things you just have to know if you want to join the open source world, like SVN and CVS are now. github has some nice tutorials. So, I would not worry about the learning curve. (In the short term, it will be a useful filter. Using git or Mercurial will weed out the really clueless people who want to contribute)
I have only used git, and it is fantastic. Things I rate highly are: speed, its facility merging and re-basing, the open-source workflows it enables. (I have no idea if these things work as well in Mercurial, but I assume it is not far off.)
github is a very nice web interface and workflow. I particularly like the ability to comment on patches. However, that infrastructure is not open source, which sucks. gitorius is better from an open-source purist's point of view.
More and more projects are moving to git (or Mercurial) so it will become one of those things you just have to know if you want to join the open source world, like SVN and CVS are now. github has some nice tutorials. So, I would not worry about the learning curve. (In the short term, it will be a useful filter. Using git or Mercurial will weed out the really clueless people who want to contribute
In additionto github tutorials, you have the 'Pro Git' book (http://progit.org/book/) which is really good IMHO.
It's available with a CC-BY-NC-SA license, and in paper-back (for example, at Amazon http://www.amazon.com/gp/product/1430218339).
Saludos. Iñaki.
Atlassian, who make the JIRA bug tracking system used by Moodle and others, have acquired Bitbucket (the leading Mercurial hosting service).
They say "we will offer additional new functionality and integration [of Bitbucket] with the entire Atlassian collaboration and development tools hosted services".
Jonathan
They say "we will offer additional new functionality and integration [of Bitbucket] with the entire Atlassian collaboration and development tools hosted services".
Jonathan
Concerns like Joseph's one is the things why I started this thread. Git may have some more complex internal features (used only rarely and with greatest care), but Mercurial is well known for good UI (stable and good TortoiseHg and - as far as I read - great Eclipse plugin too).
Also, while I don't have a command-line phobia, I find GUI quite useful when looking on colored diff's or cherry-picking changes by mouse etc.
You, of course, could use git steeper learning curve to "weed out" contributors like Joseph (some even well know that I'm not the one to like his form of contribution at all - but they still attract quite a number of users) - the question is did you really want it. That means less teachers-more programmers in Moodle development, and while it has obvious benefits the fate of SAKAI, created by professional developers on structured principles should teach us something.
The Moodle main strength was in shallow learning curve, easy to install and use, easy to mod or write plugin. Now it is more and more losing it. It is good to see Moodle more scalable and structuring. But it is worrying to see it more complicated to newbies of all sorts.
Also, while I don't have a command-line phobia, I find GUI quite useful when looking on colored diff's or cherry-picking changes by mouse etc.
You, of course, could use git steeper learning curve to "weed out" contributors like Joseph (some even well know that I'm not the one to like his form of contribution at all - but they still attract quite a number of users) - the question is did you really want it. That means less teachers-more programmers in Moodle development, and while it has obvious benefits the fate of SAKAI, created by professional developers on structured principles should teach us something.
The Moodle main strength was in shallow learning curve, easy to install and use, easy to mod or write plugin. Now it is more and more losing it. It is good to see Moodle more scalable and structuring. But it is worrying to see it more complicated to newbies of all sorts.
I think the shallow learning curve bit is important.
But really, the debate here is which is easier: CVS or git?
I am not sure that git is much harder than CVS. Of course, at the moment, a lot of people in the Moodle world already know CVS and don't know git. A change will be painful for them. However, a page like "git_for_Administrators", with the same information as CVS_for_Administrators would be easy to write, and about the same length, if not shorter.
Similarly, Development:CVS_for_developers probably only gets simpler (we should need less verbose stuff about merging.)
And, I am sure that in 5 years time, more people in the world will know git, and CVS will seem like some arcane skill that most people would rather not learn. Switching to git now may be a little ahead of the curve, but it is still the right direction to be moving in.
Of course, it is critical that things like Tortoise git and the Eclipse/Netbeans git plugins are solid.
But really, the debate here is which is easier: CVS or git?
I am not sure that git is much harder than CVS. Of course, at the moment, a lot of people in the Moodle world already know CVS and don't know git. A change will be painful for them. However, a page like "git_for_Administrators", with the same information as CVS_for_Administrators would be easy to write, and about the same length, if not shorter.
Similarly, Development:CVS_for_developers probably only gets simpler (we should need less verbose stuff about merging.)
And, I am sure that in 5 years time, more people in the world will know git, and CVS will seem like some arcane skill that most people would rather not learn. Switching to git now may be a little ahead of the curve, but it is still the right direction to be moving in.
Of course, it is critical that things like Tortoise git and the Eclipse/Netbeans git plugins are solid.