Using GIT for Dataflex Development: Difference between revisions
From DataFlex Wiki
Jump to navigationJump to search
Using GIT for Dataflex Development (view source)
Revision as of 12:48, 25 March 2020
, 25 March 2020Added to Tutorials category
Hsymington (talk | contribs) m (Added to Tutorials category) |
|||
| (15 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
== Why Version control == | == Why Version control == | ||
Before we jump into GIT in specific, it is important to mention some reasons why developers are more productive when using version control; | Before we jump into GIT in specific, it is important to mention some reasons why developers are more productive when using version control; | ||
* We can | * We can keep track of multiple versions deployed | ||
* Multiple developers can be working on same project | * Multiple developers can be working on same project | ||
* It is helpful with code checks for auditing or training | * It is helpful with code checks for auditing or training | ||
| Line 7: | Line 7: | ||
* We can locate changes for one feature/fix across a number of changed files | * We can locate changes for one feature/fix across a number of changed files | ||
* The code is in a safe location, in case of lost hardware | * The code is in a safe location, in case of lost hardware | ||
* We can find when a located bug introduced, so you can see what clients are effected | * We can find when a located bug was introduced, so you can see what clients are effected | ||
It can be tough when you are looking at a piece of code, not knowing when/how it’s used. But when you can run a version control tool, which shows exactly when those lines were added, by who and with what description, it makes it so much easier to decide what to do with that piece of unknown code, whether it’s retiring it, refactoring, documenting or just leave it as it is. | It can be tough when you are looking at a piece of code, not knowing when/how it’s used. But when you can run a version control tool, which shows exactly when those lines were added, by who and with what description, it makes it so much easier to decide what to do with that piece of unknown code, whether it’s retiring it, refactoring, documenting or just leave it as it is. | ||
Another good reason that warrants its own paragraph is when you are developing using Agile sprints/iterations. Oversimplified, you determine a list of features you or your team are going to implement in order of priority, but your iteration is timeboxed to eg 4 weeks. This means that after 4 weeks all approved and tested code stays in the product and the features that did not make it in full or are not fully tested and or approved, are to be taken out and used for the next sprint/iteration. This warrants for a good use of version control, where each feature can very | Another good reason that warrants its own paragraph is when you are developing using Agile sprints/iterations. Oversimplified, you determine a list of features you or your team are going to implement in order of priority, but your iteration is timeboxed to eg 4 weeks. This means that after 4 weeks all approved and tested code stays in the product and the features that did not make it in full or are not fully tested and or approved, are to be taken out and used for the next sprint/iteration. This warrants for a good use of version control, where each feature can very easily be isolated from the packaged software. | ||
=== Types of version control tools === | === Types of version control tools === | ||
Version control is a way of work, not a tool itself. There are many version control systems, some are more suitable for the VDF development cycle | Version control is a way of work, not a tool itself. There are many version control systems, some are more suitable for the VDF development cycle than others. We can identify the following types. | ||
Historically version control was done by directory backups e.g. by using zip and file naming. The result is very near identical copies. It also requires a lot of self discipline. | |||
Centralised version control has been very popular for years, where you have one centralised server and many remote clients. Examples are CVS, Subversion, Vault, Visual Source Safe and Team Foundation Server. These work very well when you are connected to the server. When not connected these are not giving much assistance. | Centralised version control has been very popular for years, where you have one centralised server and many remote clients. Examples are CVS, Subversion, Vault, Visual Source Safe and Team Foundation Server. These work very well when you are connected to the server. When not connected these are not giving much assistance. | ||
Distributed version control is the latest and most popular peer to peer version control tool. Examples are Mercurial (hg), GIT, BitKeeper etc. | Distributed version control is the latest and most popular peer to peer version control tool. Examples are Mercurial (hg), GIT, BitKeeper etc. | ||
This white paper focuses on the last category | This white paper focuses on the last category of distributed version control, with GIT in particular. | ||
If you are currently using a Centralised version control, you might be interested in the following list of major changes with the Distributed flavour; | If you are currently using a Centralised version control, you might be interested in the following list of major changes with the Distributed flavour; | ||
* No access to a server is required, the distributed VC has a local repository that gets synch’ed with a remote (central or peer to peer) repository when it can but can work fine on its own. | * No access to a server is required, the distributed VC has a local repository that gets synch’ed with a remote (central or peer to peer) repository when it can but can work fine on its own. | ||
* Each developer has | * Each developer has their own repository local to their working directory | ||
* No file checkout is required, just start changing the files | * No file checkout is required, just start changing the files | ||
* You can stage a number of files, so multiple files can be part of one commit (maintaining the relationship of the changes in the files) | * You can stage a number of files, so multiple files can be part of one commit (maintaining the relationship of the changes in the files) | ||
| Line 32: | Line 32: | ||
=== Download and install GIT-Gui === | === Download and install GIT-Gui === | ||
Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing | Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing 2.10.0 and about 30Mb in size). Install on your machine, I recommend keeping the installer suggested components, and suggested ‘Adjusting of PATH environment’. The latter helps when creating menu’s in DataFlex Studio. The ‘Configuring the line ending conversions’, leave for DF development as checkout as-is, commit as-is. | ||
=== Creating your first repository === | === Creating your first repository === | ||
Let’s create a GIT repository of the | Let’s create a GIT repository of the Dataflex example Order Entry workspace. This workspace always is clean when VDF is installed but in my case, full of test and other changed code after a while. Being able to go back to the original version seems like a good idea for a first repository. | ||
Start with navigate to and select the workspace directory then use the right click (short cut) menu, and select ‘Git Init Here’ as below. | Start with navigate to and select the workspace directory then use the right click (short cut) menu, and select ‘Git Init Here’ as below. | ||
| Line 66: | Line 66: | ||
We can teach GIT what files to ignore by placing a file called .gitignore in the workspace directory. The content of the file is; | We can teach GIT what files to ignore by placing a file called .gitignore in the workspace directory. The content of the file is; | ||
<nowiki> | <nowiki> | ||
#Exclude the following files for | #Exclude the following files for DataFlex Projects | ||
#################################### | #################################### | ||
programs/*.exe | programs/*.exe | ||
| Line 194: | Line 194: | ||
I inserted ‘Use for_all.pkg’ at the top of the SalesP.vw code and the code below just before the End_object of the oContainer1; | I inserted ‘Use for_all.pkg’ at the top of the SalesP.vw code and the code below just before the End_object of the oContainer1; | ||
< | <source lang="dataflex"> | ||
// This only works from VDF 17.0 where Refresh is also send to containers | // This only works from VDF 17.0 where Refresh is also send to containers | ||
Procedure Refresh Integer eMode | Procedure Refresh Integer eMode | ||
| Line 221: | Line 221: | ||
End_Procedure | End_Procedure | ||
End_Object | End_Object | ||
</ | </source> | ||
Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed. | Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed. | ||
| Line 298: | Line 298: | ||
Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code: | Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code: | ||
< | <source lang="dataflex"> | ||
// This only works from VDF 17.0 where Refresh is also send to containers | // This only works from VDF 17.0 where Refresh is also send to containers | ||
Procedure Refresh Integer eMode | Procedure Refresh Integer eMode | ||
| Line 311: | Line 311: | ||
Forward Send Refresh eMode | Forward Send Refresh eMode | ||
End_Procedure | End_Procedure | ||
</ | </source> | ||
Compile and confirm the code. | Compile and confirm the code. | ||
| Line 625: | Line 625: | ||
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics | |http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics | ||
|} | |} | ||
== Third party Git utilities == | |||
* [https://www.syntevo.com/smartgit/ SmartGit] | |||
* [https://github.com/nvie/gitflow Gitflow] | |||
* [https://gitforwindows.org/ Git for Windows] | |||
---- | ---- | ||
| Line 630: | Line 636: | ||
If you like this article, find issues or need more explanation on any of this, please send me an email. | If you like this article, find issues or need more explanation on any of this, please send me an email. | ||
My email is m dot kuipers at internode dot on dot net | My email is m dot kuipers at internode dot on dot net | ||
[[Category:How To]] | |||
[[Category:Tutorials]] | |||
