QESTonline - User contributions [en]

QEST Platform 4.5.2895

2017-12-18T23:00:42Z

David.lucas:

==QEST Platform 4.5.2895==
{|class="wikitable"
|- valign="top"
!Bug/CR ID
!Customer Code
!Customer Reference
!Product(s) Modified
!Name
!Release Notes

|- valign="top"
|style="background:white smoke;"|Bug#5760
|style="background:white smoke;"|AUCOF
|style="background:white smoke;"|Cof16.125
|style="background:white smoke;"|QESTLab
|style="background:white smoke;"|Hydrometer: Calculation corrections for AS/RMS tests
|style="background:white smoke;"|The following changes have been made to test screens Grading - Hydrometer [AS 1289.3.6.3] (ID 11021) and Grading - Hydrometer [RMS T190] (ID 11022)
* The Total Dry Mass of the hydrometer sub-sample will now be calculated according to formula 7(2) of the standard AS 1289.3.6.3
* New fields have been added to the Pretreatment tab to determine Mass of Dispersing Agent (g)
* A bug which caused the field Mass Before Pretreatment (g) to become unlocked has been fixed.
* The value of Mass After Pretreatment (g) will be adjusted using the Mass of Dispersing Agent (g) rather than the value of Dispersant Correction Ca.
* Mass After Pretreatment (g) will no longer overwrite the dry mass of the sub-sample after a split at the 2.36mm sieve
* The hydrometer reading/depth calibration will now be interpolated using a line of best fit of all calibrated points, rather than the two neighbouring point, when determining the value of correction factor F1
* Correction factor F2 will now be calculated rather than derived from a lookup table. This removes the restriction placed on the value of soil density.
* The calculation for Adj. Smaller than D (%) will now apply the soil density correction factor.
Additionally, a bug which caused the warning text to display incorrectly for some hydrometer tests has been fixed.
|- valign="top"
|style="background:white;"|Bug#6689
|style="background:white;"|AUGCC
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|CBR values are not updated correctly
|style="background:white;"|An issue where changing Seating Deflection or Seating Load would not update CBR values correctly has been fixed.
|- valign="top"
|style="background:white;"|Bug#6827
|style="background:white;"|AUPAR
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|CBR: Load Cell Reading Convertion
|style="background:white;"|For Q113 CBR test screens, users can now directly record the force readings from a load cell and QESTLab will converts the values into Newton based on the force unit set for the selected load cell equipment.
 
The following changes have been made as well:
- Drop-down boxes and edit boxes are now aligned in Force Indicator frame.
- A warning message will show up when users switching between different force indicators (proving ring and load cell) and any penetration results are entered.
|- valign="top"
|style="background:white smoke;"|Bug#6891
|style="background:white smoke;"|AUQMR
|style="background:white smoke;"|
|style="background:white smoke;"|QESTLab
|style="background:white smoke;"|CBR: Negative correction
|style="background:white smoke;"|Negative correction is no longer applied for CBR values on CBR test screens.
|- valign="top"
|style="background:white;"|Bug#6994
|style="background:white;"|INTERNAL
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|California Bearing Ratio - Import MDD result
|style="background:white;"|Pressing the Import button in the compaction section of the CBR screen now imports the MDD and OMC values from the specified sample instead of throwing a runtime error 91.

|}

QEST Platform 4.5.2895

2017-12-18T22:55:20Z

David.lucas:

==QEST Platform 4.5.2895==
{|class="wikitable"
|- valign="top"
!Bug/CR ID
!Customer Code
!Customer Reference
!Product(s) Modified
!Name
!Release Notes

|- valign="top"
|style="background:white smoke;"|Bug#5760
|style="background:white smoke;"|AUCOF
|style="background:white smoke;"|Cof16.125
|style="background:white smoke;"|QESTLab
|style="background:white smoke;"|Hydrometer: Calculation corrections for AS/RMS tests
|style="background:white smoke;"|The following changes have been made to test screens Grading - Hydrometer [AS 1289.3.6.3] (ID 11021) and Grading - Hydrometer [RMS T190] (ID 11022)
The Total Dry Mass of the hydrometer sub-sample will now be calculated according to formula 7(2) of the standard AS 1289.3.6.3
New fields have been added to the Pretreatment tab to determine Mass of Dispersing Agent (g)
A bug which caused the field Mass Before Pretreatment (g) to become unlocked has been fixed.
The value of Mass After Pretreatment (g) will be adjusted using the Mass of Dispersing Agent (g) rather than the value of Dispersant Correction Ca.
Mass After Pretreatment (g) will no longer overwrite the dry mass of the sub-sample after a split at the 2.36mm sieve
The hydrometer reading/depth calibration will now be interpolated using a line of best fit of all calibrated points, rather than the two neighbouring point, when determining the value of correction factor F1
Correction factor F2 will now be calculated rather than derived from a lookup table. This removes the restriction placed on the value of soil density.
The calculation for Adj. Smaller than D (%) will now apply the soil density correction factor.
 
Additionally, a bug which caused the warning text to display incorrectly for some hydrometer tests has been fixed.
|- valign="top"
|style="background:white;"|Bug#6689
|style="background:white;"|AUGCC
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|CBR values are not updated correctly
|style="background:white;"|An issue where changing Seating Deflection or Seating Load would not update CBR values correctly has been fixed.
|- valign="top"
|style="background:white;"|Bug#6827
|style="background:white;"|AUPAR
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|CBR: Load Cell Reading Convertion
|style="background:white;"|For Q113 CBR test screens, users can now directly record the force readings from a load cell and QESTLab will converts the values into Newton based on the force unit set for the selected load cell equipment.
 
The following changes have been made as well:
- Drop-down boxes and edit boxes are now aligned in Force Indicator frame.
- A warning message will show up when users switching between different force indicators (proving ring and load cell) and any penetration results are entered.
|- valign="top"
|style="background:white smoke;"|Bug#6891
|style="background:white smoke;"|AUQMR
|style="background:white smoke;"|
|style="background:white smoke;"|QESTLab
|style="background:white smoke;"|CBR: Negative correction
|style="background:white smoke;"|Negative correction is no longer applied for CBR values on CBR test screens.
|- valign="top"
|style="background:white;"|Bug#6994
|style="background:white;"|INTERNAL
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|California Bearing Ratio - Import MDD result
|style="background:white;"|Pressing the Import button in the compaction section of the CBR screen now imports the MDD and OMC values from the specified sample instead of throwing a runtime error 91.

|}

Template:QEST Platform 4.5.2895

2017-12-18T22:52:10Z

David.lucas:

==QEST Platform 4.5.2895==
{|class="wikitable"
|- valign="top"
!Bug/CR ID
!Customer Code
!Customer Reference
!Product(s) Modified
!Name
!Release Notes

|- valign="top"
|style="background:white smoke;"|Bug#5760
|style="background:white smoke;"|AUCOF
|style="background:white smoke;"|Cof16.125
|style="background:white smoke;"|QESTLab
|style="background:white smoke;"|Hydrometer: Calculation corrections for AS/RMS tests
|style="background:white smoke;"|The following changes have been made to test screens Grading - Hydrometer [AS 1289.3.6.3] (ID 11021) and Grading - Hydrometer [RMS T190] (ID 11022)
The Total Dry Mass of the hydrometer sub-sample will now be calculated according to formula 7(2) of the standard AS 1289.3.6.3
New fields have been added to the Pretreatment tab to determine Mass of Dispersing Agent (g)
A bug which caused the field Mass Before Pretreatment (g) to become unlocked has been fixed.
The value of Mass After Pretreatment (g) will be adjusted using the Mass of Dispersing Agent (g) rather than the value of Dispersant Correction Ca.
Mass After Pretreatment (g) will no longer overwrite the dry mass of the sub-sample after a split at the 2.36mm sieve
The hydrometer reading/depth calibration will now be interpolated using a line of best fit of all calibrated points, rather than the two neighbouring point, when determining the value of correction factor F1
Correction factor F2 will now be calculated rather than derived from a lookup table. This removes the restriction placed on the value of soil density.
The calculation for Adj. Smaller than D (%) will now apply the soil density correction factor.
 
Additionally, a bug which caused the warning text to display incorrectly for some hydrometer tests has been fixed.
|- valign="top"
|style="background:white;"|Bug#6689
|style="background:white;"|AUGCC
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|CBR values are not updated correctly
|style="background:white;"|An issue where changing Seating Deflection or Seating Load would not update CBR values correctly has been fixed.
|- valign="top"
|style="background:white;"|Bug#6827
|style="background:white;"|AUPAR
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|CBR: Load Cell Reading Convertion
|style="background:white;"|For Q113 CBR test screens, users can now directly record the force readings from a load cell and QESTLab will converts the values into Newton based on the force unit set for the selected load cell equipment.
 
The following changes have been made as well:
- Drop-down boxes and edit boxes are now aligned in Force Indicator frame.
- A warning message will show up when users switching between different force indicators (proving ring and load cell) and any penetration results are entered.
|- valign="top"
|style="background:white smoke;"|Bug#6891
|style="background:white smoke;"|AUQMR
|style="background:white smoke;"|
|style="background:white smoke;"|QESTLab
|style="background:white smoke;"|CBR: Negative correction
|style="background:white smoke;"|Negative correction is no longer applied for CBR values on CBR test screens.
|- valign="top"
|style="background:white;"|Bug#6994
|style="background:white;"|INTERNAL
|style="background:white;"|
|style="background:white;"|QESTLab
|style="background:white;"|California Bearing Ratio - Import MDD result
|style="background:white;"|Pressing the Import button in the compaction section of the CBR screen now imports the MDD and OMC values from the specified sample instead of throwing a runtime error 91.

|}

QESTNET Internal:Creating Build 4.0

2016-03-01T04:05:01Z

David.lucas:

==QESTNET 4.0 Release Build Process (Fugro)==
<ol>
<li>Checkout the release-4.0 branch from qestnet repository.</li>
<li>Ensure the branch is at the current origin head and all required commits for the build are present. This may mean a hotfix commit or a merge (--no-ff) branch dev4.0 into release-4.0.</li>
<li>Open the QESTNET.sln and QESTField.sln. Ensure the QESTNET.Custom.Fugro.DataBackbone and QESTNET.Integration.Portal projects are loaded.</li>
<li>Update the AssemblyVersion and AssemblyFileVersion of all AssemblyInfo.cs files with the new version number in both solutions.</li>
<li>Build debug & release QESTNET:</li>
<ol>
<li>Switch to debug.</li>
<li>Re-build the Schema Generator if required.</li>
<li>Upgrade the database you intend to build against, using the qestnet.upgrade tool built for this release. Run any required post-install scripts.</li>
<li>Build the qestlab.data project. See [http://online.spectraqest.com/index.php?title=qestnet_internal:developer_setup_qestnet#build_qestlab.data build qestlab.data].</li>
<li>Re-build QESTNET.sln.</li>
<li>Switch to release.</li>
<li>Re-build QESTNET.sln.</li>
</ol>
<li>Run '''~\QESTNET\copy_all_to_libraries.bat'''.</li>
<li>Create a new folder '''v4.0.XX''' in '''~\Libraries\QESTNET\''' where XX is the build version number. Copy the Debug and Release folders also in this folder, into the new '''v4.0.XX''' folder.</li>
<li>Update the build parameter in '''build-debug-x64.bat''' and '''build-release-x64.bat''' in '''~\QESTNET\QESTNET.Deployment\''' with the new build version number. E.g.,
<blockquote>C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe /t:Rebuild .\QESTNET.Deployment\QESTNET.Deployment.wixproj /p:Configuration=Release;QestnetVersion='''4.0.18'''
</blockquote></li>
<li>Run '''build-release-x64.bat'''.</li>
<li>Run '''package_release.bat'''. This will copy the installer to '''\\adls0003\Development\Product Distribution\QESTNET\'''. Move it to folder '''Fugro'''. This will make the release publicly available.</li>
<li>Switch the '''QESTField.sln''' to release. Publish the solution to a temporary folder.</li>
<li>Zip the contents of the temporary folder and name the zip '''QESTField v4.0.XX.zip''' where XX is the build version number.</li>
<li>Copy the zip file to '''\\adls0003\Development\Product Distribution\QEST Field\'''. This will make the release publicly available.</li>
<li>Commit the qestnet branch changes to git with commit message '''Prepare release v4.0.XX''' where XX is the build version number.</li>
<li>Tag the commit with '''v4.0.XX''' where XX is the build version number.</li>
<li>Push the commit to github.</li>
<li>Push the tag to github (tags need to be pushed explicitly).</li>
<li>Inform appropriate parties of the new release build.</li>
<li>Have a cider as this should be automated.</li>
</li>
</ol>

QESTNET Internal:Developer Home

2016-03-01T03:14:00Z

David.lucas:

This page acts as a home for QESTNET developers and aims to provide easy access to all relevant information and processes.

== For Managers ==
=== Installation / Usage Guides ===
[[Implementation:Main_Page|Should probably be linked off of this page eventually?]]

Documentation is not officially released yet. It is currently inside the QESTNET GitHub repository. Eventually it will be automatically built into the Product Distribution folder, so anyone can access it. For now these are GitHub links to the most recent version of each. If you don't have a GitHub account, copies can be found in "\\adls0003\Development\Product Distribution\QESTNET Documentation".

* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTField%204.1%20Installation%20Guide.docx QESTField 4.1 Installation Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTField%204.1%20Confiuration%20Guide.docx QESTField 4.1 Configuration Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTNET%204.1%20Installation%20Guide.docx QESTNET 4.1 Installation Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTNET%204.1%20Confiuration%20Guide.docx QESTNET 4.1 Configuration Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTField%20QESTNET%20Architecture%20%26%20System%20Requirements.pdf QESTField QESTNET Architecture and System Requirements]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTNET%204.1%20Console%20-%20Hanson%20Specific%20Draft.docx Using the QESTNET Console]
* [https://github.com/spectraqest/qestlab/raw/master/Documentation/QIntegrator%20Installation%20%26%20Configuration%20Guide.docx QIntegrator Plugin Installation and Configuration Guide]

== For Developers ==
=== Developer Setup Guide ===
* [[QESTNET_Internal:Developer_Setup_Requirements|Requirements]]
* [[QESTNET_Internal:Developer_Setup_Git|Git]]
* [[QESTNET_Internal:Developer_Resharper|Resharper]]
* [[QESTNET_Internal:Developer_Setup_QESTNET|QESTNET]]
* [[QESTNET_Internal:Developer_Setup_QESTField|QESTField]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Console|QESTNET Console]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Tester|QESTNET Tester]]

=== General Process Guides ===
* [[QESTNET_Internal:Developer_Git etiquette|Using Git]]
* [[Media:User Guide - ADLSV0010 - Dev DB Server.docx|Migrating and Using Databases on ADLSV0010]]
* [[QESTLab_Internal:SQL Script Guidelines|SQL Script Guidelines]]

=== Development Process Guides ===
* [[QESTNET_Internal:Developer_QESTNET_Changing_Branches Changing|QESTNET Branches]]
* [[QESTNET_Internal:Developer_QESTNET_Creating_A_New_Workflow|Creating A New Workflow]]

=== Builds ===
<UL><LI>[http://online.spectraqest.com/index.php?title=QESTNET_Internal:Creating_Build_4.0 Build QESTNET v4.0 (Fugro)]</LI></UL>
<UL><LI>[https://github.com/spectraqest/qestnet Build QESTNET v4.1]</LI></UL>

----

=== Coding Knowledge Base ===

==== Coding Guidelines ====
This section is intended to provide a set of guidelines that are helpful to people writing code in the QESTNET repository.
* [[QESTNET_Internal:Developer_Code_Comments|Code comments]]

==== QESTNET / QESTField Codebase ====
* [[QESTNET_Internal:QESTNET_Projects_Quick_Reference_Guide|QESTNET Projects Quick Reference Guide]]

==== QESTNET Integration ====
* [[QESTNET_Internal:Creating Integration Projects|Creating Integration Projects]]
* [[QESTNET_Internal:Integrator Project Structure|Integrator Project Structure]]
* [[QESTNET_Internal:Building_and_Installing_an_Integration_Project|Building and Installing an Integration Project]]
* [[QESTNET_Internal:QIntegrator Plugin|QESTLab Integration and the QIntegrator Plugin]]

==== Fugro Data Backbone ====
* [[QESTNET_Internal:Fugro_DBB_Service|Fugro Data Backbone Service]]
* [[QESTNET_Internal:Fugro DBB_TestMapping_Guide|Fugro Data Backbone Test Mapping Step-by-step Guide]]
* [[QESTNET_Internal:Fugro_DBB_Export_Test|Fugro Data Backbone Export Test]]

----

=== Troubleshooting ===

[[Category:Development|{{PAGENAME}}]]
[[Category:Guidelines|{{PAGENAME}}]]
[[Category:QESTNET_Internal|{{PAGENAME}}]]
[[Category:Internal|{{PAGENAME}}]]

QESTNET Internal:Developer Home

2016-03-01T03:12:51Z

David.lucas:

This page acts as a home for QESTNET developers and aims to provide easy access to all relevant information and processes.

== For Managers ==
=== Installation / Usage Guides ===
[[Implementation:Main_Page|Should probably be linked off of this page eventually?]]

Documentation is not officially released yet. It is currently inside the QESTNET GitHub repository. Eventually it will be automatically built into the Product Distribution folder, so anyone can access it. For now these are GitHub links to the most recent version of each. If you don't have a GitHub account, copies can be found in "\\adls0003\Development\Product Distribution\QESTNET Documentation".

* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTField%204.1%20Installation%20Guide.docx QESTField 4.1 Installation Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTField%204.1%20Confiuration%20Guide.docx QESTField 4.1 Configuration Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTNET%204.1%20Installation%20Guide.docx QESTNET 4.1 Installation Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTNET%204.1%20Confiuration%20Guide.docx QESTNET 4.1 Configuration Guide]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTField%20QESTNET%20Architecture%20%26%20System%20Requirements.pdf QESTField QESTNET Architecture and System Requirements]
* [https://github.com/spectraqest/qestnet/raw/alien/Documentation/QESTNET%204.1%20Console%20-%20Hanson%20Specific%20Draft.docx Using the QESTNET Console]
* [https://github.com/spectraqest/qestlab/raw/master/Documentation/QIntegrator%20Installation%20%26%20Configuration%20Guide.docx QIntegrator Plugin Installation and Configuration Guide]

== For Developers ==
=== Developer Setup Guide ===
* [[QESTNET_Internal:Developer_Setup_Requirements|Requirements]]
* [[QESTNET_Internal:Developer_Setup_Git|Git]]
* [[QESTNET_Internal:Developer_Resharper|Resharper]]
* [[QESTNET_Internal:Developer_Setup_QESTNET|QESTNET]]
* [[QESTNET_Internal:Developer_Setup_QESTField|QESTField]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Console|QESTNET Console]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Tester|QESTNET Tester]]

=== General Process Guides ===
* [[QESTNET_Internal:Developer_Git etiquette|Using Git]]
* [[Media:User Guide - ADLSV0010 - Dev DB Server.docx|Migrating and Using Databases on ADLSV0010]]
* [[QESTLab_Internal:SQL Script Guidelines|SQL Script Guidelines]]

=== Development Process Guides ===
* [[QESTNET_Internal:Developer_QESTNET_Changing_Branches Changing|QESTNET Branches]]
* [[QESTNET_Internal:Developer_QESTNET_Creating_A_New_Workflow|Creating A New Workflow]]

=== Builds ===
<UL><LI>[http://online.spectraqest.com/index.php?title=QESTNET_Internal:Creating_Build_4.0 Build QESTNET v4.0 (Fugro)]</LI></UL>
<UL><LI>[https://github.com/spectraqest/qestnet Build QESTNET v4.1]</LI></UL>

=== Coding Knowledge Base ===

==== Coding Guidelines ====
This section is intended to provide a set of guidelines that are helpful to people writing code in the QESTNET repository.
* [[QESTNET_Internal:Developer_Code_Comments|Code comments]]

==== QESTNET / QESTField Codebase ====
* [[QESTNET_Internal:QESTNET_Projects_Quick_Reference_Guide|QESTNET Projects Quick Reference Guide]]

==== QESTNET Integration ====
* [[QESTNET_Internal:Creating Integration Projects|Creating Integration Projects]]
* [[QESTNET_Internal:Integrator Project Structure|Integrator Project Structure]]
* [[QESTNET_Internal:Building_and_Installing_an_Integration_Project|Building and Installing an Integration Project]]
* [[QESTNET_Internal:QIntegrator Plugin|QESTLab Integration and the QIntegrator Plugin]]

==== Fugro Data Backbone ====
* [[QESTNET_Internal:Fugro_DBB_Service|Fugro Data Backbone Service]]
* [[QESTNET_Internal:Fugro DBB_TestMapping_Guide|Fugro Data Backbone Test Mapping Step-by-step Guide]]
* [[QESTNET_Internal:Fugro_DBB_Export_Test|Fugro Data Backbone Export Test]]

----

=== Troubleshooting ===

[[Category:Development|{{PAGENAME}}]]
[[Category:Guidelines|{{PAGENAME}}]]
[[Category:QESTNET_Internal|{{PAGENAME}}]]
[[Category:Internal|{{PAGENAME}}]]

QESTNET.Upgrade Internal:Creating Build 1.0

2016-01-29T00:54:30Z

David.lucas:

==QESTNET.Upgrade 1.0 Release Build Process (Fugro 4.0)==
<ol>
<li>Checkout the approriate branch for the build from qestnet.upgrade repository. E.g. fugro-dbb.</li>
<li>Ensure the branch is at the current origin head and all required commits for the build are present.</li>
<li>Update the build parameter in '''package_development.bat''' and '''package_release.bat''' in the root directory with the new build version number. E.g.,
<blockquote>C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe build.proj /t:SetVersion;RebuildAll /p:Configuration=Development;MajorVersion=1;MinorVersion=0;Build='''205'''
</blockquote></li>
<li>Run '''package_release.bat'''.</li>
<li>Copy '''QESTNET.Upgrade.dll''', '''QESTNET.Upgrade.UI.exe''' and '''QESTNET.Upgrade.UI.exe.Config''' in '''~\QESTNET.Upgrade\bin\Release\''' to a temporary folder for zipping.</li>
<li>Copy the folder (and contents) '''Scripts''' in the root directory to this temporary folder.</li>
<li>Update the '''QESTNET.Upgrade.UI.exe.Config''' file to the below xml.

<blockquote><pre>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
<appSettings>
<add key="manifestPath" value="./Scripts/database_upgrade.qn.manifest" />
</appSettings>
<connectionStrings>

</connectionStrings>
</configuration>
</pre></blockquote>
</li>
<li>Zip the contents of the temporary folder and name the zip '''QESTNET.Upgrade v1.0.XXX.zip''' where XXX is the build version number.</li>
<li>Copy the zip file to '''\\adls0003\Development\Product Distribution\QESTNET.Upgrade\'''. This will make the release publicly available.</li>
<li>Commit the qestnet.upgrade branch changes to git with commit message 'Prepare release v1.0.XXX' where XXX is the build version number. The AssemblyVersion classes, database_upgrade.qn.manifest and package batch files would have changed.</li>
<li>Tag the commit with 'v1.0.XXX' where XXX is the build version number.</li>
<li>Push the commit to github.</li>
<li>Push the tag to github (tags need to be pushed explicitly).</li>
<li>Inform appropriate parties of the new release build.</li>
<li>Have a non-alcoholic beverage as this was too easy.</li>
</li>
</ol>

QESTNET.Upgrade Internal:Creating Build 1.0

2016-01-29T00:51:23Z

David.lucas:

==QESTNET.Upgrade 1.0 Release Build Process (Fugro 4.0)==
<ol>
<li>Checkout the approriate branch for the build from qestnet.ugprade repository. E.g. fugro-dbb.</li>
<li>Update the build parameter in '''package_development.bat''' and '''package_release.bat''' in the root directory with the new build version number. E.g.,
<blockquote>C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe build.proj /t:SetVersion;RebuildAll /p:Configuration=Development;MajorVersion=1;MinorVersion=0;Build='''205'''
</blockquote></li>
<li>Run '''package_release.bat'''.</li>
<li>Copy '''QESTNET.Upgrade.dll''', '''QESTNET.Upgrade.UI.exe''' and '''QESTNET.Upgrade.UI.exe.Config''' in '''~\QESTNET.Upgrade\bin\Release\''' to a temporary folder for zipping.</li>
<li>Copy the folder (and contents) '''Scripts''' in the root directory to this temporary folder.</li>
<li>Update the '''QESTNET.Upgrade.UI.exe.Config''' file to the below xml.

<blockquote><pre>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
<appSettings>
<add key="manifestPath" value="./Scripts/database_upgrade.qn.manifest" />
</appSettings>
<connectionStrings>

</connectionStrings>
</configuration>
</pre></blockquote>
</li>
<li>Zip the contents of the temporary folder and name the zip '''QESTNET.Upgrade v1.0.XXX.zip''' where XXX is the build version number.</li>
<li>Copy the zip file to '''\\adls0003\Development\Product Distribution\QESTNET.Upgrade\'''. This will make the release publicly available.</li>
<li>Commit the qestnet.upgrade branch changes to git with commit message 'Prepare release v1.0.XXX' where XXX is the build version number. The AssemblyVersion classes, database_upgrade.qn.manifest and package batch files would have changed.</li>
<li>Tag the commit with 'v1.0.XXX' where XXX is the build version number.</li>
<li>Push the commit to github.</li>
<li>Push the tag to github (tags need to be pushed explicitly).</li>
<li>Inform appropriate parties of the new release build.</li>
<li>Have a non-alcoholic beverage as this was too easy.</li>
</li>
</ol>

QESTNET.Upgrade Internal:Creating Build 1.0

2016-01-29T00:43:00Z

David.lucas:

==QESTNET.Upgrade 1.0 Release Build Process (Fugro 4.0)==
#Checkout the approriate branch for the build from qestnet.ugprade repository. E.g. fugro-dbb.
#Update the build parameter in package_development.bat and package_release.bat in the root directory with the new build version number. E.g.,
#: C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe build.proj /t:SetVersion;RebuildAll /p:Configuration=Development;MajorVersion=1;MinorVersion=0;Build='''205'''
#Run package_release.bat.
#Copy QESTNET.Upgrade.dll, QESTNET.Upgrade.UI.exe and QESTNET.Upgrade.UI.exe.Config in ~\QESTNET.Upgrade\bin\Release\ to a temporary folder for zipping.
#Copy the Scripts folder in the root directory to this temporary folder.
#Update the QESTNET.Upgrade.UI.exe.Config file to the below xml.
<pre>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
<appSettings>
<add key="manifestPath" value="./Scripts/database_upgrade.qn.manifest" />
</appSettings>
<connectionStrings>

</connectionStrings>
</configuration>
</pre>
#Zip the contents of the temporary folder and name the zip QESTNET.Upgrade v1.0.XXX.zip where XXX is the build version number.
#Copy the zip file to \\adls0003\Development\Product Distribution\QESTNET.Upgrade\. This will make the release publicly available.
#Commit the qestnet.upgrade branch changes to git with commit message 'Prepare release v1.0.XXX' where XXX is the build version number. The AssemblyVersion classes, database_upgrade.qn.manifest and package batch files would have changed.
#Tag the commit with 'v1.0.XXX' where XXX is the build version number.
#Push the commit to github.
#Push the tag to github (tags need to be pushed explicitly).
#Inform appropriate parties of the new release build.
#Have a non-alcoholic beverage as this was too easy.

QESTNET Internal:Developer Setup QESTNET

2015-11-17T00:14:11Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
Complete the following steps within GitHub to fetch the QESTNET repository:
*Change the directory to your root GitHub folder (eg. cd /c/dev)
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Change the directory to the new qestnet folder (cd qestnet/)
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files.

=====Unhandled Login Fault Exception=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Go to '''Debug > Exceptions'''
**Find '''System.ServiceModel.FaultException`1'''
**Uncheck '''User-unhandled'''. This will stop the debugger breaking on a fault exception catch every time you login. It is on a "to do" list somewhere to fix... really I (DL) promise.

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTNET.Sessions.Lab\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the project QESTNET.Service\QESTNET.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to. ''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />'' 
*Open '''~\qestnet\QESTNET\QESTNET.Service\QESTNET\app.config'''
*Open '''~\qestnet\QESTNET\QESTNET.Service\QESTNET.Sessions\app.config'''
*Open '''~\qestnet\QESTNET\QESTNET.Custom\QESTNET.Custom.Fugro.DataBackbone.Tests\app.config'''
*Open '''~\qestnet\QESTNET\QESTNET.Sessions.Lab\Tester\app.config'''
**Check or change the storage location. ''<add key="fileStorePath" value="C:\NEEDSTOEXIST" />'' 
*Open the program '''Windows PowerShell ISE''' with Administrator rights.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*In Visual Studio, right-click the '''GenerateDataSchema.ps1''' file under QESTNET.Sessions.Lab\QESTLab.Data\Entities and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell Executable (C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell_ise.exe)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio. Run this file.

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
** Right-click file name and select to exclude it from the menu. [[Image:QESTNet_Build_Fugro_Exclude.png]]
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''. If you cannot see this file, click the "Show All Files" button on the Solution Explorer toolbar.
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project.

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.
**Errors in QESTNET.Custom are usually due to projects related to other customer's databases being compiled. Right click any Custom projects unrelated to the current customer's database you are connected to and select "Unload Project".
=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
**The batch file assumes naively that InstallUtil.exe is installed at "C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe". If it is not, you will need to change the batch file to suit your local machine. Do not commit these changes.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account ("sqaus\''your.name''") or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Unload non-Fugro projects
**Highlight all non-Fugro Projects under '''QESTNET.Custom''', right-click and '''Unload Projects''' [[Image:QESTNet_Build_Fugro_UnloadNonFugroProjects.png]]
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup QESTNET Tester

2015-07-20T05:12:26Z

David.lucas:

===QESTNET Tester===
The Tester project is a simple console application which allows you to directly call any code in QESTNET without using the QESTNET service. This can be useful for target testing, performance testing or bugs which are hard to track down through the QESTNET service.
*Open '''~\qestnet\QESTNET\ QESTNET_with_tests.sln'''
*Set '''Tester''' as the Startup Project
* Open the App.Config file in the Tester project. Edit the connectionString to point to the desired QESTLab database.
*Start Debugging ('''F5''')

QESTNET Internal:Developer Setup QESTField

2015-07-20T03:51:59Z

David.lucas:

===QESTField===
*Open '''~\qestnet\QESTField MVC\QESTField.sln'''
** If the solution does not load, check that .NET Framework 4.5 and ASP.NET MVC 4 are installed on your local machine. Use the Visual Studio 2012 CD to repair the installation.
*Build the solution. There should not be any errors
*Go to '''Debug > Exceptions'''
**Find '''System.ServiceModel.FaultException`1'''
**Uncheck '''User-unhandled'''. This will stop the debugger breaking on a fault exception catch every time you login. It is on a "to do" list somewhere to fix... really I (DL) promise.
*Start Debugging ('''F5'''). This will launch a web browser. The choice of web browser is configured in Visual Studio where Start Debugging is. Google Chrome is the recommended choice for QESTField development. The browser will take you to the web address of a local ASP.NET Development Server which Visual Studio has spun up. The login page of QESTField should be displayed. You can login using any QESTLab login credentials which are available in the database and have permission to use QESTField.
**Error: "Underlying service failed to Open." - Check the Event Viewer log. It is normally due to the QESTNET service credentials not having permission to access the QESTLab database.

QESTNET Internal:Developer Setup QESTField

2015-07-20T03:27:26Z

David.lucas:

===QESTField===
*Open '''~\qestnet\QESTField MVC\QESTField.sln'''
** If the solution does not load, check that .NET Framework 4.5 and ASP.NET MVC 4 are installed on your local machine.
*Build the solution. There should not be any errors
*Go to '''Debug > Exceptions'''
**Find '''System.ServiceModel.FaultException`1'''
**Uncheck '''User-unhandled'''. This will stop the debugger breaking on a fault exception catch every time you login. It is on a "to do" list somewhere to fix... really I (DL) promise.
*Start Debugging ('''F5'''). This will launch a web browser. The choice of web browser is configured in Visual Studio where Start Debugging is. Google Chrome is the recommended choice for QESTField development. The browser will take you to the web address of a local ASP.NET Development Server which Visual Studio has spun up. The login page of QESTField should be displayed. You can login using any QESTLab login credentials which are available in the database and have permission to use QESTField.
**Error: "Underlying service failed to Open." - Check the Event Viewer log. It is normally due to the QESTNET service credentials not having permission to access the QESTLab database.

QESTNET Internal:Developer Setup QESTField

2015-07-20T03:15:15Z

David.lucas:

===QESTField===
*Open '''~\qestnet\QESTField MVC\QESTField.sln'''
** If the solution does not load, check that .NET Framework 4.5 and ASP.NET MVC 4 are installed on your local machine.
*Build the solution. There should not be any errors
*Go to '''Debug > Exceptions'''
**Find '''System.ServiceModel.FaultException`1'''
**Uncheck '''User-unhandled'''. This will stop the debugger breaking on a fault exception catch every time you login. It is on a "to do" list somewhere to fix... really I (DL) promise.
*Start Debugging ('''F5'''). This will launch a web browser. The choice of web browser is configured in Visual Studio where Start Debugging is. Google Chrome is the recommended choice for QESTField development. The browser will take you to the web address of a local ASP.NET Development Server which Visual Studio has spun up. The login page of QESTField should be displayed. You can login using any QESTLab login credentials which are available in the database and have permission to use QESTField.

QESTNET Internal:Developer Setup QESTNET

2015-07-20T02:27:05Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files.

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project.

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.
**Errors in QESTNET.Custom are usually due to projects related to other customer's databases being compiled. Right click any Custom projects unrelated to the current customer's database you are connected to and select "Unload Project".
=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
**The batch file assumes naively that InstallUtil.exe is installed at "C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe". If it is not, you will need to change the batch file to suit your local machine. Do not commit these changes.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup QESTNET

2015-07-20T02:26:17Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files.

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project.

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.
**Errors in QESTNET.Custom are usually due to projects related to other customer's databases being loaded. Right click any Custom projects unrelated to the current customer's database you are connected to and select "Unload Project".
=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
**The batch file assumes naively that InstallUtil.exe is installed at "C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe". If it is not, you will need to change the batch file to suit your local machine. Do not commit these changes.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup QESTNET

2015-07-20T02:11:27Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files.

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project.

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.

=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
**The batch file assumes naively that InstallUtil.exe is installed at "C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe". If it is not, you will need to change the batch file to suit your local machine. Do not commit these changes.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup QESTNET

2015-07-20T01:58:34Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files.

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project.

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.

=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup Requirements

2015-07-20T01:53:40Z

David.lucas:

*Install Visual Studio 2012 (or higher);
**This may take up to an hour to install depending on the initial state of your local machine.
**Opening ~\qestnet\QESTField MVC\QESTField.sln is normally a good guide to determine if Visual Studio installed correctly. The git setup guide and a clone of the qestnet repository will need to be completed before this solution is available on your local machine.
*Install ReSharper 9.1.1;

QESTNET Internal:Developer Setup QESTNET

2015-07-20T01:36:44Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files.

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project.

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.

=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\bin\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup QESTNET

2015-07-20T01:35:58Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files
 

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.
 

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project
 

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.
 

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are only errors which start "The command mkdir and end with "NET START QESTNET exited with code 2.", continue on to the next step. Any other errors will need to be fixed before continuing.

=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\bin\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 
*Check that the service is running. If the service is not running check the Event Viewer logs to determine why.

=====Rebuild QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Setup Requirements

2015-07-17T02:45:04Z

David.lucas:

*Install Visual Studio 2012 (or higher);
**Opening ~\qestnet\QESTField MVC\QESTField.sln is normally a good guide to determine if Visual Studio installed correctly. The git setup guide and a clone of the qestnet repository will need to be completed before this solution is available on your local machine.
*Install ReSharper 9.1.1;

QESTNET Internal:Developer Setup Git

2015-07-17T02:38:48Z

David.lucas:

== Initial Setup ==
*Signup for a GitHub account www.github.com. Tell someone your username so they can add you to the appropriate SpectraQEST teams. For QESTNET you will need access to the qestnet repository.
*Download and install Git from http://git-scm.com/download. Windows has two possible ways to run git: choose msysgit instead of Cygwin. When installing, choose all the options that they recommend for Windows development. Install again to something like “C:\Program Files (x86)\Git”.
**You will be prompted about line ending conversions at some point. Use the auto-convert option, I think it’s the first option. It should produce the line “autocrlf = true” in the default config: “C:\Program Files (x86)\Git\etc\gitconfig”.
*You can now:
**Run the Git console using Git Bash, a shortcut (quotes included): "C:\Program Files (x86)\Git\bin\sh.exe" --login –i
**Run Git GUI using this entire command (quotes included) in a shortcut: "C:\Program Files (x86)\Git\bin\wish.exe" "C:\Program Files (x86)\Git\libexec\git-core\git-gui"
**A shortcut for both of these should have been created in the Start Menu automatically.
*Your global Git configuration file “.gitconfig” is found under “C:\Users\Your.Name\.gitconfig”. Setup your username and email by using the following commands in Git Bash:
**git config --global user.name “Your name”
**git config --global user.email your.name@spectraqest.com
*Download and install KDiff3 (this will be used as the merge tool for changes that can’t be automatically merged. Can maybe make it work with WinMerge, but haven’t tried.) This can be installed to the default location, something like “C:\Program Files (x86)\KDiff3”.
*Setup Git to use KDiff3 and optionally Notepad++ as your editor instead of Vim by editing the global .gitconfig file. I find it easier to edit manually in Notepad++ than using the console. Here’s an example of a config file:
<nowiki>[core]
editor = "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession -noPlugin"
autocrlf = true
[user]
name = John Meegan
email = john.meegan@spectraqest.com
[merge]
tool = kdiff3
[mergetool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe
[diff]
tool = kdiff3
[difftool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe</nowiki>
*Set up your public key: http://github.com/guides/providing-your-ssh-key . Note that the ~ directory in Git Bash corresponds to “C:\Users\Your.Name\”, so your SSH public key can be found in “C:\users\Your.Name\.ssh\id_rsa.pub” after you’ve generated it.
**By this point you will have a GitHub account and password, a private and public SSH key, and a password to access your private SSH key. This last password is just in case someone steals your computer, they cannot access your private key without a password. This prevents them from accessing anything you use your key for, such as GitHub, once you have added your public SSH key to GitHub.
*Make the folder “C:\dev\” on your C Drive for development work.
*Get a Git repository from GitHub via something like the following (note the URL comes from GitHub and changes depending on the project):
**cd /c/dev/
**git clone git@github.com:spectraqest/qestnet.upgrade.git
*That’s pretty much it. There are plenty of tools you can try out to assist with using Git if you wish. Two of the most popular are:
**GitHub for Windows: https://windows.github.com
**Atlassian SourceTree: http://www.sourcetreeapp.com/

QESTNET Internal:Developer Resharper

2015-07-17T02:32:45Z

David.lucas:

==Resharper==
===What is it?===
A third party extension for Visual Studio by JetBrains which is designed to make Visual Studio a better IDE and you more productive.
===Documention===
Go to https://www.jetbrains.com/resharper/help/Introduction__Index.html for Resharper Help.
===Options===
In Visual Studio open the menu item Resharper and select Options. Here is where all of Resharper's extensions can be turned on or off.
====Initial option setup====
*Code Inspection -> Inspection Severity -> XAML -> Set “Unresolved binding path when DataContext is known” to “Error”. That will mean you get a full error if any of the bindings to entity properties in the XAML are not valid.
These are useful to reduce warning spam:
*Code Inspection -> Inspection Severity -> All -> Constraints Violations -> Namespace does not correspond to file location -> Set to "Do not show".
*Code Editing -> C# -> Code Style -> Instance members qualification -> Use “this.” Qualifier for -> set to Field, Property, Event, Method. QN has liberal use of “this” and you’ll get warnings about them being unnecessary otherwise.
*Code Editing -> C# -> Naming Style -> Instance fields (private) -> Remove the underscore from the start of “lowerCamelCase”. Again we don’t use these in QN so it will give warning about them.
===Solution Wide Analysis===
Once you have opened a solution in Visual Studio. Right click on the circle in the bottom right hand corner of Visual Studio. Select "Start Solution Wide Analysis". This will turn on Resharper for this solution. It will be constantly running in the background. Any errors or warnings will be highlighted in the code like normal but can be accessed as well via the circle.

QESTNET Internal:Developer Home

2015-07-17T02:15:03Z

David.lucas:

This page acts as a home for QESTNET developers and aims to provide easy access to all relevant information and processes.

== For Developers ==
=== Developer Setup Guide ===
* [[QESTNET_Internal:Developer_Setup_Requirements|Requirements]]
* [[QESTNET_Internal:Developer_Setup_Git|Git]]
* [[QESTNET_Internal:Developer_Setup_QESTNET|QESTNET]]
* [[QESTNET_Internal:Developer_Setup_QESTField|QESTField]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Console|QESTNET Console]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Tester|QESTNET Tester]]

=== Coding Guidelines ===
This section is intended to provide a set of guidelines that are helpful to people writing code in the QESTNET repository.
* [[QESTNET_Internal:Developer_Git etiquette|Git etiquette]]
* [[QESTNET_Internal:Developer_Resharper|Resharper]]
* [[QESTNET_Internal:Developer_Code_Comments|Code comments]]

----

=== Coding Knowledge Base ===

==== QESTNET Projects Quick Reference Guide ====
* [[QESTNET_Internal:QESTNET_Projects_Quick_Reference_Guide|QESTNET Projects]]

==== Database ====

==== Classes, Controls, Modules ====

==== Testing and Debugging ====

==== Other ====
* [[QESTNET_Internal:Fugro_DBB_Service|Fugro Data Backbone Service]]
* [[QESTNET_Internal:Fugro DBB_TestMapping_Guide|Fugro Data Backbone Test Mapping Step-by-step Guide]]

----

=== Troubleshooting ===

== For Managers ==

[[Category:Development|{{PAGENAME}}]]
[[Category:Guidelines|{{PAGENAME}}]]
[[Category:QESTNET_Internal|{{PAGENAME}}]]
[[Category:Internal|{{PAGENAME}}]]

QESTNET Internal:Developer Home

2015-07-17T02:14:37Z

David.lucas:

This page acts as a home for QESTNET developers and aims to provide easy access to all relevant information and processes.

== For Developers ==
=== Developer Setup Guide ===
* [[QESTNET_Internal:Developer_Setup_Requirements|Requirements]]
* [[QESTNET_Internal:Developer_Setup_Git|Git]]
* [[QESTNET_Internal:Developer_Setup_QESTNET|QESTNET]]
* [[QESTNET_Internal:Developer_Setup_QESTField|QESTField]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Console|QESTNET Console]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Tester|QESTNET Tester]]

=== Coding Guidelines ===
This section is intended to provide a set of guidelines that are helpful to people writing code in the QESTNET repository.
* [[QESTNET_Internal:Developer_Git etiquette|Git etiquette]]
* [[QESTNET_Internal:Developer_Resharper|Resharper]]
* [[QESTNET_Internal:Developer_Code_Comments|Code comments]

----

=== Coding Knowledge Base ===

==== QESTNET Projects Quick Reference Guide ====
* [[QESTNET_Internal:QESTNET_Projects_Quick_Reference_Guide|QESTNET Projects]]

==== Database ====

==== Classes, Controls, Modules ====

==== Testing and Debugging ====

==== Other ====
* [[QESTNET_Internal:Fugro_DBB_Service|Fugro Data Backbone Service]]
* [[QESTNET_Internal:Fugro DBB_TestMapping_Guide|Fugro Data Backbone Test Mapping Step-by-step Guide]]

----

=== Troubleshooting ===

== For Managers ==

[[Category:Development|{{PAGENAME}}]]
[[Category:Guidelines|{{PAGENAME}}]]
[[Category:QESTNET_Internal|{{PAGENAME}}]]
[[Category:Internal|{{PAGENAME}}]]

QESTNET Internal:Developer Git etiquette

2015-07-15T07:12:57Z

David.lucas:

== How to "git" started ==
===Understanding Git===
Even I’ve only seen the tip of the iceberg, but there are some major conceptual differences with both VSS and SVN that are worth knowing.
 
There’s a couple of good resources that I like:
*Git Magic - http://www-cs-students.stanford.edu/~blynn/gitmagic/
*HgInit - http://hginit.com/top/ (Really well written, but actually for Mercurial, not Git. But the products are so similar that I found this one really useful anyway).
*Stack Overflow - http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide (this question has a ton of links to other resources if you want them)
*Git Manual – you should be able to do “git help” from the command line to bring up the git manual.
The biggest difference between Git and VSS is VSS will create a local copy of a particular branch, but Git will create a copy of all of the branches as well as their entire histories. This means you can switch between them all without the server being involved. You can then change multiple branches and push all of them up to the server. You only ever “see” one branch at a time however, and switch between them using the “checkout” command. So instead of “checkin” and “checkout” going to and from the server, they are local commands. You then use push and fetch to go to and from the server. Google it, see the above links, or talk to one of us for more info.
===Command line vs. VS plugin===
Although there is a Git plugin for Visual Studio, I really don’t like it myself. Personally I think I’m getting along with Git much better with just the command line interface, which is faster in the long-run. So, once installed, I like to use “Git Bash” (available in the Start Menu). That opens up a Linux emulation, which I prefer because it has color-coding and shows your current branch etc; however, you can also run it directly from a Windows command line (assuming you installed Git with that option selected).
 
The main non-intuitive thing at first with Git Bash is that path names would be described like /c/dev/ and not “c:\dev\”.
===How do I check out a file? (and branching)===
Two major points of difference with VSS here. One, individual files are not checked out, rather the entire tree is. Two, “checking out” really means switching to another branch. Though Git has a “checkout” command, it is not really like the VSS checkout at all.
 
Git is very big on branching, mainly because branching and merging are trivial in Git where they’re not in other SCMs. So you have not just the shared branches for separating stable and development code, but also you create them in your local repository to separate any particular line of work you might be following.
 
A branch is always on your entire working tree; in other words, any changes at all that you make while in the context of a branch apply to that branch. Making individual branches allows you to work on several different tasks at once without them interfering with each other. For example, a good approach is to have a separate branch for each issue that you’re working on. When you’re done working on the issue, you commit that whole branch.
 
Let’s say you’re working on a change to Program.cs, issue #5000. You might checkout a new branch just for working on that:
git branch 5000_program_fix
git checkout 5000_program_fix
(The above two commands can also be done with git checkout –b 5000_program_fix)
 
You start work on it, and modify Program.cs as you like. Suddenly, you’re told that issue #5055, a task to update the application readme.txt file, has to be done right away. So you commit your changes to the 5000_program_fix branch, and create a new branch for 5055_readme_fix.
notepad.exe Program.cs
git commit –a –m ‘Modified message on console main screen.’
git checkout –b 5055_readme_fix dev
(Note: if you don’t supply the starting point of master, the new branch (5055) will be created as a sub-branch of the current branch (5000), and will include all of the changes already committed for 5000.)
 
(Note 2: the “-a” in commit means “--all" and will automatically stage any changed files. See the git doco for more. It is not recommended unless you are sure you want all changed files included.)
 
You make the changes to the readme.txt and commit them.
notepad.exe readme.txt
git commit -a -m ‘Modified readme.txt with new instructions.’
Now you’ll find that you can switch between any of the three branches at will, and all of your work is separated correctly:
git checkout dev (contains neither the changes to Program.cs or readme.txt)
git checkout 5055_readme_fix (contains only the changes to the readme.txt)
git checkout 5000_program_fix (contains only the changes to Program.cs)
===How do I check in a file? (merging and pushing)===
Actually we sort of saw this in the previous question; we use git commit to “check in” a file to the current branch.
 
That’s not quite the end of the story though. For one, you’ve still got your changes in your own branch, like 5000_program_fix. So the first thing you should do once you’re happy with your fix is to merge it back into the development branch:
git checkout dev
git merge 5000_program_fix
If there are changes that can’t be automatically merged it should pop up the configured diff tool to let you do it manually. Otherwise, it just merges them in and automatically commits them (keeping your history of commits).
 
Remember, though, that this is all still occurring on your local repository; since you got the repository from GitHub, there’s been no communication at all with an external server. So, in order to put them back on the “central” repository:
git push origin dev
That will push all changes you’ve made to the dev branch up to the remote server.
 
Merging is a pretty common thing (just as common as branching really!). For example if a branch you’re working on needs a fix that you did in some other branch, just merge from that branch into the one you want.
===How do I see what I’ve changed?===
The easiest is to run Git Gui (or similar) and it will show you the changed files. If you want to use the console you can use:
git status
git status –u
See the manual for usage.
===Okay, but how do I see what’s changed in those files?===
In Git Gui, click on them. You can compare files in all sorts of ways, but most commonly may be between different branches, or different commits.
 
To view the differences in all of your uncommitted changes:
git diff
To view the differences in your uncommitted changes for a specific file:
git diff Program.cs
To view the differences between the master branch and the 5055 branch:
git diff master 5055_readme_fix
To view the differences between the current version and 2 commits ago:
git diff HEAD~2
There’s every other conceivable option you might need to compare too, those are just a very few basic ones.
 
You may also like to use the Git GUI for this, which provides a reasonably nice way of seeing complete file history of the entire repository – and generally much faster than SourceSafe does. Git GUI > Repository > Visualize … History.
 
Whoops, I made a mistake when committing! How do I undo it?
It’s quite alright to modify your own commits, since they still only exist in your own repository. The safest way is to use the reset command:
git reset --soft HEAD^
To explain: HEAD^ indicates that we should reset back to the state of the previous commit; if you wanted to go back two commits, you could use HEAD^^ or HEAD~2. The --soft reset means that the files themselves will not be modified, which is generally what you want; if you do a --hard reset instead, the files themselves will revert to the state they were in before you modified them, so only do that if you really want to throw away those changes.
 
After you’ve done a push it gets trickier because people may have pulled your mistake into their own repositories. In this case it’s generally recommended that you fix the mistake with another commit.
 
I need some cutting edge code that someone else is developing but which they haven’t pushed to the main repository. Can I get it?
Yes, you can pull from anyone’s repository, but I’m still working on the details of what’s required to allow our repositories to access each other. In the meantime, you could get the other person to push their branch up to the GitHub server and then you can pull from it.
===Where’s my Tools > Options menu?===
You have Git configuration options at the individual repository level, or at a global level (i.e. applies to all repositories). These are stored in configuration files, but are most easily accessible via the command line. For example to see all settings applying to the current repository:
git config --list
Or if you want to see just your global settings:
git config --list --global
Then if you want to change a setting, just issue the name and new value:
git config core.autocrlf true
Again, if you’re changing a global setting, use the --global parameter. Repository-level settings will override global ones I think.

===I’ve made a whole ton of commits, but it makes for a pretty messy history. Can I clean it all up?===
Yes, the easiest way is to use the rebase command. This usage is most well described here: http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks/2047707#2047707.
 
Also note Linus Torvalds’ recommendations with rebase, namely that you only rebase your own work: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html. Though product managers may want to clean up the code of their developers if absolutely necessary.

===Common Git Commands===
*git fetch – This will get the latest code from GitHub for all branches.
*git fetch <branchname> – The same but for a specific branch.
*git checkout <branchname> – Change to a specific branch on your local machine.
*git commit – Create a new commit on your local machine.
*git commit –a – Create a new commit on your local machine and automatically include all changed files. This will not add new files.
*git commit –m “message” – Create a new commit on your local machine and use the supplied message for it.
*git commit --amend – Change the message for the last commit you made.
*git push origin <branchname> – Push changes for a specific branch to GitHub.
*git rebase <target_branchname> – Rebase your currently checked out branch on top of the target branch.
*git rebase –i head~10 – Rebase the last 10 commits interactively. This lets you change commit messages, re-order commits, squash multiple commits together, etc.
*git merge -–ff-only <branchname> – A special type of merge just to update to more recent code.
*git mergetool – Run the merge tool any time a rebase or merge fails and it needs manually consolidating.

===Merge vs Rebase:===

Merge joins 2 branches together:
<nowiki>
A---B---C branch 2
/ \
D---E---F---G---H--- branch 1
</nowiki>

Rebase (based on the above) applies the changes for one branch on top of another:
<nowiki>
D---E---F---G---H---A---B---C--- branch 1, branch 2
</nowiki>

Because rebasing is destructive, this should not be done for code that has already been pushed up to GitHub. This is for reorganising commits on your local machine to make them nicer to push up.
 
This is most useful when you do a “git fetch” and discover someone else has pushed work up before you have. You then reapply your changes to the end of the history before pushing to GitHub.

==Git workflow==
===Starting a new bug/change request===
*Checkout the development branch (e.g. alien) that the bug/change request will be added to.
**Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien or git fetch origin alien and git merge --ff-only origin/alien).
**Create a new branch using the bug/cr and some form of descriptor as the name (e.g. cr4321-tv-map or bug1234-tv-map-ucs).
**Checkout the new branch (git checkout cr4321-tv-map).
*Make regular commits to this branch as you are developing (git commit -a -m 'Commit message.').
**Once initial development is complete rebase the bug/cr branch to a single commit (git rebase -i origin/cr4321-tv-map).
**Review the files that you’ve changed, using git status and git diff to ensure there are no unexpected changes.
**The bug/cr branch can now be pushed to github for testing (git push origin cr4321-tv-map).
*The tester will fetch and checkout the cr/bug branch to test it and give feedback.
**At this point make any required changes on the branch. Commit and push to github so that the tester can re-test.
**Once all development is complete, checkout the development branch again (git checkout alien). Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien).
**Merge the bug/cr branch into the development branch, resolving any conflicts (git merge cr4321-tv-map).
**The development branch can now be pushed to github for integration testing (git push origin alien).
*The tester will fetch and checkout the development branch to test it and give feedback.
**Minor fixes required from integration testing can be made directly on the development branch. These should be no major problems but if there are the fixes should be made on the bug/cr branch and tested there first. This should be done with priority as the development branch may be "broken" until these changes are merged.
**Once integration testing is complete or if it is not required the bug/cr branch can be deleted locally and on github.

QESTNET Internal:Developer Git etiquette

2015-07-15T07:12:21Z

David.lucas:

== How to "git" started ==
===Understanding Git===
Even I’ve only seen the tip of the iceberg, but there are some major conceptual differences with both VSS and SVN that are worth knowing.
 
There’s a couple of good resources that I like:
*Git Magic - http://www-cs-students.stanford.edu/~blynn/gitmagic/
*HgInit - http://hginit.com/top/ (Really well written, but actually for Mercurial, not Git. But the products are so similar that I found this one really useful anyway).
*Stack Overflow - http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide (this question has a ton of links to other resources if you want them)
*Git Manual – you should be able to do “git help” from the command line to bring up the git manual.
The biggest difference between Git and VSS is VSS will create a local copy of a particular branch, but Git will create a copy of all of the branches as well as their entire histories. This means you can switch between them all without the server being involved. You can then change multiple branches and push all of them up to the server. You only ever “see” one branch at a time however, and switch between them using the “checkout” command. So instead of “checkin” and “checkout” going to and from the server, they are local commands. You then use push and fetch to go to and from the server. Google it, see the above links, or talk to one of us for more info.
===Command line vs. VS plugin===
Although there is a Git plugin for Visual Studio, I really don’t like it myself. Personally I think I’m getting along with Git much better with just the command line interface, which is faster in the long-run. So, once installed, I like to use “Git Bash” (available in the Start Menu). That opens up a Linux emulation, which I prefer because it has color-coding and shows your current branch etc; however, you can also run it directly from a Windows command line (assuming you installed Git with that option selected).
 
The main non-intuitive thing at first with Git Bash is that path names would be described like /c/dev/ and not “c:\dev\”.
===How do I check out a file? (and branching)===
Two major points of difference with VSS here. One, individual files are not checked out, rather the entire tree is. Two, “checking out” really means switching to another branch. Though Git has a “checkout” command, it is not really like the VSS checkout at all.
 
Git is very big on branching, mainly because branching and merging are trivial in Git where they’re not in other SCMs. So you have not just the shared branches for separating stable and development code, but also you create them in your local repository to separate any particular line of work you might be following.
 
A branch is always on your entire working tree; in other words, any changes at all that you make while in the context of a branch apply to that branch. Making individual branches allows you to work on several different tasks at once without them interfering with each other. For example, a good approach is to have a separate branch for each issue that you’re working on. When you’re done working on the issue, you commit that whole branch.
 
Let’s say you’re working on a change to Program.cs, issue #5000. You might checkout a new branch just for working on that:
git branch 5000_program_fix
git checkout 5000_program_fix
(The above two commands can also be done with git checkout –b 5000_program_fix)
 
You start work on it, and modify Program.cs as you like. Suddenly, you’re told that issue #5055, a task to update the application readme.txt file, has to be done right away. So you commit your changes to the 5000_program_fix branch, and create a new branch for 5055_readme_fix.
notepad.exe Program.cs
git commit –a –m ‘Modified message on console main screen.’
git checkout –b 5055_readme_fix dev
(Note: if you don’t supply the starting point of master, the new branch (5055) will be created as a sub-branch of the current branch (5000), and will include all of the changes already committed for 5000.)
 
(Note 2: the “-a” in commit means “--all" and will automatically stage any changed files. See the git doco for more. It is not recommended unless you are sure you want all changed files included.)
 
You make the changes to the readme.txt and commit them.
notepad.exe readme.txt
git commit -a -m ‘Modified readme.txt with new instructions.’
Now you’ll find that you can switch between any of the three branches at will, and all of your work is separated correctly:
git checkout dev (contains neither the changes to Program.cs or readme.txt)
git checkout 5055_readme_fix (contains only the changes to the readme.txt)
git checkout 5000_program_fix (contains only the changes to Program.cs)
===How do I check in a file? (merging and pushing)===
Actually we sort of saw this in the previous question; we use git commit to “check in” a file to the current branch.
 
That’s not quite the end of the story though. For one, you’ve still got your changes in your own branch, like 5000_program_fix. So the first thing you should do once you’re happy with your fix is to merge it back into the development branch:
git checkout dev
git merge 5000_program_fix
If there are changes that can’t be automatically merged it should pop up the configured diff tool to let you do it manually. Otherwise, it just merges them in and automatically commits them (keeping your history of commits).
 
Remember, though, that this is all still occurring on your local repository; since you got the repository from GitHub, there’s been no communication at all with an external server. So, in order to put them back on the “central” repository:
git push origin dev
That will push all changes you’ve made to the dev branch up to the remote server.
 
Merging is a pretty common thing (just as common as branching really!). For example if a branch you’re working on needs a fix that you did in some other branch, just merge from that branch into the one you want.
===How do I see what I’ve changed?===
The easiest is to run Git Gui (or similar) and it will show you the changed files. If you want to use the console you can use:
git status
git status –u
See the manual for usage.
===Okay, but how do I see what’s changed in those files?===
In Git Gui, click on them. You can compare files in all sorts of ways, but most commonly may be between different branches, or different commits.
 
To view the differences in all of your uncommitted changes:
git diff
To view the differences in your uncommitted changes for a specific file:
git diff Program.cs
To view the differences between the master branch and the 5055 branch:
git diff master 5055_readme_fix
To view the differences between the current version and 2 commits ago:
git diff HEAD~2
There’s every other conceivable option you might need to compare too, those are just a very few basic ones.
 
You may also like to use the Git GUI for this, which provides a reasonably nice way of seeing complete file history of the entire repository – and generally much faster than SourceSafe does. Git GUI > Repository > Visualize … History.
 
Whoops, I made a mistake when committing! How do I undo it?
It’s quite alright to modify your own commits, since they still only exist in your own repository. The safest way is to use the reset command:
git reset --soft HEAD^
To explain: HEAD^ indicates that we should reset back to the state of the previous commit; if you wanted to go back two commits, you could use HEAD^^ or HEAD~2. The --soft reset means that the files themselves will not be modified, which is generally what you want; if you do a --hard reset instead, the files themselves will revert to the state they were in before you modified them, so only do that if you really want to throw away those changes.
 
After you’ve done a push it gets trickier because people may have pulled your mistake into their own repositories. In this case it’s generally recommended that you fix the mistake with another commit.
 
I need some cutting edge code that someone else is developing but which they haven’t pushed to the main repository. Can I get it?
Yes, you can pull from anyone’s repository, but I’m still working on the details of what’s required to allow our repositories to access each other. In the meantime, you could get the other person to push their branch up to the GitHub server and then you can pull from it.
===Where’s my Tools > Options menu?===
You have Git configuration options at the individual repository level, or at a global level (i.e. applies to all repositories). These are stored in configuration files, but are most easily accessible via the command line. For example to see all settings applying to the current repository:
git config --list
Or if you want to see just your global settings:
git config --list --global
Then if you want to change a setting, just issue the name and new value:
git config core.autocrlf true
Again, if you’re changing a global setting, use the --global parameter. Repository-level settings will override global ones I think.

===I’ve made a whole ton of commits, but it makes for a pretty messy history. Can I clean it all up?===
Yes, the easiest way is to use the rebase command. This usage is most well described here: http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks/2047707#2047707.
 
Also note Linus Torvalds’ recommendations with rebase, namely that you only rebase your own work: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html. Though product managers may want to clean up the code of their developers if absolutely necessary.

===Common Git Commands===
*git fetch – This will get the latest code from GitHub for all branches.
*git fetch <branchname> – The same but for a specific branch.
*git checkout <branchname> – Change to a specific branch on your local machine.
*git commit – Create a new commit on your local machine.
*git commit –a – Create a new commit on your local machine and automatically include all changed files. This will not add new files.
*git commit –m “message” – Create a new commit on your local machine and use the supplied message for it.
*git commit --amend – Change the message for the last commit you made.
*git push origin <branchname> – Push changes for a specific branch to GitHub.
*git rebase <target_branchname> – Rebase your currently checked out branch on top of the target branch.
*git rebase –i head~10 – Rebase the last 10 commits interactively. This lets you change commit messages, re-order commits, squash multiple commits together, etc.
*git merge -–ff-only <branchname> – A special type of merge just to update to more recent code.
*git mergetool – Run the merge tool any time a rebase or merge fails and it needs manually consolidating.

===Merge vs Rebase:===

Merge joins 2 branches together:
<nowiki>
A---B---C branch 2
/ \
D---E---F---G---H--- branch 1
</nowiki>

Rebase (based on the above) applies the changes for one branch on top of another:
<nowiki>
D---E---F---G---H---A---B---C--- branch 1, branch 2
</nowiki>

Because rebasing is destructive, this should not be done for code that has already been pushed up to GitHub. This is for reorganising commits on your local machine to make them nicer to push up.
 
This is most useful when you do a “git fetch” and discover someone else has pushed work up before you have. You then reapply your changes to the end of the history before pushing to GitHub.

==Git workflow==
*Checkout the development branch (e.g. alien) that the bug/change request will be added to.
**Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien or git fetch origin alien and git merge --ff-only origin/alien).
**Create a new branch using the bug/cr and some form of descriptor as the name (e.g. cr4321-tv-map or bug1234-tv-map-ucs).
**Checkout the new branch (git checkout cr4321-tv-map).
*Make regular commits to this branch as you are developing (git commit -a -m 'Commit message.').
**Once initial development is complete rebase the bug/cr branch to a single commit (git rebase -i origin/cr4321-tv-map).
**Review the files that you’ve changed, using git status and git diff to ensure there are no unexpected changes.
**The bug/cr branch can now be pushed to github for testing (git push origin cr4321-tv-map).
*The tester will fetch and checkout the cr/bug branch to test it and give feedback.
**At this point make any required changes on the branch. Commit and push to github so that the tester can re-test.
**Once all development is complete, checkout the development branch again (git checkout alien). Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien).
**Merge the bug/cr branch into the development branch, resolving any conflicts (git merge cr4321-tv-map).
**The development branch can now be pushed to github for integration testing (git push origin alien).
*The tester will fetch and checkout the development branch to test it and give feedback.
**Minor fixes required from integration testing can be made directly on the development branch. These should be no major problems but if there are the fixes should be made on the bug/cr branch and tested there first. This should be done with priority as the development branch may be "broken" until these changes are merged.
**Once integration testing is complete or if it is not required the bug/cr branch can be deleted locally and on github.

QESTNET Internal:Developer Setup Git

2015-07-15T07:11:56Z

David.lucas:

QESTNET Internal:Developer Home

2015-07-15T07:10:49Z

David.lucas:

This page acts as a home for QESTNET developers and aims to provide easy access to all relevant information and processes.

== For Developers ==
=== Developer Setup Guide ===
* [[QESTNET_Internal:Developer_Setup_Requirements|Requirements]]
* [[QESTNET_Internal:Developer_Setup_Git|Git]]
* [[QESTNET_Internal:Developer_Setup_QESTNET|QESTNET]]
* [[QESTNET_Internal:Developer_Setup_QESTField|QESTField]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Console|QESTNET Console]]
* [[QESTNET_Internal:Developer_Setup_QESTNET Tester|QESTNET Tester]]

=== Coding Style Guidelines ===
This section is intended to provide a set of guidelines that are helpful to people writing code in Spectra QEST. It includes notes on naming conventions, coding style, commenting, tips for performance, avoiding errors, and error handling.
* [[Development:Symbols|Symbols]]
* [[Naming conventions]]
* [[Development:Code_Commenting_Guidelines|Code commenting]]
* [[QESTNET_Internal:Developer_Git etiquette |Git etiquette]]
----

=== Coding Knowledge Base ===

==== QESTNET Projects Quick Reference Guide ====
* [[QESTNET_Internal:QESTNET_Projects_Quick_Reference_Guide|QESTNET Projects]]

==== Database ====

==== Classes, Controls, Modules ====

==== Testing and Debugging ====

==== Other ====
* [[QESTNET_Internal:Fugro_DBB_Service|Fugro Data Backbone Service]]
* [[QESTNET_Internal:Fugro DBB_TestMapping_Guide|Fugro Data Backbone Test Mapping Step-by-step Guide]]

----

=== Troubleshooting ===

== For Managers ==

[[Category:Development|{{PAGENAME}}]]
[[Category:Guidelines|{{PAGENAME}}]]
[[Category:QESTNET_Internal|{{PAGENAME}}]]
[[Category:Internal|{{PAGENAME}}]]

QESTNET Internal:Developer Setup QESTNET

2015-07-15T07:09:15Z

David.lucas:

===QESTNET===
=====QESTNET Repository=====
*Clone the qestnet repository (git clone git@github.com:spectraqest/qestnet.git).
*Fetch the branch to be used for development (git fetch origin branch_name).
*Checkout the branch (git checkout branch_name).

=====App Configuration=====
Config files often have ever changing information specific to your setup in them. As such files with extension '''.config''' are ignored by git. See '''.gitignore''' files for other files git will ignore. All config files have an associated default file. e.g., app.config has app.config.default. This will give a new setup a starting template. If you add additional configuration properties make sure the '''.default''' file is updated as this is the only one committed to git.
*Run the batch file '''~\qestnet\QESTNET\copy_default_config.bat'''
*The batch file will go through the qestnet repository and create '''.config''' files from the '''.default''' files
 

=====Create QESTNET Service=====
*Run '''~\qestnet\QESTNET\bin\install_qestnet_debug.bat'''. This will create a QESTNET windows service on your machine.
*Open Services from the control panel.
*Right click the QESTNET service and select properties. Change the Log On permissions to your account or the windows NETWORK SERVICE account. If you use the NETWORK SERVICE account you will need to ensure it has the necessary permissions to ports and files the qestnet service will use.
*Start the service
[[Image:QESTNET Service.jpg]]
 

=====QESTLab Schema Generator Setup=====
*Open '''~\qestnet\QESTNET\QESTLab.SchemaGenerator\ QESTLab.SchemaGenerator.sln'''.
**Build the solution, there should be no errors.
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
**Open the app.config file in the QESTNET project.
**Edit the QESTLab_Data connection string to point to the QESTLab database you want to connect to.
''<add name="QESTLab_Data" connectionString="metadata=res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.csdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.ssdl|res://*/Spectra.QESTLab.Data.Entities.QESTLabModel.msl;provider=System.Data.SqlClient;provider connection string="data source=ADLD0031;initial catalog=fugro_20150320_qestlab;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />''

*Open the program Windows PowerShell ISE.
**Enter '''set-executionpolicy remotesigned''' into the console
**This comes up, click Yes
[[Image:QESTNET Service 2.jpg]]

*Right-click the '''GenerateDataSchema.ps1''' file in QESTLab.Data and select Open With
**Click add new program (“Add...”)
**Enter the PowerShell folder (C:\WINDOWS\system32\WindowsPowerShell\v1.0)
**Click OK?
**Click “set as default” on the open with window.
**Click OK.
The file can now be run using PowerShell by double clicking on it in Visual Studio.
 

=====Build QESTLab.Data=====
The first time QESTLab.Data is built on a machine or if the bin is cleaned out for the project the following steps will need to be done. This is due to a circular reference that exists in QESTLab.Data. The QESTLab_Data_Views.tt references the QESTLab.Data.dll which is built using the QESTLab_Data_Views.tt output.
*Exclude '''QESTLab_Data_Views.tt''' from the QESTLab.Data project
*Build QESTLab.Data project
*Include '''QESTLab_Data_Views.tt'''
*Right click '''QESTLab_Data_Views.tt''' and select '''Run Custom Tool'''
*Build QESTLab.Data project
 

=====Update QESTLab.Data Schema=====
The following steps will update the QESTLab.Data schema to match the QESTLab database structure
*Run '''GenerateDataSchema.ps1'''
*Build QESTLab.Data project
*Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
*Build QESTLab.Data project.
It is on the "to do" list to get the PowerShell script to do all the last three steps as well. This was initially a one click operation but no one can stop the inexorable march of progress.
 

=====Build QESTNET=====
*Open '''~\qestnet\QESTNET\QESTNET.sln'''
*Build the solution. If there are no errors the QESTNET service has been successfully built and the service restarted.

QESTNET Internal:Developer Git etiquette

2015-07-15T07:03:22Z

David.lucas:

== Initial Setup ==
*Signup for a GitHub account www.github.com. Tell someone your username so they can add you to the appropriate SpectraQEST team
*Download and install Git from http://git-scm.com/download. Windows has two possible ways to run git: choose msysgit instead of Cygwin. When installing, choose all the options that they recommend for Windows development. Install again to something like “C:\Program Files (x86)\Git”.
**You will be prompted about line ending conversions at some point. Use the auto-convert option, I think it’s the first option. It should produce the line “autocrlf = true” in the default config: “C:\Program Files (x86)\Git\etc\gitconfig”.
*You can now:
**Run the Git console using Git Bash, a shortcut (quotes included): "C:\Program Files (x86)\Git\bin\sh.exe" --login –i
**Run Git GUI using this entire command (quotes included) in a shortcut: "C:\Program Files (x86)\Git\bin\wish.exe" "C:\Program Files (x86)\Git\libexec\git-core\git-gui"
**A shortcut for both of these should have been created in the Start Menu automatically.
*Your global Git configuration file “.gitconfig” is found under “C:\Users\Your.Name\.gitconfig”. Setup your username and email by using the following commands in Git Bash:
**git config --global user.name “Your name”
**git config --global user.email your.name@spectraqest.com
*Download and install KDiff3 (this will be used as the merge tool for changes that can’t be automatically merged. Can maybe make it work with WinMerge, but haven’t tried.) This can be installed to the default location, something like “C:\Program Files (x86)\KDiff3”.
*Setup Git to use KDiff3 and optionally Notepad++ as your editor instead of Vim by editing the global .gitconfig file. I find it easier to edit manually in Notepad++ than using the console. Here’s an example of a config file:
<nowiki>[core]
editor = "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession -noPlugin"
autocrlf = true
[user]
name = John Meegan
email = john.meegan@spectraqest.com
[merge]
tool = kdiff3
[mergetool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe
[diff]
tool = kdiff3
[difftool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe</nowiki>
*Set up your public key: http://github.com/guides/providing-your-ssh-key . Note that the ~ directory in Git Bash corresponds to “C:\Users\Your.Name\”, so your SSH public key can be found in “C:\users\Your.Name\.ssh\id_rsa.pub” after you’ve generated it.
**By this point you will have a GitHub account and password, a private and public SSH key, and a password to access your private SSH key. This last password is just in case someone steals your computer, they cannot access your private key without a password. This prevents them from accessing anything you use your key for, such as GitHub, once you have added your public SSH key to GitHub.
*Make the folder “C:\dev\” on your C Drive for development work.
*Get a Git repository from GitHub via something like the following (note the URL comes from GitHub and changes depending on the project):
**cd /c/dev/
**git clone git@github.com:spectraqest/qestnet.upgrade.git
*That’s pretty much it. There are plenty of tools you can try out to assist with using Git if you wish. Two of the most popular are:
**GitHub for Windows: https://windows.github.com
**Atlassian SourceTree: http://www.sourcetreeapp.com/

== How to "git" started ==
===Understanding Git===
Even I’ve only seen the tip of the iceberg, but there are some major conceptual differences with both VSS and SVN that are worth knowing.
 
There’s a couple of good resources that I like:
*Git Magic - http://www-cs-students.stanford.edu/~blynn/gitmagic/
*HgInit - http://hginit.com/top/ (Really well written, but actually for Mercurial, not Git. But the products are so similar that I found this one really useful anyway).
*Stack Overflow - http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide (this question has a ton of links to other resources if you want them)
*Git Manual – you should be able to do “git help” from the command line to bring up the git manual.
The biggest difference between Git and VSS is VSS will create a local copy of a particular branch, but Git will create a copy of all of the branches as well as their entire histories. This means you can switch between them all without the server being involved. You can then change multiple branches and push all of them up to the server. You only ever “see” one branch at a time however, and switch between them using the “checkout” command. So instead of “checkin” and “checkout” going to and from the server, they are local commands. You then use push and fetch to go to and from the server. Google it, see the above links, or talk to one of us for more info.
===Command line vs. VS plugin===
Although there is a Git plugin for Visual Studio, I really don’t like it myself. Personally I think I’m getting along with Git much better with just the command line interface, which is faster in the long-run. So, once installed, I like to use “Git Bash” (available in the Start Menu). That opens up a Linux emulation, which I prefer because it has color-coding and shows your current branch etc; however, you can also run it directly from a Windows command line (assuming you installed Git with that option selected).
 
The main non-intuitive thing at first with Git Bash is that path names would be described like /c/dev/ and not “c:\dev\”.
===How do I check out a file? (and branching)===
Two major points of difference with VSS here. One, individual files are not checked out, rather the entire tree is. Two, “checking out” really means switching to another branch. Though Git has a “checkout” command, it is not really like the VSS checkout at all.
 
Git is very big on branching, mainly because branching and merging are trivial in Git where they’re not in other SCMs. So you have not just the shared branches for separating stable and development code, but also you create them in your local repository to separate any particular line of work you might be following.
 
A branch is always on your entire working tree; in other words, any changes at all that you make while in the context of a branch apply to that branch. Making individual branches allows you to work on several different tasks at once without them interfering with each other. For example, a good approach is to have a separate branch for each issue that you’re working on. When you’re done working on the issue, you commit that whole branch.
 
Let’s say you’re working on a change to Program.cs, issue #5000. You might checkout a new branch just for working on that:
git branch 5000_program_fix
git checkout 5000_program_fix
(The above two commands can also be done with git checkout –b 5000_program_fix)
 
You start work on it, and modify Program.cs as you like. Suddenly, you’re told that issue #5055, a task to update the application readme.txt file, has to be done right away. So you commit your changes to the 5000_program_fix branch, and create a new branch for 5055_readme_fix.
notepad.exe Program.cs
git commit –a –m ‘Modified message on console main screen.’
git checkout –b 5055_readme_fix dev
(Note: if you don’t supply the starting point of master, the new branch (5055) will be created as a sub-branch of the current branch (5000), and will include all of the changes already committed for 5000.)
 
(Note 2: the “-a” in commit means “--all" and will automatically stage any changed files. See the git doco for more. It is not recommended unless you are sure you want all changed files included.)
 
You make the changes to the readme.txt and commit them.
notepad.exe readme.txt
git commit -a -m ‘Modified readme.txt with new instructions.’
Now you’ll find that you can switch between any of the three branches at will, and all of your work is separated correctly:
git checkout dev (contains neither the changes to Program.cs or readme.txt)
git checkout 5055_readme_fix (contains only the changes to the readme.txt)
git checkout 5000_program_fix (contains only the changes to Program.cs)
===How do I check in a file? (merging and pushing)===
Actually we sort of saw this in the previous question; we use git commit to “check in” a file to the current branch.
 
That’s not quite the end of the story though. For one, you’ve still got your changes in your own branch, like 5000_program_fix. So the first thing you should do once you’re happy with your fix is to merge it back into the development branch:
git checkout dev
git merge 5000_program_fix
If there are changes that can’t be automatically merged it should pop up the configured diff tool to let you do it manually. Otherwise, it just merges them in and automatically commits them (keeping your history of commits).
 
Remember, though, that this is all still occurring on your local repository; since you got the repository from GitHub, there’s been no communication at all with an external server. So, in order to put them back on the “central” repository:
git push origin dev
That will push all changes you’ve made to the dev branch up to the remote server.
 
Merging is a pretty common thing (just as common as branching really!). For example if a branch you’re working on needs a fix that you did in some other branch, just merge from that branch into the one you want.
===How do I see what I’ve changed?===
The easiest is to run Git Gui (or similar) and it will show you the changed files. If you want to use the console you can use:
git status
git status –u
See the manual for usage.
===Okay, but how do I see what’s changed in those files?===
In Git Gui, click on them. You can compare files in all sorts of ways, but most commonly may be between different branches, or different commits.
 
To view the differences in all of your uncommitted changes:
git diff
To view the differences in your uncommitted changes for a specific file:
git diff Program.cs
To view the differences between the master branch and the 5055 branch:
git diff master 5055_readme_fix
To view the differences between the current version and 2 commits ago:
git diff HEAD~2
There’s every other conceivable option you might need to compare too, those are just a very few basic ones.
 
You may also like to use the Git GUI for this, which provides a reasonably nice way of seeing complete file history of the entire repository – and generally much faster than SourceSafe does. Git GUI > Repository > Visualize … History.
 
Whoops, I made a mistake when committing! How do I undo it?
It’s quite alright to modify your own commits, since they still only exist in your own repository. The safest way is to use the reset command:
git reset --soft HEAD^
To explain: HEAD^ indicates that we should reset back to the state of the previous commit; if you wanted to go back two commits, you could use HEAD^^ or HEAD~2. The --soft reset means that the files themselves will not be modified, which is generally what you want; if you do a --hard reset instead, the files themselves will revert to the state they were in before you modified them, so only do that if you really want to throw away those changes.
 
After you’ve done a push it gets trickier because people may have pulled your mistake into their own repositories. In this case it’s generally recommended that you fix the mistake with another commit.
 
I need some cutting edge code that someone else is developing but which they haven’t pushed to the main repository. Can I get it?
Yes, you can pull from anyone’s repository, but I’m still working on the details of what’s required to allow our repositories to access each other. In the meantime, you could get the other person to push their branch up to the GitHub server and then you can pull from it.
===Where’s my Tools > Options menu?===
You have Git configuration options at the individual repository level, or at a global level (i.e. applies to all repositories). These are stored in configuration files, but are most easily accessible via the command line. For example to see all settings applying to the current repository:
git config --list
Or if you want to see just your global settings:
git config --list --global
Then if you want to change a setting, just issue the name and new value:
git config core.autocrlf true
Again, if you’re changing a global setting, use the --global parameter. Repository-level settings will override global ones I think.

===I’ve made a whole ton of commits, but it makes for a pretty messy history. Can I clean it all up?===
Yes, the easiest way is to use the rebase command. This usage is most well described here: http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks/2047707#2047707.
 
Also note Linus Torvalds’ recommendations with rebase, namely that you only rebase your own work: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html. Though product managers may want to clean up the code of their developers if absolutely necessary.

===Common Git Commands===
*git fetch – This will get the latest code from GitHub for all branches.
*git fetch <branchname> – The same but for a specific branch.
*git checkout <branchname> – Change to a specific branch on your local machine.
*git commit – Create a new commit on your local machine.
*git commit –a – Create a new commit on your local machine and automatically include all changed files. This will not add new files.
*git commit –m “message” – Create a new commit on your local machine and use the supplied message for it.
*git commit --amend – Change the message for the last commit you made.
*git push origin <branchname> – Push changes for a specific branch to GitHub.
*git rebase <target_branchname> – Rebase your currently checked out branch on top of the target branch.
*git rebase –i head~10 – Rebase the last 10 commits interactively. This lets you change commit messages, re-order commits, squash multiple commits together, etc.
*git merge -–ff-only <branchname> – A special type of merge just to update to more recent code.
*git mergetool – Run the merge tool any time a rebase or merge fails and it needs manually consolidating.

===Merge vs Rebase:===

Merge joins 2 branches together:
<nowiki>
A---B---C branch 2
/ \
D---E---F---G---H--- branch 1
</nowiki>

Rebase (based on the above) applies the changes for one branch on top of another:
<nowiki>
D---E---F---G---H---A---B---C--- branch 1, branch 2
</nowiki>

Because rebasing is destructive, this should not be done for code that has already been pushed up to GitHub. This is for reorganising commits on your local machine to make them nicer to push up.
 
This is most useful when you do a “git fetch” and discover someone else has pushed work up before you have. You then reapply your changes to the end of the history before pushing to GitHub.

==Git workflow==
*Checkout the development branch (e.g. alien) that the bug/change request will be added to.
**Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien or git fetch origin alien and git merge --ff-only origin/alien).
**Create a new branch using the bug/cr and some form of descriptor as the name (e.g. cr4321-tv-map or bug1234-tv-map-ucs).
**Checkout the new branch (git checkout cr4321-tv-map).
*Make regular commits to this branch as you are developing (git commit -a -m 'Commit message.').
**Once initial development is complete rebase the bug/cr branch to a single commit (git rebase -i origin/cr4321-tv-map).
**Review the files that you’ve changed, using git status and git diff to ensure there are no unexpected changes.
**The bug/cr branch can now be pushed to github for testing (git push origin cr4321-tv-map).
*The tester will fetch and checkout the cr/bug branch to test it and give feedback.
**At this point make any required changes on the branch. Commit and push to github so that the tester can re-test.
**Once all development is complete, checkout the development branch again (git checkout alien). Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien).
**Merge the bug/cr branch into the development branch, resolving any conflicts (git merge cr4321-tv-map).
**The development branch can now be pushed to github for integration testing (git push origin alien).
*The tester will fetch and checkout the development branch to test it and give feedback.
**Minor fixes required from integration testing can be made directly on the development branch. These should be no major problems but if there are the fixes should be made on the bug/cr branch and tested there first. This should be done with priority as the development branch may be "broken" until these changes are merged.
**Once integration testing is complete or if it is not required the bug/cr branch can be deleted locally and on github.

QESTNET Internal:Developer Git etiquette

2015-07-15T07:01:23Z

David.lucas:

== Initial Setup ==
*Signup for a GitHub account www.github.com. Tell someone your username so they can add you to the appropriate SpectraQEST team
*Download and install Git from http://git-scm.com/download. Windows has two possible ways to run git: choose msysgit instead of Cygwin. When installing, choose all the options that they recommend for Windows development. Install again to something like “C:\Program Files (x86)\Git”.
**You will be prompted about line ending conversions at some point. Use the auto-convert option, I think it’s the first option. It should produce the line “autocrlf = true” in the default config: “C:\Program Files (x86)\Git\etc\gitconfig”.
*You can now:
**Run the Git console using Git Bash, a shortcut (quotes included): "C:\Program Files (x86)\Git\bin\sh.exe" --login –i
**Run Git GUI using this entire command (quotes included) in a shortcut: "C:\Program Files (x86)\Git\bin\wish.exe" "C:\Program Files (x86)\Git\libexec\git-core\git-gui"
**A shortcut for both of these should have been created in the Start Menu automatically.
*Your global Git configuration file “.gitconfig” is found under “C:\Users\Your.Name\.gitconfig”. Setup your username and email by using the following commands in Git Bash:
**git config --global user.name “Your name”
**git config --global user.email your.name@spectraqest.com
*Download and install KDiff3 (this will be used as the merge tool for changes that can’t be automatically merged. Can maybe make it work with WinMerge, but haven’t tried.) This can be installed to the default location, something like “C:\Program Files (x86)\KDiff3”.
*Setup Git to use KDiff3 and optionally Notepad++ as your editor instead of Vim by editing the global .gitconfig file. I find it easier to edit manually in Notepad++ than using the console. Here’s an example of a config file:
<nowiki>[core]
editor = "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession -noPlugin"
autocrlf = true
[user]
name = John Meegan
email = john.meegan@spectraqest.com
[merge]
tool = kdiff3
[mergetool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe
[diff]
tool = kdiff3
[difftool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe</nowiki>
*Set up your public key: http://github.com/guides/providing-your-ssh-key . Note that the ~ directory in Git Bash corresponds to “C:\Users\Your.Name\”, so your SSH public key can be found in “C:\users\Your.Name\.ssh\id_rsa.pub” after you’ve generated it.
**By this point you will have a GitHub account and password, a private and public SSH key, and a password to access your private SSH key. This last password is just in case someone steals your computer, they cannot access your private key without a password. This prevents them from accessing anything you use your key for, such as GitHub, once you have added your public SSH key to GitHub.
*Make the folder “C:\dev\” on your C Drive for development work.
*Get a Git repository from GitHub via something like the following (note the URL comes from GitHub and changes depending on the project):
**cd /c/dev/
**git clone git@github.com:spectraqest/qestnet.upgrade.git
*That’s pretty much it. There are plenty of tools you can try out to assist with using Git if you wish. Two of the most popular are:
**GitHub for Windows: https://windows.github.com
**Atlassian SourceTree: http://www.sourcetreeapp.com/

== How to "git" started ==
===Understanding Git===
Even I’ve only seen the tip of the iceberg, but there are some major conceptual differences with both VSS and SVN that are worth knowing.
 
There’s a couple of good resources that I like:
*Git Magic - http://www-cs-students.stanford.edu/~blynn/gitmagic/
*HgInit - http://hginit.com/top/ (Really well written, but actually for Mercurial, not Git. But the products are so similar that I found this one really useful anyway).
*Stack Overflow - http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide (this question has a ton of links to other resources if you want them)
*Git Manual – you should be able to do “git help” from the command line to bring up the git manual.
The biggest difference between Git and VSS is VSS will create a local copy of a particular branch, but Git will create a copy of all of the branches as well as their entire histories. This means you can switch between them all without the server being involved. You can then change multiple branches and push all of them up to the server. You only ever “see” one branch at a time however, and switch between them using the “checkout” command. So instead of “checkin” and “checkout” going to and from the server, they are local commands. You then use push and fetch to go to and from the server. Google it, see the above links, or talk to one of us for more info.
===Command line vs. VS plugin===
Although there is a Git plugin for Visual Studio, I really don’t like it myself. Personally I think I’m getting along with Git much better with just the command line interface, which is faster in the long-run. So, once installed, I like to use “Git Bash” (available in the Start Menu). That opens up a Linux emulation, which I prefer because it has color-coding and shows your current branch etc; however, you can also run it directly from a Windows command line (assuming you installed Git with that option selected).
 
The main non-intuitive thing at first with Git Bash is that path names would be described like /c/dev/ and not “c:\dev\”.
===How do I check out a file? (and branching)===
Two major points of difference with VSS here. One, individual files are not checked out, rather the entire tree is. Two, “checking out” really means switching to another branch. Though Git has a “checkout” command, it is not really like the VSS checkout at all.
 
Git is very big on branching, mainly because branching and merging are trivial in Git where they’re not in other SCMs. So you have not just the shared branches for separating stable and development code, but also you create them in your local repository to separate any particular line of work you might be following.
 
A branch is always on your entire working tree; in other words, any changes at all that you make while in the context of a branch apply to that branch. Making individual branches allows you to work on several different tasks at once without them interfering with each other. For example, a good approach is to have a separate branch for each issue that you’re working on. When you’re done working on the issue, you commit that whole branch.
 
Let’s say you’re working on a change to Program.cs, issue #5000. You might checkout a new branch just for working on that:
git branch 5000_program_fix
git checkout 5000_program_fix
(The above two commands can also be done with git checkout –b 5000_program_fix)
 
You start work on it, and modify Program.cs as you like. Suddenly, you’re told that issue #5055, a task to update the application readme.txt file, has to be done right away. So you commit your changes to the 5000_program_fix branch, and create a new branch for 5055_readme_fix.
notepad.exe Program.cs
git commit –a –m ‘Modified message on console main screen.’
git checkout –b 5055_readme_fix dev
(Note: if you don’t supply the starting point of master, the new branch (5055) will be created as a sub-branch of the current branch (5000), and will include all of the changes already committed for 5000.)
 
(Note 2: the “-a” in commit means “--all" and will automatically stage any changed files. See the git doco for more. It is not recommended unless you are sure you want all changed files included.)
 
You make the changes to the readme.txt and commit them.
notepad.exe readme.txt
git commit -a -m ‘Modified readme.txt with new instructions.’
Now you’ll find that you can switch between any of the three branches at will, and all of your work is separated correctly:
git checkout dev (contains neither the changes to Program.cs or readme.txt)
git checkout 5055_readme_fix (contains only the changes to the readme.txt)
git checkout 5000_program_fix (contains only the changes to Program.cs)
===How do I check in a file? (merging and pushing)===
Actually we sort of saw this in the previous question; we use git commit to “check in” a file to the current branch.
 
That’s not quite the end of the story though. For one, you’ve still got your changes in your own branch, like 5000_program_fix. So the first thing you should do once you’re happy with your fix is to merge it back into the development branch:
git checkout dev
git merge 5000_program_fix
If there are changes that can’t be automatically merged it should pop up the configured diff tool to let you do it manually. Otherwise, it just merges them in and automatically commits them (keeping your history of commits).
 
Remember, though, that this is all still occurring on your local repository; since you got the repository from GitHub, there’s been no communication at all with an external server. So, in order to put them back on the “central” repository:
git push origin dev
That will push all changes you’ve made to the dev branch up to the remote server.
 
Merging is a pretty common thing (just as common as branching really!). For example if a branch you’re working on needs a fix that you did in some other branch, just merge from that branch into the one you want.
===How do I see what I’ve changed?===
The easiest is to run Git Gui (or similar) and it will show you the changed files. If you want to use the console you can use:
git status
git status –u
See the manual for usage.
===Okay, but how do I see what’s changed in those files?===
In Git Gui, click on them. You can compare files in all sorts of ways, but most commonly may be between different branches, or different commits.
 
To view the differences in all of your uncommitted changes:
git diff
To view the differences in your uncommitted changes for a specific file:
git diff Program.cs
To view the differences between the master branch and the 5055 branch:
git diff master 5055_readme_fix
To view the differences between the current version and 2 commits ago:
git diff HEAD~2
There’s every other conceivable option you might need to compare too, those are just a very few basic ones.
 
You may also like to use the Git GUI for this, which provides a reasonably nice way of seeing complete file history of the entire repository – and generally much faster than SourceSafe does. Git GUI > Repository > Visualize … History.
 
Whoops, I made a mistake when committing! How do I undo it?
It’s quite alright to modify your own commits, since they still only exist in your own repository. The safest way is to use the reset command:
git reset --soft HEAD^
To explain: HEAD^ indicates that we should reset back to the state of the previous commit; if you wanted to go back two commits, you could use HEAD^^ or HEAD~2. The --soft reset means that the files themselves will not be modified, which is generally what you want; if you do a --hard reset instead, the files themselves will revert to the state they were in before you modified them, so only do that if you really want to throw away those changes.
 
After you’ve done a push it gets trickier because people may have pulled your mistake into their own repositories. In this case it’s generally recommended that you fix the mistake with another commit.
 
I need some cutting edge code that someone else is developing but which they haven’t pushed to the main repository. Can I get it?
Yes, you can pull from anyone’s repository, but I’m still working on the details of what’s required to allow our repositories to access each other. In the meantime, you could get the other person to push their branch up to the GitHub server and then you can pull from it.
===Where’s my Tools > Options menu?===
You have Git configuration options at the individual repository level, or at a global level (i.e. applies to all repositories). These are stored in configuration files, but are most easily accessible via the command line. For example to see all settings applying to the current repository:
git config --list
Or if you want to see just your global settings:
git config --list --global
Then if you want to change a setting, just issue the name and new value:
git config core.autocrlf true
Again, if you’re changing a global setting, use the --global parameter. Repository-level settings will override global ones I think.

===I’ve made a whole ton of commits, but it makes for a pretty messy history. Can I clean it all up?===
Yes, the easiest way is to use the rebase command. This usage is most well described here: http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks/2047707#2047707.
 
Also note Linus Torvalds’ recommendations with rebase, namely that you only rebase your own work: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html. Though product managers may want to clean up the code of their developers if absolutely necessary.

===Common Git Commands===
*git fetch – This will get the latest code from GitHub for all branches.
*git fetch <branchname> – The same but for a specific branch.
*git checkout <branchname> – Change to a specific branch on your local machine.
*git commit – Create a new commit on your local machine.
*git commit –a – Create a new commit on your local machine and automatically include all changed files. This will not add new files.
*git commit –m “message” – Create a new commit on your local machine and use the supplied message for it.
*git commit --amend – Change the message for the last commit you made.
*git push origin <branchname> – Push changes for a specific branch to GitHub.
*git rebase <target_branchname> – Rebase your currently checked out branch on top of the target branch.
*git rebase –i head~10 – Rebase the last 10 commits interactively. This lets you change commit messages, re-order commits, squash multiple commits together, etc.
*git merge -–ff-only <branchname> – A special type of merge just to update to more recent code.
*git mergetool – Run the merge tool any time a rebase or merge fails and it needs manually consolidating.

===Merge vs Rebase:===
<nowiki>
Merge joins 2 branches together:

A---B---C branch 2
/ \
D---E---F---G---H--- branch 1

Rebase (based on the above) applies the changes for one branch on top of another:

D---E---F---G---H---A---B---C--- branch 1, branch 2
</nowiki>

Because rebasing is destructive, this should not be done for code that has already been pushed up to GitHub. This is for reorganising commits on your local machine to make them nicer to push up.
 
This is most useful when you do a “git fetch” and discover someone else has pushed work up before you have. You then reapply your changes to the end of the history before pushing to GitHub.

==Git workflow==
*Checkout the development branch (e.g. alien) that the bug/change request will be added to.
**Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien or git fetch origin alien and git merge --ff-only origin/alien).
**Create a new branch using the bug/cr and some form of descriptor as the name (e.g. cr4321-tv-map or bug1234-tv-map-ucs).
**Checkout the new branch (git checkout cr4321-tv-map).
*Make regular commits to this branch as you are developing (git commit -a -m 'Commit message.').
**Once initial development is complete rebase the bug/cr branch to a single commit (git rebase -i origin/cr4321-tv-map).
**Review the files that you’ve changed, using git status and git diff to ensure there are no unexpected changes.
**The bug/cr branch can now be pushed to github for testing (git push origin cr4321-tv-map).
*The tester will fetch and checkout the cr/bug branch to test it and give feedback.
**At this point make any required changes on the branch. Commit and push to github so that the tester can re-test.
**Once all development is complete, checkout the development branch again (git checkout alien). Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien).
**Merge the bug/cr branch into the development branch, resolving any conflicts (git merge cr4321-tv-map).
**The development branch can now be pushed to github for integration testing (git push origin alien).
*The tester will fetch and checkout the development branch to test it and give feedback.
**Minor fixes required from integration testing can be made directly on the development branch. These should be no major problems but if there are the fixes should be made on the bug/cr branch and tested there first. This should be done with priority as the development branch may be "broken" until these changes are merged.
**Once integration testing is complete or if it is not required the bug/cr branch can be deleted locally and on github.

QESTNET Internal:Developer Git etiquette

2015-07-15T06:59:35Z

David.lucas:

== Initial Setup ==
*Signup for a GitHub account www.github.com. Tell someone your username so they can add you to the appropriate SpectraQEST team
*Download and install Git from http://git-scm.com/download. Windows has two possible ways to run git: choose msysgit instead of Cygwin. When installing, choose all the options that they recommend for Windows development. Install again to something like “C:\Program Files (x86)\Git”.
**You will be prompted about line ending conversions at some point. Use the auto-convert option, I think it’s the first option. It should produce the line “autocrlf = true” in the default config: “C:\Program Files (x86)\Git\etc\gitconfig”.
*You can now:
**Run the Git console using Git Bash, a shortcut (quotes included): "C:\Program Files (x86)\Git\bin\sh.exe" --login –i
**Run Git GUI using this entire command (quotes included) in a shortcut: "C:\Program Files (x86)\Git\bin\wish.exe" "C:\Program Files (x86)\Git\libexec\git-core\git-gui"
**A shortcut for both of these should have been created in the Start Menu automatically.
*Your global Git configuration file “.gitconfig” is found under “C:\Users\Your.Name\.gitconfig”. Setup your username and email by using the following commands in Git Bash:
**git config --global user.name “Your name”
**git config --global user.email your.name@spectraqest.com
*Download and install KDiff3 (this will be used as the merge tool for changes that can’t be automatically merged. Can maybe make it work with WinMerge, but haven’t tried.) This can be installed to the default location, something like “C:\Program Files (x86)\KDiff3”.
*Setup Git to use KDiff3 and optionally Notepad++ as your editor instead of Vim by editing the global .gitconfig file. I find it easier to edit manually in Notepad++ than using the console. Here’s an example of a config file:
<nowiki>[core]
editor = "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession -noPlugin"
autocrlf = true
[user]
name = John Meegan
email = john.meegan@spectraqest.com
[merge]
tool = kdiff3
[mergetool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe
[diff]
tool = kdiff3
[difftool "kdiff3"]
path = c:/Program Files (x86)/KDiff3/kdiff3.exe</nowiki>
*Set up your public key: http://github.com/guides/providing-your-ssh-key . Note that the ~ directory in Git Bash corresponds to “C:\Users\Your.Name\”, so your SSH public key can be found in “C:\users\Your.Name\.ssh\id_rsa.pub” after you’ve generated it.
**By this point you will have a GitHub account and password, a private and public SSH key, and a password to access your private SSH key. This last password is just in case someone steals your computer, they cannot access your private key without a password. This prevents them from accessing anything you use your key for, such as GitHub, once you have added your public SSH key to GitHub.
*Make the folder “C:\dev\” on your C Drive for development work.
*Get a Git repository from GitHub via something like the following (note the URL comes from GitHub and changes depending on the project):
**cd /c/dev/
**git clone git@github.com:spectraqest/qestnet.upgrade.git
*That’s pretty much it. There are plenty of tools you can try out to assist with using Git if you wish. Two of the most popular are:
**GitHub for Windows: https://windows.github.com
**Atlassian SourceTree: http://www.sourcetreeapp.com/

== How to "git" started ==
===Understanding Git===
Even I’ve only seen the tip of the iceberg, but there are some major conceptual differences with both VSS and SVN that are worth knowing.
 
There’s a couple of good resources that I like:
*Git Magic - http://www-cs-students.stanford.edu/~blynn/gitmagic/
*HgInit - http://hginit.com/top/ (Really well written, but actually for Mercurial, not Git. But the products are so similar that I found this one really useful anyway).
*Stack Overflow - http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide (this question has a ton of links to other resources if you want them)
*Git Manual – you should be able to do “git help” from the command line to bring up the git manual.
The biggest difference between Git and VSS is VSS will create a local copy of a particular branch, but Git will create a copy of all of the branches as well as their entire histories. This means you can switch between them all without the server being involved. You can then change multiple branches and push all of them up to the server. You only ever “see” one branch at a time however, and switch between them using the “checkout” command. So instead of “checkin” and “checkout” going to and from the server, they are local commands. You then use push and fetch to go to and from the server. Google it, see the above links, or talk to one of us for more info.
===Command line vs. VS plugin===
Although there is a Git plugin for Visual Studio, I really don’t like it myself. Personally I think I’m getting along with Git much better with just the command line interface, which is faster in the long-run. So, once installed, I like to use “Git Bash” (available in the Start Menu). That opens up a Linux emulation, which I prefer because it has color-coding and shows your current branch etc; however, you can also run it directly from a Windows command line (assuming you installed Git with that option selected).
 
The main non-intuitive thing at first with Git Bash is that path names would be described like /c/dev/ and not “c:\dev\”.
===Hive in Git – Structure===
In theory, with only one version of the Hive ever live at a time, we should only need two branches: production (stable) and development. But for now, with the 0.7 and development branches so radically different, and 0.7 development still going on a bit, I’ve created independent branches for them both. We should be able to merge fairly easily between the branches anyway. If we need to later we might want to archive the 0.7 stuff away once we’re done with it. So, in short:
 
stable 
|-- dev 
|-- dev0.7 
 
Don’t ever work directly on the stable branch, for the obvious reason that it means you’re whacking new stuff directly into a branch that is supposed to be stable. Instead make your own branches under the dev branches as required and then, when you’re happy with it, merge it into the dev branches. More on the workflow later.
===App.config / web.config files===
As suggested by Lief a while ago, there’s also a better way to separate our app.config files, which I thought would go well with new source control. The technique is shown in the test-repository-net application on GitHub, though it’ll take a little bit of work to do it in Hive and I won’t worry about doing it in the 0.7 branch.
 
Basically, it allows us to store prod / test versions of configuration in source control, but allows our local development environment to use config that’s not in source control.
===How do I check out a file? (and branching)===
Two major points of difference with VSS here. One, individual files are not checked out, rather the entire tree is. Two, “checking out” really means switching to another branch. Though Git has a “checkout” command, it is not really like the VSS checkout at all.
 
Git is very big on branching, mainly because branching and merging are trivial in Git where they’re not in other SCMs. So you have not just the shared branches for separating stable and development code, but also you create them in your local repository to separate any particular line of work you might be following.
 
A branch is always on your entire working tree; in other words, any changes at all that you make while in the context of a branch apply to that branch. Making individual branches allows you to work on several different tasks at once without them interfering with each other. For example, a good approach is to have a separate branch for each issue that you’re working on. When you’re done working on the issue, you commit that whole branch.
 
Let’s say you’re working on a change to Program.cs, issue #5000. You might checkout a new branch just for working on that:
git branch 5000_program_fix
git checkout 5000_program_fix
(The above two commands can also be done with git checkout –b 5000_program_fix)
 
You start work on it, and modify Program.cs as you like. Suddenly, you’re told that issue #5055, a task to update the application readme.txt file, has to be done right away. So you commit your changes to the 5000_program_fix branch, and create a new branch for 5055_readme_fix.
notepad.exe Program.cs
git commit –a –m ‘Modified message on console main screen.’
git checkout –b 5055_readme_fix dev
(Note: if you don’t supply the starting point of master, the new branch (5055) will be created as a sub-branch of the current branch (5000), and will include all of the changes already committed for 5000.)
 
(Note 2: the “-a” in commit means “--all" and will automatically stage any changed files. See the git doco for more. It is not recommended unless you are sure you want all changed files included.)
 
You make the changes to the readme.txt and commit them.
notepad.exe readme.txt
git commit -a -m ‘Modified readme.txt with new instructions.’
Now you’ll find that you can switch between any of the three branches at will, and all of your work is separated correctly:
git checkout dev (contains neither the changes to Program.cs or readme.txt)
git checkout 5055_readme_fix (contains only the changes to the readme.txt)
git checkout 5000_program_fix (contains only the changes to Program.cs)
===How do I check in a file? (merging and pushing)===
Actually we sort of saw this in the previous question; we use git commit to “check in” a file to the current branch.
 
That’s not quite the end of the story though. For one, you’ve still got your changes in your own branch, like 5000_program_fix. So the first thing you should do once you’re happy with your fix is to merge it back into the development branch:
git checkout dev
git merge 5000_program_fix
If there are changes that can’t be automatically merged it should pop up the configured diff tool to let you do it manually. Otherwise, it just merges them in and automatically commits them (keeping your history of commits).
 
Remember, though, that this is all still occurring on your local repository; since you got the repository from GitHub, there’s been no communication at all with an external server. So, in order to put them back on the “central” repository:
git push origin dev
That will push all changes you’ve made to the dev branch up to the remote server.
 
Merging is a pretty common thing (just as common as branching really!). For example if a branch you’re working on needs a fix that you did in some other branch, just merge from that branch into the one you want.
===How do I see what I’ve changed?===
The easiest is to run Git Gui (or similar) and it will show you the changed files. If you want to use the console you can use:
git status
git status –u
See the manual for usage.
===Okay, but how do I see what’s changed in those files?===
In Git Gui, click on them. You can compare files in all sorts of ways, but most commonly may be between different branches, or different commits.
 
To view the differences in all of your uncommitted changes:
git diff
To view the differences in your uncommitted changes for a specific file:
git diff Program.cs
To view the differences between the master branch and the 5055 branch:
git diff master 5055_readme_fix
To view the differences between the current version and 2 commits ago:
git diff HEAD~2
There’s every other conceivable option you might need to compare too, those are just a very few basic ones.
 
You may also like to use the Git GUI for this, which provides a reasonably nice way of seeing complete file history of the entire repository – and generally much faster than SourceSafe does. Git GUI > Repository > Visualize … History.
 
Whoops, I made a mistake when committing! How do I undo it?
It’s quite alright to modify your own commits, since they still only exist in your own repository. The safest way is to use the reset command:
git reset --soft HEAD^
To explain: HEAD^ indicates that we should reset back to the state of the previous commit; if you wanted to go back two commits, you could use HEAD^^ or HEAD~2. The --soft reset means that the files themselves will not be modified, which is generally what you want; if you do a --hard reset instead, the files themselves will revert to the state they were in before you modified them, so only do that if you really want to throw away those changes.
 
After you’ve done a push it gets trickier because people may have pulled your mistake into their own repositories. In this case it’s generally recommended that you fix the mistake with another commit.
 
I need some cutting edge code that someone else is developing but which they haven’t pushed to the main repository. Can I get it?
Yes, you can pull from anyone’s repository, but I’m still working on the details of what’s required to allow our repositories to access each other. In the meantime, you could get the other person to push their branch up to the GitHub server and then you can pull from it.
===Where’s my Tools > Options menu?===
You have Git configuration options at the individual repository level, or at a global level (i.e. applies to all repositories). These are stored in configuration files, but are most easily accessible via the command line. For example to see all settings applying to the current repository:
git config --list
Or if you want to see just your global settings:
git config --list --global
Then if you want to change a setting, just issue the name and new value:
git config core.autocrlf true
Again, if you’re changing a global setting, use the --global parameter. Repository-level settings will override global ones I think.

===I’ve made a whole ton of commits, but it makes for a pretty messy history. Can I clean it all up?===
Yes, the easiest way is to use the rebase command. This usage is most well described here: http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks/2047707#2047707.
 
Also note Linus Torvalds’ recommendations with rebase, namely that you only rebase your own work: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html. Though product managers may want to clean up the code of their developers if absolutely necessary.

===Common Git Commands===
*git fetch – This will get the latest code from GitHub for all branches.
*git fetch <branchname> – The same but for a specific branch.
*git checkout <branchname> – Change to a specific branch on your local machine.
*git commit – Create a new commit on your local machine.
*git commit –a – Create a new commit on your local machine and automatically include all changed files. This will not add new files.
*git commit –m “message” – Create a new commit on your local machine and use the supplied message for it.
*git commit --amend – Change the message for the last commit you made.
*git push origin <branchname> – Push changes for a specific branch to GitHub.
*git rebase <target_branchname> – Rebase your currently checked out branch on top of the target branch.
*git rebase –i head~10 – Rebase the last 10 commits interactively. This lets you change commit messages, re-order commits, squash multiple commits together, etc.
*git merge -–ff-only <branchname> – A special type of merge just to update to more recent code.
*git mergetool – Run the merge tool any time a rebase or merge fails and it needs manually consolidating.

===Merge vs Rebase:===
<nowiki>
Merge joins 2 branches together:

A---B---C branch 2
/ \
D---E---F---G---H--- branch 1

Rebase (based on the above) applies the changes for one branch on top of another:

D---E---F---G---H---A---B---C--- branch 1, branch 2
</nowiki>

Because rebasing is destructive, this should not be done for code that has already been pushed up to GitHub. This is for reorganising commits on your local machine to make them nicer to push up.
 
This is most useful when you do a “git fetch” and discover someone else has pushed work up before you have. You then reapply your changes to the end of the history before pushing to GitHub.

==Git workflow==
*Checkout the development branch (e.g. alien) that the bug/change request will be added to.
**Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien or git fetch origin alien and git merge --ff-only origin/alien).
**Create a new branch using the bug/cr and some form of descriptor as the name (e.g. cr4321-tv-map or bug1234-tv-map-ucs).
**Checkout the new branch (git checkout cr4321-tv-map).
*Make regular commits to this branch as you are developing (git commit -a -m 'Commit message.').
**Once initial development is complete rebase the bug/cr branch to a single commit (git rebase -i origin/cr4321-tv-map).
**Review the files that you’ve changed, using git status and git diff to ensure there are no unexpected changes.
**The bug/cr branch can now be pushed to github for testing (git push origin cr4321-tv-map).
*The tester will fetch and checkout the cr/bug branch to test it and give feedback.
**At this point make any required changes on the branch. Commit and push to github so that the tester can re-test.
**Once all development is complete, checkout the development branch again (git checkout alien). Pull or fetch from github the latest of the branch and ensure that your local copy is at the head (git pull origin alien).
**Merge the bug/cr branch into the development branch, resolving any conflicts (git merge cr4321-tv-map).
**The development branch can now be pushed to github for integration testing (git push origin alien).
*The tester will fetch and checkout the development branch to test it and give feedback.
**Minor fixes required from integration testing can be made directly on the development branch. These should be no major problems but if there are the fixes should be made on the bug/cr branch and tested there first. This should be done with priority as the development branch may be "broken" until these changes are merged.
**Once integration testing is complete or if it is not required the bug/cr branch can be deleted locally and on github.