Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of version control

bramcohen.com

Post reply on HN
Print view View original

381–390 of 407 posts

Re: The future of version control

#381

Post by gavinhoward »

PunchyHamster wrote: post #311

At this point if your VCS isn't a layer above git plumbing, nobody gonna waste time using it. Especially if the improvements are minor enough that it could be reasonably just a wrapper and still have 90% of the improvements. > Two opaque blobs. You have to mentally reconstruct what actually happened. Did you not discover what git diff does ? It's clearer than the presented improvement ! Plenty of 3 way merge tools su…

> At this point if your VCS isn't a layer above git plumbing, nobody gonna waste time using it.

Probably true, but it's a shame because there are better ways of storing and processing the data, ways that natively handle binary files, semantics, and large files without falling over.

Re: The future of version control

#382

Post by gnufx »

zamalek wrote: post #258
ZoomZoomZoom wrote: post #4

The key insight in the third sentence? > ... CRDTs for version control, which is long overdue but hasn’t happened yet Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it. Not that Bram is not one of those, but the post reads like you all know what.

Pijul isn't a CRDT is it? It's theory of patches (i.e. DARCS++) alongside native conflicts.

Its author says it implements a CRDT in its theory documentation.

Re: The future of version control

#383

Post by gnufx »

WolfeReader wrote: post #353
m12k wrote: post #347

I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual chang…

Darcs did this decades ago with the "replace" command. It's not a legitimate semantic replacement, though - it's more just telling your VCS to do a find/replace.

As far as I remember, that's just because only the find/replace was implemented, and it could have more sophisticated (semantic?) features.

Re: The future of version control

#385

Post by simonmic »

aduwah wrote: post #104
alunchbox wrote: post #36

Jujutsu honestly is the future IMO, it already does what you have outlined but solved in a different way with merges, it'll let you merge but outline you have conflicts that need to be resolved for instance. It's been amazing watching it grow over the last few years.

The only reason I have not defaulted to jj already is the inability to be messy with it. Easy to make mistakes without "git add"

You can turn off the auto-tracking, and add your files manually.

Re: The future of version control

#386

Post by nkmnz »

AceJohnny2 wrote: post #94
nkmnz wrote: post #86

I don't quite understand how CRDTs should help with merges. The difficult thing about merges is not that two changes touch the same part of the code; the difficult thing is that two changes can touch different parts of the code and still break each other - right?

Eh. It's a matter of visible pain vs invisible pain. Developers are quite familiar with Merge Conflicts and the confusing UI that git (and SVN before it, in my experience) gives you about them. The "ours vs theirs" nomenclature which doesn't help, etc. This is something that VCSs can improve on, QED this post. Vs the scenario you're describing (what I call Logical Conflicts), where two changes touching different part…

Thank you for the clarification. I agree that the current state of the art to show conflicts _in the same part of the code_ is not sufficient, so any improvement with regard to that is welcome. Still, I'm more looking for solutions with the Logical Conflicts.

Re: The future of version control

#387

Post by meindnoch »

tasuki wrote: post #93
gnarlouse wrote: post #14

I think something like this needs to be born out of analysis of gradations of scales of teams using version control systems. - What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts? - What do teams of 1, 10, 100, 1k, etc care the most about? - How does the modern "agent explosion" potentially affect this? For example, my experience working in the 1-100…

> What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts? > What do teams of 1, 10, 100, 1k, etc care the most about? Oh god no! That would be about the worst way to do it. Just make it conceptually sound.

Also, we need personas! Sally the developer, Mark the UX designer, Taylor the manager. Also, we need to build a community, with the help of evangelists!

Re: The future of version control

#388

Post by jayd16 »

samuelstros wrote: post #361
jayd16 wrote: post #355

Earlier quoted context omitted.

What's the plan for large files that can't be merged? Images, executable binaries, encrypted files, that sort of thing?

Simple left or right merge. One overwrites the other one. The appeal or structured file formats like .docx, .json, etc. Images are unstructured and simple "do you want to keep the left or right image" is good enough.

That doesn't really address the game dev use case then. Artists and designers want to prevent conflicts, not just throw away half the work and redo it.

Re: The future of version control

#389

Post by mdnahas »

This is a bad idea. I spent a lot of time thinking about git’s snapshot system vs. merge-based system that were promoted by functional programming fans. Auto merging systems are bad for a good reason: because we care about features, which are a property of snapshots not diffs.

If you have a diff that adds a button and a diff that turns existing button blue, the merge of those diffs doesn’t add a button and have all button blue. Because it may not make the new button blue.

Features like “all buttons are blue” are properties of snapshots. Snapshot based revision control, like git, it better for that reason.

Re: The future of version control

#390

Post by samuelstros »

jayd16 wrote: post #388
samuelstros wrote: post #361

Earlier quoted context omitted.

Simple left or right merge. One overwrites the other one. The appeal or structured file formats like .docx, .json, etc. Images are unstructured and simple "do you want to keep the left or right image" is good enough.

That doesn't really address the game dev use case then. Artists and designers want to prevent conflicts, not just throw away half the work and redo it.

track the source of the asset and it works. take ui design. dont track the svg. track the design file itself
Post reply on HN