Hacker News new | ask | show | jobs
by edent 336 days ago
I'm playing about with collaborative code editors at the moment. See https://mastodon.social/@Edent/114862593530392361

I want an experience more like Google Docs and less like emailing diffs to a mailing list.

4 comments

Having a private local copy of the codebase is a feature. It means I can make whatever changes I want to the code without anybody else even knowing. And once I've finished mucking about with it and learning what I need to do, I can tidy it up into something I'm ready for other people to look at.

Not having a private playground is one of the big drawbacks of all the modern cloud SaaS stuff. If I want to play around and learn something, suddenly that affects everyone else. It shouldn't.

Even in the hypothetical scenario that sources only exist on a server, there would still have to be branches and personal workspaces for lots of reasons. But there'd be none of the current ridiculously overblown git ceremony around sharing a branch with a colleague if you want them to have a look.
I can't imagine the horror of tracking down a regression and finally fixing it, only to find someone else edited another section of the codebase, ruining all my efforts.

This is fine in text documents (to an extent, obviously references to sections of text that no longer exist can happen) because different sections are not as inextricably linked to each other.

Once everyone is done collaboratively editing, how do you control changes to the file in actual source control (in other words, commit a known configuration and receive formal,audit-sufficient approval from others to integrate the changes into source control)?
How do you test something if multiple people are making changes at the same time?
You don't. Having isolated code bases for each developer and a well-defined merge procedure is a feature, not a bug.

I've seen teams develop on a single target system, all of them bashing on the same source code base at once. It sort of works with a well-tuned team, that communicates well, and is capable of dealing with the resulting inconveniences, up to maybe 3 or 4 developers. Probably helps to have dynamic scripting languages in use by most of the devs so you aren't trying to time your compiles with each other's actions. And they still stepped on each other more than I would have been able to tolerate. There's no way this scales.

For non-code documents, by all means share. English prose doesn't crash if you start editing page 5 while someone else has an incomplete sentence fragment they're in the process of changing on page 2. But trying to edit code that way doesn't scale for squat.

From this point of view, whether it's "files" or "a database" or whatever that's being developed on isn't relevant. The point is that I actively do not want somebody else's half done work randomly getting integrated with what I'm working on right now.

How do you test something is working if one person is making changes?

You stop then test.

You're going to ask everyone else to stop working while you test something? Even if they agree, what if they continue working in between your changes? What if they are halfway through something and the code won't even compile until they're done?

I'm sure you have good ideas about better workflows here but I don't think they're as obvious to other people as you maybe assume?

Not sure if you've ever used git, but developers usually create a branch before editing.

So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test.

> a bunch of you discuss and edit in real time.

So now you have to get everyone into the same headspace at the same time and schedule coding sessions across timezones?

What if two people independently feel like doing some quick incompatible changes late at night? Do they have to message everyone on the team to see if it’s OK? Or do they make a branch of the branch of the branch to test it by themselves? How is that more convenient? And in that world, how can you do those tests privately, without everyone on the team (plus the service you’re using) being able to see them? And what happens when you don’t have an internet connection (or your service is down) but you want to continue working?

I agree with the parent comment, there are too many unanswered questions in your proposed scenario.

The whole blog post in general feels incongruent, and it’s not surprising to me you’re getting conflicting feedback. You’re conflating different scenarios and proposing broad vague ideas which are not only impractical for a multitude of scenarios, they remove user agency and give more power to corporations, which is exactly the opposite of what we should be doing.

How do you personally do that branching without git? What tool(s) do you use?

> So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test

What if you want to test your work out, and don't want to wait until everybody else has finished with their work and stopped working to test? What if you don't want to try to coordinate 100 different instances of "everybody stop working (but also make sure the build isn't broken), I want to run tests" per day?

Once you have branches, you have merges, so you're back to a version of git that's somehow less convenient.
I think what your parent comment is getting at is “how can you reliably test your changes if someone else is changing something else somewhere which may interfere with what you’re editing”.

Your “one person” rebuttal doesn’t work, because one person is not sabotaging themselves in other files of the same project.