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

Re: --ignore-properties for merge

From: Sergei Riaguzov <riaguzov_at_gmail.com>
Date: Thu, 7 Nov 2013 16:18:51 +0100


On Thu, Nov 7, 2013 at 3:16 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> Is there a way to exclude mergeinfo changes from commit? I.e. to use
> > --ignore-properties for svn merge in the same way as for svn diff?
> >
> > Rationale: imagine a feature branch which is created for implementing
> just
> > one feature. There are many commits with messages like "grrr..." or "wtf"
> > or whatever else since this is just a private branch for a feature. There
> > are also bunch of merges from trunk back to feature branch.
> >
> > Now the feature is done and the branch is to be reintegrated back to
> trunk.
> > It works, however commit contains a lot of property changes of
> directories
> > (mergeinfo). Also files that were added in the branch now have a
> property,
> > saying from were they were added.
> Sounds like you're using 1.6 clients. Is that the case?
> If so you want to upgrade them all to 1.7 or even better 1.8.
> See
> http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording

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. 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

> > The feature branch is to be removed after reintegration and no one is
> > supposed to see all those stupid messages. So what I would like to do is
> to
> > create a patch with a difference between branch and trunk and then apply
> a
> > patch to trunk.
> Well, this is possible by running the appropriate 'svn diff' command
> and saving its output to a file:
> e.g. like this: svn diff ^/trunk_at_400 ^/branches/mybranch > branch.diff
> Then give the branch.diff file to 'svn patch' (new in Subversion 1.7)
> in a working copy of trunk, which is simple: svn patch branch.diff
> HOWEVER: There is no support in svn patch for copied things (copies
> will show up as additions) and no support for renamed things (i.e you
> won't get tree conflicts alerting you of renamed paths). I would
> suggest using a reintegrate merge instead (see below).
That is exactly the problem - using svn diff, and then svn patch is not
convinient, merges are more convinient, however they lead to mergeinfo,
which I don't want. There is an option for a diff, why cannot be there for
a merge? The diff option is very handy indeed, I mean:

svn diff --ignore-properties --old ^trunk --new ^branch

That is very useful! Also if trunk changes often, we can use:

svn diff --ignore-properties --old
url_to_trunk_at_rev_where_trunk_was_last_merged_to_branch --new url_to_branch.

Such diff contains no mergeinfo and can be sent for review or to some other
person. Why cannot same option be introduce to svn merge, so that it would
be possible to say:

svn merge --ignore-properties ^url_to_branch

while being in trunk working copy?

> > Now there will be only one commit and no mergeinfo changes,
> > as if there is only one commit for a feature. This is exactly what I want
> > but it is not convenient at all because if there will be conflicts you
> > won't have a way to postpone them or resolve them.
> >
> > What I want to do is being in trunk to say something like:
> >
> > svn merge --ignore-properties ^trunk
> >
> > It works for diff (svn diff --ignore-properties --old trunk --new branch)
> > but there is no such option for merge. Is there a possibility that this
> > option can be added in a feature release?
> I don't really see a need for such an option, and I don't really
> understand where your problem is coming from in the first place.
1. I do not want to see where added files come from
2. I do not want to see any mergeinfo at all, the branch changes are coming
from is to be completely removed
3. There is a handy option --ignore-properties for diff, why cannot it be
for merge?

> You're not describing what Subversion commands you are running
> for merges. It is possible that you have problems because you're
> not using the right commands. How are you running merges exactly?
cd /path/to/branch
svn merge ^trunk
then to reintegrate
cd /path/to/trunk
svn merge ^branch

Everything is fine except that there is information for files which were
added in branch (they are shown in TortoiseSVN as copied from trunk) and
there is mergeinfo written to the root directory (and in case something has
screwed up while merging trunk to feature branch and some manual merges had
to be done - a whole bunch of other mergeinfos for other directories).

> Have you tried a reintegrate merge of the branch back to trunk?
> That creates a single revision in trunk history, which brings in
> all changes from the branch. You only see the branch log messages
> if you include merged revision in the log output (svn log -g).
> So it sounds like what you really want is the standard reintegrate merge.
> See
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
> and also
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
I am doing a standard reintregrate merge.
And with that merge I see:
1. Added files as copies
2. Mergeinfo for root directory
3. Mergeinfo for many other directories if something screwed up alongside
and manual merges had to be done from trunk to branch (which happens).
Received on 2013-11-07 16:19:30 CET

This is an archived mail posted to the Subversion Dev mailing list.