Cloning

[OEP]

Following the server-side forking issue over at django-buffet, it seems like it would be pretty simple to add cloning to python-anyvcs.

Here are some of the changes I would anticipate making:

anyvcs.probe(path)

This would just factor out some of the functionality of anyvcs.open() which discovers the type of repositories on disk into a new public function (though it could be private as well).

anyvcs.clone(srcpath, destpath, vcs=None)

This would clone srcpath to destpath, skips VCS discovery if vcs is set, and returns an instance of {Git,Hg,Svn}Repo rooted at destpath, using the corresponding class's clone() call.

For Git, this would create bare repositories and for Subversion this would create the "central" repositories we currently support.

Unit testing

I'm not sure of everything we'd want to test quite yet. Of course we'd want to test the return type of clone() but I'm not if we'd want to check all the repository operations and make sure they are the same as the source.

Future directions

If at some point in the future we decide to support Subversion working copies, we could add a wc=False parameter to anyvcs.clone(). Setting wc=True implies that a non-bare repository would be made for Git, and a checkout would be made for Subversion. Mercurial just ignores it. This would be backwards-compatible with the API.

I guess the only downside of not supporting wc immediately is that we do support non-bare repositories for git but clone() would not create them. The downside of supporting wc immediately is that the return value for anyvcs.clone(..., vcs='svn', wc=True) is not clear since we do not support SVN working copies.

"Clone" isn't in the SVN verbiage, so another possible direction we could go with this is a different function, anyvcs.checkout(), which does essentially the same thing as wc=True in the previous case. You still have a wording clash here since checkouts are something entirely different in Git and Mercurial. I don't see a technical advantage here, I guess it's more a preference thing (I prefer the former).

[ScottDuckworth]

Good plan.

As for the unit tests, I think it would be adequate to only test the basics: make sure the tip is the same and the path is different.

Git working copies aren't officially supported. We don't have any unit tests for them and I don't remember if I ever even manually tested them. If it works it's only because the git commands we use work the same in working and bare repositories. So I'm in favor of not starting to try to support working copies at this point...maybe later.

Subversion can just suck it up and live with the fact that we call it clone. Actually that operation isn't exactly native in Subversion, so it doesn't even go by another name. It's pretty easy to implement a "clone" for Subversion using svnadmin dump and load - I worked out the details of that for another project. However, doing a merge from a "clone" isn't possible if both repos have changed.

Speaking of merge, do we want to also support conflict-free merging of repos which were cloned at some point? Excluding Subversion, of course.

[OEP]

That all sounds good. I had also planned to pipe load/dump to emulate a clone for SVN. If there were some way to get SVN to hard link its plumbing in an appropriate way I think that'd be preferable, but not even svnsync does that for local syncs. As far as I know, SVN only does hard links for server-side branch creations (within one repo).

I think conflict-free merges would be great to have somewhere along the way, especially since some of our users want to adopt the PR style of workflow. It sounds like a lot of work, whereas clones seemed like low-hanging fruit.

[ScottDuckworth]

I'd say don't worry about hardlinking the Subversion plumbing files. That seems like a bag of worms. If someone is concerned about storing duplicate data then perhaps using a deduplicating file system is the answer.

Merging in git requires a working copy, so it does seem like the correct way to implement git merging would be to get a working copy object, do the merge there, then push back to the bare repo. That algorithm might work best for hg as well in case the merge does have conflicts (we don't want to leave partial merges laying around in the central repo).

So it seems we have some options:

1. Fudge it and go ahead and implement merge in the existing API so that it clones to a temporary directory, does the merge, does the push, then cleans up the temporary directory.
2. Wait until we have proper working copy support.
3. Go ahead and implement partial working copy support, making merge our first and only order of business for the next release.

If we do the 3rd option then I have a feeling that will be fairly easy with git and hg, since the existing commands work pretty much the same for working copies or bare repos, but more involved for Subversion, since the commands are totally different. I'd be in favor of raising NotImplementedError for Subversion in the next release series.

[ScottDuckworth]

Merged in dfcb543b147dff190b29540fafcaee5a28ee6365

[ScottDuckworth]

I will open another issue for the merge feature.