On Thu, Nov 19, 2009 at 05:35:42PM +0100, Martin Furter wrote: > 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.
svn:externals also contain multi-line values. > >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. Yes, of course. > >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. Yeah I forgot that there is no working copy when you start the checkout :) > 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). I guess people would expect svn not to pull down anything from the server that isn't in the view. If we could get that to work somehow I think we should try. > 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. That's a good point. What about allowing both? svn:view could contain view specifications, and svn could also be told to use view specifications from a file instead of (or in addition to) what's in the svn:view property. > >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. So multiple views can be active at the same time within the same WC? Would this not complicate things a bit too much? Why not just get the project2 view into one WC and the project5 view into another WC? Stefan
