On Mon, May 10, 2010 at 07:45:07PM +0800, Jean Seurin wrote:
> 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.
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.
> 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:
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
source (the project-dev branch):
> 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 trunk_at_X and branch_at_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
Received on 2010-05-10 19:34:06 CEST