2015-07-08 15:15 GMT+02:00 Alexandre Bergel <alexandre.ber...@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 <o...@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.ber...@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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Reply via email to