This project is read-only.

Managing Your Development Environment

Topics: Installing Orchard
Oct 17, 2012 at 6:27 PM

Pardon the newbonics, but I'm confused about how to setup my own development environment using the Mercurial source code and VS2010.  In past projects, I would just zip up my files and move from work to home and take everything with me.  If I'm tethered to a Mercurial installation of the Orchard source code at work I'm not sure how to take my work home.  Curious how other folks handle this.



Oct 17, 2012 at 6:34 PM

Don't see why it would be different. Are you facing a specific problem when you try it?

Oct 17, 2012 at 6:38 PM

Thanks for the quick response, I guess I may have over-reacted a bit here.  At one point WinRar was taking forever to rar up the project.  It's faster when I do it just now.  So to confirm, I'll maintain the Mercurial installation with the source code on my work machine and just move my folder to my home machine and load it up there.  When I bring my files back and unzip to my work directory, won't I knock my clone fully out of sync, or am I again over-thinking things a bit...

Oct 17, 2012 at 6:40 PM

Well, another, immensely cleaner thing you can do is leverage DVCS and have your own private Mercurial repository (BitBucket hosts those for free) and sync on both ends with that.

Oct 17, 2012 at 6:46 PM

That sounds like a great approach.  Thanks!  Any advice on where to go to learn best practices there?  Thanks again Bertrand!

Oct 17, 2012 at 6:48 PM

About Mercurial you mean? On the Mercurial web site I suppose.

Oct 17, 2012 at 6:49 PM

Great.  I'm on my way.  :T

Oct 18, 2012 at 3:28 PM

Sorry to make an encore here.  I've figured out how to create my own Mercurial repository and host it on BitBucket but can't get my head around how to also "pull" updates from the Orchard Codeplex source repository.  I've created a repository on BitBucket and cloned it on my local PCs at the office and at home.  How do I also stay updated from

Thanks again!


Oct 18, 2012 at 5:47 PM

If you use TortoiseHg, you can have more than one path defined in the Synchronize screen. You can have one that is your private, to which you push, and one that is CodePlex, from which you pull general updates. That's what I do on my own projects and it works great, especially since we got rid of subrepositories.

Oct 18, 2012 at 5:54 PM

Thanks for the response Bertrand.  Though this is 101 stuff for sure, I bet there are a ton of people who will benefit having this spelled out.  Have a great day! Toby

Nov 6, 2012 at 8:33 PM

Still getting off to a bumpy start.

I cloned the project and then ran it in Visual Studio.  This creates the "App_Data" folder.  Sadly using Mercurial I can't for the life of me get App_Data added to my local repository.  It simply can't find the folder at all.

I've tried:

hg add

hg addremove

hg status

etc... and no sign of that folder being added.  Can some kind soul explain what my major malfunction is here?



Nov 6, 2012 at 8:38 PM

You are looking to add App_Data to the repository? Not sure if that's a good idea, but if you must:

That folder is being ignored as per the .hgignore file (for good reasons, as you normally wouldn't want to commit logs, dependencies and databases).

If you remove the following line:


And refresh the changes in the Workbench you should be able to commit App_Data.

Nov 6, 2012 at 9:46 PM

Great, thanks!  I'm trying to add it so I can move my entire project (with SQL CE database) from office to home by pushing to a BitBucket repository (as Bertrand suggested).  When I'd get home and pull the code my site wouldn't be there as App_Data (including Orchard.sdf) had been left behind.  If you'd like to suggest an alternative approach I'd appreciate it.  Regardless this did it - thanks so much for the quick response!

Nov 6, 2012 at 10:05 PM

No problem :)

For sharing the database I have used this approach before, and it works fine.

However, I prefer to maintain a custom recipe that will recreate the entire site. This has the benefit of being able to blow away the database which may become messy during development, while at the same time I don't have to manually recreate content and configure the site. this approach adds a little overhead, but it has been worth my while.

Nov 6, 2012 at 11:56 PM

Yes, the database under source control is not a good idea because you can't diff or merge.

I would suggest exporting the contents instead, and checking that in: this way you get something that can be merged and diffed and that is also easy to restore.

Nov 9, 2012 at 4:25 PM

I guess the solution for me is to use a standalone SQL Server and manually copy the App_Data directory on to whatever machine is working on the project at the outset.  This assumes that App_Data is stable and unchanging though.  Is that a fair assumption?  Thanks again!

Nov 9, 2012 at 4:57 PM

I second and third sfmskywalker's and bertrand's recommendation. I also use recipes along with a batch file that rebuilds the database from scratch and imports the content by running the recipes. Content changes are made in the recipes, or via migrations.cs, which are handled nicely by source control. 

Nov 9, 2012 at 7:01 PM

Sadly, this may be over my head a bit.  If you could point me towards any documentation or tutorials I'd really appreciate.  Thanks again for your help guys.  I look forward to paying this info back to the community someday...