2016-06-11 21:53 GMT+02:00 Branko Čibej <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>>: > > > > 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. All users use TortoiseSVN. You think it's related to the client? Should I ask the Tortoise community instead? // Olof
