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
