You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jean Seurin <je...@gmail.com> on 2010/05/06 10:18:07 UTC

Cannot reintegrate feature branch

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

Re: Fwd: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
Hi Stefan,

it actually does not appear in mergeinfo.

thanks
Jean

On Thu, May 6, 2010 at 7:11 PM, Stefan Sperling <st...@elego.de> wrote:

> On Thu, May 06, 2010 at 06:49:51PM +0800, Jean Seurin wrote:
> > 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
>

Re: Fwd: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 06, 2010 at 06:49:51PM +0800, Jean Seurin wrote:
> 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

Fwd: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
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 <je...@gmail.com>
Date: Thu, May 6, 2010 at 6:18 PM
Subject: Cannot reintegrate feature branch
To: users@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

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 07, 2010 at 02:16:20PM +0200, Stefan Sperling wrote:
> On Fri, May 07, 2010 at 11:35:16AM +0800, Jean Seurin wrote:
> > 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

Re: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
Stefan Sperling wrote:
> On Tue, May 11, 2010 at 12:06:50PM +0800, Jean Seurin wrote:
>    
>> 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
>> the problem comes from. Here's our setup right now:
>>
>>             [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.
> 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
>
>    
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.
> 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
>
>    
>> 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.
>
>    
>> 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.
> 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.
>
>    
>> /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...
>> /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?
>
>    
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.
>> Even using the regular scenario, it seems some mergeinfo never
>> disappear. For instance:
>>
>> Properties on '$REPO/trunk/commons-client':
>>    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".
>
>    
>> 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

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 11, 2010 at 12:06:50PM +0800, Jean Seurin wrote:
> 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
> the problem comes from. Here's our setup right now:
> 
>            [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
 
> 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.

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

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

> /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?

> Even using the regular scenario, it seems some mergeinfo never
> disappear. For instance:
> 
> Properties on '$REPO/trunk/commons-client':
>   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".

> 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

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
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@X and branch@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

Re: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
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

Stefan Sperling wrote:
> On Mon, May 10, 2010 at 07:16:37PM +0800, Jean Seurin wrote:
>    
>> 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.
>
> For instance, this will list all mergeinfo within the trunk:
>    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
>    

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Mon, May 10, 2010 at 12:08:15PM +0800, Jean Seurin wrote:
> 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.

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

Re: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
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

Stefan Sperling wrote:
> On Fri, May 07, 2010 at 11:35:16AM +0800, Jean Seurin wrote:
>    
>> 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
>    

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 07, 2010 at 11:35:16AM +0800, Jean Seurin wrote:
> 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

Re: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
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

Stefan Sperling wrote:
> On Thu, May 06, 2010 at 01:36:04PM +0200, Stefan Sperling wrote:
>    
>> You want mergeinfo like this:
>>
>>    /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
>    

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 06, 2010 at 01:36:04PM +0200, Stefan Sperling wrote:
> You want mergeinfo like this:
> 
>   /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

Re: Cannot reintegrate feature branch

Posted by Jean Seurin <je...@gmail.com>.
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

Stefan Sperling wrote:
> On Thu, May 06, 2010 at 06:18:07PM +0800, Jean Seurin wrote:
>    
>> Hi,
>>
>> I just persuaded my organisation to give a try to Feature Branch.
>>
>> After 3 merges only,
>>      
>
> What 3 merges precisely?
>
>    
>> 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
>>      
>
> 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
>
>    
>> 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.
>>      
>
> 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?
>
>    
>> 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
>    

Re: Cannot reintegrate feature branch

Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 06, 2010 at 06:18:07PM +0800, Jean Seurin wrote:
> Hi,
> 
> I just persuaded my organisation to give a try to Feature Branch.
> 
> After 3 merges only,

What 3 merges precisely?

> 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

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

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

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?

> 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