Forgotten patch: qofid.diff

Fri Oct 28 16:19:52 EDT 2005

On Thursday 27 October 2005 4:36 am, Chris Shoemaker wrote:
> > We need quick and open ways to publish *early* code - pseudo code if you
> > will. Designs, plans, ideas. Rough hacks, concepts, logic. Code that is
> > certain to break the sacrosanct CoreBuild. Branches are part of the
> > answer but, as Derek pointed out, technology isn't the answer to
> > sociological problems.
>
> I know nobody liked my ideas about branching, but maybe I'm just using
> the term differently than others. 

It's certainly how I understand the term. I use makepatch to handle my 
changesets but my process is long winded:

1. Ensure all changes are in local CVS from /opt/working but do NOT update my 
own pristine source in /opt/devel
2. cvs update in /opt/forge that contains the pristine gnucash source.
3. makepatch with /opt/devel as old and /opt/forge as new. This gives me a 
single patch that covers all changes since my last commit to remote CVS.
4. View the patch and check for conflicts with files I've been changing 
locally. This is a time consuming stage.
5. Copy files around if I haven't changed them myself and hack remote changes 
into my modified files. Resolve conflicts and post to the list!!!
6. Now update /opt/devel with my local changes and the remote changes and my 
hacks to combine the two.
7. Remake the makepatch to see what I might have missed.
8. Set the scripts running to build various trees (6 at present count) while I 
go off and do something different.

> There's a interesting case-study 
> right here.  In my view, *every* time you're writing code, you're
> implicitly branching whether you realize it or not. 

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.

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

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.

CVS patches the remote files to be exact copies of my local files which is 
wrong. 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.

> Now, I've seen this pattern probably 20 times (not with gnucash) and
> it can get pretty hairy.  The only time this process doesn't really
> suck is when I know somebody's been merging my code, and exactly what
> state they were merging from, (like now).

Which is why we NEED more publication of the DEVELOPMENT code, not the 
finished "CoreBuild" code.

> IMO, this is a PITA, because I *REALLY* DON'T WANT TO CARE who's been
> doing whatever with whatever I've written.  I'm *sharing* my code for
> a reason: I want other people to benefit from it.  That benefit is
> severely diminished if it's a pain for other people to independently
> improve my code and still retain my further improvements, too, or if I
> have to keep tabs on everything that happens to every revision of my
> code just to make it *not* a pain to incorporate further improvements.

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. The ONLY reason for that is the insistence on 
not breaking the CoreBuild.

I don't know if my changes will break the build when placed on top of someone 
else's changes, I only know that they do NOT break the build when placed over 
the code BEFORE that person's changes. To avoid being flamed (again), I have 
to delete the entire commit patch and start all over again. WHY? (fear).

> 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, as long as there is an easier way of creating and reviewing lots 
of other branches / series of changesets.

> Now, I certainly don't want to be the one responsible for maintaining
> it, but I'd sure have a healthy amount of respect for anyone who did.

We would have to share that burden - when our own branches DO get to 
finished / build-ready code, not before.

> 1) stream a bunch of patches to -patches that don't always compile,
> are obviously incomplete and ugly, have dependencies higher than our
> target release, probably break the build, and probably shouldn't be
> applied by anyone not working on the register rewrite; and hope
> Didier's tools are handy enough to autosuck patches from email (oooh
> distributed development 1980's style)

Not the easiest way for others to review the code - I found it quite hard to 
compose that reply to your budget code about the QofClass because reading a 
diff in an email client isn't natural.

> or 2) take this into a back-alley and get some real collaboration
> going, even though it'll be in relative isolation from the people who
> have the most to offer in terms of assistance.

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

> *sigh* Ok, I'm done.  :( Please include the word FLAME in the subject
> of your response if I'll need my asbestos underwear.

Not from me, I'm right in the dog-house with you, Chris!

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-patches/attachments/20051028/ad243295/attachment.bin