Greg Stein <firstname.lastname@example.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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Nov 28 18:30:58 2005