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

Re: Serf and Subversion

From: <kfogel_at_collab.net>
Date: 2005-11-28 16:54:44 CET

Greg Stein <gstein@lyra.org> writes:
> Assuming that it will end up being built as ra_serf, does it need to
> go into a branch? We use branches to avoid disrupting developers'
> normal work, but given that an explicit switch to ./configure would be
> needed to see this (and especially if a (debug) scheme were used),
> then it seems it would be easier to keep the dev on trunk. I think the
> one decision point *against* using trunk would be if people want to
> see the work [on a branch], and evaluate it before allowing it to
> trunk. And that sort of falls back to, "does anyone think this is a
> bad idea/approach and shouldn't be done?"

+1 on trunk.

In reply to Justin:

> > Is there any way to put both serf and neon implementations separately
> > inside libsvn_ra_dav/? I'm not proposing that we mix the code, just
> > that we keep the names reflective of the actual situation.
> I don't think so. Other than having #ifdef's or introducing a
> libsvn_ra_dav meta-API that both serf and neon can hook in to that
> mimics the RA layer for all intents and purposes, I don't see how it'd
> work. Serf and neon have a similar purpose, but view the world very
> differently - therefore, I think it's best to keep the code as separate
> as possible.

Sure -- I'm also proposing that they be kept separate. All I meant
was, reorganize libsvn_ra_dav/ to have two separate subdirs:

    libsvn_ra_dav/neon/ <-- for everything currently in libsvn_ra_dav/

The above change sounds major, but it's pretty trivial to implement.
The compile-time switch would determine which subdir gets used.

I seem to be the only person who thinks this is important, but believe
me, to a new developer, a code tree layout that makes sense is a great
blessing :-). If I were approaching Subversion for the first time,
and saw libsvn_ra_dav/ (which ironically would implement a *less*
DAV-like DAV, using Neon) and its sibling libsvn_ra_serf/ (which would
implement a *more* DAV-like DAV, using Serf), I'd be pretty confused.

By putting them both under libsvn_ra_dav/, we'd make the layout
reflect reality, namely, that we have two different implementations of
the DAV protocol.


www.collab.net  <>  CollabNet  |  Distributed Development On Demand
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 18:30:58 2005

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