From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24831 invoked by alias); 13 Nov 2004 01:19:07 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 24594 invoked from network); 13 Nov 2004 01:19:03 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 13 Nov 2004 01:19:03 -0000 Received: from [192.168.181.128] (unknown[67.176.41.158](misconfigured sender)) by comcast.net (sccrmhc13) with ESMTP id <2004111301185901600gploie>; Sat, 13 Nov 2004 01:19:03 +0000 Message-ID: <419560F9.1030608@phy.cmich.edu> Date: Sat, 13 Nov 2004 22:52:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: cstevens@gencom.us CC: xconq7@sources.redhat.com Subject: Re: New Home for Xconq Project? References: <200411121739.38994.cstevens@gencom.us> In-Reply-To: <200411121739.38994.cstevens@gencom.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01407.txt.bz2 Hi Coop, D. Cooper Stevenson wrote: > What would happen if we went to SourceForge or Savannah for "eyballs" and > pointed to the Xconq.org or RedHat site for a CVS backup? I think that, in the case of Sourceforge, it would fit closer to their [Sourceforge's] philosophy if we, at least, made files available for download on their mirrors (via their File Release System). As far as CVS goes, I don't know. I think we should try their CVS server first. If it doesn't prove reliable, then we can use a CVS server elsewhere (xconq.org, perhaps). > It's trivial for me to mirror the xconq.org server with the source > repository's server. As long as it isn't against their policy and doesn't hog too much bandwidth, I think it would be good to have a CVS mirror. When we get to that point, I would say to go for it. > Obviously, this isn't an "automatic failover" solution but would it provide a > good compromise? Well, this gives redundancy from an end user standpoint. As a developer, if the main repository is inaccessible, then I am still stuck with waiting for it to come back before I can commit changes. Any changes committed to a "mirror repository" would have to be synchronized/committed to the main server later. Even if such a thing is a current technical possibility, it would seem that information pertaining to the original committer, original commit date, original commit messages, etc... would be lost. Regards, Eric