On 2/27/06, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > > Any good suggestions, then, on how to approach handling the ordering > > of patches without calling darcs every time? > > Use repository ordering, but make sure that you regenerate your > database every time somebody calls an unsafe darcs operation. > > Unsafe operations are optimize, repair, unpull and unrecord (am I > missing any?).
Right, that makes sense and it should be easy enough to run the marshalling posthook on any unsafe operations and/or disable them for such repositories (this is meant for repo-browsing like darcsweb, so having a defaults with the unsafe operations disabled would be a useful thing to have in this project's documentation/examples). Right now I'm building this in an onion-approach (low level to high level), and I've got the general patch view, which is generally date-ordered (because the dates are an inherent facet of the patch). This corresponds fine with the repos that I'm working with and for basic repositories (smallish ones with mostly logical patches) this appears fine. If I'm going to introduce repo-ordering its going to be at the next "level" in the abstraction onion, as I don't think it makes sense for a patch to know its repo order (particularly if the same patch table stores patches for multiple repositories). Now I'm just trying to debate what that next level should be and the best way to go about representing it in the database. The obvious next level up (in terms of a user's view) is the Tag (and then Repo/Branch has a collection of Tags, plus a repo-specific "Head" tag, plus a collection of Files (and then Project has a collection of Repos/Branches, etc)). The problem I'm coming to, however, is I'm trying to figure out how best to model Tags in the database. In particular, I'm having a hard time of figuring out how to get "idempotent" tag information from darcs (ie, if two repos have the same tag I shouldn't have to reverify that tag's patch/tag dependency order). For example, if I'm reading through ``darcs changes -s --xml-output`` and the patch's name, date, author, hash, invert match and existing patch in the database I can reasonably assume that the patch in the database is the same patch, and that I don't need to remarshal the patch summary (or even patch diff when I get around to that...). But, how do I get *the* patch dependency for a Tag? Naively, I could assume all of the patches "below" a Tag in the changes list, but its already been proven previously in the thread that that might not necessarily be the case. Also, I don't see any way to determine if a patch is a tag other than for regexing for "^TAG" in the change list. Basically, it seems that Tags are "second-class patches" to ``darcs changes``, which is great for abstraction (it is useful seeing the Tag patches in the Patch Log), but seems to be tough for seeking tag-specific information. Also, why doesn't the --xml-output <summary> tags have some sort of <tagged> change, like it has adds/modifies/removes? (This would be particularly useful should there come a day should darcs move to allowing Tags within larger logical patches, which I have seen debated previously.) Time for ``darcs query tags``? -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
