Hi,
On 24.07.2013, at 10:52, Antoine Pelisse <apelisse@xxxxxxxxx> wrote:
> I think the best way would be to create the shared repository in
> .git/hg/$share, with $share being a path that can't be a remote name
> (so that it doesn't conflict with remote directories),
> and then apply the following patch (copied in gmail)
Maybe ".git/hg/.share"?
> diff --git a/contrib/remote-helpers/git-remote-hg
> b/contrib/remote-helpers/git-remote-hg
> index 0194c67..21c8091 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -390,7 +390,7 @@ def get_repo(url, alias):
> if not os.path.exists(dirname):
> os.makedirs(dirname)
> else:
> - shared_path = os.path.join(gitdir, 'hg')
> + shared_path = os.path.join(gitdir, 'hg', $share)
> if not os.path.exists(shared_path):
> try:
> hg.clone(myui, {}, url, shared_path, update=False, pull=True)
>
> That way, the share can be created even if .git/hg already exists
> (because of a previous import, before the shared machinery existed, or
> because you already have a local remote).
I like the idea of having independent remotes (fetching one, doesn't update another). http://mercurial.selenic.com/wiki/ShareExtension warns about this, and i wasn't sure it wouldn't cause intricate bugs. This is why I opted for the explicit cloning, no shared history for several remotes.
I'd really like some feedback on this one as he probably knows the hg internals well enough that he can make a more educated guess on this than I can: when you import several hg remotes and fetch them / push to one, wouldn't such a shared repo cause problems?
If unsure i still opt for my version as it keeps things isolated at the cost of some optimization.
>> Changing gitdir to dirname causes shared_path ==
>> .git/hg/<remote_name>/hg. The call to hg.share with local_path ==
>> .git/hg/<remote_name>/clone works again.
>
> I think that will be a problem, because then the shared_path will no
> longer be shared, will it ?
Yupp, the shared_paths won't be shared, so it's not as optimal as possible, but it will work at least ;)
Cheers,
Jörn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html