Peng_ | mwhudson: Hi. | 01:21 |
---|---|---|
mwhudson | Peng_: hi | 01:21 |
Peng_ | (Actually, I'm totally not here right now.) | 01:21 |
mwhudson | i was going to ask something about loggerhead, but i forget wat | 01:21 |
Peng_ | mwhudson: Anyway, w -- ah. | 01:21 |
mwhudson | i was probably just going to tell you to merge your branches, but i see they have merge proposals so i'll comment there i guess :) | 01:22 |
igc | morning all | 01:22 |
mwhudson | when i emerge from my pile of email | 01:22 |
mwhudson | hello igc | 01:22 |
Peng_ | igc: Good morning. :) | 01:22 |
Peng_ | Well, if you remember what it was, I should be back in maybe 30 minutes. Or maybe 1-2 years; I'm a bit tired. :D | 01:25 |
Peng_ | If I do sleep for 2 years, please don't deprecate pack-0.92 while I'm gone. :D | 01:25 |
igc | so today's focus for me: nested-tree review; benchmark, tweak & announce https://launchpad.net/bzr-historycache | 01:29 |
=== TheMuso_ is now known as TheMuso | ||
levo | hey, anyone around to help a newbie? I'm having problems with getting rename to work. | 03:24 |
levo | I modified and moved some files, but bzr mv complains the destination dir. isn't versioned | 03:26 |
levo | or if I add the destination dir, it complains the source isn't versioned, but it's marked as removed in bzr status | 03:26 |
Peng_ | levo: Did you rename the dir as well? Have you bzr added it? | 03:26 |
Peng_ | levo: Hmm, not sure. But you may want "bzr mv --after". | 03:27 |
levo | that's what I'm using, I can't find any way to get it to work though :/ | 03:27 |
Peng_ | Oh. | 03:27 |
Peng_ | My only other suggestion is that a newer version of bzr might be better, but I really don't know. Sorry. | 03:28 |
* Peng_ hopes someone else is here. | 03:28 | |
Peng_ | Pastebinning the list of commands you ran may help. | 03:28 |
levo | OK, thanks Peng, I'm not running the RC yet but I'll try that | 03:29 |
bob2 | did you ad the destination dir? | 03:30 |
bob2 | bzr add -N thatdir | 03:30 |
bob2 | then mv --after | 03:30 |
levo | It says the target file is already versioned: | 03:31 |
levo | bzr: ERROR: Could not move string.h => string.h: reusable/string.h is already versioned | 03:31 |
Peng_ | bob2: -N? | 03:31 |
bob2 | then un-add it | 03:32 |
levo | to bzr add? it says no such option | 03:32 |
bob2 | what? | 03:32 |
bob2 | pastebin the output of 'bzr status' | 03:32 |
levo | bzr add -N says no such option, not sure if that's what you mean though | 03:33 |
bob2 | pastebin the output of 'bzr status' | 03:34 |
levo | http://pastebin.com/d6c2d994b | 03:34 |
levo | I basically moved the directories 'test' and 'reusable' out of source up to the top level, sorry its kind of spammy | 03:37 |
bob2 | yowch | 03:37 |
bob2 | in future, use bzr mv | 03:37 |
bob2 | that is easy to recover, you also added a bunch of other files | 03:37 |
levo | lol I'm hosed aren't I? | 03:37 |
bob2 | no | 03:38 |
spiv | 1.14rc1 adds "bzr mv --auto" which would probably do a good job here. | 03:38 |
spiv | (After unadding the moved files, of course) | 03:38 |
bob2 | mv reusable/threading/ ,,f ; for thing in resuable/* ; do bzr rm --keep $thing ; bzr mv --after rc/$thing $thing ; done ; mv ,,f reusable/threading | 03:39 |
bob2 | or so | 03:39 |
lifeless | spiv: whatcya up to today? | 03:40 |
* bob2 wonders if he will ever shake ,, | 03:40 | |
levo | trying to parse all that, I'm on windows :p | 03:41 |
bob2 | yowch | 03:41 |
lifeless | bob2: {{}} | 03:41 |
spiv | lifeless: have finally upgraded to Jaunty, happily minimal fallout so far :) | 03:44 |
spiv | lifeless: am about to embark on lunch, but would love a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090417141519.GA9721%40steerpike.home.puzzling.org%3E | 03:44 |
Peng_ | Stupid question because I'm lazy: Can "merge --uncommitted" work over a remote branch? | 03:44 |
spiv | Peng_: off the top of my head, no, because we don't (yet?) support reading non-local working trees. | 03:45 |
Peng_ | Yeah, I just tried it, and you're right. | 03:45 |
lifeless | PathNotChild: Path "/extra" is not a child of path "/extra/" | 03:51 |
lifeless | spiv: it smells a little off | 03:53 |
levo | thanks for the help everyone, I managed to get it all sorted out | 04:01 |
levo | kind of understand why it wasn't working automatically now | 04:02 |
levo | kind of a confusing diagnostic to say that the source isn't versioned, although I don't know what it should say instead since I don't understand exactly why it couldn't be moved in terms of the internal mechanics | 04:08 |
lifeless | I think there is a ui bug | 04:09 |
lifeless | but I'm glad you're up and running | 04:09 |
levo | thanks! and thanks for bzr, it's awesome | 04:10 |
lifeless | spiv: ping | 04:26 |
lifeless | spiv: How would you feel if we stopped PathNotChild occuring with foo, foo/ | 04:26 |
spiv | lifeless: so long as there's no risk of foobar being accidentally allowed, I suppose it's ok. I'm a little surprised it's not already accepted come to think of it. | 04:48 |
spiv | lifeless: I thought it did a bit of path normalisation before checking for PathNotChild? | 04:48 |
=== abentley1 is now known as abentley | ||
=== abentley1 is now known as abentley | ||
BasicPRO | blah, bad time for LP to sit down | 05:28 |
spm | BasicPRO: which part is sitting down? | 05:32 |
BasicPRO | code | 05:32 |
spm | wfm. can you give a url or similar? | 05:34 |
BasicPRO | http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/files | 05:35 |
BasicPRO | click "NEWS" | 05:36 |
spm | interesting. readme gives an internal error as well. mwhudson ^^ <== | 05:38 |
* mwhudson looks | 05:38 | |
mwhudson | spm: it's timing out for me, is that what you mean? | 05:39 |
BasicPRO | means I broke it? :-( | 05:39 |
=== BasicPRO is now known as BasicOSX | ||
spm | mwhudson: partially. the NEWS file times out. README gives an informative "Internal Server Error" - nothing else :-( | 05:39 |
mwhudson | i wonder if pygments is being insane, or annotate being slow | 05:40 |
spm | bouncy time? see if that helps? | 05:40 |
mwhudson | won't make a difference for the ISE | 05:41 |
spm | mwhudson: I live in hope that it would :-) | 05:44 |
mwhudson | um | 05:44 |
mwhudson | BasicOSX: i presume "bzr annotate README" works for you? | 05:44 |
BasicOSX | yes | 05:45 |
mwhudson | hm | 05:46 |
mwhudson | BasicOSX: bzr annotate http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/README fails for me | 05:50 |
mwhudson | BasicOSX: i don't know what's going wrong, but i plead NMF :) | 05:50 |
BasicOSX | does that mean I did something wrong when I setup the branch? | 05:51 |
spiv | BasicOSX: it appears you've been hit by bug 354036 | 05:58 |
ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036 | 05:58 |
BasicOSX | heh | 05:58 |
spiv | BasicOSX: did you use your 1.14rc2 branch to push it up? :) | 05:58 |
BasicOSX | bzr.dev | 05:58 |
spiv | Huh! | 05:58 |
spiv | That's a worry :( | 05:59 |
BasicOSX | Bazaar (bzr) 1.15dev r4299 | 05:59 |
BasicOSX | It would be initial push tho right? | 05:59 |
BasicOSX | Not the last one I just did? | 05:59 |
spiv | Right. | 05:59 |
BasicOSX | that was bzr.dev before patch | 05:59 |
spiv | As in, if any pushes had been done with unfixed bzr.dev... | 06:00 |
spiv | Ah, phew :) | 06:00 |
spiv | Ok that explains it then. Deleting the branch (or at least deleting the remote .bzr dir) and repushing will fix the problem. | 06:01 |
spiv | (I'm not sure that this is the cause of viewing README triggering Internal Server Error, although it could be) | 06:02 |
lifeless | I don't think it is | 06:04 |
BasicOSX | PQM playing 1.14rc2 | 06:09 |
lifeless | cool | 06:10 |
lifeless | I'm beat; had a fluvax shot yesterday and my arm has been killing me | 06:10 |
lifeless | if anyone needs me call my mobile | 06:10 |
BasicOSX | grrr, comcast I hate you | 06:22 |
mwhudson | spiv, lifeless: it is why viewing README triggers a 50x | 06:23 |
mwhudson | at least, the error i got on the command line was the same one i found in the logs | 06:23 |
spiv | mwhudson: which error? I get a "No such file" on the command line. | 06:39 |
mwhudson | spiv: maybe BasicOSX has done stuff to the branch already | 06:40 |
mwhudson | it ended with | 06:40 |
mwhudson | parent_lines = [parent_cache[parent] for parent in parent_map[key]] | 06:40 |
mwhudson | KeyError: ('README-20050309040720-8f368abf9f346b9d', 'abentley@panoramicfeedback.com-20070612162140-vea2zg1sbw6kckic') | 06:40 |
spiv | mwhudson: ah ok. Yes, that does look possibly related. | 06:42 |
jelmer | moin | 08:56 |
jelmer | looks like all working tree stuff on git indexes is working | 09:13 |
jelmer | except for commits | 09:13 |
=== BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14rc2 released 20 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
robin_dewd | cool. :-) I got your dulwich and bzr-git stuff from trunks I think and even updated bazaar to trunk as well (1.15dev) and was not able to make much with it at this point | 09:20 |
igc | me dinner | 09:20 |
jelmer | robin_dewd: what didn't work exactly? | 09:24 |
jelmer | there have been a lot of changes in the last few days | 09:24 |
robin_dewd | i tried a couple of things with it | 09:25 |
robin_dewd | one was to clone a git repository from github (I was excited alright ;-) | 09:25 |
robin_dewd | other was to branch from a local repo on a near directory | 09:25 |
jelmer | rockstar: if you can get it to blow up with the current version, please file bugs :-) | 09:31 |
jelmer | I can get it to work on most things right now, I fixed a couple of nasty issues | 09:31 |
bignose | how can I remove an un-wanted loom from a branch? | 09:42 |
Kinnison | Not sure, the help for "combine-thread" suggests that will, in the future, unloomify a branch | 09:50 |
lifeless | bignose: once it has only one thread its ~= to a branch; just export the thread and remove the loom | 09:53 |
lifeless | bignose: obviously this could be improved | 09:53 |
bignose | no hackery in the branch that can be done? | 09:54 |
lifeless | not trivially no | 09:55 |
lifeless | this would work: | 09:55 |
lifeless | bzr export-thread ../foo | 09:55 |
lifeless | rm -rf .bzr/branch | 09:55 |
lifeless | mv ../foo/.bzr/branch .bzr | 09:56 |
bignose | can I branch from a loomified branch, and specify that the new branch should *not* have a loom? | 09:56 |
lifeless | not currently, its a good idea; you can export the top thread though | 09:56 |
bignose | okay, that's the chosen workaround then. | 09:56 |
bignose | thanks. | 09:56 |
bignose | hmm wait, how do I export from one branch to another branch? exporting to a directory just exports a working tree. | 09:57 |
bignose | oh, export-thread | 10:03 |
bignose | an undocumented command :-( | 10:03 |
bignose | actually, a non-existent command (bzr-loom 1.4.0~bzr93-2) | 10:04 |
bignose | so, with no "branch without getting a loom" command, and with no "export-thread" command | 10:05 |
bignose | how can I get a branch from branch 'foo/' without a loom? | 10:06 |
lifeless | bignose: sorry, its just export-loom | 10:08 |
lifeless | export-thread has been discussed not done | 10:08 |
bignose | hmm. and if I have no threads, export-loom does nothing? | 10:13 |
bignose | attempting to create a thread in a loom that has no threads gives an AssertionError | 10:15 |
bignose | assert after_thread is None or after_thread in state.get_threads_dict() | 10:15 |
lifeless | uhm, having no threads == having no branch - you have no tips at all | 10:25 |
lifeless | I'm not sure how you'd even get to that state | 10:25 |
bignose | well, 'bzr show-loom' shows no threads, but 'bzr info', 'bzr check' and 'bzr status' all seem happy | 10:34 |
bignose | 'bzr log' shows revisions as expected | 10:34 |
jelmer | lifeless: so, it would be nice if it would be possible to support just record_iter_changes() or record_entry_contents() in CommitBuilder implementations | 10:36 |
jelmer | lifeless: does it sound sensible to e.g. add a "supports_record_iter_changes" and a "supports_record_entry" contents variable to CommitBuilder | 10:36 |
bignose | same when I branch; the new branch is also showing fine, but has no threads when I 'show-loom' | 10:36 |
jelmer | lifless: that influences the decision of Commit() as to what to use? | 10:36 |
bignose | so, I'm stuck on this branch; if the loom is broken, I don't know what else might break and I don't want to continue relying on this branch | 10:40 |
bignose | but apparently I can't remove the loom. | 10:40 |
lifeless | jelmer: I want to migrate to just ric | 10:42 |
lifeless | jelmer: multiple codepaths indefinitely is not attractive | 10:43 |
jelmer | lifeless: Ok | 10:49 |
jelmer | lifeless: I'd like a way to say I'd always like ric then :-) | 10:49 |
jelmer | lifeless: I already have that for bzr-git | 10:49 |
jelmer | and I don't feel like implementing record_entry_contents, too | 10:49 |
lifeless | jelmer: there is a comment in commit.py about this | 10:51 |
lifeless | jelmer: until its safe in all those cases we can't force it to ric always | 10:51 |
lifeless | it will be faster once we can, so its important to aim for that | 10:51 |
=== Bambi_BOFH is now known as Kamping_Kaiser | ||
jelmer | lifeless: hmmok | 10:54 |
lifeless | jelmer: in particular you can't have a iter_changes on your trees that is actually both correct-for-status and correct-for-commit when new directories are added and specific files is selected | 10:55 |
lifeless | and iter_changes doesn't do excludes at all yet | 10:57 |
lifeless | so the fastest way to get ric used only, is to fix these issues in bzr core | 10:57 |
bignose | lifeless: okay, a workaround that worked: | 11:01 |
bignose | bzr init bzr/ && cd bzr/ && bzr pull ../foo/ | 11:01 |
bignose | erm, s/init bzr/init bar/ | 11:01 |
bignose | causes the new branch 'bzr/' to have no loom but have all the revisions from 'foo/' as desired | 11:02 |
bignose | argh | 11:02 |
bignose | new branch 'bar/' that is. | 11:02 |
bignose | damned muscle memory :-) | 11:02 |
jelmer | lifeless: hmm | 11:08 |
* bignose hopes all his wild assertions about Bazaar looms on the mailing list are actually true | 11:29 | |
finiteset | how do I checkout an old revision from my project? | 12:30 |
lifeless | if you have a tree you're in, bzr revert -r X, or if you want a new tree, bzr branch -r X sourcebranch / bzr checkout -r X sourcebranch | 12:33 |
finiteset | I have a project using in bzr and I want to check out an older revision of it to a different location. | 12:35 |
mars | why does the shelve command offer the options "yes", "no", "finish", and "quit"? Shouldn't that be "yes", "no", "all", "quit"? | 13:02 |
mars | ah, nevermind - finish means "done", doesn't it? And quit actually means "abort"? | 13:03 |
ddaa | Hello, | 13:52 |
beuno | hi, | 13:53 |
ddaa | When trying to use bzr-hg, "bzr pull ../hg-branch" fail with a "AssertionError: KnitPackRepository('file:///home/david/Documents/Akamao/akamao.bzr/.bzr/repository/') not in write group" | 13:53 |
ddaa | raised from File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 660, in add_inventory | 13:53 |
ddaa | Any idea what that means, and how I can work around or fix this? | 13:54 |
ddaa | I have no idea what this "write group" concept is. Is this something new? | 13:54 |
ddaa | Mh... I guess I could try adding some repo.start_write_group() and repo.commit_write_group()... | 13:56 |
ddaa | Maybe add in a couple of chicken bones. | 13:57 |
ddaa | mh... it will probably be quicker to learn hg than to turn bzr-hg into something usable | 14:07 |
lifeless | ddaa: jelmer has a bzr-hg branch that is more advanced, I believe | 14:09 |
lifeless | ddaa: write groups are broadly transactions, they are the basis of packs | 14:10 |
ddaa | lifeless: hello mate | 14:10 |
lifeless | :) hi | 14:10 |
ddaa | yup, actually, just after asking I started remembering, and used grep powers to find out the relevant methods. | 14:10 |
ddaa | I patched the write-group thing, but now I have an error where the branch head revision cannot be found in the repo. | 14:11 |
* ddaa is using launchpad's trunk, is going to check whether jelmer has an active personal branch. | 14:12 | |
lifeless | catch you later | 14:12 |
lifeless | <afk | 14:12 |
=== jelmer_ is now known as Guest60279 | ||
=== Bambi_BOFH is now known as Kamping_Kaiser | ||
=== thunderstruck is now known as gnomefreak | ||
LeoNerd | How do I stop this fscking annoying popup window that says there's a new revision, every time I commit to a branch? It seems to have started recently, since a debian update... | 16:05 |
Kinnison | presumably you now have the bzr-gtk notification doobry running | 16:07 |
Kinnison | look for "bzr-notify" in your process list | 16:07 |
LeoNerd | Ahyes. There it is. Just kill it? Or will something start it up again? | 16:10 |
* ddaa is kinda puzzled at how mercurial requires one to edit the ~/.hgrc in a trivial way to enable bundled extensions. | 16:10 | |
Kinnison | I imagine it'll start on desktop start | 16:10 |
Kinnison | see /etc/xdg/autostart | 16:10 |
Kinnison | there'll be bzr-notify.desktop in there | 16:11 |
Kinnison | not sure how you disable it short of rm -f the file | 16:11 |
LeoNerd | Ahyes | 16:11 |
* Kinnison just got used to it | 16:11 | |
Kinnison | :-) | 16:11 |
LeoNerd | $ sudo mv bzr-notify.desktop bzr-notify.desktop.NOYOUFSCKINGDONT | 16:11 |
LeoNerd | Hrm.. shame I can't even chmod -x it | 16:12 |
awilkins | I saw an article that put forward the idea that .desktop files were the equivalent of Outlook worms for GNOME | 16:12 |
LeoNerd | It is annoying that there doesn't seem to be a local policy override thing | 16:13 |
Kinnison | No idea if removing it from the session applet would do the trick | 16:14 |
Kinnison | sorry | 16:14 |
Kamping_Kaiser | why dont you just remove the package? | 16:16 |
Kinnison | bzrk is too useful I imagine | 16:16 |
Kinnison | Unfortunately bzr-notify is part of bzr-gtk | 16:16 |
ddaa | awilkins: it's not nearly as bad it sounds. The problem basically is that the rest of the system assumes that not setting the execute permission on a file will prevent it from being executed accidentally, but .desktop files can be executed by nautilus regardless of the execute permission. | 16:17 |
Kamping_Kaiser | ah | 16:17 |
james_w | LeoNerd: cp /etc/xdg/autostart/bzr-notify.desktop ~/.local/share/applications/ | 16:17 |
james_w | then edit ~/.local/share/applications/bzr-notify.desktop to have "NoDisplay=True" | 16:18 |
LeoNerd | Ya.. None of my files have +x on | 16:18 |
james_w | "NoDisplay=true" perhaps | 16:18 |
LeoNerd | james_w: Ahh.. Hrm.. Can I just set that value in /etc ? | 16:18 |
LeoNerd | (go go magic negative-options) | 16:18 |
james_w | yep | 16:19 |
moquist | Is it possible for me to edit my bzr log messages after commit? | 16:21 |
Kinnison | No[*] | 16:21 |
moquist | james_w: hey! I was just dusting my bzr bd skillz off the other day and thought of you. | 16:21 |
Kinnison | [*: Yes, but not really, erm, urp] | 16:21 |
moquist | Kinnison: possible but highly discouraged? | 16:22 |
ddaa | moquist: [*] you can get a similar effect using uncommit, and rebase if you want to change a commit message that is before other commits you do not want to change. | 16:22 |
igc | night all - see you next week after I return from leave | 16:22 |
ddaa | Of course, that will confuse merge/pull, etc for every branch out there that contains revisions that were changed/rebased. | 16:23 |
moquist | ddaa: Hmm. I have lots of messages that say (e.g.) "yeep" b/c I was just making tiny changes in my own repo...but now I want to publish this, and I figure the rest of the world won't find "yeep" very helpful. | 16:23 |
ddaa | moquist: was that understandable, our do you need spelled it out more? | 16:23 |
moquist | ddaa: maybe. I'll look into it first. | 16:23 |
moquist | I might just inflict yeeps on the world. | 16:24 |
ddaa | Here's how I would go about it: | 16:24 |
ddaa | 1. inflict "yeep" on the world | 16:24 |
moquist | ddaa: heh. Sounds good to me. :-D | 16:25 |
ddaa | 2. failing that, for every revision do something like "merge -r2..3 ../orig; commit -m 'nice message'" | 16:25 |
james_w | hey moquist | 16:25 |
ddaa | when specifying a range to merge, you actually do (essentially) a diff+patch, without referring to the merged revisions in the parents. | 16:25 |
ddaa | But it's going to be quite tedious if you have more than a half-dozen revisions. | 16:26 |
moquist | ddaa: yeah. not too many more, but maybe 10-15 messages to change. | 16:26 |
* Kinnison recommends option 1 | 16:28 | |
Kinnison | with addendum: "Learn not to yeep in future" | 16:28 |
* ddaa ruffles Kinnison. | 16:28 | |
moquist | yeah...that's the real moral of the story. | 16:28 |
moquist | thx! | 16:28 |
Kinnison | There's some *really* crap commit messages in the world from me | 16:31 |
moquist | Kinnison: I pledge never to hold them against you. | 16:31 |
Kinnison | So kind :-) | 16:31 |
Keybuk | jelmer: so I installed bzr-git | 16:38 |
Keybuk | and it doesn't show up in bzr plugins | 16:38 |
Keybuk | and thumper said to ask you ;) | 16:38 |
jelmer | Keybuk: Did you install the package or from the bzr branch? | 16:39 |
jelmer | Keybuk: No warnings from bzr about it not being able to load the plugin ? | 16:39 |
Keybuk | jelmer: the bzr branch | 16:40 |
Keybuk | there is no package | 16:40 |
Keybuk | wing-commander scott% apt-cache search bzr-git | 16:40 |
Keybuk | wing-commander scott% | 16:40 |
jelmer | Keybuk: It's not in Ubuntu (yet), just experimental for now | 16:41 |
jelmer | The bzr branch is probably the best source for it for now anyway, given the rate of changes | 16:41 |
jelmer | Keybuk: So you have it in ~/.bazaar/plugins/git, are there any warnings about it not being able to load in ~/.bzr.log? | 16:42 |
Keybuk | it went into /usr/local/lib somewhere | 16:42 |
Keybuk | it doesn't work anyway - managed to get bzr to see it and it complained it needed 1.15 | 16:42 |
=== thekorn_ is now known as thekorn | ||
jelmer | ah, yes, it unfortunately does at the moment; remote git servers are a bit limited in what they support | 16:44 |
jelmer | so I had to patch bzr, and that change won't land until 1.15 | 16:45 |
Keybuk | ok | 16:47 |
Keybuk | oh well | 16:47 |
* Kinnison wows | 16:47 | |
Kinnison | bzr managed to use my link fully just now | 16:47 |
* Kinnison gives it the 1MB/s prize | 16:47 | |
jelmer | Kinnison: :-) | 16:48 |
Kinnison | hah, now it's lying, claiming 1.4MB/s which is faster than my link goes, while actually doing bugger all network traffic | 16:49 |
* Kinnison takes the prize back and gives bzr a wooden spoon | 16:50 | |
* Kinnison pouts -- python-dulwich is too old in intrepid | 16:57 | |
jelmer | Kinnison: Yeah, development has been going pretty quickly (un)fortunately | 17:06 |
jelmer | Kinnison: I suspect it'll have slowed down enough for Koala | 17:07 |
awilkins | Kinnison: Is is possible your 2MBit/s connection has just been upgraded to 10Mbit/s - your ISP is doing that. I only noticed when things went _pchow_. | 17:08 |
awilkins | 1.4 MB/s would fit 10Mbit/s | 17:08 |
* awilkins could also be mad | 17:09 | |
Kinnison | awilkins: Erm, the only thing I'm waiting for is my 10Mbit/s service to be upgraded to 20Mbit/s | 17:11 |
* Kinnison is on business-grade cable | 17:11 | |
* SamB_irssi attempts to push to SVN using bzr-svn ... | 17:28 | |
SamB_irssi | jelmer: how do I specify what user to use for a specific SVN server ? | 17:37 |
=== bob2 is now known as Guest28542 | ||
joaopinto | hello, I am getting the "http does not support mkdir" that is usually related to the missing launchpad-login | 18:39 |
joaopinto | I need to commit some changes, and it's always trying to use the http method, how to I change it to bzr+ssh ? | 18:41 |
cody-somerville | joaopinto, does it say that when you commit? | 18:45 |
cody-somerville | joaopinto, ie. do you have a binded branch/checkout? | 18:45 |
joaopinto | cody-somerville, yes, it shows the http branch | 18:45 |
cody-somerville | joaopinto, just do bzr bind <bzr+ssh url> | 18:46 |
joaopinto | ah | 18:46 |
joaopinto | the bind operation does not report an error, but does not help either | 18:48 |
joaopinto | Cannot lock LockDir(http://bazaar.launchpad.net/%7Egetdeb-web-developers/getdeb-web/main/.bzr/branch/lock) | 18:48 |
SamB_irssi | jelmer: having to use "svn propdel" to get a username into the SVN auth cache isn't ideal! | 18:49 |
SamB_irssi | hmm. | 18:49 |
SamB_irssi | didn't even work? | 18:49 |
joaopinto | cody-somerville, ops, bind did help, tks | 18:50 |
cody-somerville | joaopinto, :) | 18:51 |
LarstiQ | SamB_irssi: *blink* | 19:17 |
stephank | I have a project I started working on in a bazaar tree. Now I'd like to reuse large parts of this application for another customer. I stripped down the application to remove functionality specific to my first customer, and now have a bazaar branch with a minimal functional version of the application. Now I'm about to branch that again so I can start work for the new customer. | 19:32 |
stephank | My question is, how do I do merges across these three branches? | 19:32 |
stephank | If I merge changes from the shared branch back into my original branch for customer 'A', I'd lose all the functionality because it take in the commits where I stripped everything down. | 19:32 |
stephank | Basically, I want to move to a /\ shape, but at the moment only have the bottom left node of that graph. | 19:33 |
* LarstiQ nods | 19:33 | |
LarstiQ | stephank: I haven't tested it out to that level, but what you should be able to do is merge your stripped branch into A, and then reject all the changes. | 19:34 |
LarstiQ | stephank: basically by doing `bzr merge stripped; bzr revert; bzr ci -m 'Reject strippage'` | 19:35 |
LarstiQ | stephank: afaics that should from then on allow you to merge changes without having to deal with the huge diff of removed functionality each time. | 19:35 |
LarstiQ | stephank: I do something similar like this (but only two branches) for merging the Debian unstable packaging of bzr-svn into the Ubuntu bzr-svn ppa packages | 19:36 |
stephank | LarstiQ: Aha! I'll try that out immediatly. :) | 19:36 |
LarstiQ | (for which I don't want the Debian changelog entries that mess up the chronological order in the Ubuntu changelog) | 19:37 |
LarstiQ | besides some real packaging differences | 19:37 |
stephank | LarstiQ: hmm.. when I revert, it really reverts the merge as well, and the commit is not picking up any changes. | 19:39 |
ddaa | stephank: you MUST do "revert ." | 19:40 |
ddaa | the final dot is important | 19:40 |
ddaa | or "revert $PATH" if you prefer | 19:40 |
stephank | ddaa: Aha, ofcourse | 19:40 |
LarstiQ | stephank: sorry, what ddaa said | 19:41 |
LarstiQ | ddaa: I actually left the . off in my advice, mea culpa. | 19:41 |
stephank | LarstiQ: no problem, thanks for the excellent help, and ddaa, this did the trick. :) | 19:42 |
fbond | What's the word on merging ancestry with cherry-picks? | 20:26 |
jelmer | SamB_irssi: hi | 20:33 |
jelmer | SamB_irssi: still there? | 20:34 |
=== thunderstruck is now known as gnomefreak | ||
=== thunderstruck is now known as gnomefreak | ||
SamB_irssi | jelmer: again | 21:33 |
SamB_irssi | I am here again | 21:33 |
SamB_irssi | jelmer: it's an https URL on sf.net, if that makes any difference | 21:33 |
jelmer | SamB_irssi: hi | 21:35 |
jelmer | SamB_irssi: Did you see the thread on the bazaar mailing list? | 21:35 |
jelmer | SamB_irssi: basically, you need to use svn+https:// | 21:36 |
SamB_irssi | jelmer: on a completely different subject, are you going to vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1LupWj-0005Cp-WD%40hydrogen%3E ? | 21:37 |
SamB_irssi | jelmer: I tried svn+https:// | 21:37 |
SamB_irssi | it didn't seem to help me get a "username" prompt | 21:37 |
SamB_irssi | hmm. | 21:37 |
SamB_irssi | maybe my bzr.dev is too old? | 21:37 |
jelmer | SamB_irssi: which version of bzr are you running? | 21:38 |
jelmer | SamB_irssi: you'd need a fairly recent one | 21:38 |
jelmer | SamB_irssi: or bzr.foreign | 21:38 |
SamB_irssi | fwiw, svn+https:// failed in the same exact way, not in a different way -- it asked me for the password for "naesten" | 21:39 |
* SamB_irssi wonders if there is a way to make irssi warn you that you are scrolled up | 21:39 | |
LarstiQ | SamB_irssi: if there is more text after you scrolled up it says - more - | 21:40 |
SamB_irssi | LarstiQ: where does that show up? | 21:41 |
* SamB_irssi waits for someone to say something so he can see where it shows up | 21:41 | |
SamB_irssi | oh, there it is | 21:41 |
SamB_irssi | LarstiQ: is there some way to change that to a different color? | 21:42 |
LarstiQ | SamB_irssi: euh, I suppose | 21:43 |
SamB_irssi | jelmer: ah, with latest bzr.dev it works better | 21:43 |
LarstiQ | SamB_irssi: may I recommend the trackbar script to you? | 21:43 |
SamB_irssi | now it just looks horrible ;-) | 21:43 |
LarstiQ | SamB_irssi: it's white for me | 21:43 |
SamB_irssi | LarstiQ: yeah, it was white here too | 21:43 |
LarstiQ | SamB_irssi: I think I'm using whatever is default in Debian qua style | 21:44 |
SamB_irssi | (the "ugly" refers to bzr-svn's username prompt, btw) | 21:44 |
LarstiQ | ah :) | 21:45 |
SamB_irssi | jelmer: uh-oh ... it's asking me first for a username, then for a password ... but now it's asking me for a password for naesten again! | 21:46 |
LarstiQ | what a naesty behaviour! | 21:47 |
LarstiQ | ok, time for bed if my jokes are that bad | 21:47 |
LarstiQ | ciao | 21:47 |
SamB_irssi | that is, first it asks for a username and I say "sbronson" ... then it asks for a password for sbronson ... then it asks for a password for naesten! | 21:47 |
* SamB_irssi puts back the svn+ | 21:48 | |
SamB_irssi | arg, apparantly it found "naesten" cached??? | 21:50 |
jelmer | SamB_irssi: can you reproduce this with the latest bzr.foreign and the latest bzr-svn? | 21:51 |
SamB_irssi | what's bzr.foreign ??? | 21:52 |
jelmer | SamB_irssi: http://people.samba.org/bzr/jelmer/bzr/foreign | 21:53 |
SamB_irssi | that looks kind of like a dash to me ... | 21:53 |
SamB_irssi | oh, wait | 21:53 |
jelmer | contains a few pending patches for bzr.dev and a workaround for the fact that bzr.dev asks for passwords more often than necessary | 21:53 |
SamB_irssi | different url | 21:53 |
* SamB_irssi was looking at something from google with a desciptively similar sounding url | 21:53 | |
SamB_irssi | s/descip/descep | 21:54 |
yacoob | is there any way to stop bzr from merging a file that has been deleted in destination branch? | 21:56 |
james_w | yacoob: no, but if you revert that path after merging then it will be remembered | 21:59 |
SamB_irssi | jelmer: okay, yes, I still have the problem | 22:00 |
SamB_irssi | but it might now just be a configuration/cache issue of some kind | 22:01 |
jelmer | SamB_irssi: so this is happening while you are pulling? | 22:01 |
SamB_irssi | jelmer: I don't believe so | 22:01 |
jelmer | SamB_irssi: so it's only while pushing? | 22:01 |
jelmer | SamB_irssi: and Bazaar is asking you for a username+password more than once? | 22:01 |
SamB_irssi | no credentials show up in ~/.bzr.log for pull | 22:02 |
SamB_irssi | oh, actually I don't get any prompts now ... | 22:02 |
SamB_irssi | sorry :-) | 22:02 |
SamB_irssi | or ... one password prompt | 22:02 |
SamB_irssi | for the wrong username, though | 22:03 |
SamB_irssi | and I can't figure out where it's getting the username/password from :-( | 22:04 |
jelmer | SamB_irssi: It should be getting it from ~/.subversion/auth if you tried to use svn itself on that URL before | 22:05 |
SamB_irssi | This is my bzr.log output: | 22:10 |
SamB_irssi | http://paste.lisp.org/display/78916 | 22:10 |
SamB_irssi | but I don't see anything in ~/.subversion/auth ... | 22:11 |
jelmer | ah, bzr-svn wasn't prompting yet | 22:15 |
jelmer | SamB_irssi: I'm pushing a fix for bzr-svn | 22:15 |
SamB_irssi | jelmer: but I'm still puzzled as to where it came up with the "password" | 22:16 |
SamB_irssi | jelmer: but I'm still puzzled as to where it came up with the "password" | 22:17 |
SamB_irssi | EWIN | 22:17 |
* SamB_irssi meant to re-do a bzr pull ... | 22:17 | |
* SamB_irssi wonders when/where jelmer is pushing it | 22:18 | |
asabil | hi all | 22:23 |
asabil | is there a way to stop the Commit().commit() from using the progress bar ? | 22:23 |
james_w | asabil: programatically? | 22:24 |
asabil | james_w: yes | 22:24 |
james_w | I think you pass in a progress bar | 22:24 |
james_w | Dummy or Null or something | 22:24 |
asabil | james_w: not for commit () | 22:26 |
james_w | ah | 22:26 |
james_w | that sounds like an omission | 22:27 |
jelmer | SamB_irssi: Just pushed it, to the 0.6 branch | 22:27 |
SamB_irssi | jelmer: I still seem to have the same problem :-( | 22:31 |
jelmer | SamB_irssi: It's not prompting you for a username? | 22:31 |
SamB_irssi | indeed | 22:31 |
SamB_irssi | but I also seem to need to pass --username to svn every time ... | 22:32 |
jelmer | SamB_irssi: so it looks like the username is cached in ~/.subversion/auth then | 22:32 |
SamB_irssi | I can't see it ! | 22:33 |
jelmer | SamB_irssi: have you grepped for it? | 22:34 |
jelmer | it should be in one of the files in ~/.subversion/auth/svn.username/ | 22:34 |
asabil | jelmer: can you take a look at this branch: https://code.launchpad.net/~asabil/bzr-rebase/filter-branch ? | 22:34 |
SamB_irssi | jelmer: I don't seem to *have* any files there | 22:35 |
jelmer | SamB_irssi: I'm not sure where it gets it from then, but if svn is assuming it knows the username then bzr-svn probably would too | 22:36 |
jelmer | asabil: sure, what about it? | 22:36 |
asabil | jelmer: what do you think about merging it into the rebase plugin ? | 22:37 |
asabil | and maybe rename bzr-rebase to bzr-rewrite ? | 22:37 |
asabil | with all the history manipulation related commands | 22:37 |
yacoob | james_w, doesn't quite work, still get conflicts on next merge. | 22:38 |
james_w | yacoob: you did a "revert; commit; merge"? | 22:38 |
james_w | and you get the same deleted conflict? | 22:38 |
SamB_irssi | jelmer: hmm. | 22:40 |
SamB_irssi | jelmer: would be nice if bzr-svn had a way to override that :-( | 22:40 |
yacoob | merge from branch a to branch b, revert addition of a file x, commit. Then made a change in file x in branch a. Merge from a to be gives a conflict. | 22:40 |
* SamB_irssi tries updating to a more recent subversion package | 22:44 | |
jelmer | asabil: can you send me a merge request? | 22:45 |
asabil | jelmer: to your personal mail box ? | 22:45 |
jelmer | asabil: I'm at a conference at the moment, don't have a lot of time to look into it atm | 22:45 |
jelmer | asabil: yeah | 22:45 |
asabil | jelmer: I can also ask for a merge from launchpad | 22:46 |
jelmer | SamB_irssi: You can override it by specifying the username in the url | 22:46 |
SamB_irssi | hmm ... it looks like if I hit "enter" at the password prompt for "naesten", vanilla svn asks me for another username | 22:46 |
jelmer | asabil: Launchpad's merges don't include merge directives though unfortunately | 22:46 |
SamB_irssi | jelmer: that didn't seem to work | 22:46 |
asabil | jelmer: okidoki, I will do then, thanks | 22:46 |
SamB_irssi | I think .. | 22:46 |
SamB_irssi | subversion doesn't seem to care if I put something before @ in the http url ? | 22:47 |
SamB_irssi | er. https ... | 22:47 |
yacoob | bug or feature? | 22:49 |
jelmer | SamB_irssi: bzr-svn does | 22:52 |
jelmer | yacoob: that's intentional | 22:52 |
jelmer | yacoob: as bzr doesn't know what to do with changes to a file that's removed | 22:52 |
jelmer | yacoob: it doesn't want to throw away those changes that have been made silently | 22:53 |
yacoob | so I'd have to deal with this on every subsequent merge... | 22:53 |
Peng_ | Only if the file was modified. | 22:55 |
yacoob | well, yes. | 22:55 |
yacoob | no way to work around it, I presume? | 22:55 |
* SamB_irssi heads home ... hasn't failed yet with the username@ in the URL, but he's still not happy about having to use that :-( | 23:05 | |
* SamB_irssi ... and it still might | 23:06 | |
lifeless | yacoob: you only have to deal with it once for each change; if upstream stop changing it it will stop conflicting | 23:07 |
lifeless | yacoob: its arguably a bug to have subsequent changes generate conflicts again; could go either way - may be worth some discussion on the list | 23:08 |
yacoob | lifeless, I'm the upstream :) and I keep config files in bzr. Branch a is 'desktop', b - 'laptop'. Some of the stuff is not needed on the laptop, so it would be nice to say once 'no, I don't need this on the laptop'. | 23:09 |
lifeless | yacoob: righto; still the analogy holds | 23:16 |
lifeless | you'd like the delete to stay deleted | 23:16 |
lifeless | even on later changes to the file | 23:17 |
yacoob | very much so. I'll open a bug about that. --flag for this would be okay I think. | 23:17 |
=== Guest28542 is now known as bob2 | ||
=== bob2 is now known as Guest93773 | ||
yacoob | https://bugs.launchpad.net/bzr/+bug/364336 | 23:24 |
ubottu | Launchpad bug 364336 in bzr "bzr merge should allow user to ignore changes in deleted files" [Undecided,New] | 23:24 |
yacoob | ah :> | 23:25 |
=== Guest93773 is now known as bob2 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!