More in this section

Forums / Developing with Sitefinity / Sitefinity & Source Control

Sitefinity & Source Control

7 posts, 2 answered
  1. Pierre
    Pierre avatar
    12 posts
    Registered:
    03 Jun 2008
    03 Sep 2009
    Link to this post
    Hi there,

    We have been using Sitefinity for a while now on a few different projects and just want to commend you on a great product!

     We are rethinking our approach to using source control with it, currently we commit the whole project into source control and then everyone updates and commits their project as such. I.e. if say we get a developer new on the project and he has to start working on it, we get him to checkout the project in full out of source control and then he just creates a new website in IIS and links to the Sitefinity project that he has checked out of source control and he is good to go and start developing etc.

    We were wondering what the best practices were with regards to source control. Should we rather just commit files such as the master pages, styles, code etc. and leave the Sitefinity folder inside the project out of our actual source control and have everyone create their own version of the project initially and then just update/commit the custom master pages, styles, code etc. we change/add?

    Any input would be appreciated! We use TortoiseSVN for our source control tasks.

    Thanks,
    Pierre.
  2. Adam @Habanero
    Adam @Habanero avatar
    45 posts
    Registered:
    22 Jun 2012
    04 Sep 2009
    Link to this post
    We do exactly what you are doing as well.  The entire sitefinity blank project lives in source control as well as all our custome code.

    As the time often comes where we have to customize some files in the sitefinity folder, we want to make sure we capture those changes and that they are under source control and versioned.

    I think best practices would be to have every single file that is needed to reproduce a functioning copy of the website in source, that way someone who needs it simply pulls down the source, builds and they are up and running.
    Answered
  3. Radoslav Georgiev
    Radoslav Georgiev avatar
    3370 posts
    Registered:
    01 Feb 2016
    07 Sep 2009
    Link to this post
    Hello Adam and Pierre,

    Thank you for using our services.

    I have to agree with Adam's point. Loading the whole blank project in the source control will give you easier access to any customizations, or new controls that your developers are working on. Leaving the Sitefinity folder out of the source control might prevent your developers from getting the latest versions of control templates for example, then you might have troubles running the project due to the differences in versions.

    Consider also the situation when you upgrade your Sitefinity version. Then for sure if you exclude the bin folder and the Sitefinity folder you will end up with assembly version differences, or you will not be able to run projects locally due to new functionality introduced in the controls.

    So to sum it. Your current approach to using source control is probably the most convenient, and in my opinion you should stick with it.

    If you have more questions, please feel free to contact us.

    All the best,
    Radoslav Georgiev
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
    Answered
  4. Pierre
    Pierre avatar
    12 posts
    Registered:
    03 Jun 2008
    08 Sep 2009
    Link to this post
    Hi there Adam & Radoslav,

    Thank you very much for your input regarding my query I have shared this with my colleagues and superior. We will continue then with our current method.

    Thanks again,
    Have a great day,
    Pierre.
  5. olav
    olav avatar
    76 posts
    Registered:
    22 Jan 2007
    15 Sep 2009
    Link to this post
    Hi all,

    Yes, we have been running with the Sitefinity folder added to source control as well, Visual Studio 2008 - integrated mode. We're quite new to Sitefinity, but we did look close at the options when making our own "best practices" for the project soruce control and Sitefinity upgrade cycle.

    I just have a few minor comments/questions, for assurance during Sitefinity upgrades late at night, when trying to overwrite, merge and leave alone the correct amount of files...
    Sorry, I might be a bit off topic here, driving at both upgrades and versioning.

    I guess/hope merge jobs are rare, I just want to be prepared.
    For example, I modified the files files SearchBox.ascx and searchCommonLayout.css in the folder ~/Sitefinity/ControlTemplates/Search/. At the same time I assume that most controls will be altered a bit during upgrades, and files need to be modified to accommodate additional functionality.

    We can cope with a few merge jobs now and then, but I would really appreciate a simple way of checking which files might need a merge. For instance, the two mentioned files were not not altered from v3.7 to 3.7SP1. But I had to check (using WinMerge) as these files in the 3.7SP1 patch archive were had more recent date than the v3.7 patch.

    Could incremental patches be an idea? Anyway, a list of changed files would be great, covering files int he Sitefinity folder and similar locations that potentially could be modified by the developer.

    Moving on, we considered input from the post Installing Sitefinity as a Web Application in Visual Studio.
    We have avoided the WebSite project types all the way (meaning this is a bit unfamiliar), but still we decided to stick with the current Sitefinity upgrade path as I read somewhere that you might consider a WebApp version somewhere from Sitefinity 4.0.

    So, we need to cope with WebSite projects unable to exclude files using the integrated source control connector. The bin folder is fortunately left alone from source control, but everything else seems to get absorbed. The exclude from project option would rename files and is useless in this context as far as I can see. We just have to remember to check out certain files before doing certain operations using the Sitefinity browser based site management at the development computer:
    - Adding pages, if an index is set to update automatically (writes to files in ~/App_Data/Search/ )
    - Uploading controls, (would write to web.config). But we had to take that one manually anyway.

    Anybody know of more project file writing operations that we should be aware of?

    Comments are very much appreciated! Thanks!
  6. Adam @Habanero
    Adam @Habanero avatar
    45 posts
    Registered:
    22 Jun 2012
    16 Sep 2009
    Link to this post
    I agree that a list of changed files AND web.config changes (not just a new web.config) would be very helpful.

    Having said that, we typically checkout the entire web project and copy the new files in.  Do a diff on the web.config and update. 

    We never store customizations to sitefinity in the sitefinity folder, it is always in another folder so that we don't lose them if they are overwritten.  If these customizations need to live in the SF folder, we use a post build command to xcopy them over to where they belong. 
  7. Georgi
    Georgi avatar
    3583 posts
    Registered:
    28 Oct 2016
    17 Sep 2009
    Link to this post
    Hi,

    Thank you for the feedback on the changed files. We are considering such feature for the 4.0 - the automatic template export tool will be able to check the templates versions/changes. 

    As for the source control, you would better exclude the whole App_Data directory. There is Wikis.xml file, in which we store the Wikis (using xml provider rather than sql provider). In the App_Data directory we store some temporary images from the Polls module as well.

    Best wishes,
    Georgi
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Register for webinar
7 posts, 2 answered