4

I'm using svn for version control and have the following question:

  • Let's say I develop something in my feature branch and constantly upstream changes from the trunk (by simply merging them and resolving conflicts). Now, at some moment I made my last upstream merge from trunk and resolved the conflicts. And, for example, right after that merge I somehow manage to "freeze" the trunk - all commits to trunk are being rejected and it always remains in the same state.

  • Does this guarantee the absence of conflicts when I perform the merge --reintegrate for my feature branch? Or I am missing some other conditions and actions, which might possibly lead to them?

Yippie-Ki-Yay
  • 20,062
  • 23
  • 85
  • 143

2 Answers2

4

How do you plan to freeze trunk?

If you do freeze trunk first, and then do your merge from trunk to branch, you are guaranteed that no one has touched trunk since your last merge.

You shouldn't have any merge conflicts if:

  • You don't cherry pick merges since all merge conflicts should have been handled when you merged from the branch to the trunk -- that's if you didn't do any cherry picking of merges.
  • You always did your merging from the same root directory.

However, it is possible with some strange edge case where this might not necessarily be true. I've tried with two feature branches to see if I could force a reintegrate conflict, but I couldn't.

David W.
  • 98,713
  • 36
  • 205
  • 318
  • Thank you! I guess it's possible to "freeze" the trunk by setting temporary read-only permissions to it for all users. However, this question is purely academic. Could you please *(if that's possible)* describe the corner cases you've encountered with a bit more detail? – Yippie-Ki-Yay Jun 04 '12 at 21:30
  • 1
    @Yippie-Kai-Yay I haven't found any corner cases. I created with two files in it, and tried using a few branching and merging things to cause the `--reintegrate` to have a conflict, and I couldn't. I purposely created conflicts too in order to force the issue, but couldn't as long as I did a merge to the branch before the reintegration. You can use my [pre-commit hook](https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook) to control who has write permissions and where. That will allow you to freeze trunk w/o having to futz with the Subversion server settings. – David W. Jun 04 '12 at 21:35
0

I don't see this behavior, I'm able to generate a conflict on the merge --reintegrate. This is with svn 1.6.18, not sure if there's a feature dependency here. In particular, where a conflict on the branch has required a manual resolution (i.e. an --accept mine-* or --accept theirs-* would not work), I can't see how subversion could avoid conflicting on the merge --reintegrate, since it can't really 'tell' how you resolved the conflict, and the conflicting lines are unchanged on the trunk.

I'm actually looking for a solution to a related question - how to 'remember' the manual resolution when remerging to trunk, so a user doesn't have to go through the same conflict resolution twice (and the same thought processes) - but I'll ask that question separately if there's no discussion here.

tryingToBeClever
  • 33
  • 4
  • Update - I worked out why I was getting conflicts on the re-merge, it is because I had unmerged changes on trunk. `svn mergeinfo ^/trunk --show-revs eligible` showed me my error. – tryingToBeClever Aug 16 '13 at 13:30