Forgotten patch: qofid.diff

[Chris Shoemaker]

On Fri, Oct 28, 2005 at 05:04:05PM -0400, David Hampton wrote:
> That would be "cvs update -j rev1 -j rev2".  Its what I do every time I
> synchronize the changes from HEAD in to the g2 branch.

And it's enough of a pain that we don't do it /every day/, which is
exactly how often I sync my development with mainline for other
projects.  And if you're tool has the full history for both branches,
merging every day is easy, even when the development branch becomes
quite heavy.  OTOH, refreshing a patch stack the size of budgetting
often became so burdonsome that if I got a few days behind, I dreaded
picking back up with gnucash development.  I don't want to go back
there.

> 
> > I'm changing files in working/ all the time - the worst time is when I'm 
> > preparing for a commit and someone else also makes a commit. Because of this 
> > single build problem, my commit process has to start all over again. It's 
> > mind-numbingly frustrating.
> > 
> > All I want is to be able to commit my changes, independent of anyone else's 
> > changes, but the current system won't allow that.
> 
> I don't follow this statement at all.  If you've changed
> src/engine/qofid.c and I've changed src/gnome/gnc-main-window.c there's
> no conflict.  If your process make you restart in this case then the
> process is the problem, not the scm system.

No way, man.  Changes in untouched files broke my patches all the
time.  Semantically, not syntactically.  Breakage wouldn't show itself
until you tried to use the feature.

> 
> > I want to only send my changes and let them be independent of 
> > unrelated changes in other parts of the tree or other files in the same part 
> > of the tree.
> 
> CVS has no problem with this unless the changes conflict in an
> individual file.

Um, yeah, but for any substantial development work, conflicts are
guaranteed.

> 
> > Which is why we NEED more publication of the DEVELOPMENT code, not the 
> > finished "CoreBuild" code.
> 
> So get a branch and publish your code.  This is no different than
> committing change sets to a repository.  Someone has to check out the
> branch/apply the changeset if they want to see what you're working on.

Practically, the difference is the relative frequency of tree-based
branch merges vs. the frequency of changeset merges.  *That* difference
is the consequence of the difficulty difference.

> 
> > Wholeheartedly agree. It is a severe PITA that unrelated changes in completely 
> > separate folders require a complete merge and rebuild to regenerate my 
> > potential patch for the commit.
> 
> It doesn't.

Well, you don't *know* that it doesn't unless you either 1) review
every line of changed code in *both* branches, or 2) merge, rebuild,
test.

> 
> > The ONLY reason for that is the insistence on not breaking the CoreBuild.
> 
> Doesn't matter to me what scm system is used.  I'm going to insist that
> the main trunk compiles on a nightly basis.  You want to commit
> non-working code to any branch other than the main trunk or a shipping
> production branch (like the 1.8 branch)?  Go right ahead.  That's what
> branches are for.

Two points: 

1) I think it's good to have a trunk that compiles every
day.  There are *tons* of good reasons for this.

2) Maybe it's too early to get retrospective about this, but... we
have to be smart about branching.  IMO, this didn't work so well with
G2.  There was no reason why there couldn't have been regular releases
of GnuCash that had incrementally more and more use of gtk2, while
still using gtk1.  We know how to solve the multiple library issues.
But it didn't happen that way.  The branches diverged just fine, so
there wasn't development conflict, but they didn't converge well
enough to keep releasing new code.  Let's not do that again.  We need
convergence tools.

> 
> > > I actually don't have any problem with there being some branch
> > > (whatever it's called) that has a very high standard for merging.
> > 
> > Neither do I, 
> 
> That's not the impression that I've gotten from the both of you
> throughout the whole scm discussion.  Today this is the g2 branch.

Then you've gotten the wrong impression.  As a matter of fact, if I
had everything /my/ way (a scary thought, I know, you can open your
eyes now) the standard would be far *higher* that it is now.  I would
name you the release manager for g2 and *only* you would decide what
goes into *your* tree (but it's all visible of course).  And it's
ready when you say it's ready and release it.  Then, there have to be
mechanisms in place to cultivate the "cloud" of code changes to swirl
around us, including you, and mechanisms to make it easy to for
everyone, including you, to grab arbitrary selections of those
changes.  You get the idea.  Anyway, I hope that clears that up.

> 
> > as long as there is an easier way of creating and reviewing lots 
> > of other branches / series of changesets.
> 
> I agree there needs to be an easier way to create branches.

!?!  Oh.  I should've read the whole mail before writing.  It looks
like we have some agreement here.  I'll just mention that it's not so
much the *creation* of branches which needs to be easy.  (It's trivial
now.)  It's the branch *management* that needs to be easier, and that
means the constellation of merge operations.

-chris