3

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 ?

Pierre
  • 133
  • 1
  • 5
  • 1
    I am not sure I understand the problem: this is a supported feature of SVN. For the last few years, you can even perform atomic commits across _repositories_, let alone _branches_. If the developer had the branch and trunk both checked out, made the change in both places and committed in one go that could explain this, but there is not enough information to say for sure. –  Mar 04 '15 at 22:03
  • Thx for your comment. I didn't know this was a svn feature, but what I meant is commiting in 2 branches was not *expected*. The developer had the the branch checked out, and not the trunk. The failing file commited on trunk was the old version of this file in the branch, not the expected commited version to the branch. – Pierre Mar 04 '15 at 22:10
  • I recommend digging through the SVN history then. If you are sure he did not have trunk checked out, maybe the commit's path will shed some light on what happened. As it is, this question is off-topic and difficult to answer anyway because there is not enough information. –  Mar 04 '15 at 22:22
  • 2
    Could the `svn switch` command be a factor here? You can switch an individual file or directory to point to a different branch (or repository) than the rest of the working copy. – Brandon Mar 04 '15 at 23:52

2 Answers2

3

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.

Simon Wang
  • 257
  • 1
  • 13
1

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.

  1. 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.

  2. There is a symlink pointing at the files in the trunk, so changing the branch actually affected the trunk as well.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513