On Jul 14, 2004, at 7:25 AM, danielv at tx.technion.ac.il wrote:

> For example, I reviewed a patch, it seems sane, I file it in. I keep on
> working, and testing other patches, until I have a chance to notice 
> some
> bugs come up that are related to that patch. So we shouldn't assume a
> stack discipline to patch application.

But if you're testing multiple patches at once, what you're really 
testing is whether or not to patches can coexist.  Which is a good 
thing to test (and probably deserves a version of its own, with a 
commit message like "successfully merged changes A and B, had to make 
minor tweak C"), but you should have tested them in isolation first, 
surely?
If you were really careful, you would use a "stack discipline" in your 
day to day development, too.  That is, the ideal thing from 
Monticello's point of view would be that, every time you started a new 
set of changes, you reverted back to the earliest version that could 
support them and continued from there.  If the next changes you make 
are unrelated to those, you revert back again and branch.  Then if both 
of those changes are required to do the next changes, you merge the two 
resulting versions and use that as the baseline going forward.  But you 
shouldn't do them linearly, because that implies to the versioning 
system that the second changes are dependent on the first, and you'll 
have trouble if you later want to use them on their own.
Now, I don't do this much in practice, because it's a hassle, and not 
the way I'm used to working.  But it would be interesting to see if 
this awareness of the dependence and independence of sets of changes 
could be integrated into the development environment well enough that 
it was a natural and pleasant way to work.

> Also, I might later on have
> additional comments to add that are related to that patch like "also
> appears to solve the X bug", even without changing the code.

Oh, I'm not really suggesting that the commit log be the only source of 
comments.  We definitely want some kind of bug-tracking system that's 
connected to all this that is organized by thread, not by version.  But 
I think the traditional "issue" is more appropriate here than "patch": 
as in the BFAV, you want to track comments and associated 
changesets/versions right from the time the bug is reported to the time 
it's closed, not just the history of a particular changeset.  It sounds 
like the question you're asking is "how do we replace the BFAV", and I 
was trying to answer "how do we replace the update stream".  I think 
the answer to the latter will inform the former - except we won't 
really replace it, just migrate it to a slightly different workflow.

Avi