3

I'm using TortoiseSVN (version 1.9.7) and just started using svn:externals. I want to use it to share some common functionality across different projects in the same repository. So the repo layout would be something like:

/projectA
/projectB
/projectC
/sharedLibs
/sharedLibs/lib1
/sharedLibs/lib2

I then use svn:externals, e.g. on /projectA/lib, to link some shared library into the current project. For example ^/sharedLib/lib1.

As recommended in the documentation I use explicit revion numbers (peg revision). Now, I can change some code in my working copy /projectA/lib/lib1 and TortoiseSVN offers me to commit that to /sharedLibs/lib1 so as to make my changes available to all projects.

However, if I want to then update the external of /projectA/lib to point to the change I just made myself, I have to make another commit just to change the svn:external property of /projectA/lib (with the “adjust to HEAD” option offered by TortoiseSVN's external-edit dialog).

Is there any shortcut to this process so that I don't have to make an extra commit every time I change something in the external (pointing to another folder in the same repository)?

Cornelius Sicker
  • 160
  • 8

1 Answers1

1

After playing around with svn:externals for a while now together with TortoiseSVN, my question now looks a bit silly to me... I'll state my current understanding here, since there is always a (small) chance it might help someone.

Basically one could try to (manually) squeeze everything into one commit, but this would fail to reflect what actually happens and would probably confuse someone reading the commit log.

Using the example from the question, what happens is the following:

  1. Local modifications in /projectA/lib/lib1 will be commited to /sharedLibs/lib1.
  2. The folder /projectA/lib has to be told to fetch the new revision of /sharedLibs/lib1, which was created in step 1. This is done by an update of the svn:externals property of the folder.

So changes actually happen in two completely different places, therefore it makes sense to use two commits. Another reason is that we want to point /projectA/lib/lib1 to a specific revision (peg revision) of /sharedLibs/lib1. We cannot know this new revision number, before the changes have been commited (in step 1 above). We could try to guess the revision number a new commit gets, but this might fail, if somebody else commits anything between our update and commit actions.

Cornelius Sicker
  • 160
  • 8