=== Verterok [n=ggonzale@184-220-114-200.fibertel.com.ar] has joined #bzr [12:05] Hi y'all [12:09] beuno: ping === ollie_r [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr [12:25] Verterok, pong [12:26] beuno: Hi! [12:27] hey Verterok, how are you doing? [12:27] working a bit in bzr-eclipse & bzr-xmloutput :D , how are you? [12:30] Verterok, working on my php<>bzr integration :D [12:30] what are you working on with bzrxml? [12:31] I made some changes that modify a bit (actually extend) the generated xml :P [12:31] these are related to merges and affected files (bzr log -v) [12:32] Verterok, interesting, I'm basing the php integration on your plugin, dos it change the format of the zml at all? [12:32] *xml [12:33] I can pastebin a generated xml, but the change is how the revisions are handled [12:34] the current trunk handle all revisions as equals (i.e: don't know about merges) [12:34] Verterok, would you? that way I can start crying on all the changes I have to make :p [12:34] sure [12:35] 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] maybe this is not too big, basically I added two new tags: and [12:36] both are child elements of [12:37] Verterok, aren't the affected files already shown? [12:38] I don't remember :P [12:38] hahaha [12:38] ok ok, well, you already show the deleted/new/modified [12:38] as a child of [12:39] in my branch I added a tag, to group them [12:39] ah, well, that will probably just me my code cleaner [12:40] that's the only bit that's a bit... les the ideal :D [12:41] what will the merge tag show? [12:41] I think that the *other* change 'll take a bit more of work (sorry for that) === Janzert [n=Janzert@75-134-223-54.dhcp.trcy.mi.charter.com] has left #bzr [] [12:41] take a look: http://rafb.net/p/thAACb16.html [12:42] Verterok, I welcome any improvements, I really do :D [12:43] great to known, but the is a big change :P [12:43] it group the merge revisions logs [12:43] aaaaaaah [12:43] Verterok,I understand :D [12:43] I was actually doing that manully in the PHP code [12:44] ah, great then! I think your code could be clean up a bit :D [12:44] I'll probably shave off half the lines of code! yay! :D [12:44] so, I have your OK to push to trunk? ;) [12:45] as I imported I chedked if it was a subrevision, and if it was, associated it [12:45] Verterok, I'm pretty sure you don't need my OK, but I welcome it [12:46] I started to work in the same processing (at the java side), but then I changed bzr-xmloutput :D [12:47] heh, yes, it makes much more sense [12:47] I wasn't as confident to go in and change someone's else code [12:47] you are most than welcome to do it :D [12:47] I have been playing around with bzr code more lately, even got a few patches in :D [12:48] 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] great! congrats! [12:49] sure! [12:49] 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] beuno: I just pushed those changes. now at revno: 18 [12:50] (I'm typing horribly today) [12:50] great, LP just emailed me too :p [12:50] no problem, I type horribly every day :P [12:51] hahhah [12:52] do you have any other changes in mind? [12:54] no to the log command, but i need to take a look to annotate [12:54] I have some plans to implement a few more commands [12:57] 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] 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] Verterok, ah, that sounds intersting, and bzr status maybe? or is that implemented already? [12:58] it's already there :D [12:59] how efficient of you :p I'm going to need that in the near future [01:00] drop me a line if you need something for: status --xml [01:01] Verterok, will do, thanks! [01:02] 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 === beuno just thought of bzr missing being useful too [01:03] sounds great! maybe in the bazaar wiki? [01:03] Verterok, yeap, seems like the right place [01:03] I never used yet :P === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [01:04] 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] that 'ld be interesting [01:06] Verterok, http://bazaar-vcs.org/bzr-xmloutput [01:06] I;ve subscribed [01:06] that was fast! [01:06] and now, I have to leave for a few hours, but we'll be in touch :D === beuno waves at vert [01:07] seeya === J-Unit [n=jdong@sharkattack.media.mit.edu] has joined #bzr === J-Unit [n=jdong@sharkattack.media.mit.edu] has left #bzr ["L] === hacklberry_ [n=hacklber@ppp167-251-99.static.internode.on.net] has joined #bzr === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr === NamNguyen [n=NamNguye@cm246.delta196.maxonline.com.sg] has joined #bzr === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr === ollie [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr === nvictor [i=nvictor@68.34.94.49] has joined #bzr [05:42] hi guys :) [05:42] I just downloaded the windows version of bazaar [05:42] can you tell me how it works? [05:42] I'm new to version control :) === nvictor [i=nvictor@68.34.94.49] has left #bzr [] === sevrin [n=sevrin@ns1.clipsalportal.com] has joined #bzr === ne1uno [i=udenity@dialup-4.156.210.82.Dial1.Boston1.Level3.net] has joined #bzr [07:28] hi [07:28] in what encoding is NEWS? [07:29] it shows Lukas Lalinsky as garbage [08:17] Looks normal to me, and I'm in UTF-8... [09:03] Aren't those things usually gzipped ascii? === MishaS [i=MishaS@a91-154-120-151.elisa-laajakaista.fi] has joined #bzr === amduser [n=amduser@93-72.res.pomona.edu] has joined #bzr === NamNT_ [n=NamNguye@cm246.delta196.maxonline.com.sg] has joined #bzr === khayashi [n=khayashi@i60-41-30-98.s04.a013.ap.plala.or.jp] has joined #bzr === dato [n=adeodato@84.120.252.218.dyn.user.ono.com] has joined #bzr === matkor [n=matkor@ip83-230-19-175.e-zabrze.pl] has joined #bzr === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr [10:47] Hi ! How can make bzr setup.py install man files in /usr/share/man (FHS) instead of /usr/man/ ? [10:48] not sure [10:48] possibly some setup.py install --help info will help [10:50] mmm I am gonna check --install-data /usr/share ... [10:50] matkor: we did a mv ${D}/usr/man ${D}/usr/share/man in the post_inst part of the Gentoo package [10:50] I don't suppose you filed a bug ? ;) [10:52] Against who? [10:53] AfC: I see similar patch for PLD ;) === alefteris [n=alefteri@unaffiliated/alefteris] has joined #bzr [10:54] [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] there should be an option to set the mandir though shouldn't there? [10:56] james_w, Afc : --install-data /usr/share seems to work [10:57] matkor: neat [10:57] thanks mak [10:58] matkor sorry. === khayashi [n=khayashi@i60-41-30-98.s04.a013.ap.plala.or.jp] has left #bzr [] === fog [n=fog@debian/developer/fog] has joined #bzr === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr [11:36] AfC: against bzr [11:36] AfC: its our problem to make our setup.py do the right thing [11:36] or to document how to do it [11:46] lifeless: ok [11:47] matkor: do you want to file it, or shall I? === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr === asabil [n=asabil@ti0035a340-0802.bb.online.no] has joined #bzr === gander [n=gander@agander.plus.com] has joined #bzr === g0ph3r [n=g0ph3r@p57A0B90D.dip0.t-ipconnect.de] has joined #bzr === g0ph3r [n=g0ph3r@p57A0B90D.dip0.t-ipconnect.de] has joined #bzr === g0ph3r [n=g0ph3r@p57A0B90D.dip0.t-ipconnect.de] has joined #bzr [12:25] what i need for syntax highlighting in olive? [12:25] in debian and ubuntu, python-gnome2-desktop [12:26] the library is called gtksourceview [12:26] hsn_: assuming you mean highlighting of the diffs [12:26] I have no idea if other highlighting is supported === duckx [n=Duck@tox.dyndns.org] has joined #bzr [12:29] i get olive errors like: ImportError: No module named dialog or bzrlib.errors.BzrError: must supply file_id or path === g0ph3r [n=g0ph3r@p57A0B90D.dip0.t-ipconnect.de] has joined #bzr [12:40] quicksilver: jelmer = jw ? [12:41] plop [12:41] Sorry [12:41] james_w: around ? [12:41] duckx: hi [12:41] duckx = Frederic Brin ;) [12:42] You are the guy behind bzr-builddeb right ? [12:42] ah, hi. Thanks for your fixes/ [12:42] No problem, I enjoy tweeking python [12:42] :) [12:43] Well, I tried the import-dsc command [12:43] And I was wondering one thing [12:43] Well, it is may be the normal behaviour [12:43] When you import a dsc, the orig.tar.gz is commited [12:43] But the debian dir is not .... [12:44] Is that the normal way to go ? === duckx thinks it is not ;) [12:44] By the way I was wondering one thing ... [12:45] What is the easiest way to get python have my bzr co of bzr-buildep be the python module loaded ? [12:45] Well, currently I hack the installed debian package, and port the tweeks back to my co tree [12:46] -> that sucks [12:46] mkdir -p ~/.bazaar/plugins/; ln -s /path/to/co ~/.bazaar/plugins/builddeb [12:46] k [12:46] Just fine for me ;) [12:46] as for the import let me investigate. [12:49] you're not using --snapshot correct? just import-dsc blah_0.1-1.dsc? [12:49] yes indeed [12:49] with the --to flag [12:50] bzr import-dsc --to gnucash gnucash*.dsc [12:52] I need to pull your fix first. Shows that I need some blackbox tests :) [12:52] ;) === chowmeined [n=will_@76.28.132.206] has joined #bzr === chowmeined [n=will_@76.28.132.206] has left #bzr ["Leaving"] [12:55] I've just imported one dsc and there are no uncommitted changes. [12:55] Hmm, damn [12:55] What did I do yesterday [12:55] Works fine for me :( [12:56] Ok lets try the merge upstream thing [12:56] ah, merge upstream doesn't commit I think. [12:57] Yeah, indead, that is the normal workflow [12:57] But I had a wired thing after doing the following workflow: [12:57] import-dsc [12:57] Then merge-upstream [12:58] bzr status gives me the following [12:59] http://www.pastey.net/73292 [01:00] that looks right for the aim of the command. [01:00] are you confused that it added all of debian/ again? [01:00] Yes ; [01:01] ok, so I had the same opinion as you at first, but other convinced me to do it this way. [01:01] Well, what I don't get [01:01] Is that I imported gnucash-2.2.1 over a 2.0.5 [01:01] I should see a bunch of file modified [01:02] nont only 2 [01:02] let me draw it for you. [01:02] Yeah thx [01:05] actually drawing it isn't very useful. [01:05] 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] My current issue is to get where the debian patch is located ... , [01:06] you have an upstream branch and a debian branch. [01:06] k [01:06] the upstream branch clearly just has upstream imports on it 0.1...0.2 etc. [01:06] Yeah That is what I see with bzr log [01:06] ------------------------------------------------------------ [01:06] revno: 2 [01:06] tags: upstream-2.2.1 [01:06] committer: Frederic Brin [01:06] branch nick: gnucash [01:06] timestamp: Sun 2007-09-02 13:00:17 +0200 [01:06] message: [01:06] import upstream from gnucash_2.2.1.orig.tar.gz [01:06] ------------------------------------------------------------ [01:06] revno: 1 [01:06] tags: upstream-2.0.5 [01:06] committer: Frederic Brin [01:06] branch nick: gnucash [01:06] timestamp: Sun 2007-09-02 12:57:51 +0200 [01:06] message: [01:07] import upstream from gnucash_2.0.5.orig.tar.gz [01:07] so your diff between the 2.0.5 and 2.2.1 lies on this branch. [01:07] yeah, so you can see the upstream changes with bzr diff -r1..2 [01:07] I get this [01:08] 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] and when you import a new upstream you need to merge the changes together. [01:08] the question is which way you perform this merge. [01:09] the way you are expecting I guess is that you do 'cd debian/; bzr merge ../upstream/' [01:09] 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] however the plugin does it the other way, so you are currently sat on the 'upstream' branch with the 'debian' changes merged in. === duckx is trying to understand the workflow ... [01:11] there is no real difference, you can see upstream changes by following one 'branch' and 'debian' changes by following the others. [01:11] you can also get the differences by diffing them. [01:12] if you fire up bzr viz (if you have it), you will see that all of the parent references are 'correct'. [01:12] Ok, let me investigate [01:13] the difficulty comes with bzr's distinction that the left parent is special, in this case that is the upstream branch. [01:13] 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] but as I say, topographically all is correct, and you have the desired parent links. [01:14] The left parent distinction is exactly why I was going with 'merge upstream in to debian' at first. [01:14] However siretart convinced me otherwise. [01:14] one moment... [01:14] k === duckx is going to install viz [01:16] it's useful to have, as it makes the topography clearer than log. [01:17] and gannotate is far more useful than plain annotate. [01:18] let me know when you're up to speed and I'll explain the rationale. [01:19] Well, I got viz installed [01:20] I see the same stuff that what I see in the log [01:21] Ok let's draw a simple example [01:21] if you click on the commits on the debian branch you should see two parents for each new debian version. [01:21] they aren't drawn on the graph, but they are shown in the info area. [01:22] Well, I don't get where the debian revision is ... [01:22] I muss have miss one stuff [01:22] have you committed? [01:22] Nop [01:22] I don't think viz shows pending merge revisions. [01:22] Ah [01:22] you can always uncommit after if you like. [01:22] But it should have been commited for the first dsc-import ? [01:22] Pending merges are figments of the working tree's imagination ;) [01:23] yeah, it was, but the merge makes it a pending merge again. [01:23] you are on the 'upstream' branch, which knows nothing about the debian revisions. [01:24] Ah [01:24] That is [01:24] The reason [01:24] Ok let me do a commit [01:27] Ok commited [01:28] bzr viz is a lot clearer right now [01:29] yep [01:30] james_w: well I need to read about dir-state tree first [01:30] I think it will make the things clearer for me [01:31] james_w: anyhow, thx for your time, and explaination [01:37] duckx: no problem. Give us a shout if you want anything else explaining. [01:37] and thanks for your fixes. === dato is now known as dato_ === dennda [n=dennda@ubuntu/member/dennda] has joined #bzr [03:40] hey there [03:41] 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.) === brasilino [n=not_me@201-24-49-52.bsace703.dsl.brasiltelecom.net.br] has joined #bzr [03:42] Well, the immediate error is that push is a writing op, and you can't write over http. [03:42] But push isn't going to solve a problem you're having with pull/merge. [03:43] The last line indicated it was a bug [03:43] That's why I ask [03:43] 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] You want the whole thing, i guess? [03:45] Well, that part isn't really a bug or anything broken; it's expected behavior, for what you tried. [03:45] What should I try instead? [03:45] Well, that would require going into the actual problem you're trying to solve :) [03:46] 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] Ah that just was the wrong adress to push to [03:47] Yah. To push you'd use a sftp://-ish (or bzr+ssh://-ish) URL. [03:47] But what's the problem you have with merge? [03:47] Yes, i tried that now. It gave me "No new revisions to push.". [03:48] 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] So I try merge: bzr: ERROR: Working tree has uncommitted changes. [03:49] Ok, let's look at 'em one at a time. First, the pull. Do you expect the branches to have not diverged? [03:49] (usually, that would mean that you've made commits to your branch that aren't in the upstream) [03:50] After I changed the file of my branch the last time, I immediately pushed it. (And that worked) [03:51] 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] http://pastebin.ca/678893 [03:52] 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] 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] I would expect pull to grab the below mentioned two missing revisions. [03:54] Pull would do that if you were still at rev 13. But you have local changes. [03:55] 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] 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] What would be the command to do that? [03:56] 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] (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] 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] Mmm. Two different questions. [03:58] 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] I just want to know what bzr wants me to commit. [03:58] Ok I will try that, just a sec === herzel97 [i=herzel@gateway/tor/x-63c3dc58b4f1d051] has joined #bzr [03:59] ah wll [03:59] of course [03:59] My programm changes the contents of the files in a directory that comes from Jasons trunk [03:59] And to test if my programm worked I ran it. So it changed these files. [04:00] 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] 'bzr revert' will get rid of uncommitted changes and bring your files back to what they were last time you committed. [04:01] What if I also changed the files _before_ I committed last time? [04:02] 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] ok so bzr revert. just a sec [04:03] ok, done [04:03] The sitution is something like: http://pastebin.ca/678904 [04:04] 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] Did you draw that right now? [04:04] "Draw" is probably an overstatement ;) [04:04] Well it's more beautiful than I would have been able to do it. [04:05] So I do have to always do this merge after I commit a change? [04:05] It looks something like a juniper bush being hit by lightning... [04:06] 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] 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] Right. There's no way "forward" from your 15 to his 15. [04:06] So, now do the 'merge', and let's see what it manages to make happen. [04:07] As I said: I already merged [04:07] If I want to do it again it says: bzr: ERROR: Working tree has uncommitted changes. [04:07] Right. Merge doesn't create the new 16; it just merges those 15's in your working tree. [04:07] So this seems to be quite the same situation as above [04:07] 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] Think you said you wanted his version of a few files, so we may want to adjust those before you commit. [04:08] Ok it's what I want [04:09] 'k. If it's all how you want it, 'commit' it, which will create the new rev 16 that we want. [04:09] Well at least I hope so ;) [04:10] 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] ok i did bzr commit and it opened (to my astonishment) vim, showing me modified files, added files, etc.. [04:10] Sounds like a great strategy for all deeds I want to do [04:11] "There's no way I could have made that commit! I was busy robbing a bank at that time!" [04:12] Ok, so what do I do with vim? === fullermd blinks. [04:12] it created bzr_log.HOrCoV [04:12] Put in the log message and all, just like you do on any other commit. [04:12] and opened it in vim [04:13] I don't understand this [04:14] 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] doesn't commit need a file specified that shall be committed? [04:15] Only if you want to commit only a particular file; normally it just checks through the tree for any modified files. [04:16] (and partial commits aren't supported on merges anyway) [04:17] so it is "bzr commit 'comment'" [04:18] james_w: Well, I need your advice for this [04:18] isn't it? [04:18] Well, "bzr commit -m 'comment'", if you want to specify the log message on the command line. [04:18] What about chmod 755 debian/rules while import-dsc ? [04:19] Without the -m, it spawns off $EDITOR for the log message. I hardly ever use -m myself. [04:20] duckx: perhaps that should be added, I'm not sure. [04:21] Well, currently When doing this [04:21] bzr import-dsc [04:21] Then bzr builddeb [04:21] It fails to build because debian/rules not 755 [04:21] fullermd: Ok. So I do push now? [04:22] Well, james_w patch is ready , just wait for your agreement to commit ;) [04:22] dennda: If you want to push up those combined changes now, yah. [04:22] yeah, it seems reasonable to me. Can you add a debian/changelog entry please. [04:23] and one for your last fix as well if you wouldn't mind. [04:23] Yes shure [04:23] sure, [04:24] thanks duckx [04:25] is there a test for it? [04:25] fullermd: /me feels uncomfortable. [04:25] How so? [04:25] I pushed now. Pull now tells me: No revisions to pull. [04:25] james_w: you mean unit test ? [04:25] duckx: yeah. [04:25] Nop [04:26] Don't think so [04:26] But I do need to pull in order to get Jasons changes, don't I? [04:26] Ups my mistake :) [04:26] Not at this point, no. Look back at http://pastebin.ca/678904 [04:26] 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] So there's nothing for pull to do. [04:27] ok let me see if you tell the truth ;) [04:27] james_w: by the way, what is the next version number 0.90.1 ? [04:27] wow! [04:27] Seems like. [04:29] 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] duckx: it will probably be 0.91 [04:29] james_w: ok === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr === dato_ wonders why the chmod is done stat.* instead of just 755 [04:30] fullermd: yes i see. and this will always happen if I change anything from my branch? [04:31] 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] ah [04:31] 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] I hope I can figure this out on my own next time. (Still seems like "Black wiZzaRdry" to me ;)) [04:32] But I think I understood [04:32] (roughly) [04:32] Thank you, fullermd! === BrianB04 [n=bbommari@c-69-136-128-216.hsd1.mi.comcast.net] has joined #bzr [04:33] Good morning everyone. [04:33] No problem :) [04:33] duckx: it would also be good to ensure that debian/rules exists. [04:33] k [04:33] hi BrianB04 [04:33] Doing it right now [04:34] thanks. [04:34] 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] james_w: isn't debian/rules a mandatory ? [04:34] BrianB04: bzr push [04:35] duckx: yes, I guess you don't have to add the check, but you never know. [04:35] Now, with push, you have to commit the first time before you push, correct? [04:35] BrianB04: yes that is correct. [04:35] ok james_w [04:37] 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] BrianB04: it will know. [04:39] if it doesn't then you can bzr pull --remember sftp://... or whatever and it will remember from then on. [04:40] 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] :) [04:42] Plus, with Bazaar running so nicely on Windows. [04:47] thanks duckx [04:56] Now, to get my launchpad account. === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr [05:03] 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. === ashish987654321 [n=root@202.141.140.34] has joined #bzr [05:11] :) === ashish987654321 [n=root@202.141.140.34] has left #bzr [] === dato [n=adeodato@debian/developer/adeodato] has joined #bzr === pete__c [n=pete@015-823-542.area5.spcsdns.net] has joined #bzr === AfC [n=andrew@office.syd.operationaldynamics.com] has left #bzr [] [05:46] Can I force merge with preserving uncommited changes ? [05:53] bzr merge --force? === ipkiss [i=ipkiss@nat/ecp/x-2e9ec040356e6945] has joined #bzr [06:00] james_w: Thanks ! === dato [n=adeodato@tarrio.org] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1177561336.dsl.bell.ca] has joined #bzr [06:40] jelmer: Could you please merge one more fix for olive-gtk from http://bazaar.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? TIA [06:42] matkor: Done, thanks! === asak [n=alexis@201-13-26-116.dsl.telesp.net.br] has joined #bzr [06:49]