Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
On 01 Dec 2014, at 19:11, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Dale,
On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
Eliot,
If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ...
`adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ...
So *please* continue to be stubborn :-)
but this is a limitation of gitfiletree.
This is a limitation of FileTree, not GitFileTree.
real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata.
As GitFileTree has been doing without libgit2 for, how long already?
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
Esteban
My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:)
+1
Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ...
So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?)
exactly.
Which would be reasonable, but it needs to be there. And thanks.
Dale
On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Dale,
On Nov 30, 2014, at 8:14 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello?
Dale
-- best, Eliot