Source version control

One of the problems in making large changes to the Second Life source is keeping track of changes, in order to be able to generate patches to submit. Also longer term, some way of keeping up with LL's changes to the source is needed. This page is an attempt to explain how to do that.

Ad-hoc

If you're not familiar with any source control systems, you can try to not use any, and instead just use the diff and patch utilities. This approach is very strongly discouraged because it doesn't scale at all. Nevertheless, it works OK for smaller things, like 1 line fixes to the source.

First, create a copy of the source:

% cp -Rdp linden linden.orig

Do some work on the linden directory. To make a patch use 'diff -u':

% diff -ru linden.orig linden > my_modification.patch

Keep the patch around. If LL releases a new version you can apply it to the new source:

% cd linden
% patch -p0 < ../my_modification.patch

This method has many disadvantages: it wastes huge amounts of disk space, is inefficient and error prone.

Subversion

Subversion is a much better option. However, it presents a bigger problem. LL offers a readonly Subversion repository that you can use to get the latest source. However, since you can't commit to it, you'll need to copy the source into your own repository. First, of all, you need to create your own repository. If you have several computers, you should do this on a machine you can reach from anywhere you might want to do development. Ideally it should be a machine accessible from the Internet.

For the purposes of the explanation, I will assume that your SVN repository is accessible through a web server at http://svn.example.com/secondlife. Check the Subversion manual for more information of how to access a repository.

First, create a repository somewhere convenient. /var/lib is a common location for a server setup, but you can choose any other.

% svnadmin create /var/lib/svn/secondlife

Now create a local directory with the initial files. By convention, SVN repositories generally have "tags", "branches" and "trunk" directories at the top level. We won't create trunk yet. The main development happens in trunk. The 'vendor' directory is for holding the original SL source, with the latest version in vendor/current, and a tag in /vendor per SL release.

% mkdir tags
% mkdir branches
% mkdir vendor
% mkdir vendor/current

Import the basic structure into your SVN repository:

% svn import -m "Initial import" http://svn.example.com/secondlife

Now move the original directory out of the way, and check it out:

% svn co http://svn.example.com/secondlife

Now you have a working copy with the empty structure. Here comes the complicated part, how to integrate LL's source there and keep it up to date. Doing this is harder than it sounds, because you need to add new files, remove deleted ones, and keep track of renamed ones (if possible). The easiest way to do that is to use the svn-load-dirs utility.

First of all, get the SL source. Get the archive and extract it. I recommend checking in only the source package, and leaving the art and libraries out of the repository. The art is best left out because it's big and will slow things down if your SVN repository is located for instance on a shared hosting server. The libraries must be left out if you intend to let anybody else access your repository because some libraries in the archive can't be redistributed.

You should now have a "linden" directory with the source code. Now use svn-load-dirs to load it:

% svn-load-dirs -t 1.17.0.12 http://svn.example.com/vendor current linden

If your repository is accessed through the internet, this can take a while (even hours)

This will load the source from the linden directory, into http://svn.example.com/vendor/current, and at the same time create a tag in http://svn.example.com/vendor/1.17.0.12. The tag is a very good idea as it allows comparing LL releases easily, makes it easy to determine the last version you merged, and simplifies keeping up with LL releases a lot.

Now from your working copy, run "svn update":

% svn update

This will bring it up to date, and fetch the recently imported LL source. Now you can start your own branch:

% svn copy vendor/current trunk

Now you have the trunk branch for working in. Go and do something in there. Now suppose LL releases a new version. First, repeat the svn-load-dirs step above. Then you can merge the new changes into trunk:

% svn merge http://svn.example.com/vendor/<previously_merged_release> http://svn.example.com/vendor/current trunk

Now the new LL changes will be merged with your code. You can then "svn diff vendor/current trunk" to get a patch to submit.