Greg Stein wrote on Tue, Apr 24, 2012 at 12:20:26 -0400: > On Apr 24, 2012 10:08 AM, "Daniel Shahaf" <danie...@elego.de> wrote: > > > > Greg Stein wrote on Mon, Apr 23, 2012 at 22:47:43 -0400: > > > On Apr 23, 2012 7:20 PM, "Hyrum K Wright" <hyrum.wri...@wandisco.com> > wrote: > > > > > > > > On Mon, Apr 23, 2012 at 4:55 PM, Greg Stein <gst...@gmail.com> wrote: > > > > > On Mon, Apr 23, 2012 at 16:21, Hyrum K Wright < > hyrum.wri...@wandisco.com> > > > wrote: > > > > >> On Mon, Apr 23, 2012 at 12:52 PM, Greg Stein <gst...@gmail.com> > wrote: > > > > >>... > > > > >>> Alright. It sounds like svn_ra.h has two purposes: stuff for > > > libsvn_client, > > > > >>> and stuff for all RA layers to use internally. Ugh. > > > > >> > > > > >> But the capability strings are part of the public API. > > > > > > > > > > Says who? Not server Ev2 support. The RA layer can isolate that, so > it > > > > > should not be "part of the public API". > > > > > > > > > > Mergeinfo support? Sure. But Ev2? Nah. > > > > > > > > The entire RA interface is part of the public API. The wire protocols > > > > are the public interface to the server, particularly for those who > > > > want to write their own clients and server. These strings are part of > > > > that definition. > > > > > > Ah. There we go. That clinches it. > > > > > > It's too bad we don't have svn_wire.h. Right now, svn_ra serves both > > > purposes, so yah... I guess it makes sense to leave it there, unless > we'd > > > like to start migrating appropriate pieces to a new header. Thoughts? > > > > Haven't followed the thread, but we generally declared only the C API to > > be public, while the wire API was considered "internal". (i.e., we'll > > have to make it compatible to respect our 1.x-client/1.y-server promise, > > but we don't officially support people writing their own wire clients, > > etc, not through our libraries) > > Hmm. True. .../include/private/svn_wire.h then. >
subversion/include/private/svn_dav_protocol.h ? (or is ra_svn involved too?) > ?
