[Kde-pim] Git migration status

[Ingo Klöcker]

On Sunday 18 April 2010, Thomas McGuire wrote:
> Hi,
> 
> On Friday 16 April 2010 21:30:26 Torgny Nyblom wrote:
> > an update on how the rules for the git migration are doing.
> > 
> > KDEPIM:
> > * 1.13 GiB transfer
> > * 1.3 GiB on disk
> > * No diff (against the trunk of my cloned svn repo)
> > * No extra files/dirs
> > * No missing files/dirs (except empty dirs as git cannot handle
> > that) * Number of WARNINGS: 1422 (according to Thomas script)
> > * Number unique WARNINGS: 190 (according to Thomas script)
> 
> 1.13 GiB is big, it means I nearly need 100 minutes to clone that.
> For me personally, that would be borderline ok, but this might not
> be very newbie friendly. What do other developers think about this
> size?
> 
> If it turns out the repo is considered too big, we should reduce it.
> The following comes to my mind, and it should then be measured how
> much size these methods save.
> - Splitting off the e35 and e4 branches into their own repo
> - Looking if there are/were single big files that cause a big
> increase in size
> - Cutting off the history at some defined date

You forgot the obvious:
- Splitting the repo into multiple per-application repos.

As for "Cutting off the history at some defined date", I'm against this. 
git-clone supports shallow cloning. So, there's no reason to cripple the 
master repository just because for some people cloning the full 
repository is problematic. Those people will have to live with a few 
limitations:
  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.

Not being able to push is of course a serious limitation, but I think 
this limitation could be circumvented more or less easily by providing 
an email service which automatically pushes patches that are sent to 
this address. Of course, there needs to be some kind of authentication 
scheme (e.g. the patches resp. the messages could be OpenPGP/MIME 
signed).

And, as last resort, there's still the possibility to burn the full 
clone on a DVD and ship it.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100418/f46e5150/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/