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

Re: Fixing "checkout -N"? (possible contracting gig)

From: Steve Johnson <steve_at_Equilibrium.com>
Date: 2005-11-10 19:26:58 CET

On 11/10/05 7:33 AM, "Greg Hudson" <ghudson@MIT.EDU> wrote:
> On Thu, 2005-11-10 at 07:20 -0800, Steve Johnson wrote:
>> Is it possible that there's a third workaround that is sort of the
>> opposite of your second scenario? Could one start with a skeleton tree
>> where all of the leaf nodes are directories that have been "svn
>> switch"ed to empty directories, and then selectively switch them back to
>> interesting directories? This would avoid the initial pain of checking
>> out the whole tree just to throw much of it away.
>
> If you created a reference skeleton tree which people could copy, this
> should work. I'm not sure how you'd efficiently create such a skeleton
> tree from scratch, although I suppose a careful series of non-recursive
> checkout and switch commands would do.

Now we're getting somewhere! I'm envisioning a python script that runs
periodically on the svn server. It would do a complete checkout just once.
Then it would create a bunch of skeleton trees by repeatidly cloning the
entire working tree and then walking through it and pointing various
subdirectories to the empty directory. It could then tarball up each
skeleton and check them into svn where developers could grab whichever one
was appropriate to their current project.

I'm going to play with this. Thanks so much...this "switch to blank dir"
thing might be just the piece of the puzzle I was missing!

BTW, I STILL would be willing to discuss getting the "checkout -N" fixed,
even if I've now got a decent work-around.

Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 10 19:28:43 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.