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