3

I'm doing many svn merges and commits. the thing that always happens to me (in every commit) is there is a constant set of files like a.java b.java foldera folderb etc and more files that the svn commit dialog always shows me i should be committing them however the files themselvs are not changed, what its showing is changed is the merge info of them, but actually i don't see why its showing them to me in commit dialog because no matter how many merges i'm doing the commit dialog always shows these files to me, even if i in source branch i change just one file i do commit i see this set of files, if i change another file in source branch and do merge to new branch and then commit again i again see this set of files (like 15 files...) anyway knows how can I overcome this please?

thanks

Jas
  • 14,493
  • 27
  • 97
  • 148

2 Answers2

4

This is usually caused by the svn:merge-info property being set at a lower then top level on a branch. This will happen if someone does a merge at a lower level. I try to do all my merges at the branch level, to make sure there are no missed files when doing a merge.

If you know you have no missing changes, you could move the values of these svn:merge-info properties up to the top level for the branch, then remove the property from lower levels.

This will prevent svn:merge-info from being wrong when viewing repository diffs.

Mike Miller
  • 2,149
  • 1
  • 18
  • 23
  • "move the values of these svn:merge-info properties up to the top level for the branch" - how do i do that? and what if i have multiple branches 1.1, 1.2, 1.3, 1.4, 1.5 where do i move the merge info to so that I wont have this error in all branches? (i'm doing merges always from 1.1 to 1.2 to 1.3 and on...) thanks – Jas Mar 19 '11 at 09:32
  • You can simply edit the svn:merge-info property like any other property. You can use the `svn pedit` command on it. – Mike Miller Mar 21 '11 at 16:30
  • I still don't understand why its happening for me. what is the connection between doing merges at a lower level than top level? i get this problem for various folders including lower level and top level... – Jas Mar 27 '11 at 10:07
  • Question: why does svn at all asks to commit svn:merge-info properties in case they got updated? i thought that svn would tell me just to commit regular files, why does it shows also these files in the commit list box? shouldn't it just commit them silently?? – Jas Mar 27 '11 at 10:15
  • The reason why it gets set at a lower level, is because if you don't merge from the top of a branch, it is possible you will miss files that were modified in a different sub-branch than the one you merged. Once the property gets set once on a sub-branch, it will need to keep it up to date forever. I try to avoid the problem, by always merging top-down. – Mike Miller Mar 28 '11 at 14:38
2

That's usually because of the way SVN manages merges. It adds a property on the file which says from which branches/revisions the file was merged.

Since in my experience (or lack of) svn is not great at tracking merges, I use the flag --ignore-ancestry when I merge. This usually removes those issues, and doesn't update the mergeinfo property.

Check on the right, there's quite a few other questions related to the same subject.

And if you feel like trying something new, move your repository to mercurial or git to avoid all the merge nonsense :).

Augusto
  • 28,839
  • 5
  • 58
  • 88
  • Hi, thanks for the informative reply, i would like to ask you in order to understand this better, if i use the --ignore-ancestry then wouldn't that mean svn will not remember which revisions i merged to my branch already? so next time i merge if i include the previous revisions i already merge it would think it needs to remerge them which will cause me merge problems? – Jas Mar 17 '11 at 16:38
  • why would git/mercurial remove the merge nonsense? I'm having multiple branches of versions like 1.1 1.2 1.3 and we need to do merges from 1.1 to 1.2 to 1.3 in anyway even if i'm on git or mercurial, thanks – Jas Mar 17 '11 at 16:39
  • about the first comment: yes, but you can merge a range of revisions, that's what I do... I'm not saying that it's best thing, but it's the best I found. About Git and Mercurial, they are million lightyears away from svn in how they manage merges. They both track commits and changes in files in a different way, which makes merging close to hassle free. Check [this other](http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem) post in SO that explains a bit how git manages the merges. – Augusto Mar 17 '11 at 16:54
  • this sounds like a very serious bug... How come svn which serves I think millions of people has such a basic bug? Changing technologies is not so simple, especially if you have hundreds of developers, there are a lot of open source projects like jboss apache who'm i know to use svn, i don't see why i should not at this stage - maybe further on i will change, but its strange to me there is such a basic bug there... I guess I need to open a bug out there to the svn implementors I'm using... sounds correct? – Jas Mar 27 '11 at 10:10