4 ms·

Managing dependencies and versions across repos is a pain. Refactoring across repos is quite hard when your code spreads across repos considering the tree of de

Managing dependencies and versions across repos is a pain. Refactoring across repos is quite hard when your code spreads across repos considering the tree of dependencies. Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases. The approach that Facebook chose with Mercurial seems a good compromise ( https://code.fb.com/core-data/scaling-mercurial-at-facebook/ https://code.fb.com/core-data/scaling-mercurial-at-facebook/ )

antt 8y ago
Git works very well when the code is distributed. Which funnily enough is in the name. That we are using git as a centralized repository is a case of "Why do I need a screwdriver when I have a hammer?".
- EpicEng 8y ago
  > Managing dependencies and versions across repos is a pain
- shub 8y ago
  There's nothing about git that requires you to use it like the kernel does. Centralized version control is just a special case of decentralized, if you're using git. You still get the benefits of your repo being a peer of the master repo, like local branches.
csdreamer7 8y ago
Doesn't the Git Virtual File system that Microsoft is contributing to Git take care of this? https://blogs.msdn.microsoft.com/devops/2017/02/03/announcing-gvfs-git-virtual-file-system/ https://blogs.msdn.microsoft.com/devops/2017/02/03/announcin... Edit: don't just down vote. If you have a problem with my comment, tell me why.
- justincormack 8y ago
  This currently only works on Windows, although they are planning OSX and Linux ports.
  - csdreamer7 8y ago
    That is important. My link was back in 2017. Do you know of any ETA for GVFS getting on Linux?
    - justincormack 8y ago
      I went to a talk earlier this year where they said they would do OSX before Linux. So it may be some time. There are design complexities in getting it to work, Windows has quite a different structure for filesystem drivers.
jsolson 8y ago
As mentioned in the post (which is from 2016), Google has also been experimenting with Mercurial as a frontend (in collaboration with "contributors from other companies that value the monolithic source model"). As an avid user of that experiment at Google, it's seems to be going very well.
- ChrisCinelli 8y ago
  I am not surprised. code.google.com used Mercurial. But I am still curious. Is Mercurial the frontend of Piper or it could live independently? What is open sourced and what is not?
  - kajecounterhack 8y ago
    Mercurial is used as a frontend to piper in that experiment. It doesn't live independently. Piper isn't open source.
deleted 8y ago
[deleted]
bluedino 8y ago
>> Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases A shallow clone can be helpful in cases like this
- justinjlynn 8y ago
  Shallow clones have some significant limitations in terms of the operations that can be performed on the resultant shallow image. It used to be quite severe but many of the initial limitations have been lifted with improved implementations. Still shallow clones are tricky to do deep in the tree, but they are a potential option for huge repos.

antt 8y ago

Git works very well when the code is distributed. Which funnily enough is in the name. That we are using git as a centralized repository is a case of "Why do I need a screwdriver when I have a hammer?".

EpicEng 8y ago
> Managing dependencies and versions across repos is a pain
shub 8y ago
There's nothing about git that requires you to use it like the kernel does. Centralized version control is just a special case of decentralized, if you're using git. You still get the benefits of your repo being a peer of the master repo, like local branches.

csdreamer7 8y ago

Doesn't the Git Virtual File system that Microsoft is contributing to Git take care of this? https://blogs.msdn.microsoft.com/devops/2017/02/03/announcing-gvfs-git-virtual-file-system/ https://blogs.msdn.microsoft.com/devops/2017/02/03/announcin... Edit: don't just down vote. If you have a problem with my comment, tell me why.

justincormack 8y ago
This currently only works on Windows, although they are planning OSX and Linux ports.
- csdreamer7 8y ago
  That is important. My link was back in 2017. Do you know of any ETA for GVFS getting on Linux?
  - justincormack 8y ago
    I went to a talk earlier this year where they said they would do OSX before Linux. So it may be some time. There are design complexities in getting it to work, Windows has quite a different structure for filesystem drivers.

jsolson 8y ago

As mentioned in the post (which is from 2016), Google has also been experimenting with Mercurial as a frontend (in collaboration with "contributors from other companies that value the monolithic source model"). As an avid user of that experiment at Google, it's seems to be going very well.

ChrisCinelli 8y ago
I am not surprised. code.google.com used Mercurial. But I am still curious. Is Mercurial the frontend of Piper or it could live independently? What is open sourced and what is not?
- kajecounterhack 8y ago
  Mercurial is used as a frontend to piper in that experiment. It doesn't live independently. Piper isn't open source.

deleted 8y ago

[deleted]

bluedino 8y ago

>> Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases A shallow clone can be helpful in cases like this

justinjlynn 8y ago
Shallow clones have some significant limitations in terms of the operations that can be performed on the resultant shallow image. It used to be quite severe but many of the initial limitations have been lifted with improved implementations. Still shallow clones are tricky to do deep in the tree, but they are a potential option for huge repos.