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

FWIW, at CollabNet, we use exactly this third workaround.

"Steve Johnson" <steve@Equilibrium.com> writes:

> 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
>

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org