Re: Splitting the repos...
Patrick Cloke <[email protected]>
| Newsgroups | gmane.comp.gnome.gaim.devel |
|---|---|
| Message-ID | <[email protected]> |
On 4/7/16 12:45 PM, James Geboski wrote: > Some *trivial* benefits: > > - Many other clients depend on libpurple, where distributions may not > separate libpurple from pidgin (or even finch). As a result, more > dependencies are imposed on the usage of libpurple. Having things > split out will provide more clearly defined boundaries for > distribution packaging. This is something that has been seen on the > BitlBee front with the majority of the users being minimalists. This would be nice. :) > - Smaller repositories. Cloning the Pidgin mercurial repository takes > forever. Having things split out would make it faster for developers > (and I guess users to an extent) to clone what they actually need. I > ran into this issue with the purple-facebook project, which clones the > mercurial sources, and applies a patch set to the sources. Is repository size really a problem? I frequently clone mozilla-central, which is WAY bigger than pidgin/main. (mozilla-central has roughly 300k commits and is 2.4 GB on disk BEFORE unpacking files, etc.) (For comparison, Pidgin has ~40k commits and is only 212M unpacked.) I think you likely want to update your version of Mercurial > 3.5 (and hope that BitBucket has a newer version) [1]. I've found with this it's usually fast enough. :) Mercurial will also soon have shallow clones to not check out the full history (I can't find a source for when this will be added... Facebook has an extension for this already and I believe it's being uplifted to core). If you want to separate them for performance of things like hg status, I'd suggest you install the hgwatchman extension. I've never found status on Pidgin's repo to be slow, however. > - It might also be easier to track and manage changes to the > respective code bases. Especially with keeping things organized with > the pull request model. See my other email, but I suspect this will become MORE difficult in actuality, as you'll have changes scattered across a bunch of different repos. --Patrick [1] http://gregoryszorc.com/blog/2015/07/31/mercurial-3.5-released/ _______________________________________________ Devel mailing list [email protected] https://pidgin.im/cgi-bin/mailman/listinfo/devel