On Wednesday 27 January 2010 18:58:59 Oswald Buddenhagen wrote: > On Wed, Jan 27, 2010 at 10:46:52PM +0100, Thiago Macieira wrote: > > [...] The build rules are: [...] > > why not (mostly) keep our current layout in form of a meta structure (be > it git submodules or not)? build order would be determined by cmakelists > which declare subdirectories (and *nothing* else) as ever. breaking out > of that layout would happen at own peril, but any breakage will be > quickly detected anyway (as the projects' cmakelists must be > self-contained and dependency-complete).
Sorry about being so late to the party, catching up on emails... At Kitware we are also working on a migration from CVS (never made it to SVN) to Git. We currently use funky filesystem magic to have a VTK subdirectory in ParaView3 be the real VTK CVS directory, and similar magics... So we have been thinking a lot about some similar issues. I have also worked on Kalzium off an on, and Avogadro (which migrated to Git more than a year ago). Personally I have always hoped to see the KDE modules split up a little more, and the Git migration seems like the perfect time. I am working on the rules for the kde edu moduel too. We are working through similar workflow possibilities. I have been experimenting with what we can get out of submodules, and we have also been looking at possible changes to Git in the future, to facilitate a smoother workflow and recover some atomicity in supermodules. For most of my work on ParaView and VTK I would rather see the two decouple. With Kalzium it was always decoupled between Kalzium and libavogadro, but may be I never found the ideal workflow there. Lots of work to do there now that trunk is open again. > > On Wed, Jan 27, 2010 at 10:56:21PM +0100, Thiago Macieira wrote: > > And here's a suggestion to address those points, so a modification to the > > rules in the earlier email. > > > > Instead of having 4 stages per category, we actually have: > > libs > > libs2 > > libs3 > > ... > > you know, sysvinit is now moving away from fixed priorities to a > dependency-based system ... ;) > anyway, my private build script does effectively the same, so it isn't > that bad as such. :D I got the initial checkouts down to, 'git clone git.url', and 'git submodules update --init'. You can have the submodules checkout master by changing the .gitmodules file to use 'update = merge' in the submodule section. As a Kalzium developer when I first started out I never liked that I was supposed to checkout the entire module just to work on Kalzium, and always wanted an easy solution to just build that one app. See the example I pushed here, http://gitorious.org/kitware/babytitan/blobs/master/.gitmodules We are working on a shorter timeframe (hopefully migrating within the next few months). I am still working on issues with workflows, and moving over to Git from CVS. Splitting would also change the work I need to do with CDash/CTest, either way we have a solution but I prefer splitting. I didn't spot a good solution to moving apps into modules and preserviing history either. It seems that it becomes relatively simple with application level repositories. I will hopefully be able to keep up with this list now, sorry if I missed anything that was already discussed. Marcus _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
