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

1. You could have a repo for each project or use a single repo for many linked project; that's really up to you. Consider that the revision number is global for the repository, so a commit on a project would increase the revision count for the whole repo.
2. They are good pratice if you need to branch your project, even if you work on it alone. They are not necessary if you have only the main branch.
3. We usually commit when a feature is complete, when a refactoring is done, etc; eg. we don't commit in the middle of an edit.
4. If you work by yourself, you can commit often to backup your work. But if you work in a team you should stick to committing "working code", otherwise your colleagues may get some non compiling code in they working copy.
5. Our repos are backed up nightly along with other stuff on the server.
6. Users don't need to access the repos directory. It should be accessible to backup admins etc.
7. There are many different GUIs for svn. Check out this: Comparison of Subversion clients.

Answer 3

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.

As you prefer it: the revision count increases with each check-in, irrelevant of which project it was in

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

Tag releases (so you can verify bugs against whatever release a reporter is using for example), branch for working on a bigger thing - if it doesn't work out the way you expected, you can always go back to the main branch

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

I commit from the beginning, right after I created the project.

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

I commit every evening if I have something that works (or in any case does not break the build). Do not check in code which does not compile (even if you work alone this is a good idea). I also commit whenever I finish whatever task that I am working on, before getting started on another task.

Answer 4

1. It's a matter of personal tastes. I prefer the single repo, it's easier to maintain users and permissions and to backup
2. Yes they are, those are two features the can be useful even in a single-person scenario.
3. Each commit should be meaningful. So, commit when you finish to implement a feature, or when you fix a bug, or when you do some work that can be meaningfully descripted in the log message. A version control tool is not a backup tool.
4. See the previuos point, you should not commit just because you are stopping to work and leave some broken code or half-done tasks in the repository.
5. Backup is always important, svn gives you different ways to do it, see the official book: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.backup
6. Normally you don't need to access it after setting it up.
7. Try using a Svn client like TortoiseSvn.

Answer 5

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.