From owner-cvs-gnu Wed Aug 16 20:06:19 1995 Return-Path: cvs-gnu-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id UAA13740 for cvs-gnu-outgoing; Wed, 16 Aug 1995 20:06:19 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id UAA13687 ; Wed, 16 Aug 1995 20:05:53 -0700 Received: (from peter@localhost) by haywire.DIALix.COM (8.7.Beta.11/8.7.Beta.11/DIALix) id LAA25779; Thu, 17 Aug 1995 11:05:11 +0800 (WST) Date: Thu, 17 Aug 1995 11:05:10 +0800 (WST) From: Peter Wemm To: "Rodney W. Grimes" cc: roberto@blaise.ibp.fr, CVS-commiters@freefall.FreeBSD.org, cvs-gnu@freefall.FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/cvs/cvs import.c In-Reply-To: <199508170226.TAA21813@gndrsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: cvs-gnu-owner@FreeBSD.org Precedence: bulk On Wed, 16 Aug 1995, Rodney W. Grimes wrote: > > On Thu, 17 Aug 1995, Ollivier Robert wrote: > > > > Now, let me see if I can compile and install this bloody thing on Freefall > > > > without too much pain :-). > > > > > > How about importing CVS 1.5 ? > > > > > > The remote support is nice to have... > > > > Umm.. I think this will suprise Rod, who has probably figured out I'm a > > "right at the bleeding edge kinga guy", but I think we'd really be > > opening up a pandoras box of problems if we enabled remote access... I'd > > be having nightmares, Rod would probably be having kittens... :-) > > I don't need any kittens, and I am sure you could use sound sleep! :-) > Now talk about a fast way to talk me right out that idea!! > > The main things I'm worried about is the commit process.. In the remote > > case, the commit text is prepared on the client, *before* the server even > > knows which files are being changed. The server no longer gets to supply > > a commit template file, because this is prepared offline now. There's no > > longer the visual check of which files you are actually writing the log > > message for - you're flying blind unless you've just done a cvs-update. > > You mean it does not inforce the up to date requirement that local > cvs does? Blehhh!!! Un acceptable for our needs. It would be far > to easy to smash other commits close togeather time wise. I must be > reading this wrong, it just can't be. Umm.. not quite.. to be honest, I didn't know exactly when the up-to-date check is enforced, but I checked and it's after you type the commit text... So you'll loose the text if you are not already up-to-date. So, in a nutshell, it's taking the text you type, then connecting to the server, then passing the text as a string to the server through '-m'. ie: What you win in convenience of not having 200+MB of cvs repository on your disk, you loose in other areas. It's a tradeoff, but in the sanity of the repository's favour. Everything else works just the same as before, except that when doing an update, it'll send a patch file instead of the entire file if it's practical. That saves bandwidth as you are only getting the deltas. There are tremendous advantages to having it running, but it's like sendmail.. how does the quote go? hmm.. "sendmail is an exotic woman - she will whisper delicious promises in your ear, but do not listen, for she is insane and will drag you down into the madness".. Being able to build and test the actual source that will be committed will be a major plus, as will editing the commit message locally, but we really dont need to TKO the repository while working for getting -stable out. Bear in mind that cvs directly writes to the rcs ,v files - the scope for corruption is pretty huge if it's wrong. It also has an alternative "dead file" system over and above the Attic.. Once this is enabled, there really is no turning back. Old cvs binaries will still work, but they wont understand the rcs state flags. (eg: "Exp".. there's a new one - "dead" that cvs looks for). > > I know the NetBSD people use it, and I know cgd had a bumpy ride > > getting it running from the early days when remote access was "new". So > ... > > > I don't know.. Is it time to start thinking about this sort of thing a > > bit more seriously? > > It is time to think about it, it is not time to do it. I am glad to > know that you are on the bleeding edge with this at your place, that > will help collect good data, and help us avoid the pitfalls when we > do go forward with it. I should just mention that cvs-1.5 has optional remote access - it doesn't have to be enabled. The cleanups and speedups relative to 1.4A2 may be worth it on their own.. For starters, it can be made to not leave stray locks anymore... > For now I think we have more important tasks at hand and do not > wish to have you loose sleep, or me be chasing after kittens. :-) :-) -Peter > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Reliable computers for FreeBSD >