Time and Location
Thursday, 2008-01-24 in #adium-devl
| PDT | MDT | CDT | EDT | CEST |
| 6 PM | 7 PM | 8 PM | 9 PM | 3 AM |
Agenda
- Version control—primarily, DistributedVersionControl
Log
18:00:55: <Catfish_Man> hokay, 6 o' clock
18:01:15: <Catfish_Man> we don't have an agenda, and it looks like comcast is still messing with evan, so anyone in particular want to go first/
18:01:16: <Catfish_Man> *?
18:01:29: <boredzo> Sure.
18:01:49: <boredzo> I've used all of them briefly, and I can tell you that Bazaar is slooow.
18:02:03: <hal2k> so is mtn
18:02:14: <Catfish_Man> bzr 1.1 came out on the 15th, btw
18:02:40: <Catfish_Man> boredzo: did you get a feel for how much of it was startup overhead and how much was processing?
18:02:43: <Catfish_Man> 'cause the former can be avoided
18:03:04: <boredzo> ___
18:03:04: <boredzo> time bzr help > /dev/null %/Volumes/RAM Disk/foo(0)
18:03:04: <boredzo> bzr help > /dev/null 0.08s user 0.08s system 98% cpu 0.165 total
18:03:04: <boredzo> ___
18:03:04: <boredzo> time hg help > /dev/null %/Volumes/RAM Disk/foo(0)
18:03:04: <boredzo> hg help > /dev/null 0.03s user 0.04s system 98% cpu 0.063 total
18:03:24: <Catfish_Man> k, that definitely sounds like startup overhead
18:03:41: <boredzo> Here's an example of committing
18:03:44: <boredzo> bzr ci -m 'Foo' 0.18s user 0.15s system 99% cpu 0.337 total
18:03:47: <boredzo> hg ci -m 'Foo' 0.05s user 0.06s system 98% cpu 0.112 total
18:03:59: <elliott> :-\
18:04:09: <Catfish_Man> ok. So hg is definitely faster
18:04:26: <elliott> Does anyone big use bzr?
18:04:35: <Catfish_Man> boredzo: out of curiosity, what repo is that on?
18:04:48: <boredzo> Small repo I just created. I have no idea how that scales up
18:04:55: <Catfish_Man> (Having this meeting before getting clones of the adium repo in different vcs was perhaps not a good idea :( )
18:05:08: <boredzo> Didn't somebody make a Mercurial version of the Adium repo?
18:05:11: <boredzo> Perhaps Colin did?
18:05:14: <elliott> cbarrett did
18:05:20: <elliott> and then some other guy did a git one
18:05:24: <Catfish_Man> ofri probably
18:05:24: <elliott> i don't think we did bzr though
18:05:28: <boredzo> hg clone http://evilfork.com/hg/adium/trunk-only
18:05:29: <elliott> no it was someone on the list
18:05:32: <Catfish_Man> ah ok
18:05:37: <boredzo> elliott: That doesn't rule out ofri.
18:05:40: boredzo clones trunk-only
18:05:50: <elliott> boredzo: true, but I know it wasn't Ofri.
18:05:59: <cbarrett> back
18:06:01: <elliott> I just don't know his name and I am too lazy to look.
18:06:02: <Catfish_Man> I fully expect git to win speed comparisons
18:06:07: <cbarrett> I have an svn import
18:06:07: <Catfish_Man> it's pretty blindingly fast in my testing
18:06:10: <boredzo> BTW, doing this on my 64 MiB RAM disk probably won't work :D
18:06:15: <cbarrett> boredzo: That won't work.
18:06:16: <Catfish_Man> but it's unclear how much that matters
18:06:18: <elliott> The biggest concern I have is that bzr doesn't seem to be in widespread use
18:06:22: <boredzo> Catfish_Man: hg is *instant* as far as user-experience goes.
18:06:23: <cbarrett> Dreamhost blows.
18:06:32: <Catfish_Man> boredzo: I doubt that on a full adium repo
18:06:34: <boredzo> When you use an editor to specify the commit message, it's *done* the instant you exit the editor.
18:06:38: <cbarrett> Catfish_Man: it is trunk only.
18:06:39: <boredzo> Catfish_Man: Well, that's why I'm cloning it.
18:06:41: <boredzo> cbarrett: Thanks, BTW.
18:06:53: <Catfish_Man> boredzo: also, using a ramdisk is silly
18:07:01: <Catfish_Man> IO is the major overhead for VCS
18:07:02: <boredzo> Nah.
18:07:04: <elliott> git and hg both have some kind of commercial backing
18:07:06: <boredzo> Well, that may be
18:07:18: <boredzo> elliott: And bzr
18:07:21: <boredzo> (Canonical)
18:07:23: <boredzo> (Ubuntu)
18:07:24: <elliott> once again
18:07:26: <elliott> who uses bzr?
18:07:28: <elliott> ok
18:07:29: <boredzo> Ubuntu.
18:07:32: <Catfish_Man> Drupal
18:08:02: <cbarrett> To be fair, I have contacts at Canonical who are more than happy to assit us with bzr stuff.
18:08:05: <Catfish_Man> not seeing any other "huge" projects
18:08:11: <Catfish_Man> I mean, bitlbee and stuff
18:08:13: <boredzo> One problem with git is that git gc command. That could get to be a hassle.
18:08:14: <Catfish_Man> but they're pretty small
18:08:34: <Catfish_Man> yes. I'm not actually advocating git here, just saying I expect it to win speed competitions
18:08:38: <boredzo> Last I read, they were considering how to automate it. But they're not there yet.
18:08:41: <boredzo> Right.
18:08:49: <boredzo> Well, hg will kick plenty of ass in a speed test, too. :)
18:08:55: <elliott> ^
18:09:02: <elliott> They are both really really fast.
18:09:06: <boredzo> Indeed.
18:09:20: <boredzo> I wonder if hg gets stuff done while you're typing into the editor. That would be *really* smart.
18:09:23: <boredzo> (Parallel processing FTW)
18:09:40: <cbarrett> I can give whoever wants to play with it, my shell scripts and files for doing a continually updating trunk-only hg repository.
18:10:00: <cbarrett> I had it running on dreamhost just fine but I couldn't ever check it out because dremahost kills processes running for more than a few minutes.
18:10:14: <elliott> cbarrett: Thoughts on hg vis-a-vis your use of it at Mozilla?
18:10:37: <cbarrett> It's pretty good. I wrapped my head around how it works pretty quickly.
18:10:46: <cbarrett> It's certainly got limitations
18:10:48: <boredzo> hg has a shallow learning curve.
18:10:48: <Catfish_Man> we should get an svndump of the adium repo up somewhere to play with
18:10:55: <boredzo> Catfish_Man: svnsync is better
18:10:56: <cbarrett> Catfish_Man: I have one.
18:11:00: <Catfish_Man> fair enough
18:11:04: <boredzo> 1. You don't need a dump. 2. You can update it.
18:11:04: <cbarrett> an svnsync, rather.
18:11:09: <cbarrett> On evilfork.
18:11:12: <Catfish_Man> cbarrett: link?
18:11:14: <elliott> I think choosing something with a shallow learning curve should be important.
18:11:19: <cbarrett> Not web-acessible yet.
18:11:22: <Catfish_Man> ah ok
18:11:23: <boredzo> Catfish_Man: svn://svn.adiumx.com/... :)
18:11:25: <boredzo> Anybody can make one.
18:11:33: <boredzo> elliott: It is important, and easy.
18:11:34: <Catfish_Man> boredzo: I'd rather not put *more* load on our server :P
18:11:37: <cbarrett> boredzo: it's harmful to the svnserver though, expensive.
18:11:38: <boredzo> bzr or hg = shallow learning curve.
18:11:42: <boredzo> cbarrett: Only once.
18:11:48: <boredzo> As opposed to a huge svndump download *every* time.
18:11:52: <cbarrett> yeah, but four people :P
18:11:53: <cbarrett> anyway
18:12:01: <cbarrett> It's part of the "hg trunk-only mirror" package.
18:12:03: <Catfish_Man> elliott: yes. Like, SVK is right out
18:12:08: <elliott> Is anyone else concerned about bzr's only really main users being the people that make it and one other project?
18:12:22: <Catfish_Man> elliott: http://bazaar-vcs.org/WhoUsesBzr
18:12:27: <Catfish_Man> I was just listing large ones
18:12:32: <cbarrett> elliott: Not really.
18:12:33: <boredzo> I'm more concerned with it being slow. They say it's "fast enough", but I've seen faster.
18:12:33: :Server: alangh (n=alangh_@fire/developer/alangh) joined #adium-devl
18:12:54: <Catfish_Man> elliott: basically, there's two potential concerns with niche stuff. One is integration with the rest of the world, the other is reliability
18:13:03: <Catfish_Man> the latter I don't think is a concern (>10k automated tests, etc...)
18:13:04: <Catfish_Man> the former may be
18:13:05: <elliott> Well, I think there is a third.
18:13:15: <elliott> Which is how well used it is.
18:13:21: <Catfish_Man> well used?
18:13:22: <cbarrett> "well used"?
18:13:23: <elliott> i.e. How many people have made the switch we are proposing
18:13:33: <Catfish_Man> why is that a first-order advantage?
18:13:37: <Catfish_Man> it seems like it only plays into the first two
18:14:03: <boredzo> Well, there is "hey, we ran into this problem, and we read that you did too. What was the fix?"
18:14:10: <elliott> ^
18:14:14: <boredzo> But, if it's open-source, we can always ask the developers and/or UTSL.
18:14:19: <Catfish_Man> ok, so community documentation basically?
18:14:27: <hal2k> integration with trac is pretty important, too
18:14:28: <boredzo> Even assuming no documentation, and most of the VCSs are well-documented.
18:14:36: <boredzo> (bzr, hg, darcs, git all are)
18:14:46: <boredzo> hal2k: Right.
18:14:51: <boredzo> I think that's the next thing on the agenda.
18:14:54: <elliott> Well, we need to begin a process of elimination.
18:15:01: <alangh> tool integration with our environments (trac/xcode) is a first-order importance item in my eyes
18:15:03: <boredzo> How well do bzr and hg integrate with Trac?
18:15:10: <Catfish_Man> alangh: you use Xcode's integration?
18:15:10: <hal2k> xcode isn't important
18:15:12: <boredzo> alangh: I don't know of anything that doesn't work with Xcode.
18:15:19: <Catfish_Man> (I wasn't aware anyone here did is why)
18:15:20: <boredzo> Xcode's built-in SCM is shit with all VCSs.
18:15:42: <elliott> well, except svn.
18:15:46: <elliott> as of Leopard.
18:15:50: <alangh> hal2k: We shouldn't ignore xcode
18:15:59: <hal2k> alangh: why?
18:16:04: <elliott> People use Xcode's SCM?
18:16:10: <elliott> Apple doesn't even use it.
18:16:12: <elliott> and that's saying something.
18:16:17: <boredzo> elliott: That much is obvious.
18:16:22: <elliott> :P
18:16:30: <alangh> you might, I use the command line 99% of the time
18:16:31: <boredzo> I should have asked Blake to explain why it doesn't work.
18:16:37: <boredzo> alangh: We all do.
18:16:40: <cbarrett> Xcode's SCM stuff is frightening to use.
18:16:40: <boredzo> Make that 100%.
18:16:51: <dsymonds> for reference: http://repo.or.cz/w/adiumx.git
18:16:56: <elliott> there it is
18:17:06: <elliott> dsymonds would be the person I was referring to
18:17:11: <dsymonds> I'm lurking, just back from lunch
18:17:25: <Catfish_Man> k
18:17:32: <alangh> the #1 question I would ask is.... .Why Change? other than easier branch merging, I see no reason
18:17:47: <cbarrett> Easier branch merging is a pretty big win.
18:17:49: <Catfish_Man> alangh: .svn files, local commits and branches, easier merging
18:17:53: <boredzo> alangh: Better integration with Pidgin. If we get them to change over it too, we can integrate their repo with ours.
18:17:58: <elliott> O(1) merging.
18:17:59: <boredzo> Local commits are a big thing, too.
18:18:00: <Catfish_Man> every one of those has messed me up personally in the last 6 months
18:18:15: <alangh> local commits is a non issue
18:18:22: <boredzo> We don't all have Wi-Fi everywhere. I could go to a park with my laptop and commit all I want.
18:18:22: <alangh> we are always connected
18:18:26: <Catfish_Man> alangh: I am not
18:18:28: <boredzo> alangh: *You* may be.
18:18:34: <alangh> do not commit without testing
18:18:38: <boredzo> Who said I wouldn't?
18:18:40: <alangh> and this is an INTERNET application
18:18:42: <boredzo> er, that I would
18:18:45: <boredzo> (blah)
18:18:45: <Catfish_Man> alangh: I work on commutes
18:18:51: <Catfish_Man> alangh: and in basements sometimes
18:18:52: <alangh> so if you are not connected you cannot test and should not commit
18:18:54: <dsymonds> alangh: don't you want your personal testing development checkpointed and tracked?
18:18:55: <elliott> alangh: It's a bigger advantage that just the fact that you don't need the internet
18:19:01: <Catfish_Man> alangh: you're confusing commit with push
18:19:05: <boredzo> alangh: Correction: If you are not connected, you should not push to the master branch.
18:19:08: <Catfish_Man> local commits are harmless even when untested
18:19:15: <boredzo> Locally, you can commit all you want and not mess up anyone else.
18:19:16: <elliott> alangh: It's a very very very helpful mental association.
18:19:21: <elliott> to push changes locally
18:19:26: <boredzo> commit changes locally
18:19:29: <boredzo> push remotely
18:19:29: <alangh> my second point, any DVCS takes a simple checkin operation and replaces it with 2
18:19:36: <elliott> right, that one.
18:19:37: <Catfish_Man> alangh: bzr doesn't, necessarily
18:19:39: <alangh> more work = bad
18:19:42: <boredzo> alangh: Only if you push *every* time you commit.
18:19:43: <dsymonds> plus, local queries of repositories are much faster
18:19:48: <Catfish_Man> you can do a 'lightweight checkout' and treat it like svn
18:19:55: <Catfish_Man> and it'll commit+push
18:19:55: <boredzo> If you do multiple commits, then push, that extra cost goes down.
18:20:17: <alangh> well if I am the only advocate for not changing...
18:20:25: <boredzo> Don't let that dissuade you from making your case.
18:20:34: <alangh> never mind
18:20:45: <boredzo> Make your case, and we'll either rebut it or be convinced.
18:20:50: <boredzo> Everybody's opinion counts.
18:20:53: <alangh> I did in the email
18:20:57: <boredzo> Yeah, I know.
18:21:49: <boredzo> So, why else *shouldn't* we switch from svn?
18:22:06: <dsymonds> At least git-wise, Trac integration is weak
18:22:11: <alangh> it works, it is supported by our tools, and it is used througout the industry
18:22:20: <Catfish_Man> solid reasons
18:22:23: <cbarrett> There are obvious disadvantages, that have been discussed over and over. There are also advantages.
18:22:33: <cbarrett> The question is do the benefits outweigh the costs.
18:22:59: <alangh> when you force me to use a DVCS, it might as well be mtn (even though it is scary-ugly) but at least that way I won't have to use 2 of them
18:23:20: <boredzo> alangh: All DVCSs are better than mtn.
18:23:24: <Catfish_Man> oh, another question: WebKit maintains both git and svn repositories. Any reason we couldn't do that?
18:23:27: <boredzo> (With the possible exception of Arch. Never used it.)
18:23:31: <Catfish_Man> autosynced, afaik
18:24:29: <dsymonds> You wouldn't get the fullest benefit of git, I think; the svn users would not be able to do the proper branching/merging
18:24:31: <cbarrett> git-svn is quite nice, but the quesiton is how far does its support go.
18:24:40: <Catfish_Man> I didn't literally mean git there, btw
18:24:43: <Catfish_Man> that was just what they do
18:24:46: <Catfish_Man> I meant $vcs
18:24:56: <elliott> Well, git-svn is supposed to be pretty good.
18:24:57: <dsymonds> git-svn is quite well supported, but it still is limited by SVN's infrastructure to some degree
18:25:12: <dsymonds> take a look at the graphiclog of the import I did: http://repo.or.cz/git-browser/by-commit.html?r=adiumx.git
18:25:18: <Catfish_Man> dsymonds: limited by svn == limited to svn's level, or limited below svn's level?
18:25:23: <cbarrett> Their featuresets and repo structures are not the same -- we would need to say "SVN is the mirror, $VCS is the master" or the otherway around.
18:25:26: <dsymonds> Catfish_Man: the former
18:25:26: <Catfish_Man> 'cause "not worse" is all the svn users would expect
18:25:33: <cbarrett> And in that case, why bother?
18:25:44: <Catfish_Man> cbarrett: comfort level?
18:25:44: <dsymonds> you can see how the trunk vs. adium-1.2 branch merging is not nice
18:25:53: <boredzo> That's the thing about the learning curve.
18:26:02: <boredzo> If we switch to, say, darcs or mtn, then svn users need to relearn everything.
18:26:06: <boredzo> Which is why we're not doing that.
18:26:14: <boredzo> (definitely not darcs, anyway)
18:26:16: <elliott> so then we are down to three
18:26:22: <elliott> hg, git, bzr
18:26:23: <Catfish_Man> (everyone comfortable with that statement? I'm not hearing any objections)
18:26:24: <alangh> but I still have to learn mtn for libpurple work
18:26:26: <boredzo> If we switch to bzr or hg, or even git, there's overlap.
18:26:37: <boredzo> alangh: That's why we should get them to switch to whatever we pick. :)
18:26:41: <boredzo> And for the integration.
18:27:02: <cbarrett> (For casual people who are just testing, we should have people using automatic builds anyway, but that's a different issue)
18:27:06: <alangh> is the pidgin team even open to a switch to a new D
18:27:08: <alangh> DVCS
18:27:19: <Catfish_Man> tentatively so
18:27:37: <boredzo> Well, Richard Laager said they could be. Not like we asked the Pidgin team and they took a vote and said "yeah, whatever you guys want". We'll pick a DVCS, *then* ask them to switch to it.
18:27:44: <dsymonds> What does the pidgin team currently use?
18:27:48: <boredzo> dsymonds: Mtn
18:27:49: <elliott> mtn
18:27:50: <boredzo> (Monotone)
18:27:57: <elliott> which is terrible imo
18:28:02: <boredzo> Also known as "Download hugemongous database file, then undergo pain"
18:28:06: <boredzo> Or simply "Undergo pain"
18:28:08: <alangh> :)
18:28:09: <Catfish_Man> my experience with mtn is poisoned by only having used it on Windows
18:28:16: <Catfish_Man> through cygwin or whatever
18:28:22: <boredzo> Catfish_Man: My experience with mtn is poisoned by having used mtn.
18:28:29: <Catfish_Man> fair enough
18:28:39: <boredzo> (*ever* so briefly)
18:28:43: <cbarrett> I have not used mtn, but I have heard a lot of people having painful experiences with it -- though some have come to love it
18:28:51: <Catfish_Man> ok, so, bzr/hg/git/svn
18:28:58: <boredzo> cbarrett: rlaager is in the "love it" camp. But we may be able to show him the light.
18:29:09: <boredzo> He sounds open to change.
18:29:14: <cbarrett> *nod*
18:29:19: <cbarrett> I was there, remember? ;)
18:29:25: <boredzo> For some of it.
18:29:30: <boredzo> You weren't at the hotel pizza party. :)
18:29:33: <cbarrett> heh
18:29:35: <elliott> ok, we need to eliminate something else
18:29:38: <elliott> let's go let's go let's go :P
18:29:45: <boredzo> I say git. Now, what's wrong with git?
18:29:47: <boredzo> Aside from git gc.
18:29:56: <Catfish_Man> it is complicated as all hell, basically
18:30:00: <elliott> git is probably the most supported of the dvcses
18:30:02: <dsymonds> git-gc isn't so bad
18:30:07: <elliott> although it's also the most complex
18:30:09: <Catfish_Man> cogito was nice, when I tried it
18:30:13: <boredzo> Well, feature-packed. Isn't the common case pretty much the same as the others?
18:30:13: <Catfish_Man> I could vote for cogito, but it's dead
18:30:20: <Catfish_Man> boredzo: I found it wasn't
18:30:33: <Catfish_Man> it exposed more guts to the user's necessary mental model
18:30:35: <cbarrett> boredzo: you have to do an add before every commit.
18:30:38: <Catfish_Man> but, maybe I was doing it wrong!
18:30:47: <cbarrett> which is really confusing.
18:30:47: <dsymonds> cbarrett: not true
18:30:50: <boredzo> dsymonds: None of the other VCSs make such a demand.
18:30:53: <boredzo> cbarrett: Yeah, that too.
18:30:55: <boredzo> dsymonds: -a
18:30:58: <dsymonds> cbarrett: you can use "git commit -a"
18:30:58: <cbarrett> git commit -a does the add for you.
18:31:03: <boredzo> ci -a is still longer than ci.
18:31:05: <cbarrett> That's still doing an add, dsymonds.
18:31:08: <boredzo> (And I don't think git has ci, either)
18:31:08: <Catfish_Man> heh
18:31:19: <elliott> shrug
18:31:22: <elliott> i don't mind the -a
18:31:23: <boredzo> So: git commit -a, vs (bzr|hg) ci
18:31:24: <Catfish_Man> one criticism the bzr people had of git was that it auto-committed after a non-conflicting merge
18:31:32: <dsymonds> the adding is probably good for keeping cruft out
18:31:36: <Catfish_Man> (commit, not push)
18:31:43: <boredzo> Catfish_Man: Hm. Not sure I like that. But that could just be the svn user in me talking.
18:31:48: <cbarrett> Catfish_Man: Yeah, git pull autocommits after you pull in new revisions.
18:31:50: <cbarrett> hg does not.
18:31:52: <elliott> I agree with dsymonds
18:31:52: <boredzo> And bzr is basically svn distributed.
18:32:00: <dsymonds> cbarrett: use git-fetch if you don't want the automerge
18:32:17: <boredzo> pull is just fetch + commit, right?
18:32:22: <dsymonds> yeah
18:32:24: <dsymonds> no
18:32:29: <dsymonds> pull == fetch + merge
18:32:33: <boredzo> Runs git-fetch with the given parameters, and calls git-merge to merge
18:32:33: <boredzo> the retrieved head(s) into the current branch.
18:32:35: <elliott> adding is actually kind of nice. it's a good sanity check :shrug:
18:32:40: <boredzo> elliott: That's true.
18:32:47: <boredzo> That brings me to another requirement
18:32:48: <boredzo> record.
18:32:53: <boredzo> darcs has this and it is fucking wonderful.
18:32:58: <dsymonds> What's record?
18:33:00: <Catfish_Man> explain it please :)
18:33:03: <cbarrett> record is awesome.
18:33:05: <boredzo> dsymonds: You pick and choose every change you want or don't want.
18:33:11: <elliott> I believe git can do that
18:33:12: <elliott> I think
18:33:15: <dsymonds> git add -i
18:33:17: <boredzo> So you can mix changes in a single file, then not commit them all in one commit.
18:33:17: <elliott> ^
18:33:20: <dsymonds> "interactive add"
18:33:21: <cbarrett> You can pick which hunks of the diff go in.
18:33:24: <elliott> it's not as elegant as darcs
18:33:26: <cbarrett> mercurial has this.
18:33:27: <dsymonds> yeah, I do that all the time
18:33:27: <elliott> but git does do it
18:33:36: <cbarrett> (basiclly a clone of the darcs feature)
18:33:36: <boredzo> hg and git have it. bzr doesn't.
18:33:38: <elliott> bzr?
18:33:41: <elliott> ok
18:33:48: <boredzo> bzr *had* a plug-in to do it, but it went 404.
18:34:04: <boredzo> So that eliminates bzr in my world.
18:34:07: <cbarrett> I think we should decide if bzr is in or out right now.
18:34:14: <elliott> I think it should be out.
18:34:15: <cbarrett> hg and git are pretty similar.
18:34:15: <boredzo> I say out.
18:34:28: <elliott> I don't think the support is there, even though it keeps svn syntax.
18:34:30: <boredzo> Bring record and I may consider it again.
18:34:34: <boredzo> (And then there's the speed thing.)
18:34:39: <elliott> interactive add and speed
18:34:43: <Catfish_Man> I'm still in favor of it, but it sounds like I'm outvoted
18:34:49: <Catfish_Man> so, hg or git
18:34:52: <boredzo> Catfish_Man: What's good about bzr?
18:34:55: <elliott> hg or git or svn
18:34:57: <boredzo> (that outweighs not having rec)
18:35:00: <alangh> thanks elliott
18:35:07: <elliott> np alangh
18:35:12: <elliott> i'm not ruling it out completely
18:35:27: <Catfish_Man> boredzo: I haven't used record yet, so I don't know yet :)
18:35:38: <Catfish_Man> but the 'shelve' feature fills most of the use-cases for it I can think of
18:35:42: <Catfish_Man> at least for my patterns
18:35:51: <boredzo> shelve == ?
18:35:52: <dsymonds> shelve?
18:36:00: <Catfish_Man> put some changes aside temporarily, basically
18:36:05: <boredzo> Ah.
18:36:06: <dsymonds> Git has git-stash, or you can create another branch
18:36:10: <boredzo> record is nicer, but that solves the same problem.
18:36:21: <elliott> i mean, i really like git but i'm not completely sold on dumping svn yet
18:36:26: <boredzo> Is shelve interactive?
18:36:29: <elliott> sounds like git has both
18:36:33: <Catfish_Man> boredzo: I don't think so
18:36:35: <Catfish_Man> elliott: git has *
18:36:38: <Catfish_Man> that's the problem
18:36:42: <elliott> heh
18:36:43: <boredzo> git has emacs. And emacs has git.
18:36:45: <Catfish_Man> often it has more than one *
18:37:04: <elliott> I think we need to narrow it down to one dvcs and svn
18:37:08: :Server: durin42 (n=durin@198.109.223.42) joined #adium-devl
18:37:09: <dsymonds> heh, git is a Swiss Army Knife
18:37:10: <Catfish_Man> boredzo: ah, bzr shelve is interactive
18:37:14: <cbarrett> Agreed, elliott.
18:37:20: <cbarrett> ahoy durin42.
18:37:24: <boredzo> Nice. So git has record and bzr has the next best thing.
18:37:24: <Catfish_Man> hi durin42
18:37:27: <elliott> there's our vcs guy
18:37:34: <durin42> Um, hang on, I can't see anything
18:37:34: <boredzo> s/git has/git and hg have/
18:37:39: <elliott> git has both and bzr has the next best thing
18:37:44: <cbarrett> durin42 must be using Linux or something.
18:37:46: <cbarrett> ;)
18:37:52: <Catfish_Man> prolly just colloquy ;)
18:37:53: <durin42> ok, there we go
18:37:57: <durin42> Colloquy actually
18:37:59: <cbarrett> Ha.
18:37:59: <elliott> yeah
18:38:00: <elliott> :P
18:38:02: <durin42> such a pile.
18:38:05: <cbarrett> Nice job calling it, Catfish_Man
18:38:08: <cbarrett> Irssi 0.8.10 (20051211) - http://irssi.org/
18:38:14: <boredzo> <-still using ShadowIRC
18:38:16: <durin42> anywho
18:38:18: <Catfish_Man> so, getting back on topic
18:38:29: <boredzo> Yeah. We were talking about emacs or something?
18:38:37: <Catfish_Man> durin42: at this point, we're discussing record/shelve/related
18:38:37: <durin42> Sorry, I got nap'ed
18:38:41: <elliott> I thought git used vi?
18:38:42: <durin42> kk
18:38:46: <Catfish_Man> git and hg both have record-alikes
18:38:48: <boredzo> elliott: $EDITOR.
18:38:52: <boredzo> It was a joke. ;)
18:38:53: <Catfish_Man> bzr has interactive shelve, which is almost as good
18:38:56: <elliott> ;)
18:39:07: <elliott> Catfish_Man: regardless, I think we've eliminated bzr, so :x
18:39:07: <boredzo> So let's not rule out bzr yet.
18:39:13: <cbarrett> durin42: bzr is on the chopping block.
18:39:14: <elliott> ok maybe not
18:39:17: <cbarrett> Defend or attack.
18:39:29: <durin42> Um...it's not hg? :p
18:39:33: <Catfish_Man> heh
18:39:35: <boredzo> Not yet.
18:39:39: <durin42> Seriously tho.
18:39:48: <boredzo> We're at the hard part.
18:39:52: <Catfish_Man> durin42: if that's your argument, I'm going to argue against hg saying "it's not bzr" :P
18:39:54: <boredzo> bzr vs git vs hg (vs svn).
18:40:08: <boredzo> This is where the argument gets hard.
18:40:16: <cbarrett> mtn and darcs can be seen in the background, crying.
18:40:28: cbarrett imagines this as some sort of KoF battle or something.
18:40:28: <durin42> I'm looking at our page now, trying to figure out what to say about bzr
18:40:32: <boredzo> I still love darcs, but I can see why you guys wouldn't.
18:40:40: <elliott> Ok well
18:40:47: :Server: edr1084 (n=edr1084@c-67-171-68-206.hsd1.pa.comcast.net) joined #adium-devl
18:40:50: <boredzo> Especially the weak Unicode-fu. Everything is just bytes.
18:40:51: <Catfish_Man> I think git doesn't meet our curve and stay-out-of-the-way-ness requirements, and hg seems to do everything we need from it just as well
18:40:52: <elliott> let's address with bzr speed
18:41:02: <durin42> boredzo: one problem with it is symlinks, right?
18:41:06: <boredzo> elliott: Maybe fast enough, but definitely slower than hg.
18:41:10: <Catfish_Man> elliott: we can't speed test until I have an svnsync to set up with
18:41:10: <boredzo> durin42: What, darcs?
18:41:17: <durin42> boredzo: yes
18:41:25: <Catfish_Man> elliott: the issue is that some of them scale differently, so merely testing startup or small repo speed is not indicative
18:41:27: <boredzo> Never had occasion to try it.
18:41:28: <hal2k> I'd say symlinks are pretty much required
18:41:41: <cbarrett> Yeah, let's not discuss darcs.
18:41:44: <boredzo> hal2k: I agree. We had the script hackery before; let's not go back.
18:41:47: <cbarrett> git v hg v bzr (v svn)
18:41:51: <hal2k> yep
18:41:51: <elliott> ^
18:41:54: <dsymonds> boredzo: What's Unicode-fu got to do with things?
18:42:01: <cbarrett> Argh, no more darcs talk.
18:42:04: <Catfish_Man> dsymonds: we have a ton of unicode files
18:42:04: <hal2k> boredzo: esp. since evands is really bad at scripts
18:42:07: <cbarrett> take it to /msg
18:42:08: <boredzo> dsymonds: We use Unicode, and I, for one, use Unicode in commit messages.
18:42:16: <dsymonds> that's no problem with git
18:42:19: <cbarrett> Darcs discussion to /msg or #adium
18:42:22: <cbarrett> Please :(
18:42:26: <boredzo> #adium? :P
18:42:29: <boredzo> Anyway.
18:42:31: <Catfish_Man> ok, so
18:42:38: <Catfish_Man> why are hg and git effectively different for our purposes?
18:42:38: <boredzo> bzr, hg, git, or svn. Who's next for the gallows?
18:42:46: <Catfish_Man> so far everything one has, the other has
18:42:48: <Catfish_Man> is what I'm seeing
18:42:48: <boredzo> Catfish_Man: hg doesn't have gc.
18:42:53: <boredzo> It Just Works.
18:42:54: <Catfish_Man> so +1 for hg
18:43:01: <dsymonds> hg doesn't have git's speed
18:43:02: <elliott> Catfish_Man: hg is much more simple, and similar to svn
18:43:03: <cbarrett> hg is simpler. Slightly less flexible.
18:43:10: <boredzo> hg has plug-ins, though.
18:43:10: <elliott> hg is a little slower and less flexible
18:43:18: <boredzo> And at least two or three of us have enough Python-fu to write them.
18:43:22: <boredzo> elliott: Slower than what? git?
18:43:23: <durin42> hg is a *little* slower than hg, but has pretty much everything else.
18:43:31: <boredzo> hg is exactly as fast as hg.
18:43:38: <durin42> boredzo: git is silly fast by making you do gc at times
18:43:38: <boredzo> I have done extensive tests on this topic.
18:43:40: <elliott> boredzo: yes, git.
18:43:41: <boredzo> I even have bar charts.
18:43:57: Catfish_Man sets mode -pedant on boredzo ;)
18:44:03: <dsymonds> Git is an order of magnitude faster than Hg for many things
18:44:14: <cbarrett> Depends on the repository, dsymonds.
18:44:20: <cbarrett> I havve noticed hg getting slower than "everything works instantly", but it was still usable.
18:44:26: <Catfish_Man> dsymonds: that implies that either they're both near-instant, or that hg is alarmingly slow in some cases
18:44:28: <boredzo> durin42: Yeah, and that's the thing. I complain about bzr being slower than hg because there's no real workflow difference. git is only as fast as/faster than hg when you gc regularly.
18:44:38: <alangh> so how does git behave on our repository size/shape
18:44:45: <dsymonds> well, I'm looking at a Mozilla-sized repo benchmark
18:44:49: <elliott> dsymonds: care to answer?
18:44:50: <dsymonds> http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html
18:44:50: <Catfish_Man> alangh: for mozilla, the repo was much smaller
18:44:59: <durin42> IIRC hg and git were pretty similar in terms of size for the history
18:45:00: <cbarrett> dsymonds: Those numbers are very out of date, durin42.
18:45:03: <cbarrett> dsymonds, rather.
18:45:03: <dsymonds> well, you can clone the SVN import I did for yourself
18:45:06: <dsymonds> http://repo.or.cz/w/adiumx.git
18:45:20: <dsymonds> It behaves quite well for me
18:45:26: <Catfish_Man> dsymonds: or you could just run du and tell us? :)
18:45:26: <dsymonds> It's big, but there's a lot of history
18:45:37: <dsymonds> I think I mentioned it in an email, but I'll run du now
18:45:39: <durin42> and hg will perform much better if we leave out early revs, because of weirdness in cvs2svn (I actually talked to fitz about that at one point)
18:45:54: <Catfish_Man> our repo is pretty weird in places
18:45:55: <elliott> durin42: hg trac integration?
18:45:59: <dsymonds> the whole directory is 869 MB
18:46:02: <boredzo> dsymonds:
18:46:02: <durin42> elliott: there's a plugin
18:46:02: <boredzo> time git clone http://repo.or.cz/w/adiumx.git %/Volumes/Adium git staging(0)
18:46:02: <boredzo> Initialized empty Git repository in /Volumes/Adium git staging/adiumx/.git/
18:46:02: <boredzo> error: Could not interpret <?xml version="1.0" encoding="utf-8"?>
18:46:12: <elliott> durin42: a working plugin?
18:46:13: <dsymonds> that's with a 768 MB .git dir
18:46:13: <boredzo> (and a whole lot of XML spam)
18:46:17: <dsymonds> boredzo: that's the wrong URL
18:46:26: <dsymonds> change /w/ for /r/
18:46:30: <dsymonds> use git://repo.or.cz/adiumx.git if you can
18:46:35: <durin42> http://trac.edgewall.org/wiki/TracMercurial
18:46:37: <dsymonds> i.e. "git clone git://repo.or.cz/adiumx.git"
18:46:51: <cbarrett> The main thing making our repositories huge is our practice of checking in 5MB binary files fairly often.
18:46:55: <dsymonds> boredzo: the /w/ URL there is only the web interface
18:47:19: <durin42> cbarrett: both git's packs and mercurial's revlog system should handle those well
18:47:31: <Catfish_Man> bzr packs should as well, afaik
18:47:41: <Catfish_Man> I don't see any problems with any of our options there, 'cept maybe svn
18:47:44: <durin42> git packs well, but it's slower for accessing old versions of files
18:47:45: <cbarrett> http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles
18:47:52: <cbarrett> Read that.
18:48:00: <dsymonds> durin42: nope, old versions are still very fast to access
18:48:10: <durin42> cbarrett: I'm familiar
18:48:14: <Catfish_Man> dsymonds: "slower" != "slow"
18:48:29: <durin42> dsymonds: "very fast" doesn't imply mercurial's O(1) "stays fast"
18:48:37: <boredzo> The question naturally arises, what is a binary file anyway? It turns out there's really no good answer to this question, so Mercurial uses the same heuristic that programs like diff(1) use. The test is simply if there are any NUL characters in the first 1K or so of a file.
18:48:41: <boredzo> ^-Fail
18:48:49: <durin42> boredzo: how is that fail?
18:48:53: <durin42> It's never done anything bad to me.
18:48:55: <dsymonds> I'm saying that accessing a particular file, no matter how old, in a Git repo is roughly a constant time
18:48:59: <cbarrett> boredzo: That's the standard *NIX definition of a binary file.
18:48:59: <boredzo> UTF-16 text has a lot of "NULs" because all ASCII text in such a file is 00__ (where __ is the ASCII code).
18:49:00: <dsymonds> age has nothing to do with it
18:49:13: <durin42> boredzo: where do we have UTF-16 in our code?
18:49:14: <boredzo> So, any UTF-16 will be recognized as "binary", and not diffed.
18:49:17: <boredzo> durin42: *.strings
18:49:31: <boredzo> And we already have this problem with svn add not recognizing that those files are UTF-16 text.
18:49:40: <boredzo> (probably using the same broken heuristic)
18:49:40: <durin42> Fun.
18:49:53: <dsymonds> Git won't screw with file contents at all
18:49:57: <elliott> but I doubt anything could realistically -fix- that
18:50:11: <elliott> i'm sure all of them use things that break on UTF-16
18:50:14: <dsymonds> CRLF-munging is completely optional, and only per-repo
18:50:15: <cbarrett> Mercurial isn't screwing with file contents either.
18:50:17: <durin42> dsymonds: the question is, how does git decide to show a diff?
18:50:31: <elliott> and whether git can diff UTF-16
18:50:39: <dsymonds> durin42: however you want; it'll be up to your viewer
18:50:50: <dsymonds> you can use an arbitrary diff tool
18:50:51: <durin42> dsymonds: git diff foo.png?
18:50:52: <boredzo> And if it's not automatic, is there a way to tell it now and forevermore "this file is text"?
18:51:09: <cbarrett> here we go
18:51:23: <cbarrett> http://www.bluishcoder.co.nz/2007/09/git-binary-files-and-cherry-picking.html
18:51:46: <cbarrett> (googled for |git binary files|)
18:52:08: <dsymonds> you can define your own diff viewers and merge drivers for particular filetypes
18:52:13: <alangh> so, shouldn't we be using UTF-8 files instead (they are safer for things like this)
18:52:24: <elliott> we can't
18:52:28: <elliott> we need UTF-16 for localization
18:52:33: <elliott> which is what *.strings is for
18:52:36: <cbarrett> .strings files need to be UTF-16, for whatever retarded reason.
18:52:42: <elliott> as every language can't be expressed in UTF-8
18:52:47: <cbarrett> elliott: uh, no.
18:52:48: <elliott> because you know, several languages can't be.
18:52:50: <cbarrett> That's not true.
18:52:53: <elliott> uh
18:52:53: <boredzo> cbarrett: So can we have *.strings +crlf +diff +merge?
18:52:59: <elliott> ISO Japanese is definitely UTF-16
18:53:01: <elliott> as is Chinese
18:53:10: <boredzo> elliott: No.
18:53:11: <elliott> they use the extra bits.
18:53:18: <cbarrett> elliott: This is why UTF-8 exists.
18:53:21: <dsymonds> When I diff strings files, I just use "GIT_PAGER=cat git diff", and let my terminal window show the UTF-16
18:53:26: <boredzo> UTF-* are just encodings of Unicode.
18:53:30: <alangh> elliott, any Unicode character can be expressed in UTF-8
18:53:31: <cbarrett> It specifies a way to use multiple 8-byte characters to encode it.
18:53:34: <dsymonds> elliott: you're mixing up Unicode and UTF-*
18:53:39: <boredzo> And *every* UTF can encode *all* of Unicode.
18:53:40: <elliott> blech
18:53:46: <elliott> my bad
18:53:47: <boredzo> Including UTF-7, UTF-8, UTF-16, and UTF-32.
18:53:58: <cbarrett> We have to UTF-16 because that's what the tools expect.
18:54:00: <durin42> FWIW, hg's diff command takes an -a --text treat all files as text option
18:54:03: <elliott> There is a good reason
18:54:04: <boredzo> dsymonds: You misunderstand.
18:54:13: <durin42> Without the -a option, diff will avoid generating diffs of files
18:54:14: <durin42> it detects as binary. With -a, diff will generate a diff anyway,
18:54:14: <durin42> probably with undesirable results.
18:54:16: <boredzo> If a file is not marked as text, or so detected, the VCS will say "that's binary" and not diff it.
18:54:18: <durin42> (from hg diff --help)
18:54:29: <cbarrett> durin42: Ah, excellent.
18:54:33: <cbarrett> So this argument is moot.
18:54:34: <dsymonds> boredzo: oh, yeah, I forgot the -a flag
18:54:36: <boredzo> durin42: Is there a way to say "all strings files are text", or at least "this file is text", now and forevermore?
18:54:46: <durin42> boredzo: don't think so
18:54:49: <cbarrett> boredzo: I don't think so.
18:54:53: <boredzo> cbarrett: Not exactly. Try that on a binary nib.
18:55:08: <cbarrett> hg very explicitly ignores storing file type information.
18:55:11: <durin42> oh, and you can grep *with hg* through history
18:55:22: <cbarrett> Yeah, grepping through history is hot.
18:55:28: <cbarrett> No idea if git can do that.
18:55:33: <elliott> but we could do that with git it seems
18:55:43: <elliott> "You can force other file types to be binary by adding a .gitattributes file to your repository. "
18:55:51: <dsymonds> "git-grep"
18:55:56: <cbarrett> heh.
18:55:58: <boredzo> Reading BinaryFiles, it sounds like all we have to do is modify hgmerge to get our desired behavior.
18:55:58: <cbarrett> Of course.
18:56:00: <cbarrett> :)
18:56:11: <durin42> boredzo: honestly, yeah.
18:56:22: <cbarrett> That would require everyone using a custom build of mercurial.
18:56:27: <durin42> It *should* be a fairly simple patch, just check for a BOM or something.
18:56:29: <cbarrett> Which is kind of a pain, but doable, I suppose.
18:56:34: <boredzo> There's also imerge.
18:56:35: <durin42> cbarrett: they might take the patch if it improved the workflow.
18:56:37: <boredzo> (part of hg)
18:56:46: <cbarrett> durin42: Perhaps, but doubtful.
18:57:04: <cbarrett> I can ask.
18:57:37: <durin42> cbarrett: I don't know - they tend to be pretty receptive to ideas.
18:57:53: <Catfish_Man> ok, reading scrollback here; coworker distracted me
18:58:26: <cbarrett> durin42: asked in #mecurial if you want to watch.
18:59:20: <boredzo> Interesting. hgmerge uses FileMerge.
18:59:20: <dsymonds> you meant #mercurial?
18:59:37: <cbarrett> boredzo: If you want. You can change that.
18:59:46: <boredzo> cbarrett: Yeah, but this may be a solution.
18:59:49: <cbarrett> But by default, yeah, it launches filemerge.
18:59:51: <cbarrett> It's pretty nice.
19:00:11: <Catfish_Man> ok, caught up
19:00:19: <cbarrett> Though trying out rtfmd's changes.app with it would be interesting.
19:00:21: <elliott> I'm going to go out on a limb
19:00:28: <elliott> and say that we're mentally ruled out bzr
19:00:30: <elliott> we've*
19:00:38: <Catfish_Man> elliott: mostly because I was afk :P
19:00:39: <cbarrett> Only because Catfish_Man shut up ;)
19:00:40: <boredzo> cbarrett: URL?
19:00:49: <elliott> ok then
19:01:09: <cbarrett> http://changesapp.com/index.php
19:01:31: <Catfish_Man> ... changesapp sounds a lot like versionsapp
19:01:34: <Catfish_Man> which makes me suspicious
19:01:42: <elliott> it's actually awesome
19:01:43: <elliott> i have the beta
19:01:49: <cbarrett> Catfish_Man: Na, it's FileMerge without suck.
19:01:50: <elliott> not made by the same people at all
19:01:52: <elliott> ^^
19:01:53: <Catfish_Man> ok, cool
19:02:44: <elliott> Anyway
19:02:48: <elliott> I need to leave.
19:02:54: <elliott> My final vote is for hg.
19:03:04: <Catfish_Man> ok. Have a good evening :)
19:03:26: <boredzo> BRB
19:03:28: <elliott> g'night
19:03:30: :Server: elliott has signed off ()
19:03:44: <cbarrett> Yeah, I need to head out soon as well.
19:05:10: <cbarrett> I think there is pretty strong support for Mercurial from a number of people. Elliott & Augie. I'd throw my vote in. I have no problem with git either.
19:05:37: <cbarrett> I'd probably vote against bzr, on self-interest grounds -- I know the least about it.
19:05:38: <boredzo> I'm in favor of hg, too, though I'm testing the UTF-16 merging right now.
19:05:45: <boredzo> cbarrett: You know svn.
19:05:47: <Catfish_Man> I need to investigate mercurial some more, but for now let's say that if not bzr, hg sounds good
19:05:48: <boredzo> Therefore you know bzr.
19:05:51: <dsymonds> Obviously my vote doesn't count, since I'm not an Adium developer; I'm just here as a passionate advocate of Git
19:06:22: <dsymonds> I'm happy to answer questions, etc., if you want to mail me
19:06:25: <dsymonds> It's up to you guys
19:06:28: <cbarrett> 19:04 < muggs> pretty soon, you'll be able to tell hgmerge that certain tools can merge 'binary' files
19:06:32: <cbarrett> neat :)
19:06:50: <Catfish_Man> dsymonds: honestly my biggest problem with git other than my own experience with it is watching seasoned webkit developers curse at it for >1hr
19:07:05: <Catfish_Man> that learning curve scares me
19:07:10: <proton> Catfish_Man: i've seen people do that with every DVCS
19:07:11: :Server: durin42_ (n=durin@207.75.229.35) joined #adium-devl
19:07:14: <dsymonds> really? I've been using Git for nearly a year, and it's been joyful almost the whole time
19:07:25: <cbarrett> I have to head out.
19:07:28: <boredzo> Catfish_Man: Are they all svn people? ;)
19:07:30: <dsymonds> yeah, there's a learning curve, but most of it was just getting used to a DVCS way of doing things
19:07:33: <Catfish_Man> boredzo: yeah
19:07:36: <cbarrett> My "votes" are above.
19:07:38: <Catfish_Man> but, so am I
19:07:42: <Catfish_Man> and so is everyone else here except dsymonds
19:07:43: <boredzo> cbarrett: Can you hang on for ~2 minutes?
19:07:48: <cbarrett> Sure.
19:07:59: <cbarrett> 19:07 < muggs> if you have a patch that detects UTF-16 accurately, e-mail it to dissonans. He'll probably take it
19:08:00: <dsymonds> :-(
19:08:59: <Catfish_Man> fwiw, it's relatively simple to get FileMerge to run with almost any version control system
19:09:04: <Catfish_Man> so regardless of what we do we can do that :)
19:09:14: <alangh> that is good
19:09:25: <boredzo> OK, hg with FileMerge works just fine.
19:09:35: <Catfish_Man> personally I don't like filemerge, but that's just me
19:09:44: <cbarrett> What'd you do, boredzo?
19:09:50: <cbarrett> extdiff?
19:09:50: <boredzo> dsymonds: Can you quickly state one feature of git that makes it beat bzr and hg?
19:09:58: <dsymonds> speed
19:10:00: <boredzo> cbarrett: Nope. Just did the usual and it Did the Right Thing.
19:10:03: <boredzo> dsymonds: So, no?
19:10:06: <cbarrett> neat.
19:10:12: <boredzo> git is *not* that much faster in my experience. :)
19:10:16: <dsymonds> better branching
19:10:18: <boredzo> (limited though it is)
19:10:21: <boredzo> Better how?
19:10:23: <cbarrett> Better?
19:10:45: <dsymonds> just a sec..
19:10:51: <cbarrett> Actually, I'm out.
19:11:01: <boredzo> cbarrett: 'Night.
19:11:04: <Catfish_Man> cbarrett: k. Have a good evening :)
19:11:08: <durin42_> 'night cbarrett
19:11:29: <proton> bzr requires a heap of dependencies. hg requires a few things to build. git doesn't.
19:11:33: <dsymonds> How does Hg handle multi-way merges?
19:11:50: <boredzo> proton: What heap of dependencies? IIRC, all they need is Python.
19:12:05: <durin42_> proton: hg builds against system python on 10.5 with no extra deps
19:12:09: <cbarrett> boredzo: if you want the svn stuff you need all this swig crap.
19:12:14: <boredzo> dsymonds: No idea. This was a really basic merge (one change on each branch, made to conflict)
19:12:14: <cbarrett> Final votes: I'd vote for git or hg, but not bzr.
19:12:30: <Catfish_Man> yeah. bzr-svn is only not a pita to build post svn-1.5
19:12:36: <Catfish_Man> that is a significant downside at the moment
19:12:40: <durin42_> dsymonds: multi-way is in three ancestors?
19:12:44: <proton> durin42_: uhm, source installation requires asciidoc and xmlto for hg
19:12:45: <dsymonds> well, switching between, say, hg and git is clean
19:12:50: <dsymonds> durin42_: 'n' ancestors
19:13:01: <cbarrett> hg does not allow n ancestors.
19:13:05: <dsymonds> (for n in [0,infinity) )
19:13:07: <durin42_> dsymonds: you would have to do n-1 two-way merges
19:13:08: <cbarrett> revlog only allows for 2 parents.
19:13:13: <dsymonds> ick
19:13:17: <proton> bzr requires a bunch of extra python modules to be installed
19:13:18: <durin42_> revlog revisions can have 1 or 2 parents
19:13:25: <cbarrett> ^5 durin
19:13:27: <cbarrett> Out for real now
19:13:57: <dsymonds> Git allows many ancestors, which is good for better merges
19:14:24: <cbarrett> Sounds confusing.
19:14:29: <dsymonds> e.g. http://repo.or.cz/git-browser/by-commit.html?r=git.git
19:14:36: <boredzo> dsymonds: Does that result in less work for the user?
19:14:37: <durin42_> I don't see that being a particularly huge thing - how many times have we needed multi-way-merges?
19:14:49: <durin42_> how does the UI for that work?
19:14:59: <durin42_> eg, merging conflicts between 4 branches
19:15:04: <dsymonds> well, if two separate people on two side branches make overlapping changes, and you try to merge both onto the master branch, it makes sense to have all three commits as the parent commits
19:15:14: <dsymonds> UI is still much the same as a regular merge
19:15:37: <dsymonds> look at the link above, and see the recent 'offcuts' branch merge
19:15:58: <dsymonds> for actually tracking multi-branch development, this kind of thing is really beneficial
19:16:05: Catfish_Man smites whoever is responsible for the horrible scrolling in git-web
19:16:08: <durin42_> dsymonds: that doesn't explain it. I mean, what UI do you use for the merging? Standard 3-way-merge tools won't handle that case.
19:16:55: <dsymonds> Git has some built-in merging "strategies", but you then can still end up by manually text-editing the bits between <<<<<< and >>>>>, etc.
19:17:12: <durin42_> I'm talking about the UI for when the magic doesn't work
19:17:16: <durin42_> and you have to do it manually
19:17:29: <durin42_> how does it denote a 4-way conflict, for example?
19:17:30: <durin42_> or does it not?
19:17:34: <dsymonds> the UI is anything you want to use, though git-gui does a reasonable job
19:17:42: <durin42_> and you simply have recursive 2-way merges?
19:17:43: <dsymonds> the conflict will be left in the file, like:
19:17:49: <dsymonds> pre-stuff...
19:17:50: <dsymonds> <<<<<<
19:17:53: <dsymonds> file-one stuff
19:17:55: <dsymonds> ====
19:17:58: <dsymonds> file-two stuff
19:17:59: <dsymonds> ====
19:18:01: <dsymonds> file-three stuff
19:18:03: <dsymonds> ====
19:18:05: <dsymonds> file-four stuff
19:18:08: <dsymonds> >>>>>>>
19:18:09: <boredzo> Ewwwwwwwww.
19:18:16: <durin42_> OK. So it's an extension of diff3 output.
19:18:21: <dsymonds> yeah
19:18:35: <dsymonds> it throws in the revision descriptions, too, so you can keep track of where the bits come from
19:18:49: <dsymonds> If someone makes a nice GUI tool for managing that, it'll JustWork(tm)
19:18:57: <dsymonds> ... but I think git-gui makes it quite easy, too
19:19:00: <durin42_> That's kinda cool, but I can't think of a reason why I'd ever need it.
19:19:26: <dsymonds> durin42_: for when multiple developers make concurrent changes
19:19:48: <durin42_> dsymonds: I know that in theory, but in practice the merges will just happen without causing multiple heads
19:19:52: <durin42_> most of the time
19:20:08: <dsymonds> durin42_: in practice, then, you won't have to do anything manually
19:20:22: <durin42_> *nod*
19:20:48: <dsymonds> Anyway, that's a feature of Git that Hg apparently doesn't have
19:20:57: <boredzo> dsymonds: Anything else?
19:21:04: <Catfish_Man> bzr doesn't have that either
19:21:06: <dsymonds> ... but with most of these things, you don't care about them unless you care about them, which you only do if you use them
19:21:17: <dsymonds> Did I mention Git's speed? ;-)
19:21:23: <boredzo> Yes. :)
19:21:43: <dsymonds> Built-in integrity checking via the SHA-1 hashes?
19:21:59: <dsymonds> (even catches local-disk corruption)
19:22:01: <boredzo> That's a plus, but using them as rev IDs is a PITA.
19:22:14: <dsymonds> You don't need to use them if you don't want to
19:22:21: <boredzo> Actually, a separate utility that hashed *everything* would be nice.
19:22:27: <dsymonds> there's tons of ways to address things without using the SHA-1
19:22:32: <boredzo> dsymonds: I know. The DVCSs page mentions that you can use timestamps instead.
19:22:42: <dsymonds> that's just the tip
19:22:52: <dsymonds> you can just use a branch name for the tip of that branch
19:22:57: <dsymonds> you can use a tag's name
19:23:18: <dsymonds> you can do relative naming: trunk~3 is the third parent (grand-grandfather) of the trunk branch
19:23:35: <boredzo> Yeah. And that's basically a negative revision number.
19:23:56: <boredzo> So instead of counting from the never-changing origin point of the repository, it counts from the ever-changing HEAD.
19:24:26: <dsymonds> etc.
19:24:26: <Catfish_Man> dsymonds: essentially the main issue we have with naming like that is how to talk about revisions
19:24:26: <Catfish_Man> particularly with users/testers
19:24:26: <dsymonds> it's very nice to be able to make a new branch from the previous commit just by typing "git checkout -b new_branch HEAD^"
19:24:28: <durin42_> Honestly, hg has an interface that will take less getting used to (eg, ci -a on git)
19:24:32: <dsymonds> Catfish_Man: the benefit of the hashes is that they're universally unique, so you have a definite version that you know they're using
19:24:42: <dsymonds> git-bisect is cool, too
19:24:46: <Catfish_Man> dsymonds: we already have that with svn ;)
19:24:52: <boredzo> What does git-bisect do?
19:25:13: <dsymonds> helps narrow down a regression
19:25:41: <durin42_> That's something we could add to hg if we wanted it fairly simply.
19:25:46: <dsymonds> you can say "This revision was good, this one is bad", etc., then git-bisect will lead you on a binary-search testing spree
19:26:00: <Catfish_Man> durin42_: webkit has it for svn
19:26:19: <durin42_> Catfish_Man: *nod* I've seen the script.
19:26:57: <boredzo> dsymonds: Handy, but does it automate any part of that?
19:27:16: <durin42_> boredzo: it automates what versions you check
19:27:17: <dsymonds> boredzo: yeah, if you give it a shell script or something that will tell it if it's bad or good
19:27:27: <durin42_> oh, I see. That's sorta handy.
19:27:33: <dsymonds> git-bisect can be completely automated if you have an automatic test script
19:27:45: <alangh> well, I gotta run.... thanks everyone
19:28:17: <Catfish_Man> bye alangh
19:28:43: :Server: alangh has left #adium-devl ()
19:29:23: <boredzo> dsymonds: OK, that would rock.
19:29:44: <boredzo> Doesn't sound that hard to implement, though.
19:29:45: <dsymonds> yeah, and it even works nicely amongst many complex inter-merged branches
19:29:59: <dsymonds> no, but it's good to have it in the standard toolkit
19:30:07: <Catfish_Man> http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension
19:30:12: <boredzo> Nice.
19:30:18: <Catfish_Man> "This extension is currently being distributed along with Mercurial."
19:30:38: <dsymonds> "This command comes from GIT."
19:30:39: <dsymonds> heh
19:30:43: <Catfish_Man> yup
19:30:58: <boredzo> Catfish_Man: What does bzr have over hg and git?
19:31:14: <dsymonds> Harder to pronounce?
19:31:18: <boredzo> Bazaar?
19:31:23: <boredzo> buh-zar. Not hard.
19:31:25: <Catfish_Man> boredzo: mostly exactly the same features, but easier to use and better documented? :)
19:31:39: <Catfish_Man> (bzr bisect exists too)
19:31:57: :Server: durin42 has signed off (Connection timed out)
19:32:00: <boredzo> Catfish_Man: But no record.
19:32:06: <boredzo> Just the next best thing.
19:32:10: <Catfish_Man> right
19:32:20: <Catfish_Man> also alangh wouldn't have to give up his precious centralized workflow ;)
19:32:30: <dsymonds> One more difference: Hg stores by revlog delta, which makes it slow to jump to an arbitrary revision; Git doesn't have that flaw
19:32:45: <durin42_> dsymonds: it's *not* slow to jump to an arbitrary revision.
19:32:59: <durin42_> It's an O(1) operation, and is very fast in my experience.
19:33:04: <boredzo> That's interesting.
19:33:06: <boredzo> rollback completed
19:33:06: <boredzo> abort: premature EOF reading chunk (got 238220 bytes, expected 1697919854)
19:33:13: <boredzo> --hg in cloning Colin's repo.
19:33:18: <boredzo> I wonder if that's DH being a bitch.
19:33:23: <durin42_> probably
19:33:33: <dsymonds> durin42_: okay, I don't know Hg all that well, you're probably right
19:33:42: <Catfish_Man> yeah, doing this off of DH is definitely not going to be a winner
19:33:45: <Catfish_Man> regardless of vcs
19:33:50: <dsymonds> DH?
19:33:52: <Catfish_Man> dreamhost
19:33:56: <dsymonds> ahhh
19:33:56: <durin42_> yeah, dreamhost is a pain in the ass
19:34:07: <dsymonds> well, there's free Git hosting at repo.or.cz ;-)
19:34:11: <boredzo> I remember when everybody was recommending I go with DH and I went with TextDrive instead. :)
19:34:15: <Catfish_Man> dsymonds: or free * hosting at adiumx.com for us
19:34:19: <dsymonds> heh, yeah
19:34:31: <Catfish_Man> boredzo: I still like DH
19:34:40: <Catfish_Man> but I have never suggested it for high availability stuff like an Adium repo
19:34:43: boredzo notes that, about three quarters of an hour later, git clone is at 28%
19:34:57: <proton> there's nothing wrong with DH, but trying to run custom server processes on shared hosting and expecting great uptime is silly
19:35:04: <boredzo> Catfish_Man: It doesn't even have to be high-availability if it's just for our testing.
19:35:12: <Catfish_Man> boredzo: true
19:35:22: <dsymonds> boredzo: are you doing it via git:// or http:// ?
19:35:25: <boredzo> proton: How about "doesn't choke and die after three-quarters of an hour"?
19:35:29: <boredzo> dsymonds: git:
19:35:36: <Catfish_Man> boredzo: anything without a custom server (i.e. * over http) should be fine then
19:35:53: <proton> boredzo: it's a custom server, they kill long running processes like most shared hosting providers
19:35:53: <boredzo> Catfish_Man: hg clone is going over http:
19:35:54: <Catfish_Man> (although I don't know if svn over http requires svn to be running?)
19:36:03: <Catfish_Man> boredzo: does it need a process serverside?
19:36:06: <proton> if you want to run custom processes you ought to be using a dedicated server...
19:36:11: <boredzo> I have no idea.
19:36:17: <Catfish_Man> prolly does if it blew up
19:36:25: <boredzo> proton: Again, this is Colin's testing repo, not the Final Adium Repo.
19:36:48: <proton> i know
19:37:19: <durin42_> OK, my final vote is still for hg
19:37:20: <durin42_> I need to go
19:37:24: <Catfish_Man> k
19:37:31: <boredzo> BTW, in fairness to git, that git clone process was competing with hg clone for my bandwidth, and vice versa.
19:37:32: <hal2k> Catfish_Man: svn needs a custom apache module, no process
19:37:34: <boredzo> It's going faster now.
19:37:44: <boredzo> hal2k: I thought svn just ran on WebDAV.
19:37:49: <boredzo> (as long as you're using Apache 2).
19:37:54: <boredzo> durin42_: 'Night.
19:38:05: <hal2k> boredzo: it's an extension to webdav I think
19:38:06: <durin42_> boredzo: no, it requires mod_dav_svn
19:38:15: <boredzo> Oh, right. That name rings a bell.
19:38:18: <durin42_> there are some extra DAV commands they add.
19:38:24: <durin42_> They regret that decision now, IIRC.
19:38:39: <durin42_> anywho, I'm out
19:38:41: <durin42_> ttfn
19:38:43: :Server: durin42_ has signed off ()
19:38:53: <Catfish_Man> so it's sounding like most people are in favor of hg
19:39:04: <Catfish_Man> I will install that now and check out the workflow and UI
19:39:11: <hal2k> I personally don't care as long as it's not mtn :)
19:39:20: <boredzo> I like hg, too.
19:40:15: <boredzo> It seems to be suck-free.
19:40:37: <Catfish_Man> my primary concern is that a relatively limited set of operations are very fast and simple. A bit of extra effort on weird stuff is ok by me
19:40:40: <Catfish_Man> (see, for example, svn merge)
19:41:47: <boredzo> Hm?
19:41:57: <dsymonds> apparently (I'm just reading some comments from elsewhere):
19:42:05: <dsymonds> "Mercurial lacks lightweight branches"
19:42:22: <Catfish_Man> that could be a problem for those limited in disk space (i.e. me :( )
19:43:03: <boredzo> Catfish_Man: RAM disk? :)
19:43:11: <dsymonds> each Git branch, not checked out, takes up about 40 bytes on disk
19:43:33: <boredzo> dsymonds: And each git branch, not checked out, can't be used for anything, right? Wouldn't you have to check it out first?
19:43:36: <Catfish_Man> boredzo: I have 3GB of ram, and regularly use 2.1+ of it
19:43:47: <dsymonds> boredzo: yes
19:43:49: <boredzo> Catfish_Man: Surely a half-GiB branch should fit just fine.
19:43:58: <Catfish_Man> boredzo: I was paging today :(
19:44:01: <dsymonds> boredzo: you can still access it's contents without checking it out, though
19:44:06: <Catfish_Man> 'bout 50k pageouts
19:44:54: <Catfish_Man> the size and speed of a local branch (with checkout!) operation is actually of some concern to me
19:45:19: <dsymonds> well, Git does that very well. It's very compact
19:45:44: <Catfish_Man> so, I fucking hate the hg quickstart
19:45:53: <Catfish_Man> who the hell writes a "quickstart" that doesn't include push?
19:45:53: <boredzo> Any idea what a branch checkout looks like, as a share of the original repo?
19:46:07: <boredzo> Catfish_Man: That's why it's so quick. No network I/O!=
19:46:09: <boredzo> -=
19:46:20: <dsymonds> A branch checkout is just the files for that revision
19:47:07: <Catfish_Man> nice, sudo port install mercurial failed with an error
19:47:22: <boredzo> Building from source worked just fine, IIRC.
19:47:29: <boredzo> Make sure you get the release.
19:47:43: <boredzo> The "stable" branch, for whatever reason, doesn't include the really good plug-ins (like record).
19:48:24: <dsymonds> by comparison, with the Adium repo: 768 MB for the git repo (the .git dir), and 101 MB for a checked out copy
19:48:35: <boredzo> That's not too bad.
19:48:54: <dsymonds> yeah, for everything back to 2002
19:49:03: <Catfish_Man> the small checkouts is a definite plus
19:49:07: <Catfish_Man> (bzr has that as well)
19:49:13: <Catfish_Man> an svn checkout is about 300MB
19:49:26: <boredzo> 231 MiB for me.
19:49:30: <boredzo> Don't forget to subtract your build folders.
19:49:41: <Catfish_Man> I rm'd the build folder
19:49:47: <boredzo> Interesting.
19:49:55: <Catfish_Man> ah, need to kill Release/build/ too
19:49:56: <dsymonds> well, a git checkout is the only the working tree; you'll still need a repo copy
19:50:07: <Catfish_Man> dsymonds: I have 7 svn checkouts of adium
19:50:17: <dsymonds> 7? Why that many?
19:50:24: <Catfish_Man> "local branches"
19:50:34: <Catfish_Man> (see why I want dvcs?)
19:50:58: <dsymonds> aah, yes
19:51:08: <dsymonds> well, if you only check one out at a time, Git is ideal
19:51:14: <Catfish_Man> I don't
19:51:20: <Catfish_Man> I ping pong back and forth constantly
19:51:31: <dsymonds> Well, switching branches in git is fast
19:51:44: <Catfish_Man> true of all dvcs afaik
19:52:09: <dsymonds> ... though there are features in Git where you can "share" the .git directory (the git repo local copy) between local repos
19:52:14: <Catfish_Man> likewise with bzr
19:52:37: <Catfish_Man> that is, in fact, how I have bzr set up for sparkweb :)
19:53:35: <boredzo> Any idea whether we can have that for hg?
19:53:35: <dsymonds> well, I have a work meeting shortly
19:53:41: <Catfish_Man> not sure
19:53:48: <dsymonds> It seems you've settled on Hg, so I'll stop bothering you all
19:54:02: <boredzo> Indeed. You could ask about that in your report to the list, Catfish_Man
19:54:22: <Catfish_Man> speaking of which, are you logging this?
19:54:25: <boredzo> Yup.
19:54:29: <Catfish_Man> good
19:55:31: <dsymonds> okay, I'm off
19:55:36: <Catfish_Man> bye dsymonds
19:55:49: :Server: dsymonds has signed off ("Outta here")
19:55:53: <Catfish_Man> hm, there's no hg switch command?
19:55:56: <boredzo> Hm?
19:56:33: <Catfish_Man> apparently there isn't
20:00:26: <boredzo> http://www.selenic.com/pipermail/mercurial/2005-June/001126.html
20:01:37: Catfish_Man smites the hg documentation some more
20:01:50: <Catfish_Man> is there a way to do push without specifying a url each time?
20:04:17: <boredzo> I think that if you clone, it always uses that other repo.
20:04:29: <Catfish_Man> ok
20:04:33: <Catfish_Man> that makes sense
20:04:47: <Catfish_Man> but so far I am going to say that my #1 problem with hg other than macports is the documentation
20:04:51: <Catfish_Man> it is *amazingly bad*
20:05:20: <boredzo> Why's that?
20:06:13: <Catfish_Man> I have so far read over *three* documents about sharing changes
20:06:17: <Catfish_Man> not one of them mentioned that fact
20:06:24: <Catfish_Man> two, in fact, did not mention that "push" existed
20:06:34: <Catfish_Man> they seemed to assume everyone would email changes around
20:06:44: <boredzo> http://hgbook.red-bean.com/hgbook.html <-Cmd-F(push)
20:06:44: <Catfish_Man> or that you were merging two things both on your own computer
20:06:57: <Catfish_Man> not found
20:07:01: <boredzo> Exactly.
20:07:14: <boredzo> http://www.selenic.com/mercurial/wiki/index.cgi/TipsAndTricks#head-903d2da677af8b40172345b98072b4b2826bad22
20:07:50: <Catfish_Man> ...is that global for all hg pushes?
20:07:56: <boredzo> Note the ".hg" part.
20:07:59: <boredzo> That's per-repo.
20:08:03: <Catfish_Man> ah good
20:08:34: <boredzo> I dislike this post-UNIX convention of calling any configuration file an "rc" file.
20:08:58: <boredzo> "rc" stands for Run Commands. That's a different concept. A shell script is an rc file; an INI file is not.
20:08:57: <Catfish_Man> guh. Anyway, I am headed home
20:09:02: <boredzo> Bye Catfish_Man :)
20:09:06: <Catfish_Man> I need food, otherwise I will be furious at hg
20:09:13: <boredzo> Definitely read that TipsAndTricks page, too.
20:09:15: <Catfish_Man> and that is not productive
20:09:29: <Catfish_Man> will do
20:09:38: <Catfish_Man> so far though, hg is losing on UI by about 5 orders of magnitude :P
20:09:48: :Server: Catfish_Man has signed off ()
â‹®
20:45:29: :Server: Catfish_Man (n=david@c-71-236-163-69.hsd1.or.comcast.net) joined #adium-devl
20:45:56: <Catfish_Man> boredzo: so, the red-bean one makes me want to hurt them less
20:48:17: <boredzo> Catfish_Man: Oh?
20:48:39: <Catfish_Man> it hasn't gotten to pushing yet, either, but at least it has shown me some cool stuff
20:58:27: <boredzo> Ah. Two hours later, git clone finally failed, running out of space on a 512 MiB RAM disk.
