Hi Stefan, thanks for your answer.
> > svn list -v -r HEAD 2 % file "a" is in the repository ... > Here, svn list traverses copy history, and shows the contents of > directory '1' in the repository. It doesn't show '2'. [...] > You might argue that this is a special case because '2' is a > copy of '1'. > However, just because '2' is a copy of '1' doesn't mean that > update should > start pulling children of '1' into '2'. They are different > directories. This seems somehow inconsistent to me: "svn ls -r HEAD 2" shows the server's content of direcory 1, but when I ask svn to fully load the content into the WC it does nothing. (Even without notice: Svn gives the impression that the operation went fine. No error message. Output is: "Revision 1." So I think that I already had and have all files in my WC.) I agree that 1 and 2 are different directories. But there should be a command line option like "svn up --set depth infinity --force" to pull the data into the WC. The use case is: First I check out only partially, because it's faster to copy, and after working a while I realize, that I do need some file in 2. Currently svn gives me no chance to load the file into the WC. Svn would exactly know what to do: it even can "svn ls" the file, that I want, on the server. BTW "svn ls -r HEAD 2" showing the server's content of direcory 1, without notice, that I get something else than I asked for, is also confusing to me: Let's look at "svn cat": - "cat" shows the situation of the WC. - "svn cat" shows the file on the server. Now, what's the situation with "svn list"? Should be similar. But: - "ls 2" shows the contents of directory named 2 on the WC. - "svn ls -r HEAD 2" does NOT show the situation on the server, where a directory named 2 doesn't exist. I would expect this command to fail, instead I get listed the contents of directory named 1. Without notice. Because I want to see how the server looks like, I made myself a bash-script that uses "svn info", grep and sed to get the URL out of the input parameter (say: "2"), and then "svn list" to go to the server. Works, but slow. It would be nice to have a command line parameter to "svn list" to do this for me, i. e. to really show the situation on the server. Thanks & Regards, Paul > -----Ursprüngliche Nachricht----- > Von: Stefan Sperling [mailto:s...@elego.de] > Gesendet: Donnerstag, 20. Januar 2011 16:24 > An: Paul Maier > Cc: users@subversion.apache.org > Betreff: Re: set-depth fails after mv > > On Thu, Jan 20, 2011 at 01:36:27AM +0100, Paul Maier wrote: > > Hello! > > > > "svn up --set-depth infinity" fails to load a file from the > repository into the WC, > > when the directory previously has only partially been > checked out and has been > > copied and has not been checked in yet. > > > > At the end of this reproduction script I would expect file > "a" to be present in > > directory "2", but it's not. > > > > #!/bin/bash -v > > svnadmin create xx > > svn co 'file:///[...]/xx' yy > > cd yy > > svn mkdir 1 > > echo a > 1/a > > svn add 1/a > > svn ci -m '' > > cd .. > > rm -rf yy > > svn co --depth immediates 'file:///[...]/xx' yy > > cd yy > > svn mv 1 2 > > svn up --set-depth infinity 2 % directory "2" is now > fully checked out; no error message > > This update is a no-op. How can '2' be "fully checked out" if > this path > doesn't exist in the repository yet? > > > svn list -v -r HEAD 2 % file "a" is in the repository ... > > Here, svn list traverses copy history, and shows the contents of > directory '1' in the repository. It doesn't show '2'. > > > ls -lrtA 2 % ... but not in the WC > > > As a workaround I could check in, then it would work. > > Yes, you need to commit the rename first. The copy half of > the rename is in > fact done on the server-side with depth infinity. So the depth of the > working copy has no effect on the copy operation. See > http://subversion.tigris.org/issues/show_bug.cgi?id=3699 > > After committing the rename, update can receive changes for > the path '2', > so --set-depth will have an effect. > > $ svn up --set-depth infinity 2 > A 2/a > > > But I don't want to check in this partial finished work. > > Your notion of using update to change the depth of a path that > doesn't exist on the server is flawed. > An update can only get changes that are already on the server. > > > So I lose my WC and have to start over, this time > > fully checked out from the beginning. > > I'd suggest adjusting the depth as desired before copying or renaming > the directory. Then the working copy will have the desired state. > There is no concept of "depth" for trees that aren't in the > repository yet. > > You might argue that this is a special case because '2' is a > copy of '1'. > However, just because '2' is a copy of '1' doesn't mean that > update should > start pulling children of '1' into '2'. They are different > directories. > > The behaviour is certainly not intuitive. But then again a > lot of things about > shallow working copies are not intuitive. It's a neat feature but it > sometimes mixes badly with other features (such as, in this case, copy > operations within a working copy). Use --depth with caution. > > See also this issue which is slightly related: > http://subversion.tigris.org/issues/show_bug.cgi?id=3569 > > BTW, below is a version of your script with minimal tweaks that allow > it to be run anywhere without modification. In the future, please keep > in mind that reproduction scripts that can be used as-is are > a lot easier > to handle for recipients. That said, thank you for adding an > almost usable > script. It is much better than providing no script at all and makes it > a lot easier to understand the question. I wish more people > would do so! > > Thanks, > Stefan > > #!/bin/sh -x > svnadmin create xx > svn co file://`pwd`/xx yy > cd yy > svn mkdir 1 > echo a > 1/a > svn add 1/a > svn ci -m '' > cd .. > rm -rf yy > svn co --depth immediates file://`pwd`/xx yy > cd yy > svn mv 1 2 > svn up --set-depth infinity 2 # directory "2" is now fully > checked out; no error message > svn list -v -r HEAD 2 # file "a" is in the repository ... > ls -lrtA 2 # ... but not in the WC >