3 ms·

I have literally 0 inside knowledge but from the article it seems to be a more human visual thing than a software problem, something like this was working in 12

by Trufa 4y ago

I have literally 0 inside knowledge but from the article it seems to be a more human visual thing than a software problem, something like this was working in 12 and broken in 13 is a more obvious regression than this was working in aaab131 and broken in ccad53s

LeifCarrotson 4y ago
13 being greater than 12 is not a property that's just for human vision. In Subversion a commit on a branch increments the global commit number. Git doesn't have a concept of one commit being before or after another once you've branched, or any native mechanism for enforcing global state across branches.
mattkrause 4y ago
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.

by Trufa 4y ago

LeifCarrotson 4y ago

13 being greater than 12 is not a property that's just for human vision. In Subversion a commit on a branch increments the global commit number. Git doesn't have a concept of one commit being before or after another once you've branched, or any native mechanism for enforcing global state across branches.

mattkrause 4y ago

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.