[00:31] <mwhudson> Peng_: are you here?
[00:34] <mwhudson> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
[00:34] <mwhudson> will that not go away until we upgrade the server?
[00:35] <lifeless> mwhudson: bug 354036
[00:35] <ubottu> Launchpad bug 354036 in bzr/1.13 "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [High,Confirmed] https://launchpad.net/bugs/354036
[00:36] <mwhudson> lifeless: oh right
[00:36] <spiv> Or, possibly, https://bugs.edge.launchpad.net/bzr/+bug/365615 ?
[00:36] <ubottu> Launchpad bug 365615 in bzr "Random 'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository" [Undecided,New]
[00:37] <mwhudson> spiv: no, not that one, for sure
[00:40] <spiv> mwhudson: upgrading the server won't fix affected branches.  When http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090422071133.GE10211%40steerpike.home.puzzling.org%3E lands upgrading the server will cause 1.13 smart clients to push unbroken stacked branches, but that won't help e.g. SFTP or <= 1.12.
[00:41] <mwhudson> spiv: right, i read the bug report now
[00:42] <spiv> mwhudson: once 1.14 is out, or the server-side fix is landed and cherry-picked to LP, (so we can hope that most new branches will be ok rather than broken) we should apply Robert's fix script to all the stacked branches on Launchpad.
[00:43] <lifeless> spiv: welcome to the connected
[00:43] <spiv> lifeless: :)
[00:44] <lifeless> spiv: I have a need
[00:44] <lifeless> spiv: I want a way to say 'dammit this medium is > X'
[00:45] <lifeless> spiv: and/or to fix the 3 insert stream round trips
[00:45] <mwhudson> spiv: ok
[00:45] <mwhudson> spiv: please tell someone when your fix lands :)
[00:46] <mwhudson> spiv: hang on, 1.14 isn't out yet?
[00:47] <spiv> mwhudson: still at rc2
[00:47] <mwhudson> spiv: when will it be out?
[00:48] <mwhudson> spiv: and how many changes are pending for lp:bzr/1.14 ?
[00:48] <spiv> lifeless: yeah, that would be good to have!
[00:48] <spiv> mwhudson: none that I know of, BasicOSX would know more but he just quit IRC...
[00:49] <lifeless> mwhudson: basicosx knows
[00:49] <mwhudson> oh hooray
[01:06] <spiv> lifeless: I can't reproduce your SSH auth problem with 1.14
[01:07] <lifeless> spiv: you don't see an explicit username passed to ssh?
[01:07] <spiv> Nope.
[01:07] <lifeless> thats extremely odd
[01:07] <lifeless> I'm presuming you have a host that you need such a config entry on for it to work
[01:07] <spiv> Right.
[01:07] <spiv> (Several :)
[01:08] <spiv> Wild guess: does your ~/.bazaar/authentication.conf accidentally have entries for that host?
[01:10] <mwhudson> fairly terrible, but interesting script for playing with loggerhead memory consumption: http://pastebin.ubuntu.com/156842/
[01:10] <lifeless> spiv: no such file
[01:12] <Dejan> ok guys, thanks for help
[01:12] <Dejan> lifeless especially
[01:12] <Dejan> \o/
[01:12] <lifeless> Dejan: anytime
[01:13] <spiv> lifeless: well, I'm out of wild guesses.
[01:14] <spiv> lifeless: I'd look at the code, but I'm pretty sure you've already done that...
[01:14] <lifeless> spiv: I'm hoping vila will
[01:14]  * spiv nods
[01:14] <lifeless> spiv: I just deleted the relevant lines from my local bzr and got on with $primary goal
[01:15] <spiv> lifeless: oh, I see, that patch in your mail is a patch that you'd like reversed?
[01:16] <lifeless> spiv: that would be one way to get it going
[01:16] <lifeless> I don't want to under vila's work though, so I'm leaving it open to him to decide how to reconcile the different needs and goals he has
[01:16]  * spiv nods
[01:17] <lifeless> s/under/undo/
[01:18] <spiv> Is there a bug tag for brisbane-core bugs?
[01:19]  * spiv blinks
[01:19] <spiv> There's now "official bug tags"
[01:28] <spiv> I just set all the tags listed on http://bazaar-vcs.org/BugGuidelines as official on LP, except for those that don't seem to be used.
[01:38] <lifeless> spiv: talk to me about error mapping
[01:39] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/message.py", line 355, in _translate_error
[01:39] <lifeless>     raise errors.ErrorFromSmartServer(error_tuple)
[01:39] <lifeless> ErrorFromSmartServer: Error received from smart server: ('FileExists', 'dir')
[01:39] <lifeless> how do I make that raise that actual error
[01:40] <lifeless> is it safe to just extend translate-message?
[01:40] <spiv> lifeless: in remote.py?  Yeah.
[01:40] <lifeless> smart/message.py
[01:41] <spiv> lifeless: hmm
[01:42] <spiv> lifeless: that exception should be ok to do in message.py
[01:42] <lifeless> how can I tell which are and are not
[01:42] <spiv> lifeless: many exceptions need to be translated by remote.py, because they need context (e.g. a Branch object) that message.py doesn't have
[01:43] <spiv> lifeless: although
[01:43] <lifeless> nearly all exceptions (I'd like to make it all) only stringify their args
[01:43] <spiv> lifeless: remote.py already translates FileExists!
[01:43] <lifeless> spiv: the vfs perhaps; I'm calling in from bzrdir.py
[01:44] <spiv> lifeless: (also, remote.py translates some errors that message.py could do, the evolution is incomplete...)
[01:44] <lifeless> I vant to vinish zis damn branch
[01:44] <spiv> lifeless: so shifting the FileExists translation from _translate_error in remote.py to _translate_error in message.py should do what you need.
[01:45] <lifeless> spiv: for now I've just added to message.py
[01:45] <spiv> lifeless: or even duplicating if you like
[01:45] <lifeless> because I don't want to destabilise stuff I'm not working on
[02:24] <mwhudson_> uh
[02:25] <mwhudson_> why would list(branch.iter_merge_sorted_revisions()) be [] for a patently non-empty branch?
[02:27] <mwhudson_> ah because historycache is buggy
[02:34] <magcius> When trying to push to Launchpad, I get this error:
[02:34] <magcius> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ejstpierre/%2Bjunk/its2ass/.bzr/branch/lock): Transport operation not possible: http does not supp
[02:36] <spiv> magcius: you need to run "bzr lp-login jstpierre" (or whatever your username is)
[02:36] <magcius> spiv, bah, okay.
[02:36] <spiv> magcius: (assuming you're using a lp:FOO url?)
[02:42] <magcius> spiv, yeah, thanks, that solved it.
[03:14] <Peng_> mwhudson_: I'm semi-here.
[03:21] <lifeless> spiv: getting there
[03:21] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/tests/bzrdir_implementations/test_bzrdir.py", line 1234, in test_format_initialize_on_transport_ex_stacked_on
[03:21] <lifeless>     repo_format_name=repo_name, stacked_on='../trunk', stack_on_pwd=t.base)
[03:22] <lifeless> ErrorFromSmartServer: Error received from smart server: ('error', "jail break: 'bzr://127.0.0.1:54060/extra/trunk/'")
[03:28] <Peng_> mwhudson_: Thanks for merging my branches. :)
[03:29] <spiv> lifeless: cool
[03:30] <mwhudson_> Peng_: np, thanks for the branches :)
[03:30] <mwhudson_> Peng_: feel free to carry on unifiying things onto the LoggerheadConfig object :)
[03:31] <garyvdm> How can one do graph.iter_ancestry and stop a revision, and be sure that all decedents of that revision have been returned, without the graph having to load the ancestors of the stop revision?
[03:32] <garyvdm> s/stop a rev/stop at a rev...
[03:35] <garyvdm> I want to load the parent_map for a ancestors of list of heads to the lca of those heads.
[03:41] <lifeless> garyvdm: probably you need to modify graph so that you can call lca(heads) and capture the parents
[03:41] <lifeless> garyvdm: but we memoise parents in various ways, so mmm, no quick answer sorry.
[03:42] <garyvdm> lifeless: thanks - I'll look at that.
[03:52] <mwhudson_> hm
[04:00] <garyvdm> lifeless: I fingered out a way: http://pastebin.com/d584a90fb
=== mwhudson_ is now known as mwhudson
[05:19] <lifeless> spiv: all implemented, same round trip count :P
[05:19] <lifeless> now to find out why
[05:29] <lifeless> spiv: ping
[05:29] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/transport/__init__.py", line 1361, in _split_url
[05:29] <lifeless>     return urlutils.parse_url(url)
[05:29] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/urlutils.py", line 728, in parse_url
[05:29] <lifeless>     raise errors.InvalidURL('Host empty in: %s' % url)
[05:29] <lifeless> InvalidURL: Invalid url supplied to transport: "Host empty in: file:///tmp/testbzr-hWEuIa.tmp/bzrlib.tests.blackbox.test_push.TestPush.test_push_smart_stacked_streaming_acceptance/work/local/"
[05:30] <spiv> lifeless: weird.
[05:31] <spiv> lifeless: I haven't seen that sort of traceback before.
[05:32] <lifeless> so
[05:32] <lifeless> I the host is empty
[05:32] <lifeless> but why does parse_url /care/
[05:33] <spiv> Yeah, I've no idea why it cares, or why you'd suddenly bump into that.
[05:33] <lifeless> I'm bumping into that because our push test stacks on a local path
[05:33] <lifeless> it stacks [over there] on ../local
[05:34]  * fullermd just got bit by that add-local-username-to-url thingy   :(
[05:34] <lifeless> fullermd: reply to the thread then please
[05:34] <lifeless> fullermd: or perhaps turn it into a bug
[05:34] <lifeless> and assign to vila
[05:34] <lifeless> :)
[05:34] <fullermd> Oh, man, is THAT what happens to you when you log off IRC?
[05:34]  * fullermd sets up a cron job...
[05:35] <lifeless> spiv: as soon as I wired up BzrDirFormat.initialize_ex to forward to RemoteBzrDirFormat.initialize_ex when there is a smart transport I triggered that
[05:35] <lifeless> spiv:
[05:35] <lifeless> AssertionError: Incorrect length: wanted 18, got 11 for [BzrDir.open, BzrDirFormat.initialize_ex, BzrDir.open, Repository.lock_write, Repository.insert_stream, Repository.insert_stream, BzrDir.create_branch, Branch.lock_write, Branch.set_last_revision_info, Branch.unlock, Branch.get_stacked_on_url]
[05:37] <spiv> lifeless: nice
[05:37] <lifeless> there is an issue
[05:37] <lifeless> we can't upgrade without doing a jailbreak
[05:37] <spiv> Really?  Why's that?
[05:38] <lifeless> consider:
[05:38] <lifeless> local is pack-0.92
[05:38] <lifeless> remote has a stacking policy pointing at $third-party
[05:39] <lifeless> our current rule says 'upgrade if the thing pointed at is stackable'
[05:39] <lifeless> but we can't examine it
[05:40] <lifeless> I could error with the policy details I guess
[05:40] <lifeless> but I'm going to punt and do the old hardcoded formats number in this case
[05:41] <spiv> *nod*
[05:42] <lifeless> (oh and the client can't examine for us, because the policy is found by the server)
[06:06] <lifeless> === modified file 'bzrlib/tests/blackbox/test_push.py'
[06:06] <lifeless> --- bzrlib/tests/blackbox/test_push.py  2009-04-22 02:36:23 +0000
[06:06] <lifeless> +++ bzrlib/tests/blackbox/test_push.py  2009-04-24 04:58:12 +0000
[06:06] <lifeless> @@ -201,7 +201,7 @@
[06:06] <lifeless>          # being too low. If rpc_count increases, more network roundtrips have
[06:06] <lifeless>          # become necessary for this use case. Please do not adjust this number
[06:06] <lifeless>          # upwards without agreement from bzr's network support maintainers.
[06:06] <lifeless> -        self.assertLength(18, self.hpss_calls)
[06:06] <lifeless> +        self.assertLength(11, self.hpss_calls)
[06:06] <lifeless>  
[06:06] <lifeless>      def test_push_smart_stacked_streaming_acceptance(self):
[06:06] <lifeless>          self.setup_smart_server_with_call_log()
[06:06] <lifeless> @@ -217,7 +217,7 @@
[06:06] <lifeless>          # being too low. If rpc_count increases, more network roundtrips have
[06:06] <lifeless>          # become necessary for this use case. Please do not adjust this number
[06:06] <lifeless>          # upwards without agreement from bzr's network support maintainers.
[06:06] <lifeless> -        self.assertLength(22, self.hpss_calls)
[06:06] <lifeless> +        self.assertLength(18, self.hpss_calls)
[06:06] <lifeless>          remote = Branch.open('public')
[06:06] <lifeless>          self.assertEndsWith(remote.get_stacked_on_url(), '/parent')
[06:06] <lifeless> spiv: ^ woo
[06:09] <spiv> Woo!
[06:10] <spiv> lifeless: nice work
[06:10] <lifeless> theres now a low hanging fruit of one more
[06:11] <lifeless> the possibly two
[06:11] <lifeless> the BzrDirFormat.initialize_ex, BzrDir.open, Repository.lock_write,
[06:11] <lifeless> second and third elements in that sequence
[06:11] <spiv> Yeah.
[06:11] <lifeless> I've sent it up for review
[06:11] <lifeless> schlepping it off to amazon in a second
[06:34] <lifeless> spiv: small number of failures, will clean up post review/monday
[06:34] <lifeless> spiv: I started early today, going to head into the city soon
=== jelmer is now known as Guest19644
=== Guest19644 is now known as jelmer
[09:01] <AnAnt> Hello, I got several packages hosted in the same branch: lp:sabily-artwork
[09:01] <AnAnt> is it possible to migrate each package to a separate branch, keeping along the history ?
[09:11] <thumper> I wonder if the split command does that
[09:13] <Peng_> That's what the split command is for. Whether it's safe to use is another question.
[09:16] <AnAnt> how ?
[09:16] <Peng_> AnAnt: bzr help split :D
[09:16] <Peng_> But you might have to upgrade the branches to an experimental format.
[09:17] <AnAnt> it says : bzr split tree
[09:17] <AnAnt> ok, I'll look at it
[09:17] <AnAnt> thanks
[09:25] <jelmer> thumper: hi
[09:26] <thumper> hi jelmer
[09:26] <jelmer> thumper: So, current bzr-git trunk should now work with bzr 1.14 proper
[09:26] <thumper> fantastic
[09:26] <thumper> how does that relate to dulwich?
[09:27] <thumper> does that matter?
[09:27] <thumper> or do we just take tip?
[09:27] <jelmer> You'll need the tip from dulwich as well
[09:27] <thumper> cool
[09:27] <thumper> I'll look to get it into LP ASAP
[09:33] <MvG> Hi! Is there some huma readable specification or documentation of the bzr smart protocol?
[09:34] <MvG> In particular, does the command allow removal of stuff like a bzr.backup directory from the remote file system?
[09:34] <MvG> Because I've upgraded a remote repo once, and trying to upgrade yet again via bzr fails as bzr.backup already exists, and removing that dir fails as ssh access is restricted to the bzr server.
[09:34] <Peng_> MvG: Sure, it supports VFS access, so you can do whatever you want.
[09:35] <MvG> VFS = virtual file system? Virtualized by whom?
[09:35] <Peng_> MvG: bzr
[09:35] <Peng_> MvG: It might be easier to use hitchhiker (sort of like a CLI FTP client, only for the bzr smart protocol) https://launchpad.net/hitchhiker
[09:36] <MvG> Sounds good. Will have a look.
[09:39] <MvG> Yes, that's exactly the tool I needed. Thanks ever so much!
[09:41] <thumper> there is a bug about the upgrade dirs
[09:41] <thumper> the upgrade command should be able to remove old backup dirs
[09:41] <MvG> Would make sense.
[09:41] <MvG> At least if it were sufficiently sure the upgrade went well and could be reverted if need be.
[09:41] <MvG> s/reverted/reversed/
[09:41] <mwhudson> thumper, jelmer: yay
[09:42] <thumper> hi mwhudson
[09:42] <thumper> mwhudson: do you want to do the honours?
[09:43] <thumper> mwhudson: if not, I'll get abentley or rockstar to
[09:43] <thumper> when they start their day
[09:44] <MvG> BTW: I've got two merge requests waiting in BB. So if anyone dev around here feels bored, I would appreciate votes on those.
[09:44] <MvG> I'll accept comments evenm from non-devs. :-)
[09:44] <mwhudson> thumper: not really at this time on a friday night
[09:44] <thumper> mwhudson: I guessed as much :)
[09:46] <Peng_> Whatwhat?
[09:47] <thumper> what?
[09:49]  * Peng_ babbles incoherently and falls asleep
[10:29] <poolie> the bzr wiki is having some trouble; IS is working on it
[10:32] <garyvdm> Hi - is it possible to ignore a file in a branch, with out committing a change to the branch? I.e. I want the ignore to only be for my copy of the branch.
[12:06] <g0ph3r> garyvdm: regarding your earlier question: AFAIK you can configure a global ignore list in your bzr settings. ("global" in this case means that you do configure it for all of _your_ branches, and that this is not visible to others)
[12:07] <g0ph3r> i don't know if this is the best way, though
=== jelmer is now known as Guest88668
[12:27] <ignas> hi
[12:27] <ignas> is there a way to find a commit in a shared repository?
[12:28] <ignas> bzr rebase messed up the history of my branch and I have a lost commit now somewhere
[12:28] <ignas> that I would like to recover
[12:32]  * SamB mumbles something about --heads
[12:33] <hmeland> ignas: I think "bzr heads" from bzrtools can help.
[12:33] <SamB> oh, is that what it was
[12:34]  * SamB knew there was a reason he was mumbling
[12:34] <ignas> i am not sure it will help me now... because I have performed a bunch of operations to recover the state on the branch
[12:35] <garyvdm> ignas: bzr heads --dead
[12:35] <garyvdm> find the revid of the head you want
[12:35] <SamB> as long as none of them involved garbage collection, you should be fine
[12:36] <garyvdm> bzr pull . -r revid:... --overwrite
[12:36] <SamB> (garbage collection of the repository, that is ;-)
[12:37] <garyvdm> SamB: the only way to do that with bzr is to create a new repository, branch, and delete the old one.
[12:37]  * SamB thought there was some command for it in bzr.dev
[12:37] <garyvdm> Oh
[12:38] <SamB> I could be wrong
[12:38] <mwhudson> i think there's a plugin somewhere or something
[12:39] <ignas> SubversionException: ('Unable to open an ra_local session to URL', 180001)
[12:39] <ignas> ouch
=== GaryvdM_ is now known as GaryvdM
[12:40] <SamB> ignas: what URL ?
[12:40] <ignas> don't know
[12:40] <SamB> ouch
[12:41] <ignas> the message is not giving any
[12:41]  * SamB wonders where jelmer is
[12:41] <SamB> you should report it as a bug on subvertpy, I think, that the URL isn't in the message anywhere
[12:43] <ignas> first - find the commit and make another release, sorry
[12:43] <ignas> will do while waiting for PPA to build a package ;)
[12:56] <ignas> Samb, hmeland, GaryvdM: thanks, that worked
[12:58] <SamB> ignas: what'd I do besides mumble misleading information and attempt to reassure you that your commit was probably still there?
[12:58] <ignas> SamB: on further review, probably not much ;)
[12:59] <ignas> but still, being a part of the community counts ;)
[13:02] <ignas> how do I only merge last 2 revisions from a branch?
[13:04] <GaryvdM> bzr merge -r ..-2
[13:04] <GaryvdM> or bzr merge -r -2..
[13:04] <GaryvdM> I can never remember which way
[13:04] <ignas> -2.. remove most of the changes from the checkout
[13:05] <ignas> and ..-2 still includes changes from earlier
[13:09] <GaryvdM> bzr merge -r -1..-2 ?
[13:10] <thumper> that'll do a reverse merge (I think)
[13:10] <thumper> it will apply the reverse of -2..-1
[13:13] <ignas> yeah, though if I want 2 last revisions it seems i have to do -3..-1
[13:57] <xiaohui> lifeless, is there a default ssh login name for using *bzr push bzr+ssh://bazzar.lauchpad.net/~MY_LAUNCHPADID/PROJECT/name*
[13:58] <xiaohui> When I use it , it shows me that Permission denied
[13:59] <james_w> your local username is the default
[14:00] <james_w> you can do MY_LAUNCHPADID@bazaar.launchpad.net
[14:00] <james_w> if you do "bzr lp-login MY_LAUNCHPADID" and the do "bzr push lp:~MY_LAUNCHPADID/PROJECT/name" it should work
[14:06] <xiaohui> I am behind the firewall
[14:06] <xiaohui> james_W, I have to use the URL for push and pull
[14:14] <xiaohui> james_w, It works now,thank you
=== jelmer is now known as Guest34677
[14:25] <phinze> hmm on bzr switch --force of a lightweight checkout to a completely different branch, i get "Conflict: can't delete features because it is not empty.  Not deleting."
[14:25] <phinze> any way i can tell bzr "yes yes just nuke this copy and make it like that branch"
[14:26] <phinze> rm -rf + bzr resolve is my best solution currently; just wondering if there's something i can do up front that's faster
[14:27] <phinze> and perhaps those here would know if maybe at the end of the day it would be faster just to kill the lw-checkout and make it again
[14:27] <phinze> rather than switching
[14:40] <ignas> don't know really, not using lw checkouts since I found out that a simple checkout is actually faster to do with my connection
=== Guest34677 is now known as jelmer
[14:41] <ignas> lw checkout saves bandwith (for me - only a bit), but takes longer
[14:41] <jml> lifeless: I've upgraded the tribunal branch anyway.
[14:42] <ignas> and if you are working on more than one branch - shared repository will take less time and bandwith than 2 lightweight checkouts
[14:42] <ignas> at least for me
[14:54] <xiaohui> when I push to lp it returned the *pipe broken ERROR*
[14:55] <xiaohui> and the connection is closed by remote host
[14:56] <xiaohui> what should I do then?
[15:12] <poolie> xiaohui: maybe your ssh key is not registered with launchpad
[15:15] <xiaohui> poolie, I have put my ssh public key to the launchpad
[15:16] <xiaohui> and the progress showed that has push 2/5
[15:18] <xiaohui> I use bzr push again, it directly come to 2/5 amd stoped
[15:35] <max_r> I have question about bzr
[15:35] <max_r> I dir bzr branch lp:aa, did bzr pull for some time
[15:36] <max_r> the commited local changes and it forces me to do bzr merge && bzr ci -m"merged" all the time
[15:36] <max_r> as far as I understand git allows simply use git pull even after local changes get commited, with forcing merge only on conflicts
[15:37] <max_r> could  I get same beheaviour for bzr?
[15:43] <james_w> max_r: not currently, no
[15:43] <rockstar> thumper, did you get your review?
[15:48] <max_r> james_w: is it planned? quite bad that simple operations takes twice as much steps
[15:49] <james_w> I don't know of anybody working on it
[15:50] <max_r> james_w: as I understand it is more UI problem than problem of repository or other low level stuff? I saw UI redesign planning for 2.0. Is it finalized yet?
[15:51] <james_w> UI redesign is planned for 3.0
[15:51] <james_w> I don't think adding an option to make it do that is something that requires a UI redesign though
[15:52] <max_r> and what is approximate eta for 3.0?
[15:52] <max_r> In bzr help pull I see:
[15:52] <max_r>   If branches have diverged, you can use 'bzr merge' to integrate the changes
[15:52] <max_r>   from one into the other.  Once one branch has merged, the other should
[15:52] <max_r>   be able to pull it again.
[15:52] <max_r> It seems rather strange
[15:52] <james_w> 3.0 in a 9 months or something
[15:52] <max_r> I merged branches, but I couldn't pull any more
[15:52] <james_w> I don't know if a timeline has been decided
[15:53] <james_w> after the merge you will be able to pull the other way
[15:54] <max_r> seen now "bzr merge --pull" what it does?
[15:54] <james_w> that doesn't do what you want
[15:54] <james_w> that will fast-forward where possible, which is another thing that "git pull" does that "bzr merge" doesn't
[15:55] <max_r> I need something like "bzr merge --commit-if-no-conflicts", right?
[15:55] <james_w> yep
[15:55] <max_r> could it be done as plugin?
[15:55] <james_w> yep
[15:55] <max_r> is relativly hard?
[15:55] <max_r> or easy?
[15:56] <james_w> shouldn't be too hard
[15:57] <max_r> is there any simple sample plugin to base on?
[15:57] <james_w> actually, it may not be that easy in a plugin
[15:58] <max_r> why? It looks easy as bash script, just running "bzr merge && bzr ci -m 'merged'" with some error checking on the first step to see if there was conflicts
[16:01] <james_w> because you don't want to open the objects more than once
[16:01] <james_w> and you don't want the tree to be modified between the merge and commit
[16:02] <james_w> that's probably the basic thing that is needed: http://paste.ubuntu.com/157278/
[16:02] <james_w> it needs tests and polish though
[16:03] <max_r> any chance it go into 1.15?
[16:04] <max_r> and what is more correct "pull --merge-if-needed" or "merge --commit-if-no-conflicts"?
[16:06] <james_w> that patch won't go in 1.15
[16:07] <james_w> a better version could if it passed review
[16:07] <james_w> and those two commands mean different things
[16:09] <max_r> james_w: could you please explain difference?
[16:10] <james_w> whether pull does something when the branches have diverged, or tells you to use merge is different to whether the a merge will commit if there are no conflicts
[16:11] <james_w> and the first option is already there, it's just spelt "merge --pull" instead of "pull --merge"
[16:12] <max_r> and how "pull --merge-if-needed" ("merge --pull" in bzr language) differs from "get all changes from that branch, and apply it locally" which as I understand is "merge --commit"
[16:13] <max_r> ?
[16:14] <james_w> pull means "make my branch the same as that one"
[16:14] <james_w> which doesn't work if you have diverged
[16:15] <james_w> merge means "merge my changes with theirs"
[16:15] <james_w> and when you do that you end up with something new, so you may want to check it before you commit, as the merge can't do everything
[16:15] <max_r> got it, i thought pull means "pull all changes from that branch"
[16:15] <james_w> nope
[16:16] <james_w> "pull" is different in git and bzr
[16:16] <max_r> which is quite confusing
[16:25] <MvG> I hope I don't start to annoy you yet, but I'm again trying to interest devs into reviewing my two open merge requests, related to reconfigure and bug 248932. Anyone willing to have a look? I'd like to get this off my head.
[16:25] <ubottu> Launchpad bug 248932 in bzr "reconfigure --standalone raises IncompatibleRepositories" [High,Confirmed] https://launchpad.net/bugs/248932
=== jkakar_ is now known as jkakar
[19:33] <AnAnt> which is better way to use bzr:
[19:34] <AnAnt> 1) bzr co <URL> , do some changes, bzr ci
[19:34] <AnAnt> or 2) bzr branch <URL> , changes, bzr ci, changes bzr ci , .. , bzr push  ?
[19:35] <james_w> AnAnt: I prefer 2, but they are equally valid
[20:21] <AnAnt> james_w: ok
[20:25] <AnAnt> I tried bzr split, but I don't think it works
[20:25] <AnAnt> I have 3 packages in the same bzr branch
[20:26] <AnAnt> I want to have separate branches for each package, yet I want to keep the bzr history of each package, is that possible ?
[20:26] <james_w> split would be the way to do it, but it may not do what you expect
[20:26] <james_w> it will keep the full history in each branch
[20:28] <AnAnt> how ?
[20:28] <AnAnt> I just done this: bzr split <packageone>
[20:28] <AnAnt> then cd <packageone>
[20:28] <AnAnt> bzr push file:///tmp/test
[20:28] <AnAnt> I got this: bzr: ERROR: Not a branch:
[20:31] <AnAnt> oh, I got an error actually when I do a bzr split:
[20:31] <AnAnt> bzr: ERROR: To use this feature you must upgrade your branch at file:///tmp/sabily-keyring/.
[20:33] <james_w> ah
[20:33] <james_w> not that helpful of a message
[20:33] <james_w> "bzr upgrade --default-rich-root" is probably what you want
[20:34] <AnAnt> k
[20:38] <AnAnt> ok, cool
[20:39] <AnAnt> btw, there's no --default-rich-root option
[20:39] <AnAnt> I used --rich-root-pack
[20:47] <BasicOSX> ja1: Bug 355238 really set to Milestone 1.14rc2?
[20:47] <ubottu> Launchpad bug 355238 in bzr "TypeError upgrading branch to gc-chk255-big" [Undecided,Fix released] https://launchpad.net/bugs/355238
[20:47] <ja1> BasicOSX: I'm pretty sure the bug listed there was fixed for the rc2
=== ja1 is now known as jam
[20:48] <BasicOSX> thanks for quick response, research further
[20:48] <jam> BasicOSX: rev 4250 on bzr.1.14
[20:48] <jam> 4250 Canonical.com Patch Queue Manager 2009-04-19 [merge]
[20:48] <jam>      (jam) Tweaks to the new --dev6-rich-root format support.
[20:48] <jam> 4251 Canonical.com Patch Queue Manager 2009-04-19 [merge]
[20:48] <jam>      (tanner) prepare-1.14rc2
[20:49] <jam> at least according to *my* branch of 1.14, my patch landed before rc2
[20:49] <AnAnt> hmmm, problem with splitting, is that I can't revert to older revisions !
[20:49]  * BasicOSX blinks 
[20:49] <BasicOSX> Who needs search when you have jam ! :-)
[20:49] <AnAnt> oh, I ccan
[20:50] <AnAnt> ok, thanks !
[20:51] <jam> well, as i just did the searches myself, I knew where to look
[21:51] <dereine> hi, i want to use bazaar together with a "checkout" on ftp, how can i do this