The minimal reproducible failure is as follows:
> mkdir test && cd test > svn co https://svn.server.com/repo . > vim php/main.php > svn commit Sending php/main.php Transmitting file data ..svn: Commit failed (details follow): svn: File not found: Transaction »52-1r«, Path »/php/main.php« svn: Your commit message was left in a temporary file:
What puzzles me is that this is a clean checkout, nobody has touched the repo (an svn update
before the commit makes no difference) and the file does exist (I can ls
it or vim
it).
The only notable thing here is that the folder name which contains main.php has changed between r1 and r52.
Where does that issue come from, why can that file not be found when it's obviously there? And how can I fix this?
It is good practice to get a file lock before editing a file. The lock tells other users that the file is being edited, and you can avoid merge issues. When you set up source control, you can configure SVN to make files with certain extensions read only. Users must get a lock on these read-only files before editing.
An svn commit of the file will fail with an “out-of-date” error. The file should be updated first; an svn update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.
You will also get this message when creating a tag using the client by copying into a new path where more than one level of the desired folder structure does not exist in repository. (Jeez that sounds complicated.)
In other words, I attempted to create a tag:
/projects/MyAwesomeProject/tags/myFirstTag
...but the 'tags' folder did not exist yet. I expected the client to do the work for me; manually creating the 'tags' folder was the cure.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With