Mark Phippard wrote:
As of 1.6, you can in fact use update to make the depth more shallow.
See:
http://blogs.open.collab.net/svn/2009/03/sparse-directories-now-with-exclusion.html
Ooh, nice, I didn't know 'exclude' yet.
My main comment was to ask if you have seen this?
http://svn.apache.org/viewvc/subversion/trunk/tools/client-side/svn-viewspec.py?view=markup
No, I didn't know that script, it's nice.
The only problem I see with that script is that it is a script. If it were
integrated into subversion all clients can (and probably will) include the
feature.
On Thu, 19 Nov 2009, Stefan Sperling wrote:
On Thu, Nov 19, 2009 at 03:54:58AM +0100, Martin Furter wrote:
Hello
I've written a little design document to specify 'views'.
Attached is also a 'proof-of-concept' python script which should
behave pretty much the same as svn checkout does, except that it
supports views
(it's not very well tested since I'm stuck with svn 1.4 on linux and
had to debug it on WinDoS, but at least "--view srv-side -F views.conf"
should work fine).
Please give me your feedback :)
Thanks
Martin
[[[
Contents
========
0. Goals
1. Design
2. User Interface
3. Examples
4. API Changes
0. Goals
========
Many users have very large trees of which they only want to
checkout certain parts. In Subversion 1.5 sparse directories
have been introduced.
This proposal adds 'views' on top of sparse directories. A view
is a list of subdirs and files with depth information. On checkout
with '--view NAME' is checked out and those paths are updated to
the specified depth.
Nice idea!
1. Design
=========
Views are defined in a simple text file. Empty lines and lines
starting with a '#' are ignored. All other lines must start with
'view' or with one of the accepted depth values, followed by at
least one whitespace and an argument.
'view' starts a new section describing the view, and the argument
is the name of the view. All lines following the view up to the
next view or end of file belong to this view.
Lines starting with a depth value have a path as argument. This
path is to be updated to the given depth. Intermediate directories
which are not specified for the view are updated to depth 'empty'.
It is an error to specify subdirs of a dir which has depth
'infinity. The special path '.' is used to set the depth of the
root directory. The default depth for the root is 'empty'.
Also a new property 'svn:views' is introduced. It is set on trunk
and its content is a relative path to the views configuration file.
Why not put the view specification into the svn:views property
directly, rather than into a separate file?
I thought long about the property or properties.
My first idea was adding a property "svn:view:NAME" containing only one
view.
Then I thought about putting all views into "svn:views". But in the early
days it has been recommended to keep property content small (not sure if
it's still that way). How big can it become? I guess it will be less
than 10kB in most cases. What about property conflicts if multiple users
edit it? I never had a property conflict, and I heard that you're working
on property conflict resolution, so I guess that's also not a problem.
So the only reason remaining is that in both cases it is a file. Either
the file is read from the repos or from a local filesystem. I thought
that makes it easier to implement since it can use the same code.
Else, what happens if the file doesn't exist?
Error :)
Also, "set on trunk" is not generic enough.
Many Subversion repositories do have a "trunk" but it's not required.
So why not allow this property on any folder, and have it take effect
if it is set on the folder which is being checked out, and if the
view specified by the user is defined in the property at HEAD?
Any svn:view properties above or below the folder being checked out
would silently be ignored.
That's exactly what i thought but forgot to write down.
But I'd read the property from the revision requested. Most of the time
this will be HEAD anyway, but if it isn't HEAD some of the paths in the
view at HEAD could be invalid.
To use views with older revisions you could checkout HEAD and update to
the revision you want, or use a local view file.
2. User interface
=================
Checkout accepts the new option '--view' whose argument is the
name of the view to checkout. '--view' and '--depth' are
mutually exclusive since the depth of the root directory is
specified in the view config file.
Additionally checkout accepts '-F' (--file) to specify a local
view config file. It is an error to use '-F' without '--view'.
If the view is specified within the property, users could simply
edit the property locally to test local changes. The -F flag would
not be necessary.
I don't see how that would work, checkout always gets all data from the
repository.
3. Examples
===========
Initializing the views: Create the file "views.conf" containing
three views, "dev", "docs" and "srv-side".
cat > views.conf << EOF
view dev
files .
infinity build
infinity subversion
view docs
empty .
infinity doc
infinity notes
infinity www
view srv-side
empty .
infinity tools/server-side
infinity contrib/server-side
EOF
svn add views.conf
svn ps svn:views views.conf .
svn ci
Checkout of the view "dev":
svn co --view dev http://svn.apache.org/repos/asf/subversion/trunk
Checkout of the view "dev" using a local config file:
svn co -F ./views.conf --view dev \
http://svn.apache.org/repos/asf/subversion/trunk
4. API Changes
==============
Only the following public function is added, the parameters are
mostly the same as for svn_client_checkout3:
Then why not add this new feature in a new version svn_client_checkout4()?
If it's OK to add two more parameters why not...
But I thought I'd take the easy route like I did in the python script:
Do a checkout first, then do all the updates needed (it could ofcourse be
integrated into the protocols but that's a lot more work).
Then svn_client_checkout4 would look something like that:
if( view_name )
do_view_stuff();
else
do_what_svn_client_checkout3_did();
svn_error_t*
svn_client_checkout_view(svn_revnum_t *result_rev,
const char *URL, const char *view_name,
const char *view_file, const char *path,
const svn_opt_revision_t *peg_revision,
const svn_opt_revision_t *revision,
svn_boolean_t ignore_externals,
svn_boolean_t allow_unver_obstructions,
svn_client_ctx_t *ctx, apr_pool_t *pool);
view_name:
Name of the view to checkout, must be non-null and non-empty.
And this parameter would be allowed to be NULL meaning "I'm not
selecting any view, behave like a normal checkout"?
view_file:
Null if the views have to be read from the repository. If
non-null it must be a path to a local views config file.
This parameter could also be dropped.
I think being able to use local view files will help in many cases, f.ex.
if you do not have commit access or for personal views nobody else needs.
Also, AFAIK it's currently not possible to update to a more
shallow depth, but that's a problem with the depth feature rather than
with views. But we need to specify how "svn update" should behave when
svn:view properties (or config files) are modified, and how this interacts
with the --set-depth option.
First I thought update is too complicated and should not be supported.
But now I think 'svn update --view X' should just pull in what's missing,
but never remove things. That way I could 'checkout --view project2' and
then 'update --view project5' and get everything I need to work on those
two projects.
Or maybe checkout should work that way if the working copy already exists
and repos UUID and URL match?
Thanks, it's a lovely idea and builds nicely on top of an existing
feature to enhance usability.
Stefan
Thanks,
Martin
