3 ms·

Sequential IDs also let you think about ranges: a feature was introduced in 11, broke in 17-23, and worked thereafter. I used SVN like this in grad school: dat

Sequential IDs also let you think about ranges: a feature was introduced in 11, broke in 17-23, and worked thereafter. I used SVN like this in grad school: data files included the SVN $Id$ of the script that generated them. This let you work around bugs and experimental changes. For example, you might hardcode a delay, realize it should be longer, and then eventually decide to let the experimenter adjust it on the fly. This is easy with sequential ids: if version < 11: delay = 50 elif 11 <= version < 29: delay = 100 else delay = params.delay Using git hashes, you'd need to maintain an exhaustive list of every version ever run, which is even tricker because there isn't a sole source of truth like an SVN repo.

cerved 4y ago
I must be missing something because this seems odd, why isn't this code just different in each corresponding version?
- mattkrause 4y ago
  The SVN-controlled code generated data by controlling hardware and embedded the $Id$ of the controlling script in its output. I would then refer to the version ID later, when loading that data in for analysis. This accounted for any changes to the data-generating code. For example, we tracked the orientation and direction of objects moving on a screen. One update redefined 0° to be up/north/12:00 instead of the +x direction used before. The code which loaded these files checked the $Id$ value and rotated the directional data so that the entire dataset used the same definition.
xfmpXIe76lF4GfR 4y ago
Git also lets you think about ranges. You just tell it the range and it figures out what commits are in the range. You can also get a sequential number from whatever point you choose with tools like `git describe`.
alerighi 4y ago
Git hashes are not for identifying versions but only to identify commit (that may not have a significance on their own, e.g. a developer uses more commits to implement a new feature!). To identify version you should use tags that can be written on the format you like. A tag is just a non mutable (unlike beaches) pointer to a particular commit. In my company we have the CI server that automatically creates a new tag (sequentially) each time one pushes on the master branch.

cerved 4y ago

I must be missing something because this seems odd, why isn't this code just different in each corresponding version?

mattkrause 4y ago
The SVN-controlled code generated data by controlling hardware and embedded the $Id$ of the controlling script in its output. I would then refer to the version ID later, when loading that data in for analysis. This accounted for any changes to the data-generating code. For example, we tracked the orientation and direction of objects moving on a screen. One update redefined 0° to be up/north/12:00 instead of the +x direction used before. The code which loaded these files checked the $Id$ value and rotated the directional data so that the entire dataset used the same definition.

xfmpXIe76lF4GfR 4y ago

Git also lets you think about ranges. You just tell it the range and it figures out what commits are in the range. You can also get a sequential number from whatever point you choose with tools like `git describe`.

alerighi 4y ago

Git hashes are not for identifying versions but only to identify commit (that may not have a significance on their own, e.g. a developer uses more commits to implement a new feature!). To identify version you should use tags that can be written on the format you like. A tag is just a non mutable (unlike beaches) pointer to a particular commit. In my company we have the CI server that automatically creates a new tag (sequentially) each time one pushes on the master branch.