Enable custom unit test location with standard location fallback#1035
Enable custom unit test location with standard location fallback#1035nulltoken merged 1 commit intolibgit2:vNextfrom whoisj:custom-unit-test-folder
Conversation
There was a problem hiding this comment.
Could you please add a new line after this brace?
|
Added instructions to the README.md per @nulltoken |
README.md
Outdated
There was a problem hiding this comment.
How about adding a bullet point with a quick one liner (Powershell, maybe?) showing how to set the LibGit2TestPath to the new mounted drive.
There was a problem hiding this comment.
Also maybe should we adding a quick note explaining that if the path doesn't exist, the test repos will fallback to standard location?
There was a problem hiding this comment.
Two more nitpicks:
- Regarding the command line to imdisk.exe, I think a quote (") is missing at the end
- It may be worth it to specifiy that this command should be run with elevated privileges.
There was a problem hiding this comment.
Yes, missing quote on the command (copy/paste error there). Agreed, need to mention elevated privileges requirement.
I'll add the fallback note to reassure readers.
As for PowerShell, I've no PowerShell experience and would have no idea where to begin.
There was a problem hiding this comment.
As for PowerShell, I've no PowerShell experience and would have no idea where to begin.
Ok. We'll update the doc if users struggle with this.
Enable custom unit test location with standard location fallback
|
Awesome feature Thanks! |
|
Published as NuGet pre-release package |
Enables developers of Libgit2Sharp to use a custom path for the temporary repositories used during unit testing. For example, I've setup a RAM disk on my development machine. While the RAM disk isn't suitable for all of operating system's
%TEMP%needs, it's ideal for unit testing Libgit2Sharp.On my Surface Pro 3 (Core i5 version) unit tests are reduced from roughly 17 minute to around 2 minutes. Basically an order of magnitude improvement.
Of course, we should fallback to the traditional
%TEMP%folder if the developer hasn't provided a viable alternative.This PR has no impact on non-Windows development environments.