Re: Cannot checkout or clean up using 1.9 dev build
On Apr 28, 2015 8:02 AM, Ivan Zhakov i...@visualsvn.com wrote: I've fixed at least one problem in svn_stream__install*() on Windows with long path names in r1676526. But I was getting different error message on Windows 8.1. Benjamin, what operating system do you use? Windows 7
Cannot checkout or clean up using 1.9 dev build
I recently tried the nightly build from TortoiseSVN, with the following version information for the supplied command-line tools: svn, version 1.9.0-dev (under development) compiled Apr 27 2015, 03:09:52 on x86-microsoft-windows Copyright (C) 2015 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_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. - using serf 1.3.8 - handles 'http' scheme - handles 'https' scheme The following authentication credential caches are available: * Wincrypt cache in C:\Users\(my username)\AppData\Roaming\Subversion I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. I get the same error message when I try svn cleanup in this partial working copy. In case it's not clear, I get this error when running the command-line tools (in addition to the TortoiseSVN GUI), so I know it's not something introduced by the TortoiseSVN folks. Is there more detail I can gather to help resolve this, or should I just sit and wait and hope it gets fixed before 1.9 gets released?
Re: Cannot checkout or clean up using 1.9 dev build
On Mon, Apr 27, 2015 at 11:06 AM, Benjamin Fritz fritzophre...@gmail.com wrote: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. I get the same error message when I try svn cleanup in this partial working copy. I should mention, I do NOT get this error using the latest of the 1.7 or 1.8 releases distributed with TortoiseSVN.
Re: Cannot checkout or clean up using 1.9 dev build
Apparently I'm not subscribed to get list emails; please CC me on future responses. I had to get this message from the archive :-) Branko Čibej wrote: On 27.04.2015 18:06, Benjamin Fritz wrote: I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters It probably does matter ... FWIW, I believe you did change the length of the file name, the workqueue record says 234 chars but the name in the record is 240; still, that shouldn't be an issue. Oops. You're right. My actual directory has only 3 characters where I replaced with Prog in the path string. Still, those 6 fewer characters are probably irrelevant. ), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. The full path of the file would be 281 characters long, which is more than Windows' limit of 260. But Subversion goes to a lot of trouble to avoid the path limit ... I wonder what's going on here. I get the same error message when I try svn cleanup in this partial working copy. In case it's not clear, I get this error when running the command-line tools (in addition to the TortoiseSVN GUI), so I know it's not something introduced by the TortoiseSVN folks. Is there more detail I can gather to help resolve this, or should I just sit and wait and hope it gets fixed before 1.9 gets released? It would really help if you could get a debug-enabled build of the command-line tools and try with that, because it'll show the actual location where the error is generated. That'll make the problem a bit easier to track down. By the way, I assume that this all works with 1.8? Yes, checking out to a similar path using SVN 1.7 or 1.8 (with 1.8 or 1.7 substituted in the working copy path) succeeds without this error and gives me a full working copy (minus some badly defined externals left over from 1.6). Do I need to compile my own SVN to get a debug-enabled build? I downloaded the source code archive for 1.9 beta, but did not try compiling yet, due to the large number of dependencies listed in the INSTALL file. But it looks like there should be a dependencies zip file available, so maybe I'll try that later. Assuming I get a debug-enabled build, what would I need to do to get the information needed?
Directory with tree conflict lies about merge result
I accidentally created a host directory both on a feature branch, and on trunk. On trunk, this directory contains a lib subdirectory containing a project to build a Windows version of the library I'm developing. On the feature branch, this directory instead contains a test directory containing a unit test of the feature. I'm trying to merge TO my feature branch, the trunk revision that added the Windows project of the library, so that the final result is my feature branch has a host directory with two subdirectories: test and lib. The result of a merge command *looks* like this is happening: C:\Project_Files\FEATURE_WCsvn merge -c 6891 http://example.com/SVN/lib/trunk --- Merging r6891 into '.': U externals Alib\win32 Alib\win32\lib.lib Alib\win32\lib.d.lib C host A host\lib\lib.sln A host\lib\proj\lib.vcxproj A host\lib\proj\lib.vcxproj.filters A host\lib\proj\lib.vcxproj.user A host\lib\proj A host\lib --- Recording mergeinfo for merge of r6891 into '.': U . Conflict discovered when trying to add 'host'. An object of the same name already exists. Select: (mf) my version, (tf) their version, (p) postpone, (q) quit resolution, (h) help: No matter what answer I give to the question (mf, tf, p, or q) when I check the host directory, no lib directory was created and neither it nor any of the added files under lib actually got added to my working copy. Why does SVN report adding those files as part of the merge, if the files were not actually added? How can I get SVN to actually add these files? Do I need to manually svn copy http://example.com/SVN/lib/trunk/host/lib into my working copy?
Re: Directory with tree conflict lies about merge result
On Wed, Aug 6, 2014 at 12:14 PM, Andreas Stieger andreas.stie...@gmx.de wrote: Hello, I recommend the following: In a clean working copy of the feature branch... svn mv host host_branch Then perform the merge, now without tree conflict. svn mv host_branch/test host/ svn rm host_branch Thanks! That got me around my immediate problem. But why does svn merge output misleading status, saying that it added files and folders that never actually get added to the working copy?
Re: Directory with tree conflict lies about merge result
On Wed, Aug 6, 2014 at 1:00 PM, Stefan Sperling s...@elego.de wrote: The server keeps sending adds for the paths. It has no idea the client cannot use them. Note how the As you're asking about appear in the tree-conflict column, not in the first column as normal adds do. They allow you to see what the server wants to add beneath its version of 'host'. I get it now! Thanks for the clarification.
How to see all history of a deleted file without knowing the exact last revision?
Actually, I was looking to answer this question on stackoverflow: http://stackoverflow.com/questions/24766535/how-to-tell-what-revision-a-folder-was-deleted-in The person was asking how to find the revision a folder was deleted in, and they knew some really old revision where the folder was definitely present (example: revision 2000 out of 1 had the folder). I thought this would be a great use for peg revisions! But this throws an error: svn log -r 1:HEAD http://example.com/svn/path/that/got/deleted@2000 This stops the log history at revision 2000, which makes it useless for finding changes (like a deletion) *after* the known revision: svn log http://example.com/svn/path/that/got/deleted@2000 In the general case I might be interested in changes to a file that happened between when I know it was there and when it eventually got deleted (for example, maybe somebody not very good at SVN renamed a file without using SVN on some branch, removed the old filename, and then merged back while we continued making changes on trunk). Is it possible to find the changes from a known revision to the deletion point, without knowing the exact revision where the file got deleted?
File externals into another external
I had a problem at work, where somebody created a tag for a library, and then deleted a bunch of files I needed from that tag. When I updated my svn:externals definition in my application to pull in the new library version, those files went away. I tried to fix it in my application, by creating file externals for those files, pointing to a previous version, but placed into the same location they would have been had the person not deleted them. I know it is not possible to create a file external from a different repository. But I expected this to work, because it is from the same repository, and the directory already exists. Is this limitation intentional, explained by this statement from http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html ? While directory externals can place the external directory at any depth, and any missing intermediate directories will be created, file externals must be placed into a working copy that is already checked out.
Reverse blame?
I wanted to find the revision where a certain line got removed from a file. Taking a hint from svn diff and svn merge, I tried doing an svn blame with the revision range backwards. I just get an error: svn: E195002: Start revision must precede end revision I see this was discussed before: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065viewType=browseAlldsMessageId=105258 however, I don't see any official comment on it. I did try the python script mentioned which solved my immediate problem, but I guess I'd rather it be built-in. Can this use-case be added to blame or should I just count on always using an external tool? Or maybe there is a different built-in tool I could use for my purpose?
Is it possible to see a diff of a replaced file?
I'm referring to files with an 'R' status in 'svn log'. I want to see the changes between the new file, and the file that it replaced. I can use 'svn cat' to get the old file and then compare it to the new one, but I am hoping there is a way to have SVN run the diff for me in one step like it can for comparing two revisions of the same file (actually I use TortoiseSVN most of the time, but I'd be willing to drop to the command line for this task if needed). We have a directory that collects files from various projects in the repository for building release loadsets for an embedded target, and I've been using 'svn copy' to replace those files in order to see the pedigree of the file more easily, but since I did it this way, I didn't notice when I removed an update somebody made directly to a file in that location instead of making it in the project folder it belonged in.
Managing needs-lock files on multiple branches
Where I work, we branch for every bugfix, to allow a clean trunk at all times. Some files we work with are not easily merged, so we have svn:needs-lock set on them. Locking one of these files is supposed to indicate to the rest of the team not to touch it until you're done (or at least, ask first). But since the lock is on a branch, somebody else on a different branch, or even merging back to trunk, will have no way to know you are editing the file. I wanted to solve this using a pre-lock hook on the server, which would automatically try to lock the trunk version of an artifact when somebody locks on a branch. But, since locking requires a username and password, and hook scripts do not have access to that information, the best I could do is deny the lock if the trunk is not locked, and also if the existing trunk lock does not contain the branch name in the lock comment. I might be able to get a special user added, with a password that never expires, which the hook script could use with a hard-coded password to create the trunk lock. Is there a nicer way to create a trunk lock from the hook script? I don't know if the powers that be will approve of a special user for this purpose. Or perhaps an alternate solution to allow branch locks to actually be useful? I sold the team on a pre-lock hook in the first place with the idea that it could be fully automated, I'll need to sell them again if there is an extra manual step in there. Most of us use the TortoiseSVN GUI rather than command-line tools, so a simple wrapper script to invoke instead of using svn lock directly isn't a very nice option either.
Re: Managing needs-lock files on multiple branches
On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard markp...@gmail.com wrote: The hook is running on the server, so it could access the repository via file:// URL to do the lock. This does not require authentication. I DID NOT KNOW THIS! Is that documented somewhere? This should allow my pre-lock hook to work exactly as I wanted! What other svn commands that also behave this way? In SVN 1.8, the svnadmin command can be used as well: $ svnadmin help lock lock: usage: svnadmin lock REPOS_PATH PATH USERNAME COMMENT-FILE [TOKEN] I don't know what version of SVN is running on our server, but I know it is definitely less than 1.8, sadly. Use --bypass-hooks to avoid triggering the pre-lock and post-lock hook scripts. Valid options: --bypass-hooks : bypass the repository hook system I've made sure the pre-lock hook will succeed under normal circumstances (i.e. file is not locked, or --force was passed) if the file is NOT on a branch. So a recursive call to lock a file NOT on a branch shouldn't be a problem, right?
Re: Managing needs-lock files on multiple branches
On Thu, Jun 13, 2013 at 3:09 PM, Mark Phippard markp...@gmail.com wrote: On Thu, Jun 13, 2013 at 4:05 PM, Benjamin Fritz fritzophre...@gmail.com wrote: On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard markp...@gmail.com wrote: The hook is running on the server, so it could access the repository via file:// URL to do the lock. This does not require authentication. I DID NOT KNOW THIS! Is that documented somewhere? This should allow my pre-lock hook to work exactly as I wanted! What other svn commands that also behave this way? Which other commands support file:// ? All of them do. file:// is one of the supported RA mechanisms for Subversion - ra_local. See: http://svnbook.red-bean.com/en/1.7/svn.intro.whatis.html#svn.intro.architecture I knew about file:// access, I just assumed username and password would still be required when using it. But looking at the documentation I see a few notes (in sections about tunneling) that the only control on access is the filesystem permissions on the DB files themselves. Do I understand correctly, that if a user can access the files within the actual SVN repository filesystem location, then that user can use any svn commands without a password? In SVN 1.8, the svnadmin command can be used as well: I don't know what version of SVN is running on our server, but I know it is definitely less than 1.8, sadly. SVN 1.8 has not been released yet. Was just pointing out that this is coming. Yes, I know. I meant I know for a fact we're not using an unreleased version, and highly suspect it will take a long time (if ever) for us to upgrade. I've made sure the pre-lock hook will succeed under normal circumstances (i.e. file is not locked, or --force was passed) if the file is NOT on a branch. So a recursive call to lock a file NOT on a branch shouldn't be a problem, right? Not sure I understand the question. You probably just have to test the scenario and see what output the command gives you. I saw notes on a few forums during my searching for answers to this, about avoiding using svn commands that would recursively trigger the same hook script. I assume that is just because I need to be careful not to cause unbounded recursion. I though I'd ask, however, to make sure SVN won't have problems because it is already processing a pre-lock hook when it gets another lock request. Note that you are going to need to a means to remove these locks. You ought to be able to do unlock with hook scripts, just test it well and make sure you accounted for everything. I think for now we'll just --force the trunk lock/unlock when needed. I can't think of a good way to unlock via hook script, because unlocking the branched file only means the changes for that particular commit on the branch are done, not that the file is OK to edit now on a different branch or trunk (since it hasn't been merged back to trunk yet). Thanks for all your help!
Re: File external that worked fine in 1.6.x not working in 1.7.5
On Thu, Jul 26, 2012 at 2:10 AM, Johan Corveleyn jcor...@gmail.com wrote: On Thu, Jul 26, 2012 at 1:57 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote: 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. Directory externals are implemented as additional svn checkouts (or updates) following the primary checkout (or update). Indeed. Directory externals are a lot like an embedded checkout with some sugar around. This was a pretty early feature of Subversion. But this technique could only work for embedding entire directories, because a checkout is directory-based as well (you can't checkout a single file). So later someone implemented file externals as an additional feature, but had to use a different technique for that (using the 'switch' infrastructure, yielding the additional restriction of being able to use only intra-repository file externals). Thanks, that does clear things up. That's a pretty clever trick. Just to double-check that we're testing the right thing here: http://asvn/ifis-sw (or http://asvn/ifis-sw/tools or http://asvn/ifis-sw/tools/coverity) is a different repository than the one where you set the externals property (the repository from which your working copy is a checkout), right? So we're testing pulling in externals from a *foreign repository*. Correct. The repository is http://asvn/ifis-sw, and I'm pulling it into a working copy in http://asvn/ifis-dev (plus a few directories). Just checking because it's not really clear from your example, and above you also mention that absolute paths work, but the problem is not about absolute paths per se, but about externals from foreign repositories (and I asked you to verify the 1.6 behavior also with an absolute path to that foreign repository). Right, but you mentioned I should try with absolute paths. I chose to demonstrate it works with absolute paths, and also to demonstrate the problem with a transcript rather than just a prose description. scarecrow_SunOS_btfritz svn update ... Fetching external item into 'scripts/README.txt' Escripts/README.txt Updated external to revision 8699. Hm, I'm not sure if that indicates success actually. The 'E' notification means that some unversioned file obstructed the update, so I'm not sure if README.txt was actually updated to be like http://asvn/ifis-sw/tools/coverity/README.txt. [snip] This seems to indicate that the scripts/README.txt was already there in the working copy, and that it wasn't updated at all. Good to know. I should have read the documentation, I assumed it meant external and since there was no warning message that it worked as expected. I thought maybe that's because I was using update on an existing working copy after removing the directory. I tried again, using just svn checkout on a completely empty directory, but get the same results: == scarecrow_SunOS_btfritz cd temp /accts/btfritz/temp scarecrow_SunOS_btfritz mkdir external-test [update path to use old svn] scarecrow_SunOS_btfritz cd external-test /accts/btfritz/temp/external-test 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 RA modules] scarecrow_SunOS_btfritz svn checkout http://asvn/ifis-dev/[project path]/trunk/coverity . Acov5data Acov5data/build_output U . Fetching external item into 'user_models' Auser_models/mutex.c Auser_models/mutex_funcs.xmldb U user_models Checked out external at revision 8700. Fetching external item into 'scripts' Ascripts/compiler_setup_FSA-5000.csh Ascripts/compiler_setup.csh Ascripts/cov5run.csh Checked out external at revision 8700. Fetching external item into 'scripts/README.txt' Escripts/README.txt Checked out external at revision 8700. Checked out revision 901. scarecrow_SunOS_btfritz ls scripts compiler_setup.csh cov5run.csh compiler_setup_FSA-5000.csh README.txt scarecrow_SunOS_btfritz svn info scripts/README.txt Path: scripts/README.txt Name: README.txt URL: http://asvn/ifis-sw/tools/coverity/README.txt Repository Root: http://asvn/ifis-sw Repository UUID: 2c721b55-c2f9-124f-bb0b-342981104e5a Revision: 8700 Node Kind: file Schedule: normal Last Changed Author: ccanet\btfritz Last Changed Rev: 8633 Last Changed Date: 2012-07-03 17:02:58 -0500 (Tue, 03 Jul 2012) Text Last Updated: 2012-07-26 10:48:57 -0500 (Thu, 26 Jul 2012) Checksum: 714960c230b3f57b093a065092c9b3b1 == It is strange that I'm
File external that worked fine in 1.6.x not working in 1.7.5
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: File external that worked fine in 1.6.x not working in 1.7.5
On Wed, Jul 25, 2012 at 5:07 PM, Johan Corveleyn jcor...@gmail.com wrote: On Wed, Jul 25, 2012 at 6:23 PM, Benjamin Fritz fritzophre...@gmail.com 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. Subversion is open source software, see http://subversion.apache.org
