Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need a new generation of source control

rookout.com

Post reply on HN
Print view View original

11–20 of 90 posts

Re: We need a new generation of source control

#11

Post by jessemillar »

klodolph wrote: post #7
kadendogthing wrote: post #4

As I've stated in another post on here, what's the point of these articles? It just says everything sucks, but doesn't really dive into why or how we could possibly fix any issues they may directly point out. Also it kind of sounds like the author really doesn't have any idea what GitLab is or does, so maybe he should check it out. But allow me to retort these bald assertions presented in the article: Monorepos are g…

> Git is the best source control system ever. To be clear, I'm not disagreeing. But it is simply not good enough. Any new generation of source control needs to be able to do things that are difficult with Git, and Git simply isn't extensible enough. Microsoft has a Git VFS, and there's Git LFS, but this just doesn't go far enough. There are good technical reasons why you would use Perforce or even Subversion these da…

Out of genuine curiosity, do you know of any resources you could point me to to explore specific situations where Git isn't fitting the bill technologically?

Re: We need a new generation of source control

#12

Post by zdragnar »

The title felt a bit misleading- this is more a gripe of git and the approaches to mono and multi repos with git.

I'm not following the call for something new, though:

> A source control that treats CI, CD, and releases as first-class citizens, rather than relying on the very useful add-ons provided by GitHub and its community.

I'm not a die-hard every-tool-should-do-exactly-one-thing-the-way-the-unix-gods-intended type of person, but in this case, I really feel that source control should stick to being source control. Hooks and add-ons are great precisely because things like CI and CD came after, and who knows what the new rage will be 5 or 10 years from now.

Building everything for today's workflow into a single tool means that by the time it's ready, the "today's" workflow won't be cool anymore, and we'll have other newer tools and processes that this new source control can't support :/

Re: We need a new generation of source control

#13

Post by sanderjd »

Isn't the argument here that Git is not good at mono-repos rather than that mono-repos suck? This seems true to me, but there are already other options that suck less if you want the advantages of a mono-repo.

I would also suggest that mono-repos work better with statically typed languages with module boundaries and visibility control. The problem of anything being able to touch anything else is not so bad when you can hide implementation details behind small APIs.

I have definitely felt some pain with having Ruby projects in a single repo using git, but much less so with Java projects using Hg.

Re: We need a new generation of source control

#14

Post by tyrust »

kadendogthing wrote: post #4

As I've stated in another post on here, what's the point of these articles? It just says everything sucks, but doesn't really dive into why or how we could possibly fix any issues they may directly point out. Also it kind of sounds like the author really doesn't have any idea what GitLab is or does, so maybe he should check it out. But allow me to retort these bald assertions presented in the article: Monorepos are g…

>what's the point of these articles?

Content marketing.

Re: We need a new generation of source control

#16

Post by sanderjd »

zdragnar wrote: post #12

The title felt a bit misleading- this is more a gripe of git and the approaches to mono and multi repos with git. I'm not following the call for something new, though: > A source control that treats CI, CD, and releases as first-class citizens, rather than relying on the very useful add-ons provided by GitHub and its community. I'm not a die-hard every-tool-should-do-exactly-one-thing-the-way-the-unix-gods-intended t…

You can already adapt mercurial to do different stuff very much like the author suggests. As a user (but not developer) of such adaptations, I think it works really well.

Re: We need a new generation of source control

#17

Post by emcq »

hashkb wrote: post #10
klodolph wrote: post #7

Earlier quoted context omitted.

> Git is the best source control system ever. To be clear, I'm not disagreeing. But it is simply not good enough. Any new generation of source control needs to be able to do things that are difficult with Git, and Git simply isn't extensible enough. Microsoft has a Git VFS, and there's Git LFS, but this just doesn't go far enough. There are good technical reasons why you would use Perforce or even Subversion these da…

> There are good technical reasons why you would use Perforce or even Subversion days. Can you say more? What are some of those reasons? Or link to some data or examples?

Partial checkouts is the main thing that comes to mind that is better with svn than git.

Re: We need a new generation of source control

#18

Post by bitwize »

weberc2 wrote: post #8
mikece wrote: post #5

I like the idea of creating a source control protocol that can be implemented with any number of tools rather than having wars over particular implementations of source control products. (And would Git really have beaten Mercurial if GitHub had been HgHub instead? GitHub's success was more about process than the technology of Git, IMO.)

> And would Git really have beaten Mercurial if GitHub had been HgHub instead? GitHub's success was more about process than the technology of Git, IMO. Hg is a much better user experience than git, that's for sure. Git won because of Github, which may have beaten any HgHub simply because Git has an actual API while Mercurial's "API" is "use subprocessing". In other words, if Mercurial gave a damn about the developer…

Git won because Linus used it and the Ruby community picked it up. It had serious cachet before GitHub became a thing.

Re: We need a new generation of source control

#19

Post by hliyan »

Are we mistaking a dependency control problem as a revision control problem?

In a previous life, before microservices, CI/CD etc. existed, we did just fine with 20-30 CVS repositories, each representing a separate component (a running process) in a very large distributed system.

The only difference was that we did not have to marshal a large number of 3rd party dependencies that were constantly undergoing version changes. We basically relied on C++, the standard template library and a tightly version controlled set of internal libraries with a single stable version shared across the entire org. The whole system would have been between 750,000 - 1,000,000 lines of code (libraries included).

I'm not saying that that's the right approach. But it's mind boggling for me that we can't solve this problem easily anymore.

Re: We need a new generation of source control

#20

Post by jrockway »

The source control system is not the piece of the equation that matters to most people. The build system is the important part. That's what prevents you from rebuilding the repository when you only change one Kubernetes config file, or what causes 100 docker images to be built because you changed a file in libc.

I think the tooling around this is fairly limited right now. I feel that most people are hoping docker caches stuff intelligently, which it doesn't. People should probably be using Bazel, but language support is hit-or-miss and it's very complicated. (It's aggravated by the fact that every language now considers itself responsible for building its own code. go "just works", which is great, but it's hard to translate that local caching to something that can be spread among multiple build workers. Bazel attempts to make all that work, but it basically has to start from scratch, which is unfortunate. It also means that you can't just start using some crazy new language unless you want to now support it in the build system. We all hate Makefiles, but the whole "foo.c becomes foo.o" model was much more straightforward than what languages do today.)

Post reply on HN