> We are using svn 1.6 for a few weeks. Since then we faced the > problem > of the mergeinfo changing in files different from those that people > were actually committing. We found out that we should always commit > from the same level to stop this to happen. > > All good. I presume that we should have svn:mergeinfo property only > on > the root of the branch we are merging too, correct? > > It happens that several sub-folders in the branch that weren't > touched, contain mergeinfo property with revisions that ahve > nothing > to do with that folder. > > I had thought that some commits done from the root would change and > clear up the mergeinfo of subfolder, but this doesn't seem to be > the > case. > > Could someone please clarify how this clearing of mergeinfo works? >
Elision will only happen if the mergeinfo is fully duplicated on the parent folder. So, you must have mergeinfo in the files that isn't in the containing folders. Also, you have to commit the Elision when it happens or else you will get property changes on every merge. > Another question: we do revision based merging, promoting > stories/goals not necessarily in the same order they were committed > in > the trunk. Besides helping in tracing the changes in the branch the > the original logs, is there any other utility in having the > mergeinfo > information? Well... the merge info is for svn so it won't merge in the same revisions more than once and also for log viewing. If you are keeping track of this manually then you probably really aren't using the feature. However, there really is no way to turn it off. But, I think being able to see history back through the merge (-g --user-merge-history) is a pretty useful thing, isn't it? BOb
