Jump to content

  • Log In with Google      Sign In   
  • Create Account


Advice to begginers


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
21 replies to this topic

#1 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 18 January 2011 - 09:25 AM

Almost anyone who has worked on a software development company is likely to know this already, but I've met many independent or amateur developers that had been working even years without this more than vital tool called Subversion (SVN).

Ever made a change in your code that screwed everything up and spent hours or even days undoing?
Ever wanted to check out a piece of code that got faded away from your project many changes ago?
Ever lost an entire project out of disk or OS failure?
Ever suffered the tedious work of combining your changes to a projects with the changes of a partner in a team project?


SVN services solve all this problems quite simply, for those who don't know this SVN is an online hosting serivce that allows you to upload not just files, but different versions of the same code file and stores only the changes, allowing you to check or even revert to previous versions with a few clicks as well as quickly combining changes from different developers.

If any of you have not used this tool and would be interested in learning more, just post a reply here and I'll post a more extense information on this.


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



Sponsor:

#2 AdamWTF   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 January 2011 - 10:40 AM

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 :)

#3 rip-off   Moderators   -  Reputation: 8049

Like
0Likes
Like

Posted 18 January 2011 - 11:03 AM

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.

#4 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 18 January 2011 - 11:21 AM

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.


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#5 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 18 January 2011 - 11:23 AM

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.



Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#6 dwarfsoft   Moderators   -  Reputation: 1210

Like
0Likes
Like

Posted 18 January 2011 - 03:02 PM

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)

#7 Zack T.   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 January 2011 - 03:39 PM

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

#8 Snarkerd   Members   -  Reputation: 146

Like
1Likes
Like

Posted 18 January 2011 - 06:29 PM

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


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

#9 Zack T.   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 January 2011 - 06:59 PM

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

#10 dwarfsoft   Moderators   -  Reputation: 1210

Like
0Likes
Like

Posted 18 January 2011 - 07:13 PM

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.

#11 s0ccaman   Members   -  Reputation: 122

Like
0Likes
Like

Posted 19 January 2011 - 08:41 AM

Do you guys recommend SVN or GIT for a single developer environment or just for teams of developers?
"An intelligent man speaks and then listens, a wise man listens and then speaks."

#12 rip-off   Moderators   -  Reputation: 8049

Like
0Likes
Like

Posted 19 January 2011 - 09:01 AM

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.

#13 JSelf   Members   -  Reputation: 102

Like
0Likes
Like

Posted 19 January 2011 - 09:37 AM

Any favorites for GIT hosting?

#14 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 19 January 2011 - 09:39 AM

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


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#15 rip-off   Moderators   -  Reputation: 8049

Like
0Likes
Like

Posted 20 January 2011 - 05:01 AM

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.

#16 Zebranky   Members   -  Reputation: 100

Like
0Likes
Like

Posted 21 January 2011 - 12:25 PM

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.

#17 Fl4sh   Banned   -  Reputation: 30

Like
0Likes
Like

Posted 07 February 2011 - 03:07 PM

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? Posted Image
They hated on Jeezus, so you think I give a f***?!

#18 Sammie22   Members   -  Reputation: 102

Like
0Likes
Like

Posted 07 February 2011 - 04:45 PM

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

#19 Nanoha   Members   -  Reputation: 296

Like
0Likes
Like

Posted 07 February 2011 - 05:06 PM

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.

#20 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 08 February 2011 - 07:52 AM

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? Posted Image


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.


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS