Hi,
It may be of interest to look at how we managed changes and conflicts in 
the OOram development.
-  The "program library" was a full image containing all our programs
-  Products were produced by stripping unwanted parts from the full image.
-  Every programmer could submit new classes and/or updated versions of any 
method.
-  Every submitted method had a new comment giving date and programmer name
    in a fixed format. Every method thus contained its change history
    in its initial comments.
-  A command in the ChangeList checked incoming methods against the one in 
the image.
    A conflict was flagged if one or more change comments in the image were 
missing
    from the incoming one.

Squeak already stores the programmer's initials with the method. It could 
be augmented to store the method's change history - possibly only updated 
when the method was filed out, e.g., to BFAV.

Regards
--Trygve

PS.
I am truly impressed with he Squeak community. I posted a question on Nov 
04 18:45:20. An answer that resolved the problem was posted Nov 04 19:21; 
36 minutes later!!
Many thanks to Ned Konz and Edgar.






At 15.11.2004 07:01, you wrote:
>"Thomas Koenig" <tomkoenig at mindspring.com> wrote:
>
> > Marcus, I see you've done a lot of reviews that resulted in conflicts.
> > One of the more tedious parts of reviewing fixes is looking to see if
> > they would regress some other change. Is there something special you are
> > doing to check for conflicts in the BFAV posts?
>
>I belive he is using ConflictChecker (It's on SqueakMap).
>Doug made this to check for conflicts before putting stuff in the update
>stream.
>
> >
> > You asked:
> > > Should we not add the conflict tag as a type tag for BFAV so posts
> > > with conflicts can be sorted under a conflicts tab. Fixes and
> > > enhancements with conflicts are a special condition and should be
> > > easily identified, and this would make BFAV easier to overview. Right
> > > now there is no way to seach for a post with conflicts.
> >
> > I could make this change to BFAV if we really want it. However, it
> > strikes me that "conflict" is orthoganal to the harvest status dimension
> > that the tabs represent.  We've already added 'bugs' as another
> > non-orthogonal aspect to the tabs.  Do we really want to continue that
> > way?  The answer may very well be yes because bugs and posts with
> > conflicts merit special attention. If so, would the order be bug,
> > conficts, reviewed,approved, update, closed, all?  With a post being
> > made a conflict unless it's in the approved, update, closed status?
>
>A way of filtering out posts wich have conflicts
>or who needs more work would be good. These posts are reviewed
>but are in special need of attention and right now they lurk around
>forever. Just closing them is often not satisfactory as they are not
>rejected, yet, they just need some attention and massageing before
>going in. We could have a timeout of a couple of months on the
>conflict/needs more work status before we close the post.
>To put these post in a special group would make them visible
>and clear up the process quite a bit.
>
> > The other way we have of filtering are the three (not quite) regular
> > expressions: name, e-mail address and title.  We might sacrifice one of
> > these (name and email are redundant for my purposes) and add logic to
> > search on the labels.  This might allow us to search for conflicts (or
> > any other tag we decide to add latter
>
>Maybe just expand to search all labels not just the group labels would
>do it ?
>I'm not quite sure how to do that though....
>Karl


-- 

Trygve Reenskaug      mailto: trygver <at> ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway