Thanks Peter, I will have a look… Alexandre

On Jul 8, 2015, at 12:31 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:

Hi Alex,

I've been troubled by this some time ago, so Thierry and Dale gave me exhaustive explanation here http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html

As for merging via git, there is also mentioned MergeDriver that's very easy to use and should be able to resolve most problems.

Peter

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Hi!

Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 08 Jul 2015, at 12:46, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:

Yurij post also an explanation recently here: http://code.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht...

That link does not seem to work ...

On Wed, Jul 8, 2015 at 12:31 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:

...

Hi Alex,

I've been troubled by this some time ago, so Thierry and Dale gave me exhaustive explanation here http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html

As for merging via git, there is also mentioned MergeDriver that's very easy to use and should be able to resolve most problems.

Peter

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:

...

Hi!

Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

This is frustrating…. I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver And I got: ~/HackathonSattose2015> git merge master pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory fatal: Failed to execute internal merge Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing…. Maybe I will go back to Smalltalkhub afterall… Alexandre

On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto@finworks.biz> wrote:

We have a .gitignore file that contains: version methodProperties.json

So, we don't bother.

The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory.

We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree.

So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more.

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:

...

Hi!

Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Our “coding” atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class.

That I understand.

Now… you are complaining in the wrong problem.

Well… Having one file per method seems to be very problematic after all.

FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. That’s what is plain wrong and should be at least optional :)

I would happily integrate a “PlainFileTree” protocol (without monticello information) as an option, if someone provides such extension. Crap, I could make it myself if I have the time!… maybe next insomnia night :P

We can work on this next week. I am fed up to hear “why you guys are not using github?" Alexandre

...

On 08 Jul 2015, at 14:51, Alexandre Bergel <alexandre.bergel@me.com> wrote:

This is frustrating….

I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver And I got:

~/HackathonSattose2015> git merge master pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory fatal: Failed to execute internal merge

Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing….

Maybe I will go back to Smalltalkhub afterall…

Alexandre

...

On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto@finworks.biz> wrote:

We have a .gitignore file that contains: version methodProperties.json

So, we don't bother.

The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory.

We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree.

So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more.

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:

...

Hi!

Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 08 Jul 2015, at 15:19, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-08 15:11 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>:

...

Our “coding” atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class.

That I understand.

...

Now… you are complaining in the wrong problem.

Well… Having one file per method seems to be very problematic after all.

It's not ;)

...

FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. That’s what is plain wrong and should be at least optional :)

I would happily integrate a “PlainFileTree” protocol (without monticello information) as an option, if someone provides such extension. Crap, I could make it myself if I have the time!… maybe next insomnia night :P

We can work on this next week. I am fed up to hear “why you guys are not using github?"

It's extremely easy to do.

Most of the code is ready for it.

But since there is no real push to get Pharo under git for now, I've left it as it is. In part because some are using FileTree directly and they need that compatibility level.

you’re wrong :) I feel the pain each time I need to provide a “we are not ready yet”. As I said… real reason we are not ready is because we are still trying to mix to words, in ways no one actually needs. So please… push! Esteban ps: and btw… there is no reason why we cannot keep “mc-file-tree” along with a “plain-file-tree” both alive. As I said… I just can image very few cases when we *actually* need that compatibility.

Thierry

2015-07-08 14:51 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:

This is frustrating….

I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver And I got:

~/HackathonSattose2015> git merge master pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory fatal: Failed to execute internal merge

Looks like a problem when installing the merge driver. pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of $ git config --get merge.mcVersion.driver

Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing….

FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo.

Maybe I will go back to Smalltalkhub afterall…

Up to you ;) Thierry

Alexandre

...

On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto@finworks.biz> wrote:

We have a .gitignore file that contains: version methodProperties.json

So, we don't bother.

The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory.

We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree.

So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more.

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:

...

Hi!

Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Thierry,

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Thanks Thierry. Seems to work. But I get this error: ~/HackathonSattose2015> git merge master readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file …] Any idea? Alexandre

On Jul 8, 2015, at 3:31 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-08 15:24 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Thierry,

...

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected?

No.

If you have your path for the merge command (something like /User/Alexandre/GitFileTree-MergeDriver/merge ), then it should be:

~/HackathonSattose2015> git config --get merge.mcVersion.driver /User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B

To correct it, what you can do by hand is:

git config --global merge.mcVersion.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B" git config --global merge.mcMethodProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --methodProperties %O %A %B" git config --global merge.mcProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --properties %O %A %B"

Don't forget to update the path !

Thierry

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Ok, thanks! Alexandre

On Jul 8, 2015, at 11:39 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Le 08/07/2015 23:25, Alexandre Bergel a écrit :

...

Thanks Thierry. Seems to work. But I get this error:

~/HackathonSattose2015> git merge master readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file …]

Can you edit the merge file (~/Dropbox/Workspace/GitFileTree-MergeDriver/merge) and change that line:

DIR=`readlink -e "$0"` || DIR="$0";

to:

DIR=`readlink "$0"` || DIR="$0";

(I would have expected this to work as well on a mac... but it isn't the case :(:( The -e option is there to try to see through symlinks. I'll correct that.)

Thierry

...

Any idea?

Alexandre

...

On Jul 8, 2015, at 3:31 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-08 15:24 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Thierry,

...

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected?

No.

If you have your path for the merge command (something like /User/Alexandre/GitFileTree-MergeDriver/merge ), then it should be:

~/HackathonSattose2015> git config --get merge.mcVersion.driver /User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B

To correct it, what you can do by hand is:

git config --global merge.mcVersion.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B" git config --global merge.mcMethodProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --methodProperties %O %A %B" git config --global merge.mcProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --properties %O %A %B"

Don't forget to update the path !

Thierry

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

I tried: ~/HackathonSattose2015> readlink --help readlink: illegal option -- - usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -help readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -? readlink: illegal option -- ? usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -h readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink ~/HackathonSattose2015>

On Jul 9, 2015, at 10:34 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Alexandre, if you had the time, could you give me the output of

readlink --help

on your computer?

Thanks,

Thierry

2015-07-09 9:44 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Ok, thanks!

Alexandre

...

On Jul 8, 2015, at 11:39 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Le 08/07/2015 23:25, Alexandre Bergel a écrit :

...

Thanks Thierry. Seems to work. But I get this error:

~/HackathonSattose2015> git merge master readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file …]

Can you edit the merge file (~/Dropbox/Workspace/GitFileTree-MergeDriver/merge) and change that line:

DIR=`readlink -e "$0"` || DIR="$0";

to:

DIR=`readlink "$0"` || DIR="$0";

(I would have expected this to work as well on a mac... but it isn't the case :(:( The -e option is there to try to see through symlinks. I'll correct that.)

Thierry

...

Any idea?

Alexandre

...

On Jul 8, 2015, at 3:31 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-08 15:24 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Thierry,

...

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected?

No.

If you have your path for the merge command (something like /User/Alexandre/GitFileTree-MergeDriver/merge ), then it should be:

~/HackathonSattose2015> git config --get merge.mcVersion.driver /User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B

To correct it, what you can do by hand is:

git config --global merge.mcVersion.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B" git config --global merge.mcMethodProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --methodProperties %O %A %B" git config --global merge.mcProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --properties %O %A %B"

Don't forget to update the path !

Thierry

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Ok, thanks! Alexandre

On Jul 9, 2015, at 1:46 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-09 13:41 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: I tried:

~/HackathonSattose2015> readlink --help readlink: illegal option -- - usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -help readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -? readlink: illegal option -- ? usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -h readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink ~/HackathonSattose2015>

Thanks, this helps!

I have updated the merge driver with a corrected merge script, which should work for you if you want to update.

Thierry

...

On Jul 9, 2015, at 10:34 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Alexandre, if you had the time, could you give me the output of

readlink --help

on your computer?

Thanks,

Thierry

2015-07-09 9:44 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Ok, thanks!

Alexandre

...

On Jul 8, 2015, at 11:39 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Le 08/07/2015 23:25, Alexandre Bergel a écrit :

...

Thanks Thierry. Seems to work. But I get this error:

~/HackathonSattose2015> git merge master readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file …]

Can you edit the merge file (~/Dropbox/Workspace/GitFileTree-MergeDriver/merge) and change that line:

DIR=`readlink -e "$0"` || DIR="$0";

to:

DIR=`readlink "$0"` || DIR="$0";

(I would have expected this to work as well on a mac... but it isn't the case :(:( The -e option is there to try to see through symlinks. I'll correct that.)

Thierry

...

Any idea?

Alexandre

...

On Jul 8, 2015, at 3:31 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-08 15:24 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Thierry,

...

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected?

No.

If you have your path for the merge command (something like /User/Alexandre/GitFileTree-MergeDriver/merge ), then it should be:

~/HackathonSattose2015> git config --get merge.mcVersion.driver /User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B

To correct it, what you can do by hand is:

git config --global merge.mcVersion.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B" git config --global merge.mcMethodProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --methodProperties %O %A %B" git config --global merge.mcProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --properties %O %A %B"

Don't forget to update the path !

Thierry

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Thanks. I believe there are no options of stat or readlink that are the same between linux and mac os X :( I like Unix portability ;) Thierry 2015-07-09 14:29 GMT+02:00 Christophe Demarey <Christophe.Demarey@inria.fr>:

The man page lists available options on OS X:

STAT(1) BSD General Commands Manual STAT(1)

NAME readlink, stat -- display file status

SYNOPSIS stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...] readlink [-n] [file ...]

DESCRIPTION The stat utility displays information about the file pointed to by file. Read, write or execute permissions of the named file are not required, but all directories listed in the path name leading to the file must be searchable. If no argument is given, stat displays information about the file descriptor for standard input.

When invoked as readlink, only the target of the symbolic link is printed. If the given argument is not a symbolic link, readlink will print nothing and exit with an error.

The information displayed is obtained by calling lstat(2) with the given argument and evaluating the returned structure.

The options are as follows:

-F As in ls(1), display a slash (`/') immediately after each path- name that is a directory, an asterisk (`*') after each that is executable, an at sign (`@') after each symbolic link, a percent sign (`%') after each whiteout, an equal sign (`=') after each socket, and a vertical bar (`|') after each that is a FIFO. The use of -F implies -l.

-f format Display information using the specified format. See the FORMATS section for a description of valid formats.

-L Use stat(2) instead of lstat(2). The information reported by stat will refer to the target of file, if file is a symbolic link, and not to file itself.

-l Display output in ls -lT format.

-n Do not force a newline to appear at the end of each piece of out- put.

-q Suppress failure messages if calls to stat(2) or lstat(2) fail. When run as readlink, error messages are automatically sup- pressed.

-r Display raw information. That is, for all the fields in the stat structure, display the raw, numerical value (for example, times in seconds since the epoch, etc.).

-s Display information in ``shell output'', suitable for initializ- ing variables.

-t timefmt Display timestamps using the specified format. This format is passed directly to strftime(3).

-x Display information in a more verbose way as known from some Linux distributions.

Le 9 juil. 2015 à 13:46, Thierry Goubier a écrit :

2015-07-09 13:41 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:

...

I tried:

~/HackathonSattose2015> readlink --help readlink: illegal option -- - usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -help readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -? readlink: illegal option -- ? usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -h readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink ~/HackathonSattose2015>

Thanks, this helps!

I have updated the merge driver with a corrected merge script, which should work for you if you want to update.

Thierry

...

...

On Jul 9, 2015, at 10:34 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Alexandre, if you had the time, could you give me the output of

readlink --help

on your computer?

Thanks,

Thierry

2015-07-09 9:44 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Ok, thanks!

Alexandre

...

On Jul 8, 2015, at 11:39 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Le 08/07/2015 23:25, Alexandre Bergel a écrit :

...

Thanks Thierry. Seems to work. But I get this error:

~/HackathonSattose2015> git merge master readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file …]

Can you edit the merge file (~/Dropbox/Workspace/GitFileTree-MergeDriver/merge) and change that line:

DIR=`readlink -e "$0"` || DIR="$0";

to:

DIR=`readlink "$0"` || DIR="$0";

(I would have expected this to work as well on a mac... but it isn't the case :(:( The -e option is there to try to see through symlinks. I'll correct that.)

Thierry

...

Any idea?

Alexandre

...

On Jul 8, 2015, at 3:31 PM, Thierry Goubier <

thierry.goubier@gmail.com> wrote:

...

...

2015-07-08 15:24 GMT+02:00 Alexandre Bergel <

alexandre.bergel@me.com>:

...

Thierry,

...

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected?

No.

If you have your path for the merge command (something like /User/Alexandre/GitFileTree-MergeDriver/merge ), then it should be:

~/HackathonSattose2015> git config --get merge.mcVersion.driver /User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B

To correct it, what you can do by hand is:

git config --global merge.mcVersion.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B" git config --global merge.mcMethodProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --methodProperties %O %A %B" git config --global merge.mcProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --properties %O %A %B"

Don't forget to update the path !

Thierry

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2015-07-09 15:36 GMT+02:00 Norbert Hartl <norbert@hartl.name>:

Am 09.07.2015 um 15:27 schrieb Thierry Goubier <thierry.goubier@gmail.com

...

:

Thanks.

I believe there are no options of stat or readlink that are the same between linux and mac os X :(

I like Unix portability ;)

You mean POSIX? ;)

Who said: what is nice with standards is that there are so many to choose from? ;) Thierry

Norbert

2015-07-09 14:29 GMT+02:00 Christophe Demarey <Christophe.Demarey@inria.fr

...

:

...

The man page lists available options on OS X:

STAT(1) BSD General Commands Manual STAT(1)

NAME readlink, stat -- display file status

SYNOPSIS stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...] readlink [-n] [file ...]

DESCRIPTION The stat utility displays information about the file pointed to by file. Read, write or execute permissions of the named file are not required, but all directories listed in the path name leading to the file must be searchable. If no argument is given, stat displays information about the file descriptor for standard input.

When invoked as readlink, only the target of the symbolic link is printed. If the given argument is not a symbolic link, readlink will print nothing and exit with an error.

The information displayed is obtained by calling lstat(2) with the given argument and evaluating the returned structure.

The options are as follows:

-F As in ls(1), display a slash (`/') immediately after each path- name that is a directory, an asterisk (`*') after each that is executable, an at sign (`@') after each symbolic link, a percent sign (`%') after each whiteout, an equal sign (`=') after each socket, and a vertical bar (`|') after each that is a FIFO. The use of -F implies -l.

-f format Display information using the specified format. See the FORMATS section for a description of valid formats.

-L Use stat(2) instead of lstat(2). The information reported by stat will refer to the target of file, if file is a symbolic link, and not to file itself.

-l Display output in ls -lT format.

-n Do not force a newline to appear at the end of each piece of out- put.

-q Suppress failure messages if calls to stat(2) or lstat(2) fail. When run as readlink, error messages are automatically sup- pressed.

-r Display raw information. That is, for all the fields in the stat structure, display the raw, numerical value (for example, times in seconds since the epoch, etc.).

-s Display information in ``shell output'', suitable for initializ- ing variables.

-t timefmt Display timestamps using the specified format. This format is passed directly to strftime(3).

-x Display information in a more verbose way as known from some Linux distributions.

Le 9 juil. 2015 à 13:46, Thierry Goubier a écrit :

2015-07-09 13:41 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:

...

I tried:

~/HackathonSattose2015> readlink --help readlink: illegal option -- - usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -help readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -? readlink: illegal option -- ? usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink -h readlink: illegal option -- h usage: readlink [-n] [file ...] ~/HackathonSattose2015> readlink ~/HackathonSattose2015>

Thanks, this helps!

I have updated the merge driver with a corrected merge script, which should work for you if you want to update.

Thierry

...

...

On Jul 9, 2015, at 10:34 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Alexandre, if you had the time, could you give me the output of

readlink --help

on your computer?

Thanks,

Thierry

2015-07-09 9:44 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Ok, thanks!

Alexandre

...

On Jul 8, 2015, at 11:39 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Le 08/07/2015 23:25, Alexandre Bergel a écrit :

...

Thanks Thierry. Seems to work. But I get this error:

~/HackathonSattose2015> git merge master readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file ...] readlink: illegal option -- e usage: readlink [-n] [file …]

Can you edit the merge file (~/Dropbox/Workspace/GitFileTree-MergeDriver/merge) and change that line:

DIR=`readlink -e "$0"` || DIR="$0";

to:

DIR=`readlink "$0"` || DIR="$0";

(I would have expected this to work as well on a mac... but it isn't the case :(:( The -e option is there to try to see through symlinks. I'll correct that.)

Thierry

...

Any idea?

Alexandre

...

On Jul 8, 2015, at 3:31 PM, Thierry Goubier <

thierry.goubier@gmail.com> wrote:

...

...

2015-07-08 15:24 GMT+02:00 Alexandre Bergel <

alexandre.bergel@me.com>:

...

Thierry,

...

...

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Any idea how I can merge then? Is this value what you expected?

No.

If you have your path for the merge command (something like /User/Alexandre/GitFileTree-MergeDriver/merge ), then it should be:

~/HackathonSattose2015> git config --get merge.mcVersion.driver /User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B

To correct it, what you can do by hand is:

git config --global merge.mcVersion.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --version %O %A %B" git config --global merge.mcMethodProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --methodProperties %O %A %B" git config --global merge.mcProperties.driver "/User/Alexandre/GitFileTree-MergeDriver/merge --properties %O %A %B"

Don't forget to update the path !

Thierry

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2015-07-08 15:15 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:

...

Looks like a problem when installing the merge driver.

pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of

$ git config --get merge.mcVersion.driver

~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B

Then this means the make in GitFileTree-MergeDriver hasn't worked. When you did the make, what was the output?

...

Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing….

FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo.

Okay, but we all agree this is very far from an ideal solution right?

No, I disagree. I have been using it in production for the past 4 years, under conditions and constraints that Smalltalkhub and mcz can't handle (and never will).

Also, if I understand correctly, at each new repository I need to create a file .gitattributes :

*.package/monticello.meta/version merge=mcVersion *.package/*.class/methodProperties.json merge=mcMethodProperties *.package/*.class/properties.json merge=mcProperties *.package/*.extension/methodProperties.json merge=mcMethodProperties *.package/*.extension/properties.json merge=mcProperties

Yes, only once. As you will setup also a .gitignore. You'll notice that some of the github hosted Pharo repositories already have that file set. Regards, Thierry

Alexandre

...

...

On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto@finworks.biz> wrote:

We have a .gitignore file that contains: version methodProperties.json

So, we don't bother.

The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory.

We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree.

So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more.

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:

...

Hi!

Do I still need to press the merge button in Monticello when I am

working on a filtree git repository?

...

...

...

I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2015-07-08 15:31 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:

...

Then this means the make in GitFileTree-MergeDriver hasn't worked. When you did the make, what was the output?

It is:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ~/Dropbox/Workspace/GitFileTree-MergeDriver> make mkdir pharo cd pharo; wget -O- get.pharo.org/30+vm | bash --2015-07-08 14:20:12-- http://get.pharo.org/30+vm Resolving get.pharo.org... 128.93.162.72 Connecting to get.pharo.org|128.93.162.72|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2901 (2.8K) [text/html] Saving to: 'STDOUT'

- 100%[=====================>] 2.83K --.-KB/s in 0s

2015-07-08 14:20:12 (146 MB/s) - written to stdout [2901/2901]

Downloading the latest 30 Image: http://files.pharo.org/get-files/30/pharo.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/get-files/30/pharo-mac-stable.zip pharo-vm/Pharo.app/Contents/MacOS/Pharo Downloading PharoV30.sources: http://files.pharo.org/get-files/30/sources.zip Creating starter scripts pharo and pharo-ui pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Gofer new url: \'http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/\'\; package: \'GitFileTree-MergeDriver\'\; load a GoferLoad git config --global merge.mcVersion.driver "`pwd`/merge --version %O %A %B" git config --global merge.mcMethodProperties.name "GitFileTree MergeDriver for Monticello" git config --global merge.mcMethodProperties.driver "`pwd`/merge --methodProperties %O %A %B" git config --global merge.mcProperties.name "GitFileTree MergeDriver for Monticello" git config --global merge.mcProperties.driver "`pwd`/merge --properties %O %A %B" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

And after that, what is your git config --get merge.mcVersion.driver ?

Please help :-)

I'm on it :) Thierry

Alexandre

Most of our problems here is because we insist on being interchangeable between git and mcz. While treating git as “just another repository” can feel appealable in certain cases (for example, in the super-uncommon way of handle vm building we have, when we use git and Eliot uses squeak source, then we are kind of a mirror), this is not the most common usage: if you start a project on git, you are expected other contributors use git too… same as in any other SVC tool (there is not compatibility between SVN, HG, GIT, etc.) Of course, it looked like a good idea at the beginning, but now I think is counterproductive (is the kind of ideas that are great at the beginning because it provides security/confortability to users, but with time demonstrate obsolete). What we actually need is tools that can load configurations from different sources (for example, I have a project in git who uses seaside and I want a configuration who loads both…). But… guess what? WE ALREADY HAVE IT!!!! Metacello is perfectly capable of doing that. Gofer is capable of doing that. Heck, even monticello is capable of doing that as long as we do not pretend their are interchangeable! So, again… what we actually need is to accept reality: we do not need all that metadata in 99% of cases! Esteban

On 08 Jul 2015, at 15:07, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2015-07-08 14:51 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>: This is frustrating….

I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver <https://github.com/ThierryGoubier/GitFileTree-MergeDriver> And I got:

~/HackathonSattose2015> git merge master pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory fatal: Failed to execute internal merge

Looks like a problem when installing the merge driver.

pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of

$ git config --get merge.mcVersion.driver

Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing….

FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo.

Maybe I will go back to Smalltalkhub afterall…

Up to you ;)

Thierry

Alexandre

...

On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto@finworks.biz <mailto:otto@finworks.biz>> wrote:

We have a .gitignore file that contains: version methodProperties.json

So, we don't bother.

The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory.

We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree.

So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more.

On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:

...

Hi!

Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello.

I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:

CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json

Why do we need this methodProperties.json and version files? Shouldn’t git handle this?

How should I merge these files? Any experience?

Cheers, Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 08-07-15 14:51, Alexandre Bergel wrote:

This is frustrating….

Maybe I will go back to Smalltalkhub afterall…

Git support is still bleeding edge. Why did you want to move away from smalltalkhub before we have libgit2 integrated? Stephan

Hi Otto, 2015-07-08 14:21 GMT+02:00 Otto Behrens <otto@finworks.biz>:

We have a .gitignore file that contains: version methodProperties.json

This is a bit drastic :)

So, we don't bother.

The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory.

GitFileTree only derives the UUID from the SHA1 of the .package directory. It derives the version number from the number of versions in the git commit history.

We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree.

This is what GitFileTree does, with a crafted command for git log ;). I'm interested in the "performance" issue reading versions from the git history you mention above. If you had the time to try with just installing GitFileTree and opening the repository, and checking: if it is slow, and if it gives you the right history.

So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more.

This is one way to do it ;) Thierry