[svn] merge to release HOWTO?
I clearly am doing something wrong when it comes to merging changes from trunk to release. I feel that as one of the release managers, this is something I should know. :-P Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way. But look at the result of my most recent merge: https://svn.boost.org/trac/boost/changeset/58336 The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way? -- Eric Niebler BoostPro Computing http://www.boostpro.com
AMDG Eric Niebler wrote:
I clearly am doing something wrong when it comes to merging changes from trunk to release. I feel that as one of the release managers, this is something I should know. :-P Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way. But look at the result of my most recent merge:
https://svn.boost.org/trac/boost/changeset/58336
The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way?
What you're doing is fine. The property changes should all be svn:mergeinfo. The changes all over the place are just a result of the way svn:mergeinfo works. In Christ, Steven Watanabe
On 12/13/2009 2:01 PM, Eric Niebler wrote:
I clearly am doing something wrong when it comes to merging changes from trunk to release. I feel that as one of the release managers, this is something I should know. :-P Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way. But look at the result of my most recent merge:
https://svn.boost.org/trac/boost/changeset/58336
The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way?
While I can't answer the boost respository specific aspects of your questions, the following article might be helpful as background info: http://www.open.collab.net/community/subversion/articles/merge-info.html
Eric Niebler wrote:
I clearly am doing something wrong when it comes to merging changes from trunk to release. I feel that as one of the release managers, this is something I should know. :-P Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way. But look at the result of my most recent merge:
https://svn.boost.org/trac/boost/changeset/58336
The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way?
The problem, as I see it, is that many files (and probably some directories too) have acquired a svn:mergeinfo property without really needing one, and things seem to get worse with time. FWIW, I only ever merge at the root. :-)
Hi ! On Monday 14 December 2009, you wrote:
Eric Niebler wrote:
The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way?
The problem, as I see it, is that many files (and probably some directories too) have acquired a svn:mergeinfo property without really needing one, and things seem to get worse with time. FWIW, I only ever merge at the root. :-)
Yes, that mostly happens when using svn 1.5.x. It is a known bug. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
2009/12/14 Peter Dimov <pdimov@pdimov.com>:
The problem, as I see it, is that many files (and probably some directories too) have acquired a svn:mergeinfo property without really needing one, and things seem to get worse with time. FWIW, I only ever merge at the root. :-)
I used to always merge at root, but I've given up on that since the root merge information isn't very useful. It seems to me that the most practical solution is to track merges on subdirectories. Then everyone can use whatever method they prefer. That leaves the files in the parent directories (root, boost, libs etc.), which just have to be manually managed. This pretty much requires that top level headers are just includes for a header in the appropriate subdirectory. Daniel
AMDG Daniel James wrote:
2009/12/14 Peter Dimov <pdimov@pdimov.com>:
The problem, as I see it, is that many files (and probably some directories too) have acquired a svn:mergeinfo property without really needing one, and things seem to get worse with time. FWIW, I only ever merge at the root. :-)
I used to always merge at root, but I've given up on that since the root merge information isn't very useful. It seems to me that the most practical solution is to track merges on subdirectories. Then everyone can use whatever method they prefer. That leaves the files in the parent directories (root, boost, libs etc.), which just have to be manually managed. This pretty much requires that top level headers are just includes for a header in the appropriate subdirectory.
I merge at the root still. Since svn:mergeinfo is inherited, I can still check which changes have been merged in each subdirectory. In Christ, Steven Watanabe
2009/12/13 Eric Niebler <eric@boostpro.com>:
Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way.
You're one of the few people who did. I'm not sure if it's worth using svnmerge.py now that subversion has built in merge tracking. It doesn't really hurt though, since it records both. Daniel
participants (6)
-
Daniel James -
egoots -
Eric Niebler -
Juergen Hunold -
Peter Dimov -
Steven Watanabe