On Mon, Dec 01, 2008 at 05:53:34PM +0900, Sam Spilsbury wrote: > On Mon, Dec 1, 2008 at 8:39 AM, Kristian Lyngstol > <[EMAIL PROTECTED]> wrote: > > As some of you might have noticed, I've been experimenting with > > submodules for a few days. > > I assume this would work like svn and cvs handle submodules, ie, one > can clone 'compiz-fusion' which clones 'compiz', 'compizconfig', > 'ccsm', 'plugins-main', 'plugins-extra'? If so that I think what would > work quite well, considering the problems we have with the plugins-* > commit hook.
It's similar, yes, but not quite the same. For the technical differences, I couldn't really answer it without investigating svn further. However, svn just refers to a repository (afaik), while git submodules refer to a specific commit in that sub module. This means branching the super repository doesn't require any modification to the submodules; the super repository would refer to the commit checked out when the branch was made, even if the 'external' repository didn't have a branch and was updated later. It would certainly be easy on the server-side, but would require a bit of scripting on the "client side", since the super repository won't automatically update submodules unless the super repository have been manually updated since the submodule was changed. But that's already covered in my test-repo with scripts/update.all.sh, which just parses .gitmodules and runs git-pull && git-checkout master on all the submodules. It's an extra step, but no worse than having to manually git-pull compiz, compizconfig* and plugins-*. But we have to keep in mind that we already do a lot of scripting, like yags and get-git, which would essentially become redundant. > > [1] http://cgit.compiz-fusion.org/~kristian/cf-master-test/ > > Cool. > > Some questions: > > 1) Will /users be allowed to subrepo? Anyone can check out, of course. With regards to user-repositories, I'm not sure that would give us much of a benfit, but we should start actually using the WIP-category, but rename it "experimental". > 2) Can we have metarepos? i.e compiz-fusion-stable gets all the stable > bits and pieces and compiz-fusion-unstable grabs the latest > development version This isn't horribly interesting. The super repository would only contain a few scripts to glue it all together, and no real code. The development versions of Compiz and Compiz Fusion are, by default, considered unstable. A stable branch would be, say, compiz-fusion-0.8, and this is VERY easy to handle with a super repository, with no second repository needed. It would go like this: 1. Branch the super repository. 2. Done. Now continue working on master on the plugins, the branched super repo would refer to the commit that was checked out when the super repo was branched. If you need to update a component, you can do one of two things: Either just re-commit the updated master of the submodule. Or make a branch in the component, with starting point being the commit in the super repo branch, make your changes, commit to the branch, then commit this submodule commit to the super repo branch. It is also equally easy to work with tags. Make a 0.9.0 tag on the super repository, and while the tags don't propagate to the submodules, you can just check out the tag on the super repository and do "git-submodule update" and you have the submodules in the same state as when the tag was made. The whole point is that you don't actually work on the super repository at all. It's just a convenience repository that allows us to gather everything up and create a proper build-system collection for git-users. There is some work required, though, notably with buildsystems for plugins, and perhaps a decision on whether to just use a simple bash script to build everything, or create a Makefile or something similar (CMake?). - Kristian
signature.asc
Description: Digital signature
_______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
