Subversion experts?

[bitWISE]

We've started to use subversion for side projects here at work and are trying to figure out whether to make the jump to TFS or subversion (or maybe even something else). The problem we've got with subversion is that even with as little as two people working on the same project, we're having instances where the last person to commit of the two just erased the other person's work. It is also rather annoying when you're pulling a copy out of subversion to update the server and you end up with the main file full of merge tags and three or four versions now sitting in the folder.

Clearly, we're not doing it right. How do large projects manage subversion?

[^misantropia^]

1. Always run `svn update` before you start hacking on a file.
2. Use `svn export` to create the production build (and test it on a staging server first).

It also pays to learn branching and merging - `svn copy` and `svn merge` - so you can hack away at your experimental features while your co-workers maintain the trunk.

[^misantropia^]

And a corollary to #1: don't do stupid things like changing the indentation of whole files just because you feel like it. That way lies conflict hell and your co-workers will hate you for it.

[^misantropia^]

And on the subject of commits:

1. Commit often. Reduces the chance of conflicts.
2. Commit little (as in: small changesets). Makes it easy to roll back bad changes and helps in tracking and visualising the evolution of your code base.

Rule of thumb: one commit, one change.

[bitWISE]

Makes sense, thanks. So you're saying use trunk for the more stable code and branch off for heavy dev work? We do essentially the opposite with VSS6 right now. We have one solution that is the main dev code and then whenever we're going to update production, we copy that code over to a "patch" solution that only gets touched if it is an approved bug fix.

I didn't know VSS2005 was on the table so it looks like we're going with that as long as the web access doesn't suck.

[^misantropia^]

Yep. Branch when you are doing experimental or major overhaul stuff and merge it back into the trunk when it has matured.

It sounds like you are already doing this (the 'copy to patch' bit) but create a branch for each major release and declare it immutable safe for show-stopper bugs. The trunk is for maintenance, the release branches for back-porting bug fixes to.

[^misantropia^]

On the topic of VSS: viewtopic.php?p=786403#p786403

Just to illustrate how awful it is: even Microsoft, a company renowned for eating its own dog food even when better alternatives exist, doesn't use VSS internally. That's saying something, innit?

[bitWISE]

Turns out we're going with subversion next week. Should be interesting as we're also converting the entire solution from NET1.1 to NET3.5.

[^misantropia^]

Let me know how that works out for you. Couple of years ago, I converted a 20,000 line C# project from 1.1 to 2.0. Went fairly smooth, no major obstacles.

[bitWISE]

I've done the conversion a couple times now. It compiles and runs but there are some things that simply don't work anymore. We had a guy test the entire app and it all seems pretty minor. I'm so pumped to not have to use VS2003 in Windows 7 anymore.

[bitWISE]

Is there a way to have a file be part of a repository, but never update locally? We have server specific files that shouldn't change. What I'm doing right now is putting an ignore on the files and checking in example.X.X.

[^misantropia^]

That's about right. I usually solve this with Maven profiles (Maven = Java build tool) where each profile corresponds with a run-time environment (dev, test, prod).