Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2017-07-14

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:20 Riastradh joined #darcs
02:24 Riastradh joined #darcs
05:40 lambdaGrp joined #darcs
09:09 stef204 joined #darcs
09:45 Igloo joined #darcs
10:09 Igloo joined #darcs
11:26 lambdaGrp joined #darcs
11:34 jeltsch joined #darcs
11:41 Igloo joined #darcs
12:12 lambdaGrp joined #darcs
13:53 Mysterious_Light joined #darcs
15:15 lambdaGrp joined #darcs
15:43 Riastradh joined #darcs
15:47 lambdabot joined #darcs
16:19 Mysterious_Light joined #darcs
18:02 Riastradh joined #darcs
18:16 Mysterious_Light joined #darcs
18:40 Mysterious_Light Hello! I've decided to explore random darcs repos on darcshub. To start with, I took pointfree's list.
18:40 Mysterious_Light For example, `camp' contains 241 patches, it took much time to build dependency graph with `darcs show dependencies`. It seems `show dependencies` takes exponential time.
18:40 Mysterious_Light Does that means maintainers do not browse patch diagram?
18:40 Mysterious_Light Does anybody explore repo's logs in depth? E.g. to find out which patches one needs to add with --ask-deps. I can't imagine adding meaningful dependencies without exploring graph with leaves highlighted.
18:43 pointfree Hello Mysterious_Light!
18:58 Mysterious_Light yeah, you find your name mentioned )) It was accidentally.
19:01 burp joined #darcs
19:05 pointfree I'm not the maintainer of camp. That repo is just a mirror (converted to darcs2). It would be cool to have something like camp-view for darcs and darcshub.
19:05 pointfree Nice to hear people are looking at my repos!
19:05 pointfree At the moment my darcshub allocated time is focused on wrapping up the darcshub social feed feature. It pretty much only needs a better way to load larger numbers of pulled patches than what fits in one environmental variable.
19:05 pointfree Speaking of which, Heffalump, sm: Does darcs record a timestamp for the time a patch was applied to the current repo, or only the record timestamp?
19:05 pointfree I was thinking the transition to Haskell Persistent, etc could happen by using Haskell Persistent with the existing darcshub couchdb database, and then switching to another database.
19:05 pointfree I should probably look into writing the Haskell Persistent wrapper for the darcs format.
19:28 jeltsch joined #darcs
19:45 sm pointfree: no I believe it doesn't, currently darcsden would have to log that itself
19:46 sm Mysterious_Light: good for you! No, nobody uses those deps much, we go with the deps darcs calculates based on edit collisions
20:05 Mysterious_Light joined #darcs
20:12 Mysterious_Light sm: in my practice, it's a common situation when a function I'm about to record uses another function written or appropriately modified in another file (i.e. without explicit collision), and I want to highlight the dependency. Especially when these functions are introduced in different "branched" (i don't remember how this technique called when prefixes in messages are used to mark semantically distingueshed branches of development)
20:13 Mysterious_Light don't you have that problem?
20:13 Mysterious_Light *branches
20:18 sm Mysterious_Light: it sounds like you are being a lot more careful than the rest of us
20:19 sm usually if things are dependent, they will all appear in the same commit, no ?
20:29 Mysterious_Light that is the point: recorded patch might use a function appearing in, say, an old commit in a *different* branch.
20:29 Mysterious_Light Well, that is the way I am trying to use darcs: cheap support of several versions simultaneously.
20:29 Mysterious_Light i.e. removing a set of patches gives a version without specific features.
20:31 Mysterious_Light If my idea is wrong, give me an advice how to manage several version simultaneously. There are tones of algorithms for git, but I doubt they are good for patch-based CVS
20:37 sm Mysterious_Light: sorry, I'm not really seeing the problem clearly. Someone else may do better. Is it possible to do it with any other VCS ?
20:37 sm (afk)
21:11 Mysterious_Light Thank you for your comment. I'll try to describe my point of view in details. mb, somebody will show a better way. Or I'll put a question that will motivate us to improve darcs. Kidding.
21:11 pointfree Mysterious_Light: I don't consider myself a patch theory expert, but I've been having similar thoughts. Does the lack of an explicit collision really guarantee a correct merge?
21:11 pointfree Is it enough to trust that a recording/commit correctly captures user intent?
21:13 pointfree Perhaps user intent should be viewed as spanning the history of the repository as well?
21:15 pointfree ...but we also want associative or commutative patches as much as possible.
21:20 Heffalump pointfree: there was some discussion with Factis a while back about scripting something that would add tags each time a patch is added to the current repo
21:23 Mysterious_Light Heffalump: so, have you already discussed an idea of local metahistory?
21:23 Mysterious_Light In git, each version (v1.0, v1.1, v2.0, v2.1 etc) is usually a separate long-living branch. If I want to slightly change, say, v1.2, I create a branch, do changes and merge it back. Since feature branch is based on v1.2 branch, each commit depends on each commit of v1.2. Therefore, transfering that feature to another version, say, v2.0, needs cherry-picking. As I understand, patch-based approach allows to do "reverse rebase" (also called "spontaneous bran
21:27 jeltsch left #darcs
21:37 Heffalump Mysterious_Light: you got cut off at "spontaneous branc.."
22:23 Mysterious_Ligh1 joined #darcs
22:24 Mysterious_Ligh1 indead, thanks irclog. repeat my message
22:24 Mysterious_Ligh1 In git, each version (v1.0, v1.1, v2.0, v2.1 etc) is usually a separate long-living branch. If I want to slightly change, say, v1.2, I create a branch, do changes and merge it back. Since feature branch is based on v1.2 branch, each commit depends on each commit of v1.2. Therefore, transfering that feature to another version, say, v2.0, needs cherry-picking.
22:24 Mysterious_Ligh1 As I understand, patch-based approach allows to do "reverse rebase" (also called "spontaneous branching") by automatically creating a patch not depending on other older patches that it don't have to depend on. Therefore, transfering a feature to another version is just pulling a set of patches with all the dependent patches.
22:24 Mysterious_Ligh1 It directly brings us to my question: how would darcs know which patches to pull with ones we ask, if we haven't annotated them with actual dependencies?
22:46 Heffalump Mysterious_Ligh1: it won't. It'll infer the textual dependencies, and you either have to annotate the actual dependencies at the time of record, or manually pull them over later.
23:11 Mysterious_Ligh1 Right now I try to annotate the actual dependencies, using script that draws a patch graph with highlighted leaves and colored nodes depending on a message's prefix. Lately I was exploring public repos and found out that my workflow can not be applied due to the large size. A discussion there is my attempt to understand how you people prefer to use darcs.

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary