On Fri, Nov 20, 2009 at 05:36:13AM +0100, Martin Furter wrote: > >So multiple views can be active at the same time within the same WC? > >Would this not complicate things a bit too much? > > No, they are not 'active in a working' copy, they're not registered > there. The view just describes what directories and files to > download, and this translates directly to a bunch of 'svn update > --set-depth' calls.
Yeah, the information about which view name was used upon checkout is transient. Maybe it should be stored somewhere? I had the vision of being able to switch a WC between views, kinda like I can switch a working copy to another branch. I.e. I have checked out view1 originally, and when I update (or switch) using --view view2, everything from view1 which is not in view2 disappears from my working copy, and everything from view2 that is not in view1 appears in my working copy. > But I guess I see what you you meant with 'active'. The root > directory of the WC knows about the view[s] and running plain 'svn > update' will pull in additional subdirs added to the view, right? The "active" view would simply be the last view that was checked out or updated to. > 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? > That approach also leads to a few more questions: > > Does wc-ng still support WC properties to be able to store the view names? I'm sure we could store them somewhere if needed. > 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. > 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. > >Why not just get the project2 view into one WC and the project5 > >view into another WC? > > A reason may be to be able to commit to both projects at the same time. Committing from multiple working copies at once is a planned wc-ng feature. So let's just let wc-ng sort that out and not complicate views because of it. I'd say one view per WC is a good way to start off implementing the feature anyway. Stefan
