Distribution.Client.VCS

A driver for a version control system, e.g. git, darcs etc.

The type of repository this driver is for.

The vcs program itself. This is used at type Program and ConfiguredProgram.

Validates that the SourceRepo specifies a location URI and a repository type that is supported by a VCS driver.

| It also returns the VCS driver we should use to work with it.

As validateSourceRepo but for a bunch of SourceRepos, and return things in a convenient form to pass to configureVCSs, or to report problems.

Clone a single source repo into a fresh directory, using a configured VCS.

This is for making a new copy, not synchronising an existing copy. It will fail if the destination directory already exists.

Make sure to validate the SourceRepo using validateSourceRepo first.

Synchronise a set of SourceRepos referring to the same repository with corresponding local directories. The local directories may or may not already exist.

The SourceRepo values used in a single invocation of syncSourceRepos, or used across a series of invocations with any local directory must refer to the same repository. That means it must be the same location but they can differ in the branch, or tag or subdir.

The reason to allow multiple related SourceRepos is to allow for the network or storage to be shared between different checkouts of the repo. For example if a single repo contains multiple packages in different subdirs and in some project it may make sense to use a different state of the repo for one subdir compared to another.

The set of all supported VCS drivers, organised by RepoType.

VCS driver for Bazaar.

VCS driver for Darcs.

VCS driver for Git.

VCS driver for Mercurial.

VCS driver for Subversion.

VCS driver for Pijul. Documentation for Pijul can be found at https://pijul.org/manual/introduction.html

2020-04-09 Oleg:

As far as I understand pijul, there are branches and "tags" in pijul, but there aren't a "commit hash" identifying an arbitrary state.

One can create `a pijul tag`, which will make a patch hash, which depends on everything currently in the repository. I guess if you try to apply that patch, you'll be forced to apply all the dependencies too. In other words, there are no named tags.

It's not clear to me whether there is an option to "apply this patch *and* all of its dependencies". And relatedly, whether how to make sure that there are no other patches applied.

With branches it's easier, as you can pull and checkout them, and they seem to be similar enough. Yet, pijul documentations says

Note that the purpose of branches in Pijul is quite different from Git,

since Git's "feature branches" can usually be implemented by just patches.

I guess it means that indeed instead of creating a branch and making PR in GitHub workflow, you'd just create a patch and offer it. You can do that with git too. Push (a branch with) commit to remote and ask other to cherry-pick that commit. Yet, in git identity of commit changes when it applied to other trees, where patches in pijul have will continue to have the same hash.

Unfortunately pijul doesn't talk about conflict resolution. It seems that you get something like:

% pijul status On branch merge

Unresolved conflicts: (fix conflicts and record the resolution with "pijul record ...")

foo

% cat foo first line >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> branch BBB ================================ branch AAA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< last line

And then the `pijul dependencies` would draw you a graph like

• ----> foo on branch B -----> resolve conflict Initial patch

• ----> foo on branch A ----->

Which is seems reasonable.

So currently, pijul support is very experimental, and most likely won't work, even the basics are in place. Tests are also written but disabled, as the branching model differs from git one, for which tests are written.