=== AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === BasicOSX [n=BasicOSX@216-243-162-1.static.iphouse.net] has joined #bzr === herzel [i=herzel@gateway/tor/x-c1976f286381567c] has left #bzr [] === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === herzel [i=herzel@gateway/tor/x-b1ecb12d9a932322] has joined #bzr === edalytical [n=eddie@student5584.student.nau.edu] has joined #bzr [12:55] poolie_: ping === offray_ [n=offray@69.79.144.212] has joined #bzr [01:01] Hi all [01:03] I'm trying to use svn2bzr to convert a svn project to bazaar but I get two errors related with bzrlib: "ImportError: No module named bzrlib.branch" or "ImportError: No module named clone". I don't know how to deal with it. May be my version of bzrlib is not syncronized with svn2bzr, but I don't know which version is supposed to be. Any pointer to a solution? [01:06] offray_: I believe that the plugin called 'bzr-svn' is the solution recommended by the Bazaar hackers; you might try that [01:08] Is there any variant on commit that doesn't actually touch the working tree? [01:08] Er, revert. [01:08] lifeless, hi === BasicOSX [n=BasicOSX@216-243-162-1.static.iphouse.net] has joined #bzr [01:10] cory: Look at 'uncommit'. [01:11] AfC: Thanks. I will try, but it says that you can put bzr code in svn, but not convert from svn to bazaar. I will read mode [01:12] Odd_Bloke: I spoke poorly. For instance, the working tree might know that I have moved a => b. I want it to forget that so that I can, say, add b and remove a instead. [01:12] add b and remove a, that would be. Maybe I should stop talking. :P [01:13] I don't want to do anything with already committed revisions, like uncommit does. [01:13] cory: Why doesn't revert do what you want? === dewd_ [n=dewd@201009147182.user.veloxzone.com.br] has joined #bzr [01:13] umm... there is a svn-import wich seems to make the same that svn2bzr [01:13] Because revert will move the file back. [01:13] I happen to need it to not do that. [01:14] cory, do you mean revert --keep? [01:14] i mean, remove --keep [01:14] I think revert --keep is what I want. ;) === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [01:15] cory, you could file a bug asking for that === cory nods. Just wanted to make sure there wasn't something obvious I was missing. [01:16] Wouldn't rm/add do that? [01:16] Or even unexposed api that I could use. [01:16] Only if there's a bzr add --even-if-it-doesn't-exist [01:17] Huh? [01:17] Why would you want to add a file that didn't exist (and what would that even mean?)? [01:17] I want it to forget that I told it to move it, not to add it! [01:18] This is me fighting with perforce, really. [01:18] cory, so in this particular case [01:18] why not just do a reverse mv [01:18] OK, you're losing me... I thought you had the case "moved a to b", and wanted to change that to the case "rm'd a and added b". [01:18] poolie_: what time should I pop over ? [01:19] any time [01:19] ok [01:19] are you trying to call? [01:19] I'll head over shortly [01:19] i can't hear anything when i pick up [01:19] do you want to meet spivvo on the way? [01:19] I did try [01:20] it went to your voice mail both times [01:20] try ringing yourself perhaps. Is the spivster up ? [01:20] cory: there is a bzrlib api to add a file regardless of physical presence [01:21] cory: tree.add([paths] , [ids] , [kinds] ) [01:22] spiv: I'll be on the 10:30 from hornsby again [01:23] Oh, I have another issue...the smart server seems to like leaving locks around. :/ === igc [n=igc@ppp121-45-227-231.lns1.bne4.internode.on.net] has joined #bzr [01:25] morning all [01:27] cory, if you abort the operation, or even when it succeeds? [01:27] igc, hi [01:27] hi poolie_ [01:27] poolie_: From aborted operations, yes. I expected the server instance would clean up after itself after it loses its connection. [01:29] Running it through inetd...maybe it's terminated before it gets the chance. [01:31] bbiab [01:32] cory: any reason you chose not to run it as a daemon full time? [01:32] AfC: No special reason. [01:33] cory: (but I note that bzr+ssh := run a `bzr --serve` for one time use and seems to manage to last long enough to clean up after itself) === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === Demitar_ [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr === offray_ [n=offray@69.79.144.212] has left #bzr [] === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #bzr === mw is now known as mw|out === rml [n=Skippy@78.32.35.169] has joined #bzr [01:55] Doh, I'm getting sigpiped. [01:55] Mmm. Could be a diff. bzr+ssh probably gets sighup. [02:10] cory, there's a recent bug discussing how to do that better [02:46] New bug: #145027 in bzr "bad assertions in WorkingTree4._add" [Medium,Confirmed] https://launchpad.net/bugs/145027 === pete__c [n=pete@032-463-246.area7.spcsdns.net] has joined #bzr [02:52] As at which version did --trees become the default implied behaviour in `bzr init-repo` (ie, can I remove --trees from my instructions now?) [02:52] 0.15, I think [02:53] Anybody keeping up should be long past that, but there're probably still a notable percentage of people below it. [02:58] fullermd: oh, that's ok [02:58] fullermd: I actively encourage my users to be >= 0.90 [02:59] fullermd: I was just worried it was 0.18 or something, in which case I would have left the documentation alone [02:59] fullermd: thanks [02:59] I think I actually have a server with 0.14... [02:59] But that's 'cuz everything on it is outdated, and I'm just waiting to do it all in one swell foop, so not bothering to piecemeal. [03:00] What about --dirstate-tags ? Is it default as of 0.90? [03:00] 0.91, I think. [03:00] fullermd: shit [03:00] ok [03:05] How does one switch a repo between --trees and --no-trees? === Peng wanders off. [03:07] rm or touch still, I think. [03:07] .bzr/repository/no-working-trees [03:08] Or checkout / remove-tree? [03:08] repo / branch...never mind. === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [03:20] New bug: #145033 in bzr "need a command to switch a repository between trees and no-trees" [Medium,Triaged] https://launchpad.net/bugs/145033 [03:22] fullermd: a patch to reconfigure to do it would be good [03:23] Would be the reasonable place for it. [03:24] or maybe we should have gdb-like set/show commands === rml [n=Skippy@78.32.35.169] has joined #bzr [03:26] Wow, we're over half a million bugs in launchpad? ;) [03:28] 564043 isn't found... [03:30] fullermd: no, 145K [03:30] or perhaps I'm on crack [03:31] today's plan: review things (particularly from lifeless and poolie), then start on OSDC tutorial [03:31] knit repo formats tidyups will be first [03:35] lifeless: I'm aware. Hence the ;) for poolie's x-ref. === NamNguyen [n=namnt@203.162.163.50] has joined #bzr [03:44] igc: thanks [03:45] np [03:45] igc: I'm working on applying inventory deltas to the parent tree of a working tree === jelmer_ [i=jelmer@12.196.220.245] has joined #bzr === jelmer__ [i=jelmer@12.196.220.245] has joined #bzr === lifeless waits for jelmer________________________________________ === jelmer__ blames AT&T [04:03] sucky airport wireless === jelmer__ is now known as jelmer_ === edalytical_ [n=eddie@student5584.student.nau.edu] has joined #bzr === edalytical_ [n=eddie@student5584.student.nau.edu] has left #bzr [] [04:15] jelmer_: is there some historical reason why the viz window is titled "bzrk"? [04:16] schierbeck: yup, it used to be a standalone plugin called 'bzrk' [04:17] or 'bezerk' (if I got hte spelling right) [04:17] jelmer_: do you think it should be changed to something more descriptive? [04:17] like "branch history" [04:17] Agreed [04:19] schierbeck: yeah, that's probably a good idea [04:20] jelmer_: i'll make a branch for it [04:20] cool, thanks (-: [04:21] "branch history" is fine, right? [04:25] sounds good [04:25] or graphical log of URL [04:25] sorry, "Log of " [04:25] (because viz is a graphical log) === orospakr [n=orospakr@bas4-ottawa23-1088826643.dsl.bell.ca] has joined #bzr [04:34] lifeless: i'm not really fond of "log" [04:34] it struck me when i saw it in olive [04:34] "history" much better captures the purpose [04:35] perhaps it's just me [04:35] it usually is [04:41] I always find "unprintable" exceptions amusing, because "unprintable" was used in place of swear words in the Foundation series. [04:42] :) === igc food [05:07] schierbeck: on the other hand, 'bzr log' is the text command to get the same data [05:07] schierbeck: I don't have a strong opinion though; mainly showing the url would be nice. [05:10] lifeless: why not show the branch nick? isn't that more descriptive? [05:12] Why not just "bzr viz: $URL" [05:13] fullermd: i'd like it to be more human-readable [05:13] remember, it could be launched from nautilus [05:14] the user may not even know of the "viz" shorthand [05:15] schierbeck: The historical reason was that it was based on "gitk". [05:15] abentley: ok [05:15] but the users won't really care about that [05:17] i'm trying to find ways to streamline the viz, to make it less confusing to newcomers === herzel [i=herzel@gateway/tor/x-49a867d0d0d4e979] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [05:36] lol, looks like the git crew stole bzrk back, and made gitview. === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr [06:18] now reviewing poolie's patch re safe_revision_id, etc. [06:20] abentley: did you see my post about reconcile where a file parent is a ghost? [06:20] Yeah. [06:21] I've created a separate branch for a particular release of my project. However, I now have a bug-fix branch which I need to apply to both branches without its application to the release branch also merging the features that have been added since the release branch was branched from trunk. What's the best way to go about doing this? [06:21] I guess I have a preference for sticking to the known facts. [06:22] The ancestry data in your knits should be derivable from the texts of the revisions and the texts of the inventories. [06:22] So I guess one issue is if we remove the parent the ghost is later filled in and it turns out that the data wasn't wrong after all, then reconcile will be introducing problems rather than fixing them. [06:22] But really, I'd rather sleep on it. [06:22] s/the ghost/and the ghost/ [06:22] Fair enough. [06:22] What problems? [06:23] That's why I wanted to check you'd seen then mail, so you had plenty of time to think about it :) [06:23] Well, just that the data is now "wrong", whereas if we'd never run reconcile in that case it wouldn't be. [06:24] Odd_Bloke: DAGgy it back to the branch point. [06:25] fullermd: DAGgy? [06:26] That's the term the mtn guys use for it. Catchy. [06:26] The theory in extremis is that you make the bug fix revision a child of the revision that introduced the bug; that way any branch that has that bug, can directly merge the bug fix. [06:26] In less extreme cases like this, just making it a child of some rev both branches have in common (the branch point being the obvious choice). [06:29] fullermd: OK, thanks. :) [06:29] Odd_Bloke: http://www.venge.net/mtn-wiki/DaggyFixes [06:39] spiv: My point is having knit data with too few ancestors doesn't produce many harmful results, while having knit data with too many ancestors does. === ..[topic/#bzr:poolie] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d [07:09] Ooh. Purdy. [07:09] abentley: possibly gitview went via hg ? [07:09] yah for the 0.91 release! [07:10] abentley: it does produce harmful results - bzr log FILENAME dpeends on the index [07:10] AIUI [07:11] abentley: the harm in having ancestors that aren't validated, at the border to a ghost, is two fold- index, and text construction. Making a fulltext there addresses the text construction hole [07:11] The gitk man page says that gitview is derived from bzrk. Of course, it could be wrong. [07:11] oh cool [07:12] what version of gitk do you have ? [07:12] I was just looking at this page: http://www.kernel.org/pub/software/scm/git/docs/gitk.html [07:14] ah [07:14] Ubuntu would appear to be out of date, and networkmanager blows again === Kinnison [n=dsilvers@spoo.flarn.net] has joined #bzr [08:01] Oh, 0.91 is out! [08:03] Cool. === Peng wanders off. === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr [08:21] bbiab === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr === Slant_Laptop [n=scott@66-233-139-237.lew.clearwire-dns.net] has joined #bzr === AnMaster [n=AnMaster@unaffiliated/anmaster] has joined #bzr === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === AfC seems to remember showing lifeless the gitview sources in a deli in Railway Square one morning and you saying "ah ha", "they copied that from us", and "yes we have that its called bzr viz" === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr [09:19] Y'know, there are some people who don't pass around source code in delis :p [09:20] (granted, they're people who live sad, colorless, wasted little lives. But still.) [09:22] AfC: sounds familiar === matkor [n=matkor@85.14.91.175] has joined #bzr [09:23] (sounds to me like the perfect opportunity for some propaganda on the bzr-gtk page) === mvo [n=egon@p54A67B72.dip.t-dialin.net] has joined #bzr === Slant_Laptop [n=scott@70.110.37.247] has joined #bzr [09:31] Am I correct in believing that `bzr serve` doesn't background itself? === pbor [n=urk@host113-46-dynamic.58-82-r.retail.telecomitalia.it] has joined #bzr [09:32] I think you are... though I've not tried, so for what that's worth... [09:33] AfC: Just running it here doesn't background it... [09:33] [I mean, you run it on the command line and it sits there in foreground, implying I need to use the otherwise frowned upon --background option to start-stop-daemon (which, itself, I frown on, but I was being a good sys admin and being lazy) [09:33] Odd_Bloke: yeah [09:43] Well then. `bzr branch http://...` takes 20m36s minutes, bzr branch bzr://...` takes 1m46s. Guess I'll run the server daemon full time now === AfC never did figure out how to get the transparent http redirect to bzr server working === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr [09:57] Canonical staff: someone should put an expires header on http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.png ... its a bit ridiculous that you download it every page load [09:58] (of course, that's a stupid way to serve static files, but anyway) === poolie__ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr [10:00] AfC: yay moin [10:00] (If there _is_ a static file I can point at, I would be happy to) === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === AfC is really enjoying watching the Bazaar logo load again and again and again! [10:15] lifeless: wow, 'diff' seems slow with packs [10:16] http://rafb.net/p/EVQLD158.html [10:18] jelmer: there doesn't seem to be any bugreport of that push -> diverged branches bug, and it's hitting me atm [10:18] jelmer: are you aware of / working on it? [10:20] AfC: what's happening? [10:20] poolie_ do a [10:21] wget -S 'http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.png' [10:21] and note the lack of expires headers [10:22] (compare [10:22] wget -S 'http://www.operationaldynamics.com/images/logo/logo-130x167.jpg' [10:22] ) [10:22] poolie_: result is that each time I reload my blog as I'm authoring I wait a few seconds for the Bazaar logo image I've used to load. [10:23] ... that has knock on effect when aggregated on places like planet.* === Lo-lan-do suggests using HEAD rather than wget -S [10:23] (knock on load for you guys, that is) [10:23] Lo-lan-do: --spider would have worked too [10:24] Lo-lan-do: but HEAD is lwp and it does funny things sometimes [10:24] Whatever. The point is to see the headers [10:25] poolie_ a .htaccess would probably kludge-fix it if you don't have easy access to the virtual host config [10:25] poolie_ I can whip up the directives if they're not coming to mind easily === GaryvdM [n=chatzill@dsl-241-254-221.telkomadsl.co.za] has joined #bzr === Gacha [n=gacha@81.198.204.153] has joined #bzr [10:27] hi [10:27] can somebody explain me the difference of --trees and --no-trees [10:27] I'm reading the docs, but I dont get it :) [10:27] A branch doesn't have to have its files (a "checkout", if you will) present [10:28] Gacha: For instance, [10:28] in whitch case? [10:28] Gacha: http://research.operationaldynamics.com/bzr/java-gnome/mainline/ is a branch called 'mainline' in a repository in directory /bzr/java-gnome on that server, whereas [10:29] which has --trees [10:29] ... in other words, files are there [10:29] Gacha: in a case you never need those file because you're only serving a branch, like launchpad does [10:29] whereas [10:29] s/a/the/ [10:29] Gacha: http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/treeview/ is quite "emtpy" [*] but contains a branch [10:30] * we actually want to change things so that a "THERE IS A BRANCH HERE" message appears [10:30] Gacha: /bzr/java-gnome/hackers is a different repository, and was created with --no-trees [10:31] Gacha: when you're working locally, you almost always want files present, so --trees [10:31] (which is the default now, according to conversation earlier today) [10:31] acf, we should probably just put the image on a static host somewhere and point to that [10:32] so with --no-trees files are keept in the main repo but not in the branch [10:32] is anyone aware of a branch of ezbzr still around? Nathaniel apparently removed everything from his site, and bzr release didn't make its way into mainline bzr [10:33] Gacha: the _revisions_ are kept in the repository (Which may be in .bzr, it may be in ../.bzr, whatever) [10:33] Gacha: whether there is a checkout of the files in that branch is what --trees influences [10:33] Gacha: like I said, you generally want files, and its default, so don't worry about it :) [10:34] ok, thanks [10:37] igc, are you still around? [10:37] yep === rml [n=Skippy@78.32.35.169] has joined #bzr [10:39] igc, i just commented on https://bugs.edge.launchpad.net/bzr/+bug/137449/comments/8 [10:39] Launchpad bug 137449 in bzr "status performance regression compared to 0.17" [Critical,Triaged] [10:39] i think that's why status looks so slow [10:40] so, do you think this is the likely cause, [10:40] and if it is, do you think it'll be hard for me to change the order in which the test components are run? [10:40] I agree with your assessment ... === asabil [n=asabil@ti0035a340-0469.bb.online.no] has joined #bzr [10:40] and have been meaning to make that change === Slant_Laptop [n=scott@CPE-76-178-155-79.natnow.res.rr.com] has joined #bzr [10:41] How can I have a directory inside my repo that is a branch from another repo, and will updates will pull from it? [10:41] it's not a large change but it's not a 10 minute one [10:41] Slant_Laptop: just branch it, and then pull changes in [10:41] it should work in the obvious way [10:42] however, at the moment you can't branch a subdirectory of a branch, if that's what you're talking about [10:42] poolie_: a sad workaround right now is, when running by hand at least, to run usertest on one tool ... [10:42] then run it again on another [10:42] you don't get the nice cross comparison of course [10:44] right, i was going to at least try that and see what happens [10:44] poolie_: I'm happy to make the change later this week if you don't get time ... [10:45] right now, I need to get my osdc tutorial together as the submission date is Sep 30 === Slant_Laptop_ [n=scott@pool-70-110-37-247.sea.dsl-w.verizon.net] has joined #bzr [10:46] Grr, that was annoying. [10:46] poolie_: So, if I already have a directory, "a/" that I did a bzr init in. [10:46] poolie_: Inside it, do a bzr branch http://blah [10:47] poolie_: If I cd into "a/blah" from then on and do a bzr update, it will merge in the upstream updates? [10:47] And if I do a bzr push from "a/" it'll push everything under a/ including a/blah? [10:48] Slant_Laptop_: no, it will only push a, you need to push a/blah separately [10:48] but i think there is a plugin (multipush?, maybe in bzrtools?) that will automate it [10:49] if you can't find it, please just ask the list [10:49] multi-pull is part of bzrtools [10:49] not sure about multi-push though [10:50] There is a multi-pull, but I don't see a multi-push. === igc food [10:53] So, no real solution to the problem? Grr, I don't want to do this in SVN. :-\ [10:54] Slant_Laptop_: there's experimental (yet) nested tree support being worked on, 0.92 I believe is the target. For now, you can use merge-into plugin [10:54] (I'm using it myself) [10:54] Slant_Laptop_: it will let you embed a branch inside another [10:54] lapthrick: It doesn't seem to be in my 0.90 copy. Do you have a link? [10:54] Slant_Laptop_: also, I'm working with SVN myself (which is why I know it), and there are bugs right now that prevent it from actually working [10:55] Slant_Laptop_: bzr plugins page links to it [10:56] Slant_Laptop_: you will need extra-recent bzr-svn (r716 or newer from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/), but that has a problem of not being able to push into SVN (because there's some breakage which makes it think the branches have diverged) [10:57] Slant_Laptop_: you will also need https://bugs.launchpad.net/bzr-merge-into/+bug/144108 for merge-into to work === Slant_Laptop_ nods. [10:57] Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 -- no attribute 'base_is_other_ancestor'" [Undecided,New] [10:58] Slant_Laptop_: I hope jelmer will fix the push thing soonish, so that it'll work finally [10:59] Slant_Laptop_: other than that, it works very well, with the caveat that merging upstream changes that move files around (as opposed to just changing their contents) will trigger spurious conflicts, that's probably unfixable before the nested trees support lands in, rendering merge-into obsolete [11:00] Hmm, gotcha. [11:00] igc, yes, that seems to be the problem with status [11:00] so that's kind of nice === Slant_Laptop_ is now known as Slant_Laptop === allenap [i=allenap@nat/canonical/x-67d478ef5e2f3336] has joined #bzr [11:11] Oh, I forgot. 0.91 adds -c. Yay! [11:11] What -c? [11:12] bzr diff and other commands. [11:12] Oh, cool. [11:12] Although I prefer diff -u myself :-) [11:12] -c revision means changes introduced by that revision. [11:12] Oh, not *that* -c. [11:13] Ah. [11:16] Peng: h? How is that different from what diff normally does? === lapthrick checks to see if gutsy has 0.91 yet [11:17] lapthrick: Instead of having to do 'bzr diff -r 99..100', you can do 'bzr diff -c 100'. [11:17] ah [11:17] handy [11:17] Also useful when dealing with a huge revno from a bunch of merges. [11:17] I was annoyed by the -r99..100 thing [11:19] night all === Mez_ is now known as Mez === AnMaster [n=AnMaster@unaffiliated/anmaster] has joined #bzr === mvo [n=egon@p54A67B72.dip.t-dialin.net] has joined #bzr === gabe [n=gabriel@91.84.56.254] has joined #bzr [11:44] hi all === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr [11:52] Hi ! One can safely edit .bzrignore files ? I would like to remove some bad patterns from it ? TIA [11:52] matkor: Yes. [11:53] Thank you Peng ! [11:54] :D [12:01] jelmer: you have a new bug report awaiting [12:01] jelmer: I actually discovered that while trying to reproduce another bug I ran into in my test repo, where bzr missing shows extra local revisions, yet bzr push says nothing to push === asabil [n=asabil@62.70.2.252] has joined #bzr [12:03] jelmer: there's definitely something wrong going on with diverged branches logic, first is that "can't push, can't merge" bug, then is that "nothing to push" (which I ran into trying to create a minimal testcase for the push bug) [12:11] Hmmm From where I can download bzr-gtk 0.91.0 ? [12:13] matkor: I don't think there is bzr-gtk 0.91 [12:13] matkor: anyway, just grab it from the plugins page [12:14] oh wait, it is synced [12:14] matkor: https://launchpad.net/bzr-gtk/0.91/0.91.0/+download/bzr-gtk-0.91.0.tar.gz [12:15] lapthrick: Thanks ! === herzel [i=herzel@gateway/tor/x-4fdd64e038888fc7] has joined #bzr [12:23] lapthrick: do you have a ~ on gnome.org ? [12:23] pbor: unsure, I know I have an SVN account [12:23] no, that's unrelated [12:24] lapthrick: pushing there with bzr push sftp takes forever (I mean it's been running for three hours and it is not even 50% of 1/4) [12:24] I was wondering if it is normal or related to gnome.org [12:24] no idea [12:25] pbor: how big is the push? [12:25] if it's pushing afresh, then you want to use rspush instead [12:25] pushing with sftp to localhost took some minutes [12:25] lapthrick: the gedit repo, so pretty big === pbor tries rspush [12:26] does that accept --create-prefix ? [12:27] it is not mentioned in the help... [12:28] dunno [12:28] pbor: but it's a shitload faster, since it uses rsync [12:33] lapthrick: execept that I get a traceback :/ [12:34] bzr: ERROR: bzrlib.errors.ObjectNotLocked: is not locked [12:35] ugh? [12:35] pbor: no idea what it means, I never got it [12:35] bzr doesn't like me apparently [12:36] jelmer: I was able to pull command log out of .bash_history, it's now reported as https://bugs.launchpad.net/bzr-svn/+bug/145165 [12:36] Launchpad bug 145165 in bzr-svn "bzr missing reports extra revs, yet push says nothing to do" [Undecided,New] [12:37] pbor: well, look at it another way: we whack the bugs now so it's awesome later :) [12:38] pbor: also, I'd definitely report that one [12:38] lapthrick: yeah, I started reporting the bugs I am running into [12:39] speaking of which, before I report a bogus bug, is this request reasonable: [12:39] pbor: btw, you can just rsync the branch over, it will work just as well [12:40] pull, hack, [someone commits an unrelated change to svn] , merge, commit, push [12:40] now two revisions are pushed to svn [12:40] my hack [12:40] and the merge [12:41] could bzr be smart enough to avoid the 'merge' revision? [12:41] pbor: presumably your 'hack' included committing? [12:41] it's already in svn, that's where I pulled it from [12:41] mwh: sure [12:41] (sorry for omitting that) [12:41] i think the same would happen with pushing to a bzr repo then [12:42] yes, I do not think it is specific to svn [12:42] but it (IMHO) sucks a bit [12:43] i think a common pattern is "only merge to mainline" [12:43] it means that for instance I'll have all the commts to po files by translators twice in the history [12:43] eh, that probably doesn't make sense [12:43] well, if I do not merge into my tree it doesn't let me commit [12:43] but anyway, you seem to be asking for a situation where you have a revision in your branch [12:44] then after a push, that revision is _not_ in the target branch [12:44] that seems to violate a pretty important invariant... [12:44] mwh: I know, in fact I would be happy to avoid the merge if I could [12:45] mwh: what I am saying is that that revision is already in the 'upstream' branch [12:45] that's where I get it from [12:45] (because I am forced to) [12:45] but the result of the merge is a separate revision (what if there were conflicts?) === mwh wishes for a blackboard [12:46] heh [12:46] ok, but there weren't... I am asking if there is a workflow to avoid that: in fact (but I still have to try) I think I can do this: === jelmer_ [n=jelmer@m400f36d0.tmodns.net] has joined #bzr [12:47] keep two branches: one mirrors upstream [12:47] 'morning [12:47] pbor: besides, the merge results are only shown in the history of the branch that did the merge in the first place. When you commit, the upstream history will only have a revision that says "pbor: merged from upstream" [12:47] every time I want to commit I sync the mirror and then merge my hacking branch and then push [12:47] jelmer_: hiya, can you read jelmer's backlog? [12:47] pbor: right, i was going to suggest a different approach here... [12:47] jelmer_: I reported a couple of bugs [12:48] mwh: that should work but it's a bit of a PITA :-) [12:48] jelmer_: and I still have that diverged branches bug, except that I can't even do a merge to fix it [12:48] pbor says it doesn't happen for him in 0.4.3 tarball, I'm running r719 tho [12:49] pbor: well, in True Distributed Style (tm) you only should only merge to mainline and push when your branch is done (bug fixed, new feature working, etc) [12:49] pbor: actually, could you try if you get that bug with the latest rev of http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ ? [12:49] if, in effect, you're using subversion to share your changes then yeah, it's a bit of a pain [12:49] lapthrick: which bug? [12:50] oh, got it [12:50] pbor: bzr push reporting that branches have diverged [12:51] lapthrick: mmm... I'll try it later, right now I have no pending changes to commit and I'd prefer to avoid bogus test changed in the upstream gedit svn repo [12:52] lapthrick: I am already waiting to flamed since my commit touched all the files :) [12:52] pbor: okay, as long as you remember to do it :) [12:52] pbor: hehe, because of bzr-svn? [12:52] yeah [12:52] how so? [12:52] no idea... probably the properties [12:53] pbor: it's only viewcvs that reports all files as changed [12:53] pbor: if you use 'svn log', you'll see there are only a few files changed by that commit [12:53] jelmer_: yeah, but I don't think viewcvs is psychic so something must have happened in the repo [12:54] :) [12:54] pbor: Replying to your bugreport atm [12:54] jelmer_: thanks! [12:54] jelmer_: I don't see the DivergedBranches bug reported anywhere (not in 0.4 anyway). should I go and create it? [12:57] lapthrick, which bug do you mean exactly? [01:01] ok, I'm off again - will reply to the bugs later today === pbor goes to lunch too [01:08] jelmer_: uh-oh, yet more bugs [01:10] New bug: #145170 in bzr "traceback doing rspush (bzrlib.errors.ObjectNotLocked)" [Undecided,New] https://launchpad.net/bugs/145170 === NamNguyen [n=namnt@cm38.delta196.maxonline.com.sg] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === Solarion [n=solarion@cruftix.physics.uiowa.edu] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] === niemeyer [n=niemeyer@200.140.230.150] has joined #bzr [02:31] so do people actually practice DAGgy bugfixes? Does it work well? [02:32] ( http://www.venge.net/mtn-wiki/DaggyFixes ) [02:33] lapthrick: i think, in practice, "no" [02:33] people don't do that [02:34] because it's a bother, or because it doesn't work? [02:34] because it's a bother [02:35] just my impression of course, both the bzr using projects i follow closely (bazaar and launchpad) have a pretty centralized model in some ways [02:36] (i.e. a mainline that contains or will contain almost everything interesting) [02:36] the kernel folks may have a different view === nocturn [n=nocturn@ubuntu/member/nocturn] has joined #bzr [02:39] Hi all [02:40] What is the difference between bzr merge and bzr merge --pull? In what circumstances do you use --pull? === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr === herzel [i=herzel@gateway/tor/x-c63a44cec40ff208] has joined #bzr [02:48] nocturn: if the thing you're merging actually supersedes the current branch (ie has only got things that you don't have) then you can pull them in on top instead of the revision graph doing a zig-zag [02:48] nocturn: it's a shortcut [02:48] nocturn: equivalent to bzr merge && bzr commit && bzr pull [02:48] nocturn: frankly I don't bother anymore, in no small part because our 'mainline' has almost always moved on since the contribution [02:49] lapthrick: It often seemed to me that `bzr pull` should just do that automatically if it isn't a "needs [manual] merge" [02:49] seems a bit silly to have the question arise [02:49] AfC: somewhat, yeah === asabil [n=asabil@62.70.2.252] has joined #bzr [02:53] Hello. I have a problem and i'm kinda confused now. Maybe i'm missing something or so. I cannot push my repository to remote server. [02:53] This is what bzr says: [02:53]