Using GIT for Dataflex Development: Difference between revisions
Using GIT for Dataflex Development (view source)
Revision as of 19:52, 30 September 2016
, 30 September 2016→Types of version control tools
| Line 16: | Line 16: | ||
Centralised version control has been very popular for years, where you have one centralised server and many remote clients. Examples are CVS, Subversion, Vault, Visual Source Safe and Team Foundation Server. These work very well when you are connected to the server. When not connected these are not giving much assistance. | Centralised version control has been very popular for years, where you have one centralised server and many remote clients. Examples are CVS, Subversion, Vault, Visual Source Safe and Team Foundation Server. These work very well when you are connected to the server. When not connected these are not giving much assistance. | ||
Distributed version control is the latest and most popular peer to peer version control tool. Examples are Mercurial (hg), GIT, BitKeeper etc. | Distributed version control is the latest and most popular peer to peer version control tool. Examples are Mercurial (hg), GIT, BitKeeper etc. | ||
This white paper focuses on the last category | This white paper focuses on the last category of distributed version control, with GIT in particular. | ||
If you are currently using a Centralised version control, you might be interested in the following list of major changes with the Distributed flavour; | If you are currently using a Centralised version control, you might be interested in the following list of major changes with the Distributed flavour; | ||
* No access to a server is required, the distributed VC has a local repository that gets synch’ed with a remote (central or peer to peer) repository when it can but can work fine on its own. | * No access to a server is required, the distributed VC has a local repository that gets synch’ed with a remote (central or peer to peer) repository when it can but can work fine on its own. | ||
* Each developer has | * Each developer has his own repository local to their working directory | ||
* No file checkout is required, just start changing the files | * No file checkout is required, just start changing the files | ||
* You can stage a number of files, so multiple files can be part of one commit (maintaining the relationship of the changes in the files) | * You can stage a number of files, so multiple files can be part of one commit (maintaining the relationship of the changes in the files) | ||