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
m (gender-neutral possessive pronoun ;-)) |
Hsymington (talk | contribs) m (Added to Tutorials category) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 9: | Line 9: | ||
* We can find when a located bug was 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 === | ||
| 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]] | |||
