Re: [PATCH] remote-bzr: update old organization

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 14, 2013, 20:50 UTC
Message-ID: <CAMP44s2B3bFWXZe0aL_GMXe_56MbhSZXf-65rT364nY3shYwUA@mail.gmail.com>
In-Reply-To: <7v8v3hi9ix.fsf@alter.siamese.dyndns.org>

On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 34 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> If a clone exists with the old organization (v1.8.2) it will prevent the
>>>> new shared repository organization from working, so let's remove this
>>>> repository, which is not used any more.
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>
>>> What happens with and without this patch to an existing user from
>>> 1.8.2 days, when she does what?
>>
>> I already explained it would prevent the new shared repository
>> organization from working, so the old organization would be used; the
>> repositories won't be shared.
>>
>>> A sample answer (to show the level of descriptiveness, not the
>>> content, I am epecting) might go something like "Because the
>>> organization is different, it will barf whenever she tries to
>>> incrementally update from the other side. By removing the old one
>>> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
>>> ends up reimporting the whole history, though."
>>
>> Bazaar won't barf, the repositories will be duplicated, so the shared
>> feature won't work.
>
> But by removing the old incarnation, you are getting rid of the copy
> for which the shared feature will not work, so with patch, "won't
> work" is no longer an issue.  Is the user making a trade-off by
> using Git with this patch?  What is she losing by removal, if
> anything?

No. The way repositories work in bazaar is tricky:

Suppose you have a directory like this:

+* first/second/foo +* first/second/bar

Both the branch and the repository are on the same directory (hence +*). We have two branches, and two independent repositories.

And then you have a shared repo:

+ first/
* first/second/foo
* first/second/bar

Now we have a single repository shared between two branches.

But:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar

If there's another repository in-between, neither 'foo' nor 'bar' can reach 'first', so they are stuck with the repository in 'second', which is not a shared repository, so they must create their own repositories, but even if they could use 'second', there still would be a problem:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar
+* first/third
+* first/third/foo
+* first/third/bar

We want 'second' and 'third' to share to object tree, but we can't.

This patch would remove the old repository ('second' and 'third') so we have exactly what we want:

+ first/
* first/second/foo
* first/second/bar
* first/third/foo
* first/third/bar

A single bzr repository shared by all the branches and all the repos.

In reality it probably wouldn't be a big deal, because in v1.8.2 users couldn't clone true bzr repos, but there are some bazaar repos with a single branch they could clone, and there would be a single duplicated repo, like this:

+ first/
+* first/second/foo
+* first/third/foo

-- 
Felipe Contreras