4 ms·

It is an incredible failure of modern version control systems that distributed branching means that they're impossible for novices to use. However, if you see

It is an incredible failure of modern version control systems that distributed branching means that they're impossible for novices to use. However, if you see github.com as a proprietary UI for git, it looks almost exactly like putting your files on S3 with some CRUD UI around it.

learc83 9y ago
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.
busterarm 9y ago
> It is an incredible failure of modern version control systems that distributed branching means that they're impossible for novices to use. No it isn't. This is entirely a sales problem. You may not have noticed, but engineers typically can't use distributed branching either. The volume of tutorial and "i'm in trouble, plz hlp" material out there for Git (and really every other VCS) is substantial. Everyone has a story about how a certain workflow got them into trouble on a project. The thing is, collectively we see a huge value in it, so we make the learning investment to use it. It's only after we learn it (and the pitfalls to avoid) that it's easy. Novices don't use it because they haven't had the value proposition made to them yet. If you can reframe the argument for why, you'll get them using it.
- codemac 9y ago
  Entirely a sales problem.. but your next line you mention that engineers have significant troubles using current tools. Sounds like it's not just a sales problem to get novices to use distributed branch management correctly.. but maybe a design problem with the current tooling. If it requires significant experience to use a tool correctly, then it is impossible for novices to use as you must turn them into experienced users. My original comment was just to point out that GitHub is another UI on git repos, and thus might work around some of these design flaws.
  - busterarm 9y ago
    The point is that all tools are hard if you don't have context about why they work the way they do. All of the tutorials are aimed at engineers, walking them through problems that they have and workflows that they'll want to use. Git Immersion is probably the best one I've ever seen and it's still aimed at budding Ruby developers. Has anyone thought about doing this for content/marketing/design people? The tools that they use are hard too, but they know how because they were sufficiently motivated to learn them. It's a big mistake for engineers to think that their jobs and the tools they use are significantly harder than in other fields.
    - codemac 9y ago
cat199 9y ago
> It is an incredible failure of modern version control systems that distributed branching means that they're impossible for novices to use. no, people are usually lazy about being extra precise about tracking transaction state of any sort (in conversation, finance, rational discussion, etc), and moving this imprecision from a linear sequence into a tree and from there into a forest only compounds things. most of the problem with (d)VCS is that people are used to fuzzy transactional thinking, and furthermore, need to learn a new vocabulary to interact with it.

learc83 9y ago

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.

busterarm 9y ago

> It is an incredible failure of modern version control systems that distributed branching means that they're impossible for novices to use. No it isn't. This is entirely a sales problem. You may not have noticed, but engineers typically can't use distributed branching either. The volume of tutorial and "i'm in trouble, plz hlp" material out there for Git (and really every other VCS) is substantial. Everyone has a story about how a certain workflow got them into trouble on a project. The thing is, collectively we see a huge value in it, so we make the learning investment to use it. It's only after we learn it (and the pitfalls to avoid) that it's easy. Novices don't use it because they haven't had the value proposition made to them yet. If you can reframe the argument for why, you'll get them using it.

codemac 9y ago
Entirely a sales problem.. but your next line you mention that engineers have significant troubles using current tools. Sounds like it's not just a sales problem to get novices to use distributed branch management correctly.. but maybe a design problem with the current tooling. If it requires significant experience to use a tool correctly, then it is impossible for novices to use as you must turn them into experienced users. My original comment was just to point out that GitHub is another UI on git repos, and thus might work around some of these design flaws.
- busterarm 9y ago
  The point is that all tools are hard if you don't have context about why they work the way they do. All of the tutorials are aimed at engineers, walking them through problems that they have and workflows that they'll want to use. Git Immersion is probably the best one I've ever seen and it's still aimed at budding Ruby developers. Has anyone thought about doing this for content/marketing/design people? The tools that they use are hard too, but they know how because they were sufficiently motivated to learn them. It's a big mistake for engineers to think that their jobs and the tools they use are significantly harder than in other fields.
  - codemac 9y ago

cat199 9y ago

> It is an incredible failure of modern version control systems that distributed branching means that they're impossible for novices to use. no, people are usually lazy about being extra precise about tracking transaction state of any sort (in conversation, finance, rational discussion, etc), and moving this imprecision from a linear sequence into a tree and from there into a forest only compounds things. most of the problem with (d)VCS is that people are used to fuzzy transactional thinking, and furthermore, need to learn a new vocabulary to interact with it.