On May 24, 2009 01:24:13 Thiago Macieira wrote: > Chani wrote: > >> If you really need to clone a specific directory, you have two > >> solutions: 1. Make the directory a separate repository and have it as > >> a submodule in the parent repository. Cons: Complex and not really > >> easy to use. 2. Don't use git for that directory; just fetch a tar.gz > >> via HTTP. Cons: Should be obvious. Not really a solution. > > > >or the ugly-hack solution: > >since scripty has to download all the modules anyways, have it copy the > > git doc folders into a separate folder, make that available online, and > > have the update_xml script rsync it or download a tgz of it or > > something. :/ > > > >none of these are good solutions, really. > > My suggestion is that we move the documentation out of each module's > repository. > > The simplest solution is that there is one repository for documentation, > which matches l10n-kde4/documentation today. Anybody who wishes to > translate documentation or write documentation has to clone this > repository. > > The other solution is that there be a submodule for documentation per > module. This submodule is linked to each module and from the equivalent of > l10n-kde4. > > The first solution represents the least diskspace used by translators (Git > repository compression works best when you have fewer repositories). > However, that is a lot more diskspace for developers when writing the > documentation itself. > > It's more hassle as well when trying to release an app, since you have to > somehow mark which commit in the documentation matches your release as > well as copy those files into your package.
there's also git subtree, an alternative to submodules: http://alumnit.ca/~apenwarr/log/?m=200904#30 which *looks* like the best of both worlds... however, pinotree doesn't think translators can handle any workflow change AT ALL, and he seems to count running anything other than "svn up" to fetch data as a workflow change. I can write a script to fetch all the documentation in git (heck, I could probably make it fetch the svn ones too if desired; it might be more reliable than the svn externals, which I *still* haven't fully downloaded despite trying a dozen times), but I can't make "svn up" magically run that script when appropriate. so, I see two options: 1) use git subtree and write a script to update the documentation folder, which update_xml would run automatically, and translators could run if they want to browse the latest english docs. pro: relatively clean (although it wastes some server disk space), no pain for packagers or developers con: I need the translators' consent, because they'd have to remember to run this script if they want documentation/ and haven't run update_xml recently. 2) have scripty copy the doc folder from each git-module into documentation/ and commit it to svn (chusslove's idea). pro: translators don't have to lift a finger, and still no pain for packagers or developers con: ugly. wastes disk space and svn revisions. (actually, there's a third option too: convince someone to write git- svnserver, a gsoc idea that doesn't seem to have been accepted. but that would take time.) -- This message brought to you by eevil bananas and the number 3. www.chani3.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
