| AfC | There are a bunch of people here running "Hardy" who have bzr-1.2-candidate.1 as their Bazaar version. | 00:06 |
|---|---|---|
| james_w | the package name, or as reported by --version? | 00:07 |
| james_w | if it's the latter I think that is expected. I think there were no code changes between the rc and release, so dato didn't bother making a no change upload to fix the version number. | 00:07 |
| Odd_Bloke | Evening. | 00:27 |
| rodge | evenin urself :) | 00:28 |
| james_w | hi Odd_Bloke. Glad to see you back to having your times of day the wrong way round. | 00:32 |
| * Odd_Bloke is going to bed as soon as his pizza arrives (and is NOM NOM NOM'd). | 00:33 | |
| poolie | hello | 00:35 |
| james_w | hi poolie | 00:37 |
| rodge | hey, quick question. if i wanna publish a branch to a server with ssh, does it have to have bzr installed? | 00:38 |
| james_w | rodge: no, but it is more efficient if it is. | 00:39 |
| james_w | if it isn't use sftp:// urls, if it is use bzr+ssh:// urls | 00:40 |
| rodge | ok, thanks heh. i would install it there if i could, but, school server =P | 00:40 |
| james_w | rodge: you can install it by downloading it if it's just a question of permissions. | 00:41 |
| james_w | use BZR_REMOTE_PATH if you do that. | 00:41 |
| james_w | obviously don't if just downloading it will get you in trouble :) | 00:42 |
| rodge | heheh, nah, and they have python 2.4 at least, so i'll try that | 00:42 |
| rodge | thanks alot | 00:43 |
| james_w | no problem | 00:44 |
| ubotu | New bug: #202710 in bzr "bzr-svn crashes with traceback when cloning a local svn file repo" [Undecided,New] https://launchpad.net/bugs/202710 | 01:01 |
| nekohayo | james_w: any news/insight on what might have happened with the weirdness in specto-jeff yet? | 01:16 |
| poolie | thanks for your post about log,james_w | 01:16 |
| james_w | nekohayo: no, sorry, I haven't tried again, and the best people probably wont be around over the weekend. | 01:16 |
| james_w | poolie: thanks, which one? | 01:17 |
| james_w | nekohayo: I'm just guessing, but I don't think it's corruption in terms of disk problems or anything, as it seems too specific for that. | 01:18 |
| nekohayo | james_w: a bug in the merge logic? | 01:19 |
| james_w | It's something like the wrong revision was recorded in a knit or something. | 01:19 |
| james_w | nekohayo: I don't think so, as upgrade fails as well | 01:19 |
| james_w | but only for -subtree, not just packs. | 01:20 |
| nekohayo | james_w: well the tree history data is corrupt though, right? | 01:20 |
| nekohayo | not corruption in terms of "the hard drive is dying" but.. | 01:20 |
| james_w | I think check should be catching the problem anyway. | 01:20 |
| nekohayo | is there a chance of fixing this? | 01:20 |
| nekohayo | is such a merge "expected" to work to begin with? | 01:21 |
| james_w | yeah, I think that's right, but as I said it's in an area of the code that I first looked at while debugging your issue, so I have no idea what is going wrong. | 01:21 |
| nekohayo | (as I'm very much a bzr beginner) | 01:21 |
| james_w | I think it should definitely be fixable, it may require a little bit of surgery. | 01:21 |
| james_w | well, it is expected to work. It won't work with no arguments to stop people from doing such a thing by accident. | 01:22 |
| nekohayo | you mean it should work with -r0..-1 but not without that, right? | 01:22 |
| james_w | however if you specify a "merge base", i.e. a revision to use as the common ancestor, which is what you are doing with -r0..1 then it will do what you want. | 01:22 |
| awmcclain | Hi all. I'm trying to debug bzr email notification. Anyone have experience with it? I've set an environment variable POST_COMMIT_TO for every user on the system. Are there any debug logs? | 01:22 |
| james_w | but as I said the resulting merge could well be quite suboptimal, as the file-ids are different. | 01:23 |
| === lamont` is now known as lamont | ||
| james_w | awmcclain: I've never used it I'm afraid. | 01:23 |
| * awmcclain cries | 01:23 | |
| james_w | awmcclain: bzr-hookless-email may be useful to you, it's a slightly different approach, and it's a bit experimental, but it suits some projects better than having everyone set up bzr-email. | 01:24 |
| james_w | awmcclain: ~/.bzr.log is the best bet for a log. | 01:24 |
| awmcclain | mmm, gotcah | 01:24 |
| awmcclain | We have a small team, really I'm just looking for global notification on commits. | 01:25 |
| james_w | awmcclain: if there is anything that looks relevant stick it in a pastebin and I'll take a gander. | 01:25 |
| james_w | the hookless thing monitors a central repo and emails when that repo is changed, by pushing or whatever. | 01:26 |
| awmcclain | oooh, sounds promising | 01:26 |
| james_w | but, as I said, it's a bit fragile, as it runs outside of bzr. | 01:26 |
| awmcclain | mm | 01:26 |
| awmcclain | does it live in launchpad? | 01:26 |
| james_w | we use it on one project I'm a member of, and sometimes it needs a poke if you notice that you didn't receive an email after a push. | 01:27 |
| james_w | I tink so | 01:27 |
| james_w | https://launchpad.net/bzr-hookless-email | 01:28 |
| james_w | http://bazaar.launchpad.net/~adeodato/bzr-hookless-email/main/annotate/dato%40net.com.org.es-20080214183337-9x3fk8kcstcv8suv?file_id=readme-20070621185945-37182pltao9vro6u-1 | 01:28 |
| awmcclain | From the bzr-email help: To have bzr send an email you need to configure an address to send mail | 01:30 |
| awmcclain | to for that branch. To do this set the configuration option ``post_commit_to`` | 01:30 |
| awmcclain | What does "set the configuration option" mean? | 01:30 |
| awmcclain | Perhaps an ENV var isn't cutting it | 01:30 |
| james_w | ah, no, env var is wrong. | 01:32 |
| awmcclain | well, there you go. | 01:32 |
| james_w | it means a bzr configuration variable. | 01:32 |
| awmcclain | ah | 01:32 |
| awmcclain | is there a way to globally set those across all branches? | 01:32 |
| james_w | if you want it user wide then ~/.bazaar/bazaar.conf | 01:32 |
| awmcclain | I want across all branches and users | 01:33 |
| james_w | or ~/.bazaar/locations.conf can be used to set it for all branches under a specific path | 01:33 |
| awmcclain | hrm... | 01:33 |
| james_w | there's no /etc/bazaar.conf unfortunately, | 01:33 |
| awmcclain | :( | 01:33 |
| awmcclain | ok, so for each user, i need to set that up | 01:33 |
| nekohayo | james_w: file-ids? delicious? | 01:33 |
| james_w | yeah, sorry. | 01:33 |
| james_w | nekohayo: sorry? | 01:34 |
| nekohayo | what is that file id thing? :) | 01:34 |
| james_w | awmcclain: you could send a message to list about supporting /etc/bazaar.conf if you like. | 01:34 |
| nekohayo | why would they be diffrent? | 01:34 |
| awmcclain | And I'm guessing that if I didn't set it for a specific user, then when that user commited, it wouldn't email. | 01:34 |
| james_w | nekohayo: bzr uses file-ids to identify paths, rather than paths. | 01:34 |
| james_w | nekohayo: so when you do bzr mv it keeps the file id. This is how renames are tracked. | 01:35 |
| nekohayo | ew | 01:35 |
| awmcclain | Are there any conf files stored by branch, rather than user? | 01:35 |
| nekohayo | that sounds like it will breakalot, no? | 01:35 |
| james_w | nekohayo: however they are generated anew on add without any more specific action. | 01:35 |
| james_w | awmcclain: .bzr/branch/branch.conf, but I doubt that setting is propogated. | 01:36 |
| awmcclain | how do you mean "propogated"? | 01:36 |
| james_w | awmcclain: i.e. it is not copied across when branching, which is obviously not what you want. | 01:36 |
| awmcclain | Ah. | 01:36 |
| james_w | awmcclain: you could have a quick test to be sure. | 01:36 |
| james_w | nekohayo: it has its downsides, yes. | 01:37 |
| awmcclain | Well, not a huge problem, since I'm only doing this for our mainline | 01:37 |
| awmcclain | Ok, great. Thank you! | 01:37 |
| james_w | nekohayo: it should possible to write a plugin to do what you want and merge based on path. | 01:37 |
| nekohayo | james_w: does that mean surgery ? | 01:37 |
| james_w | awmcclain: no problem. | 01:37 |
| james_w | nekohayo: what do you mean. | 01:37 |
| nekohayo | yeah, I doubt I could write such a plugin though :) | 01:37 |
| nekohayo | well does that mean that it will refuse to merge, conflict everywhere and/or duplicate files/eat files? | 01:38 |
| james_w | awmcclain: if you find yourself doing something suboptimal please email the list to ask for something that would suit you better. | 01:38 |
| awmcclain | james_w: Will do. | 01:38 |
| james_w | awmcclain: I think we have a few downsides to out config file handling, shown by your use case. | 01:38 |
| awmcclain | S'ok. | 01:39 |
| awmcclain | I <3 bzr | 01:39 |
| james_w | nekohayo: conflict everywhere at a guess, so that is obviously the worst outcome in your case. | 01:39 |
| james_w | as it doesn't really help you merge the contents of the files. | 01:39 |
| awmcclain | As shown by http://www.fluther.com/disc/7307/can-i-import-my-git-repository-into-subversion/ | 01:39 |
| james_w | awmcclain: nice :) | 01:42 |
| nekohayo | so I will have to wait a few work days and see if the mailing list folks have an idea what happened | 01:42 |
| james_w | awmcclain: when you write that blog post please swing by here and drop us a pointer. | 01:43 |
| james_w | it's always good to read about people's experiences and the features that they like the best. | 01:43 |
| awmcclain | Sure thing! | 01:43 |
| james_w | nekohayo: I'm afraid so, as I said it's way over my head. | 01:43 |
| james_w | nekohayo: unfortunately some of the team is at pycon, so that may slow things down a bit in the next week. | 01:44 |
| nekohayo | no problem, your comments were quite insightful :) | 01:44 |
| james_w | nekohayo: I'm glad you thought so :) | 01:45 |
| AfC | Hey, I just did `bzr commit --fixes 459940` and it bailed with | 01:49 |
| AfC | bzr: ERROR: Invalid bug 459940. Must be in the form of 'tag:id'. Commit refused. | 01:49 |
| nekohayo | that makes me think... can commit --fixes have multiple numbers? (multiple bugs fixed)? | 01:49 |
| AfC | What does that mean? | 01:49 |
| james_w | AfC: In which bug tracker is the bug filed? | 01:49 |
| james_w | nekohayo: you can give --fixes multiple times. | 01:49 |
| AfC | {shrug} GNOME, although I don't see how that's any affair of Bazaar's | 01:50 |
| james_w | AfC: you have to tell it the URL and give it a tag, then it would be bzr commit --fixes gnome:459940 | 01:50 |
| AfC | james_w: bzr: ERROR: Unrecognized bug gnome:459940. Commit refused. | 01:50 |
| james_w | AfC: yeah, you have to set it up first. | 01:51 |
| * AfC is befuddled | 01:51 | |
| james_w | AfC: see bzr help bugs. | 01:51 |
| AfC | james_w: ok | 01:51 |
| james_w | AfC: I'm not a fan of the --fixes implementation. | 01:51 |
| james_w | AfC: If you want to tell me the settings you use for gnome I'll submit a patch to make it available by default. | 01:52 |
| james_w | AfC: and I'll send one now to link that error message to the help topic. | 01:52 |
| AfC | james_w: Will do | 01:59 |
| AfC | james_w: where does that fixes information get used? Anywhere in Bazaar itself? (ie, I was about to give you the URL I used, except that I wanted to check it first) | 02:06 |
| AfC | james_w: anyway, I used | 02:06 |
| AfC | bugzilla_gnome_url = http://bugzilla.gnome.org/ | 02:06 |
| AfC | {shrug} | 02:06 |
| james_w | AfC: no it is just recorded in a revision property. | 02:06 |
| AfC | caveat emptor, baby | 02:07 |
| james_w | it's not going to start sending mails to anywhere or anything. | 02:07 |
| AfC | james_w: I was thinking as I was reading that, by the way, that rather than bugzilla_gnome_url = URL | 02:07 |
| AfC | Maybe it could be in a section of its own, | 02:07 |
| AfC | perhaps | 02:07 |
| AfC | [bugs] | 02:07 |
| AfC | gnome = http://bugzilla.gnome.org/ | 02:07 |
| AfC | Anyway, it being 03:08 I should be abed | 02:08 |
| schierbeck | jelmer: ping | 02:34 |
| LeoNerd | I think I'll have to write my über-revisioncontrolsystem program sometime | 03:59 |
| LeoNerd | One that just looks at -d CVS or -d .bzr or -d .svn or -d {arch} or .... and reruns the command I typed with the right tool | 03:59 |
| LeoNerd | I'm forver trying to cvs di in bzr checkouts, or vice versa | 03:59 |
| LeoNerd | Hmm.. On second thoughts... bzr mv foo bar in a CVS checkout might go horribly wrong :) | 04:00 |
| unenough | how is darcs next to bzr? | 08:02 |
| poolie | unenough: well, the ui is somewhat similar; bzr keeps a record of history whereas darcs does not; bzr typically scales better | 08:12 |
| unenough | is there something that admittedly darcs does better? | 08:14 |
| poolie | yes, darcs is better at letting you arbitrarily combine patches in different orders | 08:18 |
| poolie | though with the caveat that it tends to give confusing merge conflicts, sometimes surprisingly so | 08:19 |
| poolie | understand that i have used darcs but am not an expert | 08:19 |
| davi | Are the bzr developers already getting the feedback exposed at the emacs email list? | 08:21 |
| poolie | yes, though i have not read all of the messages from the weekend yet | 08:22 |
| davi | great | 08:22 |
| poolie | anything in particular, or just checking? | 08:22 |
| davi | "Speed of bzr, how to use it, etc." | 08:23 |
| davi | RMS was asking for somebody "to volunteer to work with the Bzr developers" | 08:24 |
| poolie | that'd be welcome | 08:24 |
| unenough | RMS? | 08:25 |
| poolie | the report about log has already got a couple of patches from someone | 08:25 |
| davi | RMS: http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01761.html | 08:25 |
| davi | It is great how bzr is improving | 08:26 |
| poolie | yeah | 08:26 |
| unenough | what's the M for? | 08:28 |
| unenough | whoa his royal majesty stallman himself... | 08:28 |
| poolie | 'matthew', fwiw | 08:29 |
| poolie | iirc | 08:29 |
| davi | yep, Richard Matthew Stallman, http://en.wikipedia.org/wiki/Richard_Stallman | 08:30 |
| unenough | i didn't know he is so actively involved in specific projects...that's good to see | 08:31 |
| davi | I had to look for it. Wikipedia rocks. | 08:31 |
| davi | unenough, He is trying to reduce his involvement in the emacs project. He is overloaded. | 08:32 |
| davi | I have read some of the emacs-devel email list. I can be mistaken, but it seems he has designed two emacs maintainers. | 08:33 |
| unenough | designed maintainers? :) | 08:35 |
| unenough | designated? | 08:35 |
| davi | Chong Yidong and Stefan Monnier | 08:36 |
| RAOF | No, designed. He also builds humanoid robots to infiltrate society. | 08:36 |
| davi | He is infiltrating our minds. That is very dangerous. | 08:38 |
| davi | (ironic) | 08:38 |
| === poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3rc1 available for testing | https://edge.launchpad.net/bzr/1.3/1.3rc1 | ||
| ubotu | New bug: #202778 in bzr "false test failure when run in a directory containing the version name" [High,Confirmed] https://launchpad.net/bugs/202778 | 09:40 |
| Peng | Yay | 09:46 |
| Peng | bzr-svn is fun! | 09:58 |
| === mwhudson_ is now known as mwhudson | ||
| Peng | Uh-oh, bzr-svn is only half done importing this branch, and it's already using 300 MB of RAM. | 10:59 |
| davi | Speed of bzr | 11:14 |
| Peng | ? | 11:14 |
| davi | it needs improvement | 11:16 |
| davi | at least that is said by some emacs developers | 11:16 |
| Peng | Indeed. | 11:17 |
| davi | I do not know myself. Unfortunately I have not tried it yet. I am busy with gnuherds.org | 11:17 |
| james_w | davi: we are well aware, and it is being worked on. | 11:18 |
| james_w | when you do try it, if you have a particular performance issue then come and talk to us. | 11:18 |
| Peng | davi: That's an interesting-looking project. | 11:18 |
| davi | It is very good to know james_w. It is great see how bzr is improving! | 11:18 |
| Peng | james_w: Think I should send a patch for a one-character typo in NEWS? :) | 11:19 |
| davi | james_w, Sure james_w | 11:19 |
| james_w | Peng: go for it. | 11:21 |
| Peng | :D | 11:21 |
| james_w | Peng: have you submitted a patch before? | 11:22 |
| Peng | james_w: Oh, yeah. | 11:22 |
| james_w | cool, you know how to do it then. | 11:22 |
| Peng | james_w: Nothing major, but never anything quite as trivial as this, I think. | 11:22 |
| james_w | Peng: if you put (trivial) in the subject, or maybe [MERGE][trivial] it will get picked up quicker. | 11:24 |
| Peng | Yep. | 11:24 |
| james_w | ah, you're well on top of it I see | 11:24 |
| Peng | 75% through, 500 MB of RAM. | 11:34 |
| Peng | I'm getting nervous. | 11:34 |
| james_w | Peng: you can do an incremental pull if it doesn't make it. | 11:39 |
| james_w | Peng: are you using the python-subversion bindings with the memory leak fixed? | 11:39 |
| Peng | james_w: In my experience, "doesn't make it" is "swap to death", so that doesn't help much. | 11:39 |
| Peng | james_w: I'm using Ubuntu, so they should have at least some of the leaks fixed. | 11:39 |
| james_w | Peng: well it starts again, but it will cap the memory usage. | 11:40 |
| james_w | only hardy has the leaks fixed. | 11:40 |
| Peng | Oh. Shoot. | 11:40 |
| Peng | I'm on Gutsy. | 11:41 |
| Peng | Oh. Maybe Gutsy just had those compatibility patches. No memory leak fixes? | 11:41 |
| james_w | yeah, it was just patches to make it work in gutsy. | 11:41 |
| Peng | Crap. | 11:41 |
| Peng | Only 4k revisions on this branch. :\ | 11:42 |
| Peng | Hey, it's done! | 12:02 |
| james_w | \o/ | 12:15 |
| nekohayo | um, how come when merging foo into bar, 7 conflicts are generated, but when resolving those conflicts (or just comparing the folders in meld) there is stuff that was never merged? | 12:53 |
| james_w | nekohayo: can you explain what you mean by never merged? | 12:59 |
| nekohayo | james_w: hmm... well... maybe I should screencast it | 13:00 |
| ubotu | New bug: #202827 in bzr "bzr deadlock itself on commit" [Undecided,New] https://launchpad.net/bugs/202827 | 13:05 |
| ubotu | New bug: #202830 in bzr "bzr status slow when pending merges" [Undecided,New] https://launchpad.net/bugs/202830 | 13:10 |
| nekohayo | james_w: could you take a look? wget http://ecchi.ca:8000/strange%20merge.ogv | 13:15 |
| nekohayo | am I doing things wrong? | 13:16 |
| james_w | hey, I've never done debugging via screencast before :) | 13:20 |
| nekohayo | well it's a first :) but is that behavior normal? | 13:22 |
| nekohayo | makes me want to go back to the simplicity of centralized repos | 13:22 |
| james_w | still downloading.... | 13:23 |
| nekohayo | yeah, it's about 5mb in size | 13:25 |
| james_w | nekohayo: good question. | 13:32 |
| james_w | nekohayo: can you annotate that file in the branch in your right hand window and find out what revision it comes from. | 13:33 |
| james_w | Then see if that revision is in your left hand branch before the merge. | 13:33 |
| james_w | Have you merged these branches before? | 13:34 |
| nekohayo | uhm, I don't quite know how to do that | 13:34 |
| nekohayo | yeah, multiple times | 13:34 |
| nekohayo | but now, it makes me think that they might *not* have merged properly for this very reason | 13:35 |
| james_w | ok bzr gannotate the file in the right window before the merge. | 13:35 |
| james_w | and find the line that you want. Then read it's revision id from the window. | 13:35 |
| james_w | I mean from the bottom, sorry. | 13:36 |
| james_w | Then fire up bzr viz in the right hand window, and find that revision. | 13:36 |
| james_w | you could also use bzr graph-ancestry and show me that and the revision id. | 13:36 |
| james_w | if that line was introduced in a revision that has already been merged it may affect the resulting merge. | 13:38 |
| james_w | The other option is to give me pointers to the branches and let me have a look. | 13:38 |
| james_w | I'm just going to grab some lunch. | 13:38 |
| nekohayo | james_w: sorry I got lost here... could you try merging http://bazaar.launchpad.net/~woutc/specto/specto-woutc into your +junk/specto-jeff ? | 13:38 |
| james_w | sure | 13:40 |
| james_w | nekohayo: so, why do you expect those lines to show up in -woutc? | 13:48 |
| james_w | it appears as though -jeff added the lines since they diverged, is that right? | 13:48 |
| nekohayo | james_w: ? | 14:06 |
| nekohayo | not sure about that | 14:07 |
| james_w | nekohayo: at the end of your screencast you bring up meld with -woutc on the left and -jeff on the right. | 14:08 |
| james_w | what were you expecting to happen to the lines that you highlighted there? | 14:08 |
| nekohayo | well normally when merging, after resolving the conflict, there should not have been any difference left I presume | 14:09 |
| james_w | you have merged -woutc in to -jeff, which means that -jeff no incorporates the changes made by -woutc since they diverged. | 14:10 |
| james_w | However it's not going to go changing the files in the -woutc branch. | 14:10 |
| nekohayo | hm, but the thing is I never intentionally diverged from -woutc | 14:11 |
| nekohayo | (afaik) | 14:12 |
| nekohayo | I think pretty much the only option left is to blow up my branch and start anew since it's so messed up | 14:12 |
| Peng | If you do, save a copy. | 14:14 |
| james_w | nekohayo: hey, that's interesting, the lines do come from an old version of the -woutc branch. | 14:15 |
| nekohayo | yeah | 14:16 |
| nekohayo | I'm totally confused | 14:16 |
| james_w | ah, I think I see what has happened. | 14:17 |
| nekohayo | do tell :) | 14:17 |
| james_w | ok, so in -jeff rev 17 you merged -woutc. In that merge you kept the lines in question, when they had been removed in woutc | 14:20 |
| james_w | ah, no that's not quite right. | 14:21 |
| james_w | In that revision you removed the lines. | 14:22 |
| james_w | However in the next merge at 18 they were readded. | 14:22 |
| james_w | this means when you merge now bzr thinks that you want them, as you added them. | 14:22 |
| nekohayo | log for rev 18: "re-merge wout's changes and all that. Seems I lack competence at merging!" | 14:23 |
| nekohayo | this means that at rev 17, these were *unintentionally* removed | 14:23 |
| nekohayo | as in, "I never even noticed they were gone and was wondering why I was full of bugs!" | 14:23 |
| nekohayo | which might have been caused by something similar to the current situation? | 14:25 |
| james_w | well it seems rev 18 merges and earlier revision than 17, so that may well confuse things. | 14:29 |
| nekohayo | o_O | 14:31 |
| nekohayo | I wonder how I managed to weirden things that much | 14:32 |
| james_w | yeah, the second merge is of a revision before the lines were removed, so your resolution to take them was not so strange. | 14:32 |
| james_w | However bzr will still take the later one as a merge base, and so consider that you wanted the changes. | 14:33 |
| james_w | either because you added them, or you merged an earlier version that still had them. It considers that an intentional act, and so doesn't argue with you. | 14:33 |
| james_w | I think that is the correct behaviour. | 14:34 |
| nekohayo | ok. so, for some reason, lines were lost between 16 and 17, then I pulled them back from 17 to put them in 18, and now it's using 18 as the base, but it adds them all the time ?_? | 14:36 |
| nekohayo | actually now I realize that the history graph is quite bizarre in Olive too. | 14:38 |
| nekohayo | ugh, I'll just move that specto-jeff to specto-jeff-borked and start fresh, I only had 2 minor commits by me | 14:43 |
| nekohayo | parent branch: specto-0.3 submit branch: specto-jeff | 14:47 |
| nekohayo | what is a "submit branch"? | 14:47 |
| nekohayo | I've never seen that term before | 14:47 |
| james_w | it's what it assumes you want to submit your changes back to. | 14:50 |
| james_w | It is what it will use to compare against for bzr send. | 14:51 |
| nekohayo | ew | 14:51 |
| james_w | It is probably used elsewhere, but for I can't remember which is which. | 14:51 |
| nekohayo | any way to remove that? | 14:51 |
| james_w | edit locations.conf I think is the way. | 14:51 |
| james_w | that's ~/.bzr/locations.conf | 14:51 |
| james_w | .bazaar I mean | 14:51 |
| james_w | weird, the emacs repo is smaller in bzr than git, I wonder what they've got in theirs that is different. | 14:52 |
| dato | several (smallish) repos of mine are smaller in bzr than in git | 14:53 |
| dato | (after `bzr upgrade && pack` and `git gc --prune`) | 14:53 |
| james_w | I knew packs were good, but not that they were better than git. | 14:54 |
| james_w | I thought they were generally smaller than hg, but larger than git. | 14:54 |
| james_w | maybe the sample size is too small though. | 14:54 |
| james_w | hi dato | 14:54 |
| dato | hello james_w | 14:54 |
| jelmer | hey james, dato | 14:55 |
| james_w | hi jelmer | 14:56 |
| Peng | And a new delta format or whatever would greatly reduce the size of packs... | 15:05 |
| luks | not that greatly | 15:06 |
| Peng | I don't get how it would be a massive improvement, but that's what's been said. | 15:19 |
| ubotu | New bug: #202884 in bzr "can't merge" [Undecided,New] https://launchpad.net/bugs/202884 | 15:46 |
| nekohayo | yeah, that was me :) | 15:46 |
| j1mc | hi all - i have a quick question about bzr resolve. if i'm working on documentation and have a conflict when merging in some changes, can i do a "bzr resolve --all" and then still commit my "conflicts" as a later revision? | 16:14 |
| Peng | Why not resolve them? | 16:16 |
| Peng | That makes for kinda sucky history. | 16:17 |
| Peng | Also, I'm not sure which file "bzr resolve" would keep. It might not do what you want. | 16:17 |
| j1mc | Peng: the conflicts are updates that i've made to my own branch, while someone else has made changes to the repository. | 16:17 |
| j1mc | i know that i can copy my changes out to another directory, do a 'bzr revert" on the changes i've made, and then merge things in... | 16:18 |
| j1mc | and then re-copy my changes and commit them. | 16:18 |
| Peng | j1mc: Wait, have you committed your changes? | 16:18 |
| Peng | Err. | 16:19 |
| j1mc | no, not yet. | 16:19 |
| Peng | You shouldn't merge with uncommitted changes.. | 16:19 |
| j1mc | if i commit my changes, and then merge... what will happen if their are differences between the repositories and my branch? | 16:20 |
| j1mc | (when i go to push my changes back up) | 16:20 |
| Peng | D'oh, I just wanted to say something to nekohayo. | 16:26 |
| j1mc | Peng: what would you recommend in this situation. i'm sure others have run into this before. | 16:27 |
| Peng | j1mc: I'd recommend committing (or shelving your changes) before merging, and resolving the conflicts immediately. Doing other things would pollute the history. | 16:27 |
| j1mc | so - bzr commit -m "whatever"... then bzr merge (which is likely to indicate conflicts)... then bzr resolve... then bzr push? | 16:29 |
| spiv | j1mc: you'd need to commit after the merge | 16:29 |
| spiv | j1mc: a merge is a change to the tree just like any other, so it isn't recorded until you commit it. | 16:30 |
| === zirpu_ is now known as zirpu | ||
| j1mc | spiv: thanks. yes. so in my example above, the second commit would come after i completed the merge (with all conflicts resolved), but before the push. | 16:31 |
| spiv | j1mc: so you'd commit your work, then do bzr merge + resolve conflicts (if any) + bzr commit -m "Merged branch X.". | 16:31 |
| spiv | Right. | 16:31 |
| j1mc | thanks, spiv and Peng | 16:31 |
| spiv | So you're keeping your changes in separate revisions to the changes you're merging in. | 16:32 |
| j1mc | will pushing back up my changes after doing the above show the previous person's revisions as (1) reverted changes done by me, and then (2) changes committed by me (even though they were the one who made the updates the to the repository? | 16:37 |
| spiv | j1mc: pushing will make the remote branch be the same as your local branch | 16:39 |
| spiv | j1mc: are you and the other person both pushing to the same branch? | 16:40 |
| j1mc | spiv: yes | 16:40 |
| spiv | j1mc: it'll probably be less confusing if you both use a checkout of that branch, rather than independent branches that you then push over the top of the central branch. | 16:42 |
| spiv | j1mc: you can reconfigure your current branch to be a checkout by using "bzr reconfigure --checkout" | 16:43 |
| j1mc | spiv: so do bzr checkout instead of bzr merge? | 16:43 |
| spiv | j1mc: then when you do "bzr commit" the new revision will be added directly to the master branch. | 16:43 |
| spiv | j1mc: you'd generally then both use "bzr update" + "bzr commit" rather than "bzr merge" + "bzr commit". | 16:44 |
| j1mc | ok. thanks for your help. i feel a bit like i'm a total noob, but i just don't want to keep making the same mistakes. | 16:44 |
| j1mc | ok | 16:45 |
| spiv | j1mc: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-central-style describes the workflow I'm talking about. | 16:45 |
| j1mc | thanks. i had committed my changes, bringing me from revision 3657 to 3658, and then merged in the updates from the server, but have not yet committed them. | 16:46 |
| j1mc | i did a bzr revert, which "unmerged" the merges, and have copied my changes to a different dir. how can i do a bzr revert to get back to 3657? | 16:47 |
| j1mc | i think i got it... | 16:47 |
| j1mc | bzr revert -r 3657 | 16:48 |
| spiv | j1mc: that will give you a copy of the files at 3657, but it doesn't uncommit the last revision | 16:49 |
| spiv | j1mc: so e.g. "bzr revno" will still say 3658, and "bzr status" will report that there are changes (because the files in the tree aren't identical to 3658). | 16:49 |
| spiv | j1mc: so depending on what you want, you may want to use "bzr uncommit" as well. | 16:50 |
| j1mc | spiv: thanks so much. | 16:51 |
| spiv | j1mc: not a problem. | 16:51 |
| j1mc | doing the bzr reconfigure --checkout was a big help, and will prevent embarrasing "uncommits/recommits" of other people's work going forward. so thanks for taking the time to understand my problem. have a good day! | 16:54 |
| Odd_Bloke | Morning. | 17:36 |
| Odd_Bloke | james_w: _Now_ I'm sleeping and waking at the wrong times. :p | 17:36 |
| schierbeck | hi guys | 17:43 |
| schierbeck | i've been thinking -- why are bugfix markers revision properties? | 17:43 |
| schierbeck | i mean, only one revision can actually fix a bug | 17:43 |
| schierbeck | so wouldn't it make sense to have it be a branch property? | 17:44 |
| schierbeck | unless you count in regressions... | 17:44 |
| nekohayo | Peng: the specto-main branch comes from having branched a svn tree | 17:44 |
| nekohayo | is it what made it a rich-root-pack? | 17:45 |
| Odd_Bloke | schierbeck: If only one revision can actually fix a bug, then surely having it as a property of that revision makes sense? | 17:45 |
| nekohayo | do I need to fix it in some way? | 17:45 |
| lwnjake | anyone know about fast-import errors when trying to convert a git repo? | 17:45 |
| Odd_Bloke | If, however, a series of revisions are needed to fix the bug, _then_ I think having it as a branch property would make sense. | 17:45 |
| james_w | Odd_Bloke: :-) | 17:45 |
| lwnjake | or should i use tailor instead? | 17:46 |
| schierbeck | Odd_Bloke: but many revisions can then mark the same bug as fixed | 17:46 |
| Odd_Bloke | Where I take 'need' to mean 'need to pull/merge into your branch to fix the bug'. | 17:46 |
| Odd_Bloke | schierbeck: I don't know, I wasn't disagreeing with you per se. :p | 17:46 |
| Odd_Bloke | Anyhow, I need to grab some breakfast^Wdinner. | 17:46 |
| schierbeck | i was thinking more of a mapping from bug id to revision id in the branch itself | 17:47 |
| schierbeck | hehe | 17:47 |
| james_w | lwnjake: hi. | 17:47 |
| james_w | lwnjake: the importer is still pretty rusty. | 17:47 |
| lwnjake | james_w: howdy | 17:47 |
| james_w | lwnjake: if you want to paste your error I can see if it's something obvious. | 17:47 |
| lwnjake | so is tailor the right way to go? | 17:47 |
| lwnjake | bzr: ERROR: Revision {('jake@lwn.net-20080127054407-u8wwscgv6ze5vumc',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xcaaa42c>". | 17:48 |
| james_w | lwnjake: you probably stand more of a chance with tailor. | 17:48 |
| james_w | but I've heard it's a bit of a pain. | 17:48 |
| lwnjake | heh, thanks! :) | 17:48 |
| Odd_Bloke | schierbeck: Well, my thinking is that I often don't fix a bug in one cherry-pickable revision, so setting a bug-fix property on that revision makes the assumption that all of its history comes with it. | 17:48 |
| james_w | lwnjake: that's odd. Do you get a traceback? | 17:48 |
| lwnjake | nope, just that ... | 17:49 |
| Odd_Bloke | Of course, I may simply not understand how cherry-picking revisions works. :) | 17:49 |
| james_w | lwnjake: did it take a long time to get there? | 17:49 |
| lwnjake | no, it is a pretty small repo and it did put out: 10:57:47 1000 commits processed (:3937) | 17:49 |
| lwnjake | before failing | 17:49 |
| lwnjake | less than a minute for sure | 17:50 |
| lwnjake | i tried exporting --all from git and just master from git with more or less the same results | 17:50 |
| james_w | ok, would you mind running again under "bzr -Derror" so that we get some more information? I can file a bug from that then. | 17:50 |
| james_w | or if the project is public could we just have the dump file? | 17:50 |
| lwnjake | should rm .bzr and reinit? | 17:50 |
| lwnjake | unfortunately not public | 17:51 |
| james_w | ok. | 17:51 |
| james_w | you should just be able to run again. | 17:51 |
| dato | james_w: tailor will work just fine if there are no merges | 17:51 |
| james_w | lwnjake: you can use --checkpoint to make it save state more often, it will then resume from their next time. | 17:51 |
| lwnjake | what repo on earth has no merges? | 17:51 |
| james_w | though it's not much use if you're just going to use tailor. | 17:52 |
| james_w | dato: ah, thanks. | 17:52 |
| lwnjake | git-fast-export master | bzr -Derror -fast-import -bzr: ERROR: bzrlib.errors.BzrCommandError: unknown command "-fast-import"\ | 17:52 |
| lwnjake | does the -Derror need to be somewhere else on the command line? | 17:52 |
| james_w | "bzr -Derror fast-import" | 17:52 |
| lwnjake | oh, duh! thanks | 17:53 |
| james_w | we have a set of global debugging flags all named -Dsomething. | 17:53 |
| james_w | -Derror just ensures you get a traceback from all exceptions. | 17:53 |
| james_w | we inhibit exceptions for things that are user errors. | 17:53 |
| lwnjake | want me to email it to you? it is rather long ... | 17:53 |
| james_w | However I don't think this one should be classed as a user error. | 17:53 |
| james_w | lwnjake: yeah, that's fine. | 17:54 |
| james_w | jw+debian@jameswestby.net | 17:54 |
| lwnjake | on its way ... | 17:55 |
| ubotu | New bug: #202928 in bzr "bzr diff slow against ancestor" [Undecided,New] https://launchpad.net/bugs/202928 | 17:55 |
| james_w | lwnjake: thanks. | 17:56 |
| lwnjake | james_w: no prob, now i'll try tailor and see how that goes ... thanks! | 17:57 |
| james_w | nekohayo: it looks like your issue may be reproducible against bzr.dev itself. That should certainly speed things up if it is the same bug. | 17:57 |
| james_w | lwnjake: no problem. Pop back if tailor doesn't do the job, and we can try and fix up fast-import | 17:58 |
| nekohayo | james_w: great! | 17:58 |
| james_w | lwnjake: oh, and there is also some support in bzr-git for pulling, so we could try that too. | 17:58 |
| nekohayo | james_w: so does that thing boil down to having dirstate not working with format rich-root-pack? | 17:59 |
| james_w | Peng: (of course) <- :-) | 17:59 |
| james_w | nekohayo: I have no idea I'm afraid. | 17:59 |
| james_w | nekohayo: though they do work together. | 17:59 |
| james_w | nekohayo: dirstate here refers to a knit based repo format. dirstate itself is the fast working tree format that was introduced a few releases ago, and hence gave it's name to the whole format. | 18:00 |
| james_w | It appears something is wrong with some knit based repos where the data is inconsistent. | 18:00 |
| nekohayo | oh | 18:04 |
| Peng | Wait, two people with missing indexes thanks to conversions? | 18:22 |
| Peng | Err, missing revisions in knit indexes, or whatever. | 18:22 |
| james_w | lwnjake: I can't immediately see what's wrong I'm afraid. | 18:31 |
| lwnjake | james_w: too bad, tailor seems to be annoying ... so far i haven't got it to work, but i am off on other things now | 18:32 |
| james_w | lwnjake: fair enough. Give us a shout if you have another go. | 18:33 |
| spiv | Ian will probably be finished lunch shortly. | 18:35 |
| spiv | He might be alble to help. | 18:35 |
| RyanRyan52 | is there an apache module for bazaar like there is for subversion? | 18:48 |
| Peng | RyanRyan52: No. | 18:48 |
| RyanRyan52 | Is there any way to do something like that? | 18:49 |
| Peng | RyanRyan52: You can serve over regular dumb HTTP, or use the faster smart server with CGI, FastCGI, mod_wsgi or something like that. | 18:49 |
| RyanRyan52 | but then you still have to have bzr to use it, right? | 18:49 |
| Peng | RyanRyan52: What? Oh, that's what you want? | 18:49 |
| Peng | RyanRyan52: Well, you could set up a web viewer. Loggerhead, bzr-webserve, bzrweb.. | 18:50 |
| RyanRyan52 | I want to also be able to look at my code through a web browser | 18:50 |
| RyanRyan52 | thanks | 18:51 |
| Peng | RyanRyan52: If you have your branch hosted or mirrored on Launchpad, it has a Loggerhead installation. | 18:52 |
| RyanRyan52 | I can't do that... | 18:58 |
| RyanRyan52 | Its not my project. I have to host it on the owners server. | 18:58 |
| RyanRyan52 | but he will let me switch it to bzr if I get all of the things working as well or better as they did with subversion | 18:59 |
| jelmer | hey Ian | 19:07 |
| jelmer | How's Pycon? | 19:07 |
| radix | good | 19:07 |
| radix | >:) | 19:07 |
| Peng | There's a couple messages in comp.lang.python saying it sucks. That it went all commercialized. | 19:08 |
| jelmer | radix: :) | 19:08 |
| jelmer | spiv: It's a pity the pyrex stuff wasn't ready before pycon, it really rocks | 19:09 |
| Peng | What Pyrex stuff? | 19:09 |
| jelmer | Peng: bzr-svn using pyrex | 19:09 |
| Peng | Oh, cool. | 19:09 |
| Peng | Significant benefit? | 19:09 |
| Peng | Wait, would you use svn's C API then? | 19:10 |
| jelmer | yes, pyrex around svn's C API | 19:10 |
| Peng | Interesting. | 19:10 |
| jelmer | instead of the SWIG-generated bindings by the subversion folks | 19:10 |
| jelmer | all memory usage problems have gone away | 19:10 |
| jelmer | cloning samba4 now gives me a bzr process that uses less than 30Mb of RAM | 19:11 |
| jelmer | where it would previously be at least 300 | 19:11 |
| Peng | Wow. | 19:11 |
| jelmer | I haven't completed a clone successfully yet though, but it's looking very good | 19:12 |
| Peng | Y'know, there's Cython now... | 19:12 |
| jelmer | cython generates larger files than pyrex unfortunately | 19:13 |
| Peng | It's supposed to be Better and Faster and Stronger though, right? | 19:15 |
| Peng | Hmph, bzr-svn causes constant repacking. | 19:20 |
| jelmer | Peng: yeah, hopefully that'll change when RevisionLoader from bzr-fastimport gets merged into core | 19:21 |
| spiv | jelmer: should I try using your pyrex branch here? | 19:25 |
| spiv | jelmer: or is it still too raw? :) | 19:25 |
| igc | jelmer: I'd suggest including revisionloader.py in bzr-svn rather than waiting for it to merge into core | 19:27 |
| igc | at least we can speed up bzr-svn a fair amount that way | 19:27 |
| spiv | jelmer: nice | 19:30 |
| spiv | jelmer: I really like the sound of your pyrex stuff | 19:30 |
| igc | james_w: I started tracking down that 'unknown revision' bug in fastimport | 19:31 |
| james_w | igc: the one that lwnjake was having? | 19:31 |
| igc | I think so | 19:31 |
| igc | there's a bug registered already for ... | 19:31 |
| james_w | cool, do you have an idea what it is yet? | 19:31 |
| igc | imports from hg-fast-import | 19:31 |
| igc | the bug looks generic though | 19:32 |
| igc | it's related to per-file-graph tracking | 19:32 |
| igc | line 111 of revisionloader.py | 19:32 |
| igc | I'm yet to get some uninterrupted time to really think it though | 19:32 |
| james_w | igc: I was looking at that, but it looked pretty sane to me. | 19:33 |
| james_w | It seemed as if you would only pass parents that you had already generated. | 19:33 |
| igc | james_w: abentley explained what the code does in London | 19:33 |
| james_w | I'm sure I will have missed something. | 19:33 |
| igc | he did find a buglet but ... | 19:34 |
| igc | this problem is something different | 19:34 |
| igc | probably | 19:34 |
| james_w | lwnjake: https://bugs.launchpad.net/bzr-fastimport/+bug/201116 and https://bugs.launchpad.net/bzr-fastimport/+bug/197755 might be of interest if you want to track progress | 19:35 |
| ubotu | Launchpad bug 201116 in bzr-fastimport "ERROR: revision not present" [Undecided,New] | 19:35 |
| james_w | igc: is pycon over with? | 19:35 |
| igc | in the last set of lightning talks | 19:36 |
| igc | there the sprint tutorials kick off | 19:36 |
| james_w | ok. | 19:36 |
| igc | jam is doing the sprint leaders roundtable real soon now | 19:37 |
| igc | spiv and I will do the tutorials after that | 19:37 |
| james_w | As there is an export stream in the later of those two bugs I can have a look some time this week if you don't get to it first. | 19:37 |
| igc | it's reproducable using libmemcached's export | 19:37 |
| james_w | cool. | 19:38 |
| Peng | jelmer: You said Pyrex bzr-svn really improved memory usage, but what about speed? | 19:45 |
| james_w | Peng: the revisionloader should improve that for initial import and subsequent pulls. | 19:47 |
| awmcclain | Ug... this is so frustrating. What's the easiest way to see all the diffs in a particular revision? | 19:55 |
| awmcclain | s/revision/changeset | 19:55 |
| dato | awmcclain: as in `bzr diff -c $revspec` ? | 19:55 |
| awmcclain | yay! yes. | 19:56 |
| Peng | Huh. I'm running bzr-svn, with the constant repacking, and it seems one is kept just about every half hour. | 20:07 |
| lifeless | moin | 20:47 |
| thumper | lifeless: morning | 20:49 |
| thumper | what's the quickest way to get the set of revision ids in a branch's ancestry? | 21:45 |
| thumper | in bzrlib (obviously) | 21:45 |
| dato | thumper: mainline or all? | 21:46 |
| thumper | dato: all | 21:46 |
| thumper | well, even an iterable would probably do | 21:46 |
| dato | then I don't know :) | 21:46 |
| thumper | I'm thinking of an optimisation for 'missing --mine-only' that I use a lot | 21:47 |
| thumper | basically I want to know if my branch has been merged fully or not | 21:47 |
| thumper | dato: branch.repository.get_ancestry(rev_id) | 21:49 |
| thumper | but I'm not sure if that is the fastest | 21:49 |
| === brunomelo is now known as bruno_melo | ||
| mwhudson | i guess branch.repository.get_revision_graph(rev_id).keys() might be faster | 21:57 |
| mwhudson | as it doesn't order the results | 21:57 |
| mwhudson | oh er get_ancestry(rev_id, toposorted=False) | 21:58 |
| mxpxpod | I noticed that bzr-svn 0.4.8 came out... are there any plans to package it for gutsy? | 22:06 |
| * eikeon having hard time getting bzr split to work using bzr 1.2.0. I'm trying to split off a subtree into its own branch. I'd love it if someone could point me in the right direction? | 22:11 | |
| james_w | mxpxpod: hopefully we will | 22:14 |
| AfC | jelmer: tinsy bug report: when you have the bzr-svn plugin misnamed in ~/.bazaar/plugins, | 22:14 |
| AfC | `bzr plugins` says something about "try renaming it to bzr_svn" | 22:15 |
| AfC | whereas the correct name appears to be "svn" | 22:15 |
| mxpxpod | james_w: thanks | 22:15 |
| poolie | good morning | 22:15 |
| james_w | AfC: that's bzr's fault | 22:17 |
| james_w | hi poolie | 22:17 |
| james_w | AfC: the problem is that if it is misnamed the plugin gets no say in what its name should be. | 22:17 |
| AfC | Delightful | 22:17 |
| james_w | perhaps splitting "bzr_" would be sane | 22:18 |
| james_w | s/splitting/stripping/ | 22:18 |
| AfC | yeah | 22:18 |
| poolie | jml: are you coming here today? | 22:18 |
| AfC | seems a pretty common misconfiguration | 22:18 |
| james_w | AfC: indeed especially if you bzr branch lp:bzr-svn | 22:19 |
| jml | poolie: yep | 22:19 |
| jml | poolie: I'm getting a haircut first | 22:19 |
| AfC | james_w: I'm about to drop off for a bit. If you think it worthy, can you file something? | 22:19 |
| james_w | AfC: a patch is probably easiest, so I might go with that. I'll take care of it though. | 22:20 |
| AfC | james_w: you rock | 22:20 |
| james_w | rarely, I prefer a nice sit down and a cup of tea. | 22:21 |
| poolie | jml, ok, great | 22:22 |
| * eikeon wonders what format I should have my repo and branch in such that I can use bzr split? | 22:25 | |
| * eikeon currently trying rich-root | 22:25 | |
| james_w | eikeon: rich-root might work. subtree definitely will. | 22:28 |
| james_w | However split is still experimental, so it may not even work for you. | 22:29 |
| eikeon | Ah... good to know. /me doesn't see subtree listed in bzr help formats | 22:29 |
| james_w | bzr upgrade --pack-with-subtree might be it. | 22:30 |
| james_w | it's hidden as having your repo as subtree can enable behaviour that can be entirely the wrong thing for some people. | 22:30 |
| james_w | rich-root stores the data needed, but without giving the extra functionality. | 22:30 |
| eikeon | I'm ultimately trying to break up one branch I've been working on into two. In svn land I used to like putting several projects under a common root. So started doing that in bzr land before I realized the difference :| | 22:33 |
| lifeless | thumper: getting the entire set is a bad idea; its extremely likely to be a pessimisation | 22:36 |
| Odd_Bloke | eikeon: In the cases where that's been the case for me, I've explicitly removed one project from two branches. They did start as related, however. | 22:36 |
| thumper | lifeless: how would I get an interable then? | 22:36 |
| eikeon | Odd_Bloke: That might work well for me too. Thank you. /me thinks how to shuffle things around to get rid of extra level of directory in that case. | 22:40 |
| lifeless | thumper: repository.get_graph()._make_breadth_first_searcher([branch.last_revision()]) | 22:41 |
| lifeless | thumper: which I think missing already does | 22:41 |
| lifeless | in .dev | 22:41 |
| thumper | lifeless: ok | 22:41 |
| lifeless | thumper: My suggestion is as a first step to file a bug tagged performance | 22:42 |
| thumper | lifeless: I was also curious for my own playing with bzrlib | 22:42 |
| Odd_Bloke | Does anyone know what the status of getting either the 1.2 release or 1.3rc1 into unstable is? | 22:55 |
| dato | debian? | 22:55 |
| Odd_Bloke | Yeah. | 22:56 |
| dato | I'm planning on uploading 1.3rc1 tomorrow morning | 22:56 |
| Odd_Bloke | OK, cool. :) | 22:56 |
| lifeless | thumper: oh sure | 22:58 |
| lifeless | thumper: and I'm happy to keep answering questions | 22:58 |
| poolie | good morning lifeless | 22:59 |
| lifeless | hi poolie | 23:06 |
| mxpxpod | is there a way to get a bzr log with svn revision numbers using bzr-svn? | 23:14 |
| kkubasik_ | afternoon all :) | 23:18 |
| poolie | mxpxpod: i don't know, ask on the list | 23:37 |
| poolie | hello pycon | 23:37 |
| jelmer | mxpxpod: not yet | 23:38 |
| jelmer | mxpxpod: there's an open bug about it | 23:38 |
| mxpxpod | jelmer: ok, thanks | 23:38 |
| Peng | You could tag every single revision. How well does bzr do with 60,000 tags? | 23:39 |
| poolie | probably ok, but it's not a great solution | 23:39 |
| moebius_ | hello, I have a weird error using bzr 1.2 | 23:43 |
| moebius_ | AttributeError: 'HttpTransport_urllib' object has no attribute '_remote_is_at_least_1_2' | 23:43 |
| poolie | hello lamont, moebius | 23:44 |
| lifeless | poolie: I don't think we'd do well on 60K tags | 23:45 |
| lifeless | poolie: because we'd download the entire tags file on push and pull; its not versions and does not have an incremental transfer format | 23:45 |
| poolie | hm | 23:54 |
| poolie | true | 23:54 |
| cavanaug | anybody know where i can find a bzr-svn for cygwin?? I tried last night to compile everything but failed miserably... | 23:55 |
| moebius_ | hello | 23:58 |
| moebius_ | I have a weird error with bzr 1.2 | 23:58 |
| moebius_ | File "/home/acastro/Desktop/bzr-1.2/bzrlib/remote.py", line 821, in _get_parent_map | 23:58 |
| moebius_ | if not medium._remote_is_at_least_1_2: | 23:58 |
| moebius_ | AttributeError: 'HttpTransport_urllib' object has no attribute '_remote_is_at_least_1_2' | 23:58 |
| moebius_ | is this known? i haven't seen any bug reports on this | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!