Re: CVS diff and unknown files.

[Greg A. Woods]

[ On , January 27, 2005 at 12:07:39 (+0300), Sergei Organov wrote: ]
> Subject: Re: CVS diff and unknown files.
>
> Well, to tell the truth, all this tagging I do would be not an issue
> should CVS support changesets. The tagging in my use-cases is in fact an
> attempt to somehow mark a changeset to be able to retrieve it later (in a
> form of diff between two tags).

CVS does support the concept of creating and managing sets of changes --
It just does not do so in the more general way you seem to think you
want it to.

Fundamentally in CVS every change set is the set of changes to the group
of files committed by any given "cvs commit" command.  Commits are more
or less atomic and the combined commit log for each change set can be
used to identify the change set.

Abstract change sets which are unrelated to the fundamental change sets
are created by using tags or branches.

Branches are currently, IMO, the best way to manage arbitrary abstract
change sets; and tags are second best, as you're discovering.

However the most commonly used technique are those basic fundamental
change sets inherently created by CVS with combined commits.  Most of
the free-OS projects that use CVS use this technique.  NetBSD, for
example, now has it down to a pretty much automated procedure and
they've enhanced their commit-log generating script to include the exact
CVS commands necessary to extract each change set on demand.  See any of
the recent commit log entries posted here for example:

        http://mail-index.NetBSD.org/source-changes/

These postings are then used by developers to identify change sets which
are to be "pulled up" to a release branch.  See this procedure
docuemnted here:

        http://www.netbsd.org/developers/releng/pullups.html

Note that I'm just a user of NetBSD, not one of the core developers.  :-)

Training your developers to work on one change at a time (per working
directory), and to always commit everything involved in a given change
with one single "cvs commit" command may not be so easy though,
especially if they've grown too accustomed to other practices.  In this
case forcing them to put each unique change set on a unique branch will
help.  Of course using branches to manage change sets in a larger full
SCM environment will require additional techniques and procedures, but
how they are designed and implemented depends almost entirely on your
specific local SCM goals and requirements.

-- 
                                                Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>