As the title says, if you have multiple working copies of your repo checked out (eg one at work and one at home) and lock a file in one of them the SVN plugin thinks you have a lock on that file no matter which working copy you’re in. So if you modify a file in the copy that doesn’t actually have a lock it happily runs along until you try to commit.
Hello ,
I’m able to reproduce this issue but only if I’m using the same account with each working copy’s source control settings. I believe with the way SVN and other source control accounts work, this is expected behavior, as it is checking out the asset to that user, not that computer. Are you using the same username to connect to source control on both computers?
Oh, yeah, I specifically meant if you’re using the same username for both working copies. I can see how that might have been confusing.
The SVN executable is able to determine if you’re checking for a lock in a different working copy though. If I run “svn status -u” from my working copy with an item locked I get:
M K 1319 Content\Blueprints\SomeBlueprint.uasset
(M meaning modified, K meaning that I have the lock, 1319 is the revision number I’m on) but if I pull down a fresh checkout and run the same command I get:
O 1319 Content\Blueprints\SomeBlueprint.uasset
(O meaning locked by other).
If I understand what the svn plugin is doing, it runs an svn info command on the URL of the asset in the repo and checks the owner of the lock. A possible solution would be, if you find a lock by the current user, to also run svn info on the current working copy (so the command for my file above would be “svn info “Content\Blueprints\SomeBlueprint.uasset” --xml”) and check if that also has a lock and that the lock tokens are the same. There might be a simpler way of checking if you have a lock in your working copy but I don’t know enough about SVN to be sure.
Thank you for that information. I’ve placed a bug report in for the issue but I’m not sure if this is intended workflow or if it is just something that hasn’t been accounted for in the plugin. You can track the issue here: UE-40126. If it’s not intended workflow it’ll be marked as Won’t Fix and if it is just an oversight, it’ll be on its way to getting fixed, but that’s up to the devs to decide.
Have a nice day!