<div dir="ltr"><div dir="ltr">On Sat, Jun 20, 2020 at 5:01 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div>Hi Chris,<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 20 juin 2020 à 23:39, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Nicolas,</div><div dir="ltr"><br></div><div dir="ltr">On Tue, Jun 16, 2020 at 3:10 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Marcel,</div><div>The presence of whole ancestry is not mandatory, as long as the common ancestor is present. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>MC is robust to the absence of some ancestors.</div></div></blockquote><div><br></div><div>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.<br><br>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.</div><div><br></div></div></div></blockquote><div><div>To me, as long as the missing part is not the common ancestor, I don't see the problem at client side. </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Can you point me to the point of failure?</div><div>Is it on the server or the client?</div></div></div></blockquote><div><br></div><div>- Diffing that version from its ancestor.</div><div>- origin function</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>This came up last year, after a long circular discussion, we realized MC does indeed handle duplicate filenames (by automatically renaming as necessary).</div><div><br></div></div></div></blockquote><div>That's about the case of name conflict for two different commits (2 different UUID), isn't it?</div></div></div></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Can we see the 2 different commits at client side?<br></div></div></div></blockquote><div><br></div><div>Certainly, in the ancestry, you can.  In the Repository browser...  I'm not sure.</div><div><br></div><div> - Chris</div></div></div>