[dead]
The future of version control
131–140 of 407 posts
Re: The future of version control
#132What CRDT's solve is conflicts at the system level. Not at the semantic level. 2 or more engineers setting a var to a different value cannot be handled by a CRDT. Engineer A intended value = 1 Engineer B intended value = 2 CRDT picks 2 The outcome could be semantically wrong. It doesn't reflect the intent. I think the primary issue with git and every other version control is the terrible names for everything. pull, p…
> It would be incredibly useful if before you were about to edit a file, the version control system would warn you that someone else has made changes to it already or are actively working on it. In large teams, this sort of automation would reduce conflicts, as long as humans agree to not touch the same file. This would also reduce the amount of quality regressions that result from bad conflict resolutions.
Bringing me back to my VSS days (and I'd much rather you didn't)
Re: The future of version control
#133What CRDT's solve is conflicts at the system level. Not at the semantic level. 2 or more engineers setting a var to a different value cannot be handled by a CRDT. Engineer A intended value = 1 Engineer B intended value = 2 CRDT picks 2 The outcome could be semantically wrong. It doesn't reflect the intent. I think the primary issue with git and every other version control is the terrible names for everything. pull, p…
well, the mismatch here is widened by the fact that almost everyone it seems uses git with a central, prominent, visible, remote repository. Where as git was developed with the a true distributed vision. Now sure that truely distributed thing only becomes final when it reaches some 'central' repo, but it's quite a big different than we all do.
Re: The future of version control
#134I'm confused about what this solves. They give the example of someone editing a function and someone deleting the same function and claim that the merge never fails and then go on to demonstrate that indeed rightly the merges still fails. There are still merge markers in the sources. What is the improvement exactly?
Re: The future of version control
#135I don't really get the upside of focus on CRDTs. The semantic problem with conflicts exists either way. You get a consistent outcome and a slightly better description of the conflict, but in a way that possibly interleaves changes, which I don't think is an improvement at all. I am completely rebase-pilled. I believe merge commits should be avoided at all costs, every commit should be a fast forward commit, and a uni…
I used to use rebase much more than merge but have grown to be more nuanced over the years: Merge commits from main into a feature branch are totally fine and easier to do than rebasing. After your feature branch is complete you can do one final main-to-feature-branch merge and then merge the feature branch into main with a squash commit. When updating any branch from remote, I always do a pull rebase to avoid merge…
I am now wholly bought into the idea of having a feature branch with (A->B->C) commits is an anti-pattern.
Instead, if the feature doesn't work without the full chain of A+B+C, either the code introduced in A+B is orphaned except by tests and C joins it in; or (and preferably for a feature of any significance), A introduces a feature flag which disables it, and a subsequent commit D removes the feature flag, after it is turned on at a time separate to merge and deploy.
Re: The future of version control
#136Earlier quoted context omitted.
a better (more confusing) example: i have a branch and i want to merge that branch into main. is ours the branch and main theirs? or is ours main, and the branch theirs?
I always checkout the branch I am merging something into. I was vaguely aware I could have main checked out but merge foo into bar but have never once done that.
git checkout mybranch
git rebase main
Re: The future of version control
#137I'm confused about what this solves. They give the example of someone editing a function and someone deleting the same function and claim that the merge never fails and then go on to demonstrate that indeed rightly the merges still fails. There are still merge markers in the sources. What is the improvement exactly?
Yeah, the author fails to present his case even in the intro
> A CRDT merge always succeeds by definition, so there are no conflicts in the traditional sense — the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails. This project works that out.
It has clear contradiction. Crdt always succeed by definition, no conflicts in traditional sense so (rephrasing) conflicting changes are marked as conflicted. Emm, like in any other source control?
In fact, after rereading that intro while writing that answer I start suspect at least smell of an ai writing.
Re: The future of version control
#138Everyone should vibe code a VCS from scratch in their fave language.
It’s an awesome weekend project, you can have fun visualizing commits in different ways (I’m experimenting with shaders), and importantly:
This is the way forward. So much software is a wrapper around S3 etc. now is your chance to make your own toolset.
I imagine this appeals more to DIYer types (I use Pulsar IDE lol)
Re: The future of version control
#139Earlier quoted context omitted.
After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly
iirc ours is always the commit the merge is starting from. the issue is that with a merge your current commit is the merging commit while with a rebase it is reversed. I suspect that this could be because the rebase command is implemented as a serie of merges/cherry-picks from the target branch.
git checkout mybranch
git rebase main
Re: The future of version control
#140This is sort of a revival and elaboration of some of Bram’s ideas from Codeville, an earlier effort that dates back to the early 2000s Cambrian explosion of DVCS. Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper). Codeville predates the introduction of CRDTs by almost a decade, and at least on the face of it the two concepts seem like a nat…
In 2007 Bram said to me that my Causal Tree algorithm is a variant of weave. Which is broadly correct. In these 20 years, the family of weave-class algos grew quite big. In my 2020 article, I devoted the intro to making their family portrait https://arxiv.org/abs/2002.09511 Could have been a separate article.