On 8/25/08 12:59 PM, "Mark Phippard" <markphip_at_gmail.com> wrote:
> On Mon, Aug 25, 2008 at 3:39 PM, Murli Varadachari
> <mvaradachari_at_facebook.com> wrote:
>
>> > We are planning to switch our subversion 1.4.x repositories over to 1.5.1
>> > shortly ‹ this effectively means that developers can start using the merge
>> > tracking functionality right away.
>> >
>> > Our current development model is as follows ==>
>> >
>> > Main development work is done on the trunk -- new features etc are done on
>> > branches [ based off the trunk]. Developers frequently merge changes from
>> > the trunk to their feature branches and on occasion merge their work back
>> > from branch to trunk. The actual revision# and command itself is added as
>> > a part of the comment during the merge-commit operation.
>> >
>> > Example:
>> >
>> > Create a new branch "mybranch" from trunk at rev# X
>> >
>> > After some trunk commits the changes are sucked into mybranch
>> >
>> > svn merge r X:Y trunk <mybranch-WC>
>> >
>> > .. Later on more trunk commits are merged to mybranch
>> >
>> > svn merge r Y:Z trunk <mybranch-WC>
>> >
>> > Finally the branch commits are merged back to trunk..
>> >
>> > svn merge trunk_at_X mybranch <trunk-WC-at latestrev>
>> >
>> > Going forward the simplest solution would have been to have developers (a)
>> > cut a new branch from trunk and (b) start using the new merge /
>> reintegrate
>> > process for trunk -> br and br->trunk [reintegrate] merges.
>> >
>> > However that does not seem likely any time soon since many developers are
>> > not ready to merge back their changes to trunk from their feature branches
>> > . So my question is how can I convert the current process so that I can
>> > start using " svn ‹reintegrate mybranch <trunk-WC>" on existing branches.
>> > There is no prior merge history in 1.4.x other than comments. At this point
>> > I can't use the above option ‹ merge complains about not having the
>> > necessary information to ‹reintegrate.
>
>>> >>Assuming branches were created via svn copy, then SVN should recognize
>>>> >>>the natural history of the branch. I'd think if you knew the last
>>> >>revision from trunk that you had merged from you could run this
>>> >>command on the branch root and commit the prop change it would create:
>
>>>> >>>svn merge --record-only -r0:LAST_REV url://trunk .
>
>>>> >>>You could probably replace the "0" with the revision when the branch
>>>> >>>was created. I'd like to think --record-only is smart enough to do
>>> >> the same, but I did not try it.
>
>>>> >>>Once you do this, you should be able to start using:
>
>>>> >>>svn merge url://trunk
>
>>>> >>>To merge future changes from trunk automatically. And use
>>>> >>>--reintegrate when you are done.
>
The question that is still not clear is how will the --reintegrate option
work.
Let use assume that the initial branch was created from trunk at rev#
100000. Subsequently I merged back from branch -> trunk at rev# 100110
manually [ pre-1.5] . Since then I have made a large number of commits into
branch that haven¹t been merged to trunk at all. Instead recently I pulled
in changes from trunk once again at rev# 150000 once again. More commits
into branch up rev# 1500010.
Now I switch to svn 1.5.1 ==>
To follow you proposal ‹ I could do this
svn merge ‹record-only r 100000:150000 url://trunk <mybranch-WC> [ this
will record the fact that all revisions upto 150000 on trunk have been
merged ]
Now when I run ³svn merge ‹reintegrate url://mybranch <trunk-WC>² what
should I expect / what would this record?
Will it pull in all changes to branch from rev# 100000 OR after rev# 150000.
How will it deal with my manual merge at rev# 100110
Would I have to execute a ³‹reintegrate ‹record-only² to account for some
previous branch -> trunk merges.
Cheers
murli
Received on 2008-08-25 23:05:57 CEST