Some notes on why and how to use a Version Control system like Git

Just recording here for posterity some comments I made on Delphi Deverloper Facebook group on the benefits and practice of using a Git repository on an online service like GitHub.

The idea with Version Control is that you can track changes, rollback easily to previous versions, if there are many contributors you can track which changes/lines they contributed etc. – e.g. see how GitHub diffs online (each Git client can use other diff tool) between the previous and newer version for a commit: https://github.com/…/03b0d7d20668a18b611dacf3134d0cdd5d…

Ideally you make commits often (a commit can contain changes to multiple files, ideally for just one feature/bug you were working on) and push them to the remote repo regularly (for extra safety/backup too), but usually when the code is buildable.

Some teams also spawn branches from the main branch in their repository (similar to forks, but those are for third parties usually to make a derivative of your whole repo) to work on experimental stuff and they merge them (and can get rid of those branches then) with the main branch when the feature/fix they were working on is ready. That way they also keep their main branch always buildable and working for testers and power users. Via automation sometimes they "continuously" (see CI / Continuous Integration) make latest/nightly builds from that main branch.

Also from that main branch they regularly make releases for the rest of the users when they’re confident enough the app/library/driver etc. they build is stable to release.

Even for small projects it’s worth setting up a Git repository (can even have pure local ones [for history tracking] with no remote) now that version control systems have nice visual clients without having to learn commands and use from the command-line. People also use them to track other artifacts like documentation, ideally text based artifacts, but there are diff tools that can compare binaries too (like images shown side by side with differences highlighted). There are some version contorl sytems specialized for non-text based artifacts, but Git can store versions of binaries too, even though it is textline-change focused.

The easiest way to use the Git repositories that GitHub offers for free (now backed by Microsoft so it will exist for years to come) is to install the GitHub Desktop app from their site (first you make a free account from their website). Then you can sync your local files to a public repository you make there (you commit updates to your local clone of the remote repository, then push the commits from the local clone to the remote repository). Others can make forks of that repository and work on their own versions and GitHub makes it easy to make pull requests (initiated by them or you) and merge changes from forks of your original repository into your own if/when you wish.

So it has the benefits of Git-based Version Control with extras too like optional Discussions, Wiki, Issue/Enhancement tracking, Milestones and Releases, Projects with Kanban boards and automated movement of tasks between columns on those boards etc.

There also other similar services like GitLab etc., but GitHub is probably the easiest to use and quite generous in offerings for OpenSource projects nowadays.

Fix: TortoiseHg not commiting files

It seems that sometimes TortoiseHg Mercurial (Hg) client on Windows fails to remove a 0-byte-sized file named “wlock” (a write lock to avoid simultaneous write to a local repository) in the “.hg” subfolder that holds a local repository.

This results in the Commit dialog never commiting changed/removed/added files and you have to press Close there and confirm cancelation of the commit action. After trying multiple times and even rebooting I realized that deleting that “wlock” file fixed the issue and could then open up TortoiseHg commit dialog again to retry the commit action (luckily it remembers the commit message from the last effort, you just have to select which files to commit again.

The default seems to be to commit only modified files, thus if files have been removed or added you have to select them. Note that selecting the 3-state checkbox at the top selects/deselects all files quickly.

Then you can proceed from the “Hg Workbench” dialog (available when you right click in Windows Explorer the folder name that contains the “.hg” subfolder) to sync the local changes with any external repository you’re using. Hg is a distributed version control, unlike other centralized ones, so you can commit even without a network connection available, since it is commiting to the local repository.