I am attempting to set up existing branches so that developers can start
using the trunk->branch [ merge] and branch-> trunk [ ł--reintegrate˛ ]
options right away.
To do that [ as you mentioned ] I am trying to use the ‹record-only
feature on existing branches.
SO here is what I did
==>>>
$ cd <branch1-WC>
$ svn merge --record-only svn+ssh://HOST/svnroot/tfb/trunk/www -r 1:92731 .
$ svn diff
Property changes on: .
___________________________________________________________________
Added: svn:mergeinfo
Merged /tfb/branches/facelift/www:r218-5929
Merged /tfb/trunk/www:r12-217,5930-92731
==>>>
I just donąt understand this syntax. The branch was cut from the łtrunk˛ at
rev# 88328 ‹ I would have expected the svn:mergeinfo to be :->
svn:mergeinfo = /tfb/trunk:r88328-92731.
Where is it picking up the additional information and why should I care
about revisions 218-5929? And what about 5930-92731.
The other aspect that is not so clear is the svn merge ‹reintegrate
behaviour. In my test case I noticed it was displaying conflict in files
that hadnąt been touched on the branch as well as files being unnecessarily
updated on the trunk . Is there some document that describes how
--reintegrate actually works in different situations
Examples:
(a) files deleted on the trunk , merged into branch but reverted before
commit
(b) files deleted and being re-added on the trunk
(c) added in trunk, branch [ same name / location ] independently
etc
Cheers
murli
On 8/25/08 2:09 PM, "Mark Phippard" <markphip_at_gmail.com> wrote:
> On Mon, Aug 25, 2008 at 5:05 PM, Murli Varadachari
> <mvaradachari_at_facebook.com> wrote:
>> > 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
>
> You will have a checked out WC from trunk, and you will run this command:
>
> svn merge --reintegrate url://branch
>
> Internally, that command will do the same as this command:
>
> svn merge url://trunk@150000 url://branch@HEAD
>
> In other words, SVN compares the current branch with trunk at the last
> revision that was merged to the branch. This produces an accurate
> diff of what is changed on the branch and applies that to the trunk WC
> as the merge operation.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Received on 2008-08-28 09:03:11 CEST