Re: History in subversion

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_at_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".
Received on 2013-06-17 00:07:03 CEST