Getting Started With Working On The Tcl/Tk Core

TODO: Guidelines for use of branches (vs direct commit to trunk, etc.).


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.

Installation

Prebuilt Fossil client binaries for the major platforms (Linux, OSX, Windows, BSD) are available at https://www.fossil-scm.org/download.html and building it yourself is of course possible as well.

Getting Tcl and Tk Sources

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 https://mirror1.tcl-lang.org/tcl tcl.fossil
fossil pull  https://core.tcl-lang.org/tcl -R tcl.fossil

fossil clone https://mirror1.tcl-lang.org/tk  tk.fossil
fossil pull  https://core.tcl-lang.org/tk  -R tk.fossil

We are using mirror1 because the repositories are large and https://core.tcl-lang.org/ 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.

By default fossil creates an administrative user for the cloned repository which is identical to the current username. This means that by default commits will be attributed to this user. Because this is probably not what is intended, you can override the default user when cloning by using the -A option:

fossil clone https://mirror1.tcl-lang.org/tcl tcl.fossil -A <username>

Make Ready For Work

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.

Fossil has two general modes of operation based on the autosync setting. If autosync is enabled, any commit will also trigger a sync (push/pull) with the repository that was cloned from. If you want more control over when pushing and pulling should occur, this behaviour can be disabled on a per repository and global level.

To disable autosync for a repository use:

fossil settings autosync off -R /wherever/you/have/repo.fossil

Or from an open checkout of the repository:

fossil settings autosync off

For changing the global setting so that all repositories will have autosync turned off, use:

fossil settings autosync off -global

Keeping Up-To-Date

Move into a checkout, then pull all changes, at last update the checkout.

cd    /somewhere/tcl
fossil pull
fossil update

The first time "fossil pull" is used you have to specify the repository (url) you are pulling from (as shown the first section of the page). From that point on fossil remembers the url and a simple "fossil pull" is sufficient.

Working In Branches

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 fossil which branch to put into it:

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

cd    /somewhere/tcl
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.

Porting Forward

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 ...

Porting Backward

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

Pushing Changes

To push changes directly to http://core.tcl-lang.org/tcl or http://core.tcl-lang.org/tk an account is needed on that repository. The administrators which can handle requests for accounts are Don Porter,, Donal Fellows, Richard Hipp, Jeff Hobbs, Joe English, Roy Keene, Kevin Kenny, and Andreas Kupries. This is primarily for Tcl and Tk Maintainers.

Assuming that you have an account A invoke

fossil push http://[email protected]/tcl

from within a local checkout. Fossil will ask for the password of A and then push all changes (if not private ).

Note that the url has to be supplied only once, for the first push or sync. Fossil remembers url and hashed password, enabling future pushes to be run by invoking the simpler

fossil push

from the checkout.

More Information

For those which have worked on the core before, using CVS, please also see the Fossil vs CVS Commands.

Bug Tracking

See

Releases

The release files stayed at SourceForge. I.e. you keep going to

for them.

Understanding the Timeline

Various branches are marked with colored backgrounds in the timeline view. The main ones to be aware of are:

  • White: Main-line trunk development. Almost always buildable.
  • Lilac (purply-blue): Tcl 8.5 branch. Almost always buildable.
  • Green: Tcl 8.4 branch. Almost always buildable.
  • Red: Bug-fix branch.
  • Yellow: Feature-development branch.
  • Grey: External import branch (normally closed; merge of changes non-trivial).

Troubleshooting notes

If you have problems with passwords, either in the browser or using the fossil command line, Troubleshooting core.tcl-lang.org fossil logins may be helpful.