Iâ€™ve posted before how Iâ€™d like to get my source code out of the version control system I used to use, because it was no longer supported by the manufacturer, and into something else.
I chose git, in large part because it uses an open format, and as such isnâ€™t going to suffer the same problem I had with ComponentSoftwareâ€™s CS-RCS.
Now that Iâ€™ve figured out how to use Bash on Ubuntu on Windows to convert from CS-RCS to git, using the rcs-fast-export.rb script, Iâ€™m also looking to protect my source control investment by storing it somewhere off-site.
This has a couple of good benefits â€“ one is that Iâ€™ll have access to it when Iâ€™m away from my home machine, another is that Iâ€™ll be able to handle catastrophic outages, and a third is that Iâ€™ll be able to share more easily with co-conspirators.
Iâ€™m going to use Visual Studio Team Services (VSTS), formerly known as Visual Studio Online, previous to that, as Team Foundation Services Online. You can install VSTS on your own server, or you can use the online tool at <yourdomain>.visualstudio.com. If your team is smaller than five people, you can do this for free, just like you can use Visual Studio 2015 Community Edition for free. This is a great way in which Microsoft supports hobbyist developers, open source projects, college students, etc.
After my last post on the topic, you have used git and rcs-fast-export.rb to create a Git repository.
You may even have done a â€śgit checkoutâ€ť command to get the source code into a place where you can work on it. Thatâ€™s not necessary for our synchronisation to VSTS, because weâ€™re going to sync the entire repository. This will work whether you are using the Bash shell or the regular Command Prompt, as long as you have git installed and in your PATH.
If youâ€™ve actually made any changes, be sure to add and commit them to the local Git repository. We donâ€™t want to lose those!
Iâ€™m also going to assume you have a VSTS account. First, visit the home page.
Under â€śRecent Projects & Teamsâ€ť, click â€śNewâ€ť.
Give it a name and a description â€“ I suggest leaving the other settings at their default of â€śAgileâ€ť and â€śGitâ€ť unless you have reason to change. The setting of â€śGitâ€ť in particular is required if youâ€™re following along, because thatâ€™s how weâ€™re going to synchronise next.
When you click â€śCreate projectâ€ť, itâ€™ll think for a whileâ€¦
And then youâ€™ll have the ability to continue on. Not sure my teamâ€™s actually â€śgoing to love thisâ€ť, considering itâ€™s just me!
Yes, itâ€™s not just your eyes, the whole dialog moved down the screen, so you canâ€™t hover over the button waiting to hit it.
Click â€śNavigate to projectâ€ť, and youâ€™ll discover that thereâ€™s a lot waiting for you. Fortunately a quick popup gives you the two most likely choices youâ€™ll have for any new project.
As my team-mates will attest, I donâ€™t do Kanban very well, so weâ€™ll ignore that side of things, Iâ€™m mostly using this just to track my source code. So, hit â€śAdd Codeâ€ť, and you get this:
Donâ€™t choose any yet
â€śClone to your computerâ€ť â€“ an odd choice of the direction to use, since this is an empty source directory. But, since it has a â€śClone in Visual Studioâ€ť button, this may be an easy way to go if you already have a Visual Studio project working with Git that you want to tie into this. There is a problem with this, however, in that if youâ€™re working with multiple versions of Visual Studio, note that any attempt from VSTS to open Visual Studio will only open the most recently installed version of Visual Studio. I found no way to make Visual Studio 2013 automatically open from the web for Visual Studio 2013 projects, although the Visual Studio Version Selector will make the right choice if you double click the SLN file.
â€śPush an existing repository from command lineâ€ť â€“ this is what I used. A simple press of the â€śCopy to clipboardâ€ť button gives me the right commands to feed to my command shell. You should run these commands from somewhere in your workspace, I would suggest from the root of the workspace, so you can check to see that you have a .git folder to import before you run the commands.
BUT â€“ I would strongly recommend not dismissing this screen while you run these commands, you canâ€™t come back to it later, and youâ€™ll want to add a .gitignore file.
The other options are:
â€śImport a repositoryâ€ť â€“ this is if youâ€™re already hosting your git repository on some other web site (like Github, etc), and want to make a copy here. This isnâ€™t a place for uploading a fast-import file, sadly, or we could shortcut the git process locally. (Hey, Microsoft, you missed a trick!)
â€śInitialize with a README or gitignoreâ€ť â€“ a useful couple of things to do. A README.md file is associated with git projects, and instructs newcomers to the project about it â€“ how to build it, what itâ€™s for, where to find documentation, etc, etc â€“ and you can add this at any time. The .gitignore file tells git what file names and extensions to not bother with putting into. Object files, executables, temporary files, machine generated code, PCH & PDB files, etc, etc. You can see the list is long, and thereâ€™s no way to add a .gitignore file with a single button click after youâ€™ve left this page. You can steal one from an empty project, by simply copying it â€“ but the button press is easier.
Iâ€™ve found it useful to run the â€śgit remoteâ€ť and â€śgit pushâ€ť commands from the command-line (and I choose to run them from the Bash window, because Iâ€™m already there after running the RCS export), and then add the .gitignore. So, I copy the commands and send them to the shell window, before I press the â€śAdd a .gitignoreâ€ť button, choose â€śVisual Studioâ€ť as my gitignore type, and then select â€śInitializeâ€ť:
First, letâ€™s start with a recap of using the rcs-fast-export command to bring the code over from the old RCS to a new Git repository:
Commands in that window:
No commands â€“ weâ€™ve imported and are ready to sync up to the VSTS server.
Commands (copied from the â€śAdd Codeâ€ť window):
Your solution still has lines in it dictating what version control youâ€™re using. So you want to unbind that.
[If you donâ€™t unbind existing version control, you wonâ€™t be able to use the built-in version control features in Visual Studio, and youâ€™ll keep getting warnings from your old version control software. When you uninstall your old version control software, Visual Studio will refuse to load your projects. So, unbinding your old version control is really important!]
I like to do that in a different directory from the original, for two reasons:
So, now itâ€™s Command Prompt window timeâ€¦
Yes, you could do that from Visual Studio, but itâ€™s just as easy from the command line. Note that I didnâ€™t actually enter credentials here â€“ theyâ€™re cached by Windows.
Commands entered in that window:
Your version control system may complain when opening this project that itâ€™s not in the place it remembers being inâ€¦ I know mine does. Tell it thatâ€™s OK.
[Yes, Iâ€™ve changed projects, from Juggler to EFSExt. I suddenly realised that Juggler is for Visual Studio 2010, which is old, and not installed on this system.]
Now that weâ€™ve opened the solution in Visual Studio, itâ€™s time to unbind the old source control. This is done by visiting the File => Source Control => Change Source Control menu option:
Youâ€™ll get a dialog that lists every project in this solution. You need to select every project that has a check-mark in the â€śConnectedâ€ť column, and click the â€śUnbindâ€ť button.
Luckily, in this case, theyâ€™re already selected for me, and I just have to click â€śUnbindâ€ť:
You are warned:
Note that this unbinding happens in the local copy of the SLN and VCPROJ, etc files â€“ itâ€™s not actually going to make any changes to your version control. [But you made a backup anyway, because youâ€™re cautious, right?]
Click â€śUnbindâ€ť and the dialog changes:
Click OK, and weâ€™re nearly thereâ€¦
Finally, we have to sync this up to the Git server. And to do that, we have to change the Source Control option (which was set when we first loaded the project) to Git.
This is under Tools => Options => Source Control. Select the â€śMicrosoft Git Providerâ€ť (or in Visual Studio 2015, simply â€śGitâ€ť):
Press â€śOKâ€ť. Youâ€™ll be warned if your solution is still bound in some part to a previous version control system. This can happen in particular if you have a project which didnâ€™t load, but which is part of this solution. Iâ€™m not addressing here what you have to do for that, because it involves editing your project files by hand, or removing projects from the solution. You should decide for yourself which of those steps carries the least risk of losing something important. Remember that you still have your files and their history in at least THREE version control systems at this point â€“ your old version control, the VSTS system, and the local Git repository. So even if you screw this up, thereâ€™s little real risk.
Now that you have Git selected as your solution provider, youâ€™ll see that the â€śChangesâ€ť option is now available in the Team Explorer window:
Save all the files (but I donâ€™t have any open!) by pressing Ctrl-Shift-S, or selecting File => Save All.
If you skip this step, there will be no changes to commit, and you will be confused.
Select â€śChangesâ€ť, and youâ€™ll see that the SLN files and VCPROJ files have been changed. You can preview these changes, but they basically are to do with removing the old version control from the projects and solution.
It wants a commit message. This should be short and explanatory. I like â€śRemoved references to old version control from solutionâ€ť. Once youâ€™ve entered a commit message, the Commit button is available. Click it.
It now prompts you to Sync to the server.
So click the highlighted word, â€śSyncâ€ť, to see all the unsynced commits â€“ you should only have one at this point, but as you can imagine, if you make several commits before syncing, these can pile up.
Press the â€śSyncâ€ť button to send the commit up to the server. This is also how you should usually get changes others have made to the code on the server. Note that â€śothersâ€ť could simply mean â€śyou, from a different computer or repositoryâ€ť.
Check on the server that the history on the branch now mentions this commit, so that you know your syncing works well.
Sure, it seems like a long-winded process, but most of what Iâ€™ve included here is pictures of me doing stuff, and the stuff Iâ€™m doing is only done once, when you create the repository and populate it from another. Once itâ€™s in VSTS, I recommend building your solution, to make sure it still builds. Run whatever tests you have to make sure that you didnâ€™t break the build. Make sure that you still have valid history on all your files, especially binary files. If you donâ€™t have valid history on any files in particular, check the original version control, to see if you ever did have. I found that my old CS-RCS implementation was storing .bmp files as text, so the current version was always fine, but the history was corrupted. Thatâ€™s history I canâ€™t retrieve, even with the new source control.
Now, what about those temporary repositories? Git makes things really easy â€“ the Git repository is in a directory off the root of the workspace, called â€ś.gitâ€ť. Itâ€™s hidden, but if you want to delete the repository, just delete the â€ś.gitâ€ť folder and its contents. You can delete any temporary workspaces the same way, of course.
I did spend a little time automating the conversion of multiple repositories to Git, but that was rather ad-hoc and wobbly, so Iâ€™m not posting it here. Iâ€™d love to think that some of the rest of this could be automated, but I have only a few projects, so it was good to do by hand.
No programmer should be running an unsupported, unpatched, unupdated old version control system. Thatâ€™s risky, not just from a security perspective, but from the perspective that it may screw up your files, as you vary the sort of projects you build.
No programmer should be required to drop their history when moving to a new version control system. There is always a way to move your history. Maybe that way is to hire a grunt developer to fetch versions dated at random/significant dates throughout history out of the old version control system, and check them in to the new version control system. Maybe you can write automation around that. Or maybe youâ€™ll be lucky and find that someone else has already done the automation work for you.
Hopefully Iâ€™ve inspired you to take the plunge of moving to a new version control system, and youâ€™ve successfully managed to bring all your precious code history with you. By using Visual Studio Team Services, youâ€™ve also got a place to track features and bugs, and collaborate with other members of a development team, if thatâ€™s what you choose to do. Because youâ€™ve chosen Git, you can separate the code and history at any time from the issue tracking systems, should you choose to do so.
Let me know how (if?) it worked for you!