[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: Andreas Schweigstill <andreas_at_schweigstill.de>
Date: Wed, 13 May 2009 17:31:09 +0200

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:

my_project
  -- trunk
  | -- dir1
  | -- dir2
  |
  -- tags
  |
  -- branches
  | -- branch1
  | | -- dir1
  | | -- dir2
  | -- branch2
  |
  -- releases
        -- version1
        | -- sources
        | -- dir1
        | -- dir2
        | -- binaries
        | file1.bin
        | filexy.elf
        | build_sources_and_copy_to_binaries_dir.sh
        | build_sources_and_copy_to_binaries_dir.log
        -- version2
              -- sources
                   -- dir1
                   -- dir2
              -- binaries
                   file1.bin
                   filexy.elf
              build_sources_and_copy_to_binaries_dir.sh
              build_sources_and_copy_to_binaries_dir.log

The "tags" directory structure will only be used to store certain
milestones of a project which are not identical to official product
releases.

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.

Regards
Andreas Schweigstill

-- 
BITTE BEACHTEN SIE UNSERE NEUE TELEFONNUMMER!
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 53035-435, Fax: (+49) 431 53035-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2239351
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-13 17:32:50 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.