| === Hydrogen is now known as hYDROGEN | ||
| === RAOF_ is now known as RAOF | ||
| === hYDROGEN is now known as Wasserstoff | ||
| Verterok | -DartifactId=maven-emma-plugin | 06:00 |
|---|---|---|
| vila | hi all | 07:07 |
| phoku | hi there | 07:13 |
| 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:42 |
| lifeless | probably a binary file | 08:43 |
| lifeless | or a parallel add | 08:43 |
| matkor | mhmmm ... its py file so popably parallel add ... thanks lifeless | 08:44 |
| 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 | 08:45 |
| 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:21 |
| === sabdfl1 is now known as sabdfl_epic | ||
| lifeless | fullermd: no, it warns clearly on that case | 09:29 |
| lifeless | I think | 09:29 |
| fullermd | No, it just says 'Contents conflict, with foo.OTHER add'd and foo.BASE unknown. | 10:00 |
| Odd_Bloke | jelmer: I'm getting a "SubversionException: ("Can't get entries of non-directory", 160016)", what might be causing that? | 10:37 |
| === doko_ is now known as doko | ||
| Odd_Bloke | jelmer: This is when doing a "$ bzr branch svn://svn.debian.org/svn/pkg-voip/freepbx/trunk freepbx" BTW. | 10:40 |
| 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. | 10:46 |
| 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:42 |
| 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:56 |
| 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:57 |
| Odd_Bloke | jelmer: Will do. | 11:59 |
| matkor | awilkins: Thanks ! | 12:08 |
| 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:10 |
| awilkins | matkor: for the deletion revision, you have to run the full log | 12:13 |
| 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:15 |
| 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:16 |
| Kinnison | if you've not pushed that, uncommit, pick them out, revert and start again | 12:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| Pieter | right | 12:25 |
| Pieter | http://pastie.org/299589 | 12:25 |
| Pieter | nice :) | 12:25 |
| Peng_ | Pieter: The bad URL being given by break-lock is known (bug 250451). | 12:43 |
| ubottu | 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:43 |
| mwhudson | so the launchpad plugin doesn't seem to cope with random network suckage all that well | 12:44 |
| mwhudson | gar | 14:07 |
| mwhudson | when will ~ work in bzr+ssh urls? | 14:08 |
| awilkins | When a developer gets annoyed enough by it to patch it, I suspect | 14:09 |
| 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:10 |
| RedLizard | is it possible to synchonize working copies using bazaar without committing the changes? | 14:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| RedLizard | fullermd: is it possible to merge your changes into the external branch, rather than the other way around? | 14:21 |
| 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:22 |
| fullermd | (and anyway, you'd have to poke around $wherever to verify the changes and commit them anyway) | 14:23 |
| 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:24 |
| RedLizard | can i merge --uncommited -d to a remote (as in, not on the local filesystem) branch? | 14:26 |
| 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:27 |
| RedLizard | i don't think that's going to help me | 14:29 |
| 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:30 |
| RedLizard | any ideas on how to accomplish this? | 14:31 |
| 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:37 |
| 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:38 |
| === bronger is now known as Torsten | ||
| 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:40 |
| RedLizard | In particular, i often need to synchonize something that isn't a logical atomic change, and therefore shouldn't be a commit | 14:42 |
| 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:43 |
| 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:45 |
| fullermd | It could be done without screwing things up, but yes, it would take a bit of rather careful (which means 'fragile') handwork. | 14:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| RedLizard | since they often contain testing files containing passwords etc. | 14:50 |
| 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. | 14:51 |
| === thunderstruck is now known as gnomefreak | ||
| === thunderstruck is now known as gnomefreak | ||
| 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:26 |
| semslie | currently my bzr repository is hosted on a different server to my trac install | 15:27 |
| 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:31 |
| 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:42 |
| fullermd | Well, you could use --no-backup to make it not create a backup file. | 15:43 |
| jelmer | mdmkolbe, it's the default | 15:43 |
| 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:44 |
| fullermd | .~whatever files are ignored. | 15:45 |
| mdmkolbe | fullermd: yes, but is there a way to (temporarily) make them not ignored? | 15:46 |
| fullermd | No. You could just whack 'em with find, or finger your way through bzr ignored. | 15:48 |
| mdmkolbe | fullermd: it looks like bzr ignored will do just what I need, thx | 15:49 |
| jdo | bug #288751 | 15:54 |
| ubottu | Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Undecided,New] https://launchpad.net/bugs/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". | 15:54 |
| === thekorn_ is now known as thekorn | ||
| RaceCondition | I think I might have asked this yesterday, but how do I convert a git repository to a Bazaar one? | 16:09 |
| RaceCondition | was it fastimport? | 16:10 |
| Odd_Bloke | RaceCondition: Yes. | 16:11 |
| RaceCondition | so bzr init mybranch; cd mybranch; bzr fastimport ../mygitrepo/? | 16:12 |
| 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:16 |
| 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:17 |
| james_w | no, the whole branch | 16:18 |
| RaceCondition | got it | 16:18 |
| RaceCondition | nice, it worked | 16:23 |
| RaceCondition | although it went crazy when I accidentially did git fast-export -all instead of --all | 16:23 |
| === thunderstruck is now known as gnomefreak | ||
| RaceCondition | does bzr-upload also upload files that are not under version control? | 16:46 |
| === sdboyer is now known as sdboyer|class | ||
| beuno | RaceCondition, no | 16:54 |
| 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 | 17:03 |
| === mark1 is now known as markh | ||
| === sdboyer|class is now known as sdboyer | ||
| fynn | Hi. How do I get all patches committed by user foo? | 19:08 |
| fynn | including a summary, a patch name, and possibly the full diff as well? | 19:09 |
| === Kinnison is now known as dsilvers | ||
| === dsilvers is now known as Kinnison | ||
| === mw is now known as mw|food | ||
| 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. | 19:58 |
| 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:00 |
| fynn | the problem seems to be caused by a file called parser.py | 20:01 |
| jam | fynn: I'm guessing you are on windows? | 20:08 |
| fynn | jam: nope, Ubuntu Hardy. | 20:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| jam | fynn: probably /usr/bin/bzr | 20:16 |
| 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:17 |
| 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:19 |
| jam | well, CWD not the literal 3-letter string :) | 20:20 |
| fynn | jam: yes. | 20:22 |
| fynn | the first entry on the sys.path seems to consistently be CWD. | 20:23 |
| 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:24 |
| 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:25 |
| 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:30 |
| 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:31 |
| fynn | jam: same behavior: | 20:32 |
| fynn | ['/home/xif/foo', | 20:32 |
| 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:33 |
| fynn | jam: OK, I checked | 20:34 |
| fynn | 1) the CWD is always added | 20:34 |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| fynn | hm, running 'python -c "pass"' doesn't do a thing. | 20:42 |
| fynn | I would have expected a printout. | 20:43 |
| fynn | jam: possibly stdout for site.py is suppressed. | 20:45 |
| 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:47 |
| jam | fynn: you might try looking at the 'def main()' function | 20:48 |
| jam | and adding some debugging there | 20:48 |
| 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:49 |
| 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:50 |
| jam | and as all python programs would suffer similar issues... | 20:51 |
| fynn | hm, I guess it _could_ be my setup. | 20:52 |
| fynn | would debug this a bit more when I have the time. | 20:52 |
| === mw|food is now known as mw | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!