On Fri, April 28, 2006 9:42 am, Mike McCormack said:
Somebody has finally spent the time needed to:
- Eliminate a dependency (good!)
This is indeed a problem and it would eliminated in both cases. It's just a matter of how we accomplish this.
- Keep binaries out of the GIT/CVS tree (good!)
I'm all for this, don't get me wrong. But it is not an absolute thing, it has to be balanced against the other evil. If we blindingly follow that it is just dogma, and it doesn't seem to be such a worthy cause after all.
As I said, virtually any Java project in existance checks in .jar files, and none of them suffer from any negative ill effect.
The code is still a bit big, but I'm confident that can be addressed.
It's insanely big. And it's not a one time thing, we'll have to maintain that. It's an ongoing cost. With what purpose? We will still have the textual representation in GIT, so changes will be displayed for those so inclined to read them. The binary files will not be included in the diffs. Bottom line is that from an outside perspective the diffs will not change. The only thing that will change is: 1. No dep on fontforge 2. Ability to control _which_ fontforge we use 3. Uniformity in fonts used by users (easier to support, etc) 4. Simplicity
What we loose is just an increased size of the archive. How big will this increase be, BTW? Can someone please how big is a .tar.bz2 of all the binary font files?
If binaries were going into the source tree, then it would have started with the icon/bitmap resource. Anybody remember who spent "tens of precious developer hours" to come up with bin2res so we didn't need to checkin binaries then?
Please, that's a trivial utility. As I said, it's a balancing act. It was very simple to have the bin2res, it looks a lot more complicated to have sfd2ttf. If all we wanted is to avoid binaries in GIT (why?), we can covert .ttf to hex via bin2res :) But I think that would be worse than the problem...