How to use SVN to download source codez

[Baker]

I've procrastinated on getting an SVN client installed. A couple of years people were pushing me to do it ... I can't remember the issue, but I think I had some problem with Windows XP SP1 and compatibility with the TortoiseSVN installer at the time.

Here is what you do to retrieve source code from an SVN repository:

1. Download TortoiseSVN, it integrates into the explorer shell in Windows. http://tortoisesvn.net/downloads

2. Create a folder somewhere you want to store the source code.

3. Open the folder and right click somewhere and then click SVN checkout.



4. A windows comes up and you enter the URL. You'll need the SVN url and enter it in:



5. After you click ok, it downloads everything. The end.

[mankrip]

I'm going to use TortoiseHG (Mercurial) instead, but I have a question: Will it detect when source files are moved around to different subdirectories?

If so, will it also detect those moved files if they have also been modified?

I've modified most of the directory structure of Makaqu's source code between versions 0.1 and 1.0, and I want Mercurial to track those changes accordingly.

Well, I gotta read more documentation.

[Spike]

A small note about SVN:
Most SVN urls will end with the directory 'trunk'. Not all, but most.
You just download 20 times as much if you forget it. :)
For example, with FTE there are two branches, 'trunk' and 'branches/wip'. The issue comes with each official release also being tagged. Okay, so there arn't many of them, but still worth mentioning.

TortoiseSVN is really quite handy though. You can click the '...' to the right of the url box to pick the branch/tag/subdir you want.
It'll show any files you modified in red.

Generally a tool will not track file moves automatically. You have to do the move with the tool in question, or your file history will get mixed up.

[Sajt]

If you have TortoiseSVN (or I assume TortoiseHG) installed, you can "right-click + drag" a file to a new location, then select from the popup menu one of the options such as "SVN Move versioned item(s) here" (then commit). The client should handle all cases properly, such as if the file was modified. If you move it normally (without informing SVN) your client will just think your files disappeared and some new unversioned one popped up somewhere else.

[goldenboy]

True, you must use svn move or it will simply restore that file next time you update.

Short Linux SVN HOWTO:

1. Install Subversion. It's a command line program, which shouldn't be a problem if you use Linux.

2. Check out a working copy like this:

svn co https://svn.blah.com/blah/svnroot Myproject

where Myproject is the name of the directory you keep the stuff in. If you need a password and username to check out stuff, Subversion will ask you to enter them.

3. To update,

svn up Myproject

4. To checkin,

svn ci Myproject

This will bring up a text editor, where you can write the commit message. Save in the editor, and it will start the commit. What editor is used depends on the environment variable $EDITOR.

5. To put a newly created file under version control, put that file where you want it using cp, mv and friends, then say

svn add myfile.file

and update and commit.

6. To move a file,

svn mv myfile.file ../myfile.file

In other words, just like mv, just with a "svn" in front of it.

The majority of tasks you'll be doing is updating and checking in, and putting new files under version control.

7. For help,

svn help

or

svn help up

svn help ci

and so forth.

Notes

Always update before committing.

If Subversion detects a conflict (usually progs.dat or something like that), you'll get a little menu with some options. You can say "tf" (theirs-full) to accept SVN's idea of what the file should be (in the case of progs.dat, that is a good idea) and then simply recompile the mod (if it is a mod) and try to check in your version again. Svn tracks differences in text files down to a single line, so there won't usually be problems with those. Except where you and someone else really edited the same line in the same file. In that case, it's a good idea to abort the update, make a backup copy of the conflicting file (using cp, as usual), then update and accept "tf". Afterwards, manually insert your changes back into the conflicting file.

Linux SVN is smart enough to not checkin .o files and binaries that are created during compile, *unless* you explicitly put them under version control with "svn add".

If you simply want to know if some file is already under version control, you can use

svn info filename.file

or

svn status filename.file

and it'll either throw an error or say "this file is not under version control" if it isn't.