RE: Checkout filtering wanted

Greetings to Richard, all!

With all due respect to the god-like Mr. Pilato...such reorganization is
often not tractable. Our tree lived for many years as a CVS tree (where
partial checkouts worked), so by the time we hit the "checkout -N"
problem, we were looking at too big a job of reorganization to undertake
it. Also, the organization that C. Michael suggests is, IMO, an awkward
way to organize source. I want the entire source for a module to be in
one place in my tree. I DO realize that this workaround has merit, and
will work for many shops.

The hard part about coding the filtering feature will not be the feature
itself. Rather, such a mechanism will have to rely on the basic notion
of partial checkouts. That is, the svn client must be able to keep
track of a "trimmed" working copy, and not fill the whole thing back in
when a top-level "up" is performed. The lack of the ability to do this
despite the presence of the -N flag to co/up is a known problem. For
more info on this, see issue #695.

If the "checkout -N" problem were solved today, I would likely go in and
implement the filtering feature myself. It's exactly what my
organization needs. When I proposed it, I thought it to be a natural
use for the metadata features in svn. Responses to my suggestion were,
however, lukewarm.

Our current solution to this problem is minimal. Our programmers DO
check out the entire tree, grumbling the whole time they're doing so.

One place we did make a change was in our nightly build system. We
build all of our products automatidly every night. Having to pull
multiple copies of the entire source tree every night turned out to be
overly burdensome. So we modified the build system to only grab the
portions of the tree needed for a particular product. In some cases,
this means using "checkout -N" to grab files where you don't want all of
the directories next to them. This works ok for the purpose of test
builds because we never need to refresh or do commits on these working
copies. This process doesn't work for a normal development tree,
because neither "up" or "ci" work as you expect.

Hope this information helps. Keep your fingers crossed for someone to
solve issue #695!
 
Steve

PS: I'm starting a donation pool for people who want to pay someone to
fix issue #695. I'll pay $1000. If you want to add to that, send me an
email.

-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: Friday, May 12, 2006 5:52 AM
To: Taylor, Richard
Cc: 'dev@subversion.tigris.org'; Steve Johnson
Subject: Re: Checkout filtering wanted

Taylor, Richard wrote:
> Hi,
>
> I was searching for information about checkout filtering can found
this
> posting.
> http://svn.haxx.se/users/archive-2005-09/0384.shtml
>
> The proposal to have filtering based on properties is exactly what we
need.
> checkout --filter 'platform=WinPc'
>
> We use SVN to store binary data accross a number of platforms. Atm
everybody
> has to check out all the data which is many 10's of gigabytes. The
ability
> to checkout just the generic data + target platform data would make a
big
> different to update and commit speeds which atm are really quite poor.

You can accomplish this through careful arrangement of your data tree.
Let's say you have a tree of stuff called 'common', and then your
"platform-specific" stuff ('win32', 'macosx', 'linux'). You can arrange
your tree like so:

   /trunk
      /src
         /common # has the common bits
         /win32 # empty directory
         /linux # empty directory
         /macosx # empty directory
      /platforms
         /win32 # has the win32 bits
         /linux # has the linux bits
         /macosx # has the macosx bits

Now, your checkout instructions for folks on plaform FOO are:

   svn checkout http://.../trunk/src my-working-copy
   svn switch my-working-copy/FOO http://.../trunk/platforms/FOO

The result is a working copy that has the common stuff, the
platform-specific stuff, plus empty directories for all the platforms
that
this user doesn't care about.

(We do this at CollabNet, not for platform-specific needs, but based on
whether or not a user wants to build one of our 130+ components from
source
or just grab the latest "prebuilt" package for that component.)

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