Hm, maybe it is about time I should write one.
To begin please help me identify the problems your are having with
understanding how STS works or is supposed to be used.
For us, a development session with STS looks something like I will
describe in the following use cases:
The environment:
================
- a clean Dolphin Smalltalk image with only STS installed
- STS repository database where all your work is kept (project and
package versions), this can be either a shared repository on a network
drive or a local one on your notebook
A typical workday:
==================
Step 1: Start a clean Dolphin Smalltalk image
Step 2: Load the last version of the project you are working on
Step 3: Do the usual development/testing
Step 4: When you are finished with your work(day) version all packages
which are changed and release the loaded package versions into an open
project edition. Version the project if it will be delivered to the
customer or another developer, else you can keep it as an open edition.
Step 5: When you exit the image you do not have to save it.
A typical merge session:
========================
When it comes to sharing code with other developers or when two
developer work on the same Dolphin Smalltalk repository a typical merge
session looks like this:
Step 1: Import the code from other developer into the repository to
which your image is connected. This can be done either by importing
Dolphin .PAC files or by importing all packages using an XML project
export format (PEZ or PEX files).
Step 2: Load one version of the project into the image, this can be
either your version or the version of the other developer.
Step 3: For each package in the project compare the loaded code with the
other version. A changes browser will open.
Step 4: Using the changes browser (aka comparison browser) go over the
list of changes between both versions and decide whether to accept the
code on the left or the code on the right side. If there is a conflict
in a particular method, double-click on the item and manually merge
changes from both changed versions. Use the button "Next difference" to
see which lines in the source code of a method have been changed.
Step 5: After all changes from the other version are loaded in the
image, make a new version of each package and create a new merge version
of the project.
Step 6: Export the merged project version so that the other developer
will have the same codebase for further development.
Discovering what has been changed from version 1.0 of you product to
version 2.0 of the product:
===========================
Step 1: Open package editions browser.
Step 2: Select version 1.0
Step 3: By holding the Ctrl key, select version 2.0
Step 4: Right click and select "Browse changes"
Step 5: A changes browser window will open with a list of all changes
between the selected versions.
....
The text above describes how STS is most often being used. I hope this
gives you an idea of what can be achieved by using STS. If you have
further needs we can look at how it can be achieved by using STS.
Best regards,
David Gorisek
http://wiki.gorisek.comSean Malloy wrote:
>>I have a suggestion. If no one does this, maybe you can write one, and
>>those who have used it can help point out any mistakes or otherwise learn
>>from it :)
>
>
> I'd write one if I knew what the hell I was doing. It'd be done already!
>
>
Locked
