On 11.06.2016 21:39, Olof wrote:
>
>
> 2016-06-11 20:03 GMT+02:00 Branko Čibej <brane_at_apache.org
> <mailto:brane_at_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
Received on 2016-06-11 21:53:10 CEST