| tolstoy | bob2: I actually does push the tags, though. | 00:00 |
|---|---|---|
| tolstoy | If I do a branch, they show up. | 00:00 |
| tolstoy | Pull doesn't pull them, it seems. | 00:00 |
| bob2 | oh | 00:00 |
| tolstoy | Yes, it's odd. | 00:01 |
| * lifeless repeats it | 00:01 | |
| lifeless | you know what sucks | 00:01 |
| tolstoy | If I do a tag, and the push, I get the "No revisions to push." | 00:01 |
| lifeless | I can't find a good clean reusable B/B+ index for python | 00:01 |
| tolstoy | But it still pushes the tags. | 00:01 |
| lifeless | all the 'pure python' databases are either csv, the moral equivalent of csv, or dbm | 00:01 |
| lifeless | NIH time | 00:01 |
| * beuno goes clean up the revision mess | 00:01 | |
| bob2 | tdb + ctypes! | 00:02 |
| lifeless | beuno: tdb wants more file system semantics than we offer | 00:03 |
| lifeless | s/beuno/bob2 | 00:03 |
| bob2 | ah, remote, right | 00:03 |
| lifeless | bob2: which is the problem with dbm too | 00:04 |
| jml | what does one need to provide to have a fully functional TestCaseWithTransport subclass? | 00:04 |
| lifeless | I went on a code search trying to find a python index module that was, well, modular. | 00:04 |
| lifeless | no such freaking luck | 00:04 |
| lifeless | jml: class foo(TestCaseWithTransport): def test_me(self): pass | 00:04 |
| beuno | mwhudson, do you have a copy of loggerhead before I pushed 173? I'm not sure how to get them back as left-hand history | 00:05 |
| jml | lifeless: in particular, I would like to be able to use make_branch. | 00:05 |
| tethridge | anybody know the size of the mysql repository? | 00:05 |
| jelmer | re | 00:05 |
| jml | When I do, I am told: AttributeError: 'TestFoo' object has no attribute '_TestCaseWithMemoryTransport__server' | 00:05 |
| mwhudson | beuno: bzr pull -r some.dotted.revno . --overwrite probably? | 00:06 |
| lifeless | jml: you have replaced setUp() and not called it | 00:06 |
| jml | well spotted. | 00:06 |
| lifeless | tethridge: 300MB I think. or maybe its 500MB. | 00:07 |
| lifeless | jam: ^ | 00:07 |
| jelmer | awilkins, still there? | 00:07 |
| awilkins | jelmer: Yes | 00:07 |
| lifeless | back in 45 or so. | 00:07 |
| jelmer | awilkins, any luck? | 00:07 |
| awilkins | jelmer: I've reduced the size of that error log a lot, but still plenty of problems | 00:07 |
| lifeless | Jc2k: did you file bugs? please say yes :P - and feel free to subscribe me to them | 00:07 |
| tethridge | lifeless, nice | 00:08 |
| awilkins | jelmer: Library discovery is really crippled on this build platform | 00:08 |
| awilkins | http://pastebin.ca/1054527 | 00:08 |
| jam | lifeless: I'm not quite sure what you are pointing me to | 00:08 |
| lifeless | jam: 'how big is a mysql branch' | 00:08 |
| jam | 500+ MB for 6.0, 300 ish for 5.0 | 00:09 |
| lifeless | ok, time to put this pc in for repair. | 00:09 |
| jam | tethridge: my copy is 591MB, with most of their branches | 00:10 |
| tolstoy | Is there a discussion of permissions anywhere? Like when different processes and/or users are pushing to a central locations? Oy. I'm not sure wide open umasks are the solution. | 00:10 |
| jelmer | awilkins: ouch | 00:10 |
| jam | bug #240262 | 00:10 |
| ubottu | Launchpad bug 240262 in bzr "No repository present error when using bzr+http protocol talking from bzr 1.5 client to a 1.3.1 repository" [High,Confirmed] https://launchpad.net/bugs/240262 | 00:10 |
| awilkins | jelmer: I remember having more success with those Pyrex bindings using MSVC ; how hard is it to ditch the dots? | 00:14 |
| awilkins | jelmer: Previously managed to get as far as having built .pyd files (even if they didn't actually work) | 00:14 |
| jelmer | awilkins: basically, it's changing all structs that use the dotted notation to explicitly set all member variables, and in the right order | 00:15 |
| awilkins | I'd guess that's quite a few | 00:16 |
| jelmer | yeah, indeed | 00:17 |
| jam | tolstoy: you may want to look at contrib/bzr_access, which would be a good place to work out multiple user keys for a shared repo, and proper umask, etc. | 00:17 |
| tolstoy | jam: Okay, thanks. | 00:18 |
| beuno | hrm, LP hates me today: | 00:21 |
| beuno | beuno@beuno-laptop:~/bzr_devel/loggerhead.fix_dirs$ bzr pull lp:~beuno/loggerhead/bug-240512 | 00:21 |
| beuno | Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) | 00:21 |
| beuno | bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 502 Bad Gateway | 00:21 |
| mwhudson | :( | 00:22 |
| mwhudson | try again again | 00:22 |
| mwhudson | i think | 00:22 |
| beuno | yeah, already did, but it's *extremely* slow | 00:22 |
| beuno | it's stuck at: 0.198 opening working tree '/home/beuno/bzr_devel/loggerhead.fix_dirs' | 00:23 |
| * beuno tries again with Dhpss | 00:23 | |
| awilkins | jelmer: Those traces are full of MSVC symbols..... | 00:26 |
| awilkins | Or rather, the lack of them | 00:26 |
| jelmer | awilkins: probably a different ABI or something | 00:27 |
| jelmer | some sort of compiler mismatch at least | 00:28 |
| awilkins | PLus things like _chkstk which is apparently shoved in when big stack frames are in there etc. | 00:28 |
| awilkins | Darn | 00:28 |
| jelmer | ok, so fixing the dotted structure notation is the only solution? | 00:29 |
| awilkins | I hate to say it, but probably | 00:29 |
| awilkins | THe other solution would be building Neon, SVN and all the other stuff on MinGW and I can't find much help for that | 00:30 |
| awilkins | There's a reason I'm using the pre-archive developers pack of SVN libraries and headers | 00:30 |
| beuno | LP is autopacking LH again | 00:30 |
| * beuno crosses his fingers | 00:30 | |
| === mario_ is now known as pygi | ||
| awilkins | jelmer: Right, it's 0033 here, I'm going to bed.... if there is any simple drudge work I can do to help, let me know. | 00:34 |
| jelmer | awilkins, will do | 00:34 |
| awilkins | jelmer: But bear in mind my C is rather rusty. | 00:34 |
| jelmer | awilkins, g'night | 00:34 |
| awilkins | Goodnight | 00:34 |
| RichW | Is this error serious? or can i ignore it? This transport does not update the working tree of: sftp://...../trunk/. See 'bzr help working-trees' for more information. | 00:40 |
| beuno | RichW, that means the the actual files aren't been updated, so it depends on what you're using it for | 00:42 |
| beuno | is that in launchpad? | 00:43 |
| mwhudson | beuno: so loggerhead/trunk looks better again thanks | 00:48 |
| beuno | mwhudson, yeah, sorry about that. I was used to the bzr workflow, where PQM is always left-hand. I'll be more careful from now on | 00:49 |
| mwhudson | no worries | 00:49 |
| beuno | autopack worked fine now (took almost 20 minutes though( | 00:50 |
| mwhudson | autopack still mostly happens client side i think | 00:50 |
| mwhudson | there's a patch floating around to fix that | 00:51 |
| beuno | yeah, but it doesn't take 20 minutes to push the full branch, so I suppose it should take at most that long, right? | 00:51 |
| beuno | anyway, it's done now, so no use in complaining :) | 00:51 |
| mwhudson | i can imagine there being a silly amount of roundtrips | 00:51 |
| mwhudson | beuno: for bug 242466, how does this look? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png | 00:52 |
| ubottu | Launchpad bug 242466 in loggerhead "Log view should show sub-revisions" [Medium,Confirmed] https://launchpad.net/bugs/242466 | 00:53 |
| mwhudson | (this is something i did ages ago in a branch which has gone to the big hard disk crash in the sky, but i think i know how to do it again) | 00:53 |
| beuno | mwhudson, that looks pretty good. I remember now you emailed that a while back to the list. I had in mind maybe trying to show them like collapsed revisions, and being able to expand them too | 00:55 |
| beuno | ok, trunk should be back to before the left-hand-side-plus-collapsing-packs mess | 01:04 |
| mwhudson | beuno: you mean, making less distinction between the mainline and off-mainline revisions? | 01:04 |
| mwhudson | that probably makes sense | 01:05 |
| beuno | mwhudson, yes. I feel it makes merged revisions seem like something different, when they're not. Users already get confused with DVCS in that sense, and that may not help | 01:06 |
| beuno | I'll try to get a mockup for that once we're through with the new theme, if you'd like | 01:06 |
| mwhudson | beuno: swings and roundabouts, i think having _some_ emphasis on the mainline revs is ok | 01:06 |
| mwhudson | (this is one of the things i find incomprehensible about bzr-webserve) | 01:07 |
| beuno | mwhudson, alright, two mockups :p | 01:07 |
| mwhudson | beuno: heh | 01:07 |
| mwhudson | let's get the new theme done | 01:08 |
| mwhudson | first | 01:08 |
| beuno | mwhudson, I had something in mind similar to "This revision is composed of N revisions. Show revisions" | 01:09 |
| beuno | and expand on-screen | 01:09 |
| beuno | if that's possible without making the UI a mess | 01:10 |
| fullermd | Well, the big problem is that having high emphasis on the mainline revs is perfect in some workflows, but with others having ANY emphasis is bunk. | 01:10 |
| beuno | lifeless, FWIW, second time Loggerhead auto-packed, after going back a few revisions, it worked out fine | 01:11 |
| mlh | Peng: true (re server generated index html). I hadn't even tried it. (smacks forehead) | 01:12 |
| mwhudson | fullermd: but it makes sense in a workflow that involves pqm, which is the right workflow, so qed | 01:12 |
| * mwhudson runs away and has lunch | 01:13 | |
| fullermd | pqwhat? :p | 01:13 |
| mlh | and ... IT WORKS!@ | 01:13 |
| mlh | now to get around the ~ since my work blocks access to 'personal pages' ie those with a tilde :-( | 01:14 |
| mwhudson | beuno: btw, are you running the tests before committing to trunk? | 01:14 |
| mwhudson | beuno: the tests suck, but they do occasionally catch problems | 01:14 |
| mlh | don't s'pose bzr does ntlm proxy auth? :-) | 01:14 |
| beuno | mwhudson, uhm, 50% of the time, tbh. I'll bump that up to always :) | 01:15 |
| fullermd | Well, if the tests cover 50% of the code, and you run them 50% of the time, the two add up to 100% coverage! | 01:15 |
| mlh | if it used curl, it could | 01:15 |
| beuno | I do go through all pages in UI, before pushing, which may catch more than tests. But I will do both until we have better tests | 01:15 |
| beuno | mwhudson, just checked though, haven't broken any tests (which just goes to show how little we're testing :P) | 01:16 |
| * beuno goes back to gnome-theming while mwhudson eats his well-deserved lunch | 01:18 | |
| tolstoy | Hm. On solaris, the xmloutput plugin says that encoding is "646". I've never heard of 646 as an encoding. | 01:19 |
| fullermd | Unicode is ISO-10646 | 01:20 |
| fullermd | Well, UCS technically. But who can keep track of all the acronyms and subacronem? | 01:21 |
| tolstoy | It's odd. I'm trying to integrate this with bamboo (oy) and its jdom parser rejects the xml output because encoding="646". | 01:21 |
| tolstoy | Interesting. On this version of python (that I compiled myself), on Solaris (hail mary), sys.getfilesystemencoding() returns '646'. | 01:24 |
| mlh | weird | 01:24 |
| === mw is now known as mw|out | ||
| tolstoy | Just as a user, rather than an ops staff, or whatever, Solaris leavs much to be desired. | 01:25 |
| mlh | yep, checked | 01:26 |
| mlh | I've got two pythons installed on solaris, site compiled, and one installed from blastwave | 01:26 |
| mlh | both have '646' | 01:26 |
| tolstoy | It's good to know I didn't mess up the compile. | 01:26 |
| fullermd | I would guess that means UTF-8. But it could be UCS-2 or some such insanity. | 01:27 |
| mlh | solaris has got a lot to be desired frmo an ops view too | 01:27 |
| mlh | first thing I do is install a swag of freeware | 01:27 |
| tolstoy | I guess I'll have to "fix" the xmloutput plugin. | 01:28 |
| fullermd | s/ frmo.*// | 01:28 |
| mlh | well, 2nd thing, after jass. (here's ends the OT) | 01:28 |
| tolstoy | mlh: I'd just erase the whole OS and install something else, but then I don't have root, and people get tired of such suggestions. ;) | 01:28 |
| mlh | :-) | 01:28 |
| fullermd | Luckily, these days, there's vmware and such ;> | 01:28 |
| tolstoy | We compile java apps, and people are afraid that if we compile on linux and deploy on solaris, Bad Things Will Happen. | 01:29 |
| mlh | we have smiilar superstitions here | 01:30 |
| mlh | even though, people have compiled on windows and deployed on solaris and it's just worked dandily | 01:31 |
| beuno | Jc2k, ping | 01:34 |
| beuno | Jc2k, lifeless, I've got some integration for the gnome theme: http://intranet.pentacorp.net:8080/changes | 01:36 |
| beuno | it could probably be nicer for the LH menu navigation/search bar, but not sure how to cram everything together | 01:37 |
| mlh | is there a proggy to generate index.html that DOES include .bzr? | 01:37 |
| mlh | it'd be pretty simple to make one I guess; just checking if there's an option or plugin | 01:38 |
| mlh | bzr ls --html mebbe | 01:39 |
| mlh | tiny bug in bzr help status: | 01:44 |
| mlh | s/bzr -SV/bze status -SV/ | 01:44 |
| beuno | mlh, I see: | 01:45 |
| beuno | to Subversion's status command. To get output similar to svn -q, | 01:45 |
| beuno | use bzr -SV. | 01:45 |
| mlh | yeah | 01:46 |
| beuno | which seems correct. What version of bzr are you using? | 01:46 |
| spiv | beuno: right, there's a command name missing | 01:46 |
| mlh | 1.5 on fedora9 | 01:46 |
| beuno | aah :) | 01:46 |
| beuno | mlh, you can either file a bug and/or send a patch | 01:46 |
| beuno | thanks spiv | 01:46 |
| mlh | er too small for a bug | 01:46 |
| mlh | one of you can just sneak it in with other fixes :-) | 01:47 |
| beuno | Jc2k, lifeless, I'm off in a few minutes to have dinner, but, screenshot up in: http://beuno.com.ar/random/gnome_themed.png and pushed it to: lp:~beuno/loggerhead/gnome_theme | 01:49 |
| lifeless | beuno: cool | 02:17 |
| lifeless | beuno: does it have bzr-search ? :P | 02:18 |
| poolie_ | hello beuno etc | 02:31 |
| === poolie_ is now known as poolie | ||
| === kiko is now known as kiko-zzz | ||
| gambler | are there any java or csharp lang bindings to bzr? | 02:39 |
| AfC | gambler: look at the bzr-eclipse plugin; the work done there is relevant. | 02:44 |
| gambler | AfC, is it stable? | 02:45 |
| * igc lunch | 02:48 | |
| lifeless | gambler: do you mean 'is it done' or 'does it work well' | 03:05 |
| gambler | does it work well | 03:07 |
| lifeless | gambler: I don't use eclipse; but various folk that do tell me it works nicely | 03:07 |
| mlh | not completely tangentally, jython 2.5 alpha is out | 03:11 |
| gambler | meh another time sink. ill investigate it then | 03:12 |
| lifeless | gambler: 'Verterok' who hangs out here is one of the primary developers | 03:14 |
| lifeless | he's in argentina though, his nighttime now | 03:14 |
| mwhudson | i installed eclipse yesterday! | 03:14 |
| mwhudson | then it confused me | 03:14 |
| lifeless | gambler: also, SoC last yerar, someone wrote some c# bindings | 03:14 |
| lifeless | dunno how good they are | 03:14 |
| gambler | linky? | 03:15 |
| lifeless | Jc2k: ironic that you are having to hack on git :) | 04:03 |
| Odd_Blok1 | poolie: At some point this week, I'd like to talk about the PQM work I'm going to be doing this summer, so I can start next Monday with clear targets and rewards. | 04:08 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| poolie | Odd_Bloke: that'd be good, could you start by putting down your thoughts on the list about what to do, so others can get involved | 04:10 |
| poolie | also the dates you'll be working on it | 04:10 |
| Odd_Bloke | poolie: I'll do that tomorrow. | 04:17 |
| xz | would someone like to help me figure out how to organize a project? I'm having trouble with the bazaar concepts | 04:44 |
| poolie | xz, sure | 04:51 |
| lifeless | gambler: sorry, was away from keyboard | 04:51 |
| lifeless | Verterok: btw - gambler is asking about accessing bzr from java | 04:51 |
| Verterok | lifeless: thanks for pointing it :) | 04:51 |
| lifeless | gambler: I'm not sure about where the c-sharp bindings are | 04:52 |
| * Verterok looking the backlog | 04:52 | |
| lifeless | I don't even remember the students name sorry :( | 04:52 |
| xz | poolie: my project is a single directory with a number of subdirectories. I want people to be able to work on the subdirectories independently, and then the parent can use various versions of them | 04:52 |
| Verterok | gambler: to access bazaar from java, there is a library I'm working on (and using it bzr-eclipse), https://launchpad.net/bzr-java-lib | 04:53 |
| xz | poolie but it should also be possible to move a file from one subdirectory to another, and that is a change to the parent | 04:53 |
| Verterok | s/it/in/ | 04:54 |
| poolie | xz, this is the subtrees feature | 04:54 |
| poolie | well, hm | 04:55 |
| poolie | there is a feature called subtrees which lets you commit independently in all the subdirectories and link them into the parent | 04:55 |
| Verterok | gambler: the current trunk of bzr-java-lib, is based on a CLI wrapper, so it's performance isn't quite good | 04:55 |
| poolie | it is a bit rough atm | 04:55 |
| xz | poolie I guess a single versioned branch (the parent) is a possibility, and to work on a subdirectory, you branch the whole thing, work on the inside, then merge back - is that the way to do it? | 04:56 |
| Verterok | gambler: I'm working in a branch that uses a xmlrpc backend, provides far better perfomance and mantain API compatibility with the CLI based one. | 04:57 |
| poolie | xz, yes, and that's probably simpler for many uses | 05:04 |
| poolie | igc, still around? | 05:11 |
| igc | poolie: yep | 05:12 |
| poolie | igc, i guess we should just consider it settled that there will be a file in the tree for preferences | 05:13 |
| poolie | i still think that's the best option but your quoted message from john makes me want to get more certainty that it is so | 05:14 |
| igc | poolie: I did :-) | 05:14 |
| poolie | did consider it settled? | 05:15 |
| igc | the issue now IMO is format marker syntax and optional vs required | 05:15 |
| poolie | right | 05:15 |
| poolie | i'm replying on that | 05:15 |
| igc | thanks | 05:15 |
| lifeless | I should reply still :( but don't block on me | 05:23 |
| beuno | hey poolie | 05:30 |
| beuno | lifeless, search isn't my choice, but if Jc2k wants it, I'd b happy to help him out with that too | 05:31 |
| lifeless | beuno: I believe he is running search already :P | 05:32 |
| lifeless | beuno: also, what time is it for you ?! | 05:32 |
| beuno | lifeless, ~1:30amish | 05:33 |
| beuno | early :p | 05:33 |
| beuno | I've been going to when mwhudson_ stops working, which is usually ~3am here | 05:33 |
| beuno | so, if he's running search I should probably make it auto-index... :/ | 05:34 |
| mwhudson_ | beuno: maniac | 05:35 |
| beuno | mwhudson_, hehehe, well, it's the only way to do *both* things (my current work and bzr/LH) | 05:36 |
| lifeless | beuno: but it already auto indexes | 05:36 |
| lifeless | beuno: so I really don't understand why you want to do that at all :P | 05:36 |
| beuno | lifeless, well, it autoindexes once it has indexed :) | 05:36 |
| lifeless | beuno: right | 05:37 |
| beuno | so, I'd like to provide an egg for the chicken | 05:37 |
| beuno | shouldn't be too hard | 05:37 |
| beuno | just juggling quite a few things at a time | 05:37 |
| lifeless | beuno: which means lh doesn't need a config item saying to index or not - it can just detect if there is an index, and only show Search when there is | 05:37 |
| lifeless | beuno: I'm not sure I agree, because it will add the need for a knob for people that don't want a search index | 05:37 |
| beuno | lifeless, right, I suppose that can be the default behaviour (which is what it currently does), but it would be nice to be able to tell it to index everything | 05:38 |
| beuno | it'll probably be 50/50 of people wanting and not wanting | 05:38 |
| beuno | it's a very cool feature :) | 05:38 |
| lifeless | beuno: wouldn't it be better to have bzr-search have an option which when set causes 'bzr branch' to create an index too ? | 05:39 |
| lifeless | (and init etc) | 05:39 |
| beuno | lifeless, that would be nice, yes. And it has the bonus that it falls on your court, and not mine! | 05:39 |
| lifeless | beuno: you've got patches in bzr-search too :P | 05:40 |
| beuno | heh, true. | 05:41 |
| lifeless | bug filed | 05:47 |
| poolie | igc, ok, reply sent | 05:52 |
| poolie | that increased my conviction that adding one will not really help anything | 05:52 |
| poolie | to me it seems like an overgeneralization from what we had before | 05:53 |
| poolie | s/what we had before/from bzrignore and internal database versioning | 05:53 |
| igc | thanks for the detailed reply poolie. I hadn't considered the idea of introducing a new file as the way to bump the format. Interesting. | 06:05 |
| jml | loom question. | 06:19 |
| jml | two commits went to the wrong thread. between now and then I've made 5 other commits. | 06:20 |
| jml | what can I do about this? | 06:20 |
| jml | cherrypick out those two wrong commits? | 06:21 |
| lifeless | jml: so thread A should have got commits 1 and 2 | 06:25 |
| lifeless | and thread B got them instead | 06:25 |
| lifeless | jml: where did commits 34567 go ? | 06:25 |
| jml | thread A | 06:26 |
| lifeless | whats thread B's position relative to thread A? | 06:26 |
| jml | immediately above. | 06:26 |
| lifeless | ok | 06:26 |
| lifeless | because B has content A doesn't, you can't just merge them in, you'd get B as well | 06:27 |
| lifeless | so yes - cherry pick merge them down to A | 06:27 |
| jml | sorry. I misread something you said. | 06:27 |
| jml | let me answer your questions again. | 06:27 |
| jml | jml: where did commits 34567 go ? | 06:28 |
| jml | thread B | 06:28 |
| jml | whats thread B's position relative to thread A? | 06:28 |
| jml | thread A | 06:28 |
| jml | err, thread B is immediately below thread A | 06:28 |
| lifeless | so | 06:28 |
| lifeless | switch to B | 06:28 |
| lifeless | bzr up-thread | 06:28 |
| lifeless | that will merge them to A, commit. | 06:29 |
| lifeless | then, switch to B | 06:29 |
| lifeless | and bzr cherrypick 1 and 2 out of B | 06:29 |
| lifeless | (e.g. by bzr merge -r -5..-7 .) | 06:29 |
| lifeless | commit | 06:29 |
| lifeless | bzr up-thread | 06:29 |
| lifeless | (which will back the commits out) | 06:29 |
| lifeless | and bzr revert . | 06:29 |
| lifeless | which will put them back and keep the merge record | 06:29 |
| lifeless | then bzr st (should show a pending merge) | 06:30 |
| lifeless | bzr commit | 06:30 |
| jml | thanks | 06:34 |
| Jc2k | hellow all | 07:16 |
| beuno | mornin' Jc2k | 07:23 |
| beuno | Jc2k, http://200.127.6.219:8080/changes | 07:25 |
| Jc2k | now that is quite pretty :D | 07:26 |
| Jc2k | beuno: can you make the plain pages that serve-branches serves equally shiny? | 07:27 |
| beuno | Jc2k, ah, yes. That would involve templating those bits, which will close a bug. I'll bump that up on my priorities | 07:27 |
| beuno | Jc2k, you can get the branch from: lp:~beuno/loggerhead/gnome_theme | 07:28 |
| beuno | we can play around with the tabs to make LH's navigation seem more integrated, but I didn't want to change anything substantial | 07:29 |
| gour | have you read http://adam.gomaa.us/blog/thoughts-on-dvcss/ (reddit) ? | 07:32 |
| eMBee | good afternoon | 07:45 |
| eMBee | is there a nice tool to display branches as a graph? | 07:47 |
| gour | eMBee: bzr vis | 07:47 |
| beuno | gour, it's an interesting read, although he seems to know nothing about bzr, and a lot about git/hg | 07:47 |
| beuno | eMBee, that would be part of bzr-gtk plugin | 07:48 |
| gour | beuno: heh, i really like such kind of posts :-/ | 07:48 |
| eMBee | ah, thanks | 07:48 |
| beuno | alright, that's it for me today | 07:48 |
| beuno | g'night everyone | 07:49 |
| beuno | Jc2k, I've got theming the remaining bits of LH on my list, make sure to poke me if you need something else :) | 07:50 |
| eMBee | bzr vis does not seem to exist, and bzr-gis only in lenny, not in etch or backports :-( | 07:50 |
| beuno | eMBee, bzr-gtk is the package, not sure if it's in etch ot backports, but you can install it with: bzr co lp:bzr-gtk ~/.bazaar/plugins/gtk | 07:51 |
| beuno | of course, you have to have gtk installed :) | 07:51 |
| eMBee | so it just uses pygtk or something? | 07:52 |
| beuno | yes | 07:52 |
| eMBee | ok, then that's good enough for testing | 07:53 |
| eMBee | normally i prefer to have the packages installed | 07:53 |
| eMBee | eeeks, need a launchpad login for that | 07:53 |
| beuno | eMBee, actually, check out the manual installation: http://bazaar-vcs.org/bzr-gtk | 07:54 |
| beuno | eMBee, you shouldn't need a LP login, no | 07:54 |
| beuno | anyway, I'm really off to be now :) | 07:55 |
| gour | jelmer: there will be new bzr-svn release soon? | 07:55 |
| eMBee | bzr branch http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk ~/.bazaar/plugins/gtk; seems to work | 08:00 |
| gour | good | 08:00 |
| eMBee | i guess lp references my local setup and assumes launchpad access | 08:01 |
| eMBee | where does bzr vis come from? is that part of the gtk plugin? | 08:02 |
| gour | eMBee: part of gtk plugin, it's alias for visualize | 08:03 |
| eMBee | thanks | 08:03 |
| gour | does it work? | 08:04 |
| * gour likes bzr vis although comfortable with cli | 08:05 | |
| * ToyKeeper ponders working on some vis improvements | 08:06 | |
| * eMBee is still loading the source | 08:07 | |
| eMBee | i like the cli. but i do like to visualize the branch graph | 08:07 |
| eMBee | it really helps me to see where i am and if the operation i do has the desired outcome | 08:08 |
| ToyKeeper | I like browsing changes and diffs in the GUI, and sometimes committing changes in the GUI, but everything else seems easier on the command line. | 08:08 |
| gour | right. it's very helpful | 08:08 |
| gour | (sometimes) | 08:08 |
| * gour comes from non-gui world of darcs | 08:09 | |
| eMBee | heh, with darcs i was always confused about the state of my branch | 08:09 |
| ToyKeeper | I liked the patch-based concept of darcs, but never really did much with it. | 08:10 |
| lifeless | Jc2k: are you running bzr-search version of loggerhead? | 08:10 |
| lifeless | Jc2k: beuno needs to know, to know to memrge it in or not :) | 08:10 |
| gour | i used it almost exclusively for several years, but had issues with it as well | 08:11 |
| eMBee | hmm: bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack | 08:11 |
| lifeless | eMBee: from bzr viz? | 08:11 |
| lifeless | eMBee: I blieve that was a specific version issue | 08:12 |
| eMBee | yes | 08:12 |
| gour | eMBee: it must be something wrong with your repo :-) | 08:12 |
| eMBee | i just checked out trunk | 08:12 |
| lifeless | eMBee: and what bzr are you runnin? | 08:13 |
| gour | i mean, the repo you want to 'vis' | 08:13 |
| eMBee | bzr is 1.5 from debian etch backports | 08:13 |
| lifeless | I suspect trunk of bzr-gtk needs trunk of bzr | 08:14 |
| eMBee | hmm, can i check out a version of gtk that works with the released 1.5? | 08:17 |
| AfC | eMBee: you mean the bzr-gtk plugin? | 08:17 |
| eMBee | yes | 08:17 |
| spiv | eMBee: you could try -rtag:bzr-gtk-0.94.0, it might work with 1.5 | 08:17 |
| AfC | eMBee: or the GTK+ library? | 08:17 |
| ToyKeeper | eMBee: You could just update your branch to a released revision. | 08:17 |
| gour | eMBee: you need trunk of bzr, if i understand | 08:17 |
| spiv | (that's just a guess though, I'm not sure if that release works with 1.5) | 08:18 |
| eMBee | but i don't want to get the trunk of bzr, i prefer to stick to the debian package | 08:18 |
| AfC | Huh. I have bzr-gtk 0.93.0 here plugged into my bzr 1.5; I guess it's time for me to poke at that. | 08:19 |
| AfC | eMBee: why would you want to do that? | 08:19 |
| eMBee | why would i want what? | 08:19 |
| AfC | stick with out of date Debian packages of a project which is iterating quickly? | 08:19 |
| lifeless | eMBee: if you are using the debian packaged bzr, you should also use the debian packaged bzr-gtk :) | 08:20 |
| eMBee | because i can not recommend others to use bzr if they are expected to get the latest revision. it just means that bzr is not yet stable for use | 08:20 |
| eMBee | lifeless: that is true, unfortunately, there is no bzr-gtk backport for etch available yet | 08:21 |
| lifeless | eMBee: have you requested one? | 08:21 |
| eMBee | only lenny, which is equally not something i can recommend | 08:21 |
| ToyKeeper | bzr pull -rtag:bzr-gtk-0.94.0 lp:bzr-gtk ~/.bazaar/plugins/gtk ? | 08:24 |
| ToyKeeper | You do have python-gtk2 installed, yes? | 08:25 |
| ToyKeeper | bzr-gtk requires python-central, python-glade2, python-gtk2 | 08:25 |
| lifeless | eMBee: have you requested a backport? | 08:30 |
| gour | i run bzr-gtk-0.94 with bzr-1.6b3 - no problems | 08:31 |
| eMBee | lifeless: i just discovered that it wasn't backported, and i am not aware of any place where i could request a backport | 08:32 |
| gour | but used it with pre1.5 as well | 08:32 |
| gour | eMBee: do you have seahorse installed? | 08:32 |
| eMBee | what's seahorse? (i guess no) | 08:33 |
| gour | there was (is) issue that bzr-gtk requires it | 08:33 |
| gour | try to install it | 08:33 |
| gour | for managing gpg keys | 08:34 |
| eMBee | installing seahorse does not make the error go away | 08:36 |
| lifeless | eMBee: I believe you file a bug on debian.org to ask for a backport | 08:36 |
| eMBee | lifeless: i'll look into that, thanks | 08:37 |
| lifeless | eMBee: http://lists.backports.org/lurker-bpo/list/backports-users.html is the users list | 08:38 |
| lifeless | eMBee: I would start there | 08:38 |
| eMBee | heh, thanks | 08:38 |
| eMBee | the backport is not a priority, since i need to get this working now. in the worst case i can make my own backport later, but that's to much effort now | 08:38 |
| gour | eMBee: can you paste error? | 08:39 |
| ToyKeeper | Is it expected that bzr trunk branching from LP complains about the server not supporting network protocol 3? | 08:40 |
| lifeless | ToyKeeper: yes; protocol 3 is new and lp hasn't been upgraded to support it yet | 08:41 |
| eMBee | yes, hold on | 08:41 |
| ToyKeeper | lifeless: Okay, that's what I figured. Just wanted to check. | 08:42 |
| lifeless | bbiab | 08:43 |
| igc | poolie: ok, you've convinced me I think. I've replied with another idea for your consideration | 08:44 |
| eMBee | http://pastebin.ca/1054962 | 08:45 |
| gour | eMBee: have you seen https://bugs.launchpad.net/bzr-gtk/+bug/237205 | 08:48 |
| ubottu | Launchpad bug 237205 in bzr-gtk "error starting webbrowser.GenericBrowser in python2.4" [Medium,In progress] | 08:48 |
| eMBee | not yet, looking now | 08:48 |
| eMBee | so i run into this problem because of python 2.4 in etch, ok | 08:49 |
| gour | right, python-2.5.2 here | 08:50 |
| eMBee | bzr vis uses a webbrowser? | 08:50 |
| ToyKeeper | Ah, I had that exact problem on edgy. | 08:51 |
| eMBee | so i just get that branch that contains the fix? | 08:52 |
| gour | i'd say so | 08:52 |
| eMBee | can i update the existing branch somehow? | 08:52 |
| ToyKeeper | bzr's gui does seem a little heavy on dependencies. I'd rather it not talk to my browser, ever. :) | 08:53 |
| * eMBee is not yet familiar with bzr | 08:53 | |
| gour | there are conflicts maybe | 08:53 |
| gour | eMBee: try merging, although i'd rm old branch and pull new one | 08:53 |
| eMBee | i don't want to merge, but just get the different revisions | 08:53 |
| ToyKeeper | eMBee: You could "bzr pull lp:~iacobs/bzr-gtk/browser-detection" (instead of using trunk) or "bzr merge lp:~iacobs/bzr-gtk/browser-detection" (into trunk) to get the fix. | 08:54 |
| eMBee | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 08:56 |
| eMBee | ok, i expect that, | 08:56 |
| gour | heh | 08:56 |
| eMBee | but why is it an error? | 08:56 |
| jml | is there an easy way to see a log of all commits made on a thread since it was created? | 08:56 |
| gour | eMBee: by design | 08:56 |
| ToyKeeper | eMBee: You can't pull one branch on top of another. It has to be merged instead. (I'm guessing you did a 'bzr branch' or 'bzr pull' inside the trunk dir, but 'bzr merge' is correct) | 08:57 |
| gour | eMBee: this is not darcs ;) | 08:57 |
| eMBee | but i don't want to merge, i want to switch and get the new branch just as it is | 08:58 |
| eMBee | but i don't want to waste bandwith and get the whole branch from scratch either | 08:58 |
| ToyKeeper | This is, admittedly, confusing. In hg, the command is 'hg pull -u', but in bzr it'd be 'bzr merge --pull'. It sounds like darcs also uses 'pull' to merge things. | 08:58 |
| eMBee | the divergion (is that aa word?) should be small | 08:58 |
| jml | eMBee: what do you know about shared repositories? | 08:59 |
| eMBee | nothing in terms of bzr | 08:59 |
| eMBee | did i just create a shared repo? | 08:59 |
| jml | eMBee: they are a way for bzr branches to share data. they can help a lot with not wasting bandwidth | 08:59 |
| eMBee | right, that's what i want | 09:00 |
| jml | eMBee: you create one by doing 'bzr init-repo path/to/repo' | 09:00 |
| jml | eMBee: then you fetch branches inside that repo | 09:00 |
| jml | eMBee: you can 'prime' one for bzr-gtk by doing something like this: | 09:00 |
| jml | bzr init-repo bzr-gtk | 09:01 |
| jml | cd bzr-gtk | 09:01 |
| jml | bzr branch ../../path/to/existing/bzr/gtk/branch-name | 09:01 |
| jml | and then you can fetch the branch ToyKeeper mentioned. | 09:02 |
| * jml hasn't been following the conversation in detail. | 09:02 | |
| jml | lifeless: did you see my loom question? | 09:02 |
| spiv | eMBee: if you have a checkout, you can just do "bzr switch" to point it to a different location. If you have a branch that you want to overwrite with another branch, you can use "bzr pull --overwrite". | 09:07 |
| thekorn | hi, I've got one bzr pull related question: | 09:08 |
| thekorn | is bzr pull lp:~<location> suppose to work? | 09:08 |
| spiv | eMBee: but if you want merge changes from one branch into another, then "bzr merge" is the command to use :) | 09:08 |
| spiv | thekorn: yes | 09:08 |
| thekorn | spiv, hmm,ok for me it returns: | 09:09 |
| thekorn | $ bzr pull lp:~bughelper-dev/python-launchpad-bugs/intrepid.merge | 09:09 |
| thekorn | bzr: ERROR: Not a branch: "/media/disk-1/python-launchpad-bugs/intrepid.merge/lp:~bughelper-dev/python-launchpad-bugs/intrepid.merge/". | 09:09 |
| jml | thekorn: what version of bzr are you using? | 09:09 |
| thekorn | jml, 1.3.1 | 09:10 |
| jml | how odd. | 09:10 |
| jml | wait | 09:10 |
| jml | thekorn: what does 'bzr st' show you? | 09:11 |
| thekorn | jml, http://paste.ubuntu.com/22535/ | 09:12 |
| jml | thekorn: sorry, I meant 'bzr info'. my bad. | 09:12 |
| thekorn | jml, np, http://paste.ubuntu.com/22537/ | 09:13 |
| jml | thekorn: ok, that definitely weirds me out. | 09:14 |
| spiv | thekorn: that's bug #181945 | 09:14 |
| ubottu | Launchpad bug 181945 in bzr "bzr pull lp:upstart fails" [Critical,Fix released] https://launchpad.net/bugs/181945 | 09:14 |
| spiv | thekorn: it's fixed in 1.4 and later | 09:14 |
| * jml unweirded. | 09:14 | |
| jml | I'll see you all later. | 09:15 |
| thekorn | ok, thanks spiv and jml, do you know if there will be a backport of bzr > 1.3.1 for hardy | 09:15 |
| spiv | thekorn: there's a PPA: https://launchpad.net/~bzr/+archive | 09:16 |
| thekorn | spiv, ok, thanks | 09:16 |
| gour | eMBee: have you managed to get 'vis' working? | 09:17 |
| thekorn | is there a tool/script available in bzr which expands adresses like lp:~<location> for me, so I can see where this location is redirected with my configuration? | 09:21 |
| james_w | only in bzrlib I think | 09:23 |
| james_w | I think it is in bzrlib/plugins/launchpad/directory_service.py | 09:23 |
| thekorn | hi james_w, thanks, looking | 09:24 |
| spiv | thekorn: yes, bzr >= 1.4 ;) | 09:24 |
| spiv | thekorn: bzr info lp:FOO is a bit slow, but will tell you I think | 09:25 |
| spiv | thekorn: if you don't mind writing python code, james_w has pointed you in the right direction | 09:26 |
| james_w | hi spiv | 09:27 |
| spiv | Good evening. | 09:27 |
| thekorn | spiv, bzr info works thanks | 09:28 |
| jelmer | gour, hi | 09:54 |
| jelmer | gour, yeah, around the same time as bzr 1.6 | 09:54 |
| spiv | jelmer: I still can't pull python trunk with the current 0.4 branch btw | 09:56 |
| spiv | jelmer: Twisted trunk works fine now, though. | 09:56 |
| jelmer | spiv: whu, ok - what error? | 09:56 |
| spiv | jelmer: http://rafb.net/p/A02Y3L67.html | 09:58 |
| spiv | jelmer: I took a quick peek but no obvious error jumped out at me | 09:58 |
| spiv | jelmer: I tried blowing away the relevant svn-cache, but that didn't help | 09:59 |
| spiv | (It was pleasingly fast to regenerate though!) | 09:59 |
| gour | jelmer: thanks | 09:59 |
| jelmer | spiv: does it work better if you make _is_http_transport() return False and throw away the cache? | 10:01 |
| * spiv tries | 10:06 | |
| jelmer | lifeless: Stacking is going to require a new repo format, isn't it? | 10:12 |
| jelmer | lifeless, or just a new branch fmt? | 10:13 |
| eMBee | how can i see which branches i have in my repo? | 10:13 |
| spiv | jelmer: it is still running, but it seems to be doing better | 10:14 |
| spiv | jelmer: i.e. it's doing lots of added revision_id {...} rather than breaking :) | 10:15 |
| spiv | It's taking ~4s per revision. I guess that's what happens when you convert via intercontinental internet. | 10:18 |
| spiv | jelmer: thanks | 10:18 |
| jelmer | spiv: Heh, probably | 10:19 |
| spiv | jelmer: oh, and memory consumption is a little high (155MB resident) | 10:20 |
| spiv | High, but apparently stable. | 10:21 |
| spiv | (Or at least, growing quite slowly) | 10:22 |
| jelmer | spiv: yeah, I'm working on freeing more of it | 10:23 |
| * spiv nods | 10:23 | |
| spiv | It's much much better than it used to be :) | 10:23 |
| spiv | jelmer: great work | 10:23 |
| jelmer | spiv: Thanks :-) | 10:28 |
| eMBee | gour: vis is not working yet, need to figure out how to switch the branch. i did bzr branch bzr-gtk/trunk, and then inside that bzr pull branch-with-fix; not sure if that was a good idea. can i change a plain branch into a repo? | 10:34 |
| ToyKeeper | jelmer: Sorry for the redundant bzr-svn bug. I didn't realize it was already fixed, and don't know where to find unreleased packaging for it. | 10:37 |
| jelmer | ToyKeeper, no worries | 10:38 |
| jelmer | ToyKeeper, branches for most bzr packages are up at http://bzr.debian.org/pkg-bazaar | 10:38 |
| === kiko-zzz is now known as kiko | ||
| ToyKeeper | eMBee: Perhaps the simplest approach is to "mv ~/.bazaar/plugins/gtk /tmp" then "bzr pull lp:~iacobs/bzr-gtk/browser-detection ~/.bazaar/plugins/gtk". | 10:55 |
| ToyKeeper | eMBee: That will just replace your trunk branch with the fixed branch. It might be missing some updates from trunk, but it'll probably at least work. | 10:56 |
| ToyKeeper | Er, s/pull/branch/ :) | 11:02 |
| eMBee | ToyKeeper: but then i am regetting 95% of the commits which i already have in trunk, that's what i want to avoid. network is slow here | 11:03 |
| ToyKeeper | Ah. | 11:03 |
| ToyKeeper | In that case, you should be able to merge the fixed branch into trunk. | 11:03 |
| eMBee | merge seems to complex, can't i just somehow get the missing commits and then switch to the branch? | 11:04 |
| eMBee | figuring out how to do this is also a way for me to learn about bzr | 11:06 |
| ToyKeeper | That basically is what merge does. It grabs the missing changes and applies them. | 11:08 |
| eMBee | how about i create a new repo and then pull both branches (the one i already downloaded and the new one into that? | 11:08 |
| eMBee | but i don' | 11:08 |
| eMBee | ooops | 11:08 |
| eMBee | i don't want the changes to be applied to the working tree | 11:08 |
| eMBee | that would mean i'd have to resolve conflicts etc | 11:08 |
| ToyKeeper | I just tried it, and it works. There were no conflicts. | 11:09 |
| eMBee | that's not the point. there could be conflicts if i do this in another situation | 11:09 |
| eMBee | i want to get at the pristine state of the branch without redownloading all of it | 11:10 |
| ToyKeeper | Ah, so you want to grab the other branch, create a local copy with two heads, and then switch to the other head? | 11:10 |
| eMBee | exactly | 11:10 |
| eMBee | sorry, i am not so sure about the right terms to be used here | 11:10 |
| eMBee | the local copy with two heads is a shared repo, right? | 11:11 |
| ToyKeeper | I'm not sure bzr allows multiple heads like that, but I'm fairly new to bzr myself. | 11:11 |
| eMBee | well, there is a concept of shared repos, but i can't figure out how to change a simple in-branch repo to a shared one | 11:12 |
| ToyKeeper | I could tell you how to do it in hg, but that doesn't help. :) | 11:13 |
| eMBee | ToyKeeper: heh, my git experience does not help me either, here | 11:14 |
| james_w | eMBee: if you just want the other branch then "pull --overwrite" will get you there. | 11:15 |
| james_w | obviously be careful if you have local commits or uncommitted changes | 11:15 |
| james_w | "bzr reconfigure" may be able to turn a branch in to a shared repo, I can't remember | 11:15 |
| ToyKeeper | I've been wondering about multiple heads in bzr for a while now... | 11:19 |
| eMBee | james_w: ah, ok, i did a pull (but not with overwrite) does the pull add a second head or does it replace the head? | 11:19 |
| ToyKeeper | I haven't seen a way to do it in a single dir, but I haven't looked very hard. | 11:19 |
| james_w | eMBee: replaces it | 11:20 |
| james_w | "bzr pull" is "make this branch exactly the same as that one over there". If they have diverged then you need --overwrite to force it to prevent you from hiding your work. | 11:21 |
| eMBee | ok, but the other commits are still there? so if i pull again from trunk it should not need to get much over the network? | 11:21 |
| eMBee | ahh, now i understand why i got an error | 11:21 |
| james_w | yep, but if you were to "branch" or "push" that branch somewhere else those extra trunk commits would not be taken as well. | 11:21 |
| eMBee | yes, of course, it should only get/push what's related to the branch | 11:22 |
| eMBee | ok, i am slowly starting to understand what's happening. makes me feel more confident now, thank you | 11:22 |
| eMBee | ok, i did the overwrite thing, now i get bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link_button_set_uri_hook' when running bzr viz | 11:27 |
| james_w | sounds like a bug in that branch of bzr-gtk | 11:28 |
| * gour <--- lunch | 11:29 | |
| gour | eMBee: strange you have those bzr-gtk problems :-( | 11:30 |
| ToyKeeper | Sounds like the version of python-gtk may not be new enough. | 11:32 |
| eMBee | maybe a amd64 issue? | 11:32 |
| eMBee | or it is not even installed in the first place | 11:33 |
| ToyKeeper | New in PyGTK 2.10, the docs say. What version (if any) do you have? | 11:33 |
| ToyKeeper | http://www.moeraki.com/pygtktutorial/pygtk2reference/class-gtklinkbutton.html | 11:34 |
| eMBee | 2.8.6 | 11:34 |
| eMBee | then you are right and i am out of luck, because i can't install the newer one from lenny | 11:34 |
| ToyKeeper | Gah, google gave me the right content, on the wrong domain. | 11:34 |
| ToyKeeper | Can you add a newer debian feed via apt-pinning, and use it only for a few packages? | 11:35 |
| gour | eMBee: i'm on amd64 as well | 11:36 |
| gour | pygttk-2.12.1 | 11:37 |
| eMBee | gour: running etch? | 11:38 |
| jelmer | I guess we could optionally disable that code if it's not available | 11:38 |
| eMBee | that would be cool, at least as long as people stull use etch | 11:39 |
| eMBee | still | 11:39 |
| * eMBee needs to go. thanks for all the help so far | 11:39 | |
| ToyKeeper | eMBee: to do pinning, put newer feeds in sources.list, add some stuff in apt/preferences, and then you can grab newer packages when necessary. | 11:40 |
| gour | eMBee: no, i'm on archlinux | 11:40 |
| ToyKeeper | eMBee: sources.list ( http://rafb.net/p/T9LNRV23.html ), preferences ( http://rafb.net/p/R0MX1K64.html ) | 11:40 |
| ToyKeeper | eMBee: then, "apt-get -t testing install bzr-gtk" should work. | 11:41 |
| ToyKeeper | It's a lot easier than trying to make a backport. :) | 11:43 |
| ToyKeeper | (assuming the new packages don't have drastic dependencies, like a newer libc) | 11:44 |
| lifeless | jelmer: new repo format | 11:45 |
| jelmer | lifeless: Any chance rich-root-pack can be lumped in with that? | 11:45 |
| lifeless | jelmer: no; stacking on existing repos would be impossible | 11:46 |
| lifeless | jelmer: this is orthogonal to the 'what is default' discussion. I'd like to see rich root become default | 11:46 |
| jelmer | it just seems to multiply the number of formats we need | 11:46 |
| jelmer | since we'd also end up with rich-root-stacking / subtree-stacking / etc | 11:47 |
| AfC | oh, yeay | 11:47 |
| lifeless | jelmer: like we have for knits as well | 11:48 |
| jelmer | the number of formats in bzr seems to be a major point people are criticizing us on | 11:48 |
| lifeless | jelmer: its not /desirable/ but its seems the lesser evil than saying 'you cannot stack unless project X goes through a one-way watershed change for you first' | 11:48 |
| jelmer | lifeless, hmm, that's a good point | 11:51 |
| jelmer | lifeless: Maybe having both rrp as default and stacking in the next version would help | 11:52 |
| lifeless | that would be ideal | 11:52 |
| jelmer | lifeless: So small projects and the like can skip one upgrade | 11:52 |
| gour | in any case, stabilizing of repo-format is desirable | 11:53 |
| lifeless | gour: that will happen naturally when we have less improvements to make | 11:54 |
| jelmer | hmm, sqlite3 is now the main memory leaker in bzr-svn | 11:54 |
| jelmer | 1476 ==5449== 25,854,223 bytes in 171,239 blocks are possibly lost in loss record 98 of 99 | 11:55 |
| jelmer | 1477 ==5449== at 0x4023D6E: malloc (vg_replace_malloc.c:207) | 11:55 |
| jelmer | 1478 ==5449== by 0x577255D: sqlite3_malloc (in /usr/lib/libsqlite3.so.0.8.6) | 11:55 |
| gour | lifeless: sure...however plethora of formats is confusing, at least | 11:55 |
| lifeless | gour: stabilising for stabilisations goal is like ABI freezing so that you can say you have frozen | 11:55 |
| lifeless | gour: its like 'best practice' - a death knell for continual improvements | 11:55 |
| gour | lifeless: nothing against improvement...but then getting rid of old formats | 11:56 |
| lifeless | gour: right, so we can hide formats that are old, and remove support for very old ones | 11:57 |
| gour | backward compat. is pita | 11:57 |
| jelmer | gour: pita for developers mainly - it's generally good for users | 11:57 |
| lifeless | we can also use development formats as a way to batch up a number of changes that are not ready for general adoption | 11:57 |
| gour | right, dev-time is wasted...users can upgrade | 11:58 |
| beuno | hey jelmer, I see you got BB back up :) | 11:59 |
| jelmer | james_w: apt_pkg is leaking memory and imported even when bzr-builddeb isn't used | 11:59 |
| Kinnison | gour: Depends what you consider more important -- Your users' comfort, or cheap developers. | 11:59 |
| jelmer | james_w: Objections to importing it at the only spot where it's being used rather than always? | 12:00 |
| Kinnison | gour: A good developer will cope easily with back-compat if it's engineered well. | 12:00 |
| sabdfl | we can certainly be more aggressive in deprecating and removing formats | 12:00 |
| dato | jelmer: "It generates inefficient code - it generates proxy classes that" <-- it gets cut off there | 12:00 |
| sabdfl | i don't think we should keep more than three in play at any time | 12:00 |
| jelmer | gour: The backwards compatibility bit only causes overhead when the interface changes, the implementation would generally stay the same | 12:00 |
| gour | Kinnison: i consider it's reasonable for users to upgrade to newer & better formats so that old & dead code can be removed | 12:00 |
| lifeless | sabdfl: our /big/ bugbear is the transition to rich roots | 12:00 |
| lifeless | sabdfl: as soon as thats done it will get a lot easier | 12:01 |
| Kinnison | gour: Users are notoriously slow in moving forward. | 12:01 |
| lifeless | sabdfl: but I agree, every format users can see in 'bzr help init' adds confusion and documentation and so on. | 12:01 |
| Kinnison | Is there not a way to hide the older formats unless the user knows to look for them? | 12:02 |
| gour | Kinnison: they're if you allow them to be lazy | 12:02 |
| lifeless | sabdfl: ideally we'd be down to one | 12:02 |
| lifeless | Kinnison: yes | 12:02 |
| Kinnison | gour: It's not a question of 'allow' -- they *are* lazy. | 12:02 |
| lifeless | gour: consider dapper | 12:02 |
| Kinnison | gour: It's a very bad software engineering practice to expect the user to conform to your software. | 12:02 |
| lifeless | gour: it has what, 0.11? | 12:03 |
| sabdfl | if bzr tells them "this format is deprecated, and will disappear, please type bzr update now" then they will do so much more | 12:03 |
| gour | Kinnison: you can say: from bzr-1.6, format X won't be supported any longer...fire! move on | 12:03 |
| Kinnison | gour: Much better to expect the software to conform to users. | 12:03 |
| jelmer | dato, whoops, I'll fix that | 12:03 |
| james_w | jelmer: none, it's used pretty rarely. | 12:03 |
| jelmer | beuno, yep :) | 12:03 |
| beuno | having LP tell users they are still using knit there would be a good start. That bites people frequently | 12:03 |
| sabdfl | just got to test the hell out of the conversion processes, and make them not too slow | 12:03 |
| lifeless | gour: we can expect many users of stable distros to be using old bzr's, and allowing new users to interoperate freely and smoothly with those users helps make the ecosystem work well | 12:04 |
| beuno | jelmer, Verterok finished my sqlite -> pg conversion, and uploaded a branch. May be worth trying to see if that's more stable | 12:04 |
| gour | Kinnison: it's ok if they want to stick and use old releases, otherwise it does not make sense. how m$ can force users to upgrade their office & OS so often | 12:04 |
| gour | lifeless: is there something older that debian? what's current bzr there? | 12:05 |
| lifeless | gour: RHE I think :P | 12:05 |
| gour | :-) | 12:05 |
| beuno | lifeless, btw, have you gave your talk on bzr-search yet? | 12:06 |
| gour | lifeless: what version is in RHE? | 12:07 |
| lifeless | no, friday | 12:07 |
| lifeless | gour: I don't know | 12:07 |
| lifeless | well, I'm heading off | 12:08 |
| lifeless | later all | 12:08 |
| beuno | lifeless, cool, I'll have the javascript quirks worked out by then | 12:08 |
| beuno | cya lifeless | 12:08 |
| Kinnison | gour: just because microsoft do it doesn't make it right :-) | 12:09 |
| jelmer | beuno, the problems are mainly the IP of that machine changing, reboots and mail handling in bb | 12:09 |
| jelmer | beuno: I'd rather avoid messing with the db if I can | 12:10 |
| gour | Kinnison: i believe it's reasonable that in order to enjoy new features in software, one should upgrade it. atm, bzr brings new features but keeps old formats (too) long which does not make much sense. either users should stay with old releases or upgrade | 12:10 |
| beuno | jelmer, ah, so it's different from bzr's problems. Would you like to move that to a more stable server? I may be able to set it up on one of mine, if I can get Red Hat to install the proper dependencies | 12:11 |
| jelmer | beuno, yeah, having a more stable server would be useful | 12:13 |
| beuno | jelmer, ok, I'll see if I can get it running, and open up an account | 12:14 |
| === kiko is now known as kiko-afk | ||
| ToyKeeper | Hmm, looks like bzr-1.3 is in EPEL for RHEL5 / CentOS5. That makes etch (bzr 0.11) and dapper (bazaar-ng 0.8.2) the oldest. | 12:14 |
| dato | EPEL? | 12:15 |
| gour | ToyKeeper: so, some formats could go away? | 12:15 |
| ToyKeeper | dato: bzr isn't in RHEL, but it's in EPEL (Extra Packages for redhat Enterprise Linux). | 12:17 |
| dato | ok | 12:17 |
| beuno | ToyKeeper, so I suppose it would only be fair to compare it against backports | 12:17 |
| ToyKeeper | I didn't see it in dapper-backports. | 12:18 |
| jelmer | it's in sarge and etch backports | 12:20 |
| === kiko-afk is now known as kiko | ||
| MvG | Is bundle buggy ill today? I get error messages about a locked db when trying to fetch the list of pending merges. | 13:22 |
| MvG | I'm also curious about the state of my setlocale merge request. poolie had voted for resubmit after a partial review, abentley and jelmer had participated in the discussion, but now it's seen no activity for almost a week, except for one more post by me where I tried to get things moving again by posting a different approach for the main concern of the previous discussion. | 13:25 |
| abentley | MvG: I've fixed bundle buggy. | 13:28 |
| MvG | abentley: Thanks! | 13:29 |
| MvG | Is anybody planning on reviewing the setlocale branch? Or perhaps has even started? | 13:35 |
| fog | how does one know that a file is under version control and not just ignored? | 14:03 |
| Kamping_Kaiser | bzr status tell you? | 14:04 |
| === eMxyzptlk is now known as eMxyzptlk[away] | ||
| fog | if the file is not changed no, it does not print anything | 14:05 |
| spiv | fog: "bzr file-id FILE" | 14:07 |
| fog | spiv: oh, nice. thanks. | 14:07 |
| === mw|out is now known as mw | ||
| fbond | Anyone had any luck playing with the bzr reviewboard back-end? | 14:41 |
| statik | hi jelmer, i'm getting bus errors with bzr-svn when i build on hardy 64-bit. do I need to build against subversion 1.5? | 14:44 |
| jelmer | hi statik | 14:45 |
| jelmer | statik: No, 1.4 should work as well | 14:45 |
| jelmer | statik: Somebody else reported issues with that as well on Mac OS X | 14:45 |
| statik | strange. the last thing in .bzr.log is opening SVN RA connection to 'http://bungeni-portal.googlecode.com/svn/trunk' | 14:45 |
| statik | I got it working on OS X by building against 1.5 last night | 14:46 |
| statik | but this is different | 14:46 |
| statik | maybe I can get a core file | 14:46 |
| fbond | statik: you aren't using any funny filesystem are you? | 14:47 |
| statik | fbond: nope | 14:47 |
| statik | how would the filesystem come into play? | 14:47 |
| fbond | statik: Okay, I've seen bus errors on Mac OS X when the FS doesn't support mmap and the client program makes an mmap call. | 14:48 |
| fbond | statik: Sorry, sounds like it's not relevant. | 14:48 |
| statik | fbond: interesting though, I'll file that away :) the bus error is on Ubuntu 8.04 64bit | 14:49 |
| fbond | statik: yuck, probably a 64-bit issue... maybe a bug in the python-svn bindings... | 14:49 |
| jelmer | statik: have you tried running it under valgrind? | 14:52 |
| jelmer | statik: you may want to try running "make valgrind-check" in the bzr-svn directory | 14:53 |
| statik | jelmer: not yet, just grabbing debug symbols now | 14:53 |
| statik | excellent, will do | 14:53 |
| === kiko is now known as kiko-phone | ||
| statik | jelmer: make valgrind-check complains about unrecognised instruction vex amd64->IR: unhandled instruction bytes: 0xF 0x1F 0x44 0x0 | 15:05 |
| statik | i'll poke at this more later | 15:06 |
| === acuster is now known as avc_lurk | ||
| jelmer | statik: Another thing you could try is "make gdb-check" | 15:11 |
| statik | jelmer: ok. that drops me into gdb right away | 15:11 |
| statik | oh, type run :) | 15:11 |
| jelmer | statik: yep :-) | 15:11 |
| statik | jelmer: that looks more useful! http://paste.ubuntu.com/22623/ | 15:12 |
| jelmer | ah, found the problem | 15:13 |
| statik | you rokc | 15:13 |
| jelmer | statik, I've pushed a fix | 15:14 |
| jelmer | s/I have pushed/I am pushing/ | 15:14 |
| statik | awesome! | 15:15 |
| jelmer | oh, somebody else also reported a bug about this | 15:15 |
| statik | i prefer to talk to the man himself, with incredible bug-fixing turnaround speed. i couldn't get this level of service if I paid for it | 15:16 |
| jelmer | (-: | 15:17 |
| jelmer | abentley: ping | 15:20 |
| abentley | jelmer: pong | 15:20 |
| jelmer | abentley, is there an easy way of checking whether a merge directive still applies? | 15:20 |
| abentley | jelmer: You mean applies without conflicts? | 15:21 |
| jelmer | abentley: Sorry, yeah | 15:21 |
| jelmer | abentley, preferably without having to create a working tree | 15:21 |
| abentley | merge --preview should tell you about any conflicts encountered. | 15:21 |
| jelmer | abentley: Ah, thanks | 15:22 |
| jelmer | abentley: I'm working on a plugin that checks the status of a bunch of merge directive files | 15:28 |
| jelmer | turns out to be quite easy to write | 15:28 |
| abentley | jelmer: What's the motivation? | 15:31 |
| jelmer | abentley: Making sure none of the merge directives I send to projects get dropped silently | 15:32 |
| abentley | jelmer: Sounds similar to the purpose of BB, though reversed, I suppose. | 15:32 |
| jelmer | abentley: yep, and not every bzr project uses bb | 15:32 |
| jelmer | abentley: It would also be nice to be able to use this for svn stuff, though I guess it's hard to verify that a patch was applied without revids | 15:33 |
| abentley | jelmer: Yeah, you'd have to use a different strategy. | 15:34 |
| abentley | Like iterating through new revisions and seeing if any incorporate the patch's changes. | 15:34 |
| madduck | bzr is hating me again | 15:41 |
| madduck | "bzr: ERROR: Tags not supported by BzrBranch5('file:///home/madduck/code/unperish/'); you may be able to use bzr upgrade --dirstate-tags. | 15:41 |
| madduck | " | 15:41 |
| madduck | +lapse:..unperish|bzr:unperish@170|% bzr upgrade --dirstate-tags. #1609 | 15:41 |
| madduck | bzr: ERROR: no such option: --dirstate-tags. | 15:41 |
| madduck | oh, the final dot. cut-n-paste. :) | 15:42 |
| jelmer | hi madduck | 15:43 |
| madduck | hi | 15:44 |
| madduck | sorry for the noise | 15:44 |
| beuno | madduck, if possible, you should upgrade to the latest storage format, packs (--rich-root-pack, I believe). Not sure what verson of bzr you're using | 15:45 |
| madduck | tracking debian unstable | 15:45 |
| beuno | jelmer, you have more experience in this area :) | 15:46 |
| jelmer | beuno: rich-root-pack is a bad idea at this point | 15:46 |
| beuno | jelmer, really? knits with tags is better? | 15:46 |
| beuno | I should really stop giving advice to people then... | 15:47 |
| jelmer | beuno: No, pack-0.92 | 15:47 |
| beuno | jelmer, pack support tags by default? | 15:47 |
| jelmer | beuno, yep | 15:47 |
| beuno | ah, that goes to show how much I use tags | 15:47 |
| jelmer | beuno: rich-root-pack is a watershed format. It's impossible to downgrade from rich-root-pack to something older | 15:47 |
| beuno | madduck, it's easier then. if you have bzr 0.92+, then just 'bzr upgrade' should do it | 15:48 |
| jelmer | I really wish we had less formats | 15:48 |
| beuno | me too :) | 15:48 |
| beuno | madduck, either way, packs format is *way* faster/solid | 15:49 |
| beuno | jelmer, shouldn't bzr recommend upgrading to packs rather than dirstate-tags? | 15:52 |
| jelmer | beuno: yeah, it should | 15:52 |
| beuno | so... rock paper scissors to see who files the bug? :p | 15:53 |
| === yacc_ is now known as yacc | ||
| jelmer | beuno, s/bug/merge request/ >-) | 15:56 |
| beuno | well, my day is just starting to begin, so it will be a while til I can start fiddling with bzrlib | 15:58 |
| Jc2k | jelmer: whats the incantation to have svn-import make working tree less branch directorys in a rich root pack repository? | 15:59 |
| jelmer | Jc2k, that's the default | 16:00 |
| jelmer | or should be, at lesat | 16:00 |
| Jc2k | hmm | 16:00 |
| * Jc2k must be doing it wrong | 16:00 | |
| Jc2k | *tries again* | 16:00 |
| jelmer | Jc2k: if there already is a repository present, it will use the working tree policy of that | 16:01 |
| Jc2k | jelmer: this is making a new repo | 16:01 |
| Jc2k | jelmer: my existing mirrors are a bit.. mutanty :P | 16:02 |
| jelmer | Jc2k: So there's no repo there when you run svn-import ? | 16:02 |
| jelmer | Jc2k: or do you run init-repo first manually? | 16:02 |
| Jc2k | init-repo --rich-root-pack && branch trunk && remote-tree trunk && svn-import | 16:02 |
| madduck | well, glad to have started a discussion. :) | 16:02 |
| * madduck must run | 16:02 | |
| Jc2k | is kind of what happened in hte past | 16:02 |
| Jc2k | *remove-tree | 16:02 |
| jelmer | Just svn-import should do it | 16:02 |
| Jc2k | thats what i thought | 16:03 |
| jelmer | that will create a new repository without trees (unless you specify --trees) | 16:03 |
| jam | Jc2k: the initial "init-repo ..." doesn't have "--no-trees" | 16:03 |
| jam | jelmer: no | 16:03 |
| jam | jelmer: 'init-repo' defaults to --trees now | 16:03 |
| jam | remember? | 16:03 |
| jelmer | jam: svn-import doesn't | 16:03 |
| jam | jelmer: but his line involved "init-repo" | 16:03 |
| Jc2k | jam: my original script did no-trees | 16:03 |
| jam | (10:02:25 AM) Jc2k: init-repo --rich-root-pack && branch trunk && remote-tree trunk && svn-import | 16:03 |
| jelmer | jam: yes, but "just svn-import" wouldn't involve init-repo | 16:03 |
| jam | I'm just mentioning what I've seen in IRC | 16:04 |
| jam | If I missed some scrollback, that's fine | 16:04 |
| jelmer | jam: Yeah, you seemed to've missed a line | 16:05 |
| Jc2k | jelmer: eh, well, it works. jeez. i wonder what i did wrong the first time | 16:05 |
| jelmer | So, summing up: bzr init-repo will default to creating trees unless --no-trees was specified | 16:06 |
| jelmer | svn-import will not use trees unless --trees was specified | 16:06 |
| jelmer | and if there's a repository already there it will use the policy of that repository | 16:06 |
| jam | I see you saying that svn-import *should* create it for you, but I see jc2k saying that he did it manually without --no-trees, but that his script actually did supply --no-trees | 16:06 |
| jam | I missed where you clarified that "svn-import" defaulted to --no-trees | 16:06 |
| jelmer | jam: I was saying that the init-repo and branch commands weren't necessary | 16:07 |
| jelmer | only the last command (svn-import) | 16:07 |
| jelmer | anyway, we seem to agree on what the situation is | 16:08 |
| jelmer | sorry if my explanation of it was a bit confusing | 16:08 |
| Jc2k | ok, my mistake | 16:09 |
| Jc2k | did something silly after the svn-import | 16:09 |
| jam | jelmer: I'm not worried about myself being confused, and it seems that jc2k followed you :) | 16:10 |
| fbond | statik: Hey, you are the reviewboard support author? | 16:37 |
| fbond | statik: Care to comment on the state of the code? | 16:37 |
| statik | fbond: no, i had worked on something a long time back but the current backend i have not looked at | 16:37 |
| fbond | statik: oh, okay... | 16:37 |
| fbond | statik: I saw https://code.launchpad.net/~statik/reviewboard/bazaarsupport ... | 16:37 |
| fbond | Is that dead? | 16:37 |
| statik | yes, i should delete that | 16:37 |
| statik | sorry :) | 16:38 |
| fbond | That's okay. | 16:38 |
| fbond | Is there a new bzr backend in reviewboard itself? | 16:38 |
| statik | i think so | 16:38 |
| statik | the backends were refactored to make it a lot easier | 16:38 |
| statik | there should be backends for bzr, git, hg | 16:38 |
| jelmer | statik, does "make check" pass for you now on 64bit? | 16:40 |
| statik | jelmer: I don't see any new revisions on the 0.4 branch | 16:40 |
| statik | last rev is 1339 | 16:41 |
| jelmer | statik: are you using launchpad? It probably hasn't mirorred yet? | 16:41 |
| statik | jelmer: yes, i'm using launchpad. ok, i'll try pulling directly | 16:41 |
| statik | jelmer: running tests now | 16:44 |
| statik | jelmer: it got a lot farther before core dumping but did eventually crash about 551 test in | 16:53 |
| statik | seems usable though, i'm trying to pull from google code now | 16:53 |
| jelmer | statik: what error did it crash with? | 16:53 |
| statik | [551/875 in 7m42s, 151 err, 49 fail] bzrlib.plugins.svn.tests.test_repository.TSegmentation fault (core dumped) | 16:54 |
| statik | re-running under gdb | 16:55 |
| statik | jelmer: when i ran make gdb-check, it ran 875 tests without crashing (53 failures, 189 errors) | 17:06 |
| jam | statik: gotta love it when it *doesn't* crash under gdb, but does manually :) | 17:06 |
| jam | my guess is an uninitialized variable | 17:06 |
| === kiko-phone is now known as kiko | ||
| jam | anyway, rebooting again | 17:08 |
| RichW | I have olive 0.93 and i get Unexpected Error: unsupported operand type(s) for /: 'float' and 'NoneType' | 17:20 |
| RichW | I get it when merging from a task branch to trunk | 17:21 |
| RichW | Any ideas? | 17:21 |
| LarstiQ | RichW: does olive support -Derror? | 17:21 |
| LarstiQ | RichW: the first thing I'd try to determine if the problem lies in bzrlib or in olive itself. ~/.bzr.log might be helpful | 17:22 |
| RichW | Merging from terminal works fine | 17:23 |
| RichW | I see no errors in log | 17:23 |
| LarstiQ | RichW: where do you see that error, on the terminal, or in a popup window? | 17:24 |
| RichW | Popup window | 17:24 |
| LarstiQ | RichW: it doesn't include a backtrace also? | 17:24 |
| RichW | I will run from terminal and try to get it. | 17:24 |
| james_w | what's the best way to get commits done on a branch to another branch in order to bind against it? | 17:25 |
| RichW | No backtrace in terminal | 17:25 |
| james_w | I'm trying to explain to someone how to use checkouts to work like subversion, but then gain offline commits. I want to explain how to get back to a bound branch when connectivity comes back. | 17:26 |
| james_w | hey LarstiQ | 17:26 |
| LarstiQ | james_w: not staved by experience, but I'd expect this to work: don't unbind when offline but commit --local; `update` when back online. | 17:27 |
| LarstiQ | james_w: please do confirm that that pivots the local commits into pending merges :) | 17:27 |
| LarstiQ | _and_ gets any new commits from master | 17:27 |
| LarstiQ | hi, btw :) | 17:27 |
| james_w | RichW: https://bugs.edge.launchpad.net/bzr-gtk/+bug/221414 sounds similar | 17:27 |
| ubottu | Launchpad bug 221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,Fix committed] | 17:27 |
| james_w | and indeed https://bugs.edge.launchpad.net/bzr-gtk/+bug/185869 | 17:28 |
| === prateeksaxena is now known as prtk | ||
| ubottu | Launchpad bug 185869 in bzr-gtk "gcommit fails with central bzr smart server" [Medium,Triaged] | 17:28 |
| RichW | What does it mean its been committed? Does it mean its in updates now? | 17:29 |
| RichW | I have latest updates as far as i know | 17:29 |
| prtk | Hello! I am trying to push a branch into launchpad, but I am getting an error - Permission denied (publickey). | 17:30 |
| prtk | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 17:30 |
| prtk | I have made my SSH key and have updated launchpad but i am still getting the error. I am a n00b. Can someone tell me what I am doing wrong | 17:30 |
| LarstiQ | prtk: are you sure you are using the correct user to connect to launchpad? | 17:31 |
| james_w | RichW: updates from where? | 17:31 |
| LarstiQ | prtk: the error it is giving you tells you that your (user, publickey) password doesn't match what launchpad expects. | 17:32 |
| RichW | Hardy hearon official repos and ive tried the official bazaar ppa. | 17:32 |
| prtk | LarstiQ: yes, "prtksxna" | 17:32 |
| LarstiQ | prtk: and the key you're trying to login with matches https://launchpad.net/~prtksxna/+sshkeys ? | 17:33 |
| prtk | LarstiQ: Where exactly am I supposed to put my key? | 17:33 |
| james_w | RichW: no, it means that it is fixed in the development branch of bzr-gtk. Ubuntu hasn't got involved at this point. Your's sounds more like the second bug that I pasted, for which there is no fix available yet. | 17:34 |
| LarstiQ | prtk: I presume you're using openssh, so that would be something like ~/.ssh/identity or ~/.ssh/id_rsa.pub | 17:35 |
| LarstiQ | prtk: btw, I hope I'm not rude asking this, but are you perhaps related to Deepak Saxena of Linux ARM fame? | 17:35 |
| LarstiQ | prtk: how long ago did you upload your ssh key to launchpad? | 17:36 |
| prtk | LarstiQ: I don't know any Deepak Saxena, but we sure have the same surname, could be related | 17:36 |
| prtk | LarstiQ: i tried one time with the one i uploaded yesterday, then with the new one | 17:37 |
| LarstiQ | prtk: launchpad only seems to know one key | 17:37 |
| prtk | LarstiQ: I am guessing that I supposed to put these files in a particular place for bzr to be able to see them (it maybe obvious to you, not me) | 17:37 |
| prtk | LarstiQ: Yeah i deleted one of them | 17:37 |
| LarstiQ | prtk: that one won't work then ;) | 17:38 |
| LarstiQ | prtk: what did you generate the key with? | 17:40 |
| prtk | LarstiQ: ssh-keygen (on my terminal) (I am on a Mac) | 17:40 |
| prtk | LarstiQ: So, sounding really stupid, to I need to put the files that ssh-keygen generated in a particular folder? | 17:41 |
| LarstiQ | prtk: by default it will put them in the right spot, afaik | 17:41 |
| LarstiQ | prtk: what files are there in your ~/.ssh ? | 17:42 |
| prtk | It puts it in the on top/root | 17:42 |
| prtk | .ssh, that would be hidden... | 17:42 |
| prtk | its empty... | 17:43 |
| prtk | Its asks for the file in which I wish to save it, then created to text files, one of them with extension .pub, | 17:44 |
| RichW | james_w: apllied fix in first launchpad bug manually and it works. | 17:44 |
| LarstiQ | prtk: ok, try ~/.ssh/identity then | 17:45 |
| james_w | RichW: great. | 17:45 |
| prtk | prateek-saxenas-computer:~/myproject/.ssh prateeksaxena$ cd identity | 17:45 |
| prtk | -bash: cd: identity: No such file or directory | 17:45 |
| LarstiQ | prtk: if you know where to find the key you already uploaded to launchpad, rename that one | 17:45 |
| LarstiQ | prtk: right | 17:46 |
| LarstiQ | prtk: I'm thinking something like 'mv ~/previous_key ~/.ssh/identity; mv ~/previous_key.pub ~/.ssh/identity.pub | 17:46 |
| prtk | That key both private and public are in the ~/myproject/ as lp and lp.pub | 17:46 |
| LarstiQ | prtk: ah ok | 17:46 |
| LarstiQ | prtk: so move them from myproject to ~/.ssh/ | 17:47 |
| prtk | LarstiQ: and rename them to? | 17:48 |
| LarstiQ | prtk: do you know if it is an rsa or dsa key? | 17:49 |
| LarstiQ | we can make it work regardeless, but it's nice to stick to the default convention if you can | 17:49 |
| prtk | LarstiQ: DSa | 17:49 |
| LarstiQ | prtk: cool | 17:49 |
| LarstiQ | prtk: you want to end up with ~/.ssh/id_dsa for the private file, and ~/.ssh/id_dsa.pub for the public one then | 17:50 |
| prtk | ok, lemme move things around (new to the Terminal as well). Gimme a minute | 17:50 |
| davidstrauss | How can I install bzr 1.5 on RHEL 5? EPEL only has 1.3, and epel-testing has nothing. | 17:50 |
| LarstiQ | davidstrauss: I'm not familiar with RHEL specific packaging, if you want to know how to do it straying out of that I can tell you though. | 17:52 |
| * LarstiQ does a quick search for it | 17:52 | |
| davidstrauss | LarstiQ: the instructions are wrong on the bzr site | 17:52 |
| davidstrauss | LarstiQ: enabling epel-testing doesn't allow me to get the latest bzr | 17:52 |
| LarstiQ | davidstrauss: I don't think http://bazaar-vcs.org/DistroDownloads says epel-testing will have the latest bzr, but that it has better chances of having newer than regular epel. | 17:53 |
| davidstrauss | LarstiQ: well, current epel has 1.3 | 17:54 |
| LarstiQ | davidstrauss: If you want to do the Right Thing (TM), I'd get the epel people to package a newer bzr. Are you interested in doing that? | 17:54 |
| LarstiQ | or do you just want to have it working now. | 17:54 |
| davidstrauss | LarstiQ: both, i guess :-) | 17:54 |
| davidstrauss | yes, i know i could install from source | 17:55 |
| LarstiQ | davidstrauss: ok, then I'll entrust you with chasing the EPEL people :) | 17:55 |
| davidstrauss | and i may do that | 17:55 |
| RichW | I downloaded the trunk version of olive "0.95" and I get this traceback when clicking "Statistics --> Log...".. pastebin: http://pastebin.com/m24964be | 17:55 |
| LarstiQ | davidstrauss: it is possible to run bzr from it's sourcedir, without installing anything. Depending on your needs. | 17:55 |
| LarstiQ | davidstrauss: ie, just unpack it and run <unpackeddir>/bzr | 17:56 |
| davidstrauss | then i'll just copy it to /opt and add it to the path | 17:56 |
| LarstiQ | davidstrauss: if it is just one user you need to do this for for a limited time, that may be a good option | 17:56 |
| davidstrauss | sticking it in /opt is perfectly clean | 17:57 |
| LarstiQ | davidstrauss: ok, for that case you might want to actually install it in /opt, that way it can compile some C code as well for speedups. | 17:57 |
| davidstrauss | LarstiQ: I think I just said I'd be doing that ;-) | 17:57 |
| LarstiQ | not entirely sure how that works with were it expects other python packages to be though, hmm | 17:57 |
| LarstiQ | davidstrauss: ok :) | 17:57 |
| LarstiQ | davidstrauss: 'copy' to me implied just that and no installing | 17:57 |
| davidstrauss | LarstiQ: Oh, I see | 17:58 |
| LarstiQ | but I may be weird in that I always run bzr from it's source dir ;) | 17:58 |
| prtk | LarstiQ: I did all that but still I get the same error | 17:58 |
| davidstrauss | LarstiQ: I have the base python system installed with EPEL | 17:58 |
| davidstrauss | LarstiQ: so that should all be in normal places | 17:58 |
| LarstiQ | prtk: can you confirm id_dsa.pub matches what is in https://launchpad.net/~prtksxna/+sshkeys ? | 17:58 |
| LarstiQ | davidstrauss: ok | 17:58 |
| prtk | LarstiQ: Yes | 17:59 |
| LarstiQ | prtk: ok, to what url are you trying to push? | 17:59 |
| prtk | bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject | 18:00 |
| LarstiQ | davidstrauss: could you try that and let me know how it goes? | 18:00 |
| LarstiQ | prtk: and it still says permission denid on the public key? | 18:00 |
| prtk | prateek-saxenas-computer:~/myproject prateeksaxena$ bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject | 18:00 |
| prtk | Permission denied (publickey). | 18:00 |
| prtk | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 18:00 |
| LarstiQ | prtk: can you access launchpad with the sftp utility? Try running 'sftp prtksxna@bazaar.launchpad.net' | 18:02 |
| davidstrauss | LarstiQ: I just did a python setup.py install | 18:02 |
| davidstrauss | LarstiQ: Slightly dirty, but OK | 18:02 |
| LarstiQ | davidstrauss: so it operates fine now? | 18:03 |
| davidstrauss | LarstiQ: I think | 18:03 |
| LarstiQ | ok :) | 18:03 |
| prtk | Connecting to bazaar.launchpad.net... | 18:03 |
| prtk | Permission denied (publickey). | 18:03 |
| prtk | Connection closed | 18:03 |
| LarstiQ | prtk: ok | 18:03 |
| LarstiQ | prtk: and 'sftp -oIdentityFile=~/.ssh/id_dsa prtksxna@bazaar.launchpad.net' ? | 18:05 |
| prtk | LarstiQ: same error :( | 18:06 |
| jam | RichW: 'committed' means someone has written a fix, 'released' means it is in a mainline branch (generally) | 18:07 |
| jam | oops, forgot to scroll to the bottom :) | 18:07 |
| prtk | prateek-saxenas-computer:~/myproject prateeksaxena$ cd .ssh | 18:08 |
| prtk | prateek-saxenas-computer:~/myproject/.ssh prateeksaxena$ ls | 18:08 |
| prtk | id_dsa id_dsa.pub | 18:08 |
| prtk | prateek-saxenas-computer:~/myproject/.ssh prateeksaxena$ | 18:08 |
| LarstiQ | prtk: that looks good to me | 18:08 |
| LarstiQ | prtk: just to be sure, can you paste the contents of id_dsa.pub on http://rafb.net/paste/ ? | 18:09 |
| prtk | LarstiQ: Yeah! But I still dont understand why it isnt working | 18:09 |
| prtk | LarstiQ: How do I open filed thru terminal? | 18:09 |
| prtk | LarstiQ: dont answer that | 18:09 |
| LarstiQ | prtk: well, for some reason launchpad doesn't think things match. So either it doesn't have the right key, you have a different key than it knows, or there is a mismatch on username. But we've gone over all those before. | 18:09 |
| LarstiQ | prtk: :) | 18:10 |
| prtk | LarstiQ: http://rafb.net/p/cQzPrp43.html | 18:11 |
| prtk | LarstiQ: Its seems to be the same | 18:12 |
| LarstiQ | prtk: yup, so that can't be the problem. | 18:13 |
| === thekorn_ is now known as thekorn | ||
| LarstiQ | prtk: have you tried doing the push with -Dhpss, and then look at the ~/.bzr.log output? | 18:13 |
| prtk | LarstiQ: Its empty | 18:14 |
| prtk | http://rafb.net/p/v7CcEO63.html | 18:15 |
| prtk | LarstiQ: http://rafb.net/p/v7CcEO63.html | 18:16 |
| LarstiQ | prtk: two things. You specified -Dpss instead of -Dhpps (dropped the h), and you should look for a file called '.bzr.log' in your homedir | 18:17 |
| LarstiQ | so 'mate ~/.bzr.log' instead of 'mate .bzr.log' from myproject would do the latter | 18:17 |
| prtk | Its it empty | 18:17 |
| LarstiQ | ok, that is very strange. | 18:18 |
| prtk | LarstiQ: Does the process differ for Mac in any way? | 18:19 |
| LarstiQ | prtk: not as far as I know, so I _really_ expect ~/.bzr.log to be there. | 18:20 |
| LarstiQ | prtk: instead of reading it from the log, you could try adding -Derror, but I'm not sure that actually gives the hpss logging on the console, instead of just the traceback | 18:21 |
| LarstiQ | prtk: so that would be bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject -Dpss | 18:21 |
| LarstiQ | eh | 18:21 |
| LarstiQ | prtk: so that would be bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject -Dpss -Derror | 18:21 |
| prtk | LarstiQ: http://rafb.net/p/ZD1dfw35.html | 18:22 |
| prtk | LarstiQ: Does that help? | 18:25 |
| LarstiQ | dang it, where did my h go? | 18:25 |
| LarstiQ | prtk: yes, but I apoligize for giving you a slightly incorrect commandline to try | 18:25 |
| * LarstiQ tries again | 18:25 | |
| LarstiQ | prtk: bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject -Dhpss -Derror | 18:25 |
| prtk | -bash: bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject: No such file or directory | 18:25 |
| LarstiQ | now with an h, as the error message said it should be | 18:25 |
| prtk | LarstiQ: wait | 18:26 |
| prtk | LarstiQ: http://rafb.net/p/SYi1Rr16.html | 18:26 |
| * prtk is frustrated with Bazaar and myself | 18:27 | |
| LarstiQ | prtk: I can understand that, although it isn't really a Bazaar problem right now. | 18:28 |
| LarstiQ | prtk: could you try using the key to login to another system? | 18:28 |
| prtk | LarstiQ: Like, this is the 1st time I have used SSH and any Subversion software | 18:29 |
| LarstiQ | you could try localhost for starters, you'll need to add (or if it doesn't exist, just copy to) id_dsa.pub to ~/.ssh/authorized_keys | 18:29 |
| LarstiQ | prtk: you do have ssh experience though? | 18:29 |
| prtk | LarstiQ: None whatsoever | 18:29 |
| LarstiQ | prtk: ah, yes, that doesn't make things easier on you. | 18:30 |
| prtk | LarstiQ: Not at all :( . But I am eager to learn | 18:30 |
| prtk | LarstiQ: So I should make another folder inside of .ssh and copy the public key inside it. Note: All this is happening in /Users/prateeksaxena/myproject | 18:31 |
| LarstiQ | prtk: no | 18:31 |
| LarstiQ | prtk: you should have a file /Users/prateeksaxena/.ssh/authorized_keys | 18:32 |
| davidstrauss | prtk: authorized_keys is not a folder | 18:32 |
| LarstiQ | prtk: it's contents should be the same as /Users/prateeksaxena/.ssh/id_dsa.pub | 18:32 |
| prtk | ok | 18:32 |
| davidstrauss | and it cannot be writable by group or world, or it will be ignored | 18:32 |
| LarstiQ | prtk: do you mean to say you have /Users/prateeksaxena/myproject/.ssh/, and not /Users/prateeksaxena/.ssh/ ? | 18:33 |
| LarstiQ | prtk: also, what davidstrauss said | 18:33 |
| prtk | LarstiQ: YEs | 18:33 |
| LarstiQ | prtk: ah, that is not what should happen | 18:33 |
| LarstiQ | prtk: whenever I say ~/<foo>, that expands to /Users/prateeksaxena/<foo> | 18:34 |
| LarstiQ | prtk: so, move /Users/prateeksaxena/myproject/.ssh/ to /Users/prateeksaxena/.ssh/ (your shell will expand ~ for you) | 18:34 |
| prtk | Ok, but the files that I need to push are in the /Users/prateeksaxena/myprojects folder... | 18:34 |
| LarstiQ | prtk: that is fine | 18:34 |
| LarstiQ | prtk: ssh will look in ~/.ssh/ for its configuration, it doesn't care where it is started from | 18:35 |
| prtk | LarstiQ: ok | 18:36 |
| prtk | LarstiQ: Done | 18:38 |
| prtk | LarstiQ: http://rafb.net/p/t0ABWi80.html | 18:38 |
| LarstiQ | prtk: ok, now that the key is in the place where ssh expects it, lets see if it wants to log in directly (or if it tells you the permission on it aren't right, or some such) | 18:40 |
| LarstiQ | prtk: 'sftp -v -o IdentityFile=/Users/prateeksaxena/.ssh/id_dsa prtksxna@bazaar.launchpad.net' | 18:40 |
| * LarstiQ notes that the -o IdentityFile.. isn't even needed when the key is at .ssh/id_dsa, it will try it by default | 18:41 | |
| LarstiQ | but it doesn't hurt | 18:41 |
| prtk | LarstiQ: I think it worked http://rafb.net/p/1eHYsg84.html | 18:43 |
| prtk | LarstiQ: I now get sftp> | 18:43 |
| LarstiQ | prtk: cool, that is what we want | 18:45 |
| LarstiQ | prtk: what did you change inbetween the failing and working attempts? | 18:45 |
| prtk | when copying to the ~ it chansed my | 18:45 |
| prtk | LarstiQ: When copying to ~ it changes my DSA public key, so I updated it again on LP | 18:45 |
| LarstiQ | okay | 18:46 |
| prtk | prateek-saxenas-computer:~/myproject prateeksaxena$ bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject | 18:46 |
| prtk | Created new branch. | 18:46 |
| prtk | Yat | 18:46 |
| LarstiQ | cool :) | 18:46 |
| prtk | YAY | 18:46 |
| prtk | LarstiQ: https://code.launchpad.net/~prtksxna/+junk/myproject WoW | 18:47 |
| LarstiQ | prtk: so to summarise, Bazaar uses openssh as it's underlying transport when you give it bzr+ssh:// urls, and openssh expects its config to be in ~/.ssh/ (the .ssh/ dir in the users homedir) | 18:47 |
| * prtk is glad that everything is working now and will push the actual code tomorrow | 18:48 | |
| prtk | LarstiQ: Thanks a lot | 18:49 |
| LarstiQ | prtk: glad to be of help. | 18:49 |
| LarstiQ | prtk: will you take this up with matsubara? | 18:49 |
| prtk | LarstiQ: As in tell him/her what the problem was | 18:49 |
| LarstiQ | prtk: yes, so he can update the FAQ | 18:50 |
| prtk | LarstiQ: Ok, but wasnt the problem very stupid wont normal developers know all this? | 18:51 |
| LarstiQ | prtk: maybe, but it would have helped you if it explicitly stated these things. | 18:57 |
| LarstiQ | matsubara will have to balance that against how long the FAQ is etc | 18:58 |
| LarstiQ | prtk: he already mentioned other people asking about this, so apparently it's not an uncommon problem (whether the cause in their cases is the same I can not say, but I'd wager it is in at least a subset) | 18:58 |
| prtk | Check #launchpad, he doesnt think its required | 18:59 |
| * LarstiQ leaves home for the night | 19:03 | |
| abentley | jam: is iter_entries_by_dir meant to guarantee a particular sort order within a directory group? | 19:15 |
| jam | abentley: I'm pretty sure it is supposed to be lexicographical within a directory | 19:16 |
| jam | not 100% positive, but pretty sure | 19:16 |
| jam | abentley: Inventory does sort them | 19:17 |
| jam | for child_name, child_ie in sorted(cur_dir.children.iteritems()): | 19:17 |
| abentley | jam: Ordering isn't guaranteed in the docstring. I have an implementation that doesn't lexicographically sort, but it fails a test because of that. | 19:18 |
| jam | abentley: I believe it is supposed to | 19:18 |
| jam | otherwise you can't iterate 2 trees side-by-side | 19:18 |
| jam | You can update the doc string if you like | 19:18 |
| abentley | Okay, will do, then. | 19:18 |
| jam | abentley: by the way, this didn't work like I would have expected "bzrlib.merge.transform_tree(tree, tree.base_tree(), [file_id])" I would have expected it to do the equivalent of "tree.revert([file_id], tree.base_tree())" any ideas why it isn't? | 19:19 |
| abentley | jam: Our revert isn't a platonic revert, so there will be differences. | 19:20 |
| abentley | In the way directories are preserved, backups are made, and so forth. | 19:21 |
| jam | abentley: well, specifically, it didn't actually revert the file, it left it untouched | 19:21 |
| jam | I was trying to get it to clean up the working directory | 19:21 |
| jam | I cribbed it from 'bzr remerge' | 19:21 |
| jam | but found that it didn't do it | 19:21 |
| jam | It caused a lot of confusion when I was remerging a text which should not have brought in a delta, and the delta wouldn't disappear | 19:22 |
| abentley | jam: No, off the top of my head, I'd expect that to work. | 19:23 |
| jam | yeah, that's why I thought there might be something more fundamentally wrong going on | 19:24 |
| jam | like file_id isn't matching up properly or something | 19:24 |
| jam | but I was using a list of file_id ('[file_id]', not 'file_id') | 19:24 |
| abentley | A list of lists of file_ids? | 19:25 |
| abentley | ['x', 'y', 'z'] should work. [['x'], ['y'], ['z']] will not. | 19:26 |
| jam | well, it should have just been a list of a single file_id | 19:26 |
| jam | sure | 19:26 |
| jam | I'll try double checking | 19:26 |
| RichW | With svn, I can use svnserve and assign people usernames and passwords. With bazaar its making me use a ssh account.. and appears that i need to make more unix accounts to give access.. but wont there be permissions problems if i want to give >1 user access to the parent branch with a seperate username and password? | 19:27 |
| RichW | How does the security model for bazaar work exactly? | 19:27 |
| jam | RichW: we expect that something else has done authentication | 19:27 |
| jam | aka, ssh, http, etc. | 19:27 |
| jam | and from there it is filesystem permissions for the given user | 19:28 |
| jam | RichW: you may want to look into 'contrib/bzr_access' (you'll want the dev version), to possibly assign permissions based on an ssh_key (at least readonly versus read-write per user) | 19:28 |
| RichW | so for example you use the http authentication? | 19:28 |
| jam | however, note that users can pretty much do whatever they want in their own branches | 19:29 |
| RichW | okay | 19:29 |
| abentley | jam: for iter_entries_by_dir, are the children groups required to appear in the order that their parents appeared? | 19:29 |
| jam | abentley: off-hand I would say yes | 19:29 |
| jam | For the same reason | 19:29 |
| jam | abentley: well, maybe not depending on what you mean exactly | 19:30 |
| jam | For example: " a/, a/b/, a/b/c, d/, d/e" | 19:30 |
| abentley | I mean if I iterate through "a", with contents "b" and "c", am I required to iterate through "b"'s contents before "c"'s | 19:31 |
| jam | you will see [a/, d/], then [a/b/], [a/b/c] | 19:31 |
| jam | and only later will you see [d/e] | 19:31 |
| jam | even though you saw "d/" before "a/b/" | 19:31 |
| jam | abentley: otherwise, yes, for two siblings, you should see all of the first siblings children before you see the second sibling's children | 19:32 |
| abentley | Okay. | 19:32 |
| abentley | ubottu: paste | 19:37 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 19:37 |
| abentley | jam: I have updated the docstring thusly: http://paste.ubuntu.com/22670/ | 19:38 |
| jam | abentley: "preceeded by the parent of *the* directory" is probably the only change I would make | 19:43 |
| jam | Though I have some other ways of saying it, I don't know that they are clearer | 19:43 |
| etank | what is the process for creating a branch of a project on launchpad? | 19:43 |
| etank | i did the "bzr branch" command | 19:43 |
| abentley | jam: It's actually the directory itself, rather than the parent of the directory, no? | 19:44 |
| etank | then went to LP and selected the register branch option | 19:44 |
| etank | but i can not push to it | 19:44 |
| jam | abentley: what about: http://paste.ubuntu.com/22672/ | 19:45 |
| jam | I was a bit confused what you were trying to say about the "preceded by" stuff | 19:45 |
| abentley | jam: Much clearer. (The "preceded by" was the original text). I'd leave out "The order that they are yielded is: " | 19:47 |
| jam | abentley: http://paste.ubuntu.com/22674/ | 19:47 |
| jam | That one has an example | 19:47 |
| jam | which are always nice to have around :) | 19:47 |
| jam | though we may need to play a small trick with the names | 19:48 |
| jam | so that they aren't strictly sorted | 19:48 |
| jam | (the top-level directories could come *before* the subdirs in pure lexicographical ordering) | 19:48 |
| abentley | I don't follow. Don't top-level directories come before subdirs anyway? | 19:49 |
| abentley | Oh, you mean that strict lexicographical would yield the contents of a subdir before yielding that subdir's sibling. | 19:50 |
| abentley | Anyhow, I think that's a vast improvement and will put it in. | 19:50 |
| jam | abentley: we've had weird edge cases with "foo/bar" and "foo-bar" | 19:52 |
| jam | that gets yielded [foo, foo/bar, foo-bar] | 19:52 |
| jam | sorry, "foo, foo-bar, foo/bar" | 19:52 |
| jam | see, I got it wrong the first time :) | 19:53 |
| abentley | hee. But the second one is the order I now expect. | 19:53 |
| abentley | When I misunderstood earlier, it's because I tend to assume that the only important ordering is that parents are emitted before children. | 19:54 |
| jam | sure, it is a over-all strict ordering | 19:54 |
| jam | so that each iterator would yield the names in a known order, and you know at all times which one is "ahead" | 19:54 |
| jam | I believe the sort key is effectively: dirname, basename = os.split(path), (dirname.split('/'), basename) | 19:56 |
| jam | abentley: we have a helper in "bzrlib.dirstate.cmp_path_by_dirblock", you can see the python code | 19:56 |
| jam | in bzrlib._dirstate_helpers_py._cmp_path_by_dirblock_py | 19:56 |
| abentley | jam: My implementation now passes the tree_implementation tests. | 19:57 |
| jam | abentley: nice, probably good enough? | 19:57 |
| jam | You can just do something like: "list(output_iter)" | 19:58 |
| jam | assert list == sorted(list, cmp=cmp_path_by_dirblock) | 19:58 |
| abentley | That's nice. I'll add it. | 19:58 |
| jam | abentley: of course, that is just on the paths :) not on the (path, entry) tuples :) | 20:00 |
| abentley | jam: Sure. If we're going to use it in the test suite, I think we should hoist it out of _dirstate_helpers.py | 20:02 |
| jam | well, you can, but they are compiled modules, so it requires moving things around a bit | 20:03 |
| jam | not really worth it, IMO | 20:03 |
| abentley | jam: Actually, iter_entries_by_dir is unicode paths, but _cmp_path_by_dirblock is str. | 20:04 |
| jam | ah... well they sort the same :) | 20:04 |
| jam | sorted(unicode_list).encode('utf8') == sorted(unicode_list.encode(utf8)) | 20:05 |
| jam | by definition of utf8 | 20:05 |
| asabil | etank: bzr push lp:~username/project/branch-name | 20:05 |
| etank | asabil: i tried that | 20:05 |
| asabil | etank: you don't need to create a branch first on LP, it is not required | 20:06 |
| asabil | just push, and things will get setup | 20:06 |
| etank | aah | 20:06 |
| etank | ok | 20:06 |
| etank | i will try that then | 20:06 |
| etank | elake@asgard:~/Code/memaker_etank$ bzr push lp:~ericlake/memaker/memaker_etank | 20:07 |
| etank | bzr: ERROR: Transport operation not possible: http does not support mkdir() | 20:07 |
| asabil | ah | 20:07 |
| asabil | etank: bzr launchpad-login | 20:07 |
| asabil | iirc | 20:07 |
| asabil | bzr launchpad-login ericlake | 20:08 |
| etank | yup. seems to be working now | 20:09 |
| etank | thanks asabil | 20:09 |
| asabil | :) | 20:09 |
| asabil | you are welcome | 20:09 |
| * abentley shakes fist impotently at gtk and loom for having broken test suites. | 20:37 | |
| jam | abentley: I had an lca question for you | 20:56 |
| jam | I'm looking at putting together LCA logic for path names, instead of always using merge3 | 20:56 |
| abentley | jam: sorry, I'll be a minute. | 20:56 |
| jam | abentley: np, I'll write it up, and you can comment later | 20:57 |
| jam | when all bases == eachother, you trivially switch back to merge3 | 20:57 |
| jam | if bases are different, you can still short-cut if 'this == other'. | 20:57 |
| jam | but is there anything we can do but conflict if this != other and all bases are not the same | 20:57 |
| jam | For "weave" we would do "if other in bases and this not in bases: this" "if this in bases and other not in bases: other" | 20:58 |
| jam | (with the idea that if one side is considered unchanged, but the other side *is* changed, then it supersedes both bases) | 20:58 |
| jam | And then if other not in bases and this not in bases, then you have a genuine conflict | 20:59 |
| beuno | james_w, blog post -> lol | 21:00 |
| james_w | hi beuno, glad you like it :-) | 21:00 |
| beuno | and thanks :) | 21:00 |
| davidstrauss | How are permissions handled when using the "Smart Server"? | 21:10 |
| Peng | Wow, Loggerhead's /changes page gzips from 82 KB to 5 KB. | 21:11 |
| davidstrauss | The smart server process theoretically has full write access. | 21:12 |
| Peng | davidstrauss: Only theoretically? | 21:12 |
| davidstrauss | Peng: and even in practice! | 21:12 |
| davidstrauss | Peng: Just theoretically because I have yet to set it up | 21:12 |
| davidstrauss | Peng: Although I may make the smart server process have only read-only access if I can't control what people do over bzr:// otherwise | 21:13 |
| james_w | davidstrauss: there are no internal permissions in the smart server, everything is based on the filesystem permissions, or something that comes before the smart server. | 21:13 |
| Peng | davidstrauss: bzr:// does no auth, so yeah, make it read-only. | 21:14 |
| davidstrauss | ok | 21:14 |
| Peng | davidstrauss: (Well, the smart server never does auth, but with bzr+http or bzr+ssh, it's easy to have the web server or sshd do it.) | 21:14 |
| davidstrauss | so bzr:// for read-only and bzr+ssh for write | 21:14 |
| james_w | over raw bzr:// it's not a good idea to allow write access unless you are on a locked down network where everyone is trusted | 21:14 |
| davidstrauss | understood | 21:14 |
| Peng | davidstrauss: You can use bzr+ssh for read access too, of course. | 21:14 |
| davidstrauss | Peng: of course, but i need a way for people to get data without me installing a key for them | 21:15 |
| Peng | Okay. :) | 21:15 |
| Peng | For anonymous read-only access, then, bzr:// is great. | 21:15 |
| davidstrauss | ok | 21:15 |
| davidstrauss | i was hoping to not need ftp or http | 21:15 |
| davidstrauss | good | 21:15 |
| === mw is now known as mw|food | ||
| abentley | jam: that sounds like it ought to be a conflict. If the bases differ, that would imply different merge resolutions. | 21:27 |
| fbond | jelmer: If I have two trees with some common ancestry in an svn repository, /trunk and /branches/foo, say... | 21:30 |
| fbond | And I use bzr-svn to like: | 21:30 |
| fbond | bzr branch svn+http://.../trunk | 21:30 |
| fbond | bzr branch svn+http://.../branches/foo | 21:30 |
| fbond | Does bzr think these two new branches have shared ancestry? | 21:30 |
| fbond | jelmer: Like, will bzr missing tell me what I would expect it to? | 21:31 |
| Jc2k | fbond: if you did svn cp trunk branches/foo at some point, then possibly | 21:31 |
| fbond | Jc2k: that's assumed. | 21:31 |
| jam | abentley: sorry, X just crashed | 21:32 |
| jam | anyway, I think if "this in bases and other in bases and this != other" that is a conflict, because they disagreed on resolution | 21:32 |
| Jc2k | fbond: if there was lots of manual merging, i don't know how will it would cope, but otherwise the answer is yes | 21:32 |
| jam | but if "this in bases and other not in bases" then it is clear that "other" should supersede both bases, right? | 21:32 |
| abentley | jam: that sounds like it ought to be a conflict. If the bases differ, that would imply different merge resolutions. | 21:32 |
| jam | abentley: if bases differ and this == other, then there is no problem | 21:33 |
| jam | I'm not sure why it isn't clear if one side supersedes | 21:33 |
| fbond | Jc2k: Well, the reason I'm asking is because that's not what I'm seeing... | 21:33 |
| fbond | Jc2k: What kind of "manual merging" would cause this? | 21:33 |
| abentley | I was reposting my reply. | 21:34 |
| jam | abentley: sure, but I think that was my original comment as well | 21:34 |
| abentley | I wasn't clear that you were saying "this in bases, other not in bases, bases not equal" | 21:35 |
| jam | it is certainly *possible* that this merged and picked one base, other merged and picked a different base, and then this superseded the result | 21:35 |
| jam | abentley: ok, lets start from the beginning :) | 21:35 |
| jam | if bases are equal, then we have simple 3-way, right? | 21:35 |
| Jc2k | fbond: i'm not very good at explaining, sorry. | 21:36 |
| Jc2k | fbond: what are you seeing? | 21:36 |
| abentley | jam: right. | 21:36 |
| jam | so the rest of this is going to assume that one of the LCA's disagreed | 21:36 |
| abentley | If bases differ, then you have different conflict resolutions. | 21:36 |
| jam | if this == other, then you have "this" without a conflict | 21:36 |
| abentley | jam: right, convergence. | 21:36 |
| jam | whether they are a base value or not, both sides obviously agree at the final result | 21:37 |
| jam | now, imagine both merge and pick base 1 | 21:37 |
| jam | and then OTHER changes it to "foobar" | 21:37 |
| jam | that should supersede, right? | 21:37 |
| abentley | That's a case where bases agree. | 21:37 |
| jam | abentley: no, because LCA's disagree | 21:37 |
| jam | and we don't share the same merge node | 21:37 |
| abentley | When both merged and picked base 1, they created new LCAs. | 21:38 |
| jam | aka, there is a Revision X from A & B which picked 1, and a revision Y from A& B which picked 1 | 21:38 |
| jam | but this doesn't have Y in its ancestry, and OTHER doesn't have X in its ancestry | 21:38 |
| jam | s/1/A/ might be a bit more obvious | 21:39 |
| fbond | Jc2k: my trunk branch thinks that it is missing *all* of the revisions in foo. | 21:42 |
| fbond | I should mention that this is what I really did: | 21:42 |
| fbond | bzr branch svn+http://.../trunk | 21:43 |
| jam | !paste | 21:43 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 21:43 |
| fbond | [make a bunch of changes to trunk] | 21:43 |
| fbond | [commit to trunk, send changes back to svn trunk] | 21:43 |
| fbond | bzr branch svn+http://.../branches/foo | 21:43 |
| fbond | So there were commits, merges, etc. to the trunk branch, and some of those commits and merges got sent back to the svn repo (with the special bzr-svn properties). | 21:43 |
| fbond | Some of those revisions eventually got merged into the svn's branches/foo before branching from foo with bzr... | 21:44 |
| fbond | So it's a little complicated... | 21:44 |
| jam | abentley: graphs for comment: http://paste.ubuntu.com/22692/ | 21:44 |
| === eMxyzptlk[away] is now known as eMxyzptlk | ||
| abentley | jam: for the last case, the two sides may agree that 'bing' has precedence over 'bar', but they don't agree that 'bar' has precedence over 'foo'. | 21:46 |
| jam | but they should agree that 'bing' has precedence over 'foo' | 21:47 |
| jam | or at least certainly one side asserts that | 21:47 |
| jam | (and certainly I can channel my inner Guilheim and see it that way, though I'm willing to be convinced otherwise) | 21:47 |
| abentley | jam: only one side asserts that. | 21:47 |
| jam | abentley: but in any 3-way scenario, one side is asserting something that the other side accepts | 21:48 |
| jam | other != base and this == base means that other > this | 21:49 |
| jam | abentley: I can understand where you are coming from, but I do think it is a case of "intelligent people can disagree" | 21:49 |
| abentley | jam: Right. We agree that it should have been "a", and I'm changing "a" to "b" | 21:50 |
| jam | And while I sort of like falling on the side of caution and issuing a conflicts | 21:50 |
| jam | mere mortals have problems with lots of conflicts | 21:50 |
| jam | as in... days of work to resolve | 21:50 |
| jam | I think some of these took a guy a week or two to resolve | 21:50 |
| abentley | jam: I think this is a UI problem, not a merge algorithm problem. | 21:51 |
| jam | so perception is that we are getting in the way when we don't have to | 21:51 |
| jam | *right now* I'm not specifically hitting this point with paths | 21:51 |
| jam | what we are generally hitting is "LCA's agree, but the path is not in the unique LCA base" | 21:51 |
| jam | which causes truly spurious conflicts | 21:52 |
| jam | so fixing that is a good step forward | 21:52 |
| jam | for now, I'm just conflicting whenever this != other and bases are not all the same | 21:52 |
| abentley | jam: In the last case, if you replace "bing" with "foo2", do you still assert that "foo2" ought to win? | 21:53 |
| jam | abentley: it would be the same reason to win | 21:53 |
| jam | I don't see how "foo2" is different than "bing" | 21:53 |
| abentley | jam: The point being that foo2 might be a single-character change of foo, basically eqivalent to foo. | 21:54 |
| abentley | I think you're right about the middle case. | 21:55 |
| jam | abentley: Right now, the texts are unimportant (IMO) other than which one supersedes which | 21:56 |
| jam | there is also another case: | 21:56 |
| abentley | In designing LCA merge, I was assuming that the lines didn't change after the criss-cross. | 21:56 |
| jam | there is also another case:http://paste.ubuntu.com/22695/ | 21:56 |
| jam | but it is just the mirror | 21:56 |
| jam | abentley: oh... they change alright :) In lots of interesting ways | 21:57 |
| abentley | jam: The reason I'm making a point about the texts is that I think you can agree that "foo" should not win-- we should get a conflict. | 21:58 |
| abentley | But from the perspective of A-B-D, "foo2" may be just as wrong as "foo". | 21:58 |
| abentley | They have spent effort, doing a correct fix, and they wouldn't want it silently obliterated. | 21:59 |
| jam | abentley: this is what I just heard from you: http://paste.ubuntu.com/22696/ | 21:59 |
| jam | Which certainly shouldn't conflict, as THIS == OTHER (convergence) | 21:59 |
| abentley | jam: I'm sorry. | 22:00 |
| abentley | I should have said bar2 all along. | 22:00 |
| jam | abentley: do you mean: http://paste.ubuntu.com/22698/ | 22:01 |
| jam | I would expect that to "win" for F versus D | 22:01 |
| jam | (under the Guilhem rules) | 22:01 |
| abentley | I don't know who this Guilhem is. | 22:02 |
| guilhembi | abentley: hi! it's me, just a user from Sun/MySQL | 22:02 |
| jam | abentley: I'm just using a term for it, but guilhem is the mysql guy | 22:02 |
| jam | abentley: Under the "if it is in my ancestry, and I supersede it, I win" | 22:02 |
| abentley | jam: But D is not in the ancestry of E. | 22:03 |
| guilhembi | jam: btw, this is out of scope and I'll shut up, but I *really* appreciate the diligence and quality work you put into these support issues. eof. | 22:03 |
| jam | abentley: but the *value* at D is | 22:03 |
| jam | as D == B | 22:03 |
| abentley | Sure, but D is an assertion that B is wrong. | 22:03 |
| jam | so there was "no change" | 22:03 |
| abentley | That C is worng. | 22:03 |
| jam | technically it is an assertion that C is wrong | 22:03 |
| jam | and F ends up agreeing :) | 22:03 |
| jam | C is wrong | 22:03 |
| jam | guilhembi: are you following the discussion? Do you feel like I am representing your position? | 22:04 |
| abentley | jam: But F is based on C. | 22:04 |
| guilhembi | jam: uh, I didn't follow it, and I was rather heading to bed :/ | 22:04 |
| guilhembi | but I can read it from irc logs tomorrow | 22:04 |
| abentley | And A-B-D thinks that C is wrong. | 22:04 |
| jam | guilhembi: no problem, sleep tight | 22:04 |
| guilhembi | thanks | 22:05 |
| abentley | And so they likely would consider F to also be wrong. | 22:05 |
| jam | abentley: so... it may just be a UI thing, but I know that when guilhem comes to me to ask why this is conflicting, he uses stuff like gannotate, and notices that everything that conflicts was already in the merged ancestry | 22:05 |
| guilhembi | yes, gannotate or annotate. | 22:05 |
| jam | we don't have any way of showing them "this conflicts because of D". | 22:05 |
| abentley | jam: right. | 22:06 |
| guilhembi | and also, "another RCS automerged it fine" (TM) | 22:06 |
| jam | in fact, 'bzr annotate' will never mention D | 22:06 |
| jam | because its text matches the parents | 22:06 |
| jam | guilhembi: I think the retort is "just because another VCS is broken, doesn't mean we need to be" :) | 22:06 |
| guilhembi | jam: yes, I knew you would say that :) | 22:07 |
| abentley | jam: so there are things we can do. | 22:07 |
| jam | abentley: in fact, D could be a conglomerate of B and C, and as long as it doesn't introduce new texts, it won't get shown | 22:07 |
| jam | aka, D is a completely unique text, but doesn't get any lines attributed to it | 22:07 |
| jam | as it is just a mash up of existing texts | 22:08 |
| abentley | One thing is to distinguish between conflicts and conflicting resolutions in our merge output. | 22:08 |
| abentley | another thing is to provide ways for the user to pick one resolution over another. | 22:08 |
| jam | abentley: you mean a "bzr remerge --this" ? | 22:10 |
| abentley | jam: or even merge --this. | 22:10 |
| jam | abentley: sure, though I would hope that you wouldn't want to do it to *all* of your files | 22:10 |
| abentley | If you believe it's suitable for one file, why wouldn't it be suitable for all? | 22:11 |
| jam | abentley: because some files conflict while others have genuine changes | 22:11 |
| jam | in ways described here | 22:11 |
| jam | --this would ignore all the real changes you are merging | 22:12 |
| abentley | Are you now talking about three-way conflicts compared to conflicting resolutions? | 22:12 |
| jam | abentley: well are you saying that '--this' is only active for conflicting resolutions? | 22:12 |
| jam | Or is it active for all conflicts? | 22:12 |
| abentley | jam: That's what I was thinking, yes. Similar to how weave behaves. | 22:13 |
| jam | abentley: also, there is a problem that the "middle case" is one that can't really be distinguished from the contentious case without inspecting the intermediate nodes | 22:13 |
| jam | which is something that I'm trying hard to avoid | 22:13 |
| abentley | I think it's impossible to distinguish the middle from the bottom without inspecting D and E. | 22:16 |
| abentley | But maybe *only* D and E need to be inspected? Not sure about this. | 22:16 |
| jam | abentley: well, you could have E == 'XXX', Echild='foo', when you decided that the other was really correct after all | 22:17 |
| === mw|food is now known as mw | ||
| jam | abentley: hmm... I have another small problem with paths on disk... | 22:20 |
| jam | In one LCA, it has name "Foo", in 2 others it is not present | 22:21 |
| jam | in this it is named "prefix_Foo" | 22:21 |
| jam | and from what I recall, guilhem was thinking it would be named "Foo" in THIS. | 22:21 |
| jam | which doesn't fit *my* best guess | 22:21 |
| jam | oh, maybe it is just because the conflict renames it | 22:22 |
| jam | and he didn't know which name it should have | 22:22 |
| lifeless | moin | 22:22 |
| jam | good morning lifeless | 22:23 |
| lifeless | Jc2k: hi | 22:51 |
| Jc2k | lo lifeless | 22:51 |
| Jc2k | google bot seems to have found bzr-mirrors loggerhead! | 22:52 |
| lifeless | cool | 22:52 |
| lifeless | did that search finish ok with the reduced threshold ? | 22:52 |
| Jc2k | ah, i forgot to rerun that | 22:53 |
| lifeless | also, did you file a bunch of bugs for the things ou mentioned | 22:54 |
| lifeless | about what some gnome devs are crying out for | 22:54 |
| Jc2k | now that i didnt forget, i just passed out after first day at codethink :p | 22:57 |
| lifeless | how was it? | 22:57 |
| Jc2k | awesome | 22:57 |
| Jc2k | its quite twisted though, im hacking on a fork of git.. | 22:58 |
| lifeless | yah, I read | 22:58 |
| lifeless | ironic, no? | 22:58 |
| Jc2k | indeed | 22:58 |
| bkor | Jc2k: what are they crying out for? | 22:58 |
| Jc2k | hopefully it will make my cries of "no git!!" more valid | 22:59 |
| lifeless | "My name is John, and I'm powerless" | 22:59 |
| Jc2k | bkor: robtaylor wants rebase | 22:59 |
| Jc2k | (--interactive) | 22:59 |
| lifeless | -i specifically yeah? | 22:59 |
| Jc2k | yep | 23:00 |
| bkor | Jc2k: that is it? | 23:00 |
| Jc2k | hell no | 23:00 |
| lifeless | ahha | 23:00 |
| Jc2k | its just one that sprang to mind. | 23:00 |
| === mwhudson__ is now known as mwhudson | ||
| Jc2k | the other one is, some pople really want the combined single folder for working tree and all branches | 23:00 |
| Jc2k | i can perhaps see usefulness of that when we couple it up to jhbuild | 23:01 |
| bkor | yeah.. they want the existing compilation thingy | 23:01 |
| bkor | meaning: branch for just a small change.. then it is handy when the compilation is as fast as possible | 23:02 |
| lifeless | did you guys see the http://kubasik.net/blog/tag/bzr/ post ? | 23:02 |
| lifeless | bkor: we have that small change thingy though via switch | 23:02 |
| lifeless | bkor: implementation vs interface difference I guess; the key thing is 'I have two branches and I can switch' | 23:03 |
| lifeless | but... I suspect that it may be more efficient to say 'ok here is a plugin that makes it look like git; now when you know the system more you may appreciate what we do' | 23:03 |
| Jc2k | indeed | 23:03 |
| Jc2k | bzr-gitmode | 23:04 |
| bob2 | gitanamo! | 23:04 |
| bkor | lifeless: btw, in one of the 'should use git' posts (IIRC on planet ubuntu), someone showed a not too descriptive bzr error msg | 23:05 |
| lifeless | bob2: groan | 23:05 |
| bkor | I don't like the advocacy style though.. 'found an unclear error msg and git it better, so git is great' | 23:05 |
| bkor | and the 'everyone knows git' + 'every dvcs is hard to understand' | 23:06 |
| lifeless | I related that one to martin | 23:06 |
| lifeless | he fell over laughing | 23:06 |
| lifeless | "its true though, *IF* every vcs were as hard to learn as git" | 23:06 |
| mwhudson | Jc2k: hello | 23:28 |
| mwhudson | Jc2k: have you seen any problems like https://bugs.edge.launchpad.net/loggerhead/+bug/242580 ? | 23:28 |
| ubottu | Launchpad bug 242580 in loggerhead "Current trunk tends to peg CPU at 100% after running a while, for no obvious reason" [Undecided,New] | 23:28 |
| lifeless | Jc2k: so yes, please file bugs for -i and having an optional all-branches-in-one-dir facility | 23:28 |
| Jc2k | mwhudson: no i havent | 23:29 |
| mwhudson | Jc2k: thanks | 23:29 |
| Jc2k | lifeless: will do | 23:29 |
| mwhudson | it's probably a bug in the config support, /me hopes | 23:29 |
| lifeless | Jc2k: and any other things that you think are important | 23:30 |
| jam | lifeless, Jc2k: I've been running with a "multiple branches, 1 working tree" for a bit now, and while there are some things missing still, I think it works rather well | 23:30 |
| jam | the big missing thing is a "bzr clone" that gets multiple branches | 23:31 |
| jam | I also find that I often *need* several live trees at once | 23:31 |
| jam | so having the flexibility of both is pretty nice | 23:31 |
| jam | (like, what was that really in bzr.dev, and working on multiple features at once, and neither is quite ready to commit) | 23:31 |
| lifeless | jam: yes; the point here is not that we have an alternative implementation; its that we're facing folk who argue for an implementation not a facility | 23:31 |
| jam | abentley: In "_merge3" you use "iter_changes(include_unchanged=True)" why do you want unchanged files here? | 23:47 |
| jam | sorry, that is "Merge3Merger._entries3" | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
