On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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@xxxxxxxxx>
>>>> ---
>>>
>>> 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
--
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