goran.krampe@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
packages@lists.squeakfoundation.org