| abadger1999 | jam: Shh.. Not that one, the other one! | 00:00 |
|---|---|---|
| abadger1999 | :-) | 00:00 |
| lifeless | hi guys | 00:01 |
| lifeless | I'm back on deck | 00:01 |
| mwhudson_ | wb lifeless | 00:01 |
| === mwhudson_ is now known as mwhudson | ||
| abadger1999 | So I'm a bit conflicted about all the changes going into the 1.x series. I love how it makes the code better instead of crufty. But at the same time as a packager, I sometimes feel like I shouldn't be pushing a new update to a release. | 00:02 |
| LaserJock | is there a way to see what branch format a branch on LP is in without branching it? | 00:02 |
| abadger1999 | Which is okay for Fedora (just update to the next release, it will be out in < 6 months) | 00:02 |
| jam | LaserJock: bzr info URL | 00:02 |
| jam | I would generally recommend the http url, otherwise you get something about the RemoteRepository, IIRC | 00:02 |
| abadger1999 | But it's going to be hard if I do that for RHEL (five years on an old version of bzr with no upstream bug fixes or security fixes). | 00:03 |
| LaserJock | darn, still getting "not a branch" | 00:03 |
| mwhudson | LaserJock: can you give us more details? | 00:03 |
| LaserJock | trying to pull bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ | 00:04 |
| jam | abadger1999: well i would argue that we've had lots of upstream bug fixes and security fixes, we just stamp it with a new release ... :) | 00:04 |
| jam | but I understand your point | 00:04 |
| jam | as of yet, there hasn't been enough impetus to backport anything | 00:04 |
| jam | I think we've had only 1 'x.y.1' release, and maybe discussed doing it 2 or 3 times | 00:04 |
| abadger1999 | jam: Yep! So far I've just rolled out updates with every new bzr release to gain all the new features/performance/bugfixes. | 00:06 |
| abadger1999 | But every time I see an entry under API BREAKS, I have to re-evaluate whether I can keep doing that or if doing so will break the expectations of the users consuming my package. | 00:06 |
| abadger1999 | It's just a mismatch between a fast moving product like bzr and pushing it to a distro with a long-term support cycle. | 00:08 |
| abadger1999 | Not sure what you guys could do about it except maybe emulating gnome by introducing new API (and deprecating the old one) instead of removing API when it is superseded by something better. | 00:09 |
| abadger1999 | But that's an increased support burden on you so I understand why you wouldn't want to do that. | 00:09 |
| jam | abadger1999: we do that for most things | 00:10 |
| jam | though "long term" is months in our case, not years | 00:10 |
| LaserJock | mwhudson: any thoughts? | 00:10 |
| jam | abadger1999: but sometimes we decide to cut our losses, rather than support something broken for a long time | 00:10 |
| abadger1999 | jam: heh. Yeah :-) | 00:10 |
| abadger1999 | months vs years is the issue I face :-) | 00:10 |
| jam | abadger1999: we've supported the disk formats for years | 00:11 |
| foom | yeah but you can't use an old version of bzr for anything | 00:11 |
| foom | because everyone *else* is using new formats | 00:11 |
| bob2 | LaserJock: wfm (r3377) | 00:12 |
| LaserJock | mwhudson: so it seems that bzr+ssh didn't work but http did | 00:12 |
| abadger1999 | Which leads to problems on a long-term supported distro... introduce a new version so some users can collaborate with others using the new format or stay with the old version so some other users can continue using their in-house, custom tools. | 00:12 |
| mwhudson | LaserJock: oh, hm | 00:12 |
| mwhudson | LaserJock: you have done bzr launchpad-login, i take it? | 00:13 |
| LaserJock | what do you mean? | 00:13 |
| abadger1999 | I guess another option would be to allow for multiple versions of bzr/bzrlib to be installed. | 00:13 |
| LaserJock | oh, no, I haven't | 00:13 |
| LaserJock | why do I need to do that? | 00:13 |
| mwhudson | LaserJock: so bzr+ssh knows with user to use | 00:14 |
| LaserJock | I told it to use my LP id | 00:14 |
| mwhudson | oh, ok | 00:14 |
| mwhudson | LaserJock: can you pastebin what happens when something goes wrong? | 00:14 |
| abadger1999 | Use deprecation until a new disk format appears/you don't want to keep supporting all the cruft. Then release with all that fixed and the module as bzrlib2. | 00:14 |
| LaserJock | mwhudson: it's just: | 00:15 |
| LaserJock | Using saved location: bzr+ssh://laserjock@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ | 00:15 |
| LaserJock | bzr: ERROR: Not a branch: "bzr+ssh://laserjock@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/". | 00:15 |
| foom | abadger1999: that only really seems doable for a mature project that's not changing rapidly | 00:15 |
| abadger1999 | That works for libraries, but I don't know that it would work for bzr since it has a client app as well. | 00:16 |
| abadger1999 | foom: Definitely would be better for mature projects :-) | 00:16 |
| abadger1999 | But GNOME is a counterpoint. They've managed not to break API compatibility for a long time despite making many changes to the API. But they pay for it by having to drag all the compatible stuff along with the good changes. | 00:18 |
| mwhudson | LaserJock: bzr -Dhpss pull and look at ~/.bzr.log ? | 00:18 |
| LaserJock | mwhudson: doesn't look all that helpful to me but I can pastebin it for you | 00:20 |
| mwhudson | LaserJock: please do | 00:20 |
| abadger1999 | Oh well, when wearing my Fedora hat I love that bzr is evolving rapidly, when wearing my EPEL maintainer hat, I often feel guilty that I'm pushing a bzr update which may break someone's code somewhere. | 00:21 |
| abadger1999 | Like I said in the beginning. I'm conflicted about this and don't see an easy answer. | 00:21 |
| LaserJock | mwhudson: http://paste.ubuntu.com/7807/ | 00:21 |
| mwhudson | LaserJock: can you write to this branch? | 00:25 |
| LaserJock | in what way? | 00:25 |
| mwhudson | push to it | 00:25 |
| LaserJock | supposedly :-) | 00:25 |
| mwhudson | are you a member of ~ubuntu-core-doc ? | 00:25 |
| LaserJock | yes I am | 00:26 |
| thumper | LaserJock: I'll take a closer look on the machine... | 00:26 |
| LaserJock | I'm just in the middle of trying to fix a boo boo | 00:26 |
| LaserJock | which I made need some help figuring it out | 00:26 |
| LaserJock | we lost some revisions on the edubuntu-hardy branch | 00:26 |
| LaserJock | and I'm not sure the best way of getting them back | 00:27 |
| LaserJock | I think as long as I keep the formats straight I should be able to just push | 00:27 |
| mwhudson | uh | 00:27 |
| mwhudson | there is no .bzr directory at all in the push area for this branch!? | 00:27 |
| LaserJock | mwhudson: which branch? | 00:28 |
| mwhudson | LaserJock: ~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy | 00:28 |
| LaserJock | you mean you can't find one or do I see one? :-) | 00:29 |
| thumper | mwhudson: yes there is | 00:29 |
| thumper | ah | 00:29 |
| thumper | damnit looking at the wrong one | 00:29 |
| mwhudson | LaserJock: i'm not asking you a question, don't worry | 00:30 |
| LaserJock | mwhudson: ok, phew ;-) | 00:30 |
| mwhudson | LaserJock: is there the slightest chance that some one has done the equivalent of "rm -rf .bzr" on this branch? | 00:30 |
| LaserJock | mwhudson: mdke said he was updating the branch formats | 00:30 |
| mwhudson | oh | 00:30 |
| mwhudson | ho ho | 00:30 |
| LaserJock | in so doing I lost 9 revisions in my edubuntu-docs branch | 00:31 |
| LaserJock | which is what I was originally trying to fix | 00:31 |
| LaserJock | but it got me sidetracked when I couldn't bzr pull the ubuntu-hardy branch | 00:31 |
| LaserJock | s/edubuntu-docs/edubuntu-hardy/ | 00:32 |
| === Necoro_dM is now known as Necoro | ||
| mwhudson | so, i have to admit, i don't really know what's happened here | 00:37 |
| LaserJock | hmm, ok | 00:38 |
| mwhudson | if mdke was trying to do format upgrades, that sounds like its probably related | 00:38 |
| LaserJock | would be logical | 00:38 |
| mwhudson | LaserJock: is the version you see at the http: url at the revision you expect? | 00:38 |
| LaserJock | yeah, it pulled in a couple revisions | 00:39 |
| LaserJock | it looked fine to me | 00:39 |
| mwhudson | looks like 3799 | 00:39 |
| mwhudson | i can copy that back into the push area | 00:39 |
| mwhudson | i guess i can do the upgrade on the server too while we're at it... | 00:40 |
| LaserJock | mwhudson: so you're able to recover the branch? | 00:42 |
| mwhudson | LaserJock: yes, if you want me to | 00:43 |
| LaserJock | mwhudson: any reason not to? | 00:44 |
| LaserJock | I assume we don't want it in the state it's in | 00:44 |
| mwhudson | LaserJock: i can't think of one | 00:44 |
| LaserJock | as long as we don't loose anything :-) | 00:44 |
| mwhudson | LaserJock: do you want it upgraded to rich-root-pack at the same time? | 00:44 |
| LaserJock | yeah, that's what we're after | 00:45 |
| mwhudson | in progress | 00:45 |
| LaserJock | mwhudson: can you see if anything happened to kubuntu-hardy and xubuntu-hardy? | 00:46 |
| LaserJock | I know I lost 9 revisions in edubuntu-hardy but I assume I can fix that with a bzr push | 00:46 |
| mwhudson | they look ok | 00:48 |
| mwhudson | edubuntu-hardy has been upgraded | 00:48 |
| mwhudson | which might be where you revisions went | 00:49 |
| mwhudson | if mdke did it by downloading the branch, upgrading and uploading it again | 00:49 |
| LaserJock | yeah | 00:49 |
| LaserJock | I don't know why he wouldn't have the revisions though | 00:49 |
| LaserJock | maybe he forgot to bzr pull first | 00:49 |
| LaserJock | mwhudson: would it be possible to have one of you guys convert kubuntu-hardy and xubuntu-hardy on the server? | 00:51 |
| LaserJock | so we don't end up with issues like this | 00:51 |
| mwhudson | LaserJock: yes, sounds sane | 00:51 |
| LaserJock | I'm sure mdke would appreciate it | 00:52 |
| mwhudson | LaserJock: can you ask a question on launchpad-bazaar ? | 00:52 |
| LaserJock | I can | 00:52 |
| lifeless | abadger1999: they have actually broken ABI since 2.0, if you consider ABI in the broader sense of 'the behaviour' rather than just 'it links and structs are the same size' | 00:53 |
| lifeless | abadger1999: but this doesn't invalidate your point about the costs | 00:54 |
| LaserJock | mwhudson: question asked and I fixed up edubuntu-hardy | 00:58 |
| === mw is now known as mw|out | ||
| === kiko is now known as kiko-zzz | ||
| lifeless | spiv: bug 220806 | 01:55 |
| ubotu | Launchpad bug 220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [Undecided,New] https://launchpad.net/bugs/220806 | 01:55 |
| spiv | lifeless: ta | 02:02 |
| lifeless | :) | 02:02 |
| abentley | lifeless, spiv: Initial branch of rocketful over bzr+ssh is excruciatingly slow. | 02:05 |
| spiv | abentley: hmm. | 02:05 |
| lifeless | abentley: yes | 02:05 |
| abentley | Our new hire reported it took 4 hours. | 02:05 |
| bob2 | ow | 02:06 |
| bob2 | segwayfuel | 02:06 |
| lifeless | we're running bzr 1.3.1 on devpad | 02:06 |
| abentley | I'm not sure how long it took for me at first. tens of minutes? | 02:06 |
| lifeless | it should have the newer graph logic | 02:06 |
| lifeless | what bzr did the hire use? | 02:07 |
| abentley | I dunno, but it looks pretty wrong with bzr.dev. | 02:07 |
| lifeless | did they create a pack or knit local repo? | 02:07 |
| lifeless | there is currently transcoding required, and that can buffer pretty highly | 02:07 |
| abentley | They just did bzr branch bzr+ssh://devpad.canonical.com/code/rocketfuel/launchpad/devel trunk | 02:08 |
| abentley | I can confirm that on my box, this does tons of Graph.get_parents_map calls. | 02:09 |
| lifeless | there is a debug flag | 02:10 |
| abentley | It's doing _walk_to_common_revisions(), which looks wrong. | 02:10 |
| lifeless | it should be exponentially increasing in data retrieval | 02:11 |
| lifeless | with a cap | 02:11 |
| abentley | Many of these calls were 14k or so. | 02:13 |
| lifeless | if you do -Dhpss | 02:14 |
| lifeless | it reports hit rate and stuff | 02:14 |
| abentley | I'm reporting the results I got from doing Dhpss | 02:14 |
| abentley | There were a lot of results with 43474 bytes. | 02:15 |
| abentley | then a lot with 83598 bytes | 02:16 |
| lifeless | what was the retransmitted revisions count ? | 02:17 |
| abentley | Always 0 of x | 02:18 |
| lifeless | ok | 02:19 |
| lifeless | how many minutes did the graph traversal take ? | 02:19 |
| abentley | Dunno. I killed it before it completed. | 02:20 |
| lifeless | how many minutes in was that ? | 02:20 |
| lifeless | and what was the last hit rate you had reached ? | 02:21 |
| abentley | The time was 488.460 | 02:22 |
| abentley | The last hit rate was 98% | 02:23 |
| lifeless | what was the rtt around the last request? | 02:23 |
| lifeless | (just the tiem from sending to the hit rate output) | 02:23 |
| abentley | Looks like 0.009 | 02:24 |
| lifeless | so something doesn't add up here to me | 02:24 |
| abentley | No, you probably want from 439.611 hpss call w/body: ' to '444.812 Current RemoteRepositor' | 02:25 |
| lifeless | so 5 seconds | 02:25 |
| lifeless | 12 steps a minute | 02:25 |
| abentley | The length of the last request was 146775 bytes | 02:27 |
| lifeless | thats a pretty big upload | 02:27 |
| lifeless | so there is a tradeoff we can make | 02:28 |
| lifeless | between retransmitted revisions; network latency, and request size | 02:28 |
| abentley | I thought for initial branches we were still doing the tarball thing. Is that gone? | 02:29 |
| lifeless | yes | 02:29 |
| lifeless | we need to handle such similar cases that can't be special cased like that anyhow | 02:30 |
| abentley | But it seems like this one could be special-cased to great benefit. | 02:30 |
| spiv | abentley: there's a new method that will stream all the necessary revision data in a single request -- once it knows what revisions to ask for. | 02:31 |
| lifeless | abentley: the tarball special case nearly broke the supermirror; it was very harsh on server load | 02:31 |
| spiv | (and without the nasty 'buffer the whole response before sending' that the tarball method had) | 02:32 |
| abentley | We probably don't need to be so extreme, but I would think _walk_to_common_revisions could be done on the server side. | 02:32 |
| lifeless | abentley: improvements in this area are welcome; I think I've posted lots on the list in the past | 02:33 |
| lifeless | abentley: doing _walk_to_common_revisions on the server side is something that conceptually eludes me | 02:33 |
| abentley | So I'm wrong in thinking this is a regression? | 02:33 |
| abentley | I could have sworn it completed in tens of minutes for me. | 02:33 |
| lifeless | its not a 1.4/bzr.dev regression *if* the bulk of the delay is in the graph walk | 02:34 |
| abentley | lifeless: _walk_to_common revisions is used to determine what we need to send, right? | 02:34 |
| lifeless | abentley: what we need to request from the server yes. And it depends on our local graph | 02:34 |
| abentley | In this case, we know the local graph is empty. | 02:35 |
| lifeless | abentley: yes | 02:36 |
| lifeless | abentley: though in general we don't want to do size(repo) operations, we do have a [relatively] cheap 'len()' for the revision graph. | 02:37 |
| abentley | So in this case, we only need server-side data to know what to send. | 02:37 |
| spiv | Ok, it took just over 1000s for the graph walking for that to complete for me. | 02:37 |
| spiv | (from my laptop to London) | 02:37 |
| lifeless | yah | 02:37 |
| lifeless | this is clearly improvable | 02:38 |
| lifeless | abentley: I'm ok with us special casing the selection somewhat; I think its important though that 'bzr branch bzr+ssh://launcpad...' into an existing non-empty repo *also* be fast | 02:38 |
| abentley | Yeah, I agree. | 02:39 |
| lifeless | abentley: the current worker method that is used to fetch is 'RemoteRepository.get_data_stream_for_search' | 02:39 |
| abentley | The reason I raised it now was because it seemed plausible as a regression. I knew you'd done some work in that area. | 02:39 |
| lifeless | abentley: if I were to special case the empty repository case I would look at constructing a search by hand | 02:39 |
| lifeless | yeah, its very plausible as a regression | 02:40 |
| abentley | I'm going to see how long it takes me. | 02:40 |
| spiv | It gets to 99% relatively quickly (only two minutes). | 02:47 |
| abentley | spiv: It's at 97% for me at 417.137 | 02:48 |
| spiv | Actually, that's a slightly confusing measurement. | 02:49 |
| spiv | More interesting is that after about 90s it starts getting lots of results of only 14 bytes, rather than 10s of kB. | 02:49 |
| lifeless | spiv: I bet its running into reached parts of the graph | 02:50 |
| lifeless | spiv: this is where I ran out of time and had to switch tracks | 02:50 |
| lifeless | spiv: history shortcuts will lead to inconsistent round trips being needed to reach a node N | 02:51 |
| abentley | Is it just me, or should we be implementing a graph traversal on the server side to avoid all these get_parent_map calls? | 02:52 |
| lifeless | abentley: the get_parent_map calls are server side graph traversal | 02:53 |
| lifeless | abentley: remember that we don't have full duplex facilities | 02:53 |
| abentley | I'm seeing hpss call w/body: 'Repository.get_parent_map' | 02:53 |
| abentley | Which makes me think we're asking for a whole bunch of parents, then waiting for the result. | 02:53 |
| abentley | Then asking for more parents. Etc. | 02:54 |
| lifeless | each time we do that we recieve more data than we asked for | 02:54 |
| lifeless | the server anticipates future requests and bundles those into the response | 02:54 |
| abentley | Cool. | 02:55 |
| abentley | So that's why you expect it to increase exponentially. | 02:55 |
| lifeless | it performs a breadth first search on the server side | 02:55 |
| lifeless | and trims revisions we've already recieved | 02:55 |
| lifeless | the result is cached in the clients RemoteRepository object | 02:55 |
| abentley | But it is definitely not increasing exponentially. | 02:56 |
| lifeless | have a read of remote.py's RemoteRepository._get_parent_map | 02:56 |
| lifeless | I think I was misremembering | 02:56 |
| lifeless | I tried a half dozen strategies when doing this | 02:56 |
| lifeless | expoential increases, constnat sizes, etc | 02:56 |
| lifeless | I believe it can be improved significantly while still only exposing 'get_parents_map' to the python client code | 02:57 |
| lifeless | hmm | 03:00 |
| lifeless | exponential backoff would be good | 03:01 |
| abentley | It started stream_revisions_chunked at 1135s | 03:02 |
| lifeless | I don't know if it needs a new wire flag or not | 03:02 |
| lifeless | so 20 minutes | 03:03 |
| lifeless | I suspect the knit conversion is a performance issue tho | 03:06 |
| lifeless | we're going to be unpacking and repacking the entire history | 03:06 |
| abentley | That's not a factor for this case, is it? Rocketfuel is in pack-0.92 | 03:08 |
| lifeless | oh, it is too | 03:13 |
| lifeless | I wonder if we annotate it on the server, send it, and then strip on the client | 03:14 |
| abentley | Well, bazaar seems to be doing *something* fairly CPU-intensive. | 03:18 |
| abentley | But bazaar doesn't CTRL-\ during network ops... | 03:19 |
| lifeless | 20098 abentley 15 0 1314m 1.2g 3020 S 0 32.7 12:17.25 python | 03:19 |
| abentley | This is how long it took you to branch rocketfuel? | 03:20 |
| abentley | Oh, ps output. | 03:20 |
| lifeless | spiv: ^ sure we don't buffer anymore? | 03:20 |
| spiv | lifeless: yes | 03:21 |
| lifeless | abentley: 'top' actually | 03:21 |
| spiv | lifeless: jam recently reported that to me too | 03:21 |
| spiv | lifeless: I haven't had time to dig into it yet, but it doesn't seem to be a regression | 03:21 |
| abentley | eh? Your 'top' output has my login name? | 03:23 |
| spiv | On devpad | 03:23 |
| abentley | Oh. | 03:23 |
| lifeless | abentley: :P | 03:23 |
| abentley | lifeless: So on my side, 'top' says: | 03:24 |
| abentley | 15492 abentley 20 0 475m 346m 2816 R 79.6 34.3 11:20.95 python | 03:24 |
| * spiv -> lunch | 03:27 | |
| * mneptok takes this opportunity to pimp htop | 03:39 | |
| RAOF | Mmm, sweet htop! | 03:40 |
| mneptok | i've updated my Unix toolset from top to tail. | 03:41 |
| mneptok | (namely, to htop and inotail) ;) | 03:42 |
| RAOF | inotail? Hm, haven't seen that one :) | 03:47 |
| lifeless | really its a bug | 03:48 |
| lifeless | should be able to select() on a disk file fd | 03:48 |
| abentley | branch complete: 73m, 4.4 seconds. | 03:54 |
| abentley | rockstar_: It took me 1h, 13 minutes to branch rocketfuel. Does that jibe with your experience? | 03:58 |
| rockstar_ | I think it was closer to two hours | 03:59 |
| mlh | I was reading themail on bzr for gedit | 04:18 |
| mlh | option C - subprocess. This might solve a lot of problems -- to strongly disassociate the ui from bzrlib | 04:18 |
| mlh | you coould even haev the tui start up a bzrlib process and send it commands. | 04:19 |
| mlh | you'd have to be careful of context/environment though | 04:19 |
| mlh | as well as interop with gedit/win32 exlporer/nautilus etc it might help the perceived speed of bzr if the client is very small | 04:20 |
| mlh | it's a big task though | 04:20 |
| mlh | see http://www.martiansoftware.com/nailgun/ for a similar idea for java - in this case the client is in C | 04:21 |
| igc | bb i a few minutes | 04:43 |
| lifeless | ok, I have the new stream stuff functional | 06:16 |
| lifeless | now to eliminate join, and then optimise the stream copy | 06:16 |
| lifeless | I'm pushing up the current branch, because I'm fading now, still not entirely well I don't think | 06:17 |
| AfC | lifeless: best wishes for a speedy recovery | 06:19 |
| lifeless | AfC: thanks | 06:24 |
| johnf | If I have two totally separare bzr trees with no common ancestors is it possible to merge one into the other. | 06:25 |
| johnf | basically I have some scripts I was keeping in a different bzr branch that I want to add to the main app | 06:25 |
| spiv | Yes, "bzr merge -r0..-1 ../unrelated" | 06:25 |
| johnf | spiv: cool that worked. Thanks | 06:26 |
| lifeless | all pushed anyhow - the 'versioned_files' branch | 06:38 |
| mdke | mwhudson_: yes, I've been doing rm -rf .bzr on it overnight - on purpose | 07:48 |
| mdke | mwhudson_: I'm just pushing the upgraded branch up now (for ubuntu-hardy) | 07:49 |
| jamesh | mdke: how did the upgrade go? | 08:16 |
| mdke | jamesh: seems to have gone fine, although i've discovered now that mwhudson_ has the magic ability to do it on the serverside | 08:23 |
| mdke | https://answers.edge.launchpad.net/launchpad-bazaar/+question/30469 | 08:23 |
| jamesh | mdke: the delete-then-upgrade strategy can take a while for knit branches with a large number of files | 08:24 |
| jamesh | since you get "2*n_files + constant" round trips | 08:25 |
| mdke | jamesh: yeah, I left the delete on overnight | 08:25 |
| jamesh | sftp lets you do things more efficiently (by pipelining commands), but I don't think lftp takes advantage of that | 08:25 |
| mdke | jamesh: one thing is that it does seem to break the LP branch - when I deleted it overnight, one of the users got a bit surprised and came in here to ask about how it could be restored; so I found it restored and upgraded when i woke up :) | 08:27 |
| jamesh | mdke: were they accessing it via http or bzr+ssh? | 08:27 |
| jamesh | and did they have write access to the branch? | 08:27 |
| mdke | without realising that that had been done, I redeleted it and pushed it again | 08:27 |
| mdke | jamesh: probably bzr+ssh and yes | 08:28 |
| jamesh | mdke: then that access would have gone through to the writable area where you were deleting stuff | 08:28 |
| mdke | ah | 08:28 |
| mdke | oh well, I had posted to the mailing list to warn people | 08:29 |
| mdke | couldn't have done much more | 08:30 |
| jamesh | pack formats comprise many fewer files, so the delete takes a lot less time | 08:33 |
| jamesh | although people are usually upgrading to pack formats than from them | 08:33 |
| * mdke nods | 08:36 | |
| * igc dinner | 09:55 | |
| awilkins | Hmm, bzr:// isn't always fastest is it? | 10:11 |
| * TFKyle expects file:// would be faster personally :) | 10:12 | |
| awilkins | It is, especially into a --no-trees repo | 10:12 |
| awilkins | bzr:// transferred about 5 MB of data then the bzr process on the server starts really chewing CPU | 10:13 |
| awilkins | Mind, this is a rather large tree | 10:13 |
| ubotu | New bug: #220936 in bzr "bzr report internal error when I try to access repository under other locale then repository was created" [Undecided,New] https://launchpad.net/bugs/220936 | 10:41 |
| toojays | Hi | 11:01 |
| toojays | I'm wondering if anyone here can help me out with bug 219832. | 11:02 |
| ubotu | Launchpad bug 219832 in bzr "KnitCorrupt: corrupt: incorrect number of lines while branching from svn" [Undecided,New] https://launchpad.net/bugs/219832 | 11:02 |
| silwol | i got a problem with bzr and paramiko installed in my home directory on a server without root access for me | 11:51 |
| silwol | installed paramiko using "python setup.py install --home ~" | 11:51 |
| silwol | did the same for bzr | 11:51 |
| silwol | when I want to branch from sftp url, I get | 11:51 |
| silwol | user@server:~$ bzr branch sftp://server/path/to/branch | 11:51 |
| silwol | bzr: ERROR: Unsupported protocol for url "sftp://server/path/to/branch": Unable to import paramiko (required for sftp support): cannot import name util | 11:51 |
| silwol | anybody knows what the problem could be? | 11:51 |
| TFKyle | silwol: you might need to add where that installed paramiko to PYTHONPATH | 11:52 |
| toojays | silwol: Do you need to set PYTHONPATH maybe? | 11:52 |
| silwol | PYTHONPATH is set to ~/lib/python | 11:53 |
| silwol | without it, bzr does not even run at all | 11:53 |
| dato | silwol: and is paramiko there too? | 11:54 |
| silwol | esd07016@hssesrv01:~$ ls $PYTHONPATH | 11:54 |
| silwol | bzrlibparamiko | 11:54 |
| dato | ok | 11:54 |
| silwol | do i need pycrypto installed? | 11:57 |
| toojays | I reckon you do. | 11:58 |
| TFKyle | heh, yeah | 11:58 |
| silwol | hmmm, too bad... there is no gcc :-( | 11:58 |
| TFKyle | silwol: out of curiosity, what version of python? | 11:59 |
| silwol | .24 | 11:59 |
| silwol | 2.4 | 11:59 |
| silwol | a current rhel server | 11:59 |
| TFKyle | 'k, so that wouldn't work even if it didn't need DES (which it probably does) | 12:00 |
| TFKyle | might be able to steal someone elses binaries and hope they work :D | 12:00 |
| silwol | well, i'll create some on my local pc | 12:02 |
| silwol | hope there are no symbol problems | 12:02 |
| TFKyle | silwol: hmm, you might be able to extract the rpm for rhel (I'd assume it'd have a pycrypto package, I could be wrong though) and throw the files in ~/lib/python | 12:02 |
| === kiko-zzz is now known as kiko | ||
| silwol | TFKyle: the admin told me there is none, otherwise he would already have it installed | 12:03 |
| TFKyle | ah | 12:03 |
| TFKyle | guess gcc is too big for the admin to want to put on? | 12:04 |
| silwol | i think it's a security issue... will ask him again | 12:05 |
| silwol | thanks for your help anyway... if i run into problems again, i'll come back | 12:05 |
| * TFKyle should probably look into doing pure-py equivs of most stuff in pycrypto, too bad everyone having 2.5 can't be relied on (makes it easier for the hashing stuff, can just call hashlib.sha256/etc. for some stuff instead of having to implement it in pure-py) | 12:08 | |
| === mrevell is now known as mrevell-luncheon | ||
| === mrevell-luncheon is now known as mrevell | ||
| silwol | okay, it worked by copying pycrypto compiled on my laptop | 13:19 |
| silwol | thanks people | 13:19 |
| awilkins | This is bugging me ; I'm trying to test some mods to gconflicts ; but I'm finding it hard to make a simple tree with text conflicts in it | 13:42 |
| awilkins | http://pastebin.ca/994453 | 13:45 |
| awilkins | Can someone explain what I'm seeing in the link? I think it's incorrect behaviour personally, but perhaps there's a good reason. | 13:45 |
| awilkins | What I would expect is a text conflict, not a content conflict | 13:46 |
| james_w | so would I | 13:46 |
| james_w | does "bzr conflicts --text" list it? | 13:46 |
| awilkins | Nope | 13:48 |
| awilkins | The logs correctly note each relevant revision as a modification to stuff.txt | 13:49 |
| james_w | it seems that the file ids get mixed up then, but you're typescript suggests that they shouldn't | 13:49 |
| awilkins | The logs never note a deletion of stuff.txt, so how can a merge produce one? | 13:49 |
| awilkins | Let me try this in a non rich-root repo | 13:50 |
| awilkins | Ok, trying with standalone pack.092 branches | 13:50 |
| awilkins | Does it in plain pack.92 branches too | 13:51 |
| luks | I get a text conflict using the same steps | 13:52 |
| james_w | I can't reproduce either | 13:52 |
| james_w | awilkins: are you on up-to-date bzr.dev? | 13:52 |
| awilkins | File-ids are identical | 13:52 |
| awilkins | james_w: No, this is 1.31 | 13:52 |
| awilkins | Erm, I thought it was, it's 1.30 | 13:53 |
| james_w | awilkins: I can't reproduce with 1.3.1 either | 13:55 |
| awilkins | WHen I finish installing 1.3.1 I'll try it again | 13:55 |
| james_w | thanks | 13:57 |
| awilkins | Same again, contents conflict | 13:59 |
| awilkins | Hmm, let me try with no plugins | 13:59 |
| awilkins | Still the same with no plugins | 14:02 |
| awilkins | Is this a windows-specific thing? | 14:03 |
| james_w | could be | 14:05 |
| awilkins | I'm presently working on the theory this may be a unicode BOM thing (?!?!?!?) | 14:06 |
| awilkins | I'll try again with ANSI files | 14:06 |
| ubotu | New bug: #195217 in bzr-lpreview "ReadOnly error when running bzr review-submit with no arguments" [Undecided,New] https://launchpad.net/bugs/195217 | 14:11 |
| awilkins | Bingo ; it's because the magic function in bzr is detecting the files as binary | 14:11 |
| abentley | awilkins: Yes, it could be a unicode BOM thing. binary detection is based on finding non-ascii bytes. | 14:11 |
| abentley | Specifically 0 | 14:11 |
| abentley | i.e. the NUL bytes. | 14:11 |
| abentley | So technically ASCII, but never used in text documents. | 14:12 |
| abentley | awilkins: Your files aren't utf-16 are they? | 14:12 |
| awilkins | abentley: Yes, they are | 14:12 |
| abentley | Oh, they are binary, then. Thanks for playing. | 14:13 |
| awilkins | abentley: 'tis what you get by default as output from Powershell | 14:13 |
| awilkins | abentley: You do the same test using cmd.exe as a shell and it works fine | 14:13 |
| awilkins | Grr, the output encoding on PSH being utf-16 by default is bloody annoying | 14:18 |
| abentley | awilkins: bzr does tend to assume that files are in a bytes-based encoding. Even if I could fix it for utf-16 files, merge would act funny because it wouldn't detect newlines correctly. | 14:18 |
| awilkins | abentley: I agree that utf-16 is something of a marginal format, especially in the west | 14:18 |
| abentley | I suppose if we detected a BOM, we might be able to skip the rest of the test. | 14:20 |
| awilkins | Want a bug submitted so people can spit on it? | 14:20 |
| abentley | But that doesn't solve the problem that '\n' doesn't mean newline in utf-16 | 14:20 |
| abentley | Sure | 14:21 |
| awilkins | No, it's \n\0 with an even offset, yes? | 14:21 |
| abentley | Well, it depends on whether the UTF-16 is LE or BE. | 14:22 |
| awilkins | Would a BOM convey that, perchance | 14:23 |
| abentley | Indeed it would. | 14:24 |
| awilkins | Python seems to be pretty encoding-savvy from what I've seen of the docs - first langauge I've seen which knows which encoding your source file is | 14:24 |
| abentley | It's definitely much better than older languages like C, but Python 3.0 will really get it right. | 14:26 |
| sssslang | hi could some can told me how to make bzr didn't complain differences between same dos and unix files(about the EOL). | 14:52 |
| ubotu | New bug: #221021 in bzr "bzr send should write to a remote file when --output file provided" [Undecided,New] https://launchpad.net/bugs/221021 | 14:57 |
| === mw|out is now known as mw | ||
| ubotu | New bug: #221031 in bzr "switching between checkout and branch causes abandoned lock" [Undecided,New] https://launchpad.net/bugs/221031 | 15:26 |
| jam | morning all | 15:30 |
| Odd_Bloke | jam: o/ | 15:31 |
| jelmer | jam, Odd_Bloke: dudes! | 15:31 |
| Odd_Bloke | Sweet. | 15:32 |
| james_w | hi all | 15:34 |
| james_w | Installer testing is fun! | 15:34 |
| james_w | jam: how was your holiday? | 15:35 |
| awilkins | Who do I mail merges for gtk plugin to? | 15:39 |
| Odd_Bloke | jelmer: ^ | 15:39 |
| * awilkins is poised to mail jelmer | 15:40 | |
| james_w | there's a list isn't there? | 15:40 |
| awilkins | https://launchpad.net/~bzr-gtk | 15:41 |
| Odd_Bloke | I think so, but jelmer probably knows the details. :p | 15:41 |
| jelmer | awilkins: bzr-gtk@lists.canonical.com | 15:41 |
| TFKyle | could also just ping him here :) | 15:41 |
| * jelmer is here, but behind a very laggy sattelite connection from the UK | 15:41 | |
| Odd_Bloke | jelmer: Whereabouts are you? | 15:41 |
| awilkins | Jelmer is team owner, but no contact details listed. Isn't there a "default place to mail stuff" field for this | 15:41 |
| jelmer | Odd_Bloke: in a train somewhere near Wakefield | 15:42 |
| jelmer | awilkins: yes, bzr-gtk@lists.canonical.com :-) | 15:42 |
| awilkins | Sent, just a small patch to improve the external conflict util starter | 15:43 |
| Odd_Bloke | jelmer: Oh, cool. What brings you to the UK? | 15:43 |
| * awilkins muses that it can't be anything you could get in Amsterdam | 15:43 | |
| jelmer | Odd_Bloke: visiting a company here that's doing some samba-related stuff | 15:44 |
| Odd_Bloke | jelmer: Cool. | 15:44 |
| jelmer | awilkins: hunting would be something that's allowed in the uk but not in .nl I think :-) | 15:44 |
| TFKyle | speaking of bzr-gtk, any way to make visualize default to showing the date column? (in current trunk) | 15:45 |
| === kiko is now known as kiko-afk | ||
| jelmer | it should just remember whether or not you have that column enabled | 15:47 |
| TFKyle | doesn't seem to here, where's it normally store that? | 15:47 |
| awilkins | TFKyle: Seems to store it in the global bzr config (or try) | 15:53 |
| jam | james_w: my holiday went quite well, though it was a bit longer than I usually prefer | 15:54 |
| TFKyle | awilkins: ah | 15:55 |
| james_w | jam: better longer than shorter :-) | 15:55 |
| awilkins | TFKyle: It stores it properly, but it doesn't seem to work here | 15:55 |
| TFKyle | seems to be there (under the DEFAULT section), just not getting it back properly, I'll have a look at the code | 15:55 |
| awilkins | Bug in the property settings | 15:57 |
| awilkins | fixx0red | 15:58 |
| awilkins | Want a merge bundle? | 15:59 |
| TFKyle | mm, indeed | 15:59 |
| TFKyle | sure | 15:59 |
| awilkins | /msg me your email addy | 15:59 |
| TFKyle | thanks | 16:02 |
| jam | james_w: it seems Thunderbird + Lightning + Gmail is capable of locking my machine hard when it goes to alert me about missed events | 16:07 |
| jam | james_w: anyway, 2 shorter vacations is better than 1 longer one (for me at least) | 16:07 |
| james_w | jam: are you using compiz? | 16:07 |
| jam | I had to get a bit creative with holidays to string together 3-weeks uninterrupted | 16:07 |
| jam | james_w: yes | 16:07 |
| james_w | jam: hardy? | 16:07 |
| jam | yep | 16:08 |
| james_w | check you have the latest compiz-fusion-plugins-main installed | 16:08 |
| jam | Well, there are 2 issues | 16:08 |
| james_w | it sounds like exactly the problem I was having that I found the fix for this morning. | 16:08 |
| jam | 1 is that I get a quick "beep beep beep" for 3 alerts | 16:08 |
| jam | and then it freezes | 16:09 |
| jam | 2 is that it has lightning, but not 'provider for google calendar' which means I can't *modify* any of those alerts | 16:09 |
| jam | I'll make sure to update, though | 16:09 |
| jam | thanks for the heads up | 16:09 |
| james_w | hmm, maybe it's different then. | 16:09 |
| jam | james_w: "apt-get update && apt-get upgrade" is asking to install 123MB of stuff | 16:11 |
| jam | so something is being updated :) | 16:11 |
| jam | compiz-fusion-plugins-main is in that list | 16:11 |
| * james_w crosses his fingers | 16:11 | |
| jam | well, for now I've uninstalled lightning-extension, but I might bring it back | 16:11 |
| jam | If I had "provider" I could at least silence the alarms for now, and get back to work | 16:12 |
| jam | but without it, it prompts me every 5 minutes or so | 16:12 |
| jam | which doesn't give a lot of uptime | 16:12 |
| awilkins | hmm, Hardy RTW is out today, no? | 16:12 |
| jam | I thought it was today or tomorrow | 16:12 |
| awilkins | 01 days to to go | 16:12 |
| awilkins | What timezone is Ubuntu Central? | 16:13 |
| jam | Probably UTC | 16:13 |
| jam | or maybe UTC +1 | 16:13 |
| jam | London, IIRC, is UTC + 1 | 16:13 |
| awilkins | London? | 16:13 |
| awilkins | UTC +1 this time of year | 16:13 |
| james_w | it will probably be about 24 hours from now. | 16:14 |
| awilkins | I've not tried it out yet | 16:15 |
| awilkins | I'll have to download it twice, 32 bit for wifetop and thumb, 64 for desktop | 16:16 |
| awilkins | Do you advise a ditribution upgrade or a reinstall? | 16:24 |
| awilkins | (ok, ok, this isn't #ubuntu) | 16:24 |
| ubotu | New bug: #221060 in bzr "Cannot branch Python onto launchpad" [Undecided,New] https://launchpad.net/bugs/221060 | 16:25 |
| james_w | awilkins: dist-upgrade should be fine, are you on gutsy? | 16:25 |
| awilkins | james_w: Yup, gutsy on the wifetop and desktop | 16:26 |
| awilkins | james_w: Will that really reduce the download size any though :-P | 16:26 |
| james_w | no, it's going to be comparable either way. | 16:26 |
| stianse | hi guys, I have a problem on windows bazaar verson 1.3.1. When I try to run "bzr stat" or "bzr commit" I get "bzr: ERROR: [Errno 13] Permission denied". Anybody knows what's wrong? | 16:27 |
| james_w | it would only be if you were concerned about getting a "clean" experience. | 16:27 |
| james_w | stianse: what version of windows? | 16:27 |
| awilkins | james_w: I only just bleached the thing clean after installing horrible Samsung printer drivers | 16:27 |
| awilkins | They mess with your privs | 16:27 |
| stianse | james_w: windows xp | 16:27 |
| james_w | stianse: I think it might be something to with locking. I can't remember the details though I'm afraid. | 16:28 |
| awilkins | Blech, my new co worker has terrible halitosis | 16:29 |
| stianse | james_w: ok. what I've done so far is pretty basic. running init, add, commit and push to a sentalized server. using branch to get a local branch. aplied some changes. And now I'm trying to commit these locally. | 16:30 |
| === kiko-afk is now known as kiko | ||
| awilkins | stianse: Is your local branch a checkout or a standalone branch? | 16:30 |
| james_w | hmm, odd that it is failing now | 16:31 |
| james_w | stianse: can you run with "-Derror" and pastebin the result. | 16:31 |
| james_w | stianse: as in "bzr -Derror st" | 16:32 |
| stianse | awilkins: I used the branch commmand, so I would say a branch? (I'm more experienced in the subversion-world, but trying to convert :-) | 16:32 |
| awilkins | stianse: Have you used a bzr bind command at all? | 16:33 |
| stianse | awilkins: no, no bind command | 16:34 |
| stianse | should I? | 16:35 |
| stianse | awilkins: http://pastebin.com/m92ff482 | 16:35 |
| awilkins | stianse: Only if you want it to automatically push changes to the server | 16:35 |
| james_w | stianse: are there any read only files in your tree? | 16:35 |
| stianse | no, I don't want that. it's pretty experimental code i'm working on. don't want to push until it's more stable | 16:35 |
| james_w | stianse: are you familiar with the python debugger at all? | 16:36 |
| stianse | james_w: no, sorry. more a c-guy ;) but I have a guy in my office that probably is. but it would have to wait until tomorrow I guess | 16:37 |
| awilkins | stianse: Do you have any of the files in the tree open in a process that is demanding an exclusive lock? | 16:37 |
| awilkins | stianse: Your error is occuring in a routine that just calculates a hash of the file, so it's not writing to a file | 16:38 |
| stianse | awilkins: of course, why didn't i think of that! just wait a second and i'll try one more time | 16:38 |
| awilkins | stianse: A resource file, possibly? Source files are usually not locked up like this by the IDE. | 16:39 |
| stianse | awilkins, james_w: thanks for your help, it works now | 16:39 |
| stianse | well, you don't know with visual studio :-) | 16:39 |
| stianse | perhaps i should just stick to emacs | 16:40 |
| awilkins | Never had that specific problem with VS. | 16:40 |
| awilkins | It's a shame the stack dump doesn't dump parameter values | 16:40 |
| stianse | ok, I'll try to investigate what the exact problem is if I ever experience it again | 16:41 |
| james_w | yup | 16:41 |
| stianse | see you later, gotta go eating dinner. thanks again! | 16:41 |
| awilkins | stianse: You might want to shove a quick catch clause into sha_file_by_name to plop the filename to the console. | 16:41 |
| awilkins | james_w: Would it be possible to make the stack dump show parameter values? | 16:43 |
| * awilkins knows not enough about Python | 16:44 | |
| james_w | I'm not sure, but it would be good if it did. | 16:44 |
| james_w | you could probably write an alternative dumper that did it. | 16:44 |
| awilkins | I mean, you have all this funky access to functions as objects and stuff..... | 16:44 |
| === kiko is now known as kiko-fud | ||
| abentley | awilkins: When you submit patches, a brief description of what the patch does is greatly appreciated. | 17:12 |
| Vadi | I did a bzr ignore with a pattern, and it said this: "Warning: the following files are version controlled and match your ignore pattern:". Did it unignore those files too? Or they're still in bzr? | 17:26 |
| abentley | They're still in bzr. | 17:28 |
| abentley | Files are only removed from bzr if you delete them or run "bzr remove". | 17:28 |
| === BasicMac_ is now known as BasicOSX | ||
| Vadi | Okay thanks | 17:49 |
| === Ursus is now known as Noia | ||
| === kiko-fud is now known as kiko | ||
| mathrick | ho-humm | 18:29 |
| mathrick | I need some conceptual help | 18:29 |
| mathrick | I need to do the following: | 18:30 |
| mathrick | I have two machines, one with fast link, but no external IP (so only accessible when I'm home), and another which has external IP, but is very slow to connect to | 18:30 |
| mathrick | so far I've been using a checkout off the slow machine | 18:31 |
| mathrick | but I'd like to only bind it to it when I'm not home, and otherwise bind to a branch of the repo on the fast machine | 18:32 |
| mathrick | and run a cronjob to sync from fast to slow periodically | 18:32 |
| mathrick | I can do that, but the problem I've run into is when conflicts arise | 18:33 |
| mathrick | it seems that neither checkouts, nor branches from a repo will tell me that the bound location / parent branch is conflicted if that happens | 18:34 |
| mathrick | what would be the best way to run what I want then, in a way that would allow me to reliably and no-brainerly catch any conflicts? | 18:34 |
| mathrick | conflicts as in there's another dev on my team, who can access both fast and slow repos independently from me | 18:35 |
| mathrick | so if we commit conflicting changes to separate repos, things break down, since the conflict isn't reported anywhere besides the sync cronjob run on the fast machine | 18:36 |
| jam | mathrick: branches can't be conflicted, only working trees, so I'm a little curious how you are getting conflicts | 18:45 |
| jam | I suppose it depends how you are doing the sync | 18:46 |
| jam | if you are just using "pull" then the cron script will probably be raising "DivergedBranches" | 18:46 |
| mathrick | jam: yeah | 18:46 |
| mathrick | but the thing is, I wont see from my checkout that there are unmerged revisions | 18:47 |
| mathrick | ie. I won't notice the trees being out of sync unless I specifically look for that | 18:47 |
| jam | mathrick: you could always keep an extra branch, which you could check | 18:47 |
| jam | so you would have: | 18:47 |
| jam | sftp://slow-host/repo/{mainline,fast-tip,slow-tip} | 18:48 |
| jam | And then the fast-tip is always a 'pull --overwrite' of the one on fast, and 'slow-tip' is "official" | 18:48 |
| jam | and you try to keep "mainline" at the same tip | 18:48 |
| jam | when it fails, you'll still have the others to see that they aren't the same | 18:48 |
| mathrick | æh, I got lost | 18:48 |
| mathrick | <jam> and you try to keep "mainline" at the same tip <-- here | 18:49 |
| jam | mathrick: when you are at home, you bind to "sftp://fast-host/fast-tip" | 18:49 |
| mathrick | yep | 18:49 |
| jam | your cron job tries to sync that to "sftp://slow-host/mainline" and always syncs it to "sftp://slow-host/fast-tip" with --overwrite | 18:49 |
| jam | if it succeeds as syncing it to slow-host/mainline it also overwrites slow-host/slow-tip | 18:50 |
| jam | then when you are away from home | 18:50 |
| jam | you bind to sftp://slow-host/slow-tip | 18:50 |
| jam | and your cron job tries to sync that to "sftp://fast-host/mainline", "sftp://fast-host/slow-tip" etc. | 18:50 |
| jam | it's a little bit messy, but would mean you can check when you are out of date, etc. | 18:50 |
| jam | I think I can simplify it a bit | 18:51 |
| jam | give me a sec to think | 18:51 |
| mathrick | jam: okay, and would I get any indicator when I try to commit and the branches have diverged? | 18:51 |
| mathrick | commit from my laptop that is | 18:51 |
| jam | mathrick: not at commit time, no | 18:51 |
| jam | you would have to check | 18:51 |
| jam | though you could add a 'pre-commit' hook that could check for you | 18:51 |
| mathrick | that's precisely the problem I have with my current setu[ | 18:51 |
| mathrick | it doesn't blow up when the trees have diverged | 18:51 |
| mathrick | I guess | 18:52 |
| jam | mathrick: well, you have another problem which is that you have no way of *detecting* that the branches have diverged | 18:52 |
| jam | I'm trying to solve the ability to detect it first | 18:52 |
| mathrick | ah | 18:52 |
| jam | and then work on doing the detection at commit time | 18:52 |
| jam | mathrick: wouldn't your cron job alert you that the branches have diverged? | 18:53 |
| mathrick | jam: okay, so lemme know if you work out a simpler version (or decide it can't be done) | 18:53 |
| jam | mathrick: as in, send you an email because it couldn't finish the 'pull'? | 18:53 |
| mathrick | jam: yes, I began building status notification into it, but then during testing I discovered that the checkouts continue happily | 18:54 |
| mathrick | so instead of just having a "lesse why it failed status page", I need something to make it fail to begin with | 18:54 |
| jam | mathrick: well, if you always did 'push --overwrite' it would probably start to complain | 18:54 |
| jam | then the push would always succeed | 18:55 |
| jam | but you would have to be careful to save the other branch's tip so you could merge it | 18:55 |
| jam | maybe that is better | 18:55 |
| mathrick | but --overwrite is destructive in the face of a conflict, no? | 18:55 |
| jam | I think you are slightly misunderstanding conflicts versus the revision DAG | 18:56 |
| mathrick | possibly | 18:56 |
| jam | *committed* revisions cannot have conflicts, they just have a graph | 18:56 |
| mathrick | yes | 18:56 |
| jam | It is possible for 2 branches to be at different tips | 18:56 |
| jam | so we refuse to allow you to 'push' so you don't lose one of the tips | 18:56 |
| jam | mathrick: anyway, I think I've worked something out, give me a sec | 18:57 |
| fullermd | You probably mean 'divergeance', not 'conflict'. | 18:57 |
| mathrick | most probably | 18:57 |
| jam | mathrick: http://rafb.net/p/0tvWF366.html | 19:02 |
| jam | ^^- Use that as the cron script on fast host | 19:03 |
| jam | It won't tell you on 'fasthost' when you are out of sync, but I can fix that. | 19:03 |
| jam | mathrick: http://rafb.net/p/BziHfX38.html | 19:07 |
| jam | Basically, when it sees the branches are out of sync, it swaps them | 19:08 |
| jam | so that your checkout will complain | 19:08 |
| jam | The only time it will succeed accidentally | 19:08 |
| jam | is if you had the branches out of sync | 19:08 |
| jam | and then you switch positions at the same time the cron script runs | 19:08 |
| jam | oh, and I guess this will eternally swap the branches, so I guess there is a 50/50 chance of it swapping it back | 19:09 |
| jam | You could stop that by remembering the last successful push/pull and stop if that hasn't changed. | 19:09 |
| mathrick | jam: lemme look at it | 19:14 |
| mathrick | jam: okay, so I take it that the latter paste replaces the former one? | 19:21 |
| jam | mathrick: it is a different way to do it, but generally yes | 19:21 |
| mathrick | ok | 19:22 |
| mathrick | jam: so, what it does is that when I have my branch bound to, say, fast-tip, and the branches diverged, what I'd be actually acessing is the mainline, which will trip over my commit because it won't see what it expected? | 19:23 |
| jam | mathrick: right | 19:23 |
| mathrick | jam: and it doesn't actually matter which is where, as long as they are swapped when they diverge, and not otherwise, right? | 19:24 |
| jam | mathrick: correct | 19:24 |
| mathrick | I guess that swapping not diverged branches is a no-op anyway | 19:25 |
| === mw is now known as mw|lunch | ||
| vila | hi all | 19:38 |
| awilkins | james_w: I wrote that argument dumping code, it isn't too horrible | 19:38 |
| vila | abentley: bb down it seems | 19:38 |
| abentley | vila: restarted. Try again in a minute. | 19:39 |
| vila | abentley: thks | 19:39 |
| beuno | vila, \o/ | 19:40 |
| vila | beuno: :) | 19:40 |
| beuno | vila, kitchen fixed up? | 19:40 |
| vila | I thought I will never come back, RL really sucked my free time | 19:40 |
| vila | kitchen is "usable", not finished, but enough to get some free time back :) | 19:41 |
| abentley | vila: kitchen beta | 19:41 |
| vila | and we are very happy with the result with *is* the point ;-) | 19:41 |
| vila | abentley: exactly, thanks :) | 19:41 |
| vila | hopefully that didn't apply to food ;) | 19:42 |
| beuno | vila, I'm glad. Good to see you back | 19:43 |
| vila | beuno: just cooking a new selftest option and I get a shot at bzr-upload ;) | 19:43 |
| beuno | vila, yay! | 19:44 |
| mathrick | jam: uh, I got a bit lost trying to bolt on the halting code | 19:47 |
| mathrick | jam: would recording the current (swapped) tip in case they diverged be a good idea? | 19:47 |
| mathrick | hmm, no, you could still commit onto it I think | 19:48 |
| mathrick | damn, I can't find any bit of state that could be persisted and also reliably recovered from only inspecting the branches in case of divergence | 19:49 |
| mathrick | oh, the latest common parent | 19:53 |
| mathrick | or whatever it is called in bzr parlance | 19:53 |
| * mathrick hits the docs | 19:53 | |
| mathrick | uh-oh | 19:54 |
| mathrick | http://starship.python.net/crew/mwh/bzrlibapi/ is down | 19:54 |
| abentley | mathrick: Are you trying to determine whether branches have diverged? | 19:55 |
| mathrick | abentley: no, I want to swap them once and only once per divergence | 19:56 |
| mathrick | abentley: I don't know if you have read my original problem and what jam said about the solution | 19:56 |
| abentley | I glanced over it. | 19:56 |
| abentley | It didn't make much sense to me, so I went back to what I was doing. | 19:57 |
| jam | mathrick: common ancestor is what we generally call it | 19:58 |
| jam | branch.repository.get_graph(other_branch.repository).find_unique_lca(branch.last_revision(), other_branch.last_revision()) | 19:58 |
| moquist | is there a good way to change a checkout into just a branch, so commits are local? | 20:02 |
| mathrick | moquist: bzr unbind | 20:03 |
| moquist | mathrick: thanks...apparently I should really just read through the whole man page, shouldn't I? :\ | 20:04 |
| mathrick | probably :) | 20:04 |
| abentley | also, "bzr reconfigure --tree" | 20:05 |
| mathrick | moquist: bzr help checkouts explains it in detail | 20:05 |
| moquist | abentley: right; I remember that being a very helpful read, though I apparently didn't catch/grok everything last time. I'll try again. | 20:07 |
| moquist | thx, mathrick and abentley. | 20:07 |
| ChristopheT | When doing a "bzr status" after a merge, is it possible to see the full log lines of the merged repository? | 20:10 |
| ubotu | New bug: #221139 in bzr-svn "bzr-svn won't remember the password." [Undecided,New] https://launchpad.net/bugs/221139 | 20:11 |
| === mw|lunch is now known as mw | ||
| abentley | ChristopheT: Not directly. You could always commit and then run log. | 20:26 |
| fullermd | I've thought from time to time that `status --show-ids` should show the revids of pending merge revs.. | 20:30 |
| mathrick | jam: awesome, it works | 20:46 |
| mathrick | jam: and bzr up + bzr resolve do what I mean | 20:47 |
| mathrick | which is sweet | 20:47 |
| mathrick | well, with the exception of spurious conflicts like: Conflict adding file file.txt.BASE. Moved existing file to file.txt.BASE.moved. | 20:48 |
| mathrick | but I can live with it | 20:48 |
| === kiko is now known as kiko-afk | ||
| korpios | Is there a straightforward way to "collapse" several revisions into a single revision? e.g., say I just committed revs 33-39, and I'd like to change the repository so that all those changes are only in a single revision 33 | 21:21 |
| jam | korpios: 2 ways to do it, but the common one is "bzr uncommit -r 33; bzr commit -m 'new 333'" | 21:22 |
| abentley | (actually, uncommit -r 32) | 21:23 |
| jam | abentley: right, uncommit jumps you *to* that revision | 21:23 |
| jam | (it used to uncommit that revision) | 21:23 |
| korpios | so uncommit doesn't touch the WC, it only alters the repository? | 21:23 |
| jam | korpios: it leaves the working tree unchanged, just changes the branch pointer | 21:23 |
| jam | (it doesn't remove revisions from the repository either, they just won't propagate out if they aren't referenced) | 21:24 |
| korpios | will a recommit then pick up on moves that happened in the revisions you just jumped back from? | 21:24 |
| jam | korpios: yes | 21:24 |
| korpios | ah, nice | 21:24 |
| jam | It also remembers merges you did, etc | 21:24 |
| korpios | that makes me happy ^_^ | 21:25 |
| jam | It is *supposed* to be like you did all the work, and just didn't "bzr commit", if you find discrepancies, let us know | 21:25 |
| jam | I don't know of any, off hand | 21:25 |
| jam | oh, except if you repeatedly merge the same branch, it doesn't prune the ancestry | 21:26 |
| jam | not sure if that is a big issue | 21:26 |
| korpios | as long as it's sane enough to work with, that's the key :) | 21:27 |
| mtaylor | hey guys - any sensible way to get a list of all files under bzr control? like bzr status, except I want to also see unchanged files, and I don't care about status? | 21:43 |
| beuno | mtaylor, inventory gives you all the files that are versioned | 21:44 |
| mtaylor | beuno: thanks. duh | 21:44 |
| beuno | :) | 21:44 |
| mtaylor | beuno: how come inventory doesn't show up in bzr help commands ? | 21:46 |
| beuno | mtaylor, I don't think it's used very often | 21:46 |
| * mtaylor grimaces | 21:47 | |
| jam | bbiab | 21:49 |
| lifeless | moin | 21:59 |
| beuno | mornin lifeless' how are you feeling today? | 22:01 |
| abentley | mtaylor: any functionality that is unique to "inventory" should be added to "ls". | 22:24 |
| mtaylor | ahhhh | 22:27 |
| beuno | abentley, so inventory is being deprecated in favour of ls? | 22:28 |
| abentley | beuno: inventory's a hidden command. That's as deprecated as commands get. | 22:29 |
| beuno | abentley, ah, I had no idea :) | 22:29 |
| mtaylor | abentley: bzr ls makes me happy | 22:29 |
| * beuno updates his mental DB | 22:29 | |
| === mwhudson_ is now known as mwhudson | ||
| mtaylor | bzr: ERROR: pycurl.error: (60, 'SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed') | 22:36 |
| mtaylor | is there a way to tell bzr that self-signed "invalid" ssl certs on https repositories are ok? | 22:36 |
| abentley | You can use urllib+https: to bypass cert checking. | 22:43 |
| mtaylor | abentley: cool. know of any plans to maybe catch that exception and ask a question? | 22:44 |
| mtaylor | abentley: I know another friend of mine was having this problem branching from a https svn repos with a self-signed-cert the other day | 22:45 |
| abentley | mtaylor: Not as far as I know. | 22:45 |
| mtaylor | ok | 22:45 |
| * mtaylor supposes that means it's time for loud complaining! :) | 22:46 | |
| abentley | You're unlikely to actually get a solution that requires user interaction. | 22:46 |
| mtaylor | abentley: bzr: ERROR: Unsupported protocol for url "urllib+https://code.launchpad.net/~sward-dev/bzr-difftools/trunk" | 22:47 |
| thebolt | i'm also having that very same problem right now ;) | 22:47 |
| thebolt | and svn+https://YYY gives "Not a branch: YYY" | 22:47 |
| mtaylor | so, that url works for me on my linux box, (https://code.launchpad.net/~sward-dev/bzr-difftools/trunk - withouth urllib) | 22:48 |
| mtaylor | but does not work for one of our devs on a windows box | 22:48 |
| abentley | Sorry, should be "https+urllib", not the reverse. | 22:48 |
| mtaylor | perhaps there is a python lib he's missing? | 22:48 |
| thebolt | i'm also using windows btw.. | 22:48 |
| mtaylor | abentley: https+urllib worked | 22:50 |
| meuserj | I can't quite figure out how to do something with bzr: | 22:52 |
| meuserj | I have a merge that I want to remove from the history... found later that it broke the program | 22:52 |
| meuserj | I did "bzr revert 13..14" | 22:53 |
| meuserj | and status reports that the merge is pending | 22:53 |
| meuserj | errr... make that "bzr merge 13..14" | 22:54 |
| abentley | You've got the numbers in the wrong order. That applies the change again. | 22:54 |
| meuserj | but the affected files haven't been reverted | 22:54 |
| abentley | You want bzr merge -r 14..13 . | 22:54 |
| meuserj | ah.. ok | 22:55 |
| abentley | You should probably do revert --forget-merges, too. | 22:57 |
| thebolt | hm, whenever i try to branch or checkout a subversion repository over https i get bzr: ERROR: Not a branch: "svn+https://crystal.svn.sourceforge.net/svnroot/crystal/CS". (both bzr 1.4.x on linux and 1.3.1 on windows), any ideas why? same repository over http goes perfectly fine | 23:07 |
| jelmer | thebolt: see the FAQ | 23:07 |
| thebolt | jelmer: which of them? ;) | 23:08 |
| jelmer | the 2nd | 23:08 |
| thebolt | i think i have read them all (ie both bazaar and bzr-svn) | 23:08 |
| jelmer | this is a self-signed ssl certificate? | 23:08 |
| thebolt | no | 23:09 |
| thebolt | (its sourceforge, the CA is equifax) | 23:09 |
| * jelmer tries | 23:12 | |
| thebolt | hmm, seems even though firefox (&ie) trusts the CA, svn and bzr doesn't.. | 23:12 |
| jelmer | that'd certainly explain it | 23:14 |
| thebolt | but then the error message isn't really descriptive ;) (and the guides you do find online for checking if the certificate is trusted doesn't include this case where some consider it trusted & other doesn't ;) | 23:15 |
| jelmer | thebolt: see the answer in the faq.. this is a python-subversion bug | 23:16 |
| thebolt | anyhow, while i'm at it, i've just (as you realize;) started to play around with bzr, at first to use it as a local vcs on top of our projects central svn repository, but possibly in the long term do a more total conversion | 23:16 |
| thebolt | well, which faq? neither http://samba.org/~jelmer/bzr-svn/FAQ.html nor http://bazaar-vcs.org/FAQ (which are the only two faqs i find links to) lists that error | 23:17 |
| thebolt | so my question would be if there's some described "best practices" when using bazaar on top of svn? something i definitly shouldn't do, and something tahts good? ; | 23:17 |
| jelmer | the one in the source | 23:18 |
| jelmer | basicaally the second one on http://samba.org/~jelmer/bzr-svn/FAQ.html | 23:18 |
| thebolt | well, the repo doesn't require name+password | 23:18 |
| jelmer | although the question now includes untrusted ssl certificates as well | 23:18 |
| thebolt | not in the version i have.. but i guess thats related to me using the windows installer to get the plugin | 23:19 |
| jelmer | it may only be in the 0.4 branch atm | 23:19 |
| thebolt | heh ok, then don't be too mad at me for not reading it.. i did try to RTFM :) | 23:19 |
| jelmer | there is no best practices document at the moment, but I'd be happy to review if anybody decides to write one :-) | 23:20 |
| thebolt | heh ok | 23:21 |
| thebolt | the guides i find use branch or checkout to mirror a single directory at a time (such as the trunk), is there a way (or any good reason not to) mirror an entire repository? | 23:21 |
| jelmer | yes, "bzr svn-import" | 23:22 |
| thebolt | but that does a conversion, doesn't it? ie not connected to the central repository? | 23:22 |
| jelmer | not sure I understand what you mean | 23:24 |
| jelmer | it does the same thing as "bzr branch" but for all branches in a svn repository | 23:24 |
| jelmer | there's no way to do imports without connecting to a central svn repository | 23:25 |
| thebolt | i mean the difference between branch and checkout.. but i guess i can do "bind" on them after svn-import to make them mirror-branches | 23:25 |
| jelmer | thebolt: the difference between branch and checkout is the same as without bzr-svn involved | 23:26 |
| thebolt | yea, i understand that | 23:27 |
| thebolt | but i want the effect of checkout but for the entire repo (&with svn ;) | 23:27 |
| thebolt | unless there is a good reason not to | 23:27 |
| jelmer | so you want the entire repo as one bzr branch? | 23:33 |
| thebolt | no, my goal would be to have a bzr "repo" with all the different branches from svn as different bzr branches, on which i could then continue to base my local (and later published) branches.. now if this sounds totally stupid say so.. (this is why i asked for a best-practices document ;) | 23:36 |
| thebolt | part of my current work is basically merging of five different branches into one (and includes some fixing of stuff where they touch the same areas ;) | 23:37 |
| jelmer | thebolt: yes, that's what "bzr svn-import" does basically | 23:42 |
| thebolt | ok | 23:42 |
| thebolt | thanks. .damn i'm not used to being such a newbie at the tools i (try) to use ;) | 23:43 |
| igc | morning | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!