Re: [Subclipse-users] subclipse merge touching non-changed files

On Wed, Mar 11, 2009 at 5:06 AM, Noel Grandin <noel_at_peralex.com> wrote:

> Situation:
>   I do repeated merges from a branch back onto trunk, cherry-picking
> specific revisions.
>
> Problem:
>  After the first couple of merges from a given trunk, lots of files in the
> trunk project end up "touched" somehow.
>  This means that they show up in the "Team Synchronizing" perspective, even
> though nothing has actually changed in those files.
>
> Am I doing something wrong? Is there a flag I should set to say "don't touch
> files that haven't actually changed"?

This is ultimately a Subversion question, not specifically Subclipse.
Not that we cannot discuss it here. I just want to make it clear this
is core-SVN behavior.

When you perform merges on a target, the target acquires merge
tracking information. Subsequent merges to a "parent" of the target
will also update this merge tracking information, which leads to
property changes that need to be committed.

Even though those paths turned out to not need any modifications for
the merge, the process did still look at those paths and figure this
out. It updates the merge tracking information so that it knows that
it does not need to do this again in the future.

The general consensus is that it is safe to not commit those changes
if it really bothers you, but you are potentially creating some other
"problems" for yourself. Namely, you are potentially making each
future merge to do more work by causing it to constantly have to
re-evaluate those paths/revisions to see if they have changes to be
merged. You are also defeating and going to lose the benefits of a
feature called elision.

Imagine, you a revision is committed and it impacts a lot of files.
You decide to cherry-pick the changes to one or a few of those files
because you need them now. This creates sub-tree mergeinfo on those
files. When you later merge the entire revision to trunk, merge
tracking is smart enough to not re-merge the files you cherry picked.
However, it will also evaluate the subtree mergeinfo and if that
revision is the only difference with the parent, it will "elide" the
subtree mergeinfo so that it now only exists at the parent.

When merge tracking was designed this seemed important. In practice,
it seems less so. But the important thing is that by not committing
those property changes you are creating differences between the
subtree mergeinfo and its parent so the properties will never be
elided away.

My best recommendation would be to just always merge into the root of
your project. Then you will never get mergeinfo on anything but the
root.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=1308119
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].