subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: svn:mergeinfo updated for unchanged files/folders at merge of a feature branch to trunk - is this desirable?
Date Sat, 11 Jun 2016 18:03:32 GMT
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

Mime
View raw message