Hi Howard!
I think this is one of those areas where workflow may well change with a shift to git.
There are two ways of managing something like contrib in git...
1. Make a git repository for each plugin, and use git-submodules to deploy them in a git moodle checkout in mod/whatever or blocks/whatever or wherever else.
2. Make a branch in another repository somewhere that includes Moodle (Branched from git.moodle.org) and adds your module/qtype/block/whatever. That way, if someone wants it, they can just
git remote add howard http://wherever
git fetch howard
git merge howard/somecoolmodule
Into their moodle git branch.
I am honestly pretty unsure about which is better.
1. is probably more complicated (I think git-submodules aren't that polished yet, although I could be wrong and DanP knows more about this than I do).
2. works fine and is probably more "gittish", but does make assumptions - eg that howard's "somecoolmodule" branch JUST contains the module and no other features. This really does enforce the workflow of feature branches and a single integration branch, which I think is a good thing, but is hard to enforce.
I think this is one of those areas where workflow may well change with a shift to git.
There are two ways of managing something like contrib in git...
1. Make a git repository for each plugin, and use git-submodules to deploy them in a git moodle checkout in mod/whatever or blocks/whatever or wherever else.
2. Make a branch in another repository somewhere that includes Moodle (Branched from git.moodle.org) and adds your module/qtype/block/whatever. That way, if someone wants it, they can just
git remote add howard http://wherever
git fetch howard
git merge howard/somecoolmodule
Into their moodle git branch.
I am honestly pretty unsure about which is better.
1. is probably more complicated (I think git-submodules aren't that polished yet, although I could be wrong and DanP knows more about this than I do).
2. works fine and is probably more "gittish", but does make assumptions - eg that howard's "somecoolmodule" branch JUST contains the module and no other features. This really does enforce the workflow of feature branches and a single integration branch, which I think is a good thing, but is hard to enforce.
Hi Fraulein Penny!
Git still makes my head melt but this *feels* like a situation where the svn/cvs model is more natural. As I've said before, though, it mostly comes down to someone making a decision and then documenting the workflow.
My other concern would be that a lot more people have access to contrib - so that's more reason to keep it simple and straightforward.
Git still makes my head melt but this *feels* like a situation where the svn/cvs model is more natural. As I've said before, though, it mostly comes down to someone making a decision and then documenting the workflow.
My other concern would be that a lot more people have access to contrib - so that's more reason to keep it simple and straightforward.
Hm, git-submodules basically does what svn:externals does. Which you can do in cvs (and svn too) by ignoring anything other than the current subdirectory I think.
I guess probably the best plan is to:
1. Set up the ability for people to have space in contrib to do whatever they want in git if they want to. We do this in Mahara, check out the following repos:
http://git.mahara.org/?p=contrib/pc.git;a=tree
http://git.mahara.org/?p=contrib/adminlang.git;a=tree
Both of which have an identical "tree" structure to Mahara.git, because they are using the approach in 2. in my last post. People are of course free to use the approach in 1.
Note that we are 100% not restricted to using git.moodle.org for this, that's one of the beauties of a distributed VCS.
2. Keep contrib CVS for as long as necessary, and run imports into git for plugins/* that can be used as sub-modules as required.
I guess probably the best plan is to:
1. Set up the ability for people to have space in contrib to do whatever they want in git if they want to. We do this in Mahara, check out the following repos:
http://git.mahara.org/?p=contrib/pc.git;a=tree
http://git.mahara.org/?p=contrib/adminlang.git;a=tree
Both of which have an identical "tree" structure to Mahara.git, because they are using the approach in 2. in my last post. People are of course free to use the approach in 1.
Note that we are 100% not restricted to using git.moodle.org for this, that's one of the beauties of a distributed VCS.
2. Keep contrib CVS for as long as necessary, and run imports into git for plugins/* that can be used as sub-modules as required.
Hello,
As Penny has already mentioned, we are using GIT for managing and maintaining the language package repositories in Mahara. Although I have never used it before, it was easy to learn the basic commands and it is easy to run from Ubuntu or linux.
Another suggestion is to use RapidSVN, which can be run from Windows.
In Sloodle.org, they just are using Googleapps as a sort of VCS.
Regards
As Penny has already mentioned, we are using GIT for managing and maintaining the language package repositories in Mahara. Although I have never used it before, it was easy to learn the basic commands and it is easy to run from Ubuntu or linux.
Another suggestion is to use RapidSVN, which can be run from Windows.
In Sloodle.org, they just are using Googleapps as a sort of VCS.
Regards
We use method 1), which I like because it makes it easier to track contrib module changes from upstream. So I
1) CVS import book module into git repository
2) In my moodle local branch add submodule for this book module
When I do a new local release, as well as updating from moodle upstream I can update from book module 'upstream' and then update my local branch to point to the new version of book.
The problem is, like you say, submodules aren't polished, in particular there is no good way to ensure you have done a checkout the submodule - the tools don't make this easy. So the flakeyness of it makes it difficult to recommend.
By the way, when I first started using submodules I had a grand plan of setting up a contrib git mirror which automatically make git repositories for each individual plugin, then other stuff got in the way and I never set it up. But i've just put the script in cvs:/contrib/tools/devtools/git-contrib-import.pl - if anyone else wants to give it a go.
1) CVS import book module into git repository
2) In my moodle local branch add submodule for this book module
When I do a new local release, as well as updating from moodle upstream I can update from book module 'upstream' and then update my local branch to point to the new version of book.
The problem is, like you say, submodules aren't polished, in particular there is no good way to ensure you have done a checkout the submodule - the tools don't make this easy. So the flakeyness of it makes it difficult to recommend.
By the way, when I first started using submodules I had a grand plan of setting up a contrib git mirror which automatically make git repositories for each individual plugin, then other stuff got in the way and I never set it up. But i've just put the script in cvs:/contrib/tools/devtools/git-contrib-import.pl - if anyone else wants to give it a go.
I think this is cleaner too. My only hesitation is that there exist modules that contain patches...
I think I've written three qtypes recently that rely on a patched formslib (See MDL-18405)
In which case, they live in plugins/question/type/foo/ , which contains a patches/ directory and a readme ;(
I think I've written three qtypes recently that rely on a patched formslib (See MDL-18405)
In which case, they live in plugins/question/type/foo/ , which contains a patches/ directory and a readme ;(
As far as I can tell, a git submodule can make its files live only within a single subdirectory in the project tree. See http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
Considering the fact that a Moodle contrib module can have its files scattered around pretty much anywhere in the Moodle tree (ie. under admin/ , blocks/ , etc.), using feature branches seems more logical.
The Wine project encourages working with feature branches. They have a nice tutorial at : http://wiki.winehq.org/GitBranches
Considering the fact that a Moodle contrib module can have its files scattered around pretty much anywhere in the Moodle tree (ie. under admin/ , blocks/ , etc.), using feature branches seems more logical.
The Wine project encourages working with feature branches. They have a nice tutorial at : http://wiki.winehq.org/GitBranches
"a Moodle contrib module can have its files scattered around pretty much anywhere in the Moodle tree"
Actually this is not true. Our plugins are always self-contained in one directory:
http://cvs.moodle.org/contrib/plugins/
Anything that isn't packaged this way is called a patch:
http://cvs.moodle.org/contrib/patches/
Actually this is not true. Our plugins are always self-contained in one directory:
http://cvs.moodle.org/contrib/plugins/
Anything that isn't packaged this way is called a patch:
http://cvs.moodle.org/contrib/patches/
200% agreed. Plugins are selfcontained. And submodules might be a good match for them... but git-submodules is quite tricky to use (at least now), and cvs isn't that bad for small single-developer codebases (which I assume contrib projects mainly are).
I'd frankly wait-and-see on contrib plugins.
Contrib 'patches' OTOH, are exactly where git shines. I can't imagine what an effective workflow can be using CVS now for any reasonably complex patchset.
I'd frankly wait-and-see on contrib plugins.
Contrib 'patches' OTOH, are exactly where git shines. I can't imagine what an effective workflow can be using CVS now for any reasonably complex patchset.
Plugins SHOULD be self contained but I think realistically we have to consider the case where the plugins are distributed with core patches.
Getting patches into core to support these sorts of needs isn't as easy as it used to be - that bug is almost 3 months old and doesn't break BC and is still apparently not acceptable for 1.9 since formslib is going to be rewritten anyway in 2.0.
I don't want to hijack this thread to whinge about that particular case though. I just think that with a lot more focus on exactly what is being committed the reality is that plugins in contrib are going to have to distribute patches more frequently and we need to have some way of managing them. There's a balance to be struck between quality and flexibility too.
When patches are included, git submodules are clearly not the way. Maybe back to the approach I suggested earlier of contrib feature branches. Or a combination of git submodules with quilt or topgit or some patch queue system.
Getting patches into core to support these sorts of needs isn't as easy as it used to be - that bug is almost 3 months old and doesn't break BC and is still apparently not acceptable for 1.9 since formslib is going to be rewritten anyway in 2.0.
I don't want to hijack this thread to whinge about that particular case though. I just think that with a lot more focus on exactly what is being committed the reality is that plugins in contrib are going to have to distribute patches more frequently and we need to have some way of managing them. There's a balance to be struck between quality and flexibility too.
When patches are included, git submodules are clearly not the way. Maybe back to the approach I suggested earlier of contrib feature branches. Or a combination of git submodules with quilt or topgit or some patch queue system.
Hmm this is quite interesting, I do actually use both submodules *and* feature branches and I don't think its ever going to be practical to put hook points for *everything* (tim makes an interesting point in his blog post on this subject).
In the case where I use submodules it just nice simple plugin/blocks which can be dropped in with git submodule. Even in this case a feature branch are more or less essential anyway to add your submodule reference on top of _STABLE anyway.
But for my 'patch' plugins - I have just put the whole thing in a feature branch and updating the plugin with changes from 'contrib' feels like a pain. When I look at these plugins, the majority of it is self contained in local/ - there are just maybe 1 or 2 core files patched to integrate it. So a combination of submodules with a patch queue systems might be interesting to explore and more maintainable (in principle - I dont like submodules implementation).
In the case where I use submodules it just nice simple plugin/blocks which can be dropped in with git submodule. Even in this case a feature branch are more or less essential anyway to add your submodule reference on top of _STABLE anyway.
But for my 'patch' plugins - I have just put the whole thing in a feature branch and updating the plugin with changes from 'contrib' feels like a pain. When I look at these plugins, the majority of it is self contained in local/ - there are just maybe 1 or 2 core files patched to integrate it. So a combination of submodules with a patch queue systems might be interesting to explore and more maintainable (in principle - I dont like submodules implementation).
To hijack your hijacking... I believe that anything along the lines of making plugins work properly and/or at all in as many places as possible in Moodle should be a big priority. One can pretty much forget getting stuff into core nowadays so the whole plugin/contrib thing is - and will - get more important by the day.
Or does it get less important because we are all using a distributed version control system which makes it easy track our local changes without enforcing them on upstream? 
(devil)
With git the worlds my oyster and I don't have a huge pain unpatching my local hacks
Playing devils advocate - I agree we must ensure the plugin points are adequate, but the beauty of git and open source is that I don't have to be limited by this
With git the worlds my oyster and I don't have a huge pain unpatching my local hacks
Playing devils advocate - I agree we must ensure the plugin points are adequate, but the beauty of git and open source is that I don't have to be limited by this
So, it seems like using git-submodule for plug-ins and a separate repository for each directory within the 'patches' area is what makes the most sense in this situation?
Does anyone know how many plug-ins within Contrib actually include patches at the moment? Is it enough that it would necessitate not going with the submodule approach?
Does anyone know how many plug-ins within Contrib actually include patches at the moment? Is it enough that it would necessitate not going with the submodule approach?