Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
On 01 Dec 2014, at 19:11, Eliot Miranda <[email protected]
<mailto:[email protected]>> wrote:
Hi Dale,
On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs
<[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> wrote:
Hi Dale,
On Nov 30, 2014, at 8:14 AM, Dale Henrichs
<[email protected]
<mailto:[email protected]>> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios
<[email protected] <mailto:[email protected]>> 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
