4 ms·

> and do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everyt

> and do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everything else. The D is DVCS is a waste of effort. Almost all projects are defacto centralized. In fact the D is anti-pattern that makes things like large binary files a still unsolved problem in Git. And no Git LFS doesn’t count. Source control should be capable for petabyte scale storage and terabyte scale partial clones, imho. Git feels like an inferior technology that succeeded and now we’re mostly stuck with it. Maybe someday someone will create a proper Perforce competitor and we can all migrate to something that’s actually good.

hprotagonist 3y ago
> The D is DVCS is a waste of effort. until the de facto centralized remote goes offline and you’re stuck with no local history …
- LordShredda 3y ago
  Not an issue, if remote goes down you can always restore from backup
  - hprotagonist 3y ago
    having been the guy who did that: i assure you, doing it is An Issue.
    - KerrAvon 3y ago
      I was once responsible for doing this with a Perforce server. Only time in my career a VCS has lost data. This was decades ago now and the data loss might have been due to hardware; I cannot definitively blame Perforce, but man was it shitty to deal with at the time. We migrated to Subversion and never had another issue.
      - hprotagonist 3y ago
        watching inodes fail before my eyes was … not an experience i’d care to repeat
- kstrauser 3y ago
  Or on a plane. It’s nice to have 100% of its functionality when you have 0% of your usual connectivity. Branches, commits, merges, all from the local file system? Yes, please. There’s a reason we moved off centralized VCS en masse.
  - forrestthewoods 3y ago
    Sorry, but you’re completely and objectively wrong. This is a huge misnomer. Distributed and “offline support” are fully orthogonal features. Distributed means every user has a full copy of the entire repo including full history. This is a radical and unnecessary limitation on the scope and size of source control. You can have full support for branching, commits, and merges without a fully distributed repo. There are numerous examples of this.
    - yjftsjthsd-h 3y ago
      > Distributed means every user has a full copy of the entire repo including full history. Then git must not be a DVCS; I use shallow clones all the time. In any event, centralized systems probably can do offline support, at least in theory, but DVCSs more or less include it for free by default, which is still worth something.
    - kstrauser 3y ago
      That's an interesting, and wrong, definition of "wrong". Git, Mercurial, and the like make every full copy of the repo equal. By convention, we often use central repos like GitHub, and commands like "git fetch" and "git push" as fast ways to sync their contents. We don't have to, though. I can clone a remote repo, then work independently for months. I do this all the time with the Mastodon server I run. I periodically pull in upstream changes, merge them into my working copy, then push those changes out to my worker instances. I might SSH into one of those servers, fix something specific to it, push the changes out to the other local servers so that they're all synced, and repeat for weeks and months on end. And because each of those repos are equally "official", all branching and merging operations are equally easy on each one of the peer machines. Although it's conceptually possible that it could be just as easy on a VCS that doesn't work with full clones, I've never seen it.
- genocidicbunny 3y ago
  I would love to see a DVCS that can effectively handle repos of the size I've seen. How well does DVCS work when your repo shallow copy is about 10TB?
  - hprotagonist 3y ago
    https://github.com/microsoft/VFSForGit https://github.com/microsoft/VFSForGit better than it used to, with the caveat that git in particular is not and has never claimed to be good at versioning blobs.
- layer8 3y ago
  Local history doesn’t imply D. The D basically means that clients and servers are equivalent. You could have a centralized VCS with client-server asymmetry and still have local history.
fritzo 3y ago
That D in DVCS is much appreciated when my power goes off, my internet goes down, etc.
- deleted 3y ago
  [deleted]
- forrestthewoods 3y ago
  Unrelated. Centralized version control systems are capable of offline mode.
- eesmith 3y ago
  You might appreciate then how fossil improves on git. When that happens with fossil you can also still update the issue tracker and wiki, while many (most?) people depends on a centralized system like GitHub or GitLab for the latter.
gorjusborg 3y ago
Binaries aren't source code. It sounds like you want a versioned file system, not source control. Git is a beautiful solution for its use case.
- forrestthewoods 3y ago
  Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. Its a god damn shame how much of our businesses use “stuff_final_final_05.psd” for “version control”.
  - gorjusborg 3y ago
    Seems like you are just complaining that something useful to a great many people isn't perfect for you particular use case. Use something thats's a better fit for your use case. There's nothing wrong with a hammer, you just want a screwdriver.
    - genocidicbunny 3y ago
      Except it seems the world keeps insisting that I use the hammer to bash on the screws.
      - gorjusborg 3y ago
        Sure, if someone is forcing you to use a tool unfit for the purpose, that's bound to frustrate you. That's not really a problem with the tool, though. That's a social problem.
      - happymellon 3y ago
        The world wants you to use git for binary file versioning? I have never encountered that. Binary files are generally kept in something like SharePoint, where it is SharePoint which is then hated by everyone. It's interesting that regardless of the tool, everyone seems to hate it. Perhaps if all tools are wrong, you are trying to force a bad usecase?
johannes1234321 3y ago
There are features which make life a lot better when you have them: A local search to explore, a way to stash the working state to try something out etc. and once you got those you have mostly a distributed VCS. True the flexibility of multiple remotes and tracking branches most users probably don't need, but it's quite nice for various things, and be it only a simple backup way. On an aside: I always chuckle on the "distributed" VCS. Back in the days some people refered to CVS as a distributed VCS, comparing to RCS.
KerrAvon 3y ago
Counterpoint: Lots of people actually use and like the D aspect. It’s one of the best things about Git! Local git repos can be shallow or partial clones if you insist on it. You say elsewhere that a VCS should support an offline mode instead, but if that’s not a copy of the repository, how is it in any way equivalent and what exactly is the difference? I’ve never understood why people like Perforce; I’ve assumed it’s some kind of weird nostalgia for mainframe user interfaces. I understand that it handles some kinds of large assets better than Git, but Perforce is so bad at everything else.
- forrestthewoods 3y ago
  People don’t necessarily “like” Perforce. However it is functional for professional game projects, and other systems like Git and Mercurial are not. Perforce is ripe for disruption. > if that’s not a copy of the repository, how is it in any way equivalent and what exactly is the difference? “Distributed” implies the user machine is at least capable of downloading the full repo history. Git defaults to full clones and has various shallow clone features. It also implies support for extremely convoluted graphs and edge cases. Offline implies a single central hub you connect to and sync with at some later point. I expect the only use case for downloading full history to be for backup purposes. Almost all operations can be performed without having access to every version of every file.
- maccard 3y ago
  I like perforce. It scales significantly better than git, (running git status on a large project, or cloning one takes significantly longer via git than p4). Not having the entire history of a project locally on disk is a pro to me, not a con. P4merge is orders of magnitude better than git's. Atomically incrementing numbers for changelists are superior to sha's if the first thing you do is implement version numbers on top of git. The default workflow is sane and teachable in all of 10 minutes even to non technical people (designers, artists). I like that history is immutable - there are admin tools available if surgery is needed. P4 isnt perfect, but it's definitely got significant advantages over git in many areas.

hprotagonist 3y ago

> The D is DVCS is a waste of effort. until the de facto centralized remote goes offline and you’re stuck with no local history …

LordShredda 3y ago
Not an issue, if remote goes down you can always restore from backup
- hprotagonist 3y ago
  having been the guy who did that: i assure you, doing it is An Issue.
  - KerrAvon 3y ago
    I was once responsible for doing this with a Perforce server. Only time in my career a VCS has lost data. This was decades ago now and the data loss might have been due to hardware; I cannot definitively blame Perforce, but man was it shitty to deal with at the time. We migrated to Subversion and never had another issue.
    - hprotagonist 3y ago
      watching inodes fail before my eyes was … not an experience i’d care to repeat
kstrauser 3y ago
Or on a plane. It’s nice to have 100% of its functionality when you have 0% of your usual connectivity. Branches, commits, merges, all from the local file system? Yes, please. There’s a reason we moved off centralized VCS en masse.
- forrestthewoods 3y ago
  Sorry, but you’re completely and objectively wrong. This is a huge misnomer. Distributed and “offline support” are fully orthogonal features. Distributed means every user has a full copy of the entire repo including full history. This is a radical and unnecessary limitation on the scope and size of source control. You can have full support for branching, commits, and merges without a fully distributed repo. There are numerous examples of this.
  - yjftsjthsd-h 3y ago
    > Distributed means every user has a full copy of the entire repo including full history. Then git must not be a DVCS; I use shallow clones all the time. In any event, centralized systems probably can do offline support, at least in theory, but DVCSs more or less include it for free by default, which is still worth something.
  - kstrauser 3y ago
    That's an interesting, and wrong, definition of "wrong". Git, Mercurial, and the like make every full copy of the repo equal. By convention, we often use central repos like GitHub, and commands like "git fetch" and "git push" as fast ways to sync their contents. We don't have to, though. I can clone a remote repo, then work independently for months. I do this all the time with the Mastodon server I run. I periodically pull in upstream changes, merge them into my working copy, then push those changes out to my worker instances. I might SSH into one of those servers, fix something specific to it, push the changes out to the other local servers so that they're all synced, and repeat for weeks and months on end. And because each of those repos are equally "official", all branching and merging operations are equally easy on each one of the peer machines. Although it's conceptually possible that it could be just as easy on a VCS that doesn't work with full clones, I've never seen it.
genocidicbunny 3y ago
I would love to see a DVCS that can effectively handle repos of the size I've seen. How well does DVCS work when your repo shallow copy is about 10TB?
- hprotagonist 3y ago
  https://github.com/microsoft/VFSForGit https://github.com/microsoft/VFSForGit better than it used to, with the caveat that git in particular is not and has never claimed to be good at versioning blobs.
layer8 3y ago
Local history doesn’t imply D. The D basically means that clients and servers are equivalent. You could have a centralized VCS with client-server asymmetry and still have local history.

fritzo 3y ago

That D in DVCS is much appreciated when my power goes off, my internet goes down, etc.

deleted 3y ago
[deleted]
forrestthewoods 3y ago
Unrelated. Centralized version control systems are capable of offline mode.
eesmith 3y ago
You might appreciate then how fossil improves on git. When that happens with fossil you can also still update the issue tracker and wiki, while many (most?) people depends on a centralized system like GitHub or GitLab for the latter.

gorjusborg 3y ago

Binaries aren't source code. It sounds like you want a versioned file system, not source control. Git is a beautiful solution for its use case.

forrestthewoods 3y ago
Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. Its a god damn shame how much of our businesses use “stuff_final_final_05.psd” for “version control”.
- gorjusborg 3y ago
  Seems like you are just complaining that something useful to a great many people isn't perfect for you particular use case. Use something thats's a better fit for your use case. There's nothing wrong with a hammer, you just want a screwdriver.
  - genocidicbunny 3y ago
    Except it seems the world keeps insisting that I use the hammer to bash on the screws.
    - gorjusborg 3y ago
      Sure, if someone is forcing you to use a tool unfit for the purpose, that's bound to frustrate you. That's not really a problem with the tool, though. That's a social problem.
    - happymellon 3y ago
      The world wants you to use git for binary file versioning? I have never encountered that. Binary files are generally kept in something like SharePoint, where it is SharePoint which is then hated by everyone. It's interesting that regardless of the tool, everyone seems to hate it. Perhaps if all tools are wrong, you are trying to force a bad usecase?

johannes1234321 3y ago

There are features which make life a lot better when you have them: A local search to explore, a way to stash the working state to try something out etc. and once you got those you have mostly a distributed VCS. True the flexibility of multiple remotes and tracking branches most users probably don't need, but it's quite nice for various things, and be it only a simple backup way. On an aside: I always chuckle on the "distributed" VCS. Back in the days some people refered to CVS as a distributed VCS, comparing to RCS.

KerrAvon 3y ago

Counterpoint: Lots of people actually use and like the D aspect. It’s one of the best things about Git! Local git repos can be shallow or partial clones if you insist on it. You say elsewhere that a VCS should support an offline mode instead, but if that’s not a copy of the repository, how is it in any way equivalent and what exactly is the difference? I’ve never understood why people like Perforce; I’ve assumed it’s some kind of weird nostalgia for mainframe user interfaces. I understand that it handles some kinds of large assets better than Git, but Perforce is so bad at everything else.

forrestthewoods 3y ago
People don’t necessarily “like” Perforce. However it is functional for professional game projects, and other systems like Git and Mercurial are not. Perforce is ripe for disruption. > if that’s not a copy of the repository, how is it in any way equivalent and what exactly is the difference? “Distributed” implies the user machine is at least capable of downloading the full repo history. Git defaults to full clones and has various shallow clone features. It also implies support for extremely convoluted graphs and edge cases. Offline implies a single central hub you connect to and sync with at some later point. I expect the only use case for downloading full history to be for backup purposes. Almost all operations can be performed without having access to every version of every file.
maccard 3y ago
I like perforce. It scales significantly better than git, (running git status on a large project, or cloning one takes significantly longer via git than p4). Not having the entire history of a project locally on disk is a pro to me, not a con. P4merge is orders of magnitude better than git's. Atomically incrementing numbers for changelists are superior to sha's if the first thing you do is implement version numbers on top of git. The default workflow is sane and teachable in all of 10 minutes even to non technical people (designers, artists). I like that history is immutable - there are admin tools available if surgery is needed. P4 isnt perfect, but it's definitely got significant advantages over git in many areas.