Project code managment using SVN

Question

Hello there..

I've started working on a project. I would like to store this project using subversion. I've installed VisualSVN server and TortoiseSVN.

This project consist of several little projects. Some of them I need everytime, some of them not. The questions are:

1. Should I store the whole project in one subversion project directory?
2. What about the soulution file (*.sln) ? Should it be stored in SVN also ?
3. On project is some kind of a framework (It will be used in other projects later). But I need it everytime when I'm working with the base project. Is there any convenient way to checkout/export my base and framework project from different SVN directories at once ?
4. If I need to work just on a part of the project, what should I do ?

Answer 1

1. You can store the project according to your directory structure. The rule of thumb is that one csproject for one svn directory
2. Yes, you should store sln in SVN. You can put this sln in one of your project directory ( usually in your GUI csproject folder)
3. For this you need to use SVN command line to do; you can write a batch script for this purpose.
4. You can just checkout the relevant project and work on it.

Answer 2

1.) How you like it. That is totally up to you. Do you want to handle several subversion folders or do you want to handle only one?

2.) Yes, of course. Only keep files out that are user-specific (like .user).

3.) No. Well, maybe. If you use AnkhSVN as Visual Studio project, then you can update the solution and all project folders will be updated with it.

4.) Work with only that project ;-)

Answer 3

For ME - the rule of thumb is 1 SVN REPO = 1 SOLUTION

I DO checkin the .sln file as well, and enforce the identical directory structure with all the people working on the project

Answer 4

Store everything in one directory. At the base of the directory should be the solution file. This should be stored in SVN as well (making it much easier to checkout a solution from SVN on a new machine).

For the framework project - try including it in the solution, and then referencing it in the base project of the solution.

If you need to just work on a part of the project, you can open up the entire solution and just work on the part that you need, or just checkout that project.

Answer 5

The setup of your subversion repository is a topic on which many different opinions are present. The answer below is based on my personal experience and preferences:

1. I recommend storing multiple modules of a project in one single repository. This eases checking out the project in its entirety. When you put the sub projects in their own sub directory in your main project, it is possible to check out the individual sub-projects on their own as well.
2. I'm not sure what a *.sln file is, but if it is required to build the project, it should be in your repository. If it is generated (or can easily be generated) and is system dependend, it should not be part of your repository.
3. It is possible to include parts of other repositories using the externals feature of svn.
4. See my answer at point 1.

Answer 6

Usually a Subversion repository has three folders trunk, branches and tags. You will place your projects in trunk. If they are not directly related, I would create one repository per project.

Yes, I keep the .sln files but ignore the .suo and cproj.user files. I also ignore bin and obj folders.

If you keep your "framework" project in one repository you just checkout the trunk folder and you are done. If you keep it in another repository you can check out the concept of externals

You usually checkout the whole trunk, even if you need to work on a special small part of the project.

The SVN Book can help you learn more.

Answer 7

Probably depends how you want to organize things, how big the individual parts are, and what works for you. Experiment a bit.

One thing that you might want to look into is externals: (http://svnbook.red-bean.com/en/1.0/ch07s03.html). This allows you to have files and folders from other repositories pulled in.

Answer 8

I've set up our internal SVN repo like the following:

SVN-Root
    - trunk
        - Projects (for each project one folder,
                    Solutions are in separate folder)
    - tag
        - Projects
    - branch
        - Projects

Though, I've read about a different set up like this:

SVN-Root
    - Solution1
        - trunk
        - tag
        - branch
    - Solution2
        - trunk
        - tag
        - branch

Answer 9

Since you are considering using several SVN repositories, you should consider the following: commiting in a SVN repository is atomic. Commiting changes that apply to several repositories is not.

Even if you are the only person using your SVN repository, the rule of thumb is that the system is designed to allow (in theory) anyone to update at any time and not risk getting source code that does not compile because of bad timing.

In conclusion, if there may be changes that need to be applied to files A and B simulatneously to keep the project compilable, then A and B should be in the same repository.

Answer 10

1

Yes, in short - but you'll be able to change your mind later on

The typical directory structure for a subversion project is:

project/branches
project/trunk
project/tags

You'd initially put all of your code in trunk and then create tags and branches later when necessary.

You might want to consider keeping everything together in one svn project folder structure initially because it will be simpler (you won't have to mess around with the solution file).

If you choose to make break parts of the projects into separate svn projects in their own right later on, you could do an 'svn rename' and create the standard branches, trunk and tags folders for them. You'd just need to modify the references in the solution file or use the svn:externals approach.

2

Absolutely - you should store everything in the repository that isn't generated by a build. Create svn:ignore attributes on generated folders (such as the obj and bin directories) so 'svn status' will give you useful feedback when you've forgotten to add an important file.

3

There is a mechanism svn:externals that enables you to create a link to another place in a subversion repository (or an external subversion repository) - that might help you to be able to check out from a single folder. You might want to consider making the svn:external reference to a specific tag of the framework so that other people's changes to the framework don't break your project.

svn:externals can make things pretty confusing however so use with caution.

4

You can check out at any level in the folder hierarchy in subversion