Andy Mayer <[EMAIL PROTECTED]> writes: > On Sat, 09 Mar 2002 03:57:05 +0000, Stephen Leake wrote: > > > I don't think CVS can do that. You are talking about managing "change > > sets". > > Then what is chapter 13 of the CVS manual all about? It says there "If you > modify a program to better fit your site, you probably want to include > your modifications when the next release of the program arrives. CVS can > help you with this task. "
Good. Learn something new every day :). I think that chapter wasn't there the first time I read the CVS manual (getting longer ago every day :). I'll have to try this. > > I handle this process by keeping a diff file of my changes to > > vendor's code, and applying it to each new release (outside of > > CVS). > > Could you please explain this process a little more? Well, I think I'm just doing manually what CVS does with branches and merging. Here's the process: 1) Unpack the vendor's version 1.0 distribution twice; one "clean" copy, one I will modify. 2) Make my modifications. 3) Run 'diff' to get a single diff file showing all my modifications. Now, when Vendor version 2.0 comes along: 1) Unpack Vendor version 2.0 twice. 2) Run 'patch' to apply my version 1.0 changes to version 2.0. 3) Make more changes. 4) Run 'diff' to make a version 2.0 patch file. This process is simpler than CVS when the vendor package is huge and my local changes are small - a typical situation. -- -- Stephe _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
