[00:55] morning === vxnick_ is now known as vxnick [03:30] lifeless, spiv : how close is lp:~spiv/bzr-builder/refactor to landing? [03:32] mwhudson: hmm [03:32] also, what does it do? [03:35] mwhudson: james_w needs to get back from UDS :) [03:36] lifeless: that makes sense i guess [03:36] mwhudson: that branch has some simple refactoring on top of lp:~lifeless/bzr-builder/bug-469874 that is used by lp:~spiv/bzr-builder/merge-subdirs-479705 [03:37] sounds like a fun stack of not-landed branches [03:37] mwhudson: basically a replaces a list of 2-tuples where (*, None), (None, *) and (None, None) all mean different things, and replaces them with objects [03:38] mwhudson: and replaces case statements about that with good ol' polymorphism [03:38] mwhudson: why do you ask? [03:38] lifeless: just poking at bzr-builder [03:39] The names I gave to the objects and methods can be improved, but the shape is certainly much nicer (and made merge-subdirs-479705 fairly straightforward). [03:40] Hmm, I guess I should make some merge proposals for those, not sure why I hadn't done that yet. [03:42] spiv: you get to use the new dependent branches feature ;) [03:45] does bzr have something like gits add --interactive? (allows commiting chunks of your current diff) [03:45] lifeless: indeed :) [03:46] Merge requests filed. That should keep james_w busy for a while :) [03:46] Kamping_Kaiser: "bzr shelve", you can shelve the parts you don't want to commit yet, then bzr commit, then bzr unshelve. [03:46] spiv: thanks, I'll have a go [03:58] igc: still around? [03:58] hi spiv, mwh [03:58] poolie: hello [03:58] spiv: that works a treat, thanks. [04:14] spiv: so you proposed the branch to my branch, not to trunk? [04:14] spiv: oh nevermind, LP confused me [04:19] !!! [04:19] :-) [04:26] yeah, news @ 11 === Peng__ is now known as Peng_ [04:40] lol [04:44] * GaryvdM is back (gone 07:00:57) === vxnick_ is now known as vxnick [08:14] is there a way to bzr diff all non .xyz files? [08:17] you can use filterdiff (not part of bzr) [08:19] ok thanks anyway [09:30] so, I've got a bot that's polling bzr branches on lp, and I'm getting RevisionNotPresent exceptions sometimes http://paste.pocoo.org/show/nHK9f5k22Vt40innuE6i/ [09:30] code in question: http://bazaar.launchpad.net/%7Estefanor/ibid/icecast/annotate/head%3A/ibid/plugins/bzr.py [09:31] should I just ignore the exception and try again in a bit? [09:43] tumbleweed: yes, I guess. [09:48] Hi! Trying to push a branch to lp failed at fist try ("different serializers") but succeeded at second try: http://pastebin.com/m27e603bb [09:48] Is this a bzr issue or a launchpad issue? [09:59] That's clever! The failure on the first push leaves enough around that the second push doesn't try to auto-stack. I'll have to remember that! [10:00] MvG: *Probably* a bzr bug, but I'm not going to set something equivalent up off-LP to verify it. [10:01] Note to self: File a bug about stacking being broken on staging... [10:02] So basically it is known current behaviour that auto-stacking doesn't work (due to some difference in repo formats?), and the fact that it worked the second time is more like a bug? Should I file anything? [10:02] MvG: What format is your local branch? If it's 2a, than yes, it's known behaviour that stacking fails. [10:03] MvG: Err, I mean, *not* 2a. [10:03] Format is 2a, according to "bzr info ..", where .. is the shared repository. [10:04] MvG: Oh, my mistake. You're using 2a, but lp:~trac-bzr-team/trac-bzr/trunk is on an older format. [10:04] MvG: What happened is that the first push created some of the control directories before it realized the format difference and exited. On the second push, since they existed, it didn't try to stack, so you didn't run into the format issue. [10:05] I understand. [10:05] MvG: Umm, I think it's worth filing, although I'm not sure it's worth fixing. :P [10:06] OK. will do so. [10:10] Peng: How do you tell lp:~trac-bzr-team/trac-bzr/trunk is older format? bzr info doesn't seem to help me there. [10:18] MvG: The error message said it was a KnitPackRepository. 2a is CHKInventoryRepository. [10:18] Ah, I see. [10:20] MvG: FYI, in bzr.dev, "bzr info -v" gives useful format information for branches accessed over the smart server. [10:20] MvG: In older versions, you can prepend "nosmart+" to the URL to force VFS access, e.g.: bzr info nosmart+lp:~trac-bzr-team/trac-bzr/trunk [10:20] MvG: (I mean, you can do it in bzr.dev too, you just don't need to...) [10:21] All of these give me info about the branch, but not about the repository format... [10:22] MvG: It included all of it. [10:23] In the Format section it says "repository: bzr remote repository" [10:23] Ah, works now... [10:23] Had been using an older bzr setup here without realizing it... [10:24] filed https://bugs.launchpad.net/bzr/+bug/484685 [10:24] Launchpad bug 484685 in bzr "Failed auto-stacking on first push from 2a branch with non-2a trunk" [Undecided,New] [10:32] hi guys, after running the bzr check command, i'm told there are ghost revisions and inconsistent parents [10:33] is there a way to resolve these somehow? [10:33] did those messages get blocked by the network for not being registered? [10:34] no [10:34] ah good, the freenode error message isn't all that clear :) [10:34] 'bzr reconcile' should fix the inconsistent parents, I think (backup your branch/repository first) [10:36] right, is there anything i can do about ghost-revisions? (and what are they?) [10:44] Glenjamin: Ghosts are revisions that your repo doesn't actually have a copy of. [10:45] i was having issues with bzr-svn in a 2a repository [10:45] Glenjamin: what kind of branch is that? A git or svn import? [10:45] i started again with 1.14-rich-root and it seems fine now [10:45] i did checkout(from svn) branch(locally) push(to svn), and it have an error about parent revisions [10:46] Glenjamin: is it happening every time? [10:46] it was with the 2a format, yes [10:56] cheers for the help guys :) [11:13] hi, any core devs here? [11:15] I half am [11:16] ho! spiv! [11:16] hello spiv [11:16] I have 2 problems [11:16] Good evening :) [11:16] for you evening, for me afternoon :-) [11:17] 1) We have a problem with reconfigure of light checkout of bzr:// branch [11:17] spiv: I've fwd'd mail from qbzr ML about this problem [11:17] spiv: if you have any ideas how to debug this problem I'll be very appresiated [11:17] spiv: if you have any ideas how to debug this problem I'll be very appreciated [11:18] 2) it seems 2a (or rich-roots) broke merge -r0..-1 when files have the same file-id [11:19] 1) Interesting! That seems quite weird. [11:21] As for 2), I would have expected that would get conflicts with or without 2a, or does it fail worse than merely conflicting? [11:22] spiv: 2) doesnot happens with pack-0.92 aka poor-rootsz [11:23] * bialix pastebins [11:23] spiv: see Makefile: http://pastebin.com/m1324b1ae [11:24] spiv: with 2a format I've got path conflict [11:24] with pack-0.92 I've got good merge [11:26] and with rich-root-pack too [11:26] rich-rot-pack -> conflict [11:28] bug https://bugs.launchpad.net/bzr/+bug/484706 [11:28] Launchpad bug 484706 in bzr "merge 2 unrelated branches in rich-root format cause path conflict for the same file-id" [Undecided,Confirmed] [11:29] Yeah, I think it's a rich-root thing. I think a conflict is reasonable in that case, I'm not sure why non-rich-root wouldn't conflict (in fact I'm tempted to think that's the bug, not the rich-root case). [11:31] I don't see a good reason for it to be inconsistent, so there's certainly some sort of bug there. [11:33] spiv: I think non-rich-root behavior is *right* actually [11:33] there is good reason to split big branch into 2 and then merge between them [11:34] spiv: if you have any ideas about 1) I'd like to get some hints [11:34] Well, I cna see an argument for allowing it, for the same reason we treat a merge that applies the exact same change as being clean. [11:34] I don't have a strong opinion either way, but my initial expectation was that it should conflict. [11:35] spiv: all this file-ids thingy is good only for 1 reason -- to track renames. But there is a lot of other reasons when file-ids only bad thing [11:35] parallel imports et al [11:35] And if the content isn't identical it certainly should. [11:37] should -> what? [11:37] Should conflict. [11:37] if content is not identical it produce text conflict (for pack-0.92 format) and this is very good [11:38] but path conflict is not good [11:41] For 1), I think I see the bug in remote.py [11:42] It doesn't look like RemoteRepositoryFormat.initialize copes properly with a non-RemoteBzrDir argument, even though there's some code to try handle that case. [11:44] It's getting late here, but I'll send an email summarising what I see. [11:47] ok, thanks [11:58] is there any work/registered idea anywhere about "semantic/smart" diffs? [11:58] for example, diff ignoring white spaces [11:58] another example, CSS diff [11:58] already possible [11:58] bzr diff --using=whatever [11:59] '--using=diff --diff-options=-w' will ignore whitespace [12:00] great :) but that's just an example [12:01] sure [12:01] if a semantic css diff program exists, bzr can use it [12:01] I have had trouble with comparing css, and I thought it would help me if the diff algorith was "smart" [12:02] bob2: ok I'm being sort of offtopic because I don't know a right channel to ask, as the subject is cross-channel [12:02] * RenatoSilva trying to remember a use case for a "semantic" css diff [12:02] * recall [12:04] hum, ordering, for example p {\n color: #333;\n margin: 0px; \n} should be considered the same as p {\n margin: 0;\n color: #333;\n} [12:04] bialix: sent [12:06] RenatoSilva: sure, but bob2's answer still seems applicable [12:06] this becomes annoying when you have a lot of stuff like this and among these lines only 1 or 2 that really matter [12:06] spiv: ok sorry, will stop now :) [12:07] RenatoSilva: that is, bzr can already cope with that, you just need to tell it to use a diff program that knows how to do the diff you want. [12:07] And if that diff utility doesn't exist yet that isn't exactly a bzr issue :) [12:08] (Although if there's some way in which bzr might help, then that would be worth discussing, but from what I see so far probably not) [12:08] Anyway, bedtime for me. [12:08] spiv: ok, actually I want those programs, which I'm afraid to exist [12:11] I'm afraid to not exist [12:13] spiv: many thanks [14:42] morning all [14:45] hello jam [15:09] * bialix akways enjoys reading jam's articles [15:09] * beuno remembers jam's "this week in bazaar" [15:10] beuno: blame statik, he left me and TWiB fell apart [15:12] * beuno looks at statik with disapointment [15:14] beuno: ya, this week journal was very cool === abentley1 is now known as abentley [15:21] Hi! I am using bzr-pipline for the first time. [15:22] wadesworld: ping if you get some time to help debug the sftp stuff [15:22] I had made some changes in the last pipe and then switched to another pipe w/o committing the changes. [15:23] Now show-pipeline displays the "U" next to this pipe. [15:24] I returned to that pipe (so show-pipeline show "*U") but I don't see the uncommitted changes, at least not with "status" or "diff". Do I need to restore them somehow? [15:26] henninge: try "bzr shelve --list", maybe the uncommited changes have been shelved [15:27] gioele: "No shelved changes" [15:27] gioele: rockstar also explained to me last week that pipelining is different from shelving. [15:28] henninge, bzr unshelve [15:28] henninge, when you change to another pipe, bzr automatically shelves the changes for you. [15:29] rockstar: but does not automatically unshelve when I return? [15:29] henninge: I believe that is true [15:29] rockstar: but "bzr shelve --list" says that there is nothing to unshelve [15:29] * henninge hasn't used shelve/unshelve before either [15:29] switch-pipe shelves but does not unshelve [15:29] henninge, so shelving is part of pipelines, but last week, the discussion was about shelving doing the same as pipelines, which is untrue. [15:29] partially because "bzr merge --uncommitted ..." is able to pull stuff out of the shelf [15:29] ah [15:30] henninge, I use shelves when I have some changes I'd like to keep instead of revert, but I need to commit something else before I commit those changes. [15:31] It's kind of like limbo for changes. Not heaven or hell. [15:31] rockstar: bzr unshelve also says, there is nothing on the shelve. [15:31] rockstar: ;) [15:31] henninge, when you do bzr pipes, what does it say? [15:31] Er, bzr show-pipeline [15:31] * rockstar always forgets that he has aliases [15:32] pipes works, too ... [15:32] rockstar: "*U pipename" [15:32] henninge, and bzr status [15:32] rockstar: nuttin' [15:33] abentley, ^^ [15:33] rockstar: I have to say that I added and deleted a pipe and had a conflict which I resolved [15:33] henninge, that shouldn't affect your changes that should have been shelved. [15:33] henninge, I must consult the pipeline gods. [15:34] jam: switch-pipe also unshelves. [15:34] I also tried "merge --uncommitted" (because I read that in the help somewhere) and it failed [15:34] abentley, I thought it did. [15:34] abentley: would make sense to be symmetric [15:34] what if you have multiple shelved patches? [15:34] just the last one? [15:34] jam: There's only one. [15:34] abentley, it sounds like something's wrong with how changes got shelved. [15:35] abentley: so 'bzr shelve' doesn't interact with the actual 'shelf' that is being used? [15:35] here is the failure: http://paste.ubuntu.com/321609/ [15:35] jam: Indeed. [15:35] oh, that is mostly explanatory text [15:35] jam: The shelved changes are stored in the branch, not the working tree. [15:36] Ah, that's clever. [15:36] So bzr unshelve shouldn't actually unshelve the changes. [15:36] here is the crash file: http://paste.ubuntu.com/321612/ [15:36] rockstar: Right, and I also try to avoid referring to it as shelving. [15:36] henninge, try switching away from the pipe and switching back. [15:37] abentley, yes, I can see why now. [15:37] henninge: doing "switch-pipe" to return to the pipe with the stored changes should restore them. [15:38] henninge: The crash you're getting is because you didn't specify a pipe to merge from. [15:38] rockstar: yup, that helped [15:38] henninge, so it's working now? [15:39] rockstar: yes, bzr status show my changed files again [15:39] show [15:39] s [15:39] henninge, great [15:39] * rockstar scurries off to find a quiet hacking place [15:39] rockstar: thanks [15:39] rockstar: go to your room! [15:39] ;-) [15:40] abentley: thanks, too. [15:42] henninge: I have filed bug #484846 about the merge issue. [15:42] Launchpad bug 484846 in bzr-pipeline "pipeline dies when location is not specified with merge --uncommitted" [Undecided,New] https://launchpad.net/bugs/484846 [15:45] rockstar: btw, "pipes" is an automatic alias for show-pipeline now. [15:45] abentley, hooray! [15:45] henninge: Is it possible that when you originally returned to the pipe, you used "switch", not "switch-pipe"? [15:46] abentley, actually, I found out last week that basically everyone at the lazr-js sprint using pipes were using my aliases. I thought about submitting a patch to make those aliases official. [15:47] rockstar: Well, I'm not sure about all of them, but just submit your aliases and I'll look them over. [15:47] abentley: "history | grep switch" only return switch-pipe ... [15:47] rockstar: pdiff and pstatus? Very useful. [15:48] abentley, cool. Well, now that I see the aliases I use, they shouldn't all go up, but EVERYONE was using next and prev. [15:48] ...as well as pipes, which is now upstream anyway. [15:49] rockstar: where do I find "your" aliases? [15:49] henninge: Okay, I'll look into why it didn't restore the changes. [15:50] rockstar: I don't get "next" and "prev". I use switch-pipe :last at least as often as switch-pipe :next. So I've aliased "switch-pipe" to "swp". [15:50] henninge, http://theironlion.net/blog/2009/08/26/5-must-have-aliases-bzr-pipeline/ [15:50] I have a few more now, but they aren't anything special. [15:50] And send-pipe is silly to have now anyway, since Launchpad ignores the bundle you send through email now. [15:51] abentley, maybe there should be a bzr last then as well. [15:51] rockstar: Anyhow, "next" and "prev" can't be automatic aliases. Only command name abbreviations can be automatic. But they could go in "help pipelines". [15:51] abentley, ah, yeah. You're right. [15:52] abentley, okay, so it's more a doc patch now. I can live with that. [15:52] rockstar: It doesn't ignore the bundle. It just has a tendency to fail to apply it correctly. [15:53] rockstar: i.e. to give an incomprehensible oops. [15:53] abentley, well, as far as the UI is concerned, it ignores it, because the preview diff is what's displayed. [15:53] abentley, it's a moot point with pre-req branches though. [15:54] rockstar: The diff was never part of the bundle, it's part of the merge directive. [15:54] * rockstar facepalms [15:54] That's what I meant. I blame UDS and lack of sleep. [15:55] rockstar: actually, I tell a lie. In bundle format 0.9 and earlier (bzr 0.18 and earlier), the diff *was* part of the bundle. [15:57] rockstar: Anyhow, there's a new lp-submit in the very latest pipelines that uses the LP API to create merge proposals. [15:57] rockstar: You get prerequisite branches automatically. [15:57] abentley, wonderful. [15:57] abentley, and the diff is generated correctly? [15:58] rockstar: Yes. [15:58] Niice! [16:07] Is there a 2a copy of MySQL somewhere for those too impatient to spend 2 days converting it? :D [16:07] abentley: I have another crash for you ... http://paste.ubuntu.com/321629/ [16:07] (I don't really care what branch; I just want it for testing.) [16:08] guys, show can i create a patch between 2 revisions? [16:08] brmassa: What for? [16:08] henninge: Your bzr C extensions are not up to date with your bzr. [16:09] abentley: how do you see that and how do I fix that? [16:10] henninge: You're running bzr from a package, right? If so, only the packager can fix it. [16:10] abentley: from the nightly ppa. [16:11] Peng: well... i created a branch for each x.x.x, 1.x.x and 1.1.x version of my app. now i submited some some to the minor branch (1.1.x), i want to generate a patch to apply into higher levels/versions [16:11] henninge: I know that it's a C extension problem only because I've experienced it myself, and since I run from source, I did "make" and it fixed it. [16:11] Woa! bazaar-vcs got a new look! [16:11] brmassa: You should have done it the other way around so you could "bzr merge". [16:12] brmassa: Make the change to the oldest branch, then "bzr merge" it into the newer branches. [16:12] jam: henninge's running from the nightly PPA, but his StaticTuple is incompatible with his bzr. Who takes care of that packaging? [16:13] Peng: I don't believe there is. I think they've talked about upgrading, and I believe 'drizzle' has switched to 2a, but I'm not sure if drizzle is the full mysql history, etc. [16:13] henninge: Perhaps you can switch to the bzr beta PPA temporarily? [16:13] abentley: the daily just needs to be rebuilt, there was a fix for that which has been around since 2.1.0b3 [16:13] I thought james_w was doing dailies [16:14] afaik, none of the 2.1 series was built into bzr-beta-ppa [16:14] johnf didn't have enough tuits [16:14] jam: Thanks. [16:14] jam: I suspect james_w will be busy this week... [16:14] abentley: that is not 2.1 yet, I tried that first. bzr-pipeline only works with 2.1, so it told me ... [16:14] jam: MySQL's history is about 2000 revisions longer than Drizzle's, so I guess it doesn't. Darn. [16:14] abentley: I am running bzr-pipeline from source [16:15] Peng: well... at one point all 3 branches were the same, but since 1.1.x is focused on bug fixing only and the other 2 includes new features, the codes might diverge... [16:15] maybe I should just run bzr from source, too [16:15] henninge: lp:bzr-pipeline/stable works just fine with 2.0 [16:15] Peng: well, you really need to compare via "bzr ancestry" and not "bzr revno" [16:15] but yeah, they might have started with a fresh codebase [16:15] abentley: ah, I could change that [16:15] * Peng didn't know about "bzr ancestry". [16:15] jam: Ehh, true. [16:16] brmassa: OK, um, commit your changes to the bugfix branch, then "bzr merge" that branch into your newer branches. [16:16] brmassa: you can alwyays do "bzr diff -c REVNO" or "bzr merge -c REVNO", or .. create a daggy fix as Peng mentions [16:17] thanks guys... its just matter of getting used to the commands and concepts. [16:17] "bzr merge -c" does a cherrypick? [16:20] how can I tell what will change from a bzr up command before actually doing it ? bzr up doesn't seem to take the --dry-run option [16:22] Peng: its working. now, is there a way to use the same commit messages used in the original branch while commiting the merge? [16:25] of course without manually writting it... [16:28] brmassa: You can copy and paste... :D [16:28] Peng: yep. i was wondering about a parameter to to this automatically [16:47] what do I need to install to get bazaar explorer? I'm on ubuntu [16:48] got it [16:48] wow, you really managed to hide that info ;) [16:50] we did? === sdboyer_ is now known as sdboyer [19:29] Augh! "bzr pull" on MySQL died after almost 2 hours and 200-300 MB of bandwidth, losing all of hte progress it had made! :( [19:38] hey, I ran into an initially confusing situation, I just wanted to see if it was a bug or expected behavior [19:38] if I have a directory under VC foo, and I do bzr mv foo bar/baz when bar doesn't exist, I get the error "bar is not versioned" [19:39] so I spent a while trying to figure out what that means, because it was obvious to me it wasn't versioned since it doesn't exist [19:39] mrooney: while correct, I agree [19:39] "bar doesn't exist" would be more helpful [19:40] yes it would have been much more helpful [19:40] mrooney: mind filing a request for that? [19:40] sure [19:40] thanks [19:40] it would be great if there was an option to create the directories if needed [19:42] I keep hitting it over and over when restructing projects, "oh this file needs to be in a directory" [19:43] what kind of restructuring is that? [19:44] in my use I usually need a directory when I have multiple files already [19:45] what is your fear of automatically creating directories? people typoing a mv when they expect the dir to exist, and silently getting a new one? [19:45] I haven't thought it through [19:45] but my fear is overloading mv even more than it already is [19:45] any sort of cleaning up a project, where I accumulate too many files in a directory and want to mv them to new directories [19:46] mrooney: do you move more than one file at once to a directory that doesn't exist? [19:46] it isn't obviously that painful to bzr mkdir first, it is just a thing I have to keep in my head [19:46] right [19:46] no just one in these cases [19:46] mrooney: it's an alien proces to me :) [19:47] mrooney: how would the ui look? [19:47] the ui? [19:49] mrooney: of mv making dirs that don't exist [19:50] * LarstiQ checks mkdir -p behaviour [19:50] mrooney: so one question that arises [19:51] mrooney: `bzr mv file non/existing/path` [19:51] mrooney: would that be non/existing/path/file or non/existing/path ? [19:51] hi LenzGr [19:52] Hi! [19:52] LarstiQ: haha yes, that is ambiguous, I assume it becomes non/existing/path unless you did bzr mvfile non/existing/path/ [19:52] I'd follow 'mv' there [19:53] though mv doesn't have a -p option like mkdir does [19:55] mrooney: right [19:55] LarstiQ: I got bug 484985 for you :) [19:55] Launchpad bug 484985 in bzr "bzr mv'ing something to a folder which doesn't exist results in unspecific error" [Undecided,New] https://launchpad.net/bugs/484985 [19:55] mrooney: thank you :) [19:56] that would definitely at least make it obvious to the user what they need to do === weigon__ is now known as weigon [21:41] Greetings All. I'm having an issue with bzr join. I started a repo in /etc/httpd some time back. Now I'd like to version /etc as a whole. I ran bzr init in /etc, and added and committed everything but /etc/httpd. Now I'm trying to join /etc/httpd by running bzr join httpd from the /etc directory. I get "bzr: ERROR: An inconsistent delta was supplied involving u'httpd', 'tree_root-20091113022148-a0u1zuvcke3o9vtb-1' reason: Path alread [21:41] versioned". Am I misunderstanding how join is supposed to be used? Bzr 2.0.1 and repo formats are both 2a. [21:42] ibrandt: add https to .bzrignore [21:42] s/https/httpd [21:46] Thanks for the help. I just ran bzr ignore and got, "Warning: the following files are version controlled and match your ignore pattern: httpd These files will continue to be version controlled unless you 'bzr remove' them.", so apparently my statement that I added everything but httpd was incorrect. [21:47] Looks like I need a "bzr forget" [21:48] ah, no, wait. I don't think you can't you can do what you think [21:49] Ah, "bzr remove --keep httpd"? [21:49] "bzr join" can only join branched created with bzr split [21:49] Oh, I see. [21:50] Any way to push the root of httpd up one dir, keeping history? [21:50] from the help of join «Such trees can be produced by "bzr split", but also by running "bzr branch" with the target inside a tree.» [21:50] ibrandt: I don't know [21:51] I saw that. Okay, thanks, I'll keep poking at it. [21:51] I already asked for a new join (and a new split) that could do what you want but that proposal did not find the support of the core devs. [21:51] while you are at it, could you expose your case to the mailing list? [21:52] Sure, do you have a thread link or a Launchpad bug I could comment on? [21:55] I got my ignores in order, and remove --keep'd httpd, and you're right, still no luck with join. [21:58] ibrandt: I will try to find the link to a gmane thread later [21:58] It's strange because how is bzr branch into an unversioned subdir of a parent tree all that different from bzr init on the same? [21:58] now I'd like to understand why it does not work [21:58] ibrandt: what about /etc/httpd/.bzr*? [21:59] do you have just .bzr or also a .bzr.retired directory? [21:59] just /etc/httpd/.bzr [21:59] My thought was the join was all about merging the history for that into /etc/.bzr [21:59] ibrandt: I see the problem [22:00] ibrandt: join is not the culprit [22:01] ibrandt: when you first added the files in /etc (including /etc/httpd) some paths have been stored in /etc/.bzr. Now that you are trying to join it, bzr sees conflicts between the recorded paths and the new paths [22:01] makes sense [22:01] ibrandt: can you start with a brand new /etc branch? [22:02] I can, just getting started, so no history there yet. [22:02] ibrandt: so just remove /etc/.bzr [22:02] and do a bzr check in /etc/httpd, just to be sure [22:04] abentley: I am using git to contribute to a project. Now I really appreciate bzr-pipeline behavior of shelving local uncommited changes when switching pipe [22:05] gioele: Cool. I certainly find it handy. There might be a way to automate it in git. Don't think they have a concept like shelving, but you could do temporary commits, I expect. [22:07] abentley: "pipe" switching is basic part of git. Shelving is called stashing. and it must be done manually when switching branch [22:07] obviously the command to switch branch is called "checkout"... [22:10] \o/ I have a ~375 MB "upload" file that hasn't been touched for 1.5 hours. What are the chances this pull crashes and burns? [22:11] gioele: Ah, I'll remember that it's called "stashing". [22:11] gioele: The git stuff with colocated branches is similar to the pipeline thing, but pipes are ordered, while git uses "stacked git" to do an ordered series of patches. [22:13] abentley: I know. Luckily in this case I am working on parallel branches, not stacked branches so I didn't try stgit (or any of its relatives). [22:14] Peng: what project is that for? [22:16] I wonder whether the future branch colocation feature of bzr will suffer of the same problem (no auto shelving): http://doc.bazaar-vcs.org/developers/colocated-branches.html [22:17] gioele: Huh, same problem. bzr check in httpd reported no errors. I rm'd /etc/.bzr and .bzrignore. In /etc did bzr init, bzr ignore ./httpd, bzr add *, bzr commit (which I verified didn't include httpd this time). But then bzr join gives the same error. [22:17] wow -- that's how awesome #bzr is. I came in here prepared to ask a question, and I solved it without even asking. woot! [22:19] Shine on, you crazy diamonds! [22:19] :-) [22:20] ibrandt: did you use exactly "bzr add *"? === Adys_ is now known as Adys [22:20] ibrandt: well, I can replicate your problem [22:21] I did, assuming httpd would be ignored [22:21] I'm trying join now prior to adding anything [22:22] ibrandt: the * got expanded by the shell and bzr sees that you are _explicitly_ adding an ignored file so it lets you add it :) [22:22] ibrandt: if you used bzr add . it would be ignored correctly [22:22] Ah, makes sense [22:24] mwhudson: Trying to "bzr pull" nearly all of lp:mysql. [22:24] Peng: ah [22:24] mwhudson: And yes, I am doing an on-the-fly conversion. :D [22:24] Peng: oh [22:24] Peng: how long has this been going for? [22:24] Oh, I suppose this is the incredibly-long "convert everything" step. [22:24] Peng: I really wouldn't do it on-the-fly [22:24] I had assumed the downloading was stuck. [22:25] 48hrs is a bad thing to have fail [22:25] jam: Luckily I don't care that much! :D [22:25] ISTR that bzr branch foo; cd foo; bzr upgrade [22:25] will probably be faster [22:32] poolie: adsl will benefit from http://staff.psc.edu/mathis/MTU/index.html#pmtud [22:32] jam: it shouldn't be any faster [22:32] jam: we stream deltas over the network, with common code [22:32] lifeless: the converter is different [22:32] the tests I had done with spiv [22:32] jam: spiv put a lot of time into unifying them [22:33]