On 01 Dec 2014, at 21:48, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 01/12/2014 21:04, Esteban Lorenzano a écrit :
On 01 Dec 2014, at 20:25, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
he was, donât worry :)
Maybe I was :)
and as an aswer: yes, Iâm not happy with filetree format, but I wouldnât spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement)
When I considered libgit2 a while ago, I was like you: a must. Then I saw that: libgit2 was low-level => lot's of code in Pharo do do simple, basic stuff. libgit2 required changes in NativeBoost => what, NativeBoost isn't ready? Pharo is stuck in 32bits land=>No libgit2 by default on target OS. NativeBoost is x86 only? No libgit2 on ARM.
Iâm also concerned about that (32bits only). But we are already working on a solution. (and libgit2 support is already there, thanks to Max). as I said⦠our problem (not yours, but ours) is that we need to keep pharo independent of installed tools. So⦠libgit2. Otherwise I would be pushing gitfiletree a lot more loud :) Esteban
In short: I don't have the resources to do that. It's too expensive for the benefits. I'm impressed by Max and your dedication.
but⦠in the not so far future the metadata *needs* to change, Iâm sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that⦠even with mergetools from Thierry, is too complicated).
The way you say it, I wonder if you understand what the MergeDriver is supposed to solve (and what it isn't). You'll have to say more ;)
(especially the bit about the merge of large projects/multiple developers being too complicated...)
Thierry
Esteban