3 ms·
It's about time someone revisited & reimagined version control. the previous generations each lasted about 15 years: SCCS/RCS -> CVS -> Bitbucket/git/mercurial
by gumby 3y ago
It's about time someone revisited & reimagined version control. the previous generations each lasted about 15 years: SCCS/RCS -> CVS -> Bitbucket/git/mercurial -> ??? so I am glad to see this.
I would start by talking about what is great about Diversion -- what it lets you do that you couldn't before.
Since you mention gaming and perforce I looked in vain to see if it supports binaries (a major limitation of git -- just simply not in its design space). "Binaries" can actually mean for some people compiled code -- not for me but I understand why people do it -- as well as images, data files, Word files etc.
Sounds like the second is scaling but you don't say what you mean by that. Git scales pretty well until either the repo & its history gets enormous or when there are a lot of people making simultaneous changes.
The realtime collab integrated with a version control mentality could be interesting -- a major problem with google docs is the lack of useful version control (even Word is better).
And why cloud native?
Once you've done that you need only briefly mention "why not just use git instead?"
- pas 3y ago??? might be https://pijul.org/ https://pijul.org/ with its commutative awesomeness
- ColonelPhantom 3y agoIt's worth mentioning that Pijul is largely based on the same theoretical model of Darcs, which actually predates Git. But Pijul definitely makes it a lot more workable, e.g. by solving the exponential (iirc) complexity merge that Darcs has.
- pmeunier 3y agoThis is not true, actually. Pijul answers the question "how to model states so that conflicts are allowed (and hence modeled)", whereas in Darcs it is "how do operational transforms on patches alone inform us about conflicts"?
- sasham 3y agoThanks for the feedback! Totally agree. Diversion does support binaries, should have mentioned it directly (will update the website). The thought behind cloud native is that workloads and devtools and data are moving there, and we want Diversion to be the best choice for when everything is in the cloud. Besides that cloud storage and DBs allow us to build and iterate much faster, and worry less about scalability, data distribution & storage etc. But we can also run Diversion locally / in a container, it just won't be as scalable.
- oblio 3y ago> SCCS/RCS -> CVS -> Bitbucket/git/mercurial You skipped Subversion/SourceForge. People forget but for about 5 if not 10 years, SVN was the biggest SCM in town, next to P4, P4 having more of a hold in the game dev world.
- gumby 3y agoI not only did not forget about subversion, I funded it in part. But it was of the CVS generation. I did leave out the proprietary things like Perforce and Aide de Camp, Solidworks PDM and the various in house things. Life's too short!
- oblio 3y agoYou also forgot Microsoft Visual SourceSafe :-p
- VyseofArcadia 3y ago> And why cloud native? And what even is cloud native? When "cloud native" isn't just marketing, it seems to have all sorts of different meanings.
- sasham 3y agoWe're using S3 storage, lambda and ECS compute, and serverless DBs. It allows us to build a scalable product much faster, and leverages cloud features like multizone backups and distribution without having to develop these ourself. It also allows fast transfer of data between Diversion and other cloud systems.
- gumby 3y agoThose are things that matter to you not your users. You did talk a little (in a comment or your post I don't remember) that you can use various cloud APIs to integrate into other systems. But at the moment, from what you're telling me "cloud native" is as interesting to me as how you format your source code.
- withinboredom 3y agoSo basically not self-hostable.
- hasty_pudding 3y agowhy is it about time?? VCS is sort of a solved problem like SQL. it's like saying it's about time someone revisited those Javascript frameworks.
- gumby 3y agoThe comment you're replying to mentions some limitations of the current state of the art. I agree that there's no reason to change just because something is older than some threshold. Bit I think the roughly 15 year cadence has reflected the time it has taken for a new VCS idea to develop and then become mainstream enough for its drawbacks to become annoying enough that it loops again.
- esafak 3y agoI don't know about that. The UX of git leaves a lot to be desired. monorepos and large files are not definitely solved, either. If not git, what solution did you have in mind?
- hasty_pudding 3y agomillions of repos on github don't have those issues. Youre talking an extreme use case. Like saying we need to replace the shovel because it cant do what a bulldozer does. Its miniscule fraction of GitHub repos have those issues like an incredibly small number mainly devoted to games or media. UX is fine if you know it. SQL UX isnt ideal either.