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

You commit changes to the repository

Merge is useful when you need to maintain two branches of a repository. For examples v1.x with most recent security fixes and the alpha version 2. That allows you to make the fixes in the 1.x code, whith the resulting binary for existing customers, and you can merge the changes into version 2 so fixing the bugs that weren't already caught.

Answer 3

I suggest you look around for 'typical svn workflows'. They will give you the big picture of the 'most common tasks'.

What you want to do is 'commit' the changes made to your files to the repository.

You need to merge in case of a conflict (when 2 or more people are working on a project and commit to the same repo. conflicts might arise).

Check the available articles on SVN kai remember to read about the sample/typical workflows or working scenarios with SVN.

Answer 4

Fully agree with David, but as far as question 3 is concerned, personally, I would distinguish between use cases:

1. Production: One project per repository. And do get warm with the mentioned tag/trunk/branch concept, it really helps a lot

2. Testing: I have one single repository where I have put virtually all my experimental codes (approx. 10 languages with x codes per language). Reason is: One experimental code takes me 1-2 minutes, creating a repository on a remote host, using ssh-security sometimes takes longer ;-)

Cheers EL

Answer 5

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.