=== Hydrogen is now known as hYDROGEN === RAOF_ is now known as RAOF === hYDROGEN is now known as Wasserstoff [06:00] -DartifactId=maven-emma-plugin [07:07] hi all [07:13] hi there [08:42] Hi ! What does conflict mean "Contents conflict in foo" ? I see only foo.BASE and foo.OTHER ? [08:42] Why no partially merged foo ? [08:43] probably a binary file [08:43] or a parallel add [08:44] mhmmm ... its py file so popably parallel add ... thanks lifeless [08:45] if bzr st shows both as versioned [08:45] then its parallel add [08:45] pick one and bzr mv it to the right name [09:21] If there's only a .BASE and .OTHER (no .THIS), wouldn't that mean you had deleted it, and OTHER had changed it? === sabdfl1 is now known as sabdfl_epic [09:29] fullermd: no, it warns clearly on that case [09:29] I think [10:00] No, it just says 'Contents conflict, with foo.OTHER add'd and foo.BASE unknown. [10:37] jelmer: I'm getting a "SubversionException: ("Can't get entries of non-directory", 160016)", what might be causing that? === doko_ is now known as doko [10:40] jelmer: This is when doing a "$ bzr branch svn://svn.debian.org/svn/pkg-voip/freepbx/trunk freepbx" BTW. [10:46] 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] 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] 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] 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] Odd_Bloke, please file a bug [11:59] jelmer: Will do. [12:08] awilkins: Thanks ! [12:10] 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] matkor: But the last revision it was _changed_ in should be good enough if you just want the file back [12:13] matkor: for the deletion revision, you have to run the full log [12:15] 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] use --show-ids? [12:16] If I want to refer to a rev on a moving branch then I use the revid [12:16] they're a bit longer, but they're stable [12:16] Hmm, I made changes to my working tree before merging, and now they're added to the merge commit :( [12:20] if you've not pushed that, uncommit, pick them out, revert and start again [12:21] yeah.. I wish bazaar would auto-commit on merge [12:21] but the merge might not be right [12:21] E.g. you might want to fix a semantic error caused by the line-by-line merge [12:21] yeah, in that case you can just amend the commit [12:22] It'd be trivial for you to write yourself a script which did merge, check-for-conflicts, commit-if-okay [12:22] If you really want that [12:22] hmm..? http://pastie.org/299587 [12:23] You can't push to launchpad over http [12:23] but why is it a saved location then? [12:23] It's probably where you pulled from? [12:23] use bzr push --remember URL-TO-RIGHT-PLACE [12:25] right [12:25] http://pastie.org/299589 [12:25] nice :) [12:43] Pieter: The bad URL being given by break-lock is known (bug 250451). [12:43] Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed] https://launchpad.net/bugs/250451 [12:44] so the launchpad plugin doesn't seem to cope with random network suckage all that well [14:07] gar [14:08] when will ~ work in bzr+ssh urls? [14:09] When a developer gets annoyed enough by it to patch it, I suspect [14:10] it's too easy to work around i guess [14:10] It's a one-time annoyance for most branches [14:10] So I suppose it doesn't pee you off on a daily basis [14:11] is it possible to synchonize working copies using bazaar without committing the changes? [14:12] It annoys me on a semi-regular basis. Probably would a lot more often it it weren't for bookmarks... [14:12] 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] 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] HippySurfer: That should work, AFAIK [14:15] thanks. [14:15] HippySurfer: Do a remove-tree on the folder first and save yourself the space (unless there are unsaved changes) [14:15] fullermd: that should work I think, thanks :) [14:15] good point. [14:21] fullermd: is it possible to merge your changes into the external branch, rather than the other way around? [14:22] 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] 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] (and anyway, you'd have to poke around $wherever to verify the changes and commit them anyway) [14:24] awilkins: but can you push uncomitted changes? [14:24] No. Push pushes revisions; it there's no revision, it can't be pushed (pash?) [14:26] can i merge --uncommited -d to a remote (as in, not on the local filesystem) branch? [14:27] No, working trees can only be accessed locally. [14:27] 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] i don't think that's going to help me [14:30] i'm trying to keep a working copy synchonized over several machines, while retaining the proper merging bazaar provides [14:30] without abusing commits just to synchonize [14:31] any ideas on how to accomplish this? [14:37] 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] why? [14:38] what's wrong with what i'm trying to do? [14:38] 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. === bronger is now known as Torsten [14:40] 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] In particular, i often need to synchonize something that isn't a logical atomic change, and therefore shouldn't be a commit [14:43] 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] 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] That's what revisions are for after all. [14:45] 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] 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] It could be done without screwing things up, but yes, it would take a bit of rather careful (which means 'fragile') handwork. [14:47] 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] '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] that could work, but there's a requirement that complicates things: [14:49] i don't want any of those synchonization-commits to show up in the public logs [14:49] [of the main repository] [14:50] since they often contain testing files containing passwords etc. [14:51] 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. === thunderstruck is now known as gnomefreak === thunderstruck is now known as gnomefreak [15:26] 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] does anyone know if the trac-bzr plugin supports remote repositories? [15:27] currently my bzr repository is hosted on a different server to my trac install [15:31] semslie, In theory I think it should, but it would be unworkably slow. [15:31] jelmer: well, thats a pretty convincing argument against. I'll try to set things up more sensibly instead. [15:42] 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] Well, you could use --no-backup to make it not create a backup file. [15:43] mdmkolbe, it's the default [15:44] 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] .~whatever files are ignored. [15:46] fullermd: yes, but is there a way to (temporarily) make them not ignored? [15:48] No. You could just whack 'em with find, or finger your way through bzr ignored. [15:49] fullermd: it looks like bzr ignored will do just what I need, thx [15:54] bug #288751 [15:54] Launchpad bug 288751 in bzr "bzr push returns error Revision not in " [Undecided,New] https://launchpad.net/bugs/288751 [15:54] just got that using 1.9dev [15:54] Using saved push location: bzr+ssh://jdobrien@bazaar.launchpad.net/~jdobrien/ubunet/subscription-payments [15:54] bzr: ERROR: Revision {jdo@canonical.com-20081006141744-k8myay8ls316o14y} not present in "purchase.py-20080823031523-leymwbfdmocqr4fp-4". === thekorn_ is now known as thekorn [16:09] I think I might have asked this yesterday, but how do I convert a git repository to a Bazaar one? [16:10] was it fastimport? [16:11] RaceCondition: Yes. [16:12] so bzr init mybranch; cd mybranch; bzr fastimport ../mygitrepo/? [16:16] hmm, I branched bzr-fastimport, but python setup.py install not easy_install . do not work [16:16] python setup.py install gives no ouput, easy_install complains [16:16] No eggs found in /Users/erik/bzr/fastimport/egg-dist-tmp-uIh1Oe (setup script problem?) [16:17] RaceCondition: it's a bzr plugin, drop it in ~/.bazaar/plugins [16:17] named as "fastimport" [16:17] oh [16:17] the fastimport module, right? not the whole branch [16:17] hmm, there is no fastimport module [16:18] no, the whole branch [16:18] got it [16:23] nice, it worked [16:23] although it went crazy when I accidentially did git fast-export -all instead of --all === thunderstruck is now known as gnomefreak [16:46] does bzr-upload also upload files that are not under version control? === sdboyer is now known as sdboyer|class [16:54] RaceCondition, no [17:03] beuno: weird, it did upload a file that was NOT under version control [17:03] but that was the initial upload, following ones might be different === mark1 is now known as markh === sdboyer|class is now known as sdboyer [19:08] Hi. How do I get all patches committed by user foo? [19:09] including a summary, a patch name, and possibly the full diff as well? === Kinnison is now known as dsilvers === dsilvers is now known as Kinnison === mw is now known as mw|food [19:58] OK, I'm encountering a weird issue. [19:58] when I run bzr (no arguments) in a directory that contains a .pyc file, that .pyc file is executed. [20:00] OK, this isn't just a .pyc file: it works if the directory contains a .py file. [20:00] i.e. same problem. [20:00] anyone knows why that is? [20:01] the problem seems to be caused by a file called parser.py [20:08] fynn: I'm guessing you are on windows? [20:08] jam: nope, Ubuntu Hardy. [20:09] hmm... we *do* "import parser" in 'bzrlib.tests.test_source' because 'parser' is a module that is part of the standard library [20:09] so you naming a file the same as a standard lib isn't a great thing to do [20:09] however, '.' shouldn't be on our search path [20:09] by default it isn't [20:10] there were some problems with /usr/lib/python2.x/site.py [20:10] which was accidentally including '' into the default search path [20:10] but IIRC that was only on win32 [20:10] fynn: can you try: "python -c 'import sys, pprint; pprint.pprint(sys.path)" and paste the output? [20:10] jam: here's a simple, straightforward reproduction of the problem: [20:10] http://dpaste.com/86633/ [20:11] 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] jam: http://dpaste.com/86634/ [20:13] fynn: notice the '' as the first entry [20:13] jam: I suspect the problem is ... right [20:13] I thought that was normal for PYTHONPATH? [20:13] fynn: you have "PYTHONPATH=''" ? [20:13] or do you have it something like "PYTHONPATH='something:'" [20:13] with a trailing ':' [20:13] anyway, you could hack the bzr startup script with [20:14] import sys [20:14] if '' in sys.path: [20:14] sys.path.remove('') [20:14] but you may want to try and debug how '' is being put into your path [20:14] jam: no, I'm not changing PYTHONPATH at all. [20:15] s/changing/setting/ [20:15] fynn: ah wait a sec, part of the issue is that 'python -c' is running in the local working directory [20:15] so yeah, it adds '' [20:15] can you try adding the 'pprint' stuff to your 'bzr' script? [20:15] where is that? [20:16] fynn: probably /usr/bin/bzr [20:17] you can just copy it somewhere else if you don't want to modify it there [20:17] cp /usr/bin/bzr ~/bzr [20:17] and then test it with ~/bzr [20:19] jam: it adds the CWD as the first entry. [20:19] fynn: it should add the directory of the 'bzr' script, but not CWD [20:19] you are seeing "CWD" always be added? [20:20] well, CWD not the literal 3-letter string :) [20:22] jam: yes. [20:23] the first entry on the sys.path seems to consistently be CWD. [20:24] fynn: just to cover all bases, here is a test script [20:24] http://dpaste.com/86640/ [20:24] can you copy that into a file like "test.py" [20:24] and then run it as [20:24] cd .. [20:24] python directory/test.py [20:24] and see if it has CWD or only CWD/directory in the search path [20:25] and assuming that fails like the rest [20:25] then it is something with your python installation [20:25] and that takes a bit more to debug [20:30] jam: $ cat bar.py [20:30] import sys, pprint [20:30] pprint.pprint(sys.path) [20:30] loggerhead just made it into unstable. \o/ [20:30] 20:26:03 < BTS> loggerhead (NEW) 1.6-1 uploaded by Jelmer Vernooij (Closes: #492477) http://packages.qa.debian.org/loggerhead [20:31] jam: $ python bar.py [20:31] ['/home/xif', [20:31] ... [20:31] fynn: that is expected. And if you run it from another directory? [20:32] jam: same behavior: [20:32] ['/home/xif/foo', [20:33] fynn: '/home/xif' is also in the path, right? [20:33] jam: if I run it from a different directory? no, it's not. [20:33] (the directory containing the script should always be added, and CWD should not. Unless, of course, the script is *in* CWD) [20:33] ah, one second then. [20:34] jam: OK, I checked [20:34] 1) the CWD is always added [20:35] (as the first entry in sys.path) [20:35] 2) the script directory is added as well, but not as the first entry. [20:35] 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] fynn: you can try editing /usr/lib/python2.5/site.py [20:37] for example, there is a function "removeduppaths" [20:37] my guess is that it will end up having a '' in sys.path [20:37] which gets expanded to CWD [20:37] just before line 95 or so there is "sys.path[:] = L" [20:37] you could add [20:38] import pprint; pprint.pprint(sys.path); pprint.pprint(L) [20:38] and then paste that [20:38] that will tell us what paths remove dup paths is getting, and what it is setting it to [20:39] 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] jam: you want me to add that debugging line before or after "sys.path[:] = L"? [20:40] (that's not it: I tried it from several newly-created directories) [20:40] fynn: *before* that line [20:40] fynn: the foo.pth is in some /usr/lib/* location [20:41] well, a "rogue foo.pth" would be there [20:41] OK, line 100-101 now looks like this: [20:41] (100-101 in my site.py) [20:41] import pprint; pprint.pprint(sys.path); pprint.pprint(L) [20:41] sys.path[:] = L [20:41] fynn: right [20:41] now try running bar.py or bzr [20:42] hm, running 'python -c "pass"' doesn't do a thing. [20:43] I would have expected a printout. [20:45] jam: possibly stdout for site.py is suppressed. [20:47] fynn: well looking here if I add "print testing" to site.py it shows up [20:47] it may be that 'removeduppaths' isn't getting called [20:48] fynn: you might try looking at the 'def main()' function [20:48] and adding some debugging there [20:49] fynn: also are you editing 'site.py' in place, or in a local copy? [20:49] jam: OK, thanks. I guess I should try that. [20:49] A local copy won't be run [20:49] editing it in place, of course :) [20:50] jam: this is a fairly vanilla Hardy installation, so I'd suspect I'm not the only one seeing this. [20:50] fynn: the first *I've* seen :) [20:51] and as all python programs would suffer similar issues... [20:52] hm, I guess it _could_ be my setup. [20:52] would debug this a bit more when I have the time. === mw|food is now known as mw