GStein and I (and Ben, and Mike) were just talking, and realized that
there might be some miscommunication here. To clarify:
Gstein's veto was because of the non-APR socket stuff.
Seperately from that, he was trying to encourage that future "power
plant" work like this be done on in-tree, either on a branch, or in
trunk but not included in the default build until ready. That way,
you can get feedback as you go (for example, the APR socket thing
would have been found right away, probably, because it would have been
convenient for people to see the code).
I think that's a pretty good practice, hope you (and others working on
power plants) agree.
Anyway, by whatever means it arrived, I'm very glad to see ra_svn in
there -- bravo!
-K
Greg Hudson <ghudson@MIT.EDU> writes:
> Yes and no. As a new RA layer, it doesn't affect anyone who doesn't use
> it. I'm not sure how having it in the tree and not built is an
> improvement on having it in the tree, built, and not used. (Branko
> already volunteered to fix any Windows build problems, and the lack of
> APR-ized sockets shouldn't actually be causing significant Windows build
> problems.)
>
> > But the non-apr-ized socket stuff is a problem, and I have serious
> > issues with huge commits that nobody has ever seen before. I don't think
> > that is a very good precedent, for anybody, no matter how good the code may
> > or may not be.
>
> I'm going to run into this issue again if I ever write libsvn_fs_fs (or
> whatever it gets called). You can't exactly write an fs or ra layer as
> a series of small commits, because you don't really know if your design
> is going to work until you've written a good 60% of the code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 3 19:13:32 2002