Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Setting Up and Running Subversion and Tortoise SVN with Visual Studio and .NET : Page 3

Find out how to set up and configure the free, open source Subversion source control system quickly and easily.


advertisement
Adding Projects and Files to Source Control
Next, here's a walkthrough showing how to add Visual Studio projects to Subversion's source control. As mentioned, Tortoise SVN doesn't use any Visual Studio integration; it manages source control at the directory and file level. Basically, you can add any file or directory to source control, which means you can use Subversion with any type of tool that has files related to it.

You need to decide how to lay out the repository. If you have many projects, it's probably a good idea to have a layout that groups things nicely. I like to use a structure such as:

Repository -- ProjectGroup1 (ie. Solution level) ----Project ----Project ----Project ----Project -- ProjectGroup2 (ie. Solution Level) ----Project ----Project

But that's entirely up to you. I like a separate "Project Group/Solution" type folder so I can use it to hold Solution files and as a "header" folder that serves as a grouping for the subprojects. Otherwise, it's too easy to end up with a deep mess of project level folders.

The examples here use a starting folder structure of:

Repository -- SummaLp ---- SummaLpManager ---- SummaLpBusiness ---- SupportAssemblies

Creating a New Top-level Folder
Creating projects is a little bit convoluted with Tortoise, because while you can easily import content into SVN on the server, an import doesn't automatically check out the content locally. You also can't immediately check out after you've imported because Tortoise will not allow you to overwrite existing files that are not under source control. Therefore, it's best to avoid using the Import feature here. Instead, create a directory in the repository without any files, check out the folder, and then manually add files and subfolders.

For this example, create a top-level folder named SummaLp as shown in Figure 2 and Figure 3.

 
Figure 2. Create New Folder: It's best to create a new folder in the repository first, check it out, and then add files with Tortoise SVN.
 
Figure 3. Adding Files: After the new folder exists you can add files to the repository.

Here's the procedure:
  1. Go into TortoiseSVN and select Repo Browser (right-click, choose Tortoise, and then choose Repo Browser).
  2. Use the Create Folder option to create a new top-level folder just beneath the main repository (name it SummaLp).
  3. Go back to Explorer and go to or create a SummaLp folder.
  4. Right-click the folder and select "Checkout…" as shown in Figure 4.
  5. Select the top-level folder in the repository and point at the corresponding local path as shown in Figure 5.
 
Figure 4. File Checkout: To check out files, select the SVN Checkout… item from the menu.
 
Figure 5. Checkout: Completing checkout copies files and folders from the repository to the specified local directory.

 
Figure 6. Source Control Icon: Folders and files under source control show up with icon overlays that show checkout status.
This puts the root folder under source control, so you can now add individual files or other folders more easily. Nothing's really checked out yet—this only marks the folder so Subversion will watch it. Go back to Explorer and check the folder; it should have a green checkmark icon next to it now (see Figure 6).

Don't just import everything listed below in one pop: It'll be much easier to create the project folders in the repository first, and then add the individual files after the folder is under source control.

Select one of the project folders and basically follow the same routine as above.

  1. Go into Tortoise and browse to your repository.
  2. Create a folder with the project name below the SummaLp folder (SummaLpManager).
  3.  
    Figure 7. Adding Files: You can add files to source control and the repository from your local installation using the "Add…" option.
  4. Go into Explorer and check out into the corresponding folder. This puts the project folder under source control.
  5. Select files and folders, right-click, and then add as shown in Figure 7.
Be selective, and if necessary, add files individually rather than adding entire subfolders. You'll want to skip over folders such as the obj folder, notes, suo, .user files, log files, and anything else that you don't want tracked.

After adding the files, you'll see a directory full of files with plus signs next to them. The plus sign means the files have been added to the local store but not synched with the server.

To sync them with the server, right-click on the project folder, and select "SVN Commit" as shown in Figure 8.

 
Figure 8. Committing Changes or Added Files: To commit any changes or added files to the repository, use the SVN Commit option.

 
Figure 9. Synched Local Copies: After you've added and checked in all files, you should see a clean repository with all green checks.
The commit process basically tries to synch all local changes to the server. In this case, committing copies the new files to the server and into the repository. If there are any conflicts, such as changes made to a file that can't be automatically merged, the entire update fails and notifies you. Commit is an all or nothing operation—all files have to pass or the "commit" is aborted. If there's a conflict, you have to resolve the conflict before you can check the file in.

After committing, your local copy should be up to date, as shown in Figure 9. Your repository is now synched.

The repository now holds the same set of files as your local folder containing the "controlled" files. Figure 10 shows the Repo Browser view. Repeat this process for each of the other project folders.

 
Figure 10. Repository Browser View: The Repo Browser lets you see all the files in the repository, which should now match the local "controlled" file view.
You'll also want to add the Solution file to source control. Just add it (click Add) and then commit it (click Commit) if it wasn't among the files you already checked in. It's best to have the solution file in the root branch (SummaLP in the example) to ensure that other paths remain properly relative.

The repository is now set up and ready for shared use. Here are the key steps to remember when creating new branches and adding new files in the repository:

  • Create a folder in the repository first.
  • Check out just the folder to your local folder.
  • Add files with Tortoise in Explorer.
  • Commit your changes.
Creating a Local Copy from the Repository
The work described in the preceding section needs to happen only once—when you first create the repository. If you are a developer who's simply connecting to get the latest revision for a local copy down to a local machine for the first time, the process is much easier:

  1. Pick a directory where you would like to create the local copy.
  2. Right-click and choose SVN Checkout… as shown in Figure 4.
  3. Open the repository, set the project folder in the repository, and then provide the local folder path that will receive the checked out files. In the example above, you would choose SummaLp (the top-level folder) and then choose Checkout to bring down the entire project with the Solution file.
Post Setup Cleanup
Remember that after downloading the project to your local machine, you may still have to configure the project properly. If you're dealing with an ASP.NET Web application, you may have to register a virtual directory and set directory permissions or add script maps, etc.

Also, depending on how well you set up the repository, you may be missing some project dependencies. You want to make it as easy as possible to get access to any support assemblies required for the project by other users. I tend to create a SupportAssemblies folder in the repository with each solution that holds all non-project assemblies that might be required by the project. I bind to those assemblies in each project to ensure that all developers are working with the same version of external assemblies.

With components in the GAC, this can be trickier. In that case, users must ensure they have the appropriate components registered on their machines. If possible (and if licensing allows), I still distribute any controls in the SupportAssemblies folder to make sure other developers can get up and running. It's a good idea to document any dependencies, and provide a Readme file with the project.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap