[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Sparse checkouts suggestion

From: Branko Čibej <brane_at_apache.org>
Date: Wed, 20 Sep 2017 08:59:37 +0200

On 20.09.2017 08:48, Branko Čibej wrote:
> 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.

For a moment I thought that our sparse working copy does have one
missing feature; consider a view defined like this:

    exclude: /*
    include: /foo

It turns out that we can model this with our current feature set: a
checkout would essentially do this:

    svn checkout --depth empty $REPO $WC
    svn update --set-depth infinity $WC/foo

However we could't use that for:

    exclude: /foo
    include: /*

if /foo does not exist at checkout time -- and if we'd want /* to mean
"include anything new that appears in the repository", not "include
everything else that's in the repository at the time of the checkout".

-- Brane
Received on 2017-09-20 08:59:46 CEST

This is an archived mail posted to the Subversion Dev mailing list.