[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Check for modifications shows confusing list of modified properties after merge

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 26 Aug 2008 18:05:03 +0200

Josef Schwaab wrote:
> Okay, looks like we start to understand more but still are confused:
>
> It's not the text status which is modified, it's the property status.
> And it was not the update command but the merge command who did change
> the
> property status. So we had been misleaded as we did not check for
> modifications
> between these both operations.
>
> I understand that if I merge a 'source' folder with another 'source'
> folder, the source folder
> may have a change of its 'svn:mergeinfo' property. I would also
> understand, that all
> effected files of that merge may get a change in its 'svn:mergeinfo'
> property,
> although this would sound ineffective to me.

Why do you think that's ineffective? A property change doesn't cost much.

> What I do not understand: We merge a revision with two files changed
> and get about 20
> files which are absolutely unrelated to that merge changed in its
> 'svn:mergeinfo' property ???
> Why these 20 extra changes. Why not all, why not none?
>
> * Is this as intended or do we do something wrong?
> * Do we have to commit all these property changes?
> * Should http://subversion.tigris.org/merge-tracking/design.html
> explain it all or are there better
> explanations (will try to understand that tonight)?

the svn:mergeinfo property is handled by the Subversion library. If you
really want to understand how they work (which means understanding how
the whole merge tracking is handled internally) you'd have to ask on the
Subversion mailing list.

But I would advise you to not mess with those. The mergeinfo props tell
Subversion what has already been merged. That means for your next merge,
it won't have to ask the repository anymore whether those revisions have
already been merged because the client will simply read the local
properties, then only ask what is not already known. Since the merge
properties are stored locally, that's a *lot* faster than asking the
repository again for every revision whether it has been merged or not.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net

Received on 2008-08-26 18:05:28 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.