[01:11] <enigma42> Hm...I ran into a strange bzr-svn error.
[01:11] <enigma42> It's throwing out stack trace.
[01:12] <enigma42> bzr-svn 0.6.5
[01:12] <jelmer> enigma42: please file a bug
[01:12] <enigma42> OK
[01:13] <enigma42> Oh...should I try 1.00 first?
[01:13] <jelmer> enigma42: probably
[01:13] <enigma42> How much of a difference is there between 0.6.5 and 1.0?
[01:13] <enigma42> OK.
[01:14] <enigma42> Oh...another quick question...
[01:14] <enigma42> How do I clear the svn cache now that it's using sqlite
[01:14] <enigma42> ?
[01:14] <jelmer> enigma42: it's always been sqlite :-)
[01:14] <enigma42> Oh. Where did the cache move to?
[01:14] <jelmer> enigma42: ~/.bzaar/svn-cache ~/.cache/bazaar/svn
[01:15] <enigma42> Oh...OK.
[01:15] <jelmer> either of thoes locations
[01:15] <zsquareplusc> is there a bzr command to remove a remote branch? (bzr+ssh URL)
[01:23] <enigma42> jelmer: I'm curious, where does the svn repo ID come from? Such as: daff2dd8-1c3d-0410-9cd2-f6297dd8f964
[01:23] <enigma42> Does subversion generate that itself?
[01:25] <enigma42> I've noticed that bzr-svn always seems to come up with the same ID no matter which machine
[01:25] <enigma42> So long as I'm pointing to the same repo.
[01:27] <lifeless> svn has a GUID repository ID
[01:28] <jelmer> enigma42: yeah, svn generates it itself
[01:39] <meoblast001> lifeless: i just wanted to tell you i think i got everything straighted out
[01:39] <meoblast001> i'm making a backup copy of the old branch just in case
[01:42] <meoblast001> scratch that, getting errors
[01:42] <meoblast001> http://codepad.org/3P2U2cGQ
[01:44] <enigma42> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/436971
[01:45] <enigma42> it just affects a couple of my projects.
[01:45] <enigma42> We have about 70+ projects using trunk1 layout.
[01:45] <enigma42> But just a couple of them get this error when I try to push a new branch into /project/branches
[01:46] <meoblast001> is that because i init'd a new branch on my system and imported my stream into it?
[01:46] <enigma42> Cooincidentally, only the problematic projects have been used with bzr-svn since the dawn of time. I'm wondering if it's an old metadata problem.
[01:54] <meoblast001> how do i make these repositories compatible
[01:55] <meoblast001> i have a stream of my branch, so all i have to do to create a new branch with the contents of this one is init it and then import it
[01:56] <fullermd> Those two in particular?  You don't.  Working across a rich root divide isn't practical.  You'd have to switch one or the other.
[01:56] <meoblast001> what do you mean?
[01:57] <fullermd> Revisions with rich root info can't be put into a repository with an impoverished-root format.
[01:58] <meoblast001> what is rich root and impoverished root?
[01:58] <fullermd> (in this case specifically, 2a is the trigger pull; it's the first default format that's rich-root.  Previous rr formats were all non-default choices)
[01:59] <meoblast001> oh, you mean because i have bzr 2.x and my old repository was 1.x?
[01:59] <fullermd> Well, impoverished root is just my term, 'cuz I feel silly typing 'non-rich-root' or variants of it all the time...
[01:59] <fullermd> Any opportunity to play games with language.
[02:00] <meoblast001> well, how do i make an impoverished root branch?
[02:00] <fullermd> Specifically, your 'old' repository is in a non-rr format.  So you'd have to use one compatible with that (something like 1.9, say).
[02:00] <meoblast001> so i have to install Bazaar 1.9?
[02:01] <fullermd> Alternately, upgrade the poor branch to a rr capable format; that's the future.
[02:01] <meoblast001> but 2.x is still in RC
[02:01] <fullermd> No, just use --format=1.9.
[02:01] <meoblast001> so bzr init --format=1.9?
[02:01] <fullermd> Sure, but there've been rr formats back as far as bzr 1.0 (rich-root-pack), and rr versions of every format since.
[02:01] <fullermd> It's just with 2 that the _default_ starts being rr.
[02:01] <fullermd> Yah.
[02:02] <meoblast001> ok
[02:02] <meoblast001> i can upgrade to rich-root later without causing problems, right?
[02:03] <fullermd> Yeah, that way works fine.  It's going the other way that doesn't.
[02:04] <fullermd> (rich root stores strictly more information, so trying to go the other way would be throwing things away)
[02:04] <meoblast001> yes, but throwing away useless information
[02:04] <meoblast001> i want to upgrade when everything is for sure stable
[02:04] <meoblast001> i'm a little cautious
[02:04] <fullermd> No, it's not useless information.
[02:05] <meoblast001> oh, i heard it was :/
[02:05] <fullermd> And throwing it away would mean you now had two versions of the same revision out there.  That's a serious no-no.
[02:05] <meoblast001> i heard instead of saving whole lines in the differences, it would only store character changes
[02:05] <fullermd> No, it's nothing like that.
[02:05] <fullermd> And that change wouldn't be incompatible anyway, as long as it assembled the same text in the end.
[02:06] <fullermd> Specifically, the different is that rich root formats store an identity for the root of the tree.  Poor roots don't.
[02:21] <mzz> http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html says I should "unset the current trunk from being the development focus" in launchpad. Where's the control for that? I can find a way to set a different development focus, but not to unset it completely.
[02:25] <wgrant> mzz: You unset the branch from the series, not the series from the development focus.
[02:26] <wgrant> mzz: https://launchpad.net/PROJECT/SERIES/+edit
[02:27] <mzz> wgrant: and set "Branch" to the empty string there?
[02:27] <wgrant> mzz: Probably.
[02:28]  * mzz tries
[02:28] <mzz> ok, that did something, let's see if the rest of the steps work
[02:29] <mzz> does it make sense to just delete ~me/project/trunk and re-push it from scratch?
[02:29] <mzz> no, wait
[02:30] <mzz> I should push a new one just in case anyone stacked on the old branch. Bleh, naming. migrated-trunk?
[02:30] <wgrant> You can't delete the old one if anything is stacked on it.
[02:31] <SamB_XP> wgrant: oh, that's nice!
[02:31] <SamB_XP> what happens if you try it from the command line ?
[02:31] <mzz> wgrant: ah, so if launchpad lets me I won't really inconvenience anyone by doing it?
[02:31] <wgrant> mzz: Well, unless they have local stacked branches, in which case they're insane.
[02:31] <SamB_XP> indeed
[02:31] <SamB_XP> what if they lost connectivity for a time?
[02:32] <mzz> well, this *is* a pretty insane project, but I seriously doubt anyone branched off it at all, let alone stack on top of it
[02:32]  * mzz smites the branch
[02:32] <wgrant> SamB_XP: Or if they want to do anything even slightly unslowly.
[02:32] <SamB_XP> wgrant: yes, or that
[02:33] <SamB_XP> it's about as insane as doing a lightweight checkout from launchpad or SVN
[02:33] <mzz> hey, I just did that
[02:34] <mzz> (to look at a file, I didn't need any history)
[02:34] <mzz> ok, this seems to have worked
[02:35] <mzz> let me do the same delete and fresh push on my two +junk branches
[02:38] <SamB_XP> mzz: if I wanted to look at just one file, I'd probably just use loggerhead or the HTTP URL ...
[02:38] <SamB_XP> ... if I could figure out what the latter was
[02:38] <SamB_XP> since I clearly can't type lp:foo in my browser's URL bar
[02:39] <mzz> SamB_XP: I was already on the commandline, not a browser. Typing "bzr co lp:whatever" and feeding the file to less was faster than switching to a browser and navigating through loggerhead
[02:39] <SamB_XP> mzz: oh, that defaults to --lightweight now?
[02:39] <mzz> (I have co aliased to checkout --lightweight)
[02:39] <SamB_XP> oh
[02:41] <mzz> I have a probably slightly odd setup where most of my code lives in no-trees repositories on a fileserver on my lan, while I work in local lightweight checkouts of those
[02:45] <SamB_XP> mzz: that's a bit less dumb
[02:45] <mzz> thanks? :)
[02:45] <SamB_XP> I sometimes work in directories that are themselves on a fileserver
[02:46] <SamB_XP> well, it's an NFS server, really
[02:46] <SamB_XP> and something about the setup makes the time to access a file pretty high ...
[02:47] <SamB_XP> I mean, if you untar something it can take quite a while
[02:47] <mzz> this setup is usually fast enough, and if it isn't I can always do a full local branch
[02:47] <mzz> advantage is that I can't forget to push changes off my desktop onto the fileserver so they're accessible remotely when the desktop is off
[02:48] <fullermd> ...  computers turn off?
[02:49] <mzz> my fileserver doesn't
[02:49] <SamB_XP> someone keeps turning off the print server here ...
[02:49] <mzz> my desktop occasionally does
[02:49] <SamB_XP> ... might be something to do with the fact that it runs windows 98 ...
[02:49] <mzz> hah
[02:51]  * mzz is upgrading all his stuff to 2a while simultaneously clearing out cruft
[02:52] <mzz> apparently I have a lot of that
[03:03] <Peng_> I keep my server on the latest formats and relatively clean, but my PC is a huge mess of formats. :D
[03:03] <RenatoSilva> Is it common to develop oriented to bugs? I mean, every change you developer want to do, you register a bug before that, making every or many commits having a bug id assigned?
[03:04] <fullermd> That sounds like a "community standards" question.
[03:12] <RenatoSilva> fullermd: mine?
[03:12] <fullermd> Yeah.
[03:14] <RenatoSilva> fullermd: I think I'll do that only for important bugs, even though it's not possible to tell launchpad since what milestone the bug applies
[03:15] <RenatoSilva> thansk anyway!
[03:15] <fullermd> Oh, see, now you're trending toward one of the two Great Unanswerable Questions.
[03:15] <fullermd> (1) What is the meaning of life?
[03:15] <fullermd> (2) Is it possible to make a bug tracker that doesn't suck?
[03:16] <fullermd> (obviously, of course, the answers are "chocolate" and "no".  But I haven't figured out for sure which answer goes to which question yet.)
[03:17] <RenatoSilva> chocolate means you're fat?
[03:17] <RenatoSilva> and lp's bugtracker does not suck
[03:17] <fullermd> I've known plenty of rail-thin people who understood the preeminence of chocolate over everything else...
[03:18] <RenatoSilva> and?
[03:18] <fullermd> All bugtrackers suck.  They just suck in different ways.
[03:18]  * RenatoSilva suffers of /clearing-screen-all-the-time syndrom and didn't read last message
[03:23] <RenatoSilva> fullermd: I think when I release the targeted milestone 'next-release' (I use date-based versions) that info will stay on the bug. So the bug affects at least the prior milestone
[03:51] <jderose> bzr sattus
[03:51] <jderose> bzr diff
[03:51] <jderose> hehe, crap, wrong window  ;)
[04:02] <meoblast001> is 725.3 KB a good file size for the .bzr directory on a 70 commit project?
[04:04] <mzz> that doesn't sound completely insane
[04:04] <mzz> wh?
[04:04] <mzz> why, even?
[04:15] <Peng_> meoblast001: Is this the one that had 10 MB of binaries?
[04:15] <meoblast001> yup :)
[04:15] <meoblast001> i think i cleaned it up a bit
[04:18] <meoblast001> Peng_: do you think it is good?
[04:18] <Peng_> Sure, why not?
[04:19] <Peng_> I don't have any actual studies to say how good that is for a project of its size, but it's not a significant amount of data unless you're on dial-up, so at that point, who cares?
[04:20] <Peng_> s/studies/data/ -- don't have to be *that* scientific
[04:20] <Peng_> meoblast001: What disk format?
[04:20] <meoblast001> SATA?
[04:20] <meoblast001> or EXT3
[04:21] <Peng_> meoblast001: I mean bzr repository format.
[04:21] <meoblast001> 1.9
[04:22] <Peng_> 2a will be smaller. And faster and just generally cooler.
[04:22] <meoblast001> i will upgradt to 2a soon
[04:23] <Peng_> :D
[06:56] <rsvp> can the new BAZAAR v2.0 write to the older formats? (assuming it can convert to the new 2a format, right?) -- must everyone on a team use the same bzr version?
[06:59] <Peng_> rsvp: Bazaar 2.0 didn't drop any of the old formats.
[07:00] <Peng_> rsvp: You don't even have to convert or anything. (Though you should. 2a rocks!)
[07:01] <rsvp> Peng_, thanks for your response -- just want to make sure to confirm answers over at #python.
[07:28] <AfC> rsvp: no, everyone on a team does not need to use the same bzr version.
[07:29] <rsvp> AfC, thanks --
[07:29] <AfC> rsvp: they just need to all be using a version that supports whatever format the team repo is in. Just the usual lowest common denominator thing.
[07:31] <AfC> rsvp: though you will accrue much greatness that lowest common denominator is 2a. It'll be worth pushing for (ie, getting people onto newer code as fast as possible, rather than lallygagging) because that format will be extant for the foreseeable future but of course bzr versions >= 2.0 will improve in other ways but building on that base.
[07:31] <rsvp> I've been upgrading using Ubuntu repository, but to upgrade via "bzr branch lp:bzr bzr.dev" from which directory should that be issued (sudo bash first)?
[07:33] <mzz> you mentioning sudo there scares me
[07:33] <AfC> rsvp: the PPA at https://launchpad.net/~bzr/+archive/ppa should always have the latest bzr release. Can you use that?
[07:33] <mzz> what are you trying to do?
[07:34] <mzz> if you're just trying to run a recent version of bzr use that ppa
[07:35] <rsvp> mzz, I want to install v2 from source.
[07:35] <mzz> why?
[07:35] <mzz> to just install v2 just use that ppa
[07:36] <rsvp> ok
[07:39] <mdz> jml, thumper, anyone around?
[07:43] <mdz> I need help with a branch incompatibility issue
[09:45] <lifeless> mdz: 'sup?
[10:29] <jelmer> Lo-lan-do: ping
[10:39] <Lo-lan-do> pong
[10:42]  * Lo-lan-do highlights jelmer
[10:44] <jelmer> Lo-lan-do: Sorry, was wondering whether a particular bug was fixed
[10:44] <jelmer> Lo-lan-do: but it seems your patches already took care of that
[10:45] <Lo-lan-do> Which one?
[13:22] <Meths> The Windows downloads show bzr-2.0.0-2-setup.exe and bzr-2.0.0-1-win32.py2.6.exe.  Is there a -2-win32 file being built or was the -2-setup only produced to fix an error in the setup file and the py2.6 file is perfectly okay to use?
[14:02] <emmajane> igc, ping?
[14:21] <awilkins> Meths: The -setup is an encapsulated py2exe applications, with it's own libraries and pre-installed plugins
[14:21] <awilkins> Meths: The python variants have no plugins and require python of the quoted version installed ; they are more suitable for someone who has more intensive plugin needs, or needs to configure a smart webserver.
[14:22] <Lo-lan-do> Shouldn't the topic mention that 2.0 is *released* now (rather than frozen)?
[14:30] <emmajane> igc, not sure if you're still up, but I'm headed out for breakfast if you want to try the merge. if not I'll look at it later this afternoon.
[15:58] <dash> congrats on the 2.0 release :)
[15:59] <dash> I am trying to upgrade Twisted's bzr repo to 2a, but it's hosted on a low-memory box, and it didn't complete before being killed
[15:59] <dash> is there a way to do the upgrade incrementally or should I just try again on a box with better specs and copy it?
[16:00] <Lo-lan-do> dash: (From a not-too-involved bystander) You may try using a swap file first.
[16:01] <dash> mmh... yeah. this is a kind of small VM
[16:01] <Lo-lan-do> My feeling is that bzr uses lots of memory, but not necessarily repeatedly, and the actual accesses feel like they're mostly local and not all around.
[16:01] <dash> maybe that'd work. can't say it excites me :)
[16:01] <Lo-lan-do> So maybe swapping won't be a performance killer.
[16:28] <meoblast001> hi
[16:30]  * SamB_XP has a feeling he's seen meoblast001 somewhere before 
[16:30] <meoblast001> yes you have
[16:30] <meoblast001> i'm the guy who constantly fears he's doing something inefficient
[16:31]  * awilkins just increased the execution time of a unit test in his project by 80% - he's definitely doing something inefficient
[16:32] <meoblast001> ok, so i just moved about a 25 line group of contiguous data up a few lines in one of my headers, is bazaar optimized to do this efficiently?
[16:32] <meoblast001> or does it just basically memorize "delete these 25 lines here, add these 25 lines here"
[16:33] <SamB_XP> awilkins: without changing the test, you mean?
[16:33] <awilkins> SamB_XP: I changed the code that's it's testing
[16:34] <awilkins> SamB_XP: I didn't think it would be that much of a change... but clearly I was wrong
[16:34] <awilkins> SamB_XP: Now I'm struggling to get the profiler installed in Eclipse because the update site is sooooo slow.
[16:35] <SamB_XP> what profiler would that be ?
[16:35] <awilkins> TPTP
[16:35] <SamB_XP> ... and why the heck would eclipse only have one update mirror ?
[16:37] <awilkins> SamB_XP: I suppose I could hunt for update mirrors.... what it needs is a way of switching between them automatically because lazy people like me are going to just check the box and hit gi
[16:37] <awilkins> go
[16:37] <SamB_XP> awilkins: what, no dialog with a list of 'em ?
[16:38] <awilkins> The update system has a list of update sites, but not a list of mirrors of update sites
[16:39] <awilkins> Even the eclipse.org site is as slow as molasses today
[16:39] <awilkins> So it's hard to find a list of mirrors :-(
[16:41] <LarstiQ> meoblast001: I wouldn't worry about it
[16:41] <meoblast001> ok
[16:41] <awilkins> It probably would remember something like that... but the group compression will probably catch that the two blocks are identical and reduce them to one object
[16:42]  * awilkins dances on "probablies"
[16:44] <SamB_XP> meoblast001: that's a tiny change anyway ...
[16:44] <SamB_XP> unless the lines are gigantic!
[16:44] <meoblast001> yeah, but it's only to make things conform with the coding standards
[16:44] <SamB_XP> I mean, as disk usage goes
[16:46]  * SamB_XP wants a dilbert tie ...
[16:46] <SamB_XP> ... you know, gravity-defying ;-P
[16:47] <SamB_XP> ... I guess if I managed to get one, I could study it and maybe win a nobel prize
[16:47] <meoblast001> SamB_XP: do you have coding standards with any of your projects?
[16:47] <SamB_XP> meoblast001: well, yeah
[16:47] <SamB_XP> a few
[16:47] <meoblast001> do you strictly enforce them
[16:47] <meoblast001> like, if you find something doesn't conform, do you fix it?
[16:48] <SamB_XP> er, well, they aren't really *my* projects
[16:48] <meoblast001> oh, ok
[16:48] <SamB_XP> at this point, I mostly work on other people's open source projects
[16:48] <SamB_XP> some of them have coding standards
[16:49] <meoblast001> oh, well, do you find it normal to strictly enforce those standards?
[16:49] <SamB_XP> some more strict than others
[16:49] <meoblast001> and clean up parts that don't follow them
[16:49] <SamB_XP> well, I guess it would depend on a few things
[16:49] <awilkins> The anal tension of the project lead, first and foremost
[16:49] <SamB_XP> some of those standards are generally pretty strict
[16:50] <SamB_XP> awilkins: well, with the less typographical standards, it may even depend on what makes more sense in the particular case
[16:50] <meoblast001> i don't think mine is too strict, but it has gotten a little more strict since i created it
[16:51] <SamB_XP> meoblast001: what specifically are you thinking about ?
[16:51] <meoblast001> what do you mean? what i'm fixing?
[16:51] <SamB_XP> I mean, what ... requirements of the standard have you tightened up on ?
[16:52] <SamB_XP> ... oh, it also can depend on whether anyone has time to fix the violation ;-)
[16:53] <meoblast001> i'm fixing the violation :P
[16:53] <meoblast001> here's my standards http://mysticgalaxies.com/wiki/index.php/Coding_Standards
[16:54] <meoblast001> but yes, i have tightened up a little so that things can be a little more consistent, and now i'm trying to fix it
[16:54] <SamB_XP> http://mysticgalaxies.com/wiki/index.php/Coding_Standards you say ...
[16:55] <meoblast001> yes
[16:56] <SamB> yeah, I just repeated it so I could open it on this computer ;-)
[16:56] <meoblast001> ah, ok :P
[16:56] <meoblast001> brb, breakfast
[16:57] <SamB> meoblast001: huh, I would call it "two space indents", given that you (wisely) require spaces rather than tabs be used for indentation ;-)
[16:58] <SamB> weird requirement on the call-parens ...
[16:59] <SamB> and calling access specifiers a level sounds weird, too -- I don't know if many editors can handle that
[17:00] <awilkins> One problem I have with coding standards is the mess they make of version histories when someone has a mass-enforcement session....
[17:01] <SamB> awilkins: yeah
[17:03] <SamB> meoblast001: oh, and I'm fairly certain that "proceed" is not the opposite of "precede" -- you probably meant "succeed" ;-P
[17:03]  * awilkins blinks    - he just managed to totally change the performance again, now it's more than 400% of it's previous execution time
[17:04] <LarstiQ> SamB: acccess specifiers as a level is the default afaik?
[17:05] <SamB> LarstiQ: I think emacs usually indents them between actual levels?
[17:13] <awilkins> Somehow I went from 31s to 49s to 130s ... I think it's all down to object boxing....
[17:14] <LarstiQ> awilkins: cricket is a much more civil sport
[17:14] <meoblast001> SamB: hm, you know what, you may be right
[17:15] <meoblast001> SamB: English is my native language but i always have trouble finding the right word when i'm writing a formal document
[17:15] <meoblast001> "following" was the word i was looking for
[17:15] <meoblast001> SamB: would you recommend i update my code to conform with it though? i suppose it's for the best
[17:17] <meoblast001> i suppose my fear is that if i let myself fix everything my OCD tells me to, before you know it i'll have a 60 GB branch and more commits than 32-bit possible
[17:17] <idnar> pfft, that's what 64-bit is for
[17:22] <meoblast001> am i freaking out way too much?
[17:26] <SamB> meoblast001: how big is your project?
[17:26] <SamB> and probably you are indeed worrying too much
[17:26] <meoblast001> big as in commits?
[17:26] <SamB> big as in lines of code
[17:26] <meoblast001> let me go check
[17:27] <meoblast001> SamB: http://www.ohloh.net/p/amethyst-mm/analyses/latest
[17:27] <meoblast001> 2000 lines of C++
[17:27] <awilkins> Teenytiny
[17:27] <SamB> indeed
[17:27] <awilkins> Let me see
[17:27] <SamB> and C++ needs quite a bit of wrangling
[17:28] <meoblast001> wrangling?
[17:28] <meoblast001> yes, it is very small
[17:28] <meoblast001> this project started in March
[17:28] <SamB> it's very badly behaved ;-P
[17:28] <meoblast001> my .bzr directory totals 724.7 KB
[17:28] <SamB> however, I think in future you may want to add more substantive things to your coding standard ;-)
[17:28] <meoblast001> substantive?
[17:29] <SamB> you know, things about what code should and should not *do*
[17:29] <meoblast001> oh, why's that?
[17:29] <meoblast001> well, what kinds of things could that be
[17:29] <meoblast001> don't set an unsigned integer to a negative number?
[17:30]  * awilkins has 22k lines of Java which is 1.7MB of code in a branch that's 14MB of packs
[17:30] <SamB> oh, I don't know
[17:31] <meoblast001> what's a good ratio of repository_size:commits
[17:32] <awilkins> And most of that 14MB is java libraries that I committed to the branch before I removed them and went all Maven on it's ass
[17:34] <SamB> meoblast001: well, it depends what you are doing ;-)
[17:38] <meoblast001> SamB: well, is 724.7 KB a normal amount for a 70 commit typical C++ applications?
[17:41] <SamB> I try to stay away from C++ programs of that size for the most part
[17:41] <SamB> the only thing I can think of that might draw me to such a thing is LLVM ...
[17:42] <meoblast001> SamB: wait, so it's too big?
[17:44] <SamB> meoblast001: too many lines of C++ for *me*, yeah
[17:44] <SamB> I don't really like C++
[17:44] <meoblast001> too many lines or too large of a repository size?
[17:45] <SamB> wait, wait, there was no size there ..
[17:45]  * SamB is confused
[17:46] <meoblast001> 724.7 KB
[17:47] <SamB> I meant, there was no amount of code there
[17:49] <meoblast001> 2000 lines
[17:49] <meoblast001> plus some build tools
[17:49] <LarstiQ> meoblast001: the code style changes will make annotation less useful
[17:49] <LarstiQ> meoblast001: that's the only thing I'd worry about
[17:49] <meoblast001> annotation?
[17:49] <LarstiQ> meoblast001: `bzr annotate`
[17:50] <LarstiQ> meoblast001: anyway, you can test what the result is, and if you don't like it, roll back to a previous revision
[17:50] <meoblast001> origin of each line in a file?
[17:50] <LarstiQ> meoblast001: yup
[17:50] <meoblast001> what use would that have?
[17:50] <LarstiQ> meoblast001: finding out when/why/by whom bugs are introduced
[17:51] <meoblast001> oh
[17:51] <Lo-lan-do> Automated finger-pointing!
[17:51] <meoblast001> :P
[17:51] <Lo-lan-do> Well, assisted, anyway.
[17:51] <Lo-lan-do> "Automated" would be with bisect.
[17:52] <meoblast001> POTFILES is not required if there's a POTFILES.in, right?
[17:53] <meoblast001> ok, just ran a test, it is not
[17:53] <Lo-lan-do> Okay, I'm fed up.  How do I fix stuff like "sha1 mismatch: ('…', '…') has sha1 f10eb6688e35bb6da12bb960b0ef58a3573e26d1 expected da39a3ee5e6b4b0d3255bfef95601890afd80709 referenced by lolando@debian.org-20090921073025-t9nre0sg59ma0i0z" errors?
[17:54] <LarstiQ> Lo-lan-do: reconcile?
[17:54] <Lo-lan-do> Done.  Several times.
[17:54] <jelmer> Lo-lan-do: that suggests dat ahas been inserted with the wrong sha1
[17:55] <jelmer> Lo-lan-do: unless you have data corruption on disk, it's probably a bug somewhere
[17:55] <Lo-lan-do> I recently did a check, found that the *one* revision listed was a head, uncommitted/recommitted it, and another check gives me another revision.
[17:56] <Lo-lan-do> This is on a fresh repo cloned from an old one, so I would have expected the stuff to be correctly inserted.
[17:56] <Lo-lan-do> 2.0.0-1 from Debian, 2a format, no frills.
[17:57] <Lo-lan-do> And it takes my computer about two hours to run bzr check in there, so I'd rather avoid fixing all these errors by hand.
[18:02] <meoblast001> SamB: it jumped to 731.9 KB
[18:02] <meoblast001> i uppose that's not much
[18:02] <meoblast001> 7.2 KB in 1 commit
[18:03] <Lo-lan-do> meoblast001: What format are you using?
[18:03] <meoblast001> 1.9
[18:03] <Lo-lan-do> 2a is more compact, if you can afford it.
[18:03] <meoblast001> afford it?
[18:03] <meoblast001> i will switch to 2a once 2.x is stable and most people are using it
[18:03] <LarstiQ> don't have older clients that can't read the format
[18:03] <Lo-lan-do> It needs all clients to be at least 1.17, I think.
[18:04] <meoblast001> oh, that should be no problem
[18:04] <meoblast001> i have no problem with forcing people to upgrade >:)
[18:05] <meoblast001> i suppose i'm worrying because i don't want my project to be one of those annoying projects that makes people say "30 minutes and you're still not done?!"
[18:06] <meoblast001> i've ran into projects that have huge source repositories
[18:06] <Lo-lan-do> You're at 70 revisions and 700 KB.  Unless you're doing dial-up over smoke signals, you're fine.
[18:06] <meoblast001> ok
[18:11] <SamB> meoblast001: this is how I feel today, btw, so if I say something strange-sounding... http://naesten.blogspot.com/2009/09/cant-haskell.html
[18:12] <meoblast001> SamB: you program in Haskell?
[18:13] <meoblast001> i kant python today... i has the dumb
[18:16] <SamB> meoblast001: I'm not saying I can't haskell, but I definately feel like I has the dumb!
[18:16] <meoblast001> :P
[18:17] <SamB> though python might actually be harder for me when I feel like this ...
[18:17] <meoblast001> speaking of Python, i think Bazaar is the best Python program out there
[18:18] <meoblast001> one of the developers on my project says he doesn't like our use of Bazaar because it depends on the unstable Python.. i said at least Bazaar is written well enough in Python to be stable :P
[18:19] <SamB> what, you mean the way they keep changing it?
[18:19] <SamB> no, that can't be what you mean
[18:19] <SamB> bazaar changes way more often than Python does ;-)
[18:19] <LarstiQ> unstable Python?...
[18:29] <SamB> LarstiQ: I guess maybe he was thinking of what happens when you make a typo and don't retest your code?
[18:32] <LarstiQ> SamB: or maybe that it has more language changes than Fortran in a 10 year period?
[18:32] <SamB> LarstiQ: I'm going to need to see sources on that
[18:33] <SamB> I mean, unless you're talking about Python 3000
[18:40] <LarstiQ> SamB: all 2.x versions have introduced something
[18:40] <LarstiQ> SamB: I still don't find that unstable, I'm just speculating as to what meoblast001' colleague could mean
[18:41] <meoblast001> i'm not upgrading for the same reason people often doing take a vaccine when it first comes out
[18:42] <meoblast001> the amount of people who have tested it isn't high enough
[18:42] <LarstiQ> sure
[18:42] <meoblast001> once 2.x is stable, most people will be using that, and most people will probably use 2a repositories
[18:42] <LarstiQ> meoblast001: but python 2.4 surely is welltested by now
[18:42] <meoblast001> ooh, regarding Python
[18:42] <meoblast001> i thought we were talking about 2a repositories
[18:42] <LarstiQ> meoblast001: no, "one of the developers on my project says he doesn't like our use of Bazaar because it depends on the unstable Python"
[18:43] <LarstiQ> is what I was responding to
[18:43] <meoblast001> ah, yes
[18:43] <meoblast001> he thinks Python is unstable
[18:47] <SamB> LarstiQ: do you have any idea how much fortran has changed in the last decade?
[18:47] <SamB> well, I don't have all that much idea either, to be honest
[18:59] <fullermd> I dunno about the last decade, but I know it changed a lot in the decade prior.
[19:00] <fullermd> My fortran book is slightly out of date.  But that's OK 'cuz I haven't really read it closely.
[19:00] <fullermd> Actually, I haven't gotten past the exercise in the first chapter about learning how to punch a card with my name on it...
[19:04] <LarstiQ> meoblast001: any idea why?
[19:05] <meoblast001> i think he thinks the API changes too often
[19:05] <LarstiQ> SamB: a bit, but it has standards that don't change
[19:23] <\u03b5> hi, is it possible to make a "link" to another branch with bzr?
[19:24] <SamB> you mean like lp:bzr-svn is a reference to something on samba.org ?
[19:25] <SamB> (iirc)
[19:25] <\u03b5> "branch blabla can be checked out in this directory"
[19:31] <zsquareplusc> \u03b5: what exactly do you expect to happen? e.g. that updating one branch also upgrades an other?
[19:31] <\u03b5> or (branching+)checking out one indeed
[19:32] <zsquareplusc> migrating from SVN? ;-)
[19:32] <\u03b5> nah, SVN is far away behind from me
[19:33] <\u03b5> I figured out about that feature in svn and thought it could be pretty nifty
[19:33] <\u03b5> but no biggie if it's not in bzr
[19:37] <zsquareplusc> i once asked about something similar to svn:exetrnals and was told that the same feature does not exits in bzr, but https://launchpad.net/config-manager would be helpful in such cases
[19:45] <\u03b5> oh well, that would be a bit overkill :)
[20:10] <davidstrauss> I'm having trouble building 2.0.0 on RHEL 5: "bzrlib/_annotator_pyx.c:30:27: error: python-compat.h: No such file or directory"
[21:09] <jderose> davidstrauss: do you see python-compat.h in brlib/?
[21:09] <mzz> davidstrauss: full build log may be of use
[22:34] <matthewlmcclure> jelmer: got a few minutes to chat about bazaar/perforce concept mapping?
[22:43] <jelmer> matthewlmcclure: hi
[22:43] <jelmer> matthewlmcclure: yeah
[22:43] <matthewlmcclure> perforce is pretty similar to subversion, at least at a high level of abstraction
[22:43] <matthewlmcclure> it's a centralized vcs
[22:45] <matthewlmcclure> it uses some different names for commands, but for the most commonly used commands, I think there's a one-to-one mapping with Subversion
[22:45] <jelmer> does it have a concept of branches?
[22:45] <jelmer> or is everything a directory like in subversion?
[22:46] <matthewlmcclure> it versions files rather than directories
[22:46] <matthewlmcclure> you can branch/copy individual files from any path to any other path in a "depot" (repository)
[22:47] <matthewlmcclure> there is a concept of a "branch spec", which is a metadata file describing how one path is branched to another
[22:48] <matthewlmcclure> however, you can "integrate" (branch) from any path to any other path without a branch spec also
[22:49] <jelmer> hmm
[22:51] <matthewlmcclure> i've been thinking that a first version of bzr-p4 might support only a single Perforce "view" and be ignorant of any branch relationship among its files
[22:51] <jelmer> can you do operations on entire directories?
[22:51] <matthewlmcclure> yes, in the sense that such an operation would apply to all files within the given directory
[22:52] <matthewlmcclure> but i don't believe there is any versioning, or data stored associated with the directory itself
[22:52] <matthewlmcclure> (like CVS)
[22:53] <matthewlmcclure> unlike CVS, and like Subversion, Perforce has a monotonically increasing "changelist" number per server
[22:53] <jelmer> ah, ok
[22:54] <matthewlmcclure> and each changelist contains n files changed
[22:54] <jelmer> so directories are implicit I guess rather than explicit (such as in svn or bzr) ?
[22:54] <matthewlmcclure> yes, i believe so
[22:59] <zsquareplusc> the bzr-explorer "edit my tools" isn't very useful.. it opens an almost empty xml file. how am i supposed to know what to write there?
[22:59] <matthewlmcclure> i've only begun to experiment with bzr-svn.  i gather that it allows viewing an svn path as a bzr branch, letting bzr commands operate directly on the svn path.  and it supports branching from the svn path, and pushing to it.
[23:00] <matthewlmcclure> to me, branching from a perforce "view", rebasing on it, and pushing to it, would be the most valuable operations to support in bzr-p4.
[23:01] <matthewlmcclure> do you have any recommendations on where i should start, or what code i should look at to see what's necessary?
[23:03] <jelmer> matthewlmcclure: I would recommend looking at the Branch and Repository classes in Bazaar
[23:03] <jelmer> those are the objects you have to provide implementations of that are answered by p4
[23:03] <jelmer> matthewlmcclure: the wikipedia page says perforce has a commercial license
[23:04] <jelmer> do you have an indepenednt python implementation or something that is available under a GPL-compatible license
[23:04] <jelmer> ?
[23:07] <matthewlmcclure> true.  it is commercially licensed.
[23:07] <matthewlmcclure> they make some concessions for open source development.  http://www.perforce.com/perforce/price.html#opensource
[23:08] <matthewlmcclure> i haven't executed anything with them yet.
[23:08] <matthewlmcclure> git-p4 uses the command-line interface of the p4 command
[23:08] <matthewlmcclure> i've been migrating away from that toward their P4Python API
[23:08] <jelmer> so all operations would have to invoke the p4 command?
[23:08] <jelmer> matthewlmcclure: is their p4python API GPL-compatible?
[23:10] <matthewlmcclure> I don't know if the FSF would say it's compatible, but redistribution in source form is permitted.
[23:13] <matthewlmcclure> the license text is in the tarball ftp://ftp.perforce.com/perforce/r09.1/bin.tools/p4python.tgz
[23:14] <jelmer> looks like a BSDish license
[23:15]  * ScottK dons his archive-admin hat and says it's GPL compatible.
[23:15] <jelmer> ScottK: :-)
[23:16] <jelmer> matthewlmcclure: it looks like the bindings link to the p4 libraries though - what's the license of those?
[23:17] <matthewlmcclure> yes, it is.  i'm not sure what the license of the C/C++ API is.  i'm looking for it now.
[23:29] <matthewlmcclure> i can't find any license that explicitly applies to the C/C++ API
[23:32] <awilkins> SamB_XP: Heh, that Java I was writing earlier now takes 12 seconds. Seems the hashtable was really slowing it down
[23:32] <SamB_XP> awilkins: what are you using instead ?
[23:33] <awilkins> I was using a fixed-depth bucket trie... I just had a hashtable in the back as well that I forgot about
[23:33] <awilkins> It eats 150MB of data files and writes the row IDS to 1000-row files in a trie folder structure on disk in that time
[23:39] <jelmer> matthewlmcclure: as I mentioned in my other mail I think a next good step would probably be to define a clear mapping between the bzr and the p4 concepts
[23:39] <jelmer> matthewlmcclure: bzr-svn has some documents in its specs/ folder
[23:40] <jelmer> matthewlmcclure: in particular, how would bzr revision ids for p4 revisions be generated, what information should they contain, etc.
[23:42] <matthewlmcclure> thanks.  i'll have a look at what bzr-svn does in that respect and write up what i think the equivalent mapping is for p4.
[23:43] <matthewlmcclure> jelmer: i have to sign off.  thanks for your help.