5 ms·

Where I work nobody enforces which RCS to use so we have lots of SVN, lots of git and some Perforce and maybe another oddball somewhere. Even though it's ugly

Where I work nobody enforces which RCS to use so we have lots of SVN, lots of git and some Perforce and maybe another oddball somewhere. Even though it's ugly I'm sold on git but every time I recommend it to someone who is not used to it I tell them: "get used to the idea that you only ever have one version of your source on your PC, no concurrent branches in different directories." I know git half-heartedly supports multiple working trees but I think you're best off doing the "commit-WIP-then-branch" approach. Even stash is pretty ugly, I only use it for things like config files someone committed that I in turn would never commit (like IDE proj files, etc.)

lowbloodsugar 6y ago
Which is, of course, bollocks, because the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. The only difference between git and perforce is that in perforce, the concept of directory<->branch is built into the system, but with git, git knows nothing about it and its all manual. Instead, git is one of the VCS that says "you can have only one working copy on disk" and when you switch branches we'll believe that you want to throw away what you were just working on. I used to think the "one directory" for everything was the way to go. In a startup around 2001, I tried ten different VCS systems, including looking for ones I'd never heard of (e.g. AccuRev), and I initially vetoed perforce because it wanted to put different branches in different folders. When all was said and done, I selected perforce for precisely that reason. But git goes further than simply not having "multiple checked out branches" as a concept. Instead, its conceptual model for why I have branches and what I want to do with them is fundamentally wrong, as this article points out.
- formerly_proven 6y ago
  > because the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. This doesn't make any sense, at all, in any way or form to me. Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. > and when you switch branches we'll believe that you want to throw away what you were just working on. Switching branches checks if something would be thrown away, and will not proceed if that is the case.
  - lowbloodsugar 6y ago
    >Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. I am so sorry. That sounds awful. Life doesn't have to be that way.
  - tsimionescu 6y ago
    Aren't the IDE and build system files IN the repo? Normally if I clone a repo from scratch, all I have to do to build is `cd new-location/ && make`, and similarly to import in the IDE (though of course that will take some extra time, because I'll be forced to do a clean build, probably also re-downloading all dependencies).
    - zwieback 6y ago
      Yes, they are in the repo but we usually have one developer own those and manage the check-ins. That avoids minor differences in those files, which sometimes depend on details of the workstation setup. There's probably a better way to handle this
    - formerly_proven 6y ago
      I mean sure but it turns this: - Checkout different branch - Continue working Into this: - Checkout branch into new location - (Close project in IDE) - Browse to branch location, open IDE - Move all terminal $PWDs to the new location, as needed - Make a coffee while the IDE re-indexes everything - (Compiled languages: Hit make, enjoy another coffee while the build runs) - (npm and similarly structured projects: Hit install, enjoy another coffee while all dependencies are being fetched/checked/installed) And I just don't see how that's desirable. With git I can create, merge and switch between branches in seconds, and don't really have any problems (I've almost never felt the need to have two branches checked out at the same time). But with tree-per-branch I only see problems, and all branch-related operations become slow and annoying. One use case I could imagine where this is useful if you are simultaneously maintaining several mainline branches. But even within those "work areas" I'd rather be able to quickly switch branches.
      - 6y ago
- etripe 6y ago
  > the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. What do you base this statement on? The only people I've ever seen do this is those who are firmly entrenched in how TFS or SVN work. That's a far cry from "anybody".

lowbloodsugar 6y ago

Which is, of course, bollocks, because the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. The only difference between git and perforce is that in perforce, the concept of directory<->branch is built into the system, but with git, git knows nothing about it and its all manual. Instead, git is one of the VCS that says "you can have only one working copy on disk" and when you switch branches we'll believe that you want to throw away what you were just working on. I used to think the "one directory" for everything was the way to go. In a startup around 2001, I tried ten different VCS systems, including looking for ones I'd never heard of (e.g. AccuRev), and I initially vetoed perforce because it wanted to put different branches in different folders. When all was said and done, I selected perforce for precisely that reason. But git goes further than simply not having "multiple checked out branches" as a concept. Instead, its conceptual model for why I have branches and what I want to do with them is fundamentally wrong, as this article points out.

formerly_proven 6y ago
> because the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. This doesn't make any sense, at all, in any way or form to me. Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. > and when you switch branches we'll believe that you want to throw away what you were just working on. Switching branches checks if something would be thrown away, and will not proceed if that is the case.
- lowbloodsugar 6y ago
  >Everything from build systems to IDEs is tied to were the tree is, I most certainly _don't_ want to constantly change that. I am so sorry. That sounds awful. Life doesn't have to be that way.
- tsimionescu 6y ago
  Aren't the IDE and build system files IN the repo? Normally if I clone a repo from scratch, all I have to do to build is `cd new-location/ && make`, and similarly to import in the IDE (though of course that will take some extra time, because I'll be forced to do a clean build, probably also re-downloading all dependencies).
  - zwieback 6y ago
    Yes, they are in the repo but we usually have one developer own those and manage the check-ins. That avoids minor differences in those files, which sometimes depend on details of the workstation setup. There's probably a better way to handle this
  - formerly_proven 6y ago
    I mean sure but it turns this: - Checkout different branch - Continue working Into this: - Checkout branch into new location - (Close project in IDE) - Browse to branch location, open IDE - Move all terminal $PWDs to the new location, as needed - Make a coffee while the IDE re-indexes everything - (Compiled languages: Hit make, enjoy another coffee while the build runs) - (npm and similarly structured projects: Hit install, enjoy another coffee while all dependencies are being fetched/checked/installed) And I just don't see how that's desirable. With git I can create, merge and switch between branches in seconds, and don't really have any problems (I've almost never felt the need to have two branches checked out at the same time). But with tree-per-branch I only see problems, and all branch-related operations become slow and annoying. One use case I could imagine where this is useful if you are simultaneously maintaining several mainline branches. But even within those "work areas" I'd rather be able to quickly switch branches.
    - 6y ago
etripe 6y ago
> the first thing anybody does when working on a hotfix is to create a new directory and create a new tree there. What do you base this statement on? The only people I've ever seen do this is those who are firmly entrenched in how TFS or SVN work. That's a far cry from "anybody".