-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project save backed by git #3851
Conversation
engine/language-server/src/main/scala/org/enso/languageserver/vcsmanager/Git.scala
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a standard PR for language server. Two things I find strange:
- Akka is a an actor framework, there should be no blocking waiting - but there is. Why?
- JGit is added as a dependency of the whole
language-server
project - that is not modular enough - we should have more compilation units and then just assemble them in runtime.
None of my comments is critical. Hence approving anyway.
engine/language-server/src/main/scala/org/enso/languageserver/text/BufferRegistry.scala
Show resolved
Hide resolved
engine/language-server/src/main/scala/org/enso/languageserver/vcsmanager/Git.scala
Outdated
Show resolved
Hide resolved
engine/language-server/src/main/scala/org/enso/languageserver/vcsmanager/Git.scala
Outdated
Show resolved
Hide resolved
engine/language-server/src/main/scala/org/enso/languageserver/vcsmanager/VcsFailureMapper.scala
Show resolved
Hide resolved
import org.enso.jsonrpc.{Error, HasParams, HasResult, Method, Unused} | ||
import org.enso.languageserver.filemanager.Path | ||
|
||
object VcsManagerApi { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this whole VCS related functionality be in its own module? Something like engine/language-server-vcs
? It looks like a quite independent sub-system with its own dependency needs. Separating it into an independent compilation unit would prevent other parts of language-server
code to use JGit API directly when it is supposed to be hidden.
Option1: Define the VcsApi
in 'language-servermodule without any dependencies on JGit. Implement it in the
language-server-vcsimplmodule that will have dependency on JGit as well as
language-server` module. Use ServiceLoader to connect them together.
Option2: Define the VcsApi
in a separate module language-server-vcs
. Implement it in language-server-vcsimpl
module that will have dependency on JGit as well as language-server-vcs
module. Change the language-server
module to depend on language-server-vcs
, use its API. The API module would use ServiceLoader again to find the right implementation during runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seemed like a bit of an overkill at this point. Mostly because we don't use any other VCS implementation right now. If we had more implementations, I would totally agree with you.
Similar thing can be said about other elements of the language server like file manager and all buffer-related stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar thing can be said about other elements of the language server
Yes. There are many other violations, but when will we start fixing them if not when introducing completely new library? Or will we continue building such a megalitic monolith forever?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds to me more like a regular refactoring action that could be applied to different subprojects of language-server
. Mixing that work with project save done here, would make review rather difficult.
So how about we schedule that work with @4e6 separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created https://www.pivotaltracker.com/story/show/183794226 as a follow up work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the fact that you removed the restriction on unique commit name ❤️
Approved, just don't forget to update the protocol-language-server.md
API doc with the new VCS methods before merging.
engine/language-server/src/main/scala/org/enso/languageserver/filemanager/Path.scala
Show resolved
Hide resolved
9d30439
to
fd90ffa
Compare
This change adds VcsManager which is responsible for all version control operations. All operations were abstracted and jGit usage is well hidden behind abstractions. This is an initial support, vcs handlers will likely change once interaction with filemanager/buffers is figured out.
Bugfixes for various corner cases than can happen. Extended coverage for those in our test cases. Added initial json tests for VcsManager.
Ensured that all commit requests, first ensure that all pending saves to the files of the project are done. That way, we are not left with pending file modifications **after** the project was explicitly saved. Added a test to illustrate the scenario. Note that one occassion we have to carry around the sender explicitly, because context changes it for the message once we want to forward it. Added some actor names, so that it is easier to debug potential issues with messages.
Rather than referring to names, one should rather refer to commit SHAs.
API docs revealed a few inconsistencies. This change resolves both.
Autosave on close was an additional requirement that fits the "save always" approach. When a request is made, we check if there are any pending saves from the client and force them, if necessary.
2cd2945
to
df58cdb
Compare
tools/legal-review/engine/org.eclipse.jgit.org.eclipse.jgit-6.3.0.202209071007-r/copyright-keep
Outdated
Show resolved
Hide resolved
tools/legal-review/engine/org.eclipse.jgit.org.eclipse.jgit-6.3.0.202209071007-r/copyright-keep
Outdated
Show resolved
Hide resolved
Rather than hardcoding `.git` in the root of the project, VCS should save data into Enso's data directory (i.e. `.enso`). This change reshuffles initialization and configuration to store Git VCS metadata by default at `.enso/.git`. This is follow up to #3851
Rather than hardcoding `.git` in the root of the project, VCS should save data into Enso's data directory (i.e. `.enso`). This change reshuffles initialization and configuration to store Git VCS metadata by default at `.enso/.git`. This is follow up to #3851
Rather than hard-coding `.git` in the root of the project, VCS should save data into Enso's data directory (i.e. `.enso`). This change reshuffles initialization and configuration to store Git VCS metadata by default at `.enso/.git`. This is follow up to #3851 # Important Notes Apparently a custom Git directory in JGit means that it always creates a `.git` **file** with `gitdir` pointing to the custom location. This is not necessary in our case since all our commands provide that explicitly. That is why `init` operation removes `.git` file, which may seem a bit counter-intuitive.
Pull Request Description
This change adds support for Version Controlled projects in language server.
Version Control supports operations:
init
- initialize VCS for a projectsave
- commit all changes to the project in VCSrestore
- ability to restore project to some pastsave
status
- show the status of the project from VCS' perspectivelist
- show a list of requested savesImportant Notes
Behind the scenes, Enso's VCS uses git (or rather jGit) but nothing stops us from using a different implementation as long as it conforms to the establish API.
Checklist
Please include the following checklist in your PR:
Scala,
Java,
and
Rust
style guides.
./run ide build
and./run ide watch
.