[06:00] <Verterok> -DartifactId=maven-emma-plugin
[07:07] <vila> hi all
[07:13] <phoku> hi there
[08:42] <matkor> Hi ! What does conflict mean "Contents conflict in foo" ? I see only foo.BASE and foo.OTHER ?
[08:42] <matkor> Why no partially merged foo ?
[08:43] <lifeless> probably a binary file
[08:43] <lifeless> or a parallel add
[08:44] <matkor> mhmmm ... its py file so popably parallel add ... thanks lifeless
[08:45] <lifeless> if bzr st shows both as versioned
[08:45] <lifeless> then its parallel add
[08:45] <lifeless> pick one and bzr mv it to the right name
[09:21] <fullermd> If there's only a .BASE and .OTHER (no .THIS), wouldn't that mean you had deleted it, and OTHER had changed it?
[09:29] <lifeless> fullermd: no, it warns clearly on that case
[09:29] <lifeless> I think
[10:00] <fullermd> No, it just says 'Contents conflict, with foo.OTHER add'd and foo.BASE unknown.
[10:37] <Odd_Bloke> jelmer: I'm getting a "SubversionException: ("Can't get entries of non-directory", 160016)", what might be causing that?
[10:40] <Odd_Bloke> jelmer: This is when doing a "$ bzr branch svn://svn.debian.org/svn/pkg-voip/freepbx/trunk freepbx" BTW.
[10:46] <james_w> lifeless, spiv: tdflanders is a tricky customer, I think it's best to just leave him be for a bit. I'm dealing with him on several other bugs as well.
[11:42] <matkor> I had file in rev_A, I did bzr update to rev_B and file is missing ... How can I get latest revision when file existed in branch ?
[11:56] <awilkins> matkor: Get the file-id from a revision where you knew it existed, and do a verbose log with file-id grepping for it
[11:57] <awilkins> matkor: It's also fairly trivial to hack in a "log on file-id" option to the log command (not this is the 4th time that's come up in the channel, I think I may submit a patch for it)
[11:57] <jelmer> Odd_Bloke, please file a bug
[11:59] <Odd_Bloke> jelmer: Will do.
[12:08] <matkor> awilkins: Thanks !
[12:10] <awilkins> matkor: You're welcome ; the problem with logging on file-id is that because of the way inventories work, you can't actually pin down which revision it was deleted in.
[12:10] <awilkins> matkor: But the last revision it was _changed_ in should be good enough if you just want the file back
[12:13] <awilkins> matkor: for the deletion revision, you have to run the full log
[12:15] <Pieter> I made a fix on my old fastimport branch yesterday. But someone had introduced a new bug in the fastimport-dev version. So I merged in fastimport-dev and now want to refer to the commit that introduced the bug. But that commit has another commit number in my branch than in fastimport.dev. how should I refer to it?
[12:15] <Pieter> use --show-ids?
[12:16] <Kinnison> If I want to refer to a rev on a moving branch then I use the revid
[12:16] <Kinnison> they're a bit longer, but they're stable
[12:16] <Pieter> Hmm, I made changes to my working tree before merging, and now they're added to the merge commit :(
[12:20] <Kinnison> if you've not pushed that, uncommit, pick them out, revert and start again
[12:21] <Pieter> yeah.. I wish bazaar would auto-commit on merge
[12:21] <Kinnison> but the merge might not be right
[12:21] <Kinnison> E.g. you might want to fix a semantic error caused by the line-by-line merge
[12:21] <Pieter> yeah, in that case you can just amend the commit
[12:22] <Kinnison> It'd be trivial for you to write yourself a script which did merge, check-for-conflicts, commit-if-okay
[12:22] <Kinnison> If you really want that
[12:22] <Pieter> hmm..? http://pastie.org/299587
[12:23] <Kinnison> You can't push to launchpad over http
[12:23] <Pieter> but why is it a saved location then?
[12:23] <Kinnison> It's probably where you pulled from?
[12:23] <Kinnison> use bzr push --remember URL-TO-RIGHT-PLACE
[12:25] <Pieter> right
[12:25] <Pieter> http://pastie.org/299589
[12:25] <Pieter> nice :)
[12:43] <Peng_> Pieter: The bad URL being given by break-lock is known (bug 250451).
[12:44] <mwhudson> so the launchpad plugin doesn't seem to cope with random network suckage all that well
[14:07] <mwhudson> gar
[14:08] <mwhudson> when will ~ work in bzr+ssh urls?
[14:09] <awilkins> When a developer gets annoyed enough by it to patch it, I suspect
[14:10] <mwhudson> it's too easy to work around i guess
[14:10] <awilkins> It's a one-time annoyance for most branches
[14:10] <awilkins> So I suppose it doesn't pee you off on a daily basis
[14:11] <RedLizard> is it possible to synchonize working copies using bazaar without committing the changes?
[14:12] <fullermd> It annoys me on a semi-regular basis.  Probably would a lot more often it it weren't for bookmarks...
[14:12] <fullermd> RedLizard: You can use merge --uncommitted on a [local] branch to bring across uncommitted changes.  But it's not really a synchonization tool.
[14:13] <HippySurfer> Hi, bzr newbie here. Is it safe to copy a branch onto a CD from a Linux box, then back onto a Windows box? Ignoring anything that that might happen to the filenames in the working copy, will the bzr files be OK?
[14:15] <awilkins> HippySurfer: That should work, AFAIK
[14:15] <HippySurfer> thanks.
[14:15] <awilkins> HippySurfer: Do a remove-tree on the folder first and save yourself the space (unless there are unsaved changes)
[14:15] <RedLizard> fullermd: that should work I think, thanks :)
[14:15] <HippySurfer> good point.
[14:21] <RedLizard> fullermd: is it possible to merge your changes into the external branch, rather than the other way around?
[14:22] <awilkins> RedLizard: You can merge the changes from the external branch, then push to it, but merging needs a working tree because you may have to resolve conflicts
[14:22] <fullermd> Well, merge has a -d option to do the merge in another directory.  But that's of limited use; it's usually a lot easier to just cd $wherever; bzr merge $other
[14:23] <fullermd> (and anyway, you'd have to poke around $wherever to verify the changes and commit them anyway)
[14:24] <RedLizard> awilkins: but can you push uncomitted changes?
[14:24] <fullermd> No.  Push pushes revisions; it there's no revision, it can't be pushed (pash?)
[14:26] <RedLizard> can i merge --uncommited -d to a remote (as in, not on the local filesystem) branch?
[14:27] <fullermd> No, working trees can only be accessed locally.
[14:27] <fullermd> Realize, you could always commit the changes, push it somewhere, and then use uncommit or pull to 'step back' your branch and not include that commit.
[14:29] <RedLizard> i don't think that's going to help me
[14:30] <RedLizard> i'm trying to keep a working copy synchonized over several machines, while retaining the proper merging bazaar provides
[14:30] <RedLizard> without abusing commits just to synchonize
[14:31] <RedLizard> any ideas on how to accomplish this?
[14:37] <fullermd> Well, as a general rule, if you're moving between machines more than once without a commit, You're Doing Something Wrong(tm).
[14:38] <RedLizard> why?
[14:38] <RedLizard> what's wrong with what i'm trying to do?
[14:38] <fullermd> Well, it's not like there's a RULE about how often you have to commit.  But if it takes so long between commits that you're moving where you're working, that tends to suggest that you're doing a whole lot between commits.
[14:40] <RedLizard> i work both at home (on my home computer) and at the university (on my laptop). Therefore, i need to synchonize twice a day, regardless of how much work I accomplish.
[14:42] <RedLizard> In particular, i often need to synchonize something that isn't a logical atomic change, and therefore shouldn't be a commit
[14:43] <fullermd> Well, but commits ARE the item that bzr synchronizes.  You can fake it with 'temporary' commits that you push around and uncommit, but...
[14:43] <fullermd> merge --uncommitted is a tool to handle the case of "Whoops, I should be making that change in _this_ branch instead"; it won't (and isn't intended to) handle syncing back and forth.
[14:43] <fullermd> That's what revisions are for after all.
[14:45] <RedLizard> well, it's true that the problem I'm trying to solve is outside the scope of bazaar, but I don't think there's a different way to do it
[14:45] <RedLizard> in particular, I can't just rsync working copies around and merge those, because that would mean i would be merging .bzr directories, which will undoubtedly screw things up
[14:46] <fullermd> It could be done without screwing things up, but yes, it would take a bit of rather careful (which means 'fragile') handwork.
[14:47] <fullermd> It may help to just scale back the meaning you assign to a commit.  While every commit I make [ideally of course; I fall short in practice sometimes] is of a _single_ thing, that thing isn't necessarily _complete_.  Often isn't, in fact.
[14:48] <fullermd> 's why I have a lot of side branches; I don't stand for half-done things sitting on a 'main' branch, but in topic branches it's far and away the common state.
[14:49] <RedLizard> that could work, but there's a requirement that complicates things:
[14:49] <RedLizard> i don't want any of those synchonization-commits to show up in the public logs
[14:49] <RedLizard> [of the main repository]
[14:50] <RedLizard> since they often contain testing files containing passwords etc.
[14:51] <fullermd> Well, I never add those sort of temp things anyway; if they exist, they're individual and tiny files, and don't change much, so I just scp 'em around manually if necessary.
[15:26] <Odd_Bloke> I'd like to email a series of patches (i.e. one for each commit) to someone.  What's a good way to do this?
[15:26] <semslie> does anyone know if the trac-bzr plugin supports remote repositories?
[15:27] <semslie> currently my bzr repository is hosted on a different server to my trac install
[15:31] <jelmer> semslie, In theory I think it should, but it would be unworkably slow.
[15:31] <semslie> jelmer: well, thats a pretty convincing argument against. I'll try to set things up more sensibly instead.
[15:42] <mdmkolbe> Every time I revert a file, bzr leaves behind a *.~1~ file, is that default or is that something that has to be set per repository?  Also how do I disable that?
[15:43] <fullermd> Well, you could use --no-backup to make it not create a backup file.
[15:43] <jelmer> mdmkolbe, it's the default
[15:44] <mdmkolbe> ok, then is there an easy way to get to or check if I have a pristine code tree.  e.g. "bzr st" doesn't show *.~1~ by default and I need it to
[15:45] <fullermd> .~whatever files are ignored.
[15:46] <mdmkolbe> fullermd: yes, but is there a way to (temporarily) make them not ignored?
[15:48] <fullermd> No.  You could just whack 'em with find, or finger your way through bzr ignored.
[15:49] <mdmkolbe> fullermd: it looks like bzr ignored will do just what I need, thx
[15:54] <jdo> bug #288751
[15:54] <jdo> just got that using 1.9dev
[15:54] <jdo> Using saved push location: bzr+ssh://jdobrien@bazaar.launchpad.net/~jdobrien/ubunet/subscription-payments
[15:54] <jdo>  bzr: ERROR: Revision {jdo@canonical.com-20081006141744-k8myay8ls316o14y} not present in "purchase.py-20080823031523-leymwbfdmocqr4fp-4".
[16:09] <RaceCondition> I think I might have asked this yesterday, but how do I convert a git repository to a Bazaar one?
[16:10] <RaceCondition> was it fastimport?
[16:11] <Odd_Bloke> RaceCondition: Yes.
[16:12] <RaceCondition> so bzr init mybranch; cd mybranch; bzr fastimport ../mygitrepo/?
[16:16] <RaceCondition> hmm, I branched bzr-fastimport, but python setup.py install not easy_install . do not work
[16:16] <RaceCondition> python setup.py install gives no ouput, easy_install complains
[16:16] <RaceCondition> No eggs found in /Users/erik/bzr/fastimport/egg-dist-tmp-uIh1Oe (setup script problem?)
[16:17] <james_w> RaceCondition: it's a bzr plugin, drop it in ~/.bazaar/plugins
[16:17] <james_w> named as "fastimport"
[16:17] <RaceCondition> oh
[16:17] <RaceCondition> the fastimport module, right? not the whole branch
[16:17] <RaceCondition> hmm, there is no fastimport module
[16:18] <james_w> no, the whole branch
[16:18] <RaceCondition> got it
[16:23] <RaceCondition> nice, it worked
[16:23] <RaceCondition> although it went crazy when I accidentially did git fast-export -all instead of --all
[16:46] <RaceCondition> does bzr-upload also upload files that are not under version control?
[16:54] <beuno> RaceCondition, no
[17:03] <RaceCondition> beuno: weird, it did upload a file that was NOT under version control
[17:03] <RaceCondition> but that was the initial upload, following ones might be different
[19:08] <fynn> Hi. How do I get all patches committed by user foo?
[19:09] <fynn> including a summary, a patch name, and possibly the full diff as well?
[19:58] <fynn> OK, I'm encountering a weird issue.
[19:58] <fynn> when I run bzr (no arguments) in a directory that contains a .pyc file, that .pyc file is executed.
[20:00] <fynn> OK, this isn't just a .pyc file: it works if the directory contains a .py file.
[20:00] <fynn> i.e. same problem.
[20:00] <fynn> anyone knows why that is?
[20:01] <fynn> the problem seems to be caused by a file called parser.py
[20:08] <jam> fynn: I'm guessing you are on windows?
[20:08] <fynn> jam: nope, Ubuntu Hardy.
[20:09] <jam> hmm... we *do* "import parser" in 'bzrlib.tests.test_source' because 'parser' is a module that is part of the standard library
[20:09] <jam> so you naming a file the same as a standard lib isn't a great thing to do
[20:09] <jam> however, '.' shouldn't be on our search path
[20:09] <jam> by default it isn't
[20:10] <jam> there were some problems with /usr/lib/python2.x/site.py
[20:10] <jam> which was accidentally including '' into the default search path
[20:10] <jam> but IIRC that was only on win32
[20:10] <jam> fynn: can you try: "python -c 'import sys, pprint; pprint.pprint(sys.path)" and paste the output?
[20:10] <fynn> jam: here's a simple, straightforward reproduction of the problem:
[20:10] <fynn> http://dpaste.com/86633/
[20:11] <jam> fynn: right, that doesn't happen here, and I believe it is because your site.py is setting up a bad python module search path
[20:13] <fynn> jam: http://dpaste.com/86634/
[20:13] <jam> fynn: notice the '' as the first entry
[20:13] <fynn> jam: I suspect the problem is ... right
[20:13] <fynn> I thought that was normal for PYTHONPATH?
[20:13] <jam> fynn: you have "PYTHONPATH=''" ?
[20:13] <jam> or do you have it something like "PYTHONPATH='something:'"
[20:13] <jam> with a trailing ':'
[20:13] <jam> anyway, you could hack the bzr startup script with
[20:14] <jam> import sys
[20:14] <jam> if '' in sys.path:
[20:14] <jam>   sys.path.remove('')
[20:14] <jam> but you may want to try and debug how '' is being put into your path
[20:14] <fynn> jam: no, I'm not changing PYTHONPATH at all.
[20:15] <fynn> s/changing/setting/
[20:15] <jam> fynn: ah wait a sec, part of the issue is that 'python -c' is running in the local working directory
[20:15] <jam> so yeah, it adds ''
[20:15] <jam> can you try adding the 'pprint' stuff to your 'bzr' script?
[20:15] <fynn> where is that?
[20:16] <jam> fynn: probably /usr/bin/bzr
[20:17] <jam> you can just copy it somewhere else if you don't want to modify it there
[20:17] <jam> cp /usr/bin/bzr ~/bzr
[20:17] <jam> and then test it with ~/bzr
[20:19] <fynn> jam: it adds the CWD as the first entry.
[20:19] <jam> fynn: it should add the directory of the 'bzr' script, but not CWD
[20:19] <jam> you are seeing "CWD" always be added?
[20:20] <jam> well, CWD not the literal 3-letter string :)
[20:22] <fynn> jam: yes.
[20:23] <fynn> the first entry on the sys.path seems to consistently be CWD.
[20:24] <jam> fynn: just to cover all bases, here is a test script
[20:24] <jam> http://dpaste.com/86640/
[20:24] <jam> can you copy that into a file like "test.py"
[20:24] <jam> and then run it as
[20:24] <jam> cd ..
[20:24] <jam> python directory/test.py
[20:24] <jam> and see if it has CWD or only CWD/directory in the search path
[20:25] <jam> and assuming that fails like the rest
[20:25] <jam> then it is something with your python installation
[20:25] <jam> and that takes a bit more to debug
[20:30] <fynn> jam: $ cat bar.py
[20:30] <fynn> import sys, pprint
[20:30] <fynn> pprint.pprint(sys.path)
[20:30] <Odd_Bloke> loggerhead just made it into unstable. \o/
[20:30] <Odd_Bloke> 20:26:03 < BTS> loggerhead (NEW) 1.6-1 uploaded by Jelmer Vernooij <jelmer@samba.org> (Closes: #492477) http://packages.qa.debian.org/loggerhead
[20:31] <fynn> jam: $ python bar.py
[20:31] <fynn> ['/home/xif',
[20:31] <fynn> ...
[20:31] <jam> fynn: that is expected. And if you run it from another directory?
[20:32] <fynn> jam: same behavior:
[20:32] <fynn> ['/home/xif/foo',
[20:33] <jam> fynn: '/home/xif' is also in the path, right?
[20:33] <fynn> jam: if I run it from a different directory?  no, it's not.
[20:33] <jam> (the directory containing the script should always be added, and CWD should not. Unless, of course, the script is *in* CWD)
[20:33] <fynn> ah, one second then.
[20:34] <fynn> jam: OK, I checked
[20:34] <fynn> 1) the CWD is always added
[20:35] <fynn> (as the first entry in sys.path)
[20:35] <fynn> 2) the script directory is added as well, but not as the first entry.
[20:35] <jam> fynn: ok, so part (1) is a bad python installation setting, which we can try to debug, but isn't specifically a bzr problem
[20:37] <jam> fynn: you can try editing /usr/lib/python2.5/site.py
[20:37] <jam> for example, there is a function "removeduppaths"
[20:37] <jam> my guess is that it will end up having a '' in sys.path
[20:37] <jam> which gets expanded to CWD
[20:37] <jam> just before line 95 or so there is "sys.path[:] = L"
[20:37] <jam> you could add
[20:38] <jam> import pprint; pprint.pprint(sys.path); pprint.pprint(L)
[20:38] <jam> and then paste that
[20:38] <jam> that will tell us what paths remove dup paths is getting, and what it is setting it to
[20:39] <jam> fynn: it *could* be that you have a rogue 'foo.pth' file in your path, causing python to get confused about the correct paths
[20:39] <fynn> jam: you want me to add that debugging line before or after "sys.path[:] = L"?
[20:40] <fynn> (that's not it: I tried it from several newly-created directories)
[20:40] <jam> fynn: *before* that line
[20:40] <jam> fynn: the foo.pth is in some /usr/lib/* location
[20:41] <jam> well, a "rogue foo.pth" would be there
[20:41] <fynn> OK, line 100-101 now looks like this:
[20:41] <fynn> (100-101 in my site.py)
[20:41] <fynn>     import pprint; pprint.pprint(sys.path); pprint.pprint(L)
[20:41] <fynn>     sys.path[:] = L
[20:41] <jam> fynn: right
[20:41] <jam> now try running bar.py or bzr
[20:42] <fynn> hm, running 'python -c "pass"' doesn't do a thing.
[20:43] <fynn> I would have expected a printout.
[20:45] <fynn> jam: possibly stdout for site.py is suppressed.
[20:47] <jam> fynn: well looking here if I add "print testing" to site.py it shows up
[20:47] <jam> it may be that 'removeduppaths' isn't getting called
[20:48] <jam> fynn: you might try looking at the 'def main()' function
[20:48] <jam> and adding some debugging there
[20:49] <jam> fynn: also are you editing 'site.py' in place, or in a local copy?
[20:49] <fynn> jam: OK, thanks. I guess I should try that.
[20:49] <jam> A local copy won't be run
[20:49] <fynn> editing it in place, of course :)
[20:50] <fynn> jam: this is a fairly vanilla Hardy installation, so I'd suspect I'm not the only one seeing this.
[20:50] <jam> fynn: the first *I've* seen :)
[20:51] <jam> and as all python programs would suffer similar issues...
[20:52] <fynn> hm, I guess it _could_ be my setup.
[20:52] <fynn> would debug this a bit more when I have the time.