=== ereslibre_uni is now known as ereslibre
[01:33] <MTecknology> Interesting error -   bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ubuntu-drupal-devs/ubuntu-drupal-locomap/6.x/.bzr/) is not compatible with CHKInventoryRepository('file:///home/michael/tmp/ubuntu-drupal-locomap/.bzr/repository/') different rich-root support
[03:50] <wgrant> Surprisingly little bzr-bashing on /. so far...
[03:51] <gutworth> some people don't like bazaar?
=== abentley1 is now known as abentley
[05:41] <akitada> Hi, can I edit history in bzr repository?
[05:55] <lifeless> wgrant: ?
[05:57] <wgrant> lifeless: The Slashdot article about Emacs moving to bzr has surprisingly little bzr bashing.
[06:12] <akitada> wgrant: that news made me feel like trying bzr for the first time
[06:13] <akitada> I use git and hg but haven't used bzr
[06:21] <akitada> still feeling bzr is a bit peculiar.
[10:25] <Wellark> could someone please explain to me how revision can have multiple parent_ids?
[10:27] <Peng> Wellark: A merge.
[10:41] <Wellark> Peng: OK, so the end result is that revision lists parent_id:s from both trees. makes sense. thanks! :)
[12:05] <__monty__> Hi, I'm having some trouble getting the bzr source code, could someone offer some help?
[12:05] <franck-bret> hello, does anyone can tell me how to have compatible repository with hardy server LTS (bzr 1.14) ?
[12:06] <Peng> franck-bret: Ideally you would use the PPA to install the latest version of bzr on it.......
[12:06] <Peng> franck-bret: If not, you should use the 1.14-rich-root format.
[12:08] <franck-bret> ive put my log here http://pastebin.com/d7bb155a7
[12:09] <Peng> franck-bret: Oh god, 1.3.1? Upgrade, dude.
[12:09] <franck-bret> it's a server with lastes UBUNTU LTS ...
[12:09] <Peng> franck-bret: And?
[12:10] <Peng> franck-bret: https://launchpad.net/~bzr/+archive/ppa
[12:10] <franck-bret> last bzr version for LTS isn't 2.**
[12:10] <Peng> franck-bret: So use the PPA.
[12:10] <__monty__> How do I get the bazaar source?
[12:11] <franck-bret> ok thanks, i'm gonna upgrade bzr, seems to be the more simple and evolutive way, thanks Peng
[12:11] <Peng> __monty__: "bzr branch lp:bzr" or download a tarball from the website.
[12:11] <bialix> __monty__: bazaar.canonical.com -> Download -> Sources
[12:11] <Peng> franck-bret: :)
[12:12] <__monty__> Can i use "bzr branch lp:bzr bzr.dev" to download the source to a folder named bzr.dev?
[12:12] <Peng> __monty__: Yes.
[12:13] <__monty__> I get this error when I try:
[12:13] <__monty__> Permission denied (publickey).
[12:13] <__monty__> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[12:13] <Peng> Uh.
[12:14] <Peng> __monty__: You've run "bzr launchpad-login" but your local SSH key doesn't match any of the ones you have on Launchpad.
[12:15] <__monty__> I registered on launchpad and then I ran "bzr launchpad-login __monty__" , but this gave me
[12:15] <__monty__> (erroneous enter)
[12:15] <__monty__> I registered on launchpad and then I ran "bzr launchpad-login __monty__" , but this gave me
[12:15] <Peng> __monty__: The username "__monty__" does not seem to exist.
[12:16] <__monty__> But I can login on launchpad.net
[12:16] <Peng> __monty__: Really? And that's your username?
[12:17] <__monty__> Yes.
[12:17] <Peng> __monty__: The 404 error at https://edge.launchpad.net/~__monty__ says otherwise.
[12:17] <Peng> I'd be surprised if Launchpad allowed leading underscores in usernames.
[12:19] <__monty__> Ok, DisplayName probably isn't the same as Name then.
[12:20] <__monty__> How do I register an SSH key?
[12:21] <Peng> __monty__: https://launchpad.net/~$name/+editsshkeys
[12:22] <Peng> __monty__: Or, click this: https://launchpad.net/people/+me/+editsshkeys
[12:24] <__monty__> How do I create such a key, I'm on mac os X.
[12:26] <Peng> __monty__: I dunno. Do you normally just use OpenSSH? ls ~/.ssh/*.pub, or the OS X equivalent.
[12:28] <Peng> __monty__: I'm not an OS X person; you should Google it.
[12:29] <Peng> (OTOH, there are a lot of terrible tutorials on Google, but...)
[12:29]  * __monty__ is googling
[12:29] <Pilky> __monty__: follow these instructions: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[12:29] <Pilky> follow the Linux instructions
[12:29] <Pilky> but skip 1
[12:30] <Pilky> OpenSSH is already installed
[12:31] <__monty__> Should I create an  rsa or a dsa key?
[12:31] <Pilky> rsa
[12:31] <Pilky> OS X is just unix so whenever there are no specific OS X instructions for something relating to the command line, try using the linux instructions
[12:32] <__monty__> I didn't yet know os X has ~openssh builtin so I thought I couldn't follow those steps without apt-get.
[12:36] <__monty__> Thanks for the help. :-)
[12:39] <__monty__> If I were to try some debugging where would I start looking in the source?
[12:44] <maxb> debugging what?
[12:48] <__monty__> Well, nothing specific, some trivial bugs, but if you need a specific example: https://bugs.launchpad.net/bzr/+bug/257170
[12:48] <ubottu> Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]
[12:53] <Peng> __monty__: I'd grep the codebase for some of the stuff that is logged to find it.
[12:54] <__monty__> Peng: How would you go about that with this specific bug?
[12:57] <Peng> __monty__: I'd check ~/.bzr.log, find something juicy, and grep for it . .
[13:00] <__monty__> Sorry for my ignorance, but what would you call juicy?
[13:02] <Peng> __monty__: Something that probably wouldn't have a lot of false positives. Actually, there aren't many choices, so I guess it would be "bzr arguments".
[13:04] <__monty__> So I just look for a line kind of like: "print "bzr arguments: %s" %(...)
[13:05] <Peng> __monty__: That's what I'd do.
[13:05] <__monty__> Peng: And how would you look for this: https://bugs.launchpad.net/bzr/+bug/239523
[13:05] <ubottu> Ubuntu bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed]
[13:06] <Peng> __monty__: Start in cmd_tag in bzrlib/builtins.py and/or grep for "Created tag".
[13:07] <__monty__> Ok, thanks for the help Peng.
[14:08] <ronny> hi
[14:08] <zekopeko_> hi
[14:08] <ronny> does bzr has some kind of concept for per-file metadata
[14:09] <zekopeko_> is there a simple way to check the revision of a branch?
[14:09] <Peng> zekopeko_: bzr revno
[14:09] <Peng> zekopeko_: bzr revision-info too
[14:09] <zekopeko_> cool. thanks
[14:10] <rubbs> ronny: can you clarify your question? I'm not sure what you mean. Do you mean does bzr keep metadata on each file?
[14:11] <ronny> rubbs: i mean if there is a way to have custom per-file metadata
[14:11] <rubbs> mmm... not that I know of, but I'm not a dev.
[14:11] <ronny> sup jelmer
[14:11] <Peng> ronny: Like svn? Um, I imagine that's how the exec bit is stored, so probably. But you definitely can't add arbitrary properties without writing some Python.
[14:12] <jelmer> hey ronny
[14:12] <ronny> jelmer: does bzr have a way to have own per-file metadata entries, preferably versioned, too
[14:12] <jelmer> ronny: nope, we don't have anything like that yet.
[14:13] <jelmer> ronny: you can of course store a dictionary with files as keys in the revision properties
[14:13] <ronny> meh, ok
[14:13] <Peng> Oh.
[14:16] <ronny> jelmer: any idea if the new repo format is able to actually store those?
[14:17] <Wellark[]> ugghh.. this is depressing.. I'm trying to verify revision signatures on server side on push in pre_change_branch_tip_hook so that I can reject the push if the verification of the signatures fail or they are missing. repository.has_revision() returns True for the new revisions, but repository.has_signature_for_revision_id() returns False, even though the revision are signed before the push :/
[14:17] <jelmer> ronny: revision properties are supported for all formats in use today
[14:17] <ronny> jelmer: i mean per-file properties
[14:18] <jelmer> ronny: There is no new file format in development at the moment as far as I know.
[14:18] <jelmer> ronny: There won't be a new default file format before 3.0
[14:19] <ronny> ok
[14:19] <Wellark[]> I'm a bit lost right now.. I'm not sure if there's any way to access the signatures before the push is completed
[14:19] <ronny> so i can just ignore that after all
[14:20] <jelmer> wellark[]: Hmm
[14:21] <jelmer> Wellark[]: Does repository.has_signature_for_revision_id() return True for those revisions after that push, from a new bzr instance?
[14:21] <jelmer> (are the signatures actually pushed correctly/)
[14:22] <Wellark[]> jelmer: I'll check
[14:35] <za> i did this: bzr init    bzr: ERROR: Already a branch: "."
[14:35] <za> how can i change my branch?
[14:35] <Wellark[]> jelmer: you got it right.. the signatures are not transfered..
[14:35] <Wellark[]> interesting..
[14:35] <Wellark[]> I'll investigate
[14:36] <jelmer> wellark[]: Thanks
[14:36] <jelmer> wellark[]: I wouldn't be surprised if there was a bug there, since the signature code isn't used very heavily at the moment
[14:39] <Wellark[]> jelmer: I'll do my  best
[14:39] <za> i am current ly using /project for my branch. but now i want to change it to /web/project . how can make these changes?
[14:39] <Wellark[]> last night was the first time I looked at bzr source code :)
[14:40] <rubbs> za: just say "bzr branch /project /web/project" and that will create a mirror to the new location. After that you can delete the old branch.
[14:45] <za> rubbs: i am getting error : "target directory already exists"
[14:46] <rubbs> za: try using the --use-existing-dir flag
[14:46] <rubbs> so it should read "bzr branch --use-existing-dir /project /web/project"
[14:47] <za> rubbs: error: already a branch
[14:47] <za> ohh sorry
[14:47] <za> wait
[14:53] <Wellark[]> jelmer: this was probably an "user error".. I signed some already pushed revisions with sign-my-commits and assumed that the signatures are pushed when I make a new push
[14:53] <Wellark[]> that's not the case if there's no other changes
[14:53] <jelmer> Wellark[]: Well, ideally we should also be fetching missing signatures for existing revisions
[14:55] <Wellark[]> jelmer: yeah, but that's now only a minor inconvenience if I can get the hook working for new revisions.
[14:58] <Wellark[]> jelmer: thanks for asking the right question ;)
[14:59] <jelmer> wellark[]: np - it's working now?
[15:02] <Wellark[]> jelmer: yes, infact it is. just tested :)
[15:03] <Wellark[]> sweet!
[15:04] <zombor> hello, im wondering if anyone can help me out, my auto complete doesn't appear to be working when i press tab to complete a directory for instance, anyone know why this might be?
[16:37] <maxb> jelmer: Hi, if you're around, how should I submit a bzr-rewrite branch? The branch description on Launchpad says MPs there will be ignored.
[16:37] <maxb> bah
[16:58] <__monty__> Can anyone tell me where  can find documentation of "trace.mutter"?
[16:59] <maxb> bzrlib/trace.py ? :-)
[17:01] <__monty__> Thank you, I thought trace.mutter referred to the builtin trace module.
[17:32] <Wellark> gah.. the signature handling is not satisfactory..
[17:33] <Wellark> if I try to push revisions which do not have signatures and the push fails and I sign the revisions and push again the signatures are not sent
[17:55] <Wellark> I haven't yet figured out what actually happens on a push
[17:55] <Wellark> repository.py is also quite massive :)
[17:56] <gutworth_> welcome to version control :)
=== gutworth_ is now known as gutworth
[17:57] <Wellark> :)
[18:02] <Wellark> at least it's nice that revision signatures are separated from actual revisions inside Repository
[18:03] <Wellark> probably allows all sort of neat stuff to be implemented without a fear of breaking revision logic
[18:04] <Wellark> I'm already thinking about resigning revisions etc :P
[18:09] <maxb> On a related note it also sucks that tags aren't push/pulled unless revisions are being transferred too
[18:16] <Wellark> maxb: really?
[18:16] <Wellark> that's truly sucks
[18:17] <Wellark> I'll keep an eye on that too when I _try_ to fix the signature problem
[18:17] <Peng> maxb: That's not the case, or didn't use to be.
[18:17] <tbnorth> hi all - the Inkscape project recently moved to bzr for VCS and someone's workflow resulted in a months worth of different people's revisions becoming sub-revisions of one person's commit.
[18:18] <Peng> Or maybe it only applied when the destination's .bzr/branch/tags was missing.
[18:18] <tbnorth> apart from educating people about correct workflow, is there any way to prevent this from happening?
[18:18] <tbnorth> it upsets people ;-}
[18:18] <Peng> tbnorth: Not really. It's a standard workflow for people to merge lots of others' revisions.
[18:19] <tbnorth> Peng: so people should just get used to it?  Part of the problem is that launchpad doesn't show the subrevisions, so people think they're lost
[18:20] <Peng> tbnorth: Well it's not like the revisions are actually any less important or anything.
[18:21] <tbnorth> ok, just wondered if there was any setup which made it harder for people to do this accidentally
[18:22] <tbnorth> the preferred workflow would be to merge your local changes into a current copy of the trunk and push that, so your local commits become subrevisions, and not all the commits which occurred since you branched
[18:32] <maxb> Peng/tbnorth: maybe append_revisions_only?
[18:32] <maxb> Peng: (re tags) Hmm.... I guess I shall have to re-test
[18:33] <tbnorth> maxb: thanks, sounds interesting, will investigate
[18:34] <maxb> tbnorth: I'm guessing that the problem workflow is that of merging trunk into your feature branch, and then pushing to trunk?
[18:34] <tbnorth> maxb: exactly
[18:35] <tbnorth> I understand no real damage is done, but others coming from SVN are all disconcerted, thinking things are lost
[18:35] <tbnorth> and people prefer a linear change log
[18:36] <maxb> Well, the 'damage' is that the revision history becomes less comprehensible
[18:36] <tbnorth> right, so append_revisions_only would help?  I'm still looking for docs for it
[18:37] <Peng> It might help, but I wouldn't be completely sure.
[18:37] <Peng> No revisions are being *removed*, some of them just aren't mainline anymore.
[18:37] <tbnorth> I've set up a little test script, I'll try it with that enabled
[18:37] <maxb> Assuming I've undersstood it correctly (which I don't guarantee), it should cause bzr to deny pushes which would move revisions off the mainline
[18:38] <Peng> tbnorth: Anyway, this is mostly a user education thing...
[18:39] <Peng> tbnorth: BTW, I bet you can do a clever merge or two to flip the mainline over again.
[18:39] <tbnorth> Peng: sure, I've been through the loop once on another project which is now quite happy with bzr, but on this project core developers are not happy at the moment
[18:40] <tbnorth> Peng: I'm not going to try and undo anything, nothing's lost at the moment, I don't want to try and be clever and break something for real
[18:40] <Peng> tbnorth: Meh, it would be hard to actually break things.
[18:42] <tbnorth> ok, in my test code append_revisions_only blocks the push that would change the log, great, now the question is can that be set on a launchpad hosted branch?
[18:45] <maxb> Sure, it's just a config file option
[18:45] <maxb> You may need to get a little sneaky to change the config file though
[18:45] <tbnorth> how so?
[18:45] <maxb> Either doing it via the bzr API, or going in via sftp
[18:46] <maxb> tbnorth: btw, has further development happened on trunk since this flip?
[18:46] <tbnorth> yes, a couple of commits I think
[18:46] <Peng> Should be really easy with the API.
[18:47] <Peng> Hold on.
[18:49] <maxb> python -c 'import bzrlib.branch as b; b.Branch.open("bzr+ssh://bazaar.launchpad.net/~maxb/tortoisehg/ppa").set_append_revisions_only(True)'
[18:49] <Peng> Damn, you beat me.
[18:49] <tbnorth> hehe, lol :-)
[18:50] <maxb> If it's only been a few commits, it still might be worth straighening out
[18:50] <tbnorth> what would the procedure be?
[18:51] <maxb> branch the former mainline; merge the commit which broke things; commit; for each subsequent revision: merge; commit
[18:51] <maxb> push the result
[18:52] <Peng> Of course, turn off append_revisions_only first. ;-D
[18:52] <Peng> (what maxb posted earlier, only replace True with False)
[18:52] <tbnorth> ok, I could try that locally I guess, actually I don't have any commit permissions on this project, but those that do might want to do that
[18:53] <tbnorth> and I'll do the set_append_revisions_only thing on the other lp project I work on.
[18:53] <maxb> Is lp:inkscape the problem branch?
[18:53] <tbnorth> yes
[18:54] <tbnorth> thanks for this help, people were panicking about bzr being usable, which I knew was over reacting
[18:56] <maxb> Right, so you'd have the problem and 4 subsequent commits which would require individually merging onto the former tip
[18:56] <maxb> Doable
[18:57] <maxb> Whilst you're at it, you might point out that their repository format is rather ancient
[18:58] <tbnorth> maxb: that's an issue I've seen on a couple of projects, what's the easiest way to fix it?
[18:58] <Peng> To fix what, ancient-formatitis? "bzr upgrade".
[18:59] <tbnorth> followed by a push?  I'm not familiar with adminning lp branches
[18:59] <maxb> This is the first time I've seen an active branch using something that's pre-knitpack :-)
[19:00] <tbnorth> probably the person who set it up didn't know better
[19:00] <maxb> upgrade is an in-place operation, but can be run on a remote URL
[19:00] <tbnorth> so if someone with the proper rights does `bzr upgrade lp:inkscape` that would do it?
[19:01] <Peng> Yeah.
[19:01] <tbnorth> thanks
[19:02] <Peng> tbnorth: Tell them to be careful what they upgrade *to*. Upgrading to 2a gets a bit complicated because it has rich roots, though even an older format like 1.9 would be an improvement and put them in this century. :P
[19:06] <tbnorth> Peng:  `bzr upgrade --format=1.9 lp:inkscape` would be the safest improvement, that's what you're saying?
[19:07] <maxb> However, given the format is already rich-root, that's not an issue
[19:07] <maxb> Really it depends how much they care about users of old versions of bzr
[19:08] <Peng> It is? Um. Who the heck uses an ancient rich-root format?
[19:08] <maxb> Personally I'd hope no one would be labouring on with bzr 1.x now bzr 2.x is here, but I guess that's not a realistic expectation
[19:08] <Peng> They're very lucky, but still.
[19:08] <maxb> It's Knit4
[19:08] <maxb> (aka 'rich-root')
[19:08] <Peng> Ah.
[19:08] <Peng> Seriously, it was a good decision, but I'm surprised someone chose it...
[19:09] <maxb> Of course, there's still the 'different serializers' incompatibility when switching to 2a
[19:09] <Peng> maxb: Only a problem with stacking.
[19:09] <maxb> An in-place upgrade to 2a would break branches stacked on the trunk...
[19:09] <maxb> indeed
[19:10] <maxb> So, yeah, personally I'd probably take it up to 1.9-rich-root
[19:10] <Peng> Hold on a sec. Given how old the format is, it's unlikely anyone's using stacking.
[19:10] <maxb> Can't you stack *on* hideously ancient formats?
[19:11] <maxb> It's a shame there's no way to ask Launchpad "Who's stacked on me?"
[19:11] <Peng> Does stacking depend on the repo format or just the branch format?
[19:14] <maxb> I think it depends on the stacker's format but not the stackee's?
[19:14] <maxb> (Other that the 2.x serializer change)
[19:20] <maxb> jelmer: Hi, if you're around, how should I submit a bzr-rewrite branch? The branch description on Launchpad says MPs there will be ignored.
[19:24] <jelmer> maxb: please send merge requests to me personally (jelmer@samba.org)
=== tbnorth is now known as tbrown_afk
[19:27] <maxb> ok, will do
[19:34] <Peng> jelmer: Just curious, why?
[19:34] <Peng> (Why not use the LP merge proposal system, I mean?)
[19:50] <maxb> Is the reason for the word 'with' in the bzr reconfigure --with-(no-)trees options because --trees and --no-trees would be interpreted as a single boolean option with a negated form?
[19:50]  * maxb is contemplating how to add reconfiguration of the append-revisions-only option
[19:52] <NfNitLoop> bleh.  I'm using git-svn to work with this svn repo that bzr-svn can't deal with.   It's making me miss bzr. :p
[19:52] <NfNitLoop> had to go ask in #git how the heck to push my locally changed branch back up to svn.  It was a bit convoluted.
[19:52] <jelmer> NfNitLoop, why is bzr-svn not working?
[19:52] <NfNitLoop> jelmer: In the history, someone checked in (then removed) a file with a \ in its name.
[19:53] <jelmer> peng: Launchpad does not attach merge directives, only plain diffs
[19:53] <jelmer> peng: making it impossible to deal with merge requests while offline
[19:54] <jelmer> NfNitLoop: Ah, ok
[19:54] <jelmer> NfNitLoop: to be pedantic, bzr doesn't allow \, bzr-svn should be fine with backslashes
[19:54] <NfNitLoop> I actually started my own bzr branch to try removing the restriction re: '\' in file names but didn't get it to a working state.
[19:54] <NfNitLoop> yep.  I've talked about it before in here. :)
[19:54] <jelmer> ah, sorry :-)
[19:55] <NfNitLoop> I was mostly just complimenting you on how nice bzr-svn integration is compared to git-svn.
[19:55] <NfNitLoop> 'bzr svn-push <my-branch-location>' is 3-4 steps in git-svn.
[19:56] <jelmer> thanks, glad to hear :-)
[19:56] <jelmer> the \ restriction is really silly, it should be trivial to remove
[19:57] <jelmer> it just hasn't been done yet because we need to warn users that a created branch won't be usable on windows
[20:00] <maxb> Is there any way to get 'bzr send' to send GPG signed merge directives, short of doing it via a GUI MUA?
[20:01] <maxb> Ideally I'd like 'editor'-type composition, but with GPG signing
[20:07] <zombor> hello, im wondering if anyone can help me out, my auto complete doesn't appear to be working when i press tab to complete a directory for instance, anyone know why this might be?
[20:21] <NfNitLoop> zombor: auto-complete for directories?  Might that be a better question for #bash?
[20:21] <zombor> NfNitLoop: but it works for all other commands, and it used to work in bzr
[20:22] <zombor> i thought maybe it was a plugin that got messed up or something
=== tbrown_afk is now known as tbrown
[20:26] <tbrown> zombor: in bash the `complete` command can impact completion for specific command lines, e.g. `complete -C ~/bin/bzropts bzr` would cause the program ~/bin/bzropts to be used to handle completion for command lines starting with bzr.
[20:28] <zombor> `which bzropts` bzropts not found
[20:28] <zombor> =/
[20:28] <zombor> im using zsh also
[20:29] <tbrown> I made that up, there's no such program, I was just pointing out that complete, in bash, can cause inconsistent autocomplete activity
[20:29] <tbrown> perhaps it's a question for #zsh
[20:30] <zombor> hrm, i wonder what i did to cause it to not work...
[20:30] <zombor> im pretty sure it stopped working after i installed bzr into my home directory
[20:46] <NfNitLoop> zombor: if you had previously installed bzr via your package manager, it may have configured bzr autocomplete for you.
[20:46] <zombor> probably...
[20:46] <NfNitLoop> so if you uninstalled it to install a different version in your home directory, that would explain it.
[20:46] <zombor> well, i didn't uninstall the system version
[20:47] <zombor> i just added my $HOME bin dir to my $PATH
[20:48] <zombor> im going to install the stable version from launchpad via my package manager, so maybe that will fix it
=== khmarbaise_ is now known as khmarbaise