Forgotten patch: qofid.diff

[David Hampton]

On Fri, 2005-10-28 at 21:19 +0100, Neil Williams wrote:

> Yes, a local, working copy that contains files that you are actively modifying 
> is just a local, uncommitted and unreviewed branch. It is precisely at this 
> early stage that others can be most useful in the peer review process and 
> where interventions are easiest to incorporate into new code.

So why not create a real explicit branch in the repository.  Commit to
your heart's content, and anyone else can check out your working (or
non-working) code.

> > order to merge E->D.  Of course, what we *want* to do is not really
> > merge E->D, but only merge the delta from B to E into D. 
> 
> Yes, what I want is not the makepatch from forge to old local, I want a 
> makepatch that synchronises forge with working WITHOUT losing the changes in 
> the working tree. It's complicated and not easily automated with current 
> tools. Current patching tools simply force the old tree to become the new - 
> byte by byte, what I need is to merge the *changes* from forge into the 
> developing code in working/ without losing other changes.

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.

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

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

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

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

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

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

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

> Which is why cashutil was mooted as a potential SourceForge project and why it 
> still has a back-alley feel because the current CVS isn't publicly accessible 
> (the server wouldn't take the load).

Is there some reason you're not doing this work in a branch of the
gnucash repository?

David