[04:06] <xnox> almost done =) soon will push & do merge request
[04:07] <xnox> keywords plugin can now update files in the working tree on post_change_branch_tip
[04:07] <xnox> including current revno & current revid of the tree =)
[04:07]  * xnox says bzr kicks svn =)
[07:56] <dcoles> Is it possible to use bzr-git to push to a git branch other than master?
[14:35] <Shin-LaC> your standalone windows installer hoses the path environment variable on windows server
[14:36] <Shin-LaC> I had path=%path%;c:\program files\python\bin (etc.) in the administrator user's settings
[14:36] <Shin-LaC> 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] <Shin-LaC> as a result, all of the standard path locations (eg system32 etc.) were dropped from the path
[14:37] <Shin-LaC> breaking a multitude of programs (you wouldn't believe how many things depend on having "more" on the path)
[14:43] <mathrick> Shin-LaC: https://bugs.launchpad.net/bzr/+bug/565963
[14:44] <mathrick> reported it for you. but if you want to subscribe, you'll need an account
[14:44] <Shin-LaC> thank you!
[14:44] <mathrick> you're welcome
[14:46] <Shin-LaC> hm
[14:48] <Shin-LaC> I hope it wasn't actually the guy who worked on that machine before me who hosed up the path
[14:49] <mathrick> Shin-LaC: try it? Uninstall things, make sure the path is correct, try installing, see if it broke?
[14:49] <Shin-LaC> I have a VM with windows server 2008
[14:49] <Shin-LaC> I'll try the installer on that
[14:51] <mathrick> good
[14:51] <mathrick> just make sure the %PATH% setup is sufficiently complicated
[15:01] <Shin-LaC> blagh
[15:01] <Shin-LaC> activating windows...
[15:03] <mathrick> Shin-LaC: you might want to snapshot it before you hose it
[15:05] <Shin-LaC> sweet
[15:05] <Shin-LaC> Content from the website listed below is being blocked by the Internet Explorer Enhanced Security Configuration. http://www.bing.com/
[15:07] <virus_found> 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] <Shin-LaC> ok
[15:11] <Shin-LaC> never mind
[15:11] <Shin-LaC> it was the other guy who hosed the path settings on his server
[15:11] <Shin-LaC> no problems on my VM
[15:11] <Shin-LaC> mathrick: sorry, you can recall that bug report
[15:12] <mathrick> Shin-LaC: okay, so mark as invalid?
[15:12] <Shin-LaC> yes
[15:13] <Shin-LaC> or delete it entirely if possible
[15:13] <mathrick> nah, that's exactly what "invalid" means
[15:14] <mathrick> done
[15:20] <mathrick> btw, is there any plan to make it possible to request merges for particular revnos in launchpad?
[15:21] <virus_found> 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] <mathrick> 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] <mathrick> you can compare the working dir to some revision, but there's nothing to tell you it corresponds to a particular revision
[15:24] <mathrick> 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] <virus_found> Ok, bzr st shows me, that current copy is old.
[15:25] <virus_found> Then how to get a changelog between my copy and the global one?
[15:26] <virus_found> Say, my copy is at rev 100, global is 111. How to get log between 101 and 111?
[15:26] <virus_found> Or 100 and 111
[15:28] <mathrick> virus_found: if by "global" you simply mean the latest, then it's bzr diff
[15:28] <mathrick> but again, are you working on a full branch or on a lightweight checkout?
[15:29] <mathrick> the answer differs depending on that
[15:29] <virus_found> I mean the latest rev, that's on the server.
[15:29] <virus_found> I did bzr co
[15:29] <virus_found> Does bzr branch provide more ways of performing my task?
[15:30] <virus_found> bzr diff shows nothing, despite the fact, my working copy is old.
[15:31] <mathrick> 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] <mathrick> but co without --lightweight creates a bound branch, which is a real branch, just tied to the remote location
[15:31] <virus_found> Hm.
[15:31] <mathrick> virus_found: if you did bzr co lp:some-project -r 100, then bzr diff will show you nothing
[15:32] <virus_found> Then I'll do bzr branch
[15:32] <mathrick> virus_found: wait
[15:32] <mathrick> because the local branch is at that revision
[15:32] <mathrick> if you want to compare branches, then bzr missing is what you want
[15:33] <virus_found> Ok.
[15:34] <mathrick> virus_found: you can also use bzr diff --new=lp to see the difference in source text and not in revisions
[15:34] <mathrick> it all depends on what you want to see and how you arrived there
[15:34] <virus_found> bzr co $smth ; bzr up -r 100 ; bzr missing $smth    results in "Branches are up to date."
[15:34] <virus_found> But the $smth is at 111
[15:35] <mathrick> hmm, lemme check
[15:35] <virus_found> Maybe it's due to checkout?
[15:35] <mathrick> virus_found: oh, right
[15:35] <mathrick> up operates on the working tree
[15:35] <virus_found> I can do branch if it helps
[15:35] <mathrick> missing operates on branches
[15:35] <mathrick> you first did a full checkout
[15:35] <mathrick> so the local branch *is* up to date
[15:35] <virus_found> Yes.
[15:36] <virus_found> Then I'll do "full" branch :)
[15:36] <mathrick> 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] <mathrick> virus_found: just do bzr up -r 111
[15:38] <mathrick> s/the tree/the branch/, to make it less confusing
[15:39] <virus_found> If I do branch, how do I make it "old" (to check "missing" after that)?
[15:39] <virus_found> up -r ?
[15:39] <mathrick> virus_found: æh? I think you're too confused now
[15:39] <mathrick> why'd you want to make it old?
[15:39] <virus_found> :)
[15:39] <mathrick> what is it you're trying to do in the first place?
[15:40] <mathrick> virus_found: again, branching won't change a thing, because you're asking a question without an answer
[15:40] <virus_found> 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] <virus_found> 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] <mathrick> virus_found: why do you need to check if you just asked for a way to make it "older"?
[15:46] <mathrick> 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] <mathrick> this way it'll be easier for everyone to understand
[15:49] <virus_found> 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] <mathrick> 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] <mathrick> 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] <virus_found> git fetch && git log --date=local ..origin/master
[15:51] <mathrick> that's what I said
[15:51] <mathrick> it's not telling you about the remote branch
[15:51] <mathrick> it's telling you things about your local copy of it
[15:51] <mathrick> OTOH, bzr missing will tell you about any branch, including remote ones
[15:51] <virus_found> Ok, I don't mind fetching. I'd like it to tell me what has changed :)
[15:51] <mathrick> virus_found: if you want to see what changes have happened between branches, bzr missing is the command you want
[15:52] <virus_found> Without flags?
[15:53] <virus_found> I wanted to make my copy "older" to emulate time going :)
[15:53] <mathrick> 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] <mathrick> bzr missing lp:someproject if you want to be explicit
[15:54] <mathrick> virus_found: bzr up does *not* operate on branches. It updates the working tree. That's where you went wrong
[15:54] <virus_found> I see.
[15:54] <mathrick> 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] <virus_found> Great.
[15:54] <mathrick> notice that the revspec is given to a different command
[15:56] <virus_found> I'm sorry, but would "bzr missing" work, if I did bzr co --lightweight  ?
[15:57] <mathrick> no, because lightweight checkouts operate completely differently, and are frankly just confusing
[15:57] <mathrick> well, they're useful, but most of the things bzr will tell you will be confusing
[15:57] <virus_found> Ok, I see. Thank you vey much for your time.
[15:57] <mathrick> 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] <mathrick> which is pretty much never what you want
[15:58] <mathrick> the UI here could use a lot of improvement
[15:58] <mathrick> 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] <virus_found> Perhaps, yes :)
[16:03] <virus_found> mathrick: I'm sorry to bother again, simple question. How do make it stop generating the log file ~/.bzr.log    ?
[16:04] <mathrick> 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] <virus_found> Ah, I don't have an ID.
[16:07] <virus_found> Ok.
[19:06] <RumblePure> hi all
[19:07] <RumblePure> I commited back to my main branch from my laptop, and now one file is all messed up.
[19:07] <RumblePure> The file contains stuff like "<<<<<<< TREE".
[19:07] <RumblePure> and also ">>>>>>> MERGE-SOURCE".
[19:08] <RumblePure> These things are written on a few lines.
[19:15] <mathrick> RumblePure: read what bzr tells you when you merge :)
[19:15] <mathrick> you have a text conflict, and these are markers to tell you which parts of the file come from which source
[19:15] <mathrick> RumblePure: `bzr conflicts' should list files that are conflicted
[19:16] <RumblePure> mathrick: I didn't merge, I committed back from the laptop.
[19:16] <mathrick> what do you mean by that?
[19:16] <mathrick> bzr won't let you commit to a diverged branch
[19:16] <mathrick> you have to merge first
[19:16] <RumblePure> mathrick: I have done bzr conflicts. It gives nothing.
[19:16] <mathrick> okay, describe exactly what you have done to get there
[19:17] <RumblePure> Ok... hope you have aspirine pills close at hand...
[19:17] <RumblePure> I didt bzr checkout bzr+ssh from my laptop so I could continue my work from the laptop.
[19:18] <RumblePure> 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] <RumblePure> So yes, initially I checked out the code from my stationary, through ssh, to my laptop.
[19:19] <mathrick> RumblePure: so that'd be me@laptop$ bzr co bzr+ssh://desktop.me/repo/project ?
[19:19] <RumblePure> 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] <RumblePure> yes mathrick, exactly. I did that on my laptop a few days ago.
[19:19] <mathrick> RumblePure: okay, what do you man by "commit back to my stationary"?
[19:20] <RumblePure> mathrick: well, after having changed branch.conf, I do "bzr commit --strict"
[19:20] <RumblePure> And that is when my problems start.
[19:20] <mathrick> wait
[19:21] <RumblePure> Bazaar talks about conflicts with the main branch, suggesting I do "bzr update".
[19:21] <RumblePure> And when I do bzr update, I get these new files called "foo.php.BASE" and similar names.
[19:21] <mathrick> RumblePure: so you were doing bzr commit --local while working on your laptop?
[19:21] <RumblePure> mathrick: yes, I thought that was standard procedure....
[19:21] <mathrick> yes, I'm just making sure
[19:21]  * RumblePure is ready to get barked at. :-)
[19:21] <mathrick> RumblePure: well then, you still have conflicts
[19:22] <mathrick> didn't bzr update tell you that?
[19:22] <RumblePure> mathrick: yes, and when I have done bzr update it suggests I do bzr conflict file_name.
[19:22] <mathrick> and it's right :)
[19:22] <mathrick> RumblePure: you got text conflict, it's that simple
[19:22] <mathrick> have you committed anything to the stationary branch in the meantime?
[19:22] <mathrick> you or anyone else?
[19:23] <RumblePure> mathrick: but how come? I didnt touch my code on the stationary after checkout.
[19:23] <RumblePure> NO, strictly no!
[19:23] <RumblePure> This time I have been super duper truper careful with NOT doing that.
[19:23] <RumblePure> Because this is not the first time i have this kind of problem!
[19:23] <mathrick> okay, then bzr got confused about what your tree is, somehow
[19:23] <RumblePure> mathrick: does it have to do with the fact that my ip got changed on stationary?
[19:24] <RumblePure> I did modify .bzr/branch/branch.conf after all....
[19:24] <mathrick> not sure, it shouldn't, but then I suspect I don't have a full picture of what happened yet
[19:24] <mathrick> RumblePure: bzr pays no attention to IPs, only the tree states are of interest, and these are immutable and identified by hashes
[19:25] <mathrick> but somehow you convinced bzr that the changes you made are already there
[19:25] <RumblePure> mathrick: then I dunno what's going on.
[19:25] <mathrick> RumblePure: let's debug it
[19:25] <xnox> Reading bzr/docs/developer/testing didn't help much. Reading tests...... well there are loads of them
[19:26] <mathrick> bzr log --show-ids bzr+ssh://desktop/repo/projects shows what?
[19:26] <RumblePure> mathrick: ok, let me run that.
[19:26] <mathrick> please paste the first ten or so commits in pastebin
[19:26] <xnox> can you please suggest a good testsuite of a small plugin that extends standard bzr commands?
[19:27] <mathrick> xnox: I have no idea about the testsuite, but the plugin pager extends standard commands in several places
[19:27] <mathrick> *pager plugin
[19:27] <RumblePure> 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] <RumblePure> mathrick: and then I'll run your commands asap.
[19:28] <mathrick> RumblePure: don't do that, because it's fixing things that shouldn't happen
[19:28] <mathrick> your files didn't go anywhere, so spending time on fixing them is useless
[19:28] <mathrick> determining what exactly went wrong is a much better use of your time
[19:29] <RumblePure> 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] <RumblePure> mathrick: ok, I'll cancel.
[19:29] <mathrick> if you want clean copies of them, just branch the last revision of your laptop branch
[19:29] <mathrick> it'll give you a nice working tree
[19:31] <mathrick> RumblePure: when you're done, run the same thing for your laptop branch, and paste it in pastebin too
[19:32] <mathrick> then link here
[19:35] <RumblePure_> mathrick: ok done: http://pastebin.com/8H9t25V6
[19:35]  * RumblePure_ is RumblePure from his laptop.
[19:35] <mathrick> RumblePure_: that's the log for the stationary branch?
[19:36] <RumblePure> mathrick: eyh yeah that's the log for the stationary when I ran that command from the laptop.
[19:37] <mathrick> 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] <mathrick> ie. the first command after which bzr told you to update
[19:37] <RumblePure_> will do chief.
[19:38] <RumblePure> ok, now I'll give an accurate recap of what I did.
[19:39] <RumblePure> 1. I modified .bzr/branch/branch.conf, on my laptop, to match the ip-number of my stationary.
[19:39] <RumblePure> 2. I did bzr commit --strict on the laptop, and that's when the problems started.
[19:40] <RumblePure> 3. I did bzr update
[19:40] <RumblePure> 4. I did bzr conflicts
[19:40] <mathrick> 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] <RumblePure> At this time I realized that a file php/cassandra/cassandra.php was screwing around.
[19:40] <mathrick> lemme test that
[19:41] <RumblePure> Ok, I'll continue to recap while you do that.
[19:41] <RumblePure> 5. I did bzr resolve php/cassandra/cassandra.php (still on lappy).
[19:42] <RumblePure> This produced some files called cassandra.php.BASE, cassandra.php.BASE.moved and etc.
[19:42] <RumblePure> 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] <RumblePure> 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] <RumblePure> There you go, my 7 steps to one hour waste of time. :'-(
[19:44] <mathrick> rumblePure: first of all, that's not how you deal with conflicts
[19:44] <mathrick> a conflict means bzr wasn't able to resolve changes automatically. Removing things without understanding the conflict is the wrong way
[19:44] <RumblePure> Well, I had a feeling I was doing _something_ wrong. :-/
[19:45] <mathrick> now, I've tried to do what you described, and it works just fine
[19:45] <RumblePure> 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] <mathrick> 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] <mathrick> rumblePure: yes, please
[19:46] <RumblePure> no, can't share content of branches, sorry. :-/
[19:46] <mathrick> and if it happens, give the exact history of all your commands, without any editing
[19:46] <RumblePure> ok, will do so.
[19:47] <mathrick> 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] <RumblePure> sure, gimme a minute.
[19:53] <RumblePure> ok, I have created a new dummy project and a bzr branch, let me check it out to the lappy.
[19:55] <RumblePure> check out went fine, will play with the dummy file a bit and do some local check ins.
[19:55] <RumblePure> *local commits
[19:57] <RumblePure> I'll even go so far that I'll disconnect my stationary to obtain new ip-address.
[20:01] <RumblePure> mathrick: are you there? I obtain the same error!
[20:01] <RumblePure_> 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] <RumblePure_> To commit to master branch, run update and then commit.
[20:02] <RumblePure> haum, maybe printing that was a bad idea. :-/
[20:03] <RumblePure> mathrick: If you want you can tell me now what to do in order to proceed and investigate the problem/bug.
[20:03] <mathrick> rumblePure: that's not an error, the question is if you get conflicts after that
[20:04] <RumblePure> mathrick: ok, so i'll do bzr update
[20:04] <mathrick> proceed as you did with your normal work, ie. update and try to commit again
[20:06] <RumblePure> mathrick: nope, no problems at all. At this time I'll give up.
[20:06] <mathrick> rumblePure: then you had to do something differently
[20:06] <mathrick> what I suspect might've happened is that you committed twice at some point, without realising
[20:06] <RumblePure> mathrick: I didn't change the ip-number in branch.conf but you keep saying that shouldn't matter.
[20:06] <mathrick> and because the IPs were different, it recorded different revids
[20:07] <jml> how could I use bzrlib's mail APIs to build and send an email with a binary attachment?
[20:07] <mathrick> 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] <cyberswat> Hi, Is it possible to generate a report on a specific users commits in a projects?
[20:07] <jml> oh huh
[20:07] <RumblePure> mathrick: yeah i said that but this time my stationary refused to change ip-number. :-/
[20:08] <jml> SMTPConnection.send_email accepts a MIMEMultipart object
[20:08] <RumblePure> let me see if turning the modem off will convince it otherwise.
[20:08] <RumblePure> 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] <RumblePure> ok i'll go offline now and be back.
[20:09] <mathrick> k
[20:15] <cyberswat> 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] <RumblePure> 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] <mathrick> RumblePure: linux?
[20:18] <RumblePure> mathrick: yes dont bark at me I'm doing a google-search right now. :-)
[20:18] <mathrick> am not barking, just asking
[20:19] <dash> cyberswat: bzr-xmloutput might be handy if you want to parse it from another program
[20:19] <RumblePure> mathrick: I was kidding, but that's the normal comment you get on irc: "google" :)
[20:20] <mathrick> RumblePure: ifdown eth0; ifconfig eth0 hw ether 00:01:02:03:04:05
[20:20] <mathrick> I think
[20:20] <cyberswat> 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] <RumblePure> ok, i'm going down again and will reappear.
[20:20] <mathrick> s/eth0/proper iface name/ of course
[20:32] <RumblePure_> mathrick: I've got the new ip-number, so I'll proceed now.
[20:32] <RumblePure_> mathrick: Just what's a bit spooky is I've got the modified mac-address even after reboot. :-/
[20:35] <RumblePure_> mathrick: Problem/bug reproduced!
[20:35]  * RumblePure is testing on laptop.
[20:36] <RumblePure> 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] <RumblePure> mathrick: So then I modified branch.conf and then did bzr commit --strict, and now I get this error:
[20:37] <RumblePure> mathrick: I get this error: http://pastebin.com/9szZAAnL
[20:39] <mathrick> rumblePure: okay, lemme try to reproduce it, and in the meantime please zip up both branches, and the command history
[20:39] <RumblePure> mathrick: so you think somethings is wrong here?
[20:40] <RumblePure> mathrick: gimme an e-mail address.
[20:41] <mathrick> rumblePure: if you could reproduce it, then something is going wrong
[20:42] <mathrick> 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] <RumblePure_> remember, I get a new ip on stationary and change branch.conf on laptop.
[20:43]  * RumblePure_ is writing down command history
[20:43] <mathrick> 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] <mathrick> rumblePure: it should be available in ~/.bash_history
[20:56] <RumblePure_> mathrick: what's your e-mail?
[20:56] <mathrick> rumblePure: I sent it to rumblePure in /msg
[20:58] <RumblePure_> mathrick: you should have it now.
[20:59] <mathrick> yu[
[20:59] <mathrick> *yup
[20:59] <mathrick> lemme try recreating this
[20:59] <RumblePure_> mathrick: now, would you please let me know how I can get my old mac-address back? :(
[20:59] <mathrick> 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] <RumblePure_> 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] <RumblePure_> mathrick: I use Kubuntu (no surprise there). :)
[21:01] <mathrick> maybe you were being naughty
[21:01] <RumblePure_> mathrick: i dont drink. i dont smoke. i dont do drugs. i dont even have a girl.
[21:01] <mathrick> RumblePure_: also I think setting 00:00:00:00:00:00 as the mac restores the default, but lemme check
[21:01] <mathrick> RumblePure_: consider starting smoking, drinking, drugs and girls then :)
[21:02] <RumblePure_> mathrick: yeah, just to balance things out. LOL! ;)
[21:03] <RumblePure_> 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] <mathrick> 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] <mathrick> you'll avoid dealing with the conflicts this way
[21:06] <mathrick> RumblePure_: btw, lshw -class net will show you what should be original MAC addresses
[21:06] <RumblePure_> mathrick: ok will use lshw -class later.
[21:08] <RumblePure_> 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] <RumblePure_> But mathrick, I've got something else weird to report.
[21:09] <RumblePure_> 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] <RumblePure_> I just checked other files that I had been working on on my laptop. They are prime and good.
[21:11] <mathrick> RumblePure_: okay, this is very weird, I did more or less the same and it works just fine
[21:11] <mathrick> only thing is that I didn't change the IP but the symbolic host name
[21:11] <mathrick> RumblePure_: what does bzr --version say?
[21:12] <RumblePure_> 2.0.2 ...........
[21:12] <RumblePure_> what version do you have?
[21:12] <mathrick> RumblePure_: okay, please paste the output bzr plugins -v
[21:12] <mathrick> 2.1.0 here
[21:13] <RumblePure_> why won't mine update? I've got repositories.
[21:13] <RumblePure_> Oh wait, maybe I'm using ubuntu's repositories.....
[21:13] <mathrick> 2.1.0 is not in the main archive I believe
[21:13] <RumblePure_> 2.1.0 is not stable?
[21:13] <mathrick> anyway, that's beside the point, if it's always one file, I suspect there are external factors at play
[21:13] <mathrick> it is, but that doesn't mean it'll be pushed to released versions' repositories
[21:14] <mathrick> and the bzr distribution in ubuntu has changed recently, I'm confused about the exact details
[21:14] <mathrick> 2.0.2 is recent enough, I'm more interested in the plugins you run now
[21:14] <mathrick> because something is clearly touching a single file
[21:14] <RumblePure_> http://pastebin.com/0jtH9s5p
[21:15] <mathrick> RumblePure_: and it happened in test.php as well you say, in the test repo?
[21:15] <RumblePure_> I've not played around with plugins to my knowledge.
[21:15] <RumblePure_> yes, test.php
[21:15] <RumblePure_> and in my main project repo, it happens to a specific file.
[21:15] <mathrick> hmm, nothing suspicious
[21:16]  * mathrick moves to looking at the zipped repos
[21:16] <mathrick> that might take some time
[21:16] <RumblePure_> mathrick: but you didn't change the ip-number. couldn't be that?
[21:16] <mathrick> RumblePure_: it's very odd, since nothing of this sort happens here
[21:16] <mathrick> RumblePure_: I changed the hostname
[21:16] <RumblePure_> mathrick: change the ip!
[21:16] <mathrick> that should be enough, if it's triggered by the remote host's name
[21:17] <mathrick> will try that later
[21:17] <RumblePure_> mathrick: well maybe it fetches the ip number in the end and somehow uses that (for hashing or such).
[21:17] <RumblePure_> mathrick: maybe changing hostname doesnt matter because it does something to ip on some lower level.
[21:17] <mathrick> it still shouldn't affect anything
[21:18] <RumblePure_> but this problem should not arise in the first place! so what difference does it make that it _shouldn't_ affect anything?
[21:18] <RumblePure_> this is a bug, so all bets are off! :)
[21:19] <RumblePure_> 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] <mathrick> RumblePure_: the zips you have sent me have a terribly unusual directory structure. I suspect that might not be unrelated
[21:21] <RumblePure_> mathrick: it's a test-directory, containing a test.php and the .bzr.
[21:22] <RumblePure_> 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] <mathrick> RumblePure_: and the zip has paths like ../../../../../../home/
[21:22] <mathrick> RumblePure_: I'm saying there's something fishy, and I can't extract these zips
[21:22] <RumblePure_> mathrick: euh, where do you see that cause I cant recall that?
[21:22] <mathrick> branch_on_laptop.zip you sent me
[21:22] <RumblePure_> mathrick: what's wrong?
[21:22] <RumblePure_> RumblePure: let me package them again.
[21:23] <mathrick> /../../../../home/purerumble/files/temporary-files/test/
[21:23] <mathrick> for instance
[21:23] <mathrick> that's from the stationary
[21:23] <RumblePure_> mathrick: where do you see that in the zip? in what file?
[21:23] <mathrick> no idea what happened here, but it's not normal
[21:23] <mathrick> in both zips you sent me
[21:23] <mathrick> there's a single directory called ".." at the toplevel of the file
[21:23] <mathrick> in it is a single directory called ".."
[21:23] <mathrick> etc.
[21:25] <RumblePure_> mathrick: making tar.gz now
[21:26] <RumblePure_> mathrick: there, you should have two tar.gz files now.
[21:27] <mathrick> RumblePure_: it has the same paths, how are you creating them?
[21:27] <RumblePure_> i use the gui in kubuntu.
[21:27] <nitian> when i do bzr merge i get : bzr: ERROR: No location specified or remembered ?
[21:28] <RumblePure_> let me do command-style
[21:29] <mathrick> RumblePure_: it's okay, I can extract them
[21:29] <mathrick> it's just odd
[21:29] <RumblePure_> mathrick: I can run tar from bash to get you the tar.gz files if you want me to.
[21:29] <mathrick> nitian: you have to say bzr merge bzr://some.brach/or/another/
[21:30] <mathrick> the first time anyway, it will remember it for subsequent uses
[21:30] <mathrick> RumblePure_: nah, it's okay
[21:31] <RumblePure_> ok, now let me see if I can get some darn work done here. :(
[21:31] <mathrick> RumblePure_: out of curiosity, could you please run `bzr status .directory' in any of your branches?
[21:31] <RumblePure_> not to say it hasn't been fun tracking this problem/bug down. :) Cause it has really been auhm, educating. :)
[21:32] <RumblePure_> mathrick: oh oh, I forgot about that.
[21:32] <RumblePure_> my distro keeps creating these .directory files in every directory.
[21:32] <mathrick> yes, it's KDE doing that
[21:32] <mathrick> and bzr --strict doesn't complain about it?
[21:32] <RumblePure_> On my main project, I tell bzr to disregard from .foo.bar files
[21:33] <RumblePure_> mathrick: euh, why should it complain when it was added to the branch from start?
[21:34] <mathrick> dunno
[21:34] <RumblePure_> 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] <mathrick> it doesn't add .dotfiles by default I believe
[21:34] <RumblePure_> are you sure? cause if it doesn't then you got that file by misstake only. then please disregard from it
[21:34] <RumblePure_> but oh ok i'll do bzr status
[21:34] <mathrick> RumblePure_: okay, I have absolutely no idea how you got there, but that history graph is NOT right
[21:35] <RumblePure_> mathrick: ....... what history graph?
[21:35] <mathrick> of your branches
[21:35] <mathrick> both of them show rev 2 as a merge, and basically neither has the original changes in the mainline history
[21:35] <RumblePure_> still dunno what you're talking about.
[21:35] <mathrick> that's wrong
[21:35] <nitian> mathrick: would this work too: bzr merge lp:something
[21:35] <mathrick> RumblePure_: bzr log stationary
[21:36] <mathrick> nitian: yes, and branch spec will work
[21:36] <mathrick> including plain directory paths and whatever else you might have registered
[21:36] <nitian> mathrick: where there is a : bzr branch lp:something
[21:36]  * mathrick has colo:origin/trunk for instance
[21:37] <RumblePure_> mathrick: bzr log > http://pastebin.com/RUqzvwtA
[21:37] <nitian> mathrick: ok.what is a branch spec? :)
[21:37] <mathrick> RumblePure_: oh, I know, I was telling you what history graph. Re-run the same command with -n0 added
[21:37] <mathrick> notice the indented revisions
[21:37] <mathrick> does it look familiar?
[21:38] <mathrick> now notice how neither branch has them non-indented, as if both merged from the other
[21:38] <mathrick> I don't understand how you got there
[21:39] <RumblePure_> mathrick: just look at the dango commands i sent ya
[21:39] <mathrick> 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] <mathrick> RumblePure_: that's what I'm doing sir
[21:39] <nitian> mathrick: ok. thanks :)
[21:39] <mathrick> it doesn't make it any less baffling
[21:40] <RumblePure_> mathrick: look, if it hasn't crossed your attention by now then yes, I'm a newb with capital letters. But I've sent you step by step instr on what I've done to end up here. You're the expert so you tell me what's causing this.
[21:41] <RumblePure_> mathrick: and if there is anything else I can do then tell me and it will be done.
[21:41] <mathrick> RumblePure_: I know you're a newb, and I'm trying to explain the problem to you so you have a clue too. Just because I have used bzr for some time doesn't mean that graph starts making sense or that I see how it could result from the commands you ran
[21:41] <mathrick> basically, what you got is impossible
[21:42] <mathrick> or should be
[21:42] <RumblePure_> mathrick: well don't overlook this simple observation that has been made: something freaky happens when I change ip!
[21:44] <mathrick> okay, so this is how the UI for checkouts works apparently. I can't say it's in any way intuitive or sensible
[21:44]  * mathrick notes to file a bug later
[21:48] <RumblePure_> mathrick: yes, because I just did checkout and commit to/from laptop without changing ip-number and the indentation remains.
[21:48] <RumblePure_> so that is working as they feel it should.
[21:48] <RumblePure_> on both branches it simply stattes that revno 2 was a merge back to stationary. this makes sense to me, and I'm a newb... so you're just making it too complicated. :)
[21:49] <RumblePure_> *states
[21:50] <RumblePure_> mathrick: did you test changing ip-number? 'cause I really cant think of anything else that's causing this bug.
[21:51] <mathrick> doing that now
[21:51] <lifeless> moin
[21:55] <rhkfin> commit - push - uncommit - undo changes - how do I now push the 'uncommit' to the push-repo??
[21:55] <mathrick> you don
[21:55] <mathrick> 't
[21:55] <mathrick> well, not directly
[21:56] <mathrick> perhaps push would establish a new tree tip, but anything with the deleted revision as the parent would continue to derive from it
[21:56] <mathrick> in general, once you publish thing, unpublishing them is Hard™
[21:56] <dash> worst case, you can use push --overwrite
[21:57] <rhkfin> So locally I'm now one version 'behind'..
[21:57] <Manganeez> If you have shell access, you can go uncommit in the push-repo.
[21:57] <rhkfin> Can I pull the rev, make new changes and make new commit?
[21:57] <rhkfin> Manganeez: no shepp access.. Launchpad :/
[21:57] <dash> remember that doing this is basically rewriting history, so you're breaking compatibility with any other branches
[21:57] <rhkfin> mathrick: ok, so you always want to think before pushing..
[21:58] <rhkfin> dash: push --overwrite, will check what it does..
[21:58] <rhkfin> dash: hmm.. that's not what I want..
[21:58] <rhkfin> compatibility needs to be stored..
[21:58] <mathrick> RumblePure_: one question, when you commit from laptop without strict, do you have any uncommitted changes, or is that on a clean tree with everything previously recorded by commit --local?
[21:59] <lifeless> rhkfin: push --overwrite
[21:59] <rhkfin> So if I now push to a new repo, things will work and be compatible with other branches??
[21:59] <lifeless> is what you need to do
[21:59] <RumblePure_> mathrick: you mean "without local", right?
[21:59] <mathrick> RumblePure_: yes
[21:59] <mathrick> rhkfin: define "compatible"?
[22:00] <RumblePure_> mathrick: no I don't have any uncommitted changes.
[22:00] <Manganeez> I wanted to ask for advice on the best way to track a vendor subversion repository while maintaining my own local changes separately. Specifically, I want to track Wordpress, including being able to switch to a new version tag when one is created (as easily as possible), while committing my own customizations (which will never be pushed upstream) locally using bzr.
[22:00] <mathrick> if anyone has branched / pulled the deleted repo, no, it will be incompatible
[22:00] <RumblePure_> mathrick: everything has been committed.
[22:00] <mathrick> RumblePure_: ok
[22:00] <RumblePure_> mathrick: but remember that this is irrelevant if ip-number hasn't changed. because then it will work even if nothing has been modified since last local commit.
[22:01] <rhkfin> mathrick: hmm.. I'll see..
[22:01] <RumblePure_> mathrick: sorry for naging about the ip-numbers, just wanna point that out. :9
[22:01] <RumblePure_> *:)
[22:01] <mathrick> I know, I know
[22:01] <mathrick> I have changed the I
[22:01] <mathrick> IP even
[22:01] <mathrick> Manganeez: bzr-colo with an origin/trunk branch might be a useful setup
[22:01] <RumblePure_> mathrick: ... and......
[22:02] <mathrick> Manganeez: but really, any branch should work if you don't ever want to push upstream. Bzr-svn is careful to assign reproducible revids
[22:02] <rhkfin> mathrick: can I bzr pull http://pushedrepo (as it's now one version ahead?), then manually undo my last changes and make new commits & push, and compatibility with other pulled repos is maintained?
[22:02] <rhkfin> extra commits are no problem
[22:03] <mathrick> rhkfin: no, the compatibility will never be maintained once you back out an already published revision
[22:03] <mathrick> it's impossible to do
[22:03] <dash> rhkfin: if you want to undo a revision, you don't use uncommit, you use merge to back out the changes then commit that
[22:03] <mathrick> if anyone has grabbed that repo, they will need to remove it manually
[22:03] <rhkfin> pain..
[22:03] <rhkfin> ok, I'll see if anyone already pulled the repo..
[22:04] <mathrick> rhkfin: but look at what dash says, because it looks like what you want to do really
[22:04] <dash> rhkfin: no need, just do it the sensible way :)
[22:04] <dash> rhkfin: "bzr merge -r-2..-1 ."
[22:04] <dash> this will apply the changs needed to undo the last revision
[22:04] <rhkfin> dash: ok, I see..
[22:04] <dash> rhkfin: so you just check that in
[22:05] <dash> rhkfin: 'uncommit' is different, because it removes the commit from the branch entirely; this way just creates a new revision that undoes an old one.
[22:05] <rhkfin> dash: I see now.. thanks for pointing that out
[22:05] <dash> uncommit is handy for a local branch where you committed earlier than you meant to.
[22:05] <Manganeez> dash: only branches created between the commit and uncommit would be affected, right?
[22:06] <dash> but if the change has been shared, you can't really unshare it :)
[22:09] <mathrick> Manganeez: FSVO "only"
[22:09] <Manganeez> hehe
[22:11] <rhkfin> on merge text conflict I solve it manually, right
[22:11] <rhkfin> ?
[22:12] <mathrick> yes
[22:12] <Manganeez> so, on the subversion thing: I'd like something as close to this as possible: Checkout/branch svn-repo/tags/2.9.2; repeat: (make local customizations; bzr commit); New upstream ver! Switch to svn-repo/tags/2.10.0 (and merge?); bzr commit? repeat: (more local customizations; bzr commit). What's the easiest scenario?
[22:13] <mathrick> Manganeez: bzr branch svn://repo/tags/2.9.2; ...; bzr merge --remember svn://repo/tags/2.10.0
[22:14] <mathrick> as far as I know, it should Just Work™
[22:14] <Manganeez> Even better: I'd really like to have a centralized bzr repo for my customization (there are more than one of us working on it)
[22:14] <mathrick> Manganeez: then you do the same, except you also have a cetralised branch that tracks upstream :)
[22:14] <Manganeez> mathrick: thanks a heap - I hadn't seen --remember before....reading about it
[22:17] <Manganeez> Oh, remember does almost nothing: the "just works" comes for free even without that, it seems
[22:17] <Manganeez> wow - maybe I just messed up when I tried it. Retesting
[22:17] <mathrick> RumblePure_: okay, I can't reproduce it. I'll have to direct you to more experienced bzr folks. lifeless seems to be awake, FWIW :)
[22:21] <nitian> mathrick: if i stop(ctrl-c) a merge activity while it is running merge, would there be any problems?
[22:21] <mathrick> no
[22:21] <Manganeez> mathrick: the svn urls can be just http for subversion, correct? Sorry, I'm still in n00b-mode on bzr-svn
[22:21] <mathrick> nitian: if C-c ever breaks things, it's a bug and needs to be reported
[22:21] <mathrick> all bzr does is supposed to be atomic
[22:21] <mathrick> Manganeez: yes
[22:22] <nitian> mathrick: ok! so i could do bzr merge lp:something tomorow as well! actually i have to go ! and merge is taking lot of time. :)
[22:22] <rhkfin> mathrick: dash thanks for your help, I think I got it now solved :)
[22:22] <mathrick> nitian: that's some big trees you have there then
[22:23] <nitian> nitian: and/or slow b/w! ;)
[22:23] <nitian> mathrick: and/or slow b/w! ;)
[22:24] <Manganeez> Is there a way to branch from an svn repo without the *full* history? I don't need the details on individual vendor commits.
[22:26] <RumblePure> mathrick: do we give up for today? I'll update bzr later to see if the problem persists.
[22:26] <mathrick> RumblePure_: yes, though you really need to grab someone more versed in bzr. It's beyond my ability to debug
[22:26] <mathrick> Manganeez: no
[22:26] <mathrick> it's a commonly requested feature, but it's not trivial
[22:27] <Manganeez> yea, I can visualize how that might not be so easy
[22:27] <mathrick> so it hasn't been implemented yet
[22:27] <RumblePure> mathrick: ok. thx for all your time & help today.
[22:27] <Manganeez> ditto on the thx to mathrick
[22:28] <lifeless> Manganeez: RumblePure: whats wrong ?
[22:28] <mathrick> no problem
[22:28] <RumblePure> lifeless: Manganeez is not involved
[22:29] <lifeless> Manganeez: sorry! I meant mathrick.
[22:29] <mathrick> lifeless: RumblePure_ has been running into a bug where bzr up on a checkout causes conflicts with the bound branch, even though only commits on the checkout have happened
[22:29] <RumblePure> lifeless: gimme your e-mail address and you'll have something that describes it all
[22:30] <lifeless> what version of bzr are you using ? We recently changed the algorithm bzr uses for update
[22:30] <RumblePure> lifeless: 2.0.2
[22:30] <lifeless> get 2.1.0 or newer
[22:30] <lifeless> * ``bzr update`` performs the two merges in a more logical order and will stop
[22:30] <lifeless>   when it encounters conflicts.
[22:30] <lifeless>   (Gerard Krol, #113809)
[22:31] <lifeless> is included in 2.1.0
[22:31] <RumblePure> lifeless: did mathrick tell you that this only happens when the ip-number of the host keeping the main branch changes?
[22:31] <mathrick> lifeless: how come it encounters conflicts in the first place?
[22:32] <mathrick> lifeless: and while we're at it, why does update do merges at all? That makes no sense, it should fast-forward whenever possible
[22:32] <lifeless> mathrick: well, its persumably a bug; the question is whether we have already fixed it.
[22:32] <lifeless> mathrick: as for why it does merges, any time you integrate code its a merge
[22:32] <lifeless> RumblePure: does the old ip stop serving ?
[22:32] <lifeless> RumblePure: or are you using a CNAME or something ?
[22:33] <RumblePure> lifeless: ? the ip of the stationary that keeps main branch is dynamic, so it changes. and on laptop i have to modify branch.conf
[22:33] <lifeless> anyhow, the first thing to do is to check bzr 2.1.0 on th client
[22:33] <mathrick> lifeless: but it hides revisions. What it does is turn purely linear history on a single branch into merges just because I happened to make some commits while disconnected
[22:33] <mathrick> that's makes no sense at all
[22:34] <RumblePure> lifeless: I wanna use this repository https://launchpad.net/~bzr/+archive. you know what i have to write in sources.list? I've got ubuntu karmic.
[22:34] <mathrick> even the need to update is not clear, it should just push
[22:34] <lifeless> mathrick: it will still be linear if no one committed to trunk
[22:34] <lifeless> mathrick: it will however roll up your commits, because thats what you're asking it to do
[22:34] <lifeless> mathrick: what bzr version are you using ?
[22:35] <mathrick> 2.1.0
[22:35] <lifeless> RumblePure: on the web page you linked are instructions
[22:35] <mathrick> lifeless: how am I asking it to roll up?
[22:35] <mathrick> ah, you mean by commit instead of push?
[22:35] <lifeless> mathrick: and do you also get spurious conflicts ?
[22:35] <mathrick> no
[22:35] <lifeless> mathrick: yes, precisely.
[22:35] <mathrick> I couldn't get any conflicts whatsoever
[22:37] <mathrick> lifeless: presumably that's a UI bug and it should somehow suggest using push instead
[22:38] <mathrick> TBH, I haven't even thought of using commit for that before, but I can see where that came from
[22:39] <nitian> mathrick: would you please have a look here: http://pastebin.com/vQSkSht0
[22:41] <mathrick> nitian: bzr info ~/proj says what about the format?
[22:46] <nitian> mathrick: format: 2a
[22:46] <mathrick> nitian: then the lp:something branch is old. I dunno how upgrading on lp works
[22:48] <nitian> mathrick: how can i change the default push branch of bzr, it is showing something i had made while learning bzr. Related branches:     push branch: bzr+ssh://nazi@bazaar.launchpad.net/~nazia/%2Bjunk/myproject/
[22:49] <mathrick> nitian: sure, --remember
[22:49] <nitian> mathrick: whereas it should be bzr push lp:~nazia/something/myproject
[22:50] <mathrick> nitian: bzr push --remember lp:~nazia/something/myproject
[22:50] <nitian> mathrick: ok! :)
[22:51] <nitian> mathrick: changed. thanks.
[22:56]  * Manganeez is confused
[22:56] <mathrick> why?
[22:57] <Manganeez> bzr branch http://core.svn.wordpress.org/tags/2.7.1/ ; Make a comment change in one file for testing; bzr commit; bzr merge http://core.svn.wordpress.org/tags/2.8/; 41 conflicts in files I did not touch.
[22:57] <rhkfin> Any idea why bzr push sftp://me@my.web.server only creates new folderbut with no data files in it, only .bzr folder
[22:58] <Manganeez> rhkfin: push doesn't do an update
[22:58] <mathrick> rhkfin: bzr help push
[22:58] <mathrick> first paragraph
[22:58] <rhkfin> great, thanks :)
[23:00] <mathrick> Manganeez: hard to say, but might be because they were backporting changes
[23:00] <rhkfin> OK, interesting.. so what's the way to get the folder populated? THe server doesn't have bzr installed...
[23:00] <mathrick> Manganeez: svn doesn't exactly have robust merges, which ripples as you try to slurp from it...
[23:01] <mathrick> rhkfin: there are plugins, such as push-and-update or rsync
[23:01] <mathrick> browse the plugins listing on the website
[23:01] <rhkfin> bzr plugins, c00l :)
[23:01] <rhkfin> ok, thanks!
[23:02] <Manganeez> I think push-and-update requires bzr installed on the server, because it just ssh's in an runs bzr update for you
[23:02] <rhkfin> ok, so it'll not work..