Hi all!

Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> Some thoughts
> > The future , as Goran said on Supertool, is not Monticello.
> > Monticello is good for some, but is not the silver bullet.

Btw, I don't think I said anything like that. :)

> I dont agree with this SuperTool is the future approach, having lived 
> with MC2 is the future for all too long.
> 
> It has taken years for the use cases to form around the current tools 
> and some of these are non trivial. I expect any new tool will do the 
> easy stuff and fail to do the difficult stuff and we will be back where 
> we started.

Note that IMHO DeltaStreams is not meant to replace MC/MC2. I see them
as complementary, at least for the foreseable future.

So the idea is to make DeltaStreams be good at its primary job - which
in my book is not the same as MC/MC2 tackles.

Also - it is driven by another principle - instead of making a very
smart tool that handles "difficult stuff" I want DeltaStreams to be
relatively "dumb" but through that dumbness enable developers to use
them and leverage them in a variety of ways and in situations where
smart tools fail - like for example harvesting "foreign fixes" into a
forked image which is quite different.

Sure, this all sounds ruther fuzzy - I agree. :)

> It takes a lot of effort and "going around the loop"  to dot 
> all the i's and cross all the t's. So I think we would be better off 
> actually finishing one tool (MC) or even its successor (MC2) before 
> starting on another.

Well, it is not an "either or" situation. I would probably never muster
to contribute to MC/MC2 - but I do feel strongly for DeltaStreams.
Others feel different of course.

> For example the case where you want to maintain several versions of the 
> one method in the image:
> 
> You want the original method to stay with its original package so that 
> when you save the original package that package does not get broken. You 
> want your changes to stay with your package so that that does not get 
> broken. This is not as easy as it sounds.
> 
> A second example, however you do it,  the out-of-order loading supported 
> by MC1.5 requires a cache of not-yet-loadable elements, I call this the 
> orphanage. Orphans get rehomed once the parents arrive!

Both situations sound like they perhaps are not in the primary field of
DeltaStreams.
And if they turn up as interesting problems to solve in the context of
DeltaStreams I believe they would be approached differently - the first
one possibly by using a "patch queue" approach as Mercurial has. The
second at least partially by loading Deltas out-of-order.

But again, I don't want to solve the same problems as MC/MC2 is trying
to solve - nor using the same ideas.

> So whatever tool you come up with will have the same basic elements, 
> like MC1 has MCMethodDefinition MCClassDefinition 
> MCClassVariableDefinition etc and a loader to apply them, browsers to 
> look at them, differs to compare them etc. Why have 1 technology when 
> you can have 4. (MC MC2 SuperTool and SystemEditor)
> 
> I mention SystemEditor because I think that a persisted system editor 
> would make a useful binary package distribution format which only needs 
> SystemEditor to atomically load!

I consider MC/MC1.5/MC2 to be variations of the same tool. They all are
our preferred advanced SCM tool(s) for maintaining packageswith full
defined history and advanced merging through that.

SystemEditor is IMHO not a tool but a low level library, at least at
this point.

DeltaStreams does not try to replace the MC-family. It tries to
complement our toolbox by offering a fine granular "pipe network" for
enabling a flow of fixes/enhancements between teams/forks/projects.

It could also work as a "commit tool" for grouping changes, temporarily
hiding or reapplying changes (patch queues) and possibly even replace
the .changes file eventually. This would then work just fine on top of
any of the MC-family tools - just like ChangeSets do today.

> MC supports Diffs in theory, so the "packages are too big" argument can 
> be tackled.
> 
> I started to add changset support to MC1.5 as well. This makes sense 
> because MC already has browsers for all this stuff.
> 
> By all means improve the recent changes and change sets support, this 
> will help all tools to work better. But is the changeset functionality 
> not wired in a deep way in all of the forks that this is aiming to 
> support? Migrating everyone to this new scheme is not going to be easy.

I am not envisioning a migration away from the MC-family.

> Personally I think that MC1.5 with SystemEditor working (MC1.5 is ready 
> its SystemEditor that is not trested) would be a winning combination. I 
> also think that MC can be simplified and slimmed down a lot with 
> SystemEditor support working.

That sounds reasonable and I really like that work on the MC-family is
revived like this.
 
> I am disappointed that we are unable to raise the effort to get 
> SystemEditor tested and usable. This is a bottleneck for all the 
> initiatives which want to use it MC1.5 MC2. and Supertool, so I think it 
> should be THE priority task. (I am a bit snowed under for now myself)

I don't yet have the insight into it to make much - but since I intend
to use it I guess I will eventually get there.

> sorry for being overly cynical

No problem! All views are valid in some sense.
 
> Keith

regards, Göran