On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras
<felipe.contre...@gmail.com> wrote:
> On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>
>>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>>> Felipe Contreras <felipe.contre...@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.contre...@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
I forgot to mention the main objective of the shared repo feature:
+ first/
* first/second/foo
* first/third/foo
* first/fourth/foo
* first/fifth/foo
* first/sixth/foo
Since in bazaar branches are repositories, we want to make it possible
for remote-bzr users to create a single remote per branch as easily as
possible (without having to duplicate huge clones).
But as I said, without this patch, they wouldn't be able to use that
feature if they cloned with v1.8.2.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
