One really great feature of Subversion is the ability to make atomic commits that can span multiple parts of a software system, provided that all the parts reside in the same (monolithic) SVN repository. It seems that is exactly what you want.
Since you said that your multiple software units are stored in one (monolithic) SVN repository, here is one possible idea: In Subversion, you can get a sparse checkout. I don't know how this is done in Tortoise because I use the command line client, but it goes something like this: svn co --depth=empty svn://path/to/repo/and/directory And you can use one of: empty, immediates, or infinity for the --depth= argument. This gives the possibility to checkout the root of your Subversion repository, as --depth=immediates, without actually copying potentially gigabytes (or even more) data to your workstation. I am assuming that the root only contains directories, or at least it doesn't contain a lot of files. With --depth=immediates, you'll get those directories but they will be empty in your working copy. Then, you can progressively change to nested directories and "telescope" the depth using: "svn update --set-depth=" with one of empty, immediates, or infinity. This functionality is called a "viewspec" in some other version control systems. There is a Python script somewhere that can automate checking out a viewspec, and you can even version the "spec" files in your repository. See, for example: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py However what we've done (because we didn't know about the Python script and now we're accustomed to doing it this way) is that we simply wrote a .bat file that checks out a working copy of the root with "svn co --depth=immediates" and then telescopically expands the directories we're interested in with "svn update --set-depth=immediates" and/or "infinity". We have such a batch file for each "viewspec" that we'd want to checkout. Having a working copy that contains all relevant parts of your software system, you can apply changes to the multiple parts and then commit them in one atomic commit. Be mindful to be in the topmost directory when doing so, as Subversion commits apply to the current directory and all nested directories under it. Atomic changes across a monolithic repository are a very valid idea. You may find the following article interesting. It is about Google's internal monolithic version control system but the general idea transfers over to Subversion (on a much smaller scale): https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext At our site, we do use externals, but we do not develop inside the externals directories. We develop in the original directories. In all cases, our externals definitions always specify both the path and peg revision so that future changes to repository layout will not affect checkouts of past revisions. Hope this is helpful. On Tuesday, July 17, 2018 at 10:09:31 AM UTC-4, Gordon Jess wrote: > > I am currently working on projects which are composed of multiple software > units (stored on one SVN repository). Projects are "assembled" by > checking-out a combination of these shared software units to the > development environment, as svn:externals. > > The externals are defined in the 'Sources' folder as so: > > (local) (url) > <layer>/software_unit_1 <svn > server>/components/software_unit_1/source_code > <layer>/software_unit_2 <svn > server>/components/software_unit_2/source_code > ... ... > <layer>/software_unit_x <svn > server>/components/software_unit_x/source_code > > and external revisions are only pegged when tagging. > > > When I make modifications to an external in my working copy, I can commit > the changes back to the server by doing 'SVN commit' at its checkout > location. Perfect. > > Because of the dependencies between software units, I'd like to be able to > commit a logical set of changes to multiple externals in the same commit. > However, when I try do 'SVN commit' at the folder with the external > definitions, the external changes listed in the commit dialog window are > all greyed-out. > > Since they are listed in the commit window, it is clear to me that they > are from the same repository and be committed in a single commit. > > If my understanding is incorrect I'd be very happy to receive an > explanation of why this isn't possible. > > It would greatly improve our current workflow as, not only would it be > faster and more straightforward, the current process of individually > committing each external separately means our CI server cannot build > automatically on commits as changes for all dependencies cannot be > committed. > > Thanks and looking forward to heading from you. -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/ce3198f6-8d65-442b-a3fc-62062cc6066e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
