WG: "svn status -u" and svn:externals - bug?

[Bay Karsten (BEG/ESR3)]

Hi SVN users,

I got no answer until now.

I think the problem described below is a bug.
Do you agree?

Is it too complex to understand?
If something is inexplicit please let me know.

Mit freundlichen Grüßen / Best regards

Karsten Bay

Bosch Engineering GmbH
BEG/ESR3
Postfach 13 50
74003 Heilbronn
GERMANY

karsten@de.bosch.com

Sitz: Abstatt, Registergericht: Amtsgericht Stuttgart HRB 108931
Aufsichtsratsvorsitzender: Rolf Leonhard; Geschäftsführung: Bernhard Bihr, 
Hanno Miorini
Umsatzsteuer-Identnummer (VAT no.): DE 18 21 37 093, Steuernummer: 99012/08009


_
Von: Bay Karsten (BEG/ESR3)
Gesendet: Freitag, 12. April 2013 15:49
An: 'users@subversion.apache.org'
Betreff: "svn status -u" and svn:externals - bug?


Hi SVN users,

I searched for this problem in the open issues but could not find a similar 
problem.
Can you help me to find out if this is a known problem/bug?

I have a repository with a few svn:externals. Some of them point to a specific 
revision (e.g. trunk@8) of their repository.
When I look up with "svn status -u" if I have to do an update SVN shows me 
files out of this external repositories which should be reputedly newer on the 
server.
The problem is that the external repository has newer revisions with a newer 
version of this file but this should not play a role for my repository (because 
of the trunk@8).

Example extract of the console output:
--
C:\WORKSPACE\SVN>svn propget svn:externals
file://???/SW/trunk@8 SW

C:\WORKSPACE\SVN>svn status -u
XSW
Status against revision:117

Performing status on external item at 'SW':
*8   C:\WORKSPACE\SVN\SW\Code.c
Status against revision: 13
--

I looked in the source code and tried to find the reason for this behavior.
I think that the problem is in status-cmd.c svn_cl__status().
There I found this piece of code which may cause this problem:
  /* We want our -u statuses to be against HEAD. */
  rev.kind = svn_opt_revision_head;
In my opinion in the case of external repository with fixed revision the check 
should be performed against this revision?


A similar problem exists if I do an update on a subfolder (one which is added 
by svn:externals and points to a specific revision) of my repository then the 
HEAD revision of this folder is checked out.


If needed I can try to do a repro-template.bat.
Normally I work with TortoiseSVN and SVN Notifier but because of the problem I 
tried to reproduce it on the command line.


Windows 7 - Subversion 1.7.9



Mit freundlichen Grüßen / Best regards

Karsten Bay

Bosch Engineering GmbH

Postfach 13 50
74003 Heilbronn
GERMANY

karsten@de.bosch.com

Sitz: Abstatt, Registergericht: Amtsgericht Stuttgart HRB 108931
Aufsichtsratsvorsitzender: Rolf Leonhard; Geschäftsführung: Bernhard Bihr, 
Hanno Miorini
Umsatzsteuer-Identnummer (VAT no.): DE 18 21 37 093, Steuernummer: 99012/08009

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Wed, May 1, 2013 at 5:01 PM, BRM  wrote:
> While I have not had the issue you are having, assuming the externals are in
> the same repository I would highly recommend changing from using the syntax
> you have to using the carrot (^) operator as it will save you many headaches
> if your original svn location changes.
>
> I.e. use:
>
> ^/FOLDER_A FOLDER_C
> ^/FOLDER_B FOLDER_D

Indeed, that's far better than using an absolute url with scheme etc.

> Also, I think the specific issue you are having (looking more closely at the
> error message below) is that AFAIK, SVN does not let you import specific
> files via externals - you have to do name spaces (aka folders) instead.

That's not correct. File externals are supported (since 1.6 I think).
They have a couple of specific problems though (a lot of which have
been fixed in 1.7), because their implementation is entirely different
from directory externals (file externals use the "switch" mechanism
underneath, while dir externals are essentially an embedded checkout
with some sugar on top).

So, concerning to the problem of the OP:

> From: "Hutchinson, Steve (UK)" 
> To: "users@subversion.apache.org" 
> Sent: Wednesday, May 1, 2013 7:01 AM
> Subject: SVN Externals 1.6 to 1.7 migration issue
>
> Hi,
>
> We're been using 1.6 svn externals to manage a FW task.
>
> In the repository we have a folder structure (which is pretty much defined
> by the tools we are using) as below :-
>
> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>
> Then using externals we link to those folder to create a WC PROJECT
> structure that looks like :-
>
> PROJECT -> FOLDER C ->  file_a1.txt, file_a2.txt, file_a3.txt AND
> file_b1.txt
> PROJECT -> FOLDER D ->  file_b1.txt, file_b2.txt, file_b3.txt
>
> The externals on PROJECT FOLDER we used looked like (not actually using file
> protocol, just created for example purposes) :-
>
> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>
> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>
> External failed:D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
> Error: Cannot insert a file external defined on
> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
> Error:  working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>
> We have tried a few things (will not share all at this point due to info
> overload), but wondered if there were any others that achieve something like
> this with 1.7 or could offer some advise ?

So essentially you are "injecting" a file external (file_b1.txt)
inside a directory external (FOLDER_C (an external of FOLDER_A)).

Hm, I remember some past discussions about edge cases like these
(during the working copy rewrite of 1.7), but I don't remember exactly
if this is actually a supported use case, or if it just happened to
work by accident in 1.6.

Perhaps someone else on this list can shed some light on this?

--
Johan

Re: "svn status -u" and svn:externals - bug?

[Johan Corveleyn]

On Thu, May 2, 2013 at 8:59 AM, Bay Karsten (BEG/ESR3)
 wrote:
> Hi SVN users,
>
> I got no answer until now.
>
> I think the problem described below is a bug.
> Do you agree?
>
> Is it too complex to understand?
> If something is inexplicit please let me know.
>
> Mit freundlichen Grüßen / Best regards
>
> Karsten Bay
>
> Bosch Engineering GmbH
> BEG/ESR3
> Postfach 13 50
> 74003 Heilbronn
> GERMANY
>
> karsten@de.bosch.com
>
> Sitz: Abstatt, Registergericht: Amtsgericht Stuttgart HRB 108931
> Aufsichtsratsvorsitzender: Rolf Leonhard; Geschäftsführung: Bernhard Bihr,
> Hanno Miorini
> Umsatzsteuer-Identnummer (VAT no.): DE 18 21 37 093, Steuernummer:
> 99012/08009
>
>
> _
> Von: Bay Karsten (BEG/ESR3)
> Gesendet: Freitag, 12. April 2013 15:49
> An: 'users@subversion.apache.org'
> Betreff: "svn status -u" and svn:externals - bug?
>
>
> Hi SVN users,
>
> I searched for this problem in the open issues but could not find a similar
> problem.
> Can you help me to find out if this is a known problem/bug?
>
> I have a repository with a few svn:externals. Some of them point to a
> specific revision (e.g. trunk@8) of their repository.
> When I look up with "svn status -u" if I have to do an update SVN shows me
> files out of this external repositories which should be reputedly newer on
> the server.
> The problem is that the external repository has newer revisions with a newer
> version of this file but this should not play a role for my repository
> (because of the trunk@8).
>
> Example extract of the console output:
> --
> C:\WORKSPACE\SVN>svn propget svn:externals
> file://???/SW/trunk@8 SW
>
> C:\WORKSPACE\SVN>svn status -u
> XSW
> Status against revision:117
>
> Performing status on external item at 'SW':
> *8   C:\WORKSPACE\SVN\SW\Code.c
> Status against revision: 13
> --
>
> I looked in the source code and tried to find the reason for this behavior.
> I think that the problem is in status-cmd.c svn_cl__status().
> There I found this piece of code which may cause this problem:
>   /* We want our -u statuses to be against HEAD. */
>   rev.kind = svn_opt_revision_head;
> In my opinion in the case of external repository with fixed revision the
> check should be performed against this revision?
>
>
> A similar problem exists if I do an update on a subfolder (one which is
> added by svn:externals and points to a specific revision) of my repository
> then the HEAD revision of this folder is checked out.
>
>
> If needed I can try to do a repro-template.bat.
> Normally I work with TortoiseSVN and SVN Notifier but because of the problem
> I tried to reproduce it on the command line.
>
>
> Windows 7 - Subversion 1.7.9
>

Hi Karsten,

It looks like an issue to me. If nobody challenges your findings
within the next couple of hours, feel free to file an issue.

However, I found this issue which looks exactly like what you're seeing:

http://subversion.tigris.org/issues/show_bug.cgi?id=3659 (Not
correct statuses for svn externals)

It's closed as fixed in 1.7.0. So either there was a regression since
1.7.0, or this issue wasn't fixed after all. I'm not sure if there is
a regression test for this.

Are you sure you used a 1.7.9 client for this?

You also pose a second question, related to updating a subfolder of an
external. But that is a different issue. The problem here is that,
once inside an external, svn doesn't really know that it's inside this
(pegged) external. It's just a (embedded) checkout as far as that 'svn
update' operation is concerned. I agree it's also a problem, but it's
more a design issue. For reference, here are some dev@ discussions
related to this:

http://svn.haxx.se/dev/archive-2010-08/0529.shtml ([RFC] 'External'
and 'Switched': common ground)
http://svn.haxx.se/dev/archive-2011-05/0104.shtml (Feature
wish/request: [--externals MODE] switch on update)

But I can't find an issue in the issue tracker about this ...

--
Johan

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn  wrote:
> On Wed, May 1, 2013 at 5:01 PM, BRM  wrote:
>> While I have not had the issue you are having, assuming the externals are in
>> the same repository I would highly recommend changing from using the syntax
>> you have to using the carrot (^) operator as it will save you many headaches
>> if your original svn location changes.
>>
>> I.e. use:
>>
>> ^/FOLDER_A FOLDER_C
>> ^/FOLDER_B FOLDER_D
>
> Indeed, that's far better than using an absolute url with scheme etc.
>
>> Also, I think the specific issue you are having (looking more closely at the
>> error message below) is that AFAIK, SVN does not let you import specific
>> files via externals - you have to do name spaces (aka folders) instead.
>
> That's not correct. File externals are supported (since 1.6 I think).
> They have a couple of specific problems though (a lot of which have
> been fixed in 1.7), because their implementation is entirely different
> from directory externals (file externals use the "switch" mechanism
> underneath, while dir externals are essentially an embedded checkout
> with some sugar on top).
>
> So, concerning to the problem of the OP:
>
>> From: "Hutchinson, Steve (UK)" 
>> To: "users@subversion.apache.org" 
>> Sent: Wednesday, May 1, 2013 7:01 AM
>> Subject: SVN Externals 1.6 to 1.7 migration issue
>>
>> Hi,
>>
>> We're been using 1.6 svn externals to manage a FW task.
>>
>> In the repository we have a folder structure (which is pretty much defined
>> by the tools we are using) as below :-
>>
>> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
>> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>>
>> Then using externals we link to those folder to create a WC PROJECT
>> structure that looks like :-
>>
>> PROJECT -> FOLDER C ->  file_a1.txt, file_a2.txt, file_a3.txt AND
>> file_b1.txt
>> PROJECT -> FOLDER D ->  file_b1.txt, file_b2.txt, file_b3.txt
>>
>> The externals on PROJECT FOLDER we used looked like (not actually using file
>> protocol, just created for example purposes) :-
>>
>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>>
>> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>>
>> External failed:D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
>> Error: Cannot insert a file external defined on
>> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
>> Error:  working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>>
>> We have tried a few things (will not share all at this point due to info
>> overload), but wondered if there were any others that achieve something like
>> this with 1.7 or could offer some advise ?
>
> So essentially you are "injecting" a file external (file_b1.txt)
> inside a directory external (FOLDER_C (an external of FOLDER_A)).
>
> Hm, I remember some past discussions about edge cases like these
> (during the working copy rewrite of 1.7), but I don't remember exactly
> if this is actually a supported use case, or if it just happened to
> work by accident in 1.6.
>
> Perhaps someone else on this list can shed some light on this?

I had the following conversation with Philip Martin, on IRC (#svn-dev):

<@jcorvel> philipm, perhaps you know the answer to this externals
question (works in 1.6, but no longer in 1.7):
http://svn.haxx.se/users/archive-2013-05/0006.shtml
 A file external defined in one working copy but located
inside another working copy is not going to work in 1.7 or 1.8.
 The directory external is a separate working copy with its
own .svn/wc.db and that knows nothing about the external defined in a
different .svn/wc.db
<@jcorvel> Ok. Sooo, is this more in the "it worked by accident in
1.6, but was never supposed to be supported" category? Or could this
be considered a regression?
<@jcorvel>  I guess it doesn't matter ... semantics ...
 I don't suppose we ever supported it deliberately.
<@jcorvel> perhaps the more interesting question then is: is this at
all supportable within the externals design (of wc-ng)? Or would this
require "externals 2.0"?
 If we change directory externals to be more like switch then
the directory externals become part of a single working copy.
<@jcorvel> ack
 It may be relatively simple to do that. At present if you
try to "svn sw URL path" and path does not exist then the switch
fails.
 But it only fails because of a high level check on path, in
the past it was possible to switch a non-existant path.
 (In the past being during 1.7 development)
 If you switch a path that does not exist that looks very
much like an external (it is how file externals are implemented)
 One of the difficulties about externals is that the
specification is so relaxed that there are so many different cases.
 Almost any change is going to break some untested corner
cases, while perhaps fixing other corner cases.
<@jcorvel> philipm: so, realistically, this will probably not be fixed
ve

Re: "svn status -u" and svn:externals - bug?

[Philip Martin]

Johan Corveleyn  writes:

> It looks like an issue to me. If nobody challenges your findings
> within the next couple of hours, feel free to file an issue.
>
> However, I found this issue which looks exactly like what you're seeing:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3659 (Not
> correct statuses for svn externals)
>
> It's closed as fixed in 1.7.0. So either there was a regression since
> 1.7.0, or this issue wasn't fixed after all. I'm not sure if there is
> a regression test for this.

svnadmin create repo --compatible-version 1.6
svn mkdir -mm file://`pwd`/repo/A ^/B
svnmucc -mm propset svn:externals '^/A@1 A' file://`pwd`/repo/B
svn mkdir -mm file://`pwd`/repo/A/C

Using 1.7:

  $ svn1.7 co file://`pwd`/repo/B wc
  $ svn1.7 st -u wc
  Xwc/A
  Status against revision:  3

  Performing status on external item at 'wc/A':
  */home/pm/sw/subversion/obj/wc/A/C
  *1   /home/pm/sw/subversion/obj/wc/A
  Status against revision:  3

Using 1.8:

  $ svn co file://`pwd`/repo/B wc
  $ svn st -u wc
  svn st -u wc
  Xwc/A
  Status against revision:  3

  Performing status on external item at 'wc/A':
  Status against revision:  1


It's fixed in 1.8.

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

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Thu, May 2, 2013 at 11:00 AM, Johan Corveleyn  wrote:
> On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn  wrote:
>> On Wed, May 1, 2013 at 5:01 PM, BRM  wrote:
>>> While I have not had the issue you are having, assuming the externals are in
>>> the same repository I would highly recommend changing from using the syntax
>>> you have to using the carrot (^) operator as it will save you many headaches
>>> if your original svn location changes.
>>>
>>> I.e. use:
>>>
>>> ^/FOLDER_A FOLDER_C
>>> ^/FOLDER_B FOLDER_D
>>
>> Indeed, that's far better than using an absolute url with scheme etc.
>>
>>> Also, I think the specific issue you are having (looking more closely at the
>>> error message below) is that AFAIK, SVN does not let you import specific
>>> files via externals - you have to do name spaces (aka folders) instead.
>>
>> That's not correct. File externals are supported (since 1.6 I think).
>> They have a couple of specific problems though (a lot of which have
>> been fixed in 1.7), because their implementation is entirely different
>> from directory externals (file externals use the "switch" mechanism
>> underneath, while dir externals are essentially an embedded checkout
>> with some sugar on top).
>>
>> So, concerning to the problem of the OP:
>>
>>> From: "Hutchinson, Steve (UK)" 
>>> To: "users@subversion.apache.org" 
>>> Sent: Wednesday, May 1, 2013 7:01 AM
>>> Subject: SVN Externals 1.6 to 1.7 migration issue
>>>
>>> Hi,
>>>
>>> We're been using 1.6 svn externals to manage a FW task.
>>>
>>> In the repository we have a folder structure (which is pretty much defined
>>> by the tools we are using) as below :-
>>>
>>> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
>>> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>>>
>>> Then using externals we link to those folder to create a WC PROJECT
>>> structure that looks like :-
>>>
>>> PROJECT -> FOLDER C ->  file_a1.txt, file_a2.txt, file_a3.txt AND
>>> file_b1.txt
>>> PROJECT -> FOLDER D ->  file_b1.txt, file_b2.txt, file_b3.txt
>>>
>>> The externals on PROJECT FOLDER we used looked like (not actually using file
>>> protocol, just created for example purposes) :-
>>>
>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>>>
>>> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>>>
>>> External failed:D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
>>> Error: Cannot insert a file external defined on
>>> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
>>> Error:  working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>>>
>>> We have tried a few things (will not share all at this point due to info
>>> overload), but wondered if there were any others that achieve something like
>>> this with 1.7 or could offer some advise ?
>>
>> So essentially you are "injecting" a file external (file_b1.txt)
>> inside a directory external (FOLDER_C (an external of FOLDER_A)).
>>
>> Hm, I remember some past discussions about edge cases like these
>> (during the working copy rewrite of 1.7), but I don't remember exactly
>> if this is actually a supported use case, or if it just happened to
>> work by accident in 1.6.
>>
>> Perhaps someone else on this list can shed some light on this?
>
> I had the following conversation with Philip Martin, on IRC (#svn-dev):
>
> <@jcorvel> philipm, perhaps you know the answer to this externals
> question (works in 1.6, but no longer in 1.7):
> http://svn.haxx.se/users/archive-2013-05/0006.shtml
>  A file external defined in one working copy but located
> inside another working copy is not going to work in 1.7 or 1.8.
>  The directory external is a separate working copy with its
> own .svn/wc.db and that knows nothing about the external defined in a
> different .svn/wc.db
> <@jcorvel> Ok. Sooo, is this more in the "it worked by accident in
> 1.6, but was never supposed to be supported" category? Or could this
> be considered a regression?
> <@jcorvel>  I guess it doesn't matter ... semantics ...
>  I don't suppose we ever supported it deliberately.
> <@jcorvel> perhaps the more interesting question then is: is this at
> all supportable within the externals design (of wc-ng)? Or would this
> require "externals 2.0"?
>  If we change directory externals to be more like switch then
> the directory externals become part of a single working copy.
> <@jcorvel> ack
>  It may be relatively simple to do that. At present if you
> try to "svn sw URL path" and path does not exist then the switch
> fails.
>  But it only fails because of a high level check on path, in
> the past it was possible to switch a non-existant path.
>  (In the past being during 1.7 development)
>  If you switch a path that does not exist that looks very
> much like an external (it is how file externals are implemented)
>  One of the difficulties about externals is that the
> specification is so relaxed that there are so many 

Fw: Problem with read only getting overwritten by rw - AuthzSVNAccessFile

[mcfreis]

Hi everybody,
 
I'm trying to setup up a server with different repositories over different 
 with LDAP and AuthzSVNAccessFile. Everything seems to work but a 
user can create a dir or a file even if he only has read access.
 
Taken from one accessfile:
 

[geraete-entw:/]
def2 = r
 
[geraete-entw:/Prozess/SvnSpielwiese]
def2 = rw
 
[geraete-entw:/Technologien/04_Adapterm]
def2 =
 
In this case user "def2" can create a dir or a file in "geraete-entw:/". 
What am I doing wrong?
 
If I change ist to:
 

[geraete-entw:/]
def2 = r
 
[geraete-entw:/Technologien/04_Adapterm]
def2 =
 
Then the user cannot create a dir or a file in "geraete-entw:/"!
 
Thank you
Björn Freise

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Thu, May 2, 2013 at 12:50 PM, Johan Corveleyn  wrote:
> On Thu, May 2, 2013 at 11:00 AM, Johan Corveleyn  wrote:
>> On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn  wrote:
>>> On Wed, May 1, 2013 at 5:01 PM, BRM  wrote:
 While I have not had the issue you are having, assuming the externals are 
 in
 the same repository I would highly recommend changing from using the syntax
 you have to using the carrot (^) operator as it will save you many 
 headaches
 if your original svn location changes.

 I.e. use:

 ^/FOLDER_A FOLDER_C
 ^/FOLDER_B FOLDER_D
>>>
>>> Indeed, that's far better than using an absolute url with scheme etc.
>>>
 Also, I think the specific issue you are having (looking more closely at 
 the
 error message below) is that AFAIK, SVN does not let you import specific
 files via externals - you have to do name spaces (aka folders) instead.
>>>
>>> That's not correct. File externals are supported (since 1.6 I think).
>>> They have a couple of specific problems though (a lot of which have
>>> been fixed in 1.7), because their implementation is entirely different
>>> from directory externals (file externals use the "switch" mechanism
>>> underneath, while dir externals are essentially an embedded checkout
>>> with some sugar on top).
>>>
>>> So, concerning to the problem of the OP:
>>>
 From: "Hutchinson, Steve (UK)" 
 To: "users@subversion.apache.org" 
 Sent: Wednesday, May 1, 2013 7:01 AM
 Subject: SVN Externals 1.6 to 1.7 migration issue

 Hi,

 We're been using 1.6 svn externals to manage a FW task.

 In the repository we have a folder structure (which is pretty much defined
 by the tools we are using) as below :-

 FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
 FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt

 Then using externals we link to those folder to create a WC PROJECT
 structure that looks like :-

 PROJECT -> FOLDER C ->  file_a1.txt, file_a2.txt, file_a3.txt AND
 file_b1.txt
 PROJECT -> FOLDER D ->  file_b1.txt, file_b2.txt, file_b3.txt

 The externals on PROJECT FOLDER we used looked like (not actually using 
 file
 protocol, just created for example purposes) :-

 file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
 file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
 file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt

 Worked ok with 1.6. We get the below error in 1.7 when updating of :-

 External failed:D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
 Error: Cannot insert a file external defined on
 'D:\FPGA\SVN_ISSUE\PROJECT' into the
 Error:  working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.

 We have tried a few things (will not share all at this point due to info
 overload), but wondered if there were any others that achieve something 
 like
 this with 1.7 or could offer some advise ?
>>>
>>> So essentially you are "injecting" a file external (file_b1.txt)
>>> inside a directory external (FOLDER_C (an external of FOLDER_A)).
>>>
>>> Hm, I remember some past discussions about edge cases like these
>>> (during the working copy rewrite of 1.7), but I don't remember exactly
>>> if this is actually a supported use case, or if it just happened to
>>> work by accident in 1.6.
>>>
>>> Perhaps someone else on this list can shed some light on this?
>>
>> I had the following conversation with Philip Martin, on IRC (#svn-dev):
>>
>> <@jcorvel> philipm, perhaps you know the answer to this externals
>> question (works in 1.6, but no longer in 1.7):
>> http://svn.haxx.se/users/archive-2013-05/0006.shtml
>>  A file external defined in one working copy but located
>> inside another working copy is not going to work in 1.7 or 1.8.
>>  The directory external is a separate working copy with its
>> own .svn/wc.db and that knows nothing about the external defined in a
>> different .svn/wc.db
>> <@jcorvel> Ok. Sooo, is this more in the "it worked by accident in
>> 1.6, but was never supposed to be supported" category? Or could this
>> be considered a regression?
>> <@jcorvel>  I guess it doesn't matter ... semantics ...
>>  I don't suppose we ever supported it deliberately.
>> <@jcorvel> perhaps the more interesting question then is: is this at
>> all supportable within the externals design (of wc-ng)? Or would this
>> require "externals 2.0"?
>>  If we change directory externals to be more like switch then
>> the directory externals become part of a single working copy.
>> <@jcorvel> ack
>>  It may be relatively simple to do that. At present if you
>> try to "svn sw URL path" and path does not exist then the switch
>> fails.
>>  But it only fails because of a high level check on path, in
>> the past it was possible to switch a non-existant path.
>>  (In the past being during 1.7 development)
>>  If you switch a path that does not exi

SASL authentication with fallback to native passwd file

[Os Tyler]

Thanks in advance for any help here.

We're using svnserve and I've successfully implemented SASL authentication 
against our company Active Directory LDAP instance. And our windows and linux 
clients are successfully connecting.

However the subversion client on our AS/400 servers does not support SASL.

I was looking for a way to configure subversion so that if the SASL 
authentication failed, it would fall back to the native passwd file and if a 
user/pass match was found there, auth would succeed.

I've searched the interwebs and the archives of this mailing list, but I'm not 
seeing that there is a way to accomplish this "SASL with fallback to native 
passwd file".

Is there a way?

Thanks,

Os Tyler

Re: SASL authentication with fallback to native passwd file

[Daniel Shahaf]

Os Tyler wrote on Thu, May 02, 2013 at 23:35:22 +:
> I've searched the interwebs and the archives of this mailing list, but
> I'm not seeing that there is a way to accomplish this "SASL with
> fallback to native passwd file".
> 
> Is there a way?

I don't think you can achieve this in svnserve.  Should be doable
in mod_dav_svn / httpd.conf though.  It's possible you could do this in
svnserve too by making a trivial modification to
subversion/svnserve/serve.c:auth_request().

Re: SASL authentication with fallback to native passwd file

[Stefan Sperling]

On Thu, May 02, 2013 at 11:35:22PM +, Os Tyler wrote:
> Thanks in advance for any help here.
> 
> We're using svnserve and I've successfully implemented SASL authentication 
> against our company Active Directory LDAP instance. And our windows and linux 
> clients are successfully connecting.
> 

Can you provide some details about how you configured svnserve with
SASL and ldap?

I'm not aware of any working example configuration to point people at
when they ask about svnserve+SASL+LDAP. The svnbook has some generic
advice but it doesn't really mention details.

Thanks!