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
Received on 2017-09-20 08:48:10 CEST