[Digikam-devel] Re: Git migration and submodules

[Andreas Pakulat]

[ Leaving out kwrite-devel as this concerns digikam only ]

Please cc me on replies as I'm not subscribed to the list.

On 22.12.10 10:27:46, Marcel Wiesweg wrote:
> 
> > The structure on projects.kde.org will also be used to create the KDE SC
> > releases. So for example even if modules like kdeedu or kdegames are
> > split up into several git repositories, the KDE SC release will still
> > ship a kdeedu.tar.bz2 (at least thats the current plan as far as I
> > know) that assembles all of the sources of the various repositories.
> 
> Creating tarballs is fine for the main KDE modules, but in digikam we have a 
> slightly different problem: There is one application with a number of 
> dependencies, which will be spread out over 7 repos.
> 
> We would like to give the user one repository which, when cloned, has all the 
> code necessary and builds just out of the box.

How about leveraging projects.kde.org infrastructure and help the
sysadmins get those xml files in place which allow tools such as
kdesrc-build to fetch all of those repositories 'at once with minimal
setup effort'? 

> It's not about tarballs or releases, it's about users who want to run latest 
> Git code to see if their problem was fixed by a commit.

A user having to setup the compilation of 7 repositories is however a
one-time thing with todays build-tools (not cmake, but the meta-tools
like kdesrc-build). On the other hand, keeping this meta-repository
compiling and working and not letting it bitrot is an every-day effort
for all involved developers.

Not to mention that if the fix is on a particular branch then such a
meta-repository won't help users either, as cloning it and updating its
submodules will always only update them to a specific commit from the
corresponding upstream. So the user still has to change into the
subdirectories and adjust the remote and/or branch manually.

> There will be additionally some very lightweight CMake glue and a README file 
> in this toplevel directory, and these file also need to have a place 
> somewhere.
> 
> The problem is that git submodules dont track the latest HEAD of the 
> referenced repos. The issue is discussed here:
> 
> http://jonathan-oliver.blogspot.com/2009/10/git-submodules-like-
> svnexternals.html
> 
> but, unfortunately, and although you'll find patches with Google, not 
> implemented by git as of yet.
> So currently it seems git-submodules is insufficient for our needs and it's 

Heh, I guess I should've read this part first before writing the above
comments :)... 

> necessary to provide a script in the toplevel directory which pulls all sub-
> repos.

Well, instead of writing your own, it may really make sense to help
sysadmins with those xml files and kdesrc-build (or other tools) to use
them. This could also solve the problem of the README, the text could
simply be part of your projects description and the xml file could
contain that description. This way kdesrc-build can generate a README
while setting up the top-level directory.

Andreas

-- 
You'll never see all the places, or read all the books, but fortunately,
they're not all recommended.