Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2015-10-20

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

All times shown according to UTC.

Time Nick Message
09:48 haasn joined #darcs
14:48 drostie_ joined #darcs
15:33 gh_ joined #darcs
17:38 biglama joined #darcs
17:39 biglama hi guys
17:39 biglama are there any recent benchmark of darcs vs git (for example) ?
17:40 biglama i am pondering the potential downsides of using darcs and it seems performance is/was an issue
17:41 dolio darcs is slower, without question. The question is, does that matter?
17:41 dolio I'm not sure you can tell from a benchmark.
17:42 biglama my use case is for small projects so I do not think it is an issue
17:43 christoph_debian joined #darcs
17:43 biglama but i've seen there was an issue with exponential merge time
17:43 biglama is it still the case ?
17:43 christoph_debian hi! clicking on the darcs website startpage on [discuss] on the top yields http://darcs.net/@FrontPage which clearly looks like spam
17:47 dolio Yes, in principle. But you need to do specific things to trigger the exponential behavior.
17:47 notdan christoph_debian: uh-oh, that's not right!
17:49 notdan Heffalump: can we remove a patch that is responsible for: http://darcs.net/@FrontPage ? I tried using Gitit to look at the history of that page, but aparently there is no
17:51 biglama dolio: i see. So can I assume it happens very unfrequently and live happily without concerns ?
17:57 dolio It might depend on what you're doing.
17:57 dolio I've never had it happen, but all my darcs repos are mostly just me.
17:58 dolio I think what we do where I work with our mercurial repositories would very likely trigger the problem, if I've read correctly, but that's because it's a policy designed for working with mercurial and not darcs.
18:00 biglama my use case is similar to yours (one user per repo) so it should be okay
18:00 dolio Of course, I don't know that it would trigger the problem, either, because I haven't tried doing the same thing on the same codebase with darcs.
18:00 biglama out of curiosity, how come git does not have the same issue ?
18:03 sm I really, really wish we had a FAQ or other doc saying: yes, darcs has exponential merge behaviour in exactly these circumstances, here is an example to reproduce it, and here is how to ensure you avoid it
18:03 dolio Because git (and mercurial, and most other version control systems) just store the graph of snapshots that actually occurred in practice, while darcs stores the patches between those snapshots, and tries to figure out how those patches could be reordered, such that you can select arbitrary subsets of them.
18:04 sm ...also, here is why we haven't fixed it and if you want to try, here is how to start..
18:05 biglama dolio: thanks a bunch
18:05 biglama sm: yes, that would be nice
18:06 biglama in my quest for answers about darcs, I've been a bit disappointed by the wiki which is not really up-to-date
18:06 sm biglama: you will never encounter it if you always merge "clean", ie in git lingo "rebase" on master before you merge
18:08 sm biglama: yes, darcs is much loved but a bit short of volunteers
18:08 biglama sm: I thought rebase and merging in git were different operations for the same goal, so what would be the point of rebasing before a merge ?
18:08 sm so our web presence/docs frankly suck a bit
18:08 sm biglama: in git, many people also recommend rebasing before you merge. It ensures the merge will be easy
18:09 biglama #darcs, or the place where you learn about git :)
18:10 sm :) I think most VCS channels have thought a lot about git
18:10 sm it's hard to avoid
18:10 biglama okay, i'm going to give darcs a try, thanks for the explanations
18:11 Heffalump biglama: in darcs a merge doesn't create any new commits/patches, it just makes your repository have both its patches and the patches being merged
18:11 biglama is darcs-bridge safe for a one-way operation (git->darcs) as it's written in the wiki ?
18:12 Heffalump where does it say that? We probably shouldn't be recomendeing it at all now.
18:12 sm all mentions of darcs-bridge or other conversion tools are obsolete, use the built-in convert command instead
18:12 biglama http://darcs.net/DarcsBridgeUsage#how-do-i-use-it
18:12 biglama "To be clear: one-shot conversions in either direction (darcs -> git or git -> darcs) should be fine, but attempting to create a synced bridge is very likely to fail/cause corruption."
18:12 sm alias darcs-to-git='git init && darcs tag to-git && darcs convert export | git fast-import && deunderscore-git-tags && git reset'
18:12 sm is what I use
18:14 sm and alias deunderscore-git-tags='echo renaming git tags...; git tag | grep _ > t; for t in `cat t`; do git tag `echo $t | sed -e s/_/./g` $t; git tag -d $t; done'
18:14 biglama will it preserve history too ?
18:14 biglama sm: you should put it on the wiki :)
18:14 sm yes. Try it in a copy to get comfortable
18:15 Heffalump biglama: I guess that page should be read in context of the warning at the top
18:15 sm the page should be removed
18:15 biglama Heffalump: yeah but I thought it would still be usable
18:15 Heffalump notdan: I'm trying to figure it out, but it looks like it might have been there for quite a while
18:15 Heffalump biglama: I don't see why it wouldn't be within those constraints, but building it might be the first challenge.
18:17 biglama okay
18:19 drostie_ joined #darcs
18:25 sm darcs.net feels very snappy btw - thanks for the system upgrade Heffalump
18:28 dolio biglama: From what I've read, the problem cases are where you have long-running branches, and keep merging from one to another, and the merges have conflicts that need to be fixed.
18:31 dolio So rebasing would solve that in that you'd rewrite all patches to be compatible with the main-branch changes, and never have conflicts when merging. But you might also naturally not have conflicting changes.
18:31 dolio I think that's pretty likely when you're just one person working on something.
18:32 sm yeah, I think I've only encountered it once in 8+ years with darcs, when trying to merge two highly divergent branches
18:33 sm and that wasn't the latest darcs
18:33 dolio So, at work, we have two very long running branches, and if a change needs to go in both branches, we're required to write it in the old-version branch and merge into main-branch.
18:34 dolio Which is kind of perfectly designed to trigger this problem.
18:34 dolio But we have to do that because cherry picking commits from main-branch to old-branch isn't a good idea in mercurial.
18:34 sm dolio: but now darcs has rebase, doesn't that solve it ?
18:34 dolio So if we were using darcs, things might be different, since cherry picking is kind of designed in.
18:35 sm ohn
18:35 sm oh
18:40 dolio I've never looked at darcs' rebase.
18:40 dolio Anyhow, I'm not sure it's even necessary. Just that you might not use darcs the same way you use mercurial. Although I haven't thought very hard about it, because I've never needed to.
18:43 Heffalump sm: I haven't done it yet!
18:43 sm woah!
18:43 Heffalump notdan: looks like the patch was previously obliterated but the file was left lying around
18:44 Heffalump notdan/cristoph_debian: should be sorted now, thanks for letting me know
18:45 dolio Instead of having development in two branches with forward porting, you have one branch that is backports only, so you might have fewer problems. Although maybe the backports would diverge enough eventually to cause conflicts. I don't know.
23:06 drostie joined #darcs
23:37 Riastradh joined #darcs

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