Learning SVN - Simple beginner questions

Question

Just started with SVN. Here is a very basic set of questions that I have after reading several articles, tutorials and playing around for a couple hours.

1. When I create a repo is it supposed to hold all of my projects or just one? It seems odd that after running import on a few projects that my revision count is going up for each new project added.

2. If I am working by myself, are tags and branches still necessary and good practice?

3. How do you know when it is time to commit a project? Especially when writing it from scratch?

4. At the end of the night, do you always commit your work? or do you leave it checked out?

5. Do you keep an exported copy of projects at all times? What if the SVN DB borks? Can you recover from a borking? If it did bork and I only had a checked out copy, would I have to remove all of the .svn directories myself? Would doing so equal an exported copy? Do you archive exported tags elsewhere?

6. Do I ever need to directly access the repository directory? Would it be better to just hide this directory? (.svn)

7. Is there an easier way to do a checkout and import then entering the whole file path (file:///Applications/MAMP/SVN/)? Can I set a repo once that I will always use?

edit thanks for clearing up all these questions. Also for the suggestions on gui's. I got it set up through textmate which is unbelievably awesome. Still have to do the initial import and checkout on the CL though...

Answer 1

1. This is up to you. Some people consider a repo "big enough" for many projects, some consider the shared numbering annoying and make it a 1:1 mapping. You decide.
2. Sure! Each time you do a release, tag it so you can easily go back to it. Each time you want to work in "isolation" on something large, branch it off.
3. Commit as often as you like, think of it as backing up your work.
4. I prefer to commit before stopping work for that day or "session" or whatever, it just makes me feel I've accomplished something, which is good for motivation.
5. I backup my SVN to a hard drive kept in a bank vault. :) Not as often or regularly as I should, but I'm working on improving that routine.
6. I don't think I've ever accessed it directly, after setting it up.
7. Not sure about that one, I use a local server dotted domain name which is pretty short (svn.unwind.se).

Answer 2

Here's my take on this:

When I create a repo is it supposed to hold all of my projects or just one? It seems odd that after running import on a few projects that my revision count is going up for each new project added.

This completely depends on your taste: there are benefits from having several projects in a single repo (eg. copying code from one project to another), but if you e.g. want to give others access to just a single project, having a big repository can make things a bit trickier.

Regarding the revision number: don't worry about it. Those numbers are only meant for administration so you can easily merge code, go back to a specific version, etc.

If I am working by myself, are tags and branches still necessary and good practice?

Absolutely! Especially if you want to release your code to others or other places (on a server for instance). You'll want to know which version you shipped (tagging). And you may want to fix something in an older release while not being bothered by the changes that you already made during further development (branching).

Furthermore: you may want to try something while you are not sure whether you want to continue on that path: create a branch, experiment and either merge it back to trunk or throw the whole branch away.

How do you know when it is time to commit a project? Especially when writing it from scratch?

I like to make small commits. Created a boilerplate project? Commit it. Added feature X? Commit it. Refactored your FooProcessor code? Commit it.

By commiting these small steps, I find it easier to backtrack what I've done. If I fixed a certain bug and in a month I come across a similar problem, I can easily determine what was part of the fix and what wasn't. (That is: if it's in another commit, it was not part of the fix. :) ) The only rule I have, which is especially important when working in a team: don't commit broken code. It can be unfinished, but it should not hurt anyone that happens to check out the code.

At the end of the night, do you always commit your work? or do you leave it checked out?

I try to commit at the end of the day (so when something happens to my computer I have a backup, or if I get sick my coworkers can continue where I left off). But only if I have reached a point where it is safe to commit.

Do you keep an exported copy of projects at all times? What if the SVN DB borks? Can you recover from a borking? ...

I don't have a checkout of the whole repository, I have backups of the repository. I've never had problems with the SVN repository though.

... If it did bork and I only had a checked out copy, would I have to remove all of the .svn directories myself? Would doing so equal an exported copy? ...

Depends on whay you want to achieve. But removing the .svn files would in effect be the same as an svn export.

... Do you archive exported tags elsewhere?

No, not really. Unless you want to call the checkout of the release on the production server an 'archive'.

Do I ever need to directly access the repository directory? Would it be better to just hide this directory? (.svn)

On a *nix system, the .svn directories are already hidden (that's why they start with a dot). You should not want to mess around in those directories though.

Is there an easier way to do a checkout and import then entering the whole file path (file:///Applications/MAMP/SVN/)? Can I set a repo once that I will always use?

As others have already mentioned: have a look at GUIs for Subversion. I personally like TortoiseSVN.