Thanks for the feedback! What about a version control system would be valuable for storing your documents? I'm curious why you couldn't use something like Google Drive/Dropbox.
Appreciate the feedback! Will keep this use case in mind, this could definitely work as a layer on top of Git when people need to pair program or preview code.
Yeah this project is still pretty early in development. The main algorithm described on the site is implemented but there's a lot missing that developers would expect from a system like this. Trying to make a version control system and hosting platform in my free time while working a full-time job is not exactly an easy task haha. I plan on adding more features in the next few months.
Hi! This is the first time I'm posting publicly about this in-development project so thanks for the feedback.
Causing a conflict will cause a .jamdiff file to be written out on the next sync with the remote changes and I'm planning on adding branches in the next update which will make how this works more clear. There's still a concept of parallel editing, since features cannot be developed/tested simultaneously without breaking. Also, anytime there's a conflict, we can just make a new branch and ask the developer to merge or keep working on the new branch.
The client will watch your file system for changes and hold a gRPC stream open for remote changes. If you don't want to sync your changes, you don't have to leave the command running. CI/CD support will come later.
I'll be compliant with regulations soon, but I'm not really expecting people to use this yet. I mostly wanted to release the source and see what people thought of the project. I am using GDPR compliant Plausible analytics if that makes you feel better!
Thanks for the suggestion on the source, the zip file is up-to-date and is part of my build process. I might host on Github in the future but really wanted to make this the source of truth. My goal of open-sourcing is not to get contributors, but to give back to people who want to view the code and self host.
> Also, anytime there's a conflict, we can just make a new branch and ask the developer to merge or keep working on the new branch.
Ok so this tool doesn't solve the problem of merge conflicts.
> The client will watch your file system for changes and hold a gRPC stream open for remote changes. If you don't want to sync your changes, you don't have to leave the command running. CI/CD support will come later.
Eek then the thing isn't consistent if two of us are using this tool and I keep it open all the time I'll generate a lot of commits. If you only run the command sporadically you'll generate significantly less.
> I'll be compliant with regulations soon, but I'm not really expecting people to use this yet. I mostly wanted to release the source and see what people thought of the project. I am using GDPR compliant Plausible analytics if that makes you feel better!
I feel nothing only pain :-). I note that you have missed out my comments on limiting your liability. Since you seem to be deliberately doing that I'll give you some advice. There are some heinous people online who will use this service in it's current form to share some vile shit with each other. At the moment you are liable for that. IANAL.
> Thanks for the suggestion on the source, the zip file is up-to-date and is part of my build process. I might host on Github in the future but really wanted to make this the source of truth. My goal of open-sourcing is not to get contributors, but to give back to people who want to view the code and self host.
Erm you know I can see the source. You have the code stored in a private repo in github.
Appreciate the feedback! I used the same name for that project but this is actually a completely different project rewritten from scratch and open-source. I've been working on the general idea for a better VCS for some time so I've restarted around 6 times so far to get something that works. Not sure it will be too productive to continue the conversation here but feel free to reach out to me if you would like.
Yes, that's one way to think about it. You could probably say it's closer to Google Drive than a VCS right now but my idea is to make a VCS that's more collaborative than the options currently available. Some people will have no issues with the current VCS that we have now but many developers that I've talked to have expressed frustration with the general user experience of VCSs and when merge conflicts occur.
The rsync paper https://www.andrew.cmu.edu/course/15-749/READINGS/required/c... is better than me at explaining this, but the rolling hash is the key to solving this misalignment problem that you describe. Essentially, using the rolling hash enables you to detect when a block as been misaligned (bytes added at the beginning of the file for example). There's no way to cause expensive resyncs in this case since it rolls over every byte in the file and reuses blocks on any alignment, even with data inserted in between.
Thanks! Yeah planning on adding the ability to mount specific directories so people don't have to pull down large assets they don't need, for example in gamedev or machine learning applications.
I'm still figuring out semantics, but currently a "commit" is made every time you make a change to a file which is synced to the remote. Every time you run `jam`, you push a commit. Or if you leave `jam` running, commits will be made each time you save. 3-way merging will be possible in the future, but will be a little different than most VCS since there is no history stored locally.
So how do you communicate with other developers the intention of a commit or set of commits, like you would with commit messages in git? How do you rewrite/cleanup history?
This is still in-development but my plan is to essentially have "branches" which are merged and create a single "commit" on the main branch. You'll have the option to add information to a branch and a merge message if you would like, but it won't be required. I don't have any approaches on rewriting/cleaning up history right now since I think managing code history is pretty low-value for most teams. In my experience, it's far better to add another commit than it is to try to change history. Would be curious to know your thoughts though!
This sounds great. Your VCS should fade into the background, rather than be front and center like git. Nobody should be breaking their flow, staging, committing, pushing as an ersatz backup, and then going back to coding. Teams shouldn't be bikeshedding on merge vs rebase, many commits vs one commit, etc. They should just be coding.
However I can see where a sort of "checkpoint" feature before performing a "hold my beer" change makes sense. A commit in some sense. `jam checkpoint` ... code ... `jam revert`
You should just be coding, and when the thing your are coding is done just do a single "squash merge (in git speak)" to the main branch.
> This sounds great. Your VCS should fade into the background, rather than be front and center like git...Teams shouldn't be bikeshedding on merge vs rebase, many commits vs one commit, etc. They should just be coding.
you're being too hard on git. large teams sharing code in previous SCCS rcs's (haha) would frequently encounter locks and not be able to "just code" but would need to negotiate with teammates or complain to committees. The features of git allow you to "just code" in a group environment, but it moves conflicts to a different link in the chain. The interplay between changes sprinkled across a codebase need to be negotiated in any system, but git generally allows you to "just code" till it makes sense or is convenient to negotiate
I've been around long enough to know git is so much better than what came before, and I appreciate it. But even so, git yak shaving still consumes more developer time than it should.
that's fair. I just didn't like seeing git sold down the river for the feature it does better than what was before :)
maybe "git with wimpy locks" would be a nice feature. if you're editing files, the center node could keep track of that, and if I go to edit one of those files, I could be told that you've already edited it. I could forge ahead ("break the lock" and you would get notice) or I could ask you. It doesn't resolve all problem between prickly developers with different styles of workflow, but it would increase communication at little cost.
