Forgotten patch: qofid.diff
Chris Shoemaker
c.shoemaker at cox.net
Sun Oct 30 18:31:40 EST 2005
On Sat, Oct 29, 2005 at 04:28:47PM -0400, Josh Sled wrote:
> On Fri, 2005-10-28 at 21:00 -0400, Chris Shoemaker wrote:
> > of the foundational issue: our development process. Our process just
> > doesn't support the case where:
> > 1. not everybody wants to work on the same thing,
> > 2. they can't produce almost perfect code the first time out, and
> > 3. they want to collaborate.
>
> Branches can support all three of these goals.
>
> Though, I continue to not understand why it's not reasonable for
> everyone to be working primarily towards the same goal/thing.
I guess we have the same goal in a broader sense. I just meant the
narrow sense of wanting to do two different things to the same code,
e.g. bug-fix current register, and completely overhaul register.
> On Sat, 2005-10-29 at 00:04 -0400, Chris Shoemaker wrote:
> > well might have a HUGE MESS. OTOH, if have all 500 commits and 250^2
> > degrees of freedom in merge order, you're much more likely to be able
> > to merge with NO conflicts. And any conflicts you do have will be the
> > conflicts of *individual* commits.
>
> 250^2 degress of freedom in merge order? Ignoring the fact that that's
> not practically true or useful given the semantic dependencies of the
> commits, do we really practically need this capability?
That depends on how you want to use it, of course. If everybody tends
to work in the same branch, then no, it's probably not a compelling
feature. OTOH, if you prefer to branch for any non-trivial code
endeavor, then yes, it's useful.
> Chris, I really don't care to spend any more time on these threads.
Me neither. I recognize there is a diminishing return value here.
> You
> assert that the development process is broken, and most of the rest of
> us assert the opposite. You really want some unspecified distributed
> SCM/"convergence tools", and most of the rest of us are fine just moving
> to SVN.
Re: "unspecified". I've been light on specification not because there
are not concrete realizations of what I'm talking about but because I
wanted to separate issue of requirements and implementation.
> You claim the problem's in the tools, then you claim it's not
> just about the tools... around and around we go.
I don't think I've been unclear here. SCM tools are both a _product_
of their development culture and _influence_ their development
culture. Problems in both are manifest in the other.
> I don't quite know how to resolve this. I guess we could make proposals
> and vote Apache-style, but I already see a concensus. What do you want?
I don't think you'd find a consensus unless you limited the vote to
certain people. I agree with Christian's recommendations: collapse G2
_soon_, move forward with SVN, re-eval next year.
-chris
More information about the gnucash-patches
mailing list