Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 312 invoked by uid 500); 26 Sep 2001 06:14:18 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 278 invoked from network); 26 Sep 2001 06:14:17 -0000 Message-ID: <004c01c14652$c7d656a0$4ca0e40f@cv.hp.com> From: "Steve Loughran" To: References: <1001430738.5689.19.camel@jesseDEB> <005a01c145dc$5d2063d0$8fa4f40f@nordwand> <1001448512.5517.50.camel@jesseDEB> Subject: Re: New Source Control Tasks Date: Tue, 25 Sep 2001 23:16:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2526.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 X-ECS-MailScanner: Found to be clean X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Jesse Stockall" To: "ant-dev" Sent: Tuesday, September 25, 2001 13:08 Subject: Re: New Source Control Tasks > On Tue, 2001-09-25 at 12:08, Steve Loughran wrote: > > Hi Jesse. > > > > Ignoring the amusing fact that you really do need a third party add on to > > make VSS work over long haul links, and the even more poignant fact that > > sourcesafe has a well founded reputation for not keeping your source safe, > > your contribution is indubitably welcome. > > > > SourceSafe is not my choice, The *nix guys here are outnumberd by the > Windows folks so we are stuck with VSS. At least SOS gives us > connectivity from Linux & Solaris. I've never tried the remote access > part of SOS, but it does the job for internal use. > ok. you just need to be aware that if source safe has a failing, it doesnt always keep your source safe. I had an incident checking in a document once when someone else filled up the shared drive during the process. The check in failed, the entire doc history was lost, and even the document took a while to locate to where it had been stuck. That kind of put me off it, even if has a reasonable UI -the authors dont have a full grasp of the concept of atomic transaction. The fact that the manuals are so full of coverage of database recovery process is another warning: if they waste paper on it, it must be a serious and recurrent incident. Which is better: not having an SCM system and knowing you dont, or thinking you have an SCM system and finding out you dont? -steve