<div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 4. März 2019 um 15:24 Uhr schrieb Tudor Girba <<a href="mailto:tudor@tudorgirba.com">tudor@tudorgirba.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Do you have experience of using Squot on a project of the size of VMMaker? Would you like to try to see how it works? And does it work for Tonel, or only for FileTree?<br></blockquote><div><br></div><div>At the moment, it is only FileTree, but the Tonel adapter is in the works. No, I have not used Squot on a project as large as VMMaker. Squot itself is probably medium-sized and is the largest project I use it on. I have also not used the Monticello converter on a larger history than that of FileSystem-Git and FileSystem for Squeak (their numbers were less than a tenth of those on VMMaker). The converter is probably slower than git-migration because it uses neither git-fast-import, nor libgit2. Since the history conversion is a seldom task, I did not bother to make it as quick as possible. I might try to convert the VMMaker ancestry to see how it goes and how long it takes. But since I have no personal projects in VMMaker, I would only evaluate how the conversion went and nothing more.</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">
<br>
In any case, I also believe that it is not unreasonable to merge things in one linear history (or even to discard parallel Monticello branches). Here is my reasoning: the way the whole history in Monticello is, to a good extent, via the author timestamp. This essentially provides one change. So, for all practical purposes, preserving the main linear history is good enough.<br></blockquote><div><br></div><div>It is good enough to continue working on the present state of a project, sure. But it will incite angriness if someone inspects the history (someone will do it) and runs into problems like Nicolas did. Once you have chosen to lose something (accurate ancestry) during the conversion, you won't be able to get it back so easily in the future. Moreover, you cannot easily rewrite the Git history again after you have shared it (in case you might change your mind and want to fix up the ancestry later). That's why I would be very cautious and advise against being satisfied with just "good enough". The Squot converter is not perfect in that regard either, as it currently loses the Monticello version names and UUIDs. Maybe I should better put these at the bottom of the commit messages.</div><div><br></div><div>Missing versions are a nuisance, too. But unless you know where to find them...</div><div><br></div><div>Best,</div><div>Jakob</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">
<br>
> On Mar 4, 2019, at 8:42 AM, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br>
> <br>
> I had a quick look at the git-migration code. From what I saw, it binds all packages together in a linear history. Though the versions are topologically sorted by the Monticello ancestry, this approach cannot preserve any branches, or parallel changes, as Nicolas noted. Thus, it produces wrong diffs. Though, it is perfectly adequate for most one-person projects or projects with a Subversion-like commit policy ("you must always merge newer versions before you save"). I guess that is the majority of Monticello projects.<br>
> <br>
> For the converter in Squot, I chose to write one strand of commits for each package, ending in a branch. The history on each strand maps the package's Monticello ancestry accurately (except that the diffs for missing versions are still missing). But it is not appealing to work with each package on a different branch, of course. Unless you have Monticello configurations, that's all the model provides, is it? You can still get an idea of the inter-package history by viewing the log sorted by author timestamps (--author-date-order), but you cannot really bisect it, for example.<br>
> <br>
> What I did in my repositories so far is import the packages on separate branches and then create an n-way merge (with the command line tools) that pulls all the packages together from the point on when I established the Git repository.<br>
> <br>
> Binding the packages together in a common history needs some kind of heuristic that guesses the past configurations that were in use. For example, timestamps and authors could be used. Let's say contributors abc and xyz worked on some project in parallel and created versions in multiple packages. Then you could assume that PkgX-abc.8 and PkgY-abc.42 with similar timestamps belong to the same branch, while PkgX-xyz.8 (with the same parent as PkgX-abc.8) and PkgZ-xyz.5 with similar timestamps belong to a different branch. There will most certainly be scenarios where the heuristic breaks. For example, when the change in PkgZ-xyz.5 is also relevant for abc's work and she "invisibly" adopts it on her "branch" in Monticello. Or when abc works on her branch and then must quickly fix a bug on whatever "master" in Monticello is, but modifies a different package there (so you cannot see the "switch" in the ancestry).<br>
> <br>
> So the one-nonlinear-branch-per-package approach is unwieldy, but at least it is does not produce incorrect results until someone comes up with a better solution. As written above, the git-migration approach is fine for one-person or branch-less projects.<br>
> <br>
> Am So., 3. März 2019 um 09:23 Uhr schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
>  <br>
> <br>
> <br>
> Le dim. 24 févr. 2019 à 21:19, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br>
> Hi Doru,<br>
> <br>
> Le mar. 19 févr. 2019 à 10:39, Tudor Girba <<a href="mailto:tudor@tudorgirba.com" target="_blank">tudor@tudorgirba.com</a>> a écrit :<br>
>  <br>
> Hi Nicolas,<br>
> <br>
> <br>
> > On Feb 18, 2019, at 3:12 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> <br>
> > Also note that vmmaker history as proposed in opensmalltalk pr was broken (no respect of branch topology). Maybe retry with Squot? <br>
> > <a href="https://github.com/hpi-swa/Squot" rel="noreferrer" target="_blank">https://github.com/hpi-swa/Squot</a><br>
> > There is still a problem of synching commits of other packages (cog, various plugins ...), and if nobody is working on it, we are condemned to a mediocre solution.<br>
> > IMO, a broken history has not much interest.<br>
> <br>
> We know it was broken, and thank you for pointing it out. We went through multiple iterations, and we think the latest one should be better. Please take a look and let us know if you still find issues:<br>
> <a href="https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker" rel="noreferrer" target="_blank">https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker</a><br>
> <br>
> <br>
> Ah OK, I'll try to have a look.<br>
> <br>
> <br>
> Hi Doru,<br>
> as follow up, I don't see the progress in package history.<br>
> If I look for example at history of ThreadedFFIPlugin, then I see this:<br>
> <br>
> <a href="https://github.com/feenkcom/opensmalltalk-vm/commit/2ec3b0f6da1a5c7801f7ce8973213ba00b10d7fd#diff-36ccd126e0dd4f5ba2a399c962426080" rel="noreferrer" target="_blank">https://github.com/feenkcom/opensmalltalk-vm/commit/2ec3b0f6da1a5c7801f7ce8973213ba00b10d7fd#diff-36ccd126e0dd4f5ba2a399c962426080</a><br>
> <br>
> Normally I should see only one diff, like this:<br>
> <br>
> <a href="http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2109.diff" rel="noreferrer" target="_blank">http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2109.diff</a><br>
> <br>
> This is because true parent is VMMaker.oscog-eem.2108<br>
> But git parent is VMMaker.oscog-eem.2109<br>
> So it seems like I am undoing all the changes from Eliot... Thats is obscuring the intentions of the commit.<br>
> <br>
<br>
--<br>
<a href="http://www.feenk.com" rel="noreferrer" target="_blank">www.feenk.com</a><br>
<br>
"What we can governs what we wish."<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>