[En-Nut-Discussion] devnut_m3n: Merging to trunk, the SVN way
Uwe Bonnes
in a tour-de-force approach, I single stepped through all trunk versions
since r3185 (last merge trunk-> branch) and merged trunk to branch. Sinle
step is needed, as svn merge only creates/moves/delets files and directories
when merging the exact version where the change took place. This
took about 25 seconds at best for each revision and much longer with many
files involved or when decisions about resolution of conflicts was
needed. Appended is a list of all resolutions to tree conflicts and file
conflicts I took. For resulting file conflicts, "MC" means I took the branch
version for the resolution, "E" means I edited the diff. "C" means a tree
conflict, mostly when trunk moved files and directories. When starting, I
mostly took the "MC" approach. Looking back I think editing would have been
better choice. However the list of files with file-conflicts is not too. So
manual control on these files could be an option.
Is this some approach we can work on? How should I proceed?
- No need to proceed, the approach is senseless?
- Show the diffs of the files with conflicts against trunk and original branch?
- Put up the merged branch somewhere
- Check-in the resulting 1700 changesets to branch in one batch?
If there is consense that the approach makes sense in our quest to merge
branch->trunk, I would even be willing to restart. Perhaps checking in
each merge result just before and just after some conflict was resolved
could make the review easier. This would give about 100 revisions in SVN for
the merge trunk->branch. Other ideas?
Bye
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
3185: Start
3188: MC devnut_m3n/nut/arch/arm/dev/dm9000e.c
3194: MC devnut_m3n/nut/tools/packaging/distcheck.lua
3260: E svn:ignore Use all files
3261: E devnut_m3n/nut/conf/at91sam7x-ek.conf Use additional item
D devnut_m3n/nut/Makevars.arm-gcc
3305: MC devnut_m3n/nut/app/led_key/pbtest.c
3306: MC devnut_m3n/nut/app/icmp-udp/icmp-udp.c
3307: MC devnut_m3n/nut/app/pppc/pppc.c
3308: E devnut_m3n/nut/app/Makefile
3310: C devnut_m3n/nut/tools/Xloader7
svn revert --depth infinity devnut_m3n/nut/tools/Xloader7
svn del --force devnut_m3n/nut/tools/Xloader7
3340: MC devnut_m3n/nut/tools/qnutconf/dirtraverser.cpp
MC devnut_m3n/nut/tools/qnutconf/mainwindow.cpp
MC devnut_m3n/nut/tools/qnutconf/dirtraverser.h
3341: MC devnut_m3n/nut/tools/qnutconf/dirtraverser.cpp
3342: MC devnut_m3n/nut/tools/qnutconf/mainwindow.h
MC devnut_m3n/nut/tools/qnutconf/mainwindow.cpp
C devnut_m3n/nut/tools/qnutconf/finddialog.cpp
C devnut_m3n/nut/tools/qnutconf/images/search_large.png
C devnut_m3n/nut/tools/qnutconf/finddialog.ui
C devnut_m3n/nut/tools/qnutconf/finddialog.h
svn revert
3344: MC devnut_m3n/nut/tools/qnutconf/mainwindow.cpp
3346: MC devnut_m3n/nut/app/pppc/pppc.c
3349: E devnut_m3n/nut/app/Makefile Use commented out
3360: MC devnut_m3n/nut/app/led_key/pbtest.c
3365: MC devnut_m3n/nut/app/led_key/pbtest.c
3370: C devnut_m3n/nut/boot/Xloader7/
svn revert --depth infinity devnut_m3n/nut/boot/Xloader7/
svn del --force devnut_m3n/nut/boot/Xloader7
3427: E devnut_m3n/nut/conf/tools.nut
nuttools_gccopt section added
3428: E devnut_m3n/nut/doc/gen/nut_en.cfg.in
Longer directory list from wroking taken
3449: C devnut_m3n/nut/arch/arm/dev/at91_emac.c
C devnut_m3n/nut/arch/arm/dev/at91sam7x_emac.c
C devnut_m3n/nut/arch/arm/dev/gpio_at91.c
C devnut_m3n/nut/arch/arm/dev/at91_twi.c
Copy version from arm/dev/ to arm/dev/atmel
svn revert /svn delete version in arm/dev
3469: E devnut_m3n/nut/arch/arm/dev/atmel/at91_emac.c
Use symbolic constants
3470: E devnut_m3n/nut/os/timer.c
3524: C devnut_m3n/nut/Makerules.arm-ecross-gccdbg
C devnut_m3n/nut/Makedefs.arm-ecross-gcc
C devnut_m3n/nut/Makedefs.arm-ecross-gcc
svn revert/ scn del
3525: C devnut_m3n/nut/app/Makerules.arm-ecross-gcc
C devnut_m3n/nut/app/Makedefs.arm-ecross-gccdbg
C devnut_m3n/nut/app/Makedefs.arm-ecross-gcc
svn revert
3527: C devnut_m3n/nut/Makerules.arm-ecross-gcc
C devnut_m3n/nut/Makedefs.arm-ecross-gccdbg
svn revert
3528: C devnut_m3n/nut/app/Makerules.arm-ecross-gccdbg
C devnut_m3n/nut/app/Makevars.arm-ecross-gcc
svn revert
3529: svn:ignore Use all files
3586: svn:ignore Use all files
3587: svn:ignore Use all files
3588: svn:ignore Use all files
3589: svn:ignore Use smaller selection (only qnutconf.exe)
C devnut_m3n/nut/app/eeprom
> lokal editiert, eingehend gelöscht bei Zusammenführung
C devnut_m3n/nut/app/ioexpander
> lokal editiert, eingehend gelöscht bei Zusammenführung
C devnut_m3n/nut/app/canbus
> lokal editiert, eingehend gelöscht bei Zusammenführung
C devnut_m3n/nut/app/led_key
> lokal editiert, eingehend gelöscht bei Zusammenführung
svn revert --depth infinity/svn del --force
References in devnut_m3n/nut/app/Makefile removed
3604: E devnut_m3n/nut/conf/dev/dev.nut
macro = "FLASH_CONF_SECTOR":
default = "0x6000",
file = "include/cfg/memory.h"
choosen
3611: devnut_m3n/nut/app/Makefile
Choose cm3 related files
3618: E devnut_m3n/nut/conf/repository.nut
choose all devices
3630: C devnut_m3n/nut/Makedefs.gcc
> lokal editiert, eingehend gelöscht bei Zusammenführung
svn del devnut_m3n/nut/Makedefs.gcc
3634: E devnut_m3n/nut/dev/dm9000.c
#include <dev/irqreg.h>
<<<<<<< .working
#include <dev/phy.h>
#include <dev/dm9000e.h>
=======
#include <dev/dm9000.h>
>>>>>>> .merge-rechts.r3634
Choose working
3656: Edevnut_m3n/nut/os/nutinit.c
<<<<<<< .working
#elif defined(__arm__) && defined(__CORTEX__)
#include "../arch/cm3/os/nutinit_cm3.c"
=======
#endif
>>>>>>> .merge-rechts.r3656
Choose working
E devnut_m3n/nut/conf/tools.nut
<<<<<<< .working
return basepath .. "arm/ldscripts"
=======
if c_is_provided("HW_MCU_LPC1700") then
return basepath .. "arm/lpc/lpc1700/ldscripts/$(LDNAME).ld"
else
return basepath .. "arm/ldscripts/$(LDNAME).ld"
end
>>>>>>> .merge-rechts.r3656
Choose rechts
E devnut_m3n/nut/include/arch/timer.h
#ifdef __NUT_EMULATION__
#include <arch/unix/timer.h>
#elif defined(__AVR__)
#include <arch/avr/timer.h>
#elif defined(__arm__) && !defined(__CORTEX__)
#if defined(__ARM_ARCH_7M__)
#include <arch/arm/lpc/lpc1700/timer.h>
#else
#include <arch/arm/timer.h>
<<<<<<< .working
#elif defined(__arm__) && defined(__CORTEX__)
#include <arch/cm3/timer.h>
=======
#endif
>>>>>>> .merge-rechts.r3656
#elif defined(__AVR32__)
#include <arch/avr32/timer.h>
#elif defined(__H8300H__) || defined(__H8300S__)
#include <arch/h8300h/timer.h>
#elif defined(__m68k__)
#include <arch/m68k/timer.h>
#endif
Edit to
#ifdef __NUT_EMULATION__
#include <arch/unix/timer.h>
#elif defined(__AVR__)
#include <arch/avr/timer.h>
#elif defined(__CORTEX__)
#include <arch/cm3/timer.h>
#elif defined(__arm__) && !defined(__CORTEX__)
#if defined(__ARM_ARCH_7M__)
#include <arch/arm/lpc/lpc1700/timer.h>
#else
#include <arch/arm/timer.h>
#endif
#elif defined(__AVR32__)
#include <arch/avr32/timer.h>
#elif defined(__H8300H__) || defined(__H8300S__)
#include <arch/h8300h/timer.h>
#elif defined(__m68k__)
#include <arch/m68k/timer.h>
#endif
E devnut_m3n/nut/include/dev/irqreg.h
as above
E devnut_m3n/nut/include/sys/atom.h
as above
3660:C devnut_m3n/nut/app/playmp3
C devnut_m3n/nut/app/playmp3
> lokal editiert, eingehend gelöscht bei Zusammenführung
devel/merge> svn status devnut_m3n/ | less
devel/merge> svn revert --depth infinity devnut_m3n/nut/app/playmp3
3670: E devnut_m3n/nut/doc/gen/nut_en.cfg.in
Choose right(
3683: E devnut_m3n/nut/net/ifconfig.c
Remove BSD clause
3695:
M C devnut_m3n/nut/include/cfg/sht21.h
> lokal hinzugefügt, eingehend hinzugefügt bei Zusammenführung
M C devnut_m3n/nut/include/cfg/mma745x.h
> lokal hinzugefügt, eingehend hinzugefügt bei Zusammenführung
M C devnut_m3n/nut/include/dev/mma745x.h
> lokal hinzugefügt, eingehend hinzugefügt bei Zusammenführung
M C devnut_m3n/nut/include/dev/sht21.h
> lokal hinzugefügt, eingehend hinzugefügt bei Zusammenführung
svn revert
3723: devnut_m3n/nut/dev/eeprom.c
<<<<<<< .working
at24c32s.PageSize = AT24C_ROW_SIZE;
at24c32s.EepromSize = AT24C_CHIP_SIZE;
=======
at24c32s.PageSize = 32;
at24c32s.EepromSize = 32*128;
>>>>>>> .merge-rechts.r3723
Choose working
3786: E devnut_m3n/configure.ac
<<<<<<< .working
AC_INIT(ethernut,4.99.0)
=======
AC_INIT(ethernut,5.0.1)
>>>>>>> .merge-rechts.r3786
Choose rechts
3841: C devnut_m3n/nut/tools/qnutconf/images
> lokal editiert, eingehend gelöscht bei Zusammenführung
M C devnut_m3n/nut/tools/qnutconf/dirtraverser.cpp
> lokal editiert, eingehend gelöscht bei Zusammenführung
svn revert , svn del --force
3891:A + C devnut_m3n/nut/include/uhttp
> lokal editiert, eingehend gelöscht bei Zusammenführung
svn revert --depth infinity /svn del --force
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ole Reinhardt
> in a tour-de-force approach, I single stepped through all trunk versions
> since r3185 (last merge trunk-> branch) and merged trunk to branch. Sinle
> step is needed, as svn merge only creates/moves/delets files and directories
> when merging the exact version where the change took place. This
> took about 25 seconds at best for each revision and much longer with many
> files involved or when decisions about resolution of conflicts was
> needed. Appended is a list of all resolutions to tree conflicts and file
> conflicts I took. For resulting file conflicts, "MC" means I took the branch
> version for the resolution, "E" means I edited the diff. "C" means a tree
> conflict, mostly when trunk moved files and directories. When starting, I
> mostly took the "MC" approach. Looking back I think editing would have been
> better choice. However the list of files with file-conflicts is not too. So
> manual control on these files could be an option.
>
> Is this some approach we can work on? How should I proceed?
>
> - No need to proceed, the approach is senseless?
> - Show the diffs of the files with conflicts against trunk and original branch?
> - Put up the merged branch somewhere
> - Check-in the resulting 1700 changesets to branch in one batch?
Please do _not_ just merge anything to the branch. Otherwise this could
end up in a non working source tree at all. And I realy need a working
tree at the moment, as we develop here for a customers project. So
please _do not break_ any current source tree.
The right way would be to create a new branch from the current
devnut_m3n and to merge in trunk to this branch.
For sure you could also create a new branch from trunk and merge the
devnut_m3n branch to this new branch.
> If there is consense that the approach makes sense in our quest to merge
> branch->trunk, I would even be willing to restart. Perhaps checking in
> each merge result just before and just after some conflict was resolved
> could make the review easier. This would give about 100 revisions in SVN for
> the merge trunk->branch. Other ideas?
I think we should relay go the way to first discuss these topics with
Ulrich and Harald in a meeting and perhaps do the merger all together
during this meeting.
When reviewing your list below I think there a lots of obsolete
conflicts where we could easily stay with the files from trunk (so no
need to merge them).
I would prefer to go the following way:
Create a branch from trunk
==> trunk_tmp
Then merge changes from devnut_m3n branch file by file and decide for
every file if we need to merge it or not. If there is a real conflict
(as both sides edited anything) we will have to cleanup this conflict by
hand.
Btw: Ulrich did some updates from trunk later too! e.g. see
r3359 | Astralix | 2011-04-20 21:59:12 +0200 (Mi, 20. Apr 2011) | 1
Zeile
STM32 devnut_m3n: Updated app from trunk
When I go through your list below I think most problems result either
from moved files (we would need to merge / copy them by hand). Only very
few files have realy been changed in the devnut_m3n branch. These are
some ethernet drivers (which use Ulrichs generic PHY implementation in
the devnut_m3n branch), some changes/additions on the GPIO api some
Make- and related files, perhaps some TWI implementations and the
different .conf and .nut files, and a very few other files, right?
So in total it should not be that much, if we do the change file by file
and think about each file twice.
What do you (and the others) think?
Bye,
Ole
--
Thermotemp GmbH, Embedded-IT
Embedded Hard-/ Software and Open Source Development,
Integration and Consulting
Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97
Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ulrich Prinz
>>
>> Is this some approach we can work on? How should I proceed?
>>
>> - No need to proceed, the approach is senseless?
>> - Show the diffs of the files with conflicts against trunk and original branch?
>> - Put up the merged branch somewhere
>> - Check-in the resulting 1700 changesets to branch in one batch?
>
> Please do _not_ just merge anything to the branch. Otherwise this could
> end up in a non working source tree at all. And I realy need a working
> tree at the moment, as we develop here for a customers project. So
> please _do not break_ any current source tree.
>
I already copied the devnut_m3n branch to a local repository server to
avoid that...
>
> The right way would be to create a new branch from the current
> devnut_m3n and to merge in trunk to this branch.
>
Right:
Uwe consider the following steps:
Checkout a fresh copy from devnut_m3n
Branch this to i.e. dev_uwe_cm3integration and, important!, switch this
copy to this new branch.
( or use repository tools to copy devnut_m3n to dev_uwe_cm3integration
and checkout that branch directly)
> For sure you could also create a new branch from trunk and merge the
> devnut_m3n branch to this new branch.
>
And in opposite to that, merge all newer revisions from trunk to the
branch. Where newer means everything that is newer in trunk compared to
devnut_m3n is now merged to dev_uwe_cm3integration.
>
After that you start to compile for all and any supported platform and
check for errors, warnings and so on.
If that then works, you can do a merge from your branch to trunk.
> I think we should relay go the way to first discuss these topics with
> Ulrich and Harald in a meeting and perhaps do the merger all together
> during this meeting.
>
> When reviewing your list below I think there a lots of obsolete
> conflicts where we could easily stay with the files from trunk (so no
> need to merge them).
There are some that need some simple #define handling as they are not
applicable for AVR and such.
>
> I would prefer to go the following way:
>
> Create a branch from trunk
>
> ==> trunk_tmp
>
Right. Never reintegrate such big changes directly to trunk, but fake a
trunk and integrate there.
Best regards
Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
On 11.03.2012 15:21, Ole Reinhardt wrote:
> Please do _not_ just merge anything to the branch. Otherwise this could
> end up in a non working source tree at all. And I realy need a working
> tree at the moment, as we develop here for a customers project. So
> please _do not break_ any current source tree.
Hope, you meant to the devnut_m3n branch. Although temporarily, I may
already broke the trunk and likely other significant changes may follow.
I assume, that the instable phase may last for 2 to 3 weeks. If this is
not acceptable for you (or anyone else), I can switch to a branch. But
would prefer to avoid this additional step.
Regards,
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ulrich Prinz
> not acceptable for you (or anyone else), I can switch to a branch. But
> would prefer to avoid this additional step.
>
We have a lot of troubles by merging from branch to branch whlie
integration of trunk on the fly and then merge back to trunk, while
you like to avoid all that work and just run the easy way blowing up
trunk...
How about the good guys walking in the front line and showing the
_good_ examples...
SCNR Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Uwe Bonnes
Ulrich> Right: Uwe consider the following steps: Checkout a fresh copy
Ulrich> from devnut_m3n Branch this to i.e. dev_uwe_cm3integration and,
Ulrich> important!, switch this copy to this new branch.
Do I have appropriate rights on sourceforge?
Ulrich> ( or use repository tools to copy devnut_m3n to
Ulrich> dev_uwe_cm3integration and checkout that branch directly)
>> For sure you could also create a new branch from trunk and merge the
>> devnut_m3n branch to this new branch.
>>
Ulrich> And in opposite to that, merge all newer revisions from trunk to
Ulrich> the branch. Where newer means everything that is newer in trunk
Ulrich> compared to devnut_m3n is now merged to dev_uwe_cm3integration.
>>
Ulrich> After that you start to compile for all and any supported
Ulrich> platform and check for errors, warnings and so on.
Ahm, I can do some test for AVR and STM32, but that's all.
After integration help and review from others is needed.
When checking in revisions from trunk, should I check in the results after
resolving conflicts or should all happen one single step. I think the first
solution is better, but it will create a lot of clutter in the log.
Bye
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Uwe Bonnes
(resent, as there was no reaction until now)
>>>>> "Ulrich" == Ulrich Prinz <ulrich...@googlemail.com> writes:
Ulrich> Right: Uwe consider the following steps: Checkout a fresh copy
Ulrich> from devnut_m3n Branch this to i.e. dev_uwe_cm3integration and,
Ulrich> important!, switch this copy to this new branch.
Do I have appropriate rights on sourceforge?
Ulrich> ( or use repository tools to copy devnut_m3n to
Ulrich> dev_uwe_cm3integration and checkout that branch directly)
>> For sure you could also create a new branch from trunk and merge the
>> devnut_m3n branch to this new branch.
>>
Ulrich> And in opposite to that, merge all newer revisions from trunk to
Ulrich> the branch. Where newer means everything that is newer in trunk
Ulrich> compared to devnut_m3n is now merged to dev_uwe_cm3integration.
>>
Ulrich> After that you start to compile for all and any supported
Ulrich> platform and check for errors, warnings and so on.
Ahm, I can do some test for AVR and STM32, but that's all.
After integration help and review from others is needed.
When checking in revisions from trunk, should I check in the results after
resolving conflicts or should all happen one single step? I think the first
Harald Kipp
On 15.03.2012 09:56, Ulrich Prinz wrote:
> We have a lot of troubles by merging from branch to branch whlie
> integration of trunk on the fly and then merge back to trunk, while
> you like to avoid all that work and just run the easy way blowing up
> trunk...
While there may be a high impact on the code, the changes are quite
limited and simple.
For example, I shifted the pointer to the NETBUF by 2 bytes to get the
IP part of the packet 32 bit aligned. This may increase the network
throughput by three of more times, but it may also break the complete
TCP stack, if I overlooked something. In that case a single command can
revert this change.
> How about the good guys walking in the front line and showing the
> _good_ examples...
Hey, I was the guy who asked the experts for help with SVN branching.
Now the experts are in trouble, asking me to provide a _good_ example?
Jo, jo... ;-)
Seriously, over the time I became quite familiar with this stuff. And I
recognized, that the m3n branch was not maintained well in regards of
trunk synchronization. Though, I understand, that the main goal was to
get the Cortex M3 running, where you and the other contributors did a
great job. These little out-of-sync-problems are no big deal.
Ole Reinhardt
> >>>>> "Ulrich" == Ulrich Prinz <ulrich...@googlemail.com> writes:
>
> Ulrich> Right: Uwe consider the following steps: Checkout a fresh copy
> Ulrich> from devnut_m3n Branch this to i.e. dev_uwe_cm3integration and,
> Ulrich> important!, switch this copy to this new branch.
>
> Do I have appropriate rights on sourceforge?
I just checked your permissions. AFAIK they should be ok to create a new
branch by using (all in one line
svn copy
https://u_bo...@ethernut.svn.sourceforge.net/svnroot/ethernut/trunk \
https://u_bo...@ethernut.svn.sourceforge.net/svnroot/ethernut/branches/devnut_uwe_cm3integration
svn co
https://u_bo...@ethernut.svn.sourceforge.net/svnroot/ethernut/branches/devnut_uwe_cm3integration
devnut_uwe_cm3integration
The newly created devnut_uwe_cm3integration directory now contains the
newly created branch working copy.
> Ulrich> ( or use repository tools to copy devnut_m3n to
> Ulrich> dev_uwe_cm3integration and checkout that branch directly)
>
> >> For sure you could also create a new branch from trunk and merge the
> >> devnut_m3n branch to this new branch.
> >>
> Ulrich> And in opposite to that, merge all newer revisions from trunk to
> Ulrich> the branch. Where newer means everything that is newer in trunk
> Ulrich> compared to devnut_m3n is now merged to dev_uwe_cm3integration.
> >>
> Ulrich> After that you start to compile for all and any supported
> Ulrich> platform and check for errors, warnings and so on.
>
> Ahm, I can do some test for AVR and STM32, but that's all.
>
> After integration help and review from others is needed.
No problem.
Btw: I also planned to give it a try and to create an own trunk
integration branch at weekend.
> When checking in revisions from trunk, should I check in the results after
> resolving conflicts or should all happen one single step? I think the first
> solution is better, but it will create a lot of clutter in the log.
First you should only work on the devnut_uwe_cm3integration branch which
is then a fresh copy of trunk. There you will merge file by file from
devnut_m3n and resolve conflict by conflict.
Do a checkin if everything got cleanly resolved. Always try to correctly
decide which changes are of interest. Only merge changes from devnut_m3n
to trunk if these are really part of the cortex development or related
changes (e.g. phy driver, changes on the rtc api) etc. If there are
questions on single files / changes, don't hesitate to ask.
If this is all ok, we will need to review it. Then we can merge
everything back into trunk.
But as mentioned before I will also try a merge, latest at the weekend.
We could either compare our results before merging back to trunk or you
just wait a few days until I'm ready if you are unsure how to proceed.
Uwe Bonnes
...
>> Do I have appropriate rights on sourceforge?
Ole> I just checked your permissions. AFAIK they should be ok to create
Ole> a new branch by using (all in one line
Okay!
...
Ole> Btw: I also planned to give it a try and to create an own trunk
Ole> integration branch at weekend.
I am on tour this weekend, so no time for a merge that soon.
>> When checking in revisions from trunk, should I check in the results
>> after resolving conflicts or should all happen one single step? I
>> think the first solution is better, but it will create a lot of
>> clutter in the log.
Ole> First you should only work on the devnut_uwe_cm3integration branch
Ole> which is then a fresh copy of trunk. There you will merge file by
Ole> file from devnut_m3n and resolve conflict by conflict.
So you propose _not_ to go step by step for each branch revision, but do the
merge more on a file by file base! However this will loose all svn history
of the cm3 branch!
Ole> Do a checkin if everything got cleanly resolved. Always try to
Ole> correctly decide which changes are of interest. Only merge changes
Ole> from devnut_m3n to trunk if these are really part of the cortex
Ole> development or related changes (e.g. phy driver, changes on the rtc
Ole> api) etc. If there are questions on single files / changes, don't
Ole> hesitate to ask.
There are some changes Ulrich did outside of the scope of CM3 that I didn't
see redone on the branch side. This is the area of most conflicts.
Ole> If this is all ok, we will need to review it. Then we can merge
Ole> everything back into trunk.
Ole> But as mentioned before I will also try a merge, latest at the
Ole> weekend. We could either compare our results before merging back
Ole> to trunk or you just wait a few days until I'm ready if you are
Ole> unsure how to proceed.
We can compare result with the tree I produces about two weeks ago. But
probably not with a tree produced as you outlined above.
Seeing alls these problems, I propose a switch to git as soon as possible
after the merge.
Ole Reinhardt
> Ole> First you should only work on the devnut_uwe_cm3integration branch
> Ole> which is then a fresh copy of trunk. There you will merge file by
> Ole> file from devnut_m3n and resolve conflict by conflict.
>
> So you propose _not_ to go step by step for each branch revision, but do the
> merge more on a file by file base! However this will loose all svn history
> of the cm3 branch!
Why shall we loose the history of the CM3 branch? If you do a merge with
svn merge -r x:y file_from_cm3_brach branches/new_trunk_copy_branch
And after all files are merged, do a single
svn ci
we won't loose any history, won't we?
What would be your alternative?
> Ole> Do a checkin if everything got cleanly resolved. Always try to
> Ole> correctly decide which changes are of interest. Only merge changes
> Ole> from devnut_m3n to trunk if these are really part of the cortex
> Ole> development or related changes (e.g. phy driver, changes on the rtc
> Ole> api) etc. If there are questions on single files / changes, don't
> Ole> hesitate to ask.
>
> There are some changes Ulrich did outside of the scope of CM3 that I didn't
> see redone on the branch side. This is the area of most conflicts.
Right. I did some further changes too.
> Ole> If this is all ok, we will need to review it. Then we can merge
> Ole> everything back into trunk.
>
> Ole> But as mentioned before I will also try a merge, latest at the
> Ole> weekend. We could either compare our results before merging back
> Ole> to trunk or you just wait a few days until I'm ready if you are
> Ole> unsure how to proceed.
>
> We can compare result with the tree I produces about two weeks ago. But
> probably not with a tree produced as you outlined above.
>
> Seeing alls these problems, I propose a switch to git as soon as possible
> after the merge.
I Totally agree.
Uwe Bonnes
Ole> Hi Uwe, First you should only work on the devnut_uwe_cm3integration
Ole> branch which is then a fresh copy of trunk. There you will merge
Ole> file by file from devnut_m3n and resolve conflict by conflict.
>> So you propose _not_ to go step by step for each branch revision,
>> but do the merge more on a file by file base! However this will loose
>> all svn history of the cm3 branch!
Ole> Why shall we loose the history of the CM3 branch? If you do a merge
Ole> with
Ole> svn merge -r x:y file_from_cm3_brach branches/new_trunk_copy_branch
Ah! As you point out here, svn can do a merge on a file by file base. I
didn't know about that option.
Ole> And after all files are merged, do a single
Ole> svn ci
Ole> we won't loose any history, won't we?
It looks like that way we don't loose history!
Ole> What would be your alternative?
No alternative needed. Only more knowledge about SVN on my side ;-)
Uwe Bonnes
Ole> But as mentioned before I will also try a merge, latest at the
Ole> weekend. We could either compare our results before merging back
Ole> to trunk or you just wait a few days until I'm ready if you are
Ole> unsure how to proceed.
Did you find time to start your test? Weather was very fine last weekend...
Is there any update on a possible meeting?
Ole Reinhardt
> Did you find time to start your test? Weather was very fine last weekend...
Yes, I just have done 90%. I therefore created
branches/dev_cm3_integration
from trunk and merged in the changes from devnut_m3n. There are only a
few files left over. Please be patient :) Hopefully I'll get it
completed today.
Please don't modify the branch until further notice. Just use it for
testing.
As a help I created a verbose svn log of the devnut_m3n branch. So I was
able to see which file was modified at what time. This helped a lot and
I crossed out every file in the List which I just completely merged.
I had to remove (disable) the arch/arm/lpc implementation as it will be
integrated to arch/cm3/nxp
The next step then would be intensive testing with the different
platforms, especially as there are also some minor changes on other
architectures.
I will write a note here if I'm ready with merging.
When all tests finished we will then do a
svn merge --reintegrate of the dev_cm3_integration branch into trunk.
> Is there any update on a possible meeting?
Unfortunately I did not get any answer from Ulrich yet.