[jira] [Updated] (SVN-695) [sparse-directories] "svn checkout -N" should actually work.

["Ivan Zhakov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SVN-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivan Zhakov updated SVN-695:
----------------------------
    Description: 
Suppose you check out the top-level of the Subversion repository with --nonrecursive, so you just get the
README, INSTALL, HACKING files etc, but none of the subdirs.

Now you have a flat, one-level working copy with just some files.

Currently, if you run {{svn update}} in that working copy, everything goes to pot.  The update state report is incorrect:
the client doesn't tell the server anything about subdirs (because the client has no record of any subdirs, neither on
disk nor in the entries file), so the server assumes that the client has revision X of the entire tree, where X is whatever
the client got when it checked out.

Depending on what has changed in the repository since X, various sorts of errors will happen at this point.  No need to go into it, you can use your imagination.

So what is the desired behavior?

Nonrecursiveness should be sticky.  That is, when you check out something --nonrecursive, the local wc directory created should remember that it is a nonrecursive tree, and tell that to the server in state reports, so the server doesn't try to send updates for anything not that directory level.

How would the working copy record this?  Probably by setting an attribute on the `this-dir' entry, plus recording all the
subdir entries with a similar attribute on them.

So {{svn update}} in this working copy would behave non-recursively by default; but if you pass the --recursive flag, then it
clears those attributes and fetches everything.  That way, the intention expressed in the initial checkout is honored, until
the user says otherwise.

This also implies that the --recursive vs --nonrecursive state variable in the client needs to become a three-state enum: --default, --recursive, and --nonrecursive.


  was:
{noformat:nopanel=true}
Suppose you check out the top-level of the Subversion
repository with --nonrecursive, so you just get the
README, INSTALL, HACKING files etc, but none of the subdirs.

Now you have a flat, one-level working copy with just some
files.

Currently, if you run "svn update" in that working copy,
everything goes to pot.  The update state report is incorrect:
the client doesn't tell the server anything about subdirs
(because the client has no record of any subdirs, neither on
disk nor in the entries file), so the server assumes that the
client has revision X of the entire tree, where X is whatever
the client got when it checked out.

Depending on what has changed in the repository since X, various
sorts of errors will happen at this point.  No need to go into
it, you can use your imagination.

So what is the desired behavior?

Nonrecursiveness should be sticky.  That is, when you check out
something --nonrecursive, the local wc directory created should
remember that it is a nonrecursive tree, and tell that to the
server in state reports, so the server doesn't try to send
updates for anything not that directory level.

How would the working copy record this?  Probably by setting
an attribute on the `this-dir' entry, plus recording all the
subdir entries with a similar attribute on them.

So "svn update" in this working copy would behave non-recursively
by default; but if you pass the --recursive flag, then it
clears those attributes and fetches everything.  That way, the
intention expressed in the initial checkout is honored, until
the user says otherwise.

This also implies that the --recursive vs --nonrecursive state
variable in the client needs to become a three-state enum:
--default, --recursive, and --nonrecursive.
{noformat}


> [sparse-directories] "svn checkout -N" should actually work.
> ------------------------------------------------------------
>
>                 Key: SVN-695
>                 URL: https://issues.apache.org/jira/browse/SVN-695
>             Project: Subversion
>          Issue Type: Bug
>          Components: src
>    Affects Versions: all
>            Reporter: Karl Fogel
>            Assignee: Karl Fogel
>            Priority: Critical
>             Fix For: 1.5.0
>
>
> Suppose you check out the top-level of the Subversion repository with --nonrecursive, so you just get the
> README, INSTALL, HACKING files etc, but none of the subdirs.
> Now you have a flat, one-level working copy with just some files.
> Currently, if you run {{svn update}} in that working copy, everything goes to pot.  The update state report is incorrect:
> the client doesn't tell the server anything about subdirs (because the client has no record of any subdirs, neither on
> disk nor in the entries file), so the server assumes that the client has revision X of the entire tree, where X is whatever
> the client got when it checked out.
> Depending on what has changed in the repository since X, various sorts of errors will happen at this point.  No need to go into it, you can use your imagination.
> So what is the desired behavior?
> Nonrecursiveness should be sticky.  That is, when you check out something --nonrecursive, the local wc directory created should remember that it is a nonrecursive tree, and tell that to the server in state reports, so the server doesn't try to send updates for anything not that directory level.
> How would the working copy record this?  Probably by setting an attribute on the `this-dir' entry, plus recording all the
> subdir entries with a similar attribute on them.
> So {{svn update}} in this working copy would behave non-recursively by default; but if you pass the --recursive flag, then it
> clears those attributes and fetches everything.  That way, the intention expressed in the initial checkout is honored, until
> the user says otherwise.
> This also implies that the --recursive vs --nonrecursive state variable in the client needs to become a three-state enum: --default, --recursive, and --nonrecursive.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)