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

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

From: Steve Johnson <steve_at_Equilibrium.com>
Date: 2005-11-10 16:20:28 CET

Hi Greg,

Thanks for your suggestions.

I've tried to think through scenarios like the ones you give here in the
past. The problem for us is that, due to the complexity of our tree,
trimming the source tree at the first level only provides a partial
solution. Given time, we could reorganize our tree to be better suited
to these workarounds, but we unfortunately do not have that time.

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.

BTW, I'm assuming that when you say "svn switch" to an empty directory,
you mean the SAME empty directory over and over. It isn't the case, is
it, that I have to have points in time where each directory to be pruned
existed but was empty?

Thanks again,

Steve

> -----Original Message-----
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Wednesday, November 09, 2005 10:25 PM
> To: Steve Johnson
> Cc: dev@subversion.tigris.org
> Subject: Re: Fixing "checkout -N"? (possible contracting gig)
>
> On Wed, 2005-11-09 at 21:56 -0800, Steve Johnson wrote:
> > This problem is affecting our development in a number of ways. We
do a
> > significant number of automated nightly builds, and the need to
check
> > out our entire source tree over and over again is affecting our
ability
> > to complete those builds in a timely fashion...a problem we never
had
> > with CVS. We're now hesitant to add larger files to our repository
for
> > fear of making initial checkouts take even longer.
>
> Just so you are aware, there are a couple of workarounds:
>
> * Do an initial non-recursive checkout. cd into the resulting
working
> copy and "svn update" the directories you actually wanted. Now, the
> trick: never update the top-level, non-recursively-checked out
> directory. Always update the subdirectories specifically, using "svn
> update *".
>
> * Do an initial complete checkout. cd into the resulting working
copy
> and "svn switch" the directories you don't want to an empty directory.
> This trick is initially less efficient, but let's you run "svn update"
> on the top-level directory without problems.
>
> Switching a subdir to an empty directory also works with the first
> trick, if you no longer want a subdirectory.
>
> > Is my
> > company's practice of fostering code sharing by keeping everything
in a
> > single repository not generally done when using Subversion?
>
> I personally advocate keeping separate projects in separate
> repositories, but that's not precisely the issue. The issue is how
you
> organize your tree. Checking out a complete subdirectory of the
> repository works just fine (or we would ourselves lose horribly; we
> check out only .../trunk when we work on Subversion, so that we don't
> get branches and tags).
>
> You may have perfectly valid reasons for wanting to organize your tree
> the way you do. I'm not trying to defend the lack of proper
> non-recursive checkout support, just to explain why there isn't a
> deafening roar.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 10 16:30:17 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.