[En-Nut-Discussion] devnut_m3n: Merging to trunk, the SVN way

Ole Reinhardt ole.reinhardt at embedded-it.de
Sun Mar 11 15:21:31 CET 2012

Hi Uwe,

> 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

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

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?




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 

More information about the En-Nut-Discussion mailing list