On Sat, 7 Nov 2009 16:08:13 -0500 Timothy Normand Miller <[email protected]> wrote:
> On Sat, Nov 7, 2009 at 3:19 PM, Peter Stuge <[email protected]> wrote: > > Timothy Normand Miller wrote: > >> >> Also, we should not host them in the SVN repo, because the project > >> >> file would be a non-ascii blob. > >> > > >> > I disagree with this. > >> > >> I agree with your reasoning. The problem is that the server the > >> repo is on doesn't belong to us. Since binaries can't be diff'ed, > >> then every time you check in an update, it takes up as much space > >> as the whole binary. > > > > Subversion is smarter than that actually. :) > > > > --8<-- http://subversion.tigris.org/faq.html#binary-files > > Note that whether or not a file is binary does not affect the amount > > of repository space used to store changes to that file, nor does it > > affect the amount of traffic between client and server. For storage > > and transmission purposes, Subversion uses a diffing method that > > works equally well on binary and text files; this is completely > > unrelated to the diffing method used by the 'svn diff' command. > > -->8-- > > > > > >> Moreover, a SVN repo, IMHO, is not an appropriate place to keep > >> releases. > > > > Ah! I agree about releases. But obscurely formatted binary files > > ("project files" above) that make up the "source" for hardware tools > > are good to have in the repo I think. > I'm not expert enough on this. Since Attila is the one who set up the > SVN server, I'll leave further discussion on this up to him. Me, I > just want to do whatever is best. :) And i decree that project files belong into the repo! :-) Don't worry about diskspace, the server has more than enough. And if at some point in time it wont be enough anymore, i get a bigger server. But i can say with quite some confidence that this wont be necessary for quite some time (OGP is the only real user of the server, all other "users" involve only mail relay and dns) As for the releases, i'm not sure whether they do not belong into the repo too. If the tools we'd use to generate them would be OSS and we could get our hands on old versions, then there would be no problem. But knowning that old versions get unavailable soon and that we need to be able to recreate binaries (aka bitstream files) exactly the way we did x-years ago for testing, i'd say it would be a good idea if we could tightly couple the releases with the repo. Either by putting the binaries into the repo or by putting them on the same server. Attila Kinali -- If you want to walk fast, walk alone. If you want to walk far, walk together. -- African proverb _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
