views:

32

answers:

1

Our Subversion repository has several subdirectories containing shared files as well as subdirectories for each project. Projects are set up with relative svn:externals properties to pull in shared directories out of the repository and set them up as subdirectories.

So, for example, our repostory looks something like this:

client
shared
portable
app1
app2

and app1 has as its svn:externals

../shared shared
../portable portable

so that on checkout, portable and shared are usable as subdirectories of app1.

TortoiseSVN has the nifty feature that doing a commit on app1 will automatically detect the externals subdirectories, realize that they're all part of the same repository, and commit all their changes as part of the same commit. However, I can't figure out how to get the same behavior out of the command-line client. Any suggestions?

+1  A: 

This feature is not yet implemented. The following is taken from the SVN ver. 1.5 book:

Perhaps most disappointingly, the working copies created via the externals definition support are still disconnected from the primary working copy (on whose versioned directories the svn:externals property was actually set). And Subversion still truly operates only on nondisjoint working copies. So, for example, if you want to commit changes that you've made in one or more of those external working copies, you must run svn commit explicitly on those working copies—committing on the primary working copy will not recurse into any external ones.

I also checked SVN 1.6 release notes and only two improvements have made which are related to svn:externals. These are: support for files in svn:externals and support for usual shell quoting rules in externals definitions.

Perhaps, this is not a feature worth to implement (and this is my view also). Generally, svn:externals are used to include relatively stable headers/files into some project/application which is dependent on them. Usually they reference to tags or paths of certain revisions. It's a big question with no particular answer what svn client is supposed to do in this case.

Pmod