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

Re: svn commit: r33855 - in branches/tree-conflicts-notify/subversion: include libsvn_client libsvn_wc svn tests/cmdline tests/cmdline/svntest

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 23 Oct 2008 04:09:48 -0700

All very good points, Julian! Very much agreed. Thanks.

I think the heart of the problem lies in "what *style* is this
branch?" as you note below:

2008/10/23 Julian Foad <julianfoad_at_btopenworld.com>:
> Does that matter? Maybe that would be better because we would all know
> exactly which commits are supposed to be reviewed (all of them) which
> would avoid the tendency for us to start ignoring all commits on
> branches. If that's the main problem (and it certainly could become a
> problem - we already review branches far less than we should), then we
> should at least consider addressing it in a different way, such as using
> a "/branches/scratch/" name space.

Bingo. I was unaware that Neels' branch was intended to be a "public
development of a patch". In that sense, then I'm very glad it is
there, for all the reasons that you point out. BUT. I didn't know that
it would be subject to (good) review when it finally got merged, on
the basis of it being reviewable-sized.

I think your suggestion would be a fine idea. Something like
/patches/tree-conflict-notify/ would work well.

> I guess you're saying that we can't trust most of ourselves most of the
> time to stick to a reviewable-sized change, and then make sure to get it
> reviewed. And historically that's been so. So maybe overall it would be
> better not to work in this way.

No, my comment wasn't about trusting ourselves, but a lack of
awareness of the *intended* size of Neels' work.

But your *is* true. Some of the branches get a bit big, or too
long-lived, or whatever.

> Is it the question of being easily able to know what to review that's
> most important here?

Yes. And to that point, let me formally suggest a /patches/ directory,
as a sibling to /branches/. We can put developer-work in there, and we
can also drop third-party patches in there, too, pending
review/tweaking/application (rather than attach them to the issue
tracker, for example).



To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-23 13:09:57 CEST

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