[00:01] <amanica_> the one day of the month I try to push code to launchpad, its down :(
[00:19] <jpds> amanica_: New code rollout.
[00:19] <amanica_> jpds: yup, I know, but its going on longer than expected
[00:20] <amanica_> and I want to push this stuff before I go to bed
[00:20] <amanica_> not sure if I should wait..
[00:21] <elmo> amanica_: you may want to go to bed and do it tomorrow
[00:22] <amanica_> elmo: thanks
[00:23] <asabil> amanica_, or sleep 3600 && bzr push
[00:23] <amanica_> in a loop yeah :) cool idea
[00:33] <amanica_> goodnight then. thanks for the advice
[01:34] <poolie> jam, still around?
[01:34] <poolie> i'm just wondering if for bug 491763, failure to rename, we should give a better message
[01:34] <poolie> there have been several like this
[01:35]  * igc lunch
[01:37] <jam> poolie: I certainly think something better than a traceback is warranted. Especially since it doesn't give the 'from_' or 'to' filenames (in this case 'to' is probably the most interesting)
[01:38] <jam> actually, take that back, this is pre-delete, which should be where it moves files out of the wt
[01:38] <jam> so from is more interesting.
[01:38] <jam> anyway... the cases where we've run into this in the past are more Windows errors
[01:38] <jam> I haven't specifically seen it on Apple before
[01:41] <poolie> oh and i see it would be relevant to your ec2 failures too, perhaps
[01:41] <poolie> i was thinking that osutils.rename should wrap it, and then we should test_source ban use of os.rename
[01:43] <poolie> i've also wondered if we should have a weakref dict of all open files
[01:43] <poolie> so we can dump it in a crash
[01:49] <poolie> igc: alldocs updates failed because bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk/".
[01:50] <poolie> oh, duh, that would be because of lp outages
[01:50] <jam> poolie: so I don't think this failure is anything like what I'm seeing on EC2 or Windows. Because it is on Apple, you can't (afaik) lock a file such that you can't rename over the top of it.
[01:51] <jam> (my guess is that the dir is readonly.)
[01:51] <poolie> it's only similar to the others in that not seeing which filename caused the rename failure is annoying
[01:51] <jam> ah, sure
[01:51] <jam> that is definitely true
[01:57] <jam> poolie: I'm going to go away for a bit but it would be nice to chat about bug #40412 a little bit when we get a chance
[01:57] <jam> I think I have something that works
[01:57] <jam> but I have to consider how to handle some lca cases, and I'd like someone to sound the idea off of
[01:58] <jam> the code is here while LP is down: http://bzr.arbash-meinel.com/branches/bzr/lps/2.0-40412-show-base-weave/
[02:02] <poolie> ok
[02:02] <poolie> i'll be here at least the next 4 hours
[02:02] <poolie> modulo lunch
[02:16] <jam> poolie: I'm back sooner than I expected :)
[02:17] <jam> so the brief summary
[02:17] <jam> I'm trying to drop a .BASE file on disk
[02:17] <jam> based on the merge plan
[02:17] <jam> so entries that are "new-a" are omitted, but "killed-a" are considered to be part of BASE, etc.
[02:18] <jam> The current issue is essentially whether we want base = UNION(bases) or base = INTERSECTION(bases)
[02:23] <marcos> hello all, question: when i try to branch docky, it shows this error: bzr: ERROR: Invalid url supplied to transport: "lp:docky": OOPS-1434EC412.  any ideas?
[02:24] <marcos> huh?
[02:28] <RAOF> marcos: I'd guess that's fallout from launchpad's current unworkingness.
[02:28] <jam> marcos: lp is currently undergoing maintenance. That may not be the problem, but it is likely to be
[02:28] <marcos> okay, fair enough. wasn't sure but I suspected that
[02:29] <jam> poolie: ping me when you are around
[02:29] <marcos> RAOF: jam: thanks
[02:29] <lifeless> marcos: you can't use lp: atm
[02:52] <igc> lp is not a drug. I can live without it. really. Just keep telling myself that and ...
[02:58] <fullermd> It's not really a drug unless all the cool kids are doing it.
[03:22] <poolie> hi jam
[03:23] <poolie> igc, i know, you don't missi it till you're gone
[03:23] <poolie> marcos: see http://identi.ca/launchpadstatus
[03:23] <igc> poolie: just did - last update was 2 hours ago
[03:24] <poolie> well, and see #launchpad-code for more details i guess
[03:27] <poolie> jam, that plan makes sense to me
[03:28] <poolie> i would say probably you want the union of bases
[03:28] <jam> poolie: so I originally also thought union, but I'm wondering about the consequences
[03:28] <jam> namely, consider the "criss-cross merge swapped resolution" case
[03:28] <poolie> i think we need some kind of warning that this file isn't guaranteed to mean anything :)
[03:28] <jam> where both sides add a line
[03:28] <jam> then both sides merge the other
[03:29] <jam> and change the order of the result
[03:29] <jam> (so XY => XaY => XabY, XY => XbY => XbaY)
[03:29] <jam> if you take the union
[03:29] <jam> you get
[03:29] <jam> XbabY
[03:29] <jam> if you take intersection you get
[03:29] <jam> XaY
[03:29] <jam> if you do diff 3 with the two tips,
[03:30] <jam> union gives you XaY
[03:30] <jam> intersection gives you XbabY
[03:30] <jam> poolie: does that make sense? Or do i need to explain further?
[03:30] <poolie> yes, i think i know the case
[03:31] <jam> the issue is if BASE has it, then it looks like it should be removed in target
[03:31] <jam> if BASE doesn't then it looks to be added
[03:31] <jam> And it seems that having the target add lines is "safer" than having it delete lines
[03:32] <poolie> but you wouldn't want to add both
[03:32] <poolie> ah, probably true
[03:32] <poolie> so in this case we have the two sides being
[03:32] <poolie> XabY and XbaY?
[03:35] <jam> poolie: right
[03:35] <jam> and I don't have a great way to say "add just one"
[03:35] <jam> merge --weave implicitly picks one
[03:35] <jam> merge --lca conflicts
[03:35] <jam> on both
[03:36] <poolie> you could almost add another option, or maybe a debug option, to control this
[03:36] <poolie> and just let them try it
[03:36] <poolie> istm it's going to depend a bit on just what operations they do
[03:37] <poolie> whether they're doing a three-way diff against base, or a two-way diff, or just looking at the basis regions within the conflict markers
[03:39] <jam> right
[03:39] <jam> this is only for a .base to use in a 3-way app
[03:40] <jam> well... primarily for that
[03:41] <poolie> so i'd probably just pick one, document it, and let them try it
[03:51]  * poolie thinks aloud: do we still want some bzr branches statically hosted on escudero?
[03:51] <poolie> like a mirror of trunk from launchpad
[03:51]  * lifeless doesn't care
[04:03] <jam> it certainly seems like launchpad has been down for a lot longer than the 90 minutes claimed in the status update
[04:04] <jam> given that amanica was commenting on it 4 hours ago...
[04:05] <mwhudson> jam: yes
[04:26] <meoblast001> oh no
[04:26] <meoblast001> i'm drawing blanks, how do you set what branch version to use in init?
[04:28] <lifeless> meoblast001: version? do you mean format?
[04:28] <meoblast001> ah, yes
[04:28] <meoblast001> thanks
[05:02] <poolie> launchpad should be ok again now
[05:09] <_diablo> poolie: it's working for me
[05:18] <igc> bbiab
[06:12] <igc> enjoy your break lifeless
[06:23] <poolie> vila: hi?
[07:19] <vila> poolie: hey !
[07:19] <vila> hi all
[07:20] <poolie> hi there
[07:25] <poolie> spiv, what's the invocation of pqm-submit to make it work directly from launchpad?
[07:28] <igc1> hi vila
[07:30] <vila> poolie: can we try to chat a bit before you EOD if only for patch pilot sync ?
[07:30] <poolie> yes, sure
[07:30] <poolie> here or on the phone?
[07:31] <vila> let's try phone ! # ending with 8840 ?
[07:31] <poolie> yes, but 1m first
[07:31] <poolie> ok, now?
[07:32] <vila> yup
[07:46] <igc> night all - have a good weekend
[07:47] <igc> poolie: fyi, I've reviewed and approved Marius's log patch to fix that bug for MySQL.
[08:02] <poolie> thanks igc
[08:02] <poolie> have a good weekend too
[08:07] <spiv> poolie: --ignore-local, you need to pass the public location and submit loctaion on the cmd line, and you need to have set pqm_email (IIRC) in your locations.conf -- it's looked up on the submit location
[08:07] <poolie> i failed
[08:07] <spiv> poolie: so I hvae [http://bazaar.launchpad.net/*/~bzr/] there IIRC
[08:10] <poolie> vila, https://bugs.edge.launchpad.net/launchpad-code/+bug/492145
[08:14] <bialix> hi
[09:26] <_Andrew> Is there a way to remove a revision that's waiting to be merged and then pull that revision from another branch again?
[09:26] <_Andrew> because bzr merge is crashing for me
[09:27] <_Andrew> ..and I think if I pull this revision again it will work
[09:28] <gioele> what is the revision spec alias for "the point where I branched off the parent branch"?
[09:28] <gioele> so that I can do "bzr diff --old when-i-branched:"
[09:30] <Peng> gioele: ancestor:, I think?
[09:32]  * wgrant uses -rancestor:../trunk
[09:36]  * AfC uses
[09:36] <AfC> $ bzr gdiff -r ancestor:../mainline
[09:36] <AfC> [or,
[09:36] <AfC> $ bzr gdiff -r ancestor:/home/andrew/src/java-gnome/mainline
[09:36] <AfC> if I'm somewhere else; for reasons I don't quite understand, Bazaar doesn't interpret ~ so
[09:37] <AfC> $ bzr gdiff -r ancestor:~/src/java-gnome/mainline
[09:37] <AfC> doesn't work]
[09:37] <AfC> gioele: note no `--old` in all that
[09:38] <AfC> Hm
[10:15] <gioele> thank you Peng, wgrant, AfC
[10:15] <gioele> bzr diff -r ancestor: is enough (I branched from mainline)
[10:16] <gioele> aliased to "bzr basediff"
[12:20] <marek> hi, can you help me with this case? i have a server with repo, and some desktops connetced to the same LAN for developers, they also have repos on their machines. One of them just branched first revision from server, and changed some files, then he commited locally and merged with server repo. now he wants to push from his machine to server and he sees a "diverged" problem, how can i deal with it?
[12:22] <Peng> marek: He did commit after merging, right?
[12:22] <Peng> marek: Or perhaps there's another new revision on the server, and he'll have to merge+commit again?
[12:23] <Peng> marek: Usually people keep a mirror of the upstream branch, and do their work in feature branches, merging the feature branch into the trunk and pushing that. Just FYI.
[12:23] <marek> ok so i will try merge and then commit and then push?
[12:25] <Peng> marek: You have to commit after merging . . .
[12:26] <marek> ok, that was it thx
[12:26] <marek> i just had to resolve conflicts
[12:26] <marek> and than push worked
[12:28] <marek> ok but stil lnot everything is ok
[12:28] <marek> so:
[12:28] <marek> on that machine with problems, there is revision 3, and i can see all files from server repo and from that developer
[12:28] <marek> i did push
[12:29] <marek> and than on server i did update, and i saw info about rev 3
[12:29] <marek> but on server i cannot see files added by that developer
[12:29] <marek> :(
[12:29] <marek> when i merged to my repo
[12:29] <marek> from server
[12:30] <marek> and than status i can see:
[12:30] <marek> pending merge tips
[12:30] <marek> and commit from that developer
[12:30] <bialix> marek: you should run `bzr update` on server after you push there
[12:30] <marek> i did
[12:30] <marek> "tree is up to date"
[12:31] <bialix> run `bzr log -l1` on server and on client
[12:31] <bialix> and compare output
[12:31] <marek> on my client, or on developers client?
[12:32] <marek> on mine i can see:
[12:32] <marek> revno 5
[12:32] <marek> and on server revno 3
[12:32] <bialix> on the client you did push
[12:34] <marek> on client: http://pastebin.com/m51448bcb
[12:34] <bialix> check the URL you and other dev used
[12:34] <bialix> specify explicit URL if you in doubts
[12:34] <marek> that one from server
[12:34] <marek> http://pastebin.com/m58d7979c
[12:35] <bialix> so they seems identical?
[12:35] <bialix> so what's the problem?
[12:36] <marek> dev has a folder on his machine
[12:36] <marek> that is not visible on server
[12:36] <bialix> check that dev actually added this folder with `bzr add`
[12:36] <bialix> you can run bzr log -v to see all changed files
[12:36] <bialix> for each revision
[12:37] <bialix> or better use qlog
[12:37] <bialix> `bzr st` also shows you unknown (not added yet) items
[12:37] <bialix> also, you may want to use `bzr commit --strict`
[12:38] <bialix> this commit refuse to work if there is unknown files in the tree
[12:40] <bialix> marek: are you unsing only command-line or some GUI client?
[12:40] <marek> cli
[12:40] <marek> ok i found something
[12:40] <marek> on logs i cannot see that files are added
[12:40] <marek> and st shows me status "unknown"
[12:40] <bialix> so they are not added
[12:40] <bialix> bingo!
[12:41] <marek> one more comit?
[12:41] <marek> no
[12:41] <bialix> bzr add && bzr commit
[12:41] <marek> hmm, whenever i add some files on local repo, do i have to bzr add?
[12:42] <bialix> yes
[12:42] <marek> ahh so that part i missed :)
[12:42] <bialix> marek, if I understand correctly you started using bzr just recently; you may try Bazaar Explorer GUI, it's very good and provides you useful hints about what's going on and what to do nextr
[12:43] <bialix> really
[12:43] <marek> i will,
[12:43] <marek> and it is first project with bazar
[12:44] <marek> but i have another problem
[12:44] <marek> diverged branches while pushing :(
[12:44] <bialix> or you can just read tutorials and user guide, of course ;-)
[12:44] <bialix> diverged branches is not problem
[12:44] <bialix> I teach you
[12:44] <bialix> it's very easy
[12:44] <bialix> do you read in Russian?
[12:44] <bialix> I have blog
[12:44] <marek> no
[12:44] <bialix> ok
[12:45] <bialix> nm
[12:45] <bialix> you should use branch on the server as authoritative one
[12:45] <marek> ok
[12:45] <bialix> for local work it's better to create shared repo (bzr init-repo)
[12:46] <bialix> then get the copy of server trunk branch (bzr branch server/trunk local/repo/trunk)
[12:46] <bialix> for each new feature you made new local branch from trunk mirror
[12:46] <bialix> bzr branch trunk new-feature
[12:46] <bialix> then cd new-feature
[12:46] <bialix> hack hack hack
[12:46] <bialix> bzr ci
[12:47] <bialix> ok, you ready to push your changes to trunk
[12:47] <bialix> you going to mirror of trunk
[12:47] <bialix> doing pull from server: bzr pull
[12:47] <bialix> no you merge your new-feature branch to this mirro:
[12:47] <bialix> bzr merge ../new-feature
[12:47] <bialix> check the result
[12:47] <bialix> resolve conflicts
[12:48] <bialix> commit the result
[12:48] <bialix> now you push to the server from this trunk mirror
[12:48] <bialix> bzr push
[12:48] <bialix> voila! no conflicts!
[12:49] <bialix> I made some typos
[12:49] <bialix> sorry
[12:49] <bialix> marek: is it makes sense for you?
[12:50] <marek> it is hard :)
[12:50] <marek> but it surely has
[12:51] <bialix> the main point: you need separate mirror of trunk
[12:51] <bialix> on each dev machine
[12:52] <marek> you just gave me a sugestion how it should look? or how can i deal with my current problem?
[12:53] <bialix> I've tried you explain how to work with bzr as DVCS
[12:53] <bialix> I'm not quite sure what is your current problem
[12:53] <bialix> there is no problem
[12:53] <bialix> maybe some misunderstanding
[12:56] <marek> problably, so you are talking about this? http://doc.bazaar-vcs.org/bzr.2.0/en/tutorials/centralized_workflow.html
[12:56] <bialix> no
[12:56] <bialix> centalized workflow uses checkouts instead of just branches
[12:57] <bialix> but you could use it, if you wish
[12:57] <bialix> I mean this: http://doc.bazaar-vcs.org/bzr.2.0/en/tutorials/tutorial.html
[12:58] <bialix> but it does not explain what I've just explained to you
[12:59] <bialix> marek: this one I suppose http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/distributed_intro.html
[12:59] <bialix> marek: or even better this: http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/organizing_branches.html
[13:01] <marek> ok i will use it
[13:06] <rubbs> marek: If you read the documentation and find something confusing, please submit a bug, and tag it with 'doc'
[13:07] <rubbs> marek: that way the bzr-doc team can try to improve it.
[13:07] <marek> ok
[13:07] <rubbs> thanks!
[13:18] <rubbs> I'm getting an error when I try to pull from bzr.dev.
[13:18] <rubbs> http://pastebin.com/f37871e00
[13:19] <rubbs> the basic error is : bzr: ERROR: exceptions.TypeError: Expected a plain str for value not: <type 'unicode'>
[13:19] <bialix> this very bad
[13:19] <bialix> file a bug
[13:19] <bialix> jam: ^
[13:19] <rubbs> Ok will do
[14:40] <sjamaan> How does bzr determine the 'default stacking branch'? Is that automatically the one you initially branched from?
[15:03] <jam> bialix, rubbs: It looks like a bug in bzr-search
[15:04] <jam> sjamaan: It is set in a config file by launchpad based on the 'development focus'
[15:04] <jam> when you push to launchpad, bzr reads that file and sets up a stacked branch
[15:04] <jam> you can set that sort of thing up locally as well
[15:04] <jam> otherwise if you do "bzr branch --stacked" then it is implicitly stacked on the source branch
[15:04] <bialix> рш офь!
[15:04] <bialix> hi jam!
[15:05] <jam> hi bialix
[15:14] <sjamaan> jam: thanks
[15:16] <rubbs> jam: thanks, I'll dissable that plugin. I submitted a bug already, should I re-target it?
[15:16] <jam> rubbs: yes
[15:18] <rubbs> jam: will do thanks
[15:25] <mgedmin> dear lazyweb, does anybody remember the shell one-liner to add bazaar PPA's GPG key to the apt keyring (in jaunty)?
[15:25] <mgedmin> found it: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECE2800BACF028B31EE3657CD702BF6B8C6C1EFD
[15:25] <mgedmin> thanks for the patience
[15:59]  * gour is happy to see igc here hoping his health is better
[16:06] <gour> two questions: is bzr-git in a better shape than bzr-hg (when there will be push) and when is emacs going to (finally) switch to bzr?
[16:15] <jelmer> gour: bzr-git doesn't support push, only dpush
[16:19] <gour> jelmer: i'm not (yet) familiar with dpush...but accordingto roadmap i see 'push' is planned...my use case is simple...don't want to dive into git's (over)complexities and would rather stay with simple & powerful dvcs-es liek bzr (& darcs)
[16:20] <jelmer> gour: Uhm, which roadmap is that? I'm the primary author of bzr-git and don't remember one..
[16:21] <gour> jelmer: http://bazaar-vcs.org/BzrForeignBranches/Git - it says push to git. is it dpush?
[16:22] <jelmer> ah
[16:22] <jelmer> that's the long term roadmap, won't happen soon
[16:22] <jelmer> use dpush in the meantime
[16:22] <jelmer> the problem with push is that we can't stow extra data anywhere in git
[16:23] <gour> huh...better not to speak too much about git ;)
[16:23] <gour> jelmer: you're pushing bzr-hg as well..
[16:24] <gour> how it plays with 1.4?
[16:25] <jelmer> bzr-hg trunk works with hg 1.4
[16:27] <gour> ohh, that's good. i wanted to do darcs <---> hg, but hg's fast-import are not really functional
[16:28] <jelmer> gour: Ah, heh
[16:29] <gour> what about emacs conversion? they're planning it for quite some time?
[16:31] <bialix> gour: last time kfogel said it happens in next 2 weeks
[16:31] <bialix> it will happens
[16:31] <gour> finally to end this saga :-)
[16:32] <bialix> jam: ping
[16:33] <jam> bialix: ?
[16:33] <bialix> if I want to get path in tests to compare
[16:34] <bialix> how can I make it canonical to avoid temp dir prefix?
[16:34] <bialix> just s.replace(osutils.getcwd(), '') is enough?
[16:34] <bialix> this is for TestCaseInTempDir
[16:35] <bialix> or maybe there is something more handy?
[16:35] <bialix> jam: I want to suppress temp dir prefix from the output of pinfo command in the tests
[16:35] <bialix> can you suggest something?
[16:36] <jam> pinfo?
[16:37] <jam> you could use path.endswith() or assertEndswith()
[16:37] <bialix> pinfo from scmproj
[16:37] <bialix> it's like usual bzr info
[16:37] <jam> I think your replace line would probably work, though there are potential problems with platforms, etc.
[16:37] <bialix> but for projects
[16:38] <bialix> what kind of problems?
[16:39] <bialix> I can try it on Linux, on Windows osutils.getcwd() returns the path without trailing slash, so I need to add it manually
[16:40] <jam> I believe there are some silly things that happen on Mac with /tmp
[16:40] <jam> something like getting remapped to /private/tmp depending on whether normpath was called or not.
[16:47] <jam> bialix: it also depends whether pinfo puts out the local path, or puts out a url
[16:47] <jam> if it does a url, then you have to worry about url escaping, etc.
[16:47] <bialix> it puts absolute path
[16:48] <bialix> no, sorry
[16:48] <bialix> it using
[16:48] <bialix> urlutils.unescape_for_display(t.base, 'utf-8')  where t is transport
[16:48] <bialix> but all this run for local objects
[16:48] <bialix> so if looks like absolute path
[16:49] <bialix> so it looks like absolute path
[19:12] <cr3> I'm attempting to upgrade a branch on launchpad to --rich-root-pack and I get: bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/15/d7/backup.bzr'
[19:24] <cr3> I'm trying to use hitchhiker and rmtree backup.bzr, but it seems to be taking a very long time
[19:38] <cr3> man, if I thought rmtree was long, the upgrade is even longer. however, everything seems to be running fine so far
[21:20] <distatica> When I create a project offline, and add a file, make a commit, and then push sftp://host/code/project (where project is a non-existent directory) the .bzr folder gets pushed fine, but the files are not there. I am trying to set this up for redmine though.. and it finds "The entry or revision was not found in the repository" how can I send the files too?
[21:21] <distatica> create the project and bzr init on the server, and then push to that folder?
[21:26] <amanica> distatica: it creates a treeless branch by default
[21:27] <amanica> distatica: the bzr-upload plugin could help you. also see: http://bazaar-vcs.org/BazaarUploadForWebDev
[21:30] <distatica> hmm.. I would want the full revision history though, wouldn't i? For redmine
[21:32] <distatica> I have to run unfortunately to a job, thanks amanica I will read more about this when I get back.
[21:33] <amanica> distatica: I've never used redmine
[21:43] <gmpff> Hi.
[22:18] <igc> amanica: your logging patch has been approved and sent to pqm. Many thanks!
[22:18] <amanica> igc: thank you!
[22:20] <amanica> igc: thinking about how the graghs work for log, made my head hurt. its the hardest I had to think in years. My brain is getting lazy :)
[22:20] <igc> amanica: :-)