Is it worth investigating starting a fresh repository for 1.6 (yet again), if we implement this?
It would mean we would lose the easy merging and branching you get when you have two versions in the same repo, but new developer approachability would go *way* up if repository size went down. I think it may be a worthwhile tradeoff, but I wonder what other folks think as well. I also wonder what the Mercurial roadmap for trimmed history clones looks like. Perhaps Augie can advise on that? My first pass, strawman take on this is that if we can eliminate *all* binary dependencies, it is worth doing. I don't know how feasible that is. -Colin On Mar 29, 2011, at 10:04 AM, Thijs Alkemade wrote: > Hey all, > > For those that might have missed it, yesterday some commits where done for to > move everything to 10.6 and drop PPC. After that to that, Adrian moved all > XCode targets to clang-llvm. The results of these changes are quite > impressive: the latest nightly built in 4 minutes, compared to just over 8 > for the last nightly before dropping 10.5. > > I, on the other hand, was busy changing all pre-built dependencies to 10.6 > and remove PPC. I messed something up, so I had to commit > Frameworks/libpurple.framework/Versions/0.7.11/libpurple twice. Oops. Sorry > all for that extra 10MB in all your repositories. > > In fact, .hg is around 450MB now. Of which: > > 207M .hg/store/data/_frameworks/libpurple.framework > > Yes, by now almost half the data a new developer downloads is old versions of > libpurple which they will probably never even glance at. > > So, as on the one hand build times have halved, and on the other hand our > repository is exploding in size, I think it really should be considered to > move the libpurple sources into the tree instead of the binary framework > (just libpurple, not GStreamer, GLib, etc, as those aren't updated nearly as > often). > > It will probably take some work to modify the build scripts to work this way, > especially to get it to play nice with XCode. But that is effort that will > have to be done anyway. When (I hope it's "when", not "if") Pidgin moves to > Mercurial, it would be great to include it as a subrepository, which means > building it in the same manner. > > Also, it would be easier to debug problems that go through libpurple code, > easier to spot problems with a build (it wouldn't be the first time a binary > frameworks turns out to be missing one or more architectures...). > > I've used the build scripts quite a lot recently, so I don't mind doing all > the work for this myself. But I wasn't around when the decision was made to > do it this way, so maybe I'm completely missing some problems with it. > > Regards, > Thijs
