Hi, Les, > Von: Les Mikesell [mailto:lesmikes...@gmail.com] > > [In all the following cases, it is assumed that the external directory > > is from the same repository than the main working copy). > > That would be a bad thing to assume in general.
I know that I cannot commit into several different repositories at the same time (subversion does not support 2 phase commit or similar mechanisms), that's why I decided to ignore that cases. > > I can commit files and directories from inside and outside the > > external directory in the same commit, as long as the external > > directory itself is not mentioned on the list of elements to commit. > > I'd consider that accidental and not count on it. Accidental. It seems that svn is more limited than I thought [1]. > > I can commit the external directory itself (with and without files and > > directories below the external directory), as long as no file or > > directory outside of the external directory is mentioned on the list > > of elements. > > That part makes sense. > > I cannot commit the external directory itself (which has changed > > properties) together with any path in the working copy outside of the > > external directory. > > > > Is there a workaround? > > If it is all in the same repository and you want it to be treated > monolithically, why not move it to the layout you want instead of > fighting with externals? I'm working on a SharpSNV based Subversion plugin for the CoDeSys IDE, and the project tree there has some logical restrictions which do not allow the user to choose a completely free layout. And although we need a mapping layer between the internal project tree and the subversion working copy[2], we want to keep the layout of the working copy tree at least similar to the project tree. Additionally, we want to enable the user to include subtrees via externals from other locations - for example, he can include a complex device tree via externals, and thus reference it from several projects (which contain different applications for similar hardware). This sharing is not possible (or at least not with the same semantics) when using svn cp or other mechanisms. > Or if the referenced parts are really > separate components, remember that and cd into the relevant directories > when committing component changes. We want to put as less limits on the user as possible, but it seems that restricting commits to not cross external borders seems to be the only comprehensible behavior we can provide for our users in this case. Having it work in some cases, but not in others (depending on whether the external root is modified or not) seems to be too complicated teach our users. But I should stop whining now, and try to produce working code[3]. Regards, Markus Schaber [1] IIRC, years ago, when I used an svnkit based Eclipse plugin on linux, it was normal for me to commit files of two different projects (and thus different working copies) if they belong to the same repository. (Which makes sense in some light, as in pre-1.7, every directory is self contained, and the server does need to know about unchanged parent directories when committing.) When using svn command line and SharpSVN later, it found it to be a somehow artificial restriction that the "original" subversion client is not capable of doing that. So I was happy to find out later when using TortoiseSVN that I was now able to commit files from inside of same-repository externals in the same commit. First, I suspected that TortoiseSVN is doing some internal magic, but as I could reproduce that with the command line, I did assume that this was intentional. [2] Some of the reasons for that mapping layer are: Our project tree is not based on a directory layout, but saved in a single file in an internal database. The tree does not distinct between folders and objects, but arbitrary objects can have children, e. G. a device has buses, the buses have other devices plugged in. And a parent may have more than one child with the same name, e. G. several empty slots. This architecture is wired deeply into the product, and cannot be changed "just for a SVN plugin". [3] Here at work, we currently only have very limited time to contribute upstream. I wanted to do that at home in my spare time (as I used to do under my former employees when I worked with Linux), but I failed hard to find a way to build SharpSVN with only free (as in beer) tools. Two days of wasted time, and I'm not able to spend my private money for visual studio full version.
