[12:05] <Verterok> Hi y'all
[12:09] <Verterok> beuno: ping
[12:25] <beuno> Verterok, pong
[12:26] <Verterok> beuno: Hi!
[12:27] <beuno> hey Verterok, how are you doing?
[12:27] <Verterok> working a bit in bzr-eclipse & bzr-xmloutput :D , how are you?
[12:30] <beuno> Verterok, working on my php<>bzr integration :D
[12:30] <beuno> what are you working on with bzrxml?
[12:31] <Verterok> I made some changes that modify a bit (actually extend) the generated xml :P
[12:31] <Verterok> these are related to merges and affected files (bzr log -v)
[12:32] <beuno> Verterok, interesting, I'm basing the php integration on your plugin, dos it change the format of the zml at all?
[12:32] <beuno> *xml
[12:33] <Verterok> I can pastebin a generated xml, but the change is how the revisions are handled
[12:34] <Verterok> the current trunk handle all revisions as equals (i.e: don't know about merges)
[12:34] <beuno> Verterok, would you?  that way I can start crying on all the changes I have to make  :p
[12:34] <Verterok> sure
[12:35] <beuno> although it's great you're extending it, if you need a hand, I get along much better with python then with java  :D
[12:36] <Verterok> maybe this is not too big, basically I added two new tags: <merge> and <affected-files>
[12:36] <Verterok> both are child elements of <log>
[12:37] <beuno> Verterok, aren't the affected files already shown?
[12:38] <Verterok> I don't remember :P
[12:38] <beuno> hahaha
[12:38] <beuno> ok ok, well, you already show the deleted/new/modified
[12:38] <beuno> as a child of <log>
[12:39] <Verterok> in my branch I added a <affected-files> tag, to group them
[12:39] <beuno> ah, well, that will probably just me my code cleaner
[12:40] <beuno> that's the only bit that's a bit... les the ideal  :D
[12:41] <beuno> what will the merge tag show?
[12:41] <Verterok> I think that the *other* change 'll take a bit more of work  (sorry for that)
[12:41] <Verterok> take a look: http://rafb.net/p/thAACb16.html
[12:42] <beuno> Verterok, I welcome any improvements, I really do :D
[12:43] <Verterok> great to known, but the <merge> is a big change :P
[12:43] <Verterok> it group the merge revisions logs
[12:43] <beuno> aaaaaaah
[12:43] <beuno> Verterok,I understand  :D
[12:43] <beuno> I was actually doing that manully in the PHP code
[12:44] <Verterok> ah, great then! I think your code could be clean up a bit :D
[12:44] <beuno> I'll probably shave off half the lines of code!  yay!  :D
[12:44] <Verterok> so, I have your OK to push to trunk? ;)
[12:45] <beuno> as I imported I chedked if it was a subrevision, and if it was, associated it
[12:45] <beuno> Verterok, I'm pretty sure you don't need my OK, but I welcome it
[12:46] <Verterok> I started to work in the same processing (at the java side), but then I changed bzr-xmloutput :D
[12:47] <beuno> heh, yes, it makes much more sense
[12:47] <beuno> I wasn't as confident to go in and change someone's else code
[12:47] <Verterok> you are most than welcome to do it :D
[12:47] <beuno> I have been playing around with bzr code more lately, even got a few patches in  :D
[12:48] <beuno> Verterok, cool, thanks, I'll look into what I'm missing/doing on my side that I can do directly in the plugin, branch, and ping you  :D
[12:49] <Verterok> great! congrats!
[12:49] <Verterok> sure!
[12:49] <beuno> I tuhnk I'll be able to release some of my php code in the following weeks, quite a few people have been requesting it, so it doesn't make sense to keep on develpoing behind closed doors
[12:50] <Verterok> beuno: I just pushed those changes. now at revno: 18
[12:50] <beuno> (I'm typing horribly today)
[12:50] <beuno> great, LP just emailed me too  :p
[12:50] <Verterok> no problem, I type horribly every day :P
[12:51] <beuno> hahhah
[12:52] <beuno> do you have any other changes in mind?
[12:54] <Verterok> no to the log command, but i need to take a look to annotate
[12:54] <Verterok> I have some plans to implement a few more commands
[12:57] <beuno> Verterok, if you want to point me at something specific to look into/code, just drop me a line and I'll see what I can do  :D
[12:58] <Verterok> for the moment I have in mind: 'bzr plugins' and 'bzr info' (maybe I'll do a custom info --xml command with more information), both to aid bzr-eclipse
[12:58] <beuno> Verterok, ah, that sounds intersting, and bzr status maybe?  or is that implemented already?
[12:58] <Verterok> it's already there :D
[12:59] <beuno> how efficient of you  :p   I'm going to need that in the near future
[01:00] <Verterok> drop me a line if you need something for: status --xml
[01:01] <beuno> Verterok, will do, thanks!
[01:02] <beuno> Verterok, what do you think on having a wiki page with ToDo's? that way it might be easier to know what needs to be done
[01:03] <Verterok> sounds great! maybe in the bazaar wiki?
[01:03] <beuno> Verterok, yeap, seems like the right place
[01:03] <Verterok> I never used yet :P
[01:04] <beuno> heh, I'll create the page real quick, we can both subscribe and spy on what the other one is thinking of  :p
[01:04] <Verterok> that 'ld be interesting
[01:06] <beuno> Verterok, http://bazaar-vcs.org/bzr-xmloutput
[01:06] <beuno> I;ve subscribed
[01:06] <Verterok> that was fast!
[01:06] <beuno> and now, I have to leave for a few hours, but we'll be in touch  :D
[01:07] <Verterok> seeya
[05:42] <nvictor> hi guys :)
[05:42] <nvictor> I just downloaded the windows version of bazaar
[05:42] <nvictor> can you tell me how it works?
[05:42] <nvictor> I'm new to version control :)
[07:28] <NamNguyen> hi
[07:28] <NamNguyen> in what encoding is NEWS?
[07:29] <NamNguyen> it shows Lukas Lalinsky as garbage
[08:17] <fullermd> Looks normal to me, and I'm in UTF-8...
[09:03] <tonyyarusso> Aren't those things usually gzipped ascii?
[10:47] <matkor> Hi ! How can make bzr setup.py install man files in /usr/share/man (FHS) instead of /usr/man/ ?
[10:48] <lifeless> not sure
[10:48] <lifeless> possibly some setup.py install --help info will help
[10:50] <matkor> mmm I am gonna check --install-data /usr/share ...
[10:50] <AfC> matkor: we did a mv ${D}/usr/man ${D}/usr/share/man in the post_inst part of the Gentoo package
[10:50] <lifeless> I don't suppose you filed a bug ? ;)
[10:52] <AfC> Against who?
[10:53] <matkor> AfC: I see similar patch for PLD ;)
[10:54] <AfC> [I mean, sure, _maybe_ FHS would be a strong enough argument to get Python to change ... but at the cost of breaking every single Python derived package out there? I doubt they'd do it, frankly] 
[10:55] <james_w> there should be an option to set the mandir though shouldn't there?
[10:56] <matkor> james_w, Afc : --install-data /usr/share seems to work
[10:57] <AfC> matkor: neat
[10:57] <james_w> thanks mak
[10:58] <james_w> matkor sorry.
[11:36] <lifeless> AfC: against bzr
[11:36] <lifeless> AfC: its our problem to make our setup.py do the right thing
[11:36] <lifeless> or to document how to do it
[11:46] <AfC> lifeless: ok
[11:47] <AfC> matkor: do you want to file it, or shall I?
[12:25] <hsn_> what i need for syntax highlighting in olive?
[12:25] <dato> in debian and ubuntu, python-gnome2-desktop
[12:26] <dato> the library is called gtksourceview
[12:26] <dato> hsn_: assuming you mean highlighting of the diffs
[12:26] <dato> I have no idea if other highlighting is supported
[12:29] <hsn_> i get olive errors like: ImportError: No module named dialog or bzrlib.errors.BzrError: must supply file_id or path
[12:40] <duckx> quicksilver: jelmer = jw ?
[12:41] <duckx> plop
[12:41] <duckx> Sorry
[12:41] <duckx> james_w: around ?
[12:41] <james_w> duckx: hi
[12:41] <duckx> duckx = Frederic Brin ;)
[12:42] <duckx> You are the guy behind bzr-builddeb right ?
[12:42] <james_w> ah, hi. Thanks for your fixes/
[12:42] <duckx> No problem, I enjoy tweeking python
[12:42] <james_w> :)
[12:43] <duckx> Well, I tried the import-dsc command
[12:43] <duckx> And I was wondering one thing
[12:43] <duckx> Well, it is may be the normal behaviour
[12:43] <duckx> When you import a dsc, the orig.tar.gz is commited
[12:43] <duckx> But the debian dir is not ....
[12:44] <duckx> Is that the normal way to go ?
[12:44] <duckx> By the way I was wondering one thing ...
[12:45] <duckx> What is the easiest way to get python have my bzr co of bzr-buildep be the python module loaded ?
[12:45] <duckx> Well, currently I hack the installed debian package, and port the tweeks back to my co tree
[12:46] <duckx> -> that sucks
[12:46] <james_w> mkdir -p ~/.bazaar/plugins/; ln -s /path/to/co ~/.bazaar/plugins/builddeb
[12:46] <duckx> k
[12:46] <duckx> Just fine for me ;)
[12:46] <james_w> as for the import let me investigate.
[12:49] <james_w> you're not using --snapshot correct? just import-dsc blah_0.1-1.dsc?
[12:49] <duckx> yes indeed
[12:49] <duckx> with the --to flag
[12:50] <duckx> bzr import-dsc --to gnucash gnucash*.dsc
[12:52] <james_w> I need to pull your fix first. Shows that I need some blackbox tests :)
[12:52] <duckx> ;)
[12:55] <james_w> I've just imported one dsc and there are no uncommitted changes.
[12:55] <duckx> Hmm, damn
[12:55] <duckx> What did I do yesterday
[12:55] <duckx> Works fine for me :(
[12:56] <duckx> Ok lets try the merge upstream thing
[12:56] <james_w> ah, merge upstream doesn't commit I think.
[12:57] <duckx> Yeah, indead, that is the normal workflow
[12:57] <duckx> But I had a wired thing after doing the following workflow:
[12:57] <duckx> import-dsc
[12:57] <duckx> Then  merge-upstream
[12:58] <duckx> bzr status gives me the following
[12:59] <duckx> http://www.pastey.net/73292
[01:00] <james_w> that looks right for the aim of the command.
[01:00] <james_w> are you confused that it added all of debian/ again?
[01:00] <duckx> Yes ;
[01:01] <james_w> ok, so I had the same opinion as you at first, but other convinced me to do it this way.
[01:01] <duckx> Well, what I don't get
[01:01] <duckx> Is that I imported gnucash-2.2.1 over a 2.0.5
[01:01] <duckx> I should see a bunch of file modified
[01:02] <duckx> nont only 2
[01:02] <james_w> let me draw it for you.
[01:02] <duckx> Yeah thx
[01:05] <james_w> actually drawing it isn't very useful.
[01:05] <james_w> what it does is really play with two branches in one, but you never see the second. Let's make the second explicit and then it might be clear.
[01:05] <duckx> My current issue is to get where the debian patch is located ... ,
[01:06] <james_w> you have an upstream branch and a debian branch.
[01:06] <duckx> k
[01:06] <james_w> the upstream branch clearly just has upstream imports on it 0.1...0.2 etc.
[01:06] <duckx> Yeah That is what I see with bzr log
[01:06] <duckx> ------------------------------------------------------------
[01:06] <duckx> revno: 2
[01:06] <duckx> tags: upstream-2.2.1
[01:06] <duckx> committer: Frederic Brin <frederic.brin@assonetworx.com>
[01:06] <duckx> branch nick: gnucash
[01:06] <duckx> timestamp: Sun 2007-09-02 13:00:17 +0200
[01:06] <duckx> message:
[01:06] <duckx>   import upstream from gnucash_2.2.1.orig.tar.gz
[01:06] <duckx> ------------------------------------------------------------
[01:06] <duckx> revno: 1
[01:06] <duckx> tags: upstream-2.0.5
[01:06] <duckx> committer: Frederic Brin <frederic.brin@assonetworx.com>
[01:06] <duckx> branch nick: gnucash
[01:06] <duckx> timestamp: Sun 2007-09-02 12:57:51 +0200
[01:06] <duckx> message:
[01:07] <duckx>   import upstream from gnucash_2.0.5.orig.tar.gz
[01:07] <james_w> so your diff between the 2.0.5 and 2.2.1 lies on this branch.
[01:07] <james_w> yeah, so you can see the upstream changes with bzr diff -r1..2
[01:07] <duckx> I get this
[01:08] <james_w> now your debian changes are based on the upstream code, so that is a separate branch that was "created" with a bzr branch -r 1 upstream debian/
[01:08] <james_w> and when you import a new upstream you need to merge the changes together.
[01:08] <james_w> the question is which way you perform this merge.
[01:09] <james_w> the way you are expecting I guess is that you do 'cd debian/; bzr merge ../upstream/'
[01:09] <james_w> and then you would see a pending merge of 'upstream 2.2.1', with all of upstream's changes, and whatever changes are made to the packaging.
[01:10] <james_w> however the plugin does it the other way, so you are currently sat on the 'upstream' branch with the 'debian' changes merged in.
[01:11] <james_w> there is no real difference, you can see upstream changes by following one 'branch' and 'debian' changes by following the others.
[01:11] <james_w> you can also get the differences by diffing them.
[01:12] <james_w> if you fire up bzr viz (if you have it), you will see that all of the parent references are 'correct'.
[01:12] <duckx> Ok, let me investigate
[01:13] <james_w> the difficulty comes with bzr's distinction that the left parent is special, in this case that is the upstream branch.
[01:13] <james_w> so bzr log etc. emphasise that, showing the mainline as upstream's code, with all of your debian/ changes merged in to the last commit.
[01:13] <james_w> but as I say, topographically all is correct, and you have the desired parent links.
[01:14] <james_w> The left parent distinction is exactly why I was going with 'merge upstream in to debian' at first.
[01:14] <james_w> However siretart convinced me otherwise.
[01:14] <james_w> one moment...
[01:14] <duckx> k
[01:16] <james_w> it's useful to have, as it makes the topography clearer than log.
[01:17] <james_w> and gannotate is far more useful than plain annotate.
[01:18] <james_w> let me know when you're up to speed and I'll explain the rationale.
[01:19] <duckx> Well, I got viz installed
[01:20] <duckx> I see the same stuff that what I see in the log
[01:21] <duckx> Ok let's draw a simple example
[01:21] <james_w> if you click on the commits on the debian branch you should see two parents for each new debian version.
[01:21] <james_w> they aren't drawn on the graph, but they are shown in the info area.
[01:22] <duckx> Well, I don't get where the debian revision is ...
[01:22] <duckx> I muss have miss one stuff
[01:22] <james_w> have you committed?
[01:22] <duckx> Nop
[01:22] <james_w> I don't think viz shows pending merge revisions.
[01:22] <duckx> Ah
[01:22] <james_w> you can always uncommit after if you like.
[01:22] <duckx> But it should have been commited for the first dsc-import ?
[01:22] <fullermd> Pending merges are figments of the working tree's imagination   ;)
[01:23] <james_w> yeah, it was, but the merge makes it a pending merge again.
[01:23] <james_w> you are on the 'upstream' branch, which knows nothing about the debian revisions.
[01:24] <duckx> Ah
[01:24] <duckx> That is
[01:24] <duckx> The reason
[01:24] <duckx> Ok let me do a commit
[01:27] <duckx> Ok commited
[01:28] <duckx> bzr viz is a lot clearer right now
[01:29] <james_w> yep
[01:30] <duckx> james_w: well I need to read about dir-state tree first
[01:30] <duckx> I think it will make the things clearer for me
[01:31] <duckx> james_w: anyhow, thx for your time, and explaination
[01:37] <james_w> duckx: no problem. Give us a shout if you want anything else explaining.
[01:37] <james_w> and thanks for your fixes.
[03:40] <dennda> hey there
[03:41] <dennda> http://pastebin.ca/678878 <-- Nice little bug I get. (Pull didn't work, so i was told to merge. That didn't work either, so i tried to push. That's the result.)
[03:42] <fullermd> Well, the immediate error is that push is a writing op, and you can't write over http.
[03:42] <fullermd> But push isn't going to solve a problem you're having with pull/merge.
[03:43] <dennda> The last line indicated it was a bug
[03:43] <dennda> That's why I ask
[03:43] <fullermd> Well, in the sense that we should say "Hey, you can't do that" instead of spitting out 30 lines of traceback, it is...
[03:44] <dennda> You want the whole thing, i guess?
[03:45] <fullermd> Well, that part isn't really a bug or anything broken; it's expected behavior, for what you tried.
[03:45] <dennda> What should I try instead?
[03:45] <fullermd> Well, that would require going into the actual problem you're trying to solve   :)
[03:46] <fullermd> It's easy enough to adjust that push so it [probably]  works, but if you're starting out trying to pull/merge something, pushing probably isn't what you want to do anyway.
[03:46] <dennda> Ah that just was the wrong adress to push to
[03:47] <fullermd> Yah.  To push you'd use a sftp://-ish (or bzr+ssh://-ish) URL.
[03:47] <fullermd> But what's the problem you have with merge?
[03:47] <dennda> Yes, i tried that now. It gave me "No new revisions to push.".
[03:48] <dennda> The actual problem is, that pull doesn't work as I would expect it: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[03:49] <dennda> So I try merge: bzr: ERROR: Working tree has uncommitted changes.
[03:49] <fullermd> Ok, let's look at 'em one at a time.  First, the pull.  Do you expect the branches to have not diverged?
[03:49] <fullermd> (usually, that would mean that you've made commits to your branch that aren't in the upstream)
[03:50] <dennda> After I changed the file of my branch the last time, I immediately pushed it. (And that worked)
[03:51] <fullermd> You can try using 'bzr missing' to figure out what revs differ between the branches; that should point you in the right direction.
[03:52] <dennda> http://pastebin.ca/678893
[03:52] <fullermd> As for the merge issue, it's just what it says; merge by default will refuse to run if you've got uncommitted changes lying around.
[03:53] <fullermd> OK, so you made your branch at revno 13.  Since that time, you've made two commits in your local branch (your 14 and 15), and Jason has made two in the upstream branch (his 14 and 15).
[03:53] <dennda> I would expect pull to grab the below mentioned two missing revisions.
[03:54] <fullermd> Pull would do that if you were still at rev 13.  But you have local changes.
[03:55] <fullermd> Pull only moves you "forward", in a sense.  And since his branch isn't "forward" of your branch (it doesn't include your current head rev), it can't do anything.
[03:55] <fullermd> So, what you need is 'merge', to merge in his revs and create a new revision with joins his changes with your local changes.
[03:56] <dennda> What would be the command to do that?
[03:56] <fullermd> That's failing for you for the reason above; you've got other changes your haven't committed yet.  So, either commit them (if you want 'em), or revert them (if you don't), then merge should do its work.
[03:57] <fullermd> (You _can_ force merge to work over uncommitted changes, but it's almost always a bad idea, because it muddles up your history.)
[03:57] <dennda> Is it possible to ask bzr what exact changes those are? I can't remember havn't changed anything that I didn't push.
[03:57] <fullermd> Mmm.  Two different questions.
[03:58] <fullermd> But this isn't stuff you haven't pushed; it's stuff you've changed but not _committed_.  So, 'bzr stat' or 'bzr diff' will tell you what's sitting around.
[03:58] <dennda> I just want to know what bzr wants me to commit.
[03:58] <dennda> Ok I will try that, just a sec
[03:59] <dennda> ah wll
[03:59] <dennda> of course
[03:59] <dennda> My programm changes the contents of the files in a directory that comes from Jasons trunk
[03:59] <dennda> And to test if my programm worked I ran it. So it changed these files.
[04:00] <dennda> I don't want to keep them. I just want to take the unaltered files from Jasons trunk. How do I do that?
[04:00] <fullermd> 'bzr revert' will get rid of uncommitted changes and bring your files back to what they were last time you committed.
[04:01] <dennda> What if I also changed the files _before_ I committed last time?
[04:02] <fullermd> Well, then that's something to resolve during the merge.  What we're doing now is making it so your working tree is the same as it was last time you committed, so that we can do the merge.
[04:03] <dennda> ok so bzr revert. just a sec
[04:03] <dennda> ok, done
[04:03] <fullermd> The sitution is something like: http://pastebin.ca/678904
[04:04] <fullermd> Right now, we're on line 11; There are two 14's and two 15's, yours and his.  We want to create a new 16 that's descended from both of them.
[04:04] <dennda> Did you draw that right now?
[04:04] <fullermd> "Draw" is probably an overstatement    ;)
[04:04] <dennda> Well it's more beautiful than I would have been able to do it.
[04:05] <dennda> So I do have to always do this merge after I commit a change?
[04:05] <fullermd> It looks something like a juniper bush being hit by lightning...
[04:06] <dennda> So I reverted, merged, tried to pull and still get: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[04:06] <fullermd> Well, it depends on the situation.  You need to merge when things have diverged.  If you and Jason were both working on a single branch, and alternated commits instead, there wouldn't be any merging.
[04:06] <fullermd> Right.  There's no way "forward" from your 15 to his 15.
[04:06] <fullermd> So, now do the 'merge', and let's see what it manages to make happen.
[04:07] <dennda> As I said: I already merged
[04:07] <dennda> If I want to do it again it says: bzr: ERROR: Working tree has uncommitted changes.
[04:07] <fullermd> Right.  Merge doesn't create the new 16; it just merges those 15's in your working tree.
[04:07] <dennda> So this seems to be quite the same situation as above
[04:07] <fullermd> Look over the changes ('diff'), and make sure the result is what you want.  Check 'stat' too, to see which files, and maybe if there are any conflicts.
[04:08] <fullermd> Think you said you wanted his version of a few files, so we may want to adjust those before you commit.
[04:08] <dennda> Ok it's what I want
[04:09] <fullermd> 'k.  If it's all how you want it, 'commit' it, which will create the new rev 16 that we want.
[04:09] <dennda> Well at least I hope so ;)
[04:10] <fullermd> Well, if it turns out not to be, claim that somebody snuck into your office and did it.  's what I always do.
[04:10] <dennda> ok i did bzr commit and it opened (to my astonishment) vim, showing me modified files, added files, etc..
[04:10] <dennda> Sounds like a great strategy for all deeds I want to do
[04:11] <fullermd> "There's no way I could have made that commit!  I was busy robbing a bank at that time!"
[04:12] <dennda> Ok, so what do I do with vim?
[04:12] <dennda> it created bzr_log.HOrCoV
[04:12] <fullermd> Put in the log message and all, just like you do on any other commit.
[04:12] <dennda> and opened it in vim
[04:13] <dennda> I don't understand this
[04:14] <fullermd> It's just like any other commit you've made.  It just happens to contain a merge, but that doesn't affect anything else about the process.
[04:14] <dennda> doesn't commit need a file specified that shall be committed?
[04:15] <fullermd> Only if you want to commit only a particular file; normally it just checks through the tree for any modified files.
[04:16] <fullermd> (and partial commits aren't supported on merges anyway)
[04:17] <dennda> so it is "bzr commit 'comment'"
[04:18] <duckx> james_w: Well, I need your advice for this
[04:18] <dennda> isn't it?
[04:18] <fullermd> Well, "bzr commit -m 'comment'", if you want to specify the log message on the command line.
[04:18] <duckx> What about chmod 755 debian/rules while import-dsc ?
[04:19] <fullermd> Without the -m, it spawns off $EDITOR for the log message.  I hardly ever use -m myself.
[04:20] <james_w> duckx: perhaps that should be added, I'm not sure.
[04:21] <duckx> Well, currently When doing this
[04:21] <duckx> bzr import-dsc
[04:21] <duckx> Then bzr builddeb
[04:21] <duckx> It fails to build because debian/rules not 755
[04:21] <dennda> fullermd: Ok. So I do push now?
[04:22] <duckx> Well, james_w patch is ready , just wait for your agreement to commit ;)
[04:22] <fullermd> dennda: If you want to push up those combined changes now, yah.
[04:22] <james_w> yeah, it seems reasonable to me. Can you add a debian/changelog entry please.
[04:23] <james_w> and one for your last fix as well if you wouldn't mind.
[04:23] <duckx> Yes shure
[04:23] <duckx> sure,
[04:24] <james_w> thanks duckx
[04:25] <james_w> is there a test for it?
[04:25] <dennda> fullermd: /me feels uncomfortable.
[04:25] <fullermd> How so?
[04:25] <dennda> I pushed now. Pull now tells me: No revisions to pull.
[04:25] <duckx> james_w: you mean unit test ?
[04:25] <james_w> duckx: yeah.
[04:25] <duckx> Nop
[04:26] <duckx> Don't think so
[04:26] <dennda> But I do need to pull in order to get Jasons changes, don't I?
[04:26] <duckx> Ups my mistake :)
[04:26] <fullermd> Not at this point, no.  Look back at http://pastebin.ca/678904
[04:26] <fullermd> His branch is now at his [right-side]  15.  Yours is at the 16.  So, you have all the changes from his branch already (though he doesn't have yours)
[04:27] <fullermd> So there's nothing for pull to do.
[04:27] <dennda> ok let me see if you tell the truth ;)
[04:27] <duckx> james_w: by the way, what is the next version number 0.90.1 ?
[04:27] <dennda> wow!
[04:27] <dennda> Seems like.
[04:29] <fullermd> Now, your two branches look a little different, of course.  His is just a straight line, from 1 to 15, like the right side up through line 11.  Yours now has that splitting apart for two revs on each side then the coming back together at 16.
[04:29] <james_w> duckx: it will probably be 0.91
[04:29] <duckx> james_w: ok
[04:30] <dennda> fullermd: yes i see. and this will always happen if I change anything from my branch?
[04:31] <fullermd> Well, it depends on the particulars of a situation.  If we imagine you made your rev 14, but he hadn't done anything, he could pull from you, and you'd both have the same straight 1->14.
[04:31] <dennda> ah
[04:31] <fullermd> When you need a merge is when you've _both_ made different 14's, because now the history has split, and merge is needed to bring it back together.
[04:32] <dennda> I hope I can figure this out on my own next time. (Still seems like "Black wiZzaRdry" to me ;))
[04:32] <dennda> But I think I understood
[04:32] <dennda> (roughly)
[04:32] <dennda> Thank you, fullermd!
[04:33] <BrianB04> Good morning everyone.
[04:33] <fullermd> No problem   :)
[04:33] <james_w> duckx: it would also be good to ensure that debian/rules exists.
[04:33] <duckx> k
[04:33] <james_w> hi BrianB04
[04:33] <duckx> Doing it right now
[04:34] <james_w> thanks.
[04:34] <BrianB04> I have a silly question, and despite finding some answers, I'm still a bit lost. I want to put my repo on my website. Now, I know you can copy the files to the webserver, but the problem is I have ignores in there, so it will take the ignored files up. Any other way to put it up on the server?
[04:34] <duckx> james_w: isn't debian/rules a mandatory ?
[04:34] <james_w> BrianB04: bzr push
[04:35] <james_w> duckx: yes, I guess you don't have to add the check, but you never know.
[04:35] <BrianB04> Now, with push, you have to commit the first time before you push, correct?
[04:35] <james_w> BrianB04: yes that is correct.
[04:35] <duckx> ok james_w
[04:37] <BrianB04> Then, once I push, do I have to pull it from the server, or is it smart enough to know where it was pushed?
[04:39] <james_w> BrianB04: it will know.
[04:39] <james_w> if it doesn't then you can bzr pull --remember sftp://... or whatever and it will remember from then on.
[04:40] <BrianB04> Very cool. Yea, I think I could get into Bazaar. I work a lot with Rails...and I typically work in what are called User Stories, so each chunk is broken up. With subversion, you have to hold back commiting because you don't want to commit untested code, and blah blah blah...pain.
[04:41] <james_w> :)
[04:42] <BrianB04> Plus, with Bazaar running so nicely on Windows.
[04:47] <james_w> thanks duckx
[04:56] <BrianB04> Now, to get my launchpad account.
[05:03] <BrianB04> You know, it's sad. NearlyFreeSpeech.net is such a superb hosting company, and they charge you for what you use, while Dreamhost, which is a touch expensive and oversells like nuts, just...is awful.
[05:11] <ashish987654321> :)
[05:46] <matkor> Can I force merge with preserving uncommited changes ?
[05:53] <james_w> bzr merge --force?
[06:00] <matkor> james_w: Thanks !
[06:40] <matkor> jelmer: Could you please merge one more fix for olive-gtk from http://bazaar.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? TIA
[06:42] <jelmer> matkor: Done, thanks!
[06:49] <matkor> jelmer: Thanks! Are you planning release 0.91 soon  ? This one with context menu was serious bug ...
[07:03] <aantn> hello
[07:04] <aantn> how can I check the version of a revision I just downloaded?
[07:07] <matkor> aantn: You mean revision number ? bzr log -r -1  ?
[07:07] <aantn> matkor: I need to find out what the number of the lastest revision is
[07:08] <aantn> and bzr log gives too many results
[07:08] <aantn> if I just run "bzr log"
[07:10] <james_w> bzr revno?
[07:10] <BrianB04> Hello all, again:)
[07:10] <dato> aantn: `bzr log -r -1` as matkor said, or just `bzr revno`, which wgives you the number and nothing else
[07:10] <aantn> hello
[07:10] <aantn> kk
[07:10] <aantn> thanks
[07:10] <BrianB04> Okay, another quick question: I pushed up the branch, so it's up on the site, now when I work on the copy on my system, and commit, it commits only to that branch, then I have to push again, and it will merge the changes?
[07:12] <dato> well, in bzr parlance there will be no changes to "merge", just changes to "push". but yes.
[07:13] <BrianB04> I'm an old school CVS/SVN user, so this DRCS is a bit of a mind switch.
[07:14] <james_w> BrianB04: yeah, your local changes are a superset of the remote ones, so you can push no problem, and it will be exactly the same as your local branch.
[07:14] <BrianB04> Only difference is commiting to my branch will never leave the main repo unstable.
[07:14] <james_w> if however you logged in to your server and also made a commit there before pushing the branches have 'diverged', i.e. one is not a superset of the other.
[07:15] <james_w> in those cases you need to merge.
[07:15] <james_w> if you only ever work on one before sychronising then push and pull will be all you need.
[07:15] <BrianB04> Well for the moment it's just me working on it, and since it's all based around sftp, I know I'm the only one that will ever push to it.
[07:16] <james_w> you can also move to a more svn like workflow by running 'bzr bind sftp://remote/'
[07:16] <james_w> which will mean that all your local commits are pushed up to the server as you do them, but that may not be what you want if you are developing experimentally.
[07:18] <cnus8n> hi
[07:19] <james_w> hi cnus8n
[07:19] <cnus8n> I am looking for setting up bazaar and webdav
[07:19] <cnus8n> is there any good tutorial for it?
[07:20] <cnus8n> i have installed the webdav plugin
[07:20] <james_w> I haven't seen one I'm afraid. Does google have anything useful?
[07:20] <cnus8n> I want some help in configuring apache
[07:20] <cnus8n> googling didnt help much
[07:20] <BrianB04> No, I'm thinking I'm going to do what some suggest, having the main repo, branch off that, add features, then merge.
[07:21] <james_w> BrianB04: that's the best workflow in my opinion.
[07:21] <cnus8n> i want to have a central shared repository - but must be able to push changes from outside
[07:24] <BrianB04> james_w: Yea, that sounds like the best idea. Granted, some stuff like licensing and versioning isn't going to be pulled out because that would be...kind of pointless to branch to put in a text file, but otherwise branch.
[07:41] <cnus8n> guys, I tried to setup webdav with bzr and I can do a checkout
[07:41] <cnus8n> but whenever i try to commit, i get an error
[07:42] <cnus8n> bzr: ERROR: File exists: 'https://foo.com/bzr/.bzr/repository/lock/ou6zj1ct2u.tmp'
[07:42] <cnus8n> can someone help
[07:44] <james_w> I've never used the plugin I'm afraid, and I'm not sure how up to date it is.
[07:45] <cnus8n> ok
[07:46] <james_w> ah, vila is the author, but he's not around at the moment.
[07:46] <james_w> it should be reasonably up to date though.
[07:47] <james_w> cnus8n: can you put the traceback you get in to a pastebin please?
[07:47] <cnus8n> I get no traceback - this is the only error message i get
[07:47] <cnus8n> i just changed to foo.com
[07:48] <cnus8n> after i checkout, i make a change and then try bzr commit
[07:48] <james_w> run what you were doing with bzr -Derror and you will get a traceback.
[07:49] <cnus8n> ok
[07:49] <james_w> also the end of ~/.bzr.log will be useful.
[07:50] <cnus8n> http://pastebin.com/m1b527125
[07:52] <james_w> ok, you are getting a 405 from your browser when you access that url.
[07:52] <james_w> from your server sorry.
[07:52] <james_w> can you open it in your browser please?
[07:52] <cnus8n> you mean https://beta.bioask.com/bzr/  ??
[07:52] <cnus8n> yeah i can open it
[07:53] <james_w> no the one that is in the error message.
[07:53] <james_w> 405 is "Method not Allowed"
[07:53] <james_w> so I guess your dav configuration isn't correct yet.
[07:54] <james_w> ah, in fact it is doing a MOVE request to the URL in the error, so the browser wont help here.
[07:55] <james_w> sorry a MKCOL request.
[08:24] <BrianB04> So, are there any good web frontends to bazaar branches?
[08:26] <james_w> loggerhead and bazaar-webserve
[08:26] <james_w> some people prefer the former, but it requires turbogears. The latter is plain python, and can serve an individual branch without apache etc.
[08:27] <BrianB04> Can bazaar-webserve serve multiple branches?
[08:27] <james_w> yes, using mod_python or cgi I think.
[08:28] <james_w> cgi is easy.
[08:30] <BrianB04> Or, I could just use Launchpad...which I'm not sure how often they update.
[08:31] <james_w> they pull once an hour when mirroring I belive.
[08:33] <BrianB04> Can't you use Launchpad to host bazaar branches?
[08:33] <mwhudson> if your branch is hosted on launchpad, the codebrowse view is live
[08:34] <BrianB04> Where can I find info on hosting it at Launchpad?
[08:34] <mwhudson> https://help.launchpad.net/CreatingAHostedBranch
[08:38] <BrianB04> Now, if I can figure out how to unregister a branch that hasn't mirrored yet...
[08:44] <grimboy> Hey, I'm having some trouble installing the trac bzr plugin (from https://code.launchpad.net/~jelmer/trac-bzr/aaron ). The exact error is "TracError: Unsupported version control system "bzr". Check that the Python bindings for "bzr" are correctly installed.". I have tracbzr.* = enabled under [components]  in trac.ini. I can import tracbzr and bzrlib in from the python prompt. My path and pythonpath are set up to be identical in the shell and the fcgi script.
[08:52] <hsn_> grimboy: what version of bzr you have?
[08:53] <grimboy> 0.90
[08:53] <hsn_> it worked for me with 0.18
[08:53] <BrianB04> This is odd, I go to push to /trunk, it says it exists, I use --use-existing-dir and it tells me it doesn't exist.
[08:53] <grimboy> Ah, hmm.
[09:02] <mwhudson> BrianB04: strange
[09:03] <mwhudson> BrianB04: though, hm
[09:03] <mwhudson> BrianB04: it's probably trying to push to a mirrored branch that's confusing it
[09:03] <mwhudson> BrianB04: if it hasn't mirrored yet, you should be able to delete it
[09:39] <BrianB04> Okay, so I finally got one to take, and now it's saying it's not a branch.
[09:42] <BrianB04> I did the bzr init, added, committed then I bzr pushed, now it's saying it's not a branch.
[09:47] <BrianB04> It didn't load the files odd.
[09:50] <BrianB04> All it has is a .bzr directory
[10:00] <james_w> a bz push sftp:// will only put a .bzr on the server.
[10:01] <BrianB04> So that's okay?
[10:01] <james_w> if you do bzr log sftp://... does it show you the whole log?
[10:02] <BrianB04> Yes
[10:02] <james_w> then that's ok
[10:04] <BrianB04> But, when I pull using this address: http://bazaar.launchpad.net/~bbommarito/rbnews/trunk it tells me it's not a trunk, and launchpad is saying it can't import it because it's not a branch.
[10:05] <BrianB04> Or rather it says: Launchpad could not mirror this branch 30 minutes ago. The error was: Not a branch: sftp://bazaar.launchpad.net/~bbommarito/rbnews/trunk
[10:07] <james_w> there's a strange error from the http:// url currently.
[10:09] <BrianB04> Hrmmm, the branch/branch-name is empty.
[10:10] <BrianB04> Oh, so there is an issue with the http connections right now on launchpad?
[10:12] <james_w> it looks that way, try opening the http:// url you pasted in your browser.
[10:13] <james_w> there is a #launchpad if you want to try and sort this out, they will have a better idea than me.
[10:13] <james_w> I think it's on freenode though.
[10:19] <lifeless> moin
[10:20] <BrianB04> Yet, the one I have on my webhost works just fine.
[10:21] <lifeless> james_w: this channel is on freenode :)
[10:21] <james_w> lifeless: oh yeah :)
[10:21] <james_w> morning.
[10:21] <BrianB04> Yea, I was just gonna say.
[10:22] <lifeless> so there is no branch ~bbommarito/rbnews/trunk
[10:22] <lifeless> on the supermirror
[10:23] <lifeless> BrianB04: ~bbommarito/rbnews/trunk exists, but has not been pushed completely
[10:23] <lifeless> BrianB04: you, or the owner, needs to push with bzr to the bzr+ssh, or sftp url.
[10:23] <lifeless> then it will show up on http
[10:23] <BrianB04> Oh, is that what's happening? I wonder what stopped it from pushing properly. Can that branch be trashed, or can I just go right over it?
[10:24] <lifeless> just push again
[10:24] <lifeless> note the error:
[10:24] <lifeless> https://code.launchpad.net/~bbommarito/rbnews/trunk
[10:24] <lifeless> 51 minutes ago
[10:24] <lifeless> ifi this is when you pushed first, there is a race condition that you may have encountered
[10:25] <lifeless> and if thats the case i don't think we have the 'try now' trigger in place - but it will sort it self out automatically
[10:26] <BrianB04> Okay, pushing right now.
[10:31] <yml> Hello
[10:32] <lifeless> hi
[10:32] <yml> I am trying to publish some change from a remote host to launchpad.net with bzr. The problem is that on that host I do not have access to /home/me so I had to put my ssh key directly on www/.ssh. Unfortunatly when I try to push I get the following error message:here it is the message : http://dpaste.com/18451/ bzr is looking at the wrong place to find the key do you know if there is a way to explicitely specify the path?
[10:33] <lifeless> bzr itself doesn't look for the key
[10:33] <lifeless> openssh does
[10:34] <yml> could you be a bit more accurate, I am not sure to understand the problem?
[10:35] <lifeless> bzr uses 'ssh' to connect to launchpad
[10:35] <yml> ok I understand this
[10:36] <lifeless> the ssh key is accessed by ssh
[10:36] <lifeless> its not something bzr has any control over
[10:37] <BrianB04> Yea...I pushed it again, still not wanting to actually pull.
[10:37] <BrianB04> Still giving me the error, but bzr said branch created...so...
[10:37] <lifeless> ok thats an improvement
[10:37] <yml> lifeless: so I guess I need to find quick how to on ssh. do you have any suggestion?
[10:37] <lifeless> google?
[10:38] <lifeless> one thing you could try
[10:38] <lifeless> is to set HOME to a path you do control
[10:38] <yml> ok :-)
[10:38] <lifeless> HOME=somepath bzr ...
[10:38] <lifeless> BrianB04: ok if it said branch created, I think you should push one more time
[10:38] <yml> ok I am going to try this
[10:39] <lifeless> BrianB04: which will trigger a retry.
[10:39] <BrianB04> Oddly enough, pulling via sftp is working.
[10:39] <lifeless> thats normal
[10:39] <lifeless> if you have write access to the branch you go to master copy
[10:41] <BrianB04> Okay, it looks like it's going to wait an hour to grab it, so we will see if it can mirror it in an hour...because pushing again simply says 'nothing to do'
[10:41] <BrianB04> Or No new revisions to push
[10:44] <lifeless> BrianB04: little big huh ?
[10:44] <lifeless> BrianB04: its probably cloning the public copy now
[10:47] <BrianB04> Big?
[10:47] <lifeless> sorrry, I mis-parsed your statement
[10:48] <BrianB04> Yea, it's showing it couldn't clone it like 15 minutes ago.
[10:48] <BrianB04> I'm guessing the http doesn't work until it's cloned.
[10:49] <lifeless> thats right
[10:50] <matkor> Hmmm What is meaning of word 'triaged' in status triaged ? TIA
[10:51] <james_w> matkor: it means it's been looked at but not diagnosed yet.
[10:52] <abentley> Strictly, it means a severity has been picked, but it doesn't mean that the bug has been verified or examined otherwise.
[10:53] <lifeless> james_w: it does not imply lack of diagnosis
[10:53] <lifeless> morning abentley
[10:54] <yml> lifeless : after some investigation I have found out that the $HOME is pointing to the right place
[10:54] <abentley> lifeless: morning.
[10:55] <lifeless> yml: I was suggesting changing it to somewhere you can write to so you can use the ssh key
[10:55] <yml> I mean my key is directly located in this directory .ssh/id_rsa
[10:56] <yml> my key is already there the pb is that bzr /openssh are not looking in that directory but in /home/yml
[10:57] <lifeless> oh
[10:57] <lifeless> well it was a thought
[10:57] <lifeless> you could try using agent mode
[10:57] <lifeless> start ssh-agent on your machine
[10:57] <lifeless> then ssh -A themachineyouarepushingfrom
[10:57] <lifeless> (you need to do ssh-add on your machine too)
[10:58] <james_w> lifeless: wouldn't you use confirmed if you had diagnosed it?
[10:59] <BrianB04> Yep, there was a race condition on the push, and it will be remirrored in about 5 hours.
[11:00] <yml> lifeless : ok I am going to find a how to ssh  :)
[11:00] <BrianB04> There is a fix in the works, but it won't be out until 1.1.9
[11:04] <lifeless> james_w: you can't triage until you can decide impact within the community
[11:05] <lifeless> its unfortunate that the lp devs put it in a spectrum
[11:06] <james_w> I thought that the definition of triage (in a wider sense) was a quick best estimate before you had all the facts that you wanted to make the full decision.
[11:08] <lifeless> triage is about allocation of resources based on likely benefit
[11:12] <lifeless> dictionary.reference.com/browse/triage
[11:12] <lifeless> but in bug systems its a little misused
[11:20] <lifeless> triage in bug systems is focused around the importance to the project, not the probability of fixing the bug easily