Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Squeak VM tags (obsolete)
Last updated at 5:16 pm UTC on 16 January 2006

This is now obsolete; we use SubVersion instead. See Getting source using the SubVersion repository


What is a CVS tag?

A CVS tag is a String acting as a symbolic alias for a specific revision of a file. CVS creates its own revision numbers whenever a file is changed so we those are "hardwired". This means a file with three different revisions have those revisions numbered as "1.1.1.1", "1.2" and "1.3". Why the first revision is called "1.1.1.1" we can leave out for now, a "CVS thing".

If I want to take a snapshot of a certain point in time I could jot down all the current revision numbers for my 121 files on a piece of paper and then later, I could retrieve those exact revisions one by one. But that would hurt both my head and my fingers...

This is where tags enter the picture. Instead of writing down the revision numbers I "tag" those specific revisions with a single symbolic alias.

And later I can in any situation where I would refer to a revision number instead refer to this single alias. And since the same alias was used for all 121 files I can suddenly update all those files to the exact revisions I wanted with one simple command.

What characters can I use?

Quote: "The only allowable characters in CVS symbolic tags are uppercase and lowercase letters, digits, underscore (_), and hyphen (-)"

We do not use upper case letters and we use underscore as "space".

When do we use tags?

Tags are made when:

When using CVS, and especially with branches, tags are important and they become plentiful pretty quick. In order to avoid total chaos we use a few rules.

Recommendation: Only use the CVS "tag" command (and not the "rtag" command) when tagging. This tags the exact revisions you have locally in your workingcopy so that you do not have to worry about some other developer "sneaking in" some other revision when you are about to tag! Also first make sure you do not have any local modifications that you haven't committed.

What do we tag?

Tags can be placed on single files, but that can be very confusing. To begin with the rule is always tag ONE or more of the directories in squeak/platforms (Cross, unix, win32, RiscOS or "Mac OS") recursively. Typically this would be one of the port directories possibly together with Cross.


Release tags

Release tags are made by the primary port maintainer(s) when a release is made.

Release tags are of the form:

<label>-<arch>-<version>

...where <label> can be much anything like for example stable.
...where <arch> is the name of the architecture: win32, unix, riscos, macos
...where <version> is the version number using underscores like for example: 3_2_2

A typical release tag for Windows would be: stable-win32-3_2_2

Branch tags

We mere mortal developers who are not primary maintainers of a port use branches for development. The branches should be considered "shortlived forks" of a subset of the CVS file tree, and when something good has been produced on a branch it should be merged back into the trunk. The merging is typically done by the primary maintainers or by someone trusted by he/she/they to do it, and the branch will then typically be abandoned.

Branches (branch tags) are made on any of the following subsets of the file tree:
We do NOT create branches on subsets of the port trees or the cross tree - it will only lead to accidental commits onto the trunk!

Branch tags are of the form:

<branchname>-[<arch>]-branch

...where <branchname> can be anything like aio_experimental. It should describe the purpose of the branch.
...where <arch> is the optional name of the architecture: win32, unix, riscos, macos
...and the branch tag ALWAYS ends with "-branch".

Root tags

When you want to create a branch we want to make sure that we somehow can refer to the "root" of the branch. This is not done automatically for us by CVS so we must do at least one of the following things:

The best is to do the former because then it will probably be easier for the port maintainers to merge your work into the trunk since it is rooted at a known release. It will then be a clean patch against the relase. Consult the maintainers to decide which is best.

Branch example

You want to create an experimental branch for experimenting with the Unix asynchronous IO on the unix subtree of the CVS repository. You decided that you do not need the cross subtree. After having consulted the port maintainer for unix he told you that you should branch from the current trunk because some important changes have been made since the last release that he wants you to base your experiments on.

  1. Checkout the trunk separately or move over your workingcopy to the trunk.
  2. Tag the unix subtree on the current trunk with: aio_experiment-unix-root
  3. Create the branch with the branch tag: aio_experiment-unix-branch
  4. Don't forget to move over your workingcopy to the new branch you just created or check it out separately before you commit anything! :-)

Merge tags

When merging repeatedly from a branch to the trunk you need to mark the point on the branch where you did your last merge. Since we do not intend to merge in the other direction (from the trunk into the branch) we only need to tag the branch. For this purpose we use tags like:

<label>-merged-<x>
...where label can be anything like socket_bugfix. It should of course describe the stuff done on the branch sofar.
...where x is a number starting from 1 and increasing by 1 for each merge from the branch.

Other tags

When tagging an interesting point in time, use tags like:

<label>-[<arch>]
...where label can be anything like before_big_io_refactoring. It should of course describe the tag somehow.
...where <arch> is the optional name of the architecture: win32, unix, riscos, macos