Ask HN: Next-Generation Version Control?
13 comments
Look for forms of development that are poorly served.
For instance, version control of Jupyter notebooks is deeply problematic because the data is coupled to the document. There is no answer to this that makes people 100% happy because maybe the data requires talking w/ compliance for months, then accessing it over a special network, then waiting 12 hours for the export scripts to run. (Or something like that...)
I would also look at how version control meshes with low-code, no-code, visual programming, UML-like systems, rules engines, etc.
For instance, version control of Jupyter notebooks is deeply problematic because the data is coupled to the document. There is no answer to this that makes people 100% happy because maybe the data requires talking w/ compliance for months, then accessing it over a special network, then waiting 12 hours for the export scripts to run. (Or something like that...)
I would also look at how version control meshes with low-code, no-code, visual programming, UML-like systems, rules engines, etc.
I think data management could be improved a lot. A common pattern is to have a data object that's generated from the source and other data objects, but is too expensive for everyone to regenerate whenever they recompile. Machine learning models are a common example, but video game development also has things like 3D models, textures, audio files, etc.
You can make it all work with git, git-lfs, CI servers and lots of typing, but it's tedious and error-prone.
You can make it all work with git, git-lfs, CI servers and lots of typing, but it's tedious and error-prone.
Agreed! Definitely something that could be improved with existing version control. I do like the "git for non-code items", including for these code-related bits.
Git is already incredibly smart about merging things — what kind of improvements do you propose to make in this regard? In certain cases it simply isn't possible to automatically merge things, they require external knowledge.
In general, with the current tools provided by VSTS, Gitlab etc (Github is lagging behind a bit here), I don't think most developers on generic codebases have much trouble with versioning.
In general, with the current tools provided by VSTS, Gitlab etc (Github is lagging behind a bit here), I don't think most developers on generic codebases have much trouble with versioning.
Regarding merging: hard to say. Possibly, if you have the ability to check for conflicts with each file touch across machines, you could in theory resolve/identify conflicts earlier. But that's a guess.
The main premise was to remove the pain of git, and it's possible that, as you say, it's not a big enough pain point!
The main premise was to remove the pain of git, and it's possible that, as you say, it's not a big enough pain point!
To me the biggest problem github and similar platforms have is censorship. I don't want Microsoft or anyone else to have a power to remove any repository. Wouldn't it be great to have a peer-to-peer git server to share and clone git repositories via something like magnet links? UI could be just another tool that you use in addition to git, possibly eventually integrated into it.
git is already a distributed, peer-to-peer system
It's not a peer-to-peer system. You have to both publish repositories somewhere and clone them from there, not from peers.
You can clone from any copy of the repo, regardless of where it is. You can setup, push, and pull from any number of 'remote's. It could be a DNS record, ip address, or local directory.
i.e. GitHub/Lab or some centralized repo is not required.
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
https://en.m.wikipedia.org/wiki/Git
i.e. GitHub/Lab or some centralized repo is not required.
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
https://en.m.wikipedia.org/wiki/Git
It cannot be a magnet link. And I think you are confusing client-server with peer-to-peer communications. What can be done without touching git is some software running locally doing peer-to-peer and speaking git's protocol, git can then use local ip address as a remote.
Git doesn't HAVE to be set up as client-server. It's just that that makes the most sense for an organization most of the time.
I don't know how I'm going to assemble commits, and while a computer can often work out what a user can't, this doesn't feel like one of those areas. After each code block that passes CI testing including documentation? The first step would be a language neutral version of Rail's Rspec + Guard.
I wonder if it would make sense to roll the entire development environment into it: code, data schema, programming editor/config, key os settings... something along the lines of Time Machine but with "markers" which allow you to flag points of progress that can be examined and diffed later.
The concept is: magic git. You just write code, and a background service handles backup/sync (ala Dropbox), assembling commits, and interacting with a git server (either GitHub or other). No more pain from wrestling with git, you can just write your code.
There is obviously a ton of complexity here: merging, code reviews, CI, etc., but the basic idea is to handle as much of the goo around versioning as smartly as possible without taking mental energy from the developer, and expose those advanced/custom controls when needed.
What do you think? Is this the right direction for version control to go? Would you use this service?