SVN externals sub folder changes not showing in view log (tortoise svn)

Question

SVN externals allow you to make an SVN folder appear as if it's at another location. A good use for this is having a common folder shared across all of your projects in SVN.

I have a /trunk/common folder in SVN that I share via several different project.

Example:

• Project1 : /trunk/project1/depends
• Project2 : /trunk/project2/depends
• Project3 : /trunk/project3/depends
• Project4 : /trunk/project4/depends

Each of these depends folders are empty, but have an svn:external defined to point to my /trunk/common folder.

The problem is when I view log within any of the projects: /trunk/projectX/ it does not show changes from the svn:externals. I am using tortoise SVN as my SVN client.

Does anyone know how to change this behavior? I would like for the show log of /trunk/projectX to include any changes to any defined svn:externals as well.

Answer 1

This is not possible with the current release of Subversion, other than explicitly calling svn log on the target of the externals directory

You can try issueing a feature request at the Apache Subversion website

Answer 2

from my personal experience the log of the external links is reported only if in the same commit where you are changed the external files, you modify also just one file in the "internal" folder. In this way SVN can retrieve with the proper log, the log from external folder too.

I think that using the hook should be possible to implement a mechanism for autocommit a spot file in the working dir for every commit, also if the commit start from external link.

Bye

Answer 3

When you display the log for a local versioned folder, it will show the changes that are relative to this particular folder. Externals are only a link to a different folder on the repository. The only thing you can track about external references, from a folder which depends on this external project, is the reference definition itself. That is because the reference is a subversion property of the dependent folder.

Imagine you have the following repo hierarchy :

repo
   myfirstproject
      trunk
   mysecondproject
      trunk
   mycommonlib
      trunk

and that mysecondproject\trunk folder has the following svn:external property :

svn://mysrv/repo/mysharedlib@2451 sharedlib

A checkout of mysecondproject\trunk inside a new folder secondproject will create something like this on your file system :

secondproject Folder (refers mysecondproject/trunk)
   sharedlib Folder (refers mycommonlib/trunk @ revision #2451)

Calling "Show log" command of Tortoise from secondproject folder will only show secondproject files changes, and eventually changes that occurred on the svn:external property of the folder.

To get change log of the external project, you need to call "Show log" from the inner folder sharedlib, which makes sense.

Answer 4

I think, after Subversion 1.7 (which introduced single .svn folder in the root of WC) it was more clean: for directory-type externals directory of external inside Working Copy is a) independent b) nested Working Copy of separate repository

>dir /B /S /AD
z:\subversion-troubleshoot-b\.svn
...
z:\subversion-troubleshoot-b\trunk
z:\subversion-troubleshoot-b\tags
z:\subversion-troubleshoot-b\trunk\lib
z:\subversion-troubleshoot-b\trunk\lib\.svn
...
z:\subversion-troubleshoot-b\tags\1.0.0
z:\subversion-troubleshoot-b\tags\1.0.1
z:\subversion-troubleshoot-b\tags\1.0.1\lib
z:\subversion-troubleshoot-b\tags\1.0.1\lib\.svn
...

and parent WC doesn't contain any information about nested WC (dir of WC, created from / of repository, note .svn dir presence twice only for mainline)

>svn ls -R
readme.textile
tags/
tags/1.0.0/
tags/1.0.0/core_mod.txt
tags/1.0.1/
tags/1.0.1/core_mod.txt
trunk/
trunk/core_mod.txt

when trunk (and tags respectively) have subdirectory lib as external

Support for handling externals added to update and commit, because this support produces independent and unrelated consecutive commands - and because without this support externals have no sense, aggregated svn log have to be somehow combined (by unknown principles, BTW)