From users-return-18306-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Sun Jun 16 22:06:57 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 5B8F1C9F8 for ; Sun, 16 Jun 2013 22:06:57 +0000 (UTC) Received: (qmail 6083 invoked by uid 500); 16 Jun 2013 22:06:56 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 6063 invoked by uid 500); 16 Jun 2013 22:06:56 -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 6056 invoked by uid 99); 16 Jun 2013 22:06:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Jun 2013 22:06:56 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [80.67.31.36] (HELO smtprelay02.ispgateway.de) (80.67.31.36) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Jun 2013 22:06:50 +0000 Received: from [66.90.153.106] (helo=[192.168.2.167]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UoL5L-0001Bi-85; Mon, 17 Jun 2013 00:06:07 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: History in subversion From: Ryan Schmidt In-Reply-To: Date: Sun, 16 Jun 2013 17:06:06 -0500 Cc: users@subversion.apache.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Olivier Antoine X-Mailer: Apple Mail (2.1508) X-Df-Sender: MzY4ODE4 X-Virus-Checked: Checked by ClamAV on apache.org On Jun 16, 2013, at 15:55, Olivier Antoine wrote: > When you commit, commit can fail, and you might have to merge before = committing. If you commit, and the commit fails because one or more of the files you = changed was also changed in the repository, then you have to "svn = update" the working copy to receive the changes from the repository. You = do *not* have to, and probably should not, "svn merge" anything at this = point. > You merge, you did some regression tests on the merged software, and = then you finally commit. > But it just mean that the software that you store in the repository is = not strictly the software that you developped, and this software is = simply lost. > This is just against the SCM principles. If you're concerned about this, then "svn cp" your trunk to a new = feature branch before beginning your work. Or even after you've finished = your work, if such a situation arises. Let's say you check out a working copy of trunk. You make changes. You = test them. You commit. The commit succeeds. Good; you're done. On the other hand, let's say you've made changes and tested them and try = to commit and it fails because a file is out of date. You wish you had = made a feature branch for these changes. No problem; you can still do it = now. Use "svn info" on the working copy to find out what revision of = trunk you had checked out. Let's say it was 1234. Make a feature branch = in the repository from that revision of trunk ("svn cp $REPO/trunk@1234 = $REPO/branches/my-feature-branch"). Switch the working copy to that = branch ("svn sw $REPO/branches/my-feature-branch"). Commit the changes; = it'll succeed. Now you have the state of the software you developed = recorded in the repository in the feature branch. Now you can continue = with the task of reintegrating the feature branch into trunk using "svn = merge".