On 4/20/05, David Shaffer <cdshaffer@xxxxxxx> wrote:
> That would be great. Still there are a small number of other overrides
> for various reasons. I'm always looking for ways to get rid of these
> but I think MC needs to be able to handle this.
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.
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.
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"...
Avi
|
