=== naoki-away is now known as naoki [04:06] almost done =) soon will push & do merge request [04:07] keywords plugin can now update files in the working tree on post_change_branch_tip [04:07] including current revno & current revid of the tree =) [04:07] * xnox says bzr kicks svn =) === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki [07:56] Is it possible to use bzr-git to push to a git branch other than master? === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki [14:35] your standalone windows installer hoses the path environment variable on windows server [14:36] I had path=%path%;c:\program files\python\bin (etc.) in the administrator user's settings [14:36] the installer took that entry, removed it, appended c:\program files\bazaar (or whatever) to it, and used that value to overwrite the *system* path variable [14:37] as a result, all of the standard path locations (eg system32 etc.) were dropped from the path [14:37] breaking a multitude of programs (you wouldn't believe how many things depend on having "more" on the path) [14:43] Shin-LaC: https://bugs.launchpad.net/bzr/+bug/565963 [14:43] Launchpad bug 565963 in bzr "Windows installer incorrectly modifies %PATH%" [Undecided,New] [14:44] reported it for you. but if you want to subscribe, you'll need an account [14:44] thank you! [14:44] you're welcome [14:46] hm [14:48] I hope it wasn't actually the guy who worked on that machine before me who hosed up the path [14:49] Shin-LaC: try it? Uninstall things, make sure the path is correct, try installing, see if it broke? [14:49] I have a VM with windows server 2008 [14:49] I'll try the installer on that [14:51] good [14:51] just make sure the %PATH% setup is sufficiently complicated [15:01] blagh [15:01] activating windows... [15:03] Shin-LaC: you might want to snapshot it before you hose it [15:05] sweet [15:05] Content from the website listed below is being blocked by the Internet Explorer Enhanced Security Configuration. http://www.bing.com/ [15:07] Hello. How do I: 1) know current rev number of a working copy (local); 2) know global revision number (knowing only its internet address); 3) get a changelog (log) between $rev1 and $rev2 ? [15:11] ok [15:11] never mind [15:11] it was the other guy who hosed the path settings on his server [15:11] no problems on my VM [15:11] mathrick: sorry, you can recall that bug report [15:12] Shin-LaC: okay, so mark as invalid? [15:12] yes [15:13] or delete it entirely if possible [15:13] nah, that's exactly what "invalid" means [15:14] done [15:20] btw, is there any plan to make it possible to request merges for particular revnos in launchpad? [15:21] Ehm, bzr revno $url shows remote revision number, that's ok. But how do I get the rev number of current local working copy? I made bzr up -r 100, but bzr revno shows me remote number all the way. I need it to show me "100". Is it possible? [15:22] virus_found: you don't, there's no such thing as "current working dir revno". The working dir is, by definition, files on disk, not a tree state [15:23] you can compare the working dir to some revision, but there's nothing to tell you it corresponds to a particular revision [15:24] virus_found: also it seems like you're referring to a lightweight checkout of a remote branch? If so, then yes, the UI for that sucks in this regard [15:25] Ok, bzr st shows me, that current copy is old. [15:25] Then how to get a changelog between my copy and the global one? [15:26] Say, my copy is at rev 100, global is 111. How to get log between 101 and 111? [15:26] Or 100 and 111 [15:28] virus_found: if by "global" you simply mean the latest, then it's bzr diff [15:28] but again, are you working on a full branch or on a lightweight checkout? [15:29] the answer differs depending on that [15:29] I mean the latest rev, that's on the server. [15:29] I did bzr co [15:29] Does bzr branch provide more ways of performing my task? [15:30] bzr diff shows nothing, despite the fact, my working copy is old. [15:31] virus_found: more like different. Lightweight checkouts differ from other ways of fetching the branch in that they don't maintain a local state and refer to the remote location for everything [15:31] but co without --lightweight creates a bound branch, which is a real branch, just tied to the remote location [15:31] Hm. [15:31] virus_found: if you did bzr co lp:some-project -r 100, then bzr diff will show you nothing [15:32] Then I'll do bzr branch [15:32] virus_found: wait [15:32] because the local branch is at that revision [15:32] if you want to compare branches, then bzr missing is what you want [15:33] Ok. [15:34] virus_found: you can also use bzr diff --new=lp to see the difference in source text and not in revisions [15:34] it all depends on what you want to see and how you arrived there [15:34] bzr co $smth ; bzr up -r 100 ; bzr missing $smth results in "Branches are up to date." [15:34] But the $smth is at 111 [15:35] hmm, lemme check [15:35] Maybe it's due to checkout? [15:35] virus_found: oh, right [15:35] up operates on the working tree [15:35] I can do branch if it helps [15:35] missing operates on branches [15:35] you first did a full checkout [15:35] so the local branch *is* up to date [15:35] Yes. [15:36] Then I'll do "full" branch :) [15:36] virus_found: so it's back to my first answer, your question has no answer because the working tree is not versioned, by definition. Only the tree is. So there's no way to tell that it's at revision something or other [15:36] virus_found: just do bzr up -r 111 [15:38] s/the tree/the branch/, to make it less confusing [15:39] If I do branch, how do I make it "old" (to check "missing" after that)? [15:39] up -r ? [15:39] virus_found: æh? I think you're too confused now [15:39] why'd you want to make it old? [15:39] :) [15:39] what is it you're trying to do in the first place? [15:40] virus_found: again, branching won't change a thing, because you're asking a question without an answer [15:40] I need to check: 1) if my branch or whatever is older, that on the server; 2) get a "diff" or "log", what's the actual difference. [15:42] Actually, cvs, svn, darcs, git and hg all have means of performing my task. It's hardly believable, that bzr can't do it. [15:46] virus_found: why do you need to check if you just asked for a way to make it "older"? [15:46] that's not what you're trying to do, please tell me what your goal is, not how you think it should be done with bzr [15:46] this way it'll be easier for everyone to understand [15:49] I do bzr co or bzr branch. (at rev 100). Time goes. Some commits happen to the server (lp:blah). I want to check, if there were any commits on it. And if so, get a changelog. [15:50] virus_found: bzr missing. But bzr up -r 100 is a different thing and that's why it doesn't work, because what you describe abov is *not* what you did with bzr up [15:50] virus_found: and actually, git doesn't have any means of doing this. You need to fetch the remote branch before you can compare it [15:51] git fetch && git log --date=local ..origin/master [15:51] that's what I said [15:51] it's not telling you about the remote branch [15:51] it's telling you things about your local copy of it [15:51] OTOH, bzr missing will tell you about any branch, including remote ones [15:51] Ok, I don't mind fetching. I'd like it to tell me what has changed :) [15:51] virus_found: if you want to see what changes have happened between branches, bzr missing is the command you want [15:52] Without flags? [15:53] I wanted to make my copy "older" to emulate time going :) [15:53] virus_found: if no flags are given, it uses the remembered pull location. If none is found, it errors out. But you can set a default pull location and then you don't have to specify anything [15:53] bzr missing lp:someproject if you want to be explicit [15:54] virus_found: bzr up does *not* operate on branches. It updates the working tree. That's where you went wrong [15:54] I see. [15:54] if you wanted to check out an older revision (which is a perfectly fine thing to do), it's bzr co -r 100 [15:54] Great. [15:54] notice that the revspec is given to a different command [15:56] I'm sorry, but would "bzr missing" work, if I did bzr co --lightweight ? [15:57] no, because lightweight checkouts operate completely differently, and are frankly just confusing [15:57] well, they're useful, but most of the things bzr will tell you will be confusing [15:57] Ok, I see. Thank you vey much for your time. [15:57] virus_found: the problem with lightweight checkouts is that they refer to the remote branch for *everything*. So if you say bzr revno, it'll do as you say and give you the revno of the remote branch [15:58] which is pretty much never what you want [15:58] the UI here could use a lot of improvement [15:58] virus_found: no problem. Though I'd suggest asking questions about your actual goals in the future, it's way easier to answer those [16:00] Perhaps, yes :) [16:03] mathrick: I'm sorry to bother again, simple question. How do make it stop generating the log file ~/.bzr.log ? [16:04] virus_found: I don't know if there's a way. It generally does it when there's been an error. It's an important clue if something goes astray, so I wouldn't want to disable it [16:06] Ah, I don't have an ID. [16:07] Ok. === retupmoca` is now known as retupmoca [19:06] hi all [19:07] I commited back to my main branch from my laptop, and now one file is all messed up. [19:07] The file contains stuff like "<<<<<<< TREE". [19:07] and also ">>>>>>> MERGE-SOURCE". [19:08] These things are written on a few lines. === naoki is now known as naoki-away === radoe_ is now known as radoe [19:15] RumblePure: read what bzr tells you when you merge :) [19:15] you have a text conflict, and these are markers to tell you which parts of the file come from which source [19:15] RumblePure: `bzr conflicts' should list files that are conflicted [19:16] mathrick: I didn't merge, I committed back from the laptop. [19:16] what do you mean by that? [19:16] bzr won't let you commit to a diverged branch [19:16] you have to merge first [19:16] mathrick: I have done bzr conflicts. It gives nothing. [19:16] okay, describe exactly what you have done to get there [19:17] Ok... hope you have aspirine pills close at hand... [19:17] I didt bzr checkout bzr+ssh from my laptop so I could continue my work from the laptop. [19:18] Having worked with my code over a few days and committed locally on the laptop, it was time to put it back on my stationary, where the main branch is. [19:18] So yes, initially I checked out the code from my stationary, through ssh, to my laptop. [19:19] RumblePure: so that'd be me@laptop$ bzr co bzr+ssh://desktop.me/repo/project ? [19:19] When I wanted to commit back to my stationary, it had a new ip-number and like always I had to open branch.conf and manually change the ip-number. [19:19] yes mathrick, exactly. I did that on my laptop a few days ago. [19:19] RumblePure: okay, what do you man by "commit back to my stationary"? [19:20] mathrick: well, after having changed branch.conf, I do "bzr commit --strict" [19:20] And that is when my problems start. [19:20] wait [19:21] Bazaar talks about conflicts with the main branch, suggesting I do "bzr update". [19:21] And when I do bzr update, I get these new files called "foo.php.BASE" and similar names. [19:21] RumblePure: so you were doing bzr commit --local while working on your laptop? [19:21] mathrick: yes, I thought that was standard procedure.... [19:21] yes, I'm just making sure [19:21] * RumblePure is ready to get barked at. :-) [19:21] RumblePure: well then, you still have conflicts [19:22] didn't bzr update tell you that? [19:22] mathrick: yes, and when I have done bzr update it suggests I do bzr conflict file_name. [19:22] and it's right :) [19:22] RumblePure: you got text conflict, it's that simple [19:22] have you committed anything to the stationary branch in the meantime? [19:22] you or anyone else? [19:23] mathrick: but how come? I didnt touch my code on the stationary after checkout. [19:23] NO, strictly no! [19:23] This time I have been super duper truper careful with NOT doing that. [19:23] Because this is not the first time i have this kind of problem! [19:23] okay, then bzr got confused about what your tree is, somehow [19:23] mathrick: does it have to do with the fact that my ip got changed on stationary? [19:24] I did modify .bzr/branch/branch.conf after all.... [19:24] not sure, it shouldn't, but then I suspect I don't have a full picture of what happened yet [19:24] RumblePure: bzr pays no attention to IPs, only the tree states are of interest, and these are immutable and identified by hashes [19:25] but somehow you convinced bzr that the changes you made are already there [19:25] mathrick: then I dunno what's going on. [19:25] RumblePure: let's debug it [19:25] Reading bzr/docs/developer/testing didn't help much. Reading tests...... well there are loads of them [19:26] bzr log --show-ids bzr+ssh://desktop/repo/projects shows what? [19:26] mathrick: ok, let me run that. [19:26] please paste the first ten or so commits in pastebin [19:26] can you please suggest a good testsuite of a small plugin that extends standard bzr commands? [19:27] xnox: I have no idea about the testsuite, but the plugin pager extends standard commands in several places [19:27] *pager plugin [19:27] mathrick: I will do shortly mathrick. I appreciate your help and want to get to the bottom with this. But please let me first fix that super important files that now has lots of "<<<<<< TREE" in it. The documentation says I should be able to resolve them manually. [19:27] mathrick: and then I'll run your commands asap. [19:28] RumblePure: don't do that, because it's fixing things that shouldn't happen [19:28] your files didn't go anywhere, so spending time on fixing them is useless [19:28] determining what exactly went wrong is a much better use of your time [19:29] mathrick: but I can see the changes that I have been working on my laptop. I can see them. It's just that they have been messed up with <<<<< TREE and such stuff. [19:29] mathrick: ok, I'll cancel. [19:29] if you want clean copies of them, just branch the last revision of your laptop branch [19:29] it'll give you a nice working tree [19:31] RumblePure: when you're done, run the same thing for your laptop branch, and paste it in pastebin too [19:32] then link here [19:35] mathrick: ok done: http://pastebin.com/8H9t25V6 [19:35] * RumblePure_ is RumblePure from his laptop. [19:35] RumblePure_: that's the log for the stationary branch? [19:36] mathrick: eyh yeah that's the log for the stationary when I ran that command from the laptop. [19:37] rumblePure: okay, could you give me the *exact* command you ran to do that commit? Just copy it straight from the history, without any editing [19:37] ie. the first command after which bzr told you to update [19:37] will do chief. [19:38] ok, now I'll give an accurate recap of what I did. [19:39] 1. I modified .bzr/branch/branch.conf, on my laptop, to match the ip-number of my stationary. [19:39] 2. I did bzr commit --strict on the laptop, and that's when the problems started. [19:40] 3. I did bzr update [19:40] 4. I did bzr conflicts [19:40] rumblePure: okay, I'm beginning to suspect one possible scenario that could lead to that, and which'd mean a UI bug in bzr [19:40] At this time I realized that a file php/cassandra/cassandra.php was screwing around. [19:40] lemme test that [19:41] Ok, I'll continue to recap while you do that. [19:41] 5. I did bzr resolve php/cassandra/cassandra.php (still on lappy). [19:42] This produced some files called cassandra.php.BASE, cassandra.php.BASE.moved and etc. [19:42] 6. I removed those newly created files, because they weren't on main branch on stationary and since I wanted to do a strict commit they had to be removed or added. [19:43] 7. I finally managed to do my bzr commit --strict on the lappy. When I had done bzr update on my stationary, that very important file was messed up. [19:43] There you go, my 7 steps to one hour waste of time. :'-( [19:44] rumblePure: first of all, that's not how you deal with conflicts [19:44] a conflict means bzr wasn't able to resolve changes automatically. Removing things without understanding the conflict is the wrong way [19:44] Well, I had a feeling I was doing _something_ wrong. :-/ [19:45] now, I've tried to do what you described, and it works just fine [19:45] mathrick: ok, well then I dunno what is wrong. Should I do a step-by-step simple checkout and commit to and from my lappy to see if it happens again? [19:45] rumblePure: are you able to share these two branches? That is, could you zip up stationary's and laptop's branches and send them to me for testing? [19:45] rumblePure: yes, please [19:46] no, can't share content of branches, sorry. :-/ [19:46] and if it happens, give the exact history of all your commands, without any editing [19:46] ok, will do so. [19:47] rumblePure: or maybe try doing that on fresh branches. Make a new branch, check it out to your laptop, edit as you would with your normal work, and then if it hits the conflict, zip them both up and send together with the command history [19:47] sure, gimme a minute. [19:53] ok, I have created a new dummy project and a bzr branch, let me check it out to the lappy. [19:55] check out went fine, will play with the dummy file a bit and do some local check ins. [19:55] *local commits [19:57] I'll even go so far that I'll disconnect my stationary to obtain new ip-address. [20:01] mathrick: are you there? I obtain the same error! [20:01] bzr: ERROR: Bound branch BzrBranch7('file:///media/disk/files/test/test/') is out of date with master branch RemoteBranch(bzr+ssh://purerumble@213.113.65.67:60000/home/purerumble/files/temporary-files/test/). [20:01] To commit to master branch, run update and then commit. [20:02] haum, maybe printing that was a bad idea. :-/ [20:03] mathrick: If you want you can tell me now what to do in order to proceed and investigate the problem/bug. [20:03] rumblePure: that's not an error, the question is if you get conflicts after that [20:04] mathrick: ok, so i'll do bzr update [20:04] proceed as you did with your normal work, ie. update and try to commit again [20:06] mathrick: nope, no problems at all. At this time I'll give up. [20:06] rumblePure: then you had to do something differently [20:06] what I suspect might've happened is that you committed twice at some point, without realising [20:06] mathrick: I didn't change the ip-number in branch.conf but you keep saying that shouldn't matter. [20:06] and because the IPs were different, it recorded different revids [20:07] how could I use bzrlib's mail APIs to build and send an email with a binary attachment? [20:07] rumblePure: I said it shouldn't, but that doesn't mean it doesn't, we're trying to determine it. And since you said you'd do it, I assumed you did [20:07] Hi, Is it possible to generate a report on a specific users commits in a projects? [20:07] oh huh [20:07] mathrick: yeah i said that but this time my stationary refused to change ip-number. :-/ [20:08] SMTPConnection.send_email accepts a MIMEMultipart object [20:08] let me see if turning the modem off will convince it otherwise. [20:08] so i'll probably go offline and crawl my way back up. :-/ but lemme first do the checkout so i can proceed if the ip is modified. [20:09] ok i'll go offline now and be back. [20:09] k [20:15] I'm trying to process the output of bzr log and retrieve all information on a specific user ... is there a known method for doing this? [20:18] mathrick: ip-number wont change. BASTARD! :-/ You know how I can change the interface's mac address? I'm convince that would give me a brand new ip-number. [20:18] RumblePure: linux? [20:18] mathrick: yes dont bark at me I'm doing a google-search right now. :-) [20:18] am not barking, just asking [20:19] cyberswat: bzr-xmloutput might be handy if you want to parse it from another program [20:19] mathrick: I was kidding, but that's the normal comment you get on irc: "google" :) [20:20] RumblePure: ifdown eth0; ifconfig eth0 hw ether 00:01:02:03:04:05 [20:20] I think [20:20] dash: thanks .. we are looking for a quick report so it looks like output to a text file and then grep will get us there for a short term fix [20:20] ok, i'm going down again and will reappear. [20:20] s/eth0/proper iface name/ of course [20:32] mathrick: I've got the new ip-number, so I'll proceed now. [20:32] mathrick: Just what's a bit spooky is I've got the modified mac-address even after reboot. :-/ [20:35] mathrick: Problem/bug reproduced! [20:35] * RumblePure is testing on laptop. [20:36] mathrick: Ok, one thing that I remembered to do is to do a bzr commit --strict without modifying branch.conf. I've always done this accidentally before realising that the conf-file must be changed. [20:36] mathrick: So then I modified branch.conf and then did bzr commit --strict, and now I get this error: [20:37] mathrick: I get this error: http://pastebin.com/9szZAAnL [20:39] rumblePure: okay, lemme try to reproduce it, and in the meantime please zip up both branches, and the command history [20:39] mathrick: so you think somethings is wrong here? [20:40] mathrick: gimme an e-mail address. [20:41] rumblePure: if you could reproduce it, then something is going wrong [20:42] though I just tested with local bound branches, and it works fine even after I change the location [20:42] * mathrick checks with his checking out off his desktop machine [20:43] remember, I get a new ip on stationary and change branch.conf on laptop. [20:43] * RumblePure_ is writing down command history [20:43] rumblePure: btw, you should be able to use avahi to get symbolic names for the machines automatically, so that you don't need to edit IPs [20:43] rumblePure: it should be available in ~/.bash_history [20:56] mathrick: what's your e-mail? [20:56] rumblePure: I sent it to rumblePure in /msg [20:58] mathrick: you should have it now. [20:59] yu[ [20:59] *yup [20:59] lemme try recreating this [20:59] mathrick: now, would you please let me know how I can get my old mac-address back? :( [20:59] RumblePure_: it should be back after reboot normally, I dunno why it preserves it. What's your distro? [20:59] * mathrick senses some redhat madness [21:00] mathrick: this is how God screws around with me; whatever small amount of time of my free time I can spare for my project gets consumed by problems with stuff like revision control. :'-( [21:01] mathrick: I use Kubuntu (no surprise there). :) [21:01] maybe you were being naughty [21:01] mathrick: i dont drink. i dont smoke. i dont do drugs. i dont even have a girl. [21:01] RumblePure_: also I think setting 00:00:00:00:00:00 as the mac restores the default, but lemme check [21:01] RumblePure_: consider starting smoking, drinking, drugs and girls then :) [21:02] mathrick: yeah, just to balance things out. LOL! ;) [21:03] mathrick: oki you got my e-mail and I'll hang around. Now I'll start working on my project if no one minds. :-/ [21:05] RumblePure_: sure, I just recommend branching the last revision of your laptop branch and working on that without committing to the stationary yet [21:05] you'll avoid dealing with the conflicts this way [21:06] RumblePure_: btw, lshw -class net will show you what should be original MAC addresses [21:06] mathrick: ok will use lshw -class later. [21:08] mathrick: Regarding the file that was screwing around, I fixed it with brute force. It didnt have many issues (not many "<<<<<< TREE") so it was ok. [21:08] But mathrick, I've got something else weird to report. [21:09] This problem that arises, that bzr says there are conflict problems with some file when compared to main branch after changing ip-number... it _always_ happens only for a single file! [21:09] I just checked other files that I had been working on on my laptop. They are prime and good. [21:11] RumblePure_: okay, this is very weird, I did more or less the same and it works just fine [21:11] only thing is that I didn't change the IP but the symbolic host name [21:11] RumblePure_: what does bzr --version say? [21:12] 2.0.2 ........... [21:12] what version do you have? [21:12] RumblePure_: okay, please paste the output bzr plugins -v [21:12] 2.1.0 here [21:13] why won't mine update? I've got repositories. [21:13] Oh wait, maybe I'm using ubuntu's repositories..... [21:13] 2.1.0 is not in the main archive I believe [21:13] 2.1.0 is not stable? [21:13] anyway, that's beside the point, if it's always one file, I suspect there are external factors at play [21:13] it is, but that doesn't mean it'll be pushed to released versions' repositories [21:14] and the bzr distribution in ubuntu has changed recently, I'm confused about the exact details [21:14] 2.0.2 is recent enough, I'm more interested in the plugins you run now [21:14] because something is clearly touching a single file [21:14] http://pastebin.com/0jtH9s5p [21:15] RumblePure_: and it happened in test.php as well you say, in the test repo? [21:15] I've not played around with plugins to my knowledge. [21:15] yes, test.php [21:15] and in my main project repo, it happens to a specific file. [21:15] hmm, nothing suspicious [21:16] * mathrick moves to looking at the zipped repos [21:16] that might take some time [21:16] mathrick: but you didn't change the ip-number. couldn't be that? [21:16] RumblePure_: it's very odd, since nothing of this sort happens here [21:16] RumblePure_: I changed the hostname [21:16] mathrick: change the ip! [21:16] that should be enough, if it's triggered by the remote host's name [21:17] will try that later [21:17] mathrick: well maybe it fetches the ip number in the end and somehow uses that (for hashing or such). [21:17] mathrick: maybe changing hostname doesnt matter because it does something to ip on some lower level. [21:17] it still shouldn't affect anything [21:18] but this problem should not arise in the first place! so what difference does it make that it _shouldn't_ affect anything? [21:18] this is a bug, so all bets are off! :) [21:19] for instance, maybe somewhere in the source code some other subroutine is used when connecting via ip-number and that subroutine is faulty. It is far fedged I know but possible. [21:20] RumblePure_: the zips you have sent me have a terribly unusual directory structure. I suspect that might not be unrelated [21:21] mathrick: it's a test-directory, containing a test.php and the .bzr. [21:22] mathrick: and you say my faulty use of faulty directory structure causes this problem arise, but only if I change the ip-number? [21:22] RumblePure_: and the zip has paths like ../../../../../../home/ [21:22] RumblePure_: I'm saying there's something fishy, and I can't extract these zips [21:22] mathrick: euh, where do you see that cause I cant recall that? [21:22] branch_on_laptop.zip you sent me [21:22] mathrick: what's wrong? [21:22] RumblePure: let me package them again. [21:23] /../../../../home/purerumble/files/temporary-files/test/ [21:23] for instance [21:23] that's from the stationary [21:23] mathrick: where do you see that in the zip? in what file? [21:23] no idea what happened here, but it's not normal [21:23] in both zips you sent me [21:23] there's a single directory called ".." at the toplevel of the file [21:23] in it is a single directory called ".." [21:23] etc. [21:25] mathrick: making tar.gz now [21:26] mathrick: there, you should have two tar.gz files now. [21:27] RumblePure_: it has the same paths, how are you creating them? [21:27] i use the gui in kubuntu. [21:27] when i do bzr merge i get : bzr: ERROR: No location specified or remembered ? [21:28] let me do command-style [21:29] RumblePure_: it's okay, I can extract them [21:29] it's just odd [21:29] mathrick: I can run tar from bash to get you the tar.gz files if you want me to. [21:29] nitian: you have to say bzr merge bzr://some.brach/or/another/ [21:30] the first time anyway, it will remember it for subsequent uses [21:30] RumblePure_: nah, it's okay [21:31] ok, now let me see if I can get some darn work done here. :( [21:31] RumblePure_: out of curiosity, could you please run `bzr status .directory' in any of your branches? [21:31] not to say it hasn't been fun tracking this problem/bug down. :) Cause it has really been auhm, educating. :) [21:32] mathrick: oh oh, I forgot about that. [21:32] my distro keeps creating these .directory files in every directory. [21:32] yes, it's KDE doing that [21:32] and bzr --strict doesn't complain about it? [21:32] On my main project, I tell bzr to disregard from .foo.bar files [21:33] mathrick: euh, why should it complain when it was added to the branch from start? [21:34] dunno [21:34] now i dont have the konsole open to check, but if the .directory was there from start and i did bzr init & bzr add then the file would have been added. [21:34] it doesn't add .dotfiles by default I believe [21:34] are you sure? cause if it doesn't then you got that file by misstake only. then please disregard from it [21:34] but oh ok i'll do bzr status [21:34] RumblePure_: okay, I have absolutely no idea how you got there, but that history graph is NOT right [21:35] mathrick: ....... what history graph? [21:35] of your branches [21:35] both of them show rev 2 as a merge, and basically neither has the original changes in the mainline history [21:35] still dunno what you're talking about. [21:35] that's wrong [21:35] mathrick: would this work too: bzr merge lp:something [21:35] RumblePure_: bzr log stationary [21:36] nitian: yes, and branch spec will work [21:36] including plain directory paths and whatever else you might have registered [21:36] mathrick: where there is a : bzr branch lp:something [21:36] * mathrick has colo:origin/trunk for instance [21:37] mathrick: bzr log > http://pastebin.com/RUqzvwtA [21:37] mathrick: ok.what is a branch spec? :) [21:37] RumblePure_: oh, I know, I was telling you what history graph. Re-run the same command with -n0 added [21:37] notice the indented revisions [21:37] does it look familiar? [21:38] now notice how neither branch has them non-indented, as if both merged from the other [21:38] I don't understand how you got there [21:39] mathrick: just look at the dango commands i sent ya [21:39] nitian: anything bzr understands to be a location of a branch. That includes http://, bzr://, /path/to/dir, lp:something, and whatever else plugins might register [21:39] RumblePure_: that's what I'm doing sir [21:39] mathrick: ok. thanks :) [21:39]