Petr Rockai writes: > "Stephen J. Turnbull" <step...@xemacs.org> writes: > > > Indeed. A standard hunk darcs-patch can be expressed efficiently > > (enough, in smallish repos) as a pair of git-tree objects. > > Unfortunately, this is not completely true. This only works as long > as you freeze the diffing algorithm.
Why do you need to freeze the diffing algorithm? Each instance of darcs uses the diffing algorithm it uses. Where's the problem? It's only a problem if you are passing around diffs themselves; the point is that you're not. > > However, for doing darcsy stuff, you'd really want the patches > > themselves. Interestingly enough, in a packed format repo, > > *most* versions are represented as patches IIUC. > > As binary deltas. But these are unrelated to actual history. It is > just a compression heuristic. So what? This is just a source of hunks. And of course they're related to actual history: they'd be useless without an index saying "to build tree 281 from tree 267, use hunks A, B, ... Z." You get the tree IDs from the commits you're working with. Agreed, you may have issues here wrt to the differ, but it's not clear to me that they're as subtle as you say. Of course you'd need to convert to darcs internal format, but patch(1) seems to do fine with multiple, very different formats. In debug versions, of course you'd build in a sledgehammer check: every patch "efficiently" extracted from a pack would be compared with the darcs diff based on the actual trees constructed from the git repo. _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
