On Sat, Jun 20, 2020 at 5:01 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Hi Chris,
>
> Le sam. 20 juin 2020 à 23:39, Chris Muller <asqueaker at gmail.com> a écrit :
>
>> Hi Nicolas,
>>
>> On Tue, Jun 16, 2020 at 3:10 AM Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>> Hi Marcel,
>>> The presence of whole ancestry is not mandatory, as long as the common
>>> ancestor is present.
>>>
>> MC is robust to the absence of some ancestors.
>>>
>>
>> While I think we should squash a lot more meat into our Versions, once
>> its in the ancestry, it needs to be in the Repository.
>>
>> It's fine to skip numbers but, if, by 'absence', you mean a VersionInfo
>> in the ancestry which is absent from the Repository, then no, it is not
>> robust to that and represents an incomplete and corrupt code model.  Please
>> don't allow this to happen.
>>
>> To me, as long as the missing part is not the common ancestor, I don't
> see the problem at client side.
>

> Can you point me to the point of failure?
> Is it on the server or the client?
>

- Diffing that version from its ancestor.
- origin function

It's a hole in the data.  Is there some reason you _want_ to do this (e.g.,
to save disk space?) or, is this just a one-off boo boo?  If the former,
IMO, we should actually do the opposite -- trim the superfluous commits
from the in-RAM VersionInfo's, not the Repository.


>
> This came up last year, after a long circular discussion, we realized MC
>> does indeed handle duplicate filenames (by automatically renaming as
>> necessary).
>>
>> That's about the case of name conflict for two different commits (2
> different UUID), isn't it?
>

Yes.


> Can we see the 2 different commits at client side?
>

Certainly, in the ancestry, you can.  In the Repository browser...  I'm not
sure.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200620/4ddf6912/attachment.html>