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

Repository layout question

From: Joerg Henrichs <joerg_at_luding.org>
Date: 2007-05-23 16:02:00 CEST

Hash: SHA1

Hi all.

I am one of the administrators of a public domain project using SVN and
we currently need some advice on how to extend our SVN repository structure.

We recently decided to add a separate media package. The idea is to have
one package containing the original art work (e.g. original 3d models,
uncompressed textures, ...), while we would use 'derivates' of those
files in the actual project (e.g. 3d models exported in a certain format
we can use, textures might be compressed, ...). A script would be used
to convert the media files into the files needed for the project.

We expect the media package to be significantly larger than the actual
source code (plus used data) package (about 20-30 MB for the current
source code+data repository, which includes everything to run; while the
media package will be 100+MB for the original art work). Only people
wanting to contribute art work (e.g. new 3d models) would actually need
the media package (and only if they want to have some examples, or use
some existing models, textures, ...).

Now, we are not entirely sure about the best layout of the repositories
in such a case, and would appreciate some advice from more experienced
people. Currently, out repository is at certain URL (say svn://url/xyz),
so there are quite a few people having svn://url/xyz/trunk checked out,
and we have the three standard subdirs: trunk, branches, tags. The root
of our repository (svn://url/xyz) is fixed, and we can't change this (we
are using a sourceforge-like environment).

We came up with the following options for the location of the media
directories (say xyz-media), and the advantages/disadvantages:

1) Add svn://url/xyz-media
   This basically means starting a new project on this sourceforge-like
   server. Advantage: clear separation of the two projects.
   Disadvantage: huge administrative overhead, no indication (except the
   name) that xyz-media belongs to xyz and is otherwise useless.
   I think no ones realistically considers this option, I just wanted to
   mention it :)

2) Move svn://url/xyz to svn://url/xyz/trunk/xyz,
   and add svn://url/xyz/trunk/xyz-media
   (same for branches, tags)
   Advantage: clear separation of the projects.
   Disadvantage: all checked out repositories need to be
   updated; people who follow the instructions on the sourceforge-
   like server (which we can't change and which say to use
   svn://url/project-name) would get the source code
   and the original media package, which they don't really need
   (which would be a considerable overhead).

3) Add the media directory to the current repository, i.e.
   create svn://url/xyz/trunk/media
   Advantage: no one would miss the media package (who might otherwise
   start modifying the exported files only), existing working copies
   work as expected. Disadvantage: many (non-artist) developers would
   be forced to download (and update) additional files in which they
   are not interested, similarly artists might not be interested in the
   source code (i.e. no separation between the projects).

4) Add svn://url/xyz/media/{trunk,tags,branches}
   Basically adding a new repository-structure (though not a completely
   new and independent repository).
   Advantages: Some separation of the projects, existing working copies
   work as expected, no checkout of unnecessary files. Disadvantage:
   somewhat ugly directory setup (with xyz-media being next to the
   trunk,branch,tag subdirs of the xyz repository), branches of media
   are unlikely to be used.

5) Add svn://url/xyz/media/ for the media files (no trunk!), but store
   tags (and branches if they should occur) in svn://url/xyz/tags/media
   Advantages: existing working copies work as expected, no checkout of
   unnecessary files. Disadvantages: uncommon directory setup, mixing of
   source and media directories in the branches/tags subdirectories.

Or perhaps there are other (and better??) options we haven't considered?
Or disadvantages we might not be aware of? Any comments or
recommendations would be highly appreciated, since we want to avoid
making a decision now, which might show some problems later, causing a
redesign and therefore an interruption to everybody's work/checked out

Thanks a lot for your time!

- --
- ----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: joerg@luding.org
URL: http://luding.org

Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 23 16:01:03 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.