The Tcl and Tk source repositories can be found at
The version control system used for these is Fossil.
The remainder of this page follows Fossil's generic Quickstart Guide , modified to suit Tcl/Tk development.
Prebuilt binaries for the major platforms (Linux, OSX, Windows, BSD) are available at http://www.fossil-scm.org/download.html Building it yourself is of course possible as well.
Fossil works with repository files (a database with the project's complete history) and with checked-out local trees (the working directory you use to do your work). The workflow for Tcl and Tk looks like this:
First, clone the repository
fossil clone http://mirror1.tcl.tk/tcl tcl.fossil fossil pull http://core.tcl.tk/tcl -R tcl.fossil fossil clone http://mirror1.tcl.tk/tk tk.fossil fossil pull http://core.tcl.tk/tk -R tk.fossil
We are using mirror1 because the repositories are large and http://core.tcl.tk/ is bandwidth-limited. To prevent fossil from remembering the wrong url for pushing we then follow this by pulls from the proper repository. This will also import all changes which were pushed while we were cloning around.
Then create local checkouts to work with (using Tcl as example):
mkdir /somewhere/tcl cd /somewhere/tcl fossil open /wherever/you/have/tcl.fossil
Now you have the most recent revision of Tcl's trunk (ex-CVS HEAD) in the directory. Hacking can commence.
To fix issues in a specific branch, for example "core-8-5-branch", we have to create a local checkout which contains the sources of said branch. We can do this in two ways:
For one, create a new checkout and tell it the branch put into the checkout:
mkdir /somewhere/tcl-core-8-5-branch cd /somewhere/tcl-core-8-5-branch fossil open /wherever/you/have/tcl.fossil core-8-5-branch
For two, reuse an existing checkout and switch it over to the desired branch
fossil update core-8-5-branch
The set of open branches can be discovered by invoking
fossil branch list
from within a checkout, or via
fossil branch list -R /wherever/you/have/tcl.fossil
if no checkout is available.
When fixing an issue start doing that at the oldest branch you wish to support. When the fix is done sequentially merge it up to the newer branches, following a stair-case pattern.
For example, start the fix in "core-8-4-branch", after committing merge 8.4 to "core-8-5-branch", and lastly, merge 8.5 to trunk. Do not follow a star-pattern where the fix is directly merged from 8.4 to trunk. This messes up the ancestor-selection logic of future merges.
# In core-8-4-branch ... develop the fix fossil commit ... # Step I, merge up to 8.5 fossil update core-8-5-branch fossil merge core-8-4-branch ... fix conflicts, if any fossil commit ... # Step II, merge up to 8.6 aka trunk fossil update trunk fossil merge core-8-5-branch ... fix conflicts, if any fossil commit ...
When fixing a bug it is not always clear in the beginning what the oldest branch is, to support. This leaves us later with the necessity of porting a change backward, making the staircase pattern impossible. In that case cherry-pick the change to apply in the older branch. Assuming our fix is VERSION, and has to go into 8.4:
fossil update core-8-4-branch fossil merge --cherrypick VERSION ... fix conflicts, if any fossil commit
TODO: Guidelines for use of branches (vs direct commit to trunk, etc.).
TODO
For those which have worked on the core before, using CVS, please also see the Fossil vs CVS Commands.