#bzr 2009-12-28
<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
<wgrant> Surprisingly little bzr-bashing on /. so far...
<gutworth> some people don't like bazaar?
<akitada> Hi, can I edit history in bzr repository?
<lifeless> wgrant: ?
<wgrant> lifeless: The Slashdot article about Emacs moving to bzr has surprisingly little bzr bashing.
<akitada> wgrant: that news made me feel like trying bzr for the first time
<akitada> I use git and hg but haven't used bzr
<akitada> still feeling bzr is a bit peculiar.
<Wellark> could someone please explain to me how revision can have multiple parent_ids?
<Peng> Wellark: A merge.
<Wellark> Peng: OK, so the end result is that revision lists parent_id:s from both trees. makes sense. thanks! :)
<__monty__> Hi, I'm having some trouble getting the bzr source code, could someone offer some help?
<franck-bret> hello, does anyone can tell me how to have compatible repository with hardy server LTS (bzr 1.14) ?
<Peng> franck-bret: Ideally you would use the PPA to install the latest version of bzr on it.......
<Peng> franck-bret: If not, you should use the 1.14-rich-root format.
<franck-bret> ive put my log here http://pastebin.com/d7bb155a7
<Peng> franck-bret: Oh god, 1.3.1? Upgrade, dude.
<franck-bret> it's a server with lastes UBUNTU LTS ...
<Peng> franck-bret: And?
<Peng> franck-bret: https://launchpad.net/~bzr/+archive/ppa
<franck-bret> last bzr version for LTS isn't 2.**
<Peng> franck-bret: So use the PPA.
<__monty__> How do I get the bazaar source?
<franck-bret> ok thanks, i'm gonna upgrade bzr, seems to be the more simple and evolutive way, thanks Peng
<Peng> __monty__: "bzr branch lp:bzr" or download a tarball from the website.
<bialix> __monty__: bazaar.canonical.com -> Download -> Sources
<Peng> franck-bret: :)
<__monty__> Can i use "bzr branch lp:bzr bzr.dev" to download the source to a folder named bzr.dev?
<Peng> __monty__: Yes.
<__monty__> I get this error when I try:
<__monty__> Permission denied (publickey).
<__monty__> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Peng> Uh.
<Peng> __monty__: You've run "bzr launchpad-login" but your local SSH key doesn't match any of the ones you have on Launchpad.
<__monty__> I registered on launchpad and then I ran "bzr launchpad-login __monty__" , but this gave me
<__monty__> (erroneous enter)
<__monty__> I registered on launchpad and then I ran "bzr launchpad-login __monty__" , but this gave me
<Peng> __monty__: The username "__monty__" does not seem to exist.
<__monty__> But I can login on launchpad.net
<Peng> __monty__: Really? And that's your username?
<__monty__> Yes.
<Peng> __monty__: The 404 error at https://edge.launchpad.net/~__monty__ says otherwise.
<Peng> I'd be surprised if Launchpad allowed leading underscores in usernames.
<__monty__> Ok, DisplayName probably isn't the same as Name then.
<__monty__> How do I register an SSH key?
<Peng> __monty__: https://launchpad.net/~$name/+editsshkeys
<Peng> __monty__: Or, click this: https://launchpad.net/people/+me/+editsshkeys
<__monty__> How do I create such a key, I'm on mac os X.
<Peng> __monty__: I dunno. Do you normally just use OpenSSH? ls ~/.ssh/*.pub, or the OS X equivalent.
<Peng> __monty__: I'm not an OS X person; you should Google it.
<Peng> (OTOH, there are a lot of terrible tutorials on Google, but...)
 * __monty__ is googling
<Pilky> __monty__: follow these instructions: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<Pilky> follow the Linux instructions
<Pilky> but skip 1
<Pilky> OpenSSH is already installed
<__monty__> Should I create an  rsa or a dsa key?
<Pilky> rsa
<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
<__monty__> I didn't yet know os X has ~openssh builtin so I thought I couldn't follow those steps without apt-get.
<__monty__> Thanks for the help. :-)
<__monty__> If I were to try some debugging where would I start looking in the source?
<maxb> debugging what?
<__monty__> Well, nothing specific, some trivial bugs, but if you need a specific example: https://bugs.launchpad.net/bzr/+bug/257170
<ubottu> Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]
<Peng> __monty__: I'd grep the codebase for some of the stuff that is logged to find it.
<__monty__> Peng: How would you go about that with this specific bug?
<Peng> __monty__: I'd check ~/.bzr.log, find something juicy, and grep for it . .
<__monty__> Sorry for my ignorance, but what would you call juicy?
<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".
<__monty__> So I just look for a line kind of like: "print "bzr arguments: %s" %(...)
<Peng> __monty__: That's what I'd do.
<__monty__> Peng: And how would you look for this: https://bugs.launchpad.net/bzr/+bug/239523
<ubottu> Ubuntu bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed]
<Peng> __monty__: Start in cmd_tag in bzrlib/builtins.py and/or grep for "Created tag".
<__monty__> Ok, thanks for the help Peng.
<ronny> hi
<zekopeko_> hi
<ronny> does bzr has some kind of concept for per-file metadata
<zekopeko_> is there a simple way to check the revision of a branch?
<Peng> zekopeko_: bzr revno
<Peng> zekopeko_: bzr revision-info too
<zekopeko_> cool. thanks
<rubbs> ronny: can you clarify your question? I'm not sure what you mean. Do you mean does bzr keep metadata on each file?
<ronny> rubbs: i mean if there is a way to have custom per-file metadata
<rubbs> mmm... not that I know of, but I'm not a dev.
<ronny> sup jelmer
<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.
<jelmer> hey ronny
<ronny> jelmer: does bzr have a way to have own per-file metadata entries, preferably versioned, too
<jelmer> ronny: nope, we don't have anything like that yet.
<jelmer> ronny: you can of course store a dictionary with files as keys in the revision properties
<ronny> meh, ok
<Peng> Oh.
<ronny> jelmer: any idea if the new repo format is able to actually store those?
<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 :/
<jelmer> ronny: revision properties are supported for all formats in use today
<ronny> jelmer: i mean per-file properties
<jelmer> ronny: There is no new file format in development at the moment as far as I know.
<jelmer> ronny: There won't be a new default file format before 3.0
<ronny> ok
<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
<ronny> so i can just ignore that after all
<jelmer> wellark[]: Hmm
<jelmer> Wellark[]: Does repository.has_signature_for_revision_id() return True for those revisions after that push, from a new bzr instance?
<jelmer> (are the signatures actually pushed correctly/)
<Wellark[]> jelmer: I'll check
<za> i did this: bzr init    bzr: ERROR: Already a branch: "."
<za> how can i change my branch?
<Wellark[]> jelmer: you got it right.. the signatures are not transfered..
<Wellark[]> interesting..
<Wellark[]> I'll investigate
<jelmer> wellark[]: Thanks
<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
<Wellark[]> jelmer: I'll do my  best
<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?
<Wellark[]> last night was the first time I looked at bzr source code :)
<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.
<za> rubbs: i am getting error : "target directory already exists"
<rubbs> za: try using the --use-existing-dir flag
<rubbs> so it should read "bzr branch --use-existing-dir /project /web/project"
<za> rubbs: error: already a branch
<za> ohh sorry
<za> wait
<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
<Wellark[]> that's not the case if there's no other changes
<jelmer> Wellark[]: Well, ideally we should also be fetching missing signatures for existing revisions
<Wellark[]> jelmer: yeah, but that's now only a minor inconvenience if I can get the hook working for new revisions.
<Wellark[]> jelmer: thanks for asking the right question ;)
<jelmer> wellark[]: np - it's working now?
<Wellark[]> jelmer: yes, infact it is. just tested :)
<Wellark[]> sweet!
<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?
<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.
<maxb> bah
<__monty__> Can anyone tell me where  can find documentation of "trace.mutter"?
<maxb> bzrlib/trace.py ? :-)
<__monty__> Thank you, I thought trace.mutter referred to the builtin trace module.
<Wellark> gah.. the signature handling is not satisfactory..
<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
<Wellark> I haven't yet figured out what actually happens on a push
<Wellark> repository.py is also quite massive :)
<gutworth_> welcome to version control :)
<Wellark> :)
<Wellark> at least it's nice that revision signatures are separated from actual revisions inside Repository
<Wellark> probably allows all sort of neat stuff to be implemented without a fear of breaking revision logic
<Wellark> I'm already thinking about resigning revisions etc :P
<maxb> On a related note it also sucks that tags aren't push/pulled unless revisions are being transferred too
<Wellark> maxb: really?
<Wellark> that's truly sucks
<Wellark> I'll keep an eye on that too when I _try_ to fix the signature problem
<Peng> maxb: That's not the case, or didn't use to be.
<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.
<Peng> Or maybe it only applied when the destination's .bzr/branch/tags was missing.
<tbnorth> apart from educating people about correct workflow, is there any way to prevent this from happening?
<tbnorth> it upsets people ;-}
<Peng> tbnorth: Not really. It's a standard workflow for people to merge lots of others' revisions.
<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
<Peng> tbnorth: Well it's not like the revisions are actually any less important or anything.
<tbnorth> ok, just wondered if there was any setup which made it harder for people to do this accidentally
<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
<maxb> Peng/tbnorth: maybe append_revisions_only?
<maxb> Peng: (re tags) Hmm.... I guess I shall have to re-test
<tbnorth> maxb: thanks, sounds interesting, will investigate
<maxb> tbnorth: I'm guessing that the problem workflow is that of merging trunk into your feature branch, and then pushing to trunk?
<tbnorth> maxb: exactly
<tbnorth> I understand no real damage is done, but others coming from SVN are all disconcerted, thinking things are lost
<tbnorth> and people prefer a linear change log
<maxb> Well, the 'damage' is that the revision history becomes less comprehensible
<tbnorth> right, so append_revisions_only would help?  I'm still looking for docs for it
<Peng> It might help, but I wouldn't be completely sure.
<Peng> No revisions are being *removed*, some of them just aren't mainline anymore.
<tbnorth> I've set up a little test script, I'll try it with that enabled
<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
<Peng> tbnorth: Anyway, this is mostly a user education thing...
<Peng> tbnorth: BTW, I bet you can do a clever merge or two to flip the mainline over again.
<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
<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
<Peng> tbnorth: Meh, it would be hard to actually break things.
<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?
<maxb> Sure, it's just a config file option
<maxb> You may need to get a little sneaky to change the config file though
<tbnorth> how so?
<maxb> Either doing it via the bzr API, or going in via sftp
<maxb> tbnorth: btw, has further development happened on trunk since this flip?
<tbnorth> yes, a couple of commits I think
<Peng> Should be really easy with the API.
<Peng> Hold on.
<maxb> python -c 'import bzrlib.branch as b; b.Branch.open("bzr+ssh://bazaar.launchpad.net/~maxb/tortoisehg/ppa").set_append_revisions_only(True)'
<Peng> Damn, you beat me.
<tbnorth> hehe, lol :-)
<maxb> If it's only been a few commits, it still might be worth straighening out
<tbnorth> what would the procedure be?
<maxb> branch the former mainline; merge the commit which broke things; commit; for each subsequent revision: merge; commit
<maxb> push the result
<Peng> Of course, turn off append_revisions_only first. ;-D
<Peng> (what maxb posted earlier, only replace True with False)
<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
<tbnorth> and I'll do the set_append_revisions_only thing on the other lp project I work on.
<maxb> Is lp:inkscape the problem branch?
<tbnorth> yes
<tbnorth> thanks for this help, people were panicking about bzr being usable, which I knew was over reacting
<maxb> Right, so you'd have the problem and 4 subsequent commits which would require individually merging onto the former tip
<maxb> Doable
<maxb> Whilst you're at it, you might point out that their repository format is rather ancient
<tbnorth> maxb: that's an issue I've seen on a couple of projects, what's the easiest way to fix it?
<Peng> To fix what, ancient-formatitis? "bzr upgrade".
<tbnorth> followed by a push?  I'm not familiar with adminning lp branches
<maxb> This is the first time I've seen an active branch using something that's pre-knitpack :-)
<tbnorth> probably the person who set it up didn't know better
<maxb> upgrade is an in-place operation, but can be run on a remote URL
<tbnorth> so if someone with the proper rights does `bzr upgrade lp:inkscape` that would do it?
<Peng> Yeah.
<tbnorth> thanks
<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
<tbnorth> Peng:  `bzr upgrade --format=1.9 lp:inkscape` would be the safest improvement, that's what you're saying?
<maxb> However, given the format is already rich-root, that's not an issue
<maxb> Really it depends how much they care about users of old versions of bzr
<Peng> It is? Um. Who the heck uses an ancient rich-root format?
<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
<Peng> They're very lucky, but still.
<maxb> It's Knit4
<maxb> (aka 'rich-root')
<Peng> Ah.
<Peng> Seriously, it was a good decision, but I'm surprised someone chose it...
<maxb> Of course, there's still the 'different serializers' incompatibility when switching to 2a
<Peng> maxb: Only a problem with stacking.
<maxb> An in-place upgrade to 2a would break branches stacked on the trunk...
<maxb> indeed
<maxb> So, yeah, personally I'd probably take it up to 1.9-rich-root
<Peng> Hold on a sec. Given how old the format is, it's unlikely anyone's using stacking.
<maxb> Can't you stack *on* hideously ancient formats?
<maxb> It's a shame there's no way to ask Launchpad "Who's stacked on me?"
<Peng> Does stacking depend on the repo format or just the branch format?
<maxb> I think it depends on the stacker's format but not the stackee's?
<maxb> (Other that the 2.x serializer change)
<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.
<jelmer> maxb: please send merge requests to me personally (jelmer@samba.org)
<maxb> ok, will do
<Peng> jelmer: Just curious, why?
<Peng> (Why not use the LP merge proposal system, I mean?)
<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?
 * maxb is contemplating how to add reconfiguration of the append-revisions-only option
<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
<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.
<jelmer> NfNitLoop, why is bzr-svn not working?
<NfNitLoop> jelmer: In the history, someone checked in (then removed) a file with a \ in its name.
<jelmer> peng: Launchpad does not attach merge directives, only plain diffs
<jelmer> peng: making it impossible to deal with merge requests while offline
<jelmer> NfNitLoop: Ah, ok
<jelmer> NfNitLoop: to be pedantic, bzr doesn't allow \, bzr-svn should be fine with backslashes
<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.
<NfNitLoop> yep.  I've talked about it before in here. :)
<jelmer> ah, sorry :-)
<NfNitLoop> I was mostly just complimenting you on how nice bzr-svn integration is compared to git-svn.
<NfNitLoop> 'bzr svn-push <my-branch-location>' is 3-4 steps in git-svn.
<jelmer> thanks, glad to hear :-)
<jelmer> the \ restriction is really silly, it should be trivial to remove
<jelmer> it just hasn't been done yet because we need to warn users that a created branch won't be usable on windows
<maxb> Is there any way to get 'bzr send' to send GPG signed merge directives, short of doing it via a GUI MUA?
<maxb> Ideally I'd like 'editor'-type composition, but with GPG signing
<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?
<NfNitLoop> zombor: auto-complete for directories?  Might that be a better question for #bash?
<zombor> NfNitLoop: but it works for all other commands, and it used to work in bzr
<zombor> i thought maybe it was a plugin that got messed up or something
<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.
<zombor> `which bzropts` bzropts not found
<zombor> =/
<zombor> im using zsh also
<tbrown> I made that up, there's no such program, I was just pointing out that complete, in bash, can cause inconsistent autocomplete activity
<tbrown> perhaps it's a question for #zsh
<zombor> hrm, i wonder what i did to cause it to not work...
<zombor> im pretty sure it stopped working after i installed bzr into my home directory
<NfNitLoop> zombor: if you had previously installed bzr via your package manager, it may have configured bzr autocomplete for you.
<zombor> probably...
<NfNitLoop> so if you uninstalled it to install a different version in your home directory, that would explain it.
<zombor> well, i didn't uninstall the system version
<zombor> i just added my $HOME bin dir to my $PATH
<zombor> im going to install the stable version from launchpad via my package manager, so maybe that will fix it
#bzr 2009-12-29
<NfNitLoop> ()!&*(ULWDJKFW.   Apparently git-svn doesn't always create the same commit IDs for things it's mapped from svn.
<NfNitLoop> gaaaah.
<NfNitLoop> I'm just going to have to fix bzr & bzr-svn to work with my repo, git-svn is making me want to stab someone. :p
<NfNitLoop> Oh.  Wow.  That was way easier than I thought.
<NfNitLoop> 1-line change in bzrlib.   2-line change in bzr-svn.  Now I can check out my repo with files with backslashes in it. :D
<fbond> Hi.  Why does bzr init recursively scan the contents of the directory I run it in?
<fbond> This directory happens to contain a huge tree of files that I'm not interested in versioning, so init looks like its hanging.  strace showed me why.
<gutworth> it assumes you want to version them :)
<fbond> I would think that that wouldn't happen until I run bzr add.
<NfNitLoop> Hrmmm.   Odd.   'bzr branch <svn-branch>' gave me a 2.3GB directory.
<NfNitLoop> a bit larger than the svn or git checkouts.
<NfNitLoop> so then I bzr init-repo, and branch that branch into the shared repo.
<NfNitLoop> and magically it's reduced to 1.4GB.
<NfNitLoop> weeeeeird.
<spiv> NfNitLoop: 'bzr pack && rm .bzr/repository/obsolete-packs/*' would probably have the same effect.
<spiv> NfNitLoop: the bzr-svn import works incrementally (1000 revisions at a time) rather than doing it all in one transaction, and the reduces the effectiveness of the automatic packing (in the short term).  The tradeoff is that if the import is interrupted it can be resumed, rather than needing to redo from start.
<spiv> (Also some of the obsolete packs won't have been cleared out by the autopacking.)
<NfNitLoop> aaaah.  Yeah, I'd tried a pack but didn't rm obsolete-packs.
<NfNitLoop> it's nice.  a bzr-svn branch with full history is smaller than my svn checkout. :D
<spiv> NfNitLoop: :)
<NfNitLoop> So.  To get this to work with my repo, which includes a file in its history with a \...
<NfNitLoop> I had to remove checks for that character in bzrlib and bzr-svn.
<whitley> hi all.  I'm looking at the ignore tests (test_ignores.py, per_workingtree/test_is_ignored.py) and don't see any tests for '**/ignoreme.o' patterns or regexp patterns.
<NfNitLoop> 3 lines changed total.
<NfNitLoop> Should I put those on launchpad?   Wondering what the ... ettiquette is there.
<NfNitLoop> er.  etiquette. :p
<spiv> NfNitLoop: oh
<spiv> NfNitLoop: so, that check is unfortunately intentional
<spiv> NfNitLoop: It's true that the current format is technically capable of representing it safely, but there are interoperability issues with other versions of bzr and other formats that meant to have identical capabilities.
<spiv> NfNitLoop: so unfortunately it's not as easy as a 3-line patch
<spiv> NfNitLoop: and you will probably have issues if you use an unpatched bzr on this repo.
<spiv> NfNitLoop: If the filename with the \ only exists in pretty old revisions, you might be able to safely do something like construct a repo that omits all revisions at and before that point
<spiv> (i.e. those revisions would be a 'ghosts' in our jargon)
<spiv> NfNitLoop: that would preserve all the same revision and file-ids, so bzr-svn would keep interoperating pretty happily unless you tried to access those old revisions.
<NfNitLoop> how do you do that?
<spiv> NfNitLoop: I think you'd need a script or a plugin to make that happen, post to the list and I'm sure someone can throw one together for you
<NfNitLoop> oh.
<spiv> NfNitLoop: unfortunately I don't have time to do so right now :/
<spiv> NfNitLoop: good luck
 * spiv -> afk
<NfNitLoop> Hrmm, I don't quite understand what you mean by "interoperability issues with other versions of bzr and other formats that [are] meant to have identical capabilities".
<NfNitLoop> I know that an unpatched repo might see the \ and throw an error.
<NfNitLoop> But that's fine by me.  I just want to use bzr wih my svn repo. :p
<NfNitLoop> Hrmm.
<NfNitLoop> I seem to have accidentally pushed a repository onto the root of my shared repository.
<NfNitLoop> Is there a way to undo that?
<bob2> pushed a /branch/ onto the root of your shared repository?
<bob2> if so, I think it is safe to just rm ~/repo/.bzr/branch
<NfNitLoop> ah, ok, thanks!
<bob2> (backup first of course :)
<NfNitLoop> that did it. :p
<visik7> how can I pick a commit made on a branch and put it in another branch ?
<hmeland_> visik7: Do a "cherrypick merge"; see the 81..82 example in "bzr help merge".
<visik7> ok thanks
<abeaumont_> is there any way to join a bzr-svn subtree in a bzr tree?
<nomatter001> hi
<nomatter001> is it somehow possible to get the working tree populated on an central server
<nomatter001> so that with a push i also get the working-files there?
<Pilky> nomatter001: I believe there is a plugin that does a push and checkout
<nomatter001> Pilky: but a checkout doesn't do anything for me
<Pilky> nomatter001: https://launchpad.net/bzr-push-and-update/
<nomatter001> Pilky: the files are still just locally
<Pilky> yeah you need to checkout the remote branch to the server
<nomatter001> Pilky: how do i do that?
<Pilky> and then after each push update the working tree on the server
<nomatter001> Pilky: on the remote server is no bzr installed
<Pilky> if your server is http://foo.com/repo then
<Pilky> bzr checkout http://foo.com/repo http://foo.com/repo
<Pilky> or however you access it
<Pilky> either way you checkout the branch to the branch location
<nomatter001> Pilky: my problem is that i created the branch locally
<Pilky> but you've pushed it to a server?
<nomatter001> Pilky: yes
<Pilky> well that's a copy of the branch on that server
<nomatter001> Pilky: but now, how do i also get the working-tree onto the server?
<Pilky> by checking out the branch on the server, to a location on the server
<Pilky> are you coming from subversion to bzr?
<nomatter001> Pilky: i used svn a lil bit but i'm generally a beginner
<Pilky> right, well think of it like this
<Pilky> you have a branch, which you can think of as a blob which contains the full history
<Pilky> if you push a branch somewhere then that is copied (unless it is stacked but we won't get into that)
<Pilky> so there are two independent copies of the branch now
<Pilky> if you delete the branch from your machine then the one on your server still exists
<Pilky> a working tree is basically the physical files that you can work on
<Pilky> in order to get a working tree from a branch that doesn't have one
<Pilky> you need to checkout that branch
<Pilky> which basically pulls the files out of the blob that represents your history and creates the individual files on disk
<Pilky> that make sense?
<nomatter001> yes
<nomatter001> but how do i checkout the branch in itself on the server
<nomatter001> so that i have basically the same on the server as on my local disk
<Pilky> well you just do what I said, at the moment your branch that has been pushed has no working tree so you need to checkout it out to the location of the branch so you do
<Pilky> bzr checkout urltobranch urltobranch
<Pilky> that will checkout the remote branch to the location of the remote branch
<nomatter001> ok thx i'll try
<Pilky> then every time after that, after you push to the remote branch
<Pilky> you need to update the remote branch too
<Pilky> but if you use this push and update plugin (https://launchpad.net/bzr-push-and-update/) then every time you push, update will be called for you
<nomatter001> now i do get: sfp://... is not a local path
<nomatter001> so the checkout from remote to remote doesn't work
<Pilky> hmm, not entirely sure then, I mean I haven't done this myself but theoretically from the commands it should work
<Pilky> you'll probably be best askign one of the bzr devs
<nomatter001> Pilky: ok but how do i get to them?
<Pilky> it seems jam wrote the push and update plugin, but he isn't online at the moment
<Pilky> just look for people with these nicks: http://wiki.bazaar.canonical.com/IrcNicks
<__monty__> Can anyone tell me where ~/.bzr.log is written, in what module?
<nomatter001> Pilky: ok ic
<nomatter001> Pilky: thx so far
<__monty__> I understand that ~/.bzr.log is referred to as _trace_file in bzrlib, is this correct?
<NfNitLoop> nomatter001: Populating remote working trees isn't supported generally.
<nomatter001> NfNitLoop: so there is no way to do it?
<NfNitLoop> you can log in to the remote machine and do 'bzr checkout .' to create a working tree.
<NfNitLoop> there may also be an option to push these days?  Let me check...
<NfNitLoop> yep, `bzr help push` says:   The target branch will not have its working tree populated because this is both expensive, and is not supported on remote file systems
<nomatter001> NfNitLoop: so it's impossible?
<nomatter001> NfNitLoop: that it's expensive doesn't bother me
<NfNitLoop> with bzr, yes.  There are other tools that are more efficient for copying files.  rsync/scp...
<rubbs> nomatter001: I'm not sure what you are looking for but if you go to http://wiki.bazaar.canonical.com/BzrPlugins and look under publishing, it gives some plugins that can push and update remote dirs.
<NfNitLoop> rubbs: Oh!  Good to know.
<rubbs> no prob.
<rubbs> it's not a part of the core because of too many problems supporting remote systems. but if you have ssh access you can use most of the plugins IIRC
<NfNitLoop> nomatter001: I think one of the reasons it's avoided is that it gets complicated fast if there are changes in the remote files, which requires doing merges, possibly including conflicts.
<NfNitLoop> so you basically need to *read and write* the entire remote filesystem to do it safely.
<rubbs> nomatter001: I think automirror might be what you are looking for: http://doc.bazaar.canonical.com/plugins/en/automirror-plugin.html
<rubbs> nomatter001: if your looking to just upload the working dir and not worrying about all the history then check out "upload": http://doc.bazaar.canonical.com/plugins/en/upload-plugin.html
<krisives> Do we have a formal retort to http://whygitisbetterthanx.com ?
<NfNitLoop> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
<NfNitLoop> There's that.
<NfNitLoop> yeah, I read "why git is better than X" a while back and rolled my eyes at a lot of them.
<rubbs> It seems to be out of date.
<rubbs> it doesn't list what versions of each system they tested on.
<rubbs> bzr doesn't seem to be that slow anymore
<krisives> NfNitLoop: Agreed
<krisives> IMO git is more complicated
<NfNitLoop> WAY more complicated.
<NfNitLoop> I was just lamenting in here yesterday about having to use git-svn for something.
<rubbs> I also think that some of it is just wrong. like git's branching model is similar to the repo idea that bzr uses. No multiple directories with the same history or anything
<NfNitLoop> I wanted to push my changes into a branch.  So I had to tell git where my svn branches were.  So it re-fetched all of svn history.  And gave everything *new commit IDs*.  Which meant my existing branch was no longer related to where I wanted to push it.
<NfNitLoop> so I got to go become an expert in their rebase command to try to fix it.  >.<
<NfNitLoop> whereas with bzr-svn it would've just been "bzr svn-push <new-branch-location>"   <3
<__monty__> Where is ~/.bzr.log written?
<gutworth> where in the code base?
<__monty__> Yeah
<gutworth> bzrlib/trace.py I believe
<fbond> How can I get bzr stats to map e-mail addresses to something more useful than "Unknown"?
<__monty__> gutworth: Is .bzr.log written in mutter?
<gutworth> I don't know, is it :)
<gutworth> ?
<NfNitLoop> Hrmm, I always forget.  How do I log "patches in this branch not in OtherBranchX?"
<gutworth> bzr missing
<NfNitLoop> aha, thanks. :)
<NfNitLoop> I always try to fool with `bzr log -r <wacky Revisionspecs>`
<__monty__> gutworth: If you want to know, I think .bzr.log is written in push_log_file() , I don't really understand what mutter() does yet.
<gutworth> I see _trace_file.write() in mutter()...
<__monty__> You're right.
<__monty__> But _trace_file originates from push_log_file()
<__monty__> gutworth: I'm trying to solve this error: https://bugs.launchpad.net/bzr/+bug/257170 ; Am I looking in the right place?
<ubottu> Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]
<gutworth> __monty__: well, the arguments are printed in commands.py
<__monty__> gutworth: How did you find that, grepping?
<gutworth> no, I remember
<__monty__> gutworth: Why is there a while loop instead of a for loop in run_bzr()?
<gutworth> because it skips args in the loop
<__monty__> Can't you do that with for?
<gutworth> no
<gutworth> well, I suppose, but it would be uglier
<__monty__> gutworth: What do you think about this: http://python.pastebin.com/d9ad1c1a ?
<gutworth> __monty__: it's ugly
<gutworth> and not flexible
<__monty__> :-(
<__monty__> What are your criteria?
<gutworth> why do you care so much?
<__monty__> I don't really do.
<__monty__> gutworth: Where should I print the version number in .bzr.log?
<gutworth> before the arguments?
<__monty__> bzr arguments: [u'VERSION', u'...', u'...'] like this, gutworth?
<jwhitley> hi all, I'm not finding any tests for '**/...'  or regexp ignore patterns.  Am I just missing them, or do they need coverage?  not in test_ignores.py or test_is_ignored.py
<jwhitley> I'm about to start working on https://bugs.launchpad.net/bzr/+bug/428031, and can add tests for those cases while I'm at it...
<ubottu> Ubuntu bug 428031 in bzr ".bzrignore should support exclusions" [Medium,Confirmed]
<jwhitley> or perhaps I'll put it another way: is there some notable obstacle to having test_ignores/test_is_ignored cover '**/...' or regexp patterns?
<gutworth> __monty__: like that
<gutworth> jwhitley: can't hurt to have more tests
<__monty__> gutworth: So I just add the version as if it's an argument?
<gutworth> __monty__: how about the line before
<__monty__> gutworth: Bazaar version: x.x.x ?
<gutworth> sure
<__monty__> And in which function, module should I put it?
<gutworth> how about above bzr arguments?
<__monty__> ?
<jwhitley> gutworth: right, then.  I'll have a go at fixing up ignore test coverage while I'm at it...
<gutworth> __monty__: in commands.py
<__monty__> gutworth: right above trace.mutter(...) ?
<gutworth> yep
<__monty__> gutworth: And I do this via a call to trace.mutter() ?
<gutworth> yes
<jwhitley> ah, test_globbing has the ** and regexp coverage, but not related to ignores.
<__monty__> gutworth: To retrieve the bzr version, can I use bzrlib.__version__
<__monty__> ?
<gutworth> sure
<Peng> __monty__: Yeah, using bzrlib.__version__ or bzrlib.version_string (which are completely equivalent) is standard practice.
<__monty__> I get '2.1.0dev5' if I print bzrlib.__version__ , this is correct right?
<Peng> __monty__: Uh-huh.
<__monty__> Peng: If I wasn't clear enough, the dev... is only printed for my version, not for every version right?
<Peng> __monty__: Alphas, betas, release candidates and releases are indeed different.
<__monty__> Peng: Could you check my solution to this: https://bugs.launchpad.net/bzr/+bug/257170 ?
<ubottu> Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]
<Peng> __monty__: I'm not qualified to review tests, but sure.
<__monty__> How can I make a diff of my change? (it's only one line so I could just write it here)
<Peng> __monty__: Well, "bzr diff".
<__monty__> Peng: And I just copy the output?
<gutworth> push a branch
<Peng> Yeah. You'll have to do that eventually anyway.
<__monty__> To launchpad?
<gutworth> yes
<Peng> Or you could push it elsewhere and then have LP mirror it, but not many people bother with that. :D
<gutworth> __monty__: have you read http://doc.bazaar.canonical.com/developers/?
<__monty__> Partly
<__monty__> Should I push to lp:username/bzr/giveback, or .../giveback/somedescriptivenamehere ?
<NfNitLoop> lp:~username/bzr/descriptive-branch-name-but-not-too-long-like-this-one
<NfNitLoop> ;)
<NfNitLoop> just from what I've seen.
<NfNitLoop> maybe an actual dev has other preferences.
<__monty__> So no 'giveback' as suggested in HACKING.txt ?
<NfNitLoop> oh.  Ignore me then. :)
<gutworth> it doesn't matter hugely
<__monty__> NitLoop: I was just asking to be sure.
<__monty__> gutworth: What is the custom?
<Peng> __monty__: Look over https://code.launchpad.net/bzr to see what other people do.
<Peng> __monty__: The custom is to name it something descriptive and useful to you, like "log-bzr-version" or somesuch.
<Peng> __monty__: Some people like to include the version number it's intended for in the branch name.
<NfNitLoop> looks like some others include the bug number.
<Peng> Ah, right, forgot that.
<NfNitLoop> but that's a bit redundant since you can tie it to a bug.
<NfNitLoop> via launchpad.
<Peng> BTW, you can do "bzr commit --fixes lp:1234" to add a little meta data tying the revision to the bug.
<NfNitLoop> ooooh, cool.
<Peng> It's not actually very *useful*, though. But LP's branch scanner will automatically link the branch and bug together when it comes across it./
<__monty__> So I just do a commit --fixes lp:257170 to link the branch to this https://bugs.launchpad.net/bzr/+bug/257170 ?
<ubottu> Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]
<rubbs> yes
<rubbs> it will link up to that bug...
<__monty__> Ok, thanks.
<rubbs> so when you view the bug on lp you can see "related branches"
<rubbs> also if you are on the branch's page, you can see linked bugs
<__monty__> I get 'pointless commit' if I do a commit --fixes lp:257170 , what should I do, commit --unchanged ?
<gutworth> have you made any changes?
<gutworth> generally you commit the --fixes with any change you've made
<__monty__> I already commited my changes.
<Peng> __monty__: it's not worth trying to retroactively do it, then.
<Peng> __monty__: But you should keep it in mind for the future. :)
<__monty__> Oh ok
<Peng> Honestly, I forget --fixes most of the time. :)
<rubbs> __monty__: Peng is correct. It's not worth retroactivly doing, but you do --fixes at the commit.
<__monty__> Should I propose my branch for merging?
<Peng> __monty__: If it's ready, yes.
<__monty__> It solves the 'bug' so I believe it's ready.
<__monty__> What should the Target Branch be?
<Peng> __monty__: What is it a branch of? lp:bzr, lp:bzr/2.0? Whichever.
<Peng> __monty__: I mean, the target branch should be what it's a branch of.
<__monty__> Should the 'Cover letter' be written in Initial Comment ?
<__monty__> And what should I enter in Reviewer and Review type ?
<Peng> __monty__: For reviewer and review type, just go with the default.
<Peng> __monty__: for the cover letter, um, yes?
<__monty__> And review type may be empty?
<Peng> __monty__: That's the default. :D
<rubbs> __monty__: yeah, just put in your cover letter in the initial comment section. the reviewer and reviewer type can be left blank because you are not a reviewer. They are not manditory fields
<__monty__> Thanks everyone for all the help. :-)
<__monty__> Goodnight.
<rubbs> night
<__monty__> One more question, how do I create a patch with bazaar?
<rubbs> __monty__: do you mean like diff? you can use -p and specify old and new file names to create a patch.  see "bzr help diff"
<__monty__> Ok thank you.
<Peng> __monty__: "bzr send" can create a merge directive, which includes all of the metadata as well.
<Peng> __monty__: If you're talking about a Launchpad merge proposal, LP will create a diff automatically.
<__monty__> It's to add a comment to the page of the bug with the patch.
<rubbs> not neccissary. LP will do that for you
<__monty__> Oh, ok
<rubbs> Necessary*
<__monty__> Well, goodnight then.
<rubbs> night.
<Peng> _ -- darn, left.
<rubbs> haha.
<Peng> I was just gonna say "good night".
<Pilky> Peng: how rude of you not to ;)
 * Peng cries
<Pilky> Peng: don't worry, you can say good night to me when I go offline
<Pilky> though that won't be for another few hours, spending the evening in photoshop
<Peng> Pilky: Pre-emptively, "Good night, Pilky".
<Pilky> shame monty left though, what I'm working on might have interested him
<Pilky> http://dropbox.mcubedsw.com/skitchpics/BazaarX%20Commit.png
<rubbs> Pilky: that's pretty nice looking... what is it?
<Pilky> mockup for BazaarX, a bzr GUI I'm making for the Mac
<Pilky> I've restarted the project enough times already
<Peng> Next someone needs to make a GUI for the iPhone. ;D
<Pilky> so I'm going through and mocking up the entire UI before I write any more code
<Pilky> annoyingly just as everyone on the Mac is switching to Bzr, Git or Hg, there were two really good GUI clients for Svn released so I'm wanting to build an open source client of a similar calibre
<rubbs> Peng: you may be joking, but I thought about the possibility of at least a diff and log checker for my Android phone. Might even do it too
<Pilky> for comparison: http://www.versionsapp.com/ and http://zennaware.com/cornerstone/
<Pilky> Peng: doubt it would be that useful :p
<rubbs> Pilky: gotcha. sounds like a good idea. If I had a Mac to play on I'd thikn about helping out. but alas.. :(
<Pilky> iPhone optimised UI for launchpad though
<Pilky> that would be useful
<Pilky> might try it when I start my crazy rocketship project
<rubbs> agreed... a mobile version of lp could be very useful.
<Pilky> (I'm going to be building an alternate UI for launchpad)
<Pilky> which I swear is the last open source project I'm going to commit to, otherwise I won't have time to work on the code that brings in the money :p
<Peng> Pilky: Get Canonical to hire you. ;-D
<Pilky> heh, well these are mostly side projects that I'm doing to help my main stuff
<NfNitLoop> Pilky: Heh.  that screenshot's so nice I wanted to grab the sliders and play around with it. :p
<Pilky> heh
<NfNitLoop> I do so little development on my mac, though...
<NfNitLoop> I mean, I'll be typing on my mac.
<NfNitLoop> but it's into an ssh session somewhere else.
<Pilky> heh
<NfNitLoop> The only local dev. work I do is on my linux box here at work.
<Pilky> well all my dev work is done on my mac so a desktop client for bzr would help me a lot
<NfNitLoop> *nod*
<NfNitLoop> Mostly I was just QQing that I wouldn't get to use it. :)
<Pilky> well it likely won't be finished for a long time :p
<Pilky> at the moment it is just consisting of mockups
<NfNitLoop> aah.
<Pilky> anyway, time to get offline for the night
<Pilky> Peng: if you want to do the honours :p
<Peng> Pilky: Good night. :D
#bzr 2009-12-30
<piyo> hello. how can i "resume" an network-interrupted "bzr checkout"? I am checking out the official emacs repository
<piyo> no sorry, i mean "bzr branch"
<piyo> not "bzr checkout"
<gutworth> you can't really
<piyo> can i do something like, bzr branch sameurl different-local-dir?
<Peng> piyo: Certainly. But the data was lost when bzr exited.
<Peng> piyo: Probably. Most of it.
<piyo> because these newbie instructions are preping a "shared repository"
<piyo> so if i successfully complete the "bzr branch" with "different-local-dir", is it sufficient to just rename "different-local-dir" to "desired-local-dir" (e.g. trunk2-try -> trunk)
<bob2> should be ok
<bob2> there's a tarball you can download, I think
<bob2> which should be more easily resumable ;)
<piyo> :)
<piyo> :(
<piyo> ok ill give the tarball a looksee as well
<piyo> huh, the tarball seems to be delisted from that official newbie guide page
<piyo> http://www.emacswiki.org/emacs-se/BzrForEmacsDevs (but view in Google Cache)
<bob2> if it was hosted at notamigos, it's probably not useful
<piyo> it was http://bzr.notengoamigos.org/emacs-merges.tar.gz
<piyo> bob2: can you point to the tarball that you are referring to? or is it this undated page? http://bzr.notengoamigos.org/
<bob2> no idea, sorry
<piyo> ok thanks
<piyo>  >bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ trunk2
<piyo>  [#########-          ]  45123KB   129KB/s | Fetching revisions:Inserting stream
<piyo> :)
<Peng> piyo: For future reference, you can do it in chunks to limit the damage if your connection goes out, and to save RAM. "bzr branch -r 1000 ...; cd ...; bzr pull -r 2000; ..."
<piyo> oh yeah this is what im looking for
<piyo> thanks
<Peng> You could even script it.
<piyo> bzr pull has sane retvals?
<Peng> piyo: No idea.
<piyo> ok
<piyo> sorry, "sane" is vague. i mean 0 == ok, 1 == no-more-to-retrieve, etc
<Peng> Nonetheless, no idea.
<Peng> Oogh, I just sneezed incorrectly.
<piyo> ok
<piyo> when you say script it, do you mean in python, but not using process return values?
<Peng> Nah, I just meant a little loop in sh.
<piyo> ok thanks
<piyo> i think the -r requires an absolute value, amirite
<Peng> piyo: Yeah.
<piyo> :)
 * piyo idles
<Kamping_Kaiser> I've run 'bzr send', and its only showing me the first line of my commit message as the subject. is the rest of it hidden somewhere (in the bundle?) or is it ignored?
<ardian> Hi
<Supertanker> Hi; this has been bugging me for awhile: exactly where does Bazaar store its files? You know how SVN has those lovely .svn folders inside each working directory? What's Bazaar's equivilent? How does it keep track?
<Supertanker> I'm uncomfortable trusting my project when I don't know what is going on with my VCS.
<Supertanker> trusting my project to a VCS*
<Kamping_Kaiser> in a .bzr directory ...
<Supertanker> Are you serious?
<bob2> yes
 * Supertanker headdesks
<Supertanker> I cannot believe I forgot to look for hidden files
<Supertanker> Foot in mouth time
<bob2> however there's only one, in the root of the checkout/branch/repository
<Supertanker> Thank you so much :>
<Supertanker> Oooh, I like that.
<Supertanker> Much more convenient than in every subdirectory.
 * Kamping_Kaiser applies a trout to Supertanker 
 * Supertanker accepts being trouted before installing bzr on one of his development servers
<mlh> OTish, but I think svn is moving to a single .svn in the root, too
<Supertanker> Huh
<Supertanker> It'd be a great idea.
<Supertanker> Hmm, does bzr have any functionality similar to svn's 'svnadmin dump > backup' and 'svnadmin load < backup'?
 * Supertanker is considering using bazaar to keep track of the fifty billion drafts for his novel
<bob2> cp -a .bzr
<Supertanker> Hmmm, simple. I like it!
<Supertanker> Oh god, I'm tired. I just thought of using bazaar to keep track of bazaar updates
<Supertanker> backups*
<Peng> Then take backups of your backups . . . . ..
<Supertanker> And back them up too, just to be safe?
<Supertanker> And print them all out as ASCII too, just to have hard copy!
<Supertanker> Okay, last question for the night: what is the difference between init and init-repo? From what I see, each 'branch' is like an svn repository, and a 'repo' is...a collection of branches. right?
<Peng> Supertanker: A shared repository (created by init-repo) is a storage optimization. If you have two branches, it's a waste of disk space for both of them to have a copy of the entire history, right? So you put them in a shared repo, then there's only one copy.
<Peng> Supertanker: In bzr, on-disk, all a repository is is a big bag of revisions. They don't even have to be from the same project.
<Peng> Supertanker: A shared repository is just a repository that will be used by multiple branches below it in the directory tree.
<Supertanker> Ah, okay, that makes sense.
<Supertanker> So if I was using the feature branches setup, I'd have 'trunk' and 'myshinyfeature'. When I wanted to add code, I'd branch trunk as myshinyfeature, work on it, and then merge it back into trunk; both of them share a repository so bzr doesn't have to keep track of two seperate histories.
<Supertanker> Right?
<Peng> Supertanker: Two separate copies of what is largely the same history, yes.
<Peng> Supertanker: It's faster, too, since you aren't always copying a bunch of data around.
<Supertanker> Okay, that makes perfect sense
<Supertanker> Thanks!
<Peng> :D
<Supertanker> Ah, I tihnk I see
<Supertanker> I was wondering how to make 'container' directories, or if there was anything special to it like the way the manual suggests, but I apparently forgot about just plain 'mkdir'. :P
<luks> ok, this is embarrassing, but for some reason I can't push to launchpad and I can't figure out what's wrong
<luks> $ bzr push lp:bzr-pager
<luks> bzr: ERROR: Cannot lock LockDir(lp-64802192:///~luks/bzr-pager/pager/.bzr/branchlock): Transport operation not possible: readonly transport
<luks> $ bzr push bzr+ssh://bazaar.launchpad.net/~luks/bzr-pager/pager
<luks> bzr: ERROR: Cannot lock LockDir(lp-64802192:///~luks/bzr-pager/pager/.bzr/branchlock): Transport operation not possible: readonly transport
<luks> any ideas?
<Peng> That's an interesting one. I've got no idea. Tried --no-plugins?
<spiv> luks: is ~luks your lp username?
<luks> yes
<luks> well, luks is my lp username
<spiv> Right, yes.
<spiv> That's what I meant :)
<Peng> luks: Try bzr+ssh://luks@bazaar...
<luks> no, bzr+ssh://luks@... doesn't work either
<Peng> luks: You have angered the Launchpad gods. Sacrifice a goat.
<spiv> luks: add -Dhpss to the command line, and pastebin the resulting ~/.bzr.log ?
<spiv> I suppose it's possible that LP is having issues.
<luks> http://paste.pocoo.org/show/160547/
<Peng> Not any more informative.
<spiv> Well, it's clear that the server doesn't think you can write to that dir.  Which is very odd!
<Peng> I can't either. So it's an LP issue.
<Peng> I get the same error on one of my branches.
<spiv> But almost certainly an LP issue rather than bzr itself.  So ask in #launchpad, or file a question at https://answers.launchpad.net/launchpad-code
<Peng> spiv: Could you try it too?
<spiv> Peng: I could, but frankly I don't expect a different result, and I ought to be enjoying my holiday :P
<Peng> spiv: :D
<spiv> luks: (I've asked in #launchpad)
<spiv> Peng: fwiw, I *can* push a new bzr branch successfully.
<Peng> Huh.
<Peng> Argh.
<Peng> I screwed up. I tested locking a mirrored branch. Of course I can't do *that*.
<spiv> Oh.
<Peng> I just tried locking a normal branch, and it succeeded.
<spiv> Peng: ok, cool
<Peng> luks: Your branch is a mirrored branch too.
<spiv> Peng: oh, urgh.
<Peng> luks: You need to push to the bzr+ssh version of http://bzr.oxygene.sk/bzr-plugins/pager
<spiv> Peng: that's a horribly unclear error for bzr + lp to give in that case!
<Peng> :D
<spiv> luks: sorry about the unclear error, please do file a bug about that one, I'm sure we can do better.
<luks> ouch
<luks> I so totally didn't realize that
<luks> thanks Peng and spiv
<spiv> luks: neither did I
<Peng> :)
<luks> spiv: well, it's my branch, I should have known this :)
<spiv> luks: so much so that I was digging up the escalation policy for lp outages before I realised.
<Peng> At least the on-call losas should be awake at this hour. :P
<mindlace> or those of us in other countries
<spiv> Peng: happily I didn't get so far as ringing the relevant phone number and finding out...
 * spiv -> afk
<Peng> spiv: See you later. :)
<finno> Newbie question: Is there an easy way to rename my trunk branch? If I just rename the directory and update the nickname, is that enough?
<luks> unless you have set the nickname manually, you don't even need to do that
<luks> just renaming the directory should be enough
<finno> looks good thanks! I was expecting it to have updated the log entries but in hindsight that was a big misunderstanding.
<Kamping_Kaiser> whoever you were, impatient sydneysider, you do need magic if you pushed it somewhere
<juffo-wup> Hi people of bzr
<rubbs> hello
<juffo-wup> I'm trying to checkout from a ftp server (FileZilla) on Windows on another Windows box
<juffo-wup> But all I get is 'Operation timed out'
<juffo-wup> What could be wrong?
<juffo-wup> Sorry, connection problems.
<juffo-wup> Does anybody have any ideas?
<juffo-wup> It worked using HTTP.
<juffo-wup> But that won't do it, as it can't create directories on the server.
<rubbs> juffo-wup: are you able to copy down the directory from the FTP server with just plain FTP?
<rubbs> I'm wondering if it's some sort of connection or authentication issue
<juffo-wup> Yes, I can.
<juffo-wup> After I log on through bzr, FileZilla reports this:
<juffo-wup> '(000018) 30-12-2009 10:43:37 - nombre (146.83.216.214)> 227 Entering Passive Mode (146,83,216,159,5,181)'
<juffo-wup> (nombre is the user name)
<rubbs> well, we've reached the end of my usefulness (already, I know it sucks), but maybe someone like Peng or Jam can help.
<rubbs> if they're around
<rubbs> lot of people are on vacation right now
<juffo-wup> Ok, thanks rubbs.
<moldy> hi
<moldy> is there any useable zsh completion for bzr by now?
<juffo-wup> Bye.
<NfNitLoop> I should never read Slashdot comments. :p
<NfNitLoop> I read the Slashdot story about Emacs switching to bzr.
<NfNitLoop> and it's full of comments along the lines of "omg, git is better".   But they've all got outdated or incorrect info.
<NfNitLoop> which, is really par for the course for Slashdot comments anyway.
<NfNitLoop> but I feel obligated to test these cases that people claim are better in git. :p
<rubbs> I stopped reading /. a while ago. I didn't really get anything from it. People are just dumb and will fight you for no reason. You get a few nutjobs in there and the whole thing goes to pot really quick
<Peng> I stopped reading it because I hate the look of the new comment system.
<NfNitLoop> Oh, I actually like the look of the new comment system.  It's just the comments themselves I don't care for. :p
<Peng> :P
<NfNitLoop> One guy's complaint was that bzr didn't track cherrypicking.  But... as far as I can tell, neither does git.
<rubbs> everything always devolves into a fight there. It's not productive and a waste of my time.
<NfNitLoop> (which he weas proposing as an alternative)
<NfNitLoop> The only thing better about git's cherrypicking is that it copied the cherrypick'd revision's commit message.
<NfNitLoop> which is nice.  but... woo.
<NfNitLoop> so, I've got a possibly stupid question.    I've got my own branch of bzr (~2.0.4dev-something) with local modifications.
<NfNitLoop> I want to make a .deb out of it so I can install it into my ubuntu system and then use it with all of the other goodies that depend on it.
<NfNitLoop> I'm trying to run tools/build-packages.sh  but that seems to be downloading a pristine source .tgz from somewhere.
<NfNitLoop> which is not quite what I want. :p
<NfNitLoop> how do I just build my version as a .deb for my platform?
<Peng> bzr-builddeb, maybe?
 * Peng doesn't know
 * NfNitLoop reads up on builddeb.
<NfNitLoop> huh.  Reading builddeb's manual is making my eyes glaaze over.  I was hoping for 1 or two commands to turn this source tree into a .deb, I don't need to create source&diff debs and all that.
 * rubbs  has no idea how to build debs. He wishes he had time to figure it out.
<zsquareplusc> rubbs: "quickly create ubuntu-application; quickly package" ;-)
<zsquareplusc> NfNitLoop: well, bzr already has packages, so all the control files should be around. in that case builddeb should work with them
<NfNitLoop> aha, if I just run it by hand and don't pass the -S flag it doesn't try to build source debs.
<Pilky> any chance I could get some opinions on this? http://dropbox.mcubedsw.com/skitchpics/BazaarX%20Log.png
<james_w> wow
<Pilky> especially from any Mac users
<rubbs> Pilky: I think it looks good. is there any reason why the newist revisions are to the left? Most time lines run from left to right rather than from right to left
<NfNitLoop> looks cool.
<Pilky> rubbs: well, scroll areas usually default to the top left of the area and I figure you're more likely to want to see the most recent parts of the time line
<rubbs> that works enough for me. I think it looks great.
<Pilky> cool
<Pilky> of course the fun bit will come when I actually implement it
<Pilky> it's all good mocking it up, but I don't see this being an easy coding job :p
<rubbs> haha... true
<Pilky> and even harder than getting it to work is getting it to be efficient.
<NfNitLoop> Hrmm. no, builddeb fails because it wants to sign a deb.  >.<
<NfNitLoop> oh, yay, there is a simple way to build.  grab the debian/ dir from somewhere, plop it in place and call dpkg-buildpackage. :)
<phinze> is 'bzr up' the cheapest way to find out if there is new data available for a bound branch?
<phinze> i'm talking with a co-worker about keeping like 8 bound branches up to date, and we're trying to figure out how to make it a bit less clunky
<phinze> i suppose bzr up gets cheaper when there aren't changes to merge, but i was just wondering if there is an even cheaper check we can do first and make it a bit lighter
<phinze> basically something that would be able to avoid the N network loops for N branches, which seems to be where the bulk of the cycles are going
<phinze> ...i'll do a bit more digging, and perhaps do a mailing list post
<NfNitLoop> Hrmm.  'bzr svn-import' is a bit slower than 'bzr branch <svn-branch>'. :p
<NfNitLoop> Got a lot of "inconsistent details in skipped record" messages.  Kindof curious what that means.
<NfNitLoop> I found bug 418257, where spiv said it's not a bug.
<ubottu> Launchpad bug 418257 in bzr "inconsistent details in skipped record" [Medium,Confirmed] https://launchpad.net/bugs/418257
<NfNitLoop> I guess I don't know what "one repository has been reconciled and the other has not" means.
<spiv> NfNitLoop: actually, I never commented on that bug
<spiv> NfNitLoop: abentley replied before I looked at it
<spiv> NfNitLoop: "been reconciled" would mean "has had 'bzr reconcile' run on it"
<spiv> NfNitLoop: but if this is during a new import from bzr-svn, then abentley's comment wouldn't apply
<spiv> NfNitLoop: but... it would also most likely be a bzr-svn bug, not bzr itself.
<spiv> NfNitLoop: (although 'bzr reconcile' would have a fairly good chance of correcting it)
#bzr 2009-12-31
<__monty__> Could someone help me with this bug: https://bugs.launchpad.net/bzr/+bug/45599 , I'm trying to find the best error message possible for this issue, a few things have been suggested so far. Should I drop "No repository present:" or should I include it in the message?
<ubottu> Ubuntu bug 45599 in bzr ""no repository present" error should suggest using bzr branch" [Wishlist,Confirmed]
<redir> morning bzr
<redir> Is there a switch in bzr which would be the moral equivalent to git commit --amend?
<jelmer> redir: Hi
<redir> :)
<jelmer> redir: There isn't anything in bzr itself, but perhaps one of the plugins supports something like that
<redir> :(
<redir> I guess I should make feature request on launchpad. The two things I miss in bzr are --amend and git add -i
<jelmer> redir: fwiw bzr shelve is sort of the reverse of git add -i
 * redir looks at docs
<redir> ah right like git stash
<redir> jelmer: thanks
<naoki_> Happy new year! (from Japan, UTC+9)
<jelmer> hey naoki_
<Pilky> naoki_: Does 2010 have jetpacks?
<jelmer> naoki_: Thanks, happy new year to you too :-)
<Guest46284> hi there,  is it possible to create a checkout of only a few files from a repos
<gutworth> no
<Guest46284> ok thanks
<_monty_> Does anyone have a suggestion for what would be the best error message for this https://bugs.launchpad.net/bzr/+bug/45599 ?
<ubottu> Ubuntu bug 45599 in bzr ""no repository present" error should suggest using bzr branch" [Wishlist,Confirmed]
#bzr 2010-01-01
<methods> after i init a new repo can i make the files visible so as to expose it via http ?
<RAOF> methods: Once you've committed a revision containing âthe files" (whatever they may be) to the branch, they'll be visible over http (assuming the branch is already visible over http).
<methods> http://fly.thruhere.net/projects/fskn_ruby/
<methods> i don't see any files
<methods> what's the proper way to setup bzr+ssh ?
<bob2> methods: so, you pushed over bzr+ssh or sftp, right?
<bob2> they doesn't update the remote working copy (ie the checked out files)
<bob2> there's an 'update after push' plugin that does that
<Noldorin> hi
<Noldorin> i'm getting the following error when i try to push to LP:
<Noldorin> Permission denied (publickey).
<Noldorin> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Noldorin> seems to be a problem with pageant and the SSH key not being recognised
<Noldorin> anyone?
<Noldorin> <Noldorin>	i'm getting the following error when i try to push to LP:
<Noldorin> <Noldorin>	Permission denied (publickey).
<Noldorin> <Noldorin>	bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Noldorin> <Noldorin>	seems to be a problem with pageant and the SSH key not being recognised
 * maxb doesn't do Windows
<Noldorin> heh, that's the most typical reply i've had so far.
<jelmer_> Noldorin: looks like your ssh key on launchpad can not be found ?
<jelmer_> Noldorin: did you add any keys on launchpad ?
<Noldorin> jelmer_: yeah, i've had one on there for a while and it's always worked
<Noldorin> i tried reuploading it after the problems too
<Noldorin> jelmer_: https://launchpad.net/~noldorin
<Noldorin> i use Pageant to provide the key, so i'm wondering if bzr isn't communicating with pageant properly...
<maxb> Noldorin: Were you on Linux, I'd recommend trying 'ssh bazaar.launchpad.net' just to test the connection. Perhaps you can do something similar?
<Noldorin> maxb: cygwin perhaps?
<Noldorin> maxb: yeah, same result
<Noldorin> Permission denied (publickey)
<Noldorin> hmm...
<Noldorin> i wonder if that could be because it's using OpenSSH rather than putty's implementation
<Wellark[]> sigh.. I'm trying to find out how to fix the problem with updating missing signatures to remote repository..
<Wellark[]> no luck yet :/
<Wellark[]> probably need to add some command like 'sync-signatures'
<Wellark[]> don't know yet
<Wellark[]> the first thing to figure out is how to get new signatures from sign-my-commits to remote repository
<Noldorin> maxb: solved. turned out the problem was habing cygwin in my path :P
<LaserJock> anybody know of any possible way to make multi-pull give more info? or alternatively how to do recursive bzr pulls with some actual change info?
 * maxb uses a shellscript
<jelmer_> wellark[]: I'd recommend writing to the list about this
<jelmer_> wellark[]: I think push should be propagating new signatures
<LaserJock> maxb: for *every* branch?
<LaserJock> it seems like something that would be quite common to do, for instance, "pull from all branches in this repo"
<maxb> Well, I use multi-pull too, it varies
<jelmer_> LaserJock: I also have a shell script that basically does "for I in src/*/*; do bzr pull -d $I; done"
<maxb> I find multi-pull malfunctions trying to pull Launchpad
<maxb> I need to get around to debugging that
<LaserJock> multi-pull is good, but it gives like no info at all
<LaserJock> so most often I don't really know if a branch has changed or not
<LaserJock> so I end up running multi-pull and then going to individual branches I care about and do a bzr lesslog to see what actually changed
<LaserJock> which seems a little suboptimal to me :-)
<LaserJock> is there any way to get bzr to do a diffstat-like output for a log or pull  like how git does when you run git-pull?
<gutworth> bzr pull -v
<gutworth> oh, no
<Wellark[]> jelmer_: sure., I'll write to the list when I have the time
<njn> Does Bazaar work on Mac?
<jelmer_> njn: yep
<eydaimon> how do I unadd a file I added by accident?
<eydaimon> nm
<eydaimon> bzr rm --keep
<kfogel> no way to edit a commit message long after it's been published in bzr, right?  (since changes are replicated all around, this would be even conceptually very difficult)
<gutworth> right
<gutworth> unless you uncommit, but that's a bit icky
<kfogel> gutworth: thank you (yeah, I know about the uncommit case, but it's of limited use for the scenarios I'm thinking of)
<Colonel-Rosa> morning
<Colonel-Rosa> Are bzr branches to those like as seen in git? For example, could I do : bzr push ssh://blah unstable?
<gutworth> no, bzr branches aren't colocated
<Colonel-Rosa> Ok, so they act as seperate repositories?
<gutworth> sort of
<gutworth> you can have multiple branches in the same repo
<Colonel-Rosa> hmm
<maxb> Colonel-Rosa: Unlike git, in bzr, both branches and repositories exist in the filesystem rather than purely in the vcs's ui
<maxb> e.g. foo/ could be a bzr repo, and foo/bar/, foo/baz/ and foo/quux/ could be three branches in that repository
<maxb> On the other hand, bzr also allows the situation where a single branch is colocated with its repository
<Colonel-Rosa> Right, I was planning to have a stable and unstable branch of my website code. I wasn't using a shared repository before
<NfNitLoop> it's easy to change.
<NfNitLoop> create a repository, then branch into it.
<NfNitLoop> any other branches you create in there will share the repository.
<maxb> Don't even need to branch into it
<Colonel-Rosa> I think I'm being a bit confusing, sorry.
<Colonel-Rosa> I'll try and draw a diagram
<maxb> To convert a branch which is currently standalone to be using a shared repository, 'bzr reconfigure --use-shared'
<NfNitLoop> maxb: aah. but then you have a branch checked out into the root of a shared repository?
<maxb> NfNitLoop: No, that's impossible
<maxb> (or at least, I think it is)
<maxb> 'bzr reconfigure --use-shared' requires that a shared repository exists *above* the branch
<NfNitLoop> Oh, I managed to do it by pushing to that location once.
<NfNitLoop> maxb: aah.
<Colonel-Rosa> Explanation : I have 2 website locations, a "production" and a "staging". My problem arrose when I found a critical bug, but I had already pushed some new features to the repository, obviously I didn't to push out those new features so I was stuck. I'm using Capistrano to pull the code from the repo btw
<Colonel-Rosa> Does that make sense?
<jelmer> hi maxb, NfNitLoop
<maxb> Yes, other than I don't know what Capistrano is
<Colonel-Rosa> maxb, it's a website deployment system, it just pulls out code from a specified repository
<NfNitLoop> Colonel-Rosa: So what I would do in this case... is create a new branch based on your current production.
<NfNitLoop> fix the bug on that branch.
<luks> Colonel-Rosa: the only sane solution is to use multiple branches
<NfNitLoop> test it.
<luks> one for production, one for staging
<NfNitLoop> if it works, merge it into production and staging.
<NfNitLoop> then throw away the branch.
<maxb> Colonel-Rosa: So, 'staging' is a fairly permanent thing, of which there is exactly one? (Rather than something you can just start up extra instances on demand, using different code?)
<Colonel-Rosa> correct
<maxb> If so, I think you should have permanent "production" and "staging" branches which are your Capistrano deploy targets, and an arbitrary and variable number of extra branches for development not yet deployed
<Colonel-Rosa> ok, I'll give it a try
<Colonel-Rosa> thank you
<Colonel-Rosa> maxb, NfNitLoop http://i.imgur.com/pn2qw.png
<Colonel-Rosa> Is that right?
<whitley> hi all.  happy new year!  initial version of ignore exclusions and tests for same at lp:~whitley/bzr/ignore-exclusion
<whitley> I still need to update the the help, add one test I just thought of, and review for any edge-cases or unintended side-effects.  Still, getting close.
<jelmer> hey whitley
<jelmer> whitley,: what does that branch do exactly?
<whitley> Implements an extension to the .bzrignore syntax.  Patterns prefixed with an exclamation point (!) have priority and are NOT ignored.
<whitley> This is very useful for cases such as versioning one's home directory, /etc, and so forth, where most files are ignored, but some selected paths/files are versioned.
<whitley> see also bug 428031
<ubottu> Launchpad bug 428031 in bzr ".bzrignore should support exclusions" [Medium,Confirmed] https://launchpad.net/bugs/428031
<whitley> bug updated with current status.  later all!
<Jordan_U> Every command I run with bzr outputs 'No handlers could be found for logger "bzr"'.
#bzr 2010-01-02
<RAOF> Jordan_U: Got a read-only $HOME?
<Jordan_U> RAOF: No
<RAOF> Sure? :)  Lucid's been resuming with a readonly home for me on occasion ;)
<RAOF> ...and a read-only home is one trigger of that behaviour that I know.
<Jordan_U> RAOF: Yes, I have been working with files in $HOME without problems
<fullermd> Check ~/.bzr.log, make sure it's owned by you.
<Jordan_U> fullermd: Ahh, it's owned by root
<Jordan_U> Probably from trying to use etckeeper with bzr
 * Jordan_U Thinks etckeeper in Ubuntu should not default to using bzr untill bzr can properly deal with being run with sudo
<Jordan_U> fullermd: That fixed it, thank you
<Noldorin> hi
<Noldorin> i'm trying to install bzr-git on windows
<Noldorin> but am having no luck
<Noldorin> bzr plugins does not list it.
<Supertanker> Is there any reason I should not access a bzr branch stored on my Samba drive?
<bob2> do you have filenames with : in them or mixed caase?
<Supertanker> Shouldn't be for the first; for my projects, I use all lowercase names
<Supertanker> Er wait no.
<Supertanker> I don't use all lowrcase names
<Supertanker> But the Samba share is hosted on a Liknux box and I don't have files with the same names but different cases in the same directory
<Supertanker> (I do jhave a login.php in one directory and Login.php in another...)
<Supertanker> Yay, bzr for windows finally downloaded
<Noldorin> hi
<Noldorin> i'm trying to use bzr dpush to push to a GIT repo, but am having the following problem:
<Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
<Noldorin> ssh://git@github.com/Noldorin/IRC.NET.git
<Noldorin> bzr: ERROR: [Error 2] The system cannot find the file specified
<Noldorin> hi
<Noldorin> i'm trying to dpush using bzr-git
<Noldorin> getting the following error though:
<Noldorin>  http://pastebin.com/m78e07c36
<fullermd> As a guess, version mismatch.
<fullermd> That's a reasonably recent bzr-git, and a several version back bzr.
<GuyFromHell> anyone on gentoo know where olive-gtk is hiding?
<Supertanker> What is this "treeless branches" feature I keep reading about, and why is it important?
<fullermd> I dunno what you keep reading about, but a branch may or may not have a tree, depending on...  well, whether it has a tree.
<mneptok> GuyFromHell: https://edge.launchpad.net/bzr-gentoo-overlay/
<mneptok> GuyFromHell: bzr-gtk is part of that overlay
<GuyFromHell> mneptok, oo, shiny. I could not find it anywhere
<GuyFromHell> thank you
<mneptok> np np
<Supertanker> fullermd, what exactly is "tree" referring to?
<fullermd> The working tree, where you edit and read and touch and caress-by-the-fireside your files.
<Supertanker> Ah, okay
 * SamB_XP can't help but remember something about some windows pack-in called "wang" ...
<fullermd> If you have a branch with a [colocated] tree, you can get rid of the tree with 'bzr remove-tree', and you can get it back with 'bzr checkout'
<fullermd> (and some args to reconfigure also, I believe)
<pattern> i just did a "bzr add myfile", but then noticed that i'd misspelled the filename
<pattern> i haven't committed yet, so is there some way to "unadd" the file?
<fullermd> Well, if you handed it a filename that doesn't exist, it shouldn't have done anything...
<pattern> it does exist
<pattern> but there's a misspelling in the filename
<pattern> so i need to rename the filename
<pattern> and "unadd" it from bzr, then add it again with the right name
<pattern> then commit
<pattern> i just don't know how to "unadd" it
<fullermd> Why unadd/readd, instead of just 'bzr mv'ing?
<fullermd> Anyway, you'd use 'rm' to unadd.
<pattern> i tried rm and it complained about not being able to safely remove the file
 * fullermd stabbies the !@&$ DWIM crap in there.
<fullermd> rm --keep
<fullermd> (and then add a bzr alias for it so it stops trying to outsmart you ever afreakingain  :p)
<pattern> thanks, fullermd
<Noldorin> hello
<Noldorin> i'm trying to use bzr-git to push a bzr branch to a git repo
<Noldorin> however, i'm geting some horrible errors...
<Noldorin> bzr: ERROR: exceptions.AttributeError: 'InterRepository' object has no attribute
<Noldorin>  'fetch_objects'
<Noldorin> the full log is here: http://pastebin.com/m78e07c36
<bob2> are you using dulwich,bzr-git and bzr trunk?
<Noldorin> bob2: indeed i am
<Noldorin> i believe everything is installed correctly, though i had some trouble yesterday...
<fullermd> Not on the latter you aren't.
<fullermd> bzr 1.17 on python 2.5.2 (win32)
<Noldorin> oh, that's true
<Noldorin> odd
<Noldorin> i'm sure i had bzr 2.0 installed
<bob2> you may well need actual bzr bzr
<Noldorin> bob2: how do you mean?
<bob2> as in bzr trunk
<Noldorin> ah right
<Noldorin> hmm
<Noldorin> brb, restarting
<jelmer> fullermd: What's the status of DWIM?
<fullermd> vila landed it a few weeks ago.
<maxb> Is there anything along the lines of architecture documentation for Bazaar? e.g. anything that helps understanding the internals?
<jml> maxb, maybe in the HACKING guide or in the developer doc section
<jml> maxb, in the tree, that is.
<jml> maxb, I've mostly got a sense of things from looking at commands in bzrlib/builtins.py and drilling down.
<SabreWolfy> Using Ubuntu Karmic and trying to install bzr-explorer, but conflicts with qbzr version preventing this; latest qbzr version in Karmic is 0.14; bzr-explorer needs 0.17
<SabreWolfy> any suggestions ?
<SabreWolfy> Adding QBZR PPA solved
<Noldorin> hi
<Noldorin> i hqave bzr 2.0 installed
<Noldorin> but for some reason, when i run bzr from the command line, it uses version 1.17
<Noldorin> looks like i have bzr 1.17 in my path somewhere, but i can't figure out where :S
<Noldorin> anyone?
<verterok> Noldorin: 'bzr version' should show the path to the executable and bzrlib
<Noldorin> hmm ok
<verterok> Noldorin: ops, only the bzrlib path
<Noldorin> verterok: c:\Python25\lib\site-packages\bzrlib
<Noldorin> yeah
<Noldorin> surely i want the one on program files though?
<Noldorin> if i do...
<Noldorin> "C:\Program Files\Bazaar\bzr.exe" version
<Noldorin> i get v 2.0.3
 * Noldorin gets out procmon
<verterok> Noldorin: check in c:\Python25\Scripts
<Noldorin> ok
 * verterok goes to the grocery store, brb
<Noldorin> verterok: seems to be a bzr in there
<Noldorin> should i remove it?
<Noldorin> ah, removing it does the trick :)
<Noldorin> thanks
<Noldorin> not bzr says it can't find dulwich :S
<Noldorin> yet it's in the python path
<verterok> Noldorin: if you'r using the standalone bzr.exe I think you need to install plugins in a different place as bzr.exe use it's own python interepreter
<Noldorin> verterok: yeah, so it seems
<Noldorin> any idea what i need to do with dulwich?
<Noldorin> since i want the bzr binary to use it
<Noldorin> well, bzr-git actually
<Noldorin> verterok: i've pasted the git and dulwich folders into C:\Program Files\Bazaar\plugins
<Noldorin> but it's not recognising dulwich still
<Noldorin> No module named dulwich.errors
<Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
<Noldorin> bzr: ERROR: Unable to import library "dulwich": bzr-git: Please install dulwich,
<Noldorin>  https://launchpad.net/dulwich
<fullermd> dulwich isn't a bzr plugin, it's a python module/library/whatevertheycallit.
<fullermd> I don't think you can use such things with the prebuilt bzr.exe; you'd have to use the python version.
<Noldorin> fullermd: yeah, that's what i was thinking
<fullermd> (Or I could be full of bullcaca; I don't really know windows)
<Noldorin> was wondering why bzr-git was looking for it in plugins there
<Noldorin> heh
<Noldorin> fullermd: i think you may well be rigtht - i may need the python version
<Noldorin> fullermd: hrm, can't i just edit the PYTHONPATH for bzr.exe somehow?
<Noldorin> http://osdir.com/ml/bazaar/2009-11/msg00361.html
<fullermd> I'm not sure you can; bzr.exe bundles it all up internally.
<Noldorin> hrm
<Noldorin> fullermd: so you recommend i just set up the python version of bzr 2.0, etc.? will it happily coexist along side the exe version?
<fullermd> I have no idea.  It's been 13 years since I had a system running Windows.
<Noldorin> hah ok
<fullermd> I'd tend to think having both would be sticky.
<fullermd> But it may not be.  I'm well into "guessing" territory there.
<Noldorin> mm, as am i
<Noldorin> fullermd: if i only have either in my PATH, then things might be ok
<Noldorin> brb
<Guest46284> hi. Is there a way of finding out what "bzr update" will do without actually running it
<Noldorin> hello. do i need the python installation of bzr to run bzr-git/dullwich?
<maxb> Is Bundle Buggy genuinely still alive, or does HACKING.txt lie?
<pattern> i have a question regarding how best to do something with bzr...
<pattern> it's a little long, though... so rather than flooding the channel, i've pasted the question here:  http://paste.pocoo.org/show/161426/
<gutworth> pattern: you can just commit specific files
<gutworth> or use a makefile which will only rebuild things if there is a change
<gutworth> or make an ignored file where you list files to ignore
<pattern> well, i could use a makefile that ignores files that aren't changed... however, LaTeX will still read them all to create the new pdf... so it doesn't really help
<pattern> the only way to have those files not read by LaTeX is either to comment out the code that includes them, or to delete that code
<gutworth> commit specific files then
<pattern> i do commit each individual file in bzr
<pattern> but the problem is more with the files that have the code that includes the individual files
<pattern> they're like #include directives in c
<pattern> and i have those lines commented out while i'm working
<pattern> each of those include directives is just \include{foo}, where "foo" is the filename
<pattern> so it's not like the file that has these include directives actually contains the whole file it's "including"
<pattern> it's just a direction to the compiler to include the file
<pattern> the contents of those files are completely seperate from the file they're included in
<pattern> and both the file that's doing the inclusion and the included file are seperately versioned in bzr
<gutworth> well, that's tricky
<pattern> yep :)
<gutworth> there must be some way to avoid rebuilding deps if they're not changed
<pattern> that's why i come to the experts :)
<pattern> i'm pretty sure there's no way to avoid rebuilding the files that haven't changed other than either commenting out or deleting the include directives
<pattern> actually.. there might be another way
<pattern> i think LaTeX has some control flow commands, which i haven't been using yet
<pattern> but i should look in to them
<pattern> that way it could maybe skip a part of the file if a variable is set
<pattern> that would be idea
<pattern> ideal
<pattern> then the variable could be set from the makefile
<pattern> and make could be told to set this variable from the command line
<pattern> that would be perfect
<pattern> hmm... but now that i think about it... it might not solve the problem after all
<pattern> as, say i bracketed off files 1-95 as being compiled or not depending on a variable... and check that version of the include file in while i worked on files 95-100
<pattern> at some point i'll want to bracket off files 1-100 while i work on files 100-105 instead
<pattern> and that will entail rewriting the code in the include file
<pattern> unless maybe i think of some way to reduce the granularity such that i can somehow include each individual file or not, from the command line
<Noldorin> hi. do i need the python installation of bzr to get bzr-git/dulwich to work on windows?
<pattern> anyway... this gives me some leads...
<pattern> thanks for your help, gutworth!
<Noldorin> getting the following error at present: http://pastebin.com/m3a6a2e4e
<maxb> How alive/dead is the BundleBuggy project now that bzr itself no longer uses it?
<Noldorin> >	hi. do i need the python installation of bzr to get bzr-git/dulwich to work on windows?
<Noldorin> bob2: ping?
<bob2> I don't have an answer
<bob2> I was just wondering if you'd asked on the list
<bob2> lots of people are on holidays atm so might not see discussion on irc
<Noldorin> yeah, good point
<Noldorin> probably worth a shot
<Noldorin> bob2: it's a pain to set some of this beta stuff up when you don't know much about python (as i don't)...
<Noldorin> it seems it's just dulwich that's causing the problem
<Noldorin> i want bzr.exe to recognise it in the path
<Noldorin> hrm
<pattern> gutworth: i finally figured out a solution for my problem... what i'll do is keep all the include directives uncommented in files A and B, and then have my makefile run them through a filter that will comment out what i need and save the output under a new name, say A2 and B2
<pattern> A and B will be versioned, but A2 and B2 will not
<pattern> and A2 and B2 will be the files that latex uses to compile
<pattern> of course, what the script run by the makefile comments out will depend on what options i pass to make on the command line
#bzr 2010-01-03
<sirpengi> is there a way to fetch a branch but not pull any history?
<bob2> --depth
<bob2> hm, maybe it only works for clones
<sirpengi> i don't seem to be able to find any documentation about --depth
<bob2> oops, wrong channel, sorry =)
<sirpengi> anyhow, I think what I'm looking for is --lightweight checkout
<bob2> I don't think "history horizons" has been implemented yet, but the lightweight checkout plugin might be good enough
<bob2> or you could stack
<sirpengi> what do you mean by stack?
<bob2> http://doc.bazaar.canonical.com/latest/en/user-guide/stacked.html
<sirpengi> ohh, nifty
<sirpengi> that'll involve me finding a place for the stacked branch though...
<sirpengi> well, I'll see if the lightweight checkout works...
<maxb> Noldorin: Funnily enough, I just needed to replace my system dulwich with a newer version
<Noldorin> maxb: oh right?
<Noldorin> you on linux though, i take it?
<maxb> I came up with the idea of creating a file .bazaar/plugins/AAAusedulwich.py containing "import sys; sys.path.insert(0, '/my/path/to/dulwich')
<maxb> Seems to work :-)
<Noldorin> oh cool
<Noldorin> i was thinking something along those lines too, but don't know any python, so meh
<Noldorin> maxb: also, are you using the binary/python version of bzr?
<maxb> I don't think that question has any meaning on Linux
<Noldorin> maxb: heh, fair enough
<Noldorin> maxb: i'll give that a go shortly. thanks for the tip :)]
<Noldorin> maxb: wait. this AAAusedulwich.py file... it's just in C:\Program Files\Bazaar\plugins ?
<maxb> I imagine that would be the relevant windows location
<Noldorin> maxb: ah ok. what's with the AAA bit...?
<maxb> To make it sort first
<Noldorin> ah fair enough
<Noldorin> maxb: i get this error now:
<Noldorin> No module named protocol
<Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
<Noldorin> bzr: ERROR: exceptions.AttributeError: 'InterRepository' object has no attribute
<Noldorin>  'fetch_objects'
<jelmer> hi Noldorin
<jelmer> Noldorin: did you see my reply to your bug comment?
<Noldorin> hi jelmer
<Noldorin> yes i did. i was just going to do a bit more testing before i replied :)
<Noldorin> jelmer: i noticed shortly after that it seems to be a problem with dulwich
<maxb> Noldorin: uhm, it shouldn't be loading dulwich itself as a plugin
<maxb> if you have a C:/Program Files/Bazaar/plugins/dulwich, get rid ot it
<maxb> *of
<Noldorin> hmm
<Noldorin> maxb: but i don't...
<Noldorin> i did previously, but i deleted it then
 * maxb is confused, then
<Noldorin> yeah, odd...
<Noldorin> jelmer: just update the bug report: https://bugs.launchpad.net/bzr/+bug/449507
<ubottu> Ubuntu bug 449507 in bzr-git "bzr-git causes crash in bzr when sync'ing to directory" [Undecided,Incomplete]
<andrewblack> I am prob being dense, is there a command to give a list of all files in the repository
<chx> hi. i want to back out a revision that changed lots of stuff ... 700+ revisions ago. I have reverted to the previous revision and planning to apply the revisions since in a loop. i was thinking to do a 'dry run' check for error and if it applies flawlessly then apply otherwise record for later manual work.
<fullermd> chx: Well, if by 'reverted' you mean 'bzr revert', it's almost certainly not doing what you think it is...
<fullermd> chx: Sounds more like a rebase-type operation.
<fullermd> andrewblack: You presumably mean 'in a branch', not 'in a repository'.  See "bzr ls".
<andrewblack> cheers fullermd .  i havent quite got hang of bzr terminology
<fullermd> andrewblack: Generally, anything you do, you do it to a branch or a working tree; you almost never do anything to a repository directly.
<andrewblack> ok.   ls -V does what i want.  ls by itself gives unknown files too whic confused me
<Noldorin> jelmer: hello?
<jelmer> Noldorin, hi
<Noldorin> hey
<Noldorin> jelmer: i saw youre reply to the bug report...
<Noldorin> wondering how my installation of dulwich got borked though....
<Noldorin> if you could help me figure out how it needs to be setup on windows, that would be great.
<jelmer> Noldorin: I've never used it on Windows I must admit
<Noldorin> jelmer: hehe ok
<Noldorin> jelmer: well what would you suggest i do if i were on linux?
<Noldorin> (maybe i can translate for windows)
<jelmer> Noldorin, I'd run "python setup.py install" in the dulwich source dir
<jelmer> Noldorin: and copy bzr-git to ~/.bazaar/plugins/git
<maxb> jelmer: ooi, what would you suggest for a per-user install of dulwich?
<jelmer> maxb: I've aliased bzr to 'PYTHONPATH=$PYTHONPATH:/home/jelmer/pylib /usr/bin/bzr'
<maxb> Ah. I've done sys.path manipulation in ~/.bazaar/plugins/AAAusedulwich.py
<Noldorin> jelmer: sorry, lost internet conn
<jelmer> Noldorin, did you see my reply?
<Noldorin> jelmer: looks like using cygwin to compile puts things in the wrong place
<Noldorin> http://pastebin.ca/1736212
<Noldorin> Noldorin: and copy bzr-git to ~/.bazaar/plugins/git
<Noldorin> that's the last message i got ^
<Noldorin> jelmer: look right/wrong to you?
<jelmer> Noldorin: So far
<Noldorin> jelmer: don't i really want the .egg in C:\Python25\... though?
<Noldorin> i'm still getting No module named dulwich.errors
<Noldorin> when i dpush
<jelmer> Noldorin: If you want the egg in c:\python25 I don't think you should be using cygwin
<Noldorin> jelmer: yeah...i really want to run the bzr on windows in (c:\program files) to use bzr-git
<jelmer> Noldorin: are you using bzr in cygwin?
<Noldorin> what is the alternative?
<Noldorin> i don't have VS 2003...
<jelmer> Noldorin: in that case, you shouldn't be using cygwin - that's completely independent
<Noldorin> ok
<Noldorin> i guess i just wanted to use cygwin for the GCC compiler
<Noldorin> hmm
<jelmer> Noldorin: binaries generated by that C compiler won't be usable with the python in c:\python25
<Noldorin> i sere
<Noldorin> see*
<Noldorin> i don't even know if c:\program files\bazaar\bzr.exe uses the python in c:\python25 though
<Noldorin> what i really want is to install bzr-git and dulwich *for bzr.exe in program files*
<Noldorin> i think i have succeeded with bzr-git, but not dulwich...
<jelmer> Noldorin: bzr-git doesn't require compilation
<Noldorin> jelmer: indeed. just pasting it into c:\program files\bazaar\plugins seems to work
<jelmer> Noldorin: you might want to ask on the mailing list about this issue, I'm afraid I don't know enough about the bzr windows installer
<Noldorin> hmm ok
<Noldorin> jelmer: by the look of it, i need to use VS 2003 to compile though no?
<jelmer> Noldorin: Yeah, I think you need to compile with the same comp[iler that was used to compile the rest of bzr
<Noldorin> unless i can somehow get bzr-git to use the *uncompiled* (python source) of dulwich
<Noldorin> ok
 * Noldorin thinks it should really be looking for VS 2008 nowadays
<jelmer> Noldorin: Yeah, you should be able to use dulwich without the extension as well
<jelmer> Noldorin: but that'll be slower
<Noldorin> yeah..
<Noldorin> not the biggrest problem atm
<Noldorin> jelmer: any idea how to tell bzr-git to use dulwich source rather than binaries?
<Noldorin> (if possible)
<jelmer> to do that, copy the 'dulwich' directory from the dulwich source tarball to some path that is in your python path
<jelmer> Noldorin: if the extensions aren't there it should just not use them
<Noldorin> right
<Noldorin> jelmer: in this case i now get...
<Noldorin> No module named protocol
<Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
<Noldorin> bzr: ERROR: exceptions.AttributeError: 'InterRepository' object has no attribute
<Noldorin>  'fetch_objects'
<Noldorin> dulwich relies on a module called 'protocol' perhap?
<jelmer> Noldorin: Where is the "No such protocol" bit raised from?
<jelmer> ~/.bzr.log should be able to tell you
<jelmer> Noldorin: You shouldn't install dulwich in your plugins directory
<jelmer> (that might explain the error, actually)
<Noldorin> jelmer: oh, there's a traceback too
<Noldorin> jelmer: it iwsn't installed in plugins. at least, i don't think so
<Noldorin> if it is, maybe i need to uninstall it somehow...
<jelmer> Noldorin: the error suggests otherwise, is there no C:/Program Files/Bazaar/plugins/dulwich directory?
<Noldorin> jelmer: nope :S
<Noldorin> http://pastebin.com/m406420d5
<jelmer> Noldorin: See line 4, there's a plugin there
<Noldorin> jelmer: there is a C:/Program Files/Bazaar/plugins/git dir but definitely no C:/Program Files/Bazaar/plugins/dulwich :S
<jelmer> Noldorin, do you still get that error if you remove the git directory ?
 * Noldorin tries
<Noldorin> jelmer: yep
<Noldorin> slightly different but similar:
<Noldorin> No module named dulwich.errors
<Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
<Noldorin> (dulwich.errors instead of protocol now)
<jelmer> Noldorin: Any other places on your system where you might've installed dulwich ?
<Noldorin> jelmer: i'll do a search
<Noldorin> jelmer: this is really weird: windows explorer shows nothing in C:\program files\bazaar\plugins, but ls does :P
<jelmer> well, that certainly explains a lot :-)
<Noldorin> heh yep
<Noldorin> jelmer: 'cannot find module' error is gone now :)
<Noldorin> now just one more...
<Noldorin> http://pastebin.com/m4ceb1ad2
<Noldorin> jelmer: bzr-git should be using the dulwich source under c:\libs\dulwich-0.4.0
<Noldorin> obviously, there is another version (compiled) under c:\cygwin\lib\python2.5\site-packages ...
<Noldorin> but that's not being used i think
<Noldorin> ping?
<Noldorin> hi jelmer. what's the last message of mine you got?
<jelmer> <Noldorin> now just one more..
<jelmer> <jelmer> Noldorin, what's left?
<Noldorin> jelmer: http://pastebin.com/m75bfdf4c
<Noldorin> jelmer: i.e. now i *only* have the error given in https://bugs.launchpad.net/bzr-git/+bug/449507
<ubottu> Ubuntu bug 449507 in bzr-git "bzr-git causes crash in bzr when sync'ing to directory" [Undecided,Incomplete]
<Noldorin> (whereas before i had multiple errors)
<jelmer> Noldorin: can you paste "bzr info" again for the source and target repositories?
<jelmer> s/repositories/branches/
<Noldorin> sure
<Noldorin> jelmer: http://pastebin.com/m1bccdfbd
<Noldorin> sorry, clipboard fail
<Noldorin> try http://pastebin.com/m6f1205ca
<Noldorin> jelmer: the second paste is correct
<jelmer> Noldorin: I think you might need to upgrade to a rich root format before you can push
<Noldorin> jelmer: hmm i see.
<jelmer> Noldorin: The source branch, that is
<Noldorin> no idea what that is/how to use it. :)\
<jelmer> Noldorin: in the source branch, run "bzr upgrade --2a"
<jelmer> and then try the dpush again
<Noldorin> jelmer: could this cause any problems elsewhere?
<jelmer> Noldorin: If you push to other branches they need to be in the 2a format (or something newer) as well
<Noldorin> oh fair enough
<Noldorin> well what's the newest?
<Noldorin> i might as well upgrade to that :)
<Noldorin> jelmer: "No new revisions to push." - i guess this means success
<jelmer> Noldorin: 2a is the newest
<Noldorin> ok great
<Noldorin> jelmer: well, only issue remaining now is to push to github
<Noldorin> i'm trying this:
<Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
<Noldorin> ssh://git@github.com:Noldorin/IRC.NET.git
<Noldorin> Permission denied (publickey).
<Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
<Noldorin> i have my SSH key in pageant, so i'm not sure of the problem...
<jelmer> Noldorin, that's not a valid URL
<jelmer> Noldorin, you need a / rather than a : after the hostname
<Noldorin> ah right
<Noldorin> same error...
<jelmer> Noldorin: what error exactly?
<Noldorin> what i just pasted: bzr: ERROR: The remote server unexpectedly closed the connection.
<Noldorin> erm
<Noldorin> Permission denied (publickey).
<jelmer> bzr-git should be using the same ssh keys that bzr itself would use
<Noldorin> that's what i thought hrm
<Noldorin> must be the URL wrong still?
<jelmer> no, the URL looks ok
<jelmer> Noldorin is your username on github?
<Noldorin> jelmer: yes
<Noldorin> jelmer: the project is http://github.com/Noldorin/IRC.NET
<jelmer> Noldorin: No idea then, sorry
<Noldorin> no worries
<Noldorin> jelmer: maybe i need to do http://github.com/blog/180-local-github-config ?
<jelmer> Noldorin: no, the API isn't relevant here
<jelmer> and bzr-git doesn't use the git config
<Noldorin> jelmer: hmm. who *should* i ask about this then?
<Noldorin> it doesn't seem to be a git problem heh
<jelmer> Noldorin: does pushing to e.g. launchpad work ok?
<jelmer> does pushing using git to github work?
<Noldorin> jelmer: yep
<Noldorin> in both cases, no problemxs
<jelmer> Noldorin: the other people on the general mailing list or on the bzr-windows mailing list might have aan idea
<Noldorin> ok
<Noldorin> it's odd tha this problem should be occuring
<Noldorin> jelmer: i just tend to think if you, the author of the lib, doesn't know, then who does ;)
<Noldorin> maybe i can turn on verbose to get some debugging info or such?
<jelmer> Noldorin, I haven't written the ssh bits
<jelmer> Noldorin: we're just calling out to the generic functionality in bzrlib for that
<jelmer> and there's windows-specific code in bzrlib for handling ssh
<Noldorin> jelmer: mm, fair enough
<Noldorin> jelmer: it would be helpful to see *which* ssh key it's trying to use though
<Noldorin> if i can somehow
<Noldorin> jelmer: i will try #git, then maybe the mailing list. thanks for all your help :)
<jelmer> Noldorin: does ssh'ing into that server work?
<Noldorin> i look forward to the next release of bzr-git..
<Noldorin> jelmer: erm...will try now
<Noldorin> jelmer: "no supporteed auth methods available"
<Noldorin> on putty
<jelmer> Noldorin: looks like the keys aren't available
<Noldorin> jelmer: well pageant is running, and i can push to bzr
<Noldorin> launchpad*
<jelmer> Noldorin: github doesn't seem to have them then
<Noldorin> ah
<Noldorin> hm
<Noldorin> jelmer: oh, it seems i *cannot* push with normal bzr to launchpad now :S
<fullermd> You upgraded in the middle?
<Noldorin> fullermd: what do you mean?
<fullermd> Since the last time you could.
<Noldorin> upgrade the branch, yep
<fullermd> No, upgrade bzr.
<fullermd> Specifically, across 2.0.0, which stopped using Putty as the default ssh implementation on Windows.
<Noldorin> fullermd: oh i see.
<Noldorin> yes i have indeed
<Noldorin> fullermd: so how can i tell it to use putty/pageant now?
<Noldorin> or should i be using something else?
<fullermd> BZR_SSH env variable (or some name like that)
<Noldorin> fullermd: set BZR_SSH = plink for putty right?
<fullermd> Your guess is as good as mine   8-}
<Noldorin> fullermd: gah, i get an error 2 now :(
<Noldorin> when pushing
<Noldorin> bzr: ERROR: [Error 2] The system cannot find the file specified
<jelmer> Noldorin: bzr can't find the ssh/plink executable locally I think
<fullermd> Rule 16: If you can't solve the problem, redefine the error.
<fullermd> My work here is done.
<Noldorin> jelmer: i need to put c:\program files\putty in my path then?
<Noldorin> fullermd: :P
<Noldorin> hehe
<Noldorin> jelmer, fullermd: http://pastebin.com/m1064404a - hmm?
<fullermd> 'bout what it says, I reckon.
<fullermd> You can't interact with the ssh process through bzr, so you can't agree to accept the host key.  Have to invoke it manually to do that.
<Noldorin> fullermd: seems to be thsi problem here: https://bugs.launchpad.net/bzr/+bug/237297
<ubottu> Ubuntu bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix]
<Noldorin> but i don't understand the solution
<fullermd> Use plink to manually connect to LP, so you ahve to chance to accept the key.
<Noldorin> fullermd: meh, seems i should really be using paramiko now
<Noldorin> installed it, but i see no info how to configure it for my key :S
<Noldorin> documentation is somewhat lacking there it seems
<Noldorin> bah
<Noldorin> putty was so much easier to use
 * fullermd finds openssh nice and easy to use   :p
<Noldorin> fullermd: yeah, it's all good on linux, but windows is a different story :P
<Noldorin> fullermd: if you can point me to a guide for paramiko on windows, that would be good heh
<luks> Noldorin: how did you use your key with putty?
<Noldorin> luks: just ran pageant and added the PPK file
<luks> the same will work for paramiko
<luks> it will use the key from pageant
<Noldorin> doesn't seem to :(
<Noldorin> luks: Permission denied (publickey).
<luks> I'm afraid I can't help with finding the problem, but it's supposed to work
<luks> (I know, because I submitted a patch for bzr a long time ago to enable it)
<Noldorin> ah right
<Noldorin> hrm
<Noldorin> luks: who might be able to suggest a solution then?
<fullermd> jam might be a good bet.  He may be back around tomorrow.
<Noldorin> ok
<Noldorin> thanks anyway
<luks> Noldorin: check your .bzr.log
<luks> it should say that it's using paramiko, and then list all available keys in messages like "Trying SSH agent key ..."
<Noldorin> luks: hrm
<Noldorin> 3.000  ssh implementation is OpenSSH
<Noldorin> could be the problem :P
<luks> :)
<Noldorin> i thought it default to paramiko though, no?
<luks> I don't know
<luks> BZR_SSH=paramiko should fix it
<Noldorin> yep, just doing that now
<Noldorin> luks: success. thanks very much
<luks> I just noticed that you mentioned you were using cygwin
<luks> adding the key to your cygwin's ssh config would be another solution
<Noldorin> luks: was just using cygwin to compile stuff
<Noldorin> normally on native windows though
<luks> is it not in %PATH%?
<Noldorin> it is
<luks> it obviously tried *some* openssh ssh client
<Noldorin> mm
<Noldorin> ok, so it's just github not recognising my ssh key now...
<Noldorin> bah
<saedelaere> hi, when i do [bzr info] i see among other things
<saedelaere> "Repository branch (format: unnamed)"
<saedelaere> what does "format: unnamed" mean, and is this ok?
<fullermd> Yes, it's fine.
<fullermd> It means bzr doesn't have a rollup name for what you have there.
<saedelaere> hm, ok. because the original branch on my computer shows
<saedelaere> "Standalone tree (format: pack-0.92)"
<fullermd> If you branch that standalone with a current bzr, you'll still have that repo format, and (I think) that branch format, but you'll have the new WT format.  Thus, unnamed.
<maxb> Use bzr info -v for individual format information on repo, branch and WT
<maxb> 'unnamed' is dramatically unhelpful, I wish it said something like 'pack-0.92+wt6'
<Noldorin> hrm, i still seem to be having the wrong URL format for bzr-git:
<Noldorin> git+ssh://git@github.com/Noldorin/IRC.NET.git
<saedelaere> ok, thank you very much.
<fullermd> maxb: Well, but it would actually be pack-0.92-wt4+wt6 or something.  Falls over soon's you wander off the beam.
<maxb> huh?
<maxb> It can't be wt4 and wt6 simultaneously
<fullermd> Thus my point   :p
<maxb> um?
<maxb> By pack-0.92+wt6 I mean pack-0.92 modified by the wt version being replaced by 6
<fullermd> Sure, but + doesn't mean modify, it means add.  So you have to subtract wt4 before you can add wt6.
<maxb> I am less strictly algebraic
<Peng> Bazaar doesn't track that it used to be WT4.
<Peng> Best you can do is a heuristic.
<lifeless> fullermd: that sounds confusing
<fullermd> That would be the meta-point...
<lifeless> fullermd: as each slot can only be filled once I don't see why you'd need a - operator
<fullermd> Whole point of a rollup name is to avoid combinatorics.  Adding combinatorics to the rollup kinda squirrels up the idea.
<lifeless> fullermd: that I don't agree with
<maxb> IMO, anything less vague than 'unnamed' is an improvement
<Peng> That reminds me, someone should file a bug about it saying "format: unnamed" for remote branches...
<lifeless> Peng: no, someone should fix it :P
<Peng> Yes, but if that someone is me, the former is much more likely than the latter. :P
<maxb> Didn't someone say it was fixed in bzr.dev?
<fullermd> Not exactly.
<fullermd> It reads the real format names over the smart protocol now.
<Peng> maxb: The detailed information is useful now (e.g. "branch: Remote: Branch format 7"), but the summary is not.
<fullermd> But since it never reads WT's remotely, it doesn't get that format, so there's never a matching rollup name.
<maxb> ah
<Peng> Oh.
<lifeless> fullermd: huh, its not about reading WT's remotely.
<lifeless> fullermd: its just info being borked.
<fullermd> Howzat?  There's no defined rollup format name without a WT format, is there?
<fullermd> So how would you expect to ever get anything but 'unnamed'?
<lifeless> fullermd: try it locally
<fullermd> Try it remotely locally?
<lifeless> try it locally locally
<lifeless> bzr init; bzr remove-tree; bzr info
<fullermd> Bah.
<lifeless> fullermd: do you see ?
<Peng> init --no-tree still isn't supported?
<Peng> Heh, thought that'd been changed.
<Noldorin> hi jelmer
<jelmer> Noldorin: hi
<Noldorin> jelmer: not sure if you got the messages, but i think aLmost evrything is sorted now...
<Noldorin> everything, except it's regusing my ssh key it seems.
<jelmer> Noldorin, cool
<Noldorin> what's the URL meant to be for github repos?
<Noldorin> i'm currently using git+ssh://Noldorin@github.com/IRC.NET.git
<Noldorin> erm
<Noldorin>  git+ssh://git@github.com/Noldorin/IRC.NET.git
<Noldorin> but if wonder if this is wrong
<jelmer> that seems right
<jelmer> I'm using something similar to push to github
<Noldorin> jelmer: i've set things up to use paramiko with pageant....
<Noldorin> perhap's it's not communicating right?
<Noldorin> hmm ok
<Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
<Noldorin> ssh://git@github.com/Noldorin/IRC.NET.git
<Noldorin> Permission denied (publickey).
<Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
<jelmer> Noldorin, did you manage to get pushing to launchpad working again?
<spiv> Good morning
* spiv changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.1.0b4 and 2.0.3 released
#bzr 2015-12-30
<makinen> I'm working on a feature which isn't ready yet but I have to stop for a while and make a more important change to the newest revision in the main repo. What is the best practice for this kind of situation?
<makinen> Should I make a new local branch, commit and switch to the trunk?
#bzr 2016-01-03
<joq> So I want to completely remove a commit that is not the last. I tried a simple google search but got nothing useful
<fullermd> Can't do it without remaking all the following commits.  Not sure if there's a good automation for that; something in the rewrite plugin maybe?
<joq> too bad, git is just one command...
<fullermd> Well, git's doing the same thing on the backend.
<fullermd> History models are largely the same, after all.
