From dev-return-897-daniel=haxx.se@subversion.apache.org Tue Jan 5 21:48:11 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o05KmACn014347 for ; Tue, 5 Jan 2010 21:48:11 +0100 Received: (qmail 18062 invoked by uid 500); 5 Jan 2010 20:48:06 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 18046 invoked by uid 99); 5 Jan 2010 20:48:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 20:48:06 +0000 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 20:47:56 +0000 X-Envelope-From: stsp@stsp.name Received: from jack.stsp.name (jack.stsp.name [217.197.84.187]) (authenticated bits=128) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id o05KlRut005497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jan 2010 21:47:31 +0100 Received: from jack.stsp.name (stsp@localhost [127.0.0.1]) by jack.stsp.name (8.14.3/8.14.3) with ESMTP id o05KlQDK004583; Tue, 5 Jan 2010 20:47:26 GMT Received: (from stsp@localhost) by jack.stsp.name (8.14.3/8.14.3/Submit) id o05KlOnN019305; Tue, 5 Jan 2010 20:47:24 GMT Date: Tue, 5 Jan 2010 20:47:24 +0000 From: Stefan Sperling To: Peter Samuelson Cc: dev@subversion.apache.org Subject: Re: Subversion in 2010 Message-ID: <20100105204724.GB18823@jack.stsp.name> References: <4DF6734D-0402-4C2C-8D15-D6FE14265B0E@mail.utexas.edu> <4B4217EC.1000009@collab.net> <4B422CEA.1000602@mark.mielke.cc> <20100104182505.GD24463@jack.stsp.name> <4B423733.7020604@mark.mielke.cc> <20100104193220.GF24463@jack.stsp.name> <4B42D5DF.3040705@mark.mielke.cc> <20100105102921.GA17177@jack.stsp.name> <20100105201825.GB7154@p12n.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100105201825.GB7154@p12n.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 On Tue, Jan 05, 2010 at 02:18:25PM -0600, Peter Samuelson wrote: > > [Stefan Sperling] > > Subversion needs to amend its data model to provide copy-to > > information, to complement the current copy-from information. > [...] > > This is easier said than done. It implies repository format changes. > > We'd need to a way to modify old revisions to store this information > > because the copy-to data needs to sit at the copy *source*. > > Huh ... this part I don't get. Surely the copy-to information would > live in the same revision where the copy (or rename) actually happens, > right? That does not require rewriting old data. Hmmm... food for thought. In fact if we're just looking at cases where the copy + delete happened in the same revision, it should even be possible to have the server transmit copy-to information which it computed dynamically, i.e. we don't need to store any extra data. Reverting copyfrom relations within a single revision should be possible, even when merging revision ranges. > I understand that this does not offer an efficient way to get _all_ the > places a node has been copied to, but in the case you're talking about, > we only care about the rename target. If the wc can enforce that both > sides of a rename be committed at the same time, the copy-to will > always be in the same revision as the delete. Revision graphing is another killer application of copy-to information, which could really only be done if copy-to info was stored in the repository. > Or, to put it another way, if the copy + delete are in separate > revisions ... then for tree conflict purposes, we can assume that the > delete is just a delete. This could be a nice way to break the copy-to problem down into smaller pieces, since it would allow us to implement copy-to information for renames in the client<->server interface before actually storing it in the repository. Stefan