You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Walter Klust <wa...@elego.de> on 2012/09/06 17:02:18 UTC

Externals: Multiple definitions for the same path

When setting or modifying the svn:externals property it is possible to specify multiple entries for the same path.

Example:

svn propget svn:externals trunk

https://svn-server:8080/svn/multi/extfolder1 barf
https://svn-server:8080/svn/multi/extfolder2 barf
https://svn-server:8080/svn/multi/extfolder1 barf
https://svn-server:8080/svn/multi/extfolder2 barf

IMHO only one entry per path should be allowed.

Would it make sense to implement a check in the command line client and issue at least a warning if someone tries to 
commit this kind of property ?


Walter

Re: Externals: Multiple definitions for the same path

Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Sep 6, 2012 at 11:18 AM, C. Michael Pilato <cm...@collab.net>wrote:


> One question, though:  is there any circumstance in which this
> functionality
> could be beneficial?  What happens if, say, I have an externals URL that's
> referenced by one URL when I'm inside my corporate firewall, and a
> different
> URL otherwise?
>
>     http://internal-only.company.com/svn/repos/my/external     ext-wc
>     https://externals-only.company.com/svn/repos/my/external   ext-wc
>
> Does Subversion gracefully handle that, allowing the last working external
> in the list to be the one that "takes"?
>

I would be surprised if that is handled gracefully, and we added support
for relative externals to solve this problem anyway.  So it seems like that
would be the solution.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: Externals: Multiple definitions for the same path

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 7 september 2012 15:27
> To: Walter Klust
> Cc: dev@subversion.apache.org
> Subject: Re: Externals: Multiple definitions for the same path
> 
> I suppose we could define the order for a single svn:externals but users
> can also use multiple svn:externals:
> 
> svn ps svn:externals ^/X1 A/B/C' .
> svn ps svn:externals ^/X2 B/C' ./A
> 
> There has been at least one report that something like (I don't remember
> the exact details):
> 
> svn ps svn:externals ^/X1 A/B' .
> svn ps svn:externals ^/X2 B/C' ./A
> 
> worked in 1.6 and didn't work in 1.7.

Defining a strict and stable order now would make it impossible to add
things like parallel updates later. 

We don't promise the order in which an svn update processes your working
copy either. We just promise that it gets to a final state when the update
is completed.
(And that you get notifications and a lot of other things...)

	Bert


Re: Externals: Multiple definitions for the same path

Posted by Philip Martin <ph...@wandisco.com>.
I suppose we could define the order for a single svn:externals but users
can also use multiple svn:externals:

svn ps svn:externals ^/X1 A/B/C' .
svn ps svn:externals ^/X2 B/C' ./A

There has been at least one report that something like (I don't remember
the exact details):

svn ps svn:externals ^/X1 A/B' .
svn ps svn:externals ^/X2 B/C' ./A

worked in 1.6 and didn't work in 1.7.

Walter Klust <wa...@elego.de> writes:

> Another minor issue: The sequence in which external definitions are applied on checkout/update is not explicitly specified in the documentation.
> The current behaviour should be documented and an according testcase provided.
>
> Thoughts ?
>
> On 06.09.2012 17:18, C. Michael Pilato wrote:
>> Walter,
>>
>> I agree that this seems like a great opportunity for Subversion to tell
>> folks they've done something that they probably don't mean to do.  Of
>> course, we don't want to break existing versioned files by erroring out if
>> we encounter this already present.  But we certainly could error out any
>> time a new or modified svn:externals property that violates this constraint
>> is about to be set on a directory.
>>
>> Feel free to file an issue in our tracker if you are able to do so,
>> referencing this thread:  http://svn.haxx.se/dev/archive-2012-09/0091.shtml
>>
>> One question, though:  is there any circumstance in which this functionality
>> could be beneficial?  What happens if, say, I have an externals URL that's
>> referenced by one URL when I'm inside my corporate firewall, and a different
>> URL otherwise?
>>
>>      http://internal-only.company.com/svn/repos/my/external     ext-wc
>>      https://externals-only.company.com/svn/repos/my/external   ext-wc
>>
>> Does Subversion gracefully handle that, allowing the last working external
>> in the list to be the one that "takes"?
>>
>> -- C-Mike
>>
>> On 09/06/2012 11:02 AM, Walter Klust wrote:
>>> When setting or modifying the svn:externals property it is possible to
>>> specify multiple entries for the same path.
>>>
>>> Example:
>>>
>>> svn propget svn:externals trunk
>>>
>>> https://svn-server:8080/svn/multi/extfolder1 barf
>>> https://svn-server:8080/svn/multi/extfolder2 barf
>>> https://svn-server:8080/svn/multi/extfolder1 barf
>>> https://svn-server:8080/svn/multi/extfolder2 barf
>>>
>>> IMHO only one entry per path should be allowed.
>>>
>>> Would it make sense to implement a check in the command line client and
>>> issue at least a warning if someone tries to commit this kind of property ?
>>>
>>>
>>> Walter
>>
>>
>
>
> -- 
> Walter Klust, Director Support
>
> fon +49 30 2345 8696, fax +49 30 2345 8695
> support +49 30 322 971 300
>
> elego Software Solutions GmbH, http://www.elegosoft.com
> Building 12 (BIG), Gustav-Meyer-Allee 25, 13355 Berlin, Germany
>
> Registered Office: Berlin, VAT Reg No: DE 163214194
> Trade Register: District Court Charlottenburg HRB 77719
> Managing Directors: Olaf Wagner, Michael Diers
>

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Externals: Multiple definitions for the same path

Posted by Walter Klust <wa...@elego.de>.
Another minor issue: The sequence in which external definitions are applied on checkout/update is not explicitly 
specified in the documentation.
The current behaviour should be documented and an according testcase provided.

Thoughts ?

On 06.09.2012 17:18, C. Michael Pilato wrote:
> Walter,
>
> I agree that this seems like a great opportunity for Subversion to tell
> folks they've done something that they probably don't mean to do.  Of
> course, we don't want to break existing versioned files by erroring out if
> we encounter this already present.  But we certainly could error out any
> time a new or modified svn:externals property that violates this constraint
> is about to be set on a directory.
>
> Feel free to file an issue in our tracker if you are able to do so,
> referencing this thread:  http://svn.haxx.se/dev/archive-2012-09/0091.shtml
>
> One question, though:  is there any circumstance in which this functionality
> could be beneficial?  What happens if, say, I have an externals URL that's
> referenced by one URL when I'm inside my corporate firewall, and a different
> URL otherwise?
>
>      http://internal-only.company.com/svn/repos/my/external     ext-wc
>      https://externals-only.company.com/svn/repos/my/external   ext-wc
>
> Does Subversion gracefully handle that, allowing the last working external
> in the list to be the one that "takes"?
>
> -- C-Mike
>
> On 09/06/2012 11:02 AM, Walter Klust wrote:
>> When setting or modifying the svn:externals property it is possible to
>> specify multiple entries for the same path.
>>
>> Example:
>>
>> svn propget svn:externals trunk
>>
>> https://svn-server:8080/svn/multi/extfolder1 barf
>> https://svn-server:8080/svn/multi/extfolder2 barf
>> https://svn-server:8080/svn/multi/extfolder1 barf
>> https://svn-server:8080/svn/multi/extfolder2 barf
>>
>> IMHO only one entry per path should be allowed.
>>
>> Would it make sense to implement a check in the command line client and
>> issue at least a warning if someone tries to commit this kind of property ?
>>
>>
>> Walter
>
>


-- 
Walter Klust, Director Support

fon +49 30 2345 8696, fax +49 30 2345 8695
support +49 30 322 971 300

elego Software Solutions GmbH, http://www.elegosoft.com
Building 12 (BIG), Gustav-Meyer-Allee 25, 13355 Berlin, Germany

Registered Office: Berlin, VAT Reg No: DE 163214194
Trade Register: District Court Charlottenburg HRB 77719
Managing Directors: Olaf Wagner, Michael Diers

Re: Externals: Multiple definitions for the same path

Posted by "C. Michael Pilato" <cm...@collab.net>.
Walter,

I agree that this seems like a great opportunity for Subversion to tell
folks they've done something that they probably don't mean to do.  Of
course, we don't want to break existing versioned files by erroring out if
we encounter this already present.  But we certainly could error out any
time a new or modified svn:externals property that violates this constraint
is about to be set on a directory.

Feel free to file an issue in our tracker if you are able to do so,
referencing this thread:  http://svn.haxx.se/dev/archive-2012-09/0091.shtml

One question, though:  is there any circumstance in which this functionality
could be beneficial?  What happens if, say, I have an externals URL that's
referenced by one URL when I'm inside my corporate firewall, and a different
URL otherwise?

    http://internal-only.company.com/svn/repos/my/external     ext-wc
    https://externals-only.company.com/svn/repos/my/external   ext-wc

Does Subversion gracefully handle that, allowing the last working external
in the list to be the one that "takes"?

-- C-Mike

On 09/06/2012 11:02 AM, Walter Klust wrote:
> When setting or modifying the svn:externals property it is possible to
> specify multiple entries for the same path.
> 
> Example:
> 
> svn propget svn:externals trunk
> 
> https://svn-server:8080/svn/multi/extfolder1 barf
> https://svn-server:8080/svn/multi/extfolder2 barf
> https://svn-server:8080/svn/multi/extfolder1 barf
> https://svn-server:8080/svn/multi/extfolder2 barf
> 
> IMHO only one entry per path should be allowed.
> 
> Would it make sense to implement a check in the command line client and
> issue at least a warning if someone tries to commit this kind of property ?
> 
> 
> Walter


-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development