Hi Ximon,
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
the works!
Take care,
Steve
> 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
> these...
> >
> > 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
> interest
> > 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
> tree,
> > and <op> defines the comparison. Only when the comparison
> succeeded on
> > a versioned object would that object be checked out. For our
> purposes,
> > this check could be done only on directories. For generality, I
> could
> > 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
> developers
> > 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
> coding
> > practices dictate organizing code by module, not by platform.
> So it
> > really does seem like a natural thing to want/ need to avoid
> irrelevant
> > platform-specific directories sprinkled throughout a source tree.
> >
> > Given the filtering enhancement mentioned above, one could simply
> tag
> > 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.
>
> Suggestions:
>
> 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?
> numeric?)
> 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
> have
> 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
> prevent
> client side expansion of shell variables so maybe this is a moot
> point.
>
> Ximon
>
>
Received on Thu Sep 8 22:50:06 2005