TortoiseSVN 1.13.1 issue: Show log does not include changes in externals

150 views
Skip to first unread message

udo...@googlemail.com

unread,
Jan 31, 2020, 3:28:49 AM1/31/20
to TortoiseSVN
Hi,

I have a source tree which contains files and also pulls in some stuff via externals property. When I show the change log on the top level source dir then I observe two cases:
a) If a commit included changes in local files and externals then the log shows the commit and all affected local and external files as expected.
b) If a commit includes changes in externals only then the log does not show the commit at all. So the change log is incomplete.

I consider case b) a bug because the log is misleading. To me, this issue caused confusion several times.

Thanks.
Udo

Justin MASSIOT

unread,
Feb 1, 2020, 4:35:18 AM2/1/20
to TortoiseSVN
Hello Udo,
What do you mean exactly by "a commit includes changes in externals only" ? Did you check in both cases the logs from the folder of your "external"?

From what I understand, you're making a confusion between what belongs to your main repository and what belongs to the external repositories.
Case a: your commit affects the main repo and the external repo. Thus it's normal that you have this revision in your "main" log. (Not sure of what I'm saying: I think this action creates 2 commits, one in each repository.)
Case b: your commit only affects the external repo. This has nothing to do with the main repo, that's why you don't see the commit in the log.

Amongst things I've learned from other developers, it may not be a good idea to mix up several repositories in a single commit like you did. This brings confusion from the point of view of the external library.

Justin

udo...@googlemail.com

unread,
Feb 1, 2020, 12:32:51 PM2/1/20
to TortoiseSVN
Hello Justin,

The externals refer to the same repo. I never mix several repos in one commit. I should have mentioned this, sorry.

Case a) works as expected. No issue here.

In case b) the commit includes changes only in files pulled in via externals (from the same repo), but does not include changes in local files. In this case the log on the top level dir does not show the changes in the externals. 

Let me try to give an example:

/lib
   lib.cpp

/trunk        svn:externals=^/lib lib
   local.cpp
   lib
      lib.cpp

My working copy (wc) is created from trunk.

In case a) I modify local.cpp and lib.cpp and do a commit on the top-level wc dir (trunk). Then I check the log on that wc dir and it shows one commit with changes in both files.

In case b) I modify lib.cpp only and do a commit. The log for the top-level wc dir does not show this commit at all. That's the issue.

When I check the log on /lib in the repo, or on the lib subdir in my wc, it shows the lib.cpp commit of course. But I would expect that the log for my top-level wc dir shows all changes that happend to any files in that wc tree. This works in case a) but not in b) which is not consistent at least.

Udo

Justin MASSIOT

unread,
Feb 1, 2020, 1:27:22 PM2/1/20
to TortoiseSVN
Udo,
From the TortoiseSVN documentation, you're using a feature which you may not be aware of:

If the external project is in the same repository, any changes you make there will be included in the commit list when you commit your main project.

If the external project is in a different repository, any changes you make to the external project will be shown or indicated when you commit the main project, but you have to commit those external changes separately.     


It's only an ease of use added on top of the regular behaviour about externals.
So to me, what you describe is not a bug, it's the standard behaviour for externals: when you look at the logs of a WC/repo, externals are not listed.

udo...@googlemail.com

unread,
Feb 1, 2020, 1:49:16 PM2/1/20
to TortoiseSVN
Hi Justin,

Thanks for your reply. 

I understand that TSVN automatically includes externals (from the same repo) in the commit. My complains are not about commit behavior. This works as expected.

What's confusing is the log. Whether or not the log shows a change in the externals depends on whether or not the commit included changes in the main dir as well. That's not consistent. I would expect that the log always shows all changes made to the given WC tree.

Udo

Justin MASSIOT

unread,
Feb 1, 2020, 1:55:29 PM2/1/20
to TortoiseSVN
Whether or not the log shows a change in the externals depends on whether or not the commit included changes in the main dir as well. That's not consistent.
Yes of course it is consistent.

I would expect that the log always shows all changes made to the given WC tree.
That's exactly what it does. 

Stefan

unread,
Feb 1, 2020, 1:58:35 PM2/1/20
to TortoiseSVN
some explanation on how "show log" actually works:

if you show the log for e.g. /trunk, then the log will show you only those revisions that have changes to and below /trunk.
So: if you made changes to your external lib and some files below /trunk, then those revisions will show up.
But if you only make changes to the external lib and no other files below /trunk, then those revisions won't show up.

udo...@googlemail.com

unread,
Feb 2, 2020, 9:41:11 AM2/2/20
to TortoiseSVN
HI,

Thanks for clarification. Yes, that's exactly the behavior I'm observing. After thinking about this again, I understand why the log behaves this way technically. So I admit my issue is not a bug but a feature request:

If a have externals (from the same repo) in my project tree then TSVN has the nice feature to include them automatically in update/commit. This allows me to do update/commit on the top-level WC dir only, just as if all files were local. But the log for the top-level dir does not include the externals. IMHO this is not consistent. Commit and log behavior should be consistent for the whole tree.

So the feature request is: Include all revisions in the log that have changes to externals (from the same repo).

Udo

Stefan

unread,
Feb 2, 2020, 9:44:49 AM2/2/20
to TortoiseSVN
What your asking for is not really feasible. Think about it:
when you do a commit, the external properties are right there in the working copy. So a commit has that information ready.
But to show a log, that information is not readily available: the external properties can change in any revision.

udo...@googlemail.com

unread,
Feb 2, 2020, 1:33:47 PM2/2/20
to TortoiseSVN
Hmm. You are right, that's a problem. However, to me it would make sense if the log considers the externals which are present in the latest revision, or alternatively in the working copy.

I find the current behavior confusing because my project tree includes several external libraries and it is difficult to get an overview of all changes.

udo...@googlemail.com

unread,
Feb 3, 2020, 5:25:50 AM2/3/20
to TortoiseSVN
Based on your explanation on how "show log" works, would the following idea be feasible?

The log for e.g. /trunk shows those revisions that have changes to and below /trunk. For every of those revision, if there is an externals property which refers to the same repo, then add all revisions that have changes to and below the externals path but only if a revision is not already included because of changes in /trunk (i.e. eliminate duplicates).

In other words: The "show log" command builds an initial list of revisions based on the primary path, then follows all externals it can find in that list and adds any revision with changes in an external path if the given revision is not already present in the list.

Udo

Stefan

unread,
Feb 3, 2020, 10:18:43 AM2/3/20
to TortoiseSVN
Example: 1000 revisions (that's a very small repo) shown in log dialog
assume 20ms round trip time to fetch external properties

So: 1000*20ms = 20'000ms

So no: that's not feasible.

Also: something like this would have to be implemented in the svn library, not TSVN.

udo...@googlemail.com

unread,
Feb 3, 2020, 2:32:28 PM2/3/20
to TortoiseSVN
Thanks for your explanations. So it looks like committing changes to externals is not a good idea because it's difficult to review changes afterwards. Probably I should rethink my use of externals and use them one-way only for pulling in files.

Udo
Reply all
Reply to author
Forward
0 new messages