| === mbp_ is now known as poolie | ||
| poolie | spiv, igc, i'm having some skype issues... | 00:05 |
|---|---|---|
| poolie | are you here? | 00:05 |
| rick_h__ | lifeless: ping | 00:11 |
| MatthewWilkes | Right 4 hours is enough. I may try again tomorrow | 00:35 |
| gdoubleu | Is there anything special you need to do when pushing a loomified branch? I pushed a loomified branch to launchpad from my laptop and then branched that onto another machine, but it didn't seem to have the threads. | 02:17 |
| gdoubleu | I have the bzr-loom plugin on both machines | 02:17 |
| Odd_Bloke | gdoubleu: Did you 'bzr record' first? | 02:20 |
| gdoubleu | i did not | 02:20 |
| Odd_Bloke | I think you need to. | 02:20 |
| Odd_Bloke | Though I don't really use looms, so am not sure. | 02:20 |
| gdoubleu | I'll try that and attempt to push again | 02:21 |
| mwhudson | how do i make a branch7 branch? | 03:24 |
| mwhudson | poolie, spiv? | 03:26 |
| mwhudson | oh, done | 03:27 |
| igc | hi all | 03:40 |
| igc | fyi, I'll be working on porting/testing fastimport to use the new Repository API today | 03:41 |
| igc | but I'll be offline for a few hours first - lunch & my daily hospital visit first | 03:41 |
| mwhudson | hey, can bzrlib.repofmt.pack_repo.RepositoryFormatPackDevelopment1 get a new name in bzr.dev really fast? | 04:31 |
| Odd_Bloke | mwhudson: Why? | 04:35 |
| mwhudson | well, because it's a terrible name | 04:35 |
| Odd_Bloke | What would you suggest instead? | 04:36 |
| thumper | SuperDuperFormat? | 04:36 |
| thumper | RockinFormat | 04:36 |
| mwhudson | not sure what the conventions are | 04:36 |
| Odd_Bloke | It'll be renamed to SuperDuperFormat or somesuch once it's actually that. | 04:36 |
| Odd_Bloke | But, ATM, it's a development format. | 04:37 |
| spiv | Something without "Development" would be nice, once it's no longer in Development. | 04:37 |
| mwhudson | well, i'm kinda hoping 1.6 is actually going to get released soon | 04:38 |
| Odd_Bloke | mwhudson: I think this format will be in development during the 1.6 cycle. | 04:38 |
| Odd_Bloke | s/1.6/1.7/ | 04:38 |
| Odd_Bloke | So will be renamed before 1.7 is released. | 04:38 |
| Odd_Bloke | So before then, users will only see it if they've opted-in to the use of a development format. | 04:40 |
| mwhudson | speaking as a launchpad developer, i really hope not :) | 04:45 |
| mwhudson | there's a difference between a development format and a non-default format, surely | 04:45 |
| Odd_Bloke | In what sense? | 04:48 |
| mwhudson | well, in the 'option name' sense | 04:49 |
| spiv | rich-root-pack is a non-default format that isn't a development format, for example. | 04:49 |
| Odd_Bloke | Well, it'll be hidden, I think. | 04:49 |
| Odd_Bloke | It certainly should be hidden... | 04:49 |
| spiv | i.e. the option for it is relatively non-scary, it isn't hidden, etc. Whereas I think the --stacked option on a branch isn't going to be hidden? | 04:50 |
| spiv | ISTR some discussion about it on the list. | 04:50 |
| === jamesh_ is now known as jamesh | ||
| poolie | mwhudson: i have a patch that makes it a stable format | 05:06 |
| mwhudson | poolie: excellent | 05:07 |
| mwhudson | how can i see things that are note()d or mutter()ed when prodding bzrlib interactively? | 05:11 |
| * mwhudson has vague memories of trace.enable_default_loggin()... | 05:11 | |
| poolie | like from a python interpreter | 05:11 |
| poolie | yes that should do it | 05:11 |
| gdoubleu | Odd_Bloke: about the pushing looms, it looks like it's not possible yet: https://bugs.launchpad.net/bzr-loom/+bug/201613 | 07:04 |
| ubottu | Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged] | 07:04 |
| mwhudson | i think that bug is actually mostly fixed | 07:09 |
| mwhudson | apart from the 'when do i need to record' confusion | 07:09 |
| * mwhudson wanders off | 07:10 | |
| stub | How do I turn off the bzr prompt thing that seems to have installed itself into /etc/bash_completion.d ? | 09:03 |
| tacone | boys, my bzr got locked, what to do ? --> Unable to obtain lock lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock | 09:08 |
| === stub1 is now known as stub | ||
| tacone | break-lock doesn't seem to work | 09:08 |
| tacone | bzr: ERROR: Unsupported protocol for url "lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock" | 09:09 |
| stub | Is it a bug that bzr has installed /etc/bash_completion.d/bzrbashprompt.sh (breaking my prompt), or is there some way I need to turn it off? | 09:09 |
| AfC | tacone: is that long number supposed to be there in the protocol? | 09:10 |
| AfC | /msg tacone Oh, just FYI, there are women here, too. | 09:10 |
| bob2 | stub: just have to rm it for now | 09:10 |
| tacone | girls, my bzr got locked :(. http://pastebin.com/m4a069b45 what to do ? | 09:11 |
| AfC | :) | 09:11 |
| spiv | stub: there is a bug report about that | 09:12 |
| AfC | tacone: maybe try `bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/` | 09:12 |
| * tacone is about to switch in scared-newbie-mode-on | 09:12 | |
| spiv | tacone: "bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/" | 09:12 |
| spiv | AfC: beat me :) | 09:12 |
| tacone | lol | 09:12 |
| AfC | spiv: Hooray! | 09:12 |
| stub | And then file a bug about the message that tells you to do different | 09:13 |
| spiv | stub: I'm just doing exactly that | 09:13 |
| tacone | worked | 09:14 |
| AfC | Terrific | 09:14 |
| tacone | I'll file a bug for that, thanks. | 09:14 |
| spiv | tacone: I just filed one | 09:16 |
| spiv | tacone: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/250451 | 09:17 |
| ubottu | Launchpad bug 250451 in launchpad-bazaar "bzr suggests wrong URL for break-lock with a LP hosted bra" [Undecided,New] | 09:17 |
| kiorky | why does bzr-svn not want to store my creds :S | 09:18 |
| tacone | spiv: oh god. I was about to click submit :-) | 09:20 |
| tacone | ok, trashed :-D | 09:21 |
| tacone | thanks you all. goodbye | 09:22 |
| jelmer | kiorky, it's not bzr-svn that doesn't store them | 09:43 |
| jelmer | kiorky, it's bzr itself | 09:44 |
| jelmer | kiorky, any chance you can file a bug about this? | 09:44 |
| lifeless | Jc2k: is the conduit guy around at the moment ? | 09:45 |
| Jc2k | lifeless: he is | 09:46 |
| lifeless | Jc2k: I have a few minutes before leaving for the train | 09:46 |
| lifeless | rick_h__: hi | 09:46 |
| Jc2k | lifeless: *tries to lure him on to gnome-bzr* | 09:46 |
| jelmer | 'morning lifeless | 09:47 |
| lifeless | ohi jelmer | 09:49 |
| kiorky | jelmer: yep, but i am at work, but sue i can when i l have time | 09:59 |
| kiorky | jelmer: maybe around 12:30, so 11:30 for u | 10:00 |
| jelmer | Thanks | 10:00 |
| kiorky | jelmer: describe me what u want as backtrace or tests and etc | 10:00 |
| jelmer | kiorky, just the fact that passwords aren't saved should be sufficient | 10:02 |
| blaudden | Hi, I'm running the "merge3-per-file" version of bzr and it just pops into "pdb" all the time. Can't see that it has any breakpoint set ot anything. Typing "cont" will run for a while and then stop at the same line again. Any advice? | 10:06 |
| jelmer | blaudden, Is that John Meinel's branch? | 10:07 |
| jelmer | You'd probably want to talk to him - he's around here as "jam" but it's probably too early for him right now | 10:08 |
| blaudden | yes, it looks like that from "bzr log" | 10:08 |
| blaudden | ok, i'll hang around. Thanks! | 10:08 |
| spiv | blaudden: presumably there's a "pdb.set_trace()" either in your branch of bzr, or perhaps in a plugin | 10:14 |
| spiv | blaudden: I'd try grepping for pdb in your branch of bzr and also in ~/.bazaar/plugins | 10:14 |
| spiv | If you do "bt" at the (pdb) prompt it should give an indication of where the pdb.set_trace() line is | 10:14 |
| blaudden | spiv: i'll try that. | 10:15 |
| blaudden | 850 import pdb; pdb.set_trace(); | 10:18 |
| blaudden | thanks! | 10:18 |
| spiv | blaudden: ta-da :) | 10:20 |
| poolie | hello | 10:25 |
| jelmer | spiv,poolie: Hallo! | 10:26 |
| rick_h__ | lifeless: still around? | 10:50 |
| lifeless | rick_h__: yes, going v soon though to start travelling home | 10:53 |
| rick_h__ | lifeless: cool, have a good trip then | 10:54 |
| rick_h__ | just wanted to try to get this repo/branch thing right in my head | 10:54 |
| lifeless | ok | 10:54 |
| rick_h__ | check that "commiting to the repo" "add files to the repo" were good | 10:54 |
| rick_h__ | and that creating a branch, and serving out the branch were right | 10:54 |
| rick_h__ | the docs with the shared repository for multiple branches seemed to make some sense | 10:55 |
| rick_h__ | I've just never set it up that way so repo == branch for appearance | 10:56 |
| lifeless | yeah | 10:56 |
| lifeless | branch is the user abstraction people work with | 10:56 |
| lifeless | there is always a repository for abranch, its implicitly created if no explicit one was made by the user | 10:57 |
| rick_h__ | so should I also commit your changes to the branch then? | 10:57 |
| rick_h__ | and the only time really refer to the repository is if setting up a shared one? | 10:57 |
| lifeless | yup | 10:57 |
| spiv | jelmer: hey | 10:58 |
| rick_h__ | ok, sounds like a plan then | 10:58 |
| lifeless | the tip of a branch is the latest revision | 10:58 |
| lifeless | a branch has a tip, tags, and configuration details | 10:58 |
| rick_h__ | yea, that comment in that article threw me a bit, but I found some of the docs that seemed to clear it up more | 10:58 |
| spiv | jelmer: how soon will bzr-svn be faster (the "find_tags is slow" bug)? :) | 10:58 |
| rick_h__ | well have a nice trip lifeless and hopefully this article will be life in Oct and then I can bug you on some more advanced stuff :) | 10:59 |
| lifeless | sure thing | 11:00 |
| jelmer | spiv: couple of days hopefully | 11:25 |
| Peng_ | With one slow and large svn repository, bzr-svn spends a massive amount of time crawling the whole thing for tags even when I do a no-op "pull", and even though the branch I actually have checked out is quite tiny. | 11:44 |
| jelmer | Peng, there's an open bug about this | 11:44 |
| Peng_ | Okay. Well, if you want an example branch, http://software.inl.fr/svn/mirror/tools/ipy/trunk (but I didn't try to reproduce it; I don't feel good about abusing random svn servers to test things). | 11:46 |
| jelmer | Peng_, Thanks for reporting this. It'll hopefully be fixed in a couple of days | 11:46 |
| jelmer | (see also spivs comments a couple of lines back) | 11:47 |
| Peng_ | Yeah, since the subject had been brought up, I just wanted to mention it. | 11:47 |
| kiorky | jelmer: uhm i have another problem, i have a bzr+qsvn branch, then i rebranch locally, but it trys to acces the foreign repo. Why ? | 13:05 |
| kiorky | jelmer: the work connection is pretty bad, soi like to work offline :) | 13:06 |
| trepca | hey | 13:09 |
| jelmer | kiorky, hi | 13:49 |
| jelmer | kiorky, I suspect you don't have an actual local branch but just a local working tree | 13:50 |
| jelmer | kiorky: E.g. "svn co" will not create a local branch | 13:50 |
| kiorky | jelmer: i used bzr branch svn+http://svncred:pass@foo | 14:07 |
| kiorky | jelmer: then bzr branch ../path | 14:07 |
| jelmer | kiorky: Where ../path was created with "bzr branch" ? | 14:08 |
| kiorky | the first yes : "bzr branch svn+http://svncred:pass@foo" | 14:08 |
| jelmer | not "bzr co" ? | 14:08 |
| kiorky | nope | 14:08 |
| jelmer | if that created "foo" then "bzr branch foo bla" should not access the network | 14:09 |
| kiorky | i can redo it to double check | 14:09 |
| kiorky | let me a minute | 14:09 |
| === mw|out is now known as mw | ||
| kiorky | jelmer: ~>bzr branch foo bar | 14:11 |
| kiorky | <https://subversion.makina-corpus.net:443> Login LDAP Makina Corpus mpa password: | 14:11 |
| kiorky | jelmer: :) | 14:11 |
| kiorky | which a fresh bzr branch svn+... | 14:12 |
| kiorky | (in foo) | 14:12 |
| nevans | bug in bzr-svn relating to checkouts: https://bugs.launchpad.net/bugs/248289 | 15:50 |
| ubottu | Launchpad bug 248289 in bzr-svn "concurrent access problems" [Undecided,New] | 15:50 |
| nevans | It seems that bzr will try to lock the checked-out branch during a bound branch's commit... | 15:50 |
| nevans | but it can't lock an svn "branch", so it winds up rewinding history on the svn repo. :-( | 15:51 |
| nevans | I didn't even notice this had happened until recently... apparently I've done it four times in the last six months... | 15:53 |
| nevans | s/done it/triggered this bug/ | 15:53 |
| === NfNitLoo` is now known as NfNitLoop | ||
| pickscrape | Is there something in bzrlib that I can use to list files in a remote directory? I'm specifically talking about a non-branch directory (e.g. a directory that might contain branches) | 16:28 |
| * pickscrape looks at bzrlib.transport | 16:30 | |
| === pmatulis is now known as pmatulis_afk | ||
| james_w | pickscrape: there is listdir(), but it doesn't work over http | 16:34 |
| pickscrape | james_w: I've got transport's list_dir working very nicely over bzr+ssh, thanks! | 16:36 |
| === mw is now known as mw|brb | ||
| bpeterson | Bazaar can use a variety of different libraries for http, correct? | 16:46 |
| luks | where 'variety' == two | 16:47 |
| bpeterson | urllib and pycurl? | 16:47 |
| luks | but I think plain urllib2 is now the prefered one | 16:47 |
| luks | yes | 16:47 |
| bpeterson | is one faster than the other? | 16:48 |
| luks | faster in what way? | 16:48 |
| luks | even if one is faster than the other, it won't be noticable | 16:48 |
| luks | network will be limiting them, not CPU | 16:49 |
| bpeterson | it's just that bzr over http seems quite slow to me | 16:49 |
| luks | bzr is slow over http | 16:49 |
| luks | or generally, bzr is slow :) | 16:49 |
| bpeterson | especially with networking | 16:49 |
| james_w | bpeterson: slower than what? | 16:49 |
| bpeterson | hg | 16:49 |
| bpeterson | I still use Bazaar because st, diffing, and committing are pretty snappy, but not networking... | 16:50 |
| luks | what format are you using? | 16:50 |
| luks | (bzr info) | 16:50 |
| bpeterson | rich-root-pack | 16:51 |
| luks | ah, not much you can do, I'm afraid | 16:51 |
| bpeterson | is rich-root-pack a comprise for space over something else? | 16:52 |
| radix | bpeterson: I think what he means is that the pack-based formats are the most efficient formats right now, so there's nothing better for you to upgrade to for better performance over HTTP | 16:53 |
| james_w | bpeterson: static-http for hg? | 16:53 |
| bpeterson | yep | 16:53 |
| nevans | how does sftp compare to http for performance? | 16:55 |
| nevans | still the same bottleneck? | 16:55 |
| bpeterson | actually I'm more concerned with performance over bzr+ssh | 16:56 |
| fullermd | No, I think sftp has all different bottlenecks :) | 16:56 |
| fullermd | I'm pretty sure sftp eats more round trips, so it's probably a bit more latency sensitive. | 16:57 |
| bpeterson | it's over ssh, so shouldn't have state? | 16:57 |
| === mw|brb is now known as mw | ||
| fullermd | Well, bzr+ssh is a totally different beast from either, so... | 16:57 |
| bpeterson | mm | 16:58 |
| === pmatulis_afk is now known as pmatulis | ||
| nevans | I think it must depend a lot on various factors (e.g. size of your repo). I just did some tests on a very small branch of mine... and bzr+ssh actually went slower than http. | 16:59 |
| nevans | probably because it has additional overhead of ssh connection and starting up bzr on the remote end | 17:00 |
| bpeterson | I'm working with the Python core bzr repo; ~200 MB | 17:00 |
| LeoNerd | 'bzr st' still claims a pending merge, even though I've shelved it away for now... How might I clear that? | 17:34 |
| LeoNerd | In actual fact I probably want to just revert it, but I'm keeping it shelved for now | 17:35 |
| bpeterson | LeoNerd: bzr resolve | 17:35 |
| luks | bzr revert --forget-merges | 17:35 |
| LeoNerd | Ah yes; the latter did it | 17:35 |
| LeoNerd | bpeterson: isn't that for conflicts? | 17:35 |
| bpeterson | yes, never mind | 17:35 |
| bialix | luks: hi | 17:40 |
| luks | hey | 17:40 |
| bialix | good evening | 17:40 |
| bialix | luks, Garyvdm was very helpful in fixing regressions | 17:41 |
| bialix | I think we are ready to release 0.9.2 | 17:41 |
| luks | I haven't followed the latest fixes | 17:41 |
| bialix | I'm planing to prepare some screenshots with new features | 17:41 |
| luks | but the current state is usable for me | 17:41 |
| bialix | me and Gary have fixed all known (for me) regressions so far | 17:42 |
| pickscrape | Does anyone know what happened to the bzr gentoo overlay? | 17:43 |
| bialix | luks: so I'm about to starting release process tonight or tomorrow | 17:43 |
| luks | cool, thanks a lot | 17:43 |
| luks | I've uploaded translations to launchpad, still waiting for review :( | 17:44 |
| bialix | I saw. | 17:44 |
| bialix | I'm confused because I could cange status of some translations | 17:44 |
| bialix | I'm confused because I could change status of some translations | 17:44 |
| bialix | I won't wait for translations and don't want to delay release | 17:45 |
| bialix | but if you wanna to update sk.po I'll wait | 17:45 |
| bialix | pickscrape: what's up with Gentoo? | 17:45 |
| pickscrape | Well, I added the overlay a while back to layman, which set it up as a bzr branch that it would pull | 17:47 |
| pickscrape | But lately it seems that the branch it pointed at has gone away. | 17:47 |
| pickscrape | Wondering if it has died or just been moved somewhere else. | 17:47 |
| bialix | luks, I can't create deb for linux. But it will be nice to have it for 0.9.2. This release will be a bomb | 17:47 |
| luks | bialix: umm, I might do it | 17:48 |
| luks | but I actually wanted to get rid of the PPA | 17:48 |
| luks | it's easy to install it on linux | 17:48 |
| bialix | well, I'm fine either way | 17:48 |
| bialix | if you will close PPA, then I'll just need to update our wiki page properly | 17:49 |
| luks | I did :) | 17:49 |
| luks | or do you mean more than removing it from there? | 17:49 |
| pickscrape | Is bzr-gtk no longer going to be in the bzr PPA then? | 17:49 |
| luks | this is about qbzr | 17:50 |
| pickscrape | oic | 17:50 |
| bialix | pickscrape: I'm actually using Windows, but I saw this: https://launchpad.net/bzr-gentoo-overlay May be it helps you | 17:50 |
| pickscrape | bialix: thanks, I just found that myself. I think they might have moved it, so I'm setting it up again to find out... | 17:51 |
| bialix | luks: I mean this: https://launchpad.net/~luks/+archive | 17:51 |
| bialix | I don't know PPA well, so maybe presence of 0.9.0 confused me a bit | 17:51 |
| luks | let me see if I can remove 0.9.0 from there | 17:52 |
| bialix | ok. I'm just wanted to check this with you | 17:52 |
| luks | I'll probably build 0.9.2 after the release | 17:53 |
| luks | but in a ~qbzr-dev PPA | 17:53 |
| bialix | ah, ok. make sense | 17:53 |
| chadmiller | Hi. I work in a project that makes a lot of tags. |wc -l says "320". This brings into relief that tagging in bzr is kind of weird. | 17:56 |
| LeoNerd | A tag is just a human-readable "friendly" name for a revision... same as a hostname is just a friendly name for an IP address | 17:57 |
| jam | chadmiller: How are you using tags, and how is it a bit weird in bzr? | 18:00 |
| jam | (eg, care to elaborate?) | 18:00 |
| jam | You might be using branches for tags, which is an older way that is certainly clumsier | 18:00 |
| chadmiller | Consider this morning: Tim noticed that some tag was on the wrong revision. He used "bzr tag --delete", "bzr tag", "bzr push" to change it. Paul comes along and, on pull, gets "Conflicting tags:\n\tblah-blah". This concerns Paul. He's questions whether his tree is valid, completed "pull" correctly, et c. | 18:01 |
| jam | chadmiller: well, tim could have used "bzr tag --force" but sure | 18:02 |
| chadmiller | He can't tell very much with "missing" or "log". | 18:02 |
| jam | The problem is that tags aren't versioned | 18:03 |
| jam | so when they disagree | 18:03 |
| jam | we don't know which one is "more correct" | 18:03 |
| chadmiller | Right. | 18:03 |
| jam | we've had some long discussions about it | 18:03 |
| jam | it is hard to do better without introducing a whole lot of "meta" overhead | 18:03 |
| jam | chadmiller: is there some ui polish we could apply to make it a bit more understandable? | 18:04 |
| chadmiller | I think my biggest problem with it is informational. Maybe the "Conflicting tags" message should also have "Don't Panic" in warm, friendly letters. | 18:06 |
| jam | Conflicting tags: <3 <3 | 18:08 |
| jam | Something like that? | 18:08 |
| Jc2k | now it sounds like bzr is enjoying your suffering | 18:08 |
| bpeterson | perhaps provide a bzr tag --rename command? | 18:09 |
| bpeterson | or document that you should use bzr tag --force if you want to rename | 18:09 |
| bpeterson | here, I'll send you a bundle | 18:10 |
| jam | bpeterson: "bzr help tag" | 18:11 |
| jam | --force Replace existing tags. | 18:11 |
| jam | But if it is missing in other documentation, feel free :) | 18:11 |
| jam | also, '--rename' sounds like it would change the name of the tag (but point to the same revision) | 18:12 |
| jam | which isn't the same as pointing the same name to a different revision | 18:12 |
| chadmiller | :) "Your $(verb)s completed, but upstream disagrees about which revisions these tags should appear on. Your tags were not updated. Conflicts:\n" | 18:12 |
| bpeterson | isnt' that what chadmiller wanted? | 18:12 |
| chadmiller | "%", not "$", grr. | 18:12 |
| jam | chadmiller: well, probably 'not all tags were updated" | 18:12 |
| jam | but I understand | 18:12 |
| chadmiller | Something in the "tag{,s} --help" about resolving those would be good too. | 18:13 |
| chadmiller | And "bzr pull --clobber-local-tags" ? | 18:15 |
| bpeterson | so if you want to rename a tag (change the name, but keep it on the same revision), you should bzr tag --delete name and bzr tag --force name | 18:15 |
| bpeterson | ? | 18:15 |
| pickscrape | We actually encountered exactly this this mornin g | 18:15 |
| jam | bpeterson: I would do "bzr tag new-name -r tag:oldname" | 18:15 |
| jam | and then "bzr tag --delete oldname" if you prefer | 18:15 |
| pickscrape | A colleague changed a tag, and when I tried to pull I got the 'conflicting' message | 18:15 |
| jam | but deleting tags doesn't propagate at the moment.. | 18:15 |
| pickscrape | The solution was for me to redefine the tag at my end, after that pull worked. | 18:16 |
| pickscrape | The problem is, I didn't know (other than talking to him myself) what revision he had changed it to | 18:17 |
| jam | pickscrape: I *think* you can also "pull --overwrite" but I'm not 100% sure. | 18:17 |
| jam | pickscrape: bzr log -r tag:NAME path/to/his/branch | 18:17 |
| pickscrape | jam: I was worried about --overwrite clobbering my local changes | 18:18 |
| jam | or 'bzr tags -d /path/to/his/branch" | 18:18 |
| pickscrape | It would have been good if the message had told me which revision the tag was defined as upstream | 18:18 |
| bpeterson | uhh. that new launchpad ui sure gets me | 18:24 |
| === mario_ is now known as pygi | ||
| trepca | is there anyway to save my password for HTTP auth | 18:52 |
| trepca | it's a pain typing it every time | 18:52 |
| trepca | even worse ... it asks me several time | 18:52 |
| chadmiller | Uhm, is the ppa "bzr-beta-ppa" a likely candidate for the real release? | 19:04 |
| chadmiller | There's some serious evil in there. | 19:05 |
| jam | Care to list specific evil? | 19:05 |
| jam | I know poolie plans a couple changes before an rc1 | 19:05 |
| chadmiller | etc/bash_completion.d/bzrbashprompt.sh . 1) clobbering $PS1. 2a) running a python interpreter twice for every shell prompt. 2b) running /bzr/ twice for every shell prompt. | 19:06 |
| jam | chadmiller: ah, that is planned to be fixed | 19:07 |
| jam | we weren't meant to install that file | 19:07 |
| jam | it is a packaging issue | 19:07 |
| chadmiller | Whew! Okay, good. | 19:07 |
| jam | in the short term you can just rm that one | 19:07 |
| radix | that reminds me of when I installed git-core and it installed a bash completion file which ran git twice | 19:08 |
| radix | unfortunately, there's another program I have installed in ~/bin called "git", which is an interactive fiction interpreter for Glulx games | 19:08 |
| radix | so every time I started a new terminal two GUI windows would pop up and give an error message | 19:09 |
| === mw is now known as mw|food | ||
| jam | radix: at least it wasn't on every \t :) | 19:11 |
| radix | heh, yeah | 19:11 |
| pickscrape | I'm writing a plugin for internal use that provides a main command with subcommands (shelf-style) | 19:34 |
| pickscrape | it's been going well, but I'm now having a problem adding options to the subcommands | 19:35 |
| pickscrape | It seems that bzrlib is trying to parse them as part of the main command, and complaining that it doesn't have the option | 19:35 |
| pickscrape | I suppose this is because subcommands are a bit of a hack, bit I'm wondering if anyone knows of a workaround | 19:36 |
| LarstiQ | pickscrape: ah, you're overloading short options that already exist in bzr? | 19:37 |
| LarstiQ | pickscrape: oh no, I see now. | 19:37 |
| LarstiQ | pickscrape: well, as a hacky workaround, combine the main command's options from the subcommand options? | 19:38 |
| pickscrape | LarstiQ: I was just going to try that. It might work, the only problem being the options would show up againt the main command in the help output. I will give it a try though | 19:38 |
| LarstiQ | pickscrape: yeah | 19:43 |
| james_w | pickscrape: you may be able to write a subclass of Command that works better with subcommands | 19:46 |
| pickscrape | james_w: I thought I'd find that when I originally looked at the shelf code, but didn't. Now that I've hit this obstacle I think I might revisit that idea again :) | 19:47 |
| james_w | it would be a useful thing to have in the core for other plugins to make use of, e.g. shelve | 19:47 |
| pickscrape | Yes, I was thinking that too. If I get one working I'll see about making it available to bzr. Thing is, nothing in bzrlib would actually need it right now. | 19:48 |
| LarstiQ | pickscrape: but because it isn't there, no one feels invited to use it :) | 19:49 |
| pickscrape | chicken/egg :) | 19:49 |
| pickscrape | My concern is more related to testing/bitrot: if it gets added but not used etc... | 19:49 |
| LarstiQ | pickscrape: right, I see. | 19:49 |
| pickscrape | I suppose shelf could keep it happy though if it was migrated to use it. | 19:50 |
| LarstiQ | pickscrape: if there are two plugins using it though, I think the use part is reasonably covered. For it to be accepted into core it needs to be fully covered with tests anyhow. | 19:50 |
| * LarstiQ nods | 19:50 | |
| pickscrape | Hmm, on that idea, perhaps it would be better added to bzrtools initially, and then to core once stable etc? | 19:51 |
| === mw|food is now known as mw | ||
| Gilgad13 | if i want to move an entire directory that is versioned, how would i do so? i've tried "bzr mv oldDir path\to\newDir" but i get an error that newDir is not versioned. Do I have to create and add newDir first? Is it possible to move whole directories? | 20:04 |
| Gilgad13 | i'm using windows, if it matters | 20:04 |
| pickscrape | Is newdir inside the same branch as the directory you're moving? | 20:05 |
| Gilgad13 | yes, its executed exactly like that, ie. both paths are relative | 20:06 |
| LarstiQ | Gilgad13: is path\to\ versioned? | 20:06 |
| pickscrape | Does path\to already exist and versioned? | 20:06 |
| Gilgad13 | no, should it be? | 20:06 |
| pickscrape | Gilgad13: yes | 20:06 |
| LarstiQ | Gilgad13: I'd think so. | 20:06 |
| Gilgad13 | hang on... | 20:07 |
| james_w | is there a typo in oldDir | 20:07 |
| james_w | I think if that is the case it complains about the wrong thing | 20:07 |
| Gilgad13 | no, versioning path\to worked | 20:07 |
| Gilgad13 | and an obvious next question. can I undo a specific move, without reverting to last commit? | 20:09 |
| Gilgad13 | no handy undo-last? | 20:18 |
| pickscrape | bzr uncommit will undo your last commit, but it will cause problems if the commit has been published elsewhere | 20:19 |
| Gilgad13 | i'm talking about operations between commits, like complex reorg's with multiple moves. Right now i either bzr revert or move the moved file | 20:20 |
| pickscrape | Oh. I think revert should do what you need it to | 20:20 |
| Gilgad13 | but it would be nice to have the safety net | 20:20 |
| Gilgad13 | well, if i'm like 4 move's in, it would suck to redo them because of a typo | 20:21 |
| LarstiQ | Gilgad13: if it's really complex there is no silver bullet. | 20:21 |
| pickscrape | revert won't undo only the last move I don't think | 20:21 |
| Gilgad13 | damn, i like silver bullets | 20:21 |
| pickscrape | AFAIK it just looks at the WC picture as a whole. | 20:21 |
| Gilgad13 | pickscrape: exactly | 20:21 |
| Gilgad13 | so i'd have to start over | 20:21 |
| LarstiQ | starting over doesn't seem like the way to go? | 20:22 |
| pickscrape | Could you just bzr mv the file back again? | 20:22 |
| LarstiQ | Gilgad13: but I don't have a clear enough picture of your situation to really give advice. | 20:22 |
| Gilgad13 | pickscrape: its what i've been doing | 20:22 |
| james_w | you can "bzr mv" back, and "revert path" would probably do it, but obviously would do the wrong thing if the files were modified as well | 20:22 |
| Gilgad13 | LarstiQ: its mostly hypethetical, so no worries | 20:22 |
| LarstiQ | Gilgad13: are you looking for a revert that only undoes treeshape changes, not content changes? | 20:23 |
| Gilgad13 | LarstiQ: yes, and if possible lets me select specific changes | 20:23 |
| LarstiQ | problem with that being creating a tree state that never existed in history, but yes. | 20:23 |
| LarstiQ | Gilgad13: what do you mean exactly? 'bzr revert -r a..b path/' wouldn't be enough? | 20:24 |
| Gilgad13 | having experimented more, i think its a mental problem with how i thought bzr recorded moves | 20:26 |
| Gilgad13 | as in, i thought the recorded a log of actions, but i now see that only the beginning (ie, last commit) and end(now) state matter, not how many moves were applied inbetween | 20:26 |
| Gilgad13 | s/the/bzr in first line | 20:27 |
| LarstiQ | Gilgad13: ah, indeed. | 20:27 |
| pickscrape | LarstiQ: I may be jumping the gun a bit here, but it looks like the only change needed to get subcommands working properly is to call parser.disable_interspersed_args() in _parse_args after retrieving it | 20:42 |
| pickscrape | Sorry, parse_args | 20:43 |
| pickscrape | (I moved it into a local subclass and called it _parse_args.) | 20:43 |
| pickscrape | So if that was moved into the Command class itself, a simple switch could potentially allow subcommands with options to function. | 20:43 |
| pickscrape | Hopefully I didn't make any other changes that I forgot to take into account here... | 20:44 |
| pickscrape | In fact, simply adding that right into bzrlib appears to make everything work, and doesn't appear to break anything else. | 21:06 |
| * pickscrape goes off to run the bzr unit tests for the first time ever :) | 21:06 | |
| pickscrape | Yeah, it does break some things. :) This is what tests are for.,.. | 21:15 |
| lifeless | Gilgad13: you can 'bzr revert FILENAME' | 21:36 |
| Gilgad13 | aye, but what would that do with regards to moves? unmove them? | 21:36 |
| Gilgad13 | revert content changes? | 21:37 |
| meatballhat | are transparent checkouts from svn supposed to 'just work'? | 21:38 |
| lifeless | Gilgad13: it would put the path back and revert content changes; I think there i sroom for a --path-only flag or something | 21:48 |
| lifeless | meatballhat: yes, though you can't pull or merge into a an actual svn tree | 21:48 |
| lifeless | meatballhat: ((ecause svn can't add revisions without doing a commit to a branch) | 21:49 |
| meatballhat | lifeless: so there is nothing akin to the 'git-svn' interface, or do I misunderstand? :) | 21:56 |
| lifeless | meatballhat: you misunderstand | 21:57 |
| lifeless | meatballhat: 'svn co svn://... foo && cd foo && bzr merge bzr://...' -> FAIL (the .svn directory is not capable of representing a pending merge) | 21:57 |
| lifeless | meatballhat: 'bzr branch svn://... foo && cd foo && bzr merge bzr://... && bzr commit && bzr push svn://...' -> WIN | 21:58 |
| meatballhat | lifeless: so I use bzr <command> with 'svn://' urls? or are you only explaining the workflow? | 21:59 |
| meatballhat | rather, is the use case documented for "I'm at work and my company uses Subversion, but I'd like to interface with it using Bzr" ? :) | 22:00 |
| lifeless | meatballhat: I think its documented on the FAQ | 22:03 |
| lifeless | meatballhat: and yes, you use svn urls with bzr | 22:03 |
| meatballhat | lifeless: thanks much! | 22:04 |
| wingo--tp | what's robert collins' nick? any idea why he hasn't definitively commented on https://bugs.launchpad.net/bzr/+bug/239499 ? | 22:17 |
| ubottu | Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed] | 22:17 |
| lifeless | wingo--tp: that would be me | 22:19 |
| wingo--tp | ah hello good sir! | 22:19 |
| lifeless | wingo--tp: I've been travelling for the last two weeks; kind of fragments things | 22:19 |
| wingo--tp | ah ok | 22:19 |
| wingo--tp | i'll wait then :) | 22:19 |
| * wingo--tp just got back to a normal rhythm, post-guadec | 22:19 | |
| lifeless | yah, I had a distro sprint post guadec, then LRL | 22:20 |
| lifeless | currently in an airport | 22:20 |
| wingo--tp | yowsers | 22:20 |
| thumper | lifeless: what is LRL? | 22:23 |
| lifeless | thumper: lug radio live | 22:23 |
| thumper | ah | 22:23 |
| jam | lifeless: I thought it might be something like "Living Real Life", but I was pretty sure you don't do that :) | 22:42 |
| * lifeless gestures | 22:42 | |
| lifeless | jam: what do you think of the marks rfc? | 22:45 |
| jam | lifeless: I think it could be really neat, as long as it doesn't get too complex for the user | 23:01 |
| jam | the hunk-level support is interesting | 23:01 |
| jam | I'm not sure how we would layer it in for stuff like 'commit', though I'm sure it is possible | 23:02 |
| jam | I guess it could just be a MarksTree(WorkingTree) | 23:02 |
| jam | lifeless: I was just looking over your testresources code, aren't you being naughty and iterating over a dictionary you are mutating? | 23:03 |
| jam | Or is that strictly allowed with your priorityDictionary | 23:03 |
| poolie | jam, hello | 23:04 |
| jam | hi poolie, ready for a call? | 23:04 |
| poolie | yes, does skype suit you | 23:05 |
| lifeless | jam: I don't recall; its nearly entirely paged out | 23:05 |
| jam | lifeless: no problem, looking closer it seems to be the way it is designed | 23:05 |
| jam | poolie: skype is fine | 23:05 |
| jam | lifeless: sorry to hear about your flight being delayed, are you on your way back to AU? | 23:06 |
| lifeless | yes | 23:06 |
| lifeless | jam: I think marks should be core | 23:06 |
| lifeless | poolie has said hes concerned by that :) | 23:06 |
| lifeless | I just think its likely to need to be pretty fundamental to work well and consistently | 23:07 |
| jam | lifeless: I think marks is hooking into a lot of places, so it would end up decorating a lot of commands | 23:07 |
| jam | status/diff at a minimum | 23:07 |
| lifeless | jam: yah | 23:07 |
| jam | commit | 23:07 |
| poolie | i was imagining a decorator type object too | 23:07 |
| jam | I'm not sure about update | 23:07 |
| lifeless | so I'm thinking a WT5 tree; with methods to get a flavour view | 23:07 |
| jam | poolie: yeah, even if it was "WT.get_view('xxx') which returned ViewTree(self) | 23:08 |
| poolie | i don't really necessarily mind it being in the core as long | 23:08 |
| lifeless | or even just change the view on the main object | 23:08 |
| poolie | something about that mail worried me on first reading | 23:08 |
| poolie | i would hope that we can work out a way to eg make a ViewTree rather than patching things all over the place | 23:08 |
| lifeless | lets not use the term view here | 23:09 |
| lifeless | views are Ian's partial-files-on-disk project | 23:09 |
| lifeless | which has some overlap but is different | 23:09 |
| jam | lifeless: well, MarksTree is a bit clumsy, but something like that | 23:09 |
| jam | sure | 23:09 |
| lifeless | (I realise I used the term view above; naughty robert :)) | 23:09 |
| poolie | it would also be nice to support | 23:10 |
| poolie | commit --interactive | 23:10 |
| poolie | which would ask which files or hunks to commit | 23:10 |
| lifeless | jam: one way is to decorate a WT; another is to alter the behaviour of the WT itself | 23:10 |
| lifeless | poolie: yes, bzr-interactive does this already | 23:10 |
| poolie | and this might want to create a transient in-memory view just for that one command | 23:10 |
| poolie | oh, nice | 23:10 |
| lifeless | poolie: and I think I proposed a way to do that in the thread using marks | 23:10 |
| jam | lifeless: sure, though I think doing it with a decorator is a bit better separation of concern | 23:10 |
| jam | but as long as it is tasteful, either way is fine | 23:10 |
| lifeless | merge needs to preserve marks for instance | 23:11 |
| lifeless | indeed tree transform needs to know | 23:11 |
| lifeless | though perhaps a lookaside structure will work | 23:14 |
| bud3030_ | Hi Bzr I have a 2nd pc with hardy on it I wen to change passwd under preference now the new and old want auth. | 23:14 |
| bud3030_ | If there is not a fix that mean a clean install | 23:16 |
| lifeless | what protocol are you using with bzr? | 23:17 |
| jam | lifeless: do we have any way of creating branching/merging history without creating a real tree on disk? | 23:18 |
| jam | BranchBuilder and MemoryTree don't really seem to offer that functionality | 23:18 |
| lifeless | jam: they both do, but at quite a low level, not by calling merge() | 23:20 |
| jam | lifeless: how do you create the second branch? | 23:20 |
| jam | BranchBuilder only has 'build_commit' | 23:21 |
| jam | and never exposes its tree | 23:21 |
| lifeless | oh hmm; remember tired :) I'm sure MemoryTree supports set_parent_ids | 23:21 |
| lifeless | BranchBBuilder though I dunno | 23:21 |
| jam | ah, I guess | 23:21 |
| jam | I guess I could do the 1 MemoryTree and use uncommit, etc to move it around | 23:22 |
| jam | I'll try it | 23:22 |
| jam | Though I guess I also need to create files in the tree | 23:22 |
| jam | which is difficult with MemoryTree ... :( | 23:22 |
| jam | oh, I guess you have put_file_bytes... | 23:22 |
| lifeless | right | 23:23 |
| lifeless | its why it exists :P | 23:23 |
| jam | but it requires a file_id | 23:23 |
| jam | which is a bit odd for creating a new file | 23:23 |
| lifeless | yes, which add gives you | 23:23 |
| lifeless | add([foo], [fooid], [file]) | 23:23 |
| jam | so you just "add(['foo']" even though foo doesn't actual exist? | 23:23 |
| lifeless | put_file_bytes(fooid, content) | 23:23 |
| jam | _add you mean? | 23:23 |
| lifeless | public add | 23:23 |
| jam | ah, and by passing the kinds it shortcuts '_gather_kinds' | 23:24 |
| jam | ok | 23:24 |
| lifeless | could you eyeball https://bugs.launchpad.net/bugs/250514 please | 23:25 |
| ubottu | Launchpad bug 250514 in bzr-email "bzr-email fails to send via a gmail tls smtp connection (needs ehlo cmd)" [Undecided,New] | 23:25 |
| jam | lifeless: I thought we already had a proper patch for that a while ago | 23:29 |
| jam | maybe it just didn't make it into trunk? | 23:29 |
| lifeless | >< | 23:30 |
| jam | jamesh: ^^ Didn't you work up a proper "resend ehlo after starting tls" ? | 23:30 |
| jam | lifeless: ah, it is the one in bzrlib which is fixed | 23:31 |
| jam | And for some reason the 'email' plugin doesn't use the one in bzrlib | 23:31 |
| lifeless | I thought it had been patched to do so :( | 23:31 |
| jam | lifeless: well, it is parameterized | 23:32 |
| jam | so it looks easy to do so | 23:32 |
| jam | but for some reason, I don't see a "from bzrlib import XXX" | 23:32 |
| lifeless | weird | 23:33 |
| jam | lifeless: I uploaded a simple patch on it | 23:34 |
| lifeless | jam: thanks | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!