Imagine there are two developers working on a project. Both need to work on separate files at the same time, and they might change methods in the same files. Merging code can be difficult and time-consuming but this guide should save you some time.
- Required Software
- Adding a new project to a repository
- Checking out (downloading) the latest copy
- Committing changes (uploading)
- Deleting Files
- Further Reading
When you start a new project, you’ll need to add it to Subversion by making an initial commit.
Click File->Subversion->Add Solution to Subversion.
Enter the location of the repository to which to upload the solution and the name for it.
Perform the commit by clicking Commit in the Subversion tab.
Before you start work, you to need the latest copy. If this is the first time you’ve worked on a project, you’ll need to open a solution from the repository.
Click File->Open from Subversion->Open from Subversion and enter the repository address.
Choose where you want to save the solution to (this will be the local copy).
If you’ve already worked on the project, click Update from the Pending Changes tab. This will replace your local copy the latest copy from the repository.
Assume you checkout a project, add a class called NewClass1.cs and update a method in an existing class.
When you’ve finish what for the day, commit your changes by clicking Commit. If no-one else has made changes, you’re done. You can add some notes about what you’ve done if you like (which makes it easier to find specific versions or go back later on).
If someone else has changed the code (checkout out a copy, made changes and committed it to the repository) since you checked out your copy, AnkhSVN won’t let you commit until you merge your changes.
Assume now you’re the second developer, you checkout the latest version, add a class called NewClass2.cs and change the same method as the first developer.
This is because someone else has committed a newer copy of a file you’ve changed.
Click Update to load the changes from the repository.
You can then see a list of conflicting files, for each one, right click and select Edit Conflicts. The first time you do this you’ll need to set TortoiseMerge as the program to use.
Merging can be a bit intimidating, as you can easily wipe out someone else’s or your own changes (but that’s the same regardless of whether or not you’re using Subversion). The nice thing about the Subversion approach is that you can usually go back if you totally mess something up.
You can choose to either use your entire file, use the entire file from the repository or choose which lines from each file to use. If you’ve added something no-one else has touched or vice-versa, TortoiseMerge will show it in yellow and should copy it automatically. Sometimes you may need to copy the change across manually. Red lines indicate a conflict (you’ve changed the same thing as someone else). You’ll need to work out whose change to keep by talking with whoever made the commit (this can be determined using SVN’s Blame feature, which lists changes, who made them and what notes they added).
When you’ve decided on which changes to keep, you can see the final file at the bottom of the window. Save and close the file when you’re done.
When you go back to Visual Studio the change should be detected.
You should now be able to commit the project from Visual Studio.
Anyone who checks out the project now will see the changes committed by the second developer.
The one thing Subversion gets confused with is deleting files. Sometimes if you delete a file in Explorer, Subversion will complain and prevent you from updating.
The easiest way to reduce the chances of this happening are to either right click, Subversion->Delete in Visual Studio or right click, TortoiseSVN->Delete in explorer.