ra_dav refactoring: approaching branch merge-back point

[Erik Huelsmann <eh...@gmail.com>]

After my series of commits from last weekend, the ra_dav-refactoring
branch is approaching 'completion': Almost all changes I intended have
been incorporated (except for the point addressed in my mail from last
night).

These points have been addressed:

- Reduced Neon type useage (which need manual tracking and destruction)
- Eliminated all marshalling of errors through the Neon layer in xml callbacks
  (making sure we leak no more).
- Reduced integration between internal ra_dav APIs and Neon's public API
- Eliminated necessity for Neon request callbacks to attach custom error
  parser to Neon requests.
- Moved from manual allocation of requests into the 2 neon sessions to
  automatic session selection.
- Separated locking code into a dedicated file.
- Code simplifications by reducing the number of manually destructed resources.


Code review of the branch diff is most welcome!

Without any comments, I'll merge the branch to trunk one week after
the last commit (I may commit some minor cleanups in the days to come)
meaning it won't happen before next week.

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_dav refactoring: approaching branch merge-back point

[Daniel Rall <dl...@collab.net>]

On Tue, 12 Dec 2006, Erik Huelsmann wrote:

> On 12/11/06, Daniel Rall <dl...@collab.net> wrote:
> >On Mon, 11 Dec 2006, Erik Huelsmann wrote:
> 
> >> Code review of the branch diff is most welcome!
> >>
> >> Without any comments, I'll merge the branch to trunk one week after
> >> the last commit (I may commit some minor cleanups in the days to come)
> >> meaning it won't happen before next week.
> >
> >Very cool!
> >
> >I'm in favor of merging, but am somewhat concerned about regressions.
> >Do any of the changes warrant additional DAV-specific tests, or is the
> >existing regression test suite sufficient?
> 
> Well, there's no new functionality there. Only rewritten-but-existing
> functionality. Though I'm sure we could always test more, I'm quite
> confident the basic level of quality is good. We could wait to merge
> right after we branch for 1.5, if you think that's nearing, but I have
> a feeling that may take a while still.

I don't see much of a point in waiting, and am in favor of merging in
the ra_dav refactoring branch in sooner rather than later.

Re: ra_dav refactoring: approaching branch merge-back point

[Erik Huelsmann <eh...@gmail.com>]

On 12/11/06, Daniel Rall <dl...@collab.net> wrote:
> On Mon, 11 Dec 2006, Erik Huelsmann wrote:

> > Code review of the branch diff is most welcome!
> >
> > Without any comments, I'll merge the branch to trunk one week after
> > the last commit (I may commit some minor cleanups in the days to come)
> > meaning it won't happen before next week.
>
> Very cool!
>
> I'm in favor of merging, but am somewhat concerned about regressions.
> Do any of the changes warrant additional DAV-specific tests, or is the
> existing regression test suite sufficient?

Well, there's no new functionality there. Only rewritten-but-existing
functionality. Though I'm sure we could always test more, I'm quite
confident the basic level of quality is good. We could wait to merge
right after we branch for 1.5, if you think that's nearing, but I have
a feeling that may take a while still.

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_dav refactoring: approaching branch merge-back point

[Daniel Rall <dl...@collab.net>]

On Mon, 11 Dec 2006, Erik Huelsmann wrote:

> After my series of commits from last weekend, the ra_dav-refactoring
> branch is approaching 'completion': Almost all changes I intended have
> been incorporated (except for the point addressed in my mail from last
> night).
> 
> These points have been addressed:
> 
> - Reduced Neon type useage (which need manual tracking and destruction)
> - Eliminated all marshalling of errors through the Neon layer in xml 
> callbacks
>  (making sure we leak no more).
> - Reduced integration between internal ra_dav APIs and Neon's public API
> - Eliminated necessity for Neon request callbacks to attach custom error
>  parser to Neon requests.
> - Moved from manual allocation of requests into the 2 neon sessions to
>  automatic session selection.
> - Separated locking code into a dedicated file.
> - Code simplifications by reducing the number of manually destructed 
> resources.
> 
> 
> Code review of the branch diff is most welcome!
> 
> Without any comments, I'll merge the branch to trunk one week after
> the last commit (I may commit some minor cleanups in the days to come)
> meaning it won't happen before next week.

Very cool!

I'm in favor of merging, but am somewhat concerned about regressions.
Do any of the changes warrant additional DAV-specific tests, or is the
existing regression test suite sufficient?

Re: ra_dav refactoring: approaching branch merge-back point

[Garrett Rooney <ro...@electricjellyfish.net>]

On 12/11/06, Erik Huelsmann <eh...@gmail.com> wrote:
> After my series of commits from last weekend, the ra_dav-refactoring
> branch is approaching 'completion': Almost all changes I intended have
> been incorporated (except for the point addressed in my mail from last
> night).
>
> These points have been addressed:
>
> - Reduced Neon type useage (which need manual tracking and destruction)
> - Eliminated all marshalling of errors through the Neon layer in xml callbacks
>   (making sure we leak no more).
> - Reduced integration between internal ra_dav APIs and Neon's public API
> - Eliminated necessity for Neon request callbacks to attach custom error
>   parser to Neon requests.
> - Moved from manual allocation of requests into the 2 neon sessions to
>   automatic session selection.
> - Separated locking code into a dedicated file.
> - Code simplifications by reducing the number of manually destructed resources.
>
>
> Code review of the branch diff is most welcome!
>
> Without any comments, I'll merge the branch to trunk one week after
> the last commit (I may commit some minor cleanups in the days to come)
> meaning it won't happen before next week.

I haven't had time to take an in depth look at this stuff, although
the bits I have seen are quite nice.  I will say that I'm VERY glad to
see Erik taking a look at this stuff, I've been of the opinion for a
while now (mostly since seeing what Justin did with ra_serf) that
ra_dav could be much nicer code if it had some attention, as opposed
to just letting it evolve over time and retain its various backwards
compatibility shims and hacks like we had done up to now, and Erik's
recent work seems to be proving that to truly be the case.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org