Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add test coverage for transitive source dependencies

If root -> first -> second, the root build should contain

VCS mappings for all builds.

- first will be cloned and added as an implicit build

- second will be cloned and added as an implicit build

  1. … 1 more file in changeset.
Refactor populate to return working directory

In an attempt to implement locking of the git clone directory in

gradle/gradle-native#146, we realized that the directory locking

mechanism writes a lock file into the directory being locked. That

lock file prevents jGit from cloning into the directory because it

expects directories to be empty when they are the target of a clone

operation.

This change moves the responsibility for calculating the path to the

working directory into the VersionControlSystem and provides the

populate method with a parent directory which can be the target of

locking.

Part of gradle/gradle-native#146

  1. … 6 more files in changeset.
Address review feedback

  1. … 11 more files in changeset.
Add a GitVersionRef and implement getAvailableVersions

This should provide everything needed to make progress on

gradle/gradle-native#87

Part of gradle/gradle-native#88

  1. … 3 more files in changeset.
Add version ref to Vcs populate

    • -0
    • +85
    ./GitRepository.java
  1. … 13 more files in changeset.
Downgrade to last version of JGit to support Java 7

  1. … 2 more files in changeset.
Remove dependency on JGit test fixture

- Use our own fixture that drives Git itself

- We can control where the temporary files live and use our

other fixtures (e.g., TestFile)

  1. … 3 more files in changeset.
Move more logic into the TemporaryGitRepository fixture

We don't have to expose the whole fine-grained API used in the JGit

unittests to meet our needs for testig Gradle code. This narrower

API allows us to reuse more logic.

    • -151
    • +24
    ./TemporaryGitRepository.java
  1. … 1 more file in changeset.
Spike a GitVersionControlSystem

This spike just shows as a proof of concept how we can generically

approach version control system integration. This spike demonstrates:

* The use of a `VersionControlSpec` to define the url of the

remote repository.

* The use of a `VersionControlSystem` as the high-level abstraction

for all version control systems.

* A *very* rudimentary implementation of the `populate` method

for a `GitVersionControlSystem`

* An initial fixture for testing our Git integration.

The spike does not yet cover:

* How to get an instance of the correct type of version control

system based on the type of the version control spec that was

provided. But, we'll probably use some version control

system registry.

* Sophisticated handling for many common scenarios when

populating a working directory from a repository.

* Working directory exists and has correct remote.

* Working directory exists but is not a git repository.

* Working directory exists but has other remote.

* Multiple working directories for the same remote.

* Poorly formed user-input.

Related to https://github.com/gradle/gradle-native/issues/107

    • -0
    • +202
    ./TemporaryGitRepository.java
  1. … 9 more files in changeset.