SVN info

[Error]

I need to know a bunch of stuff about SVN, as I've never used it. I'm wanting to set one up for my quake mod, and also I thought it'd be good to have on the forum for us svn-noobs to look at.

Things like:

1. How to set it up
2. What are it's uses
3. What's the best one to use
4. Any downfalls
5. How the hell do I use it
6. Any other info that would be useful to a noob

Thanks.

[goldenboy]

1. Get hosted at a place that provides SVN repos (we used assembla.com, now using icculus.org). You'll get a SVN URL and a user/password.

1 a) I *think* (it's been so long since I did this): Install a SVN client. Use your SVN client to do a checkout. This gives you a local copy (working copy). It will be an empty folder in the beginning. Put your stuff into this folder, and again use your SVN client to add all the files (put all the files under version control / "SVN Add" depending on client). Then do a checkin to upload your changes to the repo.

2. It runs a central repository of something where it keeps track of all changes, so there are no conflicts when 10 people upload stuff at the same time. It's a version control system, quite literally doing the bookkeeping of a multi-user project. It can keep track of changes down to a single line in text files and merge those; it obviously can't merge binary files like images or executables. It keeps all your changes - you can revert to a 5 year old version of a file if needed. Nothing is lost. Thus it also serves as a backup.

3. The best one to use? Subversion is Subversion. There are different clients though. I use the command line client, most Windows users I know use TortoiseSVN, which hooks into your Windows Explorer and basically gives you some additional options in the popup menu.

4. Umm... Not that I know of. Migrating multiple users, especially when they're not really disciplined, from one SVN repo to another can be an interesting experience, but usually it just runs. One downside is teaching new team members the workings of SVN. Prepare to explain the same things over and over.

5. You usually do checkins (this uploads your changes) and updates (downloads the latest changes that others possibly made). You do a checkout (downloads everything) when you're new to a project. All this is done with your SVN client (read the Tortoise SVN manual at their website, it is good). A typical use is: Do an update, then do a checkin. You'll also add new files to the SVN whenever necessary.

6. Don't listen to people who tell you to use GIT or anything like that, at least not until you tried SVN.

6 a) Try to get it for free.

[WickedShell]

Only additions I'd add, based on my experiences.

3) Gotta push the command line. If your working from that, you will at least have to know what you're doing and in the end that's the only interface that will be common across all platforms. You will spend time explaining to everyone who is using a GUI client how you make things work in they're specific world.

6) Git vs SVN is the great debate. I will say I've used both of them as controller, authorized write, and anonymous checkout. (And from SVN submitting my changes upstream via patch files to people with write access). Git had it's advantages, distributed model (git) vs centralized model (svn), and full local backup (git). I can say I've had less of an issue with GIT for merging 2 different working branches, but that could just be usage scenario. (github.com provides free open source hosting for git btw, I'm sure there's an SVN equivelent I just don't know of it) In the end they both accomplish the same thing. This will be come a holy war for anyone else using it with you, so once you pick one be prepared to sit with it for a while, and sit on your users, that you are using one or the other for the time being.

[Spirit]

I like Git and do not see any reason why one should use SVN instead. That is my honest opinion and I am not saying it just to piss off gb.

[goldenboy]

It's like Mac vs Windows or one of these things. WickedShell said it better than me.

[leileilol]

I learned the hard way for one thing - Code repository software sucks for media.

[Spike]

I hate git. people fork your project (even an svn-based one) then complain whenever you commit even the slightest buggy untested feature!

I understand the merits of a distributed revision control system. safer backups, full local copy, etc...
but full local copy means the thing takes AAAAAAGES to download in the first place. seriously ages.
when you have a 4gb or so repository, of all previous versions, which must be downloaded in order to use the thing, and your internet connection is your average shoddy business routed-through-country-you've-never-heard-of connection that even gets google to display in gibberish, that cuts out every 3.5gb of data... the whole thing gets very tiring.
maybe its just that I don't know how to use git (ie: creating a local version which does not require me to download 3gb of old redundant changes). the problem is that I'm not the only one.

git might be powerful, but until it has something simple and usable like tortoisesvn, its not going to see that much use, at least amongst windows users who can never remember the bizzare technogibberish required to use a commandline effectively (and that's just the shell).

[frag.machine]

[revelator]

hmm just to bleed some http://code.google.com/p/tortoisegit/

but yeah im perfectly happy with svn though bazaar is starting to look good also.

[goldenboy]

We use SVN for media files a lot, including wav files, images, models etc. Never really encountered a problem, but perhaps that's because we have pretty clear job descriptions and OK communication in our team and it's unlikely that two people want to work on the same sound or model file at the same time.

It's always possible to roll back to an older version because nothing ever gets lost.

The one file where conflicts often occur is the progs.dat file. It happens when several people make code changes and recompile the progs for testing. This will produce a conflict when the second changed progs.dat is checked in; it is usually resolved by accepting their progs, then recompiling the qc so both changesets are included.

[Spike]

[goldenboy]

Well, it works. Not committing any binary files is out of the question for us. I don't think it's a serious problem.

[Error]

This seems like it became more of a debate than helpful. Where would I go to set up svn? Where would you suggest? I know google code does svn now. Plus, google is reliable.

[qbism]

The day a thread like this doesn't devolve into a debate is the day everyone has been replaced by too-friendly alien robots.

I use Sourceforge for svn and TortoiseSVN client, both free. I've had an account there about 10 years. They've improved the appearance of their website over the past year or so. The advertising displayed to people downloading files is pretty light. Sourceforge is fairly simple and intuitive, but commits and repository changes seem slow. Different file types don't seem to be a problem, although I guess that large image or media file revisions would be sluggish. I've never tried multi user features.

If it's not been made clear already, SVN is not a "live" or real-time connection. Commits can be automated by some software, but I always update manually.

Common Tortoise commands
SVN update - download changes (any conflicts are noted and saved w/ different filename)
SVN commit - upload changes
Repo browser - change log notes, delete files, etc. on the svn repository

[goldenboy]