Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis <simos lists googlemail com>]

On Sun, Jan 18, 2009 at 9:55 AM, Gil Forcada <gforcada gnome org> wrote:
> There isn't an option (I have read it somewhere, sorry for bad
> references) that tells git to only download the last version and not the
> full history?

There is an option '--depth 1' that you can use when you clone a repository.
Depending on the module, I noticed it gives up to moderate time and
space improvements.
git.gnome.org is now down, so I tried with
git://anongit.freedesktop.org/git/xorg/xserver

Clone: 1.43 min, objects 26.19 MiB, directory size 55MB
Shallow clone: 50s, objects 16.22 MiB, directory size 43MB

I also tried with the Linux kernel,
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Clone: 9.10min, objects 258.23 MiB, directory size 660MB
Shallow clone: 5.38min, objects 152.34 MiB, directory size 531MB

When cloning, the 'Receiving objects' stage is the one that takes most
of the time
and refers to compressed data. I suppose it is a good indication of
the total time.

When I tried the other day with git.gnome.org, I noticed much slower times.
It appears the reason is that git.gnome.org (test server) was very
slow when I tried it,
achieving up to 100KB/s at best. With X.Org and the Linux kernel, the
speed was most of the time at 800KB/s.

In addition, the 'git clone' man page mentions

"--depth <depth>

    Create a shallow clone with a history truncated to the specified
number of revisions. A shallow repository has a number of limitations
(you cannot clone or fetch from it, nor push from nor into it), but is
adequate if you are only interested in the recent history of a large
project with a long history, and would want to send in fixes as
patches."

It says that you cannot "push from [a shallow clone]", which means
that a translator would not be able to push a translation from a
shallow clone. I tried with a small repository where I have push
access and I was able to push a commit from a shallow clone to the git
server. This may be some feature on GitHub; all Google searches for
'shallow clone' repeat that you cannot push your changes from your
shallow clone.
It would be important to try this one out on git.gnome.org, when it is
available.

Simos

> Cheers,
>
> El dg 18 de 01 de 2009 a les 00:01 +0000, en/na Simos Xenitellis va
> escriure:
>> On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen <k nielsen81 gmail com> wrote:
>> > 2009/1/16 Gil Forcada <gforcada gnome org>:
>> >>
>> >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va
>> >> escriure:
>> >>> On 1/15/09, Claude Paroz <claude 2xlibre net> wrote:
>> >>> > Le mardi 13 janvier 2009 à 23:01 +0000, Simos Xenitellis a écrit :
>> >>> >  > This is a long-ish post regarding the migration to Git and
>> >>> >  > what we can do to make l10n a bit better.
>> >>> >  >
>> >>> >  > Here I suggest to use the 'git submodule' support
>> >>> >  > so that the translation material for each language
>> >>> >  > reside in a single repository.
>> >>> >  > Comments would be appreciated.
>> >>> >  > If all is fine, I'll put this, with more details, to live.gnome.org.
>> >>> >
>> >>> > <snip>
>> >>> >
>> >>> >  Thanks Simos for taking the time to evaluate such an infrastructure for
>> >>> >  l10n.
>> >>> >  However I doubt the relative complexity implied by your solution is
>> >>> >  worth the trouble. I see basically two use cases:
>> >>> >
>> >>> >  1. The non-technical coordinator, who would like the simplest
>> >>> >  infrastructure to commit his translation files.
>> >>> >
>> >>> >  -> In this case, an auto-commit feature integrated in damned-lies is the
>> >>> >  best solution. No (D)VCS knowledge is required for him. FYI I've already
>> >>> >  tested a prototype which can do this in the testbed git infrastructure.
>> >>> >
>> >>> >
>> >>> >  2. The geek coordinator who like to have the most control on what he's
>> >>> >  doing and how he do it.
>> >>> >
>> >>> >  -> IMHO, this one won't mind checking out entire git modules. This is
>> >>> >  not very much different than the current situation.
>> >>>
>> >>> FWIW, I fully agree with Claude here.
>> >>
>> >> +1 also :)
>> >
>> > And a +1 from me.
>>
>> OK, let's summarize for future reference and close the thread.
>>
>> One of the issues to try to split translation files from the rest of
>> the modules is because a 'git clone' downloads the full history of a
>> repository, compared to a 'svn checkout' which downloads just a
>> snapshot. In addition, svn can also checkout a subdirectory of a
>> repository, something that git cannot do.
>>
>> Separating the repositories in code and translations using 'git
>> submodule' would add too much effort in terms of updating the tools,
>> and changing the practices that translators would use to maintain the
>> translations. It is easier to keep as is.
>>
>> In terms of disk space, a 'git clone' is surprisingly very economic,
>> almost matching an 'svn checkout'.
>> In terms of speed when cloning a repository, git is more CPU intensive
>> for the GIT server, and is slower than a 'svn checkout'.
>> It would make sense for translators to dedicate some space so that
>> cloned repositories are kept locally (instead of erasing them).
>>
>> Simos
>> _______________________________________________
>> gnome-i18n mailing list
>> gnome-i18n gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-i18n
> --
> gil forcada
>
> [ca] guifi.net - una xarxa lliure que no para de créixer
> [en] guifi.net - a non-stopping free network
> bloc: http://gil.badall.net
>
>