[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC/PATCH] Allow merge to apply only svn:mergeinfo diffs

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 28 Sep 2009 15:32:27 -0400

On Mon, Sep 28, 2009 at 2:16 PM, Paul Burba <ptburba_at_gmail.com> wrote:

> 1) Any problem with implementing something like this?
> 2) If the general idea is ok:
> 2a) Should any notifications be shown?  The existing patch shows
> notifications for paths with mergeinfo changes, but I'm not sure how
> useful these are.  Perhaps, like --record-only, there should be no
> notifications?

I like seeing notifications. I do not see what it hurts and it can
help scripts and tools. In Subclipse, as an example, the
notifications lets us know what paths have been changed so that we can
refresh their status.

> 2b) Should this be a new option to svn merge as in the patch?  Or
> should it be the default behavior of --record-only?  If the latter
> then we need to consider that this will slow --record-only merges down
> compared with today's simple-no-editor-drive approach.  Though I don't
> think the performance hit will be too severe, since a lot of the
> performance problems related to merge (Issue #3443, implicit mergeinfo
> lookups (r36509), etc.) are fixed on trunk or don't apply here (e.g.
> multiple editor drives during a singe merge).  Or maybe there is some
> other solution, --record-only = ARG, where ARG is two choices, one
> representing the old simple way, one the new restricted editor drive.
> Any thoughts are appreciated, thanks,

It is probably opening a can of worms we are not ready to deal with,
but what about using --block ? As your own description explains, that
is exactly the kind of scenario where this is needed.

The big problem I see ( can of worms ) is that eventually people want
to see what they have blocked and so this would not be enough.

Mark Phippard
Received on 2009-09-28 21:32:51 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.