[PATCH] unionrepo: read-only operations on a union of two localrepos

Mads Kiilerich mads at kiilerich.com
Fri Feb 8 11:59:58 CST 2013

On 02/08/2013 04:22 PM, Brodie Rao wrote:
> On Fri, Feb 8, 2013 at 11:12 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> # HG changeset patch
>> # User Mads Kiilerich <madski at unity3d.com>
>> # Date 1358520849 -3600
>> # Node ID 1f62f308ce833825eb8878af4b0c42a7eb1ea175
>> # Parent  2fefd1170bf269e26bb304553009f38e0117c342
>> unionrepo: read-only operations on a union of two localrepos
>> unionrepo is just like bundlerepo without bundles.
>> The implementation is very similar to bundlerepo, but I don't see any obvious
>> way to generalize it.
>> Some most obvious use cases for this would be log and diff across local repos,
>> as a kind of preview of pulls, for instance:
>>    $ hg -R union:repo1+repo2 heads
>>    $ hg -R union:repo1+repo2 log -r REPO1REV -r REPO2REV
>>    $ hg -R union:repo1+repo2 log -r '::REPO1REV-::REPO2REV'
>>    $ hg -R union:repo1+repo2 log -r 'ancestor(REPO1REV,REPO2REV)'
>>    $ hg -R union:repo1+repo2 diff -r REPO1REV -r REPO2REV
>> This is going to be used in RhodeCode, and Bitbucket already uses something
>> similar. Having a core implementation would be beneficial.
> It might be useful to support an arbitrary number of unions. It should
> be pretty easy to extend this to support that.

Yes, that could be added later if someone has a use case for it.

It could also make equally much sense for bundlerepo to support multiple 
bundles. But I guess it easily could confuse what corresponds to the 
existing 'hg -R bundle:b.hg' functionality where it bases the aggregate 
repo on the  'current' repo.

>> +def instance(ui, path, create):
>> +    u = util.url(path)
>> +    assert u.scheme == 'union'
>> +    repopath, repopath2 = u.path.split("+", 1)
>> +    return unionrepository(ui, repopath, repopath2)
> This should raise util.Abort() if create is True, since creating a
> unionrepo wouldn't make much sense. bundlerepo does this same check
> already.

Agreed. Next version will do that. And I will reuse more code from 

> On a related note, it'd be interesting to see what happens if you
> clone a repo with a union: destination.

In the next version it will fail in the abort mentioned above.

(bundlerepo would create a repo named 'repo1+repo2.hg' - probably 
because of the special handling in the url class).


More information about the Mercurial-devel mailing list