[00:01] <Peng_> Woah, 50 took 10 times as long as 2500? ...And used more RAM?
[00:03] <mae^> how do I convert a lightweight checkout into a full branch?
[00:03] <poolie> bzr help reconfigure
[00:04] <mae^> ah, thanks
[00:26] <Toksyuryel> it's almost hard to believe bzr is almost up to 1.10 already
[00:26] <Toksyuryel> it was barely 1.1 when I first discovered it like 5-6 months ago
[00:59] <lifeless> Toksyuryel: 1 release a month
[01:00] <lifeless> Toksyuryel: you must have found a a distro with an older version :)
[01:00] <Toksyuryel> it was 1.1 when I joined this channel
[01:00] <Toksyuryel> unless this channel was a distro with an older version :O
[01:00] <lifeless> then you joined 9-10 months ago  :)
[01:01] <Toksyuryel> I do have a poor grasp of time
[01:01] <Toksyuryel> I should inspect my logs to find the real date
[02:06] <lifeless> Peng_: v
[02:06] <lifeless> robertc@tungsten:~/python$ du -sh .bzr/bzr-search/
[02:06] <lifeless> 296M    .bzr/bzr-search/
[02:06] <lifeless> robertc@tungsten:~/python$ du -sh .bzr/repository/
[02:06] <lifeless> 213M    .bzr/repository/
[02:07] <lifeless> Peng_: 2 and mumble hours to index; group_size 500
[02:31] <Peng_> Yeah, I could download those indexes faster than you could generate them. :P
[02:31] <Peng_> lifeless: Thanks for crunching the numbers. :)
[02:41] <lifeless> Peng_: thats at group size 500
[02:41] <lifeless> Peng_: so, 1 hour to do with group 1500
[02:44] <lifeless> bbs, fooding
[03:01] <markh> poolie: do you think it is too late to get the new shell extension (which also gives us 64bit support) into 1.10?  The changes are only to setup.py, the inno installer, and tortoise itself.
[03:01] <markh> i've a patch ready to send if so
[03:02] <markh> err - if not :)
[03:02] <poolie> if it's just adding a new capability i'd say it should wait for 1.11 just on risk-avoidance
[03:02] <poolie> if it's fixing a bug or regression, maybe 1.10
[03:02] <poolie> what do you think?
[03:03] <markh> yeah, it certainly falls more into "new capability" - I don't mind waiting...
[03:03] <poolie> ok
[03:03] <poolie> you can still send it now of course
[03:03] <poolie> since 1.10 has branched off
[03:04] <markh> yeah - will do
[03:05] <markh> for the same reason, we should probably let john build using mingw for this release, and once its out I can have less fear of breaking something
[03:25] <Rolly> Hi guys/girls, I'm having a problem with performing operations on a remote linux 1.9-rich-root branch from my Windows computer. I get this:
[03:25] <Rolly> ERROR: bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', "Unknown repository format: 'Bazaar RepositoryFormatKnitPack6R
[03:25] <Rolly> ichRoot (bzr 1.9)\\n'")
[03:25] <Rolly> On my Windows box, I can use 1.9-rich-root branches locally with no problem.
[03:26] <lifeless> Rolly: your remote machine is using some version of bzr < 1.9
[03:26] <Rolly> bzr version on my remote machine reports "Bazaar (bzr) 1.9"
[03:27] <Rolly> oh sorry, you're right. The bzr in my chroot is 1.8
[03:27] <lifeless> what does
[03:27] <Rolly> thanks for the clue
[03:27] <lifeless> 'ssh machine bzr --version'
[03:27] <lifeless> heh :)
[03:27] <Rolly> :D
[03:28]  * Rolly bangs head
[03:42] <markh> poolie: I think I've broken kerguelen :(  You familiar with their web interface?
[04:14] <poolie> yes
[04:15] <lifeless> yes its broken, or yes you're familiar ;)
[04:15] <poolie> yes i'm familiar
[04:15] <poolie> i'm going to check if i can log in
[04:16] <poolie> markh, it says "The system is not available as the server is currently stopped. You can select another system.0"
[04:17] <poolie> do you think you specifically broke it, or did it just stop working?
[04:18] <poolie> maybe the vm host server crashed?
[04:18] <poolie> i've filed a support ticket
[04:18] <poolie> markh^^
[04:19] <markh> poolie: I installed windows updates, and it said it needed to reboot, so I let it, and it didn't come back up.  It had successfully rebooted after the VS install though...
[04:20] <poolie> ah
[04:20] <markh> but it does look like a very early error
[04:20] <markh> the status never changes to "booting"
[04:20] <poolie> i think they said something about not installing windows updates, but rather letting them do it :)
[04:20] <poolie> sorry, i should have mentioned this earlier
[04:20] <markh> oh :)
[04:20] <poolie> otoh i don't see why that would make it permanently stop
[04:20] <markh> I can't see that referenced in their support section though
[04:20] <markh> (I looked for it after the fact ;)
[04:21] <markh> the server had many security related updates outstanding, which probably isn't a good thing
[04:21] <poolie> i'm not sure if it was them, or someone else
[04:21] <poolie> i looked at a few providers
[04:21] <poolie> i'm looking too
[04:21] <lifeless> markh: it may have had the 'server will run under VM' 'fixes' outstanding :)
[04:21] <poolie> and i agree that if their policy is to not just apply them that would suck
[04:22] <markh> lifeless: :)
[04:23] <poolie> i can't find anything about it either
[04:23] <poolie> or in my mail from them
[04:24] <poolie> markh: "
[04:24] <poolie> I am looking into this for you now, can you advise if you have installed updates or patches, or any other software prior to the issue presenting ?"
[04:24] <markh> but I can't find much there at all - eg, the work "troubleshooting" has zero hits
[04:24] <markh> heh
[04:24] <markh> yeah - "installed all critical windows updates" :)
[04:24] <Rolly> Is there a global .bazaar config file location? bzr help files only references ~/.bazaar/bazaar.conf
[04:24] <poolie> i'll forward the mail to you
[04:25] <lifeless> Rolly: not currently
[04:25] <Rolly> darn. OK
[04:25] <poolie> i'm open to moving to some other provider if they would be better
[04:26] <markh> it seemed quite fine so far.
[04:33] <CXI> is there an explanation of the various repository formats somewhere?
[04:35] <markh> CXI: "bzr help formats" is the best I'm aware of
[04:39] <CXI> hm, okay... I think I might be missing some conceptual understanding
[04:41] <lifeless> CXI: you can just ignore the formats unless you are using bzr-svn, or very big projects
[04:41] <CXI> well, maybe
[04:41] <CXI> I like to keep a documents directory under version control - it has code for various projects, documents and other junk that I want to keep versioned and backed up
[04:42] <lifeless> is it 10000 files or more?
[04:42] <CXI> nope
[04:42] <lifeless> have you made 10000 changes or more?
[04:42] <CXI> double-nope
[04:42] <lifeless> are you using bzr-svn?
[04:42] <CXI> not yet, but I'd like to
[04:43] <lifeless> you can ignore formats for now
[04:43] <lifeless> when you start using bzr-svn you will need to learn a little
[04:43] <CXI> I should clarify that I installed bzr yesterday, so the "not yet" time period is pretty small :)
[04:44] <CXI> also, do I need to do anything special to checkout/work on code for an individual project rather than getting the whole repo?
[04:45] <lifeless> I don't know quite what you mean
[04:45] <lifeless> branches are individual projects...
[04:46] <CXI> well, let's say I have documents/code/proj1 and documents/code/proj2
[04:46] <CXI> if documents is a repo, can I check out proj1?
[04:47] <Peng_> CXI: You should have made separate branches for proj1 and proj2.
[04:48] <lifeless> CXI: what do you mean by repo? if you mean something made by 'bzr init-repo' - no, because code/proj1 is probably just a file on disk :)
[04:48] <lifeless> CXI: or rather, 'repository' is *totally* unrelated to 'I have a branch X'
[04:48] <lifeless> CXI: you can checkout anything that is a branch.
[04:49] <lifeless> CXI: you cannot checkout things that are not branches.
[04:50] <Rolly> if there's a network problem or glitch, will bzr branch detect it and abort?
[04:51] <lifeless> Rolly: if bzr gets an error from the OS yes
[04:51] <Rolly> Cool
[04:52] <lifeless> Rolly: if its transient and the OS recovers the tcp link, bzr will not be aware of the issue
[04:52] <Rolly> I was just a bit concerned because the spinner wasn't moving
[04:52] <Rolly> all is well
[04:53] <CXI> oh!
[04:53] <CXI> I was calling branches repositories because I didn't understand them properly
[04:54] <Rolly> a "tree" is a branch + a repository, right?
[04:54] <Rolly> "standalone tree" I mean
[04:55] <lifeless> Rolly: its a checkout + branch + repository colocated
[04:55] <lifeless> Rolly: (ls .bzr/)
[04:56] <Rolly> My branching operation just finished and I only see the .bzr directory, but bzr info says standalone tree
[04:58] <Rolly> when I cd into the directory containing .bzr/ and run bzr co, I get "ERROR: File exists: u'G:/temp/www/.bzr'"
[04:59] <lifeless> Rolly: uhm
[04:59] <lifeless> Rolly: don't do that :P
[04:59] <Rolly> why not? :)
[04:59] <lifeless> Rolly: I was saying 'ls .bzr' because that shows the objects present in the directory
[04:59] <lifeless> 'bzr co' inside .bzr isn't something normal to do
[05:00] <Rolly> i'm not inside of .bzr/
[05:00] <Rolly> I'm in the directory that contains .bzr/
[05:00] <lifeless> Rolly: oh, misread
[05:00] <Rolly> the place I branched to
[05:00] <lifeless> Rolly: whats listed if you do 'ls .bzr' there?
[05:00] <Rolly> > ls .bzr/
[05:00] <Rolly> branch  branch-format  branch-lock  checkout  README  repository
[05:01] <lifeless> Rolly: it has a checkout already
[05:01] <Rolly> > ls -lah .
[05:01] <Rolly> total 0
[05:01] <Rolly> drw-rw-rw-  3 user 0 0 2008-12-01 23:42 .
[05:01] <Rolly> drw-rw-rw-  3 user 0 0 2008-12-01 23:42 ..
[05:01] <Rolly> drw-rw-rw-  6 user 0 0 2008-12-01 23:52 .bzr
[05:01] <lifeless> Rolly: what does 'bzr st' report?
[05:01] <Rolly> where is the checkout? :O
[05:02] <Rolly> 'bzr st' show all of the files as "removed"
[05:02] <lifeless> Rolly: 'bzr revert'
[05:02] <lifeless> I would guess something interrupted bzr
[05:02] <lifeless> as it was building the checkout
[05:03] <Rolly> > bzr revert
[05:03] <Rolly> bzr: ERROR: No final name for trans_id 'new-2222'
[05:03] <Rolly> file-id: None
[05:03] <Rolly> root trans-id: 'new-0'
[05:03] <Rolly> 'bzr st' still shows all as removed
[05:03] <Rolly> shall I try to branch again?
[05:04] <lifeless> Rolly: no, that phase worked
[05:04] <Rolly> OK
[05:04] <lifeless> Rolly: are you on windows?
[05:04] <Rolly> Yep
[05:04] <Peng_> Rolly: What version of bzr?
[05:05] <lifeless> so, start by filing a bug; there will be a backtrace in your .bzr.log (bzr --version lists where that can be found)
[05:05] <Rolly> Bazaar (bzr) 1.9
[05:05] <lifeless> Rolly: try 'bzr remove-tree' then 'bzr checkout .' (the '.' is important)
[05:06] <markh> it looks like BB missed that second mail attempt too :(
[05:06] <Rolly> ok lifeless
[05:06] <Rolly> > bzr remove-tree
[05:06] <Rolly> bzr: ERROR: Working tree "G:/webdev/bibliotik/temp/www/" has uncommitted changes.
[05:07] <lifeless> Rolly: rm -rf .bzr/checkout
[05:07] <lifeless> Rolly: :)
[05:07] <lifeless> then try 'bzr checkout .'
[05:07] <Rolly> > bzr remove-tree
[05:07] <Rolly> bzr: ERROR: No working tree to remove
[05:07] <Rolly> ah,
[05:07] <Rolly> ok I ran the checkout
[05:08] <lifeless> did it work?
[05:08] <Rolly> ERROR: Unable to create symlink 'blahblahblah' on this platform
[05:08] <lifeless> ok
[05:08] <Rolly> now I remember I saw that when I branched
[05:08] <lifeless> there is the problem :)
[05:08] <Rolly> phew
[05:08] <lifeless> there is a plugin you can use I think
[05:08] <lifeless> on the plugins wiki page
[05:08] <Rolly> yeah I'll check it out
[05:08] <Rolly> thanks for the assistance
[05:12] <Rolly> here goes nothin'
[05:13] <Rolly> argh!
[05:13] <Rolly> > bzr checkout .
[05:13] <Rolly> bzr: ERROR: [Error 123] The filename, directory name, or volume label syntax is incorrect
[05:13] <Rolly> .bzr.log says "WindowsError: [Error 123] blahblah"
[05:14] <CXI> okay, I think I'm getting this - I should create a *repository* for my documents directory, then a *branch* for each project
[05:14] <CXI> but what when I just want to check out all my code or all my documents? are there tools that will check out an entire repository?
[05:15] <markh> poolie: I'm happy for those updates to be rolled back, but am interested in why so many security updates would then be listed as outstanding, and why this isn't a concern for us...
[05:15] <poolie> did you reply to them, or they to you?
[05:15] <poolie> i didn't see anything
[05:15] <markh> they to both of us it seems
[05:16] <markh> I never got anything from you yet either, which is strange - only their reply
[05:22] <lifeless> CXI: no, checking out an entire repository doesn't make sense - the repository is *just* a database
[05:22] <lifeless> CXI: there are tools to mirror *all the branches in a repository*
[05:27] <Rolly> lp:bzr-win32symlinks Last Modified: 78 weeks ago
[05:27] <Rolly> heh... no wonder
[05:27] <CXI> hm
[05:28] <Rolly> I probably need to check my cygwin installation
[05:30] <spiv> poolie: thanks for undoing my caching patch
[05:39] <poolie> np
[05:39] <poolie> can you try it a different way?
[05:39] <poolie> maybe with a cache in a write stream from the transport that can be flushed?
[05:40] <metajack_> Is there a short guide to getting a server side hook set up for commit emails somewhere?  i see there was an appropriate hook added in 1.6, but can't find anything else about it.
[05:44] <markh> poolie: will you reply or shall I?
[05:44]  * markh assumes the mail has finally arrived for you...
[05:45] <poolie> markh, i replied
[05:45] <markh> cool, thx
[05:45] <poolie> no reply from them yet
[05:48] <awmcclain> Is there a way to un-remove a file?
[05:49] <awmcclain> (I keep getting "not a versioned path" if I try to bzr add or bzr revert)
[05:50] <spiv> poolie: the three obvious fixes are 1) transport level cache, 2) have a smart verb [but that doesn't help sftp push], 3) teach the client to read from the local repo rather than reading back from the remote when reconstructing fulltexts
[05:50] <lifeless> awmcclain: what bzr version?
[05:50] <spiv> poolie: probably 1) is the most straightforward.
[05:50] <lifeless> awmcclain: also, yes, 'bzr revert FOO' will look for FOO in the last commit, but no further back than that
[05:50] <awmcclain> lifeless: 1.6.1
[05:50] <awmcclain> hrm
[05:50] <lifeless> awmcclain: use 'bzr log -v' to find when it was deleted, then 'bzr revert -r XX FOO' to reinstate it
[05:52] <spiv> poolie: (by "have a smart verb", I mean an "insert_record_stream" sort of verb)
[05:53] <lifeless> spiv: sftp already has a network cache
[05:53] <lifeless> spiv: or rather,it has a network pipeline, which is why its faster than bzr:// in this case, I expect
[06:16] <vila>  lifeless: regarding bug  255687, I tagged it log as I want to make 'log -v <FILE>' display only the inventory entries related to FILE, i.e. making log a usable tool to find when a file was removed (I'm not sure I will succeed though :)
[06:25] <lifeless> vila: sure, but that bug is about annotate
[06:25] <lifeless> vila: and log -v FILE shouldn't (really really shouldn't) be digging more than one revision back anyhow, to find 'FILE'
[06:26] <vila> lifeless: why shouldn't it ?
[06:26] <vila> scratch that
[06:27] <vila> Say I have two branches conflicting about a file which get added/removed, how can I find the history of the files (which may be be different file-ids) ?
[06:27] <vila> As a user
[06:28] <vila> log sounds the most obvious answer hence the desire to make it usable to dig the history with the file path
[06:29] <lifeless> vila: well, I'm not disputing the use case; I'm disputing that the bug you tagged is about log
[06:30] <vila> I could delete the tag if you prefer, I put it because it was so close to the use case I was trying to address
[06:30] <vila> and I didn't want to forget it
[06:30] <lifeless> as long as the bug doesn't get closed if log starts doing that
[06:30] <vila> Fine, np for me
[06:31] <lifeless> cause there are clear issues for annotate, cat, ls, etc for this
[06:31] <lifeless> as for why not searching deep history
[06:31] <lifeless> 'bzr log file-that-never-existed'
[06:32] <vila> should display nothing, even if it takes a long time ?
[06:32] <lifeless> should not take a long time
[06:33] <vila> Is that the final reason for not providing the feature ?
[06:39] <lifeless> I'm not saying don't provide an answer for the use case
[06:39] <awmcclain> Anyone if trunk for bzr-email works with gmail now?
[06:39] <lifeless> awmcclain: I don't know sorry
[06:41] <lifeless> vila: I'm saying that making log FILE, as well as all the other commands, take a long time on bogus input is not user friendly
[06:41] <vila> lifeless: Right :-/
[06:42] <vila> Hmm
[06:42] <lifeless> vila: log isn't any more relevant than annotate or even 'ls' for 'find when a FILE was deleted'
[06:44] <vila> well, the use case is about: show me the history of that file, including when it was added, modified and removed
[06:46] <lifeless> not really
[06:46] <lifeless> "
[06:46] <lifeless> When a file has been removed from the repository, it is very difficult to find out what revision it was removed."
[06:46] <vila> Sorry, I was talking about *my* use case, not the bug 255867 one !
[06:47] <vila> grr 255687. please ubottu, deal with my typos !
[06:48] <lifeless> so I think  your use case is good; but I don't htink it maps to the users use case *that* closely
[06:48] <lifeless> they want to be told clearly when a file is requested that used to exist; they don't care about other stuff
[06:49] <vila> Right, I'll clear that tag right now ! :-) I wanted it to apply only to the "Use 'bzr log FILE' if FILE is removed" line :)
[06:50] <vila> done
[06:50] <lifeless> I don't have an issue really, with it being tagged log
[06:52] <vila> Ok, let's forget about that
[06:52] <lifeless> have you had time to hack on split-inventory stuff?
[06:52] <vila> no :-/
[06:53] <lifeless> thats a shame
[06:53] <vila> yes
[07:07] <awmcclain> FWIW, it doesn't. :(
[07:07] <awmcclain> (bzr-email trunk doesn't work with gmail)
[07:18] <awmcclain> Hrm... bzr dies when I try to set my launchpad ID. http://dpaste.com/95285/
[07:20] <lifeless> its pycurl
[07:20] <lifeless> there is a bug about this
[07:21] <awmcclain> K. I'll check.
[07:22] <lifeless> vila: could I ask a favout?
[07:22] <lifeless> favour
[07:23] <lifeless> bug 303959 - turn it into a patch?
[07:26] <vila> lifeless: there are other issues regarding redirection handling. I'd like to address some more before issuing a patch (with tests)
[07:26] <vila> But thanks for bringing it on my radar again :-/
[07:26] <awmcclain> lifeless: You're not talking about bug 271573?
[07:27] <awmcclain> Ah, found it. bug 82086
[07:27] <lifeless> vila: that one in particular is kinda important
[07:28] <lifeless> vila: because it breaks the gnome playground
[07:28] <vila> lifeless: Let's say I send a patch today whether or not it's complete enough ok ?
[07:29] <lifeless> that would be awesome
[07:30] <awmcclain> Is there a way to workaround this so bzr push lp:..... doesn't spawn a bad CA error?
[07:30] <lifeless> awmcclain: remove pycurl
[07:30] <lifeless> awmcclain: or setup the certificate
[07:45] <awmcclain> Does bzr set the cainfo when using pycurl? Where does it look for the .pem?
[07:49] <lifeless> bzr doesn't ask pycurl to do anything special
[07:58] <awmcclain> Hrm. Well, I can't uninstall pycurl, and I can't for the life of me figure out how to get it to recognize the pem file I've downloaded for the certificate.
[07:59] <awmcclain> Using bzr push https+urllib://code.launchpad.net/~awmcclain/bzr-email/gmail-fix tells me I "have a valid .bzr control directory, but not a branch or repository"... is that because I'm trying to push a checkout to a branch?
[08:09] <lifeless> awmcclain: it sounds like it got interrupted creating the dir
[08:09] <lifeless> awmcclain: you can just use bzr send and mail me a bundle if you like
[08:11] <awmcclain> Yeah, I temporarily disabled pycurl and now I'm getting a transport error: http://dpaste.com/95289/
[08:12] <awmcclain> What if I delete the branch on launchpad and start again? I'm just trying to publish the updated bzr-email that works with gmail.
[08:17] <lifeless> yah delete the branch and start again
[08:43] <gioele> hi
[08:45] <gioele> is there a command I can use to see the status of a file? On one file bzr status says nothing. I don't understand whether it is ignored, unknown or versioned
[08:49] <poolie> gioele, 'bzr ls' in the directory will tell you if it's versioned or not
[08:52] <gioele> poolie: thanks
[08:53] <gioele> anyway, isn't there a single command that integrates status and ls?
[08:53] <gioele> I wonder why status --verbose is silent for versioned files
[08:55] <poolie> that seems like a bug to me too
[08:55] <poolie> in fact, a regression
[09:01] <markh> does bundlebuggy only see mails that *start* with "[MERGE"?  HACKING says only "put [PATCH] or [MERGE] in the subject"
[09:02] <mwhudson> markh: i think it's startswith, yeah
[09:04] <markh> oh well, 3rd time lucky I guess...
[09:05] <poolie> it shouldn't be
[09:06] <markh> BB didn't pickup my retried message, and AlexB sent me a private email telling me he thought it was a regex with "^[MERGE"...
[09:06] <markh> 3rd try sent now :)
[09:08] <markh> yep - and BB immediately got it
[09:09] <lifeless> o
[11:08] <stephank> Hi! I have a bit of a problem. I have a bzr working directory I imported from a project source tarball. Now I've worked on this extensively, branched this several times, etc. The original project has since made some interesting changes available in a subversion repository, and I want to merge this into one of my branches. But of course, bazaar complains about no common ancestor. How would I go about this?
[11:16] <lifeless> stephank: the easiest way would be to branch off your original import, then run 'svn diff -r ORIG -r -1' | bzr patch
[11:16] <lifeless> or something like that
[11:19] <stephank> lifeless: I see, I'll try that. Thanks :)
[13:01] <sven_> hi! my friend got this crash when running gcommit : http://pastebin.com/dd9a619f
[13:01] <sven_> is that a known bug?
[13:01] <sven_> shall i report it?
[13:04] <jelmer> yeah, it's a known bug - there's a bug open about it in lp I think
[13:05] <sven_> jelmer, ok, thanks
[13:05] <vila> sven_: It is a known bug and I'm pretty it's already fixed, my best guess is that your don't have the latest bzr-gtk version available
[13:05] <sven_> vila, ok, good to hear
[13:09] <vila> sven_: it should be bug #286834, if that's not the case, let us know
[13:11] <sven_> vila, thanks a lot. i'll let you know if the problem persists after he upgrades
[13:15] <vila> sven_: strictly speaking this may be bug #279831, but the fix for #286834 was merged later and cover other related cases, so you need at least revno 617 of bzr-gtk
[13:18] <vila> jelmer: ping, I just marked bug 279831 as Fixed Released and realized that may not be the bzr-gtk policy, can you confirm ? I.e. the fix is merged on trunk even if 0.96.0 has not been formally released
[13:23] <vila> jam: ping
[14:05] <jelmer> vila, we usually mark as released after a release
[14:05] <vila> damn, ok, I'll fix the two I know about then
[15:16] <jam> vila: pong
[16:32] <luks> hehe, git-generated patch against bzr in the ML
[16:37] <LarstiQ> Jari seems to have that as his mo.
[16:52] <CardinalFang> Hi all.  Why would a "bzr pull", not "merge", ever generate conflicts?
[16:53] <Ursinha> CardinalFang, because you have a modified file on your local version that was changed on the remote one?
[16:53] <CardinalFang> Ursinha, Then "pull" would abort and say "use 'merge' instead", yes?
[16:53] <james_w> yeah, if you have uncommitted changes then you can get conflicts on pull
[16:54] <CardinalFang> Uncommitted changes.  Ah.
[16:54]  * CardinalFang checks.
[16:54] <luks> another possible conflict is if the remote side removes a directory,but you still have some unversioned file in the directory
[16:54] <CardinalFang> I see "Contents conflicts" on files, fwiw.
[16:55] <james_w> yeah, "Contents conflicts" is probably something like luks says
[16:55] <james_w> unversioned files conflicting with tree state changes
[17:00] <awilkins> Waa
[17:01] <awilkins> I'm having to convert a version control system to a newer one
[17:01] <awilkins> Problem is, the "version control system" is a guy who periodically just backs up the folder and adds the date to the name
[17:02]  * awilkins wants to revert to HIS revision 0 and delete some vital code
[17:02] <luks> replacing humans by software is always fun
[17:04] <luks> or are you converting the old guy into a newer guy? :)
[17:04] <awilkins> I'd settle for some upgrades
[17:06] <Tak> awilkins: you and I must have the same coworkers
[17:28] <vila> jelmer: ping
[17:30] <vila> jelmer: can you give me more info about bug #303959 ?
[18:26] <awmcclain> Can't catch a break while trying to push to a new branch on lp: http://dpaste.com/95441/
[18:30] <jam> awmcclain: use a newer bzr :)
[18:30] <jam> Actually the "in_buffer" bug is only because you used -Dhpss (it was a bug in the debug code)
[18:31] <jam> what happens if you *don't* use -Dhpss
[18:32] <awmcclain> See the top of the of the paste... same faliar.
[18:32] <awmcclain> faliure.
[18:32] <awmcclain> failure.
[18:32]  * awmcclain fails.
[18:36] <jam>  awmcclain: "Permission denied (publickey)" means that launchpad doesn't like your ssh key
[18:36] <awmcclain> A ha!
[18:36] <awmcclain> Makes sense.
[18:36] <jam> You can try "sftp -v bazaar.launchpad.net/~awmcclain/bzr-email/gmail-fix" if you want more debugging on that
[19:06] <LaserJock> is there a way to tell what bzr release a particular version of bzr-svn works with?
[19:06] <sri> s'happenin
[19:06] <sri> hey, anybody got vim scripts to do commits within vim?
[19:07] <sri> otherwise I suppose I'll write one..
[19:08] <lifeless> there is something
[19:08] <lifeless> search the list archives for vim :)
[19:09] <sri> oaky, I did a google and turned up nada.. which is why I asked here :)
[19:09] <awmcclain> sri: One of the VCS plugins has bzr support.
[19:09] <sri> I'll check the list archives.
[19:09] <lifeless> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=bzr+vim ?
[19:09] <sri> awmcclain: okay.
[19:09] <lifeless> sri: ^ my first google fu is strong
[19:10] <sri> damn.. I did vim scripts bzr
[19:10] <sri> your fu is strong :)
[19:10] <sri> I knew there had to be one.. I couldn't imagine nobody not writing one.
[19:25] <Rolly> hi all. someone committed a few revisions with the wrong name/email. Is there anyway to change them?
[19:26] <lifeless> Rolly: you can uncommit and recommit, but you can't just edit previous commits
[19:28] <Rolly> Okay thanks
[19:28] <Rolly> by the way, what is a typical use-case for bzr link-tree ?
[19:30] <Rolly> I didn't see it in the docs or the user guide
[19:33] <lifeless> it just hardlinks files in two trees that are the same, together
[19:33] <lifeless> its a space saver if you have very large trees
[19:36] <Rolly> Gotcha
[19:37] <lamalex> mwhudson: beuno: ping?
[20:37] <lifeless> bug 304547
[20:38] <LaserJock> does anybody know if the lesslog plugin is going to be maintained? it seems to have disappeared
[20:38] <lifeless> LaserJock: no idea sorry
[21:15] <rockstar> jelmer, ping
[21:20] <jelmer> rockstar, pong
[21:22] <rockstar> jelmer, I don't see a subvertpy release.
[21:22] <jelmer> rockstar, there is none, just a bzr branch :-)
[21:23] <rockstar> jelmer, but it's stable, right?  You're not going to change the API?
[21:23] <bpierre> hi
[21:24] <bpierre> when is the final release for 1.10 due?
[21:24] <jelmer> rockstar, yes, the API is stable
[21:25] <jelmer> rockstar, the basie project is already using it in their vcs browser
[21:27] <NfNitLoop> Pushing 4 small revisions via bzr-svn is slow.  It always makes me worry that it's doing something it shouldn't be. :p
[21:27] <jelmer> NfNitLoop, 0.5 will be much quicker I think :-)
[21:28] <NfNitLoop> cool. :)
[21:29] <NfNitLoop> and I noticed some comments about 0.5 doing away with branching schemes.
[21:29] <NfNitLoop> which will be nice.  Because it seems nobody around here can follow a standard. :p
[21:42] <NfNitLoop> (here - my workplace, in case that was vague.  Not y'all.)  :)
[21:49] <lifeless> jelmer: what has enabled the speed increase?
[21:51] <jelmer> lifeless: A bunch of things
[21:51] <lifeless> .next()
[21:51] <jelmer> lifeless, Eliminating various loops over all revisions in the repository to fetch and replacing with a single loop
[21:52] <jelmer> lifeless, Never fetching file properties for a directory more than once
[21:52] <jelmer> lifeless, Not fetching bzr file properties when we can prove they can't be there
[21:55] <lifeless> jelmer: did bzrlib changes help this? and if so can you suggest more we should do?
[21:56] <jelmer> lifeless, in terms of performance, I don't think there's a lot more that can be fixed in bzrlib (other than those two issues I raised)
[22:01] <flacoste> hi there, how can find the 'submit:' revision using bzrlib?
[22:03] <flacoste> how put another way
[22:03] <flacoste> i have a WorkingTree and I want to call changes_from() to get the list of changes relative to the submit: target
[22:05] <lifeless> do you mean equiv to 'bzr st -r submit:'?
[22:06] <flacoste> yes
[22:08] <flacoste> looking at status.py
[22:08] <flacoste> i guess that I need a RevisionSpec
[22:08] <flacoste> and call spec.as_tree(wt.branch) on it?
[22:09] <lifeless> I think you have  tree, so tree.branch.get_config().<something> will give you the submit url
[22:09] <lifeless> then you should open the branch - Branch.open(submit_url) and get the tip via branch.basis_tree()
[22:09] <lifeless> or something like that
[22:10] <flacoste> wouldn't RevisionSpec.from_string('subtmi:').as_tree(wt.branch) takes care of looking at the config?
[22:11] <flacoste> seems to work here
[22:36] <lifeless> flacoste: revision specs are really a UI feature
[22:36] <lifeless> flacoste: I wouldn't encourage using them in direct scripts
[22:37] <flacoste> really
[22:37] <lifeless> Peng_: present for you
[22:37] <flacoste> lifeless: they offer a nice abstraction api
[22:40] <markh> poolie: did you CC me on that last message to web24 support?  If so I haven't got it yet and I notice kerguelen is still down...
[22:40] <lifeless> flacoste: they do, but as a UI layer we change things as we find what works for users and does not work
[22:40] <lifeless> flacoste: compared to the underlying api where we tolerate awkward naming, for instance, more.
[22:41] <flacoste> lifeless: what about configuration names? is that the UI layer also?
[22:41] <poolie> markh: i last posted through their web support portal
[22:41] <poolie> john also found it was still down
[22:41] <flacoste> lifeless: because if I don't use RevisionSpec.from_string('submit:') i have to copy the 'submit:' configuration logic encapsulated into RevisionSpec_submit
[22:43] <lifeless> flacoste: flacoste its 'branch.get_submit_branch()'
[22:43] <lifeless> flacoste: no, you don't :)
[22:43] <flacoste> lifeless: a! that's even better!
[22:43] <flacoste> that's a very nice API
[22:43] <poolie> jam, markh: While we have removed all the Windows updates by our usual method, there still appears to be an issue with the server (stemming from the Windows updates carried out).
[22:43] <poolie> I have escalated this to Parallels' developers, seeking their assistance (highest support priority) in getting your server back online.
[22:44] <lifeless> flacoste: I just checked, we have some code duplication surrounding this
[22:44] <markh> bleh :(
[22:44] <markh> the web portal now shows the status as "booting" - obviously not very successfully though :)
[22:44] <lifeless> flacoste: as you say, there is logic there that would be duplicated to be 100% correct; I suggest filing a bug as its also duplciated in cmd_bundle
[22:45] <flacoste> lifeless: you mean between RevisionSpec_submit and cmd_bundle?
[22:52] <lifeless> yes
[22:59] <lifeless> Peng_: btree bzr-search, now 10% faster
[23:08] <lifeless> flacoste: generally we try to have a really nice api
[23:08] <lifeless> flacoste: it makes scripts clearer
[23:08] <flacoste> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/304585
[23:23] <CaMason> hi guys. I've renamed a file on my system without using bzr rename. Is there a way I can link these files before I commit?
[23:24] <bob2> bzr help mv -> --after
[23:24] <CaMason> aha thanks bob2
[23:25] <CaMason> ace. worked like a treat
[23:28] <jelmer> lifeless, Is there any chance split inventories will help with bzr-svn?
[23:30] <lifeless> jelmer: likely
[23:30] <lifeless> jelmer: what things slow bzr-svn up
[23:31] <jelmer> lifeless: lsprof reports:
[23:31] <jelmer>  * Inventory.copy() (33%)
[23:31] <jelmer>  * Repository.add_revision() (49%) (most of which is spent serialising
[23:31] <jelmer> the inventory)
[23:32] <lifeless> jelmer: grab the brisbane-core branch
[23:32] <lifeless> jelmer: use --development4
[23:32] <jelmer> lifeless, would any of these functions in particular become faster or do I have to make different calls as well?
[23:32] <lifeless> (--development4-subtrees I guess, or make the obvious changes to get a -rich-root variant)
[23:33] <lifeless> Inventory.copy() isn't relevant to split-inventories
[23:33] <lifeless> jelmer: describe the context you are using these things in
[23:33] <jelmer> lifeless: This is during svn-import
[23:33] <jelmer> add_revision() is called each time a new revision is imported from svn and added to the bzr repository
[23:34] <jelmer> Inventory.copy() is called before each revision delta that is fetched from svn
[23:34] <lifeless> ok, and where are you using I.copy?
[23:34] <jelmer> We make the changes against the copy of the inventory because we have to keep the parent inventory around as well
[23:35] <jelmer> (to see what file ids certain paths had in the parent revision, etc)
[23:35] <lifeless> ok
[23:35] <lifeless> change your code to do this:
[23:36] <lifeless> * create an inventory delta
[23:36] <lifeless> call Repository.add_inventory_delta(...)
[23:36] <lifeless> Repository.add_revision()
[23:36] <lifeless> and just hold onto inventories you want
[23:42] <jelmer> lifeless, thanks, I'll have a look at that
[23:43] <lifeless> it should work fine on bzr.dev too
[23:43] <lifeless> but on development4 it will apply the delta without examining the entire inventory
[23:53] <thumper> lifeless: when are you off?
[23:53] <thumper> lifeless: 'cause I have a big pqm patch
[23:53] <thumper> lifeless: to fix multipart message handling
[23:53] <lifeless> thumper: 1 hour
[23:53] <thumper> lifeless: ah
[23:54] <thumper> lifeless: the verify-email-hackage branch just refactors the email processing and verification
[23:54] <thumper> lifeless: I'm going to write another that does the multipart handling of merge directives
[23:54] <thumper> lifeless: but probably not today
[23:55] <lifeless> thumper: very cool - thank you
[23:55] <lifeless> thumper: today I fly, tomorrow I'm on leave, friday fosscamp starts
[23:55] <lifeless> I'll do what I can
[23:55] <thumper> lifeless: ok
[23:56] <thumper> lifeless: I have mthaddon waiting on a version that handles merge-directives to test
[23:56]  * thumper needs coffee badly
[23:57] <lifeless> thumper: bug 304545 is in the lp-bazaar baliwick
[23:57]  * thumper looks
[23:58] <lifeless> looks like an internal service went transiently awol
[23:58] <lifeless> likely not a code bug per-se, but still...
[23:58] <thumper> lifeless: retargetted
[23:58] <thumper> lifeless: I think it is a known bug, where the fix is in progress