| dark_soul | bzr whoami 'your info' | 00:01 |
|---|---|---|
| dark_soul | in case someone is interested | 00:01 |
| Boobek | bye | 01:22 |
| === nlisgo_ is now known as nlisgo | ||
| l0de | The l0de radio hour is now online! stream up at www.klulz.com , call in live at 914 502 2625! Tonight's Episode: THE DOWNTOWN MOTOWN SHOWDOWN AND THROWDOWN SO BRING YA HOW DOWN NIGGA U BOUT TO GET CLOWNED | 06:03 |
| bignose | Committing to a particular remote repository gives: | 07:23 |
| bignose | Doing on-the-fly conversion from RepositoryFormatKnitPack4() to RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n'). | 07:23 |
| bignose | This may take some time. Upgrade the repositories to the same format for better performance. | 07:23 |
| bignose | but when I attempt to upgrade it, Bazaar asserts there's nothing to do: | 07:24 |
| bignose | $ bzr upgrade --format 2a bzr+ssh://bzr.debian.org/bzr/collab-maint/python-daemon/python-daemon.debian/ | 07:24 |
| bignose | bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format. | 07:24 |
| lifeless | bignose: are you upgradeing a branch perhaps | 07:24 |
| lifeless | oh | 07:24 |
| lifeless | bignose: the remote repository is 21 | 07:24 |
| lifeless | bignose: the *local* one isn't | 07:24 |
| lifeless | s/21/2a/ | 07:24 |
| bignose | hmm, checking | 07:25 |
| lifeless | thats the the mesage indicates | 07:25 |
| bignose | well spotted. but how did you spot that? | 07:25 |
| lifeless | the error string: RemoteRepositoryFormat(_network_name=...) - thats what repositories using a proxy object over bzr:// protocols show as | 07:26 |
| bignose | thanks. | 07:27 |
| lelit | hi all | 08:53 |
| lelit | I'm still in the process of converting a bunch of svn repo to bzr. The standalone repos seems in good shape, and I am now trying to group them with the "externals" plugin | 08:55 |
| lelit | I have a "metarepo" containing just external refs to a few repo | 08:56 |
| lelit | the test I did some days ago worked great, but now "suddenly" cloning such metarepo gives me a desolately empty repo, with 0 revision in it... it completely misses any ref to the externals | 08:58 |
| lifeless | lelit: your terminology is confusing me | 09:01 |
| lifeless | you can't clone repos in bzr | 09:01 |
| lelit | uhm, sorry lifeless, I'm still learning the new terminology :) | 09:03 |
| lelit | isn't "clone" an alias of "branch"? | 09:03 |
| lifeless | yes | 09:03 |
| lelit | this is my migration script: http://pastebin.com/vd7KBEmG | 09:03 |
| lifeless | a repository is just a database | 09:03 |
| lifeless | it can't be pushed/branched/cloned/anything | 09:04 |
| lelit | ah, so what I call "repository" is a "branch" instead? | 09:04 |
| lelit | you know, I'm coming from darcs, where there isn't such distinction | 09:05 |
| lifeless | I would guess; you're the one that knows what you mean :) | 09:05 |
| lelit | :) | 09:05 |
| lelit | ok | 09:05 |
| lelit | the script above will create a "metarepo", containing .bzrmeta/externals pointing to the bzr-based branches of my svn repos | 09:07 |
| lelit | but when I "cd /tmp; bzr branch .../metarepo" I don't get those | 09:07 |
| lelit | I'm just blind :) | 09:11 |
| lelit | I need to commit, after all those eadds! :-) | 09:11 |
| lelit | sorry, caffeine is not circulating yet | 09:11 |
| lelit | gosh, this works ok on bzr 2.1.1, but fails with 2.0.1 | 09:17 |
| lifeless | ok | 09:31 |
| lifeless | well 2.1.1 is nice ;) | 09:31 |
| lelit | http://pastebin.com/DK73EFtY | 09:41 |
| lelit | eh! unfortunately on debian/lenny there is 2.0.3 in backports | 09:42 |
| thumper | lifeless: the config object passed into Commit.commit is ignored | 10:11 |
| thumper | lifeless: is that right? | 10:11 |
| lifeless | thumper: no; but you should be calling tree.commit, not Commit.commit | 10:14 |
| thumper | lifeless: I am | 10:15 |
| thumper | but I'm following the path through | 10:15 |
| thumper | MutableTree.commit calls Comit().commit(... | 10:15 |
| thumper | the Commit object __init__ method can set self.commit | 10:15 |
| thumper | the config object passed in to the commit method of Mutable tree seems to be ignored to me | 10:16 |
| thumper | ... | 10:16 |
| thumper | not mutable tree | 10:16 |
| thumper | the Commit._commit method | 10:16 |
| thumper | I'm wanting to set the committer of the revision to be wikkid, but the author to be the author | 10:17 |
| lifeless | thumper: its a regression | 10:17 |
| lifeless | added by spivs run_cleanups stuff | 10:17 |
| thumper | hmm... | 10:18 |
| thumper | lifeless: how can I set the signing policy for a branch? | 10:18 |
| lifeless | thumper: well, I say regression | 10:19 |
| lifeless | its an ambiguous interface | 10:19 |
| lifeless | :q | 10:19 |
| thumper | it should use the passed in config like the reporter several lines above | 10:19 |
| lifeless | no | 10:19 |
| lifeless | ambiguous like I say | 10:19 |
| thumper | why not? | 10:19 |
| lifeless | hang a sec | 10:19 |
| thumper | I'm thinking line 347 of bzrlib/commit.py | 10:20 |
| lifeless | http://pastebin.com/hxtjLNp0 | 10:20 |
| lifeless | apply that patch | 10:20 |
| thumper | I'll work around it for now, hopefully by setting the branch signing policy | 10:21 |
| lifeless | please don't | 10:21 |
| lifeless | its a regression, I'm just submitting the fix | 10:21 |
| thumper | funny, yesterday you were saying don't override the config | 10:22 |
| lifeless | I still say that | 10:22 |
| lifeless | but my point is to honour what the user has configured | 10:22 |
| thumper | if it is operating as a webapp, that is a very bad idea | 10:22 |
| lifeless | if you are going to override it, passing in a new object is the cleanest way IMO | 10:22 |
| lifeless | thumper: sysadmins are users too | 10:23 |
| thumper | I don't get the reference | 10:23 |
| lifeless | if its running as a webapp | 10:23 |
| lifeless | then the configuring person is the sysadmin | 10:23 |
| thumper | right | 10:23 |
| lifeless | who may well want commits on the server to be signed | 10:23 |
| thumper | but you don't want it prompting for a password | 10:23 |
| lifeless | *I* would | 10:23 |
| lifeless | why would it prompt in such a setup | 10:24 |
| thumper | fair call | 10:24 |
| thumper | I've added a TODO in the init method to allow using the users signing policy | 10:24 |
| thumper | I intend to honour it | 10:24 |
| thumper | just not right now | 10:24 |
| lifeless | see, it seems to me you are adding code you don't need to | 10:25 |
| lifeless | thats my whole point here | 10:25 |
| thumper | well, right now I don't want to change my default config | 10:25 |
| thumper | I have signing on | 10:25 |
| lifeless | don't change it | 10:25 |
| lifeless | you can override for your test wikis in 2 lines in ~/.bazaar/locations.conf | 10:25 |
| thumper | which is way I said before, how do I set the signing policy for a branch | 10:25 |
| lifeless | or in branch.conf | 10:26 |
| lifeless | review wanted: https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/23150 | 10:26 |
| thumper | does branch.conf go with the branch? | 10:26 |
| thumper | on push? | 10:26 |
| lifeless | no | 10:26 |
| lifeless | but I'm not sure how that affects your dev environment | 10:26 |
| thumper | it doesn't | 10:27 |
| thumper | I was just wondering | 10:27 |
| lifeless | I'd like to have some stuff propogate | 10:27 |
| lifeless | currently nothign does | 10:27 |
| lifeless | what would you need to be happy with its behaviour for you ? | 10:28 |
| lifeless | no signing for wikki branches? | 10:28 |
| lifeless | thumper: ^ | 10:29 |
| thumper | I'd like it to work as people expect | 10:30 |
| lifeless | ok, me too :) | 10:30 |
| lifeless | *I* expect things using bzr to honour my bzr settings. | 10:30 |
| thumper | I found it surprising that it asked me to sign my commit when I hit save on the webpage | 10:30 |
| lifeless | but you seem to be annoyed that you're getting signing prompts | 10:31 |
| lifeless | so I'd like to teach you how to turn that off, for your wikis. | 10:31 |
| thumper | just in locations.conf? | 10:31 |
| lifeless | thats what I | 10:31 |
| lifeless | thats what I'd reach for first in this case, I think. | 10:31 |
| thumper | I'll go with that for now | 10:31 |
| thumper | I agree that in a server setting it would make sense to use the config settings | 10:32 |
| lifeless | [file:///tmp] | 10:32 |
| lifeless | create_signatures = never | 10:32 |
| thumper | I'll go with honouring bzr expectations | 10:32 |
| lifeless | what bzrlib do you have installed btw | 10:34 |
| thumper | nightly ppa | 10:34 |
| abli | Hi! If I created a branch in a shared repository, do I need to do anything special when I want to delete it? or simply rm-ing the directory will do? | 10:40 |
| thumper | abli: that works | 10:46 |
| thumper | abli: it won't however remove the revisions from the repository | 10:46 |
| abli | where are the revisions actually stored? in the repo's .bzr, so the branch-directories' .bzr contains no revision data, only some metadata? | 10:47 |
| lifeless | right | 10:48 |
| lifeless | thumper: http://pqm.bazaar-vcs.org/ | 10:48 |
| abli | Would deleting the branch now and later creating a branch with the same name be a problem? (Storing the revisions is not a problem in my case because they are quite small, so I won't care about the wasted space), but I want to avoid confusing people with old and obsolete branches | 10:49 |
| lifeless | thumper: have you seen the progress bar ? :) | 10:49 |
| lifeless | abli: no problem | 10:49 |
| thumper | lifeless: nice | 10:49 |
| lifeless | abli: or at least, no technical problems. *you* might get confused though | 10:49 |
| lifeless | thumper: subunit :) | 10:49 |
| abli | you mean if I create a branch with the same name, revisions from the old branch will come back? | 10:50 |
| lifeless | abli: no | 10:50 |
| lifeless | abli: I mean you might not remember if its the old or new branch, in a couple of weeks time :> | 10:50 |
| abli | oh. Ok, I'll remember to keep that straight then. | 10:50 |
| abli | Thanks everyone! | 10:51 |
| sipsniffa | testing the addition of files from within the current project directory and below using: bzr add --dry-run **/*.py | 11:07 |
| sipsniffa | none of *.py in the current directory get added. am i missing something? | 11:07 |
| lifeless | sipsniffa: your shell isn't matching them | 11:08 |
| sipsniffa | i understand ** to mean zero or more | 11:08 |
| lifeless | sipsniffa: any reason you don't just do 'bzr add' ? | 11:08 |
| lifeless | sipsniffa: and let bzr find all unignored files and add them for you | 11:08 |
| sipsniffa | i can drop the ** from **/*.py and get all the current directory py files | 11:08 |
| sipsniffa | probably the only reason is that i'm unfamiliar with bzr conventions and ways of working | 11:09 |
| lifeless | sipsniffa: the usual way is to setup bzr ignore rules for things you don't want to version | 11:09 |
| lifeless | and use 'bzr add' - just that - to add things automatically | 11:10 |
| sipsniffa | ok, will go that route | 11:10 |
| sipsniffa | still curious to know whether ** pattern matching is misbehaving | 11:10 |
| lifeless | check your shell's man page | 11:10 |
| lifeless | its outside bzr's control, unless you are on windows | 11:10 |
| sipsniffa | i've done bzr help patterns | 11:11 |
| lifeless | on windows bzr does the expansion | 11:11 |
| sipsniffa | linux | 11:11 |
| lifeless | right | 11:11 |
| lifeless | bzr doesn't see the **/*.py | 11:11 |
| lifeless | if you look in ~/.bzr.log | 11:11 |
| lifeless | you can see the command line bzr is being given | 11:11 |
| lifeless | your shell - e.g. bash, or zsh, or whatever - is expanding the **/*.py | 11:12 |
| sipsniffa | k, just tried quoting the pattern: bzr add --dry-run '**/*.py' | 11:13 |
| lifeless | bzr won't glob expand though :) | 11:14 |
| lifeless | that will add the file '**/*.py', if you had one | 11:14 |
| sipsniffa | gives an error! | 11:14 |
| lifeless | as I said, you need to check the documentation for your shell under 'GLOBBING' | 11:14 |
| sipsniffa | k | 11:15 |
| sipsniffa | thanks for the pointers, lifeless | 11:15 |
| bialix | igc: ping | 14:11 |
| igc | hi bialix | 14:32 |
| bialix | igc: what dependecies I should install? | 14:33 |
| igc | bialix: for the installer stuff? | 14:34 |
| bialix | yes, you have asked me to look at bzr-windows-installer script | 14:34 |
| igc | if you have the latest stuff, it will build the windows help but it expects ... | 14:35 |
| igc | sphinx 0.6 and make | 14:35 |
| bialix | I'm lacking the fresh info about bzr build dependencies | 14:35 |
| igc | http://wiki.bazaar.canonical.com/BzrWin32Installer is the place to start | 14:36 |
| igc | but you no longer need pycurl and cog | 14:36 |
| igc | and zlib gets installed for you | 14:37 |
| igc | bialix: any particular questions? I'm heading to sleep real soon now | 14:38 |
| bialix | that page is awfully outdate as I can see | 14:38 |
| igc | yes, I've been meaning to update it :-( | 14:38 |
| igc | next week hopefully | 14:38 |
| bialix | I don't have questions because I'm trying to figure out what I need to install | 14:39 |
| igc | do you have the old stuff installed still? | 14:39 |
| igc | the key bits are ... | 14:39 |
| bialix | no, for python 2.6 I have nothing | 14:39 |
| igc | python + pytqt + paramiko + sphinx + ms help compiler + innosetup | 14:40 |
| bialix | ms help compiler? | 14:40 |
| igc | for sphinx, start with setuptools, then easy_install it | 14:40 |
| bialix | C compiler? | 14:40 |
| igc | yes, you'll need one, either visual C or Mingw32 | 14:41 |
| igc | also pyrex | 14:41 |
| bialix | can you put the dependencies version to simpleplain text file in the branch with script? | 14:41 |
| bialix | maybe tomorrow or the next week, maybe | 14:42 |
| igc | yes, that's the plan | 14:42 |
| igc | bialix: http://www.microsoft.com/downloads/details.aspx?familyid=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en | 14:44 |
| bialix | igc: so perhaps we need to continue this odissey tomorrow or then next week, good night! | 14:49 |
| igc | bialix: I'll type something up tomorrow if I can | 14:50 |
| igc | bialix: night | 14:50 |
| bialix | that's ok, sleep well | 14:50 |
| * fullermd sure is glad to be on a *nix system :p | 14:55 | |
| bialix | fullermd: :-P | 14:59 |
| jml | I accidentally resolved a directory conflict by deleting the directory | 15:06 |
| jml | the commit that did that is way back in the history of my branc | 15:06 |
| jml | but it turns out that the project won't build without this (empty!) directory | 15:07 |
| jelmer | jml: can't you just re-add it with the same file id? | 15:07 |
| jml | jelmer, same file id? I didn't know you could do that | 15:07 |
| jml | jelmer, how would I do that? | 15:08 |
| jelmer | jml: you can't really specify a file id, but you can have 'bzr add' use the file id the same path has in another tree | 15:08 |
| jelmer | jml: so if you have an old copy of lp around you can use 'bzr add --file-ids-from=lp:launchpad/devel path/to/empty/dir' | 15:08 |
| fullermd | Easier to use revert. | 15:09 |
| fullermd | Just find a rev where it existed and revert -rwhatever dir | 15:09 |
| jelmer | fullermd: that won't readd the dir though right? | 15:13 |
| jelmer | fullermd: and if it's not added to the working tree, it won't have a file id | 15:13 |
| fullermd | Er, it certainly SHOULD. | 15:13 |
| fullermd | It works fine on FILES. And dirs are just files in pink tutus. | 15:14 |
| fullermd | If it doesn't, that's a glaring bug that needs to be fixed. | 15:14 |
| sebi_` | what would be the reason for bzr not to upload certain files and/or directories when pushing a revision? I had to repush for the third time now. note that all files and directories are read and writable, and owned by my systemuser | 15:22 |
| bialix | sebi_`: bzr does not update remote working tree usually, only those on the local disk | 15:23 |
| sebi_` | okay | 15:23 |
| sebi_` | well, some of the files in the revision were empty, even though they aren't in the local source tree | 15:24 |
| jelmer | fullermd: you're right sorry. I never use revert with -r | 15:24 |
| sebi_` | ah well. if that's the only thing i'll have to live with, then i'll live with it. :P | 15:24 |
| bialix | sebi_`: if you need to upload files to remote location look at bzr-upload plugin | 15:36 |
| sebi_` | I was just talking about `bzr push $branch`, but i'll take a look at the bzr-upload plugin | 15:37 |
| bialix | there is also push-and-update plugin | 15:49 |
| MvG | FYI: I've just released version 1.1.0 of the bzr-bash-completion plugin, including completion for registry-based options. | 16:48 |
| jelmer | MvG: nice | 16:48 |
| MvG | I've also filed bug #560030 to get something done about the horribly outdated completion scripts included in the bzr source tree. If you want to discuss it, I'm all ears. | 16:49 |
| ubottu | Launchpad bug 560030 in bzr "Shell completion scripts outdated" [Undecided,New] https://launchpad.net/bugs/560030 | 16:49 |
| MvG | I'd be particularly interested in opinions as to whether bzr-bash-completion should be included with bzr itself, either now or in the forseeable future. I have no strong opinion either way, but it has been suggested to me by users, and I'd like to know what you think. | 16:51 |
| jelmer | doesn't bash itself also ship with some completion scripts? | 16:52 |
| jelmer | I think it should be shipped either with bzr or with bash | 16:52 |
| MvG | I assume that the bash progcomp api is far more stable and also a lot simpler than the bzr plugin and options api. Therefore I'd keep it with bzr. | 16:54 |
| MvG | I don't think bash ships anything related to bzr, but I'll check. I know zsh does ship a completion function. | 16:55 |
| MvG | Nope, neither bash 4.1 nor bash-completion 1.1 (from http://bash-completion.alioth.debian.org/ ) ship anything bzr-ish. | 16:58 |
| MvG | By the way: what are the steps turning a merge proposal at LP into an actual merge performed by PQM? And which of these steps are automatic? Do I need a certain number of approving comments, or approval by the right person, or either of these? Is there some document outlining this process? | 17:00 |
| jelmer | MvG: you need to approvals from bzr committers | 17:01 |
| jelmer | MvG: s/to/two/ | 17:01 |
| jelmer | MvG: the merge is submitted manually by a pqm committer, usually through "bzr lp-land" or pqm-feed (from hydrazine) | 17:01 |
| MvG | Thanks! | 17:02 |
| RobOakes | Hi, I am getting a very strange error when I try and import from an SVN repository. bzr: ERROR: Unable to convert Subversion path help/hits/LaTeX\docs because it contains characters invalid in Bazaar. | 18:21 |
| RobOakes | Does anyone know how I can by-pass this error? The file it references is a documentation file and not really important to my merge. | 18:21 |
| jelmer | RobOakes: Bazaar doesn't allow backslashes in paths | 18:40 |
| RobOakes | Is there any way that I can exclude that one file? Or can I update just the project src directory? | 18:40 |
| jelmer | RobOakes: I think the only real option is to use something like fastexport/fastimport that allows you to remove the backslash from the stream before importing it into bazaar | 18:41 |
| RobOakes | Do you know if there is a tutorial that explains how to do that? (I'm a pretty novice bzr user.) | 18:42 |
| jelmer | I'm not aware of one, but that doesn't say a lot. | 18:42 |
| RobOakes | Any idea on how I could use fastexport/fastimport to do what you describe? | 18:44 |
| RobOakes | I'm trying to merge bugfixes made to an svn version of the bzr branch. | 18:44 |
| RobOakes | Thanks, I found a way around the problem. There are only a few folders that I need to merge. The merge works if I only update those selected folders. | 18:55 |
| sebi_` | okay, I think i've figured out why some files were missing when pusing a new revision; I forgot to add them. :P | 19:21 |
| === radoe_ is now known as radoe | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!