Cannot reintegrate feature branch

[Jean Seurin]

Hi,

I just persuaded my organisation to give a try to Feature Branch.

After 3 merges only, when I attempt to --dry-run a merge --reintegrate
I've got the following error:

svn merge --reintegrate ^/branches/project-dev --dry-run

With an OSX 1.6.11 client :

svn: Cannot reintegrate into a working copy not entirely at infinite depth

with a Ubuntu 1.6.5 client on fresh check out:

svn: Reintegrate can only be used if revisions 6336 through 6393 were
previously merged from svn://company/company/trunk/project to the
reintegrate source, but this is not the case:

branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/resources/log4j.properties
Missing ranges:
/trunk/project/src/test/resources/log4j.properties:6336-6389

I really don't undertsand what has happened. The merge went well.
I've tried to modify the svn:mergeinfo properties to add the missing
info but to now avail. I think I shouldn't have to that.

Help please!
Jean

[Jean Seurin]

Some more information, that may indicate a bug:

All and only the 5 files concerned with the probleme have been commited
during after a merge from the trunk, empty of modification, but with the raw
properties modified as follow:
added line
/branches/project-1.13/*pathToFile*:6266-6372

This comes from a merge done on the trunk from a release branch, which in
turn made its way to the Feature branch of the trunk.

The operation seem regular to me, the question is why only those 5 files
have add the mergeinfo added?

What can I do to solve this? Would simply remove the added line in mergeinfo
for those 5 files would do trick?

thanks
Jean

---------- Forwarded message ----------
From: Jean Seurin <***@gmail.com>
Date: Thu, May 6, 2010 at 6:18 PM
Subject: Cannot reintegrate feature branch
To: ***@subversion.apache.org


Hi,

I just persuaded my organisation to give a try to Feature Branch.

After 3 merges only, when I attempt to --dry-run a merge --reintegrate I've
got the following error:

svn merge --reintegrate ^/branches/project-dev --dry-run

With an OSX 1.6.11 client :

svn: Cannot reintegrate into a working copy not entirely at infinite depth

with a Ubuntu 1.6.5 client on fresh check out:

svn: Reintegrate can only be used if revisions 6336 through 6393 were
previously merged from svn://company/company/trunk/project to the
reintegrate source, but this is not the case:

branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/resources/log4j.properties
Missing ranges:
/trunk/project/src/test/resources/log4j.properties:6336-6389

I really don't undertsand what has happened. The merge went well.
I've tried to modify the svn:mergeinfo properties to add the missing info
but to now avail. I think I shouldn't have to that.

Help please!
Jean

[Stefan Sperling]

Post by Jean Seurin
added line
/branches/project-1.13/*pathToFile*:6266-6372

A * has special meaning in mergeinfo.
Does the * actually appear in the mergeinfo or not?

Stefan

[Jean Seurin]

Hi Stefan,

it actually does not appear in mergeinfo.

thanks
Jean

Post by Stefan Sperling

Post by Jean Seurin
added line
/branches/project-1.13/*pathToFile*:6266-6372

A * has special meaning in mergeinfo.
Does the * actually appear in the mergeinfo or not?
Stefan

[Stefan Sperling]

Post by Jean Seurin
Hi,
I just persuaded my organisation to give a try to Feature Branch.
After 3 merges only,

What 3 merges precisely?

Post by Jean Seurin
when I attempt to --dry-run a merge
svn merge --reintegrate ^/branches/project-dev --dry-run
svn: Cannot reintegrate into a working copy not entirely at infinite depth

That error is important.
Why is your working copy not entirely at infinite depth?

If you don't understand this error message, please read:
http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html

Post by Jean Seurin
svn: Reintegrate can only be used if revisions 6336 through 6393
were previously merged from svn://company/company/trunk/project to
branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/resources/log4j.properties
/trunk/project/src/test/resources/log4j.properties:6336-6389
I really don't undertsand what has happened. The merge went well.

Well, let's look at what the error is saying:

So there are files in trunk/project from which you have not yet merged
changes into your branch. You have however merged changes to other
files from revisions 6336 through 6393 to your branch from trunk.

That is what's causing the error. r6336 to 6393 have not been completely
merged from trunk to the branch. The changes listed in the error message
are the changes which have not been merged into the branch yet.

This can easily happen if people do merges into shallow working copies,
with depth != infinity. Maybe your working copy on the Mac is shallow,
and you have done incomplete merges from trunk to the branch with it,
and as a result those merges weren't complete, causing reintegrate to
complain?

To illustrate, let's assume I make a commit to trunk in r50,
which affects the following files:

/trunk/foo.c
/trunk/bar/baz.c

Now I merge r50 from trunk to my branch, but the merge omits the change
to bar/baz.c because my branch working copy is shallow.
The mergeinfo created by this merge looks like this:

/branch (svn:mergeinfo = trunk:r50*)
/branch/foo.c (svn:mergeinfo = trunk:r50)

The * means "only applies to this folder, not its children".
This happens because svn realises that I did not merge changes r50
made inside of /trunk/bar/. Maybe I still want to merge those later.
Because the mergeinfo at /branch is not inheritable, svn also made
a note at /branch/foo.c saying "this file already has changes to r50".
This will prevent changes made in r50 to foo.c from being merged to
the branch again.

Trying to reintegrate the branch from this state without first merging
everything r50 did will result in the error you are getting.

You want mergeinfo like this:

/branch (svn:mergeinfo = trunk:r50)

Which says "This entire branch has all changes made to trunk in r50".

BTW, a 1.6 client will flag a tree conflict in this case,
saying "local delete, incoming edit upon merge", because in my WC
it looks as if I deleted bar/ (though it should probably say "local
missing because of shallow working copy, incoming edit").
You probably did the merge with a 1.5 client since you didn't get a conflict?

Post by Jean Seurin
I've tried to modify the svn:mergeinfo properties to add the missing
info but to now avail. I think I shouldn't have to that.

No, you shouldn't. My guess is that (possibly unconscious) use of shallow
working copies is responsible for this error.

Shallow working copies have their use cases, but merging into them
isn't one of them (unless you know about the consequences and know
how to deal with them).

Thanks,
Stefan

[Jean Seurin]

I mean 3 times doing a
svn merge ^/trunk/project
on the feature branch and then commit.

So each time commiting some modifications coming from the trunk,
everything went well.

I checked sparse dir doc, I understand it. I've run the same reintegrate
command on freshly checked out working copy, same result except that it
was with a Ubuntu 1.6.5 client and the error was more explicit.

We are not working with shallow working copies.

A possible explanation I foresee, is someone with a 1.5 client doing the
merge from the Release branch to the trunk, causing problem when merging
trunk to Feature Branch afterward.

Investigating...

Thanks for your deep explanation of the shallow copies ;)
Jean

Post by Stefan Sperling

Post by Jean Seurin
Hi,
I just persuaded my organisation to give a try to Feature Branch.
After 3 merges only,

What 3 merges precisely?

Post by Jean Seurin
when I attempt to --dry-run a merge
svn merge --reintegrate ^/branches/project-dev --dry-run
svn: Cannot reintegrate into a working copy not entirely at infinite depth

That error is important.
Why is your working copy not entirely at infinite depth?
http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html

Post by Jean Seurin
svn: Reintegrate can only be used if revisions 6336 through 6393
were previously merged from svn://company/company/trunk/project to
branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/resources/log4j.properties
/trunk/project/src/test/resources/log4j.properties:6336-6389
I really don't undertsand what has happened. The merge went well.

So there are files in trunk/project from which you have not yet merged
changes into your branch. You have however merged changes to other
files from revisions 6336 through 6393 to your branch from trunk.
That is what's causing the error. r6336 to 6393 have not been completely
merged from trunk to the branch. The changes listed in the error message
are the changes which have not been merged into the branch yet.
This can easily happen if people do merges into shallow working copies,
with depth != infinity. Maybe your working copy on the Mac is shallow,
and you have done incomplete merges from trunk to the branch with it,
and as a result those merges weren't complete, causing reintegrate to
complain?
To illustrate, let's assume I make a commit to trunk in r50,
/trunk/foo.c
/trunk/bar/baz.c
Now I merge r50 from trunk to my branch, but the merge omits the change
to bar/baz.c because my branch working copy is shallow.
/branch (svn:mergeinfo = trunk:r50*)
/branch/foo.c (svn:mergeinfo = trunk:r50)
The * means "only applies to this folder, not its children".
This happens because svn realises that I did not merge changes r50
made inside of /trunk/bar/. Maybe I still want to merge those later.
Because the mergeinfo at /branch is not inheritable, svn also made
a note at /branch/foo.c saying "this file already has changes to r50".
This will prevent changes made in r50 to foo.c from being merged to
the branch again.
Trying to reintegrate the branch from this state without first merging
everything r50 did will result in the error you are getting.
/branch (svn:mergeinfo = trunk:r50)
Which says "This entire branch has all changes made to trunk in r50".
BTW, a 1.6 client will flag a tree conflict in this case,
saying "local delete, incoming edit upon merge", because in my WC
it looks as if I deleted bar/ (though it should probably say "local
missing because of shallow working copy, incoming edit").
You probably did the merge with a 1.5 client since you didn't get a conflict?

Post by Jean Seurin
I've tried to modify the svn:mergeinfo properties to add the missing
info but to now avail. I think I shouldn't have to that.

No, you shouldn't. My guess is that (possibly unconscious) use of shallow
working copies is responsible for this error.
Shallow working copies have their use cases, but merging into them
isn't one of them (unless you know about the consequences and know
how to deal with them).
Thanks,
Stefan

[Stefan Sperling]

Post by Stefan Sperling
/branch (svn:mergeinfo = trunk:r50)

Oh, and I'm not implying that you should modify the mergeinfo by hand.
Just do the merge from trunk to the branch again, but with a working
copy at depth infinity. This will make the branch pick up the missing changes.
Then try to reintegrate the branch again.

Stefan

[Jean Seurin]

Hi Stefan,

unfortunately even with a fresh branch check out, it would not pick up
the missing changes, that is the problem.
All our WC are at infinity by default, if I'm not mistaken, since we
don't use sparse directories. So this can't have been the source of the
error.

cheers
Jean

Post by Stefan Sperling

Post by Stefan Sperling
/branch (svn:mergeinfo = trunk:r50)

Oh, and I'm not implying that you should modify the mergeinfo by hand.
Just do the merge from trunk to the branch again, but with a working
copy at depth infinity. This will make the branch pick up the missing changes.
Then try to reintegrate the branch again.
Stefan

[Stefan Sperling]

Post by Jean Seurin
Hi Stefan,
unfortunately even with a fresh branch check out, it would not pick
up the missing changes, that is the problem.

Can you try to find out why it would merge the remaining changes?

I don't think anyone can help you debug this remotely without
knowing what your mergeinfo really looks like.
Maybe you can pin-point the problem yourself by looking at
mergeinfo? Using commands like svn mergeinfo, and if necessary
looking at mergeinfo properties directly should provide clues.

Stefan

[Stefan Sperling]

Post by Stefan Sperling

Post by Jean Seurin
Hi Stefan,
unfortunately even with a fresh branch check out, it would not pick
up the missing changes, that is the problem.

Can you try to find out why it would merge the remaining changes?

s/would/would not/

Sorry,
Stefan

[Jean Seurin]

Hi Stefan,

mergeinfo properties are exactly as I mention for the file causing problems:

all and only the 5 files concerned with the problem have been commited
after a merge from the trunk, empty of modification, but with the
mergeinfo properties modified as follow:
added line
/branches/project-1.13/pathToFile:6266-6372

This comes from a merge done on the trunk from a Release branch, which
in turn made its way to the Feature branch in question.

The operation seem regular to me. The question is why only those 5 files
have add the mergeinfo added?
All the other files commited in the trunk as part of the same merge from
the Release branch didn't get their mergeinfo updated.

cheers
jean

Post by Stefan Sperling

Post by Jean Seurin
Hi Stefan,
unfortunately even with a fresh branch check out, it would not pick
up the missing changes, that is the problem.

Can you try to find out why it would merge the remaining changes?
I don't think anyone can help you debug this remotely without
knowing what your mergeinfo really looks like.
Maybe you can pin-point the problem yourself by looking at
mergeinfo? Using commands like svn mergeinfo, and if necessary
looking at mergeinfo properties directly should provide clues.
Stefan

[Stefan Sperling]

Post by Jean Seurin
Hi Stefan,
all and only the 5 files concerned with the problem have been
commited after a merge from the trunk, empty of modification, but
added line
/branches/project-1.13/pathToFile:6266-6372
This comes from a merge done on the trunk from a Release branch,
which in turn made its way to the Feature branch in question.

I'm afraid I still think I'm not getting the whole picture, which
makes it hard to understand the problem and help you solve it.

You're giving us hints about what changed in the mergeinfo, but you
aren't providing a complete picture of what the mergeinfo in your
repository really looks like.

Maybe you don't want to or cannot share that information, that's fine.
I think in this case it would be best if you could try to reproduce the
failing merge with a small example script, starting by creating an empty
repository, and running svn commands creating all necessary branches
and doing merges in order to make the problem appear. Then we can reason
about that example and try to find out what is wrong.

You can find an example script you can base your own script on here:
http://subversion.apache.org/docs/community-guide/repro-template.sh

Thanks,
Stefan

[Jean Seurin]

Here's the whole thing, minus unconcerned subprojects:

Properties on '$REPO/trunk/project/src/test/resources/log4j.properties':
svn:mergeinfo

/branches/project-1.10/src/test/resources/log4j.properties:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13/src/test/resources/log4j.properties:6266-6372

/branches/project-adptation-to-commons-1.1/src/main/resources/log4j.properties:1780-1790
Properties on
'$REPO/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java':
svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:1780-1790
Properties on
'$REPO/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java':
svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:1780-1790
Properties on
'$REPO/trunk/extranetof/src/main/filters/jse.filter.properties':
svn:mergeinfo
Properties on '$REPO/trunk/project':
svn:mergeinfo
/branches/project-1.10:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13:6266-6372
/branches/project-adptation-to-commons-1.1:1780-1790
Properties on
'$REPO/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java':
svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:1780-1790
Properties on
'$REPO/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java':
svn:mergeinfo

/branches/project-1.10/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405

/branches/project-1.13/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6266-6372

/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:1780-1790

I leave as it is, it probably speaks to you more it does for me.
Here's the list of error produce by 1.6.5 that indicates problematic files:

svn: Reintegrate can only be used if revisions 6336 through 6393 were
previously merged from $REPO/trunk/project to the reintegrate source,
but this is not the case:

branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6336-6389

branches/project-dev/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java
Missing ranges:
/trunk/project/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6336-6389
branches/project-dev/src/test/resources/log4j.properties
Missing ranges:
/trunk/project/src/test/resources/log4j.properties:6336-6389

Jean

Here're the entire mergeinfos in the problematic files,

That is still not enough. Subversion considers mergeinfo set
on every file or directory within the merge target when determining
what needs to be merged where. From the target's root folder downwards.
svn propget -v -R svn:mergeinfo $REPOSITORY_URL/trunk
Please keep the discussion on-list (e.g. by Cc'ing the users list)
since everyone needs to see all messages to participate in the
discussion.
Thanks,
Stefan

[Stefan Sperling]

Post by Jean Seurin
svn:mergeinfo
/branches/project-1.10/src/test/resources/log4j.properties:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13/src/test/resources/log4j.properties:6266-6372
/branches/project-adptation-to-commons-1.1/src/main/resources/log4j.properties:1780-1790
svn:mergeinfo
/branches/project-1.10/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6266-6372
/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/adherent/persistence/AdherentDAOHibernateTest.java:1780-1790
svn:mergeinfo
/branches/project-1.10/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13/src/test/java/com/company/client/project/courrier/persistence/CourrierDaoHibernateTest.java:6266-6372
/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/courrier/persistence/CourrierDAOHibernateTest.java:1780-1790
Properties on
svn:mergeinfo
svn:mergeinfo
/branches/project-1.10:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13:6266-6372
/branches/project-adptation-to-commons-1.1:1780-1790
svn:mergeinfo
/branches/project-1.10/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDaoHibernateTest.java:6266-6372
/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/codeobjet/persistence/CodeObjetDAOHibernateTest.java:1780-1790
svn:mergeinfo
/branches/project-1.10/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDaoHibernateTest.java:6266-6372
/branches/project-adptation-to-commons-1.1/src/test/java/com/company/client/project/dossierstagiaire/persistence/DossierStagiaireDAOHibernateTest.java:1780-1790
I leave as it is, it probably speaks to you more it does for me.

What strikes me is that you have a lot of subtree mergeinfo,
but no mergeinfo on the trunk root folder. This indicates that you
are probably not doing merges in a way you want to.

It looks as if changes were merged into files one-by-one, rather than
merging reivisions from the root of the source branch into the working
copy root. This happens e.g. if people right-click files in TortoiseSVN
to merge changes into them, or if they specify paths other than the
working copy root when using the svn merge command.
This works, but should only be done if you really need it.

Usually, you'd merge from one branch root to another.
Anything else is special, and if you're not a merging expert
and just want things to work, do not do it!
Right-click on the working copy root folder.
At the command line, change directory to your branch root before
doing merges, and use the default merge target path (which is ".",
the current directory).

Note that mergeinfo is always created at the merge target.
These are the locations of mergeinfo in trunk of your repository:

trunk
project [svn:mergeinfo]
src
test
resources
log4j.properties [svn:mergeinfo]
java
com
company
client
project
adherent
persistence
AdherentDaoHibernateTest.java [svn:mergeinfo]
courrier
persistence
CourrierDaoHibernateTest.java [svn:mergeinfo]
codeobjet
persistence
CodeObjetDaoHibernateTest.java [svn:mergeinfo]
dossierstagiaire
persistence
DossierStagiaireDaoHibernateTest.java [svn:mergeinfo]
extranetof
src
main
filters
jse.filter.properties [svn:mergeinfo]


What I would normally expect is this:

trunk [svn:mergeinfo]
project
src
test
resources
log4j.properties
java
com
company
client
project
adherent
persistence
AdherentDaoHibernateTest.java
courrier
persistence
CourrierDaoHibernateTest.java
codeobjet
persistence
CodeObjetDaoHibernateTest.java
dossierstagiaire
persistence
DossierStagiaireDaoHibernateTest.java
extranetof
src
main
filters
jse.filter.properties


In the above case, the mergeinfo at the trunk root would contain the
superset of all mergeinfo you have spread all over the place right now.
There are several advantages in putting your mergeinfo at the branch root:

1) Merges perform better.
2) Merges are complete, in the sense that they have branch-wide scope,
rather than file-level scope. Not many version control tools even
support tracking merges made into subtrees of a branch (e.g. git
and mercurial do not track such merges).
3) It is easier to understand the mergeinfo if you're trying to find
out why a merge isn't working as expected
4) It is usually what people want and expect. So if you find mergeinfo
on folder or files other than the branch root, you know that you
are using an unusual merging pattern, and you should make sure you
know why you are using this pattern.

Now I'll stop lecturing and try to help you get out of the situation.

Post by Jean Seurin
svn: Reintegrate can only be used if revisions 6336 through 6393
were previously merged from $REPO/trunk/project to the reintegrate

So it is talking about $REPO/trunk/project. The mergeinfo there is:

Properties on '$REPO/trunk/project':
svn:mergeinfo
/branches/project-1.10:2344-2345,2347,2349,2351,2361,2363,2405
/branches/project-1.13:6266-6372
/branches/project-adptation-to-commons-1.1:1780-1790

There were merges done from 3 different branches into trunk/project.

Now let's see what Subversion thinks is missing in the reintegrate

Post by Jean Seurin
branches/project-dev/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java
Missing ranges: /trunk/project/src/test/java/com/company/client/project/adherent/persistence/AdherentDaoHibernateTest.java:6336-6389

This means that if you reintegrate the project-dev branch into trunk as
it is now, you will revert changes made to AdherentDaoHibernateTest.java
on trunk in 6336-6389.

Why this is depends on the mergeinfo on branches/project-dev (which I
cannot see right now but I can still give you suggestions that might help).

Let's try to concentrate on this one file first.
The other cases should be similar.
To continue, we'll need to know what the project-dev branch can still
receive from trunk. Subversion can tell us this, as follows:
svn mergeinfo --show-revs eligible $REPOS/trunk $REPOS/branches/project-dev

If this produces any output, it lists revisions which have made changes
to the trunk which the project-dev branch has not received yet.
To merge those revisions, get a working copy of the project-dev branch,
cd into it, and run:

svn merge ^/trunk

In TortoiseSVN, right-click on the root folder of the branch, and
select the first merge option, specify trunk as the source to merge
from, do *not* specify any revisions, and run the merge. You might
have to resolve conflicts. If you commit the result of this merge,
reintegrating the branch should work.

My suspicion is that because you did not merge into branch roots
but into individual files, you did not really merge all changes
between branches. But if you want to use reintegrate, the reintegrate
source needs to have soaked up a continuous range of revisions from
the target. Otherwise, the reintegrate merge would undo changes made
in the target.

To provide an abstract example:

[copy] [merge]
branch --------------------------
/ /
trunk ---rA---------------rX--------

The branch was created in rA. In rX, a merge was done from trunk
into the branch. This merge might have merged changes made to trunk
in one or more revisions between A and X. The catch is that if you want
to reintegrate the branch into trunk, *all* revisions between rA and rX
that touched the trunk must have been merged into the branch.
The reintegrate merge takes the difference between ***@X and ***@HEAD,
and applies this difference to the trunk. If the branch does not contain
changes made on trunk between A and X, those changes would be undone by
the reintegrate merge. This is why you get the error.

Below is a simple example where I reproduce this problem by making
two commits to the trunk in r3 and r4. I then only merge r4 from trunk
to the branch, so that r3 is missing. Trying to reintegrate the branch
into trunk results in the error you are seeing:

$ echo aaa > alpha
$ svn ci -mm
Sending alpha
Transmitting file data .
Committed revision 3.
$ echo bbb > beta
$ svn ci -mm
Sending beta
Transmitting file data .
Committed revision 4.
$ cd ../branch/
$ svn merge -c4 ^/trunk
--- Merging r4 into '.':
U beta
--- Recording mergeinfo for merge of r4 into '.':
U .
$ svn ci -mm
Sending .
Sending beta
Transmitting file data .
Committed revision 5.
$ cd ../trunk
$ svn up
At revision 5.
$ svn merge --reintegrate ^/branch
svn: Reintegrate can only be used if revisions 2 through 5 were previously merged from file:///tmp/svn-sandbox/repos/trunk to the reintegrate source, but this is not the case:
branch
Missing ranges: /trunk:3


I hope this helps you figure out how to get the branch reintegrated.
If you have more questions or trouble doing the merge, don't hesitate
to ask.

Stefan

[Stefan Sperling]

Post by Jean Seurin
Hi Stefan
first of all thanks for spending the time for this long thorough analysis.
1) I want to state that we're using a range of different SVN
clients, cli, Intellij Eclipse, mainly, and some people under
Windows may use Tortoise - bu those usually don't venture into
merges - yet.
I tought at first it could be the cause of the problem, since I have
had bad experiences with SVN clients on some IDEs.
But after reading through your whole analysis, I think I get where
[copy] [merge of bugfix r4 only]
release-branch-1.13--r2---r4------------------
/ \
trunk -----------r1----r3------r6------------------
\ \ \ / [--reintegrate not possible anymore]
feature-branch-dev-r5------r7---------
[copy] [merge] [merge]
Hope the drawing make sense: we have to merge back bug fix from
/release branch/ back to trunk. We don't really have to use merge
command for that, but some developer start to take a fancy into it
and uses it to merge a revision only, that corresponds to a bug fix.

Can you state which revisions were merged where in your example?
I guess r2 is the commit which was not merged back into trunk?
How was the merge from release-branch-1.13 to trunk in r6 done?

If you want all changes that happened in the release branch
merged to trunk, you can use --reintegrate for that, since the merge
is going into the opposite direction to the branch copy.
But there's a catch: if you want to reintegrate multiple times (to merge
more bufixes later), you have to use the trick described here:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice

Or you can do a cherry picking merge (grab one or more revisions
like your developer did). But cherry picking should only be done
into a single direction (mostly to keep things simple and prevent
developer insanity, but also because it makes merging with svn easier).
So if you ever cherry-picked one way, do not cherry pick the other way.

The canonical way to do the cherry-pick would be:
cd trunk-working-copy
svn merge -c 6 ^/release-branch-1.13

Post by Jean Seurin
If I follow you - and that would make sense - once this merge to
trunk makes its way to the /feature branch/, this one becomes not
'reintegratable' anymore.

It depends. I'm still not entirely sure I understand your example.
If you could describe how each of the merges was (reintegrate merge,
sync merge, cherry-pick merge) that would help.

Post by Jean Seurin
This use case appears to be quite regular to me. If it is not
possible to use it, it'd be better to know it before using /Feature
branch.

It is possible to use features branches and release branches at
the same time. Merging bug fixes from the release branch to the
trunk should not prevent reintegration of the feature branch.
That alone does not explain the problem.

I still think it's more likely that your problem is due to the
scattered subtree mergeinfo on trunk and possible the project-dev
branch. The mergeinfo shows "holes" in the merge history between
project-dev and trunk. These holes need to be filled before project-dev
is ready for reintegration.

I don't think a single cherry-picking merge from an unrelated branch
would cause this problem.

Post by Jean Seurin
/2) How can I solve my problem?
It seems from the reasoning above that the right solution would be
to do a complete merge of the Release branch 1.13 to the trunk -
instead of just a revision. I doubt that is possible for us.
If not, what are the options left? /

Making sure merges into your project-dev branch from trunk cover
a continuous revision range is your best option I think.

Post by Jean Seurin
/I want to get rid of the subtree mergeinfo - for those blocking
files, they seem to have been commited by mistake anyway- to keep
only the trunk root mergeinfo. Can I delete them manually?
If not how to get rid of subtree mergeinfo?

In general, do not delete mergeinfo yourself.
In some cases, where mergeinfo was created by accident (seems to be
the case in your situation), you can delete mergeinfo if and only if
there exists mergeinfo above it which is inheritable (does not have a *)
and is a superset of the mergeinfo below it.

E.g. this subtree mergeinfo is safe to delete:

trunk [svn:mergeinfo = branch1:r4-50, branch2:r30]
src
foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo

But this isn't safe to delete:

trunk [svn:mergeinfo = branch1:r4-50]
src
foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo

and this also isn't safe to delete:

trunk [svn:mergeinfo = branch1:r4-50*, branch2:r30*]
src
foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo

Have you tried the merges from trunk to the project-dev branch
I suggested in my last mail? What happened when you tried them?
Did they help?

Post by Jean Seurin
Even using the regular scenario, it seems some mergeinfo never
svn:mergeinfo
/branches/commons-opapl-dev:6352-6355
/branches/commons-client-test:6346-6349
These two branches were test feature branch: they have been
reintegrated and deleted already.
Is that regular for SVN to keep all those infos about deleted branches?

Yes, of course. It's part of the history of your repository.
Don't worry about that. That's totally fine. In fact, if you remove
those branches from mergeinfo you'll break commands like "svn log -g".

Post by Jean Seurin
3) I have long lasting development Feature branches that I don't see
any mention of in the mergeinfo. When are mergeinfo actually
created?

Mergeinfo is created at the merge target when you do a merge.

Stefan

[Jean Seurin]

Post by Stefan Sperling

Post by Jean Seurin
Hi Stefan
first of all thanks for spending the time for this long thorough analysis.
1) I want to state that we're using a range of different SVN
clients, cli, Intellij Eclipse, mainly, and some people under
Windows may use Tortoise - bu those usually don't venture into
merges - yet.
I tought at first it could be the cause of the problem, since I have
had bad experiences with SVN clients on some IDEs.
But after reading through your whole analysis, I think I get where
[copy] [merge of bugfix r4 only]
release-branch-1.13--r2---r4------------------
/ \
trunk -----------r1----r3------r6------------------
\ \ \ / [--reintegrate not possible anymore]
feature-branch-dev-r5------r7---------
[copy] [merge] [merge]
Hope the drawing make sense: we have to merge back bug fix from
/release branch/ back to trunk. We don't really have to use merge
command for that, but some developer start to take a fancy into it
and uses it to merge a revision only, that corresponds to a bug fix.

Can you state which revisions were merged where in your example?
I guess r2 is the commit which was not merged back into trunk?
How was the merge from release-branch-1.13 to trunk in r6 done?

You guessed right. I have been able to figure with the developer that
commited the problematic merge how he actually did it: he used a
"clever" integration function of Eclipse. He's got no clue what he did
really and I'm not using Eclipse so I dont' either. I guess I'm not
going to investigate further. I just told him to control hat he commits,
not to commit empty files, but revert them instead.

I've created a new Feature branch from the trunk and copied the few
commits by hand. It was faster in the end. But I'm really happy to have
learn so much thanks to you.

Post by Stefan Sperling
If you want all changes that happened in the release branch
merged to trunk, you can use --reintegrate for that, since the merge
is going into the opposite direction to the branch copy.
But there's a catch: if you want to reintegrate multiple times (to merge
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice

That's a very good one to know. I guess, almost all modifications made
on a Release branch (in our case at least) should made their way to the
trunk. Except the one made on the pom.xml when releasing.
As far as i can see, for this reason only we need to do cherry picking.

Post by Stefan Sperling
Or you can do a cherry picking merge (grab one or more revisions
like your developer did). But cherry picking should only be done
into a single direction (mostly to keep things simple and prevent
developer insanity, but also because it makes merging with svn easier).
So if you ever cherry-picked one way, do not cherry pick the other way.
cd trunk-working-copy
svn merge -c 6 ^/release-branch-1.13

Post by Jean Seurin
If I follow you - and that would make sense - once this merge to
trunk makes its way to the /feature branch/, this one becomes not
'reintegratable' anymore.

It depends. I'm still not entirely sure I understand your example.
If you could describe how each of the merges was (reintegrate merge,
sync merge, cherry-pick merge) that would help.

Post by Jean Seurin
This use case appears to be quite regular to me. If it is not
possible to use it, it'd be better to know it before using /Feature
branch.

It is possible to use features branches and release branches at
the same time. Merging bug fixes from the release branch to the
trunk should not prevent reintegration of the feature branch.
That alone does not explain the problem.

I'm very glad to know that, I was afraid that scenario wouldn't be
supported by SVN. We definitely need that for the reasons I mentioned above.

Post by Stefan Sperling
I still think it's more likely that your problem is due to the
scattered subtree mergeinfo on trunk and possible the project-dev
branch. The mergeinfo shows "holes" in the merge history between
project-dev and trunk. These holes need to be filled before project-dev
is ready for reintegration.
I don't think a single cherry-picking merge from an unrelated branch
would cause this problem.

Post by Jean Seurin
/2) How can I solve my problem?
It seems from the reasoning above that the right solution would be
to do a complete merge of the Release branch 1.13 to the trunk -
instead of just a revision. I doubt that is possible for us.
If not, what are the options left? /

Making sure merges into your project-dev branch from trunk cover
a continuous revision range is your best option I think.

Maybe o all the merges myself ! But that's a lot of work...

Post by Stefan Sperling

Post by Jean Seurin
/I want to get rid of the subtree mergeinfo - for those blocking
files, they seem to have been commited by mistake anyway- to keep
only the trunk root mergeinfo. Can I delete them manually?
If not how to get rid of subtree mergeinfo?

In general, do not delete mergeinfo yourself.
In some cases, where mergeinfo was created by accident (seems to be
the case in your situation), you can delete mergeinfo if and only if
there exists mergeinfo above it which is inheritable (does not have a *)
and is a superset of the mergeinfo below it.
trunk [svn:mergeinfo = branch1:r4-50, branch2:r30]
src
foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30]<- subtree mergeinfo
trunk [svn:mergeinfo = branch1:r4-50]
src
foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30]<- subtree mergeinfo
trunk [svn:mergeinfo = branch1:r4-50*, branch2:r30*]
src
foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30]<- subtree mergeinfo
Have you tried the merges from trunk to the project-dev branch
I suggested in my last mail? What happened when you tried them?
Did they help?

I've tried, but not working. SVN doesn't find anything to merge.
I've discovered the --record-only option in the Svn-book. It seems it
could help with my problem, but it seem dangerous to use and their
examples are not enough for me to be confident on using it.

Post by Stefan Sperling

Post by Jean Seurin
Even using the regular scenario, it seems some mergeinfo never
svn:mergeinfo
/branches/commons-opapl-dev:6352-6355
/branches/commons-client-test:6346-6349
These two branches were test feature branch: they have been
reintegrated and deleted already.
Is that regular for SVN to keep all those infos about deleted branches?

Yes, of course. It's part of the history of your repository.
Don't worry about that. That's totally fine. In fact, if you remove
those branches from mergeinfo you'll break commands like "svn log -g".

Post by Jean Seurin
3) I have long lasting development Feature branches that I don't see
any mention of in the mergeinfo. When are mergeinfo actually
created?

Mergeinfo is created at the merge target when you do a merge.
Stefan

Thanks a lot for the time spent.
Jean