Re: Code signing plugin

[Thorsten Schöning]

Guten Tag Herkes, Colin,
am Dienstag, 24. Juli 2012 um 18:08 schrieben Sie:

> Does anyone know if there is any plugins/tools or API for doing
> code signing that can be integrated with subversion.  I would like
> to automate the approval and code signing process as much as possible.

In my opinion this is best suited in a Continuous Integration
environment like Huson or Jenkins, where you can test successfully
builds of your software and afterwards sign automatically. It's just
some scripting if your signing process can be triggered using a shell.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Query on subversion

[Rupam Chowdhury]

Hi, I have downloaded Subversion 1.7.5 (.zip) and trying to install it after extracting the zipped file (as per the installation guide, section II D.  ie. Installing from a Zip or Installer File under Windows).  Here I am not able to find any .dll file or .exe file under any folder to install it. Could you  please let me know where can I get that installer file. Also please let me know whether Subversion can work with Weblogic server (OS: Windows 2000) or not. Regards,Rupam ChowdhuryTata Consultancy ServicesCell:- 09830818093Mailto: rupam.chowdh...@tcs.comWebsite: http://www.tcs.com=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Re: Query on subversion

[vishwajeet singh]

On Wed, Jul 25, 2012 at 1:26 PM, Rupam Chowdhury wrote:

> Hi,
>
> I have downloaded Subversion 1.7.5 (.zip) and trying to install it after
> extracting the zipped file (as per the installation guide, section II D.
> ie. Installing from a Zip or Installer File under Windows).
>
> Here I am not able to find any .dll file or .exe file under any folder to
> install it. Could you  please let me know where can I get that installer
> file.
>

Do you see a bin directory  ?? If not than probably you downloaded the
source.

You can look for binaries here
http://subversion.apache.org/packages.html#windows



> Also please let me know whether Subversion can work with Weblogic server
> (OS: Windows 2000) or not.
>

Windows yes, weblogic no, you would need to use Apache or svn server.


> Regards,
> Rupam Chowdhury
> Tata Consultancy Services
> Cell:- 09830818093
> Mailto: rupam.chowdh...@tcs.com
> Website: http://www.tcs.com
>
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>


-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

Re: unable to login to svn repo

[Philip Martin]

"Kapur, Rajneesh"  writes:

> Thanks for pointing it out. I cleaned everything and started fresh
> with new repo named repo4:

Do you mean the repository is a directory 'repo4' on disk?

> 1) svnserve.conf file
>
> [general]
> anon-access = none
> auth-access = write
> password-db = passwd
> authz-db = authz
> realm = repo4
> [sasl]
>
> 2) authz file
> [aliases]
> [groups]
> harry_and_sally = harry,sally
> [repository:/home/RKapur/repo4]
> @harry_and_sally = rw

That authz file provides no access to a repository called 'repo4'.

> 11090 2012-07-24T18:13:26.821156Z 192.168.4.64 harry home/RKapur/repo4 ERR 
> subversion/svnserve/serve.c 167 170001 Authorization failed

So you get this error.

-- 
Philip

Re: moved repository

[Nico Kadel-Garcia]

On Tue, Jul 24, 2012 at 2:48 PM, Talkov, Roger  wrote:
> We moved out repository to a new server.
> I was able to do svn log on files or directories but when I tried to do a
> commit, I get errors like the following:

How did you "move the repository"? Did you use svnsync, are you using
HTTPS access, did you migrate webserver configuration files? If you
use Apache and just copied the files over, did you set the file
ownership so the 'apache' user has write access to the database files?

Details, man, details!!!


>
> org.apache.subversion.javahl.ClientException: RA layer request failed
> svn: Commit failed (details follow):
> svn: Server sent unexpected return value (500 Internal Server Error) in
> response to POST request for '/svn/!svn/me'
>
> I get these erros from all clients: command line, Tortoise, & subclipse.
> I did an svn switch –relocate oldURL newURL, but this didn’t help
>
> Roger Talkov
> Senior Java Developer
> -
> UC4 Software, Inc.
> 14475 NE 24th St  Suite 210
> Bellevue, WA  98005
> USA
> phone: (425) 633-2568
>
> web: www.UC4.com
> mailto:roger.tal...@uc4.com
>
>
>
>
> This email (including any attachments) may contain information which is
> privileged, confidential, or protected. If you are not the intended
> recipient, note that any disclosure, copying, distribution, or use of the
> contents of this message and attached files is prohibited. If you have
> received this email in error, please notify the sender and delete this email
> and any attached files.
>

RE: unable to login to svn repo

[Kapur, Rajneesh]

Thanks Philip, Thorsten, and Ryan

Do you mean the repository is a directory 'repo4' on disk?
> Yes, my repository is named: repo4 - located at /home/RKapur with 
absolute path /home/RKapur/repo4

Here is the output of "ls -l" at /home/RKapur
drwxr-xr-x 7 rkapur hie_dev   4.0K Jul 25 10:55 repo4

If I "cd" into "repo4" and do "ls -l" then it shows this:
-rw-r--r-- 1 rkapur hie_dev  229 Jul 25 10:55 README.txt
drwxr-xr-x 2 rkapur hie_dev 4.0K Jul 25 10:55 locks
drwxr-xr-x 2 rkapur hie_dev 4.0K Jul 25 10:55 hooks
drwxr-xr-x 2 rkapur hie_dev 4.0K Jul 25 10:55 dav
-r--r--r-- 1 rkapur hie_dev2 Jul 25 10:55 format
drwxr-sr-x 5 rkapur hie_dev 4.0K Jul 25 10:55 db
drwxr-xr-x 2 rkapur hie_dev 4.0K Jul 25 10:57 conf

the permissions inside "conf" directory is:
-rw-r--r-- 1 rkapur hie_dev 383 Jul 25 10:56 svnserve.conf
-rw-r--r-- 1 rkapur hie_dev 305 Jul 25 10:56 passwd
-rw-r--r-- 1 rkapur hie_dev 894 Jul 25 10:57 authz


You are right - looks like tortoiseSVN or "svn" client can't find the 
repository. I just tried with tortoiseSVN and I see more logs in server log 
file:

-start Logs 
-
19269 2012-07-25T14:58:19.946784Z 172.20.33.153 - home/RKapur/repo4 open 2 
cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
SVN/1.7.5 -
19269 2012-07-25T14:58:19.959811Z 172.20.33.153 - home/RKapur/repo4 
get-latest-rev
19268 2012-07-25T14:58:19.959823Z 172.20.33.153 - home/RKapur/repo4 
get-latest-rev
19269 2012-07-25T14:58:19.970012Z 172.20.33.153 - home/RKapur/repo4 reparent /
19268 2012-07-25T14:58:19.970035Z 172.20.33.153 - home/RKapur/repo4 reparent /
19268 2012-07-25T14:58:20.003675Z 172.20.33.153 harry home/RKapur/repo4 ERR 
subversion/svnserve/serve.c 167 170001 Authorization failed
19269 2012-07-25T14:58:20.008894Z 172.20.33.153 harry home/RKapur/repo4 ERR 
subversion/svnserve/serve.c 167 170001 Authorization failed
19270 2012-07-25T14:58:20.015983Z 172.20.33.153 - home/RKapur/repo4 open 2 
cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
SVN/1.7.5 TortoiseSVN-1.7.7.22907
19271 2012-07-25T14:58:20.089746Z 172.20.33.153 - home/RKapur/repo4 open 2 
cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
SVN/1.7.5 TortoiseSVN-1.7.7.22907
19271 2012-07-25T14:58:20.107691Z 172.20.33.153 - home/RKapur/repo4 
get-latest-rev
19273 2012-07-25T14:58:20.180937Z 172.20.33.153 - home/RKapur/repo4 open 2 
cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
SVN/1.7.5 -
19272 2012-07-25T14:58:20.180989Z 172.20.33.153 - home/RKapur/repo4 open 2 
cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
SVN/1.7.5 TortoiseSVN-1.7.7.22907
19273 2012-07-25T14:58:20.198600Z 172.20.33.153 - home/RKapur/repo4 
get-latest-rev
19272 2012-07-25T14:58:20.198659Z 172.20.33.153 - home/RKapur/repo4 
get-latest-rev
19273 2012-07-25T14:58:20.215981Z 172.20.33.153 - home/RKapur/repo4 reparent /
19272 2012-07-25T14:58:20.216031Z 172.20.33.153 - home/RKapur/repo4 reparent /
19272 2012-07-25T14:58:20.274188Z 172.20.33.153 harry home/RKapur/repo4 ERR 
subversion/svnserve/serve.c 167 170001 Authorization failed
19273 2012-07-25T14:58:20.274690Z 172.20.33.153 harry home/RKapur/repo4 ERR 
subversion/svnserve/serve.c 167 170001 Authorization failed
19274 2012-07-25T14:58:20.348340Z 172.20.33.153 - home/RKapur/repo4 open 2 
cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
SVN/1.7.5 TortoiseSVN-1.7.7.22907
19274 2012-07-25T14:58:20.366374Z 172.20.33.153 - home/RKapur/repo4 
get-latest-rev
19274 2012-07-25T14:58:20.386632Z 172.20.33.153 - home/RKapur/repo4 reparent /
19274 2012-07-25T14:58:20.446603Z 172.20.33.153 harry home/RKapur/repo4 ERR 
subversion/svnserve/serve.c 167 170001 Authorization failed
19275 2012-07-25T14:58:20.499907Z 172.20.33.153 - - ERR 
subversion/svnserve/serve.c 2847 210005 No repository found in 
'svn://192.168.4.64/home/RKapur'
19276 2012-07-25T14:58:20.538166Z 172.20.33.153 - - ERR 
subversion/svnserve/serve.c 2847 210005 No repository found in 
'svn://192.168.4.64/home'
19277 2012-07-25T14:58:20.569107Z 172.20.33.153 - - ERR 
subversion/svnserve/serve.c 2847 210005 No repository found in 
'svn://192.168.4.64'
- END logs 
-

It looks like when I used "svnadmin create /home/RKapur/repo4" then the 
directory permissions were not set correctly. It might be because of the user 
"rkapur" that I am logged in as. Is this correct? Do I have to login as "root"? 
If so then I have to ask our system admins. as I don't have "root" access. I 
also checked in other machine where we have older linux ES release 4 (Nahant 
Update 9) -

In older machine svnadmin command creates directory as follows:
drwxrwxr-x   7 jboss jboss 4.0K Mar 22 11:09 svn_repo

and if I "cd" into svn_repo (our old repository) then I see:

Re: Subversion authentication via SASL GSSAPI and likewise open

[xumuku]

My current  /usr/lib/sasl2/svn.conf is:

pwcheck_method: saslauthd
mech_list: GSSAPI
saslauthd_path: /var/run/saslauthd/mux
log_level: 7

But I get the error:
Cannot negotiate authentication mechanism

1. Does *anyone* have Windows SVNServe authenticating to AD/Kerberos via 
SASL/GSSAPI?
2. Cannot negotiate authentication mechanism 

Re: unable to login to svn repo

[Philip Martin]

"Kapur, Rajneesh"  writes:

> Thanks Philip, Thorsten, and Ryan
>
> Do you mean the repository is a directory 'repo4' on disk?
> > Yes, my repository is named: repo4 - located at /home/RKapur with 
> absolute path /home/RKapur/repo4

> You are right - looks like tortoiseSVN or "svn" client can't find the 
> repository. I just tried with tortoiseSVN and I see more logs in server log 
> file:
>
> -start Logs 
> -
> 19269 2012-07-25T14:58:19.946784Z 172.20.33.153 - home/RKapur/repo4 open 2 
> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / 
> SVN/1.7.5 -
> 19269 2012-07-25T14:58:19.959811Z 172.20.33.153 - home/RKapur/repo4 
> get-latest-rev
> 19268 2012-07-25T14:58:19.959823Z 172.20.33.153 - home/RKapur/repo4 
> get-latest-rev
> 19269 2012-07-25T14:58:19.970012Z 172.20.33.153 - home/RKapur/repo4 reparent /
> 19268 2012-07-25T14:58:19.970035Z 172.20.33.153 - home/RKapur/repo4 reparent /
> 19268 2012-07-25T14:58:20.003675Z 172.20.33.153 harry home/RKapur/repo4 ERR 
> subversion/svnserve/serve.c 167 170001 Authorization failed

The repository has been found.  As I said in my previous mail your authz
file:

> 2) authz file
> [aliases]
> [groups]
> harry_and_sally = harry,sally
> [repository:/home/RKapur/repo4]
> @harry_and_sally = rw

only provides access to a repository called 'repository', it provides no
access to a repository called 'repo4'.

> It looks like when I used "svnadmin create /home/RKapur/repo4" then the 
> directory permissions were not set correctly. It might be because of the user 
> "rkapur" that I am logged in as. Is this correct? Do I have to login as 
> "root"? If so then I have to ask our system admins. as I don't have "root" 
> access. I also checked in other machine where we have older linux ES release 
> 4 (Nahant Update 9) -

You need to fix your authz file.  Your layout is very confusing.  You
have a repository on disk at the path /home/RKapur/repo4 and you are
providing authz rules for the path /home/RKapur/repo4 inside the
repository.  It's not impossible for the path inside the repository to
be the same as the path to the repository but it is unconventional.

-- 
Philip

svn log -g doesn't return merge info when operating against repository root

[Justin Johnson]

Hello.

The command "svn log -vg" is not returning merge info when I execute
the command while sitting in a working copy of the root level of a
repository or when I pass in the URL to the root level of root level
on the command line.  A simple test case can be seen below.

I see there is already an issue related to faulty merge history logic
(3235), but it isn't apparent that it is related to what I'm seeing.
Is this a known bug?

Justin

$ svn --version
svn, version 1.7.5 (r1336830)
   compiled Jul 11 2012, 13:58:27

Copyright (C) 2012 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme



echo "## Create repo ##"
svnadmin create repo

echo "## Add initial project ##"
svn co file://`pwd`/repo wc
cd wc
mkdir -p p/trunk p/branches
echo hi > p/trunk/file.txt
svn add p
svn ci -m "initial import"

echo "## Copy trunk to A and make changes ##"
svn cp p/trunk p/branches/A
svn ci -m "Create branch A"
echo hello >> p/branches/A/file.txt
svn ci -m "Changes on A"
svn up

echo "## Merge A to trunk ##"
cd p/trunk
svn merge "^/p/branches/A"
svn ci -m "Commit merge results"
svn up

echo "## Log from WC - trunk ##"
svn log -vg
cd ../..

echo "## Log from WC - repo root ##"
svn log -vg
cd ..

echo "## Log from URL - repo root ##"
svn log -vg file://`pwd`/repo

File external that worked fine in 1.6.x not working in 1.7.5

[Benjamin Fritz]

I have two repositories and I am using svn:externals to place a
directory and a few files from one repository into a working copy of
the other.

I have the following two svn:externals definitions on a directory in
my working copy for the repo-A repository:

^/../repo-B/tools/coverity/scripts scripts
^/../repo-B/tools/coverity/README.txt scripts/README.txt

Note that this will create a "scripts" directory from repo-B in
repo-A's working copy, and then place a single file from repo-B into
the directory from repo-B. This worked fine in 1.6.17, but on upgrade
to 1.7.5, I get the following message when I do "svn update":

Fetching external item into 'scripts\README.txt':
svn: warning: W27: Unsupported external: url of file external
'http://server/repo-B/tools/coverity/README.txt' is not in repository
'http://server/repo-A'

and then:

At revision 885.
svn: E205011: Failure occurred processing one or more externals definitions

I get the same results on Windows XP 64-bit as I do on a Solaris 9 system.

I searched the bug tracker for "externals" (155 issues found) but none
of the results seemed relevant. The documentation (
http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html ) says
that "A file external's URL must always be in the same repository as
the URL that the file external will be inserted into," but even though
the file is from a different repository in this case, it is being
PLACED INTO a directory from the same repository, so I expect it to
work (especially since it worked in 1.6.17).

A Google search for the W27 message turns up only a collection of
hits for commits to the SVN project. I have not spent a lot of time
deciphering the code changes from these commits, but at a glance (and
from the commit message) it appears as if a check was added
specifically to prevent using externals from different repositories.
I'm not sure whether it was intentional that it removed the use case
of grabbing a file from a different repository and placing it into a
directory from that same repository.

Whether or not this is going to be fixed, is there a workaround that
would allow me to get the README.txt file into repo-A from repo-B
without getting the entire directory containing it? Or should I just
give up and put README.txt into repo-A directly (probably in a
location that multiple projects in the repository can access via
svn:externals)?

Please copy me on any response; I'm not currently planning to
subscribe to the mailing list.

-- 
Ben Fritz

RE: moved repository

[Marriott, Arthur]

Actually, since the incumbent platform was already doing nightly backups using 
"svnadmin dump", we created fresh repositories on the new machine and 
incorporated the data using "svnadmin load".  Admittedly there may have been a 
problem there--on several of the larger repositories, it was necessary to use 
the "--bypass-prop-validation" argument.  However, on our first "trial run" 
with this several months ago, the result seemed to work fine.

-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: Wednesday, July 25, 2012 5:44 AM
To: Talkov, Roger
Cc: users@subversion.apache.org; Marriott, Arthur
Subject: Re: moved repository

On Tue, Jul 24, 2012 at 2:48 PM, Talkov, Roger  wrote:
> We moved out repository to a new server.
> I was able to do svn log on files or directories but when I tried to 
> do a commit, I get errors like the following:

How did you "move the repository"? Did you use svnsync, are you using HTTPS 
access, did you migrate webserver configuration files? If you use Apache and 
just copied the files over, did you set the file ownership so the 'apache' user 
has write access to the database files?

Details, man, details!!!


>
> org.apache.subversion.javahl.ClientException: RA layer request failed
> svn: Commit failed (details follow):
> svn: Server sent unexpected return value (500 Internal Server Error) 
> in response to POST request for '/svn/!svn/me'
>
> I get these erros from all clients: command line, Tortoise, & subclipse.
> I did an svn switch -relocate oldURL newURL, but this didn't help
>
> Roger Talkov
> Senior Java Developer
> -
> UC4 Software, Inc.
> 14475 NE 24th St  Suite 210
> Bellevue, WA  98005
> USA
> phone: (425) 633-2568
>
> web: www.UC4.com
> mailto:roger.tal...@uc4.com
>
>
>
>
> This email (including any attachments) may contain information which 
> is privileged, confidential, or protected. If you are not the intended 
> recipient, note that any disclosure, copying, distribution, or use of 
> the contents of this message and attached files is prohibited. If you 
> have received this email in error, please notify the sender and delete 
> this email and any attached files.
>

Re: moved repository

[Thorsten Schöning]

Guten Tag Marriott, Arthur,
am Mittwoch, 25. Juli 2012 um 18:30 schrieben Sie:

> Admittedly there may have been a problem there--on several of the
> larger repositories, it was necessary to use the
> "--bypass-prop-validation" argument.

Which errors did you get? In my cases, I recently dumped/loaded to
upgrade the repos from 1.4.x to 1.7.x, I got errors with inconsistent
new line on properties, but everything seems to work fine, but I'm
running svnserve. If you really want to make sure, you can svnsync,
some kinds of property errors get fixed, especially newline problems.

> However, on our first "trial
> run" with this several months ago, the result seemed to work fine.

What about the server logs? I don't think that
--bypass-prop-validation really is your problem. You can test with a
local client on the server committing using a file:/// Url to one of
your repos. If this works, your web server configuration is the
problem.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: File external that worked fine in 1.6.x not working in 1.7.5

[Johan Corveleyn]

On Wed, Jul 25, 2012 at 6:23 PM, Benjamin Fritz  wrote:
> I have two repositories and I am using svn:externals to place a
> directory and a few files from one repository into a working copy of
> the other.
>
> I have the following two svn:externals definitions on a directory in
> my working copy for the repo-A repository:
>
> ^/../repo-B/tools/coverity/scripts scripts
> ^/../repo-B/tools/coverity/README.txt scripts/README.txt

Wow, so you're ascending beyond the repository root, to refer to
something from another repository (on the same server). I didn't know
that worked. I'm not sure if that's a supported use case ...

> Note that this will create a "scripts" directory from repo-B in
> repo-A's working copy, and then place a single file from repo-B into
> the directory from repo-B. This worked fine in 1.6.17, but on upgrade
> to 1.7.5, I get the following message when I do "svn update":
>
> Fetching external item into 'scripts\README.txt':
> svn: warning: W27: Unsupported external: url of file external
> 'http://server/repo-B/tools/coverity/README.txt' is not in repository
> 'http://server/repo-A'
>
> and then:
>
> At revision 885.
> svn: E205011: Failure occurred processing one or more externals definitions
>
> I get the same results on Windows XP 64-bit as I do on a Solaris 9 system.
>
> I searched the bug tracker for "externals" (155 issues found) but none
> of the results seemed relevant. The documentation (
> http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html ) says
> that "A file external's URL must always be in the same repository as
> the URL that the file external will be inserted into," but even though
> the file is from a different repository in this case, it is being
> PLACED INTO a directory from the same repository, so I expect it to
> work (especially since it worked in 1.6.17).

No, what it means is that a file external must come from the same
repository, not from a different one. That's because file externals
are implemented internally like a "switch", and "svn switch"-ing
(without --relocate) also only works if you're switching to some other
path inside the same repository. So I think this was never intended to
work, and I'm surprised that it worked for you in 1.6.17.

Maybe the 1.7 (or 1.7-upgrade) code tightened the checks a bit, by
normalizing the url's in those external definitions (so it saw that
those url's are really from a different repository).

Regarding the fact that this worked in 1.6.17: as a test, if you
replace those "^/../repo-B" url's, in the externals definition, with
absolute url's including scheme etc, does that still work?

> A Google search for the W27 message turns up only a collection of
> hits for commits to the SVN project. I have not spent a lot of time
> deciphering the code changes from these commits, but at a glance (and
> from the commit message) it appears as if a check was added
> specifically to prevent using externals from different repositories.
> I'm not sure whether it was intentional that it removed the use case
> of grabbing a file from a different repository and placing it into a
> directory from that same repository.
>
> Whether or not this is going to be fixed, is there a workaround that
> would allow me to get the README.txt file into repo-A from repo-B
> without getting the entire directory containing it? Or should I just
> give up and put README.txt into repo-A directly (probably in a
> location that multiple projects in the repository can access via
> svn:externals)?

Sorry, no concrete suggestions here ...

-- 
Johan

Re: File external that worked fine in 1.6.x not working in 1.7.5

[Benjamin Fritz]

On Wed, Jul 25, 2012 at 5:07 PM, Johan Corveleyn  wrote:
> On Wed, Jul 25, 2012 at 6:23 PM, Benjamin Fritz  
> wrote:
>> I have two repositories and I am using svn:externals to place a
>> directory and a few files from one repository into a working copy of
>> the other.
>>
>> I have the following two svn:externals definitions on a directory in
>> my working copy for the repo-A repository:
>>
>> ^/../repo-B/tools/coverity/scripts scripts
>> ^/../repo-B/tools/coverity/README.txt scripts/README.txt
>
> Wow, so you're ascending beyond the repository root, to refer to
> something from another repository (on the same server). I didn't know
> that worked. I'm not sure if that's a supported use case ...
>

Yup, it works. I'm not sure where I saw this trick, I thought it was
from http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
but I just checked and it's not mentioned there. So maybe I just tried
it and saw that it worked. It's nice where I work because I'm not
certain the repository will stay on the same server but I am fairly
certain the two repositories will move together if they do move at
some point.

>> Note that this will create a "scripts" directory from repo-B in
>> repo-A's working copy, and then place a single file from repo-B into
>> the directory from repo-B. This worked fine in 1.6.17, but on upgrade
>> to 1.7.5, I get the following message when I do "svn update":
>>
>> Fetching external item into 'scripts\README.txt':
>> svn: warning: W27: Unsupported external: url of file external
>> 'http://server/repo-B/tools/coverity/README.txt' is not in repository
>> 'http://server/repo-A'
>>
>> and then:
>>
>> At revision 885.
>> svn: E205011: Failure occurred processing one or more externals definitions
>>
>> I get the same results on Windows XP 64-bit as I do on a Solaris 9 system.
>>
>> I searched the bug tracker for "externals" (155 issues found) but none
>> of the results seemed relevant. The documentation (
>> http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html ) says
>> that "A file external's URL must always be in the same repository as
>> the URL that the file external will be inserted into," but even though
>> the file is from a different repository in this case, it is being
>> PLACED INTO a directory from the same repository, so I expect it to
>> work (especially since it worked in 1.6.17).
>
> No, what it means is that a file external must come from the same
> repository, not from a different one. That's because file externals
> are implemented internally like a "switch", and "svn switch"-ing
> (without --relocate) also only works if you're switching to some other
> path inside the same repository. So I think this was never intended to
> work, and I'm surprised that it worked for you in 1.6.17.
>

That's interesting that it works like a switch underneath. But it IS
very possible to pull in *directory* externals from other
repositories, which makes me wonder about whether this is relevant.
The explanation works for file externals but doesn't explain why
directory externals from other repositories work.

> Maybe the 1.7 (or 1.7-upgrade) code tightened the checks a bit, by
> normalizing the url's in those external definitions (so it saw that
> those url's are really from a different repository).
>
> Regarding the fact that this worked in 1.6.17: as a test, if you
> replace those "^/../repo-B" url's, in the externals definition, with
> absolute url's including scheme etc, does that still work?
>

Yeah, absolute paths work in 1.6.17, but not in 1.7.5. See the
following transcript from a 1.6.17 working copy. I've removed output
from directories not related to this discussion:

scarecrow_SunOS_btfritz> svn --version
svn, version 1.6.17 (r1128011)
   compiled Oct 12 2011, 12:29:56

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

[snip]

scarecrow_SunOS_btfritz> svn propget svn:externals
# latest version of scripts and user models #
http://asvn/ifis-sw/tools/coverity/user_models user_models
http://asvn/ifis-sw/tools/coverity/scripts scripts
# also pull in the readme file
http://asvn/ifis-sw/tools/coverity/README.txt scripts/README.txt


scarecrow_SunOS_btfritz> svn update

Fetching external item into 'user_models'
External at revision 8699.


Fetching external item into 'scripts'
Ascripts/compiler_setup_FSA-5000.csh
Ascripts/compiler_setup.csh
Ascripts/cov5run.csh
Updated external to revision 8699.


Fetching external item into 'scripts/README.txt'
Escripts/README.txt
Updated external to revision 8699.

[updated path here to point to the new Subversion client]

scarecrow_SunOS_btfritz> svn --version
svn, version 1.7.5 (r1336830)
   compiled Jun 14 2012, 11:00:46

Copyright (C) 2012 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subv

Re: File external that worked fine in 1.6.x not working in 1.7.5

[Ryan Schmidt]

On Jul 25, 2012, at 17:50, Benjamin Fritz wrote:

> That's interesting that it works like a switch underneath. But it IS
> very possible to pull in *directory* externals from other
> repositories

Absolutely.

> which makes me wonder about whether this is relevant.

It's my understanding that file externals (which are a relatively new feature 
for Subversion) are implemented very very differently under the hood from 
directory externals (which have been around for a long long time) so it's not 
surprising they would have very different restrictions and behaviors.

> The explanation works for file externals but doesn't explain why
> directory externals from other repositories work.

Directory externals are implemented as additional "svn checkout"s (or updates) 
following the primary checkout (or update).