[Kde-scm-interest] scripty questions

Chani chanika at gmail.com
Sun May 24 22:27:52 CEST 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090524/bc657445/attachment.sig 


More information about the Kde-scm-interest mailing list