[Kde-scm-interest] kdelibs official branches import finished

[Johannes Sixt]

Thiago Macieira schrieb:
> Johannes Sixt wrote:
>> Local disk usage does not worry me. It's the network traffic of a clone
>> that we should keep low. Keep in mind that you are exchanging this repo
>> basically in a LAN.
>>
>> We should not expect that every casual KDE contributor has to download
>> 250M for kdelibs, 250M for kdebase, and several dozens of megs for each
>> other module - just to fix a buglet.
>>
>> But, oh well, there is the shallow clone feature, which could reduce the
>> traffic to a minimum. Except that shallow clones are crippled: You can't
>> fetch from nor push into them. So, if you want a full-featured clone,
>> you have to have a full clone. In which case many people really will
>> have a second thought before they download 500+M. It scares away
>> people.
> 
> Hmm... I see your point.
> 
> If we cut the history at the kde4 branch start, kdelibs's pack drops from 
> 239 MB to 148 MB (both include the index). That's for a 65 MB checkout. 
> The equivalent SVN traffic would be more or less that for the intial 
> checkout.

IMHO, 148M is still too much, but OTOH having all of kde4 history may be
worthwhile during a bugfix sessions. Whereas everything before that,
including kde3.* is really just for archeologists.

> To help the initial checkout, we provide well-compressed tarballs for 
> the .svn directories. That adds the ability to restart the download 
> later. I don't see why we couldn't do that for Git -- except that the 
> tarballs would be much, much larger.

If we could improve git so that the http transport understands
continuation then the tarballs (of full repositories) don't add value
because they cannot be smaller than what the http transport downloads.

Tarballs to seed a --depth=1 shallow repository make still sense, of course.

> For comparison: the --depth=1 clone of that KDE/kdelibs repository is 
> 12.50 MB for "master" only but 85.96 MB for all branches. That one hogged 
> the CPU for 30% and consumed 17% of its RAM (that was a 1 GB machine).

Uh, that's tough. I assume this was on the client side. If this is on the
server side, this workflow won't fly.

> So we want definitely to have a repository per major branch. I'm not sure 
> about slashing history.

Do you mean independent histories by "repository per major branch"?

-- Hannes