Basic Subversion questions

Question

I've just started using subversion, and have read the official documentation (svn book), cheat sheet and a couple of guides. I know how to install subversion (in linux), create a repository (svnadmin create), and import my Eclipse project into the repository (SVN import), view the repository files (using svn list).

But I am unable to understand some of the other terminologies. For example, after importing my Eclipse project into the newly created repository I have made changes to my Eclipse project (more than 1 file). Now, how should I update the repository with this added files/changes made to my Eclipse project?

The svn update command brings the changes from the repository into your working copy - which is the opposite of what I want i.e. bring the changes I made in my Eclipse project into the previously imported project in repository. If I am correct, you update the repository more often (as you keep extending your project implementation) than your current project (with update).

Also, I do not understand when would you use svn merge. The svn book states it applies the differences between 2 sources to a working copy. Is there a scenario which would explain this?

Finally, can I have more than 1 project checked into the repository? Or is it better to create a new repository for each project?

Answer 1

1. The term you are looking for is "commit".

2. Subversion does not exclusively lock a file for editing (though there is a command to do this if you really, really want to). So it is possible that you will need to merge two different users' sets of edits on a file, or even edits from two different working copies in two different locations on your machine.

3. Multiple projects is fine. Best approach IMHO is repository/project/trunk etc rather than repository/trunk/project.

Answer 2

Three things about SVN you should know:

1. Trunk - The main version of your code
2. Tags - 'Tagged' Versions of your code (i.e. v1.2.5-release)
3. Branches - Forks of the code for divergent development paths. We typically fork new branches to work on different versions, so if the current version is 1.2.4, you'd branch for 1.3's development. So if emergency changes to 1.2 need to be made (i.e. 1.2.5) you can work on it without worrying about what you broke by refactoring / feature adding in your 1.3 branch. The merge operation is designed so you can merge 1.3's branch back into trunk when you're ready to release 1.3, or a similar operation. You can also merge individual files (if two or more developers edited the same file at the same time and now you need to 'merge' the changes into the same file.

Each project in your repository should have 3 folders in it:

1. /trunk
2. /branches
3. /tags

These house the three points above. You don't have to have these folders, but you should. Other more mature VCS like Mericual/Git have the concepts of tags and branches baked into the system. In SVN these are more of a convention/reccomendation.

Terminology

• Working Copy - The copy on your hard-drive, that contains all your edits, etc...
• Add - Registers a file for tracking in version control
• Update - Updates the working copy with changes from the server repository
• Commit - Updates the server repository with changes from the working copy
• Switch - Replaces the working copy with another folder within the server repository
• Diff - Does a differential analysis of two files / versions of a file to see the changes between them.
• Merge - Attempts to apply the changes from one or more files into another, highlighting conflicts.
• Patch - A set of differences that can be used to update a file.