[ 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 <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs