Re: Modifying SVN Externals with Specific Revision

[Daniel Shahaf]

Crast, Nicholas wrote on Mon, Jan 25, 2016 at 14:16:52 +:
> For anyone else in the future, there is more information here:
> https://people.apache.org/~brane/svndocs/capi/group__Commit.html

Not quite.  That's trunk's documentation; promises made there are not
binding.  The released docs are these: https://subversion.apache.org/docs/#api

Cheers,

Daniel

RE: Modifying SVN Externals with Specific Revision

[Crast, Nicholas]

Thanks Daniel!

Exactly the information I was looking for. 

For anyone else in the future, there is more information here:
https://people.apache.org/~brane/svndocs/capi/group__Commit.html

-Nick


Nick Crast
Software Engineer
Saab Sensis Corporation
Phone: 315-445-5703
Email: nicholas.cr...@saabsensis.com


-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Saturday, January 23, 2016 7:00 PM
To: Crast, Nicholas
Cc: users@subversion.apache.org
Subject: Re: Modifying SVN Externals with Specific Revision

Crast, Nicholas wrote on Wed, Jan 20, 2016 at 21:05:51 +:
> This is, in fact, the behavior I want. I just want to know if it's 
> guaranteed that modifications to external directories with a specific 
> revisions will not be committed.

It is an explicit API promise of svn_client_commit6():

 * If @a include_file_externals and/or @a include_dir_externals are #TRUE,
 * also commit all file and/or dir externals (respectively) that are reached
 * by recursion, except for those externals which:
 * - have a fixed revision, or
 * - come from a different repository root URL (dir externals).
 * These flags affect only recursion; externals that directly appear in @a
 * targets are always included in the commit.

Cheers,

Daniel
-
This message is intended only for the addressee and may contain information 
that is company confidential or privileged.  Any technical data in this message 
may be exported only in accordance with the U.S. International Traffic in Arms 
Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 
CFR Parts 730-774). Unauthorized use is strictly prohibited and may be 
unlawful. If you are not the intended recipient, or the person responsible for 
delivering to the intended recipient, you should not read, copy, disclose or 
otherwise use this message. If you have received this email in error, please 
delete it, and advise the sender immediately. 
-  

Re: Modifying SVN Externals with Specific Revision

[Daniel Shahaf]

Crast, Nicholas wrote on Wed, Jan 20, 2016 at 21:05:51 +:
> This is, in fact, the behavior I want. I just want to know if it's
> guaranteed that modifications to external directories with a specific
> revisions will not be committed.

It is an explicit API promise of svn_client_commit6():

 * If @a include_file_externals and/or @a include_dir_externals are #TRUE,
 * also commit all file and/or dir externals (respectively) that are reached
 * by recursion, except for those externals which:
 * - have a fixed revision, or
 * - come from a different repository root URL (dir externals).
 * These flags affect only recursion; externals that directly appear in @a
 * targets are always included in the commit.

Cheers,

Daniel

Modifying SVN Externals with Specific Revision

[Crast, Nicholas]

Hi all,

I have a folder with the svn:externals property set, grabbing an external 
folder from a different part of the repository:
-r6367 ../common/testproc proc1/common

If I go into proc1/common and edit a file in there, svn stat shows the file as 
modified, but it seems that since I specified a specific revision, I am unable 
to commit the modified external file. It is essentially ignored by svn commit.

This is, in fact, the behavior I want. I just want to know if it's guaranteed 
that modifications to external directories with a specific revisions will not 
be committed.

Can someone verify this? Cannot find this specific case anywhere.

-Nick


Nick Crast
Software Engineer
Saab Sensis Corporation
Phone: 315-445-5703
Email: nicholas.cr...@saabsensis.com


This message is intended only for the addressee and may contain information 
that is company confidential or privileged. Any technical data in this message 
may be exported only in accordance with the U.S. International Traffic in Arms 
Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 
CFR Parts 730-774). Unauthorized use is strictly prohibited and may be 
unlawful. If you are not the intended recipient, or the person responsible for 
delivering to the intended recipient, you should not read, copy, disclose or 
otherwise use this message. If you have received this email in error, please 
delete it, and advise the sender immediately.

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Wed, May 1, 2013 at 5:01 PM, BRM bm_witn...@yahoo.com 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) steven.hutchin...@mbda-systems.com
 To: users@subversion.apache.org 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 Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn jcor...@gmail.com wrote:
 On Wed, May 1, 2013 at 5:01 PM, BRM bm_witn...@yahoo.com 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) steven.hutchin...@mbda-systems.com
 To: users@subversion.apache.org 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
philipm 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.
philipm 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 ...
philipm 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?
philipm If we change directory externals to be more like switch then
the directory externals become part of a single working copy.
@jcorvel ack
philipm 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.
philipm But it only fails because of a high level check on path, in
the past it was possible to switch a non-existant path.
philipm (In the past being during 1.7 development)
philipm If you switch a path that does not exist that looks very
much like an external (it is how file externals are implemented)
philipm One of the difficulties about externals is that the
specification is so relaxed that there are so many different cases.
philipm Almost any change is going to break some untested corner
cases, while perhaps fixing other corner cases.
@jcorvel philipm: so, realistically, this will probably

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Thu, May 2, 2013 at 11:00 AM, Johan Corveleyn jcor...@gmail.com wrote:
 On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn jcor...@gmail.com wrote:
 On Wed, May 1, 2013 at 5:01 PM, BRM bm_witn...@yahoo.com 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) steven.hutchin...@mbda-systems.com
 To: users@subversion.apache.org 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
 philipm 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.
 philipm 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 ...
 philipm 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?
 philipm If we change directory externals to be more like switch then
 the directory externals become part of a single working copy.
 @jcorvel ack
 philipm 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.
 philipm But it only fails because of a high level check on path, in
 the past it was possible to switch a non-existant path.
 philipm (In the past being during 1.7 development)
 philipm If you switch a path that does not exist that looks very
 much like an external (it is how file externals are implemented)
 philipm One of the difficulties about externals is that the
 specification is so relaxed that there are so many different cases.
 philipm Almost any change is going to break some untested corner

Re: SVN Externals 1.6 to 1.7 migration issue

[Johan Corveleyn]

On Thu, May 2, 2013 at 12:50 PM, Johan Corveleyn jcor...@gmail.com wrote:
 On Thu, May 2, 2013 at 11:00 AM, Johan Corveleyn jcor...@gmail.com wrote:
 On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn jcor...@gmail.com wrote:
 On Wed, May 1, 2013 at 5:01 PM, BRM bm_witn...@yahoo.com 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) steven.hutchin...@mbda-systems.com
 To: users@subversion.apache.org 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
 philipm 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.
 philipm 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 ...
 philipm 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?
 philipm If we change directory externals to be more like switch then
 the directory externals become part of a single working copy.
 @jcorvel ack
 philipm 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.
 philipm But it only fails because of a high level check on path, in
 the past it was possible to switch a non-existant path.
 philipm (In the past being during 1.7 development)
 philipm If you switch a path that does not exist that looks very
 much like an external (it is how file externals are implemented)
 philipm One of the difficulties about externals is that the
 specification is so relaxed that there are so many

Re: SVN Externals 1.6 to 1.7 migration issue

[BRM]

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

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.

I would suggest doing one of two things in a batch file that gets run after 
checkout (manually by the user, though TSVN may be able to give you some 
automatic client-side scripting):

1. Use mklink to create an NTFS file link after the checkout for the file you 
are trying to relocate.
2. Copy the file from the one directory to the other


Or

3. Copy the file as part of the SVN source tree to the other folder; but you'll 
also have to continuously merge the changes back and forth.

#1 is your best option if you want to not change anything at all, but requires 
that you are running a newer version of Windows than Windows XP. I think 
Microsoft first started providing the mklink utility with Vista; but it could 
be WIn7, and might also depend on which edition of each of those you have as 
well. (e.g. it might not be in the Home Premium version, but might be in Pro 
and Ultimate).

#2 is an okay backup if you can't do #1, but you'll need to treat the file as 
read-only as it will certainly be very much manual effort to maintain.

#3 is automatic, but you'd have to ensure the file matches what is at its 
origin - a bit of a manual effort, but easy to do.

$0.02

Ben





 From: Hutchinson, Steve (UK) steven.hutchin...@mbda-systems.com
To: users@subversion.apache.org 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 ?

Thanks for any help.

Regards
Steve H


This email and any attachments are confidential to the intended recipient and 
may also be privileged. If you are not the intended recipient please delete it 
from your system and notify the sender. You should not copy it or use it for 
any purpose nor disclose or distribute its contents to any other person. 

MBDA UK Limited, a company registered in England and Wales, registration 
number 3144919 whose registered office is at Six Hills Way, Stevenage, 
Hertfordshire, SG1 2DA, England.

Re: SVN externals (externals failed, already locked)

[Matthew J Fletcher]

On 13/03/12 18:07, Matthew J Fletcher wrote:

Hi,

I've been expermenting with SVN externals and found an issue which i
dont fully understand. My repository is as follows;


--

+Play (with and extern to URL https://swserver:8443/svn/Play/Shared
Sources Local Path Project 3)

- Project 3 (externed)
- shared.txt

- Project 2 (with an extern to URL
https://swserver:8443/svn/Play/Shared Sources Local Path Outstation
Files)
- - Outstation Files (externed)
- - - shared.txt
- - unieque.txt

- Project 1 (with an extern to URL
https://swserver:8443/svn/Play/Shared Sources Local Path osfiles)
- - osfiles (externed)
- - - shared.txt
- - unieque.txt

- Shared Sources
- shared.txt

-

All the externs work as expected and changes to files in Shared
Sources are reflected across the 3 projects. However when doing an
update/checkout i get the following error  'External failed Project 3'
is allready locked via .

I suspect that its because i am external'ing not into a seperate folder,
whereas in Project 1 and Project 2 the Shared Sources go in there
own folder. However the externals do work as expected.

I am using subversion 1.7.4 (same on server), via TortoiseSVN.



Hi,

Has anyone tried to do this before and encountered this problem ? or can 
offer some advice on this usage of externs.



regards

- Matthew J Fletcher

Re: SVN externals (externals failed, already locked)

[Philip Martin]

Matthew J Fletcher ami...@sky.com writes:

 I've been expermenting with SVN externals and found an issue which i
 dont fully understand. My repository is as follows;


 --

 +Play (with and extern to URL https://swserver:8443/svn/Play/Shared
 Sources Local Path Project 3)

 - Project 3 (externed)
 - shared.txt

 - Project 2 (with an extern to URL
 https://swserver:8443/svn/Play/Shared Sources Local Path Outstation
 Files)
 - - Outstation Files (externed)
 - - - shared.txt
 - - unieque.txt

 - Project 1 (with an extern to URL
 https://swserver:8443/svn/Play/Shared Sources Local Path osfiles)
 - - osfiles (externed)
 - - - shared.txt
 - - unieque.txt

 - Shared Sources
 - shared.txt

I'm having difficulty making sense of that description.

svnadmin create repo
svn co file://`pwd`/repo wc
svn mkdir wc/Play
svn mkdir wc/Play/SharedSources
echo foo  wc/Play/SharedSources/shared.txt
svn add wc/Play/SharedSources/shared.txt
svn mkdir wc/Play/Project1
svn mkdir wc/Play/Project2
svn ps svn:externals '^/Play/SharedSources Outstation' wc/Play/Project1
svn ps svn:externals '^/Play/SharedSources osfiles' wc/Play/Project2
svn ps svn:externals '^/Play/SharedSources Project3' wc/Play
# or maybe one svn:externals on Play
# ^/Play/SharedSources Project3
# ^/Play/SharedSources Project2/Outstation
# ^/Play/SharedSources Project1/osfiles
svn ci -mm wc
svn up wc

echo mod  wc/Play/SharedSources/shared.txt
svn ci -mm wc
svn up wc

 All the externs work as expected and changes to files in Shared
 Sources are reflected across the 3 projects. However when doing an
 update/checkout i get the following error  'External failed Project
 3' is allready locked via .

I don't understand that either.  How can the externs work as expected
if neither checkout nor update work?

 I suspect that its because i am external'ing not into a seperate
 folder, whereas in Project 1 and Project 2 the Shared Sources go
 in there own folder. However the externals do work as expected.

-- 
Philip

SVN externals (externals failed, already locked)

[Matthew J Fletcher]

Hi,

I've been expermenting with SVN externals and found an issue which i 
dont fully understand. My repository is as follows;



--

+Play (with and extern to URL https://swserver:8443/svn/Play/Shared 
Sources Local Path Project 3)


- Project 3 (externed)
- shared.txt

- Project 2 (with an extern to URL 
https://swserver:8443/svn/Play/Shared Sources Local Path Outstation 
Files)

- - Outstation Files (externed)
- - - shared.txt
- - unieque.txt

- Project 1 (with an extern to URL 
https://swserver:8443/svn/Play/Shared Sources Local Path osfiles)

- - osfiles (externed)
- - - shared.txt
- - unieque.txt

- Shared Sources
- shared.txt

-

All the externs work as expected and changes to files in Shared 
Sources are reflected across the 3 projects. However when doing an 
update/checkout i get the following error  'External failed Project 3' 
is allready locked via .


I suspect that its because i am external'ing not into a seperate folder, 
whereas in Project 1 and Project 2 the Shared Sources go in there 
own folder. However the externals do work as expected.


I am using subversion 1.7.4 (same on server), via TortoiseSVN.

regards

---
Matthew J Fletcher
amimjf(at)sky.com
www.amimjf.org
---

Re: SVN externals - using a GUID style instead of a path?

[Geoff Rowell]

On Jul 29, 2011, at 8:17 AM, Thomas Harold thomas-li...@nybeta.com wrote:

 http://subversion.apache.org/docs/release-notes/1.5.html#externals
 
 The relative URLs being allowed in svn:externals was a huge step forward.  
 But it still relies on the source path not ever changing.
 
 For example:
 
 /repos/zag foo/bar1
 
 Which is fine as long as zag never changes its name.
 
 What if there was some sort of a GUID value for each object, created the 
 first time that the object is added to the repository, that could then be 
 used as the source URL?
 
 /repos/GUID:4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 foo/bar1
 
 Which would hopefully track /repos/zag as it changes from /repos/zag to 
 /repos/zig to /repos/forgreatjustice.
 
 (I suspect this all ties in with the copy/rename issue, which is itself a 
 rather hairy topic.)
I wouldn't use/suggest this. It'd be difficult to determine where a GUID 
pointed, once created.

 Is this also a moot point if you use the pegged revision style of 
 svn:externals where you prefix the property value with -r ?  That even 
 if /repos/zag changes to /repos/zig it won't matter because you're 
 pegging to a revision before the name change occured?
Peg revision should be indicated by @, appended to the repos path. I'd 
prefer that syntax.

Re: svn externals

[Ryan Schmidt]

On Feb 14, 2011, at 02:06, Stephen Connolly wrote:

 On 14 Feb 2011 07:59, Ryan Schmidt wrote:
  
  On Feb 14, 2011, at 01:57, Stephen Connolly wrote:
  
  yeah, but you'd want at least an option for the client to override ;-)
  
  Why would one want that?
 
 because you might not want the git on the system path

I had assumed that there would be git libraries that Subversion would find 
during configuration and link with; no binary needed. If git does not provide 
libraries, then I had assumed Subversion would find the appropriate binary at 
configuration time.


 because you may not have permissions on windows to set the uri handler

I don't know what that means.

Re: svn externals

[Ryan Schmidt]

On Feb 14, 2011, at 01:57, Stephen Connolly wrote:

 yeah, but you'd want at least an option for the client to override ;-)

Why would one want that?

Re: svn externals

[Stephen Connolly]

because you might not want the git on the system path

because you may not have permissions on windows to set the uri handler

just two, there's more

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 14 Feb 2011 07:59, Ryan Schmidt subversion-20...@ryandesign.com
wrote:

 On Feb 14, 2011, at 01:57, Stephen Connolly wrote:

 yeah, but you'd want at least an option for the client to override ;-)

 Why would one want that?

Re: svn externals

[Ryan Schmidt]

On Feb 12, 2011, at 13:26, Stephen Connolly wrote:

 oh I like that.
 
 you could even allow the client config file to add custom uri schemes and the 
 path to the exec that handles them

Well, I wasn't thinking there would be any client-side configuration 
possibility. I merely meant that the Subversion client code would gain the 
ability to deal with certain foreign types of repositories.

Re: svn externals

[Stephen Connolly]

yeah, but you'd want at least an option for the client to override ;-)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 14 Feb 2011 07:12, Ryan Schmidt subversion-20...@ryandesign.com
wrote:

Re: svn externals

[Ryan Schmidt]

On Feb 12, 2011, at 00:25, Robert Bielik wrote:

 Ryan Schmidt skrev 2011-02-11 22:20:
 
 
 svn:externals is for accessing other (or the same) Subversion repositories 
 only.
 
 Yes, I know, but I had hopes :) Wouldn't it be cool with a svn:command 
 feature in which you'd be able to write a git pull command ? I.e.
 a generic property which executes written commands when you update ? ;)

I can see the appeal, but I can also see the great possibility for mischief. I 
don't like the idea of svn up being given the power to run any command on my 
system. What if someone commits a command that has a bug that causes data to be 
deleted on my system? What if a hacker gains access to the repository and 
commits an svn:command that, when run on my system, installs malware? It's 
the same reason why Subversion doesn't have client-side hooks. Even in the 
absence of such threats, it can take a lot of work to ensure what you write 
will work on any user's system. What if the user has a different version of the 
git command that behaves differently? What if the user is on Windows, or Unix, 
or Mac OS X -- do they all behave the same?

Don't get me wrong, I think it would be nice for Subversion to be able to pull 
in data in an externals-like manner from repositories that are not on 
Subversion. But if that is implemented, it should be in the Subversion client 
code -- perhaps as simply as allowing git or hg URLs in svn:externals -- and 
not as the ability for the repository to dictate arbitrary client-side 
executables to run.

Re: svn externals

[Stephen Connolly]

oh I like that.

you could even allow the client config file to add custom uri schemes and
the path to the exec that handles them

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Feb 2011 18:23, Ryan Schmidt subversion-20...@ryandesign.com
wrote:

svn externals

[Robert Bielik]

Hi all,

In my project I need to use a library that's only available using git, I wonder 
if there is some way to have svn:externals point to
a git repo (just doing a git pull) ?

TIA
/Rob

Re: svn externals

[Ryan Schmidt]

On Feb 11, 2011, at 08:28, Robert Bielik wrote:

 In my project I need to use a library that's only available using git, I 
 wonder if there is some way to have svn:externals point to
 a git repo (just doing a git pull) ?

svn:externals is for accessing other (or the same) Subversion repositories only.

Re: svn externals

[Robert Bielik]

Ryan Schmidt skrev 2011-02-11 22:20:


On Feb 11, 2011, at 08:28, Robert Bielik wrote:


In my project I need to use a library that's only available using git, I wonder 
if there is some way to have svn:externals point to
a git repo (just doing a git pull) ?


svn:externals is for accessing other (or the same) Subversion repositories only.


Yes, I know, but I had hopes :) Wouldn't it be cool with a svn:command feature in which 
you'd be able to write a git pull command ? I.e.
a generic property which executes written commands when you update ? ;)

Rgrds,
/Rob

SVN Externals query

[Hutchinson, Steve (UK)]

Hi group,
 
We have a product development structure that looks a bit like below :-
  
trunk
  Design
Module_A
file_bundle_x_source
Module_B 
file_bundle_y_source
 
  Verification - (externals)
   Simulation_1
   file_bundle_x
   Simulation_2
   file_bundle_x
   Simulation_3
   file_bundle_y
   file_bundle_x
 
Basically some source files are generated within the Design folder under
their respective modules. These source files need to be used within the
test environment. One option would have been to script the copying of
the various bundles to the appropriate simulation environment when they
change. There is scope for these bundles to become large so I thought
that using svn:externals on my verification folder seemed like a good
idea. The properties taking the form a bit like below.
 
-r777  https repo\trunk\Design\Module_A\file_bundle_x_source
Simulation_1/file_bundle_x
 
Generally speaking from a trunk perspective everything seemed ok.
then we branch to investigate a problem. Due to probably inexperience we
now have a branch that is not really self contained? Modifications on
the branch can directly impact the trunk, well on the externals bit
anyway.

One thought is to have the externals property be relative to the parent
folder, which I think would then prevent the branch direct link to the
trunk. We were very keen to ensure that any externals property refers to
a specific revision (or my tags not self contained) but I do not
appear to be able to link a specific revision and use relative paths?

Any other better ideas ?
  
Regards
Steve Hutchinson
 
FPGA Group Leader


This email and any attachments are confidential to the intended recipient and 
may also be privileged. If you are not the intended recipient please delete it 
from your system and notify the sender. You should not copy it or use it for 
any purpose nor disclose or distribute its contents to any other person. 

MBDA UK Limited, a company registered in England and Wales, registration number 
3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, 
SG1 2DA, England.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Svn externals question

[Stefan Sperling]

On Mon, Nov 08, 2010 at 10:24:03AM -, Hutchinson, Steve (UK) wrote:
 Do it the other way: Store your component configuration in a versioned
 file or even a database, and write a script to configure svn:externals
 properties based on that data. Maybe even add an automated check into
 the mix that makes sure the svn:externals in the repository's HEAD
 revision are in sync with your primary externals configuration source.
 
 I think unfortunately this is where you lose me :) I am not too sure why
 this is too different from the other way. In both situations I end up
 with a set of project folders with svn:externals on them. but the
 latter I say have one top level externals.lst and associated script
 file that is used to apply them. Probably a reflection of my knowledge
 level but not clear where the gain has come from ?

It depends on what you need to do with information about your modules.
It also depends on scale.

If svn propget -R output is sufficient and fast enough for you,
then you don't need a separate database of externals information.
In this case you simply haven't scaled up your usage of externals to
the point where propget -R becomes inhibiting.

E.g. if you need tool support to configure and compose your modules or
variants because you have a lot of them (say, various kinds of embedded
devices built from common parts), having the configuration data in svn
properties means that an application has to crawl the repository to
figure out which components are used where.

Also consider that you need might to crawl more than one revision
to find an answer you're looking for. A database can instantly tell you
things like this component is no longer used, and was last used in
devices A, B and C. if fed a proper query. If such information is
hidden in externals in past revisions, you're putting unnecessary load
on your Subversion server by trying to track down the right properties.

Stefan

RE: Svn externals question

[Hutchinson, Steve (UK)]

Stefan, 

Your point well understood now. Thanks for the clarification,
appreciated.

Steve H

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: 08 November 2010 17:01
To: Hutchinson, Steve (UK)
Cc: users@subversion.apache.org
Subject: Re: Svn externals question

  SPECIAL MBDA ALERT - SECURITY INCREASED FOR WEEK COMMENCING 
 08/11/10
PLEASE TAKE EXTRA CARE NOT TO CLICK ON HYPERLINKS WHERE YOU DO NOT KNOW
THE SENDER ANY SUSPICIOUS EMAIL, PLEASE FORWARD TO ftn.VIRUS CONTROL



   *** WARNING ***

This mail has originated outside your organization, either from an
external partner or the Global Internet. 
 Keep this in mind if you answer this message. 

On Mon, Nov 08, 2010 at 10:24:03AM -, Hutchinson, Steve (UK) wrote:
 Do it the other way: Store your component configuration in a 
 versioned file or even a database, and write a script to configure 
 svn:externals properties based on that data. Maybe even add an 
 automated check into the mix that makes sure the svn:externals in the

 repository's HEAD revision are in sync with your primary externals
configuration source.
 
 I think unfortunately this is where you lose me :) I am not too sure 
 why this is too different from the other way. In both situations I 
 end up with a set of project folders with svn:externals on them. 
 but the latter I say have one top level externals.lst and associated

 script file that is used to apply them. Probably a reflection of my 
 knowledge level but not clear where the gain has come from ?

It depends on what you need to do with information about your modules.
It also depends on scale.

If svn propget -R output is sufficient and fast enough for you, then you
don't need a separate database of externals information.
In this case you simply haven't scaled up your usage of externals to the
point where propget -R becomes inhibiting.

E.g. if you need tool support to configure and compose your modules or
variants because you have a lot of them (say, various kinds of embedded
devices built from common parts), having the configuration data in svn
properties means that an application has to crawl the repository to
figure out which components are used where.

Also consider that you need might to crawl more than one revision to
find an answer you're looking for. A database can instantly tell you
things like this component is no longer used, and was last used in
devices A, B and C. if fed a proper query. If such information is
hidden in externals in past revisions, you're putting unnecessary load
on your Subversion server by trying to track down the right properties.

Stefan



This email and any attachments are confidential to the intended recipient and 
may also be privileged. If you are not the intended recipient please delete it 
from your system and notify the sender. You should not copy it or use it for 
any purpose nor disclose or distribute its contents to any other person. 

MBDA UK Limited, a company registered in England and Wales, registration number 
3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, 
SG1 2DA, England.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Svn externals question

[Hutchinson, Steve (UK)]

Hi,
 
Currently we are attempting to use svn externals to help build various
projects from what I would call a few reuse repositories. We are
attempting to be structured as to what level of design hierarchy we
apply the properties but sometimes when we inherit a design people can
spend a bit of time trying to identify where externals have been used.
 
Is there a simple way of identifying in a structure folders that have
external properties, come to think of it maybe any form of property ?
 
Thanks for any help.
 
Regards
Steve Hutchinson
FPGA Group Leader
 


This email and any attachments are confidential to the intended recipient and 
may also be privileged. If you are not the intended recipient please delete it 
from your system and notify the sender. You should not copy it or use it for 
any purpose nor disclose or distribute its contents to any other person. 

MBDA UK Limited, a company registered in England and Wales, registration number 
3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, 
SG1 2DA, England.



__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Svn externals question

[Jack Repenning]

In a checked-out working copy, svn status marks directories loaded by virtue 
of svn:externals with an 'X'. 

Other props, and finding even that one from the repository, requires scripting 
a loop to use svn plist or similar, I believe. 

Sent from my iPhone

On Nov 5, 2010, at 9:50 AM, Hutchinson, Steve (UK) 
steven.hutchin...@mbda-systems.com wrote:

 Hi,
  
 Currently we are attempting to use svn externals to help build various 
 projects from what I would call a few reuse repositories. We are attempting 
 to be structured as to what level of design hierarchy we apply the 
 properties but sometimes when we inherit a design people can spend a bit of 
 time trying to identify where externals have been used.
  
 Is there a simple way of identifying in a structure folders that have 
 external properties, come to think of it maybe any form of property ?
  
 Thanks for any help.
  
 Regards
 Steve Hutchinson
 FPGA Group Leader
  
 
 
 This email and any attachments are confidential to the intended recipient and 
 may also be privileged. If you are not the intended recipient please delete 
 it from your system and notify the sender. You should not copy it or use it 
 for any purpose nor disclose or distribute its contents to any other person. 
 
 MBDA UK Limited, a company registered in England and Wales, registration 
 number 3144919 whose registered office is at Six Hills Way, Stevenage, 
 Hertfordshire, SG1 2DA, England.
 
 
 __
 This email has been scanned by the MessageLabs Email Security System.
 For more information please visit http://www.messagelabs.com/email 
 __

Re: Svn externals question

[Stefan Sperling]

On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote:
 Hi,
  
 Currently we are attempting to use svn externals to help build various
 projects from what I would call a few reuse repositories. We are
 attempting to be structured as to what level of design hierarchy we
 apply the properties but sometimes when we inherit a design people can
 spend a bit of time trying to identify where externals have been used.
  
 Is there a simple way of identifying in a structure folders that have
 external properties, come to think of it maybe any form of property ?

The designers of the externals feature envisioned maybe a handful
of external library dependencies that don't vary much over time.
These are automatically pulled into a working copy, much like an automated
svn checkout.

But the design doesn't account for what happens when people start using
svn:externals for variant management or large-scale component reuse.
If you're pulling together project components from externals in various
combinations, like lego blocks, or simply have many externals, don't use
the svn:externals properties as the primary source of your configuration data.

Do it the other way: Store your component configuration in a versioned
file or even a database, and write a script to configure svn:externals
properties based on that data. Maybe even add an automated check into
the mix that makes sure the svn:externals in the repository's HEAD
revision are in sync with your primary externals configuration source.

You can query a file or a database easily to find out which components
are used where. But svn properties haven't been designed for this use case.
You cannot query a Subversion repository like you can query a database.
Well, you could crawl the repository, but that's quite slow.

Hope this helps,
Stefan

Re: Svn externals question

[Jack Repenning]

If you do switch to the approach Stefan suggests (and I agree, it's probably 
more satisfactory) you also might want to use svn switch instead of the 
svn:externals. You'll still have the auditable, versioned definition of your 
canonical configuration (in the form of the script), but also there will be 
more freedom for variations, such as while preparing a new configuration. 

Sent from my iPhone

On Nov 5, 2010, at 10:09 AM, Stefan Sperling s...@elego.de wrote:

 On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote:
 Hi,
 
 Currently we are attempting to use svn externals to help build various
 projects from what I would call a few reuse repositories. We are
 attempting to be structured as to what level of design hierarchy we
 apply the properties but sometimes when we inherit a design people can
 spend a bit of time trying to identify where externals have been used.
 
 Is there a simple way of identifying in a structure folders that have
 external properties, come to think of it maybe any form of property ?
 
 The designers of the externals feature envisioned maybe a handful
 of external library dependencies that don't vary much over time.
 These are automatically pulled into a working copy, much like an automated
 svn checkout.
 
 But the design doesn't account for what happens when people start using
 svn:externals for variant management or large-scale component reuse.
 If you're pulling together project components from externals in various
 combinations, like lego blocks, or simply have many externals, don't use
 the svn:externals properties as the primary source of your configuration data.
 
 Do it the other way: Store your component configuration in a versioned
 file or even a database, and write a script to configure svn:externals
 properties based on that data. Maybe even add an automated check into
 the mix that makes sure the svn:externals in the repository's HEAD
 revision are in sync with your primary externals configuration source.
 
 You can query a file or a database easily to find out which components
 are used where. But svn properties haven't been designed for this use case.
 You cannot query a Subversion repository like you can query a database.
 Well, you could crawl the repository, but that's quite slow.
 
 Hope this helps,
 Stefan

Re: Svn externals question

[Stefan Sperling]

On Fri, Nov 05, 2010 at 11:03:58AM -0400, Jack Repenning wrote:
 If you do switch to the approach Stefan suggests (and I agree, it's
 probably more satisfactory) you also might want to use svn switch
 instead of the svn:externals. You'll still have the auditable,
 versioned definition of your canonical configuration (in the form of
 the script), but also there will be more freedom for variations, such
 as while preparing a new configuration. 

Right. But note that switched subtrees cannot come from a different repository.

Re: Svn externals question

[Johan Corveleyn]

On Fri, Nov 5, 2010 at 3:09 PM, Stefan Sperling s...@elego.de wrote:
 On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote:
 Hi,

 Currently we are attempting to use svn externals to help build various
 projects from what I would call a few reuse repositories. We are
 attempting to be structured as to what level of design hierarchy we
 apply the properties but sometimes when we inherit a design people can
 spend a bit of time trying to identify where externals have been used.

 Is there a simple way of identifying in a structure folders that have
 external properties, come to think of it maybe any form of property ?

 The designers of the externals feature envisioned maybe a handful
 of external library dependencies that don't vary much over time.
 These are automatically pulled into a working copy, much like an automated
 svn checkout.

 But the design doesn't account for what happens when people start using
 svn:externals for variant management or large-scale component reuse.
 If you're pulling together project components from externals in various
 combinations, like lego blocks, or simply have many externals, don't use
 the svn:externals properties as the primary source of your configuration data.

 Do it the other way: Store your component configuration in a versioned
 file or even a database, and write a script to configure svn:externals
 properties based on that data. Maybe even add an automated check into
 the mix that makes sure the svn:externals in the repository's HEAD
 revision are in sync with your primary externals configuration source.

 You can query a file or a database easily to find out which components
 are used where. But svn properties haven't been designed for this use case.
 You cannot query a Subversion repository like you can query a database.
 Well, you could crawl the repository, but that's quite slow.

 Hope this helps,
 Stefan


For finding the folders that have the svn:externals property, how about:
svn propget -R svn:externals TARGET

where TARGET can be a working copy path or a url. For a url it will
not be fast, but it works (for a working copy it works quite fast).

I do agree with Stefan though, that it's best to have another
canonical source for this kind of configuration data, especially if
it starts becoming more and more complex, and to derive the externals
configuration from that.

Cheers,
-- 
Johan

Re: Svn externals question

[David Weintraub]

On Fri, Nov 5, 2010 at 9:49 AM, Hutchinson, Steve (UK)
steven.hutchin...@mbda-systems.com wrote:
 Is there a simple way of identifying in a structure folders that have
 external properties, come to think of it maybe any form of property ?

Not 100% clear what you're looking for. You could be looking for one
of two things:

1). You have a project, and it has svn:externals set on certain
folders. You want to find those folders.

That's fairly easy to do with the svn propget. Go to the root of
your project and run:

$ svn propget -v -R svn:externals

That will show you all the directories where svn:externals are set and
directories are being pulled in.

2). You have a bunch of external projects, and want to know in what
other projects they're being used.

This is much more difficult since there's no way to see what projects
are using a particular directory as an external project. The only
thing I can think of is to run the svn propget on the entire
repository and parse the output.

-- 
David Weintraub
qazw...@gmail.com

Re: Svn externals question

[David Weintraub]

On Fri, Nov 5, 2010 at 10:09 AM, Stefan Sperling s...@elego.de wrote:
 The designers of the externals feature envisioned maybe a handful
 of external library dependencies that don't vary much over time.
 These are automatically pulled into a working copy, much like an automated
 svn checkout.

 But the design doesn't account for what happens when people start using
 svn:externals for variant management or large-scale component reuse.
 If you're pulling together project components from externals in various
 combinations, like lego blocks, or simply have many externals, don't use
 the svn:externals properties as the primary source of your configuration data.

The big problem with svn:externals is that they don't version very well.

Imagine I have a project called foo, and in the root directory, I
set an svn:external property to pull in the trunk of module bar that
contains certain routines I'm using:

$ svn propset svn:externals bar /externals/bar/trunk

When foo is ready for Release 1.0, I create a tag:

$ svn copy svn://subversion/foo/trunk svn://subversion/foo/tags/REL-1.0

Everything is fine and dandy, but we found a few bugs, so we're going
to create a Release 1.1 to fix those bugs. I create my 1.1 branch:

$ svn copy svn://subversion/foo/tags/REL-1.0
svn://subversion/foo/branches/1.1

But, there's a problem. I discover that what is tagged as REL-1.0
isn't the code I released. In fact, all the difference between what
has been tagged and what was released are in that bar subdirectory
that was created by my svn:externals property.

The problem is that the external directories themselves aren't tagged
or branched when I did my tag or branch. Instead, the svn:external
property itself was versioned, and if you have that pointing to just
the branch or the trunk without a version number, that external
directory can keep changing in the tag.

You can partially solve that problem by making sure your svn:external
property points to a specific tag and/or a specific version of the
external directory. But, then you have to start keeping the
svn:external tags up to date which can be a headache if you have a lot
of them.

When I first started using Subversion, I though svn:externals was a
great feature. But I quickly discovered what a mess they can create. I
now take the approach of thinking of my externals as releasable
components that are also versioned and released, and I put them into
a release repository where various projects can import a specific
revision of that component. This makes it much easier for developers
to track what particular version of that component they're using.

-- 
David Weintraub
qazw...@gmail.com

Re: Svn externals question

[Ryan Schmidt]

On Nov 5, 2010, at 11:54, David Weintraub wrote:

 The big problem with svn:externals is that they don't version very well.

 The problem is that the external directories themselves aren't tagged
 or branched when I did my tag or branch

If this is important to you, then you should use the svncopy.pl script to 
create your tags because this is exactly what it takes care of for you.

Some relative svn externals takes very long time

[Joakim Tjernlund]

Hi

We have a repo with lots of svn:externals that looks like this
 ^tags/x/y z
Each time one executes a svn up or svn status it takes a very long time
to complete. The reason is that for each such external a new svnserve if
started on the server.
The ^tags/x/y externals are relative to the repo so I wonder
if it is possible to follow these externals within the same
svnserve process instead?

 Jocke