Thanks for the feedback. The issues you raise are right on. Many of
them were going through my head as I wrote my email. I figured I was
just laying the basic idea out there, and that the details could come
later. In fact, I wonder if others more familiar with svn might be
better suited than I to spec the exact feature. I mainly just know
what behavior I need from the system.
I'm anxious to learn more about the feature Ben sited in his
response. Maybe something that will solve this problem is already in
> Steve Johnson wrote:
> > Greetings,
> > We've been playing with Subversion for a few months, and have just
> > taken the plunge and converted over from CVS. Svn is generally
> a huge
> > improvement over CVS. We do, however, have a few key features that
> > we'd like to see implemented. I'd like to discuss the first of
> > I've perused the mailing list and have read discussion threads
> > regarding a number of requests/needs for checkout filtering.
> From what
> > I've seen, however, none of these discussions led to any real
> > in actually implementing a filtering mechanism. I'm wondering
> why this
> > is, and I'm hoping to be able to change this.
> > Subversion's arbitrary properties would seem to me to lead
> naturally to
> > a filtering mechanism. What I want to see implemented is:
> > checkout --filter '<name><op><value>'
> > where <name> is a subversion property name, <value> is a value to
> > compare with the value of the <name> property at each node of a
> > and <op> defines the comparison. Only when the comparison
> succeeded on
> > a versioned object would that object be checked out. For our
> > this check could be done only on directories. For generality, I
> > see extending it to files as well. The 'update' action would
> have to
> > take this argument as well.
> > For example (and to illustrate one of my company's needs),
> others have
> > asked for a way to do a checkout that avoids directories of code
> > specific to a platform other than the one currently targeted. We
> > currently support 6 platforms, and might add others. Having
> > pull down all the code and prebuilt libraries for all 6
> platforms is
> > wasteful of both time and disk space. Some have mentioned the
> > work-around of separating all such code into totally separate major
> > subtrees. Don't most of you agree that this is absurd? Good
> > practices dictate organizing code by module, not by platform.
> So it
> > really does seem like a natural thing to want/ need to avoid
> > platform-specific directories sprinkled throughout a source tree.
> > Given the filtering enhancement mentioned above, one could simply
> > their platform specific directories with say a "platform"
> property, and
> > then do:
> > checkout --filter 'platform=Mac'
> > to get a source tree applicable for building the mac version of a
> > product. For this to be really useful in this situation, the
> > nonexistence of the referenced property should be treated as a
> match so
> > that untagged directories are always grabbed. I guess it would
> be nice
> > to have the filter op able to work either way.
> > I would also use this feature for optimizing particular product
> > builds. Areas of the tree needed only to build specific
> products could
> > similarly be tagged appropriately. So, for example, to grab a tree
> > with only the files sufficient to build DeBabelizer (that's our
> > product) on Macintosh, you'd do:
> > checkout --filter 'platform=Mac, product=Debab'
> I like the suggestion at first glance. You'd need to specify how
> this works in
> a little more detail though.
> 1. To match when the property does not exist use a command line
> option, e.g.
> --filter-match-missing-prop=yes|[no]. Default to no.
> 2. Do not use a comma between match specifications as it is not
> clear if the
> match specifications should be and'd or or'd. I'd expand the
> definition of the
> syntax to something like:-
> name := any valid property name, in quotes ("" or '') if
> includes spaces
> op := one of ==, !=, <, > (how do comparisons work? string?
> value := a string value, in quotes if necessary
> combine:= one of &&, ||
> match := <name><op><value>
> filter := <match>(<combine><match>)*
> 3. No magic on commit, newly added files/directories must manually
> properties set on them. This means it is possible to checkout using
> a filter
> and then commit files/dirs that don't match the filter. Does this
> matter? If
> so perhaps add a --enforce-filter-match option to commit?
> 4. The filter value should allow shell expansion on the client
> before being
> interpreted thereby allowing something like --filter 'arch=
> $HOSTTYPE' (on my
> system $HOSTTYPE is i386). I don't know if it's even possible to
> client side expansion of shell variables so maybe this is a moot
Received on Thu Sep 8 22:50:06 2005