[squeak-dev] The Trunk: Collections-mt.898.mcz

Chris Muller asqueaker at gmail.com
Sat Jun 20 23:13:53 UTC 2020

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?


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

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

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

More information about the Squeak-dev mailing list