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

Re: How to avoid cluttering the svn repository with several versions of compiled files

From: Andy Levy <andy.levy_at_gmail.com>
Date: Wed, 13 May 2009 11:39:07 -0400

On Wed, May 13, 2009 at 11:31, Andreas Schweigstill
<andreas_at_schweigstill.de> wrote:
> Hello!
>
> Andy Levy schrieb:
>> If you can produce your compiled item from resources in the repository
>> (sources, stylesheets, makefiles, etc.), then there's no real need to
>> store the compiled items themselves - you can reproduce them anytime
>> you want in the future. Most people *don't* keep compiled binaries in
>> their repositories.
>
> Hmm, a reproduction of old generated files is only possible if the build
> environment hasn't changed and if there are no other influences to the
> build process, e.g. timestamps or random generator data.
>
> When I do an offical software release I distinguish between "trunk",
> "tags", "branches" and "releases", so the repository has the following
> structure:

> Since the copied content of "trunk" is located in the "sources"
> subdirectory of "releases/version1" and not in the root it is possible
> to create multiple other directories, e.g. to store the generated
> binary files. Especially if the build process contains build steps which
> have to be asynchronously or seperated from the main build the
> "binaries" directory will also be used as a transfer directory for those
> special build steps.
>
> And also some kind of release documents which are created outside the
> software build process can be stored in their own directories below
> "releases/version1", e.g. release notes which have been created by an
> external certification authority.
>
> So there are lots of reasons to store generated documents in a
> Subversion repository. But it would be really bad practice to mix source
> files with generated files, e.g. put object files in the same
> directories as source files.

For this sort of setup, I wouldn't even put the compiled items into
the repository. I would create a separate "release archive" which is
built from a tag when a release is prepared. Aside from space
efficiencies (which may not even be realized, due these being binary
files), there's not much to be gained by putting releases into
Subversion instead of a decently-structured archive directory on a
server.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2239396

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-13 17:41:54 CEST

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.