On Tuesday 02 February 2010, Olivier Sannier wrote:
> tags
> branches
> feature1
> trunk
> libs
> libA
> libB
> project1
> vendors
> libA
> current
> libB
> current
[...]
> the feature1 branch was created as a copy of /trunk at revision 45 and
> changes from trunk were regularly merged into it which gives the
> following merge info on /branches/feature1:
> /trunk:45-99
>
> The last final merge from trunk being done in revision 100.
> Now I want to reintegrate the feature branch back into trunk but I get
> the an error message saying that it is unable to reintegrate because
> some revisions are missing on the branch:
>
> /branches/feature1/libs/libA is missing /trunk/libs/libA:45-99
> /branches/feature1/libs/libB is missing /trunk/libs/libB:45-99
>
> I don't understand why it complains as all changes are already in
> since they were merged before the feature branch was created.
> Adding the above two paths and revision numbers in the merge infos for
> libA and libB allows to reintegrate but I would prefer if this could
> be avoided.
When you create the branch, you have
branches/
feature1/
libA/ mergeinfo:/vendors/libA/current:25,30
When you now merge from trunk, you will have
branches/
feature1/ mergeinfo:/trunk:45-99
libA/ mergeinfo:/vendors/libA/current:25,30
/trunk:45-99
IOW, the '/trunk:45-99' will both be attached to the 'branches/feature1'
folder and additionally to the 'branches/feature1/libA' folder. If you now
commit only the former (or revert the latter), thinking that you didn't
change anything in the 'libA' folder, you simply mess up the merge
information.
Check if while merging you omitted changing the mergeinfo in the 'libA'
folder. If so, that's probably a human error. Adding the missing info
manually is the right way to go.
Actually, the fact that merging to X changes the mergeinfo in subdir Y that
wasn't touched is a common source of confusion. There are two ways out:
1. Educate the users. They must understand that these separate mergeinfo
properties are actually necessary. Yes, a better design could perhaps fix
that, but that is not the status quo.
2. Merge to the root of the project only. This avoids having subdirs with
differing mergeinfos. This is a bit difficult in your project, because it
contains the libs which are otherwise on the same "level", i.e. projects
themselves. What you should consider is not having copies of the libs in your
main project but references. The closest to the current state would be to use
svn:external to reference the libs. That way, the mergeinfo of both your
project and the external libs wouldn't be mixed but stay apart.
Uli
--
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen,
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht
verantwortlich.
**************************************************************************************
