4 ms·

I think they don't branch code because perforce branches are horrible and merging them back to HEAD is extremely painful process for monorep.

raverbashing 8y ago
So, use a better tool?
- philosopher1234 8y ago
  Or, don’t branch. Is branching so essential?
  - lordnacho 8y ago
    Isn't it essential for mental organisation? How do you think about what's different about a set of changes without some sort of DAG?
    - hopler 8y ago
      Make one change at a time.
    - yjftsjthsd-h 8y ago
      Just do one thing at a time? Today, I am working on X; my commits are for X, and details are in the commit message.
      - dharmab 8y ago
        That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.
        addicted 8y ago
        How often does that happen to an individual developer though? Once a month? In an averagely well run company even that may be towards the higher end. Should your entire development strategy be based on a once a month occurrence?
        idontpost 8y ago
        > Once a month? Closer to once a week for me.
    - username90 8y ago
      They are grouped by linking them to issues in the issue tracker. All commits will then get a link to the issue and the issue gets a link back to the commit. This way you can easily track and read the full context of old changes. Example issue, note that public ones are not associated with commits: https://issuetracker.google.com/issues/122326181 https://issuetracker.google.com/issues/122326181
  - raverbashing 8y ago
    If you don't want to be stuck while a colleague does changes that conflict with what you're changing then yes, you need branching.
    - hknd 8y ago
      You don't need branching for this. If 2+ people are working on the same file which might result into a conflict, you can either: - handle the conflict as soon as you merge your branches somewhen in the future or - handle it when trying to commit your change to head Only difference is whether you handle the conflict now, or in the future.
    - hopler 8y ago
      You need to communicate with your colleagues to coordinate your work.
- StreamBright 8y ago
  What do you mean? Branching is not a solved problem once people are editing the same files.
  - ashelmire 8y ago
    Git is actually pretty good at automatically resolving conflicts within files; unless you edit the same lines, it’s easy. If you do edit the same lines, merging is pretty straightforward. This whole conversation the last day or two on HN has been kind of nuts. Like everybody agrees you shouldn’t put all your code in a single file, right? Why not? It would let everyone see all of the source code in one place! But it would be huge and hard to avoid conflicts. So we split things into files. Then “trees”, etc... Basically it sounds like googles monorepo is really a bunch of repos glued together with changes in one triggering changes in others. The difference, it seems, is that google does not get to benefit from the things OS developers like about git. It’s like google developed custom versions of GitHub, circleci, and other tools and are marketing that as a better solution (just build several billion dollar solutions to manage your monorepo!). And even after all that, google has a bunch of separate repos for important open source or secret work.
    - StreamBright 8y ago
      Sure, so here is a challenge for you. Original file: a = 1 Contributor X: a = 5 Contributor Y: a = 0 Both contributors created a pull request and submitted it. In the description they both state that the new value should be the one they put it. How would you resolve this issue in a timely fashion making sure you do not take down a service accidentally and do not slow down development too much. I intentionally gave you a very simple example but if you want we can go into rolling out new features, fixing security bugs and a lot more where such issues arise. And, no git will never be able to solve these issues. I don't think that HN going nuts (except few zealots) and these problems come from the nature of software development in general. We have seen how Google solves these (monorepo, custom CI/CD, etc. etc.) and there are other companies solving it different ways (maybe have a branching model, using Github). People are just putting out here they experience and based on that and they level of understanding the perceived solutions.
StreamBright 8y ago
Even git or hg branches are horrible. Once you have multiple people working on the same codebase and touching the same files it is pretty horrid to manage. I know several companies not using branches because the merge conflict resolution takes too much time. The PDF explicitly calls out the time consuming part: "Almost all development occurs at the “head” of the repository, not on branches. This helps identify integration problems early and minimizes the amount of merging work needed. It also makes it much easier and faster to push out security fixes."
- sigsergv 8y ago
  Rebased branches in git are nice (for one developer only unfortunately), there are some pain of course but when rebase is performed often (once a day) it consumes not so much of time. The real pain begins when some huge commit is pushed to HEAD but it still manageable. Anyway, I feel sad that so much efforts were put on really nice VCS concepts and almost no one use them in enterprise development.
dilyevsky 8y ago
Google havent been using p4 since around 2013
- sigsergv 8y ago
  Piper interface and workflow is heavily influenced by perforce.
  - dilyevsky 8y ago
    Except it’s now highly scalable that is taking care of branching performance. Nothing technically making it difficult to branch afaik. In fact rapid (grape) used it pretty heavily to track rollouts if I remember correctly.

raverbashing 8y ago

So, use a better tool?

philosopher1234 8y ago
Or, don’t branch. Is branching so essential?
- lordnacho 8y ago
  Isn't it essential for mental organisation? How do you think about what's different about a set of changes without some sort of DAG?
  - hopler 8y ago
    Make one change at a time.
  - yjftsjthsd-h 8y ago
    Just do one thing at a time? Today, I am working on X; my commits are for X, and details are in the commit message.
    - dharmab 8y ago
      That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.
      - addicted 8y ago
        How often does that happen to an individual developer though? Once a month? In an averagely well run company even that may be towards the higher end. Should your entire development strategy be based on a once a month occurrence?
        idontpost 8y ago
        > Once a month? Closer to once a week for me.
  - username90 8y ago
    They are grouped by linking them to issues in the issue tracker. All commits will then get a link to the issue and the issue gets a link back to the commit. This way you can easily track and read the full context of old changes. Example issue, note that public ones are not associated with commits: https://issuetracker.google.com/issues/122326181 https://issuetracker.google.com/issues/122326181
- raverbashing 8y ago
  If you don't want to be stuck while a colleague does changes that conflict with what you're changing then yes, you need branching.
  - hknd 8y ago
    You don't need branching for this. If 2+ people are working on the same file which might result into a conflict, you can either: - handle the conflict as soon as you merge your branches somewhen in the future or - handle it when trying to commit your change to head Only difference is whether you handle the conflict now, or in the future.
  - hopler 8y ago
    You need to communicate with your colleagues to coordinate your work.
StreamBright 8y ago
What do you mean? Branching is not a solved problem once people are editing the same files.
- ashelmire 8y ago
  Git is actually pretty good at automatically resolving conflicts within files; unless you edit the same lines, it’s easy. If you do edit the same lines, merging is pretty straightforward. This whole conversation the last day or two on HN has been kind of nuts. Like everybody agrees you shouldn’t put all your code in a single file, right? Why not? It would let everyone see all of the source code in one place! But it would be huge and hard to avoid conflicts. So we split things into files. Then “trees”, etc... Basically it sounds like googles monorepo is really a bunch of repos glued together with changes in one triggering changes in others. The difference, it seems, is that google does not get to benefit from the things OS developers like about git. It’s like google developed custom versions of GitHub, circleci, and other tools and are marketing that as a better solution (just build several billion dollar solutions to manage your monorepo!). And even after all that, google has a bunch of separate repos for important open source or secret work.
  - StreamBright 8y ago
    Sure, so here is a challenge for you. Original file: a = 1 Contributor X: a = 5 Contributor Y: a = 0 Both contributors created a pull request and submitted it. In the description they both state that the new value should be the one they put it. How would you resolve this issue in a timely fashion making sure you do not take down a service accidentally and do not slow down development too much. I intentionally gave you a very simple example but if you want we can go into rolling out new features, fixing security bugs and a lot more where such issues arise. And, no git will never be able to solve these issues. I don't think that HN going nuts (except few zealots) and these problems come from the nature of software development in general. We have seen how Google solves these (monorepo, custom CI/CD, etc. etc.) and there are other companies solving it different ways (maybe have a branching model, using Github). People are just putting out here they experience and based on that and they level of understanding the perceived solutions.

StreamBright 8y ago

Even git or hg branches are horrible. Once you have multiple people working on the same codebase and touching the same files it is pretty horrid to manage. I know several companies not using branches because the merge conflict resolution takes too much time. The PDF explicitly calls out the time consuming part: "Almost all development occurs at the “head” of the repository, not on branches. This helps identify integration problems early and minimizes the amount of merging work needed. It also makes it much easier and faster to push out security fixes."

sigsergv 8y ago
Rebased branches in git are nice (for one developer only unfortunately), there are some pain of course but when rebase is performed often (once a day) it consumes not so much of time. The real pain begins when some huge commit is pushed to HEAD but it still manageable. Anyway, I feel sad that so much efforts were put on really nice VCS concepts and almost no one use them in enterprise development.

dilyevsky 8y ago

Google havent been using p4 since around 2013

sigsergv 8y ago
Piper interface and workflow is heavily influenced by perforce.
- dilyevsky 8y ago
  Except it’s now highly scalable that is taking care of branching performance. Nothing technically making it difficult to branch afaik. In fact rapid (grape) used it pretty heavily to track rollouts if I remember correctly.