<div dir="auto">Hi Tudor,<div dir="auto">It depends good enough for what?</div><div dir="auto">If i'm the author of a change that happens to be a mistake, then i want to be able to exert my responsibility.</div><div dir="auto">But i must first understand the context in which i took sone decisions, and a broken history won't help.</div><div dir="auto">Also linear history is breaking authorship, so maybe i won't even blame myself... example:</div><div dir="auto"><br></div><div dir="auto">Vm.branch1-eem.10 change method a</div><div dir="auto">Vm.branch2-nice.10 change method b</div><div dir="auto">Vm.merge.eem.11 => i'm the author of b changes</div><div dir="auto"><br></div><div dir="auto">But</div><div dir="auto"><br></div><div dir="auto"><div dir="auto" style="font-family:sans-serif">Vm.branch1-eem.10 change method a</div><div dir="auto" style="font-family:sans-serif">Vm.branch2-nice.10 change method b</div><div dir="auto" style="font-family:sans-serif">Vm.branch1-eem.11 change method c</div><div dir="auto" style="font-family:sans-serif">Vm.merge.eem.12 => Eliot is attributed the authorship of b changes</div><div dir="auto" style="font-family:sans-serif"><br></div><div dir="auto" style="font-family:sans-serif">That often happens with my own changes because Eliot is continuously developing. So from my POV, it's not good enough... just unusable.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 4 mars 2019 à 15:23, Tudor Girba <<a href="mailto:tudor@tudorgirba.com" target="_blank" rel="noreferrer">tudor@tudorgirba.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Hi,<br>
<br>
Thanks for this summary!<br>
<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>
<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>
<br>
Cheers,<br>
Doru<br>
<br>
<br>
> On Mar 4, 2019, at 8:42 AM, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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 noreferrer 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 noreferrer 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 noreferrer 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 noreferrer 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 noreferrer noreferrer" target="_blank">www.feenk.com</a><br>
<br>
"What we can governs what we wish."<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>