SVN::S4

We have a need to enhance the s4 view to support regexps at multiple levels of directory hierarchy.

Given a project laid out like this:

^/project/trunk/foo/foo.txt
^/project/trunk/bar/bar.txt
^/project/trunk/baz/baz.txt

For example:

view  ^/project/trunk/(.*)/(.*).txt   txt/$1/$2.txt

You would end up with:

txt/foo/foo.txt
txt/bar/bar.txt
txt/baz/baz.txt

This requires doing a server-side glob, which is a little painful. You may want to only evaluate the regexp when a viewspec change is detected, instead of server-side globbing on every update. For example, the viewspec may not have changed, but the repository may have changed and new file matches may need to be pulked into the working copy. I'm going to file a issue ticket for a new feature that might alleviate the issue.

Here is an email thread relating to the discussion:

It really needs to be one query, as each query takes about 1 
second.  You're probably right that our repository is small 
enough to make this work.  I'll fix it; I'll require the /'s 
though to indicate depth.

-Wilson
-----Original Message-----
From: Dobbie, Brad 
Sent: Wednesday, February 16, 2011 9:28 AM
To: Snyder, Wilson
Subject: RE: dvtools view

I'd rather not limit the feature in that way (if we move the files around 
now, nothing prevents us from getting in the same situation again).

$ /usr/bin/time -p svn ls ^/o68/trunk --depth=infinity > /dev/null
real 1.04
user 0.06
sys 0.01

The above relatively fast, plus you can trim the search path in some cases:

$ /usr/bin/time -p svn ls ^/o68/trunk/rtl --depth=infinity > /dev/null
real 0.82
user 0.02
sys 0.01

If you can't do that for some reason, you could process the regexp 
in stages, leaving the "/" as hard boundaries like glob does (you 
already limit the number of matching expressions to two).

@stage1 = match( '.*', `svn ls ^/o68/trunk/rtl/`);
foreach $dir ( @stage1 ) {
  push @stage2, match( '.*csr', `svn ls ^/o68/trunk/rtl/$dir`);
}

I wonder if doing a single svn ls is faster than a bunch of small 
ones (first method vs. second method). Probably depends on the 
repository layout.

We can discuss in person once Joe gets in (if you want to continue 
down this path).  I'm afraid if we can't get this wildcard case to 
works, then it's probably not worth porting switchrtl to a viewspec.

Brad

-----Original Message-----
From: Wilson Snyder
Sent: Wednesday, February 16, 2011 9:04 AM
To: Dobbie, Brad
Subject: Re: dvtools view

>Now I'm trying to build a "switchrtl" view:
>/nfs/users/bdobbie/dv12/test_o68_1.0
>
>For example (simplified):
>
>view    ^/o68/trunk                                     o68_1.0
>view    ^/o68/tags/O68_1_0/rtl                          o68_1.0/rtl
>view    ^/o68/trunk/rtl/utils                           o68_1.0/rtl/utils
>
>Now I need to do some wildcarding, but I'm having trouble figuring out
>the syntax:
>
># switch csr files back to trunk
>view    ^/o68/trunk/rtl/(.*)/(.*csr)                    o68_1.0/rtl/$1/$2

You can't wildcard more than one directory component, as I
"ls" only one subversion directory; otherwise I would have
to do a recursive list of the whole repository.

IE this is legal

view    ^/o68/trunk/rtl/(.*)_zz(.*)

but not

view    ^/o68/trunk/rtl/(.*)/zz(.*)

We'll need to expand the files list rather than wildcard.
(Or better, move files so that it's more consistent.)

-Wilson