As cool as git is, this seems to be more obtrusive and take more time than necessary as opposed to the old system where changes were automatically committed when you closed out a script; if I wanted version control that allowed staged changes and conflict resolution, I would just use git and rojo.
I was expecting something more like google docs, where multiple people can edit at the same time and see each others’ cursor positions. This is kind of a let-down for me to be honest, and I don’t think I’ll be enabling it as it slows down my workflow rather than speeding it up in most cases. I’ll try it out for a day or so maybe though, since I do find myself using the “apply edits” all the time with the old system, so it’s not too different from before in the end.
The main difference about this is that you have to constantly keep the “drafts” window open if you’re editing a script (another thing unnecessarily taking up space in studio), and your drafts aren’t automatically applied when you leave the team create place unlike the old system.
It would be nice if “Commit” was added to this context menu, and the “*” indicator was brought back to show that your changes have not been committed.
The drafts dialog is particularly inconvenient because it only appears once you make changes to a script, and if you stack windows on top of each other (like I do, because I don’t want this window to take up so much of my dang screen), it doesn’t automatically become the active tab when it first appears. There’s no option in the “View” toolbar to show the drafts window, so I’m guessing it’s its own sort of system. Just another clunky slowdown to my workflow.
Finally, one more inconvenient part is the need to go down the list and commit every single module one by one, rather than staging multiple changes together. This is awfully inconvenient, since usually my changes when working on a particular feature span multiple modules at once. With the old system, although it was inconvenient to apply edits one by one as well, I could just right click and hit “Close all scripts” to apply edits on every script with drafted changes.
“This person” can delete the scripts you are working on, but you may simply restore it, so really, there’s no threat by your claim. Instead, it offers more security with the system of drafts and personalized scripts that may or may not be published to the Server.
Not really. This is more of an alternative to the GitHub/Visual Studio Code/Rojo setup if someone doesn’t want to use third-party programs but rather use a first-party feature for version control of their game.
THANK YOU! This is an amazing update that many people were surely looking forward to. Now I can not only collaborate with others with even more ease, but I’ll also have an easier time helping my friends learn how to script.
This sounds like a great update! I am sure that many developers who collaborate will make use of this! It’s always nice to see improvements to Studio, and I for one am encouraged to see such an active development team working on it.
This update is nice, thankfully it came sooner than later… The studio updates improvements are getting better as it goes, keep it up, thanks for the release… happy holidays.
I’m extremely excited to use this. But, I’m also skeptical of it:
Does it provide value.
and how will this impact future additions.
Value
It is pretty limited right now so I can’t say for sure (like traditional version control). The biggest advantage of version control is that it keeps software in sync with a team of developers. But Roblox does not get this advantage, as it already had it before.
Even in an Agile development workflow with version control that handles merging, people are usually discouraged from working on the same file. It just leaves too high of a potential for conflicts and bugs being introduced in the merging process.
If this is the feature on the roadmap (Script Collaboration), I can’t say this was what I was expecting (thought it would be more like Microsoft LiveShare). I definitely wanted version control for Roblox places, but more so for version history and revision support.
If no one can see your changes (source code, not results) until after you’ve commited to them, is it even collaborative?What is the point?
Future Potential
Considering Roblox allows clients to send several events, seconds apart, using a RemoteEvent, I don’t think it is too improbable for Roblox to distribute clusters of text to studio instances that aren’t running the game. At first, thinking about it, I didn’t think Roblox could support both workflows going forward. But thinking about it, Visual Studio Code is a good example of how to support this. Editors just have to be invited to work on a single copy and the host has to commit it.
As for place-level version control, don’t think this changes anything. Just changes how the server receives changes.
Very sorry for the long reply, but I feel it is important to consider and entirely related.
This is amazing, can’t wait to try it out. I still prefer having a full repository external from Roblox, but I can definitely see people building better code with these improvements.
Other people have already provided answers to this comment, but here’s another thing, and this may be a bit off topic but it’s also relevant:
[A] Stop complaining about new features. NOTHING is going to be perfect, at least this is an improvement.
[B] The entire point of this update was to be able to collaborate but ALSO to ensure that there’s an extra cushion against someone deleting your scripts. Now, you can see WHO deleted your scripts and then re-add them without a hassle. PLUS, you now have the chance to stop a developer you just fired from destroying your work by seeing what they did and then reverting it.
Sorry, this is due to a limitation of not having access to keyboard modifiers in Lua widgets. We support multiselect (shift/ctrl) in the drafts window, but we are still working on improving our input pipeline so Lua code in plugin widgets can know when you have a modifier pressed.
This is a bug, and we are tracking it internally. Thanks!
Got approval from Design for the commit option and are looking into the indicator. Thanks for the suggestion!
Supplanting git and rojo was not the goal of this project. For starters, this alleviates the problem of being locked out of scripts when someone else is editing them, and not being able to sign off for the day with pending edits to a script without 1) submitting your half-working changes, 2) keeping studio open, or 3) extending how long you work so you can unlock the script.
Between drafts and a Google docs-like approach, the latter did not put us in a state that provided significant benefit over the existing one. Before being able to test your changes, you must first wait for every developer modifying the script to get it to a working state, and you do not get a holistic view of how your changes are impacted and affect other developers’ work since it is all happening in realtime (compared to drafts in which you can review interim changes with diffs or the merge window before committing). At this point, we would just be trading some problems with script locking for some new ones with realtime collaboration.
Realtime collaboration does have its benefits, as mentioned by previous users. If you would like us to support it as well, please make a feature request.
We are aware there are many ways we can expand collaborative editing. That said, we had two options:
Wait a year or few until we have a fully-featured set of collaborative editing tools to release any of it
Iteratively release pieces as we are able
We chose the latter, as it allows us to both alleviate existing pain points more quickly, and get feedback on the feature early and act on community thoughts & ideas as we continue work. Had we chose the former, you would be stuck with script locking for a much longer time, and we would have had to guess what developers wanted without asking their input for years.
Yes, this is collaborative and mirrors the same behavior you get from other source control like Git and Perforce. You are unable to see other developers’ local changes in a Git source controlled project until they are committed from their local machine to their branch, just as with Collaborative Editing. Likewise, local changes to a Perforce source controlled project are not visible to anyone else until they are committed or shelved.
It is not really possible for us to apply this kind of feedback towards future iterations. If you are looking to shape the future of Collaborative Editing, it is more effective to provide feedback on what the feature has done / should do, rather than whether particular business requirements were fulfilled. We have a Post_Approval team that can provide pointers, should you need any.
YOU 
