[Svnmerge] Fwd: [PATCH] preserving mods to renamed files/directories

[Archie Cobbs]

Resend.. I sent this from the wrong email address before..

---------- Forwarded message ----------
From: Archie Cobbs <archie at awarix.com>
Date: Jul 12, 2007 9:21 AM
Subject: Re: [Svnmerge] [PATCH] preserving mods to renamed files/directories
To: "lsuvkne at onemodel.org" <lsuvkne at onemodel.org>
Cc: rasky at develer.com, svnmerge at orcaware.com

I'm not sure if this is directly relevant to this issue, but here's a
possibly useful idea to help with situations like this....

In the same way that "svn diff" allows you to plug in your own diff(1)
command using the "--diff-cmd" flag, why not have add a flag like
"--merge-cmd" to svnmerge that allows you to plug in your own merge command
( i.e., it would be used in place of "svn merge")?

Then, instead of folding special merge functionality into svnmerge, once
could just provide their own "merge" tool that can be plugged into svnmerge.
Such a merge tool might better handle the "rename/merge" problem, etc.

Just a thought.

On 7/12/07, lsuvkne at onemodel.org <lsuvkne at onemodel.org > wrote:
>
> >>> On Wed, Jul 11, 2007 at  5:51 pm, in message <46956CE5.1070900 at develer.com
> >,
> Giovanni Bajo <rasky at develer.com> wrote:
> > On 10/07/2007 5.57, lsuvkne at onemodel.org wrote:
> >
> >> This relates to preserving file and  revision log comments changes
> >> across a merge that includes renames.
> >>  [snip]
> >> ..I added a call to check_for_changes_to_preserve_across_merge(). This
> >> function, and the functions it depends on, determine from "merge
> >> ?? dry? run" output whether there are any matching "add/delete" pairs
> of
> >> statements (representing renames) about to be applied, and for each of
> >> those renames, determines from logs what file edits (diffs) and
> comments
> >> would be lost due to the merge's deleting that file and replacing it.
> It
> >>  [snip]
> >
> > I'm ? 1 on this patch, because it adds a *lot* of unnecessary
> complication in
> > svnmerge.py, just to workaround a bug (or missing feature) in svn.
> >
> > I think there is a right place for every feature, and svnmerge.py isn't
> just
> > the right place for this one. I can't but agree with Daniel Rall that
> any
> > effort in this direction should be aimed at issue #2685, rather than
> > kludging
> > svnmerge.py.
> >
> > Really, it's not that I'm against having the bug fixed: it hurts me many
> > times! It's just that to fix the bug, you need to fix issue #2685, not
> > svnmerge.py.
>
> I can't disagree with you.  Our internal situation benefits,
> however, as we now switch from CVS to Subversion, and to a mode of
> parallel development with many renames and merges.  We don't want to
> lose changes, and this was something feasible in the time available.
>
> I did a lot of research and posted to this list for feedback, before
> starting work on this patch.  Past surprise complexities, postponements,
> and "false peaks" have plagued the project on this general problem since
> before svn 1.0.  We can't wait for #898 (atomic renames) to be fixed,
> and it's questionable whether anything like #2685 or #2282
> (http://subversion.tigris.org/issues/show_bug.cgi?id=2282) will be done
> soon enough.
>
> What will the purpose of svnmerge.py be, after 1.5 is in
> use?  Granted, some things, like --bidirectional checking (last I knew)
> could still be missing from merge tracking at 1.5.0.   But our
> organization will almost certainly still need svnmerge.py after 1.5.0,
> with this (kludgy, temporary, useful, documented, well-tested)
> patch--until a real solution is in place that minimizes our data loss.
>
> Now, having a short-term solution in place for our developers, I'm
> hoping to learn more about the issues around #2282 and #2685 and see
> what will or can be done in the medium term or sooner.  If there are
> other ideas for better short-term dataloss prevention, I will be
> grateful to hear them.
>
> So I posted in case anyone else could benefit, or correct mistakes in my
> thinking; thanks for the feedback thus far.
>
> > Moreover, I find your variables with names longer than 30 variables
> totally
> > unreadable. If you need 30 characters to describe a variable, it's
> really
>
> Yes, my long variable names. You said it well and I'll try to do better.
>
> Best regards,
>
> -Luke
>
> _______________________________________________
> Svnmerge mailing list
> Svnmerge at orcaware.com
> http://www.orcaware.com/mailman/listinfo/svnmerge
>



-- 

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

-- 

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/svnmerge/attachments/20070712/2e372303/attachment.html>