Difference between revisions of "Subversion"

From Open Surge Engine Wiki
Jump to: navigation, search
m (moved Patch files to Subversion: better name)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This is a tutorial on the creation of patch files using the Subversion command line tools.  While the info is currently targeted towards Windows users, it should be beneficial to all programmers not familiar with it already.   
+
{{deprecated}}
 +
 
 +
This is a tutorial on using Subversion to work with the Open Surge code, as well as the creation of patch files.  While the info is currently targeted towards Windows users, it should be beneficial to all programmers not familiar with it already.   
  
 
The good news is that it is not difficult to learn or do, and once you have made your first patch file you'll wonder why the heck someone didn't think of that before (they did in 1974).
 
The good news is that it is not difficult to learn or do, and once you have made your first patch file you'll wonder why the heck someone didn't think of that before (they did in 1974).
Line 12: Line 14:
 
The link in Step 1 points to Subversion's new home which may change a bit still, but at the time of this writing there is a link to ''Binaries'' on the left side of the page and Windows files are near the bottom.  There are presently five options for Windows, but the author of this tutorial only has experience with ''SlikSVN'', so neither of them are endorsed over any other.
 
The link in Step 1 points to Subversion's new home which may change a bit still, but at the time of this writing there is a link to ''Binaries'' on the left side of the page and Windows files are near the bottom.  There are presently five options for Windows, but the author of this tutorial only has experience with ''SlikSVN'', so neither of them are endorsed over any other.
  
After correctly installing the SVN package, its time to get a hold of the OpenSonic source code.  We'll be using the ''command prompt'' for this job, so if you are not familiar with '''C:\>''' you're gonna get some practice now.
+
After correctly installing the SVN package, its time to get a hold of the Open Surge source code.  We'll be using the ''command prompt'' for this job, so if you are not familiar with '''C:\>''' you're gonna get some practice now.
  
 
  '''Step 2)''' Open a command prompt window
 
  '''Step 2)''' Open a command prompt window
Line 25: Line 27:
 
When in doubt, search the web.  Once you are ready, its time to get to work.
 
When in doubt, search the web.  Once you are ready, its time to get to work.
  
  '''Step 3)''' Find a directory for the OpenSonic files and change to it
+
  '''Step 3)''' Find a directory for the Open Surge files and change to it
  
 
The author has a folder on his computer at "c:\projects" where all his source checkouts exist.  You should be able to make this folder on your own (or one of your choosing) but here is a simple set of commands to get it done:
 
The author has a folder on his computer at "c:\projects" where all his source checkouts exist.  You should be able to make this folder on your own (or one of your choosing) but here is a simple set of commands to get it done:
Line 35: Line 37:
 
Remember, you only have to do the second line ("md projects") once.  After that, you should be able to hit the other two of those to get back to the projects folder you made.
 
Remember, you only have to do the second line ("md projects") once.  After that, you should be able to hit the other two of those to get back to the projects folder you made.
  
  '''Step 4)''' Check out the OpenSonic project
+
  '''Step 4)''' Check out the Open Surge project
  
 
Presently, the command to do just that is:
 
Presently, the command to do just that is:
  
  svn co https://opensnc.svn.sourceforge.net/svnroot/opensnc/opensonic/trunk opensonic
+
  svn co https://opensnc.svn.sourceforge.net/svnroot/opensnc/opensurge/trunk opensurge
  
== Working with the OpenSonic code ==
+
== Working with the Open Surge code ==
You only have to check out the OpenSonic code once, unless you want a clean checkout somewhere else.  To grab the server changes and ''update'' your checkout, change into your OpenSonic folder and run the ''svn up''.
+
You only have to check out the Open Surge code once, unless you want a clean checkout somewhere else.  To grab the server changes and ''update'' your checkout, change into your Open Surge folder and run the ''svn up''.
  
 
  cd \
 
  cd \
  cd projects\opensonic
+
  cd projects\opensurge
 
  svn up
 
  svn up
  
 
You'll want to update your source checkout whenever you start coding for the day or after a significant break, unless you are confident nothing has changed.   
 
You'll want to update your source checkout whenever you start coding for the day or after a significant break, unless you are confident nothing has changed.   
  
=== Scenario ===
+
== Pulling a "diff" ==
 
Let's say you've sat down, updated the source checkout, and started working on a file such as ''src\level.c'', making several changes that would be difficult to describe in a forum post.  Go ahead and pull a diff of this file to see what your changes look like:
 
Let's say you've sat down, updated the source checkout, and started working on a file such as ''src\level.c'', making several changes that would be difficult to describe in a forum post.  Go ahead and pull a diff of this file to see what your changes look like:
  
Line 69: Line 71:
  
 
Good luck!
 
Good luck!
 +
 +
[[Category:Users]]
 +
[[Category:Cookbooks]]

Latest revision as of 19:01, 11 June 2018

This section is deprecated due to newer versions. We ask that you don't use the information provided in this section, but read up on the most recent information available on this wiki or in the forum.

This is a tutorial on using Subversion to work with the Open Surge code, as well as the creation of patch files. While the info is currently targeted towards Windows users, it should be beneficial to all programmers not familiar with it already.

The good news is that it is not difficult to learn or do, and once you have made your first patch file you'll wonder why the heck someone didn't think of that before (they did in 1974).

Introduction to Revision Control

Revision control came about in 1972 as a way to keep track of source code changes made by multiple developers. Files are committed to a source code repository, from which previous versions can be retrieved. Over the years various applications handling this job have appeared, some still alive today with quite useful features.

One popular revision control offering goes by the moniker SVN but is more officially known as Subversion. In theory the Subversion package is a suite of tools designed with nearly all you would need to maintain your code project over space and time; in practice it's just a quick install and learning a few ubiquitous commands.

Step 1) Download and install Subversion from http://subversion.apache.org/

The link in Step 1 points to Subversion's new home which may change a bit still, but at the time of this writing there is a link to Binaries on the left side of the page and Windows files are near the bottom. There are presently five options for Windows, but the author of this tutorial only has experience with SlikSVN, so neither of them are endorsed over any other.

After correctly installing the SVN package, its time to get a hold of the Open Surge source code. We'll be using the command prompt for this job, so if you are not familiar with C:\> you're gonna get some practice now.

Step 2) Open a command prompt window

Vista users can shift-right-click the desktop and hit "Open Command Prompt Here". XP users will have to hunt for it in the programs folder or use the Run... box (just type "cmd" and hit enter).

Rather than teach you command prompts, go ahead and check out Microsoft's input on the subject at their Shell Overview page. To continue this tutorial you must be able to do the following:

  • Change directories using cd command
  • Make new directories using md command

When in doubt, search the web. Once you are ready, its time to get to work.

Step 3) Find a directory for the Open Surge files and change to it

The author has a folder on his computer at "c:\projects" where all his source checkouts exist. You should be able to make this folder on your own (or one of your choosing) but here is a simple set of commands to get it done:

cd \
md projects
cd projects

Remember, you only have to do the second line ("md projects") once. After that, you should be able to hit the other two of those to get back to the projects folder you made.

Step 4) Check out the Open Surge project

Presently, the command to do just that is:

svn co https://opensnc.svn.sourceforge.net/svnroot/opensnc/opensurge/trunk opensurge

Working with the Open Surge code

You only have to check out the Open Surge code once, unless you want a clean checkout somewhere else. To grab the server changes and update your checkout, change into your Open Surge folder and run the svn up.

cd \
cd projects\opensurge
svn up

You'll want to update your source checkout whenever you start coding for the day or after a significant break, unless you are confident nothing has changed.

Pulling a "diff"

Let's say you've sat down, updated the source checkout, and started working on a file such as src\level.c, making several changes that would be difficult to describe in a forum post. Go ahead and pull a diff of this file to see what your changes look like:

svn diff src\level.c

The results of this command are dependent entirely on what changes are made to that file, so if you just tried it on a fresh update you'll naturally get nothing. Assuming you do have an output of semi-intelligible quasi-text from that command, lets convert it to a patch. You can call the file what you want but the general idea is:

svn diff src\level.c > name_of_patch_file.txt

Now you have a patch file, which can be uploaded and shared with others working on the project. The process is as simple as it is straightforward.

Summary

Being able to pull a diff, store it in a file, and call it a patch is nothing special by itself, but the time it saves others who do want to see your work several minutes of hand-copying from the forum.

Also, patches tend to impress older programmers for some reason, possibly tickles their nostalgic bone. If you find yourself in an interview, just asking if they want changes committed directly or in patch form could be a landing point.

All said and done, contributions will be appreciated, and there is not any requirement which says code suggestions must be in patch form. Ultimately, though, the less time spent examining the impact of your work on the game, the more time will be available for making that impact a reality.

Good luck!