On 19.09.2017 18:05, Branko Čibej wrote: > On 19.09.2017 13:24, Daniel Shahaf wrote: >> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200: >>> On 19.09.2017 00:59, Paul Hammant wrote: >>>> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a >>>> following `svn up` it would *remember the current view*, it would be good. >>> I don't think there's any need to remember the "current view": a sparse >>> working copy already maintains its topology, so the view spec is only >>> needed on checkout to construct the sparse WC (and then update to >>> explicitly change it, etc.) >> What if the view excludes A/D, and then the wc is updated from a >> revision where A/D doesn't exist, to a revision where it does? > I still say we shouldn't remember the view spec; the WC should remember > the topology. Your example might involve the WC remembering exclusions > for nonexistent paths. Yes, that would be a WC format change.
On consideration ... it might not even require a format change, just a constraint change -- I don't know whether that requires a format bump for backwards compatibility. The basic idea is that this would have to work: $ svnadmin create repo $ svn co file://$(pwd)/repo wc Checked out revision 0. $ cd wc $ svn up --set-depth exclude X svn: E155010: The node '.../wc/X' was not found. ^^^ This currently fails, but if it didn't and we recorded the exclusion in the WC and later X appeared in the repository, the client would silently ignore it. As I said, I've not a clue what that means for WC backwards compatibility. But it should be enough to implement 'future exclusion' in views. Of course, whether 'future exclusion' even makes sense as a feature is a different question. -- Brane
