Redesigning Source Control at Anthropic

Re:Redesigning Source Control at Anthropic by altcognito on Tuesday October 13, 2026 @03:49PM (#50077608)

I personally haven't dealt with a big-corp level of mono-repo. The choices you make might be justifiable to bring in certain binaries as opposed to resolve artifacts from some type of library repo. Especially if they are doing web front ends and whatnot?

And actually, the lack of an artifact server and some sort of proper knowledge of compatibility requiring a CI pull across hundreds of different projects with every merge is probably the explanation. Seems like there is an innovation waiting to happen there.

[ Parent | on HN ]

Re:Redesigning Source Control at Anthropic by rhdunn on Tuesday October 13, 2026 @04:15PM (#50077993)

For local projects I'm using a repo per module/package, creating tagged releases, and pushing them to a local package hosting server. I can then reference those artifacts as dependencies in the projects that need/use them. No need for complex CI pulls, just coordinated releases.

I also have a template repository I use to help with common setup for different project types so I don't need to repeat that every time I create a new project.

For Python it's easy to create an artifact server as the artifacts are just wheel files in a directory with the server listing the directories (packages), files (releases), and downloading the files.

I'm not sure about other artifact servers for other projects.

[ Parent | on HN ]