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

Project Layout advice: non version controlled tree's in project

From: Tim Harvey <tim_harvey_at_yahoo.com>
Date: 2005-10-06 18:01:13 CEST


I'm in the process of evaluating Subversion over Perforce (our current SCM) for
an existing project that consists of an embedded linux distribution which
distributes its usersland apps/libs as binaries, but its kernel as source
(resulting in a pretty large disk footprint). Our project makes changes in
several directories of this embedded distro. When using Subversion to control
the entire project layout (the original distro + our various tree's within the
distro) I'm running into a disk-space roadblock due to the fact that Subversion
stores a 'pristine' copy of each file in the project. As an example, the
project directory before svn import is 1.1G, but a working copy is 4.4G. I'm
not clear why there is a 4X increase and not just a 2X increase (can anyone
answer this?) but the real question here is that knowing we will never make
changes in certain directory tree's of the embedded linux distro (ones
responsible for most of the disk usage), what are some recomendations regarding
how we can structure our project layout to avoid version controlling these
specific trees?

If our project touched simply 1 subdir of the embedded linux distro I would
simply source control only that directory, however we touch several trees.
Therefore I'm thinking we can use some sort of 'overlay' method where in order
to get a working copy of the overall project you first need to untar a tarball
of the embedded linux distro, then checkout our project from the repo which was
imported with certain (uncontrolled) tree's of the distro missing. Does an
approach like this sound reasonable? Any advise from someone doing something
similar in nature?



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 6 18:04:01 2005

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.