6 ms·

> 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.
    - puchatek 3y ago
      Interesting usecase. The "git bad for everything else" commenter was probably unaware of it. That said, it's not very representative of what git is mostly used for and where there comparison with fossil is least favorable.
- lelanthran 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. You don't need the VCS to be a distributed VCS to have offline capability. > There’s a reason we moved off centralized VCS en masse. No, there's a reason we moved to git specifically. We didn't move to the competing DVCS, did we?
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.

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.
  - puchatek 3y ago
    Interesting usecase. The "git bad for everything else" commenter was probably unaware of it. That said, it's not very representative of what git is mostly used for and where there comparison with fossil is least favorable.
lelanthran 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. You don't need the VCS to be a distributed VCS to have offline capability. > There’s a reason we moved off centralized VCS en masse. No, there's a reason we moved to git specifically. We didn't move to the competing DVCS, did we?

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.