8 ms·

Today’s Version Control Tools Are Still Primitive

28 points by kartickv 9y ago

sytse 9y ago
This article really resonated with me. Especially the integration is something we can uniquely do. At GitLab we'll build the GitLab IDE in 2018. It will be a single user thing at first but the article has a couple of great ideas for to do it with multiple users.
- procrastitron 9y ago
  This resonated with me except the part about integration. The article seems to assume tight coupling between tools as a prerequisite for seamless integration between them. I am the maintainer of git-appraise, and its founding precept is that tools can be loosely coupled and still seamlessly integrate together. All they have to do is store their data in the git repository in a common format. The result works well. For example, a commit can be built by both Travis and Jenkins, and other tools can show both results without caring which tools produced them. The rest of the suggestions seemed reasonable, though.
  - kartickv 9y ago
    Author here. If you can build a seamlessly integrated user experience from separate tools, that's fine with me.
- elygre 9y ago
  Ah, please don’t. I love GitLab, made it a corporate standard accessible to every single employee. But the current problem space is already huge, and you are struggling to solve all of it properly. Branching off into an entirely new dimension, like an IDE will be, will make it even harder for you to satisfy existing customers.
  - sytse 9y ago
    Thanks for using GitLab. Overextending ourselves is a concern we share. Where in the problem space so you think we struggle most?
  - kartickv 9y ago
    That's the problem with enhancing existing tools — you have to choose between satisfying existing customers in the short term. The best vehicle for my ideas may be a new tool built from scratch. Sure, reuse code fragments or libraries, but don't feel constrained by backward compatibility.
languagehacker 9y ago
If you've used Git for only a year, and you've got a mere "hundreds of commits" under your belt with distributed version control systems, then the pain you're feeling may not necessarily be coming from the tool. Many of your unmet needs basically boil down to a desire for automatic replication of the state of a codebase to a remote endpoint. Right now, it's an explicit choice made by the developer. There are a lot of good reasons for this. If you don't feel like any of them apply to you, it should take you maybe half a day to write a script that creates a throwaway commit and is pushed to an arbitrary remote. Or you can just put your project in Dropbox and call it a day. Also, if you're looking to work on a Git project using a Chromebook, maybe just use the inline edit mode in GitHub. In all, I don't think the features you're looking for necessarily belong in a distributed version control system or its related protocols. As I've outlined above, you can get what you want by extending such a system, or using existing extensions on top of those systems.
- DesiLurker 9y ago
  ya many of those things are quite simple & can be easily achieved by having multiple remotes with one sitting in a common NFS mounted drive (I've even done sshfs & it all works fine). far as backup is concerned it just a tarball to nfs. alternatively one might look at something like gitfs. My problem with such 'overly integrated solutions' is that they work until they dont. if git were to do it the okay but what if you are dealing with multiple git repos? what if some of them are gitfusion repos from perforce backend? IMHO simple & deterministic (as in deterministic to human mind) is better.
  - deleted 9y ago
    [deleted]
- kartickv 9y ago
  Author here. You're right that I'm a Git beginner. I don't want to hack up my own distributed version control system that fails in interesting ways :) And yes, I do put my Git workspaces in Google Drive, but that doesn't address many of the limitations in the post. Github's inline edit mode is exactly the kind of affordances we need. When I needed to make a simple change to my open-source project (adding comments to document assumptions), I didn't want to mess with downloading, resolving conflicts, merging and pushing. Regarding your point that this doesn't belong in a version control system (a point that other people made on this HN post) but in extensions, I want an integrated environment. I don't want to investigate extensions and hooks and scripts to make things work together. I want it to be seamless. Just like IDEs are different from text editors (and upset some old-school programmers that "XYZ shouldn't be in a text editor"), I'm advocating a new style of version control system that does more.
qznc 9y ago
I like that this is not just a rant about git. Instead there are quite specific demands which are really not available anywhere. I think this goes beyond version control though. To move computation seamlessly integration with lots of parts is necessary. I think something tightly integrated like Smalltalk would be the best path to build a prototype.
jabot 9y ago
This article has a few points. First of all, the author wants backup, switching machines, and collaboration all integrated into VC. This is a worthwile goal, and i can see that shoehorning git et al into those rules can feel... clunky. I think there is room for improvement there. The author comes off a little greedy, when he wants to (a) be able to instantaneously create a new workspace while (b) being able to manage huge code bases. Oh, and everything should work even on his chromebook - as long as he has one computer that can do the work, all his other computers should offload the work to the one capable of doing it. Transparently of course. This sounds great and all... but i would not want to implement it :-)
- bitwize 9y ago
  I, too, want a pony.
  - kartickv 9y ago
    Preemptively reducing your expectations is a great way to ensure that we won't take big leaps forward. You can choose to be sarcastic, while I'll keep my positive, hopeful attitude.
- kartickv 9y ago
  Author here, and I wouldn't want to implement it either, unless I have a big enough team and funding :)
- Terretta 9y ago
  https://codenvy.com https://codenvy.com https://eclipse.org/che/ https://eclipse.org/che/ https://c9.io https://c9.io Etc.
amelius 9y ago
This article could just as well be titled "Today's OSes are still primitive".
lozenge 9y ago
Is the author using Google Drive sharing as a substitute for a Git server like Github? > That frees him to modify the code as he sees fit without worrying about whether he’s accidentally throwing away my work, making me unhappy. Git already keeps history! > I should be able to instantly create another workspace. Currently, syncing everything down from the server takes 10 or 20 seconds It'll only take a moment with `git clone --shallow` and you can then run `git fetch` in the background. > The last time I switched branches in Git for this, I accidentally had an unsaved change in my text editor. When I later pressed Cmd-S, it got saved to the wrong branch. Use a text editor that knows Git. This is unsolvable with a text editor that isn't integrated with your version control. > If you want to keep two versions of code, the filesystem already offers a solution. It’s called folders. That makes it easier to switch between them, as easy as minimising a window. It’s hack to have only one folder and copying files back and forth to simulate having multiple folders. git supports having multiple folders with different versions of your code checked out: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree The entire CPython repository is 300MB (less over the wire thanks to compression) and once it's downloaded, Git can answer just about any query you can think of in under 100ms, or as the author says, "instant". I'll take that over some complicated smart-sync cloud solution any day.
- kartickv 9y ago
  Author here. I have all my Git workspaces in Google Drive, but that's a hack, because I'm using two cloud systems (BitBucket and Drive) together. It would be like editing some Word documents by keeping the intermediate versions in Dropbox but the result in Google Drive. > Git already keeps history! Not for uncommitted changes. Like edits in Google Docs. Being able to go back lets me freely modify the code to try out something else knowing I can easily go back. Without making intermediate commits, branches, a second workspace, or other overhead. > This is unsolvable with a text editor that isn't integrated with your version control. Actually it's solvable, by having different workspaces instead of branches when I want to try out two different approaches to see which one works better. Thanks for suggesting worktrees, but given Git's complexity and poor UX, I try not to get too fancy :) But you're right that does work instantly. I'd like instant performance + easy UX.
Myrmornis 9y ago
Several of the authors complaints stem from him not using temporary branches liberally. I think he’s suffering from the common beginners’ problem of thinking that committing has to be final. The word “commit” doesn’t help; “snapshot” might be a better metaphor. But even if you understand that a commit is cheap, and disposable, it takes quite a bit of experience to get comfortable using the graph comprising different branches, and to be confident with remote and local branches. This learning curve could be said to be a problem, but personally I don’t really want software engineers as colleagues if they can’t learn git.
- kartickv 9y ago
  Author here. You're right -- I haven't created even one branch so far, let alone liberally. But snapshotting should be automatic, like in Google Docs. It's not that someone "can't learn git". Learning is a process, and takes time. But I have no sympathy for tools with an unnecessarily steep learning curve and poor UX like Git. I should have to pay that price only when I want to do something very sophisticated that only Git can do. Not for basic tasks. Simple things should be simple and hard things possible. Snapshotting should be automatic.
  - Myrmornis 9y ago
    OK, I hope the tone of my original post wasn't unpleasant (on re-reading, not sure I'm a huge fan of it). It might be interesting to have a version control system which does continuous recording. If git is the last word in VCS then I guess humans didn't live for much longer! But personally I am completely happy with the current style in which the user explicitly creates snapshots and these form a distributed graph, and the user is given tools to work with the graph.
    - kartickv 9y ago
      Thanks for clarifying tone.
xq3000 9y ago
You are talking about much more than just version control here. And, yes, a web based IDE with web based workspaces is probably the way to go. I think Eclipse Che is doing exactly that today and is production ready.
mankash666 9y ago
Concur with #7 & #8. IDE support & support for large repos seem basic. Other features are not strictly within the scope of VCS, but things that we've come to expect in 2017. I'm for keeping them separate
luckydude 9y ago
Sadly, Git won. BitKeeper solves a bunch of this stuff, not all, but a bunch but nobody cares. The reality is GitHub won. To 99.99% of the world version control is GitHub. Step outside of what GitHub can do and you get blank stares. If you want to play with BK, it's at bitkeeper.org, all open source, apache v2 license (because that seemed to be the license that most people liked, contact me if that doesn't work for you).
- kartickv 9y ago
  Interesting, and sad that Git won. I used Mercurial earlier, given that it seemed to have a better user experience, but Xcode's integration with Git made me switch. Thanks for your offer.
- deleted 9y ago
  [deleted]
hasenj 9y ago
It seems like most of his demands can be solved with Dropbox or a similar cloud sync software. Git will likely never implement his ideas because git is designed for decentralized workflows where you can have hundreds of people working on different things in the same large repo. Why should Linus have on his disc a copy of every single WIP branch of the many people currently hacking on the Kernel? This will never happen. It's completely outside the scope of git.
- kartickv 9y ago
  Linus needn't have on his disc every random person's WIP. The software can be smart enough to only sync code he's tried to read, edit or compile. Or Linux can choose. An analogy is Google Drive letting you choose which folders to sync down to your device. The point is that there are many better solutions to the problem than people never want to see each other's work, which is the status quo, and requiring them to jump through hoops if they want to. Git will never implement my ideas, and I wasn't asking for it to. I was calling for a new kind of integrated version control system. It's like an IDE vs a text editor, and many old-school programmers saying, "No, that shouldn't be part of an editor".
AkshatM 9y ago
Nearly all of these features are appropriate to a cloud-based IDE with sync capabilities, not a distributed version control system. The author even acknowledges he's thinking of such an IDE by referencing Cider. A DVCS does one thing and one thing well: it enables copying one history of a codebase to different clients. Broadcasting updates to a client's particular history to all other clients in real time is not its job - yet all the listed 'desirable' features (with the exception of those citing performance) seem to do just that.
gbtw 9y ago
This seems all nice to have but what I really miss is the software engineering side integration into the whole development side. You should have the software engineering people who make J-STD-016 or similar traced requirement, design, test and deployment documentation all the way into the code. Heck sometimes generating code & tests from documentation is really valuable in a large system. Now we get around this by making Jira tickets and hanging jira tickets in change requests and change requests have documentation changes but really i would like to pull up any piece of code and read all the requirements and the design decisions that are made on it. Is something we miss (30 man year sized project, with 3 full time engineers, both software engineering and coding) and is more of an imitate problem once the software becomes to complex to hold into an engineers head (i try ;)).
Snappy 9y ago
A web IDE is a great start, and as Sid already pointed out, at GitLab we'll ship an IDE deeply integrated with version control (and CI, CD, monitoring, etc.) in 2018. But that only covers part of the problem. A lot of the post revolves around newer concepts of realtime as exemplified by Google Docs. Specifically I mean: * Realtime * Collaborative * Versionless An IDE is obviously realtime, but our focus is on single-user realtime, at least initially. CodeEnvy, Koding, and others have created shared editing environments, so maybe that's a pattern that works. But that still doesn't sound like what the author is really looking for. These are editing environments built on top of git so require the same branch and commit model. e.g. if you forget to commit your changes, anyone looking at the code outside of your (shared, collaborative, online) environment won't see it. I've been wondering for a while what the next iteration of VCS (or DVCS) is going to be, and I have a hunch it will involve realtime. What would it look like if the underlying VCS was realtime itself? If it worked like Google Docs? I imagine it kind of like Google Docs's "suggesting" mode, where edits are shown on the mainline, but as suggestions which can be accepted or rejected. That's kind of like merging a merge request or pull request. But it doesn't seem to scale well. Imagine a doc with hundreds of simultaneous suggestions on the same code, especially stale suggestions that you aren't going to merge, but aren't ready to delete either. Would you switch between groups of suggestions/suggesters (like you would switch branches)? Would you just not work with long branches? I mean, that's an anti-pattern anyway. And don't even think about branches of branches or applying a patch to the last N stable branches. But if you're doing continuous deployment to a web product, those patterns don't apply anyway. Would being forced to see all the suggestions trigger latent OCD and cause people to clean them up constantly? Or would it turn out not that bad because you're only seeing simultaneous changes on a single page at a time? That brings up another challenge, changes that spread across many different files, but need to be considered together to make sense. Google Docs rarely have that problem. Maybe that means that it's inherently incompatible. Maybe it just needs a new solution we haven't seen yet. One idea comes to mind: the way recent editors show a mini-map of a file, and when you search, all search hits are highlighted on the mini-map. Extend that in some way so that when I'm looking at one suggestion, related suggestions are highlighted for me. I don't know, might be a dumb idea, but the point is that some thinking out of the box might solve this. Google Docs (and realtime collaborative editing in general) were such a game changer that people flocked to it even though it was seriously under-featured compared to Word. Sure, tons of enterprises are still on Word, and there's a bit of a gap between companies that have embraced Docs or not. But for those that did, it's changed how we work. Keeping everyone in sync is far more important than having 10,000 options for making words follow a curve in 3D. I wonder if some realtime version control, applied to code, will open up new ways of working we can't even conceive of today, and we'll slowly forget that we once loved the branch and commit model.

28 points by kartickv 9y ago

This article really resonated with me. Especially the integration is something we can uniquely do. At GitLab we'll build the GitLab IDE in 2018. It will be a single user thing at first but the article has a couple of great ideas for to do it with multiple users.

procrastitron 9y ago
This resonated with me except the part about integration. The article seems to assume tight coupling between tools as a prerequisite for seamless integration between them. I am the maintainer of git-appraise, and its founding precept is that tools can be loosely coupled and still seamlessly integrate together. All they have to do is store their data in the git repository in a common format. The result works well. For example, a commit can be built by both Travis and Jenkins, and other tools can show both results without caring which tools produced them. The rest of the suggestions seemed reasonable, though.
- kartickv 9y ago
  Author here. If you can build a seamlessly integrated user experience from separate tools, that's fine with me.
elygre 9y ago
Ah, please don’t. I love GitLab, made it a corporate standard accessible to every single employee. But the current problem space is already huge, and you are struggling to solve all of it properly. Branching off into an entirely new dimension, like an IDE will be, will make it even harder for you to satisfy existing customers.
- sytse 9y ago
  Thanks for using GitLab. Overextending ourselves is a concern we share. Where in the problem space so you think we struggle most?
- kartickv 9y ago
  That's the problem with enhancing existing tools — you have to choose between satisfying existing customers in the short term. The best vehicle for my ideas may be a new tool built from scratch. Sure, reuse code fragments or libraries, but don't feel constrained by backward compatibility.

languagehacker 9y ago

If you've used Git for only a year, and you've got a mere "hundreds of commits" under your belt with distributed version control systems, then the pain you're feeling may not necessarily be coming from the tool. Many of your unmet needs basically boil down to a desire for automatic replication of the state of a codebase to a remote endpoint. Right now, it's an explicit choice made by the developer. There are a lot of good reasons for this. If you don't feel like any of them apply to you, it should take you maybe half a day to write a script that creates a throwaway commit and is pushed to an arbitrary remote. Or you can just put your project in Dropbox and call it a day. Also, if you're looking to work on a Git project using a Chromebook, maybe just use the inline edit mode in GitHub. In all, I don't think the features you're looking for necessarily belong in a distributed version control system or its related protocols. As I've outlined above, you can get what you want by extending such a system, or using existing extensions on top of those systems.

DesiLurker 9y ago
ya many of those things are quite simple & can be easily achieved by having multiple remotes with one sitting in a common NFS mounted drive (I've even done sshfs & it all works fine). far as backup is concerned it just a tarball to nfs. alternatively one might look at something like gitfs. My problem with such 'overly integrated solutions' is that they work until they dont. if git were to do it the okay but what if you are dealing with multiple git repos? what if some of them are gitfusion repos from perforce backend? IMHO simple & deterministic (as in deterministic to human mind) is better.
- deleted 9y ago
  [deleted]
kartickv 9y ago
Author here. You're right that I'm a Git beginner. I don't want to hack up my own distributed version control system that fails in interesting ways :) And yes, I do put my Git workspaces in Google Drive, but that doesn't address many of the limitations in the post. Github's inline edit mode is exactly the kind of affordances we need. When I needed to make a simple change to my open-source project (adding comments to document assumptions), I didn't want to mess with downloading, resolving conflicts, merging and pushing. Regarding your point that this doesn't belong in a version control system (a point that other people made on this HN post) but in extensions, I want an integrated environment. I don't want to investigate extensions and hooks and scripts to make things work together. I want it to be seamless. Just like IDEs are different from text editors (and upset some old-school programmers that "XYZ shouldn't be in a text editor"), I'm advocating a new style of version control system that does more.

qznc 9y ago

I like that this is not just a rant about git. Instead there are quite specific demands which are really not available anywhere. I think this goes beyond version control though. To move computation seamlessly integration with lots of parts is necessary. I think something tightly integrated like Smalltalk would be the best path to build a prototype.

jabot 9y ago

This article has a few points. First of all, the author wants backup, switching machines, and collaboration all integrated into VC. This is a worthwile goal, and i can see that shoehorning git et al into those rules can feel... clunky. I think there is room for improvement there. The author comes off a little greedy, when he wants to (a) be able to instantaneously create a new workspace while (b) being able to manage huge code bases. Oh, and everything should work even on his chromebook - as long as he has one computer that can do the work, all his other computers should offload the work to the one capable of doing it. Transparently of course. This sounds great and all... but i would not want to implement it :-)

bitwize 9y ago
I, too, want a pony.
- kartickv 9y ago
  Preemptively reducing your expectations is a great way to ensure that we won't take big leaps forward. You can choose to be sarcastic, while I'll keep my positive, hopeful attitude.
kartickv 9y ago
Author here, and I wouldn't want to implement it either, unless I have a big enough team and funding :)
Terretta 9y ago
https://codenvy.com https://codenvy.com https://eclipse.org/che/ https://eclipse.org/che/ https://c9.io https://c9.io Etc.

amelius 9y ago

This article could just as well be titled "Today's OSes are still primitive".

lozenge 9y ago

Is the author using Google Drive sharing as a substitute for a Git server like Github? > That frees him to modify the code as he sees fit without worrying about whether he’s accidentally throwing away my work, making me unhappy. Git already keeps history! > I should be able to instantly create another workspace. Currently, syncing everything down from the server takes 10 or 20 seconds It'll only take a moment with `git clone --shallow` and you can then run `git fetch` in the background. > The last time I switched branches in Git for this, I accidentally had an unsaved change in my text editor. When I later pressed Cmd-S, it got saved to the wrong branch. Use a text editor that knows Git. This is unsolvable with a text editor that isn't integrated with your version control. > If you want to keep two versions of code, the filesystem already offers a solution. It’s called folders. That makes it easier to switch between them, as easy as minimising a window. It’s hack to have only one folder and copying files back and forth to simulate having multiple folders. git supports having multiple folders with different versions of your code checked out: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree The entire CPython repository is 300MB (less over the wire thanks to compression) and once it's downloaded, Git can answer just about any query you can think of in under 100ms, or as the author says, "instant". I'll take that over some complicated smart-sync cloud solution any day.

kartickv 9y ago
Author here. I have all my Git workspaces in Google Drive, but that's a hack, because I'm using two cloud systems (BitBucket and Drive) together. It would be like editing some Word documents by keeping the intermediate versions in Dropbox but the result in Google Drive. > Git already keeps history! Not for uncommitted changes. Like edits in Google Docs. Being able to go back lets me freely modify the code to try out something else knowing I can easily go back. Without making intermediate commits, branches, a second workspace, or other overhead. > This is unsolvable with a text editor that isn't integrated with your version control. Actually it's solvable, by having different workspaces instead of branches when I want to try out two different approaches to see which one works better. Thanks for suggesting worktrees, but given Git's complexity and poor UX, I try not to get too fancy :) But you're right that does work instantly. I'd like instant performance + easy UX.

Myrmornis 9y ago

Several of the authors complaints stem from him not using temporary branches liberally. I think he’s suffering from the common beginners’ problem of thinking that committing has to be final. The word “commit” doesn’t help; “snapshot” might be a better metaphor. But even if you understand that a commit is cheap, and disposable, it takes quite a bit of experience to get comfortable using the graph comprising different branches, and to be confident with remote and local branches. This learning curve could be said to be a problem, but personally I don’t really want software engineers as colleagues if they can’t learn git.

kartickv 9y ago
Author here. You're right -- I haven't created even one branch so far, let alone liberally. But snapshotting should be automatic, like in Google Docs. It's not that someone "can't learn git". Learning is a process, and takes time. But I have no sympathy for tools with an unnecessarily steep learning curve and poor UX like Git. I should have to pay that price only when I want to do something very sophisticated that only Git can do. Not for basic tasks. Simple things should be simple and hard things possible. Snapshotting should be automatic.
- Myrmornis 9y ago
  OK, I hope the tone of my original post wasn't unpleasant (on re-reading, not sure I'm a huge fan of it). It might be interesting to have a version control system which does continuous recording. If git is the last word in VCS then I guess humans didn't live for much longer! But personally I am completely happy with the current style in which the user explicitly creates snapshots and these form a distributed graph, and the user is given tools to work with the graph.
  - kartickv 9y ago
    Thanks for clarifying tone.

xq3000 9y ago

You are talking about much more than just version control here. And, yes, a web based IDE with web based workspaces is probably the way to go. I think Eclipse Che is doing exactly that today and is production ready.

mankash666 9y ago

Concur with #7 & #8. IDE support & support for large repos seem basic. Other features are not strictly within the scope of VCS, but things that we've come to expect in 2017. I'm for keeping them separate

luckydude 9y ago

Sadly, Git won. BitKeeper solves a bunch of this stuff, not all, but a bunch but nobody cares. The reality is GitHub won. To 99.99% of the world version control is GitHub. Step outside of what GitHub can do and you get blank stares. If you want to play with BK, it's at bitkeeper.org, all open source, apache v2 license (because that seemed to be the license that most people liked, contact me if that doesn't work for you).

kartickv 9y ago
Interesting, and sad that Git won. I used Mercurial earlier, given that it seemed to have a better user experience, but Xcode's integration with Git made me switch. Thanks for your offer.
deleted 9y ago
[deleted]

hasenj 9y ago

It seems like most of his demands can be solved with Dropbox or a similar cloud sync software. Git will likely never implement his ideas because git is designed for decentralized workflows where you can have hundreds of people working on different things in the same large repo. Why should Linus have on his disc a copy of every single WIP branch of the many people currently hacking on the Kernel? This will never happen. It's completely outside the scope of git.

kartickv 9y ago
Linus needn't have on his disc every random person's WIP. The software can be smart enough to only sync code he's tried to read, edit or compile. Or Linux can choose. An analogy is Google Drive letting you choose which folders to sync down to your device. The point is that there are many better solutions to the problem than people never want to see each other's work, which is the status quo, and requiring them to jump through hoops if they want to. Git will never implement my ideas, and I wasn't asking for it to. I was calling for a new kind of integrated version control system. It's like an IDE vs a text editor, and many old-school programmers saying, "No, that shouldn't be part of an editor".

AkshatM 9y ago

Nearly all of these features are appropriate to a cloud-based IDE with sync capabilities, not a distributed version control system. The author even acknowledges he's thinking of such an IDE by referencing Cider. A DVCS does one thing and one thing well: it enables copying one history of a codebase to different clients. Broadcasting updates to a client's particular history to all other clients in real time is not its job - yet all the listed 'desirable' features (with the exception of those citing performance) seem to do just that.

gbtw 9y ago

This seems all nice to have but what I really miss is the software engineering side integration into the whole development side. You should have the software engineering people who make J-STD-016 or similar traced requirement, design, test and deployment documentation all the way into the code. Heck sometimes generating code & tests from documentation is really valuable in a large system. Now we get around this by making Jira tickets and hanging jira tickets in change requests and change requests have documentation changes but really i would like to pull up any piece of code and read all the requirements and the design decisions that are made on it. Is something we miss (30 man year sized project, with 3 full time engineers, both software engineering and coding) and is more of an imitate problem once the software becomes to complex to hold into an engineers head (i try ;)).

Snappy 9y ago

A web IDE is a great start, and as Sid already pointed out, at GitLab we'll ship an IDE deeply integrated with version control (and CI, CD, monitoring, etc.) in 2018. But that only covers part of the problem. A lot of the post revolves around newer concepts of realtime as exemplified by Google Docs. Specifically I mean: * Realtime * Collaborative * Versionless An IDE is obviously realtime, but our focus is on single-user realtime, at least initially. CodeEnvy, Koding, and others have created shared editing environments, so maybe that's a pattern that works. But that still doesn't sound like what the author is really looking for. These are editing environments built on top of git so require the same branch and commit model. e.g. if you forget to commit your changes, anyone looking at the code outside of your (shared, collaborative, online) environment won't see it. I've been wondering for a while what the next iteration of VCS (or DVCS) is going to be, and I have a hunch it will involve realtime. What would it look like if the underlying VCS was realtime itself? If it worked like Google Docs? I imagine it kind of like Google Docs's "suggesting" mode, where edits are shown on the mainline, but as suggestions which can be accepted or rejected. That's kind of like merging a merge request or pull request. But it doesn't seem to scale well. Imagine a doc with hundreds of simultaneous suggestions on the same code, especially stale suggestions that you aren't going to merge, but aren't ready to delete either. Would you switch between groups of suggestions/suggesters (like you would switch branches)? Would you just not work with long branches? I mean, that's an anti-pattern anyway. And don't even think about branches of branches or applying a patch to the last N stable branches. But if you're doing continuous deployment to a web product, those patterns don't apply anyway. Would being forced to see all the suggestions trigger latent OCD and cause people to clean them up constantly? Or would it turn out not that bad because you're only seeing simultaneous changes on a single page at a time? That brings up another challenge, changes that spread across many different files, but need to be considered together to make sense. Google Docs rarely have that problem. Maybe that means that it's inherently incompatible. Maybe it just needs a new solution we haven't seen yet. One idea comes to mind: the way recent editors show a mini-map of a file, and when you search, all search hits are highlighted on the mini-map. Extend that in some way so that when I'm looking at one suggestion, related suggestions are highlighted for me. I don't know, might be a dumb idea, but the point is that some thinking out of the box might solve this. Google Docs (and realtime collaborative editing in general) were such a game changer that people flocked to it even though it was seriously under-featured compared to Word. Sure, tons of enterprises are still on Word, and there's a bit of a gap between companies that have embraced Docs or not. But for those that did, it's changed how we work. Keeping everyone in sync is far more important than having 10,000 options for making words follow a curve in 3D. I wonder if some realtime version control, applied to code, will open up new ways of working we can't even conceive of today, and we'll slowly forget that we once loved the branch and commit model.