I've been following this thread and am very interested in this type of feature
for the same reason Steve is.
I'm experimenting with svn:externals myself and am wondering if this is a valid
solution for this type of problem. In my situation I have a large tree that is
a dependency for several other projects. This tree contains linux distros for
several architectures, but the architecture specific sub-trees are burried many
levels deep (and we don't control the base distro so we can't re-organize it
ourselves). The issue at hand is that this base distro, while taking 2.1G in
the repo takes 74mins to checkout and produces a working directory of 7.5G. If
I prune out the architectures I'm not interested in the checkout takes 23mins
and 2.8G in the working directory - something much more desirable.
In creating the smaller projects that use this base, I've used an svn:external
property to pull the tree's we want from the base. Because svn:externals is an
all-or nothing feature I've written a little perl script that will build the
smallest list possible of externals for a tree given a list of excludes.
I'm not sure if this solution has merit as svn:externals seem to function as
separate working directories (or specifically, working directories inside of
working directories). This may make it more problematic to perform commits as
you would have to specify the full path to the external tree you are
committing. It seems that the 'svn status' command will recurse into externals
in a way, but 'svn commit' does not.
Thoughts?
Tim
Steve Johnson <steve <at> equilibrium.com> writes:
>
> 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'
>
> or something similar.
>
> I want this feature so bad, I'm thinking of implementing it
> myself!!! There must be others out there that would greatly benefit
> by this feature. What do others think? Is there any downside to
> such a feature? Am I forgetting something that would make this
> feature "evil"?
>
> Thanks in advance for any valuable discussion that might ensue.
>
> Steve Johnson
> Equilibrium
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 12 17:24:34 2005