"Zack Weinberg" <[EMAIL PROTECTED]> writes: >> If you have a conflicted file in a roster, it is marked as conflicted >> in the status output. You get four copies of the file in your >> workspace: ancestor, left, right, and merged-with-conflict-markers >> (respectively: myfile.ancestor.<rev>, myfile.<revL>, myfile.<revR> and >> myfile). Once you've fixed the conflict, you run "mtn resolved" on >> the file. It then has its conflict status in the roster resolved and >> the three extra files in the workspace are removed. > > I would actually say it is easier to do it the other way around. > There are many different kinds of name conflicts, but for each of > them, I believe it's possible to recover roster sanity by tacking a > canned sequence of renames onto each change set involved. The > existing namespace manipulation commands can then be used to resolve > the conflicts. > > By contrast, file content conflicts require you to come up with > an entirely new mechanism for making the roster sane. We certainly > want all the files you listed to show up in the workspace, but which > of them get to be 'known' and which are just dumped there?
I would vote for ignoring the "extra" files, and listing the conflicted one as "known conflicted" in 'automate inventory' in nvm.basic_io.inventory (which needs to be merged with main soon). > Tangentially, I want conflict marker generation to be left to a lua > hook. Yes, with a default to the CVS style. > Roster means one of the data structures defined in roster.{cc,hh} and > stored in the 'rosters' and 'roster_deltas' tables in the database. > There is one roster per revision, and its content is a structured list > of files in that revision, plus mark-merge metadata, as I understand > it. The 'revision' structure (revision.{cc,hh}; 'revisions' and > 'revision_ancestry' tables) is concerned with ancestry, not content. > > Manifests are older, and I believe now used only in the netsync > protocol; they did the same job as rosters, but did not carry all of > the same information. Ah. So in the info manual in general, we should talk about "rosters", not "manifests"? I just rewrote the section for 'automate inventory' in nvm.basic_io.inventory, using the term 'manifests'. > I would be very reluctant to put the conflict marker in the roster. > That data structure is complicated enough. I'd rather see a separate > serialization of the conflict list in the roster_merge_result, > indicating which changes to the workspace roster have been faked up to > remove conflicts. I'm not clear how that would interact with 'automate inventory'; that code gets all of it's information from rosters (I think). -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel