On Thu, Nov 07, 2013 at 04:18:51PM +0100, Sergei Riaguzov wrote:
> I am using 1.8.3 client. I've seen mergeinfo for a bunch of directories in
> my merges, when something screwed up while merging branch into trunk with
> subversion saying that revision range XXX:YYY was not merged from trunk to
> branch I have to manually merge those revisions and then merging branch to
> trunk lead to a huge amount of mergeinfo.
> But even if nothing is screwed up mergeinfo is saved for added files. If
> files are added to a branch and then merged to trunk, then for example in
> TortoiseSVN I can see that they originally come from a branch. I don't want
> that information.
That's a presentation-level issue for you with TortoiseSVN.
TSVN chooses to show information by default which you don't want to
be shown. TortoiseSVN is a separate project, so you're writing the
above request to the wrong mailing list.
> I even don't want information for even one directory -
> the root one (even if subtree mergeinfo is not recorded). I just don't want
> any mergeinfo, since the branch I am merging from is to be deleted and
> forgotten.
And you don't want any of the other benefits offered by mergeinfo?
I'm not sure you understand why merge-tracking exists.
> I am doing a standard reintregrate merge.
> And with that merge I see:
> 1. Added files as copies
> 2. Mergeinfo for root directory
Both of that works as designed. There is no good reason to change that.
The commands you use would stop working as expected if this was changed.
Problems merge-tracking was created to solve would re-appear (such as
spurious conflicts because of repeated merges of the same changesets,
no automatic reintegrate merge, etc. etc.). Please take some time to
understand why merge-tracking is necessary, and so understand its
design and implementation at a high level. For example, please read
http://www.open.collab.net/community/subversion/articles/merge-info.html
if you haven't already.
> 3. Mergeinfo for many other directories if something screwed up alongside
> and manual merges had to be done from trunk to branch (which happens).
We'll need to figure out why this mergeinfo is being created then.
This usually shouldn't happen unless you perform subtree merges,
or run into some edge cases Subversion doesn't handle very well.
We need to address the source of the problem. Hiding the problem
with an --ignore-properties option is not a solution.
Please explain in detail the merges which result in the creation
of the mergeinfo you don't want. Perhaps there is a bug that needs
to be fixed. The description you have given so far:
"when something screwed up while merging branch into trunk with
subversion saying that revision range XXX:YYY was not merged from trunk"
is not specific enough, I'm afraid. Someone else will need to be
able to understand your problem so well that they can reproduce it
locally.
Thanks!
Received on 2013-11-07 16:50:59 CET