You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John McGrath <jo...@xilinx.com> on 2008/09/05 11:11:02 UTC
svn list no working for some working directories
Hi All,
My understanding is that 'svn list' will show the contents of the
repository for the same path as the current directory in the workspace.
For example, if my workspace has
dir1/
dir2/
file1
but the repository has a new directory recently added, called dir3,
svn ls would report
dir1/
dir2/
dir3/
file1
i.e. it shows me the contents of the repository.
However, if the local workspace was originally checked out with the -N
(non-recursive) command,
running svn ls would only show me the directories I have, it would not
show me dir3!
This appears to be a bug - becuase if not, what advantage is svn ls over
plain ls, in this case?
I have tested this will the latest svn 1.5.2, and it still operates in
this way.
The same thing goes for svn update, if the local working direcotory was
originally checked out with -N, running svn update will only get the
contents of directories that are in the workspace.
It would be great if there was a switch to force recursion, like -R or
something, or even -R n, where n would be a number of levels.
At the very least, I think this is a bug in the terms of svn ls,
changing svn update to work as described is a bonus!
Cheers,
John (not subscribed)
--
***********************************************************************
/ /\/ John McGrath
\ \ Senior IC Design Engineer
/ / Xilinx Ireland
\_\/\ Units 9 A&B, Eastgate Ave.
East Gate, Little Island,
Cork, Ireland.
Internal Ext: 2614
Tel: +353 21 435 5704
FAX: +353 21 435 3342
***********************************************************************
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn list no working for some working directories
Posted by Karl Fogel <kf...@red-bean.com>.
Sorry, the below was meant to be in response to another thread, please
ignore it. I've reposted in the correct thread now.
Karl Fogel <kf...@red-bean.com> writes:
> Wait, I think I've got it!
>
> The problem is that the "svn:special" property is set to "link" on both
> the old and new file, so it never appears as a prop diff -- nor should
> it, since there's no difference.
>
> But (I think) the code that handles the "svn:special" property only gets
> activated when the property is added or removed. (I guess it would also
> get activated if the property value changed, but in practice, it's
> always "link" right now, since the details appear in the file text.
> Thus our concern here is with the property being added or removed.)
>
> I haven't investigated this line of reasoning yet, but will later
> tonight if no one beats me to it.
>
> -Karl
>
> Karl Fogel <kf...@red-bean.com> writes:
>> John McGrath <jo...@xilinx.com> writes:
>>> My understanding is that 'svn list' will show the contents of the
>>> repository for the same path as the current directory in the
>>> workspace.
>>>
>>> For example, if my workspace has
>>> dir1/
>>> dir2/
>>> file1
>>>
>>> but the repository has a new directory recently added, called dir3,
>>> svn ls would report
>>> dir1/
>>> dir2/
>>> dir3/
>>> file1
>>>
>>> i.e. it shows me the contents of the repository.
>>>
>>> However, if the local workspace was originally checked out with the -N
>>> (non-recursive) command,
>>> running svn ls would only show me the directories I have, it would not
>>> show me dir3!
>>
>> I cannot reproduce this. Could you give a complete reproduction recipe
>> please (that is, a script)? My transcript is below.
>>
>>> This appears to be a bug - becuase if not, what advantage is svn ls
>>> over plain ls, in this case?
>>> I have tested this will the latest svn 1.5.2, and it still operates in
>>> this way.
>>>
>>> The same thing goes for svn update, if the local working direcotory
>>> was originally checked out with -N, running svn update will only get
>>> the contents of directories that are in the workspace.
>>> It would be great if there was a switch to force recursion, like -R or
>>> something, or even -R n, where n would be a number of levels.
>>
>> -N is deprecated; we use --depth=foo now. And the --set-depth option
>> does what you want.
>>
>>> At the very least, I think this is a bug in the terms of svn ls,
>>> changing svn update to work as described is a bonus!
>>
>> The reported 'svn ls' behavior would be a bug, I think; but I cannot
>> reproduce it with latest trunk Subversion (which is similar to 1.5.2,
>> though not exactly the same).
>>
>> The 'update' behavior is as-designed, and you should use --set-depth to
>> expand ("unfold") the directories.
>>
>> Here's my repro script:
>>
>> ---------------------------------------------------------------------------
>> #!/bin/sh
>>
>> # The next line is the only line you should need to adjust.
>> SVNDIR=/home/kfogel/src/subversion
>>
>> SVN=${SVNDIR}/subversion/svn/svn
>> SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
>> SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
>>
>> URL=file:///`pwd`/repos
>>
>> rm -rf repos wc import-me
>>
>> ${SVNADMIN} create repos
>>
>> echo "### Making a Greek Tree for import..."
>> mkdir import-me
>> mkdir import-me/trunk
>> mkdir import-me/tags
>> mkdir import-me/branches
>> mkdir import-me/trunk/A
>> mkdir import-me/trunk/A/B/
>> mkdir import-me/trunk/A/C/
>> mkdir import-me/trunk/A/D/
>> mkdir import-me/trunk/A/B/E/
>> mkdir import-me/trunk/A/B/F/
>> mkdir import-me/trunk/A/D/G/
>> mkdir import-me/trunk/A/D/H/
>> echo "This is the file 'iota'." > import-me/trunk/iota
>> echo "This is the file 'A/mu'." > import-me/trunk/A/mu
>> echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
>> echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
>> echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
>> echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
>> echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
>> echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
>> echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
>> echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
>> echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
>> echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
>> echo "### Done."
>> echo ""
>> echo "### Importing it..."
>> (cd import-me; ${SVN} import -q -m "Initial import." ${URL})
>> echo "### Done."
>> echo ""
>>
>> ${SVN} co -q -N ${URL}/trunk wc
>>
>> cd wc
>> ${SVN} ls
>> cd ..
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn list no working for some working directories
Posted by Karl Fogel <kf...@red-bean.com>.
Wait, I think I've got it!
The problem is that the "svn:special" property is set to "link" on both
the old and new file, so it never appears as a prop diff -- nor should
it, since there's no difference.
But (I think) the code that handles the "svn:special" property only gets
activated when the property is added or removed. (I guess it would also
get activated if the property value changed, but in practice, it's
always "link" right now, since the details appear in the file text.
Thus our concern here is with the property being added or removed.)
I haven't investigated this line of reasoning yet, but will later
tonight if no one beats me to it.
-Karl
Karl Fogel <kf...@red-bean.com> writes:
> John McGrath <jo...@xilinx.com> writes:
>> My understanding is that 'svn list' will show the contents of the
>> repository for the same path as the current directory in the
>> workspace.
>>
>> For example, if my workspace has
>> dir1/
>> dir2/
>> file1
>>
>> but the repository has a new directory recently added, called dir3,
>> svn ls would report
>> dir1/
>> dir2/
>> dir3/
>> file1
>>
>> i.e. it shows me the contents of the repository.
>>
>> However, if the local workspace was originally checked out with the -N
>> (non-recursive) command,
>> running svn ls would only show me the directories I have, it would not
>> show me dir3!
>
> I cannot reproduce this. Could you give a complete reproduction recipe
> please (that is, a script)? My transcript is below.
>
>> This appears to be a bug - becuase if not, what advantage is svn ls
>> over plain ls, in this case?
>> I have tested this will the latest svn 1.5.2, and it still operates in
>> this way.
>>
>> The same thing goes for svn update, if the local working direcotory
>> was originally checked out with -N, running svn update will only get
>> the contents of directories that are in the workspace.
>> It would be great if there was a switch to force recursion, like -R or
>> something, or even -R n, where n would be a number of levels.
>
> -N is deprecated; we use --depth=foo now. And the --set-depth option
> does what you want.
>
>> At the very least, I think this is a bug in the terms of svn ls,
>> changing svn update to work as described is a bonus!
>
> The reported 'svn ls' behavior would be a bug, I think; but I cannot
> reproduce it with latest trunk Subversion (which is similar to 1.5.2,
> though not exactly the same).
>
> The 'update' behavior is as-designed, and you should use --set-depth to
> expand ("unfold") the directories.
>
> Here's my repro script:
>
> ---------------------------------------------------------------------------
> #!/bin/sh
>
> # The next line is the only line you should need to adjust.
> SVNDIR=/home/kfogel/src/subversion
>
> SVN=${SVNDIR}/subversion/svn/svn
> SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
> SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
>
> URL=file:///`pwd`/repos
>
> rm -rf repos wc import-me
>
> ${SVNADMIN} create repos
>
> echo "### Making a Greek Tree for import..."
> mkdir import-me
> mkdir import-me/trunk
> mkdir import-me/tags
> mkdir import-me/branches
> mkdir import-me/trunk/A
> mkdir import-me/trunk/A/B/
> mkdir import-me/trunk/A/C/
> mkdir import-me/trunk/A/D/
> mkdir import-me/trunk/A/B/E/
> mkdir import-me/trunk/A/B/F/
> mkdir import-me/trunk/A/D/G/
> mkdir import-me/trunk/A/D/H/
> echo "This is the file 'iota'." > import-me/trunk/iota
> echo "This is the file 'A/mu'." > import-me/trunk/A/mu
> echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
> echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
> echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
> echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
> echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
> echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
> echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
> echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
> echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
> echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
> echo "### Done."
> echo ""
> echo "### Importing it..."
> (cd import-me; ${SVN} import -q -m "Initial import." ${URL})
> echo "### Done."
> echo ""
>
> ${SVN} co -q -N ${URL}/trunk wc
>
> cd wc
> ${SVN} ls
> cd ..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn list no working for some working directories
Posted by John Mcgrath <jo...@xilinx.com>.
Hi Julian, Karl,
Thank you both for this!
I have aliased svnls to be 'svn ls -r HEAD', so I can run a quick 'ls'
on the repository, without having to update my workspace first, and it
works wonderfully!!
Thanks again!
John
-----Original Message-----
From: Julian Foad [mailto:julianfoad@btopenworld.com]
Sent: Monday, September 08, 2008 5:20 PM
To: John Mcgrath
Cc: Karl Fogel; users@subversion.tigris.org; dev@subversion.tigris.org
Subject: RE: svn list no working for some working directories
John Mcgrath wrote:
> Hi Karl,
> Thanks for your response on this - it is greatly appreciated.
> I modified your script to reproduce the error (well done, it is a very
> nice, neat way of describing a problem, I must say!)
John,
Looking at what your script does, I can see this is just a case of the
default revision for "svn list" being "BASE" and not "HEAD". At the end
of your script, where you do "svn ls" in "wc1", you would find the same
lack of visibility in "wc" (because BASE rev of "." is still 1 though
BASE rev of the file that was committed is 2):
[[[
> $ svn st -v wc
> 1 1 julianfoad wc
> 2 2 julianfoad wc/ls_should_see
> 1 1 julianfoad wc/iota
> $ svn ls wc
> A/
> iota
> $ svn ls wc@HEAD
> A/
> iota
> ls_should_see/
]]]
In both wc and wc1, if you "svn update" first you'll see "svn ls" will
then show the newly added dir.
- Julian
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn list no working for some working directories
Posted by John Mcgrath <jo...@xilinx.com>.
Hi Julian, Karl,
Thank you both for this!
I have aliased svnls to be 'svn ls -r HEAD', so I can run a quick 'ls'
on the repository, without having to update my workspace first, and it
works wonderfully!!
Thanks again!
John
-----Original Message-----
From: Julian Foad [mailto:julianfoad@btopenworld.com]
Sent: Monday, September 08, 2008 5:20 PM
To: John Mcgrath
Cc: Karl Fogel; users@subversion.tigris.org; dev@subversion.tigris.org
Subject: RE: svn list no working for some working directories
John Mcgrath wrote:
> Hi Karl,
> Thanks for your response on this - it is greatly appreciated.
> I modified your script to reproduce the error (well done, it is a very
> nice, neat way of describing a problem, I must say!)
John,
Looking at what your script does, I can see this is just a case of the
default revision for "svn list" being "BASE" and not "HEAD". At the end
of your script, where you do "svn ls" in "wc1", you would find the same
lack of visibility in "wc" (because BASE rev of "." is still 1 though
BASE rev of the file that was committed is 2):
[[[
> $ svn st -v wc
> 1 1 julianfoad wc
> 2 2 julianfoad wc/ls_should_see
> 1 1 julianfoad wc/iota
> $ svn ls wc
> A/
> iota
> $ svn ls wc@HEAD
> A/
> iota
> ls_should_see/
]]]
In both wc and wc1, if you "svn update" first you'll see "svn ls" will
then show the newly added dir.
- Julian
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn list no working for some working directories
Posted by Julian Foad <ju...@btopenworld.com>.
John Mcgrath wrote:
> Hi Karl,
> Thanks for your response on this - it is greatly appreciated.
> I modified your script to reproduce the error (well done, it is a very
> nice, neat way of describing a problem, I must say!)
John,
Looking at what your script does, I can see this is just a case of the
default revision for "svn list" being "BASE" and not "HEAD". At the end
of your script, where you do "svn ls" in "wc1", you would find the same
lack of visibility in "wc" (because BASE rev of "." is still 1 though
BASE rev of the file that was committed is 2):
[[[
> $ svn st -v wc
> 1 1 julianfoad wc
> 2 2 julianfoad wc/ls_should_see
> 1 1 julianfoad wc/iota
> $ svn ls wc
> A/
> iota
> $ svn ls wc@HEAD
> A/
> iota
> ls_should_see/
]]]
In both wc and wc1, if you "svn update" first you'll see "svn ls" will
then show the newly added dir.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn list no working for some working directories
Posted by Julian Foad <ju...@btopenworld.com>.
John Mcgrath wrote:
> Hi Karl,
> Thanks for your response on this - it is greatly appreciated.
> I modified your script to reproduce the error (well done, it is a very
> nice, neat way of describing a problem, I must say!)
John,
Looking at what your script does, I can see this is just a case of the
default revision for "svn list" being "BASE" and not "HEAD". At the end
of your script, where you do "svn ls" in "wc1", you would find the same
lack of visibility in "wc" (because BASE rev of "." is still 1 though
BASE rev of the file that was committed is 2):
[[[
> $ svn st -v wc
> 1 1 julianfoad wc
> 2 2 julianfoad wc/ls_should_see
> 1 1 julianfoad wc/iota
> $ svn ls wc
> A/
> iota
> $ svn ls wc@HEAD
> A/
> iota
> ls_should_see/
]]]
In both wc and wc1, if you "svn update" first you'll see "svn ls" will
then show the newly added dir.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn list no working for some working directories
Posted by Karl Fogel <kf...@red-bean.com>.
John Mcgrath <jo...@xilinx.com> writes:
> I modified your script to reproduce the error (well done, it is a very
> nice, neat way of describing a problem, I must say!)
Thanks! In r32969, I added it to our bug-reporting instructions, so
future bug reports can offer such a script from the beginning.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn list no working for some working directories
Posted by Karl Fogel <kf...@red-bean.com>.
John Mcgrath <jo...@xilinx.com> writes:
> I modified your script to reproduce the error (well done, it is a very
> nice, neat way of describing a problem, I must say!)
Thanks! In r32969, I added it to our bug-reporting instructions, so
future bug reports can offer such a script from the beginning.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn list no working for some working directories
Posted by John Mcgrath <jo...@xilinx.com>.
Hi Karl,
Thanks for your response on this - it is greatly appreciated.
I modified your script to reproduce the error (well done, it is a very
nice, neat way of describing a problem, I must say!)
------------------------------------------------------------------------
---
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/jmcgrath/bin/linux/subversion/subversion-1.5.2/bin
SVN=${SVNDIR}/svn
SVNSERVE=${SVNDIR}/svnserve
SVNADMIN=${SVNDIR}/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc* import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda echo
"This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha echo
"This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL}); echo "###
Done."
echo ""
${SVN} co -q -N ${URL}/trunk wc
${SVN} co -q -N ${URL}/trunk wc1
cd wc
mkdir ls_should_see
${SVN} add ls_should_see -q
${SVN} ci ls_should_see -q -m "initial import"
cd ..
echo "### Should see the directory 'ls_should_see' below..."
# this is because svn ls should be looking @ the repository
# but we do not see it
cd wc1
${SVN} ls
cd ..
------------------------------------------------------------------------
---
Cheers,
John
-----Original Message-----
From: Karl Fogel [mailto:kfogel@red-bean.com]
Sent: Friday, September 05, 2008 9:45 PM
To: John Mcgrath
Cc: users@subversion.tigris.org; dev@subversion.tigris.org
Subject: Re: svn list no working for some working directories
John McGrath <jo...@xilinx.com> writes:
> My understanding is that 'svn list' will show the contents of the
> repository for the same path as the current directory in the
> workspace.
>
> For example, if my workspace has
> dir1/
> dir2/
> file1
>
> but the repository has a new directory recently added, called dir3,
> svn ls would report
> dir1/
> dir2/
> dir3/
> file1
>
> i.e. it shows me the contents of the repository.
>
> However, if the local workspace was originally checked out with the -N
> (non-recursive) command,
> running svn ls would only show me the directories I have, it would not
> show me dir3!
I cannot reproduce this. Could you give a complete reproduction recipe
please (that is, a script)? My transcript is below.
> This appears to be a bug - becuase if not, what advantage is svn ls
> over plain ls, in this case?
> I have tested this will the latest svn 1.5.2, and it still operates in
> this way.
>
> The same thing goes for svn update, if the local working direcotory
> was originally checked out with -N, running svn update will only get
> the contents of directories that are in the workspace.
> It would be great if there was a switch to force recursion, like -R or
> something, or even -R n, where n would be a number of levels.
-N is deprecated; we use --depth=foo now. And the --set-depth option
does what you want.
> At the very least, I think this is a bug in the terms of svn ls,
> changing svn update to work as described is a bonus!
The reported 'svn ls' behavior would be a bug, I think; but I cannot
reproduce it with latest trunk Subversion (which is similar to 1.5.2,
though not exactly the same).
The 'update' behavior is as-designed, and you should use --set-depth to
expand ("unfold") the directories.
Here's my repro script:
------------------------------------------------------------------------
---
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
echo "### Done."
echo ""
${SVN} co -q -N ${URL}/trunk wc
cd wc
${SVN} ls
cd ..
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn list no working for some working directories
Posted by John Mcgrath <jo...@xilinx.com>.
Hi Karl,
Thanks for your response on this - it is greatly appreciated.
I modified your script to reproduce the error (well done, it is a very
nice, neat way of describing a problem, I must say!)
------------------------------------------------------------------------
---
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/jmcgrath/bin/linux/subversion/subversion-1.5.2/bin
SVN=${SVNDIR}/svn
SVNSERVE=${SVNDIR}/svnserve
SVNADMIN=${SVNDIR}/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc* import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda echo
"This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha echo
"This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL}); echo "###
Done."
echo ""
${SVN} co -q -N ${URL}/trunk wc
${SVN} co -q -N ${URL}/trunk wc1
cd wc
mkdir ls_should_see
${SVN} add ls_should_see -q
${SVN} ci ls_should_see -q -m "initial import"
cd ..
echo "### Should see the directory 'ls_should_see' below..."
# this is because svn ls should be looking @ the repository
# but we do not see it
cd wc1
${SVN} ls
cd ..
------------------------------------------------------------------------
---
Cheers,
John
-----Original Message-----
From: Karl Fogel [mailto:kfogel@red-bean.com]
Sent: Friday, September 05, 2008 9:45 PM
To: John Mcgrath
Cc: users@subversion.tigris.org; dev@subversion.tigris.org
Subject: Re: svn list no working for some working directories
John McGrath <jo...@xilinx.com> writes:
> My understanding is that 'svn list' will show the contents of the
> repository for the same path as the current directory in the
> workspace.
>
> For example, if my workspace has
> dir1/
> dir2/
> file1
>
> but the repository has a new directory recently added, called dir3,
> svn ls would report
> dir1/
> dir2/
> dir3/
> file1
>
> i.e. it shows me the contents of the repository.
>
> However, if the local workspace was originally checked out with the -N
> (non-recursive) command,
> running svn ls would only show me the directories I have, it would not
> show me dir3!
I cannot reproduce this. Could you give a complete reproduction recipe
please (that is, a script)? My transcript is below.
> This appears to be a bug - becuase if not, what advantage is svn ls
> over plain ls, in this case?
> I have tested this will the latest svn 1.5.2, and it still operates in
> this way.
>
> The same thing goes for svn update, if the local working direcotory
> was originally checked out with -N, running svn update will only get
> the contents of directories that are in the workspace.
> It would be great if there was a switch to force recursion, like -R or
> something, or even -R n, where n would be a number of levels.
-N is deprecated; we use --depth=foo now. And the --set-depth option
does what you want.
> At the very least, I think this is a bug in the terms of svn ls,
> changing svn update to work as described is a bonus!
The reported 'svn ls' behavior would be a bug, I think; but I cannot
reproduce it with latest trunk Subversion (which is similar to 1.5.2,
though not exactly the same).
The 'update' behavior is as-designed, and you should use --set-depth to
expand ("unfold") the directories.
Here's my repro script:
------------------------------------------------------------------------
---
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
echo "### Done."
echo ""
${SVN} co -q -N ${URL}/trunk wc
cd wc
${SVN} ls
cd ..
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn list no working for some working directories
Posted by Karl Fogel <kf...@red-bean.com>.
John McGrath <jo...@xilinx.com> writes:
> My understanding is that 'svn list' will show the contents of the
> repository for the same path as the current directory in the
> workspace.
>
> For example, if my workspace has
> dir1/
> dir2/
> file1
>
> but the repository has a new directory recently added, called dir3,
> svn ls would report
> dir1/
> dir2/
> dir3/
> file1
>
> i.e. it shows me the contents of the repository.
>
> However, if the local workspace was originally checked out with the -N
> (non-recursive) command,
> running svn ls would only show me the directories I have, it would not
> show me dir3!
I cannot reproduce this. Could you give a complete reproduction recipe
please (that is, a script)? My transcript is below.
> This appears to be a bug - becuase if not, what advantage is svn ls
> over plain ls, in this case?
> I have tested this will the latest svn 1.5.2, and it still operates in
> this way.
>
> The same thing goes for svn update, if the local working direcotory
> was originally checked out with -N, running svn update will only get
> the contents of directories that are in the workspace.
> It would be great if there was a switch to force recursion, like -R or
> something, or even -R n, where n would be a number of levels.
-N is deprecated; we use --depth=foo now. And the --set-depth option
does what you want.
> At the very least, I think this is a bug in the terms of svn ls,
> changing svn update to work as described is a bonus!
The reported 'svn ls' behavior would be a bug, I think; but I cannot
reproduce it with latest trunk Subversion (which is similar to 1.5.2,
though not exactly the same).
The 'update' behavior is as-designed, and you should use --set-depth to
expand ("unfold") the directories.
Here's my repro script:
---------------------------------------------------------------------------
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
echo "### Done."
echo ""
${SVN} co -q -N ${URL}/trunk wc
cd wc
${SVN} ls
cd ..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn list no working for some working directories
Posted by Karl Fogel <kf...@red-bean.com>.
John McGrath <jo...@xilinx.com> writes:
> My understanding is that 'svn list' will show the contents of the
> repository for the same path as the current directory in the
> workspace.
>
> For example, if my workspace has
> dir1/
> dir2/
> file1
>
> but the repository has a new directory recently added, called dir3,
> svn ls would report
> dir1/
> dir2/
> dir3/
> file1
>
> i.e. it shows me the contents of the repository.
>
> However, if the local workspace was originally checked out with the -N
> (non-recursive) command,
> running svn ls would only show me the directories I have, it would not
> show me dir3!
I cannot reproduce this. Could you give a complete reproduction recipe
please (that is, a script)? My transcript is below.
> This appears to be a bug - becuase if not, what advantage is svn ls
> over plain ls, in this case?
> I have tested this will the latest svn 1.5.2, and it still operates in
> this way.
>
> The same thing goes for svn update, if the local working direcotory
> was originally checked out with -N, running svn update will only get
> the contents of directories that are in the workspace.
> It would be great if there was a switch to force recursion, like -R or
> something, or even -R n, where n would be a number of levels.
-N is deprecated; we use --depth=foo now. And the --set-depth option
does what you want.
> At the very least, I think this is a bug in the terms of svn ls,
> changing svn update to work as described is a bonus!
The reported 'svn ls' behavior would be a bug, I think; but I cannot
reproduce it with latest trunk Subversion (which is similar to 1.5.2,
though not exactly the same).
The 'update' behavior is as-designed, and you should use --set-depth to
expand ("unfold") the directories.
Here's my repro script:
---------------------------------------------------------------------------
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc import-me
${SVNADMIN} create repos
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
echo "### Done."
echo ""
${SVN} co -q -N ${URL}/trunk wc
cd wc
${SVN} ls
cd ..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org