Pfthb

I want a way to get the latest changed revision which is in my current working copy. I've tried doing this:

svn info --show-item last-changed-revision

This works most of the time, but if I make a commit it doesn't. For example:

$ svn info --show-item last-changed-revision
169680

$ svn add test.txt
A test.txt

$ svn commit -m "test change"
Adding test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170547.

$ svn info --show-item last-changed-revision
169680

As you can see, it's still returning the last revision after the commit. If I update my working copy, it will (mostly) work:

$ svn update
Updating '.':
At revision 170547.

$ svn info --show-item last-changed-revision
170547

However, this would get any changes that anyone else has committed since I made my commit, which is a risk I'd rather not have to take.

Is there another way to make my local workspace aware of the revision I have committed, without actually getting latest?

The use case is a build tool where we want to be able to name the build after the revision it's made from, but we also commit a version update to the branch in the building process, which is why we generally don't get the correct revision from the svn info call.

EDIT: After suggesting from Richard Smith, I tried adding a * at the end of the line (and also tried a .).

$ svn commit -m "test change 2"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170555.

$ svn info --show-item last-changed-revision *
169680 android
169680 AssetBundles
170555 test.txt
169680 unity
...

$ svn info --show-item last-changed-revision .
170547

$ svn update
Updating '.':
At revision 170555.

$ svn info --show-item last-changed-revision .
170555

As you can see, the revision is actually correct on the file that was updated ("test.txt") even before the update, but the revision on the top directory is not. That seems "incorrect" to me, both because the top directory contains the edited file, so it would be the most recent contained change, and since it does show the new revision in the directory after the update.

EDIT 2: I considered using svn log instead, thinking that would obviously contain the commit I just made, but this doesn't seem to be the case, either:

$ svn commit -m "Test 5"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170617.

$ svn info --show-item last-changed-revision
170566

$ svn log -l 1
------------------------------------------------------------------------
r170566 | svend.hansen | 2018-11-13 15:06:08 +0100 (Tue, 13 Nov 2018) | 1 line

$ svn log -l 1 test.txt
------------------------------------------------------------------------
r170617 | svend.hansen | 2018-11-14 10:10:12 +0100 (Wed, 14 Nov 2018) | 1 line

$ svn info --show-item last-changed-revision test.txt
170617

So even the log seems to not return something matching the actual state of the working copy. This must be a bug in subversion, right? I can't think of any good reason that the log would not include changes that are actually in the working copy?

TLDR: You can get the last locally available changed revision with this command:

svnversion -c

Here are some more thoughts on why SVN works this way, and our solution, that isn't just using this revision directly:

Actually, I can think of a reason the log wouldn't include the last commit: SVN will let you submit changes to a repository, even though there are changes in that repository they you don't have locally, as long as the files affected in those changes don't overlap with those affected by yours. This means that you can commit revision 10 without having revision 8 and 9. So when asking for the log for the entire directory, it can't show 10, as that then be missing 8 and 9. However, it can say that it got 10 when asking for the latest revision for the specific file, as it wouldn't allow you to commit 10 without getting 8 and 9 if they also affected the file, and therefore they wouldn't be included in the log just for that file.

I guess this way of working stems from the way SVN doesn't have projects in a repository, but just lots of folders, and you can check out any subfolder and make changes to it, with no regards to what folders contain it.

This is how we have decided to work:

$ echo test6 > test.txt

$ svn commit -m "Test 6"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170633.

$ svnversion -c
20414:170633

$ svn update -r 170633
Updating '.':
At revision 170633.

That way we both get the revision of the latest change, and we ensure that the state of the working copy, before building, is one that is represented in SVN.