From dev-return-7720-apmail-continuum-dev-archive=continuum.apache.org@continuum.apache.org Wed Jan 14 22:24:58 2009 Return-Path: Delivered-To: apmail-continuum-dev-archive@www.apache.org Received: (qmail 38334 invoked from network); 14 Jan 2009 22:24:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Jan 2009 22:24:56 -0000 Received: (qmail 87103 invoked by uid 500); 14 Jan 2009 22:24:55 -0000 Delivered-To: apmail-continuum-dev-archive@continuum.apache.org Received: (qmail 87065 invoked by uid 500); 14 Jan 2009 22:24:55 -0000 Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@continuum.apache.org Delivered-To: mailing list dev@continuum.apache.org Received: (qmail 87053 invoked by uid 99); 14 Jan 2009 22:24:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Jan 2009 14:24:55 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of wsmoak@gmail.com designates 74.125.44.158 as permitted sender) Received: from [74.125.44.158] (HELO yx-out-1718.google.com) (74.125.44.158) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Jan 2009 22:24:45 +0000 Received: by yx-out-1718.google.com with SMTP id 34so311075yxf.50 for ; Wed, 14 Jan 2009 14:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xdYiNcR0LTGXW2avL/KboWPT/eFIQJ/0/5Dr53ceK6c=; b=dR9X8sIF47yHBqAQNRtxKuW91btWrQ6+bo1/BkmxCIA6tX8uuUu1HnrO65KKstgyBl GRVlDwJp27VhVnvF/m/zvSPYFHRk7gJwVOCAYwlmla6cQrSEj0NfZccWSYg3yLpBFQCm BSadhn3ZjaeMU9zJoH1UWJNO9aCEJlI3pOto8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=f4mIfOQL6hzuFvUit1liY9DnBq76CErn5cynQ4GIV5apZz8v6PLsaMcUaIODgMAfe9 YXjtd0bVFos7al4P/a4XMS+o4PgvrfYDHZl9wl41ZIxQs7uFdFQ0Jweg8kKqPJoe2RA3 EJ9bPeuAHXuvTvX9b8pwTI0v9XCmd3PHX92HU= Received: by 10.151.6.2 with SMTP id j2mr2706600ybi.50.1231971863952; Wed, 14 Jan 2009 14:24:23 -0800 (PST) Received: by 10.151.99.7 with HTTP; Wed, 14 Jan 2009 14:24:23 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2009 15:24:23 -0700 From: "Wendy Smoak" To: dev@continuum.apache.org Subject: Re: First Part of Distributed Builds In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <10c62ca80812120546g2dff62e4u75b3f03568cfbdd9@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Jan 14, 2009 at 12:18 AM, Napoleon Esmundo C. Ramirez wrote: > Having lots of data aggregated from different Continuum instances into one > will need some kind of an importer tool. I'm thinking this should only > support data from Continuum instances of the same model version, while data > from different versions will have to be handled by a separate db migration > and conversion tool. I'd like to point out that distinction and combining > the two is an option, but let's take things bit by bit first. It is the db migration tool that is blocking a release of 1.3 right now, so the first thing I'm looking for is a way to upgrade a single instance of 1.2.x to 1.3.1-SNAPSHOT. The importer tool to consolidate multiple existing instances would be nice to have, but so far I'm the only one asking. :) > Briefly: > 1. The Backup functionality should be available in the Continuum web ui. > The core functionality is available, making it accessible in the Continuum > web ui will ease the generation of data to import. Not sure if you have these in any sort of order, but this is low priority for me. I'd get it working at the command line before worrying about adding it to the webapp. > 2. Create the Import functionality. > 2.a This accepts the backup files as input. > 2.b All the data in the backup file will be appended to the existing data > of the Continuum instance it is imported to. I think there needs to be an option to import and overwrite -- there is always some data in a Continuum instance, even a brand new one (the default project group, default schedule, etc.) If you always append, there will be no way to restore from a backup and get back to the same state. > A basic rule is: no duplicates. In case of duplicates, either a new Was there more on this thought? > The complications are: > 1. The keys of the entities in the imported data may have duplicates in the > Continuum instance it is imported to. To address this, the keys of the > imported data will have to be adjusted, shifting the values to next > available values but giving preference to the existing data (latest key > value + 1 ??). > 2. Since the keys will be adjusted, the relationships between the entities > of the imported data will have adjust as well. What about the build output, which is stored in numbered directories? I don't think it is included in the xml backup, you're just expected to have them in the right place on disk. Those directories would either have to be re-numbered along with the records in the database, or we'll have to document that we don't support keeping build output when you consolidate server config. Or maybe we just leave out build results altogether for the first pass at this, and say we only support consolidating the projects/schedules/installations/etc -- the configuration and not the historical data. Thanks, -- Wendy