[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn list no working for some working directories

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Fri, 05 Sep 2008 18:53:04 -0400

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 <kfogel_at_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 <kfogel_at_red-bean.com> writes:
>> John McGrath <john.mcgrath_at_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_at_subversion.tigris.org
>> For additional commands, e-mail: users-help_at_subversion.tigris.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-06 00:53:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.