Torsten.Bergmann at phaidros.com wrote:

>We need something to uniquely identify a piece of code (class, changeset, 
>method version) or running object (application, object, project ...) in
>squeak.

Why?

Let's talk about TEAM TOOLS here.  Let's assume that a team tool should
help people who participate on a common project to share their work.
Simple that is.  So my question is: What's the best unit of work that can
be shared?  A class?  A method?  I doubt.

IMHO one would like to share the results of tasks.  A task could be as
large as implementing the next milestone or as small as fixing an annoying
little bug.  Sounds like a change set IMHO.

To ease distribution of code, one might want to additionally share complete
sets of code, ready to install in other systems.  These sets must also be
removable and/or replaceable by other versions.  Let's call them modules.
They're a name, a number and consist of a set of class and method
definitions - optionally plus some initialisation and uninitialization code.


Now let's look at VERSIONING and understand that this aspect is unrelated
to the team sharing aspect.  You want to keep a history of your work.  You
want to  look back, go back or compare.  But versioning is no replacement
for an undo/redo facility which is nowadays standard in text editing tools.

Versioning is something like snapshotting your image and still being able
to compare single classes or methods.  You want to reload a class or two or
undo some method deletions.  Versioning should be possible even if you're
working alone.

The Smalltalk change set fullfills most (if not all) of these requirements
but a better gui would be helpful.

Keep in mind, these are minimal requirements but I'd like to see these
relalized then endless talking about what the complete set of features is -
if I'm allowed to choose ;-)


Can CVS be used to implement this?  I think, it can.  I believe, you can
even replace the current flat change set with an CVS based approach.  Torge
and I talked about this at lunch today.  Create a directory per class (and
name it the same).  Create a file per method (for more reliability, the
file name should consists of the class name and the method name; you can
replace : with _ and have a standard replacement for all binary selector
characters) and store it in that directory.  Add another file for the class
description which contains name, superclass name, variable names (for all
kinds) and - this is most important - name and version for all methods.

The result looks very much like ENVY - if done right.  Where's the
advantage?  Well, you can build on proven technology which already has a
working client server mode.  You omit envy's one-big-unknown-contents-file.
 It's no closed source and -- hopefully - less expensive.


And if you don't go for ENVY (Doug, I'd really like to hear your arguments
why you think ENVY's approach is better) but follow by ideas about what
sharing units of work means, CVS looks even better. 


>What about UUID's (Unversally Unique Identifiers) from the DCE standard.

PS: I really want to know how to create these numbers.  Does anybody have a
pointer to some description of the algorithm?  The address Torsten
mentioned leaves out the implementation aspect.  All I found was that UUID
as standarized by some ISO-115xx (I forgot the number) norm.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.