IRC_Meetings: ghc-metting-2008-07-23.log

File ghc-metting-2008-07-23.log, 22.7 KB (added by nominolo, 6 years ago)

GHC Meeting 2008-07-23 (timestamps in UTC+2), Topic: Version Control System for GHC

Line 
1
2[17:01] JaffaCake:
3hi all!
4[17:01] BSP_:
5afternoon!
6[17:02] JaffaCake:
7so, welcome to the #ghc meeting
8[17:02] JaffaCake:
9I thought today we could talk about version control systems
10[17:03] JaffaCake:
11we're still having issues with darcs, particularly on Windows
12[17:03] BSP_:
13have you investigated upgrading to the darcs2 format at all?
14[17:03] JaffaCake:
15I've tried an experimental conversion, but we haven't used it in anger yet
16[17:04] JaffaCake:
17if we stick with darcs, we'll certainly have to make that switch, becasue the darcs2 format fixes many of the bugs
18[17:05] TMD:
19Is there a solid idea of which darcs + windows bugs are left after a switch?
20[17:05] dcoutts:
21my (humble) opinion is that we should try darcs2 before abandoning darcs completely
22[17:05] JaffaCake:
23the main problem with switch VCs is that we also have all the library repos
24[17:05] JaffaCake:
25s/switch/switching
26[17:05] Igloo:
27We should also work out when a good time to switch (either to darcs2 or something else) is
28[17:05] JaffaCake:
29when we have the fewest active branches, presumably
30[17:05] Igloo:
31I think that just before we fork the 6.10 branch is probably best
32[17:06] nominolo:
33i have a lot of problems with darcs
34[17:06] JaffaCake:
35I believe tailor can recreate branches, even for a darcs2 conversion
36[17:06] Igloo:
37As most of the 6.10 work should be done by then, so VC issues aren't as important
38[17:06] nominolo:
39case-sensitivity issues, looping darcs on ./darcs-all, no bisect
40[17:07] Igloo:
41nominolo: Have you had looping problems since the bandwidth to monk was turned up?
42[17:07] JaffaCake:
43people have lost a lot of time to darcs
44[17:07] nominolo:
45Igloo: yes
46[17:07] BSP_:
47the merge bugs are what are killing me..
48[17:07] nominolo:
49yesterday
50[17:07] • Igloo
51doesn't understand nominolo's problems
52[17:07] nominolo:
53right, having to avoid confilcts is a PTIA
54[17:07] nominolo:
55*PITA
56[17:07] mainland (n=mainland@eecs-60-dhcp10.eecs.harvard.edu) joined the chat room.
57[17:07] JaffaCake:
58yes, definitely
59[17:08] JaffaCake:
60took me a whole day to merge my parallel GC branch
61[17:08] JaffaCake:
62and there were only 3 minor conflicts
63[17:08] nominolo:
64ouch
65[17:08] BSP_:
66wow
67[17:08] JaffaCake:
68just that one of the conflicts was in an early patch, so I had to replay the whole history
69[17:09] nominolo:
70i tried to convert the ghc repo to darcs2 format a few days ago.  except for warnings about lossy conversion (conflicts) i didn't find any problems
71[17:09] JaffaCake:
72can we trust darcs2 enough?
73[17:09] BSP_:
74i did see some complaints about performance regressions in the darcs bug tracker from the GHC team
75[17:09] BSP_:
76for the darcs2 format, that is
77[17:09] JaffaCake:
78darcs2 is definitely slower
79[17:10] JaffaCake:
80I did a local get yesterday, and it takes forever
81[17:10] JaffaCake:
82no idea why
83[17:10] nominolo:
84oh dear
85[17:11] JaffaCake:
86I assume git is the main alternative
87[17:12] Deewiant:
88mercurial would be nicer for windows users
89[17:12] BSP_:
90is it possible to do an incremental switch to darcs2, where we can synchronise patches between the old and new formats? i guess not, but i'm not massively well informed
91[17:12] JaffaCake:
92unless anyone wants to argue for mercurial or bzr?
93[17:12] nominolo:
94i have personally tried git and can say that is has enough features to be useful, and the #git channel seemed very helpful
95[17:12] JaffaCake:
96BSP_: I don't think so, no
97[17:12] matthew-_:
98I read through the mercurial and bzr tutorials over the last couple of days. They seem pretty evenly matched
99[17:12] Deewiant:
100bzr used to be slow, don't know about nowadays
101[17:13] nominolo:
102i think it is more complicated in some cases
103[17:13] JaffaCake:
104I couldn't see how to do things like unrecord and amend-record in mercurial
105[17:13] JaffaCake:
106except for the most recent commit
107[17:13] Deewiant:
108I've never had a need for that but I think that's what the mqueue extension is for
109[17:14] JaffaCake:
110it's very useful to be able to modify your history
111[17:14] JaffaCake:
112before sharing it, that is
113[17:14] matthew-_:
114could you explain why that is better than just adding an extra revision that fixes the mistake?
115[17:15] dcoutts:
116matthew-_: it makes you look like an uber hacker who designs perfectly from day one ;-)
117[17:15] JaffaCake:
118that could cause spurious conflicts later
119[17:15] Deewiant:
120yes, http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension seems to be it
121[17:15] lambdabot:
122Title: MqExtension - Mercurial
123[17:16] ttt-- (n=ubuntu@78-23-117-225.access.telenet.be) left the chat room. (Read error: 110 (Connection timed out))
124[17:16] JaffaCake:
125thanks Deewiant
126[17:17] Deewiant:
127but you can't mess around with anything in "prehistory" in Mercurial, which I think is a philosophical difference with git?
128[17:17] nominolo:
129rewriting too early isn't exactly safe in Git either
130[17:17] Deewiant:
131i.e. once you're done with the queues and you've made a proper commit, it's final
132[17:17] nominolo:
133at least i encountered some bugs there
134[17:17] Deewiant:
135(except for rollback which can undo the latest)
136[17:17] JaffaCake:
137matthew-_: so maybe I make more mistakes than average :) but I often find that I forgot to include something in a patch.  If I make two separate patches, then it's harder for somone else to know that the patches should go together.
138[17:18] matthew-_:
139JaffaCake: but with branch per bug dev model then I tend to treat branches as atomic units
140[17:18] nominolo:
141Deewiant: if you want to do things like bisect it's nice to have every version be correct
142[17:18] nominolo:
143ie, buildable
144[17:18] Deewiant:
145true
146[17:19] matthew-_:
147I guess it depends on how often you merge selected revisions rather than branches, or do cherry picking
148[17:19] JaffaCake:
149we do a lot of cherry picking
150[17:19] nominolo:
151oh, i meant to tell that to matthew-_
152[17:20] JaffaCake:
153but cherry picking isn't always easy with darcs either, particularly when you want to cherry pick a patch without its dependencies
154[17:20] JaffaCake:
155that works much better in git
156[17:21] Deewiant:
157bos wrote the Mercurial book so I suppose he could answer related questions fairly well :-)
158[17:21] JaffaCake:
159yep, true
160[17:22] nominolo:
161@seen bos
162[17:22] lambdabot:
163bos is in #ghc and #haskell. I don't know when bos last spoke.
164[17:22] bos:
165you can turn a committed change back into a patch if you  need to
166[17:22] BSP_:
167do we have any information on the relative adoption of bzr, hg and git?
168[17:22] JaffaCake:
169so if we were to switch, what happens to the library repos?
170[17:22] BSP_:
171because what i'm most concerned about is that the system will be actively maintained for some time to come
172[17:22] Deewiant:
173git > hg > bzr from what I understand
174[17:22] nominolo:
175BSP_: according to popcon, git is far ahead
176[17:22] Deewiant:
177I think bzr's quite rare, actually
178[17:22] bos:
179git has about 2x the number of users of hg, and only one significant project uses bzr.
180[17:23] JaffaCake:
181that rules out bzr, I think
182[17:23] matthew-_:
183quoting from: http://www.lshift.net/blog/2008/04/30/choosing-a-new-version-control-system
184[17:23] lambdabot:
185Title: LShift Ltd. » Choosing a new version control system, http://tinyurl.com/5tjklc incompatible encoding
186[17:23] matthew-_:
187"Git is used most famously by the Linux kernel, Bazaar by Ubuntu’s Launchpad development centre, and Mercurial by the Java and Mozilla projects"
188[17:23] JaffaCake:
189bos: so what's the situation with file/directory renames in hg?
190[17:23] bos:
191JaffaCake: should all work fine.
192[17:24] JaffaCake:
193but is it based on heuristics like git, or native like darcs?
194[17:24] bos:
195it's not based on heuristics.
196[17:24] JaffaCake:
197so it maintains accurate history of renames?
198[17:24] bos:
199yes.
200[17:24] JaffaCake:
201ok, thanks
202[17:25] JaffaCake:
203I'll try to break it later :)
204[17:25] bos:
205you have to tell it that you're renaming something of course.
206[17:25] JaffaCake:
207sure
208[17:25] nominolo:
209mercurial also seems more windows-friendly than git
210[17:25] Deewiant:
211yes, that's my main reason for recommending it
212[17:25] bos:
213it's also much easier to learn.
214[17:25] nominolo:
215git has git rename, too
216[17:25] nominolo:
217you only can't rename an empty directory
218[17:26] Deewiant:
219you can't even track an empty directory in Mercurial
220[17:26] nominolo:
221and there's bitbucket, hg also has something similar to github
222[17:26] Deewiant:
223which is perhaps somewhat annoying but not significantly so
224[17:26] bos:
225right. neither git nor mercurial track directories explicitly.
226[17:26] JaffaCake:
227git doesn't track renaming history, it tries to reconstruct it
228[17:27] bos:
229correct.
230[17:27] JaffaCake:
231it's quite easy to construct an example that goes wrong
232[17:27] JaffaCake:
233I did it on my first try
234[17:27] nominolo:
235oh, ok
236[17:27] Deewiant:
237good to know, I've always been wary of git in that regard :-)
238[17:27] JaffaCake:
239but adding some garbage to the files made it work again, because it detected the rename
240[17:28] nominolo:
241how does mercurial do merges?
242[17:28] • bos
243`ap` shower
244[17:28] bos:
245three-way, interactive if needed.
246[17:28] Deewiant:
247with an external proggy.
248[17:28] nominolo:
249ok. same as git then
250[17:29] nominolo:
251i guess mercurial has something like bisect as well?
252[17:29] JaffaCake:
253good support for renaming would push me towards hg, but I'd really like to be able to fiddle with the history
254[17:29] dbueno (n=dbueno@cpe-69-202-89-145.twcny.res.rr.com) left the chat room. (Read error: 110 (Connection timed out))
255[17:29] BSP_:
256in what ways is git windows unfriendly? in that it requires cygwin? but we need that for the GHC build anyway..
257[17:30] MyCatVerbs:
258BSP_: it's reputed to be very slow on Windows.
259[17:30] JaffaCake:
260git might be more windows-friendly than darcs :)
261[17:30] Igloo:
262Is bisect like darcs trackdown? If so I'm not convinced that it is useful
263[17:30] MyCatVerbs:
264BSP_: naturally the author isn't particularly interested in optimizing that particular case. ;P
265[17:30] nominolo:
266Igloo: yes
267[17:30] nominolo:
268Igloo: it uses binary search
269[17:30] BSP_:
270MyCatVerbs: right ;-) but wikipedia claims: "However, the recent rewriting of many shell commands in C have resulted in significant speed improvement on Windows"
271[17:31] JaffaCake:
272MyCatVerbs: I heard rumours it was getting faster, they rewrote more of it in C
273[17:31] Deewiant:
274JaffaCake: ah, there's also http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension apparently
275[17:31] lambdabot:
276Title: TransplantExtension - Mercurial, http://tinyurl.com/2mdrc6
277[17:31] nominolo:
278well, Git isn't very windows-friendly by culture alone.  i don't think that will change soon
279[17:31] MyCatVerbs:
280BSP_, JaffaCake: oh, cool. I guess that was only to be expected, in the longer run.
281[17:32] MyCatVerbs:
282Actually, come to think of it, if they used to use shell scripts everywhere, no wonder it was slow on Windows.
283[17:32] JaffaCake:
284Deewiant: extensions are all very well, but they don't make for a coherent UI
285[17:32] nominolo:
286ah, so hg has a rebase command
287[17:32] Deewiant:
288I think Mercurial extensions are really easy to use, actually
289[17:33] Deewiant:
290just enable it in .hgrc and then the corresponding "hg foo" command works.
291[17:33] MyCatVerbs:
292What with the much-heavier processes and difficulty of supporting fork() and exec() efficiently on Windows - Hell, pretty much every single line that passes through the 'terp has to do both.
293[17:33] nominolo:
294most of git commands are extensions, too
295[17:33] JaffaCake:
296ok, fair enough
297[17:34] nominolo:
298their are just shell scripts on top of the core commands
299[17:34] BSP_:
300if git and hg are fairly comparable feature wise, whats the speed like?
301[17:34] JaffaCake:
302comparable :)
303[17:34] nominolo:
304hg is slightly slower
305[17:34] BSP_:
306git seems to have a reputation as the fastest
307[17:34] nominolo:
308but, mostly comparabel
309[17:34] Deewiant:
310I think it varies per operation
311[17:34] Deewiant:
312depending on what blog's benchmark you look at, of course :-P
313[17:35] nominolo:
314it would probably only really matter if ghc reaches 1M SLOC
315[17:35] nominolo:
316or more
317[17:35] matthew-_:
318well Linus wanted git to be as fast as bitkeeper was/is. So the inital designs were very heavily optimised
319[17:35] nominolo:
320which i hope will never happen
321[17:35] JaffaCake:
322we can't be that far off 1M if you count everything
323[17:35] nominolo:
324bos: how well does mercurial handle sub-modules?
325[17:36] nominolo:
326JaffaCake: well, the evil mangler will hopefully go
327[17:36] MyCatVerbs:
328BSP_: for most code bases, they're both fast enough that you don't care about the speed, so worry about feature sets instead. :)
329[17:36] nominolo:
330bos: for example for bisect/trackdown we need to link ghc and the core-libs, otherwise it's useless
331[17:37] nominolo:
332(since different library versions don't build with certain ghc versions and vice versa)
333[17:37] BSP_:
334nominolo: can git handle that?
335[17:38] nominolo:
336not nicely (yet), but you can write some scripts
337[17:38] Igloo:
338I'm not sure if we can change the libraries. We'd have to get agreement from hugs etc first
339[17:39] JaffaCake:
340yeah
341[17:39] nominolo:
342oh. hm.
343[17:39] JaffaCake:
344and Cabal
345[17:40] nominolo:
346ok.  so where are we now?
347[17:40] JaffaCake:
348we'd probably be stuck with needing to use two VCSs
349[17:41] nominolo:
350is there a way to have a reliable bridge?
351[17:41] BSP_:
352what problems can you forsee that causing?
353[17:41] nominolo:
354using, say, tailor?
355[17:41] Igloo:
356I don't think bridges are plausible
357[17:42] JaffaCake:
358BSP_: no technical problems, just hard to use two different tools
359[17:42] Igloo:
360The only problem that 2 VCSs would cause is that we'd keep typing the wrong thing
361[17:42] matthew-_:
362context sensitive wrappers?
363[17:42] JaffaCake:
364yep
365[17:42] Igloo:
366Maybe, if the VCSs' features map well enough
367[17:43] • JaffaCake
368notes that hg is the easiest to type, followed by git, then darcs
369[17:43] thoughtpolice:
370nominolo: there's some mingw versions of git for windows that I had some good experiences with
371[17:43] bos:
372hg has partial submodule support, which i'm working on.
373[17:43] thoughtpolice:
374the main catch was that I think you had to run git-gc a little more frequently since garbage could build up easier
375[17:43] Igloo:
376JaffaCake: But I already have e.g. p aliased to (roughly) darcs pull -p, so that's easiest for me!
377[17:44] nominolo:
378JaffaCake: i always type "git" when i want to type "get".. so that's a con ;)
379[17:44] bos:
380Igloo: dons tells me you've been looking into organisations like SFC and SPI for haskell.org help.
381[17:44] bos:
382Igloo: i've done quite a bit of work with the SFC and SFLC, and i'm very happy with them. i'll be meeting various of their number during the week here.
383[17:45] bos:
384Igloo: let me know if you want anything said.
385[17:45] Igloo:
386bos: OK, thanks. Hopefully I'll be in touch soon
387[17:46] • bos
388off to breakfast
389[17:47] BSP_:
390right, so what is the consensus on actually moving off darcs? are we going to do it?
391[17:47] JaffaCake:
392so another problem with staying with darcs is that annotate still doesn't work (in the sense that it takes several minutes to give a result)
393[17:48] JaffaCake:
394I use the git repository for annotate
395[17:48] nominolo:
396yes, and getting/pulling doesn't seem faster with v2
397[17:48] nominolo:
398JaffaCake: you have your own git repo?
399[17:48] JaffaCake:
400I'm using yours :)
401[17:48] nominolo:
402JaffaCake: oh, that's outdated
403[17:48] JaffaCake:
404the one from darcs.haskell.org
405[17:48] nominolo:
406because the update hook doesn't run
407[17:49] JaffaCake:
408right, but I'm usually not interested in recent history
409[17:49] nominolo:
410ah, i see
411[17:49] JaffaCake:
412I can get that easily enough from darcs
413[17:49] JaffaCake:
414with darcs changes | grep
415[17:49] nominolo:
416ok.  so i haven't tried mercurial, but i would be fine with git
417[17:50] nominolo:
418from what i hear hg would be fine, too
419[17:50] JaffaCake:
420anyway we can use the new git conversion tool that's much faster, right?
421[17:50] nominolo:
422probably, i didn't try to build it
423[17:50] BSP_:
424have we got a hg conversion of ghc anywhere?
425[17:50] nominolo:
426it requires patching darcs head
427[17:50] JaffaCake:
428BSP_: not that I'm aware of
429[17:51] JaffaCake:
430so yes, looks like we need to do an eval of hg too
431[17:51] JaffaCake:
432at this stage I'm tending towards switching... is anyone strongly opposed?
433[17:53] JaffaCake:
434I guess not!
435[17:54] dcoutts:
436so what's the decision? move to
437[17:54] nominolo:
438*crickets chirping*
439[17:54] • dcoutts
440has been busy announcing the OpenSPARC project
441[17:54] JaffaCake:
442dcoutts: we need to look at hg too
443[17:54] Igloo:
444So I think that for each contender we need someone to convert the GHC repo and translate a list of darcs commands so we can try it out?
445[17:55] JaffaCake:
446Igloo: right
447[17:55] dcoutts:
448JaffaCake: so the decision is to switch from darcs1, and now we evaluate a short list of options?
449[17:55] JaffaCake:
450I think that would be the best plan, yes
451[17:56] JaffaCake:
452I don't think switching to darcs2 will buy us enough
453[17:56] JaffaCake:
454we'll still have performance problems and Windows bugs
455[17:57] dcoutts:
456unless someone fixes them
457[17:57] dcoutts:
458sigh
459[17:57] MyCatVerbs:
460Hang on, GHC still uses darcs1?
461[17:57] nominolo:
462which is unlikely to happen soon
463[17:57] JaffaCake:
464MyCatVerbs: yes
465[17:58] MyCatVerbs:
466Damn.
467[17:58] JaffaCake:
468dcoutts: I can see the Windows bugs being fixed, but not the performance issues
469[17:58] MyCatVerbs:
470Out of curiosity, have you tried darcs2 against ghc?
471[17:58] Igloo:
472Are you talking about "whatsnew is slow" or "conflict resolution is exponential"?
473[17:58] • MyCatVerbs
474winces at the mention of the latter.
475[17:58] JaffaCake:
476Igloo: the first kind
477[17:58] dcoutts:
478JaffaCake: aye, probably so
479[17:59] JaffaCake:
480Igloo: annotate is too slow to use, and everything else is just slow
481[17:59] dons:
482http://www.reddit.com/r/programming/comments/6t3pa/Sun_Microsystems_funding_Haskell_on_multicore/ announce is out.
483[17:59] lambdabot:
484Title: Sun Microsystems funding Haskell on multicore OpenSPARC! : programming, http://tinyurl.com/5p7vjj
485[17:59] matthew-_:
486ironically, the continual development of GHC is likely to make darcs a more viable choice ;)
487[18:00] JaffaCake:
488Igloo: so is conflict resolution still exponential in darcs2?
489[18:00] MarcWebe1 (n=marc@pD9E0A63E.dip.t-dialin.net) joined the chat room.
490[18:00] JaffaCake:
491with the darcs2 format, I mean
492[18:00] MyCatVerbs:
493JaffaCake: no, that bug was squished hard. It was specifically a large part of the raison d'etre for darcs2.
494[18:01] nominolo:
495matthew-_: how?
496[18:01] Igloo:
497Yeah, I understand that it's not a problem with the new format, although i haven't tried it myself
498[18:02] matthew-_:
499nominolo: it'll make darcs faster, due to better optimisations. Albeit I suspect too slowly
500[18:02] nominolo:
501matthew-_: that'll be maybe 5% / year.  in the best case
502[18:02] matthew-_:
503quite ;)
504[18:03] BSP_:
505nominolo: and that's assuming its compute bound...
506[18:03] JaffaCake:
507ok, I have to go, thanks folks!
508[18:03] • dcoutts
509points out http://haskell.org/opensparc/
510[18:03] JaffaCake:
511dcoutts: nice
512[18:03] nominolo:
513with pictures!
514[18:03] BSP_:
515does anyone want to volunteer for the hg conversion? :)
516[18:04] dcoutts:
517any student ghc hackers interested in working on GHC's native code gen for SPARC ?
518[18:04] dcoutts:
519nominolo: of course :-)
520[18:04] nominolo:
521too bad i won't have time
522[18:04] dcoutts:
523:-(
524[18:04] dcoutts:
525doesn't all have to be in one go
526[18:05] nominolo:
527i'll have to talk to simon thompson then
528[18:10] bringert (n=bringert@3-1-5-7a.gva.gbg.bostream.se) joined the chat room.
529[18:10] bringert (n=bringert@3-1-5-7a.gva.gbg.bostream.se) left the chat room. (Client Quit)
530[18:15] benny99 (n=bebenny@p5486F483.dip.t-dialin.net) joined the chat room.
531[18:15] benny99 (n=bebenny@p5486F483.dip.t-dialin.net) left the chat room. (Read error: 104 (Connection reset by peer))
532[18:16] TMD (n=tmdubui@144.51.26.41) left the chat room.
533[18:16] MarcWeber (n=marc@pD9E0994B.dip.t-dialin.net) left the chat room. (Read error: 110 (Connection timed out))
534[18:16] nominolo:
535is someone responsible for putting the log somewhere?
536[18:17] dejones (n=donnie@74-131-36-199.dhcp.insightbb.com) joined the chat room.
537[18:19] dolio (n=dolio@216.68.186.59) left the chat room. (Read error: 104 (Connection reset by peer))
538[18:19] dolio (n=dolio@216.68.186.59) joined the chat room.
539[18:20] BSP_:
540nominolo: igloo did the last one (http://hackage.haskell.org/trac/ghc/wiki/IRC_Meetings) but feel free :)
541[18:20] lambdabot:
542Title: IRC_Meetings - GHC - Trac
543[18:21] malcolmw:
544personally, I would be very sorry to see darcs abandoned by ghc, but then I don't actually trip over any of its foibles on a regular basis
545[18:23] Igloo:
546Oh, yes, please put up a log on that page if you have one
547[18:23] Igloo:
548malcolmw: That's basically my opinion, too
549[18:23] mainland:
550just out of curiosity---and please don't bludgeon me here---but what about switching to a non-distributed version control system?
551[18:24] Igloo:
552That's a no-go IMO
553[18:24] thoughtpolice:
554no offline commits seem to be the biggest issue in that case
555[18:24] thoughtpolice:
556imo, anyway
557[18:24] mainland:
558but one can always use something like darcs offline
559[18:24] mainland:
560do a subversion checkout, then a darcs init...
561[18:24] bos:
562bleugh.
563[18:26] BSP_:
564you could use something like svk, to build a distributed VCS on top of SVN
565[18:26] BSP_:
566but i'd kind of prefer something more mainstream :)
567[18:27] mainland:
568you can use whatever tool you want on top of SVN
569[18:27] thoughtpolice:
570git-svn would work too
571[18:27] mainland:
572darcs, got, hg, whatever
573[18:27] Igloo:
574mainland: And what's the advantage?
575[18:27] thoughtpolice:
576but regardless the cost-benefit seems too unbalanced
577[18:27] thoughtpolice:
578you can reap just as many benefits from using solely distributed version control if you ask me
579[18:28] mainland:
580sure, if they worked well
581[18:28] thoughtpolice:
582they do, darcs in particular just has problems
583[18:28] bos:
584it would be very silly to switch from a DVCS to SVN.
585[18:29] thoughtpolice:
586that's nothing against darcs
587[18:29] thoughtpolice:
588for small stuff it works well, and it's working on a hard problem
589[18:29] bos:
590even the original authors of SVN use hg for most of their revision control work now.
591[18:29] nominolo:
592BSP_: ok, your log format is nicer
593[18:29] mainland:
594will people really not have just as many problems, though perhaps different, with any other DVCS?
595[18:29] nominolo:
596no
597[18:29] bos:
598no.
599[18:30] nominolo:
600the problems with darcs are mostly performance
601[18:30] thoughtpolice:
602darcs has inherent issues that inhibit it's flexibility and performance
603[18:30] nominolo:
604and some missing features
605[18:30] thoughtpolice:
606especially for large stuff
607[18:30] Svrog (n=ivan@d5153048F.access.telenet.be) left the chat room. ("Ex-Chat")
608[18:31] nominolo:
609darcs is nice and simple for smaller projects
610[18:32] thoughtpolice:
611imo if you want a vcs that can sustain 'high load,' darcs isn't it; not yet, anyway.
612[18:32] nominolo:
613BSP_: can you upload your log, please?
614[18:33] nominolo:
615i'll try to find out why mine didn't generate a log file
616[18:33] BSP_:
617nominolo: i'm trying to work out how to get colloquy to generate a plain text log file :)
618[18:33] nominolo:
619heh, me too
620[18:34] waern (i=53915df2@gateway/web/ajax/mibbit.com/x-70ab84da77ee7d90)  left the chat room. ("http://www.mibbit.com ajax IRC Client")
621[18:34] BSP_:
622actually i didn't even turn on the logging so this is fruitless