[Vm-dev] reorganizing opensmalltalk-vm

Ben Coman btc at openinworld.com
Mon Oct 29 00:15:53 UTC 2018


On Mon, 29 Oct 2018 at 03:52, tim Rowledge <tim at rowledge.org> wrote:

>
> > On 2018-10-28, at 12:37 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > The only thing I'd like to see in Tonel is per-method timestamps a la
> >
> [snip]
> >
> > but I know there is active opposition to this idea.
>
> Why on earth is there any opposition to what appears a perfectly
> reasonable idea? Within, of course, the context of an idea I find rather
> daft, that of trying to force Smalltalk source code into a model that seems
> completely at odds.
>

Active opposition seems a bit strong.  My understanding is that problematic
merge conflicts of such version info were difficult to work around.
Something similar to this...
[1] http://developers-club.com/posts/244839/

Here are some historical discussion of merge problems experienced in the
move to support git...
[3]
http://forum.world.st/metadata-less-FileTree-repository-support-part-I-td4906094.html

[4] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html

[5]
http://forum.world.st/git-and-author-timestamps-10000-s-of-files-etc-td5063124.html


At one point I thought I might do better and spent a fair it of time trying
to crack this.
I was experimenting by manually simulated the version info updates using a
text editor
and merging different branches, but it beat me.

However I just now bumped into a novel solution that I never considered
which doesn't require merge drivers and wonder how this approach
might influence the merge issues we found problematic
[2]
https://stackoverflow.com/questions/33122014/git-conflicts-with-json-files/33262179#33262179
See first answer "Oh, I actually tried this out and encountered some odd
problems."

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181029/069a6f73/attachment-0001.html>


More information about the Vm-dev mailing list