DarcsEvaluation: dag-version-control.txt

File dag-version-control.txt, 22.4 KB (added by guest, 6 years ago)

Discussion of how to conduct versioning on a git/hg style system versus Darcs

Line 
1[2008-07-30 20::52:54] matthew-_: sorry, I missed the meeting this afternoon. Are logs available? - they don't seem to be up on the wiki yet...
2[2008-07-30 20::59:26] Igloo: dons: ?
3[2008-07-30 21::11:40] nominolo: BSP_: ok, make sure you update before that
4[2008-07-30 21::12:26] » andyjgill joined the chat room.
5[2008-07-30 21::12:40] BSP_: oh, did you push something recently?
6[2008-07-30 21::13:00] » ttt-- joined the chat room.
7[2008-07-30 21::15:18] » gbeshers left the chat room.
8[2008-07-30 21::17:08] nominolo: matthew-_: just added it
9[2008-07-30 21::17:38] matthew-_: nominolo: many thanks
10[2008-07-30 21::17:59] nominolo: BSP_: no, but it's important to avoid conflicts
11[2008-07-30 21::27:01] Igloo: Thanks nominolo!
12[2008-07-30 21::28:00] nominolo: BSP_: i'm using macirssi now, but i'm not sure i'm staying with it -- it doesn't support unicode
13[2008-07-30 21::28:45] BSP_: don't worry, i'm building these doc patches on a clean, up to date repo
14[2008-07-30 21::30:49] nominolo: the latest version only works with leopard, but i have the previous version
15[2008-07-30 21::30:54] » Jedai joined the chat room.
16[2008-07-30 21::33:42] matthew-_: so I really like the http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation page - obviously a lot of effort has gone into it. It's a shame that bzr doesn't really support cherry picking as I think if it did then it would be a front runner.
17[2008-07-30 21::33:46] lambdabot: Title: DarcsEvaluation - GHC - Trac
18[2008-07-30 21::34:15] matthew-_: I'm used to monotone which is also dag-based rather than changeset based, and I've never ever wanted to cherry pick, even though it does support it
19[2008-07-30 21::36:40] BSP_: it could just be that there's a better way to do the things that we do currently with cherrypicking
20[2008-07-30 21::37:09] matthew-_: but I guess the point is to find a tool that supports the current clearly effective workflow without the issues of darcs
21[2008-07-30 21::37:20] BSP_: that would be ideal
22[2008-07-30 21::38:13] matthew-_: can you elaborate on that? I actually don't know darcs at all well
23[2008-07-30 21::38:22] BSP_: monotone seems quite unpopular, at least among debian users: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2Cbzr%2Csvn%2Cmonotone&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
24[2008-07-30 21::38:27] lambdabot: Title: popcon graph, http://tinyurl.com/568qtg
25[2008-07-30 21::38:45] matthew-_: yeah, I wouldn't trust those graphs myself. I also wouldn't recommend monotone
26[2008-07-30 21::38:59] BSP_: well, darcs' interface is based on pervasive cherrypicking, which i find very convenient
27[2008-07-30 21::39:36] matthew-_: I don't trust the mtn devs anymore - the really smart people who got it to a great state have left and I don't believe there are enough ppl left who understand it properly
28[2008-07-30 21::39:43] BSP_: thats unfortunate
29[2008-07-30 21::40:44] matthew-_: right, so obviously as a believer in the DAG approach, I don't really believe in cherry picking. It would seem that some of the ghc workflow has adapted to the features that darcs makes available and will have a hard time moving away from those features
30[2008-07-30 21::41:08] BSP_: could be
31[2008-07-30 21::41:47] matthew-_: typically people do a branch per bug or per feature and then so long as merging is fast and easy, it's straightforward to propogate from the mainline to your branch and vice versa
32[2008-07-30 21::42:51] BSP_: it doesn't really have a notion of branches
33[2008-07-30 21::43:10] Igloo: I don't see why that isn't a branch
34[2008-07-30 21::43:26] BSP_: well, i mean that it doesn't have a distinguished status for branches
35[2008-07-30 21::44:14] matthew-_: well, how easy is it for n people to colaberate on any given branch? i.e. what infrastructure do you have to add, how do you share changes on that branch alone, how do new people get hold of that branch etc?
36[2008-07-30 21::44:58] BSP_: i guess you'd need to host a new directory on darcs.haskell.org or some other provider, and pull from that instead
37[2008-07-30 21::45:00] matthew-_: eg with Hg, a repo can contain all branches. And so you just pull/push from your "central" repo and switch branch as you want
38[2008-07-30 21::45:29] BSP_: thats an interesting point
39[2008-07-30 21::45:36] » benny99 joined the chat room.
40[2008-07-30 21::45:37] matthew-_: same with Monotone, and I would imagine bzr and git, though I really don't know about them
41[2008-07-30 21::45:54] Igloo: There's unnecessary complication, though. You need to know how to move changes between repos, and move changes between branches
42[2008-07-30 21::45:54] » andyjgill left the chat room.
43[2008-07-30 21::46:08] ToRA: sorry for jumping in, but with darcs does this mean all records/patches are supposed to be meaningful, and not wip, i'm just backing up commits?
44[2008-07-30 21::46:31] matthew-_: Igloo: that's just a core operation though, I feel.
45[2008-07-30 21::46:34] Igloo: ToRA: I don't follow
46[2008-07-30 21::46:58] matthew-_: Igloo: on the same level as ci, pull, push, merge
47[2008-07-30 21::47:08] Igloo: matthew-_: Right, you need more core operations
48[2008-07-30 21::47:33] matthew-_: infact, with most of them, it's just merge, but you add one extra arguement to say that you're merging with a head in another branch rather than two (or more) heads in the current branch
49[2008-07-30 21::48:23] ToRA: Igloo: so if you have a branch per bug then the branch from start to finish is the meaningful work (the new feature or fix), but the individual commits may not mean anything without all of the branch
50[2008-07-30 21::48:57] matthew-_: ToRA: well, only in a DAG based system. Because each revision references its parent
51[2008-07-30 21::49:08] Igloo: Ah, I see. You normally try to make the repo work after each patch, but not necessarily
52[2008-07-30 21::49:46] BSP_: well, it's nice having rebase so you can make the repo work after each patch after the fact
53[2008-07-30 21::49:57] ToRA: matthew-_: technically it's only meaningful when you merge back into the mainline branch, and it's the delta from the branch point to the merge point that's "meaningful"
54[2008-07-30 21::50:25] matthew-_: yep.
55[2008-07-30 21::50:56] » mav left the chat room.
56[2008-07-30 21::51:16] » Jedai left the chat room.
57[2008-07-30 21::51:18] matthew-_: so with a DAG based system, you wouldn't really want to cherry pick out of a branch as you don't know whether it works or not. Typically the branch authors would merge back to main/trunk at suitable points
58[2008-07-30 21::51:36] BSP_: it's certainly an interesting approach
59[2008-07-30 21::51:40] matthew-_: but as I say, I'm used to monotone and really unused to darcs
60[2008-07-30 21::52:03] BSP_: i don't think people do that with darcs at all, because branching is relatively costly
61[2008-07-30 21::53:06] matthew-_: right, so I think if branching is really cheap then you can treat each branch as a separate container which shields mainline from the changes you make
62[2008-07-30 21::53:31] BSP_: what about if you're working on a branch and you decide you want to checkpoint some of your changes for inclusion into HEAD, but continue working on developing the rest?
63[2008-07-30 21::53:40] matthew-_: but yep, merging to and from different branches has to be easy, and switching branches has to be really low cost
64[2008-07-30 21::53:58] BSP_: right
65[2008-07-30 21::54:05] matthew-_: you then merge your branch head with mainline
66[2008-07-30 21::54:14] » Pieter joined the chat room.
67[2008-07-30 21::54:25] BSP_: ok, but say in the merge you discarded some of the changes from your previous patches
68[2008-07-30 21::55:00] matthew-_: hang on
69[2008-07-30 21::55:09] BSP_: (btw i'm not saying darcs can do this, i'm just curious)
70[2008-07-30 21::55:56] matthew-_: with this pattern, a merge would be three way between the branch head, the trunk head and the common parent (which would be the last merge between the branch and mainline or failing that the revision at which the branch was created)
71[2008-07-30 21::56:38] BSP_: right, ok
72[2008-07-30 21::56:48] matthew-_: now, you can always easily switch back to an earlier revision
73[2008-07-30 21::56:54] BSP_: and merge that
74[2008-07-30 21::56:57] matthew-_: that's always trivial, and merge from there
75[2008-07-30 21::57:59] » dolio left the chat room.
76[2008-07-30 21::58:20] BSP_: Igloo: what do you think about this approach? you probably have to do this kind of operation more than any of us, to maintain e.g. the 6.8 branch
77[2008-07-30 21::58:32] nominolo: i guess git/mtn/hg/bzr could have a tool where you just drag and drop parts of graphs :)
78[2008-07-30 21::59:16] matthew-_: nominolo: that's probably why I'd recommend Hg or Bzr over Monotone - extending mtn is a pita, whereas the other two, being in python, are really easy to extend
79[2008-07-30 21::59:16] BSP_: :)
80[2008-07-30 21::59:56] matthew-_: well yeah, things like emailing diffs on commit
81[2008-07-30 22::00:18] nominolo: well, there's actually a haskell library for git
82[2008-07-30 22::00:28] BSP_: i guess you can always use shell scripts.. .http://ozmm.org/posts/git_post_commit_for_profit.html
83[2008-07-30 22::00:29] matthew-_: nominolo: I sit corrected then :)
84[2008-07-30 22::00:29] lambdabot: Title: Git post-commit for profit ones zeros majors and minors
85[2008-07-30 22::00:36] BSP_: git haskell??
86[2008-07-30 22::00:54] nominolo: also, our darcs commit messages are just shell scripts
87[2008-07-30 22::01:45] BSP_: nominolo: have you got a link for that library?
88[2008-07-30 22::01:46] matthew-_: also, mtn uses an sqlite db to store everything in, which has both benefits and drawbacks. One of the issues is that there's just a single big db lock, which adds a whole lot of pain when trying to extend mtn
89[2008-07-30 22::01:51] » dolio joined the chat room.
90[2008-07-30 22::02:11] nominolo: i though i had seen something like this on hackage
91[2008-07-30 22::02:40] BSP_: thats a shame
92[2008-07-30 22::03:52] matthew-_: the maintanence of, eg 6.8, backporting fixes from mainline would be just horrendous without rebasing
93[2008-07-30 22::04:28] BSP_: matthew-_: you mean, if we weren't to use the topic branch approach?
94[2008-07-30 22::05:02] matthew-_: no, if you had one mainline devel branch, then a branch per feature, and then further branches for stable releases
95[2008-07-30 22::06:00] BSP_: heh
96[2008-07-30 22::06:24] matthew-_: you'd want to take a branch which was a fix, then rebase it onto the current head of the 6.8 branch
97[2008-07-30 22::06:48] BSP_: ok
98[2008-07-30 22::07:11] matthew-_: well, depends where the bug is
99[2008-07-30 22::07:15] BSP_: the revision on mainline corresponding to the earliest occurance of the bug?
100[2008-07-30 22::07:27] matthew-_: yes, that's the ideal situation
101[2008-07-30 22::09:18] BSP_: i see
102[2008-07-30 22::09:44] nominolo: wouldn't it be the same with darcs?
103[2008-07-30 22::10:04] BSP_: you can cherry pick patches from another repo just fine
104[2008-07-30 22::10:23] nominolo: if you have dependent patches that touch other parts, etc
105[2008-07-30 22::10:38] matthew-_: if you do branch per feature then you might be able to identify "the bug is with this feature, so I'll fix it in the branch for that feature". That would create a new head in that branch, which would then have to be merged with whatever heads are relevant.
106[2008-07-30 22::11:56] nominolo: i like lightweight branches. and i like if it's easier to have a building patch
107[2008-07-30 22::12:40] matthew-_: that way, the original branch is protected as the patches maintain their relationship with each other, and mainline is protected as you have this new branch with a single revision in it to act as the timemachine
108[2008-07-30 22::13:14] BSP_: heh
109[2008-07-30 22::13:48] nominolo: here's a commit history: o--o--o--o--o
110[2008-07-30 22::14:03] » benny99 left the chat room.
111[2008-07-30 22::14:26] nominolo: and here's a branch '--o--o
112[2008-07-30 22::14:42] matthew-_: this could get messy... use different letters for different branches - to give them names
113[2008-07-30 22::14:49] nominolo: too bad ascii art is not portable in irc
114[2008-07-30 22::14:55] matthew-_: quite
115[2008-07-30 22::15:02] nominolo: depends on how clients render text
116[2008-07-30 22::16:42] Pieter: most irc clients use fixed fonts
117[2008-07-30 22::17:29] nominolo: most /= all
118[2008-07-30 22::18:27] » bos left the chat room.
119[2008-07-30 22::18:39] » BSP__ joined the chat room.
120[2008-07-30 22::18:43] » TomMD joined the chat room.
121[2008-07-30 22::19:22] BSP__: nominolo: there does appear to be a macirssi preference for UTF8
122[2008-07-30 22::19:54] nominolo: try typing some special letter
123[2008-07-30 22::20:20] BSP__: λ
124[2008-07-30 22::20:20] nominolo: heh, it spells it out
125[2008-07-30 22::20:29] Pieter: I just wanted to drop a note that if you repack your git test repository, you can get it down to 40MB
126[2008-07-30 22::20:42] nominolo: Pieter: how?
127[2008-07-30 22::20:53] Pieter: nominolo: git repack -adf --window=50 --depth=50
128[2008-07-30 22::21:03] nominolo: interesting
129[2008-07-30 22::21:06] Pieter: the default pack parameters are a bit low for big repositories
130[2008-07-30 22::21:38] nominolo: atm, it's 65meg, when i uploaded it to github it was 65, then 90meg
131[2008-07-30 22::21:46] matthew-_: I have a 24 line diagram of what I was trying to explain. Should I flood or use hpaste or something else?
132[2008-07-30 22::21:48] nominolo: probably because they were caching the current status
133[2008-07-30 22::22:47] matthew-_: http://hpaste.org/9272
134[2008-07-30 22::22:48] Pieter: http://hpaste.org/9272
135[2008-07-30 22::24:32] Igloo: Is "Mercurial Distributed SCM (version 0.9.1)" too old for the GHC mercurial repo?
136[2008-07-30 22::24:42] matthew-_: so I suspect you're quite justified in turning round and saying, cherry picking is much easier, we're used to it, and it works.
137[2008-07-30 22::25:09] Igloo: And if not, what's going wrong here?
138[2008-07-30 22::25:10] lambdabot: Title: Index of /ghc.hg
139[2008-07-30 22::25:14] matthew-_: and I would say, I really value the DAG, the history it provides and the ease of navigating around it
140[2008-07-30 22::25:42] BSP_: Igloo: annoyingly you can't clone over http without a special hg server
141[2008-07-30 22::25:53] Pieter: matthew-_: why do you have to create a new branch in that example?
142[2008-07-30 22::26:12] Igloo: Hmm, OK; we'll have to do something about that if we want to use it
143[2008-07-30 22::26:21] matthew-_: Pieter, which branch - g'?
144[2008-07-30 22::26:28] Pieter: yes
145[2008-07-30 22::26:40] BSP_: Igloo: right. there's an apache module, or the command "hg serve" for personal use
146[2008-07-30 22::26:58] matthew-_: as the last line of text tries to say, because doing so would confuse the purpose of branch g
147[2008-07-30 22::27:15] BSP_: you're fixing g though
148[2008-07-30 22::27:15] Pieter: but if you merge g in mainline, g won't change
149[2008-07-30 22::27:18] matthew-_: branch g should only be concerned with that feature, and not with other changes that are going on at the same time
150[2008-07-30 22::27:40] Pieter: but then you can just merge branch g again?
151[2008-07-30 22::27:50] matthew-_: but then dealing with the merging (which implicitly brings in the results of branch f) should be kept separate
152[2008-07-30 22::28:29] Pieter: http://hpaste.org/9273
153[2008-07-30 22::29:04] Igloo: hg clone ssh://darcs.haskell.org//home/darcs/ghc.hg
154[2008-07-30 22::30:00] BSP_: Igloo: hmm, interesting
155[2008-07-30 22::30:10] matthew-_: Pieter: yep, sorry I dunno what smack I'm on. you're entirely right:)
156[2008-07-30 22::30:21] Pieter: :)
157[2008-07-30 22::30:25] BSP_: Igloo: huh, my darcs.haskell.org account has stopped working for some reason.. it's asking for a password (I just have public key). know why that might be?
158[2008-07-30 22::30:45] matthew-_: if f and the fix to g have conflicting patches then it'll be a manual merge, but that's all
159[2008-07-30 22::31:04] Igloo: BSP_: Username?
160[2008-07-30 22::31:08] BSP_: Igloo: mbolingbroke
161[2008-07-30 22::31:50] nominolo: mine works
162[2008-07-30 22::31:51] BSP_: Igloo: by the way, i made the repo with hg v1.0.1, so it might be using a different format
163[2008-07-30 22::31:56] matthew-_: BSP_: ahh, that's you! did you not get our email about AH the other day?
164[2008-07-30 22::32:06] Igloo: BSP_: Your authorized_keys2 is empty
165[2008-07-30 22::32:23] BSP_: Igloo: huh, ok.. it worked last friday (simon marlow set it up)
166[2008-07-30 22::32:51] » andyjgill joined the chat room.
167[2008-07-30 22::32:59] BSP_: matthew-_: yes, sorry i haven't replied yet, i was mulling over whether to come :)
168[2008-07-30 22::33:18] Igloo: BSP_: Please
169[2008-07-30 22::33:31] nominolo: how often is AH?
170[2008-07-30 22::33:38] matthew-_: fair enough. well there's some interest in your GHC Plugins SoC work, and if you could make it on the Saturday, we have a slot reserved for you to give a talk
171[2008-07-30 22::33:38] Igloo: Once a year
172[2008-07-30 22::34:03] nominolo: oh, ok
173[2008-07-30 22::34:28] matthew-_: nominolo: but, but, but... I made green lambdas!
174[2008-07-30 22::34:34] nominolo: ugh
175[2008-07-30 22::34:53] BSP_: Igloo: can you see my dcc file transfer? or should i try another communicationschannel?
176[2008-07-30 22::35:16] Igloo: Can you e-mail it please?
177[2008-07-30 22::35:31] matthew-_: nominolo: hmm. I live in London, thus have forgotten what colour grass green is
178[2008-07-30 22::36:04] nominolo: what colour is central park grass?
179[2008-07-30 22::36:11] Igloo: wonders where grass green came from
180[2008-07-30 22::36:18] nominolo: last time i've been there it was greenish
181[2008-07-30 22::36:44] Igloo: Uh huh :-)
182[2008-07-30 22::36:59] nominolo: which, i guess, filters red light
183[2008-07-30 22::37:24] BSP_: ;)
184[2008-07-30 22::37:56] nominolo: well, almost: http://en.wikipedia.org/wiki/Chlorophyll
185[2008-07-30 22::37:56] lambdabot: Title: Chlorophyll - Wikipedia, the free encyclopedia
186[2008-07-30 22::38:52] nominolo: i could even tell you why the sky is blue!
187[2008-07-30 22::39:17] matthew-_: well quite.
188[2008-07-30 22::39:56] nominolo: i hope it's better in kent
189[2008-07-30 22::41:17] matthew-_: Pieter: thinking about it, the reason to use a g' would be if f altered the validity of the fix in g. I.e. if the fix in g was correct for g, but actually had to be rewritten once f had been merged due to substantial changes that f made to m.
190[2008-07-30 22::42:12] Pieter: matthew-_: I think those changes mostly happen in the merge commit itself
191[2008-07-30 22::43:34] matthew-_: yeah, indeed, it depends how you like to do merges. Personally I like to use xxdiff where you can't actually edit the merge manually, you're just selecting which parts of which files make up the merged result.
192[2008-07-30 22::44:02] » zeno left the chat room.
193[2008-07-30 22::44:09] matthew-_: but then subsequent further modifications to g would force you to repeat work
194[2008-07-30 22::45:40] Igloo: BSP_: Should be fixed now
195[2008-07-30 22::46:36] BSP_: matthew-_: i guess the trade off there is that then you couldn't easily push the fix from g to a branch from m (e.g. v6.8) that came after g began but before the merge of m into g for the fix
196[2008-07-30 22::47:02] Igloo: No
197[2008-07-30 22::47:28] Pieter: matthew-_: yeah.. you can just work on mainline for subsequent fixes, and name that your new branch, if you wish
198[2008-07-30 22::47:56] BSP_: Igloo: quite from the wiki "Versions 0.9.1 and earlier of Mercurial cannot read repositories with the new layout directly"
199[2008-07-30 22::48:11] matthew-_: BSP: absolutely. In that case, the g and g' would be better because then you could take all of g, rebase it to the v6.8 head, and then merge there without having to deal with f/m at all
200[2008-07-30 22::49:17] Igloo: BSP_: What would the disadvantage be of using the older format?
201[2008-07-30 22::49:39] BSP_: Igloo: quote "The repository layout has been improved to guard against issues with case-insensitive filesystems and improve interoperability for repositories shared between Unix and Windows systems."
202[2008-07-30 22::51:16] Igloo: When was the next version released?
203[2008-07-30 22::51:24] BSP_: december 2006
204[2008-07-30 22::52:41] Igloo: Anyway, using > 0.9.1 in the near future is going to mean a little hoop jumping for anything running Debian, which is me (twice) and darcs.h.o
205[2008-07-30 22::53:05] BSP_: ah, i see
206[2008-07-30 22::53:08] matthew-_: backports?
207[2008-07-30 22::53:10] Igloo: And rebase is also "coming soon". Hmm.
208[2008-07-30 22::53:57] BSP_: i'd heard debians packages were old, but i didn't realise they could be years behind
209[2008-07-30 22::54:05] matthew-_: bzr has rebase.
210[2008-07-30 22::54:49] BSP_: it does, but i'm just a bit leery about using it since it seems to be fairly unpopular
211[2008-07-30 22::55:10] matthew-_: yeah. I'm not sure why though
212[2008-07-30 22::55:40] Pieter: http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism
213[2008-07-30 22::58:00] Igloo: The current Debian release was April 2007, so a December 2006 release was probably too late to go in, especially as you don't want bugs in something like that (presumably not too unlikely after a repo format change)
214[2008-07-30 22::58:35] matthew-_: I think that unless there are horror stories of bzr not working or the devs abandoning the project, it shouldn't be discarded. OTOH, I completely appreciate the "we want something that's going to be around in the future" argument
215[2008-07-30 22::58:47] BSP_: Pieter: isn't his example bzr workflow just a manual rebase? you can do just that with a sequence of strategically placed squash/edit commands in git
216[2008-07-30 22::58:55] » isaac1 joined the chat room.
217[2008-07-30 22::59:07] Igloo: bzr hasn't been rejected yet
218[2008-07-30 22::59:20] » nominolo_ left the chat room.
219[2008-07-30 22::59:21] BSP_: right, and bzr at least has canonical behind it
220[2008-07-30 22::59:21] Igloo: It was rejected at one stage, but got unrejected in the second #ghc meeting
221[2008-07-30 22::59:22] » nominolo left the chat room.
222[2008-07-30 22::59:29] Pieter: BSP_: with his trick, I think the commit will be a merge, where you retain all the previous flawed commits
223[2008-07-30 22::59:45] matthew-_: yeah, canonical who are rapidly loosing any good will from "the community"...
224[2008-07-30 22::59:56] Pieter: not sure though, I don't really get bazaar
225[2008-07-30 23::00:14] dons: bzr's less used that darcs.
226[2008-07-30 23::00:27] Pieter: bazaar has a small but very vocal user base
227[2008-07-30 23::00:34] matthew-_: so's monotone, but I've been happy with it for years ;)
228[2008-07-30 23::00:42] » nominolo joined the chat room.
229[2008-07-30 23::01:31] matthew-_: Pieter: I think bzr just has a couple of modes which hg doesn't, like the bound repo, which is useful for people who want to work a la cvs/svn, but can otherwise be ignored
230[2008-07-30 23::02:34] dons: right. it has a brand.