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:stsp_at_elego.de]
> Gesendet: Donnerstag, 20. Januar 2011 16:24
> An: Paul Maier
> Cc: users_at_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
>
Received on 2011-01-21 03:16:48 CET