On Apr 8, 2008, at 5:44 PM, David Carson wrote:
> I added a new directory tree to my repository, but when I do 'svn
> update' in my working copy, it does not retrieve the new directory
> tree.
> - server: 1.3.2
> - client: 1.4.4
>
> Here's a shell session to show what I'm talking about:
>
> > pwd
> /data/bldtools
> > svn info
> Path: .
> URL: svn://buildmaster/trunk
> Repository Root: svn://buildmaster
> Repository UUID: 92351ce5-5732-41c3-b2a0-4e42f99bfd37
> Revision: 33
> Node Kind: directory
> Schedule: normal
> Last Changed Author: dcarson
> Last Changed Rev: 33
> Last Changed Date: 2008-04-04 10:06:25 -0400 (Fri, 04 Apr 2008)
>
> > svn ls svn://buildmaster/trunk/gnu-mips64-elf
> bin/
> lib/
> mips64-elf/
> > ls gnu-mips64-elf
> ls: gnu-mips64-elf: No such file or directory
> > svn update
> At revision 33.
> > svn log -r33
> ------------------------------------------------------------------------
> r33 | dcarson | 2008-04-04 10:06:25 -0400 (Fri, 04 Apr 2008) | 1 line
>
> initial revision -- gnu-mips64-elf
> ------------------------------------------------------------------------
> >
>
>
> The 'svn ls' shows that the directory is in the repository. Why is
> the update not pulling it into my working copy?
>
> Thanks,
> David
Is it possible that this working copy was created using a non-
recursive checkout? If you do the following with svn 1.4 or earlier
you won't get new directories when you do a generic update:
% svn checkout -N <URL> .
In order to do an update and bring in anything that has been added in
that same directory, you have to explicitly update to that directory.
In your case, you would do the following:
% svn update gnu-mips64-elf
If the problem is unrelated to a non-recursive checkout then I'm at a
loss. The only way I know of to fix the non-recursive checkout
problem is to do a fresh checkout without the -N and then you will be
able to do 'svn update' and have it correctly bring in new items.
-Steve
Received on 2008-04-09 14:51:49 CEST