Hi All,
I recently setup several add-on modules for a new instance of moodle I'm running, and had a very frustrating experience finding the latest versions of each. Several modules were attachments to forum threads, while some were hosted off the moodle site, etc. Getting consistent/reliable info about any of these add-ons was near impossible.
GForge.org is a very slick, free, opensource package (forked from sourceforge.net software a few years ago) that would provide a sourceforge.net like interface for only moodle projects.
GForge.org also provides both CVS and SVN access.
moodleforge.org domain is available. I think moodleforge.org would be a perfect incubator for add-on modules that may eventually be adopted upstream by the main moodle project. In the meantime, it provides a straight-forward interface where folks can find what they are looking for, and have it properly versioned. etc.
Thoughts? Anybody else frustrated with current setup for finding/downloading add-on modules or am I just out there on this?
Thanks,
John
Well, the downloads page has a great "modules" link. All the interesting modules in contrib are there. Nag the authors of those modules to make sure they are there for them to be easy to find (and so that they find a wider audience).
If you create a new site, you'll have to nag the authors of the modules already in the download page plus the authors of all those other modules to help you keep it up to date. More work for you -- and more places to go to for users, less efficiency ;)
On the other hand, and talking about GForge, yes, there's an education oriented (and heavily Moodle oriented) GForge out there: Eduforge.org -- the NZVLE team runs it
But for Moodle modules, Moodle.org has CVS (via sourceforge.org) a great download page, has forums, the bugtracker... I keep track a lot of Moodle-related development and I really appreciate that it's all in one site, one place, one user acct to have (and to lose the password for).
Here's the page: http://download.moodle.org/modules/ ... let's nag those lazy module maintainers to ensure they are listed there.
If you create a new site, you'll have to nag the authors of the modules already in the download page plus the authors of all those other modules to help you keep it up to date. More work for you -- and more places to go to for users, less efficiency ;)
On the other hand, and talking about GForge, yes, there's an education oriented (and heavily Moodle oriented) GForge out there: Eduforge.org -- the NZVLE team runs it
But for Moodle modules, Moodle.org has CVS (via sourceforge.org) a great download page, has forums, the bugtracker... I keep track a lot of Moodle-related development and I really appreciate that it's all in one site, one place, one user acct to have (and to lose the password for).
Here's the page: http://download.moodle.org/modules/ ... let's nag those lazy module maintainers to ensure they are listed there.
Well, specifically, I am putting together a completely hands-off, self-paced course. So, I decided to use Activity Locking, Feedback, and Certificates modules. These 3 are all very useable modules, yet none of them are listed on the moodle downloads page.
As far as eduforge.org. That looks good, but something that was specific to moodle (moodleforge.org) would be optimal. Considering the size of the moodle community, I think a moodle instance of gforge would be a very busy place.
The idea that you need to encourage (nag) developers to get their stuff onto the downloads page indicates to me that there is a problem. Why aren't they putting them up there? Is it too difficult?
It seems reasonable that on the main download page, you only want high-quality modules listed, but this is where an incubator comes in. You need a place where projects can grow-up to become high-quality modules that can then get listed on the main site. Right now, it is just a mish-mash of modules posted here and there, and everywhere.
With GForge, you just sign-up and it creates the repository, etc and you are off to the races. You then post the announcement of your project on moodle, but the SVN/CVS development happens there.
Maybe it is just wishful thinking, but I think that such a setup would really improve the collaborative development of these add-on modules.
Regards,
John
As far as eduforge.org. That looks good, but something that was specific to moodle (moodleforge.org) would be optimal. Considering the size of the moodle community, I think a moodle instance of gforge would be a very busy place.
The idea that you need to encourage (nag) developers to get their stuff onto the downloads page indicates to me that there is a problem. Why aren't they putting them up there? Is it too difficult?
It seems reasonable that on the main download page, you only want high-quality modules listed, but this is where an incubator comes in. You need a place where projects can grow-up to become high-quality modules that can then get listed on the main site. Right now, it is just a mish-mash of modules posted here and there, and everywhere.
With GForge, you just sign-up and it creates the repository, etc and you are off to the races. You then post the announcement of your project on moodle, but the SVN/CVS development happens there.
Maybe it is just wishful thinking, but I think that such a setup would really improve the collaborative development of these add-on modules.
Regards,
John
> Why aren't they putting them up there? Is it too difficult?
I think you hit the nail in the head here. Perhaps we should nag MD to make a self-submitted unofficial modules list/directory that is really easy for module authors to maintain. For it to work, it probably has to be a good vehicle for promoting their modules. (Edit: thinking out of the box -- perhaps a glossary?)
Bear in mind that most modules are already in /contrib and if they aren't there, is mostly because the authors didn't want them to be in a central location or didn't care enough.
Module authors know, or should know, that by having the modules in /contrib they make sure that the core developers see emails when they make commits -- a strange but useful kind of self promotion
I think you hit the nail in the head here. Perhaps we should nag MD to make a self-submitted unofficial modules list/directory that is really easy for module authors to maintain. For it to work, it probably has to be a good vehicle for promoting their modules. (Edit: thinking out of the box -- perhaps a glossary?)
Bear in mind that most modules are already in /contrib and if they aren't there, is mostly because the authors didn't want them to be in a central location or didn't care enough.
Module authors know, or should know, that by having the modules in /contrib they make sure that the core developers see emails when they make commits -- a strange but useful kind of self promotion
Perhaps we should nag MD to make a self-submitted unofficial modules
list/directory that is really easy for module authors to maintain. For
it to work, it probably has to be a good vehicle for promoting their
modules.
Yes, yes. Please do that! I have two incubating modules that I want to make available more widely than just posting on the General Developer forum. Sorry, I don't know about CVS and how to find it or contribute to it. I would love if we have something like a Not-Ready-for-Standard-Release Module Downloads page for people like me to browse.
Yes, yes. Please do that! I have two incubating modules that I want to make available more widely than just posting on the General Developer forum. Sorry, I don't know about CVS and how to find it or contribute to it. I would love if we have something like a Not-Ready-for-Standard-Release Module Downloads page for people like me to browse.
The idea of such a repository sounds great. I would suggest to set it up so not just modules can be kept there but also patches/hacks, extra blocks, etc. There is a number of those floating around, some of them used by quite a few people and even kept updated. It would be nice if one did not have to scavenge forums to find these and their latest versions. Since not all of those authors may be CVS-savvy, having simple ftp access as option would be a plus.
Good idea. I once had something to contribute and was told by Martin how to get CVS access but it just didn't work, and my request for help went unanswered in the forums. Fortunately, someone else eventually got it into Contrib (and I missed out on the self-promotion), but I believe a lot of people would be willing to put things in CVS if it were doable.
May be make download's index in wiki? Integrated into MoodleDocs, for example? And leave CVS in sourceforge...
I'm painfully aware of this problem.
We have been working very hard on the Database module for months and the main reason I want it finished is to solve exactly this problem. Not long now! You'll love it!
For CVS there is no need for any more forge sites or anything else, we have a contrib section on sourceforge cvs:/contrib to which I give access fairly freely. All those directories are balled up every night as http://download.moodle.org/download.php/modules/directory.zip.
If you really want to you can set up your own sub project there (as some others have done)
We have been working very hard on the Database module for months and the main reason I want it finished is to solve exactly this problem. Not long now! You'll love it!
For CVS there is no need for any more forge sites or anything else, we have a contrib section on sourceforge cvs:/contrib to which I give access fairly freely. All those directories are balled up every night as http://download.moodle.org/download.php/modules/directory.zip.
If you really want to you can set up your own sub project there (as some others have done)
Is there anywhere that people can see a list of the zips? I had no idea that my contrib projects were being bundled up - it would have saved me some effort in doing the zipping myself!
It would be nice if the download page had a tiny little link somewhere for "display a complete list of user-contributed downloads". I appreciate that because some contrib projects may be very immature, the link definitely shouldn't be emphasised.
It would be nice if the download page had a tiny little link somewhere for "display a complete list of user-contributed downloads". I appreciate that because some contrib projects may be very immature, the link definitely shouldn't be emphasised.
Hi Dan,
Basically, cvs: moodle/contrib lists all contrib projects. As Martin mentions, any directory may be downloaded using http://download.moodle.org/download.php/modules/directory_name.zip e.g. http://download.moodle.org/download.php/modules/webctimport.zip.
Please note that within CVS, the word "modules" refers to separate collections of code.
Basically, cvs: moodle/contrib lists all contrib projects. As Martin mentions, any directory may be downloaded using http://download.moodle.org/download.php/modules/directory_name.zip e.g. http://download.moodle.org/download.php/modules/webctimport.zip.
Please note that within CVS, the word "modules" refers to separate collections of code.
Martin, thanks for the straightforward reply 
I think the database will solve part of this problem, but not all of it. Would you share your vision of how this will work?
How will this solve the inconsistency problem? For example (apologies in advance to the module author) let's take the activity locking module. If you look in the cvs:/contrib directory, the version there is 4 months old. Yet, in this thread (http://moodle.org/mod/forum/discuss.php?d=35488) attached as a zip file is a newer version of activity locking dated only 2 months ago.
How or why that happened, I'm not sure, but it certainly makes for lots of confusion and wasted time sorting it out. I do have a guess, and that is that the author felt he would get more exposure by posting on the forum than updating the CVS
Is this a solvable problem? IMHO, only a system that encourages and promotes material being stored in contrib and ensures that updates in contrib are automatically made available or with minimal effort to the new 'database'.
So my question to you, is how might a 'database' module solve this?
Some other thoughts on version control. Version control isn't difficult stuff, but it seems there is a segment of folks here who haven't (for one reason or another) become familiar with it. Perhaps, proper encouragement (when they see CVS stuff automatically appearing on moodle.org) and how-to's would go a long way toward getting all that good work that is floating around these forums into a more structured and useful format.
Finally, sourceforge.net subversion support is in beta now and supposed to be offered across the board in Feb 2006 (http://sourceforge.net/docman/display_doc.php?group_id=1&docid=19242). Have you given any thought to switching over? The improved merging, better branch support, and atomic commits (changesets) would make YOUR life much easier. Being able to link/reference a specific changeset is a huge improvement over CVS. Trac is a great example of how beautifully this integration can work.
Sorry for being so long-winded
Regards,
John
I think the database will solve part of this problem, but not all of it. Would you share your vision of how this will work?How will this solve the inconsistency problem? For example (apologies in advance to the module author) let's take the activity locking module. If you look in the cvs:/contrib directory, the version there is 4 months old. Yet, in this thread (http://moodle.org/mod/forum/discuss.php?d=35488) attached as a zip file is a newer version of activity locking dated only 2 months ago.
How or why that happened, I'm not sure, but it certainly makes for lots of confusion and wasted time sorting it out. I do have a guess, and that is that the author felt he would get more exposure by posting on the forum than updating the CVS
So my question to you, is how might a 'database' module solve this?
Some other thoughts on version control. Version control isn't difficult stuff, but it seems there is a segment of folks here who haven't (for one reason or another) become familiar with it. Perhaps, proper encouragement (when they see CVS stuff automatically appearing on moodle.org) and how-to's would go a long way toward getting all that good work that is floating around these forums into a more structured and useful format.
Finally, sourceforge.net subversion support is in beta now and supposed to be offered across the board in Feb 2006 (http://sourceforge.net/docman/display_doc.php?group_id=1&docid=19242). Have you given any thought to switching over? The improved merging, better branch support, and atomic commits (changesets) would make YOUR life much easier. Being able to link/reference a specific changeset is a huge improvement over CVS. Trac is a great example of how beautifully this integration can work.
Sorry for being so long-winded
Regards,
John
John, it will be good, trust me.
1) People can still promote new stuff in the forums, but the definitive list will be in the new listing made with the Database module. It's up to authors to update CVS, obviously, but we can encourage them. Most do update in CVS, this is not a major problem.
2) CVS works fine the way we use it, I don't have any problems with it - changing to something else is a BIG thing and will not be happening in the near future. I hear a lot of negative stuff about Subversion in particular.
1) People can still promote new stuff in the forums, but the definitive list will be in the new listing made with the Database module. It's up to authors to update CVS, obviously, but we can encourage them. Most do update in CVS, this is not a major problem.
2) CVS works fine the way we use it, I don't have any problems with it - changing to something else is a BIG thing and will not be happening in the near future. I hear a lot of negative stuff about Subversion in particular.
Ok. I have been using subversion for about 6 months now, and won't be looking back. CVS is definitely history for me. I would be interested to hear about your perceived negatives for subversion.
And now for the 'if they are doing it, it must be ok argument': If a site like sourceforge.net is ready to roll-out subversion, I can't believe they wouldn't have done their homework on it.
Regards,
John
And now for the 'if they are doing it, it must be ok argument': If a site like sourceforge.net is ready to roll-out subversion, I can't believe they wouldn't have done their homework on it.
Regards,
John
And on the "talk to people who know" track, Eduforge supports subversion and I've written good chunks of that support myself (GForge had an incomplete implementation that I finished up). So you could say I've done my homework and if you want to look, at the last Linux.conf.au I've hosted a techical talk on Subversion together with Sam Vilain. (Of course, I also hosted a technical talk on an SCM that is actually good, but that's an anecdote for another day ).
SVN has very limited -- read "useless" -- support for branching and merging (actually -- they copied the functionality of the branching/merging tools that CVS has). I can understand you won't look back at CVS -- who would!? But being better than CVS is way too low a goal -- and SVN's design is marred by the fact that they looked at CVS way too much.
SVN is be reasonably good for single developers or small in-house teams. It is no improvement over CVS for a project like Moodle.
Moodle core today has 13K files and ~40 committers. I don't know of any project that size using SVN happily. If you want to perform an experiment try running a CVS2SVN import preserving history and all the branches. Try and work with a checkout from that SVN repo.
... and for comparison, try git-cvsimport ...
SVN has very limited -- read "useless" -- support for branching and merging (actually -- they copied the functionality of the branching/merging tools that CVS has). I can understand you won't look back at CVS -- who would!? But being better than CVS is way too low a goal -- and SVN's design is marred by the fact that they looked at CVS way too much.
SVN is be reasonably good for single developers or small in-house teams. It is no improvement over CVS for a project like Moodle.
Moodle core today has 13K files and ~40 committers. I don't know of any project that size using SVN happily. If you want to perform an experiment try running a CVS2SVN import preserving history and all the branches. Try and work with a checkout from that SVN repo.
... and for comparison, try git-cvsimport ...
John -- one of the things that you have to consider is that using GForge adds more steps and more inconsistencies. I should know -- we are running Eduforge.org and I'm very familiar with what it takes to use it and how it works internally. When you are using Moodle.org everything is here.
If there was a benefit to the Moodle community to be using a GForge site for module development... I'd be on your side and promoting it.
The other thing to consider is that GForge is really hard to deploy and maintain, specially if you plan on offering SVN/CVS in a secure manner. You need a lot of knowledge of PAM-LDAP/PAM-Pg, chrooted environments, CVS and SVN repo internal structures, email server configuration, the works.
Oh, and something else -- as someone who has used version control systems a lot, I have to agree with MD here. SVN is a small marginal improvement over CVS in some areas, but neither of them are good. Moodle is fine at the moment with CVS, but switching to SVN would be a huge undertaking for little or no benefit.
If you are interested in SCMs, there's a new generation of SCMs that do the right thing. Think BitKeeper, Mercurial, BazaarNG (aka bzr), darcs and GIT. I work on GIT in my spare time, so I'd suggest you try GIT or Cogito (which is easier to learn). Any of these are good.
If there was a benefit to the Moodle community to be using a GForge site for module development... I'd be on your side and promoting it.
The other thing to consider is that GForge is really hard to deploy and maintain, specially if you plan on offering SVN/CVS in a secure manner. You need a lot of knowledge of PAM-LDAP/PAM-Pg, chrooted environments, CVS and SVN repo internal structures, email server configuration, the works.
Oh, and something else -- as someone who has used version control systems a lot, I have to agree with MD here. SVN is a small marginal improvement over CVS in some areas, but neither of them are good. Moodle is fine at the moment with CVS, but switching to SVN would be a huge undertaking for little or no benefit.
If you are interested in SCMs, there's a new generation of SCMs that do the right thing. Think BitKeeper, Mercurial, BazaarNG (aka bzr), darcs and GIT. I work on GIT in my spare time, so I'd suggest you try GIT or Cogito (which is easier to learn). Any of these are good.
While I can appreciate that it may not be the right time to wholly switch from
CVS to SVN, I would urge that this be given due consideration at some point
over the next year (or 2).
CVS is no longer under active development, whereas SVN is quite active.
From where I'm standing, it's just a matter of time before SVN replaces CVS.
There are several largish features that SVN does bring to the table which are
not in CVS:
1) deleting directories. It's not possible to delete a directory within CVS entirely,
you are always left with blank directories. This does get in the way of renaming
directories. The usual fix is to run around to the
CVS file store and delete directly. This is a vestige of an original design decision
for CVS. SVN does provide for this feature.
2) storing binaries as diffs. CVS stores any non-text file in it's entirety,
where as SVN stores them as diffs just like text files. This has a fair sized
impact on the total storage used, as non-text files tend to dominate.
3) handling multiple commits at-the-same time. If you get very active
commitors that do largish commits concurrently, CVS can have trouble.
While only a factor in rather large projects, in time this could become an
occasional issue. SVN has a more sophisticated approach, several in fact.
Of course, SVN is itself a work-in-progress, so it's not shocking to me if
there are reports of problems. CVS was a leap of faith over the earlier RCS
back in 1995, and hardly anyone uses RCS now. As I say, in time I see SVN replacing CVS, this is where the energy
is going on new developement, there hasn't been a CVS release for years.
CVS to SVN, I would urge that this be given due consideration at some point
over the next year (or 2).
CVS is no longer under active development, whereas SVN is quite active.
From where I'm standing, it's just a matter of time before SVN replaces CVS.
There are several largish features that SVN does bring to the table which are
not in CVS:
1) deleting directories. It's not possible to delete a directory within CVS entirely,
you are always left with blank directories. This does get in the way of renaming
directories. The usual fix is to run around to the
CVS file store and delete directly. This is a vestige of an original design decision
for CVS. SVN does provide for this feature.
2) storing binaries as diffs. CVS stores any non-text file in it's entirety,
where as SVN stores them as diffs just like text files. This has a fair sized
impact on the total storage used, as non-text files tend to dominate.
3) handling multiple commits at-the-same time. If you get very active
commitors that do largish commits concurrently, CVS can have trouble.
While only a factor in rather large projects, in time this could become an
occasional issue. SVN has a more sophisticated approach, several in fact.
Of course, SVN is itself a work-in-progress, so it's not shocking to me if
there are reports of problems. CVS was a leap of faith over the earlier RCS
back in 1995, and hardly anyone uses RCS now. As I say, in time I see SVN replacing CVS, this is where the energy
is going on new developement, there hasn't been a CVS release for years.
Martin,
Points taken. However, the technical difficulties of administering an environment aren't really relevant to the users using them. But again, I understand your point.
Regarding SCM, to each his own, I guess. I certainly think, contrary to you, that SVN is much more than a 'marginal improvment' over CVS.
I too have used version control alot. Perhaps the entire KDE project made a bad choice moving from CVS to subversion? I don't think so
I am familiar with BitKeeper (now closed source), Mercurial, BazaarNG (ubuntu uses/sponsors development of this), darcs, etc. Not sure why you include GIT in there. Even Linus does not consider this an SCM.
The whole distributed SCM vs centralized SCM argument is very interesting and I think most people agree that choosing one over the other really depends on the kind of project you are working on. For the linux kernel, clearly the distributed model is better. For moodle, I don't know. Probably centralized.
Anyway, we are a bit off-topic here. I just want to solve the problem of making it sane to research and get source for modules (as well as contribute patches, etc).
John
Points taken. However, the technical difficulties of administering an environment aren't really relevant to the users using them. But again, I understand your point.
Regarding SCM, to each his own, I guess. I certainly think, contrary to you, that SVN is much more than a 'marginal improvment' over CVS.
I too have used version control alot. Perhaps the entire KDE project made a bad choice moving from CVS to subversion? I don't think so
I am familiar with BitKeeper (now closed source), Mercurial, BazaarNG (ubuntu uses/sponsors development of this), darcs, etc. Not sure why you include GIT in there. Even Linus does not consider this an SCM.
The whole distributed SCM vs centralized SCM argument is very interesting and I think most people agree that choosing one over the other really depends on the kind of project you are working on. For the linux kernel, clearly the distributed model is better. For moodle, I don't know. Probably centralized.
Anyway, we are a bit off-topic here. I just want to solve the problem of making it sane to research and get source for modules (as well as contribute patches, etc).
John
> I am familiar with BitKeeper (now closed source), Mercurial,
> BazaarNG (ubuntu uses/sponsors development of this), darcs, etc.
> Not sure why you include GIT in there. Even Linus does not
> consider this an SCM.
That was true at the beginning. Now, the UI has improved heaps (or you can use Cogito for a simpler cvs/svn like inteface). There are _heaps_ of projects switching to GIT. Wine is one. Just been at Linux.conf.au -- we had Martin Poole (BazaarNG author), the guy behind Mercurial, and Linus.
People from almost all the large projects were asking about GIT. And the X.org/Cairo guys (their checkout is 4x the size of the kernel tree, and they have 20 years of source control history) are 99.9% there in switching to GIT. Take a look at the LCA thread and the [Census] subthread here: http://www.gelato.unsw.edu.au/archives/git/0601/index.html#15542 and bear in mind that some people posting are really heavy hitters (Keith Packard is one of the guys who designed X 20 years ago, and is still one of the core hackers.)
I sat down with them and imported their last ~5 years of history in a couple of hours. They've been fiddling with it since, and according to Keith, Cairo is switching immediately.
> Anyway, we are a bit off-topic here.
Indeed -- but we there are SCM geeks in the room. You can't expect to mention SVN and CVS in the same line and _not_ get a flamewar!
> I just want to solve the problem of making it sane to research
> and get source for modules (as well as contribute patches,
> etc).
Yep, and doing it from the downloads page is the sane place. MD doesn't want it to fragment, and I wholeheartedly agree. Less steps, less places to go to. Just give him some time to get mod/database sorted. Perhaps offer some help?
> BazaarNG (ubuntu uses/sponsors development of this), darcs, etc.
> Not sure why you include GIT in there. Even Linus does not
> consider this an SCM.
That was true at the beginning. Now, the UI has improved heaps (or you can use Cogito for a simpler cvs/svn like inteface). There are _heaps_ of projects switching to GIT. Wine is one. Just been at Linux.conf.au -- we had Martin Poole (BazaarNG author), the guy behind Mercurial, and Linus.
People from almost all the large projects were asking about GIT. And the X.org/Cairo guys (their checkout is 4x the size of the kernel tree, and they have 20 years of source control history) are 99.9% there in switching to GIT. Take a look at the LCA thread and the [Census] subthread here: http://www.gelato.unsw.edu.au/archives/git/0601/index.html#15542 and bear in mind that some people posting are really heavy hitters (Keith Packard is one of the guys who designed X 20 years ago, and is still one of the core hackers.)
I sat down with them and imported their last ~5 years of history in a couple of hours. They've been fiddling with it since, and according to Keith, Cairo is switching immediately.
> Anyway, we are a bit off-topic here.
Indeed -- but we there are SCM geeks in the room. You can't expect to mention SVN and CVS in the same line and _not_ get a flamewar!
> I just want to solve the problem of making it sane to research
> and get source for modules (as well as contribute patches,
> etc).
Yep, and doing it from the downloads page is the sane place. MD doesn't want it to fragment, and I wholeheartedly agree. Less steps, less places to go to. Just give him some time to get mod/database sorted. Perhaps offer some help?
Martin L.,
Just read the thread in the link you provided. Wow...it certainly seems like the distributed SCM landscape/uptake is changing rapidly. I last looked into distributed SCM's last year right after the BitKeeper fiasco. But it seems like now, that perhaps the BitKeeper thing was really a blessing in disguise. Now, I'll just humbly crawl back under my rock...
It was interesting to note Linus' explanation of how lstat() makes GIT so fast on linux and that it stinks on NTFS. Won't this hinder GIT for cross-platform projects? (not that Linus cares about that)
Also, it seems like there is a general lack of GUI clients for distributed SCM's, although as you say, this is changing (qgit looks pretty good). To be a viable replacement for CVS in a project like moodle (think cross-platform development; lots of windows users), I think GUI SCM clients are necessary. Same for IDE's; Virtually all PHP IDE's offer CVS integration and are now getting around to offering SVN integration.
Is it too early to pick a 'winner' for the open source distributed SCM race? When will we see good gui clients and integration with IDE's?
I will still be using SVN for my small-shop needs, but will keep an eye on distributed SCM's
Also, I'm looking forward to MD's 'database' solution. Anything will be better than the current arrangement As a very part-time moodler, I'm not sure how much of a help I'd be, but if there is something I can do, please let me know! Moodle has certainly been good to me, and I know any help is better than none.
John
Just read the thread in the link you provided. Wow...it certainly seems like the distributed SCM landscape/uptake is changing rapidly. I last looked into distributed SCM's last year right after the BitKeeper fiasco. But it seems like now, that perhaps the BitKeeper thing was really a blessing in disguise. Now, I'll just humbly crawl back under my rock...
It was interesting to note Linus' explanation of how lstat() makes GIT so fast on linux and that it stinks on NTFS. Won't this hinder GIT for cross-platform projects? (not that Linus cares about that)
Also, it seems like there is a general lack of GUI clients for distributed SCM's, although as you say, this is changing (qgit looks pretty good). To be a viable replacement for CVS in a project like moodle (think cross-platform development; lots of windows users), I think GUI SCM clients are necessary. Same for IDE's; Virtually all PHP IDE's offer CVS integration and are now getting around to offering SVN integration.
Is it too early to pick a 'winner' for the open source distributed SCM race? When will we see good gui clients and integration with IDE's?
I will still be using SVN for my small-shop needs, but will keep an eye on distributed SCM's
Also, I'm looking forward to MD's 'database' solution. Anything will be better than the current arrangement
John
> Is it too early to pick a 'winner' for the open source
> distributed SCM race? When will we see good gui clients and
> integration with IDE's?
Just today I heard that there's a Darcs-Eclipse plugin in existence... and I heard it from someone who's working towards a GIT-Eclipse plugin.
So the answer is: Soon.
> distributed SCM race? When will we see good gui clients and
> integration with IDE's?
Just today I heard that there's a Darcs-Eclipse plugin in existence... and I heard it from someone who's working towards a GIT-Eclipse plugin.
So the answer is: Soon.
Oh, forgot to mention...
> For the linux kernel, clearly the distributed model is better.
> For moodle, I don't know. Probably centralized.
Agreed. In any case, GIT is a better centralized SCM than CVS or SVN. At Catalyst, we use it mostly in a centralized fashion -- all our team commits/pushes to the same repo and we are forced to be up to date (almost) all the time.
It does get distributed-ish if I go away with my laptop for a few days and commit onto my laptop -- it's easy to push onto the repo after updating my checkout with what others have done (not unlike cvs/svn -- "update before commit" becomes "update before push"). But that's really cream on top.
> For the linux kernel, clearly the distributed model is better.
> For moodle, I don't know. Probably centralized.
Agreed. In any case, GIT is a better centralized SCM than CVS or SVN. At Catalyst, we use it mostly in a centralized fashion -- all our team commits/pushes to the same repo and we are forced to be up to date (almost) all the time.
It does get distributed-ish if I go away with my laptop for a few days and commit onto my laptop -- it's easy to push onto the repo after updating my checkout with what others have done (not unlike cvs/svn -- "update before commit" becomes "update before push"). But that's really cream on top.