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
Received on 2011-01-20 16:24:21 CET