Thu Aug 13 07:08:49 BST 2009 Ganesh Sittampalam <gan...@earth.li>
* fill in some old conversation about the hashed-storage library split
Thu Aug 13 07:09:15 BST 2009 Ganesh Sittampalam <gan...@earth.li>
* fill in some old conversation about indexed trees
Thu Aug 13 07:21:05 BST 2009 Ganesh Sittampalam <gan...@earth.li>
* performance on plain repos
New patches:
[fill in some old conversation about the hashed-storage library split
Ganesh Sittampalam <gan...@earth.li>**20090813060849
Ignore-this: afcfaf1f4c84298668548d9f8cc166b2
] hunk ./Review/DarcsHS.page 34
lock-step development is a problem, but I am not sure how much it can be
eliminated. Probably something for further discussion.
- [Some conversation I don't have access to on the train]
+ Ganesh: I guess the question is what the intended use cases for hashed-storage
+ outside darcs are. I can see two possibilities:
+
+ (a) General hash-structured storage library. It feels like it should be
+ generally useful but the only concrete idea I can think of would be for
+ reading git repos. In this situation hashed-storage really does belong as
+ an independent library.
+
+ (b) A way of reading darcs repos (and perhaps writing them, for the
+ brave). This would be an important step towards a stable darcs API, and
+ clearly should be a separate cabal package, but if it's just that, I think
+ it should be called something darcs-specific (darcs-storage?) and live in
+ the darcs tree.
+
+ Nicolas Pouillard: Or writing a program that needs massive persistent data, like a mail client.
+ I'm planning to use this kind of library one day for a program like this,
+ however maybe hashed-storage would have to be more flexible.
+
+ I'm not saying that either of these use cases have to exist prior to
+ merging into mainline, just that it has to be understood (and documented)
+ what the expectations are.
Ganesh: IMO, the emergence of a separate project using hashed-storage clearly
settles the question of whether hashed-storage should be an independent
[fill in some old conversation about indexed trees
Ganesh Sittampalam <gan...@earth.li>**20090813060915
Ignore-this: 8fd7700b487892aeadf9d9e5cccccc1
] hunk ./Review/DarcsHS.page 108
a Tree that wasn't quite like normal Trees, which makes me uncomfortable.
We should discuss a bit more what it's trying to achieve (perhaps on IRC).
- [There was more conversation after this that I don't have access to on the train]
+ Petr: This is now done as well. The readIndex function now gives a pair: the Tree
+ object, and an action to "update" it. I have documented the new behaviour [1]
+ in haddock. It is indeed a little different from the usual Tree objects in the
+ sense that it gives you what is in the index file -- which may be out of
+ date. It would however be a waste to update all of the index every time
+ (although this may be what git does, IIUIC). To make it possible to update only
+ a part of the index, you can trim down the index Tree and then update the
+ result. It however wouldn't be much of a problem to also provide a function
+ that will always give you full, up-to-date index. For darcs however, we need
+
+ Ganesh: OK, so now what you've got is an API with lots of constraints on how it
+ should be used and lots of ways to get it wrong. How about an alternate
+ type, e.g. IndexTree, with its own filter operation, and functions to
+ get at either the real Tree or both the real Tree and the hash/mtime
+ map (both of which force it)? Under the covers IndexTree could just be a
+ Tree with the current implementation, but at least the API would be safe.
+
+ Petr: So I have thought about this, and what I finally did:
+
+ - wrapped the Tree that comes from readIndex in a newtype (not exporting its
+ data constructor)
+ - lifted filter into a type class, so it can be used on both usual trees and
+ the index newtype
+ - if we find more operations that are both safe and meaningful on IndexTree, we
+ can lift them into a type class as well
+
+ The class is a little tricky [1], and I couldn't find a better solution -- if
+ you have one, shoot. This also prompted types like:
+
+ restrictSubpaths :: (RepoPatch p) => Repository p C(r u t) -> [SubPath]
+ -> IO (forall t m. FilterTree t m => t m -> t m)
+
+ in darcs-hs, but I am reasonably content about needing this in exchange for the
+ safe API.
+
11. Safety of hash treatment
[performance on plain repos
Ganesh Sittampalam <gan...@earth.li>**20090813062105
Ignore-this: 14194f62ba62247041e9d064f6e67c97
] hunk ./Review/DarcsHS.page 271
Ganesh: We should defer the corrupt pending naming from this review.
+16. Performance on old fashioned repos with plain pristine
+
+ Ganesh: As per the IRC conversation from 12th August, it turns out that this work
+ makes operations (just the ones that involve diffing?) on plain repos much slower,
+ because the hashed-storage Tree structure doesn't track mtimes and so they can't
+ be used as a substitute for hash comparison.
+
+ If we are to introduce substantial slowdowns for plain repos, we need to discuss
+ and agree this more generally. Note that darcs 2.3 is already experiencing these
+ slowdowns for whatsnew.
+
+ One option would be to keep around the old code (unsafeDiff/Slurpy etc) for use
+ with plain pristines. This would have the obvious disadvantage of leaving us with
+ two sets of filesystem abstraction code to maintain.
+
+ Petr's suggestion is (I think) to superimpose a hashed index on plain pristine, which
+ would also add a level of robustness against pristine corruption - darcs would at least
+ be able to complain if something messed up the plain files. This sounds like a good
+ idea to me, though I haven't thought about it in great detail yet.
Context:
[argh
kowey <>**20090814163018
Ignore-this: 947bf528842be0c100f6b4b61450ee17
]
[tweak URL formatting
kowey <>**20090814162959
Ignore-this: dafed569adee44be0ad12867da6df7a2
]
[formatting
kowey <>**20090814162857
Ignore-this: 597eda56577b08389366b28b51a964bf
]
[fix formatting
kowey <>**20090814162801
Ignore-this: 3ba1ed55db1c0888b83186810d83c761
]
[link to separate troubleshooting page
kowey <>**20090814162432
Ignore-this: a8fef4b6d593e8b2a6b3b480be9459a2
]
[copy from FAQ
kowey <>**20090814162246
Ignore-this: c13a3659a1c9943026e100dd394611eb
]
[Start to clean up a bit.
Eric Kow <ko...@darcs.net>**20090814161852
Ignore-this: e8573841d809107abc79ba1e9c8edf12
]
[Add some more thoughts and try to reduce duplication.
Eric Kow <ko...@darcs.net>**20090814160459
Ignore-this: 565cc053c846b608fb859891eb90f1c0
]
[see also (mostly for bugtracker)
kowey <>**20090812142852
Ignore-this: f02cb87e875511a651d64b8d366e3aeb
]
[add bug tracker entry
kowey <>**20090812142657
Ignore-this: 7f1416530d3ce12e0cf1f1ce4f645761
]
[no more autobuilds, sorry
kowey <>**20090812132943
Ignore-this: 53888b629f7be358682e83ec33b3f36f
]
[note about tags
kowey <>**20090812120951
Ignore-this: 2226b8fd63bec3940e7661e55cb020e5
]
[talk to us!
kowey <>**20090812120348
Ignore-this: cbc05121609863ae7eb5469b8b7f00ca
]
[wibble
kowey <>**20090812120111
Ignore-this: 65b4bf96046343489466620ddbd886ba
]
[tidy up speed faq
kowey <>**20090812115954
Ignore-this: 55ec9767813fcdfb3e777d9ea0584e3c
]
[simplify release planned text
kowey <>**20090812100935
Ignore-this: 68c395ecccb87679d1924478ea56d82f
]
[config: turn the logging all the way up
gi...@darcs.net**20090812013401
Ignore-this: 67367ff6e4069925208e3c12a28fa0da
]
[follow gitit HEAD: js
gi...@darcs.net**20090812013342
Ignore-this: c6992e903a683b28dc3b0f79b848bc39
]
[follow gitit HEAD: css
gi...@darcs.net**20090812012409
Ignore-this: 6481186f0ebd6f2d329cc47c21d3b7a9
]
[follow gitit HEAD: switch to split apart template.html
gi...@darcs.net**20090812011119
Ignore-this: 4a1bd6577c21b966847f350e0459726d
]
[TAG 2009-08-11
Ganesh Sittampalam <gan...@earth.li>**20090811205633
Ignore-this: 4a7e002c94ced233987bec815afe9799
]
Patch bundle hash:
1b1d643b75038b2573bf9d99aa5b5137d6eec955
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
