Date: Mon, 9 Dec 1996 20:48:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: chat@freebsd.org, terry@lambert.org Subject: Re: siguing into current from a random version Message-ID: <199612100348.UAA03319@phaeton.artisoft.com> In-Reply-To: <199612100228.DAA27241@uriah.heep.sax.de> from "J Wunsch" at Dec 10, 96 03:28:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... lock updat commit test unlock ... ] > Even this can take several hours to complete. Think of machines > running at clock frequencies slightly lower than 200 MHz :), or of the > sluggishness of many Internet connections (including mine) where it's > _simply not an option_ that i can refetch the CVS source home right > after a commit (at least, if the commit affected more than just a > couple of files). You don't commit until you compile successfully. I don't understand where you think "refresh the CVS tree after a commit" comes into it at all. > Neither is compiling everything on freefall (or thud) an option. > Everything had to remain locked for all those hours -- that's > unacceptable. It has to be locked over an update/build/commit. I don't see where "hours" come into it (unless you are confused and thing the update is on your home machine? The commit, by definition, must take place on the main CVS tree). In addition, the update process is typically never going to get triggered, in any case ...the update will result in no "M" or "C" records. Unless what you guys have been claiming about people only rarely working on the same files is false, and you're picking now to admit it for some reason. > In particular unacceptable since what you are > suggesting to us as the `problem' you're trying to solve is hardly > being remembered by any of the committers as really being one. That really depends on if your "product" is a source tree, doesn't it? > So the costs are simply to high. Sell your model to somebody else, please > (should you find one). You are exagerating the costs by intentionally assuming that you will be hitting the worst case each time, and in doing so, you are contradicting some of your assumptions (like the one that says these worst cases never arise, so you don't need the locks to keep people from stepping on each other's toes). A implies not B B implies not A If I argue for a soloution to A, you can not use B as a counter argument, and vice versa. Please pick one viewpoint to argue from, and see it through, instead of changing viewpoints when its convenient (to "better put down Terry's suggestions, and logic be damned"). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612100348.UAA03319>