You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Paul Maier <sv...@web.de> on 2011/01/20 01:36:27 UTC
set-depth fails after mv
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
svn list -v -r HEAD 2 % file "a" is in the repository ...
ls -lrtA 2 % ... but not in the WC
As a workaround I could check in, then it would work. But I don't want to check in
this partial finished work. So I lose my WC and have to start over, this time
fully checked out from the beginning.
Full console output follows:
svnadmin create xx
svn co 'file:///[...]/xx' yy
Ausgecheckt, Revision 0.
cd yy
svn mkdir 1
A 1
echo a > 1/a
svn add 1/a
A 1\a
svn ci -m ''
Hinzufügen 1
Hinzufügen 1\a
Übertrage Daten .
Revision 1 übertragen.
cd ..
rm -rf yy
svn co --depth immediates 'file:///[...]/xx' yy
A yy\1
Ausgecheckt, Revision 1.
cd yy
svn mv 1 2
A 2
D 1
svn up --set-depth infinity 2
Revision 1.
svn list -v -r HEAD 2
1 User2 20. Jan 01:16 ./
1 User2 2 20. Jan 01:16 a
ls -lrtA 2
insgesamt 0
drwxr-xr-x+ 1 User2 Kein 0 20. Jan 01:16 .svn
Regards,
Paul
AW: set-depth fails after mv
Posted by Paul Maier <sv...@web.de>.
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@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
>
Re: set-depth fails after mv
Posted by Stefan Sperling <st...@elego.de>.
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