Date: Tue, 14 May 1996 16:00:58 -0500 (CDT) From: Tony Kimball <alk@Think.COM> To: nate@sri.MT.net Cc: hackers@freebsd.org Subject: Re: why so many ways to stay in sync? Message-ID: <199605142100.QAA27146@compound.Think.COM> In-Reply-To: <199605142009.OAA16821@rocky.sri.MT.net> (message from Nate Williams on Tue, 14 May 1996 14:09:09 -0600)
next in thread | previous in thread | raw e-mail | index | archive | help
I've redirected the discussion. Because the remote repository is on the ground... Ah... now I understand the concept of an "airplane" much better:-) I had thought you were referring to using one of those AT&T phones on the seatbacks. Frationing the repository is a CTM admin issue, methinks. Consider the case of FreeBSD. What if the various top-level directories were maintained in separate ctm domains, so that there was a cvs-cur-root cvs-cur-ports cvs-cur-src-bin cvs-cur-src-etc cvs-cur-src-games ... cvs-cur-src-usr.sbin eh?? All ctm cvs-cur users would keep cvs-cur-root, but not all would need every subset. Local mods are a client implementation issue. Suppose there were an lcvs program, which would only handle the 'new update commit delete diff log' commands. It could refer to the local repository maintained via ctm, but add a file for each local branch file, to contain local patches and history. COPYRIGHT,v COPYRIGHT,v.local lcvs could also permit commits (using RCVS protocol) to the main repository, using another commit command, say 'lcvs rcommit'. Upon success it could perform a symmetric commit against the local repository, but balk at collisions between ctm updates and local histories. Would this fulfill your ideal requirements? This seems like about the least amount of work, of all the approaches that I have considered, to resolve the problems you describe. //alk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605142100.QAA27146>