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.
Where do we start?
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:
Some interesting options here
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.
What Iâve found
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:
- cd workspace/
- mkdir Juggler
- cd Juggler
- ../rcs-fast-export.rb -A ../AuthorsFile /mnt/c/RCS/c/stress/Juggler > Juggler.gx
- git init
- git fast-import < Juggler.gx
No commands â weâve imported and are ready to sync up to the VSTS server.
Commands (copied from the âAdd Codeâ window):
But thatâs not quite allâŠ
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:
- I donât want to overwrite or delete the working workspace Iâve been working in until the new workspace works. So I still have the old directory to work from if I need to, while Iâm moving to the new place.
- I want to make sure that a developer (even if itâs just me six months from now, after Iâve wiped everything in a freak electromagnet accident) can connect to this version control source, and build everything.
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:
- md workspace/Juggler
- cd workspace/Juggler
- git clone https://<yourdomain>.visualstudio.com/DefaultCollection/_git/Juggler .
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.
And youâre done
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!