I work on a project using maven and svn.
Today after a svn update, the maven build was failing on the svn trunk. When I looked in the svn logs, I saw something strange: a commit affecting two branches. Few files were commited on the foo branch – the expected result of this commit – and one were commited on the trunk (the reason of the maven fail), all of this in one commit.
This commit was made on Eclipse using a SVN plugin (I don’t know which one). Merges between this two branches had already been made few days ago, and the developer had an up to date working copy.
This was fixed easily by reverting the delictuous file, but I don’t understand what happend and I would like to understand it. Is this the result of an unfixed conflict, or an auto-commited unstaged file from a switched branch ? On svn, isn’t a working copy “linked” to one branch ?
4
As previously noted in the comments, a commit which affects a branch and a trunk at the same time is technically possible, so it looks more like PEBCAK.
I can see two reasons.
-
The person had both the trunk and the branch checked out, and the person mistakenly changed the trunk when thinking he was working on the branch. It happens.
-
There is a symlink pointing at the files in the trunk, so changing the branch actually affected the trunk as well.
Just share some interesting thing about this.
I personally run into this myself before, and at the time I believed I committed only once for one branch, but it changed files in two branches.
I spent quite a long time figured out why, I’m having a habit to reuse same local folder for different branches, by keep using svn switch. But I always switch on the root level of the folder, and I never switch individual file or directory like @Brandon mentioned in the comment.
I figured out why as again when I tried to switch that folder to a different branch, the switch was faster and it changed part of the folders rather than all of them, I noticed the difference and stopped the switch, and then check on sub folders and found some of those pointing to new one and some pointing to old one. And also it didn’t raise any problem. If I do the switch again it would switch the rest of it.
My best guess was at the time I switch there might be a network blip stopped the process but I didn’t notice it’s not done. Which lead to commit into both branches as I changed a lot files.
I have never try to recreate it again after, and I suspect that individual issue I run into might be gone as that time the local svn folder structure was like every folder has it’s own “.svn” folder, now with new svn working folder structure, “.svn” only exists in root so I guess it can’t easily happen again.