From users-return-26925-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Thu Mar 8 11:47:19 2018 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 B726917614 for ; Thu, 8 Mar 2018 11:47:19 +0000 (UTC) Received: (qmail 82691 invoked by uid 500); 8 Mar 2018 11:47:19 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 82641 invoked by uid 500); 8 Mar 2018 11:47:19 -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 Delivered-To: moderator for users@subversion.apache.org Received: (qmail 5921 invoked by uid 99); 8 Mar 2018 11:08:53 -0000 X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_SHORT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Hgys1Ejk+9yfk40xBHPUj+CLuZMLFLSHLBDxGLi0GlI=; b=MoCTLvX0oi94ktfJk4mBd5gjgbarYiiYg0UpND8bwI6gfCjCjTX7urNQtDBy3yB3TW T9e+krpAH363UKrzWWthPdEjw7l+7Y87ElVWl2QE/dwdA8L7hLS1cMGDl0i+bcDzkomn LPOMiR9DqCKwMuKCB/kZIvAPlJ7WlFCjmJUMTRMPVZ2+9mlGErKUcTMcO8Q13neFwQ0u jVYpu4k+G1nZOLCYLhgj9ZafZtlweVN3jfLxhKgJhxeUAeziA9CKqhyu/qDSREEtpypx RsTjbZCHKfNQvjYeNaQOQtcPBOFK+vSponm9oA0oKfFJ+Jbyyp3L4BB2YAXhRCjVtafD HfFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hgys1Ejk+9yfk40xBHPUj+CLuZMLFLSHLBDxGLi0GlI=; b=Hnh73uA76IjohHmH8xMoYcvp9lFSgMeLbMQ/kVEmqRuxIvkSqtd+d/x5S+N04hmLqf 3Y0IvAgPv/WmfDpXgJMPpBY3jZcm+wBVc7IpH3sPLwJaS8DCBp6IzjTtrnu7yP+PIHk2 i0VC4UsMstjz+ra6cPmR97lSbJUv/mJvm1gKGZoXdCYQqmJyMD9Z6jHMtl0LSc1/vQCu jhJubHvw2GixDuZ3+WU9FuoULlOOqeQXyyOiawhHJC1HstICWTAkDciWrfXXY6bNYXOm 9ggVtPnWmUil4mOhsE+oc2A09CTKYe6H8fIaIvumwDudIR6c0cqwym8AfEkmJR1L9PPI azcw== X-Gm-Message-State: AElRT7Fmu7RSL2FQA2cu1nCuFYfRoLNojPnvemTRxDhdx4qyOE+P+9o5 /s7kg7Lzy3rSWKLH+vt7i0/jMOFK7IKb+2lNeUVlUA== X-Google-Smtp-Source: AG47ELtNzv0NNMSemc3245lKXWOCSTPsqhb+1iocB3Y0qDq3cQfQRIOlLuA5kWvP1kwVELmYGWJ1ILI39s6LF62Co9k= X-Received: by 10.157.6.70 with SMTP id 64mr17089761otn.259.1520507331000; Thu, 08 Mar 2018 03:08:51 -0800 (PST) MIME-Version: 1.0 From: Jay Foad Date: Thu, 8 Mar 2018 11:08:50 +0000 Message-ID: Subject: trunkless svn: using svn without a trunk To: users@subversion.apache.org Content-Type: multipart/alternative; boundary="94eb2c095da857bd850566e4b329" --94eb2c095da857bd850566e4b329 Content-Type: text/plain; charset="UTF-8" Does anyone have experience of using svn without a trunk? We use svn for a product with an annual release cycle. All new development is done on trunk. Once a year we take a release branch, for fixing bugs reported by customers. One slight annoyance with this model is that when we start working on version N of the product, it lives at http://svn.foo.com/trunk, but later (after we have made the release branch) that same version lives at a different location, http://svn.foo.com/branches/N. This means we have to update some buildbots and svn:externals and whatnot that pointed to the previous location. In order to avoid that (amittedly minor) pain, we are considering moving to a "trunkless" model where we abandon the use of http://svn.foo.com/trunk and always work on http://svn.foo.com/branches/N for some value of N. When we start working on version N+1 we will create .../branches/N+1 as a branch of .../branches/N, and start working there. By the time we get to version 100 we'll be working on a branch of a branch of a branch of a branch of ... 99 times over. Does anyone have any experience of how well this works out in practice? (In case it makes a difference: we don't tend to use a lot of feature branches, so don't tend to do many big merges. I don't expect that to change, regardless of whether or not we go trunkless.) I'm aware of one technical problem: it'll be harder for us to do bisection on our source code, because "svn update -r X" does not let you update to a revision X that is older than when the current branch was created. I'm optimistic that this can be improved in a future version of svn. I found some previous discussion here: https://svn.haxx.se/users/archive-2007-01/0354.shtml But I'm still wondering if there are any other technical problems I should be aware of, or if there have been any relevant changes in the last 11 years of svn development. Thanks, Jay. --94eb2c095da857bd850566e4b329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does anyone have experience of using svn without a trunk?<= div>
We use svn for a product with an annual release cycle. A= ll new development is done on trunk. Once a year we take a release branch, = for fixing bugs reported by customers.

One slight = annoyance with this model is that when we start working on version N of the= product, it lives at http://svn.foo.c= om/trunk, but later (after we have made the release branch) that same v= ersion lives at a different location,=C2=A0http://svn.foo.com/branches/N. This means we have to update s= ome buildbots and svn:externals and whatnot that pointed to the previous lo= cation.

In order to avoid that (amittedly minor) p= ain, we are considering moving to a "trunkless" model where we ab= andon the use of=C2=A0http://svn.foo.c= om/trunk and always work on=C2=A0
http://svn.foo.com/branches/N for some value of N. When = we start working on version N+1 we will create .../branches/N+1 as a branch= of .../branches/N, and start working there.

B= y the time we get to version 100 we'll be working on a branch of a bran= ch of a branch of a branch of ... 99 times over.

D= oes anyone have any experience of how well this works out in practice?

(In case it makes a difference: we don't tend to u= se a lot of feature branches, so don't tend to do many big merges. I do= n't expect that to change, regardless of whether or not we go trunkless= .)

I'm aware of one technical problem: it'= ll be harder for us to do bisection on our source code, because "svn u= pdate -r X" does not let you update to a revision X that is older than= when the current branch was created. I'm optimistic that this can be i= mproved in a future version of svn.

I found some p= revious discussion here:=C2=A0https://svn.haxx.se/users/archive-2007-01/0354.shtml

--94eb2c095da857bd850566e4b329--