| Time |
S |
Nick |
Message |
| 01:25 |
|
lispy |
aFlag: afaik, no you don't have to do anything |
| 01:26 |
|
lispy |
aFlag: in a wost case scenario there maybe something with the _darcs/repoformat or some file like that, if you don't get errors using 1.0.8 then you're fine for now :) |
| 01:26 |
|
aFlag |
good :) |
| 01:26 |
|
lispy |
but for now darcs is backwards compatible (and i doubt that would change within the 1.x line) |
| 01:28 |
|
aFlag |
yeah, that's was what I was hoping :) |
| 01:32 |
|
lispy |
if the maintainers try that i will scream pretty loud. at a minimum I would request them to bump the second number... |
| 01:32 |
|
lispy |
(try breaking backwards compatibility i mean) |
| 01:35 |
|
kpreid_ |
probably silly question: darcs would work fine used for 'syncing' between three repositories in arbitrary combinations of directions of update, yes? |
| 01:35 |
|
lispy |
kpreid_: i don't pretend to understand patch theory, but i thought the brochure said that was okay to do |
| 01:36 |
|
lispy |
kpreid_: i find that in practice a star topology is easiest to remember/think about |
| 01:40 |
|
aFlag |
i didn't understand about anything on the last three lines :P |
| 01:46 |
|
lispy |
aFlag: imagine having 3 copies of a repository and pushing/pulling patches between them arbitrarily |
| 01:47 |
|
lispy |
aFlag: a star topology would mean that you have one repository that you always push to and each repository must get it's updates from there |
| 01:47 |
|
lispy |
s/it's/its |
| 01:48 |
|
kpreid_ |
at which point you might as well be using svn :) |
| 01:48 |
|
aFlag |
yeah, I always do the star thing |
| 01:49 |
|
aFlag |
I never tried to work with everyone actually having their own repository and pushing and pulling stuff around without any rules |
| 01:49 |
|
arjanb |
in darcs every order of merging should yield the same result so any topology is possible |
| 01:49 |
|
aFlag |
but again, I've only done really small projects for classes, so that was all I needed |
| 01:50 |
|
aFlag |
I see |
| 01:50 |
|
aFlag |
that's nice |
| 01:50 |
|
lispy |
kpreid_: not exactly |
| 01:51 |
|
lispy |
kpreid_: darcs still offers many benefits, for example, you can change which node is at the center of the star at any point |
| 01:52 |
|
aFlag |
I use darcs mainly because of it's simplicity |
| 01:53 |
|
aFlag |
I find it really easy to install and use |
| 01:53 |
|
aFlag |
so I use it everywhere |
| 01:53 |
|
lispy |
yeah |
| 01:53 |
|
kpreid_ |
lispy: ah, yes |
| 01:59 |
|
lispy |
cherry picking, the occasional disruption to the star topology without fear of breaking things, the nice user interface, darcs test, darcs trackdown and I'm sure i can think of others if you really want me to keep going :) |
| 02:09 |
|
aFlag |
yeah, I never used the darcs test feature |
| 02:09 |
|
aFlag |
it seems nice |
| 16:29 |
|
droundy |
Anyone here have experience with DAGs as data structures? |
| 16:29 |
|
arjanb |
hey david |
| 16:29 |
|
droundy |
Hi Arjan. Do *you* have an idea how to code a patch dependency DAG? |
| 16:30 |
|
arjanb |
i think DAGs aren't needed for storage |
| 16:30 |
|
droundy |
How'd you avoid them? |
| 16:30 |
|
arjanb |
i was confusing it with the DAGs that patch dependencies have |
| 16:31 |
|
droundy |
I see. But I still think that I'd want a DAG to hold resultions conflicting with resolutions (which in practice is common). |
| 16:32 |
|
droundy |
We need some way to store the set of conflicting patches, and I don't think a tree will work... or i don't see how it'll work. |
| 16:35 |
|
arjanb |
every repo without conflicts is a sequence, merging can yield a tree with the common part as root |
| 16:35 |
|
arjanb |
i don't see how you can create a conflict that isn't a tree |
| 16:36 |
|
droundy |
brb (got a phone call) |
| 16:38 |
|
eivuokko |
I am not knowledgeable ... conflicts create tree, but can't a patch create multiple conflicts, which needs DAG? |
| 16:40 |
|
arjanb |
no because everything can viewed as the result of repeatedly merging a bunch of repos without conflicts |
| 16:41 |
|
eivuokko |
Hmmm. |
| 16:43 |
|
eivuokko |
Ok, I'll take your word for it. I can't see that myself. I'll leave you experts to it, then :) |
| 16:45 |
|
arjanb |
and i think a resolution isn't a DAG but a tree with all but one dead ends |
| 16:45 |
|
arjanb |
brb meal |
| 16:45 |
|
eivuokko |
Bon apetit. |
| 16:46 |
|
idnar |
on a different note, I've sometimes thought (inspired by Mercurial) that it might be nice to have a single structure in which to store related repos as some kind of tree/DAG-like structure |
| 16:46 |
|
idnar |
("related" meaning they have a number of patches in common) |
| 16:51 |
|
droundy |
I'm back. (and thinking about DAGs again) |
| 16:52 |
|
droundy |
The question is how you view a conflict resolution. Your though (arjanb's) is that it results in a bunch of dead ends. My thought is that it ties all the threads of a tree together. |
| 16:53 |
|
droundy |
So a repo which had conflicts and is now resolved would be one that has a tree structure that comes together again, which is a DAG (albeit a trivial one). |
| 16:54 |
|
droundy |
And when you pull from multiple repos with resolved conflicts (and with conflicting resolutions) you get a possibly quite complex DAG as a result. |
| 16:56 |
|
droundy |
eivuokko: A patch could create multiple conflicts, but unless there's a resolution (which is the subject the debate between arjan and I), that should form a tree. I.e. multiple conflicts just means that there are multiple branches (possibly not a binary tree). |
| 16:59 |
|
droundy |
arjanb: (asking a question for after your meal) Are you thinking that a "dead end" is a special state for the branch of a tree, and distinguishing between "free ends" which are unresolved conflicts, and "dead ends" which are resolved conflicts? |
| 17:04 |
|
Heffalump |
ooh, a David |
| 17:04 |
|
Heffalump |
waves |
| 17:04 |
|
Heffalump |
LTNS :-) |
| 17:04 |
|
droundy |
Hi! :) Indeed, it's been a while! |
| 17:05 |
|
droundy |
Any chance you'll make the HW this year? |
| 17:05 |
|
Heffalump |
ooh, darcs-conflicts traffic |
| 17:05 |
|
Heffalump |
no :-( |
| 17:05 |
|
Heffalump |
can't really afford to go to Oregon. |
| 17:05 |
|
Heffalump |
has a wedding to pay for, for one thing ;-) |
| 17:05 |
|
droundy |
yeah, it's amazingly cheap for me... really? Congratulations! (assuming it's your wedding...) |
| 17:05 |
|
Heffalump |
indeed, thanks :-) |
| 17:06 |
|
Heffalump |
we got engaged a week ago. It's scary how much of my new fiancee's free time since then has been spent looking at wedding stuff. |
| 17:06 |
|
Heffalump |
have you got a job sorted now? |
| 17:07 |
|
droundy |
Wow, that's exciting. Yeah, at Oregon State University (which is why the HW is cheap for me--and why I'll be able to afford the time to attend.) |
| 17:09 |
|
Heffalump |
oh, cool |
| 17:09 |
|
Heffalump |
have you started already? |
| 17:09 |
|
droundy |
arjanb: I can see how the "dead ends" approach could be done, and suspect that it's the best approach. Then we don't need DAGs at all. |
| 17:10 |
|
droundy |
Heffalump: No, I start Sept 16 or so, classes start Sep 23 or something like that. |
| 17:10 |
|
Heffalump |
DAGs are very easy to store, AFAIK |
| 17:10 |
|
Heffalump |
the ATerm library is one that does it already |
| 17:10 |
|
droundy |
Really? Is ATerm a Haskell library? Also, how easy are they to reason about. I suspect that trees are better for us anyways. |
| 17:11 |
|
Heffalump |
it has a concept of maximal sharing, so if you have two identical DAGs you always get the same bit of memory |
| 17:11 |
|
Heffalump |
they're not as easy as trees to reason about |
| 17:11 |
|
Heffalump |
and no, ATerm is a C library (I think). But it's written by some program transformation people. |
| 17:11 |
|
Heffalump |
I was just thinking that the ideas behind its design were worth looking at. |
| 17:11 |
|
droundy |
That's my concern, since we'll be having to merge these things and do commutation on them and other scary stuff. Trees are dead easy. |
| 17:12 |
|
Heffalump |
Although its web page talks just about trees, so I'm a little confused now. |
| 17:12 |
|
Heffalump |
I've briefly skimmed the new traffic on the ML but haven't really understood the suggestion. |
| 17:12 |
|
Heffalump |
Is it easy to summarise? |
| 17:12 |
|
droundy |
It does say "tree-like", which could describe DAGs. |
| 17:13 |
|
droundy |
The idea is to scrap conflictors, which means merging won't always be done by commutation with inverses. |
| 17:14 |
|
Heffalump |
and instead? |
| 17:14 |
|
droundy |
Instead we allow the repository to hold not just a sequence of patches, but also trees of patches (or maybe DAGs), which would be how conflicting patches are represented. |
| 17:14 |
|
droundy |
Each branching of the tree would be a conflict. |
| 17:15 |
|
droundy |
Then we'd need "resolution" patches to tell us what to do in the case of a conflict. And I'd thought of a resolution patch as tying together the ends of the tree (which would make a DAG), but arjanb is thinking of a resolution just marking those ends as "dead ends", so they don't count as conflicts any more. |
| 17:15 |
|
Heffalump |
ok, so when commutation fails we make a branch instead. |
| 17:15 |
|
droundy |
Right. |
| 17:15 |
|
Heffalump |
I think intuitively I prefer your view of it. |
| 17:16 |
|
droundy |
It's nicer, but the more I think about it, the scarier it seems. Perhaps we could think of the "dead ends" as attaching to the resolution, but not have that reflected in the data structure. |
| 17:16 |
|
Heffalump |
do we always commute non-conflicting patches as far up the tree as possible? |
| 17:16 |
|
droundy |
Yeah, that's the idea. Although the exact protocol I'm not sure of. |
| 17:17 |
|
Igloo |
So the DAGness happens when a resolution is recorded? |
| 17:17 |
|
Heffalump |
(cos then we just need to maintain a marker in the tree that is "this is the point we can actually see in the repo") |
| 17:17 |
|
droundy |
Right, and then it gets even more DAGgy when you pull conflicting resolutions, and resolutions of conflicting resolutions. |
| 17:17 |
|
Heffalump |
dead ends sound asymmetric to me |
| 17:17 |
|
Igloo |
I'm wondering if it works for resolution to cause A+B to turn into AA^BB^R, where R is the resolution patch |
| 17:18 |
|
Heffalump |
do you have a concrete example of the scariness of DAGs? |
| 17:18 |
|
droundy |
Igloo: you could think of it that way, and interperet the dead ends as being a short hand for "and its inverse". |
| 17:19 |
|
Heffalump |
should have written a paper for the HW, I could probably have got work to pay for me to go then :-) |
| 17:19 |
|
Igloo |
Actually, can't you put R at the branch point and then have A and B be dangling chains? |
| 17:19 |
|
Heffalump |
Igloo: does that deal with more complicated sets of conflicts well? |
| 17:19 |
|
droundy |
Igloo: right, that's what the "dead ends" approach is. |
| 17:19 |
|
Igloo |
I don't know. That's why I'm saying it here in teh hope that someone else will work it out :-) |
| 17:19 |
|
Heffalump |
oh, right, so it is symmetric |
| 17:21 |
|
droundy |
Heffalump: (regarding scariness of DAGs) I just can't figure out how to store a DAG in terms of "simple" sub-DAGs probably because it isn't possible for a general DAG, which is pretty much what we'd have. |
| 17:21 |
|
Heffalump |
hmm, flight to Oregon for ÂL500, musn't be tempted... |
| 17:21 |
|
droundy |
:) |
| 17:22 |
|
Heffalump |
a DAG is just a node with pointers to children isn't it? |
| 17:22 |
|
Heffalump |
well, set of nodes |
| 17:22 |
|
Heffalump |
they're not as compositional as trees, certainly |
| 17:23 |
|
droundy |
But doing that prettily is tricky. In particular, I'd like to keep the GADT checking of patch orders. I think with trees that is extremely doable, which is nice. |
| 17:23 |
|
Heffalump |
DAGs are a bit trickier to represent in Haskell. |
| 17:23 |
|
Heffalump |
There's a good paper on the subject, Launchbury and King, "Structuring Depth-First Search in Haskell". |
| 17:23 |
|
Heffalump |
but it's certainly a layer of complication |
| 17:25 |
|
droundy |
Also, when looking for patch B which depends on A, with a tree, you only need look down the branch that has A, and at every branching point you know precisely which way you're going (since there's only one route to your destination). |
| 17:25 |
|
Heffalump |
hmm. In a DAG, will each branching point have precisely one resolution point? |
| 17:25 |
|
Heffalump |
thinks not, cos of A, B and C all conflicting, and someone resolves just A and B. |
| 17:25 |
|
droundy |
No, not necesarily. |
| 17:26 |
|
arjanb |
reads up |
| 17:26 |
|
Heffalump |
http://portal.acm.org/citation.cfm?id=199530 if you have an institutional ACM DL subscription btw. |
| 17:26 |
|
Heffalump |
(for the aforementioned paper) |
| 17:27 |
|
droundy |
arjanb: I think we've all reached agreement with you (with possible exception of Heffalump), or at least with my interpretation of what you meant by "dead ends". |
| 17:28 |
|
arjanb |
i see |
| 17:28 |
|
Heffalump |
tell you what, I'll think about DAGs some more and try to summarise what I come up with so you can decide if they are worth it again. |
| 17:29 |
|
droundy |
okay. It'll be interesting to learn about, anyways. |
| 17:29 |
|
Heffalump |
so what happens with "dead ends" if you have A B and C conflicting and you resolve A and B? you push R up to the branch point and leave C dangling? |
| 17:30 |
|
Igloo |
If I have A in my repo, I pull B from your repo, resolve with R, and then pull B' from your repo (which depends on B), what does my repo look like? |
| 17:30 |
|
Heffalump |
B' and R end up conflicting, right? |
| 17:31 |
|
droundy |
Heffalump: No, I'd say R stays where it is, but C is now dangling. We need a clear distinction between live and dead ends. |
| 17:31 |
|
Igloo |
But B' can't be at the root of the DAG |
| 17:31 |
|
Igloo |
(AIUI) |
| 17:31 |
|
Heffalump |
oh, hmm. |
| 17:32 |
|
arjanb |
Igloo: i think you get a conflict between the resolution patch and the sequence BB' |
| 17:32 |
|
Heffalump |
and it should be below B. |
| 17:32 |
|
droundy |
Igloo: we can have a conflict between patches that aren't at the same root. There's a bit of a danger that all conflicts end up sharing a common root, if people don't stop. |
| 17:32 |
|
Igloo |
arjanb: So I end up with 2 copies of B in my repo? |
| 17:32 |
|
Heffalump |
do we expect that if B' depends on B, then B' is a child of B? |
| 17:32 |
|
droundy |
wishes he had nice tree-drawing tools |
| 17:33 |
|
kowey |
droundy: omnigraffle? |
| 17:33 |
|
droundy |
Igloo: No, just one copy of each patch in each tree, but the "endings" are different. |
| 17:33 |
|
Igloo |
My understanding of the tree/DAG was that any route from the root to any point gave you a valid patch sequence |
| 17:33 |
|
droundy |
Yeah, that's true. |
| 17:34 |
|
arjanb |
you can have a patch in multiple branches of a tree i think |
| 17:34 |
|
Heffalump |
ok, so B' has to be a child of B somehow. |
| 17:34 |
|
droundy |
Right, B' is a child of B. |
| 17:35 |
|
Heffalump |
arjanb: that sounds potentially exponential |
| 17:35 |
|
droundy |
arjanb: I don't think we need (or want) a patch in multiple branches. |
| 17:36 |
|
Heffalump |
how do "dead ends" indicate which patches are resolved? Because they end up being the children of the resolution patch? |
| 17:36 |
|
Igloo |
http://urchin.earth.li/~ian/conf.png is my question. As I understand the proposal I can't just put B' under B as then it would be resolved by R. |
| 17:37 |
|
droundy |
Igloo: your first resolution is wrongly drawn, I'd say. |
| 17:38 |
|
Igloo |
OK, that's what I meant by |
| 17:38 |
|
Igloo |
[18:19] < Igloo> Actually, can't you put R at the branch point and then have A |
| 17:38 |
|
Igloo |
and B be dangling chains? |
| 17:39 |
|
Igloo |
so if that's not the dead ends approach then I don't know that is :-) |
| 17:39 |
|
droundy |
I'll draw something as soon as I can figure out how. |
| 17:39 |
|
Igloo |
heads foodwards |
| 17:39 |
|
Igloo |
:-) |
| 17:40 |
|
Heffalump |
we need a sketching attachment for a wiki |
| 17:40 |
|
kowey |
there are wikis out there with a graphviz plugin |
| 17:41 |
|
arjanb |
a resolution patch would be something like: |
| 17:41 |
|
arjanb |
-*--R-- |
| 17:41 |
|
arjanb |
\-B |
| 17:42 |
|
arjanb |
. /-A |
| 17:42 |
|
arjanb |
.-*--R-- |
| 17:42 |
|
arjanb |
. \-B |
| 17:43 |
|
Heffalump |
which way up is that? |
| 17:43 |
|
arjanb |
root on the left |
| 17:44 |
|
Heffalump |
why are there two Rs and two Bs? |
| 17:44 |
|
arjanb |
ignore the first 2 lines pasting went wrong |
| 17:45 |
|
Heffalump |
ok, so what does that picture look like when B' comes in? |
| 17:46 |
|
arjanb |
. /-A |
| 17:46 |
|
arjanb |
. /-*--R-- |
| 17:46 |
|
arjanb |
.-* \-B |
| 17:46 |
|
arjanb |
. \-B-B'- |
| 17:47 |
|
Heffalump |
the duplication of B seems dangerous to me |
| 17:47 |
|
droundy |
Okay, http://darcs.net/Simpleconflict.pdf shows the first conflict being resolved. A+B resolved by R |
| 17:48 |
|
Igloo |
Yeah, that's going to quadratic in the size of Bs |
| 17:48 |
|
arjanb |
i think the duplication happens only with unresolved conflicts |
| 17:48 |
|
Heffalump |
isn't it exponential in the depth of the dependency chain? |
| 17:49 |
|
Heffalump |
oh, so edge-labelled graphs |
| 17:49 |
|
Heffalump |
droundy: and where does B' go in your graph? |
| 17:49 |
|
Igloo |
Both arjanb's and droundy's are isomorphic to mine, incidentally, you've just written the R in a slightly different place |
| 17:49 |
|
droundy |
Heffalump: one moment. |
| 17:49 |
|
Igloo |
(and I didn't put the live tail in) |
| 17:50 |
|
droundy |
see http://darcs.net/conflict2.pdf |
| 17:51 |
|
droundy |
Note that only tree ends are live or dead in the picture. |
| 17:51 |
|
Igloo |
How do we know that R resolves A and B but not B'? |
| 17:51 |
|
Heffalump |
I found http://twiki.org/cgi-bin/view/[…]s/TWikiDrawPlugin , I could install it somewhere if that would be useful to anyone |
| 17:52 |
|
Heffalump |
because the B' tail is live? |
| 17:52 |
|
Heffalump |
But I don't see how that scales to B -> B' -> B'' . |
| 17:52 |
|
droundy |
Igloo: the contents of R indicate which patches it resolves. Resolution patches are a special sort of patch. |
| 17:53 |
|
Igloo |
vanishes again |
| 17:53 |
|
Heffalump |
Oh, ugh. It really ought to be visible from the graph, IMO. |
| 17:53 |
|
arjanb |
i would view a tree of a resolved conflict internal to the resolution patch |
| 17:55 |
|
arjanb |
so you can't just attach B' to it but B' has to be in a seperate branch |
| 17:55 |
|
droundy |
arjanb: possibly, but then you'd have to pull it out whenever the conflict's reopened. |
| 17:56 |
|
droundy |
I've put up a http://darcs.net/conflict3.pdf by the way. Nothing surprising (perhaps?) |
| 17:57 |
|
Heffalump |
why is R' not just the resolver of R and B'? |
| 17:57 |
|
Heffalump |
A and B were already dead when we did that. |
| 17:57 |
|
droundy |
I suppose you could say that. In fact, probably it is. But I think it'd also need to resolve B, since B was in a live branch. |
| 17:59 |
|
Heffalump |
this feels wrong. The DAG makes it all much clearer. And I don't actually see how having R refer to A and B is any different to having a DAG. |
| 18:00 |
|
droundy |
i think it is perhaps conceptually a DAG, but in terms of data representation it's a tree, which makes life simpler. |
| 18:00 |
|
Heffalump |
how is the A that is referred to in R(A,B) represented then? |
| 18:01 |
|
droundy |
A PatchInfo, I presume. |
| 18:02 |
|
Heffalump |
what's that? (the darcs-patch-theory repo doesn't seem to know) |
| 18:03 |
|
droundy |
Oh, it's the name of a "named" patch, including your email and patch name and date. |
| 18:03 |
|
droundy |
I see these as "high level" pictures, which means each patch has a unique identifier. |
| 18:03 |
|
Heffalump |
ok, so it's implicitly a reference. |
| 18:04 |
|
droundy |
Right. Which is why this really works out to a sort of DAG, but with a distinction between arrows. |
| 18:05 |
|
Heffalump |
hmm. |
| 18:08 |
|
arjanb |
i don't think name references are needed but that would cost some duplication of the patch contents |
| 18:08 |
|
droundy |
Right, we wouldn't need them, but at the top level we've got them, and I think we might as well use them. |
| 18:09 |
|
droundy |
And it might not be a small duplication of patch contents at all. It's very easy for newbies (or sometimes oldies) to get in usage patterns where *lots* of patches conflict and the same ones are repeatedly resolved (and the resolutions conflict, etc). |
| 18:10 |
|
Heffalump |
would like to get into a usage pattern where there were lots of conflicts |
| 18:10 |
|
Heffalump |
but I can't, cos darcs blows up on me, so I've trained myself not to |
| 18:10 |
|
Heffalump |
but it's sometimes annoying |
| 18:10 |
|
Heffalump |
I do stuff like using amend-record after I resolve something, forcing order on myself. |
| 18:10 |
|
droundy |
I see a real advantage of this approach being that we only store each patch once. |
| 18:11 |
|
droundy |
agrees with Heffalump about the conflicts business, the original intent was that one could blithely code without worrying about such things due to the patch algebra. |
| 18:12 |
|
Heffalump |
at work I find myself having to decide "which of these two lines of work will I want to check in (to the central svn repo) first" |
| 18:12 |
|
Heffalump |
continues to think about DAGs (which also have the store-once property) |
| 18:13 |
|
Heffalump |
sadly it's not at all obvious how to have the context arguments we'd want for the GADT stuff |
| 18:14 |
|
droundy |
Heffalump: you mean with DAGs, or with the tree+label approach I'm leaning towards? |
| 18:17 |
|
arjanb |
how would an inverse of a resolution patch look like? |
| 18:18 |
|
droundy |
arjanb: I suppose it would undo the effect, and make all the dead ends live again? |
| 18:19 |
|
Heffalump |
with DAGs |
| 18:19 |
|
Heffalump |
but I now have the germ of an idea about how it might be done. |
| 18:19 |
|
droundy |
Right |
| 18:20 |
|
Heffalump |
hmm, inverses sound bad. |
| 18:20 |
|
Heffalump |
(with DAGs) |
| 18:22 |
|
droundy |
Indeed. in a pinch we could consider disallowing inverses of resolution patches (but I'd rather not). |
| 18:28 |
|
arjanb |
so what's open besides how to implement it? |
| 18:28 |
|
Heffalump |
eek, what happened to all the weeks of discussing complicated conflict scenarios? ;-) |
| 18:30 |
|
droundy |
There is that. And I'm looking into graphviz for displaying complicated conflict scenarios... |
| 18:30 |
|
droundy |
But my guess is that arjan's right and the next stage is looking into implementation. |
| 18:31 |
|
droundy |
First thing is decent tree-handling code, dealing with things like taking the union of two trees. |
| 18:32 |
|
Heffalump |
that's a well-understood problem |
| 18:33 |
|
droundy |
right, it's defnitely doable, but needing to commute makes it considerably more tedious. |
| 18:49 |
|
Igloo |
Did you all agree DAGs are the way to go? |
| 18:51 |
|
Igloo |
doesn't see why inverses of resolutions cause problems with DAGs |
| 18:55 |
|
droundy |
i don't think they are, directly, although including patch ids of patches we resolve in the resolution patches makes our data logically equivalent to a DAG. |
| 18:55 |
|
droundy |
but I think we want to have in memory just a normal tree. |
| 18:56 |
|
Igloo |
So that's a 'no' to my first line, right? |
| 18:58 |
|
arjanb |
right |
| 19:08 |
|
arjanb |
is thinking about how the patch with its inverse constructions fit in this tree thing |
| 19:10 |
|
Igloo |
doesn't understand that |
| 19:13 |
|
arjanb |
i want to try to get merges like A + BB^ always succeed |
| 19:14 |
|
Igloo |
Ah, I see |
| 19:14 |
|
Igloo |
If I pointed out that that would automatically work if we had full graphs, who would shoot me first? |
| 19:16 |
|
droundy |
arjanb: I don't see how we can do that, unless we used a resolution to kill B rather than an inverse. |
| 19:17 |
|
droundy |
Igloo: i'm not sure what you mean by "full graphs". |
| 19:17 |
|
Igloo |
DGs rather than DAGs |
| 19:17 |
|
droundy |
Yikes. |
| 19:21 |
|
arjanb |
droundy: it's the shadowpatch construct in my code and i have seen no problems in manipulating it |
| 19:22 |
|
arjanb |
i guess it's similiar to have a dead end branch that isn't part of a resolution patch |
| 19:22 |
|
Igloo |
Actually, I think we can probably keep B and B^ together in the DAG and just treat them as a single non-conflicting blob for everything |
| 19:23 |
|
droundy |
Why not just make it a resolution patch? |
| 19:23 |
|
droundy |
i.e. a resolution patch kills a branch, so why should a shadow patch be different? |
| 19:23 |
|
Igloo |
Oh, no, that doesn't quite work |
| 19:25 |
|
arjanb |
not sure but it might generalise to the same thing |
| 19:54 |
|
droundy |
I'm afraid I'm going to need to stop for the day. It's been fun. And hopefully, Arjan, we'll be able to work together to get some working code, at least if you've got time? |
| 19:55 |
|
arjanb |
i will have a lot of time the coming weeks |
| 19:55 |
|
droundy |
Excellent. Do you have a computer where you can put a darcs repository, or could I give you an account on darcs.net? |
| 19:56 |
|
droundy |
I'm afraid my endurance for coding is nowhere near where it used to be (plus I've not got much free time). |
| 19:58 |
|
arjanb |
i don't have webspace atm but i will see if can get it somewhere |
| 19:58 |
|
droundy |
If that's a problem, I can give you an account, quite easily... |
| 20:00 |
|
arjanb |
no need for now |
| 20:00 |
|
droundy |
okay. I'll probably be back tomorrow morning and late afternoon (although that'll be after playing ultimate frisbee, so we'll see how much energy I've got left). Bye! |
| 20:01 |
|
arjanb |
bye |
| 21:24 |
|
njs |
re: sketching graphs, y'all might find http://aaronbentley.com/pastegraph.cgi handy |
| 21:30 |
|
Heffalump |
ta |
