You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Olivier Sannier <ob...@free.fr> on 2010/01/27 08:49:15 UTC
Reintegrate with vendor branches
Hello all,
Let's consider the following repository structure :
tags
branches
feature1
trunk
libs
libA
libB
project1
vendors
libA
current
libB
current
The repository is at revision 100
libA and libB are external libraries managed as vendor branches which
were merged twice each into the trunk since its beginning. This means
that the following mergeinfo is on trunk/libs/libA :
/vendors/libA/current:25,30
and the following on trunk/libs/libB:
/vendors/libB/current:28,36
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.
This was done with version 1.6.6 clients
Do you think this is a bug?
If yes, is it already reported and/or a fix available?
If not, what have I done wrong to get to this situation?
Regards
Olivier
Re: Reintegrate with vendor branches
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Wednesday 03 February 2010, Olivier Sannier wrote:
> Ulrich Eckhardt wrote:
> > 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.
>
> I can't use svn:external because I have local modifications that are not
> in the public versions of those libs.
> In the end, I'll have to keep an eye on my users.
No, that's not what I meant. I meant that you point the svn:external to a URL
inside your own repository, where you have the (modified) version of the
vendor sources.
Uli
--
FAQ: http://subversion.tigris.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.
**************************************************************************************
Re: Reintegrate with vendor branches
Posted by Olivier Sannier <ob...@free.fr>.
Ulrich Eckhardt wrote:
> 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.
>
Yes, that's pretty much the conclusion I came up to as well. I'll have
to go around and tell the users to remember to commit everything. And I
agree that a better design would help avoiding the confusion, even
though I'm not sure what this design could look like.
> 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.
>
I can't use svn:external because I have local modifications that are not
in the public versions of those libs.
In the end, I'll have to keep an eye on my users.
Regards
Olivier
Re: Reintegrate with vendor branches
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
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.
**************************************************************************************
Re: Reintegrate with vendor branches
Posted by Olivier Sannier <ob...@free.fr>.
Olivier Sannier wrote:
> Hello all,
>
> Let's consider the following repository structure :
>
> tags
> branches
> feature1
> trunk
> libs
> libA
> libB
> project1
> vendors
> libA
> current
> libB
> current
>
> The repository is at revision 100
> libA and libB are external libraries managed as vendor branches which
> were merged twice each into the trunk since its beginning. This means
> that the following mergeinfo is on trunk/libs/libA :
> /vendors/libA/current:25,30
>
> and the following on trunk/libs/libB:
> /vendors/libB/current:28,36
>
> 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.
> This was done with version 1.6.6 clients
>
> Do you think this is a bug?
> If yes, is it already reported and/or a fix available?
> If not, what have I done wrong to get to this situation?
>
> Regards
> Olivier
>
>
I wonder if this message was seen, or if I missed some answers.
Does anyone have any clue?
Thanks
Olivier