How to collaborate on projects with SVN

6

Index

Stats

22,752 visits, 58,626 views

Tools

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 25 Apr, 2013. Last updated 1 Apr, 2020

First commit

The trunk folder is empty, and there's nothing on the server. Someone has to be first to put some files on SVN. Pick a client to be the first committer. If you have an existing project you want to move to SVN, copy the project folder inside the trunk folder now. Otherwise start a new empty project in Construct, and save it as a folder project in the trunk folder. You should make another subfolder in trunk for the project, so the project folder is actually something like:

\trunk\MyProject\

This allows you to have other projects in the same repository, and also allows you to source-control other materials in other folders like documentation, todo lists, tools, technical information, information for other team members, and pretty much anything else related to the project at all. It's very useful to have all files related to your project on SVN, so you can collaborate on those as effectively as you can with the project itself. For example you could even track changes to your todo list over time, and see who made which changes. You can add extra files for the first commit now, if you like.

Notice your project folder in trunk doesn't have an extra icon over it. This is because TortoiseSVN ignores everything until you specifically add it to source control. Later on you'll still need to regularly add the new files that appear as you add to your project. However for now we just want to commit the initial files.

Right-click the 'trunk' folder and choose TortoiseSVN -> Add. This is recursive, so it'll look in all subfolders. (Note: if you right-click a particular folder or file, only that will be added, so be sure to do this on the parent folder that holds everything.)

The Add dialog appears:

This lets you confirm what you're adding. The files with a ticked checkbox will be added. Note the .uistate.xml/.uistate.json files are skipped, because we added them to the global ignore pattern earlier. If they show up, you can untick them so they won't be added, or press Cancel and go back to amend the ignore list. Don't untick any project files or you'll end up with errors in Construct due to the files going missing.

In this case everything is fine so we click OK to add the empty project files to SVN.

Notice now in Windows the trunk folder icon has changed:

The red exclamation mark icon indicates it has contents which have been changed but not committed to the server. The green ticks for the other folders indicates they haven't been modified. Also note the project files have a plus icon over them:

This indicates the folder/files have been added, but not yet sent to the server. Let's send them to the server now. Right-click and select SVN Commit. This is what you'll be using regularly to send your changes to the server.

The Commit dialog appears. This is an important part of the workflow of source control.

The Message is very important. You'll want to provide a comprehensive and useful description with every commit you ever make, describing what's been changed and why. Later on when we use some of the incredibly useful tools like the log history, the description will help you remember what you were doing at the time and what the change involves. Imagine a team member looking up a 6-month old change (this happens!) - they are going to rely on the description almost exclusively to both find the change they're looking for, and to remember what exactly was done. Both for yourself and your team mates, be sure to reliably write good commit messages.

As with adding, there's a list of files involved in the commit, with checkboxes. You can untick some checkboxes if you want to commit those files separately (useful if you made two unrelated changes and want to commit the first alone). In this case we want to commit them all, so leave them all ticked and press OK.

TortoiseSVN will show a log of activity, then say "Completed". Note the revision number which is how many commits there have been to the server - a useful way to note the version of both the project and individual files. The project files are now on the server's master copy. The project files on the client now also show a green tick - they are now up-to-date with the server, so they no longer count as modified by the client.

Note the .uistate file has no icon. It's an unversioned file, so has no status.

Updating other clients

Your other clients still have empty folders. Updates are not automatic, so the client has to explicitly choose to do them. We know the server has some project files on them, so head to another client and right-click on the empty 'trunk' folder, and choose SVN Update.

Notice even before the update, when the server has newer files, the icon is still a green tick. That only means this client hasn't changed anything. It does not guarantee that there are no changes on the server, but it does guarantee that should that file have been changed on the server, it will update successfully without conflicts.

When you select SVN Update, TortoiseSVN should work away, and moments later your client should have the project files as well with green ticks to show they're unmodified. Congratulations, you've transferred changes to the server then updated them to another client! Notice the .uistate files are missing, because they weren't sent to the server. That's good, because we don't want them on anyone else's computer. When we open the project Construct will create new .uistate files for that client, and not share them over SVN either.

Since updates are manual, you need to make a habit of updating before making any new changes. This reduces the chance of a conflict.

Updating and committing is the essence of the SVN workflow. The second client can now make some changes, commit them again, then the first client can update again to receive the changes. There's no particular need to co-ordinate commits and updates, but co-ordinating to make sure two people don't edit the same part of the project at the same time is useful to avoid conflicts. (More on conflicts later.)

A note about TortoiseSVN

Remember that when you right click and add, commit or update, only the files or folders you right click are affected. For example if you right-click a single file and choose Update, TortoiseSVN will only attempt to update that single file, and not the rest of the project. If you want to guarantee you always update and commit for the entire project, be sure to right-click the root folder when choosing the SVN commands.

  • 8 Comments

  • Order by
Want to leave a comment? Login or Register an account!