Monticello bugfixes

Colin Putney cputney at wiresong.ca
Tue Nov 9 03:21:43 UTC 2004


On Nov 8, 2004, at 2:29 PM, Chris Muller wrote:

> Hi Colin, thanks for looking at my suggested fix.
>
>> Here's the example I was working with: Consider three packages A, B 
>> and
>> C, where A requires B and B requires C. With A and C both dirty, we
>> save A.
>
> This would not expose the problem.  To see the problem, start with A, 
> B and C
> not dirty, then make a change to C.  Note the problem, neither B or A 
> are
> marked dirty when you do this.

What you say is true, but in and of its self, this is not a problem. 
Neither A nor B are, in fact, dirty.

> Saved MCVersions refer to specific-versions of their prerequisite 
> packages by
> UUID.  However unsaved MCWorkingCopy's refer to them by *name*.  This 
> allows
> the in-image tree of MCWorkingCopy's to represent a declaration of 
> code for an
> entire "working-configuration" of packages.  But merely saving the new 
> version
> of C is not sufficient to be able to load "A" into a fresh image and 
> get back
> to the current working-copy state.  That's because the top-version of B
> currently saved in the repository still refers to the prior version of 
> C (by
> UUID) unless you somehow remember to *resave* B so that it points to 
> the new
> UUID of C, which is hard to remember because it's not shown as dirty.

To create a version of A that reconstructs the state of your working 
copy, all you have to do is save A. You can do this even if A isn't 
dirty, and doing so will automatically save B and C as well.

> So, put another way, the pain stems from the fact the code in the 
> "workspace"
> cannot simply "worked" into a state the developer desires and then 
> save all
> dirty packages and be assured they will load to the same state on a 
> naked
> system somewhere else (if they will load at all, because if the UUID 
> defined as
> the prereq isn't found in the repository, Monticello reports 'not 
> found' and
> you're stuck).

No, you can't do this by saving all the dirty packages. But you can do 
it by saving the top-level packages - that is, the packages that you'd 
like to reconstruct in another image. Is there some reason this isn't 
adequate?

> I feel this is more than a mere "convenience notification" feature.  I 
> consider
> the prerequisites as part of the declaration of a package.  Therefore,
> "Changes" for any package would normally account for the prerequisites
> (currently, they don't).  But one step at at time.

I'm very reluctant to take the approach of propagating the dirty flag 
up the dependency tree. What worries me is that the affected packages 
aren't really dirty. There are many areas of the code, however, that 
use that dirty flag and expect it to be accurate. The user also has a 
reasonable expectation that a package marked dirty really has changed.

Consider this example, again using packages A, B and C. What if you 
make a change to C, then save the image and come back to it later. You 
notice that A and B are dirty, but don't remember changing them, so you 
click the Changes button to see what has changed. Not only won't there 
be any changes, but the package will now be marked clean. Now we could 
adopt the rule that when we reset the dirty flag we first check the 
dependency tree to see if it contains any dirty working copies. This 
might work, but there are several other places in the code we'll also 
have to modify in similar ways.

Ultimately what you are proposing is to change the meaning of dirty. 
Currently it means "the code in this package has changed since it was 
loaded." Your definition would add, "or one of the packages it requires 
is dirty." These are two separate pieces of information. By lumping 
them together we loose the ability to distinguish between them. Right 
now, the code examines both pieces - whether the package is dirty, and 
whether its dependencies are dirty - and does the right thing based on 
both of them.

Now, it's possible that our current notion of the "right thing" is 
wrong in certain situations. Do you have a situation where saving the 
top-level package isn't enough to reproduce the state of the code? If 
so, perhaps we can work out a solution that doesn't involve changing te 
semantics of working copies.

Colin




More information about the Squeak-dev mailing list