Hacker News new | past | comments | ask | show | jobs | submit login

I never understood this either.

Why not simply lock the file automatically when someone types and unlock it after a few seconds pause.

What do I get from parallel edits? When I finish my stuff and my collaborator isn't finished, we will end up with broken code until they have finished editing.

Sure it is nice to be able to write comments at some place while someone else edits code at another place, but then row-based locking would do the trick too.

Sure, you can do this but you’re basically sacrificing collaborative editing and you’re going to end up with a very laggy system. You’re also going to have to implement distributed locking which isn’t as easy as it looks.

Also if the connection drops then you’re going to loose any pending edits because you’ve lost your lock.

> When I finish my stuff and my collaborator isn't finished, we will end up with broken code until they have finished editing.

You can’t actually do this under the model you’ve suggested because your collaborator will be locked out of editing the document while you edit it. So if they’re editing then you just have to sit there staring at your screen.

In our company, we work with a small team on each pentest, and we do have concurrent edits in the same file quite regularly. One example is going through the network scan results at the beginning of a test: one person works from the top, the other from the bottom, and frequently, we will be editing the file at the same time because we are just getting an overview of the infrastructure and picking interesting targets. Locking the whole file would actually be cumbersome for us.

But I agree that locking sounds like a fairly low-tech solution to reliably solve the issue, though I would do it on row level (or perhaps the current row plus one above and below). The way I see this work is that your client will automatically fetch a lock on the row where your cursor is placed, and you can type at will. If you are inactive, your client could automatically release the lock. Most of the time you're not working on the exact same line as someone else anyway (two persons one sentence, feels a little like trying to type with two persons on one keyboard).

Edit: In a sibling thread, u/espadrine raised a good point:

> what if concurrently someone inserts Enter on line 3? Executing "line 9 […] insert <Enter>" must not be done on line 9.

I guess my idea of line locking may not work after all. Or at least, we would have to change "line number" to some identifier that can not be modified by an edit.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact