Tuesday, November 14, 2006

To publish, or not to publish: of love, overrides, and everything else

I've been asked to publish the speedups I've been making to VW in the public repository. Thank you so much for the interest!

Alas, this brings me a problem. I had decided to just publish updated versions of the base VW code in my local repository because then, when I update to a new version of VW, I can just merge stuff into the new version. In this way, I treat my changes as a branch that needs to be remerged...

... and it also saves me from dealing with overrides. Personally, I guess I have not learned to see their advantage, or that I am missing the point somehow. I tend not to use them because of two reasons.

First, Store tends to become more brittle --- my image has overrides due to loading parcels that came with VW, and now I cannot publish the parcel as a package and the modified bundle into my local repository without having at least one of them become dirty.

Second, overrides held in a separate package don't show you where the code was to begin with, and then loading them into a new version of VW just stomps over the other stuff. It becomes much harder to, say, compare the code before and after the potential changes.

But now that I am asked to share via the public repository, I can't simply publish new versions of VW 7.2.1nc, which is what I am using now. What to do...

... hmm, I wish there was some sort of "unit of work package" idea, something like a package in which you could say "all these changes are because of this reason". This unit of work would not own the changed code, which would still be published as versions of the base pundles. However, it would provide a good mechanism to load pieces of code into many different pundles in a controlled way, without owning the code by itself.

If units of work existed, I could simply publish them into the public repository, and upon loading others would get their base pundles modified. Or there could be an option on load: "load & modify", or "load & override" (in which case the unit of work would own the code).

One could even have these things have particular load requisites --- if the code in the image does not match what the unit of work expects to change, then provide a warning before loading the changes. And then, instead of talking about ARs, we could talk about "units of work" that improve a particular version of the system. Let's call these particular units of work "updates", put them in the Update Store Repository, and then you could simply invoke "Get Updates" from the menu because VW would come with a read-only anonymous account for the update repository.

I have a feeling that is what is missing here. In the meantime, I guess I will have to figure out some way to emulate it.

3 comments:

Anonymous said...

One of the things I keep meaning to write is something that can easily convert between the two forms. That is, given a published version of something (or even a group of somethings), generate a "patch" package out of the changes, that will contain the added/changed methods as overrides. Similarly, given such a package, take the methods and distribute them into the appropriate packages. There are a couple of possible issues with determining "appropriate", but I suspect it could easily do a good job for most cases, and require limited manual intervention for the others. One could even annotate the generated patch with version information about the versions of the original package. I think this would make it significantly easier to deal with some of these issues. Now if I could just get around to actually doing it...
-- Alan Knight

Charles Adams said...

I understand the dilemma of overrides. It is one I face every day it seems. I have several overrides of VW classes and have finally become comfortable that the system is stable even with these overrides in place. But it presents a problem to my customers. If I override the same VW class that my customer wants to change, he is forced to employ the override mechanism to introduce his change. If instead I provide a new version of the VW class (package) then my customer can either override or create yet another version.

There might also be issues with load order of multiple overrides on the same method. Not being particular adventurous, I tend to keep my overrides to more esoteric areas of the system code.

I appreciate the override mechanism, but I'm not convinced it should be in widespread use. As a patch mechanism, I think it is much worse than simply publishing the change.

Robert said...

I would like to think that we could leverage SOUL and LiCoR being available in the Store repository LiCoR
as Store evolves ...