Advice to begginers

I'm not exactly new to using SVN I've had to many many times far to many projects call for using them especially large ones ofc. However I've never managed to get one up and running myself, if you can give some concrete information on that I'd be grateful and it'd help a lot. Using it isn't a problem like I said... Simply getting my own online and working well aha.

Thanks

The vital thing is called "Version Control". SVN is one approach to it. Using a distributed version control system such as Git or Mercurial is becoming more and more popular.

If you are new to version control, I would recommend you go for a distributed one.

Well, the main thing to know about svn is that runs on a server computer, this can be done on any personal computer, but I've never done that.

However, there are many online sites that provide this service for you, some payed and some for free, google has a free subversion hosting serivce, I think it was code.google.com, http://www.assembla.com/ is another similar service that I've grown very fond of for personal uses, although most of the additional features have been falling into the payed service packages, svn is still free in assembla.

These pages provide the hosting and storage service. To interact with them however, you need a service client, the most popular free SVN Client is Tortoise SVN, http://tortoisesvn.net/downloads.html
This installs a small interface that allows you to upload and download your changes and other peoples changes if there is more than one developer involved.


You might already used this interface if you worked with svn before, however I will provide a small summary of use just in case for you and other people.

First of, you need to have an svn repository, this is, the hosting service already created, either in a personal computer or in one of the above mentioned pages.

Once you have the URL of that repository, for example http://code.google.com/projects/mytestproject you need to do a repository checkout.

Create somewhere in your disc the directory in which you will like to work, then right click on it and the new contextual interface added by tortoise will display new options, click on SVN Checkout, put your url in the proper field on the menu that got opened and voila! you have a subversioned empty directory.

Create your project inside that directory and add some basic code.

Now to keep in mind, not every file in the directory will be versioned, in fact, by default none of them will, you must manually choose what files to add, this is done by multiple-selecting the files and directories you want to be subversioned and right clicking, under the tortoise sub menu there is the add option, you click that to add stuff.

What DO we want subversioned? if you subversion everything indiscriminately your repository will quickly fill up with unnecessary data (free repositories tend to have a space limit).
You want to subversion only the files that will be necessary to be able to work from another computer, for instance, every temporary or dynamically generated file, such as the compiled binaries of the project, are not necessary, if you have the solution, projects and source code, you can compile on any computer with the development software installed.
Avoid versioning intellisense databases and such since they are dynamically generated and tend to be VERY heavy.
Content is optional, if you have a very large project with gigs of models, textures and such, an svn repository might get filled very quickly, so you might want to handle that some other way, if it is small you might version your content too.
Keep in mind that unlike text files such as code, text and xmls, content such as textures, models and binary files will be duplicated.


When you commit a change in a code, SVN only stores the difference between your new code and the previous file version, if you changed about 15 lines in a 500 line code file, only 15 lines of text are commited, and then mixed with the original file, optimizing the weight of your repository, all the way back to the original file as it was added.
This way Svn can handle text files very efficiently, but with content files it cannot distinguish the relative changes, if you changed one pixel in a 512x512 texture, the ENTIRE texture will be uploaded, and since previous versions are preserved, you just duplicated the file.


Now, for general use rules, assuming you are working with another developer, before beginning to work, right click your repository root directory and update, this will download any changes made by others since the last time you updated, compile to check if any of the new code has created errors, make your changes, once you are finished for the day, update again!, if you have been working for hours, new changes might have been commited by other developers, if there was, compile again to make sure no new errors have arisen, and now you can commit your changes.
As a rule try not to commit code that does not compile or that crashes the application on runtime if you know it does. It is best to comment new code before commiting it if it's not done yet, so you don't screw the project for other developers.


Another good practice is to always fill the commit summary with short description of the changes you are uploading both for other people to know what's new and for you to be able to check back afterwards when a specific change was introduced.

To sum up:

Checkout the project.





Update

Compile

Work

Update

Compile again and fix any errors

Remember to add any new files you have created or other people will get errors of missing files they cannot fix without you

Commit.

The vital thing is called "Version Control". SVN is one approach to it. Using a distributed version control system such as Git or Mercurial is becoming more and more popular.

If you are new to version control, I would recommend you go for a distributed one.

That's right, thanks for the observation, I was not being accurate.

I've found something better than SVN, and that is GIT. TortoiseGit makes Version Control so much better (particularly when merging two branches from different users). It also makes commit-early-commit-often a methodology to live by. I have many Subversion repositories still, I have TortoiseSVN for managing those if I want to go back to SVN, but GIT-SVN provides me local GIT functionality for remote SVN repositories.

I recommend using either SVN or GIT for source revisioning. I also recommend backing up your repositories often to an offsite location (if you can, otherwise a USB stick which stays with you is a nice alternate backup location)

I use Dropbox. seems to work well enough for my purposes.

I use Dropbox. seems to work well enough for my purposes.

That is because you have not experienced the joyous epiphany that is Git.

You're right. Can't miss what you don't have. And you can't get used to what you don't use.

That is because you have not experienced the joyous epiphany that is Git.

+1 Absolutely right! Git is the win. Only caveat is if you have Unicode filenames/folders ... Doesn't encode/decode properly on Windows (or at least not from Linux->Windows). Best for merging and local commits though by far.

Do you guys recommend SVN or GIT for a single developer environment or just for teams of developers?

I generally use version control for everything - certainly once I work on a project for more than a couple of days. Even my little trivial utility scripts are in a common directory that is version controlled.

Any favorites for GIT hosting?

There are a few different types of version control, as has been said before, I've recomended SVN and posted a small instruction on it's use because it is the one I have experience with, since I haven't used GIT I wouldn't know enough to say if it is better or not.

Regardless, preference in this kind of cases tends to be a matter of taste and comfort, I would advice to those who preached about GIT's superiority to avoid the philosophical debate and simply post as I have, a small instruction on how to use it, so other people can make their own choice and test various methods.

Preference left aside, the main point of this thread is to advice to use SOME kind of version control to make your work easier for those who don't have these practices assimilated yet, you may change from one version control system to another, but once you have used one of them, you will never willingly work without any of them again

Actually, in this case GIT (or other distributed version control systems) offer a significantly different workflow to that of centralised ones. It isn't just taste or comfort here, it is practical benefits for day to day work. A distributed version control workflow is totally different to a centralised one, and it will probably become the norm in the next couple of years as the bigger players start adopting it.

If you haven't tried a distributed on, you should. HGInit is a great introduction.

If you haven't tried a distributed on, you should. HGInit is a great introduction.

I was just going to suggest HGInit! I still tend to use SVN for team projects (game mods in particular) because it generally has better adoption and is easier for non-coders to understand. Mercurial is now my go-to version control system where I just need to slap version control on top of a solo project. I'm sure I'm missing out on a lot of its features, but even so, I like it.

Which files should I upload to my repository? I'm using tortoiseSVN. For example, I have VS2010 proj folder....should I just upload the source files and resource file? What's the standard practice?

Didn't see this mentioned here.. A good, free plugin to VS for svn: http://ankhsvn.open.collab.net/

Not sure how I could live without svn now. So good to be able to revert things/check what you've changed. Doesn't need to be online either, I run mine from one of my harddrives. I back the whole repository up "every so often" just in case.

Which files should I upload to my repository? I'm using tortoiseSVN. For example, I have VS2010 proj folder....should I just upload the source files and resource file? What's the standard practice?

The rule is to upload only those files that you cannot generate in a different computer, for instance, code, you cannot guess what code changes have been introduced in another computer, therefore, code should be uploaded, the solution and project files as well, you cannot guess if somebody added a new code file to the project, if only the code file was uploaded, your project won't be aware of it and will get compile errors.

Every generated file, such as compiled binaries, console log, and any other application process output, you should not upload.

In C# XNA projects it is fairly easy to know, by extension, you should upload any .cs; .proj; .sln and any content resource such as non generated xml, png, .X, wav, mp3, etc.