local SqueakMap's (was Re: Feedback)

[Lex Spoon]

goran.krampe at bluefish.se wrote:
> > Clashes seem like a fine strategies as well.  Notice that they also seem
> > to happen whenever you do an "update" from a more public server; changes
> > that have been committed locally, may turn out to clash with something
> > that happened upstream.
> 
> Well, in general systems yes :) but in SM, no, not really. Because
> locally you will only modify your own account - modifying other parts of
> the map is a general "no, no". If you do that, then you are on your own
> IMHO. :)

Okay, if it helps then this constraint does not seem too onerous.


> >  Going the clashes route, it seems like the
> > model now needs to have support for "stuff killed off by an update from
> > upstream", plus some way for the local users to fix up the situation.
> 
> Yes. Typical issues when committing are:
> 
> 	- You created a package (or some other artifact with unique names) with
> a name that already exists.
> 	- Your SMObjects refer to other SMObjects that do not exist anymore
> (categories could be removed, package releases also etc, etc)
> 
> ...but without giving it tons of thought I do think the above two things
> are mostly it.

Okay.  Just wait until you try to write a "merge" method.  :)  You'll
find the cases in a hurry!


>  
> > I guess another general approach, is to try and rename the UUID's
> > locally, in order to undo the conflict.  I don't know if this is doable
> > or not.
> 
> Hmmm. Not sure I grok that. :)

Bah, let me write it more carefully.  Suppose you add a package "Foo",
and someone else adds a package "Foo" upstream.  One solution is that
the tool automatically renames the local Foo to be Foo2 in order to
avoid the conflict.

It also works at the ID level.  If you make a package with ID 1234, and the
upstream server also used ID 1234, then change your package to use 5678
and update all references to your package to use the new ID.



> > And (heck) a fourth, is that you change from UUID's to server-unique
> > ID's.  So when you refer to an ID, you have to know which server it
> > pertains to.
[...]
> Which means that, perhaps I didn't write it, but the server marker in
> each SMObject makes sure it has a "home server" in the server "tree", [...]

Cool, this home marker you describe seems like a fine way to implement
this fourth strategy.  An ID does not have to just be a number; it could
be a tuple of (home-server, number).  Then, even if two different
servers use number 1234, it is okay, because the full identifiers will
have different home servers.



> One way of making mixins simpler might be to restrict mixins to be a
> leaf thing. I mean, the servers are all in a tree like I describe but
> the leaf (localhost) could possibly use mixins and take the heat of that
> locally. But again, I would gladly wait with mixins until later.

Yes, that would be workable if it helps.  It's nicer if servers can pull
from multiple locations as well, but if that's not possible, it could
always be placed in the map's top-level comment, just like dependencies
are described in pacakages on SqueakMap of today.

Is it a mixed blessing to push it down to the leaves, though?  It seems
like once you have accepted the pain of dealing with conflicts from
upstream, it might only a small additional amount of pain to deal with
conflicts from multiple upstream pointers?



Lex