Fixes for issues #35 #48 #78
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 8 commits
November 18, 2013 17:14
We will later rename "Timeouts" to "Time", grouping there all time-related utils
"Timeouts" is in project d-build, but that is not imported by some places where timed() would be useful
By using refspecs in a different manner, it is no longer necessary to manually adjust local refs to match possibly changing remote refs: all is done by force during fetch. Still experimenting with jgit at this time, although this chane in logic makes the theoretical speed benefit of jgit moot, and the absence of hard linking a significant disadvantage.
This commit completely reorganizes the git support infrastructure, making it considerably faster and adding optional jgit support. The number of git invocations is now reduced, by using specially crafted refspecs that allow "fetch" to replicate all of the remote tags, branches, etc, in a single operation. The references of the form "pull/nnn/head", for Github pull requests, are now fully supported and involve no particular speed penalty during regular use. Support for jgit has also been added. Since jgit has no support for hardlinking, however, additional copies of all clones will be made, which is both slower and uses more disk space. Because of this reason, jgit is not the default resolver for "git://" schemes. It can be selected, however, just by specifying a URI of the form "jgit://" in one or all the projects. This commit closes #48, and closes #35.
The git resolver uses jgit, but jgit may also be used by sbt. The support-default project is a dependency of the sbt plugin, and jgit changed packages structure in a non-compatible way, meaning that either sbt or the dbuild sbt plugin may be left unable to find their correct jgit classes, after Ivy completes its resolution and picks one of the two. This commit moves jgit to a separate project, which does not get included with the dbuild sbt plugin, thereby removing the conflict.
ghost
assigned 
|
LGTM - Nice work here, especially the optimisations. Is there a noticiable speed difference between jgit/git we should document? I understand the file-copying concerns, but in my experience sometimes JGit lead to faster checkout/resolve times than Git. |
|
I've not benchmarked, but while testing I had the impression that they were essentially the same speed, at least in this scenario. I added a timer for this reason, and saw no large differences. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adding support for JGit, supporting Github's "pull/nnn/head" references for pull requests, and improving the resolution logic for git repositories, making it both more robust and faster.