Hi, Stefan. Glad to see this!
Changing the API syntactic form to an opaque struct + accessor
functions sounds fine, as I mentioned on IRC. I see you've done that
already.
As for the semantic changes, I want to help clarify our understanding
of the high level 'shape' of merge scenarios. We need cl
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: vrijdag 29 mei 2015 13:16
> To: dev@subversion.apache.org
> Subject: [RFC] new svn_client_conflict API
>
> Another sore point is property conflicts. There's still no way in our A
I would like to start transitioning away from svn_wc_conflict_description2_t
in public APIs and introduce a higher-level API to eventually replace it.
My end goal is to use an opaque type with methods that make it possible
to implement conflict resolution in a way that is easier to use.
For exampl
3 matches
Mail list logo
