Releases do not belong in your source repository. In your "standard" CM/build/release environment, development builds are done on some frequency. Depending on your release process, either one of those development builds will be deemed "releasable", or the decision will be made to make a separate release build. The source that will go into the build will be denoted in some fashion and the release build done off that source. The release binaries will be denoted in the same fashion and placed in a release "repository". The release binary is traceable back to the appropriate source by its version/build number/some identifier that is part of the binary itself. This identifier aligns with the identifier used to select the source used to generate the binary.
In this way, a binary release is always reproducible, just by knowing its release identifier. The tooling used to generate the binary is always an issue as it is required to be "archived" along with the release if you need exact and absolute reproducibility. If not, then the above is enough for most situations. "Normal" CM tools generally use labels for identification in situations like this. Subversion of course doesn't support labels. They closest it comes is making a new tag. Not exactly the same thing, but perhaps sufficient. Patrick M ________________________________ From: Attila Kinali <[email protected]> To: Timothy Normand Miller <[email protected]> Cc: [email protected] Sent: Mon, November 9, 2009 7:20:13 AM Subject: Re: [Open-graphics] Re: Request for help build an XP10 FPGA image 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)
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
