http://www.nabble.com/Thoughts-about-git-td16409123.html
I think I will have to start learning Java now!
No Java, NOOOOOOOOooooooooooooo 
They can't take the lead. We had a lone individual pushing git long before they did. 
In reply to Martin Dougiamas
Re: We can't let Sakai take the lead, can we? ;-)
by Visvanath Ratnaweera -
Talking about git, here is another take http://video.google.com/videoplay?docid=-2199332044603874737
It doesn't mean that git will do the programming for you!
It doesn't mean that git will do the programming for you!
I have to admit, git is pretty cool especially for developers! - I'd avoided it for a long time thinking it was rather complicated and stuck to cvs.....but now that I "have" to use git and needed to figure it out...... I don't want to go back to cvs! 
I wonder, especially now that we've moved to the whole _WEEKLY thing, what's to stop the dev team using git, and publishing out to a read-only CVS for those who want to get their updates that way?
Dan
I wonder, especially now that we've moved to the whole _WEEKLY thing, what's to stop the dev team using git, and publishing out to a read-only CVS for those who want to get their updates that way?
Dan
what's to stop the dev team using git, and publishing out to a read-only CVS for those who want to get their updates that way?
We would need a script that will 'replay' the history from git into a public cvs server.
Andrew McMillan has written that exact script. Mahara is developed with GIT, and publishes CVS and SVN readonly repos.
For Moodle, there is still the issue of avoiding hassles for translators -- most of them use TortoiseCVS and are blissfully unaware of SCM terminology and machinery. There are a few easy options
- Let them keep "lang" in CVS - which can only be done for a limited time - at some point we will need to move on from that.
- Move them to git, but offer git-cvsserver
- Wait for Cheetah (a Tortoise lookalike with GIT internals) to become usable
'Wait for Cheetah (a Tortoise lookalike with GIT internals) to become usable'
Oh look! You've identified the solution already
I don't think any project including Moodle should switch to Git or any other version control system until there is (a) a working Windows/cross-platform GUI client, and (b) a working Eclipse plugin on a level with Eclipse CVS support. [How's progress on that?] For a large project like Moodle, it's probably a good idea to wait a while after that for more plugins, more time to polish UI, and more ubiquity.
By the way I was amused to see somebody posted a link about java being slower than C++. NO DUH. Unless they've improved the just-in-time compilation since a few years ago, for a heavily CPU-intensive task [audio compression in memory], Java is about 3 times slower than C; this is using a direct port of the same code. In addition Java programs tends to use vastly more memory than they would in C. But it's not terribly relevant, and I suspect that article's old; it should probably be renamed 'Why Java Will Always Be Slower than C++ But Nobody Gives a Toss Any More'. (Although, if you're writing high-performance simulation code to be run in expensive supercomputer time, and a factor-3 performance issue is a difference between 1 month and 3 months of said time? Um, don't use Java.)
Since neither Moodle nor Sakai are written in C++, however, this is perhaps less than relevant (even given the thread drift to that point). I suspect the speed difference between PHP and Java is rather more than a factor of 3, but you can easily throw away Java's huge performance advantage by adopting a complex web-services architecture. (Um, just as an example...) CPU performance of the interface language matters approximately not at all in comparison to database queries or web service requests.
--sam
Oh look! You've identified the solution already
I don't think any project including Moodle should switch to Git or any other version control system until there is (a) a working Windows/cross-platform GUI client, and (b) a working Eclipse plugin on a level with Eclipse CVS support. [How's progress on that?] For a large project like Moodle, it's probably a good idea to wait a while after that for more plugins, more time to polish UI, and more ubiquity.
By the way I was amused to see somebody posted a link about java being slower than C++. NO DUH. Unless they've improved the just-in-time compilation since a few years ago, for a heavily CPU-intensive task [audio compression in memory], Java is about 3 times slower than C; this is using a direct port of the same code. In addition Java programs tends to use vastly more memory than they would in C. But it's not terribly relevant, and I suspect that article's old; it should probably be renamed 'Why Java Will Always Be Slower than C++ But Nobody Gives a Toss Any More'. (Although, if you're writing high-performance simulation code to be run in expensive supercomputer time, and a factor-3 performance issue is a difference between 1 month and 3 months of said time? Um, don't use Java.)
Since neither Moodle nor Sakai are written in C++, however, this is perhaps less than relevant (even given the thread drift to that point). I suspect the speed difference between PHP and Java is rather more than a factor of 3, but you can easily throw away Java's huge performance advantage by adopting a complex web-services architecture. (Um, just as an example...) CPU performance of the interface language matters approximately not at all in comparison to database queries or web service requests.
--sam
> Andrew McMillan has written that exact script. Mahara is developed with GIT, and publishes CVS and SVN readonly repos.
While it's true that we did this in the beginning, we abandoned it as soon as we started doing stuff with branches (and I just checked, it was svn only, not cvs) - I think that the branching support was really not that good. We basically only did it because some of those tools that monitor open source projects version control repos and generate stats for them didn't support git at the time, but they have for ages and it's been discontinued for about a year.
While it's true that we did this in the beginning, we abandoned it as soon as we started doing stuff with branches (and I just checked, it was svn only, not cvs) - I think that the branching support was really not that good. We basically only did it because some of those tools that monitor open source projects version control repos and generate stats for them didn't support git at the time, but they have for ages and it's been discontinued for about a year.
Interesting. The Rails (my "other love") core team announced this month that they're moving from Subversion to Git http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git
... it sparked a massive debate/flame war about whether it meant that the team was abandoning support for developers on Windows.... with the response from the lead developer: "If you’re freaking out, calm down. Rails and the developers behind it have snubbed Windows far, far worse in the past"
It seems the clock's ticking for CVS et al... ;)
... it sparked a massive debate/flame war about whether it meant that the team was abandoning support for developers on Windows.... with the response from the lead developer: "If you’re freaking out, calm down. Rails and the developers behind it have snubbed Windows far, far worse in the past
It seems the clock's ticking for CVS et al... ;)
> the team was abandoning support for developers on Windows
For the record, I have been using GIT on windows for about 8 months and it is rock solid, and fast fast FAST. And it does not require Cygwin anymore.
Before that, I had discounted GIT on Windows as a hack that wouldn't be usable for a while. I tried it once, and it worked 80%. Tried it two weeks later and it was *perfect*. And it has only been getting faster since (and getting corner cases fixed).
Now the same team is putting together something called Cheetah - a proper match for Tortoise
Project page for the port:
http://code.google.com/p/msysgit/
For the record, I have been using GIT on windows for about 8 months and it is rock solid, and fast fast FAST. And it does not require Cygwin anymore.
Before that, I had discounted GIT on Windows as a hack that wouldn't be usable for a while. I tried it once, and it worked 80%. Tried it two weeks later and it was *perfect*. And it has only been getting faster since (and getting corner cases fixed).
Now the same team is putting together something called Cheetah - a proper match for Tortoise
Project page for the port:
http://code.google.com/p/msysgit/
In reply to Martín Langhoff
Re: We can't let Sakai take the lead, can we? ;-)
by Ludo (Marc Alier) -
Quote: "Java is evil and eats kids" MD 2005
In reply to Ludo (Marc Alier)
Re: We can't let Sakai take the lead, can we? ;-)
by Martín Langhoff -
And he abstained about Eclipse, quite tactfully too
Jokes aside, I agree that for some projects Windows support is important, and for a subset of those, a gui can be important.
Eclipse is just an editor - I really like my Emacs, but I use vi, jed, gedit, Eclipse or whatever comes along when Emacs isn't available. So I am not sure if it's an end-of-the-world matter.
There is an eclipse-integration project for git luckily, and it's a nice to have. But I hesitate at letting the tail wag the dog. The editor is there to edit code, not to put conditions on a project.
Jokes aside, I agree that for some projects Windows support is important, and for a subset of those, a gui can be important.
Eclipse is just an editor - I really like my Emacs, but I use vi, jed, gedit, Eclipse or whatever comes along when Emacs isn't available. So I am not sure if it's an end-of-the-world matter.
There is an eclipse-integration project for git luckily, and it's a nice to have. But I hesitate at letting the tail wag the dog. The editor is there to edit code, not to put conditions on a project.
Missing support for Eclipse would definitely be the end-of-the-world for me 
If Eclipse was just an editor, then I probably wouldn't use it....
Exactly. It's not so much that Eclipse is fantastic as an editor (it is, but less so for php) but that developers - and not just those on Windows - use editors like Eclipse precisely because they integrate with CVS so nicely. Because the PHP side of Eclipse is actually pretty so-so, you don't get all that much out of using eclipse, vs say a simple text editor that only does syntax highlighting, except for CVS. (OK and project-global search, regex search/replace etc. which may not be available in text editors.)
CVS integration is definitely the biggest reason why we tell new developers here to use Eclipse. (And that's because of the quality/ease of use of the integration compared to using a separate editor and TortoiseCVS, not compared to command-line or anything.)
Also the availability of a stable, complete Eclipse plugin would indicate that plugins for most other development environments are likely imminent, as that means that there's a full Java implementation (or else a full Java wrapper to a native-code implementation).
So, yes - if there isn't a finished plugin for the best known, most-successful IDE, I think it's still too early to take a version control system seriously. Even though CVS does suck.
--sam
PS Totally random comment but I wish Eclipse had a button to make a patch file out of any Compare viewer... then it would be perfect! Well, almost.
CVS integration is definitely the biggest reason why we tell new developers here to use Eclipse. (And that's because of the quality/ease of use of the integration compared to using a separate editor and TortoiseCVS, not compared to command-line or anything.)
Also the availability of a stable, complete Eclipse plugin would indicate that plugins for most other development environments are likely imminent, as that means that there's a full Java implementation (or else a full Java wrapper to a native-code implementation).
So, yes - if there isn't a finished plugin for the best known, most-successful IDE, I think it's still too early to take a version control system seriously. Even though CVS does suck.
--sam
PS Totally random comment but I wish Eclipse had a button to make a patch file out of any Compare viewer... then it would be perfect! Well, almost.
So, yes - if there isn't a finished plugin for the best known, most-successful IDE, I think it's still too early to take a version control system seriously.
When the version control system limits your development model or severely hurts it (and I'm not implying this is so in Moodle as of now), having a plugin for your favourite IDE/editor (be it the most-successful or not) shouldn't be the deciding factor.
If I don't switch to a VCS that helps me (instead of getting in my way) that is going to hurt the project as a whole, even if I feel more confortable with my IDE.
I've always tried to use the best tools for a given job, even if that meant learning to use new tools. For me that's part of the fun!
Saludos. Iñaki.
That's true, but you missed the point. I'm not saying that Eclipse support is a requirement for a version control system because I use Eclipse and I want my version control system integrated (I do want it, personally, but that shouldn't be a requirement).
I'm saying that support for Eclipse (because it's the most successful IDE) is a quick-and-dirty indication of a basic level of maturity for a version control system. If it doesn't have support for the biggest IDE (or if it does but that support is in alpha state or doesn't implement all the features people expect from the cvs plugin) then how likely is it to have support for the other IDEs that other people prefer? How likely is it to have nice, mature GUI standalone interfaces on all platforms? How likely is it that the system's APIs and code are flexible enough that it can easily be integrated into other programs and implemented in several languages? How likely is it that other applications such as bug trackers also include plug-ins to integrate with the version control system?
git actually does have plugins for lots of things (including of course Eclipse, and also the Moodle bug tracker, Jira) but a lot of them seem to be in a slightly sketchy, unfinished or untested state and/or still require complex install steps. So in other words though the system might have benefits, unless there's an urgent reason for moving from CVS, it's better to wait a few months until things mature a bit. CVS has been around for nearly 25 years so at least it is well understood and supported even if it does suck
--sam
I'm saying that support for Eclipse (because it's the most successful IDE) is a quick-and-dirty indication of a basic level of maturity for a version control system. If it doesn't have support for the biggest IDE (or if it does but that support is in alpha state or doesn't implement all the features people expect from the cvs plugin) then how likely is it to have support for the other IDEs that other people prefer? How likely is it to have nice, mature GUI standalone interfaces on all platforms? How likely is it that the system's APIs and code are flexible enough that it can easily be integrated into other programs and implemented in several languages? How likely is it that other applications such as bug trackers also include plug-ins to integrate with the version control system?
git actually does have plugins for lots of things (including of course Eclipse, and also the Moodle bug tracker, Jira) but a lot of them seem to be in a slightly sketchy, unfinished or untested state and/or still require complex install steps. So in other words though the system might have benefits, unless there's an urgent reason for moving from CVS, it's better to wait a few months until things mature a bit. CVS has been around for nearly 25 years so at least it is well understood and supported even if it does suck
--sam
Eclipse is your favourite IDE, I very frankly doubt it is the most successful... except among Java programmers. I am pretty sure that the market of IDEs is very segmented by development type. MS's Visual C#/C++ crowd probably has other favourites. The kernel/bsd/low-level unix tools folk are still on emacs/vi.
And maturity is not the main concern, or we'd be using BB instead of Moodle. Quality of the core tool *is* the most important metric, and the second one in my book is the dynamic of the community around it.
That's how I chose Moodle, that's how I chose git. Was moodle a tad rough around the edges at version 1.3? You bet! Was it clear that it was a fantastic platform on a speeding rocket to the moon? Sure was
Support for the well-cushioned-Eclipse will come in due course. In the meantime, you could use it as an excuse to play with the commandline which also lets you do some cool things like tail the logs
(Perhaps eclipse includes tail and grep. I haven't used it in ages.)
And maturity is not the main concern, or we'd be using BB instead of Moodle. Quality of the core tool *is* the most important metric, and the second one in my book is the dynamic of the community around it.
That's how I chose Moodle, that's how I chose git. Was moodle a tad rough around the edges at version 1.3? You bet! Was it clear that it was a fantastic platform on a speeding rocket to the moon? Sure was
Support for the well-cushioned-Eclipse will come in due course. In the meantime, you could use it as an excuse to play with the commandline which also lets you do some cool things like tail the logs
(Perhaps eclipse includes tail and grep. I haven't used it in ages.)
Support for the well-cushioned-Eclipse will come in due course. In the meantime, you could use it as an excuse to play with the commandline which also lets you do some cool things like tail the logs
I put it to you that the commandline is your IDE
FWIW, I don't think I would, and i've just found one such example why in my bash history from today:
git status | grep Modified | awk '{print $3}' | xargs vim -p
The pace of git is incredible though, so it wont be long till its got all its integration hooks.
I was expecting something rough round the edges before I first played with it and instead found beautiful little surprises. e.g. git diff if output is bigger than terminal size it'll send it through your pager, if smaller it wont. Small touch, saves me minutes each day.
BTW: if anyone from catalyst is reading this, your git moodle import hasn't been importing since 20080412
My fault, working on a fix now.
Import ran cleanly this morning and should be fine going forwards. I had moved some stuff around on that server so it supported importing from another cvs project into git and at some point permissions got a bit screwed.
Gentlemen - let me suggest that we revisit this issue over luncheon at the club in exactly (checks watch) six and half months from now.
*ahem*
gentlewhatnow?
(btw I agree that your editor should not influence your vcs choice.....
what was that axiom again about each individual tool doing its own task well? )
gentlewhatnow?
(btw I agree that your editor should not influence your vcs choice.....
what was that axiom again about each individual tool doing its own task well?