Chris Shoemaker's (Jul) patch for account-*-balance refactoring and code

[Chris Shoemaker]

On Sat, Oct 08, 2005 at 10:07:36AM -0400, Josh Sled wrote:
> On Sat, 2005-10-08 at 01:08 -0400, Chris Shoemaker wrote:
> 
> > Here's what happened: At some time long after sending those patches, I
> > made more changes to Account.[ch].  Unless I go out of my way to make
> > a new patch containing just the new changes, the new changes just get
> > wrapped up into the same patch when the patch is refreshed.  Since the
> > patch I sent hadn't been ack'd, nack'd, or commented on, I figured it
> > would be ignored until I resubmitted, so I didn't make a new patch.
> 
> I'm a bit confused, here.  Why didn't you just cvs update the
> patched-changes into your working copy and re-generate the new patch of
> just the other changes?  Why is patch-generation 'out of [your] way'?
> 

Hmm. I wish I'd thought of that.  That probably would've been the
easiest way.  Just to explain: The reason I didn't think about it is
that it's kind of orthogonal to my normal workflow.  I never keep
patched trees around, just the bare patches.  Normally, there are
never any changes in my tree when I do a cvs update, so there are
never any conflicts.  Here's why: If there are any applied patches
during the update then quilt will mistakenly think that the updates
that came from cvs should be in the refreshed patch.  So, I have to
pop the entire patch stack, cvs update, and then re-apply my patch
stack, resolving conflicts as I go.

In the future, I think I'd resolve this type of problem post-facto by:
checkout cvs versions from before the apply, manually apply my patch,
do a cvs update, and cvs diff to get a new patch.  Quite simple,
really, just completely different from my normal workflow.  Thanks for
pointing that out.

> 
> > Another solution would be to only apply patches "soon" after
> > submission.  IOW, we'd agree that the patches expired after some time,
> > and I would be free to change and resubmit after that time.
> > 
> > Any other suggestions or ideas?
> 
> Patches should be applied quickly; this was just a failing on our side.
> I probably should have checked if you still "approved" the patch, given
> that it was so old and I know you're making other changes.  (FTR, I did
> ask about the INLINE_FUNC patch and haven't heard a reply yet... :)

Sorry, I missed (or forgot?) that, I'll go look it up and respond.

> 
> I'm not sure what else can be done... there's an inevitable drift
> problem as the patch ages and the tree changes independently.  I think
> the only solution is to have less outstanding patches.  To me, this
> means: smaller patches applied quickly, so your pool of outstanding
> patches is small.
> 

Agreed.  I'd love to reduce the size of my patch stack.

> 
> It doesn't sound like it's useful now that you've gone through and done
> the work, but we can revert those changes if you want.
> 

No need.

-chris

> ...jsled
> -- 
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`