From users-return-19563-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Mon Sep 9 03:20:10 2013 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0851810F46 for ; Mon, 9 Sep 2013 03:20:10 +0000 (UTC) Received: (qmail 19800 invoked by uid 500); 9 Sep 2013 03:20:03 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 19731 invoked by uid 500); 9 Sep 2013 03:20:02 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 19650 invoked by uid 99); 9 Sep 2013 03:19:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Sep 2013 03:19:59 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [210.9.117.138] (HELO gatekeeper.aapl.com.au) (210.9.117.138) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Sep 2013 03:19:55 +0000 Received: from gatekeeper.aapl.com.au (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 367885C72EB_22D3E45B; Mon, 9 Sep 2013 03:19:33 +0000 (GMT) Received: from aaplexchange.aapl.com.au (aaplexchange.aapl.com.au [10.63.2.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by gatekeeper.aapl.com.au (Sophos Email Appliance) with ESMTPS id 288935BBF1B_22D3E45F; Mon, 9 Sep 2013 03:19:33 +0000 (GMT) Received: from AAPLExchange.aapl.com.au ([10.63.2.50]) by AAPLExchange.aapl.com.au ([10.63.2.50]) with mapi; Mon, 9 Sep 2013 13:19:32 +1000 From: Geoff Field To: "Trent W. Buck" , "users@subversion.apache.org" Date: Mon, 9 Sep 2013 13:19:32 +1000 Subject: RE: Breaking up a monolothic repository Thread-Topic: Breaking up a monolothic repository Thread-Index: Ac6tAr4liL0+I6kFSgS2JaXEMqvp4AAB/QKg Message-ID: <4A2A8BDDBE6EFE4199FB22121DB971B1025A4134@AAPLExchange.aapl.com.au> References: <87d2oier13.fsf@gmail.com> <87bo42g2nh.fsf@gmail.com> In-Reply-To: <87bo42g2nh.fsf@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org > From: Trent W. Buck > Sent: Monday, 9 September 2013 12:17 PM > Nico Kadel-Garcia writes: >=20 > > Lock the existing repo: Do clean exports, and imports, to new=20 > > repositories with the new layout, with a README.md or other=20 > guideline=20 > > to where the legacy repository exists. You lose the infinitely=20 > > preserved history this way, but for most working software projects,=20 > > you don't *need* that. And it's a good opportunity to discard=20 > > materials, such as bulky binaries or security sensitive=20 > files with plain text passwords. >=20 > Ah, sorry, I forgot to mention that preserving history was a=20 > hard requirement handed down from higher up. You *could* argue that the existing repository preserves the history. However, I think I know what they mean. > I get the impression that $company's projects mostly have a=20 > finite lifespan (a couple of years), By "lifespan", what exactly do you mean? At my company, the individual pro= jects might be in production within anywhere from 6 months to 2 years after= start of development, be manufactured for two to four years, then go into = support mode for up to 7 years (or more). > so I think that approach=20 > ends up being very similar to my current plan of creating new=20 > projects as new repos, and letting the monolithic repo die=20 > out via attrition. That sounds like an easy way to do things. > I don't actually know exactly what they put in their repos; I=20 > think it's about half "huge unpacked source tarball I=20 > downloaded from somewhere then tinkered with" and half huge=20 > CAD files and .docx contracts. It's entirely possible that the empty commit messages you reported were due= to users not actually entering anything in the messages. Many of the comm= it messages I've seen (particularly from non-software people, but even from= a few of those) are less informative than I'd like - a lot are totally emp= ty. Regards, Geoff --=20 Apologies for the auto-generated legal boilerplate added by our IT departme= nt: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sen= der immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached fil= es for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or dama= ge of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.=20