[Seaside] Toggle Halos issue

[C. David Shaffer]

Avi Bryant wrote:

>MC handles branching and merging much better than it handles
>overrides.  In general, rather than overriding a package's methods, I
>think a good strategy is to publish a branch of that package that has
>the modifications you want.  Anyone loading, say,
>SeasideTesting-cds.32 would also want to merge in
>Seaside.seasidetesting-cds.32.  This wouldn't let them publish
>Seaside, but it would accurately record what had happened if they did.
>  
>
How would I track my overrides?  Looking at the diffs from the base
version?  I'm not really fond of this idea but maybe I just need time to
let it sink in.  I'd like something more natural but I appreciate that
what you are suggesting gets us part of the way there.  In VW, for
example, it keeps the source to the overridden methods.  I have heard
some grumblings on vwdev about people having problems with this but I
personally use it a lot and never had any lost code.  (I think that the
people having problems didn't correctly indicate that they were
overriding a method in a different package...you have to use the tools
properly for it to work!).

Now that I think about it...can we back up and be more explicit (all
version numbers are ficticious):

My development image:

   --- from where I am now ---
   1) Load Seaside-avi.10
   2) Publish (in a public repository) Seaside.seasidetesting-cds.1
   3) Load SeasideTesting-cds.932   (I publish way too often)
   4) Make changes that I need to Seaside
       (and move them out of *SeasideTesting-override* category) and
publish Seaside.seasidetesting-cds.2
   5) Publish SeasideTesting-cds.933
   6) Write a script which:
       loads SeasideTesting-cds.933
       merges Seaside.seasidetesting-cds.2   (yes, keeping the version
numbers equal is a good idea)
       that script becomes my SqueakMap load script

   ----- a new release of Seaside comes along -----
   1) merge Seaside-avi.11
   2) publish merged version as Seaside.seasidetesting-cds.3
   3) (publish new SeasideTesting if needed)
   4) Write new load script

   ---- I create a new devel image to move to 3.8 or whatever ----
   1) Load Seaside.seasidetesting-cds.3  (no need to load
Seaside-avi.11, right)
   2) Load SeasideTesting (most recent).

>From a ST user's point of view:

   1) Load Seaside-avi.10 (via SqueakMap or whatever)
   2) Execute my load script which will give them an error if it sees
that they are trying to merge Seaside.seasidetesting-cds.3 with an older
version of Seaside and a conflict exists.

> It would also warn them before loading a new version of Seaside that
>they were about to blow away the changes.  And it would give the
>notification you wanted that the modified methods had changed in the
>meantime, in the form of a merge conflict.
>  
>
How are they going to get a merge conflict if they "load" the most
recent Seaside into an image with ST already in it?  I would think it
would just blow away my overrides.  Maybe I just need to try it.  Now, I
can see the other way around that if I load Seaside and then merge in my
branch that I will get merge conflicts...as described above.

>
>The biggest hassle here is how you distribute such a thing - right now
>the only way would be as a small script that requested that MC merge
>one version and load the other.  What we probably want are "merge
>dependencies" as well as "load dependencies"...
>  
>

Can I merge in code and catch a notification or something to avoid
raising the merge dialog?  An experienced user could always manually
merge in my branch and deal with conflict resolution so this does not
present a real barrier to loading ST.

I don't understand your wording: "...requested that MC merge one version
and load the other."  Just to make sure I understand, I want it to load
then merge as described above, right?

Maybe this discussion should be on the MC list?

David

-- 
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com