Hi! I’ve been working on a new version control system for the past couple months and would like to know what you think.
Jamsync aims to enable software engineers to deploy code in realtime and solve the scaling and UX problems that developers in large companies run into. It's still early in development but functions mostly as a fast file backup and syncing tool currently.
Yeah I agree that live editing is probably a more appropriate name right now but I think there are so many tools that already do that right now and haven't really made much impact. I don't see a large value in the live editing aspect when it comes to developing and deploying faster, even though this system will support it. The live editing is most valuable when preventing merge conflicts and working on several machines. Definitely open to your thoughts though.
1) Agreed, caching might not be great for large files. I don't think this is the only way though. I think there is another approach, that I haven't explored, which is storing a pointer to the last known Data block in each Range block. This means that you can just jump directly to the actual data without having to go through this regeneration or caching process. The space cost of this would be pretty low, one int per block, but it would mean that you wouldn't need to iterate through every change. Still figuring this out though and caching would be the best option if this doesn't work.
2) Yes I haven't totally figured this out yet. I'll give this a look, thanks!
Not currently, but it would definitely be interesting to have an unzip done automatically based on the file type. Then you would be able to track the contents efficiently, rather than having large binary blobs with large diffs. I haven't heard of other version control systems out there doing this.
There are some similarities but Fossil still has a push/pull/commit flow, although it does provide syncing features to automatically pull commits. Also, I don't think it has great support for large files.
Ultimately, the priorities of Fossil are going to be different than Jamsync, since Jamsync is not decentralized. Being centralized means that we'll be able to do some different things, like live file editing, but with some downsides related to replication and distribution.
Haha appreciate you taking a look. One use case is to prevent merge conflicts, especially when working on a fast-moving project. Merge conflicts generally occur when you make changes on some old code. Jamsync constantly "rebases" your changes on top of new changes so that your code will always be up to date. Obviously some merge conflicts will still occur but much less so in this approach.
Multiple times I've been on teams with spray and pray type developers who commit more frequently. Begetting more chaos and rework, of course. But great for apparent "velocity".
Whereas I tend to work slow and deliberate. Doing old timey stuff like unit tests and verifying my code works before committing. Which then puts the onus of resolving merge conflicts onto me. Which then delays my commits. Which means more even more merge conflicts.
A vicious cycle.
It'd be cool if better tooling, such as jamsync, helped mitigate the penalty for doing good work.
This could work for the pulling side but really what jamsync does is both pull and push. Having changes that are always present in the remote means that merge conflicts are less likely. If you were to do this with Git, you would also have to automate the git add, commit, and push steps which would ruin the log in addition to being pretty slow.
