| schierbeck | poolie: it would be extremely awesome, but i think it needs to wait until there are python bindings for gio | 00:01 |
|---|---|---|
| schierbeck | sometimes i wish bzr had a shared library in c | 00:01 |
| schierbeck | and perhaps a gobject wrapper | 00:01 |
| LeoNerd | Reminds me.. I need to have a play with the Python CPAN module, see if I can use bzrlib from perl | 00:04 |
| mtaylor | hey guys - what's the bottom of the revision graph look like? | 00:31 |
| mtaylor | like, If I start from the top, getting the tuple of revisions attached to the top revision, and then walking down the tree from there, how do I know I've hit bottom. | 00:32 |
| mtaylor | will a revid have an empty tuple? | 00:32 |
| * mtaylor answered his own question | 00:44 | |
| mtaylor | it is, in fact, an empty tuple | 00:44 |
| james_w | how do I get a list of versioned files that are not present on the disk? | 00:51 |
| james_w | WorkingTree.list_files doesn't list missing ones. | 00:52 |
| james_w | tree.changes_from doesn't list them in removed. | 00:52 |
| james_w | perhaps I have to use the inventory and work out paths on my own. | 00:52 |
| james_w | also, how do I get the root directory of a WorkingTree? | 00:59 |
| lifeless | james_w: iter_changes | 01:09 |
| lifeless | james_w: wt.abspath('.') | 01:10 |
| === kiko is now known as kiko-zzz | ||
| james_w | thanks. | 01:10 |
| james_w | I've got something with inventory, but wt.unversion([ids]) doesn't like it if you give it two ids, one for a directory, and one for a file in that directory. | 01:11 |
| james_w | for path, ie in tree.inventory.iter_entries(): | 02:16 |
| james_w | file_id = ie.file_id | 02:16 |
| james_w | if file_id == tree.get_root_id(): | 02:16 |
| james_w | continue | 02:16 |
| james_w | relpath = tree.id2path(file_id) | 02:16 |
| james_w | raises NoSuchId too much for my liking. | 02:17 |
| Odd_Bloke | Morning. | 02:22 |
| james_w | Morning Odd_Bloke | 02:25 |
| === mwhudson_ is now known as mwhudson | ||
| * mwhudson thinks people are not sleeping at the approved times of the day! | 02:34 | |
| * Odd_Bloke has a project due in in around 12 hours. | 02:36 | |
| Odd_Bloke | Also, I woke up earlier than intended. | 02:36 |
| thumper | Odd_Bloke: ooh, what type of project? | 02:36 |
| Odd_Bloke | thumper: A stock trading game for Deutsche Bank. | 02:38 |
| Odd_Bloke | As part of our "Group Software Development Project". | 02:38 |
| thumper | Odd_Bloke: and the rest of your group are working too? | 02:38 |
| Odd_Bloke | thumper: Well, I didn't want to do it in Java, so we're using Django. | 02:39 |
| Odd_Bloke | Which means that I'm doing the majority of the coding. | 02:39 |
| Odd_Bloke | But they get to mess around with all the templating stuff. | 02:39 |
| thumper | Odd_Bloke: sounds like you're doing the majority of the work | 02:42 |
| Odd_Bloke | thumper: I'm doing the majority of the coding, they're doing the final report. | 02:45 |
| Odd_Bloke | So the work load is probably fairly even, but the work I'm doing doesn't become entirely useless to me in around 13 hours. :p | 02:46 |
| chadmiller | How does one deprecate a function in bzr src? I see the decorator and version id. Is that the current version? | 03:04 |
| chadmiller | The to-be-released next version, that is? | 03:05 |
| Odd_Bloke | chadmiller: The release in which it was deprecated (which is normally the to-be-released version). | 03:06 |
| chadmiller | Thanks. | 03:07 |
| bob2 | HACKING.txt has some details about it (but not that specific answer) | 03:08 |
| james_w | chadmiller: @deprecated_function(one_four) is probably what you want. | 03:09 |
| chadmiller | Ah. Are we too close to one_three, then? | 03:09 |
| chadmiller | Guess I'll have to add one_four. | 03:10 |
| james_w | oh yeah, it's not frozen yet is it? one_three is probably better then. | 03:10 |
| james_w | unless it's going to take a little while, and you will end up having to go with one_four anyway. | 03:10 |
| chadmiller | Nope. This is a simple patch. | 03:11 |
| bob2 | lifeless: will shallow branches save network traffic, ram and diskspace when branch'ing? | 04:17 |
| jml | bob2: not sure about memory, but for network traffic and storage, compared to standalone branches the answer is yes. | 04:19 |
| jml | bob2: not sure about branches in a shared repository though. | 04:19 |
| bob2 | yay | 04:19 |
| bob2 | trying to branch emacs has taken all my linode's memory for half an hour | 04:20 |
| jml | ahh :) | 04:20 |
| jml | are you branching directly from a remote server? | 04:21 |
| bob2 | yeah | 04:21 |
| Odd_Bloke | bob2: If you check out the webpage, there is a ready-made repository tarball you can grab. | 04:22 |
| Odd_Bloke | bob2: At http://bzr.notengoamigos.org/ | 04:22 |
| bob2 | Odd_Bloke: I know, I wanted to see how annoying actually using bzr with it would be :) | 04:22 |
| Odd_Bloke | bob2: How often are you expecting to be branching the full emacs history when developing on emacs? :p | 04:23 |
| bob2 | hah, more wondering how much complaining emacs developers are about to start doing | 04:24 |
| nxvl | Shi | 04:26 |
| nxvl | i'm looking for a getting started web | 04:26 |
| nxvl | or some development documentation to start | 04:26 |
| Odd_Bloke | bob2: As rms has said bzr is the way to go, I'm sure they'll get over it. ;) | 04:29 |
| bob2 | haha | 04:29 |
| Odd_Bloke | nxvl: http://doc.bazaar-vcs.org/latest/ has the latest bzr docs. | 04:29 |
| bob2 | nxvl: to start developing with bzr, or to start developing bzr itself? | 04:29 |
| Peng | Apparently emacs went with bzr. Congrats. :) | 04:36 |
| nxvl | bob2: bzr itself | 04:36 |
| Odd_Bloke | nxvl: http://doc.bazaar-vcs.org/latest/en/developer-guide/HACKING.html is the main Developer Guide, which is worth having a look at. | 04:38 |
| Odd_Bloke | nxvl: What sort of thing are you looking to do? | 04:38 |
| Peng | http://lwn.net/Articles/273117/ / http://lwn.net/SubscriberLink/272853/835e7363ca833e6a/ | 04:38 |
| nxvl | Odd_Bloke: i'm thinkinf on olive right now, but i will be more hapopy with the crypt and communication part | 04:40 |
| bob2 | ah, it's lwn day again | 04:41 |
| bob2 | oh no someone made a ssh lib for java called "jaramiko" | 04:41 |
| Odd_Bloke | nxvl: Olive is part of the bzr-gtk plugin (https://edge.launchpad.net/bzr-gtk), and jelmer or phanatic (and perhaps beuno?) can probably help you out there. | 04:41 |
| Odd_Bloke | nxvl: As to the other stuff, posting to the list with your interests might help you find something to work on (if there isn't already something specific you're thinking of). | 04:42 |
| nxvl | Odd_Bloke: i will take a llok at the list, thank you! | 04:43 |
| === lamont` is now known as lamont | ||
| lifeless | bob2: they may reduce peak memory in some cases | 05:05 |
| lifeless | bob2: definiately disk space | 05:05 |
| lifeless | bob2: definately less network, though obviously if you do 'log' will will have to go to the net for more stuff | 05:20 |
| LaserJock | hmm, anybody know what the status on bzr-svn is? | 05:21 |
| LaserJock | jelmer said a while ago he'd have new packages up on the PPA but I haven't seen anything yet | 05:22 |
| bob2 | lifeless: awesome | 05:22 |
| Odd_Bloke | LaserJock: He was finalising the release a couple of days ago, I think. | 05:30 |
| Odd_Bloke | Though I can't really tell you any more than that. :) | 05:30 |
| LaserJock | k | 05:31 |
| fullermd | There were a pile of commits in my mailbox from him earlier... | 05:38 |
| mlh | lifeless: what sort of state is config-manager in? Would you recommend it or perhaps something else? | 07:49 |
| mlh | your page mentions a python rewrite but no more details | 07:51 |
| lifeless | mlh: 'working' | 08:03 |
| lifeless | mlh: but nested trees are concptually better | 08:03 |
| mlh | I was thinking of something for someone use svn to use instead of svn:external | 08:15 |
| mlh | but ta | 08:16 |
| ubotu | New bug: #201725 in olive "TypeError on close Olive-gtk" [Undecided,New] https://launchpad.net/bugs/201725 | 08:45 |
| ubotu | New bug: #201727 in bzr-gtk "gcommit fails when committing to sftp server" [Undecided,New] https://launchpad.net/bugs/201727 | 08:55 |
| ubotu | New bug: #201733 in bzr-gtk "Tags with underscore in viz" [Undecided,New] https://launchpad.net/bugs/201733 | 09:30 |
| === kiko-zzz is now known as kiko | ||
| === mrevell is now known as mrevell-afk | ||
| awilkins | 201733 | 11:17 |
| awilkins | 201733#201733 | 11:17 |
| awilkins | 201733#201733# | 11:17 |
| awilkins | #201733 | 11:17 |
| awilkins | Apologies | 11:17 |
| fullermd | You missed #201733#201733 | 11:38 |
| awilkins | I was just trying to provoke ubotu | 11:50 |
| === mrevell-afk is now known as mrevell | ||
| lamont | awilkins: for that you want to say: bug 201733 | 13:18 |
| ubotu | Launchpad bug 201733 in bzr-gtk "Tags with underscore in viz" [Undecided,Confirmed] https://launchpad.net/bugs/201733 | 13:18 |
| awilkins | TA. | 13:18 |
| awilkins | Why hasn't bzr got a "bzr copy" ? (I presume the revision model doesn't allow for files to have history trees, just linear revision history?) | 13:19 |
| james_w | awilkins: it is desired to have that, but it is very tough to do with our current model | 13:20 |
| lamont | awilkins: I expect that a merge would kinda force a tree, no? | 13:20 |
| fullermd | Mostly a combination of nobody having time to get to it, and nobody being willing to fully define the semantics. | 13:20 |
| * lamont searches for the equivalent of 'git branch -l' in bzr (list of the branches in the current tree) | 13:20 | |
| awilkins | git just intrinsically supports this kind of thing because it just versions whole trees, yes? So it would notice if you split a file up or joined two together? | 13:21 |
| awilkins | lamont: I don't mean "branch revision tree" I mean "file revision tree" | 13:22 |
| fullermd | That's one way of looking at it, I guess. Another is "git doesn't track anything anyway, so tracking copies as well as anything else comes naturally" | 13:22 |
| luks | awilkins: it would notice if you tell it to notice | 13:22 |
| * awilkins still isn't comfy with git | 13:22 | |
| luks | but it's hard to do it "the bzr way", because bzr assigns a file-id to each file | 13:22 |
| luks | and you can have two files with the same file-id | 13:22 |
| fullermd | There's nothing conceptually difficult about referencing file splits/joins. It's deciding what the implications of that are that bogs you down. | 13:23 |
| awilkins | And the file doesn't have a "parentId" | 13:23 |
| awilkins | ? | 13:23 |
| luks | parent-id is it's parent directory | 13:23 |
| luks | but there is no parent-id in on the history line | 13:23 |
| luks | no 3d trees for bzr :) | 13:24 |
| lamont | awilkins: ah, as in "bzr cp a b" to make file b a copy of file a? | 13:24 |
| awilkins | Yes | 13:24 |
| awilkins | Was just an abstract thought, I don't have a real use-case for it ATM | 13:24 |
| lamont | and yeah, git does that automatically, since the id of a file is the sha1 of the file | 13:24 |
| lamont | or some such | 13:24 |
| luks | the id in git is it's name | 13:25 |
| lamont | ok | 13:25 |
| === cpro1 is now known as cprov | ||
| fullermd | A difficulty is that there are a lot of operations smashed together in that one umbrella. | 13:25 |
| luks | sha1 is it's revision id | 13:25 |
| fullermd | Splitting a file is one. Merging isn't covered at all, but would need to be. And then there's really-copying... | 13:25 |
| awilkins | THe revision id of he file, or the tree? | 13:25 |
| luks | well, in git it's called "object id" I think | 13:26 |
| lamont | awilkins: the revision id of the object. whatever "object" happens to be. | 13:26 |
| awilkins | Ah. /me hasn't studied git | 13:26 |
| lamont | (current head, patchset, etc) | 13:26 |
| lamont | so did bzr ever grow the ability to have two branches in one .bzr tree, and switch between them? or is it still "directory-per-branch, have a nice day?" | 13:27 |
| awilkins | lamont: shelve is sort-of-there | 13:28 |
| luks | it's more "directory-per-branch, have a wonderful day!" | 13:28 |
| awilkins | Or you can keep a no-trees repo of branches and use a checkout, and switch that | 13:28 |
| luks | in bzr is branch the primary object, unlike git where you work primarily with repositories | 13:28 |
| lamont | ok | 13:29 |
| lamont | that's going to be a fun paradigm shift to bounce back and forth across | 13:29 |
| lamont | luks: about the time I quit using bzr last, there weren't repositories... | 13:31 |
| james_w | lamont: yeah, switch and cbranch can approximate it. | 13:31 |
| james_w | lamont: or bzr-loom can do it if your branches have a string total ordering. | 13:32 |
| lamont | string total ordering? | 13:32 |
| james_w | no, your branches are dependent on ones lower | 13:33 |
| james_w | think quilt patch series. | 13:33 |
| lamont | ok. (quilt: how to implement a revision control system in the source package. see also: dpatch) | 13:34 |
| james_w | :-) | 13:34 |
| lamont | also known as "my revision control system sucks for merging, so we're going to reimplement that to make it less painful" | 13:35 |
| lamont | well, on one front, anyway | 13:35 |
| === thekorn_ is now known as thekorn | ||
| lamont | the only other reason for using quilt or dpatch is because you don't want to make would-be contributors learn your VCS-of-choice | 13:36 |
| === FreeNode is now known as herb | ||
| lamont | could someone remind me what the bzr equivalent of 'gitk --all' is? (or even without the --all...) | 13:39 |
| james_w | there is not equivalent to all. | 13:39 |
| james_w | --all sorry | 13:39 |
| james_w | bzr viz is equivalent to gitk | 13:39 |
| lamont | bzr: ERROR: unknown command "viz" | 13:40 |
| lamont | what magic piece am I missing, I wonder | 13:40 |
| james_w | apt-get install bzr-gtk | 13:40 |
| awilkins | You need the gtk plugins | 13:40 |
| lamont | bzr-gtk? | 13:40 |
| james_w | provides gtk GUI for some things, e.g. viz - history viewing | 13:41 |
| lamont | bzr, bzrtools, and bzr-gtk are all installed on the box... | 13:41 |
| awilkins | It's "vis" nativelt, it was written by a Brit :-P | 13:41 |
| awilkins | (but there is an alias for viz) | 13:41 |
| fullermd | Actually, it's "visualize"... | 13:42 |
| lamont | bzr: ERROR: unknown command "visualize" | 13:42 |
| james_w | lamont: are you running bzr from source? | 13:42 |
| awilkins | It's visualise | 13:42 |
| luks | `bzr plugins` | 13:42 |
| awilkins | not visualize | 13:42 |
| lamont | bzr plugins | 13:43 |
| lamont | launchpad | 13:43 |
| lamont | Launchpad.net integration plugin for Bazaar. | 13:43 |
| lamont | so obviously something b0rked between the bzr 1.2 and the bzr-gtk 0.93 versions I have... | 13:43 |
| james_w | if you are not using the system bzr it won't pick up the system plugins. | 13:43 |
| james_w | ah, you need to upgrade bzr-gtk then. | 13:43 |
| lamont | that was what I was just thinking... | 13:43 |
| * lamont refrains from commenting on the packaging decisions that lead to 5 packages that must all be upgraded together and are built from separate sources | 13:44 | |
| awilkins | Needs a meta-package that gathers them | 13:45 |
| awilkins | apt does that, no? | 13:45 |
| lamont | well, given that I have to backport bzr and bzrtools to dapper each release anyway, I'll just add bzr-gtk to the pile, for my happiness | 13:46 |
| james_w | we can't do it yet as the bazaar package FTBFS | 13:46 |
| lamont | ?? | 13:46 |
| awilkins | F**ks the basic file system? | 13:46 |
| lamont | awilkins: fails to build from source | 13:46 |
| james_w | bazaar is the baz package, we want to make it a transitional package for that, and a meta package for bzr, bzrtools, bzr-gtk, etc. | 13:47 |
| lamont | james_w: and you mean source package: bazaar? or some other package? | 13:47 |
| james_w | but we can't as it FTBFS, the maintainer is pretty AWOL, and no-one with the skills to debug the failure is that bothered about doing so. | 13:47 |
| * lamont notes that bzr-gtk 0.93.0-1 is the current version, sighs | 13:51 | |
| fullermd | I thought 0.93 worked fine with 1.2. | 13:51 |
| lamont | fullermd: well, I do freely admit that I'm running my backport of 1.2, since I had to install that on a bit over 100 systems before it actually built on dapper. | 13:52 |
| lamont | in the ppa, that is | 13:52 |
| lamont | I'm not sure if the version in the ppa is the result of my patch making it back to someone, or if it's different work | 13:53 |
| james_w | lamont: you can check ~/.bzr.log to see why the plugin didn't load. | 13:53 |
| lamont | 0.104 encoding stdout as sys.stdout encoding 'UTF-8' | 13:55 |
| lamont | 0.105 bzr arguments: [u'viz'] | 13:55 |
| lamont | 0.106 looking for plugins in /home/lamont/.bazaar/plugins | 13:55 |
| lamont | 0.106 looking for plugins in /var/lib/python-support/python2.5/bzrlib/plugins | 13:55 |
| lamont | 0.106 Plugin name __init__ already loaded | 13:55 |
| lamont | 0.106 Plugin name __init__ already loaded | 13:55 |
| lamont | 0.148 Traceback (most recent call last): | 13:55 |
| lamont | that? | 13:55 |
| lamont | ah.. it's looking in python-support | 13:55 |
| lamont | now to figure out why that is | 13:55 |
| lamont | beacuse it's a muppet. that's why. broken build for me. yeah! | 13:56 |
| lamont | (iz a gutsy build of round 1 of dapper building, which took 2 rounds to get right) | 13:56 |
| lamont | thanks | 13:56 |
| * lamont didn't know about .bzr.log | 13:56 | |
| fullermd | 'bzr version' shows a lot of that sort of info too. | 13:56 |
| lamont | bzr viz love. | 14:04 |
| lamont | thanks | 14:04 |
| james_w | lamont: glad it works for you now. | 14:06 |
| lamont | re: bazaar ftbfs... given that the answer to _ANY_ question about baz is 'switch to bzr', I expect that a package that hasn't changed in a year could be summarily executed... | 14:10 |
| james_w | lamont: except that manoj doesn't want that. | 14:11 |
| james_w | though he hasn't stepped forward to maintain the package. | 14:12 |
| lamont | and bazaar-vcs.org delivers its own packaging, and could easily introduce an epoch and shoot the debian package in the head. | 14:12 |
| lamont | that is, if the user is mixing bazaar-vcs.org and debian repos | 14:12 |
| fullermd | Didn't tla absorb pretty much all of the baz changes by the last release? | 14:12 |
| * lamont didn't care enough to ever look back at tla | 14:13 | |
| james_w | I don't know, I've never used either. | 14:13 |
| lamont | when I unified all my packages (into git) the issue I had was that I couldn't find a sane way to migrate from baz to git. and the cvs trees were kinda ugly (don't ask...) so in the end I just committed release tarballs into the git tree so as to have some history, and went from there. | 14:15 |
| lamont | that was over a year ago, iirc. | 14:16 |
| lamont | since then, I've been encouraged to use bzr... so I do. | 14:17 |
| lamont | OTOH, I don't see myself switching existing bases anytime soon.. at least not until I get a lot more comfortable with bzr | 14:18 |
| fullermd | Yeah, switching acids is a lot easier. | 14:19 |
| abentley | lamont: The bazaar package is kept around to provide a way of converting Arch/Baz archives to bzr. | 14:20 |
| lamont | well, given that (1) I'm comfortable with git and (2) need to use it anyway (kernel stuff), the result is that I get to learn both. | 14:21 |
| lamont | abentley: then it needs to get fixed... | 14:21 |
| fullermd | Git seems pretty well positioned to turn into "you have to learn it, because something you care about is going to end up using it" | 14:22 |
| * lamont plans to don his pedant hat and crusade for the FTBFS since gutsy(?) bazaar 1.4.2-5.3 binary to get removed from hardy+1 | 14:23 | |
| lamont | fullermd: that's a long winded way of saying it has a significant user base | 14:23 |
| fullermd | My way sounds more erudite. | 14:24 |
| lamont | mind you, your way is also the base reason for why bzr needs to be taught to interoperate (read and write) with git:// protocol | 14:24 |
| lamont | so that users who like the bzr UI, but have encountered said git-using software, can continue to be happy | 14:25 |
| * lamont test-builds bazaar in gutsy, just to see if it's ftbfs there, or if it's just finally b0rked in hardy | 14:26 | |
| fullermd | If that doesn't turn out to be self-defeating... | 14:26 |
| lamont | abentley: and if bazaar is ftbfs in lenny, you can bet that it stands a fair chance of being dropped from lenny before release. | 14:26 |
| lamont | yep. ftbfs in gutsy | 14:27 |
| * lamont throws it against the feisty wall | 14:27 | |
| abentley | The issue AIUI is that at least one of the libraries it requires has been received API-incompatible updates. | 14:27 |
| lamont | fullermd: the alternative is to make sure that there's enough software in bzr to force the users to learn both. In which case, the git crowd will write a git UI for bzr. | 14:28 |
| james_w | the failure is in the testsuite, so it's not incompatible to the point of failing to compile. | 14:28 |
| abentley | lamont: Please no | 14:29 |
| lamont | abentley: please no which? | 14:30 |
| abentley | No git-like UI for Bazaar. | 14:31 |
| lamont | _I_ have no plans to write one | 14:31 |
| lamont | if bzr repos ever get significant traction, you can bet that someone in the git community will, though | 14:31 |
| abentley | Git has unaccoutably horrid UI. | 14:32 |
| lamont | and it wouldn't be a "git-like UI"... it'd be git talking to a bzr repo, just like {git,bzr}-svn do today | 14:33 |
| lamont | git has an unaccountably horrid UI that is loved and/or used by many. | 14:33 |
| lamont | exposing the index to users has a big advantage for at least one use case that I regularly have | 14:34 |
| fullermd | From what I understand of how git-svn works, that will lead to long flames about the bzr CLI startup time... | 14:34 |
| lamont | specifically, when I want to require that I type in exactly which files I want in this commit, rather than accidentally committing things that I didn't mean to. | 14:34 |
| luks | but how often do you need that and how often do you commit all files? | 14:35 |
| lamont | it may be that the best stall tactic would be to implement a bzr repo interface that sits on top of a git repository and plumbing... dunno | 14:35 |
| lamont | luks: the use case is specifically /etc, being kept in $VCS for revision history/blame, and multiple users making changes on the box simultaneously. | 14:36 |
| lamont | I didn't say it was a common use case... it's one that _I_ regularly bump into | 14:36 |
| luks | I personally think that's using the wrong tool for the job | 14:37 |
| luks | but that's just me | 14:37 |
| fullermd | I certainly don't take issue with the idea of a workflow involving pre-noting the files you want to be dealt with. It's got any number of use-cases. | 14:37 |
| lamont | wasn't my decision | 14:37 |
| fullermd | But it being the _default_? That's another matter.... | 14:38 |
| lamont | fullermd: then give me the option to do that in bzr.. | 14:38 |
| lamont | and the ability to set the default on a per-.bzr instance | 14:38 |
| luks | I'd really hate if bzr had 'bzr edit', which people were suggesting on the ML, as the default | 14:38 |
| fullermd | If I could get my magic wand recharged... | 14:38 |
| igc | morning all | 14:41 |
| * fullermd waves at igc. | 14:42 | |
| igc | hi fullermd | 14:42 |
| fullermd | Waitaminute. It's morning _here_. What are YOU doing saying 'morning'? | 14:42 |
| igc | I'm in sunny Chicago at pycon | 14:42 |
| abentley | lamont: It would be pretty easy to add an --explicit-files parameter to commit, so that it would fail if no files were specified. Would that satisfy your use case? | 14:44 |
| lamont | abentley: can I make that be the default for some particular .bzr instance? | 14:44 |
| lamont | branch/repo/checkout/whatever we call that | 14:45 |
| lamont | that is, does .bzr have a file under it that is default args for various commands? | 14:45 |
| abentley | No, you could default it using an alias, but that's global. | 14:45 |
| abentley | allowing .bzr to specify command parameters would not be safe, because the branch author may not be you. | 14:46 |
| lamont | abentley: and for most repos, I'd want to not require --explicit-files | 14:48 |
| lamont | ~/.bazaar-defaults allowing me to specify it for a branch would work, I suppose... | 14:48 |
| lamont | (or whatever file it wants to be..) | 14:48 |
| lamont | that is, I as a user would like to be able to say "when I'm in this tree, require explicit files, everywhere else, don't" | 14:48 |
| fullermd | Theoretically, such a thing could be set in locations.conf. I'm not aware that the file format allows any sort of implicit nesting, though. | 14:48 |
| abentley | The format does. | 14:48 |
| abentley | Bazaar only looks for aliases in bazaar.conf, though. | 14:49 |
| fullermd | Oh, it does? I didn't know that... I thought you only got the one level. | 14:49 |
| lamont | so does this mean I should file a bug asking for --explicit-files and a way to specify default commit parameters in locations.conf? | 14:51 |
| lamont | branch: could not determine source revision from directory: /build/lamont/bazaar-1.4.2/debian/build/baz/tests/workdir/test-1-workdir | 14:51 |
| lamont | FTBFS in _FEISTY_. | 14:51 |
| lamont | well... feisty + security | 14:51 |
| lamont | actually, all the build-deps came from feisty | 14:51 |
| james_w | lamont: you could file a bug asking for an explicit-files config option, that is more what you want I think. | 14:52 |
| james_w | Unless you want to alias it for all branches. | 14:52 |
| abentley | lamont: ideally, you would submit the idea to the mailing list. | 14:55 |
| * lamont is seldom ideal. | 14:55 | |
| lamont | :-( | 14:55 |
| lamont | that would involve finding the mailing list, which would take about 15 extra seconds | 14:55 |
| abentley | lamont: It's not a bug, it's a feature request. Bugs don't usually require much discussion. Feature requests are ususally improved by them. | 14:57 |
| lamont | true | 14:59 |
| * lamont marks 201823 wishlist | 15:00 | |
| fullermd | Plus, abentley will hunt you down and drive a spear through you if you file feature requests as bugs ;) | 15:00 |
| Af1 | I know you guys don't care much about advocacy, but if you want GNOME to not switch to Git, we're really going to need to find some core GTK and GNOME people to start publicly endorsing Bazaar real soon now, or it's going to be too late. | 15:02 |
| === Af1 is now known as AfC | ||
| awilkins | What are they in now, SVN? | 15:04 |
| awilkins | I see that you mirror their repo on Launchpad | 15:05 |
| ubotu | New bug: #201823 in bzr "please add an --explict-files config option" [Wishlist,New] https://launchpad.net/bugs/201823 | 15:05 |
| * awilkins hears abently polishing his stick | 15:06 | |
| awilkins | s/stick/spear/phallic-euphemism of choice/ | 15:06 |
| abentley | lamont: If you insist on using launchpad instead of participating in discussion, could you at least use blueprints, not bugs? | 15:06 |
| lamont | abentley: I'll see what I can do. | 15:07 |
| lamont | I | 15:07 |
| AfC | awilkins: the import on Launchpad is unfortunately useless because you can't use bzr-svn with it to push changes back to the origin project. | 15:08 |
| lamont | I'm working on overcoming a year plus of dealing with bzr pain by ignoring bzr... | 15:08 |
| awilkins | AfC: Yes, that is a bummer ; maybe if there was a plugin that emitted SVN flavoured patches? | 15:09 |
| fullermd | Heh. "bzr made me cry, so I fixed it by using git for a while. Now I'm much happier with bzr" :> | 15:09 |
| awilkins | AfC: If you attached some properties to it you might even get it to round-trip | 15:09 |
| AfC | awilkins: the worst part is that there are already a lot of people using git-svn to do their work; with released bzr-svn taking ~ 1 week to pull GTK down it's really not viable for me to recommend it to people | 15:09 |
| lamont | fullermd: it's more "bzr made me cry. so I use git for development. and now my job requires me to use bzr for at least some stuff." | 15:09 |
| awilkins | AfC: Maybe it would be possible to adapt a svn-fast-export to emit a bzr-svn repo? | 15:10 |
| lamont | "so now I drip tears on the floor in #bzr and the bug tracking system" | 15:10 |
| AfC | And such comments have to be taken seriously. We cannot tell lamont here that his opinion is wrong. It's his opinion. | 15:10 |
| fullermd | Pfft. Don't be interruptin' my "random IRC commenting to avoid irritating code-shuffling work"'ing with the facts! | 15:10 |
| lamont | AfC: sure you can | 15:11 |
| AfC | awilkins: that would be awesome if it would work. | 15:11 |
| AfC | fullermd: :) :) | 15:11 |
| AfC | fullermd: I agree. Facts are overrated. | 15:11 |
| lamont | fullermd: I think you mean "Stop introducing facts into the argument" :-) | 15:11 |
| awilkins | AfC: I don't know of any reason why it shouldn't ... but I'm not the expert on bzr-svn. | 15:11 |
| lamont | or has that argument morphed since Oxford, I wonder... | 15:11 |
| AfC | awilkins: it's probably worth a try | 15:12 |
| * AfC admits that he doesn't quite understand the difference between the previous generation of import tools and *fast* | 15:12 | |
| fullermd | YKYAANW: you read that, and your first thought is "Huh? 'o' and 'r' aren't valid hex digits..." | 15:12 |
| awilkins | AfC: fast-import takes a sort of lingua-franca of version control from a stream ; the fast-export streams it out | 15:12 |
| james_w | I think git-fast-import is fast because you can do it all in one lump, rather than the usual load of forking. | 15:13 |
| * awilkins has a shufty at the features that bzr-fast-import tacked onto git-fast-import | 15:13 | |
| AfC | I would imagine that unless jelmer et al deliberately made bzr-svn compatible with the revisions created by bzr-fast-whaver, then it won't work | 15:14 |
| AfC | by accident. | 15:14 |
| james_w | there were then fast-export tools written to export the format, and bzr-fast-import written to allow bzr to use the stream format. | 15:14 |
| AfC | I could be wrong | 15:14 |
| awilkins | I don't know which bot dtermines the revids | 15:14 |
| james_w | I don't know enough about bzr-svn to say, but I think you may need more metadata in the stream to do it right. | 15:14 |
| james_w | but the question is would that be any faster than bzr-svn? | 15:15 |
| awilkins | If the export end determines revid you could "season" an existing svn-fast-export to emit it | 15:15 |
| AfC | james_w: if you can't use bzr-svn to return changes back to upstream, then bzr-fast-import won't work. | 15:15 |
| AfC | (in the case of the requirement I am articulating) | 15:15 |
| AfC | (as I noted yesterday, I probably could have picked an easier case than 19,000 revisions of GTK, but hey, I'm at a GTK hackfest :)) | 15:16 |
| awilkins | I agree with his use case in a more general sense ; round-tripping with SVN is something that will be a major driver for adoption of any new VCS | 15:16 |
| james_w | AfC: I agree, but I'm saying that I'm not sure if there is a reason that fast-import should be any faster than bzr-svn. | 15:17 |
| awilkins | Since server infrastructure is often under the control of people who don't care or understand | 15:17 |
| AfC | awilkins: well, if we can't get it right in the next 2 weeks or so we will lose GNOME | 15:17 |
| awilkins | james_w: I can think of at least one reason | 15:17 |
| awilkins | james_w: One thing bzr-svn is use one write-group for each revision | 15:17 |
| AfC | Anyone know if jelmer did his next bzr-svn release yet? I know that spiv and jelmer did some great improvements in London | 15:17 |
| lamont | the initial import from svn into $VCS doesn't need to be particularly fast, if I can do something in $VCS to fetch anything new, and can push my commits back to the svn server as svn commits | 15:17 |
| awilkins | It means the repo is repacked after every revision ; it's good in the "live use" case beacuse it means you can resume a broken pull | 15:18 |
| james_w | AfC: I haven't seen it, I checked bazaar-announce earlier today. | 15:18 |
| awilkins | But it really slows it down for the "big pull" | 15:18 |
| awilkins | There are two ways it could improve markedly ; one, shallow history, two, much faster initial import | 15:18 |
| AfC | james_w: (I think it turns out that if shallow branches had existed a while back, and if bzr-svn was able to use them, then we'd be sorted; to use bzr to work with [in this case svn based] GTK I only need the ability to get most recent revision or so) | 15:19 |
| awilkins | I agree, I seldom care about much beyond the last few tens of revisions (if that) | 15:19 |
| awilkins | AfC: There's a 0.4.8 release on the stove for 1.2 | 15:20 |
| AfC | stove? | 15:20 |
| awilkins | Just a mannerism | 15:20 |
| AfC | I know what it means. I just don't know whether you mean that it is released or not\ | 15:21 |
| awilkins | Well, it's not linked but you can pull from the branch | 15:21 |
| awilkins | Tell a lie, the branch is on launchpad now | 15:22 |
| kiko | hey | 15:22 |
| awilkins | AFAIK spiv/jelmer didn't change the one-write-group-per-revision thing though | 15:22 |
| kiko | how do I back out a merged revision? | 15:22 |
| AfC | Everytime I ask around here if it is safe to use bzr-svn from VCS the answer I get is "no"; admittedly if he is in the mode of doing a release instantaneously then it cannot be but safe. | 15:22 |
| kiko | do I just generate the reverse diff | 15:22 |
| kiko | or is there something saner? | 15:22 |
| awilkins | kiko: You can do an uncommit | 15:22 |
| awilkins | bzr uncommit | 15:22 |
| AfC | `bzr uncommit` | 15:22 |
| AfC | *unless* | 15:22 |
| awilkins | You'll be left with the merge diffs in your tree | 15:23 |
| AfC | the revision has propagated, | 15:23 |
| AfC | in which case yes, you will have to commit a reverse | 15:23 |
| kiko | awilkins, AfC: other stuff has landed after that, though :-( | 15:23 |
| kiko | I only want to back out that merge. | 15:23 |
| luks | bzr merge -r X..X-1 | 15:23 |
| AfC | kiko: little choice then. Just create a reverse diff. | 15:23 |
| AfC | kiko: what luks said :) | 15:24 |
| kiko | ok, cool. | 15:24 |
| AfC | kiko: use `bzr diff -r n..n-1` will help you make sure you have what you want | 15:24 |
| awilkins | AfC: AFAIK the 0.4.8 branch is stable | 15:24 |
| awilkins | AfC: It's been tagged, it's a release | 15:26 |
| AfC | awilkins: fair enough. | 15:27 |
| AfC | awilkins: thanks for the heads up. Will attempt to pull. | 15:27 |
| AfC | ^$#!#@ damn it. | 15:28 |
| AfC | $ bzr branch http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk bzr-svn | 15:28 |
| AfC | bzr: ERROR: Repository KnitPackRepository('file:///home/andrew/vcs/launchpad/.bzr/repository/') is not compatible with repository KnitRepository('http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/trunk/.bzr/repository/') | 15:28 |
| AfC | Why is Jelmer's repo not packs? | 15:28 |
| AfC | and more to the point, why doesn't this just work? | 15:28 |
| awilkins | < AfC> Why is Jelmer's repo not packs? | 15:28 |
| jelmer | hey folks | 15:29 |
| * awilkins waves | 15:29 | |
| AfC | jelmer: strange thing, | 15:29 |
| jelmer | awilkins: One sec, I'll upgrade it | 15:29 |
| AfC | I tried to grab your bzr-svn branch, and | 15:29 |
| AfC | bzr: ERROR: Repository KnitPackRepository('file:///home/andrew/vcs/launchpad/.bzr/repository/') is not compatible with repository KnitRepository('http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/trunk/.bzr/repository/') | 15:29 |
| AfC | Mostly, I'm surprised that this was an error at all. I thought we capable of interoperating and all | 15:29 |
| jelmer | AfC: Right, my bzr-svn branch uses a subtree format | 15:29 |
| abentley | AfC, diffs are not the only solution. A reverse merge will do the trick. | 15:29 |
| AfC | abentley: right | 15:30 |
| awilkins | We were also discussing the possibility of svn-fast-export | bzr-fast-import , whether it would/could be compatible with bzr-svn and whether it would be faster than bzr branch svn+http:// | 15:30 |
| AfC | abentley: that's what luks said | 15:30 |
| AfC | abentley: a very nice feature on Bazaar's part. | 15:30 |
| jelmer | awilkins: That's a lot harder than it sounds. fast-export doesn't provide the right information | 15:30 |
| abentley | You're welcome :-) | 15:30 |
| jelmer | I discussed this a little bit with igc at the sprint | 15:30 |
| awilkins | jelmer: But presumably you could take an existing svn-fast-export implementaion and hack it, or decorate it? | 15:31 |
| awilkins | Or is fast-import protocol not rich enough? | 15:31 |
| jelmer | awilkins: Yes, but there's no reason why that would be any faster than bzr-svn itself could potentially be | 15:31 |
| jelmer | awilkins: The fast-import protocol is not rich enough | 15:31 |
| AfC | jelmer: Three days later I'm still only 45% through branching GTK with bzr-svn. I'm very much looking forward to trying 0.4.8 | 15:32 |
| awilkins | AfC wants GNOME and GTK to have an epiphany about bzr | 15:32 |
| === kostja is now known as kostja_osipov | ||
| AfC | jelmer: I remarked earlier that I think that if shallow branches had existed a while back, and if bzr-svn was able to use them, then we'd be sorted. But that's not the case, so {shrug} we deal with what we have. | 15:32 |
| AfC | awilkins: well, it's worse than that. If we do not actively convert some key people Real Soon Now, we will lose out to Git. | 15:33 |
| kostja_osipov | statik: I sent a note on the bug report | 15:33 |
| luks | AfC: is that a bad thing is they prefer to use git? | 15:33 |
| AfC | Too many people are already using git-svn to talk to svn.gnome.org. There won't be a central decision, but it's happening on inertia. | 15:33 |
| luks | *if | 15:34 |
| statik | hi kostja_osipov! great, thank you | 15:34 |
| * awilkins just wants a VCS that tracks merges and has a good Eclipse plugin and works well on Windows | 15:34 | |
| luks | svn 1.5!!! | 15:35 |
| * luks hides | 15:35 | |
| AfC | luks: {shrug} if you believe that Bazaar is a better tool, then yes. I certainly don't want to use Git ever again for anything, so the fact that most of the people around me today are talking about Git (and making me cringe for how crazy it is) | 15:35 |
| luks | dunno, I personally couldn't care less what people use if it fits their needs | 15:35 |
| kostja_osipov | statik: do you meet physically? would be nice to come over to a) get some training b) point out the missing features c) have no ambiguity as to whether there is or there is no speed problem | 15:35 |
| awilkins | luks: I forgot to say "also tracks renames properly" | 15:36 |
| luks | oh, then svn 1.5 is out :) | 15:36 |
| awilkins | Besides, the Eclipse support will be AGES | 15:36 |
| statik | kostja_osipov: in moscow? probably not, but I'm sure we can work something out in realtime. maybe even video conference | 15:37 |
| awilkins | ATM I have rudimentary Eclipse and Java support through the client library in bzr-svn | 15:37 |
| kostja_osipov | not in moscow, :) | 15:37 |
| awilkins | ATM I have rudimentary Eclipse and Java support through the client library in bzr-eclipse | 15:37 |
| abentley | luks: It is nice when people can work together instead of each doing their own thing. | 15:37 |
| AfC | It was a pleasure to work Verterok last week on the bzr-eclipse plugin. It's coming along really nicely. | 15:38 |
| jelmer | AfC: Sorry, PCI hardware bug hang my laptop again | 15:38 |
| abentley | And it can hurt cooperation if people are using different tools that don't work well together. | 15:38 |
| luks | abentley: people will always use different tools, though. no matter how hard you try | 15:38 |
| lamont | git prior to 1.5 had an abysmal UI. git 1.5 is at least usable. | 15:38 |
| AfC | jelmer: that's ok. The network here is shit (and overloaded) too | 15:38 |
| luks | and git is definitely not going away anytime soon | 15:38 |
| jelmer | AfC, awilkins: Basically, the main thing that is making bzr-svn slow at the moment is the fact that it has to generate consistent deterministic revision and file ids | 15:38 |
| awilkins | jelmer: What's the algorithm for that? | 15:39 |
| AfC | jelmer: understood | 15:39 |
| lamont | luks: and given that, making tools interoperate is a good goal. | 15:39 |
| luks | sure | 15:39 |
| jelmer | awilkins: It's described by the mapping.txt file in bzr-svn | 15:39 |
| AfC | jelmer: [please don't forget to fix your repo if you get a chance... I would like to pull your code if I can] | 15:39 |
| awilkins | jelmer: Is it one of those things that might benefit from a pure C module? | 15:40 |
| awilkins | Not that my C is any good :-) | 15:40 |
| jelmer | awilkins: I think we can gain a lot simply by improving the logic behind the current Python code | 15:40 |
| awilkins | Is it all in mapping.py? | 15:40 |
| jelmer | awilkins: I've started factoring out the mapping code so this is easier to do | 15:41 |
| jelmer | awilkins: Yes, mostly | 15:41 |
| jelmer | I'm looking into using pyrex for the python bindings for subversion btw | 15:41 |
| jelmer | it's much easier than I thought, and I regret not having looked into this earlier | 15:42 |
| awilkins | Would that fix memory leaks much? | 15:42 |
| awilkins | Would it avoid SWIG :-) | 15:42 |
| jelmer | yes, both :-) | 15:42 |
| * awilkins applauds | 15:42 | |
| fullermd | AfC: It can't be 'fixed' so you can pull it into that repo... you'd have to put it standalone somewhere. | 15:43 |
| awilkins | AfC: Pull it somewhere outside of your big repo, then move the folder into the plugins folder | 15:43 |
| awilkins | (an ignore-repo switch for bzr branch would be useful here) | 15:44 |
| fullermd | You could probably do that via init'ing it with the -subtree format; I think that'll create a standalone in that place, since the repo isn't compatible. | 15:45 |
| AfC | awilkins: yeah. It seems pretty whacked the way it is now. | 15:45 |
| fullermd | (then pull'ing) | 15:45 |
| AfC | fullermd: interesting | 15:45 |
| fullermd | (I haven't tried, of course, but It Stands To Reason(tm)) | 15:46 |
| AfC | yup | 15:46 |
| james_w | that should work, yep | 15:46 |
| awilkins | It seems to still keep it's revisions in the parent repo though | 15:48 |
| jelmer | AfC: I've upgraded it to pack-0.92-subtree | 15:48 |
| AfC | Um... there's no 0.4.8 tag in that branch. | 15:48 |
| AfC | awilkins: where did you see such a tag? | 15:48 |
| AfC | jelmer: sweet | 15:49 |
| awilkins | AfC: In the 0.4.8 branch | 15:49 |
| awilkins | http://people.samba.org/bzr/jelmer/bzr-svn/0.4.8/ | 15:50 |
| awilkins | (also on launchpad) | 15:50 |
| awilkins | ls | 15:51 |
| AfC | Ok. Unusual that trunk wouldn't contain that, but whatever. | 15:51 |
| awilkins | 0.4.8 contains at least one cherrypick there... | 15:51 |
| jelmer | AfC: 0.4.8 isn't released yet and is being stabilized | 15:51 |
| * awilkins presumed the tag meant stable, sorry | 15:51 | |
| AfC | jelmer: ah. Others were saying otherwise. Thanks. | 15:51 |
| awilkins | It still works well for me :-) | 15:52 |
| awilkins | That reminds me, must have another try at converting my Big Fat Repo | 15:52 |
| awilkins | It wouldn't be faster over file:// would it? It seems to be CPU limited whenever I try it | 15:53 |
| jelmer | hmm, the pyrex stuff actually appears to be faster than the swig bindings, too | 15:56 |
| dato | jelmer: these pyrex bindings would substitute the existing ones upstream? | 15:57 |
| jelmer | dato: no, they'd be included with bzr-svn | 15:57 |
| dato | ok | 15:57 |
| awilkins | Are they API compatible with the existing ones? | 15:57 |
| luks | not that surprising, swig generates quite awful bindings | 15:57 |
| jelmer | dato: subversion generates bindings for a large range of languages and they have to maintain API compatibility | 15:58 |
| Stavros | hell | 16:00 |
| Stavros | hello, rather | 16:00 |
| Stavros | can i merge multiple commits into one? | 16:00 |
| awilkins | Are they at the tip of the branch? | 16:01 |
| Stavros | it's a theoretical question at this stage, so let's assume both ways :P | 16:01 |
| awilkins | If they are, you can uncommit them and then recommit the changes as a single revision | 16:02 |
| Stavros | oh | 16:02 |
| Stavros | isn't there a command to do that? | 16:02 |
| Stavros | i'm guessing no | 16:02 |
| awilkins | bzr uncommit | 16:02 |
| Stavros | no, i mean merge them | 16:02 |
| Stavros | anywhere in the history | 16:02 |
| awilkins | No idea | 16:02 |
| luks | bzr usually doesn't commands for automatic destroying of history :) | 16:03 |
| Stavros | hmm, i thought there was one | 16:03 |
| Stavros | maybe it's in git? | 16:03 |
| luks | very likely | 16:03 |
| === bigdo2 is now known as bigdog | ||
| Stavros | hmm | 16:03 |
| fullermd | You can make a new rev containing those two revs in various ways. But you'll have to recreate every rev after that point too, so you generally don't want to do that. | 16:03 |
| awilkins | Is this "rebase" or some other abomination? | 16:03 |
| Stavros | awilkins: no idea, i have never used git | 16:03 |
| fullermd | I think it's a 'feature' of git's rebase. | 16:03 |
| awilkins | Ah | 16:03 |
| dato | yes; of git rebase --interactive, in particular. | 16:04 |
| awilkins | You could { bzr branch tree newtree -r n-1 ; cd newtree ; bzr merge tree -r n-1..n+1 ; bzr commit ; bzr merge tree -r n+3 } ? | 16:05 |
| Stavros | awilkins: true, but it's not worth it, i was just wondering if there was a command | 16:05 |
| luks | Stavros: what's the use case for this? | 16:05 |
| luks | I mean, in git people use it because they use almost-plain patches to send changes around | 16:06 |
| Stavros | luks: committing not-quite-finished code so you can sync/run-test it, and then convert them all into one when done | 16:06 |
| fullermd | I've occasionally speculated about a full "history rewriting language", where you can define a spec of how you want to mutate history, and hand that off to an interpreter that goes off and does it. | 16:06 |
| fullermd | Interesting way to mentally occupy a couple hours. | 16:06 |
| luks | Stavros: why not just normal merge? | 16:07 |
| awilkins | Stavros: Do that sort of thing on a feature branch, and merge it when tested | 16:07 |
| jelmer | fullermd: that's actually what git rebase -i does | 16:07 |
| jelmer | to some degree | 16:07 |
| Stavros | the "unclean" commits remain unclean, though | 16:07 |
| fullermd | Well, only if you wrap expect around it or something :p | 16:07 |
| awilkins | Stavros: That way it becomes a single "merge" revision in the target branch (listing the full history from the merged branch) | 16:07 |
| luks | Stavros: they are part of the history | 16:07 |
| luks | maybe one year later you will wonder what it's done that way and those unclean commits will help you | 16:07 |
| awilkins | Stavros: You'll have no unclean commit on the main line, just in the subhistory of the top revision | 16:08 |
| luks | *why | 16:08 |
| Stavros | aha | 16:08 |
| fullermd | I don't think it can do all the mutations you'd want, either. | 16:08 |
| Stavros | so it'll be one revision number? | 16:08 |
| luks | one mainline revision, yes | 16:08 |
| awilkins | Stavros: Yes, it's one revision number, with a list of branch revisions inside it's history | 16:08 |
| Stavros | good, that should do then | 16:08 |
| fullermd | Frex, the nuclear * problems. | 16:08 |
| Stavros | it's just that my OCD flares up when I check in nonworking code | 16:09 |
| awilkins | You must write a lot of unit tests :-) | 16:09 |
| Stavros | i try :( | 16:09 |
| === kostja_osipov is now known as kostja|brb | ||
| === kostja|brb is now known as kostja | ||
| === kostja is now known as kostja_osipov | ||
| jelmer | man, I really should've looked at pyrex earlier | 16:30 |
| jelmer | almost done wrapping the core ra functions in just 2.5 hours | 16:30 |
| Stavros | what's ra? | 16:31 |
| jelmer | Stavros: Subversion Remote Access API | 16:31 |
| Stavros | ah | 16:32 |
| Stavros | can bzr push to subversion yet? | 16:32 |
| jelmer | Stavros: Has been able to do so for more than a year | 16:33 |
| Stavros | oh | 16:36 |
| Stavros | why have i been using svn then? :( | 16:36 |
| Stavros | are there any caveats? | 16:36 |
| schierbeck | hi jelmer | 16:36 |
| * awilkins is up for building/testing the pyrex bindings on win32 | 16:38 | |
| jelmer | Stavros: Speed is the main thing at the moment | 16:39 |
| jelmer | schierbeck: hey | 16:39 |
| Stavros | ah, i don't mind | 16:39 |
| jelmer | awilkins: cool | 16:39 |
| Stavros | i have to do svn copy from time to time to copy revisions to the release folder, can i do that with bzr-svn? | 16:39 |
| schierbeck | jelmer: i'm looking at fixing bug #93652 regarding lock handling ui | 16:40 |
| ubotu | Launchpad bug 93652 in bzr-gtk "Lock handling" [Low,Confirmed] https://launchpad.net/bugs/93652 | 16:40 |
| schierbeck | you're talking about complaining if there's a write lock on the branch being viewed by the viz? | 16:41 |
| awilkins | Stavros: I think you can push new branches into svn with bzr-svn (jelmer?) | 16:41 |
| awilkins | Not tried that feature yet :-) | 16:41 |
| jelmer | schierbeck: one sec | 16:42 |
| jelmer | Stavros: yep | 16:42 |
| Stavros | hmm | 16:42 |
| Stavros | jelmer: how do i do it exactly, do you know? | 16:42 |
| jelmer | Stavros: bzr svn-push | 16:42 |
| Stavros | ah, thanks | 16:43 |
| jelmer | schierbeck: Yep, that's about write locks | 16:43 |
| jelmer | schierbeck: I think currently it writes an error message about the lock to the terminal | 16:43 |
| schierbeck | jelmer: is there a way i can safely put a branch in a write-locked state? | 16:44 |
| schierbeck | (for a longer duration) | 16:44 |
| jelmer | schierbeck: Branch.open("foo").lock_write(); sleep(2000) | 16:45 |
| schierbeck | okay | 16:45 |
| Stavros | hmm, i installed the bzr-svn windows installer but it can't find either the svn plugin or the svn bindings | 16:46 |
| awilkins | Stavros: What I do it install the plugin by branching it inside my %appdata%/bazaar/2.0/plugins folder and the binding by unpacking libsvn and svn folders into c:/python25/lib/site-packages | 16:49 |
| Stavros | oh, that should work, thanks | 16:50 |
| Stavros | don't i need patched bindings though? | 16:50 |
| awilkins | Yes, get them from http://d5190871.u44.websitesource.net/bzr/ | 16:50 |
| schierbeck | jelmer: hmm, it doesn't seem that Branch.is_locked() and Repository.is_locked() do what i had thought | 16:50 |
| jelmer | schierbeck: You may want to have a look at the implementation of the break-lock command in bzr core | 16:51 |
| Stavros | awilkins: ah, that worked, thanks | 16:52 |
| Stavros | getting "bzr: ERROR: Permission denied: ".": Can't get password" now | 16:52 |
| Stavros | do i need bzr co or bzr branch? | 16:52 |
| schierbeck | jelmer: yeah, probably | 16:53 |
| jelmer | Stavros: non-ssh authentication doesn't work on Windows unless you have Subversion 1.5 | 16:54 |
| schierbeck | jelmer: for an initial implementation, with just a decent error message, couldn't i just catch LockNotHeld? | 16:54 |
| jelmer | schierbeck: Not sure I understand what you mean - the bug is about hooking into the bzrlib code that errors about existing write locks | 16:58 |
| awilkins | Stavros: Do something that needs auth (like grab a lock) using the svn client and cache your password | 16:59 |
| schierbeck | yeah, but i'm trying to get an incremental understanding of this: a LockNotHeld exception is raised when trying to unlock a branch with a write lock on it | 16:59 |
| awilkins | Stavros: And you want to bzr branch svn+http:// | 16:59 |
| Stavros | awilkins: it's svn:// | 17:00 |
| schierbeck | the sequence in which the viz operates is unlock lock_write unlock lock_read | 17:00 |
| awilkins | Stavros: That should be fine | 17:00 |
| schierbeck | i would expect an exception to be thrown when read-locking a write-locked branch, but nothing happens | 17:00 |
| jelmer | schierbeck: Yes, and that shouldn't change. We should hook into the code in bzrlib that currently prints to the terminal | 17:01 |
| awilkins | Stavros: You might want to init a rich-root-pack branch and pull into it, it's more recoverable if there is a problem (like memory issue which crop up on large repos) | 17:01 |
| Stavros | aha, let me do that | 17:01 |
| schierbeck | jelmer: hmm, okay | 17:02 |
| Stavros | done, but there's still the auth issue to counter | 17:02 |
| schierbeck | ideally, i could just check if there is a write-lock on the branch, and err out | 17:02 |
| james_w | AfC: ask and you shall receive :) -> http://planet.bazaar-vcs.org/ | 17:02 |
| awilkins | Stavros: Do an svn lock svn://project/trunk/randomfile and svn will cache your password | 17:03 |
| Stavros | awilkins: i did a commit to the server using tortoisesvn, do i need to do it in the folder i want to pull in? | 17:03 |
| Stavros | oh, let me try with the client | 17:03 |
| schierbeck | ahh, Branch.peek_lock_mode() | 17:04 |
| awilkins | Unlock the file afterwards :-) | 17:04 |
| Stavros | it was already cached, apparently | 17:04 |
| Stavros | still nothing, though :/ | 17:04 |
| awilkins | Hmmph, I had some issues with this. | 17:04 |
| AfC | james_w: oh, good show. Well done. | 17:05 |
| Stavros | james_w: what was that in response to/ | 17:07 |
| james_w | Stavros: Myself and jam were having a discussion at the sprint, and AfC suggested that one of us write up the discussion to show the thought that goes in to the design decisions, and where some tradeoffs are made. | 17:08 |
| === kiko is now known as kiko-fud | ||
| james_w | Stavros: and also partly due to the last two links. | 17:09 |
| Stavros | ah, thanks | 17:10 |
| james_w | Anyone know if there is a good general algorithm to take a set of actions and their weight and pick the set of actions with the highest weight? | 17:11 |
| james_w | where you can't just take them all I mean. | 17:11 |
| james_w | or maybe not a general algorithm, but a set of principles or something? | 17:11 |
| Stavros | awilkins: i have the bzr-server conversation if you want | 17:12 |
| schierbeck | for the love of god, a little documentation in bzrlib would make my life a whole lot easier... Branch.get_physical_lock_status() | 17:13 |
| james_w | or at least what the class of problem is called so that I can google for myself. | 17:14 |
| Stavros | does anyone have an idea why i can't pull with svn-bzr? maybe i need the svn client in the PATH? | 17:16 |
| james_w | Stavros: you shouldn't. What's the error message you get? | 17:16 |
| Stavros | bzr: ERROR: Permission denied: ".": Can't get password | 17:17 |
| Stavros | i sniffed the packets, if anyone speaks svn | 17:17 |
| jelmer | Stavros: non-ssh authentication doesn't work on Windows unless you have Subversion 1.5 | 17:19 |
| james_w | Stavros: http://bazaar-vcs.org/BzrForeignBranches/Subversion/FAQ | 17:19 |
| Stavros | o | 17:19 |
| Stavros | i thought you meant for http | 17:19 |
| james_w | Stavros: the second question might apply. | 17:19 |
| Stavros | james_w: it probably does, let me get 1.5 | 17:20 |
| Stavros | any idea where the 1.5 binaries are? :/ | 17:22 |
| nir | How can I have a generated file that is not under version control, but bzr export will export it? | 17:23 |
| nir | e.g version info file, used in a makefile to compile build number into a product | 17:23 |
| james_w | Stavros: 1.5 isn't released yet :) | 17:23 |
| Stavros | not even prerelease binaries? | 17:24 |
| Stavros | you built me up just to tear me down, didn't you! | 17:24 |
| james_w | Stavros: they might be available, I'm not sure. | 17:24 |
| james_w | nir: I don't think that is possible. | 17:24 |
| Stavros | james_w: can't find anything on the site, so i don't think so | 17:24 |
| schierbeck | jelmer: okay, i've done some initial ui | 17:25 |
| schierbeck | i'll work more on it later, got an appointment now | 17:26 |
| schierbeck | adios! | 17:26 |
| awilkins | Hey, someone with wiki admin rights unlock editing FortuneCookies, I want to put "bzr push does not update the remote tree!!!!!!" in it. | 17:27 |
| nir | Looks like I need to edit the exported tar.gz | 17:27 |
| awilkins | Stavros: You can find builds of 1.5, but I'm not sure about the 1.5 python bindings | 17:27 |
| jelmer | Stavros: I doubt there are any available for Windows yet | 17:28 |
| awilkins | http://merge-tracking.open.collab.net/servlets/ProjectProcess?tab=4 | 17:30 |
| awilkins | There are windows binaries there, but not the Python bindings (which need building AFAIK) | 17:30 |
| Stavros | it's ok, i'll wait then :/ | 17:31 |
| awilkins | At the speed Jelmer is going, we could have spanky new pyrex bindings by the end of the day.... | 17:32 |
| james_w | nir: you can export to a directory. | 17:33 |
| ubotu | New bug: #93652 in bzr-gtk "Lock handling" [Low,In progress] https://launchpad.net/bugs/93652 | 17:36 |
| statik | awilkins: you want the push_and_update plugin | 17:40 |
| statik | it's very nice | 17:40 |
| awilkins | statik: No, I don't have a need for it, but it has to be the most FAQ in here | 17:41 |
| awilkins | Perhaps having it as a page cookie would increase awareness as a kind of background noise :-) | 17:41 |
| luks | I don't think even having it on the homepage would :) | 17:42 |
| fullermd | I wouldn't think it would. I mean, bzr _tells_ you every time you push... | 17:43 |
| awilkins | Maybe it should print it in flashing red. | 17:44 |
| fullermd | Pop up a little speech balloon, with a trumpet flourish sound effect. | 17:44 |
| awilkins | Add a switch --i-understand to bzr push that has to be used to make it work..... | 17:47 |
| fullermd | "I, fullermd, by running this command, do assert and warrant that I am of sound mind and body, and have been apprised of and reviewed the document BZR-E-238634.7, entitled 'Push does not update remote working trees', and further affirm [...]" | 17:49 |
| awilkins | Make the user sign the "allowed-to-use-push" file with a GPG key that corresponds to their current whoami. | 17:51 |
| === mwhudson_ is now known as mwhudson | ||
| === kiko-fud is now known as kiko | ||
| jelmer | any pyrex experts awake? | 17:58 |
| jelmer | hmm, I guess that means no :-) | 18:10 |
| === pmezard_ is now known as pmezard | ||
| fullermd | I think jam does, but he's doesn't seem to even be nominally here today... | 18:13 |
| === Demitar_ is now known as Demitar | ||
| === mrevell is now known as mrevell-dinner | ||
| === mw is now known as mw|lunch | ||
| === mw|lunch is now known as mw | ||
| ubotu | New bug: #201934 in bzr-webserve "Inventory of files, get latest version" [Undecided,New] https://launchpad.net/bugs/201934 | 20:21 |
| === andrea-bs is now known as BeeBot | ||
| === BeeBot is now known as andrea-bs | ||
| ubotu | New bug: #201935 in bzr "Improve performance of bash completion (caching) (dup-of: 84822)" [Undecided,Invalid] https://launchpad.net/bugs/201935 | 20:31 |
| announcer | Rev 3272: (bialix) Significantly reducing execution time and network traffic bialix@ukr.net | 20:43 |
| statik | poolie: ^ there you go | 20:43 |
| mwhudson | hey, cool | 20:43 |
| statik | mwhudson: until it blows up | 20:44 |
| mwhudson | statik: ever the optimist | 20:44 |
| mwhudson | the first line of that commit message is more exciting than the whole thing | 20:44 |
| announcer | Rev 3272: (bialix) Significantly reducing execution time and network traffic bialix@ukr.net | 20:44 |
| statik | ok, announcer, we know that one already | 20:45 |
| statik | that one was my fault | 20:45 |
| statik | it should be all set now. | 20:45 |
| orospakr | http://blog.orebokech.com/2008/03/emacs-in-bzr-initial-impressions.html | 21:36 |
| mwhudson | wow, revision-info could do with some common-case speeding up | 21:48 |
| mwhudson | b.get_revision_id_to_revno_map() ? | 21:48 |
| mwhudson | oh, and revision_history() | 21:50 |
| ubotu | New bug: #201956 in bzr-gtk "Document bzr-gtk keybindings" [Undecided,New] https://launchpad.net/bugs/201956 | 21:51 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 21:59 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:04 |
| === jelmer_ is now known as jelmer | ||
| === jelmer is now known as jelmer_ | ||
| === jelmer_ is now known as jelmer | ||
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:09 |
| mwhudson | announcer: shut it | 22:10 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:14 |
| jelmer | mwhudson: Do you have any idea who owns announcer ? | 22:15 |
| mwhudson | jelmer: statik | 22:16 |
| yacc | mwhudson: announcer has just a bad memory and has to repeat a number of times so he doesn't forget this gem of information ;) | 22:16 |
| * jelmer wonders what the benefits of announcer over cia are | 22:17 | |
| yacc | jelmer: well, it's not torturing you by mistake ;) | 22:18 |
| yacc | jelmer: I meant interogate firmly ;) | 22:19 |
| jelmer | heh | 22:19 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:19 |
| jelmer | hmm, is this going to continue every 5 minutes? | 22:20 |
| jelmer | s/continue/repeat/ | 22:20 |
| yacc | nor does it kidnap you and throw you in an unmarked plane to fly you to some idyllic tourismus hotspot | 22:20 |
| yacc | jelmer: well, most IRC clients have support for ignoring ;) | 22:21 |
| jelmer | statik: ping | 22:22 |
| jelmer | statik: That's mainly useful for stuff you'd like to ignore but can still be interesting for other people | 22:22 |
| jelmer | I don't think that's the case here | 22:23 |
| jelmer | anybody with pyrex karma around? | 22:23 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:24 |
| mwhudson | jelmer: i think pyrex is bad for the soul, but i know a bit about it | 22:25 |
| jelmer | mwhudson: If you think pyrex is bad for the soul, you should try swig ;-) | 22:25 |
| jelmer | mwhudson: I'm trying to create a class from some pyrex code but need to set two C members in it | 22:26 |
| mwhudson | jelmer: well yes, swig is worse | 22:26 |
| mwhudson | i don't see what the problem is with just writing c, to be honest | 22:27 |
| jelmer | and I can't figure out a way to do it. There's no way to create an __init__ that takes C pointers | 22:27 |
| jelmer | mwhudson: Too much work | 22:27 |
| mwhudson | oh, ok, that goes beyond my pyrex knowledge already | 22:27 |
| jelmer | mwhudson: ah, ok | 22:28 |
| * jelmer just redid most of the python subversion bindings in ~5 hours using pyrex | 22:28 | |
| jelmer | It's just this last bloody thing that's I can't seem to get right | 22:29 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:29 |
| * TFKyle stabs announcer | 22:30 | |
| mwhudson | where is igc | 22:30 |
| mwhudson | he's sending email but not on irc? | 22:30 |
| jelmer | yeah, same thing for John | 22:30 |
| james_w | I think they are at/on the way to PyCon | 22:34 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:34 |
| mwhudson | ooh | 22:35 |
| mwhudson | right | 22:35 |
| mwhudson | bzr revision-history in the emacs import takes ~8 seconds :/ | 22:35 |
| === asak_ is now known as asak | ||
| dato | mwhudson: but not with your patch :-P | 22:36 |
| dato | ah | 22:37 |
| mwhudson | dato: no, i only did revision-info | 22:37 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:39 |
| dato | statik: is announcer yours? | 22:41 |
| dato | statik: it's misbehaving | 22:41 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:44 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:49 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:54 |
| poolie | hello | 22:56 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 22:59 |
| mwhudson | hi poolie | 23:00 |
| jelmer | hey Martin | 23:00 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:04 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:09 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:14 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:19 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:24 |
| schierbeck | hi jelmer | 23:29 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:29 |
| jelmer | hey Daniel | 23:31 |
| schierbeck | jelmer: i'm playing a bit with launchpad edge, and i'm pretty impressed. do you think we at one point would be able to switch to using it to handle merge requests? | 23:32 |
| jelmer | schierbeck: Can it deal with merge requests by email yet? | 23:33 |
| schierbeck | i'm not sure, i'm playing around with a toy project to get a sense of the features | 23:34 |
| schierbeck | if not, i'll add it to the lp bug tracker | 23:34 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:34 |
| * arjenAU hears an echo | 23:35 | |
| mwhudson | can someone kick announcer please? | 23:35 |
| jelmer | poolie and lifeless are the only people with op rights | 23:35 |
| jelmer | poolie: ping | 23:36 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:39 |
| jelmer_ | crap, that's the 4th time today | 23:43 |
| jelmer_ | my PCI BUS is being crappy | 23:43 |
| === jelmer_ is now known as jelmer | ||
| awilkins | That's one sick computer | 23:43 |
| jelmer | yeah :-( | 23:44 |
| awilkins | I remember sitting with a diagram of motherboard interrupt lines trying to work out which slot to stick my Audigy in | 23:44 |
| awilkins | Creative cards really hate sharing interrupts | 23:44 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:44 |
| awilkins | Hmph, apparently, announcer does not respond to polite hints like "/msg announcer FUCK OFF" | 23:45 |
| awilkins | jelmer: What's your bindings problem.... I'm not familiar with pyrex but I do have experience writing horrible P/Invoke calls from VB6 :-) | 23:46 |
| jelmer | heh | 23:46 |
| awilkins | Cheers, lifeless | 23:47 |
| jelmer | lifeless: our hero | 23:47 |
| lifeless | np | 23:48 |
| lifeless | brb | 23:48 |
| jelmer | awilkins: see my description a bit earlier | 23:48 |
| jelmer | awilkins: I'm trying to pass C variables rather than python objects to a class constructor somehow | 23:48 |
| awilkins | Callback? | 23:49 |
| jelmer | no, not that | 23:49 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:49 |
| jelmer | argh | 23:49 |
| announcer | Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com | 23:50 |
| awilkins | Seems to be unstuck, at least | 23:50 |
| jelmer | I don't think so. That's the revision that was just merged by pqm | 23:50 |
| jelmer | it's probably just announcing the tip of bzr.dev constatntly | 23:50 |
| awilkins | It was stuck on 3273 before | 23:51 |
| awilkins | Seems to be 5 minute intervals | 23:51 |
| awilkins | jelmer: Would extension types solve your problem? | 23:52 |
| jelmer | awilkins: not sure what you mean? | 23:52 |
| awilkins | "wrap arbitrary C data structures and provide a Python-like interface to them" | 23:52 |
| jelmer | it's a very pyrex-specific problem | 23:52 |
| awilkins | What's the constructor you're trying to call? | 23:54 |
| jelmer | I can't create a constructor with c types as arguments | 23:54 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:54 |
| announcer | Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com | 23:54 |
| awilkins | jelmer: So have a constructor with extension types as arguments and define extension types to pass to it | 23:55 |
| awilkins | http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/extension_types.html ? | 23:55 |
| announcer | Rev 3273: (jam) Fix moving directories to root nodes. john@arbash | 23:59 |
| announcer | Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!