[00:20] <lifeless> jam: btw, is up or down 'towards parents'
[00:21] <jam> parents are up
[00:53] <jelmer> lifeless, pong
[00:53] <jelmer> AfC, I would very much like a bug report :-)
[00:56] <AfC> jelmer: It was a false alarm, turns out. I think their first revision is huge (it was an import of an existing project into VCS), and I was on poor link. I tried it again from my office and while it took a long time before network traffic started, eventually it got going and did a huge transfer.
[00:56] <AfC> jelmer: thanks for your response, though.
[00:56] <jelmer> AfC, ah, ok - no progress indication whatsoever, or just slow?
[00:57] <lifeless> jelmer: hi
[00:58] <jelmer> lifeless: hi!
[00:58] <lifeless> jam: merge_sorted would be more concise perhaps
[00:58] <AfC> classic case of Bazaar's less than useful progress indicator hurting more than it helps - it was camped out on the initial 0/260 for several minutes. And since no network I/O was going on either, it was disheartening.
[00:59] <AfC> (it's so cosmetic, but if youtube-dl can actually give you live activity stats, surely bzr could. Its one of the things that massively contributes to the subjective opinion that Bazaar is slow if you've used Git)
[00:59] <lifeless> AfC: was the spinner spinning?
[00:59] <jelmer> lifeless, what's up?
[00:59] <jelmer> AfC, right
[00:59] <AfC> (and yes, I know about how it's all one library call, and that library doesn't report back events, etc. {shrug} Whatever it is, it needs replacement.)
[00:59] <fullermd> Well, look at the bright side; if the progress indicator actually updated progress more, you'd have more chances to get annoyed at the step-numbering...
[01:00] <AfC> lifeless: checking
[01:00] <AfC> [and if you haven't tried youtube-dl, grab it and watch it go. It's *sweet* from a user feedback standpoint]
[01:00]  * fullermd rather likes mtn's progress output too.
[01:01] <fullermd> Both in its smoothness of update, and in that it *STAYS* there; after it's done, you can still see what it did.
[01:01] <lifeless> jelmer: are  you waiting on me for any reviews?
[01:02] <AfC> lifeless: can't reproduce right now. I'll try it again from that cafe later today.
[01:02] <lifeless> AfC: k
[01:03] <fullermd> AfC: Of course, you think THAT bad usage of a library is living long...   Mozilla *STILL* doesn't give you any freakin' stats on what/how much/how fast it's loading.  WTF?
[01:03] <AfC> lifeless: [just now there was 21 seconds of no progress bar at all, and no network activity, and then a monster transfer, and then the progress bar came up at 1/. When I was having the trouble 2 days ago it was stuck at 0/ with no network activity]
[01:07] <jelmer> lifeless, not that I'm aware of :-)
[01:08] <jelmer> lifeless, well, I'm waiting for two minor requests for bzr and one for pqm, but that's not waiting on you particularly
[01:09] <AfC> Is bzr-webserve still an active project, or did it get absorbed by loggerhead  | launchpad, or ...?
[01:10] <AfC> Sorry, my actual question is "I've long heard discussion of a simple and if-possible-more-or-less-built-in web interface for Bazaar; did anything come of that? Is bzr-webserve that?"
[01:11] <spiv> AfC: not yet
[01:11] <AfC> Either way, what should I be trying and who trying to help?
[01:11] <AfC> s/who/who should I be/
[01:11] <spiv> I think a cut-down loggerhead is likely to be the way to get there.
[01:12] <spiv> But I don't know of anyone working on it.
[01:13] <AfC> spiv: k, thanks
[01:13] <lifeless> spiv: I've updated bzr-email for server side deployments
[01:14] <lifeless> spiv: if there are docs for gnome or whatever you might like to give it a spin :)
[01:21] <spiv> lifeless: ah, neat.
[02:06] <ym1> I used bzr co to get a project from google code. I would like to work for some times locally using bzr.
[02:07] <ym1> However as soon as I try to do a bzr commit, bzr tries to commit on google code. what should I do to stop this ?
[02:10] <jelmer> ym1, use "bzr branch" rather than "bzr co"
[02:16] <ym1> jelmer: I have already done some modification there. Is it too late to save this branch
[02:18] <jelmer> ym1, "bzr unbind"
[02:18] <jelmer> will turn a "bzr co" into a "bzr branch"
[02:18] <ym1> jelmer: thank you
[02:19] <ym1> That is the command I was looking for
[02:20] <ym1> Before applying, does bzr bind is working in the context of bzr svn ?
[02:21] <ym1> If yes that means that I can work disconnected for some times that then apply my changes to the central repository.
[02:22] <ym1> jelmer: If this possible I am curious to know how the 10 "locals" commit is going to be represented in the central SVN repository.
[02:24] <jelmer> ym1, you'll have to push them back using "bzr push"
[02:47]  * spiv -> lunch
[05:39] <ToyKeeper> D'oh.  'bzr st' reports modified files, and 'bzr di modified_file' says nothing at all.
[05:40] <spiv> ToyKeeper: does "bzr st" report it with a "*"?
[05:40] <ToyKeeper> Nope.
[05:41] <spiv> Or any other flags?
[05:42] <ToyKeeper> The only odd thing is I made the branch via bzr-svn.
[05:43] <ToyKeeper> Let's see... bzr 1.10~rc1-1 from debian
[05:44] <spiv> That doesn't affect working trees AFAIK.
[05:44] <spiv> Can you pastebin the exact output of the bzr st and bzr diff?
[05:44] <ToyKeeper> Sure.
[05:45] <ToyKeeper> Ah, it's definitely because of bzr-svn.
[05:45] <ToyKeeper> When I disable it, everything works fine.
[05:46] <ToyKeeper> I'm guessing jelmer did something clever.
[05:46] <ToyKeeper> Like, intercepting diff and hiding the result if 'svn diff' says it's up to date.
[05:46] <spiv> That does sound like a bzr-svn bug, although a weird one.
[05:47] <spiv> But it's not an SVN working tree?
[05:47] <ToyKeeper> It's also a svn working tree.
[05:47] <spiv> You mean there's both .svn and .bzr stuff for that directory?
[05:47] <ToyKeeper> This project does stupid things, like call 'svn info' during its debian build process.
[05:47] <ToyKeeper> Yes, both .bzr and .svn dirs.
[05:48] <spiv> I can see how that would cause confusion -- the .svn directory might think the working copy is at a different revision to where the .bzr directory thinks it is at.
[05:48] <spiv> So inconsistent results are a fundamental issue there.
[05:49] <spiv> I guess bzr-svn could perhaps try to warn you if that's the case, although I'm not sure it's possible to do that cheaply with svn.
[05:50] <ToyKeeper> Yeah, I don't care if svn is confused by it.  I'd prefer to get rid of it entirely.
[05:51] <ToyKeeper> I'm thinking I'll probably skip bzr-svn on this one...  don't need history just to make a few small patches.  :)
[05:51] <spiv> If you don't care what svn thinks, then just get rid of the .svn directories :)
[05:52] <ToyKeeper> That breaks the build process.  :(
[05:52] <ToyKeeper> Oh, nice.  'bzr diff file' says nothing, but 'bzr diff' alone shows the changes.
[05:52] <ToyKeeper> Or, with bzr-svn removed, everything works.
[06:02] <ToyKeeper> woot, bzr-svn also breaks 'commit' in this case.
[06:12] <funkychicken818> i am running bzr on windows and i have two problems 1 when i open bzr i get unable to load bzr-svn extension - did you build it? 2 bzr cache is annoying and takes up to much memmory how do i stop it?
[06:14] <funkychicken818> any one?
[06:15] <ToyKeeper> I've never tried bzr on Windows, so I'm not much help.
[07:32] <rocking777> hello room
[07:33] <rocking777> i am using bzr for the first time ein my new project and facing lot of difficulties
[07:33] <rocking777> there is work going on 2-3 of my modules and one of the module is completeed. I want to push this module to staging server
[07:33] <rocking777> but it is not allowingg me to do so
[07:33] <rocking777> it is saying that there are uncommitted changes in my code
[07:35] <bob2> 'push' doesn't care about thta
[07:35] <bob2> what command are you running?
[07:41] <rocking777> bar push and then providing the repository address
[07:41] <rocking777> my bazaar checkout is a direct branch of SV
[07:41] <rocking777> SVN
[07:42] <rocking777> bzr push svn+ssh://my address
[07:46] <vila> hi all
[07:47] <vila> rocking777: 'push' cares only about revisions, so to avoid errors it checks about uncommitted changes
[07:48] <vila> You may want to look at shelve/unshelve to get to a point where you can commit and then push
[07:49] <rocking777> yes, but then those uncommitted changes are related to other modules
[07:49] <rocking777> so i dont want to commmit or push that coe
[07:49] <igc> hi vila
[07:49] <rocking777> i want to push only the code related to my module
[07:49] <vila> igc: HI !
[07:50] <vila> igc: was thinking about you at that precise second :-)
[07:50] <igc> vila: :-)
[07:51] <fullermd> Fine then, don't think about me   :(
[07:51] <Peng_> igc: Welcome back. :)
[07:51] <igc> thanks Peng_
[07:52] <igc> fullermd: we're always thinking of you  - take it for granted :-)
[07:52] <vila> fullermd: I was thinking about you when reading my IRC backlog :-)
[07:52]  * fullermd is mollified for the moment.
[07:54] <vila> People most often refer to the Muppet's Show for the Swedish Chef, but my favorite muppets were the two old mens and their remarks... :-)
[07:54] <vila> That was a random thought of course....
[08:08] <funkychicken818> bzr cache is annoying and takes up to much memmory how do i stop it?
[08:08] <jml> vila: Waldorf and Stadtler, I think.
[08:10] <vila> jml: Wow ! I didn't even know they had *names* :-)
[08:10]  * fullermd nods at jml.
[08:20] <luks> funkychicken818: depends on what do you mean by bzr cache
[08:28] <GPH-Laptop> jml, vila, fullermd: I'm pretty sure it was Statler (without the D)
[08:29] <funkychicken818> luks well i mean the tortise cache bzr cache
[08:29] <funkychicken818> Tortoise Bazaar
[08:30] <Peng_> GPH-Laptop appears to be correct.
[08:34] <GPH-Laptop> ;)
[08:36] <luks> funkychicken818: surry, I don't know then
[09:27] <funkychicken818> hey how do i not cache with bzr?
[09:33] <LarstiQ> funkychicken818: most of us are not windows users, I at least have only a vague hunch what that means. Is that the status cache to speed up icon overlay drawing?
[09:36] <funkychicken818> yes
[09:36] <funkychicken818> its very annoying its taking up tons of memory
[09:37] <funkychicken818> right now its at 500,000 K
[09:37] <funkychicken818> and i only have 2GB of memory
[09:37] <funkychicken818> LarstiQ: is the any way to stop it?
[13:14] <wild_oscar> hey there. could someone help me with the bazaar plugin for eclipse?
[13:14] <wild_oscar> I was following the steps here http://bazaar-vcs.org/BzrEclipse/Installation
[13:15] <wild_oscar> but I'm getting an error when configuring bazaar in the preferences: http://pastebin.com/d45c56522
[13:52] <vila> wild_oscar: what does 'bzr plugins' display ?
[13:52] <vila> wild_oscar: or said otherwise, do you have the xmloutput plugin installed ?
[14:07] <kebomix> Free Programming e-books With Direct Links & Request ebooks Here : http://request-ebooks.blogspot.com/
[14:12] <wild_oscar> back
[14:13] <wild_oscar> vila: well, it seems it was a problem with bzr's version
[14:13] <wild_oscar> I upgraded to 1.10 and it's working
[14:13] <vila> good
[14:14] <wild_oscar> thanks for the tip, though
[15:10] <nevans> so... let's say that you are writing a teeny tiny little library for a community that seems irrationally connected to github, and you want to make a git mirror so that they can send in patches that way
[15:10] <nevans> but you would rather be using bzr yourself
[15:11] <nevans> what are your options (besides just sucking it up and using git yourself, because that's what the crowd wants)
[15:36] <lifeless> nevans: use bzr fast-export to generate the git repo
[15:36] <lifeless> nevans: and insist on patches not branches being given to you :)
[15:40] <nevans> lifeless, sounds like a plan.  :)
[15:41] <nevans> I suppose there isn't a decent two way mirroring solution as of yet?
[15:55] <NfNitLoop> Hrmm.
[15:56] <NfNitLoop> SO I've got a bzr repo that I've been working on standalone.
[15:56] <NfNitLoop> and I would like to check it in to subversion.
[15:56] <NfNitLoop> I tried bzr svn-push $REPO/branches/newbranchname
[15:56] <NfNitLoop> is that correct?   (I got an assertion failed message.)
[15:57] <NfNitLoop> This is with 1.9 and the corresponding bzr-svn, so I guess I'll upgrade and try again.
[16:07] <luks> does anybody know if there is a way to get bzrlib call ui_factory.get_password() when using openssh?
[16:08] <NfNitLoop> Hmm, same error with bzr 1.10 and the new (.4.x) bzr-svn:
[16:09] <NfNitLoop> assert not self.push_metadata or self._new_revision_id is None or self._new_revision_id == revid
[16:09] <NfNitLoop> fails.  :/
[16:09] <khemicals> I set up bzr server to run via xinetd on Centos 5 via the EPEL package (version 1.3.1) and was getting bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: 'No handlers could be found for logger "bzr"\n'
[16:10] <khemicals> so I upgraded to 1.10 -- still getting that error and an additional set of "Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)" -- ideas?
[16:12] <NfNitLoop> khemicals: Hmm, I haven't actually ever run the bzr server before... sorry.
[16:13] <NfNitLoop> khemicals: Why are you using that instead of just HTTP and/or SSH?
[16:13] <NfNitLoop> (just curious)
[16:13] <khemicals> When over SSH I get similar error message
[16:13] <khemicals> haven't tried HTTP
[16:14] <lifeless> NfNitLoop: tat should have been right; I suggsest putting a question on bzr-svn in lp
[16:14] <lifeless> luks: no, openssh doesn't call the get_password callback
[16:15] <NfNitLoop> lifeless: actually, what I'm working on isn't a branch, it's completely new code.
[16:15] <NfNitLoop> I'm wondering if that's what's messing it up.
[16:15] <luks> lifeless: so if I call access a bzrlib transport from a GUI program and it needs password I'm screwed?
[16:16] <lifeless> luks: ssh-agent
[16:16] <lifeless> NfNitLoop: no, that should be fine.
[16:16] <lifeless> bbiab
[16:16] <NfNitLoop> and instead of trying to put it in $REPO/newproject, I'm trying to put it in $REPO/oldproject/branches/xyz which might confuse the branching scheme?
[16:16] <NfNitLoop> aah.
[16:16] <lifeless> NfNitLoop: ah, newproject may be better ;
[16:16] <lifeless> )
[16:16] <lifeless> -gone
[16:16] <luks> lifeless: well, not in *my* case, but how do I tell the user it's not going to work?
[16:17] <luks> hm, perhaps I should force bzrlib to use paramiko when running qbzr commands
[16:19] <jam> luks: you're pretty dependent on how ssh works
[16:20] <jam> It generally doesn't let you get around its password prompt, for security reasons.
[16:20] <luks> jam: I just don't want my programs to hang, that's all
[16:20] <jam> I thought there was a way to declare a password program.
[16:20] <jam> Since that works with Gnome, etc.
[16:20] <luks> jam: it sits and waits for the password on a terminal, with no notification to the GUI
[16:20] <jam> If you run something that requires ssh but doesn't have aterminal, it will pop up a gui password
[16:20] <luks> jam: I'd rather make it fail than do this
[16:21] <jam> luks: man ssh gives me this: http://paste.ubuntu.com/83568/
[16:22] <NfNitLoop> lifeless: aha, yes, pushing to $REPO/newproject worked.  Unfortunately that doesn't match our branching scheme here, hrrmm.
[16:22] <khemicals> luks: Why not just use ssh keys for auth instead of password auth?
[16:22] <jam> I also see something about SSH_TTY
[16:23] <luks> khemicals: because I don't have a way to tell the user of my application that asking for password is not going to work in this specific case
[16:23] <jam> You can also pass "-n" to the ssh process
[16:23] <luks> khemicals: I can't do it globally, because it works for some different ssh provider
[16:23] <jam> which causes it to redirect stdin to /dev/null
[16:23] <jam> khemicals: luks is trying to get qbzr to work nicely
[16:23] <jam> which is a gui app
[16:24] <jam> luks: I would recommend doing something with SSH_ASKPASS
[16:24] <jam> it seems like you could have a tiny qbzr command
[16:24] <luks> I'll try that
[16:24] <jam> well, probably not command
[16:24] <jam> it probably needs to be a full script, etc.
[16:24] <khemicals> Did you poke at how tortoiseCVS handles it?
[16:24] <jam> khemicals: I'm pretty sure TCVS requires you use the putty code
[16:25] <luks> "bzr qaskpass" should probably work
[16:25] <jam> not openssh
[16:25] <jam> luks: I just don't know if you can supply arguments, or if it has to be a single no-whitespace string.
[16:26] <jam> env vars aren't particularly great for allowing whitespace-in-path *and* allowing arguments
[16:26] <luks> hmm
[16:26] <luks> I need to find a way to trick it into thinking it doesn't have a terminal available
[16:27] <LeoNerd> pipe stdout through cat?
[16:28] <luks> nah
[16:28] <luks> it's smarter than that :)
[16:30] <fullermd> Presumably you'd have to use something like setsid() to throw away the process group holding you on the terminal.
[16:36] <jam> luks: it mentions needing to redirect stdin to /dev/null as a possibility
[16:36] <jam> you could also unset TTY
[16:36] <jam> and possibly SSH_TTY
[16:36] <jam> I don't know why that would be set
[16:36] <jam> (I would assume ssh itself sets that)
[16:36] <jam> or passing "-n" on the command line
[16:36] <jam> A bit hard to do through the bzr layers
[16:36] <jam> but you could hack it in and see if that fixes it
[16:36] <luks> jam: nope, neither of that works
[16:36] <jam> luks: not even -n ?
[16:36] <luks> it seems to be a common problem though
[16:36] <jam> do you have DISPLAY set?
[16:37] <luks> I have a running X11 session, so yes
[16:38] <jam> anyway, I've never done it myself
[16:38] <jam> just trying to track down the things it mentions in the man page
[16:39] <luks> it will really need some syscalls to disassociate the process from the terminal
[16:39] <luks> which will get ugly, I guess
[16:48] <jam> of course, it is easier if you just force the ssh agent to be paramiko
[16:48] <jam> but that would also mean losing whatever config they have set up in ssh
[16:48] <jam> And I know I have some ssh connections that require going through a proxy ssh connection, etc
[16:48] <jam> (canonical is pretty tight on security)
[16:49] <jam> It is probably not the most common case, but I know I can't (easily) use paramiko to access things on most canonical machines.
[17:01] <vila> luks: as a last resort you may check that the SSH_AUTH_SOCK env variable is set to ensure same ssh agent is used...(but do ssh agents work for passwords ?)
[17:19] <khemicals> found the cause of the issue I noted earlier -- noting for anyone reading through the logs -- set the BZR_LOG env variable and the errors go away (set it to something writable -- ala /tmp/bzr.log) -- suggest setting to something sane and properly perm-set for a proper permanent solve
[17:19] <khemicals> bug #106117
[17:59] <rocky> jelmer: hey ... when a bzr svn-push is pushing and it scans for all branches in the remote svn repo .... does it save that info so it doesn't have to do it again on the next svn-push ?
[17:59] <jelmer> rocky, most of it, yes
[18:00] <rocky> jelmer: i'm pushing to a repo which apparently has about 1100 branches and it's taking forever right now
[18:00] <rocky> i don't undesrtand why it has to scan branches for "projects" which aren't even related to the folder/trunk i'm dealing with
[18:02] <jelmer> rocky, 0.5 should be able to not do that
[18:03] <jelmer> rocky, 0.4 basically assumes one project per repository
[18:04] <rocky> gotcha
[18:05] <kjcole> 'lo. Back again.  I'm rebuilding a knit file the hard way.  What is the last number on the first line (version line) of a knit file and can I regenerate that outside bzr?
[18:05] <kjcole> And second, compressing the file: is there any special option I should add to gzip to produce the compressed knit?
[18:07] <kjcole> (The knit file doesn't need to be 100%, as the file's been removed.  It just needs to be good enough for the repository to survive an upgrade to a better format.)
[18:08] <kjcole> I have a possibly corrupt version line from the original, and it contains the right filename and line count.  I also have the original file from which the knit was produced.
[19:49] <kjcole> Is the sha1 hash for a knit determined from the raw data (without compression, version header, end trailer, line prefixes) or after?
[20:18] <lifeless> kjcole: the sha in a knit record is that of the data alone
[20:22] <kjcole> lifeless: Thanks. (I just finished posting the question on the mailing list, so ignore it there.)  Does it exist anywhere else?  and is it simply what "sha1sum" produces?
[20:24] <lifeless> kjcole: bzrlib/knit.py
[20:24] <lifeless> kjcole: if oyou're creating a knit from scratch you can just use the api :)
[20:24] <kjcole> lifeless: Although I've "fixed" the broken gzip knit file, I now have an incorrect sha1. So I'm wondering if it recomputes it or compares it to a stored value.
[20:24] <kjcole> lifeless: I suppose that would have been the sensible thing to do. ;-)
[20:24] <lifeless> its compared on extraction
[20:25] <lifeless> if it doesn't match its an error
[20:26] <kjcole> lifeless: Hokay...  Lemme see if I can figure out knit.py.  Thanks.
[20:26] <seb_kuzminsky> me again with more problems
[20:26] <lifeless> kjcole: I suggest creating the knit using the api
[20:26] <lifeless> kjcole: this will ensure no mismatches
[20:26] <lifeless> seb_kuzminsky: hi
[20:26] <seb_kuzminsky> thanks to lifeless, the server-side email plugin/hook is doing it job well
[20:27] <seb_kuzminsky> but one of the developers here is on a mac, and it chose to install some unknown version of bzr-email along with bzr 1.10
[20:27] <seb_kuzminsky> now his local bound branch tries to run bzr-email when he commits on his mac
[20:27] <seb_kuzminsky> and it's failing, it looks like the mac "mail" program isnt quite what bzr-email expects
[20:27] <lifeless> well
[20:28] <lifeless> 'bzr help email'
[20:28] <lifeless> will document the options there; but that dev doesn't need bzr-email installed :)
[20:28] <kjcole> lifeless: I'm just trying to get past an error from a single corrupt file many revisions back.  (The file is one that never changed, and was removed from the repository minutes after it was added.)
[20:28] <seb_kuzminsky> we tried setting post_commit_mailer=/usr/bin/true in his .bzr/branch/branch.conf, but to no avail
[20:28] <seb_kuzminsky> i understand he doesnt need bzr-email install
[20:28] <kjcole> lifeless: (in fact, minutes after the repository was inited.)
[20:28] <lifeless> kjcole: yes, I understand, what I'm suggesting is probably the easiest way. Note that you *cannot* make 'check' pass unless you can get something that matches the sha1sum sum in the layer above the knit
[20:29] <kjcole> lifeless: Thanks. Will pursue.
[20:30] <lifeless> kjcole: as inventing something with a specific sha1 is hard :) - you'll be better off with the rebase-the-repository approach :)
[20:30] <seb_kuzminsky> is there a way to enable/disable plugins/hooks on a per-branch basis?  it seems like it's pretty much system-wide
[20:31] <lifeless> seb_kuzminsky: the plugins run systemwide, but *activate* per-branch
[20:31] <seb_kuzminsky> what controls which plugins are active on each branch?  i didnt see anything in .bzr/branch
[20:32] <seb_kuzminsky> hi lenny
[20:33] <lennybn> seb_kuzminsky: hi
[20:33] <seb_kuzminsky> lifeless: meet lenny my mac-using co-worker
[20:39] <lifeless> lennybn: hi
[20:39] <lifeless> seb_kuzminsky: well for bzr-email, its 'has a post_commit_to value set'
[20:39] <lifeless> lennybn: can you (simplest thing) just remove bzr-email
[20:40] <lennybn> lifeless: do you know where it lives?
[20:40] <seb_kuzminsky> i'm pretty sure lenny doesnt have post_commit_to set in his .bzr/branch/branch.conf
[20:41] <seb_kuzminsky> it's in /usr/share/pycentral on intrepid, not sure about on the mac
[20:42] <lifeless> lennybn: python -c 'import bzrlib.plugins.email; print bzrlib.plugins.email.__path__'
[20:44] <lennybn> for future reference it is in /Library/Python/2.5/site-packages/bzrlib/plugins/email
[20:45] <lifeless> just delete that directory
[20:46] <seb_kuzminsky> lifeless: do you want a bug report against bzr-email that it still does something on mac even if post_commit_to is not set in .bzr/branch/branch.conf?
[20:48] <lennybn> I removed the the directory and now it is working correctly.
[20:50] <lifeless> seb_kuzminsky: it is set - if lennybn has a bound branch
[20:52] <seb_kuzminsky> lifeless: i thought the "local" branch had config & plugins independent of the "remote" branch it's bound to (on another machine), is that not so?
[20:52] <lifeless> seb_kuzminsky: plugins are per-machine/user; config is bzr/branch/branch.conf + ~/.bazaar/locations.conf + ~/.bazaar/bazaar.conf
[20:53] <lifeless> seb_kuzminsky: bound branches couple together two branches
[20:53] <lifeless> seb_kuzminsky: or lenny may have had a checkout, which doesn't have a full local branch anyhow
[20:53] <lifeless> seb_kuzminsky: I'm aware that there is some less-than-optimal stuff with smarst-server + bzr-email interactions, but don't need a bug for it
[20:54] <seb_kuzminsky> oh, hm.  i think he has a "heavy checkout", which i *thought* was the same as a bound branch
[21:11] <vadi2> Hi, I'm having some trouble pulling from a branch. My local copy was modified, so bzr told me to merge - I did, however it still does not want to pull: http://pastebin.com/m1592533f
[21:12] <Peng_> vadi2: You have to commit after merging.
[21:12] <vadi2> ok
[21:13] <luks> vadi2: but that will not solve your "pull" problem
[21:13] <luks> vadi2: bzr will not allow you to pull until you have local revisions not present in the pulled branch
[21:25] <yml> I have done bzr push <svn repository> after rather long reorganization. This reorganization has lot of addition, and mv .
[21:26] <yml> The command is running for the last 10 minutes
[21:26] <yml> can I be confident that this is gonna end up in something good or should I kill it and try again.
[21:28] <vadi2> Peng_ thanks, that helped
[21:28] <Peng_> Whether or not it will succeed, I doubt killing and restarting it will do anything but waste time.
[21:28] <Peng_> vadi2: :)
[21:30] <yml> Peng_ : I will wait some times and see if anything could come out ?
[21:31] <yml> In case nothing good happens what are the options ?
[21:33] <yml> I mean anything better than do it again in a fresh svn co. If this information can help I have done a push between 2 bzr repositories and it works fine.
[21:33]  * Peng_ shrugs.
[22:17] <yml> jelmer: After a long can I know that bzr push < URL of the svn repository> is not going to do anything.
[22:25] <meoblast001> my friend just said bzr hung while pushing... killed all his programs.. and gave him the busy box fatal message
[22:46] <mtaylor> hey all... I know this is an outstanding bug, but getting messages about bzr break-lock lp-44825360:///~drizzle-developers/drizzle/development/.bzr/branch/lock continues to be confusing to people...
[22:48] <rocky> jelmer: i just had my "bzr svn-push" take several hours and sitll not complete, it looped over all branches over and over :(
[23:08] <roadrunner_> Noob here. Sorry in advance. Wondering how to pull down using bzr previous versions of a main branch
[23:08] <roadrunner_> My latest version of Gwibber does not work
[23:08] <roadrunner_> Previous version worked fine so I had bright idea of using bzr to grab earlier revision
[23:21] <jml> roadrunner_: "bzr pull -r <revision_spec>"
[23:21] <jml> roadrunner_: if you know the revno you want, use that. Otherwise "bzr help revisionspec".
[23:22] <jml> if you want to make a new branch for the older version, "bzr branch -r <revision_spec> <url>"
[23:24] <mwhudson> vila: you here?
[23:25] <mwhudson> mm, i guess it's pretty late for you
[23:44] <yml> ﻿rocky : If this can help you. I had the same problem
[23:46] <yml> I haven't been able to solve it at the end I gave up I did all the modif again with SVN
[23:47] <yml> rocky How do you know what bzr is doing ?
[23:49] <rocky> yml: use the -v switch and monitor ~/.bzr.log