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

Re: Checkout filtering wanted

From: Steve Johnson <steve_at_Equilibrium.com>
Date: 2005-09-09 23:45:30 CEST

Hi Ben,

I'm very glad to hear that the non-recursive fix will be coming
soon. Thanks for that.

Symbolic links would indeed also solve my problem. In fact, for
reconfiguring trees for particular products, it might even be the
ideal solution. New products are born at a distinct point in time,
and it's usually known up front what parts of existing code they will
utilize. So having to build a link tree for a new product seems
reasonable.

I believe, however, that for my need to configure a tree for a
particular platform, links would be a cumbersome and error-prone
solution. Any engineer might decide to add a platform-specific
directory at any point in the tree at any time. Whenever this
occurs, the maintainer of the link trees for each platform would have
to go in and refactor all of the trees at the point where the
platform-specific directory was added to cause the new directory to
only be picked up on the relevant platform. We currently support 6
platforms. This would mean a change to 6 link trees at a minimum.
And what if we also want to have different link trees for different
products. Now we have 6 * <# of products> trees to maintain. This
idea could quickly become intractable.

The filter expression idea seems simple and elegant to me. I'm
curious why you think the feature could get "very complex". Is it
the general expression nature that bothers you? Or, is the node
filtering itself more complex than my naive view envisions? It seems
to me that making a per-directory binary choice during traversal
would be fairly trivial. And again, I think that svn's general
property mechanism is screaming out to be used this way. It's really
a database, after all...and selection is one of the primary
operations done on a database.

Take care,

Steve
> On Thu, Sep 08, 2005 at 06:12:39PM -0700, Steve Johnson wrote:
> > Ben Collins-Sussman suggested I contact you. I'm (we're) very
> > interested in the ability to do partial checkouts using "svn". Ben
> > says that you're working on fixing "svn checkout -nonrecursive", and
> > if I understood him right, also working on some feature that would
> > allow filtered checkouts by directory/file name.
> >
> > As I'm sure you're aware, a properly functioning -nonrecursive is
> > necessary to write external scripts that do partial checkouts.
> > Having this fix might be all I need. Can you tell me how this work
> > is coming along and when a fix might be available?
> >
> > I recently proposed a filtered checkout mechanism that would utilize
> > expressions on svn properties. My post is what led Ben to point me
> > to you. It would be exactly what I need, and I would expect be
> > applicable to a wide range of similar problems. If you haven't yet
> > read the thread that I initiated, I encourage you to do so. The
> > initial post is here:
> >
> > http://subversion.tigris.org/servlets/ReadMsg?
> list=users&msgNo=38123
> >
> > I welcome your thoughts on my proposal. I would also be interested
> > in hearing about any work you are doing or contemplating regarding
> > filtered checkouts.
>
> The fixes to non-recursive checkouts should be done by the end of
> September. They will be necessary to support what you're talking
> about.
> However, I think in the long term something like symbolic links in the
> repo would be better. I can see the filter feature you describe
> getting
> very complex, whereas allowing links in repo would let people make
> their
> own "view" type setups in directory trees. Would be very simple to
> manage and use.
>
> --
> Ben Reser <ben@reser.org>
> http://ben.reser.org
>
> "Conscience is the inner voice which warns us somebody may be
> looking."
> - H.L. Mencken
>
Received on Fri Sep 9 23:47:21 2005

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.