On Fri, 20 Nov 2009, Stefan Sperling wrote:
On Fri, Nov 20, 2009 at 05:36:13AM +0100, Martin Furter wrote:
Since it's easy to merge views (just add all subdirs of the
requested views and for duplicates let the greater depth win) we
could add support for multiple views in one WC.
I don't see a practical use case for merging views.
Why not just define a view that is a superset of multiple other views
and use that?
Our repos layout is trunk/project/subproject and in this case merging
views of multiple subprojects would make sense. On the other hand we can
define views per group of developers and if someone wants a special view
we can add that too. So one view per WC is fine.
What happens if I run update in a subdir? Just ignore views?
Depends on whether we make views "sticky" or not.
I guess they would be sticky anyway since the depth of each directory
is recorded upon checkout time, and can only be changed again with
--set-depth, right?
So if you checked out with --view view1, subsequent updates would only
get directories belonging to view1 (view1 might change over time,
requiring a couple of automated --set-depth commands to update the view).
A special flag such as --clear-view or --view none or --view disable
could cause the WC to be transformed into a "normal" WC (or, rather,
switched to the default view which always includes everything, i.e.
--set-depth=infinity everywhere).
What if the views came from a local file?
We'd have to store the view name and the associated depths
somewhere where we can get at it later.
The associated depths are stored one layer below views using the sparse
directories so we just have to store the view name. We could also store
the filename to be able to reread it (and error if it's invalid).
I'd be happy with either of those approaches.
I'd say let's not get too carried away with this.
Make it work for checkout first. Ignore update, and rely on depth
being sticky. For now, people can change the view later by using
--set-depth. Clearly design it as a fancy way of specifying --depth
upon checkout, nothing more.
Once that works, try to get svn update --view to work.
I think we should sort out the update cases first, or at least think about
some edge cases which will influence checkout.
Actually there's only one major problem remaining with 'sticky' views:
Users can run update --set-depth in their working copy which leads to a WC
which is different than the view which created it. I see multiple ways to
solve that problem:
1) Disallow --set-depth if the WC is a view. Bad.
2) Plain "svn update" undoes the users '--set-depth'. Hmm, also bad?
3) Plain "svn update" does what it did in 1.6 and to update the view users
have to run "svn update --view name". But then we don't have to store the
view name since it has to be specified.
3b) Same as 3 but with a special view 'current', but that word is too
long. Maybe '.' like 'current dir' or vi's repeat command?
4) Is there another solution?
If the view is sticky what happens if I update to a revision (or
switch to a branch) where it is not defined?
I guess an error saying 'remove the view first' should be enough.
I still wonder if 'sticky' is worth all the additional complexity.
But it doesn't interfere with checkout (except storing the view name) so I
can start working on it.
Thanks,
Martin
