Hi SVN, We're stuck for the time being with server 1.4.2 but have updated our svn client(s) on Windows PCs (most of use Cygwin, CollabNet command line client and Tortoise) periodically over the last year or two.
About 7 or 8 months ago, we began using svn:externals heavily. At the time, I could've sworn we got errors when trying to tell an external to stream in to a subdirectory that didn't exist, e.g. our svn:externals on /app/trunk looks like this, for an arbitrary web app: modules/foo http://server/repo/path/to/foo/tags/01 modules/bar http://server/repo/path/to/bar/tags/02 modules/baz http://server/repo/path/to/baz/tags/03 In order for this to work, we had to create an empty `modules` folder under /app/trunk otherwise checking out would fail for foo, bar and baz externals. Well, we recently hired some new people and started seeing modules folders disappearing from the repository. Nobody's complaining about breakage... and so we did some tests and realized that the client can create folders at arbitrary depths when building the path necessary for an external. Can someone confirm this was changed recently for svn client? Otherwise I think I'm losing my mind because I swear this was not possible before. I tried to find the release notes for the different versions on the collabnet site but was unsuccessful. One other question about svn:externals. If you change or delete the local paths you're pointing your externals to, it leaves stray folders from before in the wc. Is this a bug or the intended behavior? Manually deleting these folders (not svn delete) works fine, but is there any more automated, foolproof way to check to see whether a certain tree in a wc has no reason for being there? (eg the external that created it it is no longer there?) specifically: svn propset svn:externals modules/foo http://server/repo/path/to/foo/tags/03 svn up svn propset svn:externals modules/bar http://server/repo/path/to/bar/tags/02 svn up svn ls modules/foo modules/bar Why does foo stick around? Thanks, Geoff
