[03:57] <RenatoSilva> verterok: hi
[04:08] <RenatoSilva> what is the .bzr/repository/lock/held file/dir?
[04:08] <RenatoSilva> what could cause access denied errors in this object?
[04:13] <RenatoSilva> what's the meaning of this log entry? can it cause access denied errors? Using fetch logic to copy between
[04:13] <RenatoSilva> CHKInventoryRepository('file:///C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests1963719442832723916/working_copies/default_branch/.bzr/repository/')(<RepositoryFormat2a>)  and
[04:13] <RenatoSilva> CHKInventoryRepository('file:///C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests1963719442832723916/working_copies/MessageVariantsCommit/.bzr/repository/')(<RepositoryFormat2a>)
[04:22] <Peng> RenatoSilva: It says it's fetching revisions from one 2a repo to another, and gives their paths. From the paths, perhaps it's from the test suite?
[04:24] <RenatoSilva> Peng: yes from the test suite, right after this line I get return code 0 , along with a test fail. When the test passes, and that's --random--, I get a lot of output after that same line and only then return code 0
[04:25] <RenatoSilva> I thought it could be something with the paths, so moved from C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests1963719442832723916 to c:/bzr_tests, didn't work
[04:26] <RenatoSilva> created a separate user, but and tried in that user, but didn't work either, although I've noted that the errors were less than current user (but same kind, access denied, unkonw cmd bzr.exe)
[04:27] <RenatoSilva> can anyone please bzr branch lp:~renatosilva/bzr-java-lin/encoding-fixes && mvn -o test ?
[04:27] <RenatoSilva> in Windows!
[04:52] <RenatoSilva> it seems soemthing regarding locking
[05:38] <jml> mwhudson_, btw, we're not going to do a bzr-builder session
[07:00] <mwhudson_> jml: that would have been more useful if my laptop hadn't still been in the other room :-)
[07:00] <jml> mwhudson_, heh
[07:30] <keithy> nothing works
[07:30] <keithy> I just upgraded to 2.
[07:31] <GaryvdM> keithy: "nothing works" does not help us help you
[07:31] <keithy> it was just the general status report
[07:31] <GaryvdM> keithy: please give us more details.
[07:32] <keithy> I am getting "unexpected end of message"
[07:35] <keithy> when remotely checking out
[07:35] <keithy> bzr+ssh
[07:35] <GaryvdM> keithy: What command did you run/what button did you click on to get that error?
[07:36] <GaryvdM> keithy: Is that the whole err, or have you shortened it. bzr errors normally start with "bzr: ERROR: "
[07:36] <spiv> keithy: which version, exactly?  2.0.2?
[07:37] <keithy> 2.0.1  on mac os x
[07:37] <keithy> and 2.0.2 on windows
[07:37] <keithy> I have to vnc to the windows machine to perform the check out as a pull
[07:37] <keithy> so it is hard to c & p errors/commands
[07:37] <spiv> pastebin the entire error text?
[07:38] <spiv> what SSH client do you use on Windows?
[07:39] <spiv> Note that since 2.0 bzr will not use plink.exe by default anymore, perhaps that's your issue?
[07:39] <keithy> could be
[07:39] <keithy> I have no idea what is on windows, it was plink
[07:39] <spiv> You can set BZR_SSH=plink in your environment to force that.
[07:39] <keithy> what will it use?
[07:40] <spiv> By default, on Windows, it will use paramiko, which is bundled in the installer.
[07:40] <keithy> ah ok
[07:40] <spiv> But perhaps it isn't finding your SSH keys
[07:40] <keithy> it gets as far as opening the channel
[07:41] <keithy> and asking for a password
[07:42] <spiv> Basically, there are two likely problems I can guess: it is failing to authenticate to the SSH server, or it is failing to run bzr on the server after logging iin.
[07:42] <keithy> authentication is succeeding
[07:42] <spiv> But i'But it's hardt to tell whithout more information.
[07:44] <keithy> any debug flags I can turn on?
[07:44] <keithy> ERROR: connection closed: unexpected end of message check permissions and connectivity
[07:46] <keithy> sftp seems to gt further
[07:48] <keithy> error file exists .... branchdirectory/.bzr
[07:48] <keithy> but I just deleted branchdirectory
[07:48] <keithy> I am doing a checkout --lightweight
[07:54] <keithy> i give up manual copy it is
[09:22] <Enisseo> hi everyone!
[09:23] <GaryvdM> Hi Enisseo
[09:23] <Enisseo> I made a bad mv, how can I cancel it?
[09:23] <GaryvdM> Enisseo: have you commited it yet?
[09:23] <Enisseo> no
[09:23] <GaryvdM> bzr revert filename
[09:24] <GaryvdM> I'm not sure if you give it the old name or then new name
[09:24] <Enisseo> I tried with both
[09:25] <Enisseo> and it prints an error
[09:25] <GaryvdM> Enisseo: let me check quickly
[09:25] <Enisseo> but in my case, maybe what's even worse is that I mv a folder into a file :S
[09:25] <Enisseo> bzr mv --after myFolder myFile
[09:26] <Enisseo> (instead of bzr mv --after myFolder myOtherFolder)
[09:27] <GaryvdM> Enisseo: Now I'n not sure about what you are trying to do.
[09:27] <Enisseo> just trying to mv a folder to another one
[09:27] <Enisseo> but the autocompletion made me mv to a file
[09:28] <Enisseo> (yes, that's a very bad mv I did :S)
[09:28] <GaryvdM> Ok - Could you please pastebin bzr status
[09:30] <Enisseo> GaryvdM: http://pastebin.com/m1b35fada
[09:31] <Enisseo> I accidently typed "mv install .buildpath" instead of "mv install _install"
[09:32] <GaryvdM> Enisseo: Are there any changes to files that you have made, if not, do bzr revert, and start again.
[09:33] <Enisseo> I made some other changes (I cleaned the bzr status before posting it)
[09:34] <GaryvdM> Enisseo: Ok - if there are no changes to .buildpath, then do bzr revert .buildpath
[09:35] <Enisseo> bzr: ERROR
[09:35] <Enisseo> :S
[09:35] <GaryvdM> What was the error?
[09:36] <Enisseo> A big one, starting with bzr: ERROR: The file id "1.2.0.7.sql-20091113082822-lh720xwrl1jupng4-1710" is not present in the tree <Inventory object at 1797e70, contents=".......
[09:36] <lifeless> poolie: bug 407834
[09:37] <distatica> how do I find out what files bzr ignored on bzr add ?
[09:38] <Lo-lan-do> "bzr ignored"
[09:39] <Enisseo> GaryvdM: solved! I launched a "bzr mv --auto" and it repaired everything :)
[09:39] <distatica> thank you Lo-lan-do
[09:42] <GaryvdM> Enisseo: Cool - I learn't something new :-)
[09:43] <Enisseo> Me too :)
[09:43] <Enisseo> Thank you for your time
[09:43] <Enisseo> bye everyone!
[09:48] <naoki> Hello.
[09:49] <naoki> One Japanese translator would like to translate bzr's help messages.
[09:49] <naoki> I found this page: http://bazaar-vcs.org/DraftSpecs/I18nSupport
[09:49] <naoki> Any progress for i18n?
[09:52] <GaryvdM> naoki: looking at the history of that doc, it was written by bialix. So he would be the best person to ask
[09:52] <GaryvdM> naoki: He's not here at the moment.
[09:53] <naoki> OK, I'll ask him. Thank you.
[09:54] <maxb> Is retrieving file content from bzr packs a really cpu intensive operation?
[09:55] <maxb> I'm running a bzr fastexport | hg fastimport, and the export can't generate the stream anywhere near as fast as the import can consume it
[09:56] <mwhudson> maxb: what format is is the bzr branch?
[09:56] <maxb> 2a (It's launchpad)
[09:57] <mwhudson> i see
[09:57] <mwhudson> generating content should be pretty fast
[09:57] <mwhudson> but only in a very general way
[09:58] <maxb> strace says bzr keeps open-fstat-fstat-lseek-mmap-lseek-read-close-munmap -ing the pack and index files repeatedly
[10:03] <poolie> hello GaryvdM
[10:03] <poolie> hello maxb et al
[10:03] <GaryvdM> Hi poolie
[10:03] <poolie> naoki: the core is not i18n; the concern is that would make startup of the command line slow(er)
[10:09] <lifeless> maxb: is the source branch local?
[10:09] <maxb> yes
[10:09] <lifeless> maxb: and fastexport probably isn't tuned at all
[10:10] <maxb> It seems to have gotten a lot slower over the course of the import, too. It was running at ~700 commits/minute near the beginning, now it's almost hung
[10:23] <GaryvdM> lifeless: I'd like to chat about some bzr-search ideas. I now a ok time?
[10:23] <GaryvdM> lifeless, Someone was asking for bzr-search to only search changed text, not all text. I'm going to have a go at it.
[10:25] <GaryvdM> lifeless, Should we have a config option to choose whether or not it does this?
[10:33] <lifeless> GaryvdM: bzr-search only searches diffs
[10:33] <lifeless> GaryvdM: but you need trunk, it was fixed in my stuff lasst week
[10:34] <lifeless> it was *reporting* way too much; however I'm being sociable right now, so now isn't a good time to chat
[10:34] <GaryvdM> lifeless: Oh cool - I'll let the person was asking for it know.
[10:34] <GaryvdM> It was RenatoSilva
[15:23] <thrope> hi, *.o in .bzrignore seems to matching files.so as well - unless .so are ignored by detault?
[15:23] <LarstiQ> both are ignored by default
[15:24] <LarstiQ> thrope: at least in my ~/.bazaar/ignore
[15:24] <thrope> oh
[15:24] <thrope> ok that explains it
[15:24] <thrope> ah yes mine too
[18:45] <smartgpx> Hi all. I'm a Win32 user of the setup.exe installer which gives a 'standalone' bzr.exe version of Bazaar without Python installed 'natively' on the machine.
[18:45] <smartgpx> In that scenario, is there a way of adding extra Python libraries (such as Paste and XMLBuild) such that the bzr.exe can find and use them?
[18:47] <smartgpx> Does bzr.exe have some equivalent of PYTHONPATH where extras should be installed?
[18:48] <LarstiQ> smartgpx: afaik, no
[18:52] <smartgpx> Thanks Wouter. I was looking at the thread bzr-git on Windows on the bzr ml which seemed to suggest it might be possible to get access to Dulwich this way - is that different? (I'll ask Jelmer directly next time he's online.)
[18:52] <LarstiQ> Dulwich is a Python git implementation
[18:52] <LarstiQ> smartgpx: do we know each other, or are you bandying whois information around willy-nilly? ;p
[18:53] <LarstiQ> smartgpx: maybe things have changed, but it used to be that the way to use other libraries was to not use the standalone bzr.exe
[18:53] <smartgpx> If that's poor nettique I apologise. It seemed more humane.
[18:54] <smartgpx> And not whois - IrcNicks instead.
[18:54] <LarstiQ> smartgpx: it's ok, I just hardly ever use that name online
[18:55] <LarstiQ> smartgpx: ah :)
[19:28] <servilio> Hi! In a local checkout I have made some local commits, but after updating it the changes I've commited before aren't there anymore, though bzr status -v shows them in a list of pending merges, but when I try to commit it tries to commit them all together
[19:28] <servilio> is there a way to commit them individually?
[19:28] <LarstiQ> servilio: you already did
[19:29] <LarstiQ> servilio: if you commit the merge, `bzr log -n0` will show you the separate commits merged in the last commit
[19:29] <servilio> LarstiQ, before doing the updated to pull changes upstream
[19:29] <LarstiQ> servilio: yes, those commits still exist and are now pending a merge
[19:30] <servilio> LarstiQ, upstream is a svn repo, if I then commit without --local will they show as individual changes in that repo?
[19:30] <servilio> because right now is asking for a commit message
[19:30] <LarstiQ> ah
[19:30] <servilio> like it would commit all at once
[19:30] <servilio> even with --local
[19:30] <LarstiQ> if it's svn, then doing it that way isn't too handy
[19:31] <servilio> LarstiQ: what would you recommend doing?
[19:31] <LarstiQ> servilio: not using --local
[19:31] <LarstiQ> but that's too late right now, so
[19:31] <servilio> LarstiQ, but it will commit directly.... ooops
[19:31] <servilio> so no way to recommit them separately now?
[19:31] <LarstiQ> servilio: you can rebase them
[19:31] <LarstiQ> but I'd unbind first
[19:32] <servilio> hmmm
[19:32] <LarstiQ> and if the result is correct, push it, and rebind
[19:32] <servilio> so, first "bzr unbind", then "bzr rebase"?
[19:32] <LarstiQ> servilio: bzr unbind; then I guess bzr commit for ease of reference; and rebase
[19:35] <servilio> LarstiQ: unbound the working dir already, but bzr commit created only one entry
[19:35] <LarstiQ> servilio: as it should
[19:35] <LarstiQ> servilio: `bzr log -n0`
[19:35] <LarstiQ> the other entries already exist, it need not create them again
[19:36] <LarstiQ> however, you want to have them linearly appended after the history in svn, that is what we're going to use rebase for
[19:36] <servilio> LarstiQ, oh, ok
[19:36] <servilio> so, commit, then rebase?
[19:37] <LarstiQ> servilio: yeah, you'll need to give rebase some options I think
[19:37] <LarstiQ> servilio: that will take some experimenting, so I'd first `bzr branch` of what you've got now
[19:37] <LarstiQ> servilio: or find someone who knows rebase better ;)
[19:38] <servilio> LarstiQ, the relevant option looks to be --pending-merges
[19:38] <LarstiQ> oh!
[19:38] <LarstiQ> that's a new one
[19:39] <servilio> LarstiQ, YES! it did it! :D
[19:39] <servilio> LarstiQ, that option rebased the pending merges as well
[19:39] <servilio> LarstiQ: thanks a lot!
[19:42] <LarstiQ> servilio: good :) checking, what does `bzr missing` think of the difference between your branch and svn?
[19:45] <servilio> LarstiQ: did not remember 'bzr missing', but it shows the three uncommitted changes I have locally
[19:45] <servilio> just as expected
[19:46] <LarstiQ> servilio: good, next step: `bzr push` back to svn, and then bind to it again
[19:49] <servilio> LarstiQ: just in the push'ing, but had to make some remembering for my password :)
[19:49] <servilio> LarstiQ: I think I will just do 'bzr push --remember' and leave the local working copy unbound
[19:50] <LarstiQ> servilio: that's cool too :)
[19:54] <servilio> LarstiQ: and actually what I wanted from the beginning, but didn't pay close attention to the difference between checkout and branch
[20:01] <servilio> LarstiQ: it would be nice that when doing an unbind the source repository would be recorded as the --remember for push/pull/missing
[20:03] <LarstiQ> servilio: if not already set, I guess
[20:03] <LarstiQ> servilio: file a bug, maybe the developers agree :)
[20:03] <servilio> LarstiQ: will do
[20:22] <lifeless> moin
[20:34] <gioele> is it me or UIFactory.show_{message,warning} are underused by bzrlib?
[20:36] <gioele> there are no uses of show_warning or show_message in bzrlib/*
[20:50] <servilio> is there a way to reference the origin branch once the source tree is unbound? something like :origin, or :branch?
[20:51] <LarstiQ> :parent
[20:51] <LarstiQ> that isn't populated for a checkout usually though
[20:51] <LarstiQ> pull --remember will set it
[20:52] <servilio> LarstiQ, any way to consult its value?
[20:52] <servilio> other than issuing a pull or similar command
[20:52] <LarstiQ> servilio: `bzr info`
[20:52] <LarstiQ> maybe -v
[20:53] <servilio> it shows the push branch, but I've already set that one
[20:56] <LarstiQ> then parent is not set
[21:06] <gioele> how come BzrEclipse has no "Diff" operation?
[21:06] <fullermd> There's a :bound alias.  I'm not sure whether it still exists when the branch is unbound (but still remembering its previously-bound location), though.
[21:09] <mkanat> So, any thoughts on whether or not tags that look like revision numbers are bad?
[21:10] <mkanat> That is, if I have a tag "3.2.4" (which could theoretically be a revision number) am I going to have some troubles?
[21:10] <LarstiQ> mkanat: hmm, it's bad practise
[21:11] <mkanat> LarstiQ: So you have any particular reasons why? I had a gut feeling it might be, but just wasn't sure.
[21:11] <lifeless> mkanat: it should be fine
[21:11] <gioele> LarstiQ: why bad practices?
[21:11] <mkanat> lifeless: Okay. Because I always have to specify tag: anyway, right?
[21:11] <lifeless> mkanat: you may ned to say -r tag:3.2.4 if you have a revno 3.2.4
[21:12] <lifeless> mkanat: there is a patch coming to search for tags if a thing isn't found in a revno
[21:12] <mkanat> lifeless: Ahh....
[21:12] <mkanat> lifeless: My concern is that things be as easy as possible for our users.
[21:12] <mkanat> lifeless: A lot of people customize Bugzilla and currently check it out via CVS, so there's going to be a lot of new bzr users. :-)
[21:13] <lifeless> mkanat: are you migrating bugzilla upstream to bzr ?
[21:13] <mkanat> lifeless: Yep!
[21:13] <lifeless> woo!
[21:13] <mkanat> :-)
[21:13] <lifeless> say hi to dave
[21:13] <mkanat> lifeless: Miller? :-)
[21:13] <fullermd> It certainly shouldn't be a *tool* problem.  It could be a *social* source of confusion.
[21:13] <lifeless> uhm so - tagging should be fine. In your docs say '-r tag:3.2.4'
[21:14] <lifeless> mkanat: yup
[21:14] <mkanat> lifeless: Ah, okay. :-) Yeah, talk to him every day, since he's theoretically the Project Leader of Bugzilla. :-)
[21:14] <mkanat> lifeless: Would it be easier if I just made them all "v3.2.4" though?
[21:14] <lifeless> mkanat: I would however encourage you to have a 3.2 releases branch, with a commit to it on each release
[21:14] <lifeless> or something like that
[21:14] <lifeless> mkanat: yeah, I worked with him some years back :)
[21:15] <mkanat> lifeless: Ah! Was that when he was at Canonical?
[21:15] <lifeless> yep
[21:15] <mkanat> lifeless: Ah, right, he was employee #1, as I recall. Hahaha. :-)
[21:15] <LarstiQ> mkanat: 3.2.4 of _what_? As fullermd says, not a tool problem.
[21:16] <mkanat> lifeless: Currently we're going to have a 3.2 branch that has tags for each release.
[21:16] <mkanat> lifeless: Although your idea of having a release branch might be better.
[21:16] <LarstiQ> mkanat: but maybe I'm too much cvs influenced
[21:16] <mkanat> lifeless: Though we also plan to have a "stable" tag on the branch, though.
[21:16] <lifeless> mkanat: sure.
[21:16] <mkanat> lifeless: So people could update to that if they wanted.
[21:16] <lifeless> mkanat: so - play a bit, find what works, document it thoroughly
[21:17] <lifeless> we've changed how we do releases a fair bit over the years. we add tags, but we don't give people instructions to *grab* a tag
[21:18]  * mkanat nods.
[21:18] <mkanat> lifeless: Would "v3.2.4" be a better tag, do you think?
[21:21] <lifeless> mkanat: it would avoid collisions with revnos
[21:21] <lifeless> I'd say perhaps release-3.2.4
[21:21] <lifeless> bzr's tags are just version numbers I think, but as I say we don't need them to get releases as we make branches
[21:21]  * mkanat nods.
[21:26] <mkanat> lifeless: What's the advantage of "release-" over "v"?
[21:26]  * mkanat is just wondering if there's a technical difference.
[21:26] <lifeless> clarity
[21:26] <mkanat> I can see that.
[21:27] <lifeless> plane catchin' time
[21:27] <lifeless> ciao
[21:27] <mkanat> Ciao!
[21:27] <lifeless> or I guess to be precise; food; bus to airport. WAIT. plane.
[21:27] <lifeless> I maybe back @ the airport :P
[21:28] <LarstiQ> :)
[21:29] <LarstiQ> mkanat: I wasn't very clear, what I would do is '$project-$version'
[21:29] <mkanat> LarstiQ: Hmm. I'd think that would be fairly clear given the branch nickname, but I suppose maybe it's less clear with merged branches?
[21:30] <LarstiQ> mkanat: maybe I'm old and biased ;)
[21:31]  * mkanat shrugs. :-)
[21:31] <hsn> there there any plans for cherrypick with history?
[21:31] <fullermd> An advantage of that is that it makes the tag name more likely to be universally unique.  That can be an advantage if it ever gets imported into a situation where tags from multiple projects have to coexist.
[21:32] <LarstiQ> mkanat: tags are stored per branch right now, but I myself won't depend on that fact
[21:33] <LarstiQ> mkanat: what happens if you join two branches together, or with fast-export/import?
[21:33] <mkanat> LarstiQ: Oh, true.
[22:21] <RenatoSilva> verterok: hi
[22:23] <phcoder> Hello, all. Is there a way to unmerge branches while still allowing them to be merged on a later date?
[22:55] <fullermd> Funny.  There's a thread about committer/reviewer resources going on on the Postgres lists right now   :p
[22:55] <verterok> RenatoSilva: hi
[23:02] <RenatoSilva> verterok: hi. I did more tests
[23:02] <RenatoSilva> verterok: I've isolated one specific test that randomly fails/passes.
[23:04] <RenatoSilva> verterok: here is the stack trace with the error message, and below the bzr log on fail/pass. The only diff in bzr log between fail/pass is that when passing, there are more lines, there's no error message in bzr log! http://pastie.org/695026.txt
[23:05] <RenatoSilva> verterok: tried cerating anotehr windows user, but same errors, although seems less ones
[23:06] <verterok> RenatoSilva: yes, the extra lines are the branch setup for the test
[23:06] <RenatoSilva> verterok: I've also run the tests in Ubuntu, and they passed!
[23:08] <RenatoSilva> verterok: does the url give you any clue on what's wrong?
[23:08] <verterok> RenatoSilva: looks like the lock isn't released, which is weird, as there is a single client running for th tests
[23:08] <verterok> *the
[23:09] <RenatoSilva> verterok: yes I've noted the access denied are about lock files
[23:10] <RenatoSilva> verterok: doesn't junit use thread when running the tests?
[23:10] <RenatoSilva> *threads
[23:10] <verterok> RenatoSilva: hmm, no. at least not by default
[23:12] <RenatoSilva> verterok: do you have winxp to test it? about linux, the tests fails for non-ascii paths, for example /I/am/in/maçã$mvn test --> fails
[23:13] <verterok> RenatoSilva: yes, it's down currently, need to get home to test in win xp
[23:14] <RenatoSilva> verterok: ok, thanks if you can. Do you usually update winXP?
[23:14] <verterok> RenatoSilva: no, it's an old version...I think SP1
[23:14] <RenatoSilva> verterok: ok...your vm in hudson too?
[23:15] <verterok> RenatoSilva: that's the only winxp I have :)
[23:15] <RenatoSilva> verterok: ahahah ok
[23:15] <RenatoSilva> verterok: I need to find someone with winxp sp3 + mvn + bzr
[23:17] <RenatoSilva> verterok: I'm lazy to create a win vm here
[23:20] <RenatoSilva> verterok: but about Linux, something seems wrong with your linux in hudson
[23:21] <RenatoSilva> verterok: just ran the tests on a virtualized kubuntu here, all successfull too
[23:21] <verterok> RenatoSilva: why? it's just a stock karmic install
[23:36] <RenatoSilva> verterok: I don't know why, I just know it's working here :D
[23:36] <verterok> jej :)
[23:40] <RenatoSilva> jej?
[23:41] <verterok> RenatoSilva: heh?
[23:41] <verterok> RenatoSilva: same as :-)
[23:42] <RenatoSilva> verterok: ah ok, never saw that, thought it was another irc acronym
[23:44] <RenatoSilva> verterok: I would like to help you solve the failures in linux, but the only thing I know is that they don't happen here in ubuntu and kubuntu
[23:44] <verterok> RenatoSilva: thanks, I'll try to take a closer look later, at home
[23:45] <RenatoSilva> ok
[23:48] <RenatoSilva> I think I'll file a bug about the WinXP for at least finding out the root cause