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".
