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

Feature idea: tree collapsing

From: David A. Ferguson <dferguso_at_broadcom.com>
Date: 2004-01-08 18:46:41 CET

This is a long email, so bear with me.



I am looking to move my group from cvs to subversion. The transition should
be relatively smooth, except for one problem:


Our projects are managed using a central repository with about five sites
around the world contributing to the repository. There are about 20 or so
people per site working on the project. The complication here is that a
freshly checked out work tree can become extremely large by the end of the
project-on the order of 50 GB.


All of this data needs to be versioned, and everyone needs a FULL work tree
for various build and simulation tools to find all their files. As you can
see, there is a huge local storage requirement for the five remote sites if
all 20 people have 50 GB checked out. There is also quite a large bandwidth
requirement for initial checkouts and for updates/status (subversion does
address some of this with a better status command).



Our current solution using CVS:


At each site, we take a snapshot every night of a completely up-to-date work
tree. This snapshot is marked read-only. Then, users that don't do active
work on a certain tree create a soft link in their work directory to this
snapshot work tree. The greatest advantage is that it saves us enormous
amounts of disk space ($$$). The individual developer can continue to make
changes and commit files in directories that he has expanded. At the same
time, scripts, tools, and simulations that expect the collapsed directories
to exist still work since they find the snapshot work tree.


The management of this system is performed by an additional script, called
tc. tc handles collapsing and expanding trees. It performs the linking
needed to collapse a tree and the 'cvs update' necessary to expand a tree.



My question (FINALLY!) is:


What do you guys think of this same methodology working with Subversion?

Are there tools out there that already exist for this task?

And the big one: how would this work if this support was added to
Subversion for a cohesive, clean implementation?


I'd like to contribute coding to this task, but I would like your
recommendations and thoughts on the issue.



David Ferguson

Received on Thu Jan 8 20:36:20 2004

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.