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