#bzr 2008-03-31
<poolie> thumper: yes
<poolie> working on ppa now
<ubotu> New bug: #209450 in bzr "The error message for "can't find bzr on remote server" when using bzr+ssh is now scary." [Undecided,New] https://launchpad.net/bugs/209450
<spiv> bob2: thanks
<bob2> I was a bit suspicious of r3313, but reverting to 3312 didn't help
<spiv> bob2: I'd probably be suspicious of 3309
<ubotu> New bug: #209458 in bzr-loom "combine-thread doesn't result in correct tree parents" [Undecided,New] https://launchpad.net/bugs/209458
<poolie> vila, what is ~bzr-upload-devs?
<lifeless> There will be a short interruption to bazaar.launchpad.net and the ubuntu wiki to deploy a fix for the performance problems.
<uniscript> how do I push a branch into a new svn: repository branch?
<spiv> uniscript: I use "svn cp" to make the branch in the repo, then "bzr push" to that
<uniscript> but bzr push says I have to merge
<spiv> uniscript: there's a bzr-svn bug (https://bugs.launchpad.net/bzr-svn/+bug/203368) you can hit if you do it directly
<ubotu> Launchpad bug 203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Wishlist,Confirmed]
<spiv> Hmm, I'm not sure why that would be.  Perhaps you did "svn cp" from a different revision of the source branch?
<uniscript> I should explain I branched an svn: repo from repo1 but want to push up to an empty dir on repo2
<spiv> Oh.
<spiv> I don't know much about different SVN repositories.
<uniscript> any suggestions on how I can achieve this?
<spiv> Or rather, about using bzr-svn with them.
<spiv> It's not something that SVN is really designed to support, so I'd expect bzr-svn to struggle with it too.
<spiv> But if you mail the bazaar list, Jelmer might be able to help.
<uniscript> does that mean I have to join another list :(
<spiv> You could mail Jelmer directly, I guess (I think his address is in the bzr-svn README file), but I think the list is a better forum, so other people can help and/or learn from the post.
<spiv> uniscript: you could join the list, but then set your mailman settings to disable mail delivery.  That way you can post unmoderated, but you won't get a flood of messages to your inbox.
<uniscript> err where is the mailing list? Can't find it on launchpad :(
<ubotu> New bug: #209490 in bzr-loom "bzr-loom does not make it obvious when to use "bzr record"" [Undecided,New] https://launchpad.net/bugs/209490
<spiv> uniscript: https://lists.ubuntu.com/mailman/listinfo/bazaar
<spiv> uniscript: (it's linked from http://www.bazaar-vcs.org/)
<uniscript> sorry, just being frustrated with launchpad. Never seem to be able to find what I want there
<uniscript> the classic is: this package keeps it's bug tracking somewhere else, but doesn't say where that somewhere else is
<awmcclain> How would I ignore a file ".foo" in every directory of my branch?
<lifeless> bzr ignore **/.foo
<lifeless> probably quoted: bzr ignore '**/.foo'
<awmcclain> Thank you!
<Verterok> lifeless: hi
<awmcclain> If i merge a branch, does the .bzrignore file merge as well?
<lifeless> awmcclain: yes
<lifeless> Verterok: hi
<awmcclain> No reason it wouldn't.
<awmcclain> Great.
<Verterok> lifeless: do you have time for a quick question about my patch for custom properties in log?
<lifeless> sure
<Verterok> I not sure what I should fix in the docstrings of the show_properties method
<Verterok> the gmane thread is: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/38101
<Verterok> lifeless: I already added the tests for error case and added error handling code in the show_properties method
<awmcclain> Is "no handlers could be found for logger "bzr" a bzr message?
<lifeless> awmcclain: its coming from pythons logging framework
<lifeless> awmcclain: are you using the bzr frontend or some other script ?
<awmcclain> lifeless: I'm running bzr automatically from capistrano.
<awmcclain> Maybe I have an unmet dependency on the box?
<lifeless> awmcclain: no sure; whats capistrano ?
<awmcclain> lifeless: A nifty automated deployment framework. Basically I'm sshing into a minimally configured ubuntu box and running bzr up --lightweight, and I'm getting back that message (everything is working though)
<lifeless> hmm, could be a missing thing I guess
<lifeless> please file a bug, for extra credit with how-to-reproduce
<awmcclain> lifeless: Okee doke. I've read on launchpad that it may be related to a lock file? Could that be?
<lifeless> doubt it
<awmcclain> Yeah, me too.
<awmcclain> Sounds like a dependency thing.
<lifeless> I'd guess race condition with the logging infrastructure setup
<awmcclain> lemme try logging in directly
<awmcclain> and see
<awmcclain> lifeless: Ok, it's not a capistrano thing.
<jamesh> lifeless: I had a bit of a play with bzr-loom.  It is quite useful, although the UI doesn't quite feel right
<lifeless> jamesh: I saw your bug - thanks.
<jamesh> perhaps that's just because I'm not used to it yet
<jamesh> lifeless: is there any reason why the unrecorded loom state is in the branch rather than working tree?
<lifeless> jamesh: yes, its branch related not tree related
<jamesh> lifeless: I guess I'd see the last recorded loom state as being branch related, but the unrecorded state as working tree related.
<abentley> awmcclain: Not lock file, log file.
<abentley> You probably don't have permission to write ~/.bzr.log
<awmcclain> abentley: Actually, I was talking about lock, as described here: https://answers.launchpad.net/bzr/+question/19988
<awmcclain> abentley: That's exactly it. The .bzr.log file is owned by root!
<abentley> Happy to help.
<awmcclain> Must be because the first time I run bzr I sudo?
<awmcclain> hrmmm
<awmcclain> I suppose I could just touch .bzr.log before I start.
<awmcclain> Yay!
<Peng> jelmer: Should I back up .bazaar/subversion.conf? If it's lost, will I have to fix the branching scheme next time I pull or something? What if I keep subversion.conf but svn-cache gets deleted?
<mdke> anyone understand this? http://pastebin.ubuntu.com/6253/
<bob2> ubuntudoc was converted from svn
<bob2> so needs to be branched into a "rich-root"-supporting repository
<bob2> alas bzr co doesn't realise that
<mdke> you mean that the downloader has got a shared repository set up there with a different format?
<bob2> no, bzr co defaults to one that doesn't support rich-root
<mdke> hmm.
<mdke> is rich-root the same as "dirstate-with-subtree"?
<mdke> that's the one we have
<bob2> afaik the work around is "bzr init-repo --rich-root-pack ubuntu-doc ; bzr co http://launchpad-asdjfhsaldfhas/trunk ubuntu-doc/trunk" or similar
<spiv> rich-root is a feature some formats support.
<mdke> spiv: and dirstate-with-subtree supports it?
<spiv> dirstate-with-subtree is one format that supports that (and also some experimental feature); rich-root-pack is the newest and best format for rich-root support.
<mdke> is there a converting tool between the two?
<jamesh> "bzr upgrade"?
<bob2> bzr upgrade will convery branches
<bob2> but that doesn't help that person
<mdke> I tried that, it failed and trashed my branch
<spiv> And you can generally "bzr pull" etc revisions into a compatible repository.
<mdke> I couldn't even restore the backup
<mdke> I should have written down the error
<bob2> that's quite bad, since the backup is done by more or less "cp -r"
<bob2> or was it mv
<mdke> I wonder if I was trying to restore it to the wrong place, I had a shared repo at the time
<spiv> bob2: there's a bug in upgrade in some situations involving shared repos
<bob2> ah
<mdke> double ah
<spiv> bob2: that can leave things in a busted (but recoverable by hand) state
<mdke> anyway, I don't think the upgrade worked
<spiv> There's a bug report about that somewhere.  lifeless knows the full details.
<Peng> .bzr/repository is renamed to .bzr/repository.backup or something, and there is no new .bzr/repository. It's entirely safe to just rename it back in that case.
<mdke> I'm definitely interested in trying to convert these branches to the "official" bzr format though
<Peng> You could've experienced another problem, of course.
<mdke> if it's possible, i would like to do it
<Peng> mdke: Rich roots are The Future.
<jamesh> the problem is that they aren't The Present.
<Peng> mdke: And converting from rich roots to non-rich roots is not supported, because that would throw away certain meta data.
<Peng> jamesh: Heh.
<spiv> mdke: you can do the upgrade manually, by doing "bzr init-repo --rich-root-format new-repo", and then manually "bzr branch"ing each branch from the old to the new, then renaming the repos "mv repo old-repo; mv new-repo repo".
<mdke> what is The Present?
<Peng> spiv: "--rich-root-pack", not "--rich-root-format"
<Peng> mdke: Non-rich roots.
<spiv> Peng: right, thanks.  That's what I get for typing commands direct into IRC :)
<Peng> :)
<mdke> I understood that the format we have now is not the best format at the present
<Peng> Indeed.
<spiv> (and maybe you need to do "bzr init" + "bzr pull" instead of "bzr branch" for subtree -> rich-rich, I forget)
 * Peng shrugs.
<Peng> I don't know that.
<mdke> spiv: I will save those commands and give them a try later on
<Peng> Um.
<mdke> spiv: thanks
<Peng> I did something like that recently.
<mdke> I think we'd be content with trying to get up to The Present
<spiv> (https://bugs.launchpad.net/bzr/+bug/145812 appears to be the bug I mentioned earlier, btw)
<ubotu> Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged]
<Peng> Right.
<Peng> I bzr branched from dirstate-with-subtree to rich-root-pack, and it worked, but it was ridiculously slow.
<mdke> I'm patient :)
<Peng> Haha.
<Peng> It took 5.5 hours for a ~1300 revision, ~200 MB repo.
<mdke> ah, overnight then
<Peng> That was over bzr+ssh over the Internet..
<Peng> Doing it locally would be faster, of course.
<Peng> But there's no way it should take nearly that long.
<mdke> that's fine. If it's the right thing to do, I'm happy to wait :)
<mdke> bbias
<Peng> mdke: Going from subtrees to rich roots is safe in many situations (subtree support more features, but if they're not being used), but it's not possible to go from rich roots to non-rich roots without losing some meta data.
<mdke> Peng: does one want to go from rich roots to non-rich roots?
<mdke> I just want to go to the best current supported format
<Peng> mdke: There's not much need.
<Peng> mdke: The only problem is that the default format does not support rich roots, so users can get confusing errors when doing "bzr init-repo" and then trying to branch a rich root branch into it, and that "bzr checkout" problem.
<mdke> Peng: could I upgrade to the "default format" instead?
<mdke> that would still be faster than the current one, right?
<Peng> mdke: Current one?
<mdke> the dirstate-with-subtree format
<Peng> mdke: Oh.
<Peng> mdke: Like I said, you can probably go from dirstate-with-subtree to rich-root-pack, but not to a non-rich-root format.
<Peng> Mmm, netsplit.
<mdke> lagged out, sorry
<mdke> last thing I have was the "isn't it a bit odd" question
<mdke> anyway, got to go to work now. thanks all for the info
<Peng> "isn't it a bit odd"?
<Peng> I didn't get that.
<ubotu> New bug: #209570 in bzr "http cannot tunnel smart protocol" [Critical,New] https://launchpad.net/bugs/209570
<thekorn> hi, does the bzr extension for nautilus from bzr-gtk work for anyone?
<james_w> hi thekorn
<thekorn> hi james_w
<james_w> I heard someone saying the other day that it didn't work for them
<james_w> so it sounds like their may well be a regression there.
<thekorn> hmm, the python bindings for nautilus does not seem to work at all, so there might be the problem
<james_w> ah, you're just trying from a python console?
<thekorn> no, within nautilus, no clue howto test it in a console-session
<thekorn> it's bug http://bugzilla.gnome.org/show_bug.cgi?id=518824
<james_w> thekorn: thanks, I'll open a bug in Ubuntu
<thekorn> james_w, okay, thanks, can you please subscribe me? :)
<james_w> done
<james_w> do you want to use your bugcontrol powers on it?
<james_w> https://bugs.launchpad.net/nautilus-python/+bug/209580
<ubotu> Launchpad bug 209580 in nautilus-python "python-nautilus doesn't work with latest nautilus" [Undecided,New]
<thekorn> james_w, yes, will set the importance to medium
<james_w> isn't it critical for that package if it doesn't work at all, or do I misunderstand?
<thekorn> james_w, critical for this package, but not for ubuntu, as the number of users affected by this is not that big, I think
<james_w> ah, ok. I thought the severity was per package
<james_w> should there be a split for the severity against the package and severity for the release?
<thekorn> I'm not sure, maybe the gnome bug needs a higher severity,
<james_w> it's critical I think
<james_w> I looked again and found an existing bug for this, so I've duped it
<thekorn> james_w, I've no clue about FFe and the related process, I will discuss this bugreport with people in #ubuntu-bugs later today
<james_w> I don't think we need an FFe to fix this, I'm not sure though.
<james_w> there's a workaround patch described in the bug report, we can add that to the package for the release I think
<ubotu> New bug: #209580 in nautilus-python "python-nautilus doesn't work with latest nautilus (dup-of: 44704)" [Medium,Confirmed] https://launchpad.net/bugs/209580
<pbor> I know I asked this before, but I can't remember how to do it... can I make  bzr diff --diff-options=-p the default for bzr diff?
<dato> pbor: yes, with an alias
<pbor> ah, ok
<pbor> I thought there was some way inside bzr
<dato> a bzr alias, not a shell alias, I mean
<pbor> ah
 * pbor looks that up
<pbor> thanks dato
<pbor> is bzr alias a plugin?
<pbor> bzr help alias gives me an error
<dato> nope, it's core
<dato> but
<dato> I don't know if you can add an alias from the command line, with a command
<dato> I *think* you have to edit the configuration file
<james_w> no, you can't
<james_w> thumper proposed a patch to do that, but I don't know what happened to it
<dato> pbor: so, like this:
<dato> % head -n 2 ~/.bazaar/bazaar.conf
<dato> [ALIASES]
<dato> up = update
<pbor> ah, ok, I can live with that :)
<pbor> thanks
<james_w> I think there was discussion about whether it should work like the shell builtin alias, or more like bzr in terms of command line parsing
<frsk> Why have you aliased update? =)
<frsk> bzr up = bzr update with aliasing it :)
<frsk> without*
<dato> frsk: I probably added it when the "up" alias didn't exist in core
<dato> and didn't clean up afterwards
<frsk> dato: Aha
<Stavros> hello
<Stavros> i need to pull the changes from a remote repository up to and including a tagged release, and substitute all my local working copy with that release. what is the correct command line?
<dato> Stavros: do you have local commits_
<dato> ?
<Stavros> dato: no, it's a production server
<Stavros> i may have some local edits which i want overwritten
<dato> aha. so, `bzr revert && bzr pull -r tag:TAGNAME http://...` ?
<Stavros> aha, that should work, let me try it
<Stavros> do i need to do something like "revert -r"?
<Stavros> oh wait, nm :/
<dato> no, you don't
<Stavros> how about pull --overwrite?
<dato> that's for when you have local commits
<Stavros> ah
<Stavros> but not local working copy changes?
<dato> nope
<dato> those are reverted with revert
<Stavros> hmm, it said something about conflicting tags...
<Stavros> aw man, i'm in the front page of reddit
<Stavros> no wonder the server is hammered
<TFKyle> Stavros: which, learn python in 10 minutes?
<Stavros> yeah :/
<Stavros> so, any idea what this talk about "conflicting tags" is?
<james_w> Stavros: there is a tag that is set to one revision in your branch and another revision in the other branch
<james_w> or two tags with the same name on two different revisions if you like
<Stavros> james_w: that's odd, don't tags get moved if they already exist?
<james_w> Stavros: I think so, what does the rest of the message say?
<Stavros> it just shows me the tag I just set
<james_w> does it stop the pull, or just warn you?
<Stavros> it just warns me, from what i can see
<james_w> does it say which one was kept?
<james_w> i.e. did it keep your tag, or use the other one?
<Stavros> no, but apparently the server has it on a different release than on my machine
<Stavros> that's odd
<Stavros> i have it on 247 and the server on 246
<Stavros> shouldn't it update the tag on pull, even though it already is on a revision on the server?
<Stavros> hmm, --overwrite works
<james_w> yep, it's a conflict, so you need to specify what you want to happen
<Stavros> ah
<Stavros> hmm, why does it not update? because i set it on the server?
<james_w> yes, the tag points to two different places, and so bzr doesn't know which one you want.
<Stavros> ah, so --overwrite should fix any future conflicts, yes?
<james_w> yes, I think so, though it's not necessarily a good idea to always use --overwrite
<james_w> why do you think you will have more conflicts?
<Stavros> i don't really think i will, but i'm pretty sure i won't have any changes there i want to keep, so it's the safe bet
<luks> that reminds me I should file a bug report about adding --overwrite-tags
<Stavros> oh, that would be quite useful
<Stavros> well, thank you all very much for your help, it works quite well now
<uniscript> I'm wanting to copy an svn branch/tree from one repo to another where I don't have server access to the repos. I wonder if bzr-svn can help with this?
<uniscript> I've branched the source using bzr-svn now how do I push it up to the target?
<james_w> uniscript: bzr svn-push is probably what you want
<james_w> uniscript: the branch doesn't exist in the second repo, correct?
<uniscript> correct
<uniscript> if I try svn-push it wants to merge
<james_w> yeah, svn-push is the answer I think.
<uniscript> I tried push --overwrite but that's not implemented yet :(
<uniscript> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<uniscript> the target directory exists in the repo and is empty
<uniscript> is that a problem?
<uniscript> testing...
<uniscript> seems happy. So that was the problem, can't branch into an empty directory, svn-push has to create the branch dir. OK. Thanks
<LeoNerd> Is there a way to do a push-or-pull operation..? Given two bzr branches, push updates from whichever is newer, to whichever is older? (obviously it'd break for diverged history)...
<hmeland_> LeoNerd: No, I don't think there is such a thing.  A branch and a checkout of that branch comes close, though.
<LeoNerd> I just wanted to put it in cron.hourly in a "foreach BRANCH in `bzr branches`; ..."   command
<ubotu> New bug: #209688 in bzr-gtk "The branch history window should use a status bar" [Undecided,New] https://launchpad.net/bugs/209688
<ubotu> New bug: #209689 in bzr "KeyError in transport close _file_streams while pulling into a bound branch" [Undecided,New] https://launchpad.net/bugs/209689
<vila> bzrlib.tests.test_revisionnamespaces.TestRevisionSpec_date.test_yesterday failed
<vila> yesterday
<vila> err, no sometimes around 0.01 this morning
<vila> ha ha, so funny
<vila> Anyway, I just demonstrated that this test *is* fragile :)
<jelmer> (-:
<mw-home> can bzr export make python eggs from my project?
<bob2> like bdist_egg? no.
<bob2> there's a setuptoolsbzr thing, tho
<mw-home> bob2: is that a bzr plugin?
<bob2> no, a setuptools one
<piedoggie> are there any guides on how to use bzr  to automatically increment the version number in a setup.py file
<james_w> piedoggie: there's the version-info command that might help you
<james_w> I think it's something like bzr version-info > _version.py and then import that in setup.py and grab the revno
<james_w> version-info --python or something actually
<james_w> is that what you meant?
<piedoggie> something like that
<piedoggie> I still need a figure out how this would affect the version number seen when you run setup
<piedoggie> also need to figure out how to include it, generate a new one on every commit etc.
<james_w> well setup.py is python, so you can do all this, and then pass it to the function that you call in there.
<james_w> ah, on commit, that's different
<james_w> you could use some sort of hook I think
<piedoggie> my nickname is Mr. forgetful.  I can't tell you the number of times I've created new packages and then fold them up with a single commit for just the version number change
<james_w> oh yeah, I do that all the time as well
<LarstiQ> version-info --template might be of help
<james_w> hi LarstiQ
<LarstiQ> hey james_w, piedoggie
<piedoggie> afternoon
<piedoggie> well, I can see the auto version number update will take a bit more thing time to make it right (or least documented)
<piedoggie> ... a bit more think time...
<hmeland_> LeoNerd: Maybe you could do "bzr pull && bzr push;"?  I.e. try to pull from "other", and unless that fails, try to push revisions from "this" to "other".
<LeoNerd> hmeland_: Hmmm... That might work... Though if both fail, how to tell between "sides are identical" from "sides have diverged" ?
<hmeland_> Quick test shows that "Nothing to do" will succeed for "bzr pull", at least.
<LeoNerd> Ah OK. :)
<hmeland_> You can apparently also use "bzr pull -q", which will give an ERROR if the branches have diverged.
<LeoNerd> OK. That's probably good enough then
<abentley> jelmer: around?
<jelmer> abentley: hi
<abentley> jelmer: We're trying to track down what happened when you got an OOPS error yesterday
<abentley> It looks as though you tried to register a branch with the name .bzr, but of course that doesn't make much sense.
<jelmer> ah
<jelmer> abentley: please ignore those
<abentley> Well, this is an internal error.  Users really shouldn't ever get those.
<jelmer> abentley: I mass-registered a bunch of branches
<abentley> Oh, shell-scripting glitch?
<jelmer> I've got a particular directory structure on my server that I relied on
<jelmer> I've got a plugin that allows short URL access to those branches and can auto-register them
<jelmer> It looks like it tried to register all the files in a working tree somewhere
<abentley> Ah, okay.
<jelmer> abentley: It would be nice to get a clearer error, but I doubt it would ever happen to a normal user.
<abentley> Cool.
<jelmer> It would of course also be nice if launchpad could do recursive finding of branches under a particular URL...
<xma> 'lo
<thumper> james_w: the alias patch has been sitting idle as I haven't written appropriate tests yet
<xma> what should I do when I merge and something is going bad ?
<james_w> thumper: ah, ok, thanks
<xma> I resolved the conflict and cleared it
<xma> but now I am stuck with "pending merges"
<thumper> james_w: I really should get around to finishing it
<james_w> it would be nice to have
<xma> nobody ? :(
<mwhudson__> xma: commit?
<xma> hum
<xma> what is the merge command purpose then ?
<thumper> xma: to merge in changes
<thumper> xma: it doesn't commit them
<xma> really ?
<james_w> to bring the other branch commits in, you still have to check they are merged well and then commit
<thumper> yes, it is a feature
<xma> oh I see :)
<xma> will it take the commit message from the merge patch ?
<dato> no
<xma> ok
<xma> I will have to generate it from my branch then
<mdke> lifeless: around?
<xma> are there any python-mode users around ?
<xma> james_w: is it normal that my merge+commit added stuff not by me ?
<xma> james_w: there were many lines touched outside of my scope
<xma> james_w: I only modified 4 files and it seems latest commit did more than that
<james_w> xma: they were changed in the branch you merged?
<xma> james_w: dunno
<xma> james_w: when I bzr status, only my files were marked as "modified"
<xma> and now I see many lines touched in many other files in the commit
<james_w> and then where do you see the other lines changed?
<james_w> no files were marked as added?
<xma> james_w: ok I think I know why :) bzr send -o mypatch was not enough
<xma> james_w: I have to add the revision number to
<xma> o
<mdke> I'm interested in getting some information about the rich-root-pack format. Is it documented anywhere? Are there any obvious disadvantages to using it? Is it expected to be the default bzr format, and if so, how far away is that?
<xma> hum no, it is not
<james_w> mdke: non-rich root repositories don't allow you store a normal file-id for the root of a repo.
<james_w> This means that they all have the same root id
<james_w> this, for instance, isn't satisfactory for bzr-svn
<mdke> I don't think that is a feature we currently use, although I suppose we might like to
<xma> james_w: how do I know what a particular rev contains ?
<xma> james_w: I want to see what is in the rev 3318 for instance
<james_w> mdke: it will not be the default format, though the default format will have rich roots
<james_w> mdke: perhaps bzr-1.4 will have a new default format with rich-roots
<mdke> james_w: rich-root-pack will never be the default format?
<james_w> mdke: no, but an evolution of it will
<mdke> james_w: will an upgrade from it be supported?
<james_w> xma: bzr log -v -r 3318
<james_w> xma: bzr diff -c 3318
<james_w> mdke: yes
<xma> james_w: thank you
<james_w> mdke: however I don't think downgrade from rich-root to non-rich-root is supported, as that would throw information away
<mdke> sure
<james_w> mdke: I don't think that would be part of your considerations though
<james_w> is this for the docs?
<mdke> ubuntu-docs
<james_w> yeah, we've heard you're not happy with the current state of things
<mdke> they currently use dirstate-with-subtree
<mdke> james_w: that's not true, I'm very happy; I'm just trying to figure out what to upgrade to...
<jelmer> mdke: they should be able to use --pack-0.92-subtree
<jelmer> that'll at least give them packs
<dato> and I thought it could work to -subtree too, albeit very slowly?
<mdke> jelmer: is that better than rich-root-pack?
<mdke> james_w: and which format to use for a potential new branch
<james_w> mdke: ah, we have heard some complaints, but if you're happy that's great
<xma> james_w: sorry to bother but how do I safely and cleanly get rid of a branch ?
<jelmer> mdke: better in what sense?
<mdke> james_w: well, not from me
<james_w> mdke: the default will be fine.
<mdke> james_w: hmm?
<james_w> mdke: probably 1.4 will upgrade that to rich roots, but if you're not going to use rich-root features then there's not much point of using the format
<james_w> mdke: you asked what to use for a new branch, I was saying the default will be fine..
<james_w> xma: is this branch using a shared repository?
<mdke> james_w: well, wouldn't a major reason to do so be to enable the branch to be used in a shared repository with the other branches
<xma> james_w: yes it does
<james_w> mdke: that's very true
<mdke> jelmer: in any sense :) I was using the word "better" in the way that someone who doesn't know much about the subject would
<james_w> xma: well rm -rf the branch (after making sure it is the right one, and there are no uncommitted changes, etc.)
<james_w> however this leaves the revisions in the shared repository
<james_w> there is currently no way to garbage collect those with a command
<james_w> if you really want to do it the best way is to create a new repository and then branch all of the branches that you want to keep in to it.
<xma> james_w: I want, in fact, to get rid of changes I have made onto a branch and put the branch "clean" with no modficiations pending etc.
<xma> in short, I want to be sure all my files are at revision #
<james_w> xma: bzr revert -r revno
<xma> james_w: ok thank you
<james_w> if that is not the current tip of the branch then that will still leave you with changes
<james_w> bzr pull -r revno --overwrite .
<james_w> will put you on a revision with no changes
<mw-home> I want to use bzr to branch an svn repository.  I tried bzr branch svn+http://asfasd and I got an error: bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/
<mw-home> Any ideas?
<james_w> mw-home: I assume you can "info" it with svn
<mdke> sorry, hit the wrong button
<mdke> james_w, jelmer - so I'm interested in upgrading to packs because I've heard it will cause good things, but I want all the branches to be the same format so they can go in a shared repository. So I'd need to upgrade the old branches as well as init the new branch with that format
<mw-home> james_w: yeah, I can run svn info on the repo, and I don't prompted for a userID and password.
<mdke> I haven't heard any disadvantages so far!
<mdke> :)
<jelmer> mdke: in that case, go for --pack-0.92-subtree if you have old branches that use --dirstate-subtree
<mw> damn nick highliting :)
<jelmer> mw: what os are you on?
<mdke> jelmer: what are the reasons that --pack-0.92-subtree is better (in the general sense) than rich-root-pack? It's harder to spell
<mw> jelmer: opensuse, why?
<jelmer> mdke: It's impossible to upgrade from --dirstate-subtree to --rich-root-pack afaik
<mdke> jelmer: I'm trying it by branching into a rich-root-pack shared repo, I was told that should work. it's going ok - about half way
<jelmer> mdke: In that case, --rich-root-pack would be a better choice, indeed
<mdke> jelmer: ok, we'll see if it works!
<mw-home> james_w: any other ideas why bzr branch svn+http would fail on an svn repo that allows the world to read it?
<mdke> james_w: is there somewhere I can read about the "not happy" thing - I'd like to correct it if it's on a public list
<jelmer> mw: what version of bzr-svn?
<james_w> mdke: no, it was just on IRC, here and Ubuntu channels. The complaint was that checkout was slow, and that the branch may not have been optimal from some things that may have happened in the past
<james_w> but there was nothing concrete in the last part
<mw> jelmer: sorry, i think you mean to be asking mw-home
<mw-home> jelmer: 1.0
<jelmer> mw: Whoops, sorry
<jelmer> mw-home: Uhm, there is no bzr-svn 1.0 :-)
<mw-home> jelmer: sorry.  0.47
<mdke> james_w: ok fine - I think it's more a question of just trying to optimise things, the checkout was always going to be slow because of the size of the working tree and the downloading of the revision history
<mw-home> 0.4.7
<james_w> mdke: yeah, it's not optimal, I'm sure. And I'm sure people get annoyed by the delays as well.
<mw-home> I installed bzr-svn as an ubuntu package.  Maybe I should remove that package and grab the bzr branch of the package instead?
<jelmer> mw-home: is this a public repository>
<jelmer> ?
<mw-home> jelmer: yeah it is a public read-only repository.  here it is: http://svn.traceback.org/python
<jelmer> mw-home: The repository requires authentication, e.g. "svn ls http://svn.traceback.org/python"
<mw-home> jelmer: I don't get prompted for authentication on the /python subdir.
<mw-home> unrelated question.  is bzr-svn/stable a tagged release of bzr?
<mw-home> bzr-svn?
<jelmer> mw-home: bzr-svn requires access to the root of the repository
<mw-home> jelmer: got it.  thanks.
<jelmer> mw-home: not sure I understand your other question
<mw-home> my other question is, i just did a bzr branch on bzr-svn/stable.  Now I have a $HOME/.bazaar/plugins/stable directory. Do I need to rename stable to bzr_svn?
<jelmer> you have to rename it to svn
<mw-home> gotcha.
<mw-home> Should that be in the README file?  I can send in a patch with that text edit if you want.
<jelmer> I think it will tell you if you give it another name
<jelmer> although patches (or bundles, rather) that improve the documentation are very welcome
<lifeless> mdke: hi, will be around in one hour
<mdke> lifeless: morning :) will try and hang around
<mdke> jelmer: looks like it is working ok! the shared repo is 1.3GB on the new format as opposed to 1.6GB with the old one, a tidy saving
<lifeless> mdke: hi
<mdke> lifeless: hiya. I've been playing with converting the branches to rich-root-pack format, with the space saving as above
<mdke> I'm still thinking of starting our intrepid branch from scratch though, just to wipe the slate clean
<mdke> I think we have a lot of heavy stuff hanging around in the history that we don't use
<mdke> and of course for historic record, we have it in the old branches
<james_w> mdke: just as a heads up, if you do decide to do this then --file-ids-from will probably be what you want to do for the first add in your new branch
<lifeless> I'm just looking at your branch now
<james_w> hi lifeless
<lifeless> hi james_w
<lifeless> mdke: so I'm doing some analysis to figure out how big your branches various data items are
<mdke> lifeless: sounds good
<abentley> james_w: Your changes to the Revision documentation make it a lot longer and intimidating.
<abentley> If you're going to go into that kind of detail, could you try writing it in newspaper style, putting the most important things first?
<james_w> abentley: sure, I'll do that tomorrow
<abentley> Thanks.
<lifeless> abentley: IIRC someone wrote a branch stats generator
<lifeless> abentley: do you remember it ?
<fullermd> I vaguely remember some stats thing that listed number of commits by commiter or something like that...
<mdke> lifeless: what's the diagnosis?
<lifeless> mdke: still getting a clone
<lifeless> mdke: you really should upgrade to rich-root-pack :P
<bob2> "bad", then ;)
<lifeless> whether or not you start over
<mdke> lifeless: ok. Would it help for you to have access to my pc?
<mdke> I have the branches converted to rich-root-pack there
<lifeless> not really
<lifeless>  its cloning inside the dc
<mdke> ok
<mdke> lifeless: out of interest, is it possible for me to overwrite the launchpad branches now I've got converted local branches with rich-root-pack?
<mdke> or do I need to delete the existing ones and recreate them
<lifeless> mdke: bzr upgrade sftp://bazaar.launchpad.net/....
<lifeless> that will download/upload it all tho, so doing it from a dc machine is preferrable
<lifeless> we will do a push-button upgrade for lp at some point
<mdke> lifeless: is bzr upgrade safe to do on that? I tried it on my local branch and it broke. for the conversion I used "bzr init-repo --rich-root-pack ; bzr branch ../old-repo/branch branch"
<mdke> I dunno if it broke because I have a shared repo or for another reason
<james_w> mdke: what was the error?
<mdke> james_w: I didn't make a note of it I'm afraid
<lifeless> mdke: 'bzr reconcile sftp://....' first then
<mdke> Ok. I'll try it after hardy is released :)
<mdke> lifeless: I have to go to bed now. If you could leave a msg here (or more reliably, pop me an email), I'd be very grateful. Thanks for all your help
<mdke> thanks james_w too
<igc> morning
#bzr 2008-04-01
<poolie> dhi
<schierbeck> jelmer: still awake?
<schierbeck> hey guys, is anybody besides me having trouble opening the bzr mainline with the viz in bzr-gtk trunk?
<fullermd> It does seem to be working very hard at doing nothing...
<fullermd> No CPU, no IO...
<fullermd> Oh, wait.
<fullermd> That may be that error in bzr with ghosts; not bzr-gtk.
<schierbeck> okay
 * fullermd doesn't really know; just guessing.
<schierbeck> well, i'm hoping :)
<schierbeck> i've got enough work already!
<fullermd> It works on other trees, and the backtrace looks like a place a ghost could cause cliff-off-falling.
<schierbeck> in Repository.sign_revision(), what the heck does gpg_strategy mean?
<schierbeck> can i just leave it as None? it's not documented at all...
<mw-home> I just install bzr-svn by running bzr branch in my home plugins dir.  Now bzr won't do anything.  Keeps complaining about cannot import CachingParentsProvider.
<mw-home> Do I need to run sudo python setup.py install first?
<mw-home> cd -
<lifeless> mw-home: I think you have a version mismatch
<mw-home> lifeless: between the plugin and my base bzr?
<lifeless> yes
<mw-home> I'm running bzr 1.0 and bzr-svn 0.4.10dev0.
<lifeless> mw-home: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show#releases
<mw-home> so i clearly need something different than bzr 1.0.  lifeless, thanks for straightening me out.
<fullermd> Trunk bzr-svn generally goes with trunk bzr.dev.  It may still work with 1.3 currently, but 1.0 is back far enough now that it's not too surprising.
<lifeless> igc: ping
<lifeless> mw-home: or an older bzr-svn :)
<igc> hi lifeless
<lifeless> igc: I really want to nuke that cache
<lifeless> igc: our discussion seems to have petered out
<igc> the one in fastimport for the inv_vf?
<lifeless> yes
<igc> no problem
<justdave> so maybe I'm just completely blind, but I'm not finding what I'm looking for in the docs...  if I want to update a working directory to a revision that's older than the head of the branch, what do I do? (equiv of cvs/svn up -rREVSPEC)
<justdave> bzr up doesn't seem to take a revision as an argument
<lifeless> justdave: revert
<igc> lifeless: as long as you're aware that it was helping, I'm ok with it going ...
<justdave> that works going forward I assume, too?
<mw-home> do most people in here use a distribution pkg for bzr, or download some other way?
<lifeless> igc: it doesn't seem to help enough to justify its existence to me.
<justdave> like if my working directory is on r5179 and I want to update it to r5185, while the repository I'm pulling from is actually on r5190...
<fullermd> justdave: bug 45719
<fullermd> https://bugs.launchpad.net/bzr/+bug/45719
<justdave> yeah, looks like that does work. :)
<justdave> the name of the command just makes it confusing :)
<igc> lifeless: understood. I think the stuff you're doing is more important than the short term gain I'm getting
<fullermd> Name of the command?
<fullermd> Oh, you mean using revert?
<justdave> so if I'm updating a website based on a tag that gets moved periodically to the revision that we want to be live on the site, my cron job needs to do "bzr revert -rtag:production"
<fullermd> Well, not really.  It needs to update -r.  The option just doesn't exist.
<fullermd> Of course, if it's a branch by itself, you can use pull -r; that may be the best solution in that case.
<justdave> using pull just tells me "No revisions to pull."
<justdave> no matter what revision I specify
<mw-home> thanks for all the help.
<fullermd> Well, if that rev is already the head, that's what you expect.
<igc> lifeless: removed and pushed to lp
<justdave> doesn't seem to matter.
<justdave> I can bzr revert -r(older rev), and then bzr pull -r(current) and it still says that
<fullermd> Don't do the revert beforehand.
 * fullermd sighs.
<fullermd> Pulling 1 rev of bzr.dev:
<fullermd> Now on revision 3320.
<fullermd> 5.352u 0.434s 1:29.75 6.4%      114+147k 274+19io 7pf+0w
<fullermd> Pulling 4 months of mutt changes (hg):
<fullermd> added 199 changesets with 417 changes to 121 files
<fullermd> 119 files updated, 0 files merged, 10 files removed, 0 files unresolved
<fullermd> 5.813u 0.396s 0:12.90 48.0%     124+161k 459+32io 0pf+0w
<justdave> # bzr up
<justdave> Tree is up to date at revision 5181.
<justdave> # bzr pull -r5179
<justdave> No revisions to pull.
<fullermd> You need --overwrite to step backward.
<fullermd> (or sideways)
<justdave> bingo
<justdave> All changes applied successfully.
<justdave> Now on revision 5179.
<fullermd> (of course, that pull if you had the files reverted might do some wacky things...)
<justdave> ok, so "bzr pull --overwrite -rtag:production" is what I want on my cron job then
<sssslang> hi there, could some one give me an advise about which gui to use under windows. i'm a newbee, thanks.
<fullermd> Noop pull on bzr.dev takes as long as that whole hg pull.  Sigh.
 * fullermd wants smarts.
<fullermd> sssslang: I think the main choices are bzr-gtk and qbzr.  bzr-gtk is more complete and seems to be a bit more work to get installed.  qbzr looks more native.
<fullermd> (all that AIUI; I don't really use either one)
<sssslang> fullermd: thanks. what about TortoiseBzr? i heard of it before when using cvs.
<fullermd> I think it's still more "proof of concept" than "use this to get work done".
<sssslang> i don't use gui, but i just want to select one for my partner.
<sssslang> i see. thank you.
<fullermd> (though again, I don't use either the GUI's or Windows, so I may be wrong.  That's just what I've picked up watching IRC/mail)
<mwhudson> is there bzrlib for 'delete the branch at this url' ?
<mwhudson> i guess i want transport.rmtree, which doesn't seem to exist
 * igc lunch
<lifeless> mwhudson: there is
<lifeless> mwhudson: delete_tree
<mwhudson> oh yay
<mwhudson> (i was looking in the wrong place)
<lifeless> pydoc bzrlib.transport.Transport :>
<AfC> lifeless: is that exposed on the command line somehow? ie, is there a way to delete a remote branch which I'm accessing via bzr+ssh://?
<AfC> (right now, of course, I'm ssh'ing to the server, cd'ing, and doing rm -r. Hm)
<lifeless> AfC: well, 'python -c "import bzrlib.transport; bzrlib.transport.get_transport('url').delete_tree()"' ?
<AfC> Let me get right on that
<lifeless> AfC: ssh is simpler :)
<AfC> The case I am interested in is where you have ssh access to run bzr commands but not an  remote shell.
<AfC> (which is what we offer our users)
<AfC> (I gather Launchpad is the same? Anyway)
<AfC> I have to delete their obsolete branches for them. Kinda ugly. You're saying I should ask them to run that snippet? Very well.
<mwhudson> launchpad allows sftp, which somewhat allows the same
<spiv> Launchpad offers no shell, although it does offer a web UI that can delete branches.
<Peng> There's no need to delete obsolete branches..
<spiv> Peng: it is useful if you like to browse branches to get a sense of what's being worked on.
<Peng> Yeah.
<spiv> (presupposing a mechanism to browse collections of branches, of course)
<Peng> I leave my branches around forever, using Launchpad to mark them as merged or abandoned or whatever.
<lifeless> AfC: no really saying that that snippet is a good answer; just thats the only answer in bzrlib today
<lifeless> I hate test_35_wait_lock_changing
<Peng> Yay, I had a weird problem with bzr-svn (traceback trying to branch something, then "not a branch"), but I upgraded, and now it's ok. :)
<Peng> So what's the status of bzr.dev and http://bazaar.launchpad.net/, what with bug 207558?
<lifeless> bug 207558?
<jdong> lol
<jdong> seveas upgraded to hardy.
<jdong> hilarity ensues.
<spiv> Peng: I'm working on it atm
<fullermd> spiv: Hey, I had a Q about that root_client_path thing you merged in today...
<fullermd> spiv: I'm not sure I understand its implications.  Could that be useful in the case where the request paths aren't directly under a common root?
<Peng> spiv: Ok.
<Peng> Oh, ubotu isn't here?
<spiv> fullermd: hmm, I'm not sure.  It's just designed so that you can publish e.g. /home/code/project-x at bzr+http://host/bzr/repos/x-project
<fullermd> spiv: I have the [recreational] desire to get the smart server in bed with UserDir's...
<spiv> So you can effectively designate some path in your public URL space as the root of the bzr-served area, and then have that consistently translated to an underlying transport.
<fullermd> Hm.  So that wouldn't really apply...
<lifeless> fullermd: ~ translation just needs a transport adapter I think
<spiv> fullermd: what lifeless said :)
 * fullermd gets his Greek-to-English dictionary out...
<spiv> fullermd: e.g. write a plugin that registers a transport for the "userdir:" URL scheme, and use that as the backing transport for your bzr+http server
<spiv> So instead of having a SmartWSGIApp that publishes '/home/code/project-x', it could publish "userdir:///".
<lifeless> spiv: well, I was thinking something that looks for ~ and does userdir expansion
<lifeless> spiv: but yeah
<fullermd> Either way, it sounds like it classifies solidly as "bzr hackers might be able to get this working".  So, I guess I'll leave that laying for a while yet.
<lifeless> always need more help fullermd
<fullermd> Well, my port of bzrlib to perl is a little stalled...
<lifeless> I said help :)
<fullermd> I am helping; it's stalled   ;)
<mdke> lifeless: thanks very much for your email
<fullermd> It's kinda odd that 'missing' doesn't have --remember, and doesn't remember by default either.  And doesn't use the submit branch...
<james_w> sounds like the start of a soppy song... "oh, if only I could remember all those missing revisions..."
<fullermd> Hm.  Yeah.  Simon and Garfunkel.
<igc> night all
<james_w> night igc
<james_w> igc: thanks for the proposed new hook, it could well make bzr great for use with ikiwiki
<james_w> does anyone understand this?
<james_w> http://release.debian.org/migration/testing.pl?package=bzr-builddeb
<james_w> it seems to be a bit of a circular argument.
<james_w> it might be http://release.debian.org/migration/testing.pl?package=bzr-svn that is the root of it then
<siretart> james_w: we need to ask the release team to add a hint that the bzr related package need to go in together
<siretart> james_w: or we could just prod dato, since he is a member of the debian release team ;)
<james_w> ah, I see, thanks siretart
<dato> siretart, james_w: I added a hint, should be done in a couple days, when bzr-svn is ready to migrate
<james_w> dato: thanks
<schierbeck> jelmer: hi
<jelmer> schierbeck: hey
<schierbeck> have a look at lp:~bzr-gtk/bzr-gtk/seahorse-integration
<schierbeck> it's rocking.
<schierbeck> i've got key fingerprints and trust down nown
<schierbeck> *now
<schierbeck> though i still need to fix some bugs
<jelmer> cool
<jelmer> schierbeck: any chance you can review my other two patches I sent to the list?
<jelmer> ([MERGE] Signatures tab and [MERGE] Split identity settings out of main preferences window.)
<jamesh> jelmer: thanks for looking at my commit-notify patch
<schierbeck> jelmer: sure
<jamesh> now I just need to get lifeless to review the bzr-dbus bits
<jamesh> :)
<jelmer> schierbeck: thanks
<schierbeck> okay
<schierbeck> looked over the settings branch, looks good!
<schierbeck> jelmer: btw, do you think we should rename the "signature" tab label to "trust"?
<schierbeck> i think it makes more sense
<schierbeck> since a signature doesn't really mean anything if you don't trust it.
<jelmer> schierbeck: I'd rather call it signature for now
<jelmer> Since trust can mean different things here
<jelmer> Does it mean you trust the person who made the signature to have made the commit, or does it mean you trust them to write good code without security bugs?
<schierbeck> that could be differentiated in the tab ui
<schierbeck> i.e. [x] Trust that this revision was committed by 'John Doe'
<schierbeck> and [x] Trust the validness of this revision
<schierbeck> where validness would be replaced with a proper word...
<jamesh> jelmer/schierbeck: if you want to do signature verification, maybe try pygpgme
<jamesh> I haven't done much work on it recently, but it works pretty well
<schierbeck> jamesh: we're looking at using the seahorse dbus service right now, but i'll take a look
<james_w> I don't know if you guys know, but we had a discussion on signatures at the sprint
<jelmer> schierbeck: The problem is that bzr can only store signatures at the moment and afaik it's not really clear what they mean
<schierbeck> jup, that's been an issue for a while
<james_w> it's not clear that what we have now is the best approach, so it may be re-evaluated.
<schierbeck> remember discussing it a few months ago
<jamesh> schierbeck: okay.  From memory, seahorse is built on top of gpgme, so they should be mostly equivalent
<jamesh> it just changes who forks and exec's gpg
<schierbeck> jamesh: i think a review system integrated into bzr would be nice
<james_w> I've been tasked with writing a spec about it
<jelmer> schierbeck: that's why I'd rather stay away from assigning trust, etc for now
<schierbeck> jelmer: i see your point
<jamesh> bzr has enough hooks now that the jam's old signing plugin could be extended to do useful things now
<james_w> or at least a document about the issues, and the fact that the point of a signature is not currently clear is the biggest problem with the current state for me
<jamesh> like refuse merges that aren't signed by a trusted key
<schierbeck> what about having review keywords, like "approve", and then just sign the keyword and sha1-sum?
<schierbeck> bzr review <approve|reject|...> -r <revision>
<schierbeck> the idea would be that all history up to that revision would then be "approved"
<schierbeck> just an idea, though
<schierbeck> jelmer: okay, i've pushed some further changes to lp
<schierbeck> the new implementation now exceeds the old in functionality
<schierbeck> jamesh: does pugpgme have any documentation?
<schierbeck> *py*
<jamesh> schierbeck: not really.  The API is mostly the same as the C one though.
<jamesh> and the tests cover pretty much all the entry points
<schierbeck> jamesh: okay
<schierbeck> perhaps i'll switch to it later on
<schierbeck> also depends on distribution stuff
<jelmer> schierbeck: I'd rather use seahorse than pygpgme since seahorses password prompting will always be gtk based
<jamesh> schierbeck: whatever you do, don't use pyme
<jamesh> it is one of the worst kinds of swig generated Python extension
<ubotu> New bug: #210053 in bzr "no way to edit subject when using bzr send builtin editor" [Medium,Confirmed] https://launchpad.net/bugs/210053
<ubotu> New bug: #210092 in bzr "Bazaar raises AssertionError in TreeTransformBase.version_file: 'file_id is not None'" [High,Confirmed] https://launchpad.net/bugs/210092
<jelmer> schierbeck: the seahorse-integration branch gives me list out of range exceptions
<ubotu> New bug: #209849 in bzr "Bazaar chokes when running commands over SFTP" [Undecided,New] https://launchpad.net/bugs/209849
<ubotu> New bug: #209948 in bzr "bzr log failure (possible regression)" [High,Confirmed] https://launchpad.net/bugs/209948
<ubotu> New bug: #209998 in bzr-gtk "Should integrate with Seahorse" [Medium,In progress] https://launchpad.net/bugs/209998
<ubotu> New bug: #209912 in bzr "--hardlink option produce traceback on Windows" [Undecided,New] https://launchpad.net/bugs/209912
<g0nzal0> hello there, I'm trying use bazaar to do personal version control of a little django project
<g0nzal0> using Ubuntu 7.10
<g0nzal0> I get this: http://dpaste.com/42536/ :(
<g0nzal0> when doing commit
<g0nzal0> for the first time
<AfC> g0nzal0: you really want to be using a version of Bazaar that is not 6 versions old.
<AfC> g0nzal0: upgrade to bzr >= 1.3
<g0nzal0> AfC: OK!
<bob2> g0nzal0: 'bzr commit -q' might succeed
<james_w> g0nzal0: what's your locale?
<bob2> if that error is from trying to print the filename
<AfC> g0nzal0: 0.90 is ancient
<g0nzal0> AfC: I thougth so.., thanks
<g0nzal0> james_w: es_AR.UTF-8
<schierbeck> jelmer: yeah, i noticed
<james_w> g0nzal0: there is a PPA you can use to get the latest version
<schierbeck> jelmer: it's if you don't have the key
<g0nzal0> AfC: I thougth apt-get install bzr would get it
<james_w> https://launchpad.net/~bzr/+archive
<g0nzal0> james_w: thanks
 * AfC is a bit shocked that Ubuntu doesn't publish updates of things, but that's ever been the Debian way.
<siretart> AfC: ubuntu does update software, even in released version. the updating policy is documented on wiki.ubuntu.com
<AfC> Uh huh
<schierbeck> jelmer: is it still giving off noise?
<jelmer> schierbeck: let me try
<jelmer> dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id:
<schierbeck> jelmer: you're at revision 427?
<jelmer> schierbeck: yes
<schierbeck> hmm
<schierbeck> i'll see if i'm running an old version of seahorse
<schierbeck> i'm running 2.20.1
<jelmer> GNOME seahorse 2.22.0
<schierbeck> you're running hardy, right?
<jelmer> no, Sid
<schierbeck> okay
<schierbeck> i'm not sure what's changed in the api
<schierbeck> can you try using self.get_id() instead of self.key in GetKeyField() et al?
<jelmer> dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id:
<schierbeck> what method is throwing it?
<schierbeck> is it discover() or one of the getters?
<jelmer> not sure, the machine I was runnig it on just crashed :-(
<sabdfl> is bzr.dev having a crisis of identity?
<sabdfl> peregrine% ./bzr pull                                        ~/software/bzr.dev
<sabdfl> Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/
<sabdfl> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/".
<Peng> sabdfl: >= r3309?
<Peng> sabdfl: https://bugs.edge.launchpad.net/bzr/+bug/207558
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress]
<sabdfl> 3323
<Peng> ubotu: When did you get back?
<Peng> Fuck! X-Chat's dying again.
<Peng> Or, some less-obscene variant of that sentence.
<schierbeck> jelmer: still no luck?
<ubotu> New bug: #210142 in bzr "Log comments cannot be changed/edited/annotated" [Undecided,New] https://launchpad.net/bugs/210142
<mtaylor> is there a way to change a repository from --with-trees to --without-trees without recreating it?
<dato> mtaylor: there is `touch .bzr/repository/no-working-trees`
<mtaylor> dato: nice :)
<schierbeck> hmm, perhaps i should work on my exam assignment today...
<schierbeck> i always get so god damned productive when i have exams!
<schierbeck> just in the wrong areas...
<jelmer> schierbeck: one sec
<jelmer> schierbeck: http://pastebin.org/26636
<jelmer> schierbeck: yeah, I always get that as well.. the more you have to do, the more interesting other things become :(
<ubotu> New bug: #210218 in bzr ""bzr send" fails if branch nick contains a slash" [Undecided,New] https://launchpad.net/bugs/210218
<aantn> hello
<aantn> can I get bzr merge to ignore two revisions from the merge source?
<aantn> I'd like it to merge all revisions after revision number x
<aantn> and permanently ignore the revisions before that
<aantn> The man page explains that "If you specify two revisions, the first will be used as a BASE,
<aantn>   and the second one as OTHER."
<aantn> I'm not sure what the 'other' means
<luks> you would need to cherry-pick those revisions
<luks> which has it's disadvantages
<luks> regular merge will only merge the whole branch
<luks> no easy way to workaround it, because it would mean that the newer revisions in the new branch have different parents than the same revisions in the old branch
<luks> what you can do is a full merge, and then revert those X revisions with a reversed merge
<aantn> I'm not sure I follow...
<luks> which part?
<luks> or the whole monologue? :)
<aantn> luks: why a regular merge beginning from a specific number wont work
<luks> because revisions in bzr have some identifiers and have defined their parent revisions
<luks> if you merge from some specific revisions, you would break the original revision parent<->children chain
<luks> bzr allows you to do that, but it will look differently from a regular merge
<luks> (it's called cherry-picking)
<luks> what is your use case for this?
<aantn> hmm...
<aantn> I run my own branch that really is probably going to split from the trunk
<aantn> I've already added the feature that those revisions add to the trunk
<aantn> And I like the way I implemented it more than the way it was done in trunk
<aantn> I think I'll just merge it in and then restore it to what it was before
<luks> yes, that's the best solution I think
<luks> do a full merge, and revert those specific changes
<aantn> luks: is there a command to do that, or should I just do it by hand?
<luks> well, if they are touching the same code, you will have conflicts on the merge
<luks> so you will probably have to do manually anyway
<aantn> luks: probably
<aantn> thanks
<luks> `bzr shelve` could help probably
<luks> that is, in case you don't have textual conflicts, but want to revert specific changes
<luks> if those changes affect whole files, you can simply use `bzr revert path/to/file`
<aantn> luks: that should work
<Peng> What's that simple POST to see if an HTTP smart server is alive, that just returns "ok2"?
<james_w> Peng: there's a hello plugin
<james_w> so I think you can do bzr hello bzr+http://wherever
<ubotu> New bug: #210280 in bzr "unable to obtain lock after push failure" [Undecided,New] https://launchpad.net/bugs/210280
<Peng> james_w: That's true. I've even downloaded it, but never installed it.
<Peng> I've got it.
<Peng> $ echo hello | POST http://.../.bzr/smart
<Peng> bzr-hello is neat too.
<cody-somerville> What is the command to build a debian package from a repository?
<LeoNerd> apt-get source foo;  debuild ?
<Peng> There's bzr-builddeb.
<cody-somerville> Thanks Peng
<LeoNerd> Oh.. that :)
<cody-somerville> Are you sure thats the command?
<cody-somerville> oh, I guess I don't have it installed
 * cody-somerville thought he did.
<Peng> Yeah, it's a package. I don't know what the command is.
<cody-somerville> fun
<james_w> cody-somerville: try without the -
<james_w> bzr builddeb
<beuno> poolie, lifeless, did you manage to send in the paper for debconf?
<james_w> hi besonen_mobile2
<james_w> and beuno, hi to you too
<beuno> hey james_w!  how are you?
<james_w> good, how are you?
<beuno> pretty good, finally caught up with most of the stuff I had left fall behind  :)
<beuno> how's your new work?
<james_w> it's going great thanks.
<beuno> I'm glad :)
<jelmer> hi james_w
<jelmer> james_w: Did you see the bug report I filed on bzr-builddeb's timestamps?
<jelmer> james_w: Took me a while to figure out what was causing those differing checksums...
<james_w> jelmer: yeah I did
<james_w> I haven't had time to look at though I'm afraid
<dato> is it going to work by just using the same timestamps?
<james_w> I don't know
<jelmer> dato: yep, a diff on the tarfile showed that was the only thing that differed
<dato> fwiw joeyh wrote pristine-tar for stuff like this
<dato> jelmer: aha
<jelmer> dato: that's the other way around though
<james_w> dato: i'd like to integrate it, but there's no easy place to stash the diff in bzr
<dato> james_w: true...
<jelmer> james_w: Hmm, looks like that's actually a bug deep inside the bzr export code...
<james_w> jelmer: that it doesn't set the timestamps, or something else?
<jelmer> james_w: it explicitly sets the timestamp to time()
<jelmer> the exporting happens from a revision tree, when there is no revision object around anymore
<jelmer> bzrlib/export/tar_exporter.py:33
<james_w> I can get the revision object in builddeb and set the timestamp then
<jelmer> you mean avoid the standard bzr export code?
<james_w> no, just set the timestamp after
<james_w> if I could do it with the bzr export code that would be better obviously
<james_w> a timestamp= parameter or something
<jelmer> james_w: there is no generic timestamp argument passed to the argument code at the moment
<jelmer> though one could be added, I guess
<james_w> yeah, I don't know if it could be done without breaking other exporters, I'm not looking at the code at the moment.
<james_w> that would probably be the cleanest way though.
<jdong> james_w: any hints on http://launchpadlibrarian.net/13012802/buildlog_ubuntu-hardy-i386.bzr-builddeb_0.93_FAILEDTOBUILD.txt.gz?
<james_w> Unable to load plugin 'builddeb' from '/build/buildd/bzr-builddeb-0.93/build/lib/bzrlib/plugins'
<james_w> that's annoying
<james_w> we need a -Dplugin_loading or something
<james_w> it means that I want the ~/.bzr.log to debug it
<james_w> jdong: there's no easy way to run the testsuite from debian/rules, I thought this way would be it, but it only seems to have built in mine and my sponsor's chroots
<james_w> so I don't know what the fix is exactly.
<james_w> perhaps just to disable the testsuite during the build.
<james_w> though I don't like doing that
<jdong> james_w: odd enough it worked in my pbuilder too....
<jdong> james_w: hmm I'll disable the test suite for now so we don't lose the bzr-builddeb binary entirely while we investigate a better fix
<james_w> thanks
<james_w> the other alternative is to cat ~/.bzr.log if that command fails, just so we can debug it properly
<schierbec1> jelmer: ping
<jelmer> schierbec1: pong
<schierbec1> jelmer: i'm tweaking the sig tab labels
<schierbec1> i'm thinking: a bold headline and a longer description
<schierbec1> such as:
<schierbec1> *Authenticity unknown*
<schierbec1> This revision has not been signed; it may be forged.
<schierbec1> etc.
<schierbec1> what do yuo think?
<schierbec1> *you
<jelmer> schierbec1: The fact there is a signature doesn't say the revision is or isn't forged
<jelmer> schierbec1: I can forge one of your revisions and sign it.
<schierbec1> jelmer: yeah, but signed + trusted key => not forged, right?
<jelmer> schierbec1: no, that implies you trust all people whose keys you've signed to not forge revisions
<schierbec1> well, okay then
<schierbec1> but then the whole idea of signatures kind of goes away
<schierbec1> if you can't even trust your trusted friend to f00k you over
<jelmer> schierbec1: right, but that's what the whole discussion about signatures in bzrlib was about
<schierbec1> jelmer: what if we match the signature name + email with the committer's?
<jelmer> schierbec1: yeah, that would make some sense
<schierbec1> so a revision signed by its author is authentic if the key is trusted?
<jelmer> schierbec1: yeah
<mdke> quick question. When I upgrade a branch from dirstate-with-subtree to rich-root-pack (on Launchpad), what will the other users of the branch need to do to get the changes? upgrade their branches too or get them again?
<jelmer> mdke: afaik they should be able to continue pulling if they have bzr >= 1.0
<mdke> jelmer: and pushing?
<jelmer> mdke: pushing will still be possible too
<mdke> cool, thanks. but to get the benefits they need to upgrade right?
<jelmer> mdke: it'll be slower than it can be though, so I would highly encourage them to also upgrade to --rich-root-pack
<mdke> fine, thanks a lot
<jelmer> schierbec1: so I think we have 4 situations then:
<jelmer> or rather 5
<schierbec1> jelmer: so we have four cases: (unsigned), (signed - trusted), (signed + trusted - committer), and (signed + trusted + committer) ?
<schierbec1> oh
<schierbec1> what's the fifth?
<schierbec1> well, (signed + committer - trusted)
<jelmer> yeah, 4
<jelmer> schierbec1: no signature, signed by trusted author, signed by untrusted party, signed by trusted person (not author)
<mw-home> does bzr have keywords like $Id: $ ?
<jelmer> okay, that matches what you said
<jelmer> mw-home: nope, not yet
<schierbec1> i think we should only handle unsigned, signed+trusted+committer and signed-trusted+committer
<jelmer> mw-home: there is an open specification about it but nobody working on it yet afaik
<schierbec1> that's all related to authenticity
<jelmer> schierbec1: I think we should show if somebody who's trusted but not the author has signed
<schierbec1> jelmer: yeah, but perhaps delay that a bit
<jelmer> schierbec1: We should clearly state that that person is not the author
<jelmer> schierbec1: ok
<jelmer> schierbec1: We should be checking against committer email btw, not author email
<schierbec1> jelmer: i think we should have an 'Authenticity' section
<schierbec1> okay
<jelmer> schierbec1: also, if the revision is signed by somebody untrusted it's not relevant if that key's email matches the committer email
<jelmer> since we can't trust the email on the key to be valid
<schierbec1> exactly
<schierbec1> jelmer: but we may like to provide the user with the option of trusting the key
<jelmer> schierbec1: we should leave that to specific apps such as seahorse imo
<schierbec1> if he's spoken with the committer and knows the revision is authentic, we can then trust it (marginally)
<schierbec1> jelmer: seahorse is meant to be integrated like that -- no ordinary user will open up a key manager
<jelmer> schierbec1: I think we should allow launching a key details dialog or something from seahorse
<mw-home> jelmer: thanks for the information.
<jelmer> but we shouldn't have a "trust this person" key, that's really outside of the scope of bzr-gtk
<schierbec1> jelmer: i'm not sure -- if that's the way the user extends his trust network?
<jelmer> schierbec1: signing keys should involve identity verification and the like
<jelmer> schierbec1: also, seahorse already deals with this task, let's not reimplement that bit
<jelmer> afaik the key information diaog from seahorse has buttons for trusting the key
<schierbec1> jelmer: allright, but perhaps we can have a look at it in the future
<schierbec1> jelmer: does it still throw exceptions at you?
<schierbec1> i talked with a seahorse dev, he said the api didn't change
<schierbec1> jelmer: btw, i've pushed to lp, you can check out the new headings
<jelmer> schierbec1: yep, still errors
<jelmer> Invalid key id:
<schierbec1> can you print out the key?
<jelmer> this is on your signed revisions
<schierbec1> it should be of the format "openpgp:<key>"
<jelmer> it works fine for my own signed revisions
<jelmer> such as 14.1.1 (in bzr-gtk)
<jelmer> schierbec1: The "Authenticity confirmed" bit is incorrect until we're checking the author email == key email
<schierbec1> jelmer: yeah, this is just the ui bits, i'll add the comparison asap
<schierbec1> jelmer: can you add a print in crypt.py so i can see what the key looks like?
<jelmer> sure
<jelmer> what/where?
<schierbec1> just in Key.__init__()
<schierbec1> print key
<schierbec1> jelmer: it may also be that my key is not fetched from the server
<jelmer> schierbec1: We should not rely on seahorse being able to fetch a key
<jelmer> schierbec1: since you may be offline, for example
<jelmer> schierbec1: I think I also have automatic key fetching turned off in gpg since it is slow
<schierbec1> jelmer: i'm not completely sure what the protocol is, but the docs mention that a key may be "missing" at first
<schierbec1> jelmer: but that may very well be the problem
<schierbec1> jelmer: i'd like to try something: in __init__(), replace "discover(key)" with "discover(self.get_id())"
<schierbec1> that's just to see if the api's changed
<jelmer> schierbec1: that changes the error back to the list index out of range exception
<jelmer> schierbec1: what does DiscoverKeys() do exactly?
<jelmer> does that try to fetch the key from the web?
<schierbec1> yup, or the local network
<schierbec1> i'd like to see the value of "key" -- can you print it out?
<jelmer> schierbec1: key is an empty string
<schierbec1> it sounds like VerifyText returns something stupid
<schierbec1> hmm
<jelmer> schierbec1: seahorse also has an option to automatically discover keys as they are requested
<schierbec1> what about cleartext in crypt.verify() ?
<jelmer> schierbec1: I'd rather rely on that
<jelmer> schierbec1: cleartext does indeed contain the testament
<schierbec1> that's funny -- the "key" return value is just empty?!
<jelmer> schierbec1: dbus.String(u'')
<schierbec1> ?
<jelmer> schierbec1: "print repr(key)" prints dbus.String(u'')
<schierbec1> 3 seconds, on the phone
<schierbec1> jelmer: sorry, my mom called
<schierbec1> hehe, a bit hard to just hang up...
<schierbec1> jelmer: but yeah, it's returning an empty string -- i'll just make a test for that and mark the key as invalid then
<jelmer> schierbec1: s/invalid/unknown?
<jelmer> since it could be trusted
<jelmer> schierbec1: it's a bit odd though that it doesn't return anything at all, it should known the key id even if it doesn't have the key
<schierbec1> jelmer: exactly, but i guess we'll just mark it as unsigned or what?
<jelmer> schierbec1: unknown should be a separate thing imho
<schierbec1> jelmer: okay, like "error verifying key"?
<schierbec1> oh, the seahorse guy is responsive now, i'll ask him
<jelmer> schierbec1: ah, cool
<jelmer> schierbec1: it would be nice if seahorse could actually return the key id there
<jelmer> schierbec1: and it would be nice if a command could be added to the DBus API to display the key information dialog for a particular key
<schierbec1> yup
<schierbec1> jelmer: could i get you to pastebin the crypttext of a revision that doesn't work?
<schierbec1> in crypt.verify()
<jelmer> http://pastebin.org/26731
<schierbec1> yeah, that looks like it should
<schierbec1> i'm talking with the seahorse guy, it seems that it's because the key is not in your keyring
<jelmer> schierbec1: right, and it shouldn't have to be
<jelmer> I mean, seahorse should be able to return the key idea
<jelmer> and we could print something like "signature from unknown key YYYY"
<schierbec1> jelmer: exactly
<schierbec1> right now, i think we should just write "Authenticity cannot be verified -- Key not available"
<jelmer> right, that makes sense
<schierbec1> jelmer: okay, pushing a fix to lp
<schierbec1> let's see if this works
<jelmer> schierbec1: yep, works now - thanks
<schierbec1> cool
<jelmer> schierbec1: This should not be marked as Authentication error imho
<schierbec1> i was just about to ask
<schierbec1> what do you think? "Authenticity cannot be verified"?
<schierbec1> s/verified/confirmed/
<jelmer> yep, that sounds good
<schierbec1> jelmer: ok, it's pushed
<schierbec1> jelmer: just one last thing -- try replacing VerifyText with DecryptText
<schierbec1> it could be an error in the VerifyText implementation
<jelmer> "No data"
<schierbec1> hmm, well, ok then
<schierbec1> jelmer: i think i'll rewrite the descriptions
<jelmer> schierbec1: we shouldn't be calling discover() imho
<schierbec1> we're not anymore
<jelmer> my bad, it's just the function that's still there
<jelmer> sorry
<schierbec1> "The revision has been signed by a person you trust" ?
<schierbec1> s/The/This/ ?
<jelmer> and which person, if possible :-)
<schierbec1> or rather "... signed with a trusted key" ?
<schierbec1> jelmer: yeah :)
<jelmer> I'd prefer "signed with a trusted key "
<schierbec1> okay
<schierbec1> and then "This revision has been signed, but you do not trust the authenticity of the key."
<jelmer> what about "This revision has been signed with an untrusted key" ?
<schierbec1> jelmer: i think it's perhaps too close to the trusted version
<schierbec1> just two letters apart
<schierbec1> we should emphasize that it's not trusted, as a signature in itself means nothing
<jelmer> we need more colored icons :-)
<Kinnison> Is bzr currently unable to branch from launchpad?
<Kinnison> I was trying to get the gedit plugin and bzr says it's not a branch
<schierbec1> jelmer: always :)
<schierbec1> jelmer: i'm working out a seahorse patch with the dev guy
<jelmer> schierbec1: cool
 * Kinnison hrms, also can't bzr pull from the bzr-svn branch
<Kinnison> perhaps launchpad is moosed
<jelmer> Kinnison: I think there was a regression in bzr.dev that breaks it with launchpad or something
<Kinnison> jelmer: arse
<Kinnison> oh well
<Kinnison> no bzr-svn for me until that's fixed :-)
<james_w> Kinnison: you should be able to pull over bzr+ssh://
<schierbec1> jelmer: what about "This signature has been signed, but the authenticity of the signature cannot be trusted."?
<Kinnison> james_w: from a branch I don't own?
<james_w> Kinnison: yeah, you don't need write permission to pull
<Kinnison> schierbec1: "...signature has been signed..." ?
<Kinnison> james_w: I was more incredulous about having ssh access to branches I didn't own
 * Kinnison didn't know that was allowed
<Kinnison> I thought launchpad virtual-chrooted you
<schierbec1> Kinnison: bzr-gtk ui bits for signed revisions
<schierbec1> oops, s/signature/revision/
<Kinnison> schierbec1: aah, suddenly it makes more sense :-)
<schierbec1> hehe
<schierbec1> jelmer: could i get you to check out a patch for seahorse?
<schierbec1> svn://svn.gnome.org/svn/seahorse/trunk/
<schierbec1> only if you have time
<jelmer> schierbec1: sure
<jelmer> schierbec1: or http://people.samba.org/bzr/jelmer/seahorse/jelmer :-)
<schierbec1> :)
<schierbec1> http://pastebin.com/d24eb0110
<schierbec1> here's the patch
<schierbec1> jelmer: "This revision has been signed, but the authenticity of the key has not been established"?
<schierbec1> perhaps s/key/signature/?
<schierbec1> just chime in, everybody!
<jelmer> schierbec1: I'd rather just say that the key is unknown or untrusted
<schierbec1> ok
<schierbec1> jelmer: "... but the key is not trusted."?
<jelmer> schierbec1: yep
<schierbec1> jelmer: have you tried out the patch?
<jelmer> working on it
<schierbec1> cool
<beuno> vila, I've got 2 hours separated for the upload plugin today, so I'll give you the feedback I owe you  :)
<vila> beuno: great !
<mwhudson> beuno: hi!
<jelmer> schierbec1: yep, that patch fixes it
<schierbec1> jelmer: awesome!
<beuno> hey mwhudson!   welcome back  :)
<ubotu> New bug: #210422 in bzr-gtk "gpg signer should be part of ui_factory" [Undecided,New] https://launchpad.net/bugs/210422
<schierbec1> jelmer: well, now we just have to wait 6 months until the next stable is released! :)
<jelmer> :-)
<chell> hi
<chell> hey
<emgent> http://nopaste/p/aMZkktaSw
<emgent> some idea?
<emgent> bzr locked.
<chell> emgent: nope sorry
<chell> "locked 123 hours, 27 minutes ago" sounds a bit weird
<jelmer> try bzr break-lock
<emgent> jelmer: same error..
<emgent> :|
<beuno> emgent, try a few times more (sometimes LP locks it a few times)
<emgent> beuno: to push or brack-lock ?
<beuno> emgent, break lock
<beuno> emgent: bzr break-lock bzr+ssh://emgent@bazaar.launchpad.net/~emgent/ubuntu-cve-tracker/universe-security-updates
<beuno> 3 or 4 times should do it  :)
<emgent> yes i know
<emgent> but same problem
<emgent> ok :)
<beuno> emgent, still nothing?
<emgent> ok now work :)
<beuno> emgent, :)
<emgent> thanks
 * beuno wonders when LP will fix that bug
<schierbec1> jelmer: okay, now we just need to figure out what to do if seahorse isn't installed
<jelmer> schierbec1: hide the signature tab :-)
<schierbec1> jelmer: yeah, but we should add a check for seahorse :)
<schierbec1> the branch is in the team repo, so you can just commit changes if you wish to
<schierbec1> jelmer: what do you think about left-aligning the table "keys"?
<schierbec1> i.e. the bold labels
<mdke> how can I make changes to the details of my "parent" or "submit" branch?
<beuno> mdke, what kind of changes?
<mdke> beuno: well, remove them or specify another branch
<beuno> mdke, just use bzr push/pull/merge new_location --remember
<mdke> thanks
 * jdong investigates bzr mailing list... did he break bzrtools?
<beuno> :)
<jdong> it worksforme....
<beuno> jdong, he probably has pycentral b0rked
<jdong> beuno: also see bug 210452 though
<ubotu> Launchpad bug 210452 in bzrtools "error updating bzrtools" [Undecided,New] https://launchpad.net/bugs/210452
<jdong> it seems like a different reporter
<jdong> perhaps it only happens on an update?
<james_w> jdong: there's a load of bugs filed with this error
<james_w> on different packages
<james_w> I can't remember the fix offhand, I think it might have been rebuilds, but that doesn't make sense here
<james_w> https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/197840 is one
<ubotu> Launchpad bug 197840 in bzr-svn "bzr-svn fails to install (Ubuntu Hardy, with ppa bzr)" [Undecided,Fix released]
<james_w> https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/197692
<ubotu> Launchpad bug 197692 in python-central "package ubuntu-desktop 1.94 failed to install/upgrade: problemas de dependencias - se deja sin configurar" [Undecided,Fix released]
<james_w> that's the one
<jdong> odd
<james_w> jdong: yeah
<james_w> jdong: passing it on to python-central may be the right thing to do, I don't know
<james_w> I don't really know what bzrtools might have done to provoke this
<james_w> although, hang on, bzrtools was a merge, so maybe something was dropped
<james_w> or maybe not dropped, but needs to be improved.
<xma> 'lo
<xma> why does bb crash so often ?
<lifeless> does it ?
<xma> :)
<xma> each time I want to read patch entries => no luck (500 internal error)
<lifeless> xma: whats the last couple of lines of the traceback?
<xma> each time I have seen it, it was a SQL query
<poolie> hello xma
<lifeless> let abentley know, probably via the list
<poolie> i think it crashes pretty often
<xma> poolie: hello
<poolie> all things considered
<poolie> i still love it deeply
<xma> yes it is very valuable
<xma> (when it works :))
<abentley> It crashes so often mainly because I don't know why it crashes so often :-)
<xma> I learnt many python related things when reading people's patches
<xma> abentley: hey aaron
<xma> 00:04 <lifeless> let abentley know, probably via the list
<xma> ;)
<xma> so it is down now: OperationalError database is locked
<xma> gotta go now
<xma> see ya all
<poolie> hello abentley
<abentley> poolie: hi
<poolie> there was a recent bug report of a failure in treetransform
<poolie> if you get a sec could you comment on it, if you have not already?
<abentley> Okay
<poolie> it should still be in the recent list
<igc> morning all
#bzr 2008-04-02
<igc> poolie, spiv: call on today?
<poolie> igc, yes, but i can't get in
<poolie> still trying
<igc> poolie: I'll hang up in case that helps
 * spiv hangs up too
<schierbec1> jelmer: ping
<igc> poolie: I got straight back in ok
<igc> is it your local phone maybe?
<poolie> it might be my phone
<poolie> when i tried i got through to varying extents
<poolie> anyhow
<poolie> let's just catch up here on irc?
<spiv> Sounds good.
<igc> me too
<poolie> so i think the PPA stuff is all settled now
<igc> today, I'm planning to review patches, particularly the xml8 serializer one
<poolie> i'm going to look at what bugs i currently have assigned to me and either finish some of them, do reviews, or do startup time hacking
<igc> I need to learn more about that so reviewing that patch will help me
<poolie> i'd like to suggest the whole project do a bug day tomorrow, will send mail about that
<poolie> also i seem to have some Ubuntu bugs atm
<poolie> so will file them
<igc> poolie: were you planning to tweak james_w's patch on lp: urls or shall I do that? we both voted tweak
<poolie> i'll do that
<igc> thanks
<poolie> also when lifeless is back i'll call him re his conference submission
<poolie> and i owe thumper a call or sketch of the branch listing page
<igc> if you get a chance, I'd like some feedback on my hook patch/rfc too
<spiv> I've sent off the core bits of the fix for bug 207558.  I want to do a little more on it (as mentioned in the most recent email to the list about it), but it's essentially done.
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
<poolie> ok
<poolie> i'll try to read that for you spiv
<poolie> what is next for you?
<spiv> So today will be mainly server-side hooks.
<igc> poolie: another thing for me today - kill & resume the OOo import
<igc> it's at 157k out of 305k, taking 18 minutes per 100 revisions so dog slow
<igc> I took the call to enable_cache out of the code yesterday at lifeless' request so I'll resume it with that code gone and see if it helps
<poolie> ok, good
<lifeless> igc: We should find what the cache was masking and fix it.
<lifeless> igc: I strongly suspect that using commit builder will give you better performance and let you get to an incremental-change approach safely for the importer
<lifeless> igc: with appropriate tweaks to the builder of course; but thats what its meant to be used for - install_revisions shouldn't, IMO, need to exist.
<igc> lifeless: maybe. commit-builder currently does things much slower than the importer does
<igc> it simply can't make some of the assumptions than an importer can
<igc> which make big differences to speed
<lifeless> igc: without details I can't comment; but if we're to continue to accelerate commit, commit builder has to learn how to work with very smart trees; which an import source can be considered to be.
<lifeless> igc: in dealing with merge revisions, if commit builder is slower, I have to assume that the importer is wrong :>
<lifeless> I'm going to do a couple of spikes today
<lifeless> and get back to VF this afternoon
<lifeless> I chatted with benno last night about python performance
<lifeless> and he concurred with my import analysis, gave some commentary on os call performance readdir etc
<lifeless> so I'm going to do this long threatened import hook
<spiv> lifeless: based on my stracing and experiments in London, I'm only expecting a very modest win (300ms improvement in cold cache time).  I'll be interested to see if the reality is different.
<lifeless> spiv: strace doesn't show how much time python spends marshalling
<lifeless> spiv: I suspect that there is some compiler overhead that won't be addressed by a simple import hook
<lifeless> holy cow 'import bzrlib' hits a lot of shit
<lifeless> 34 modules
<poolie> yes, i know
<lifeless> many are demand load stubs I think
<lifeless> or something strange
<lifeless> -weird
<lifeless> >>> type(sys.modules['bzrlib.struct'])
<lifeless> <type 'NoneType'>
<spiv> That's expected.
<spiv> When a module inside the bzrlib package tries "import struct", python first treats it as a relative import.
<spiv> And when an import fails, it caches misses as well as hits in sys.modules.
<lifeless> ah good
<spiv> (Bring on python 2.5...)
<lifeless> 12 real modules imported then
<spiv> lifeless: I see 58 new modules imported by "import bzrlib" with bzr.dev.  (Only 12 with http://people.ubuntu.com/~andrew/bzr/faster-startup, though...)
<spiv> (as measured with PYTHONPATH=. python -c "import sys; get_mods = lambda: set(name for name, mod in sys.modules.items() if mod is not None); before = get_mods(); import bzrlib; after = get_mods(); print len(after - before)")
<lifeless> spiv: what does your faster-startup branch do ?
<lifeless> spiv: (I am only planning to alter the behaviour of bzrlib specific imports)
<spiv> lifeless: basically, various hackery to defer unnecessary imports
<spiv> (or avoid)
<spiv> lifeless: it's cumulatively a few hours of iterating on "bzr --profile-imports" on simple commands like "rocks" and "status" and seeing what cheap wins I could get.
<lifeless> has anyone tried running freeze on bzr ?
<spiv> Oh, and specifically also reducing the amount of the universe that "import bzrlib" imports :)
<lifeless> e.g. making *everything* import and running freeze
<lifeless> spiv: so my thesis is that we should make importing everything fast
<lifeless> because in the general case most of the code is needed
<lifeless> spiv: what do you mean about 2.5?
<mwhudson> i don't think he meant 2.5
<mwhudson> at some point, imports written the normal way will be absolute
<mwhudson> which means less looking for things like bzrlib.struct
<spiv> I meant file:///usr/share/doc/python2.5/html/whatsnew/pep-328.html
<spiv> 2.5 introduces "from __future__ import absolute_import"
<mwhudson> oh, heh
<mwhudson> shows when i stopped paying microscopic attention to python development
<lifeless> damn, pkgutil doesn't exist in 2.4
<lifeless> so, I'm saving 130/4900 open calls
<lifeless> all of which look like failures
<LaserJock> question, how do I change the "parent branch" of a branch?
<poolie> igc, is there a BB enttry for the patch from james_w you mentioned before?
<poolie> igc, i take it you were referring to the one to give a warning when getting a readonly transport?
<igc> poolie: that's right
 * igc looks
<igc> http://bundlebuggy.aaronbentley.com/request/%3C1205831646.7247.295.camel@flash%3E
<igc> poolie: ^^^
<poolie> thanks
<lifeless> LaserJock: pull --remember
<LaserJock> lifeless: awesome
 * igc lunch
 * mwhudson tries to work out if it's strange or not for merge --preview to complain about uncommitted changes
<spiv> mwhudson: there was a thread about that on the list recently
<spiv> mwhudson: it shouldn't complain, IIRC
<mwhudson> there was?  must have missed that in my catchup
<lifeless> mwhudson: it should tell you, and take your changes as part of the merge
<lifeless> mwhudson: IMO
<mwhudson> i guess that makes sense
<lifeless> ok, I now have my code being called consistently
<abentley> lifeless: well, I'm not convinced.
<abentley> It's not a very accurate preview that way.
<lifeless> abentley: why is it less accurate?
<abentley> because merge won't make any of those changes.  It will barf.
<poolie> abentley: thanks for the review ofthe help change
<abentley> np
<abentley> Something else I meant to mention is that people will still get criss-cross warnings if they are using --weave or --lca
<abentley> Even though those algorithms handle criss-cross better.
<abentley> So perhaps it should say not to remerge if you're already using --lca or --weave.
<poolie> so would you overall suggest using remerge, or revert and merge again?
<lifeless> back in a few minutes; getting lunch
<abentley> poolie: I'd suggest revert and merge.
<abentley> Fewer commands to learn that way.
<lifeless> abentley: when is remerge a good thing to learn and use then ?
<abentley> I generally use it when I've got a single file with really wacky conflicts, and I want to try out a bunch of different mergers to get the best result I can.
<abentley> If there are basic, intermediate, and advanced commands, I'd consider it intermediate.
<lifeless> ok
<lifeless> one thing I've found with loom is that there was a bunch of 'when I use it' implicit in the thing that I hadn't written down.
<lifeless> I think we may have something similar here.
<poolie> that is basically when i use remerge too
<poolie> rarely on the whole tree
<poolie> could we at least make it fail safe on looms - like give an error rather than mess things up?
<abentley> lifeless: are you familiar with the problem?
<lifeless> abentley: no, I've never used remerge like that
<lifeless> oh, you mean with looms - I've seen the bug report
<abentley> So the problem is that remerge assumes the .THIS file coresponds to the left workingtree parent.
<abentley> but with up-thread, it is actually the rightmost parent.
<lifeless> I think the things are about-face for performance
<lifeless> I didn't want to transform; then merge
<abentley> I'm not sure your approach is wrong.  A different approach might lead to more conflicts.
<lifeless> its on my long todo to teach bzr's merge the ability to be told different file suffixes
<lifeless> so we can drop the 'right files' in the right places
<lifeless> and give better herringbone labels
<abentley> You'd also want to swap the conflict markers.
<abentley> :-)
<lifeless> I'd actually like to call them by their thread names
<fullermd> Speaking of merge, did --reprocess stop doing its thing sometime?  Or did it just never really cut things down a lot?
<abentley> Sure.
<lifeless> fullermd: I think it became default
<poolie> abentley: could you suggest some better help text?
<poolie> should we say "use remerge FILE, or revert and merge again?"
<abentley> Let's say "revert and merge again".
<abentley> lifeless: So we understand the problem-- is there a short-term fix we can do like poolie suggested?
<abentley> fullermd: I don't think it became the default.  But it only helps a narrow class of merges, and only applies to --diff3
<abentley> lifeless: The problem so far is that we can't even tell that the merge was different.
<fullermd> I've got kernel configs in bzr to easily merge upstream changes, and every time I do (last was some months ago), I get hyuge spurious conflicts that it doesn't help.
<abentley> fullermd: line endings?
<fullermd> No, but changes in single lines ended up resurrecting giant blocks that I'd deleted.
<awmcclain> Imagine we pushed some changes for April Fools day. Like, 4 revisions. What would the easiest way, hypothetically, to check an older revision to head?
<fullermd> I guess it's some artifact of the diff hunk for the revs where I whacked the blocks.
<spiv> awmcclain: bzr push -r NNN --overwrite
<spiv> awmcclain: (NNN == -4, I guess...)
<awmcclain> spiv: And if it's a bound branch, can we do bzr ci -r NNN --overwrite?
<abentley> fullermd: I'd normally offer to help, but I'm behind already.
<spiv> awmcclain: ah, with a bound branch, use uncommit
<awmcclain> spiv: 4 times?
<spiv> awmcclain: which also takes a -r arg.
<spiv> Or just run it 4 times, sure.
<awmcclain> spiv: Gotcha!
<fullermd> Or just pull -r-4 --overwrite .
<spiv> fullermd: heh.
<lifeless> fullermd: pull overwrite affects master branch :)
<fullermd> abentley: *shrug*  It's not that big a deal.  Bugs me for 30 seconds or so a couple times a year when I do it.  Hasn't been a high enough priority for me to build up a test case for it.
<abentley> fullermd: You might try --lca.  It's kinda got --remerge built in.
<abentley> s/--remerge/--reprocess
<fullermd> Last time I tried was probably pre-lca; I tried both diff3 and weave, with/out reprocess; came up the same every time.
<awmcclain> But if I want to commit _over_ the current changes, not remove them.. could i bzr revert -r NNN then ci?
<fullermd> I'll try getting creative next time it comes up.
<spiv> awmcclain: right
<poolie> abentley, BB seems to be stuck, can you whack it?
<abentley> poolie: did it give you a lock error?
<spiv> abentley: I'm currently getting 502 Proxy Error
<spiv> "Reason: Error reading from remote server"
<igc> abentley: me too
<igc> " The proxy server could not handle the request GETÂ /."
<abentley> I have increased the database timeout to unreasonable levels.
<abentley> So there's an active lock, but I'm not sure whether it will resolve itself.
<abentley> The last time I got a 502, it did.
<poolie> same
<lifeless> you're using sqlite right?
<abentley> Okay, whacked.
<abentley> lifeless: right
<lifeless> there is something funny in the python bindings AFAICT
<bob2> sqlite3?
<poolie> abentley: how about this:
<poolie> In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give
<poolie> better results.  You may wish to `bzr revert` the working tree and merge
<poolie> again, or use `bzr remerge` on particular conflicted files.
<poolie> i feel kind of reluctant not to mention remerge because it's what i usually run myself
<poolie> i see your point though about involving less commands
<abentley> Okay, fair enough.
<poolie> and if they did help criss-cross just after the failure they will not lose anything
<abentley> Perhaps we should omit the revert; remerge thing.
<abentley> Pardon?
<abentley> lifeless: Any suggestions on a band-aid for up-thread?
<lifeless> abentley: w.r.t remerge ?
<abentley> Yes.
<lifeless> I don't think there is a good band-aid; I think it just needs the bzrlib work done.
<poolie> """In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give
<poolie> better results.  You may wish to `bzr revert` the working tree and merge
<poolie> again.  Alternatively, use `bzr remerge` on particular conflicted files.
<poolie> "'"
 * poolie reads fix for 207558
<lifeless> poolie: call ?
<poolie> in 6m?
<lifeless> sure
<abentley> poolie: re that TT bug, it's due to adding a file to a deleted directory, when the deleted directory was the root directory.
<poolie> !
<poolie> ok
<lifeless> spiv: ping
<abentley> Anyhow, now that I can reproduce it, it shouldn't be a hard fix.
<lifeless> I have a 'wtf' moment with my import hook
<poolie> lifeless: your phone's engaged?
<lifeless> its trying to import 'debian_bundle' from '' in the Numeric path path_hook object
<lifeless> poolie: no??
<spiv> lifeless: pong
<lifeless> does Numeric do crack?
<spiv> lifeless: I don't know if Numeric does crack or not.
<mwhudson> beuno: around?
<lifeless> spiv: you have mail
<lifeless> spiv: should be self evident if you want to apply it to bzr.dev and play
<lifeless> spiv: I get quite reduced syscalls with this but its buggy :/
<jamesh> lifeless: bzr-gtk has now been updated so that it functions correctly with my bzr-dbus patches, btw
<jamesh> they're waiting on you for review though.
<lifeless> thanks
<spiv> abentley: bb seems to be wedged again
<vila> lifeless: regarding loom-specific conflict markers, please be sure you won't break external tools that are looking for them (i.e. may be *add* thread name after the usual markers instead of replacing MERGE-SOURCE and/or TREE)
<Egotrip> Want to make $$$ just by clicking? Sign up on http://bux.to/?r=eg0trip, and begin recieving checks!
<james_w> no thanks
<Egotrip> yes you do
<mdke> lifeless: still around?
<lifeless> dunno who egotrip was, but we don't want spam here.
<fullermd> He didn't explain himself very well, certainly.  I kept clicking, but I got @@@ instead of $$$   :|
<jamesh> and I'd prefer to receive cheques rather than checks
<yacc> Hmm, how can I force a baseless merge with bzr?
<schierbeck> jelmer: ping
<yacc> schierbeck: I second that: ping jelmer
<schierbeck> :)
<yacc> schierbeck: what's it for you? In my case bzr-svn seems to have forgotten about branch relationships ;(
<schierbeck> tough luck
<schierbeck> nah, i just want him to give his 2 cents before i send in a merge request
<james_w> yacc:  merge -r1..-1
<yacc> james_w: is that a good idea, considering that the branch contains the same revisions as the remote one? (bzr just seems to think that they are unrelated)
<james_w> yacc: probably not
<james_w> how did you create your local branch?
<yacc> bzr branch svn+https://...
<james_w> from the same branch you are trying to merge now?
<yacc> Look at: https://bugs.launchpad.net/bzr-svn/+bug/210705
<ubotu> Launchpad bug 210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New]
<yacc> james_w: but basically yes.
<yacc> james_w: => it remembers where it pulled from, and pushed to in the past.
<yacc> james_w: just when doing a merge it complains about being unrelated.
<yacc> Oh, bzr missing lists all revisions as missing on both sides, plus the one that I did commit locally, which is only listed on one side.
<yacc> but the merge did not help anything, it still misses 3/4 revisions ;(
<yacc> james_w: despite the above merge -r1..-1, it still claims that the branches are diverging.
<james_w> yacc: can you pastebin a bzr missing --show-ids
<yacc> james_w: just a moment, first I'm curious ;)
<yacc> james_w: they don't match :(
<yacc> http://rafb.net/p/a1aZXh19.html
<yacc> james_w: guess that is what jelmer meant with the ids can change?
<yacc> jelmer!!!!!!!!!!!!!!!
<james_w> they don't match is the reason that you are seeing this issue.
<james_w> calm down, he's been highlighted, if he's around he'll see it
<yacc> james_w: yeah, BUT: I had to change the scheme to include new trunks
<yacc> revision-id: svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56
<yacc> revision-id: svn-v3-list-QlpoOTFBWSZTWYDqAEcAADdRgAAQAAK3r94gIABISkMo0zUaemoEkkaZMAm1IM83f4FQYGxfzVWsvATONoa96yIoS8IEx1BxVRIGB_MCYIMwX5NxaET_F3JFOFCQgOoARw..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56
<yacc> see the base64 encoded list of paths <= I had to change that to accomodate a new branch.
<james_w> you changed the svn branching scheme?
<yacc> james_w: list-path1-path2 => list-path1-path2-path3 <= I had to add path3 because it's a new branch I need access to?
<yacc> james_w: basicaly the revids for branch X contain the a list of all other branches that I'm accessing in the given SVN repo.
<yacc> james_w: Hmmm, I think the fix would be to make bzr-svn use svn-v3-list-$PATH_USED_IN_THIS_CASE instead of svn-v3-list-$PATH_OF_THE_COMPLETE_SCHEME?
<yacc> james_w: Any explanation what the different branching schemes are good for?
<james_w> yeah, so it's caused by the change to the branching scheme
<james_w> the scheme is to tell bzr-svn which paths in svn to consider branches
<yacc> yeah, but the problem is, appending one new "path" in the repository is a quite expected thing to do.
<yacc> It should not break all branches/checkouts in the wild, just because I need to track one additional location?
<james_w> yacc: add this information to the bug report.
<yacc> Already done so.
<yacc> james_w: single would mean that I can only access exactly one path inside the svn repo?
<james_w> I think so
<yacc> Hmmm.
<yacc> So basically I would need to parametrize the "schema name for property name" lookup thing.
<yacc> It basically needs to take the URL being accessed into account ;(
 * yacc wonders what the schemes are good for at all?
<igc> james_w: I'm hoping to review that gnome bug tracker patch tomorrow
<igc> if you put through abentley's tweak tonight, that would be nice ...
<igc> though I realise you may not have time
<igc> I'm heading off now
<igc> night all
<james_w> igc: thanks, I'll try and get to it.
<james_w> night
<jml_> lifeless: ping
<yacc> jelmer: ping
<yacc> jelmer: would it be ok by you to implement a "EveryPathIsABranchScheme"?
<AnAnt> Hello, when using bzr, can't I checkout just a single folder instead of the whole branch ?
<luks> right, you can't
<luks> bzr can only work with whole branches
<AnAnt> unlike svn
<luks> svn doesn't have branch :)
<luks> *branches
<yacc> luks: and branches is (almost) all that bzr has ;)
<yacc> How do I make bzr send my local commits as a patch to the maintainer?
<luks> bzr send
<yacc> I just discovered that just switching schemes won't work => the svn repos contains pointers to the old scheme name, ...
<yacc> My only hope for a sane scheme is rapidly crashing.
<yacc> jelmer: ping
<ChriS_T> I am trying to convince a colleague to use bzr for our collaboration.  However, he has a mac OSX 10.4 intel.  Is there a ready to use disk image for that machine ?
<james_w> there's a macport I think
<ubotu> New bug: #210665 in bzr-svn "bzr svn-import fails" [Undecided,New] https://launchpad.net/bugs/210665
<ubotu> New bug: #210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] https://launchpad.net/bugs/210705
<ubotu> New bug: #210723 in bzr "Some tests failed when selftest is invoked with -v" [Low,Confirmed] https://launchpad.net/bugs/210723
<jelmer> yacc: pong
<jelmer> yacc: EveryPathIsBranchingScheme will be incredibly slow
<yacc> jelmer: why?
<yacc> jelmer: and it misses to_list, which makes --set break, but I guess it breaks for other schemes too.
<jelmer> yacc: When searching for revision ids, bzr-svn checks every possible branch path for properties
<yacc> Well, it seems the that list paths get embedded in the properties somehow, so just doing a fresh branch with the ammended paths is not an option either.
<jelmer> in the case of EveryPathIsBranchingScheme that means one call per file/directory in the remote repository
<yacc> And let me guess it does not cache the results in any way ;)
<jelmer> it does cache the results
<jelmer> but that's still too slow
<yacc> brb
<yacc> so how to fix the list scheme then?
<jelmer> how do you mean?
<yacc> Well, the list scheme embeds the paths in the revision stuff.
<yacc> Meaning that when somebody adds a new path (because a new path got added), bzr-svn implods.
<yacc> jelmer: : #210705
<yacc> jelmer: easy to demonstrate: with a branch that uses a list scheme, add another path to the list => et voila, bzr thinks that the svn remote branch and your local bzr branch do not share any history.
<yacc> Which is wrong.
<yacc> Considering the fact that some svn users use very very creative directory setups, ...
<jelmer> yacc: that's correct because they have a different branching scheme
<yacc> Ok, so how do I handle the case that my upstream project just got a new subproject?
<jelmer> yacc: What you really want is a fix for bug 130372
<ubotu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
<jelmer> yacc: you can use wildcards in listbranchingscheme
<yacc> jelmer: Only if I would have started with wildcards. Take a look at the later comments in 210705 and you'll notice that it seems impossible to switch the scheme for a given repo and recreate the bzr branch
<jelmer> yacc: yes, that's correct
<jelmer> yacc: that's why there's bug 130372
<ubotu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
<yacc> so what do I do? write myself scripts that replace ~/.bazaar/subversion.conf based on the directory I'm in when calling bzr?
<jelmer> yacc: The error fetching after changing branching schemes is a bug
<yacc> So I open up a time loop window, and go studying the source code to fix that bug? <= I mean the scheme is part of the revision IDs?
<yacc> Serious, new bug or known bug?
<jelmer> yacc: the branching scheme is part of the revision id
<jelmer> yacc: that's bug 130372 I mentioned earlier
<ubotu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
<yacc> jelmer: 130372 is not about a bug fix, it's about joined branches, right? Meaning that you could drop to supporting only trunk/none for bzr-svn and make the people use split out parts of these repositories, right?
<jelmer> yacc: no, it's about abandoning branching schemes completely
<jelmer> as soon as by-value branches are supported
<jelmer> well, replacing branching schemes with a "repository layouts", which are not included in the revid
<yacc> So nothing simple for a newbie that has only a limited understanding of bzr internals might want to tackle ;(
<jelmer> yacc: not really, though it should be possible to get that "not present in "... error fixed
<jelmer> I'll see if I can fix that
<rexbron> hey everyone, the docs on this function are a little bit unclear in what order the branch and tree objects are returned
<rexbron> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_tree_or_branch
<rexbron> I think it is mentioned at the end, but I am still unsure
<jelmer> rexbron: tuple with tree and branch
<rexbron> jelmer: K, it mainly that the other funtions make that more clear
<bob2> the first sentence should be fixed then
<yacc> How do I undo local commits?
<rexbron> yacc: bzr uncommit?
<rexbron> or revert
<rexbron> bob2, jelmer: I think it should be changed to something like the method below: Returns (tree, branch)
<bob2> famen
<bob2> tr -d f
<spiv> yacc: in bzr.dev, "bzr uncommit --local"
<spiv> I don't think that's in a release yet, though :(
<yacc> spiv: Well, uncommit seems to have worked :)
<james_w> rexbron: tree will be None if there isn't one if you hadn't figured that out yet.
<spiv> yacc: oh good :)
<rexbron> james_w: I think I need to refresh exactly what the difference between a branch on the file system and a workingtree (beyond different methods for those objects)
<james_w> rexbron: i see ":return: (tree, branch)" for that method
<james_w> rexbron: you can have a branch with no tree
<james_w> i.e. you have .bzr/branch/
<james_w> but there are no files in the working directory, and there will be no .bzr/checkout/
<rexbron> james_w: My comment was that it could be more clearly stated, like in the other functions
<rexbron> james_w: ok
<james_w> you can get this with bzr remove-tree, or with a treeless repository
<bob2> james_w: the furst sentence says the opposite, and I don't think it's unreasonable to assume that it should be correct also :-)
<james_w> and it will also happen for remote trees.
<james_w> bob2: that's true
<james_w> rexbron: that is markup that used to denote the return value.
<rexbron> james_w: is the doc system supposed to format it differently that it currently is?
<james_w> ah, it appears to be spelt wrong, as other functions have it formatter
<james_w> see open_containing_from_transport
<rexbron> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_repository seemes to also have a formatting issue
<rexbron> for :param _unsupported:
<rexbron> now that I look for it, I see a lot of method docs that are (perhaps) not formatted correctly
<james_w> yeah, they do seem to be a bit bad.
<james_w> the API documentation is very hit and miss
<rexbron> james_w: what system is being used, as I would be happy to submit patches
<rexbron> ok, looks like pydoctor
<sabdfl> is mail from the bazaar list getting doubled up?
<yacc> :)
<james_w> sabdfl: I don't see it, you mean you receive multiple copies?
<rexbron> Is there a page which documents the syntax for pydoctor? or is it the same as something else?
<james_w> rexbron: I think it uses the pydoc ones or whatever they are.
<james_w> rest markup in python docstring might get you some useful pages from google.
<sabdfl> james_w: yes, i do get multiple copies
<sabdfl> peregrine% ./bzr pull
<sabdfl> Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/
<sabdfl> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/".
<sabdfl> anybody know what would cause this?
<sabdfl> when I go to that URL I see the loggerhead page
<spiv> sabdfl: you're using bzr.dev
<james_w> sabdfl: I think the default is for the list software not to forward it's copy to you if you are already in the to list, but it sounds like it's all mail.
<spiv> sabdfl: the fix is on the list
<sabdfl> ok thanks spiv
<spiv> sabdfl: the bug is 207558
<spiv> ubotu: bug 207558
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
<rexbron> hmm, I can not seem to find what markup syntax bzr is using to generate the api docs
<rexbron> pydoctor's site does not really mention anything
<spiv> rexbron: epydoc
<bob2> epydoc
<spiv> (the ReST variant of it, IIRC)
<james_w> rexbron: http://epydoc.sourceforge.net/manual-epytext.html
<rexbron> james_w:
<james_w> but it uses : to start, rather than @
<rexbron> ya, I found that
<james_w> it is the rest variant it uses, but that seems to suggest other markup.
<rexbron> From a quick look, the reason some is being formatted correctly and others not is a lack of a blank line
<schierbeck> jelmer: i've made the bugs tab look good: lp:~dasch/bzr-gtk/revisionview-bugs-page
<schierbeck> what do you think?
<jelmer> schierbeck: yeah, that's definitely an improvement
<jelmer> hmm, the bug isn't clickable anymore
<schierbeck> try double-clicking
<schierbeck> i'll fit a button in there
<schierbeck> for now, i removed the status string, since "fixed" is the only one supported...
<jelmer> double-clicking doesn't work
<jelmer> schierbeck: I'd rather keep it in there and make the message say something like "This revision changes the affects one or more bugs."
<schierbeck> jelmer: the status message?
<schierbeck> i think we should only do that when bzr supports more than one type
<jelmer> yeah, or otherwise we should be making sure the status message == "fixed"
<schierbeck> i could do that
<jelmer> otherwise if bzr supports more than one type in the future, users will get very confusing errors
<schierbeck> jelmer: okay
<schierbeck> jelmer: i think the bugs tab should always be visible
<schierbeck> it's pretty confusing when ui elements magically appear on the screen
<jelmer> I'd be fine with having it insensitive
<jelmer> if there are no bugs
<jelmer> but one of the nice things now is that you don't actually have to switch to the bugs tab to see if a revision touches any bugs
<schierbeck> okay
<schierbeck> jelmer: the same thing applies for signatures
<schierbeck> but if the user is not able to open the tab, he may think that he needs to install something
<jelmer> schierbeck: Alternatively, we could show an icon in the branchview to indicate a revision touches bugs
<schierbeck> jelmer: just my thought
<schierbeck> i just need a smaller icon then
<schierbeck> currently i just copy-paste from the shared icons i've got lying around...
<schierbeck> hope i don't get in any trouble
<jelmer> schierbeck: yeah, we need to check what the license on those icons is..
<schierbeck> i'll get on it before we release, but most likely it won't be an issue
<ignas> are there any documents on how to solve permission problems with shared repositories? i have a group stbaz that can commit to the shared repository, but it seems that after bzr push'es or bzr commits from a lightweight repos using sftp
<ignas> some files get owned by my user
<ignas> both as a user and as a group
<Invisionfree> Hi, I was just wondering, does BZR work with Kerberos?
<bob2> it doesn't have specific kerberos support, afaik, but it would work with kerberised ssh
<jelmer> yeah, I used it with kerberized ssh without problems
<jelmer> kerberized ftp is not supported yet though (kerberized sftp should be fine)
<james_w> ignas: have you set g+s on the directories?
<ignas> yes, it seems so
<ignas> let me check
<schierbeck> jelmer: okay, i've pushed the changes to lp
<james_w> ignas: there's also a limitation of sftp in this area, bzr+ssh will serve you better.
<ignas> james_w: oh, i see, do i need to do something special? or just replace sftp with bzr+ssh and that's it?
<james_w> ignas: you need bzr installed on the server
<james_w> but otherwise probably not
<ignas> i see
<james_w> (the exception would be if you had bzr installed somewhere outside the $PATH on the server)
<ignas> it's in $PATH
<ignas> by the way - is there a way to get something like a lightweight checkout
<ignas> that would not need network connection
<ignas> for bzr status or bzr diff
<james_w> bzr checkout --lightweight
<ignas> i am using --lightweight
<ignas> but every operation like bzr st or bzr diff seems to be connecting to the server
<james_w> oh, not need network connection, sorry.
<bob2> that's the 'lightweight' - most stuff is on the server
<Peng> s/most/all/.
<james_w> you can use a normal, non lightweight, checkout.
<ignas> well - i want a compromise
<ignas> something that is not 70mb
<ignas> and does not need network to tell if i have changed a file
<ignas> like with svn ;)
<james_w> that puts all of the data on your local disk, but pushes it to the server when you commit, so you only need network access for write operations.
<Peng> ignas: There is nothing like that yet.
<ignas> i see
<ignas> :/
<Peng> ignas: All or nothing.
<ignas> ouch
<bob2> how far along are lifeless's shallow branches?
 * Peng points out that 70 MB isn't huge.
<james_w> bob2: quite close I think, it's just a case of making everything "stackable-on"
<james_w> the smart server for one thing I think
<bob2> ah
<bob2> hopefully 1.4 then
<jelmer> schierbeck: I think the message in the bugs tab should say "This revision fixes one or more bugs." since we're not showing the status anymore
<abentley> bob2: They aren't shallow branches.
<schierbeck> jelmer: i'm editing it as we speak :)
<bob2> abentley: oh
<abentley> They're not intended to allow you to work when the source branch is unavailable.
<bob2> ah
<schierbeck> jelmer: should we use "fixes" or "claims to fix"?
<abentley> Stacked branches are mostly a storage optimization.
<bob2> sounds about equivalent to co's bound to a shared repo?
<schierbeck> jelmer: for now i'll go with "claims to fix", as we don't really know
<abentley> Well, stacked could let you create a checkout of emacs without downloading all its revisions.  And diff/status would be zippy.  But log would not be.
<bob2> ah, of course
<jelmer> schierbeck: yeah, claims to fix sounds fine
<abentley> In a true shallow checkout, non-local revisions would be handled as ghosts, so log would be speedy but short.
<bronger> Is "bzr branch" identical to "bzr init" + "bzr pull"?
<fog> re
<TFKyle> bronger: I wouldn't think so, but I could be wrong
<gioele> hello
<bronger> The background of my question is: If I want to update a remote SVN repo, I can create a branch of it locally, merge the new changes and pull it back.  Would it be different in any way if I pulled it to an empty revisioned directory first?
<bronger> Sorry "... push it back"
<gioele> what is a "submit branch"?
<gioele> is it another name for a "push branch"?
<bronger> gioele: It may also mean a commit in the branch is bound.
<bronger> "... if the branch is bound"
<gioele> bronger: bzr info in a bound branch (a checkout) says
<gioele> Location:
<gioele>   light checkout root: .
<gioele>    checkout of branch: http://...
<gioele> is that the submit branch?
<james_w> bronger: init + pull is the same as branch, yes.
<gioele> ah, the submit branch is the location where "bzr send" sends changes
<bronger> james_w: Thank you!
<gioele> is there a revspec with the meaning "last time it was changed"?
<gioele> For example, current revision is 20 and file foo has been modified at revision 12 and 8. Is there a revspec that I can use instead of 12 and 8 in "bzr diff -r 8..12 foo"
<Peng> That would be useful, but I don't know of one.
<Peng> The docs list all the types of revspecs.
 * Peng goes back to bed.
<schierbeck> jelmer: ping
<jelmer> schierbeck: pong
<schierbeck> jelmer: do you think we should rename the "Signature" tab to "Authenticity"?
<james_w> gioele: I don't think there is one.
<schierbeck> after all, that's really all it's about
<jelmer> schierbeck: We need to verify the testament first
<jelmer> schierbeck: but otherwise, sounds fine to me
<schierbeck> jelmer: yeah, i was gonna ask that, too
<antoranz> Hi, guys!
<mw-home> morning
<antoranz> I was merging the changes from another branch yesterday (both local FS branches) and I got an error and don't know if It's a bug in bazaar
<antoranz> I had made a post in linuxquestions but nobody replyed to it, that's why I looked if there was an IRC channel... and so I'm here.
<gioele> antoranz: link?
<antoranz> the post is here: http://www.linuxquestions.org/questions/linux-software-2/problem-with-bazaar-632262/
<bob2> in future, I'd say that posting to the list is a lot more likely to find someone who knows bzr thatn linuxquestions :)
<gioele> list = mailing list on bazaar-vcs.org
<antoranz> k
<bob2> someone reported almost that exact error yesterday
<bob2> bzr in gutsy?
<antoranz> mmm........... yes, it's gutsy
<gioele> I think this deserves a bug at https://bugs.launchpad.net/bzr/+filebug
<james_w> there's already a bug for it I think
<bob2> try upgrading (add 'deb http://ppa.launchpad.net/bzr/ubuntu gutsy main' to /etc/apt/sources.list, 'sudo aptitude update', 'sudo aptitude dist-upgrade')
<james_w> I don't think it's fixed
<bob2> ah, ok
<bob2> I forget the conversation yesterday, but did -q workaround?
<antoranz> what's the problem? My use of "Ã¡" in the directory name or something?
<antoranz> cause I haven't had a problem so far with it in the branch where I created it committing to it.
<antoranz> is that repository stable?
<james_w> bob2: I think this is a different location to yesterday's
<james_w> https://bugs.edge.launchpad.net/bzr/+bug/135320
<ubotu> Launchpad bug 135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New]
<antoranz> I'll append my info to that bug.
<antoranz> The bug a little old though
<antoranz> anyway... I've already appended my trace to it.
<gioele> How do you debug bzr plugins?
<gioele> Is there a way to make the plugin hook the eric debugger at a certain point? Any other IDE is OK
<antoranz> I'll try changing the name of the directory to see what happens
<antoranz> F***! It failed when I tried to commit the mv
<antoranz> all I did was: $ bzr mv doc/Cities/BogotÃ¡/ doc/Cities/Bogota
<ignas> Peng: by the way - if 70 mb is not much, why is it taking ~30 minutes or more tu make a branch :/ how long does it take with "much" ;)
<james_w> antoranz: can you pastebin the traceback you get for that please?
<james_w> gioele: what I normally do is edit the source and add "import pdb; pdb.set_trace()" where I want it
<james_w> if the problem is a plugin not loading then ~/.bzr.log will have the error.
<antoranz> sure
<gioele> james_w: is there an API documentatio for bzrlib?
<antoranz> I'm filling for a new bug including both bugs in https://bugs.launchpad.net/bzr/+filebug. Want to see it?
<james_w> gioele: sort of yes
<antoranz> Here it is: https://bugs.launchpad.net/bzr/+bug/210838
<ubotu> Launchpad bug 210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New]
<james_w> http://starship.python.net/crew/mwh/bzrlibapi/
<antoranz> that was fast! :-D
<james_w> there's also http://bazaar-vcs.org/Integrating_with_Bazaar
<james_w> antoranz: he responds to what you say
<james_w> they'll be the new bug notification in a minute or two
<bob2> ignas: btw, cp -r is a valid way to branch a standalone branch to anothoer standalone branch
<ignas> bob2: i know, but cp -r does not work if your branch is on launchpad
<bob2> ah
<antoranz> ignas: that was good!
<ubotu> New bug: #210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New] https://launchpad.net/bugs/210838
<antoranz> I'll try the repository you provided mye with... hold on to your butts. :-)
<antoranz> hell! I tried to commit just like that and it "added" the directory (didn't move it)
<antoranz> I just checked the repository and I have 5 inconsistent parents
<antoranz> how do I get rid of those "parents"?
<schierbeck> jelmer: what do you think about a "Tags" page in the revision view? i think it would boost the discoverability.
<schierbeck> i know they belong in the branch, but to the user who wants to add a tag to a revision, it's natural to select that revision in the viz and go from there.
<jelmer> schierbeck: tags are already shown in the revisionview, in the main tab
<schierbeck> jelmer: yeah, but i'm thinking more like a treeview, where you can "rename" and add tags
<antoranz> can I delete .bzr/branch/lock so I get rid of the lock on the repository?
<schierbeck> jelmer: the current ui doesn't allow for deleting tags in the revisionview
<antoranz> I've already done it, so I think it's safe, right?
<jelmer> schierbeck: yeah, makes sense
<schierbeck> jelmer: let's get the bugs and signature page branches merged first, then i'll refactor the revision view and go from there
<abentley> antoranz: You're supposed to use the bread-lock command.
<schierbeck> jelmer: do you think there's anything missing from those two branches? i've already sent a mail to the tag icon artist
<antoranz> I've should know better, wasn0't I? after I removed the lock (by deleting, by the way :(), I was able to commit into the stable branch even with the names with non-ascii characters
<antoranz> my godness... what a gramatical mess did I write! :-D
<jelmer> schierbeck: the signatures branch disables the signature tab
<jelmer> schierbeck: but that still says "this revision has one or more signatuers"
<schierbeck> schierbeck: huh?
<jelmer> schierbeck: that's all I can think of right now
<schierbeck> jelmer: the seahorse-integration branch?
<schierbeck> i think that's the one we should ship
<antoranz> I think my repository got completely busted (both the stable and the development one... as a matter of fact, I deleted the developemt one and can't branch from the stable)
<antoranz> I just noticed I lost quite some hours of work goys
<antoranz> say-.... 2 days of work
<kohwj> hi, can i get bzr serve to prompt clients for a password?
<antoranz> there's something strange going on here.
<antoranz> I was able to commit the changes brought from the development branch in the stable branch.... I can see the diffs applied
<antoranz> however, there are not "efective" in the physical files of the stable repository
<antoranz> they, I mean
<schierbeck> jelmer: okay, i've sent in the merge requests
<schierbeck> once they're approved, i'll start refactoring the revision view
<gioele> schierbeck: olive? gtk?
<schierbeck> gioele: bzr-gtk
<schierbeck> the bottom part of the viz
<gioele> I love viz
<gioele> How do I get the arguments passed to bzr from my RevisionSpec?
<ignas> why is bzr push to a remote repository is a mega pain? and what should I do instead?
<snod> unter linux siehts auf jeden fall anders aus
<snod> fc
<ignas> i checkout the "trunk", checkout the branch, bzr merge the branch into the trunk, and am trying to bzr push the mainline back so everyone (especially our mega release tools) would see the changes...
<ignas> bzr push seems to be taking ages
<ignas> even though there was only 1 small change made to the trunk
<bob2> are they the same branch formats (should be unless you use a shared repo)
<ignas> hmm, ok it seems that it was taking so long because it was synchronizing the fact that i have enabled tags on the remote repository
<ignas> i am using a shared repository
<ignas> for my remote branch
<ignas> because all the release branches will be stored in the same location
<ignas> but yes, now that the first push got through it is bearable (takes only 10-20 seconds)
<ignas> what can I do about "Value "bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/" is masked by "bzr+ssh://bazaar.launchpad.net/%7Eignas/schooltool/lyceum/" from locations.conf"?
<ignas> and where is that locations.conf thing?
<ignas> i have tried doing "bzr push --remember bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/"
<gioele> ~/.bazaar/locations.conf
 * gioele wonders when bzr will conform to XDG Base Dir spec
<ignas> emm, why is it there? and why is it overriding parameters i am passing through command line?
<ignas> i mean - maybe there is a reason, and i am doing something wrong...
<gioele> that file is used for the parameters that you didn't specify on the cmd line
<ignas> so when i do "bzr info"
<ignas> paths are taken from that file
<ignas> not from some place in .bzr ?
<luks> ignas: old branch formats used to save it to locations.conf, new formats use .bzr/branch/branch.conf
<ignas> oh, i see
<ignas> so i should upgrade my branch and remove that file?
<luks> if it was complaining about masked location, your branch is probably already upgraded
<luks> you can just remove the branch from locations.conf
<ignas> ok
<schierbeck> jelmer: ping
<jelmer> schierbeck: hi
<schierbeck> jelmer: i've got permission to use the tag icon
<jelmer> cool
<schierbeck> can i get you to review the merge request?
<jelmer> yeah, just give me a few minutes
<schierbeck> okay
<ignas> how do i convert a branch into a checkout?
<schierbeck> ignas: bzr help bind
<ignas> schierbeck: thanks
<eddyMul> how do I "un-add" files?
<antoranz> revert
<eddyMul> antoranz: ah! thanx!
<antoranz> if you haven't commited
<eddyMul> antoranz: no, I haven't.  :)
<antoranz> there you go then.
<gioele> hello
<gioele> does the mailing list accept mails from Gmane?
<ubotu> New bug: #210938 in bzr "bzr status -v should show also non-modified files" [Undecided,New] https://launchpad.net/bugs/210938
<james_w> gioele: I don't know. The list is moderated, so it might be that.
<gioele> james_w: no, it passed fine. Maybe Gmane is a bit slow today
<james_w> ah, ok
<bialix> hi, I have question about merge.py
<bialix> abentley, may I ask you about merge.py?
<abentley> Sure.
<bialix> there is Merger, Merge3Merger and others
<bialix> it seems like Merger is main of them
<bialix> it's correct?
<abentley> Yes.  It's been suggested that Merger should be renamed to MergeController.
<bialix> so, it's always created Merger instance for merge operations?
<abentley> Yes.  It's not required, but I believe all callers do go through Merger.
<bialix> my actual question is: where I should put my code for support merge of file properties
<bialix> is it Merger correct place, or Merge3Merger?
<abentley> Probably in Merge3Merger.
<bialix> i.e. actual merge done in Merge3Merger, right?
<abentley> Yes, the actual operation is handled by Merge3Merger or a subclass.
<bialix> all other merge types is subclased Merge3 as I could see.
<abentley> Right.
<bialix> okay, thank you.
<abentley> np
<Verterok> moin
<abentley> eddyMul: More specifically, you use "bzr remove --keep --new".  That will avoid reverting any other changes.
<eddyMul> abentley: I used `bzr revert specific_files`, and it worked for me.
<eddyMul> abentley: judging from `bzr help remove`, it appears like `bzr remove --keep --new` is the like the "anti" of `bzr add`. Very handy. Thanx!
<abentley> np
<james_w> hi bialix, Verterok
<bialix> hi james_w
<james_w> bialix: sorry I haven't had a chance to look over your file properties mail yet
<bialix> it seems like nobody have this chance yet
<bialix> there was a lot of people who cry without line-endings support
<Verterok> james_w: hi
<james_w> bialix: yeah, it would be great to have.
<bialix> they already worked
<bialix> I need only to beat merge and to teach it write files to disk with proper eol
<bialix> abentley: Merge3Merger.__init__: has arguments working_tree, this_tree, base_tree, other_tree -- what's difference between working_tree and this_tree? it's not the same?
<abentley> this_tree is the input tree that you read from in order to calculate the merge.  working_tree is the output tree that you write the changes to.
<abentley> They are commonly the same, but this_tree is sometimes a RevisionTree.
<bialix> in which case?
<bialix> I see in constructor's code:         self.this_tree = working_tree
<bialix> and it seems like this_tree argument is not used actually
<bialix> so I'll ignore it.
<abentley> Don't be a jerk.
<james_w> abentley: as far as I can see the "this_tree" argument to Merge3Merger is not used in Merge3Merger.__init__, and none of the subclasses in the same file override __init__.
<db-keen> Why can't I bzr mv from one branch in a repository to another?
<james_w> so is it just there in case a subclass wants to?
<mwhudson> db-keen: because bzr is not like subversion?
<abentley> james_w: WeaveMerger used to do that, and future mergers may also do that.  It's quite likely to be a performance win.
<james_w> ah, ok, thanks
<poolie> db-keen: well it's more complicated for us than for svn
<poolie> we should make it possible
<gioele> is there a way to have "external" branches inside a branch?
<james_w> abentley: I think your reaction might have been a bit strong then, but maybe I misread it
<db-keen> I'm trying to take a project and split it into smaller branches, what's the best way to do this?
<james_w> db-keen: are you splitting on directory boundaries?
<abentley> james_w: If writes to this_tree or reads from working_tree, I'll veto his patch so fast his teeth will shake.
<db-keen> my initial reaction was to create new branches and move stuff from the old large one into these new small ones, but obviously that doesn't work
<db-keen> james_w: mostly
<james_w> db-keen: there's a split command that may help
<james_w> abentley: but the default mergers read from working_tree?
<abentley> No
<abentley> They read from this_tree
<james_w> abentley: they read from self.this_tree, which working_tree is assigned to in the constructor
<abentley> which is entirely different.
<poolie> thumper: hi, are we meeting now?
<thumper> poolie: yeah
<james_w> abentley: well, I don't still fully understand, even with the extra discussion, so I still think your response was too strong.
<abentley> james_w: think what you like.  When people ask me for advice, I expect them not to ignore it.
<dato> james_w: I guess that the API/contract is that you read from this_tree, without caring what gets assigned to it before. or so. from my limited understanding. :)
<abentley> They may decide that they don't agree, or that it doesn't apply.  But it's not okay if they just ignore it.
<james_w> I read his statement as ignoring this_tree, just like the existing code does, not ignoring your answer, but I don't know what he meant
<abentley> The existing code does not ignore this_tree.
<james_w> maybe I am wrong to say ignore, but the this_tree parameter passed to Merge3Merge.__init__ is unused as far as I can see. This may well be because working_tree fulfils the contract of this code just as well as this_tree.
<abentley> We're not talking about constructors, so when you say this_tree, I assume you mean self.this_tree
<james_w> sorry for the misunderstanding then, I tried to be clear that I was talking about this_tree passed to the constructor as opposed to self.this_tree
<abentley> So it looks like the Merge3Merge constructor is a bit broken.
<hmeland_> Regarding the "fix botched log-message" discussion: Does any of the storage mechanisms actually have an API for "turn revision X into a ghost"?
<abentley> It's probably due to the shuffling around we did to enable merge previews.
<abentley> hmeland_: No, all of our formats are append-only.
<abentley> You would need to create a new repository, and not add those revisions.
<hmeland_> Right.
<hmeland_> In principle you could repair revision X by adding a X' (which has X and the parent(s) of X as its parents) with the fix, convert X into a ghost, and repeat for all revisions that are descendants of X.
<hmeland_> But without an easy way to do the "convert X into a ghost" step, that sounds somewhat cumbersome.
<hmeland_> The approach might also have bad (performance) implications for e.g. merge, especially if such fixing were to be as common as I gather git's "commit --amend" is.
<james_w> "commit --amend" only works for the tip of the branch, and is another form of rebase.
<hmeland_> Ah, good.
<james_w> I think there are two cases being discussed, one is the "nuclear launch codes" and the "abusive commit message" case, and the other is the "spelling mistake case"
<dato> "abusive commit message"?
<james_w> the latter could be solved by just adding a note somewhere saying "when displaying it, set the message of X to Y"
<james_w> dato: it's an example from the list of where there was evidence of sexual harrasment in a commit message.
<dato> oh, wow, I missed that
<hmeland_> james_w: I think *abusive* commit message is a form of nuclear launch codes, actually.
<james_w> hmeland_: yes, it is, but I was just using the two examples from the list discussion.
<hmeland_> OTOH, an *incorrect* commit message might be solvable in the way you describe.
<james_w> for the former you need to remove X from history so that it is unreachable.
<james_w> so this could either be a rebase type operation, or introducing a ghost, both of which have their issues.
<hmeland_> Yes.  Both NLC and ACM goes in the former category, to my mind.
<hmeland_> The nice thing about the ghost-introduction solution is that other existing branches would still be related to the original branch.
<james_w> exactly
<hmeland_> You might have to take care that merges from any such branches didn't re-introduce the ghosted revisions, though.
<james_w> however, currently ghosts have no information whatsoever, not even their parents, which means that you can't get at the history previous to the ghost.
<james_w> and it would also be information disclosure, which some people in some circumstances wouldn't accept.
<hmeland_> If you branched from revision Y, which has now been converted into a ghost, there will be a new revision Y' in the source branch, whose mainline history will take you all the way back to before the fixed revisions.
<james_w> hmeland_: no, when you branch you are based of Y still
<james_w> it's not like svn where you have to make a commit to start a branch.
<james_w> but you are right, I think care would have to be taken not to get unwanted ghosts again when merging.
<hmeland_> Yes, that's what I'm saying.  In the *source* branch there will be a Y'.
<james_w> hmeland_: ah, in your proposal for creating Y' from Y, sorry
<james_w> there would be the peverse case where you made Y a plain ghost, as now you can't do 3 way merging as you can't get the text from the base revision.
<lifeless> hmeland_: the conversion of X's descendants to X''s descendants will not propogate
<hmeland_> james_w: Right, you'd have to pull before merging, I think.
<hmeland_> lifeless: In the case of multiple fixes, you mean?
<hmeland_> X' will have (X + parents(X)) as parents.  X'' will have (X' + parents(X')) as parents.
<james_w> hmeland_: you can't pull before merging, if you have diverged then pulling is not allowed.
<james_w> hi lifeless
<lifeless> hi james_w
<lifeless> hmeland_: no, I mean in the case of having more than one repository which needs the correction done
<lifeless> hmeland_: all other repositories will have the original X as their semi-ultimate descendant
<hmeland_> Not X, but the tip of the branch X was in when X was fixed, I think?
<hmeland_> But yes, ghosts do not propagate.
<schierbeck> jelmer: ping
<jelmer> schierbeck: pong
<schierbeck> I've fixed the remaining issues with the Seahorse integration branch, and I've sent in an updated merge request. Could I get you to take a look at it?
<lifeless> hmeland_: and neither does the conversion to 'fixed' revisions, only the ones actually fixed will propogate
<schierbeck> wow, apparently you can be allergic to electricity...
<schierbeck> that's pretty f****d up!
<jelmer> schierbeck: Iyou don't appear to be catching the errors if there is no seahorse interface
<schierbeck> jelmer: have you tested it? i check for the seahorse service name
<schierbeck> if seahorse is installed, the object paths and interfaces should be there
<schierbeck> it worked when i uninstalled seahorse...
<hmeland_> lifeless: Assuming a mainline-only history: If you actually fix revision 2 by introducing 2' (with 2 (now ghosted) and 1 as parents), and "fix" revision 3 by introducing 3' (with 3 (now ghosted) and 2' as parents), wouldn't a branch at e.g. 3 doing a pull cause both 2' and 3' to propagate?
<jelmer> schierbeck: ah, I missed that - sorry
<schierbeck> jelmer: :)
<jelmer> schierbeck: any chance you can make two more changes?
<jelmer> schierbeck: I'll reply to the email
<schierbeck> jelmer: which?
<schierbeck> ok
<lifeless> hmeland_: a new branch from 3' will take 3' of course. But *all* the other existing branches won't be fixed.
<james_w> I think the suggestion is to mark some ghosts as propagating, so the next merge or pull will fix them
<hmeland_> james_w: That's not what I'm suggesting; I'm just trying to understand if the algorithm I suggested above might be a viable starting point for the requested functionality.
<james_w> ah, ok, sorry
<lifeless> the general thing here is that revisions are immutable
<lifeless> having efficient, safe trustable mutable revisions is possible, buts its a lot of complexity
<lifeless> you basically need a meta-timeline for versioning revisions too
<hmeland_> If you the requires-fixing revision is present in branches you don't control, I'm leery of trying to propagate the fix to them automatically.
<hmeland_> lifeless: Yeah.  So I'm trying to see whether the "convert to ghost and add alternative timeline" approach could get us at least some of the benefits without all the complexity.
<hmeland_> Anyway, thanks for the input, I guess I'll sleep on it and see if I can come up with something.
<xma> 'lo #bzr
<lifeless> hi
<schierbeck> jelmer: okay, i've sent in yet another iteration
<schierbeck> i've also contacted the author of the bug icon
<jelmer> schierbeck: ah, thanks
<jelmer> schierbeck: (wasn't strictly necessary btw, I voted bb:tweak)
<xma> is it me or the proportion for BB to be unavailable is increasing day after day ?
<jelmer> it's been months since I've seen bundlebuggy downtime for bzr.dev
<igc> morning
<yacc> Hmmm, does anyone maintain a bzr branch of the current Python code?
<yacc> I'm not completly sure if branching the svn URL would be a very enjoyable experience.
<jelmer> yacc: it's not too bad with 0.4.9
<radix> yacc: you mean CPython? I'm pretty sure I've heard others talking about such a thing, but I'm not sure where.
<mwhudson> yacc: you mean like http://www.python.org/dev/bazaar/ ?
<yacc> jelmer: you are trying to sell me on going back to using a released version of bzr-svn ;)
<jelmer> yacc: :-)
<jelmer> yacc: If performance or reliability matters to you, you should be using a release
<jelmer> performance certainly matters for the python repo, given its size
<yacc> jelmer: does it support bzr 1.3?
<jelmer> yacc: yep
<yacc> jelmer: And I ended up using a trunk scheme, so I guess this should work too?
<bob2> yacc: http://www.python.org/dev/bazaar/
<jelmer> yacc: yep
<bob2> oh, oops, too slow
<mwhudson> bob2: well, maybe he'll tell _you_ why that isn't what he wants :)
<jelmer> bob2: what's too slow?
#bzr 2008-04-03
<poolie> igc, spiv: call now
<schierbeck> jelmer: could i get you to review the latest seahorse-integration?
<lifeless> finally
<lifeless> core vf files passing tests with finished largely gone
<poolie> wtg!
<jelmer> schierbeck: sure, one sec
<schierbeck> jelmer: okay, another iteration coming your way -- we'll land this tonight!
<jelmer> schierbeck: feel free to just merge - I voted bb:tweak
<schierbeck> okay
<jelmer> ather than bb:resubmit
<jelmer> I trust you are able to remove that one line :-)
<schierbeck> hehe :)
<schierbeck> jelmer: by the way, i've got this in the works: lp:~dasch/bzr-gtk/branchview-selected-row-color/
<jelmer> we seem to be better on track than bzr.dev this week though ;-)
<schierbeck> it adds a stroke of white around the line graph when selected
<schierbeck> jelmer: yeah, they seemed panic-stricken
<jelmer> schierbeck: any chance you can have a look at my mime patch?
<schierbeck> jelmer: sure
<schierbeck> jelmer: i've got an actual patch icon, if you'd like it
<schierbeck> tango styled and everything
<schierbeck> i see you use the bazaar icon
<jelmer> yep
<schierbeck> jelmer: i'll mail it to you
<lifeless> lunch break for me
<schierbeck> jelmer: can you receive over irc?
<schierbeck> f00k it, i'll jsut mail them
 * igc reviewing spiv's patch for #207558 now
<schierbeck> jelmer: this is also a possibility: http://tango.freedesktop.org/User:Dobey#Tango_Icon_Theme_Icons_.28CC-By-SA_2.5.29
<schierbeck> jelmer: oh, just found where i got the icons i sent you from: http://www.quantum-bits.org/?page_id=3
<jelmer> schierbeck: ah, thanks
 * igc reviewing spiv's nosmart+ decorator patch
 * schierbeck is going to bed
<igc> abentley: yes, please merge that
<abentley> Already in PQM
<igc> sorry I missed the assert issue - here's to jam's good catch on that one
<igc> great
<ubotu> New bug: #211122 in bzr "bzr help cherrypick would be useful" [Wishlist,Triaged] https://launchpad.net/bugs/211122
 * igc reviewing the arch-independent site directory patch now
<lifeless> garh test_35_wait_lock_changing
<lifeless> _so_ fragile
<poolie> lifeless: you can kill it
<poolie> i think my branch to add another exception class makes it possible to write a much cleaner test but i have not yet done so
<poolie> spiv: nosmar +1 from me too
<spiv> poolie: ok, that's enough good enough for me.  Thanks!
<poolie> this should be rarely used anyhow
<poolie> we hope
<spiv> Right.
<lifeless> I was hoping for http-bzr
<lifeless> just for cool factor
<poolie> ?
<poolie> surely that would be the opposite?
<lifeless> http minus bzr :)
<poolie> oh i see
<lifeless> standards, pfft
<poolie> presumably we should use the unicode MINUS SIGN which looks almost but not quite like a dash? :)
<lifeless> I'm so totally unsure that that would be valid in the scheme
<spiv> lifeless: it might not be valid, but "standards, pfft" ;)
<lifeless> indeed
<lifeless> though being able to type it in++
<poolie> it will avoid people using it accidentally :)
 * poolie is merging the test progress fix
<abentley> lifeless: could I get your feedback on my "Playing with Stacked Branches" post?
<poolie> yeah for some reason gmail thinks the time is 'undefined'
<poolie> i wonder if i should reboot google? :)
<matthewlmcclure> abentley: do you have a moment to discuss cygwin/symlinks (re: bug 209281)?
<ubotu> Launchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,Invalid] https://launchpad.net/bugs/209281
<abentley> matthewlmcclure: Sure.
<matthewlmcclure> i'm not sure how to proceed since several people have expressed concerns.  here are the concerns i understand:
<matthewlmcclure> (1) you'd like "nice" pathhames, e.g., 'old' and 'new'
<matthewlmcclure> (2) martin disliked forking a process to dereference the 'new' symlink
<matthewlmcclure> (3) i want a windows diff program to find the files it needs to diff; and it can't dereference directory symlinks or understand cygwin full paths
<matthewlmcclure> (4) you said you thought my original patch addressed (3) in the wrong place
<matthewlmcclure> re: (4) do you have a suggestion where is the right place?
<abentley> _try_symlink_root
<matthewlmcclure> it seems to me also that (1) and (3) are fundamentally in conflict, but maybe you have a better idea than anything i've come up with
<abentley> They aren't in conflict.  You just make a copy of the file with a nice name.
<matthewlmcclure> ah, right... i can do that; it's a reasonable compromise, but it doesn't address:
<matthewlmcclure> ( 5) i'd like the right side of the diff to be the working copy (so it can be tweaked in the diff program)
<abentley> Well, we could provide that as an optional mode, and sacrifice (1) in that case.
<abentley> But mainly, we shouldn't be creating symlinks if we don't want to use them.
<matthewlmcclure> ok... i understand now that your primary concern is not to create the symlinks if they'll only be dereferenced
<abentley> That's right.
<matthewlmcclure> so we have a choice: ( a) copy the right side files and get nice pathnames, or ( b) use the working tree directly and get editability
<matthewlmcclure> there's a precedent for ( a) on native Windows
<abentley> The dereferencing was far more involved than fixing it at the source would be.
<abentley> matthewlmcclure: Personally, I would prefer to make a) the default, and b) an optional mode.
<matthewlmcclure> ok... i'll do ( a) in one patch, and worry about  an option for ( b) separately
<abentley> Well, maybe I'm being hasty.
<abentley> You're the first person to ask for this.
<abentley> Both a) and b) are analogous to our existing Unix behavior.
<abentley> a) is the same as our windows behavior.
<lifeless> abentley: sure
<abentley> Yeah, let's do --use-real-path as a second step.  It should affect both Cygwin and Windows.
<abentley> lifeless: thanks.
<matthewlmcclure> ok, will do.
<matthewlmcclure> thanks for your time
<abentley> matthewlmcclure: no problem
<markh> noob question: Say I pull a "pristine" tree  from a public server, then pull a "working" directory from that pristine tree.  If I made a bundle from the "working" tree, the bundle references the local path to that pristine tree.  Is that a problem?  Do I need to tell 'bundle' what the real public tree is?
<markh> eg, if I want to send the bundle to the bazaar list as a merge request ;)
<abentley> didn't Google just unleash some sort of "customize your time" thing?
<Peng> They also announced their partnership with Virgin to set up a colony on Mars.
<abentley> markh: You should put the public location in the merge directive, either by specifying it, or by setting the "public_branch" config value on your local copy.
<markh> abentley: ah, config value makes sense - thanks
<abentley> np
<abentley> poolie: I've written a nanny script for Bundle Buggy to restart it if it gets a lock error.
<abentley> Obviously, this is a stopgap.
<poolie> yay
<poolie> thanks
<abentley> No problem.
<abentley> I'm going to try moving it to Postgres, which I've wanted to do anyhow.
<lifeless> so
<lifeless> sqlite does document its locking policy; like I said I think there is something crackful in the python bindings; they open new transactions implicitly AFAICT.
<abentley> lifeless: It could be.
<abentley> It could also be a hung thread, right?
<ubotu> New bug: #211139 in bzr "add reports partial success incorrectly" [Undecided,New] https://launchpad.net/bugs/211139
<lifeless> abentley: possibly; if it is a hung thread one would expect contention in posgresql too
<lifeless> abentley: I would like bb to continue to support sqlite; pgsql is a lot harder to deploy
<abentley> I don't intend to stop supporting sqlite, but I want to use postgres for myself.
<lifeless> cool
<abentley> But schema migrations are way too painful in sqlite.
<lifeless> they are ?
<abentley> Sure.  In order to add a foreign key column, you have to create a new table with the new schema, copy the data over from the original, delete the original, rename the new one into place, and re-create some indices.
<lifeless> weird; sqlite supports alter table ... add column
<abentley> lifeless: Yes, but as far as I can tell, that doesn't support foreign key relationships.
<lifeless> it supports anything create table supports
<lifeless> http://www.sqlite.org/lang_altertable.html
<abentley> I have tried it.  I couldn't get it to work.
<abentley> Note that the foreign key relationship is not specified as part of a column definition.  It's some kind of suffix on the CREATE TABLE command.
<lifeless> what syntax are you using
<abentley> It has been a while since I tried it.
<abentley> What would you suggest?  I've got an sqlite prompt open.
<abentley> Here's something that doesn't work: ALTER TABLE vote ADD COLUMN dogbert INTEGER, FOREIGN KEY(dogbert) REFERENCES tg_user;
<markh> so, while playing around locally, a couple of my local branches show "public branch" and "submit branch" values have been remembered as "related branches".  How do I remove or change them?
<lifeless> so abentley, before trying to debug it, why are you using foreign key there at all - sqlite doesn't support foreign keys last I heard it.
<lifeless> http://www.sqlite.org/omitted.html
<abentley> It certainly acts like it does,
<abentley> https://pastebin.canonical.com/3816/
<lifeless> theres nothing in there that suggests anything more than accepting the syntax
<abentley> Well, I would like to add more columns that give such an impression.
<abentley> Enforcing the constraint would be kinda nice, too.
<markh> and depending on what I try, I can manage to get my bundles showing both 'target_branch' and 'source_branch'.  Am I correct that I just want target_branch pointing at the public branch and no value for 'source_branch'?
<lifeless> http://www.justatheory.com/computers/databases/sqlite/
<lifeless> abentley: I think the add column syntax is infact invalid
<lifeless> abentley: but i'm not sure immediately how to work around that
<abentley> markh: If you are not publishing branches, you want no value for source branch.
<markh> abentley: thanks
<abentley> the submit_branch is remembered by merge and send, the public_branch is remembered by send only.
<markh> how can I "unremember"?
<abentley> There is not "unremember".  You may be better off just editing ./bzr/branch/branch.conf
<markh> it only seems to remember first time
<markh> ok
<abentley> markh: If you want it to remember when it already has a remembered value, you can supply --remember.
<markh> ah - thanks
<abentley> But by default we assume it's a temporary override.
<markh> I do remember seeing that now - my head is kinda exploding still though :)
<abentley> lifeless: The page you gave already says that columns with unique constraints and primary keys can't be added.  I think they just forgot to mention foreign keys.
<lifeless> abentley: sounds plausible
<RAOF> jml: Incidentally, hooray for bzr-svn.
<jml> oh?
<RAOF> After the initial branch, it makes working with banshee much nicer.
<jml> ahh :)
<jml> I need a new plunger :(
<spiv> jml: yours has taken it's final plunge?
<jml> I just got a mouthful of wet coffee grinds
<RAOF> Mmmm, coffee grounds!
<fullermd> Yeah, it sucks when they get soggy; all the crunch is lost.
<jml> heh heh
<Angelic13> i'm having trouble getting "bzr viz" to work on my Windows machine.  i keep getting the error "PyGTK not installed".  PyGTK *is* installed, and i'm able to run use it in a python shell.
<Angelic13> i'm also having problems installing tortoiseBZR that might be related. when i try to do so, it says it can't find bzrlib and it needs to be in PYTHONPATH. i've tried setting this to several different things and can't get it to work. should this be set to "C:\Program Files\Bazaar" or something else?
<jml> Angelic13: I'm no Windows expert, but your PYTHONPATH should be set to the directory that contains 'bzrlib'
<fullermd> Angelic13: How did you install bzr?
<Angelic13> and what does bzrlib look like in windows?
<Angelic13> i see a bzrlib in python/Lib/site-packages/bzrlib
<Angelic13> this only has a plugins directory and nothing else though, so i'm not sure if that's what it wants
<jml> *interesting*
<Angelic13> fullermd: i believe i installed it with the bzr installer.  it's been somet ime
<fullermd> I think this comes up with some regularity from using the standalone installer...
<Angelic13> c:\Progam Files\Bazaar has the program files, and it has a lib directory, but nothing called bzrlib in there
<Angelic13> i've searched through the whole system, and the only place there's a bzrlib is the directory in site-packages
<Angelic13> trying an install again with the python bzr installer
<jml> that sounds like a broken install to me.
<jml> (note: I have never used Bazaar on windows)
<fullermd> No, I think that's what you get with the standalone installer.
<jml> fullermd: really?
<bob2> is it py2exed or something?
<jml> fullermd: where does it find the libs?
<fullermd> With that, it doesn't use any external python stuff, it's all bundled up together.  And that doesn't work with external stuff like bzr-gtk etc.
<jml> ahh
<jml> so what do you do if you want to use plugins?
<Angelic13> ah this intaller put some more stuff into the bzrlib directory
 * fullermd doesn't use Windows either; just going by what he's seen here and on the list
<Angelic13> maybe that's what i needed
 * fullermd nods at Angelic13.
<Angelic13> i used bzr-setup-1.3.exe before i think
<Angelic13> i just used bzr-1.3.win32-py2.5.exe now
<Angelic13> okay yay i can import bzrlib now ^_^
<Angelic13> that must have been the problem. i didn't see any documentation anywhere saying to stay away from that particular installer though
<fullermd> Yah.  AIUI, that installs normal python stuff.
<Angelic13> ok installing tortoisebzr worked.  bzr viz still isn't working, but perhaps another reinstall of pygtk will help
<Angelic13> still can't get bzr viz to work, but tortoisebzr seems to work for now, so i guess that's good enough
<bob2> if you start a python shell, can you import bzrlib and pygtk?
<Angelic13> yes
<Angelic13> but bzr viz keeps saying PyGTK isn't installed
<Angelic13> right now i have bzr-gtk in "c:\Documents and Settings\user\Application Data\bazaar\2.0\plugins\gtk", and i *think* that's right
<spiv> Angelic13: I think that's right.  If it wasn't, you'd get a different error (bzr: ERROR: unknown command "viz")
<Angelic13> moving it to "C:\Program Files\Bazaar\plugins\gtk" doesn't seem to work
<Angelic13> that is, it isn't working in the same way
<Angelic13> also can't run scripts/olive-gtk directly :/
<kgoetz> hi all. how can i bring a branch in line with a new upstream head? i want to blow away any unknown files/changes/pending merges etc and replace it
<abentley> kgoetz: bzr revert; bzr pull --overwrite
<Angelic13> hmm seems like i had to download libglade separately and put it into my gtk directory.  that was missing from some of the docs.
<Angelic13> so now i can run olive with scripts/olive-gtk
<Angelic13> but bzr viz still doesn't work
<kgoetz> abentley: thanks.
<Angelic13> ah but olive crashes with a GtkWarning *sigh*
<bob2> bzr gtk only claims to require glade, gtk and bzr
<Angelic13> bazaar-vcs.org/bzr-gtk only says you need bazaar and pygtk though
<Angelic13> in the windows install section
<Angelic13> this is the most informative doc i've found so far http://faq.pygtk.org/index.py?req=show&file=faq21.002.htp
<abentley> poolie: The nanny just restore BB successfully for the first time.
<Peng> What breaks BB exactly?
<poolie> abentley: way to go
<spiv> abentley: great!  You may now enjoy your local timezone ;)
<spiv> igc: have a good holiday
<igc> thanks spiv
<AfC> What could one have done to do a merge, commit it - but not have the revisions consisting of the contributed patch not appear in the history?
<fullermd> cherrypick, or revert --forget-merges
<AfC> (I had to do the merge again, resolve a conflict, and then the contributor's branch showed up - but all the files were otherwise present)
<AfC> yes, it said something about cherry pick.
<AfC> What would have caused that?
<AfC> I just did the usual
<AfC> bzr merge ~/Desktop/contributed.patch
<fullermd> That being a merge directive?
<AfC> yeah
<AfC> "merge request" :)
<fullermd> Then it would come from the person making it, making it as a cherrypick.
<AfC> AH
<AfC> (really)
<AfC> (huh?)
<AfC> Wait a minute. I did the same
<AfC> bzr merge ~/Desktop/contributed.patch
<AfC> both times.
<AfC> It was only after I had committed it and run `bzr viz` that I realized something was wrong
<AfC> doing it a second time resulted in the revisions showing up.
<fullermd> I would guess you did something in between that filled in enough of the 'missing' revs that it could be applied directly.
<AfC> (I realized something was wrong when I tried to see the parents of the merge, and saw only one)
<AfC> fullermd: fair enough, but
 * AfC is horribly confused, and his confidence is shaken.
<fullermd> Well, that's why I'm here   :)
<fullermd> Remember that when you merge a MD, it's not the same as merging the branch; in the latter case, you do the merge you ask for, but in the former, you do the merge that the MD creator asked for.
<AfC> Actually, I'm 3/4 way to being serious. I did a merge, and it decided NOT to merge the revisions. This is astonishing to someone who has been, for better or for worse, been trained by Bazaar in its behaviour.
<AfC> Hm.
<fullermd> Well, if it's doing a cherrypick, it can't merge the revisions, because there's nowhere for the graph to hook up.
<igc> night all. I'm away on leave until the 14th now so happy Bazaar'ing while I'm gone. :-)
<fullermd> If you look in viz, what I suspect you'll see is that one of the revs in that merge has a parent that wasn't in your graph at the time of your previous attempt.
<AfC> This is one of the reasons the terminology behind "merge directive" has always distressed me. It's not a directive, because contributors cannot Â«tellÂ» me to do anything. It's a patch, and I am considering it for merging, or not.
<AfC> fullermd: no. It shows no parents whatsoever.
<fullermd> Urr?  An unrelated branch?
<AfC> I wish I knew what happened, so I could tell this contributor not to do whatever they did again. Better yet, I wish Bazaar wouldn't have permitted it in the first place.
<AfC> fullermd: EXACTLY
<AfC> changes got committed, but not revisions.
<AfC> I carried on as normal, no problem, la ti da
 * fullermd goes cross-eyed.
<fullermd> Start over.
<fullermd> An unrelated branch would have revisions with number like 0.1.x.
<fullermd> That's the only way (aside from the left path, of course) you ever get revs with no parents; at the start of an unrelated merge-in.
<AfC> Whatever. Grab the branch yourself and look:
<AfC> bzr viz bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/
<AfC> revno 461.1.1
<AfC> Where are the revisions of the contributed patch?
<AfC> The code delta is there, for sure.
<AfC> But I had to do the merge _again_ revno 465 to make the revisions appear.
<fullermd> It's called 461.1.1.  That means that when you did that merge, you were at rev 461.
<AfC> I would be thrilled if I could identify what I [presumably] did wrong.
<fullermd> But if you look at the revs when the merge worked, the merge revs are 463.x.x, which means those revs are children of rev 463.
<fullermd> Thus, where you did that merge the first time, you didn't have the revs in your branch, that were the parents of the revs to be merged.
<fullermd> Thus, they couldn't be attached into the tree 'normally', and become a cherrypick.
<AfC> Hm.
<fullermd> That means the cause is probably not actually the sender requesting a cherrypick in the MD creation, but rather that your branch was 'old' where you did the merge.
<AfC> Hm
<AfC> Yes, ok, I can see that.
<AfC> weird
<AfC> {shrug}
<fullermd> It speaks highly of the quality of your contributors that they keep so up to date, that _you're_ the one behind   ;)
<AfC> so what gets me is that those  revisions didn't "appear" (or whatever) when I subsequently merged it to 'mainline' at 464
<AfC> fullermd: nah, I had a 'cairo' branch lying around, and so did it there. I evidently forgot to pull from mainline first.
<AfC> Still.
<fullermd> Because it was too late at that point; when you committed 461.1.1 (or 462 as it was called on the branch when you merged it), those revs couldn't be hooked to the tree, so they weren't included.
<fullermd> So when you got around to merging it in in mainline:464, there was no longer any link to them to be reconnected.
<AfC> So I merged a second time to "fix" it, but is there something else I should have done instead?
<fullermd> Well, the 'rightest' thing would have been to stop when it told you it was cherrypicking, and figure out whether that was what should be happening.
<AfC> [this will teach me not to do integration merges on 'mainline', but anyway]
<AfC> fullermd: ah
<AfC> fullermd: interesting.
<fullermd> Once that's committed and stuck onto mainline (and you don't want to uncommit and dump that rev), there's no way to rewrite the rev to say "Oh, this was a parent of mine".
 * spiv isn't really here, but as a drive-by comment, this sounds like surprising behaviour, so probably there's a bug to be fixed somewhere.   Probably the original "bzr merge ..." should have made more fuss about the fact that the base revision referenced in the merge directive wasn't present?
<AfC> spiv: I think so
<fullermd> Well, it's tricky.  Cherrypicks can be intentional.
<AfC> spiv: I think that's where I got off track
<spiv> (and optionally, maybe, provide a way to say, "no, this isn't a cherrypick, just a ghost..."?)
<fullermd> I don't think MD's explicitly say whether they were intended to be cherrypicks.
<AfC> fullermd: put another way, I haven't knowingly done a "cherrypick" since, oh, 0.91
<AfC> Well, mostly I'm glad to hear that it wasn't Vreixo who screwed up, it was me. I can handle that.
<fullermd> Well, that goes back to the 'directive' part; when you merge a MD, the 'intention' is expressed by the person making it.
 * spiv -> really gone
<spiv> AfC: :)
<AfC> fullermd: ... which is ass-backwards for anything other than a bot receiving it.
<fullermd> Using 'send -rx..y' can express an intent to cherrypick (in the case that rev 'x' isn't in the upstream already)
<AfC> fullermd: I hadn't realized that cherry picks were that far along. I gather there is still a way to go, however.
<AfC> fullermd: (it's that whole partial implementation thing you and I were talking about, I think)
<fullermd> Well, it's where they've been since...  I dunno.  0.6 or something.
<AfC> _really_
<AfC> Hm
<fullermd> Pretty much the same place they are in everything but darcs.
<AfC> Well.
<AfC> fullermd: so that branch is now "safe", you think?
<fullermd> "bzr send -ofile -rx..y ; cd $UPSTREAM ; bzr merge file" gives the same result as "cd $UPSTREAM ; bzr merge -rx..y $OTHER"
<AfC> fullermd: yeah, ok, I can buy that
<fullermd> Oh, yes.  That -2 rev may have wacky files compared to what you wanted, but the branch is fine.
<AfC> Then "fix merge bug" is a surprisingly accurate commit message, it seems :)
<AfC> fullermd: thank you for your time.
<fullermd> Prescient   :)
<ubotu> New bug: #211209 in bzr "bzr 1.3 fails with a ValueError" [Undecided,New] https://launchpad.net/bugs/211209
<VSpike> Anyone got any ideas how I can work around this? https://bugs.launchpad.net/bzr/+bug/181855
<ubotu> Launchpad bug 181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Medium,Confirmed]
<VSpike> the annoying thing is, I'm sure this worked a couple of weeks back
<VSpike> I'm beginning to wish I hadn't chosen bzr to work with a visual studio project... there's no working VS integration yet afaik, cygwin bash + cygwin bzr has the above bug, cygwin bash + windows bzr has problems with sftp and doesn't work, and the windows command line is loathsome
<VSpike> you could argue that the mistake was using visual studio/windows rather than bzr and I probably wouldnt put up much of a fight
<VSpike> hmm the original reporter got no answers at all on the cygwin list
<muszek> hi
<muszek> http://pastebin.us/?show=m2d341b75 <-- bzr died when I tried bzr revert.  Please help, I need to revert.
<muszek> Bazaar (bzr) 1.1.0.candidate.1, Debian Sarge (package from backports.org)
<AfC> muszek: you might do well to just install Bazaar manually. 1.1.0rc1 is a bit old.
<AfC> muszek: (assuming no one has a Debian package of bzr 1.3)
<muszek> AfC: the one from hardy probably wouldn't install, right?
<AfC> muszek: you won't know until you try.
<muszek> rgr
<AfC> muszek: We don't use Ubuntu at our company, sorry.
<muszek> AfC: what do you use? (just curious, feel free to ignore me)
<AfC> muszek: we run Gentoo on our systems
<AfC> Anyway, good luck to you
 * AfC heads to bed.
<muszek> AfC: thanks, good night
<ignas> hi
<ignas> how do I find out whether remote branch format matches the local branch format?
<ignas> my commits are taking ages ...
<AfC> ignas: bzr info URL
<AfC> bzr info .
<ignas> :/ can't do that while commiting apparently
<AfC> :(
<ignas> so i'll have to look at it in 5 minutes
<ignas> and it's a 1 line change in .bzrignore :/
<AfC> ignas: for what it's worth, I'd encourage you to maintain a branch locally and work there and commit there. You can then push your changes to the remote repo separately. That should work much better for you.
<ignas> AfC: release managing requires a lot of pushing
<AfC> ... and if you have to merge, well, {shrug} you merge.
<ignas> so i actually need my changes to appear in the remote repository
<ignas> as soon as I do them
<AfC> ignas: you've got a modern 3rd generation distributed revision control system at hand. You would do well to take advantage of it.
<ignas> when developing - yes i can work on an isolated branch
<ignas> but i need to do the push after merging and it is taking way too much
<AfC> I assume you've got bzr 1.3 on both sides and that you are pushing via bzr+ssh. If not, try upgrading and changing protocols.
<ignas> hmm Repository branch (format: unnamed)
<ignas> remotely
<ignas> and Checkout (format: dirstate-tags)
<ignas> locally
<ignas> what should i do to fix that?
<ignas> and no it's not 1.3, it's the version that is available as debs for ubuntu gutsy...
<ignas> 1.0 i think
<ignas> though maybe i should switch to bzr PPA instead of using the old deb package repository
<AfC> ignas: well that's your first problem, depending on Ubuntu to give you up to date software. The hackers here maintain a "PPA" (whatever that is) which gives you more modern packages.
<luks> ignas: don't use bzr+ssh url for `bzr info`
<AfC> As for what to do, after upgrading to Bazaar >= 1.3.0, run something like `bzr upgrade` (probably `--default` on a test branch and see if that helps.
<luks> bzr+ssh hides the real format
<ignas> and what about the remote repository?
<ignas> luks: oh
<AfC> luks: how strange
<ignas> makes sense
<AfC> ignas: upgrade it too
<ignas> you can use bzr+ssh with old versions of bzr
<AfC> ignas: (again, modulo testing and backups etc)
<ignas> Repository branch (format: pack-0.92)
<luks> that's the problem then
<ignas> if i want to upgrade a repository not just the branch
<luks> upgrade your local repository
<ignas> i should run bzr upgrade in the repository
<luks> yes
<ignas> will it upgrade all the branches inside?
<luks> not sure about that
<ignas> hmm, bzr upgrade says it's the most recent format already
<luks> what version of bzr?
<ignas> 1.0
<ignas> so it seems i will have to fix apt sources :/
<luks> hm
<ignas> this makes sysadmins so much more enthusiastic about bzr ;)
<luks> what does bzr info say in the local repository?
<ignas> the remote repository
<ignas> i have a local checkout
<ignas> of a branch that is in a shared repository on a remote server
<luks> no local repository?
<luks> then you need to upgrade the checkout
<ignas> no, don't need it, i am working on a single checkout at the moment
<luks> the remote side is already using pack-092, which is the most recent format
<ignas> hmm
<ignas> i see
<ignas> bzr upgrading local one
<ignas> neat, would have never managed to find out which one
<ignas> pack-092 or dirstate-tags is more recent
<ignas> you should call the next version gruntmaster-6000 ;)
<AfC> {grin}
<ignas> yippie it's only 60 seconds not 5 minutes!
<luks> still too slow
<ignas> i know, i have a weird sense of humor ;)
<luks> I'd try to use sftp instead of bzr+ssh
<ignas> it messes up permissions on the remote repository
<luks> oh
<awilkins> Does bzr+ssh use the smart server or something faster?
<bob2> smart server
<AfC> awilkins: more or less by definition, that is the smart server.
<luks> the problem is that the smart server isn't that smart
<bob2> smarter than sftp, less smart than...a brick
<luks> with packs it usually does more requests then dump sftp
<luks> than
<bob2> or dumb http
<AfC> awilkins: (you can also get to it by running one full time, ie bzr:// )
<bob2> (for the intiial checkout, at least)
<awilkins> Oh yes, familiar with that, just wondered if bzr+ssh was the same thing
<AfC> awilkins: for some operations it is slower, but for many operations (notably, most of the uploading and data comparison cases) it is faster.
<luks> yes, it's the same procotol over a different transport layer
<ignas> bzr website sounds a lot more optimistic about these kinds of issues ;)
<awilkins> Well, I'd be optimisitic if I was so much faster than CVS and SVN :-)
<ignas> emm, difficult to do, especially when repository is 70 megs, and an svn checkout is a few hundered kilobytes and the connection is around 10 kb/s
<awilkins> ignas: Well, ok, that's less wonderful.
<awilkins> ignas: But things like grabbing a checkout of 13,000 files over a local network kick it's ass.
<ignas> emm - what about the distributed part
<ignas> like - some team members in US, some in Lithuania, and the server is in UK ;)
<awilkins> That also kicks ass.
<bob2> except for the latency!
<ignas> not when you tell them to try out a checkout from bzr ;)
<bob2> rsync ftw.
<awilkins> Although my interactions with Lithuania are limited to storing my coke-and-hookers funds
<ignas> so you are suggesting making the initial checkout using rsync and only then using bzr?
<ignas> as in - bring a checkout to sprint on a usb stick and make everyone copy it
<ignas> instead of 5 guys making a branch from the central repository
<awilkins> Because of the "distributed" thing, that works just as well as all getting grabbing a branch from central server
<awilkins> Better, if your sneakernet bandwidth is high but your network bandwidth is low
<bob2> well, not suggesting, but rsync is really quite awesome for copying data, and afaik bzr is not faster than it, yet, for the intial checkout
<ignas> just that - you can give the svn url using irc, and have them all with a check out faster than 2 guys can copy something from 1 usb stick :/
<luks> depends on how many files you have there
<luks> svn can be pretty slow on large trees
<ignas> yes, but bzr is slow on large histories
<ignas> and apparently we have a huge history with a moderate tree ...
<ignas> and it's not the network apparently
<ignas> svn checkout reaches the speed of like 50 kb/s
<TFKyle> schierbeck: hmm, looking at the new seahorse integration in bzr-gtk, wouldn't it be fine to rely on dbus's autostarting (ie. just using get_object, or calling the stuff to autostart it on org.freedesktop.DBus if that isn't compatible enough) instead of checking if it's currently running/the name is owned currently in dbus?
<ignas> bzr up - does not use the network compared to that ...
<awilkins> A use case for history horizons
<TFKyle> mm, also get an exception with current bzr-gtk trunk when seahorse is running
<ignas> an svn checkout is 2 minutes 20 seconds, bzr up with no changes is 30 seconds :/
<muszek> I've just upgraded to 1.3 and bzr still dies (I was writing ~half an hour ago about bzr revert failing).  I've also tried commiting (to see if I can revert on another machine), but it also fails.  http://pastebin.us/?show=d12b0633a
<bob2> muszek: what does 'bzr check' say?
<muszek> bob2: one sec
<TFKyle> (on bzr visualize, ah it's calling discover with an empty string)
<muszek> bob2: http://pastebin.us/?show=d2387e94d
<TFKyle> (hmm, just when bzr visualize'ing the bzr-gtk branch though)
<TFKyle> also, looks like bzr sign-my-commits was designed to give people RSI :P
<bob2> muszek: that sounds like disc corruption or bzr bug
<bob2> TFKyle: does it work with gpg-agent?
<TFKyle> probably, don't have it running atm though
<bob2> ah
<bob2> no whinging then :P
<muszek> bob2: prior to that error, I ran two scripts on the whole dir... one that changes ownership and permissions, other converts "leading spaces to tabs"... I haven't ran them in a while - possibly since I've started using bzr couple of weeks ago... and I haven't excluded .bzr from being messed by that script :/
<TFKyle> also hmm, sign-my-commits seems to be signing with my main email for the key rather than the email I used for the commits
<bob2> yaga
<andihit> when I use bzr, can I checkout only one sub-dir of my repo? when I have some dir in my repository, and on some other PC i want clone only one directory from my repo - is that possible?
<bob2> not directly
<bob2> and not like svn
<bob2> but 'bzr split' is something related (you could split to a seprate branch)
<spiv> andihit: there was talk at a recent London sprint to add a feature for that
<spiv> andihit: there's a rough plan for implementing it, but it's still some time away from being ready
<andihit> hm, I'm currently reading the "BzrVsGit"-wiki, it says 'Directories are branches. In Git they are branch containers where you switch to different views.' <-- that means, every directory is a branch. and that means, I can't checkout one specific branch?
<luks> perhaps there is a terminology confusion
<bob2> you can checkout one specific branch, but in a repository, not all directories are branches
<luks> in your previous question by 'repo' you meant an actual bzr repository, or a branch?
<TFKyle> ah, hmm
<spiv> andihit: in bzr, each branch has its own directory on disk.  That doesn't imply that each directory is a branch :)
<andihit> hm then rewrite the sentence ;)
<andihit> k thx
<ignas> hmm, bzr up from a remote branch is 30 seconds, bzr up locally takes like 1 second, downloading a file get's me 50kb/s, ssh feels sluggish, can i assume that bzr is doing a lot of connections and a lot of round trips
<ignas> thus is very sensitive to latency problems
<spiv> ignas: there's work on the smart server protocol to reduce round tips
<spiv> round trips, rather
<spiv> ignas: also, make sure your branch/repo are in pack format, not knit
<spiv> The knit format tends to require many many round trips.
<ignas> they are in pack format now
<ignas> have bzr upgraded everything on both sides
<TFKyle> schierbeck: another thing, would it be sane to just check that the key belonging to the signature is the same as one of the ones in opengpg.MatchKeys(email_address)? (or possibly comparing the fingerprints)
<schierbeck> TFKyle: i've sent in a patch already
<schierbeck> i call dbus.validate_bus_name('org.gnome.seahorse')
<TFKyle> 'k
<brokencycle> hi!
<gioele> hello
<brokencycle> i've just tried to convert a CVS repository, but now I'm stuck using the output. bzr info says "shared repository", but i'm unable to "get" or "branch" from it.
<gioele> brokencycle: a shared repo is an empty place where you can put branches
<gioele> branches are *inside* a shared repo
<gioele> (empty from a logical POW, it contains a log of small bookkeeping files from a practical POW)
<brokencycle> thank you! now i got the "right" contents, but the naming inside the shared repository is not-so-good... need to export/import into a different shared repo to fix it, right?
<gioele> brokencycle: I'm sorry but I know nothing of the current cvs-to-bzr tools :(
<brokencycle> no problem, your hint got me a big step forward already. Thank you!
<poolfool> brokencycle: which CVS to BZR tool are you using? I hope to move a CVS repo to BZR some time soon, so your input is pretty valuable to me right no.
<poolfool> brokencycle: /s/no./now./
<gioele> what is the difference between the trunk and the dev branches?
<brokencycle> well, i only found 'cvsps-import' (I only need to go one-way, so 'tailor' would be really overkill).
<gioele> (of bzr I mean)
<brokencycle> btw, the need for 'cvsps' could/should find some mentioning in the plugin's description. I only learned about it when I first tried to do the import, and failed.
<brokencycle> I'm on bzr 1.2, if that matters.
<poolfool> brokencycle: I remember someone on IRC mentioning one tool (I think tailor) working better then the other. IE. one tool was no longer in development.
<LeoNerd> CVS is an acronym. bzr isn't.
<poolfool> Yea I should get better control of that shift key, I have a bad habit of adding caps in the wrong place.
<gioele> brokencycle: what matters most is not the bzr version but the repository format version current default format is ok, older (pre 0.92 formats) are difficult to use with external tools
<brokencycle> that should not be relevant since i'm converting from CVS - so the bzr part of it should get created as recent as the "underlying" bzr allows.
<gioele> I never used tailor, but it has a very large user base, with some heavy user. I would use such a big and tested tool instead of ad-hoc smaller programs
<gioele> brokencycle: yes indeed
<brokencycle> I also never used tailor, but assumed that it has a huge list of dependencies that I don't want/need on the target machine... the 'ad-hoc progam' is, at least, created by one of the core bazaar developers, as far as I can see: http://bazaar-vcs.org/BzrPlugins (~ 2 thirds down the page).
<gioele> will running bzr.dev overwrite something on the repository where it is used?
<pmezard> brokencycle: do you need it to be incremental ?
<brokencycle> ?
<brokencycle> pmezard: do you mean, if i want to repeat the conversion process to import more and more CVS commits?
<pmezard> yes
<brokencycle> If so, the answer is no. :)
<pmezard> did you try cvs2svn ?
<brokencycle> No. Then I would also need SVN, right?
<brokencycle> And then i could import from there?
<pmezard> i think there was some work on a bzr backend
<pmezard> by reusing git fast-import format
<brokencycle> I'd like to avoid having to drag along too many other systems. In this case, I'm only versioning /etc, wanting to keep the history.
<rysiek|pl> hi guys
<rysiek|pl> this is an emergency: is there a way of UN-reverting?
<rysiek|pl> I just might have lost a few hours worth of work -_-'
<LeoNerd> Look for the FOO.~1~ files
<LeoNerd> Or ~2~ or whatever number it gave them
<rysiek|pl> phew
<LeoNerd> When you "revert", any changed files get backed up to ~somenumber~, whatever is the next free number
 * rysiek|pl stops hiperventilating and dives into the filesystem
<LeoNerd> find . -name '*.~1~'
<rysiek|pl> yeah, just done that ;)
<brokencycle> @poolfool: thanks  - I didn't check the development status of the plugin... but even then, maybe I've already "fixed" it, by editing something in the guts of .bzr. Will keep an eye on it.
<rysiek|pl> wtf... there were some pending local commits... and seems like THOSE changes were lost
<rysiek|pl> shit. they ARE lost!
<poolfool> brokencycle: Yea ... I did a little looking at taylor vs cvsps and I think I want cvsps to bring over all of my history including branches ... talor looks to just do the root (head?) branch as a patch set.
<rysiek|pl> why the heck does bzr backup the uncommited files, but CLEANS the locally-commited changes?
<rysiek|pl> or am I missing something again
<gioele> rysiek|pl: what kind of working tree is that? checkout? branch?
<rysiek|pl> checkout
<gioele> bound or unbound?
<rysiek|pl> bound
<brokencycle> I just found out that I probably don't want to use tailor because there's no port of it to OpenBSD. For cvsps, there is... simplifies things quite a bit (probably).
<rysiek|pl> (i think)
<rysiek|pl> gioele: checkout of branch: sftp://mike@(...)
<rysiek|pl> I am reading the manpages but cannot find the info is there a way to get my locally commited changes back
<rysiek|pl> why on earth does revert destroy locally COMMITED(!) changes by *default*?..
<gioele> because revert thinks that you want to revert to what is consider the base: the remote branch you're bound to
<rysiek|pl> ok, but it keeps backups of the changed files. neat.
<rysiek|pl> but WHY OH WHY doesn't it keep some kind of backups of locally commited changes?
<rysiek|pl> one would think that locally commited changes - simply because they *are commited* - should be considered more... hmm... permament?
<gioele> they are
<rysiek|pl> ?
<gioele> but revert is more "going back to revision X, pass over everything"
<jelmer> rysiek|pl: revert does not destroy committed changes
<gioele> still it should backup everything it throws away, committed or not
<rysiek|pl> jelmer: those were locally-committed changes
<jelmer> only uncommitted changes
<jelmer> rysiek|pl: what was the exact command you were running?
<rysiek|pl> jelmer: well, the situation here is: I had two revisions committed locally; I made some additional changes and was ready to commit to the master branch
<rysiek|pl> jelmer: bzr ci ...  -> woosh, some conflicts emerged
<rysiek|pl> jelmer: I hadn't had time to resolve those, so I thought I simply revert (to the last LOCALLY committed revision)
<rysiek|pl> jelmer: bzr rever
<jelmer> rysiek|pl: that is the latest local revision at that point
<jelmer> rysiek|pl: I think "bzr update" is not doing what you expect it to
<rysiek|pl> jelmer: woosh - my changes from the two locally-committed revisions are gone, and I only have backups of the latest, uncommitted changes
<jelmer> rysiek|pl: it updates the local branch tip to the master branch tip and adds the extra local revisions as pending merges
<rysiek|pl> jelmer: yeah, I know that
<rysiek|pl> jelmer: so? I lost my locally-committed revisions because they became pending merges?
<rysiek|pl> jelmer: after an update, that is?
<jelmer> rysiek|pl: yes, because revert throws away pending merges
<rysiek|pl> so they are completely gone, are they
<rysiek|pl> *aren't
<jelmer> no, they're still hidden in the repository
<jelmer> the heads plugin may be able to retrieve them
<rysiek|pl> this is the point where you can save a man's life
<rysiek|pl> 'kay, on it
<rysiek|pl> anybody knows if the heads plugin is packages somewhere (bzrtools?) for ubuntu gusty
<jelmer> it's not packaged
<rysiek|pl> ok
<gioele> rysiek|pl: it is easy to install "mkdir ~/.bazaar/plugins; bzr co --lightweight where-is-heads ~/.bazaar/plugins/heads"
<poolfool> jelmer: Um for the cheap seats here ... if I 1) checkout from somewhere sftp://fool@... (call it r1) , 2) make some changes and commit changes #bzr commit (call it r1.1) , 3) make some more changes but 4) accidentaly do a revert  #bzr revert my local copy will be back to r1 ... is that what happened to rysiek|pl ?
<rysiek|pl> poolfool: 1. r1.1 is a local commit
<jelmer> poolfool: no
<rysiek|pl> poolfool: plus there is a 3.5 step
<rysiek|pl> poolfool: 3.5) bzr update
<jelmer> poolfool: this can only happen to you if you use "bzr commit --local"
<poolfool> jelmar: while 'bound' to the remote repo?
<jelmer> poolfool: yes
<gioele> mind if I file a bug about this?
<jelmer> gioele: about what exactly?
<poolfool> So is it step 3.5 #bzr update , that was the problem command? Now the 'local commits' are pending in limbo, yet the 'heads' plugin may save the day?
<gioele> jelmer: local commits thrown away without a backup when update/revert is used
<rysiek|pl> jelmer: about not asking the user "man, you ARE going to lose those pending merges: ..."
<jelmer> gioele: what would the bug be exactly? revert throws away pending merges? update adds local commits as pending merges?
<rysiek|pl> just asking would suffice, as that would be the point were I would jump, hit n, Ctrl+C and/or the master power switch
<rysiek|pl> gioele, jelmer: maybe a feature request
<gioele> jelmer: the problem is that revert is *deleting* stuff without telling the user about that and without saving what it is tossing away
<jelmer> gioele: revert throwing away pending merges makes a lot of sense in 90% of other situations
<rysiek|pl> gioele, jelmer: "during revert, if there are any pending merges, ask the user if he knows those pendng merges will be deleted"
<gioele> jelmer: better safe than sorry
<jelmer> rysiek|pl: For unbound branches throwing away pending merges without asking does make sense
<rysiek|pl> and there can always be a config option"do not ask about blah blah"
<gioele> revert has backups, what is wrong with extending them to pending merges?
<rysiek|pl> jelmer: I am not saying it doesn't
<jelmer> rysiek|pl: It would be really annoying if "bzr revert" started asking about throwing away pending merges
<rysiek|pl> jelmer: I am only saying that it might save some people some loose hairs and stress
<jelmer> rysiek|pl: I understand the problem but I think the problem is with update rather than revert
<rysiek|pl> well then, update saying "local commits are now pending merges, watch with that revert, mind you"
<gioele> jelmer: what is the problem with throwing away pending merges *and* doing backups?
<rysiek|pl> are there any docs for heads?
<jelmer> gioele: backups are already done
<rysiek|pl> jelmer: where ;)
<rysiek|pl> bzr heads shows nothing
<rysiek|pl> ok, --all
<rysiek|pl> jelmer: I only have ONE out of TWO local commits
<rysiek|pl> and have no idea whatsoever how to get it re-merged
<jelmer> rysiek|pl: bzr merge -rrevid:<revid>
<jelmer> where <revid> should be printed by "bzr heads"
<jelmer> rysiek|pl: heads only prints the latest commit
<rysiek|pl> ok, thanks
<rysiek|pl> jelmer: so the pre-last is lost? or by reverting (meh...)  to the one I get the pre-last, too?
<jelmer> rysiek|pl: by merging the latest you get the latest-1 as well
<fullermd> No, heads only shows the heads.  The prior one isn't a head, it's an ancestor of that one.
<rysiek|pl> ah, right
<rysiek|pl> fingers crossed
<johnny> so what's the recommended bzr web frontend these days?
<rysiek|pl> bzr: ERROR: No location specified or remembered
<rysiek|pl> bzr merge ... ./ or bzr remerge ?
<jelmer> rysiek|pl: try .
<gioele> johnny: http://www.lag.net/loggerhead/
<rysiek|pl> ok, done.
<johnny> that is the recommended one? i see bzr-webserver being updated more recently
<johnny> i like the ui of loggerhead, but the fact that i can't figure out how to not making it run as it's own user is weird
<johnny> and not as root that is :)
<rysiek|pl> worked!
<rysiek|pl> jelmer, gioele: thanks a lot! I could have been banging my head against the wall on this for the next 3hrs, and then probably having to re-write it from scratch
<jelmer> rysiek|pl: ah, cool
<jelmer> rysiek|pl: one thing that would perhaps help is if "bzr revert" could tell you the command to apply the pending merges again
<rysiek|pl> yup
<rysiek|pl> jelmer: in fact, anything that would *hint* on the fact that you might lose (well, almost ;) ) your local commits would suffice
<muszek> I have my local repo binded to a repo on an external server.  is there some neat command to update a remote working tree when I commit?
<rysiek|pl> jelmer: problem is with the obscurity of the problem - "local commits" becoming "pending merges"
<jelmer> rysiek|pl: update already does
<jelmer> rysiek|pl: at the point your commits become pending merges they're no longer local commits
<jelmer> muszek: try the push-on-update plugin
<rysiek|pl> ok, so I am the fool. whatever, I am just happy to have my changes back
<muszek> jelmer: ty
<jelmer> rysiek|pl: right, that's why I mentioned this is actually a problem of update
<ubotu> New bug: #211412 in bzr "bzr should never throw away changes without making backups" [Undecided,New] https://launchpad.net/bugs/211412
<rysiek|pl> methinks that's a wee bit too broad, will get rejected :/
<jelmer> gioele: what would you like bzr to do on revert then though? SHould it write a bundle filewith the pending merges in it?
<rysiek|pl> ok, just need to make sure:
<rysiek|pl> I have those local commits in again, and some new changes
<gioele> jelmer: that would be cool
<rysiek|pl> I want to commit all to master branch - bzr commit should do the trick, right?
<gioele> jelmer: but a simple cp of all the changed file is enough
<jelmer> gioele: that's going to kill performance though
<jelmer> gioele: all changed files are already backed up
<gioele> jelmer: --no-backups then
<johnny> gioele, have you set up loggerhead?
<gioele> jelmer: As a user I would never trade safety for performance
<gioele> johnny: no
<gioele> jelmer: if you fear performance issues, then make a non default --slow-but-safe global option for bzr, I'll enable it
<jelmer> gioele: that's simply deferring the decision of what to do to the user
<jelmer> gioele: and will still get it wrong in a lot of cases
<jelmer> gioele: my point also was that it's update that's throwing things away
<jelmer> since it's removing local commits
<rysiek|pl> jelmer: humm... bzr help commit yields this at the end
<rysiek|pl> jelmer: (As a general  rule, when in doubt, Bazaar has a policy of Doing the Safe Thing.)
<rysiek|pl> jelmer: The Safe thing here would be AT LEAST asking the user
<rysiek|pl> jelmer: it doesn't hurt much to hit 'y' from time to time, but it saves time (lives? ;) )
<jelmer> rysiek|pl: that's true for update, not for revert
<rysiek|pl> jelmer: whatever! I don't really care if it's in revert or update
<jelmer> rysiek|pl: also, bzr doesn't have interactive stuff on purpose
<rysiek|pl> jelmer: I do care, however, that it's *somewhere*, as if I would get such info from update OR revert I would stop
<gioele> jelmer: I agree with rysiek|pl: I don't care. I want my data back ;)
<gioele> how many ppl are going to came here asking for what rysiek|pl asked?
<jelmer> gioele: that's why I suggested "bzr revert" should tell you the merge command to readd those pending merges
<rysiek|pl> jelmer: and that would be just ideal, IMHO
<gioele> jelmer: but then, as you said, that would be interactive and not needed in 90% of the cases
<johnny> so... loggerhead anybody?
<gioele> I think that silently doing the backups is the safest way
<jelmer> gioele: no, it's simply an extra line of output from revert
<gioele> jelmer: and it will not be read
<rysiek|pl> gioele: it will
<rysiek|pl> gioele: after I run the command, I read the output
<rysiek|pl> gioele: ESPECIALLY when I have lost something
<gioele> rysiek|pl: no you don't
<gioele> you read messages *after* you've lost something
<gioele> the line appears *before*
<rysiek|pl> gioele: thing is: it is *not* lost
<gioele> wait, I got lost
<rysiek|pl> gioele: I just needed some third-party plugin to tell me the exact revid of the "lost" commits
<rysiek|pl> gioele: thing is:
<rysiek|pl> gioele: 1. bzr ci --local once or twice
<rysiek|pl> gioele: 2. /code code code/
<rysiek|pl> gioele: 3. bzr up /local commits become pending merges here/
<gioele> ok, I got it
<rysiek|pl> gioele: 4. oops, a conflict - revert /pending merges are "lost", but the changes are kept.. well, somewhere ;) /
<gioele> rysiek|pl: an hell from an help-line pow ;)
<rysiek|pl> gioele: now, if revert had just told me: those pending merges were "lost", you can re-merge them with bzr merge -revid:<blah>
<rysiek|pl> gioele: I wouldn't even come here :)
<rysiek|pl> so technically, the changes aren't lost, I just did not know how to get them back - and I needed a third-party plugin to get on this
<rysiek|pl> plus info on how to use it. that's exactly what printing "you can re-merge blah blah" would give me :)
 * rysiek|pl EOF
<gioele> as long as the change are store somewhere, and accessing them does not require an external plugin (the revid can be outputted by revert itself I think), that is a perfect solution
<rysiek|pl> yup
 * rysiek|pl had a deja-vu - something has changed in the Matrix, I guess
<ubotu> New bug: #211434 in bzr "revert should tell the user what pending merges were thrown away" [Undecided,New] https://launchpad.net/bugs/211434
<mathiaz> Hi - I'd like to be able to create (and then send) an email containing the diff and the log message for a specific revision in a bzr branch. Is there a command/plugin that does this ?
<johnny> thereis an email plugin on the site
<johnny> in the plugin section
<poolfool> johnny: Were you asking about loggerhead vs bzr-web?
<johnny> vs bzr-webserve
<johnny> ist here just bzr-web?
<mathiaz> johnny: thanks.
<poolfool> Johnny: Sorry 'web-serve' ... I use 'web-serve' for personal use, very low traffic, but a great tool to graphicly check some things.
<poolfool> johnny: I am pretty sure launchpad(sp) is using loggerhead.
<johnny> poolfool, have you setup loggerhead yourself?
<poolfool> johnny: sorry no ... loggerhead is a little to complex for me. web-serve gives me the features I need.
<johnny> loggerhead runs fine for me.. i just want it to run under my webserver
<johnny> instead of as it's own user :(
<johnny> a web thing that doesn't do any file system writing. should be able to run like every other webapp i have
<poolfool> Um ... how do you start loggerhead?
<johnny>  ./start-loggerhead :)
<johnny> but that's not the way i want to run it
<johnny> but it does work
<poolfool> so ... start-loggerhead is a perl script?
<johnny> python
<johnny> why would it be perl? turbogears is in python
<poolfool> sorry python ....
<poolfool> Maybe you can tell what I am trying to debug in the background?
<mxpxpod> I ran into this problem when checking out an svn repo: https://bugs.launchpad.net/bzr-svn/+bug/206728
<ubotu> Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix committed]
<mxpxpod> but when I grab the 0.4 branch of bzr-svn, I can't use it with 1.3
<mxpxpod> does anyone know the relevant change to fix bzr-svn for 1.3?
<johnny> ?
<johnny> err poolfool ?
<poolfool> johnny: I am working on some perl in the background ... work.
<poolfool> johnny: Ok, probably not a good answer, but http://docs.turbogears.org/1.0/mod_python
<poolfool> Johnny: Use Mod_perl with apache to run loggerhead ?
<johnny> i don't use apache
<johnny> fastcgi is prolly the method i'll go with
<johnny> i found docs for it
<johnny> but they don't make sense without understanding turbogears
<johnny> maybe the people in #turbogears will be more helpful this time
<poolfool> Johnny: So you are actually looking to better understand turbo gears so you can change the UID of the process running loggerhead?
<johnny> but it seems that channel is more for people developing turbogears apps, not helping people deploy random turbogears apps
<poolfool> Johnny : Check out this link http://irclogs.ubuntu.com/2008/02/09/%23bzr.html ... I think you may want to watch for 'mwh'
<poolfool> johnny: Are you trying to run your loggerhead on a low port? Something under 256?
<schierbeck> jelmer: ping
<jelmer> schierbeck: pong
<schierbeck> jelmer: okay, it looks like we have two options regarding seahorse
<schierbeck> 1) call DiscoverKeys() before trying to get any info -- unknown keys will then appear in the local database, but marked as missing
<schierbeck> 2) call ListKeys() to get a copy of the local key database and check it ourselves -- this could be bad for memory consumption, however
<schierbeck> hmm, wait a minute -- i think i have a better solution
<schierbeck> give me 5
<mxpxpod> jelmer: perhaps you can help me with https://bugs.launchpad.net/bzr-svn/+bug/206728
<ubotu> Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix committed]
<mxpxpod> jelmer: where in the 0.4 branch was that fix committed?
<jelmer> mxpxpod: the best way to find it is to run "bzr annotate" on the news file and see when the line that announces that bug has been fixed was last changed
<mxpxpod> jelmer: ah, thanks
<jelmer> mxpxpod: rev 1031 apparently
<jelmer> schierbeck: looks like a "Find when bug X was fixed" item in viz cuold also be useful :-)
<schierbeck> jelmer: yup. submit a bug for it?
<jelmer> no gpg here :-( I'll try to remember to file one later today
<schierbeck> jelmer: i think i've finally cracked the key availability issue
<gioele> wow, bundle buggy is cool
<jelmer> schierbeck: cool, how?
<schierbeck> jelmer: i use MatchKeys()
<schierbeck> first i was a bit afraid, because the docs said it could take a while to return, but that's apparently not true if i give a complete key id
<jelmer> schierbeck: what is "pattern" exactly?
<schierbeck> jelmer: not sure
<schierbeck> i'll ask
<jelmer> the fact it fetches remote keys also worries me a bit though if it doesn't yet, I guess we're fine for now
<schierbeck> jelmer: it only searches the local database
<jelmer> schierbeck: I would actually expect seahorse to handle optional fetching of the keys itself
<jelmer> when you call GetKeyField()
<schierbeck> yeah, but apparently it doesn't
<johnny> poolie,  i was trying not to run it on a port at all, just be picked up by the webserver
<mxpxpod> jelmer: thanks, that worked
<schierbeck> jelmer: okay, i've sent in a revised patch
<schierbeck> this one really simplifies things
 * Peng kicks the PPA.
<Peng> Has everything in the PPA ever been compatible?
<jelmer> I think bzrtools is not compatible with the rest or something atm
<jelmer> Odd_Bloke: ping
<Peng> bzr-svn for Gutsy is only 0.4.6.
<Peng> bzrtools WFM.
<jelmer> Peng: oh, right. I stopped uploading bzr-svn to the other distros because of .orig.tar.gz checksums mismatching
<Peng> Huh.
<jelmer> bzr builddeb generates tarballs with different timestamps for the files
<jelmer> that causes different checksums on the tarball
<jelmer> and ppa refuses uploads of the same filename with different checksums
<jelmer> that means I can only upload once (to hardy), other uploads are refused
<jelmer> schierbeck: what does pattern match on?
<jelmer> schierbeck: only on key ids or on names as well?
<ubotu> New bug: #211523 in bzr "lack of repository upload progress indication" [Undecided,New] https://launchpad.net/bugs/211523
<wardi_> question for a windows user: is tortoisebzr ready for non-developers?
<jelmer> wardi_: not really at this point
<wardi_> bummer, I really don't want to tell her to use svn
<jelmer> beuno: ping
<schierbeck> jelmer: key ids and emails
<schierbeck> jelmer: i'm not sure of the efficiency, but at least we'll only call it once per key
<schierbeck> jelmer: i guess we could devise a solution where we could match a whole batch of id's, if that's more efficient
<wardi_> (again for a windows user):  Is Olive a usable alternative to tortoisebzr?  I think she's coming from wincvs or somesuch
<schierbeck> but that would require us to call it asynchronous, which raises other issues
<beuno> jelmer, pong
<mlh> wardi_: someone on the mailing list recommended qbzr
<mlh> as being the most mature/easy to use/complete (<-- one or more of those; I forget which)
<jelmer> beuno: any news on the nautilus disable patch?
<beuno> jelmer, I'm a bit stuck on where to implement the global disable
<jelmer> beuno: Would it be ok with you if I made those two small additions and sent it in?
<beuno> jelmer, sure, go ahead, although I've got the per-branch bit thing down, just haven't figured out where to move the global disable in the UI
<jelmer> beuno: ah, ok
<jelmer> beuno: I wasn't sure where to put that either yet
<jelmer> beuno: There's no way to add items to the Nautilus Preferences dialog as far as I can see
<beuno> jelmer, that's my problem  :)
<beuno> we can not have it for now if you want, and I'll send the patch in a while
<jelmer> beuno: Yeah, that would be nice; at least it's an improvement over the current situation.
<beuno> jelmer, sure, I'll send the patch in a few hours if that's ok. On the other hand, if you're in a hurry, go ahead and do it yourself
<jelmer> beuno: I'm not in that much of a hurry :-)
<jelmer> thanks for looking into this stuff
<jelmer> schierbeck, phanatic: I'd like to do a release this weekend
<beuno> jelmer, my pleasure!  I'm happy to be helping out
<jelmer> would that be ok with you, or do you think there's other pending stuff that needs to be fixed?
<schierbeck> jelmer: i'd like to land my bug page fixes, and do a cleanup of the revision view
<schierbeck> but if there's not time for it, that's okay
<jelmer> schierbeck: I think it's possible to get your bug page fixes in before then
<jelmer> schierbeck: what exactly would you like to fix in the revisionview?
<schierbeck> jelmer: i'd like to pull each page into its own FooPage class and use proper signalling to update them
<schierbeck> and i'd like to use symbolic names for the pages, like GENERAL_PAGE, SIGNATURE_PAGE etc.
<phanatic> jelmer: i'm fine with a release. do you want to do it?
<rysiek|pl> gtg, cu all
<rysiek|pl> jelmer: thanks for your help
<jelmer> schierbeck: symbolic names where exactly?
<jelmer> phanatic: Sure, it's been a while but I'll happily let somebody else do it if they're interested :-)
<schierbeck> jelmer: just use constants that map a symbolic page name to an integer denoting that page's position in the notebook
<schierbeck> jelmer, phanatic: i think we should also have gannotate use the general page only, instead of the entire notebook
<schierbeck> jelmer, phanatic: by the way, i just sent in a crash-fix
<phanatic> i'll try to catch up with all patches tomorrow (at least i hope so). i was just following the mailing list, but haven't tried the new features yet...
<beuno> vila, ping
<beuno> bzr: ERROR: No such file: '/home/beuno/public_html/test_upload/.bzr-upload.revid': [Errno 2] No such file
<beuno> is that an expected failure?
<jelmer> schierbeck: hmm, seahorse slows viz down really really badly here
<jelmer> schierbeck: it takes >2 seconds to select a revision if the signature is from a missing key
<jelmer> schierbeck: trusted keys seem to work better
<schierbeck> jelmer: i'll have a look
<schierbeck> jelmer: it's pretty fast here
<beuno> vila, got it, needed to use --full for the first time.  You rock!  I'm going to polish a few bits of it now, and start using it internally  :)   We might be almost ready to release a beta
<schierbeck> jelmer: that must be MatchKeys() then
<jelmer> schierbeck: How many keys do you have in your local seahorse database?
<schierbeck> but it should only happen once for a key
<schierbeck> only 66... guess that's why
<jelmer> ah
<jelmer> I've got >2000
<schierbeck> hmm
<schierbeck> jelmer: still, it will only happen once for a key. after the release we should work towards an asynchronous solution
<lifeless> spiv: ping
<jelmer> schierbeck: it really makes viz unusable for me
<schierbeck> jelmer: should i add a "Disable signature checking" option in the menubar?
<jelmer> schierbeck: I'd rather avoid that sort of workaround but get the code right in the first place
<jelmer> schierbeck: would it be possible to only determine the signature when the signature tab is viewed, for example?
<schierbeck> yeah, it would
<schierbeck> i did that for the changes page
<schierbeck> let me have a look
<jelmer> that would help things a lot
<jelmer> schierbeck: also, do we validate the testament yet?
<schierbeck> jelmer: nope, we need to do that
<schierbeck> i'm not sure what will be sufficient
<beuno> jelmer, finishing something with the upload plugin, and I'll review my changes and send 'em over
<schierbeck> jelmer: i'll add the symbolic page names -- comparing with integers is really ugly
<jelmer> beuno: cool, thanks
<schierbeck> jelmer: i'm having some smtp trouble
<schierbeck> there
<schierbeck> think evolution just f00ked up
<schierbeck> jelmer: okay, it's sent
<schierbeck> along with a crash fix
<lifeless> yay all tests pass
<Kinnison> s'always good
 * Kinnison pats lifeless on the head
<Kinnison> lifeless: Do you have any recommendations for C based test suite managers? I've been using 'check' but it's a bit clunky
<lifeless> well
<lifeless> check with my subunit patch is kinda nice
<lifeless> the gnome one doesn't seem any better or worse to me as a programmer, but its less mature and has less features
<schierbeck> Kinnison: i've heard good things about the new gtester, but that's part of glib
<schierbeck> at least as far as i know
<lifeless> schierbeck: isn't that the gnome one I was referring to ?
<Kinnison> lifeless: subunit patch?
<schierbeck> lifeless: probably, not sure if they have an older framework
<Kinnison> schierbeck: I've only had issues with that and vala (well, libgee really)
<poolie> hello Kinnison
<lifeless> Kinnison: there is a patch for check in subunit
<poolie> lifeless, spiv: call scheduled for 5m
<poolie> as there is only spiv and me i propose to call you directoly
<poolie> unless robert wants to come
<spiv> poolie: sounds good to me
<lifeless> I want to talk with spiv
#bzr 2008-04-04
<poolie> together or separately?
<lifeless> about the 1.3 regression
<lifeless> https://bugs.edge.launchpad.net/ubuntu/hardy/+source/bzr/+bug/208418/
<ubotu> Launchpad bug 208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Critical,Confirmed]
<poolie> yes me too
<poolie> call the meeting room then
 * spiv dials in
<beuno> vila, uploaded a few changes, hope they're fine with you  :)
<lifeless> x`whats the page again
<lifeless> got it
<spiv> lifeless, poolie: http://people.ubuntu.com/~andrew/bzr-dbus-knit.tar.gz
<spiv> "bzr pull bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr-dbus/trunk/" in that
<jelmer> woot, finally got bzr to authenticate over ftp using Kerberos \o/
<spiv> "13.743  incompatible format signature inserting to KnitVersionedFile(file:///home/andrew/code/bzr-dbus.knit-1/.bzr/repository/knits/b7/test_hook.py-20070206032
<spiv> 729-2b5teqiwctqrfgei-8)"
<spiv> that looks suspicious
<spiv> From the -Dhpss output, there's only two chunks been read.
<spiv> So it's seeing an incompatible format chunk, and translating that, then falling over.
<spiv> And it happens on the first knit record.  (The first chunk read is an overall format header, IIRC).
<beuno> jelmer, around?
<beuno> jelmer, it seems to use Branch.get_config(), I need to pass a branch to it, so I have to check each time if there is branch or not. Won't that be a bit of a performance git?
<beuno> s/git/hit
<lifeless> spiv: so, my bet is spot on ;)
<jelmer> beuno: I think it's pretty quick if bzrlib is already loaded
<jelmer> beuno: To be sure it may be useful to bypass that stuff if GlobalConfig() has nautilus integration disabled
<spiv> lifeless: what do you make of http://rafb.net/p/b2vAx192.html
<spiv> lifeless: it looks like maybe fulltext records are missing the int,int,int header?
<poolie> jelmer: nice
<poolie> re kerberos
<beuno> jelmer, let me give it a try...
<poolie> spiv: well, itym the deltas?
<poolie> the deltas look like fulltexts?
<spiv> poolie: each component should be (component_id, record, record_details, digest)
<spiv> Hmm, well.
<spiv> the first component has ('line-delta', False), but also has the int,int,int header line.
<spiv> The final component has ('fulltext', False),
<spiv> It seems to be iterating the components in reverse order.  And the second last one has 'line-delta', but is a fulltext.
<spiv> So I guess that's why it's blowing up.
<poolie> spiv: what routine did this come from?
<spiv> It builds that components list using KnitVersionedFile._get_record_map
<spiv> bzrlib.knit:KnitVersionedFile._get_content_maps
<poolie> it looks to me like the secondone is also a delta but does not have int,int,int headers?
<spiv> Right, but it hasn't got that far.
<spiv> Because it's already blown up :)
<lifeless> spiv: the '88,89,1\n',
<lifeless> spiv: is the delta length header
<lifeless> spiv: fulltexts are not meand to have one
<poolie> lifeless: so the first delta looks ok, but the others are not
<poolie> spiv: what method is iterating the components in reverse order?
<poolie> oh
 * poolie reads the backtrace
<spiv> poolie: KnitVersionedFile._get_content_maps is
<poolie> riht
<lifeless> so lower_fulltext doesn't have a int int int prefix
<lifeless> spiv: line 123 is the bug
<lifeless> spiv: it claims 'line-delta' but it has a fulltext
<lifeless> spiv: as you say above :>
<poolie> of which file?
<lifeless> spiv: so you need to look at what created the content maps
<poolie> or of the pastebin
<lifeless> poolie: of the pastebin
<poolie> right
<poolie> i was really impressed for a second there :)
<spiv> lifeless: right, and ditto line 239
<spiv> self._index.get_build_details(['robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d']) claims line-delta
<spiv> (ditto for the other fulltext record)
<poolie> spiv: could you pastebin the -Dhpss output if you have it?
<spiv> Which asks the backing index for the _StreamIndex
<spiv> poolie: coming up
<lifeless> spiv: what is self._index?
<spiv> poolie: http://rafb.net/p/vLuSj352.html
<schierbeck> jelmer: ping
<spiv> lifeless: <bzrlib.knit._StreamIndex object at 0x88db2ec>
<spiv> lifeless: with a .backing_index of _KnitIndex(b7/test_hook.py-20070206032729-2b5teqiwctqrfgei-8.kndx)
<lifeless> k
<lifeless> the backing index is in the target repository is it not?
<spiv> Which has 'line-delta' in its self._cache
 * poolie looks at diff from 1.2 to 1.3 in knit.py
<spiv> lifeless: the one I'm pulling into, yes
<spiv> lifeless: the remote branch is in pack format
<lifeless> spiv: is 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d' in the local knitindex?
<spiv> lifeless: yes: http://rafb.net/p/nfa8B131.html
<spiv> lifeless: and, curiously, it's a line-delta in the test_hook .kndx file.
<lifeless> spiv: well 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d' in self._index.backing_index.versions() is easier :)
<spiv> So, the kndx says line-delta.
<spiv> But the component the code was dealing with in _get_content_maps looked like a fulltext.
<lifeless> so, how did the component get there :P
<spiv> Gar, pdb bugs.
<spiv> --Call--
<spiv> /usr/lib/python2.5/bdb.py:318: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
<spiv>   i = max(0, len(stack) - 1)
<spiv> LEAVING RECURSIVE DEBUGGER
<spiv> Oh, right, because I tried to step into a generator.
<spiv> I've seen that pdb bug before.
 * spiv puts a breakpoint somewhere else
<poolie> i'm going to try just getting the data stream for this file across hpss
<spiv> Ok, I think I see part of the problem:
<spiv> (Pdb) pp self._access.backing_knit.get_lines('robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d')[0]
<spiv> '# bzr-dbus: dbus support for bzr/bzrlib.\n'
<spiv> (Pdb) pp self._access.backing_knit._index.get_options('robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d')
<spiv> ['line-delta']
<spiv> (Pdb) pp self
<spiv> <bzrlib.knit._KnitData object at 0x88dc36c>
<spiv> I think that may be causing _StreamAccess.get_raw_records to return a fulltext with a 'line-delta' flag.
 * spiv rereads
<jelmer> schierbeck: pong
<poolie> get_lines is meant to return a fulltext though...
<schierbeck> could i get you to review the seahorse patches?
<spiv> Hmm, maybe not.
<schierbeck> including the gannotate crasher fix?
<schierbeck> it can wait until tomorrow if you like
<poolie> so we're working on file id 'test_hook.py-20070206032729-2b5teqiwctqrfgei-8' right?
<poolie> afaics the only new version of that is 'jelmer@samba.org-20080319144357-o10479ukm9486mjc'
<beuno> jelmer, almost there  :)
<spiv> poolie: that matches what I've seen.
<poolie> so i have a reference to the remote knit, and to the composite knit used in pulling
<poolie> am going to try to read the raw records from  both..
<poolie> ok, so, obviously, calling get_lines on the result of _knit_from_datastream fails
<poolie> whereas calling that on the vf obtained direct from the remote repository works
<jelmer> schierbeck: I don't like the fix, I think we should rather pass in a branch and a repository
<jelmer> schierbeck: since gannotate does have a repository and a repository is sufficient for retrieving the signatures
<schierbeck> okay
<poolie> i wonder if the problem relates to sharing the local index...
<spiv> Ugh, pdb gets really confused by generators.
<poolie> they have the same index except obviously a different index_memo
<lifeless> poolie: get lines returns an output
<poolie> what do you mean?
<lifeless> meh, sorry
<lifeless> bad api - similar method names different levels
<poolie> :) i think i said something to that effect last week
<poolie> so i'm going to try to use the index memo to get the raw record in both ways
<poolie> and see if they are plausible
<spiv> Interestingly, I'm seeing duplicated reads of knit records.
<spiv> Huh!
<spiv> I'm seeing different bytes for subsequent reads of one of the affected records...
<poolie> ipython yay
<spiv> Ah, different index_memos.
<spiv> (None, 3160, 743) vs. (True, 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d', None, None)
<poolie> interesting
<poolie> ok, so In [73]: rcptknit._data.read_records([(missing_version, rcpt_index_memo)])
<poolie> Out[73]:
<poolie> {'jelmer@samba.org-20080319144357-o10479ukm9486mjc': (['88,89,1\n',
<poolie>                                                        "            hook.on_server_start(['source'], 'target')\n",
<poolie>                                                        '109,110,1\n',
<poolie>                                                        "            hook.on_server_stop(['source'], 'target')\n"],
<poolie>                                                       'aeb329edcf769738daaf07c22e921310551ff520')}
<poolie> in other words, the composite knit for receiving the data stream _does_ seem to have the right delta at one level
<poolie> it must be losing it later on
<spiv> Well, that particular version_id has had the rigth data all the way through, I think.
<spiv> We seems to be seeing the mismatch on a record that's already present locally, I think?
<poolie> oh fuck
<poolie> gnome terminal crashed losing all my state
<spiv> poolie: *suck*
<lifeless> xterm
<lifeless> + screen
<poolie> yeah
<poolie> it had just sucked me into trusting it in hardy
<lifeless> spiv: what did you think of my impotr hook
<spiv> lifeless: it looks interesting, but I haven't done much more than glance at it
<poolie> spiv, so we think the bad version is eg 'robertc@robertcollins.net-20070326022727-xatcyboet3na2p9d'?
<spiv> poolie: yes
<spiv> poolie: (and 'robertc@robertcollins.net-20070427001748-ctalelbr21ggxkuh', but it's choking on the other one first)
<lifeless> its not me I promise
<spiv> lifeless: :)
<spiv> So fundamentally, I think the mismatch is read_records_iter is returning a fulltext, where _get_components_positions says it should be a line-delta
<poolie> ok, so calling remote_vf.get_data_stream gives back a gzipped record that does have delta markers within it
<spiv> The interesting thing is that read_records_iter is recursing: the top-level one has a _StreamAccess, which calling get_raw_records on causes an underlying _KnitData.read_records_iter to be called.
<poolie> but at some later point they seem to be lost
<poolie> one change in this since 1.3 is that we try to share structure among copies of the text
<poolie> to avoid constructing new ones
<lifeless> 'oops'
<poolie> i can't really see how it would happen, but maybe this is causing something that should have line deltas to have them edited out
<spiv> The bottom-most read_records_iter does give back a line-delta record, but by the time it goes through the intervening layers it's a fulltext.  So I'm suspecting _get_components_positions isn't taking that into account?
<beuno> jelmer, sent the patch
<poolie> i think it's somewhere there too
<schierbeck> jelmer: i've sent in a new iteration of the gannotate fix
<poolie> spiv: well, at some point it must be actually getting transformed into a fulltext
<poolie> oh
<poolie> here's an idea
<poolie> i have been assuming it's being passed back as the fulltext of that version
<poolie> but we haven't checked that's true
<poolie> or i haven't
<poolie> anyhow
<spiv> Hmm!
<spiv> I think I have a fix.
<spiv> I'm not sure it's the right fix...
<spiv> poolie: lifeless: http://rafb.net/p/FvWu4u73.html
<poolie> i had been wondering about get_build_details
<poolie> (why won't irssi do tab-completion on symbols? :)
<spiv> Hmm, I think I maybe got the comment backwards.
<poolie> what is index_memo[0] in this case?
<spiv> 'thunk_flag'
<spiv> poolie: see the docstring on _StreamIndex.get_position
<poolie> in what sense is it thunking?
<spiv> Basically, if that's set, then _StreamAccess.get_raw_records will unconditionally return a fulltext.
<lifeless> spiv: IIRC getting the stack is kindof slow ?
<spiv> lifeless: yeah
<poolie> maybe we can rename it?
<spiv> _StreamAccess.get_raw_records has a comment in the implementation that sort of explains the thunking.
<lifeless> spiv: for debugging, it would be nice to give the call frame for the lock acquisition that hasn't been released.
<abentley> lifeless: Is http://people.ubuntu.com/%7Erobertc/baz2.0/shallow-branch/ revno 3247 the most recent version?
<spiv> lifeless: yeah, that would be nice
<lifeless> abentley: probably
<lifeless> spiv: but we do lots of locking
<lifeless> spiv: so the test suite would likely be visibly slower. any thoughts?
<spiv> Yeah.
<spiv> Debug flag, I think :(
<spiv> I don't think we want this on all the time.
<poolie> because of holding the call stacks?
<lifeless> spiv: planning a debug flag already
<lifeless> thanks
<spiv> Happily, with my -Dselftest_debug flag, you can set debug flags that won't be cleared by the test suite...
<poolie> lifeless: why slower?
<spiv> So that's probably good enough.
<abentley> lifeless: I have done some prototyping of the remote stacking default discussed in my email here: http://code.aaronbentley.com/bzr/bzrrepo/stacking-policy2/stacking-policy
<spiv> poolie: just acquiring the current stack trace is relatively slow.
<lifeless> spiv: how does that work ?
<spiv> lifeless: if -Dselftest_debug is set, then the "clear the debug flags" part of the test setup is disabled.
<spiv> lifeless: so I can do e.g. -Dselftest_debug -Dhpss and get nice hpss debug logs in test failures.
<spiv> I strongly suspect it will confuse any tests for debug.debug_flags itself, but as a tool for debugging individual tests rather than the whole suite, it's helpful.
<spiv> (plus turning on debug flags that emit log output might confuse tests that are particular about the log output they expect)
<spiv> Well, tests pass with my patch.
<poolie> lifeless: of course the lock statement that is not cleaned up may not be the one that actually acquired the lock in the first place
<spiv> lifeless: any comments on my candidate fix?
<poolie> so perhaps you should leave this for now
<poolie> wow
<poolie> that is a bit messy
<lifeless> poolie: huh?
<poolie> spiv: http://rafb.net/p/n0SGoV75.html
<lifeless> poolie: knowing who physically aquired the lock should be enough to debug things
<poolie> i think that should be 'if from_backing_knit'
<lifeless> poolie: I am leaning towards leaving the warnings in place
<poolie> lifeless: surely in a test the filename of the lock will make it fairly easy to tell?
<spiv> poolie: yeah, that would be clearer.  I don't recall why it tests that rather than the thunk_flag.
<lifeless> poolie: smart server threads?
<poolie> otoh, for the gc warning, then knowing the allocating stack _will_ make it far more useful
<poolie> since right now the gc message is pretty hard to match up to a bug
<poolie> otoh if it's slow you would not want it on by default
<lifeless> right
<lifeless> how about I finish the code :P
<poolie> spiv: how about http://rafb.net/p/dte0qf23.html
<poolie> i'm a big fan of making the bug obvious before you fix it
<spiv> poolie: +1
<poolie> (not actually tested, just in addition to your change)
<spiv> It looks correct to my eyes.
<spiv> I'm fairly sure this is the bug.
<poolie> yes it looks right to me to
<poolie> too
<spiv> I'm not sure why 1.2 didn't have this bug, I guess get_build_details has changed since then.
<poolie> um, i wonder if the code at the bottom of get_raw_records, circa l2270 is right
<poolie> what is it doing with orig_options?
<poolie> and why? :)
<spiv> It's making sure orig_options has the right value ;)
<spiv> And then ignoring it :)
<poolie> can it do anything more useful?
<poolie> i think not because it's the higher level index that says what the options will be, in here we can't really check it
<spiv> Yeah, I think so too.
<poolie> i actually think the orig options are none of our business..
<spiv> This method smells a bit.  I guess it's meant to be somewhat temporary.
<poolie> if the backing_knit returned a text that's good enough?
<spiv> Yeah, I think so.
<poolie> lifeless: this is your code i think
<poolie> the handling just above that of final newline looks suspicious to me too
<poolie> shouldn't that be handled inside get_lines?
<lifeless> poolie: sorry, I'm not tracking the conversation
<lifeless> whats up?
<poolie> do you have a sec?
<poolie> wondering about the handling of orig_options in about line 2270
<poolie> and the addition of a final newline above that
<lifeless> which file, what source code tree
<lifeless> I mean, what branch
<poolie> knit.py 1.3
<poolie> probably unchanged in trunk
<lifeless> let me branch 1.3
<poolie> if that's easier
<lifeless> I've spent the last three weeks changing this in trunk
<lifeless> :P
<spiv> poolie: I'm going to break for lunch now
<poolie> :)
<lifeless> if its anything to do with StreamAccess, andrew wrote the code
<poolie> http://rafb.net/p/GRinMk31.html <--- 2nd hunk of this
<lifeless> and john did some large scale restructuring
<poolie> ok, so
<poolie> do you think that patch is reasonable?
<lifeless> hmm from_back_knit seems wastage
<lifeless> that should have just replaced the index object with a index that represents the backing object
<lifeless> anyhow
<lifeless> poolie: you're commenting out some adaption logic ?
 * spiv is not quite at lunch yet...
<lifeless> index_memo has to stay opaque please
<poolie> yes, i think it's dead code but it's attributed to you
<lifeless> don't call it a tuple of things, or ti stops being opaque
<poolie> within this class it has that form
<poolie> will add a note to that effect
<lifeless> yes, but the docstring is for the public interface
<lifeless> an Index and an Access class are paired
<poolie> sure
<poolie> so, why does that code add a newline?
<spiv> I dimly recall there being some deficiency in the get_lines interface that made that necessary.
<spiv> Something to do with the noeol flag, maybe?
<poolie> sure
<poolie> but it seems to me that, hm, that should be handled by the backing knit
<lifeless> so I think its attributed to me because of a move
<kgoetz> is anyone aware of a bzr script/tool that opens up a diff in one pane (of emacs/vim) and your log edit window in the other when doin a commit?
<lifeless> kgoetz: well, 'bzr commit --show-diff' will give you the diff in the editor
<lifeless> you could split the pane
<spiv> Hmm, I definitely need some food.
 * spiv -> really lunch
<poolie> lifeless: ok i will kill it and see if it still passes
<lifeless> poolie: final eol issues
<kgoetz> lifeless: thanks, i'll try it out
<poolie> we should really work out how to test for it
<lifeless> poolie: so, the low level storage does not have enough info to reconstruct a full text correctly, ever, without the index metadata
<poolie> right :/
<kgoetz> wow. ancient bzr doesnt have the switch :| *goes to find a newer version*
<lifeless> kgoetz: improvements come over time; news at 11 :)
<jml> lifeless: how do I uncombine threads?
<kgoetz> lifeless: hehe :)
<lifeless> jml: make a new thread, set appropriate last revisions
<poolie> lifeless: oh i remember: the problem with the gc warnings and tests (or one additional problem) is that now we just use short random nomes for the test directories it is very unclear even which test caused the problem
<kgoetz> are backports build of bzr for feisty?
<poolie> yes, in the ppa
<kgoetz> thanks, i'll keep looking.  :)
<poolie> launchpad.net/~bzr/+archive i think
<poolie> is it not?
<poolie> lifeless: so anyhow regarding EOLs
<poolie> shouldn't self.backing_knit.get_lines(version_id)
<poolie> return lines that either have an eol or not as appropriate?
<lifeless> poolie: interestingly; LockDir does not clear the nonce when it unlocks
<lifeless> poolie: backing_knit.get_lines() should yes
<lifeless> poolie: but if we're returning whats meant to look like a serialised record
<lifeless> poolie: then it has to have a trailing newline regardless
<lifeless> poolie: frankly, I think you're altering the wrong bit in this patch
<lifeless> because its returning valid texts, with a single incorrect bit set AFAICT
<poolie> that's the point of +            if index_memo[0]:
<poolie> +                # texts retrieved from the backing knit are always full texts
<poolie> +                method = 'fulltext'
<lifeless> except somehow we're returning line-delta for one of those
<poolie> right
<poolie> andrew's reasoning aiui is this
<poolie> whenever we get something from the backing knit
<poolie> we always get a full text
<poolie> therefore our index should always say that it will be returned as a full text
<poolie> the separate issue i'm concerned with is whether it correctly passes through the noeol flag on lines retrieved from the backing knit
<lifeless> well, if the eol flag is wrong the md5 sum check will error
<lifeless> the noeol *flag* must be preserved unaltered
<lifeless> the last line of the lines returned must always end in \n except for an empty content
<lifeless> because thats the serialised form
<poolie> ok
<poolie> so, we add this so that the serialized form is correct
<poolie> and the noeol option will be seen because the _StreamIndex.get_options passes through the option from the backing file
<poolie> i might get lunch too and wait for andrew
<poolie> biab
<lifeless> right
<lifeless> thats how I read the code
<beuno> jelmer, I forgot to update news. Should I send a bundle to the list or just merge?
<lifeless> poolie: did you land the warning disabling patch ?
<jelmer> beuno: just merging is fine I think
<poolie> lifeless: i don't think so; at any rate i did not send it today
<poolie> spiv: back?
<beuno> jelmer, done. Ping me if you need anything else on my end to get 0.94 out the door
<poolie> lifeless: can i bother you about this some more, or at least yammer in your direction
<lifeless> sure
<poolie> so get_raw_records to get it from thebacking knit
<lifeless> do you want voice?
<poolie> is getting the lines, joining them, then converting that to a data blcok
<poolie> hm
<poolie> it seems like this is sometimes double handling but i guess making it faster is not the point here, just making it work
<poolie> for this bug
<poolie> oh i see
<poolie> nm
<kgoetz> lifeless: thanks for your tip earlier. its exatly what i'm after.
<poolie> spiv, lifeless: so it seems to me that _StreamIndex.get_options is also wrong:
<poolie> if we're going to return a record from the backing knit, i.e. by generating a fulltext record, then we must change the options to indicate that it will be a fulltext record - agree?
<moquist> I'm new to bzr, and I would like to use it to help me manage my .bash* and .vim* files on several systems. I can't figure out how to pull/checkout/branch without getting my bzr-ed dotfiles in a subdirectory of my home directory. "bzr: ERROR: Target directory "./" already exists" is a message I'm not sure how to avoid.
<poolie> moquist: i think you, on the destination machine
<poolie> | cd ~
<poolie> | bzr init
<poolie> | bzr pull --remember URL
<poolie> welcome to bzr btw
<moquist> poolie: hi. We spoke in an elevator at UDS-Montreal about you teaching me bzr someday. :)
 * mneptok waves from said city
<moquist> poolie: and thx.
 * moquist tries it out
<mneptok> moquist: personally, i would create ~/scratchdir and put your content in there. init bzr there. practice, get comfy, then init in your ~/ for actual usage.
<poolie> oh, right
<poolie> hi matt
<poolie> ^^ wise man :)
<mneptok> moquist: but then, i'm shy on first dates ;)
<poolie> so actually, i keep my dotfiles in .bzrconfig and symlink them into my homedir
 * mneptok swoons
<poolie> i'm not sure it's really needed
<mneptok> *that's* the kinda talk i like, poolie :)
<poolie> on the second date he brings his toybox though
<poolie> or so i hear
<moquist> mneptok: Well, I just learned today how to use bzr for managing source for a real project, and I'm more-or-less comfortable with merges, conflict resolution, etc. But I'm happy to work on a project in a subdir, so this was a confusion I didn't have to figure out for that. :)
<lifeless> poolie: that sounds plausible
<poolie> about mneptok, yeah
<mneptok> moquist: just a suggestion. i've been burned so many times i always play it safe. you know your needs and abilities far better than do i. do what suits your comfort level and needs. :)
<poolie> or my patch?
<lifeless> heh; what time did you start this morning :P
<lifeless> both I guess
<moquist> mneptok: Oh, I appreciate the advice, and I'm thinking about it. And I'm thinking through my backups, and whether or not they're current, etc. ;)
<mneptok> poolie: only you get the toybox, big fella :)
<poolie> about 9 when steve called and said mdz was bitten by this bug
<poolie> but i started early and finished late
<poolie> yesterday
<poolie> so will have an early friday and take you up on that virtual ale
<mneptok> do bugs in bzr reflect the Ausiie nature of most of the dev team? like, are the bugs highly toxic, venomous, and capable of supersonic flight?
<poolie> heh
<poolie> did you read the crocodile hunter's company is being charged with tax evasion?
<mneptok> *that's* goota sting, Ray.
<mneptok> *gotta
<poolie> we should rename KnitCorrupt, it usually means "your data is fine but we have a bug..."
<mneptok> maybe they'll change the daughter's name to Bindy Suit
<AfC> Gah. I wish I could supress the whole branch nickname thing.
<AfC> It always ends up being about three branches out of date after we've switched a few times.
<lifeless> it doesn't change when you switch ?
<poolie> it may be a tree nickname instead? which would be a bug
<lifeless> don't think trees have nicks
<poolie> just a guess, if it is not working properly with switch
<poolie> but i think i remember seeing it really in the branch
<jml> mneptok: the Bazaar User Guide recommends shaking out your boots before using bzr.dev.
<jml> just in case.
<poolie> lol
<spiv> poolie: yes, back.
<AfC> lifeless: no. I can't say that I blame anyone for what I thought, but I did sorta think it would switch to the last component of the branch URL I was switching to. [This is with bzr 1.3]
<AfC> jml: :)
<mneptok> jml: and all this time i thought that was to make sure lifeless wasn't hiding in there, optimizing your lacing routines
<mwhudson> but lifeless is from kiwi-land -- surely his software should spew lava and pyroclastic flows all over everything?
<poolie> spiv: see my scrollback about get_options?
<mneptok> mwhudson: you should see the haka it makes when it segfaults
<spiv> poolie: catching up atm
<poolie> this is my current overall diff
<poolie> we should think about writing a test for this
<spiv> poolie: what you say about get_options makes sense to me.
<rockstar_> I'm trying to use svn2bzr.py, and I'm getting an error on from bzrlib.clone import copy_branch because there's no module named clone
<poolie> rockstar_: i would guess the version of svn2bzr is too old for your bzrlib or vice versa
<rockstar_> poolie, I pulled the svn2bzr from lp, and I've got bzr 1.1.0.candidate.1 installed
<poolie> i meant to say, this is my current diff: http://rafb.net/p/bonbwZ20.html
<rockstar_> Is there a branch outside the lp 'main' branch I should be pulling from?
<lifeless> you should only use the main branch there if you want a development version
<lifeless> and its development versions work with bzr's development versions
<poolie> i think we removed bzrlib.clone some time ago, do you recall?
<rockstar_> Well, I couldn't find a released version of the script.
<rockstar_> At least, not on the lp site
<poolie> rockstar_: the site says "svn2bzr is a tool to convert Subversion repositories into Bazaar 2.0 repositories. It does not currently have an active maintainer. You might be interested in bzr-svn instead."
<poolie> bzr-svn does seem to be what most people use
<rockstar_> That appeared like a bridge between a working svn and a working bzr branch though.
<poolie> yes, it is
<poolie> you don't have a working svn server (anymore)?
<rockstar_> Well, I do, but I don't want to use it.  Just want to convert the entire repo from svn to bzr and move forward on bzr
<poolie> ok
<poolie> so svn2bzr may need a small update for the new api
<poolie> can i suggest you please file a bug at https://bugs.edge.launchpad.net/svn2bzr/trunk/
<poolie> with the full traceback
<poolie> um
<poolie> you may have more success if you use an older version of bzr corresponding to that svn2bzr release
<spiv> poolie: s/memors/memos/.  I agree with lifeless earlier comment that get_build_details docstring shouldn't say more than "opaque structure".
<rockstar_> poolie, where's the current svn2bzr trunk?  I'd like to take a whack at fixing the bug.
<poolie> then (if necessary) upgrade
<poolie> great!
<poolie> spiv: agree too, was just changing that
<spiv> poolie: I'm not certain if the change to get_method is 100% safe -- shouldn't it raise an error if the backing knit doesn't have that version?
<spiv> (I can imagine it not mattering in practice, but we should be conservative with changes we're backporting)
<poolie> spiv: good point, maybe i should change it to call my get_options and use that?
<spiv> Yeah, that sounds like a good idea.
<spiv> Otherwise, that patch looks good to me.
<poolie> rockstar_: https://code.edge.launchpad.net/~niemeyer/svn2bzr/trunk
<spiv> We just have to figure out what test(s) to write...
<lifeless> yay
<lifeless> ERROR: test_lockdir.TestLockDir.test_20_lock_peek
<lifeless>     Different number of acquired and released locks. ([<bzrlib.lock.LockResult object at 0x311ee10>], [])
<lifeless> if I may
<lifeless> I'd rather you guys didn't make too many changes here; just the minimum to fix the bug
<lifeless> I'm in the business of overhauling this entire structure anwyay
<lifeless> but I'd be happy to take a list of 'we think X should be done' and I'll fold that into my loom
<poolie> well
<poolie> i'll try to keep it focussed but i think a strictly minimal one line fix leaves trouble in the code-
<lifeless> and indeed
<lifeless> test_20_lock_peek was leaving a physical lock in place
<poolie> yay
<lifeless> so a couple of commits and I'll send in this loom for review
<lifeless> it may not be perfect; but its a good step I feel
<poolie> great
<poolie> so you are going to actually fix them?
<poolie> or some of them?
<poolie> spiv: so http://rafb.net/p/hPuGm457.html is my final patch, i think
<poolie> with your fix for get_method and better commentsn
<poolie> needs tests still obivously
<spiv> poolie: still has the "memors" typo in a docstring
<poolie> hopefully there are already some for the stream classes
<poolie> thanks
<spiv> and slightly odd wrapping in the same docstring
<lifeless> poolie: no, I shall leave that for lesser beings
<spiv> poolie: I think that patch looks good.
<lifeless> it will now print out:
<lifeless> Broken test test_20_lock_peek (bzrlib.tests.test_lockdir.TestLockDir): Different number of acquired and released locks. ([<bzrlib.lock.LockResult object at 0x33f9d10>], [])
<lifeless> on left behind physical locks
<lifeless> I think this is a significant improvement even if not 100% accurate.
<lifeless> it may not be 100% congruent with the current stipple
<lifeless> because I think its lockable files or something that does the current warnings
<poolie> if we had selftest --strict it would be nice for it to trap these
<poolie> like for tests to say "actually i kinda failed but i'll live"
<spiv> selftest --test-harder? ;)
<poolie> elite mode
<poolie> the developer guide does i think say we want --strict
<poolie> --fierce :)
<lifeless> hmm
<lifeless> what I've *done* is have -Dlock trap them
<lifeless> and in future -Dlock should also get full backtraces of the acquirer
<lifeless> anyhow, its a sonnet in two parts; reviews FTW
<spiv> So, to test this fix... we can either try poking at KnitVersionedFile.insert_data_stream directly, or write a higher-level test that pack->knit pulling via streams works.
<spiv> The key properties seem to be that the knit needs a line-delta record, and the format of the stream needs to be incompatible with the knit versioned file, triggering this code path.
<rockstar_> poolie, it looks like the error I'm getting in svn2bzr.py has to do with the dump file I'm using.  It's trying to split on a line that throws a ValueError
<rockstar_> 'Node-path: ' can't split on ': '  It's not catching an empty value
<poolie> rockstar_: i thought you were getting an import error?
<poolie> spiv: ok, are there any tests for such pulling already?
<lifeless> rockstar_: bzr-svn has an import mode
<lifeless> rockstar_: I think you will likely have better results with it
<rockstar_> lifeless, yea, that was suggested too.  I just figured I could fix a bug while I was in here.
<spiv> poolie: test_knit.BasicKnitTests has some test_insert_data_stream* methods.
<lifeless> rockstar_: up to you :P.
<spiv> poolie: I don't know of any similar tests at a higher level.
<lifeless> this is strange
<lifeless> :!bzr annotate bzrlib/knit.py
<lifeless> bzr: ERROR: exceptions.TypeError: sequence item 0: expected string, tuple found
<lifeless> :/
<poolie> i meant an error from an import statement
<poolie> above
<poolie> just going to branch and commit what i have
<poolie> i find this creation of new singleton classes for each group of locks a bit gross
<lifeless> singletons ?
<poolie> +hooks = PhysicalLockHooks()
<lifeless> oh group of hooks ?
<poolie> yes
<lifeless> well, its less text than putting staticmethod decorators on everything
<poolie> why not just have them all on Hooks()?
<lifeless> I actually like it, its very convenient, useful for testing and creating isolated state
<lifeless> namespaces are good, we should do more of them
<lifeless> but look, if you want to collapse them all into one, create a patch. *I* think it will be ugly, less modular, harder to extend and reuse.
<poolie> hm
<poolie> ok
<poolie> i think the problem is they are fragmented namespaces
<poolie> afaik there is no way to find out about all the hooks that are active in bzrlib
<poolie> sight
<fullermd> So, is it known that bzr.dev eats itself in some cases talking to bzr://, while 1.3 works peachy?
<lifeless> re: introspection - you are correct that there isn't a single call you can make to find out about all the hooks
<poolie> to the same version?
<fullermd>   File "/home/fullermd/src/bzr/bzr.dev/bzrlib/remote.py", line 883, in _get_parent_map
<fullermd>     assert type(key) is str
<fullermd> AssertionError
<poolie> having a namespace like "lock.acquired" is of course fine
<fullermd> Same with bzr.dev and 1.3 acting as the server.  'bzr log bzr://localhost/...' works with the 1.3 client, and dies with a trace ending as above with bzr.dev.
<spiv> fullermd: that one is new to me
<lifeless> thats a line I added
<lifeless> to ensure correct api usage with a changed api
<lifeless> well, to catch incorrect api usage
<lifeless> fullermd: can you file a bug with how to reproduce?
<poolie> lifeless: the other specific thing that bothers me is that reset_hooks() needs to know what specific class to create a new instance of
<lifeless> fullermd: assign to me, I'll fix on monday or before
<poolie> it's not very unreasonable for a test to do so
<poolie> it just seems odd
<lifeless> I don't see that a single class changes that
<lifeless> it will still know the class to create :P
<lifeless> did you watch the paradox of choice?
<poolie> no, there was a critical bug, you might have noticed :P
<poolie> may do it when this was done
<poolie> more generally,
<poolie> if you have an object api, where the general api is that you're meant to operate on the object rather than rebinding the variable
<poolie> then needing to do so for this case seems unclean
<lifeless> how so - the object is the saved state
<fullermd> lifeless: bug 211661, filed and assigned
<ubotu> Launchpad bug 211661 in bzr "bzr.dev smart client fails on log" [Undecided,Triaged] https://launchpad.net/bugs/211661
<lifeless> think of it as a register window rather than stack frame
<lifeless> rather than copying everything to the stack frame, we just move the window
<lifeless> and its all there waiting for us when we return
<poolie> so the problem is: there's no standard way to save a group of hooks, clear them, and restore it
<poolie> there is almost a standard pattern, but it requires creating a new class for each one
<poolie> instance of a different class rather
<poolie> but it's ok, it's consistent with what we have
<poolie> can be cleaned up later
<lifeless> so if I wanted to do it generically, I think I would do  saved_hooks = hooks; hooks = hooks.__class__()
<poolie> right
<lifeless> I think that it is fine to mandate a parameterless constructor
<poolie> or you could have in the base class, hooks.make_empty()
<lifeless> I don't know that that would be cleaner
<poolie> maybe not
<lifeless> I want 'bzr p ull' to work. that is all.
<poolie> if we hooked into zsh correction sufficiently well it might
<poolie> though i don't know if it ever suggests joining words like that
<lifeless> bash <-
<lifeless> spiv: http://bundlebuggy.aaronbentley.com/request/<20080228144229.GF3192@steerpike.home.puzzling.org> <- has that landed?
<ubotu> New bug: #211661 in bzr "bzr.dev smart client fails on log" [Undecided,Triaged] https://launchpad.net/bugs/211661
<spiv> lifeless: IIRC yes, let me check
<lifeless> bb thinks it hath not
<spiv> Huh, interesting.
<spiv> Some of it has :)
<lifeless> poolie: btw, you said I had broken ReST in my plugin api patch, but rest doesn't think so. Why did you think I did?
<poolie> i don't remember, where was the patch?
<lifeless> http://bundlebuggy.aaronbentley.com/request/<1204283630.28682.40.camel@lifeless-64>
<lifeless> btw, the status heading I intend to keep because its consistent with other documents
<abentley> poolie: I've solved that merge bug.
<poolie> way to go
<poolie> spiv: my patch is in https://code.edge.launchpad.net/~mbp/bzr/208418-knit-parsing (not mirrored yet)
<spiv> poolie: thanks!
<poolie> abentley: I got a bb 500 error, just so you know
<poolie> will try again...
<abentley> Please do.
<poolie> it was "database is locked"
<poolie> lifeless: i thought there were column separators missing from your table
<poolie> you're welcome to keep a heading called "Status", I just want you to put some actual status information under it
<poolie> like adding "this api is implemented in 1.2 and is stable"
<abentley> poolie: Well, that one might have been due to all the mail going through it.
<abentley> At least, it's working, and I don't have any mail from the nanny-script.
<poolie> ok
<poolie> is it just that only one process can use sqlite at a time?
<abentley> Many can read, only one can write.
<abentley> Viewing the home page writes to some caches.
<abentley> (line number count, for example)
<poolie> right
<poolie> so switching to pgsql should help this
<abentley> Finer-grained locking?
<poolie> iirc it should allow multiple fronts to (apparently) write at once
<abentley> lifeless: hbb?
<lifeless> hypothetical bundle buggy
<lifeless> k, thats 8 hours
<lifeless> to keep robert sane, work shall cease
<bob2> ETOOLATE
<abentley> bob2: lol
<abentley> poolie: Could you do that "Bzr Developers" stuff?
<poolie> oops, wrong channel
<poolie> 15:51 <poolie> spiv, so you're working on tests?
<poolie> 15:52 <poolie> spiv, lifeless: I'm wondering about starting to make a new release
<poolie>                1.3.1 with just that change, before the tests are done
<poolie> 15:52 <poolie> with a view to getting it out at a reasonable time today
<poolie> abentley: what stuff?
<abentley> I created a team called "Bzr Developers" so that it can own bzr, and I can join it instead of Bazaar Developers.
<abentley> That way, I don't get mail about subprojects I'm not interested in.
<poolie> ok
<abentley> I made you the owner of Bzr Developers after I'd set up the profile.
<spiv> poolie: I am
<poolie> do you think i shouldmerge this now?
<poolie> and release it?
<poolie> i guess i could at least call it 1.3.1rc1
<poolie> abentley: but isn't that what ~bzr is for?
<abentley> ~bzr is Bazaar Developers.
<poolie> i see
<poolie> a bit poorly named then
<poolie> Launchpad loves creating teams
<abentley> Yeah, it's a bit ugly at times.
<abentley> I don't know how else to handle scads of people, though.
<jamesh> poolie: would it really be any better if we called them ACLs?
<poolie> :)
<poolie> indeed
<poolie> well, it would have two differences
<poolie> one is that they would not then have such visible names
<poolie> that might make it more confusing to be dealing with these anonymous objects
<poolie> certainly harder to give the same acl to different objects
<poolie> but otoh it would not cause lasting problems when people use the name ~bzr for what should actually be ~bazaar-devs
<poolie> secondly, it would raise the question of whether we want different ACEs
<jamesh> poolie: I think providing a project-level namespace for branch aliases that is controlled by the project owner might be the answer here
<poolie> like read/write/control access, or negative ACEs
<poolie> !
<jamesh> effectively an extension of the current lp:$PROJECT names
<poolie> well i agree with you, but i was talking more generally than just that
<spiv> poolie: I don't see any harm in making a 1.3.1rc1 out of what you already have
<abentley> poolie: Could you also make ~/bzr-developers the owner of /bzr please?
<spiv> poolie: if the only difference between the rc and final is adding some tests, then I think that's fine.
<poolie> ar
<poolie> yes
<poolie> getting tired
<poolie> jamesh: that might do
<poolie> wouldn't those important branches normally be series?
<poolie> maybe not, they might be important feature branches
<poolie> so should that right be restricted to project admins?
<poolie> oh, owners
<jamesh> poolie: would the old bzr.hpss branch have been a series?
<poolie> so typically a team
<jamesh> or would you consider it not special enough to put in the project namespace?
<poolie> jamesh: 1s
<poolie> abentley: uh how do i do that?
<poolie> oh
<poolie> 'change maintainer'
<poolie> there are too many similar names: owner/maintainer/author/registrant
<poolie> some have distic
<poolie> some have meaning and some don't
<abentley> I think owner/maintainer/registrant are the same here!
<poolie> "change maintainer" takes you to a page headed "change owner" :)
<abentley> "Change maintainer" link goes to "Change owner" and button says "Change registrant"!
<poolie> that's really funny
<spiv> abentley: bingo! :)
<poolie> bug 202135
<ubotu> Launchpad bug 202135 in launchpad "Change project maintainer page also uses owner and registrant" [Undecided,New] https://launchpad.net/bugs/202135
<abentley> Well, at least people are noticing.
<abentley> Okay, looks like I can change the owner.
<poolie> hm
<poolie> abentley: might it not have been better to keep ~bzr as the owner of bzr, and make the new team for everything else?
<poolie> and wasn't vila trynig to do something similar?
<poolie> did you talk to him?
<abentley> No, I wasn't aware of vila's efforts.
<abentley> I'm not sure whether we can change the shortname of Bzr Developers easily.
<jamesh> the team owner should be able to change its nickname
<jamesh> (I think)
<abentley> Yeah, looks like we can.
<abentley> Shall I?
<abentley> Oh, I can't change the shortname for Bazaar developers, which would have to happen first.
<abentley> Anyhow, Bazaar Developers, which everyone's subscribed to, should retain its memberships in other teams.
<poolie> spiv: did your patch actually allow you to pull from 'bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr-dbus/trunk/'
<poolie> it is not working for me
<abentley> So we can just swap the shortnames.
<poolie> my larger patch may have broken it
<poolie> abentley: i'm concerned that will cause the ppa to move
<abentley> Aren't PPAs associated with teams?
<AfC> Anyone know off hand what we need to do to get Ohloh to support Bazaar? [no, not that it matters, but you know, its one of those things that can enhance visibility]
<poolie> AfC: mail them and ask?
<abentley> I think right now the PPA hasn't moved, but if we swap the shortnames, it will.
<poolie> abentley: yes that's what i meant
<cprov> abentley: they get affected by renaming person/team
<spiv> poolie: it gave me the same "branches have diverged" error as sftp:// did
<spiv> poolie: whereas without it gave a traceback
<AfC> poolie: I guess so. http://www.ohloh.net/about/faq#sourcecontrol
<chandlerc> anyone familiar with bzr-svn?
<poolie> spiv: with my branch I get
<poolie> KnitCorrupt: Knit <bzrlib.knit.AnnotatedKnitContent object at 0xb75222ec> corrupt: line in annotated knit missing annotation information: need more than 1 value to unpack
<abentley> poolie: I believe we can copy stuff from one PPA to another, so we can do that if/when we change the shortnames.
<spiv> poolie: hmm!
<spiv> poolie: no, I didn't get that.
<abentley> poolie: Anyhow, thanks!
<poolie> abentley: really my question is: why not remove ~bzr from everything but ownership of bzr?
<poolie> won't that give what you want?
<abentley> Yes.  I assume other people want to stay members of other things, though.
<cprov> abentley: or just request a sysadmin to rename the archive disk directory ;) you can have such privileges.
<chandlerc> well, if anyone has any ideas, i'm getting a SubversionException Unrecognized URL scheme ... 170000
<abentley> If they do, then we'd have to switch the team associations from ~bzr to ~bazaar
<abentley> And move a bunch of people there, too.
<chandlerc> however svn co on the exact same URL, so I'm fairly certain my Subversion is built with SSL Support
<AfC> chandlerc: you are using the latest bzr and bzr-svn?
<chandlerc> bzr 1.3, bzr-svn 0.4.9
<abentley> But for me personally, that solution would be fine.
<spiv> poolie: just to confirm, my simple patch works with a pristine copy of the knit repo for running "bzr pull --overwrite", where without the patch that fails.
<chandlerc> svn is a weird 1.6 build
<chandlerc> trying to be a 1.5 branch build of subversion now
<spiv> poolie: I'm rereading your diff now to see if I can spot the culprit
<poolie> spiv: that's odd, i don't even get the divergence error
<poolie> and i'm using the tarball and url you cited earlier
<spiv> poolie: odd!  I'm working with bzr.dev rather than 1.3, but that ought not make a difference...
 * spiv tries with poolie's branch
<poolie> spiv: well a lot of stuff changed in knit.py since 1.3
<spiv> poolie: I can reproduce your error with your branch (after fixing a trivial bug in get_options)
<spiv> poolie: merging bzr.dev into your branch makes no difference
<lifeless> well
<lifeless> looking up
<lifeless> i think we should rename ~bzr to ~bazaar
<lifeless> and ~bazaar-devs to ~bzr
<lifeless> then transfer objects, ppa etc across
<lifeless> *or*
<lifeless> rename 'bazaar developers' to 'bzr develoeprs' to match its original intent and make the new group the project-wide group
<poolie> i agree with lifeless
<poolie> and i prefer the second option, i think
<chandlerc> AfC: I don't guess that helped much?
<poolie> spiv: so maybe i should apply your minimal patch to 1.3 and see what happens
<poolie> and we can triangulate
<poolie> or rectangulate
<spiv> poolie: it's your changes to get_method/get_option, it seems
<spiv> poolie: If I back those out, it works
<poolie> chandlerc: jelmer may be on in a few hours
<poolie> or you can file a bug at launchpad.net/bzr-svn
<spiv> poolie: specifically, get_options
<poolie> if you do not ultimately get a good solution
<poolie> spiv: thanks!
<poolie> oh
<poolie> aside from anything else i should not be mutating that lisnt
<poolie> (whatever my next project is it will be in a pure language :)
<AfC> chandlerc: Sounds like you've got a stack trace to hand, so I'd suggest filing a bug. It might be something silly, of course, but it might just as likely be something real.
<abentley> poolie: Okay, I'll create a doppelganger Bazaar Developers with the name /~bazaar
<AfC> that "170000" sounded a bit weird, but depending on what you're doing [vs what you _should_ be doing] it could mean anything
<spiv> poolie: ah-hah
<spiv> poolie: that was the bug, well spotted
<chandlerc> AfC: k, i'm gonna try and roll back to svn 1.5 to be a little less bleeding edge, and if it happens then, i'll file a bug
<AfC> as for Subversion, I've certainly never heard of 1.6; we're all still waiting impatiently for them to get off their asses and ship 1.5
<poolie> apache libraries like using large decimal numbers for errors iirc
<AfC> chandlerc: good luck
<chandlerc> AfC: It's just a select revision of the trunk
<poolie> woo
<chandlerc> not a real release.. i dunno why the hell its even packaged, but it was easier to get that 1.5
<poolie> spiv: that worked then
<poolie> packaged in what system? ubuntu?
<chandlerc> gentoo
<spiv> poolie: yep, wrapping a list(...) around self.backing_index.get_options(version_id) fixed it
<chandlerc> having to scrounge for ebuilds... i need svn+https authentication, which seems to require at least 1.5
<chandlerc> not even a patched 1.4.6
<abentley> poolie: The problem with that theory is that there's already a ~bazaar in Launchpad.
<abentley> Though it looks like a dead account.
<poolie> we could be a bit more explicit like ~bazaar-overall
<AfC> chandlerc: I wouldn't recommend overlays under normal circumstances, but if you take the subversion ebuild from the bzr-gentoo-overlay thing lurking on Launchpad somewhere it will get you the necessary patches to svn for bzr-svn to work.
<chandlerc> AfC: that works, but doesn't allow full use of https subversion repo's i thought
<AfC> ah
<abentley> poolie: I called it bazaar-devs, but I'm happy to rename it.
<poolie> ok with me
<poolie> spiv:
<poolie> spiv:     * Fix a bug causing a ValueError crash when fetching revisions from a knit
<poolie>       to pack repository or vice versa.
<poolie>       (#208418, Andrew Bennetts, Martin Pool, Robert Collins)
<poolie> accurate?
<spiv> poolie: accurate, but maybe also mention that it happens with the smart server
<spiv> poolie: I don't think that code path is hit by other transports
<spiv> poolie: depends on how much detail you want to cram into a single bullet point I guess :)
<poolie> anything else?
<poolie> no i doubt it
<poolie> thought it is general code
<poolie> spiv: can i say you will be helping me get the review queue down next week?
<spiv> Yep
<johnny> is there a way to run loggerhead via fastcgi ? it's hard to tell with those start and stop scripts
<poolie> johnny: seems like it should be possible, mail the list or ask mwh for details
<chandlerc> AfC: I filed it here: https://bugs.launchpad.net/bzr-svn/+bug/211683 thanks for the help.
<ubotu> Launchpad bug 211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,New]
<ubotu> New bug: #211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,New] https://launchpad.net/bugs/211683
<poolie> 1.3.1rc1 is out
<poolie> i'm going to sign off
<poolie> thanks for your efforts, spiv and lifeless and everyone
<spiv> poolie: great!
<spiv> poolie: I'm learning more about the precise conditions thanks to trying to write a test case :)
<poolie> ok
<poolie> that sounds useful
<poolie> call if you want to talk about it
<spiv> the conditions appear to be that the stream is delivering a line-delta record, whose parent is in the target, and also stored as a line-delta.  (And of course that the source and target have different format signatures, i.e. one is annotated and the other isn't).
<spiv> But it's bit frustrating trying to reproduce that in test_knit, as you don't get much control over whether something is stored as a knit.
<spiv> er, stored as a delta.
<spiv> Ah-hah, I have a failing test.
<spiv> And it passes with the fix.
<spiv> poolie: ok, I should have this sent to the list in a couple of minutes
<spiv> poolie: have a great weekend
<spiv> And that's me done for the day.
<ubotu> New bug: #131008 in bzr-svn "bzr-svn stores sqlite db in ~/.bazaar => REALLY SLOW on NFS" [Low,Triaged] https://launchpad.net/bugs/131008
<jelmer> pushing to svn+ssh is now slightly faster than pushing over bzr+ssh
<aantn> hello
<aantn> I seem to have gotten locked out of launchpad
<aantn> http://rafb.net/p/amQNZj18.html
<james_w> aantn: run bzr break-lock sftp://branch a few times
<aantn> james_w: thanks
<aantn> that did it
<cody-somerville> Is it possible to have branches within branches?
<james_w> cody-somerville: so that the outer ones know about the inner ones?
<james_w> or are you just asking if bzr will fall over if you make a branch in a subdirectory?
<cody-somerville> james_w, the outter ones known in the inner ones.
<james_w> they are called nested trees, or subtrees. bzr can do them, but you will probably find some very surprising bugs at this point.
<cody-somerville> Okay
 * cody-somerville is convincing his company to use bazaar over svn.
 * cody-somerville hopes he isn't shooting himself in the foot.
<LeoNerd> ??
<LeoNerd> Are you just asking if you can branch a branch?
<LeoNerd> If so.. sure... branches don't really have topology
<LarstiQ> LeoNerd: no, if branches can contain branches.
<LeoNerd> A branch is a container of a sequence of revisions
<cody-somerville> ...
<LarstiQ> LeoNerd: yes, but that isn't helpful in this discussion :P
<LeoNerd> Well, I was still trying to understand the question
<LarstiQ> cody-somerville: you can certainly have branches within other branches, you require propagation as well I gather?
<LarstiQ> cody-somerville: are you using svn:externals (heavily)?
<LarstiQ> cody-somerville: or formulated differently, what prompts you to ask about this feature?
<cody-somerville> We don't currently use svn
<cody-somerville> but we'd like to be able to pull sub-components of the system as well as the entire system
<LarstiQ> cody-somerville: right
<LarstiQ> cody-somerville: ah, you're evaluating both bzr and svn, but are using something else atm?
<cody-somerville> LarstiQ, I just got hired and they aren't using anything :/
<LarstiQ> cody-somerville: well, from the positive side, no need to worry about legacy!
<cody-somerville> :)
<NfNitLoop> cody-somerville: Ouch.
<ubotu> New bug: #211852 in bzr "bzr log should accepts multiple files" [Undecided,New] https://launchpad.net/bugs/211852
<xif> hello
<xif> can I commit to an SVN repo with bzr?
<xif> ah, there's bzr-svn in the repositories
 * xif <3 Ubuntu
<seb_kuzminsky> hi folks, i've got merging problems...  or maybe my workflow is just wrong for bzr
<seb_kuzminsky> i think the root of my problem is lack of cherrypicking
<seb_kuzminsky> i'm working on a project where the upstream repo is in cvs (boo, hiss)
<seb_kuzminsky> i've checked out their tree and checked it into a local bzr branch called "upstream" in a shared repo
<seb_kuzminsky> then i branched my upstream to "local",
<seb_kuzminsky> and i'm doing all my development in my local branch
<seb_kuzminsky> when i have something ready to send back to them, i first merge it to my "upstream" bzr branch
<seb_kuzminsky> then cvs commit the merged result
<seb_kuzminsky> i dont always merge all of local into my upstream, instead picking one or a few particular "local" commits to merge to "upstream" and commit to their cvs
<seb_kuzminsky> that's cherrypicking, right?
<seb_kuzminsky> then next time i try to do a similar thing to the next lump of patches, the merge gets all confused...
<seb_kuzminsky> anyone here?  maybe i should take this question to the mailing list?
<james_w> seb_kuzminsky: that's cherry-picking yes.
<james_w> seb_kuzminsky: you may be better off on the list.
<seb_kuzminsky> ok thanks james i'll try that
<awilkins> seb_kuzminsky: Have you considered using seperate feature branches?
<Stavros> hello
<Stavros> i am trying to checkout a repo using bzr+ssh but i'm getting "unknown command: serve"
<Stavros> any ideas why that might be?
<beuno> Stavros, does the remote location have bzr installed?
<beuno> (and, if it does, what version?)
<Stavros> beuno: 0.8.2 :/
<Stavros> could that be it?
<beuno> Stavros, that doesn't sound like a bzr version
<luks> that's ancient...
<Stavros> stavros@menhir$ bzr version
<Stavros> bzr (bazaar-ng) 0.8.2
<luks> bzr didn't have a smart server back then
<Stavros> ah :/
<Stavros> i'll ask for an upgrade
<rockstar_> Using bzr-svn, I checked out an svn repository as a bzr branch, effectively converting the repo.  Is there a similar tool for CVS?
<seb_kuzminsky> awilkins: that would probably help...  but i'd still have the same problem unless i could convert my workflow to only use "merge -r" with increasing revno's, right?
<rockstar_> I'm trying to move a project from sourceforge's CVS to Launchpad.  Is there a tool readily available that would preserve history and such?
<kgoetz> perhaps the #launchpad ffolks if they have migration tools
<axes> does the windows installer for bazaar install the necessary libraries for uploading to an SSH server?  The connection starts correctly, getting up to the rsa fingerprint, but then drops with "EOF during negotiation".
<kgoetz> axes: sounds like a key missmatch
<james_w> rockstar_: there are a couple of cvs importers, I don't know which is best, I think cvsps-import is meant to be pretty good.
<axes> kgoetz: It notifies me that the key isn't cached, but doesn't give me an option to override - is there a flag I can add to force it without the key?
<james_w> but as kgoetz says #launchpad may be able to give you a pointer as they spend a lot of time trying to import from cvs
<james_w> axes: you can select what will provide the ssh somehow, I think an environment variable.
<james_w> kgoetz: aren't you supposed to be playing games? :-)
<kgoetz> james_w: i'm multitasking :)
<axes> james_w: I'm not on a personal computer, so I'd prefer to use the built in libraries - the windows installer packages this functionality, doesn't it?
<abentley> james_w, axes: Well, Launchpad uses cscvs, which is pretty stable, but not very friendly.
<james_w> ah, thanks abentley
<james_w> axes: are you using pageant?
<abentley> lifeless originally wrote it to import into Gnu Arch.
<axes> james_w: I'm not sure what I'm using, I haven't done any additional confiuration beyond installing.
<james_w> axes: I'm not familiar with the windows version, sorry, but I know that paramiko is used, so you are able to use different ssh client libraries.
<james_w> I don't know how it goes about finding and picking them on windows though
<james_w> axes: http://bazaar-vcs.org/Bzr_and_SSH might help you
<axes> james_w: I'm going to try and manually install the paramiko and pyCrypto packages now (I'd think they came with the installer, but maybe not).  Also, it seems odd that it gets as far as it does in the connection and then fails, if the problem is a lack of an SSH library
<james_w> oh, I don't think it's lack of a client.
<james_w> do you need a key to access the server?
<axes> james_w: The server should accept any key, I'm hoping it'll ask for a password
<axes> james_w: Now I'm getting an error saying that a procedure entry point was not found in cygcrypto-0.9.8.dll...
<james_w> ouch
<xma> hi #bzr
<blueyed> jelmer: I'm looking at improving bzr support in etckeeper (which has been added in Debian) and especially the pre-commit hook. Do you have something new about this? I've thought about shipping a bzr plugin with etckeeper, but that seems bulky..
<beuno> is there anyway to ask bzr log for "all commits after X revid"?
<frsk> Is bzr log -r x.. doing what you want?
<beuno> frsk, ah, it's bzr log revid:X...
<beuno> (not quite, but made me think, thanks)
<frsk> D'oh, forgot he revid-part
<frsk> the*
<NfNitLoop> Does anyone know if there is work being done on a Netbeans bzr plugin?
<NfNitLoop> I've seen some online sources that say "Well, Mercurial did it, so it shouldn't be too hard..."
<NfNitLoop> but nothing beyond that.
<beuno> NfNitLoop, not at the moment, no
<beuno> Verterok was looking into it, but I believe he doesn't currently have the time
<ubotu> New bug: #211967 in bzr "bzr smart server should support hooks" [Undecided,New] https://launchpad.net/bugs/211967
<NfNitLoop> I've been using Eclipse, but a project at work uses Netbeans and I miss bzr integration sorely. :)
<beuno> NfNitLoop, well, maybe if you ping Verterok, he might regain interest in it  :)
<NfNitLoop> Verterok: *ping*   ;)
<NfNitLoop> I dunno, maybe I'll get interested in it. : )
 * beuno hides
<beuno> NfNitLoop, well, if you do, Verterok can be very much of help to you, since he already went through the whole eclipse pain
<NfNitLoop> I could have the time, but as much as I'd like to be the steward of some cool OSS, I alway seem to end up doing something else. :p
<NfNitLoop> beuno: aah, he wrote the Eclipse one?  I use it.  It's nice. :)
<beuno> NfNitLoop, yeap, that's why he would be _the_ person to help you out with it
<NfNitLoop> I imagine I might take the same approach, use bzr-xml to read any data that gets returned, and just call the bzr command.
<tro> i dunno if there are any devs around, but BZR ROCKS. and THANKS! it works as i expect it to, which is rare
<beuno> tro, it would be great if you could send a mail to the list with a few reasons why
<NfNitLoop> tro: isn't it?   "Hey, it's featureful AND makes sense!"
<tro> i love how i just moved the entire repo with a single bzr push
<NfNitLoop> tro: tar works too.  ;)
<NfNitLoop> (and mv, while we're at it!)  :)
<tro> neat. i think the best part of it that i can unbind at any time and then rebind. i've got my repo on this really sucky slow server, so whenever it gets too slow, i just unbind, commit and bunch of revisions and bind/update/commit the next day
<NfNitLoop> tro: I pretty much stick to unbound dev, then push changes when I'm done.
<NfNitLoop> that way it's easy to keep my laptop, server & workstation all in sync.
<NfNitLoop> but checkouts are nice too. : )
<abentley> tro: Glad you like it.
<tro> NfNitLoop: i'm afraid of losing my changes, though, so i like to sync at least once a day
<tro> anyway. thanks, guys! *back to coding*
<db-keen> I've been using bzr branch and bzr push to work with svn repositories, I just noticed svn-import. Should I be using that instead of branch?
<bob2> only if you want to import the entire sn repository
<NfNitLoop> I assume if you branch from another svn-branch into a shared repo, it will share history (as much as svn allows?)
<NfNitLoop> (even if you didn't svn-import?)
<NfNitLoop> or, at least, I hope.  Since I've been working under that assumption.  ;)
<spiv> NfNitLoop: that's right
<blueyed> jelmer: around? (re: etckeeper)
#bzr 2008-04-05
<Verterok> NfNitLoop: pong (sorry for the delay)
<Verterok> NfNitLoop: still around?
<Verterok> beuno: thanks for the redirect ;-) (don't hide, if I can get some spare time, NetBeans is the next IDE to integrate:-D)
<NfNitLoop> Verterok: I'm around-ish. :)
<Verterok> Hi NfNitLoop
<NfNitLoop> H'lo.
<NfNitLoop> I don't know that I'll actually be writing (or even needing) a Netbeans bzr addon, I was mostly inquiring if anyone had started that work.
<Verterok> NfNitLoop: just to let you know, as part of bzr-eclipse  (but not coupled) I wrota  a Java library that wraps all the mechanics to call bzr-xml and it parsing
<NfNitLoop> aah, cool.
<NfNitLoop> so that would be portable, eh?
<NfNitLoop> It's not too tightly coupled to the eclipse APIs?
<Verterok> NfNitLoop: it's a standalone Java lib :-D
<NfNitLoop> ah, well then. :)  I'll be sure to keep it in mind should I become inspired to write an addon.  :)
<NfNitLoop> I use bzr-eclipse, though, in the meantime.  Good stuff.  :)
<NfNitLoop> Actually, while I've got your ear...
<Verterok> I started to look the NetBeans hg plugin, it's nice, but to adapt it to bzr, it need a major rewrite
<NfNitLoop> I set up eclipse to show a quickdiff with the latest bzr revision, but for some reason it seems to stop updating after i've committed.
<NfNitLoop> seen anything like that before?
<Verterok> NfNitLoop: Oh, Great you like it
<NfNitLoop> Yup!
<Verterok> oh, weird. could you fill a bug? :)
<NfNitLoop> Sure.
<NfNitLoop> I'll have to figure out how to reproduce it first. :)
<Verterok> I'm going to make a new build soon, maybe I can work on this before that
<NfNitLoop> 'k.     Well, I'm off to dinner.   *wave*
<Verterok> no problem, just fill the bug, I'll try to reproduce it
<jelmer> blueyed: hi
<Verterok> NfNitLoop: bon appÃ©tit
<jelmer> blueyed: the problem is, I have a plugin but there is no start-commit hook yet
<johnny> aha.. loggerhead fails on my .qs file
<TFKyle> .qs == ?
<johnny> quickstart
<johnny> since kickstart uses ks
<bob2> what is a quickstart
<johnny> an automated installer for gentoo, modeled after kickstart , which is an automated installer for fedora
<bob2> ah
<blueyed> jelmer: so the pre-commit hook cannot modify the tree (with calling "bzr add" or some such)?
<jelmer> blueyed: nope
<jelmer> blueyed: at that point the tree is already finished
<jelmer> blueyed: we need a new hook (in WorkingTree)
<johnny> yay for 500 errors :(
<blueyed> jelmer: ok, so I can put my half-assed plugin aside and get the package as good as possible for FFe (and to send it upstream, who has been very responsive).
 * johnny uses too many vcs
<johnny> now in one day, i have to use svn, bzr, git, mtn ,cvs :(
<blueyed> johnny: a lot of practice ;)
<johnny> even just contributing to make ltsp work in gentoo requires svn,bzr,and git
<johnny> if i was an official dev, i'd have to use cvs too
<johnny> most of my cvs is read.. not write atm luckily
<mxpxpod> I just committed some changes to my local repo that I'd like to uncommit, but still have the changes in the repo... will "uncommit" do that?
<mxpxpod> s/repo/branch/
<jelmer> blueyed: all the work in upstream is already done, it's bzr that needs patching
<jelmer> blueyed: not sure I understand what you mean
<blueyed> jelmer: for Ubuntu. bzr has been integrated in Debian, but there are still some issues and I've hoped I could add the pre-commit somehow, too.
<jelmer> blueyed: the pre-commit stuff isn't in debian yet either
<mxpxpod> jelmer: btw, bzr-svn rules
<mxpxpod> thanks for it
<jelmer> mxpxpod: thanks, that's good to hear
<jelmer> blueyed: bug 186422
<ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged] https://launchpad.net/bugs/186422
<mxpxpod> jelmer: I use it to track and develop all of my svn projects that don't have externals
<blueyed> jelmer: I've seen that bug already.. (and your work on it, which suddenly stopped)
<jelmer> mxpxpod: hopefully externals will be supported soon too, once bzr itself supports nested trees
<blueyed> jelmer: I've tried bzr-svn, too, but it had serious memory problems (which I have worked around).
<jelmer> blueyed: most of those should be fixed in hardy
<mxpxpod> the only thing I wish I could do would be to get svn revision numbers along-side bzr revision numbers in the log
<blueyed> jelmer: great to hear.
<jelmer> blueyed: the bugs were actually in python-subversion
<jelmer> blueyed: is it likely that bzr 1.4 will make it into hardy? If so, I could probably have a look at getting that start-commit hook in..
<jdong> jelmer: when is it to be released?
<blueyed> jelmer: 1.3 has just been released, not?
<blueyed> ..and the rc for 1.3.1
<blueyed> jelmer: so, quite unlikely
<jelmer> jdong: 1.4rc1 is planned for next friday
<jdong> jelmer: hmm if Debian can get their packages for 1.4 up soon after that I would try filing a freeze exception for it...
<jdong> jelmer: but I think the release managers may be a bit gunshy after the 1.3->1.3.1 thing... :(
<blueyed> jelmer: if you have the time, please try getting hook improvements in.
<jelmer> Hmm, there's no mutabletree tests?
<abentley> jelmer: Nope, you can do anything you like to 'em.
<abentley> That's what makes them so mutable :-)
<jelmer> abentley: lol
<blueyed> jelmer: nice, thanks! Those hooks get installed like the current ones, as a plugin, correct?
<jelmer> blueyed: yes, and the matching plugin is already in my etckeeper git repository
<jelmer> blueyed: hmm, it looks like upstream merged another branch that adds support for bzr
<blueyed> jelmer: yes, it has been submitted in LP and I've forwarded it.. it's quite the same though.
<blueyed> I have some fixes laying around here, and looked at your branch also.. I'll try to submit it tomorrow..
<blueyed> Good night.
<ubotu> New bug: #212083 in bzr-gtk "viz displays wrong revnos, tries to display NULL revision" [Undecided,New] https://launchpad.net/bugs/212083
<chandlerc> jelmer: you around? i filed the 170000 exception bug... investigating stuff now
<xma> hello #bzr
<cammoblammo> I've noticed when I commit a change --- even a small one --- to an upstream repository via ftp there seems to be a fairly large download from the repo. Is this normal?
<Peng> Are you using a lightweight checkout? That would make it worse than usual.
<Peng> Is upstream using the latest disk format (packs)?
<Peng> Also, the smart server would provide better performance.
<Peng> (Also, FTP? Ew.)
<cammoblammo> It's a full checkout, rich-root-pack.
<cammoblammo> The repo is on the 60 MB of free web space I get with my ISP, ftp only.
<cammoblammo> I haven't looked to see if I can get the server running, but I very much doubt I'd be able to.
<Peng> Yeah, if you only have FTP access, that's very unlikely.
<Peng> It would be quite easy if you had SSH, but...
<cammoblammo> I'll pony up for a real web server one day.
<Peng> If it's a FOSS project, you could host it on Launchpad. https://launchpad.net/
<Peng> cammoblammo: You don't need a real web server. You could get the smart server running on many shared hosts, if they provided SSH. Even just using nice, encrypted SFTP would be better than FTP...
<cammoblammo> Unfortunately, it's not. It's mainly papers written in LaTeX, music written in LilyPond and other things with weirdly capitalised names.
<cammoblammo> They don't have ssh. That was the first thing I asked when I signed up. You get what you pay for, I guess.
<Peng> Oh, what bzr version? Performance has gotten better over time.
<cammoblammo> bzr version 1.3. I suppose it doesn't get too much better than that!
<Peng> :)
<cammoblammo> It does seem to have improved since 1.2
<cammoblammo> What's the download for? Does it have to compare with what the repo has before it commits?
<Peng> Yes.
<Peng> It also has to upload the new data, of course.
<Peng> Pack repos also have to be repacked occasionally, which requires downloading a portion of the history and uploading it again.
<cammoblammo> Of course, Then again, a 1 or 2 MB download in order to upload a 3kb diff seems a little unproportional. This is probably the only complaint I have after moving from svn.
<Peng> How large is the branch?
<cammoblammo> Peng: According to bzr info -v it's 13436 KiB
<Peng> Downloading 1 to 2 MB sounds bad.
<Peng> I'm not a bzr expert, so I can't be of any more help..
<cammoblammo> Feels bad too, especially when my office shares a 256 kbps 'net connection, and two other workers are using heavy web apps. I can be very unpopular sometimes!
<Peng> Ouch.
<cammoblammo> Peng: That's cool. I just wanted to make sure it was normal and the problem was my braindead way of having to use it.
<Peng> It surprises me, but I'm really not an expert. I doubt you're doing anything wrong.
<cammoblammo> Tell my coworkers that ;-)
<Peng> At least you're not running BitTorrent. ;)
<cammoblammo> Peng: True. In fact, we have a 600 MB per month limit on our connection, after which we pay something like a dollar a meg. Our corporate headquarters assures us it's all we need.
<cammoblammo> Peng: It's not all /I/ need, though.
<Peng> Wow.
<Peng> Um.
<Peng> Where did you find this ISP?
<Peng> Or are you in Nowhere, Africa where the nearest power line is 500 miles away?
<cammoblammo> Peng: I didn't find it. It was in the memo that came from HQ, along with a modem/router, instructions to install it and a phone number to ring to get our IT department to pcAnywhere in so they could get us on the VPN properly.
<cammoblammo> Peng: I live in the country, but the same thing goes for offices in metropolitan Melbourne.
<cammoblammo> Peng: 'Information Technology' is something of a misnomer.
<Peng> You could each chip in like $10 and get a real Internet connection for the office. :P
<cammoblammo> We could, but then we'd lose the 10.x.x.x IP addresses we've been so lovingly given in order to connect to our 'precious' web apps. Besides, they'd have to authorise the release of the line from our ISP and they'd keep charging us $25 p/m!
<cammoblammo> If they ever found the GNU/Linux computer in my office, there could be some real trouble...
<Peng> It must be technically possible to get a real connection, use it for the outside, and keep the old one for the corporate stuff.
<Peng> But anyway...
<Peng> The company sounds pretty cheap. Do you have cardboard desks too? :\
<cammoblammo> Peng: You'd think so. Getting another connection is a bit of work, and the only reason we really need it is so I can use bzr, which is officially verboten anyway. It'll be easier and cheaper to move my repo to a better hosting service.
<asabil> cammoblammo: ftp, sftp and rsync are dumb transports
<cammoblammo> asabil: That's very true.
<asabil> so they are not really efficient, and iirc bzr repositories are not append only (correct me if I am wrong)
<asabil> the best you could do is move the repository to a host that has an ssh connection, so that you can use the bzr+ssh transport
<cammoblammo> asabil: I think you're right, unfortunately. If my ISP used ssh it would be nice, but they don't seem to see the need. It's free space, after all.
<asabil> cammoblammo: you can also try bzr init --append-revisions-only
<asabil> never used it, but it seems to force an append only repository similar to mercurial's
<cammoblammo> asabil: I'm guessing functionality is lost? Or am I reading the help wrong?
<asabil> yes you might lose some functionality
<asabil> an uncommit followed by a push won't work
<Peng> I doubt that would help.
<asabil> a push --overwrite won't work either I think
<Peng> I expect that has to do with history, not files.
<Peng> It's not like it would use a completely different repo format.
<Peng> And if for some reason it turned off repacking, that would be awful for performance.
<asabil> right
<asabil> cammoblammo: do you have to host your code somewhere else ?
<asabil> I mean you can still use a local server in your office
<asabil> can't you ?
<cammoblammo> asabil: I can host it at home, but it would be nice to have it offsite somewhere. I'm still thinking in svn term, though. There's no reason why my home branch couldn't be a notional 'repository' and still have my host for backups and uploading when I'm on holiday.
<asabil> yep
<asabil> or you can also use some other machine in your office
<cammoblammo> I can't connect to the office from outside --- everything's firewalled up the wazoo. Their ISP policy might be crap but the security's pretty tight.
<asabil> do you need to connect to the office from outside ?
<asabil> I mean, if I understood it correctly, you just need a hosting for backup purposes
<asabil> and you are the only one working on that branch
<asabil> right ?
<cammoblammo> I should mention that I do most of my work from home. I only have a branch at the office for convenience. It's largely work related, but I can choose where I work!
<asabil> yes that's fine, just create a branch on your laptop for example
<asabil> and when you get to the office push the branch to your backup server
<asabil> and keep working on your own branch on your laptop
<cammoblammo> I could just have a branch on my USB drive. When I moved house a few weeks ago and I was without a connection that worked quite well.
<cammoblammo> My laptop... well, it's pretty crusty and I only use it when I'm away.
<Bronger> I added "http://ppa.launchpad.net/bzr/ubuntu" to my repositories, however, synaptic reports that some packages are unauthorized.  Which keys must I add in order to avoid this message?  I added the key of the uploader (mpl) but this didn't help.
<yacc> Bronger: apt-get update should tell you the key ids.
<yacc> Bronger: after that you can use gpg to fetch these from the keyservers.
<Bronger> Yes, I know this procedure.  It worked well for bzr-svn.
<yacc> Bronger: now, that is critical, call the key owner to verify the fingerprint :-P
<yacc> Bronger: after that you export the key from the gpg keyring and add it with apt-jet
<yacc> apt-key
<Bronger> A second source that is a simple server which is improbable to be hacked is enough.  ;-)
<Bronger> yacc, apt-get just tells me that there aren't any updates.  Isn't there a possibilitry to just give a URL and Ubuntu tells me with which ID it it signed so that I can look for this ID on the net?
<yacc> apt-get install package should also complain :-P
<Bronger> Yes, but only that it couldn't be authenticated.  Isn't it signed at all?
<yacc> Bronger: that's theoretically possible too.
<yacc> you could also make apt-get refetch the data and recomplain, using such a standard tool like rm :-P
<james_w> Bronger: the packages aren't signed at all yet unfortunately
<ubotu> New bug: #212193 in bzr "bzr crashed while pushing" [Undecided,New] https://launchpad.net/bugs/212193
<ubotu> New bug: #212195 in bzr "Cannot use backslash character in file name" [Undecided,New] https://launchpad.net/bugs/212195
<Stavros> hello
<Stavros> is there a good writeup of branching/merging with bzr?
<Stavros> i want to make a branch for a feature i'm working on
<xma> bzr branch <fom> my-feature
<xma> from
<xma> hack hack hack commit
<xma> cd from
<xma> bzr merge ../my-feature
<xma> comit
<Stavros> ah, that's all? thanks
<Stavros> and do i need to keep that branch for further hacking?
<Stavros> or do i need to rebranch after the merge or something?
<Peng> You can do what you want.
<Peng> You can just delete the branch if you want to.
<Peng> You can "cd my-feature && bzr merge ../from && bzr commit -m 'Merge from from' && hack hack hack" and eventually merge it back into from again.
<bimberi> Stavros: This helped the penny drop for me:
<bimberi> Stavros: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#organizing-branches
<Stavros> aha, hmm, well, i'm wondering how the graph will look in that case
<Stavros> ah, i'll read that, thanks
<bimberi> np
<bimberi> although i did read everything before it first :)
<Stavros> haha
<Stavros> i'll try that too, then :p
<Stavros> just to get this straight, when you are working on a feature branch, you "merge" instead of "pushing" because the branches might have diverged, correct?
<Peng> When the branches have diverged, you merge. When they have not, you push/pull.
<Peng> If you try to do the wrong thing, bzr will tell you.
<jelmer> chandlerc: ping
<Stavros> Peng: great, that's what i needed to know, thanks
<ubotu> New bug: #212289 in bzr "test_diff.TestDiffFromTool.test_prepare_files fails on Windows" [Undecided,New] https://launchpad.net/bugs/212289
<abentley> asabil: Logically, all bazaar repositories are append-only.  Physically, knit repositories are append-only and pack repositories are write-once.
<abentley> Physically on the file level, that is.
<asabil> oh oki, didn't know
<asabil> thanks
<ubotu> New bug: #212325 in bzr-pqm "Should support pqm_cc / pqm_bcc settings" [Undecided,New] https://launchpad.net/bugs/212325
<Stavros> hmm, bzr always gives me trouble updating tags, anyone know why that is?
<ubotu> New bug: #212333 in bzr-pqm "Doesn't expand directory services in URLs" [Undecided,New] https://launchpad.net/bugs/212333
<Bronger> Can one just use the GNU Arch functionality of Savannah.gnu.org to manage Bazaar branches?
<jelmer> Bronger: what sort of gnu arch-specific stuff does savannah support?
<Bronger> Actuall I don't understand really what's there on the server side. http://lists.gnu.org/archive/html/savannah-hackers-public/2008-03/msg00033.html suggests that I already can use Bazaar on Savannah.  But Bazaar is *nowehere* mentioned on the site.  I can only activate GNU Arch services for a particular project.
<Bronger> And, I don't know how similar Arch and Bazaar are so that support for one implies support for the other as well.
<jelmer> Bronger: it looks like the arch support is simply a sftp server
<jelmer> Bronger: if that is the case, you should be able to use bzr with it as well
<Bronger> Okay, thank you!  So far, I've used Bazaar in remote operation only with Launchpad.  Let's see whether I manage this sftp thing, too.  ;-)
<BeeUteefool> hello
<BeeUteefool> what does it mean if someone says  Patch against bzr?
<sabdfl> BeeUteefool: can you give some more context?
<BeeUteefool>     * GNOME_Desktop_User_Guide_Inconsistency, changed group to layout (922 bytes, text/plain)
<BeeUteefool> Fixed this in gnome-user-docs.
<BeeUteefool> Patch against bzr.
<BeeUteefool> please visit this link so that you'll get more context...    https://bugs.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/205140
<ubotu> Launchpad bug 205140 in gnome-user-docs "'GNOME Desktop User Guide' Inconsistency" [Undecided,Confirmed]
<BeeUteefool> so what does it mean this   Patch against bzr?
<abadger1999> With 1.3, is anyone seeing "ssh: connect to host bzr.fedorahosted.org port 22: Connection timed out"
<abadger1999> I've been seeing this since upgrading.  I've also had bzr just hang somewhere near the start of a pull... I'm wondering if it's all related.
<abadger1999> hmm.... and it looks like bzr-webserver works with bzr-1.2 but not bzr-1.3 :-(
<xif> Hi
<xif> I'm trying to push to an SVN repo with bzr
<xif> but I get "Unable to handle http code 401: Authorization Required"
<xif> anyone knows how to handle this?
<yacc> xif: include user+password in the URL?
<yacc> svn+http://user:password@hostname/path
<xif> bzr: ERROR: Invalid url supplied to transport:
<xif> it treats the : as a port number.
<yacc> xif: don't think so, I'm using the same format, albeit with https.
<xif> bzr: ERROR: Invalid url supplied to transport: "invalid port number
<yacc> xif: OTOH, you might have some specific "values" in your URL.
<yacc> Try:
<yacc> Access it via svn:
<yacc> svn ls http://....
<yacc> make svn remember the password
<yacc> try bzr with username but without password
<xif> yacc: doesn't work :/
<xif> `svn ls` works just fine
<xif> bzr without user+password doesn't work
<yacc> xif: jelmer is your best bet then :-P
<yacc> Well, you need to specify the user for sure.
<xif> I think I found the possible cause of the problem though
<yacc> Yes?
<xif> my username contains a @
<xif> any idea how to fix that?
<xif> (this seems to be a cause for the parsing error above)
<jelmer> xif: hi
<xif> hello jelmer
<jelmer> xif: try without including the username + password in the url
<xif> bzr: ERROR: Invalid http response for http://svn.devjavu.com/xif/linux_settings/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<jelmer> please prefix the url with svn+
<jelmer> (svn+http://svn.devjavu.com/...)
<xif> OK, sec
<xif> I'm in the middle of upgrading bzr+bzr-svn
<xif>  bzr-svn: Depends: python-central (>= 0.6) but 0.5.15ubuntu2 is to be installed
<jelmer> what distro?
<xif> Ubuntu Gutsy
<xif> the problem is that the most up-to-date python-central for Gutsy is 0.5.15
<jelmer> I think there are quite recent versions in gutsy-backports
<jelmer> of bzr and bzr-svn
<xif> jelmer: OK, any idea how I install it from there?
<xif> I do have latest stable bzr installed
<xif> OK, found it
<jdong> jelmer: thanks for reminding me; need to get bzr 1.3.1-ish backports going :)
<sabdfl> BeeUteefool: i think it means someone has a patch which applies against the tip of a bzr branch
<sabdfl> it's an odd way to work, because it would be easier to have their work in a bzr branch
<xif> OK, nothing works
<jelmer> xif: installing the packages you mean?
<xif> jelmer: yeah, I get the same error after adding gutsy backports to the sources.list
<jelmer> xif: about python-central you mean?
<xif> needs python-central >= 0.6, only has 0.5.15
<xif> yup.
<jelmer> xif: Do you happen to have any other entrise in sources.list, such as ppa?
<xif> yes
<xif> deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
<xif> deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
<xif> maybe I should have just stayed with bzr 0.9?
<xif> (the latest in Gutsy's repositories)
<xif> trying to upgrade seems to put me in a worse position than I was.
<jelmer> you mean 0.90?
<xif> yes
<jdong> xif: the PPA tends to be out-of-sync a lot more often than backports
<xif> so what should I do?
<xif> remove all the PPA entries and try to install from backports?
<jelmer> xif: It'll probably work better if you remove PPA
<xif> k, trying
<jdong> xif: yeah, I recommend removing the PPA entires and using Backports
<jelmer> xif: I can only upload to the hardy PPA
<jelmer> xif: I think the gutsy one is at least a couple of versions behind
<xif> OK, be advised that the latest bar in backports is 1.0-1~gutsy1
<xif> installing that right now.
<xif> OK, I downgraded to 0.90 again
<xif> jelmer: tried the following:
<xif>  bzr svn-push svn+http://svn.devjavu.com/xif/linux_settings
<xif> result:
<xif>  bzr: ERROR: libsvn._core.SubversionException: ("Undefined tunnel scheme 'http'", 125002)
<xif> I think maybe I should save some time and just use SVN.
<jelmer> xif: and with "bzr push" rather than "bzr svn-push" ?
<xif> jelmer: same error.
<xif> jelmer: (note that I'm on 0.90 again)
<xif> OK, I already spend two hours on this.
<xif> investing more time in this doesn't seem logical, but thanks jelmer.
<johnny> don't go with svn :(
<xif> johnny: it's not like I have much choice, I need to commit to a remote SVN server.
<johnny> uggh.
<johnny> lots of the gnome folks are so irritated with svn, they are creating their own git repositories and committing to that for their own work,and then running some script to convert to svn
<johnny> kinda silly :(
<xif> well, the best option for me would have been to keep using my bzr repo and commit from it.
<xif> except it doesn't work.
<yacc> johnny: it's silly and then not so, svn being the lowest common denominator, that is needed for a somewhat modern VCS (atomic file set changes, but missing some metadata, notice how each of the SVN interoperability tools tend to define and use their own merging properties, e.g. svk, bzr-svn)
<johnny> sure, but i'm used to using other vcs for my upstream work :)
<johnny> so working with svn still feels uncomfortable due to lack of local history
<yacc> johnny: I always use svk with svn, it's relationship with svn being way stronger than say bzr-svn, it basically works.
<yacc> If you can wait the 2secs or so perl takes to compile SVK on each command
<johnny> i've been using monotone for quite some time, never saw a reason to use svk i guess
<johnny> and use svn for my own stuff in the process that is
<jelmer> yacc: you mean because it doesn't have the branching scheme stuff or other things as well?
<ubotu> New bug: #212477 in bzr "bzr init-repo over sftp fails" [Undecided,New] https://launchpad.net/bugs/212477
<xif> johnny: you know, SVN ain't so bad
<xif> obviously it sucks when you don't have server access.
<xif> and it would be great to sync only when I want to.
<xif> but as long as the intertubes work...
<Peng> Except for the lack of renames, linear history, bad performance (or so I've heard; FSFS's file layout isn't good though), bad disk space use...
<Peng> Apparently the API is ok though, or else jelmer would have long gone insane working on bzr-svn. ;)
<yacc> Peng: Not sure if he hasn't gone insane :-P
<Peng> Well, he *does* only use one space in between sentences.
<yacc> jelmer: my comment was "pragmatic". Svn is "simple enough" that even sub-average developers can somehow use it, and most more advanced VCS have some form to interoperate with svn. And svk makes it bearable in practice.
<Peng> Even more bearable would be using any of the other VCSes...
<Peng> But, I don't know what the conversation has been.
<Peng> I just like insulting svn. :)
<jelmer> yacc: I meant more in terms of comparison between bzr-svn and svk
<stefan_today> I'm just starting out with bzr.  We're two people with laptops and we'd like to follow the "partner" workflow described at http://bazaar-vcs.org/Workflows is there a more detailed howto for that?
<stefan_today> i.e. what commands to enter, what our choice of transports are (we'd like to use email or I'm) but can't seem to make "bzr send" work ("no submit branch known or specified")
<stefan_today> er, "or IM"  :-)
<bimberi> stefan_today: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sharing-with-peers
<bimberi> stefan_today: and http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sending-changes
<beuno> stefan_today, you can do bzr send -o file.patch
<beuno> and email the file to eachother
<bimberi> (which is basically what the 2nd link says)  ;)
<beuno> jelmer, around?
<stefan_today> so the "no submit branch known or specified" message is ignorable?
<beuno> stefan_today, well, it depends
<beuno> the workflow I usually have
<beuno> is branch trunk (or whatever you are working on)
<beuno> then, branch that locally to a "feature branch"
<beuno> so, there you have a submit branch to compare against
<stefan_today> the submit branch being your first local branch?  does the recipient of that merge directive need to have access to trunk?
<beuno> stefan_today, yes, the sumbit branch will automatically be the first local branch (where you branched from)
<beuno> the other recipient oes not have to have access to trunk, no. He recieves a standard patch with some bzr metadata that he can use to merge, if he has a branch with common ancestry
<stefan_today> ok, so if one of us were to zip up and send a branch (including .bzr directory) to the other as a starting point, we could each branch from that original branch (so we have common history) and email merge directives back and forth thereafter?
<beuno> stefan_today, yeap, exactly
<jelmer> beuno: hi
<beuno> jelmer, hey  :)
<beuno> I was thinking about starting to cook up something like we talked about in the sprint, about having easier collaboration in a network
<beuno> have one screen where you see everybody in the network, what they are working on, etc
<beuno> using avahi and al that magic
<jelmer> beuno: ah, something like  a GUI for avahi?
<beuno> jelmer, exactly
<jelmer> jamesh may have some thoughts about that
<beuno> do you think I should work on it as part of bzr-gtk or a seperate project?
<stefan_today> cool, we're up and running.  thanks beuno.  thanks bimberi
<beuno> stefan_today, welcome and good luck  :)
<jelmer> beuno: doing it as part of bzr-gtk sounds sensible (if it's going to be gtk based :-)
<beuno> jelmer, absolutely, pygtk
<jelmer> as long as bzr-gtk doesn't get a hard dependency on bzr-avahi, but that shouldn't be hard
<beuno> jelmer, I'll do my best. And if it does, I'll just seperate it
#bzr 2008-04-06
<nysin> I've tried importing an svn repository using svn-import of the bzr-svn plugin via bzr 1.3 using both the none and branch schemes, and it doesn't seem to preserve history across what were svn cp's
<floam> is there anything fairly easy one can do to automatically get the revision number into a controlled source file on commits?
<jelmer> nysin: that's correct, bzr does not support copy tracking
<floam> what I did now is I have version = 120 in one of my files that I try to remember to manually increment each time -- but it's a losing battle
<nysin> Oh. I took "Follow branch copies. Revision history is not truncated when a branch was copied in Subversion." from the BzrForeignBranches page to mean something else?
<jelmer> nysin: that's copies of branches, not copies of directories or files
<nysin> Ah, alright.
<nysin> Which means that it doesn't matter which branching scheme svn-import uses with regards to intra-repository history tracking?
<nysin> (The reason I tried to use scheme=none was to get that history)
<jelmer> nysin: yes
<nysin> Okay, thanks.
<jelmer> nysin: Or perhaps, another way to look at it is
<jelmer> nysin: only copies of the root of a branch are tracked
<jelmer> nysin: so if you copied /branches/foo to /trunk and you use scheme=trunk, bzr will keep the history of that branch
<jelmer> nysin: if you use scheme=trunk and you copied /trunk/foo to /trunk/bar, that will not be tracked
<nysin> Hm. That's more or less what I did. The former.
<nysin> But I guess not via a branch.
<nysin> It started as /svn/trunk, then a big change happened, so I split off that version to /svn/branches/foo and branches/bar
<nysin> And then finally branches/bar back to /trunk when it stabilized
<nysin> But it was all via svn copy
<jelmer> it should show all history for that then
<nysin> How might I determine why it isn't, then?
<nysin> Or, maybe it is an I'm missing it somehow
<jelmer> is this a public repository?
<nysin> The svn is, yeah
<nysin> URL in a moment. bzr is all local so far
<nysin> http://colon.ath.cx:8008/svn/ should work
 * jelmer tries with bzr-svn 0.4.9
<nysin>  /trunk/foo is branches/wtl
<nysin>  /trunk/bar is branches/smartwin
<nysin> er /branches/... for the first two in those
<nysin> Oh, yeah, and that's the bzr-svn version I was using too, from Debian unstable.
<nysin> ScriptManager.{cpp,h} as well as the scripts/ directory are files that should have retained a history amongst the longest...
<jelmer> nysin: branches/wtl and branches/smartwin are unrelated in that svn repository
<nysin> yes
<nysin> wtl should have no offspring to speak of
<jelmer> nysin: where exactly were you expecting it keep history but it isn't?
<nysin> Alright, for example the scripts directory
<nysin> which was copied around unchanged from one part to another
<jelmer> from wtl into smartwin you mean?
<nysin> As well as trunk/ from smartwin/, which is just a big scp copy
<nysin> yes
<nysin> er
<nysin> svn copy
<jelmer> nysin: that's a directory copy though
<nysin> Which you said wasn't covered, yes
<jelmer> nysin: not a branch copy
<nysin> I guess I wasn't clear on that distinction whilst using svn - it worked about as well either way
<jelmer> the copy from /branches/smartwin to /trunk appears to be picked up correctly here with history retained
<nysin> hm.
<jelmer> nysin: svn doesn't have a notion of branches
<jelmer> which is one of its strongest advantages and one of its weaknesses :-)
<nysin> Yeah, and its documentation discusses copies as 'light branches' of sorts
<nysin> I really like that
<nysin> Verifying locally though
<nysin> the history...
<nysin> Yeah I don't see it
<nysin> "bzr log formatting.lua" has only one entry
<nysin> in trunk.
<jelmer> nysin: that's correct, because it was introduced by a directory copy (r820)
<nysin> Yeah, which you said before etc. I had accepted that and then I got confused when you said you did in fact see some cross-branch history preserved
<jelmer> nysin: right, with copies such as the one in r818 history is preserved
<nysin> Alright, but when I actually go and check that in the wtl directory...
<nysin> branches/wtl$ bzr log --short changelog.txt
<nysin>   818 cologic   2008-01-18
<nysin>       archive WTL 0.699d version
<nysin> And that's it
<nysin> It did have a history before that..
<jelmer> nysin: I mean r818 in svn
<nysin> Yeah my current bzr is no-branches so they match revision-wise
<nysin> svn818 is the trunk -> wtl branch in both repositories specifically.
<nysin> or bzr818
<nysin> But regardless, I'm trying to see what history you're saying it's preserving? I might be missing something there
<jelmer> That's only true for scheme=trunk
<jelmer> Which causes /trunk and /branches/wtl to both be considered branches
<nysin> hm? scheme=trunk produced local revision #s
<jelmer> revision numbers are per-branch in bzr
<nysin> Sure, so they weren't going to match svn. Which is fine and all, but just means that I don't see what correspondence you say works with and only with scheme=branch?
<jelmer> history preservation only works when copying branches
<jelmer> scheme=trunk causes "/trunk" and /branches/* to be considered branches
<jelmer> scheme=none considers "" to be considered a branch
<nysin> ah
<nysin> Now it makes sense
<jelmer> s/considered//
<nysin> I've been looking at the no-branch version (I archived both so I'll go look at the branching version now...)
<nysin> ahh
<nysin> Much better.
<jelmer> It would be nice if bzr could support file copy tracking at some point, even if just for log and annotate
<nysin> When I was Googling I found some mailing list messages all the way back from the 0.10 era agreeing with that
<nysin> And, especially, since svn at least does treat copies as 'branches' of sorts, then it seems pretty useful.
<nysin> Oh, there's even a spec on it ( https://launchpad.net/bzr/+spec/filecopies ) which gets at the usage scenarios
<tro> i swear i got bazaar to include the diff in the commit note (in the ignored section) somehow, but i can't remember how i did it :/
<tro> is it a config option?
<beuno> tro, just do bzr commit
<beuno> without -m
<beuno> ah, no, wait
<tro> all i get is the modified files list
<beuno> yes, that's right
<tro> bzr ci --show-diff
<tro> aha
<Stavros> why is bzr always telling me about conflicting tags? i just moved the tag, i want it to be moved on the remote branch as well
<Stavros> sorry, i left by mistake
<spiv> Stavros: push --overwrite
<Stavros> o
<Stavros> hmm, thanks
<Stavros> shouldn't that be done normally, though?
<spiv> Stavros: bzr won't overwrite a tag by default, because it doesn't know which one is the one you want to use.
<Stavros> oh
<Stavros> so it doesn't save the change of the tag as well, huh..
<ubotu> New bug: #212645 in bzr-svn "cannot import name CachingParentsProvider" [Undecided,New] https://launchpad.net/bugs/212645
<ubotu> New bug: #212649 in trac-bzr "Viewing a changeset in trac 0.11 produces traceback" [Undecided,New] https://launchpad.net/bugs/212649
<cammoblammo> What are the differences between bzr branch, clone and get?
<mwhudson> there are none
<spiv> cammoblammo: $ bzr help branch | grep Aliases
<spiv> Aliases:  get, clone
<spiv> cammoblammo: they're all the same command
<cammoblammo> Ah. I thought I saw that somewhere, but I couldn't find it!
<cammoblammo> Thanks
<cammoblammo> I've got an existing working branch that I want to turn into a shared repository without the tree. What's the canonical way to do it (or can I just copy the branch and remove all the non .bzr directroies?)
<spiv> cammoblammo: branch it into a shared repository (initialise the repo with "bzr init-repo --no-trees PATH")
<cammoblammo> That's what I thought. I wasn't sure if that worked for already existing repositories.
<cammoblammo> Okay. I successfully tried "bzr init-repo --no-trees --rich-root-pack SharedRepo"
<cammoblammo> However, "bzr branch OldRepo SharedRepo" complains that the repo exists already. But of course it does...
<cammoblammo> Hang on, shouldn't I be using the import command?
<cammoblammo> Don't worry folks, I'm having a brain fart. I've figured it out, and yes I am embarrassed.
<cammoblammo> ;-)
<exothermc_> does bzr preserve perms and ownership?
<bob2> no
<bob2> alas
<exothermc_> bah looking for a good solution to manage my server config files such as /etc
<exothermc_> svn does it but only with a wrapper
<bob2> etckeeper
<bob2> (which layers on top of bzr)
<exothermc_> ahh ok
<exothermc_> does it hook into rpm as well?
<bob2> dunno
<exothermc_> one last question do newly created files and dirs get automatically added to the repository?  also are deletes removed?
<cammoblammo> Can an existing branch be turned into a --no-trees cwntral repo?
<bob2> exothermc_: bzr records deletions automatically, but not additions
<bob2> not sure what etckeeper does on top of that
<exothermc_> ok
<bob2> cammoblammo: not, afaict, through the ui
<bob2> cammoblammo: bzr reconfigure --no-trees would get rid of the working copy, though
<bob2> cammoblammo: is the branch just too big for you to create the repository and then branch into it?
<cammoblammo> I'm trying to reconfigure my set up so I can put my repo on a server at home rather than the free piece of rubbish my ISP gives me (no ssh, etc.)
<bob2> ok
<bob2> so, is "bzr init-repo --no-trees --rich-root-pack repo ; bzr branch /your/branch repo/branch" what you wany?
<cammoblammo> Something like that. I did try that sort of thing, but I had problems. I'll try it again and see if it an operator error ;-)
<cammoblammo> Hm, same thing. I end up with a treeless version of my branch in a directory in the repo.
<cammoblammo> So it looks something like /home/cammoblammo/repo/branch/.bzr
<cammoblammo> With a .bzr in the /repo directory as well.
<spiv> cammoblammo: isn't that what you're after?
<cammoblammo> Not quite. I was after /home/cammoblammo/repo/.bzr without anything else in there. That's how my current repo at my ISP looks.
<bob2> standalone repos always have .bzr in the root and in the branch...
<bob2> what you have at your isp looks like it's just a standalone branch with no working tree...
<cammoblammo> That's what I'm trying to get here. Isn't that how it's supposed to look?
<bob2> not if you want a shared repository
<bob2> what was your original goal (i.e. not "make it look like the existing one")?
<cammoblammo> I need to be able to access my repo from work. I used to run a svn server here at home, but when I changed to bzr I moved the repo to my ISP to save space on my home machine (not to mention give me more reliable access when I'm on the road). The ISP only lets me use ftp, though, which is a big performance hit. I want to move it back to try using bzr+ssh.
<bob2> ok
<bob2> sounds like a shared repository would work well for you.  'bzr init-repo --no-trees repo', then branch things into it.  the branches will be in subdirs under repo (and have their own, small .bzr dirs), but all the revision data gets store in repo/.bzr, so it's not duplicated.
<cammoblammo> Well, if that's what I have to do ;-) It will look a bit silly though --- I'm only running one branch. Of course, I don't have to look at it, do I?
<bob2> ah, ok, now I understand
<cammoblammo> As another thought, will it work if I just copy the directory at my ISP? It's probably dirty, but...
<bob2> don't make a repo then, just create a branch
<bob2> that will work fine
<cammoblammo> Out of interest, is there any reason I shouldn't just copy the repo over?
<bob2> btw, "repo"  is generally used to mean something else (what init-repo produces) in relation to bzr, hence my confusion earlier
<bob2> sure, you can copy it over
<cammoblammo> Oh well then, problem solved! I've never seen that sort of approach mentioned in the docs, so I figured it must be discouraged for some reason. Then again, that's how I got it to the ISP in the first place.
<bob2> "bzr branch /home/cammoblammo/repo/ ftp://blahblah" should just work, as well
<cammoblammo> Hmm, let's see...
 * cammoblammo is waiting very patiently...!
<cammoblammo> Well, something's coming down the tubes...
<cammoblammo> bob2: It worked, but it wasn't treeless, even though I initialised the repo that way. Oh well.
<bob2> oops - bzr reconfigure --branch ftp://...
<cammoblammo> bob2: Yeah, I picked up on that.
<cammoblammo> Hang on, no I didn't.
<cammoblammo> Let me see now...
<cammoblammo> Well, close! I took a copy of a standard working branch and ran the reconfigure command over it and it worked.
<cammoblammo> Now for another problem :-( !
<bob2> ok
<cammoblammo> I can check the shiny new repo out locally, but via bzr+ssh I get a problem: ERROR: Repository KnitPackRepository(local details) is not compatible with Repository RemoteRepository(Repo details)
<bob2> what does "bzr info" say when run in the same location that is giving you that error?
<cammoblammo> Do I have to change the repository format?
<bob2> ?
<cammoblammo> Sorry, missed your message. One sec...
<cammoblammo> Bound branch format: pack-0.92
<cammoblammo> The repo (if I can use that word) is rich-root-pack.
<bob2> that's the entire output?
<bob2> the related branch part isn't important
<cammoblammo> Yes, apart from the Location and binding info.
<bob2> whici is what I wanted to se...
<cammoblammo> Oops. One tic...
<cammoblammo> branch root: .
<bob2> the error could be because you're inside a repo made with init-repo, or it could be because you're co'ing from rich-root-pack
<cammoblammo> Hmm. I'm trying a clean checkout, so I'm not inside anything relevant (and I did check that).
<cammoblammo> Is there a problem co'ing from a rich-root-pack?
<bob2> ah, ok.  it's because co has a bug and uses the bzr default format for the checkout, instead of the remote branch format
<cammoblammo> Yay me! I didn't do something wrong (for once). Is there a work around, or do I have to somehow reconfigure the repo?
<bob2> you can either: "bzr branch ftp:/// foo ; bzr reconfigure --checkout foo" or "bzr init-repo --rich-root-pack repo ; bzr branch ftp:// repo/blah" wwwwwwwwww
<bob2> note that rich-root-pack is generally only useful if the branch came from svn (or you're z bzr developer)
<cammoblammo> Really? Someone here told me it was now the default and I should upgrade.
<cammoblammo> Grr.
<cammoblammo> Anyway, let's give it a go...
<bob2> default's still pack-0.2 afaik
<cammoblammo> Don't believe everything you see on IRC!
<luks> you can generalize that to The Internet :)
<cammoblammo> ;-)
<cammoblammo> Actually, you can generalise that to anything involving, well, anything.
<cammoblammo> Guess what guys? IT WORKED!!!!! I now have a treeless copy of my project which is functioning as a shared repository for at least two other machines, and I've lost no history along the way, but I have gained bzr+ssh functionality. YIPPEE!!!
<cammoblammo> (Now I can get back to work)
<cammoblammo> Dammit.
<bob2> yay
<cammoblammo> Oh yeah, thanks bob2 (and everyone else for putting up with the noise).
<bob2> no worries
<cammoblammo> See you on #emacs!
<bob2> ciao
<matid> Hello there. I was wondering, has any of you managed to set up svn integration in Bazaar on OS X?
<matid> I'm having issues with python bindings.
<matid> I compiled svn 1.6 from source and installed python bindings with 'make install-swig-py' but bzr keeps telling me "Installed Subversion version does not have updated Python bindings."
<matid> And whenever I try to run 'from svn import fs, repos, core' in python it says:
<matid> http://pastie.caboo.se/176037
<matid> Any ideas?
<DaNGeRs> alows
<DaNGeRs> hello
<DaNGeRs> lol[
<jelmer> matid: did you follow the instructions on the wiki?
<matid> jelmer: Yeah, I did.
<matid> You're referring to http://bazaar-vcs.org/BzrForeignBranches/Subversion right?
<matid> They refer to svn 1.5 even though trunk is 1.6 now, so atm I'm trying to build it with the 1.5.x branch.
<matid> We'll see if it works.
<jelmer> yep
<matid> jelmer: No luck.
<matid> Still the same issue, both with svn 1.6 and 1.5
<jelmer> you probably have another svn install that's conflicting with the one you just installed
<matid> jelmer: Yeah, I've got one that is installed with Mac OS X by default, but it shouldn't conflict with the new one...
<jelmer> matid: I don't know then, sorry.
<jelmer> it's getting the wrong svn library for some reason though
<matid> OK, thanks for your help anyway.
<matid> I'll try to work it out on my own.
<pbor> if I have a shared-repository on a remote server (sftp), can I push a new branch on that server?
<iKs> pbor: as far as I know yeah, there's no problem in doing that
<iKs> bzr push sftp://yourserver/your/directory/
 * pbor tries
<bob2> yeah
<pbor> the shared repo docs only mention "branch", that's why I ask
<pbor> worked great
<pbor> awesome
<matthewlmcclure> I had a branch in a shared repository.  I did: $ bzr reconfigure --lightweight-checkout; then $ bzr reconfigure --branch .  Now the branch is missing revisions.  Any way to get them back?
<Odd_Bloke> matthewlmcclure: What does `bzr info` report the repository location (of the branch) to be?
<matthewlmcclure> $ bzr info
<matthewlmcclure> Repository tree (format: pack-0.92)
<matthewlmcclure> Location:
<matthewlmcclure>   shared repository: /c/home/mlm/sandbox/bzr/repo
<matthewlmcclure>   repository branch: .
<Odd_Bloke> That's odd.
<Odd_Bloke> I don't really know what else to try...
<james_w> matthewlmcclure: installing the heads plugin and using that may help you resurrect the missing revisions.
<matthewlmcclure> james_w: presumably because they are in my shared repo still?
<james_w> matthewlmcclure: yeah, they won't have been deleted.
<Bronger> Can anybody explain http://dpaste.com/43416/ to me?  I try to update an SVN repo.
<Bronger> Sorry, forget it, my fault.
<matthewlmcclure> james_w: thanks... is this a bug/missing feature in 'reconfigure'.  shouldn't it protect the user from this?
<james_w> matthewlmcclure: it sounds like it may be a bug.
<james_w> it would be interesting to know what about your setup caused it
<james_w> it may be the fact that you were in a shared repo, or it may have been something else.
<matthewlmcclure> i'll see if i can reproduce
<abentley> matthewlmcclure: When you say they're "missing", what do you mean?  Log doesn't include them?
<matthewlmcclure> right, log doesn't include them
<abentley> Strange that it would do that.  Is there anything significant about the revision where it stops?
<matthewlmcclure> the broken branch had a parent in the shared repo, and the last rev in the broken branch is the parent's last rev
<abentley> I have trouble imagining how a bug like that could work.  If you can reproduce it, that would be great.
<abentley> Oh, okay.
<abentley> let me see if it could be the reconfiguration to lightweight checkout.
<matthewlmcclure> that would be my guess as to when things went wrong
<abentley> Yeah, that's it.
<abentley> It's not really sensible to convert a branch with unique revisions into a lightweight checkout, because whatever it's a checkout of won't have those revisions.
<matthewlmcclure> so it's official that i know just enough to be dangerous now
<abentley> I'm sorry about this bug.  I'll add a check
<abentley> I can help you recover the revisions.
<matthewlmcclure> i don't actually need them in this case, but thanks for offering
<abentley> Okay.
<matthewlmcclure> hm... actually, i am curious if there's a way to recover a branch from a repo; say, if i had deleted the branch's directory
<abentley> You can create a new branch with the same tip.
<abentley> First you have to find the revision-id of the branch tip.
<abentley> The heads plugin is useful for this.
<matthewlmcclure> got it.  thanks
<abentley> Then you branch from any branch in the repository, and specify -r revid:
<ubotu> New bug: #212853 in bzr "AssertionError: 17 != 18 when trying to comuit to bzr.debian.org" [Undecided,New] https://launchpad.net/bugs/212853
<offby1> The docs show some examples that use abbreviations for URLs, like "bzr branch m:/cool-trunk
<offby1> where is that abbreviation format described?
<james_w> offby1: there's an "m:/" described?
<james_w> there's "lp:/" provided by the launchpad plugin that is shipped with bzr.
<offby1> there's both!
<asabil> there is bz-bookmarks
<offby1> .../doc/en/user-guide/branching_a_project.txt, r3336, line 60
<james_w> offby1: that's a windows drive, "m:/"
<dato> right, but check bzr-bookmars as asabil said
<dato> er, bzr-bookmarks
<offby1> oho
<offby1> I also created my local repository by doing "bzr branch lp:bzr"
<ubotu> New bug: #212908 in bzr "fetch all from a repo with identical contents fails with pack repos" [High,Triaged] https://launchpad.net/bugs/212908
<ubotu> New bug: #212917 in bzr ""make check" got an internal error" [Undecided,New] https://launchpad.net/bugs/212917
<ubotu> New bug: #212979 in bzr "trying to do checkout of some django code" [Undecided,New] https://launchpad.net/bugs/212979
<nick125> good afternoon.
<nick125> I'm looking for a SCM to integrate into an IDE project that I'm writing, and I've been looking at bazaar as a possible option. The idea is to use a SCM to internally version saves, as well as allowing a user to use an "external" SCM. What I'm looking for is a SCM that will allow me to use a non-standard directory to store the SCM's files, so that I can have two instances of the SCM versioning the same source tree. Can bazaar do that?
<nick125> I like bazaar since it's written in Python, which will make it easier to integrate into my IDE (since I'm writing it in Python).
<ubotu> New bug: #213032 in bzr "allow to change author (name <e-mail>) and description in past commits" [Undecided,New] https://launchpad.net/bugs/213032
<Cerulean> I'm probably missing something obvious, but I want to branch a repository onto my server
<Cerulean> I can't access the repo from my server (firewall etc)
<Cerulean> so something like bzr push that pushes the files. What can I do?
<TFKyle> nick125: mm, writing an IDE now?
<nick125> TFKyle: yep
<nick125> TFKyle: What are you upto these days?
<TFKyle> nick125: looked at crypto/digital signing stuff a while ago, a few days ago I got a fingerprint scanner and made a small thing using pylibusb to access it and get fingerprints from it :)
<nick125> Sweet, how much did the scanner set you back/
<TFKyle> nick125: ~$50 CAD
<nick125> That's not bad.
<TFKyle> the scans seem a bit low quality, dunno what sort of quality the other scanners have though (can create 128x128 images, with a few pixels being blacked out for some reason (think the register values I'm using aren't the most perfect combination though, stole them mostly from the kernel driver (that doesn't compile with newer kernels obviously))
<TFKyle> tried just changing the one required for it to send data, but it seems to produce more heat (or more electricity, not sure), should have a look at what the windows driver does too
<nick125> TFKyle: I wonder what kind of program you'd use for reverse engineering the windows driver..
<TFKyle> nick125: usbsnoop/snoopy is supposedly pretty good for USB devices (logs the traffic to the USB device)
<nick125> TFKyle: Aah, fun. I've never tried to reverse enginner anything before.
<nick125> (Well, least over USB)
<lifeless> poolie: up?
<lifeless> nick125: so, we don't have code in bzrlib to maintain two completely separate trees like you want to; knowing why might help :P
<nick125> lifeless: Would it be possible to simply use a different directory for .bzr?
<nick125> lifeless: Also, the reason I want to have two trees is so that my "internal" save bzr tree will not conflict if the user uses bazaar for an external SCM.
<asabil> nick125: why not simply support bzr alone ? :D
<asabil> you can still write repository handlers for other scms ?
<nick125> asabil: Well, the idea is that I'd integrate really closely to a SCM to keep an internal save revision tree, that way, if you delete a file or something, you can restore it easily. The only problem with using bazaar for the internal SCM is that it might conflict if the user wants to use bazaar for their "external" SCM.
<beuno> how would I get the list of uncommited changes to a working tree?  I'm getting a bit lost in the code
<beuno> nevermind, got it :)
<lifeless> nick125: well, you could submit a patch:P.
<nick125> Is the .bzr path hardcoded into bazaar?
<lifeless> no
<lifeless> and yes
<lifeless> see, we support svn natively :P
<lifeless> so there are factory functions to drive a lot of things; you could for instance subclass the stock format and create a .idesave control directory
<lifeless> which would be a bzr one internally but just change the .bzr -> .idesave
<nick125> lifeless: Hmm, how hard would that be to implement?
<lifeless> I think the setup.py of the plugin would be longer than the code
<nick125> ouch :p
<lifeless> (or you could import bzrlib and register after import, no bzrlib plugin needed then, in which case the code will still be small :P)
<nick125> I wonder how hard it is to interface with bazaar in Python
 * nick125 looks at bzrlib
<lifeless> as a user of ides from time to time, I would prefer to see ide save stuff to be done as a branch off my actual vcs; but thats me
<lifeless> pydoctor generates good docs, there is developer docs in doc/en/developer/
<lifeless> or something like that :)
<lifeless> bbiab
<nick125> Hmm...using a branch could be useful.
#bzr 2009-03-30
<igc> morning all
<jelmer> hi Ian
<jelmer> lifeless: it looks ok, but it seems like the check patch is significantly changeed, not just polished?
<igc> hi jelmer. Thanks that your reviews over the weekend. Much appreciated
<igc> morning lifeless
<jelmer> igc: svn-keywords is already partially working :-)
<igc> jelmer: I'm actually keen to get bzr-keywords into the core as well, so you can assume that code is there and build on it
<igc> jelmer: now that the fallback bit is in place, you'll only need to register how to expand the keywords I think
<igc> jelmer: and you get the sweet publishing features in bzr-keywords for free as well
<igc> next weekend maybe :-)
<stbuehler> jelmer: saw my feedback for svn / dpush ?
<jelmer> stbuehler: hi
<jelmer> stbuehler: where?
<jelmer> (I haven't seen anything yet)
<stbuehler>  jelmer: just wanted to give some feedback: bzr dpush does *not* give you the svn-revisions back, even if you had new commits pushed to upstream svn
<stbuehler> perhaps that works if you never used the normal push, didn't try that
<stbuehler> seems like i cannot force bzr to rebase to the svn branch
<jelmer> stbuehler: no, it doesn't as that would require changing existing revisions; we can keep a map though and display that sort of information
<lifeless> jelmer: yes, 0.9.5 to 0.9.6 added a special linker script
<stbuehler> i wouldn't mind changing them, if it where an option :)
<jelmer> stbuehler: can you please file a bug report about this? I'll try to get it fixed for the next version
<stbuehler> jelmer: so dpush should change existing revisions? k, let me try :)
<jelmer> stbuehler: yeah, dpush basically pushes all revisions into the remote repository
<jelmer> stbuehler: and then fetches the revisions that were created remotely and overwrites the local revisions with them
<jelmer> stbuehler: push (by definition) only changes the remote revision
<jelmer> s/revision/branch/
<stbuehler> yes, that is perfectly valid :)
<lifeless> jelmer: the 0.9.6 patch is polish from the subunit point of view, its just updating against the check project
<jelmer> stbuehler: oh, maybe I misunderstood
<jelmer> stbuehler: dpush won't change any previously "bzr push"'ed revisions of course
<jelmer> it only affects revisions not yet in svn in any form
<stbuehler> i mentioned i "dpush"ed new commits, which were not in svn
<stbuehler> but maybe it only works if you never used "push"
<jelmer> stbuehler: sorry
<jelmer> stbuehler: it should work fine if older revisions were pushed
<jelmer> stbuehler: is this repo public?
<stbuehler> svn://svn.lighttpd.net/spawn-fcgi/trunk
<jelmer> thanks
<jelmer> stbuehler: ok, I figured out what's happening, this shouldn't be too hard to fix
<jelmer> lifeless: btw, I hope to split out libtorture from samba at some point
<jelmer> so we can use that in bitlbee, ctrlproxy, etc in favor of libcheck
<lifeless> jelmer: thats your C testing infrastructure?
<jelmer> lifeless: yep
<jelmer> it already does subunit
<lifeless> jelmer: I'd be inclined to put patches into libcheck, the fork isolation really is nice
<jelmer> lifeless: is there any chance of your subunit patch actually making it into libcheck?
<lifeless> jelmer: yes
<lifeless> I've resubmitted it, chris pickett has ack'd that they were being overly nitpicky
<jelmer> hmm
<lifeless> entry point to the recent dicussion http://sourceforge.net/mailarchive/message.php?msg_name=1235597368.24285.63.camel%40lifeless-64
<lifeless> its a terrible list archive ui
<jelmer> ah, cool
<jelmer> bleh, sf svn is still slow :-(
<jelmer> lifeless: you are using bzr-svn for check development, right ? >-)
<lifeless> jelmer: yes, do you want me to push trunk in bzr format somewhere?
<jelmer> lifeless: yes, if it's not too much trouble
<lifeless> sure thing
<jelmer> I can do a pull myself, but it looks like it's going to take at least 30 min at this rate..
<lifeless> there is a  https://code.edge.launchpad.net/~vcs-imports/check/trunk :)
<jelmer> lifeless: except that imports from CVS, and hasn't been updated since 2005 :-)
<lifeless> heh. we should redirect it then :) . bzr+ssh://bazaar.launchpad.net/%7Elifeless/check/svn
<lifeless> pushing my subunit branch now
<jelmer> lifeless: thanks
<lifeless> jelmer: bzr+ssh://bazaar.launchpad.net/~lifeless/check/subunit
<jelmer> got it
<jelmer> did launchpad just upgrade to 1.13 or something?
<lifeless> not for 2 more days
<jelmer> it's too freakishly fast all of a sudden
<spiv> Last week bzr.dev got a fix for a performance bug when pushing to pre-1.13 servers, maybe it's that?
<lifeless> I think jelmer was pulling :)
<jelmer> well, pushing was the main thing that got faster
<jelmer> I pushed a 130Mb repo to lp in < 1m
<lifeless> that would be spiv's fix
<spiv> :)
<lifeless> lunch, back soon
<jml> lifeless: the only subunit branch up for review I see is https://code.edge.launchpad.net/~radix/subunit/report-errors-better/+merge/4292
<lifeless> jml: jelmer reviewed the polish branch
<jml> oh cool.
<lifeless> jml: if you didn't get notice about the subunit branch, are you subscribed appropriately to trunk ?
<thumper> lifeless: what would cause a knit to become corrupt and raise SHA1KnitCorrupt when calling show_log?
<lifeless> an actual knit?
<lifeless> or something in a pack?
<lifeless> thumper: ^
<ovnicraft> hi folks. is it posible configure bzr with emacs to commit comments?
<bob2> ovnicraft: recent emacs has vc-bzr built in
 * igc lunch
<ovnicraft> bob2, yep i got it thx
<beuno> igc, hi
<beuno> I was looking at your mergeline cache RFC supersede your plugin?
<lifeless> tracked down the commit failure
<lifeless> [bah]
<igc> hi beuno
<beuno> hey igc
<beuno> how are you?
<igc> beuno: flat out - trying hard to make our next-gen the best it can be
<igc> beuno: no, it doesn't supercede it - it helps it though
<beuno> igc, I've seen. It's impressive work
<beuno> ok, good, because I was about to spend the weekend working on loggerhead + your plugin to get them working well together
<igc> beuno: there's still a need for caching the full history to make log *really* fast - that the revnocache
<beuno> I obviously got sidetracked by RL, but was very clse  :)
<beuno> *cloase
<igc> the mergeline case helps *one* special but importasnt case - lookup of a single non-mainline revno
<beuno> hotcha
<beuno> (typing sucking)
<beuno> I see
<beuno> brisbane-core is going to rock...
<fullermd> Hmm.  Is there some reason it can't help in other cases?
<lifeless> igc: a 22K file is quite a lot of data to be updating on push/pull over the wire... I'm inclined to react cautiously and suggest taking the revnocache approach
<fullermd> I can see that it wouldn't save you any total time on log (since you pull all the info anyway), but wouldn't it let you number and start displaying more quickly?
<igc> lifeless: it doesn't get updated on push or pull
<igc> lifeless: only the first time log is used on that remote branch
<Stanlin> hi
<lifeless> igc: I don't get the connection between my ocmment and your reply :)
<Stanlin> May i use BZR with any kind of files?
<igc> lifeless: log, status and diff are read operations
<igc> you suggested not updating files during them
<fullermd> bzr currently maintains an embargo against Cuban and North Korean files...
<igc> I'm saying "that's the whole basis of the design"
<igc> I'm now updating the mergeline-store file *outside* the read transaction
<igc> so I think it's safe
<igc> given I check the data is still current before saving it
<igc> and lack of data there is handled without a drama
<igc> lifeless: make more sense now?
<igc> lifeless: and sorry if the reply wasc rushed - I'm tired today :-(
<igc> s/wasc/was/
<lifeless> igc: well, its clearly vulnerable to race conditions
 * fullermd is somewhat uncomfortable on principle with the idea of 'log' writing stuff...
<lifeless> igc: I assume I'm not understanding the cache, and I'm really concerned that this is being rushed into - we have only this week to freeze the bbc format, if I remember the dates
<igc> lifeless: right. fwiw, I'm not doing anything that couldn't work on bzr.dev now - it's not tied to brisbane-core though I'm ok with doing that
<lifeless> igc: this isn't clearly correct, and has serious potentially serious issues as all caches do.
<lifeless> not to mention that writing during a read operation is simply impossible on e.g. http:// urls, so its entirely useless there
<fullermd> Are serious potentially trivial issues more or less hazardous than trivial potentially serious issues?
<igc> lifeless: true. But the important case if local so we could easily restrict it to that
<igc> s/if/is/
<igc> and remove any network concerns
<lifeless> igc: I'm finding the discussion hard, it feels like you're presenting this as all-or-nothing, and already-analysed-this-is-right, rather than engaging
<igc> lifeless: sorry - I'm not meaning to come across like that
<igc> lifeless: and I'm very interested in how you think it's subject to race conditions and/or ought to proceed
<lifeless> igc: so as a design principle we are trying to remove all our caches
<lifeless> for instance, one possible cache that was proposed as an alternative to brisbane-core was to cache inventory deltass in commit objects
<lifeless> we successfully avoided that while still getting good performance
<lifeless> which means we get good performance on arbitrary tree deltas rather than only on adjacent ones
<igc> lifeless: really? That's sounds crazy. Caches are necessarily bad. Even bash has them :-)
<igc> s/are/aren't/
<bob2> Stanlin: yes
<lifeless> for this case, I'm interested in: what the root problem is. (is it revnos? is it index performance? something else?) I'm interested in why the operations are faster *overall* with this - what work is it actually saving, and why
<lifeless> igc: caches increase data storage, add the opportunity for bugs relateed to coherency, increase writes needed and can often reduce performance overall
<Stanlin> bob2: including graphics and big files??
<fullermd> Stanlin: It will _work_ for them (mod performance or memory issues with large files, anyway).  Whether it's particularly _useful_ depends on your situation.
<Stanlin> fullermd: awesome, ok so i can go ahead and use bzr for all my desktop
<fullermd> If any files are a significant fraction of your available physical memory (ISO's and the like are common offenders), you're likely to hit some unpleasantness.
<fullermd> And of course a number of operations (like merging) are a lot less useful with binary files.
<Stanlin> fullermd: well for starters i just want to do it with small documents
<Stanlin> fullermd: what is the best scenario to , use bzr, as server,   and lets all users push and pull, without editors or any control?
<lifeless> igc: so we really want caches where they really appear to be the best answer, not the first answer.
<fullermd> Stanlin: That's way too broad a question to answer in general   :)
<lifeless> igc: and this one, given the data I have so far, appears to be the first answer with none of the deep questions answered
<fullermd> Stanlin: Very dependant on exactly what your situation is.
<Stanlin> is bzr superior to Git?
<lifeless> igc: I may well be wrong and have missed the guts of the analysis
<lifeless> Stanlin: we think so :)
<fullermd> Yes and No and See Me Next Tuesday.
<Stanlin> gnight all :D
<lifeless> woo, faster commit landing
 * Stanlin performs aptitude remove git
<igc> lifeless: it's very early days w.r.t the mergeline cache. It works but that doesn't make it the answer. Please don't reject it on principle though. From *my* analysis, it's the smallest amount of data needed to make some selected use cases perform well. I done lots in work in recent months on stuff like revnocache and this is the only part of that plugin that I've ever thought should go in the core
<igc> And if it's not core-worthy, it will go into revnocache instead
<lifeless> igc: I won't reject it on principle; but to put it in core I would want those deeper questions considered
<igc> lifeless: sure, and I have considered cache currency in the design already, for example
<lifeless> I need to head off; day is done and all
<lifeless> http://pqm.bazaar-vcs.org/
<lifeless> record-iter-changes commit - landing now
<igc> lifeless: well done and thanks no the commit stuff
<igc> s/no/on/
<igc> and for playing devil's advocate :-)
<fullermd> FWIW, I agree in principle too...
<fullermd> I'd rather see fixable performance issues fixed (even if rather later) than papered over.
<fullermd> Once papered over, fixes tend to get pushed back a long ways, and even when made, the papering often remains messing things up worse   :|
<fullermd> (this of course expresses no opinion whatsoever on where the current questions falls on that spectrum, since that's all the opinion I'm qualified to express...)
<igc> fullermd: we currently cache the last revno and last-rev-id for the mainline
<lifeless> igc: revno is a cache, last-rev-id isn't
<lifeless> :)
 * lifeless goes
<igc> fullermd: all I'm doing is extending the idea to each "mergeline" so finding a rev-id for x.y.z doesn't require a full graph build
<fullermd> igc: Convincing me of the fitness or lack thereof of some internal mechanism is kinda wasted effort   ;)
<fullermd> I have pro and con feelings on the issue, but considering how drastically uninformed they are compared to anybody else you talk to about it...
<igc> fullermd: thanks for the tip. I was being polite and offering an explanation in case you cared :-)
<fullermd> Oh, I do appreciate that.  It's why I'm here and occasionally even pay attention   8-}
<fullermd> Just that pretty much any insight or judgement that might occur to me, lifeless already thought of 20 minutes before I read any descriptions, and either already brought up or mentally discarded as absurd.
<vila> hi all
<Peng_> Good morning.
<igc> hi vila
<thumper> can someone tell me the difference between 1.13 and 1.13.1?
<thumper> will it matter server side?
<thumper> should LP use 1.13 or 1.13.1?
<Peng_> thumper: Look at the announcement: 1.13.1 fixes a version number mismatch in bzr vs. bzrlib, fixes an error in NEWS (I think), fixes 'merge --force', and bzr-1.13.tar.gz didn't include the Pyrex-generated C files. Does any of that matter for LP?
<Peng_> thumper: If LP doesn't use "bzr", doesn't use "bzr --force" and has Pyrex installed on the build machine or doesn't use the tarball in the first place, I guess it doesn't really matter.
<thumper> Peng_: thanks, I think LP will stick with 1.13
<thumper> :)
<Peng_> Err, "bzr merge --force", I meant..
<spiv> thumper: I agree with Peng_'s assessment.  Also, we write the NEWS file for a reason ;)
<thumper> spiv: don't expect people to actually read NEWS, geez
<thumper> spiv: what makes you think I have a copy of trunk?
<spiv> thumper: Well, I'm reasonably sure you have a tool to browse files in branches online
<spiv> thumper: but also the relevant parts of NEWS are sent in each release announcement
<thumper> spiv: geez, why all this reading when someone can just ask :P
<spiv> thumper: of course, http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head:/NEWS would be even better if LP didn't time out trying to render it ;)
<spiv> thumper: when you ask, all I do is go and read that file
<spiv> thumper: so you might as well cut out the middle man :)
<thumper> spiv: and save me the trouble :)
<VSpike> Greetings.  A general question.  I have a project where parts of it are customized files for the end customer - e.g. web pages, set up files, theme files etc...
<VSpike> I want to maintain these branches in parallel for the long term.  Is there a way to make this easier, i.e. to ensure that some changes in a branch never get pushed to the parent?
<VSpike> The other approach would be to treat all the customer specific files as a separate project under source control.
<VSpike> But bzr doesn't seem to handle related sub-projects yet - unless that has change since I last checked?
<yogsototh> VSpike: got the same problem with 3 diffÃ©rent environments.
<yogsototh> I use 3 differents branches
<yogsototh> And I never use pull nor push
<yogsototh> but only merge
<yogsototh> That should work just great
<VSpike> yogsototh: do you mean that you never make code changes in the child branches that need go back to parent?
<joie> Apologies if I'm asking the obvious - but I can't find it in the docs. Is there any way of finding out the common ancestor a merge command is using?
<joie> (I'm kinda new to bzr - but been using baz for a long while, trying to make the switch!)
<lifeless> joie: bzr find-merge-base
<lifeless> joie: found in 'bzr help hidden-commands'
<joie> Ahhah - sounds like a useful thing to know - thanks!
<joie> I'm essentially trying to do the equivalent of a baz apply-delta to put all the work from one branch onto my working branch, and want to be sure that merge is doing the "right" thing!
<james_w> jelmer: hey, thanks, I was just about to take another look at bzr 1.13.1 and I saw the ACCEPTED mail.
<jelmer> james_w: it turned out there was a bug in the python2.6 package in experimental that I had instlaled
<jelmer> james_w: uninstalling it made the problem go away
<Tak> jelmer: hello
<igc> night all
<emmajane> igc, just got your email. The reason I emailed you back with the link was because I don't have time to do this right now.
<liw> what's this mean: Unable to contact DBus session: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.
<jelmer> liw: bzr-dbus was unable to contact your local DBus
<jelmer> liw: while attempting to signal that a new commit was made / branch was updated
<liw> ok. why is dbus being contacted? I'm not running under X for that command (ssh into the machine; there is an open X session in the console, though)
<jelmer> liw: you have bzr-dbus installed probably
<jelmer> liw: newer versions of bzr-dbus will not show any error / output if it fails
<liw> jelmer, ok, then I'll just ignore it, thanks
<jam> vila: just a quick question, if you managed to fix the duplicate "CHKInventory" stuff.
<vila> ajmitch: yu[
<vila> ajmitch: sorry wrong target
<vila> jam: yes ?
<jam> vila: ?? or 'yes' :)
<vila> jam: I pushed --overwrite on vilajam
<vila> jam: 'just quick question, if' I was waiting for the question :)
<vila> jam: the fix may not be the cleanest one (you can still find the duplicate in a couple of revisions if you dig enough), but I think it's "good enough"
<meuserj> Is there an existing plugin or other method for creating a default template for commit text?
<jelmer> meuserj: there's no plugin yet, but there is a hook you can use if you're going to write such a plugin
<vila> jam: in gc, _compress last returned value is length, documented as 'number of bytes accumulated in the group output so far' but the code seems to calculate the delta length instead
<vila> vila: it seems to be used only in _insert_record_stream and even there that seems like a left over
<jam> vila: so the return is currently (sha1, start_of_record, end_of_record, kind, length_of_record)
<jam> the last part is obviously redundant with end_of_record - start_of_record
<vila> jam: not so obviously :-) but thanks for confirming, it's not always the case for the python impl. but if the semantic is correct, I'll just delete it
<vila> jam: can I get also get rid of the last_fulltext_len in _insert_record_stream ?
<jam> vila: sure, I think there was something about returning the size of the fulltext that was being compressed, etc
<jam> I would probably just get rid of 'length'
<jam> (evolving interfaces :)
<vila> jam: ok, doing it right now
<jam> so stuff like last_fulltext_len was meant as a possible way to play with varying the compression decisions
<vila> I can 1) get rid of it as well as length, 2) keep it and update it with end - start
<jam> vila: We can always bring it back if we decide we want to use it
<jam> for now, cleaner code is probably better for landing in bzr.dev
<vila> ok
<jelmer> jam: hi
<jelmer> jam: How do I create a branch5 format programmatically?
<jam> jelmer: in a test suite or just from bzrlib?
<jelmer> jam: in a testsuite
<jelmer> for other branch formats I can use ._matchingbzrdir
<jam> jelmer: self.make_branch('dirstate'
<jam> would probably be fine
<jam> at least that was the last one to use Branch5
<jam> if you need more control than that, then I can go through it
<jam> (that will be a knit format repo, with a branch5 branch)
<jelmer> jam: is there any way to obtain that from a BranchFormat instance?
<jam> jelmer: are you saying you need the name of the format?
<jelmer> jam: I have a BranchFormat instance (BzrBranchFormat5) and need to create a branch that uses it
<jam> bzrlib.branch.BranchFormat5.initialize()
<jelmer> preferably as generic as possible, without special casing BzrBranchFormat5
<jelmer> This is for the InterBranch tests
<jam> jelmer: my_format.initialiaze(a_bzrdir) ?
<jam> my_format.initialize(a_bzrdir) ?
<jelmer> jam: but in that case what format can a_bzrdir have?
<jam> jelmer: there is only 1 'metadir' bzrdir format
<jelmer> can I use a BranchFormat5 with a recent repo format?
<jam> jelmer: yes
<jam> it will "work" we just don't give you a way to specify that with a short name from 'init'
<jelmer> ah, neat, I wasn't aware of that
<jam> vila: so where are you at? I haven't seen your commit showing up yet :)
<vila> I tracked down the unicode symlinks error back to bzr.dev@4216 :-/
<vila> Can you run ./bzr selftest -s bt.branch_implementations.test_sprout.TestSprout.test_sprout_with_unicode_symlink in your bzr trunk ?
<vila> jam: ^ ?
<jam> vila: currently on win32, I'm sure it will pass just fine :)
<vila> jam: lol, yeah, but I don't understand how pqm let it pass
<jam> vila: on my server, that test fails about 5 times
<jam> 'ascii' codec can't decode byte 0xce
<vila> yup, that one
<jelmer> with or without the dirstate pyrex extensions?
<jam> jelmer: both
<vila> jelmer: both
<jam> vila: maybe a python2.4 issue?
<vila> revno 4215 succeeds, 4216 fails
<vila> just reproduced it with 2.4 too 8-/
<jam> vila: so I could see where 'iter_changes' is accidentally using 8-bit symlink_target rather than unicode, but yeah, I don't see how pqm didn't fail just like us
<vila> UnicodeFilenameFeature not available on pqm ?
<jam> vila: certainly possible, I don't know
<jam> actually, probably likely
<jam> try setting LANG=fr
<jam> or something
<jam> rather than fr.UTF-8
<vila> EMYOSDOESNTSPEAKFRANCAIS :)
<vila> LANG=en_US.UTF-8
<vila> always
<jam> :)
<jam> so LANG=en_US  then :)
<jam> vila: yeah, it passed with a skip here
<vila> yup, tests are skipped in that case
<vila> crap
<vila> jam: by the way, I pushed my last changes at vilajam
<vila> jam: you may want to pull --overwrite from there though
<vila> jam: I mean, I you keep a mirror of that one
<vila> jam: I mean, IFF you keep a mirror of that one
<jam> vila: well, I'm a bit saddened that you keep '--overwrite'ing all of my branches. You pushed up your history for brisbane-core, and vilajam...
<vila> jam: ?? I try to respect the mainline most of the time, but here you had committed *on top* of the error, so I tried to get rid of the problem as best as I can :-/
<vila> jam: I tried alternate ways to fix it, but most of them ended up with the wrong annotation for both CHKInventory and CHKInventoryDirectory (all the lines were attributed to *me*), at least now the attributions are correct and  your revisions still present
<jam> not a big deal, really
<jam> I was just surprised to see both mainlines changing to "merged bbc@" especially since it was the bbc trunk
<vila> I thought correct annotations were more important than revision history :-/
<jam> vila: personally I use "bzr log" about 20x more than "bzr annotate", but as I said, in another week I won't even notice
<vila> jam: and yes, the way I rebuilt my loom wasn't the clearest either :-/
<vila> jam: on the other hand, may be you should push to jamvila :)
<jam> :)
<vadi2> does bzr use sha1 behind the scenes?
<james_w> yes
<luks> heh, python is going to use mercurual
<cody-somerville> luks, its official?
<cody-somerville> luks, link?
<luks> http://mail.python.org/pipermail/python-dev/2009-March/087931.html
<jszakmeister> yep, it's official.
<cody-somerville> That sucks :(
<cody-somerville> bzr rocks
 * jszakmeister agrees
<cody-somerville> Is there an announcement or anything?
<jszakmeister> It probably boiled down to performance... the email is a little vague, but I agree... a decision needed to be made
<jszakmeister> luks put the url in IRC
<cody-somerville> but bzr is fast now :(
<BFrank> that is the joy of open source, you are free to choose amongst many good choices
<cody-somerville> I can't wait until Launchpad supports git and mercurial imports
<santagada> is the code for launchpad avaliable somewhere already?
<cody-somerville> santagada, You might want to ask in #launchpad - this is #bzr
<Toksyuryel> and each choice typically tries its best to make switching between choices as painless as possible
<mwhudson_> cody-somerville: soon!
<mwhudson_> for git
<santagada> cody-somerville: no one here knows? I would supose it is pretty important
<cody-somerville> santagada, Why?
<cody-somerville> mwhudson_, :)
<antoranz> when I pack, can I delete everything in .bzr/repository/obsolete_packs/?
<beuno_> antoranz, in general, yes
<antoranz> ok
<bialix> hi guys, in which time igc (Ian) will be here?
<beuno> bialix, I'd say in about 3 hours or so
<bialix> thanks. perhaps too late for me
<BFrank> why doesn't it cleanup obsolete packs?
<bialix> igc: I'd like to talk about eol labels and strategies with you tomorrow morning (~ 6-8 am UTC). OK?
<beuno> BFrank, I don't know all the details, but it mostly has to do to ensure that we don't run into data loss
<BFrank> hmm
<bialix> igc: I'll be there tomorrow.
<beuno> BFrank, there are some crazy scenarios where that happens
<BFrank> when exactly does it cleanup the obsolote packs?
<BFrank> shouldn't there be a point when it is safe for bazaar to clean them up?
<james_w> it cleans them up before writing any more
<james_w> so next time it does a "pack" operation it first removes the obsolete ones
<BFrank> shouldn't it cleanup for other types of operations, where it won't create new ones?
<BFrank> or do all operations create them?
<james_w> no, just the ones you would expect
<james_w> commit, pull, pack, merge, push into, etc.
<BFrank> hmm
<antoranz> what tool can I use to import a git repository into bzr?
<mwhudson> antoranz: bzr-git or bzr-fastimport
<antoranz> ok
<mwhudson> antoranz: the latter is probably more robust at this point, but bzr-git is moving fast
<antoranz> ok
<jelmer> mwhudson: moin
<mwhudson> jelmer: hi
<jelmer> mwhudson: my git import now works on lp btw
<mwhudson> jelmer: yes, i saw that
<mwhudson> jelmer: did you find out what was going on when it was just showing 1000 revs?
<jelmer> mwhudson: yes, I had only pushed 1000 revisions (bzr push -r1000) :-)
<mwhudson> jelmer: hahahaha
<mwhudson> jelmer: so if i wanted to make a bzr-svn import of pypy, what would i have to do?
<mwhudson> jelmer: i remember you saying that i could probably hack something to ignore certain errors
<jelmer> mwhudson: ah, yeah
<jelmer> mwhudson: when it calls get_dir()
<jelmer> you have to ignore 157002 errors
<mwhudson> jelmer: alternatively
<mwhudson> if i dump the repo, filter out the offending fileprops, recreate it locally
<mwhudson> do the import from my local repo, will it be possible to update the import from codespeak?
<jelmer> mwhudson: yes
<mwhudson> jelmer: awesome
<mwhudson> jelmer: do you happen to know how to filter a dumpfile?
<jelmer> mwhudson: vi ? :-)
<mwhudson> jelmer: heh
<phinze> so i've got a meeting this afternoon about revising my group's code review practice, which currently consists of all devs (4-6 of them) sitting around a table and scrolling through one big diff that's getting deployed
<phinze> wondering if anyone else using bazaar in a dev group can talk about what they do for code review?
<phinze> we're hoping to move toward peer-review where one other dev signs off on each commit to trunk
<james_w> phinze: that's what bzr does, as you probably know
<phinze> yes bzr does PQM where what like at least one other dev must approve?
<james_w> you work with much smaller, more targetted diffs, which is a big win
<james_w> but there will some cross-change intricacies that can be missed
<james_w> yeah, two core devs total, so you get two reviews of code from those that haven't been let in to that group yet
<phinze> we're thinking of using PQM here too
<james_w> I think that's a stricter requirement than a lot of open source projects, where once you are a core committer you can generally do what you like
<phinze> yeah seems pretty strict but also seems like it works :)
<phinze> so it's either BB:approve or BB:reject...?
<james_w> e.g. in Ubuntu. What happens there is sometimes you request your changes are reviewed before uploading (committing to mainline). Some people watch the -changes list (equivalent to -commits) and review things that catch their eye
<james_w> so it's much less comprehensive
<james_w> but the volume of changes there is too large, and the expertise too thinly spread, to have bzr's system of review.
<phinze> ahh yeah
<james_w> there is BB:approve, BB:reject, BB:rebsubmit, BB:tweak, BB:comment and BB:abstain I think
<phinze> lol abstain
<james_w> where approve, resubmit and tweak are the most commonly used
<phinze> how to resubmit/tweak work in that case
<phinze> are they just different semantic keywords on top of reject?
<phinze> s/to/do
<james_w> reject is pretty final, "I don't want any change like this in bzr", for something like "remove bzr commit, make everyone commit by editing .bzr/repository"
<phinze> :)
<james_w> resubmit means, "I'm fine with where you are going, but there are some problems with your implementation, make some changes and ask for review again"
<james_w> tweak means "basically fine, there's a typo here, fix that up and submit it, you don't need to get it re-reviewed"
<phinze> from BB/PQM's perspective, though, it's just a "go/no go"?
<james_w> BB tracks the votes, I'm not sure what algorithm it uses to decide, if any
<james_w> PQM is not automatic, a developer has to submit each change
<james_w> there's no link between them currently
<phinze> ahh BB and PQM are two separate systems... i thought they were two head of one beast
<james_w> PQM just saves you from having to wait for the testsuite before committing, you submit, and some time later get a mail telling you if it passed or not
<james_w> nah, they could work more closely together, but it works fine to have them separate, so no-one put the effort in
<mwhudson> jelmer: ok, i have a dump file, can you give me some clues what i'm looking for?
<jelmer> mwhudson: look for the particular revision that was causing problems (I think I mentioned it in the bug report)
<jelmer> You'll see entries in the dump file for each property change and each file change
<jelmer> just remote the K ... / V ... bits for the problematic property (with a / in the name IIRC)
 * mwhudson wonders about an appropriate tool for editing a 3.7 gig file
<stbuehler> "rm" :)
<NfNitLoop> heh.
<thumper> mwhudson: sed
<mwhudson> thumper: you might be rite
<thumper> mwhudson: or emacs :)
<mwhudson> right
<mwhudson> does emacs not load the entire file into ram?
<mwhudson> i was ~sure it did
<NfNitLoop> a friend of mine had to remove middle chunks of very large (gig+) files and ended up using head & tail.
<thumper> mwhudson: I'm not sure
<jelmer> mwhudson: there are some tools for editing svn dumps
<jelmer> but I'm not familiar with them
<jelmer> they do exist though :-)
<mwhudson> ok
<phinze> james_w: thanks for explaining all that; very helpful!
<james_w> np
 * mwhudson finds a perl thingy
<mwhudson> hang on
<mwhudson> jelmer: can svn-import import from a dump file?
<mwhudson> or
<jelmer> mwhudson: it can import from a dump file but it will simply load the dump file into a repo and then import it
<jelmer> mwhudson: actually, you should be able to import from that dumpfile directly
<jelmer> mwhudson: as that problem only occurred over http
<mwhudson> right
<mwhudson> that was what i was thinking
 * mwhudson plays the install dependencies game
<shtylman_> I am looking to setup my own bzr server for a group I am working with. I wanted to do it using https transport to basically get pretty urls (ie. https://domain/repo/project) ... I know bzr can work over ssh, but then I don't get the pretty name...without putting the repo under root...which I would like to avoid...any suggestions/ideas?
<NfNitLoop> shtylman_: You can use read-only "dumb servers" over HTTP trivially:
<NfNitLoop> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<NfNitLoop> but ssh will probably be best (read: easiest) if you want to give people write access.
<shtylman_> NfNitLoop: I am aware of the "dumb" servers...and yea...I was thinking the same thing....but just wondering if I overlooked something simple
<NfNitLoop> Not that I know of.
<NfNitLoop> you could use `bzr serve`, but that's apparently only for a single repo.
<LarstiQ> afaik bzr serve is for directory hierarchies, not repositories.
<NfNitLoop> Oh.  ok, misread that while skimming.
<LarstiQ> so serving / would work
<NfNitLoop> there you go then, bzr serve.
<NfNitLoop> (though, you probably don't want to serve /)  ;)
<LarstiQ> shtylman_: you could use a chrooting ssh server to prettify your urls, just like launchpad does
<mwhudson> jelmer: import to a brisbane-core format blew up in a really exciting way
<shtylman_> LarstiQ: will that interfere with the current ssh server on the machine? sounds like it will...
<LarstiQ> shtylman_: it could
<mwhudson> jelmer: http://pastebin.ubuntu.com/140987/
 * LarstiQ goes to bed
<mwhudson> jelmer: and then when trying to import into --1.9 http://pastebin.ubuntu.com/140995/
<jelmer> mwhudson: not sure any of those are bzr-svn issues
<mwhudson> jelmer: what might they be?
<mwhudson> the thread-starting one is pretty odd
<jelmer> mwhudson: Does it start a very large number of threads or something like that?
<mwhudson> jelmer: bit hard to tell, this is on a remote machine
<mwhudson> which is an openaz slice, or something, so it's possibly a slightly strange environment
<lifeless> shtylman_: you could put a symlink in the root
<shtylman_> lifeless: yep...decided on that few min ago :)
<jam> jelmer: for the first pastebin, something is passing a 'key' that has a unicode string, which I don't think is allowed. Since both "file_id" and "revision_id" are declared to be utf-8 strings internally.
<jam> Given that it is clearly an 'id' followed by a 'path' I'm a bit confused by it, though
<jam> Though it also seems be failing in the middle of 'svn/errors.py ... convert'
<jam> which sounds like an exception in the middle of reporting an exception.
<mwhudson> jelmer: i'm tar tjf-ing the repo, will see if it ends up small enough to download to my laptop reasonably
<mwhudson> cfj, obv
<jam> anyway, I'm off for tonight, catch y'all later :)
<lifeless> gnight jam
<igc> morning al
<igc> all
<lifeless> hi igc
<igc> hi lifeless
<igc> lifeless, jam: I'm up at the hospital most of the day
<lifeless> igc: good luck
<igc> what code do you want me reviewing while I'm there?
<igc> I'm thinking chk_map
<igc> (groupcompress in out of my depth and we have 3 people who ought to know it reasonably well)
<igc> s/in/is/
<lifeless> that would make sense; re the cache you are proposing, yes your mail comes across very strongly ;). I would like to note that AIUI the revnos do _not_ require the full graph to be traversed
<lifeless> so if we strip the hyperbole we can be examining that part of the problem
 * SamB_irssi begins to wonder why svn-import is only available for svn ...
<plexq> I'm trying to merge lots of subprojects into one big central project.  Is there a way to do that?
<plexq> should I just make one big honking bzr
<lifeless> there is a merge-into plugin
<plexq> or do subprojects like you can in svn
<plexq> merge-into - yeah - I saw that - does it still work? i t hasn't been touched in 9 months?
<lifeless> as far as I know it does work yes
<lifeless> we have sub projects being worked on but its not really ready yet
<plexq> kk
<plexq> I'd heard a rumour that bazaar was going away because Gnome picked git, is there any truth to this?
<SamB_irssi> I heard that Emacs is going to be switching to bzr soon ...
<james_w> first I've heard of it
<lifeless> plexq: no truth to it at all
<lifeless> and yes, emacs are talking timeframes now
<plexq> I know for us - it will depend on IDE plugins.  We are using bazaar right now, but I've heard there is a pure Python version of git, and IntelliJ 8.1 now has a git plugin, but no good bazaar support :(
<lifeless> plexq: the pure version of git is 'dulwich' a project started for 'bzr-git', our git interoperation plugin
<plexq> heh
<lifeless> eclipse has bzr support FWIW
<plexq> yeah - but eclipse is a POS
<plexq> it's horrible
<plexq> took one look at IntelliJ and never looked back
 * igc breakfast
#bzr 2009-03-31
<lifeless> vila: ping
<vila> lifeless: zzz pong zzz
<lifeless> vila: your patch is wrong :)
<lifeless> vila: because it decodes a fs output which may not be utf8
<lifeless> vila: which is why we should fix tree.get_symlink_target
<vila> lifeless: isn't tree a revision tree here ??
<lifeless> no
<jelmer> yay
<jelmer> after more than a year, I finally have a current copy of samba in bzr again
<lifeless> cool
<lifeless> spiv: are we getting together?
<spiv> lifeless: not today, I'd be keen to pair tomorrow though.
 * spiv is off to lunch
<johnf> when running a hook I don't suppose the current revno gets put into the environment somewhere?
<lifeless> johnf: a shell hook or python hook?
<lifeless> the former I dunno, the latter - its available via the api
<johnf> lifeless: shell
<johnf> yeah I just ran env as a hook and there is nothing there
<johnf> might have to do something evil with builddeb pre-export and pre-build hooks using a temporary file
<lifeless> are they not python hooks?
<johnf> Basically I want access to the revno inside the build dir
<johnf> probably
<lifeless> Are they fired by builddeb itself?
<johnf> let me see
<lifeless> if they are fired by builddeb, use the bzr Hook infrastructure instead
<lifeless> change the shell hooks to be hooks in that infrastructure, then you can write your hooks in pythn
<johnf> builddeb has a run_hook method which uses popen so I'm guessing they don't use the hook infrastructure
<pjz> is it possible that I lost content if I had files in mworking dir when I typed 'bzr rebase' ?
<pjz> they seem to be gone
<pjz> which makes me a bit unhappy
<thumper> what is the way to create a new branch in format say 1.9 format using bzrlib?
<lifeless> thumper: look at builtins.py, cmd_init
<pjz> any chance that my content that looks lost is really stored somewhere else?
<pjz> how do I list branches?
<lifeless> pjz: bzr branches [optional url]
<lifeless> pjz: you may have shelved it
<lifeless> pjz: or it could be a dead head (bzr heads --dead)
<pjz> lifeless: ah! bzr heads --dead found it! now... how do I bring it back?
<lifeless> pjz: you can pull it or merge it, using -r revid:REVISIONID
<pjz> lifeless: how can I change the parent branch of a checkout?
<pjz> lifeless: b/c the repo it's in has a bogus parent branch set, so trying to pull -r it tries to pull that bogus parent branch and fails
<lifeless> pjz: bzr unbind
<lifeless> pjz: or bzr switch
<lifeless> unbind stops it being a checkout, but if the parent is deleted you can get around that
<lifeless> oh
<lifeless> pjz: "bzr pull . -r revid:REVID"
<pjz> lifeless: ah! thanks muchly!
<pjz> lifeless: is there a doc that describes how to use branches of a project on launchpad correctly? Like I registered and created a branch to push to, but got into trouble not knowing how to rebase up once the upstream branch advanced some
<lifeless> pjz: why would you rebase?
<lifeless> pjz: with bzr people generally just merge from trunk
<pjz> lifeless: uh... how else do I movemy work to top of tree?
<pjz> lifeless: ah, okay
<lifeless> rebase seems to be a very git thing
<lifeless> most other vcs's don't need it anywhere near as much
<pjz> well, they do it differently
<pjz> everytime you do an 'update' in svn or cvs, that's really a rebase of your working tree onto the trunk
<lifeless> pjz: you can do 'bzr update' too, when you have a checkout of trunk
<lifeless> that pivots your work into a pending merge on the old tip of trunk
<pjz> lifeless: okay, so anyway, is there a 'usual-workflow' doc of bzr & launchpad somewhere?
<pjz> lifeless: so what should my initial checkout be of? my branch? or the trunk?
<lifeless> I don't think there is; there are ones for bzr
<lifeless> and launchpad just expects any normal use of bzr
<pjz> lifeless: ah, okay. is there a good bzr workflow doc somewhere then?
<lifeless> doc.bazaar-vcs.org has the users guide, reference manual etc
<lifeless> in short though, its usually
<lifeless> bzr branch trunk myfeature
<lifeless> hack and commit in myfeature
<Peng_> Ehh, is it possible to set "log --levels N" for all commands that show logs, not just "log"?
<lifeless> if trunk changes, cd myfeature, bzr merge $trunk; bzr commit -m 'merge trunk'
<lifeless> when the feature is done,
<lifeless> cd trunk; bzr merge $myfeature; bzr commit -m 'myfeature is finished'
<lifeless> pjz: both cvs and svn can do merges as well as updates btw :)
<pjz> lifeless: oh, so I have to keep a trunk tree and a branch tree both around?
<lifeless> pjz: either that or use bzr switch to move a checkout between branches
<lifeless> with a checkout its
<lifeless> bzr branch trunk myfeature; cd $checkout; bzr switch myfeature; hack commit etc; bzr switch trunk; bzr merge myfeature && bzr commit -m 'feature done'
<lifeless> pjz: if its a small project, just have a couple of trees, if its big like emacs/python etc, you'll want a shared repo setup (bzr init-repo /src/repo --no-trees), which means that making new branches will not setup working trees
<lifeless> pjz: and then you'd use switch
<lifeless> pjz: this is a bit of a wart on our UI, and we're discussing at the moment how to fix this while still keeping the things we love (that branches have real url's mainly)
<lifeless> pjz: does this make sense?
<pjz> lifeless: mrm, yeah, somewhat
<thumper> ?!? Ignoring request for a stacked branch as repository already exists at the destination location.
<thumper> it lies
<thumper> I supplied --stacked-on
<lifeless> thumper: you're pushing somewhere that has a repo already
<thumper> lifeless: no I'm not
<thumper> lifeless: I'm pushing to launchpad
<lifeless> thumper: no chance that you had a partial push already at that url with a repo and no branch?
<thumper> none at all
<thumper> the branch didn't exist before
<lifeless> then file a bug
<pjz> lifeless: so you still haven't told me how to set the parent branch of a checkout
<thumper> lifeless: what does walking content mean when inserting stream?
<lifeless> pjz: pull --remember
<lifeless> thumper: its a progess message from the guts
<thumper> lifeless: handy
<pjz> lifeless: thanks muchly
<pjz> lifeless: for all the help
<lifeless> pjz: my pleasure
<pjz> lifeless: and I think things will be nicer when you can address branches in the same repo
<pjz> lifeless: which should be fairly easy - just pick some separator char or path or something
<pjz> lifeless: so file://foo/bar/baz/.bzr/onebranch means 'in repo file://foo/bar/baz, branch onebranch'
<pjz> lifeless: b/c the real cool thing about URLs is that they can be virtual :)
<lifeless> pjz: so, you can already, 'bzr switch' for instances knows to lookup relative to the current branch
<lifeless> pjz: but yes we need to do something to make this better
<pjz> lifeless: also once you get this you should be able to do things like add /parent and /push subpaths to the branch to make them addressable
<pjz> lifeless: er, to the branch URI
<lifeless> pjz: what do you mean?
<pjz> lifeless: well so if I have a branch 'feature1' from a trunk 'trunk', and 'feature1' has a subbranch called 'bugfix1', I could maybe merge it all the way to the trunk by just doing a merge with feature1/parent instead of having to remember trunk's URL
<lifeless> so at the moment
<lifeless> if I have three branches
<lifeless>  /trunk, /feature1, /bugfix1
<lifeless> and a checkout of bugfix1
<lifeless> I can do
<lifeless> 'bzr switch trunk'
<lifeless> to go direct to trunk without remembering the url
<lifeless> repositories are just storage to bzr, we don't need to make them more than that to get nicer paths
<lifeless> what it needs though is the core performance stuff we're working on for 2.0 finished
<lifeless> then I and others can spend some serious time on UI
<pjz> lifeless: how do you list what branches are in a repo?
<lifeless> bzr branches
<lifeless> which looks at .
<lifeless> unless you give it a url
<pjz> lifeless: wow, I get a blank line when I run that
<pjz> lifeless: so I have no branches?
<pjz> or one with an empty name?
<lifeless> one with an empty name I'd say
<lifeless> as it defaults to looking in . :)
<pjz> lifeless:  so I've got a branch named '', a parent branch of http://trunk and a push-branch of lp:mybranch
<pjz> lifeless: aaand a submit-branch of the old absolute path to ., that changed when I renamed what .. calls .
<pjz> any way I can update the submit path?
<pjz> er, submit branch
<lifeless> bzr submit branch-to-submit-against --remember
<lifeless> erm
<lifeless> s/submit/send
<pjz> lifeless: any way to do it without actually doing a send?
<lifeless> pjz: you can edit the config setting directly
<lifeless> its the submit_branch setting (and see bzr help configuration for details on the configuration stuf)
<cody-somerville> wow
<cody-somerville> bzr just caused me a lot of data loss
<lifeless> orly?
<cody-somerville> I was trying to get bzr to recognize that I had moved some directories around
<cody-somerville> as I had moved a ton of directories in the cwd into a new, unversioned directory called desktop-guide
<cody-somerville> I did bzr --after libs/ desktop-guide/
<cody-somerville> and then when I went to try to move something else into desktop-guide, it told me desktop-guide was already versioned
<cody-somerville> so I did bzr status and saw that bzr had moved libs to desktop-guide
<cody-somerville> not desktop-guide/libs/
<cody-somerville> so I did bzr revert libs/ to undo that
<cody-somerville> and so bzr deleted desktop-guide and brought back libs <g>
<cody-somerville> not quite what I wanted at all
<lifeless> that is what you asked it to do
<lifeless> bzr revert is not 'undo the last command'
<lifeless> its 'put things back to the way they were in the last commit'
<cody-somerville> Right
<cody-somerville> I thought it would bring back libs/
<cody-somerville> not delete desktop-guide
<cody-somerville> I understand why it did
<lifeless> it should ahve created backup files
<lifeless> and they are probably in libs
<cody-somerville> oh weird
<cody-somerville> Its like it merged the two directories together
<lifeless> night all
<vila> hi all
<cody-somerville> When will bzr work with python2.6?
<gour> hi, what's going on with bzr lately (considering both gnome and python 'missed' it)?
<cody-somerville> nvm
<cody-somerville> I had hardy ppa enabled and not jaunty
<cody-somerville> gour, to answer your question, I heard they were working on a revolutionary new storage engine or something that is super fast and takes up very little disk space
<gour> cody-somerville: i must say that i played a lot with bzr (after moving from darcs), but have tendency to go back seeing (too) many format options in bzr not being able to settle on something :-(
<cody-somerville> gour, why? It doesn't really affect you or me.
<RAOF> cody-somerville: That'd be brisbane-core, which, if I understand it correctly, will allow the devs to fix all the bugs I care about, and implement (almost) all the features I care about.
<cody-somerville> indeed
<gour> cody-somerville: well, it does not impress one - storage format is one of the important issues for VCS
<gour> cody-somerville: and in the meantime most major players will migrate....and it will be extremely difficult to get 'em back
<cody-somerville> gour, Right and bazaar is continuing to innovate in that area providing you and me with improved performance and more features transparently
<RAOF> To a certain extent, as long as bzr-git works, I don't much care.
<cody-somerville> So what features are you interested in RAOF?
<RAOF> So, I'd like, in no particular order: push to not push a minimum of 1Mb of data, at a rate < 10K/sec (roundtripping to .uk!).  'bzr externals' type support.  Pull to nearly saturate downstream bandwith (less roundtrippin' to UK!)
<RAOF> Some other random stuff that I can't remember right now, too.
<Peng_> RAOF: What version of bzr do you run? There were push & pull improvements in 1.12 or 1.13.
<Peng_> (or both?)
<RAOF> Peng_: 1.13; Jaunty default.
<igc> hi vila
<igc> vila: I'm seeing 2 test failures running 'bzr selftest groupcompress' in brisbane-core
<igc> vila: do you know if anyone is working on fixing those?
<vila> igc: there is a python version of gc that should land soon, what failures are you seeing ?
<igc>  test_insert_record_stream_existing_keys
<vila> igc: by the way, I just fixed 3 more failures in test_commit_with_revision_id_record_iter_changes
<igc> once for groupcompress and once for groupcompress-graph
<vila> ha yes, those ones, no, nobody is on it yet AFAIK
<enquest> I'm following http://bazaar-vcs.org/BazaarForWebDevs
<enquest> this line does not work python setup.py build_ext -i
<enquest> there is not setup file created when you get the branch bzr branch https://launchpad.net/bzr-push-and-update bzr_push_and_update
<vila> enquest: forget it, that's a typo, this is not needed
<enquest> maybe somebody wants to change it http://bazaar-vcs.org/BazaarForWebDevs
<enquest> thxs
<vila> enquest: hit refresh :)
<enquest> :)
<vila> and the command should really be: bzr branch https://launchpad.net/bzr-push-and-update push_and_update
<vila> note: no leading 'bzr_' for the plugin directory name
<ronny> yo
<ronny> is there any command that will tell me what history i'll get if i pull/merge with a remote?
<Kinnison> What you will get?
<Kinnison> the 'missing' command might be what you're after
<Kinnison> type 'bzr help missing' and take a look at the usage
<vila> igc: ping
<igc> hi vila
<ronny> hmm
<igc> vila: I've got to run sorry - dinner
<igc> bbl
<vila> igc: there is a thred in bazaar@lists.canonical.com about these failures:  VF.insert_record_stream() with duplicates in stream
<vila> igc: so jam is indeed aware of the problem and already working on possible solutions, sorry I didn't make the link sooner
<ronny> oh dammit
<ronny> it doent tell me about all changes, but only the last merge
<vila> ronny: bzr missing
<ronny> vila: yes, exactly that one ...
<ronny> only shoes the latest merge in the remote, not all of the changes
<vila> ronny: hmm, bzr version ?
<ronny> 1.13.1
<vila> by alll the changes you mean merged revisions ?
<ronny> i want to see all revs
<ronny> not just merges
<vila> bzr pull -v should still show all merged revisions :-/ igc is working on log and changed some defaults, you may be seeing a side-effect here
<vila> ronny: if you got the the revision range you're interested into (from missing) you can still do:
<vila> bzr log <remote_branch_url> -r <revision_range> --levels 0
<lifeless> ronny: bzr missing --include-merges
<ronny> lifeless: the description of that in the help is DAMN confusing and missleading
<ronny> "--include-merges      Show merged revisions." - my first tought about that was "hu? it shows the merges already"
<fullermd> That sounds like mtn-thinking carryover.
<vila> ronny: how would you make the distinction between the merging revision and the merged revisions ?
<vila> ronny: is 'Show all revisions in addition to the mainline ones.' clearer ?
<ronny> vila: yes, that would be very good
<ronny> fullermd: well, mtn was my first dvcs
<ronny> (and the first vcs i could actually use nicely, cause svn is a clusterfuck)
<fullermd> I'm not saying it's bad, just that mtn --no-merges and bzr --include-merges talk about completely different things...
<fullermd> Emergent both, kinda.
<Theuni1> owd
<Theuni1> Here is a question that might be a bit more general than just Bazaar. But I'm wondering: in a central environment (company) it sounds strange that DVCS can't manage multiple branches that belong to the same project and make sure that a developer never can delete history: pushes always seem to be just mere file system accesses so I as a developer can also just go ahead and delete that branch and any history of it.
<Theuni1> Is there a practice in Bazaar to avoid this?
<Theuni1> I'm also suspicious that LP does part of that job, but that's a no-go as it's not open source.
<SamB> what? never throw branches that didn't work out??
<SamB> if you have to worry about that happening, I think you need to pay your people more ;-P
<Edulix> hi
<Peng_> Theuni1: You can totally nuke stuff on Launchpad.
<Edulix> so I do bzr pull, and it downlads a new revision. without messing with the revno, how to do a bzr diff between the last revision and current one?
<Edulix> bzr diff -1.. or something like that?
<LeoNerd> Theuni1: It sounds like you're worrying about intentional deletes from, say, an audit perspective; rather than accidental ones during normal workflow
<Peng_> Edulix: bzr di -c -1?
<Peng_> Edulix: That shows what changes were introduced by revision -1 (aka the most recent revision).
<Edulix> Peng_:  thanks
<bob2> Theuni1: ask on the list
<spiv> Theuni1: you can always deny developers direct write access to the central branches, and make them go via a gatekeeper tool like PQM (https://launchpad.net/pqm).  That's probably overkill, and with DVCS it will always be possible for a dev to make a non-central branch that you don't even know exists.
<njpatel> Hey, is there something like svn:externals for bzr?
<james_w> njpatel: not yet
<james_w> well, there is, but not production quality
<james_w> hopefully in a month or two that will change as Aaron is working on it
<njpatel> james_w: hey! I thought as much :)
<njpatel> cool, it would be pretty useful
<vila> igc: back ?
<spiv> lifeless: fresh comment on http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html btw
<igc> vila: hi
<vila> igc: groupcompress has evolved quite a bit with the introduction of the python implementation, I'm about to push it to bcc
<vila> bbc even
<igc> vila: can you merge my code cleanups easily?
<vila> I don't think so
<vila> igc: let me try
<igc> vila: thank-you
<vila> igc: :-/ conflicts all over the place as I fear
<vila> The main part you modified has been split into implementation specific classes and some of your points were already addressed, the conflicts are a total mess
<igc> vila: it shouldn't be too hard, though messy, to apply the changes by hand
<igc> vila: most of them are assert -> AssertionError
<igc> and some variable renaming & docstring corrections
<vila> I'm about to start again on the assertions
<igc> vila: I guess I can apply them tomorrow by hand
<igc> but I'd appreciate any you knock off tonight
<vila> igc: I think it ill be eaiser for you to see what still applies tommorow, I'll try to see what I can do until then
<igc> vila:np
<Theuni1> spiv: pqm seems to be overkill indeed, as handling *many* small projects with it seems to have too much overhead.
<Theuni1> bob2: I probably will.
<Theuni1> spiv: Actually I kinda also worry about accidental deletes. Not so much toolwise (although bzr push did at some point screw up branches on LP having to delete them) but more from the perspektive that e.g. in Subversion creating or deleting a branch is a managed operation under SCM perspective.
<Theuni1> Which allows me to get notified when new branches get created destroyed. One of the purposes of DVCS obviously is not having to do that, but I think it might be a worthwhile scenario to support if wanted.
<spiv> Theuni1: if you require that all access is via a smart server, you could do that.
<Theuni1> spiv: interesting. that was one of the answers i hoped for. i find the documentation of the smart server a bit lacking. ;)
<Theuni1> I'll digg deeper into the smart server then.
<spiv> Theuni1: well, except that there's no way to delete branches via the smart server yet (or with the "bzr" command in general)
<Theuni1> I'm fine with that for now. :)
<spiv> Theuni1: but if/when the command does, the smart server should export a hook point you can use to find out about
<Theuni1> Can the smart server export multiple branches of multiple shared repositories?
<spiv> The basic tool you probably want is the "post_change_branch_tip" hook.
<spiv> Yes, it just serves a filesystem.
<Theuni1> Even more interesting.
<Theuni1> I wonder whether I'm blind or the docs are evading me.
<spiv> (Or a bzr transport, in fact, you could write your own virtual fs...)
<Theuni1> I'm happy not to write too much tool-stuff myself. ;)
<spiv> Some caveats: the smart server still allows arbitrary file-level operations that won't trigger any hooks, so someone could still delete stuff and what have you by scripting with bzrlib.
<Theuni1> I didn't quite get the ending of that sentence.
<spiv> (Although we're getting closer to being able to turn that off; most of the operations are now done through higher-level network RPCs rather than file RPCs)
<Theuni1> spiv: Exactly those higher-level RPCs is what I'm looking for.
<spiv> Well, you don't really want to be dealing with RPCs, you want to use the hooks.
<spiv> post_change_branch_tip is the one you want.
<Theuni1> Right.
<Theuni1> But you need to make your own abstraction over the file RPCs to achieve that ;)
<spiv> Also, you want to set append_revisions_only in your branches' branch.conf probably
<spiv> The caveat about the file RPCs is just to say that it isn't watertight yet.
<spiv> It will be.
<Theuni1> Would the smart server be able to enforce that for all branches it handles?
 * spiv -> gone
<Theuni1> spiv: thanks a lot!
<Theuni1> Even if there's stuff in the future, I'm happy to hear about the direction you're going.\
<Theuni1> I'll look into the smart server.
<jelmer> moin
<ivangarcia> hi guys, I'm having a problem when pushing the code of my project
<ivangarcia> i got this error
<ivangarcia> bzr launchpad-login chaos.proton
<ivangarcia> bzr: ERROR: Connection error: curl connection error (SSL certificate problem, verify that the CA cert is OK. Details:
<ivangarcia> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed)
<ivangarcia> on https://launchpad.net/%7Echaos.proton/%2Bsshkeys
<ivangarcia> any help ?
<james_w> it looks like you need to make curl aware of the CA certificate
<vila> ivangarcia: try installing ca-certificates >
<ivangarcia> hmm, I have slackware, is there a package for it?
<vila> ivangarcia: I don't know, but then you'd better search what ssl implementation curl is using and whether or not there is such a thing as CA certificates installed system wide
<ivangarcia> thks vila
<vila> ivangarcia: if you don't care about certificate validation, you can also just use the urllib based http implementation instead of the pycurl one
<vila> ivangarcia: if you find the certificates but can't make curl/pycurl find them, you may want to look into bzrlib/transport/http/ca_bundle.py which gives some hints (mostly used on windows, but should apply in your case too)
<vila> ivangarcia: roughly, you make the env variable CURL_CA_BUNDLE points to the appropriate ca-bundle.crt file (*finding* that file is left as an exercise ;-)
<jam> vila: did you spend time working on resolving Ian's cleanup patch? Or should I go ahead and do that?
<vila> jam: I'm doing it as I replace the assertions, go fix InterDiffering ;-)
<jelmer> vila: Submitted a fix for 256612 >-)
<jelmer> bug 256612 I mean
<ubottu> Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612
<vila> jelmer: will look into it
<jelmer> vila: thanks
<jam> vila: do you have a quick list of the test that is failing because of "inter-differing"?
<jam> I think I have a fix, and just don't want to wait for everything to finish
<vila> jam: -s bt.per_repository.test_fetch.TestFetchSameRepository.test_fetch_to_knit3 (for the 2 errors)
<vila> jam: -s test_fetch.Test1To2Fetch.test_two_fetch_changed_root -s test_fetch.TestFetch.test_fetch_incompatible (for the 2 failures)
<jam> vila: the "test_fetch_to_knit3" has been fixed, I'll work on the other
<vila> jam: yeah :)
<jelmer> igc: are you at PyCon?
<mwhudson> jelmer: no
<jam> vila: the other two tests now pass
<jam> So I've fixed the 4 cases above
<jam> any others?
<igc> jelmer: Brisbane and about to go to sleep :-)
<jam> igc: it is what, 5am there?
<jam> ah, I guess only 1:30am
<vila> jam: let me see... 4err, 3fail - 2err -2fail -2err, that leaves only the asserts :)
<jelmer> igc: ahh :-)
<igc> jam: 1.24 :-)
 * jelmer isn't used to seeing Australians on IRC around dinner time :-)
<vila> jelmer: dinner at 17h26 ? :-)
<igc> jam: trying to put the eol issue to bed. It just refuses to die because every man and their dog has an opinion :-)
<jam> igc: at least their cats leave you alone :)
<igc> small mercies
<jelmer> vila: traditionally dinner time in .nl is around 6
<jam> igc: for what its worth.... I think your final "native" and "native:crlf" for people that really need it is a decent proposal.
<jelmer> vila: not that I ever eat before 8 :-)
<jam> I'm not 100% sure that the content filtering stack is 100% right, but it is probably good enough for what we want
<jam> (I think I would rather register a handler for the property name (eol) and then have it passed the value, and it returns the actual filters at that time)
<jam> but hey, you wrote it :)
<jam> I didn't
<igc> anyhow, I just need lifeless to not block releasing a 1.14 format and to get a majority consensus on eol naming and it's done and dusted
<igc> jam: there is a fallback method that does exactly that: value -> stack
<jam> of course, I can throw a big wrench, should it be called "eol" :)
<igc> thanks to jelmer bugging me about it
<jam> igc: yeah, but it is a bit cludgy versus doing that from the beginning
<igc> jam: you get both - dictionary lookup + lookup function - and can use whatever makes the most sense
<igc> jam: and it's internal-ish
<igc> getting UI consensus is the harder issue it seems
<phinze> is there a way to prevent users from committing changes directly to certain files in a branch
<jam> igc: its internal ish, but hard to change for compatibility reasons
<igc> anyhow, time for bed
<phinze> and only letting them be changed by merges?
<igc> night all
<jam> phinze: no
<jam> what is your use case ?
 * phinze is having trouble in dev group with constant mistakes of people committing changes to a shared library too far downstream
<jam> phinze: so the issue is that in a distributed system, you don't really have any control over individuals machines ...
<jam> Providing a way to help people realize they didn't actually want to modify something
<jam> is something we would be interested in
<jam> but ultimately, the point of distrbuted VCS is that people get to do what they want
<phinze> right, but when they push to a shared location we can yell at them
<phinze> the hooks are there in order to examine changed files pre-commit and conditionally reject, no?
<jelmer> jam: was there a conclusion about whether subtrees (even in disabled form perhaps) were going to make it into the bbc format?
<vila> jelmer: both patches reviewed
<vila> jam: try -s bt.interrepository_implementations
<vila> jam: 14 errs and counting :)
<jelmer> vila: thanks, much appreciated
<jam> jelmer: the serializer will support subtrees
<jam> the "supports_subtrees" flag will probably be set to False
<jam> vila: are those new, or ones we just didn't see before?
<vila> new they all say 'KnitPackRepository' object has no attribute 'supports_tree_reference' so probably related to your last fixes
<vila> jam: also -s test_fetch.Test1To2Fetch.test_fetch_ghosts errors with KnitPackRepository('file:///tmp/testbzr-lKx3YV.tmp/bzrlib.tests.test_fetch.Test1To2Fetch.test_fetch_ghosts/work/tree/.bzr/repository/') has no revision ('ghost-parent',)
<jelmer> jam: neat
<vadi2> Hi. It seems the 64bit package for intrepid from the ppa is not installable, there is an error: http://paste.pocoo.org/show/110454/
<phinze> jam: so re above, conceptually are the pieces there for me to tie together to have a pre-commit hook on a certain shared branch that checked modified files and rejects commits if protected files are modified and the commit is not a merge?
<phinze> not a merge from a certain branch even
<jam> vila: yeah, I had a typo in there "target.supports..." rather than "target._format.supports"
<jam> weird that the other tests started passing
<vila> grr, C-w is cut damn it, not close window, or vice-versa...
<jam> vila: yeah, I ran into that with ^L, which is refresh in a lot of windows, but is "clear the screen" in Pidgin
<jam> I had the problem because there was something about Vim + Ubuntu that was causing it to not draw all characters all the time
<jam> so ^L was needed to actually show the local content
<jam> anyway, 3915 should fix those intertree test failures
<vila> I have less problems under OSX :)
<vila> I mean, I *still* have the problem with M-w and clower-w but M-w is copy :)
<vila> s/clower/clover|apple|whatever/
<vila> jam: and no more asserts
<jam> vila: so intertree all pass here
<vila> jam: I'll push as soon as the test pass
<jam> sorry interrepo
<vila> jam: I pulled, full test suite running
<vila> jam: and also running in the branch I started for the asserts, I'll appreciate if you could have a look at them for typos or better descriptions once I merge them in bbc
<vila> so virtually we have a bbc passing tests :)
<jam> ah, virtual test suites :)
<rryan> Hi -- (I hope it's ok to ask bzr questions in here) I'm working on Mixxx, and we use Launchpad. We're migrating to using bzr from svn on sourceforge.
<rryan> We have a release branch that all our developers are working on, but when any of us do merge/commit/push to both pull in changes from upstream and push local changes to the LP release branch, the history view on LP replaces the merged log entries with the 'merged' message from the developer that did the merge. How can I prevent this?
<Kinnison> The branch you pushed had the merged message as its commit
<Kinnison> that's expected
<Kinnison> It's only if you drill into that revision that you'd see the individual commits
<Kinnison> If you want to see what the merge actually merged, then get your developers to write more useful merge change messages :-)
<Kinnison> consider https://code.launchpad.net/~aranha/aranha/mainline (one of my personal projects)
<Kinnison> all the commits are merges
<Kinnison> because I work on branches, and a robot merges that branch onto mainline
<rryan> Kinnison : yea I see that -- when I push, its like I replace the remote branch's history with the history with respect to my branch.
<Kinnison> indeed
<vila> jam: you still fail the -s test_fetch.Test1To2Fetch.test_fetch_ghosts
<Kinnison> I strongly recommend the use of a robot-controlled mainline
<Kinnison> I think launchpad may even be able to help with that
<rryan> Kinnison : when I use git, for example, the remote HEAD shows its history with respect to itself. And when I push to it, it shows all of the local commits I made, and a 'merging from upstream' message, but since the merge from upstream was already in upstream, it keeps those log messages in the history as they occured.
<Kinnison> rryan: the history of what you merged is still present, it's just not rendered by default
<rryan> Kinnison : I know, I see that I can drill down to the merged branch to see the previous commits. What I'm wondering is, can I use bzr in such a way that it won't take other people's commits out of the main branch history?
<luks> rryan: there is really no technical difference, it's just a display issue
<Kinnison> always merge into the mainline, don't merge the mainline into you?
<Kinnison> So have your mainline branch, then have a feature branch you work on
<Kinnison> then you pull your mainline, merge your feature, and push your mainline
<Kinnison> that way you don't disturb the mainline history
<rryan> Kinnison : Ah... now I see why that is happening. Thanks a lot for your help
<rryan> I'll switch to using it that way
<Kinnison> OOI, any launchpadders here right now?
 * Kinnison is wondering how to upgrade a branch which is a mirror
<vila> jam: assert cleanup pushed as 3916
<jam> vila: /cheer, I'm fixing up that test, I understand why it is failing
<vila> jam: yeah :) Thanks, you make my day end nicely
<vila> jam: I may pass around later, but no promise...
<jam> rryan: there is a flag "append_revisions_only" that you may be interested in.
<jam> You can set "append_revisions_only = True" in branch.conf
<jam> and then the bzr client will refuse unless you merge to mainline first
<jam> (it will refuse the 'push')
<beuno> mwhudson, ^^
<beuno> how do you upgrade branches that are mirrored?
<jam> beuno: upgrade the source branch
<jam> the mirror script auto-detects
<mwhudson> right
<rryan> jam : I see -- thanks
<jam> and wipes and starts over
<beuno> ah
<Peng_> Very bandwidth-efficient. :P
<jam> Peng_: especially when you upgrade the repository for 100 shared branches...
<Peng_> jam: Auto-stacking is a big help.
<jam> which then takes enough bandwidth that lp times out trying to mirror 1 of them :)
<mwhudson> well
<vila> when in doubt... use more bandwidth ?
<Kinnison> jam: noted, thanks
 * Kinnison won't upgrade the source repo until his new colo box is in place
<Kinnison> so a few weeks of annoying messages so far
<Kinnison> and a few weeks left :-(
<Kinnison> Thanks
<Peng_> How gigantic is the repo? It's not a big deal.
<Kinnison> Oh this is not big
<Kinnison> but I can't upgrade the source repo until I can upgrade bzr on the colo box (which is using packaged bzr so I have to do the OS upgrde, which means the new machine really)
<jam> Kinnison: so any more LP will stack mirrored branches, so it isn't as big of an issue
<Kinnison> jam: nod.
<jam> however, that wasn't the case 1-2 years ago when I upgraded my repo
<jam> from knits => packs IIRC
<bialix> jelmer: ping, have a question about rebase
<jam> and that caused LP to timeout on mirroring all of my branches
<Kinnison> aye, I'm still on knits in this repo
<Peng_> It won't stack them if they're in a pre-1.6 format (both the repo and branches).
<Kinnison> Is it now possible to branch with a horizon then? (talking of stacking)
<bialix> jam: hi
<jam> hi bialix
<jam> I just met Andrew
<bialix> jam, jelmer: can you suggest something about error http://paste.ubuntu.com/141559/
<bialix> jam: :-)
<jam> I don't really know about the rebase plugin
<bialix> jam: but errors come from bzrlib
<jam> it sounds like it is setting "kwargs={'author':XXX} and author=YYY"
<bialix> rebase try to write original author with --author option
<bialix> my problem occurs when I'm trying to rebase the same branch several times
<bialix> jam: I'll try to look for the kwargs, as you said.
<bialix> jam: are you still at PyCon?
<jam> bialix: yep
<bialix> :-)
<jam> vila: ok, that fetch test is now fixed, committing once the subset tests finish
<vadi2> It seems the 64bit package for intrepid from the ppa is not installable, there is an error: http://paste.pocoo.org/show/110454/
<Peng_> So, who wants a really trivial patch to a couple error messages in brisbane-core? :D
<NfNitLoop> Awww.  Just saw the news that Python is going with Hg. :/
<NfNitLoop> according to the post, "few (except Canonical employees) seem to like Bzr."
<NfNitLoop> !?
<NfNitLoop> Does Bzr have an image problem I'm unaware of? :)
<LeoNerd> I dunno.. I tend to pick tools on their merits, not their popularity
<NfNitLoop> Yeah, I agree.
<NfNitLoop> (though buy-in can't be completely dismissed in a DSCM.)
<Peng_> LeoNerd: Popularity is a factor. Popular tools are more likely to be improved and maintained.
<Peng_> LeoNerd: And people will write better converters to new, better VCSes. :D
<jelmer> wait, mercurial is a VCS? I thought it was just the name of one of Bazaars repository formats ;-)
<Peng_> Ouch.
<jelmer> (Although I guess this is a good reason to improve bzr-hg a bit more..)
<vila> jam:  @bbc ./bzr selftest -x '(?i)loom' ==> OK (known_failures=14)
 * vila goes back  cooking
<Peng_> vila: Congrats.
 * vila pass to jam ;-)
<jelmer> niice
<bialix> jelmer?
<Peng_> He was here 10 minutes ago, fwiw
<jelmer> bialix: hi
<bialix> hi jelmer
<bialix> did you saw my pastebin about 40 min ago about rebase error?
<bialix> may be you can suggest something how to workaround it
<bialix> jelmer: http://paste.ubuntu.com/141559/
<bialix> I've tried to rebase the same branch several times, because I want to throw away some revisions
<jelmer> bialix: I've pushed a change that I think should fix it
<jelmer> bialix: also, removing revisions from a branch isn't really the purpose of rebase
<bialix> can I run rebase-continue, or should I start my rebase again from the original branch?
<jelmer> rebase-continue should work
<bialix> jelmer: but rebase do the right thing
<bialix> I mean it can remove revisions
<bialix> btw, jelmer, while I'm here. To rebase one revision e.g. N I should use syntax -r N..N+1
<bialix> i.e. your plugin don't use last number
<bialix> is it intended?
<bialix> when I need to rebase tail of the branch I have to use -r N..
<bialix> it's not obvious from rebase doc
<bialix> jelmer: I found very neat usage for rebase to perform cherrypicking with history
<bialix> IIUC, I've got almost the same result as git cherrypicking does
<jelmer> bialix: different from "bzr merge -c" ? as that's all that rebase does, basically
<bialix> yep ,different from merge -c
<bialix> I've started heavily using daggy fixes
<bialix> and rebase in help here
<bialix> it seems your fix helps, and rebase-continue going forward
<bialix> jelmer: big thanks
<bialix> jelmer: you save my day, many many many thanks. rebase is great tool to remove revisions, it does the right thing!
<bialix> even if you don't plan to use it this way
<bialix> :-)
<jelmer> bialix: how is rebase behaving different from "bzr merge -c" though?
<jelmer> bialix: as "bzr merge -c" is basically what it's doing under the hood
<bialix> rebase allows me to keep the log messages
<bialix> sometimes I'm cherrypicking several revisions in a row
<jelmer> ah, ok
<bialix> rebase helps because it does the boring job: transplate revisions meta-data
<bialix> it's a huge gain for me
<bialix> in the past I've often copy-pasted log messages when I've committed cherrypick. Now I can use rebase
<bialix> it's incredible
<jelmer> cool :-)
<bialix> rebase --onto rocks :-)
<bialix> btw, what was main reason for --onto in first place?
<jelmer> bialix: being able to rebase onto a revision not the last revision on your current branch
<bialix> you mean upstream branch, I guess
<jelmer> yeah
<bialix> jelmer, I can write small recipe how I do cherrypick with rebase. Actually I will write it for my Russian bzr blog. I can translate it if you like to put it somewhere into rebase cookbock
<jelmer> bialix: I'd rather not encourage people to use rebase that way
<jelmer> bialix: instead, bzr replay should be used (but can't handle conflicts yet)
<bialix> hmm,
<bialix> replay missing --onto
<bialix> what the intended usage of replay?
<bialix> and where it different from rebase?
<jelmer> bialix: replay is intended for exactly that - replaying specific ranges of revisions on top of a different parent revision
<jelmer> bialix: rebase is intended to replay the extra revisions your local branch has on top of an upstream branch
<bialix> if I need to move range of revisions back in the history
<bialix> for me both rebase . --onto and replay do the same
<bialix> I need to play with replay, never used it before
<bialix> rebase . --onto == does not require additional branch
<jelmer> jam: ping
<jam> hey jelmer
<jelmer> jam: hi
<jelmer> jam: So, I'm looking at adding a new Revision serializer
<jelmer> jam: So that we can get rid of the _escape_commit_message hack in bzr-{git,svn,hg}
<jam> jelmer: basically, it probably just needs to be something on bzrlib.chk_serializer.pack_revision
<jelmer> jam: Should this just be a matter of adding write_revision() / write_revision_string() / read_revision() / read_revision_string() onto CHK_Serializer ?
<jam> or something along those lines
<jam> jelmer: probably, though I would probably make it a class independent
<jam> and test it directly
<jam> and then hang it onto CHK_Serializer
<jelmer> jam: CHK_Serializer base classes from something in xml_serializer, is that historical, or is there actually still XML involved?
<jam> ultimately, we'll probably have to watch out for some of the 'fetch' code
<jam> which may not be casting all the way up to Revision objects
<jam> jelmer: we still *can* go to xml, and we do in some odd circumstances that we would eventually like to get rid of
<jam> certainly we still use the Revision xml
<jam> since we don't have another format yet :)
<jelmer> jam: Right, but there's nothing fundamentally depending on the fact that a Serializer would use XML for revisions?
<jam> jelmer: there might be code that doesn't realize the formats can be different, but there *shouldn't*
<jelmer> jam: I haven't looked at the internals of CHK inventories yet, what sort of encoding do they use?
<jelmer> or is there some place where I could read about that?
<jam> bzrlib.inventory.CHKInventory.to_lines() might be what you are looking for
<jam> if not there
<jam> bzrlib.chk_map.py
<jam> in general, null terminated strings
<jelmer> thanks
<jam> CHKInventory._entry_to_bytes is the serialization of individual InventoryEntries
<jelmer> (I'm asking since it seems to make sense to use something similar)
<jam> sure
<jam> we did get to the point of using '\n' termination
<jam> to be easier on the eyes/line-based deltas
<jam> but for what you are doing, I think null-based strings would be reasonable
<jam> jelmer: oh, and I might recommend grouping content that is likely-to-change separate from content that is 'likely-to-be-the-same'
<jam> but I can think about that once you've done some work
<jelmer> I don't think there would be a lot in revision data
<jelmer> that stays the same
<jelmer> perhaps the committer / revision properties (with "author" and "nick")
<jelmer> I would expect the revision id to change pretty much 100% of the time :-)
<jelmer> parent ids and commit message also change fairly often I would imagine
<jelmer> vila: ping
<BasicOSX> LP hates me today: Timeout error  (Error ID: OOPS-1186H2211)
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1186H2211
<thumper> BasicOSX: this should be fixed with the rollout
<thumper> BasicOSX: it is still slowish to do the revision count query
<thumper> BasicOSX: for the release after this we are rejigging the internals to use a special cache for the counts
<thumper> BasicOSX: which should kill the timeouts on this page for once and for all
<BasicOSX> I liked that LP just hated be :-P
<BasicOSX> %s/be/me/g
<thumper> BasicOSX: I could add some special hate code if you like if you tell me your lp-id
<thumper> BasicOSX: although it might not get past review :P
<BasicOSX> >8-)
<awmcclain> Hi all... is there a way for me to remerge? I merged in some changes on a file I've been editing and accidentally saved over the changes. I don't want to revert my changes since I'd lose my edits.
<mwhudson> rockstar: https://code.edge.launchpad.net/~mwhudson/loggerhead/js-cleanup/+merge/5087
<mwhudson> awmcclain: there's a 'remerge command' which might do what you want
<awmcclain> mwhudson: Is that new since 1.9?
<mwhudson> awmcclain: no, it's ancient
<awmcclain> Great. THank you!
<awmcclain> Oh, also, since we got into a huge hassle with this this morning... what's the best method of undo-ing a bzr add?
<rockstar> awmcclain, bzr revert?
<mwhudson> or bzr rm --keep
<awmcclain> rockstar: Doesn't revert remove the file, though?
<mwhudson> i'm pretty sure reverting an addition doesn't remove the file
<rockstar> awmcclain, it only works if you haven't committed though.  In that case, do what mwhudson says.
<alevine> is there any way to set a parent location as permanent...so if I do bzr push without any options it always pushes to that location?
<mwhudson> alevine: --remember
<mwhudson> alevine: but the default location for push is the push location, not the parent location
<alevine> mwhudson, thanks. what is the parent location?
<mwhudson> alevine: the default for pull/merge
<alevine> thanks
<awmcclain> Even though sometimes I hate it, I have to say, I love, love, love bzr.
<igc> morning
<jelmer> 'moin Ian
<lifeless> hi igc
<igc> hi lifeless, jelmer
<igc> bbl
#bzr 2009-04-01
<lifeless> spiv: ping; my place is available if you're interested; or I can head north.
<Pegasus_RPG> hello there.
<Pegasus_RPG> If a repo's URL changes, can bzr be told of that change or do people need to do a new checkout/branch?
<lifeless> Pegasus_RPG: 'bzr switch' can be used to change what things are checkouts of
<lifeless> branches don't care, they just need to pass the url to the next pull/merge
<lifeless> e.g. 'bzr pull URL --remember'
<Pegasus_RPG> lifeless: ok, so a user needs to issue both a switch and the pull --remember?
<lifeless> Pegasus_RPG: either/or
<Pegasus_RPG> oh ok cool
<Pegasus_RPG> thank you muchly
<lifeless> if they have a checkout, switch, if they have a branch, pull/merge --remember
<Pegasus_RPG> (The #mixxx teamis getting our feet wet)
<Pegasus_RPG> with bzr
<lifeless> cool
<Pegasus_RPG> reading "Bazaar was made for merges" made me happy
<Pegasus_RPG> (I recently had to merge one of our branches to trunk on SVN...not fun)
<Pegasus_RPG> btw, is there any decent Linux GUI for BZR? (Like KDESVN is for svn?)
<lifeless> http://www.mixxx.org/ ?
<Pegasus_RPG> yep that's us
<lifeless> for kde, you should look at qbzr
<Pegasus_RPG> ok thanks
<lifeless> for gnome there is gtk-bzrn
<lifeless> *gtk-bzr*
 * Pegasus_RPG has kde and was not impressed with Olive
<lifeless> olive is gtk based
<lifeless> you may like qbzr more
<lifeless> and please file bugs about the things you'd like different
<lifeless> they are both under active development
<Pegasus_RPG> OK cool. Thanks again
<shtylman> can I create bazaar users without creating system users? I guess similar to how subversion could create users?
<spiv> lifeless: I'll head south soon, just sending a fix for the get_parent_map bug
<lifeless> cool
<mwhudson> shtylman: svn doesn't really know about users either, do you mean the apache integration?
<mwhudson> shtylman: but the answer is approximately "no"
<shtylman> mwhudson: I see...so places like launchpad...they create system wide uers?...lets say I can do that...how then do I limit the user to bzr only?
<shtylman> is that possible...?
<mwhudson> shtylman: launchpad has a custom ssh server
<shtylman> ahh
<mwhudson> shtylman: you can play tricks with .ssh/authorized_keys though
<mwhudson> (i think this is what bitbucket does for ex)
<shtylman> mwhudson: k...thanks..I will look into some alternatives
<jelmer> lifeless: did my InterBranch.pull patch look ok to you other than the issues you raised?
<lifeless> jelmer: I haven't looked all that closely; as long as there is a per_interbranch test parameterisation done sanely, its probably good
<jelmer> lifless: yeah, I think that is the case (we already had the infrastructure for InterBranch.update_revisions())
<beuno> hello hello
<beuno> as of yesterday
<beuno> bzr is amazingly slow
<beuno> https://pastebin.canonical.com/15795/
<beuno> I'm pulling a branch with a few small changes
<beuno> and it's taking ages
<beuno> is there anything in bzr.dev that would provoke this?
<beuno> not sure what all those "Repository.get_parent_map" are
<beuno> or RemoteSSHTransport.readv 5 offsets => 2 coalesced => 1 requests (2)
<lifeless> its falling down to vfs
<beuno> ah
<beuno> why would it do that?
<lifeless> because lp is still running 1.12
<beuno> well, it was working fantastically well up until yesterday
<beuno> and edge says 1.13: https://code.edge.launchpad.net/
<lifeless> you're looking at the wrong things
<lifeless> and edge lies vis-a-vis the server
<lifeless> the 3 minute gap between lines 11 and 12 is the problem
<beuno> ah
<lifeless> the rest is 17 seconds long
<lifeless> if you have ssh connection sharing, and suspended with a master ocnnection open, that might fit
<beuno> ah, I do
<lifeless> nothing to do with bzr :)
<beuno> I see
<beuno> but something must of changed to suddenly make this a problem, no?
<beuno> even though it's my settings
<lifeless> no
<lifeless> its been latent in your ssh config, or perhaps a ssh change on your system
<beuno> .ssh/config:  https://pastebin.canonical.com/15796/
<lifeless> beuno: ...and?
<lifeless> beuno: kill your master connections, try the pull again, if its not faster, we can dig deeper
<beuno> ehm
<beuno> lifeless, as usual, you're right
<beuno> thanks
<lifeless> I know :)
<AfC> lifeless: you don't *really* expect us to let THAT stand, do you?
<AfC> :)
<lifeless> weeeel
<lifeless> l
<lifeless> lunching
<lifeless> jelmer: the check devs have said 'will be integrated in april, or we'll give you commit and you can do it yourself' :)
<ivan> The docs say "bzr log -r date:yesterday..date:today" should give me all of today's revisions, but it only returns revision 1
<ivan> but "bzr log -r date:yesterday.." works as I expect
<ivan> is "today" strange or are the docs wrong?
<spiv> Possibly both ;)
<lifeless> you may have found a bug
<ivan> heh, "date:today..date:yesterday" still returns revision 1
<fullermd> Actually, date:today.. gives you all of today's revs...
<ivan> it does
<lifeless> ivan: did you start your project today?
<ivan> yep
<lifeless> so, date:today is 12am today
<lifeless> the start of today
<lifeless> I think
<fullermd> date:yesterday..date:today probably gives you all of yesterday's revs, and the first rev from today.
<fullermd> Which would fit.
<ivan> date:1999-01-01..date:2000-01-01 still gives me r1 :)
<lifeless> something to read http://dabeaz.com/coroutines/
<fullermd> ivan: date: has a lot of rather scary dark corners  :)
<ivan> I really like bzr, even after just a few hours
<fullermd> For instance, the latest rev [I have] of bzr.dev has timestamp: Tue 2009-03-31 02:11:33 +0100
<fullermd> But date:2009-03-31 doesn't find anything for me, because that rev is from 2009-03-30 in my TZ.
<spiv> ivan: we like it too ;)
<ivan> are there any consequences if I'm inconsistent about which branch is my mainline?
<ivan> it doesn't really seem like it, given how revision numbers work
<lifeless> ivan: mainline is just social, so you can organise however you like
<ivan> thanks
<lifeless> jelmer: ping
<ivan> can I steal the commit message from the (only) change made in a branch?
<ivan> I merge a branch in, then don't want to type the commit message again
<lifeless> ivan: we don't have UI glue to do that; if there is only one change, why not just pull ?
<spiv> An auto-commit-message plugin might be a cute hack.
<fullermd> Actually, maybe using a more full variant (like --short) instead of --line for the merged revs in the commit editor might be helpful.
<ivan> lifeless: i did not know about pull :)
<fullermd> Well, until you get the people who remove the delimiter line accidentally and end up commiting the whole deal as the log message, anyway...   ;)
<vila> hi all
 * fullermd waves at vila.
<lifeless> jml: several new-stacked-branch performance fixes landed today, last one in-train at the moment
<luks> ehm, I hate when qbzr is being presented as a kde application :(
 * vila quietly remove alias kbzr qbzr
<Peng_> BasicOSX: Since you're the current release manager (and poolie's not here right now): There's a question on LP about how the "current release" branch isn't being maintained. https://answers.launchpad.net/bzr/+question/66037
<ivan> i'm trying to use the trunk versions of bzr-git and dulwich to import a git repo, but it dies with some kind of mmap error: http://rafb.net/p/9nnue853.html
<ivan> anyone know what to do? :-)
<ivan> it's ok with allocating 230952 bytes, but fails when allocating 2595068
<ivan> looks like it works if I patch dulwich/pack.py with: supports_mmap_offset = False
<james_w> is there a ulimit for mmap?
<ivan> probably not
<james_w> so it is the size argument that trips it up?
<james_w> it's possibly a bug in python2.6 with the offset, or some calculation of the parameters, because some take page sizes rather than bytes
<ivan> oh, that's bad
<ivan> yeah, it's definitely buggy, reported a month ago
<james_w> oh, what's the link?
<ivan> https://bugs.launchpad.net/bzr-git/+bug/336393
<ubottu> Ubuntu bug 336393 in dulwich "Can't branch on Windows" [Medium,Triaged]
<ivan> and https://bugs.launchpad.net/dulwich/+bug/352998
<ubottu> Ubuntu bug 352998 in dulwich "supports_mmap_offset-related crash with Python 2.6" [Undecided,New]
<ivan> I don't mind fixing every program that I run, though it does get exhausting :)
<james_w> ivan: could you do it again, but print all the parameters this time?
<james_w> it would be good to know what they all are, thanks
<ivan> PARAMS ARE 6 230952 1 0finding revisions to fetch 0
<ivan> PARAMS ARE 10 2595068 1 12ding revisions to fetch 6
<ivan> bzr: ERROR: mmap.error: [Errno 22] Invalid argument
<ivan> the param order for the print matches mmap.mmap(f.fileno(), size, access=access, offset=offset)
<james_w> thanks
<james_w> I'll drop that in the bug
<ivan> :-)
<james_w> so the differences are that the size is greater, and that an offset is being used
<james_w> and that it's a different fd I guess
 * SamB lols at Guido's new title
<SamB> or, uh, joke title
 * SamB wishes gmail would just gray out the Archive button where it is not appropriate
<LarstiQ> SamB: I'm partial to barry's title too :)
<SamB> LarstiQ: but it's not as meaningful a word, I think
<LarstiQ> SamB: true, true.
<SamB> though it *is* delightfully silly
<SamB> and Python people are just silly enough that that message would actually be quite plausible if it weren't April 1st
 * jelmer wonders what he is missing
<LarstiQ> jelmer: http://www.python.org/dev/peps/pep-0401/
<jelmer> lol
<vila> lifeless: ping, selftest --parallel works again, care to review ?
<Peng_> They really did add the barry_as_FLUFL future though.
<Peng_> http://svn.python.org/view?view=rev&revision=70945
<vila> james_w: builddeb tests failing it may be due to recent changes in commit you may want to check
<Peng_> But I think it just adds the <> operator, not the print statement.
<james_w> vila: I don't see it, have a traceback for me?
<vila> james_w: ./bzr selftest -s bzrlib.tests.test_msgeditor.MsgEditorTest.test_generate_commit_message_template_hook with bzr.dev@4230
<vila>   File "/home/vila/.bazaar/plugins/builddeb/__init__.py", line 64, in debian_changelog_commit_message
<vila>     if not commit.work_tree.has_filename(cl_path):
<vila> AttributeError: 'Commit' object has no attribute 'work_tree'
<james_w> urgh
<vila> james_w: The bug may be on bzr side for not being compatible though, you may have a better POV than me in this area
<SamB> darnit, I need to get that flaky RAM and/or motherboard fixed ...
<james_w> vila: yeah, see it now
<vila> james_w: good, I check I had builddeb up to date in the mean time, did I send you a bundle for test failures since 2009-03-16 ?
<vila> james_w: about pristine-tar ?
<SamB> is there an alternative to sed for rewriting many similar URLs in a number of branch.confs simultaneously?
<james_w> vila: got one on Mon, 16 Mar 2009 17:32:11, thanks
<vila> ok
<james_w> it adds the PristineTarFeature
<Peng_> SamB: I'd write a small Python script using bzrlib.
<vila> james_w: just checking it wasn't lost as it doesn't show up on lp:bzr-builddeb
<james_w> I've probably just not pushed yet, sorry
<vila> james_w: np, np, no urgency
<vila> james_w: you may even veto it, your call :-)
<james_w> nope, it's merged in my local branch :-)
<SamB> er, basically I meant "plugin"
<ploum> Hello
<ploum> I've a problem with bazaar
<ploum> all my pushes to my local server are frozen at :
<ploum> \     17kB @   15kB/s
<ploum> not all, it depends on the repository
<ploum> some are frozen, some are working normally
<ploum> but branch is still working normally
<Peng_> When dealing with Launchpad, what type of URL do you think should be used as the parent/submit/etc. location? lp:~foo/bar/baz? http://bazaar.launchpad.net/~foo/bar/baz/?
<jelmer> vila: ping
<SamB> don't forget lp:bar
<james_w> if you let bzr set it with "bzr push lp:foo" then it will write the second form, but that's debated
<Peng_> james_w: Yeah, I know. To use an lp: URL you'd have to edit branch.conf, but I do that all the time anyway, so..
<vila> jelmer: pong
<vila> ploum: what kind of server are you using ? what bzr version (client/server) ?
<jelmer> vila: so, what do you prefer I do in regard to get_username() ?
<jelmer> raise NotATerminal and provide a mock implementation that doesn't and test that, similar to get_password() ?
<ploum> vila: I'm using bzr+http (smart server)
<ploum> vila: the client and the server are both using ubuntu intrepid with bzr from ppa
<vila> ploum: then add 'debug_flags = hpss' in bazaar.conf on the client or -Dhpss on the command line we'll know a bit more
<ploum> after a while (like 5 minutes) I have :
<ploum> bzr: ERROR: Could not acquire lock "(remote lock)"
<vila> ploum: sorry I don't know intrepid version by heart, use 'bzr version'
<ploum> vila: so it should look like : bzr -Dhpss push bzr+http://... ?
<SamB> hmm, apparantly when pages try to use tables for layout, you can improve the way they print out by deleting extraneous cells in firebug ...
<ploum> 1.13
<vila> jelmer: there is no point in not testing code, I mention the two issues are distinct: get_username should check the tty (it will be called *before* get_pasword now)
<vila> that part of get_password becomes irrelevant if you call get_username before get_password, so don't break it
<vila> ploum: the lock should the consequence of a previous ctrl-c no ? use 'bzr break-lock' before bzr pull -Dhpss
<ploum> No revisions to pull.
<ploum> HPSS calls: 9 <bzrlib.transport.http.SmartClientHTTPMedium object at 0x853b82c>
<ploum> now trying push
<vila> jelmer: or get rid of it on the assumption that it is in fact dead code, but then you'll have to propose a solid explanation that it was never needed
<vila> ploum: ghaaa, of course I meant push :)
<ploum> I was not sure if you wanted some information
<vila> ploum: sry
<ploum> so I broke the lock (as you said)
<ploum> no problem, thanks for trying to help me :-)
<jelmer> vila: my point is, if I make get_username() raise NotATerminal then I can't test it
<jelmer> vila: and I have to add a mock implementation of it like get_non_echoed_pw()
<jelmer> wb vila (-:
<vila> jelmer: haaaa, sry, then you should refactor get_non_echoed_password in both implementations
<vila> jelmer: darn ctrl-w again :)
<jelmer> vila: refactor get_non_echoed_password?
<vila> the purpose of get_n_e_p in TestUI is to get rid of the 'echo' constraint, it's a side-effect if it doesn't raise NotATerminal :)
<jelmer> vila: but we won't have a terminal during the tests
<vila> jelmer: I get that and we don't want to raise NotAterminal in most of the cases
<vila> jelmer: let start again
<vila> when get_username|password is called by bzr, we should raise NotATerminal if indeed there is no terminal to query the user
<vila> when testing, we don't want to check that *of course* except to test tht NotATerminal is raised but not the rest of the behavior
<ploum> vila:
<ploum> bzr: ERROR: Could not acquire lock "(remote lock)"
<ploum> HPSS calls: 10 <bzrlib.transport.http.SmartClientHTTPMedium object at 0xa12562c>
<ploum> but I did break-lock before
<vila> ploum: are you alone using that repository ?
<ploum> oh wait!
<ploum> I had to break the lock on the server
<ploum> not on the client
<jelmer> vila: ahh
<vila> ploum: both, but don't do that if someelse is using that repo
<vila> jelmer: haaa too :)
<ploum> maybe should I report a bug so :
<ploum> 1) There's less delay when you cannot acquire a lock
<ploum> 2) It's more explicit about locks
<jelmer> vila: so we should have a helper for get_username() that gets overridden in TestUIFactory and just does checking for whether there's a terminal?
<ploum> vila: I'm alone on that repository
<vila> ploum: ok, so a bare 'bzr break-lock' should propose you to break both locks except if you mess things up before by breaking only the remote one
<vila> jelmer: TestUIFactory shouldn't raise NotATerminal, it's here to be used *without* a terminal anyway, there should be another test for checking NotATerminal
<ploum> vila: I think so
<vila> which doesn't use TestUIFactory
<ploum> not everyone a SSH access to the repository
<vila> jelmer: whether there is a single method in [Test]UIFactory to handle that is up to the first dev that needs it :-)
<vila> ploum: 'not everyone' is not exactly the same as 'only ploum' :)
<ploum> vila: indeed. I mean : I have ssh access to my repository so I can break a lock if needed but what about people that cannot do that ?
<vila> ploum: if they can't write they can't lock
<vila> if they can't lock they don't need to break locks
<ploum> but if you use bzr+http, you can create a lock
<ploum> without being able to breaking it
<vila> if you use bzr+http you can lock and you can break locks
<ploum> that's why I didn't understood you
<ploum> I was not aware of that
<vila> ploum: you do 'bzr break-lock bzr+http://whatever
<ploum> I logged into the server with SSH to break lock at that place
<ploum> sorry
<ploum> thanks for the information
<vila> ploum: np
<ploum> thanks for the help
<ploum> I managed to push my commits
<vila> jelmer: so basically I think prompt() should take care of NotATerminal *and* prompt encoding and then only prompt needs to be redefined in TestUiFactory
<vila> jelmer: it sounds rather unfortunate that this was done by get_password so far...
<jelmer> vila: well, get_password() doesn't use prompt() afaik
<jelmer> since getpass() prints the prompt for it
<vila> jelmer: that's one facet of the bug :)
<vila> it should use self.prompt and then pass an empty prompt to getpass
<jelmer> vila: but would it be ok for now to just raise NotATerminal from get_username() ?
<vila> jelmer: you mean 'I found a bug, but I'd like to not fix it now but instead duplicate the bogus code, is that ok' ? :-)
<jelmer> basically, yes :-)
<vila> jelmer: hmmm, I can fix it, but then we'll conflict, wait a minute
<fullermd> Mmph.  I wish there were a way to pass defaults to log formatters...
<vila> fullermd: nag igc or better expose your use case to the ML, this is under discussion
<fullermd> Well, my use case is that I WANT to see the merge revs on --long all the time   :p
<fullermd> "Undo what you did" is rather obstreperous naggery.
<vila> fullermd: 'My preferred use case is not the default one anymore' is a valid user feedback in my book
<vila> fullermd: and when it comes to UI tweaks, user feedback is *gold*
<Peng_> fullermd++
<vila> Peng_: mail-the-ML++
<vila> log and log formatters are actively worked on, the more feedback we get....
<fullermd> I think I'm over my quota of griping-ish mails to the ML for one day.
<vila> fullermd: quota++
<Peng_> vila: Sorry, I just hit my quota of getting off my ass and doing things for the week.
<vila> Peng_: quota++
<Peng_> Exception: IntegerOverflow
<Peng_> Sorry, it's limited to a 2-bit signed int.
<jelmer> vila: ok
<antoranz> huys, when is support for "Doesn't matter the EOL format" coming?
<Peng_> antoranz: ...1.14?
<Peng_> antoranz: It should land in bzr.dev, uh, yesterday or tomorrow or something.
<antoranz> really? cause I had read about this feature coming like... a year ago... and I just made a lousy test and it failed miserably
<Peng_> antoranz: It's been in progress for ages.
<antoranz> and it's really coming in 1.14? or it's just a guess?
<Peng_> antoranz: The required infrastructure has already been merged. The EOL stuff itself has either been merged, is up for review, or is projected to be up for review within 48 hours; I don't remember which.
<antoranz> ok.... sounds like it's coming finally
<antoranz> by the way... did you hear that microsoft is using git for version control? http://www.fsdaily.com/HighEnd/Microsoft_uses_git_for_version_control
<abentley> antoranz: It's possible that MS *is* using git, but that article is an april fools' joke.
<antoranz> damn! am I so obvious? :-)
<ricardokirkner> hi guys.. I am having some issues with merges..
<ricardokirkner> the thing is I have two svn repos
<ricardokirkner> I need to merge
<ricardokirkner> i tried to use bzr for this
<ricardokirkner> I created a bzr branch for each branch in the svn repos
<ricardokirkner> then I tried to merge between the bzr branches
<ricardokirkner> and I got the error bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<jelmer> ricardokirkner: svn repositories or svn branches?
<jelmer> ricardokirkner: I mean, do they have shared history?
<ricardokirkner> jelmer, I have an upstream repo with branch A and a local repo with branch B (which is a copy of branch A from upstream)
<ricardokirkner> I have worked locally on branch B and now I want to push to upstream
<ricardokirkner> the thing is, the whole development started out with svn, and before being able to change our workflow, I need to push these changes to upstream first
<jelmer> ricardokirkner: upstream svn repo and local svn repo?
<ricardokirkner> and I would like to preserve history
<ricardokirkner> jelmer, yes
<jelmer> ricardokirkner: but how was branch B originally created from branch A?
<ricardokirkner> jelmer, as far as I remember, svn export ; svn import
<ricardokirkner> I know its not ideal, and that is the reason why bzr cannot find a common ancestor
<ricardokirkner> but, cannot it be told to be 'more intelligente' :-)
<ricardokirkner> ?
<jelmer> ricardokirkner: you can force bazaar to do the merge by using the "-r0..-1" argument to merge
<jelmer> ricardokirkner: but it'll most likely result in a large number of conflicts
<fullermd> That sounds like it would yield a staggeringly terrible result...
<jelmer> as there is no shared history information
<ricardokirkner> jelmer, I try and let you know
<jelmer> moin mwhudson
<mwhudson> hi jelmer
<james_w> vila: it's a test isolation problem. The tests don't clear the msgeditor hooks.
<james_w> they aren't registered in hooks.known_hooks, but that registry is a little underdocumented
<beuno> jelmer, what's the deal with bug 336749?
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [Undecided,Invalid] https://launchpad.net/bugs/336749
<beuno> ted is getting desperate  :)
<jelmer> beuno: it's a bug in ghost handling in VersionedFiles
<jelmer> beuno: if you add a text with a ghost parent it blows up when re-extracting that text
<beuno> jelmer, so I need to chase lifeless about it?
<jelmer> beuno: yeah
<beuno> jelmer, thanks
<jelmer> beuno: I tried to see if I could figure out what was causing it, but couldn't easily find the issue
<jelmer> I'm also not too sure what's happening exactly when storing packs
<beuno> inkscape is in a bad situation because of it, because they're last import is broken
<jelmer> something somewhere is assuming that the delta parent is the left hand side parent
<jelmer> yeah, so I've understood
<beuno> so they're in a situation where they either manage to do the import, or have to switch or something
<jelmer> LarstiQ has a similar issue with his company repo
<jelmer> and there are more people that have hit this problem
<jelmer> beuno: I've marked this particular bug as High already earlier this month
<vila> jelmer: sorry, longer than anticipated and phone calls too, digging the subject anyway, I end up getting rid of NotATerminal anyway, so forget about it, but add the tests for utf8 (unless you know better about what encoding should be used for unicode usernames)
<jelmer> vila: ok
<beuno> jelmer, yeah, saw it, thanks. I'll start chasing people and see where that gets me  :)
<vila> jelmer: I'll submit something about NotATerminal
<jelmer> vila: I'll send a new merge request to the list if that's ok
<vila> see you there :)
<vila> james_w: which tests don't clear ? yours ? bzr ones ? someone else tests ?
<james_w> vila: the general bzr test setup
<james_w> it clears all the know hooks so that doing say "commit" in a test doesn't trigger hooks
<james_w> but fails to clear this hook, so my code runs. The test that fails shouldn't actually run any of the plugin code at all, so that's the real bug.
<vila> james_w: ok, you should file a bug (I'm surprised commit hooks are not registered, but there may be a reason), anyway in the mean time you can also protect you own code, see bzrlib/tests/test_msgeditor.py test_generate_commit_message_template_hook
<james_w> yeah
<vila> jelmer: before I forget ! Make a big fat item in NEWS as GUIs will have to implement get_username now
<vila> jelmer: and also: regarding defaulting to getpass.getuser(), I think the easiest it  to make get_username prompts only if asked (i.e. not prompt by default) grepping for getpass.getuser will give you the call sites, only http doesn't care anymore
<jam> james_w: hooks.known_hooks is a recent addition, *because* of issues like this
<jam> (there were other hook instances *inside* bzrlib that were being missed)
<james_w> sure, I realise that, I'm just trying to work out what to add to it to register this hook point
<jam> james_w: not 100% sure, but basically something like "bzrlib.branch", "Branch.hooks"
<jam> so <module>, <object>
<jam> as names
<mwhudson> jelmer: InterToSvnRepository.fetch needs to support fetch_spec i think
<jelmer> mwhudson: yeah, it doesn't at the moment
<jelmer> mwhudson: when does that break?
<mwhudson> jelmer: bzr get <svn>
<jelmer> mwhudson: that wouldn't use InterToSvnRepository
<jelmer> mwhudson: InterToSvnRepository is used in the case of push
<mwhudson> jelmer: i can only tell you what my eyes tell me
<mwhudson> jelmer: http://pastebin.ubuntu.com/142161/
<antoranz> by the way. when is 1.14 expected/projected to come out?
<jelmer> mwhudson: you're cloning *into* a svn repo?
<mwhudson> jelmer: not deliberately!
<VSpike> My workflow is way too complex .. I get the feeling I'm doing it all wrong
<VSpike> Got a project which consists of a website tree and a library code tree.  I have library/main/... website/main/web/... website/main/lib/... website/branchA/web/... website/branchA/lib/...
<VSpike> I work in two windows VM's on two linux boxes, so i have a sort of master shared repo on one linux box, and replicate the above structure in the master and in both VM's
<VSpike> Trying to push changes around gets very muddled
<VSpike> Especially for the library code
<jelmer> mwhudson: should be fixed now
<mwhudson> thanks :)
<jelmer> mwhudson: of course, it won't actually fix the issue for you, as it will still try to write to the svn repo
<mwhudson> jelmer: jam managed to convert the repository we care about now anyway
<jelmer> mwhudson: is it correct that it tries to write to a svn repo?
<mwhudson> jelmer: how could i tell?
<jelmer> mwhudson: bzr info -v
<jelmer> will tell if you have a svn repo locally
<mwhudson> now it does this
<mwhudson> mwh@starship:~/code$ rm -rf sizer/ && BZR_PDB=1 BZR_PLUGIN_PATH=plugs PYTHONPATH=subvertpy/ ./brisbane-core/bzr get file:///home/crew/mwh/code/codespeak/user/nick8325/sizer
<mwhudson> bzr: ERROR: The branch file:///home/crew/mwh/code/codespeak/user/nick8325/sizer has no revision None.
<mwhudson> mwh@starship:~/code$ bzr info -v
<mwhudson> bzr: ERROR: Not a branch: "/home/crew/mwh/code/".
<jelmer> that's really weird
<jelmer> mwhudson: the first error is bzr masking some other error
<mwhudson> it's possible that this machine has a super-ancient version of libsvn or something
<jelmer> shouldn't matter
<jelmer> mwhudson: bzr decided it wanted to fetch into a svn repo for some reason in the backtrace you posted earlier
<exarkun> pushing to launchpad is taking too long :(
<exarkun> isn't stacking supposed to mean it's super quick
<exarkun> mwhudson: hey where are you
<exarkun> I want to complain
<mwhudson> exarkun: launchpad is still running 1.12 and 1.13 pushing to 1.12 sucks ass
<exarkun> how about 1.11 to 1.12?
<mwhudson> exarkun: if you add the bzr crack-of-the-day ppa it will be better
<mwhudson> exarkun: that should be ok
<mwhudson> exarkun: glyph was complaining earlier
<exarkun> it just took about 8 minutes to push a pyopenssl branch
<exarkun> (and took about as long for one earlier today too)
<mwhudson> exarkun: how does 'mtr bazaar.launchpad.net' look for you?
<exarkun> ~102ms latency
<mwhudson> :/
<exarkun> oh hey
<mwhudson> well, it will be better tomorrow
<exarkun> also 50% packet loss
<mwhudson> if you upgrade to 1.13
<exarkun> level3 for the lose
<mwhudson> ah
<exarkun> okay launchpad is super great I love it. :)
<mwhudson> i don't think we like our isp very much
<exarkun> but hey maybe you guys should switch to udp I hear it is fast
<mwhudson> exarkun: go away
<exarkun> >:)
<mwhudson> i think unreliable delivery is *just* what you want for a vcs
<mwhudson> "i've pushed my changes... probably!"
<fullermd> darcs uses UDP.  After all, order doesn't matter.
<Glenjamin> hi guys, i'm having some issues using the sftp transport
<Glenjamin> basically, i keep getting bzr: ERROR: Unable to connect to SSH host trucklomax.com; EOF during negotiation
<jelmer> Glenjamin: can you sftp in using the sftp client?
<Glenjamin> yes
<Glenjamin> is there an evn var i can set to see the full stack trace?
<jelmer> you can use -Derror I think
<Glenjamin> i'm getting a socket connection error in connect_sftp
<Glenjamin> hrm, its from the subprocess vendor, is that correct?
<Glenjamin> ah, its trying to use plink
<Glenjamin> aha, bzr seems to favour installed ssh clients over paramiko now
<jelmer> vila: ping
<gioele> hello
<gioele> bzr push complains that branches have diverged after "bzr uncommit; bzr commit". Why?
<beuno> gioele, because the revision ids are now different
<gioele> beuno: can't I "force" the push?
<gioele> is push --overwrite a forced push?
<beuno> gioele, sure, just add --overwrite
<exarkun> Should I commit a merge and other changes in a single revision?
<gioele> beuno: thank you
<james_w> exarkun: you can do
<james_w> if it's fixing up the build with the merge or something then it can be good
<james_w> if it's something completely separate then split it in to a new revision
<exarkun> It was a ChangeLog entry in this case
<exarkun> I guess that kind of makes sense
<seb_kuzminsky> i know how to use things like  "bzr log -v -r ancestor:../other-branch" to find the changes since the most recent merge
<seb_kuzminsky> how do i find out the revision number (or revid, or something) of that ancestor?
<james_w> bzr revno -r ancestor:...?
<seb_kuzminsky> ^C0 seb@slurp /home/seb/bzr/emc2/hostmot2>  bzr revno -r ancestor:../upstream
<seb_kuzminsky> bzr: ERROR: no such option: -r
<seb_kuzminsky> that's 1.11, maybe i should upgrade?
<james_w> no
<james_w> don't think that's changed
<Peng_> It hasn't,
<james_w> find-merge-base?
<seb_kuzminsky> james_w: yes, thank you
<jelmer> wtf, unicode revision ids are allowed now ?
<Peng_> jelmer: Maybe not intentionally.
<jelmer> Peng_: there's a test that checks they work
<Peng_> jelmer: Oh. That sounds pretty intentional, then. Never mind. :P
<seb_kuzminsky> one of the open-source groups i'm working with is considering switching from CVS to some DVCS, i'm pushing for bzr and the other folks have some questions/issues that i'll proxy to you ;-)
<thewrath> hello i was told to come over here
<thewrath> i want to set up bZR and having some issues
<thewrath> any help woudl be hot
<thewrath> i am nto sure if i have python 2.5
<seb_kuzminsky> is there a good way to set up the central server so a select bunch of people can push changes without having shell accounts?
<seb_kuzminsky> thewrath: python -V?
<thewrath> i am in windows
<thewrath> do that in command line?
<seb_kuzminsky> thewrath: i dont know much about windows, but yeah, try it in a command window
<thewrath> nope
<thewrath> anyone using it in windows
<thewrath> i tried to install the dependency and it said python not installed
<MizardX> ... I can't manage to get the authentication to work with bazaar <-> launchpad on windows. Keys added to lp and pageant successfully, but when I try to use bzr branch/co/push with lp I get the error "Permission denied (publickey)."
<thewrath> MizardX: can you help me set up bazaar on widnows
<MizardX> thewrath: No. I need help myself.
<thewrath> ok
<thewrath> i just need help setting it up
<thewrath> i have installed it but after that i dont know what to do
<thumper> MizardX: have you loaded your ssh key into Launchpad?
<MizardX> Yes.
<thumper> MizardX: have you done a `bzr lp-login` ?
<thumper> MizardX: as it is likely that your lp name isn't the same as your local one
<MizardX> Yes. "marjar-4"
<Peng_> beuno: ping
<beuno> Peng_, pong
<thumper> MizardX: if this is not your normal ssh key, have you set it to be the one to use talking to bazaar.launchpad.net ?
<Peng_> beuno: With the Loggerhead YUI CDN thing, what about changing it to just put a big "if branch.use_yui_cdn" in the template? Then the URL could be hardcoded in the template instead of the Python code. Would that be better?
<schmichael> if i push/pull/merge with lots of remote branches, is there some way to give each one a nickname?
<Peng_> beuno: That would mean the list of scripts would be duplicated, but I could use the nifty combo thing.
<Peng_> schmichael: bzr-bookmarks plugin?
<MizardX> thumper: It's my only key. Generated it to be used with bazaar/launchpad.
<MizardX> thumper: Otherwise I don't know what you mean.
<schmichael> Peng_: will check it out, thanks
<thumper> hmm..
<MizardX> thumper: Does they "bzr whoami" play any part in authentication?
<MizardX> the*
<thumper> MizardX: no
<thumper> MizardX: which version of bzr are you using?
<MizardX> latest stable... 1.13
<thumper> in which case I have no idea why it isn't working
<thumper> perhaps lifeless might know more
<thumper> he knows lots of weird shit
<lifeless> you called
<MizardX> puttygen/pageant version 0.60.0.0
<lifeless> MizardX: ok, you're on windows, I was about to ask :)
<lifeless> thewrath: You don't know what to do.. to achieve what ? [do you want to start a new project, get the code for someone elses existing project ...?]
<beuno> Peng_, I think that's better
<beuno> at least it feels less awkward
<schmichael> Peng_: yikes!  not even a README file for bzr-bookmarks?  maybe i'll wait for it to mature a bit first :)
<lifeless> MizardX: we're meant to autodetect pagent automatically; uhm, first thing I'd try is giving the full url automatically.
<beuno> mwhudson, any thoughts  ^
<lifeless> MizardX: e.g. whats a branch you want to make from launchpad?
<Peng_> beuno: It is better, but I think it'll be uglier and more complicated. Also I'll have to learn some TAL. :P Anyway, I'll try it.
<beuno> Peng_, well
<beuno> it will be uglier
<beuno> so let's weigh this in...
<Peng_> It will be nice to use the YUI combiner thingy.
<mwhudson> beuno: on what?
<beuno> Peng_, of course, you could kick off the config file work we want to do, by using a config file through bzr. Which we could install by default our something
<Peng_> mwhudson: Option to load YUI from Yahoo!'s CDN. https://code.launchpad.net/~mnordhoff/loggerhead/yui-cdn/+merge/5119
<seb_kuzminsky> lifeless: what's the prefered way to grant commit access to a central repo without granting shell access to the machine hosting the central repo?
<MizardX> lifeless: http://pastebin.ca/1379351
<beuno> mwhudson, https://code.edge.launchpad.net/~mnordhoff/loggerhead/yui-cdn/+merge/5119
<mwhudson> oh right
<mwhudson> well, i've nothing really against the idea
<mwhudson> so long as we don't accidentally turn it on for launchpad or anything
<luks> schmichael: bzr help plugins/bookmarks
<MizardX> "Launchpad will be going offline for maintenance in 30 seconds." :(
<mwhudson> Peng_: go for it, if you have time before the rollout >:)
<beuno> 20 seconds!
<schmichael> luks: thanks
<lifeless> MizardX: do you have a ssh client?
<mwhudson> argh
<lifeless> MizardX: oh, yeah, there is a major maintenance rollout happening today, new backend db server change over and other cool stuff
<mwhudson> i was working with jam on code that's only on his laptop and launchpad
<mwhudson> and he just left
<mwhudson> nice timing, hudson
<Peng_> Haha. Nice timing.
<lifeless> MizardX: when it comes back, I suggest using a ssh client to ssh to marjar-4@bazaar.launchpad.net; you can't do anything useful but it should connect ok, if it doesn't the key isn't configured right at one end or the other; if it doees bzr isn't picking up pagent/putty correctly
<MizardX> ok
<MizardX> Thanks for the help so far.
<beuno> ok, I'm off for a little while
 * Peng_ grumbles at YUI.
<Peng_> Oh, I'm just a dummy. Never mind.
<lifeless> seb_kuzminsky: bzr+https would meet your needs AFAICT
<seb_kuzminsky> does the "bzr+" mean it's using the smart protocol, just tunneled over https?
<lifeless> yes
<seb_kuzminsky> cool :-)
<seb_kuzminsky> where are the bzr transports documented?
<lifeless> as opposed to e.g. webdav
<lifeless> bzr can also autodetect, if you say 'https://' it will probe for a smart server on the host
<lifeless> anyhow, bzr help urlspec is client side docs
<lifeless> and there is docs in the manual for setting up a http server
<seb_kuzminsky> thanks lifeless :-)
<lifeless> anytime
<Peng_> mwhudson: Stupid TAL question: It can do "if"-like stuff, but what about "else"?
<mwhudson> <tal:b condition="thing>...</tal:b><tal:b condition="not:thing>...</tal:b>
<mwhudson> :(
<seb_kuzminsky> lifeless: i guess i'm being daft here - which manual has the http server setup stuff?  i'm not seeing anything in the User Guide or the User Reference
 * igc breakfast
<Peng_> mwhudson: Thanks.
<Peng_> Hmm, since I got a bb:approve from both of you, maybe I shouldn't be messing with this anymore. :P
<mwhudson> Peng_: with what?
<igc> so hg-fast-export took 65 hours to export OOo
<igc> bzr-fast-export took 2h42m to import the first 50k revisions of those 260K
<Peng_> mwhudson: The YUI thing.
<igc> on brisbane-core's latest format
<Peng_> D'oh, I just found the YUI 3 configurator after finishing! :(
<igc> I think we now have fast bulk data-entry almost nailed
 * igc food
<mwhudson> Peng_: oh right
<mwhudson> Peng_: well, you can't land it for a bit :)
<seb_kuzminsky> lifeless: oh i see, it's in an appendix to the User-Guide
<lifeless> seb_kuzminsky: http://doc.bazaar-vcs.org/bzr.1.13/en/user-guide/index.html#running-a-smart-server and http://doc.bazaar-vcs.org/bzr.1.13/en/user-guide/index.html#serving-bazaar-with-fastcgi
<lifeless> seb_kuzminsky: it needs a better title I think
<Peng_> mwhudson: Since LP is down and I'm impatient (:P), new revision: http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/revision/323
<Peng_> mwhudson: Do you prefer the old one? Or something else?
<mwhudson> Peng_: i wonder if it might be better to list the module names in python rather than macros.pt
<Peng_> mwhudson: What about defining a tuple or whatever in macros.pt, if that's possible? A bit evil, but putting it in Python seems weird.
<lifeless> spiv: ping; we really need to motor on the inventory fetch stuff; I propose a near-full-day focused sprint if you're up for it - pick a place
<mwhudson> Peng_: i guess you can say tal:define="yuimods python:('...',)"
<Peng_> mwhudson: Oh. Well, if the feature exists, than it's not evil to use it, right? :D
<mwhudson> Peng_: um
<mwhudson> Peng_: i would recommend against applying that rule of thumb too often :)
<Peng_> mwhudson: What could possibly go wrong? :)
#bzr 2009-04-02
<spiv> lifeless: pong; just figuring out my after-work commitments now so I can plan that.
<Peng_> mwhudson: Now with more evil and depravity :) http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/revision/324/loggerhead/templates/macros.pt
<lifeless> spiv: kk
<weigon> lp's ssh refuses to connect :(
<Peng_> weigon: LP's down for maintenance.
<Peng_> maintanence? Eh, whatever.
<weigon> *doh* thx
<jelmer> crap, revision properties contain arbitrary binary data?
<mwhudson> jelmer: it's just {str:str} isn't it, so i guess so?
<jelmer> mwhudson: what's the easiest way to escape arbitrary data in something representable in unicode?
<Peng_> jelmer: repr()? s.encode('unicode-escape')? base64?
<mwhudson> jelmer: i guess it might be meant to be utf-8 or something
<mwhudson> i guess i'm the wrong person to ask
<lifeless> jelmer: why do you say they contain arbitrary data?
<jelmer> Peng_: base64 is overkill, unicode-escape requires a unicode string (and I have no way of creating one)
<mwhudson> Peng_: your increased depravity looks fine to me :)
<Peng_> mwhudson: Is that a bb:approve? :D
<jelmer> lifeless: at least one of the tests tries to add "\xb5" as property value
<jelmer> (in other words, a <str> object and invalid utf8)
<lifeless> jelmer: ah interesting
<lifeless> and we what, base64 enciode them ?
<jelmer> it seems like it silently gets casted to unicode
<jelmer> in the XML serializer
<jelmer> so "\xb5" goes in, u"\xb5" comes out
<lifeless> but you said \xb5 isn't valid unicode?
<jelmer> lifeless: it's invalid utf8
<lifeless> jelmer: is the test testing that or is it a bug in the test?
<jelmer> lifeless: the bug is in the test
<MizardX> lifeless: "No shells on this server." ... Connecting with putty with same certificate seems to work. You said if that was so, then bzr didn't pick up Pageant. How would I fix that?
<lifeless> MizardX: now we've reached the end of my knowledge :( I haven't used bzr on windows
<MizardX> Ok. Thanks.
<lifeless> MizardX: but we now know that your launchpad and putty stuff is setup
<lifeless> uhm
<lifeless> did you install using the windows binary, or the 'python installer' ?
<MizardX> binary
<lifeless> bzr --version will give you the path to a log file
<MizardX> I think it's compiled with py2exe
<lifeless> you might look in that log and see if there is anything about pagent/putty
<MizardX> Just "ssh implementation is OpenSSH" and "ConnectionReset: Connection closed: please check connectivity and permissions"
<lifeless> ok
<lifeless> that suggests it found a ssh.exe on your machine and is using that
<lifeless> there is an environment variable to control this I think, one sec
<lifeless> do you have plink installed?
<MizardX> yes
<lifeless> ok
<lifeless> try
<lifeless> setting the BZR_SSH environment variable to 'plink'
<MizardX> "FATAL ERROR: Disconnected: No supported authentication methods available", not it doesn't find the certificate
<MizardX> now*
<spiv> lifeless: I'll head to you.  ETA is 11:50 by the time I buy my coffee :)
<MizardX> Ah, pageant wasn't running...
<MizardX> "Branched 8 revision(s)." :D
<MizardX> Thanks, lifeless.
<Peng_> mwhudson: ping
<Peng_> mwhudson: Mind if I make an old-style class in Loggerhead new-style without getting it reviewed? (Well, asking is almost as inconvenient as a review...)
<lifeless> MizardX: cool
<nsh22> what does this mean: error: unable to create symlink 'themes' on this platform
<Snova> Would I be correct at guessing you're running Windows?
<Snova> Also, how did this come about? What command caused it?
<nsh22> unfortuneatly yes
<nsh22> i was just getting a branch
<Snova> Then I can only assume the branch contains symlinks, which have no equivalent on Windows... I dunno what else it could mean.
<nsh22> ugh, ok... the thing is is that it gave me any of the other files in the branch
<jml> Launchpad is running bzr 1.13 on production now.
<jml> ~18s & 21 hpss calls to push no revisions to a stacked branch. ~7s of that is SSH connection time.
<jml> ~27s & 32 hpss calls to push one revision to a stacked branch.
<lifeless> jml: is this better :)
<jml> yes.
<sm> g'day all
<sm> how long should bzr selftest take on a macbook ?
<sm> it has been running an hour and a hlaf
<jelmer> sm: it takes about 20 minutes here
<jml> lifeless: bzr pull is noticeably faster.
<sm> jelmer: on a macbook ?
<jelmer> sm: ah, no, sorry - linux
<jml> lifeless, spiv: congratulations!
<lifeless> thanks
<jml> hmm. making a new stacked branch is still kind of slow.
<jml> I wonder if bumping our format to 1.9 would change that.
<lifeless> do you have the patches we landed yesteday?
<jml> lifeless: only if they are in the nightly -- I'll update my bzr.dev and try pushing with that.
<lifeless> well, whats your nightly version?
<jml> lifeless:  1.14~bzr8.10-4223-1
<jml> lifeless: down from 81 -> 66 calls using bzr.dev. still the same elapsed time.
<lifeless> jml: ok, thats interesting
<lifeless> pop the log up somewhere
<jml> lifeless: http://paste.ubuntu.com/142445/ -- first is using nightly, second is bzr.dev
<jml> both are pushes of the same branch to Launchpad but to different locations. branch was made locally from a mirror of the default stacked-on branch. so no new revision data for either push.
<Snova> What would be the best way to have a particular file updated every commit to include a revision number? I think I could use a hook for it, but it looks like I would have to require it be installed on all committer's computers.
<Peng_> Snova: Well, that's what the new keyword plugin is for, although it just applies to the working tree, not the history itself, like svn:keywords.
<Peng_> Snova: That'd mean you only need the people who actually need the revision numbers to install it.
<Peng_> Snova: Anyway, the usual workaround is to have your Makefile run "bzr version-info >whatever".
<lifeless> Snova: what do you want to achieve with this?
<Snova> lifeless: I'd like the server I'm writing to send the revision number along with the version.
<lifeless> Snova: of the codebase its running?
<Snova> Yes.
<lifeless> as Peng says, invoking bzr version-info during server startup is probably better
<Snova> I could, but then it assumes it's always in a branch... a source tarball or any form of distribution wouldn't... although I primarily want this during development, if I actually released it there wouldn't be much point.
<Snova> I guess that works, and it's the simplest way.
<lifeless> you can hook that into your tarball export logic too
<spiv> lifeless: http://bugs.python.org/issue5660
<spiv> jml: well, we think we have stuff in the works that will cut another ~10s out of that fairly soon (needs new verbs, though).
<spiv> jml: thanks for the log
<AfC> Hooray for Bazaar!
<jml> spiv: cool.
<lifeless> jml: so if you're lucky, 1.14 on the server and client will fix it
<lifeless> if you're not, it won't :)
<jml> if I'm extra double lucky, we might get an edge codehosting service so we can run 1.14 on the server before the next LP release.
<lifeless> when is the next release?
<jml> lifeless: four weeks from today
<Peng_> What would the edge codehosting do? Have a second copy of everything? Would the main and edge instances both pull mirrored branches?
<spiv> jml: btw, my locations.conf for my bzr branches now defaults to lp
<jml> spiv: nice!
<spiv> 67 HPSS calls, 48s (including SSH handshake) and 207k to push up a new branch with a new revision.  Not too bad.
<jml> Peng_: it would just be the SSH server & surrounds. There would be no edge puller.
<jml> Peng_: it would use the same data and be in every way analogous to the edge web service
<spiv> jml: uh
<spiv> jml: bzr: ERROR: Server sent an unexpected error: ('error', '<ProtocolError for xmlrpc.lp.internal:8097/branchfilesystem: -1 >')
<spiv> jml: that was on a Branch.unlock RPC on an empty push
<jml> spiv: hmm. I bet it's an operational glitch.
<spiv> jml: maybe the XML-RPC server was unreachable temporarily for the "hey please rescan this branch" ping?
<spiv> jml: how hard would it be to get that message to a) have an OOPS code, and b) make it clear that LP is to blame, not the client? :)
<jml> spiv: if you asked me, I would have thought that the OOPS was already in it.
<spiv> jml: I see!
<spiv> jml: So that means there is probably already an OOPS generated, at least?  That's nice!
<spiv> jml: btw, it does seem to be a transient issue, a second attempt at the empty push worked just fine, rather than erroring on the final (13th! spooky!) RPC.
<spiv> jml: In my magical land of perfect software and ponies, and temporary inability to reach xmlrpc.lp.internal wouldn't break anything...
<jml> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/281042
<ubottu> Error: This bug is private
<spiv> s/and/an
<jml> describes such a land. except that it's private, for reasons that elude me at present.
<spiv> jml: ah, yes, I guess it was a timeout, judging from the 20s + a bit it took between request and error response.
 * spiv clicks the hard-to-find "me too" link.
<spiv> (Something seems wrong when it's easier to add a "me too" comment than use the "me too" feature...)
<beuno> spiv, yes. Quite a few things, actually. Hopefully, we'll address that in 2.2.5 with the change in the bug lauout page
<jml> spiv: fwiw, https://bugs.edge.launchpad.net/launchpad-bazaar/+bugs?field.tag=codehosting-ssh is actually a fairly complete list of bugs in the codehosting server
<jelmer> spiv: btw, what's the status of your ~ patch?
<spiv> jelmer: limbo; I need to find some spare time to rewrite along the lines poolie wanted to see if I'm happy with his approach
<spiv> jelmer: I think I'll be fine with poolie's approach (although his approach does need a new server, which is a minor drawback), but it needs to be implemented...
<jelmer> spiv: ah
<spiv> (on the other hand my approach needs a new client and his doesn't...)
<cody-somerville> Could someone take a look at lp:xubuntu-docs and see if there is anyway we can improve performance? Branching and pushing seems to take a very long time on it
<lifeless> cody-somerville: use bzr 1.14
<lifeless> cody-somerville: and be sure you have done bzr launchad-login
<cody-somerville> I have
<cody-somerville> I'm using 1.13
<cody-somerville> is 1.14 in the ppa?
<lifeless> in the nightly ppa yes
<igc> jelmer: jam has suggested that the filter registration function just take a callable, not a dict and a callable
<igc> jelmer: I think it's a good idea. OK with you if I put a patch up for that?
<igc> we want the API stable for 1.14
<spiv> cody-somerville: also, have you tried branching and pushing since the lp rollout that happened an hour or so ago?
<cody-somerville> I just branched
<spiv> cody-somerville: I'm doing a branch now, and it's streaming to me here in Sydney at ~150K/s
<spiv> (which I believe is the capacity of this ADSL link)
<lifeless> (I have a 1.5MB connection, so thats 1.2MB used by bzr
<lifeless> cody-somerville: and how long did it take to branch?
<lifeless> cody-somerville: [you are aware you have 30Mb of history]
<cody-somerville> Yea, I figure thats what the problem is
<cody-somerville> I did some nasty stuff to get the revision history to show correctly
<beuno> cody-somerville, and, you could use a shared repo, so you only download whatever revision once in a life time
<cody-somerville> I am using a shared repo
<lifeless> cody-somerville: "12:46 < lifeless> cody-somerville: and how long did it take to branch?
<lifeless> "
<beuno> so it should be very fast after you did it oncec...?
<beuno> once even
<cody-somerville> lifeless, about a minute
<spiv> "time bzr branch lp:xubuntu-docs" here just took 4m23.953s, which seems to be about as fast as this ADSL link allows.
<spiv> Given that it had to fetch ~36M
<lifeless> cody-somerville: do another branch with -Dhpss please, and we can look at the network activity if you grab the log for that bzr command from your ~/.bzr.log
<cody-somerville> okay
<lifeless> 60 seconds is long to figure out you have everything locally, unless you didn't branch into your shared repo
<cody-somerville> I did and am again
<lifeless> oh; also try 'time bzr checkout --lightweight $SOME_LOCAL_BRANCH /tmp/foo'
<spiv> lifeless: FWIW, that takes less than 1s here.
<lifeless> cody-somerville: ping; 1 minute should have finished ages back
<cody-somerville> lifeless, It takes a long time to copy and paste the log :P
<lifeless> cody-somerville: I'm kindof paying attention here to give you a fast turnaround; if you're going away to do stuff let me know and I'll get back to coding
<cody-somerville> http://pastebin.ubuntu.com/142472/
<cody-somerville> No, just takes a long time to copy and paste 6078 lines
<lifeless> you missed the top of the log even so :)
<cody-somerville> Before that is log stuff about another command I did
<cody-somerville> oh wait
<cody-somerville> nvm
<lifeless> cody-somerville: don't worry
<lifeless> you're not using a shared repo
<lifeless> so its copying everything
<cody-somerville> http://pastebin.ubuntu.com/142475/
<cody-somerville> oh... I guess you're right
<cody-somerville> I thought I had created that
<cody-somerville> btw, I did bzr check and it said this: http://pastebin.ubuntu.com/142477/
<cody-somerville> Is an inconsistent parent bad?
<lifeless> its something to fix
<lifeless> bzr reconcile will fix it
<cody-somerville> lifeless, So I moved a bunch of files - when I merge from the parent, which hasn't moved the files, will bzr do the right thing or will they go to the old location?
<lifeless> cody-somerville: why don't you try ?:)
<cody-somerville> lifeless, cause the branch is reconciling atm or I would ;)
<cody-somerville> oh, that was quick
<cody-somerville> lifeless, would a repack help make the branch smaller?
<lifeless> cody-somerville: no
<lifeless> bzr repacks itself as it needs to
<cody-somerville> what about that obsolete_packs directory?
<cody-somerville> is that maybe causing the download to be more than it needs to be?
<spiv> No, it doesn't affect downloads at all.
<cody-somerville> hmm... the branch seems to be bigger now than before
<lifeless> cody-somerville: 1 minute is not long
<spiv> You have 36M of actual revision history, which doesn't sound so unlikely for nearly 200 revisions of a 5.9M tree of files.
<cody-somerville> Its 77M on disk
<lifeless> cody-somerville: all seems to be working reasonably; its under a second to make a working tree, and with a shared repo new branches hsould be about 3 seconds or less
<lifeless> cody-somerville: thats because of the reconcile; ignore it
<lifeless> cody-somerville: housekeeping will take care of it
<cody-somerville> lifeless, so will this reconcile get pushed to launchpad?
<lifeless> cody-somerville: no
<lifeless> launchpad needs to be reconciled separately
<cody-somerville> should I do that?
<lifeless> if you like
<cody-somerville> what exactly am I fixing?
<cody-somerville> Will it make merging easier or something?
<lifeless> what revisions annotate will attribute content to
<lifeless> cody-somerville: generally speaking you shouldn't need to worry or do anything special with bzr to make it perform well; the one key exception is shared repositories
<lifeless> and the second key exception is using a smart server if one is available (which lp: does for you once you login, and bzr+ssh/bzr+http do elsewhere)
<exarkun> Hey I discovered the super awesome "bzr join" command without any help from mwhudson but the only problem is that I can't figure out how to use it would anyone like to assist me
<exarkun> I have two unrelated branches and I want to make one of them just be part of the other one.
<cody-somerville> hmm...
<cody-somerville> bzr doesn't seem to have done the right thing :(
<cody-somerville> and ugh.. "1432 conflicts encountered".
<lifeless> exarkun: use the bzr merge-into plugin; join is part of an as-yet unreleased feature
<lifeless> cody-somerville: did it print 'criss cross merge' at the top ?
<cody-somerville> no
<lifeless> thats very odd then
<lifeless> what are the conflicts?
<lifeless> and when you say you did nasty things, could you be more specific
<lifeless> I'm going to guess you've been doing history-glueing in some nasty manner, and it is [predictably] biting you
<cody-somerville> Well, I took branch A and branch B
<exarkun> lifeless: Oops!  I figured out how to use bzr join while I wasn't looking at IRC.
<cody-somerville> A wasn't based on branch B
<exarkun> lifeless: Should I start over with merge-into?
<cody-somerville> But really was
<lifeless> exarkun: if it has worked, go for it.
<exarkun> okay cool, thanks :)
<cody-somerville> So I merged B into A using -c 1
<cody-somerville> That worked fine and I got what I wanted except I lost all the revision history from branch B and some people didn't like that
<lifeless> cody-somerville: when you say 'a wasn't based on branch b' do you mean 'they were completely separate projects' ?
<cody-somerville> No, it was Xubuntu docs and Ubuntu docs
<cody-somerville> They're similar but the branches didn't have shared revision history because Matthew restarted all the branches from scratch for some reason
<cody-somerville> I imagine for performance reasons
<lifeless> ok, which means 'they were completely separate projects'
<lifeless> no history -> separate projects
<cody-somerville> Right
<cody-somerville> B was based on C
<lifeless> you should use 'bzr merge-into' to join them.
<cody-somerville> and now I'm trying to merge C into B
<cody-somerville> Oh I missed a part
<cody-somerville> I removed everything in B and put in the contents from A to get the history back
<cody-somerville> and then I merged A into B to get the metadata
<cody-somerville> B *is* based off of C and now I'm trying to merge C into B
<lifeless> well
<lifeless> you might try merge --weave
<cody-somerville> I moved a ton of stuff into a subdirectory
<lifeless> it may do better
<lifeless> did you move using 'bzr mv' ?
<cody-somerville> so now I have a bunch of files in the old directory ending with .BASE and .OTHER
<cody-somerville> lifeless, I did in A, yea
<lifeless> or did you move by doing 'mv; bzr add' ?
<cody-somerville> I did bzr move
<cody-somerville> but in A
<lifeless> is A merged into C or B or neither?
<cody-somerville> into B
<cody-somerville> so should I do: bzr remerge --merge-type weave --reprocess
 * cody-somerville tries
<cody-somerville> lifeless, If this doesn't work, would branching C and doing the moves over again and then merging that into B work and make future merges of C work?
<cody-somerville> hmm... only 1324 conflicts this time
<cody-somerville> but didn't do the right thing. bzr diff desktop-guide (the directory I moved almost all the directories into) returns nothing.
<lifeless> cody-somerville: what would you expect it to return?
<cody-somerville> lifeless, The changes bzr merged in?
<cody-somerville> lifeless, bzr isn't touching any of the files already in the branch
<cody-somerville> lifeless, all the conflicts are on files its added
<cody-somerville> I'm also getting this error now trying to branch inside the shared repository I created: http://pastebin.ubuntu.com/142494/
<lifeless> cody-somerville: you ran 'bzr init-repo' to make the shared repository, yes?
<cody-somerville> yup
<lifeless> cd to the root of the shared repo
<cody-somerville> okay
<lifeless> and run bzr upgrade --default-rich-root
<cody-somerville> bzr: ERROR: no such option: --default-rich-root
<lifeless> 'use bzr 1.14' :)
<lifeless> hell you're canonical, you should be using the nightly ppa :)
<cody-somerville> ;p
<cody-somerville> also, I just got this when trying to do bzr remove */po/*.po: bzr: ERROR: [Errno 24] open: Too many open files: '.'
<SamB> hmm, I wish that the GNOME vcs-imports branches weren't the default branches :-(
<spiv> SamB: if there's a better branch to use, file a request at https://answers.launchpad.net/launchpad-bazaar asking for the default to be changed.
<SamB> spiv: well, in #launchpad they've got me seeing if I was using a bleeding-edge enough bzr that they should have fixed the problem where it takes forever to push to a branch with little to no shared history with the branch it is to be stacked on ...
<spiv> SamB: ah, yes.  We keep fixing bugs :)
<spiv> SamB: but even so, if there's a better branch, do let the relevant people know
<SamB> and they said something about how GNOME is supposed to be switching to git
<SamB> so that the bzr-playground branches might not be that great for too long
<spiv> SSH handshake time is now well over a third of the overall time in random incremental pushes to my branches on LP.
<SamB> oh, incremental pushes seem fine
<spiv> SamB: I'm opening to changing the message if it can be less confusing
<spiv> SamB: but I figured I should explain why it is saying that (and why it's not "lying").
<SamB> Well, "transferring" is a much more neutral word
<SamB> if it can't be bothered to figure out which of the two activities it is engaged in is taking all the time ...
<spiv> I'm not sure what you mean by that comment?
<spiv> The activity is (accurately, by its choice of perspective) called "fetching".
<SamB> well, it's not waiting on the fetches from the local repository ... it's waitng on the stores to the other one
<spiv> Not really, those things aren't really decoupled.
<SamB> well, okay, in that case the word is "transfer"
<lifeless> so
<lifeless> we're going to overhaul this
<lifeless> and make it prettier
<SamB> at least, in en_US that's the case
<lifeless> transfer is indeed a synonym
<lifeless> or nearly so
<lifeless> at the right point in the code
<SamB> maybe in en_AU or en_UK, fetch is more synonymous with transfer?
<lifeless> but one of the basic problems is that the code doesn't *know* which end of the pipeline the human is sitting
<lifeless> so really, a more directional adverb to describe what is going on isn't easy to correlate with the UI
<SamB> well ... saying "transfer" is a nice and neutral thing to do in that case
<SamB> or when, say, both repos are local
<lifeless> sure, thats one way we can alter the message
<lifeless> all I'm trying to say is:
<lifeless>  - it is broken at the moment
<SamB> okay, yeah, I gathered ;-)
<lifeless>  - its not top of the pops for time until the rc
<lifeless>  - until then, I don't plan on thinking too hard about it
<lifeless> (so please forgive me for simply acking that its an issue, until we're looking at the code, finding a combination that reads well and fits the code isn't necessarily easy
<lifeless> the code itself *is* highly directional
<SamB> you know, I guess I don't need to finish this push ;-)
<lifeless> SamB: is it still slow?
<SamB> it's just that I was just pushing the same thing to a new branch
<SamB> so now that I've established that it was just a confusing progress message, I don't need to finish
<lifeless> oh :)
<lifeless> makes sense to me
<vila> lifeless: did you see my patch about --parallel ?
<lifeless> no
<vila> lifeless: ~one liner to make it work but I think you're the one that can review it
<lifeless> where is it
<lifeless> vila: ^
<vila> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2iqlozk7x.fsf%40free.fr%3E
<lifeless>  # A registry where get() returns a suite decorator.
<lifeless>  parallel_registry = registry.Registry()
<lifeless> +
<lifeless> +
<lifeless>  def fork_decorator(suite):
<lifeless>  those changes are bogus , PEP8 allows adjacent for things that are closely related
<lifeless> specifically I want the FOO_decorator and register..FOO adjacent
<lifeless> vila: reviewed
<vila> lifeless: still ok to separate each couple ?
<lifeless> sure
<VSpike> If I do bzr revert on a file, does that count as a change? IOTW, if I commit it, will it commit the reverted file as a head revision?
<luks> bzr revert is no different from manually changing the working tree
<luks> plain 'bzr revert' will just revert to the head revision, so it wouldn't commit anything
<VSpike> Ah OK - thanks.  I used to use perforce, and that behaved quite differently IIRC. It would rememeber what revision number of each file you currently have in your working tree.
<luks> hm?
<VSpike> So pulling out an old version to look at was not a change.
<luks> ah
<luks> no, bzr revert operates purely on the working tree, you can do something like 'bzr cat -r file >file' and it will be more or less the equivalent
<VSpike> Right - makes sense. Thanks!
<awilkins> jelmer/vila: would authentication.conf have problems with passwords that contain @ characters?
<awilkins> Specfically, if I put my password in the file, it fails, remove it and I get prompted more than once for each bzr-svn push
<vila> awilkins: quote it
<awilkins> Aha
<awilkins> vila: Failed
<vila> awilkins: :-/ quoted as in user@host => user%40host ?
<awilkins> Ah, as in "c@r"
<vila> awilkins: sorry, I meant url encode it
<awilkins> Hmmph, still not working
<awilkins> Although by now I may have locked out my account I suppose
<awilkins> Nope, still works fine at the command line
<vila> awilkins: what protocol are you using ?
<awilkins> svn+http
<vila> you mean bug #256612 ?
<ubottu> Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612
<vila> or some related problem ?
<awilkins> THe username is correctly being picked up from auth.conf with is set up for the host
<awilkins> If I add the password it failes
<vila> I thought connecting succesfully with *svn* was the current work-around
<awilkins> Yes, I thought I'd done that
<awilkins> Although it was with TSVN
<awilkins> I'll try getting it cached in the CLI client also
<awilkins> That works
<vila> good, then you encountered the bug above or something very close
<awilkins> It's obviously using the password when it's provided in the conf file, but it appears to be wrong
<spiv> lifeless, jml: they've fixed the deepcopy(TestCase(...)) bug
<spiv> lifeless, jml: but you might want to take a look at the new TestCase.addTypeEqualityFunc method
<fbond> jelmer: I imported an svn repository with bzr-svn's svn-import.  I see "svn revno: x" in log output, but I can't use -r svn:x.  Why not?
<jelmer> fbond: you need a newer version of bzr-svn to do that on imported branches
<jelmer> igc: yeah, just taking a callback sounds good to me
<fbond> jelmer: Okay, thanks.
<fbond> jelmer: I'm using trac-bzr; it'd be really swell if I could get the old references to svn revisions work in the diff viewer. ;)
<fbond> I mean [283] links and whatnot.
<jelmer> vila: bleh, I'm not sure how I missed that appearance of 'password'
<vila> jelmer: :-)
<jelmer> vila: I did actually refactor that function but changed it back after I noticed it broke for LC_ALL=C
<vila> jelmer: huh ? the one you copy from has been passing for ages or did I miss something ?
<jelmer> vila: Yes, but I changed it after I copy pasted it
<vila> haaa :)
<jelmer> vila: and that broke the tests, so I fixed it and ended up with what the original did :-)
<jelmer> vila: Your NotATerminal patch looks ok, with one minor concern
<jelmer> vila: won't this caused backtraces when there's no terminal?
<jelmer> getpass() will raise an exception that's not caught atm
<vila> jelmer: which exception ? EOFError ?
<jelmer> vila: termios.error
<jelmer> in my case:
<jelmer> termios.error: (25, 'Inappropriate ioctl for device')
<jelmer> including backtrace
<vila> and the backtrace leads to what ? 'sys.stdin.readline()' or some termios call ?
<jelmer> vila: getpass.py line 32
<jelmer> that's indeed a termios call in getpass()
<vila> jelmer: grr
<vila> stream=None => stream = sys.stdout, damn, I explicitely avoid using a prompt and see what happens ! :)
<vila> vila: oh no, it's indeed related to stdin
<vila> hmm, so that's why NotATerminal was there :-/
<jelmer> vila: ah, right
<jelmer> good I did some testing then :-)
<jelmer> vila: So NotATerminal can't be removed, but your other refactoring is still valid right?
<vila> jelmer: indeed !
<vila> jelmer: No
<vila> hmm, or may be we just need to put raise NotATerminal in get_password...
<vila> Urgh, how ugly, the user can enter its login but not its password
<vila> no, I think the right fix is to either call readline() or getpass depending on stdin.isatty() or something like that
<vila> turning echo off makes sense only on a tty and that's the reason we want to use getpass
<jelmer> vila: sounds reasonable
<exarkun> If I committed with a bad username, is there a way to fix those revisions to use a new value for that field?
<LeoNerd> Only by uncommit/recommit
<LeoNerd> Or variants thereof.. The internal revision ID uses a hash of the data, collectively. So changing the data would change the hash, and hence the revid
<jelmer> vila: will you submit a new patch?
<vila> I think so, but not in the coming minutes nor hours I'm affraid
<jelmer> vila: thanks, no hurry :-)
<jelmer> vila: and thanks for the work on this auth stuff, hopefully bzr/bzr-svn 1.14 will be the first bzr where this stuff works properly
<vila> jelmer: np, I'd still like feedback from the other devs about utf8 encoding
<exarkun> LeoNerd: Thanks
<vila> jelmer: I noted that you didn't *call* get_username, are you planning to work on that ?
<vila> jelmer: yeah hopefully, but as you see, evils is in the details :)
<jelmer> vila: don't call it in what sense?
<jelmer> vila: get_user() would use it
<vila> oooh, yes, indeed, the other patch, ok
<jelmer> vila: speaking of which..
<vila> then will you update that one to take into account the other calls to getpass.getuser() /
<vila> s!/!?!
<jelmer> vila: you mentioned that http uses get_user() atm and the others use getpass.getuser()
<vila> yup, that point :)
<jelmer> vila: Just to make sure; they should all call get_user() but get_user() should default to getpass.getuser() ?
<jelmer> vila: You also mentioned something about only prompting if a prompt was specified
<vila> jelmer: yes, except that defaulting should be the default but http can overrride it
<vila> ha, I didn't think about using the prompt for that...
<jelmer> vila: so defaulting is directly returning getpass.getuser() or rather printing "[DEFAULT]" and letting the user just hit <enter> to use that?
<vila> ...I was thinking about a new, optional, parameter...
<vila> no
<vila> we don't want to require pressing enter where we didn't before
<jelmer> ok
<vila> when we default to getpass.getuser... we default period. You can ask for feedback but I doubt we want to change that
<jelmer> vila: ok, so I won't touch anything but http at the moment
<jelmer> vila: what would you like to change in case of http?
<jelmer> is it ok to require pressing <enter> or entering a username there if there's no user specified in authentication.conf ?
<vila> jelmer: I think you should change ftp/ssh/http, call ui.get_username() from config.get_user() but only if required via a parameter (i.e. http only) and get rid of the getpass.getuser() calls in ftp/ssh
<vila> just do a grep getpass you'll understand easily I'm sure
<jelmer> vila: ah, ok
<jelmer> vila: so, just to make sure:
<jelmer> vila: I'd add a new parameter to get_user() that specifies whether or not to ask the user
<jelmer> vila: and only http for now sets that parameter to true
<vila> exactly
<exarkun> So once I do the uncommit/commit dance to get my username right in the revisions, if I want to fix what's on launchpad, should I do a push --overwrite?
<vila> sounds like the cleanest way while still allowing get_username to get overwritten by GUIs with the usual mechanism
<jelmer> exarkun: yes
<exarkun> cool
<nilg> hi, I've made bzr rm file, on the wrong file, is there anyway to get it back simply?
<nilg> I haven't committed yet
<luke-jr> is there a bzr-cvs plugin?
<nilg> hi, I've made bzr rm file, on the wrong file, is there anyway to get it back simply?
<luke-jr> bzr revert file?
<nilg> luke-jr, it works thanks a lot (I got scared for a second)
<ricardokirkner> hi jelmer, I am having some issues with bzr-svn, that I saw were supposedly fixed in bzr 1.6. I am using bzr 1.13 with bzr-svn from launchpad, and am still getting python: subversion/libsvn_subr/path.c:414: svn_path_is_empty: Assertion `is_canonical(path, strlen(path))' failed.
<ricardokirkner> when trying to push to upstream
<fbond> Any way to get a series of patches for a series of commits?
<fbond> (In one command, or so.)
<fbond> Hm, I guess I'll just shell script it.
<jfroy> Any thoughts on https://bugs.launchpad.net/bzr/+bug/354036?
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,New]
<jfroy> I suspect it may have to do with the recent Launchpad bzr 1.13 upgrade
<jfroy> But that's speculation.
<klbate> Hello! If I have pushed a commit but forgot to sign it, how can I push just the signature afterwards?
<Peng_> klbate: You can run "bzr sign-my-commits", but I dunno if pushing afterwards will push the new signatures.
<klbate_> Sorry, was disconnected...
<klbate_> In Git there is something like 'push --tags', is there a bzr equivalent?
<Peng_> klbate_: "bzr push" will silently push new tags, so it's a reasonable assumption that it will do the same with signatures.
<Peng_> It's worth a try, at least.
<ricardokirkner> jelmer, really sorry to insist... but whenever you can I would really appreciate it, as it's a blocker for me right now
<luks> can somebody in the ~bzr lp group please copy the qbzr 0.9.9 packages from https://launchpad.net/~qbzr-dev/+archive/ppa to https://launchpad.net/~bzr/+archive/ppa ?
<Peng_> Huh, bzr just started whining about an invalid config file somewhere.
<Peng_> lifeless: ping
<abentley> lifeless: ping
<abentley> emmajane: Oh, hi.
<emmajane> ola abentley :)
<abentley> Ãa va?
<ricardokirkner> what options should I use in order to find out why bzr-svn is crashing?
<emmajane> presque. :)
<emmajane> I'm inside and it's nice outside. :)
<emmajane> abentley, how's the weather down south today?
<emmajane> abentley, someone told me we're getting another dump of snow. which makes me cry inside.
<abentley> emmajane: It's not bad.  You can get away without a jacket for a bit.  But the clouds have rolled in today.
<Peng_> abentley: What are you pinging him about:? :D
<emmajane> abentley, boo to the clouds.
<abentley> Peng_: WorkingTree4.iter_references
<Peng_> abentley: Oh.
<abentley> emmajane: Did you know Mike Audet's up in Peterborough nowadays?
<emmajane> abentley, the nerve! what's he doing up there?
<emmajane> abentley, my cousin is at Trent. :)
<abentley> emmajane: Teaching, doing some programming on the side.
<emmajane> abentley, sweet!
<kfogel> it's fairly standard in bzr to use "r800" as an abbreviation for "revno 800", right?
<kfogel> (Users Guide seems to indicate so, but only by implication...)
<mwhudson> kfogel: i certainly do that quite a lot
<kfogel> mwhudson: thx
<Peng_> kfogel: I picked up the habit from svn and still use it with bzr.
<kfogel> Peng_: more confirmation, good
<james_w> does -r handle "r800"?
<kfogel> james_w: in svn, yes :-)
<james_w> I thought I remembered a bug about it not doing so
<Peng_> Oh crap. I just reverted bzr to r3234 instead of r4234. Now it doesn't even recognize the branch format. :D
<Peng_> Thank goodness I had another copy of bzr around.
<lifeless> Peng_: pong
<lifeless> abentley: pong
<abentley> lifeless: DirStateWorkingTree.iter_references raises and AttributeError if you don't lock the tree before use.  I found this surprising.
<abentley> s/and/an
<lifeless> abentley: thats certainly a bug; I would expect it to raise, but not AttributeError
<Peng_> lifeless: Oh hi. I filed bug 354075 about what I was pinging you about, but forgot to unping you.
<ubottu> Launchpad bug 354075 in bzr "Branch.get_config_file smart verb breaks get_bzr_remote_path" [Undecided,New] https://launchpad.net/bugs/354075
<lifeless> abentley: btw, how long does it take you to run the bzr test suite ?
<nsh22> hi umm, how do i merge two different lp branches?
<abentley> lifeless: This is because you initialize DirStateWorkingTree._repo_supports_tree_reference when the tree is locked.
<lifeless> nsh22: cd branch1 && bzr merge branch2 && bzr commit && bzr push
<abentley> lifeless: Rather than at __init__ time, as you do with the RevisionTree.
<nsh22> lifeless: thx
<abentley> lifeless: What's the reason for delaying that?
<lifeless> abentley: I guess I was thinking of cases where 'bzr switch' was used and the backing repo facilities changed
<abentley> lifeless: I dunno how long the suite takes.  Maybe 25 minutes?
<lifeless> abentley: with the bzr-ec2test plugin & 2 warmed up instances, its takes ~90 seconds. You might like to play :)
<abentley> lifeless: In the 'switch' case, the tree would remain write_locked during the switch, so the _repo_supports_tree_reference would get stale, wouldn't it?
<lifeless> abentley: possibly yes; I guess you're trying to see whether to work around [e.g. getattr, init to None etc] or to move it to __init__ - I'm happy either way, or even a third
<lifeless> I'd suggest avoiding a getattr(), I don't think one is justified
<abentley> lifeless: I'm also wondering if the win of caching that data on WT is worth it.  Thoughts?
<lifeless> if its accessed during the iter_changes outer loop it may be measurable on 'bzr st' timings
<lifeless> abentley: oh, possibly it wasn't caching at all; maybe WT2 can't be right root ?
<lifeless> and so we have tree code that correctly needs to ask the tree not the repo.
<abentley> lifeless: I suppose that's useful when you're detecting subtrees and then forcing them to directories because of the repo.
<lifeless> abentley: well also for 'add-reference' to fail correctly when the tree can't represent the add
<abentley> lifeless: In that case, I don't think the caching is essential.
<abentley> WT2 can implement add_reference to always raise...
<lifeless> Peng_: so, what is 'bytes'
<Peng_> lifeless: Eh?
<jelmer> ricardokirkner: hi
<jelmer> ricardokirkner: are you using the latest bzr, bzr-svn and subvertpy?
<ricardokirkner> hi jelmer, thanks
<ricardokirkner> bzr 1.13
<ricardokirkner> latest bzr-svn
<ricardokirkner> and subvertpy
<ricardokirkner> yes
<ricardokirkner> I have been tracing bzr, until I got to line commit.py:600
<jelmer> ricardokirkner: please run inside of gdb and pastebin the bracktrace
<ricardokirkner> I'll do that
<ricardokirkner> but maybe I have found the reason. let me explain
<jelmer> ricardokirkner: subvertpy 0.6.5?
<ricardokirkner> yes
<ricardokirkner> and python 2.6 (64 bits)
<ricardokirkner> the line that causes an abort, is when doing
<ricardokirkner> ret.append(ret[-1].add_directory(name, copyfrom_url, base_rev))
<ricardokirkner> now, I just saw that copyfrom_url ends with a '/'
<ricardokirkner> I from what I read, that is causing the svn abort
<ricardokirkner> does this make sense?
<jelmer> ricardokirkner: copyfrom_url doesn't matter in this case
<jelmer> ricardokirkner: does path end in / ?
<ricardokirkner> what path?
<ricardokirkner> name?
<jelmer> ricardokirkner: anyway, that backtrace would really be useful here..
<ricardokirkner> ok
<ricardokirkner> sec
<ricardokirkner> jelmer, http://ricardokirkner.pastebin.com/d3ec659ab
<lifeless> mwhudson: is loggerhead bust?
<lifeless> mwhudson: it shows me no diff for http://bazaar.launchpad.net/~geoff.bache/bzr/trunk/revision/4158
<mwhudson> lifeless: 'expand all'
<lifeless> mwhudson: does nothing
<Peng_> lifeless: It's all Ajaxy now. Do you have JS disabled, or a weird browser?
<mwhudson> lifeless: hmm, maybe shift-reload
<Peng_> lifeless: It works for me.
<Peng_> Oh, good point.
<mwhudson> i keep meaning to vary the static urls by version...
<lifeless> Peng_: epiphany,
<lifeless> mwhudson: thanks
<lifeless> mwhudson: and please do that, kthanksworking
<jelmer> ricardokirkner: please try again with latest rev on subvertpy
<ricardokirkner> jelmer, I installed subvertpy using easy_install, should I try downloading from trunk?
<jelmer> ricardokirkner: yeah
<ricardokirkner> ok
<jelmer> lifeless: any chance you can have a look at my BzrDir.push() patch ?
<lifeless> jelmer: sure, url
<jelmer> lifeless: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090401141753.GA16842%40vernstok.nl%3E
<ricardokirkner> jelmer, same thing :-(
<jelmer> ricardokirkner: are you sure you're running the latest subvertpy
<jelmer> ricardokirkner: oh, whoops
<jelmer> ricardokirkner: push failed, one sec
<ricardokirkner> oh
<jelmer> ricardokirkner: pushed properly now, r2051
<Peng_> lifeless: Oh, sorry I didn't understand you. I updated the get_bzr_remote_path bug.
<Peng_> Wait a minute, it's *supposed* to be the contents of branch.conf, so why is ConfigObj balking?
<ricardokirkner> jelmer, :-(
<jelmer> ricardokirkner: ?
<ricardokirkner> same thing still happening
<ricardokirkner> I checked and doublechecked
<jelmer> ricardokirkner: backtrace?
<jelmer> ricardokirkner: at least the line numbers should be different..
<ricardokirkner> ok, one sec
<ricardokirkner> jelmer, http://ricardokirkner.pastebin.com/d767040a9
<ricardokirkner> jelmer, I have to go now,.. will try again later
<ricardokirkner> thanks a lot for your help
<jelmer> ricardokirkner: I'm working on a fix
<jelmer> ricardokirkner: to subvertpy
<jelmer> should be committed in a few minutes
<Peng_> lifeless: ping
<lifeless> Peng_: pong
<Peng_> lifeless: Hi.
<lifeless> hawwo, was just responding, again, to the 1.14 delay thread
<lifeless> hopefully Ian wins troll of the year award
<lifeless> for his april first post
<Peng_> ?
<lifeless> new 1.14rc date, was posted april 1st
<Peng_> Oh.
<lifeless> he really needs to jump out about now in the thread and say 'april fools'
<lifeless> :)
<lifeless> anyway
<Peng_> lifeless: I was just pinging you because I want hand-holding through the get_config_file bug. :D
<lifeless> right
<lifeless> just change it to bytes.splitlines('\n') is probably enoug
<lifeless> rather than [bytes]
<lifeless> also config objs constructor blows chunks
<Peng_> I just used "splitlines()". That's what I wanted to ask.
<lifeless> oh
<lifeless> yeah that shold be fine
<lifeless> working >> anything else
<Peng_> Is that alright? Should I only split on \n?
<lifeless> splitlines should be ok
<lifeless> jelmer: does bzrdir.push work for you?
<BasicOSX> lifeless:  thanks for the response regarding 1.14 RC date
<BasicOSX> I think mbp should never go on another holiday again, ever! :-P
<lifeless> BasicOSX: :)
<Peng_> lifeless: Anyway, the other thing I wanted to ask you about was adding a test.
<Peng_> Um.
<lifeless> Either expand one of the test_remote.py tests for _get_config
<lifeless> or add another in the same class
<lifeless> just set two keys and then get one back
<lifeless> should trigger
<Peng_> Um.
<Peng_> Pardon my dumbness, but I'm completely lost in the test suite.
<lifeless> una momento
<Peng_> Wait, hold on.
<Peng_> I think I can just copy test_get_branch_conf.
<Peng_> Or I could just modify it to use a 2-line file.
<Peng_> Oh, interesting. ConfigObj(['# line 1\n# line 2\n'], encoding='utf-8') works.
<Peng_> You need non-comment lines to trigger the failure.
<Peng_> lifeless: Where should I add the test? test_remote.TestBranchControlGetBranchConf? That seems to be the only place it's tested.
<Peng_> lifeless: (I mean, in that file..)
<lifeless> Peng_: yes, thats the unit test for it
<Peng_> lifeless: Should I modify the current test or add a new one? I'd prefer to do the latter, just...cuz.
<lifeless> either is fine, new test is clearer
<Peng_> Okay.
<Peng_> Then...send it to the mailing list? :D
<Peng_> lifeless: If that email *was* an April Fool's joke, he definitely wins this year. That sparked a huge discussion!
<lifeless> Peng_: sadly it wasn't
<lifeless> Peng_: yah, [MERGE] it up
<Peng_> lifeless: Oh, too bad.
<lifeless> it will need to be cherry picked to 1.14 too now :)
<Peng_> lifeless: ok
<lifeless> jelmer: ping
<lifeless> jelmer: does the BzrDir.push patch meet your needs, and is it mainly moved code?
<jelmer> lifeless: yes and yes
<yacoob> Hello there :)
<lifeless> jelmer: land it
<jelmer> lifeless: is that a bb:approve ? :-)
<yacoob> a (perhaps stupid) question: provided I want to keep a set of config files in a bazaar repository, is there a way of saying 'get me this revision of this file from repo'?
<lifeless> jelmer: not quite
<lifeless> yacoob: bzr cat -r X this_file
<jelmer> lifeless: so what do you mean exactly?
<lifeless> I've reviewed
<lifeless> BasicOSX: I too am a little confused
<lifeless> BasicOSX: did you mean 'land bbc now' too ?
<BasicOSX> lifeless:  yes
<lifeless> ok cool.
<lifeless> we'll land on trunk and merge to the rc branch then - you might like to clarify that on the list :)
<jelmer> lifeless: ? land it where ?
<jelmer> lifeless: oh never mind
<jelmer> lifeless: I hadn't seen your email reply
<Peng_> What's being landed where?
<Peng_> lifeless: Anyway, I think I sent it. My IMAP server is slow today, but SMTP probably works.
<lifeless> Peng_: if I understand BasicOSX correctly; brisbane-core will go to bzr.dev asap (meaning a once-through review) and be cherry picked to 1.14
<lifeless> BasicOSX: ^ is that what you mean to have happen?
<Peng_> Cherry-picking hundreds of revisions consisting of thousands of lines of code sounds like "fun".
<jelmer> hmm
 * jelmer thinks one of the hot topics at the bzr sprint this year should be "parallel imports"
<johnjosephbachir> 'ello. bzr newbie here. i just did a couple commits, then did "uncommit" twice, then commited that. all seems to have behaved as epected, and bzr status shows no changes. BUT, the actual source tree has not been changed!
<lifeless> johnjosephbachir: it would't have
<johnjosephbachir> ORLY
<Peng_> johnjosephbachir: "uncommit" and "commit" don't change the working tree.
<lifeless> uncommit pops a commit off, it doesn't revert the changes in your tree
<BasicOSX> I was under the impression BC was in 1 branch that could be merges in bzr.dev?
<lifeless> BasicOSX: it is
<BasicOSX> :%s/merges/merged/
<johnjosephbachir> lifeless Peng_ okay cool cool... sooooo what do i do? :)
<lifeless> johnjosephbachir: well, what do you want to achieve?
<BasicOSX> Sorry on the busy and very bumby, typing going to be hard
<BasicOSX> busy=bus :-)
<BasicOSX> type
<lifeless> :)
<johnjosephbachir> lifeless: i waaaant.... to make my source tree reflect... my commits? (maybe i have the wrong terminology)
<lifeless> BasicOSX: so am I understanding correctly? [you can say yes/no] - we merge it to .dev, and to 1.14
<Peng_> johnjosephbachir: After uncommitting, if you want to throw out all of your noncommitted changes, use "bzr revert".
 * igc breakfast
<johnjosephbachir> Peng_: hmm... just tried it... no change to files
<BasicOSX> yes .dev, yes 1.14
<lifeless> BasicOSX: thanks! will get right on it
<Peng_> johnjosephbachir: Because you went and committed all of the changes again.
<johnjosephbachir> Peng_ lifeless oh maybe i didn't commit... the uncommits properly, because i didn't revert after doing the uncommits?
<johnjosephbachir> haha, okay
<Peng_> johnjosephbachir: You don't commit an uncommit. When you run uncommit, it removes the revision from the branch's history.
<BasicOSX> can yyuou clarify on the maikkling llist (eerrr!) so people aren't freaking out? <- lifeless
<Peng_> johnjosephbachir: After running "uncommit", it's done. There's nothing left to do.
<johnjosephbachir> Peng_: OIC
<johnjosephbachir> thanks
<BasicOSX> i will follow up properly once I get home
<Peng_> johnjosephbachir: When you ran "commit" afterwards, all you did was commit all of the changes in your working tree, including the changes from the 2 revisions you uncommitted.
<johnjosephbachir> oh noes!
<johnjosephbachir> Peng_: okay, thanks, i'll try to apply all that knowledge and see where i get
<johnjosephbachir> Peng_: yes, working perfectly now. hooray for bzr!
<Peng_> :D
<lifeless> BasicOSX: sure thing
<BasicOSX> almost out of battery back tonight
<lifeless> ciao
<thewrath> hey all
<thewrath> i got bzr working
#bzr 2009-04-03
<lifeless> spiv: so am I booking for 3, 4 or 5?
<lifeless> jml: ping me when you leave home
<jml> lifeless: will do
<johnjosephbachir> if i merge in some changes from the parent branch, and they all come in smoothly and their own commit messages are sufficient to describe the changes, and then i want to commit them to my branch without my own log comments, is there slick/standard way to do this, or must i type "merging in some changes"
<spiv> lifeless: good question, just a sec
<Peng_> johnjosephbachir: Well, I think it's good practice to give a short (one-line) description in the merge commit.
<johnjosephbachir> Okay.
<Peng_> You can always copy and paste it from one of the revisions you're merging. :D
<spiv> lifeless: 5, I think
<garyvdm> I'm getting an error in some qbzr code that I'm working on - that I just can't figgure
<garyvdm> http://pastebin.com/d98bbf0e
<garyvdm> I'm expecting a InvalidRevisionSpec to be raised, but I get the TypeError displayed ing the pastebin
<garyvdm> Please can someone help me out
<lifeless> garyvdm: TypeError: 'NoSuchRevisionSpec' object is not callable
<lifeless> garyvdm: you have something called NoSuchRevisionSpec which isn't a class (callable) or function(callable)
<garyvdm> there is errors.NoSuchRevisionSpec - but I'm not calling it
<garyvdm> It's not getting called anywhere
<lifeless> run with BZR_PDB=1
<lifeless> then you can debug
<garyvdm> ok
<garyvdm> export BZR_PDB=1 ?
<lifeless> or just BZR_PDB=1 ./bzr foo
<garyvdm> lifeless: I just get the same traceback written to the console.
<lifeless> garyvdm: uhm
<lifeless> put a pdb import and trace at the point its raised then, perhaps
<garyvdm> ok
<garyvdm> lifeless: fixed :-)
<garyvdm> I had except errors.NoSuchRevisionSpec, errors.InvalidRevisionSpec:
<garyvdm> changed to
<garyvdm> except errors.NoSuchRevisionSpec:
<garyvdm>    ...
<garyvdm> except errors.InvalidRevisionSpec:
<garyvdm>    ...
<garyvdm> thanks
<meoblast001> hi
<lifeless> meoblast001: hi
<igc> lifeless: I've started on the process of preparing brisbane-core patches for landing into bzr.dev
<lifeless> igc: cool
<igc> lifeless: I just want to check how you want it done ...
<lifeless> igc: theres nearly 800 commits in bbc, I was thinking we might want to just cherrypick bits
<igc> me too
<lifeless> until the branch has no content
<igc> so my plan is ...
<igc> merge bzr.dev into bbc (done)
<igc> branch bzr.dev xxx
<lifeless> and iterate
<lifeless> sure
<lifeless> lets start with chk_map
<lifeless> actually
<igc> merge ../brisbane-core/x ../brisbane-core/y ../brisbane-core/z ...
<igc> right
<lifeless> lets start with the knit changes to support autogenerating the keys from the sha
<lifeless> 1
<lifeless> that will lead into chk_map
<lifeless> which leads into the inventory changes
<igc> so first patch with be gc + chk as that's all new stuff + some tweaks to setup.py & tests/__init__.py
<igc> knit stuff is knit.py + what else?
<lifeless> gc and chk are separate things
<lifeless> I'm not sure you should land them together if you want to be doing specific patches
<igc> ok
<lifeless> knit stuff is knit.py/weave.py/versionedfiles.py and their tests
<igc> ok, I'll do that one first, then gc, then chk_map
<igc> lifeless: and you can review/approve them :-)
<lifeless> sure thing
<lifeless> I'd be inclined to do knit stuff, chk_map, chk_inventory, gc, new-format. With anything not covered by that list as soon as it can be done topologically.
<lifeless> Peng_: ping
<Peng_> lifeless: pong
<lifeless> Peng_: did you send a bundle to the list or just push your branch
<Peng_> lifeless: Both.
<lifeless> hmm, I can't see the bundle
<Peng_> lifeless: Although my email client and/or IMAP server are screwy, so I can't *read* the list.
<lifeless> I'll merge your branch to another branch fleshing out the config stuff I have
<Peng_> Oh, really?
<Peng_> Well, according to the list archive, there's *something* attached to my message.
<lifeless> hmm
<lifeless> anyhow, I'll incorporate it :)
<lifeless> though your pushed branch is missing the test changes
<Peng_> Oh, really?
<lifeless> yes
<Peng_> lifeless: BundleBuggy found it fine.
<Peng_> lifeless: Oh, LP is, since it won't mirror the branch for a couple more hours. My server has them, though.
<lifeless> http://bazaar.launchpad.net/~mnordhoff/bzr/fix_get_config_file/revision/4242
<lifeless> ah k
<Peng_> Hey, I think that's the first bug that got assigned to me. :D
<spiv> lifeless: hmm, actually, just 4 for dinner; Mary can't make it after all.  Sorry about the late notice.  I'm still in.
<lifeless> k
 * lifeless books
 * igc lunch
<lifeless> spiv: your books are here
<spiv> lifeless: funny you should say that, I was just about to head out the door to join them :)
<spiv> lifeless: see you soon!
<Cessen> Is there a reason that stacked branches require access to the stacked-on branch, even for operations that don't involve history prior to the branching?
<Cessen> For example, I can't commit locally without access to the stacked-on branch.  This seems really weird to me.
<Cessen> I'm wondering if there is a rationale for this, or if it's just something that hasn't been gotten to yet.
<lifeless> Cessen: stacked branches federate the bzr database; they are not intended for disconnected operation.
<lifeless> Cessen: We plan to have a thing called'history horizons' which would permit that, but its not in any developers current todo list that I know of
<lifeless> Cessen: we're bringing in a massive improvement to history size though - a 60% reduction in disk and network utilisation, over the next few releases.
<lifeless> Cessen: which should make the need for '--stacked' when making local branches a lot less
<Cessen> lifeless: so are stacked branches mainly intended as an alternative to shared repos, then?
<lifeless> yes.
<Cessen> Okay.  Thanks.  That's where my misunderstaning was, then.
<lifeless> also for publishing branches, so you don't have to upload a lot of data when giving someone your branch
<lifeless> as uplinks are usually even smaller than downlinks
<Cessen> Okay.
<Cessen> When I read descriptions of it I thought it was like "history horizons" that you mentioned above.  So I was very confused when I tested removing the branch I branched from, and then couldn't do anything.
<lifeless> Cessen: ah yes, I can understand that
<Cessen> Anyway, thanks for your help. :-)
<Cessen> I like to abuse bzr for revision control of media files.  History horizons would make it viable for collaborative online media projects, too, which would be cool.
<Cessen> I can always dream. :-)
<Cessen> I suppose bzr dev is focused more on code vcs, though.  Which makes sense.
<lifeless> we're certainly open for improvements for all history needing projects
<lifeless> but yes, code is the primary goal :)
<Cessen> lifeless: thanks very much for your time. :-)
<jfroy> I just pulled bzr.dev
<jfroy> and, erm... I can't seem to be able to pull anything :p
<spiv> jfroy: bug 354036?
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [High,Confirmed] https://launchpad.net/bugs/354036
<jfroy> bzr just errors out with "bzr: ERROR: Not a branch" giving me the path of the cwd.
<spiv> Oh, something different :)
<jfroy> No matter which protocol I give it :p
<jfroy> spiv: yeah, was trying to do the http pull.
<jfroy> revno 4241 on bzr.dev
<jfroy> anyone else seeing something similar?
<jfroy> Getting something like
<jfroy> jfroy:Projects bahamut$ bzr pull lp:rivenx
<jfroy> bzr: ERROR: Not a branch: "/Volumes/Crossroads/bahamut/Documents/Projects/".
<spiv> jfroy: things seem normal for me so far
<jfroy> mmmm
<spiv> jfroy: what's the traceback in ~/.bzr.log?  (pastebin it)
<jfroy> http://pastebin.com/dfe6d1a1
<jfroy> It makes no sense to me :p
<spiv> jfroy: do you mean s/pull/branch/ ?
<spiv> jfroy: or is /Volumes/Crossroads/bahamut/Documents/Projects/ meant to be a branch of lp:rivenx already?
<jfroy> ahhhhhhhhhh
 * jfroy rams head in wall
<spiv> :)
<jfroy> You are, of course, right on.
<jfroy> http puling is sooooo slow
<jfroy> well, slower
<jfroy> OK, the pull worked fine through http.
<kfogel> whew. Python PEP 0374 ended up on O'Reilly Radar blog.
<vila> hi all
<Peng_> Good morning.
<vila> Peng: good morning :) Did your quota get restored ? :-P
<Peng_> Yes, but then I traded it for some cold pizza.
<igc> hi vila
<igc> lifeless: shall I land the chk_map code into bzr.dev or leave that bit to a proper merge of the main bits?
<fullermd> Wait.  I can get cold pizza just for handing over my quota?
<igc> spiv: can I get a quick review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D59D2E.50500%40internode.on.net%3E
<igc> spiv: vila wrote this code so he could approve it (given I think it's ok) but if you're still around, it will only take a minute or two
<igc> vila: I think spiv and lifeless might be offline for a few hours
<igc> vila: can I request a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D5B919.9090700%40internode.on.net%3E please?
<igc> I'm landing all the trivial, next-to-zero risk stuff out of brisbane and I need a vote to keep pqm busy :-)
<vila> igc: the diff by itself doesn't make much sense, I'm a bit concerned that landing pieces like that screw the annotations badly and will make debugging harder :-/
<vila> igc... oh wait !
<vila> igc:  may be there is a way to still merge the bbc branch once everything has landed...
<vila> igc: regarding your request above, I approved it, but that doesn't carry much weight, except that I remember having seen that modifications and I'd say they come from at least 3 different sources
<lifeless> igc: the one that got approved is good to land
 * awilkins is interested in this "cold pizza" that is spoken of
<visik7> when I merge from a branch do I need to put a insigniful comment in the commit after the merde ?
<visik7> merge
<vila> visik7: was there anything interesting brought in by that merge ? That's what *readers* want to know
<visik7> I mean I usually  merge instead of update
<visik7> 'couse I can see and revert if something goes wrong (usually I forgot at which revision I was)
<visik7> but if I would commit I need to put a meaningless message
<visik7> nevermind I run a revert and update
<joie> Hi - I'm moving over from baz to bzr (gradually) and reading a lot about cherry picking changes, and how bzr doesn't support such things as "skip present" and so on, that baz did. I was wondering if there had been any improvements in this area in recent times (the discussions I've found about it are rather old). Ta!
<james_w> joie: no improvements, but a bit more discussion recently
<james_w> I'm not sure how close anyone is to working on it right now
<joie> I essentially have a situation identical to this one as discussed some time ago "Cherrypicking workflows with bzr": https://lists.ubuntu.com/archives/bazaar/2006q1/007591.html
<joie> So looks like for the forseeable future I'll have to live with more conflicts between branches/trunk, unfortunately. It's not all bad news - bzr is better in lots of other ways, I'll just have to be careful with merging!
<joie> Even if we can't track cherrypicks, one thing that would be really useful is to be able to "pretend" to have merged all the changes from one branch to another - rather like baz sync-tree - do you know if something like this is possible in bzr? Thanks again!
<james_w> joie: I'm not familiar with baz, so I don't know what the command does
<james_w> in bzr it's possible to merge in all the changes from a branch, without actually making any of the changes
<james_w> so that a further merge would not do anything, but your branch content hasn't changed ata ll
<Stavros> hello
<Stavros> i have some local commits, how can i push them upstream?
<Stavros> bzr up shows them as local merges and asks me to commit again
<joie> james_w: that sounds perfect!
<james_w> Stavros: if you commit they will be committed upstream as well
<james_w> joie: to do that you do the merge and then run "bzr revert ."
<Stavros> but i have already committed them locally, i just want to push them
<james_w> the "." means just revert the tree changes, not the pending merges
<joie> james_w: I'll try that - thanks for the tip!
<james_w> if you then run "bzr status" you will see no files changed, but there will be pending merges
<james_w> you then commit
<james_w> and then try "bzr merge" again and it will say "Nothing to do"
<Stavros> james_w: is that for me?
<james_w> Stavros: it's not possible to "just push" as upstream had also done some work, so you had diverged
<Stavros> james_w: i don't think it had, as i'm the only person working on this
<Stavros> how can i check?
<james_w> ah, then perhaps "bzr up" with local commits and no changes to the master branch does something different to what I expect
<james_w> run "bzr log -r -10.." and see what those revisions are
<james_w> if they are things that were already there when you did your local commit then I am confused
<Stavros> there were, all i see is my changes
<Stavros> i committed revision 50, then 51 locally, and tried to commit 52 upstream
<Stavros> but now i get odd messages about pending merges and inability to do select-file commits
<fullermd> I'm pretty sure update with local commits always turns them into pending merges.
<Stavros> probably, yes
<Stavros> but what do i do?
<fullermd> Commit.
<Stavros> i can't commit, i have pending file changes
<SamB> can you stash?
<Stavros> hmm, yes
<Stavros> bzr shelve?
<fullermd> Well, there's not much point in committing if you DON'T have pending file changes  ;p
<Stavros> i have changes i don't want to commit
<Stavros> i only want to commit a file
<Stavros> but it doesn't support it, apparently
<fullermd> Yes, if you have pending merges, you can only commit the whole tree.
<fullermd> No way to record a partial-tree merge.
<Stavros> bzr: ERROR: Selected-file commit of merges is not supported yet
<Stavros> hmm
<Stavros> okay, i'll shelve then
<SamB> why does bzr up do that without asking for any kind of okay ?
<SamB> bzr merge requires --force to get you into this sort of mess ...
<fullermd> I'm not the guy to ask  ;p
<Stavros> hmm
<ronny> hmm
<ronny> bzr log in a svn workdir is painfull
<ronny> at least the initial one
<fullermd> I do that sort of thing in CVS workdirs sometimes.  That's not painful.  Just depressing.
<SamB> isn't using CVS painful though?
 * SamB remembers CVS getting stuck on his old 56k connection ... having to abort with only half of the files updated ...
<OllieR> Hey I am trying to revert a branch to exactly how it was at revno 9. I added a whole load of files to do an upgrade, but now want to go back. I did bzr revert and all the files that were versioned have been reverted. Great! But there are a whole load of unknown files when I do bzr st. Can I issue a command to remove all these new unknown files so I am completely back at revno 9 as if I did a checkout?
<OllieR> just wondering before I go off an do a long rm session
<igc> abentley: can you poke BB soon please? Seems to be down
<james_w> hi igc
<james_w> OllieR: bzr clean-tree can do that
<james_w> rm $(bzr unknowns) as well
<OllieR> clean tree is not a core command right?
<james_w> only recently
<igc> hi james_w: how was your holiday btw?
<OllieR> so i will go for the command substitued rm route
<james_w> igc: very nice thanks
<james_w> your city is very pleasant :-)
<OllieR> james_w: thanks a lot
<igc> james_w: it is. Did you get to see much outside the city?
<ronny> jelmer: sup? does dulwich have a own api for building commits by now?
<ricardokirkner> hi jelmer, I just wanted to tell you that everything went fine after your last commit
<ricardokirkner> thanks a lot for the help
<james_w> igc: I didn't unfortunately, but I had a very relaxing time.
<jelmer> ronny: hi
<jelmer> ronny: You can build and serialize the various objects and add them to a git repo
<jelmer> ronny: but there's no function yet that you can tell "please go and do a commit in this working tree" yet
<ronny> jelmer: but it should just work via bzr's workingtree for now?
<ronny> (i want an reasonable way to build in-memory commits in memory)
<jelmer> ronny: no, bzr's workingtree doesn't work on git indexes yet
<jelmer> ronny: you can commit in bzr working trees and dpush into git though
<ronny> jelmer: i dont need an index, just commit
<jelmer> ronny: So you need to do in-memory commits?
<ronny> well, more something like a commitbuilder
<jelmer> ronny: and you have a tree in memory that you'd like to commit?
<ronny> jelmer: yeah, this is supposed to be a simple backend for a cms/wiki - i want simple support for all dvc's, and no possibility of concurrent fuck up in workdirs
<jelmer> ronny: so, while we don't have a commit builder it's trivially possible to create one yourself in a few lines of code
<jelmer> and specific to your problem
<jelmer> I'm happy to help, but it's hard to comment without looking at the code
<ronny> hmm, ok, then i'll just try to do one in anyvc
<ronny> bascially build blobs, build trees, build commit
<ronny> well, and update refs ^^
<abentley> igc: restarted.
<igc> abentley: thanks
<igc> night all
<jelmer> ronny: cool
<ronny> jelmer: btw, is subvertpy able to do commits without workdir?
<ronny> (and is there a simple example ican steal)
<jelmer> ronny: yes, it can
<jelmer> ronny: I'll add an example to examples/
<vila> igc: really gone ?
<ronny> jelmer: btw, do you see any way to have the svn log as iterator instead of callback?
<jelmer> ronny: not really
<jelmer> ronny: in C it's a callback
<jelmer> ronny: so the only way to do that is to use threads
<jelmer> ronny: bzr-svn has a wrapper that does that
<ronny> so threads + queue
<ronny> sad
<ronny> i wonder if greenlets could do
<jelmer> ronny: yeah, that's a limitation of the svn unfortunately
<jelmer> SVN *API* I mean
<jelmer> ronny: I've committed an example of using ra.get_commit_editor()
<ronny> ok, looks like a bearable startingpoint
<ronny> jelmer: btw, does svn actually have anything to reliable figure branches/tags ? last time i asked the svn people about the actual structure they told me random gibberish about a dag and needing to read the api
 * maxb wonders what it means to "figure branches/tags"
<ronny> maxb: well, in svn branches/tags are bascialy copy's
<maxb> Indeed.
<ronny> so one needs to figure whats a normal copy,and whats a branch/tag
<maxb> Well, the only way to do that is by conventions / naming scheme
<jelmer> ronny: yeah, conventions are the only way
<ronny> i know of projects that break them awfully nasty
<maxb> Most svn users accept the advised trunk,tags,branches idea, some..... really don't :-)
<jelmer> ronny: yeah, there's no way around that
<ronny> well, i know of people that switched around conventsions various time in the early days of svn
<jelmer> ronny: bzr-svn looks at the changes in the last 2k revisions and uses that to determine if one of the standard layouts is being used
<jelmer> that seems to work pretty well
<ronny> i'd like to take a look at the usual complete graph of copy's + deletes to see whats up in my absraction
<ronny> jelmer: do i understand it right, that editor.close generates the commit?
<jelmer> ronny: yeah
<ronny> any exceptions for remote commits?
<ronny> hmm, and i should figure how to deal with workdir status
<jelmer> ronny: no, just specify a different URL to RemoteAccess() :-)
<ronny> jelmer: sorry, bad workding, i mean what exceptions may it throw when i do conflicts
<ronny> im preparing for a anyvc sprint over the weekend, parital history view + branches support + creating history
<ronny> then later maybe merges and deal with local branches
<ronny> since im not going for isomorph mappings, but just access its damn much more easy than bzr's stuff
<jelmer> ronny: SubversionException
<jelmer> ronny: is the only class of exception it will raise, with different error numbers
<ronny> jelmer: so its bascially just a errno alike?
<vila> fwiw bbc pass the full test suite under python 2.[456]
<jelmer> ronny: yeah; "pydoc subvertpy" has the most common ones
<jelmer> ronny: it also includes a (localized) error message
<ronny> jelmer: how would i get the workdir status via subvertpy?
<jelmer> ronny: subvertpy.wc.WorkingCopy
<jelmer> allows you to open and inspect the working copy
<ronny> hmm, looks weird, lets see if i can get it usefull in anyvc
<mgedmin> awesome!  I'm in the middle of an editor writing a message for bzr commit, but I can run bzr log in a different window
<mgedmin> I didn't expect I could do that
<jelmer> hmm, can we use --parallel on the PQM machine ? (-:
<vila> jelmer: hmmm, I don't think so :) Did you use it locally ?
<jelmer> vila: no, I haven't tried it yet
<vila> A lovely side-effect, IMHO, is that traceback for failing or erroring tests is now displayed as soon as it occurs
<vila> unfortunately it's a bug that we should fix :)
<vila> I confess that I'm not very motivated to fix it
<jelmer> ahh
<jelmer> vila: Hmm, it looks like lp:testtools doesn't export the right objects; do I need to use something else?
<jelmer> ah, I was using the wrong branch
<jelmer> --parallel is pretty quick compared to serial..
<antoranz> Guys!
<antoranz> I need some help
<antoranz> after having imported from a git (imported from svn, by the way), I ended up with no room in my home
<antoranz> there I had two directories: git-svn and master
<antoranz> so I deleted them
<antoranz> I moved .bzr to another partition, I "packed" the repo
<antoranz> and now I want to see those two branches
<antoranz> how can I "rebuild" them?
<jelmer> antoranz: I'm not sure I understand completely what you mean
<jelmer> but I think "bzr heads --all" is what you are looking for
<antoranz> let's see
<antoranz> I imported from git
<antoranz> that, ok?, right?
<antoranz> at the end of the import, I was told I had two branches: git-svn and master
<antoranz> there were two directories with those names in the sahed repo
<jelmer> sure
<antoranz> but I had no room left in the partition
<antoranz> so I moved .bzr (nothing else) no another partition
<antoranz> to, I mean
<antoranz> I packed it
<antoranz> and now I want to be able to recreate those two branches in the shared repo
<antoranz> how can I do that?
<jelmer> just copy them over
<antoranz> I deleted them
<jelmer> run "bzr heads --all"
<antoranz> ok
<jelmer> and then you should be able to recreate them
<antoranz> how about just a branch?
<antoranz> heads is not in the bzr commands
<antoranz> bzr: ERROR: unknown command "heads"
<jelmer> I think you need bzrtools
<antoranz> installing....
<antoranz> I can see the last revision (I think). What's next?
<antoranz> jelmer: ok... so how do i recreate them?
<jelmer> bzr init trunk
<jelmer> bzr pull -d trunk -rrevid:<somerevid>
<antoranz> from the base of the shared repo?
<jelmer> yeah
<jelmer> at least I think that's how you do it, I've never done this before
<jelmer> abentley: I see your patches still use the dirstate-with-subtree format rather than something newer, is that intentional?
<abentley> jelmer: No, that's just what they've always used.
<antoranz> jelmer: doesn't work
<beuno> so, I'm going crazy here. I have a specific revision deep down in history, that does a bunch of changes to a bunch of files, that I want to revert
<antoranz> bzr: ERROR: No pull location known or specified.
<jelmer> antoranz: perhaps try this:
<jelmer> antoranz: bzr pull -d trunk -rrevid:<somerevid> trunk
<antoranz> just in case.. the <> are your remaks or they are necessary?
<jelmer> antoranz: they're my remarks
<beuno> how would I do that?
<antoranz> ok
<jelmer> beuno: reverse merge  ?
<antoranz> jelmer: Could not determine revno for {konold@283d02a7-25f6-0310-bc7c-ecb5cbfe19da-19990503013312-xiqgf956oal5i62} because its ancestry shows a ghost at {konold@283d02a7-25f6-0310-bc7c-ecb5cbfe19da-19990503013312-xiqgf956oal5i62}
<beuno> jelmer, bzr merge -r $oldrevno?
<beuno> it says "nothing to do"
<james_w> you need $oldrevno..$oldrevno-1
<antoranz> or 0..oldrevno?
<beuno> hrm, this gets complicated because the revno is burried inside a merge
<james_w> we could do with a "parent:" revspec
<abentley> james_w: We have one.
<james_w> ah
<james_w> even better
<abentley> james_w: It's "before:"
<antoranz> so, what do I do? Slash my wrists with a sharpless spoon? :-D
<james_w> one that also allowed you to select which parent would be peachy, but that covers 99% of cases, thanks
<beuno> so:  bzr merge -r:before:..7578 ?
<james_w> bzr merge -r 7578..before:7578
<abentley> beuno: "bzr merge -r:before:7578..7578 ."  Remember the .
<james_w> won't that try and make the same changes again?
<beuno> bzr: ERROR: No namespace registered for string: u':before:7578'
<abentley> beuno: Sorry, should be "bzr merge -r 7578..before:7578 ."
<beuno> new error!
<beuno> bzr: ERROR: No namespace registered for string: u':7578'
<abentley> beuno: Are you sure you didn't put an extra colon?
<beuno> beuno@dell-desktop:~/canonical/lp-branches/blueprints_kill_portlet$ bzr merge -r:7578..before:7578 .
<beuno> ah
<jelmer> antoranz: probably easiest to redo the import
 * beuno hides
<antoranz> oh, man... don't say that... not even playing. :-)
<beuno> abentley, jelmer, james_w, thanks
<antoranz> but come on.... if the import ca recreate the branches, so should I right?
<jelmer> antoranz: well, I'm not sure how the import determined the revno
<jelmer> antoranz: how was the import done?
<james_w> "bzr branch trunk temp -r revid:whatever" might work?
<jelmer> james_w: that gives an error about not being able to termine revno because of ghosts
<james_w> oh, missed that error, sorry
<rbriggsatuiowa> I did a bad bzr revert
<rbriggsatuiowa> is there a way to undo a revert?
<james_w> rbriggsatuiowa: it will have left backup files in the tree
<james_w> whatever.~<num>~
<beuno> beatiful, this bzr thing is really amazing
<rbriggsatuiowa> THANK YOU!
<AnMaster> I'm trying to find a way to copy a directory (and all files in it) and keep it's history, but I can only find bzr mv to move, bzr cp doesn't seem to exist.
<abentley> AnMaster: That's correct.  bzr does not support copies at present.
<AnMaster> I need this because I'm splitting a certain sub-library of the projects in two diverging variants, which will be diverging and tuned/specialised for different loads (if project was in C I would probably use the preprocessor instead)
<LeoNerd> A file in bzr just exists. It has revision controlled properties. One such property is its filename.
<AnMaster> abentley, oh... any plans to add such support?
<LeoNerd> A file can therefore only have one such name
<AnMaster> hm ok
<abentley> AnMaster: There are some ideas, but no firm plans.
<NfNitLoop> AnMaster: Is that not a case for a new branch?  `bzr branch` works well. :)
<AnMaster> NfNitLoop, both will be used in the same build, but for different tasks
<NfNitLoop> AnMaster: aah.
<AnMaster> NfNitLoop, need two very differently tuned internal hash libraries basically.
<antoranz> jelmer: I tried heads --tips and bzr exploded
<jelmer> antoranz: how did you do the original import?
<antoranz> well.... I exported from git and gzipped ther result
<antoranz> then i zcat | bzr fast-import - (basically)
<jelmer> antoranz: I think you've hit a bug in bzr-fast-import
<jelmer> antoranz: afaik it should never create ghosts
<antoranz> wait till I recover from laughing on the floor at the sight of wasting so may CPU hours importing this. :-S
<antoranz> I'll try to reimport to see if it just finishes the job.
<jelmer> antoranz: please file a bug against bzr-fast-import
<jelmer> antoranz: igc may also be able to help you further, I'm not very familiar with it
<BasicOSX> lp speed today is making me cry
<BasicOSX> Just posted to the mailing list as well, lifeless  are you awake? Looking for the 1.14 branch Ian claims is available for me :-)
<BasicOSX> I see vila's 1.14 branch but that is it
<antoranz> the import did recreate the branches
<jrwren> I have a bound branch. is there a way I can tell what rev my branch is on?  bzr log -r -1 . is telling me latest rev of the branch to which I am bound, not my branch.
<beuno> jrwren, bzr revno
<jrwren> is that new?
 * fullermd stabbies bound branches.
<jrwren> I like my bound branch workflow :)
<jrwren> sorry.
<beuno> jrwren, no, it's as old as I can remember  :)
<jrwren> i fail for not finding it sooner.
<fullermd> If revno is telling you the revno of your local branch rather than the branch you're 'bound' to, I'd call it a bug.
<jrwren> no, revno is fine.
<jrwren> log -r -1 is showing me the bound rather than local.
<fullermd> That's what it should do.  Sorta.
<jrwren> I'd think revno should (and does) show me local rev.
<fullermd> Unless we had bound branches, which we don't.  Quite.
<fullermd> We have checkouts.  Almost.
<jrwren> basically, i'm just trying to detect when a branch is out of date.
<jrwren> while : ; do myrev=...; serverrev=... ; if [[ $myrev -lt $serverrev ]]...
<fullermd> Why not missing :bound?
<Peng_> I forget, does bzr use "Fix Committed" or "Fix Released" when a bug fix gets merged to bzr.dev?
<beuno> Peng_, my instict says "committed", so probably "released"
<beuno> I remember bzr does it the opposite of everything else
<beuno> so, if IIRC, fix committed == it's committed "somewhere"
<beuno> fix released == in trunk
<beuno> but maybe jam or abentley can confirm
<abentley> beuno: confirmed
<Peng_> Thanks.
<meoblast001> hi
<meoblast001> i just had someone commit source into his launchpad account... i'd like to merge it into my project... how do i do that?
<beuno> meoblast001, bzr merge LOCATION
<meoblast001> ok thanks
<meoblast001> how would i know where he's putting it
<Peng_> meoblast001: https://code.launchpad.net/~him
<Peng_> meoblast001: Then find the branch.
<Peng_> meoblast001: The page gives an lp:~him/project/branch URL for the branch; bzre that.
<meoblast001> ok
<meoblast001> thanks
<Peng_> ERrr.
<meoblast001> and that will just import his code in with mine?
<Peng_> "bzr merge that"
<Peng_> meoblast001: Yes. (Don't forget to commit.)
<meoblast001> yeah
<meoblast001> bzr merge lp:blahblahblah && bzr ci && bzr push....
<Peng_> Yep.
<meoblast001> except i won't use the && just incase of an error
<Peng_> :)
<meoblast001> Peng_: this just pulls his code and throws it into mine right? it doesn't copy his commits too
<meoblast001> oh no.... i'm so lost
<Peng_> meoblast001: By default, yes, it copies the commits too.
<meoblast001> Peng_: i think he had an outdated version
 * meoblast001 is having a panic attack
<Peng_> Outdated version of what?
<meoblast001> Peng_: he had revision 10 when i have 15 revisions
<meoblast001> i don't think i'm liking this merging stuff
<meoblast001> >>>>>>> MERGE-SOURCE is going to cause compiler errors
<Peng_> meoblast001: There were conflicts. Get out your text editor and fix them.
<Peng_> Or fancy diff/merge software or whatever.
<meoblast001> Peng_: i don't even think i want the guys changes anymore... it's not well commented
<meoblast001> i don't understand any of it
<Peng_> meoblast001: Well, you could "bzr revert" to throw it all out.
<meoblast001> yeah
<Peng_> meoblast001: You could also tell him to merge your branch and fix all of the conflicts so it'll be less work for you.
<meoblast001> Peng_: so now am i not allowed to edit my source until he fixes his code?
<Peng_> meoblast001: What? Why?
<meoblast001> i just found out he did merge my branch
<meoblast001> Peng_: if i change my code, wont his overwrite my changes?
<meoblast001> idk... i've never merged before
<Peng_> meoblast001: The point of merging is so that both side's changes will be preserved.
<meoblast001> oh
<Peng_> meoblast001: Of course, if you both modify the same code, the computer won't be able to figure it out, it'll result in conflicts and one of you will have to fix them manually.
<Peng_> s/same code/same lines of code/
<meoblast001> yeah
 * Peng_ goes /away
#bzr 2009-04-04
<luke-jr> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<luke-jr> How can I resolve this?
<jelmer> luke-jr: well, you can't really resolve that but you can force bzr to merge anyway by using "bzr merge -r0..-1"
<luke-jr> jelmer: will that copy the metadata?
<luke-jr> jelmer: my target branch is empty
<luke-jr> a simple Svn repo with a single commit creating trunk, branches, and tags
<jelmer> luke-jr: if your target branch is empty, why would you merge rather than pull?
<luke-jr> pull doesn't work either
<luke-jr> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<jelmer> luke-jr: what do you have locally?
<luke-jr> everything âº
<jelmer> luke-jr: I mean, what repository format?
<luke-jr> origin is CVS and Subversion
<luke-jr> I uses the cvsps thing to turn CVS into Bazaar
<luke-jr> now I need to put the Subversion revisions on top of that
<jelmer> luke-jr: that's not likely to going to work as the file ids will be different
<luke-jr> I can delete the Subversion repository once complete. I think.
<jelmer> so merging will result in a lot of conflicts as bzr thinks there are two different files with the same name
<luke-jr> well, that's why I'm going from Bazaar to Subversion first
<luke-jr> so Bazaar can set up its revprops
<luke-jr> and then loading the svndump should just commit the Svn repo's changes to existing files
<jelmer> luke-jr: so, creating an empty "trunk" directory in svn is the first commit in that branch
<jelmer> and that branch obviously doesn't share any history with the bzr branch you're trying to merge
<luke-jr> the only commit in the new dummy Subversion repository
<luke-jr> I'm trying to take the bzr branch's history to Subversion
<jelmer> luke-jr: what you *can* do is push the entire branch from bazaar into svn
<luke-jr> exactly
<jelmer> luke-jr: but to be able to do that /trunk shouldn't exist yet
<luke-jr> what is it going to push into? O.
<jelmer> luke-jr: and you can then run 'bzr svn-push <repo-url>/trunk' from the bzr branch
<jelmer> that will create the svn branch and push all contents
<luke-jr> will it create branches and tags too?
<luke-jr> the dirs
<jelmer> luke-jr: it will create those if it needs them but they can exist
<luke-jr> jelmer: btw, will I have trouble when I need to merge upstream CVS commits?
<jelmer> luke-jr: no, you'll be able to keep merging from the branch imported with cvsps
<luke-jr> jelmer: is it possible to backdate commits?
<luke-jr> (I'm turning patches into branches)
<jelmer> luke-jr: It's theoretically possible, but I don't think bzr allows anything like that on the command-line
<jelmer> s/theoretically/technically/
<luke-jr> any other metadata I might want to manipulate?
<jelmer> --author perhaps
<luke-jr> ok
<luke-jr> --author plus libfaketime ;)
<luke-jr> timestamp: Sun 194065-07-12 23:15:44 -0500
<luke-jr> that didn't work :o
<jelmer> whoa :-)
<luke-jr> oh well
<luke-jr> I'll just declare it the commit time instead of change time
<luke-jr> :/
<vinc456> i'm a little confused about the docs. says "* Talk to us in irc://irc.ubuntu.com/bzr"
<vinc456> i tried to connect and it seemed to lead to here
<luke-jr> vinc456: what's to be confused about?
<luke-jr> this is #bzr
<vinc456> isn't this freenode?
<vinc456> is this the "official" channel?
<jelmer> vinc456: irc.ubuntu.com points at freenode
<jelmer> vinc456: yep, this is the official channel
<vinc456> weird
<ezyang> Hello all, I'd like to check out all of the branches of a repos that I checkout one branch of. Is there an easy way of doing this?
<ivan> I pulled someone's trunk into my no-working-copy branch
<ivan> bzr said a lot of things conflict because it expected files to be there
<ivan> how do I escape from this mess? :)
<jelmer> ivan: bzr won't create conflicts if there is no working tree
<jelmer> ivan: can you expand a bit as to what's happening?
<ivan> http://rafb.net/p/mGvDyg47.html
<ivan> I think what might be the problem is that I manually removed the working trees
<jelmer> ah, not using 'bzr remove-tree' ?
<ivan> I touched a file somewhere to convince bzr not to create working copies any more
<ivan> but perhaps that was not enough to switch to no-trees
<ivan> jelmer: yeah :(
<jelmer> ivan: you can just remove those files manually again (everything except .bzr) and then run 'bzr remove-tree'
<luke-jr> I can't find version 1 of a patch
<luke-jr> can I commit version 2 and edit the history later? ;)
<ivan> jelmer: thanks, my branches are back to normal
<ivan> took me a few minutes to figure out that I should be doing merge ../trunk instead of merge trunk, though
<Peng_> bzrtools's clean-tree command makes it easier to delete all of hte unnecessary files.
<Peng_> (See the help, though.)
<ivan> i'm trying to figure out how to recreate the tree so that I can remove-tree
<ivan> I have uncommitted changes involving all the files being gone
<ivan> this is just a problem in the branch, not in the checkouts
<jelmer> ivan: try 'bzr revert'
<ivan> jelmer: thanks again, life is good now
<meoblast001> how do you delete a bazaar branch
<Peng_> meoblast001: rm -rf
<backz> hi
<Peng_> meoblast001: If you're using a shared repo, it's not trivial to remove the now-unnecessary revisions from it. Most of us just live with the couple MB of wasted disk space.
<Peng_> It probably wouldn't be hard to write a "gc" plugin though.
<meoblast001> how do i remove a branch from a proejct
<Peng_> backz: Hello
<Peng_> meoblast001: Eh? On Launchpad?
<backz> I'm using bzr for a private project, I need to share this repo with team, need I pay some host service with shell in order to give write-access to this repo to all my team remotely?
<meoblast001> Peng_: yues
<Peng_> meoblast001: There's a little X button next to the branch's title on its web page.
<Peng_> backz: All you really need is SFTP (or, god forbid, FTP).
<meoblast001> https://code.launchpad.net/amethyst-mm where?
<Peng_> meoblast001: Click on the branch.
<meoblast001> k
<backz> I've looking for services like github, but it's only for git. Lauchpad is only for open source apps.
<Peng_> I don't know of any. :\
<backz> is bzr slow to transfer data by sftp ?
<backz> in the first edition, it was.
<Peng_> backz: Well, it's certainly not as fast as the smart server, especially after all the recent work on improving the smart server's performance.
<meoblast001> Peng_: i'm lost
<meoblast001> i don't see an x https://code.launchpad.net/~tedks/amethyst-mm/devel
<Peng_> meoblast001: You own that branch?
<meoblast001> no
<meoblast001> it just got randomly sorted in with my project
<Peng_> meoblast001: Well you can't delete other peoples' stuff.
<meoblast001> i don't know why
<meoblast001> i don't want ot
<meoblast001> i dont want it in my project
<Peng_> meoblast001: It looks like it's related to your project.
<meoblast001> oh
<BasicOSX> The server at bugs.launchpad.net is taking too long to respond. <- just me or others have problems?
<Peng_> Umm, if Firefox wasn't swapping, I'd check.
<Peng_> BasicOSX: https://bugs.edge.launchpad.net/ works for me
<Peng_> Sigh, I think I've given up on "WFM" :(
<wgrant> backz: You can use Launchpad for proprietary projects, but you have to pay.
<olliepetch_> hey guy's i'm just exploring the bzr code base and am trying to find where a file is distinguished between text or binary before a delta is written to repository, can anybody let me know where this code lye's? cheers
<olliepetch_> hey guy's i'm just exploring the bzr code base and am trying to find where a file is distinguished between text or binary before a delta is written to repository, can anybody let me know where this code lye's? cheers
<Peng_> Deltas are binary, although the current formats are all line-based.
<Peng_> So...it doesn't.
<LarstiQ> olliepetch_: I suppose you want to accomplish something with this information?
<olliepetch_> yeah i want to add an extra check to see if it is a odf file, so i can open up the archive and store difference data on the content.xml file
<LarstiQ> olliepetch_: hmm, I'd probably start by looking at the different merge types in bzrlib.merge
<backz> hi
<Peng_> Hi
<yacoob> If I have a shared repo, with one branch in it, would branching it outside, and then pushing to a "new" branch in the same repo result in shared storage use?
<yacoob> or do I need to go to the repository and do 'bzr branch old new' there?
<james_w> it would
<james_w> the second option only requires one branch operation though
<LarstiQ> but the results inside the repo would be the same for options 1 and 2
<yacoob> great, that's what I expected, but I wasn't sure :)
<yacoob> so, how is it done under the hood? I mean, do the branches have uuids and upon new push bzr recognizes that the new one was branched from the old one? Or does it analyse the files and spots similarities?
<LarstiQ> yacoob: every commit has it's own unique revision id. A branch is just a pointer to a revision.
<LarstiQ> yacoob: so if you just `bzr branch old new`, all the revision objects will already be in the repo, 'new' is just an additional pointer.
<yacoob> LarstiQ, what I'm wondering about is, if I'm pushing *some* branch X to a shared repo - will it share storage only if it has been branched from something already in the repo, or will it work as long as the files in the branches have "similar" content?
<LarstiQ> yacoob: it will need to share revisions, files having similar content will not do it.
<Peng_> (
<Peng_> (Although they might in a future disk format.)
<Peng_> Err. Did that make sense?
<LarstiQ> yacoob: you can use `bzr missing` to see which revisions will take up additional storage space.
<LarstiQ> well, roughly
<LarstiQ> s/see/get an idea of/
 * Peng_ goes to bed. Maybe.
<yacoob> neat, thanks
<nekohayo> let's say I want to revert a change that was made in a previously merged revision, what would be the best way to go about it?
<nekohayo> let's say I'm at rev 119 and I want to revert what was done in rev 98.3.36
<LarstiQ> nekohayo: you can commit the reverse diff: `bzr merge -r 98.3.36..98.3.35 .; bzr ci`
<nekohayo> o_o and that won't mess up history or anything6
<nekohayo> so basically, "bzr merge -r 98.3.36..98.3.35 ." and then "bzr commit". Interesting
<LarstiQ> nekohayo: that will leave the old 98.3.36 intact.
<LarstiQ> nekohayo: if you needed to remove that revision, you could bzr uncommit (and then a rebase invocation to keep the content of the newer revisions)
<nekohayo> nah, I guess just reverting the actual code is enough
<nekohayo> it's not seen as a "merge" by bzr status though
<nekohayo> I guess it's just as if I did the diff manually and committed a new revision
 * LarstiQ nods
<nekohayo> about cherry picking, I'm still a bit confused. What happens to history if I cherry pick something from another branch? And more importantly, does using cherry-picking imply that once you use it, you must keep using it for all further merges from that branch?
<nekohayo> that's basically what makes me hesitant to use it
<LarstiQ> nekohayo: to start at the end. No, you don't need to keep using cherry-picking.
<LarstiQ> nekohayo: the first question, nothing happens to history.
<nekohayo> (actually it was pretty much the same question, now that I think of it ;)
<LarstiQ> nekohayo: A cherry pick in Bazaar does not currently record any metadata, only content changes.
<nekohayo> LarstiQ: example: I merge from "bob" who has revisions 1,2,3,4, and I cherry-pick 2-3. But then if it doesn't merge the metadata, what will happen when I do a simple "bzr merge bob" afterwards? that's what was puzzling me
<nekohayo> won't it pull in revs 1,2,3,4 all at once?
<nekohayo> merge*
<LarstiQ> nekohayo: yes, but Bazaar will not conflict on the content of 2,3 already being present
<nekohayo> oh, that's nice :) I guess it's just a social question rather than a technical one then
<nekohayo> as in if you disagree with someone's branch or something, you have to keep cherry-picking it ;)
<LarstiQ> nekohayo: If there is just one thing you disagree with, merging everything and applying the reverse diff works as a 'reject'.
<LarstiQ> nekohayo: in general we tend to encourage doing orthogonal work in seperate branches
<nekohayo> LarstiQ: ok, but that needs to be done in separate commits, afaik. Actually, I'm not in need of things like this so far, I was just doing an exercise in thought :) is there such a thing as a bazaar/dvcs etiquette in the docs?
<LarstiQ> nekohayo: maybe, I'm not aware of it. It's a good idea though.
<nekohayo> I think it would be a neat thing for switchers from centralized models, or even for people starting from zero into the VCS world
 * LarstiQ nods
<nekohayo> LarstiQ: I obviously don't have the knowledge for this, but should I file a bug about bzr's docs or something?
<LarstiQ> nekohayo: if you can't find such a thing on the wiki or on doc.bazaar-vcs.org, go ahead
<LarstiQ> nekohayo: or perhaps start a page on the wiki
<LarstiQ> nekohayo: http://bazaar-vcs.org/Scenarios might come close
<nekohayo> indeed, "Review and accept changes from others, into a project that I manage using bzr" ; however, that page doesn't exist :)
<LarstiQ> nekohayo: create it, note down how you think it should be done, and someone will correct it if needed! ;)
<nekohayo> that's the problem, I don't really have much of an idea how it should be done :)
<LarstiQ> nekohayo: I have some ideas for that
<nekohayo> hm. maybe you could start that etiquette/good management practices page and I could watch it and comment
 * nekohayo has a weird feeling that this is also the kind of things that usually gets demonstrated in live talks
<LarstiQ> it is
<nekohayo> afaik there are no recordings of those talks on the website :)
<LarstiQ> nekohayo: I've put it on my todo list, I won't be doing it for a while today
<nekohayo> should I point specto to a particular page to watch out for?
<LarstiQ> nekohayo: the Scenarios page
<nekohayo> allright
<luke-jr> I'm trying to create a branch with its first revision being a merge of another existing branch
<luke-jr> eg, start the numbering over at 1
<luke-jr> yet, if I do bzr init foo; cd foo; bzr merge ../bar
<luke-jr> bzr status says I am not "up to date" and bzr update deletes all the merged files; bzr commit then creates a revision with delete for all of them
<luke-jr> what am I doing wrong? :/
<jkakar> luke-jr: I don't think you want to do a merge.  This is basically just a fresh branch with a bunch of new files added... ie: you explicitly don't care about the history of those files.
<luke-jr> jkakar: I *do* want the history
<luke-jr> just as 0.1.*
<luke-jr> I also want to retain the ability to merge from other branches
<jkakar> luke-jr: Hmm.  Why do you care about the revision number starting at 1?
<luke-jr> jkakar: I'm importing âº
<jkakar> luke-jr: Uhm, I don't understand what that means.
<luke-jr> and I'd prefer my trunk branch not be renumbered
<luke-jr> I'm moving my Subversion repository
<jkakar> Ah ha.
<luke-jr> rev 1 is my initial import
<luke-jr> I want to keep it the same in Bzr
<jkakar> I'm not sure how you would do that, sorry.
<luke-jr> sigh
<luke-jr> if it was rev 2, it'd be easy
<luke-jr> oh
<luke-jr> stupid me
<jkakar> If the SVN repository is public, I would probably just arrange Launchpad to do a vcs-import for me and let it all happen magically.  I don't think it'll do what you want withj revno's though.
<luke-jr> svn and bzr revno are going to differ no matter how I do it
<luke-jr> jkakar: not that simple âº
<luke-jr> I don't think Launchpad's VCS import is designed for branches spanning CVS and Subversion both
<jkakar> luke-jr: Launchpad can import from CVS and Subversion.
<luke-jr> jkakar: whilst keeping merges between the two consistent?
<jkakar> luke-jr: You probably need to use bzr-svn if you want to do that.
<luke-jr> that only works with Svn
<luke-jr> not CVS
<jkakar> Ah, I see.
<vinc456> luke-jr: how do you type a smiley face?
<luke-jr> I press ':'
<luke-jr> then ')'
<luke-jr> âº
<vinc456> luke-jr: hmmm, maybe your client transforms it because when i message myself i just see a colon and right parenthesis
<NfNitLoop> yeah, his client is sending some unicode character.
<ricardokirkner> hi. I am tracking an svn bzr using bzr-svn.. I keep getting bzr prompting me for the password, although this is supposed to be already handled. I am trying to trace the auth code, but its never being called. Maybe its something to do with that my branch starts with https:// instead of svn+https:// ?
<luke-jr> bzr: ERROR: Prefix missing for branches/randomRange; please create it before pushing.
<luke-jr> wtf? :/
<bob2> bzr push --create-prefix
<bob2> it doesn't create more than one level of directory, by default
<ricardokirkner> hey jelmer. how are you doing?
<ricardokirkner> I just wanted to know if some behaviour I am seeing is alright or is a bug: when I have an svn branch directly using the https:// transport, it doesn't use the svn credentials; however if I use the svn+https:// transport it does, but it says the svn+ is deprectaed and I should use the https directly
<ricardokirkner> I would like to fix this issue (if it is a bug indeed), but I would like some guidance, as to not loose myself within the code :-)
<LarstiQ> sounds like a bug to me
<ricardokirkner> I guess I would have to modify the bzrlib/transport/http/<somefile>
<ricardokirkner> to determine if the underlying repo is svn or not and in the former case, request the svn credentials
<ricardokirkner> am I right?
<LarstiQ> ricardokirkner: no, that doesn't sound right
<ricardokirkner> LarstiQ, what do you suggest?
<LarstiQ> ricardokirkner: bzr-svn does interact with the http:// url, right?
<ricardokirkner> supposedly, yes
<ricardokirkner> I mean, it is working alright, except for the credentials stuff
<ricardokirkner> it is as if the http transport is being handled by another handler that is not svn aware
<ricardokirkner> which make complete sense
<ricardokirkner> as the http protocol might be used for bzr repos too
<LarstiQ> transports and credentials aren't tied directly to each other
 * LarstiQ looks at the bzr-svn code
<LarstiQ> ricardokirkner: svn/auth.py is where I'd look
<ricardokirkner> yes, I have already looked in there
<ricardokirkner> the thing is, the auth.py stuff is not being called for credentials
<ricardokirkner> I have set some breakpoints in there, but the pdb never halts on them
<LarstiQ> ricardokirkner: but it does for https?
<ricardokirkner> no
<LarstiQ> how have you set breakpoints, and where?
<ricardokirkner> what I meant before is: the svn repo handling is working alright, but the http/https credentials stuff are being handled by another handler
<ricardokirkner> I am running "pdb /usr/bin/bzr pull"
<ricardokirkner> when it starts I set a breakpoint on the code I want to analyze
<ricardokirkner> e.g. auth.py
<LarstiQ> hmm, that might work
<ricardokirkner> and let it continue
 * LarstiQ usually does 'import pdb; pdb.set_trace()' in the code directly
<ricardokirkner> so I have seen that the auth.py code that handles credentials is not being called
<ricardokirkner> yes its the same
<LarstiQ> ricardokirkner: specifically SubversionCredentialStore.decode_password?
<ricardokirkner> specifically create_auth_baton
<ricardokirkner> and from there downwards
<LarstiQ> ricardokirkner: for debugging, I'd next look at get_credentials in bzrlib/config.py
<ricardokirkner> alright
<ricardokirkner> what I just saw is that if I dont specify the credentials in the url, it fails; if I do, the default http credentials stuff is being called
<ricardokirkner> I will look at the config stuff now
<LarstiQ> ricardokirkner: I'm not convinced create_auth_baton is meant to be called even
<LarstiQ> ricardokirkner: is the regular credentials stuff also called if you provide a username, but no password?
<ricardokirkner> LarstiQ, exactly, if I provide the username as part of the url, the http credentials handler is called
<ricardokirkner> and prompts for a password
<ricardokirkner> after I enter the password everything works fine
<LarstiQ> ricardokirkner: hmkay
<james_w> I seem to remember something about putting something in authentication.conf to allow bzr-svn to provide the credentials
<ricardokirkner> another possibilty is that the SvnRaTransport is not being added to the list of possible_transports
<LarstiQ> ricardokirkner: this area certainly has bugs that need squashing
<LarstiQ> ricardokirkner: right
<ricardokirkner> so, once it fails trying with the default handler, it exits
<ricardokirkner> I am not sure thought if the SvnRaTransport should be added to the list of possible_transports for the http/https protocol (althought it doesn't seem so far-fetched)
<ricardokirkner> LarstiQ, ok, I found a possible solution (pretty easy and straightforward too). I am not entirely sure if it is completely correct, and would like feedback on it
<ricardokirkner> I basically registered SvnRaTransport as lazy transport for the http and https protocols, in the __init__.py file of the svn plugin
<ricardokirkner> and it works (with the minimal testing I did so far)
<ricardokirkner> if this is alright.. what steps should I do to include this fix into bzr-svn?
<ricardokirkner> (btw, another solution that works, is to add the repo to the authentication.conf file :-))
<LarstiQ> ricardokirkner: with password_encoding=subversion?
<ricardokirkner> ???
<LarstiQ> I guess not :)
<LarstiQ> ricardokirkner: how do you add it to authentication.conf?
<ricardokirkner> no, in the authentication.conf file I just specified username, password
<LarstiQ> ah, well, yes :)
<ricardokirkner> and host
<ricardokirkner> but the other approach (registering the transports in __init__.py) seems better (less intrusive on the user)
<ricardokirkner> what do you think?
<LarstiQ> ricardokirkner: I don't know the code well enough to judge if that is a correct thing to do.
<LarstiQ> ricardokirkner: one issue for example is not loading the svn plugin until it is really needed
<ricardokirkner> alright... what's the usual approach here? should I branch the bzr-svn code, fix the code in my branch, submit a bug request, and submit a possible solution pointing to my branch for review?
<LarstiQ> ricardokirkner: yes
<ricardokirkner> ok
<ricardokirkner> will do that now
<ricardokirkner> thanks a lot for the 'mentoring' :-)
<LarstiQ> no problem :)
<LarstiQ> ricardokirkner: for the last part, linking the branch to the bug is what I'd do
<ricardokirkner> ok
<james_w> I think password_encoding is the way it is supposed to be enabled
<LarstiQ> james_w: is that a choice not to use credential stores unless explicitly told to?
<james_w> I believe so, but a debated one
<LarstiQ> yeah, I believe the out of the box experience for svn at least should be better
<ricardokirkner> james_w, yes, I agree with LarstiQ
<ricardokirkner> I am almost new to the bzr codebase
<ricardokirkner> but I have seen there is the possibility to register several transports for a protocol
<ricardokirkner> the problem is that when the first transport fails, the next ones are not tried out
<ricardokirkner> maybe if we allow to iterate over all transports, until we reach one that succeeds, it would be just a matter of registering several transports for http/https
<ricardokirkner> (e.g. register the svn transport if it exists as the first one, and fall back to the default transport for http if the svn one fails)
<ricardokirkner> james_w, btw, if you could point me to the thread where this was discussed, it would be really helpful
<ricardokirkner> as, currently, one of the greatest benefits of git for me right now, is that it supports svn out of the box; I wish I could have that issue less in my comparison between bzr and git , as I would really like to continue using bzr as my default vcs
<james_w> I only remember the discussion about whether the methods should have to be declared from IRC, sorry
<james_w> if you post to the list or file a bug then it would probably revive the discussion
<ricardokirkner> james_w, alright.
<ivan> if you want to make a small fix to all of your very different branches, what's the right thing to do?
<ivan> make it in one and cherry-pick it to everywhere?
#bzr 2009-04-05
<luke-jr> bzr diff ../server/e/HEAD/ -c 64 | patch -p0
<luke-jr> why does that work, yet bzr merge is too stupid to handle it? :/
<luke-jr> fuzz 2?
<RAOF> luke-jr: Answering that would requrire the message bzr gives as the reason it can't merge.
<luke-jr> it just does conflicts galore
<luke-jr> I'm merging lp:moo/lambdamoo-1.8 updates into lp:~luke-jr/moo/db_options
<RAOF> Hm.  Not really sure.
<lifeless> luke-jr: does it detect a criss-cross merge?
<luke-jr> lifeless: there is no criss-cross, no
<luke-jr> db_options has and never will be merged into lambdamoo
<lifeless> luke-jr: its odd that it is conflicting
<lifeless> what type of conflicts is it giving?
<luke-jr> the MERGE-SOURCE side is trying to add about 500 lines of code that was removed in the branch
<lifeless> you could try --weave
<luke-jr> haha. no.
<luke-jr> weave is evil
<lifeless> so you're merging trunk into a branch that hasn't been merged into trunk ever, and its reinstating code that was deleted in the branch ?
<luke-jr> correct
<luke-jr> trunk is a CVS import, if that is at all relevant
<luke-jr> branch was created from a tag in the bzr import
<luke-jr> I need to manipulate file-ids. Any advice?
<lifeless> why do you need to do that?
<luke-jr> telling Bazaar about a rename
<lifeless> I think you're getting the conflict because the code that was deleted in the branch was altered in the trunk. Is that potentially accurate?
<luke-jr> long after the fact
<lifeless> bzr mv --after
<luke-jr> it wasn't
<luke-jr> lifeless: long after, meaning the commit is 50 revisions ago
<lifeless> re the conflicts - in which case please file a bug
<lifeless> luke-jr: bzr rm foo --keep; bzr add --file-ids-from [place that has the file] foo
<lifeless> luke-jr: also --weave isn't evil, its good - mysql use it all the time to get massively less conflicts
<luke-jr> hmm
<luke-jr> --weave reduces conflicts, sure, but often it duplicates code
<lifeless> does it? I haven't seen that. That would be a bug IMO
<luke-jr> O.o
<lifeless> basically, feel free to file bugs on merge logic
<lifeless> some will be things we can't easily fix without throwing other things out
<lifeless> but there is lots of room to improve
<luke-jr> the problem-causing merges seem to trigger patch to say "with fuzz 2"
<luke-jr> I can only presume that's related
<BasicOSX> getting only 8kB from LP everything else fast
<luke-jr> lifeless: any way I can ensure I'm not about to totally screw up my branch? XD
<luke-jr> bzr status is giving me some funky output ;/
<luke-jr> added: db_objects.c
<luke-jr> renamed: db_objects.c => db_save_objects.c
<luke-jr> modified: db_save_objects.c
<luke-jr> does that make sense? :/
<lifeless> sure
<lifeless> it says that db_objects was modified and renamed
<lifeless> and that you have added a new fiel db_objects.c
<luke-jr> ok
<luke-jr> sigh
<luke-jr> trying to tie these merge trees together is a pain
<chx> how do i get my working tree into where it was before 9841 was committed?
<LeoNerd> bzr revert -r9840
<chx> oh
<LeoNerd> Or.. more accurately, something like   bzr revert -rparent:9841   but that probably comes down to 9840 anyway
<chx> i thought revert was only for reverting changes since last commit.
<chx> my bad.
<LeoNerd> revert puts it back to the state at some commit.. by default the most recent... but -r can pick a different one
<luke-jr> what does -rparent do for merges? :p
<Peng_> Hmm, it's "before:", and the help doesn't say.
<vinc456> can i reload my bzr.conf file?
<vinc456> i've made an edit but the changes don't seem to take effect
<Peng_> bzr.conf?
<vinc456> sorry branch.conf
<Peng_> The changes don't take effect...where? There's nothing to reload
<vinc456> well i defined the alias from the tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<vinc456> but if i try something like 'bzr ll' i get an unknown command error
<vinc456> i thought i might have to run some sort of source command, the way i do when i edit .bashrc or something
<Peng_> vinc456: Maybe you have to set that in ~/.bazaar/bazaar.conf.
<vinc456> Peng_: i set ~/.bzr/branch/branch.conf
<vinc456> anyways it's not a big deal
<vinc456> it'll probably work fine once the next time i reboot
<Peng_> vinc456: Um, no it won't.
<Peng_> vinc456: ~/.bazaar/bazaar.conf.
<vinc456> Peng_: ah ok, i was confused
<vinc456> thanks
<seb_kuzminsky> does cherrypicking lose merge tracking?
<seb_kuzminsky> i do "bzr merge -c $MY_FAVE_REVNO && bzr merge -c $OTHER_REVNO && bzr commit", and then "bzr log" shows just the final commit, not three new commits (a merge of two previous commits)
<seb_kuzminsky> that's on bzr 1.11
<Peng_> seb_kuzminsky: That's correct. Which is why we try to avoid cherrypicking. :D
<seb_kuzminsky> ok thanks Peng
<Peng_> Sorry. :\
<BasicOSX> make check-dist-tarball failing on 1.14rc1 release. Anyone able to look at bug 355454 ?
<ubottu> Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [Undecided,New] https://launchpad.net/bugs/355454
<Peng_> I don't think Unicode issues like that are new.
<BasicOSX> wasn't an issue 1.13
<Peng_> Oh. Never mind then. :D
<BasicOSX> interesting bzr selftest passes
<Peng_> make check tests with multiple LANG values.
<Peng_> So it's more likely to expose Unicode bugs than just selftest.
<BasicOSX> Ahh, how it make through PQM? I thought the multiple LANG stuff got put into PQM?
 * Peng_ shrugs
<BasicOSX> less shrugs, more answer! :-P
<Peng_> make check runs with your normal locale and the standard C locale. I'm not sure what PQM does.
<Peng_> Maybe your specific locale exposes some bug that PQM's setup doesn't.
<Peng_> That's about all the answer I have.
<glyph> I've got a branch that I want to push to a public location.  Unfortunately most of the commits were made before I understand how 'bzr whoami' worked, so they are from "Glyph Lefkowitz <glyph@some-random-host-I-use>" rather than "Glyph Lefkowitz <glyph@twistedmatrix.com>"
<glyph> Is there a way I can fix up that history?
<Peng_> Pretty much no.
<glyph> Peng_: Hmm... I guess I should rebase from zero then?
<luke-jr> I used cvsps-import to do the initial migration of a CVS upstream to Bzr; how do I get syncs from CVS in?
<spiv> glyph: editing a fast-import dump might be relatively painless, if you really care.  (does it really matter?)
<glyph> spiv: I don't know.  Does it?  I was under the impression that email address was sort of the primary key for identifying committers.
<jkakar> glyph: I trust GPG signed commits as a verification method much more than an email address.
<glyph> jkakar: These commits weren't signed either :)
<glyph> jkakar: Can I go back and sign them?
<bob2> bzr sign-my-commits
<glyph> bob2: Huh
<glyph> and then if I push somewhere, signatures for old revisions will be published?
<bob2> dunno
<bob2> also not sure what it'll do wrt your whoami having changed - you might need to temporarily change that back
<glyph> bob2: It looks like I can pass a committer on the commandline
<lifeless> glyph: no, old revision signatures are not automatically propogated, because thos revisions are not being examined. The library can do it; I guess we should add a flag to push/pull ; I think there is a bug already open
<lifeless> glyph: and possibly a hidden command
<glyph> I guess for now I will not worry about this
<jkakar> glyph: I have this in my ~/.bazaar/locations.conf, which causes all my commits to be GPG signed: http://paste.ubuntu.com/144726/
<glyph> jkakar: I'll be adding something like that soon, as soon as I figure out how seahorse-agent works
<glyph> (I don't like having gpg private keys on my hard drive)
<jkakar> Yeah, that's probably a good call.
<jkakar> I was doing the SSH+GPG key on a USB stick thing for a while...
<glyph> jkakar: You stopped?
<pygi> ok, folks, got a tiny problem with push
<jkakar> but then I noticed how much easier it was to steal radix's keys (with USB key attached) at sprints, compared to his whole computer, and decided it might not be so bulletproof.
<pygi> http://slexy.org/view/s21qWJI3Rj
<jkakar> Though, I guess most of the time my hard drive is potentially more accessible to evil hackers than a USB key in my house, where I spend most of my computing time.
<jkakar> glyph: So yeah, I stopped.
<jkakar> I'm probably not paranoid enough, oh well.  Ignorance really is bliss. ;)
<kizzo> How would I go about undoing a "bzr add"?
<kizzo> : )
<kizzo> [ removing all of the files that were added b/c of that command.. ]
<jkakar> kizzo: rm `bzr added`
<lifeless> kizzo: or 'bzr revert' the added files
<kizzo> jkakar: That looks like it would actually delete the files from my disk, huh?
<kizzo> The first one.
<jkakar> kizzo: It will, yes.
<kizzo> Oh ok, so revert is probably what I would like to happen then.
<kizzo> Cool.
<kizzo> Thanks.
<pygi> :-/
<lifeless> py	whats wrong?
<lifeless> pygi: ^
<pygi> lifeless, If I knew that'd be good :p
<pygi> probably something with the server :P
<pygi> lifeless, http://slexy.org/view/s21qWJI3Rj
<lifeless> oh, I can't browse right now
<pygi> :P
<pygi> basically, I can't push :D
<lifeless> do you get an error?
<pygi> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'Operation not supported: open_write_stream')
<lifeless> that sounds like you have an _extremely_ old server
<lifeless> or hmm
<lifeless> perhaps its backed onto a readonly transport
<lifeless> the latter is more likely I think
 * pygi is pretty sure he configured rw privs
<pygi> it might be that security subsystem of this server is a bit wonky
<pygi> its still pretty fresh
<lifeless> are you pushing to bzr+ssh/bzr/bzr+http?
<pygi> bzr+http
<lifeless> what backing transport did you give it in your glue code?
<pygi> hmm
<pygi> how do you mean?
<lifeless> well to setup a bzr+http server you need some wsgi glue
<lifeless> and in that you tell it where the server backend is
<lifeless> what url did you use in there
<pygi> yup, moment :p
<pygi>     local_url = wsgi.local_path_to_url(root)  ?
<pygi> I mean, I can branch pretty fine, its probably something in the security code or something :-/
<lifeless> no
<pygi> (not of bzr security code, but of that wsgi glue/security glue code that you say :)
<lifeless> did you follow the howto ?
<lifeless> doc/en/user-guide/http_smart_server.txt
<pygi> actually, no, purely because I use a custom-written server (clue-bzrsever)
<lifeless> ok
<lifeless> well
<lifeless> cross reference the howto
<lifeless> if when you start the backend server you are passing in an http transport its fundamentally wrong
<lifeless>     from bzrlib.transport.http import wsgi
<lifeless>     smart_server_app = wsgi.make_app(
<lifeless>         root='/srv/example.com/www/code',
<lifeless>         prefix='/code/',
<lifeless>         path_var='REQUEST_URI',
<lifeless>         readonly=True,
<lifeless>         load_plugins=True,
<lifeless>         enable_logging=True)
<lifeless> is the key bit
<lifeless> root needs to be your on disk path to the root you want to serve out
<lifeless> and you'll want readonly=False :)
<pygi> :)
<pygi> thanks, I'll see what I can do
<pygi> hm, ok, readonly IS false
<pygi> is this correct:    write = ['mkdir', 'put_file', 'delete', 'rename', 'rmdir', 'append_file', ]  ?
<lifeless> that looks like something to do with your custom server
<lifeless> its certainly not an accurate list of what bzr uses to push, if thats what you're asking
<pygi> can that be the problem?
<lifeless> I don't know, I'm guessing at things here
<lifeless> what does this custom server do?
<lifeless> how does it hook into bzr?
<pygi> using bzrlib
<lifeless> I mean, it could implement the protocol, or it might subclass the request dispatcher, or handler lookup, or decorate the backing transport, or something else again
<lifeless> I have no idea about it, today is the first time I heard of it
<lifeless> and without knowing a fair bit more I can't offer good advice :(
<pygi> let me check
<lifeless> I will note that the open_write_stream method is one on transport that isn't exposed in the smart server API, so its possibly decorating the backing transport
<lifeless> in which case giving it a more complete list would be a good idea:)
<pygi> could you point me to location where I can find more complete list? :)
<lifeless> pydoc bzrlib.transport.Transport is the base class for all transports
<lifeless> it defines the public api
<lifeless> pygi: what does the custom server do for you?
<pygi> serves bzr directories (repos) and handles security
<pygi> it seems to define its own ACLTransport ...(or well, at least it has such a class :P)
<pygi> (bzr 1.13.1, if it makes any difference)
<lifeless> yes, they probably didn't implement the entire contract, only what they saw used
<lifeless> bzr 1.13 streams
<lifeless> which means the server will use the streaming transport apis
<pygi> hm, can that be the problem then? I mean I doubt this was written with 1.13 in mind...
<pygi> (and yes, I know I'm bugging, sorry :))
<lifeless> I assume so
 * pygi goes try with different bzr
<pygi> guess I'll just have to submit patches if that's the problem:)
<pygi> it seems to need 1.12...
 * pygi tries that
<pygi> lifeless, ok, different problem: bzr: ERROR: Server sent an unexpected error: ('error', 'Operation not supported: append_file')
<pygi> o.O
<lifeless> pygi: have you used this software before :) - [is it complete :P]
<pygi> lifeless, actually, this is the first time I'm testing it thoroughly :P
<pygi> but it is supposed to be complete :p
<pygi> don't worry about it, I'll look into the codebase :)
<pygi> thanks for all the help
<lifeless> np
<CBro2007> http://www.pastie.org/437377
<CBro2007> guys
<CBro2007> guys I was trying to understand this error. can someone help?
<CBro2007> http://www.pastie.org/437377
<CBro2007> Basically want to get rid of everything in the dir and get a fresh new copy from bzr repository
<CBro2007> can someone please help? :)
<bob2> bzr break-lock file:///home/dchoon/dcrepo/
<Peng_> CBro2007: Check for any bzr process that actually has been running for the last 98 hours. If there aren't any, use "bzr break-lock" -- bah, bob2 is quick.
<CBro2007> Peng_: Yeah I just ran the bzr break-lock
<CBro2007> it worked
<CBro2007> but then I did the "bzr pull --overwrite"
<CBro2007> and it still kept all the rest of the files in there
<Peng_> Uh-huh...?
<Peng_> What files?
<bob2> so you deleted some files
<bob2> and want them back?
<bob2> ala 'xvs update'?
<CBro2007> well basically this developer added new files etc... and his version doesn't work
<CBro2007> so I suggested overwriting all his local files
<bob2> that's not an awesome idea
<CBro2007> well basically want to revert back to what was working well...
<CBro2007> he has gone ahead and created all these files and ran commands that blurted out lots of stuff that isn't needed
<CBro2007> its easier for him to checkout the latest repo copy and start from there
<bob2> so, 'bzr revert' will revert to the last commited version
<CBro2007> yeah but it might still keep the new stuff?
<CBro2007> he has not ADDED his new files
<bob2> then delete them
<bob2> pull isn't going to delete random un-added files from the working tree
<bob2> bzr revert ; bzr clean-tree # revert and delete all unadded files
<CBro2007> says unknown command
<bob2> it's new
<CBro2007> clean-tree is an unkown command
<bob2> alternatively, 'bzr status' then manually delete the files
<CBro2007> got an older equivalent
<bob2> or branch from your repository again
<CBro2007> how bout add and then revert?
<CBro2007> would that not add all the new files in and then when you revert it gets rid of them all?
<LarstiQ> CBro2007: clean-tree used to be in bzrtools before it moved to bzr core
<CBro2007> ok
<LarstiQ> bzr ls --unknown | xargs rm
<LarstiQ> would also work
<bob2> as long as there are no spaces in your filenames
<LarstiQ> and no directories, but you get the idea
<CBro2007> thanks bob2
<CBro2007> thats all good now
<CBro2007> just a normal delete and then a revert
<Stavros> why does bzr insist on messing up my tree when all i want to do is push my local changes upstream?
<Stavros> it is interfering with the whole "distributed" paradigm
<Stavros> can i just push instead of updating on a bound branch?
<beuno> Stavros, yes, but you have to use branches instead of checkouts
<beuno> you can use --reconfigure to change a checkout into a branch
<Stavros> beuno: i have a checkout right now, and whenever i do a local commit and then try to update, it messes up my working tree
<LarstiQ> Stavros: eh?
<Stavros> i just want to push the changes, how can i do that?
<LarstiQ> Stavros: could you be more specific as to what happens?
<Stavros> LarstiQ: i have a bound branch
<Stavros> i commit with --local
<Stavros> then i update, and my local working directory gets messed up
<LarstiQ> please describe 'messed up' a bit more.
<james_w> LarstiQ: he doesn't want the merge implied by update
<Stavros> bzr thinks there are conflicts, but the revision on the remote repo is one earlier than the local one
<LarstiQ> Stavros: that is weird
<Stavros> so the remote has rev 60, the local rev 61, and it still merges
<james_w> Stavros: why are you doing update? why not just commit?
<Stavros> james_w: i did commit once
<Stavros> james_w: don't i have to update to push them?
<LarstiQ> Stavros: are they the same revision though?
<Stavros> LarstiQ: the local repo has one more revision
<james_w> Stavros: I don't think so
<Stavros> LarstiQ: i'm the only person working on this, so they never diverge
<Stavros> james_w: hmm
<LarstiQ> Stavros: you do update to merge in changes from the master branch
<LarstiQ> Stavros: hah, I diverge myself pretty often, but ok :)
<Stavros> LarstiQ: sure, but isn't bzr supposed to know that there haven't been any?
<Stavros> now, it tries to sort of "revert" to the master branch
<Stavros> and gives me conflicts to what i changed
<LarstiQ> Stavros: indeed, so I'm rather suprsised at conflicts.
<Stavros> LarstiQ: well yes, but i don't atm :p
<Stavros> now i have a pending commit, how do i push it upstream?
<LarstiQ> Stavros: commit.
<Stavros> with a message again?
<Stavros> i don't want to commit my local changes, though
<LarstiQ> Stavros: yes, or you can be sneaky.
<Stavros> hmm
<LarstiQ> Stavros: and bzr pull . -r revid:revidoflocaltip
<LarstiQ> Stavros: it does sound like maybe a checkout is not the optimal workflow for you though.
<Stavros> i just want to do the equivalent of a push but on a bound branch :/
<Stavros> LarstiQ: why not?
<LarstiQ> (apart from update pivoting changes when not strictly needed)
<Stavros> LarstiQ: i don't want to push each time by hand, so a checkout suits me better
<LarstiQ> Stavros: judging from this one case, but maybe the rest of what you do suits better
<LarstiQ> Stavros: right, ok
<LarstiQ> Stavros: let me mock something up and test if that would work for you
<Stavros> so what's the best way to just push my changes?
<Stavros> thanks
<Stavros> LarstiQ: can you reproduce the update merge, by the way?
<LarstiQ> Stavros: the update merge is normal, but it doesn't produce any conflicts for me
<Stavros> hmm
<Stavros> i had rev 60, committed 61 locally, changed a line in a file, and that line conflicted on update
 * LarstiQ pauses his mockup
<LarstiQ> Stavros: I'll find you a relevant bug report about the pending merges pivot first
<Stavros> hmm ok
<Stavros> so it goes, bzr ci, bzr ci --local, change line, bzr up, conflicts
<LarstiQ> ah, that is slightly different from what I did, will try it too
 * LarstiQ didn't have uncommitted changes prior to the bzr up
<Stavros> ah
<LarstiQ> hmkay, can't find it from bug titles, back to mocking
<LarstiQ> Stavros: yeah, a local change gets me a conflict
<Stavros> is that normal?
<LarstiQ> I understand why it might happen, it's not ideal.
<Stavros> hmm
<LarstiQ> Stavros: do you know the revid of the pending merge by chance?
<Stavros> it's still in my repo, how do i see it?
<LarstiQ> it's unfortunately harder to get to after the fact
<LarstiQ> Stavros: `bzr heads` from bzrtools might help
<Stavros> hmm, let me install it
<LarstiQ> `bzr heads --dead` specifically
<LarstiQ> you can then do `bzr pull . -r revid:<bzr heads discovered revid>`
<LarstiQ> that will probably give you lots of extra conflicts :/
<Stavros> well what good is that then? :P
<LarstiQ> Stavros: the revisions are pushed to the master
<Stavros> ah
<Stavros> with pull?
<LarstiQ> Stavros: yup, it's a bound branch
<Stavros> oh right
<Stavros> sec
<Stavros> there are two dead revisions
<Stavros> one is five days old
<Stavros> wth
<LarstiQ> yeah, 'dead' revisions are not garbage collected
<Stavros> ah
<Stavros> is the other one in my tree?
<LarstiQ> lucikly for us, since we can now recover
<LarstiQ> Stavros: it is in your repository, but since it is dead not part of your branch history
<Stavros> hmm
<Stavros> well that's odd
<LarstiQ> Stavros: this happens for example when you use uncommit
<Stavros> how did the history progress without it?
<Stavros> i didn't
<LarstiQ> Stavros: or pull --overwrite
<LarstiQ> or several other ways possibly
<LarstiQ> Stavros: history progressed by backtracking from this branch in the revision DAG and setting off in a different direction
<Stavros> ah
<Stavros> so what should i do now? pull with the revid?
<LarstiQ> Stavros: yes
<Stavros> wait, am i pulling from my branch to my branch?
<LarstiQ> Stavros: yes
<Stavros> should i back up my working tree first?
<LarstiQ> Stavros: should not be really needed, but safety first :)
<LarstiQ> Stavros: rather than pulling from your branch to your branch, you are pulling from the repository your branch uses
<Stavros> the local one, you mean?
<Stavros> or the bound one?
<LarstiQ> Stavros: the local one
<Stavros> ah
<Stavros> it's pulling
<Stavros> a bunch of conflicts again
<Stavros> and my tree is ruined :/
<LarstiQ> Stavros: well, you can resolve the conflicts
<Stavros> already did
<Stavros> but it should be a simple process :/
<Stavros> i don't want my dvcs to get in the way like this
<LarstiQ> Stavros: agreed.
<Stavros> is there another way to do it?
<Stavros> maybe unbind and push or just push or something?
<LarstiQ> Stavros: unbind and push would have worked.
<LarstiQ> Stavros: not having local changes at update time would also not have caused conflicts
<LarstiQ> Stavros: personally, I don't use checkouts
<LarstiQ> Stavros: longer term, this area needs love
<LarstiQ> Stavros: imho, the update should not pivot out the local commits if the master is a strict subset
<Stavros> yeah :/
<LarstiQ> Stavros: that way it wouldn't need to do any merges, hence no conflicts
<Stavros> agreed
<Stavros> i use checkouts because i update the master branch every time
<LarstiQ> I am very certain this has been discussed in the past, but I can't find a relevant bug atm :/
<Stavros> for backup or other workflow purposes
<Stavros> hmm :/
<LarstiQ> Stavros: maybe you can help me search?
<LarstiQ> and then update the bug/try to get some movement on it
<Stavros> sure
<Stavros> damn, my connection sucks
<Stavros> still loading the bugs page
<LarstiQ> https://bugs.edge.launchpad.net/bzr/+bug/175589 is not what I had in mind, but it describes your situation
<ubottu> Launchpad bug 175589 in bzr "suggested update when bound branch is out of date does confusing things" [Undecided,Incomplete]
<pygi> lifeless, I fixed the problem, just in case you're interested :p
<Stavros> i can't load any pages :/
<Stavros> my connection is the equivalent of dialup
<Stavros> oh wait, it's loading
<LarstiQ> Stavros: that sounds painful
<Stavros> LarstiQ: it is :/
<Stavros> pushes take a minute
<Stavros> ah, the page loaded
<Stavros> should i comment on that?
<LarstiQ> Stavros: I'll comment on it
<Stavros> thanks
<LarstiQ> Stavros: did I forget anything?
<Stavros> i will tell you when it loads :p
<Stavros> nope, looks pretty spot on
 * LarstiQ subscribed to the bug
<LarstiQ> now to file one for `bzr st -v --show-ids`
<Stavros> damn, i forgot to subscribe
<Stavros> another two minutes of loading
<Stavros> pretty multicultural, the subscription list
<LarstiQ> Stavros: if needed I can subscribe you
<Stavros> i subscribed, thanks
<Stavros> it finally loaded
<Ileden> Hi! Is there a way to have the .bzr directory in different location of the working tree?
<LarstiQ> Ileden: I think the answer is 'no', but I admit that your question isn't entirely clear to me.
<Ileden> for example, having tree at /home/ileden/projects/foo/tree-goes-here  and having the .bzr directory for in in /home/ileden/projects/bzrdata/foo/.bzr (or such)
<Ileden> I guess one option would be to always have the project files one step deeper, but a custom location would be mor elegant in a way
<Ileden> the problem is, I'd like to sync the working tree with Dropbox, which cannot be told how to ignore the .bzr data dir.
<Ileden> LarstiQ: yeah, I was afraid it's probably impossible.
<Ileden> the underlying problem here is that I'm doing developement on three different computers, and want to keep them in sync
<LarstiQ> Ileden: and using the regular publishing methods (bzr push/pull/merge) is not an option?
<LarstiQ> (say, you want to sync uncommitted changes as well)
<Ileden> yes
<Ileden> and if I'm working on three different projects I'd have to throw all my changes to a network place every time I switch computers
<Ileden> good scripting might hand that, true, but I still prefer the completely unobtrusive sync Dropbox offers
<LarstiQ> does it need to ignore .bzr?
<Ileden> I fear it's probably a bad idea to sync the .bzr dir via dropbox.
<LarstiQ> `bzr export` also only exports committed revisions, not uncommitted changes
<LarstiQ> Ileden: well, a checkout would presumably give you the same style as dropbox
<Ileden> LarstiQ: true, but I would lose the ability to make commits independent of network connection
<Ileden> which is a real issue, since I do a lot of developement in a disconnected environment (namely, the train :) )
<LarstiQ> right
<LarstiQ> there is --local, but it has some issues
<Ileden> and I also couldn't switch platforms to continue on uncommited changes... athough that's probably not such a big an issue, really.
<Ileden> Oh well, placing the files one level deeper than the tree will work fine, just not as elegant, so I think I'll use that.
<Ileden> hmm, a bigger problem is of course that I can only apply revision history and commits on one of the computers.
<Ileden> ach, it's all just giving me a headache, really :D
 * LarstiQ would drop Dropbox
<LarstiQ> but that's just me
<Ileden> yeah, it's not really a tool for this situation, I know. :-/
<Ileden> It's just I love the fact I don't have to do anything to keep the files in sync. Like using a shared online directory, only it's in local path and works offline.
<LarstiQ> Ileden: something like the network_manager plugin might help there
<Ileden> what are the issues using --local, by the way?
<LarstiQ> Ileden: `bzr update` after local will turn your local commits into pending merges, which if there are uncommitted changes will result in spurious conflicts.
<Ileden> LarstiQ: Ok. Well, thanks for all the information! I'll try to figure out which would be the best approach for me.
<LarstiQ> Ileden: you gave me an interesting idea for changing the network_manager plugin anyway :)
<Ileden> :D
<goodmami> bzr status says I have a pending merge, but bzr merge says "Nothing to do". any ideas?
<Necoro> goodmami: if you have a pending merge, you already merged ... so "bzr merge" won't do anything
<Necoro> you need to commit
<goodmami> Necoro, thanks. I was confused because my "bzr pull"s were failing and telling me to do a merge
<goodmami> i'll try a commit
<LarstiQ> goodmami: when pull complains the branches are diverged, you bzr merge; (bzr st; bzr diff, etc to make sure everything is ok); bzr commit
<goodmami> LarstiQ, thanks. I committed and pushed fine, and all the code seems in order, but it seems to have erased history of a merge from my other developer
<goodmami> (my other developer's changes were the ones i was having trouble merging into my tree)
<LarstiQ> goodmami: it sounds like his changes are now merged revisions, and not mainline
<LarstiQ> goodmami: does `bzr missing` from his branch to the one you just pushed to claim the revisions are actually missing?
<goodmami> LarstiQ, yeah perhaps. The repo is hosted by a launchpad team, of which both he and I are members
<LarstiQ> goodmami: also see bzr log --long (and -n0 if using a new enough bzr)
<LarstiQ> goodmami: the launchpad web interface doesn't show all revisions, just the mainline ones.
<LarstiQ> goodmami: lp:glot?
<goodmami> oh ok, i see his messages in the log file. they are under (indented in) my merge
<goodmami> LarstiQ, yes
<goodmami> launchpad did show his changes until i did the last push, so i figured his were mainline
<LarstiQ> goodmami: when you merged his changes and then committed, you reordered the mainline
<goodmami> LarstiQ, oh. hm. i guess that can happen, huh.
<LarstiQ> goodmami: it can happen. It is indeed not the recommended workflow.
<goodmami> LarstiQ, how do I avoid this in the future? should only one person do pushes to the mainline?
<LarstiQ> goodmami: the trick is to merge into the trunk, not merge the trunk into your branch and then push it over trunk
<LarstiQ> goodmami: say you have ~/src/glot/trunk and ~/src/glot/mami
<LarstiQ> goodmami: the first is a mirror of lp:glot, and the second is where you committed your revision 9, then discovered the other Michael had pushed diverging changes to lp:glot
<LarstiQ> goodmami: you've now probably done, from ~/src/glot/mami; bzr pull (lp:glot) -> message about divergance; bzr merge; bzr ci; bzr push
<LarstiQ> goodmami: if instead of that you did, cd ~/src/glot/trunk; bzr pull; bzr merge ../mami; bzr ci; bzr push; cd ../mami; bzr pull
<LarstiQ> goodmami: then his changes would have the same revnos they had (still on the mainline)
<goodmami> LarstiQ, I see what you mean, but I was working in trunk (probably not the best idea)
<LarstiQ> goodmami: and then your changes would not be shown by the launchpad web interface
<goodmami> LarstiQ, I had some changes that i committed, and when i pushed it said I didn't have an up to date tree or something
<LarstiQ> goodmami: right
<goodmami> LarstiQ, so I think I did a pull and a merge
 * LarstiQ nods
<LarstiQ> goodmami: there isn't anything technically wrong with how you did things, his changes are still present.
<LarstiQ> goodmami: it is just presenting a different view on history.
<goodmami> LarstiQ, it said there was something wrong in the file from my other dev, so i tried reverting it, then tried to throw away my changes and only use his
<LarstiQ> which I admit us humans aren't always comfortable with
<LarstiQ> goodmami: it had a conflict?
<goodmami> LarstiQ, great, now I'm a historical revisionist... ;)
<LarstiQ> goodmami: only the victors get to rewrite history ;)
<goodmami> LarstiQ, it didn't have a conflict, but it complained about it, so I assumed there was a conflict
<goodmami> LarstiQ, so... I win?
<goodmami> LarstiQ, anyway, I'll be more careful about that now. thanks for the help
<LarstiQ> goodmami: in the sense of determing which revisions are the mainline, yes, you just won.
<LarstiQ> bzr has an option to disable reordering the mainline, I'm not sure if launchpad can support that too
<goodmami> ah
<goodmami> LarstiQ, well hopefully we won't come across this again.
<LarstiQ> append_revisions_only
<goodmami> thanks
<LarstiQ> (dredged up from `bzr help configuration`)
<goodmami> ooh, i'll go check that out
<LarstiQ> goodmami: please do :)
<LarstiQ> feedback welcome
<goodmami> sure
<goodmami> thanks again
<stbuehler> what does it mean when i get "conflicting tags" in a "bzr push" to a svn repository (we migrated to a new server, 32 -> 64 bit) ?
<LarstiQ> no other changes to the svn repo?
<LarstiQ> no editing of the tags on the bzr side?
<stbuehler> i don't know for sure, but i don't thinks o
<LarstiQ> stbuehler: then my ideas are depleted and you'll have to ask jelmer
<stbuehler> any simpler way restoring this than rebranching it? i do not really care about my bzr history, i use bzr just as a frontend to svn
<LarstiQ> stbuehler: does the push actually fail, or is it just a message? I suspect the latter.
<stbuehler> just a message
<stbuehler> but i don't like it :)
<LarstiQ> stbuehler: does it repeat on later pushes?
<LarstiQ> stbuehler: and yes, it should go away after rebranching
<stbuehler> yes
<LarstiQ> stbuehler: I'm not too well versed in tags, but if you can find out what (bzr-)svn thinks the tags are, you could edit the tags file by hand
<stbuehler> i deleted some tags and pushed again -> no warning for them. bzr pull, tags reappeared, and with the next push the warning came back
<LarstiQ> stbuehler: ok. Have you looked through open bzr(-svn) bugs on tags?
<gotgenes> I'm trying to install bzr to my home directory on a red hat machine; I got the error "ImportError: No module named _md5" What's supposed to provide that module?
<LarstiQ> gotgenes: what version of python and bzr are you using?
<gotgenes> looks like python 2.5.1 installed to /usr/local
<gotgenes> bzr 1.13.1 from source
<LarstiQ> gotgenes: can you pastebin the backtrace?
<gotgenes> LarstiQ: Sure
<gotgenes> one sec
<LarstiQ> gotgenes: note that you can run bzr from source, no installation needed
<LarstiQ> (running make is still a good idea for more performance)
<gotgenes> LarstiQ: http://rafb.net/p/yXkGrD79.html
<LarstiQ> gotgenes: that looks like your python install is broken.
<LarstiQ> gotgenes: or at the very least doesn't contain the modules one expects from stdlib.
<LarstiQ> gotgenes: is this a python2.5-minimal package or somesuch?
<gotgenes> LarstiQ: Possibly. I'm not the sysadmin for that box, unfortunately.
<gotgenes> LarstiQ: Quite likely.
<gotgenes> Supposedly it was downloaded from source.
<LarstiQ> gotgenes: python -c 'from hashlib import md5' breaks, right? Does python -c 'import md5' fail as well?
<gotgenes> LarstiQ: Yes, I just ran that.
<LarstiQ> gotgenes: if so, I'd bug the admin asking for a working python install.
<gotgenes> LarstiQ: It seems I'll need to.
<LarstiQ> gotgenes: bzr does really need that to operate, is installing your own copy of python an option in the mean time?
<gotgenes> LarstiQ: Sure, into my home directory
<gotgenes> Suppose that's not too hard to do
<gotgenes> LarstiQ: installed Python to the home dir and bazaar installed fine after
<LarstiQ> gotgenes: cool
<gotgenes> Thanks for your help.
<jml> hello
<jml> I was looking at bug 351686, and wondering whether it's even possible with Bazaar
<ubottu> Launchpad bug 351686 in launchpad-bazaar "Merge proposal diffs should use -p option" [Undecided,New] https://launchpad.net/bugs/351686
<lifeless> small matter of code
<lifeless> -p is actually a regex search up from the change region
<lifeless> we support external diff options too if you're invoking diff
<jml> cool.
#bzr 2010-04-05
<lifeless> ok thats weird
<lifeless> http://github.com/matee911/bzr-flakes
<lifeless> bzr plugin, hosted on github.
<lifeless> We've got a *serious* usability failure to make that happen.
<SamB_XP> lifeless: so are you doing followup?
<lifeless> SamB_XP: I might
<lifeless> we'll see
<SamB_XP> apparantly he just imported it to github about two and a half weeks ago, with no commits since?
<lifeless> yah
<lifeless> it was on lp
<SamB_XP> yeah, so it says
<SamB_XP> but what I wanna know is why he didn't convert the history
<lifeless> wha! wow
<SamB_XP> yeah, he left behind a grand total of 3 commits!
<mtaylor> mordred@orisndriz03:~/src/drizzle/unittests$ bzr pump
<mtaylor> bzr: ERROR: exceptions.AttributeError: 'RevisionTree' object has no attribute 'branch'
<mtaylor> pipeline hate me
<johnf> Is it possible to get export to also export uncommited changes?
<lifeless> johnf: not currently; please ensure there is a bug
<ronny> sup
<ronny> where did bzrlib.diff._get_trees_to_diff go ?
<ronny> whops, it was turned to something more complicated but luckyly its actually a unused import i left in
<lukus> hi - i've just started using bzr and i've got a quick question
<lukus> i'm using a centralised store - but I'm the only person using bzr .. with my local copy, would it be okay to 'checkout' the trunk and work that independently and then push it back once i'm done, or should i still create independent branches?
<michaelforrest> does anybody know how I can get a combined bzr log for two or more branches?
<michaelforrest> or - you know - a repository log?
<michaelforrest> i.e. a text output of the stuff you see with bzr qlog ?
<michaelforrest> hm, okay the qbzr source has a load of 'open_locations' and 'append_branch' etc..  so I guess there's not a straightforward way :(
<sproaty> is there a way to exclude a file from a single commit?
<sproaty> I want to commit all changes besides one file
<beuno> sproaty, not easily
<beuno> you can use "shelve"
<beuno> to shelve the changes done to that file
<beuno> or specify the files you do want to commit, and leave the other one out
<sproaty> so I shelve the file, commit and then unshelve
<sproaty> and it'll show as a change for the next commit?
<beuno> yes
<sproaty> awesome  :)
<fullermd> Actually, commit has an -x/--exclude arg...
<sproaty> cheers
<sproaty> done what I wanted :D
<u-foka> hy!
<u-foka> is there a good way to completely remove a branch from a shared repo?
<luks> not easily
<luks> you have to re-creeate the repo
<u-foka> well, i hoped that an easier way exists :)
<u-foka> then stacked branches seems the only solution to the problem?
<_buck> I am working with Bazaar (bzr) 2.0.2  Python interpreter: /usr/bin/python 2.6.4 Platform: Linux-2.6.31-19-generic-i686-with-Ubuntu-9.10-karmic. At my university we connect using a http proxy(all protocols).
<_buck> When I do bzr launchpad-login eraser029   , I get this error : bzr: ERROR: Connection error: while sending GET /~eraser029/%2Bsshkeys: [Errno 111] Connection refused
<_buck> Please help.
<_buck> Can somebody tell me how to resolve this issue?
<dcraven> I'm using bzr-svn. Is there any way to get an svn style diff outside of using 'bzr send'?
<dcraven> I only want a diff of specific local revisions.
<jelmer_> dcraven: hi
<jelmer_> dcraven: not at the moment, though I agree it would make sense to provide a way to do that
<dcraven> Crud :)
<jelmer_> dcraven: can you perhaps file a bug about this?
<dcraven> jelmer_: I will do that. Thanks.
<lifeless> moin
<jelmer_> 'lo lifeless
<igc> morning
<lifeless>  hi
#bzr 2010-04-06
<lifeless> igc: I'm popping up to the doctor
<igc> lifeless: ok
<lifeless> igc: I'm back on bzr now; if you need me in the next few hours you can SMS me
<igc> thanks
<meoblast001> hi
<meoblast001> i'm considering writing a hook for my Bazaar server
<meoblast001> i need to know if this will work
<meoblast001> i know a guy who is willing to help me out on one of my projects, but i don't know if i can trust him because he specifically said he would replace all tab characters will 4 spaces and commit with that...... is there a way i could make a server hook that swaps all 4-space tabs with tab characters when he pushes?
<meoblast001> right now,i really can't trust him
<meoblast001> or at least deny his client from pushing if he uses 4-space tabs (that way at least he can't cause damage)
<fullermd> Well.  That would require rewriting all the revs, so he'd have to pull --overwrite afterward...
<meoblast001> is there a pre-push hook on the server?
<fullermd> But if you can't trust him, why the putz would you let him push in the first place?
<meoblast001> that would allow me to end the push
<meoblast001> fullermd: i have no idea... i don't think i will
<meoblast001> i just want to know if i can just incase i ever do give him write access
 * igc back in a few hours
<GungaDin> is there an easy way to check what branch another branch was branch off?
<lifeless> meoblast001: there is a pre change hook yes
<lifeless> see bzr help hooks
<meoblast001> lifeless: can i use that to completely kill the push?
<lifeless> that is why I mentioned it
<meoblast001> ah, ok :)
<meoblast001> lifeless: you're both a Bazaar and Launchpad dev right?
<lifeless> roughly
<lifeless> I've written code for both
<lifeless> not really active on lp codebase at the moment though
<meoblast001> the code viewer in LP, that browses code in Bazaar
<meoblast001> i'm thinking about scripting up something small like that in PHP for my server, so people can browse my sources
<meoblast001> does Bazaar have utilities for getting file sources at certain revisions?
<lifeless> yes
<lifeless> bzr cat
<meoblast001> ah, ok thanks :)
<lifeless> bzr xmloutput might have something
<lifeless> but personally, I'd suggest you just install loggerhead
<meoblast001> what does loggerhead do?
<spm> meoblast001: loggerhead == "the code viewer in LP, that browses code in Bazaar"
<meoblast001> ah, is it a Python/Django script?
<spm> django? not that I'm aware of. python yes. https://edge.launchpad.net/loggerhead/
<meoblast001> ah, ok
<meoblast001> spm: does that use bzr cat?
<meoblast001> or is it a Bazaar plugin?
<spm> meoblast001: perhas if we back up a bit and you ask what you're trying to get to? else we're just playing 1001 questions here :-)
<meoblast001> well, does Loggerhead use bzr cat, or does it actually consist of a Bazaar plugin to make it more efficient?
<lifeless> meoblast001: its a bzr plugin
<meoblast001> ah, ok
<lifeless> meoblast001: and standalone WSGI app
<lifeless> using python-paste for serving
<lifeless> I think django can speak wsgi too
<meoblast001> what advantage does that provide over using a pipe in PHP?
<lifeless> its already written and feature complete?
<lifeless> it uses bzr's library, so can keep state in memory, making it ~ 1000 times faster
<Talidan> hey there, im a little confused about what bazaar is capable of doing
<Talidan> btu for our project, we're basically looking for SVN with forks
<Talidan> people can create their own fork of the main repo, and we (administrators) can cherry pick and merge specific changes from remote forks
<RAOF> Talidan: bzr can do that (among other workflows)
<RAOF> Talidan: http://wiki.bazaar-vcs.org/Workflows might help you.
<Talidan> thanks RAOF, i'll check it out
<eydaimon> I need merge revno 519, 521, and 522. Is there some way I can do it in a single merge?
<TresEquis> Howdy, all
<lifeless> hi
<TresEquis> Any news on the nested-trees blueprint on launchpad?  Look like it blocks support for implementing svn:externals in bzr-svn
<TresEquis> https://blueprints.launchpad.net/bzr/+spec/nested-tree-support
<TresEquis> Branch hasn't been updated in quite a while
<lifeless> no news
<lifeless> its essentially stalled
<TresEquis> 2 years worth :(
<lifeless> there are other projects like scmproj and bzr-externals that may interest you
<TresEquis> I was looking at bzr-externals
<lifeless> you've been able to do svn-externals like stuff for about 5 years now, using config-manager
<TresEquis> would be cool if bzr-svn would use one of them to handle the mapping
<lifeless> true
<lifeless> the main thing is that noone is scratching the itch in the core
<TresEquis> Its a blocker for using bzr against "big" SVN projects, which use externals a bunch
<lifeless> sure
<lifeless> you know how open source goes though :)
<TresEquis> So far, the only one I have stumbled over, using bzr 2.1 and bzr-svn 1.0.2
<TresEquis> yup
<sinasalek> Hi
<lifeless> woo: Running [ 1% 3 test(s) ] Current test: bzrlib.tests.blackbox.test_add.TestAdd.test_add_control_dir(pre-views)
<sinasalek> I'm about to select bazaar , however there is a feature i pretty much need which it seems that bazaar does not support.
<sinasalek> Do you the status of partical checkout/branch , i know there is a roadmap but don't know when it will be released
<lifeless> partial in what sense ?
<sinasalek> like subversion update --depth
<lifeless> I don't know what that deos.
<lifeless> s/deos/does/
<sinasalek> When i want to checkout a large project in order to work only on an specific folder. i don't want to download the whole thing
<sinasalek> Only that folder.
<sinasalek> does it make sense know?
<lifeless> there is a feature called 'views' that avoids putting the content for other folders on disk.
<lifeless> However, bzr still downloads the same backend data for the repository content.
<sinasalek> i'm aware of that, but i couldn't figure out how to use it with branch sub command
<sinasalek> there nothing mentioned in documentation or man pages
<lifeless> probably needs a patch to let you set the view when you branch
<sinasalek> Yeah, that's the problem. what do suggest me to do?
<lifeless> see if there is a bug open
<lifeless> if there isn't, file one
<lifeless> if you'd like, I can then mentor you on making the code change
<sinasalek> Than lifeless i appreciate it. So you're saying that it's implemented ?
<lifeless> no
<lifeless> I'm saying that it needs to be implemented
<lifeless> and we need a bug open to track it
<lifeless> and its likely small, so if you want to do it, we can help you do it.
<lifeless> spm: http://pqm.bazaar-vcs.org/ - check it out :) - thanks
<spm> wooo!
<lifeless> the line 'Running [ 19% 4408 test(s) ] Current test: bzrlib ...
<lifeless> is the UI benefit here
<lifeless> failures will include a subunit trace if we've done it right
<lifeless> I'm going to send a failing merge after this
<sinasalek> lifeless: I see
<sinasalek> lifeless: i'll search the issue and come back. tx
<lifeless> jelmer: ping
<sinasalek> lifeless: i submitted a new issue.https://bugs.launchpad.net/bzr/+bug/556236
<ubottu> Ubuntu bug 556236 in bzr "branch --view feature is missing" [Undecided,New]
<lifeless> vila: see the shiny shiny pqm progress bar ?
<vila> lifeless: yup :)
 * igc dinner
<mobby> Hi, just wondering if someone could help me please? I'm getting "Unable to find old fileid for..." errors when using bzr with an SVN repository in work. Any ideas why I would be getting this problem or what the problem means?
<bialix> can you pastebin full traceback?
<bialix> have you changed anything on your svn server?
<bialix> maybe root id f svn server?
<bialix> maybe root id of svn server?
<mobby> well the repository recently went from 1.5 to 1.6 format but I was having the same problem before the migration
<mobby> root id? sorry bit of a newbie to the finer workings of vcs :)
<mobby> I've put a stack trace on pastebin, here http://pastebin.com/4g9Xz0ez
<mobby> hopefully I've done that right :)
<mobby> I changed some of the path names, filenames, etc as like I said it's an svn repo in work
<mobby> you'll see in the traceback I'm doing an update, but I get the same error doing a checkout (lightweight) of a different path as well (albeit due to a different file).
<bialix> mobby: it looks like the bug in bzr-svn
<bialix> our bzr-svn wizard is not here right now
<bialix> can you file a bug against bzr-svn on LP, please?
<bialix> mobby: also, can you say how you get the working copy? with `svn co` or some bzr command?
<mobby> Ok I'll raise a bug. I use "bzr checkout --lightweight http://....." I can't quite remember how I got hold of the one I'm doing the "update" in. I think it was using "bzr checkout ...." (I'll put this info in the bug)
<mobby> thanks for your help
<bialix> mobby: you can try to re-create working copy from the scratch in some empty folder
<bialix> mobby: also there is cache of svn metadata in your bazaar config directory. maybe you need just delete it
<mobby> oh ok, I'll try deleting that...
<bialix> though this is just stab in the dark
<mobby> I'm trying a new checkout and if that fails I'll try deleting the metadata and try again. Fingers crossed as I've been wanting to use bzr for a while now with our repo but keep hitting brick walls, usually due to our svn server which bzr isn't liking.
<masklinn> small issue with bazaar & merges: a colleague merged a branch in our trunk, but it turned out that he'd incorrectly resolved conflicts/missed some and hadn't tested the merge correctly. Except he still pushed it. So we decided not to uncommit (because it's ugly) and we reverted the merge commit instead (with merge -r{commit-revision}..{revision-before-commit}).
<masklinn> Broken code gone, but now when I try to rebase the old branch into the reverted trunk, whatever options I provide, it tells me the trunk is a parent of my branch (technically true) and just performs a pull
<masklinn> is there a way out of that?
<masklinn> s/into the/onto the/
<maxb> Other than hacking the bzr-rewrite source to remove that check, I can't think of one
<masklinn> dammit
<masklinn> mmm or maybe I can try a rebase on the revision right before the merge, it should change all revision ids, and then I rebase again to the current tip
<mobby> bialix: Is that metadata the "subversion.conf" file or are there other cache files?
<jelmer> masklinn: that revision is already present in the parent branch, that's why it's trying a pull
<masklinn> jelmer: yeah I understand why it behaves as it does and why you'd usually want that, but that doesn't help me much as I'm specifically in a case where that's not what I want
<maxb> masklinn: I have commented out this check in the past and things have worked fine
<masklinn> maxb, ok, I'll try to do it in to steps first, and if that doesn't work I'll do the commenting thing
<masklinn> s/to/two/
<lifeless> masklinn: please make sure there is a bug erport for what you need
<masklinn> lifeless: are you sure? it's a fairly specific (and I'd hope rare) need
<masklinn> and I'm not sure whether it'd be a bug in bazaar (bug: impossible to revert a "merge" revision, merged commits are still considered being in the history) or rebase (wishlist: be able to force rebase even when rebased revisions are already in target branch)
<bialix> mobby: ask jelmer
<mobby> bialix: ok thanks :)
<mobby> jelmer: Hi, before you were here I asked the following question. I wonder if you could help me please? - I'm getting "Unable to find old fileid for..." errors when using bzr with an SVN repository in work. Any ideas why I would be getting this problem or what the problem means?
<bialix> mobby: btw, are you using bzr.exe? from standalone windows installer?
<mobby> bialix: yeah it's the standalone windows install
<bialix> mobby: I'm not sure which libsvn version there is bundled. in the past it was 1.5
<jelmer> mobby: hi
<mobby> jelmer: hi
<bialix> so it's not really possible to work with 1.6 server
<bialix> maybe it's not true anymore
<jelmer> mobby: Can you pastebin the error?
<mobby> http://pastebin.com/4g9Xz0ez
<mobby> bialix: from the .bzr.log the svn version is 1.6.6 in bzr-svn. (I think)
<jelmer> mobby: please file a bug, this is almost certainly a bzr-svn issue
<bialix> mobby: ok, thx for the info
<mobby> jelmer, bialix: ok will do. I've cleared the cache and I'm doing a new checkout, so far it is going on longer than before so the fix for the bug might be to clear the cache. I'll let you know how it goes.
<mobby> s/fix/workaround/
<jelmer> I don't think clearing the cache will help, unless you've been changing existing revisions in your repository
<mobby> jelmer: Not sure, I know our repo was upgraded from 1.5 format to 1.6 recently but I *think* I was having the same problem before that change.
<lifeless> masklinn: a rebase bug
<lifeless> there are bugs already for cherrypick merge
<mobby> jelmer: hmm, after clearing the cache and doing a clean checkout using bzr I got a different error - bzr: ERROR: subvertpy.SubversionException: ("REPORT of '/PATHXXX/!svn/bc/601278': 200 OK (http://XXX)", 175002 )
<mobby> jelmer: I'll raise the other bug now anyway
<mobby> jelmer: Bug raised here - https://bugs.launchpad.net/bzr-svn/+bug/556451. Hopefully it has the information you require.
<ubottu> Ubuntu bug 556451 in bzr-svn "Unable to find old fileid error on checkout/update" [Undecided,New]
<jelmer> mobby: thanks
<mobby> jelmer: no problem :)
<Lo-lan-do> Hi all
<jelmer> hi Lo-lan-do
<Lo-lan-do> jelmer: Question about bzr-svnâ¦ apparently branches stored in /branches/dir/subdir in the SVN repo don't get recognised by "bzr branches", is that known?
<Lo-lan-do> I'd like to tell FusionForge hackers to feel free to host their branches in /branches/people/$login/$feature
<Lo-lan-do> (Or even without the /branches component, ie straight in /people/$login/$feature)
<Lo-lan-do> Am I likely to run into problems?
<jelmer> Lo-lan-do: where /branches is inside of a Subversion repository?
<Lo-lan-do> Yes
<jelmer> Lo-lan-do: You won't run into problems trying to clone those branches later, but they e.g. won't be imported as separate branches by "bzr svn-import"
<jelmer> Lo-lan-do: This is all because Subversion doesn't really have a notion of what a branch is
<Lo-lan-do> I see.  Yes, I know of that limitation, but I guess I can live with that.
<jam> morning all
<jam> So vila, about history-db, you mentioned there were bits you didn't understand, care to elaborate?
<vila> jam: So, about Caching 'dotted_revnos' and merge_sort, first, what are you caching exactly for a given revision ?
<vila> the same revision (in the worst case) can have a different revno in each branch
<jam> vila: so yes, "worst case" the cache would be N revs * M branches, where M could get close to N
<jam> however, I posted some results for both mysql and bzr
<vila> yes,
<jam> and importing the whole history, with each rev as a different "branch"
<vila> that's the part I don't get
<jam> take the history of bzr.dev
<jam> walk all revisions
<vila> you mean a branch the branch is the tip ? Something else ?
<jam> consider this revision as the tip
<jam> import and cache
<vila> ok
<jam> I optimize it slightly
<jam> by walking backwards through history
<jam> so I'll often get shared mainlines
<vila> that doesn't give me the revno when this branch is merged though
<jam> and only import 1 of a series
<jam> vila: so #1, import the merge_sorted graph
<jam> splitting it by mainline revno
<lelit> hi all, a tailor user asked me about this problem: http://codepad.org/ru75we4F that happens on a big CVS repo, both with bzr 2.0.1 and with 2.1.1. Anybody knows if there is some kind of "finalization" I'm missing, when dealing with open_workingtree() objects?
<jam> which *does* tell you what revisions were merged into a given mainline rev
<jam> it doesn't tell you the info for that merged revision as the tip, though
<jam> that comes later.
<jam> vila: does that help?
<vila> Right, so that's an intermediate result,
<vila> and you use that to speed merge_sort by importing the "bottom" of the graph, right ?
<jam> lelit: looking at "stat_and_sha1" the file_obj = ... is shortly followed by a "try/finally:file_obj.close()"
<jam> So I don't think it would be leaking *those* file handles
<jam> but it may be leaking elsewhere?
<jam> vila: so... I *think* I haven't finished implementing "speed merge_sort" yet
<jam> That's part of what I wanted to discuss, to see if my thoughts there made sense.
<jam> *Right now* the current code is:
<jam> for a given branch (bzr.dev): KG.merge_sort(), import everything
<lelit> jam: the tailor side is doing this: http://progetti.arstecnica.it/tailor/browser/vcpx/repository/bzr.py#L365
<vila> jam: also, in your mail for mysql-6.0 --expand-all, you say: 32m import time
<jam> with --expand-all
<vila> 32 minutes ?
<jam> I then walk backwards from tip
<bialix> hi jam, vila
<jam> morning bialix
<vila> hey bialix
<bialix> morning jam, there is afternoon :-P
<jam> and if a given revision isn't already imported as a 'tip' (as identiified by tip_revision = merge_revision), then I do another KG.merge_sort(new_tip) and cache the result
<jam> Without --expand-all, mysql imports in about 11s
<jam> With --expand-all, it finds ~17k unique branches, and takes 32 minutes, yes
<bialix> jam, after reading your cache db mail, I've suddenly realized we need for qlog only dotted revno of the tip of merged branch
<bialix> I'm not sure what is KnownGraph stuff you and Gary merged recently
<jam> but 17k * 11s >> 32 minutes
<jam> bialix: not really related to what I'm doing now, I suppose tangentially
<vila> haaa, imports is reading all the graph *today*
<jam> vila: so you have to read the whole graph 1 time, but after that we can do better
<bialix> jam: do we have any way to say "this revision is mainline", or this is also should be cached?
<bialix> sorry to cross you and vila
<jam> bialix: its ok. for an arbitrary revision?
<bialix> jam: yes
<bialix> jam: when you traverse merged branch you need to know where to stop, when you come back to mainline. is it correct?
<jam> You can call Branch.revision_id_to_revno
<jam> and if it raises an exception, the revision isn't on the mainline
<vila> jam: I have trouble with the numbers you mention as I can't easily say which relates to our existing code and which depend on your wip
<jam> bialix: there is quite a bit more too it, as some of the intermediate 'merged' revisions may have been merged earlier
<jam> http://paste.ubuntu.com/410035/
<jam> bialix: with time going up
<jam> you need to know that C is merged into E when you go to expand F
<jam> because you don't display it
<bialix> jam: I see
<jam> http://paste.ubuntu.com/410036/
<jam> merge_sort is how we determine what revisions go where in the graph
<jam> and then we put dotted_revnos from that fairly easily
<bialix> actually qlog expand entire merged branch, which sometimes is not the best thing. but I see what you mean
<jam> bialix: sure, but even then you need to know that C was merged
<jam> somewhere
<jam> and to determine that
<jam> you currently have to walk backwards from all mainline revs
<jam> in *case* it was merged there
<jam> vila: so, the *counts* should be correct
<vila> jam: I think loading the whole graph for a mysql branch < 2s, not 11s
<bialix> jam: ok
<jam> vila: importing the whole graph into the database is 11s
<jam> "bzr walk-ancestry --method=bzr" was 2s
<jam> --method=bzr-kg was 1.4s
<jam> --method=db-dotted was 0.087s
<Lo-lan-do> jelmer: Switching to /branches/$login_$branchname, IÂ seem to run into "Operation denied because it would change the mainline history." when committing a merge, which I don't understand since I'm doing no such thing.
<jam> vila: so the time to get data *out* of the db should be accurate, and the counts of objects *in* the db should be accurate for future reference
<jam> (subject to tuning, etc :)
<jam> the time to put data *in* the database is still being worked on
<vila> ok, clearer, loading the db is not the most relevant, it should occur only one and then incrementally
<jam> vila: so I think loading the db taking 11s the first time is probably going to stay
<jelmer> Lo-lan-do: you're not pushing merges?
<vila> hmm, may be not, well it depends, your focus is loggerhead only/first/dunno ?
<jam> Loading an arbitrary real-world branch (today) requires grabbing get_known_graph().merge_sort()
<jam> which has a similar ~1s overhead
<Lo-lan-do> jelmer: I'm trying to commit a merge in a branch bound to SVN, so I probably am.
<jam> but then loading the unmerged data into the db is quite fast
<jam> --expand-all is sort of the ultimate "bring in as many branches as I can possibly find"
<jam> meant to stress-test the system
<jam> though you may want to run that in the future
<jam> In the import code *today* I believe the bottleneck is calling KG.merge_sort() for each one
<Lo-lan-do> jelmer: svn cp $svnrepo/trunk $svnrepo/branches/lolando_test, then a commit in a bzr branch bound to svnrepo/branches/lolando_test, then a merge of that into a checkout of $svnrepo/trunk, then commit.
<jam> Once I finish what I'm looking at now
<jam> both should be possible as an 'incremental update', and then you should be sub-second for all imports after the fisrt one
<jam> (note that right now you are at around 44ms for --expand-all per branch, and I think 40ms of that is merge_sort)
<jam> mysql is around 100ms per expanded-branch
<jam> vila: do those numbers make sense to you?
<vila> jam: that sounds sensible, my first interpretation is that you're demonstrating that the IOs are killing us, so batching them is good :)
<vila> jam: the db size is still a problem though, may be not for loggerhead... well, at least lp should make it possible to have one by project
<jam> vila: well, I was pretty surprised to see that "walk-ancestry" using the database was still 300ms or so, until you start walking 100 mainlines at a time, and it suddenly drops by an order of magnintude
<vila> jam: your dn can be shared across all branches of project right ?
<jam> vila: in theory it can be shared across all branches of all projects
<jam> though like shared repos, you don't benefit as much
<vila> jam: the numbers for walk_ancestry are for iterating the whole ancestry ?
<jam> vila: yes
<jam> 80ms to get the *entire* ancestry
<jam> 30k revs
<jam> or 68k revs for mysql
<jam> though for the db numbers, that isn't always in 'revision_ids'
<jam> you would have to probe one more table to get back to raw revision_ids
<Lo-lan-do> jelmer: http://whiteboard.debian.net/d6d21f.wb has the log
<jam> vila: so I'd like to discuss some of the algorithms for generating merge_sort, and see if they make sense to you
<vila> jam: sure
<jam> so I have some updated docs, and a start of an implementation in lp:~jameinel/+junk/bzr-history-db
<jam> (currently on rev 45)
<jam> there are a few ideas in there, I didn't really get it polished
<jam> but the general idea is to figure out what revisions need to be adedd
<jam> added
<SamB_XP> aeddd
<jam> (to the dotted_revno cache)
<jam> and I thought of some interesting uses of gdfo and parent => child mappings
<jam> the idea is that if all known children of a revision can be accounted for, then you can know that a rev was/wasn't merged
<jam> rather than having to walk in pure gdfo order
<vila> "accounted for" ?
<vila> oh, and how do you handle ghosts ?
<jam> http://paste.ubuntu.com/410050/
<jam> time going upwards for you
<jam> sorry, missed a step, just a sec
<jam> well, maybe I can work with that
<jam> the idea is that X : B could be very long
<jam> which would make E have a high gdfo
<jam> however, thinking about it, it would still only be proportional to the diffs in the graph
<jam> so that doesn't quite fit my case yet
<jam> vila: at the moment ghosts are just treated as roots
<jam> I plan on accounting for them by putting them in a 'ghosts' table
<jam> since they are rare, I don't want to add a column on the 'revision' table for all the ones that aren't ghosts
<jam> so one possiibility: http://paste.ubuntu.com/410052/
<jam> In this case, B is from a very old revision, so X has a few revs to it, but can have a much lower gdfo than C
<jam> the idea is that the only known child of X is D
<jam> so you know it wasn't merged before C
<jam> and the only known child of parent_of(X) is X
<jam> so again, you know it wasn't merged before
<jam> which continues until you get to B
<jam> at which point, you have to see if B was merged before,
<jam> so you start walking the mainline
<jam> however, I do wonder how the design works with: http://paste.ubuntu.com/410056/
<jam> (no merge)
<jam> It will need to walk all the way back to A, and will load the dotted-revno info inbetween
<jam> may be unavoidable, but I think with known_children you could instead just walk the mainline revs, and not their merged revs
<vila> your db provide the children ? Or you build that as you walk the graph ?
<jam> vila: the parent table intrinsically provides children
<jam> SELECT child FROM parent WHERE parent =?
<jam> vs
<jam> SELECT parent FROM parent WHERE child = ?
<jam> I believe I have 2 indexes on the table
<jelmer> Lo-lan-do: it wants to copy from one of the merged branches I suspect
<jelmer> Lo-lan-do: and keep that as mainline
<jelmer> Lo-lan-do: please file a bug
<vila> jam: well, then you have even more shortcuts than with gdfo :)
<Lo-lan-do> jelmer: I've tried to do a svn commit in trunk just now, and now I can't bzr update the bound branch :-/
<Lo-lan-do> AssertionError: Tried registering <CachingRevisionMetadata for revision 9363, path trunk in repository '9d84d37e-dcb1-4aad-b103-6f3d92f53bf6'> as parent while None already was parent for <CachingRevisionMetadata for revision 9368, path trunk in repository '9d84d37e-dcb1-4aad-b103-6f3d92f53bf6'>
<jam> vila: right
<vila> jam: you're still loading the whole graph anyway right ? (by whole I mean the revisions reachable from tip)
<jam> vila: the goal is to not do so
<jam> I believe I can compute merge_sort by only loading "enough" revisions
<jam> which is, the last merge sorted parent
<jam> of all newly merged revisions
<jam> and possibly a bit more context to get the numbers right
<jam> I still haven't sorted all that out, but I think I have a feel for it
<vila> jam: the thing I like with your approach is that it makes it easier to try various new tricks, some of them could be backported with a bit of luck
<vila> jam: can we query the bzr indices from a starting key for batch of keys ?
<jam> vila: not trivially
<jam> though that is what _known_graph_ancestry tries to do
<IslandUsurper> sorry for the interruption, but did cherrypicking ever cause a pending merge? I was surprised when it didn't just now
<maxb> cherrypicking never does
<maxb> It would be illogical for it to do so
<jam> IslandUsurper: if you give a "cherrypick" range that actually includes a full ancestry, then it will record a pending merge
<jam> if it is 'accidentally' not actually a cherrypick
<IslandUsurper> yeah, that makes sense
<jam> vila: I think I've found a couple holes in my new design
<jam> I pushed up a test case in rev 46 that might show it
<jam> specifically, when computing the second value in the dotted revno scheme, you pretty much *have* to load all children of the first revno
<jam> because there can be shortcuts that bump the 'branch' number, that are hidden by more recent merges
<jam> :(
<jam> vila: what were you saying about changing how we number again ? :)
<vila> jam: hehe, don't resign too fast :)
<vila> jam: but yeah, since there is not much added value in our actual scheme, changing for one that would give the merged-in mainline revno, can't be a loss
<jam> so one option is still "load all the ancestry between now and the parent you want to number from"
<vila> jam: but if merge_sort is only 40ms for a complete graph, the problem to address is really to load the graph (or the needed part) faster (and preferably with an acceptable space cost ;) no ?
<jam> vila: 40ms * 4k is minutes to expand all of bzr.dev. With incremental merge numbering we should be able to cut that by at least an order of magnitude
<jam> the bigger issue
<jam> is that I'd like to have a cache that gets updated with *commit*
<vila> 4k ?
<LeoNerd> Tiny bugreport: bzr should ignore SIGWINCH...   I got a failure of "bzr pull" with "Interrupted system call" from resizing the window
<jam> (4k branches in the history of  bzr)
<jam> so the 1-2s to load the ancestry of bzr.dev plays a much bigger deal there
<jam> which is why I wanted an incremental algo
<vila> I'm talking about a *single* merge_sort, isn't it 40ms *without* the loading part ?
<jam> right
<vila> right, gdfo is the easiest trick to manage at commit time :-)
<vila> gdfo = mac(gdfo) + 1 :)
<vila> s/mac/max/
<vila> but the actual numbering scheme is the problem since it requires loading the whole graph
<vila> even if you manage to  "load all the ancestry between now and the parent you want to number from", you still have the case where some daggy-fixed from a merged branch and merge again
<vila> s/some/someone/
<jam> vila: true, though even daggy fixes don't go back to revno 1
<vila> jam: indeed !
<jam> the painful one in bzr's history is aaron's *long* lived integration branch
<jam> however, I do think those cases are the exception rather than the rule
<jam> and having an incremental algo will be good
<jam> just that i have to be aware of edge cases so I don't get them *wrong*
<jam> and the algo can be fast as long as it detects when it needs to fall back
<jam> so far, the 'detecting' part still looks expensive, which I'm unhappy about
<vila> jam: I think that even branches that are merged multiple times could be addressed too  with a different revno scheme, they'll get dotted revnos with different first parts
<vila> jam: and again, using gdfo will help ensuring we number each revision based on its first landing (but gdfo may not be enough here, we may need a bit more help)
<vila> jam: so, concerning roots, you haven't addressed the filling part yet right ?
<jam> vila: ghosts/roots, no. But wipe and restart is a valid option.
<jam> The parent graph is still correct in the db
<jam> so you don't have to  go back and touch branches again
<jam> vila: note that gary told me earlier that qlog makes use of the fact that a "branch" maintains its second number
<jam> well, first 2 numbers
<vila> jam: yeah, I think it's not such a good idea, but a good shortcut because we don't have cheaper ancestry checks
<vila> jam: and I would be delighted if he could magically find back the true branches in mysql mazes :)
<vila> jam: I just noticed: "If a revision   X is in the ancestry of tip T, then the dotted revno for X will be the same  for all descendents of T."
<vila> this is true *only* if T was a tip and is *still* on the mainline
<vila> jam: have you tried reusing your db on different mysql branches ?
<jam> vila: well I did --expand-all, which should be approx the same as "different branches"
<jam> vila: and for the "same for all descendents", sure, but that is how I'm caching
<vila> jam: ok, just wanted to make sure, there is really no mainline shared between mysql branches (apart from the initial import maybe)
<jam> vila: see my results
<jam> there is an average of only 68 rev divergence
<jam> and the rest is 'shared mainline'
<jam> vs bzr which has an average of 170 rev divergence
<jam> put another way, even though the ancestry of mysql-6.0 is 2x that of bzr, the final size of the db was == bzr after filling out the dotted revno table
<vila> jam: that's where I'm really surprised :)
<jam> vila: yep, I was too
<jam> I haven't probed enough to figure out why
<vila> jam: as in: a bit too much to trust these numbers wit... yeah :)
<vila> jam: what commands should I run in a given branch to get the same stats ?
<jam> vila: generally 'bzr create-history-db --db=filename -d branch --expand-all'
<jam> It *might* be broken right now, let me check
<jam> ah, it should be fine if you don't use --incremental
<jam> with --expand-all it should spit out some stats about how many revs were expanded, etc. And how many total entries you have
<jam> which is how I figured the numbers
<jam> you can also use "sqlite3 filename" and then do custom queries in there
<vila> jam: random thought: at *merge* time it's cheap to record how "deep" the merged branch is (for external branches) or how many new revisions are merged from the other mainline
<vila> jam: some hints may help devising a new incremental revno scheme
<jam> vila: I'm not really sure what you are proposing.
<jam> when merging, all branches are 1 deep
<jam> all *merged* branches are 1 deep
<jam> 'how many new revisions' is probably not all that easy
<jam> graph-difference vs just finding a common ancestor
<vila> jam: think merge-into and the consequences on the revnos
<vila> jam: sure, but you have the relevant graph already loaded anyway
<jam> at least most, probably
<vila> jam: so we are in the "40ms for merge_sort" area, hence cheap
<NfNitLoop> Coworker came to bzr from git.  He wanted to get rid of the last 3 revisions, so he did a 'bzr update -r -4'.  Then did some work, and was surprised when he couldn't commit.
<NfNitLoop> we fixed it with shelve and 3x 'bzr uncommit',  but...
<NfNitLoop> is there a better way to do that?
<NfNitLoop> bzr pull?
<james_w> yeah, that works
<james_w> or bzr uncommit -r
<NfNitLoop> Ok.  What's the purpose of being able to do an update to a past revision, then?
<NfNitLoop> seems weird if you can't commit to it.
<zooko> Folks: there is a student applying for Google Summer of Code to work on the Tahoe-LAFS project and to integrate Tahoe-LAFS with a DVCS.
<zooko> bzr is a candidate.
<zooko> Would any bzr hackers be interested in mentoring or at least consulting?
<jelmer> NfNitLoop: you can if the branch is not bound I think
<jelmer> zooko: Yeah, np
<NfNitLoop> it was not a bound branch.
<NfNitLoop> 'bzr up -r -4' seemed to update the working copy and even the current revision, but when he tried to commit it said that he couldn't because the working copy was out of date.
<NfNitLoop> even though it's a standalone branch.  (Well, within a shared repo.)
<eydaimon> I need merge revno 519, 521, and 522. Is there some way I can do it in a single merge?
<vila> What is the english expression about a round thing into a squared other thing ?
<LeoNerd> Round peg, square hole?
<LeoNerd> (or vice versa, really.. I expect either way works)
<vila> yes ! But what is the sentence used ?
<vila> trying to fit a round peg in a square hole ?
<LeoNerd> Oh. something to the effect of "trying to fit.." yes. that
<jam> vila: are you still around?
<jam> just to mention "square peg in a round hole" is the more common phrasing
<jam> http://www.google.com/search?q=round+peg+square+hole
<jam> (notice that I searched for round peg square hole and got the reverse)
<jam> anyway, I had another idea about the partial graph, in case vila comes back around.
<vila> jam: still there for a few minutes
<jam> http://paste.ubuntu.com/410151/
<jam> vila: basic observation
<vila> jam: and another random idea: you can add gdfo into your db right ?
<jam> vila: gdfo is already in the db
<jam> and I'm using it now
<jam> basic observation: you don't need to load back to revno 0
<jam> you need to load back to revno x.y.? that you are based on
<jam> That can potentially be a big difference
<jam> when finding a new branch number based on 1.5000.1, you don't need the data for anything 1.<5000 (maybe)
<vila> jam: you got it
<vila> jam: and then, if you had a bit more info in the ancestry graph you may even get there without a cache
<vila> jam: like: next merge point in my ancestry is at distance x
<vila> jam: which should help addressing the problem of the last part of the revno (otherwise you have to walk it until its origin to start at 1) (for various definitions of origin)
<vila> jam: but I'm still not sold about numbering in one way or the other (M: 5.1.1, L: 5.2.1, K: 5.1.2, etc) or (M: 5.1.2, K: 5.1.1)
<balor> Gah, I can never remember what should be merged! Do I merge a THIS and OTHER on to BASE?
<jam> vila: sure, I can see changing the numbering, but finding that while I need more-than-minimal but I need less-than-back to 1 makes it worth moving forward
<jam> I just wanted to make sure someone else agreed with my logic
<IslandUsurper> balor, THIS is your working tree, OTHER came from the merged branch, and BASE is what they have in common. So for each chunk, ask which change is more important, the one you had or the one you're getting.
<IslandUsurper> the tricky ones have some of each
<balor> So merge THIS and OTHER into each other
<IslandUsurper> right
<IslandUsurper> they're displayed together in the original filename
<balor> So what's the point of BASE?  What information does it give me?
<balor> As I get common chunks in the same colour in Meld
<IslandUsurper> if you diff BASE and either THIS or OTHER, you can see exactly what they changed
<balor> ah
<balor> thanks
<vila> jam: sure, sure, I'm very happy you work on *that* (reducing the cases requiring loading all the history)
<lifeless> jam: your logic ?
<jam> full discussion is in the text file in my lp:~jameinel/+junk/history-db branch.
<jam> basically,
<jam> for simple children, you just need to know there isn't another child
<jam> and then you can do X.Y.Z+1
<jam> for a new sub-branch
<jam> you need to know if there is an X.Y+1
<jam> to know that, you need to check all descendants merged into trunk from X.Y.1
<jam> sorry
<jam> all merges into trunk since X.Y.1 was merged
<jam> however, you don't care about when X.Y-1.* was merged
<jam> lifeless: ^^
<jam> maybe put another way
<jam> if you are walking backwards, you need to load X.Y.Z if it is a parent of yours, so that you can do any of X.Y+1.Z, or X.Y.Z+1
<jam> to determine which
<jam> you need to load the children of X.Y.Z
<jam> if there are no other children, you can do X.Y.Z+1 and do no further loading
<jam> if there is one
<jam> then you need to load from X.Y.1 to determine any X.Y+1.1 that exist
<jam> (+N if you prefer)
<jam> The key is that you don't need to load from X
<jam> since anything landed before X.Y.1 was landed, will have have a second number < Y.
<lifeless> vila: can I purchase a review ?
<lifeless> jam: bzr+ssh://bazaar.launchpad.net/~jameinel/%2Bjunk/history-db/ - not a branch
<jam> lifeless: sorry bzr-history-db
<jam> lp:~jameinel/+junk/bzr-history-db
<lifeless> so, 'only the right hand side *children* of X can influence revision numbers X.*.*' ?
<jam> lifeless: I'm pretty sure only lh children
<jam> sorry
<jam> you were saying X
<jam> children of X with X in their LH history will be numbered based on it, yes
<jam> the way the data is stored in the dotted_revno table today does affect things
<jam> you need to know that a child of X is in the ancestry of the current branch
<jam> just being a child doesn't affect X.*.* for *this* branch
<lifeless> sorry, I should have said 'rh parents of X'
<jam> lifeless: rh parents of X have no affect
<jam> X is the ancestor of X.*.*
<jam> it is, specifically, a LH ancestor
<lifeless> jam: https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/22848
<lifeless> jam: vila: https://bugs.edge.launchpad.net/bzr/+bug/530265
<lifeless> do you guys have a preference between
<lifeless> *) a line to delete
<ubottu> Launchpad bug 530265 in bzr "Not modifying a suggested commit message commits anyway" [Medium,Confirmed]
<lifeless> *) a y/n prompt if the message is the unaltered template
<jam> lifeless: If we are being interactive enough to pop up an editor
<jam> I think it is ok to prompt for a "did you really want to commit an empty message" ?
<jam> lifeless: the mutter() seems fine
<jam> I'm trying to understand the revprops chacheng
<jam> change
<lifeless> oh
<lifeless> I had it in my commit branch; it just reduces some cruft
<jam> you are removing it from _commit, but adding it to the constructor?
<lifeless> shorter parameter list
<lifeless> its already in the constructor
<lifeless> its an internal handoff within the object
<lifeless> so just changing where it becomes an attribute, to spend less time passing it around
<jam> it would seem reasonable to do that to all the other ones as well then...
<jam> so... not a problem, but incomplete one way or another
<lifeless> yup
<lifeless> If I end up doing much more to commit I'll probably do the rest too
<lifeless> its a bit ugly as it stands
<jam> anyway :approve
<lifeless> thanks
<lifeless> re prompt/message
<lifeless> I guess I feel that its cleaner to only interrupt the user once
<lifeless> GUI's can check in the dialog
<lifeless> hmmm
<lifeless> jam: whats the current open bzr version on trunk ?
<lifeless> assign to milestone is showing about 15 things, rather than 3
<lifeless> <- confused bear of small brain
<jam> lifeless: either 2.2.0 or 2.2.0b2 I believe
<lifeless> so commits in trunk will still be 2.2 ?
<jam> well, 2.2b2
<jam> yes
<lifeless> kk
<lifeless> can we deactivate some of the others, do you think ?
<jam> From looking at it, they are all stuff in the future
<jam> not sure that we would disable them, but I suppose we could for now
<jam> unlikely to target them explicitly, but it can be nice to know when they are expected
<jam> (so not great in the bug UI, nice to have elsewhere)
<Talidan> Hi there, i was just reading http://wiki.bazaar-vcs.org/CherryPick
<Talidan> Cherrypicking is vital to our project, the idea is that other users can mirror our branch, make changes
<Talidan> and we can merge them if they're decent
<Talidan> i was just wondering what's meant by "Bazaar does not track cherrypicked revisions, although this feature is firmly on the wish list. "
<Talidan> ideally (currently im testing on launchpad) the person we merge from is credited with the change
<lifeless> I don't see why you need cherrypicking given your description of your idea.
<Talidan> well, we're thinking of migrating from GIT
<Talidan> which was hosted at github
<Talidan> there everyone (besides official mantainers) would open their own fork
<lifeless> right
<Talidan> andn push their changes to their own fork
<Talidan> and if we thought they were decent, we'd merge them over
<Talidan> my understanding is that it requires cherrypicking for bazaar
<Talidan> Bearing in mind their fork might have loads of crap we dont want
<lifeless> ah
<Talidan> we only select the commits that we actually want
<lifeless> so, you can use 'bzr merge -c rev'
<lifeless> which will do a cherrypick merge
<Talidan> i was just wondering what "does not track cherrypicked revisions" actually means
<lifeless> and commit --author "foo bar <foo.bar@example.com>"
<lifeless> it means we don't track them
<Talidan> mind elaborating?
<lifeless> uhm
<lifeless> I'm not sure where the disconnect is
<Talidan> track could mean a whole lot of things
<lifeless> there is no record kept of the fact that a particular commit was a cherrypicked merge.
<Talidan> Right, okay thanks
<lifeless> you can do cherrypick merges easily
<lifeless> (merge -c)
<lifeless> and if you commit with --author they will be credited appropriately
<lifeless> (in bzr merges never create commit objects, you need to do a commit after the merge)
<mwhudson> jelmer: ayt?
<Talidan> What windows GUI bzr client would you guys reccomend?
<jelmer> mwhudson: I am now
<Talidan> TortoiseSVN is the only Tortoise* i've had a good experience with, tortoisegit is a pile of rubbish, and tortoisehg is average
<mwhudson> jelmer: have you tested the kernel import on staging since last week?
<mwhudson> (with a new bzr-git & dulwich)
<jelmer> mwhudson: I don't have a way to update the dulwich/bzr-git on staging afaik :-)
<mwhudson> jelmer: well, "caused to be tested" then :)
<mwhudson> jelmer: you have the same mechanism as me!
<mwhudson> jelmer: do you think it would be a useful test at this stage?
<lifeless> Talidan: I hear good things about bzr-explorer
<Talidan> Thanks, i'll give it a go
<jelmer> mwhudson: ah, asking a losa ? :-)
<jelmer> mwhudson: There's one bug I noticed that I'd like to get fixed first (unusual modes disappearing doesn't seem to be handled right)
<mwhudson> jelmer: yeah
<mwhudson> jelmer: ok
<mwhudson> jelmer: any idea how long that'll be?
<jelmer> mwhudson: might be tonight, but there's a few other things I have to take care of first
<mwhudson> jelmer: okidoke
 * mwhudson continues applying the email shovel
<Talidan> i think it's an oversight to not have simple authentification given open source projects that dont need security but simplicity
<Talidan> or wiat, does bzr support user/pass?
<Talidan> i guess it's launchpad doesn't?
<lifeless> bzr supports user/pass
<lifeless> lp uses ssh and oauth
<lifeless> bzr doesn't support oauth yet
<lifeless> there is an interesting spec though
<lifeless> that google and others have done for oauth IMAP and SMTP
<lifeless> we could perhaps adapt that
<lifeless> lp doesn't maintain cleartext passwords though, so it wouldn't be easy to turn on plain ol password supoprt
<jelmer> lifeless: OAUTH over SASL, or using some different mechanism?
<lifeless> jelmer: I haven't read the spec for how they did it in IMAP yet
#bzr 2010-04-07
<igc> morning
<abadger1999> lkoggerhead question -- Is it possible to configure it to serve on a subdiretory?
<abadger1999> *loggerhead
<abadger1999> Like this:
<abadger1999> http://localhost/bzr/myproject/branch-foo
<abadger1999> I haven't been able to move it away from  this style of url http://localhost/myproject/branch-foo
<lifeless> abadger1999: yes, python-paste permits this
<lifeless> sorry pastedeploy
<abadger1999> lifeless: Do you know the config option I'd need to change?
<lifeless> not offhand
<lifeless> uhm
<lifeless> are you using WSGI, serve-branches or bzr serve --http ?
 * abadger1999 is also aiming to get this working with mod_wsgi... but that would come after getting it working at all.
<abadger1999> mod_wsgi is my goal but I've experimented with both of the others.
<lifeless> abadger1999: I wouldn't sequence things like that; just aim directly at your goal
<lifeless> wsgi apps can be layer
<abadger1999> lifeless: Alright -- mod_wsgi :-)
<lifeless> to do path manipulation etc in containing apps
<lifeless> look for PrefixMiddleware in serve-branches
<mwhudson> abadger1999: serve-branches --prefix should do that, how are you proxying to it?
<abadger1999> mwhudson: I'm not proxying.  My last bit of trying has been based on this: http://blog.projectfondue.com/2009/11/26/loggerhead-and-mod-wsgi
<mwhudson> abadger1999: then --prefix bzr should Just Work, i think
<abadger1999> lifeless: There's no PrefixMiddleware in serve-branches -- the wsgi script I was using has PrefixMiddleware(app, prefix='')
<abadger1999> Changing that to prefix='/bzr' didn't work out very well.
<abadger1999> It made the front page correct but links to subpages had no /bzr in the url.
 * abadger1999 tries serve-branches --prefix
<lifeless> hmm my trunk of loggerhead must be stale
<abadger1999> mwhudson: Pretty good.  It's interesting that it's serving on both /bzr and / but the links look consistent
 * abadger1999 looks at code
<lifeless> igc: $ bzr pull
<lifeless> Using saved parent location: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/
<abadger1999> I'm using the 1.17 release right now.
<lifeless> No revisions to pull.
<lifeless> my serve-branches has prefix middleware
<abadger1999> So it might be that things have changed since then
<lifeless> revno 345
<mwhudson> lifeless: that's not lp:loggerhead any more
<lifeless> mwhudson: oh
<lifeless> mwhudson: what is then ?
<lifeless> and why did it change?
<mwhudson> lifeless: i think it's called trunk-ric
<mwhudson> lifeless: and it was to do with upgrading to 2a
<lifeless> ugh
<mwhudson> it wasn't me
<lifeless> I do so hate that approach
<lifeless> no, I know
<lifeless> its the approach thumper and igc advocated, IIRC
<thumper> ?
<igc> lifeless: I agree it's annoying that lp:xxx can change and we don't follow the new location
<igc> I'm pretty sure there's a bug for that
<thumper> I think bzr should store the url for before and after resolution
<thumper> and warn the user if they change
<thumper> or something
<igc> thumper: it only stores the "after resolution" info right now
<thumper> igc: right
<lifeless> there is a bug about us storing the directory service url
<lifeless> however I'm complaining about the manner of upgrade where a new branch is used
<igc> lifeless: I got that
<lifeless> which does, I admit, interact with that bug.
<lifeless> however, even if we had fixed that bug, people following our docs that don't use launchpad would still have the same pain.
 * igc out for a few hours
<mwhudson> jelmer: looks like you fixed that problem you talked about earlier?
<lifeless> thumper: have you looked at any rich root branches rev 1 in loggerhead before ?
<thumper> lifeless: no, but I used diff locally
<thumper> lifeless: I'll check now
<thumper> it could be a bug in loggerhead
<lifeless> I branches the branch you're complaining about
<lifeless> it checks clean
<lifeless> st -r 0..1 is clean
<lifeless> diff -c 1 is clean
<thumper> weird
<thumper> ok, not a bzr-hg bug then
<lifeless> the / is simply the root id being added, its normal, and IMO not a serious bug that loggerhead shows it
<thumper> must be a loggerhead display bug
<abadger1999> mwhudson: Ah.... I vaguely remember this issue.
<abadger1999> mwhudson: For some reason loggerhead doesn't handle URLs without a trailing "/" quite right.
<abadger1999> mwhudson: With mod_wsgi and clicking on a directory of branches (as opposed to directly onto a branch), it goes to http://localhost/bzr/python-fedora <= no trialing slash
<abadger1999> mwhudson: That redirects to http://localhost/python-fedora/
<mwhudson> abadger1999: that's quite strange
<abadger1999> mwhudson: So something is dropping the '/bzr/' in there
<mwhudson> abadger1999: do you have a prefixmiddleware in your wsgi stack?
<abadger1999> mwhudson: Using serve-branches --prefix yields a slightly different issue.
<abadger1999> mwhudson: Yeah Letme upload the script
<mwhudson> abadger1999: what i know about mod_wsgi setup could fit quite comfortably on the back of a postage stamp, btw
<abadger1999> http://toshio.fedorapeople.org/loggerhead.wsgi
<abadger1999> This line probably isn't needed: os.environ['loggerhead.static.url'] = '/bzr'
<abadger1999> mwhudson: So serve-branches.... I invoke it like this:  serve-branches --prefix bzr /var/www/bzr
<abadger1999> mwhudson: Then if I browse to http://localhost/bzr  <= No trailing slash
<abadger1999> mwhudson: There's no /bzr/ in the urls
<mwhudson> abadger1999: i know that pastedeploy expects that the /bzr part of the path is in the script_url in the environment that it sees
<mwhudson> abadger1999: is that something you can control from the mod_wsgi side?
<mwhudson> maybe i mean path_info there
<abadger1999> mwhudson: Hmm... Let me see if I can
 * abadger1999 knows how to do that for TurboGears apps
<mwhudson> jelmer: ayt?
<abadger1999> mwhudson: Huh.... I'm a little bit stumped... I've got script_name as /bzr and path_info as /stats/changes or etc... seems to work.
<mwhudson> abadger1999: hmm
<abadger1999> mwhudson: But when I go to /bzr/python-fedora my instrumented wsgi script doesn't seem to get invoked at all.
<mwhudson> well working > understanding i guess :)
<mwhudson> ah
<abadger1999> And that gets redirected to /python-fedora where it fails.
<mwhudson> that sounds like an apache/mod_wsgi problem then?
<abadger1999> So ....  it seems like something is doing the redirect before the wsgi app.
<abadger1999> I'm going to pursue that until I find out different :-)
<abadger1999> mwhudson: Okay... this gets stranger although it's still not looking like loggerhead's fault => firefox doesn't work but wget redirects correctly.
<mwhudson> abadger1999: sounds like you either need to go to bed or get drunk :-)
<abadger1999> mwhudson: yeah, I'm going to second that.
<abadger1999> Thanks for the help!
<mwhudson> abadger1999: np
<fullermd> Why is this an "or"?  Does nobody have the foresight to have a wet bar built in to the nightstand?
<AndrewLuecke> G'day, does bazaar have a way to restrict&control SSH access?
<AndrewLuecke> aah.. nevermind..
<AndrewLuecke> Got it ..
<igc> back
<mwhudson> igc: hi
<igc> hi mwhudson
<mwhudson> igc: i just wanted to encourage you to just make/land changes to loggerhead trunk if you feel they are improvements
<igc> mwhudson: ok. I'm hoping to start looking at the loggerhead stuff any day now - building a Windows 2.2 installer currently
<mwhudson> igc: ah ok
<mwhudson> igc: loggerhead should be more fun than that :)
<igc> mwhudson: I've been reading up on WebOj and Chameleon while up at the hospital in recent days as well
<igc> mwhudson: yes :-)
<mwhudson> i've been feeling bad for being a slack maintainer lately, and it looks like i'll be getting even less time for it
<mwhudson> igc: i think chameleon is probably a pure win if we can keep streaming
<mwhudson> simpletal is kinda horrible
<igc> mwhudson: np. I'll be sure to ping you asking for advice if I have any concerns about changes
<mwhudson> igc: cool
<igc> mwhudson: yeah, I find TAL+TALES+METAL a lot less readable than jinja2 but I'll survive :-)
<igc> mwhudson: I'm curious about the stability issues as well
<mwhudson> well if you want to rewrite all the templates...
<mwhudson> igc: so are we all, i think
<igc> mwhudson: is there a 60 second summary of what not to touch, e.g. the threading code?
<mwhudson> igc: i'd consider most of it fair game i guess :)
<mwhudson> igc: the code for the url dispatch, information gathering and rendering stages is fairly separate
<mwhudson> igc: the problems tend to be in the middle stage, unsurprisingly, so it's probably best to at least be careful there
<igc> mwhudson: by middle, you mean "info gathering"?
<igc> the "interfacig to bzrlib" bit?
<mwhudson> igc: yes
<igc> mwhudson: ok
<mkanat> I'm seeing a lot of what seem to be spurious merge conflicts when I try to update a bzr branch from Bugzilla 3.4 to Bugzilla 3.6.
<mkanat> Perhaps there's some documentation that I haven't read?
<AndrewLuecke> Sorry to bug you guys again.. But we are branching a SVN tree into bzr, and would like to still be able to pull off their tree, as well as maintain history.. I assume  bzr-svn is the best way of doing this?
<mwhudson> AndrewLuecke: yes
<AndrewLuecke> ok.. cool..
<AndrewLuecke> This is SOOOO much nicer than mercurial's and gits way of doing it
<AndrewLuecke> I've spent the last 4 days on this.. And this is soooo streamlined
 * AndrewLuecke has become a fanboy suddenly
<igc> hi bialix
<bialix> hi igc!
<bialix> glad to see you
<igc> bialix: ditto
<bialix> I've used explorer yesterday on colo workspace. nice work with context menu
<igc> bialix: if you get some time soon, can you try the latest bzr-windows-installers scripts?
<bialix> I think we need even better support for colo
<igc> +1 from me on that
<bialix> igc: perhaps on weekends only
<bialix> is it ok for you?
 * bialix trying to finish main work to be able attend UDS
<igc> bialix: whenever suits you is good. I'm trying to get a bzr 2.2 build with Python 2.6 (and I'm struggling)
<bialix> igc: I need to make auto-generated en.po translation to be LF-only as well. is it still a problem?
<igc> bialix: no, I think the problem is elswwhere
<igc> elsewhere
<bialix> python 2.6... I've tried to avoid it in my work, just because there is some struggles with py2exe
<igc> my current struggle is probably something to do with how py2exe is configured
<bialix> igc: will be nice if you send me a mail closer to weekend and highlight the moments I should check/help
<igc> there's a PyQt4.uic.port_v3 on the filesystem but py2exe is falling over becuae it con't find it
<bialix> there is not much configuration knobs in the py2exe
<bialix> maybe env path
<igc> bialix: hmm - maybe I need to look there
<igc> bialix: i'ts very frustrating when it fails because it gives you so little to work out what's wrong :-(
<bialix> igc: there is something like debug output in py2exe, at least it can generate full dependency graph for you
<bialix> igc: which version of PyQt I should use?
<igc> I'm trying to build with Python 2.6.5 and PyQt 4.7.2
<igc> bialix: ^^^
<bialix> ok, I'll grab those
<igc> bialix: thanks
<igc> bialix: with rev 108 of bzr-windows-installers, the command to run is ...
<igc> build.py installers --standalone-only
 * bialix nods
 * bialix has pyqt 4.7.0 as well
<lifeless> thumper: https://edge.launchpad.net/codewiki
 * igc dinner
<vila> lifeless: heads-up, feed-pqm doesn't prefix your commit messages with (lifeless)
<lifeless> vila: interesting; file a bug on hydrazine please
<vila> lifeless: I don't think so, we tend to use a rather liberal prefix there (mbp, for parthm) for example
<lifeless> vila: if we were to fix this, where would it get fixed?
<vila> lifeless: we never fixed pqm-submit, why should we fix feed-pqm ? :->
<lifeless> because a smooth toolchain is nice to work with
<lifeless> so I repeat
<lifeless> vila: if we were to fix this, where would it get fixed?
<vila> lifeless: educate the user :)
<lifeless> vila: I don't understand why you don't want this automated.
<vila> lifeless: if that doesn't work, joking, let me finish :)
<vila> it that doesn't work, then either pqm or feed-pqm, probably the later, but the rules need to be defined, like, generate a prefix only if none are present and put... username there?
<lifeless> vila: this, file a bug
<lifeless> *thus*
<lifeless> and yes, hydrazine for now, I think
<ezod> suppose a remote (upstream) bound branch is at revision N, and i make a local commit, so i'm at revision N + 1, then i run bzr update, putting me back to N
<ezod> is there any way to get revision N + 1 changes back?
<awilkins> ezod, update again (presuming you did an update to -r -2 to get to N)
<ezod> no, rev N + 1 was local only
<ezod> will this work:
<ezod> bzr pull . --overwrite -r revid:<N+1>
<ezod> perhaps?
<awilkins> ezod, try `bzr heads` to find the revision number
<ezod> `bzr heads` doesn't return anything
<ezod> oh
<ezod> bzr heads --dead does
<awilkins> ezod, find your revision and pull that
<ezod> revid is email-timestamp-string
<ezod> ok cool, will try
<awilkins> bzr pull -r revid:<blah>
<ezod> awilkins: thanks, seems to have worked :)
<c_korn> hello, how can I fix this error ? http://pastebin.com/XVcmjnWg
<awilkins> c_korn, You need to upgrade the remote repository
<awilkins> I believe there's a button in LP for that
<awilkins> Or take a local branch that isn't rich-root
<jam> morning all
<jam> hey vila, I got most of the merge_sorted stuff working
<jam> some edge cases that i want to write tests for first
<vila> jam: morning jam !
<vila> jam: good work !
<vila> jam: so youwant to write test first ? :-P
<jam> I do that sometimes :)
<jam> seriously, when it is tricky edge case stuff, I usually do
<jam> to make sure that I'm actually exposing the code I think I ame
<jam> am
<vila> yeah, that's the idea ;-)
<vila> by the way, have a look at bug #489179
<ubottu> Launchpad bug 489179 in bzr "log file -v misses some revisions" [Low,Confirmed] https://launchpad.net/bugs/489179
<vila> jam: not for the bug itself, bug look at revno 4081.2.2 with qlog
<vila> jam: Iwas surprised by the revno numbering here, as if daggy fix could somehow violate the stability,
<vila> jam: I didn't dig but thought you may be interested
<jam> daggy shouldn't affect numbering
<c_korn> awilkins: ok, I think I found the button.
<c_korn> this is it I think: http://www.ubuntu-pics.de/bild/50919/screenshot_001_4B7Mnw.png
<vila> jam: I realize that, but just have a look
<awilkins> c_korn, You might want to warn the rest of the dev team :-)
<c_korn> awilkins: yes, I am currently doing this
<jam> vila: so what am I looking at wrt 4081.2.2 ?
<jam> vs log file -v ?
<jam> I see a lot of files merged in 4081.2.2, but that is expected, since it is all of 5112-4081 from bzr.dev being merged in one go
<vila> jam: just a sec, killed the wrong qlog seconds ago
<jam> if you are wondering about the revno, it is because they merged bzr.dev into the changelog branch, not based the changelog branch on bzr.dev
<vila> jam: ha, right, twice, I've been tricked by qlog for the other case but it's right here :-)
<vila> jam: I think my initial surprise was more about the -n0 -v revno being so far away from the revs shown by -n0, but that may just be the revno scheme after all
<jam> I don't quite understand "the -n0 -v revno"
<jam> when I do "bzr log -v -r 4081.2.2" w/ bzr.dev, I only get the one rev
<Lo-lan-do> Hi all
<jam> morning Lo-lan-do
<Lo-lan-do> jelmer: I think I found a race condition in bzr-svn the hard way :-(
<jelmer> Lo-lan-do: hmm?
<Lo-lan-do> Someone did an svn commit just as I was starting pulling a branch onto my bzr checkout
<Lo-lan-do> SVN did record both his revision and my series (of 21) revisions, but now I get an assertion error in my bzr checkout
<Lo-lan-do>  File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/branch.py", line 484, in get_rev_id/assert revmeta.get_revno(mapping) == revno
<Lo-lan-do> Okay, I removed revprops, uncommitted and pulled again, and now I'm fine again.
<jelmer> Lo-lan-do: his changes interrupted your push of a serie of revisions?
<Lo-lan-do> Unfortunately not.
<Lo-lan-do> I think his commit happened between the time bzr had read the existing revprops and the time bzr started pushing.
<jelmer> Lo-lan-do: but it's now interwoven with your changes?
<Lo-lan-do> SVN's revision history was, say, 100-101-102-103, with 101 being my coworker's commit and 102-103 being mine
<Lo-lan-do> But bzr log only displayed 100-102-103
<Lo-lan-do> 102 had 100 as its parent bzr-wise
<jelmer> bug 515850
<ubottu> Launchpad bug 515850 in bzr-svn "Revisions added while a commit is happening are ignored" [High,Triaged] https://launchpad.net/bugs/515850
<Lo-lan-do> Sounds like exactly that, indeed :-)
<Lo-lan-do> Sorry for the interruption.
<tyarusso> I know this is an odd request, but does anyone have a side-by-side technical comparison of bzr against RCS?
<jelmer> Lo-lan-do: np, it is an important bug to fix
 * jelmer waves to jam, vila
<jelmer> tyarusso: hi
<jelmer> tyarusso: I'm not aware of one - the major difference seems to be that RCS is per-file, Bazaar versions an entire tree
<tyarusso> hey jelmer
<jelmer> tyarusso: I'm not sure if that helps at all.
<jam> morning jelmer
<tyarusso> dunno
<tyarusso> The main thing that annoys me with RCS is that the revision files aren't "hidden", so directories get really cluttered.
<jelmer> jam: looks like I'll need packs for bzr-git's cache anyway
<jelmer> jam: group compress doesn't rely on parent information right?
<jelmer> jam: (for performing well, I mean)
<jam> jelmer: correct
<jam> though you need some sort of 'grouping' key
<jam> atm we use file-ids and sort them
<jam> which often works pretty well
<jelmer> that's fine, I'd want Git paths in that case
<tyarusso> What happens if you do a bzr init in a directory that already has a repo going?  (For instance, if you have a bunch of scripts that want to version something in /etc, and they don't know which script will run first. (not using etckeeper))
<jam> well, you'd want filenames not paths, I would guess
<jam> or reverse paths or something
<jam> all files in a dir don't often compress as well as all files named Foo
<jelmer> jam: Sorry, that's what I meant
<jelmer> it's the same key that git uses to compress its packs
<jelmer> jam: Basically, I'd like to cache git Tree objects and Blob objects for symlinks
<RobOakes> Morning everyone.  I am trying to push a bzr branch into an empty svn repository (for backup/collaboration purposes).  However, when I run bzr push https://path/to/repo, it tells me that the branches have diverged.
<RobOakes> Does anyone know how I can push my local branch to the remote server with bzr-svn?
<tyarusso> This there a way to give each versioned file a description?  For instance "Config file for MySuperCoolProgram".
<jelmer> RobOakes: your bzr branch has a different history than an empty svn branch (which has exactly one commit on it)
<jelmer> RobOakes: If you push to a location that doesn't exist yet things should work
<RobOakes> For example: http://server/repo/subdir?
<jelmer> yeah
<jelmer> provided subdir doesn't exist yet
<RobOakes> Oh, that worked great.  Thanks!
<Torne> is it intentional that pressing 'f' in the builtin shelve command selects "yes" for all remaining hunks?
<Torne> it seems much more logical for it to select "no", since that's the default
<msmith> hello everyone, i have a question about bzr-svn on debian
<msmith> when installing on debian using apt-get i get the following:
<msmith>  bzr-svn: Depends: bzr (< 1.6~) but 2.0.3-1~bpo50+1 is to be installed
<tyarusso> I suppose I *could* create a local branch for each file and name those, but that seems a little silly.
<msmith> is there a repository i can add to my sources.list that would contain an updated version?
<Peng> msmith: Yes, unless the repository is out-of-date too.
<Peng> Don't have a link right this second, though.
<Peng> msmith: Try https://launchpad.net/~bzr/+archive/ppa, or possibly https://launchpad.net/~bzr-svn/+archive/ppa or something
<Peng> IIRC there is a bzr-svn ppa, but I don't remember the link. :-\
<Torne> msmith: which version of debian are you using? all versoins should have a matching bzr-svn for the bzr they have
<Torne> msmith: it looks like you maybe installed bzr from somewhere else
<Peng> Err, right, Debian. The PPA's out, then...
<Peng> Sorry.
<msmith> :)
<Torne> msmith: ah, you have bzr from lenny-backports
<Torne> msmith: there's no bzr-svn backported to lenny.
<Torne> either install the testing/unstable version of bzr along with all its dependencies, and the matching version of bzr-svn from testing/unstable, or downgrade to the lenny version of bzr, or build your own package..
<Torne> (or ask someone else for a backport :)
<msmith> ok, thanks.  i'll try to follow that path and scream for help if i fall off a cliff
<krisives-gearbox> I have 2 branches that didn't start as the same code, but I'm trying to get them to be equal. I've made both a bzr repo and added all the files. What strategy should I use to try and get them to be equal?
<rellis> Is there a way to get a commit history for a particular user with bzr?
<krisives-gearbox> http://superuser.com/questions/128540/bazaar-merge-identical-files
<vila> krisives-gearbox: you should put one branch under bzr and then, override all the files with your second branch and finally do 'bzr diff'
<krisives-gearbox> override>
<krisives-gearbox> ?
<vila> copy over
<krisives-gearbox> if I do that in a new area I can then push/pull those diffs into one of the original to make them all equal
<vila> when a file is first added to a branch, it receives and unique ID, if you so that in two different (unrelated) branches, the "same" file get a different ID, when your try to merge bzr then see them as different and move one away (.moved)
<vila> s/and unique/ a unique/
<vila> meh s/so that/do that/
<vila> krisives-gearbox: you can't start with two different histories, that's the so-called "parallel import" problem which is yet to be addressed by bzr
<krisives-gearbox> One issue with that strategy though
<krisives-gearbox> I want to end up with 2 bzr repos
<krisives-gearbox> nvm I think I figured it out, I'll let you know how it works
<vila> krisives-gearbox: are you sure you don't mean two branches here ? A repo for bzr is just a place to put revisions used by one or many branches
<krisives-gearbox> bzr init creates a repo, right?
<krisives-gearbox> I probably have that wrong
<vila> 'bzr init' creates a branch, a branch uses a repo, if no repo is available to be shared, 'bzr init' will create one for the branch itself, but if you intend to use several branches, you use 'bzr init-repo project' and then 'bzr init project/trunk' and 'bzr init project/feature' etc
<vila> trunk and feature will then share the repo created for project
<krisives-gearbox> whats the diff between merging repos and branches? or does that question not make sense?
<vila> krisives-gearbox: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief is pretty quick to read
<krisives-gearbox> thanks
<vila> krisives-gearbox: you merge branches, repos come into play in the background, you rarely use them directly
<krisives-gearbox> ok
<vila> krisives-gearbox: 'bzr reconfigure' can also be used if you change your mind about your branches layout
<krisives-gearbox> I'm still thinking it out hehe
<krisives-gearbox> I'm integrating bzr so we can keep client sites up to date
<krisives-gearbox> The old system is a hacked PHP upload script garbage blah
<vila> "Whatever works" he said :)
<krisives-gearbox> Randomly, is there a way to tell `cp` not to copy a specific directory in a recursive?
<vila> krisives-gearbox: randomly: cp everything somewhere, delete the offending dir, cp the result ?
<krisives-gearbox> good idea
<vila> krisives-gearbox: 'tar' has more options, but it's also a bit harder to use it to just copy files around
<Peng> You could use rsync. But, again, way complicated.
<krisives-gearbox> I think I'm going to do from/* to avoid getting the .bzr
<krisives-gearbox> cp -r from/* to/*
<Peng> krisives-gearbox: Use "bzr export" to get a copy of a working tree somewhere.
<krisives-gearbox> usually would, but doing an "override"
<Peng> krisives-gearbox: A repository is just a big bag of revisions. They can be from related branches or not. There's really not much to think about there.
<jelmer> jam: what's this history db thing you're working on?
<jam> jelmer: caching the dotted revno / merge sorted graph
<jam> I've posted some of the results to the list
<jam> The basic idea: a dotted revno cache can be shared between branches
<jam> as long as you store it based on the mainline revision
<jelmer> ah, nice
<jam> you can store it completely clustered (only new info per new mainline rev) as long as it is fast to expand
<jam> in the process
<jam> I also think I can *compute* the merge_sort graph fairly efficiently for new revisions
<jam> I think I've found solutions for everything
<jam> such that nothing is O(history)
<jam> most things are (at worst) O(history since you branched from)
<jam> some interesting other results, though
<jam> like loading the whole ancestry of mysql in 80ms or so
<Peng> Wait, where would this be implemented? bzrlib? A plugin? Something Loggerhead can steal....? :>
<jelmer> jam: ooh, that sounds pretty nice :-)
<jam> Peng: it is currently a bzr plugin, and inspired from some of the needs of loggerhead and some other bits
<Peng> <3
<jam> also from codehosting
<Peng> Granted, it would take more than this to fix Loggerhead's issues, but... :P
<jam> where I'm told there is a table that stores "what revisions are in the ancestry of this revision" for all revisions
<jam> Peng: well the root idea was that loggerhead loads the whole history graph when it often doesn't care
<jam> so how do we store it
<jam> in such a way that we can read only parts of it
<jam> and how can we make that efficient against N branches
<jam> etc
<Peng> Ah. So this could be plugged into a lot of Loggerhead?
<jam> Peng: it would replace the RevisionCache, IIRC
<jam> you get to keep dotted_revnos in the api
<jam> without having them be 2s to compute per branch
<jam> get_dotted_revno() for an old revision in mysql takes 13ms
<jam> for a new revision, it si about 5-10ms
<jam> And I *think* that will scale 'out', where you ask for multiple dotted revnos in a single pass
<jam> so it shouldn't be 26ms for 2 dotted revnos, but more 14ms or s.
<jam> so
<jelmer> jam: what's the status on your pack collection work, is it ready to use in its current form?
<jam> not yet
<jam> I got distracted by this
<Peng> We need to get you to collaborate with yourself from an alternate universe to get both done at once. :)
<jelmer> jam: ok
<pyMynx> anyone there? ^^
<Peng> Possibly!
<krisives-gearbox> Thanks again for the help vila
<lifeless> jam: before you wrap for the day, could I beg a review?
<mwhudson_> jelmer: slightly obscure bzr-git kernel import failure leads to finding a sha1 problem: http://staging.launchpadlibrarian.net/42124151/mwhudson-linux-trunk.log
<jam> lifeless: of?
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/22920
<lifeless> jam: ^
<jelmer> mwhudson_: That's rev 58, caused by an issue with unusual modes. I'm working on it at the moment.
<mwhudson_> jelmer: ahead of me as usual :)
<pyMynx> I'm pushing a folder to a server
<pyMynx> but the folder on the server is empty after push
<pyMynx> all I have is a .bzr folder
<pyMynx> :(
<jelmer> pyMynx: yes, bzr push does not create a working tree
<jam> lifeless: 1) I'm pretty sure the "msg_transport.get_bytes()" is unnecessary as the rest of the code certainly expects 'msgfilename' to be a local object that you can open()
<lifeless> jam: yes, but that needs try:finally:close9)
<jelmer> pyMynx: you can use the push-and-update plugin to keep the working tree up to date
<pyMynx> jelmer: how should I create the branch on the server? I thought I had to push through sftp like in the tutorial
<pyMynx> jelmer: oh ok
<lifeless> 5 lines, twice, or local function, vs 1 line twice + a 2 line setup
<jelmer> pyMynx: bzr push creats a branch (including all history) but not a working tree
<lifeless> if we had with, open would be fine.
<jam> lifeless: also, you return "" if get_boolean() returns false. Shouldn't you be returning None ?
<jam> like the other code path does
<lifeless> actually
<lifeless> its mixed
<lifeless> some code paths return None
<lifeless> some return ""
<lifeless> if you return None, it raises 'please specify a message via --file or --message'
<lifeless> if you return "" you get 'empty commit message supplied'
<lifeless> which is a more appropriate error
<lifeless> I'll add a comment
<jam> lifeless: bb:tweak
<jam> lifeless: you also don't have a test case that shows that giving "n" actually cancels the commit
<lifeless> sure, I can add one.
<pyMynx> jelmer is that the only way? with the plugin? ...i'm following the instruction but it says lp:bzr-push-and-update does not exist yikes!
<Peng> pyMynx: lp:~bzr/bzr-push-and-update/trunk WFM
<pyMynx> other way to create workingtree on server? :(
<Peng> SSH? :D
<mwhudson> bzr upload is another option, but it's rather different
<Peng> pyMynx: Why are you asking for anotehr solution? What's wrong with bzr-push-and-update?
<mwhudson> jelmer: oh, that reminds me, what are the names of the bzr-git caches now?
<pyMynx> Peng: I can't install the plugin damn... maybe it's just me
<jelmer> mwhudson: everything is in git/ basically
<jelmer> mwhudson: .bzr/repository/git/ that is
<mwhudson> jelmer: ok
<Peng> pyMynx: What error message do you get?
<Peng> Hold on.
<jelmer> mwhudson: I can give you more specific names if that helps, but supporting git/ would avoid having to play catch up in the future
<Peng> pyMynx: Do you have the built-in launchpad plugin disabled for some reason?
<mwhudson> jelmer: supporting git/ is probably easy enough
<pyMynx> Peng: I've placed the folder inside the plugins folder, but for some reason it doesn't come up when I type bzr plugins
<Peng> pyMynx: Did you name it "push_and_update"?
<pyMynx> Peng: no, I'll try it now
<Peng> pyMynx: Bazaar plugins, like all Python modules, can't have - in their names.
<pyMynx> Peng: worked :|
<Peng> yay
<pyMynx> Peng: :D thank you very much!
<pyMynx> Peng: btw sorry if I ask, but does the plugin automatically work when I do push or do I need to type something else? because the docs I found seem very short
<Peng> pyMynx: It works automagically.
<Peng> pyMynx: But only if a working tree already exists.
<pyMynx> Peng: lol
<pyMynx> Peng: in local?
<Peng> pyMynx: No, in the location you're pushing to.
<pyMynx> Peng: all I did was follow the tutorial doing, bzr init, add and then after commit something
<Peng> ...
<Peng> What are you trying to accomplish?
<Peng> Why do you need working trees on servers?
<pyMynx> I have a workingcopy of this site on my desktop
<pyMynx> I would like to have the same repository on the server
<pyMynx> so whenever I change a few things that I like, I push the changes onto the server
<Peng> Does the server need a working tree, or just the Bazaar data?
<pyMynx> Peng: the server needs all the files in my folder
<pyMynx> Peng: I'm sorry for being a pain :)
<Peng> pyMynx: Well... if bzr is installed on the server, and a working tree exists, it'll all work automagically.
<Peng> pyMynx: If a working tree doesn't exist yet, you need to SSH into the server and run "bzr co" in the branch's directory.
<pyMynx> Peng: bzr co should make a tree automatically?
<Peng> ...
<Peng> cd to a branch without a tree, run "bzr co", and it'll make a tree.
<pyMynx> ok thanks
<pyMynx> on it!
<pyMynx> Peng: nightmare :| no module XMLSerializer
<mwhudson> jelmer: +0000 vs -0000 ? argh!
<jelmer> mwhudson: yeah, nasty one :-)
<jelmer> mwhudson: I need to figure out if git consistently uses -0000 or if it writes +0000 sometimes as well
<jelmer> yeah, it seems inconsistent
<jelmer> committing manually I can only get it to write +0000
<mwhudson> boo :/
<mwhudson> another revprop then?
#bzr 2010-04-08
<jelmer> mwhudson: looks like it; and an API breakage in dulwich as we currently use an integer offset
<mwhudson> jelmer: you could use a float i guess, then you have a negative zero :-)
<mwhudson> (not serious)
<jelmer> actually, I think we might already be using a float
<jelmer> mwhudson: can you perhaps re-review https://code.edge.launchpad.net/~lifeless/bzr-git/bug-526133/+merge/22986 ?
<mwhudson> jelmer: i think i already merged it in fact
<mwhudson> jelmer: the diff is empty, in any case
<jelmer> mwhudson: oh
<jelmer> mwhudson: ah, you're right
<jelmer> I guess launchpad didn't pick that up because it was proposed for merging into lp:bzr-git
<mwhudson> does anyone know where the
<mwhudson> /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<mwhudson> messages are coming from?
<millun> hi
<millun> is it ok if i add like 4000 .xml files (to a colocated branch) that i will never modify?
<beuno> millun, what do you mean by "is it ok"?
<millun> is it a good practice? :)
<millun> the thing is that i don't know how to untick so many files in bzr gui app
<igc> morning
<millun> (at once)
<lifeless> mwhudson: I smell eggs
<spiv> Good morning.
<lifeless> mornink!
<spm> lifeless: I trust you also smell bacon with those eggs, and you merely left off that part of the description because: 1. it's implied and 2. you're in too big a hurry to eat the bacon and hence the additional description typing time cuts into the bacon eating time. ??
<cody-somerville> and... how do you smell cooked egg?
<spm> cody-somerville: with your nose? :-)
<abadger1999> mwhudson: Got loggerhead working with mod_wsgi -- needed this patch https://bugs.launchpad.net/loggerhead/+bug/557737
<ubottu> Launchpad bug 557737 in loggerhead "Content length needs to be a byte string" [Undecided,New]
<abadger1999> The error from last night is some problem specific to firefox  I haven't tracked it down yet but it's gone away for now.
<lifeless> spm: no, python eggs.
<mwhudson> abadger1999: !
<lifeless> wow
<mwhudson> at least the fix is simple
<lifeless> mwhudson: will you apply this ?
<abadger1999> yeah
<mwhudson> lifeless: i can't see why not
<lifeless> mwhudson: ok cool
<lifeless> otherwise I would be happy to
<mwhudson> lifeless: feel free
<Peng> Rock paper scissors for who gets to land the trivial patch!
<Peng> I pick paper.
<abadger1999> :-)
<Peng> If someone else does it, don't forget --author. :D
<Peng> And --fixes! I always forget --fixes...
<Peng> Wait wait, lp:~toshio? Don't you have some other branch up for review from like...2008? :D
<Peng> https://code.edge.launchpad.net/~toshio/loggerhead/mod_wsgi/+merge/1168 Yeah, 2008. Nice.
<abadger1999> Peng: yeah -- it's work on doing this same thing from a long time ago.
<abadger1999> Peng: Things have progressed on all fronts :-)  This is the only byte string problem I found this time around.
<Peng> Ah, right, it ran into Unicode issues and then got dropped.
<Peng> abadger1999: Nice.
 * abadger1999 crosses fingers
<Peng> Seriously, who's landing the patch?
<lifeless> Its landed.
<Peng> OK.
<abadger1999> Thanks!
<Peng> Eh. Does Loggerhead use Fix Committed or Fix Released for this?
<lifeless> Peng: In the absence of clear docs, it can get by with the bzr idioms.
<Peng> :D
<lifeless> besides which
<lifeless> the solution for needing 'fix committed in trunk' is to release often.
<Peng> Naw, releasing is silly. Just make users run from version control.
<lifeless> it would be cool if pulling into bzrlib upgraded the bzrlib doing the pull as it pulled
<Peng> And then you get bizarre API compatibility issues. I've had that happen.
<Peng> I imagine reload()ing half of bzrlib would make a huge mess.
<lifeless> don't forge the pyrex
<spiv> Peng: reload() isn't sufficient on its own anywy
<Peng> If you like pain, work on Loggerhead's caching or hpss optimization, not this. :P
<Peng> (Or try wearing a corset. Sorry.)
<mkanat> mwhudson: Did you see my question on the hang bug?
<mwhudson> mkanat: yeah, but i don't have an answer for you
<mkanat> mwhudson: Okay.
<Peng> Eh? Link?
<mkanat> mwhudson: BTW, part of my contract is a retainer for me to do bug-fixing on an hourly basis for other bugs.
<Peng> (NMot that I'll have an answer either.)
<lifeless> mkanat: cool
<mkanat> mwhudson: I don't know if you have to run it by Francis or not, but personally I'm happy to look at and fix any bug. I know there are some that are hitting us pretty hard at Mozilla.
<mkanat> lifeless: Cha.
<mkanat> lifeless: Did you see the bzr bug I filed yesterday?
<lifeless> possibly
<mwhudson> mkanat: there have been a couple of further crashes, i should post them to the bug...
<mkanat> lifeless: The one about CVS having better merging behavior than bzr.
<lifeless> oh
<lifeless> I saw it go by
<lifeless> I haven't looked into it
<lifeless> uhm
<Peng> CVS does something better? Oh, that's terrible.
<lifeless> is there a SSCCE with it ?
<mkanat> lifeless: SSCCE?
<mkanat> lifeless: Oh, yes.
<lifeless> Peng: usually when we investigate merge issues it turns out to be a valid-conflict that cvs punts on
<mkanat> lifeless: There's a series of commands that will reproduce it with the same content from both bzr and CVS.
<lifeless> mkanat: have you tried --weave?
<mkanat> lifeless: Yeah, I tried all three.
<mkanat> lifeless: IIRC, there was 0 difference.
<mkanat> lifeless: Okay, there's a tiny difference. 81 conflicts with LCA, 105 with merge3, and 108 with weave.
<mkanat> Oh, though 83 with --weave --reprocess.
<mkanat> (Same with --merge3 --reprocess.)
<mkanat> Here's one of the "conflicts": http://pastebin.org/140807
 * spm waves hi to mkanat, passing thru
<mkanat> Hey spm. :-)
<lifeless> mkanat: what was the base
<lifeless> (--show-base)
<mkanat> lifeless: The top one.
<lifeless> no, thats orig
<mkanat> lifeless: http://pastebin.org/140815
<lifeless> mkanat: so bzr saw two different inserts
<mkanat> lifeless: Hmm, maybe it did.
<lifeless> branch one went from "" to "foo\n"
<lifeless> and branch two went from "" to "bar\n'
<mkanat> lifeless: So why doesn't CVS conflict there?
<lifeless> how are you doing the merge in CVS ?
<mkanat> lifeless: cvs up -dP -rBUGZILLA-3_6-BRANCH
<mkanat> lifeless: That particular conflict is from another nearly identical example to the one in the bug.
<lifeless> ah
<lifeless> its not a merge.
<mkanat> lifeless: Right, it's an upgrade. But bzr behaves the same way with "bzr up" as it does with "bzr merge".
<lifeless> right
<lifeless> because its actually merging
<lifeless> here is what CVS does:
 * mkanat nods.
<lifeless> BASE == 'bzr revision-info'
<lifeless> ORIG == current tree
<lifeless> (or THIS == current tree)
<lifeless> OTHER == -rBUGZILLA-3_6-BRANCH
<lifeless> so the only things that can conflict with that invocation you are doing are *edits* against the current tree
<lifeless> the equivalent command in bzr is 'bzr switch'
<lifeless> (in terms of merge operations)
<mkanat> lifeless: Ahhh.
<lifeless> now
<mkanat> lifeless: You're my hero.
<lifeless> cvs up -dP -rBUGZILLA-TRUNK_3_6_BASE:BUGZILLA-3_6-BRANCH
<lifeless> would do something close to bzr merge
<lifeless> but you need to have a tag that represents the last merge between two CVS branches to be able to do that
<lifeless> (which hno's most excellent merge scripts for cvs do)
 * igc out for a few hours
<mkanat> lifeless: Oh, um, hmm.
<mkanat> lifeless: Okay...I suppose I need to figure out how to, say, upgrade a customized Bugzilla 3.4 to Bugzilla 3.6 w/o the conflicts that naturally come from upgrading 3.4 to 3.6.
<mkanat> lifeless: Ideally, some set of instructions simple enough that I could at some point provide them to clueless end users.
<lifeless> mkanat: now, all of the above said, we can probably do better here
<lifeless> in your specific case I mean
<lifeless> if the conflicts are mostly of the pattern 'new left and new right differ and we always want new right'
<lifeless> you could write a merge hook to do that automatically
<mkanat> lifeless: I think it's probably "if both new right and new left try to insert a line, we want new right".
<mkanat> But otherwise, we want conflicts.
<lifeless> right
<lifeless> so, you can (fairly easily) whip up a plugin to do that
<lifeless> or even prompt per hunk
<lifeless> mkanat: spiv or I are both familiar with that code and can help you out :)
<mkanat> lifeless: Okay. :-)
<mkanat> lifeless: It looks like, for what I want to do, I can also bundle up the customized revisions and merge the bundle into a branch of the newer branch.
<lifeless> mkanat: yes
<mkanat> lifeless: It's just going to be confusing to instruct people that they have to do something different depending on whether or not they've customized their local code.
<lifeless> mkanat: looms might be a good fit for this too, for deployment/customisation separation
<lifeless> mkanat: if they haven't customized, surely they can just bzr pull ?
<mkanat> lifeless: Right, or switch.
<mkanat> lifeless: But if they have, then there's a whole second set of instructions now.
<mkanat> lifeless: And some people sometimes take over an existing Bugzilla installation and don't know that they've customized.
<lifeless> ah
<lifeless> so at least bzr will tell them 'cannot pull'
<lifeless> :)
<mkanat> lifeless: Yeah.
<mkanat> lifeless: But switch would just switch them.
<lifeless> well, I wouldn't document switch then
<lifeless>  the discussion about switch is most interesting in that it identifies the issue: CVS customisations are not comitted; bzr ones are.
<mkanat> lifeless: Yeah.
<mkanat> lifeless: Which is great, and a really nice advantage for us.
<mkanat> lifeless: I think there's just not yet too much consideration for the "we have a custom local branch of this product and want to upgrade" in the bzr UI.
<lifeless> a cherrypick merge / rebase on top of the next release should work.
<mkanat> lifeless: Yeah, bundle/merge works the way that I want.
<lifeless> Its *interesting* that you have customisations that are so extensive, and manage to conflict so thoroughly with the next release.
<lifeless> mkanat: bundle won't make any difference to the merge
<lifeless> mkanat: its the revision range operator - the cherrypick - that is changing what is going on
<mkanat> lifeless: Yeah, I know, but the bundle worked because I bundled up only the customized revisions.
<lifeless> mkanat: equally, cd 3.6; bzr merge ../3.4 -r customised..revisions
<mkanat> lifeless: Except that I'd have to list a whole series of ranges.
<mkanat> lifeless: Because the branch keeps merging in the upstream branch.
<lifeless> mkanat: you had to for the bundle, didn't you ?
<lifeless> mkanat: when you merge upstream, do you do cherrypicks ?
<mkanat> lifeless: No, I did this: cd bmo-3.4; bzr bundle bzr://bzr.mozilla.org/bugzilla/3.4 > bmo.diff
<mkanat> lifeless: No, just "bzr merge bzr://bzr.mozilla.org/bugzilla/3.4"
<lifeless> mkanat: so this is very odd; I wonder if its a bad base selection
<lifeless> what does bzr show-merge-base report ?
<mkanat> lifeless: Does that need a plugin?
<lifeless> no
<mkanat> bzr: ERROR: unknown command "show-merge-base"
<lifeless> though I may be misrememberign the command name
<mkanat> lifeless: I understand why bzr thinks there are conflicts--we often check in slightly different patches to already-diverged branches.
<lifeless> mkanat: If you have merged the original patch from trunk though
<lifeless> even if you alter it as you merge
<lifeless> it shouldn't later conflict
<mkanat> lifeless: We don't, we check them in separately.
<lifeless> mkanat: ah!
<mkanat> lifeless: Also, we're an import from CVS.
<mkanat> lifeless: So the importer couldn't have known.
<lifeless> mkanat: if you can commit them once, then merge them around and edit as needed, bzr should do much better
<mkanat> lifeless: "merge -c" doesn't seem to retain any revision info, though...does it?
<lifeless> no
<lifeless> you'd need to do full merges
<mkanat> lifeless: So -r1..2 ?
<lifeless> no, that == -c
<mkanat> lifeless: Okay. But I'm talking about a single patch.
<lifeless> 'bzr merge branch'
<mkanat> lifeless: Yeah, we don't want to merge the trunk into a branch.
<lifeless> yeah we have room to improve there
<lifeless> mkanat: I thought you said earlier that you merge from the branch repeatedly ?
<mkanat> lifeless: I think perhaps I should explain everything at once, to make it clearer.
<mkanat> lifeless: Because I'm talking about two things-- (1) The Bugzilla development process (2) a local customized installation.
<mkanat> lifeless: For the Bugzilla development process, at any time we have four or five supported branches, including the trunk.
<mkanat> lifeless: The trunk and the last stable release both get bug fixes.
<mkanat> lifeless: The older branches get security fixes only.
<mkanat> lifeless: So, let's pretend there's a security fix that needs to be done for four branches, and it requires a slightly different patch for each.
<mkanat> lifeless: That means that each patch gets attached to Bugzilla, gets reviewed, and then gets committed individually to each branch.
<lifeless> mkanat: you can use 'daggy fixes' here
<lifeless> commit it to the oldest branch
<lifeless> merge that branch to the next oldest
<lifeless> changing the patch as you merge, if needed.
<lifeless> repeat forward
<mkanat> lifeless: That won't work, either, because we already have 7000 revisions or so.
<lifeless> mkanat: why not ?
<mkanat> lifeless: So, for example, right now if I tired to merge 2.22 into 3.0 (both branches are frozen and dead), I'd get conflicts.
<lifeless> oh, you need to seed it
<lifeless> cd 3.0
<lifeless> bzr merge ../2.22
<lifeless> bzr revert .
<lifeless> bzr st - will show you 2.22 being merged, no file content changes
<mkanat> lifeless: Hmmm, interesting!
<lifeless> bzr commit thast
<lifeless> you may need to do a bzr resolve --all, if you had really pathological conflicts
<mkanat> lifeless: I'll keep getting conflicts, though, because of things like "bump the version number for the next release".
<mkanat> lifeless: That is, in the future.
<pyMynx> can use an ssh key with bzr ?
<mkanat> lifeless: I'll have to keep seeding the branches; it seems overly complicated.
<pyMynx> please tell me I can ^^
<lifeless> pyMynx: you can
<pyMynx> lifeless yay!
<lifeless> mkanat: you don't need to do that process again; when you do a merge, you resolve any conflicts (they should be trivial as you note) and keep going.
<mkanat> mwhudson: Thanks for those traces, they look much more helpful than the first one.
<mwhudson> mkanat: i'm glad to hear it
<mkanat> mwhudson: And those are all hangs, right? Somebody just did a kill -SEGV on it?
<mwhudson> mkanat: hangs, yeah
<mkanat> mwhudson: Great, thanks.
<mwhudson> mkanat: the cores were made with gcore
<mkanat> mwhudson: Okay.
<mkanat> mwhudson: Any chance of getting logs from the same time as those traces?
<mkanat> mwhudson: The first one looks like the server was just overloaded, the second one looks like it's not getting any connections.
<mwhudson> mkanat: i'll have a rummage
<mkanat> spm: Are you still around? I was wondering a bit about the setup of codebrowse.
<spm> mkanat: sure am
<mkanat> spm: Is there some proxy, like Apache or something, in front of loggerhead for codebrowse?
<spm> yeah - saw your bug report on that - been meaning to reply, but the last couple of days have been a level of "AAAAAAAAAAAAAAAAAAAAAA" ness
<spm> 'something' is a good describer....
<mkanat> spm: Hahaha, okay. :-)
<mwhudson> mkanat: bazaar.launchpad.net runs apache
<mwhudson> mkanat: a prg rewritemap sends certain requests via rewriterule [p] to another host, which runs loggerhead
<mkanat> mwhudson: PRG RewriteMap? (Not familiar with the terms.)
<mwhudson> loggerhead makes an xmlrpc call to find out the id of the branch being accessed, and accesses the branch over http at a url based on the id of the branch
<mkanat> (I am familiar with a RewriteRule [P] though.)
<spm> what mwh said; it's not a proxy - per-se; but bunches of rewrite rules
<mwhudson> mkanat: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap
<spm> no. I lie. it is a proxy.
<mkanat> mwhudson: Okay. Does that xml-rpc call happen within Paste, or in some code outside of it?
<mwhudson> mkanat: the section "External Rewriting Program"
<mwhudson> mkanat: within paste
<mkanat> Okay. And when you have one of these hangs, all you do is restart loggerhead on the loggerhead host and things work?
<mwhudson> yeah
<mwhudson> at least that's my understanding
<mkanat> spm: Is that accurate?
<spm> yup; only ever restart loggerhead
<mkanat> Hmm, okay.
<spm> well.. not loggerhead. codebounce; but you get the idea
<mwhudson> mkanat: http://bazaar.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel/annotate/head%3A/launchpad_loggerhead/app.py#L169 <- xml-rpc call
<mkanat> spm: codebounce?
<spm> err *codebrowse* oops. slipup there :-P
<spm> mkanat: at one point we were bouncing it so frequently it *earned* the label 'codebounce' vs it's true name of 'codebrowse'
<mkanat> spm: lol
<spm> something about sysadmins, small minds, and easily amused. probably.
<mkanat> mwhudson: Okay, I will examine the trace more carefully to see if some of the Queue.get calls are actually in a deadlock.
<mkanat> mwhudson: I might need to write a patch for Paste or Loggerhead to get more logging info; we'll see.
<spm> mkanat: Oh, I should add. generally whenever we get a 'non responsive' alert; it's from the *local* check. ie, bypassing apache etc and talking directly to codebrowse.
<mkanat> spm: Oh, hmm, thanks.
<mwhudson> mkanat: sure thing
<mwhudson> mkanat: core.14870 seems to be the lru_cache getting damaged bug
<spm> mwhudson: I don't believe you've seen our other derogatory name for codebrowse? codebbbbbbbbbbounce (like the bbbbbbbbb Berrocca advert) fyi. :-)
<mkanat> mwhudson: Okay. So that's bzr's issue and not ours, then, yeah?
<mwhudson> mkanat: uncelar
<mkanat> mwhudson: Okay.
<mkanat> mwhudson: So the one where we're all in sem_wait is the one I'm working on.
<mwhudson> mkanat: which time was that one?\
<mwhudson> mkanat: also in the launchpad-loggerhead glue is some magic that kills threads that have been inactive for 300 seconds
<mkanat> mwhudson: So if you kill the thread that has the lock and it never releases the lock....
<mwhudson> mkanat: the kill appears as an exception being raised
<mkanat> mwhudson: Okay. So provided that Queue.py is written properly, it should have a finally.
<mwhudson> yeah, it doesn't cause a deadlock, just masses of exceptions
<lifeless> spiv: do you know if vila had gotten anywhere on the 'merge deletes a directory with ignored files causes conflicts' case ?
<spiv> lifeless: not sure, but not afaik
<spiv> lifeless: hopefully the relevant bug report has the latest info
<spiv> lifeless: it'd be lovely if he has, though :)
<lifeless> and the other is a stable monotonic timescale.  Of course then you'd
<lifeless> bah
<lifeless> middle button fail sorry
<lifeless> ok this is weird
<lifeless> mwhudson: :!bzr push
<lifeless> Using saved push location: bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/apport
<lifeless> bzr: ERROR: Cannot lock LockDir(lp-67241552:///~lifeless/bzr/apport/.bzr/branchlock): Transport operation not possible: readonly transport
<mwhudson> lifeless: is it a mirrored branch?
<lifeless> How can I tell ?
<lifeless> ah, yes.
<lifeless> thanks
<lifeless> terribly confusing
<mwhudson> there's a fairly recent bug report about that
<Peng> Hehe. The first time someone ran into that, we almost woke up a losa. :D
<igc> back
<lifeless> spm: hey, is there a tool for sensibly benching LAN configurations ?
<spm> lifeless: the general answer is "yes" - if at a cost; but more precisely - to do what? achieve what?
<spm> as in lan layout configs? down at the switch h/w layers?
<lifeless> I have a gigbit switch at home
<lifeless> and two machines that have negotiated gig links
<spm> but you're seeing 10mb/s throughtput? :-)
<lifeless> but wgettting a 4GB file from one to the other is peakign at 24MB/s
<lifeless> its writing to /dev/null
<lifeless> and the file is in cache on the server (iotop shows no activity)
<lifeless> therefore something is wrong
<spm> +1
<lifeless> I should be able to push 100MB or so on such a full duplex connection
<lifeless> now, I can go through a tedious checklist.
<spm> http://en.wikipedia.org/wiki/Iperf is one istr using... (still chasing links/names)
<lifeless> but I was wondering if, someone has written something to just 'figure it out'(tm)
<spm> Ahh yes. via nlanr, they had a few funky tools.
<spm> so the idea with iperf and friends is to minimise the whatsits right down to the bone - so *really* max the connection; bypassing eg apache/wget etc
<lifeless> right
<spm> I was getting just shy of theroretical max on a 100mbs network in '00 between a couple of sparc t1's. 78? 88? mbs. shrug.
<spm> ... using iperf, or something very like it.
<spm> the other possibility is to snarf the entire flow in tcpdump etc; and do an analysis of that; you may just be hitting tcp window maxes - or something silly/funky like that
<spm> heh; or you have a crap switch ;-)
<spm> might even be worth removing the switch and trying a cross over cable if iperf can't really zot it along.
<spm> could also try; eg; ftp  to an ftp daemon; and/or samba to flip some possibilities
<spm> or nc...
<spm> Actually - this'd be via your shiny new laptop? the network interface may be Gig, but hooked into the pcmcia bus or some sillyness down that path; I know my older laptop has woeful network connection speed compared to a stock desktop/card
<lifeless> spm: yeah, I'll build up to that.
<lifeless> no, its not my laptop; desktop hardware. asus mb
<lifeless> mbs
<spm> cool; if the network is on the m/b; try a card if you have a spare lying around.
<lifeless> I don't ;)
<spm> heh; I think I do; but that may be hard to easily borrow :-)
<lifeless> [  3]  0.0-10.0 sec    727 MBytes    609 Mbits/sec
<lifeless> so, thats a lot better than wget is maanging
<spm> schweeet! so nothing wrong with the switch or network h/w.
<lifeless> well
<lifeless> thats .7 of theoretical or so
<spm> probably that crappy open-sores stuff. install windows and watch the problems fly fly fly away
<lifeless> hah
<lifeless> I want to be able to test bzr perf :)
<fullermd> Most builtins on Asus are Realtek NIC's.  So .7 is pretty good   :p
<lifeless> first step is to make sure that the wiring is good - which it seems to be
<lifeless> next to figure out why wget is slow with apache2
<spm> actually this has all made me curious as to what I can get on my network....
<lifeless> hmm, default tcp buffer size is 85KB ?
<spm> [  3]  0.0-10.0 sec    539 MBytes    452 Mbits/sec <== sadness :-(
<lifeless> hmm, I should play with jumbo frames
<lifeless> spm: you had a tool to analyse window info didn't you?
<spm> tcptrace + xplot for pretty graphs
<spm> wireshark can do similar; but the above is still light years ahead
<lifeless> this is interesting
<lifeless> $ cat /proc/sys/net/ipv4/tcp_mem
<lifeless> 88416   117888  176832
<lifeless> $ cat /proc/sys/net/ipv4/tcp_mem
<lifeless> 573408  764544  1146816
<lifeless> the second, with the larger - better - setting, is lucid
<lifeless> sorry
<lifeless> is karmic.
<lifeless> the first is lucidish
<lifeless> ok, 85MB/sec
<lifeless> had my gateway in the loop
<lifeless> ok cool, my python server keeps up @ 85MB
<lifeless> \o/
<lifeless> spm: thansk
<spm> coolio; anytime etc :-)
<lifeless> trafshow is interesting btw
<lifeless> not brilliant
<lifeless> but interesting
<spm> yeah? not familar with one.
<lifeless> apt-get install trafshow :P
<spm> sush :-)
<spiv> Oh, grr!
<spiv> siginterrupt(signum, False) is reset everytime the signal is received.
<bialix> spiv: hi
<spiv> bialix: good evening
<spiv> I'm about to finish up for the day.
<bialix> spiv: I have a question which bothers me for a long time
<spiv> So I'm extra annoyed to bump into another signal/EINTR issue!
<bialix> why smart server returns to the client relpath to the shared repo root, but then client do upwalk search anyway?
<spiv> bialix: because we haven't finished improving the client yet :)
<bialix> spiv: sorry, I don't want to increase your temper
<bialix> spiv: is it known bug?
<spiv> Oh, that's fine, I'm not bothered at all :)
<spiv> Yeah
 * bialix wanna subscribe to it
<bialix> spiv: ok, thanks, you save me another year of bothering with this question :-)
<spiv> Hmm, not sure if there's a bug number for it, but it's certainly an issue known to me and lifeless!
<spiv> There might be
<spiv> If there isn't you're welcome to file one :)
<bialix> now I know kung-fu too
<spiv> heh
<bialix> ok, I'll file it
<spiv> Basically, there's no convenient place in bzrlib at the moment to make use of the relpath info the smart server is returning there
<spiv> We need to replace or improve the regular 'open' code path
<bialix> I see
<spiv> Which has historically been a bit fragile when touched.
<spiv> I'd rather not duplicate it, because there's really quite a lot of code there for format detection etc.
<spiv> Anyway, I'm done for the day.
<spiv> Happy hacking!
<bialix> gnight
<bialix> spiv: https://bugs.launchpad.net/bzr/+bug/557915
<ubottu> Launchpad bug 557915 in bzr "smart server returns relpath to shared repo but client don't use it and do upwalk search anyway" [Low,Confirmed]
<bialix> I've pasted our converstaion
<spiv> bialix: thanks
<igc> night spiv
<thumper> hi people
<thumper> I'm using bzrlib to commit to a working tree
<thumper> and I'm specifying the committer
<thumper> my .bazaar/bazaar.conf says create_signatures = always
<thumper> but I don't want my script to use this
<thumper> what should I set?
<thumper> BZR_HOME env variable?
<thumper> and how to I set it to just "something that isn't my home" ?
<spiv> BZR_HOME=/dev/null works (with a warning)
<thumper> what warning?
<thumper> and does it matter from bzrlib?
<spiv> failed to open trace file: [Errno 20] Not a directory: '/dev/null/.bzr.log'
<thumper> perhaps I should use a tempdir instead
<spiv> You could always use BZR_HOME=`mktemp -d`
<thumper> spiv: this is from python code, so probably inserting into sys.environ
<spiv> thumper: right
<spiv> And probably by using the tempfile module rather than calling out to /bin/mktemp, too ;)
<thumper> spiv: yeah, looking at that right now
<bialix> BZR_LOG=/dev/null may helps to avoid warning
<thumper> bialix: too late :)
<thumper> although this might be easier
<bialix> spiv: I like your branch name
<bialix> :-)
<thumper> /dev/null doesn't work on windows though does it?
<bialix> thumper: on Windows one should use BZR_LOG=NUL
<bialix> not sure if BZR_HOME=NUL will work though
<thumper> bialix: yeah, so I'm going for the cross platform: tempfile.mkdtemp and atexit.register(shutil.rmtree...)
<bialix> thumper: +1 from me
<thumper> bialix: I'm getting close to actually getting wikkid working
<bialix> wikkid ?
<thumper> http://wikkid.info
<thumper> should redirect to LP :)
<bialix> does not work for me
<thumper> really :(
<thumper> what do you get?
<thumper> works for me
<bialix> it says: Firefox can't find the server www.wikkid.info
<thumper> hmm...
<thumper> weird, should work
<thumper> that redirect is in place too
<bialix> perhaps DNS issue?
<thumper> perhaps
<bialix> C:\Temp>ping wikkid.info
<bialix> Ping request could not find host wikkid.info. Please check the name and try again.
<bialix> :'-(
<thumper> https://edge.launchpad.net/wikkid
<bialix> wow!
<thumper> I have many plans
<thumper> some are getting there
<bialix> it's my dream: to have bzr-based wiki and bug tracker
<thumper> I want a wiki in launchpad
<bialix> wiki in LP! YAY!
<thumper> bialix: well, I'm not doing a bug tracker
<james_w> thumper: you can pass a custom config to .commit()
<bialix> thumper: that's ok
<thumper> I'm designing wikkid with the intent of having it integrated into launchpad
<bialix> thumper: so it will be zope-based?
<thumper> but wikis are not a priority for LP
<thumper> so I'm doing it in my own time
<thumper> bialix: no paste
<thumper> wsgi
<bialix> ok
<thumper> james_w: interesting
 * bialix want to know all this cool things someday
<james_w> thumper: so you could just grab the branch config and override the signatures thing
<thumper> james_w: I'm sure I'll get some people commenting on my bzr hackery in wikkid soon enough
<james_w> or just use an empty config to get the defaults if you don't want anything from the environment
<thumper> james_w: that may be even easier for me :)
<spiv> bialix: :)
<lifeless> thumper: publicity!
<thumper> lifeless: :)
<thumper> I'm having issues with smart_add
<thumper> perhaps I should be more choosey
<lifeless> well
<lifeless> if you have temp files smart_add will break you ;)
<lifeless> that said
<lifeless> you can do tree.smart_add([relpath_to_tree]) and it should work
<lifeless> the fact that you have to give the path to the tree is a bug - I forget the number
<lifeless> its fugly
<lifeless> very old partially fixed up API (used to be a standalone function poking at the internals)
<thumper> ah
<thumper> that might explain it
<thumper> d
<thumper> d'oh
<thumper> I'm giving it ['.']
<thumper> which is the cwd
<thumper> not the location of the tree
<lifeless> yeah
<lifeless> if you'd like to submit a patch to fix it, we'd love that.
<thumper> lifeless: I honestly don't know where to start
<thumper> well
<thumper> I could probably stumble about for a while
<lifeless> tree.bzrdir.base_transport.local_abspath('.')
<thumper> base_transport or root_transport?
<lifeless> root
<lifeless> DWIMNWIS
<thumper> :)
<thumper> :(
<thumper> still failing
<thumper> bzrlib.errors.PathNotChild: Path "/" is not a child of path "/home/tim/src/wikkid/sandbox"
<thumper> it seems to be calling smart_add now with the path shown on the end
<thumper> this is the path of the working tree I'm editing
<thumper> [canonical_relpath(base, p) for p in paths] blows up
<thumper> perhaps I shouldn't use smart_add but use something else
<thumper> ?
<thumper> the reason i used smart_add was I didn't want to have to check the creation of all the subdirs
<thumper> and adding them properly
<lifeless> what is canonical_relpath ?
<thumper> lifeless: a big picture captured with coloured error bits: http://people.canonical.com/~tim/wiki-error.png
<thumper> lifeless: although I'm about to stop and watch House that we recorded on Tuesday
<thumper> lifeless: I'll get back to this tomorrow maybe
<lifeless> thumper: did you see my question about MAN's in NZ ?
<lifeless> thumper: pass a list in
<lifeless> thumper: not a single path
<lifeless> your path is being interpreted as ['/', 'h', '....
<lelix> hi all
<lelix> I'm going to convert a project from svn to bzr. Right now it is composed by a few distinct repositories, and I'm doing svn-import on each of them
<jelmer> hi lelix
<lelix> now I have a doubt on the resulting bzr repos
<lelix> hi jelmer
<maxb> What do you doubt?
<lelix> I simply did "bzr svn-import https://.../repoX", and got two different "kind" of bzr repos: one contains two subdirs ("branches" and "trunk") that I assume are "branches" in bzr parlance
<maxb> The "branches" directory is not a bzr branch. It is merely a container to match the svn naming scheme for branches
<lelix> the other instead is "monolithic", that is, it does contain just a ".bzr" subdir, and checking it out I get the whole thing that is "/trunk", "/branches" and "/tags"
<lelix> maxb: yes
<maxb> The actual bzr branches are at "branches/FOO"
<lelix> yes, it even told me that, so I could not do "bzr co .../repo1" but had to do "bzr co .../repo1/trunk"
<maxb> If trunk/, tags/ branches/ are present *inside* a bzr checkout/branch, then the import has imported the wrong thing
<lelix> yes, that's what seems happened
<lelix> I see svn-import uses a "layout" option, I left the default "auto", and the import step told me "using repository layout trunk0"
<lelix> but I fail to understand the difference between one kind and the other... it must be something different in the source repositories...
<lelix> maybe I can "svn-import" just the svn "/trunk" instead of processing the whole repository?
 * lelix tries
<jelmer> lelix: you can 'bzr branch' just the trunk
<jelmer> lelix: svn-import is for importing multiple branches
<lelix> jelmer: with the former, you mean I don't have to use svn-import at all, and just branch it out of svn?
<jelmer> lelix: yep
 * lelix leaves for lunch
<lelix> jelmer: thanks, I'll retry later
<lifeless> vila: two questions
<lifeless> vila: did you get anywhere on the lost+found approach for conflicts deleting directories that contain ignored files?
<lifeless> vila: and, if I wanted to do a POST, to an http url that I have a bzr transport connected too; is there a clean way? or the best unclean way?
<lelix> just to understand: what determines the kind of thing I obtain with "bzr branch" wrt to working-tree? Doing a branch from a svnrepo I get a workingtree-less branch, while branching from there I get the working tree...
<lelix> does the presence of the wtree imply some difference in the repo itself?
<IslandUsurper> lelix, possibly. bzr repos can be set to use working trees or not by default. run `bzr info` on your destination branch to see if it tells you.
<IslandUsurper> I doubt it has to do with bzr-svn or the svn repo
<jelmer> lelix: you can create a working tree by running 'bzr co'; there is a setting in the repository that determines whether working trees are created by default
<pyMynx> how can I get bzr to use a different python install?
<SamB_XP> what OS?
<SamB_XP> pyMynx: if you're on *nix, you can either change the #! line at the top of the bzr executable, or you can change which python install is invoked by /usr/bin/env python
<SamB_XP> (or whatever it is at the top of your bzr executable -- I guess it might be something else ;-)
<SamB_XP> but note that (a) bzrlib will have to be in that python's module path and (b) you may lose features if you switch major versons of Python without getting the extensions compiled for the major version you switch to
<SamB_XP> pyMynx: so ... are you gonna say anything or not ?
<lelix> jelmer, ok: but from the repository POV, does that make any difference? Or is that completely transparent in the operations one can do on it? Ideally, it seems that I can keep my "master" repos (the one linked to some kind of bug-tracker/repo-browser say) always as wtree-less repositories, right?
<maxb> Yes, this is correct. Working trees are purely for doing development work in
<lelix> thanks
<pyMynx> SamB_XP: hey thanks very much! I think I fixed it by moving the bin path up in the PATH environment variable
<pyMynx> SamB_XP: it always resets for some reason :( , I'm using CentOS btw
<johnjosephbachir> howdy
<johnjosephbachir> anyone here know much about the --file-ids-from flag for the 'add' command?
<maxb> johnjosephbachir: What about it?
<johnjosephbachir> well, i used it when adding in some code from another repo (svn), thinking it might be helpful for merging in updates from that repo in the future. Now, i'm trying to merge in changes from another one of my own branches (on a directory above that dir in question), and bzr is very confused, thinking that the dir i added witih --file-ids-from needs to be deleted
<johnjosephbachir> maxb: ^
<maxb> Does the dir in question exist in any of your branches, *except* by way of being added by that one addition you mentioned?
<maxb> And when you say svn, do you mean a bzr-svn conversion?
<johnjosephbachir> here's what i did. i have trunk, and branch-1
<johnjosephbachir> branch-1 is a branch of trunk, as you might imagine. inside of branch-1, i did this command:
<johnjosephbachir> svn export http://svn.example.com/path/to/tag mydir
<johnjosephbachir> bzr add --file-ids-from= http://svn.example.com/path/to/tag mydir
<johnjosephbachir> and committed, and have been doing tons of development in both trunk and branch-1 since then
<fullermd> I wouldn't --file-ids-from can do anything when pointed at a svn repo...
<fullermd> (wouldn't think)
<johnjosephbachir> now, when i do a merge, i get tons of errors, the first one being:
<johnjosephbachir> "Conflict: can't delete mydir because it is not empty.  Not deleting."
<johnjosephbachir> maxb: ^
<johnjosephbachir> maxb / fullermd and i am fairly certain this problem is a result of my file-ids-from, for reasons i will be happy to explain if you would like me to (but it will take a while)
<maxb> erm. And did the content of mydir correspond closely to the content of http://svn.example.com/path/to/tag ?
<fullermd> I'm pretty sure you'd have to point at a bzr branch for file-ids-from to have any possible meaning.
<johnjosephbachir> maxb: the contents were identical when added (note that it came directoy after an svn export)
<maxb> I don't suppose this is a public project? It would be so much easier to see it breaking
<johnjosephbachir> maxb: alas, no, but if you are available for consulting i can email you the repos in question
<fullermd> At any rate, you could just check whether the two branches have the same file-id's.  But I'd doubt it.
<johnjosephbachir> fullermd: well the thing is, i don't actually want to do any operations on the foreign repo... so its state shouldn't matter for this operation
<johnjosephbachir> (if i get what you mean)
<fullermd> I don't.
<johnjosephbachir> you don't wnat?
<johnjosephbachir> *what? :)
<fullermd> At any rate, if the file-id's of two branches don't match, you're not going to have any direct luck merging them (it's bad enough them not sharing ancestry)
<johnjosephbachir> fullermd: i
<fullermd> And using file-ids-from pointed at a SVN repo is almost certain not to make the two bzr branches match, if indeed it does anything at all.
<johnjosephbachir> fullermd: i'm not trying to merge them. i'm truing to merge two of my own branches, one of which has a subdirectory based off of a foreign branch
<johnjosephbachir> fullermd: got it. well, the dir in question doesn't exist at all in the branch i am merging in... so i'm not sure why it cares about it at all
<fullermd> Did it ever?
<johnjosephbachir> nope
<johnjosephbachir> fullermd: is there a way to "normalize" my file-ids in my imported branch? i.e., clear out the result of using --file-ids-from, and let bzr make its own "normal" ids ?
<johnjosephbachir> '
<johnjosephbachir> maxb: ping
<maxb> johnjosephbachir: Empirically, --file-ids-from has no effect when given a remote svn repository
<fullermd> I'm not sure that's a meaningful statement.  I'm still of the SWAG belief that --file-ids-from=<something svn> is nugatory from the get-go.
<fullermd> And if it weren't, letting bzr create its own random ones still wouldn't help you with merging down the line.
<johnjosephbachir> okay, i'll tell you guys what else i've observed
<maxb> I have tested fullermd's SWAG and it is correct. I disbelieve that --file-ids-from is the problem here
<johnjosephbachir> so i tried this workaround. i tried first removing mydir in branch-1, committing that (let's say that's revision 10). then, i did the merge, with no problems. then i committed that merge. THEN, i tried to undo revision 10, with bzr merge -r10..9 , and i got this error: http://pastie.org/909742
<fullermd> You forgot to tell it a meaningful place to merge from (e.g., itself)
<fullermd> I think you're succumbing to shotgunitis, here.
 * johnjosephbachir tries it with a dot
<johnjosephbachir> WIN
<johnjosephbachir> okay so, that worked, and is probably a good workaround, BUT: 1) we still don't know why the merge didn't work, and 2) i don't wnat to have to do this every time
<johnjosephbachir> any ideas? maxb fullermd
<johnjosephbachir> i would be happy to send either of you the branches and pay you to solve this problem, if you have the skills/time/interest
<maxb> I don't think any further debugging is really possible without seeing the actual history. If this were svn, I'd ask for a 'svn log -v', but I don't know of any equivalent bzr view that actually shows file/dir add/del/move operations
<maxb> I'm not doing paid consulting, but you've got me curious - if you want to send it to me, I'm happy to see if I can solve the conundrum
<johnjosephbachir> maxb: cool, wanna pm me your email?
 * maxb afk 5mins
<jam> maxb: bzr log -v doesn't give the equivalent?
<sebi`> Hi, do i need to worry when including .bzr/ in distribution packages and branches? are there any sensitive information saved in there?
<jam> sebi`: I would not include .bzr/ in dist packages, as it doesn't really make *sense* more than it would be bad
<jam> you wouldn't include .svn, right?
<jam> anyway, it could include the whole history of the project, but I don't see it including anything more sensitive than that
<sebi`> I've never worked with svn before, so I can't really say If i would
<jam> sebi`: generally VCS data is excluded from a .deb
<sebi`> the history, including all revisions are publicly visible anyway, so I don't see a reason in hiding them
<sebi`> okay
<sebi`> so I can assume there are no sensitive information saved in there, such as passwords, login-names, etc?
<jam> right, there shouldn't be anything sensitive
<jam> the main thing is that if people wanted the history, they would ask for it
<jam> if they are grabbing a .deb they don't want the history
<IslandUsurper> and they would ask for it by using bzr
<sebi`> okay, makes sense to me
<jam> and it can significantly increase the size of the download
<sebi`> woah you're right... .bzr is about 2.3M big right now
<sebi`> didn't know it gets huge so fast
<barry> hi folks.  are there any windows/bzr experts around?  i know next to nothing about windows, but have bzr explorer installed and have done 'bzr launchpad-login' but i'm getting hung up on ssh (maybe this is really a windows ssh problem)
<jam> hey barry
<jam> easiest 'fix' is to make sure you have Pageant installed, and that the ssh-key is properly shared with LP
<jam> but 'it depends' on your ssh setup otherwise
<jam> well, properly shared *and* properly loaded
<barry> jam: pageant?  is that a windows ssh client?
<jam> pageant is part of the putty tools, and is an ssh-agent, not really an ssh client
<barry> jam: gotcha, thanks!
<jam> alternatively, you can use regular openssh style credentials, but need to have them in the right place on your path so we can find them
<jam> $HOME/.ssh IIRC
<jam> where $HOME is often C:\Users\username
<jam> or C:\Documents and Settings\username
<jam> depending on your Windows ver
<barry> jam: windows 7
<jam> I haven't used 7
<jam> but I'm guessing C:\Users\<username>
<jam> after Vista's style
<jam> So I think if you copy your id_rsa and id_rsa.pub to C:\Users\barry\.ssh\id_rsa
<jam> we can probably find it without pageant
<barry> jam: cool, thanks.  i'll give that a shot.  it's boggling how little useful stuff windows actually comes with :)
<jam> barry: installing cygwin usually helps, but yeah
<barry> jam: yeah :)
<jam> bare-bones OS vs OS + apps
<jam> and no package manager
<barry> "get a real os" is my usual response :)
<barry> jam: otoh, explorer is pretty nice
<jam> bzr explorer works on real OS's too
<barry> yeah, but it's only windows that makes me all clickity clackity
<mneptok> barry: your tap shoes don;t do that?
 * mneptok is Fred to barry's Ginger
<barry> mneptok: i don't have red hair or taps, but i do have bells on my toes
<mneptok> barry: i don't want to rmeinf you again not to arouse me during working hours.
<mneptok> *remind
<jam> vila: I thought you weren't working today. Why are you triaging bugs? :)
<abadger1999> Hey, I'm writing a proposal for Fedora EPEL to be able to upgrade the bzr package we have despite API compatibility changes.
<abadger1999> Can someone confirm whether bzr-2.1 can support all the repos that bzr-1.3 has?
<Noldorin> hi jelmer
<fullermd> You mean the formats?  Sure.
<jelmer> Noldorin: hi
<Noldorin> jelmer: i see bzr-git has come along a bit. though i might give it another shot with github :)
<Noldorin> (not sure if you remember me...)
<jelmer> Noldorin: I remember :-)
<Noldorin> :)
<jelmer> Noldorin: I don't think anything has changed in the area you were seeing problems though
<Noldorin> i'm working off bzr-git and dulwich trunks now
<Noldorin> ah right
<Noldorin> jelmer: still, i've cleaned up my system and my bazaar installation a bit too, so i'm sort of doing things afresh now
<Noldorin> if you wouldn't mind providing a few pointers...
<lifeless> abadger1999: yes, 2.1 can read and write to a superset of 1.3
<abadger1999> lifeless: Thanks!
<Noldorin> jelmer: it says i need distutils for a start, now...
<Noldorin> jelmer: oops, seems my system is still detecting an old python version, which explains
<Noldorin> jelmer: sorry.... what was the trick to get dulwich being recognised by bzr-git after doing setup.py install?
<jelmer> Noldorin: you can set PYTHONPATH I guess
<Noldorin> jelmer: yeah, but to what, if i've installed it?
<Noldorin> the source (pulled from the branch) lives in c:\lib\dulwich
<jelmer> Noldorin: to the location in which it's been installed
<Noldorin> jelmer: sorry, i'm still quite ignorant of python. all i know is that setup.py install ran and completed successfully...
<jelmer> Noldorin: you should set the environment variable PYTHONPATH to the path of the directory that contains dulwich\__init__.py
<Noldorin> jelmer: ok, so that's what i'm doing. is the separator in the PYHTONPATH the ; character?
<jelmer> Noldorin: I think so
<Noldorin> jelmer: ok, cheers. so it finds dulwich now, but i get this error:
<Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
<Noldorin> ssh://git@github.com/Noldorin/IRC.NET.git --no-strict
<Noldorin> bzr: ERROR: [Error 2] The system cannot find the file specified
<Noldorin> if i recall correctly, we never did figure out the required URL for github... hmm
<barry> jam: or other folks.  i don't know enough about how bzr explorer does its thing but i think it maybe causing spurious failures in the python test suite.  i think we're seeing something similar to this: http://bugs.python.org/issue7443
<barry> jam: is it possible to "turn off" bzr explorer temporarily for that directory and all sub-directories?
<jelmer> Noldorin: that URL is correct, I'm quite sure it is
<Noldorin> ok good
<Noldorin> but yes, this Error 2 is unexpected...
<jam> barry: do you mean explorer or TortoiseBzr ?
<jam> (explorer == gui standalone app, TortoiseBzr == Windows Explorer integration)
<jam> AFAIK, not easy to disable per dir without just uninstalling it
<jam> but I don't follow it very closely.
<jelmer> Noldorin: somebody reported an error against Dulwich trunk the other day about atomic renames
<Noldorin> jelmer: ah, you think this couldbe causing error 2? if so, should i maybe revert to a previous revision of dulwich?
<barry> jam: probably tortoisebzr
<lifeless> vila: ping ?
<barry> jam: ah.  don't really want to do that.  maybe i can copy the directory elsewhere or mv the .bzr directory aside?
<jam> barry: mv the .bzr aside would probably work
<barry> jam: cool thanks.  trying...
<Noldorin> jelmer: looks like a windows style error anywya
<lifeless> james_w: btw, multiprocessing is really slow
<Noldorin> jelmer: i'm up for a little debugging of the source, if that helps you :)
<james_w> lifeless: what do you mean?
<lifeless> james_w: I benchmarked doing stuff with python's multiprocessing module a while back
<jelmer> Noldorin: we need to find a good alternative to atomic renames on Windows
<lifeless> james_w: it was only marginally faster than threads, and a lot slower than using a custom external helper
<jelmer> Noldorin: you're on Windows < 7 I suspect?
<jelmer> Noldorin: I wonder what C Git uses
<Noldorin> jelmer: i'm on Windows 7 actually
<Noldorin> yeah...
<Noldorin> jelmer: if there's any testing we can do at the moment (for a temporary solution at least), that's cool though
<Noldorin> having some devs on my project before git, and others prefer bzr is making things a pain heh!
<Noldorin> some devs on my project prefer*
<jelmer> Noldorin: you could revert back to older versions of dulwich and bzr-git
<Noldorin> jelmer: ok, i will try that
<Noldorin> which revision of each do you recommend?
<jelmer> the latest release I guess
<Noldorin> jelmer: how do i know what that is?
<Noldorin> never mind, it's all tagged :)
<jelmer> yep :-)
<Noldorin> jelmer: same error i'm afraid
<Noldorin> on the 0.5.0 release
<jelmer> Hmm, I guess the GitFile changes made it into the 0.5.0 release as well
<jelmer> I guess you'll need one of the 0.4.x releases then
<Noldorin> ok
<jelmer> I'm not sure if that's actually newer than last time you tried
<Noldorin> jelmer: crazy. still exists in 0.4.3/0.4.1
<jelmer> are you sure you're running an older version?
<Noldorin> yep
<Noldorin> 'bzr plugins' says git 0.4.3
<jelmer> Noldorin: that doesn't mean it's an older version of dulwich
<Noldorin> jelmer: yes i know, but i've checked my dulwich version too and rebuilt it :)
<Noldorin> bzr revert -r xyz
<Noldorin> python setup.py build
<Noldorin> python setup.py install
<Noldorin> and retest
<Noldorin> jelmer: any ideas...?
<Noldorin> otherwise i will just leave it for now heh
<jelmer> Noldorin: sorry, no idea; I doubt there's much point in trying with such an old version anyway
<jelmer> since it would be the same version as what you tried earlier
<Noldorin> jelmer: indeed
<Noldorin> jelmer: well, if/when you think it's worth trying again, do ping me please :)
<jelmer> Noldorin: will do :-)
<Noldorin> cheers
#bzr 2010-04-09
<lifeless> thumper: ping
<lifeless> thumper: did you seem my reply last night ?
<maxb> Why would I see a contents conflict on merging, instead of a text conflict, for a file which is ostensibly text, and has common ancestry between the branches being merged?
<spiv> maxb: good question.  Not sure!
<maxb> oh, oops, it was removed at one point on the merge target branch
<abadger1999> Another question for my request to update the EPEL bzr -- what's the API policy and release lifecycle of the 2.x branches?
<abadger1999> is it 2.x is compatible but 2.(x+1) can have API breaking changes?
<abadger1999> And is it 2.x will be supported for 6 months?  1 year?  Undetermined?
<abadger1999> I'm trying to find the best release to put into a repository that's supposed to remain API stable for 4 more years.
<james_w> 2.X.Y should be stable across Y
<abadger1999> Excellent.
<james_w> as for support timeframes, they are longer, but not sure about 4 years
<abadger1999> <nod>
<abadger1999> Is there a doc that tells what hte expected timeframe is?
<james_w> 2.1.1 is in Ubuntu lucid, which will be around for years
<james_w> so 2.1.X might be a good choice
<james_w> I don't think so
<james_w> Martin started a discussion a couple of weeks ago on the list about what sort of timeframes people would be interested in for the various releases
<james_w> maybe you would like to weigh in there
<abadger1999> yeah, I saw that in passing... wasn't sure how to ask for a seven year release lifetime, though :-)
<james_w> heh
<abadger1999> LTS releases are approximately 5 years?
<james_w> 3 on the desktop, 5 on the server
<james_w> not sure where bzr falls
<james_w> night
<abadger1999> Night.  And thanks!
<lifeless> abadger1999: we don't have any release thats stable for 4 years for bzr itself
<abadger1999> <nod>
<lifeless> abadger1999: our policy is to minimise API changes totally on the .Y as james_w says
<lifeless> but the bzr community doesn't do bugfixes for 5 years on a given X.Y
<lifeless> more like 6-12 months
<lifeless> so no API changes on .Z unless its fully compatible or needed for security
<lifeless> few changes in .Y's, but they happen
<lifeless> and anything goes on X's
<lifeless> a new .Y every 6 months
<lifeless> a new .Z every month, for the last few .Y's
<abadger1999> Okay.  So .Y's are expected to break compatibility but hopefully in little used areas, .Z's are expected to not break anything (barring no other way to fix a security hole)?
<abadger1999> Or is it more accurate to say .Y's can break things but porting should be straightforward?
 * abadger1999 trying to figure out how best to phrase this in the request to update
<thumper> lifeless: yes I did, thanks
<lifeless> thumper: cool
<lifeless> abadger1999: .Y's *may* break it, if doing so makes things better for bzrlib API's. Not expected, but also not unexpected.
<lifeless> so yes, '.Y's can break things but porting should be straightforward?'
<abadger1999> lifeless: Thanks!
<igc> hi all
<abentley> I just got a local delivery failure sending a message to the Bazaar mailing list: http://pastebin.ubuntu.com/411371/
<spiv> abentley: ouch.  I guess that's something to ask IS or at least a losa about?
<lifeless> #is
<lifeless> yeah
<abentley> spiv, wanted to make sure it wasn't a known issue.
<spiv> abentley: well, not known to me :)
<spiv> It wouldn't surprise me to find that #is knows already.
<lifeless> there has been no chatter
<LaserJock> how can I undo a commit, not revert, just get rid of the log entry, etc.
<jelmer> LaserJock: bzr uncommit
<LaserJock> jelmer: awesome, is there something like unadd?
<LaserJock> oh, maybe rm --keep or something
<jelmer> LaserJock: yep, sounds like it
<fullermd> If the two are related, it sounds more like you want 'pull' than 'uncommit'...
<spiv> Woo, 0 new bugs again.
<LaserJock> fullermd: but I have nothing to pull from
<fullermd> You have itself.
<fullermd> bzr pull --overwrite -r-2 .
<LaserJock> hmm, interesting
<fullermd> The different between pull [--overwrite] to a prior rev and uncommit is that uncommit leaves your WT in the state it's in right now, with pending edits and adds and rm's and merges equal to the commit you were at.
<fullermd> pull goes back to that rev (roughly; mod currently uncommitted changes which get merged)
<spiv> "bzr uncommit" followed by "bzr revert" is probably a less confusing way to do that, even if it is two operations.
<spiv> pulling from ". -r-2" is a bit subtle.
<LaserJock> well, I was trying to unadd mistakenly added files
<LaserJock> so i wanted to uncommit, unadd, then recommit
<spiv> LaserJock: sounds like the uncommit and rm commands you found were just what you wanted, then :)
<fullermd> Well, if you want to be unsubtle, there's always `git reset --kinda-soft-like-a-spring-rain` or whichever variant it is...
<lifeless> LaserJock: you can safely revert an added file, btw
<lifeless> it will just get unadded
<LaserJock> oh
<LaserJock> I get mixed up between git revert and bzr revert so I tend to avoid both
<LaserJock> the curse of the multiple-DVCS world
 * RAOF grumbles at git deliberately using different terminology to everyone else.
<lifeless> LaserJock: apt-get install bzr-git; never look back.
<RAOF> Well, look back a *little* bit, at least until there's some way to refer to a colocated branch.
<lifeless> RAOF: there is
<RAOF> WHEN DID THIS HAPPEN?
<LaserJock> well, I do like git sometimes, I don't know that I want to get rid of it altogether
<lifeless> LaserJock: I wasn't suggesting migrating
<LaserJock> but it is annoying that they seem to use different terminology form everybody else
<lifeless> LaserJock: just using bzr :)
<LaserJock> right, but that's full of FAIL, IMO
<RAOF> lifeless: Make my life better.  Point me at docs :)
<lifeless> RAOF: https://code.edge.launchpad.net/~jelmer/bzr/colo-urls/+merge/20860
<LaserJock> is it easy to push and branch with bzr-git?
<LaserJock> the "consumer" end isn't so bad
<LaserJock> but if I'm the only bzr user in a team of git-heads I think I'm at a disadvantage using bzr-git
<RAOF> Branching just works; to push you need to use âdpushâ rather than âpushâ (unless that's been resolved), but that also works.
<LaserJock> then there's that branch-as-a-dir thing that still gets me about bzr even after years of use
<LaserJock> I'm getting there though :-)
<LaserJock> I just have to force myself to stop blowing away branches
<lifeless> why?
<lifeless> I delete branches all the time
<lifeless> I just deleted 5
<LaserJock> because then I don't ever branch
<lifeless> ...
<LaserJock> I think branching should be a useful thing, but I don't think I'll use them if I just keep deleting them
<LaserJock> maybe it's repos I don't like more than branch-as-a-dir
<LaserJock> I suppose it's just psychology, I find it somewhat intuitive to mix VCS and non-VCS dirs
<LaserJock> *unintuitive
<LaserJock> I regularly do that with bzr and I often don't know what's a branch and what isn't
<lifeless> LaserJock: so I have one work dir
<lifeless> and N branches
<LaserJock> I go and blow away a branch thinking it's something else
<LaserJock> hmm
<LaserJock> so is that like using bzr switch?
<LaserJock> I was reading something about being able to do something git-esque by switching working dirs or something
<LaserJock> seemed overly complicated
<lifeless> spiv: are you around ?
<lifeless> LaserJock: bzr switch? 2 extra commands to setup, after that no-brainer
<spiv> lifeless: I am
<lifeless> I want to talk commands
<lifeless> if you're working
<spiv> I am working
<spiv> Now's as good a time as any, I suppose1
<spiv> !
 * igc out for a few hours
<thumper> lifeless: got a few minutes?
<thumper> every time I try to use the bzr command line client I get:
<thumper> $ bzr info
<thumper> /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<thumper> anyone know what I need to stab to make it go away?
<lifeless> thumper: sure
<lifeless> thumper: uhm
<lifeless> thumper: pkg_resources sucks.
<lifeless> thumper: file a bug on lazr
<thumper> lifeless: and the short solution to stop bzr complaining at me all the time?
<lifeless> apt-get remove python-launchpadlib, I guess
<lifeless> thumper: you can make it break - and get a backtrace
<lifeless> python -Werror BZR_PDB=1 /usr/bin/bzr info
<thumper> didn't stop unfortunately
<lifeless> thumper: poke around /usr/lib/pymodules/python2.6
<thumper> and BZR_PDB=1 had to go first
<lifeless> its a nuts error
<lifeless> thumper: do you have python, or setuptools, or soething like that coming from the lp ppa ?
<thumper> probably something
<thumper> how can I see?
<lifeless> apt-cache policy <package>
<lifeless> aptitude search ~o
<lifeless> its a nuts error because for /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, to have been imported /usr/lib/pymodules/python2.6 has to be on the path already
<lifeless> have I mentioned I hate pkg_resources ?
<thumper> :)
<SamB_XP> lifeless: what IS that ?
<lifeless> what is what ?
<SamB_XP> that thing you keep saying you hate
<lifeless> http://pypi.python.org/pypi/setuptools
<SamB_XP> ah, something from the infamous setuptools then ?
<lifeless> pep 365 is pkg_resources, but its a pje special
<lifeless> note the status - rejected ;)
<thumper> pje?
<lifeless> phillip J eby
<SamB_XP> I'm assuming he's one of the people behind the infamous package mentioned above
<lifeless> the guy that brough setuptools and easy_install to life
<SamB_XP> exarkun, I believe, is often ranting about setuptools
<lifeless> Most Hated Module Ever
<lifeless> it has caused more bugs than I want to think about
<lifeless> for fun, read /usr/lib/python2.6/dist-packages/pkg_resources.py
<SamB_XP> no thanks ;-P
<lifeless> note the 15 line vertical whitespace
<SamB_XP> woah
<lifeless> I mean, thats a trivial thing right. But so unnecessary
<SamB_XP> and I thought that one NES emulator was bad!
<SamB_XP> it used like up to 5 lines of whitespace in a row for different reasons ...
<lifeless> have a look at this:
<lifeless> if (modname not in sys.modules or modname in nsp
<lifeless>     or modname in _namespace_packages
<lifeless> ):
<lifeless>     continue
<lifeless> for indenting
<lifeless> thumper: so the bug is
<lifeless> thumper: that pkg_resources has a bug (surprise)
<lifeless> thumper: if you add
<lifeless> if fn in sys.path:
<lifeless>     continue
<lifeless> at line 2333 of /usr/lib/python2.6/dist-packages/pkg_resources.py
<lifeless> it will probably silence the error
<thumper> nope
<lifeless> oh
<lifeless> well, I'd put pdb in there and inspect
<lifeless> I guess there may be an egg magic causnig it to be loaded without the containing dir being on the path.
<lifeless> Moar reasons to hate eggs
 * SamB_XP wonders if there is such a thing as "build-conflicts"
<lifeless> for debian packaging? yes
<lifeless> I forget the exact header name
<lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/commands/+merge/23068
<abentley> lifeless, do commands need to call  ui.ui_factory.clear_term if they might have caused progress messages?
<lifeless> abentley: I think thats the current workaround
<lifeless> abentley: there is some discussion about makeing self.outf do that if needed, automatically.
<abentley> lifeless, I've looked at builtins.py and I only see one command doing that (ls.)  I guess the rest are doing it lower down?
<lifeless> let me have a squiz
<lifeless> gpg strategy does it
<lifeless> abentley: note() does it
<lifeless> and so does warning()
<lifeless> abentley: so yes, I think that that accurately summarises - the rest are doing it lower down
<parthm> lifeless: ping
<lifeless> hi
<parthm> hi.
<parthm> so i am trying to understand rio better. if i get it right, right now its a binary format meant to be written to a file?
<parthm> what does rio stand for?
<lifeless> see the top of bzrlib/rio.py
<parthm> lifeless: thanks. i am just trying out your tags diagnostic patch.
<lifeless> parthm: as martin_gzlist says, its not that
<parthm> lifeless: yes. just noticed that. so rio is more of an internal binary format (ascii + utf-8) not really meant for stdout. so what would be a good fix for this?
<lifeless> parthm: as per the list/bug - change the command to take a filename
<lifeless> permit '-' for people to that want to use it
<parthm> in 'version-info [location]' with location being optional we probably need a option --output or something. so if the file is open-ed with the correct encoding that should take care of making rio readable?
<lifeless> if we are breaking compat
<lifeless> change it to version-info filename [location]
<lifeless> or
<lifeless> change it to version-info filename [-d location]
<lifeless> (-d is a common argument we want to support for 'look elsewhere for stuff')
<parthm> lifeless: sounds fine to me. so this is probably more of a 2.3 change. i still need to understand rio better will probably spend some more time on that.
<lifeless> ok
<parthm> i will discuss this on the mailing list in case there are some more suggestions/refinements.
<parthm> lifeless: thanks for the help.
<lifeless> anytime!
<mwhudson> so what are actual good tools for visualizing conflicts?
<lifeless> meldd
<spiv> mwhudson: http://blogs.mathworks.com/images/steve/2009/windowing_fft_2_03.jpg
<lifeless> ow!
<lifeless> warn usbefore doing that :P
<mwhudson> spiv: thanks
<mwhudson> lifeless: hm, bit underwhelmed by meld in this case, how do you invoke it?
<lifeless> there is a plugin I believe
<mwhudson> oh right 'extmerge'
<mwhudson> jelmer: hooray for inconsistent tabs vs spaces in dulwich's _pack.c
<mwhudson> at least i assume that's what's going on, not just inconsistent indentation
<lifeless> thumper: have you seen https://edge.launchpad.net/codewiki ?
 * igc night all
<lifeless> gnight
<thumper> lifeless: I took a brief look, yes
<lifeless> vila: ping
<lifeless> mwhudson: do you know, is paste able to run on unix sockets ?
<jelmer> lifeless: I ran an evolution git import overnight with profiling: commit_write_group(): 22%, add_inventory_by_delta: 10%, insert_record_stream (overall) 60%
<jelmer> anyway, food for thought :-)
 * jelmer goes back to soyuzy issues
<Kinnison> mmm soyuz
<thumper> how do I override create_signatures when calling workingtree.commit() ?
<thumper> I want to get the committer from the config
<thumper> but not sign
<lifeless> pass in your own config object if you want to control that sort of thing
<thumper> how do I create a config object?
<lifeless> why don't you want the users signing policy to apply though?
<thumper> lifeless: because I don't want a box popping up when editing a wiki page
<lifeless> thumper: uhm
<thumper> and I'm explicitly setting the committer
<lifeless> thumper: give me more context, but this sounds like something you shouldn't be bothering with, to me.
<lifeless> some folk may want signed wiki changes
<lifeless> some folk won't, and bzr lets users choose
<thumper> I'm making an executive decision for now
<thumper> people can haul me up on it later
<thumper> it bugs me
<lifeless> thumper: so change your config
<thumper> my local commits are always signed
<lifeless> the default isn't to sign
<lifeless> thumper: are your wikis in a specific subdir ?
<thumper> currently it is
<thumper> it'll always point to a branch though
<lifeless> thumper: so, I suggest you set the signing policy in branch.conf when you create a wiki branch
<thumper> ok, you've convinced me to at least make it an option
<thumper> but the original question still stands
<thumper> how to I override the config
<lifeless> bzrlib.config has a number of config objects
<thumper> thanks, I'll take a look
<lifeless> I still say, don't do it.
<lifeless> you're certain to regret it
<thumper> I regret many things
<thumper> :)
<thumper> I already regret some code I wrote three days ago
<Kamping_Kaiser> could someone look at this and say if it looks like a bzr bug? i type 'bzr ignoreb' and press tab. result is the paste here http://paste.debian.net/68133/
<thumper> lifeless: if it is sign when required, when is it required?
<lifeless> thumper: not implemented
<james_w> Kamping_Kaiser: you have a conflict in /home/kgoetz/.bazaar/plugins/rewrite/commands.py
<Kamping_Kaiser> james_w: thanks. is that a conflict between bzr and rewrite?
<james_w> no
<james_w> you edited the file at some point or something
<james_w> and then did a pull and it put conflict markers in the file
<james_w> so it's not valid python
<james_w> so bzr crashes trying to load it
<james_w> arguably that last bit is a bzr bug
<james_w> but you can fix the issue by resolving any conflicts in /home/kgoetz/.bazaar/plugins/rewrite/
<Kamping_Kaiser> james_w: i've never edited the file, but i'll make sure my branch is valid
<Boobek> hi
<Boobek> I have a question before I send a bug request:
<Kamping_Kaiser> james_w: loads of conflict markers, reverting them fixes the tab issue. thanks :)
<Boobek> can I make a branch from a launcpad project on my localdrive? (for example: bzr branch lp:slip-cover
<thumper> Boobek: yes
<thumper> that's one of the main points :)
<Boobek> :)
<Boobek> ok, but in bzr 2.1.1 i get the following output:
<Boobek> http://paste.ubuntu.com/411555/
<Boobek> it's normal?
<thumper> Boobek: looks like you haven't told launchpad your ssh key
<thumper> Boobek: but you have done a bzr lp-login
<lifeless> gahk
<lifeless> hg ships its own bindings to inotify
 * thumper is done hacking for a friday night
<Boobek> I told it from browser but this command isn't work
<Boobek> I have the same output: http://paste.ubuntu.com/411559/
<jelmer> thumper: how did the linux import go?
 * thumper looks
<jelmer> thumper: I don't see how many revs it's already done
<thumper> about 65k revs
<thumper> look at the most recent log
<jelmer> thumper: where do you see that?
<thumper> Boobek: ask in #launchpad and someone should help
<thumper> http://staging.launchpadlibrarian.net/42124618/mwhudson-linux-trunk.log
<thumper> https://code.staging.launchpad.net/~mwhudson/linux/trunk - see the log links
 * thumper signs off
<jelmer> thumper: That's what I'm looking at :-)
<Boobek> thumper, thx
<Boobek> join #launchpad
<jelmer> Have a nice weekend thumper
<thumper> jelmer: it started at around 215k revs, now down to 150k ish
<thumper> jelmer: you too
<jml> my records aren't good enough to file a proper bug
<jml> but the way that bzr handles "conflicts" when deleting directories that contain non-versioned content just cost me quite a lot of time and inconvenience
<lifeless> jml: there is a bug. its a real pain.
<lifeless> jml: there is a plan too; I believe vila is working on it.
<LeoNerd> Mmm... gotta love sshfs. I've double-mounted router -> server -> desktop via sshfs. bzr on my AMD64 2.2GHz desktop is still faster, over all that, than bzr natively on the AMD Geode 266 router.
<hersonls> can i ignore all symlinks in a repo with .bzrignore?
<bialix> .bzrignore is filenames pattern matching, not file kind pattern matching
<lifeless> no, though that might be an interesting extension; some way to say that an ignore rule applies by kind
<hersonls> exists another way to do this?
<bialix> hersonls: one can write pre_commit hook to blacklist symlinks from commit?
<hersonls> bialix, i go see in documentation how do this
<hersonls> a pre_commit
<SamB_XP> lifeless: so should someone make a ticket requesting that?
<LeoNerd> Ugh... Why is Module::Pluggable soooooo slow?
<LeoNerd> It takes 7 seconds on my slowtiny AMD Geode 233
<LeoNerd> er... wrongchannel ;)
<bialix> hersonls: you can look at the checkeol plugin
<bialix> it has pre_commit hook check
<orattue> Hey I am moving from a backup of an old repository to a new one and have run into a small problem when pushing the revision history.
<orattue> http://pastebin.com/vZ8UPDkU
<orattue> When I push to my new repo it becomes a working tree but I want to keep this a treeless repository. How could I achieve this?
<fullermd> Just use remove-tree to get rid of it?
<orattue> fullermd: perfect many thanks
<lelit> hi all, is there a command to get rid (if at all possible!) of .bzr/obsolete_packs, after a branch taken out of svn?
<MvG> Hi! I just noticed that RegistryOption.from_kwargs adds arguments to the help text in the order kwargs.iteritems() returns them, which seems to be arbitrary and in particular not the one they were given at invocation time. This yields to non-deterministic help texts, which shouldn't be a real problem but feels a bit ugly nevertheless. Opinions?
<jelmer> MvG: I agree
<jelmer> lelit: not yet afaik, other than rm -rf .bzr/repository/obsolete_packs
<MvG> So maybe I should file a bug.
<jelmer> MvG: or submit a patch :-)
<lelit> jelmer: that's good enough, if its safe :)
<MvG> jelmer: I'm not sure enough what the "right" approach would be. Alphabetical order? Or is there a way to get at the argument order of a **kwargs?
<lelit> are those effectively garbage-able?
<jelmer> lelit: generally, yes
<MvG> Is there a proper way to include the help text of the alternatives of a RegistryOption in the generated help? RegistryOption.from_kwargs does that, but when I use a proper registry I don't see a way.
<krisives-gearbox> Does bzr support scripts in .bzr/hooks ?
<LarstiQ> anyone know where I should ask to have my two bazaar-vcs.org wiki users merged? (openid based and old style)
<fullermd> I gave up and hoped to $DEITY I'd never have to change any of my settings.
<LarstiQ> fullermd: well, I do :)
<MvG> jelmer: For the record: Filed bug 559409, attached a branch and requested a merge.
<ubottu> Launchpad bug 559409 in bzr "RegistryOption lists help strings in arbitrary order" [Undecided,New] https://launchpad.net/bugs/559409
<MvG> I just hope such a trivial fix can do without NEWS item.
<bialix> MvG: hi
<MvG> bialix: hi!
<bialix> I have a question on trac-bzr
<bialix> MvG: https://answers.launchpad.net/trac-bzr/+question/106783
<bialix> can you comment on that?
<MvG> I wonder why I haven't seen a mail for this...
<bialix> MvG: maybe because there is no answer contact set?
<MvG> Probably.
<bialix> I'm not sure how this part of LP supposed to work
<MvG> Grrrr! news_merge seems to be causing backtraces.
<marcingy> hi - just wondering if there is anyway to prevent a file being committed as part of a bzr commit command. The file is part of the tree but I have a need for a specific local change for testing purposes that doesn't need to be committed to the trunk ever. and I don't want to have to cotinually remember to enter bzr commit .
<bialix> MvG: for bzr-explorer we have answer contact set to bzr-explorer-dev group, and therefore we get notifications on the questions and answers
<bialix> marcingy: maybe you need to use loom or pipeline plugin to keep your changes in separate place?
<MvG> Now that I've reported bug 559436 I can return to that question...
<ubottu> Launchpad bug 559436 in bzr "AttributeError: 'NoneType' object has no attribute 'get_config'" [Undecided,New] https://launchpad.net/bugs/559436
<LarstiQ> marcingy: that, or consider commit -x
<marcingy> thanks and I'll go and have a look at loom and pipeline
<MvG> bialix: answered.
<bialix> thx
<bialix> heya LarstiQ ! how are you?
<LarstiQ> bialix: heya! :) Done well with studies so far, but pressure building up again with several deadlines
<bialix> are you planning to attend UDS?
<LarstiQ> ah, there is one coming up again I guess
<LarstiQ> bialix: no, not so far
<bialix> I understand
 * LarstiQ has been focusing on studying, little time for anything else
<LarstiQ> bialix: ah, and I still have lectures and one exam in that week, so no
<LarstiQ> bialix: how about you?
<bialix> I'll be there
<bialix> first time to meet all legendary bzr hackers
<LarstiQ> cool :)
<bialix> yeah :-)
<fullermd> _all_?  Better hope an asteroid doesn't choose that time and place to fall on...
<bialix> fullermd: if there won't be you then of course not all, but many
<LarstiQ> or one very big bus
<fullermd> Legendary bzr hacker?  Me?  I guess that's true...   my great bzr hacks never really happened, which makes them pretty dang legendary   :p
<LarstiQ> bialix: will you be in Brussels the weekend after UDS?
<bialix> fullermd: common, I'd like to meet you anyway, you adding the charm to this channel :-)
<bialix> LarstiQ: no, fly away at Saturday
<fullermd> Well, exactly.  If I went somewhere, what would the channel do while I was gone?   8-}
<bialix> LOL
<bialix> that's true, silly me!
<fullermd> Have a sprint in my backyard, I'll be there.
<fullermd> It's beautiful this time of year, and for probably at least another week, or even two.  Then it gets mother-letching hot and miserable.
<bialix> what it means "mother-letching"?
<LarstiQ> bialix: ok, I'll see if I can maybe be there on Friday evening then
<fullermd> It's a content-free emphatic.  A polite euphemism for a more profane way of saying it.
<bialix> ok, got it
<fullermd> ...  OK, not especially polite, but at least politER.
<MvG> Is someone around here empowered to make me either an additional or the sole owner of the LP trac-bzr-team?
<lifeless> MvG: its owned by ~bzr
<lifeless> MvG: so I could transfer ownership, but why? Perhaps administrator is what you want?
<jelmer> MvG: thanks (for filing that bug report about option ordering)
<MvG> lifeless: Dunno what the difference between ownership and admin is. I only realized that I couldn't make the team the answer contact, and assume it's due to missing privileges. You could make me admin, see if that helps.
<mwhudson> lifeless: i don't know, sorry
<dark_soul> how do we change the commiter name? without having to reininstall
#bzr 2010-04-10
<dark_soul> bzr whoami 'your info'
<dark_soul> in case someone is interested
<Boobek> bye
<l0de> The l0de radio hour is now online! stream up at www.klulz.com , call in live at 914 502 2625! Tonight's Episode: THE DOWNTOWN MOTOWN SHOWDOWN AND THROWDOWN SO BRING YA HOW DOWN NIGGA U BOUT TO GET CLOWNED
<bignose> Committing to a particular remote repository gives:
<bignose> Doing on-the-fly conversion from RepositoryFormatKnitPack4() to RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n').
<bignose> This may take some time. Upgrade the repositories to the same format for better performance.
<bignose> but when I attempt to upgrade it, Bazaar asserts there's nothing to do:
<bignose> $ bzr upgrade --format 2a bzr+ssh://bzr.debian.org/bzr/collab-maint/python-daemon/python-daemon.debian/
<bignose> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
<lifeless> bignose: are you upgradeing a branch perhaps
<lifeless> oh
<lifeless> bignose: the remote repository is 21
<lifeless> bignose: the *local* one isn't
<lifeless> s/21/2a/
<bignose> hmm, checking
<lifeless> thats the the mesage indicates
<bignose> well spotted. but how did you spot that?
<lifeless> the error string: RemoteRepositoryFormat(_network_name=...) - thats what repositories using a proxy object over bzr:// protocols show as
<bignose> thanks.
<lelit> hi all
<lelit> I'm still in the process of converting a bunch of svn repo to bzr. The standalone repos seems in good shape, and I am now trying to group them with the "externals" plugin
<lelit> I have a "metarepo" containing just external refs to a few repo
<lelit> the test I did some days ago worked great, but now "suddenly" cloning such metarepo gives me a desolately empty repo, with 0 revision in it... it completely misses any ref to the externals
<lifeless> lelit: your terminology is confusing me
<lifeless> you can't clone repos in bzr
<lelit> uhm, sorry lifeless, I'm still learning the new terminology :)
<lelit> isn't "clone" an alias of "branch"?
<lifeless> yes
<lelit> this is my migration script: http://pastebin.com/vd7KBEmG
<lifeless> a repository is just a database
<lifeless> it can't be pushed/branched/cloned/anything
<lelit> ah, so what I call "repository" is a "branch" instead?
<lelit> you know, I'm coming from darcs, where there isn't such distinction
<lifeless> I would guess; you're the one that knows what you mean :)
<lelit> :)
<lelit> ok
<lelit> the script above will create a "metarepo", containing .bzrmeta/externals pointing to the bzr-based branches of my svn repos
<lelit> but when I "cd /tmp; bzr branch .../metarepo" I don't get those
<lelit> I'm just blind :)
<lelit> I need to commit, after all those eadds! :-)
<lelit> sorry, caffeine is not circulating yet
<lelit> gosh, this works ok on bzr 2.1.1, but fails with 2.0.1
<lifeless> ok
<lifeless> well 2.1.1 is nice ;)
<lelit> http://pastebin.com/DK73EFtY
<lelit> eh! unfortunately on debian/lenny there is 2.0.3 in backports
<thumper> lifeless: the config object passed into Commit.commit is ignored
<thumper> lifeless: is that right?
<lifeless> thumper: no; but you should be calling tree.commit, not Commit.commit
<thumper> lifeless: I am
<thumper> but I'm following the path through
<thumper> MutableTree.commit calls Comit().commit(...
<thumper> the Commit object __init__ method can set self.commit
<thumper> the config object passed in to the commit method of Mutable tree seems to be ignored to me
<thumper> ...
<thumper> not mutable tree
<thumper> the Commit._commit method
<thumper> I'm wanting to set the committer of the revision to be wikkid, but the author to be the author
<lifeless> thumper: its a regression
<lifeless> added by spivs run_cleanups stuff
<thumper> hmm...
<thumper> lifeless: how can I set the signing policy for a branch?
<lifeless> thumper: well, I say regression
<lifeless> its an ambiguous interface
<lifeless> :q
<thumper> it should use the passed in config like the reporter several lines above
<lifeless> no
<lifeless> ambiguous like I say
<thumper> why not?
<lifeless> hang a sec
<thumper> I'm thinking line 347 of bzrlib/commit.py
<lifeless> http://pastebin.com/hxtjLNp0
<lifeless> apply that patch
<thumper> I'll work around it for now, hopefully by setting the branch signing policy
<lifeless> please don't
<lifeless> its a regression, I'm just submitting the fix
<thumper> funny, yesterday you were saying don't override the config
<lifeless> I still say that
<lifeless> but my point is to honour what the user has configured
<thumper> if it is operating as a webapp, that is a very bad idea
<lifeless> if you are going to override it, passing in a new object is the cleanest way IMO
<lifeless> thumper: sysadmins are users too
<thumper> I don't get the reference
<lifeless> if its running as a webapp
<lifeless> then the configuring person is the sysadmin
<thumper> right
<lifeless> who may well want commits on the server to be signed
<thumper> but you don't want it prompting for a password
<lifeless> *I* would
<lifeless> why would it prompt in such a setup
<thumper> fair call
<thumper> I've added a TODO in the init method to allow using the users signing policy
<thumper> I intend to honour it
<thumper> just not right now
<lifeless> see, it seems to me you are adding code you don't need to
<lifeless> thats my whole point here
<thumper> well, right now I don't want to change my default config
<thumper> I have signing on
<lifeless> don't change it
<lifeless> you can override for your test wikis in 2 lines in ~/.bazaar/locations.conf
<thumper> which is way I said before, how do I set the signing policy for a branch
<lifeless> or in branch.conf
<lifeless> review wanted: https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/23150
<thumper> does branch.conf go with the branch?
<thumper> on push?
<lifeless> no
<lifeless> but I'm not sure how that affects your dev environment
<thumper> it doesn't
<thumper> I was just wondering
<lifeless> I'd like to have some stuff propogate
<lifeless> currently nothign does
<lifeless> what would you need to be happy with its behaviour for you ?
<lifeless> no signing for wikki branches?
<lifeless> thumper: ^
<thumper> I'd like it to work as people expect
<lifeless> ok, me too :)
<lifeless> *I* expect things using bzr to honour my bzr settings.
<thumper> I found it surprising that it asked me to sign my commit when I hit save on the webpage
<lifeless> but you seem to be annoyed that you're getting signing prompts
<lifeless> so I'd like to teach you how to turn that off, for your wikis.
<thumper> just in locations.conf?
<lifeless> thats what I
<lifeless> thats what I'd reach for first in this case, I think.
<thumper> I'll go with that for now
<thumper> I agree that in a server setting it would make sense to use the config settings
<lifeless> [file:///tmp]
<lifeless> create_signatures = never
<thumper> I'll go with honouring bzr expectations
<lifeless> what bzrlib do you have installed btw
<thumper> nightly ppa
<abli> Hi! If I created a branch in a shared repository, do I need to do anything special when I want to delete it? or simply rm-ing the directory will do?
<thumper> abli: that works
<thumper> abli: it won't however remove the revisions from the repository
<abli> where are the revisions actually stored? in the repo's .bzr, so the branch-directories' .bzr contains no revision data, only some metadata?
<lifeless> right
<lifeless> thumper: http://pqm.bazaar-vcs.org/
<abli> Would deleting the branch now and later creating a branch with the same name be a problem? (Storing the revisions is not a problem in my case because they are quite small, so I won't care about the wasted space), but I want to avoid confusing people with old and obsolete branches
<lifeless> thumper: have you seen the progress bar ? :)
<lifeless> abli: no problem
<thumper> lifeless: nice
<lifeless> abli: or at least, no technical problems. *you* might get confused though
<lifeless> thumper: subunit :)
<abli> you mean if I create a branch with the same name, revisions from the old branch will come back?
<lifeless> abli: no
<lifeless> abli: I mean you might not remember if its the old or new branch, in a couple of weeks time :>
<abli> oh. Ok, I'll remember to keep that straight then.
<abli> Thanks everyone!
<sipsniffa> testing the addition of files from within the current project directory and below using: bzr add --dry-run **/*.py
<sipsniffa> none of *.py in the current directory get added. am i missing something?
<lifeless> sipsniffa: your shell isn't matching them
<sipsniffa> i understand ** to mean zero or more
<lifeless> sipsniffa: any reason you don't just do 'bzr add' ?
<lifeless> sipsniffa: and let bzr find all unignored files and add them for you
<sipsniffa> i can drop the ** from **/*.py and get all the current directory py files
<sipsniffa> probably the only reason is that i'm unfamiliar with bzr conventions and ways of working
<lifeless> sipsniffa: the usual way is to setup bzr ignore rules for things you don't want to version
<lifeless> and use 'bzr add' - just that - to add things automatically
<sipsniffa> ok, will go that route
<sipsniffa> still curious to know whether ** pattern matching is misbehaving
<lifeless> check your shell's man page
<lifeless> its outside bzr's control, unless you are on windows
<sipsniffa> i've done bzr help patterns
<lifeless> on windows bzr does the expansion
<sipsniffa> linux
<lifeless> right
<lifeless> bzr doesn't see the **/*.py
<lifeless> if you look in ~/.bzr.log
<lifeless> you can see the command line bzr is being given
<lifeless> your shell - e.g. bash, or zsh, or whatever - is expanding the **/*.py
<sipsniffa> k, just tried quoting the pattern: bzr add --dry-run '**/*.py'
<lifeless> bzr won't glob expand though :)
<lifeless> that will add the file '**/*.py', if you had one
<sipsniffa> gives an error!
<lifeless> as I said, you need to check the documentation for your shell under 'GLOBBING'
<sipsniffa> k
<sipsniffa> thanks for the pointers, lifeless
<bialix> igc: ping
<igc> hi bialix
<bialix> igc: what dependecies I should install?
<igc> bialix: for the installer stuff?
<bialix> yes, you have asked me to look at bzr-windows-installer script
<igc> if you have the latest stuff, it will build the windows help but it expects ...
<igc> sphinx 0.6 and make
<bialix> I'm lacking the fresh info about bzr build dependencies
<igc> http://wiki.bazaar.canonical.com/BzrWin32Installer is the place to start
<igc> but you no longer need pycurl and cog
<igc> and zlib gets installed for you
<igc> bialix: any particular questions? I'm heading to sleep real soon now
<bialix> that page is awfully outdate as I can see
<igc> yes, I've been meaning to update it :-(
<igc> next week hopefully
<bialix> I don't have questions because I'm trying to figure out what I need to install
<igc> do you have the old stuff installed still?
<igc> the key bits are ...
<bialix> no, for python 2.6 I have nothing
<igc> python + pytqt + paramiko + sphinx + ms help compiler + innosetup
<bialix> ms help compiler?
<igc> for sphinx, start with setuptools, then easy_install it
<bialix> C compiler?
<igc> yes, you'll need one, either visual C or Mingw32
<igc> also pyrex
<bialix> can you put the dependencies version to simpleplain text file in the branch with script?
<bialix> maybe tomorrow or the next week, maybe
<igc> yes, that's the plan
<igc> bialix: http://www.microsoft.com/downloads/details.aspx?familyid=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en
<bialix> igc: so perhaps we need to continue this odissey tomorrow or then next week, good night!
<igc> bialix: I'll type something up tomorrow if I can
<igc> bialix: night
<bialix> that's ok, sleep well
 * fullermd sure is glad to be on a *nix system   :p
<bialix> fullermd: :-P
<jml> I accidentally resolved a directory conflict by deleting the directory
<jml> the commit that did that is way back in the history of my branc
<jml> but it turns out that the project won't build without this (empty!) directory
<jelmer> jml: can't you just re-add it with the same file id?
<jml> jelmer, same file id? I didn't know you could do that
<jml> jelmer, how would I do that?
<jelmer> jml: you can't really specify a file id, but you can have 'bzr add' use the file id the same path has in another tree
<jelmer> jml: so if you have an old copy of lp around you can use 'bzr add --file-ids-from=lp:launchpad/devel path/to/empty/dir'
<fullermd> Easier to use revert.
<fullermd> Just find a rev where it existed and revert -rwhatever dir
<jelmer> fullermd: that won't readd the dir though right?
<jelmer> fullermd: and if it's not added to the working tree, it won't have a file id
<fullermd> Er, it certainly SHOULD.
<fullermd> It works fine on FILES.  And dirs are just files in pink tutus.
<fullermd> If it doesn't, that's a glaring bug that needs to be fixed.
<sebi_`> what would be the reason for bzr not to upload certain files and/or directories when pushing a revision? I had to repush for the third time now. note that all files and directories are read and writable, and owned by my systemuser
<bialix> sebi_`: bzr does not update remote working tree usually, only those on the local disk
<sebi_`> okay
<sebi_`> well, some of the files in the revision were empty, even though they aren't in the local source tree
<jelmer> fullermd: you're right sorry. I never use revert with -r
<sebi_`> ah well. if that's the only thing i'll have to live with, then i'll live with it. :P
<bialix> sebi_`: if you need to upload files to remote location look at bzr-upload plugin
<sebi_`> I was just talking about `bzr push $branch`, but i'll take a look at the bzr-upload plugin
<bialix> there is also push-and-update plugin
<MvG> FYI: I've just released version 1.1.0 of the bzr-bash-completion plugin, including completion for registry-based options.
<jelmer> MvG: nice
<MvG> I've also filed bug #560030 to get something done about the horribly outdated completion scripts included in the bzr source tree. If you want to discuss it, I'm all ears.
<ubottu> Launchpad bug 560030 in bzr "Shell completion scripts outdated" [Undecided,New] https://launchpad.net/bugs/560030
<MvG> I'd be particularly interested in opinions as to whether bzr-bash-completion should be included with bzr itself, either now or in the forseeable future. I have no strong opinion either way, but it has been suggested to me by users, and I'd like to know what you think.
<jelmer> doesn't bash itself also ship with some completion scripts?
<jelmer> I think it should be shipped either with bzr or with bash
<MvG> I assume that the bash progcomp api is far more stable and also a lot simpler than the bzr plugin and options api. Therefore I'd keep it with bzr.
<MvG> I don't think bash ships anything related to bzr, but I'll check. I know zsh does ship a completion function.
<MvG> Nope, neither bash 4.1 nor bash-completion 1.1 (from http://bash-completion.alioth.debian.org/ ) ship anything bzr-ish.
<MvG> By the way: what are the steps turning a merge proposal at LP into an actual merge performed by PQM? And which of these steps are automatic? Do I need a certain number of approving comments, or approval by the right person, or either of these? Is there some document outlining this process?
<jelmer> MvG: you need to approvals from bzr committers
<jelmer> MvG: s/to/two/
<jelmer> MvG: the merge is submitted manually by a pqm committer, usually through "bzr lp-land" or pqm-feed (from hydrazine)
<MvG> Thanks!
<RobOakes> Hi, I am getting a very strange error when I try and import from an SVN repository.  bzr: ERROR: Unable to convert Subversion path help/hits/LaTeX\docs because it contains characters invalid in Bazaar.
<RobOakes> Does anyone know how I can by-pass this error?  The file it references is a documentation file and not really important to my merge.
<jelmer> RobOakes: Bazaar doesn't allow backslashes in paths
<RobOakes> Is there any way that I can exclude that one file?  Or can I update just the project src directory?
<jelmer> RobOakes: I think the only real option is to use something like fastexport/fastimport that allows you to remove the backslash from the stream before importing it into bazaar
<RobOakes> Do you know if there is a tutorial that explains how to do that?  (I'm a pretty novice bzr user.)
<jelmer> I'm not aware of one, but that doesn't say a lot.
<RobOakes> Any idea on how I could use fastexport/fastimport to do what you describe?
<RobOakes> I'm trying to merge bugfixes made to an svn version of the bzr branch.
<RobOakes> Thanks, I found a way around the problem.  There are only a few folders that I need to merge.  The merge works if I only update those selected folders.
<sebi_`> okay, I think i've figured out why some files were missing when pusing a new revision; I forgot to add them. :P
#bzr 2010-04-11
<bendj> I'm using -- or trying to -- bzr-eclipse with Eclipse35 (Galileo).  I've created a new project by doing a Checkout (heavyweight) from a remote server to a local project.  Works great.  I then edit locally, and exec a commit.  My understanding was that @ commit in this HW checkout, the changes are auto-pushed back to the original branch at the remote server.
<bendj> It seems that that IS the case -- but I still need to do a 'bzr update' *AT* the server to see the pushed changes.
<bendj> Is that 'expected' behavior?
<fullermd> Yes.
<bendj> fullermd: Must reread the docs, then :-(  Is there a brz command to execute at the local box to get that final update @ the server to occur?  Or do I have to log in and do the update at the server?
<fullermd> Well, yes and no...
<lifeless> you can install the push-update plugin
<lifeless> the branch on the server gets the changes immediately you commit, its just the user content that isn't updated (because its hard to do well)
<fullermd> bzr doesn't deal with working trees remotely.  The push-and-update (what lifeless said) turns 'push' into 'push ; ssh foo bzr up'.
<fullermd> So, it does log in and do the update at the server, just automatically.
<bendj> fullermd: lifeless Ok, have the plugin.  Thanks.  BUT, it's gonna NOT be available to the Eclipse plugin until it's integrated, right?  For now, just available at cmd line ... or ?
<fullermd> I dunno.  At one time I thought the Eclipse plugin called the CLI fairly remotely on the backend, in which case the push would DTRT there.
<fullermd> Though I don't remember if p-a-u ever actually integrated hooking into commit at all, now that I think of it, so it may not do what you want in a checkout anyway...
<fullermd> Dunno though.  I remember it was discussed.
<bendj> fullermd: Ok, I'll look thru mail archives for it.  Having the plugin installed doesn't seem to change anything in the eclipse interface :-/
<fullermd> Basically, when you start talking about either one, you're way off my turf; I just know the right-sounding words to describe parts of it   8-}
<bendj> fullermd: Ah, you're in Marketing ;-p
<fullermd> I...    oooh!  Why, you...
<bendj> Coulda been worse ... Sales!
<bendj> Posted a question abt push-and-update integration into the Eclipse intfc at Launchpad.  Thanks folks!
<AndrewLuecke> g'day, I hate to bug you guys again, but anyone else experienced really slow code browsing on their server? ie: http://develop.getnightingale.org/browser/nightingale
<AndrewLuecke> does it in loggerhead and trac..
<MTecknology> I'm getting this error when I try to push a branch - bzr: ERROR: Server sent an unexpected error: ('error', 'mail is not installed !?')
<MTecknology> sendmail is installed on that server
<MTecknology> I also installed bzr-mail
<MTecknology> oh - bsd-mailx required too
<MAfifi> I've recently begun to use bzr(coming from mercurial background). I'd like to know if bzr has a command corresponding to mercurial's "hg update -r <rev>".
<MAfifi> I mean if I want to assess some functionality or bug in an old version...
<LarstiQ> MAfifi: not sure what hg update -r does exactly, but I'm guessing it's `bzr update -r` or `bzr revert -r`
<MAfifi> I've just tried; there's nothing as "bzr update -r ...".
<MAfifi> bzr revert -r seems to work however, it restores the status of the target revision to the working tree(causing dirty changes to the tree, but that isn't a big problem anyway).
<LarstiQ> MAfifi: what version of bzr is that? (Also, it helps if you prefix with my nick so irc highlights)
<jelmer> MAfifi: newer versions of bazaar have 'bzr update -r'
<LarstiQ> seems to be introduced in 2.1.0rc1
<MAfifi> LarstiQ: I've version 2.0.0.
<LarstiQ> MAfifi: that explains it
<MAfifi> LarstiQ: So should I get a higher version?
<LarstiQ> MAfifi: personally I'm fine with `bzr revert -r revno; # check situation; bzr revert` to inspect and return to current state
<LarstiQ> MAfifi: but you can upgrade to 2.1.0 if you want, it's been out for 2 months now
<MAfifi> LarstiQ: Thanks, I found that in 2.1.0 rc1 release notes "bzr update now takes a --revision argument. This lets you change the revision of the working tree to any revision in the ancestry of the current or master branch. (Matthieu Moy, Mark Hammond, Martin Pool, #45719)"
<LarstiQ> MAfifi: yup :)
<BiosElement> Hmm, anyone hopefully know a solution to this bug? http://paste.ofcode.org/FMFft2e3Lb7JnGAMDyYWPf
<vila> BiosElement: it may be bug #375898 if you previously merged an external branch (unrelated at the time of the first merge)
<ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Fix released] https://launchpad.net/bugs/375898
<BiosElement> Aye, that sounds like it vila.
<vila> BiosElement: or something else, the messages about the progress bars sound like a quite old version of bzr, try upgrading it first
<BiosElement> vila: if only it were that simple. It's bzr 2.1.1.
<vila> BiosElement: the fix for the bug above is not yet in any release (it will be soon), so you may need to use the branch associated with the bug
<BiosElement> Aye, I'm looking at compiling it for use.
<vila> BiosElement: I'm just passing around and it's late here, if you still have problems, try the mailing list or file a bug (if your branch is public, add the url)
<BiosElement> Aight, thanks vila.
<vila> or come back tomorrow :)
<BiosElement> Heh, aight
<lifeless> moin
<jelmer> 'morning lifeless
<jelmer> lifeless: I finally managed to get around to writing that per_bzrdir_color branch; was much easier than I expected, thanks for the hints.
<jelmer> *colo
<lifeless> jelmer: cool
<lifeless> thats really encouraging
<igc> morning
<igc> hi lifeless, jelmer
<jelmer> Hi Ian
<lifeless> hi igc
<lifeless> ugh
<lifeless> quick sanity check
<lifeless> > /usr/lib/python2.6/dist-packages/bzrlib/transport/local.py(484)stat()
<lifeless> that does a 'stat()'
<lifeless> not an 'lstat()'
<lifeless> is it just me or is that nuts ?
#bzr 2011-04-04
<poolie> biab
<Stavros> hello
<Stavros> how can i convert a bzr repo to a git repo by dpushing with bzr-git?
<jelmer> Stavros, hi
<Stavros> jelmer: hey jelmer
<jelmer> Stavros, didn't I help you do that last week ? :)
<Stavros> you did :(
<Stavros> i'm missing a step now
<Stavros> i did git init and git init --bare and dpushed to it
<jelmer> you need a bzr init as well
<Stavros> but i keep getting "/mydir" is not a branch
<Stavros> ah
<Stavros> that was it, thanks
<Stavros> bzr init --git
<jelmer> git init /tmp/foo; bzr init /tmp/foo; bzr dpush /tmp/foo
<jelmer> there's no need for the --git
<Stavros> ah, yes
<jelmer> (if you're creating a branch in a git repository we always create a git branch)
<Stavros> but if you don't have a git repo in there, you can do bzr init --git and it still works
<Stavros> ah
<spiv> Good morning.
<poolie> hi spiv
<spiv> Hi poolie
<poolie> hi, how are you?
<poolie> spiv could you be pilot this week?
<spiv> Sure!
* spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.4b1 is officially out (ppa:bzr/beta needs love)
<poolie> thanks; i updated the rota
<vila> hi all !
<spiv> Hi vila
<vila> spiv: _o/
<poolie> hi there vila, spiv
<poolie> vila, what's up for you today?
<vila> poolie: config :)
<poolie> the whole hog? :)
<vila> poolie: nope, a minimal set (excluding locking/minimal IOs/option registry) but enough to look at deplying/migrating
<vila> deploying
<poolie> you know i'd really like a new caller ui :)
<vila> poolie: just tell me which ;)
<poolie> sorry, api, not ui
<vila> poolie: ... or let's discuss it on my proposal, I think we are roughly on the same page so it shouldn't be too far from what you're expecting
<vila> poolie: of course if you speak earlier it would be even closer :D
<poolie> :) i might still have a mail starred to reply to
<poolie> i have a call in 20m but perhaps i can do it after that
<poolie> i thought i did reply
<vila> poolie: I'm processing my inbox so I may not have seen it yet
<vila> oh, hmm, just noticed the PP update, I won't be able to do it the whole week (vacations), who should I switch with ?
<poolie> i haven't replied after your last mail
<poolie> whoever
<poolie> you're not up this week
<poolie> can swap with me i think
<poolie> for some reason i really prefer .config_stack; i feel there's already going to be some risk of confusion about particular files vs stacks
<poolie> maybe not though
<poolie> why do you put "sections (read-only and mutable)" first?
<vila> poolie: I'm talking about *next* week, and I can't switch with you either as I won't be there from 2011-04-13 to 2011-04-27 ;)
<vila> poolie: bottom-up
<vila> poolie: TDD is easier for me when implementing from the lower levels first
<vila> poolie: regarding .config vs .config_stack, the only cases where you want to use the config file directly is to modify it and even there you could do it via the stack, so somehow, devs shouldn't manipulate config files directly, only the user should really see them as an entry point (like command-line options or env vars)
<vila> poolie: I can be persuaded otherwise but I think that if we change the API now, it's to also change the mental model, and configs should be seen as stacks rather than files
<spiv> vila: are they always files?  I would expect that e.g. bzr-svn branches may provide some config-like values without having a config file.
<poolie> ok
<vila> spiv: indeed, they are stacks built from stores (the first store will be based on ConfigObj) but other stores can be implemented as long as they can give us sections
<poolie> actually i don't strongly prefer it anymore ; i did on friday but not now
<vila> really, I don't think I'm reinventing wheels here, just shuffling the design a bit around what we already do while getting rid of many hackish parts
<poolie> i think so too
<poolie> i can see why afc thought it was complex
<vila> it may appears I'm not, but really, that's my intent
<poolie> i do still kind of feel smaller steps are possible
<vila> how small ?
<vila> or rather,
<vila> at which point does the cost of wiring the smaller steps become higher than leapfrogging a couple of them ?
<AfC> U+200D ZERO WIDTH JOINER small!
<vila> AfC: :)
<poolie> for example just changing the internal api not to construct global configs all over
<vila> ha, and how do you ensure you won't have to do that twice ?
<vila> or do it without adding stuff we'll delete later ?
<poolie> i don't
<poolie> it's a risk
<poolie> on the other side you have to weigh the risk of doing preparatory stuff that's not actually delivering value yet
<poolie> so if i was reading that list properly, what's first?
<vila> poolie: you mean section/abstract store/stacks ?
<poolie> yes
<vila> so section are first
<vila> I already have some stuff tested/coded for sections and stacks, I blocked a bit on store Friday for the locking part, so I wrote some thoughts about it and will focus on using the existing scheme
<poolie> so just to make sure i understand
<poolie> when you say section, this is about letting the stack choose to use just one section from inside a particular file?
<vila> s/wrote some thoughts/wrote some thoughts about the new locking scheme allowing allowing minimal IOs/
<poolie> like in looking at  locations.conf it'll pick out the relevant sections and slot them in?
<vila> a selection of sections yes, like matching_sections does today for locations.conf
<vila> but allowing that for any store
<vila> nothing fancy either for now, only what exist: globs (which is mainly used as just paths today)
<vila> oooh, col*l*ocated !
<vila> is that indeed the correct spelling ?
<poolie> i think there would be one
<poolie> co-located
<vila> hmm, so using 'colocated' is just stripping the '-' in identifiers ?
<vila> err, as in python identifiers or paths
<poolie> yes i think so
<poolie> did i spell it the other way somewhere?
<vila> k, will do that then
<vila> poolie: not you, ispell
<vila> (0) co located (1) co-located (2) collocated
<poolie> i know of 'collated'
<poolie> http://en.wikipedia.org/wiki/Collocation
<poolie> interesting
<vila> right, this page only used 'located' once in collocated, I can go with co-located if you prefer
<spiv> I think that's jargon that isn't referring to a particularly similar concept
<vila> or may be we just don't care :D
<poolie> which page?
<vila>  http://en.wikipedia.org/wiki/Collocation
<spiv> And that page links to http://en.wikipedia.org/wiki/Colocation_%28disambiguation%29 which links to http://en.wikipedia.org/wiki/Colocation_%28business%29
<poolie> "go with co-located if you prefer" where?
<poolie> vila, can you either take, or assign to yourself, one or more bugs about config
<vila> poolie: certainly
<vila> poolie: thanks for the reminder, I should have done that long ago
<spiv> http://en.wiktionary.org/wiki/colocation suggests that with or without the hyphen are both used.
<vila> spiv: excellent ! There is even (and indeed) http://en.wiktionary.org/wiki/colocated
<vila> jelmer: hi
<poolie> vila, for our stuff, 'colocated
<vila> poolie: yup, I've already reverted to that
<spiv> jelmer: I just gave you a review, of sorts, finally: https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/54958
<poolie> vila, so at the end of this, what sections will we have
<poolie> just locations, or also others?
<vila> sections anywhere and their definition should be file specific, but for bzr itself, urls (as of today) for bazaar.conf/locations.conf (or only paths/globs there) and probably relative paths for others
<vila> some plugins may want to use different schemes for sections (window names for GUIs for example ?)
<vila> or hosts for authentication.conf (which uses arbitrary section names today and relies on their definition order rather than matching)
<vila> I don't intend to modify authentications.conf until we need too though
<vila> but the point is that sections are a different way to look at partitioning the options and it's best to leave that part open if you can
<vila> err if we can
<jam> morning vila, getting yourself out of PP rotation I see ?
<vila> jam: hehe, pushing down the stack yeah :D
<vila> sorry I didn't realize that earlier
<vila> poolie: by the way, stacks were somehow implemented in bzrlib/rules.py too
<poolie> ok
<poolie> i might stop for today
 * vila cries, compiz shortcuts gone again....
 * spiv stops for the day
<jelmer_> vila is skipping patch pilot duty ? :)
<vila> jelmer_: yup, and to add insult to injury, he's taking vacations, what a shame :D
<jelmer> (-:
<DeeLay> I have a feature branch that has been merged into trunk, I need to undo that merge continue working on the feature branch, and then re-merge the feature branch back into trunk at some point in the future.  Any suggestions on the best approach?
<vila> DeeLay: depends on two things: is the trunk public, do you still have your pristine feature branch
<vila> if you still have your feature branch before the merge, just keep working on it
<vila> you'll merge it to trunk later, only additional changes will appear on trunk at that point
<vila> for the trunk, there are two ways: either it's public and people already have pulled from it so you need to merge a reverse of your changes
<DeeLay> vila: trunk is not public, but it is the branch we release from.  The feature got cancelled at the last minute, so we need to pull it from trunk, so that other features can be released without needing to do cherry picked releases
<vila> it's not public or nobody had pull from it (always hard to ensure but) you can just push --overwrite -r<revno-before-the-merge>
<vila> s/^/if/
<vila> DeeLay: is the above clear enough or do you need more details ?
<DeeLay> vila: yeah I think that makes sense, I'll give that a go, thanks
<vila> DeeLay: if your merge is the last commit on trunk, you can also 'bzr uncommit' there and 'bzr revert [--no-backup]' or 'bzr clean-tree' to get rid of the *~ files created by revert
<DeeLay> vila: unfortunately not, and the last time I uncommitted a merge, it didn't re-merge the changes later
<vila> DeeLay: right, so you have other commits on top of your "faulty" merge, more care needed
<vila> DeeLay: you probably need to revert this merge explicitly then 'bzr merge -r<revno>..<revno>-1' <revno> being your merge
<vila> DeeLay: and commit the result with a message explaining the issue for future references if some other dev built on top of your merge *including* parts you wanted to remove,
<vila> DeeLay: you *should* be able to detect such cases when you merge the reverted change, but evil is in the details...
<DeeLay> vila: yeah that was my first attempt, but that means merging trunk into the feature branch (to keep it upto date) would remove the changes from the feature branch
<vila> DeeLay: no, you can do that on the trunk itself
<vila> DeeLay: it will be clearer there for everybody involved (hopefully)
<DeeLay> yeah, that's what I mean, so if I bzr merge -r <revno>..<revno-1> in trunk, I can effectively remove the changes introduced by the feature branch
<DeeLay> in the meantime dev work will continue, so i will need the feature branch to keep up to date with other changes being merged to trunk
<vila> DeeLay: now, on your feature branch, you can add more changes and merge the overall in trunk again when needed, you may encounter conflicts then though
<DeeLay> but from the feature branch, bzr merge trunk, will remove the changes that the feature branch introduced to trunk from the actual feature branch
<vila> haa, that, yeah
<vila> well, the sooner you merge trunk to your feature branch, the sooner you'll address the possible conflicts
<DeeLay> also tried bzr revert -r <revno-1> in trunk, which gets round the commit of the reverse merge issue
<DeeLay> but in that scenario, re-merging the the feature branch comes back with "nothing to do"
<vila> DeeLay: well, revert will also revert all subsequent commits so probably not what you want
<vila> DeeLay: the reverse merge is called a cherry-pick, it doesn't track the ancestry so it finds no new *revision* to merge
<DeeLay> vila: yeah, but I can live with that if it worked, as the other changes could be re-merged.  The essential problem is that trunk will always remember that the reverted commits happened, so it won't re-merge them
<vila> DeeLay: that's why you need to merge trunk again after that into your feature branch: to ensure that your branch carries the right changes
<maxb> <DeeLay> but from the feature branch, bzr merge trunk, will remove the changes that the feature branch introduced to trunk from the actual feature branch
<maxb> There's a way to avoid this, let me explain:
<maxb> Step 1: Merge the revision of trunk immediately prior to the revert commit as normal
<maxb> Step 2: Merge the revert commit and *only* the revert commit from trunk, and do "bzr revert .", and commit that
<maxb> At this point you now have a feature branch which says "I know trunk reverted these changes, but *I* am going to keep them"
<maxb> And I believe they should even merge sensibly back into trunk when you have another attempt to land the feature.
<jelmer> vila: have you heard anything more about the SRU?
<vila> jelmer: no :-/
<DeeLay> maxb: if I merge trunk, then revert, there will be nothing to commit, won't there??
<maxb> Note carefully: "bzr revert .", not "bzr revert"
<DeeLay> maxb: ah, nice
<maxb> This will revert all the tree changes, whilst keeping the "I have merged revision X" metadata
<DeeLay> maxb: that totally worked, reverse cherry picked from trunk, merged trunk to feature branch, and then tried a dry run of re-merging the feature branch into trunk and the changes come across again
<DeeLay> thanks guys
<idnar> so, this is sort of related to the conversation from earlier
<idnar> -c 123 is equivalent to -r 122..123; is there any equivalent to -r 123..122 ?
<jam1> idnar: no shorthand form, though X..before:X works for all types of X
<idnar> yeah... bleh
<idnar> was writing an automated script, and my revisionspec is already 10 pages long :P
<maxb> Yes, a backwards -c would be very useful
<maxb> Subversion uses a negative number for this, but that's already taken in bzr. Took me a while to un-train my fingers from that one.
<jam> vila, jelmer: testing question. I'm working on bug #740932, and I want to test that we cache the correct packed-stat value even though Transform does stuff like renaming the file after it is created.
<ubot5> Launchpad bug 740932 in Bazaar "building working tree doesn't update sha cache" [High,Confirmed] https://launchpad.net/bugs/740932
<jam> The specific problem is that the time to create and rename the file runs in under 1s
<jam> which is the granularity of our sha cache test.
<vila> touch the file with a specific time ?
<jam> I'm trying to find a tasteful way to test it
<jam> vila: so the point is that Transform is creating the file
<jam> how do I touch it
<jam> (where/when?)
<vila> from the test ? hmm or from some hook triggered by a test decorated class ?
<vila> that's not the first time I'd like to better control the clock, but here you want to observe a fs behaviour which is trickier
<jam> vila: yep
<jam> it does call os.rename
<jam> which I could hack into
<jam> but that is pretty ugly
<vila> how about reducing the 1s to 1us ?
<vila> for tests I mean
<jam> vila:  not optional
<vila> make it so :)
<jam> Dirstate's packed-stat is integers only
<vila> ouch
<vila> hmm
<vila> how about changing its scale then
<vila> again, for tests
<vila> or may be you should have different tests for the different effects you want to observe
<jam> vila: I *really* don't think we want to be hacking into compiled code and adding if checks in our tight-loop functions
<jam> vila: the issue is that in the real world, it can take several seconds from the time we start creating files until we've finished the last one. which gives us plenty of files whose state we can cache
<jam> but we have to be careful because we also rename the top-level ones right before we finish
<jam> I wonder if I need to worry, because that rename is probably never going to be outside our 3-second window
<vila> what do you want to test ?
<jam> it doesn't help that Dirstate caches's its threshold time to the first time it checks
<jam> vila: this is what I have so far
<jam> at the point where we have Transform.create_file
<jam> I store the sha1 and stat value of the file
<jam> at the point that we have finished creating all of these files
<jam> I then call Tree._observed_sha1 for everything I cached
<jam> there is one step inbetween, where Transform renames all the files into place
<jam> thus changing their 'ctime'
<jam> but we could be saving the sha1 value with the new ctime
<vila> huh ? renaming change the ctime of the containing dir not of files itself right ?
<vila> err, mtime
<jam> vila: renaming the *file* changes the ctime of the *file*
<vila> ctime as 'creation time' ??
<jam> vila: stat
<jam> ctime == last meta-info changed time
<jam> on *windows* == creation time
<jam> on Linux something different
<jam> (we've talked about not paying attention to ctime, but we currently do)
<vila> and you want to avoid calculating the sha1  for files that were only renamed ?
<jam> vila: *today* after doing 'bzr co' the next 'bzr st' will re-read every file to check if it is up to date, and re-sha the content
<jam> which is affecting eg linaro, because it takes >1m to re-sha the whole tree
<jam> so bzr branch-for-feature ; bzr st; bzr commit; takes longer than it should
<vila> yeah, I've read your analysis
<vila> and you want to avoid calculating the sha1  for files that were only renamed ?
<vila> or touched by the transform
<jam> vila: I already have code that handles the 'create_content' part
<vila> rhaa, calculate only for files modified, yeah, create_content
<jam> I can easily add code that handles the "and the files are renamed into place" part
<jam> vila: but I don't know how to test it
<vila> ISTM you're trying to test from too high, get closer to the code that you want to test
<jam> note, I just realized my changes need some updating, but I have a handle on that
<jam> vila: so step through TreeTransform.apply inlined into a test case and assert the dict values?
<jam> I really don't want to rewrite the apply function
<jam> because of drift, etc.
<vila> err, no, I thought about where you establish that a file need to be re-hashed
<jam> vila: well, with my first fix, the test accidentally succeeds, because the file doesn't look like it needs to be rehashed
<jam> because the timestamp didn't actually tick over 1 second
<jam> because the 'rename' happened within 1s of the creation
<jam> which doesn't happen in reality
<jam> because creation can take a minute for large trees
<vila> because you exercise too much code to properly test what you care about (is what I'm trying to explain :--/)
<vila> if you go closer to tiny part you care about, you should be able to be more precise
<vila> or is this code inlined in a compiled extension ?
<jam> vila: the code that compares to see if a file is up to date goes through packed_stat which truncates to 1s resolution.
<jam> (we compare packed_stats)
<vila> inject them
<vila> you're telling me that you can't have a test with sleep(3s) right ?
<vila> so you have to change at least one constraint succeed :) The clock seem too hard, so that leaves faking the data based on this clock
<jam> vila: I could detect it with a sleep(1)
<vila> well, sleep(1) is bad :)
<jam> or hacking os.rename to add a os.utime to mutate mtime to fake the ctime change
<vila> sleep() is bad
<jam> since you can't directly touch ctime
<LeoNerd> I'm not sure you're -guaranteed- to notice a ctime tick using sleep(1)
<LeoNerd> sleep(1) asks to sleep for no more than 1000ms.
<jam> LeoNerd: while round(time.time()) == orig_time: time.sleep(...)
<vila> as long as it's explained in the test *that* sounds better but involving os.rename() in your test seems like enlarging the scope of the tested code too
<vila> jam: said otherwise: you seem to be writing a blackbox test when a unit test could be more precise
<vila> "blackbox" with quotes
<vila> jam: blackbox as in: not allowing to observe directly what you want to test
<jam> vila: testing that 'bzrlib.transform.build_tree" has the sha hash values correct doesn't seem particularly 'black box' to me.
<jam> and the lifetime of the caching has to be across the TreeTransform.apply stage.
<jam> because you don't want to try to save the sha1 until you're done, to give it the best chance to be outside the 3s window
<vila> jam: given that this function is more than 100 lines... it's hard to *not* consider it as an opaque box with a lot of side effects
<vila> jam: the aim is good but it doesn't mean you can't test a building block
<vila> ow, and it uses a 50 lines _create_files() too...
<jam> vila:  a fair amount of it is if blocks that you can avoid. by not setting accelerator_tree, etc.
<vila> right, I'm beginning to feel your pain :-/
<vila> jam: can't you split out the part you're interested in ?
<vila> jam: how many existing direct tests for _build_tree ?
<jam> vila: by re-writing Transform.apply
<vila> jam: good luck with that :-(
<jam> and I still don't really know how to handle making sure we get the correct time for top-level files
<vila> jam: anything smaller ?
<jam> anyway, I have a couple other bits to fix now anyway.
<vila> jam: you may be just be facing a hole in the test suite :-/
<jam> vila: so I could fake TreeTransform state, call one of the functions on it, and assert the after state
<jam> but TT state is pretty big, too
<vila> jam: a known one for that matter
<vila> ok, so, best effort would indeed be to write blackbox tests here :-/ Sadly that means adding more tech debt...
<vila> what {worries me|makes me sad} is that you end up talking about TT when you care about a packed_stat which TT doesn't even know about
<vila> jam: from the you-wish-you-did-it-long-ago dept: use an in-memory fs and control its clock ! :-}
<jelmer> jam: hi
<jelmer> jam: do you know how significant the memory usage improvements between 2.2.3 and 2.3.1 are in terms of fetch performance ?
<jam> jelmer: you'd have to read the release-notes. I don't think it is huge, though.
<jam> jelmer: stuff that accesses all chk pages can be quite a bit cheaper, I guess
<jam> jelmer: "bzr ls -R" dropped from 400MB to 250MB, which is roughly equivalent to fetching a reasonable amount of data
<jelmer> jam: ah
<jelmer> jam: the fix you did after the gcc performance analysis hasn't ended up in a release yet right?
<jam> jelmer: that is the "iter_entries_by_dir()" change?
<jam> I don't think that has been released
<jam> jelmer: actually, according to release-notes it is in 2.4b1
<jelmer> ah, cool
<vila> jam, jelmer: according to the https://launchpad.net/bzr/+milestone/2.4b1 changelog, it is not
<vila> jam: did I copy the wrong changelog or did you merged in the wrong section ?
<jam> vila: lp only counts things that you target the bug to
<vila> jam: I'm talking about the changelog the RM copied at the time the release was frozen
<jam> vila: ah
<jam> it landed in 5730
<jam> it certainly could have been merged into the wrong section
<jam> since that happens *by default*
<vila> and 2.4b1 is 5727
<vila> jam: no worries, just wanted to make sure jelmer got the right stuff
<jam> vila: so I found a better way to poke at it. Use 'os.utime' between the time that we call create_file, and the time that we call .apply
<jam> it is actually asserting something that doesn't happen, but it would catch a real bug
<barry> i'm having a problem trying push a branch to launchpad. it seems like bzr and hg are fighting each other for some weird reason.  on natty.  i get:
<barry> bzr: ERROR: No such file: /~barry/mailman/restusers/.hg/requires
<barry> but this is a bzr branch in a shared repo and hg shouldn't enter into it!
<barry> (there is no .hg directory in this directory)
<barry> i do have bzr-hg installed however
<jelmer> hi barry
<jelmer> barry: That's bzr-hg, although that bug should be fixed
<jelmer> barry: how do you have bzr-hg installed?
<barry> hi jelmer.  apt-get install bzr-hg
<jelmer> barry: the one that was synced today, or from earlier?
<jelmer> barry: can you give the bzr-hg in the bzr daily builds PPA a try?
<barry> jelmer: from a few days ago.  apt-get upgrading now :)  i'll let you know if that fixes it
<bpierre> hi
<bpierre> is the PQM version used by the Bazaar team the one from lp:pqm?
<barry> jelmer: that did the trick.  thanks!
<jelmer> bpierre: approximately
<bpierre> jelmer: :P, patched?
<bpierre> I have been looking into it
<bpierre> I managed to make it somewhat work
<jelmer> bpierre: To be honest, I think we're just using lp:pqm but I'm not sure
<bpierre> ok
<bpierre> so do you know if your version work by making a direct lightweight checkout of lp for each merge?
<bpierre> I see no activity on the lp code page for the project
<jelmer> I'm pretty sure pqm creates a full branch, and that's what we're seeing too
<bpierre> and a number of branches marked in developement and not merged...
<bpierre> so branch lp:bzr, with tree, and then merge?
<jelmer> bpierre: pqm is pretty much dead upstream; bzr (and launchpad too, IIUC) are looking to move to tarmac long term
<bpierre> tarmac?
<bpierre> ok, I'll look into it
<bpierre> PQM, I add to make a number of patches, and still less than optimal ;(
<jelmer> lp:tarmac
<bpierre> yeah, seems to be tied to launchpad ;(
<lifeless> jelmer: pqm's not dead, just not being changed unless there is a defect
<lifeless> bpierre: yes, we run trunk of lp:pqm without patches
<bpierre> lifeless: ok, so unless I missed something, everytime a merge is attempted, pqm does a lightweight checkout of the target branch, right?
<lifeless> bpierre: yes, clean slate each time
<bpierre> I see no support for caching
<bpierre> so for a big working tree, a lot of network traffic
<lifeless> bpierre: so, what you can do is use a local tree and set the published_to option
<lifeless> s/tree/branch/
<lifeless> it will checkout locally (no network traffic) and do a push afterwards
<bpierre> mmm, but I still need to update this local tree somehow, no?
<lifeless> as long as pqm is the way things are landed this works fine; if you manually push to $wherever, then you need to do a manual push to that local branch too
<lifeless> it would be quite reasonable to file a bug asking for a more transparent cache facility
<bpierre> ok, I also ran into an issue with the way a working tree name is constructed, plus ploblems with encoding
<bpierre> I also patched it for merge directive support
<bpierre> (there is already a branch in lp, but with conflicts, and another I did not see until after making the patch)
<bpierre> anyway, I wonder if the support for other VCSs is of interest?
<lifeless> do you have some tests in your branch? I hesitate to incorporate changes which can break silently on future changes
<bpierre> I understand completly
<lifeless> the other vcs support is maintained by other vcs folk
<bpierre> is it used?
<lifeless> it used to be :) I have no idea now.
<lifeless> theres no requirement that new features work on all vcses
<bpierre> because I add to bypass some abstractions, to support merge directive inlined in a mail
<lifeless> ah
<bpierre> plus the code looks complicated
<bpierre> at least to me :P
<lifeless> it is, it started as a simple script
<lifeless> and gew
<lifeless> *grew*
<bpierre> the lack of documentation also does not help
<lifeless> code level docs?
<lifeless> there is a docbook manual for users
<bpierre> yeah, I'm starting to think it might be simpler to just start from scratch
<bpierre> I'm problably way understimating the time it will take :D
<lifeless> thats the usual thing
<bpierre> the docbook manual in the code is not really helpful
<bpierre> I add to look at the code and experiment
<lifeless> so, caching transparently should be easy - have an option, say, 'cache_repository' and when thats set use bzrlib apis to cache the tip revision of the branch
<lifeless> construct a temp branch in it during the merge - a few lines of code
<bpierre> yeah, a few lines there, and few lines somewhere else... :P
<lifeless> for your merge directive support; if it doesn't break other vcses, and you wouldn't mind if I broke it by mistake fixing other things, then it doesn't /need/ tests.
<bpierre> I can't help to notice that every plugin that need to merge dupplicate parts of the bzrlib code for the merge builtin
<lifeless> yeah
<bpierre> *from the
<bpierre> one question about the bzrlib API: is there a way to get the canonical URL for a branch?
<bpierre> the only way I found is by opening it and looking at base
<bpierre> what I mean is correctly expand lp:bzr to bzr+ssh://....
<bpierre> or expand my local bookmark bm:something to the real URL
<bpierre> ?
<maxb> bpierre: bzrlib.directory_service.directories.dereference(url) ?
<bpierre> maxb: ok, I'll try
<ps_jinx> spiv: I am getting this bug http://psjinx.pastebin.com/yxS2PNGm .. what can be the issues
<jelmer> ps_jinx: That's a known bug related to proxies; it's fixed in newer versions of bzr.
<ps_jinx> jelmer: but I'm able to pull the code successfully
<jelmer> ps_jinx: that's a different code path
<ps_jinx> ok
<poolie> hi all
#bzr 2011-04-05
<michaelh1> Hi there.  I'm using feature branches for development.  How can I find the revno of mainline that I branched from? (Google doesn't help)
<michaelh1> bzr missing ../mainline, taking the lowest revno of the feature branch changes, then subtracing one would work but it's ugly...
<lifeless> theres a find-merge-ancestor or some such, or log -r ancestor:../trunk
<poolie> find-merge-base i think
<lifeless> note that where you branched is not supported at all, only where you have merged up to (which is subtly different :))
<poolie> well, where you branched from, or where you last pulled up to, is possible to compute
<poolie> but i don't think there's any ui to get it
<michaelh1> OK.  That gives me a revid, and I can use bzr log to turn that into a revno
<lifeless> michaelh1: try bzr revision-info -r ancestor:path/to/trunk
<michaelh1> lifeless: ta, that does it.  revision-info isn't in man bzr or bzr help commands...
<poolie> https://bugs.launchpad.net/bugs/748141 asks for it to be shown
<ubot5> Ubuntu bug 748141 in Bazaar "Please unhide some hidden commands" [Undecided,New]
<poolie> filed just yesterday ironically enough
<spiv> Good morning
<poolie> hi there spiv!
<poolie> spiv, i'm just looking at some of the branch privacy setup issues on lp
<poolie> then, i'm going to push a bit on our srus, do a few reporting chores, and then push on my in-progress branches
<poolie> also, bug 740932 is perfect john-bait :)
<ubot5> Launchpad bug 740932 in Bazaar "building working tree doesn't update sha cache" [High,Confirmed] https://launchpad.net/bugs/740932
<spiv> I thought he was already working on that, actually :)
<spiv> Ah, yep.
<poolie> exactly
<lifeless> http://yaxu.org/cyclic-revision-control/
<poolie> interesting
<poolie> i think maxb is on the right track with a wiki page showing how the ppas are getting along
<poolie> maybe i will make a similar thing for srus
<vila> hi all !
<poolie> hi there vila
<poolie> how are you
<vila> fine, good progress on configs
<poolie> vila, good
<vila> I don't quite get your comment on bug #725234
<ubot5> Launchpad bug 725234 in Bazaar "config doesn't provide a --section parameter" [Low,Confirmed] https://launchpad.net/bugs/725234
<maxb> You mean DailyPpaStatus?
<vila> poolie: what could be simpler than [~/work]\nfoo=bar\n in bazaar.conf ?
<maxb> That was useful - on the other hand, ProposedPpaStatus ceased to be particularly useful after I had the first big push to bring it up to date
<maxb> Speaking of PPAs, I need to write a status email about the twisty chaos of dh_python2/pycentral/pysupport
<vila> maxb: +1
<poolie> yes
<maxb> But yes, in general: If you don't have time to code a status tracking webapp: Use a wiki! :-)
<vila> maxb: and its impact on the beta ppa ?
<poolie> vila, my point is that i'm not sure if at the ui level users should be thinking about sections
<poolie> maxb so it's kinda tracked in bugs
<poolie> certainly more so than the ppa failures
<poolie> but, perhaps not really clearly enough
<poolie> vila  if you can find the time helping spiv with reviews could be good
<poolie> the page is really long
<vila> poolie: what's wrong with that ? It looks like a common practice to me, especially if sections allow grouping so you DRY
<maxb> I don't think the beta ppa is blocked on anything - just lower on my priority list than bringing the dh_python2 backport magic up to speed and in its final form
<poolie> let me back up
<vila> maxb: ok
<poolie> in the case of my example where they want to set some policy for a particular directory (and children)
<poolie> what do you think the user would say?
<vila> bzr config foo=bar --scope bazaar --section ~/work
<poolie> how does that work?
<poolie> can bazaar.conf have per-directory sections?
<spiv> FWIW, my initial reaction is that â--section ~/workâ feels a bit weird.  There's nothing obviously âthis for a locationâ in that command to my eyes, except by inferring it from the ~/work bit which looks like it's probably a directory name.
<spiv> (reaction to that hypothetical command line)
<vila> that's the plan, yes, to replace their abusive use in locations.conf which should define overriding options while bazaar define defaults
<vila> section names can't be inferred, they need to be specified
<vila> (when they are paths/globs)
<vila> supporting them fill the gap that requires hand editing today
<spiv> I don't understand why there's a beneficial difference between "define per-location setting in a section in bazaar.conf" and "define per-location setting in a section in locations.conf"?
<poolie> hm
<poolie> me either
<spiv> Unless the goal is to remove locations.conf entirely.
<poolie> also, i think the ui should be something like
<poolie> bzr config --location ~/work foo=bar
<poolie> which can internally may to "section ~/work in file locations.conf"
<vila> locations.conf is (and has always been) defined for *overriding* settings in branch.conf
<vila> that's not the way people expect it to be but that's the way it is implemented
<spiv> vila: oh *branch.conf*
<spiv> You said bazaar
<vila> I said bazaar because I thought poolie wanted defaults
<vila> poolie: not all section names will be locations
<spiv> Hmm.
<vila> poolie: if we had an easier way to parse options dynamically, they could depend on --scope, but that seems quite complicated
<spiv> I kinda like that only locations.conf is defined as having section name == location glob
<vila> why ?
<spiv> I wouldn't want DEFAULT in bazaar.conf to suddenly match a directory I have that happens to have that name
<vila> I want to get rid of DEFAULT
<vila> exactly because it can conflict
<spiv> Well, or any other section type :)
<vila> same same :)
<spiv> And ALIASES?
<vila> yup
<vila> bzr.aliases.mylog
<spiv> Hmm
<vila> I think it's described explicitely in http://doc.bazaar.canonical.com/devnotes/configuration.html
<vila> tly
<spiv> That's uglier to look at than what we have now :/
<vila> can you elaborate ?
<spiv> Sorry, I haven't made time to read and digest that doc yet :/
<spiv> Well,
<spiv> [ALIASES]
<spiv> commit = commit --strict
<spiv> Is really clear and obvious I think
<vila> we *don't* have a way to specify defaults values per location *and* define exceptions in branch.conf today
<spiv> And bzr.aliases.mylog is not quite as much.
<spiv> Sure, I'm not disagreeing with that :)
<spiv> It seems to me there's a namespace problem with section names
<vila> *because* sections have been used in bazaar.conf
<spiv> Right
<vila> indeed
<vila> spiv: have a look a bzr-bookmarks
<spiv> So why not disambiguate by having location-matched sections be called [location:/path/...] ?
<poolie> i think we need to be clear about what sections are for
<poolie> are they basically part of the namespace of the option
<spiv> Or even [location /path/...]
<vila> spiv: it uses *both* a section [BOOKMARKS] in bazaar.conf *and* prefixed options in branch.conf
<poolie> iow it's really ALIASES/commit
<poolie> or are they something used to select which values are active
<poolie> at the moment it's a bit of both
<vila> poolie: the later
<vila> exactly
<vila> using a hierarchical name space for options is powerful enough to free the section namespace
<vila> so the section namespace can be used for other things
<vila> for bazaar.conf, locations.conf, branch.conf and even tree.conf, repo.conf, rules and so on path/glob sounds good enough
<vila> but plugins may decide differently which is why I'm trying to not *force* path/globs for section names
<spiv> But you have?
<vila> not yet
<vila> err, not so far ?
<vila> and hopefully never
<spiv> In your scheme, how can a plugin define e.g. [explorer] as a section and avoid having it match that path?
<spiv> Sorry if I'm making you repeat your doc!
<vila> because sections are selected when building the stack and this selection can be file-specific
<spiv> In general though I think it'll be hard to understand for users if sections are mostly one thing but occasionally another.
<spiv> e.g. see how I'm confused right now ;)
<vila> it's used only by locations.conf today and implemented in LocationConfig, so I just have to *not* reuse that code or reuse it in the right place
<vila> not if documented by file
<spiv> Oh, you're saying that in a plugin-specific conf file section names can have a different meaning?
<vila> yes
<spiv> Ok, but then it's the same as today?
<vila> qbzr can use window names for example
<spiv> locations.conf uses them as locations, nowhere else does.
<vila> I'd rather use the name space too for that but for the sake of the example
<spiv> Is the main issue you want to solve that we can currently only define per-location overrides, and can't define per-location defaults?
<vila> spiv: yes, nobody does *today*, but still, people use path as sections to define defaults in locations.conf (which breaks if you define exceptions in branch.conf), so given them section as paths in bazaar.conf address the need
<vila> that's one issue yes, dunno if it's the main one
<spiv> Well, I can think of less radical changes that would solve that issue :)
<vila> the main one is to be able to define option values that apply to various contexts without duplication
<vila> spiv: yes ?
<spiv> Add a location-defaults.conf (and maybe rename locations.conf to location-overrides.conf), for instance.
<spiv> Or allow bazaar.conf to contain e.g. [location-match /pathâ¦] section names.
<vila> ah, yes, that's not ruled out, but you still need to support section that are not *only* path/glob
<spiv> Not saying these are better, but they would appear to require less change, at least in how users write out and read options.
<vila> err, you still need to move parts of locations.conf to another file  right ? Why is that less changes ?
<spiv> Well, I don't need to rewrite my ALIASES section
<vila> spiv: and have you tried adding a conf file to BranchConfig ? And have it supported by RemoteBranchConfig ?
<vila> haaa, I didn't say [ALIASES} will disappear at once
<vila> It can still be supported and deprecated in the future to address the collision issue
<spiv> Or otherwise rewrite any options, unless I want to change any existing per-location stuff I have from being an override
<spiv> (And off the top of my head, I think I want most of my per-location conf to be overrides)
<spiv> In my alternative, ALIASES wouldn't ever need to be removed
<spiv> Also, it's a bit interesting that your way could perhaps allow per-location aliases
<spiv> I'm not sure if that's a good or bad thing
<spiv> I definitely don't want branches to even look like they can define them though!
<vila> the starting point was to use --location instead of --section, if you want to keep ALIASES, you want --section
<vila> spiv: you can't decide that for *all* options, but you can defined that for *some* options
<vila> s/defined/define/
<vila> anyway, the implementation under work is about *allowing* more control, the current design just doesn't scale for the already existing (and unanswered) needs
<vila> it gives ways to clear the section name space so it can be better defined and extended,
<vila> I won't implement more than paths/globs to start with because it's not needed *yet*
<vila> I won't implement selecting which config files allow which options either for the same reasons
<poolie> vila, i really don't want to get one big "take it or leave it" patch
<vila> poolie: which is why I'm creating different threads so they can be reviewed and discussed independently
<poolie> but you know that :)
<vila> the aim is that the first implementation should be 100% compatible with the existing config files
<vila> *then* and only then, can we start discussing migration plans for new features (including removing [ALIASES] and [BOOKMARKS], allowing sections in bazaar.conf, etc)
<spiv> I think you'll get a negative reaction from users if you make simple things like alias definitions less pretty than "foo = command --args"
<spiv> ICBW :)
<vila> bzr alias can very well stay and be re-implemented on top of the new design to start with
<vila> see 100% compatible above
<spiv> It's great to have nice command line UI inspecting and updating various config settings
<vila> implementing -Ofoo=bar is just... beyond me with the actual design
<vila> with the new one, it will just be adding a new read-only section in stacks that want to support it
<poolie> i might have a stab at that
<poolie> then either we will get the feature, or i will stop telling you it's easy :)
<vila> :)
<vila> poolie: don't forget bzr.config.expand :-p
<poolie> what about it?
<poolie> maxb, jelmer, i started http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates
<poolie> is pretty ugly
<poolie> i feel it ought to have red and green bits but i'll get to that later
<vila> poolie: expansion should be able to cross configs, especially for -O or it won't be taken into account
<poolie> hm
<poolie> i don't feel that is as important as the other config bugs
<maxb> poolie: It looks good, and it calls to my attention an issue - what are our plans re lucid - which is, after all, an LTS
<vila> poolie: for the sake of the experiment, have a look at it to avoid having to fix it twice, pretty please
<vila> poolie: +1 on maxb
<vila> poolie: I'm all for handling 2.2 *first* but 2.1 should be seen as dead yet
<poolie> vila my plate's pretty full so these are idle threats :) but i will
<maxb> In fact, in the greater scheme of things, 2.1 is more important - not that it necessarily needs to get done first, but it's more important that it actually gets done
<poolie> we should do it too
<poolie> i mean we should do 2.1 too
<vila> poolie: not a threat, more like getting an apple-to-apple comparison ;)
<vila> poolie: expand_options is currently implemented for Config and that's a blocker for expansing across config files (without going into quite complicated implementations)
<vila> poolie: it really should be implemented on stacks
<poolie> no, i mean "i'll do it" is an empty threat
<poolie> :)
<poolie> anyhow, i'm probably getting to the point of just holding you back
<poolie> hm making this page is quite good
<poolie> might be better as a little api client app
<poolie> later
<vila> poolie: ha, that, yeah, hehe
<poolie> ah, maxb, what's happened
<vila> hmm, expanding not expansing ;)
<vila> let's not start about performance issues ;D
<poolie> ok, fixed
<poolie> hm, what's the most interesting bug fix in https://launchpad.net/bzr/+milestone/2.3.2
<poolie> 616878 will do
<jam> poolie: 733350 is probably the biggest regression sort of bug
<poolie> yeah, the other one might hurt more people
<poolie> it's a bit arbitrary
<poolie> ok
<poolie> i'm a bit scared of uploading to -proposed, and i need to go out soon, so i'm not going to do it tonight
<poolie> but i will tomorrow
<poolie> good night all
<lool> Hey
<lool> I'm looking for a way to override specific bzr settings via the environment
<lool> To be precise, I'd like to override the email address used in commits
<elmo> lool: BZR_EMAIL ?
<lool> elmo: Oh gosh, thanks!
<lool> elmo: EMAIL doesn't override the config, but BZR_EMAIL does
<lool> elmo: Thanks  :-)
<jam> lool: you might also want "bzr whoami --branch" if you want to configure it for specific areas.
<spiv> Is it just me, or does bzrlib.log._apply_log_request_defaults unintentionally mutate the _DEFAULT_REQUEST_PARAMS var?
<vila> spiv: you're probably right that it was unintentional (you're definitely right that it mutates it ;)
<jelmer> jam: Thanks for the reviews :)
<jam> jelmer: happy to keep the queue flowing. Thanks for all the work :)
<jam> jelmer: for some reason pqm seems a bit slower to me. Have you noticed a difference?
<jelmer> jam: I haven't noticed anything, but I usually just send things off and then look at the email later so I probably wouldn't notice if it got slower either.
<jelmer> jam: is cython preferable over pyrex? We seem to prefer pyrex at the moment.
<jam> jelmer: we are stuck with a pyrex dependency (we support pyrex 0.9.6 or whatever)
<jam> however, Cython is a lot nicer if you have a choice
<jam> meliae is cython only
<jelmer> jam: shouldn't we prefer cython in setup.py in that case?
<jam> jelmer: hysterical raisons
<jam> I would be fine changing that
<jam> the main issue is the *code* that you get to write
<jam> not so much the final performanec
<jam> performance
<jam> you get to write "cdef list foo; foo.append()" rather than "PyList_Append(foo, ...)"
<jelmer> isn't cython supposed to be better performing?
<jam> jelmer: there are a few things internally that are a little better. I don't have a great feeling about real-world perf
<jelmer> ah, it's just that certain pythonish code gets more efficiently processed by cython?
<jam> they do stuff like "likely()" macros, etc.
<jam> jelmer: right
<jam> that is the *big win*
<jam> however, if we have to do the work under Pyrex, then it doesn't matter whether we use Cython or Pyrex
<jam> we could use "cdef list foo" in Pyrex, if we bumped the minimum version to 0.9.8
<jam> or something like that
<jam> jelmer: did you see my reviewe for "lazyimport-scope-etc" ?
<jam> I just got a submit failure
<jelmer> jam: Yep, thanks
<jelmer> jam: A submit failure on lazyimport-scope-etc, or the 2.3->bzr.dev merge?
<jam> lazyimport-scope-etc, I just copy and pasted it into the form
<jelmer> jam: ah, thanks
<jelmer> jam: do we have any way to remove the generated .c and .py files from e.g. the makefile?
<jelmer> I can't find one (other than bzr clean-tree, which isn't usable here)
<jam> jelmer: I don't know of any generated .py files
<jam> I usually do "rm bzrlib/*.[ch]; bzr revert"
<jam> wow, bzr-vimdiff was still in *knit* format
<jelmer> jam: ah, there aren't any, I'm being stupid...
<jam> jelmer: there certainly are generated .c and .h files
<jam> which would be nice to have a simple clean target for
<jam> but I don't know of any
<fullermd> https://bugs.launchpad.net/bzr/+bug/130783
<ubot5> Ubuntu bug 130783 in Bazaar "`make clean` should clean up after pyrex" [Wishlist,Confirmed]
<jelmer> fullermd: the problem is that make clean shouldn't remove those files, they're included with the tarball
<jam> jelmer: make dist is used to generate the tarball
<jam> which uses 'make clean && make && copy .c/.h files'
<jam> so make clean could delete them
<jam> unless it is a debian-thing
<jelmer> jam: that means that a user who has the tarball unpacked and runs "make clean" ends up deleting his copies of those files
<jam> fairy-nuff
<jelmer> s/his/their/
<jam> http://en.wikipedia.org/wiki/Singular_they
<jam> (I personaly like singular they)
<jam> jelmer: so it should be under dist-clean?
<maxb> It is of particular annoyance that there does not seem to be any consistent file name pattern for what is autogenerated and what is not
<jam> maxb: it is pretty straightforward, .pyx => .c, .h, _api.h
<jam> well, you only get _api.h under certain circumstances
<jam> and we're *pretty* good about naming it all _pyx.pyx
<jam> so that you get foo_pyx.c , etc
<maxb> jam: Not so - there are files matching *_api.h and *_pyx.h which are source-controlled
<jam> maxb: sure, I was thinking about it in the reverse direction.
<maxb> It looks like *_pyx.c are all autogenerated, as are *_pyx_api.h
<maxb> However _simple_set_pyx.h is autogenerated, whereas _bencode_pyx.h (for example) is not
<jam> maxb: I think changing the _*_pyx.h to only have auto-generated files would be reasonable
<jam> I think we have 2 (maybe 3) of them
<jam> which is our way of adding extra DEFINE sort of things to the pyrex code
<jam> but we could do a new notation for those
<maxb> bencode, dirstate_helpers have a _*_pyx.h that is human-written
<maxb> There's also _static_tuple_c.h
<jam> maxb: _c.h
<jam> not _pyx
<maxb> yes - just pointing out the close similarity
<jam> _static_tuple_c is specifically '_c' because it *isn't* from Pyrex source
<jam> maxb: we could probably move both of those into python-compat.h and be done with it
<jam> it is 2 defines for bencode, and a special-cased (by platform) import logic for dirstate_helpers
<maxb> That sounds like a promising solution. And it would make a suitable Makefile clean target easy
<maxb> Although given how bencode-specific those two macros are, perhaps we should have _bencode_pyx_helpers.h
<maxb> This is of particular interest to me since the daily-ppa recipe builds are currently failing due to stale pyrex generated files :-)
<jelmer> maxb: that's what prompted me to look at this
<maxb> I have thus far been unable to figure out why natty is working and the rest are failing :-(
<jam> maxb: so why does the recipe builds have compiled pyrex lying around. Shouldn't it all be built from scratch?
<jam> or is it the -maverick building after -natty that is re-using the dir
<maxb> It gets imported from the tarballs into the debian packaging branches
<maxb> For some indeterminate reason, the natty build is seeing the timestamps such that it should rerun pyrexc, the rest are not
<jelmer> the convention is that distclean removes the files generated by configure, which we don't have
<jelmer> I'll add a "make realclean"
<gypsymauro> hi
<jelmer> hi gypsymauro
<magcius> if I have a bunch of changes in my working dir,
<magcius> is there a way I can "clear" them to the last known thingy?
<magcius> revision
<jelmer> magcius: bzr revert
<magcius> oh
<magcius> I did that, but saw "M foo.py"
<magcius> and I didn't do a status afterwards
<jam> magcius: right, it is just telling you what things it changed
<magcius> that's confusing
<jam> magcius: would you rather we change things without telling you we did so?
<magcius> I told you to change things with bzr rever.
<magcius> revert.
<magcius> I don't really need to know what changed, as long as you "did the right thing."
<jam> sure, though if you issue a bare revert, you may not realize *what* things changed
<ovnicraft> hello i am using v2.3.1 always after push the transport does not update my remote tree, so can i configure or pass any arg to update my remote tree automatically?
<jam> ovnicraft: you can install the 'bzr-push-and-update' plugin
<ovnicraft> jam thanks
<marvin2> If "bzr pull" updates the local working tree, what is the use of "bzr update" (apart from use with checkouts)?
<marvin2> Anybody?
<maxb> moving the working tree to historical revisions?
<maxb> updating the working tree if something went wrong during an update after a pull?
<magcius> er
<magcius> can I rewrite the last commit message? I just made a typo.
<LeoNerd> uncommit / commit again. But that's kinda evil
<LeoNerd> (it's rewriting history)
<magcius> Uh, I promise to use my powers for good?
<marvin2> maxb: Thanks.
<marvin2> I have the following situation: Have 2 branches A and B, both synced at rev 2. A goes from rev 2 to 3 while B goes to rev 4. I then merge changes from A to B; A stays at 3 and B moves to 5. I then push B to A which makes them identical.
<marvin2> Can I undo the last step so that I don't lose A's history?
<maxb> You lost no history
<marvin2> maxb: Sorry, let me rephrase that
<marvin2> Can I undo the last step so that I don't lose A's "perspective" of things?
<marvin2> I'll pull in changes from B.
<maxb> If you locate A's previous tip revision, you can use pull / push --overwrite to reset A to it
<marvin2> maxb: 3 in this case, if I understand "tip" correctly.
<marvin2> ?
<marvin2> But the revision numbers have been inherited from B
<maxb> revnos are meaningful only in the context of a branch. what was r3 in A before you pushed B into it is not necessarily the same revision as r3 in A now
<marvin2> maxb: Yeah, so how do I identify the "tip" of A before I pushed the merged version of B to it?
<maxb> You must browse history (e.g. using "bzr qlog") and pick it out through your knowledge of the branches
<marvin2> bzr qlog. Thanks!
<marvin2> maxb: Unknown command
<maxb> part of the qbzr extension
<marvin2> maxb: Looking into it right now. Thanks for the pointers.
<ls3> Hello. I have a large repo and accidently deleted a single file. I don't want to commit this change but do want to re-download a copy of that file.
<ls3> How can I get that single file back into my local repo?
<ls3> (ops...deleted a single file from my local repo is what I mean...)
<maxb_> bzr revert filename
<ls3> got it with bzr cat
<ls3> Appreciate it
<Odd_Bloke> Is there a bug open for "bzr mkdir -p"?
<jelmer_> Odd_Bloke, I believe so, though I don't have the bug # here..
<Odd_Bloke> Launchpad's search is being useless.
<Odd_Bloke> I guess because basically all bug reports have mkdir in. Â¬.Â¬
<achiang> hello, i'm having a little trouble with bzr merging
<achiang> i'm in branch A, merged B
<achiang> discovered a problem in B, so i reverted B (or so i thought i did)
<achiang> now i'm ready to test B again, so i try to merge again
<achiang> but nothing is actually happening
<achiang> changes introduced by B do not appear in A after the merge; i've tried --reprocess and that doesn't seem to help
<achiang> oh joy, i guess i've found https://bugs.launchpad.net/bzr/+bug/152008
<ubot5> Ubuntu bug 152008 in Bazaar "Ability to unmerge or revert a merge sensibly" [Wishlist,Confirmed]
<lifeless> achiang: did you commit after merging, before the revert?
<achiang> lifeless: hm, this was a while ago, let me think...
<lifeless> if you did, you can just revert/uncommit back to that point
<lifeless> but yeah, merge B; revert .; commit -> rejects that merge forever
<achiang> lifeless: well, there were definitely commits
<lifeless> merge B; revert; commit -> 'error: pointless commit'
<achiang> lifeless: the workflow was: merge B, upload to PPA, discover B was broken, revert B, commit, new upload to PPA
<lifeless> righto, thats defintely rejecting the changes
<achiang> (because we were preparing for a release and didn't have time to fix B)
<lifeless> that will propogate
<achiang> now i'm ready to test B again
<lifeless> merge . -r rev-that-rejected-B..(rev-that-rejected-B-1_
<achiang> lifeless: is this a design choice or just a bug of some sort?
<lifeless> standard behaviour for every DVCS
<lifeless> you did a merge and accepted it
<lifeless> then you textually undid that change
<lifeless> the system is *expected* to propogate your change
<lifeless> and the merge is already known as done
<achiang> i don't know what the key word "textually" means there
<lifeless> text, source code,
<achiang> my mental model is that, revert introduces a new commit that makes the merge go away
<achiang> yeah, but you say that like the objects underneath don't care or something
<lifeless> right, they don't
<lifeless> what was the exact command you used to revert ?
<lifeless> if you used 'bzr revert .' it *keeps the merge record*
<achiang> bzr merge . -2..-3, iirc
<lifeless> so, that just changes the text in tree, it doesn't alter the revision graph
<lifeless> see bzr help merge
<lifeless> and read about cherrypicks
<achiang> wow, that is quite confusing
<achiang> lifeless: this is the key paragraph from bzr help revert -- http://pastebin.ubuntu.com/589890/
<lifeless> achiang: yup; now read the merge help to see what that does
<achiang> lifeless: i  must be missing the key paragraph there, because i've read that help many times and i'm not getting the enlightenment you think i should be getting
<lifeless> huh, its not there
<lifeless> anyhow
<lifeless> a cherrypick is not reflected in the revision graph
<lifeless> merge is completely ignorant about cherrypicked changes
<achiang> ok, i don't know enough about bzr internals to understand this behavior (or the explanation, really)
<achiang> my expectation is that any change i make to my tree should be reflected in the revision graph
<achiang> i find it strange that some things would be in there, but other things not
<lifeless> revisions have a list of parents
<lifeless> when you commit  amerge the list is of length 2 (or more)
<lifeless> normal commits, and commits of cherrypicks, have a list of length 1
<achiang> ok, so what is the proper way to revert a change then?
<achiang> because clearly i did something wrong or weird
<lifeless> no
<lifeless> this is the expected behaviour if you back something out after recording the merge
<lifeless> after you back it out, its backed out, and it doesn't alter the behaviour of merge
<achiang> ok, i'm having trouble with this because from what i remember in git, it behaves differently. but perhaps i'm remembering incorrectly
<lifeless> git does a regular three way merge
<lifeless> same behaviour
<lifeless> the way to avoid it is to not commit the merge of B in the first place
<lifeless> there are bugs open to add more capabilities here
<lifeless> but the only systems I know of at the moment that can do better are darcs and arch; the latter is dead (and had other significant downsides) and the former is a totlly different model
<achiang> i'm just doing a little test right now in git to prove to myself that my memory is just bad/corrupted. ;)
<achiang> lifeless: ok, i must have had a bad memory. you are right, git behaves the same way, so thank you for the explanation
<achiang> lifeless: can you explain this comment again? merge . -r rev-that-rejected-B..(rev-that-rejected-B-1_
<achiang> oh, now i see the "-1" in the 2nd revspec
<lifeless> yeah, same thing you used to undo it
<lifeless> to undo the undo
<achiang> lifeless: that worked, thank you
<jelmer> g'morning poolie
<poolie> hi jelmer
<jelmer> poolie: thanks for adding that SRU overview page. Is there anything more we should do to get the SRU's going or do we just need to wait for review from pitti and spamaps?
<poolie> thanks, i feel i have more of a handle on things now two
<poolie> i _think_ i just need to  upload to maverick-proposed
<poolie> s/two/too
<poolie> i was just going to check that with an ubuntu developer
<poolie> or perhaps you can confirm that for me?
<poolie> that does seem to be the next step on the sru checklist
<jelmer> Yeah, that's my understanding of it too.
 * jelmer links the branch for the lucid update to the bug
<jelmer> hmm, the Lucid branches' changelog doesn't mention bug 707075
<ubot5> Launchpad bug 707075 in bzr (Ubuntu Maverick) "[sru] lp-propose fails with a 404 error" [Undecided,New] https://launchpad.net/bugs/707075
<poolie> i saw your packaging branch for that
<poolie> i'll add that to the changelog
<jelmer> Vincent prepared a Lucid branch here: https://code.launchpad.net/~vila/ubuntu/lucid/bzr/sru-2.1.3
#bzr 2011-04-06
<spiv> Good morning.
<poolie> hi spivvo!
<poolie> nice to see pjkeating getting an outing again
<poolie> jelmer, do you know off hand how many importer branches have succeeded?
<wallyworld_> poolie: did you know "bzr xmlls" is broken on natty?
<poolie> that's from bzr-xmloutput?
<poolie> i did not
<wallyworld_> poolie: it's a python 2.7 incompatibility. i'll raise a bug
<wallyworld_>   File "/usr/lib/python2.7/dist-packages/bzrlib/plugins/xmloutput/xml_errors.py", line 30, in __str__
<wallyworld_>     _escape_cdata(str(e))
<wallyworld_> TypeError: _escape_cdata() takes exactly 2 arguments (1 given)
<wallyworld_> well i think it's python 2.7 related. haven't really looked into it
<wallyworld_> it worked fine before i upgraded to natty
<jelmer> poolie: Sorry, was afk. I'm not sure how many successful imports we have.
<poolie> np, i took a reasonable guess
<poolie> have a good night
<jelmer> wallyworld_: I'm pretty sure that's been fixed in trunk, any chance you can give lp:bzr-xmloutput a try?
<poolie> wallyworld, bug 732881
<ubot5> Error: Launchpad bug 732881 could not be found
<poolie> thought it rang a bell
<wallyworld_> jelmer: sure can. i'm just finishing up something. will do it soon. thanks for letting me know :-)
<jelmer> poolie: That's the plan :)
<jelmer> ttyl
<poolie> :) cheerio
<wallyworld_> poolie: jelmer: xmloutput works fine from trunk. thanks!
<spiv> poolie: Hey :)
<spiv> poolie: ah, I guess freenode shenanigans or something kept you from seeing me earlier.
<poolie> hi there
<poolie> ah i wondered if it was something like that
<poolie> either that or you'd abandoned 90s irc technology for tweeting
<spiv> Hah.
<poolie> how are the failures?
<spiv> The LP workaround has passed ec2 and so landed on lp:launchpad
<poolie> ok, and i guess will go live on the next downtime rollout?
<spiv> I guess so
<spiv> Hmm
<spiv> I assume code changes on codehosting ssh aren't rolled out until there's downtime to restart the service
<spiv> But because it's really split into the 'listens on ssh port' process and the 'bzr lp-serve' worker processes, in principle improvements to the latter could often be deployed without restarting the former.
<poolie> yeah
<poolie> ok, and so now ... the twisted upstream fix?
<spiv> I guess when the ssh service can be brought down gracefully by being run behind haproxy there won't be as much incentive to try take advantage of that.
<spiv> s/brought down/upgraded/
<spiv> Is still waiting for a hopefully final review.
<spiv> All the review points so far have been addressed.
<poolie> great
<poolie> i guess i will look into this possible whoami related selftest regression first
<poolie> since a lot of other outstanding stuff hangs off that
<poolie> how about you?
<spiv> Patch piloting
<spiv> As opposed to jelmer, who's been patch bombing ;)
<poolie> :)
<poolie> he certainly has
<poolie> john too
<poolie> good idea
<spiv> poolie: hmm, hydrazine is now broken for me on maverick
<spiv> TypeError: login_with() got an unexpected keyword argument 'application_name'
<spiv> I do want to upgrade to natty quite soon, but perhaps not *right now* ;)
<poolie> :/
<poolie> i guess it needs some version-conditional code then
<poolie> could you have a go at it?
<spiv> I took a quick stab at backing out just that one revision to see the difference and got a surprisingly large conflict, so I just reverted to the version I was using before.
<poolie> ok i'll try when i can get unity going
<poolie> spiv could you glance at https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/55872
<spiv> glanced, and approved :)
<poolie> thakns
<vila> Heigh Ho, Heigh Ho, hi all !
<fullermd> OK, you've exhausted your allocated supply of "h"'s for the day...
<spiv> vila: Â¡hola!
<vila> fullermd: I don't tink so
<jam> i vila, ow's it going?
<jam> fullermd: I tink e stole mine
<vila> hehe
<fullermd> jam: Try substituting an aitch.
<vila> fullermd: fail
<fullermd> I gotta stick with my strengths...
<jam> I'm surprised ow readable tings are witout te letter. I say we get rid of it. It clearly is 'arming the language
<jam> sucks, missed one
 * fullermd invokes Mark Twain...
<jam> fullermd: I do like that quote
<fullermd> "Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld."
<vila> dunno if it exists for English but I remember a text about mutating French to simplify it
<vila> fullermd: yeah, like that ;)
<jam> fullermd: I can probably read 90% of that, enough to understand it.
<jam> A bit like reading Dutch for me :)
<vila> this also reminds me of Perec who managed to write a book without the letter 'e'...
<fullermd> If we'd just switch over to Lojban and be done with it..
 * spiv hÌ¶mms
<vila> . o O (Probably never translated ;)
<jam> vila: hard to write his name, though
<vila> jam: hehe, good point, I wonder if he used a pseudo :)
<fullermd> Authors are best kept out of their work anyway   :p
<vila> te autor
<vila> zomg, they *did* translate it: http://en.wikipedia.org/wiki/A_Void
<vila> all: poolie said hi !
 * fullermd turns up the music and drags himself back to pretending to work.
<jam> vila: sure, but http://en.wikipedia.org/wiki/Gadsby_(novel) was done 30 years earlier
<vila> fullermd: not so fast ! What about http://pycon.blip.tv/file/4878868/ ? Can FreeBSD do that ?
<fullermd> Show me a big grey box saying something about a plugin that would crash my browser regularly if it existed?  Looks like...
<vila> . o O (Totally unrelated but worth trying to distract fullermd )
<jam> vila: well, he did it on a mac, which is technically just a glorified BSD machine, right?
<vila> jam: don't spoil it ! ;D
<vila> jam: what with Gatsby ? (Obviously I don't know)
<jam> vila: and there is http://en.wikipedia.org/wiki/Lipogram
<jam> describing earlier works as well.
<jam> vila: Gadsby was the first long text without the letter E
<vila> hoooo, I didn't know that
<vila> interesting... sort of ;) Hackers all over the place ;D
<jam> vila: "Hamlet without the letter I".
<jam> To be or not to be, that's the query
<jam> (since question has an I)
<fullermd> Eh.  You haven't experienced Shakespeare until you've read it in the original Klingon.
<vila> wow 'the quick brown fox...' omits S !
<spiv> jumps?
<jam> http://en.wikipedia.org/wiki/The_Klingon_Hamlet
<vila> spiv: The quick brown fox jumped over the lazy dog
<jam> I'm pretty sure the full "quick brown" text has all English letters
<vila> could be
<jam> as it is supposed to be a text for showing typography
<fullermd> Yeah, I gave my mother a copy for Christmas some years back.
<jam> http://en.wikipedia.org/wiki/The_quick_brown_fox_jumps_over_the_lazy_dog
<vila> yup, may be just a variant to explain lipogram
<vila> ok, back to liprogramming config without the letter 'bug' :D
<vila> jam: by the way, congrats on your efforts around the sha1s !
<jam> vila: thanks
<jam> unfortunately, I still need to track down all the other paths
<jam> like merge
<jam> and revert
<jam> and ...
<vila> jam: I'm not surprised :-/
<jam> I could cheat and recompute the sha1 in create_file, but that would just move the processing time around.
<vila> jam: feel free to find shortcuts along the way !
<jam> vila, jelmer, spiv: Are we doing the standup now?
<vila> jam: I think it was decided to do it tomorrow (as an exception)
<jam> vila: I think you're right
<jam> I always have trouble with "you have a meeting" emails
<jam> for some reason the *date* of the meeting is never clear to me
<vila> jam: easy short, I did accept the invitation this night :) You made me doubt about the *week* ;)
<vila> s/short/shot/
<jam> yeah, it definitely has @ Thu
<jam> I just need to pay more attention :)
<jelmer> looking at the date isn't a guarantee, I've seen a few evolution timezone bugs ;)
<fullermd> Gaah.  And once again, I waste a bunch of time because of bug 315399  :(
<ubot5> Launchpad bug 315399 in Bazaar "diff gives huge areas of unnecessary changes" [Medium,Confirmed] https://launchpad.net/bugs/315399
<hrw> hi
<hrw> will there be bzr-fastimport 0.10.0 package for ubuntu natty?
<vila> fullermd: any chance you can point to a public branch allowing to reproduce (for the record ?)
<fullermd> Not that I know of.
<jelmer> hrw: it's not planned; we should be able to get the new snapshot from Debian synced if there's a good reason to
<hrw> jelmer: trying to get git-bzr-ng working again - it lists 0.10.0 as requirement
<jelmer> hrw: natty has a 0.9 snapshot IIRC, I think it has the fixes required by git-bzr-ng
<hrw> jelmer: bzr: ERROR: unknown command "fast-export"
<hrw> http://paste.ubuntu.com/590170/ is whole output
<jelmer> hrw: does "bzr plugins" list the fastimport plugin?
<hrw> ha! nice catch. http://paste.ubuntu.com/590175/ shows that it is installed but bzr does not know that
<hrw> but why it happened? no idea
<vila> hrw: python version mismatch ?
<hrw> vila: fastimport landed in /usr/lib/pymodules/python2.7/bzrlib/plugins/ when all other plugins are in /usr/lib/python2.7/dist-packages/bzrlib/plugins directory
<hrw> this is under natty (which was upgraded from maverick in beginning of development cycle)
<vila> hrw: 'bzr plugins -v' will tell you where plugins have been  found
<hrw> vila: already used -v to find where normally they reside. only bzr-fastimport got into other place
<vila> hrw: I'm not *that* familiar with packaging to say what the right directory is, but it's weird that two different ones are used (not counting link farms)
<jelmer> I bet it's the switch to python-support that's related
<hrw> jelmer: sure. but why bzr does not check python-support dirs too?
<vila> hrw: could be a bug in packaging, you're using the daily ppa ? (Obviously no: bzr-fastimport 	0.9.0+bzr311~ppa129~natty1  there)... where did your package come from ?
<jelmer> hrw: bzr simply uses the standard python import mechanism
<vila> ha, no, you're using stock natty
<hrw> vila: plain natty package
<vila> yup, rmadison told me
<hrw> anyway - symlinked it to ~/.bazaar/plugins/fastimport for now
<jelmer> hrw: it's definitely some sort of packaging issue, any chance you can file a bug?
<vila> you meant s/to/from/ ?
<hrw> vila: ln -sf /usr/lib/pymodules/python2.7/bzrlib/plugins/fastimport/ ~/.bazaar/plugins/fastimport/
<vila> but yeah, easiest work-around if you don't want to put a branch there
<hrw> jelmer: sure
<jelmer> vila: what's the problem with try/finally in tests?
 * vila nods ln -s will confuse me until my death, there is no way I will get it right now after getting it wrong for the past 30 years
<vila> jelmer: error-prone, less clear generally
<vila> jelmer: there are some exceptions but as a rule, avoiding them is generally better
<jelmer> vila: I understand less clear, but in what way is it error-prone?
<jelmer> I don't have any objection to using self.addCleanup(), just curious.
<vila> hmm, yeah, what did I mean...
<vila> you can define the try/finally scope wrongly
<jam> jelmer: try/finally also tends to lead to terrible scopes when you have 3-4 of them
<vila> or more generally forget it, whereas using addCleanup *unless* you can't wait the end of the test to cleanup is generally safer
<jelmer> ah, fair enough
<vila> jelmer: so it's kind of error-prone to *not* use addCleanup
<vila> jelmer: which may be more precise than saying try/finally is error-prone
<vila> jelmer: yeah, I think that's what I meant :D
<vila> zomg, when did the ppa pages got the stop signs in 'Latest updates' ?
<vila> for ever but I never look at the page while failures where pending ?
<spiv> jelmer: the two basic problems with try-finally vs. addCleanup are
<hrw> jelmer: bug 752396
<ubot5> Launchpad bug 752396 in bzr-fastimport (Ubuntu) "bzr-fastimport is not listed in "bzr plugins" list" [Undecided,New] https://launchpad.net/bugs/752396
<spiv> 1) if the cleanup is distant from the initial action (i.e. many lines away) it's easier for skew between those to be missed, and
<jelmer> hrw: thanks, marked confirmed
<spiv> 2) an error in a finally block will override a prior error
<hrw> git-bzr-ng now works in both directions - finally no need to touch bzr directly ;D
<spiv> So you can get e.g. TooManyConcurrentRequests or some odd pack exception rather than the actual problem.
<spiv> And there's related things like if you have code like "if cond: foo.lock_read()" then you need to say "if cond: foo.unlock()" in your finally, so you're repeating yourself
<jelmer> spiv: that makes sense, thanks
<spiv> Basically, default to using addCleanup everywhere it's conveniently availableâ¦ and if it's not conveniently available, consider using it anyway ;)
<vila> jelmer: and I don't remember a case where migrating from try/finally to addCleanup made the test harder to read or maintain
<vila> jelmer: but a lot of cases where it fixed some nasty bugs
<jelmer> just to be clear, I'm not arguing for try/finally, I was only wondering why addCleanup is better.. I think I know now :)
<vila> well, may be no a lot, but some lock checks failures were fixed this way
<vila> jelmer: I think you got a good summary :)
<jam> vila: some more "Welcome to Europe" things for you.
<jam> 1) The EU "Queen" size is 8cm wider than the US one.
<jam> (for matresses)
<jam> so it isn't a trivial "buy a split foundation". We did so, and now it doesn't fit with the frame, etc.
<jelmer> jam: isn't it supposed to be the other way around?
<jelmer> generally stuff is larger in the US :)
<jam> jelmer: that's what they say :)
<jam> 2) ... dang, I swear I had 2
<jam> jelmer: http://en.wikipedia.org/wiki/Mattress
<jam> has a big table of "crazy" sizes
<jam> apparently UK has yet-another standard set of sizes
<jam> I believe the phrase is "Standards are great, we should clearly have more of them"
<jelmer> heh, indeed :)
<jam> jelmer: apparently the US "King" size is bigger. 193cm vs 180cm.
<jelmer> jam: At least this is standardised, so many things are still different across EU countries
<jam> jelmer: of course as mentioned, depends if UK is part of the EU or not :)
<jelmer> jam:
<jelmer> I don't really think they are :)
<vila> jam: 8=/
<vila> Yup, I can confirm that, they aren't :D
<jam> vila, jelmer: And AIUI neither is Switzerland or Czech, or ...
<jelmer> jam: well, the UK is formally a part of the EU, just not in spirit :)
<jelmer> jam: Switzerland is a part of some treaties (like Schengen, the customs treaty) but not of the EU
<jam> jelmer: being able to half-join is like having yet-another-standard
<vila> jam: oh, no, Switzerland, pfff of course not ;) You know, while the EU is far younger than the US, the family history if far longer and some episodes goes really far into the past ;)
<vila> jam: can you imagine that the parliament is moved, twice a month, including all admin people and of course all of the paper archives ?
<jelmer> vila: good business for Strasbourg though, no? :)
<jam> wow, seems crazy
<jam> or like a rock-and-roll show
<spiv> A parliament with roadies!
<jam> spiv: just watch out for the groupies
<spiv> jam: ITYM "public servants"
<jam> :)
<jam> spiv: and 'pay-to-play' politics
<vila> jelmer: that's what they say ;)
<jelmer> maxb_: Do you know if there was anything in the newer debhelper that we actually needed?
<jelmer> nevermind
<maxb_> jelmer: --buildsystem
<maxb> and override_dh_foo
<gypsymauro> hi
<maxb> hello
<gypsymauro> I'm trying to use the syntax bzr serve --port=localhost:1234 --directory=/srv/bzr/repo
<gypsymauro> but when I try to bzr log bzr://localhost:1234/ .. does nothing
<gypsymauro> any hint?
<maxb> "does nothing" is not a helpful problem description. It certainly does something - even if that something is "hang" or "exit with no error and no output"
<gypsymauro> it "hangs"
<gypsymauro> even ctrl-c on server doesn't kill it
<maxb> What is your platform? Linux?
<gypsymauro> yes
<maxb> If  you re-run the "bzr log" command adding the "-Derror" option, and Ctrl-C it after a while, what error do you get?
<maxb> Whilst in the hung situation, can you see any tcp connections using "netstat -tn | grep 1234" ?
<gypsymauro> tcp        0      0 127.0.0.1:41908         127.0.0.1:1234          ESTABLISHED
<gypsymauro> tcp       85      0 127.0.0.1:1234          127.0.0.1:41908         ESTABLISHED
<gypsymauro> so it seems a connection
<gypsymauro> after ctrl-c noone error I waitd 5 mins
<maxb> Please check the ~/.bzr.log file for any potentially useful information
<gypsymauro> maxb: nothing usefull
<gypsymauro> it's like is bzr serve that freezes
<trond->  I'm using bazaar for webdevelopment of a service that I
<trond-> (gr.) starting over
<trond-> I'm using bzr for webdevelopment, and I have created a solution that is available for a few customers. I have branched those versions. Now, If I change something in one branch, and want this change to be available for the others, how do I do this?
<jam> trond-: can you just go to the other branch and "bzr merge" the first one?
<maxb> If you have multiple customer specific branches, it can be worth maintaining a central generic branch from you merge changes
<jelmer> maxb: I'm considering splitting bzrlib.tests into its own (Arch: all) package
<jelmer> maxb: it's 16Mb (vs 29Mb in all of bzrlib/)
<maxb> gosh. Quite a saver. Sounds great, though we might need to patch other stuff to fail helpfully, I suppose?
<jelmer> maxb: yeah
<jelmer> AFAIK "bzr selftest" is the only thing that really imports from bzrlib.tests
<maxb> Oh, and presumably anything that matters will already have a conditional to react nicely to the absence of python-testtools?
<jelmer> maxb: presumably, but in practice that isn't actually the case
<jelmer> nothing outside of bzrlib.tests uses testtools though
<maxb> Oh
<jelmer> one of the nice things of splitting bzrlib.tests out is that it can actually depend on python-testtools properly
<maxb> Perhaps "No module named testtools" was sufficiently informative to class as "reacting nicely" in my head :-)
<jelmer> heh, fair enough
<maxb> OK, so we could either patch cmd_selftest upstream to say something like "The testsuite is not part of this bzr installation", or we could patch it in the packaging branch to suggest 'apt-get install python-bzrlib-tests' similar to what the debian mercurial package does for this sort of thing
<jelmer> maxb: sounds reasonable to me
<mrnuke> hi
<mrnuke> I'd like to know how to merge two bzr branches, and keep the commit history from both branches
<mrnuke> if I just bzr merge /path/to/other/bbranch, it discards the commit history from the other branch
<luks_> it doesn't discard anything
<mrnuke> so after bzr merge, I can simply bzr commit without fear?
<luks_> but I think that bzr log doesn't display it by default (wow, it's been a long time since I used log)
<luks_> you can use bzr log -n0
<luks_> or better, bzr qlog
<luks_> yes
<mrnuke> oh, thanks :)
<mrnuke> I was afraid to commit fearing the history would be lost
<trond-> jam, ref my question and your reply - go to other branch and bzr merge. Do you mean go to the main code and merge, or to the branch and merge?
<trond-> maxb, I agree. (central generic branch)
<mwhudson> huh, this isn't how i expected bzr-hg to choke on pypy: http://launchpadlibrarian.net/68480618/mwhudson-pypy-hg-trunk.log
<mwhudson> (for the click-shy it's "IOError: [Errno None] connection ended unexpectedly")
<mwhudson> jelmer: hi :-)
<jelmer> hey Michael :)
<jelmer> mwhudson: I guess we wait too long reading all of the data and meanwhile the connection times out
<mwhudson> yeah, i guess so
<mwhudson> bitbucket have a really crappy router doing nat? :)
<jelmer> mwhudson: we're too slow parsing hg data?
<mwhudson> i guess that's a more realistic explanation yes
<jelmer> mwhudson: can you file a bug? I don't think we have that one yet
<mwhudson> jelmer: ok
#bzr 2011-04-07
<mjflick> hi, i compiled bzr but i'm getting the following error when running it, "bzrlib._static_tuple_c.StaticTuple is not a type object"
<mjflick> any ideas what's broken here?
<lifeless> what python ?
<mjflick> 2.5.2
<poolie> kind of sounds like something's out of date with your python version
<mjflick> great
<spiv> Hi folks.
<poolie> hi there spiv
<poolie> lifeless, http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
<echo-area> spiv, vila: I'm sorry I was busy doing other things these days so I didn't follow up spiv's bug report and didn't work on the document improvement of types of conflicts yet.  I'm still busy now, but I'll return to this later.  Apologize.
<AfC> Is there no way to engineer out the "updating git map" step? It's going to take half an hour!
<AfC> then "fatal: The remote end hung up unexpectedly"
<poolie> :/
<AfC> then, we start again at 0/19738
<poolie> jelmer would know best, and he's likely asleep?
<AfC> bloody hell
<poolie> file a bug?
<AfC> yeah
<AfC> poolie: I guess I've kinda got tired of hassling Jelmer with bugs about bzr-git
<mwhudson> i bet you haven't done it nearly as much as me
<AfC> I never seem to be able to get it to work :(
<poolie> i don't think he feels hassledh
<poolie> and they do seem to get closed
<AfC> poolie: filed, https://bugs.launchpad.net/bzr/+bug/753155
<ubot5> Ubuntu bug 753155 in Bazaar "bzr-git crashes when trying to update GTK" [Undecided,New]
<poolie> thanks
<poolie> ok, SRUs here i come
<poolie> OK, sru for bug 707075 proposed; let's see
<ubot5> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/707075)
<lifeless> thats no good
<lifeless> 2.5 seconds for me
<lifeless> 177 queries though
<lifeless> which makes me sad
<vila> lifeless: 197 queries/external actions issued in 4.01 seconds here
<vila> hi all !
<vila> poolie: 2.1.4 is planned for next week, are you ok to wait a bit and use bug #707075 (come one ubot5, try better) to drive the 2.1.4 SRU ?
<ubot5> Launchpad bug 707075 in bzr (Ubuntu Maverick) "[sru] lp-propose fails with a 404 error" [High,In progress] https://launchpad.net/bugs/707075
<vila> good bot
<lifeless> vila: thats interesting, I wonder why
<vila> lifeless: 177 vs 197 you mean ? I was about to ask
<lifeless> possibly there is a memcache fragment in there we missed
<lifeless> but it should be disabled on BugTask:+index
 * spiv steps AFK.
<spiv> Back in a bit.
 * vila scratches head
<vila> poolie: how can I check that bzr has been uploaded to maverick-proposed ? It doesn't show up in synaptic...
<lifeless> vila: become an ubuntu archive-admin
<lifeless> vila: you might be able to see it in the maverick +queue page
<vila> lifeless: the intent is to test it, I hope testing is open to non-admin people
<lifeless> once its accepted into -proposed, yes
<vila> oh, ok, that's probably the issue then
<maxb> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text=bzr
<maxb> vila: ^
<vila> maxb: you rock ;)
<vila> >-/ http://launchpadlibrarian.net/68515880/bzr_2.2.1-0ubuntu1_2.2.4-0ubuntu1.diff.gz mentions 2.2.2-dev in the generated C files
<vila> may be the generated content is correct but if it has been generated there but this seems really wrong
<vila> it should be 2.2.3-dev according to my local workflow
<vila> err, no, 2.2.4-dev of course
<vila> ok, false alarm
<vila> it's a local glitch, I rely on make there *but* rename the directories after releases, so the path mentioned is the one that was current the last time the file has been generated
<vila> I should probably add 'make clean; make' somewhere to avoid this
<vila> on the other hand, full paths should be used only when building locally for debug purposes, relative paths should be used otherwise,
<vila> especially for releases so that the above diff will stop containing the spurious comment changes
<vila> I thought we had a bug for that but all I can find is bug #336933 which is only tangentially related
<ubot5> Launchpad bug 336933 in Bazaar "version control the pyrex output files" [Wishlist,Confirmed] https://launchpad.net/bugs/336933
<maxb> vila: I would like that. I suppose we need to either fix pyrexc or apply sed
<vila> maxb: yup, I vaguely remember looking at that loong ago but don't remember ever finding a solution (didn't try sed though)
<vila> but injecting sed between generation and compilation in build_extension may be tricky
<fullermd> I recall doing a bunch of sed'ery in my (unsuccessful) attempt to figure out why they were blowing up a couple years back.
<vila> and Cython may proceed differently, but anyway, it may be worth another try
<fullermd> Last I checked, cython just flat didn't work, so that's easy to ignore  ;)
<vila> hehe
<poolie> hi spiv, vila, jam, jelmer
<jelmer> hey poolie
<vila> poolie: hey
<poolie> hi there
<poolie> iirc we're going to a have a standup call now?
<spiv> poolie: yes
<jam> hi poolie, what method?
 * spiv is on mumble
<poolie> mumble?
<poolie> it apparently wants to be reinitialized for natty
<jam> apparently we upset vila
<poolie> :)
<vila> poolie, jam, jelmer, spiv : Gee, I lack caffeine: lp says 2011-*05*-12 and that's right unless someone insists about releasing 2.1.4 sooner, next month seems fine as far as SRUs are concerned
<poolie> hi jelmer?
<jam> vila: not a whole lot of stuff in the 2.1 series that I can see *needs* release
<jam> Though it is nice if we are going to do a backport to actually get it out to users.
<vila> jam: sure, but what we want is to get 2.1 updated for lucid which is LTS, so it's more about having the SRUs running (and we need to SRU 2.2 *before* 2.1 AIUI)
<poolie> still here?
<jelmer> FFS
<poolie> jelmer, that's nice
<jam> jelmer: want to finish up in IRC
<jam> we'll just talk about you behind your back
<jelmer> yeah, that might be better, my mumble seems unreliable today
<poolie> jelmer, you should send a mail about that great result
<jelmer> jam: >-)
<vila> jelmer: don't worry, I had to *reboot* myself ;)
<jelmer> This week I'd like to work on finishing the bzr-svn/bzr-hg/bzr-git releases and getting them and a newer bzr deployed on LP
<vila> \o/
<jelmer> as well as getting the transport-segments patch finished
<poolie> that sounds good
<poolie> spiv's talking about getting the twisted failure patch and workaround done
<poolie> i'll send minutes too
<poolie> we could try using canonical asterisk conferencing next time
<poolie> or skype
<poolie> spiv: and the patch to upstream twisted?
<poolie> oh, just briefly
<poolie> because the kanban is working well i was thinking about changing what we do with bugs
<poolie> specifically actually using fix committed/fix released to remind us to make a release
<vila> meh, for bzr itself you mean ?
<poolie> yes
<vila> We stopped using fix committed to ease the RM work IIRC
<jam> vila: and to avoid the "100 bug spam updates when a release is made"
<vila> and I thought Fix committed was going to be deprecated anyway
<vila> jam: hmm, yeah, *I* wouldn't mind that if I wasn't the RM as a reminder of which fixes are about to be released
<jelmer> it should be possible to do a trivial script that marks all bugs for a milestone as fix released
<vila> arf arf, headset delivered *just* after the online meeting, the irony :)
<jelmer> vila: :)
<vila> jelmer: right, truth is I'm mainly using the milestone pages to see which bugs are fixed by which release and that will still work if we use Fix Committed so I'm not violently *against* using it (I always liked the distinction between committed and released myself though I used it to distinguish between: there are a fix in *a* branch and the fix has landed in the official branch)
<vila> but anyway, worth discussing on the list as poolie proposed
<poolie> o/ spiv
<jam> poolie: does feed-pqm notice that Branch A is approved but its prerequisite B is not?
<poolie> no
<jam> poolie: I thought so, but just checking
<poolie> what do you think it should do?
<poolie> arguably lp should warn you about this
<jam> poolie: warn/not show it as submittable/ something
<poolie> yes
<jam> I'm reviewing Jelmer's stack, and the first I need to discuss a bit more, most of the follow ups are obviously ok
<jam> but I don't want to mark them Approved, since it would want to be submitted
<jam> poolie: speaking of which, I think you have 3-4 "approved but not landed" branches.
<jelmer> jam: hi
<jam> hey jelmer
<jam> jelmer: questions are in https://code.launchpad.net/~jelmer/bzr/knitpackrepo/+merge/56383
<poolie> it is not all that great at showing the whole stack
<jam> poolie: I realize it is a little bit tricky, since prerequisite branches are off-to-the-side, since you don't set a prerequisite merge-proposal
<jam> which is where the "is this merged" is generally tracked
<askhl_> Hi.  I have a bzr repository with multiple branches and tags, and would like to transfer this whole structure to a project in Launchpad.  How should this be done?
<jelmer> jam: ah, thanks
<askhl_> (One could conceivable create series for the different tags and manually push each tag/branch as appropriate.  Is this the smartest way or is there a better way?)
<jam> askhl_: generally you would create a new project on launchpad, then push up your primary development branch, mark it as such, then push up the rest
<askhl_> conceivably*
<askhl_> jam: so the rest of the branches/tags are simply pushed individually?
<jam> askhl_: I'm not sure what you are doing with tags, but yes
<jam> for the branches
<askhl_> jam: the tags correspond to stable versions.  I guess they're sort of like series
<askhl_> jam: thanks for the help
<jam> askhl_: what are the branches then? My guess is you would just have a series branch that happens to have the individual release tags on it.
<jam> I don't know if you need separate branches for each release tag.
<jam> s/need/need or want/
<spiv> jam: related bug I filed today: https://bugs.launchpad.net/launchpad/+bug/753185
<ubot5> Ubuntu bug 753185 in Launchpad itself "Merge proposals with prerequisites should also show if that prerequisite is merged (dup-of: 456418)" [Undecided,New]
<ubot5> Ubuntu bug 456418 in Launchpad itself "merge proposal status info should reflect status of prerequisite branch" [Medium,Triaged]
<askhl_> Say, we have this repository.  And we would like to push the branches in this repository to LP.  But when attempting to do so, it complains that "location is a repository".  Apparently the subdirectories are not quite branches that can be pushed.  How do we proceed?
<spiv> askhl_: push the branches, not the repository.
 * spiv -> dinner
<askhl_> spiv: I'm in one of them (trunk) and running bzr push lp:<project>.  That's when it complains
<askhl_> Strange.  The trunk is actually not reported to be a branch by bzr info, while the other branches are.  Maybe this is an error in svn2bzr (which has been used)?
<askhl_> But we need trunk to be a branch (including revision history)...
<vila> askhl_: directory has not the same meaning in bzr and svn, in bzr it's just a revision store, bzr deals with branches mainly
<vila> askhl_: a branch can have multiple tags, each one associated with a specific revision
<vila> askhl_: launchpad hosts only branches with some of them having aliases for convenience
<vila> lp:bzr is a shortcut for the dev focus branch which is lp:~bzr-pqm/bzr/bzr.dev
<vila> for project branches, the url syntax is lp:~<user>/<project>/<branch>
<askhl_> vila: thanks
<vila> so, if 'bzr push lp:<project>' fails, that's possibly because the dev focus is not correctly defined for <project>
<askhl_> So right now the problem is that svn2bzr converted the trunk branch of svn to something which is not a branch in the bzr sense.  So we need to make a branch out of it (including entire revision history) and push it to LP.
<askhl_> We managed to push one of the non-trunk svn tags (technically a branch) successfully, it's just that trunk itself is not a branch for some reason
<vila> askhl_: well, you need a branch to start with, I'm pretty surprised that svn2bzr produced something that isn't one
<vila> askhl_: if you do 'bzr info' in any directory, it should tell you what it thinks the directory contains
<vila> askhl_: pastebin'ing the result may ease the dialog ;)
<askhl_> vila: right, bzr info reports that it is a 'shared repository', whereas for the other branches it reports two lines, one stating that it is a shared repository (or part thereof), the other stating that it is a branch
<vila> right, so a shared repository is a repository used my multiple branches (a repository can also be private to a branch)
<fullermd> A 'branches' run may be helpful.
<vila> so you did the first 'bzr info' at the repository level, the branches should be down the hierarchy starting there
<vila> ha, of course, fullermd to the rescue ;)
<vila> askhl_: try 'bzr branches' ^
<fullermd> From the 'top level' of your conversion.
<askhl_> Oh, there's the problem: svn2bzr has converted all the *subdirectories* of trunk into different branches
<fullermd> jelmer: I haven't read your email yet, but just from the subject line I'm totally in favor of whatever it contains   :p
<vila> askhl_: 'branches' is part of the bzrtools plugin (in case you got an Unknown command error)
<askhl_> as revealed by svn branches
<askhl_> That explains it then
<askhl_> Thank you, vila  and fullermd
 * fullermd goes back to lurking until vila almost solves the next problem, then jumps in to take the credit   8-}
<vila> fullermd: for once I didn't start with http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief which may have been an error ;)
<vila> askhl_: I'm not that familiar with svn myself, but from the various discussions here, people use bzr-svn more than svn2bzr, you may want to have a look at it
<fullermd> I should blow an afternoon sometime trying to see if bzr-svn can be sweet-talked into running over the BSD src repo, but I have a feeling I'd spend hours just trying to tell it the repo structure.
<fullermd> Then more hours and several times my RAM waiting for it to figure out what to do...
<vila> askhl_: also, launchpad can import from svn so you may wan to look there too, maybe it can do the work for you ;)
<askhl_> vila: it seems that bzr-svn is useful for using bzr as a frontend to svn repos, whereas we are converting an svn repo to bzr permanently.  I think we'll figure it out now with bzr2svn, so things should be fine! (until we get more questions of course .))
<jelmer> askhl_: bzr-svn has a "bzr svn-import" command that has behaviour similar to svn2bzr
<jelmer> fullermd: how weird is the repository layout?
<vila> jelmer: it uses CVS :-D
<fullermd> Fairly.  Ignoring stuff that's unnecessary for a generally-good-coverage import, there's still a fair spread of stuff to get...
<fullermd> vila: ports is still CVS.  The master for src is in svn.
<jelmer> jam: whoa, 77 entries in your sys.path?
<fullermd> I think about trying ports again sometimes too, but I sober up real quick  :p
<vila> :)
<jelmer> jam: I heard people complain about a single additional entry in sys.path on Ubuntu
<jam> jelmer: easy_install defaults to putting every installed software into a custom location
<jam> so that you can have 2.4 and 2.5 installed, but pick which one is active
<jam> however, Launchpadlib has *huge* dependencies
<jam> (well, a very large dependency stack)
<jam> which I don't want to manually install, but obviously has some severe negatives w/ easy_install
<jelmer> jam: hey, it's nothing compared to Launchpad's dependency stack :-P
<jam> jelmer: sure, but you can't easy_install Launchpad on Windows, either
<jelmer> that's probably for the best :)
<jelmer> whoa, we had *9* knit pack repository formats?
<maxb> I count 7 _released_ ones
<vila> jelmer: part of why bialix was talking about a zoo format :-}
<vila> err, format zoo
<jelmer> yeah
<dije> Doing a checkout to my home directory from a branch at ~/bzr_scm/dot, I get the following error:
<dije> bzr: ERROR: Failed to rename /Users/phil/Library/Preferences to /Users/phil/.bzr/checkout/limbo/new-159/Preferences: [Errno 13] Permission denied
<dije> How can I remediate this?
<dije> (On Mac OS X 10.5.8, Titanium PowerBook G4)
<dije> Anybody here?
<jelmer> dije: hi
<dije> jelmer: hi
<jelmer> dije: I'm here, but I'm not entirely sure what's going on there
<dije> Nothing shows on a google search
<jelmer> brb
<achiang> hello, what is the preferred GUI bzr tool?
<achiang> i guess it's just bzr-gtk?
<james_w> qbzr is actually better these days I think
<james_w> bzr-explorer provides a nice intergrated environment if you prefer that to the "bunch of tools" approach
<achiang> james_w: ok
<achiang> james_w: i need to do a rather complex operation
<achiang> trunk is A, merged in branch B; then had to revert B (bzr merge . --revision -2..-3); then A had more changes; then I added B back in; more changes, now i need to revert B again. :-/
<achiang> james_w: thanks for the tip on bzr explorer. i'm stumbling my way through this morass of my own making
<LeoNerd> ARGH FSCKING REVERT
<LeoNerd> "bzr revert" after shelve/unshelve thought it was safe to blow away my changes. It wasn't. Any chance I can get them back, or is that gone gone?
<james_w> LeoNerd, there will be .~N~ files for each changed file
<james_w> where N is a number >=1, use the last for each
<LeoNerd> No.. there aren't.
<james_w> you used --no-backup?
<LeoNerd> Normally there are.. not immediately after shelve/unshelve
<LeoNerd> revert believes it's reverting after a merge, so doesn't bother to keep them
<james_w> erk
<LeoNerd> Fortunately I happen to have the diffs in my xterm scrollback buffer, so I can reapply. Problem is, it also reverted adding a new file, for which I dno't have the original content
<james_w> would you file a bug on the unshelve+revert thing
<james_w> ?
<james_w> once you are finished unpicking the fallout
<LeoNerd> I thought there already was one
<james_w> oh, ok
<LeoNerd> Atleast, I've known about it for like a year now.. seen mention of it. I was presuming debian was just behind the times in not giving me a fixed one
<LeoNerd> Was wondering if anyone knows if the 'shelve'd content is stored somewhere after unshelve, that I could get at still
<james_w> I don't know that it is
<philsf> I have a local versioned dir , and I want to set it up in a server. I didn't find in the site docs what is needed on the server side to use it remotely. Is a user account and ssh access enough?
<maxb> philsf: Yes. You can then simply use bzr+ssh://host/path/to/dir URLs in bzr commands
<philsf> maxb, so I can just rsync the whole dir, including .bzr/* to the destination?
<maxb> It would work, though it's not the nicest way
<maxb> Is Bazaar installed on the serve?
<maxb> *server
<philsf> not yet
<maxb> You can use Bazaar using sftp://host/path/to/dir URLs without having bzr installed remotely, though the performance will not be as good as bzr+ssh
<philsf> what's the polite way to transfer the whole branch, instead of rsyncing the whole thing?
<maxb> bzr push remote-url-where-you-want-it
<philsf> forgive my ignorance, what's the difference?
 * jelmer waves
<maxb> Not a great deal, but: 1) pushing doesn't create a working tree on the server, and 2) your local branch remembers where you pushed it to for convenience when you want to push updates
<philsf> thanks, bye
<AfC> How hard would it be to have Bazaar insert a \n instead of clearing the terminal line when it's printing status messages?
<jelmer> AfC: with status messages, do you mean progress indication messages?
<AfC> jelmer: yes?
<AfC> The stuff that spews out on teminal for 10ms then gets erased whenever you do anything
<AfC> jelmer: [are those "progress indication messages"?]
<jelmer> I'm not sure which messages you mean, I haven't seen any messages from bzr get erased when I type stuff.
<jelmer> AfC: can you give an example of the contents of one of those messages?
<AfC> jelmer: "...Inserting stream..."
<jelmer> ah, those are indeed the progress indication messages
<jelmer> adding a newline there will mean *a lot* of output though
<jelmer> it's not a generic status message, it just tells you what bzr is working on; if something completes quickly enough it's not shown
<AfC> I'd obviously want to nuance it that things that are just updating the 0/100 wouldn't trigger the \n, just a changed message
<jelmer> AfC: I think you're just asking for more high-level output on what's actually been completed?
<AfC> jelmer: I want to evaluate (subjectively) the impact of seeing more output from bzr when running things. We all know git "seems" faster, and I want to see whether that has to do with it looking like it's "doing more" per unit time / per unit message
<AfC> jelmer: [but as an aside, having no idea what any of Bazaar's messages actually are makes it harder for all of us user types to communicate with the bzr hackers about "why it is doing ____"]
<AfC> jelmer: [so I'd like to start seeing 'em]
<jelmer> AfC: the related code is in bzrlib/uyi/text.py, see show_progress()
<jelmer> s/uyi/ui/
<AfC> Eeeek!
<AfC> http://bazaar-vcs.org/bzr/bzr.dev/ is permanently redirected to http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
<AfC> bzr: ERROR: Cannot lock LockDir(http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<AfC> what the heck/
<AfC> from
<AfC> $ bzr pull
<AfC> oh... it's a format 1.14 branch. Is bzr.dev 2a yet?
<AfC> still, that's some error message
<jelmer> yeah, I'm pretty sure bzr.dev is 2a
<jelmer> AfC: is this a checkout perhaps?
<AfC> jelmer: yeah, I assume so
<AfC> jelmer: I always do "read-only" checkouts (mirrors?) of upstream.
<AfC> Shouldn't I?
<jelmer> AfC: you can, but you should in that case use "bzr up" to update
<jelmer> AfC: you were trying to pull new changes into your local branch and its master branch, to which you have no write access
<jelmer> (the error message about the master branch being readonly is more than weird, I admit)
<AfC> jelmer: update vs pull sometimes being one thing and sometimes being another is probably THE thing I hate the most about bzr, :(
<AfC> In a branch, regardless of what type it is, it should be pull, or update. They shouldn't be the same sometimes.
<jelmer> AfC: hopefully it's something that will be addressed in the 3.0 UI revamp
<AfC> I hope we can clean this up in 3.0
<AfC> jelmer: tag you're it
<jelmer> AfC: well, technically they are different things.. but I won't go there, I get your point.
<AfC> jelmer: I know they're different things. That's why I'd rather they be 2 commands that you have to do
<AfC> jelmer: the whole thing is founded in the idea that "people shouldn't have to do two steps" but look at the confusion that resulted.
<AfC> jelmer: if pull and update are different and have side effects, then they're different.
<AfC> {shrug}
<AfC> Meanwhile, starting again,
<AfC> $ bzr branch http+urllib://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
<AfC> can't give me an estimate of total size to be transfered? :(
#bzr 2011-04-08
<poolie> hi all
<spiv> Hi poolie
<spiv> You have some approved branches to land :)
<jelmer> moinmoin :)
<poolie> hey, thanks
<poolie> that's not very dutch :)
<jelmer> apparently it is, though not the area of the Netherlands I'm from
<jelmer> http://en.wikipedia.org/wiki/Moin
<poolie> oh, cool, i was just wondering after i asked
<poolie> spiv there was one patch i think about adding options to diff that was a bit old and that needed tests
<poolie> maybe you/we should finish it
<poolie> jelmer, i liked your mail about lazy imports
<poolie> great title too
<dash> ahoyhoy. if i have a lightweight checkout whose branch has moved, can i point it at the branch's new location or do I have to blow it away?
<jelmer> poolie: thanks :)
<poolie> dash, you should be able to redirect it with 'bzr switch'
<dash> oh, hup. switch works if I remove the loom plugin.
<poolie> maybe 'switch --force'?
<dash> yeah.
<dash> should've immediately gotten suspicious when that error message said 'thread' in it.
<jelmer> that sounds like a bug in the loom plugin?
<dash> quite likely
<jelmer> it wraps the switch command to add some extra functionality
<dash> I also had a terribly old version of it hanging around
<dash> (just upgraded this box from karmic to natty)
<poolie> that would be such a good case for refactoring commands to allow cleaner extension
<poolie> in fact, that refactoring may already exist in cmd_status and just need to be used
<mwhudson> btw
<mwhudson> some kind of anonymous smart server access to lp would be nice!
<mwhudson> i guess this is still lurking at the "not important enough" level
<lifeless> well
<lifeless> loggerhead does it
<lifeless> probably just need:
<lifeless>  - permit the url through
<lifeless>  - resource it
<poolie> there is a bug for it
<spiv> poolie: any objections to me landing https://code.launchpad.net/~bialix/bzr/2.3-py2exe/+merge/55103 ?
<spiv> poolie: it's been sitting around for a while and looks safe enough.  My main hesistation is that it's sort-of adding a feature to a stable release series.
<spiv> poolie: but my I'm inclined to think it's worthwhile despite that.  I guess you could say that it's fixing a bug (not being able to install plugins when using the windows .exe) rather than adding a feature.
<poolie> it's ok with me
<poolie> bialix is probably best placed to judge the risk of it
<poolie> let's not let it sit anyhow
<vila> hi all !
<spiv> poolie: thanks!
<poolie> oh i was going to ask you to do a pp report
<poolie> we've got a bit out of the habit but there were a lot of patches this week
<vila> spiv: +1, I think the issue here is that it's landing into core when it's really a windows installer bug
<poolie> and you did a lot on them
<vila> poolie (et al. ;): config stuff sneak preview available at lp:~vila/bzr/new-config,
<vila> beware, it's a loom, but it contains the minimal implementation of the needed building blocks
<vila> it still lacks doc (which I will write today)
<vila> it's currently ~1000 lines tests + code (evenly split, amazing...) and define 9 threads for review (the upper two are not relevant)
<vila> so, to really see where I'm heading you can look at the config-concrete-stores and config-concrete-stacks threads to get an idea
<spiv> vila: speaking of configsâ¦ https://code.launchpad.net/~abentley/bzr/appenddir/+merge/50060 is stalled, and you're probably the best person to unstall it
<spiv> vila: is it still Needs Info for you, after the reply from Aaron?
<vila> spiv: yeah, that's part of the motivation for focusing on config :)
<vila> basically I'd like to get rid of policies as they are today and I'm still unclear about whether this can land soon enough to provide an alternative
<spiv> vila: well, at the least put a comment on the merge proposal saying what we're waiting for
<spiv> vila: so other people (like patch pilots ;) can understand where it's at, and why
<poolie> hi vila
<vila> spiv: done
<vila> poolie: hey !
<poolie> vila i'm not a big fan of policies either, and i'm not very keen to add more of them
<vila> poolie: rationale added in the comment
<poolie> i think it complicates the user model a fair bit for what it actually buys us
<vila> +1
<poolie> vila, do you think you could send a short overview of that loom
<poolie> like, 3 paragraphs?
<vila> poolie: I was about to make a "fake" merge proposal for it with a bit of high level description of the goals, sounds good ?
<poolie> mm
<poolie> rather than the goals i'd be more interested in
<poolie> what changes to the user experience there are, if any
<poolie> and what changes to the api there are, if any
<poolie> i think we pretty much agree on the goals in your previous mail
<vila> ha right, bad words again
<vila> I thought new API and what is still needed to actually use it in bzrlib
<vila> but also mentioning some issues that this new design is ought to address
 * poolie branches it
<spiv> vila: thanks!
<vila> spiv: does my comment makes sense ? Explain why I was apparently silent on the subject ?
<spiv> vila: yes
<vila> thanks
<poolie> vila, one comment on your docs
<vila> https://code.launchpad.net/~vila/bzr/new-config/+merge/56887
<poolie> (i've done the opposite on this myself in the past)
<poolie> and that is, describing the current problems in documentation that is intended to be merged and carry on into the future is bad
<vila> forget about the doc in this loom, I plan to rewrite it from the ground up separating user and dev povs
<poolie> the config doc starts off with what will be, in september 2011, a description of primitive history
<poolie> ok
<spiv> poolie: should https://code.launchpad.net/~mbp/bzr/506265-command-deprecation/+merge/55030 be marked Work In Progress rather than Needs Review?  The last comment suggests you're going to do more work.
<poolie> spiv tbh i wouldn't mind a tie-breaker there
<vila> poolie: at most, I will outline issues with specific markup or something so they stay up-to-date with the code
<poolie> it is not perfect but in some ways i want to just land it
<poolie> and then add a general configuration option to turn off particular warnings
<poolie> for which i think there is a bug
<vila> poolie: oh, I wouldn't mind landing incomplete stuff if it makes further submissions easier to review
 * vila LOL
<poolie> vila, perhaps the "here's what's bad today" belongs in a bug or a set of bugs
<poolie> nice, but i was talking to spiv
<vila> poolie: it belongs to devnotes in my mind
<vila> poolie: yeah, I understood, was just being silly ;)
<vila> poolie: I also thought about easy ways to deprecate config options so if you work on easily deprecating commands I know I
<vila> I'll benefit from it (damn badly placed return key !)
<spiv> poolie: so what's the downside?  That there's no way for a user to suppress the warnings currently, even if they alias get=branch?
<poolie> yes
<poolie> that's the only problem i know of
<poolie> there may be others
<spiv> poolie: Ok, in that case I agree let's just land it and find out if there are any others :)
<spiv> poolie: (but file a bug for being able to suppress the warning, if there isn't already)
 * spiv updates the MP
<vila> poolie: Is the cover letter for https://code.launchpad.net/~vila/bzr/new-config/+merge/56887 answer your needs ?
<vila> poolie: or do you want more details on say, policies for example, or option converters or <fill the blank>
<poolie> spiv, we're more likely to find the unknown unknowns if we land it
<poolie> vila it's a good start
<spiv> poolie: precisely
<spiv> poolie: Be Bold, as wikipedia would sayâ¦
<vila> poolie: you said 2 or 3 paragraphs, I tried to make it short ;)
<spiv> poolie: that makes three approved patches you have waiting to be fed to PQM.  Is there any reason not to run those through feed-pqm now (aside from any inconsequential stuff like needing to set commit messages)?
 * spiv is hoping to get http://webnumbr.com/bzr-active-reviews back down to pre-April heights.
<poolie> spiv, please do
<poolie> i did get some pqm failures earlier but i have not worked them out yet
<poolie> you might as well feed all the approved ones though
<spiv> Ok, that should keep PQM busy for a while.
<poolie> vila: i replied
<vila> poolie: hmm, food for thought...
<vila> poolie: at first glance I think we agree but don't understand each other yet
<poolie> :)
<vila> ha, right, I misread 'reusing existing objects' at first read,
<vila> you mean we should reuse config files that has been already read from disk ?
<vila> (I misread it as: we should reuse python classes we already defined)
<spiv> vila: it sounds more like 'reuse instances' than 'reuse classes' to me
<vila> yeah, I agree with that, this is not apparent in the implementation but it's definitely on my agenda
<vila> so, not apparent *yet*
<vila> but roughly there should be something ~like possible_transports for config Stores
<spiv> vila: hmm.
<poolie> vila, wow, interesting point about fixed bugs
<poolie> it reminds me how much i dislike all the 'fix released' bugspam you can get
<vila> spiv: the intent being that a given config file should not be read more than once for a given bzrlib operation (as opposed to read once by option today)
<poolie> perhaps that idea should really go into lp
<poolie> ie merge those states and say the milestone the fix is in is released, or not
<spiv> vila: for configs tied to branches or working trees, that might be good.  For globals though I think it'd be weird to have to pass around a param everywhere when it's "global"
<vila> spiv: yup, I think we *shouldn't* pass it around *because* it's global
<spiv> vila: off the top of my head, poolie's suggestion that it could be stored on the library_state sounds good to me
<vila> spiv: it's even defined *outside* of bzrlib: inf files on disks
<vila> spiv: yup, agreeing to that too, replying
<spiv> vila: cool
<vila> spiv: in fact, it's either user (or site) specific and should be tied to libstate, or it's branch/wt specific and should be tied to that
<poolie> vila https://bugs.launchpad.net/launchpad/+bug/163694
<ubot5> Ubuntu bug 163694 in Launchpad itself "Fix Committed/Released distinction is inconsistent and unproductive" [High,Triaged]
<poolie> vila, one specific point for the library_state is:
<poolie> if that was done properly, there would not need to be any config-specific test isolation code
<poolie> which would be nice
<vila> spiv: which should be ... yeah to what poolie said ;)
<poolie> (well, there may need to be some to isolate it from the environment in which the tests are run, but we should get for free isolation of one test from the next)
<vila> poolie: e-x-a-c-t-l-y
<vila> use TestCase and rest assured you're isolated
<vila> the more I think about it, the more I view global configs as... compilation options. But because we use python, we can handle them dynamically
<vila> Still, you want the code associated with the options to be well tested
<vila> and you want easy ways to test them
<poolie> well
<poolie> even in TestCase, it would be good to have fewer things that specifically isolate different aspects
<poolie> spiv thanks for feeding in  https://code.launchpad.net/~mbp/bzr/659763-non-ascii-gecos/+merge/55862
<vila> yup, but some existing things could find their way in configs too
<poolie> it could have been polished more but finishing it is more important than getting the skip message precisely right
<poolie> that too!
<poolie> i have seen many tests that could be better with this
<poolie> also it will give them a less ad-hoc way to control what happens in the code under test
<vila> poolie: replied, second read mad more sense, I confirm my original feeling ;D
<vila> poolie, spiv: Also note that the proposal doesn't make any assumption about what name space is used nor what section names are used/enforced whatever
<vila> I knowingly limit myself there to what is used *today*
<vila> I still have some strong opinions about how we should change that though ;)
<poolie> vila, i need to go soon
<poolie> to meet spiv, actually
<vila> But hopefully these opinions can be expressed in further submissions focusing the discussion and more importantly *not* blocking the building blocks to land
<vila> poolie: no worries, I still have plenty to do
<vila> poolie: and I optimistically consider that we agree enough to continue ;)
<vila> poolie: gee, bug #163694 has a real high S/N ratio... still reading
<ubot5> Launchpad bug 163694 in Launchpad itself "Fix Committed/Released distinction is inconsistent and unproductive" [High,Triaged] https://launchpad.net/bugs/163694
<poolie> it is nice
<maxb> hrm
 * maxb gets an unexpected need to re-oauth hydrazine to lp
<maxb> poolie: Would it upset you if I set append_revisions_only on hydrazine trunk? :-)
<vila> maxb: bad symptom, I remember poolie venting (first time I ever witness that ;) about a lp API change.. may be related
<maxb> ironically I think it's poolie's changes which probably caused it for me :-)
<maxb> But yes, I am deeply disappointed about launchpadlib's cavalier approach to api compatibility
<poolie> maxb, sorry for the bump, please do
<poolie> i would like that to actually become the builtin default
<poolie> but it will take a bit of consideration
<poolie> that reminds me to comment again on that bug
<maxb> Well - I think it should be the default for server-hosted always-remote branches, but probably not for local working areas
<maxb> or maybe it should be the default even there, but there should be a y/n prompt or dedicated option to say it's ok
<maxb> or maybe it should be on for push but off for pull :-)
 * maxb stops brainstorming into the channel
<vila> options, options, so many gems waiting to be used from inside bzrlib, so little ways to get there (so far ;)
<maxb> OK, so to finish the hydrazine point I raised: Yes, hydrazine has changed its credentials storage path and you will need to reauthenticate.
<maxb> I wonder if it's worth migrating old credentials
<poolie> maxb, are you going to come and meet us in london?
<poolie> some of the time?
<poolie> it's from the 16th of may on
<maxb> oh, that reminds me
<vila> . o O (Please say yes)
<poolie> ah i was thinking of https://bugs.launchpad.net/launchpadlib/+bug/752095
<ubot5> Ubuntu bug 752095 in launchpadlib "Launchpad constructor parameters changed incompatibly in natty" [Undecided,New]
<maxb> I was going to send a "Hi, what do you do at these things,  and how much is worth attenting for non-employees?" email
<maxb> I have holiday allotment to spare, so I might turn up for the entire week if it's sensible to do so
<poolie> so, we'll mostly just pair on things together
<poolie> there will be some talking but mostly hacking
<poolie> and just hanging out together
<poolie> in the evenings or whatever
<maxb> hmm. I could finish off some of my limbo-ed bzr-rewrite and udd branches :-)
<poolie> that would be nice; you could probably get someone to work on it with you
<poolie> it is pretty non-corporate, i would say
<poolie> in canonical's early days there was a lot of spec-writing at UDS and other sprints
<vila> maxb: It tremendously helps understand each other better to have face-to-face discussions and the consequences are still seen months after a sprint
<maxb> Well - sounds like it could be fun, so you'll be seeing me there for some, if not all of the week :-)
<vila> \o/
<vila> I still remember AfC face from years ago and it gives a different color to everything he said since then, for example
<poolie> ok good night guys
<poolie> :)
<vila> poolie: enjoy your week-end !
<vila> maxb: and that's without counting the high bandwidth during the sprint itself of course
<vila> poolie: (too bad you're gone) https://bugs.launchpad.net/launchpad/+bug/163694/comments/28 ... nicely summarized and cross-linked, S/N enhanced :-)
<ubot5> Ubuntu bug 163694 in Launchpad itself "Fix Committed/Released distinction is inconsistent and unproductive" [High,Triaged]
<dije-away> Tried yesterday, trying again today:
<dije>  Doing a checkout to my home directory from a branch at ~/bzr_scm/dot, I
<dije> get the following error:
<dije> bzr: ERROR: Failed to rename /Users/phil/Library/Preferences to
<dije> /Users/phil/.bzr/checkout/limbo/new-159/Preferences: [Errno 13] Permission
<dije> denied
<dije> (On Mac OS X 10.5.8, Titanium PowerBook G4)
<vila> dije: from an OSX pov, renaming  /Users/phil/Library/Preference sounds really dangerous
<dije> vila: right, so why is bzr doing it?
<vila> dije: what do you version in ~/bzr_scm/dot ?
<dije> vila: My home config
<vila> dije: cause you asked it to :) Why you asked it to is the question
<vila> dije: more precisely ?
<dije> vila: config files for:
<dije> tcsh
<dije> emacs
<dije> screen
<vila> you version files that are under library/preferences ?
<dije> ratpoison
<dije> vila: I think so
<dije> vila: Probably Mozilla*
<vila> dije: ok, so to clarify, try to branch in a different directory to see which files are versioned
<vila> dije: different from your home directory that is, so ~/test will do
<dije> vila: Everything in bzr_scm/dot is versioned, that's its only purpose
<vila> dije: I'm searching for specifics, *everything* is not specific
<dije> vila: Sorry, answered too soon (after you typed "versioned")
<dije> vila: So I'm looking for specific diffs in permissions only, and/or existence vs. non-existence, and/or content diffs?
<vila> hard to tell :-/
<vila> start for searching for files/dies under lib/prefs
<dije> vila: Will get started
<vila> dirs not dies
<dije> vila: You said branch, I'm trying to checkout; which do I need for this exercise?
<vila> also, *why* do you get permission denied there ? what does 'ls -dl lib/prefs' says ?
<dije> vila: Set-group-id. Weird
<dije> vila: (until I chmod'ed it)
<vila> hmm, can you check what is the default chmod for another user ?
 * vila curses not having an osx setup at hand
<dije> I did, against my own (the machine under discussion is my parents')
<dije> I'm maintaining it remotely over ssh
<dije> My machine differs in being Intel not PowerPC, but same OS release.
<dije> The perms on ~/Library/Preferences show as drwx------+ on my machine
<dije> and on theirs as drwx------@ (after I chmod'ed it)
<vila> hmm, so that @ is for extended attributes IIRC, but no idea what they are
<vila> bzr is still failing after your chmod /
<vila> ?
<dije> OS X (HFS+) does ACLs, but they've never been used on either machine to my knowledge
<dije> bzr is still failing
<dije> Same error
<vila> attrs can be more than just ACLs IIRC
<vila> ok, try to rename it from the finder ?
<dije> Rename ~/Library/Preferences?
<dije> Sounds dangerous
<vila> oh, wait, you don't have weird mounts or something where ~ and ~/lib/prefs are on different volumes right ?
<dije> No. Good check though.
<vila> dije: yes, this one, you can revert it
<vila> if it works from the finder, try from a terminal, I'm trying to see how to reproduce without bzr being involved, it's a file system issue at the root
<dije> Oh no, remote machine is gone! Parents are coming to lunch, I think they're bringing it
<dije> Sorry
<vila> dije: and yes, it's dangerous in itself but
<dije> It's near 11am here
<vila> oh wait ! You said accessed thru ssh ?
<dije> Right, I run screen on their machine and (re-)attach to it over ssh
<vila> ha, ok, so bzr runs locally not on top of an ssh fs right ?
<dije> Right
 * vila rules sshfs fuse bugs
<vila> out
<dije> yes
<dije> It's a single-disk, single-cpu, single-user (mainly), router-and-one-computer-LAN home office setup, absolutely nothing fancy apart from DynDNS and my remote access
<vila> ha, finally found an OSX host I can look at with ssh
<vila> cd Library ; mv Preferences toto
<vila> mv: rename Preferences to toto: Permission denied
<vila> ok, so, we can't do that, that's a point, we can now switch to *why* are we trying ;)
<dije> ditto on my Intel machine
<vila> dije: can you retry your failing co with -Derror
<vila> that should give us a traceback, pastebin it and I can look at where it's coming from
<dije> Not til they arrive with the laptop! Sorry
<vila> lol, oh right, try again later then
<dije> Will do, thanks for help so far
<vila> dije: or file a bug explaining our discussion a bit, that will make it easier to track for everybody
<dije> ok
<vila> dije: https://bugs.launchpad.net/bzr/+filebug
<vila> dije: oh, and don't forget to mention your bzr version and where you installed it from (in case the traceback is not clear enough for that)
<dije> vila: will do
<dije> FYI: MacPorts package
<vila> dije: >-/ We don't often hear about it (as opposed to the installers) but while there are some dark areas regarding the dependencies, we didn't hear about blatant bugs there either
<dije> vila: Python should isolate the platform to a degree
<vila> hehe, yeah, to a degree and for some values of isolate ;)
<dije> Right :-)
<dije> I've had MacPorts bzr working on multiple Macs for x > 3 years
<vila> but nothing that should be related to your bug anyway, I still can't think of a cause so far
<vila> wow, great
<vila> and kudos for admin'ing with bzr ;)
 * dije blushes
<dije> Works great across linux and cygwin too
<vila> dije: it it turns out to be a bug related to some internal design, it may be hard (and long) to fix, so, as a *workaround*, I admin some osx hosts myself but instead of versioning the files directly, I use a mix of symlinks or copies of the system files
<dije> I don't version any *system files*, just config files under (in this case) system dirs
<dije> First time the issue has arisen
<vila> right, but the issue is kind of the same, if you need special rights for some operations, using copies works around the issue
<dije> Need to take that into account, maybe redesign my repo
<vila> I can;t think of why we want to rename Preferences though, unless some weird side-effect ends up triggering it
<dije> Already use symlinks extensively
<dije> Yes, that does seem strange
<vila> yeah, me too, but nothing under prefs so far, only under LaunchAgents in fact
<vila> I know Preferences is localized when looked at from the finder, but at the fs level, it's always Preferences
<vila> so this should *also* rules out any fancy language change from your parents
<dije> had not thought of that!
<dije> More weird detail: the target dir *used* to be versioned, but when I tried to sync up for the first time in quite a while (x > 6 months) I found no .bzr dir
<vila> oops, someone deleted it ?
<dije> The branch in ~/bzr_scm/dot was intact and synced fine with my remote machine
<vila> or moved it ?
<dije> Well, "someone" could only have been me
<vila> no restore from backup ?
<dije> In a fugue state
<dije> This *is* my restore-from-backup strategy
<vila> dije, well, your parents can too no ? They have physical access to the mac I presume ;)
<dije> Yes but not admin, and they have nothing like the skills to single-user-boot
<vila> maybe moved somewhere else ?
<dije> Maybe
<vila> err, wait, oh you mean that's inside your own account ?
<dije> Right
<vila> aaah
<vila> yeah, of course, makes sense
 * dije spots light going on over vila's head
<vila> eheh
 * dije holds breath
<vila> no no keep breathing ;)
<dije> phew
<vila> ha, one possible scenario (but hairy)
<vila> you somehow, by working on two different branches (one local, one remote), added Preferences twice
<vila> each add creating its own file-ID for it
<dije> omg
<dije> sounds feasible
<vila> now, updating the remote tree, creates a conflict to tell you that (A so-called Content Conflict: the same name for two different objects)
<vila> *This* could lead to an attempt to rename the dir
<vila> ha no, wait, that's simpler than that !
<dije> Really?
<vila> You're trying to checkout an existing branch onto an existing tree and bzr try to move the items that are on its way !
<dije> Yes, lots and lots of them
<vila> damn, I didn't realize the fallouts of 'the .bzr dir has disappear'
<vila> wow, hmm, how to recover from that...
<dije> Can't checkout to some new dir, then move files including .bzr/ ?
<vila> the most obvious will be to create a clean tree somewhere and just move the .bzr dir
<dije> That answers that :-)
<dije> So the move of .bzr is necessary; is it sufficient, or do I need to move all the checked-out files (that differ) as well?
<vila> dije: hmm, I think you found a nice bug, trying to do a checkout in an already populated directory is likely to cause chaos and we shouldn't even try (unless there are use cases that escape me at the moment)
<vila> dije: no, that's the nice bit
<vila> move the .bzr dir only (restore it in fact)
<vila> and 'bzr st' will tell you about the changes
<dije> Use cases like this PEBKAC ?
<vila> from there you can decide if you want to 'bzr commit' or 'bzr revert'
<vila> dije: It's hard to say
<vila> as you present it, you're just trying to restore order and bzr answer is creating even more chaos, not *that* helpful ;)
<vila> Now, recovery plans are not always the cleanest process in the world...
<dije> vila: Great, this gives me hope. So, I checkout to ~/foo, then mv ~/foo/.bzr ~/, then either bzr commit or bzr revert.
<vila> dije: 'bzr st' first !
<dije> Where do I bzr st first, in ~ or ~/foo?
<vila> dije: both :)
<vila> dije: to make sure we don't run into path issues:
<dije> Hang on, can't 'bzr st' in ~ ... no ~/.bzr!
<vila> cd ~/foo ; bzr st; bzr info
<dije> OK
<vila> check the paths mentioned by the later if some are relative you may run into trouble by moving .bzr
<vila> if they are absolute, you should be fine, so:
<vila> mv ~/foo/.bzr ~/
<vila> cd ~
<vila> bzr st
<dije> OK
<vila> should tell you the differences between the basis revision (the one defined in the branch) and the actual content on disk
<vila> from that, it should be obvious to you, either the tree is correct: bzr commit
<vila> or the tree is wrong: bzr revert
<dije> Got it. You are a genius.
<dije> What if paths are relative?
<vila> if it's a mix, well, 'bzr revert <file>' or 'bzr commit -m 'recover from ???' <file>'
<dije> Can I edit something under ~/.bzr to fix paths?
<vila> dije: you will need to edit them in /.bzr/branch/branch.conf probably
<dije> Cool
<vila> dije: you're a fast learner :)
<vila> dije: really, the missing bit was '.bzr disappear' and I'm trying to recover
<dije> Right
<vila> dije: I may have understood faster what was going on if you started with that, but, hey, bug reporting when you know what the bug is is so easy ;D
<dije> Right, hindsight helps
<vila> dije: worth filing a bug *anyway* if only to remind us how confusing the error was for you (and even for me)
<dije> Techie view is to start with the detail instead of the big picture
<vila> yeah, not blaming you here, just sharing thoughts
<vila> I'm not sure I would have done better...
<dije> Understood
<vila> but telling the story often works better than focusing on the end ;)
<dije> Ain't it the truth?
<vila> on the other hand, some stories are full of useless details :D
<vila> doomed if you do...
<vila> ok, lunch time here, bbl
<dije> thanks
<cheater99> hi
<cheater99> is it very difficult to set up bzr on a server so that i can check in files from home and the office?
<vila> cheater99: if bzr is installed on the server *and* you also happen to have ssh available there *then* you're all set
<vila> cheater99: i.e. if the server is unix-based, you're done, if it's windows.... it's harder but doable, but I don't remember who knows about the gory details
<cheater99> vila: yeah i have a dedicated slicehost server
<cheater99> with ubuntu 10.04 on it with root access
<Peng> Excellent. No problem, then.
<cheater99> so how does it work then? is there some sort of tutorial?
<Peng> Ubuntu even has a package for bzr, though it ain't entirely up-to-date.
<cheater99> what is missing in the package?
<Peng> Missing?
<cheater99> well you said it was out of date
<cheater99> so there are probably some cool new features missing, or bad bugs, otherwise there wouldn't be a mention, right?
 * Peng shrugs
<Peng> I don't know anything specific at the moment. Distro packages are never entirely up-to-date, which is usually okay.
<cheater99> oh ok :)
<Peng> It's okay unless a newer version has the *one* feature or *one* minor bug fix you need. ;-)
<jam> Peng: that's what ppa's are for :)
<cheater99> Peng: :)
<Peng> Right. I should've mentioned that...
<cheater99> nah, don't want to bother with ppa's
<Peng> Well, you don't have to, but it wouldn't be much of a bother anyway.
<Peng> dash____________: Quite a tail you've got there.
<\sh> moins...has anyone the new location of the bzr eclipse package? http://verterok.com.ar/bzr-eclipse/update-site/ <- doesn't work...
<vila> cheater99: with 10.04 it's only 'add-apt-repository ppa:bzr' *once* and then you get stable releases for bzr and plugins as you get the updates for Ubuntu itself
<cheater99> hmm
<vila> err, that's ppa:bzr/ppa sorry
<cheater99> but i don't see any need for a newer version
<vila> right, your choice, but lucid carries only 2.1 and we almost don't backport fixes on 2.1 anymore
<cheater99> do you think lucid will upgrade to a newer bzr?
<vila> anyway, back to your initial question, once bzr is installed and an ssh server active, you're set, you can start using bzr+ssh: urls
<vila> lucid will receive SRUs when we get to that, it carries 2.1.1 now and we have 2.1.2, 2.1.3 already released but not SRUed
<cheater99> what are SRU's?
<vila> ha, soory for the jargon, roughly they are described here http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates for bzr with links to more general definitions
<jam> cheater99: SRU is getting an updated version into the official Ubuntu Updates repositories
<cheater99> gotcha
<cheater99> ok, when an SRU for 2.2.4 happens, will it be put in the ubuntu 10.04 repository?
<cheater99> or will it be put in maverick or something like that?
<jam> cheater99: it isn't the original repo, it s the "updates" one, so I think you have to enable it, but it will be the 10.04 repo
<vila> cheater99: try 'rmadison bzr' , SRUs will never cross series
<cheater99> ok, gotcha
<vila> so lucid will for ever carries 2.1
<jam> vila: right, so if you want 2.3.x, then you want a ppa
<cheater99> ah ok, gotcha
<vila> cheater99: that's why Peng mentioned the ppa, with the stable ppa, you'll get the most stable release, which is 2.3 currently
<verterok> \sh: I'm trying to get the server fixed...should be available soon-ish
<cheater99> i thought i would get 2.3 in the end, just later
<vila> jam: yup, you're typing faster than me ;)
<cheater99> but in this case, let me set up the ppa
<vila> cheater99: err, if you setup the ppa, you'll get 2.3 *now*
<vila> cheater99: which is fine :)
<cheater99> yes
<cheater99> that is what i have meant, i will get 2.3 when i use the ppa, i will not if i don't
<vila> cheater99: and you'll get updates faster as building for the ppas is lighter than going through the SRU proces
<vila> ha, right, yes, that's it
<vila> . o O (With such a nick, I thought he will prefer the ppa...) :D
<cheater99> lol
<cheater99> ok, i think something is broken. now i have added the wrong repository :D
<vila> how so ?
<cheater99> i copy-pasted without fixing the ppa url :D
<cheater99> now i am wondering how to fix this using the command line
<vila> and you ended up adding what then ?
<cheater99> add-apt-repository ppa:bzr
<vila> cheater99: I don't remember the details for lucid, but it's either in /etc/apt/sources.list or /etc/apt/sources.list.d/
<cheater99> the funny thing is i cannot find the ppa in /etc/apt/sources.list
<cheater99> ok it's in .d
<vila> ha, good
<vila> cheater99: in any case, it's described at https://launchpad.net/~bzr/+archive/ppa
<cheater99> =)
<vila> honestly, I have no idea where ppa:bzr is pointing to... what what the url in apt ?
<vila> what was ! (grr)
<cheater99> not sure anymore
<cheater99> let me add it again and see
<vila> never mind
<cheater99> nah let me do it just a sec
<cheater99> now i wish the python-support trigger weren't so sluggish
<cheater99> that's the one thing i hate about installing things on ubuntu right now :D
<\sh> verterok: ah thx a lot :)
<cheater99> ok it turns out to be deb http://ppa.launchpad.net/bzr/ppa/ubuntu lucid main
<cheater99> whereas the "correct" url that you gave me later does: deb http://ppa.launchpad.net/bzr/ppa/ubuntu lucid main
<cheater99> so, the same thing in the end :D
<vila> lol
<vila> so what is broken then ?
<cheater99> nothing i guess
<vila> ha cool
<cheater99> it just works
<vila> yeah, ppas are lovely
<vila> and add-apt-repository really closes the loop, before karmic you needed to hand-edit sources.list *and* fetch the gpg key too after copying it from somewhere (when possible)
<cheater99> ok, now i have a problem: add-apt-repository doesn't exist on 10.04 on slicehost
<cheater99> and aptitude search brings up nothing either :D
<vila> 8-/
<cheater99> googling..
<cheater99> http://ubuntuforums.org/showthread.php?t=1320536
<cheater99> aight, getting bzr installed!
<vila> apt-get install apt-file ;  apt-file search add-apt-repository, pfew that was tedious and so slower than you ;)
<vila> but at least I now know how to do it :D
<cheater99> :D
<jelmer> busy day for pqm today :)
<cheater99> ok.. i am doing my initial commit, and it's not big, it's just under maybe 100 mb, but i'm not sure what is going on with it
<cheater99> it's stuck at "^[[Bloading data to master branch - Stage:Fetching revisions:Get stream source"  ... ok pressed some buttons
<jam> cheater99: if you are using a checkout, then it is copying the 100MB you just committed up to your remote branch.
<cheater99> yeah i am
<cheater99> i was a bit surprised that it was so silent and there was no progress indicator
<cheater99> i was afraid it hung up
<jam> cheater99: I'm surprised there isn't a progress indicator
<cheater99> nope none
<cheater99> is this a bug?
<jam> cheater99: not one that I know of. Feel free to report one
<cheater99> would you yourself expect an indicator there?
<jam> yes
<jam> if there is a lot of transport activity going on, we should be indicating it
<cheater00> i would even say just have a spinner show up after a few seconds
<cheater00> to show activity...
<cheater00> and, if it takes even longer, have an interactive input ("Press v to monitor progress") which starts showing you what's going on
<cheater00> this could probably show up after half a minute, and people wouldn't be freaking out
<kirkland> question about bzr-builddeb ...
<kirkland> as of *very* recently, i can no longer test/build with bzr bd, if my distribution is "unreleased"
<kirkland> this is kind of a bummer, as I *always* do that, before go through my release processes
<kirkland> is this a bug, or new behavior by design?
<kirkland> bzr: ERROR: Unknown distribution: unreleased.
<maxb> I seem to recall some conversation about that
 * maxb tries to recall *where*
<kirkland> maxb: my build/release scripts are all broken right now, and i'm trying to find a workaround :-(
<maxb> kirkland: What version are you using, because I'm seeing a recent commit claiming to specially support UNRELEASED
<kirkland> maxb: bzr                               2.3.1-1ubuntu1
<maxb> kirkland: of bzr-builddeb
<kirkland> maxb: bzr-builddeb                      2.7.2
<kirkland> maxb: tis what's in Natty 11.04
<maxb> kirkland: wait, "unreleased", literally? Not "UNRELEASED" ?
<kirkland> maxb: i have tried both
<kirkland> maxb: with lowercase, I get:
<kirkland> bzr: ERROR: Unknown distribution: unreleased.
<kirkland> maxb: with upper case, I get:
<kirkland> bzr: ERROR: Unknown distribution: None.
<kirkland> maxb: which is a little odd ;-)
<maxb> Ah.... is there one and only one changelog entry in this debian/changelog ?
<maxb> kirkland: ?
<kirkland> maxb: yes, exactly, new package
<maxb> Right, ok then.
<maxb> So 1) the existing changes break using bzr bd on new packages
<maxb> 2) the existing changes forbid the use of bzr bd for arbitrary third-party repositories
<maxb> both are nasty bugs IMO
<kirkland> maxb: yeah, thanks
<maxb> kirkland: I will be pushing a branch with a proposed fix shortly
<kirkland> maxb: great, thanks
<kirkland> maxb: i'll +1 that for getting into Natty, as it's going to make my life hell, managing dozens of projects/packages in lp/bzr
<maxb> james_w: Are you around to comment on this? (This being that bzr-builddeb should not error if it cannot recognize the distribution of the top changelog entry?)
<maxb> kirkland: If you would like to test out my branch, "bzr branch lp:~maxb/bzr-builddeb/no-error-unknown-distro ~/.bazaar/plugins/builddeb"
<kirkland> maxb: will do, give me a couple of minutes ...
<james_w> maxb, indeed it should not
<maxb> branch merge-proposed :-)
<Deathzor> hey guys just wondering is there some way to push into a different branch then you pull from ( without having the user change the target )
<dash> Deathzor: sure, 'bzr push <url>'
<Deathzor> dash: not exactly what i'm looking for but oke ( i'm trying to find some way of hooking in a testing system at the central repo ) that allows me to make sure i don't accept any untested code.
#bzr 2011-04-09
<psusi> how do you get bzr to remove unknown files?  like git reset --hard?
<poolie> psusi, bzr clean-tree
<psusi> ahh, ty
<poolie> np
<poolie> see also 'bzr clean-tree --ignored
<luks_> any way around this? http://paste.pocoo.org/show/368383/
<luks_> LP seems to be trying to stack on a branch with incompatible format, which fails
<thumper> luks_: either upgrade trunk to 2a, or pester the bzr devs to add a flag to push to say (no... really don't stack)
<thumper> luks_: there is an incredibly hacky solution that used to work
<thumper> I'm not sure if it still will...
<thumper> you start a push but terminate it with Ctrl-C
<thumper> that creates the basics of the branch and db structure
<thumper> but it hasn't set any stacking info
<thumper> then you push again
<luks_> thumper: I've found out that nosmart+lp: works
<thumper> really?
<luks_> yep, it doesn't try to stack
<thumper> weird
<thumper> that is probably a bug :-)
<camason_> hi guys. I've SSH into a remote machine and I'm trying to do some merging etc, but I'm getting `bzr: ERROR: gnomekeyring.IOError:`
<jelmer> camason_: that's a known bug in bzr-gtk, should be fixed in newer versions
<camason_> jelmer ok - any way I can merge whilst over ssh?
<jelmer> camason_: install a newer version of bzr-gtk or disable it for the moment
<jelmer> e.g. by setting BZR_DISABLE_PLUGINS=gtk
<cheater00> hey guys
<jelmer> hi cheater00
<cheater00> is there a way to continuously use both hg and bzr?
<cheater00> at the same time?
<jelmer> cheater00: how do you mean?
<cheater00> i have a bzr repository, but i want to start using fogbugz and kiln
<cheater00> kiln is hg based
<jelmer> cheater00: there is a bzr-hg plugin which adds support for hg format repositories to bzr
<jelmer> I should note it's alpha at this point though
<cheater00> what about converting from bzr to hg?
<cheater00> and keeping on converting every time i push to bzr?
<cheater00> like a bidirectional bridge ..
<jelmer> cheater00: you cna push from a bzr branch into a hg branch but you'll lose some metadata
<cheater00> what metadata do i lose?
<jelmer> and that's still very much experimental as well
<jelmer> cheater00: renames, revision properties, revision parents if there are more than two
<jelmer> cheater00: see "bzr dpush"
<cheater00> why are renames lost?
<cheater00> i'd have expected hg to support something as simple as this
<jelmer> cheater00: they're copies + deletes in hg, don't map easily to renames in bzr
<cheater00> hmm... why?
<jelmer> cheater00: why what?
<cheater00> why don't copy+delete in hg map easily to renames in bzr?
<jelmer> cheater00: it's hard to get it to work while not hurting performance significantly
<jelmer> cheater00: anyway, for the moment bzr-hg dpush is probably not ready for production use
<cheater00> oh? how so?
<cheater00> gotcha
#bzr 2011-04-10
<kgoetz> ah. i just exploded bzr
<kgoetz> does the bot report bug numbers? just filed https://bugs.launchpad.net/bzr/+bug/756228 . would it be useful for me to keep a copy of the repo for testing?
<ubot5> Ubuntu bug 756228 in Bazaar "bzr: ERROR: exceptions.StopIteration" [Undecided,New]
<d1b> hi um i did a bzr clone lp:~launchpad-pqm/launchpad/stable in a vm with 256mb of ram
<d1b> it is taking a long time and using a fair amount of memory
<d1b>  539m 171m  956 D  4.6 69.9   3:15.61 bzr
<d1b> it is Bazaar 2.1.2
<d1b> interesting it got oom killed :P
<d1b> fail++
<lifeless> uyeah
<lifeless> you'll need a little more ram than that
<methods> can the bzr web repo browser allow people to edit and commit ?
<jelmer> methods: no, although you can e.g. run wikkid to allow editing of bzr branches from the web
<methods> hm wikkid ?
<methods> https://launchpad.net/wikkid
<methods> that one ?
<jelmer> yep
<vokoda> hi, is it ok to ask about loggerhead in here?
<lifeless> sure
<vokoda> ok, so I'm running loggerhead 1.18.1 on a high port, and serving it up via nginx pass_proxy, which works fine at mydomain.com. but now I want to serve from mydomain.com/bzr - i've set my nginx location in the usual way, and i can see the requests going through to loggerhead: GET /bzr/ HTTP/1.0... etc. but i just get a 404 response and "The resource could not be found."
<vokoda> i've set prefix=/bzr in my loggerhead.conf
<vokoda> but that was on a whim
<vokoda> i couldn't find any real docs for loggerhead config
<vokoda> is prefix= deprecated? it doesn't seem to be doing anything
<lifeless> do you have pastedeploy installed ?
<vokoda> not sure, i installed via apt-get from debian stable. but it works at mydomain.com/, so presumably i do?
<lifeless> loggerhead looks for HTTP_X_FORWARDED_SERVER
<lifeless> to determine its virtual path
<lifeless> is nginx setting that ?
<lifeless> (see loggerhead/main.py)
<maxb> Random other comment, loggerhead.conf is deprecated and does not exist in future loggerhead versions
<vokoda> maxb: i'm actually using serve-branches.conf, I presume that's just a different name for loggerhead.conf?
<maxb> actually, no :-)
<maxb> serve-branches.conf is an invention of the debian packaging which just passes a few values to the init script to use on the command line starting the server
<vokoda> right, ok
<vokoda> mine is very simple
<vokoda> http://paste.pocoo.org/show/369250/
<vokoda> lifeless: googling 'HTTP_X_FORWARDED_SERVER nginx' turns up nothing
<vokoda> so i guess it's a job for tcpdump
<vokoda> or pdb but I'm not up for that right now
<mDuff> IIRC, setting up any headers to be added on proxying has to be explicit in nginx
<vokoda> mDuff: ah, proxy_set_header
<vokoda> lifeless: looks like loggerhead/main.py raises an error if 'HTTP_X_FORWARDED_SERVER' is set?
<lifeless> vokoda: *and* paste.deploy is not present
<lifeless> vokoda: python-pastedeploy is the package, I think
<lifeless> pastedeploy is needed to run behind a proxy
<vokoda> lifeless: sigh.. installing pastedeploy worked, i feel stupid now. I thought serve-branches would be a bit louder about an import error
<vokoda> at least it's working
<vokoda> thanks
<lifeless> vokoda: cool
#bzr 2012-04-02
<KombuchaKip> poolie: Hey poolie. Question for you and everyone.
<poolie> hey
<KombuchaKip> As bzr bundles go, does anyone suggest a file extension, such as .bundle? Or is .patch or .diff fine, even though they are more than vanilla unified diffs?
<poolie> i'd say either .bundle or .diff
<KombuchaKip> poolie: Ok.
<vila> hi all
<mgrandi> hi
<vila> blast, I almost fall for the freenode/acta announcement, time for another coffee ;)
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer
<mgz> morning all
<LarstiQ> hi mgz
<mgz> hey LarstiQ
<poolie> o/ mgz,larstiq
<mgz> hey poolie
<ams_cs> jelmer: ping
<jelmer> ams_cs: pong
<ams_cs> jelmer: did you make any progress on the lp:gcc/4.7 merge problem?
<ams_cs> it is now getting urgent
<LarstiQ> heya poolie :)
<jelmer> ams_cs: no, not much unfortunately
<jelmer> also hi LarstiQ, poolie, mgz
<ams_cs> jelmer: hmm, if I were to take a diff from the upstream branch, and apply it to the local branch as a manual merge, would that be a problem when the problem is solved?
 * ams_cs is looking for work-arounds
<lifeless> ams_cs: as long as it doesn't add files, that should be fine
<ams_cs> lifeless: hmm, it almost certainly will add files
<lifeless> its more complex if it does, because of file ids
<ams_cs> lifeless: if I revert the manual merge before doing the automatic merge, that would be ok as long as none of the new files had local modifications?
<jelmer> you should be able to create consistent file ids by using 'bzr add --file-ids-from'
<ams_cs> so, "bzr diff -r m..n lp:gcc/4.7 | patch -p1 && bzr add --file-ids-from" should DTRT?
<mgz> you need to supply a tree to take the file ids from, but yes, probably.
<mgz> *branch
<mgz> ...or is it tree
<ams_cs> mgz: if I do the wrong one (tree v. branch), will it say so, or will it just silently fail?
<jelmer> ams_cs: it will just say "adding FILE" rather than "adding FILE w/ fileids from other tree" (or something along those lines)
<jelmer> vila: ping?
<vila> jelmer: pong
<mgz> ...this query stuff is silly, most of what vila and I have been discussing this morning should just have been in a public channel
<jml> mgz: this is what you meant by defining __unicode__ to return something consistent? http://paste.ubuntu.com/911396/
<jml> mgz: context: https://code.launchpad.net/~frankban/testrepository/encoding-error/+merge/98207
<mgz> ah, yes, was going to respond to that today
<mgz> jml: exactly
<jml> mgz: thanks.
<jml> mgz: I really appreciate your help with this.
<mgz> and the reasoning is that then we don't need to worry about if the formatting of the exception *already* did the replacement of bytes, thereby invalidating the test
<mgz> the same test, with a stream that has an encoding attribute, would then match u"...MyError: \u201c"
<mgz> .encode(stream.encoding)
<jml> right.
<mgz> bzr-grep is one of the plugins that needed a relative import fix, right?
<jelmer> yes
<mgz> is this build (test) failure on arm something spurious we have a bug for?
<mgz> <https://launchpad.net/ubuntu/+archive/test-rebuild-20120328/+build/3328150>
<jelmer> mgz: isn't that just the normal spurious failure?
<mgz> it's not the one I normally see, but it may well be the normal one for the bots
<jelmer> I've seen this one regularly
<mgz> does seem to be bug 874153 indeed
<ubot5> Launchpad bug 874153 in bzr (Ubuntu) "Spurious per_interrepository.test_fetch.TestInterRepository. test_fetch_parent_inventories_at_stacking_boundary_smart_old failures" [High,Triaged] https://launchpad.net/bugs/874153
<pikkachu> hi, is it possible to deactivate bazaar log or change its path?
<jelmer> pikkachu: you can set the BZR_LOG environment variable
<pikkachu> jelmer: that's the only option? ok
<pikkachu> I'd like to ideally disable it...
<pikkachu> I should set it to 'NUL' http://doc.bazaar.canonical.com/development/en/release-notes/bzr-1.3rc1.html
<pikkachu> thanks!
<mgrandi> does anyone know where the code in bzr-fastimport where the stuff for 'fast-export-from-X' is? i cant seem to find it
<jelmer> mgrandi: it's been removed
<mgrandi> really?
<mgrandi> so then why do i still have access to those commands
<mgrandi> o.o
<jelmer> you have an old version of bzr-fastimport installed I think
<jelmer> we removed it because it didn't really seem useful to ship outdated (and thus buggy) exporters for other version control systems
<jelmer> while there are better ways to get the current exporters
<mgrandi> well they wern't really buggy since they used other sources, but yeah the command line args
<mgrandi> were wrong =P
<jelmer> mgrandi: they used exporters shipped with bzr-fastimport itself (except for git-fastexport)
<mgrandi> well fast-export-from-cvs required cvs2svn/bzr
<mgrandi> and seemed to just call that
<jelmer> the other thing is that the 'bzr fast-export-from-X' code was a really trivial wrapper around the actual fastexport tool, but didn't provide all functionality
<mgrandi> ah ok.
<wgz> what time should I wake up tomorrow morning?
<lifeless> wgz: wat time do you want to wake up tomorrow?
<mgrandi> 8am?
<fullermd> Before noon?!  What kind of sadist are you?
<mgrandi> haha
<mgrandi> one with school at 9 am :>
<jelmer> wgz: how long do you usually eat breakfast ? :)
<jelmer> though I am kind of curious about timezones and stuff too
<wgz> hugs all round :)
<wgz> okay, I'll go for starting at 08:00+01 and eat breakfast very slowly if no one else is around yet
<jelmer> wgz: so that's the same time you guys met up as last week?
<jelmer> but one hour before our scheduled call?
<poolie> hi all
<poolie> i currently have it for, um
<poolie> 7pm
<poolie> oh, i have a conflict
<poolie> 11h from now
<poolie> but i might push it back a bit
<poolie> wgz, 11:30 uk, 12:30 cet
<jelmer> hi poolie
<jelmer> thanks for confirming
<poolie> no what
<poolie> :/
<poolie> this app is confused
<poolie> but those times are correct
<poolie> late enough you oughta be awake anyhow
<wgz> okay, I'll set a less punishing alarm
<poolie> wgz, i think i'm now +9h from you
<jelmer> poolie: yeah, that's 3.5 hours later than two weeks ago I think :)
<KombuchaKip> Is there any way to have bzr ensure that a file has an executable bit set?
<poolie> KombuchaKip, even if someone else tries to turn it off?
<poolie> not built in
<poolie> iguess you could write a hook that forces it
<poolie> i would probably do it from the eg makefile
<KombuchaKip> poolie: The reason I'm asking is there is a script my makefile calls, both under bzr, and the script needs to have its executable bit set.
<poolie> couldn't the makefile chmod it?
<poolie> or, run it directly through '$(SH) script'
<mgrandi> doesn't bzr make sure that the executable bit is set? (as in that it versions that attribute)
<poolie> it does
<poolie> i assumed he was talking about cases where someone intentionally or accidentally unset it
<KombuchaKip> poolie: No, I just mean as in ensuring that when they checkout their working copy, the files are executable that had the attribute set when they were first commit.
<KombuchaKip> poolie: Do you happen to know off hand how users check to see what bzr knows of a file's attributes in a branch?
<poolie> i think bzr ls will show you
<poolie> "when they checkout their working copy, the files are executable that had the attribute set when they were first commit."
<poolie> this should happen automatically
<KombuchaKip> poolie: So changing a file's attributes, via whatever the platform's interface may be, without changing the file's contents, should flag the file as modified?
<poolie> yes
 * KombuchaKip experiments
 * KombuchaKip confirms poolie's claim. Files are listed under modified with an asterisk after their name in bzr status.
<poolie> nice when that happens
<KombuchaKip> poolie: ;)
<dakira> hi.. maybe someone can help me working with launchpad. I just checked out lp:compiz and used add-patch to add a patch. I pushed it to a branch in my userspace: https://code.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot
<dakira> Now when I propose this for merging a lot more than my simple patch is chown in the diff. Why is that? Where did I go wrong?
<mgrandi> a link to the patch you applied and the merge proposal (where it shows the diff) would be good
<dakira> mgrandi: I deleted the merge-proposal as I didn't want anyone bothering with such a huge diff. the patch is here: http://pastebin.com/bNtzZKky
<mgrandi> do you have the diff that it was creating?
<dakira> http://bazaar.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot/revision/766#debian/patches/fix-screenshots.patch
<dakira> mgrandi: no, sorry.. should I propose it for merging again?
<mgrandi> you can probably generate it without doing that
<mgrandi> by trying to merge your branch into lp:compiz
<mgrandi> i think you do this by cding to your branch of lp:compiz and then doing bzr merge <path to your branch>
<dakira> mgrandi: I'm on it
<mgrandi> it might be that addpatch is doing something weird
<dakira> mgrandi: looks just as expected: http://pastebin.com/2N2UxHsG
<mgrandi> so that diff you just pasted is what you expect, but not what launchpad gave you?
<dakira> mgrandi: yep. but fortunately launchpad just send me a mail with the review-diff which I'll upload in a second ;)
<dakira> http://dl.dropbox.com/u/79339/review-diff.txt
<mgrandi> .bzr-builddeb/default.conf
<mgrandi> some things you accidentally added
<mgrandi> i think
#bzr 2012-04-03
<dakira> mgrandi: argh.. I think I see what happened
<mgrandi> oh?
<mgrandi> did addpatch add a bunch of files?
<dakira> bzr lp-propose automaticalle selected lp:ubuntu/compiz as the branch to merge with. That is the branch where the development takes place. lp:compiz is where the merge should happen (it only contains the debian directory)
<mgrandi> ah yeah
<mgrandi> it did seem like there were a bunch of files that were present and got added
<mgrandi> because the branches diverged
<mgrandi> so what is lp:compiz then if dev happens at ubuntu/compiz
<poolie> upstream development ought to be in lp:compiz
<poolie> well
<poolie> that ought to be a mirror, i suppose
<mgrandi> ah makes sense
<dakira> https://code.launchpad.net/~compiz/compiz/ubuntu
<mgrandi> so yeah, just change the merge proposal dest and you should be good
<dakira> this branch is listed in debian/control under the Vcs-Bzr tag
<mgrandi> hmm
<mgrandi> im not too familiar with how lp-propose works
<mgrandi> but poolie can help hehe!
<mgrandi> i have to go, gl
<dakira> poolie: so what do I have to enter as the target branch if I want the above to be the target branch?
<dakira> When I try to propose my branch to be merged back into lp:compiz I get "This branch is not mergeable into lp:compiz."
<dakira> okay.. this looks better https://code.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot/+merge/100539
<vila> hi all
<mgz> morning
<lifeless> ok look, its wgz renamed :P
<fullermd> He's not renamed, he's just on the other side of the world from you, so he looks upside-down.
<mgz> we are certainly each other's evil twin
<fullermd> That's just the sort of thing an evil twin would WANT us to believe.
<lifeless> spiv: https://code.launchpad.net/~spiv/ubuntu/lucid/paramiko/address-families-579530-lucid/+merge/25297
<lifeless> spiv: perhaps that needs a 'delete' button clicked on it or something. I imagine its still in your activereviews list
<jelmer> mgz, vila: are we hanging out now?
<vila> jelmer: waiting for poolie ?
<mgz> jelmer: that's the general plan
<poolie> hi all
<jelmer> hi..
<vila> h...
<vila> hi poolie
<poolie_> hi
<poolie_> am i here?
<jelmer> poolie_: hi
<jml> how can I eliminate this warning? 2012-04-03 10:57:12,217 - udd.scripts.mass_import - WARNING - Error accessing max threads file /srv/package-import.canonical.com/new/max_threads: [Errno 2] No such file or directory: u'/srv/package-import.canonical.com/new/max_threads'
<poolie_> jml, hi, does the file exist?
<jml> poolie_: no. when I create it empty the error goes away. useful error huh?
<poolie_> :/
<poolie_> it's a bit hardcoded
<poolie_> whack james
<ErwinM> Hi, I am looking for the automv plugin, but it seems gone
<ErwinM> 	http://bzr.oxygene.sk/bzr-plugins/automv/ <-- empty
<jelmer> ErwinM: it's now in bzr core I think
<jelmer> ErwinM: "bzr mv --auto"
<ErwinM> Aha, thanks
<ErwinM> Yes, that worked just fine. :-)
<jam> jml: echo 5 > /..../max_threads ?
<jam> I believe it does a live check to allow you to turn up and down the number of running threads
<jam> (udd uses it to lower throughput when LP is under high load)
<jam> I think warning is probably useful for UDD, since it indicates a configuration error.
<jam> Not as useful for your project, though.
<jam> anyway, EOD here, have a good evening to all.
<jml> jam: it runs when the file is empty
<jml> jam: so it's  a bogus warning.
<jam> jml: well, I'm sure there is a default num threads.
<jam> But not having the file would be a misconfiguration for UDD
<jml> pha
<jam> jml: I can see your point, it is just a "how generic is this code" issue. It isn't super-duper useful for UDD
<jam> other than if we set a value and it doesn't take
<jam> a warning helps understand if we accidentally have the file owned as "root" for example
<Merwin_> Hey, I've got would like to make patch using diff of a revision range A..B but excluding the rev XXX, how can I do this ?
<Merwin_> I would like*
<mgz> I would... make a new branch -r B, merge -rXXX...(XXX-1), and diff -rA..
<Merwin_> Hum good idea, I'll try, thank you
<Merwin_> Erf, I tried to remove a colo-branch with bzr rmbranch and know my depo is unusable...
<Merwin_> I had no pushed commits...
<Merwin_> bzr: ERROR: No repository present: "file:///home/thibaut/OpenERP%206/OpenAssur/addons-opas/"
<Merwin_> Seriously, I lost everything ?
<mgz> hm, and I'm not sure the fix for bug 922953 has been landed on 2.5
<ubot5> Launchpad bug 922953 in Bazaar "rmbranch should refuse removing active branch" [Medium,Fix released] https://launchpad.net/bugs/922953
<Merwin_> I used bzr rmbranch mycolobranch
<Merwin_> How can I fix that mgz ? I had work I didn't pushed, is it lost ?
<mgz> welcome to the git way of working, I guess...
<mgz> am checking to see if pre-fix there was a way of recovering or not
<Merwin_> I don't understand why it removed my trunk branch wheras I told him to remove a colo branch Oo
<mgz> see also bug 920653
<ubot5> Launchpad bug 920653 in Bazaar ""bzr rmbranch" doesn't handle colocated branches" [Medium,Fix released] https://launchpad.net/bugs/920653
<Merwin_> ...
<Merwin_> Here, I don't even have a branch, brz branches prints nothing...
<mgz> I did recover from doing various daft things with colo, but don't recall which issue was which
<mgz> jelmer: any suggestions?
<Merwin_> or vila maybe ?
<Merwin_> Please tell me I'll be able to push my last 2 hours work I just commited before doing this :D
<mgz> there's always the filesystem recovery tool route
<Merwin_> At least it didn't removed the files...
<mgz> just the repo and branch metadata, not the tree, right?
<mgz> comma after repo.
<Merwin_> Yep I guess, I've got a .bzr dir and my files are still there
<Merwin_> So, I've got to call my boss est tell him why I can't push the things we were supposed to put in production tonight (I was making a patch for this)
<mgz> but no repository/ or branch/ inside, right?
<Merwin_> branch  branches  branch-format  branch-lock  checkout  README
<Merwin_> In .bzr
<mgz> Merwin_: so, you have your actual changes, so this isn't a complete disaster
<mgz> can either branch from previous location, copy tree across and commit for now
<mgz> or.. it was a fresh project? recreate and copy tree, add and commit
<Merwin_> I can't commit
<mgz> in that branch.
<mgz> you can make a new one.
<Merwin_> Hum
<mgz> which unblocks you for tonight.
<Merwin_> I try
<Merwin_> Don't seems to work: bzr branch actual_dir new_dir
<Merwin_> Same error: bzr: ERROR: No repository present: "file:///home/thibaut/OpenERP%206/OpenAssur/addons-opas/"
<mgz> Merwin_: so, did you create this from scratch 2 hours ago, or branch from an origin?
<Merwin_> Nope, it's a long time branch I used for weeks
<mgz> but you have no other version of the same base project anywhere?
<Merwin_> Yes, on our dev server
<Merwin_> Where I regulary push
<mgz> okay, so branch from that.
<Merwin_> But I won't have the last commit I made in my branch (the one I did't pushed yet)
<mgz> then copy in your changes from today, and do one big commit.
<Merwin_> Ok
<mgz> you lose any little commits you did along the way, but the changes are still there.
<mgz> and +affectsmetoo that bug I linked :)
<Merwin_> That's enought for tonight
<Merwin_> I did it thank you. It's a hudge repo, it's downloading I keep you informed :)
<mgz> :)
<Merwin_> mgz, while it's downloading, could you tell me how I'm supposed to remove a colo-branch ?
<mgz> that would be the way, it's just buggy in 2.5.0
<mgz> it should be roughly equivalent to removing the dir .bzr/branches/NAME though
<Merwin_> ok...
<mgz> not your fault, basically
<Merwin_> mgz, merge -r 552.1.1...X => What should I put at X?
<Merwin_> I want to undo the commit 552.1.1
<mgz> 552
<Merwin_> Looking at qlog, it seems that its 'ancestor' is 552.
<Merwin_> Ok
<mgz> it's easy in that case, .1 follows from the without-dot form always
<Merwin_> Hum, my patch contains binary files that I want to have
<Merwin_> It doesn't seems to handle binary files (OpenOffice .sxw, models for generating PDF)
<Merwin_> I'll have to add them manually ?
<mgz> you mean the textual patch only says "binary file added" but you want to be able to apply it and have the files added?
<Merwin_> Yes, exactly :)
<Merwin_> I don't have a lot I can push them via SFTP, it's not a problem, I'm just curious if there is a way to handle this
<mgz> you can just use a different diff format I think.
<mgrandi> hey jelmer if you are there, i remember you saying yesterday that you took out the fast export from x stuff from bzr-fastimport, does that include the bzr fast import (from svn dumpfile)?
<jelmer> mgrandi: bzr fast improt never supported importing from a svn dump file
<jelmer> mgrandi: bzr-svn supports importing from a dumpfile
<mgrandi> hmm, does that get called by bzr fast-import?
<jelmer> mgrandi: no, they're unrelated
<mgrandi> just trying to understand the structure a bit
<mgrandi> how did i import that svn dumpfile then
<jelmer> mgrandi: bzr-fastimport only deals with the fastimport/fastexport format used by git-fastexport
<jelmer> mgrandi: with bzr-svn I think? "bzr svn-import <dumpfile> <target>" ?
<mgrandi> yeah
<mgrandi> that seems like it, ok. I was going to say since import from dumpfile seemed important
<jelmer> mgrandi: it doesn't read the dumpfile directly
<jelmer> mgrandi: it creates a svn repo first from the dumpfile, and then uses that
<mgrandi> yeah
<mgrandi> i meant the general concept of importing from a dumpfile since svn doesn't seem to have fast-export
<mgrandi> at least i think
<jelmer> mgrandi: subvertpy has a 'subvertpy-fast-export' command that can generate a fast-export stream
<mgrandi> ah ok.
<mgrandi> also, before you dissapear again, i was wondering if there was anything to kinda 'verify' the integrity of a branch, or is it just bzr check
<jelmer> mgrandi: just 'bzr check'
<jelmer> mgrandi: generally, it's better to just talk to the svn repo directly rather than using a dumpfile
<mgrandi> yeah that makes sense. let svn worry about the dump file.
<mgrandi> but i was wondering cause im going to see if this bzr plugin for a IDE works, but it hasn't been updated in like a year so i have no idea if it still works
<jelmer> mgrandi: the svn dumpfile is a distraction, it just adds two extra steps to the process
<poolie_> hi all
<jelmer> 'morning poolie_
<LeoNerd> Can I somehow "bzr ignore" files in a directory that don't have an extension (i.e. a "." in their name). These will be compiled binaries, but I don't want to ignore e.g. the .c source for them
<mgrandi> should be able to with regular expressions
<mgrandi> which i believe bzr uses for bzrignore
<LeoNerd> Mhmm?
<mgrandi> bzr ignore "RE:^#"
<mgrandi> so to do a reg exp you put RE:
<mgrandi> you can also look at 'bzr help ignore' for some more examples, you can also tell it to nOT ignore .c files
<mgrandi> so, tell it to ignore everything in that directory, but not c files maybe?
<LeoNerd> Oooh that might work too
<bob2> or just ignore them all and add -f the source
<LeoNerd> Nah, 'cause I'd still like to be reminded about new files in case I forget :)
<wgz> LeoNerd: `bzr help ignore`
<mgrandi> so add "somedirectory/*", and then "!somedirectory/*.c"
<wgz> ...and I was scrolled up a little
<mgrandi> time to go, laterz
<wgz> can also do exactly "that don't have a dot in the name" with /[^.]*/
<LeoNerd> That got it :)
<LeoNerd> RE:examples/demo-[^.]+
#bzr 2012-04-04
<converge> hi, how can I get the last version of a branch? bzr pull ?
<poolie> converge, can you be  more specific?
<converge> i had downloaded it wih bzr branch name_of_branch
<converge> need to update it with the latest improvements
<poolie> then yes, bzr pull there will download new revisions from the parent branch
<poolie> and update the working tree
<converge> thanks dude
<lifeless> spiv: around ?
<spiv> lifeless: yep
<lifeless> I'm trying to clean up https://code.launchpad.net/~lifeless/+activereviews
<lifeless> https://code.launchpad.net/~spiv/ubuntu/lucid/paramiko/address-families-579530-lucid/+merge/25297 is in the way
<spiv> I guess I'll abandon it
<spiv> Although it's a bit of a pity that you can't shift that off your queue yourself.
<lifeless> spiv: so, I can't land it
<spiv> Me either :P
<spiv> Hmm
<lifeless> You could drive the SRU process for it, but thats not strictly a MP thing anyhow
<spiv> Neither "Work in progress" or "Merged" look like great alternatives, but those are my two choices
<spiv> (Setting WIP)
<lifeless> can you resubmit ?
<lifeless> you could retarted for lucid-proposed
<spiv> Oh, I can delete it or resubmit, I see.
<lifeless> our branch based workflow for ubuntu is very raw
<lifeless> there are appropriate bugs open
<spiv> Well, I'm not going to push this at all.
<lifeless> me neither
<lifeless> (which is a bit sad in principle, but a statement of reality)
<spiv> Yeah.  Our time is finite, sadly.
<lifeless> spiv: thanks
<vila> hi all
<Merwin_> Hi
<mgz> morning
<vila> mgz: heya
<m1sc> just to confirm: loggerhead doesn't support shared repos yet.?
<jelmer> m1sc: what is there to support?
<m1sc> jelmer: say loggerhead points to /repo with the following branches /repo/{trunk,branches/one,branches/two,..} inside, it doesn't show these branches.
<m1sc> jelmer: wrong expectation on my side?
<jelmer> m1sc: yeah, that's odd - it should be able to show them. and it works without a shared repo?
<jelmer> m1sc: a shared repo should just be a storage optimization
<m1sc> jelmer: hmm ok. it's --no-trees -- does it matter?
<jelmer> m1sc: no, that shouldn't matter as far as I know - loggerhead looks at the branch contents, not the tree
<ccxCZ> is there ready-made snippet for getting revno when I run program from a bzr repo and appending that to version number?
<jelmer> ccxCZ: not that I'm aware of - see bug 689367
<ubot5> Launchpad bug 689367 in Bazaar ""bzr describe" command" [Wishlist,Confirmed] https://launchpad.net/bugs/689367
<ccxCZ> hmm I guess Branch.open(dirname(dirname(__file__)).revno() will do
<jelmer> ccxCZ: `bzr revno` will just get you the revision number, if that's what you mean?
<ccxCZ> well, I want it from python app, so spawning another process seems bit overkill
<m1sc> jelmer: ok, solved -- had a guard branch in /repo/.bzr, once removed it seems to work. thank you.
<jelmer> ccxCZ: in that case your code is indeed what you want
<LarstiQ> ccxCZ: though perhaps you want Branch.open_containing instead of dirname(dirname(?
<maxb> There is a danger in using open_containing if the code might sometimes run in an exported copy of the code - it may recurse far above where you wanted in that instance
<LarstiQ> maxb: right
<Merwin_> mgz, hi, you saved my (yester)day, thank you ;)
<Merwin_> I update to bzr 2.6b1 to avoid these problems :D
<mgz> I'm glad Merwin :)
<mgz> I'll also make sure those fixes are back ported for 2.5.1
<Merwin_> I installed latest 2.6 with pip and I had a message saying that it could not compiel some extensions (whereas I installed Cython, and saw some gcc lignes during installation)
<Merwin_> It works fine, but if it could work faster, that would be nice ;)
<mgz> hm, yes, the setuptoolsy installs may not do the right compile stuff
<Merwin_> I'll remove it and install from sources
<Merwin_> mgz, bzrtools 2.5 works with 2.6 or I'll have to get the dev branch ?
<mgz> it should work.
<james_w> jml,  https://code.launchpad.net/~james-w/udd/remove-max-threads-warning/+merge/100816
<jml> james_w: I think there's more in that diff than you intended.
<james_w> ah, looks like I missed pushing to trunk yesterday
<james_w> jml, fixed
<jml> james_w: thanks.
<james_w> that also means I didn't roll out the new code as intended yesterday
<james_w> doing that now
<jml> james_w: approved.
<james_w> thanks
<mgz> james_w: do you want anything else from me on the udd mp reviews?
<james_w> mgz, not at this time, thanks for the reviews
<james_w> jml, mgz: around still? https://code.launchpad.net/~james-w/udd/storm-fixes/+merge/100838
<jml> james_w: already approved :)
<mgz> ...he's too fast!
<james_w> oh yay
<james_w> thanks
<james_w> one more coming up
<james_w> larger and without explicit tests unfortunately
<jml> james_w: classy.
<mgz> james_w: do we need to do something about storm on jubany still?
<james_w> mgz, I had the package installed
<mgz> you're a star.
<james_w> these fixes are from my finding some problems when trying to deploy the code
<james_w> https://code.launchpad.net/~james-w/udd/unicode-everything/+merge/100842
<james_w> diff is generating now
<mgz> eheh, winning branch name
<james_w> oh, I forgot the pre-req
<jml> james_w: I think you missed one:
<jml>     except errors.NotBranchError:
<jml> -        ubuntu_b = bstore.get_branch_parts("ubuntu", ubuntu_current_series,
<jml> +        ubuntu_b = bstore.get_branch_parts(u"ubuntu", ubuntu_current_series,
<jml>                 "release", possible_transports=possible_transports)
<jml> "release" â u"release"
<james_w> argh
<james_w> thanks
<james_w> jml, mgz: thanks, I'll land these and try a rollout
<jml> \o/
<jml> james_w: I'll be semi-around
<james_w> ok
 * jml is packing for a move tomorrow.
<james_w> jml, it all looks to be running ok so far
<james_w> adding new jobs
<james_w> importing packages
<james_w> updating the status page
<jml> james_w: great :)
<james_w> I'll go and grab some lunch and check it all again when I get back
<jml> cool
<mgrandi> jelmer, i dont see the difference between the 'fastimport' download and the 'pythonfastimport' download on the python-fastimport launchpad page, did you make a mistake there or something? :o
<poolie> lifeless, hi, can we chat briefly?
<lifeless> sure thing
<lifeless> ring me ?
<poolie> sure
<jelmer> 'evening poolie, lifeless
<jelmer> mgrandi: there is none
<jelmer> mgrandi: pip falls over if the tarball has a name that doesn't match the module name, even if that's what is registered on pypi
<mgrandi> oh
<mgrandi> ok
<poolie> hi there
<lifeless> hi jelmer
#bzr 2012-04-05
<poolie> spiv, hi?
<mgz> morning all!
<Merwin_> hi mgz :)
<mgz> to get a log of the whole of a history branch given a dotted revno from within it,
<mgz> is there anything smarter than:
<mgz> `bzr log --forward -l1 -r191.1.5..`
<mgz> then seeing what the revno of that is in the parent branch and doing:
<mgz> `bzr log -n0 -c198`
<ribe> I have checkout main project branch, but how do I create development branch on my localhost?
<mgz> ribe: not really sure what you want, but just `bzr branch exisiting_main new_devel`?
<vila> mgz: bzr log -n0 -cmainline:191.1.5 ?
<mgz> vila: thanks!
<jonathanj> hi, i have a stange problem with locations.conf that has only recently (and suddenly) started happening
<jonathanj> for some reason bzr is not matching stanzas in locations.conf that is has been matching for years
<jonathanj> i'm using bzr 2.6b1 on OS X 10.7.3
<jonathanj> is there some way to debug the matching?
<jonathanj> my branch is at /Users/jonathan/Coding/Project/branches/123-branch, i have a /Users/jonathan/Coding/Project/branches stanza
<jonathanj> if i remove path elements until a location stanza starts appearing in "bzr config" i end up with /Users/jonathan/Coding, which seems bizarre (hah!)
<jonathanj> as far as i can tell there is nothing (nor has there ever been) anything special about the Coding directory
<jelmer> jonathanj: this code has been changed recently, so I suspect it's a regression
<jelmer> jonathanj: can you file a bug?
<jonathanj> jelmer: after a whole lot more messing around it seems that somehow os.getcwd was reporting "Coding" as "coding" (while Finder, pwd, ls, etc, reported it as "Coding"), moving it to foo and back to Coding appears to have resolved all my issues
<jonathanj> although on OS X "coding" and "Coding" are actually the same path, so maybe i should file a bug about that
<huggie> So I committed, pushed but it was wrong.  I'd like to undo that.  I found uncommit and revert and now I'm back where I should be but I can't push.  I tried an empty commit and now I've diverged.  Um, help? ;)
<jelmer> huggie: you can discard the remote history using "bzr push --overwrite"
<huggie> Aha.
<huggie> Woo.  After a little time launchpad updated too.
<huggie> jelmer: Thanks, that was perfect :)
 * mgz blames jml here instead
<mgz> skip on twisted and unittest should not use incompatible exception classes
<jml> backwards compatibilit
<mgz> is it actually impossible to skip a test in such a way as it'll not count as a fail on one of trial or unittest -m?
<james_w> https://code.launchpad.net/~james-w/udd/packages-last-update/+merge/101009
<ribe> When I do MERGE/ POOL main branch to my branch msg is 'there is nothing to do', but right after that if I do merge my branch into main there is changes to commit. How is that possible?
<ribe> I'm truing to revert some changes btw, and can't update my branch to current version of main branch...
<ribe> How to revert my branch to privies version and the do update/pull the current version of the main branch?
<jelmer> ribe: 'bzr pull --overwrite <main-branch-url>' ?
<ribe> jelmer: that may help, just that I using Bzr explorer...need to check out how to do that in terminal...
#bzr 2012-04-06
<ggherdov> hi all. i know i know bzr ain't SVN but: can I merge *only* folder FOO in branch BAR with the whole branch BOO ?
<pikkachu> anyone ever used bazaar from linux to operate on a ntfs-3g mount point?
<pikkachu> bazaar does not work (diff and status) when I use hide_hid_files
<pikkachu> this option should hide hidden files from listings but not from accessing
#bzr 2012-04-07
<bob2> sounds like a terrible idea
<sudarshans> is there any place where I can get a few tech specs of bazaar's repo format?
<sudarshans> as in some idea of what system is used to store files (packs like git, or deltas or ...?)
<sudarshans> looked around a bit, couldn't find any relevant info
<sudarshans> basically do renames consume significant space?
<sudarshans> and do similar files get automatically grouped together
<sudarshans> so as to use deltas between them?
<sudarshans> well?
<sudarshans> lifeless: ^
<sudarshans> https://answers.launchpad.net/bzr/+question/192935
<sudarshans> hope that is the right place
<sudarshans> good bye!
#bzr 2012-04-08
<Pegasus_RPG> Hello. We have frequent complaints that Bazaar is slower by far than any other VCS. We use Launchpad to store our branches. Did we do something wrong with the storage format? lp:mixxx
 * Pegasus_RPG doesn't know because he's only ever used svn
<Noldorin> hello jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, i see you fixed my dpush issue :-D
<jelmer> huh?
<Noldorin> jelmer, i got a notification about it
<Noldorin> saying "triaged"
<Noldorin> is that not fixed? :-(
<Noldorin> i mean, it was "in progress" before it seems...
<jelmer> Noldorin: that basically means it's confirmed that it's a bug, but there's no work going on
<Noldorin> oh :-(
<Noldorin> i misunderstood
<Noldorin> heh
<Noldorin> at least priority has gone up to "high" though hah
<jelmer> Noldorin: I unassigned a bunch of bzr-git bugs from myself because I haven't really gotten to them
<Noldorin> ah
<Noldorin> it turns out i didn't move to Hg yet anyway
<Noldorin> just not enough demand for the Git mirror
<Noldorin> (yet)
<Noldorin> so safe for now
<Noldorin> oh well
<lifeless> maxb: the list is a better way to coordinate things
<maxb> mm, possibly. "Contact team" does have the upside of reaching precisely the set of affected people, though
#bzr 2013-04-02
<jazon> Hello everybody, I have a problem with bazaar, I search on Google but I don't find anything can help me. Pastebin for message : http://pastebin.com/hbTVM9Ps (and sorry for my bad english, I'm french user)
<jazon> If someone can help me, I don't understand what happened...
<mgz> jazon: looks like bug 951276
<ubot5> bug 951276 in Bazaar "bzr crashed with MalformedTransform in resolve_conflicts(): Tree transform is malformed [('versioning no contents', 'new-119')]" [High,Confirmed] https://launchpad.net/bugs/951276
<jazon> thanks I look.
<mgz> jazon: as a workaround, you can probably *branch* from that revision afresh, even if the update hits that bug
<mgz> so, `bzr branch . ../newtrunk`
<mgz> from inside the branch with that issue
<jazon> thanks mgz
<jazon> someone know what is the good way to "uninit" branch but without remove files?
<jelmer> jazon: just 'rm -rf .bzr' you mean?
#bzr 2013-04-03
<Saviq> hi, is it possible to set a default stacking branch for branches under a directory?
<Saviq> i.e. we have lp:unity/phablet and pushing without explicit --stacked-on ... tries to stack on top of lp:unity
<Saviq> but the two don't have any common history
<Saviq> so we're pushing the whole thing every time
<Saviq> any pointers on how to improve that?
<mgz> actually create seperate projects fro seperate projects?
<mgz> launchpad stacking is special cased for how launchpad wants you to lay things out
<mgz> it expects code under one project to share history
<kate`> hiya. i'm trying to convert something from svn to bzr, and confusing myself an awful lot in the process
<mgz> hey
<mgz> you might get a good response if you post the details of the conversion on the bazaar mailing list
<kate`> way back when, i had three seperate svn repositories. at some point i combined all these into one (by dumping them and 'svnadmin load'ing them into different subdirectories) - and then i continued development from that point onwards, in one single repository
<mgz> the people who've dived in those waters should see it there
<kate`> well, maybe :)
 * fullermd read that as "died in those waters"...
<kate`> i'm wondering how's the best way to represent this in bzr.. clearly i could just convert the repository as-is, but i want those histories to appear in paralle, as they're unrelated until that point where they combine
<kate`> i.e. i don't want a linear history with the work on those three things interspersed
<mgz> that sound doable, but potentially not simply
<kate`> what options can i consider? i could use svn's dump filter things to split those apart again
<kate`> i thought either i can leave this as one giant repository and try to have bzr svn-import understand that merging, or: i could convert them seperate, merge in bzr, and then somehow svn-import the rest of the work after the merge
<fullermd> That last step would be the really tricksy part.
<kate`> yeah
<kate`> can svn-import import after existing commits?
<kate`> or: are there any other ways to go about this? i'm not really sure how this history *should* look
<kate`> i assume these three origional svn repos should become branches in bzr
 * jelmer waves
<jelmer> kate`: svn-import can import after existing commits, but it won't recognize merges that were not made with bzr
<kate`> ok. so does my plan to seperate back out my svn repository into three before-the-merge and one after-the-merge sound sane, with doing that merge by hand in bzr?
<kate`> i.e. to svn-import them to three seperate bzr repositories, rather than branches within one repository or something
<jelmer> kate`: I don't think that will work, if the three different branches don't have shared history
<jelmer> (shared history where svn/bzr is concerned, that is)
#bzr 2013-04-04
<kate`> can i bzr merge multiple things simultaneously, or must i merge one, commit, and then merge the next?
<fullermd_> kate`: You _can_.  Rarely a good reason for it though, IMO.
<kate`> fullermd_, in this case i started development with three independent repositories, in parallel. they're all of equal status; i want to move them all to the same repository (and discard their origional repositories)
<kate`> so i thought it'd make sense to merge them all simultaneously if i can, because there's no reason i'd order one over the other two
<kate`> they all contain independent files, too. no paths in common
<kate`> ah. i see --force mentioned in 'help merge'
<kate`> what an ominous name
<fullermd_> It used to be called --brute-force, but we decided to reserve that for the rumored "every-which-way" merge.
<kate`> it's really "even though i have uncommitted changes", isn't it?
<fullermd_> Just so.
<spiv> It's not a great option name, but it's familiar from some other tools like dpkg.
<spiv> Or even coreutils like rm, I suppose.
<kate`> personally i'm terrible at naming things
<kate`> i had a desktop with the hostname "what" at one company :/
<kate`> "can i get to what?"
<kate`> imagine the confusion
<spiv> "You want me to connect to what?"
<spiv> I can imagine :)
<kate`> "what's down" <- this never happened, but i wanted it to :)
<spiv> There's always "what's up"
<kate`> "nothing!" OH MY GOD PANIC
<fullermd_> No, who's up.  What's in a second.
<kate`> i've 20 or so svn repositories i'm converting to bzr. some of them have (or rather would have, if svn could express it) pretty complex histories
<kate`> so i'm converting them by cutting them apart, and splicing them back together with manually-inserted branches and merges and things, which is what i would have done at the time, but couldn't
<kate`> that way i'll have a history which actually shows what i was intending, rather than just one linear changelog with unrelated things interspersed
<kate`> it's very tedious doing this, but it'll make me a happy bunny
<kate`> for a few i reorganised the top-level layout occasionally, and (as in the case i just mentioned with the three seperate repositories being joined), various other things automated tools don't understand
<kate`> ok. so i'm confused. if i have a repository which contains /a, and another which contains /b, i would expect that i can merge both to a checkout of another copy (which itself has neither /a nor /b)
<kate`> but issuing those two seperate merges, i'm told i have conflicts for paths under /a, when i merge in b's repository
<kate`> how can that be?
<kate`> if i checkout b's repository and look through the log, it only contains stuff under /b
<LarstiQ> kate`: might conflict on the root, that is, / being in a different location?
<kate`> hm. i don't understand that; how can / be in a different location?
<spiv> kate`: like any other file/dir, it is possible to rename, and bzr will track that.  Not sure that'
<spiv> s the case here though; if you're able to pastebin a couple of lines of the conflict details it might help diagnose.
<kate`> let me see if i can do that in an understandable manner...
<kate`> http://codepad.org/v6n152NN
<kate`> lx.bzr contains /lx and all commits are under that path. -r2 is just mkdir for /lx
<kate`> main.bzr has never had /lx at any point in its history
<kate`> i don't understand what these conflict messages are telling me
<kate`> lx.bzr was also created by svn-import
<kate`> although with --layout=none, unlike main.bzr
<kate`> huh. the range for -rx..y is inclusive, right?
<kate`> geez. if i make that -r0..4 then "All changes applied successfully.". but 0 is an empty commit!
<fullermd_> 0..X is what you want for bringing together unrelated histories, since you want to merge everything from nothing to now.
<kate`> well r0 looks to be a completely empty commit, i think as a side effect of the filtering i did with svn... so i was trying to elide that
<fullermd_> No, that's expected.  Your first commit is r1, so r0 is The Void.
<kate`> aha, okay
<fullermd_> Remember that revisions are _states_, not _changes_.  So asking for "merge -r0..1" means "merge the change from state 0 (nothing) to state 1 (first commit).
<kate`> that makes sense
<fullermd_> So 0..4 is "everything from start to rev4"
<fullermd_> Ditto for "diff -r0..1" etc.
<fullermd_> We all kinda fudge things when it comes to 'log' of course, since in your log for rev X you're really describing the change from (X-1) to X rather than the state X which is what you're actually recording, but...
<fullermd_> At least, everyone I've ever known does.  Otherwise, by rev 1000 or so your log message is gonna be _really_ long  ;>
<kate`> you know, if there's one thing i consistently get wrong with programing - in any language - it's off-by-one errors when i'm thinking about sets of items, iterating through them, and what i consider an item or the distance between items
<kate`> (i'm not talking about 0-indexed versus 1-indexed arrays)
<fullermd_> Everybody does  :)
<kate`> like for example if i'm implementing binary search, and i need to consider the middle element of a range. i find that sort of thing super difficult
<fullermd_> That's why you write scripts to help you debug, that just load up your program and add a "-1" to a random line to see if it helps.
<kate`> do you do that? i tend to assert everything is in the range i expect it to be
<fullermd_> Or just stick random values in $[
<fullermd_> But that really annoys people.
<fullermd_> Not really.  But I've thought about it.  Mostly avoided it because I was afraid it would sooner or later _work_, and that would just drive me insane.
<kate`> i prefer some sort of illusion of a scientific approach...
<kate`> okay. here's the origional conflict problem i mentioned, which is confusing me still: http://codepad.org/cT2Rffdt
<fullermd_> That's why I imagine that the gnomes that sneak in during the night and break my code are wearing labcoats.
<kate`> there you can see i merge in libre.bzr, commit it, and merge in lx.bzr
<kate`> libre.bzr only contains paths starting with /libre in its history, and lx.bzr only contains paths starting /lx
<fullermd_> lx.br sure looks like it's touching all kinda of stuff in libre.
<kate`> yeah, it does. but it's not!
<fullermd_> The mods in the files suggest bzr thinks they're related files.  The path conflict suggests an unrelated file with the same name.
 * kate` increases in confusion
<fullermd_> My work here is done   8-}
<kate`> can i show you a screenshot?
<kate`> this is really silly
<fullermd_> What's the provenance of the xyz.bzr's; are those from a svn conversion too?
<kate`> they are, yes
<kate`> they come from the same repository, actually. but svndumpfiltered to just include that path
<fullermd_> So, there's apparently only 4 revs in lx.bzr (at least, only 4 you care about here), so I'd start looking there.
<kate`> oh so i bet the repository's UUID is carried over...
<fullermd_> UUID won't matter to bzr (in this meaning anyway)
<fullermd_> The important thing to bzr will be the revs themselves, and since you're forcing the range from 0 that's probably not at the forefront.  What will be is fileids.
<kate`> this is the log for lx.bzr, which i just checked out so i can 'bzr explore' it: http://dioptre.org/tmp/lx-bzr.png
<fullermd_> But, start with revs, just to be sure.  See what, if any, is common between libre and lx
<kate`> revision '1' there is the empty revision i mentioned. no message, and no tree
<kate`> so i think i want to merge from -r1:4 (i don't want revisions 5 onwards)
<fullermd_> (e.g., "cd libre.bzr ; bzr missing /where/ever/lx.bzr")
<kate`> hm ok
<fullermd_> If bzr really thinks they're unrelated (which I wouldn't unsuspect, but might as well be sure) both lists will start from rev 1 onward.
<fullermd_> And if that's the case, you've probably got fileids lining up somewhere you don't expect.
<kate`> is a fileid a hash?
<fullermd_> No, pseudorandom uuid.
<kate`> hmmm
<fullermd_> But the svn conversion complicates (or simplifies) things in that it'll try to take hints from svn about what files may be the same.
<fullermd_> Which means a heuristic, which is such a nice polysyllabic word for "wrong".
<fullermd_> Anyway.
<fullermd_> Looking at something like "log -v --show-ids -r0..4" for lx might give some hints, as may poking around 'ls --show-ids' in the current of libre.
<fullermd_> It seems at a glance the fruitful course would be poking around those two and ignoring trunk (though that could be wrong, and it could be a trunk/lx conflict, but it _seems_ like libre/lx)
<kate`> should these two suspiciously hashy looking numbers be identical? http://codepad.org/YPWcS047
<kate`> that's the UUID from my svn dump
<fullermd_> That could be the way bzr-svn synthesizes fileids on import.
<fullermd_> Once in bzr-land, it's not a svn rev or uuid or path anymore though, it's just an opaque string.
<fullermd_> So those two are different.
<kate`> hm. so the :%2Flx at the end is part of the string?
<fullermd_> But look for that lx'd id across all the revs in lx.
<fullermd_> Yes.
<fullermd_> bzr's standard generation ends up looking something like "basename-datestamp-randombits".  The svn conversion looks like rev@uuid:path.  But either way, it's functionally opaque; just a pile of bytes to identify it.
<kate`> ok, cool. so all the fileids for 'bzr log -v --show-ids -r1..4' for lx.bzr are dinstinct from libre.bzr's fileids
<kate`> now i'm wondering about revision-ids
<kate`> ...and the revision-ids are of the form svn-v4:UUID:rev where rev is the svn revision
<kate`> so... both lx.bzr and libre.bzr contain the same revision-ids. i think these should be distinct, right?
<fullermd_> That seems odd.  the lx merge is modifying libre/src/Makefile and libre/src/cli/main.c etc, so it apparently has some file that matches that file-id.
<fullermd_> Well, they are; if they weren't, there'd be nothing to merge.
<kate`> right. i think merge is confused because the revision-id for the incoming lx changeset is the same as the revision-id as one of libre.bzr's changesets
<kate`> so the conflict is mistakenly looking at the wrong one...
<kate`> i think
<fullermd_> That wouldn't be confusing, that would be "nothing to do".
<kate`> hm
<fullermd_> Check the missing output; if the revid's are the same, those revs wouldn't be in it.
<kate`> well i'm just looking at log --show-ids, and i can see revision-id there
<kate`> okay. well my best hypothesis so far is that the UUID being the same is causing some problem *somehow*, and i can test that easily enough by substuting different UUIDs for each of my dumps
 * kate` does so
<fullermd_> If you've got two revs that really have the same revid, and different contents, then you've got corrupted data.
<kate`> revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::2
<kate`> revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::1
<kate`> that's how they look
<kate`> (for both lx.bzr and libre.bzr)
<fullermd_> If you made two different svn dumps with the same uuid and different contents, that would be one way to get things all squirreled up.
<kate`> right. that's what i've done
 * kate` unsquirrels them
<fullermd_> (it is of course Obviously(tm) a bug that bzr would do something as foolish as trust svn, but there ya go...)
<kate`> i think a --ignore-uuids option to svn-import wouldn't go amiss
<kate`> the use-case is for when somebody has filtered a single svn dump into several distinct streams, and wishes to import each of those
<kate`> HAH!
<kate`> it works :D
<kate`> i modified the UUIDs in each of the streams i use to create lx.bzr and libre.lx, so that they're distinct
 * fullermd_ takes the credit.
 * kate` beams
 * mgz ducks
<mgz> careful with those beams!
<kate`> ducks are probably more harmful
<fullermd_> Hey, worry about your own mote before concerning yourself with... wait...
<kate`> ok. so now i'm 'svn-import'ing another dump which i'd like to continue linearly in my bzr repository's history, just as if i commit things by hand
<kate`> i think i checked before, but i'm still not sure. can i svn-import into a repository which already has some commits?
<kate`> do my svn revision numbers matter?
<jelmer> kate`: just reading up on backlog...
<jelmer> if you modified the UUID in a svn repository to have the same UUID as another svn repository that doesn't have the exact same contents, you're very likely to break bzr-svn (if not now, then you'll hit bumps at some point in the future)
<jelmer> kate`: svn-import can importing into a repository that already has commits
<jelmer> kate`: do svn revision numbers matter for what specifically?
<kate`> jelmer, this is a one-way conversion of an svn repository which i want to be store henceforth canonically in bzr - so i think the UUID doesn't matter
<kate`> ok. well svn-import of a svn dump which has changesets that mv around a few files (these files are already present in my bzr repository): bzr: ERROR: subvertpy.SubversionException: ('Relative source revision -1 is not available in current repository', 160006)
<jelmer> kate`: the UUID does matter - bzr-svn will assume that two svn repositories with the same UUID have the same contents
<jelmer> kate`: and it relies on this; the error you just saw is very likely caused by modification of the repository UUID
<kate`> right. i modified my UUIDs to make them distinct
<jelmer> ah, if you made them distinct it shouldn't be an issue..
<kate`> hm. so i want that new incoming dump to have the same UUID as my bzr repository, perhaps
<kate`> possibly maybe
<kate`> hm no. the UUID doesn't seem to relate to that Relative source revision -1 error
<kate`> i think that might be due to my dump referring to a previous revision which is not present, because i filtered it out
 * kate` investigates
<kate`> ah. i bet it's the Node-copyfrom-rev: references
<kate`> i could just recreate these particular commits by hand, i suppose
<jelmer> kate`: you also might want to import this into a svn repository rather than calling bzr svn-import on it directly
<kate`> hm. and then how would i get those commits to my bzr repository?
<jelmer> kate`: bzr svn-import works on svn repositories fine too
<jelmer> kate`: in fact, if you give it a svn dumpfile, it will create a svn repository first, and then import from that svn repository
<kate`> ok. but as far as i can see that would import from the very first revision --until something, right?
<jelmer> kate`: yes, but it will skip any revisions already present in the bzr repository
<jelmer> kate`: the behaviour (and code paths involved) are exactly the same as with a svn dump file
<kate`> ooh. that's the bit i didn't know :)
<kate`> the skipping part, that is
#bzr 2013-04-05
<inductiveload> hi! i'm looking to rebase a branch of a repo onto the current head, but i'm not sure how to go about it. the branch is question is here: https://code.launchpad.net/~inductiveload/lubuntu-artwork/lubuntu-artwork
<inductiveload> all i have on this machine is a checkout of that branch, though
<rihnapstor> how to check bzr version ?
<Peng> rihnapstor: "bzr version"
<jelmer> inductiveload: rebase doesn't work very well in checkouts, so you may want to unbind it first
<mgz> or just merge in trunk
<jelmer> inductiveload: after that, just "bzr rebase /path/or/url/to/upstream/branch" should do the trick
<jelmer> merge is usually a better idea, indeed :)
<jelmer> mgz!
<mgz> jelmer!
<inductiveload> hmm, ok, i did a merge already (to an older head), so I can do that again
<mgz> are you settled yet jelmer, or still a-roving?
<Kakadu> hey
<Kakadu> if i have a repo which is on the revision 5. Than I execute `bzr update` and there are some changes. How can I checkout *last* revision?
<Kakadu> (It is automatization script so executing `bzr log` and looking for the latest number is not mine variant)
<Kakadu> (I can parse log output but I want something more simple)
<mgz> update does update the tree
<Kakadu> I thought about that but it seems that `update` doen't. `bzr revert -rN` prints changes when switching revision and does not if N is the same revision. So I do `revert -r5` than `update` and than `revert -r5`. Nothing is printed. So, it seems that `bzr update` does not change revision number.
<mgz> what's you actual setup? just a standalone branch? lightweight checkout?
<Kakadu> I executed `bzr branch lp:ubuntu/ocaml-syck` and so some experiments
<Kakadu> s/so /do /
<mgz> you probably just don't want to use revert
<mgz> that changes the tree contents, but doesn't change the revision
<mgz> eg, instead, do `bzr branch -r5 lp:ubuntu/ocaml-syck` then cd in and do update - the right thing happens
<Kakadu> I want to simulate situation when `bzr update` have added added information about some new commits
<mgz> or, `bzr pull` rather there
<mgz> update is for checkouts really
<Kakadu> Got it!
<Kakadu> mgz: many thanks
<LarstiQ> mgz: my offer on providing you with some snow still stands, btw ;)
<mgz> ha! sun today
<mgz> we did get some snow falling this week, but it hasn't stuck
#bzr 2013-04-06
<macobo> Hi, sorry for the silly question, but I have been fighting bzr for a while now and searching seems to be yielding no results.
<macobo> I branched a repo, made a few commits and pushed to my own branch on launchpad. Now, how do I reset the working tree to the state it was before my commits (ignoring files that are in the .gitignore equivelent of bzr)
<LarstiQ> macobo: I think you want `bzr revert`
<LarstiQ> macobo: or less likely, `bzr update`
<LarstiQ> macobo: why do you want to reset the state? Or, what is it that you are trying to accomplish?
<macobo> bugfix, push it to my own branch and reset to the state the state the trunk is in (for another bugfix)
<macobo> After bzr revert, bzr log showed the same commits I made a little while ago and new commits had the last one as parent.
<macobo> At the end I just undid all the commits and destroyed the changes (they still live on on the lp)
<LarstiQ> macobo: right, bzr revert is for working tree content
<LarstiQ> macobo: so, there are several things you could do
<LarstiQ> macobo: imo the most natural thing to do is to switch to a different branch
<LarstiQ> macobo: but you could also force your local branch to be the same as on lp, by doing `bzr pull parent: --overwrite`
<macobo> I will look into the first one, looks sane. :) Thank you.
#bzr 2013-04-07
<Kakadu> Hey. I continue writing script for package system and now I want to do this thing
<Kakadu> Let I'm on revision 5. If I execute `bzr pull` than I will be automatically switched to revision N. Are there any way to rint changed files between this two revisions?
<Kakadu> print*
<Kakadu> N.B. I don't know concrete numbers of revisions. It will be great if magic option for pull exists.
<LarstiQ> Kakadu: -v, so `bzr pull -v`
<Kakadu> LarstiQ: And how should I grab in my script changed files after that?
<LarstiQ> Kakadu: ehm, what is your script trying to do?
<Kakadu> I want to check updates from remote repo and print changed files (if they exists)
<Kakadu> for example `git diff ` have `--name-only` option
<LarstiQ> Kakadu: aha
<LarstiQ> Kakadu: so why not use `bzr status -r old..new` then?
<Kakadu> to use it my script should know these two numbers. Can I easily get them or should I parse `bzr log`?
<LarstiQ> Kakadu: `bzr revno` before and after the pull for example
<Kakadu> LarstiQ: great!
<fullermd> May not be reliable depending on your workflow; may want to grab the revids instead.
<lifeless> should be fine as long as you set the option to prevent mainline revno pivots
#bzr 2014-04-01
<Foad_NH> Hi, I have this problem:
<Foad_NH> bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' [Errno -2] Name or service not known
<Foad_NH> fixed! sorry
#bzr 2014-04-02
<domas> Hi, how one should install bzr as a library dependency? Adding 'bzr' to setup.py will try to look up bazaar-vcs page and fail - http://pastebin.mozilla.org/4746002
<hazmat> hi folks i'm trying to get bzr + git to work with git https urls.. latest git plugin (tip), latest dulwich (tip) and bzr 2.6..
<hazmat> i get an error about a non existant store method.. store.get_graph_walker()
<hazmat> not clear if that's an old deprecated thing or not..
<hazmat> i had to modify the git plugin remote to support the additional transport url
<hazmat> full traceback http://paste.ubuntu.com/7195053/
<hazmat> jelmer, ^ any suggestions would be appreciated
<zyga> hazmat: hey, I never got any luck with git + bzr other than what I did with git-lp
<LeoNerd> It's a known bug
<LeoNerd> Quick solution is to rollback to an older dulwich
<jelmer> hazmat: what LeonErd says
<hazmat> LeoNerd, jelmer thanks
<hazmat> any particular version that is best?
<jelmer> the latest that doesn't have the get_graph_walker changes
<jelmer> 0.9.0 probably?
<hazmat> looks like 0.9.3
#bzr 2014-04-03
<mgrandi> hey jelmer, you here?
<jelmer> mgrandi: hi
<mgrandi> I know you really don't work on the bzr-git plugin much anymore, but im hitting an exception and its baffling me, cause its a result of the bzr-git code calling a method that doesn't exist, and it hasn't been in there for ..at least a year
<mgrandi> bzr-git/fetch.py line 705 calls 'get_graph_walker' on a object BazaarObjectStore
<mgrandi> yet bazaar object store doesn't have such a method, and going back in the log i can't find it ever being added or removed
<jelmer> mgrandi: yeah, that's because of changes in dulwich
<jelmer> mgrandi: using an older version of dulwich (0.9.2 apparently) should work around it for now
<mgrandi> its a dulwich thing? but the object-store.py file is in the bzr-git codebase not dulwich
<jelmer> mgrandi: it's a Dulwich interface
<jelmer> Dulwich changed where this method is located, and bzr-git hasn't been updated
<mgrandi> ah.
<mgrandi> It apparently still works, but it just throws an exception, haha.
<jelmer> I'd be surprised if it still worked..
<mgrandi> it pushed to github fine
<mgrandi> I was on this tangent because dulwich is using the git ssh.exe, and for some reason git's copy of ssh.exe NEVER works
<mgrandi> for anything other then git
<mgrandi> and i was trying to figure out how to make it use plink.exe
<jelmer> mgrandi: it might have pushed fine but failed to update the local bzr branch?
<mgrandi> thats probably what was happning
<mgrandi> annnnnd windows doesn't have stdint.h
<fullermd> Has inttypes.h, maybe?
<mgrandi> its cause microsoft doesn't support c99 apparently
<mgrandi> but jelmer, i downgraded dulwich but its still failing cause the bzr-git code is trying to call that method, is it supposed be using a dulwich copy of BazaarObjectStore or something?
<jelmer> mgrandi: you might have to go back even further (to dulwich 0.9.0 perhaps?)
<mgrandi> well, its just that its importing BazaarObjectStore from bzrlib.plugins.git.object_store
<mgrandi> so im confused on how downgrading only dulwich fixes this
<jelmer> dulwich doesn't import anything from bzr-git
<mgrandi> im talking about the bzr-git plugin
<jelmer> mgrandi: the interfaces bzr-git and dulwich use are out of sync now
<jelmer> mgrandi: there are two options for working around this:
<jelmer> 1) update dulwich to a version from before the interface change
<jelmer> 2) update bzr-git to use the new interface
<mgrandi> yeah, i did #1, but it seems that the problem isn't in dulwich at all, its a object defined in bzr-git
<jelmer> mgrandi: can you paste the backtrace?
<mgrandi> http://paste.pound-python.org/show/QdpZG9BKVyj4kXlNdC5m/
<jelmer> mgrandi: yes, that's caused by a change in Dulwich
<jelmer> BazaarObjectStore derives from ObjectStore (which is a Dulwich object)
<jelmer> and ObjectStore no longer provides that method
<mgrandi> Ok. there is my confusion
<mgrandi> I will look into it, thanks =)
#bzr 2014-04-04
<mgrandi> do you have any hints on how to update the interface jelmer? I see that the object BaseRepo now has get_graph_walker(), but i don't see anything in the InterRemoteGitNonGitRepository that inherits from that object to get the walker
<jelmer> mgrandi: sorry, not off the top of my head. It's been way too long since I've looked at that code in bzr-git
<jelmer> IIRC that method moved from Repo to ObjectStore
<jelmer> or the other way 'round
<mgrandi> the other way around
<mgrandi> i'll look at it, thanks anyway =)
<jelmer> mgrandi: bzr-git is in dire need of a new maintainer, if you feel so inclined (-:
<mgrandi> haha
<mgrandi> i dunno if id be the best fit, but ill what happens =P
#bzr 2014-04-06
<asido> is bzr a distributed scm?
<Peng> yes
<fullermd> (depending on where you stand on the scm-vs-vcs semantic argument, anyway)
<Peng> there's a semantic argument?
<fullermd> Hey!  Stop poking, and put down that stick!   :p
<Peng> Should I put the petrol back, too?
<fullermd> There are people for whom the terms mean very different things, and boy will they get steamed when they ask a scm question and you try and give a vcs answer...
<Peng> I did not know.
<Peng> I always use "VCS".
<fullermd> Aegis tends more toward the scm side, for examples (at least in most uses of the terms distinctively.  There's not even universal agreement among the nutcases as to what flavor the nuts should have ;)
#bzr 2015-04-05
<veddox> Hi everyone, I was just wondering if I can find the archive of the Bazaar mailing list anywhere online? Googling didn't turn it up...
<fullermd> First hit on google for "bazaar mailing list": https://lists.ubuntu.com/mailman/listinfo/bazaar
<veddox> uups, embarrassing :-/
<veddox> but thanks!
#bzr 2016-04-04
<Mmike> Hi, lads. What's bzr's equivalent of 'git -S' - that is, I'd like to find when a certain string has been introduced into particular file
<LeoNerd> You might want to explain to us what  git -S  does as we might not know
<LeoNerd> (I for one don't)
<fullermd> Mmike: perhaps some invocation with bzr grep?  If nothing else, you could use log -p and search through the output...
#bzr 2016-04-06
<GnuYawk> bazaar sucks
<GnuYawk> git >>>
<abiliojr> hi, trying to spot something in an ubuntu ppa ... cloned the bzr repo, when it finishes cloning it says Most recent Ubuntu Wily version: 6.0.8-1
<abiliojr> yet on the current changelog (and seems to be the case with the code contained within) is says "version 4.x"
<abiliojr> am I missing anything?
<abiliojr> I'm a bzr newbie
<abiliojr> last commit in the log is from 2012, yet the 6.0.8 version it claims being the last is from this year
#bzr 2016-04-09
<vila> abiliojr: Sheesh, too bad your timeout is too short :-/
<vila> abiliojr: 'cloned the bzr repo' is the root. I guess you're using the ubuntu source one and it is out-of-date :-/
<vila> abiliojr> am I missing anything? => See above.
<vila> <abiliojr> I'm a bzr newbie: Nothing wrong with that but if you know how to clone the ubuntu sources you're already not a newbie anymore ;)
#bzr 2018-04-02
<gour> morning
<gour> is it possible to continue using brz with the repo which was originally cloned/pulled with git?
<gour> i tried 'brz pull' on my repo and got the following: https://pastebin.com/U8GcUQsb
<jelmer> gour: should be fixed if you update your version of bzr-git
<gour> jelmer: ok, thanks
<gour> jelmer: now i get this: https://paste.fedoraproject.org/paste/~ubZeJ0wGMk8fIv6nICrqw
<jelmer> gour: you need a newer dulwich as well
<jelmer> gour: (and possibly a newer bzr)
<gour> jelmer: i already updated brz, now pulled and re-install all of them, but still get 'brz: ERROR: ImportError: cannot import name LOCAL_TAG_PREFIX'
<jelmer> gour: try pulling from dulwich now? Sorry, forgot to push that last change
<gour> jelmer: now it's ok. excuse me for bothering you
<gour> although now after pull i get: "brz: ERROR: These branches have diverged. Use the missing command to see how...", but that's probably another non-brz-related issue
<jelmer> gour: no worries, I'm curious why our CI didn't catch this particular issue
<jelmer> gour: do you have local changes?
<gour> jelmer: i bet i didn't have, except in case i just did a local build
<jelmer> gour: local committed changes, I mean
<gour> jelmer: yeah, i understand...it could be that i did perform local build on freshly cloned repo without commit...now cloning from the scratch
<gour> jelmer: now i did 'brz pull' into another repo originally fetched via git and get the same msg, although 'git status' shows everything is clean?
<jelmer> gour: are you specifying an explicit URL to pull from?
<gour> jelmer: nope
<jelmer> gour: is the URL it says it's pulling from what you would expect? are there other branches in the remote URL?
<gour> jelmer: see https://pastebin.com/7ASkhwJa
<jelmer> gour: ah, restic is a public repo? I can try and reproduce it here
<gour> jelmer: yes, https://github.com/restic/restic
<gour> so, first cloned via git and now tried to update by pulling with brz
<jelmer> gour: oh, the URL is invalid
<jelmer> it's a rsync-style URL, which bzr doesn't understand
<jelmer> try git+ssh://git@github.com/restic/restic
 * jelmer files a bug
<jelmer> hey gour_
<jelmer> gour_: so I've fixed the URL issue (change is landing now), but I can't reproduce the DivergedBranches issue
<gour> jelmer: when the changes is going to be landed,i can try pull some other git-cloned repo
<gour> only brz-git is affected?
<jelmer> brz-git and dulwich
<jelmer> I'll let you know when it lands
<gour> thank you
<jelmer> gour: changes have landed; you'll need a new brz-git & a new dulwich
<gour> jelmer: tried with another github project and got the same diverged branches
<jelmer> gour: what does "git pull origin HEAD" report if you try that instead?
<gour> jelmer: https://pastebin.com/RuDNSxtH
<jelmer> gour: thanks, reproduced now
<jelmer> gour: pushed a fix to lp:brz-git, can you try again?
<gour> jelmer: excuse me, was afk...now it works, thanks a lot!!
<jelmer> \o/
#bzr 2018-04-03
<gour> morning
<gour> do you consider that brz-git is beta now?
<jelmer> Hi gour
<jelmer> I'm not sure, what does that mean?
<gour> jelmer: well is it ready to recommend it (as beta) to some users forcing to use git and would be more pleased witz brz
<jelmer> gour: I'm not sure; the software is stable, but things are still changing a lot and you need to keep your brz/brz-git/dulwich synced or things may not work because of API incompatibilities
<gour> jelmer: ok, i'll wait a bit and using it personally before further recommendation
<jelmer> gour: it should be okay to use, but there will be annoying API incompatibilities issues until breezy hits 3.0 beta
<gour> jelmer: ok, i got it ;)
<LeoNerd> Hrm... Migrating some commits of a project from bzr to git. Options? I see  `bzr fast-export | git fast-import`  but that appears to be for entire history
<LeoNerd> I made my bzr branch as a snapshot of current master out of git, made some commits, and now I want to apply those same changes into git
<LeoNerd> So my next thought was: checkout from git, cd into it, and use `bzr replay ../path/to/bzr/version` to replay individual commits. That gets upset too:  bzr: ERROR: Push is not yet supported for bzr-git. Try dpush instead.
<LeoNerd> I don't want it to push. Just to apply
 * LeoNerd decides to write a script to do it commit by commit
<jelmer> LeoNerd: hi
<LeoNerd> Hello
<jelmer> LeoNerd: probably the thing that comes closest is to use bzr to generate git-am style patches and apply those with 'git apply'
<LeoNerd> Yes. But I couldn't work out how to do that
<jelmer> if you have bzr-git installed, I believe it's "bzr send --format=git -o dir -r-10"
<LeoNerd> Ah,.. there's a --format option
<LeoNerd> bzr: ERROR: No submit branch known or specified
<jelmer> you can probably just specify the local branch if you specify a range
<LeoNerd> Hrm... it mkdired 'dir' but that's now empty
<LeoNerd> $ bzr send --format=git -r 2.. -o dir ../Net-Async-SOCKS+bzr1/
<LeoNerd> bzr: ERROR: exceptions.TypeError: from_trees_options() takes exactly 10 arguments (9 given)
<LeoNerd> Well that's fun too :)
<LeoNerd> Ooooh this is so close.  bzr log -p  outputs a metadata header + patch. I can almost pipe that into  git apply  except for the fact that git expects file paths to begin with  a/  and  b/
<LeoNerd> It doesn't look like there's arguments to bzr log -p to prepend those, nor git apply to not expect them
<LeoNerd> Oh humm... it seems my entire endevour might be for naught :/ turns out what I thought was a clean snapshot of master, wasn't. :/ so I have some spurious other differences to fix up first
<mgz> hm, the diff arg to set prefixes is amusingly also -p
<LeoNerd> Yes... So I can get it from  bzr diff -pa/:b/
<LeoNerd> I'll just run two commands, a bzr log without -p to get the metadata, plus bzr diff to get the patch
<fullermd_> Almost makes one wonder if tailor still works   :)
<gour> fullermd_: i believe it does not, based on the chat with its author some time (months) ago
<fullermd_> Wouldn't be surprised.  It was always a neat but finicky hack.
<fullermd_> Not sure I ever succeeded in using it to really do anything nontrivial, even when it was active.
#bzr 2018-04-04
<gour> morning
<gour> afaik, after cloning some git repo with 'git clone repo-url', one can do 'git fetch' and then checkout to some other (non-master) branch. with brz it's possible to use 'brz switch', but i wonder how to replace 'git clone url; git fetch' with brz only?
<jelmer> gour: breezy's operations are generally per branch rather than per repository (as in Git)
<jelmer> gour: there is https://bugs.launchpad.net/brz/+bug/831939 for clone support
<ubot5`> Ubuntu bug 831939 in Breezy "command for cloning bzrdir including *all* colocated branches" [Wishlist,Triaged]
<gour> jelmer: thanks. that would be cool to have, indeed
<jelmer> gour: FWIW you can address individual colocated branches by adding ",branch=blah" to the end of a URL
<jelmer> but it's a bit clunky
<gour> jelmer: i tried that before, but it was not clear whether i should do it in a separate directory or within original clone...moreover, i got some errors in regard and therefore did 'git clone; git fetch'
<jelmer> gour: something like 'brz branch https://code.blah/foo,branch=blah file:.,branch=blah' should work
<jelmer> but yeah, pretty clunky :)
#bzr 2018-04-05
<gour> df -h
