DataFlex Wiki - User contributions [en]

Talk:Using GIT for Dataflex Development

2016-09-30T18:08:01Z

Sture:

Great article! But references to VDF and Visual DataFlex should omit the "Visual" part. Or maybe just add a note about it in the beginning. -Sture

Talk:Using GIT for Dataflex Development

2016-09-30T18:07:01Z

Sture:

Great article! But references to VDF and Visual DataFlex should omit the "Visual" part. -Sture

Talk:Using GIT for Dataflex Development

2016-09-30T18:05:54Z

Sture: Created page with "Great article! But references to VDF and Visual DataFlex should omit the "Visual" part."

Great article! But references to VDF and Visual DataFlex should omit the "Visual" part.

Using GIT for Dataflex Development

2016-09-30T17:59:44Z

Sture: /* Download and install GIT-Gui */

== 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* 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.
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 easy be isolated from the packaged software.

=== 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 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.
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 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;
* 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 its own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
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 ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Using GIT for Dataflex Development

2016-09-30T17:59:03Z

Sture: /* Download and install GIT-Gui */

== 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* 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.
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 easy be isolated from the packaged software.

=== 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 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.
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 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;
* 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 its own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
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 VDF Studio. The ‘Configuring the line ending conversions’, leave for VDF development as checkout as-is, commit as-is.

=== Creating your first repository ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Using GIT for Dataflex Development

2016-09-30T17:54:23Z

Sture: /* Types of version control tools */

== 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* 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.
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 easy be isolated from the packaged software.

=== 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 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.
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 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;
* 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 its own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing 1.8.0 and about 15Mb 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 VDF Studio. The ‘Configuring the line ending conversions’, leave for VDF development as checkout as-is, commit as-is.

=== Creating your first repository ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Using GIT for Dataflex Development

2016-09-30T17:52:48Z

Sture: /* Types of version control tools */

== 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* 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.
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 easy be isolated from the packaged software.

=== 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 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.
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 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;
* 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 his own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing 1.8.0 and about 15Mb 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 VDF Studio. The ‘Configuring the line ending conversions’, leave for VDF development as checkout as-is, commit as-is.

=== Creating your first repository ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Using GIT for Dataflex Development

2016-09-30T17:50:12Z

Sture: /* Types of version control tools */

== 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* 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.
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 easy be isolated from the packaged software.

=== 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 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.
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 the 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;
* 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 its own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing 1.8.0 and about 15Mb 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 VDF Studio. The ‘Configuring the line ending conversions’, leave for VDF development as checkout as-is, commit as-is.

=== Creating your first repository ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Using GIT for Dataflex Development

2016-09-30T17:44:31Z

Sture: /* 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* 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.
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 easy be isolated from the packaged software.

=== 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 then others. We can identify the following types.
Historical version control was done by directory backups e.g. by using zip and file naming. The result is many 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.
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 the 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;
* 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 its own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing 1.8.0 and about 15Mb 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 VDF Studio. The ‘Configuring the line ending conversions’, leave for VDF development as checkout as-is, commit as-is.

=== Creating your first repository ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Using GIT for Dataflex Development

2016-09-30T17:42:56Z

Sture: /* 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;
* We can keep track of multiple versions deployed
* Multiple developers can be working on same project
* It is helpful with code checks for auditing or training
* A proper change log of each change is maintained
* 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
* We can find when a located bug 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.
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 easy be isolated from the packaged software.

=== 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 then others. We can identify the following types.
Historical version control was done by directory backups e.g. by using zip and file naming. The result is many 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.
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 the 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;
* 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 its own repository local to their working directory
* 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 optionally stage only a couple of changed lines in a file (if more changes are made then you want to stage).
* You commit the staged changes with a comment
* You push and pull changes between the local and remote repositories
* Branching used to be hard and therefore hardly used. Now really simple.
* But commit is local, so developers have to do a push to remote to make the change visible for other developers to do a clone/pull from remote

== Installing and using GIT ==
Enough theory, we’ll now show how it’s done. GIT is very small and easy to uninstall later if you decide to do so, therefore I strongly suggest you just follow these steps and perform these yourself while reading this white paper.

=== Download and install GIT-Gui ===
Navigate your browser to http://git-scm.com/downloads and download the latest windows version (at time of writing 1.8.0 and about 15Mb 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 VDF Studio. The ‘Configuring the line ending conversions’, leave for VDF development as checkout as-is, commit as-is.

=== Creating your first repository ===
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.

[[File:UsingGitforVdfDev_image001.png]]

The Git Init takes about a second. In this second it initialised a local repository in this work directory. You find that a subsequent right mouse click on the same directory now shows a different short cut menu;

[[File:UsingGitforVdfDev_image002.png]]
Inside the Order Entry directory you see a new hidden directory ‘.git’. This directory contains the whole local repository. So if you would delete this, the repository is gone.

Although the repository is created, it has not added any of our files. For this to happen we need to stage the files and then commit. We do this in the following steps;

Go back to the workspace directory and select ‘Git Gui’ from the shortcut menu on the Order Entry directory.

[[File:UsingGitforVdfDev_image003.png]]

Git Gui will start like below

[[File:UsingGitforVdfDev_image004.png]]

Panel 1 shows all files that are detected to differ from the repository. As the repository is empty, this means this list contains all files. Clicking on a file name (not the icon) shows in panel 3 the changes compared with the repository version

Panel 2 has the files that you have indicated you want to stage for commit. Clicking on the icon of a file in Panel 1, shifts the file from Panel 1 ‘Unstaged Changes’ to panel 2 ‘Staged Changes’.

If this starts to sound all too complicated bare with me, it is really not that hard and there are very good reasons for doing the staging this way

When you look at the files in Panel 1, the Unstaged Changes, you find that it has a number of files you do not want to track such as IDESrc/Workspace.loc, possibly files in the data directory etc.

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>
#Exclude the following files for DataFlex Projects
####################################
programs/*.exe
programs/*.dbg
programs/*.exe.manifest
programs/webapp.log
appsrc/*.dep
appsrc/*.fld
appsrc/*.pbg
appsrc/*.pdp
appsrc/*.pkd
appsrc/*.prp
appsrc/*.err
data/*.cch
ddsrc/*.bak
idesrc/studiometadata.mtd
idesrc/workspace.loc

vssver2.scc
nppbackup

#personal preference
####################################
appsrc/*.prn
idesrc/*.dsk
</nowiki>

So create this file in notepad, insert the above content and save with filename’.gitignore’ as sibling next to the ‘Order Entry.sws’ file.

If you kept Git Gui open, use the ‘Rescan’ button (or F5 key) and confirm that the unwanted files are no longer shown in the list of Unstaged changes.

Ok, now it’s time to stage all not to be ignored files. You can either select each file in Panel 1, by clicking its icon, use the shift key to select multiple and use Ctrl+T Stage to commit, or click ‘Stage changed’ button (that I marked with ‘A’ in the screenshot).

Now enter the Initial Commit Message like ‘VDF 17.0 Order entry sample as released by Data Access’. And click the ‘Commit’ button (marked with ‘B’ in my screenshot).

You noticed that the commit was really quick, and all panels are blank. You have just created a new repository, told GIT what files to ignore, and committed all other files into the repository.

=== Setting up the author in GIT ===
When you commit, GIT keeps track of not only the changes, but also of the Author of the changes. In the above initial commit, we did not set this and as DAW is the author this did not really matter, but changed from now on, should have yourself as the author.

To set the Author select menu Edit – Options.

[[File:UsingGitforVdfDev_image005.png]]

As you can see there are many settings you can do. For now just set the Username and email address as indicated below with the arrows.

[[File:UsingGitforVdfDev_image006.png]]

== Using git ==

=== Making changes and revert back ===
We have our safe initial commit so we can make changes to our hearts content.

Open the Order Entry.sws. Let’s say you want to add the container3D around the objects in the customer view to make it consistent with the other views in this workspace. So I selected in the Design view the Customer Number and Name form, as well as the dbTabDialog. Did Cut, dragged a Container3D from the palette, made it big enough, Pasted the objects back in (while Container3D was selected) and resized the container holding CTRL key to make sure it does not resize the objects. Then I compiled the projects and confirmed all was working.

Notice that I did NOT have to checkout any files!

So when happy with the changes, switch back to Git Gui (Alt+Tab if you leave it running), and do a Rescan by clicking on the button or F5.

Two files are loaded in the Unstaged Changes. As you select the filename you see the changed lines in the third panel.

In this example we have no interest in committing any changes and basically want to lose all uncommitted changes.

From the menu select Branch-Reset. A warning dialog will indicate that you indeed will lose all uncommitted changes. Select Yes.

Switch back to VDF Studio and notice that the customer view is back to what it was.

Now hold-on you might say, why is this in the branch menu, I would not have looked there... When we look a bit further at branching I promise it will make more sense. If impatience; the short answer is that the master is also a branch.

=== Creating a branch and making changes ===
As a developer you should not create changes direct in the master branch. Instead you should create a branch specific to the change you want to make (topic branch), and then when you decide to keep the change, merge the topic branch into the master (or even better in a release branch).

There are two methods of organising the topic branches. The first way is as sibblings, the other way is consecutive. This document starts with the sibbling way.

Let’s create a new branch; switch back to Git gui and select menu: branch – create to open the following dialog;

[[File:UsingGitforVdfDev_image007.png]]

I’ve entered a branch name. Notice that the dialog does not allow you to insert spaces, so use Mixed case notation. Use a naming that refers to an ID in your change request system so use something like “CR5612_UpdateFontsOnReports “.

Notice that the starting revision is ‘master’ but don’t worry about this too much, otherwise you might think it’s more complex than it is.

So click on Create after you entered the name. The dialog changes and all you are left in is the message above the Unstaged Changes panel showing the current branch.

[[File:UsingGitforVdfDev_image008.png]]

Make some changes like commenting out the Crystal reports to save compile time (Includes and menu’s). And replace in CustomerListWP.rv the ‘arial’ font to ‘Segoe UI’.

Compile the project and see how much better the report looks.

Switch back to Git Gui and do a Rescan.

[[File:UsingGitforVdfDev_image009.png]]

You see the three changed files, and at the right the line old and new line.

Let’s assume that this is all the change you want to do for now. The work is not fully done, as you want to change the font on all the reports, but need to attend to another change you want in your project.

So you stage and commit these changes into this branch. Click ‘Stage Changed’ button (or Ctrl+I), enter a commit message eg ‘Changed first report and removed crystal reports’. Click ‘Commit’ (or Ctrl+Enter).

The next change you want to make is not related to the above change. So you create a new topic branch. You’ll soon found that for each individual programming request you want to create an own topic branch.

But take care when creating the new branch; you want to create this from the master. So in the create branch dialog (Menu Branch-Create), you want to select the master as the Starting revision local branch;

[[File:UsingGitforVdfDev_image010.png]]

''I use the name ‘Topic branch’. This is not a name used in GIT itself, but it is used in the GIT documentation to refer to a branch created for the purpose of creating, updating or removal of a specific feature.''

[[File:UsingGitforVdfDev_image011.png]]

Hovering over the branch names shows some information regarding the branch, which for the sake of this document highlighted in a green box.

When you click create, you see that the Current Branch is changed to the newly created one.

[[File:UsingGitforVdfDev_image012.png]]

As you selected the master to be the starting revision, you will also find that when switching back to the VDF Studio, the state of source code is back to what it was when we committed the master. This might worry you but this is a good thing.

Please confirm that the Crystal reports are back and the font is also back to arial.

''If you made a mistake and did not base the new branch on master, just switch away from the new branch with Branch-Checkout and select master. Then do menu Branch-delete and select the wrongly created branch. Once deleted create the new branch again, but this time based on the master.''

Make a change like adding the Total sales to the Sales Person entry view. In this revision we just calculate on the spot, but we might later add a field for it;

[[File:UsingGitforVdfDev_image013.png]]

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;

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Send CalculateTotalSales to oTotalSalesForm
End_Procedure

Object oTotalSalesForm is a Form
Set Size to 13 44
Set Location to 4 182
Set Form_Datatype to Mask_Currency_Window
Set Enabled_State to False
Set Form_Mask to "$,0."
Set Label to 'Total sales:'
Set Label_Col_Offset to 2
Set Label_Justification_Mode to jMode_Right

Procedure CalculateTotalSales
Number nTotalSales
Open OrderHea
For_All OrderHea by 0
Constrain OrderHea Relates to SalesP
do
Add OrderHea.Order_Total to nTotalSales
End_For_All
Set Value to nTotalSales
End_Procedure
End_Object
</nowiki>

Switch back to Git Gui and do a rescan (F5). You see that SalesP.vw and probably order.cfg are changed.

If you are happy with the changes, then Stage and commit them.

=== Merge branches ===
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers.

We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master.

Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M.

[[File:UsingGitforVdfDev_image014.png]]

Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one.

Git has a fantastic build in 3 way merge, illustrated in the image on the right.

However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this;

[[File:UsingGitforVdfDev_image015.png]]

[[File:UsingGitforVdfDev_image016.png]]

Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text.

[[File:UsingGitforVdfDev_image017.png]]

The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’.

Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here.

In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this.

In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options:

# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent)

Whatever your choice of addressing the merge conflict, you stage and commit the version to keep.

Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch.

The test version is ready for... testing.

''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.''

=== Further changes required on one of the change requests ===

As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown.

It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related.

So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout.

[[File:UsingGitforVdfDev_image018.png]]

If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on.

[[File:UsingGitforVdfDev_image019.png]]

So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset.

So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit.

This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit.

Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout.

Confirm that the current branch switched;

[[File:UsingGitforVdfDev_image020.png]]

Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code:

<nowiki>
// This only works from VDF 17.0 where Refresh is also send to containers
Procedure Refresh Integer eMode
Handle hoServer
Boolean bHasRecord

Get Server to hoServer
Get HasRecord of hoServer to bHasRecord
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm
Set Visible_State of oTotalSalesForm to (bHasRecord)

Forward Send Refresh eMode
End_Procedure
</nowiki>

Compile and confirm the code.

To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change.

We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’

We change branch by Checkout of the PlayWithWinPrintReports and make out changes there.

When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in.

You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could.

=== Branching – Merging wrap-up ===

I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not.

You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch.

== Using GIT during developing & a centralised VCS for releases ==

You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature.

You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards.

I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS.

== Multiple developers, multiple repositories ==

In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository.

More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories.

=== Create a remote backup repository ===

To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter.

In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention.

[[File:UsingGitforVdfDev image021.png]]

Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add.

'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.'''

What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory.

After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P);

[[File:UsingGitforVdfDev image022.png]]

By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated.

Please note that you are pushing the whole history of commits, not just the latest state.

== Creating a local repository from a remote repository ==

So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository.

In Git terminology you want to clone an existing repository.

''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.''

Start Git Gui from start menu or by right mouse click on any directory that does not have a repository.

[[File:UsingGitforVdfDev image023.png]]

Click the Clone existing repository link.

[[File:UsingGitforVdfDev image024.png]]

Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace.

Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work.

When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’.

''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.''

=== Keeping multiple repositories synchronised ===

In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote.

We also discussed that a remote repository can be kept up-to-date with Push.

Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes.

For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch.

When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository.

This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push.

=== Local and Remote branches ===

Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share.

If you do want to collaborate on a branch, you explicitly push the branch to the remote.

When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch.

The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch.
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source

[[File:UsingGitforVdfDev image025.png]]

So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’.

So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch.

=== Collaborating on a topic branches ===
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project]

== Browse repository ==

=== Gitk ===

Git-gui comes with a basic visualising tool gitk. It shows the commit and branch history, and the files and lines changed in these commits. It has some search facility in commit messages.

This visual commit viewer is started from git-gui by the repository menu options ‘Visualise <current branch> History’ and ‘Visualise All Branch History’.

[[File:UsingGitforVdfDev image026.png]]

This does the job most of the time. But to get the most out of your carefully build version control documentation, you should have a look at git extensions. You can use git extensions exclusively, meaning you do not need any functionality of git-gui. For learning the basics of git, I believe that git-gui is an excellent way and not get lost straight away in the functionality of git extensions.

=== Git extensions ===

Git extensions is an active open source project. The source code is here https://github.com/gitextensions/gitextensions

However the latest version, wrapped in a windows installer is here http://code.google.com/p/gitextensions/ this is most likely the version you want.

It comes with a manual, that should after reading this document, be quite easy to follow. Especially chapter 3 browse repository is really good.

==== View commit log ====

In addition to seeing commit changes just like in gitk, you can also ctrl click any two commits to view the differences.

[[File:UsingGitforVdfDev image027.png]]

==== Search history ====

Using regular expressions in commit message, author and committer.

[[File:UsingGitforVdfDev image028.png]]

==== Single file history ====

[[File:UsingGitforVdfDev image029.png]]

==== Blame ====

See for every line, when this was committed. Then double click to see other files of that commit.

[[File:UsingGitforVdfDev image030.png]]

== Tips and Tricks ==

=== Unmodifying a modified file ===

When you realise you don’t want to keep any changes to a file, you can unmodify it – reverting to what it looked like when you last committed (or cloned or merged etc).

In Git Extensions this can be done several ways. One of them is in the commit dialog;

[[File:UsingGitforVdfDev image031.png]]

[[File:UsingGitforVdfDev image032.png]]

=== Renaming of a file ===

GIT is really smart. If you rename a file, it detects that a file is missing, a new file appeared and the content is (almost) the same. It just picks it up and accepts the rename of the file as a change you can commit.

Extremely cool!

=== Libraries used by multiple workspaces ===

A great way to have copy of a VDF library workspace within every workspace that uses the library, while the version control helps you detect changes and merge them into the ‘local’ library.

More details are here; [http://git-scm.com/book/en/Git-Tools-Submodules]

=== Unstage Line from Commit ===

Sometimes you might have done a number of changes to a file and forgot to commit these separately, while you would like to.

In that case just stage the file, click on the file in the second panel, then in the 3rd panel where you see your code select the lines and use right mouse click to Unstage lines from commit. You could also select stage specific lines when you have not staged the file.

''If you cannot select the file, it just switches from Unstaged to Staged, you've click the file icon, instead of the name. Click the name instead.''

=== Cherry picking ===

Apply a commit from another branch to the current branch. Only the lines changed in the particular commit will be applied.

This is the best way to apply e.g. a bug fix, made in the master branch, onto the development branches. Or if doing consecutive commits, in a development branch you only want to pick some to be updated in this new branch.

=== Keep uncommitted changes when changing branch (Stash) ===

Git protects you from loosing uncommitted changes to your files when changing branches. But sometimes you are just not ready yet to commit. You might be in the middle of some programming that is not ready to compile, while you need to attend to an urgent bug.

This function is not (yet?) in Git Gui, but is very handy. You will however find it in git extensions.

Alternatively in the command line (right mouse cick on workspace directory, select Git Bash. A command window opens. Run the commands ‘Git add .’ and ;Git stash’.

You notice that all changes are ‘removed’ from the working directory and you can checkout another branch. To retrieve the content of the stash, go back to the original branch and do a ‘git stash pop’

Then just change the branch to where you need to be working on.

=== Global .gitignore file ===

If you are sick and tired to add the .gitignore file every time in each new workspace, you can create a global ignore file. This drawback is that this is global for all projects, not just VDF projects. This only goes up if you use GIT also for other files where you do want to track some of these files.

In your user data directory you find your settings in a file called ‘.gitconfig’. Create another file in this directory with the name ‘.gitignore_global’, then update the .gitconfig file to add the excludes file reference as follows;

<nowiki>
...
[core]
excludesfile = c:/Users/Marco/.gitignore_global
...
</nowiki>

You can also add this using the command interface and the command

<code> git config --global core.excludesfile ~/.gitignore_global </code>

''If you are trying to rename eg .gitignore to .gitignore_global windows will bark at you as it sees the file as no name, only extension. If you however rename to .gitignore_global. (with an extra . at the end) it will bypass the validation and rename the file properly.''

=== Setup a different merge and diff tool ===

You can select almost any merge or diff tool.

However the 3 way merge in beyond compare is a version only available in the Pro version. I would focus on getting to know git first.

Channing the merge and diff tool, is easiest using a Git Extensions dialog;

[[File:UsingGitforVdfDev_image033.png]]

[[File:UsingGitforVdfDev_image034.png]]

After this setting, eg in file history you can use this;

[[File:UsingGitforVdfDev_image035.png]]

The panel of the commit changes will not be changed.

=== Loose objects warning ===

This warning can be really annoying and the check and possible warninig is fired each time that you start Git-gui. To stop the warning, start the Git Bash from your start menu.

[[File:UsingGitforVdfDev_image036.png]]

Then type the following line and press enter

[[File:UsingGitforVdfDev_image037.png]]

<code> git config --global gui.gcwarning false </code>

Then close the git bash and the check/warning is gone.

=== Committing PRN files, but exclude from viewing diff ===

Earlier we suggested to add the PRN file to the list of ignored files. However it could be interesting for line numbers of user reported errors. When you do not exclude the PRN, you might find that expecially a larger file with slow down the show difference when clicked by accident.

One trick you can do, is to tell git that a .prn file is a binary file. In that case it will not show any differences, just that they differ. This way you can stage and check in the file, and this retrieve later when required.

Create in your work directory a file with the name ‘.gitattributes’ and content ‘*.prn binary’.

=== Renaming of a remote ===

If you want to rename the alias of a remote you can issue the following command

<code> git remote rename <currentName> <newName> </code>

=== Tagging ===

You can like most Version control tools, tag specific points in history. Generaly this is used to mark release points (v1.0 etc).

To create an annotated tag (so all information is stored), use the following command:

<code> git tag –a <tagName> -m <tagMessage> </code>

''If you forgot to place the tag and done some work already after, you can still tag that point in time. Have a look at Tagging on [http://git-scm.com/book/en/Git-Basics-Tagging]
''
=== Removing a Recent Repository from git gui start screen ===

When git gui is started from a directory that does not contain a repository, it will show create/clone/open options as well as 'Open Recent Repositories'.
These are loaded from the global .gitconfig file.

In my case this is on windows 7 and logged in as marcok; C:\Users\marcok\.gitconfig
You can remove the recentrepo entries that you no longer wish to have in this list.

Rather than directly changing the text file you can also use the git bash line:

<code>git config --global --unset gui.recentrepo "C:/work/VisualLMS"</code>

== Further reading or reference material ==

{|
|Git reference; an easy to read quick reference. Although it focuses on the commands (using command line), it makes the dialogs in Git Gui easy to understand what the options mean.
|http://gitref.org/index.html
|-
|A beginner tutorial, most of the content is covered in this white page.
|http://matthew-brett.github.com/pydagogue/git_gui_windows.html
|-
|Pro Git book
|http://git-scm.com/book
|-
|DataAccess Blog: Configuring Source Control for Visual DataFlex
|http://support.dataaccess.com/Forums/entry.php?116-Configuring-Source-Control-for-Visual-DataFlex
|-
|DataAccess Blog: Source Control and Visual DataFlex 101: The Basics
|http://support.dataaccess.com/Forums/entry.php?117-Source-Control-and-Visual-DataFlex-102-Multi-Developer-Use
|-
|DataAccess Blog: Source Control and Visual DataFlex 102: Multi-Developer Use
|http://support.dataaccess.com/Forums/entry.php?92-Source-Control-and-Visual-DataFlex-101-The-Basics
|}

----

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

Portal:Development Tools

2007-12-31T10:19:31Z

Sture: /* Dataflex Libraries */

For any Dataflex Developer there are a range of tools useful for many situations.

==Data Access Tools==
[[Data Access]] provide a core of development tools vital to Dataflex development.
*[[Visual DataFlex Studio]]
*[[Database Builder]]
*[[Database Explorer]]

==Third Party Development Environments==
Other tools have been developed by the dataflex community over the years. These tools frequently take inspiration from the larger development community and often preview features which eventually make it into the official VDF Studio.
*[[Eclipse]]
*[[The Hammer]]

==Dataflex Libraries==
*[[VDFQuery]]
*[[StarZen's Wizard]]
*[[StarZen's Date form control]]

==Other Tools==
*[[Version Control]]
*[[File Comparison]]
*[[Text Editors]]

[[Category:Development Tools]]

VDFQuery

2007-12-06T18:13:10Z

Sture:

VDFQuery is a collection of general-purpose packages that has been available since 1997. As the name implies, its main attraction is an ad hoc query tool for VDF Windows applications.

The general purpose packages are mainly in the form of global functions, most notably for date manipulation, string manipulation and sequential input/output.

The packages are authored mainly by Sture Andersen but over the versions many developers have contributed bug fixes and extensions, which has led to a fairly stable code base.

The download is free for all to use. It is available from the ftp server of DAW in a number of versions. You may need to browse through the readme files to identify the best version for your version of VDF.

[ftp://ftp.dataaccess.com/pub/products/vdf/Software/VDFQuery/ link to download]

VDFQuery

2007-12-06T18:05:20Z

Sture:

VDFQuery is a collection of general-purpose packages that has been available since 1997. As the name implies, its main attraction is an ad hoc query tool for VDF Windows applications.

The general purpose packages are mainly in the form of global functions, most notably for date manipulation, string manipulation and sequential input/output.

The packages are authored mainly by Sture Andersen but over the versions many developers have contributed bug fixes and extensions, which has led to a fairly stable code base.

The download is free for all to use. It is available from the ftp server of DAW in a number of versions. You may need to browse through the readme files to identify the best version for your version of VDF.

Here is the link ftp://ftp.dataaccess.com/pub/products/vdf/Software/VDFQuery/

Talk:Main Page

2007-12-06T17:18:22Z

Sture: /* Backups */

= What would you like to see on this wiki? =

Feel free to discuss the purpose of this wiki on this page. You are also welcome to provide feedback on how you want this site to interact with other resources (e.g the newsgroups and vdf-guidance.com) --[[User:Jka|Jka]] 23:35, 25 November 2007 (CET)

== Overall goal ==

I think VdfWiki should be a place assemble knowledge and articles in the long term (in a structured manner).

There are some guidelines for keeping VdfWiki on the right track :[[VdfWiki_guidelines]]

The newsgroups are still '''THE''' place to ask question and chat about current events.--[[User:Jka|Jka]] 08:28, 23 November 2007 (CET)

==Wiki Structure Proposal==
I ([[User:Mikepeat|Mike]]) have just modifed the sidebar (the panel on the left of every page) to add "sections". (If any Sysop is not happy with this then it can be undone by editing the page [[MediaWiki:Sidebar]], or by just reverting my changes to it.) I have used the sections as currently laid out on the main page, but I would like to propose a significant restructuring of those sections. I will take no action until there has been reasonable discussion of it here and a consensus reached however.

=== Overall structure (from Mike)===
I would propose something like the following overall structure:

* <big>'''Main Page'''</big> (Brief Product Overview)
** Product Detail
** '''Windows'''
*** CodeJock
*** OLE/COM/ActiveX
*** Reporting
** '''Web'''
*** AJAX
*** JavaScript
** '''Character Mode'''
*** DOS/Console Mode
*** Unix/Linux
** '''Web Services'''
*** SOA
** '''Databases'''
*** Embedded
*** MS SQL Server
*** Oracle
*** IBM DB/2
*** Pervasive
*** MySQL
*** ODBC

(All comments and abuse will be gratefully received! [[Image:Smile-tpvgames.gif|20px]])

--[[User:Mikepeat|Mike]] 02:46, 21 November 2007 (CET)

::I agree, the current structure on the main page isn't clear enough at the moment. [[User:Hellboy1975|Hellboy1975]] 05:37, 21 November 2007 (CET)

::: Marco here... I agree too. I'd like to add some gotcha's about moving from DataFlex tables to DB2, accessed from DF32 on Linux and VDF on Win32.

=== Data Dictionaries ===
::: I also want to add a topic on batch create/update/delete using DataDictionaries. Where would that live? Would it be a topic referenced from Web and Windows and Webservices, or should this be another section, 'Data Dictionaries'?
::: I think a section about 'Data Dictionaries' could be great. I'll just add one (also containing the Databases' links from Mike --[[User:Jka|Jka]] 10:16, 25 November 2007 (CET)

=== Suggestion for topic (Development Tools)===

Can I suggest that we add a new section or link on the main page for general development tools and articles that sit outside of the existing Web/Windows/WS/Console categories. [[User:Hellboy1975|Hellboy1975]] 00:07, 23 November 2007 (CET)

:Sounds perfectly sensible to me... "Other" as a general catch-all, or "Other Tools": a bit more specific, but then we might have issues with things that fell outside that ''and'' our existing sections. --[[User:Mikepeat|Mike]] 00:14, 23 November 2007 (CET)

:: I am OK with a "tools" section. We can still lay down the law in that page :P The trick is to create a separate page for each tool we want to describe - and keep the external links down to a minimum (this should make it easier to keep track of the content on the page). I think the title "Development tools" could work. articles not related to these sections can be attached to a specific user page - we should try not to clutter the frontpage and 1st level navigation too much. --[[User:Jka|Jka]] 08:15, 23 November 2007 (CET)

== Discussing cookbooks ==

::That structure looks reasonable. My original idea with the "cookbooks" was to put a list of howto-do-stuffs in there. E.g a list of recipes in them - and have the "other" page contain the description. E.g "Windows" contains the description and "Windows cookbook" contains the recipes. I've found that the early contributions have been about "howto do stuff" (e.g something that should go in the cookbook). I can see now , that there should be no distinction between e.g "Windows" and "Windows cookbook" - they should be the same page. --[[User:Jka|Jka]] 09:38, 21 November 2007 (CET)

:::On the "''cookbooks''" issue... perhaps using "Categories" might be a help. This is not a subject I understand well enough (yet!), but it seems to me that it might add a multi-dimentional element to how articles are arranged and accessed, so that they can be come at from more than one direction (don't know how yet - research needed!). I think the original idea had merit - that some articles will be of a "howto" nature while others will be more descriptive, others discursive and still others umm... complaining (whining? - "''why don't DAW do more with the Linux product?''" <g>). In a big Wiki like Wikipedia, searching is usually the only way to start, but with our rather less ambitious subject matter, good organisation might lead people quickly to what they need (even if they didn't know they needed it and didn't know it was there). --[[User:Mikepeat|Mike]] 11:12, 21 November 2007 (CET)

::Yes . The need for having a "cookbook" can be adressed by having a category for all the different recipees. I think we should proceed in this direction . I removed the cookbook links from the frontpage and the navigation. --[[User:Jka|Jka]] 20:12, 21 November 2007 (CET)

==Style Guide?==
At the suggestion of [[User:Hellboy1975|Hellboy1975]] (what is that all about anyway, Matt? <g>) - see [[Talk:Web_Service_Basics]] - I have been changing the colour I am using to emphasise stuff - in this case (for now anyway) changing blue to midnightblue to avoid confusion with hypertext links (I'm not sure that is enough - I think I've just made that text look like visited links).

However it would have saved me this effort if I'd had a guideline on what colours etc. to use from the start. I think we need to evolve some kind of consensus "Style Guide" which would help us all use a nice, clear, consistent style for various things. It would be bound to be an evolving document, as we are unlikely to think of everything on day one and will have to be flexible and inclusive rather than prescriptive, but the sooner we start laying it down, the less time will be wasted later fixing stuff up that doesn't match or looks ugly. (''I did experiment with using a template - [[Template:Colorise]] - but couldn't get what I wanted to work: the amount of time I can afford to devote to learning the WikiMedia Template [http://en.wikipedia.org/wiki/Domain-specific_programming_language DSL] is strictly limited!'' <g>) [[User:Mikepeat|Mike]] 11:03, 22 November 2007 (CET)
:I should have said ''proscriptive'' above - it would indeed be ''prescriptive'', by intent! [[User:Mikepeat|Mike]] 14:54, 22 November 2007 (CET)
:Something like the Wikipedia [http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style Manual of Style] is always a good place to start. Another place to look for examples are in some of the programming manuals on Wikibooks. Here's one of the pages in the C++ manual for instance. [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Variables] [[User:Hellboy1975|Hellboy1975]] 00:20, 23 November 2007 (CET)

==Opensource/community libraries==

I understand that there is a [[Data Access Worldwide|DAW]] community site in the works. please consider this when describing available available [[Open Source]] [[Visual DataFlex]] libraries. --[[User:Jka|Jka]] 00:49, 1 December 2007 (CET)

== Main Page ==

I'm sure you've all noticed by now I've made a bit of a change to the front page. It's more or less the same as before, just with a bit more information for users who are a bit new to the whole wiki thing. What do you guys think? [[User:Hellboy1975|Hellboy1975]] 05:21, 5 December 2007 (CET)

:Looks good Matt... you might consider mentioning [[Special:Categories]] in addition to the [[Category Index]], and maybe adding the [[Category Index]] to the "navigation" pane (edit [[MediaWiki:Sidebar]]). ...And be careful who you say doesn't bite: '''''I''''' haven't had any coffee yet! [[Image:Smile.gif]]

:I think we probably need a single person (oops: that would be you... ''sucker!'' You have only yourself to blame!) to head-up work on structure, accessibility, cross-indexing and the like. We have made a big step forward with Categories, giving us the three tools you mention: Structure, Search and Categories... ''now'' let's talk '''''namespaces!'''''

::Given that [[User:Hellboy1975|Matt]] has proclaimed himself 'category enforcer' - then I think he could lead the overall structure on the wiki ;) --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

:::That's fine, I'm happy to take on the roll of structuring the site for now. My first goal is to make the main page a bit more accessable, and then each of the main categories (Web, Windows, Character Mode, DD's and Development Tools). I guess my plan with these pages at the moment is to make the more structures, in much the same way as the Main Page on Wikipedia [[User:Hellboy1975|Hellboy1975]] 00:25, 6 December 2007 (CET)
::::Take a look at [[Main_Page_1]] for a preview [[User:Hellboy1975|Hellboy1975]] 01:53, 6 December 2007 (CET)

:::::Like it Matt! ''Very'' nice. Keep up the good work! --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET)
:::::Awesome effort :) You rock --[[User:Jka|Jka]] 10:06, 6 December 2007 (CET)
:::::So... when are you going to make that live? I can't believe anybody is going to think we should ''not'' go with it... it is just a question of fleshing out some of those "wanted" links first IMO. --[[User:Mikepeat|Mike]] 10:22, 6 December 2007 (CET)
::::::Still got a couple of little things I want to do, mainly including some more info from the original main page. All things going well sometime tomorrow or over the weekend. [[User:Hellboy1975|Hellboy1975]] 13:08, 6 December 2007 (CET)

:Actually, namespaces require modification of the LocalSettings.php file on the server I think, so adding them is non-trivial (i.e. down to somebody with OS access to the server: Jacob, Johan or Sture, etc.) and thus they are a blunter and less flexible tool than Categories, but worth thinking about, in a background sort of way.

::Let's do some experimenting with namespaces when we have a backup copy of VDFWiki running on a separate machine. --[[User:Jka|Jka]] 10:10, 6 December 2007 (CET)

==Backups==
(Seem to have spawned a different thread here, so... [[Image:Smile.jpg]] --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET))

I have two other MediaWikis set up that I can play/practice on (but they are hosted on ''real'' operating systems [[Image:Smile.gif]]), and if you are going to do that stuff I suggest you set one up for yourself, if you have not already - the software is a snap to set up, at least on Linux. Actually, several of us might consider doing that just to take periodic back-up copies of VdfWiki onto... just a thought.

:Good idea to do multiple backups. Sture and I have been talking about uploading the content to 'somebody's ftp server - to have it duplicated. is that 'somebody' you , Mike? --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

::It ''could'' be. Right now I have MediaWikis running on two Linux boxen - one in the office (Ububtu server) and one at home (Fedora). I realise that you guys are running under WinDoze/IIS - would that cause any issues do you think? We have a public, hosted FTP server that I ''should'' be able to configure access to for you, so we are a possibility as a backup, but I think DAW or DAE are probably a better bet, both from a technical and an administrative PoV. If needed, I could act as "''third string''" to a DAW/DAE "''second string''", in that you could dump stuff nightly to my FTP server (and I would then ignore it), where, in the event of an emergency, it could be restored from to a MediaWiki I could set up specifically for it (on another Fedora machine that I have spare in the office). If I set up VdfWiki on that, it would be sitting ready to go from backup... But I'd explore the Data Access options first I think. --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::Or... we also have our [http://www.unicorninterglobal.com web site] hosted, with the ability to host others (we do host a couple of others there). I have work to do in moving that all to a new machine on the hosting site (I'm just too overloaded to contemplate it ATM), but once I've done that we could offer a WinDoze compatible alternative hosting platform as a backup (primary or otherwise). --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::: DAE has agreed to set up an ftp account for our purpose. Its content will be part of their backup sequence (cool). Once we get it [[User:Jka|Jacob]] will upload a vdfwiki image and we'll see if it runs easily at your server(s). --[[User:Sture|Sture]] 18:16, 6 December 2007 (CET)

==Common Editing Mistakes==
Something to watch for (and maybe warn against): I had occasion last night to move an article ([[Add Workspace Parameter]]) by [[User:Peter Brooks|Peter Brooks]] which he had put on the [[:Category:How To]] page; I moved it off onto its own page, but it is an easy mistake to make: just go to a Category and start editing. --[[User:Mikepeat|Mike]] 11:01, 5 December 2007 (CET)

Talk:Main Page

2007-12-06T17:16:49Z

Sture: /* Backups */

= What would you like to see on this wiki? =

Feel free to discuss the purpose of this wiki on this page. You are also welcome to provide feedback on how you want this site to interact with other resources (e.g the newsgroups and vdf-guidance.com) --[[User:Jka|Jka]] 23:35, 25 November 2007 (CET)

== Overall goal ==

I think VdfWiki should be a place assemble knowledge and articles in the long term (in a structured manner).

There are some guidelines for keeping VdfWiki on the right track :[[VdfWiki_guidelines]]

The newsgroups are still '''THE''' place to ask question and chat about current events.--[[User:Jka|Jka]] 08:28, 23 November 2007 (CET)

==Wiki Structure Proposal==
I ([[User:Mikepeat|Mike]]) have just modifed the sidebar (the panel on the left of every page) to add "sections". (If any Sysop is not happy with this then it can be undone by editing the page [[MediaWiki:Sidebar]], or by just reverting my changes to it.) I have used the sections as currently laid out on the main page, but I would like to propose a significant restructuring of those sections. I will take no action until there has been reasonable discussion of it here and a consensus reached however.

=== Overall structure (from Mike)===
I would propose something like the following overall structure:

* <big>'''Main Page'''</big> (Brief Product Overview)
** Product Detail
** '''Windows'''
*** CodeJock
*** OLE/COM/ActiveX
*** Reporting
** '''Web'''
*** AJAX
*** JavaScript
** '''Character Mode'''
*** DOS/Console Mode
*** Unix/Linux
** '''Web Services'''
*** SOA
** '''Databases'''
*** Embedded
*** MS SQL Server
*** Oracle
*** IBM DB/2
*** Pervasive
*** MySQL
*** ODBC

(All comments and abuse will be gratefully received! [[Image:Smile-tpvgames.gif|20px]])

--[[User:Mikepeat|Mike]] 02:46, 21 November 2007 (CET)

::I agree, the current structure on the main page isn't clear enough at the moment. [[User:Hellboy1975|Hellboy1975]] 05:37, 21 November 2007 (CET)

::: Marco here... I agree too. I'd like to add some gotcha's about moving from DataFlex tables to DB2, accessed from DF32 on Linux and VDF on Win32.

=== Data Dictionaries ===
::: I also want to add a topic on batch create/update/delete using DataDictionaries. Where would that live? Would it be a topic referenced from Web and Windows and Webservices, or should this be another section, 'Data Dictionaries'?
::: I think a section about 'Data Dictionaries' could be great. I'll just add one (also containing the Databases' links from Mike --[[User:Jka|Jka]] 10:16, 25 November 2007 (CET)

=== Suggestion for topic (Development Tools)===

Can I suggest that we add a new section or link on the main page for general development tools and articles that sit outside of the existing Web/Windows/WS/Console categories. [[User:Hellboy1975|Hellboy1975]] 00:07, 23 November 2007 (CET)

:Sounds perfectly sensible to me... "Other" as a general catch-all, or "Other Tools": a bit more specific, but then we might have issues with things that fell outside that ''and'' our existing sections. --[[User:Mikepeat|Mike]] 00:14, 23 November 2007 (CET)

:: I am OK with a "tools" section. We can still lay down the law in that page :P The trick is to create a separate page for each tool we want to describe - and keep the external links down to a minimum (this should make it easier to keep track of the content on the page). I think the title "Development tools" could work. articles not related to these sections can be attached to a specific user page - we should try not to clutter the frontpage and 1st level navigation too much. --[[User:Jka|Jka]] 08:15, 23 November 2007 (CET)

== Discussing cookbooks ==

::That structure looks reasonable. My original idea with the "cookbooks" was to put a list of howto-do-stuffs in there. E.g a list of recipes in them - and have the "other" page contain the description. E.g "Windows" contains the description and "Windows cookbook" contains the recipes. I've found that the early contributions have been about "howto do stuff" (e.g something that should go in the cookbook). I can see now , that there should be no distinction between e.g "Windows" and "Windows cookbook" - they should be the same page. --[[User:Jka|Jka]] 09:38, 21 November 2007 (CET)

:::On the "''cookbooks''" issue... perhaps using "Categories" might be a help. This is not a subject I understand well enough (yet!), but it seems to me that it might add a multi-dimentional element to how articles are arranged and accessed, so that they can be come at from more than one direction (don't know how yet - research needed!). I think the original idea had merit - that some articles will be of a "howto" nature while others will be more descriptive, others discursive and still others umm... complaining (whining? - "''why don't DAW do more with the Linux product?''" <g>). In a big Wiki like Wikipedia, searching is usually the only way to start, but with our rather less ambitious subject matter, good organisation might lead people quickly to what they need (even if they didn't know they needed it and didn't know it was there). --[[User:Mikepeat|Mike]] 11:12, 21 November 2007 (CET)

::Yes . The need for having a "cookbook" can be adressed by having a category for all the different recipees. I think we should proceed in this direction . I removed the cookbook links from the frontpage and the navigation. --[[User:Jka|Jka]] 20:12, 21 November 2007 (CET)

==Style Guide?==
At the suggestion of [[User:Hellboy1975|Hellboy1975]] (what is that all about anyway, Matt? <g>) - see [[Talk:Web_Service_Basics]] - I have been changing the colour I am using to emphasise stuff - in this case (for now anyway) changing blue to midnightblue to avoid confusion with hypertext links (I'm not sure that is enough - I think I've just made that text look like visited links).

However it would have saved me this effort if I'd had a guideline on what colours etc. to use from the start. I think we need to evolve some kind of consensus "Style Guide" which would help us all use a nice, clear, consistent style for various things. It would be bound to be an evolving document, as we are unlikely to think of everything on day one and will have to be flexible and inclusive rather than prescriptive, but the sooner we start laying it down, the less time will be wasted later fixing stuff up that doesn't match or looks ugly. (''I did experiment with using a template - [[Template:Colorise]] - but couldn't get what I wanted to work: the amount of time I can afford to devote to learning the WikiMedia Template [http://en.wikipedia.org/wiki/Domain-specific_programming_language DSL] is strictly limited!'' <g>) [[User:Mikepeat|Mike]] 11:03, 22 November 2007 (CET)
:I should have said ''proscriptive'' above - it would indeed be ''prescriptive'', by intent! [[User:Mikepeat|Mike]] 14:54, 22 November 2007 (CET)
:Something like the Wikipedia [http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style Manual of Style] is always a good place to start. Another place to look for examples are in some of the programming manuals on Wikibooks. Here's one of the pages in the C++ manual for instance. [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Variables] [[User:Hellboy1975|Hellboy1975]] 00:20, 23 November 2007 (CET)

==Opensource/community libraries==

I understand that there is a [[Data Access Worldwide|DAW]] community site in the works. please consider this when describing available available [[Open Source]] [[Visual DataFlex]] libraries. --[[User:Jka|Jka]] 00:49, 1 December 2007 (CET)

== Main Page ==

I'm sure you've all noticed by now I've made a bit of a change to the front page. It's more or less the same as before, just with a bit more information for users who are a bit new to the whole wiki thing. What do you guys think? [[User:Hellboy1975|Hellboy1975]] 05:21, 5 December 2007 (CET)

:Looks good Matt... you might consider mentioning [[Special:Categories]] in addition to the [[Category Index]], and maybe adding the [[Category Index]] to the "navigation" pane (edit [[MediaWiki:Sidebar]]). ...And be careful who you say doesn't bite: '''''I''''' haven't had any coffee yet! [[Image:Smile.gif]]

:I think we probably need a single person (oops: that would be you... ''sucker!'' You have only yourself to blame!) to head-up work on structure, accessibility, cross-indexing and the like. We have made a big step forward with Categories, giving us the three tools you mention: Structure, Search and Categories... ''now'' let's talk '''''namespaces!'''''

::Given that [[User:Hellboy1975|Matt]] has proclaimed himself 'category enforcer' - then I think he could lead the overall structure on the wiki ;) --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

:::That's fine, I'm happy to take on the roll of structuring the site for now. My first goal is to make the main page a bit more accessable, and then each of the main categories (Web, Windows, Character Mode, DD's and Development Tools). I guess my plan with these pages at the moment is to make the more structures, in much the same way as the Main Page on Wikipedia [[User:Hellboy1975|Hellboy1975]] 00:25, 6 December 2007 (CET)
::::Take a look at [[Main_Page_1]] for a preview [[User:Hellboy1975|Hellboy1975]] 01:53, 6 December 2007 (CET)

:::::Like it Matt! ''Very'' nice. Keep up the good work! --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET)
:::::Awesome effort :) You rock --[[User:Jka|Jka]] 10:06, 6 December 2007 (CET)
:::::So... when are you going to make that live? I can't believe anybody is going to think we should ''not'' go with it... it is just a question of fleshing out some of those "wanted" links first IMO. --[[User:Mikepeat|Mike]] 10:22, 6 December 2007 (CET)
::::::Still got a couple of little things I want to do, mainly including some more info from the original main page. All things going well sometime tomorrow or over the weekend. [[User:Hellboy1975|Hellboy1975]] 13:08, 6 December 2007 (CET)

:Actually, namespaces require modification of the LocalSettings.php file on the server I think, so adding them is non-trivial (i.e. down to somebody with OS access to the server: Jacob, Johan or Sture, etc.) and thus they are a blunter and less flexible tool than Categories, but worth thinking about, in a background sort of way.

::Let's do some experimenting with namespaces when we have a backup copy of VDFWiki running on a separate machine. --[[User:Jka|Jka]] 10:10, 6 December 2007 (CET)

==Backups==
(Seem to have spawned a different thread here, so... [[Image:Smile.jpg]] --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET))

I have two other MediaWikis set up that I can play/practice on (but they are hosted on ''real'' operating systems [[Image:Smile.gif]]), and if you are going to do that stuff I suggest you set one up for yourself, if you have not already - the software is a snap to set up, at least on Linux. Actually, several of us might consider doing that just to take periodic back-up copies of VdfWiki onto... just a thought.

:Good idea to do multiple backups. Sture and I have been talking about uploading the content to 'somebody's ftp server - to have it duplicated. is that 'somebody' you , Mike? --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

::It ''could'' be. Right now I have MediaWikis running on two Linux boxen - one in the office (Ububtu server) and one at home (Fedora). I realise that you guys are running under WinDoze/IIS - would that cause any issues do you think? We have a public, hosted FTP server that I ''should'' be able to configure access to for you, so we are a possibility as a backup, but I think DAW or DAE are probably a better bet, both from a technical and an administrative PoV. If needed, I could act as "''third string''" to a DAW/DAE "''second string''", in that you could dump stuff nightly to my FTP server (and I would then ignore it), where, in the event of an emergency, it could be restored from to a MediaWiki I could set up specifically for it (on another Fedora machine that I have spare in the office). If I set up VdfWiki on that, it would be sitting ready to go from backup... But I'd explore the Data Access options first I think. --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::Or... we also have our [http://www.unicorninterglobal.com web site] hosted, with the ability to host others (we do host a couple of others there). I have work to do in moving that all to a new machine on the hosting site (I'm just too overloaded to contemplate it ATM), but once I've done that we could offer a WinDoze compatible alternative hosting platform as a backup (primary or otherwise). --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::: DAE has agreed to set up an ftp account for our purpose. Its content will be part of their backup sequence (cool). Once we get it [[User:Jka|Jacob]] will upload a vdfwiki image and you can experiment with your servers. --[[User:Sture|Sture]] 18:16, 6 December 2007 (CET)

==Common Editing Mistakes==
Something to watch for (and maybe warn against): I had occasion last night to move an article ([[Add Workspace Parameter]]) by [[User:Peter Brooks|Peter Brooks]] which he had put on the [[:Category:How To]] page; I moved it off onto its own page, but it is an easy mistake to make: just go to a Category and start editing. --[[User:Mikepeat|Mike]] 11:01, 5 December 2007 (CET)

Talk:Main Page

2007-12-06T17:16:33Z

Sture: /* Backups */

= What would you like to see on this wiki? =

Feel free to discuss the purpose of this wiki on this page. You are also welcome to provide feedback on how you want this site to interact with other resources (e.g the newsgroups and vdf-guidance.com) --[[User:Jka|Jka]] 23:35, 25 November 2007 (CET)

== Overall goal ==

I think VdfWiki should be a place assemble knowledge and articles in the long term (in a structured manner).

There are some guidelines for keeping VdfWiki on the right track :[[VdfWiki_guidelines]]

The newsgroups are still '''THE''' place to ask question and chat about current events.--[[User:Jka|Jka]] 08:28, 23 November 2007 (CET)

==Wiki Structure Proposal==
I ([[User:Mikepeat|Mike]]) have just modifed the sidebar (the panel on the left of every page) to add "sections". (If any Sysop is not happy with this then it can be undone by editing the page [[MediaWiki:Sidebar]], or by just reverting my changes to it.) I have used the sections as currently laid out on the main page, but I would like to propose a significant restructuring of those sections. I will take no action until there has been reasonable discussion of it here and a consensus reached however.

=== Overall structure (from Mike)===
I would propose something like the following overall structure:

* <big>'''Main Page'''</big> (Brief Product Overview)
** Product Detail
** '''Windows'''
*** CodeJock
*** OLE/COM/ActiveX
*** Reporting
** '''Web'''
*** AJAX
*** JavaScript
** '''Character Mode'''
*** DOS/Console Mode
*** Unix/Linux
** '''Web Services'''
*** SOA
** '''Databases'''
*** Embedded
*** MS SQL Server
*** Oracle
*** IBM DB/2
*** Pervasive
*** MySQL
*** ODBC

(All comments and abuse will be gratefully received! [[Image:Smile-tpvgames.gif|20px]])

--[[User:Mikepeat|Mike]] 02:46, 21 November 2007 (CET)

::I agree, the current structure on the main page isn't clear enough at the moment. [[User:Hellboy1975|Hellboy1975]] 05:37, 21 November 2007 (CET)

::: Marco here... I agree too. I'd like to add some gotcha's about moving from DataFlex tables to DB2, accessed from DF32 on Linux and VDF on Win32.

=== Data Dictionaries ===
::: I also want to add a topic on batch create/update/delete using DataDictionaries. Where would that live? Would it be a topic referenced from Web and Windows and Webservices, or should this be another section, 'Data Dictionaries'?
::: I think a section about 'Data Dictionaries' could be great. I'll just add one (also containing the Databases' links from Mike --[[User:Jka|Jka]] 10:16, 25 November 2007 (CET)

=== Suggestion for topic (Development Tools)===

Can I suggest that we add a new section or link on the main page for general development tools and articles that sit outside of the existing Web/Windows/WS/Console categories. [[User:Hellboy1975|Hellboy1975]] 00:07, 23 November 2007 (CET)

:Sounds perfectly sensible to me... "Other" as a general catch-all, or "Other Tools": a bit more specific, but then we might have issues with things that fell outside that ''and'' our existing sections. --[[User:Mikepeat|Mike]] 00:14, 23 November 2007 (CET)

:: I am OK with a "tools" section. We can still lay down the law in that page :P The trick is to create a separate page for each tool we want to describe - and keep the external links down to a minimum (this should make it easier to keep track of the content on the page). I think the title "Development tools" could work. articles not related to these sections can be attached to a specific user page - we should try not to clutter the frontpage and 1st level navigation too much. --[[User:Jka|Jka]] 08:15, 23 November 2007 (CET)

== Discussing cookbooks ==

::That structure looks reasonable. My original idea with the "cookbooks" was to put a list of howto-do-stuffs in there. E.g a list of recipes in them - and have the "other" page contain the description. E.g "Windows" contains the description and "Windows cookbook" contains the recipes. I've found that the early contributions have been about "howto do stuff" (e.g something that should go in the cookbook). I can see now , that there should be no distinction between e.g "Windows" and "Windows cookbook" - they should be the same page. --[[User:Jka|Jka]] 09:38, 21 November 2007 (CET)

:::On the "''cookbooks''" issue... perhaps using "Categories" might be a help. This is not a subject I understand well enough (yet!), but it seems to me that it might add a multi-dimentional element to how articles are arranged and accessed, so that they can be come at from more than one direction (don't know how yet - research needed!). I think the original idea had merit - that some articles will be of a "howto" nature while others will be more descriptive, others discursive and still others umm... complaining (whining? - "''why don't DAW do more with the Linux product?''" <g>). In a big Wiki like Wikipedia, searching is usually the only way to start, but with our rather less ambitious subject matter, good organisation might lead people quickly to what they need (even if they didn't know they needed it and didn't know it was there). --[[User:Mikepeat|Mike]] 11:12, 21 November 2007 (CET)

::Yes . The need for having a "cookbook" can be adressed by having a category for all the different recipees. I think we should proceed in this direction . I removed the cookbook links from the frontpage and the navigation. --[[User:Jka|Jka]] 20:12, 21 November 2007 (CET)

==Style Guide?==
At the suggestion of [[User:Hellboy1975|Hellboy1975]] (what is that all about anyway, Matt? <g>) - see [[Talk:Web_Service_Basics]] - I have been changing the colour I am using to emphasise stuff - in this case (for now anyway) changing blue to midnightblue to avoid confusion with hypertext links (I'm not sure that is enough - I think I've just made that text look like visited links).

However it would have saved me this effort if I'd had a guideline on what colours etc. to use from the start. I think we need to evolve some kind of consensus "Style Guide" which would help us all use a nice, clear, consistent style for various things. It would be bound to be an evolving document, as we are unlikely to think of everything on day one and will have to be flexible and inclusive rather than prescriptive, but the sooner we start laying it down, the less time will be wasted later fixing stuff up that doesn't match or looks ugly. (''I did experiment with using a template - [[Template:Colorise]] - but couldn't get what I wanted to work: the amount of time I can afford to devote to learning the WikiMedia Template [http://en.wikipedia.org/wiki/Domain-specific_programming_language DSL] is strictly limited!'' <g>) [[User:Mikepeat|Mike]] 11:03, 22 November 2007 (CET)
:I should have said ''proscriptive'' above - it would indeed be ''prescriptive'', by intent! [[User:Mikepeat|Mike]] 14:54, 22 November 2007 (CET)
:Something like the Wikipedia [http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style Manual of Style] is always a good place to start. Another place to look for examples are in some of the programming manuals on Wikibooks. Here's one of the pages in the C++ manual for instance. [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Variables] [[User:Hellboy1975|Hellboy1975]] 00:20, 23 November 2007 (CET)

==Opensource/community libraries==

I understand that there is a [[Data Access Worldwide|DAW]] community site in the works. please consider this when describing available available [[Open Source]] [[Visual DataFlex]] libraries. --[[User:Jka|Jka]] 00:49, 1 December 2007 (CET)

== Main Page ==

I'm sure you've all noticed by now I've made a bit of a change to the front page. It's more or less the same as before, just with a bit more information for users who are a bit new to the whole wiki thing. What do you guys think? [[User:Hellboy1975|Hellboy1975]] 05:21, 5 December 2007 (CET)

:Looks good Matt... you might consider mentioning [[Special:Categories]] in addition to the [[Category Index]], and maybe adding the [[Category Index]] to the "navigation" pane (edit [[MediaWiki:Sidebar]]). ...And be careful who you say doesn't bite: '''''I''''' haven't had any coffee yet! [[Image:Smile.gif]]

:I think we probably need a single person (oops: that would be you... ''sucker!'' You have only yourself to blame!) to head-up work on structure, accessibility, cross-indexing and the like. We have made a big step forward with Categories, giving us the three tools you mention: Structure, Search and Categories... ''now'' let's talk '''''namespaces!'''''

::Given that [[User:Hellboy1975|Matt]] has proclaimed himself 'category enforcer' - then I think he could lead the overall structure on the wiki ;) --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

:::That's fine, I'm happy to take on the roll of structuring the site for now. My first goal is to make the main page a bit more accessable, and then each of the main categories (Web, Windows, Character Mode, DD's and Development Tools). I guess my plan with these pages at the moment is to make the more structures, in much the same way as the Main Page on Wikipedia [[User:Hellboy1975|Hellboy1975]] 00:25, 6 December 2007 (CET)
::::Take a look at [[Main_Page_1]] for a preview [[User:Hellboy1975|Hellboy1975]] 01:53, 6 December 2007 (CET)

:::::Like it Matt! ''Very'' nice. Keep up the good work! --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET)
:::::Awesome effort :) You rock --[[User:Jka|Jka]] 10:06, 6 December 2007 (CET)
:::::So... when are you going to make that live? I can't believe anybody is going to think we should ''not'' go with it... it is just a question of fleshing out some of those "wanted" links first IMO. --[[User:Mikepeat|Mike]] 10:22, 6 December 2007 (CET)
::::::Still got a couple of little things I want to do, mainly including some more info from the original main page. All things going well sometime tomorrow or over the weekend. [[User:Hellboy1975|Hellboy1975]] 13:08, 6 December 2007 (CET)

:Actually, namespaces require modification of the LocalSettings.php file on the server I think, so adding them is non-trivial (i.e. down to somebody with OS access to the server: Jacob, Johan or Sture, etc.) and thus they are a blunter and less flexible tool than Categories, but worth thinking about, in a background sort of way.

::Let's do some experimenting with namespaces when we have a backup copy of VDFWiki running on a separate machine. --[[User:Jka|Jka]] 10:10, 6 December 2007 (CET)

==Backups==
(Seem to have spawned a different thread here, so... [[Image:Smile.jpg]] --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET))

I have two other MediaWikis set up that I can play/practice on (but they are hosted on ''real'' operating systems [[Image:Smile.gif]]), and if you are going to do that stuff I suggest you set one up for yourself, if you have not already - the software is a snap to set up, at least on Linux. Actually, several of us might consider doing that just to take periodic back-up copies of VdfWiki onto... just a thought.

:Good idea to do multiple backups. Sture and I have been talking about uploading the content to 'somebody's ftp server - to have it duplicated. is that 'somebody' you , Mike? --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

::It ''could'' be. Right now I have MediaWikis running on two Linux boxen - one in the office (Ububtu server) and one at home (Fedora). I realise that you guys are running under WinDoze/IIS - would that cause any issues do you think? We have a public, hosted FTP server that I ''should'' be able to configure access to for you, so we are a possibility as a backup, but I think DAW or DAE are probably a better bet, both from a technical and an administrative PoV. If needed, I could act as "''third string''" to a DAW/DAE "''second string''", in that you could dump stuff nightly to my FTP server (and I would then ignore it), where, in the event of an emergency, it could be restored from to a MediaWiki I could set up specifically for it (on another Fedora machine that I have spare in the office). If I set up VdfWiki on that, it would be sitting ready to go from backup... But I'd explore the Data Access options first I think. --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::Or... we also have our [http://www.unicorninterglobal.com web site] hosted, with the ability to host others (we do host a couple of others there). I have work to do in moving that all to a new machine on the hosting site (I'm just too overloaded to contemplate it ATM), but once I've done that we could offer a WinDoze compatible alternative hosting platform as a backup (primary or otherwise). --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::: DAE has agreed to set up an ftp account for our purpose. Its content will be part of their backup sequence (cool). Once we get it [[User:Jka|Jacob]] will upload a vdfwiki image and you can experiment with your servers. --[[User:Sture|Sture]] --[[User:Sture|Sture]] 18:16, 6 December 2007 (CET)

==Common Editing Mistakes==
Something to watch for (and maybe warn against): I had occasion last night to move an article ([[Add Workspace Parameter]]) by [[User:Peter Brooks|Peter Brooks]] which he had put on the [[:Category:How To]] page; I moved it off onto its own page, but it is an easy mistake to make: just go to a Category and start editing. --[[User:Mikepeat|Mike]] 11:01, 5 December 2007 (CET)

Talk:Main Page

2007-12-06T17:14:39Z

Sture: /* Backups */

= What would you like to see on this wiki? =

Feel free to discuss the purpose of this wiki on this page. You are also welcome to provide feedback on how you want this site to interact with other resources (e.g the newsgroups and vdf-guidance.com) --[[User:Jka|Jka]] 23:35, 25 November 2007 (CET)

== Overall goal ==

I think VdfWiki should be a place assemble knowledge and articles in the long term (in a structured manner).

There are some guidelines for keeping VdfWiki on the right track :[[VdfWiki_guidelines]]

The newsgroups are still '''THE''' place to ask question and chat about current events.--[[User:Jka|Jka]] 08:28, 23 November 2007 (CET)

==Wiki Structure Proposal==
I ([[User:Mikepeat|Mike]]) have just modifed the sidebar (the panel on the left of every page) to add "sections". (If any Sysop is not happy with this then it can be undone by editing the page [[MediaWiki:Sidebar]], or by just reverting my changes to it.) I have used the sections as currently laid out on the main page, but I would like to propose a significant restructuring of those sections. I will take no action until there has been reasonable discussion of it here and a consensus reached however.

=== Overall structure (from Mike)===
I would propose something like the following overall structure:

* <big>'''Main Page'''</big> (Brief Product Overview)
** Product Detail
** '''Windows'''
*** CodeJock
*** OLE/COM/ActiveX
*** Reporting
** '''Web'''
*** AJAX
*** JavaScript
** '''Character Mode'''
*** DOS/Console Mode
*** Unix/Linux
** '''Web Services'''
*** SOA
** '''Databases'''
*** Embedded
*** MS SQL Server
*** Oracle
*** IBM DB/2
*** Pervasive
*** MySQL
*** ODBC

(All comments and abuse will be gratefully received! [[Image:Smile-tpvgames.gif|20px]])

--[[User:Mikepeat|Mike]] 02:46, 21 November 2007 (CET)

::I agree, the current structure on the main page isn't clear enough at the moment. [[User:Hellboy1975|Hellboy1975]] 05:37, 21 November 2007 (CET)

::: Marco here... I agree too. I'd like to add some gotcha's about moving from DataFlex tables to DB2, accessed from DF32 on Linux and VDF on Win32.

=== Data Dictionaries ===
::: I also want to add a topic on batch create/update/delete using DataDictionaries. Where would that live? Would it be a topic referenced from Web and Windows and Webservices, or should this be another section, 'Data Dictionaries'?
::: I think a section about 'Data Dictionaries' could be great. I'll just add one (also containing the Databases' links from Mike --[[User:Jka|Jka]] 10:16, 25 November 2007 (CET)

=== Suggestion for topic (Development Tools)===

Can I suggest that we add a new section or link on the main page for general development tools and articles that sit outside of the existing Web/Windows/WS/Console categories. [[User:Hellboy1975|Hellboy1975]] 00:07, 23 November 2007 (CET)

:Sounds perfectly sensible to me... "Other" as a general catch-all, or "Other Tools": a bit more specific, but then we might have issues with things that fell outside that ''and'' our existing sections. --[[User:Mikepeat|Mike]] 00:14, 23 November 2007 (CET)

:: I am OK with a "tools" section. We can still lay down the law in that page :P The trick is to create a separate page for each tool we want to describe - and keep the external links down to a minimum (this should make it easier to keep track of the content on the page). I think the title "Development tools" could work. articles not related to these sections can be attached to a specific user page - we should try not to clutter the frontpage and 1st level navigation too much. --[[User:Jka|Jka]] 08:15, 23 November 2007 (CET)

== Discussing cookbooks ==

::That structure looks reasonable. My original idea with the "cookbooks" was to put a list of howto-do-stuffs in there. E.g a list of recipes in them - and have the "other" page contain the description. E.g "Windows" contains the description and "Windows cookbook" contains the recipes. I've found that the early contributions have been about "howto do stuff" (e.g something that should go in the cookbook). I can see now , that there should be no distinction between e.g "Windows" and "Windows cookbook" - they should be the same page. --[[User:Jka|Jka]] 09:38, 21 November 2007 (CET)

:::On the "''cookbooks''" issue... perhaps using "Categories" might be a help. This is not a subject I understand well enough (yet!), but it seems to me that it might add a multi-dimentional element to how articles are arranged and accessed, so that they can be come at from more than one direction (don't know how yet - research needed!). I think the original idea had merit - that some articles will be of a "howto" nature while others will be more descriptive, others discursive and still others umm... complaining (whining? - "''why don't DAW do more with the Linux product?''" <g>). In a big Wiki like Wikipedia, searching is usually the only way to start, but with our rather less ambitious subject matter, good organisation might lead people quickly to what they need (even if they didn't know they needed it and didn't know it was there). --[[User:Mikepeat|Mike]] 11:12, 21 November 2007 (CET)

::Yes . The need for having a "cookbook" can be adressed by having a category for all the different recipees. I think we should proceed in this direction . I removed the cookbook links from the frontpage and the navigation. --[[User:Jka|Jka]] 20:12, 21 November 2007 (CET)

==Style Guide?==
At the suggestion of [[User:Hellboy1975|Hellboy1975]] (what is that all about anyway, Matt? <g>) - see [[Talk:Web_Service_Basics]] - I have been changing the colour I am using to emphasise stuff - in this case (for now anyway) changing blue to midnightblue to avoid confusion with hypertext links (I'm not sure that is enough - I think I've just made that text look like visited links).

However it would have saved me this effort if I'd had a guideline on what colours etc. to use from the start. I think we need to evolve some kind of consensus "Style Guide" which would help us all use a nice, clear, consistent style for various things. It would be bound to be an evolving document, as we are unlikely to think of everything on day one and will have to be flexible and inclusive rather than prescriptive, but the sooner we start laying it down, the less time will be wasted later fixing stuff up that doesn't match or looks ugly. (''I did experiment with using a template - [[Template:Colorise]] - but couldn't get what I wanted to work: the amount of time I can afford to devote to learning the WikiMedia Template [http://en.wikipedia.org/wiki/Domain-specific_programming_language DSL] is strictly limited!'' <g>) [[User:Mikepeat|Mike]] 11:03, 22 November 2007 (CET)
:I should have said ''proscriptive'' above - it would indeed be ''prescriptive'', by intent! [[User:Mikepeat|Mike]] 14:54, 22 November 2007 (CET)
:Something like the Wikipedia [http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style Manual of Style] is always a good place to start. Another place to look for examples are in some of the programming manuals on Wikibooks. Here's one of the pages in the C++ manual for instance. [http://en.wikibooks.org/wiki/C%2B%2B_Programming/Variables] [[User:Hellboy1975|Hellboy1975]] 00:20, 23 November 2007 (CET)

==Opensource/community libraries==

I understand that there is a [[Data Access Worldwide|DAW]] community site in the works. please consider this when describing available available [[Open Source]] [[Visual DataFlex]] libraries. --[[User:Jka|Jka]] 00:49, 1 December 2007 (CET)

== Main Page ==

I'm sure you've all noticed by now I've made a bit of a change to the front page. It's more or less the same as before, just with a bit more information for users who are a bit new to the whole wiki thing. What do you guys think? [[User:Hellboy1975|Hellboy1975]] 05:21, 5 December 2007 (CET)

:Looks good Matt... you might consider mentioning [[Special:Categories]] in addition to the [[Category Index]], and maybe adding the [[Category Index]] to the "navigation" pane (edit [[MediaWiki:Sidebar]]). ...And be careful who you say doesn't bite: '''''I''''' haven't had any coffee yet! [[Image:Smile.gif]]

:I think we probably need a single person (oops: that would be you... ''sucker!'' You have only yourself to blame!) to head-up work on structure, accessibility, cross-indexing and the like. We have made a big step forward with Categories, giving us the three tools you mention: Structure, Search and Categories... ''now'' let's talk '''''namespaces!'''''

::Given that [[User:Hellboy1975|Matt]] has proclaimed himself 'category enforcer' - then I think he could lead the overall structure on the wiki ;) --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

:::That's fine, I'm happy to take on the roll of structuring the site for now. My first goal is to make the main page a bit more accessable, and then each of the main categories (Web, Windows, Character Mode, DD's and Development Tools). I guess my plan with these pages at the moment is to make the more structures, in much the same way as the Main Page on Wikipedia [[User:Hellboy1975|Hellboy1975]] 00:25, 6 December 2007 (CET)
::::Take a look at [[Main_Page_1]] for a preview [[User:Hellboy1975|Hellboy1975]] 01:53, 6 December 2007 (CET)

:::::Like it Matt! ''Very'' nice. Keep up the good work! --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET)
:::::Awesome effort :) You rock --[[User:Jka|Jka]] 10:06, 6 December 2007 (CET)
:::::So... when are you going to make that live? I can't believe anybody is going to think we should ''not'' go with it... it is just a question of fleshing out some of those "wanted" links first IMO. --[[User:Mikepeat|Mike]] 10:22, 6 December 2007 (CET)
::::::Still got a couple of little things I want to do, mainly including some more info from the original main page. All things going well sometime tomorrow or over the weekend. [[User:Hellboy1975|Hellboy1975]] 13:08, 6 December 2007 (CET)

:Actually, namespaces require modification of the LocalSettings.php file on the server I think, so adding them is non-trivial (i.e. down to somebody with OS access to the server: Jacob, Johan or Sture, etc.) and thus they are a blunter and less flexible tool than Categories, but worth thinking about, in a background sort of way.

::Let's do some experimenting with namespaces when we have a backup copy of VDFWiki running on a separate machine. --[[User:Jka|Jka]] 10:10, 6 December 2007 (CET)

==Backups==
(Seem to have spawned a different thread here, so... [[Image:Smile.jpg]] --[[User:Mikepeat|Mike]] 09:54, 6 December 2007 (CET))

I have two other MediaWikis set up that I can play/practice on (but they are hosted on ''real'' operating systems [[Image:Smile.gif]]), and if you are going to do that stuff I suggest you set one up for yourself, if you have not already - the software is a snap to set up, at least on Linux. Actually, several of us might consider doing that just to take periodic back-up copies of VdfWiki onto... just a thought.

:Good idea to do multiple backups. Sture and I have been talking about uploading the content to 'somebody's ftp server - to have it duplicated. is that 'somebody' you , Mike? --[[User:Jka|Jka]] 11:45, 5 December 2007 (CET)

::It ''could'' be. Right now I have MediaWikis running on two Linux boxen - one in the office (Ububtu server) and one at home (Fedora). I realise that you guys are running under WinDoze/IIS - would that cause any issues do you think? We have a public, hosted FTP server that I ''should'' be able to configure access to for you, so we are a possibility as a backup, but I think DAW or DAE are probably a better bet, both from a technical and an administrative PoV. If needed, I could act as "''third string''" to a DAW/DAE "''second string''", in that you could dump stuff nightly to my FTP server (and I would then ignore it), where, in the event of an emergency, it could be restored from to a MediaWiki I could set up specifically for it (on another Fedora machine that I have spare in the office). If I set up VdfWiki on that, it would be sitting ready to go from backup... But I'd explore the Data Access options first I think. --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::Or... we also have our [http://www.unicorninterglobal.com web site] hosted, with the ability to host others (we do host a couple of others there). I have work to do in moving that all to a new machine on the hosting site (I'm just too overloaded to contemplate it ATM), but once I've done that we could offer a WinDoze compatible alternative hosting platform as a backup (primary or otherwise). --[[User:Mikepeat|Mike]] 13:05, 5 December 2007 (CET)

:::: DAE has agreed to set up an ftp account for our purpose. Its content will be part of their backup sequence (cool). Once we get it [[User:Jka|Jacob]] will upload a vdfwiki image and you can experiment with your servers. --[[User:Sture|Sture]]

==Common Editing Mistakes==
Something to watch for (and maybe warn against): I had occasion last night to move an article ([[Add Workspace Parameter]]) by [[User:Peter Brooks|Peter Brooks]] which he had put on the [[:Category:How To]] page; I moved it off onto its own page, but it is an easy mistake to make: just go to a Category and start editing. --[[User:Mikepeat|Mike]] 11:01, 5 December 2007 (CET)

User:Sture

2007-12-03T12:44:51Z

Sture: New page: = Information = {{User| |Name=Sture Andersen |Email=sture@sture.dk |Company=Sture Aps }}

= Information =

{{User|
|Name=Sture Andersen
|Email=sture@sture.dk
|Company=Sture Aps
}}

Main Page

2007-08-25T19:04:53Z

Sture: /* Introduction */

== Introduction ==

Welcome to StureWiki. Here you can share your Visual DataFlex programming knowledge (and learn a little too).

== Subjects ==
*[[AJAX Library for Visual DataFlex| AJAX programming (AJAX Library for Visual DataFlex)]]
*[[Visual DataFlex| Windows programming (Visual DataFlex)]]
*[[DataFlex| Character mode (DataFlex)]]
*[[Electos| Content Management (Electos)]]

== Tools==
*[[SCM| Source code Management]]
*[[Editors| Editors]]

== Projects ==
*[[VDFQuery| VDFQuery : the framework behind Wasp ]]
*[[WikiKnowledgeBase| Using a wiki for a knowledge base ]]

== Other resources ==
*[http://www.vdf-guidance.com vdf-guidance.com]
*[http://blog.front-it.dk 'Charlottes web']
*[http://www.dataaccess.com/support.asp?pageid=771 Data Access Worldwide whitepapers]
*[http://www.sture.com/wasp 'WASP (Newsgroup search)']

Main Page

2007-08-25T18:58:51Z

Sture: /* Introduction */

== Introduction ==

Welcome to StureWiki. Here you can brag about your VDF programming powers (and learn a little too).

== Subjects ==
*[[AJAX Library for Visual DataFlex| AJAX programming (AJAX Library for Visual DataFlex)]]
*[[Visual DataFlex| Windows programming (Visual DataFlex)]]
*[[DataFlex| Character mode (DataFlex)]]
*[[Electos| Content Management (Electos)]]

== Tools==
*[[SCM| Source code Management]]
*[[Editors| Editors]]

== Projects ==
*[[VDFQuery| VDFQuery : the framework behind Wasp ]]
*[[WikiKnowledgeBase| Using a wiki for a knowledge base ]]

== Other resources ==
*[http://www.vdf-guidance.com vdf-guidance.com]
*[http://blog.front-it.dk 'Charlottes web']
*[http://www.dataaccess.com/support.asp?pageid=771 Data Access Worldwide whitepapers]
*[http://www.sture.com/wasp 'WASP (Newsgroup search)']

Main Page

2007-08-25T18:57:27Z

Sture: /* Other resources */

== Introduction ==

Welcome to StureWiki. Here you can brag about your godlike programming powers (and learn a little too).

== Subjects ==
*[[AJAX Library for Visual DataFlex| AJAX programming (AJAX Library for Visual DataFlex)]]
*[[Visual DataFlex| Windows programming (Visual DataFlex)]]
*[[DataFlex| Character mode (DataFlex)]]
*[[Electos| Content Management (Electos)]]

== Tools==
*[[SCM| Source code Management]]
*[[Editors| Editors]]

== Projects ==
*[[VDFQuery| VDFQuery : the framework behind Wasp ]]
*[[WikiKnowledgeBase| Using a wiki for a knowledge base ]]

== Other resources ==
*[http://www.vdf-guidance.com vdf-guidance.com]
*[http://blog.front-it.dk 'Charlottes web']
*[http://www.dataaccess.com/support.asp?pageid=771 Data Access Worldwide whitepapers]
*[http://www.sture.com/wasp 'WASP (Newsgroup search)']

Visual DataFlex

2007-08-17T12:02:25Z

Sture:

Hey hey wiki world

==External links==
* http://www.visualdataflex.com
* http://www.dataaccess.com
* http://www.dataaccess.nl
* [http://www.sture.com/wasp/ WASP Newsgroup search] engine

*[[DataFlex Connectivity Kit|Connectivity]]

SVN

2007-08-17T11:53:47Z

Sture: /* omitting data files */

= omitting data files=
When coding DataFlex with the native database, then we do not want .dat files in version control. (They will take up too much space on the server in different versions). To solve this we either need to tweak the svn setup.

Tweaking the svn setup : http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html

Global ignore pattern could be set to:

*.dat *.k* *.vld *.hdr *.mtd *.dsk *.loc *.prn *.prp *.bak *.pkd *.pbg *.fld *.exe *.dbg *.trc *.doc

= Importing a project =
If you are importing a project , then remember to have write access to the repository url you are writing to.

Here is a description of how to do it in tortoise svn: http://wsmoak.net/subversion/demo/tsvn-import.html

= Links =
*docs: http://svnbook.red-bean.com/
*client: http://tortoisesvn.tigris.org/
*server: http://svn1clicksetup.tigris.org/

SVN

2007-08-17T11:53:23Z

Sture:

= omitting data files=
When coding DataFlex with the native database, then we do not want .dat files in version control. (They will take up too much space on the server in different versions). To solve this we either need to tweak the svn setup.

Tweaking the svn setup : http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html

Global ignore pattern could be set to

"*.dat *.k* *.vld *.hdr *.mtd *.dsk *.loc *.prn *.prp *.bak *.pkd *.pbg *.fld *.exe *.dbg *.trc *.doc"

= Importing a project =
If you are importing a project , then remember to have write access to the repository url you are writing to.

Here is a description of how to do it in tortoise svn: http://wsmoak.net/subversion/demo/tsvn-import.html

= Links =
*docs: http://svnbook.red-bean.com/
*client: http://tortoisesvn.tigris.org/
*server: http://svn1clicksetup.tigris.org/

DataFlex Wiki:Site support

2007-08-16T14:32:34Z

Sture: New page: No donations, please

No donations, please