Avi Bryant <avi at beta4.com> wrote:
> > I think to replace the BFAV-centric process, MC needs to deal with some
> > of the same, and some new concepts:
> > 1. Instead of global "approvers", MC should let each user have a list 
> > of
> > "repos I monitor".
> 
> Doesn't it already?  Though I admit that "monitor" needs to be fleshed 
> out: what I want is for it to automatically download new versions it 
> finds in those repositories to the cache, and inform you of them - I'm 
> picturing repositories being treated something like RSS feeds.
You're right of course, I intended mostly to show the mapping - the 
monitored repos replaces a current concept. This also shows what 
enhancements would be beneficial in this context - ideally, Dougs
version
would use his monitored repos list to produce something very similar to
the BFAV window with the "approved" filter.


> > 2. In addition to existing concepts, we need "patch" or "change", which
> > aggregates some of the stuff an update does -
> > a. Set of specific changes to a package (or a few?)
> > b. Documentation of the change (as a change, besides code comments and
> > so forth)
> > People should be able to look at the list of patches in someones
> > repository, not just the code diffs compared to his version. People
> > should be able to take/reject/remove specific patches.
> 
> You can already look at the diffs between two arbitrary versions 
> (though I admit the UI could make this more obvious).  And there are 
> already commit logs for each change you make (and a given commit should 
> really only encompass one or two changes). 
I'm not convinced the concept I'm talking about should be mapped to 
versions, but maybe. To make sure we're talking about the same use
case - during a month I apply 20 fixes from the BFAV (not everyone is 
using MC (yet)). Doug was hard at work, comes back and sees I've 
got some patch I've commited 3 weeks ago (presumably I'm happy with
them) and something suspicious I put in this last week, and also a fix 
I took in at the beginning of the month. He should see the separate
patches
at a glance, and those he decides to adopt should survive intact with
their
former documentation (posters characterization, my review/notes..).
He should also be able to merge in or reject any of the above, without
much
regard to time, at least as long as they touch disjoint sets of code.

If the right way to do this is to have a version for every patch I
filein,
then it would be a good thing to MC to detect such system operations
and version before and after them automatically. I know the lack of this

feature was a great annoyance with change sets.

> But no, there's no easy way 
> to apply the diff between two versions to an unrelated third version.  
AFAIU, they should not be unrelated versions - MCing people will be 
synching with Dougs repository quite often. Maybe I'm missing 
something?

> The problem is that this has unspecified ancestry semantics: in what 
> way does it affect future merges?  Should it not change the ancestry of 
> your image at all, and just be as if you had independently made those 
> same changes?  If that became a common practice, we'd make automatic 
> merges much messier down the line.
I think we should whatever is possible to make sure that merges do not 
become more messy, since we'll be doing lots of them. For example if we 
want to handle the file in of other formats as mentioned above, and 
suppose to people filein the same code separately, it would be nice if
MC 
knew the common ancestry (say, by using a content hash on the file). 

(not sure whether I replied to your question, btw, if not, I didn't get
it :-)

BTW, at the moment I'm not particularly trying to make this
easy/incremental
on MC, but instead to think about what's need to make it easy to do the 
process. Its important to think whether this can be done in small steps.

Daniel