[mpas-developers] request to merge lateral_boundary branch to the trunk
Todd Ringler
ringler at lanl.gov
Tue May 4 16:13:15 MDT 2010
Hi Michael,
Thanks for the heads up on the reintegrate option. Just a note to
anyone reading, the reintegrate option essentially renders the branch
unusable (which is fine because it was merged).
In Subversion 1.5, once a --reintegrate merge is done from branch to
trunk, the branch is no longer usable for further work. It's not able
to correctly absorb new trunk changes, nor can it be properly
reintegrated to trunk again. For this reason, if you want to keep
working on your feature branch, we recommend destroying it and then re-
creating it from the trunk:
Cheers,
Todd
On May 4, 2010, at 3:35 PM, Michael Duda wrote:
> Hi, Todd.
>
> Nice work on the branch update. I checked out the new
> lateral_boundary_conditions branch and compared with with the copy
> that I had merged using the tool from CGD, and everything matches
> except for the top-level Makefile (EXPAND_LEVELS is commented) and
> the namelist.input.ocean file. The new experience with merging
> branches should certainly make our lives easier in future.
>
> I think we may need to use the svn option --reintegrate when
> adding changes from a branch back into the trunk, according to the
> svn documentation at the bottom of p.93 here:
> http://svnbook.red-bean.com/en/1.5/svn-book.pdf Perhaps that
> option would resolve some of the tree conflicts, which aren't
> actually conflicts?
>
> In any case, assuming we get identical results from the sw and
> hyd_atmos cores, I'd be fine with merging the branch changes back
> into the trunk.
>
> Cheers,
> Michael
>
>
> On Tue, May 04, 2010 at 02:43:23PM -0600, Todd Ringler wrote:
>>
>> Hi Michael,
>>
>> After the merge of the trunk to the lateral_boundary_conditions
>> branch, I went to the trunk and issued the command
>>
>> svn merge --dry-run -r 160:HEAD
>> https://svn-mpas-model.cgd.ucar.edu/branches/lateral_boundary_conditions
>>
>> that resulted in the following:
>>
>> --- Merging r161 through r243 into '.':
>> U src/core_hyd_atmos/module_advection.F
>> U src/core_hyd_atmos/module_time_integration.F
>> U src/core_sw/Registry
>> U src/core_sw/module_time_integration.F
>> C src/core_sw/module_vector_reconstruction.F
>> U src/registry/gen_inc.c
>> C src/core_ocean/module_test_cases.F
>> C src/core_ocean/Registry
>> C src/core_ocean/module_time_integration.F
>> C src/core_ocean/module_vector_reconstruction.F
>> U src/framework/module_io_input.F
>> U src/framework/module_io_output.F
>> U src/framework/module_block_decomp.F
>> U src/framework/module_dmpar.F
>> C src/operators
>> C namelist.input.ocean
>> Summary of conflicts:
>> Text conflicts: 4
>> Tree conflicts: 3
>>
>> There are no conflicts within the framework or within the hyd_atmos.
>> The conflicts in the sw model are due to issues with the
>> reconstruction being moved into the operators directory (these
>> account
>> for all three tree conflicts) -- this is easily fixed. The text
>> conflicts in the ocean core are by design, we made some changes to
>> the
>> solver.
>>
>> Mark Petersen will now do the evaluation of the branch code. I expect
>> bit-for-bit in the shallow-water model and the hydrostatic core and
>> will verify this. I will also clean up the minor conflicts.
>>
>> Assuming that Mark's evaluation is positive and that I can verify
>> bit-
>> for-bit in the sw and hyd cores, is there any reason to delay
>> committing this to the trunk sometime later this week?
>>
>> Cheers,
>> Todd
>>
>>
>> On May 4, 2010, at 11:47 AM, Michael Duda wrote:
>>
>>> Hi, Todd.
>>>
>>> On the topic of merging, I think I've learned something here. I had
>>> been using a tool developed by someone in CGD (at the time) that is
>>> used by several of the WRF developers, but it's good to know more
>>> about
>>> the merge built into svn.
>>>
>>> Your plan sounds good to me -- once you've committed the updates to
>>> the
>>> branch, it should be much simpler to see the differences before
>>> merging
>>> the branch back to the trunk.
>>>
>>> Cheers,
>>> Michael
>>>
>>>
>>> On Tue, May 04, 2010 at 11:31:46AM -0600, Todd Ringler wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> Based on some tips from Mark Petersen, I have done an svn merge
>>>> from
>>>> the trunk to the lateral boundary branch as
>>>>
>>>> svn merge --dry-run -r 160:240
>>>> https://svn-mpas-model.cgd.ucar.edu/trunk/mpas . (see what
>>>> would
>>>> change)
>>>> svn merge -r 60:240 https://svn-mpas-model.cgd.ucar.edu/trunk/
>>>> mpas . (merge trunk onto branch)
>>>>
>>>> (supposedly) this merges the repository at .../trunk/mpas at rev
>>>> 240
>>>> (which is the head) onto the branch that was created at rev 160.
>>>> I am
>>>> testing this code right now. Note that the "dry-run" option tells
>>>> us
>>>> what changes without actually doing the merge.
>>>>
>>>> Having not done this before, I am learning as I go -- so
>>>> suggestions
>>>> are welcome.
>>>>
>>>> Once I think I have the merge done correctly, I will commit the
>>>> changes to the branch -- at that point we should be able to
>>>> identify
>>>> the changes that would occur by merging the branch to the trunk.
>>>>
>>>> Cheers,
>>>> Todd
>>>>
>>>>
>>>>
>>>> On May 4, 2010, at 11:05 AM, Michael Duda wrote:
>>>>
>>>>> Hi, Todd.
>>>>>
>>>>> Actually, I've only made minimal changes to the hydrostatic
>>>>> atmosphere core to handle the 'garbage' cell nCells+1; but, those
>>>>> changes don't appear to have any negative effects.
>>>>>
>>>>> I think one step that could help us in testing would be to bring
>>>>> the lateral_boundary_conditions up to date with respect to the
>>>>> trunk, so that the differences in the branch are exactly those we
>>>>> will be proposing to make to the trunk. I've just started
>>>>> experimenting with a diff tool yesterday evening, so I could try
>>>>> to produce a set up updates to the branch that would bring it up
>>>>> to date, and I could place those updates somewhere accessible to
>>>>> other developers; if those updates pass inspection, I could commit
>>>>> them. Does this sound like a reasonable approach?
>>>>>
>>>>> Cheers,
>>>>> Michael
>>>>>
>>>>>
>>>>> On Mon, May 03, 2010 at 04:38:44PM -0600, Todd Ringler wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> We have been working on a clean implementation of lateral
>>>>>> boundary
>>>>>> conditions for a while now. Michael and I put together a design
>>>>>> and
>>>>>> requirement document on the top that was circulated for comments.
>>>>>>
>>>>>> As near I can tell, we have successfully implemented this
>>>>>> design in
>>>>>> the shallow-water model and in the ocean model. Changes committed
>>>>>> by
>>>>>> Michael lead me to think that the design has also been pushed
>>>>>> into
>>>>>> the
>>>>>> hydrostatic atmosphere model.
>>>>>>
>>>>>> Over the next couple of days Mark Petersen will be doing a review
>>>>>> and
>>>>>> testing of the code under the lateral_boundary_conditions. His
>>>>>> focus
>>>>>> will be on the ocean model component. Over the last couple of
>>>>>> weeks
>>>>>> Mat Maltrud has been testing the shallow-water core with
>>>>>> realistic
>>>>>> boundaries. All of this testing has occurred in "MPI-mode" on
>>>>>> numerous
>>>>>> different platforms.
>>>>>>
>>>>>> Some of the changes in this design occur under frameworks, so the
>>>>>> push
>>>>>> back to the trunk will impact all model components when
>>>>>> rebuilt. As
>>>>>> far as we can tell, these changes are innocuous to those not
>>>>>> enforcing
>>>>>> lateral boundary conditions.
>>>>>>
>>>>>> A quick comparison of the shallow-water models in the branch
>>>>>> and in
>>>>>> the trunk show agreement out to ~12 digits after 500 time
>>>>>> steps in
>>>>>> test case #5.
>>>>>>
>>>>>> I am asking for suggestions in terms of testing and evaluation.
>>>>>> We
>>>>>> would like to merge this branch with the trunk very soon, but we
>>>>>> want
>>>>>> to be careful not to adversely impact the broader development
>>>>>> effort.
>>>>>>
>>>>>> Cheers,
>>>>>> Todd
>>>>>>
>>>>>> _______________________________________________
>>>>>> mpas-developers mailing list
>>>>>> mpas-developers at mailman.ucar.edu
>>>>>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>>>>> _______________________________________________
>>>>> mpas-developers mailing list
>>>>> mpas-developers at mailman.ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>>>>
>>> _______________________________________________
>>> mpas-developers mailing list
>>> mpas-developers at mailman.ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>>
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20100504/dff9bd8b/attachment-0001.html
More information about the mpas-developers
mailing list