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

41–50 of 90 posts

Re: We need a new generation of source control

#41

Post by klodolph »

falsedan wrote: post #39
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…

> it doesn't have access controls (and there's only so much you can add) so there's a lot of drawbacks to using gitolite but we were able to customise access controls down to allowing some users the ability to only change lines of checked-in config only to certain values

How do you prevent users from reading certain parts of the repository, though? This was what I meant by "there's only so much you can add"... you can reject pushes that change parts of the repo, but you can't prevent reads without breaking everything.

Re: We need a new generation of source control

#42

Post by Tempest1981 »

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?

With git, can you set specific user permissions by directory? We need a way to prevent pull or commit by certain users.

Or require a review before committing to some projects/dirs, but not all.

Re: We need a new generation of source control

#43

Post by TheGRS »

hliyan wrote: post #19

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 cha…

I dunno, the only 3rd party over-dependencies I see is in frontend code and that code is usually in one big repo (in my personal experience). I think the proliferation of NPM dependencies is its own problem, but usually when I'm thinking of mono-repo vs multi-repo its because teams/repos are having trouble coordinating between each other, not because some NPM library hasn't been updated lately.

Re: We need a new generation of source control

#44

Post by dclowd9901 »

I don't really understand the problem with multi-repos. Maybe because I'm a FE developer, I'm shielded from some of the pain of launching an external service locally, but I find the process of needing to update an external module to be rather similar to open source dev: clone, link, fix, PR, approve, merge, update package.json. It's that simple. The only part that can present itself as somewhat tricky is how your environment handles linked dependencies, but that can be resolved if you've configured your webpack or whatever correctly.

Re: We need a new generation of source control

#45

Post by klodolph »

falsedan wrote: post #35
emcq wrote: post #17

Earlier quoted context omitted.

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

git archive is ... ok, not pretty great, but it works

That's not really a working copy, though. What some need is a tool that lets you check out a part of the repository as a working copy, without checking out the rest. By "part" we might mean more than one directory and its descendants (i.e. not a single root).

Re: We need a new generation of source control

#46

Post by Tempest1981 »

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?

With a monorepo, how do you avoid the situation where almost every time you want to commit, you have to pull-and-rebase first? Because somebody has always pushed a change, every minute or two.

Re: We need a new generation of source control

#47

Post by klodolph »

kadendogthing wrote: post #34
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…

You have completely missed the point of my post. The point was my post had as much substantial points as the article in question, with less words obviously. Which should be obvious but never get in the way of a good tech contrarian article stating everything sucks I suppose.

Ah, thank you for the clarification, I had interpreted your comment far too generously.

Re: We need a new generation of source control

#48

Post by khazhou »

netheril96 wrote: post #33

Google uses a monorepo for most of its code and I find it a much better experience than what I’ve had in the past. But that good experience is predicated on a lot of Google only internal tools. If Google open sources enough of those such that people outside can have the same experience, maybe the debate will end decisively in favor of monorepo.

What kinds of tools?

Re: We need a new generation of source control

#49

Post by joshuamorton »

bluGill wrote: post #36
organsnyder wrote: post #29

Earlier quoted context omitted.

My preferred approach for a microservice architecture: - Contract-first API development - All API contract definition files (OpenAPI/Swagger, .proto, .wsdl...) in a single repo, which has a CICD pipeline to bundle them into artifacts for various platforms (Maven, Nuget, NPM, gem...) - Consumers and producers import the "api-contracts" dependency; this is the only coupling between components - Consumers and producers…

I agree with your last point in theory, but in practice consumers start to rely on bugs and implementation details, and eventually it is easier to change the contract that fix the clients.

Hyrum's law and all.

But I don't think that's what he was saying so much as your clients shouldn't depend on the server code, only the api definition. Which is true and possible in general.

Re: We need a new generation of source control

#50

Post by falsedan »

headcanon wrote: post #21
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…

One thing about GitLab tooling is that they have features that apply only on a per-repo basis, for example GitLab CI. Suppose for example we have 2 distinct projects - a backend and frontend, which each have their own testing and deployment strategy. GitLab CI only allows one CI pipeline config per-repository. While we could take care of that with scripting, that can easily get out of hand as we increas the number of…

> single commit hash

sounds like you have a deploy & release issue, not a developing or publishing one. Octopus Deploy was the first system I saw that make a distinction between them, and it eliminated a swathe of issues by simply saying "a release is a set of versioned packages"

wow octopus deploy got expensive

Post reply on HN