On 11.06.2016 22:03, Olof wrote: > > > 2016-06-11 21:53 GMT+02:00 Branko Čibej <br...@apache.org > <mailto:br...@apache.org>>: > > On 11.06.2016 21:39, Olof wrote: > > > > > > 2016-06-11 20:03 GMT+02:00 Branko Čibej <br...@apache.org > <mailto:br...@apache.org> > > <mailto:br...@apache.org <mailto:br...@apache.org>>>: > > > > On 11.06.2016 19:48, Olof wrote: > > > Hello, > > > > > > Perhaps someone here can bring some light to this topic. > > > > > > We use the common technique with a trunk and feature > branches. A > > > feature branch is created by branching trunk. The feature > branch is > > > continually kept up-to-date with trunk by merging changes > from trunk > > > to feature branch (rebase). When development in the feature > > branch is > > > finished the content is merged back to trunk. > > > > > > When the feature branch is merged back to trunk all > changes to the > > > feature branch, including those created by rebase, is > recorded in > > > svn:mergeinfo property of the affected file/folder in > trunk. One > > > consequence of this is that files and folders which have > not been > > > updated in the feature branch (except by rebase) is marked as > > changed > > > (property only) in trunk when the feature branch is merged > back > > to trunk. > > > > > > The trunk log shows that these folders/files where changed > when the > > > feature branch was merged back to trunk despite that no > folder/file > > > content has been changed in the feature branch relative to > > trunk. This > > > is quite confusing for our users because TortoiseSVN shows > that > > a lot > > > of folders/files they haven't changed have been updated in the > > merge. > > > In addition a lot of unchanged files will be shown as > updated at > > next > > > SVN update command. Why is this necessary? Is it a desirable > > behavior? > > > Shouldn't SVN be able to figure our what's actually > changed in the > > > feature branch relative to trunk and record only this > mergeinfo? > > > > The real question is, where do all that mergeinfo properties > come > > from. > > > > In typical usage, you'd have an svn:mergeinfo property on > the root of > > each branch (including trunk). If mergeinfo properties are > defined > > beneath the root, the most likely reason is that someone > merged a > > subtree of the branch instead of the whole branch (hence, we > call this > > subtree mergeinfo). During a merge, all subtree mergeinfo > must be > > updated to reflect the merge results, regardless of whether > there were > > any changes in the subtree. > > > > I'm also a bit confused about your wording (re: > "folders/files"): > > do you > > actually have mergeinfo on files? > > > > -- Brane > > > > > > Now I had a close look at my trunk log. For some commits only files > > are changed, but there are also many commits for which mergeinfo is > > added to subfolders despite commit on top level. For example the log > > might look like > > > > a/b/c.txt - modified > > a/b - modified, mergeinfo only > > a/d/e.txt - modified > > a/d - modified, mergeinfo only > > a - modified, mergeinfo only > > > > Since both subfolders of a has been committed I conclude that > folder a > > must have been committed in one single commit. The added > mergeinfo in > > a, a/b and a/d is essentially identical, folder change only. This > > doesn't occur for all commits, only some. I cannot see a pattern for > > which ones. Ideas? > > In fact the root of the commit is irrelevant. What's relevant is the > root of the merge; 'svn merge' creates or updates the svn:mergeinfo > property, but does not commit it. > > An explanation for your example could be that someone merged the two > text files individually, then committed from the root of the branch, > like this: > > $ cd a/b > $ svn merge ^/a/b/c.txt c.txt > $ cd ../d > $ svn merge ^/a/d/e.txt e.txt > $ cd ../.. > $ svn commit > > > A subsequent merge at the root of the branch would update the subtree > mergeinfo on a/b and a/d as well as the root mergeinfo, and it's quite > reasonable that the mergeinfo becomes equivalent at all levels. > > There are valid reasons for doing things like that (or we wouldn't > support subtree mergeinfo in the first place). Or maybe this is just a > side effect specific to merge support in some client. I couldn't > guess. > > > No, I don't have mergeinfo on files, my mistake. > > That's good. :) > > -- Brane > > > It's not a result of merge of individual folders. I find the pattern > in the log for commits I've done and I have most definitely not gone > out of my way to explicitly merge several subfolders one-by-one.
As I said, once the subtree mergeinfo is in the repository, it will be updated in /every/ merge. > All users use TortoiseSVN. You think it's related to the client? > Should I ask the Tortoise community instead? We'de really need a more detailed what's actually happening. I'm afraid that for now we're only guessing based on your description of the logs; that's far from enough. Personally, the few times I've used TortoiseSVN for merging, I didn't notice it behaving in any way differently from the command-line client. -- Brane
