[darcs-users] Moving a tag?

BARBOUR Timothy Timothy_BARBOUR at rta.nsw.gov.au
Tue Jun 8 07:45:10 UTC 2004


I suspect people are suffering from a poor understanding of proper release
management. It is difficult to do it well with the old kind of revision
control systems (e.g. CVS), and also people can feel they are too busy.

Specifically, my understanding (in CVS terms) is that (assuming people
record changes on the trunk, not a branch):

(i) an unstable source tree can always be obtained from the trunk, so does
not need a tag (and is hardly a "release")
(ii) a stable source tree cannot be obtained from the trunk, so we need at
least a tag
(iii) we cannot make fixes to a stable version on the trunk (because we
would interfere with the versions succeeding the tagged ones), so we need a
*branch* for the stable release

Since darcs uses repositories as branches, it appears to me that proper
release management requires a minimum of two darcs repos: one for the trunk,
and one for the stable release. As successive stable releases are made, each
one is likely to need its own branch (i.e. repo). Since darcs uses hard
links to share patches between repos, a large number of repos need not be
cause for concern. Releases should be tagged along the way, and the tags
will need to incorporate a patch-level, which is good practice anyway (e.g.
<major version>-<minor version>-<patchlevel>). These tags, and the patches
they depend on, are pushed to the trunk repo, so that all versions are
accessible from there, but the releases are *maintained* in their individual
repos. It should be okay to push all release patches to the trunk, because
only bug-fixes should occur in releases, and these will be needed on the
trunk too. Because all the release patches are in the trunk repo, it is not
necessary to back up the release repos (saves space if your backup system
makes deep copies of hard links). As maintenance of each old release comes
to an end, its branch repo is no longer needed (in fact it can be deleted
whenever convenient, since it only needs a "darcs get <tag>" to recreate
it).

Considering darcs as an example, I wonder how David makes releases ?

I would be inclined to do it as follows:

Keep the current stable release of darcs in a separate repo, and only push
new features to that repo after they have been tested in the unstable
version for some time. Have a series of repos, one for each actively
maintained release (at present maybe just the last stable release), then a
repo for the next pending stable release, then the trunk. Bug-fixes can
probably be spread around everywhere that they are applicable (without
dragging new features into releases). New features should be pushed from the
trunk to the pending stable release after sufficient testing. When it is
time to release the pending stable release, it is added to the stable
release series, and is copied (via darcs) to make the repo for the *next*
pending stable release. As above, patches and tags for releases should be
pushed into the trunk, so that the releases can be accessed from there.

I think the above processes could be automated. Pure bug-fixes could be
automatically pushed everywhere (provided we can identify them), and new
feature patches could be automatically pushed to the pending release after
they reach a certain age. The creation of a release could be triggered by a
human running a script, or from a cron job.

Tim

-- sorry about the lame .sig --

IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.




More information about the darcs-users mailing list