Hi,
Sorry that I did not get too much response to my thoughts below.
Disappointing indeed...
Well then let me ask a question: How is it possible that a 3.7.1 was
'released for download' whereas the about box in the CVS still names it
3.7?
Regards,
Joost.
On Fri, 2009-02-27 at 15:15 +0100, Joost ´t Hart wrote:
> 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
