Author Topic: Svn Usage Note  (Read 2076 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Svn Usage Note
« on: April 04, 2010, 10:26:31 PM »
I've noticed more people have been using the SVN repository as of late. I thought maybe it's time to start adding some suggested usage notes. Some of these options are a bit hidden, and others are more obvious if you have experience working with SVN, or know a bit about how it works internally. Some are just to help communicate better with other developers.


1) You should enter a log message with your commit to summarize why the change is being made. This can be really simple, but generally shouldn't be blank. Take a look at the log for examples of messages. This makes searching for a specific change easier. Examples might be "Added new project X", or "Fixed bug X", or "Added feature X".

2) You should (usually) only commit source files, not compiler outputs. The compiler outputs are perhaps more useful in a release pack (zip/rar) rather than in the repository, or in cases where there is no source code and work is done directly on the binary code, such as patches to Outpost2.exe. You should not generally commit compiled DLL files for level projects, and you should definately not commit intermediate files, such as .obj files. I generally add an ignore for any Debug/, Release/, or Release-MinSize/ folder to ensure they don't get accidentally committed. Files which should be committed are source files (.cpp, .h), and project/workspace (solution) files (.dsw, .dsp for MSVC6, .sln, .vcproj for Visual Studio 2008). If both MSVC 6 and VS2008 project files exist, and both contain the same data, then I have a preference for only storing the MSVC 6 project files. The MSVC 6 project files can be auto upgraded to VS2008 versions, but you can't open the VS2008 project files in MSVC 6, which a lot of people still use. If you make changes to the project file using VS2008, then by all means, commit the VS2008 project files to the repository. You should probably not commit other files that are generated automatically by your development environment. Also, be aware that the other files may contain personal information, such as your login account name.

3) You should not constantly add and remove files to update them. If you make changes to a file, you may notice Tortoise SVN has a little red exclaimation icon overlaid on top of the file's icon. This is to let you know that your local working copy has changed from the last sync with the repository. The proper way to push that change to the repository, is with an SVN commit (or perhaps an SVN revert). Doing an SVN delete, following by an SVN add is a lot more expensive in terms of storage costs in the repository, and it also breaks history (the log) and requires more bandwidth for the new addition. The strength of SVN is that is stores changes to files between version, rathern than complete copies of each version.

4) If you are creating a new branch of an existing project in the repository, or perhaps starting a new one using an old project as a template, try using SVN copy. Again, this is cheaper in terms of repository storage, and you can potentially trace history across the copy to see where the project comes from. For instance, when creating a new level, you can potentially start with an SVN copy of the blank template project. To do an SVN copy from Windows Explorer, right-click drag the file or folder to it's new destination. When you release the right mouse button, a menu will pop up asking you what you want to do. You can choose SVN copy, SVN move, regular copy, and regular move.

5) Use SVN move to move or rename an existing file. Again, this is cheaper to store, and doesn't break history. See note 4, as it uses the same right-click drag method as SVN copy.
 

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Svn Usage Note
« Reply #1 on: April 06, 2010, 10:09:40 PM »
Hmm, I forgot about CodeBlocks, and looking at SVN logs, perhaps it was an important detail.


If you're using CodeBlocks to edit your project, then you probably DO want the CodeBlocks project files stored in the SVN repository. I didn't mention them above, but then, I'm not too sure what extra files code blocks uses.

I guess I kind of assumed people would either use MSVC 6, or Visual Studio 2008, now that Visual Studio 2008 is a free alternative to MSVC 6. It's a bit of a sizable download though.