Hi all!

Keith Hodges keith_hodges@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