[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Storing VS binaries in Subversion

From: Toby Johnson <toby_at_etjohnson.us>
Date: 2007-06-14 17:58:04 CEST

Eric Nicholson wrote:
> On 6/13/07, Toby Thain <toby@smartgames.ca> wrote:
>>
>>
>> Personally I think it's bad practice to store any derived file
>> (especially objects) in a repository. Ymmv; I'd be interested to hear
>> an argument in favour of it, because I can't think of [m]any.
>>
>>
>
> I always prefer that there is no reason to version the derived files,
> but sometimes things are beyond your control because:
> * Some files are not deterministically generated
> * Some files are very expensive (time/effort) to generate
> * Some files are created by a third party
>
> In that case it's very helpful to version the files. Maybe more
> helpful than versioning your source code.

In this case I would recommend setting up a separate repo for the binary
stuff. That way your source code repo remains light, small, and fast,
which you'll definitely appreciate when you need to start performing
operations that reach way back in time such as Blame.

You can also then wipe out your binary repo and start over periodically,
or do a dump/load to get rid of binary files older than x. Even if it is
a handy distribution mechanism for binary files, there's really no need
to keep 2 years' worth of daily binary data lying around.

The only problem with this approach is that most build scripts build the
files in a subdirectory of the source trees. You could solve that by
either making your bin/obj folders external references to the binary
repo, or copying/moving the binary files to a WC of the binary repo
after the build.

toby

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 14 17:58:34 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.