| * ToyKeeper wonders if there is a way to make sftp://host/path resolve to host:path instead of host:/path | 00:20 | |
| ToyKeeper | (so, a single slash after host would be relative to $HOME, and two slashes relative to root) | 00:20 |
|---|---|---|
| abentley | ToyKeeper: You can get that effect with sftp://~/ | 00:35 |
| abentley | i.e. sftp://host/~/ | 00:35 |
| ToyKeeper | Ah, I only tried that with bzr+ssh, which didn't work. | 00:36 |
| ToyKeeper | As sftp, it's fine. I wonder if the other host is just too old to support that syntax. | 00:37 |
| lifeless | bzr+ssh doesn't support ~ yet | 00:38 |
| poolie | hello all | 00:40 |
| lifeless | hi | 00:41 |
| ToyKeeper | I don't recall the last time I wanted to specify a repo path from root instead of ~ ... good to know it's not there yet. :) | 00:42 |
| === BasicMac is now known as BasicOSX | ||
| spiv | Good morning. | 00:59 |
| onox | good night | 00:59 |
| mwhudson | hello spiv | 01:01 |
| awmcclain | "bzr: ERROR: Transport error: Server refuses to fullfil the request" is a bzr error, correct? | 01:06 |
| awmcclain | (I'm just trying to do a sanity check on this script I'm writing) | 01:06 |
| poolie | awmcclain: yes | 01:08 |
| poolie | hello kiko | 01:08 |
| poolie | abentley: hi, how about a brief call? | 01:09 |
| === LeoNerd is now known as LeoNerd_ | ||
| abentley | poolie: sure. | 01:26 |
| abentley | skype? | 01:26 |
| poolie | sure, it'll just take a few minutes to start that machine | 01:27 |
| kiko | hey poolie | 01:36 |
| spiv | poolie: Ok, I've sent that to PQM. | 01:37 |
| spiv | poolie: (James and Ian's Branch.set_last_revision_info hook) | 01:38 |
| lifeless | spiv: do we both actually reading less than full records from streams at all? | 01:41 |
| lifeless | spiv: I'm writing up the new streams api proposal in detail, and wondering whether to do the read() callable thing, or just slap bytes around | 01:41 |
| spiv | lifeless: I'm not sure. I remember doing some of the work to make that possible, I don't recall how far it got. | 01:41 |
| lifeless | just saying 'here are the bytes' seems easier to me; once we have the interface in widespread use we could version it again. What do you think? | 01:44 |
| === mw is now known as mw|out | ||
| spiv | I'm fine with what's easy. | 01:45 |
| lifeless | ok | 01:46 |
| spiv | Hmm, there's a few fully-approved things lingering on BB. | 01:46 |
| lifeless | I don't want to merge the inventory thing | 01:47 |
| lifeless | aaron raised important concerns about it in London | 01:47 |
| lifeless | that aren't addressed; for all that Ian has approved it. | 01:47 |
| lifeless | (so its not been sitting there due to lazy robert; its deliberate) | 01:47 |
| spiv | lifeless: you also have " Fix the test HTTPServer to be isolated from chdir calls made while it is running" | 01:47 |
| lifeless | that bounced with a spurious conflict I think | 01:48 |
| lifeless | NEWS update or something. Be good to merge that. | 01:48 |
| lifeless | abentley: btw, I sent a loom:Merge thing to the list yesterday; as the only other active loom dev would you like to approve/resubmit it? | 01:48 |
| spiv | (I don't actually see your inventory thing in the list) | 01:49 |
| lifeless | sorry, http://bundlebuggy.aaronbentley.com/request/<1199746830.1954.76.camel@lifeless-64> | 01:49 |
| lifeless | its resubmit | 01:50 |
| lifeless | but doing the things it lists isn't enough, is what I meant | 01:50 |
| lifeless | the problems are more conceptual than code | 01:51 |
| spiv | lifeless: well, I'm not too worried about the details of resubmit items, given the number of approved and conditionally approved items... | 02:01 |
| lifeless | sure, my memory was glitchy | 02:01 |
| spiv | That's why we have BB :) | 02:02 |
| === kiko is now known as kiko-zzz | ||
| lifeless | ok | 02:06 |
| lifeless | draft written, sending as MERGE hopeing for comments | 02:07 |
| abentley | Oh, I think I know a significant factor in the BB lockups-- the automatic merge detection seems to be triggering them. | 02:35 |
| lifeless | ah | 02:36 |
| abentley | It's a fairly long process, possibly it can be sped up. | 02:36 |
| lifeless | which reminds me | 02:37 |
| abentley | Or maybe I can reduce the period it takes out locks. | 02:37 |
| lifeless | I really need to track down the slow index lookups bug | 02:37 |
| lifeless | abentley: could you calculate the things you need to analyse, release lock, do the work, reacquire and insert results ? | 02:37 |
| abentley | That would be unspeakably awesome. | 02:37 |
| abentley | lifeless: Hard to say. The framework has hidden the fact that any locks are being acquired. | 02:38 |
| lifeless | yes, they tend to do that. | 02:38 |
| lifeless | I've become quite allergic to that behaviour as the years have gone by | 02:38 |
| abentley | In terms of the process, yes, I don't need to hit the database until I've calculated what's new. | 02:39 |
| abentley | about stacking: one case that worries me is when the owner of the stacked-on branch doesn't realize that it's stacked-on. | 02:42 |
| abentley | And deletes it, thinking it won't break anyone else. | 02:42 |
| lifeless | right | 02:42 |
| abentley | Even though the person who stacked on it made an explicit choice. | 02:43 |
| lifeless | This is why I punted on auto stacking initially, because then users are always explicitly accepting that risk. Obviously thats not viable for Just Works long term though. | 02:43 |
| lifeless | But I don't see any good way of telling people | 02:43 |
| abentley | So you're okay with it, if the user explicitly chose to stack? | 02:44 |
| lifeless | I don't see a way out | 02:45 |
| lifeless | I have minor nightmares about what happened in arch | 02:45 |
| abentley | Make it a social problem? | 02:45 |
| abentley | It's rude to stack on someone who hasn't invited it? | 02:45 |
| lifeless | yeah | 02:45 |
| lifeless | bundles are a good example of a form of stacking that works quite well | 02:46 |
| abentley | Right. | 02:46 |
| lifeless | I think it would be ok for me to branch from you, but stack on bzr.dev. For instance. | 02:46 |
| lifeless | by ok, I mean 'pretty safe' | 02:47 |
| abentley | The policy stuff I'm working on would allow me to *recommend* that if you upload stuff to my site, you should stack on my copy of bzr.dev. | 02:47 |
| lifeless | thats nice | 02:47 |
| abentley | I'm leaving out auto-stacking on the local host. | 02:47 |
| abentley | Unless the user configures it. | 02:48 |
| abentley | But no local stacking by default, since it proved controversial. | 02:48 |
| abentley | So I think we don't need a way for branches to declare that they can't be stacked on. Which means we don't need a new format for stacked-on branches. | 02:50 |
| lifeless | abentley: yup. | 02:50 |
| lifeless | (beyond it working of course :P) | 02:50 |
| abentley | Speaking of formats that don't work, if you decide supporting weaves is too painful, I'm definitely amenable to ditching them at this point. | 02:53 |
| lifeless | have a read of the doc | 02:53 |
| lifeless | I think it will be easy to work with | 02:53 |
| lifeless | and not leak abstractions everywhere | 02:53 |
| abentley | One thing I notice is that you provide a way to ensure that the stream can reconstruct a fulltext. | 03:00 |
| lifeless | the thing for inventories do you mean? | 03:01 |
| abentley | Yes, for inventories. Bundles don't do that-- they get the compression parent fulltext from the target repo, convert it to the right format, and apply the delta to it. | 03:01 |
| lifeless | generally these streams will do the same. there is a case where that does not work though for fetch | 03:02 |
| lifeless | if you look at the model1To2Helper | 03:02 |
| lifeless | instead of copying inventories it does iter_rev_trees | 03:02 |
| lifeless | tweaks the content, and serialises | 03:02 |
| abentley | Did you have more to say? | 03:04 |
| lifeless | oh sorry; email distraction. damn thing. | 03:06 |
| lifeless | so a line delta of an xml6 inventory is not safe to apply to an xml7 inventory, etc. | 03:07 |
| lifeless | thats why the inventory option exists, because one needs to be able to construct the inventories to do iter_rev_trees in the model changing helper | 03:07 |
| abentley | But an xml7 inventory can be converted into an xml6 inventory. | 03:08 |
| abentley | And the delta can be applied to that. | 03:08 |
| lifeless | so read in the inventory, parse, downgrade, serialise, then apply the delta | 03:08 |
| lifeless | ? | 03:08 |
| abentley | Right. | 03:09 |
| abentley | You can do it however you want. Just thought I'd mention the option. | 03:09 |
| lifeless | as long as we have deterministic serialisers that will work, but it feels like there is an element of risk we can avoid | 03:09 |
| lifeless | If you don't have a strong opinion I'd rather avoid having to have the text storage layer adapt back through the parsed data like that | 03:10 |
| abentley | Sure. It looks fine to me. | 03:12 |
| abentley | (Aside from the fact that it doesn't fix bug #2:-) | 03:13 |
| lifeless | *blink* | 03:13 |
| abentley | BB thinks you promised that this patch would fix bug #2. Perhaps the bug regex is too forgiving. | 03:14 |
| lifeless | ah | 03:14 |
| lifeless | I went to https://bugs.edge.launchpad.net/bzr/+bug/2 | 03:15 |
| beuno | lifeless, just for the record, I feel bad my command not found code ended up getting into the core with both you and abentley being against it :( | 03:21 |
| beuno | s/bad/not satisfied | 03:21 |
| beuno | so I'm open to go a different direction, if we can find one that makes everyone happier :) | 03:22 |
| lifeless | beuno: that was a confusing message - not that my vote was 'approve' | 03:23 |
| lifeless | *note* | 03:23 |
| lifeless | beuno: The core code without a included database I am entirely happy with. | 03:23 |
| beuno | lifeless, yes, I saw the approve, I was referring to both of you being against it, even though I split it into two, so we could discuss the remaining part separately | 03:25 |
| abentley | beuno: If I felt strongly, I'd have vetoed. I just don't like the feature very much. | 03:25 |
| abentley | So changing approach wouldn't help. | 03:26 |
| abentley | But please don't take it personally. | 03:26 |
| lifeless | beuno: thats why I'm saying my comment was confusing. The core I'm happy with. The remaining part I'm not. | 03:26 |
| lifeless | and as abentley sayss, if we felt stringly we can veto | 03:26 |
| beuno | alright, feel less bad about it being piped through with "because poolie said so" :p | 03:26 |
| lifeless | I wrote that two days ago | 03:26 |
| lifeless | and thought it included the database at the time I wrote it | 03:27 |
| lifeless | then I realised it didn't, but didn't clear the comment field when I changed the vote to approve. | 03:27 |
| lifeless | lifeless, here for your confusion. | 03:27 |
| beuno | aaah, right, ok ok | 03:27 |
| beuno | I can continue the remaining steps as a plugin and try and find consensus along the way | 03:28 |
| beuno | ah, I can't reject my own stuff on BB | 03:38 |
| spiv | beuno: huh, that's odd. Oh, because you don't have voting rights on BB in general? | 03:55 |
| beuno | spiv, yup yup | 03:57 |
| beuno | but I though I could reject my own stuff | 03:57 |
| beuno | jelmer, BB still hates me :) my patches get approved automatically (one vote), but I can't vote on other patches | 04:05 |
| lifeless | hmm, this isn't quite right | 04:05 |
| lifeless | the delta closure stuff fits the api, but the api doesn't make it clear how to serialise | 04:06 |
| lifeless | shrug; I think it will be more clear in the wash. | 04:06 |
| lifeless | actually, no - the key thing is that we're going to want to be able to ask for a full text | 04:08 |
| * lifeless goes back to api design for a bit | 04:08 | |
| poolie | spiv: reading your #213425 fix | 04:13 |
| spiv | poolie: ah cool. I'm just heading off for lunch | 04:18 |
| abentley | lifeless: I didn't realize 'till now that was a stale message. I'll look, but I very much doubt BB caused the delay. | 04:58 |
| spiv | Hmm, the set_last_revision_info hook failed to merge. | 05:15 |
| Talden | What the recommended CVS to Bazaar path (HEAD, branches and tags)? I know the cvs2svn does 'the right thing' as I've been through that process... Is the task of getting subvsersion changesets into bazaar straightforward? svn2bzr from a subversion dump dies on even the most trivial dumps I've tried. | 05:15 |
| mwhudson | there are versions of svn2bzr around that work, i don't know the details though | 05:16 |
| mwhudson | there is also cvsps-import, don't know if that does branches/tags though | 05:16 |
| AfC | spiv: that Subversion import is _still_ running. Seems to be going a bit faster, though [I have the shell script loop printing the date each cycle of 100 revisions]. | 05:16 |
| Talden | cvs2svn is amazingly good at ironing out those CVS inconsistencies. | 05:17 |
| AfC | It almost seems to imply that accessing newer revisions in an upstream Subversion repo is faster than older ones. {shrug}. It is such a travesty that the pain inflicted by this reflects poorly on Bazaar. | 05:17 |
| mwhudson | Talden: there is also bzr-svn of course | 05:18 |
| AfC | Talden: you're probably better off to go from CVS to Bazaar direct. The less intermediaries the better. | 05:18 |
| Talden | I had a look at there were mentions of svn 1.5 and patching python bindings... I'd rather not have to learn all about python to use the tool. | 05:18 |
| spiv | jamesh: your set_last_revision_info branch is failing: http://rafb.net/p/p2S39x21.html | 05:19 |
| spiv | jamesh: I'm looking into it now | 05:19 |
| Talden | the cvs2svn tool is adding git conversion, hopefully bazaar shouldn't be any harder. | 05:19 |
| Talden | It will be interesting to see what happens with repo size... CVS 2.1GB -> Subversion 1.6GB... hopefully Bazaars is a little tighter. If it's not we'll probably be forced to say bye-bye to a lot of the history to make it more manageable. | 05:21 |
| jamesh | spiv: hmm. I wonder if the conversion code should use _write_last_revision_info()? | 05:36 |
| spiv | jamesh: yeah, I was just starting to think the same thing | 05:37 |
| spiv | jamesh: after all, we don't really want the hook to fire in this case anyway | 05:37 |
| jamesh | spiv: and we don't quite have a valid branch at that point either. | 05:38 |
| spiv | Right. | 05:38 |
| spiv | So giving that branch object to a hook would definitely be a bad idea. | 05:38 |
| spiv | Using _write_last_revision_info fixes the test. I'll run the full suite and if it passes, I'll resubmit. | 05:39 |
| spiv | I suspect this is the only problem. | 05:39 |
| jamesh | well, it might be a valid branch by the time the hook is called if it didn't throw an exception earlier :) | 05:39 |
| spiv | Heh :) | 05:39 |
| jamesh | actually, it hasn't even written the branch/format at that stage | 05:39 |
| spiv | Right, so giving a branch 6 object that's pointing to a branch 5 on disk is asking for trouble. | 05:40 |
| spiv | Besides, the last_revision_info isn't being changed, so firing the hook is definitely the wrong thing to do. | 05:40 |
| spiv | jamesh: tests all pass locally, I'll resend to PQM with that one-line change. | 05:52 |
| jamesh | spiv: thanks | 05:52 |
| poolie | spiv: paramiko fix looks good | 06:31 |
| poolie | i'm going to start doing 1.4 now | 06:31 |
| abentley | Okay, Bundle Buggy should never drop mail now. | 06:44 |
| abentley | Even if hung when the mail comes in (it will just build up until processed). | 06:45 |
| spiv | abentley: nice! | 06:49 |
| jamesh | do you know why it dies occasionally yet? | 06:49 |
| poolie | is it just me or do we get a lot of lock warnings from the tests now? | 07:02 |
| lifeless | thats what prompted me to do my patch | 07:05 |
| poolie | is it still awaiting review? | 07:05 |
| spiv | We do get a lot of warnings, yeah. | 07:07 |
| poolie | it looks like there were a lot more than before | 07:09 |
| lifeless | abentley: it was in my browsers POST cache | 07:14 |
| lifeless | abentley: I hit retry and it went in; I erroneously blamed BB for the queing | 07:15 |
| siretart | hi folks | 07:46 |
| siretart | can someone look what going wrong here: http://paste.ubuntu-nl.org/62805/? is this a known bug, or did I manage to fuck up my branch on launchpad? | 07:47 |
| siretart | UserWarning: file group LockableFiles(<bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.launchpad.net/%7Esiretart/aspectc%2B%2B/debian/.bzr/repository/>) was not explicitly unlocked | 07:48 |
| ubotu | New bug: #215522 in bzr "bazaar internal error on FTP push" [Undecided,New] https://launchpad.net/bugs/215522 | 08:01 |
| poolie | siretart: hi | 08:01 |
| siretart | hi poolie | 08:02 |
| poolie | i'll check it out | 08:03 |
| siretart | I'm trying to imort that into a an rich-pack-root shared repository, using bzr 1.3 | 08:03 |
| siretart | seems to be related to that, becuase local branching does work, though | 08:04 |
| poolie | ah ok | 08:06 |
| poolie | this rings a bell | 08:06 |
| poolie | siretart: i think abentley will be around in a few hours and i think he is working on a bug related to this | 08:06 |
| poolie | sorry but i really need to finish up and leave here | 08:06 |
| poolie | if you search lp for "revision not present" you may find the bug | 08:07 |
| poolie | siretart: in your local repo would you please run | 08:15 |
| poolie | cat .bzr/repository/format | 08:15 |
| siretart | poolie: Bazaar pack repository format 1 (needs bzr 0.92) | 08:19 |
| poolie | ok | 08:19 |
| poolie | https://bugs.edge.launchpad.net/bzr/+bug/215533 | 08:19 |
| ubotu | Launchpad bug 215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New] | 08:19 |
| siretart | poolie: wow. Thanks for filing the bug. Subscribing myself now | 08:21 |
| poolie | i suggest you should either upgrade the branch on launchpad | 08:22 |
| poolie | or upgrade locally and push up | 08:22 |
| poolie | assuming you are able to write to this branch | 08:22 |
| poolie | you should just make sure you have a backup first to be sure | 08:22 |
| siretart | :) | 08:22 |
| poolie | sorry for the interruption | 08:23 |
| poolie | when it's upgraded it should be much faster though | 08:23 |
| siretart | with 'pushing up', you mean rsyncing it over sftp? (does rsync support sftp at all?) | 08:23 |
| poolie | over sftp or bzr+ssh | 08:25 |
| ubotu | New bug: #215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New] https://launchpad.net/bugs/215533 | 08:25 |
| poolie | oh obviously you can write to it | 08:25 |
| poolie | ppas building now... | 08:56 |
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr 1.4rc1 up for testing now | ||
| poolie | good night | 09:08 |
| === mwhudson_ is now known as mwhudson | ||
| spiv | poolie: hooray! | 09:23 |
| AfC | Still importing... | 09:31 |
| === mwhudson_ is now known as mwhudson | ||
| AfC | Hm. Here's a stupid question. Anyone know if you can get an svn "dump" of a subversion repository with other than local filesystem access to it? Its gotta be faster to rsync that blob down locally and then pull revisions out of it directly. 9 minutes per 100 revisions is crazy. | 09:37 |
| mwhudson | svnsync | 09:38 |
| mwhudson | i doubt it's very fast though | 09:39 |
| AfC | Whoof. Bug report, I think: If bzr-svn is in the middle of a pull, and you try and branch from that repository, bzr breaks complaining index file blah .iix not found. Shouldn't the otherwise accursed locks be preventing this? | 09:51 |
| === mtaylor is now known as mtaylor|away | ||
| j^ | hi, why does .bzr/branch/branch.conf have push_location but parent_location instead of pull_location? | 10:23 |
| poco | hi | 10:40 |
| poco | any idea on how to tunnel a bzr+ssh on windows? (windows->gateway->ssh-server) | 10:41 |
| AfC | Hm. I now have a pack that is 177.9 MB big | 12:06 |
| === thekorn_ is now known as thekorn | ||
| === mrevell is now known as mrevell-luncheon | ||
| === mrevell-luncheon is now known as mrevell | ||
| clarby | hi, is it possible to do a partial push? like, i commit A and B, but I only want to push B. | 13:50 |
| andrea-bs | clarby: are A and B two files or two revisions? | 13:52 |
| clarby | andrea-bs: ah, sorry, they are files (directories) | 13:53 |
| andrea-bs | clarby: you can revert the changes made to A, push and recommit A | 13:54 |
| clarby | ah, too much hassle .. I can just finish what I'm not done with yet and push it all | 13:55 |
| ubotu | New bug: #215674 in bzr-gtk "uncommit needs an option for saving commit messages" [Undecided,New] https://launchpad.net/bugs/215674 | 14:05 |
| ubotu | New bug: #130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 | 14:07 |
| === mw|out is now known as mw | ||
| === mtaylor is now known as mtaylor|to-home | ||
| ubotu | New bug: #215732 in bzr "bzr-buildpackage --native had an internal error" [Undecided,New] https://launchpad.net/bugs/215732 | 16:06 |
| awilkins | Ok, I just had a massive all-nighter hackathon on my current horrible++ project (involving bzr). Someone give me something to do for the next 20 minutes that isn't hacking horrible Java code :-) | 16:08 |
| bob2 | haha | 16:09 |
| awilkins | THen I can POETS | 16:09 |
| mw-home | is there a bzr-svn to go with bzr 1.4? | 16:19 |
| awilkins | jelmer: ping | 16:20 |
| dato | mw-home: no, according to jelmer in the mailing list | 16:28 |
| mw-home | dato: ouch! I need to rollback to bzr 1.3 then. | 16:28 |
| jelmer | mw-home: it's not 1.4 that's out yet btw, it's just the rc | 17:24 |
| _MMA_ | I don't know if this is a Launchpad or Bazaar question. Is there a way to keep specific files synced between branches? | 17:34 |
| jdahlin | Hi, are there any web based frontends for bzr similar to what is used on http://git.kernel.org ? | 17:35 |
| jdahlin | basically just a list of project / description / owner / last change | 17:35 |
| _MMA_ | "Automatically" synced that is. | 17:35 |
| johnny | jdahlin, so you don't consider bzr-webserve or loggerhead to be similiar? | 17:39 |
| johnny | :) | 17:40 |
| jdahlin | johnny: can I get such a view from them? | 17:40 |
| johnny | similiar is a very broad term for web viewers :) | 17:40 |
| jdahlin | oh, no, not similar enough! | 17:40 |
| johnny | you'd have to customize the code | 17:40 |
| johnny | patches are accepted i'm sure tho | 17:40 |
| jdahlin | eg, I have to do it myself! | 17:41 |
| johnny | what do you find lacking? | 17:41 |
| johnny | well some things are prolly more on the upstream developer todo than others | 17:41 |
| jdahlin | a "list of project / description / owner / last change" and being able to track on a per user basis | 17:41 |
| johnny | track on per user i'm sure is coming | 17:41 |
| johnny | sorry.. i'm not sure of the details 100% | 17:42 |
| johnny | i'm doing the same thing you are prolly :) | 17:42 |
| jelmer | jdahlin: I think webserve has such a thing, but I'm nto entirely sure | 17:50 |
| ubotu | New bug: #215797 in bzr "regression in annotate on mysql tree" [Undecided,New] https://launchpad.net/bugs/215797 | 18:08 |
| rocky | don't suppose there are gutsy packages for latest bzr-svn (0.4.9) and bzr 1.3.1 floating around? | 18:35 |
| _MMA_ | rocky: They might have been backported. | 18:36 |
| rocky | ppa has bzr 1.4rc1 and bzr-svn 0.4.6 ... which are incompatible with one another | 18:36 |
| jelmer | rocky: I've just removed bzr-svn-0.4.6 | 18:37 |
| rocky | jelmer: that... doesn't help ;) | 18:37 |
| clarby | Hmm, every other time I try to push a commit it just halts. I log into the server I'm pushing to , run break-lock, and it re-push and it works. consistently. Anyone else get this? | 18:38 |
| jelmer | rocky: at least it shouldn't complain about incompatible versions anymore.. | 18:39 |
| clarby | (and my cpu goes to 100% when it halts/hangs) | 18:39 |
| rocky | hrm, can't seem to access packages.ubuntu.com | 18:39 |
| jelmer | rocky: there's no bzr-svn compatible with bzr 1.4 | 18:39 |
| rocky | didn | 18:40 |
| rocky | *didn't suspect there was | 18:40 |
| rocky | mostly i'm just interested in using the latest bzr-svn | 18:40 |
| rocky | whatever bzr comes with that is fine | 18:40 |
| jelmer | debian sid and ubuntu hardy have the latest | 18:41 |
| rocky | don't suppose the src pkg for ubuntu hardy would just recompile on gutsy? | 18:41 |
| jelmer | I think that should work, not aware of anything that may break it | 18:43 |
| clarby | Does anyone know if you're supposed to send recipients into send_mail() in chunks, or if the MTA chunks them up? (roughly 550 email addresses). | 18:45 |
| rocky | jelmer: needs a newer version of python-central it seems | 18:46 |
| rocky | ok, looks like i'm good | 18:48 |
| rocky | jelmer: don't suppose you have a "getting started with bzr-svn" link for people who need DVCS, never used bzr, but have to deal with a company's svn repo? :) | 19:01 |
| jelmer | rocky: there's no specific documentation for bzr-svn other than the FAQ | 19:02 |
| jelmer | rocky: bzr-svn makes svn branches feel like regular bzr branches | 19:03 |
| rocky | so "bzr branch http://mysvnurl.com/something/trunk" should work just fine? | 19:03 |
| jelmer | rocky: yep | 19:03 |
| rocky | i'm getting a 401 error even tho svn has cached the credentials for my site | 19:03 |
| rocky | in other words, svn ls http://mysvnurl.com/something/trunk works fine | 19:04 |
| rocky | but branch on the same url does not | 19:04 |
| jdahlin | jelmer: do you know of a site that uses bzr-webserve, I couldn't trivally find an example | 19:04 |
| jelmer | and you're using svn+http://... as the url? | 19:04 |
| rocky | no i'm not, lol | 19:04 |
| rocky | that's what i asked you above =P | 19:04 |
| jelmer | rocky: well, the svn+ stuff is a workaround for a bug in bzr itself | 19:05 |
| rocky | gotcha | 19:05 |
| jelmer | rocky: it's only necessary if you use authentication | 19:05 |
| rocky | i jus couldn't find any docs telling me that i need to prepend svn+ to the url any place | 19:05 |
| rocky | ah | 19:05 |
| jelmer | jdahlin: no, not aware of any; sorry | 19:05 |
| jelmer | jdahlin: bzr-webserve is derived from hgweb | 19:06 |
| jelmer | jdahlin: http://code.bitlbee.org/hgweb/ contains an hgweb instance using bzr branches | 19:06 |
| jelmer | I think the layout has changed since then though | 19:07 |
| jdahlin | jelmer: perfect | 19:09 |
| javierder | ping jelmer | 19:18 |
| keescook | hi! I haven't been able to find docs for something I think should be simple to do -- I want to have some kind of hook to run syntax checks before I do a commit for my tree. where should I be looking? | 19:54 |
| exarkun | I can't create tags because my branch format is too old or something. "bzr upgrade --dirstate-tags", as suggested in the error message which is reported, doesn't fix the problem. | 20:09 |
| beuno | exarkun, what does bzr info output? | 20:10 |
| exarkun | this http://rafb.net/p/POS2mv85.html | 20:11 |
| beuno | exarkun, and what version of bzr are you using? | 20:12 |
| ubotu | New bug: #215872 in bzr-gtk "gtk.branchview.linegraph.linegraph() expets tuple but some functions still pass string" [Undecided,New] https://launchpad.net/bugs/215872 | 20:12 |
| exarkun | I tried with 1.0.0.candidate.1 on one machine and 1.3 on another with the same results | 20:12 |
| mtaylor | anybody around with zen on bzr-cvsps-import | 20:27 |
| beuno | exarkun, I really don't know, I don't use tags at all :( | 20:28 |
| beuno | maybe a plain "bzr upgrade && bzr reconcile"? | 20:29 |
| beuno | (this is me guessing though) | 20:29 |
| exarkun | hmm, bzr reconcile | 20:29 |
| beuno | exarkun, that's just to fix some problems that might arise on upgrade | 20:30 |
| jkakar | It would be cool to have a 'pull' revision identifier that would behave somewhat like last, but based on the pull history. | 20:31 |
| jkakar | For example, pull:1 would be the same as last:1. pull:2 would be the revision before the last pull, and so on. | 20:31 |
| beuno | jkakar, feel free to open a bug requesting it :) | 20:31 |
| beuno | you mean "after"? | 20:32 |
| beuno | I'm on revno 10 | 20:32 |
| beuno | bzr pull:1 would pull in revno 11 | 20:32 |
| beuno | ? | 20:32 |
| jkakar | This would make reviewing changes easier. You could pull a branch, review some changes and make comments. Then, when comments are addressed do 'bzr pull && bzr diff -r pull:2' to see the changes made since your review. | 20:32 |
| jkakar | beuno: Not quite. pull:N would be a history of revisions at the time bzr pull was called. | 20:32 |
| beuno | jkakar, hm, seems a bit more tricky, as you'd have to know what set of revisions you last pulled | 20:33 |
| jkakar | beuno: Right, I suspect that's the hard part. Make bzr pull store a revision history somewhere. | 20:33 |
| beuno | jkakar, IMHO, having what revisions you pulled would be a step closer | 20:33 |
| beuno | or even how many revisions got pulled/merged in | 20:34 |
| beuno | "now at revno X" doesn't really say much to me | 20:34 |
| jkakar | beuno: Well, I first thought I wanted exactly what you suggest, but that still means I need to remember an ID to do what I want. | 20:34 |
| jkakar | beuno: A better UI is to offer a symbol that I can use consistently. | 20:35 |
| bialix | mtaylor: hi, I did several conversion with bzr-cvsps-import and it worked for me. | 20:35 |
| beuno | jkakar, right, it's a step closer and seems easier though :) | 20:35 |
| mtaylor | bialix: have you done any of those with rich-root-pack? | 20:35 |
| bialix | no, why for? | 20:36 |
| beuno | jkakar, I might give showing what revisions you pulled a try, so if you open a bug for that one I might give it a try | 20:36 |
| mtaylor | bialix: when trying to push to a rich-root-pack repo, or trying to upgrade, we're getting this: | 20:36 |
| beuno | the other one seems a bit over my head | 20:36 |
| mtaylor | bzr: ERROR: Revision {('cvs-1:mtaylor-20070503013257-q7msvneefnm8ft54',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x2aaab1ff6050>". | 20:36 |
| bialix | mtaylor: upgrade to rich-root-pack is currently broken | 20:36 |
| jkakar | beuno: Cool, will do! :) | 20:36 |
| mtaylor | bialix: for cvs based things? or in general? | 20:36 |
| bialix | I promote importance of corresponding bug report to Critical | 20:36 |
| bialix | in general | 20:37 |
| mtaylor | upgrade to rich-root-pack being broken should be Critical... | 20:37 |
| beuno | jkakar, you can file them as separate bugs, maybe someone else can pick the other one up | 20:37 |
| awilkins | Bug is aleady raised to critical | 20:37 |
| bialix | mtaylor: sorry for my english. I already promoted it. | 20:38 |
| mtaylor | good | 20:38 |
| mtaylor | :) | 20:38 |
| mtaylor | bialix: does that explain why pushing from a cvs-imported branch to a RRP repo would also break with the same error? | 20:38 |
| bialix | Aaron said that new format pack-1.4 should land soon, that's why this bug is not fixed still, IIUC | 20:39 |
| mtaylor | um, all the various incompatible formats is starting to get un managable | 20:39 |
| mtaylor | I'm trying to move an organization to bzr, and the formats and their inability to interoperate properly is causing various amounts of bitching... fwiw of course | 20:40 |
| bialix | mtaylor: I think some common codepaths from non-rich-root to rich-root is just broken and this is affect and cvs-import too. | 20:40 |
| mtaylor | ok | 20:40 |
| mtaylor | bialix: cool. thanks! | 20:41 |
| awilkins | crazy format diversity problem ++ | 20:41 |
| bialix | currently rich-root needed only for bzr-svn | 20:41 |
| mtaylor | but packs are the good-and-efficient thing, no? | 20:41 |
| awilkins | Yes, packs ++ | 20:42 |
| awilkins | rich-root ++ also because good interop with SVN is a key adoption feature | 20:42 |
| bialix | packs is very carefully tested and widely used | 20:42 |
| mtaylor | bialix: by "packs", do you mean "--pack-0.92" | 20:43 |
| jkakar | beuno: Bug #215903 filed. :) | 20:43 |
| ubotu | Launchpad bug 215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Undecided,New] https://launchpad.net/bugs/215903 | 20:43 |
| bialix | so if you don't need bzr-svn interaction it's better to not using rich-roots | 20:43 |
| bialix | IMO, of course | 20:43 |
| beuno | jkakar, confirmed and assigned to me ;) | 20:44 |
| bialix | mtaylor: yes. | 20:44 |
| mtaylor | see, this is the thing though... I even hang out in here alot, and I obviously can't figure out what format I should be using | 20:44 |
| jkakar | beuno: Awesome, thanks! | 20:44 |
| bialix | mtaylor: better to use default format. pack-0.92 is default | 20:45 |
| awilkins | I use rich-root-pack all the time because I have a lot of branches in svn | 20:45 |
| bialix | yes, of course | 20:46 |
| mtaylor | from an i'm-an-idiot standpoint, pack-0.92 sounds much less stable than rich-root-pack | 20:46 |
| mtaylor | something about that 0.92 in the name | 20:46 |
| bialix | that's why I called them simply packs | 20:47 |
| bialix | 0.92 is version number when they was landed to bzr | 20:47 |
| awilkins | Hmph. With pack-1.4 coming up, "pack" as a format alias would be dicey | 20:47 |
| awilkins | Are packs optimised for speed or size? | 20:48 |
| beuno | awilkins, both :) | 20:48 |
| bialix | for size and speed. but some operations is still too slow with packs | 20:48 |
| awilkins | I've seen some papers where compressions formats got some serious performance boosts by sacrificing some size. | 20:49 |
| bialix | I'm still use knits for some cases | 20:49 |
| bialix | awilkins: there is plans about adding local cache for speeding things up. but still not. | 20:50 |
| ubotu | New bug: #215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Wishlist,Confirmed] https://launchpad.net/bugs/215903 | 20:50 |
| bialix | currently some operations much faster with packs, but others with knits | 20:51 |
| jdahlin | mwhudson: thanks for doing the stoqlib/stoqdrivers import and applying the pydoctor patch! | 22:04 |
| mwhudson | no worries | 22:04 |
| mwhudson | sorry for taking quite so long on the patch, it completely slipped under my radar | 22:05 |
| jdahlin | no worries | 22:05 |
| jdahlin | :-0 | 22:06 |
| jdahlin | :-) | 22:06 |
| fbond | lifeless: ping | 22:43 |
| ubotu | New bug: #78765 in bzr-gtk "Allow diff between two selected revisions in bzr viz" [Wishlist,Confirmed] https://launchpad.net/bugs/78765 | 23:31 |
| ubotu | New bug: #215996 in bzr-gtk "Select revision dialog doesn't show "sub" revisions" [Undecided,New] https://launchpad.net/bugs/215996 | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!