http://www.nabble.com/Thoughts-about-git-td16409123.html
I think I will have to start learning Java now!
Re: We can't let Sakai take the lead, can we? ;-)
It doesn't mean that git will do the programming for you!
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
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
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.
... 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... ;)
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/
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.
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.
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
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 And would you use supper-dooper-with-bells-on SCM if it was a gui application without command line support?
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
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? )