On Sun, Aug 4, 2013 at 5:38 AM, Antoine Pelisse <apelisse@xxxxxxxxx> wrote: > 6796d49 (remote-hg: use a shared repository store) introduced sharing > repository capability, but it broke backward-compatibility with already > existing repositories. > > Indeed, 6796d49 assumes that .git/hg/.hg (the shared repository) will > exist if .git/hg exists. > This can be false for already existing clones. It can also be false for > local repository that are not cloned. > > Fixes the compatibility break by always cloning into .git/hg/.shared > (even for local repositories). This seems to presume that there's no way to fix it otherwise, but there is. Maybe always cloning is a good idea, maybe it's not, but that is a change that should be done in a separate commit, and it can. > In order to avoid expensive clone > retrieval from slow remotes, also look for already existing clones in > .git/hg/$aliases/clone. This is yet another change that should be in yet another patch. > Reported-by: Joern Hees <dev@xxxxxxxxxxxx> > Suggested-by: Felipe Contreras <felipe.contreras@xxxxxxxxx> > Signed-off-by: Antoine Pelisse <apelisse@xxxxxxxxx> > --- > Hey, > > OK, I think this version will work in all cases. > Either you clone local and then remote, or remote and then local, > or old version local and then remote, or old version remote and then local: > You will always either have .shared repo already cloned, or will find a way to > create it: either by using an already existing clone, or by cloning the given > url (and that last step can't be done if we don't use .shared). Perhaps it would work in all the cases, but it would need to reclone if the user is updating from v1.8.3. > I also decided to always clone local repositories because what Jörn Hees > said makes sense: > If you have a local clone of a big repository, and then want to add a slow > remote, you would have to reclone everything. > I think the trade-off is good, because clone from local should not be that > time expensive (maybe it can be on disk-space though). As I said; this should be discussed in a different patch. Personally I think the current behavior is all right, because the use case of cloning a local repository is way more common that cloning a repository, and then adding a slow remote. We should optimize for the common use-case. -- Felipe Contreras -- 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