commit/update/merge commands in svn

Question

i want to know exactly when i should use either of commit, update and merge command in svn.

after i've checked out a project and altered the code, should i use update, commit or merge to stay in sync?

correct me if im wrong:

update = all changes in the repo is copied to your local project.

commit = all changes in your local project is copied to the repo.

merge = same as above, but you determine the direction?

when do i use each command above?

Answer 1

And I quote from the SVN Book :

The typical work cycle looks like this:

Update your working copy . This involves the use of the svn update command.

Make your changes . The most common changes that you'll make are edits to the contents of your existing files. But sometimes you need to add, remove, copy and move files and directories—the svn add , svn delete , svn copy , and svn move commands handle those sorts of structural changes within the working copy.

Review your changes . The svn status and svn diff commands are critical to reviewing the changes you've made in your working copy.

Fix your mistakes . Nobody's perfect, so as you review your changes, you may spot something that's not quite right. Sometimes the easiest way to fix a mistake is start all over again from scratch. The svn revert command restores a file or directory to its unmodified state.

Resolve any conflicts (merge others' changes). In the time it takes you to make and review your changes, others might have made and published changes, too. You'll want to integrate their changes into your working copy to avoid the potential out-of-dateness scenarios when you attempt to publish your own. Again, the svn update command is the way to do this. If this results in local conflicts, you'll need to resolve those using the svn resolve command.

Publish (commit) your changes . The svn commit command transmits your changes to the repository where, if they are accepted, they create the newest versions of all the things you modified. Now others can see your work, too!

Answer 2

Let's look at how "update" and "merge" are different:

Suppose the revision history of a repository X looks like this:

 ...->2707->2708->2709->2710->2711

2711 is the latest revision number of X. There might be a bug that was introduced somewhere between revision 2708 and 2711. You know the bug did not exist at revision 2707. It could have been introduced at 2708, 2709, 2710 or 2711. Basically, you are interested to know which commit introduced the bug.

One way of doing things would be to go back (roll back) the changes in your local repository at each of this revision number and check if the bug still exists. Suppose say the bug was introduced in revision 2709. You could do roll back of your commits with the folllowing commands:

$ svn update -r 2710

The bug still exists...

$ svn update -r 2709

The bug still exists...

$ svn update -r 2708

The bug doesn't exist. This implies revision 2709 caused the bug.

However, you could equally do,

$ svn merge -r 2711:2708

The only difference between the two, is that svn update would raise flags if there were local changes and let you know. You could either accept those changes or revert back so that when you run svn diff there are no changes. On the other hand, svn merge would resolve the differences between the local copy and the repository. Utility wise they would still be doing the same thing, but they only demonstrate here behavioral differences.