i would like an option (i know subversion option) that it shouldnt touch
files that are currently not merged
Because if you just let this be then eventually many many files are suddenly
touched when you do a merge that includes 1 file
And the thing is that if you always do just the files you know that should
be merged, other files are i think not touched (not sure about this)
but if you do a parent it is touched. So somehow it is not really needed...
It shouldnt matter what the selection is... For example if subversion wants
as much info as needed. Then in my eyes it
can just also add merge properties to all the files that are merged (not
just what i selected so the project or another root)
Then it does have way more info even on the files itself. And those files
are changed anyway so i commit them anyway
Why is it important for subversion what i select? Isnt the files that are
really merged way more important?
The only thing i get is that it also have to insert into the dir i selected
so that it can filter the next time the revision i already merged right?
johan
On Wed, Mar 11, 2009 at 15:28, Mark Phippard <markphip_at_gmail.com> wrote:
> 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].
>
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=1308180
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-03-11 15:38:01 CET