In working on my huge refactoring of Darcsweb, one of my goals is to get
as much useful information into the database as I can. I figure for
most cases an SQL query is going to be optimized faster than a darcs
call, not to mention it saves me from having to write something
resembling an SQL query interface for darcs or everywhere passing around
darcs parameters strings like Darcsweb (which isn't very good Object
abstraction/encapsulation).
Anyway, I realized I had some assumptions about Patch Ordering/Contexts,
but wasn't sure where I was getting them, and I wanted to insure that
they were indeed properties before relying on them:
In iterating through ``darcs changes``, can I assume everything earlier
than a Tag to be "frozen" and unlikely to change? What would be the
circumstances for such change? Can I assume upon reaching another
earlier tag that it is wholly included in the context of the later tag?
(I do realize that anything recent, following all tags, is subject to
heavy reordering.)
Should I attempt to default the patch ordering, just just displaying a
list of recent patches for instance, to the changes ordering? Is there
a strong enough argument for repo ordering versus, say, date ordering?
Here's why I ask:
I'm trying to come up with a good way to represent in the database repo
ordering and contexts, and right now my current thought is doing it
based on Tags, and assuming that Tag contexts shouldn't change. Then I
can just keep track of the "latest" tag in a repo and psuedo-tag-like
"repo trunk" context, to be updated with each ``darcs changes`` call
(which it looks like I may only ever have to call in a --posthook
script, which could be pretty cool).
--
--Max Battcher--
http://www.worldmaker.net/
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
