Sorry if my language was confusing. As you say below, the behavior of svn up is correct, it is svn info and svnversion that I think are wrong (as they should indicate this is a sparse checkout). I have run into this issue before randomly without doing the svn up --set-depth (i.e. I have gotten into this state where svn info does not indicate sparseness but there are items missing), but I can't remember how - the set of steps below is the easiest way to reproduce this.
Paul Burba wrote:
> On Wed, Aug 5, 2009 at 4:06 PM, Alfonso Gonzalez del
> Riego<agonzalez_at_itasoftware.com> wrote:
>> I sent this potential bug report to the users mailing list some time ago but it was never addressed. It is still reproducible with svn 1.6.3.
>> -------- Original Message --------
>> Subject: Problem with svn up --set-depth?
>> Date: Thu, 11 Jun 2009 16:55:02 -0400
>> From: Alfonso Gonzalez del Riego <agonzalez_at_itasoftware.com>
>> To: users_at_subversion.tigris.org
>> I have run into the following problem, which seems like a subversion bug:
>> (With svn 1.6.2)
>> Create a repo:
>> cd /blah
>> svnadmin create test
>> svn mkdir file:///blah/test/trunk -m "Create folder"
>> svn co file:///blah/test/trunk
>> Add some folders and files:
>> cd trunk
>> svn mkdir f1
>> svn mkdir f2
>> svn commit -m "Add some folders"
>> Exclude a folder
>> svn up --set-depth=exclude f2
>> Now, neither svn info nor svnversion report that this is a sparse checkout, yet doing svn up will never pull f2 again (unles you svn up --set-depth infinity).
> Hi Alfonso,
> I wouldn't expect svn up to ever pull down f2 again, you have
> requested that it be excluded (I don't think this is what you mean,
> but your use of "yet" gives me pause).
> I do agree that there should be some way (e.g. svn info or svnversion)
> to determine that we have excluded subtrees in our working copy. Is
> that what you are getting at?
Received on 2009-08-06 20:24:05 CEST