Hi,
We use cvs, ok, but as I see it we only do version control on individual
files. For several reasons this may not be sufficient.
Version control makes no sense if you are not prepared to revert to a
previous revision and branch-and-merge in case "something has gone
wrong." For individual files we are OK, but in practice doing so will
lead to an inconsistent tree since most of the times other files did
undergo a related change that should be undone as well.
Currently there is no straightforward means of getting there safely.
Another major thing is creating baselines, or releases or release
candidates, or whatever. As I see it, at 'D-day' we make a copy of the
HEAD of the tree and that's about it. A few problems:
- No controlled bug-fixes on the baseline
- No controlled/documented relationship between the baseline and the
main development track.
For the first issue I recommend to introduce a Task concept: A unit of
work. A Task adds a feature, corrects a bug, etc and involves changes to
some set of one or more files.
Without additional tooling task management does not come for free, but
it can be done without too much hassle:
1) Create a new version-controlled file 'tasks'. In this file tasks are
given a unique Id (something like TID<number>) and possibly even a
description of it.
2) Tasks can only be created by the integrator.
3) Tasks have a state, being Open or Closed. Once a task has been
closed, no further commit shall be done for this task. Bugs introduced
in or with the implementation of some feature are handled with a new
task.
4) The log message of all commit operations related to this task shall
contain at least this task ID.
5) No commits to any file (except 'tasks' itself) shall be done without
reference to some task.
+ With a simple (awk, perl, tcl,...) script the "cvs log" output can be
filtered to obtain the set of files and their revisions for this task.
+ It is easy to see what work is ongoing and what has been done.
Two remarks:
- Subversion ('another cvs') handles this problem implicitly, in that it
does version control on the complete tree, instead of on individual
files. The latter is only a means to accomplish this.
- Cvs tagging (see also below) is a built-in way to accomplish this
("cvs history -r TIDnnnn" will do the scripting job), but it requires a
separate tag command (by the CVSROOT admin) be executed after each
commit. This is not very comfortable.
For making base lines, the cvs tagging concept was invented. You do not
merely make a copy of the HEAD of the tree, but tag the whole tree with
a baseline identification.
This has numerous advantages, a.o:
+ It is possible to explicitly check out this baseline from the
repository and commit a branch for each file (note that without doing
this, the baseline is only a snapshot). Having checked out the baseline
explicitly, the baseline tags become "sticky" so they are on the newly
committed files as well. After that, bug fixes to the baseline (e.g. a
release candidate) are possible and there is no need to freeze the main
development, which can happily continue at the HEAD of the tree.
+ The advantage over creating a new CVS repository for the baseline
(which is another way of allowing controlled bug fixes on the baseline)
is that you lose the ability to easily merge those bug fixes into the
main line if needed. The tools will leave you alone there.
Happy to hear what you think of this... The baseline part will certainly
make Pascal's life a lot easier. Having tasks should help any developer
in better understanding what is going on at the HEAD.
Cheers,
Joost.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
