[00:01] <dark_soul> bzr whoami 'your info'
[00:01] <dark_soul> in case someone is interested
[01:22] <Boobek> bye
[06:03] <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
[07:23] <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:24] <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:25] <bignose> hmm, checking
[07:25] <lifeless> thats the the mesage indicates
[07:25] <bignose> well spotted. but how did you spot that?
[07:26] <lifeless> the error string: RemoteRepositoryFormat(_network_name=...) - thats what repositories using a proxy object over bzr:// protocols show as
[07:27] <bignose> thanks.
[08:53] <lelit> hi all
[08:55] <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:56] <lelit> I have a "metarepo" containing just external refs to a few repo
[08:58] <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
[09:01] <lifeless> lelit: your terminology is confusing me
[09:01] <lifeless> you can't clone repos in bzr
[09:03] <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:04] <lifeless> it can't be pushed/branched/cloned/anything
[09:04] <lelit> ah, so what I call "repository" is a "branch" instead?
[09:05] <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:07] <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:11] <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:17] <lelit> gosh, this works ok on bzr 2.1.1, but fails with 2.0.1
[09:31] <lifeless> ok
[09:31] <lifeless> well 2.1.1 is nice ;)
[09:41] <lelit> http://pastebin.com/DK73EFtY
[09:42] <lelit> eh! unfortunately on debian/lenny there is 2.0.3 in backports
[10:11] <thumper> lifeless: the config object passed into Commit.commit is ignored
[10:11] <thumper> lifeless: is that right?
[10:14] <lifeless> thumper: no; but you should be calling tree.commit, not Commit.commit
[10:15] <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:16] <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:17] <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:18] <thumper> hmm...
[10:18] <thumper> lifeless: how can I set the signing policy for a branch?
[10:19] <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:20] <thumper> I'm thinking line 347 of bzrlib/commit.py
[10:20] <lifeless> http://pastebin.com/hxtjLNp0
[10:20] <lifeless> apply that patch
[10:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <lifeless> what would you need to be happy with its behaviour for you ?
[10:28] <lifeless> no signing for wikki branches?
[10:29] <lifeless> thumper: ^
[10:30] <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:31] <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:32] <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:34] <lifeless> what bzrlib do you have installed btw
[10:34] <thumper> nightly ppa
[10:40] <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:46] <thumper> abli: that works
[10:46] <thumper> abli: it won't however remove the revisions from the repository
[10:47] <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:48] <lifeless> right
[10:48] <lifeless> thumper: http://pqm.bazaar-vcs.org/
[10:49] <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:50] <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:51] <abli> Thanks everyone!
[11:07] <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:08] <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:09] <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:10] <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:11] <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:12] <lifeless> your shell - e.g. bash, or zsh, or whatever - is expanding the **/*.py
[11:13] <sipsniffa> k, just tried quoting the pattern: bzr add --dry-run '**/*.py'
[11:14] <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:15] <sipsniffa> k
[11:15] <sipsniffa> thanks for the pointers, lifeless
[14:11] <bialix> igc: ping
[14:32] <igc> hi bialix
[14:33] <bialix> igc: what dependecies I should install?
[14:34] <igc> bialix: for the installer stuff?
[14:34] <bialix> yes, you have asked me to look at bzr-windows-installer script
[14:35] <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:36] <igc> http://wiki.bazaar.canonical.com/BzrWin32Installer is the place to start
[14:36] <igc> but you no longer need pycurl and cog
[14:37] <igc> and zlib gets installed for you
[14:38] <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:39] <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:40] <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:41] <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:42] <bialix> maybe tomorrow or the next week, maybe
[14:42] <igc> yes, that's the plan
[14:44] <igc> bialix: http://www.microsoft.com/downloads/details.aspx?familyid=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en
[14:49] <bialix> igc: so perhaps we need to continue this odissey tomorrow or then next week, good night!
[14:50] <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:55]  * fullermd sure is glad to be on a *nix system   :p
[14:59] <bialix> fullermd: :-P
[15:06] <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:07] <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:08] <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:09] <fullermd> Easier to use revert.
[15:09] <fullermd> Just find a rev where it existed and revert -rwhatever dir
[15:13] <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:14] <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:22] <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:23] <bialix> sebi_`: bzr does not update remote working tree usually, only those on the local disk
[15:23] <sebi_`> okay
[15:24] <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:36] <bialix> sebi_`: if you need to upload files to remote location look at bzr-upload plugin
[15:37] <sebi_`> I was just talking about `bzr push $branch`, but i'll take a look at the bzr-upload plugin
[15:49] <bialix> there is also push-and-update plugin
[16:48] <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:49] <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:51] <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:52] <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:54] <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:55] <MvG> I don't think bash ships anything related to bzr, but I'll check. I know zsh does ship a completion function.
[16:58] <MvG> Nope, neither bash 4.1 nor bash-completion 1.1 (from http://bash-completion.alioth.debian.org/ ) ship anything bzr-ish.
[17:00] <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:01] <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:02] <MvG> Thanks!
[18:21] <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:40] <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:41] <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:42] <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:44] <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:55] <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.
[19:21] <sebi_`> okay, I think i've figured out why some files were missing when pusing a new revision; I forgot to add them. :P