SD119390

Control Your Code: Introduction to Source Control for

Programmers and CAD Managers
Ben Rand
Job Industrial Services, Inc.

Learning Objectives
• Learn how to create a repository for code projects
• Learn how to commit code and resolve conflicts
• Learn how to compare previous versions of files to see changes
• Learn how to create and merge branches while maintaining working code

Description
Do you write code in any language (LISP, C#, JavaScript, and so on)? Do you work in a
programming team or solo? Do you wish you had a way to compare today's version of the code
to what you or someone else wrote several weeks or months ago? Do you ever make a coding
mistake and wish you could easily revert back? Is your code backed up? In this class, we'll
explore how to get started with source control software, no matter what language you currently
program in. Whether you're a CAD manager who infrequently dabbles in LISP code; a newbie
.NET programmer trying to write your first plug-in for AutoCAD software, Revit software, or 3ds
Max software; or a full-time web developer, you can benefit from this class. We'll look at how to
set up code repositories for LISP or .NET code (or any other code, for that matter), check out
repositories, update and commit code changes, compare to previous versions, roll back to
previous versions, and more.

Speaker(s)
Ben Rand has been using AutoCAD software since Release 12 (not 2012…R12). He learned to
program using LISP in AutoCAD, worked his way up through VBA, VB6 and VB.NET, and now
spends most of his days programming in C# (occasionally still in AutoCAD!). He dabbles in
other languages like JavaScript, Ruby, Java and Python. He has worked in the Industrial
Engineering field for more than 15 years as a CAD Manager, developer and IT Director. He’s
also a mentor for AutoCAD software trial users, and was the 2013 Top DAUG overall winner.
Ben is the proud father of four children and enjoys reading and playing a variety of sports
including pickleball, tennis and volleyball.

Page 1
Introduction to Source Control Software
Source Control software1 (SC for short) is used to record changes to your code over time. You
might think of it as a backup system, but it’s far more than that. It’s more like a database for your
files and project structure (folders), but one that remembers every change you commit to the
system, and who made each change. By tracking every change to your code over time, SC lets
you easily compare the changes between two versions of a file at any point in time. You can
restore individual files or the entire project to a prior revision, branch projects to allow work on
an important new version while still maintaining the current “in production” code, then merge
branches back when development of the branch is complete.
SC is crucial for allowing multiple developers to collaborate on a project. Each developer checks
out his/her own copy of the code on their machine, periodically updating their copy to get the
latest updates from the repository and committing their own changes to the repository. SC helps
to mitigate conflicts when two developers attempt to update/commit a file with different changes.
Although SC is commonly used when working in programming teams, I’ve found it so important
that I will never program again without it (beyond a simple trash project), even when working on
solo projects.
A few key things to remember when using SC:
• If you write code that’s important to you, you should be using SC. You may not need to
do restores or comparisons daily, but when you do, you’ll be glad you have it.
• You can’t update frequently enough. Always update before you start to code, and before
you try to commit. This reduces your chances of conflicts.
• Commit frequently. I try to commit my changes no less than once a day2, if for no other
reason than knowing my work is backed up somewhere else.
Source Control Software
There are several well-known SC systems available, including Git3, Subversion4, CVS, and
Microsoft’s Team Foundation Server (TFS).
Each of these systems typically entails two main components. The first is a centralized server
component, capable of managing one or more repositories. The second is an application used
to communicate with the server component. These types of applications come in many forms,
from command-line utilities to Windows shell plugins, to IDE-specific plugins, and you’ll often
use two or more of these in conjunction with one another. I’ll refer to these types of applications
collectively as “tooling.” These applications serve to enable developers to get the latest version
of a code base to their machine for development, and then update the code base with their
changes when they are done.

1 Also referred to as Version Control System, VCS for short.

2 Your team may have guidelines about when you should or shouldn’t commit. “Don’t break the build” is a
common guideline requiring any changes you’ve made to compile before you can commit.
3 Github.com is a cloud-based VCS system. You can sign up for a free account, but repositories are open

to the public. You can also pay a small monthly fee for personal or organization accounts if you need
private repositories. Many open source libraries are located on github and if you have a distributed
development team, this is definitely something to consider. The Autodesk Developer Network team uses
github for many of its samples (https://github.com/ADN-DevTech).
4 https://subversion.apache.org

Page 2
SC for Free
There are many ways to start using SC for free. Here’s the list of what we’ll use for this class,
but know that there are other options for whatever platform you program on, and for most IDEs
in use (not the VisualLisp IDE, though ).
What we’ll use in this class:
• VisualSVN Server (http://www.visualsvn.com) is a free5 Subversion server.
• AnkhSVN (https://ankhsvn.open.collab.net/), a free Subversion plugin for Visual Studio
which lets you execute Subversion commands from within Visual Studio.
• Tortoise SVN (https://tortoisesvn.net/) is a free Windows Shell plugin, which helps you
execute Subversion commands from any folder, via simple right-click commands.
• NOTE: VisualSVN also provides a plugin for Visual Studio. This is free for personal use,
but you must purchase a license for use within an ActiveDirectory environment.
• Time permitting, I may do an example using the Eclipse IDE (popular for Java, Python,
and others), in which case I’ll make use of the Subversive plugin:
https://eclipse.org/subversive/downloads.php

Before proceeding, be sure that Visual SVN server is installed either locally on your computer,
or on a “server”—some other Windows computer on your network. You also need TortoiseSVN
installed on your Windows computer (the one you develop from), and the AnkhSVN plugin for
Visual Studio, if you are using that.

Creating a Repository for Code Projects

We need to start our journey into source control by creating a repository for our code. You have
a decision to make here: do you create separate repositories for each project, or one repository
with multiple project folders in it? I think the right choice largely depends on the types of projects
you work on. If you write code for multiple clients, you may be better off keeping each client’s
code in separate repositories. I write code just for my company, and although I have different
projects, I like to try and reuse components between projects. I find it simpler to use a single
repository, but really it works either way.

Quick Configuration of VisualSVN Server

There’s a little bit of initial configuration you should do if this is the first time you’re using
VisualSVN Server.

1. On the computer where it’s installed, start VisualSVN Server.

2. Right-click VisualSVN Server and choose Properties.
3. Click the Storage item and verify the folder is in a location you desire. NOTE: This folder
should be backed up, like any other important files on your network!

You may also want to look at Authentication where you can choose between Subversion’s own
authentication, or Windows authentication. We’ll stick with the default option, Use Subersion
authentication.

5 There is a paid edition of VisualSVN Server that enables some advanced Enterprise-specific
functionality.

Page 3
4. Click OK to apply your changes.
5. Right-click the Users folder and choose Create User….
6. Enter the user name and password information as requested. You’ll need to provide this
when you connect to VisualSVN Server from other clients, such as Tortoise SVN.

Creating a Repository
1. Right-click Repositories and choose Create New Repository.
2. Select the default Regular FSFS repository, then click Next.
3. Enter a repository name6. I’ll use AU2017 for this class.
4. Choose Empty repository for the structure (default option), and click Next.
5. Choose All Subversion users have Read/Write access7 (default option), then click
Create.
6. Make a note of the Repository URL, and click Finish.

At this point, you could be done with VisualSVN Server, other than occasional adding a user or
modifying access permissions. Most everything we’ll do from here out can be done from
TortoiseSVN or the AnkhSVN plugin, but there is one nice feature I want to point out in
VisualSVN Server first.
Creating a Project Folder
It’s typical within Subversion projects to have three main folders: trunk, branches and tags. We’ll
talk about these in more detail shortly, but let’s create a new project folder in the repository we
just created. We’ll use this to start managing that folder full of LISP code you all have out there
on your network.

1. In VisualSVN Server, expand the Repositories node, then right-click the repository you
just created and click New > Project Structure.
2. Enter a name8 for your project, I’ll call mine Lisp, and click OK.
3. Expand the new project node to see the structure that’s been created.

FIGURE 1 TYPICAL PROJECT STRUCTURE

6 Repository names may only include alpha, numeric, dash, dot or underscore characters.
7 You can of course choose different access options so that you have complete control over who has
access to what projects within your repository. Each project folder’s properties can be modified to
supersede the default repository settings.
8 See previous note about Repository names, same rules apply for project names.

Page 4
This is a nice feature because it creates all the extra sub-folders for us. We can create a project
folder using other SVN clients, but we have to create the sub-folders ourselves. We’ll do this in
a later exercise.
Getting the Project Url
VisualSVN Server provides a Url (basically a web address) for any given folder in the repository.
You should make note of this Url at this point, as you will need it when we begin using
TortoiseSVN in a later section.

1. In VisualSVN Server, expand the Repositories node, then the repository you created,
then select the Lisp (or project) node.
2. The Url is displayed at the top of the pane on the right. In the example below it is
https://VM-Win10-Ben/svn/AU2017/Lisp.
3. You can also right-click the folder and choose Copy URL to clipboard.

FIGURE 2 REPOSITORY URL

The Url is pretty easy to figure out: https://name-of-server/svn/name-of-repository/name-of-

folder/name-of-subfolder.

Understanding Trunk, Branches and Tags

Imagine your code project as a tree that grows over time. You develop the main functionality,
then later need to maintain the code, debugging, refactoring, and adding new features. Most of
the activity will take place in the trunk of this tree, hence the folder name, “trunk.”

When you release software, it’s often released with a specific version number. Because a
source control system has its own internal numbering system, it’s impossible to align this with
your application version. Rather than having to keep track of meaningless source control
numbers, you can create a tag, which is effectively a branch of your code, frozen in time (i.e. at
the time of release). Tags are stored in the “tags” folder.

Sometimes you need to add a new feature or do a non-trivial refactoring that is going to take
several days, weeks or months. Meanwhile, your application is in production and may need
ongoing maintenance while the new feature is developed. SC makes this easy to do by allowing
you to branch (or fork in git parlance) the code away from the trunk, hence the “branches”
folder. The trunk and each branch can be maintained independently, but it’s recommended that
the changes to the trunk be merged into branches periodically so they don’t diverge too much.

Page 5
 FIGURE 3 TRUNK, BRANCHES, AND TAGS

Eventually, the changes from each branch will be merged back into the trunk. This capability
would be extremely difficult to accomplish just copying files around yourself. But with SC, it’s
pretty easy to do.

Getting Existing Code into Source Control

Your code project might be as simple as a folder full of text files (the infamous “LISP” folder), or
it can be a complicated multi-project solution created with Visual Studio, Eclipse, XCode, Ruby
on Rails, etc. SC systems don’t really care how your code was created, or how it’s structured.
We just need to import it into a project folder in our repository, then check it out to get started.

In this section, we’ll lean heavily on the TortoiseSVN plugin for Windows, which you should
have installed earlier. You can close out

Import an Existing Project

In this course materials, you’ll find a LISP folder which you should extract to a convenient
location, such as your desktop.

In the real world, copy your “LISP” folder from the network to your local drive. The
network folder is your “in production” code, and it’s good practice to avoid modifying “in
production” code until you, the developer are ready to release it. Work from your local
copy when you’re working on the code.

1. Right-click the Lisp folder on your desktop to see the TortoiseSVN commands available.

Page 6
 FIGURE 4 IMPORTING CODE TO A REPOSITORY

2. Select TortoiseSVN > Import.

3. Enter the Url we located earlier and append /trunk to it, as shown below. We want the code
imported into the /Lisp/trunk folder, not the /Lisp folder. You can also click the … button, to
enter the Url, then browse the repository to select the correct folder.
4. Enter a message9 that describes the change you are making, then click OK.

FIGURE 5 ADDING A MESSAGE TO A COMMIT

Checkout Code from a Repository
In the previous section, you imported code into the repository, so you should be good to go,
right? Wrong. You need to checkout the code you just imported, which will add a special .svn
folder to the directory, which is how Subversion tracks changes between your local working
copy, and the copy in source control.

9Messages aren’t required with each commit, but they are very important because they provide
searchable notes you can use later to find a particular commit. If you don’t add messages to your
commits, they can’t help you out later!

Page 7
1. Right-click the Lisp folder on your desktop again, and choose SVN Checkout.
2. Verify the Url of repository, which should be the one you just imported into.
3. Verify the Checkout directory, which should be the folder you just right-clicked. Note that
the checkout directory folder name does not necessarily match the last folder name of the
project you’re checking out from10.

FIGURE 6 CHECKING OUT CODE FROM A REPOSITORY

4. Verify that HEAD revision is checked, then click OK.

5. Tortoise warns you that you’re about to checkout files into a non-empty directory. Since you
are checking out to the same folder you just imported from (no changes have occurred, yet),
click Checkout.
6. A summary of the checkout appears. Click OK.

So what actually happened? In this case, remarkably little. You’ll notice there’s a .svn folder in
the directory, and that’s about it. However, that folder is critical to Subversion and should
NEVER be modified11.

FIGURE 7 RESPECT THE .SVN FOLDER (LEAVE IT ALONE)

10 This is a good thing. Otherwise you’d have a bunch of “trunk” folders on your desktop with no way to
tell them apart.
11 If you really wanted to disconnect a working copy from Subversion, you could simply delete the .svn

folder. But don’t do this.

Page 8
If you start digging around in the .svn folder you’ll be shocked(!) and mystified(?!?) about the
complete lack of resemblance to your project structure or files. Frankly, it’s above our pay grade
to try and explain or understand12 it.

It’s important to understand that you now have a working copy of the entire project on your
desktop, and there’s the committed copy in your repository. Other developers might also check
out their own working copies at the same time. Subversion and Tortoise do the hard work of
merging everything together as everyone commits their changes. I’ll say this several more
times, though: always update your working copy before committing!

Committing Code and Resolving Conflicts

We’ve got our code under source control and can begin making changes to our code. How
exciting. This isn’t a coding class, so I’m not going to write exciting code, sorry. Plus I’ll be
showing examples in multiple languages and I don’t expect you all to know or use all of them.
The main point is pretty simple: I’m making changes to files, and we want to capture those
changes in our repository.

1. Open the JISCommon.LSP file in your favorite text editor13.

2. Scroll down to the comment that says “3D ON and OFF”. The comment formatting is
inconsistent with other comments, so we’ll clean that up as highlighted below.

FIGURE 8 CHANGED COMMENT CODE

3. Save and close the file.

4. Note the icon change in Windows Explorer.

FIGURE 9 CHANGED FILE STATUS ICON

12 If you have a burning desire to understand how git (and Subversion) work, check out Paolo Perrotta’s
“How Git Works” course on Pluralsight: https://www.pluralsight.com/courses/how-git-works. It’s a
masterpiece of explaining a complicated subject in an easy to understand way.
13 Notepad++ is a great (free!) text editor, but you can use VLIDE, Notepad, or whatever you like.

https://notepad-plus-plus.org/

Page 9
This is the TortoiseSVN shell at work, indicating that your copy of the file is different from the
version in the repository.
Committing Code to the Repository
Once we’ve tested that our change works, we should commit the change to the repository so
that other developers can update their working copies to the latest change.

1. Right-click the Lisp folder on the Desktop and choose SVN Update14.
2. Any changed files will be downloaded to your working copy, and any conflicts will be
highlighted in red. We’ll see how to deal with these later. Click OK.
3. Right-click the Lisp folder again and choose SVN Commit.
4. Enter a message (important!) and click OK.

FIGURE 10 COMMITTING A CHANGE

Note in the screenshot above that you see a list of all changed files and folders that are about to
be committed. After you commit, all the icons in your working copy should turn into green check
marks.
Dealing with changes from two (or more) developers—the Happy Path
If you are the one and only “Sole Maintainer of the Code”15 in your organization, as many CAD
Managers tend to be, then you’ll be pretty hard pressed to have a conflict with yourself16.
Conflicts will happen when you work in teams if 1) two people work on the same file and 2)
make different edits to the same lines of code. In this section, I’m going to fake a two-developer
situation. I’m going to checkout two copies of our Lisp project into folders Lisp_Dev1 and

14 Remember what I said before: Always update before you commit! Someone else might have committed
changes since you last updated. You want to be sure you have the latest version before committing your
own changes.
15 This position usually includes a royal scepter and crown, or cape.
16 Trust me though, it can be done. Particularly if you share projects among solutions. Moral of the story:

update your working copy before you start coding, every time. And commit your changes frequently.

Page 10
Lisp_Dev2. I’ll make changes to the same file in each folder, then walk through the
update/commit process.

1. Repeat the steps17 from earlier to checkout code from the \Lisp\trunk directory to a new
folder on your desktop called Lisp_Dev1.
2. Checkout the code a second time to a folder called Lisp_Dev2.
3. In the Lisp_Dev1 folder open the JISToolbox.LSP file and edit line 48:

(princ “\nHello AU2017”)

4. Save and close the file.

5. Update and commit your changes, and be sure to include a message.
6. In the Lisp_Dev2 folder open the JISToolbox.LSP file and edit line 50:

(princ “\nWelcome to the Venetian”)

7. Create a new file in the Lisp_Dev2 folder, and name it AUTools.lsp with the following
code:

(defun c:wft ()
(if (= (getvar "wipeoutframe") 0)
(setvar "wipeoutframe" 1)
(setvar "wipeoutframe" 0)
)
);end function WipeoutFrameToggle

8. Save and close the file.

Let’s review the project status. Developer 1 has changed a file, then saved and committed her
changes. Developer 2 has changed the same file (different lines), and added a new file to the
project.

9. Right-click the Lisp_Dev2 folder and choose SVNUpdate.

Tortoise shows us that JISToolbox.lsp has been merged. Keep in mind, we’re not done. We
haven’t committed Developer 2’s changes yet. But let’s take a look at what the update has
done.

17 From the section on Checkout Code on page 8.

Page 11
 FIGURE 11 UPDATE WITH MERGED FILES

10. Click OK to close the Update results window.

11. Open the JISToolbox.lsp file, and look at lines 48 and 50 where you should see the
changes from Developer 1, along with the uncommitted changes by Developer 2.

FIGURE 12 MERGED CHANGES IN JISTOOLBOX.LSP

12. Close the file, then right-click the Lisp_Dev2 folder and choose SVN Commit.
13. Check the Show unversioned files check box as shown below.

FIGURE 13 SHOWING AND ADDING UNVERSIONED FILES

Developer 2 added a new file. Tortoise recognizes that it’s not a versioned file (it’s not in the
“database”), so we need to add it.

14. Check the AUTools.lsp file to include it in the changes to be added to the repository.
15. Enter a message explaining your changes, then click OK.

Page 12
 FIGURE 14 COMMIT WITH ADDED AND MODIFIED FILES

There’s one more thing that needs to happen. Developer 1 doesn’t yet know about Developer
2’s changes. The simplest thing to do is to use the SVN Update command, which you should
get in the habit of doing every time you start to code.

16. Right-click the Lisp_Dev1 folder and choose SVN Update.

17. Check the contents of Lisp_Dev1 where you should see the (updated) JISToolbox.lsp
and the (added) AUTools.lsp files.

This demonstrated a “Happy Path” scenario where each developer was responsible for different
files, or made changes to distinct lines within the same file. Let’s next look at what happens
when a conflict occurs, where the same line is changed in two different ways by two different
developers.
Dealing with changes from two (or more) developers—the Conflicting Path
If two developers work on the same file, and make different changes to the same line(s), you’ll
wind up with a conflict that SC can’t easily work out. In this case, you’re going to have to work
out which version to keep, mine or theirs. But most SC tooling gives you tools to relatively easily
figure out what you want to do, and modify the files accordingly. Continue on with the
Lisp_Dev1 and Lisp_Dev2 folders from the previous section.

1. In Lisp_Dev1, open the AUTools.lsp file and add line 7:

(princ “\nLoaded AUTools”)

2. Save and close the file, then commit your changes.

3. In Lisp_Dev2, open the AUTools.lsp file and add line 7:

(princ “\nAU2017 is awesome!”)

4. Save and close the file, then use SVN Update.

Page 13
 FIGURE 15 UPDATE WITH CONFLICTED FILES

5. Click OK.

In Windows Explorer, notice what has happened.

FIGURE 16 ADDITIONAL FILES CREATED FOR CONFLICT RESOLUTION

AUTools.lsp is marked with the exclamation mark—conflicted! But several other files have also
been added:

• AUTools.lsp.mine is your current copy of the file.

• AUTools.lsp.r28 and AUTools.lsp.r29 are the two previous commits of the file.

The interesting one is AUTools.lsp. It has been modified to identify the conflicting lines.

6. Open AUTools.lsp.

FIGURE 17 A FILE SHOWING CONFLICTING LINES

Page 14
Lines 6-8 show the changes “you” (Developer 2) have made since r28. Lines 9-11 show the
changes “they” made in r29. I wanted you to see this, but picking through this is rarely how you’ll
resolve a conflict.

7. Close AUTools.lsp, then right-click it and choose TortoiseSVN > Edit conflicts.

This opens TortoiseMerge18, which displays the two conflicting versions side-by-side in a text
editor with some helpful tools to fix the conflict. Line 7 is different in each file, so you’ve got to
decide whose version to keep. We’ll keep “Mine” (Developer 2’s version).

FIGURE 18 TORTOISEMERGE HELPS YOU RESOLVE CONFLICTS

8. In the Merged – AUTools.lsp window (bottom pane), right-click the red lines at lines 6-
7, then choose Use text block from ‘mine’. Lines 6-7 will turn green in the Merged –
AUTools.lsp file.
9. Click Save, then click Mark as resolved when prompted.
10. Close TortoiseMerge and notice that the extra files have been removed from the
Lisp_Dev2 folder.
11. Right-click Lisp_Dev2 and choose SVN Commit.
12. Enter a message, then click OK.
13. Right-click Lisp_Dev1 and choose SVN Update to update that copy to the latest
revision.

18There are alternatives to TortoiseMerge, and you can configure Tortoise to use one of those if you
prefer.

Page 15
We’re done with the Dev1/Dev2 scenario, so feel free to delete one of the copies from your
desktop at this point.

Comparing Code to a Previous Revision

One of the key benefits of using Source Control is allowing you to view and compare any
previous version to your current working copy.

• It’s pretty common to comment out large sections of code that are no longer needed, but
you want to keep around, just in case. Over time, all of this “dead commented code”
starts littering your files, making it harder to read. And worse, you waste time trying to
figure out why that code is still there. When code is no longer needed, you should delete
it. That sounds scary, but in a source controlled project, you can always compare the
working copy to a prior version.
• Another common occurrence when working in teams is comparing the file you just
inherited with previous versions to see what changed.
• Sometimes you make a change that you think is working, then later discover a bug. You
may want to revert a portion of the file back to a previous version.

There are a number of ways to go about this.

1. In either Lisp_DevX folder, right-click the AUTools.lsp file and choose TortoiseSVN > Diff
with previous version.
2. TortoiseMerge opens again, with the two revisions side by side, and the differences
highlighted.

FIGURE 19 DIFF PREVIOUS VERSIONS

Note that you can “restore” chunks of code here using copy/paste, or right-clicking and choosing
one of the “Use…” options.

If you need to compare to a revision further back, do the following:

1. Right-click the file and choose TortoiseSVN > Show log.

Page 16
 FIGURE 20 VIEWING THE LOG OF CHANGES TO A FILE

In this case the log files shows you a complete revision history for any commit where the
selected file was included. To see a complete revision history for the project, you’d need to use
Show log from the main project folder.

2. Right-click any revision in the history list at the top of the dialog and choose Compare
with working copy.
3. TortoiseMerge opens with the selected version compared against the current working
copy.
Exporting code to an unversioned folder
One last thing remains with our Lisp example. Early on, we copied a “production” folder from a
network location to our local computer, and put the local copy into source control. We made
changes and committed them to the repository. After testing, you’re ready to put the
modifications back into production.

1. Right-click the Lisp_DevX folder on your desktop, and choose TortoiseSVN > Export19.
2. Browse to the drive and folder you want to export to and click Select Folder.

19You can also choose Repo-browser, verify that you are on the correct sub-folder (i.e. “trunk” or a folder
under “branches”, then right-click the appropriate folder and choose Export.

Page 17
The latest version of your project is exported to the selected folder. Note that TortoiseSVN will
prompt you if you will be overwriting existing files.

3. Choose Overwrite to proceed (or Cancel if you’re not sure and need to select a different
output folder).

You can now move the unversioned folder back to its proper location on the network.

Using Subversion with Other Project Types

We’ve spent a lot of time with Lisp based examples, but many of you are likely programming in
a variety other languages and/or IDEs. For this next section, we’ll use Visual Studio to start a
very simple Autocad plugin project. Again, the point is not the code itself, but to look at how to
integrate source control into a Visual Studio solution. We’ll see some basics of how the
AnkhSVN plugin is integrated, and how to handle an advanced scenario when integrating
common “library” projects into a larger solution.

Creating a Project/Solution in Visual Studio20

If you’re working in another IDE (like Eclipse) or another language (C#, VB.NET, Python, Java,
HTML/Javascript, etc) the overall process will be similar.

• Create a project/solution using your IDE of choice (or even simply a folder on your hard
drive)21.
• Create a project structure (or repository) in the source control “database” (i.e. in
VisualSVN Manager, or Git).
• Import the solution into the repository/project/trunk folder.
• Checkout the solution from the repository right back into the project/solution folder you
imported from.

Thanks to the AnkhSVN plugin for Visual Studio, we can do all of this right inside the IDE. Let’s
see what this looks like for an Autocad plugin created in Visual Studio.

1. In Visual Studio, click File > New > Project.

2. Select Templates > Visual C# > Class Library.
3. Enter MyPlugin as the name.
4. Verify that Create directory for solution is checked, then click OK.

20 To create an Autocad plugin, you will need to have the ObjectARX SDK downloaded to your computer.
You can find this at http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=785550. You’ll need to
choose the correct version for your version of Autocad.
21 You can start coding, but I prefer to get my solutions under source control as soon as possible, usually

immediately after creating them in the IDE.

Page 18
 FIGURE 21 NEW PROJECT

5. Once the project is created, go to Solution Explorer, and navigate to MyPlugin >
References.
6. Right-click References and choose Add Reference.
7. Click Browse and locate the ObjectARX folder. Mine’s located at C:\ObjectARX 2016\inc.
Your location may vary depending on which version and where you elected to install it.
8. Select AcCoreMgd.dll, AcDbMgd.dll, and AcMgd.dll, then click Add, then click OK.
9. In the References node, select all three of references you just added, then right-click and
choose Properties.
10. Change Copy Local to False.

Page 19
 FIGURE 22 SETTING AUTOCAD DLL’S COPY LOCAL PROPERTY TO FALSE

11. Return to Solution Explorer tab.

12. Right-click MyPlugin and choose Properties.
13. On the Debug tab, select Start external program.
14. Click the … button and browse to the location of acad.exe on your computer. Mine’s at
C:\Program Files\Autodesk\Autocad 2017\acad.exe.

FIGURE 23 DEBUG SETTINGS FOR AUTOCAD PLUGIN

15. Close the Properties tab.

Page 20
This is the basic setup required for an Autocad plugin. Let’s use the AnkhSVN plugin22 to get
this solution into source control23.

1. In Solution Explorer, right-click the Solution node and choose Add solution to
Subversion.
2. Select or enter the Repository Url of your repository (mine is https://vm-win10-
ben/svn/AU2017.
3. Select the repository in the tree view (mine is svn/AU2017).
4. Check Add trunk folder for Project.

FIGURE 24 ADDING A VISUAL STUDIO SOLUTION TO SUBVERSION WITH ANKHSVN

5. Click OK.
6. Enter a log message, then click OK.

22 See Appendix C for guidance on installing the AnkhSVN plugin.

23 You could also continue to use TortoiseSVN. IDE specific plugins are nice because they’re integrated
right into the programming environment. But if you can’t find a plugin (VLIDE), or simply want to use
TortoiseSVN, you can. In practice I use a mixture of both.

Page 21
Status icons in Solution Explorer show Subversion status of each file/folder in the project.

FIGURE 25 ANKHSVN STATUS ICONS IN SOLUTION EXPLORER

Let’s add some code to our project that actually does something: writes “Hello World” to the
command prompt, and draws a circle. As this isn’t a class on coding, I’m not going to spend
time explaining it. Copy and paste the code below into your Class1.cs file, replacing the entire
contents of the file.

using Autodesk.AutoCAD.ApplicationServices.Core;
using Autodesk.AutoCAD.DatabaseServices;
using Autodesk.AutoCAD.EditorInput;
using Autodesk.AutoCAD.Runtime;
using System;
using System.Linq;

namespace MyPlugin
{
public class Class1
{
[CommandMethod("Hello", CommandFlags.Modal)]
public void HelloWorld()
{
var ed = Application.DocumentManager.MdiActiveDocument.Editor;
ed.WriteMessage("\nHello world");

var opts = new PromptPointOptions("\nSelect center point:");

var result = ed.GetPoint(opts);
if (result.Status != PromptStatus.OK)
return;
var cenPt = result.Value;

var distOpts = new PromptDistanceOptions("\nEnter or select radius:")

{
UseBasePoint = true,
BasePoint = cenPt
};
var radResult = ed.GetDistance(distOpts);
if (radResult.Status != PromptStatus.OK)
return;
var radius = radResult.Value;

var db = Application.DocumentManager.MdiActiveDocument.Database;
using (var tran = db.TransactionManager.StartTransaction())
{
var bt = (BlockTable)tran.GetObject(db.BlockTableId, OpenMode.ForRead);
var ms =
(BlockTableRecord)tran.GetObject(bt[BlockTableRecord.ModelSpace], OpenMode.ForWrite);

Page 22
 using (var circle = new Circle())
{
circle.Center = cenPt;
circle.Radius = radius;

ms.AppendEntity(circle);
tran.AddNewlyCreatedDBObject(circle, true);
}

tran.Commit();
}
}
}
}

Let’s go ahead and commit the changes (all new files) to the repository. We’ll use the Pending
Changes tab for this.

7. In the Pending Changes tab, click Update24.

8. Enter a Message in the box provided, then click Commit.

FIGURE 26 THE PENDING CHANGES TAB - PART OF ANKHSVN

The Pending Changes list clears, and the status icons in Solution Explorer change to check
marks. IDE specific plugins like this are very handy, and keep you right in your regular workflow.
We won’t repeat using similar commands we’ve already covered with the TortoiseSVN plugin,
many are available simply by right-clicking a file in Solution Explorer, as shown below.

24 Just in case someone else has committed changes to the project!

Page 23
 FIGURE 27 INTEGRATED SUBVERSION COMMANDS - PART OF ANKHSVN

One of the nice things about the AnkhSVN plugin (other plugins have similar functionality) is that
changes are automatically detected in your solution, and files that need to be added, deleted or
moved in the repository are largely handled automatically. You mostly need to take care of
updates and commits.

To update your solution, right-click the solution node in Solution Explorer and choose Update
Solution to Latest Version. To commit changes, you can use the Pending Changes tab, which
we saw earlier, or right-click the solution node in Solution Explorer and choose Commit
Solution Changes.

Be sure that your changes to the MyPlugin project are committed before continuing to the next
section.

Learn how to create and merge branches while maintaining working code
One of the more complex things you can do using source control is branching (forking in git
terminology) your code. This allows for development of features in your code that may take a
while to work out. Meanwhile, the main “trunk” of your code is still available for making minor
maintenance fixes. Once the branch development is complete, Subversion helps you merge the
trunk and branch changes back together.

In this section, we’re going to create a branch of our Visual Studio solution, then add another
project to it. While we’re at it, I want to show you an advanced feature of Subversion, called

Page 24
“externals,” which allows you to link other independent projects in the repository with the
project/solution you’re developing. This is extremely helpful if you like to create “toolboxes” of
functionality which you can reuse in multiple projects.
Adding a “toolbox” project to the repository
We need to switch gears momentarily in order to add a “toolbox” project to the repository. This
represents some functionality that you wish to share among other projects, which is maintained
in its own, distinct project in the repository.

In your class downloads, unzip the file SharedProject.zip to your desktop. This is a Visual
Studio solution that creates a DLL we can use in Autocad.

1. In VisualSVN Server, create a new project structure named SharedProject in your

repository.
2. Use TortoiseSVN to import the SharedProject folder from your desktop to the
/SharedProject/trunk folder in the repository25.

With this bit of housekeeping out of the way, we can proceed to branch MyPlugin.
Branching a project using AnkhSVN
Before proceeding, verify that all changes in the MyPlugin solution are committed. The Pending
Changes tab should be clear.

1. In Solution Explorer, right-click the Solution node and choose Subversion > Branch
solution26.
2. Verify the Folder and From Url. These should default to the right locations.
3. Verify that the Version is set to Head/Latest Version.
4. Add a name to the end of the To Url. I named my branch “01_AddingExternalProject27”.
Note that you’re automatically defaulted to the /branches sub-folder.
5. Add a log message.
6. Be sure and check the Switch to Branch after creation. This switches your working copy
to the new branch once it’s created.

25 You do not need to checkout SharedProject at this time. In fact, you can actually delete it from the
Desktop altogether once you’ve verified that it successfully imported into the repository. We’ll see it again
soon enough.
26 You can also do this with TortoiseSVN by right-clicking the working copy project folder then choosing

TortoiseSVN > Branch/Tag. The specific steps and screens are different in TortoiseSVN, but the end
result is the same.
27 I don’t know of any particular convention for naming branches, I just like the idea of adding a numerical

sequence to the branch name, although Subversion keeps track of the order branches were added to the
repository. But typical naming conventions for repository folders still applies.

Page 25
 FIGURE 28 CREATING A BRANCH/TAG

7. Click OK. If you keep an eye on the Pending Changes tab, you’ll notice the address box
updates to the new branch folder name.
Adding an “external” project
1. In Solution Explorer, right-click the solution node and choose Subversion > Solution
Properties.
2. Click the Add… button.
3. Under Property Name, select svn:externals.

FIGURE 29 ADDING AN EXTERNAL PROJECT

4. Click the button next to Url as shown above.

5. Under Url, select the Url of your repository, then expand to
SharedProject\trunk\SharedProject28.
6. Select that folder and click OK.

28The SharedProject solution has a project also named SharedProject within it. When imported into the
repository, the .sln file (among others) resides in the /trunk folder. We need to provide the folder where
the .csproj file resides within the solution.

Page 26
7. In the Name column, enter SharedProject.

FIGURE 30 ENTERING EXTERNALS INFORMATION

8. Click OK to return to the SVN Properties window.

FIGURE 31 EXTERNAL PROJECT CONFIGURED

9. Click OK again.
At this point, it doesn’t look like much has happened. We need to update the working copy in
order to copy the external projects into the solution folder.
10. On the Pending Changes tab, click Update.
Again it doesn’t appear that much has changed, unless you look in the solution folder in
Windows Explorer. There, you’ll see that the SharedProject folder has appeared. We now need
to add the project to the MyPlugin solution so we can start using it.
11. In Studio Explorer, right-click the solution node, then choose Add > Existing Project.
12. Navigate to the MyPlugin solution folder, where you should see the SharedProject folder.
13. Double-click the SharedProject folder and choose SharedProject.csproj, then click Open.
14. The project appears in Solution Explorer.
Just one more step and we can begin using our “toolbox” from MyPlugin. We need to add a
reference from the MyPlugin project to the SharedProject project.
15. Right-click the MyPlugin > References node and choose Add Reference.

Page 27
16. Click Projects on the left, then check the box next to SharedProject, then click OK.

FIGURE 32 ADDING A REFERENCE TO SHAREDPROJECT

Using shared code libraries

SharedProject adds some useful static methods that allow us to simplify accessing The Editor,
Document and Database objects in Autocad, as well as simplify using transactions. This code is
taken from Scott McFarlane’s AU2015 class, entitled “SD12077: Being a Remarkable C# .NET
AutoCAD Developer” which I highly recommend you take a look at. Unfortunately we can’t dig
into the details, but let’s modify Class1 to make use of these handy tools.
NOTE: After you add SharedProject to the solution, it will probably fail to build
because the references to the three AutoCAD plugins can’t find the ObjectARX
folder. Expand the SharedProject > References node and remove the Ac*
references. Then add them back in as explained previously in the “Creating a
Project/Solution in Visual Studio” section.
1. Open the MyPlugin > Class1.cs file in Visual Studio, and replace the entire contents with
the code below:
using Autodesk.AutoCAD.ApplicationServices.Core;
using Autodesk.AutoCAD.DatabaseServices;
using Autodesk.AutoCAD.EditorInput;
using Autodesk.AutoCAD.Runtime;
using SharedProject;
using System;
using System.Linq;

namespace MyPlugin
{
public class Class1
{
[CommandMethod("Hello", CommandFlags.Modal)]
public void HelloWorld()
{
var ed = Active.Editor;
ed.WriteMessage("\nHello world");

var opts = new PromptPointOptions("\nSelect center point:");

var result = ed.GetPoint(opts);
if (result.Status != PromptStatus.OK)
return;
var cenPt = result.Value;

var distOpts = new PromptDistanceOptions("\nEnter or select radius:")

{
UseBasePoint = true,

Page 28
 BasePoint = cenPt
};
var radResult = ed.GetDistance(distOpts);
if (radResult.Status != PromptStatus.OK)
return;
var radius = radResult.Value;

Active.UsingModelSpace((tran, ms) =>

{
using (var circle = new Circle())
{
circle.Center = cenPt;
circle.Radius = radius;

ms.AppendEntity(circle);
tran.AddNewlyCreatedDBObject(circle, true);
}
});
}
}
}

This new version calls the static Active.UsingModelSpace method which reduces the
complexity of starting a transaction and getting hold of the model space block table record quite
a bit, and is a nice reusable bit of code we can use anywhere we want to draw or edit objects in
modelspace.
2. If Visual Studio indicates an error on the Active.UsingModelSpace line, right-click on the
MyPlugin node in Solution Explorer and choose Build.
3. From the Pending Changes tab, update, then commit your changes.
It’s possible that you will see a message like the one below:

FIGURE 33 COMMIT FROM MULTIPLE WORKING COPIES

Because MyPlugin and SharedProject are different projects within the repository, and we’ve
made changes to both, AnkhSVN needs to commit them in separate steps. Just check both
boxes under Working Copy and click OK.

Page 29
This ends our modification to the branch. Once we’ve tested our changes, the last thing
remaining is to merge our branch back into the trunk.
Merging a branch into the trunk

NOTE:Before proceeding with the next steps, be absolutely sure that the branch
working copy has been updated and all changes are committed in the repository.

Prior to merging the branch, we need to switch our working copy from the branch back to the
trunk.

1. On the Pending Changes tab, click the Switch Solution button , located to the right of
the repository Url.
2. Click the … button to browse the repository, then choose the /trunk folder and click OK.

FIGURE 34 SWITCHING THE WORKING COPY TO THE TRUNK

3. Click OK. In Solution Explorer you’ll notice that the SharedProject has disappeared, and
Class1.cs has reverted back to the earlier version.
4. On the Pending Changes tab, click the arrow next to Update, and choose Merge Solution.

FIGURE 35 MERGE SOLUTION

Page 30
5. Select Reintegrate a branch29 and click Next.
6. Click the … button next to Merge from to browse the repository.
7. Select the \branches\01_AddingExternalProject30 folder.

FIGURE 36 SELECTING THE BRANCH TO MERGE

8. Click OK, then Next.

9. Allow the default conflict options in the next step, then click Next.
10. Review the settings in the Merge Summary, and if you’re ready to proceed, click Finish.
11. Click OK.
12. Because the .sln and .csproj files have been changed, Visual Studio prompts you to reload.
Choose Reload All.
13. You may need to build your solution at this point, so select MyPlugin in Solution Explorer
and press F6.
14. If everything builds, add a message in the Pending Changes tab, then click Commit.
Unversioning (ignoring) build folders
In a Visual Studio solution, compiled .dll (or .exe) files go into the bin and obj folders. There’s
little point in storing these folders in the repository as they take up a lot of space. Any developer
can simply checkout the latest version of the code and build the solution if they need a working
.dll or .exe. Let’s see how we can unversion these folders.

1. In Solution Explorer, right-click the Solution node, and choose Open folder in Windows
Explorer.
2. Navigate into the MyPlugin folder.
3. Right-click the bin folder and select TortoiseSVN > Unversion and add to ignore list >
bin.
4. Repeat these steps for the obj folder.

29 Note that AnkhSVN allows several types of merges, and provides a helpful diagram and description of
each type when you select each option.
30 Whatever your branch name is.

Page 31
5. Navigate into the SharedProject folder, and repeat steps 3 and 4 to unversion the bin and
obj folders for this project as well.
6. Right-click the MyPlugin solution folder, then choose SVN Commit.

-------------------
Need to repeat these steps and make sure I got them right.
-------------------
Summary
If you write code that is important to you (and your company), you need to be using source
control. There are a variety of tools available for most operating systems and IDEs that are
completely FREE, so there’s no reason for you to not get started right away.

In this class we used a line of free products based on the Subversion source control system.
However, there are many alternatives and you are encouraged to weigh the pros and cons of
each system for your organization.

Don’t put it off just because it sounds complicated. Hopefully you’ve seen through this class that
it’s easy to setup a repository, and easy to import your existing code into a repository. Once you
get into the habit of a) update before you code, b) update again before you commit (if you work
on a team), and c) commit your changes, your programming life gets a lot easier. Merging code
contributions from multiple developers is nearly automatic. Conflicts will be relatively rare. And
you will find many benefits to having the ability to look back at any part of your project at any
stage of its development.

If you have any questions about this course, please feel free to contact me, Ben Rand, at
[email protected].

Resources
Github: https://github.com/pricing
Subversion: https://subversion.apache.org
VisualSVN Server (free Subversion server): http://www.visualsvn.com
AnkhSVN (free plugin for VS): https://ankhsvn.open.collab.net/
TortoiseSVN (free Windows Shell plugin): https://tortoisesvn.net/
Subversive (free Eclipse plugin): https://eclipse.org/subversive/downloads.php
Pluralsight course on how Git works (Subversion is roughly similar):
https://www.pluralsight.com/courses/how-git-works
Notepad++: https://notepad-plus-plus.org/
ObjectARX: http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=785550

Page 32
Appendix A: Installing VisualSVN Server
In this appendix, I’ve provided screenshots of the installation of VisualSVN Server, with
additional comments where you need to consider the options.

Page 33
If you want Enterprise Edition features (Active Directory sign-on), the cost is $950 per server.
But the Standard Edition is truly free, and does everything a small development group needs.

Page 34
This is the main step to pay attention to. You need to identify the Repositories directory and the
Backups directory. These should be somewhere on a server or network drive that is backed up
with a normal “server” backup process.

Page 35
After the installation, you’ll want to start the Server Manager to configure a few things, which are
covered in the main handout.

Page 36
Appendix B: Installing TortoiseSVN
In this appendix, I’ve provided screenshots of the installation of TortoiseSVN, with additional
comments where you need to consider the options.

You have to scroll (err, read…) to the end of the license agreement.

Page 37
If you love typing commands at the command prompt, you may want to install the command line
client tools option.

Page 38
After installing TortoiseSVN, you should probably restart your system, even though the installer
doesn’t tell you to. This seems to be necessary to get the status icons showing up properly for
working copies.

It’s important to note that TortoiseSVN isn’t a standard application that you run. It’s a Windows
shell extension. To use it, just right-click anywhere on your desktop, or in Windows Explorer,
and you’ll see a set of right-click options.

NOTE: Before connecting to Repo browser for the first time, you should have setup a repository
and one (or more) users in VisualSVN Manager. These steps are covered in the main handout.

If you right-click and choose TortoiseSVN > Repo browser, you may be prompted for a
repository URL. This will typically be https://servername/svn/repositoryname.

Page 39
You will probably need to login to the repository, using proper credentials already setup using
VisualSVN Manager.

Page 40
Appendix C: Installing AnhkSVN Plugin for Visual Studio
In this appendix, I’ve provided screenshots of the installation of AnkhSVN, with additional
comments where you need to consider the options. AnkhSVN automatically detects which
version(s) of Visual Studio you have installed, and installs wherever appropriate.

NOTE: I’m not sure if Visual Studio Community Edition (free) supports the AnkhSVN plugin. It
may only work for the Professional or higher (paid) editions. If it doesn’t work, you can fall back
to using TortoiseSVN.

Open up Visual Studio, then go to Tools > Options > Source Control and change the current
source control plug-in to AnkhSVN – Subversion Support for Visual Studio.

Page 41
You can turn on the Source Control – Subversion toolbar, and go to Views > Other Windows
and turn on the Pending Changes, and Subversion Info windows. Most of the time, you’ll
access the functionality by right-clicking in the Solution Explorer window, where you’ll find
many Subversion commands.

Page 42