First, a quick status report: My Ruby darcs-compatible tool (yarcs) can
now perform a "check" against the official darcs repo, up through
0.9.10. It starts with an empty tree, applies all those patches, and
produces exactly the same tree as what is in _darcs/current as of 0.9.10.
Current speed is about half that of darcs, even though it's in an
interpreted language, and I haven't done any speed optimizations yet.
I'm happy with that for now.
The situation I'm currently trying to handle:
After the 0.9.10 tag, darcs included its first 'merger' patch, in the
patch file that begins "Place_1etc_under" (note that's a 1, not an l,
since the patch label was "Place /etc under"). I'm trying to figure out
how to apply this merger patch to the tree. The merger itself is pretty
small:
merger 0.9 (
hunk ./Makefile 38
- install -m 0644 cgi.conf /etc/darcs/cgi.conf
+ test -e $(DESTDIR)/etc/darcs/cgi.conf || \
+ install -m 0644 cgi.conf $(DESTDIR)/etc/darcs/cgi.conf
hunk ./Makefile 37
- install -d $(DESTDIR)/etc/darcs
- install -m 0644 cgi.conf /etc/darcs/cgi.conf
+ install -d $(DESTDIR)/$(PREFIX)/etc/darcs
+ install -m 0644 cgi.conf $(DESTDIR)/$(PREFIX)/etc/darcs/cgi.conf
)
Looking at the code, I am supposed to invert p1 (because neither of the
merged patches are themselves mergers, so merger_undo is just to invert
p1), then glump p1 and p2. All of that is then run through
sort_coalesce_composite, which due to my poor haskell skills (and
currently tired brain) is hard to tell whether it sorts before or after
coalescing.
Oh, and I may have to invert this patch. I think that happens it's if
it's a 'regrem' patch instead of a 'merger' patch.
Now, the glump ("0.9") seems to call unravel, and if it returns an array
of patches we can just join them. But if it returns a 'pss' (?) we
either run it through mangle_unravelled_hunks (if it is only hunks), or
otherwise just join the head of pss. But I thought pss wasn't an array,
so this is confusing.
Since unravel itself is the "second most complicated algorithm" in
darcs, I'll save that for another day. But I would like to understand
the code I've described above, and if possible, start to understand the
"big picture" of applying a merger patch.
My questions:
1. Can you confirm where p1 and p2 came from, and what context they were
intended to be applied to before they got merged? I'm guessing that p1
was already in your tree when you tried to apply p2 that came from
somewhere else.
2. In this specific case, can you describe what would end up in lines
37-39 of the file? It looks like we would roll back the test -e line to
be install -m. Then, we would apply a mangled unravelled version of the
combination of p1 and p2. But there doesn't seem to be enough
information here to reconcile the $(PREFIX) change with the test -e change.
3. When would a 'regrem' patch be created?
4. Is the sort step necessary here, or could I just do a coalesce?
5. Would unravel here return an array, or a pss? What is a pss?
6. Is it possible to briefly summarize the algorithm used by
mangle_unravelled_hunks?
7. What does dbcp stand for?
Thanks much,
Kevin
|
