Hi Stefan.
I'm just about starting to get the idea that I think you're talking about, but
I'm still having a hard time seeing how a state machine in the library would
need more than one state transition for any chosen resolution, or why it would
need to control information-display requests.
I
On Thu, May 17, 2012 at 11:09:48AM +0100, Julian Foad wrote:
> Let's take a closer look at what the user (through the client
> application) needs to be able to do.
Thanks for your comments. I think we're about to each consensus
on this. We just have a slight misunderstanding to clear up, and
need
Stefan Sperling wrote:
> On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote:
>> OK, I appreciate that issue. I see two ways the client lib can help:
>>
>> 1. providing a set of client-lib APIs to perform the most commonly
>> wanted resolutions;
>>
>> 2. providing a set of (APIs? com
On Wed, May 16, 2012 at 02:52:46PM +, Markus Schaber wrote:
> Hmm, this may lead to _very_ special strategies implemented in the core.
>
> Like when a CoDeSys Device plugged into a Slot conflicts, and a neighbor slot
> is empty.
>
> On the SVN Working copy, this looks like (irrelevant files
On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote:
> OK, I appreciate that issue. I see two ways the client lib can help:
>
> 1. providing a set of client-lib APIs to perform the most commonly wanted
> resolutions;
>
> 2. providing a set of (APIs? comments?) that suggest what set of p
- Original Message -
> From: Stefan Sperling
> To: Julian Foad
> Cc: "dev@subversion.apache.org" ; Bert Huijben
>
> Sent: Wednesday, 16 May 2012, 14:07
> Subject: Re: new conflict callback API
>
> On Wed, May 16, 2012 at 01:55:01PM +0100, Julian
On Wed, May 16, 2012 at 8:55 AM, Julian Foad wrote:
> Stefan Sperling wrote:
>
>> Bert Huijben wrote:
>>> Note that the simple view of this model doesn't match GUI clients
>>> expectations.
>>>
>>> GUI's can stay inside a callback and keep the gui functional for other
>>> operations, so callba
On Wed, May 16, 2012 at 01:55:01PM +0100, Julian Foad wrote:
> I think the way to avoid "offering options the client library is not prepared
> to handle" is that the application should resolve a conflict by calling a
> series of (mostly) normal client operations, rather than by telling the
> cli
Stefan Sperling wrote:
> Bert Huijben wrote:
>> Note that the simple view of this model doesn't match GUI clients
>> expectations.
>>
>> GUI's can stay inside a callback and keep the gui functional for other
>> operations, so callbacks can only be handled by application-modal dialogs
>> (You
On Wed, May 16, 2012 at 01:59:43PM +0200, Bert Huijben wrote:
> Note that the simple view of this model doesn't match GUI clients
> expectations.
>
> GUI's can stay inside a callback and keep the gui functional for other
> operations, so callbacks can only be handled by application-modal dialogs
>
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: woensdag 16 mei 2012 13:25
> To: dev@subversion.apache.org
> Subject: RFC: new conflict callback API
>
> The current conflict callback API passes a svn_wc_conflict_description2_t
> struct to the callback, and all
11 matches
Mail list logo
