home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] does a DVCS *necessarily* mirror the entire repo history?

  • Subject: Re: [OCLUG-Tech] does a DVCS *necessarily* mirror the entire repo history?
  • From: Alex Pilon <alp [ at ] alexpilon [ dot ] ca>
  • Date: Thu, 22 Sep 2016 10:18:38 -0400
On Thu, Sep 22, 2016 at 07:43:34AM -0400, Robert P. J. Day wrote:
>   (side note: currently updating all my git wiki pages and tutorials,
> so i'll be asking a number of questions about git, including
> apparently trivial ones that might not be so trivial.)


>   pro git book makes the claim:
> "In a DVCS (such as Git, Mercurial, Bazaar or Darcs),

People still use the last two‽

> clients don’t just check out the latest snapshot of the files: they
> fully mirror the repository."
>   is that claim true in *every* case? as in, is there no "distributed"
> VCS that doesn't necessarily mirror the entire repo that was cloned or
> checked out?

At least Git can do shallow clones, though that's not the normal use

> i'm not sure how that would work but, theoretically, it
> might be possible to still have some sort of distributed operation
> where you don't have the entire repo history on your local machine.

If distributed file sharing and filesystems exist, a PoC DVCS should be
possible. How radically different of a departure from your Git workflow
were you imagining? Just lazy but automatic retrieval of history from
your remotes? Lazy push to your remotes? Seamless developer networks?
Lazy server push to past clients? Sharding? More?

Kiss goodbye to force push and history rewriting.

I don't want to deal with some of the consistency issues—race conditions
in some possible designs for a DVCS anyway. What if two people commit
and push at the same time?

Just don't try to make it work developer-to-developer. NAT's still
normal, and IPv6 is still a pipe dream.

Besides, doesn't Git emphasize distributed workflows more than
distributed storage? E.g., how the Linux kernel is developed in a
distributed fashion.