Re: svn commit: rev 3964 - in trunk: . subversion subversion/libsvn_ra subversion/include subversion/tests/clients/cmdline/getopt_tests_data subversion/libsvn_ra_svn subversion/svnserve

[Greg Hudson <gh...@MIT.EDU>]

On Tue, 2002-12-03 at 05:36, Greg Stein wrote:
> On Mon, Dec 02, 2002 at 09:55:50PM -0600, ghudson@tigris.org wrote:
> >...
> > Modified:
> >    trunk/build.conf
> >    trunk/configure.in
> 
> -1
> 
> This code should not be part of the default build (for now)

Okay... but I think you broke the build and the test suite by reverting
just these two files.  I'll fix that.

> * the socket stuff needs to be apr-ized

Oh, hey, there's APR socket stuff!  I somehow just assumed that Apache
used its own socket stuff.  And it looks like I can turn an apr_file_t *
into a socket at least on Unix, which will allow pipe operation to
work.  I'll get right on that.

> * this code has never been seen before; 150k is a *huge* amount of code to
>   appear from nowhere and suddenly become part of the build

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

Re: svn commit: rev 3964 - in trunk: . subversion subversion/libsvn_ra subversion/include subversion/tests/clients/cmdline/getopt_tests_data subversion/libsvn_ra_svn subversion/svnserve

[Karl Fogel <kf...@newton.ch.collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:
> My main concern is having to stop and write detailed log messages every
> time I want to change the infrastructure code a little bit.  You don't
> know what you want your low-level routines to do until you've written a
> bunch of higher-level routines, so there were a lot of such moments in
> ra_svn.
> 
> And I'm just not sure how much value there is in seeing all the
> intermediate steps before a new module of moderate size is implemented. 
> Commits tend to be unreviewable due to the amount of refactoring
> involved, and even when review is possible, the feedback is usually of
> limited value.  Collaboration isn't generally possible because of the
> level of churn and unwritten design details.  It's true that people
> might have noticed the non-apr sockets code earlier, but that only took
> two hours to fix after the power plant.

Understood.  (I don't know enough to say whether more incrementalism
was possible in this case or not, but whatever.  As long as we all
know that it is encouraged, we'll try to do it where possible, that's
the most one can hope for in changes like this.)

-K

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

Re: svn commit: rev 3964 - in trunk: . subversion subversion/libsvn_ra subversion/include subversion/tests/clients/cmdline/getopt_tests_data subversion/libsvn_ra_svn subversion/svnserve

[Greg Hudson <gh...@MIT.EDU>]

On Tue, 2002-12-03 at 13:05, Ben Collins-Sussman wrote:
> I understand that many people want to work alone -- or don't want to
> be drowning in feedback before they even have working code.

My main concern is having to stop and write detailed log messages every
time I want to change the infrastructure code a little bit.  You don't
know what you want your low-level routines to do until you've written a
bunch of higher-level routines, so there were a lot of such moments in
ra_svn.

And I'm just not sure how much value there is in seeing all the
intermediate steps before a new module of moderate size is implemented. 
Commits tend to be unreviewable due to the amount of refactoring
involved, and even when review is possible, the feedback is usually of
limited value.  Collaboration isn't generally possible because of the
level of churn and unwritten design details.  It's true that people
might have noticed the non-apr sockets code earlier, but that only took
two hours to fix after the power plant.

(I did plan to present a design document for fs_fs before writing any
code and take feedback, because there is a lot more important design
involved there.  ra_svn did involve designing a protocol, but most of
the decisions were arbitrary or were previously aired on the list.)


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

Re: Working on branches was Re: svn commit: rev 3964...

[Karl Fogel <kf...@newton.ch.collab.net>]

Justin Erenkrantz <je...@apache.org> writes:
> > world.  We've criticized gat for this, as well as mbk, and we'd like
> > to discourage others from repeating this behavior in the future.  So
> > pretty please, ghudson, don't write libsvn_fs_fs in cave!
> 
> Then, what is the policy for creating branches?
>
> [...]
>
> Branches may be good for work we know will be merged, but what about
> stuff that might not be merged or not all developers agree on whether
> it should be in?

We seem to be doing branches on a case-by-case basis.

For patches attached to issues, there's no branch because, hey, it's
right there in the issue.  (Whether it's kept up-to-date or not is
another question.)  That covers some, but not all, of the patches you
mentioned.

For patches where there's not a consensus that the patch is a Good
Thing, or disagreement about its general direction (such as the
svn:permissions patch), then it just stays as a separately maintained
patch, without any issue.

For patches that aren't ready for mainline dev yet, but for which
there is a consensus that it will eventually be ready for the
mainline, then we do a branch.

But these aren't hard and fast rules, it just seems to depend on the
individual situation... I don't know how much the committers group as
a whole is wedded to this policy, it's just what we seem to have
settled into.
 
> I don't necessarily have the time to meet the requirements of every
> developer to get all of my patches accepted.  It's just that people
> keep asking about some of my functionality and I can't say it's in
> HEAD or even within SVN itself.  I have to provide diff-style patches
> myself.  So, yeah, branches would be goodness, but I have a hunch what
> I would want in a branch wouldn't be approved.  -- justin

I wish we had cross-repository branching already :-(.

-K

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

Working on branches was Re: svn commit: rev 3964...

[Justin Erenkrantz <je...@apache.org>]

--On Tuesday, December 03, 2002 12:05:08 -0600 Ben Collins-Sussman 
<su...@collab.net> wrote:

> world.  We've criticized gat for this, as well as mbk, and we'd like
> to discourage others from repeating this behavior in the future.  So
> pretty please, ghudson, don't write libsvn_fs_fs in cave!

Then, what is the policy for creating branches?

I've got several things in my cave that haven't been accepted.  Almost all 
of them have been submitted to the list, but not included for various 
reasons. Some are due to time constraints on my end, and others due to 
conflicting world views among SVN developers.

1) svn:permissions
    Bill and Branko refuse to accept it until it can handle Win32 
permissions, which of course, is downright near impossible.  And, we're 
diametrically opposed on whether SVN should even do this or not.  (Not 
looking to bring this discussion up again - I was obviously in the minority 
on this.)
2) Using APR's libtool rather than SVN's own generated libtool
    This is required to use my jlibtool, but someone complained that SVN 
needed its own libtool rather than using APR's.  My current version ensures 
the APR libtool is new enough for SVN, but still...
3) Adding a --with-diffutils option to configure
    Solaris's diff isn't good enough, and forcing me to include a good diff 
in my PATH is, um, icky.  But, the ac-helpers/check-diff.sh is bypassed 
with an explicit value passed - no time to clean that up by rewriting 
check-diff.sh as an M4 macro.
4) My update of mbk's svn switch --relocate patch
    I haven't had time to catch up with the Issue #1000 patch which fixes 
loggy wcprops.  I think the patch works even in that case, but I haven't 
had time to sift through that new code.  As those in Vegas know, I merged 
that code into my tree while I was there.  I also fixed up a bunch of minor 
nits in mbk's original patch.
5) My 'mirror' repos code
    I just wrote this code, but perhaps others would be interested in 
having this functionality.  At the very least, it'd be a jumping-off point 
for thinking about distributed SVN repositories.

Branches may be good for work we know will be merged, but what about stuff 
that might not be merged or not all developers agree on whether it should 
be in?

I don't necessarily have the time to meet the requirements of every 
developer to get all of my patches accepted.  It's just that people keep 
asking about some of my functionality and I can't say it's in HEAD or even 
within SVN itself.  I have to provide diff-style patches myself.  So, yeah, 
branches would be goodness, but I have a hunch what I would want in a 
branch wouldn't be approved.  -- justin

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

Re: svn commit: rev 3964 - in trunk: . subversion subversion/libsvn_ra subversion/include subversion/tests/clients/cmdline/getopt_tests_data subversion/libsvn_ra_svn subversion/svnserve

[Ben Collins-Sussman <su...@collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:

> 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.

I don't think anyone objects to this new code being in the tree.
We're all super happy about this contribution.

I think Greg Stein's point (which I agree with) is that we're trying
to prevent anti-social behavior here.  It's very "uncollaborative" to
crawl into a cave, write a massive feature, then present it to the
world.  We've criticized gat for this, as well as mbk, and we'd like
to discourage others from repeating this behavior in the future.  So
pretty please, ghudson, don't write libsvn_fs_fs in cave!

I understand that many people want to work alone -- or don't want to
be drowning in feedback before they even have working code.  But it's
easy to ask people to back off.  Notice what I/cmpilato/fitz are doing
with the Subversion book... we're working on it incrementally, in
public, but people have been very good about leaving us alone (until
we ask for feedback later.)  It's just a matter of asking people to do
so.  And when you're done, there's no "overwhelming power-plant"
effect.

So consider this a social-engineering request.  :-)

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

Re: svn commit: rev 3964 - in trunk: . subversion subversion/libsvn_ra subversion/include subversion/tests/clients/cmdline/getopt_tests_data subversion/libsvn_ra_svn subversion/svnserve

[Karl Fogel <kf...@newton.ch.collab.net>]

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 <gh...@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