Date: Sun, 5 Oct 1997 08:30:01 -0400 (EDT) From: Hetzels@aol.com To: chad@dcfinc.com Cc: freebsd-stable@freebsd.org Subject: Re: CVSup release identity Message-ID: <971005083000_1543650796@emout05.mail.aol.com>
next in thread | raw e-mail | index | archive | help
In a message dated 97-10-04 18:27:20 EDT, chad@freebie.dcfinc.com writes: > > I agree that it needs a little work in order to support cvs & ctm. > > One thought is to make .ctm_status a permant part of the source tree > > and to have an additional file .cvs_status that would be used to track > > version #'s of source files that have changed between each CTM delta. > > That way a CVS user could pull down modified source files and know how > > far off from the CTM delta they are. > > Reverse the thinking. Make .cvs_status a permanent part of the tree, > and increment it each and every time a change is comitted. Then there > is a known place to get a marker of where along the line of updates a > particular system resides. > I see one problem with a permanant .cvs_status file. If commiter A changes files X,Y, & Z, does he increment .cvs_status for each file or per change. Then if 2 commiters A (X, Y, Z) & B (D, E) change files which one changes the .cvs_status file. What prevents them from submitting the same change to the file? A tool that would automaticly update the .cvs_status file would then be needed. I suggested the .ctm_status file because there is already such a tool to create this file. Besides how fine a grain do you need?, An Exact version identity, or at least knowing that your between point A & B. Thus, if someone reports a bug at point A, and it is fixed at point B, all anyone has to say is update your system to at least point B and your problem is solved. Since CTM deltas are created every so often during the day, it makes the perfect choice to track where the source tree is at during any given time period. Scot
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?971005083000_1543650796>