Julian:
Given the required RA protocol changes, when could this change be shipped?
What version of SVN?
Thank you.
Doug
On Wed, Feb 19, 2014 at 10:06 AM, Julian Foad <julianfoad_at_btopenworld.com>wrote:
> Marc Strapetz wrote:
> > Julian Foad wrote:
> >> It looks like we have an agreement in principle. Would you like to file
> an
> >> enhancement issue?
> >
> > Great. I've filed an issue now:
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=4469
> >
> > Would you please review the various attributes (Subcomponent, ...)?
>
> That's great, thanks. I added a reference to this email thread, added
> myself to the CC list, and tweaked the type from 'feature' to 'enhancement'
> (just my personal interpretation) and schedule from '---' to 'unscheduled'
> (which just indicates I've thought about it and am stating that it's not
> currently tied to any particular release, it doesn't mean it has to stay
> that way).
>
> I talked with Brane about this and we discussed how it might make more
> sense to do a higher level API. Instead of asking "what is the absolute
> difference in the mergeinfo representations?" it could ask "What merges and
> other interesting events have occurred in the lifetime of this path?".
> There are a couple of reasons.
>
> The API as sketched so far is pretty straightforward, but even so the
> effort needed to implement it is not trivial. It requires RA protocol
> changes as well as all the layers of API change. The mergeinfo
> representation is subject to change. It feels like a backward step to
> invest effort in adding more support that is tied specifically to the
> current format.
>
> SmartSVN and other front ends like to be able to draw a merge graph. Even
> the 'svn mergeinfo' command-line command now draws a little ASCII-art graph
> showing limited information about the most recent merge. At present they
> all have to interpret mergeinfo themselves, at a pretty low level, and the
> interpretation is subtle and poorly understood. (I don't understand the
> edge cases related to adds and deletes properly, and I've been working with
> it for years.)
>
> So it seems like a good idea to encapsulate the interpretation of
> mergeinfo a bit more, and expose data in a form that is geared specifically
> towards explaining the history in the way that users can understand it.
> Maybe think of it as an extended 'log' operation, adding a small number of
> new notification types such as:
>
> * there is a full merge into here, bringing in all the new changes
> from PATH up to REV;
> * there is a partial merge to here, bringing in some changes
> from PATH between REV1 and REV2;
>
> What do you think of that sort of interface? Does your code already
> calculate something like that?
>
> - Julian
>
>
--
Douglas B. Robinson | *Senior Product Manager*
WANdisco // *Non-Stop Data*
t. 925-396-1125
e. doug.robinson_at_wandisco.com
--
Listed on the London Stock Exchange: WAND<http://www.bloomberg.com/quote/WAND:LN>
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.
Received on 2014-02-21 15:51:00 CET