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 Sun, 12 Jun 2016 00:11:57 GMT
On 11.06.2016 22:03, Olof wrote:
>
>
> 2016-06-11 21:53 GMT+02:00 Branko Čibej <brane@apache.org
> <mailto:brane@apache.org>>:
>
>     On 11.06.2016 21:39, Olof wrote:
>     >
>     >
>     > 2016-06-11 20:03 GMT+02:00 Branko Čibej <brane@apache.org
>     <mailto:brane@apache.org>
>     > <mailto:brane@apache.org <mailto:brane@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

Mime
View raw message