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