Wednesday, April 27, 2011
Enter Git SVN. Git SVN allows you to use a local git repository with a remote subversion server. This means that you can initialize git and commit like crazy, and then when you are ready to share your changes with the rest of your team, you synchronize them with the Subversion server.
This is not without its pitfalls – they are two very different version control systems, so if you are doing complex things with them, you may run into some troubles. However where I work we have small teams, and many of my projects are done solely by me, so Git SVN works out great for us, as the main reason for pushing the code to the Subversion server is so that it’s backed up and easily retrieved in the future.
I’ve run into a few issues at times with setting this up, so I thought that I’d create a quick guide for how I am now doing it on new projects.
First of all, I create my subversion repository in VisualSVN.
I like to setup the standard SVN directory structure, and Git SVN can accommodate this.
I then open a git bash at the parent folder of where my project will go (or where it currently is – this still works if you’ve already created your solution/folders, as long as they are named the same, or you move the files).
run the command ‘git svn clone –s URL’ where URL is the path to your subversion server. I’ve found that this must be in all lowercase. The –s tag specifies that you are using the standard SVN directory structure – emit this if you didn’t create it when you setup your repository.
This command will then check out your subversion repository into a directory of the same name as the repository – it will either create this, or use an existing one if it has the same name.
Next, make sure your .gitignore file is setup in the directory and then cd into it with ‘cd REPOSITORY_NAME’. Git status will show you the current files ready to be checked in.
Then you should be able to do your first git commit
Now your local git repository is up to date – so you are doing version control, and you can go along like this checking in regularly, then when it’s time to send the commits to the server, use ‘git svn dcommit’
Then you are all up to date! You can also use ‘git svn fetch’ to to a svn update from the server if others on your team have committed.
Wednesday, April 20, 2011
To get this to work, I just had to run caspol.exe on each machine to make their machines trust that certain location, for example:
However in upgrading the add-ins to Revit 2012, this method did not work. The add-ins simply would not load, and in the journal file I was seeing this error:
This was when my assemblies were compiled in .NET 4 and the same error occurred after I recompiled them in .NET 3.5. I had a feeling that it might have something to do with the changes in security that were introduced with .NET 4, but the fact that it happened to .NET 3.5 dll’s as well was odd.
Turns out there’s a fix for it, which is a little bit of a pain, your user needs to update their revit.exe.config file in the Revit program directory (C:\Program Files\Autodesk\Revit Structure 2012\Program) and make the following change:
look for the <runtime> tag, and just after it’s opening, put:
The add-ins should then run correctly. This is however a bit of a pain, I’ll have to incorporate this into an installation tool. I’d love to hear of a better solution to this problem if anyone knows of one, however for now, this will work around it.
Thanks to this post for helping to point me in the right direction.
Tuesday, April 19, 2011
If you’ve made the jump to Revit 2012, you may have noticed that there is a new directory structure in the program files dir.
There is no longer a journals folder. So where has it gone? The answer is that It appears to have been moved to the AppData directory.
C:\Users\USERNAME\AppData\Local\Autodesk\Revit\Autodesk Revit Structure 2012\Journals
Replace the uername with your username, and also enter the correct Revit vertical you are using.
For those of you that don’t know, Fluent NHibernate is a great project for anyone that uses NHibernate in their .NET development. Instead of creating Hibernate XML files for your mappings (yuck), you can use a strongly typed, 'fluent’ syntax in C# code. An example mapping for a class would look something like:
I recently converted some mapping files of my own over from hibernate XML to Fluent NHibernate and came across one gotcha worth mentioning. In my project, I had some Enums as properties. Say for example EmploySection enum might have EmploySection.Administration, EmploySection.Structural, EmploySection.Civil as options. My database had these mapped as integers previously, and NHibernate would take this mapping and cast the enum as an integer and save it to the database.
By default, Fluent NHIbernate does this differently, it uses a string to save the enum value to the database. This caused some issues as I had existing data which needed to read these fields, so I wanted to tell NHibernate how to do this.
The solution is to add ‘.CustomType(typeof(int))’ to the end of your mapping, for example:
Sunday, April 17, 2011
If you are new to version control, basically it involves you ‘checking in’ your code at various points of development. This keeps a version history of your project, so if you delete some code, and then later on decide you want it back, you can easily rollback changes, or check out an old version. Additionally, you can setup a version control server, which you check your code into, which effectively then serves as a backup for your code in case your main development computer dies. Subversion is a great example of a popular version control system with great support in Windows. TortoiseSVN, AnkhSVN and Visual SVN Server are a great, free way to get setup with Subversion on Windows and Visual Studio if you decide that Git isn’t for you.
If you are already familiar with Subversion, you should be aware that Git works a little differently. First of all, Git keeps a full copy of the repository on your local computer, so you can continue checking in frequently even when you cannot access the remote server. The workflow in Git involves you committing regularly to your local Git repository, and then when you are ready to share your changes with the rest of your team you ‘push’ them to a remote server. This allows Git users to commit far more frequently than Subversion users as they don’t have to worry about sending half finished changes to the rest of the team. Additionally, you can have multiple ‘remotes’ that you push your code to, allowing a ‘distributed’ architecture. Git also does things differently to Subversion when it comes to branching. While branching was nothing short of a nightmare in Subversion, Git has a great branching system that allows you to merge changes together with less conflicts for you to manually sort out.
For more information on using Git, check out the Git website’s documentation section. I personally read the book ‘Pro Git’ on my Kindle when learning the system, and found it probably goes into more depth than you need in day to day use, but if you want to get a good understanding of how it all works, it’s a good place to start.
So, how do I get started using this on Windows?
There are two ways to get started. First of all, if you are a command line fiend, you can simply head over to the Git Website and download the Windows installer, this will give you access to the ‘git bash’ that lets you use all the git commands to manage your code.
Alternatively, if you prefer the option of a graphical user interface (as well as a fallback to the command line) you should check out Git Extensions. Git extensions is a great project that provides Windows Explorer and Visual Studio integration for Git. It’s not perfect, but it’s probably the best GUI for Git on Windows at the moment (there is a TortoiseGIT project as well if that’s your preference).
Download the installer, and run through it. I choose to install MsysGit and KDiff, but otherwise just leave everything as the defaults.
when the Git setup wizard comes up, it’s a good idea to tick the option for ‘Git bash here’ windows explorer integration.
Once this is done, you’ll notice you can then right click on folders and see the various Git Extensions shortcuts
or alternatively you can click the ‘Git Bash Here’ option and see the command line.
But first, you’ll have to head into the ‘Settings’ section of Git Extensions and setup a username and email address
Then you are all configured, if you open visual studio and create or open a project, you should see a ‘Git’ dropdown menu at the top of the screen. From here you can initialize a new repository
After this you are ready to do your first commit, you can do that from the ‘Commit’ option. You’ll then see the commit screen:
You may notice a large amount of junk/temp files that you don’t want to commit into your version control, you can remove these by creating a .gitignore file in your project directory. GitExtensions has a preconfigured file of these you can use. Go to working dir changes, edit ignored files and click ‘add default ignores’
You should then see your files list shrink somewhat. You can now ‘stage’ your files (which is a git terminology, it lets you choose which files you are going to commit at any point, though many people simply stage and commit all at once) , enter a commit message and then commit them.
Then you will have just made your first revision! These revisions are internally stored in the .git folder in your projects base, so you could copy and paste your project folder around, store it in Dropbox, zip it up and email it – all while keeping this all in tact.
As you can see, Git Extensions is quite useful for the general Git workflow, and is a good way to get introduced to the Git world. I personally prefer the command line most of the time, but having Git in my Visual Studio is very handy. For more information on how to use Git Extensions, check out this manual.
Finally, now that you know how to get Git running as a local repository, I recommend you take a look at arguably the best feature of Git – Github.com. Github.com is an online repository hosting service that has gained huge popularity, and today drives people to take a look at Git, even if it is just to make use of their services. If you are happy for your project to be open source, Github gives you free hosting, if not, you can pay a small fee a month to get some repositories. Their servers are rock solid, and their web interface is wonderful. You should definately check it out.
Much of the code that I create for this blog is available on my Github profile.
I hope that this article has given you enough of an introduction to Git to encourage you to do some more reading on it. If you aren’t using any version control for all of your projects, no matter how small, please, start doing so – you’ll thank yourself later!