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

Re: Can't commit multiple externals with depth infinity

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 09 Jul 2008 01:00:39 +0100

Bert Huijben (TCG) wrote:
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
>> Sent: woensdag 9 juli 2008 1:22
>> To: Bert Huijben (TCG)
>> Cc: dev_at_subversion.tigris.org
>> Subject: Re: Can't commit multiple externals with depth infinity
>>
>> Bert, this is almost certainly caused by the fact that your current
>> working directory and your externals directories are disjoint.
>
> My current directory is the directory containing the externals
Yes, yes, but by definition externals definition are fleshed out into
working copies in which the primary working copy contains no reference save
that in the svn:externals property. In other words, I would expect that
were you to examine ./.svn/entries, you'd find no record there of the
externals-created subdirectories. This is what I mean by "disjoint".

>> In non-recursive commit mode, though, Subversion is more conservative
>> about its locking, which turns out well in your case, as it never
>> bothers to check for each locked target that they all live in a single
>> working copy.
>
> Can I (and can TortoiseSVN+AnkhSVN) depend on this 'feature' for future
> 1.X versions of subversion?

I can't say. I mean, I'd like to say, "Sure, in fact this is only going to
get better in the future, to the point that you needn't even futz with the
whole --depth=empty bit to make it work." But I go a D- in fortune-telling
(primarily because I kept wanting to drill three holes in the crystal balls
and roll them towards triangularly arranged pins), and to my knowledge our
current API documentation doesn't promise the behavior.

> I just played a little further and came to an even stranger svn error.
>
>>> Using subversion 1.5.0:
>>>
>>> ============================
>>> # Create a test repository
>>>
>>> svnadmin create e:/q/repos
>>> svn mkdir -m "" file:///e:/q/repos/root
>>> svn mkdir -m "" file:///e:/q/repos/a
>>> svn mkdir -m "" file:///e:/q/repos/b
>>>
>>> # Create working copy
>>>
>>> svn co file:///e:/q/repos/root wc
>>> pushd wc
>>> svn pe svn:externals .
>>>
>>> # Add this to the externals property
>>> # a ^/a
>>> # b ^/b
>>>
>>> # Then fetch the externals
>>> svn up .
>>>
>>> # Make a few more changes
>>> echo > a/file
>>> echo > /b/file
>>> svn add a/file b/file
>>>
>>> # This fails:
>>>
>>> svn ci . a/file b/file -m ""
>>> #svn: Are all the targets part of the same working copy?
>>> #svn: Unable to lock 'E:\q\root\a'
>>>
>>> # But this succeeds:
>>> svn ci --depth=empty . a/file b/file -m ""
>>> #Adding a\file
>>> #Adding b\file
>>> #Sending .
>>> #Transmitting file data ..
>>> #Committed revision 4.
>
> svn pe .
> # Add the following external to the two existing externals
> # http://svn.collab.net/repos/svn/trunk/build/ build
>
> svn up
> echo > a/f
> echo > b/f
> echo > build/f
>
> # And then as expected
> svn ci -m "" . a/f b/f build/f
> #svn: Are all the targets part of the same working copy?
> #svn: Unable to lock 'E:\q\root\a'
>
> # But then I tried
>
> svn ci -m "" a/f b/f build/f
> #svn: Commit failed (details follow):
> #svn: Unrecognized URL scheme for ''
>
> ============================
> I never would have guessed this error.

So, was the problem then that the externals definition fields were reverse?
  Do we need to do a little svn_path_is_url() checking somewhere before
trying to foist data off to the RA layer?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-07-09 02:01:05 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.