First, I'd like to apologize for the tone of my previous post, I'm just getting out of a seriously frustrating period (grading finals and assigning grades). I should (a) get some sleep and (b) do something productive myself before commenting on anybody else's work. Thanks to Eric for his temperate response.
Eric Y. Kow writes: > > You don't. This is a serious bug in Darcs with the backward- > > compatible repo formats (--old-inventory-format and --hashed). (It's > > new to me, and I don't know if it's an old but unknown bug or a > > regression.) > > I may be mistaken when I say this, but I reckon this sort of thing > is a UI issue and not a patch-theory one (if this is of any > consolation). Well, I do think this is a patch-theoretic issue. The question is the one that's often referred to as the "container issue". If a file is considered a container with an identity separate from its contents (which is effectively what Darcs does via the file-add patch), then we have conflicting adds. I can think of a number of ways to represent this, but none of them include leaving an unchanged file there. I have to think that there's a breakdown in application of patch theory if a file that is identical to one of the version to be merged is left behind. One possibility (adopted by git in a difference context) is to provide three files, which could be named file.merged, file.ours, and file.pulled. The rationale would be that since file names usually indicate the purpose of the file, it's likely that the two files have similar intended semantics and "mix 'n' match" is the appropriate way to merge them. However sometimes that might not be true (eg, some projects use README for installation instructions, others for licensing), so having the other two versions would be a convenience. A second possibility, used by the Coda file system, is to replace the file by a directory of the same name, containing files named "merged", "ours", and "pulled". In the two cases above a UI that provides simple ways to rename one or both files, as well as editing one or more, then "collapsing" them into the original form would be nice. A third possibility would be to decide that the container, being abstract, already "exists" (in the same way that in algebraic geometry all the points in the X-Y plane already exist) and adding the name to inventory is simply bookkeeping (like plotting a point); the file-add patch is idempotent and multiple adds of the same file are not conflicts. Then we'd have a simple hunk conflict. It would be pretty clear that this is actually an add/add conflict, since you'd have two hunks that each contain an entire file and no common text. This third interpretation would mean that if you add an empty file in either branch, no conflict would occur in that file at merge. I don't know if this is a good thing or a bad thing (except if both versions are empty, when it's definitely good). On the other hand this seems to be effectively what Darcs-2 does. > Do you think it would be feasible for conflicting adds to be marked up > sensibly? I.e. in the working directory, one of the adds happens (seems > easy), and both hunks get thrown in on top (maybe not so easy?) I don't see why this would be hard. > Or maybe you'd prefer just leaving it as it is since the darcs-2 format > fixes it? As Curt points out, in the status quo the pulled content isn't available (except buried in the merger patch). That's probably not a great idea. Also, I think it would be a good idea for David to pronounce what the appropriate interpretation of a file add patch is, and have all formats in use (try to) conform to that. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
