On 6/23/06, Philip Martin <philip@codematters.co.uk> wrote:
> "Erik Huelsmann" <ehuels@gmail.com> writes:
>
> > Currently we dry-run-merge and later real-merge during 'svn up'/'svn
> > switch'. This is to support interactive merge tools. However, most
> > setups seem to use our internal merge, which doesn't need this
> > behaviour.
>
> Sounds good.
>
> > --- subversion/libsvn_wc/update_editor.c        (revision 20223)
> > +++ subversion/libsvn_wc/update_editor.c        (working copy)
> > @@ -2070,7 +2070,8 @@
> >                newrev_str = apr_psprintf(pool, ".r%ld",
> >                                          new_revision);
> >
> > -              /* Merge the changes from the old-textbase (TXTB) to
> > +              /* When using external diff:
> > +                 Merge the changes from the old-textbase (TXTB) to
> >                   new-textbase (TMP_TXTB) into the file we're
> >                   updating (BASE_NAME).  Either the merge will
> >                   happen smoothly, or a conflict will result.
> > @@ -2078,12 +2079,13 @@
> >                   and keyword translation, and diff3 will insert
> >                   conflict markers for us.  It also deals with binary
> >                   files appropriately.  */
> > -              SVN_ERR(svn_wc__loggy_merge(&log_accum, adm_access,
> > -                                          base_name, txtb, tmp_txtb,
> > -                                          oldrev_str, newrev_str, ".mine",
> > -                                          pool));
> > +              if (diff3_cmd)
> > +                SVN_ERR(svn_wc__loggy_merge(&log_accum, adm_access,
> > +                                            base_name, txtb, tmp_txtb,
> > +                                            oldrev_str, newrev_str, ".mine",
> > +                                            pool));
> >
> > -              /* Run a dry-run of the merge to see if a conflict will
> > +              /* Run (a dry-run of) the merge to see if a conflict will
> >                   occur.  This is needed so we can report back to the
> >                   client as the changes come in. */
> >                base = svn_wc_adm_access_path(adm_access);
> > @@ -2091,12 +2093,14 @@
> >                /* ### FIXME: We force use of the internal diff3 here
> >                       because we don't want to run a graphical external
> >                       diff3 twice.  See issue 1914. */
>
> That comment would need updating.
>
> > +              /* Dry-run iff resorting to external diff for real merge */
> >                SVN_ERR(svn_wc_merge2(svn_path_join(base, txtb, pool),
> >                                                svn_path_join(base,
> > base_name, pool),
> >                                      adm_access,
> >                                      oldrev_str, newrev_str, ".mine",
> > -                                    TRUE, &merge_outcome, NULL, NULL,
> > +                                    diff3_cmd != NULL, /* dry run */
> > +                                    &merge_outcome, NULL, NULL,
> >                                      pool));
>
> This now makes changes in the working copy without using the log file
> mechanism.  The second merge, the one that made all the changes in the
> past, does use log files.  Now the log file code have always been a
> bit of a tricky area, I'm not sure we get it right at present, but is
> your change doing the right thing?
It's doing the same thing we always did in the second merge, but, I
think we need to change both. Instead of merging directly into the
working copy file, I think we should copy the wc file into the admin
area, merge into that 'backup copy' and then - using loggy code - move
the merge result into the working copy.
Sound better?
Thanks for your comments!
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 23 11:02:50 2006