4 ms·

They're still teaching them about branches, pull requests, commit messages, merging, and build statuses. Not to mention that mixing data and code into the same

They're still teaching them about branches, pull requests, commit messages, merging, and build statuses. Not to mention that mixing data and code into the same versioning system adds complexity that I don't think is maintainable. There is a reason we tend to version data separately from code.

rpedela 9y ago
What complexity is added by keeping data in the tree? If we are talking about GB+ datasets, then yes that shouldn't be stored in the tree. But a small list of products that needs to be manually updated regardless of where it is stored? That is perfectly fine to store in the tree and I think the author was talking about that sort of data. As always, it depends on the data. Sometimes git is fine. Sometimes you need S3. Sometimes Postgres. There is no one size fits all solution.
- learc83 9y ago
  What complexity is added by keeping data in the tree? Polluting the commit logs with thousands of extra commit messages if you're dealing with fast changing data for one. If a developer is working on a "data file" that happens to contain logic (its going to happen no matter how diligent you are about keeping them separate), dealing with unnecessary merging from the constant edits is another. >That is perfectly fine to store in the tree and I think the author was talking about that sort of data. The individual datasets may be small, but from reading the authors comments here, the scope of what they're storing this way seems to be way beyond what I'd feel comfortable managing this way.
madeofpalk 9y ago
No, they’re not. We’ve used this approach before we were able to intergrate required CMS, and it was fine. Our Product Owner would go into the YAML files in Github, click "Edit", make the changes, then hit the big green ”Create Pull Request" button. GitHub actually makes it fairly easy to do this flow and comes with sane default commit messages.
- learc83 9y ago
  >No, they’re not. The article explicitly mentions that they teach them these things.

rpedela 9y ago

What complexity is added by keeping data in the tree? If we are talking about GB+ datasets, then yes that shouldn't be stored in the tree. But a small list of products that needs to be manually updated regardless of where it is stored? That is perfectly fine to store in the tree and I think the author was talking about that sort of data. As always, it depends on the data. Sometimes git is fine. Sometimes you need S3. Sometimes Postgres. There is no one size fits all solution.

learc83 9y ago
What complexity is added by keeping data in the tree? Polluting the commit logs with thousands of extra commit messages if you're dealing with fast changing data for one. If a developer is working on a "data file" that happens to contain logic (its going to happen no matter how diligent you are about keeping them separate), dealing with unnecessary merging from the constant edits is another. >That is perfectly fine to store in the tree and I think the author was talking about that sort of data. The individual datasets may be small, but from reading the authors comments here, the scope of what they're storing this way seems to be way beyond what I'd feel comfortable managing this way.

madeofpalk 9y ago

No, they’re not. We’ve used this approach before we were able to intergrate required CMS, and it was fine. Our Product Owner would go into the YAML files in Github, click "Edit", make the changes, then hit the big green ”Create Pull Request" button. GitHub actually makes it fairly easy to do this flow and comes with sane default commit messages.

learc83 9y ago
>No, they’re not. The article explicitly mentions that they teach them these things.