Orchard Hungary is an archive

This site is now an archive. We'll keep it so the content is accessible, but we won't update it anymore. However, we frequently publish Orchard-related news on our other site Orchard Dojo, so be sure to check that out instead. And if you're interested in news about our Orchard development company, Lombiq, check out our website.

Ways of source controlling an Orchard solution

Tags: source control, version control, Orchard, team development

When working in a team you naturally need source control but it's strongly advised even if you develop individually. So how to do this when working with Orchard? There are a few good options.

  • Downloading the source and copying it to your own repository: probably the most simple solution. Its advantage is that it's simple and the repository will only contain your commits. Downside is more complicated upgrading: when there's a new Orchard release you have to update your source by hand (e.g. by removing everything and adding the new source). 
  • Forking the main Orchard repository: by having a private fork of the main Orchard repo and keeping your own changes in a separate branch you can very easily pull in changes and update your source. Not to mention it will feel like Sebastien is on your team :-). However the repository will contain all commits from the main repo too, mixed with yours and also you won't be able to use the default branch. Naturally this also means that you have to use the same source control system as the main repo, currently Mercurial.

Keeping the Orchard source version controlled is one question but there is another one: how to version control your own modules and themes? Again, there are basically two options:

  • Keeping your module/themes projects in your main repository: this is simple but it also means that every commit needed for a module/theme is a commit in the main repo.
  • Having subrepos for your modules/themes: with this setup you can keep your main repo just to accumulate changes from all subrepos, i.e. a commit in the main repo can correspond to multiple commits in a subrepo (or even in multiple subrepos). You'll need this kind of setup for extensions that you want to publish individually or that are from a 3rd party (as these will have their own repositories e.g. on GitHub). On the other hand pushing and pulling gets slower with each subrepository: if the team members push frequently this can get quite a pain.

As a bonus here are two long tested ignore files that you can use with Mercurial (as .hgignores files). For module subrepositories:

syntax: glob
obj/
bin/
*.user

Beware that this advertises the practice of not keeping dependencies in the bin folder!

And for the main repo if you opt with copying the Orchard source to your repo:

syntax: glob
desktop.ini
obj/
*.suo
*.sln.cache
*.orig
*.user
*Thumbs.db
build
buildazure
buildtasks
artifacts
src/Orchard.Web/Media/
robots.txt
syntax: regexp
(?i)src/.*bin/.*
src/Orchard.Web/App_Data(?!.*/Localization).+

This will include localization files from App_Data, but nothing else. If you use SQL CE as a database and want to include the database and settings files included in source control, just go to the respective files and right click -> TortoiseHg -> Add Files (if you're using TortoiseHg).

Update: the Orchard Dojo Library contains continuously updated versions of these files, see the "Development environment advices" page.

No Comments