| emmajane | poolie, ping? | 00:08 |
|---|---|---|
| poolie | emmajane: hi | 00:10 |
| poolie | nice to see you | 00:10 |
| emmajane | poolie, and you as well. :) | 00:10 |
| poolie | are you in the UK and up really late? | 00:10 |
| emmajane | have you got a few minutse? | 00:10 |
| poolie | sure | 00:11 |
| emmajane | Indeed. It's gone midnight here. | 00:11 |
| poolie | just give me 2m here first though.. biab | 00:11 |
| emmajane | np | 00:11 |
| igc | morning | 00:25 |
| KeBugCheckEx | I need a better progress info for bzr branch | 00:41 |
| KeBugCheckEx | Event if I need to develop a plugin or use the bzr API | 00:41 |
| KeBugCheckEx | bzr checkout -v is not enough, it's sens stalled for long time | 00:41 |
| KeBugCheckEx | Anyone knows if it's possible? | 00:42 |
| poolie | spiv, hi, i have a call with francis in a bit | 00:57 |
| poolie | KeBugCheckEx: is this as a user of the command line or from your own program (ie at the api level) | 00:57 |
| KeBugCheckEx | poolie: I'll do it at the api level | 00:59 |
| poolie | KeBugCheckEx: so there are two layers: events fired from the core code to the uifactory | 00:59 |
| poolie | you can hook into that if you're eg using bzrlib in a gui or daemon | 00:59 |
| === zirpu2 is now known as zirpu | ||
| poolie | and then if the core code is not sending enough progress events, i guess file a ubg | 01:00 |
| poolie | try using the breaking debugger (Ctrl-\ or Ctrl-Break) to see where it's spending time and not repotring it | 01:00 |
| poolie | for curiousity, what is the app you're doing this from, and on what platform? | 01:00 |
| KeBugCheckEx | poolie: I downloaded Bzr Explorer for Windows, it shows the same progress the bzr command does | 01:00 |
| KeBugCheckEx | lots of time in "Fetching revisions:Inserting stream" | 01:01 |
| poolie | nice nick btw | 01:02 |
| KeBugCheckEx | I'm testing on Windows XP and Ubuntu Server, bzr 1.17 | 01:02 |
| poolie | this is over the network? | 01:02 |
| KeBugCheckEx | testing with bzr branch -v http://bazaar-vcs.org/bzr/bzr.dev bzr.dev | 01:02 |
| poolie | KeBugCheckEx: on the command line you should get a network progress indicator? | 01:04 |
| KeBugCheckEx | Maybe it's to early to ask questions since I didn't study the api enough, but I didn't find any tool with a decent progress report | 01:04 |
| poolie | it may be that bzr explorer doesn't expose that | 01:04 |
| KeBugCheckEx | It shows the progress, but looks like it doesn't know how much is left to be downloaded | 01:04 |
| poolie | like this: http://www.ubuntu-pics.de/bild/24166/screenshot_20090909_09_37_17_rjPOI4.png | 01:05 |
| poolie | blah | 01:05 |
| poolie | not that | 01:05 |
| poolie | this: [#########| ] 2KB 0KB/s | Fetching revisions:Inserting stream | 01:05 |
| poolie | showing the network rate | 01:05 |
| KeBugCheckEx | bzr and bzr-explorer just show the bytes dowloaded but not how much there's left | 01:05 |
| KeBugCheckEx | the tool I'll develop will need to show how much MBs is left | 01:06 |
| poolie | ok | 01:06 |
| poolie | what tool is that? | 01:06 |
| KeBugCheckEx | I'll create a tool for non technical people based on bzr | 01:06 |
| KeBugCheckEx | open source of course :0( | 01:07 |
| KeBugCheckEx | :-) | 01:07 |
| KeBugCheckEx | but the repositories will be big | 01:07 |
| KeBugCheckEx | maybe gigas | 01:07 |
| poolie | ok | 01:07 |
| KeBugCheckEx | it's very important to show the user how much time is left | 01:07 |
| poolie | our current setup is to have the server stream out data as it works through history | 01:08 |
| poolie | so it doesn't necessarily know up front how much data it will send | 01:08 |
| poolie | however, we could probably give at least some estimate | 01:08 |
| poolie | of how many more revisions need to be copied | 01:08 |
| poolie | if you look at eg 'bzr check' it does i think show how many objects will be checked | 01:08 |
| poolie | so you get proportional overall progress | 01:08 |
| KeBugCheckEx | let me try the checkout... | 01:09 |
| poolie | if you hook in at that level, when the core is updated, your ui will be told | 01:09 |
| KeBugCheckEx | bzr checkout -v --lightweight looks better | 01:12 |
| KeBugCheckEx | Build phase:Adding file contents 533/1105 | 01:12 |
| KeBugCheckEx | I'm assuming 1105 is the number of files to download | 01:13 |
| KeBugCheckEx | can I copy a branch from a machine to another? copy the files? | 01:13 |
| KeBugCheckEx | creating a branch in /tmp, zipping and then sending it via http is a viable alternative for me | 01:14 |
| poolie | KeBugCheckEx: yes, that will work | 01:31 |
| poolie | 1105 is the number of files in the working copy | 01:31 |
| poolie | you should get that output from any command that creates a tree | 01:31 |
| poolie | spiv, hello? | 01:31 |
| KeBugCheckEx | So, if I ensure nobody is changing the branch I can copy the branch files, right? | 01:32 |
| poolie | right | 01:32 |
| KeBugCheckEx | Event form Linux to Windows? | 01:32 |
| poolie | yes | 01:32 |
| KeBugCheckEx | *Even* | 01:32 |
| KeBugCheckEx | nice! | 01:33 |
| poolie | make sure it's a standalone branch, ie includes the repository data too | 01:33 |
| KeBugCheckEx | If someout changes the branch after this I only need to merge | 01:33 |
| KeBugCheckEx | someone | 01:34 |
| KeBugCheckEx | ok, I thing I can start something with this info. Thanks! | 01:34 |
| KeBugCheckEx | god, I better go sleep or take some typing lessons... | 01:35 |
| spiv | poolie: good morning. | 01:52 |
| poolie | hi spiv | 02:04 |
| poolie | spiv, did your patch land? | 02:04 |
| spiv | poolie: no, a surprising number of tests try to commit invalid revisions. | 02:06 |
| spiv | I just fixed a test in per_workingtree, for example, which I wasn't expecting to be affected. | 02:06 |
| spiv | Mainly it's been that a lot of tests that create revisions directly, without creating the texts in those revisions. | 02:08 |
| spiv | And all 2a revisions have a root. | 02:08 |
| spiv | Ok, looks like per_workingtree is now passing. | 02:09 |
| spiv | Also, we have lots of tests that do: "start_write_group(); try: ...; except: abort_write_group(); else: commit_write_group()" | 02:10 |
| poolie | :/ | 02:10 |
| spiv | But actually when commit_write_group fails we still need to do abort_write_group(), otherwise the inevitable unlock will raise an error from the cleanups and hide the real failure. | 02:10 |
| poolie | what's the problem with that one? | 02:10 |
| spiv | So more correct is to put the commit_write_group inside the try, I think. | 02:11 |
| spiv | But I wonder if commit_write_group shouldn't actually be "commit_or_else_abort_write_group". | 02:11 |
| lifeless | spiv: commit can lead to suspend, no? | 02:12 |
| lifeless | spiv: not that I'm here today. | 02:12 |
| * lifeless goes :) | 02:12 | |
| spiv | Because I don't think we ever try to recover if commit_write_group fails, so the current API is a bit suboptimal. | 02:13 |
| spiv | lifeless: actually, no | 02:13 |
| spiv | lifeless: we detect that case before trying commit | 02:13 |
| spiv | But anyway by far the most common case is "I want to either commit, or fail", but the current API makes that tedious. | 02:14 |
| lifeless | spiv: I'd favour a helper rather than a larger contract for commit | 02:15 |
| spiv | Sure, I agree it's useful to have the smaller operation available. | 02:16 |
| spiv | We're just not doing a good job of catering to the common case, atm. | 02:16 |
| poolie | yeah, copy & pasting this seems bad | 02:17 |
| poolie | on phone | 02:17 |
| * igc lunch | 04:02 | |
| spiv | poolie: my patch landed. | 04:35 |
| jam | mwhudson: I'm sort of around, though not for long | 04:56 |
| mwhudson | jam: no worries | 04:57 |
| mwhudson | jam: i commented on a bzr/launchpad-code bug, it would be nice if you replied at some point | 04:57 |
| jam | mwhudson: response sent | 05:02 |
| poolie | spiv, woo, way to go | 05:08 |
| poolie | spiv, did you get another review? it sounded like there were nontrivial changes there | 05:10 |
| mwhudson | jam: thanks | 05:12 |
| mwhudson | spiv: the fix for https://bugs.edge.launchpad.net/launchpad-code/+bug/424136 should be on staging by now, want to test it? | 05:29 |
| ubottu | Ubuntu bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Fix committed] | 05:29 |
| spiv | mwhudson: hmm, it should be straightforward to test I guess. | 05:54 |
| spiv | make a 1.9 trunk branch; make a 1.9 branch stacked on trunk; upgrade trunk to 2a; upgrade stacked to 2a. | 05:54 |
| poolie | igc, it's sphinx 0.6 you need? | 06:12 |
| spiv | mwhudson: hmm | 06:28 |
| spiv | mwhudson: when I try to upgrade my test trunk on staging I get bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'mismatched lock context and write group. None, <bzrlib.transactions.WriteTransaction object at 0x3111ed0>') | 06:29 |
| spiv | mwhudson: oh, actually, nevermind | 06:29 |
| mwhudson | ! | 06:29 |
| spiv | That's probably just because I'm trying to push from a 1.9 local branch to a 2a remote, but the server is too old to support that sanely. | 06:30 |
| spiv | Oh, hmm, 1.18rc1 | 06:30 |
| spiv | Oh, right, but it doesn't support the new insert_stream verb, and yeah. | 06:30 |
| spiv | Known issue, I think. | 06:31 |
| spiv | mwhudson: (p.s. please upgrade lp to 2.0rc2 ;) | 06:32 |
| mwhudson | tests fail currently | 06:36 |
| * spiv waits for https://code.staging.launchpad.net/~spiv/+junk/test-stacked to find out if 424136 is fixed. | 06:40 | |
| spiv | mwhudson: looks good, thanks! | 06:42 |
| mwhudson | spiv: yay | 06:43 |
| igc | poolie: yes | 06:46 |
| poolie | igc, that's only in karmic | 06:47 |
| poolie | that kind of worries me | 06:47 |
| poolie | dependencies are a pain in the butt | 06:47 |
| poolie | despite all the work that's gone into modularity | 06:47 |
| igc | poolie: the best result comes from sphinx 0.6 | 06:48 |
| igc | poolie: I suspect it still works on earlier versions but I'd need to test | 06:48 |
| poolie | oh ok | 06:48 |
| igc | poolie: it shouldn't be hard for us to support earlier sphinx versions | 06:49 |
| igc | poolie: but we won't get the blue theming for example pre 0.6 IIUIC | 06:49 |
| poolie | i'm just worried about adding it at all, given the kerfuffle with putting it on orcadas | 06:49 |
| igc | poolie: well I felt our *default* docs ought to look the best they can - see http://sphinx.pocoo.org/theming.html | 06:50 |
| igc | poolie: less pretty colours in the docs for a given distro concern me much less, of course | 06:51 |
| igc | by default, I meant our online ones | 06:51 |
| poolie | essentially i'm not feeling this is a good risk/reward tradeoff to land at this time | 06:52 |
| igc | :-( | 06:53 |
| poolie | what do you think? | 06:53 |
| igc | well, I'm not objective it | 06:53 |
| poolie | to me the main thing is to field it on the public site, and we can do that without putting it in the 2.0 tarball | 06:53 |
| poolie | i don't want to frustrate you, but i also don't want packaging to be held up | 06:54 |
| poolie | so | 06:54 |
| igc | I've put a lot of energy into getting good pdf and chm docs ready for the win and os x installers | 06:54 |
| poolie | hm | 06:54 |
| poolie | they are really popular | 06:54 |
| poolie | i guess if this doesn't go in, we won't get chm etc? | 06:54 |
| igc | right | 06:54 |
| poolie | or we won't get it split out by language, so it looks broken? | 06:55 |
| poolie | or just not at all? | 06:55 |
| igc | and searching in html will suck as well | 06:55 |
| igc | without this patch, we have no chm at all and no/very-little pdf at all | 06:56 |
| igc | poolie: so the blocker is dependency on sphinx 0.6 | 06:56 |
| igc | if it built with sphinx 0.4 or 0.5, that would be ok? | 06:57 |
| poolie | how about if i try this branch on jaunty | 06:57 |
| poolie | that will give us some data | 06:57 |
| igc | sounds good | 06:57 |
| poolie | so sphinx is reasonably straightforward to install on windows? | 06:57 |
| poolie | and os x? | 06:57 |
| igc | I'm on jaunty as well but will sphinx installed via easy-install | 06:57 |
| igc | poolie: easy to install on Windows - I did that to build the chm's | 06:58 |
| igc | poolie: on Windows, install python, install east_install via an installer and then use easy_install to grab sphinx | 06:58 |
| poolie | spiv, tell me about https://code.edge.launchpad.net/~spiv/bzr/set-tags-bytes-bug-2.0/+merge/10778 | 07:00 |
| poolie | it seems like that should land to 2.0? | 07:00 |
| poolie | did it bounce? | 07:01 |
| spiv | poolie: hmm! | 07:01 |
| poolie | also, do you have an opinion about changing to sphinx for documentation generation for 2.0? | 07:02 |
| spiv | I'm also wary of making life harder for packagers just before 2.0 | 07:03 |
| spiv | But I don't really know how much of a problem sphinx would be for packagers. | 07:03 |
| vila | hi all | 07:06 |
| * bialix waves at vila | 07:06 | |
| spiv | poolie: I don't know any reason why that set-tags-bytes-bug-2.0 branch hasn't merged yet. | 07:07 |
| vila | hmm, regarding docs, it sounds a lot like we want to split the docs *out* of the bzr package like we do for installers, | 07:07 |
| * vila waves back | 07:07 | |
| spiv | I've just merged in latest lp:bzr/2.0 to make sure the NEWS entry is in the right spot. | 07:07 |
| spiv | Oh, perhaps that's why, the 2a transition. | 07:07 |
| * spiv pushes to a new lp branch to workaround 424136 | 07:08 | |
| vila | hmm, still regarding docs, without looking at the code, ISTM that there should a basic way to produce the html docs from the source package, then, any installer branch can add its own way of generating specially targeted docs, chm, pdf, shiny web site, etc | 07:10 |
| vila | that way we don't add dependencies on the source package. | 07:10 |
| vila | poolie: testing on jaunty is hardly relevant, try, say, OSX, Fedora and FreeBSD. *Then* you'll get a batter taste of the dependency issue :-D | 07:11 |
| spiv | poolie: lp:~spiv/bzr/set-tags-bytes-bug-2.0-again is up-to-date, and not broken by the 1.9->2a transition. | 07:11 |
| spiv | poolie: I'm happy to fire that at PQM unless you'd rather have PQM to yourself for making a release? | 07:12 |
| vila | Did I say jaunty is hardy relevant ? I should have, that's the current LTS | 07:12 |
| poolie | spiv, yes please, send it | 07:17 |
| spiv | poolie: ok | 07:18 |
| poolie | vila, you don't need to convince me, i'm the one that has doubts about it | 07:26 |
| vila | :) | 07:26 |
| * fullermd waits for vila to question how well the docs show up in Mosaic :p | 07:27 | |
| poolie | vila, see pm | 07:31 |
| rockstar | easy_install fail - error: Can't download http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz: 404 Not Found | 07:55 |
| bialix | rockstar: 2.0rc1 had critical bug inside and was withdrawn | 07:59 |
| igc | poolie: call? | 08:19 |
| vila | fullermd: the interesting question, IMHO, is: can we still setup, on today's hardware, an OS where we can install Mosaic ? :-D | 08:20 |
| Lo-lan-do | *Still* discussing Mosaic? | 08:21 |
| vila | Lo-lan-do: welcome to VCS channel where you can have branched discussions that last forever ! | 08:22 |
| Lo-lan-do | :-) | 08:22 |
| poolie | igc, hi | 08:24 |
| poolie | sure, call | 08:24 |
| spiv | poolie: the _set_tags_bytes fix landed, btw. | 08:32 |
| poolie | yay | 08:32 |
| spiv | First time, unlike the last patch :) | 08:32 |
| vila | bug #424136 | 08:33 |
| ubottu | Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Fix committed] https://launchpad.net/bugs/424136 | 08:33 |
| vila | hmm, spiv, can you tell me more about that bug ? I successfully upgraded a couple of branches by doing: 'bzr upgrade bzr+ssh://lpnet' ignore the error, 'bzr reconfigure --stacked-on bzr+ssh://lp,net' pesting because I couldn't use lp url in the later, but otherwise, I got usable branches... I didn't check the public ones though | 08:36 |
| spiv | vila: it's the public ones that are the problem | 08:40 |
| spiv | vila: also, look at the branch pages for the branches you've upgraded | 08:40 |
| spiv | vila: oh, and beware the confounding bug that if you don't change the tip revision, lp won't try update the mirror AFAICT, even if the format has changed. | 08:41 |
| vila | right, I upgraded branch to push, so there ;) | 08:42 |
| spiv | vila: for an example of an affected branch, see https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root | 08:43 |
| spiv | vila: https://code.edge.launchpad.net/~vila/bzr/test-isolation appears to be a victim of the same bug, for instance | 08:43 |
| vila | spiv: right, I think that's where the 'bzr reconfigure --stacked-on' workaround help | 08:47 |
| vila | spiv: do you mind if I try there or do you want to keep that as evidence ? | 08:47 |
| spiv | vila: no, go ahead. | 08:47 |
| spiv | vila: I don't care much, as mwhudson has fixed the bug anyway (although it's only rolled out on staging so far) | 08:48 |
| vila | spiv: ok, thanks for the feeback ! | 08:48 |
| AfC | What would I have to do to info.py in bzr-git to make it work with bzr 2.0-rc1? | 08:51 |
| bialix | poolie: still here? | 09:23 |
| bialix | hmmm, every new repo/branch format changed the way how locking works | 09:24 |
| bialix | every time we have to accommodate qbzr internals | 09:25 |
| bialix | does 2a format is radically different from 1.9 re locking? | 09:25 |
| vila | bialix: I don't think the design changed, but the usage may raise lock errors at different places/times... | 09:26 |
| * igc dinner | 09:27 | |
| vila | ...if not used correctly (bzr itself had bugs there) | 09:27 |
| bialix | Bug 426688 | 09:27 |
| ubottu | Launchpad bug 426688 in qbzr "ObjectNotLocked opening diff from annotate on 2a branch." [Critical,Confirmed] https://launchpad.net/bugs/426688 | 09:27 |
| bialix | vila: ^ | 09:27 |
| vila | exactly | 09:27 |
| poolie | bialix: it's not very different with regard to locking | 09:27 |
| bialix | perhaps there should be some guidelines for bzrlib users | 09:28 |
| bialix | I don't understand why it worked fine before and now blow up | 09:28 |
| poolie | i wonder if this relates to john's fix to fix shelve or something similar | 09:28 |
| vila | bialix: sometimes locks were taken abusively and are not anymore, that leads to bugs like above | 09:28 |
| bialix | shelev fix is lifeless work | 09:29 |
| poolie | my mistake | 09:29 |
| vila | poolie, bialix: It may very well be related to lifeless fix | 09:29 |
| bialix | bzr 1.17 | 09:29 |
| bialix | vila, poolie: ^ | 09:29 |
| bialix | it's not related | 09:29 |
| bialix | to lifelees fix | 09:29 |
| vila | ok, still, it certainly mean you need to take a read lock where it was taken by bzrlib before (for wrong reasons AIUI) | 09:30 |
| poolie | i wish people would put useful reprs on | 09:30 |
| poolie | does locking a wt implicitly lock the branch and repo? | 09:31 |
| bialix | my question is more generic | 09:32 |
| vila | 'why it worked fine before and now blow up' ? | 09:34 |
| poolie | sorry, what's the question? | 09:34 |
| vila | That's what bugs are about generally... | 09:34 |
| vila | bugs that appear to make things work being the worse kind ! | 09:34 |
| poolie | vila :-) :-) nice mail | 09:37 |
| vila | poolie: thanks :) | 09:37 |
| bialix | vila: no, why it blows up every time new format is appears | 09:47 |
| vila | bialix: same answer: new format, new bugs, now, giving the backtrace, it starts with a call to id2path() which is an important change in 2a (inventories), bugs there are not that surprising | 09:49 |
| bialix | heh | 09:50 |
| * bialix not planned to switch to new format because of all this stuff | 09:51 | |
| vila | it's a bit surprising that it ends up in a groupcompress index though | 09:51 |
| poolie | mm | 09:51 |
| poolie | i'd say this is a latent bug in either qbzr or elsewhere though | 09:51 |
| * bialix thinks 1.18.1 is the right thing to have as latest stable pre-2a default format | 09:51 | |
| poolie | that it was getting away with it before | 09:51 |
| vila | bialix: that's still a bug in qbzr IMHO | 09:51 |
| bialix | vila: yes | 09:51 |
| bialix | I'm really hope 1.18 can be a long term supported pre-2a release as poolie want for post 2a development | 09:53 |
| bialix | there is too much dependencies between various tools | 09:53 |
| poolie | bialix: how about if we add an option to 2.0 to set the default format | 09:53 |
| poolie | and then support 2.0? | 09:53 |
| bialix | maybe other people can jump right into 2a -- I can't | 09:53 |
| vila | bialix: even for new projects ? | 09:53 |
| bialix | so when jam wrote he don't think 1.18.1 make sense -- it hurts | 09:54 |
| poolie | that's probably the last thing i should do today | 09:54 |
| bialix | vila: I don't have completelly new projects at work | 09:54 |
| vila | I don't follow your reasoning, 2a becomes the new default format, but previous formats are still supported... | 09:54 |
| bialix | 2a is default when you start working | 09:54 |
| vila | nobody forces you to *upgrade* | 09:55 |
| bialix | bzr init-repo will create repo in 2a, right? | 09:55 |
| bialix | this will be implicit upgrade | 09:55 |
| bialix | and then I can't push to my central repo | 09:55 |
| vila | yes, you do that frequently ? | 09:55 |
| bialix | because of incompatible rich-roots, pfffs! | 09:55 |
| bialix | yes, I'm do new local shared repos frequently | 09:55 |
| bialix | for each customer we support, when new features need to be implemented | 09:56 |
| vila | you can swallow the incompatible rich-root by upgrading to 1.9-rich-root or 1.14-rich-root | 09:56 |
| bialix | 1.9-rich-root is slower than pack-0.92, you know? | 09:56 |
| vila | but 1.14 should be faster no > | 09:57 |
| vila | but 1.14 should be faster no ? | 09:57 |
| bialix | 1.14 is base don 1.9, no? | 09:57 |
| bialix | 1.14 is just new wt format? | 09:57 |
| vila | AIUI it has the faster indexes | 09:57 |
| poolie | so | 09:57 |
| poolie | if we made it read /etc/bazaar.conf | 09:58 |
| poolie | and there had default_format = 1.9 | 09:58 |
| poolie | then you'd get the same behaviour but from the different code base | 09:58 |
| poolie | or rather the same codebase | 09:58 |
| bialix | if you will allow 0.92 as well -- then great | 09:58 |
| vila | 0.92 *is* still supported | 09:58 |
| bialix | I mean allow in bazaar.conf | 09:59 |
| poolie | sure | 09:59 |
| vila | it's called --pack-0.92, ha, right, | 09:59 |
| poolie | bialix: want to choose a name for this release? :) | 09:59 |
| vila | Nein-Nein-Nein :) | 10:00 |
| bialix | lol | 10:00 |
| bialix | last from Mogikan? | 10:00 |
| poolie | that's the name? | 10:02 |
| poolie | it's a place? | 10:02 |
| bialix | wait a sec | 10:02 |
| bialix | The Last of the Mohicans | 10:03 |
| bialix | James Fenimore Cooper | 10:03 |
| poolie | because it's the last post 2.0? | 10:03 |
| bialix | something like that | 10:04 |
| poolie | i wonder if Disney will trouble us? | 10:04 |
| bialix | it makes sense for those who read/saw the movie | 10:04 |
| bialix | I feel the joke | 10:04 |
| bialix | never mind me, I'm thinking in Russian | 10:04 |
| bialix | it's famous quote in our culture | 10:05 |
| poolie | hm | 10:06 |
| poolie | i think there is a cultural difference | 10:07 |
| poolie | how about if i use the way you originally spelled it? | 10:07 |
| bialix | lol | 10:07 |
| bialix | poolie: I realy had to shut up | 10:08 |
| poolie | anyhow, i want to get it out tonight | 10:08 |
| bialix | vila's variant is funny | 10:08 |
| poolie | oh, it is too | 10:08 |
| bialix | I hope spiv landed that patch for tags | 10:08 |
| poolie | to 2.0 yes | 10:08 |
| bialix | I've backported it to 1.18.1 | 10:08 |
| poolie | oh, he was going to land your backport? | 10:09 |
| bialix | he seems to land it | 10:09 |
| bialix | but to wrong branch | 10:09 |
| bialix | https://code.launchpad.net/~bialix/bzr/bzr-1.18-set-tags-bytes-bug/+merge/10811 | 10:10 |
| vila | poolie: my proposal will not be fun at all if you don't release today :) | 10:10 |
| poolie | vila: genau! | 10:10 |
| bialix | vila: oh | 10:10 |
| bialix | you mean 9-9-9 | 10:10 |
| vila | bialix: yup, double meaning :-) | 10:11 |
| bialix | I've recall Hitler "nine" from recent movie | 10:11 |
| vila | bialix: Infurious Bestards ? | 10:11 |
| bialix | yep | 10:11 |
| bialix | saw the trailer | 10:11 |
| bialix | poolie: is it possible to land https://code.launchpad.net/~bialix/bzr/bzr-1.18-set-tags-bytes-bug to 1.18.1? | 10:12 |
| vila | Watch it undubbed (sp?), Brad Pitt accentS are hilarious ! | 10:12 |
| poolie | yes | 10:12 |
| bialix | spiv has not landed it | 10:12 |
| poolie | i'll merge it | 10:12 |
| bialix | vila: ok, will wait for dvd with English sound and subtitles | 10:12 |
| poolie | in fact i am merging it | 10:12 |
| luks | vila: especially the italian one :) | 10:12 |
| vila | luks: indeed ! | 10:13 |
| bialix | hi luks | 10:13 |
| luks | hey | 10:13 |
| luks | bialix: there is more german and french than english | 10:14 |
| bialix | well, in Ukraine I believe our brave translators cut out german and french and leave only ukrainian | 10:17 |
| luks | heh | 10:17 |
| bialix | so original DVD sound is cool for listen | 10:17 |
| bialix | yep | 10:17 |
| poolie | bialix, was there a bug for that change? | 10:19 |
| poolie | i think there was | 10:19 |
| bialix | yes, it was | 10:19 |
| bialix | Bug 418931? | 10:20 |
| ubottu | Launchpad bug 418931 in bzr "AssertionError: _remember_remote_is_before((1, 18)) called, but _remember_remote_is_before((1, 15)) was called previously" [High,Fix committed] https://launchpad.net/bugs/418931 | 10:20 |
| bialix | yes, that bug | 10:20 |
| bialix | poolie: ^ | 10:21 |
| poolie | lp is a bit down | 10:23 |
| vila | poolie: slow, but not down | 10:25 |
| poolie | ok, i'm sending 1.18.1 to pqm | 10:28 |
| poolie | ok that's it for me | 10:32 |
| bialix | vila: do you want long answer in e-mail about setup.py? | 10:56 |
| bialix | I think you can look at qbzr's setup.py and its extras/ | 10:56 |
| bialix | to get some impression | 10:56 |
| vila | oooh, so you meant, 'that' already what qbzr does' not 'we don't need that stuff' ? | 10:58 |
| bialix | I've lost in ' signs | 10:59 |
| vila | sorry, reading /extras/* | 10:59 |
| vila | bialix: what qbzr did is exactly what bzr needs to do there, and igc should really look at build_docs for example, it sounds like a far easier way to make sphynx a soft dependency that trying to do that from the Makefile | 11:00 |
| vila | bialix: now, I don't really know hoe bzr setup.py and plugins setup.py can collaborate, but I'm sure we'll find :) | 11:01 |
| vila | s/hoe/how/ | 11:01 |
| vila | bialix: Do we agree ? | 11:02 |
| vila | bialix: still there ? | 11:05 |
| bialix | vila: ping, I'm back | 11:14 |
| vila | ha ok, so ^ | 11:14 |
| bialix | [13:00]<vila>bialix: what qbzr did is exactly what bzr needs to do there, and igc should really look at build_docs for example, it sounds like a far easier way to make sphynx a soft dependency that trying to do that from the Makefile | 11:15 |
| bialix | yes, I agree here | 11:15 |
| bialix | [13:01]<vila>bialix: now, I don't really know hoe bzr setup.py and plugins setup.py can collaborate, but I'm sure we'll find :) | 11:15 |
| bialix | ^ I think all setup.py should be importable | 11:15 |
| bialix | i.e. call to setup() function should be guarded with if __name__ == '__main__' stuff | 11:16 |
| vila | ooooh, so we can use 'from bzrlib.plugin.qbzr import setup as qsetup' for example and collect anything we need ? | 11:19 |
| vila | bialix: sounds like a very good plan | 11:19 |
| vila | bialix: so may be you should point to qbzr/extras stuff in that mail discussion so that we converge | 11:29 |
| bialix | .ьу иид | 11:37 |
| * bialix bbl | 11:37 | |
| bialix | vila: ping | 12:27 |
| bialix | [13:19]<vila>ooooh, so we can use 'from bzrlib.plugin.qbzr import setup as qsetup' for example and collect anything we need ? | 12:27 |
| bialix | ^ yes | 12:27 |
| === mrevell is now known as mrevell-lunch | ||
| lvh | hello | 13:38 |
| lvh | I'm getting AttributeError: 'module' object has no attribute 'ProgressBarStack' when inspecting a file with loggerhead | 13:38 |
| lvh | loggerhead 1.10-1 from debian testing, bzr1.17 from the same | 13:39 |
| CameronP | Hi Everyone | 13:43 |
| lvh | just upgraded to 1.18, problem persists | 13:46 |
| === mrevell-lunch is now known as mrevell | ||
| alex-weej | sometimes i like to commit just to save a checkpoint even if i don't intend the commit to be permanent (i.e. a mess of files left over from some aborted experiment) | 13:54 |
| alex-weej | *e.g.! | 13:54 |
| alex-weej | is there a way i can re-organise such commits at a later date? | 13:54 |
| alex-weej | and what are the implications on the sequential revision numbers? i think git sidesteps the problem by using hashes | 13:55 |
| AfC | alex-weej: the revnos are just aliases (and are unique to any branch) | 14:00 |
| AfC | s/unique/local/ | 14:00 |
| AfC | alex-weej: speaking personally | 14:01 |
| AfC | when I have to do what you're describing | 14:01 |
| alex-weej | hey AfC :) | 14:01 |
| AfC | I make a commit with a log message like "CHECKPOINT" and it's pretty obvious that the next morning I'll be uncommitting that. | 14:01 |
| AfC | alex-weej: yo | 14:01 |
| alex-weej | lol yeah | 14:01 |
| spiv | lvh: hmm, sounds like your loggerhead is trying to use an old bzrlib API. | 14:01 |
| AfC | alex-weej: others use `bzr shelve` for this sort of thing | 14:01 |
| AfC | alex-weej: I use `bzr commit -m "CHECKPOINT"` ... and then switch away to another branch | 14:02 |
| alex-weej | ok i got another question then, when i want to merge changes from a workmate's branch | 14:02 |
| AfC | alex-weej: that all said, | 14:02 |
| AfC | alex-weej: I should observe that there's a slight cultural difference 'round here | 14:02 |
| AfC | alex-weej: in that most people would probably encourage you just to commit with a half decent attempt at some vaguely almost useful sentence as a log message, | 14:03 |
| AfC | alex-weej: and then just carry on from there (ie, no uncommit later) | 14:03 |
| alex-weej | hm. a lot of the time i just want a kind of undo history when i am doing some dirty development. i should probably hack better, though, really. | 14:03 |
| AfC | alex-weej: while there is a rebase capability lying around, most of us tend not to use it. Just merge, and carry on. It's not lkml | 14:03 |
| AfC | alex-weej: (ie, I review patches at merge time. I really do encourage people contributing to me to write good log messages so the annotation is good, | 14:04 |
| Lo-lan-do | I do rebase, but not to change history. | 14:04 |
| AfC | alex-weej: but on the other hand, if people are doing small to micro commits then, well, the usefulness of individual log messages starts to go down) | 14:05 |
| Lo-lan-do | I use it to port local branches to an SVN trunk, so I need to linearise. | 14:05 |
| AfC | Lo-lan-do: perhaps, but if *anyone* else has access to your previous branch, well, then you're recreating history. | 14:05 |
| AfC | if it's just you and not published, then {shrug} | 14:05 |
| Lo-lan-do | They don't, that's thte point :-) | 14:05 |
| AfC | [I don't push to subversion any more, and I publish everything including work-in-progress, so... | 14:06 |
| AfC | I have to assume someone else might have a revision I've made] | 14:06 |
| alex-weej | when i want to merge changes from a workmate's branch, i look at it and see that i want to merge e.g. up to revision 17, but in the time it takes me to type bzr merge -r 17 /path/to/branch, revision 17 may have been changed! i tried to use one of the revision IDs with some kind of number and a hash, but "merge" didn't accept it. | 14:06 |
| Lo-lan-do | Well, technically the clients for whom I developed the stuff could see it, but in practice they don't even look. | 14:06 |
| AfC | alex-weej: um | 14:06 |
| jelmer__ | moin AfC, Lo-lan-do | 14:06 |
| AfC | alex-weej: 17 won't have changed | 14:06 |
| AfC | ... oh | 14:06 |
| AfC | alex-weej: so -r takes all kinds of things | 14:07 |
| AfC | -r 17 is shorthand for -r revno:17 | 14:07 |
| AfC | from there we can consider | 14:07 |
| spiv | alex-weej: "bzr merge -r revid:FOO" is how you use the long identifier for a revision. | 14:07 |
| AfC | -r tag:v4.0.7 | 14:07 |
| lvh | spiv: So, update loggerhead? | 14:07 |
| spiv | alex-weej: see also "bzr help revisionspec" | 14:07 |
| alex-weej | ahhhh | 14:07 |
| spiv | lvh: at a guess, yeah. | 14:07 |
| AfC | but what you want is what spiv just saidm | 14:07 |
| alex-weej | AfC, spiv, thanks :) will use revid | 14:07 |
| alex-weej | i love bzr!! | 14:07 |
| Lo-lan-do | I'd love to get away from SVN too, but I still have to contend with git users, so until bzr and git can cooperate fully we keep SVN as a pivot. | 14:07 |
| AfC | -r revid:andrew@operationaldynamics.com-20090909023536-f0n026ookg9j64vr | 14:08 |
| Lo-lan-do | (Which is why I'm a pain in jelmer's neck from time to time :-) | 14:08 |
| spiv | lvh: https://launchpad.net/loggerhead mentions a 1.17 release, so my guess is 1.10 is pretty out of date. | 14:08 |
| spiv | alex-weej: also, | 14:08 |
| spiv | alex-weej: you could just do "bzr merge /path/to/branch", then review then changes with "bzr diff", and then either revert or commit. | 14:08 |
| AfC | alex-weej: while revnos are specific [local] to a given (and each) branch, they are somewhat usable on (say) a published 'mainline' that everyone else is merging in from | 14:08 |
| AfC | alex-weej: but yes, be aware that there in (say) my ~/src/java-gnome/ directory, I have many many branches | 14:09 |
| alex-weej | spiv: yeah good point, i forgot it wasn't an automatic commit | 14:09 |
| AfC | with revno 646 in them. | 14:09 |
| spiv | alex-weej: then if the other branch changes since you did the merge, it doesn't matter; those changes won't affect what you commit. | 14:09 |
| spiv | alex-weej: even if it was an automatic commit, there's always uncommit ;) | 14:09 |
| AfC | (which could refer to different things if these various branches all forked off of mainline at, say, revno 640) | 14:09 |
| AfC | alex-weej: what you and I call cherry picking is [still] a bit funny around here. If you find yourself fighting it, give me a shout and I'll do my best to talk you through the possibilities. I've been fighting it for 3+ years now | 14:10 |
| alex-weej | i thought it was just merge -r 19..20 or something? | 14:11 |
| AfC | alex-weej: yes... but revisions are tree states, not diffs | 14:12 |
| alex-weej | hmm | 14:12 |
| AfC | but in several permutations you can pull in a patch without pulling in / merging "revisions" which, as far as I'm concerned == loss of history. Which I continue to be very grumpy about | 14:12 |
| alex-weej | eugh | 14:12 |
| AfC | alex-weej: anyway, if you just merge a branch, or a branch up to a revno | 14:12 |
| alex-weej | well, hopefully never have to do it | 14:13 |
| AfC | then in come the revisions. | 14:13 |
| AfC | as you'd expect. | 14:13 |
| AfC | $ bzr status -v | 14:13 |
| AfC | after a merge before committing it will show you all the revisions you're merging in. That's useful to keep an eye on. | 14:14 |
| Tak | hello jelmer_* | 14:14 |
| AfC | alex-weej: (essentially, you will either not notice this at all, or hit it all the time. All depends on your usage habits. As a maintainer & gatekeeper trying to be selective about things, I hit it a lot, but the problem goes away the more I encourage people to submit orthogonal branches) | 14:15 |
| alex-weej | everyone else here uses it as if it was cvs | 14:16 |
| AfC | alex-weej: at the end of the day, though, just merge branches. It'll do the right thing. | 14:16 |
| alex-weej | but say i am working on my mainline, and my boss asks me to put a new feature that's in mainline into the deployed stable branch... i can't just merge all the way up! | 14:17 |
| AfC | alex-weej: yeah, that's when you have to start cherry picking | 14:17 |
| Lo-lan-do | Maybe bzr replay would work here, although it's still not recorded. | 14:18 |
| AfC | alex-weej: probably have a read of http://blogs.operationaldynamics.com/andrew/software/version-control/bzr-orthogonal-patches.html . That might be a bit outdated now, but it's where I was a couple years ago. | 14:18 |
| AfC | alex-weej: in the case you're describing, [even if you happen to use a -r range to get the delta you're looking for], you really are creating a new changeset and on committing a new revision [on your stable release branch] | 14:19 |
| AfC | anyway, I'm still a bit sceptical. I but heads with the bzr hackers about this all the time | 14:20 |
| alex-weej | so when you use -r a..b it's not really merging revisions? | 14:20 |
| jelmer__ | alex-weej: you're merging revisions but bzr can't track cherrypick merges at the moment | 14:21 |
| jelmer__ | so it won't remember what happened there and can't use that fact when you're doing merges in the future | 14:22 |
| alex-weej | oh right, so it is likely to conflict in the future if i merge the whole branch? | 14:22 |
| alex-weej | or is there some other issue i'm overlooking? | 14:23 |
| alex-weej | sorry i'm still quite new to dvcs really | 14:23 |
| AfC | alex-weej: it [probably] won't conflict if the lines of text are the same (which they will be). | 14:23 |
| AfC | alex-weej: [that's sorta the point of the essay I linked to above] | 14:23 |
| AfC | alex-weej: fwiw, have a read of the "Getting Started" section of http://java-gnome.sourceforge.net/4.0/HACKING.html ; it's not really that java-gnome specific | 14:26 |
| AfC | alex-weej: Bazaar also has a thick extensive user manual, which has the drawback of explaining that there are 6 different ways to use the thing. | 14:26 |
| alex-weej | AfC: ok, don't have time to read it now though as i'm on the clock. have bookmarked :) | 14:27 |
| alex-weej | thanks for your help, i need to write some code though now! | 14:27 |
| AfC | alex-weej: (admittedly that talks about the contributor side of things, not the maintainer viewpoint) | 14:28 |
| phinze | is there a plugin that allows you to selectively commit a la shelve? | 15:11 |
| phinze | interactive? | 15:11 |
| vila | phinze: not that I know of, but you can use shelve and *then* commit :-) | 15:12 |
| phinze | vila: yeah i do that a lot, looking to cut out that extra step... looks like lp:bzr-interactive might do it... checking it out | 15:13 |
| phinze | yup, adds `bzr commit -i` ... with colored output and everything, nice! | 15:14 |
| Lo-lan-do | That should be fasttracked to mainline, I think :-) | 15:15 |
| phinze | Lo-lan-do: +1 here, from inital usage | 15:17 |
| Lo-lan-do | And I said that without even initial usage :-) | 15:18 |
| Lo-lan-do | That and interactive rebase with squashing, and git is dead. | 15:19 |
| Lo-lan-do | (maybe) | 15:19 |
| Lo-lan-do | Oh, and cherrypicking. And milliseconds-fast, too. | 15:20 |
| jelmer__ | Lo-lan-do: cherrypicking is already supported | 15:20 |
| Lo-lan-do | Shush, I'm trolling! | 15:20 |
| * Lo-lan-do returns to trying to fix bzr-git | 15:22 | |
| jelmer__ | (-: | 15:23 |
| Lo-lan-do | How would you debug that, by the way? My usual technique of printf-debugging ends up on the wire so it can't be done. | 15:23 |
| jelmer__ | Lo-lan-do: debug what specifically? | 15:24 |
| Lo-lan-do | bzr-upload-pack | 15:25 |
| Lo-lan-do | Mostly dulwich's server.py it seems | 15:26 |
| Lo-lan-do | I'll try speaking the git protocol into stdin, the good old-fashioned way. | 15:28 |
| * Lo-lan-do remembers speaking IRC into a telnet tube years ago | 15:28 | |
| jelmer__ | Lo-lan-do: pdb is your friend :-) | 15:30 |
| jelmer__ | Lo-lan-do: and wireshark is very useful for protocol debugging | 15:30 |
| jelmer__ | although there isn't a specific git protocol dissector yet | 15:31 |
| Lo-lan-do | Doesn't pdb eat my stdin? | 15:35 |
| \u03b5 | erm, is there a doc for whatever Branch.tags is? | 15:36 |
| \u03b5 | ah, right | 15:38 |
| jelmer__ | \u03b5: try "pydoc bzrlib.branch.Branch.tags" :-) | 15:38 |
| \u03b5 | bzrlib.tag.BasicTags | 15:38 |
| \u03b5 | no Python documentation found for 'bzrlib.branch.Branch.tags' | 15:39 |
| \u03b5 | hehe | 15:39 |
| Lo-lan-do | jelmer: I think I found something. In bzr-git's server.py, line 603 indirectly calls graph_walker, but it's been called already and therefore it won't return anything since the client isn't going to send the list again. | 15:48 |
| Lo-lan-do | Shouldn't there be a cache of some sort? | 15:49 |
| Lo-lan-do | One can't reset the iterator, either, for the same reason. | 15:50 |
| * jelmer__ looks | 15:57 | |
| jelmer__ | Lo-lan-do: I don't have a line 603 | 15:57 |
| \u03b5 | what should I use to find out a branch's public URL? get_public_branch, or get_push_branch, or get_parent_branch or nothing? | 15:58 |
| \u03b5 | and get_master_branch for bound checkouts | 15:58 |
| jelmer__ | \u03b5: for the public branch, get_public_branch() | 15:58 |
| \u03b5 | or am I missing something that does the job already | 15:58 |
| \u03b5 | it's empty :x | 15:59 |
| jelmer__ | \u03b5: did you set a public branch URL explicitly? | 16:00 |
| \u03b5 | nope, and I doubt people will do so | 16:00 |
| Lo-lan-do | jelmer: You have a *revno* 603, and I should look in the appropriate place, sorry. Line 136. | 16:01 |
| jelmer__ | \u03b5: the public URL of a branch depends on the setup | 16:01 |
| \u03b5 | yeah, I saw | 16:01 |
| jelmer__ | \u03b5: so it may be right it's empty | 16:02 |
| \u03b5 | in one branch I have it as parent branch, in the other as push location | 16:02 |
| jam | btw \u03b5, cute name (epsilon, right?) | 16:03 |
| \u03b5 | heh yes | 16:03 |
| jdo | bzr: ERROR: Lock not held: LockableFiles(lock, bzr+ssh://bazaar.launchpad.net/~jdobrien/ubuntuone-servers/coucdb-web-api/.bzr/repository/) | 16:06 |
| jdo | how can i fix that? ^^ | 16:06 |
| Lo-lan-do | jelmer__: Do you think adding a cache and a reset method to dulwich's UploadPackHandler.ProtocolGraphWalker would break things? If not, I'll try implementing that. | 16:12 |
| === cprov is now known as cprov-lunch | ||
| vila | hey morning jam ! | 16:39 |
| jam | morning vila | 16:40 |
| igc | night all | 17:09 |
| Lo-lan-do | jelmer__: I have git fetch and git pull working now! | 17:17 |
| * Lo-lan-do dances the happy dance | 17:17 | |
| jelmer__ | Lo-lan-do: w00t! | 17:21 |
| * jelmer__ awaits the merge requests (-: | 17:21 | |
| Lo-lan-do | You bet :-) | 17:21 |
| weigon | Lo-lan-do: you work on git-bzr ? | 17:24 |
| Lo-lan-do | weigon: I'd love to get rid of SVN as a pivot for FusionForge, and making bzr branches accessible with the git clients would be a good way to do that. So I'm only interested in that part. | 17:25 |
| \u03b5 | is there a way to have bzrlib.branch.Branch.revision_history() grab merged revisions too? | 17:26 |
| === abentley1 is now known as abentley | ||
| Lo-lan-do | jelmer__: Can I pastebin the bundles? This account has no email access… | 17:29 |
| luks | \u03b5: you can get the ancestry from the repository, using branch.last_revision as the top revision | 17:31 |
| lvh | hi | 17:31 |
| lvh | bzr (or lp) appears to be convinced a few commits didnt come from me | 17:32 |
| lvh | https://code.launchpad.net/~lvh/twisted/positioning | 17:32 |
| luks | but it's been a long time since I worked with that, I guess there are some fancier graph functions now | 17:32 |
| lvh | how can I fix that | 17:32 |
| luks | lvh: it probably looks at the email address for account matching | 17:32 |
| lvh | ah, right | 17:33 |
| luks | I wouldn't care about it, personally | 17:33 |
| luks | not sure if you can convince LP that lvh@leibniz is you | 17:33 |
| lvh | well, im nto worried about those 3 commits | 17:34 |
| lvh | but it'd be nice if i could fix my bzr config so it sets my email address properly | 17:34 |
| luks | see bzr whoami | 17:34 |
| lvh | Laurens Van Houtven <lvh@leibniz> | 17:34 |
| lvh | Yup. | 17:34 |
| lvh | Next step: fixing it. emacs ~/.bazaar/authentication.conf? | 17:35 |
| luks | you can use `bzr whoami '...'` to change that configutation | 17:35 |
| luks | I believe it's the first step of the bzr tutorial :) | 17:35 |
| lvh | hah | 17:35 |
| lvh | right, sorry :-) | 17:35 |
| lvh | this is the second box I'm using bzr on -- new install. | 17:36 |
| \u03b5 | hm, there is Graph.iter_ancestry() | 17:43 |
| \u03b5 | but, if I got it right, that gives recursive tuples | 17:44 |
| \u03b5 | would I have to count them manually? | 17:44 |
| luks | the one I was thinking about is repository.get_ancestry(rev_id) | 17:45 |
| \u03b5 | yeah | 17:45 |
| luks | which gives you a list of all revisions in the branch | 17:45 |
| \u03b5 | wouldn't that list all revisions in the repo? | 17:45 |
| luks | no, only revisions below rev_id | 17:45 |
| luks | so if rev_id == branch.last_revision it will return all revisions in the branch | 17:46 |
| \u03b5 | thanks | 17:48 |
| jam | \u03b5: dict(graph.iter_ancestry()) tends to work pretty well | 17:49 |
| jam | but depends what you need | 17:49 |
| === abentley1 is now known as abentley | ||
| lvh | What's the reccomended tool to see the tree structure of a bzr branch 20 revisions back? | 17:52 |
| lvh | checking out that revision? | 17:52 |
| Lo-lan-do | bzr ls | 17:52 |
| jam | lvh: you can 'bzr revert -r -20' or do "bzr co -r -20' | 17:53 |
| jam | or 'bzr st -r -20' | 17:53 |
| jam | if you just want to see the changes | 17:53 |
| Lo-lan-do | bzr ls -R -r -20 | 17:53 |
| lvh | thanks everyone, worked a charm :-) | 18:10 |
| luks | I'd recommend 'bzr qbrowse -r -20', but not sure if that's useful to a emacs user :) | 18:15 |
| === deryck_ is now known as deryck | ||
| === cprov-lunch is now known as cprov | ||
| === gorozco is now known as p4tux | ||
| === thekorn_ is now known as thekorn | ||
| CoffeeIV | I am taking over a project from from another developer; I am looking in his workspace at his .bzr directory, how do I find out the URL of the repository from that directory, so I can do a fresh checkout myself ? | 19:19 |
| maxb | Try bzr info | 19:20 |
| bac | what is wrong with doing "bzr pull :push" (other than it looks funny)? i get the following error: http://pastebin.ubuntu.com/268111/ in the same branch 'bzr pull :public" works | 19:23 |
| jam | bac: your :push is configured to an "lp:" url, and ":push" doesn't expand 2x | 19:25 |
| jam | not sure if that makes sense, but it does to me... | 19:25 |
| jam | if :push was configured to bzr+ssh://bazaar.launchpad.net/... then it would probably work | 19:25 |
| bac | jam: ok. that makes sense. | 19:26 |
| bac | jam: yes, public is a bzr+ssh URL and it works. just more typing! :) | 19:26 |
| jam | bac: I think it is an open bug | 19:27 |
| jam | and something that *I* would like to see fix | 19:27 |
| jam | fied | 19:27 |
| jam | fixed | 19:27 |
| jam | as I have some config that is set up for automatic 'lp:' paths | 19:27 |
| bac | well, my odds are improved, then | 19:27 |
| jam | but just one of the things on the list... :) | 19:27 |
| bac | thanks for the answer... | 19:27 |
| blueyed | Is it possible to show last-mod-date of files using "status" and maybe even sort by them? (without much shell-foo) | 19:32 |
| blueyed | I think "st --verbose" should show that maybe?! | 19:33 |
| Lo-lan-do | jelmer: Am I confused or is the current bzr-git supposed to be able to store several git branches and not only one? | 19:46 |
| Lo-lan-do | The "for oldsha, sha, ref in refs: if ref[:11] == 'refs/heads/':" loops seem to be indicating so much | 19:46 |
| benchik | hello | 19:47 |
| benchik | today for some reason i started to get: bzr: ERROR: These branches have diverged. See "bzr help diverged-branches" for more information. how do i tell bzr to override the shared version with my version? | 19:48 |
| glyph | benchik: Did you read 'bzr help diverged-branches'? :) | 19:50 |
| benchik | glyph: didn't tell me anything useful in my situation | 19:50 |
| glyph | benchik: what is your situation? (the way you asked the question, 'override the shared version', doesn't really make sense) | 19:51 |
| Lo-lan-do | jelmer: So it is. Yay, yay, yay :-) | 19:52 |
| Lo-lan-do | I'm still struggling with the confusion over the "transport" stuff, but I feel like I'm close to getting push working, too. | 19:52 |
| CoffeeIV | maxb: thanks ! | 19:54 |
| benchik | glyph: i want to run the shared version over, with my version | 19:54 |
| benchik | glyph: the tips the help gave: bzr missing etc. didn't give me useful results | 19:55 |
| glyph | benchik: why do you think you want to do that? I suspect what you actually want to do is to merge your changes into the shared version | 19:57 |
| glyph | if you "run the shared version over" then any other people or other repositories which have changes in them that know about the current shared version will immediately make it diverge again | 19:58 |
| Lo-lan-do | benchik: Maybe you're looking for bzr push --overwrite (but as glyph says, it's evil) | 19:58 |
| glyph | Lo-lan-do: I was trying to avoid saying that until he explained that he actually wanted it ;) | 19:59 |
| benchik | glyph: because i think i got all the changes before. and today i updated the app, and it's the most recent update. also i think merging will be harder | 19:59 |
| Lo-lan-do | glyph: Evil is not patient. | 19:59 |
| glyph | benchik: you're wrong, you didn't get all the changes before. otherwise it wouldn't have diverged :) | 19:59 |
| glyph | benchik: merging is easy. | 19:59 |
| glyph | here's how you do it: | 19:59 |
| glyph | bzr merge | 19:59 |
| glyph | bzr ci -m "merged from shared" | 19:59 |
| glyph | bzr push | 19:59 |
| glyph | and besides, even if it's harder, it give you more pretty lines in 'bzr visualize' which is totally what you want | 20:00 |
| benchik | when i bzr merge i get: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 20:00 |
| Lo-lan-do | Totally | 20:00 |
| Lo-lan-do | bzr viz is just an intricate way of designing celtic knots | 20:01 |
| benchik | glyph: how do i resolve this error? | 20:01 |
| Lo-lan-do | I think someone's been evil before you had a chance to be. | 20:02 |
| benchik | Lo-lan-do: so what do i do now? | 20:02 |
| Lo-lan-do | Try to talk with your coworkers to understand where this situation comes from. | 20:03 |
| benchik | Lo-lan-do: no way on my side to merge? | 20:06 |
| Lo-lan-do | I have to admit I'm not enough of a guru to answer this one, and I'll leave you in some more capable hands. | 20:06 |
| benchik | ok | 20:09 |
| Lo-lan-do | Um. jelmer? Is is expected that a ./repository/git.tdb for a 80 MB repository eats more than 200 MB (and still growing)? | 20:59 |
| bzr_troubling | Hello... How can I verify which SVN version bzr is using ? | 21:00 |
| bzr_troubling | I'm getting the Svndiff too-large window, and I'm trying to verify if bzr is using my 1.6.5 version of the svn client... ( I have 1.4.4 and 1.6.5) | 21:01 |
| Lo-lan-do | Are you using a package from a distribution? | 21:02 |
| bzr_troubling | No.. I'm in MacOS X, Leopard | 21:02 |
| bzr_troubling | The package from SVN I got from Collabnet | 21:03 |
| Lo-lan-do | I think bzr-svn doesn't use the command-line svn client. | 21:03 |
| Lo-lan-do | It uses subvertpy, which, in turn, uses the SVN libraries. | 21:04 |
| bzr_troubling | But the libraries it uses are built-in bzr or it looks for the libraries in my computer ? | 21:05 |
| Lo-lan-do | I'm not familiar enough with MacOSX to be answer that question reliably, sorry. | 21:06 |
| bzr_troubling | Because the Svndiff too-large window bug was reported as a svn bug.. and I should upgrade my svn version.. | 21:06 |
| bzr_troubling | Ok, but still know a way to find out which version of the libraries ou binaries of SVN bzr uses ? | 21:06 |
| Lo-lan-do | Not really. On Linux I'd use strace, but that's low-level and I doubt it works on other kernels. | 21:07 |
| Lo-lan-do | You could move one version aside temporarily and see if the other still works :-) | 21:08 |
| bzr_troubling | hum, too bad. Is there a way to convert my bzr working copy to SVN only working copy ? That way I can check what's happening.. | 21:08 |
| Lo-lan-do | Not as far as I know. You could do an SVN checkout. | 21:09 |
| Lo-lan-do | I may be wrong though, I'm just not aware of another way. | 21:09 |
| bzr_troubling | Ok, I'm looking at the documentation.. maybe there's a tool for that. | 21:10 |
| bzr_troubling | Thank you very much Lo-lan-do | 21:10 |
| === oubiwann_ is now known as oubiwann | ||
| Magilum | I get this error trying to install bzr-svn from the ppa in Ubuntu Jaunty: bzr-svn: Depends: bzr (< 1.18~) but 1.18-1~bazaar1~jaunty1 is to be installed | 22:25 |
| poolie | hullo all | 23:13 |
| === Mez__ is now known as Mez | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
