Date: Tue, 14 May 1996 15:23:38 -0600 From: Nate Williams <nate@sri.MT.net> To: Tony Kimball <alk@Think.COM> Cc: nate@sri.MT.net, hackers@freebsd.org Subject: Re: why so many ways to stay in sync? Message-ID: <199605142123.PAA17207@rocky.sri.MT.net> In-Reply-To: <199605142100.QAA27146@compound.Think.COM> References: <199605142009.OAA16821@rocky.sri.MT.net> <199605142100.QAA27146@compound.Think.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I suppose I could, but it would be expensive. And, being on an airplane is just one of the many ways of being net-separated from the Repository. > 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. Yep, but again it's not setup this way right now, and administration time *is* significant. > 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 CVS doesn't work that way. Also, in my *grand* scheme of things, you couldn't do local only commits. All commits *must* be done on the remote site, and site consistancy *must* be maintained. > 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. Again, this is *sort* of what I'd like to see. > 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. I think the amount of work required is much higher than you think, but you're welcome to it. I'd even be willing to give my less-than-expert opinion on how I think it *should* work. :) Basically, any commands which modify the local respository should *require* that the local and remote repositories by sync'd up, and make sure that the modifications are against the most recent copies of the sources. Second, normal CVS operations should occur *only* against the local copy, and a new 'synchronizes' command should be added which performs the same functions as CTM/SUP do now, but on the fly. This could be run in a cron job nightly to make sure the local and remote copies are synchronized. This is where SUP is a win and CTM loses. The CVS protocol I'm submitting requires that the server be able to synchronize the system at *any* point in time, since the developer shouldn't have to wait for a particular 'window' in order to commit code. My assumption is that the developers time is the most valuable commodity for the project, so minimizes his time and maximizing his usefulness via access to information and ability to get his work done however and whenever he wants is the number one priority. The problem in itself isn't really that hard conceptually, but it requires a way to seamlessly integrate the functionality of SUP plus the ability to make sure files are up to date for commits and such. The joy of using this systems is that almost all relevant information is available to the developer on his local site for quick and easy development. However, with this scheme there are no extras steps needed to 'commit' the working code into the main tree. As it stands now, there are two solutions, neither of which are the best solution for slow-network link folks. 1) Use RCVS - Much of the helpful data lives on the remote systems, making access to it either slow or non-existant. 2) SUP + CVS - All data exists locally, but taking the tested/working code and committing it to tree requires quite a few (interactive) steps which makes it difficult and impossible sometimes over a slow/crappy network link. Peter Wemm currently uses a combination of both methods above, but I don't recommend it, as it's not for the faint of heart. I've messed around a bit with it, but gave up since it requires too much work to make sure the remote/local repositories are synchronized. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605142123.PAA17207>