| poolie | lifeless: can tribunal already handle subunit? | 00:15 |
|---|---|---|
| * poolie just branches lp:tribunal | 00:19 | |
| lifeless | tribunal runs a python test suite | 00:19 |
| lifeless | if that uses a SubProcessTestSuite, its transparent to tribunal | 00:19 |
| lifeless | igc: how are those reviews going | 00:19 |
| igc | starting now | 00:20 |
| igc | (been reading the threads with abentley's and spiv's comments) | 00:20 |
| lifeless | the one I pointed you at is much simpler | 00:21 |
| lifeless | *ones* | 00:21 |
| ubotu | New bug: #208039 in bzrtools (main) "Feature Freeze Exception: bzr 1.3" [Undecided,New] https://launchpad.net/bugs/208039 | 00:51 |
| poolie | markh: that document is pretty interesting | 01:12 |
| markh | poolie: thanks! | 01:12 |
| * poolie avoids getting sucked into reading the whole Old new thing | 01:13 | |
| markh | heh - its a very intersting blog for windows developers | 01:14 |
| markh | I'm going to dig deeper into the tsvn cache etc | 01:15 |
| markh | and decided to get sidetracked by pulling their svn tree via bzr ;) | 01:15 |
| * beuno pokes poolie and lifeless about the debconf bzr talk deadline | 01:15 | |
| poolie | beuno: hi | 01:16 |
| poolie | thanks | 01:16 |
| beuno | hey poolie :) | 01:16 |
| poolie | so what did we work out about that? that lifeless would propose a talk and james_w might go too, iirc? | 01:16 |
| beuno | yeap, he was willing to go | 01:17 |
| === kiko is now known as kiko-zzz | ||
| beuno | and jelmer and LarstiQ are interested in going too, they where going to apply for sponsorship by debian | 01:18 |
| beuno | and with me and Verterok, we might be a pretty big bzr possy | 01:18 |
| beuno | might even be worth organizing a sprint :) | 01:19 |
| beuno | oh, and dato might come too, right dato? | 01:21 |
| jelmer | 'evening markh | 01:22 |
| jelmer | markh: great to see you taking on TortoiseBzr ! | 01:22 |
| markh | hi jelmer - thanks! | 01:22 |
| markh | key to its success will be these "external apps" which we call to do the grunt work. I haven't really looked at them yet | 01:23 |
| markh | I don't have pygtk locally | 01:23 |
| markh | but the cool thing is we can fix them later, and independently of the shell itself | 01:23 |
| jelmer | I think it would make sense to call out to qbzr from tortoisebzr rather than bzr-gtk | 01:23 |
| jelmer | qbzr is easier to install than bzr-gtk and looks more native on windows | 01:24 |
| markh | there is an existing impl for a couple of "commands" in the tbzr tree | 01:24 |
| markh | I *think* they are gtk, but I've really only noticed they exist, not what they do :) | 01:25 |
| jelmer | yeah, that's all gtk | 01:25 |
| markh | so I'm up for nuking them, or whatever everyone agrees | 01:25 |
| beuno | jelmer, hey :) I haven't had _any_ free time at all these past weeks, but I do have a few hours now. Is the bzr-gtk release missing anything other than the disable-through-nautilus bit? | 01:25 |
| jelmer | we initially created tortoisebzr as a fork of bzr-gtk | 01:25 |
| markh | but no1 focus should be the shell IMO | 01:25 |
| jelmer | beuno: yep, that's the only bit missing | 01:25 |
| jelmer | beuno: hi :-) | 01:26 |
| lifeless | right, I need a topic I think | 01:26 |
| jelmer | lifeless: "sock puppets" ? | 01:26 |
| markh | how about xul? ;) | 01:26 |
| * markh ducks | 01:26 | |
| beuno | jelmer, alright, I'm on it. I'll try and get that done tonight | 01:26 |
| jelmer | beuno: that'd be awesome | 01:26 |
| beuno | xul! that would be interesting! | 01:26 |
| poolie | beuno: if those people don't get sponsorship from debian talk to me | 01:27 |
| poolie | markh: i don't have any particular comments, but it looks like a good start | 01:28 |
| jelmer | markh: I think nuking them wouldn't be a problem - they're also in bzr-gtk anyway | 01:29 |
| abentley | lifeless: your deprecation of get_graph_with_ghosts appears to also affect get_graph | 01:29 |
| poolie | markh: i guess i would be inclined not to have a separate cache process other than the xmlrpc server, at least at first, just to reduce the number of moving parts | 01:29 |
| luislavena | jelmer: hello. | 01:29 |
| jelmer | luislavena: hi | 01:29 |
| poolie | also, maybe you could expand in a future post on what kind of debug/trace _is_ needed? | 01:29 |
| beuno | poolie, sure, I'll follow it closely. jelmer, LarstiQ, keep your agendas open got august ;) | 01:30 |
| luislavena | jelmer: is there a way I can branch/svn-cache 16K svn revisions without hit the memory error? | 01:30 |
| luislavena | :-D | 01:30 |
| jelmer | beuno: will do, thanks :-) | 01:30 |
| markh | poolie: it we move to pure C++ for the shell, I'm a little concerned the xmlrpc requirement will complicate what should be fairly simple | 01:30 |
| jelmer | luislavena: use a version of python-subversion with the memory leaks fixed | 01:30 |
| markh | and slower and less secure if implemented via sockets on windows :) | 01:30 |
| poolie | hm | 01:31 |
| poolie | what would be better? | 01:31 |
| lifeless | abentley: thats 'index.get_graph' which is on a private attribute of knits - knit._index.get_graph. | 01:31 |
| poolie | i guess you could make a dcom server in python? | 01:31 |
| luislavena | luislavena: mmm, that will need me to swtich to ubuntu and put that on a pendrive :-D | 01:31 |
| jelmer | luislavena: or you can use "bzr init dir"; bzr pull -r1000; bzr pull -r2000; bzr pull -r3000.. etc | 01:31 |
| poolie | would that be easier to talk to? | 01:31 |
| beuno | markh, you'd also be able to get XML straigh out of bzr, just like with the current xmloutput plugin | 01:31 |
| markh | the cache process is likely to need to create a hidden window to receive shell notifications from explorer when a user deletes files, for example, and maybe register for asynch NT filechange notifications to even handle the command-line changing the file-system | 01:31 |
| luislavena | jelmer: pull directly instead of branch? | 01:31 |
| jelmer | luislavena: yes, pull 1000 revisions each time | 01:32 |
| poolie | markh, i guess i don't understand what you mean by "the xmlrpc requirement will complicate what should be | 01:32 |
| poolie | fairly simple" | 01:32 |
| markh | poolie: dcom might work, yeah - but a few simple commands over a named pipe is really quite trivial | 01:32 |
| luislavena | jelmer: great, thank you for the pointer. | 01:32 |
| abentley | lifeless: acceptable breakage. | 01:32 |
| markh | xmlrpc imples a few C++ libraries I'm not familiar with | 01:33 |
| jelmer | DCE/RPC \o/ | 01:33 |
| markh | and we want this as thin as possible, as it gets dragged into many processes | 01:33 |
| poolie | markh: another option is to talk the bzr network protocol | 01:34 |
| poolie | the encoding for it would be pretty trivial to write in c++ | 01:34 |
| poolie | some of the commands you need may not exist | 01:34 |
| poolie | this will possibly be smaller or simpler than xmlrpc | 01:34 |
| poolie | probably more new code though | 01:35 |
| igc | lifeless: looks like abentley and I just reviewed that patch for you. One was approve and the other was resubmit (though my review was borderline tweak) | 01:35 |
| markh | Would all the gui apps be written to use this xmlrpc server? | 01:36 |
| beuno | markh, that's the plan, GUI and IDEs | 01:36 |
| abentley | lifeless: please to be running the test suite before submitting your patch. | 01:37 |
| bob2 | snap | 01:37 |
| markh | But isn't it more moving parts for a GUI app that has direct access to bzrlib? I do see the benfit for IDEs etc, but not so much for gui apps that are "part of" bzr | 01:37 |
| markh | but thats fine :) | 01:37 |
| markh | I don't need to be convinced ;) | 01:38 |
| poolie | i didn't think guis would but i might be out of date | 01:38 |
| beuno | markh, well, if you can access python directly, then it makes sense, yes | 01:38 |
| beuno | IIRC, there where some use cases for GUIs that couldn't interact with python | 01:38 |
| markh | so - that would make the shell code the only known consumer of this server on windows today. Its not written yet, it adds complexity and offers a much richer API than we actually need :) | 01:39 |
| markh | hence I'm still on the "simple" side of the fence :) | 01:40 |
| lifeless | abentley: igc: both of you reviewed the superseded, broken, version of it | 01:40 |
| lifeless | abentley: I do run the test suite usually :) | 01:41 |
| abentley | Should BB have noticed that it was superseded? | 01:41 |
| beuno | markh, after a whole sprint of "windows support is extremely important", and nobody willing to do anything about it, I guess you should go down whatever path you want, and we can just help :) | 01:41 |
| markh | I'm obviously happy to go with whatever is decided - but in the meantime I must take off to the shops for lunch. bb in an hour. thanks for the info about the server thinking! | 01:42 |
| markh | beuno: thx - its still obviously open for discussion! | 01:42 |
| abentley | I'm pretty sure BB didn't notice that it was superseded, because I voted using BB. | 01:43 |
| lifeless | oh hmm | 01:43 |
| === mw is now known as mw|out | ||
| igc | lifeless: sorry about that. I don't seem to have a more recent one in my email though and BB didn't list another with a similar name? | 01:43 |
| lifeless | hmm | 01:45 |
| lifeless | oh, *I* was confused | 01:45 |
| LaserJock | is there an advantage to having a shared repo on a bzr server other than saving space? | 01:54 |
| beuno | LaserJock, nope, and that just applies if the branches have common revisions | 01:56 |
| beuno | jelmer, we agreed on setting the nautilus disable flag in "~/.bazaar/bazaar.conf", right? | 01:57 |
| fullermd | Well, You save a lot of traffic... | 01:59 |
| abentley | LaserJock: Yes, it also saves time. | 02:00 |
| LaserJock | I guess my question is, is there a difference if the user creates a shared repo or if it's already a shared repo on the server? | 02:02 |
| LaserJock | not sure if I was clear the first time | 02:02 |
| lifeless | LaserJock: no different really; but lp doesn't support or use shared repos's. if thats what you were thinking :> | 02:03 |
| beuno | LaserJock, my attempts to use shared repos for _many_ unrelated branches led to some weird results | 02:03 |
| LaserJock | lifeless: yeah it was | 02:03 |
| LaserJock | lifeless: does LP support rich-root-pack ? | 02:04 |
| lifeless | yes | 02:04 |
| beuno | LaserJock, LP has the latest version of bzr, so whatever you push to it will work | 02:04 |
| LaserJock | so just getting some LP bzr admin type to convert our dirstate-with-subtree branches to rich-root-pack should speed things up and allow us to make shared repos, correct? | 02:05 |
| LaserJock | that's my bottom line I guess :-) | 02:06 |
| beuno | LaserJock, you shouldn't need an admin if you have access to the branch | 02:06 |
| beuno | you can just "upgrade --format=" | 02:06 |
| LaserJock | heh | 02:06 |
| LaserJock | but I can't really push it back up | 02:07 |
| LaserJock | if it takes pushing the whole branch | 02:07 |
| beuno | LaserJock, no, you can do bzr upgrade --format bzr+ssh://laserjock@baza.... | 02:07 |
| lifeless | well | 02:08 |
| RAOF | beuno: But upgrade doesn't work over bzr+ssh, right? | 02:08 |
| lifeless | you can't beuno | 02:08 |
| beuno | oh? sftp then? | 02:08 |
| RAOF | That works, or should. | 02:09 |
| beuno | LaserJock, right, sftp instead of bzr+ssh | 02:10 |
| LaserJock | so would the LP server then do the conversion? | 02:10 |
| beuno | yeap | 02:10 |
| * LaserJock struggles to wrap his brain around this stuff | 02:10 | |
| RAOF | Well, no. Your local bzr client does the conversion over sftp. | 02:11 |
| RAOF | So this can be _sloooooooow_. | 02:11 |
| LaserJock | so when I did it locally it took 40 min | 02:11 |
| beuno | of course, I'm not sure what wil happen when pushing/pulling from other local formats. You'd probably want to upgrade all current branches | 02:11 |
| LaserJock | when we first pushed this branch it took about 5 days | 02:11 |
| LaserJock | so roughly how long do you think it'd take? | 02:11 |
| beuno | LaserJock, I'd say run it and go to sleep :) | 02:12 |
| LaserJock | I'd have to do it for 4 branches | 02:13 |
| LaserJock | and I only have 2 locally | 02:13 |
| beuno | LaserJock, many times it's faster to re-branch | 02:14 |
| LaserJock | what do you mean by re-branch? | 02:14 |
| beuno | upgrade in LP, and re-branch to your box | 02:14 |
| LaserJock | ah | 02:14 |
| beuno | much cheaper in big repos | 02:14 |
| LaserJock | if we could get that done before Intrepid get's really going I think it'd be a big advantage for new contributors | 02:15 |
| lifeless | beuno: upgrade over sftp copies all the data twice | 02:16 |
| lifeless | beuno: over the wire | 02:16 |
| beuno | LaserJock, if it's that big of a deal, then it might be faster to get a LP admin to do it. Maybe abentley? | 02:16 |
| beuno | lifeless, ah, so it should be cheaper to upgrade locally and fully re-upload? | 02:17 |
| LaserJock | beuno: yeah, I just sent an email to the team to start a discussion about shared repos and getting the format upgraded | 02:17 |
| LaserJock | we'll see how it goes, but I'm sure everybody will like the improvement | 02:17 |
| LaserJock | how old of a bzr version will handle rich-root-pack? 1.0 ? | 02:18 |
| beuno | LaserJock, I think from 0.92 | 02:19 |
| beuno | or 0.91 even | 02:19 |
| beuno | so 1.0 should be a safe bet | 02:19 |
| LaserJock | k, just wondered about gutsy users | 02:19 |
| abentley | They were introduced in 1.0, according to NEWS. | 02:20 |
| beuno | abentley, wasn't it introduced with packs itself? | 02:20 |
| lifeless | no | 02:20 |
| * beuno is awfully wrong today | 02:21 | |
| * beuno alt+tabs into vim | 02:21 | |
| jdong | beuno: at least that's one thing right. | 02:26 |
| beuno | jdong, :p | 02:27 |
| LaserJock | jdong: I thought it was just typo ;-) | 02:27 |
| LaserJock | *just a | 02:28 |
| beuno | igc, btw, thanks for redirecting all the IDE people to be, I've got a pretty good list of people working on stuff. I'll put up a wiki page with it soon | 02:40 |
| igc | beuno: excellent. I almost did exactly that yesterday but didn't get to it | 02:41 |
| igc | I want a page called EditorsAndIDEs (say) that lists all of them together with software and/or contact points | 02:41 |
| beuno | exactly what I had in mind :) | 02:42 |
| igc | we can also use that to direct people to the team you've set up | 02:42 |
| beuno | igc, yeap, sounds great. Seems the news from the sprint got many people excited about it | 02:43 |
| lifeless | igc: there were two patches ... | 02:44 |
| igc | lifeless: didn't abentley approve the seocnd one? | 02:45 |
| === bigdo1 is now known as bigdog | ||
| lifeless | *blush* | 02:49 |
| lifeless | ok | 02:49 |
| * igc lunch & doctor visit | 02:59 | |
| lifeless | abentley: cool patch; I don't think I'll get to review it myself today | 03:41 |
| lifeless | abentley: but it sounds excellent (though I'm not 100% sure about validating against different formats automagically) | 03:42 |
| lifeless | abentley: spiv: duplication reduction ping | 03:42 |
| abentley | lifeless: Well, that's only on conversion. And it's only if the obvious choice fails. | 03:42 |
| lifeless | so, I've reduced about half of the duplicate sites to use helpers; the rest are not actually all the same | 03:43 |
| lifeless | the knit and versionedfile ones don't filter nulls and so on | 03:44 |
| abentley | Otherwise, I would have to fail to convert. | 03:44 |
| lifeless | well, my thoughts were that if its wrong, its wrong and failure is expected. | 03:45 |
| lifeless | I'll sleep on it | 03:45 |
| abentley | So that means that if we convert something from format 5 into 6, we can't convert it to 8 | 03:45 |
| abentley | And similarly for 7 -> 5 | 03:45 |
| abentley | sorry, 7->6 | 03:45 |
| lifeless | the way I looked at it, reading the old inventory will fail | 03:46 |
| lifeless | so this is a job for reconcile, which is allowed to be slower and more complex than just pull | 03:46 |
| spiv | lifeless: yeah, in the patch I saw I think there were two variants. | 03:46 |
| lifeless | spiv: do you want to see the new diff; I think its about as reduced as I'm comfortable with | 03:47 |
| lifeless | or an incremental diff? | 03:47 |
| lifeless | or <alternate> | 03:47 |
| abentley | lifeless: But then you're generating format 5 serializations with differing inventory_sha1s for the same revision. | 03:48 |
| spiv | lifeless: an incremental diff would do | 03:48 |
| lifeless | abentley: huh? whatever rich-root is today - yes. And it can happy today trivially. | 03:48 |
| lifeless | abentley: all you have to do to get different inventory sha 1s today is to do a bzr baz-import into a rich root repo, and also a bzr baz-import into a pack-0.92 which you then upgrade. | 03:49 |
| abentley | The 5, 6 and 7 serializers all use format 5 for their serialization. | 03:49 |
| abentley | of revisions. | 03:49 |
| lifeless | and ditto with bzr-hg/hg-import etc - all the deterministic importers will create this | 03:50 |
| lifeless | spiv: mailed you | 03:50 |
| spiv | lifeless: ta | 03:50 |
| abentley | lifeless: That's just them not being completely deterministic. | 03:51 |
| beuno | jelmer, sent the patch :) I suppose I have to add the stuff I ahve done up to now in NEWS, but I'll wait until it gets approved to send that in | 03:51 |
| lifeless | abentley: they would have to generate a format 5 inventory, grab its sha, and then reserialise to format 7 inventory | 03:51 |
| lifeless | abentley: I think they are being completely deterministic; its *our* bug on upgrade that makes any problems exist; which is what your patch is about fixing. | 03:52 |
| abentley | They're not deterministic. They don't force the root revision_id to always be updated, AFAIK | 03:52 |
| abentley | which is the non-rich-root behavior. | 03:52 |
| lifeless | abentley: mmm, possibly; | 03:53 |
| abentley | i.e. what you'd get if you converted something from baz into knit, then rich-root. | 03:53 |
| spiv | lifeless: +1 | 03:53 |
| lifeless | thanks | 03:56 |
| beuno | poolie, if you want some help with bzr packaging for ubuntu, just upload the current branches to LP and I'll pitch in to get 1.3 into PPA | 03:57 |
| lifeless | beuno: I need a topic suggestion; looms would be ideal but they aren't really polished yet :( | 03:57 |
| beuno | lifeless, how about generically going for "managing your packages with bzr"? | 03:58 |
| beuno | and then see how polished they are by august :) | 03:58 |
| markh | is there a simple way to have bzr show the traceback when it can't load a plugin? | 04:16 |
| spiv | markh: the traceback is written to the .bzr.log | 04:17 |
| markh | ah - thanks! | 04:17 |
| spiv | markh: it might be good if there were a -Dplugin debug flag, perhaps. | 04:17 |
| poolie | markh: i would think -Derror should do that but i guess it does not? | 04:28 |
| markh | heh - the log is in "my documents" :) | 04:31 |
| markh | so - .bzr.log is misplaced IMO on windows. What is the best place to discuss that? Open a launchpad bug or just email the list? The patch is trivial, but agreement on the correct place might not be ;) | 04:42 |
| lifeless | markh: see the archive first please | 04:43 |
| lifeless | markh: its not accidental where it is :> | 04:43 |
| markh | bugger - so it is to help the user find the log? | 04:45 |
| lifeless | it may be that there is a better place | 04:46 |
| lifeless | bzr --version shows where the log is going | 04:46 |
| lifeless | so please google a bit, and if you decide that it should be moved:- send a [MERGE] in :) | 04:47 |
| markh | well - making it easy to explain to a user where to find the log is very true and I don't want to start a bikeshed discussion - but I think its safe to say I'm very glad that no other apps take the approach of dumping their logs where I store my documents ;) | 04:48 |
| lifeless | markh: which is why I am acking that there may be a better place; but asking you to check the history a bit first, and rather than openning a bikeshed discussion, send in a patch that does the right thing | 04:49 |
| markh | fair enough - tho me even bringing it up is kinda bikeshedding :) | 04:52 |
| lifeless | I don't think its bikeshedding to say 'here is a way to do things better'. bikeshedding is arguing about trivialities. | 04:55 |
| spiv | "I want my shed to be pink, and called 'My Documents'" ;) | 04:55 |
| markh | I did assume the location was "accidental" - but given it was explicitly decided, the location of the log file is almost a triviality at this stage of the game - much bigger fish to fry! | 04:57 |
| markh | eg, how we bend py2exe to allow plugins to work OK in binary releases. For now I'll just switch to a source version of bzr instead though... | 04:58 |
| lifeless | tchau | 05:18 |
| poolie | bye lifeless | 05:18 |
| AfC | Is jam up? Guess not. | 06:28 |
| poolie | AfC: he's on holidays for the next week and a bit | 06:29 |
| AfC | poolie: ah! Nice. Thanks | 06:29 |
| poolie | i've forwarded your expenses | 06:33 |
| poolie | btw | 06:33 |
| AfC | poolie: thanks | 06:35 |
| AfC | ! | 06:35 |
| AfC | poolie: So it's probably a rear guard action at this point, | 06:35 |
| AfC | but I'm trying to [automate] set up [of] bzr-svn branches for GNOME projects for people to use. | 06:36 |
| AfC | I'm happy to publish a selection of the resultant branches on our R&D server, but | 06:36 |
| AfC | I was wondering if the launchpad guys are {likely, in progress} doing that themselves | 06:37 |
| poolie | i'd like them to move to doing it through bzr-svn rather than cscvs | 06:37 |
| AfC | (versus bzr-vcs-import, which is unfortunately no good for projects that are not migrating but still using Subversion as their main) | 06:37 |
| poolie | for a few reasons including the result being more useful, ... well you can imagine | 06:37 |
| poolie | but that is not on their plate at present | 06:38 |
| poolie | um | 06:38 |
| poolie | i have heard there is interest in having those imports though | 06:38 |
| AfC | poolie: ok. Just thought I'd ask before writing a bunch of scripts and kicking them off. | 06:38 |
| poolie | sure | 06:38 |
| poolie | can you mail the list when you do it? | 06:38 |
| poolie | i'd like to at least mirror them to launchpad | 06:38 |
| AfC | poolie: yeah, I sorta heard that murmour in the back of the room in London; I also now understand some of the things the Launchpad team are up against. | 06:38 |
| poolie | :) | 06:39 |
| AfC | poolie: yeah, for sure. | 06:39 |
| poolie | we had an interesting thread about downtime recently | 06:39 |
| poolie | it's actually above 99% but whether that's good or not depends on your point of view | 06:39 |
| poolie | anyhow i should finish rebuilds | 06:40 |
| AfC | Not bzr-svn's fault, but I had to do the 100 revisions at a time trick to try and do the 19,000 revision repo. I didn't have a server handy with the patched Subversion, and the machine I was on (ie, my laptop) was in an environment that was VERY intermittent. | 06:40 |
| AfC | It took 9 days to do the import. | 06:40 |
| AfC | Needless to say, I'm not going to tell anyone else that :) | 06:40 |
| poolie | well | 06:40 |
| poolie | this is one reason it would be good to get it running on proper infrastructure | 06:41 |
| AfC | poolie: [99%.... for most people, that's pretty good. The one I usually look for is planned vs unplanned] | 06:41 |
| spiv | AfC: jelmer says bzr-svn 0.4.9 is much faster, btw | 06:41 |
| AfC | spiv: I was just going to grab it... I know it has the changes that you and he made a couple weeks back | 06:41 |
| spiv | AfC: so if the dependencies aren't too horrible, it'd be worth trying the upgrade | 06:42 |
| AfC | spiv: should be ok... I just had to jump through lots of stupid hoops to get Subversion to co-operate. | 06:42 |
| AfC | Anyway, it's on my list of things to contribute in April. | 06:42 |
| === doko_ is now known as doko | ||
| igc | night all - have a good weekend | 07:59 |
| === cprov-out is now known as cprov | ||
| === weigon__ is now known as weigon | ||
| james_w | thanks jdong | 09:24 |
| poolie | hi james_w | 09:26 |
| james_w | hi poolie | 09:26 |
| james_w | how are you? | 09:26 |
| poolie | very good | 09:26 |
| poolie | i should sign off though... | 09:27 |
| james_w | have a good weekend | 09:27 |
| Lo-lan-do | G'day all | 10:16 |
| james_w | Hi Lo-lan-do | 10:17 |
| Lo-lan-do | I'm reading about the new dpkg source formats, including one called "3.0 (bzr)". | 10:17 |
| Lo-lan-do | (Basically, replace orig.tar.gz+diff.gz with a single tarball containing a bzr branch) | 10:17 |
| Lo-lan-do | That sounds interesting to me, but converting my main package (gforge) to it would make the source package grow from ~10MB to ~60MB, because of the full history included. | 10:18 |
| Lo-lan-do | So I was wondering whether the history horizon/shallow branches feature is still being worked on... | 10:18 |
| Kamping_Kaiser | i expect any package will have that problem too :| | 10:19 |
| Lo-lan-do | Not every package has thousands of revisions, but yeah. | 10:20 |
| Lo-lan-do | It would be nice to be able to only keep like the last year of revisions. | 10:20 |
| poolie | some preparatory work is happening but it is still over the horizon | 10:21 |
| Lo-lan-do | I see. | 10:22 |
| poolie | um | 10:23 |
| poolie | but you can use lightweight checkouts in many places, i presume | 10:23 |
| poolie | and then they will not be so large | 10:23 |
| poolie | anyhow, really going now | 10:23 |
| Lo-lan-do | I know about lightweight checkouts, but that's not the use case I'm talking about. | 10:24 |
| james_w | poolie: nice pun :-) | 10:27 |
| dato | heh, so I wasn't the only one =) | 10:27 |
| james_w | hi dato | 10:27 |
| dato | hello james_w | 10:28 |
| james_w | Lo-lan-do: I haven't looked in to those formats to understand them yet. | 10:28 |
| Lo-lan-do | james_w: They sound promising to me, but I won't switch quite yet, because of the size problem. | 10:32 |
| james_w | yeah, I think that's reasonable. | 10:32 |
| james_w | it seems to me like they may be more of a stepping stone to get to a proper VCS based workflow | 10:33 |
| chadmiller | Moin moin. | 12:20 |
| === mrevell_ is now known as mrevell-lunch | ||
| yacc | Just making sure, when I work with a remote repo, I do a "bzr commit" and after that a "bzr push", right? | 13:05 |
| yacc | So that my changes get immediatly applied to the remote repository? | 13:06 |
| Lo-lan-do | Yes, unless you're in a checkout (bound branch) | 13:06 |
| luks | by repo you mean a branch created by 'bzr branch'? | 13:06 |
| yacc | luks: not hundred percent. By repo I mean a svn+https:// url that I have created via bzr svn-push. | 13:07 |
| yacc | andreas@andi-lap:~/lookery/lookery_memberfind> bzr merge svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process/trunk/logs/lookery-memberfind | 13:07 |
| yacc | bzr: ERROR: Repository KnitPackRepository('file:///home/andreas/lookery/lookery_memberfind/.bzr/repository/') is not compatible with repository SvnRepository('svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process') | 13:07 |
| luks | oh, no idea about bzr-svn | 13:07 |
| yacc | Isn't that peachy? | 13:07 |
| luks | this looks like a incompatible shared repository format | 13:08 |
| james_w | yacc: you created ~/lookery/lookery_memberfind with bzr-svn? | 13:08 |
| luks | and I think it's explained in bzr-svn's FAQ | 13:08 |
| yacc | No, lookery/lookery_memberfind was the initial directory where the project started, so it was created by bzr init. | 13:09 |
| bob2 | the project originated in bzr, then was branched to svn? | 13:09 |
| yacc | bob2: yeah. | 13:09 |
| bob2 | the bzr branch has to have a compatible repository format | 13:09 |
| yacc | Yeah, but upgrade --rich-root-pack breaks too. | 13:10 |
| bob2 | 'bzr upgrade --rich-root-pack' (ideally after making a backupof it) | 13:10 |
| bob2 | ah, suck | 13:10 |
| yacc | bob2: well, I did already svn-push from this directory. | 13:10 |
| bob2 | the push will be fine | 13:10 |
| bob2 | pull/merge won't, tho | 13:11 |
| bob2 | some missing revision error from bzr upgrade? | 13:12 |
| james_w | yacc: what's the error on upgrade? | 13:12 |
| yacc | Yeah, but it complains about diverged branches and asks me to merge. Which is curious, as there have been no commits to the directory in the mean time. | 13:12 |
| yacc | bob2: it complains that some version does not exist in the repo. | 13:12 |
| yacc | james_w: bzr: ERROR: Revision {('andreas@andi-lap-20080318163204-v6cbndpdo3k2hneq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb6c53b2c>". | 13:12 |
| james_w | suck | 13:13 |
| james_w | yeah, I don't know if there is a workaround for that problem yet, sorry | 13:13 |
| bob2 | what about 'bzr missing' - does it show revisions missing on both sides? | 13:13 |
| james_w | abentley: hi, are you around? | 13:13 |
| yacc | james_w: yeah, I'm getting this sick feeling that despite jelmer's efforts bzr-svn is not a viable svn client solution ;( | 13:13 |
| bob2 | 'bzr reconcile' might 'fix' it for now | 13:13 |
| yacc | bob2: I already run reconcile | 13:13 |
| abentley | james_w: hi | 13:13 |
| james_w | abentley: hi, is there a workaround known for yacc's error above? | 13:14 |
| bob2 | yacc: the issue is with the conversion, as far as I know - if you'd started with rich-root-pack (or branched from svn), pretty sure it would be fine | 13:14 |
| yacc | That's curious, branching the svn repo freshly, commit the single again, and pushing it worked fine. | 13:14 |
| yacc | bob2: yeah, I have a feeling that the "start a svn repo with bzr" is not exactly a typical usecase. | 13:14 |
| james_w | yeah, you get the right local repository format that way, the problem is with the upgrade | 13:14 |
| bob2 | yacc: maybe branching the original bzr branch into a rich-root-pack repo would work, too | 13:15 |
| abentley | What was the original format? dirstate-tags? | 13:15 |
| yacc | bob2: well, I'll try to start my new egg with svn mkdir && bzr branch for a change. | 13:16 |
| yacc | abentley: the format before was pack-0.92. | 13:16 |
| bob2 | abentley: KnitPackRepository | 13:16 |
| yacc | abentley: But svn-pushing worked before, ... | 13:16 |
| james_w | yacc: yeah, it's not the typical use case. | 13:16 |
| bob2 | yacc: pushing wiwll work, it's the pulling of data from svn that is the issue, afaik | 13:16 |
| abentley | yacc: You were using bzr-svn 0.3? | 13:16 |
| yacc | abentley: nope :) | 13:17 |
| yacc | bob2: yeah, but it complained about diverging branches, so pulling was needed too. | 13:18 |
| yacc | bob2: despite that nobody has commited anything to the directory on svn. | 13:18 |
| bob2 | yacc: does 'bzr missing' explain that? | 13:18 |
| abentley | yacc: AIUI, bzr-svn 0.4 requires a rich-root format. So I don't know how you got that. | 13:18 |
| yacc | bob2: nope, I already managed to push it via a fresh branch. | 13:19 |
| yacc | abentley: which makes me wonder how the revisions in lookery-memberfind ended up in the svn repo in the first case? | 13:20 |
| yacc | Ok, I've got an idea what can be out of whack. | 13:21 |
| yacc | bzr missing complains that I'm missing the initial revision the directory is based on, that I did via "svn mkdir" if I remember right. | 13:21 |
| abentley | yacc: Could you run this in the root of your branch please? | 13:21 |
| abentley | python -c "from bzrlib import workingtree; wt = workingtree.WorkingTree.open('.'); wt.lock_read(); print wt.inventory.root; wt.unlock()" | 13:21 |
| yacc | abentley: nope, the branch had a portion of tender-love-care from rm -Rf ;( | 13:22 |
| abentley | yacc: So you didn't originate this bzr-svn conversion? | 13:22 |
| yacc | I did orginate yet again, but I solved it by branching the svn url freshly, applying my change and pushing it. Everything worked fine then. | 13:23 |
| james_w | yacc: did you just start with bzr init, made some commits, and then did bzr svn-push? | 13:24 |
| yacc | james_w: yes. | 13:24 |
| abentley | Alright, I guess there's nothing for me to see here. | 13:24 |
| james_w | thanks abentley | 13:24 |
| abentley | james_w: To somewhat answer your question, there are two fixable causes of that error. | 13:25 |
| abentley | One is the sort of data inconsistencies that reconcile will fix, so that's fixable. | 13:25 |
| yacc | And the second one? | 13:26 |
| abentley | The other is that the non-rich -> rich converter assumes non-rich trees have TREE_ROOT as their tree root. That hasn't been addressed yet, but I'm planning to do it as part of my pack-1.4 work. | 13:26 |
| schierbeck | hey guys -- any news on nested branches? | 13:28 |
| james_w | abentley: great, thanks. | 13:28 |
| james_w | schierbeck: I think LarstiQ had almost all tests passing in London, so hopefully we will get the first bits to review at some point. | 13:29 |
| schierbeck | awesome! | 13:29 |
| === mrevell-lunch is now known as mrevell | ||
| deepjoy | bzr+http woohoo!!! | 13:56 |
| deepjoy | finally got the basics running | 13:56 |
| deepjoy | not if only I could figure out how to use the update the working tree remotely or an alternate work flow that will server multiple developers | 13:57 |
| deepjoy | I have bzr+http with write enabled working with mod_authz_ldap | 13:58 |
| deepjoy | anybody here to share my joy :-) | 13:58 |
| dato | "yay!" | 13:58 |
| Lo-lan-do | Yaaay. | 13:58 |
| deepjoy | dato: Lo-lan-do: thanks | 13:59 |
| chadmiller | Hi all. I'm trying to push a Very Large pack-0.92 branch (total repo is ~500MB) to Launchpad using very recent bzr.dev over bzr+ssh. | 13:59 |
| bob2 | deepjoy: you should document that somewhere :) | 14:00 |
| chadmiller | By my calculation, if it were just streaming data, it would take ~30 minutes over my 'net connection. | 14:00 |
| chadmiller | But, I stopped it yesterday at 8 hours, with the progress bar about 2/5ths the way across the screen. | 14:01 |
| Lo-lan-do | chadmiller: You might try packing it first | 14:01 |
| Lo-lan-do | (But I don't know what I'm talking about, so ignore me if I'm just giving nonsense) | 14:02 |
| chadmiller | It is packed. | 14:02 |
| bob2 | was it still sending data when it stopped (according to iptraf or tcpdump or whatever) | 14:02 |
| chadmiller | bob2: Yes. | 14:02 |
| chadmiller | The trees are public, if anyone wants to try. | 14:04 |
| chadmiller | https://code.edge.launchpad.net/~mysql-developers/ | 14:04 |
| chadmiller | branch from 6.0-trunk, push back. | 14:05 |
| Lo-lan-do | chadmiller: Are you trying to push over a DSL line? | 14:05 |
| chadmiller | Lo-lan-do: No. Cable. | 14:05 |
| Lo-lan-do | Large latency? | 14:06 |
| chadmiller | No, not usually. Very good, most of the time. | 14:06 |
| Lo-lan-do | If so, you may want to rsync over to a good server, and push from there | 14:06 |
| luks | pushing over sftp will be probably faster than over bzr+ssh if it's just one big pack file | 14:07 |
| chadmiller | Lo-lan-do: I can scp the whole repo in ~30 minutes. | 14:08 |
| Lo-lan-do | chadmiller: Hence the idea to push over bzr+ssh from a place where network roundtrips don't matter much | 14:09 |
| chadmiller | Lo-lan-do: That's not it, sorry. | 14:09 |
| Lo-lan-do | Then I'm happy to be ignored :-) | 14:09 |
| chadmiller | While I've been patient about other uses of bazaar, I'm trying to decide whether or not to use bazaar (and launchpad) for my Google-Summer-of-Code students. | 14:17 |
| james_w | chadmiller: the ~/.bzr.log from the push may give some clues | 14:21 |
| james_w | chadmiller: for future reference -Dhpss can help debugging this | 14:22 |
| chadmiller | james_w: The .bzr.log has the startup info, and then at t+33 "Using fetch logic to copy..." and is then silent. | 14:23 |
| james_w | chadmiller: that's not much use then. | 14:23 |
| james_w | shame | 14:23 |
| chadmiller | james_w: I left it running last night with -Dhpss, and (I suppose) it bogged down enough that the ssh socket timed out. | 14:24 |
| chadmiller | Oh, wait, that was -Devil. | 14:24 |
| * chadmiller uses hpss. | 14:24 | |
| james_w | -Devil isn't that useful as it doesn't really change depending on your specific circumstances | 14:25 |
| chadmiller | (Yeah. After the 8-hour wait, I wanted to see if there was anything obviously algorithmic in the way.) | 14:26 |
| asabil | when having a conflicts | 14:54 |
| asabil | is there a way to tell resolve to auto pick the .THIS ? | 14:54 |
| asabil | overriding the changed from .OTHER ? | 14:54 |
| james_w | I don't think so | 14:54 |
| asabil | oki thanks | 14:55 |
| fullermd | cp ; resolve | 14:57 |
| fullermd | Or revert, I s'pose. | 14:57 |
| asabil | fullermd: yes, but when you have a bunch of files | 14:59 |
| asabil | you need to end up using find | 15:00 |
| Lo-lan-do | Not necessarily. | 15:00 |
| fullermd | Nah, you could use perl instead ;) | 15:00 |
| Lo-lan-do | How about "bzr conflicts --text | xargs bzr revert"? | 15:00 |
| james_w | that should work | 15:00 |
| asabil | hmmm right, forgot aboy xargs | 15:00 |
| asabil | about* | 15:01 |
| asabil | thanks | 15:01 |
| fullermd | Though it does lead one to think that bzr really needs a -0 option... | 15:01 |
| fullermd | Got it on ls, but not on conflicts. | 15:02 |
| Lo-lan-do | Also, this will entirely drop the parts of the patches that are not conflicting. | 15:03 |
| === mw|out_ is now known as mw | ||
| === kiko-zzz is now known as kiko | ||
| luislavena | hello guys, question for any using bzr-svn... | 17:00 |
| luislavena | even I created a branch in svn using svn copy from trunk, bzr merge is not accepting it: | 17:00 |
| luislavena | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 17:00 |
| luislavena | I use bzr pull since branch was eating all my memory :P | 17:00 |
| Lo-lan-do | luislavena: I know, I already reported that bug. | 17:05 |
| luislavena | Lo-lan-do: oh, I see, I'm not the only one. | 17:05 |
| Lo-lan-do | https://bugs.launchpad.net/debian/+bug/197356 | 17:05 |
| ubotu | Launchpad bug 197356 in debian "Branches created in svn don't seem related in bzr (dup-of: 203368)" [Unknown,Confirmed] | 17:05 |
| luislavena | Lo-lan-do: how do you workaround it? | 17:05 |
| ubotu | Launchpad bug 203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Wishlist,Confirmed] | 17:05 |
| Lo-lan-do | Which is even a duplicate | 17:05 |
| Lo-lan-do | I, uh, don't. | 17:06 |
| Lo-lan-do | Apart from using bzr-push to create the branch in the first place. | 17:06 |
| luislavena | Lo-lan-do: the branch already existed :-( | 17:07 |
| luislavena | guess that will have to deal with the shelve. | 17:07 |
| Stavros | hello | 17:52 |
| Stavros | what's the difference between "bzr branch" and "bzr co"? | 17:52 |
| LeoNerd | Where the commits go | 17:52 |
| LeoNerd | If you commit to a 'branch'ed one, it's only stored there | 17:52 |
| LeoNerd | If you commit to a 'co'ed one, it'll try to push it back upstream again | 17:52 |
| Stavros | ah, so you need to push afterwards | 17:52 |
| Stavros | aha, thanks | 17:53 |
| LeoNerd | push, or pull from the other place, or merge.. | 17:53 |
| Stavros | ah | 17:53 |
| LeoNerd | Basically, it's a question of "is this some other branched work, or is it supposed to be 'thesamework' in another physical location?" | 17:53 |
| Stavros | hmm, it's the latter, but i think i'll still tell people to branch | 17:53 |
| Stavros | so they can commit offline until they're ready to push | 17:54 |
| LeoNerd | Ah.. well, that can be done too | 17:54 |
| LeoNerd | For "occasional-offline" machines, you can co anyway.. and pass the --local flag to commit | 17:54 |
| Stavros | indeed... | 17:54 |
| Stavros | is there a windows setup package that includes a gui? | 17:54 |
| Stavros | i suggested bzr over svn so i want to make this as easy as possible | 17:55 |
| Stavros | (to avoid getting lynched, you understand) | 17:55 |
| jkakar | Is bzrtools distributed in the bzr PPA? | 17:58 |
| abentley | jkakar: yes | 17:58 |
| jkakar | abentley: Cool, thanks. | 18:00 |
| sabdfl | hey folks, should we still have "baz" packages in ubuntu, labelled "bazaar"? | 18:21 |
| chadmiller | sabdfl: I think it's to be fixed soon. The disambiguating version number is about to be false too. | 18:22 |
| dato | sabdfl: afaik james_w and beuno are putting some work into having them renamed to baz, and have bazaar be bzr (at some point) | 18:23 |
| sabdfl | james_w: is that a hardy exercise? | 18:23 |
| sabdfl | imo, we definitely don't want "bazaar" being "baz" for all of hardy | 18:23 |
| james_w | sabdfl: I would like it to be, but baz FTBFS and I haven't been able to fix that yet | 18:24 |
| james_w | so the transition is stalled until we can fix that. | 18:24 |
| dato | .oO(unless you completely drop it from the dist) | 18:24 |
| * sabdfl is inclined to drop baz | 18:24 | |
| sabdfl | does bzr still do a good job of conversion from baz? | 18:25 |
| chadmiller | sabdfl: What's the "sa"? | 18:25 |
| james_w | that's reasonable, we'd like to do the transition in Debian as well, and there is less support for just dropping it there | 18:25 |
| james_w | the other thing is that baz is a requirement for bzr baz-import, and so it's a way we can provide a migration path for baz users to bzr | 18:25 |
| ubotu | New bug: #208387 in bzr "bzrtools 1.3 is not available for feisty fawn" [Undecided,New] https://launchpad.net/bugs/208387 | 18:26 |
| sabdfl | chadmiller: self-appointed | 18:31 |
| Stavros | hmm, i think bzr doesn't like cygwin | 18:58 |
| Stavros | bash: bzr: command not found | 18:58 |
| james_w | Stavros: did you install the cygwin or Windows bzr? | 19:00 |
| Stavros | james_w: python, i think | 19:00 |
| Stavros | definitely not cygwin | 19:00 |
| Stavros | let me doublecheck | 19:00 |
| james_w | I think you may need to adjust your $PATH | 19:01 |
| james_w | though I think windows bzr through cygwin is a long road to pain | 19:01 |
| ubotu | New bug: #208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Undecided,New] https://launchpad.net/bugs/208418 | 19:01 |
| Stavros | damn, it's huge | 19:01 |
| Stavros | james_w: it's not through cygwin | 19:01 |
| Stavros | i didn't touch cygwin | 19:01 |
| james_w | yeah, there's a separate cygwin port | 19:02 |
| Stavros | i have no clue wtf it's doing with bash now.. | 19:04 |
| Stavros | oh | 19:04 |
| Stavros | maybe it's running bash on the remote server | 19:04 |
| Stavros | or maybe bash is telling me bzr wasn't found | 19:05 |
| Stavros | that's it :/ | 19:05 |
| Stavros | what's an easy to install gui for windows? | 19:05 |
| james_w | ah, what command are you running? | 19:05 |
| Stavros | bzr+ssh | 19:06 |
| Stavros | but it's odd, because bzr is supposed to be there | 19:06 |
| james_w | BZR_REMOTE_PATH might help you there. | 19:06 |
| james_w | set that in your environment to be the path to bzr on your server | 19:06 |
| Stavros | hmm, it's multiuser, so it should just work :/ | 19:07 |
| Stavros | i will ask the admin to do it | 19:07 |
| Stavros | hmm, shouldn't bare ssh:// work? | 19:10 |
| fullermd | Well, it doesn't. | 19:10 |
| fullermd | "should" is a very broad question :p | 19:10 |
| Stavros | hmm | 19:10 |
| Stavros | so anything i can do now? | 19:12 |
| sabdfl | poolie: ping | 19:23 |
| james_w | Stavros: sftp:// should work for you | 19:28 |
| Stavros | oh, thanks | 19:28 |
| Stavros | ah, it needs paramiko :/ | 19:28 |
| Stavros | does anyone have the link to the qt redist i need to install to get qbzr to work? the one i got is 70 mb | 19:29 |
| james_w | does it work? | 19:30 |
| Stavros | does what work? | 19:30 |
| james_w | the distribution you have? | 19:31 |
| Stavros | what do you mean? i'm in windows | 19:32 |
| james_w | you said "does anyone have the link to the qt redist i need...the one i got" | 19:32 |
| Stavros | oh | 19:32 |
| james_w | which seems contradictory to me | 19:32 |
| Stavros | i mean the link i found | 19:32 |
| Stavros | i didn't download it | 19:33 |
| james_w | ah, ok | 19:33 |
| Stavros | is that the correct one? | 19:33 |
| james_w | is it a qt distribution, or a qbzr one? | 19:33 |
| Stavros | qt | 19:33 |
| Stavros | damnit, why doesn't anyone include the correct link in the qbzr page? :( | 19:36 |
| === mw is now known as mw|food | ||
| luks | because you are supposed to use the binary qbzr installer | 19:37 |
| Stavros | what if you used the python bzr package? | 19:37 |
| luks | that's not a problem | 19:37 |
| Stavros | apparently it is, because i can't get it to work | 19:38 |
| luks | unless you have some strange version of python | 19:38 |
| Stavros | i just installed 2.5 | 19:38 |
| Stavros | qt isn't included in what i installed | 19:38 |
| luks | yep, I said the binary installer | 19:38 |
| Stavros | the 110 kb one? | 19:38 |
| luks | you can use http://www.riverbankcomputing.co.uk/pyqt/download.php for the other one | 19:39 |
| luks | I dunno how big is it | 19:39 |
| Stavros | it doesn't include qt | 19:39 |
| luks | that's the wrong one then | 19:39 |
| Stavros | there's one for python and one for standalone | 19:39 |
| luks | "qbzr-setup-0.8.0.exe " | 19:39 |
| Stavros | that's for the standalone bzr version | 19:39 |
| Stavros | i don't want that version | 19:39 |
| luks | ignore that | 19:40 |
| luks | otherwise, download pyqt from the link I posted | 19:40 |
| Stavros | ok, i'll do that and see... | 19:40 |
| james_w | jelmer: my apologies, I underestimated bzr-svn | 20:02 |
| jelmer | yacc: if you want a stable bzr-svn, use a release... | 20:03 |
| LarstiQ | bzr: ERROR: Unable to push revision 'wouter@chuck-20080328195425-e5de7xtz87t6ozd4' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path | 20:04 |
| LarstiQ | ho hum | 20:04 |
| LarstiQ | jelmer: I suppose this is due to different branching schemes | 20:04 |
| jelmer | LarstiQ: you can only append revisions when pushing to a repository root | 20:06 |
| jelmer | LarstiQ: you merged I think, and that would change the lhs revision history | 20:07 |
| jelmer | yacc: still there? | 20:14 |
| LarstiQ | jelmer: well. That sucks. | 20:16 |
| jelmer | LarstiQ: it's impossible to change the root in subversion | 20:16 |
| LarstiQ | jelmer: I don't understand it yet, but I'll just uncommit for now | 20:17 |
| fullermd | Anything's possible if you push hard enough ;) | 20:27 |
| RainCT | Hi | 20:31 |
| RainCT | can I let bzr remember two commit URLs? | 20:31 |
| RainCT | ie, save a second one with an alias so that I don't have to write the complete URL each time I want to push there | 20:32 |
| beuno | RainCT, I don't think you can have aliases on a per-branch basis | 20:32 |
| RainCT | hm.. well I think I'll just keep two branches locally too | 20:35 |
| RainCT | thx | 20:35 |
| === mw|food is now known as mw | ||
| beuno | RainCT, you can always file a bug requesting it :) | 21:06 |
| james_w | yeah, aliases would be a good thing to have | 21:16 |
| RainCT | james_w: great you want them too, feel free to request them then :P | 21:19 |
| james_w | feel free to implement them :-) | 21:19 |
| fullermd | It's probably been at least a month since they were last requested :P | 21:20 |
| javierder | Hello! | 21:24 |
| javierder | I'm working in a bzr plugin for Gedit. | 21:25 |
| javierder | And I have a problem! :) | 21:25 |
| dash | Hi. does bzr have anything like svn's "externals"? | 21:25 |
| javierder | when doing a workingtree.smart_add("mypath") to add everything there, it only adds files in that directory, but it's not recursive... | 21:26 |
| beuno | jelmer, ping | 21:40 |
| abentley | dash: There has been some work on that, but it is incomplete. | 21:41 |
| dash | OK | 21:41 |
| dash | is it the useful-in-limited-situations kind of incomplete or the breaks-in-surprising-ways kind? :) | 21:42 |
| abentley | sabdfl: bzrtools does good conversion from baz, but it uses baz to do it. (bzr itself has never handled baz) | 21:43 |
| abentley | dash: The latter. | 21:44 |
| dash | OK. | 21:44 |
| sabdfl | thanks abentley | 21:44 |
| dash | Guess I'll be patient then. :) | 21:44 |
| sabdfl | anybody know why 1.3 hasn't shown up in the PPA? | 21:44 |
| beuno | sabdfl, it has today :) | 21:45 |
| beuno | I just installed a few minutes ago | 21:46 |
| beuno | ah, you meant bzrtools | 21:46 |
| * beuno goes back into vim | 21:46 | |
| awmcclain | Just to be clear... there's no way to check out one file from a branch, correct? | 21:52 |
| james_w | corrrect | 22:00 |
| james_w | javierder: I think it should be recursive, is there a recursive parameter to the method? | 22:01 |
| james_w | javierder: another possibility is that all the files in there are ignored. | 22:01 |
| javierder | james_w, i found the problem. there was a .bzr inside the subfolder. thanks! | 22:31 |
| james_w | javierder: cool | 22:34 |
| awmcclain | uh oh | 22:43 |
| james_w | what's up? | 22:44 |
| awmcclain | I think i really broke something... I changed my .bzr/branch/location from sftp:// to bzr+ssh://, got a bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request '/'\n" | 22:45 |
| awmcclain | And now when i changed it back, i get bzr: ERROR: Not a branch: "sftp://bamboo.fluther.com/repos/conf/ | 22:45 |
| james_w | ouch | 22:45 |
| awmcclain | any thoughts? | 22:45 |
| james_w | double ouch | 22:45 |
| james_w | I'm not really sure. | 22:46 |
| awmcclain | triple ouch | 22:46 |
| james_w | that's a public branch? Is there http access? | 22:46 |
| awmcclain | no, it's publicly available authenticated branch | 22:46 |
| james_w | ok, can you ssh to the machine? | 22:49 |
| james_w | if you can please do so and ls -R .bzr on the branch. | 22:50 |
| james_w | let's find out what state it is in | 22:50 |
| luislavena | hello everybody. | 23:00 |
| luislavena | been testing bzr-svn in my workflow, and found something funny... | 23:00 |
| luislavena | if you svn-push a new branch (which previously was a branch from trunk) and forgot to push the changes in trunk, it always mark as missing and don't let oyu push them... | 23:01 |
| awmcclain | ok | 23:05 |
| awmcclain | james_w: Here's the output of the ls http://dpaste.com/41918/ | 23:06 |
| awmcclain | james_w: Fortunately, I don't have very many changes | 23:08 |
| awmcclain | james_w: I can re-checkout the branch and port my changes over | 23:08 |
| james_w | luislavena: you probably want to file a bug on that | 23:10 |
| james_w | awmcclain: sorry, I was trying to code, let me look now | 23:10 |
| awmcclain | james_w: np | 23:10 |
| hno | Is there any way of creating a submission bundle (bzr send) of changes already in trunk? | 23:10 |
| james_w | awmcclain: that's the remote branch? | 23:10 |
| awmcclain | james_w: Correct. | 23:11 |
| james_w | it looks ok. perhaps you should cat .bzr/branch/format and check it is sane | 23:11 |
| awmcclain | james_w: I just rebranched and was able to checkin | 23:11 |
| james_w | hno: you might be able to do it with a -r | 23:11 |
| awmcclain | err | 23:11 |
| beuno | hno, I suppose you could copy over trunk, bzr revert to where you want it, and do a send against that one | 23:11 |
| luislavena | james_w: ok, I'll try to recreate the steps and post on a bug. | 23:11 |
| luislavena | james_w: thank you. | 23:11 |
| james_w | and what beuno says | 23:11 |
| awmcclain | james_w: (re checked-out, i should say) | 23:11 |
| lifeless | hno: yes, just supply the exact revision range | 23:12 |
| hno | james_w: Not quote.. the patch gets rendered fine, but the resulting bundle is empty.. | 23:12 |
| lifeless | hno: -r x..y | 23:12 |
| james_w | hi lifeless | 23:12 |
| hno | hi lifeless | 23:12 |
| james_w | awmcclain: odd, perhaps your local end was messed up | 23:12 |
| james_w | awmcclain: does it still happen with the original checkout? | 23:12 |
| awmcclain | hrm | 23:12 |
| hno | lifeless: I guess it's due to not really having a target branch.. | 23:12 |
| james_w | awmcclain: -Derror and ~/.bzr.log might help if so | 23:12 |
| james_w | though I don't know if -Derror will change anything here | 23:13 |
| hno | (used trunk as the target) | 23:13 |
| james_w | hno: what do you want the merge directive for? | 23:13 |
| lifeless | hno: perhaps try manual target branch etc; it seems to me it should still add content in this case and I'd call it a bug | 23:13 |
| fullermd | Mmmph. Seems like we've had that discussion more than once... | 23:14 |
| awmcclain | james_w: A ha! | 23:15 |
| hno | lifeless: I guess it would work specifying an empty target branch, or at least one not having the change... | 23:15 |
| awmcclain | james_w: Newline at the end of the file! | 23:15 |
| james_w | awmcclain: wow | 23:15 |
| fullermd | hno: I doubt that would do what you want either... | 23:15 |
| awmcclain | james_w: FTR, this is all because you can't do a branch on a rich-root-pack over ssh:// | 23:16 |
| james_w | bzr+ssh://> | 23:16 |
| james_w | ? | 23:16 |
| awmcclain | james_w: Correct. | 23:16 |
| james_w | awmcclain: sorry, I'm not familiar with that problem, what is it? | 23:17 |
| awmcclain | james_w: Ah. Branch over a smart protocol default to creating the branch in the default format (pack?). If you have a branch converted from svn (in rich-root-pack) it will fail. The workarounds are 1) Do a lightweight checkout 2) cehckout into a shared repo formatted with rich-root-pack 3) checkout over sftp://, then change the protocol to bzr+ssh:// | 23:18 |
| hno | using an empty target branch was not a good idea.. bzr send -r x..y /empty/branch is chewing up all the cpu... | 23:18 |
| lifeless | hno: yah; I think this is a bug :> | 23:19 |
| fullermd | It'll end up bundling the WHOLE branch. | 23:19 |
| lifeless | hno: using a branch without y, where -r x..y, will work; ideally the branch will contain x. | 23:19 |
| hno | Feels kind of odd to not be able to create an untargeted bundle.. | 23:20 |
| fullermd | The logic (AIUI) goes like - "-r" gives the rev range to be commanded - The displayed patch is an approximation of the result of applying that - The revisions bundled up are determined by what doesn't exist in the target branch | 23:21 |
| james_w | awmcclain: ah, I remember now, thanks | 23:21 |
| hno | fullermd: Yes, I understand that. But what I need in this case is to bundle exactly the revisions said without a specific target.. it's input to a separate cherrypicking/backporting tracker. | 23:23 |
| fullermd | Right; there isn't a way. | 23:24 |
| fullermd | What you'd do is make a temp branch to use as the target holding the base rev. | 23:24 |
| fullermd | (at least, there isn't a UI way; you could probably force it using bzrlib directly) | 23:25 |
| * hno isn't a very python guy.. | 23:25 | |
| * fullermd isn't either :) | 23:26 | |
| * hno wonders what that send against an empty target is up to.. it's still running.. | 23:27 | |
| fullermd | Bundling up the whole history of the branch. | 23:27 |
| fullermd | (after all, the target doesn't have ANY of those revs, so we need to send them ALL) | 23:27 |
| hno | that doesn't make sense. | 23:28 |
| fullermd | A merge directive is a directive to merge. -rx..y defines what revs the other end is being told to merge. The target branch determines what revs need to be bundled to do that. | 23:29 |
| fullermd | So the bundled revs are something like -r{HEAD_OF_TARGET_BRANCH}..y | 23:29 |
| fullermd | And since the head of your target branch is nothing (or at least, nothing in the ancestry of x or y, which is the same thing in this case)... | 23:30 |
| james_w | heh, it seems I've invented an O(ugliness of history algorithm) | 23:36 |
| james_w | or rather O(ugliness of history) algorithm | 23:36 |
| james_w | though I'm sure the former would be an interesting one to try and analyse | 23:36 |
| hno | fullermd: I believe you that it's what bzr does. But still doesn't make sense. | 23:39 |
| james_w | on bzr.dev: bzr mlog 4.21s user 0.09s system 93% cpu 4.598 total | 23:39 |
| james_w | on emacs: 0.24s user 0.05s system 87% cpu 0.328 total | 23:39 |
| james_w | (straight line history for the latter) | 23:39 |
| === mw is now known as mw|out | ||
| james_w | though I guess it's not unusual | 23:41 |
| fullermd | james_w: The prettier the algorithm is, the better it scales? There's a PhD thesis in there somewhere... | 23:44 |
| james_w | I think so too | 23:45 |
| fullermd | Hm. That suggests that code optimization could best be done in Befunge... | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!