#bzr 2007-12-24
<``Cube> jelmer: the icons are ready!
<``Cube> I updated them!
<``Cube> and all sizes
<``Cube> 192x192, 144x149, 48x48, 32x32, 22x22 and 16x16
<``Cube> also, I doesn't seems like I got your cc
<``Cube> jelmer??
<``Cube> jelmer?
<jelmer> ``Cube: Hi!
<``Cube> hey
<``Cube> did you get the link, jelmer?
<``Cube> uh
<jelmer> ``Cube: No
<``Cube> jelmer: I mean did you get my last messages
<``Cube> well
<``Cube> http://cubibubi.cu.funpic.de/tango/bazaar/
<``Cube> check this out
<``Cube> I fixed the issue you told me yesterday
<jelmer> ``Cube: thx
<``Cube> and?
<``Cube> how do you like themÃ
<``Cube> ?
<jelmer> ah
<jelmer> yep, this is what I meant
<jelmer> brb
<``Cube> I didn't get the mail you wanted to cc me?
<``Cube> !
<``Cube> oh ok, I got it :P
<``Cube> jelmer: but it would be nice if you used my real name instead of that nick
<jelmer> re
<jelmer> ``Cube: I didn't know your real name, that's why I used your nick
<``Cube> sure of course!
<``Cube> no problem, just for the next time
<jelmer> ``Cube: sure, will do
<jelmer> ``Cube: Btw, nice work on the icons. I like them (-:
<``Cube> jelmer: thanks. what do you think, will they become official?
<jelmer> ``Cube: It would be nice to get some input from the other bzr-gtk team members
<``Cube> jelmer: hmm yes, you're right
<``Cube> just subscribed to the list
<``Cube> jelmer: you might send the pictures I did attached or just send the link to the mailing list for the people to get a general idea and to be able to decide whether this is worth consideration or not
<``Cube> or should I do this?
<``Cube> jelmer...
<jelmer> ``Cube: Sorry, I'm usually a bit slow replying on IRC
<jelmer> ``Cube: Either would be fine with me
<``Cube> hehe ;) no problem
<``Cube> you mean, its ok if I do it, but you wouldn't have a problem doing it yourself?
<jelmer> ``Cube: I'd be happy to send the icons, but it may also be a good way for you to introduce yourself :-)
<jelmer> yep
<``Cube> hehe :D exactly what I wrote :P
<``Cube> ok
<jelmer> :-)
<jelmer> yep, whatever you prefer
<``Cube> ill introduce myself, ok?
<``Cube> jelmer: can I attach images to the email I send to this mailing list?
<jelmer> ``Cube: Yep, that's fine
<``Cube> is there any size restriction?
<jelmer> Not sure, I think it's a couple of hundred kb
<``Cube> oh ok
<``Cube> thanks
<mlh> whois ``Cube
<mlh> oopsa
<``Cube> :P
<``Cube> its me
<mlh> :-)
<mlh> hadn't seen you here before
<``Cube> ;)
<``Cube> yea
<``Cube> I'm kinda new here
<mlh> converting from some other vcs or just thinking?
<``Cube> huh?
<jelmer> mlh: ``Cube is helping us (bzr-gtk) out with some icons
<mlh> axcellent
<mlh> I just 'updated' in fedora7
<``Cube> ehm, is there anything else then bzr-gtk here?
<mlh> got bzr 1.0, bzr-gtk 0.93  bzrtools 1.0.0 .. good work!
<``Cube> ah
<``Cube> anyone got my mail?
<jelmer> ``Cube: I did
<``Cube> oh
<jelmer> none of the other bzr-gtk folks appear to be here atm
<``Cube> could you reply something?
<``Cube> hmm ok
<jelmer> it's usually more busy
<``Cube> ok ;)
<aadis> does pull need a destination?
<CardinalFang> aadis, It's usually the present branch.  I don't think it even makes sense from outside a branch.
<aadis> yeah. all the examples never mention that you have to specify the full path the first time
<aadis> I meant, source to pull from
<CardinalFang> aadis, And if you don't, the default is the place from which you cloned that branch the first time, yes?  (I may be wrong.  I'm pretty new to Bzr, but I've used others.)
<aadis> i don't think that works.
<aadis> i just did a checkout, and then immediately a pull. fails.
<CardinalFang> Hmmpf.
<aadis> @areia:~/src/pentaur/argus $ bzr pull
<aadis> bzr: ERROR: No pull location known or specified.
<luks> if you have a checkout, use 'bzr up'
<bob2> the default will be set for branch, not pull
<bob2> er, not co
<CardinalFang> aadis, Ah, that's it.  Don't use "checkout".  That's the command for Svn users who don't know any better.
<CardinalFang> ...maybe.
 * CardinalFang lurks.
<aadis> well, that's what the docs suggest
<aadis> for doing distributed development
<aadis> since chekcout allows you to do local commits without --local all the time :)
<bob2> it's the other way round
<aadis> really?
<bob2> unless you co from a local repository, then co and branch don't need --local
<bob2> er, "local mirror of a remote branch in a local repository"
<aadis> ah, ok. so it seems.
<aadis> if i create a local branch (ie i have checked out trunk and branch from it)
<aadis> how do i ensure my branch also gets committed to the server? (so two people can work on one feature branch)
<bob2> you can bind it to the server (cd branchdir ; bzr bind sftp://host/branch)
<bob2> then it acts as if you did a co sftp://host/branch
<aadis> ah. so when i commit it goes to server.
<bob2> as well as the local branch, yeah
<bob2> you can "bzr unbind" to disable it
<aadis> cool. thanks bob2
<aadis> bob2: and i'm assuming sftp://host/branch already exists? or someone needs to run bzr init for it?
<bob2> right
<aadis> ok, so someone will need to do "bzr init branch" on host?
<bob2> yes
<bob2> maybe it works over sftp etc now
<bob2> appears to
<aadis> we'd be using bzr+ssh anyway, so smart server might be able to do it
<aadis> doesn't seem to work for me, over bzr+ssh
<bob2> wfm
<aadis> @areia:/tmp/sandbox/test-1-branch $ bzr bind sftp://a@pr0n/home/p/bzr/sandbox/test-1-branch
<aadis> bzr: ERROR: Not a branch: "sftp://a@pr0n/home/p/bzr/sandbox/test-1-branch/".
<bob2> oh bind
<bob2> does "ssh a@pr0n ls -la /home/p/bzr/sandbox/test-1-branch/" show a .bzr dir?
<aadis> no
<aadis> ah, i see your point. I need to do bzr init sftp://a@pr0n/home/p/bzr/sandbox/test-1-branch first
 * aadis is slow today
<aadis> though http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-checkouts says:
<TFKyle> heh, nice machine name
<aadis> it's also cnamed to cocaine.company.com
<aadis> and also dev.company.com for the suits ;)
<TFKyle> aadis: not sure if I understand the situation fully, but wouldn't you want to bzr push to the remote location not init it? (unless you havn't created the branch locally yet I guess)
<aadis> i'm *very* new to bzr, so i'm trying to figure the right thing
<aadis> we're following the distributed model
<aadis> so when i'm hacking on a local branch and also want to share it with other people
<TFKyle> ok, that typically means that you have a local branch of the project and then push to a place that other people can pull from manually
<aadis> is bzr push the right idea? /home/p/bzr/sandbox was created with "bzr init-repo sandbox"
<TFKyle> though if you have a local server I guess having a bound branch to it works too
<aadis> i think we'd do a bind/commit/push/unbind would be done very infrequently
<aadis> TFKyle: so should we do a bzr init && bzr bind ; or bzr push?
<TFKyle> aadis: not sure, have you created the repo locally already?
<aadis> what do you mean by locally? my machine or the server?
<TFKyle> your machine
<aadis> what i did was. bzr init-repo; bzr branch sftp://server/trunk; bzr branch trunk fix-branch
<aadis> so i think yeah, the repo is created locally
<TFKyle> ok, and you want to put that branch onto another server? if so then you probably want to bzr push it to that server then optionally bind to the branch on that server (not sure how repos work really though, havn't looked at them much)
<CardinalFang> Hi all.  I want to write a plugin trigger that runs only for one project.  Any suggestions?
<TFKyle> (if you bzr init'd another branch on the server it wouldn't have any commits your local branch has currently)
<aadis> TFKyle: ah, i see. good point.
<CardinalFang> No one has ideas about making a plugin trigger run for only one kind of project?
<CardinalFang> I could insert some sort of test at the beginning, I suppose, and exit if it fails.
<CardinalFang> ^exit^return
<CardinalFang> Maybe require that a specially-named file exists.  What would that be?  "if not master.repository.path2id("foo"): return False"
<radix> CardinalFang: sounds like you want a configuration directive
<radix> CardinalFang: branch.get_config().get_user_option("foo")
<radix> CardinalFang: then people can put "foo = whatever" in their ~/.bazaar/locations.conf under the appropriate path
<CardinalFang> radix, I have more than a hundred people to give this to.  Giving a file is fine.  Telling them to customize it is not.
<radix> unfortunately there's not a branch-hosted configuration mechanism yet :\ you could definitely come up with something ad hoc.
<CardinalFang> It would be cool and useful to safe the changeset (and file) commit messages saved at "uncommit" and inserted as the default for the next commit.
<CardinalFang> ^safe^save
<micr0c0sm> Would anyone care to look at a design document for a new distribution I am going to make as part of a University project?
<micr0c0sm> You know, shoot some holes in any of the design/implementation issues that are probably there before I start coding something impossible.
<gianmt> guys, kind of dumb question but... how do I set the bookmarks in bzr-gtk?
<gianmt> after a couple of minutes fighting I gave up
<gianmt> :p
#bzr 2007-12-25
<catfacts> can someone help me set up a bzr+launchpad account
<beuno> catfacts, do you have a launchpad account already?
<catfacts> yes
<catfacts> i have a project and a project branche reged too
<beuno> catfacts, great, then it's fairly simple
<beuno> catfacts, perfecto
<beuno> what's your username and project name?
<beuno> (so I can just paste you what you need to do)
<catfacts> catfacts3192 and fcm-colab
<catfacts> i tried
<catfacts> bzr push bzr+ssh://catfacts3192@bazaar.launchpad.net/~catfacts3192/fcmcolab/fcm-colab
<beuno> you want to setup a new repository in launchpad?
<catfacts> and got an error
<catfacts> no i have one
<catfacts> https://code.launchpad.net/~catfacts3192/fcmcolab/fcm-colab
<beuno> catfacts, what error did you get?
<catfacts> a big one h/o
<beuno> catfacts, have you commited to the branch already?  do you have revisions?
<catfacts> http://pastebin.ca/831483
<catfacts> yes i did one initial commit
<catfacts> to my computer
<beuno> catfacts, seems that you don't have your ssh key setup properly
<catfacts> ssh key?
<beuno> yes, that's what LP uses for authentication
<catfacts> ah
<catfacts> so how do i set this up
<beuno> you have a key uploaded to your profile, you should double check that your on the same PC that you created that key
<catfacts> oh
<catfacts> i just reinstalled, like today
<beuno> catfacts, right, did you save your ~/.ssh folder?
<beuno> if not, http://bazaar-vcs.org/Bzr_and_SSH
<beuno> is a good way to regenerate it
<catfacts> i have a file called known_hosts
<beuno> catfacts, did you save your ~/.ssh folder?
<beuno> or is it a fresh one?
<beuno> you need to have 2 files, id_rsa and id_rsa.pub
<beuno> if you don't
<beuno> you need to regenerate your key
<beuno> and upload it again to LP
<catfacts> now i do
<beuno> catfacts, did you re-generate or copy the old one?
<catfacts> new one
<beuno> great, then upload the new key to LP
<catfacts> done
<catfacts> ok it looks like it is doing something
<beuno> :D
<catfacts> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x866f14c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<beuno> ah, not nice
<beuno> what version of bzr are you running?
<catfacts> http://pastebin.ca/831486
<catfacts> i guess the most recent one
<catfacts> i just updated my system
<beuno> 0.90, 1.0 is out already
<beuno> I'd recommend to update to that
<catfacts> and after this i get to fix php5+apache :p fun
<beuno> it's far more stable
<beuno> http://bazaar-vcs.org/Download
<catfacts> yup .9
<beuno> catfacts, I have to run
<beuno> good luck with that
<catfacts> sigh thanks
<catfacts> :P
<catfacts> can someone tell me what to do http://pastebin.ca/831497
<catfacts> i registered that branch so i have no clue
<jelmer> catfacts, try running "bzr break-lock"
<catfacts> looks good so far jelmer
<``Cube> jelmer: no news?
<tumbleweed> what's whrong with this URL? pserver://anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal?tag=DRUPAL-5-5
<tumbleweed> it seems to be downloading trunk
<tumbleweed> s/trunk/HEAD/
<tumbleweed> erk, seems there's no mention of tag support in the source...
<tumbleweed> bad documentation--
<jelmer> tumbleweed: ?
<jelmer> The user guide should have documentation on tags
 * fullermd is somewhat frightened at the thought of bzr working with pserver:// URL's...
<jelmer> fullermd: I think he's using launchpads import service or something
<fullermd> jelmer: Does that mean you're NOT writing bzr-cvs any time soon?   ;)
<jelmer> yup (-;
 * jelmer still needs to spend some time with bzr-git to make it workable
<tumbleweed> jelmer: In that case I've never seen the config-manager docs
<tumbleweed> jelmer: because I never found anything beyond the most basic list of features and an example
<jelmer> tumbleweed: ah, you're talking about config-manager
<jelmer> lifeless is the person you'd want to talk to
<jelmer> I doubt there are much config-manager users here
<tumbleweed> jelmer: ja, I left him a /msg a few days ago
<tumbleweed> jelmer: I've been having no end of trouble with it :-)
<tumbleweed> tcp resets ++
<dato> uuh, oh.
<dato> can somebody confirm/deny that with bzr.dev running `bzr diff` in a subdirectory only shows changes under that directory?! (works in 1.0)
<fullermd> Er.  Not that I've seen...
<dato> fullermd: aha. well, if you could check, that'd be nice
<beuno> dato, I can confirm that
<beuno> bzr diff in the latest bzr.div only outputs the changes within that dir
<beuno> actually, it does recursively go to other dirs
<beuno> but misses the parent dirs
<beuno> s/go/goes
<beuno> bzr status outputs correctly though
 * dato files a bug
<ubotu> New bug: #178591 in bzr "running `bzr diff` in a subdirectory does not show changes in the	parent directory" [Undecided,New] https://launchpad.net/bugs/178591
<Qhestion> is it possible to integrate bazaar into kdevelop?
<beuno> Qhestion, I suppose with enough time/effort, you can integrate it into anything, but there isn't any plugins like for eclipse as far as I know
<Qhestion> well, it "has" Perforce, CVS, Clearcase and Subversion...
<Qhestion> not that i would ever want to use these...
<beuno> Qhestion, yeap, there shouldn't be any other reason besides someone taking the time to do it for it to exist
<Qhestion> i prefer command line anyway :/
<Qhestion> (usually, but i just tried kdevelops "new project" wizard and it asked me for a version control system to use... eeh.)
<Qhestion> ok thanks
<beuno> Qhestion, you might want to open a bug requesting it
<beuno> knowing that there is some interest in it, you might make someone curious enough to try
<Qhestion> i really should
<Qhestion> i will - at least if that bugtracker does not require me to create an account first
<beuno> Qhestion, launchpad will, yes
<Qhestion> oh launchpad
<Qhestion> i thought you meant the kdevelop trackers...
<Qhestion> funny, there are *always* two sides..
<beuno> Qhestion, I'd file it in launchpad first
<beuno> :D
<Qhestion> i think i should do that
<beuno> https://bugs.launchpad.net/bzr/
<Qhestion> did not find the trackers for kdevelop...
<Qhestion> their homepage is not very well organized i guess
<Qhestion> and here comes another @mailinator.com account :/
<Qhestion> and konqueror hangs, does not display the launchpad site..
<mathrick> hiya
<mathrick> congrats on 1.0 :)
<mathrick> also, rebasing can be used to reshape the commit history into clean "logical" patches, instead of how the devel actually happened, right? If so, how exactly would I go about that?
#bzr 2007-12-26
<ubotu> New bug: #178695 in bzr-cvsps-import "Problem when trying to import CVS module" [Undecided,New] https://launchpad.net/bugs/178695
 * ddaa starts looking at bzr-git
<ddaa> > stgit is used to provide python parsing of the output of git commands.
<ddaa> gack! pyarch flashback!
<``Cube> has anyone received my mail?
<``Cube> ddaa: ?
<ddaa> Is that the quick hack it looks like, or is this the officially blessed way to bind to git?
<ddaa> ``Cube: using CLI spawning/parsing as a library binding is evil.
<``Cube> huh?
<``Cube> just asked about the icon mail
<``Cube> I didn't get any feedback yet
<ddaa> dunno what you asked about, I just got in. This was an unrelated comment.
<``Cube> ah ok :D
<``Cube> well, so I'll ask again: I sent a mail with icons
<``Cube> did you get it?
<``Cube> some days ago
<ddaa> I have 4764 unread mails in my bzr folder.
<``Cube> WOO
<``Cube> lol nice
<``Cube> could you search for mine?
<ddaa> subject?
<``Cube> one second, oki?
<``Cube> Introduction + Bazaar Icon Tango Remake
<ddaa> There's such an email
<ddaa> with one giant png that collates a bunch of icon
<``Cube> heh ;)
<``Cube> yea
<``Cube> thanks it
<``Cube> *that's it
<ddaa> not really usable as is
<``Cube> hmm :S
<``Cube> it was just a propose
<``Cube> hmm, you don't like it, ok
<``Cube> looks like its not gonna pass
<ddaa> I am in no position to make a judgement about it.
<ddaa> It just looks kind of weird to me that you submit tango icons to upstream. Shouldn't this be packaging in the tango theme package, instead of bzr?
<``Cube> well, I wanted to replace the current icons with tango icons
<``Cube> on launchpad, the webpage and so on
<ddaa> ``Cube: Also, all the Canonical folks are on holiday ATM, so you should wait until January for an authoritative reply.
<``Cube> oh, ok
<``Cube> but you don't think they'll pass it?
<``Cube> by the way, the 16x16 isn't ready yet
<ddaa> They sure look nice. My private opinion is that they are too low-contrast for use as the main icons. But they are a great fit to tango-like themes.
<ddaa> But it's only my private opinion, the people in charge may very well think differently.
<``Cube> oh ok
<``Cube> I mean, I can change them completely
<ddaa> couple of things I do like
<``Cube> I just tried to make them look close to the original ones
<ddaa> is the lack of drop-shadow under the arrow, and the square incoming road.
<ddaa> Please do not change them because of my feedback. Wait for authoritative feedback.
<``Cube> heh ;) ok sure
<``Cube> well, are the canonical very...
<``Cube> lets say
<``Cube> professional?
<``Cube> or do they accept lil mistakes at the beginning
<``Cube> and similar stuff?
<ddaa> Being professional and being welcoming to new community contributors do not have to be mutually exclusive.
<``Cube> hmm, you're right...
<``Cube> well ok, thanks a lot, ill wait until they come back
<``Cube> in JAN
<``Cube> ehm, do you have someones IM?
<``Cube> I'd like to contact them personally
<``Cube> because, if there are so many mails coming in
<``Cube> mine will probably go under
<ddaa> That's okay. They know how to do deal with large amount of email. I'm sure you'll receive some attention.
<ddaa> Nagging is not a good idea at first. You did the right thing by posting to the mailing list and by asking here.
<ddaa> BTW, this crowd tend to prefer pure-text email rather than HTML.
<ddaa> Just for the future.
<``Cube> hmm ok
<``Cube> thanks
<``Cube> but someone with pure-text, can he receive my mails at all?
<ddaa> sure
<ddaa> they include a text/plain mime part.
<``Cube> ah, ok
<ddaa> they do not look optimal (too many blank lines) but they are perfectly readable.
<``Cube> oh yes, heard about that blank line issue somewhere
<lifeless> beuno: there are plugins for eclispe and visual studio for bzr :))
<ddaa> hey lifeless
<lifeless> hey ddaa, happy xmas stuff
<ddaa> thank, happy yours
 * ddaa had enough christmas for one year
<i386> lifeless: :)
<i386> merry xmas and all that crap :)
<lifeless> i386: :)
 * ddaa went out to ask about binding in #git
<ddaa> this really gives me very strong flashbacks of GNU Arch.
<ddaa> I hope it's just my personal prejudice.
<lifeless> git is the new arch
<ddaa> I'm fearing that much.
<ddaa> This notion scares the hell outta me.
<lifeless> libgit is internal only
<lifeless> I investigated this when starting bzr-git
<lifeless> anyhow, I'm not here ;), Just checking mail after 5 das without :)
<Peng> Git is the new Arch?
<ddaa> Apparently they seem to have this notion that "writing a library interface" is something you can slap over an existing codebase designed to be CLI-driven.
<ddaa> Although my experience in this respect is limited to tla, I believe it's usually nowhere near that simple.
<ddaa> Small things like error reporting and resources handling you need not worry much about in small one-off processes are critical to making a good library API. And a huge pain in the ass to retrofit.
<ddaa> Then "since nobody has bothered to do it, it's probably not all that useful"...
<ddaa> GNU Arch had a way to twist people perceptions. I'm scared that similar things might be at work in the git community.
<ddaa> Not, all of what I just said is my just my personal opinion.
<ddaa> And not all that informed at that.
<ddaa> It seems that git failure modes are indeed consistent with my expectations...
<ddaa> "Fails in mysteriously arcane way for trivial mistakes."
<Peng> Hmm. Bzr and hg are written as libraries. That's kind of an advantage, huh?
<ddaa> Trying to clone from something that's is not a git repo yields "fatal: Not a valid object name HEAD". That's git-speak for "Not a branch."
<Peng> So they write error messages in code. What does that have to do with librarification? :)
<ddaa> tla tended to have the same error reporting issues
<ddaa> things written to be a bunch a scripts seem to tend to suck at propagating error conditions and displaying meaningful context-sensitive messages.
<ddaa> So, then tend to resort to displaying low level errors to the user.
<Peng> Is doing it well in C harder than in Python?
<ddaa> It's not really a matter of language.
<Peng> Ok.
<ddaa> Rather a matter of how people think about their software.
<ddaa> Though, good error reporting is much harder in C than in Python. Exception was one of the great advances in programming languages that occured after C.
<ddaa> But it seems good C programmers are kind of used to setting up whole frameworks to give C things like exceptions, managed memory and run-time polymorphism. And I assume that git programmers are good C programmers.
<fullermd> All that stuff isn't important, though.  Fast is all that matters.
<ddaa> fullermd: always the troll, aren't you? :)
<fullermd> I'm trying to reach my quota so I can leave my bridge for a few hours today.
 * ddaa gives fullermd a red herring
 * fullermd chops down a tree with it.
<ddaa> in monkey island, that used to make the bridge troll happy
<mathrick> ddaa: oh man, tla was horrible
<mathrick> "ERROR: botched assertion (125)"
<mathrick> though it made me learn the word "botched", so it was useful in a way
<ddaa> that one usually meant some form of data corruption :)
<ddaa> in bzr you'd get a traceback in similar cases, which is only marginally better
<acuster> Hey all, with bzr-svn what's the difference between an initial 'bzr branch' and a 'bzr co'?
<GaryvdM> acuster: branch can create a branch without a working tree.  checkout w
<GaryvdM> checkout allways creates a branch with a working tree
 * fullermd blinks.
<acuster> okay, that makes sense
<GaryvdM> checkout is also used to create a working tree for a branch that does not have a working tree
<fullermd> Not to me it doesn't...  is bzr-svn really so different from bzr?
<GaryvdM> no
<acuster> do you know what format I should init-repo with for bzr-svn?
<fullermd> Then the difference is that branch creates a branch, and co creates a checkout.
<GaryvdM> Am I wrong fullermd?
<acuster> fullermd, that may be entirely true but pedagogically, it's useless
<ddaa> Ahem
<ddaa> Okay, so a checkout (heavy checkout) is just a branch.
<fullermd> Grr.  No it's not, it's a checkout.
 * fullermd stabbies the branch.
<ddaa> Except it's "bound" to a master, and when committing to a checkout, changes are automatically pushed to the master, atomically.
<GaryvdM> Checkout = branch + working tree?
<fullermd> A branch gives you an independent branch to work on.
<dato> GaryvdM, nope
<fullermd> A checkout lets you work on the branch you point it at.
<bob2> acuster: something with rich-root support (--rich-root or --rich-root-pack)
<ddaa> GaryvdM: I am afraid you are confused.
<acuster> bob2, thanks
<GaryvdM> oh
<ddaa> GaryvdM: what you call a checkout here is a lightweight checkout.
<ddaa> hello bob2
<ddaa> long time no see
<bob2> he ddaa
<bob2> er, hey.
<ddaa> acuster: so, with bzr-svn, you only really want to use "bzr checkout" to create a branch that you will use only to merge your bzr work into the svn repository.
<ddaa> note, that you can turn a "checkout" into a "branch" using "bzr unbind", and conversely using "bzr bind".
<ddaa> (those are fairly obscure commands, but they are useful to illustrate that a heavyweight checkout is just a branch with some special behaviour)
<fullermd> I still say that definition should die a quick and painful death.
<fullermd> It just makes everything more painful.  It's not a branch with special behavior, it's a checkout with special behavior.
<dato> and what's a checkout without special behavior? :)
<fullermd> Nothing, any more than an internal-combusion motor without special behavior is anything.  Everything has attributes.
<fullermd> Heavy and light are just two different kinds of checkouts with varying attributes and behaviors in edge cases.
<ubotu> New bug: #178722 in bzr "Wrong argument for "bzr log --timezone" triggers internal error" [Undecided,New] https://launchpad.net/bugs/178722
<ddaa> what's the trick to make "bzr selftest" and pdb go along?
<ddaa> I stuck a "import pdb; pdb.set_trace()" in some method called from a test, but it seems pdb is confused by the test runner.
<ddaa> nevermind
<ddaa> it was my evil psyco plugin
<Poromenos> hi, is there a way to change a commit message?
<dato> Poromenos: nope
<dato> Poromenos: well
<dato> Poromenos: if it's the latest entry, and you haven't pushed to a remote place, you could uncommit, and commit again with a fixed message
<dato> but other than that...
<Poromenos> it's  not :/
<Poromenos> ah well, thanks anyway
<Poromenos> is there a way/need to specify dependencies on a project on launchpad?
<ddaa> ah, I found how to fix the test suite on jam's branch.
<ddaa> It seems that git-fast-import --export-marks=foo now actually changes the foo file instead of just writing to it (hardlink breaking), so it defeats the use of NamedTemporaryFile in the GitBranchBuilder.
 * ddaa grumbles
<ddaa> that's the kind of stupid shit you get when trying to bind to a CLI
<acuster> grrr 1000 of 7300 and already at 61% cpu,
<``Cube> oh no
<acuster> no way to branch that svn repo
<``Cube> incredible
<acuster> well, let's run until we crash.
<acuster> Does bzr still have know memory leaks?
<jelmer> acuster: It's subversion
<jelmer> There was a huge memory leak in the subversion python bindings
<acuster> hey jelmer
<jelmer> http://subversion.tigris.org/issues/show_bug.cgi?id=3052
<acuster> thanks
<jelmer> hi ``Cube
<``Cube> hi
<ddaa> jelmer: I think the SvnRaTransport docstring "This implements just as much of Transport as is necessary to fool Bazaar." is a tad bit outdated now :)
<jelmer> heh, good point :-)
<ddaa> was looking for a template transport to define a git:// transport
<jelmer> ah, working on bzr-git ?
<ddaa> just some holiday hacking
<ddaa> best way to benchmark against git would be having a working bzr-git in the first place
<ddaa> also, git is not going to away anytime soon, so it will be useful, and help some ubuntu folks that need to deal with git upstreams.
<jelmer> same here
<jelmer> now that Samba has switched to git, it would be very nice to see a working bzr-git
<fullermd> Think it'll be good and usable in 6 months, say?
<ddaa> there are some unique challenges
<ddaa> such as dealing with git's approach of guessing renames instead of recording them
<ddaa> that assumes the intelligence is in the commands, not in the data.
<ddaa> That clashes quite badly with the bzrlib design.
<fullermd> I just need a planning number, so I can figure out when it'll be time to get samba to switch to the next VCS I want foreign branch support for   ;)
<ddaa> It seems quite unlikely to me that anybody would switch away from git to anything but svn or bzr.
<ddaa> depending on where they put the blame for the pain they endured.
<ddaa> what's this me_too thing?
<fullermd> Can't see.  too_short.
<jelmer> ddaa: As long as the plugin always detects renames at the same places, there's no problem :-)
<ddaa> I mean that git has a lot of freedom to evolve their rename-guessing logic
<ddaa> but a bzr-git plugin would be much more constrainted
<fullermd> Yeah.  They've got all the time in the world to try and come up with a herustic to figure out the information that the user could just provide at the time   :p
<jelmer> ddaa: yup
<jelmer> path tokens ftw!
<ddaa> what's that?
 * ddaa is hopelessly out of touch
<jelmer> replacement for fileids proposed by robert
<ddaa> gotta be interesting
<jelmer> meant to solve parallel imports and copy tracking
<jelmer> yeah, the idea is very interesting
<jelmer> but it's also quite abstract at this point
<jelmer> http://bazaar-vcs.org/DraftSpecs/PathTokens
<ddaa> I regard git's support for parallel imports a very strong point for them.
 * ddaa reads the spec
<fullermd> git doesn't lack in strong points.  Now, if it lacked a bit more in nuttiness...
<fullermd> The content-addressed storage is certainly a strong point.
<ddaa> I've always felt utterly nonplussed by this.
<fullermd> And I get to like the crypto-hash-as-revid concept better the longer I think of it.
<ddaa> really, we only have identity problems in bzr because of limitations in how we deal with parallel imports.
<ddaa> and content-addressing has some major drawbacks
<fullermd> It's got major advantages too.
<ddaa> as in making it pretty much impossible to have native checkout for foreign repository formats.
<fullermd> Though I see it as fairly orthogonal to the identity issue (at least, insofar as I'd mentally want to take it; file texts)
<ddaa> mh... this spec is pretty light on actual ideas
<ddaa> it's just a problem statement
<ddaa> jelmer: why does bzr-svn uses BOTH BzrDirFormat.register_control_format AND format_registry.register to register SvnRemoteFormat?
<jelmer> Hmm, you're right, that's confusing..
<ddaa> I guess that means only format_registry is needed, right?
<jelmer> No, I think the first one is for the handling of ".bzr"
<jelmer> s/.bzr/.svn
<jelmer> while the latter is usually a combination of a branch, repository and working tree format
<ddaa> BzrDirFormat.register_control_format(format.SvnRemoteFormat)
<jelmer> "dirstate-with-subtree"
<ddaa> that is not .svn stuff
<jelmer> that's the remote stuff
<jelmer> detecting the control dir happens by checking whether the transport is a SvnRaTransport
<ddaa> right
<jelmer> rather than checking for a .svn directory
<ddaa> but then
<ddaa> format_registry.register("subversion", format.SvnRemoteFormat,
<ddaa>                          "Subversion repository. ",
<ddaa>                          native=False)
<jelmer> the format registry bit is just so it appears in the output of "bzr init --help"
<ddaa> ok
<jelmer> and so info knows how to call it
<Poromenos> for some reason i can't branch from https, (launchpad), curl is giving me an error. any ideas?
<ddaa> couple of them
<ddaa> either use the actual http or bzr+http address of the branch
<ddaa> https://code.launchpad.net is just a redirection to http://bazaar.launcphad.net
<Poromenos> it redirects
<Poromenos> hmm
<ddaa> or do not use curl
<Poromenos> i'm not doing it intentionally, bazaar is
<Poromenos> http://bazaar.launchpad.net/gnuhello isn't working
<ddaa> you can use https+urllib:// urls to stop it from using pycurl
<Poromenos> not a branch, actually
<Poromenos> ah
<ddaa> or you can uninstall pycurl if nothing else is using it on your system
<Poromenos> i don't think anything is, i'll try that, thanks
<ddaa> btw, this url is indeed not a branch
<Poromenos> as an aside, do you know how i can generate ssl keys?
<Poromenos> yes, but launchpad.net/gnuhello is
<ddaa> check https://code.edge.launchpad.net/~vcs-imports/gnuhello/trunk
<ddaa> you'll see the download URL there
<Poromenos> ah, urllib worked, thanks though
<ddaa> the redirection magic only happens on code.launchpad.net, not on bazaar.launchpad.net
<Poromenos> ah
<ddaa> Poromenos: the command is ssh-keygen, if you are on linux
<ddaa> if you are on Windows, I have no clue.
<Poromenos> i'm on ubuntu, thanks
<ddaa> Poromenos: I'm pretty sure there is extensive documentation about this stuff on help.launchpad.net
<Poromenos> i can't find it, i'm following the tutorial but i couldn't find help on either the tutorial or the ssl keys page
<Poromenos> ssh, i mean
<ddaa> ok
<ddaa> maybe file a bug on launchpad-bazaar then
<ddaa> this sort of thing should be crystal clear.
<Poromenos> i will, thanks
<Poromenos> can i delete a branch after i publish it?
<Poromenos> (on launchpad)
<dato> jelmer: did you see my mail about bzr-plugins?
<jelmer> dato: no that I remember - where did you send it?
<dato> bazaar@ and -maint
 * jelmer has a look
<GaryvdM> If I ran bzr-gtk's ./setup.py install - is there a way to uninstall?
<Poromenos> can anyone ssh to bazaar.launchpad.net?
<Poromenos> it's not working for me
<ddaa> the shell is disabled
<Poromenos> oh
<Poromenos> temporarily?
<ddaa> permanently
<Poromenos> how do people upload code then?
<ddaa> bzr push
<Poromenos> push where...
<ddaa> to the bzr+ssh url displayed on the branch page of a hosted branch
<Poromenos> that's what's not working
<Poromenos> https://code.launchpad.net/~stavrosk/gmailchecker/main
<ddaa> please paste the bzr command you typed and the output it produced
<Poromenos> bzr push bzr+ssh://stavrosk@bazaar.launchpad.net/~stavrosk/gmailchecker/main
<Poromenos> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<Poromenos> that's it
<ddaa> meh
<ddaa> indeed, it's down
<dato> Next mirror:
<Poromenos> ah
<dato> As soon as possible
<dato> heh
<Poromenos> i'll wait then, thanks
<Poromenos> can i name a branch?
<Poromenos> i mean in bzr
<Poromenos> probably not, nm
<ddaa> not sure what you mean
<ddaa> you can specify a branch nick that will be recorded in commits
<ddaa> otherwise, the name of a branch is its url
<ddaa> you can change the last past of a branch url on launchpad
<ddaa> "Edit branch details", it's the branch name field.
<Poromenos> i just saw "branch name" on the web interface, but i realized it's what you enter
<Poromenos> yes, thanks
<kripken__> Since an hour ago I get an error when I try to use bazaar to update my branches on launchpad, "connection refused: please check connectivity and permissions". Any idea how to do that? (it says "try -Dhpss", but that doesn't help)
<ddaa> apparently the ssh server is down
<ddaa> there should be a nagios alarm ringing right now
<foom> are there any speed improvements on the horizon? bzr still (1.0; rich-root-pack source format) seems to be unusably slow (20 minutes, local disk) at making a branch of a 40krev repository.
<luks> the trick is to use shared repositories
<ddaa> right, you don't want to duplicate 40krevs of data anyway
<ddaa> aside from the fs bloat, it does not allow efficient use of the disk caches.
<foom> sure, that's a nice trick when it works. but it doesn't work in all situations, and 20 minutes is *reaaaallly* long.
<jelmer> hi foom
<luks> hm, what are the situations when it doesn't work?
<foom> jelmer: hey there
<foom> luks: branching a remote repository, for example.
<kripken__> ddaa: thanks for the info
<luks> foom: but you do that only once, and never again
<luks> not such a big problem, IMO
<luks> next time you branch you have most of the data locally
<ddaa> luks: normally, remote branch should be essentially limited by how fast you can pump data off the server. Anything else is a bug.
<ddaa> although it is planned to have shallow branches in the future
<luks> ddaa: yes, but without a shared repository you download it over and over again
<ddaa> so you won't HAVE to pump all the history of the server to make a local branch.
<luks> which is that I guess foom is doing
<luks> er, s/that/what/
<foom> luks: well, okay, you've got me, if this was the only slow thing in bzr, I guess that might be okay. I dunno if it is or not, it's just the first thing I've tested this go-around.
<foom> and it seems quite unlikely that this would be the only too-slow operation
<ddaa> bzr is certainly not as fast as some of the competition, but using the most recent formats, it should be fast enough.
<ddaa> i.e. the time should be a small multiple of the time of other tools, not orders of magnitudes slower as it used to be.
<ddaa> We think it's more important to have "merge" and "commit" be reliable and easy to use, than to have them run in 0.5 second instead of 2 seconds.
<luks> the most annoying thing to me is not the actual performance, but the startup time
<foom> jelmer: i saw you found the (a?) memory leak in svn python bindings and said you worked around it in bzr-svn; is that workaround expected to not be a full fix?
<jelmer> foom: Yes, it isn't a full fix
<foom> jelmer: okay, cause bzr crashed my machine converting a svn repository by running it out of memory and invoking the OOM killer which killed half the important processes. :(
<jelmer> foom: You need an updated version of the python-subversion bindings for all of the memory leaks to go away
<foom> "hey look, X is taking some memory, let's kill it!". thanks linux...heh
<jelmer> http://subversion.tigris.org/issues/show_bug.cgi?id=3052
<foom> that's not patched in ubuntu yet is it?
<foom> luks: startup time?
<foom> and...'bzr log -r20000' takes 23s.
<ddaa> jelmer: it seems pretty much impossible to implement a transparent git:// transport
<ddaa> short of reimplementing the client code
<ddaa> common git servers only expose git-fetch-pack and git-peek-remote services
<ddaa> and the former requires a local git dir
 * ddaa finds this frustratingly limited
<ddaa> yay! git_connect dies on error :(
<jelmer> ddaa: Are you working based on stgit?
<ddaa> jelmer: I'm based on jam's branch
<ddaa> it has no stgit dependency
<ddaa> and right now, I'm staring at the git source itself
<ddaa> and all my fears are confirmed
<jelmer> :-/
<ddaa> 	if (protocol == PROTO_GIT) {
<ddaa> 		/* These underlying connection commands die() if they
<ddaa> 		 * cannot connect.
<ddaa> 		 */
<ddaa> Also, all the network code seems to assume that sockets and pipe and interchangeable
<ddaa> i.e. forget about windows
<ddaa> At least some of the client code will have to be written from scratch.
<ddaa> or heavily patched.
<jelmer> ddaa: You're writing this in C or Python?
<ddaa> just explorating
<ddaa> Actually, I think I'm going to give up on the transparent transport.
<jelmer> I thought Robert already had a lot of this done
<ddaa> the bzr-git code I see is quite proof-of-concept
<ddaa> and it only works locally
<ddaa> i.e. it does not try to do more than git
<ddaa> which pretty much only knows how to fetch packs over the network, then does everything locally.
<jelmer> ah, ok
<ddaa> unfortunately, I do not think that's an acceptable level of functionality for bzr :(
<ddaa> Hey, bazaar.launchpad.net SFTP server is up again
<piedoggie> I just started reading the user documentation and I am damned impressed.
<piedoggie> it is the clearest description I have ever seen up any revision control system.
 * piedoggie thinks everybody is out at Boxing Day parties
<eddyMul> hi. I have a bzr branch in my ${HOMEDIR}. I also have another bzr branch in my ${HOMEDIR}/Desktop/vision/proj2/. If I want to graft/merge proj2 to ${HOMEDIR}, should I use `bzr merge`?
<Verterok> eddyMul: take a look to the merge-into plugin <https://launchpad.net/bzr-merge-into/>, might be helpful.
<eddyMul> Thanx, Verterok. Will look at it
<eddyMul> Verterok: looks like this is what I'm looking for. There's a bug againts bzr-0.90. Do I need bzr-1.0?
<Verterok> eddyMul: it's seems is broken :(
<Verterok> it's broken against bzr.dev, probably it won't work with 1.0
<eddyMul> Verterok: when I try merging, it kept complaining "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
<eddyMul> which sounds about right
<eddyMul> when I specify the revisions (there are 5 revs) -r1..5, bzr bombs w/ AssertionErrors
<eddyMul> :(
<Verterok> eddyMul: I just found find-merge-base command, it's part of the hidden commands, take a look to that maybe it can help you to find a base revision to merge
<spiv> eddyMul: you can try "-r0..5"
<spiv> eddyMul: also, there's a "bzr join" command, but it's still experimental.
<Verterok> spiv: thx for the r0..x tip :-)
#bzr 2007-12-27
<eddyMul> spiv: that seemed to do the trick
<eddyMul> spiv: now, it's just a matter of moving them around
<eddyMul> spiv: but that's probably the next rev
<eddyMul> (and pending merges shows the revs. I assume this will show up in my logs, too?)
<spiv> Whatever is in pending merges will be recorded when you do "bzr commit", yes.
<eddyMul> spiv, Verterok: I merged it, and moved stuff, and commited it. I'm happy w/ the output of `bzr log`. Thanx, guys!
<spiv> eddyMul: glad I could help!
 * spiv -> late breakfast
<ubotu> New bug: #178813 in bzr "unexpected end of regular expression" [Undecided,New] https://launchpad.net/bugs/178813
<Catfish_Man> hi everyone!
<Peng> What everyone?
<Catfish_Man> well, presumably the people in the channel
<Catfish_Man> there appear to be quite a few
<Catfish_Man> although given that this is irc, I assume most of them are idle
<Catfish_Man> anyway, I was reading up on the "smart server" stuff, but wasn't able to find a whole lot in the way of documentation
<Catfish_Man> is it just a performance optimization? or would it also allow, say, people committing without shell or ftp accounts on the box in question?
<Peng> Catfish_Man: Mostly a performance optimization. I'm not sure how possible or easy it is to do that yet, but it could certainly work.
<Catfish_Man> ok. I'll set it up on my test server then and see if I can get it working
<Catfish_Man> thanks
<ubotu> New bug: #178838 in bzr "Progress bar for annotate" [Undecided,New] https://launchpad.net/bugs/178838
<mathrick> I asked about rebase previously, and I don't have access to logs to see if anyone answered
<mathrick> the question was: rebasing can be used to reshape the commit history into clean "logical" patches, instead of how the devel actually happened, right? If so, how exactly would I go about that?
<mathrick> was there any answer to that?
<GaryvdM> mathrick: There are irc logs here: http://bzr.arbash-meinel.com/irc_log/bzr/
<mathrick> GaryvdM: ah, handy
<mathrick> hmm, no reply, so my question remains open
<mathrick> jelmer: poke with the above question?
<acuster> jelmer, ?
<ubotu> New bug: #178865 in bzr-eclipse "diff error for newly added but not commited files" [Undecided,New] https://launchpad.net/bugs/178865
<ubotu> New bug: #178873 in bzr "IndexError exception when branching into subversion format repo" [Undecided,New] https://launchpad.net/bugs/178873
<jelmer> acuster: hi
<jelmer> mathrick: rebase can be used to "linearalize" history
<jelmer> it does not do things like combine revisions or anything like that
<acuster> hey, jelmer a few questions for you
<jelmer> hi
<acuster> 1) svn;// doesn't seem to work here (possibly because of the server). Is there any advantage to using it rather than http://
<jelmer> svn:// is a different protocol than http://
<jelmer> it only works if the server is running the svnserve application
<acuster> 2) I made a shared repo called gtnew, and did the bzr(-svn) branch so my ~/.bazaar/subversion.conf has a line "locations = file:///soft/BZR/gtnew"
<acuster> do I need to do anything special to rename that dir to gtbranches?
<acuster> (re 1:) right, but is bzr-svn much faster using svn:// or does it not matter?
<jelmer> I think svn:// is slightly faster, but I'm not sure
<jelmer> to bzr-svn there is no difference
<jelmer> the difference is all in the Subversion libraries
<acuster> ok
<jelmer> how did you create the shared repo? It shouldn't be adding an entry to subversion.conf if you create a new shared repo
<acuster> 3) can I reorganize my branches under a shared repository at will? e.g. I have sharedRepo/trunk and I'd like to make sharedRepo/original/trunk so can I just do local unix commands to change that?
<acuster> no, the entry was created when I branched under that shared repo
<jelmer> acuster: Any reason you're branching /into/ a Subversion repository rather than into a Bazaar repository?
<acuster> cd /soft/BZR/; mkdir gtnew; cd gtnew; bzr init-repo --no-trees --rich-root; bzr branch http://svn..../trunk/ .
<jelmer> ahh
<acuster> I must be phrasing things incorrectly
<jelmer> you should be able to simply use mv
<acuster> we have an svn server in canada; I'm trying to use bzr locally
<acuster> ok
<acuster> so do I need to worry about the subversion.conf file at all if I rename the bzr shared-repo directory?
<mathrick> jelmer: I see, git's rebase does allow you to rewrite history in such a way
<mathrick> (rebase --interactive + "squash" and/or "edit" merge directives)
<mathrick> I'd find such a rewriting tool very useful, it allows you to submit changesets with patches that follow the logical order, instead of the chronological and you don't have to expose the intermediate bugs
<jelmer> mathrick: patches are welcome :-)
<mathrick> :)
<acuster> is there documentation for the subversion.conf file?
<jelmer> acuster: not really
<jelmer> acuster: the locations= setting isn't read by bzr-svn
<acuster> cool. Thanks for the help.
<acuster> and thanks, more importantly, for the code :-)
<jelmer> Glad it's useful (-:
 * ddaa just spent one hour setting up eclipse+pydev+bzr
<ddaa> first keystroke in a python file, and it busylocks...
<ddaa> why do all IDEs have to suck soo much?
<__gotcha> has bzr-svn been built as a macport ?
<__gotcha> rather, has a macprot been built for bzr-svn ;-) ?
<ddaa> What is the coding style for imports in bzr? It seems to be a mixture of "from package import module" and "from package.module import definition". I have trouble telling when to use which.
<lifeless> ddaa: its in HACKING
<ddaa> lifeless: thanks
<lifeless> ddaa: and up to the developer using the thing if they want to be doing module.blah or definition; with one caveat
<lifeless> ddaa: things that are deliberatly monke pachable are always the former.
<ddaa> mh, HACKING does not seem to give any specific answer to my question.
<ddaa> I'm trying to clean up the bzr-git code in the way that will make jam most happy (since my code is based on his branch).
<ddaa> although I do have a strong preference for "from package.module import definition"...
<ddaa> I guess, mainly because it's the Launchpad convention.
<lifeless> ddaa: nice, have fun. I'd assume the imports are fine though ;)
<mtaylor> jelmer: I'm having bzr-builddeb issues with it not being able to clean the build area
<mtaylor> jelmer: should I be running bzr-builddeb under sudo ?
<mtaylor> jelmer: bzr branch http://bazaar.launchpad.net/~pkg-sphinx/pkg-sphinx/trunk
<mtaylor> will get you an easily build branch that will break on the clean step
<mtaylor> if it's a problem in my packaging, I'd be happy to fix it - but also I thought you might want to see it if it is a bug
<mtaylor> jelmer: ^^
<mtaylor> jelmer: aha! I think I might know the problem.
<mtaylor> jelmer: the packages I'm building install binaries into /usr/bin as root and stuff... whereas python packages wouldn't have this problem?
<fullermd> Wow, git's arg parsing can't even handle "-ad", but requires "-a -d"?  How lame.
 * mtaylor is really annoyed when people can't parse args right
<mtaylor> it got solved like, 15 years ago for crying out loud - stop re-coding it
<mtaylor> grrr
<fullermd> Well, you never know.  Maybe getopt() is just too slow...
<mtaylor> then maybe someone should fix it. :)
<foom> getopt() is no solution
<fullermd> Interestingly, pre-repack, git loses against bzr packs for storing 1 rev of an import of the YUI library.
<fullermd> (size-wise)
<fullermd> Post-repack, it wins, though.
<fullermd>  11M    yui.knits/.bzr
<fullermd> 7.9M    yui.packs/.bzr
<fullermd> 5.7M    yui.git/.git
<fullermd> (git was ~9.6m before repack -a -d)
<fullermd> It's only one rev, so there's no delta compression to be had.  I wonder what git did with that extra 1.7 meg.  Maybe it uses less compression by default?
<foom> git doesn't just compress between revisions.
<foom> it compresses vs arbitrary other data
<fullermd> Well, yeah.  That's why it wins post-repack.
<fullermd> I'm mildly curious where the pre-repack loss comes from.
<fullermd> (not curious enough to really investigate, of course  :)
<MicahElliott> Is there a good reason I can't branch into an existing dir?  E.g.: bzr branch sftp://path/ .
<MicahElliott> bzr: ERROR: Target directory "." already exists.
<fullermd> It's probably mostly because doing so without some checking would be dangerous, and nobody's bothered to write checking code.
<fullermd> I don't know of anybody objecting to it in principle (though I hardly know everything, or even most things)
<MicahElliott> fullermd: checking what?
<fullermd> That the directory is empty would be sufficient, probably.
<MicahElliott> My use case is managing an existing dir that may already contain a bunch of *un*versioned stuff, like $HOME.
<fullermd> Mmm.  Now that's more likely to raise principle objections.
<fullermd> And requires a lot more checking; it would probably be Wrong(tm) for branch to proceed if there are any filename conflicts, frex, but deciding whether there are can be sticky.
<MicahElliott> Maybe some sort of "clobber" option (desirable in my case) would be useful?
<fullermd> Could be.  It would certainly be shouted down as a default, but...   unusual cases are what unusual options are for   :)
<MicahElliott> I'm not sure what other situations this might arise.  But I'd be surprised if no one here is already managina $HOME with bzr.
<fullermd> Some people are.  I don't think anybody's tried to branch it into an existing $HOME, though.
<MicahElliott> I do seem to have it working.  But it's a bit ugly to have to do the branch to create a new dir and then: cp newdir/* newdir/.[a-zA-Z]* .
<fullermd> You might be able to do a branch into a tree-less repo, mv the .bzr into your homedir, then co the working tree.
<MicahElliott> hmm.  That sounds cleaner.
<fullermd> You'd have to deal with whatever conflicts it causes...
<fullermd> I _think_ it would tend to make the bzr-version the '.moved' variant and leave the existing files with the current name.  'revert --no-backup' would overwrite them, I think.
<MicahElliott> fullermd: I'll play around some more with this.  Thanks for the advice.
<fullermd> (Well, I guess you'd have to fiddle a little bit to get the repo put together with the branch in that case...)
<jelmer> re
<jelmer> mtaylor: I'm not sure. You should be using something like fakeroot, even with bzr builddeb
<jelmer> mtaylor: james_w is the expert though, he may be able to comment on this better
<mtaylor> jelmer: so you think I should be doing "fakeroot bzr bd"
<jelmer> I'm not actually sure
<jelmer> "bzr builddeb" has "just worked"[tm] for me
<mtaylor> ok. :)
<mtaylor> well, I tried a small little patch to builddeb that tries shutils.rmtree() and if that fails tries sudo rm -rf
<mtaylor> which now works for me :) but I'm sure is not the "right" way to do it
<bob2> builddeb should have a -r option like debbuild
<jelmer> bob2: I think it already does something
<jelmer> since I don't have to specify anything or configure anything
<jelmer> I'm sure at least one of my packages runs dh_checkroot
<mtaylor> I have some packages that build fine and some that give me this problem
<bob2> do they build ok under dpkg-buildpackge -rfakeroot?
<mtaylor> yup
<mtaylor> but the clean that's failiing here has nothing to do with dpkg-buildpackage
<mtaylor> it's a clean of the build area
<mtaylor> perhaps builddeb needs to do a debian/rules clean before it cleans the build area?
<mtaylor> so that it can let dpkg-buildpackage invoke fakeroot/sudo as needed for the clean?
#bzr 2007-12-28
<mtaylor> jelmer, bob2: aaaaah... I think that this all be my fault.
<mtaylor> I've been building with -rsudo in my .devscripts
<mtaylor> instead of -rfakeroot
<jelmer> ahh, that would explain it (-:
<mtaylor> yup. that was it. I fixed that and all is now well.
<mtaylor> stupid root privileges
<jdrake> I have just registered a project on launchpad, and I am trying to figure out how to push the code I have just imported into it. I am not seeing any documentation  that leads me in the right direction.
<Peng> You could register a branch on LP.
<fullermd> Actually, I thought you pretty much just pushed, and it created it on the fly.
<jdrake> It appears /~username/Project/trunk  will work
<ddaa> jdrake: https://help.launchpad.net/FeatureHighlights/EasyBranching
<dlee> Easiest way to submit minor typo corrections to Bza docs?  And thanks MUCH for this tool...I'm trying to talk my company into using it instead of CVS or SVN.
<dlee> Lol... and I type Bza for Bzr while asking how to fix typos... :P
<Kamping_Kaiser> at a guess file a bug in launchpad. someone may have a better idea though
<Peng> I always just send a patch to the mailing list.
<Peng> (bundle)
<Peng> WTF?
<Peng> I have a "bzr push" from the 25th using 100% of one CPU core.
 * Peng hits Ctrl+C.
<Peng> real    3892m35.171s
<Peng> user    296m58.803s
<Peng> sys     3575m18.538s
<Peng> :)
<Peng> I see a push in .bzr.log. The last thing logged is "ssh implementation is OpenSSH".
<Peng> Remote probably got killed.
<Peng> while autopacking.
<Peng> Why exactly is that an excuse to deadlock?
<Kamping_Kaiser> nice
<lifeless> eek
<Peng> Huh, the packs autopack combined weren't all in chronological order. It left some behind.
<Peng> It combined the 60 MB pack, but not the 70 KB one. :\
<Peng> Since this was over SFTP, that's very nice...
<lifeless> is the 70kb pack in the pack-names file?
<Peng> Yes.
<Peng> 9 packs, 9 listed in pack-names. I didn't check if they are correct, except for that one..
<lifeless> k
<lifeless> night
<Peng> ...Night.
<blauwal> join #oooscm
<Verterok> moin
<sabdfl> howdy
<jelmer> Hi Verterok, sabdfl
<sabdfl> hey jelmer, compliments of the season to you
<jelmer> sabdfl: Thank you, and likewise :-)
<Verterok> hi jelmer
<aadis> anyone having luck with trac-bzr?
<Verterok> aadis: which branch are you using?
<aadis> there are so many
<aadis> can you recommend one?
<aadis> i get this: TypeError: can't compare datetime.datetime to float
<Verterok> aadis: try with tim hatch branch
<Verterok> aadis: which version of trac?
<aadis> 0.11dev
<aadis> 0.11b1
<Verterok> yes, tim hatch branch is ok
<aadis> okies.
<Verterok> it should work with a small change in backend.py
<aadis> Verterok: http://timhatch.com/projects/trac-bzr/ right?
<Verterok> let me check
<radix> ah, when distributed development goes wrong :P
<Verterok> aadis: https://code.launchpad.net/~timhatch/trac-bzr/thatch-dev
<aadis> radix: heh, i can almost see some of the problems.
<aadis> there must be, what, 10 branches of trac-bzr, and no way to figure out which works
<foom> hm, trac-bzr...anyone have a running instance they can point me to?
<radix> http://bazaar-vcs.org/TracBzr has some links
<foom> thanks
<Verterok> foom: I have an outdated trac-bzr running with trac-0.10 at: https://trac.steppenwolf.selfip.net/bzr-eclipse/
<foom> no branch support?
<radix> apparently aaron bentley's version supports multiple branches
<radix> but I don't know where there's an example
<Verterok> aadis: once you get the code, in backend.py add/define a top level/global variable: version = '0.2'
<aadis> okies
<Verterok> radix, foom: I think marienz-dev branch also supports branches
<foom> i'm not gonna install any, I just want to see one someone else has. :)
<Verterok> an exmample here: http://www.pkgcore.org/trac/pkgcore/wiki/Branches
<aadis> Verterok: thanks! :)
<foom> ah, thanks.
<Verterok> aadis: np ;-)
<dato> hm, is it me or james_w hasn't been around for a while?
<aadis> Verterok: and it works! mucho gracias.
<aadis> it was a pain to see the latest commits otherwise
<Verterok> aadis: great! de nada ;-)
<aadis> though trying to view a changeset says this: TypeError: format_to_html() takes at least 3 arguments (2 given)
<Verterok> ups, that is a new one :P
<aadis> looking into it
<aadis> Verterok: turning off property renderer works, since the block is inside "if has_property_renderer". so that's a workaround.
<Verterok> nice, at least it's working :-P
<aadis> indeed!
 * Verterok thinks that maybe it's time to start filling bug reports against trac-bzr 
<BasicOSX> grrr
<BasicOSX> Colloquy crashed
<Verterok> seeya guys, I'm leaving for the weekend.
<aadis> BasicOSX: was it after a suspend on leopard? I see colloquy doing that when i come back from suspend
<BasicOSX> yes
<elmo> if I have a master tree, now at r990.  and someone has a branch at 980 or so, which they then made 3 changes to.  how do I see just those diffs?
<elmo> bzr missing --theirs-only kinda does the right thing, except without the diff part
<fullermd> You probably want a construct like -rancestor:their/branch..branch:their/branch
<jelmer> One way would be bzr diff -r980.. in "their" branch would probably work
<fullermd> Easier would be to go into a copy of theirs and -rancestor:yours..
<luks> bzr diff /path/to/branch1 /path/to/branch2
<luks> but I think this doesn't work with bzr.dev anymore
<elmo> luks: that definitely doesn't work
<elmo> fullermd: yours seems good
<luks> it should in 1.0
<fullermd> Well, it "works", but it doesn't show what he wants.
<elmo> oh, I'm in 0.92 or something, it's some random Debian box running something from 1999
<fullermd> Oh, so it's the Debian bleeding edge?   ;>
<luks> oh, right, I misread the question
<luks> I'd personally just do `bzr send -o- | less` :)
<elmo> oh, yay, we have bzr diff -c now \o/ thank you whoever implemented that
<fullermd> Absolutely.  It's such a small thing, but it makes it SO much easier to step around...
<dato> +1
<dato> though I wrote myself in the early days a plugin to make -r X work like -c X works now, and now I can't teach my fingers to type -c instead of -r :(
<mtaylor> jelmer: feature request for bzr-svn... if I'm doing an svn-import, and it gets interrupted and I have to restart it, is there any way it can pick up where it left off?
<mtaylor> jelmer: I'm doing an import over the wire of 8394 revs, which took 3 hours to get to 5536... at which point the network went away :(
<mtaylor> jelmer: OH
<mtaylor> hey, look at that
<mtaylor> jelmer: nevermind... it's already doing that. you ROCK
<fullermd> He's real quick with those feature requests   ;)
<mtaylor> no kidding
<jelmer> mtaylor: (-:
#bzr 2007-12-29
<abentley> ddaa: How goes?
<ddaa> hello
<ddaa> well, I'm on leave
<ddaa> been poking around with bzr-git
<ddaa> managed to get a simple blackbox test "bzr log" working
<ddaa> now I'm kind of stumped trying to get "bzr pull" to work
<ddaa> it seems a lot of stuff needs InventoryEntry.revision to be set
<ddaa> but bzr-git cannot easily set this to a meaningful value
<ddaa> okay... it seems just using the current revision might work
<ddaa> now need to find the text sizes...
<abentley> I messed around with bzr-git a long time ago.
<abentley> Watch out for the hashes; AFAICT, they are *not* the fulltext sha1s.
<ddaa> ew
<ddaa> thanks
<ddaa> thinking of it, that makes sense
<ddaa> they are the hashes of the git representation, not of the data itself
<abentley> Also, I don't know if bzr-git still uses the quilt "bindings", but you're better off writing your own, a la pybaz.
<ddaa> I'm working on jam's branch
<abentley> Ah.
<ddaa> it does not depend on stgit anymore
<abentley> Ah, stgit.  Sorry.
<ddaa> a couple of days ago, I tried to make a transparent git:// transport
<abentley> I've just implemented a new merge algorithm that should match beat weave merge on criss-cross, and equal three-way the rest of the time.  I'm very excited.
<ddaa> now, I'm pretty sure it cannot be done in the current state of git
<abentley> ...match *or* beat...
<ddaa> that sounds really cool
<ddaa> one merge to rule them all :)
<abentley> Oh, absolutely.  Merge should Just Work to the maximum extent possible.
<ddaa> at least a git:// transport would require reimplementing all the git client code
<ddaa> so it does not depend on the existence of a local .git directory :(
<abentley> Yikes.
<abentley> What about treating remoted gits as a kind of smart server?
<abentley> btw: http://code.aaronbentley.com/bzr/bzrrepo/lcamerge if you're interested.
<ddaa> vanilla git servers pretty only know how to transfer packs
<ddaa> as far as I can tell, it works like in a rsync-like manner
<ddaa> first there's a negotiation phase where client and server determine what objects are needed
<ddaa> then the server builds a pack and sends it over the wire
<ddaa> the problem is that all the existing git code just work off filesystem structures
<ddaa> and has nice things like hardcoded exit() calls...
<abentley> tla, how I haven't missed you ;-)
<ddaa> exactly :/
<ddaa> also, all the code assumes that sockets can be used as file descriptors
<abentley> It sounds like a tough problem.
<ddaa> so it just cannot work on win32
<abentley> Is this hacking launchpad-related?
<ddaa> no, that's off hours hacking
<ddaa> sounds like a lot of trouble, so I just gave up on this for now
<ddaa> local bzr pull would be nice enough
<abentley> What can bzr-git do these days?
<ddaa> run bzr vis :)
<ddaa> but now it has some tests
<abentley> That's it?  Still?
<ddaa> it cannot even display diffs
<abentley> I'm pretty sure my branch could do checkouts.
 * ddaa tries
<foom> ddaa: couldn't you just invoke git to download the data onto the local drive and then manipulate from there?
<ddaa> foom: that's the line I'm exploring now
<foom> ddaa: sounds sensible. :)
<ddaa> but that means the data has to be duplicated on disk, that's less than ideal.
<foom> yeah, but at least you don't have to rewrite git.
<ddaa> ideally, all you'd need to do would be "bzr branch git://foo", like bzr-svn does.
<ddaa> abentley: my branch cannot do lightweight checkouts
<ddaa> but OTOH I pretty much rewrote all of your stuff already
<ddaa> you should have written some tests :)
<abentley> lifeless didn't!
<abentley> Why should I start?
 * ddaa looks up despair.com
<ddaa> That one would do
<ddaa> http://despair.com/tradition.html
<fullermd> I love their mug.
<abentley> lol
<abentley> One nice thing about git is you should be able to do really fast tree comparisons.
<ddaa> it's not clear that bzrlib will make this any easy
<ddaa> building a proper inventory pretty much requires building the whole tree
<ddaa> I'm planned to use "git archive" to write a tarball to a pipe, and then process it incrementally.
<ddaa> that seems to be the only way to get multiple text_size in a single git call
<ddaa> pyarch taught me that if you are naive with CLI bindings, you get to pay excessive process spawning costs
<ddaa> the unix-scripting model does not play well with object orientation
<abentley> ddaa: I would expect you can implement _iter_changes without too much API friction.
<abentley> We are working hard on making the inventory itself go away.
<abentley> From the public API, I mean.
 * fullermd is looking forward to inventory reworks.
<ddaa> what is _iter_changes useful for?
<abentley> diff, merge, status, etc.
<ddaa> that's a RevisionTree method?
<abentley> Yes, a Tree method.
<abentley> It is implemented on InterTrees, so it can be specialized for particular tree types.
<ddaa> this interstuff is still a bit magic to me
<ddaa> I get the general idea though
<ddaa> double-dispathc
<abentley> Right.
<ddaa> time to go hack this TarFile thing
<abentley> Happy hacking!
<mtaylor> bzr: ERROR: mismatched lock context and write group.
<mtaylor> aroo?
<mtaylor> jelmer: ^^ I got that doing a bzr svn-import
<abentley> Wow, I've never even heard of that one.
<jelmer> mtaylor: that has been fixed in the 0.4 branch
<mtaylor> jelmer: hrm. and here I thought I was using 0.4 :(
<mtaylor> jelmer: 0.4 is the one that goes with bzr 1.0 right?
<jelmer> no, that's 0.4.5
<jelmer> 0.4 is a bzr branch
<jelmer> the fix is not in any release
<mtaylor> ah. ok
<mtaylor> hehe
<mtaylor> Repository KnitRepository  is not compatible with repository KnitRepository
<mtaylor> :)
<jelmer> abentley: happens if you close a write group that has already been closed
<jelmer> mtaylor: you need a rich-root repository
<abentley> jelmer: Ah.
<abentley> lifeless really should have made sure the repr still distinguished between those types.
<mtaylor> and it would be great if the error messages mentioned the type of repos like "rich-root" instead of the class name...
<mtaylor> as the mapping is not always evident
<jelmer> yeah, we need to fix that
<jelmer> I actually said I was going to send in a patch for that
<jelmer> but haven't gotten round to it yet unfortunately
<mtaylor> I have a long list of similar items
<jelmer> mtaylor: what sort of items?
<mtaylor> not for bzr... just a list of patches I need to add to things that I haven't gotten around to
<jelmer> ah :-)
<mtaylor> sorry ... english broke on me there. :)
<ddaa> grmbl
<jelmer> hey ddaa
<ddaa> tarfile generated by git causes TarFile to try to seek backwards at some point...
<jelmer> how's bzr-git going?
<ddaa> mh... I think it's actually a case of "oops, int overflow"
<jelmer> ah, having fun \o/
<ddaa> trying to efficently extract data out of this git thingy
<jelmer> it uses tar internally??
<ddaa> I've been told it's fast, so I'm reluctant to spawn it for. every. single. inventory. entry. to get the text_size and sha1
<ddaa> and it seem the only way to get it to spit multiple files at once is using git-archive
<jelmer> could you make text_size and sha1 properties and do lazy evaluation?
<ddaa> that produce a tarfile on a pipe
<ddaa> mh
<jelmer> mh ?
<ddaa> would that really be a gain?
<jelmer> In some situations, yes
<ddaa> The issue is that I would like bzr pull to work somewhat efficently
<jelmer> ok, no point in that case
<ddaa> and I GUESS it will have to check every single inventory entry
<ddaa> I'm already going to spawn "git cat-file" once for every file
<ddaa> I'd rather not do it twice...
<jelmer> heh, oops
<ddaa> kind of weird though that tarfile ends up with a stream pos of 2315264L
<jelmer> no performance improvements by using bzr-git then?
<ddaa> git is heavily fs-based
<ddaa> it does not play nice with object-based bzrlib
<jelmer> bzr-svn can in some rare situations actually be faster than bzr native
<ddaa> in this sense, svn is probably less hostile
<jelmer> bbl
<ddaa> in that it actually tries to be a library
<mtaylor> jelmer:
<mtaylor> oh crap
<mtaylor> he's gone
<mtaylor> I tried the most recent bzr-svn from 0.4
<mtaylor> and now I'm getting:
<mtaylor> NoSuchId: The file id "7924@3c33494c-61f7-0310-86b9-b90697347e9d:branches%2Fdevelopment-2.0:server%2Fmerlin%2FWEB-INF%2Fsrc%2Fcom%2Fmysql%2Fetools%2Fscratch" is not present in the tree <Inven
<mtaylor> etc.
<ddaa> jelmer: it seems like spaces are not allowed in file ids, is that right?
<ddaa> I mean, is that correct?
<abentley> ddaa: I can't remember.  It doesn't seem like a good idea, at least.
<mtaylor> how would they have gotten in the file id though?
<ddaa> because I'm defining the file ids
<ddaa> using the file name as a file id
<hunmonk> anybody know when the fink port is going to get some love??  http://pdb.finkproject.org/pdb/package.php/bzr-py25
<hunmonk> it's still at 0.18  :(
<mtaylor> ddaa: so does that mean I'm just screwed if I've got spaces in file names here? I know I've got those elsewhere?
<ddaa> don't worry
<ddaa> normally bzr generate random ids
<ddaa> my problem is specific to my own hacked up experimental branch of bzr-git that eats little kittens at breakfast.
<mtaylor> so it's just a bzr-svn issue then? ah...
<ddaa> not at all
<mtaylor> I thought you were commenting on my error from above?
<mtaylor> :(
<ddaa> I don't pretend to have a clue about debugging bzr-svn
<ddaa> I have looked just enough at the code to realize how complicated it is.
<mtaylor> it works in an amazingly diverse number of situations
<ddaa> wow! I got bzr pull to actually do something
<mtaylor> w00t!
<ddaa> now I need to find a way to avoid marking every file modified at every revision
<ddaa> that might help storage efficiency a bit, I guess
<ddaa> mh... passing bzr check would be a first step
<ddaa> w00t
<ddaa> well, it seems like the tarfile approach does not work... for some reason yet unknown
<lifeless> abentley: lol; I wrote the core of bzr-git at europython between ddaa's and my talk, and the lightening talks that afternoon
<ddaa> hey
<ddaa> I hate that bzrlib cannot guess the revision of an InventoryEntry
<ddaa> I just want to stuff it the file data, and leave it to find where it was introduced.
<abentley> lifeless: And bzr-hg?  Did you write tests for that?
<lifeless> abentley: some I think
<lifeless> abentley: my initial goal was to bring up enough stuff that the interface tests kicked in; but they were at the time very hostile to non bzr native things
<lifeless> not much less hostile now I suppose
<abentley> Hehe.
<abentley> Are you enjoying the time off?
<lifeless> yah
<lifeless> until I got net a couple days ago I hadn't thought code for nearly a week
<lifeless> totally different mind set
<lifeless> and I'm trying not to get into it now either; I am helping squid migrate to bzr though ;)
<lifeless> we should change this message
<abentley> Risky business, that.
<lifeless> bzr: ERROR: Tags not supported by BzrBranch5('file:///home/robertc/source/baz/plugins/bzrtools/ab-trunk/'); you may be able to use bzr upgrade --dirstate-tags.
<abentley> Actually using bzr for other things tends to bring the urge to tweak it.
<lifeless> migrating or thinking ?
<abentley> Both, I guess.
<lifeless> http://wiki.squid-cache.org/Squid3VCS
<abentley> Why are you branching and binding rather than checking out?
<lifeless> IIRC checking out there will create a tree
<abentley> Ah, so treeless bound branches actually have some value for you.
<bagueros> join #cake
<abentley> lifeless: I see you mention "bzr patch", but I don't think you mention installing bzrtools.
<abentley> lifeless: Also, I now have "merge --preview" working locally.
<lifeless> nice!
<lifeless> a -r spec sounded like a great way to present it
<lifeless> I can imagine bzr diff -r merged:../trunk
<ddaa> lifeless: remind me what revision of a directory entry should be?
<abentley> It does, but it doesn't really leave room for listing file conflicts, so I've just gone with merge --preview for now.
<lifeless> ddaa: its in the docs; don't want to think too hard bout work stuff right now
<abentley> I think it's more important to specify merge type than diff type, too.
<ddaa> docs?
<lifeless> abentley: this is a use case for diff and status being on deltas not against wrking trees - then conflicts can come up naturally for this :)
<lifeless> anyhow
<lifeless> I'm off for now
<lifeless> ciao
<abentley> ciao
<jelmer> bye
<Peng> What's that thing called that's like a redirect, where a file tells bzr to look somewhere else? How can I create one, and is it worth using it over an HTTP redirect?
<Peng> Is no-working-trees relevant in a non-shared repo?
<acuster> hey all, is there any tool to see the size of the changes in the various revisions?
<bob2> what sort of format?  bzr diffstat (from the plugin of the same name) might be what you're looking for
<dato> ok, bzr 1.0 uploaded to backports.org for etch
<acuster> bob2, thanks. will look into that.
<acuster> I guess I'm trying to see the size of each commit
<acuster> so I can identify the commits where some massive files were dumped into the repo
<dato> if in a repository I want to change the mtime of actual files in the tree to that of the latest revision that touched them, can somebody give me a crash course how to find that information for each file?
<dato> Peng: echo "Bazaar-NG Branch Reference Format 1" >.bzr/branch/format
<dato> Peng: Peng echo -n "http://url.com/path/to/the/other/branch" >.bzr/branch/location
<dato> Peng: the sole advantage would be that after people branch from that location, next time they pull they would go directly to the referenced branch, not the original one
<Peng> dato: Clients use the new URL?
<dato> yes, the new url is storead as parent_location, from what I've seen
<dato> so the behavior is quite different from an HTTP redirection
<Peng> Might not be a bad idea to update parent_location for HTTP permanent redirects too...
<Peng> Which version was the reference format introduced in? Do any other files need to be in branch/?
<dato> only those two afaik, but remember .bzr/branch-format as well
<Peng> Right.
<Peng> Haha, nice. I need a \n at the end of format but not at location.
 * Peng notices that dato's example followed that.
<dato> :)
<acuster> The descriptions on the bzr plugins page could be a tad bit more complete.
<Peng> Blah, I'll stick with an HTTP redirect.
<Peng> It's not like anybody has copies of my branches anyway. :)
<Peng> Thanks for you help, dato.
<dato> np
<acuster> jelmer, around?
<jelmer> acuster: hi
<acuster> hey
<acuster> just tried doing my first push to the svn
<acuster> which consisted of adding two comment markers to one file
<acuster> it's taking a long time and sending lots of data so I presume I'm doing something wrong
<acuster> should I be able to do just: bzr push http://svn.geotools.org/geotools/trunk/gt ?
<acuster> if I am in the trunk/gt directory locally
<acuster> actually, in the working/gt directory locally
<jelmer> acuster: It can only push full branches, not parts
<jelmer> acuster: What is your branch of locally?
<acuster> I branched trunk
<acuster> then locally branched to make a working
<acuster> then did a checkout
<acuster> commited to the checkout
<jelmer> in that case, you should be able to push to http://svn.geotools.org/geotools/trunk
<acuster> and want to push back up
<acuster> do I have to be in trunk/ locally as well?
<jelmer> no
<acuster> tanks
<jelmer> trunk/gt would be fine as well
<acuster> thanks
<acuster> is this a really expensive operation? If so, is it only expensive the first time?
<jelmer> depends on what its saying
<jelmer> it may well be expensive the first time if you have a lot of other branches
<acuster> two branches locally only
<acuster> seems like a lot is going over the network
<jelmer> acuster: no, I mean in Subversion
<acuster> bzr doesn't remember that it came from that same source?
<jelmer> Does the Subversion repository contain any other branches?
<acuster> ah, yes, the Subversion is a total mess
<jelmer> in that case, it could be a bit slow the first time
<acuster> thanks
<jelmer> but a lot faster after that
<acuster> I'm very worried about hurting the svn
<acuster> since it's delicate and being used by several groups for production
<jelmer> you can run with -Dcommit -Dtransport to see what its doing
<jelmer> (it will write info to ~/.bzr.log)
<acuster> Thanks!
<jelmer> time for another talk
<jelmer> back later
<acuster> ciao
<acuster> jelmer, when you get back: The FAQ looks out of date for 1.0 re how to upgrade a repo. You should probably mention the 'rich-root' meme to match bzr 1.0's 'bzr help upgrade' info.
<jjensen> Hi.  I'm on WinXP with Bazaar 1.0.  When I run bzr checkout bzr://localhost:9500/branch, I get the error message: bzr: ERROR: socket.error: (10055, 'No buffer space available').  Any ideas?
<jjensen> There are 2 revisions in the repository.  The first is 73,975,380 bytes.  The second is 5,972,504 bytes.
<jjensen> bzr checkout --lightweight does work, but I want the history locally.
<fullermd> I think there was some issue with the bzr protocol and large socket buffers that blew up Windows.
<fullermd> Using a dumb transport like http or sftp should fix it.  It may be fixed in the dev head (to be 1.1) or not; can't remember.
<acuster> why does bzr report files including the working directory? It breaks the standard unix cut/paste of dbl click on the file name; middle click to paste
<ddaa> it usually does not, here
<jjensen> fullermd: Hmmm... I was hoping to set up nothing more than the smart server.  I'm behind https with client authentication.  I haven't tried bzr to see if it supports client certificates.  Mercurial does not.
<ddaa> paset the command you used and its output, please
<jjensen> Maybe I'll try to build dev head and see what happens.
<acuster> oh, I get it; it's reporting the file name from the root of the tree not from the working directory
<ddaa> acuster: right
<acuster> hmmm
<ddaa> I believe most commands can be restricted to the current subdir
<ddaa> if you add "." at the end of the command line
<fullermd> jjensen: Yeah, try that.  You don't need to actually install it; you can just branch it and run it out of its branch dir.
<fullermd> It'll still show paths relative to the root.
<acuster> it's too bad --- a tiny slowdown in workflow; I wonder if it's fixable
<acuster> maybe I'll understand enough later to make a suggestion
<dlee> Shared repos a la init-repo save space if what's under them are branches of one project.  Any gain (other than shorter URLs) for putting multiple projects in the same source language under one such repo--i.e., init-repo .../hub, init .../hub/proj1, init .../hub/proj2, ...?
<dlee> I won't often need multiple branches per project, and those could be .../hub/proj1.exp1 and the like.  I'm also wondering how to list branches under a shared repo, but I bet I missed something simple there.  I'm just starting with Bazaar, but with much enthusiasm, coming from years of CVS and a bit less time with Subversion.
<ddaa> you won't gain anything by putting multiple unrelated branches in the same repo
<dlee> Will I lose anything (space or efficiency)?
<ddaa> Not sure, you might lose a bit of efficiency.
<ddaa> To get all the branches in a repo, you can use "bzr branches" from bzrtools
<ddaa> though it does not work with all transports
<fullermd> You'll lose a little, from having bigger indices etc. to search through.  Unless they're rather large projects, you probably won't notice.
<ddaa> Generally, a repository does not know of the branches it contains (so you can rename branch with just "mv"). The "bzr branches" command basically does something like "find -type d -name .bzr", so it requires a listable transport, and can be rather slow.
<ddaa> typically, http is not listable (unless the server supports webdav).
<ddaa> jelmer: can I reuse inventory entries among inventories?
<ddaa> I mean, can I assume that bzrlib will not modify my inventory entry objects?
<dlee> I look forward to nested trees. :)  Projects are small, but there are many of them.
<dlee> I guess I'll try bzr init-repo --no-trees .../hub (actually .../var/bzr) and then bzr init repos under it just so everyone can create projects with a simple bzr init, or leave /var/bzr empty and do bzr init-repo /var/bzr/proj1 + bzr init /var/bzr/proj1/main etc. for each project--but the latter will look like overkill to the version-control-uninitiated around here :)
<jjensen> fullermd: Sadly, with bzr 1.1.0.dev.0 on python 2.5.1.final.0 (win32), I still get error: (10055, 'No buffer space available').  :(
<jjensen> But it is nice that bzr head works out of the box like that without installing any extra Python modules.
<jjensen> As a possible alternative, is there a binary build of bzr-svn I can download?
<jelmer> re
<jelmer> acuster: thanks
<jelmer> acuster: that has already been fixed in 0.4, will be updated for 0.4.6
<jelmer> ddaa: not that I know
<ddaa> that's okay
<ddaa> I think I found a correct and reasonably efficient way to compute entry.revision without involving a monster inventory cache.
<juh> How to report an issue in documentation?
<jelmer> juh: Please file a bug on launchpad - http://launchpad.net/bzr
<juh> ok
<ddaa> jelmer: so, I have got a super-experimental bzr-git that looks like it can actually pull
<ddaa> how do you think I should release this without have innocent users start to use it for real work?
<jelmer> ddaa: w00t \o/
<jelmer> ddaa: sure, as long as there's the usual warnings about eating your cat, etc.
 * jelmer would be happy to do testing
<jelmer> is there a testsuite?
<ddaa> I mean, what's the best in-your-face way to put those warnings?
<ddaa> jelmer: the pull stuff is not tested
<ddaa> it's pure binge hacking
<jelmer> ddaa: in the README and the announcement I'd say
<ddaa> there is a embryonic test suite that covers stuff up to "bzr log"
<juh> jelmer: done
<jelmer> juh: thanks!
<Peng> Prompt three times with caps lock and lots of exclamation points before doing any command. :)
<Peng> Also, adding a GTK+ bit to do big flashing red text would be good.
<ubotu> New bug: #179292 in bzr "Wrong order of new branch command in Quick Start Guide" [Undecided,New] https://launchpad.net/bugs/179292
<lifeless> ddaa: rev the namespace
<lifeless> ddaa: in particular if you think you might not be 'done' use an experimental namespace
<lifeless> ddaa: /win 17
<jelmer> ooh, lifeless has knowledge about David's irssi windows?
<lifeless> no
<ddaa> in lifeless's world, everybody uses irssi :)
<lifeless> I would like to see the common bits of cvsps-import, bzr-hg and bzr-git commonalised
<lifeless> and bzr-svn for that matter
 * ddaa forces himself to stop tweaking and release the code
<ddaa> jelmer: https://code.edge.launchpad.net/~ddaa/bzr-git/bzr-git.pull
<ddaa> That's announcement enough, I think. Feel free to point other interested hackers to it.
<ddaa> At this point, I think it needs an InterRepository to stop the memory use from growing too much.
<hsn_> bazaar 1.0 with packs safe to put into production?
<jelmer> ddaa: Thanks!
<jelmer> I'll give it a try
<ddaa> Now, I'm going to remove some of the cruft that accumulated in the past 24 hours of binge hacking.
<acuster> jelmer, the FAQ has been fixed? /me was talking about: http://bazaar-vcs.org/BzrForeignBranches/Subversion/FAQ
<jelmer> ah, ok
<jelmer> that's just an online copy of the FAQ in the branch
<jelmer> I should move the bzr-svn homepage away from the wiki at some point so I can automate it
<acuster> ah, then it just needs a bump, should be easy
<jelmer> and no longer have to update those pages manually
<jelmer> or perhaps editmoin could support uploading wiki pages at some point >-)
<lifeless> hsn_: sure is
<lifeless> jelmer: you can automate changes to the wiki
<lifeless> jelmer: its just a trivial post
<jelmer> lifeless: sure, but scripting that is more work than running rst2html on samba.org
<lifeless> jelmer: or perhaps just make the wiki page into a redirect to the codehosting source browser ? :)
<jelmer> well, that doesn't do rst rendering yet :-/
<jelmer> anyhow, time for the hacker jeopardy
<jelmer> back later
<jelmer> lifeless: btw, I don't know what the experimental flag in BzrDirFormatInfo is used for
<jelmer> but it's still set to true for some of the packs formats
<jelmer> (in bzrlib/bzrdir.py)
<lifeless> jelmer: its ui fluff
<ddaa> what's funny with self-hosted VCS
<ddaa> is that you can be pretty sure that the self-hosted repo is going to contain a large sample of the interesting corner cases :)
 * ddaa has just been bitten by having to escape control chars around revno 3000 in the git repo.
<hsn_> packs format seems to use lot of CPU power
<ddaa> interesting factoid from #git
<ddaa> apparently the die() call can register handlers
<ddaa> so it's possible to recover from die() using longjmp()
<ddaa> cehteh did so
<fullermd> I usually need to recover from longjmp()   :p
<lifeless> ddaa: you may recover but have malloc structures inconsistent
<lifeless> ddaa: which is to say, you may 'recover'
<ddaa> apparently, git uses malloc in unusual ways
<lifeless> this does not surprise me
<ddaa> only for large allocations (presumably mmaped), and then uses custom allocators
<ddaa> lifeless: how does longjmp() cause inconsistent malloc structures?
<lifeless> longjmp doesn't
<fullermd> But presumably die() could be called from messy places, like signal handlers.
<ddaa> *shrug*
<ddaa> as a sidenote, cehteh confirmed my impression that we'll likely need to reinvent a lot of wheels if we want to have a git:// transport that works without local git data.
<lifeless> shrug
<lifeless> I don't really care if we need local git data or not
<lifeless> can always use a cache and discard after the operation
<ddaa> I mean, "not a full git repository"
<ddaa> Maybe we could use a temporary, shallow .git, but it's unclear that git can support this.
<lifeless> anyone know turbogears here?
<lifeless> https://edge.launchpad.net/squid/3.0/+source needs a 'register branch' link as well as 'choose existing'
#bzr 2007-12-30
<ubotu> New bug: #179314 in bzr "bzr reconfigure ctrl-C errors inappropriately" [Undecided,New] https://launchpad.net/bugs/179314
<ubotu> New bug: #179316 in bzr "bzr reconfigure is not order-safe" [Undecided,New] https://launchpad.net/bugs/179316
<lifeless> ddaa: what does 'remote' mean for branches ?
<ddaa> lifeless: context?
<lifeless> lp
<lifeless> https://code.edge.launchpad.net/~lifeless/squid/squid3-trunk
<ddaa> not copied on vostok
<lifeless> oh foo
<lifeless> what do I have to change to make it 'mirrored' and wouldn't 'not-mirrored' or 'reference-only' or something be clearer ?
<ddaa> either 1. edit branch details 2. if that does not work delete the branch 3. if that's not desirable ask an admin to poke the db
<lifeless> I was meaning what db values :)
<lifeless> branch details does not have a field for remote/mirror
<ddaa> the should be a Branch.type column or somesuch now.
<ddaa> with corresponding BranchType in c.l.i.Branch
<ddaa> about the naming, I guess it would be better yes
<ddaa> file a bug :)
<ddaa> there's an annoying failure mode of changing the branch type in the UI that prevented from enabling it
<ddaa> hosted -> mirror -> hosted can have unexpected effects
<lifeless> don't have to allow all
<lifeless> just allow mirror/remote
<ddaa> sure
<ddaa> sure... remote came up after that was considered
<ddaa> not sure if it makes sense to allow as well
<ddaa> since we should also delete data on mirror->remote
<ddaa> unless the various front-ends just ignore remote branches
<ddaa> then it should be okay, I think
<lifeless> how do I tell it to mirror ?
<lifeless> https://code.edge.launchpad.net/~lifeless/squid/squid3-trunk
<lifeless> (next mirror: disabled)
<lifeless> found it
<lifeless> ok thanks
<abentley> lifeless: just saw your bug report.  Am very surprised that reconfigure would delete the repository if fetch failed.
<lifeless> abentley: it may have just scribbled over the branch but left the repository intact
<lifeless>  ls .bzr/
<lifeless> branch  branch-format  branch-lock  checkout  README  repository
<lifeless> either way though, the target should be fully prepared before the local tree is altered I think
<abentley> Ideally, the whole thing would be atomic.
<distatica> Hey folks, I am following the mini tutorial. Everything worked great up until I pushed to my server. The directory gets created in the right place, however there are no files. I have created and modified the file locally, commited it (twice), and pushed it three times now, no files still.
<distatica> using sftp provided by openssh server.
<lifeless> distatica: if there is a .bzr directory it has worked
<distatica> there is no directory
<abentley> distatica: push isn't supposed to create any files.
<lifeless> distatica: your editable files are not created on push
<distatica> oh wait, there is too
<distatica> ohh
<distatica> so where are the files stored? Always locally?
<abentley> The files are always local, for whatever machine bzr is running on.
<distatica> oh, so if I switch to another computer then there's no way to get the files, without having them uploading seperately?
<distatica> sorry, I'm used to SVN, I usually hope between computers and use it and my server for moving between machines. But there's some things I don't like about the subversion setup. It's harder ot make multiple projects for one.
<distatica> erm, hope == hop
<abentley> If you switch to another computer, you'll branch from a remote copy.
<Peng> distatica: All of the data is stored in the .bzr directory.
<abentley> That will download everything you've committed, and recreate the working files from the committed data.
<distatica> heh, I'm trying to see how this works, but I get an unknown branch format using the debian stable binary
<distatica> debian etch*
<Peng> distatica: You're using 1.0 on your other machine?
<distatica> 0.11.0
<Peng> Dude.
<Peng> That's like 75 years old.
<distatica> lol
<distatica> I don't doubt it, I think my grandfather worked a bit on etch packages.
<distatica> I'm installing the one from the site now.
<distatica> I was just trying to test it quickly
<Peng> The two current repo formats were introduced in 0.15 and 0.92. I'd be kinda surprised to find a branch in the wild that was compatible with 0.11.
<Peng> (0.15 is only from April, but still.)
<abentley> Peng: "dirstate" used the same branch and repo format as "knit", so they were network-compatible with bzr back to 0.8.
<distatica> Is there anything like trac (or a plugin for trac) for bzr? Or at least some other way to browse the source through a browser (prefer with syntax color)
<abentley> It was only with "dirstate-tags" that we broke compatibility with older-than 0.15
<Peng> abentley: Oh, ok.
<abentley> There are actually quite a lot of branches in older formats out there.
<Peng> So that's why it's called "dirstatE".
<Peng> distatica: There's Loggerhead, but it's pretty heavyweight (TurboGears). There's also bzr-webserve and bzrweb. Probably a Trac plugin too.
<abentley> There is a trac plugin, but I don't recommend it.  It's slow because trac and bzr have fundamentally different formats.
<abentley> Peng: I don't see TurboGears as especially heavy.  It's just a dependency and the install is dead easy.
<distatica> Good to know though, since this is for shared hosting.
<lifeless> abentley: FWIW it took about 6 hours to install turbogears on freebsd 5.5
<distatica> decent shared hosting (ruby on rails, php, python) but shared nonetheless.
<lifeless> man-hours
<abentley> lifeless: Ouch.  Why?
<lifeless> the dependency chain is deep
<lifeless> something like 20 deeper module
<lifeless> the ports tree only ships python 2.4 stuff for some, 2.5 for others, default python version is 2.5.
<lifeless> freaking mess, I had to hand-update half the ports
<lifeless> the ports use eggs not source tarballs, so projects that hadn't uploaded 2.5 eggs were bustificated too
<abentley> I've done several clean installs lately, and I don't think they took longer than 10 minutes.
<distatica> Can't find a whole lot about this bzrweb, found one site that looked like it's the one, but internal server errors.
<lifeless> and the PEAK stuff just is too new to be packaged on BSD at all.
<lifeless> distatica: what operating system are you using ?
<abentley> Ah.  This was just easy_installing, with no manual intervention.
<distatica> lifeless: windows 2000 here, XP on the other machine, and debian etch on the server (local server, pretty much just a POS to do my bidding)
 * fullermd glances at the turbogears port.
<lifeless> distatica: etch should have a good turbogears package.
<fullermd> Yeah, it looks messy.
<distatica> lifeless: was interested in the other two, to see how they work and if they would run on my shared host.
<distatica> installing dependencies is out of the question there.
<abentley> distatica: You can install apps, but not their dependencies?
<distatica> I can't install apps. I can install scripts, for viewing on the Internet.
<distatica> PHP, Python, Ruby, but I can't just install python dependencies no.
<jelmer> A
<distatica> abentley: that's why I'm looking for more information on those two programs, I'm not sure if they're full blown web servers (obviously one is, but does it have any useful code, for my needs?) or a script that actually reads the .bzr directory.
<abentley> I don't think any of them are CGI scripts, if that's what you mean.
<distatica> yeah, that's another (better) way of putting it.
<abentley> One of them is a bzr plugin, IIRC.
<abentley> Anything that views bzr repositories is going to need bzrlib, but bzrlib doesn't need to be *installed*, per se.
<abentley> You can usually just stick a symlink to bzrlib in the root directory of the program that uses it.
<distatica> that sounds like a neat trick
<lifeless> back later
<distatica> ok, thanks for the help
<ubotu> New bug: #179325 in bzr "error with "bzr gcommit": 'NoneType' object has no attribute 'abort'" [Undecided,New] https://launchpad.net/bugs/179325
<fullermd> lifeless: Actually, doesn't look like anybody's really maintaining it.  It's a couple versions back, and hasn't had any real work since before 2.5 became default   :|
<Peng> Loggerhead?
<dlee> Low-prio idea: Anything against generalizing the default-push-branch, default-pull-branch, bind branch, etc., concept to just letting us create branch nicknames, where some nicknames like "push" etc. have special uses?  Not sure how many people link one project to a number of branches, but if this is a common use case, it could make sense.
<distatica> well, loggerhead was a good suggestion, didn't take too much time either, thanks. Looks nice.
<abentley> Peng: I think fullermd was talking about FreeBSD TurboGears.
<abentley> dlee: I tried that before with a VCS UI called Fai, and I found it very confusing.  Always having to remember which aliases are set in which tree is not a good thing, IMO.
<dlee> Could be set in bazaar.conf too I suppose
<abentley> dlee: I think global aliases are a much better idea.  But that is no longer an extension of the push/parent/submit location idea.
<dlee> touche
<abentley> Just don't use ^ to indicate aliases or zsh users will take you.  All the good metacharacters are gone.
<abentley> s/take/hate
<dlee> leading @ ?  I haven't thought this part out much.
<dlee> I suppose a leading : could work too, unless there's an OS-specificism I've never seen
<dlee> Anyway...just a random thought, caused by my working to make bzr look unbelievably easy to some folks here that don't use version control much or at all yet.  So far, I've achieved short branch names via bzr serve on a LAN; you use a VPN to get to it if outside, but once there, a dotless server name resolves (probably via Windows means), so branch names like bzr://servername/projname are possible.  Good enough. :)
<Peng> FWIW, hg uses branch aliases exactly like that.
<CardinalFang> Hi all.
<CardinalFang> Suppose I "bzr rm" a file and them commit.  How can I then see the history for that file?
<CardinalFang> "bzr log foo" says "bzr: ERROR: Path does not have any revision history: foo"
<abentley> CardinalFang: It looks as though there's no direct way.  You'd have to check out an earlier version of the tree, or resurrect the file.
 * CardinalFang boggles.
<ddaa> well... that's not a hugely common operation
<abentley> Obviously, that should be fixed.
<ddaa> hey abentley, I have a bzr-git that does pull
<ddaa> not very fast, or very correctly
<ddaa> but it does kind of works
<abentley> ddaa: Hehe, but still, great.
<ddaa> just added some sqlite so it runs out of memory later
<mtaylor> anybody know if there's a good way to get the results of bzr log for a deleted file?
<mtaylor> so like, if you wanted to find out when a file was deleted?
 * Peng looks up at CardinalFang ten minutes ago.
<Peng> mtaylor: The answer was that there isn't really a good way right now. "You'd have to check out an earlier version of the tree, or resurrect the file."
 * Peng wanders off.
 * CardinalFang pokes mtaylor 
 * Peng at two words per minute.
 * mtaylor rubs himself where he got poked
<mtaylor> CardinalFang: did I miss the conversation about this? :)
<CardinalFang> Yes.  Sorry.
<dlee> mtaylor: You came in a couple minutes after it--so close I did a double take and looked to see if you two were different people :)
<mtaylor> how funny
<mtaylor> hi CardinalFang
<abentley> ddaa: Wait, you're trying to make it run out of memory later?
<ddaa> I mean later as in "not as early"
<abentley> lol.  Gotcha
<ddaa> there seems to be a minor inefficiency in our repo format: when the x bit changes, it seems the file text is stored once more.
<ddaa> or maybe I misinterpret the  bzr check output
<lifeless> checj is rubbish :)
<ddaa> well, check and the install_revisions code
<abentley> lifeless: Did you see my new merge algorithm?  I'm still quite excited.
<lifeless> abentley: don't think so; if its in bazaar-ng I'll see it wednesday
<lifeless> or thuesday
<abentley> Ah, you're been getting my mail because it's cc'ed to you.  I thought you were reading the list.
<abentley> In the non-criss-cross case, it behaves like 3-way.
<abentley> In the criss-cross case, it should behave better than "weave".
<abentley> So I think it could make mesh-merging basically painless.
<lifeless> good
<dysinger> hey
<dysinger> so after reviewing all the other DVCS I really like BZR.  However I cannot seem to get Python 2.5 on Leopard and Patched Subversion 1.4 and bzr-svn to work.  It's %@#$ing killing me after 24 hours of &%*ing around with it.
<dysinger> I like BZR UI - it's better than GIT.  Help me out here.  I have to work with SVN users.
<dysinger> I have carefully compiled Subversion patched like bzr-svn says to.  Insalled it to /usr/local
<dysinger> in fact - here is my pastie of notes of EXACTLY what I have done http://pastie.caboo.se/133164
<dysinger> It's killing me.  If BZR can't operate with svn EASILY then I have to toss it out.
<dysinger> After my careful install - all I get is
<dysinger> "Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details.
<dysinger> Unable to load plugin 'svn' from '/Users/tim/.bazaar/plugins'"
<dysinger> BZR by itself is cool.  I like it better than GIT.  I wish this would just work.
<dysinger> Thanks for any help.
<lifeless> there may be more detail in ~/.bzr.log
<dysinger> ok one sec
<dysinger> I appologize I am a Java & Ruby nerd.  I don't speak the snake.
<dysinger> http://pastie.caboo.se/133165
<lifeless> lines 8-15
<dysinger> http://pastie.caboo.se/133166 <- I think I have my path right for my custom subversion
<lifeless> try python -c 'import svn; print svn.__file__'
<dysinger> http://pastie.caboo.se/133167
<lifeless> thats the svn its loading
<dysinger> You can see from http://pastie.caboo.se/133164 that I did in fact apply the patches.  It did infact install to /usr/local/lib/svn-python/ and I symlinked it to where I think python likes it better (site-packages)
<lifeless> You also need a fairly recent version of the official Python bindings to the
<lifeless> Subversion libraries. At the moment, the svn plugin only works with
<lifeless> Subversion 1.5 (trunk). The python-subversion (not python-svn!) package
<lifeless> thats from READ
<lifeless> ME
<dysinger> hmm - must have glossed over that.
<dysinger> I went straight to the bottom of http://bazaar-vcs.org/BzrForeignBranches/Subversion
<dysinger> Under Requirements and Subversion 1.4.3 w/ patch
<lifeless> jelmer: ^
<dysinger> It's a bummer to have to go grab /trunk subversion to get this to work.  That makes it harder for me to convince my team to switch.  :/
<dysinger> but I appreciate the help
<lifeless> once you build it once they can use binaries surely?
<dysinger> Even if it's for my fun only.
<dysinger> The OS X Leopard installer is so slick to for BZR 1.0
<dysinger> slick too
 * dysinger compiling 
<abentley> dysinger 1.5 coming out soon?
<dysinger> I don't know - is it ?
<abentley> I was joking about "dysinger copiling", as if you were a software product.
<dysinger> ah :)
<ddaa> I'm done with bzr-git hacking for this year.
<ddaa> all my stuff is pushed on launcphad
<ddaa> enjoy
<dysinger> nice
<dysinger> Well 1.5 trunk svn compiles ok but make chek-swig-py bombs
<abentley> I'm afraid I can't help with that.  My preferred platform has suitably patched bindings.
<dysinger> bzr selftest svn fails :/
<abentley> ddaa: Cool.
<dysinger> My preferred platform has 8 cores at 3GHZ and 16GB ram :)
<dysinger> (new mac pro)
<abentley> ddaa: what's interesting and in Git?
<ddaa> xorg
<ddaa> kernel
<ddaa> samba
<ddaa> small stuff nobody uses like that ;)
<abentley> Yeah, so basically stuff I don't really have disk space for.
<ddaa> well, git itself
<ddaa> it's small enough
<ddaa> though it does produces a >1GB git-cache
<ddaa> all because bzrlib is too dumb to figure out inventory entry revisions by itself :(
<dysinger> so while I have you guys here.  What makes BZR better than GIT?  I like the UI better but it's not a compelling enough reason not to use GIT by itself.
<ddaa> lesse
<dysinger> The SVN integration thing is not working for me even with 1.5
<ddaa> it works on windows
<dysinger> yes that's a plus
<ddaa> generally, it's more user-oriented
<dysinger> yeah I like the UI better
<ddaa> good user interface is not skin deep
<dysinger> like in git git-checkout means like 3 different things
<ddaa> I believe it support more workflows naturally, actually bzr in extremely flexible
<ddaa> s/in/is/
<dysinger> (make a branch, switch working branches and replace files with original)
<ddaa> really, bzr strong points all revolve around the user experience
<dysinger> I don't like that - I like bzr's simple commands.
<ddaa> it's *designed* to be nice to use
<ddaa> while git is designed to be incredibly fast
<dysinger> I like that I can push without having to set hooks or export a "bare" repository.  I like that I can push to sftp with no setup.
<dysinger> I just can't get it to work with SVN :/
<ddaa> honestly, it's more a problem with svn
<dysinger> yeah by itself BZR is very cool.
<ddaa> jelmer had to write a bunch fixes to the python bindings
<dysinger> I just have to work with remote svn - everybody uses svn.
<ddaa> and they need to go through svn release process.
 * dysinger understands
<ddaa> dysinger: if you do not have commit access, you could use launchpad's code import service.
<ddaa> that does not work all the time, and that only import trunk, but that's often enough.
<ddaa> oh, if you're a company
<dysinger> that would work for personal and open source projects but not for client's code.
<abentley> ddaa: is git-over-http supported?  Or do I need to do the initial clone in git?
<ddaa> abentley: it needs a local git
<ddaa> I've been ranting a lot the past few days about how git:// is going to be a pain to support
<ddaa> or git/http for that matter
<ddaa> so, if you're a company
<ddaa> you can talk to Canonical to get professional support for bzr.
<abentley> Or you can run Ubunut in Parallels :-)
<abentley> s/Ubunut/Ubuntu
<ddaa> oh, yes, that's a way to make bzr-svn easier :)
<ddaa> Ubunut is fine
<abentley> I know there's been discussion about packaging bzr-svn for Mac.
<abentley> But I don't think it's happened yet.
<abentley> ddaa: Feature request: progress bar for fetch.
<ddaa> bzrlib bug
<abentley> What's that?
<ddaa> could be worked around using a custom interRepository
<ddaa> InterDifferingSerializer is the thing that lacks the progress bar
<dysinger> I run Ubuntu all over the place - mostly Xen.  It's a great OS - but mostly because it came from great roots - debian.
<abentley> duuude.  That's my "last chance, you better be desperate" InterRepository that I wrote a month ago.
<ddaa> well, that's a perfect fit for this
<ddaa> I guess a custom InterRepo could be more efficient, but that's too much dark magic for me.
<ddaa> Just support .revision_tree() and a couple other things and it works
<abentley> Well, we'll have to see about overcoming this dark magic thing at some point.
<abentley> It works, sure, but it does whole-tree operations where it should really be doing per-change operations.
<ddaa> well.. the thing is git does not give us changes...
<ddaa> at least it's not it's natural medium
<ddaa> I guess it would be faster if we asked changes from git and fed them to bzrlib
<abentley> Anyhow, it's still chugging away.
<ddaa> if you are trying it on git, do not run it all the whole history at first
<ddaa> it take a looooong time
<ddaa> it's fast enough for the 1000 first mainline revs
<ddaa> but at some point the inter-repo starts slogging seriously
<abentley> Oh.  Stopped.
<abentley> So what, pull in groups?
<ddaa> with the recent optimizations, that should not make a huge difference
<ddaa> My latest commit does a good job of keeping the memory inflation slow.
<ddaa> Just use less data if you just want to play with it.
<ddaa> An interrepo that makes small write groups would be nice too.
<ddaa> So it could be interrupted in progress without losing the work.
<ddaa> like bzr-svn
<abentley> That's interesting.
<abentley> Of course, each write group is actually a pack, so you wouldn't want to do it too often.
<ddaa> doesn't bzr repack automatically?
<ddaa> I'm imagine that making small write groups would be less time-efficient, but that should not cause significant space waste.
<abentley> Repack is on certain operations only.
<abentley> IIUC
<abentley> So after conversion, the next time you pulled, it would repack everything into one pack.
<ddaa> well, not big deal to add a repack at the end of the fetch
<abentley> large numbers of packs reduces the efficiency of indexes a lot.
<abentley> time efficiency, I should say.
<ddaa> anyway, there's a lot to gain now by making the interrepo smarter.
<abentley> The viz is nice and zippy, though.
<abentley> But I could have sworn that Git provided tree-delta output.
<ddaa> it certainly does
<ddaa> it's just that I would have no idea how to use it :)
<ddaa> also, it's more natural to start by working of trees and blobs
<ddaa> which are the building blocks of git
<abentley> Well, earlier you said "the thing is that git does not give us changes..."
<ddaa> well
<ddaa> For my defence, it's 7:30 am here
<ddaa> I might not be entirely lucid
<abentley> hehe
<ddaa> "git diff -p --raw --binary --full-index A B" might be something to look at
<abentley> I think maybe branching from git should produce a Bazaar branch.  What do you think?
<ddaa> sure
<ddaa> just found it easier to make pulling work at first
<abentley> We're not going to support writing to git for a while anyhow, right?
<ddaa> that's a good working assumption
<ddaa> I would not bet on it when jelmer gets active, though :)
<ddaa> abentley: though you really should be working off my stable branch
<ddaa> the one with a test suite that actually passes :)
<ddaa> have fun, beddy time now
<abentley> G'night.
<ddaa> ahah, just when I said that, my pull of all git just completed :)
<lifeless> you missed...
<lifeless> 17:49 -!- ddaa [n=ddaa@canonical/launchpad/ddaa] has quit ["Leaving."]
<lifeless> 17:49 < abentley> G'night.
<lifeless> 17:50 -!- ddaa [n=ddaa@canonical/launchpad/ddaa] has joined #bzr
<abentley> Gratz
<abentley> ddaa: got lightweight checkouts working
<ddaa> just needed a stub format, I guess?
<abentley> Right.
<lifeless> checkouts of ?
<abentley> lightweight checkout from a git repo
<abentley> ddaa: And a cloning_metadir
<ubotu> New bug: #179368 in bzr "bug in lighttpd 1.4.18 makes bzr loop or issue too many requests" [Medium,In progress] https://launchpad.net/bugs/179368
<sandrot> I'm having trouble getting pycrypto installed on a mac, will bzr+ssh do the same thing as sftp?
<TFKyle> not afaik, I think bzr+ssh uses bzr's smartserver over ssh, where sftp just uses the sftp subsystem of ssh to transfer the branch
<sandrot> hrm, well I was able to checkout and commit over bzr+ssh without (knowingly) running smartserver
<luks> bzr+ssh will run the smart server on it's own, you just need to have bzr installed on the remote machine
<sandrot> so it seems bzr+ssh would work for me but I don't know if I'm missing anything by not using pycrypto
<sandrot> I see
<luks> I guess it uses openssh on mac
<sandrot> bzr+ssh?
<luks> pycrypto is only needed for paramiko, which is a python ssh-client implementation
<luks> bzr+ssh, sftp, anything ssh related
<sandrot> I can't use sftp because pycrypto isn't installed
<sandrot> and I'm having issues getting pycrypto installed =(
<TFKyle> atleast sftp uses openssh or putty if it can find them I think, otherwise it tries using paramiko which uses pycrypto
<luks> well, just use bzr+ssh if it works for you
<sandrot> guess so, doesn't python have a psuedo package management system? setuptools or something? think I could install pycrypto with that?
<TFKyle> setuptools isn't part of python itself, but you could try using it/easy_install if pycrypto's on pypi
<TFKyle> what problems are you having with pycrypto btw?
<sandrot> `setup.py build` can't build
<sandrot> I run ubuntu myself but am borrowing my friends mac so we can get bzr setup
<TFKyle> mind pastebinning the error?
<sandrot> macports failed miserably, python2.5, bzr and paramiko installed nicely but pycrypto has issues...
<TFKyle> (http://rafb.net/paste is a good one if you don't know of any)
<sandrot> cool, one sec
<sandrot> Mm, I'm afraid I can't capture all of the output but after doing setup.py build > log, log tells me to check my Xcode version
<sandrot> I'm going to do that realy quick
<sandrot> brb
<jelmer> 'morning
<sandrot> hi
<abentley> TFKyle: Bazaar always uses Paramiko for the sftp protocol, even if the ssh connection uses OpenSSH or PuTTY.
<TFKyle> hmm, I remember being able to branch from sftp:// before without having paramiko installed, parts of paramiko are in bzr or?
<TFKyle> abentley: <TFKyle> hmm, I remember being able to branch from sftp:// before without having paramiko installed, parts of paramiko are in bzr or?
<TFKyle> (though that was back in the 0.1x days, havn't tried it recently without paramiko installed)
<abentley> I can't see how that would be possible.
<TFKyle> looking at the 1.0 sftp transport indeed it looks like it does need paramiko
<TFKyle> guess I was remembering wrong, sorry
<abentley> np
<hsn_> any reports about bzr 1.0 corrupting pack repos?
<hsn_> my 2 repos are corrupted
<elmo> hmm, does cherrypicking merges (merge -c) "lose" history?
<hsn_> -r lose history, never used -c
<elmo> bother
<hsn_> i think that -c is just syntax sugar for -r
<elmo> right, so probably the same deal
<elmo> bzr: ERROR: Revision {joerg@debian.org-20071229214821-h9rkdipixra914oe} not present in "<bzrlib.knit.KnitGraphIndex object at 0x2b03534e0c50>".
<elmo> ^-- umm - what?
<elmo> (from trying to merge a bundle)
<abentley> elmo: Your bundle is based on a revision not present in your repository
<abentley> hsn_: I'm not aware of any corruption issues with pack repos.  Please file bug reports.
<elmo> abentley: ah, double bother.  so don't cherry-pick with bundles then?
<abentley> elmo: unless you're generating old bundles, cherry-picking should be fine.
<elmo> abentley: 'old bundles'?
<abentley> Format 0.9 or earlier.
<elmo> abentley: I'm using bzr 1.0 on both sides, so I assume not
<abentley> Not unless you're trying to.
<abentley> So when you generate a merge directive, the contents of the bundle are whatever's needed to install the revisions into your submit branch.
<elmo> abentley: the 'master' tree I'm trying to bzr merge into is at r993 or something.  the other side, the guy has a bunch of changes, up to r1009.  I want to bzr send, just revision 1009.  which is what I tried, and what I failed - should that have been possible?
<elmo> (as in, I did bzr send -r 1008..1009)
<abentley> That should have been possible.
<elmo> bzr doesn't love me today.
<abentley> So what was the command you issued?
<abentley> to send?
<elmo> bzr send -r 1008..1009 -o /some/filename
<elmo> then 'bzr merge /some/filename' on the other side
<abentley> And what was your submit branch?
<elmo> 'submit branch'?
<abentley> The first argument to bzr send
 * dato guesses "none"
<abentley> it is the branch that you want to submit your changes to.
<dato> and then the default value got used, and maybe that was an intermediate branch which had up to r1008 or so
<abentley> dato: It can't be none if the send succeeded.
<dato> abentley: none explicitly mentioned in the command line, I meant
<elmo> oh, I see
<elmo> so I need to bzr send with a submit branch of what I call 'master'?
<abentley> The submit branch is used to decide what revisions are needed in the bundle.
<abentley> It needs to have a subset of the revisions in master.
<dato> abentley: (as a side note, mergin such bundle causes a cherrypick anyway, no? that is, that no merged revision show up in commit)
<abentley> dato: It depends on whether you have the cherrypick base.
<abentley> If it is possible to do a non-cherry-pick merge, bzr will.
<elmo> ok, so using a submit branch worked, thanks
<abentley> great.
<elmo> of course, it's still a cherry pick, so my unsubtle attempt to work around losing merge history failed entirely ;-)
<dato> under what circumstances is that possible? the picture I have in mind is master "r1 - r2", feature "r1 - r2 - r3 - r4", bzr send -r 3..4
<abentley> A scenario where it's possible is master "r1-r3", feature "r1 - r2 - r3 - r4", bzr send -r 3..4
<abentley> elmo: I believe bzr 1.1 will attempt to download the missing revisions from your submit branch for you.
<elmo> abentley: the missing revisions aren't in the submit branch though, and I don't actually want them - if you see what I mean?
<abentley> It will install them into your repository so that the cherrypick works.
<dato> elmo: "don't actually want them" <-- in your branch, you wouldn't mind them being in your repository
<abentley> It won't do a full merge or anything.
<elmo> aha!
<elmo> I see what you mean.  that'd be lovely
<dato> abentley: what happens if you later merge the full branch? (r993 .. r1009)
<abentley> Well, a three-way merge doesn't do *too* badly if you haven't changed the bits you cherrypicked.
<abentley> Especially if you merge --reprocess.
<abentley> If you've changed the bits you cherrypicked, you'll get conflicts.
<abentley> elmo: I'm sorry that we can't yet represent a cherrypick in our metadata.  It is something we plan to support.
<elmo> abentley: no problem, it's a relatively minor detail - if it's on your (collective) radar to fix, I'm more than happy
<hsn_> !pastebin
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<hsn_> abentley: http://paste.ubuntu-nl.org/50171/
 * dato wonders *why* *on* *earth* reporting malicious content in that pastebin is done *just by following a link*
<hsn_> because spam bots will self-cancel?
<dysinger> So sorry to interrupt any conversations.  Just wanted to ask more questions.  I think I have pretty much exhausted all reasonable attempts at pushing / pulling to svn with a mac and bzr 1.0.  I can't do any direct imports either both branches of svn2bzr are broken on my 128MB 6 month old repository.  So I have yet to find a way to use my existing project in bzr that's not a time-sync and hassle for me (being new to bzr).  Just some feedback 
<jelmer> hi dysinger
<jelmer> dysinger: you were the guy having problems patching python-subversion, no?
<dysinger> The patch applied cleanly to 1.4 subversion but then I just kept getting "No Python bindings for Subversion installed. See the bzr-svn README for details. Unable to load plugin 'svn' from '/root/.bazaar/plugins'"
<dysinger> So I tried 1.5 trunk last night but it didn't compile so smooth.
<dysinger> I really like BZR so this isn't critique
<jelmer> There were a couple of people that reported that installing a patched subversion on Mac OS X would install to a differnet location
<jelmer> can you run the following:
<dysinger> I tried patching and installing it to $HOME like I do everything else and I also did /usr/local with same result.
<jelmer> python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler"
<dysinger> OS X Leopard comes with libsvn and svn for python 2.5 preinstalled.  I tried to make sure my path was straight so that my /usr/local bindings loaded first
<dysinger> I get False from that - I have been using it as a test from your source.
<jelmer> and does this give a location you expect:
<dysinger> y
<jelmer> python -c "import svn.delta; print svn.delta.__file__"
<dysinger> gives me /usr/local...
<jelmer> dysinger: did building subversion rerun SWIG?
<dysinger> I am trying to gather notes and be helpful if I can too.  I always do that on my blog (mostly ruby stuff) http://dysinger.net so if I can figure it out and put together a bash-notes script I will post it there.  I am trying to do this without macports, fink etc - I prefer from scratch.
 * jelmer wonders if the Subversion sources comes with prebuilt versions of the Python bindings
<dysinger> Yes I rebuilt SWIG and ran the SWIG tests.
<dysinger> before install
<jelmer> did you run install-swig-py ?
<dysinger> y
<dysinger> (testing it before hand)
<dysinger> 1.5 trunk fails those tests
<dysinger> 1.4 is fine.
<jelmer> and grepping for svn_delta_invoke_txdelta_window_handler in /usr/local/ returns the right python file?
<dysinger> this installs libsvn* in /usr/local/lib along with SWIG stuff in /usr/local/svn-python/
<dysinger> one sec
<jelmer> how are you trying to run bzr to make sure that it loads the right bindings?
<dysinger> just trying to branch something
<dysinger> like bzr branch http://macromates.com/svn/Bundles/trunk/ textmate-bundles
<dysinger> and it always gripes about the bindings
<jelmer> dysinger: it probably loads the system-provided bindings for python-subversion then though
<jelmer> rather than the ones in /usr/local
<dysinger> I went to the bzr_svn code in __init__ and pulled out your checks and just did them at the command line
<dysinger> and it always fails no matter what I do
<dysinger> I checked my PYTHONPATH too
<dysinger> jelmer: I think you are right.
<jelmer> can you try setting the PYTHONPATH manually? E.g.: PYTHONPATH=/usr/local/lib/svn-python python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler"
<dysinger> but python -c "import svn.delta; print svn.delta.__file__" returns the right file
<dysinger> yes give me a minute to reinstall 1.4 like I had it.
<jelmer> it may actually be loading the python file from the right location but the corresponding shared library from the wrong location. or something.
<dysinger> y
<jelmer> dysinger: still there?
<dysinger> y
<dysinger> sorry re-installing it real quick
 * dysinger feels stupid now.
<dysinger> oh man I think I figured it out and I am  an embarrassed dumb-ass - lol - sorry - in my efforts to automate everything via a script and deprive myself of sleep, I wasn't applying the patch correctly :/
<dysinger> sorry
<jelmer> :-/
<jelmer> well, at least you did find it now :-)
<lifeless> just highlights the need for a package IMO :)
<dysinger> gaahhh I wasted sooo much time on that.
<jelmer> afaik phanatic and erik are working on that
<dysinger> y I will paste my notes on my blog asap and you can pull them off for mac folks if you want.
<jelmer> dysinger: feel free to just add a link to the wiki
<dysinger> k
<jelmer> hi schierbeck
<jelmer> schierbeck: There was somebody from the tango team around a couple of days ago
<jelmer> Asking about icons for bzr-gtk
<jelmer> There is a thread about it on the bzr-gtk mailing list, any input would be welcome :-)
<schierbeck> jelmer: hi!
<schierbeck> yeah, i talked to a guy named Cube some time ago
<dysinger> well I feel less like a dumbass now.  It still doesn't work.  I don't want to waste a bunch of your time.  Could you look at my notes and results here http://pastie.caboo.se/133339 for a second ?
<schierbeck> he started working on some icons, but he never really got around to finishing them
<dysinger> I wonder if it's the patch?  I see everything installs correctly.  The patch doesn't complain.  It finds the right svn.delta.__file__ but it doesn't have the svn_delta_invoke_txdelta_window_handler
 * dysinger sighs
<jelmer> schierbeck: yep, that's the one
<jelmer> schierbeck: he sent mail to the list, did you see it?
<schierbeck> jelmer: yup
<schierbeck> was busy with exams and all the christmas stuff
<schierbeck> we really need those icons
<jelmer> no worries :-)
<jelmer> Some comments would be nice though
<sam1234> Hello people? Can I ask some question about bazaar?
<jelmer> sure
<sam1234> ok. So I have a problem with user id...
<sam1234> bzr whoami MyName tell my name
<sam1234> but...
<sam1234> When i tried to change it, for example: bzr whoami MyNewName
<sam1234> commits, that I have done still have my old name.
<jelmer> yes, it only works for commits you are doing since the chance
<jelmer> you can not alter existing commits
<sam1234> I have spend some time to find some solutions, but with no result. The problem...
<sam1234> for me is that when I change my e-mail, then people that try to contact me by my old e-mail will be confused
<jelmer> sorry
<jelmer> that's the way it works
<sam1234> I looked at .bzr directory but changing something by hand result error.
<sam1234> Do you know some VCS that don't have this limit?
<jelmer> sam1234: even if bazaar would uspport it
<jelmer> how would it be able to do that?
<jelmer> I don't think there are any other systems out there that do support it
<sam1234> Sorry, I don't know much about VCS, that's why ask. This is feature that could be usful for me, but isn't so important.
<sam1234> So if this can't be done, I still can live.
<sam1234> Name is constant, only e-mail will be changed.
<sam1234> thanks for you time jelmer. Best regards.
#bzr 2008-12-22
<mkanat> Hey poolie.
<mkanat> The Bugzilla Project is thinking about switching to bzr: https://bugzilla.mozilla.org/show_bug.cgi?id=bz-bzr
<Toksyuryel> :D
<mkanat> And related discussion thread here: http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/8f1d9255845b3794
<beuno> mkanat, I'm really not here, but, you have my full support to get Loggerhead into the shape you need
<mkanat> beuno: Sweet.
<beuno> ping me with the bugs you want me working on, and I'll focus on them  :)
<mkanat> beuno: I filed one just today.
<beuno> mkanat, and I confirmed it and marked it as high
<mkanat> beuno: Great. :-)
<beuno> mkanat, just make sure that I'm aware of your major pain points, I tend to drift  ;)
<mkanat> beuno: Okay, cool. :-)
<markh> mkanat: do you have many developers on Windows?
<mkanat> markh: We have some, yeah.
<mkanat> markh: And we keep our VCS stuff in all our tarballs.
<markh> will EOL support be an issue?
<mkanat> markh: So users will end up using bzr, too.
<mkanat> markh: Hm?
<markh> IIUC, your cvs repo will have \r\n line endings on windows
<mkanat> Ohh.
<markh> well - the windows checkouts of the repo
<mkanat> markh: What does bzr do with EOLs now, just leave them as they are in the repo?
<markh> yeah - nothing
<markh> so bzr checkouts on windows will have \n
<markh> but this is being worked on
<mkanat> markh: I think that's OK, actually.
<mkanat> markh: Since we're a web app.
<mkanat> markh: We have problems with that anyway, right now, so we have to deal with it on our end.
<markh> diffing a cvs and bzr tree becomes hard, for example, and "dumb" editors will have trouble.  But in practice, it often isn't really a problem.
<markh> silly things like the patch tool I use always converting files to \r\n is annoying - for large projects in the meantime, a hook that *prevents* \r\n checkins might help for the future too.
<mkanat> I'm pretty sure it's all mixed up currently in our CVS repo. :-)
<markh> heh - no problem then - bzr has exactly the support you need ;)
<mkanat> :-D
<mkanat> beuno: Is Search supposed to be working in 1.6? The relnotes seem to indicate so, but it doesn't seem to quite be working, even with bzr-search installed and the branches indexed.
<mkanat> beuno: Our Loggerhead is at http://bzr.bugzilla.org/ and it allows access to the .bzr directories too if you want to poke around and figure out why search isn't working.
<mkanat> beuno: (e.g. http://bzr.bugzilla.org/bugzilla/trunk/.bzr/ )
<beuno> mkanat, you need to have the bzr-search plugin installed
<mkanat> beuno: I do.
<beuno> and index each branch one time (bzr index)
<mkanat> beuno: You can see the indexes in that link there.
<beuno> mkanat, ah
<beuno> mkanat, does bzr search work through the terminal?
<mkanat> beuno: It does.
<mkanat> bzr-1.9 FWIW.
<beuno> mkanat, it should work, lifeless made sure it did
 * beuno thinks
<mkanat> beuno: This is python-2.4, also.
<mkanat> beuno: And the only thing I don't have is sqlite3, as far as loggerhead's prereqs go.
<mkanat> At least, as far as I know.
<beuno> mkanat, sqlite will just improve performance, but everything should work without it
<beuno> are you using loggerhead's trunk?
<mkanat> beuno: No, 1.6.
<mkanat> I'm using the tip of whatever 1.6 branch is right now.
<beuno> mkanat, ah, go for trunk. It has the work for 1.9
<beuno> I'll be making a new release soon
<mkanat> beuno: Ah, okay. :-) Is trunk stable enough to use right now?
<beuno> mkanat, yeap, much better than 1.6!
<mkanat> beuno: Great!
<beuno> mkanat, in general, trunk is pretty stable. We try and not do any crazy stuff in trunk  :)
<mkanat> beuno: Okay, great. :-)
<mkanat> beuno: I'll just run trunk then.
<beuno> mkanat, let me know if that fixes the search issues
<mkanat> beuno: Yeah, that fixes it. :-)
<mkanat> Really, overall, loggerhead is great.
<mkanat> Probably the best code browser for any VCS.
<mkanat> Anyhow, I'm off for the night.
<mkanat> Later!
<beuno> :)
<mwhudson> man, loggerhead is terrible
<mwhudson> i can believe that other code browsers are even worse though :)
<jamesh> viewvc isn't so bad
<jamesh> although it doesn't map easily to bzr
<evarlast> i love viewvc
<mwhudson> is there some easy way from the command line to write lock and then unlock a branch?
<mwhudson> i guess it would be a very easy plugin...
<evarlast> what would be the point?
<mwhudson> obscure details of how launchpad works :)
<mwhudson> (i.e. it would make my job a teensy bit easier)
<jamesh> mwhudson: lock the branch then sys._exit()?
<mwhudson> no, nothing so fancy
<mwhudson> i think http://pastebin.ubuntu.com/90483/ does what i want :)
<jml> mwhudson: except lock_write, right?
<mwhudson> uh
<mwhudson> yes
<mwhudson> sshfs + flymake-mode considered irritating
<rocky> hm, is there a hook or someway to be notified whenever an init-repo is performed? (code-wise)
<jml> rocky: I don't *think* so.
<jml> rocky: what do you want it for?
<igc> markh: just posted a review of your cicp patch (at last!)
<poolie> jml, are you still around?
<jml> I am.
<jml> poolie: what's up?
<poolie> i wanted to check about this progress bar thing
<jml> poolie: ok. I've got to head out soon. Should I skype you or something?
<poolie> i'd like to finish soon too
<poolie> sure let's talk there
<jml> "Call refused"
<markh> igc: excellent, thanks.  You may be correct that special-casing mv and add might be best.  The rest are nice and easy :)
<markh> (and many I should have known better - leading _, double space :))
<igc> markh: cool. I was thinking re ongoing support of the feature as much as anything
<markh> yeah
<markh> choosing the word "canonical" to describe the feature is working against the 1-line docstrings too :)
<igc> markh: btw, going over 80 chars on that one line is fine if required
<markh> oh - excellent!
<igc> poolie: so I'm adding base classes for wt4 and later workingtrees as discussed
<igc> are the names _DirStateWorkingTree and _DirStateWorkingTreeFormat ok with you?
<dD0T> Hello, I'm playing around with a project whose build environement is heavily path dependent and I would like to know if it is possible to easily manage several "branches" in a single directory with bzr. Thanks.
<RAOF> dD0T: Kind of.  Pretty much.
<RAOF> dD0T: As I understand it, a branch is a directory.  But you can do what you want by using checkouts of local branches and switching between them with 'bzr switch'.
<dD0T> RAOF: So I would keep my branches somewhere and "switch" to lightweight checkout of the one I want to work on in the directory specified by the build environement?
<RAOF> Yes.
<RAOF> Exactly.
<dD0T> ROAF: Sweet ;-) I guess that's good enough for me.
<dD0T> ROAF: Thanks for you help!
<RAOF> Great :)
<dD0T> Just out of curiosity. Anyone got a clue when windows binaries for the new version will be available?
 * igc dinner - night all
<Peng_> dD0T: There's a problem with the Windows build machine. I don't know of an ETA for fixing it and building 1.10.
<dD0T> Peng_: :-( Anyway. Up to now I found nothing terribly wrong with 1.09 so I can wait.
 * markh should just make them again :)
<thekorn> hi, I've got a quick question: I know a change was made in a merged revision (let's say 45.1.2), is there a easy way to get the revision number of the merge?
<Peng_> I'd just run "bzr log | less" and search for the revision, but I don't know if there's a better way.
<fullermd> There isn't a UI way I can think of, certainly.
<thekorn> Peng, yeah that's similar to what I'm doing, but it can be terribly difficult
<thekorn> I'm fine with every bzrlib piece of code, if there is something,
<thekorn> but I don't know the magic of bzrlib enough do code it myself ;)
<luks> I'd just use bzr qlog, and click on revision links until I find the merge
<beuno> thekorn, if you want to know what mainline revision a dotted revno belongs to, there's no easy way to do it with bzrlib
<markh> luks: hi!
<luks> beuno: no easy way? simple iterate over parents backwards
<luks> hi markh
<beuno> luks, well, yes and no. Because you can have multiple parents.
<beuno> and, getting the revision graph from a big branch is pretty expensive
<luks> revision numbers depends on the whole revision graph anyway, you can't work that around
<luks> so as soon as you want to translate 45.1.2 to a rev_id, you already have the whole graph loaded
<beuno> that's true
<beuno> there's something to load mainline revnos lazily, but not dotted ones
<Emmanuel> Hi, I would like to know if it is safe to push a repository to a central directory on a shared directory. How Bazaar handles concurrency ?
<thekorn_> ok, thanks beuno, so I will go on with grepping in the output of bzr log, but that's ok
<Lo-lan-do> Hi there
<Lo-lan-do> Is there a way to see what's in a repository?
<Lo-lan-do> I have a shared repo with other shared repos underneath, and I'd like to be sure the real data are in the sub-repos.
<LarstiQ> Lo-lan-do: which data?
<Lo-lan-do> Revisions and what they contain
<LarstiQ> right, but not some random revisions I suppose
<LarstiQ> bzr check on a branch at least will check for ghosts
<LarstiQ> Lo-lan-do: what situation are you guarding against?
<Lo-lan-do> Yeah, I'll try and be more precise, sorry.
<Lo-lan-do> I have several repositories under a common directory.
<Lo-lan-do> ~/bzr-repo/gforge, ~/bzr-repo/client-1, and so on.
<Lo-lan-do> They all contain branches which seem to work (at least, I can't see any problems with them)
<Lo-lan-do> However, I just realised that ~/bzr-repo is also a repository itself.  It has a .bzr subdirectory, which contains knits and whatnot.
<Lo-lan-do> I'd like to know if I can zap it, but for that I'd need to be sure that there's nothing important in there.
<LarstiQ> ah, right, yes.
<LarstiQ> Lo-lan-do: branches store their revisions in the first repo above them they find, if all branches work fine, then nothing uses the one above. Of course, you need to be sure they work fine then.
<LarstiQ> Lo-lan-do: you can use `bzr heads` on the repo to get an idea of what is inside.
<Lo-lan-do> Thanks
<LarstiQ> (it would be possible to have ~/bzr-repo/somedir/branch, then make ~/bzr-repo/somedir a repo too, and have branch miss the earlier revisions)
<LarstiQ> commandline bzr will refuse to make somedir a repo though, but with mv being careless it could happen
 * LarstiQ goes afk for dentist
<Lo-lan-do> Good luck, and thanks, it does list a few heads.
<Lo-lan-do> (dead ones)
<LarstiQ> none of the dead heads is in the ancestry of live branches you care about?
<LarstiQ> yay transitivity, and now really gone
<Lo-lan-do> Not sure, I'll grep
<Lo-lan-do> Hm.  They all are.
<Lo-lan-do> But moving ~/bzr-repo/.bzr to someplace else doesn't seem to break anything in these live branches, so I guess I'm fine.
<gar1t> Anyone use cherrypicking routinely in their workflow?
<gar1t> I'm wondering if there's a decent way to a) review the changes from a branch and b) selectively merge those into a feature branch (or the upstream branch)
<gar1t> Obviously there's "diff", but I'd like a streamlined approach that let me review each revision and decide whether to merge it or not.
<gar1t> Then there's "log", which of course gives me the list of revisions.
<gar1t> I guess I'm looking for something that stream lines that process. Kinda like an unshelve style interaction.
<beuno> mwhudson, I'm releasing a new version of LH today
<beuno> it's been too long, and too many people use releases
<beuno> also, I'll push packages to a PPA
<mkanat> beuno: Yay. :-)
<beuno> mkanat, and after that, I'm tackling the latest bug you filed. That's my priority list ATM for Loggerhead  :)
<mkanat> beuno: Great. :-)
<mkanat> I wonder if there are any other Bonsai features that people are going to want...
<mkanat> Oh, date limiters, probably.
<beuno> mkanat, we can easily do that
<beuno> also
<mkanat> That'd probably make you guys pretty much functionally equivalent to Bonsai.
<mkanat> And so much nicer.
<beuno> if you want a nice theme for bugzilla, let me know, I have a week or so off coming up  ;)
<mkanat> beuno: Ooooh. :-)
<mkanat> beuno: Even if you just wanted to play with our Skins (which is just CSS stuff), that'd be fun. :-)
<beuno> mkanat, sure. I'll add that to my list as well then.
<mkanat> Sweet. :-)
<mkanat> We're also doing some usability work with NASA and the whole Mozilla UX team, too.
<beuno> although, a theme may kinda force you to merge from trunk. It kinda sucks how we do themes today.
<beuno> oh, very cool
<mkanat> beuno: Although actually, the default loggerhead theme is probably fine.
<mkanat> beuno: I misunderstood you and thought you meant for Bugzilla itself. :-)
<mkanat> beuno: That's where the seemingly non-sequitur comment about our UX work came from.
<beuno> mkanat, well, we can slap a header with a logo on there
<beuno> heh, right
<beuno> I'd love to help out there as well
<mkanat> That's a much bigger sort of project, though. :-)
<beuno> but time, as it turns out, is very limited  :)
<mkanat> Hahaha, yeah.
<mkanat> beuno: Oh, it looks like you guys already have date stuff? https://bugs.launchpad.net/loggerhead/+bug/121719
<ubottu> Ubuntu bug 121719 in loggerhead "need more discoverable search facilities" [Undecided,Confirmed]
<mkanat> beuno: Maybe just a [Help] link for the search box...
<beuno> mkanat, we do, although it's a bit cryptic, and I'm not sure if it still works when bzr-search is installed
<mkanat> Ah, okay.
<beuno> so I didn't want to confirm until I tested it
<beuno> that's kinda why I said it was easy  ;)
<mkanat> Ahh, okay. :-)
 * emmajane waves :)
<jelmer> emmajane: hi!
<emmajane> jelmer, hey :)
<emmajane> jelmer, any new and exciting stories for today?
<jelmer> not yet, but hopefully bzr-git should be supporting imports from git by the end of today
<emmajane> WOO
<jelmer> Jc2k, hi!
 * emmajane has a new question about bzr.
<emmajane> I tried to "pull" some XML files for the desktop course. but got an error that I'd diverged.
<emmajane> So I merged instead and it said I'd merged....but I think it should have taken longer.
<jelmer> emmajane, merging should be pretty quick if you tried to pull earlier, since it would've already retrieved all the data from the remote branch
<emmajane> the pull was almost instantly rejected...
<jelmer> emmajane, did "bzr merge" show a summary of changes that you expected?
<emmajane> no. :/ it just said, Merging from remembered location bzr+ssh://emmajane@bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta/ All changes applied successfully.
<emmajane> I think it's lying.
<Jc2k> jelmer: sounds exciting!
<Jc2k> jelmer: and useful for me!
<mkanat> emmajane: You could do "bzr status"
<emmajane> AHA, that's more useful, thanks mkanat
<emmajane> mkanat, now I can see there is one pending merge.
<jelmer> emmajane, the merge didn't bring in any actual file changes, but it did bring in a new revision
<emmajane> jelmer, There have been branches merged since I last made updates though.
<jelmer> emmajane, perhaps both branches contained the same changes, but those changes were committed in both independently?
<emmajane> jelmer, wishful thinking. :(
<Jc2k> i've seen that before when i made the same change to my branch of dulwich as jelmer did :p
<emmajane> emmajane@gollum:~/ubuntu/ubuntu-desktop-course$ bzr status
<emmajane> pending merges:
<emmajane>   Belinda Lopez 2008-12-10 Merged corrections to front matter and chapters 1...
<emmajane> (what's the rule on pastebin? how many lines of spam do I need before I start getting thwacked?)
<mkanat> emmajane: No more than three lines, in most channels.
<emmajane> kay :)
<emmajane> To me "pending merge" implies, "not done yet." Does that seem right?
<jelmer> emmajane, they are merges that are already in your working tree but not committed yet
<emmajane> jelmer, so they are downloaded?
<jelmer> emmajane, yes, and applied to the working tree (if they made any changes)
<emmajane> excellent, thanks jelmer
<emmajane> And now the status returns no text.
 * emmajane thinks that dancing elves might be a nice touch. That sing a little midi tune to tell you there are no changes and no errors.
<emmajane> just an idea. ;)
<Peng_> Hmm, pygame could handle that, right?
 * emmajane chuckles.
<emmajane> Peng, for the bzr v 99837.7 beta release? :)
<Peng_> I'll put it on my to-do list. I'll probably have learned bzrlib and pygame by then, right? :D
<emmajane> lol :)
<emmajane> I love it. :)
 * emmajane will learn how to make midis.
<Peng_> :D
<nosklo> Can't use authentication.conf with bzr-svn and googlecode.com passwords. Although I have the correct password in authentication.conf it still gives me "ERROR: Permission denied". If I remove authentication.conf and enter the password by hand it works, I have triple-verified the password
<nosklo> but also, it asks for the password 3 times each branch I try
<nosklo> and that is annoying
<jelmer> nosklo, do you have the username specified in authentication.conf ?
<nosklo> jelmer, yes, and I am also specifying the same username in https://user@project.googlecode.com
<nosklo> because otherwise bzr-svn won't kick up, and it will try to branch a bzr repository which will also fail
<jelmer> nosklo, there is an open merge request for bzr about this I think
<nosklo> jelmer, cool, can I pull it
<jelmer> nosklo, when bundlebuggy gets back up :-/
<jelmer> abentley, ping
<nosklo> I love bzr, but bzr-svn is not up to the task yet
<jelmer> nosklo, this particular bit is a bzr bug
<jelmer> nosklo, at least as far as I can see
<nosklo> I am trying to move everything I have to bzr
<nosklo> git-svn seems to work better for now
<jelmer> nosklo, what's problematic about bzr-svn?
<nosklo> jelmer, well, it can't detect I am using svn, if I use just a http url it fails to try it as svn
<nosklo> jelmer, I have to use svn+http or use username@host to make bzr-svn try the url
<jelmer> nosklo, again, that's a bzr bug - you can workaround
<jelmer> nosklo, it by specifying svn+http://
<Lo-lan-do> beuno: Did jelmer tell you about some of the wishes we have for LH on alioth.debian.org?
<jelmer> Lo-lan-do, Hi
<Lo-lan-do> Hi jelmer :-)
<jelmer> Lo-lan-do, yeah, we discussed it here a couple of days ago
<nosklo> jelmer, the other problem I have is that it asks for authentication 3 times each branch I make :)
<Lo-lan-do> Great
<beuno> Lo-lan-do, hi
<beuno> jelmer, did we solve all of them?
<beuno> I forget  :)
<nosklo> typing generated passwords of letters and numbers 3 times each branch, is... annoying
<jelmer> nosklo, as I mentioned, please use svn+https://
<jelmer> nosklo, that way regular bzr probing is skipped
<emmajane> beuno, hey :)
<jelmer> beuno, Well, start-loggerhead/stop-loggerhead are still present :-)
<beuno> hey hey emmajane
<emmajane> beuno, are you back in the land of warmth and sunshine? :)
<beuno> jelmer, ah. Well, I'll make it a goal for the next release to remove them and substitute all functionality with serve-branches
<beuno> I'm releasing Loggerhead 1.10 *today*
<Peng_> .10?
<Lo-lan-do> beuno: Good news :-)
<jelmer> ah, cool
<Jc2k> hi beuno :)
<Peng_> Not .7?
<beuno> hey Jc2k
<beuno> Peng_, we're following bzr's versions
<Peng_> beuno: ah.
<beuno> as counter-intuitive as that is  :)
<Peng_> You should follow bzr, only backwards...somehow. :)
<beuno> I'm open to suggestions if you guys think that's too crazy
<nosklo> jelmer, okay, thank you. It says its deprecated but works. But it is still asking 3 times for the password
<beuno> jelmer, I'm going to upload this release to PPA
<jelmer> nosklo, if you run "svn ls" or something on the URL once, it will cache that in ~/.subversion and bzr-svn will use those credentials
<Peng_> nosklo: Yeah, "svn+" is officially deprecated, but still has a purpose.
<beuno> jelmer, have you updated your packaging branch to reflect the dependency changes?
<Peng_> Dependency changes?
<jelmer> beuno, yeah
<jelmer> beuno, please let me know when 1.10 is out, so I can upload to debian :-)
<beuno> jelmer, if everything goes well, in about 20 minutes, but I will ping you   :)
<Peng_> mkanat: BTW, did you see my comment on bug 240577?
<ubottu> Launchpad bug 240577 in loggerhead "Loggerhead should be able to serve branches through http" [Undecided,Confirmed] https://launchpad.net/bugs/240577
<Peng_> ubottu: botsnack
<mkanat> Peng_: Oh, true.
<ubottu> Yum! Err, I mean, APT!
<beuno> jelmer, https://code.edge.launchpad.net/loggerhead/1.10/1.10
<jelmer> beuno, awesome, thanks
<jelmer> beuno, tags?
<beuno> jelmer, loggerhead-1.10 on trunk
<emmajane> beuno, yay :)
<jelmer> beuno, loggerhead/__init__.py still says 1.6
<beuno> dang
<beuno> jelmer, I'll remove/add the tag again
<beuno> and push to lp:loggerhead/1.10
<beuno> jelmer, done
<beuno> thanks
<beuno> I'll re-create the tarball as well
<jelmer> beuno: I've updated the packaging branch
<beuno> jelmer, you have the full release in that branch?
<jelmer> beuno, yes, it's an ancestor of lp:loggerhead
<beuno> jelmer, so what do you use to create the package?
<beuno> not the tarball?
<jelmer> beuno: The upstream tarball is generated from lp:loggerhead, by exporting the relevant tag/revision
<beuno> I was thinking about using the scripts in bzr.dev/tools/packaging/*
<beuno> jelmer, so why do you have all the files in the branch then?
<jelmer> beuno, Building it should be as simple as "bzr builddeb"
<jelmer> beuno, the files in the branch are used to generate the debian diff
<beuno> jelmer, so you merge into that branch for each release?
<beuno> I'm getting no revisions to pull on the debian branch
<jelmer> beuno, yes, I merge for each release (using "bzr merge-upstream" (from bzr-builddeb))
<jelmer> beuno, launchpad may not have mirrorred it yet
<jelmer> http://bzr.debian.org/pkg-bazaar/loggerhead/unstable is the original URL
<jelmer> (fwiw, all bzr-related packages for debian use this structure atm)
 * beuno has to learn to use bzr-builddeb
<emmajane> in your spare time, eh beuno ? :)
<beuno> emmajane, I haven't seen any of that in a while!
<emmajane> beuno, I hear it goes on sale in the new year!!
 * beuno will be in the front of the queue waiting
<emmajane> :)
<nosklo> jelmer, well, it works, after svn ls it does not ask anymore for auth, even without authentication.conf - it seems to read svn authentication. I had to install subversion though
<nosklo> jelmer, is it a bug? shouldn't it ask only once and use the same name/password pair for all subsequent requests, at least on the same session?
<nosklo> jelmer, Is there something I can do to help?
<jelmer> nosklo: basically, this requires some improvements of the credentials layer in bzrlib that vila has been working on
<jelmer> nosklo, hopefully that will also allow bzr to in the future write credentials to authentication.conf rather than just reading them from there
<nosklo> jelmer, yeah, even reading from there seems broken... but anyway, I got mine to work, thanks again.
<jelmer> I'm not entirely sure why specifying them manually in authentication.conf doesn't work
<jelmer> nosklo, any chance you can file a bug about that bit?
<nosklo> jelmer, of course, you got it. I will start with a fresh environment and put it in a way you can reproduce. Where do I file the bug, malone?
<jelmer> nosklo, yep - http://launchpad.net/bzr-svn/+filebug IIRC
<abouche2> what exactly does bazaar do?
<emmajane> abouche2, there's a really great documentation site that explains some of the basics: http://bazaar-vcs.org/
<emmajane> awww.
 * emmajane was just getting started!
<beuno> wise man  ;)
<beuno> jelmer, is there any way I can have the equivalent of debuild -S with bzr-builddeb?
<jelmer> I think "bzr builddeb -S" is the equivalent
 * beuno tries for the 6th time to get the package into a PPA
<jelmer> beuno, what's being problematic?
<beuno> jelmer, I am  :)
<jelmer> I mean, what's preventing it from getting into PPA ? :_)
<jelmer> Or do you mean it's a PEBKAC?
<beuno> I haven't used builddeb, so I'm going ahead with "trial and error" instead of "reading documentation"
<emmajane> beuno, *grin*
<beuno> so PEBKAC I guess
<beuno> emmajane, :)
<beuno> emmajane, the suggestion is pretty good though
 * emmajane chuckles at beuno's aversion to documentation.
<emmajane> I promise it's not ALL bad.
<beuno> emmajane, I'm not taking any risks today  ;)
 * emmajane grins.
<emmajane> give me an hour, I'll whip up a screen cast. ;0
<emmajane> ok, maybe four. I'd need to read the documentation first.
<beuno> heh
<RainCT> Hi
 * emmajane waves to RainCT 
 * RainCT waves back :)
<RainCT> Is there some FLOSS good bug tracker which supports bzr (so that you can say "I fixed this bug on revision X")?   (a friend is asking for this o.O)
<emmajane> RainCT, like having a project in Launchpad?
<RainCT> emmajane: yes, but to install on his own server
<emmajane> RainCT, I believe there's a bugzilla plug-in.
<emmajane> and can't you install bugzilla for your own server?
<mkanat> Indeed, indeed.
<mkanat> Although we don't have highlighting in comments for things like "revision X" if that's what you were looking for.
<emmajane> http://www.bugzilla.org/download/
<emmajane> http://bazaar-vcs.org/BzrPlugins is the list of plugins.
<emmajane> I'm not sure how they fit together though. :)
<RainCT> heh OK I'll tell him
<RainCT> thanks :)
<mkanat> bzr has some native support for bugzilla, too.
 * RainCT personally dislikes Bugzilla, though.. :P
<emmajane> RainCT, google might have more ideas too.
<mkanat> RainCT: Awww. :-) It's much nicer nowadays than it used to be, if you used it a long time ago.
<RainCT> mkanat: I've used the version on GNOME and on Mozilla
<mkanat> RainCT: The current mozilla one is representative of what Bugzilla is like out of the box, largely.
<mkanat> RainCT: The GNOME one is a very old version.
<RainCT> and I'm sorry but the interface is nothing against Launchpad :P
<RainCT> well, thanks mkanat and emmajane :)
<mkanat> np. :-)
<jam> RainCT: there is also "bugs everywhere" which was a look at distributed bug tracking from Aaron Bentley
<jam> and I know there is some amount of Trac + bzr work
 * mkanat is still all for Bugzilla... :-D
 * RainCT likes the "bugs everywhere" concept :)
<RainCT> hehe
<beuno> jelmer, any workaround for the orig.tar.gz changing with builddeb?
<jelmer> beuno, ahh, you hit that bug?
<beuno> jelmer, yeah  :(
<poolie> hello
<beuno> I can't upload to multiple releases of Ubuntu
<jelmer> beuno, edit .bzr-builddeb/default.conf and comment out the export-upstream bits
<beuno> heya poolie
<jelmer> it will then use whatever tarball is available in ../tarballs
<jelmer> rather than creating it again
<beuno> jelmer, so I just create a dir in .. named "tarballs", or does it use the tarball in the dir below?
<jelmer> beuno, it uses the tarball in the dir below I think
<jelmer> the defaults have changed recently, I can't remember what they are atm
<Lo-lan-do> jelmer, beuno: You might like to have a look at http://bzr.debian.org/loggerhead/users/lolando/loggerhead/daemonise
<Lo-lan-do> It's rather crude, but I set that up on Alioth and it seems to work.
<Lo-lan-do> (Remove the "loggerhead" component in the URL for the branch)
<jelmer> Lo-lan-do, ah, nice
<Lo-lan-do> Ah, I forgot the logrotate stuff.
<beuno> jelmer, Lo-lan-do, I'll leave it up to you guys to fix/review the daemonizing bits, I don't really know much about it, so, if jelmer approves, I'll merge into trunk  :)
<Lo-lan-do> There, logrotate added.
<beuno> jelmer, I tried downloading the orig file from LP, but it's still complaining. It's the file timestamp, isn't it?
<jelmer> beuno, no, it's the filestamps of the files inside of the tarball
<beuno> well, then it shouldn't break... should it?
<Rob123> Hi all, is it possible to edit commit messages after commiting?
<Lo-lan-do> Rob123: You can uncommit and commit again
<beuno> jelmer, it seems to still be creating the tarball with those lines commented?
<beuno> even though it says:
<Rob123> Lo-lan-do sounds like a good solution but what if I have to edit about 10 revisions back?
<beuno> dpkg-source: info: building loggerhead using existing loggerhead_1.10.orig.tar.gz
<Peng_> Rob123: You can't really. Revisions are immutable.
<Rob123> ah, I used to be able to do this in SVN I think
<Peng_> Yep.
<Peng_> svn is centralized, so it's easier to manage changing data.
<Peng_> Or something.
<Rob123> yeah, that makes sense
<beuno> jelmer, I'll just use the Launchpad copy feature instead  :)
<jelmer> heh, that will work too :-)
<Rob123> ok thanks
<beuno> alright
<beuno> loggerhead is now in PPA
<beuno> it has been released and announced
 * beuno dances
<jelmer> beuno, congrats :-)
<beuno> jelmer, thanks for all the work  ;)
<Peng_> beuno: Congrats. :)
<beuno> Peng_, thanks  :)
<beuno> how's the memory usage for you?
<beuno> still the same or higher?
<Peng_> beuno: Heh, it had been stable for almost a day, but it jumped a bit in the last 1.5 hours. :P
<Peng_> beuno: Anyway, nothing new to add. I have a feeling it might be slightly worse than it used to be, but I have no evidence. It's certainly not a problem.
<beuno> Peng_, I'm still surprised that the latest changes didn't have a significant effect
<beuno> but of course, reality says that it didn't...
 * Peng_ shrugs.
<Peng_> It feels slightly more erratic, but it could actually be better. It's always grown over time, so it's difficult to compare..
<Peng_> ("better" == "lower total usage")
<beuno> heh
<beuno> right
<beuno> the fact is that we haven't found the biggest problem yet
<beuno> Peng_, how do you deal witht he growth?  restart it every now and then?
<mkanat> beuno: That's what I do.
<beuno> mkanat, how often?
<Peng_> Eek
<mkanat> beuno: I'm not really having any trouble on bzr.bugzilla.org though, just on bzr.everythingsolved.com.
<mkanat> beuno: Once a day.
<mkanat> beuno: I have it cronned.
<Peng_> beuno: Yeah. I run the development branches of bzr and loggerhead and plugins anyway, so I have to restart it frequently for upgrades. I don't often restart it for memory use.
<jelmer> fwiw, a similar problem exists in bzr-svn and bzr-fast-import
<jelmer> maybe it's related?
<beuno> jelmer, hm, interesting
<beuno> in bzr-eclipse as well
<Rob123> I need a bzr pattern to 'ignore all files in \/this\/folder except this.file' any ideas?
<beuno> mkanat, http://bzr.everythingsolved.com/ looks pretty broken  :)
<Rob123> ignore backslashes :)
<mkanat> beuno: Yes, that's also true. :-)
<mkanat> beuno: That's with start-loggerhead.
<mkanat> beuno: Whereas bugzilla.org is just using serve-branches.
<emmajane> beuno, nono, "differently styled" ;)
<beuno> jelmer, to be honest, my current plan is to move from threads to sub-processes so that the memory usage gets hidden under the carpet
<beuno> mkanat, ah, so start-loggerhead has a broken theme?
<mkanat> beuno: I think so.
<Peng_> Rob123: Ignore everything, then bzr add the file you want?
<beuno> *sigh*
<mkanat> beuno: I haven't really looked into it much. It might just be on the front page.
<Peng_> beuno: ...Would subprocesses use more memory in any way?
<beuno> Peng_, no, they should use memory, and then die
<jelmer> beuno, would be nice to fix it properly.. bzr-svn, -fast-import and -eclipse can't easily do that :-)
<beuno> so the memory goes with them
<Rob123> Peng_: Oh, wouldn't I get warning messages from bzr that I have a pettern that clashes?
<Rob123> pattern even
<jelmer> beuno, (assuming it's the same problem)
<Peng_> beuno: Fork on every request?
<beuno> jelmer, it would, yes. But I have no idea how to find the problem  :(
<Peng_> Rob123: Ehh. Um. I dunno. I don't remember ever seeing such a warning. Try it! :)
<beuno> Peng_, yeap, and cache the revision graph in sqlite
<Rob123> ok thanks :)
<jelmer> beuno, same here :-(
<Peng_> beuno: Forking hurts performance, though, right?
<Peng_> Says a guy who runs CGI for some things anyway..
<beuno> Peng_, yeah, it may use more CPU. I haven't started work/test with it yet
<beuno> mkanat, why are you using start-loggerhead instead of serve-branches?   I'm curious because we want to kill start-loggerhead
<mkanat> beuno: I need to not publish certain branches broadly.
<Peng_> beuno: Well, I'd be happy to test it. If you're pretty sure it won't crash or eat all my RAM. :)
<mkanat> beuno: They're there in the directory, but I don't want to advertise most of them.
<beuno> jelmer, does the memory usage grow endlessly with -svn?
<beuno> mkanat, gotcha. We'll make sure we allow you to do that with server-branches for the next release then
<jelmer> beuno, as far as I can tell, yes
<jelmer> beuno, it doesn't grow very quickly though
<beuno> Peng_, I will try and test it as much as possible before throwing a branch your way  :)
<jelmer> (not anymore, at least)
<Peng_> beuno: :)
<beuno> jelmer, it doesn't here either, but in LP, it explodes about once a day
<jelmer> hmm
<beuno> maybe it's time we start a thread in the bzr ML?
<beuno> all us consumers of bzrlib  :)
<jelmer> beuno, yeah, I think that may be a good idea
<rexbron> It is possible to merge two branches but only merging changes to existing files?
<bob2> you could merge, commit, rm the formerly new files
<rexbron> bob2: there are a _lot_ of new files... trying to use bzr with debian packaging and a build taht did not cleanup after itself
<zsquareplusc> i have bzr-gtk V0.95 installed as ubuntu package, but when i lauch olive-gtk, the help dialog reports 0.94. and more importantly, it fails to "show log" on my repo.
<zsquareplusc> is there a way to clean up the installations? maybe some file is left over from an older bzr or olive version
<igc> morning all
#bzr 2008-12-23
<poolie> hello igc
<igc> hi poolie
<snot> I'm working on a linux distributed based on ubuntu. I wanna do some version control... is bzr the right tool for such a task?
<Peng_> You could look at how other Debian- and Ubuntu-based distros manage everything.
<snot> Peng_: yeah, but I was just hoping to make a shortcut here and either eliminate bzr or use it straight. the dude who was in chage of this before me didnt do any versioning
<snot> s/straight;2/right away/
<snot> -;2
<snot> :)
<zsquareplusc> snot: ubuntu likes bzr, you can can even have you .deb packages built automatically on lauchpad.net
<snot> zsquareplusc: yeah, this is all very new to me. and it's not opensource so AFAIK launchpad isnt an option
<zsquareplusc> yes, the server side is not yet open
<snot> the distro I'm developing isnt open source :)
<snot> (sadly)
<snot> sort of it actually is...
<zsquareplusc> is it really worth doing your own, compared to just have your custom package repository?
<snot> parts of it isnt shared so I dont belive launchpad is an option... and beside I just wanted to know if I could manage an entire distribution with bzr'
<snot> zsquareplusc: it's a must... it runs on this "thin" box
<snot> a little box with only a flash harddisk and very limited cpu
<zsquareplusc> a big part of a distro are packages or at least the core source of a package from upstream. they will use what they want anyway.
 * zsquareplusc runs debian on a NSLU2 with 1GB flash disk :-)
<snot> indeed... we have our own repository setup as well and I'm very much encuraged to make the mopst changes with packages as well
<snot> mmmm... debian :)
<snot> zsquareplusc: damn... now I want to get a Linksys NSLU2
<snot> I have too little time :)
<zsquareplusc> snot: it doesn't take too much time. its an official platform fore debian. so you have all the stuff you know from larger boxes ;-)  but i think we're a bit OT here..
<snot> zsquareplusc: indeed, I easily get side tracked :)
<snot> I'll go see what I can find at the ubuntu hp, tahnks for your time, take care :)
<zsquareplusc> so you want to trac a few package sources. i've not yet used bzr for large things, but i got the impression that is should be quick on larger trees too
<snot> that as well and I got that setup already. I did bzr init, bzr add and bzr ci -m 'inti... bla bla as we spoke
<snot> it does not seem fast but it seems to... well work
<snot> I just wanna version whatever changes I make to etc the users home folder and such
<snot> I think I'll just give it a try and see how this goes
<snot> in case anyone cares, I can inform that it didnt go... it's way way too slow
<snot> I'm handling about 120000 files and bzr st took about 8 mins to execute... I'll have to find another way
<snot> hmm... the second time I executed bzr st it went quite a lot faster
<snot> http://nopaste.org/p/aJ4kY0sWg
<jam> lrrrr
<igc> hi jam
<jam> sorry cleaning the keyboard :)
<igc> 'lrrrr' ???
<jam> hi, btw
<jam> snot: that URL gives me a 404
<jam> I would guess the first time is computing the sha sum for all files
<fullermd> igc: Obviously, his yox was already clean   :p
<jam> and from there on it should be just doing a stat
<jam> Though with 120k files
<jam> it is possible to have the OS take a long time to page in the inodes
<jam> after say a restart
<igc> fulermd: obviously :-)
<jam> snot: also, what version of bzr?
<snot> jam: yeah, sorry, I deleted it... had a few lines I didnt felt like sharing anyway. but the second time around it only took about 19 secs
<jam> I thought the code had been updated in 1.8 so that it would update the sha values during commit
<snot> Bazaar (bzr) 1.6.1
<jam> snot: ok, so some of that should be better with newer versions of bzr
<snot> so version 1.8 might be worth a try
<snot> true, damn now I'm lagging also
<igc> poolie: if you get a chance, can you have a look at my 1.12-preview formats patch?
<igc> (the filtered-views patch will be quite a bit smaller once that's landed)
<poolie> igc, i can
<ia> hello, everybody. could you tell me please, in which articles or docs i can found some internal information about bazaar? for example, practically any user of git knows, that it uses sha1 for store objects, how it save content, etc. Does exists some docs about this for bzr? i just would like to know internal concept of bzr and how it works.
<nosklo> ia, source code is pretty comprehensive
<jelmer> ia: see also doc/developers/ in the source tarball
<igc> ia: see http://doc.bazaar-vcs.org/bzr.dev/developers/index.html
<igc> thanks poolie
<markh> igc: hi ian - some advice on docstring folding in your review if you don't mind:
<markh> eg: >> +    def get_canonical_inventory_paths(self, paths):
<markh> >> +        """Returns a list with each item the first path that
<markh> >> +        case-insensitively matches the specified input paths.
<markh> Its ok to make that a single line, which would end at char 115?  I can't see how to obviously shorten it...
<igc> mrkh: hmmm
<markh> actually, I could shorten that to make it the "singular" version, and just make the "plural" version's docstring refer to the shorter one...
<igc> markh: sounds sensible
<igc> going over 80 is ok but 115 is a bit long
<markh> so to be clear, while the docstring can go over 80 chars, there is a kinda fuzzy "sensible" upper limit probably ~100?
<markh> yeah
<poolie> hello markh
<markh> hi poolie
<poolie> abentley, if you're here, BB is apparently stuck...
 * igc bbl
<Leefmc> Question: Bzr has taken a branch and saved a push location that i do not want (originally i pushed to "temp_branch", and now it is always using that push branch as the default), how can i remove/overwrite this saved location?
<bob2> push --rememver somewhereelse
<bob2> or edit .bzr/branch.conf (iirc)
<Leefmc> k thanks
<Peng_> That'd be .bzr/branch/branch.conf.
<Peng_> It's easier to use "bzr push --remember" unless you want to delete the saved location completely.
<abentley> poolie: fixed
<ia> hello. could you tell me please, does bzr has any color support (or some plugin, maybe) for output of basics commands and actions? (something like [colors] section in .gitconfig)
<LarstiQ> ia: there is color diff in bzrtools at least
<IslandUsurper> Interesting. I have a shared repository that contains a checkout of a project on a different server. I then made a lightweight checkout from the repo. Apparently local commits from the lightweight checkout work just like I expect them to. Uncommitting didn't, because I had to update and then revert the pending merge, but that's ok.
<ia> in 'bzr viz' there is 'summary' column; how get this information from command line?
<ia> oh, via 'bzr log' - in summary shows just commit messages. :-)
<cr3> I have a general revision control question: lets say I branch my project for a particular release, 0.2 for example, does that imply the trunk should now be on 0.3 or can it still progress on 0.2 releases?
<beuno> cr3, so, trunk can be "trunk", and not a version
<beuno> and you only assign version numbers to release branches
<beuno> but there's probable a dozen different ways of working
<cr3> beuno: but when I make changes to the changelog under the trunk...
<beuno> cr3, personally, I keep the top section of the changelog as "development"
<beuno> and only rename that when it's spun off to a release
<MattCampbell> I see that no Windows installer is available yet for bzr 1.10.  Is this just because the bzr team needs someone with Windows to build one?
<Emmanuel> Hi , i would like to know if anyone would be aware of any recent benchmark ( as suggested on Bazaar web site ) of bzr,hg,git ... ?
<kfogel> I've got a patch ready to suggest for merging.  Couple of questions: the change is actually two revisions (3910 and 3911 in branch http://bazaar.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent).  Can I post a "[MERGE]" request just pointing at that branch, or should I package up the changes as a "bundle" and attach that to the mail?
<kfogel> (I guess that's my main question.)
<bob2> bundles are more common these days
<beuno> kfogel, a bundle is the only way to file merge requests in bzr
<kfogel> beuno: thanks
<beuno> make sure you do a send against a recent version of bzr.dev so it applies cleanly  :)
<bob2> you sure?
<bob2> HACKING needs an update then
<beuno> bob2, where?
<beuno> it says generate a bundle
<beuno> AFAICS
<bob2> "If you'd like to propose a change, please post to the
<bob2> bazaar@lists.canonical.com list with a bundle, patch, or link to a
<fullermd> Merge directives don't have to contain the bundled revs; they can point at a branch.
<bob2> branch"
<jam> beuno: you can send a branch, or you can send a patch, or you can send a lot of things with [MERGE] in the header, and bundle buggy will track them.
<fullermd> (I don't know how BB deals with that, but...)
<jam> We just highly recommend sending a bundle
<jam> because it is far easier for us to review it.
<beuno> oh, I didn't know BB was so smart...
<jam> Anything with [MERGE] gets tracked
<jam> even if there aren't any attachments
<beuno> right, but not the diff and such
<jam> right
<jam> which is why we *prefer* getting a bundle sent :)
<beuno> got it  :)
<kfogel> beuno: just some sanity checking.  I have a branch locally (call it LB) that was created by 'bzr branch lp:~kfogel/bzr/306394-status-tolerate-nonexistent LB'.  Then I committed my two changes in LB (3910 and 3911), and did 'bzr push' to send them up to the parent.  Now in my LB directory, I just need to do 'bzr send -o fix-306394.patch' and that will create the right bundle?  (Because I did that, but it's hard for me to tell if the resultant
<kfogel> bundle contains the right stuff...)
<kfogel> FWIW, I only did the 'bzr push'es so people could review the changes; I understand that pushing them up was not necessary to make the bundle in LB.
<jam> kfogel: to be *positive* you can do "bzr send -o fix...  http://bazaar-vcs.org/bzr/bzr.dev"
<kfogel> jam: hmmm.  I'll do 'bzr help send' now to grok that command :-).
<jam> That will ensure the target branch is set correctly, and that the bundle applies to the target branch
<jam> kfogel: you are setting "SUBMIT_BRANCH" which is the branch that you want the bundle applied to
<kfogel> jam: ENLIGHTENMENT.
<kfogel> Thank you.
<jam> kfogel: happy to help. There are other ways, like using a local mirror with the public_branch set, but that is the most straightforward
<kfogel> jam: one thing I'm slowly getting used to is that there are usually 3 to 5 different ways to do anything.
<kfogel> :-)
<kfogel> That's a sign of a flexible tool, I think, but also means a steep learning curve.
<LarstiQ> indeed.
<igc> kfogel: send needs a bit more love in the User Guide I think
<LarstiQ> the wealth of workflow posibilities can be rather overwhelming.
<igc> specially when to comes to patches on top of patches and stuff like that
<kfogel> LarstiQ: exactly
<kfogel> igc: mmm, yes
<kfogel> wouldn't hurt
<kfogel> jam: Fascinating!  When I included a SUBMIT_BRANCH in the 'bzr send' command this time, my bundle looks completely different: it includes a human-readable diff now, and the encoded bundle portion at the end is much larger than it was the first time (when I did not use a SUBMIT_BRANCH).
<kfogel> jam: One thing that's too bad, though, is that my log messages are not included in human-readable form in this new bundle.
<kfogel> Question: some [MERGE] requests attach the bundle, others just include it inline in the body of the mail.
<kfogel> Is one way better than the other?  http://bazaar-vcs.org/BzrGivingBack says to attach.
 * LarstiQ attaches.
<LarstiQ> kfogel: just make sure the content encoding isn't set to something so mail readers won't show it as text
<LarstiQ> since reviewing from within the mail client is nice
 * LarstiQ forgets which clients mail patches like that
<LarstiQ> mutt plays nice :)
<kfogel> LarstiQ: oh, I can make sure it's text/plain or text/x-patch or whatever.  But the easiest thing is just to include it inline, as some people seem to do.  I can't tell whether that's "officially approved" though.
<kfogel> :-)
<LarstiQ> kfogel: applying the patch would then a bit more work I guess, I have no strong opinion on it though.
<LarstiQ> kfogel: so I'd say, try it and see if you get away with it ;)
<fullermd> Wait...  there are people who use something other than mutt?
 * kfogel growls "Gnus"
<fullermd> That sounds like a nasty throat infection you've got there...
<jam> kfogel: Without setting the SUBMIT_BRANCH it defaults to the parent, IIRC. Which would mean submitting a bundle that doesn't include any changes, because your parent == your local branch
<jam> Which is why you get a better result the other way
<jam> We don't include the log messages by default, though BundleBuggy is capable of extracting them
<jam> that said, it often doesn't matter, as we'd rather have a nice human summary
<jam> which isn't always present in the log messages.
<jam> especially since we'd like explanations, etc.
<jam> I would recommend attaching the bundle
<kfogel> jam: it's sent
<jam> because it makes it easier *for me* to download and apply it
<jam> I think it is easier for BB as well, but I'm not sure.
<kfogel> jam: I guess "log message" can mean the individual log msg associated with each commit in the bundle, and then (in theory?) a summary message explaining the bundle itself.  Which I should have passed with -m or -F to 'bzr send', right?  (I didn't.)
<jam> I believe "-m" just sets the subject
<kfogel> ah
<jam> so it has no effect her
<jam> here
<kfogel> jam: that explains why bzr send does not take -F, but bzr commit does.
<jam> Older bundle formats actually had a summary message it would display
<jam> but we didn't really use it
<kfogel> jam: so there's no way for one to attach such a summary to a bundle, as a kind of log message?  Instead one just includes it in the mail where one is submitting the bundle?
<jam> kfogel: yep
<jam> kfogel: Your "trivial typo fix" email doesn't seem to actually have a bundle
<jam> Just a *description* of the attachment it wanted to send
<jam> <#part type="text/x-diff" filename="~/src/bzr/bzr.dev/fix-typo.patch"
<kfogel> ???
<kfogel> jam: mail client error.  That's weird.  I'll resend.
<kfogel> thanks
#bzr 2008-12-24
 * LeoNerd unsubs from the mailing list
<LeoNerd> This is just waaaaay too busy for me to keep up with :/
<jelmer> LeoNerd, hmm? I thought it was actually pretty quiet lately..
<poolie> jml, hi?
 * igc lunch
<jml> poolie: hi
<jml> poolie: I'm not at work today.
<poolie> hi
<poolie> jml, i just realized that
<poolie> enjoy your holidays
<DBO> is it possible to make one bzr branch just eat all the files of another bzr branch that has no common ancestor
<poolie> DBO, 'bzr merge -r 0.. OTHER_BRANCH'
<DBO> poolie, slightly too late =(
<DBO> just did it all by hand
<poolie> sorry
<bobesponja> hi
<bobesponja> is there a way to do a partial checkout of a branch?
<igc> bobesponja: not yet. See http://bazaar-vcs.org/FilteredViews for the latest on progress towards this feature.
<bobesponja> ok thanks
<igc> time for my xmas holiday/break
<igc> see you all next year
<CaMason> Hi guys.. I just tried to so a bzr branch over sftp on Vista x64, and I got a BSOD :o
<CaMason> if I do a branch on my linux machine, then copy that over to windows, will it work
<CaMason> ?
<Jc2k> xD
<jelmer> Jc2k, hi
<jam> bzr co
<jam> mt
<rexbron> hello, is it possible to change the dpkg-buildpackage command that --source uses in bzr-builddeb?
<rexbron> ie. via an environment var or something?
<LarstiQ> rexbron: could you give some more context? What are you trying to do?
<jelmer> rexbron, yes, I think it's mentioned in the bzr-builddeb docs (can't remember off the top of my head)
<rexbron> LarstiQ: in the bzr-bd man page is states that --source defaults to "dpkg-buildpackage -rfakeroot -us -uc -S". Looking closer, I see it mentions that it can use config files, but no reference is made as to 1) where those config files should be/are and 2) the format those config files should take
 * LarstiQ looks at bd docs
<LarstiQ> rexbron: I'd assume regular bazaar configuration mechanisms
 * rexbron found the README :P
<LarstiQ> rexbron: the README states, .bzr-builddeb/local.conf in the package directory, ~/.bazaar/builddeb.conf and .bzr-builddeb/default.conf in the package directory
<LarstiQ> right :)
<rexbron> 199 		    The command used to build a source package if the ``--short`` or ``-S``
<rexbron> 200 	69.1.7 	    options are used.
<rexbron> hmm, is --short supposed to be --source?
<james_w> rexbron: it is, yes
<james_w> http://jameswestby.net/bzr/builddeb/user_manual/configuration.html
<rexbron> james_w: what would be the best way of adding additonal export profiles? ie. my builder command for the archives would be different from the one I would use for revu.
<rexbron> is it possible to do so from the .conf files?
<james_w> not currently
<james_w> I want to add that sort of ability, but I've not come up with a good way to do it yet
<rexbron> james_w: is this a planned feature already? Shall I draw up a spec?
<james_w> if you have a good idea of how it should work I would love to hear it
<rexbron> james_w: just thinking here, the same way that we can pull the value of builder from config file, perhaps it would be possible to also define a way to have bzr-bd associate command-line switches
<rexbron> something along the lines of if --revu is passed and is in a .conf file, use this builder string
<james_w> not sure about that
<james_w> you could have "--builder-profile revu" which makes it look up "revu-builder" in the configuration
<rexbron> and a short alias for brevity :)
<james_w> :-)
<rexbron> that would simpify things for me and strikes me as something that people will want as Ubuntu moves towards bzr and bzr-bd as the primary tools for handeling packages
<james_w> probably
<james_w> we also need a way to easily add e.g. "-sa" to the build
<james_w> separate "profiles" to do that seems like a bit of overkill
<rexbron> james_w: profiles would be an extendable way to impliment that, while seeming like overkill would prevent this sort of problem from ocuring further down the line. I would sugget that either bzr-bd or another package in ubuntu ship a set of commonly used profiles.
<james_w> yup
<rexbron> james_w: so now it all comes down to getting someone motivated to do it ;)
<james_w> heh :-)
<rexbron> james_w: I'll take a stab at it, but I am a real amature
<james_w> it shouldn't be too hard
<james_w> famous last words :-)
<james_w> that would be great though, thanks
<rexbron> james_w: I am really wondering what the best way to go about this is
<rexbron> james_w: I am wondering if implementing something like the way hooks work...
<rexbron> would be the best way to go
<james_w> I don't see how
<rexbron> james_w: basically specifying a section like [PROFILES]
<james_w> ah
<james_w> yeah, that could work
<rexbron> and either specifying profile = revu
<rexbron> builder = ..
<rexbron> and so on an so forth
<rexbron> or whether it would be better to merge the profile name into the variable
<james_w> revu = debuild --whatever
<james_w> would work
<james_w> or it could go in to the [BUILDDEB] section as "revu-builder"
<rexbron> james_w: or better might be rather than have a section called profiles, just use the profile name there instead
<james_w> rexbron: yeah, I agree
<dash> anybody know who I could talk to about bzr-builddeb? :)
<james_w> heh
<dash> aha
<james_w> hello dash
<dash> that name looks familiar. :)
<dash> so, i'm adding debian packaging to a project I developed in bzr
<dash> it uses autotools
<dash> i don't keep 'configure' and other generated stuff in the repo, just the sources (configure.ac, Makefile.am)
<dash> is there a way to get bzr-builddeb to run autoreconf before starting dpkg-buildpackage?
<dash> i could added it to debian/rules, but I wouldn't want to run it if building from a tarball
<dash> any ideas? :)
<james_w> dash: http://jameswestby.net/bzr/builddeb/user_manual/hooks.html
<dash> aha, hooks
<dash> i should have read that. :)
<dash> that does the trick
<dash> james_w: thank you. hope your Christmas is full of merges and conflict-free. :)
<james_w> heh. thanks :-)
<rexbron> james_w: I think I just got it to work :D
<james_w> cool
<Jc2k> jelmer: hi
<jelmer> Jc2k, hi!
<jelmer> Jc2k, I've added a dul-fetch-pack command that seems to work
<Jc2k> cool!
<jelmer> Jc2k: Your upload-pack command doesn't seem tested yet in the server?
 * jelmer now needs to figure out how the pack filename is determined
<Jc2k> pack-sha1ofpack.pack
<Jc2k> ?
 * Jc2k is on phone
<jelmer> Jc2k, it's a sha1, but I'm not quite sure of what yet. It's not the sha1 of the pack file or its index at least
<Jc2k> i just assumed it was the sha1 of the pack (minus the 20 byte sha footer) :(
<Arjen> jelmer: I think you can find the answer in pack-write.c (if you're talking about Git packfiles)
<Jc2k> jelmer: am gonna pull the git backend out of the daemon and into dulwich/server.py (planning to add dul-receive-pack and dul-upload-pack)
<jelmer> Arjen: That assumes the sha1 is already calculated elsewhere (it uses sha1 in struct packed_git)
<Jc2k> unless there is a better place
<jelmer> Jc2k, you mean dul-receive-pack and dul-upload-pack as separate binaries ? :-/
<Jc2k> jelmer: just for testing purposes - they'll basically be little stubs..
<jelmer> Jc2k, ah, ok
<Jc2k> jelmer: then i can plumb them directly to git with git-fetch-pack --exec=dul-upload-pack or whatever the syntax is]
<rexbron> Interesting error: https://code.edge.launchpad.net/~rexbron/bzr-builddeb/trunk.profiles
<jelmer> Jc2k: So dul-daemon will still be using the internal code?
<rexbron> something about an internal check failing
<Jc2k> jelmer: yeah, it becomes about 3 lines importing TCPGitServer and GitBackend and then calling TCPGitServer.serve_forever
<jelmer> Jc2k: Ah, makes sense
<rexbron> Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2def190> has delta references to items not in its repository: {'inventories': [('jw+debian@jameswestby.net-20081202164232-17kqr0tsvqy3ebyi',)], 'texts': [('config.py-20060816235838-wk9rk801k2fdaihy-3', 'jw+debian@jameswestby.net-20080529233852-6p0p3xd8198fx20t'), ('readme-20060917150309-xbse5n20p61fw62z-1', 'jw+debian@jameswestby.net-20080910170020
<rexbron> -6helfl8ag97p4sgt')]}
<jelmer> rexbron, is this a stacked branch?
<Jc2k> jelmer: don't worry, im not going to start doing forky things :p
<rexbron> jelmer: yes, but this is only LP's side only
<rexbron> s/only//
<jelmer> rexbron, looks like a stacking bug to me, there were some issues like this fixed recently
<rexbron> jelmer: would it be a client or server side bug?
<jelmer> rexbron, no idea, sorry
<james_w> I think that was a bug fixed in a recent client
 * rexbron goes to see if it hit jaunty
<jelmer> Jc2k, found it
<jelmer> Jc2k, it's the sha1 over the object sha1s in the pack
<rexbron> james_w: would deleting the branch and re-pushing it potentially avoid the error
<james_w> rexbron: yes, if you have a fixed client
<LarstiQ> jelmer: so then you know not to fetch the pack if you have all objects, or what?
<jelmer> LarstiQ, I think the main intent is that it would be unique
<jelmer> And deterministic
<LarstiQ> hmm
<Jc2k> it means lots of people can push at once and not collide
<LarstiQ> Jc2k: ah yes, and if the pack is already there, no need to push it, since all your object are there
<Jc2k> well, it doesnt care about the pack
<Jc2k> just the objects
<LarstiQ> how would people collide then if not for the naming?
<Jc2k> the objects would be duplicated :)
<Jc2k> git just checks all pack indexes until it finds a match, so objects can be duplicated until the next git repack
<LarstiQ> ah
<rexbron> I just noticed that the bzr PPA does not build packages for Jaunty, would this be possible?
<LarstiQ> ~/bzr/+archive has loggerhead-1.10 for jaunty
<LarstiQ> rexbron: https://edge.launchpad.net/~bzr-nightly-ppa/+archive though
<rexbron> LarstiQ: thanks
<asabil> jelmer: I just checked out dulwich, and ran the unit tests, it seems like 1 test case is failing
<asabil> is that a known issue ?
<Jc2k> jelmer: pushed dul-upload-pack and dul-receive-pack, untested atm (on a mini mini laptop which is making me want to cry)
<Jc2k> jelmer: what are you thinking about re tests and the server code?
 * Jc2k wants tests v v v v much
 * LarstiQ offers jc2k his 3 kilo laptop in exchange for the mini laptop
 * Jc2k has an XPS GEN2 at home, so declines :p
<jelmer> asabil, yeah, that's right. I haven't checkout out what's causing it yet
<jelmer> Jc2k, Yeah, we need heavy testing
 * Jc2k agrees
<Jc2k> i wanted to test it directly against the client side git components
<jelmer> hmm, looks like the delta resolution can use some more work. It works, it's just not very fast
<Jc2k> also pushed some protocol doc. its not much atm, but adds a bit more to upstream docs.
<rexbron> bzr-bd review request: https://code.edge.launchpad.net/~rexbron/bzr-builddeb/trunk.profiles/+merge/2535
<jelmer> rexbron, this seems pretty similar to "source-builder" setting in the bzr-builddeb config?
<rexbron> jelmer: what if you have multiple targets for your source builds?
<jelmer> rexbron, what do you mean with multiple targets specifically?
<rexbron> jelmer: I need to use different dpkg-buildpackage options to upload to REVU as I would for the main ubuntu archives.
<rexbron> for example, revu always requires a full-source upload
<jelmer> rexbron, ah, ok
<jelmer> rexbron, that makes more sense
<rexbron> james_w and I discussed this earlier today and came to the conclusion that this is more extendable solution
<jelmer> Jc2k, hmm, if I send "have" lines the server suddenly hangs up on me
<Jc2k> jelmer: i havent tested that yet - got distracted by the corrupt packs
<Peng_> jelmer: Not to try to rush you, but is anything going to become of 308353, or am I gonna be stuck on bzr-svn 0.4 or something?
<Peng_> Err, bug 308353
<ubottu> Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Triaged] https://launchpad.net/bugs/308353
<Jc2k> jelmer: will have a look when i've wrapped my mums xmas present!
<Peng_> Like I said, I'm not trying to rush you. I'd just like to know it's somewhere on your todo list.
<jelmer> Peng_, I *may* get to it in the next two days, otherwise it'll probably be in one of the first days of the new year
<Peng_> jelmer: Ok. Thank you. :)
<asabil> jelmer: concerning the test failure in dulwich, I think the test case is wrong
<asabil> the ordering of the expected result seems reverted
<asabil> s/revert/invert/
<Jc2k> jelmer: hang up with no error, or something else?
<jelmer> Jc2k, never mind that, I've already fixed it
<jelmer> asabil, as I said, I haven't really looked into it yet
<jelmer> asabil, patches welcome, though :-)
<asabil> jelmer: yeah sure, I will try to push a branch when I get more confident about my checks
<jelmer> ah, I know why the delta resolving is slow
<jelmer> it's in an infinite loop :-P
<Jc2k> :p
<Jc2k> jelmer: do you have any thoughts on testing server.py?
<Jc2k> if not im going to knock up something that should work, but im not sure where it lands on the dirty scale
<jelmer> Jc2k, well, some ad-hoc tests won't hurt
<jelmer> Jc2k, It would also be nice to test the client against the server
<jelmer> but it's also good to test outside of that, to make sure they're not both broken :-)
<Jc2k> :]
<Jc2k> i was thinking dummy backend + pre-recorded streams to replay at client
<Jc2k> **SERVER
<Jc2k> idef send_fn(data): sys.stdout.write(data) sys.stdout.flush()
<Jc2k> oops
<Jc2k> damn tiny laptop
<Jc2k> is the client pushed somewhere?
<Jc2k> i merged lp:jelmer
<Jc2k> /dul/trunk
<jelmer> http://people.samba.org/bzr/jelmer/dulwich/trunk
<jelmer> Jc2k, ^
 * Jc2k merges, commits, pushes
<jelmer> Jc2k: hardcoding some streams doesn't seem to ugly to me
<jelmer> the main issue would be the readability, and the size of the tests
<Jc2k> i was going to reuse the pkt line stuff from server.py
<Jc2k> so it would be a bit less eww..
<Jc2k> i wanted to try integrating dul-* foo into the git test suite if its not too bad..
<Jc2k> i think we can factor some of client and server code out into protocol.py ?
<Jc2k> like the pkt_line stuff and sideband stuff.
<Jc2k> and possbily capabilities
<jelmer> Jc2k, yeah, I think that would be useful
<Jc2k> jelmer: just pushed a protocol.py and made client and server use it
<Jc2k> im a bit drunk and theres no coverage so YMMV :)
<Jc2k> *test
<Jc2k> jelmer: going to write some tests that poke the server stuff via protocol.py
<Jc2k> jelmer: how about an object with 2 read/write pairs
<jelmer> Jc2k: :-)
<jelmer> Jc2k, btw, do you have any objection to having all new code being GPLv2+ like bzrlib rather than GPLv2?
<Jc2k> none at all
<Jc2k> though i wrote some of this on work time so i should probably check..
<jelmer> Jc2k: k
<Jc2k> tests: i dont want to enter blocking hell by trying to test my server directly, so was thinking about a buffer object where i created an expected conversation (a buffer to read from, and a buffer off what to expect the server to send)
<Jc2k> THEN invoke the server handler with a read_fn and write_fn that just operate on the buffer
<Jc2k> exploding if the output differs.
<jelmer> that doesn't ensure that a packet in the read buffer comes before one in the write buffer and vice versa though?
<Jc2k> blocking hell it is, i guess :o
<Jc2k> or i could make my test case yield
<Jc2k> i dont have enough brain for that tonight..
<Jc2k> the conversation builder idea could be modified to be a single buffer of tuples ('r', 'foo'), ('w', 'bar'). the yieldy approach would just remove the buffer and be a pull instead of a push
<Jc2k> all so messy.
<Jc2k> i might just wait to see how you test the client :P
<jelmer> heh, ok
<jelmer> cycling time, back in ~45 min
<Jc2k> jelmer: moved the send_cmd stuff as AFAIK its tcp/ip specific - so now the GitClient class should work for git+ssh:// access for when i start jabbing things with the git tests
#bzr 2008-12-25
<jelmer> Jc2k, re
<jelmer> Jc2k, k
<Jc2k>  :)
<Odd_Bloke> Merry Christmas, #bzr. :)
<jelmer> merry christmas Odd_Bloke :-)
<SnowyOwl> Hello colleagues, and Merry Christmas!
<SnowyOwl> I keep getting 'ImportError: no module named commands' with TortoiseBzr from bzr-setup-1.10-1.exe
<SnowyOwl> on several systems, most of them were working well with bzr-setup-1.9.exe
<Spaz> merry christmas :)
<Jc2k> merry christmas.
<jelmer> merry christmas :-)
<jelmer> hi Jc2k
<Jc2k> *blinks*
<Jc2k> i was just going to ping you jelmer :)
<Jc2k> push and clone against server.py are working again
<jelmer> ah cool
 * jelmer merges
<Jc2k> hopefully pull too, really need tests gah :p
<magcius> Is bzr daemonless?
<jelmer> magcius, not sure what you mean with daemonless
<magcius> Does there need to be a server running like traditional VCS toold?
<magcius> tools*
<jelmer> magcius, you can pull / push to a remote server without a bzr-specific daemon necessarily running on that server
<magcius> jelmer, so it uses WebDAV?
<jelmer> magcius: But you can optionally use a server on the remote side, for better performance
<jelmer> magcius, the main "dumb" transport that seems to be used is sftp
<jelmer> magcius, ftp is also supported out of the box, and there is a plugin for webdav
<magcius> Ah. Okay.
<jelmer> Jc2k: I'm working on getting packs fixed, and on supporting fetch from remote in bzr-git
<Jc2k> jelmer: okie dokie. i'm tempted to move the pack generation out of server.py and make client.py use it
<jelmer> Jc2k: Go for it :-)
<Jc2k> jelmer: im a bit cautious of moving anything to pack.py as i need to go via the repo object.. dont like the bouncy-around-dependencies :\ am i just being over sensitive, or shall i add packwriter.py/packbuilder.py?
<magcius> Is there a bzr emacs ... err.. hook?
<asabil> magcius: there is the emacs dvc mode iirc, and it does support bzr
<jelmer> Jc2k, yeah, same here. What do you need the repo object for?
<magcius> asabil, not according to this here HOWTO
<asabil> magcius: http://www.xsteve.at/prg/emacs_dvc/dvc.html#table
<Jc2k> jelmer: if i'm building a pack, i walk the dag to work out what objects to send. currently i use the repo both for the tree() /commit() methods and because in theory i might be generating a pack out of loose objects
<jelmer> Jc2k, perhaps just extract out a function that works out what objects to send based on a list of shas and a callback for get_object ?
<Jc2k> it would need def pack_contents(want, have, get_commit, get_tree)..
<Jc2k> i guess i could also follow the bzr pattern and have a wrapper on the repo object that fills in get_commit and get_tree for me
<ia> hello. for example, i create branch from other place. does exist some way to check for available changes in origin branch without 'bzr update' run?
<jelmer> Jc2k, You can just use get_object() rather than get_commit / get_tree; they do the same thing
<jelmer> ia, "bzr missing <url>"
<ia> jelmer: oh, thank you very much. that's exactly what i looking for :-)
<jelmer> Jc2k, updating my samba tree is actually already pretty quick
<sohail> for bzr, how can I get the last checkin to a specific directory?
<sohail> with svn, I'd just do svn log /path/to/dir | head -n 1 or something
<magcius> sohail, do you want the checkin time or the revision number?
<sohail> magcius, I want the revision number
<sohail> I tried bzr revno /path/to/dir but that gives me the revno for the whole repo not that directory
<beuno> sohail, changes to the dir, or anything in it?
<sohail> beuno, anything in it actually
<magcius> I think each revision is a branch, so it can't distinguish non-changed files
<beuno> sohail, right, I don't think you can do that with the bzr client
<beuno> maybe bzrlib, if you're into python
<sohail> :-O
<sohail> oh well, I need it to overcome a slight design miscalculation in my build automation but I'm still surprised
<sohail> I'd rather fix that than figure out bzrlib :-)
<sohail> thanks for your help!
<beuno> :)
<beuno> file bugs, everyone lines bugs in bzr
<sohail> I assume you mean to say likes bugs
<beuno> ah, yes
<beuno> I do
<A_Bach> im looking for configuration eclipse + bazaar plugin help...
<mtaylor> lifeless: around?
<bewst1> bzr-svn is giving me headaches.  I'm trying to push and it tells me the branches have diverged and I need to merge first, which is certainly false.  I merge anyway and it says "nothing to do," and I loop back to the beginning :(.  Any help?
<jelmer> bewst1, did you commit your merge?
<jelmer> bewst1, or do you perhaps have any local changes?
<jelmer> bewst1, what version of bzr-svn are you using?
<bewst1> jelmer: I don't know what it means to "commit a merge."  I did commit one file that I have changed, but I still have some changed files in my working copy that I don't want to push.  So, yes, I have local changes
<jelmer> bewst1, and the branch you're pushing to has no changes you don't have locally?
<bewst1> That's correct
<bewst1> double checking...
<bewst1> Why does everything seem to go so slowly?
<bewst1> Yep, pull says "no revisions to pull" and merge says "nothing to do."
<jelmer> bewst1, and you're pulling from the same location that you're pushing to?
<jelmer> bewst1, what does "bzr missing <push-url>" say?
<bewst1> yes, pull and push locations match
<jelmer> bewst1, what version of bzr-svn are you running?
<bewst1> bzr missing says I have 4 extra revisions.
<bewst1> How to check the bzr-svn version?
<jelmer> bewst1, "bzr plugins" should print it
<bewst1> 0.4.13
<bewst1> It's what Intrepid gives me by default
<bewst1> I don't know what this "4 extra revisions" business is; I'm going to look at it
<bewst1> Oh, it also says I'm missing 13 revisions
<jelmer> bewst1, that would explain the divergence
<jelmer> not sure why pull doesn't do anything though
<bewst1> How is that possible?  Those revisions are basically the whole history of the file
<bewst1> Maybe I did a lightweight branch?
<jelmer> bewst1, did you change the branching scheme recently?
<jelmer> bewst1, is the branch public?
<bewst1> Sorry, n00b.  What is a branching scheme?
<bewst1> The svn branch is not public
<jelmer> bewst1, if you don't know I guess you haven't changed it :-)
<bewst1> the bzr branch is in a local repo on my machine
<bewst1> I don't know from public bzr branches
<bewst1> The svn branch is... a branch of some svn trunk.  The 13 branches missing appear to be those that were made on trunk before the svn branch
<bewst1> Does that help?
<bewst1> The 4 "extra" revisions appear to be the ones made in the svn branch plus the one I committed to my bzr repo and am trying to push
<jelmer> bewst1, if you run "bzr missing --show-ids" are the revision ids for the revisions the same?
<bewst1> Sorry, the same as /what/?
<jelmer> bewst1, the revisions in the svn branch as reported by "bzr missing"
<jelmer> since "bzr missing" would report some revisions twice in the "missing" and the "extra" listings
<bewst1> ?? without the --show-ids, no ids are reported.  Do you mean "are the revisions numbers the same?"
<jelmer> bewst1, no, the revision ids
<jelmer> bewst1, if you run "bzr missing --show-ids", it should report a list of revisions that's missing locally and a list of revisions that's extra locally
<bewst1> jelmer: yes
<jelmer> bewst1, for each revision it should print the revision id
<bewst1> ues
<bewst1> yes
<bewst1> compare that id with what?
<jelmer> bewst1, if I understand you correctly, some revisions are listed in both the first and the last list
<bewst1> first? last?  Sorry, I don't know what you mean
<jelmer> bewst1, some revisions are in both the "locally missing" /and/ the "locally extra" list, right?
<bewst1> no
<jelmer> not sure I follow you then
<bewst1> The "locally extra" list contains revisions made in the svn branch, plus the one I committed to my local bzr repo.  The "locally missing" list contains revisions made in the svn trunk before the svn branch point
<bewst1> Taken together that appears to be *all* of the revisions of the one file that I changed in the local repo
<bewst1> Sorry, I should have said "directory," not "file"
<jelmer> bewst1, can you pastebin the "bzr missing" output? just the revision-id for each commit should be sufficient
<bewst1> http://dpaste.com/102508/
<bewst1> The only revision made in the bzr repo is on line 1
<bewst1> Lines 2-4 are revisions made to the svn branch
<bewst1> The rest are revisions made to the svn trunk
<bewst1> jelmer: nothing jumps out at you?
<jelmer> bewst1, it does actually
<jelmer> bewst1, the branching scheme has changed underneath you
<bewst1> possibly when we upgraded to svn 1.5?
<bewst1> I'm still not sure what a branching scheme is ;-)
<jelmer> bewst1, (fwiw, this bug is fixed in bzr-svn 0.5, which no longer has branching schemes)
<jelmer> bewst1, it should be possible to work around it though
<bewst1> Why don't I just upgrade?
<bewst1> I'd rather get something that works than get involved in workarounds.
<jelmer> bewst1, 0.5 is still in development, and requires bzr 1.10
<jelmer> bewst1, the workaround shouldn't be too bad
<bewst1> listening
<jelmer> bewst1, in ~/.bazaar/subversion.conf, set "branching-scheme = trunk2" in the section [bbad15d5-7c10-0410-ba9e-f711d5c1d17a]
<bewst1> How is it possible that the branching scheme, which is not a concept I even know about, has changed?
<jelmer> bewst1, bzr-svn detects it based on the URL used
<bewst1> Oh... well, there's a little problem with the svn+ prefix which I have occasionally ommitted and then added back
<bewst1> bzr-svn complained that it was deprecated, but then wouldn't do something unless I supplied it.
<jelmer> bewst1, yeah, that's a known bug (in bzr itself)
<bewst1> OK, so I'll try this workaround
<jelmer> maybe also set "branching-scheme-mandatory = True"
<bewst1> jelmer: same result without mandatory.  Will try that next
<bewst1> btw, it changes the branching scheme back to what it was when it fails
<bewst1> It's not failing... yet.  But damn it's slow
<bewst1> Finally it asked for my svn password twice and failed with an internal error.
<jelmer> internal error?
<bewst1> http://dpaste.com/102509/
<bewst1> I've gotta say, this first encounter with bzr is a bit of a nightmare.
<jelmer> bewst1, wait.. weren't you trying to push to boost-consulting/site/branches/seo ?
<bewst1> I know DVC is supposed to speed up development, but I could've gone a long way further with SVN by now.  Is it worth trying to figure this out, or should I come back when 1.5 is out?
<jelmer> bewst1, I would recommend trying again when bzr-svn 0.5 is out
<bewst1> Well, I was in a subdirectory of seo called utils, and was trying to push that
 * LarstiQ would say trying to back on svn is the main source of pain here
<jelmer> bewst1, that prevents all this mess with branching schemes
<jelmer> bewst1, you can't push subdirectories in bzr
<jelmer> bewst1, at least that explains why it was switching to a different branching scheme
<bewst1> Oh, I totally messed this up.  I'm an idiot.  Let me try again.
<jelmer> you probably want to push to boost-consulting/site/trunk I think?
<jelmer> bewst1, you're not an idiot, but bzr-svn 0.4 exposed some internals that really should be hidden from the user..
<bewst1> I was even pushing to the trunk.  Gah.  But now it says no new revisions to push
<bewst1> Do I need to revert the branching scheme?  I didn't save it :(
<jelmer> bewst1, if you push to trunk it should use the right branching scheme
<bewst1> jelmer: I didn't want to push to trunk!
<bewst1> I was being a fool
<jelmer> bewst1, are you sure the revision isn't in svn yet?
<bewst1> Will look.
<bewst1> it is!
<bewst1> OK, will try some more.  Any idea what the release date for 0.5 /might/ be?
<jelmer> bewst1, roughly a month from now I hope
<bewst1> That might be worth hanging on for
<jelmer> there is a release candidate out that people found a few bugs in, I plan to fix those and release another RC in a week or two
<bewst1> kewl; thanks
<jelmer> unless any significant bugs come up in that RC, I will release that as 0.5
<bewst1> Does bzr-svn interoperate properly with svn 1.5 branch/merge tracking?
<jelmer> bewst1, somewhat
<jelmer> bewst1, only for full merges (no cherrypicking)
<jelmer> bewst1, since none of the main DVCS'es do cherrypicking tracking
<jelmer> (yet)
<bewst1> Sorry, what constitutes a full merge?
<jelmer> bewst1, if you "svn merge" a branch, it will track that
<jelmer> bewst1, if you "svn merge -c" a specific revision only or a revision range, it won't
<bewst1> jelmer, OK, thanks.  So if you think you might want to do something like that, just create separate bzr branches for each such separate change?
<jelmer> bewst1, for example
#bzr 2008-12-26
<jfroy> urg
<jfroy> Bazaar just threw me an exception when pushing to launchpad
<jfroy> Much sadness ensued :|
<dabreegster> I just made a stupid error. In my ~/ I have lab with a fub directories kept under bzr control. I untarred an archive and it added/overwrote to those directories, including .bzr stuff (from within the tarball). I killed the untarring midway through, but how can I get rid of whatever I added? Are .bzr files so named to where I just lost all my changes?
<tmske> Hi, can someone help me to push with bzr-svn to google code? I try with bzr svn-push but get a 401: Authorization Required
<edcrypt> tmske are ou using https?
<edcrypt> *you
<tmske> edcrypt: yes brz svn-push https://... I think it may be related to this bug: https://bugs.launchpad.net/bzr-svn/+bug/120768
<ubottu> Ubuntu bug 120768 in bzr-svn "Should prompt for passwords" [Low,Fix released]
<tmske> but at the moment it looks like I have a different problem at the moment... svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for ...
<tmske> this happens even if I do a checkout with svn :-S
<edcrypt> tmske: gcode is a bit buggy sometimes :/
<kiorky> pnn/b 24
<tmske> edcrypt: well it worked at least, with some detour, but it doesn't look like anything is pushed
<tmske> edrypt: I have allready pushed to launchpad, can that be a problem?
<edcrypt> you are pushing something you branch'ed from the svn repo, right?
<edcrypt> nope, I do somethng similar with a project.
<edcrypt> I keep a branch on my pc that I use as a bridge between gcode and lp
<tmske> edcrypt: I have created a local bzr repo and I want to push that to google code, so I use bzr svn-push but nothing get pushed
<edcrypt> 'bzr svn-push https://...', right?
<tmske> edcrypt: yes
<tmske> that command said something like this: Initialising Subversion metadata cache in... but nothing more
<edcrypt> how are you checking if thing where pushed, svn? the web interface?
<edcrypt> *things
<edcrypt> some earlier bzr versions where short on feedback
<edcrypt> (IIRC)
<tmske> edcrypt: svn up doesn't import anything either
<edcrypt> tmske try dpush.
<tmske> edcrypt: dpush wants to push to launchpad, how do I point it to gcode? with the specified link?
<edcrypt> yep, 'bzr dpush https://code.google....' -- you can use --remember to make this url the default, if you want
<edcrypt> I prefer *no* default urls when I dont have a 'main' repo, like when using lp/gcode, tho
<edcrypt> tmske: but please take a look at 'bzr help dpush' and 'bzr help svn-push'
<tmske> edcrypt: thanks for the bzr help command, didn't know that one.  bzr dpush doesn't seem to work though.. *** Bazaar has encountered an internal error.
<edcrypt> tmske hm, please report it. out of curiosity, what is your 'bzr --version'?
<tmske> 1.10 with python 2.6 on opensuse 11.1, it's bzr from the repo found on the homepage of bazaar
<edcrypt> make sure you are using the latest bzr-svn.
<tmske> edcrypt: thanks for all the help, I'll try to install the latest version of bzr-svn tomorrow, I don't have time for it now
<edcrypt> np.
<epsy> hey, how do I know if a working tree's revision is tagged or not ?
#bzr 2008-12-27
<hstuart> hey - been looking through the docs for a while without much luck... is there a way to alias urlspecs so if I collaborate with, say, 2 other people I can go: bzr merge user1 or bzr merge user1 instead of bzr merge reallylongurl or bzr merge somethingelseIllfroget ? :)
<bob2> bzr-bookmarks plugin
<bob2> aiui
<hstuart> gracias
<epsy> oh, and for the tag thingy: tag=$(bzr tags | grep -P "^(.*?) +${rev}$" | awk '{ print $1 }')
<rocky> hrm ... i've been using a bzr repo and the other day i accidentally did a "bzr init" in that repo dir which turned it into a branch as well, any way to un-branch it? :)
<gotgenes> rocky: rm .bzr?
<gotgenes> er, rm -rf
<gotgenes> but be careful
<gotgenes> make sure you're in the right spot
<rocky> um, but isn't the repo stuff stored in .bzr ?
<gotgenes> it is
<gotgenes> did you cd into your .bzr repo
<gotgenes> and then issue "bzr init"?
<rocky> yes
<rocky> (some time later on)
<gotgenes> rocky: okay. then cd into your repo's .bzr repo
<rocky> but i've never committed anything to that repo/branch
<gotgenes> do an ls -a
<gotgenes> you should see another .bzr inside it
<gotgenes> rm -rf that one
<rocky> no wait, i think i'm confused...
<rocky> this is what i did...
<gotgenes> Actually, just to be certain, do this
<rocky> bzr init-repo sandbox
<rocky> cd sandbox
<rocky> bzr init
<gotgenes> ah
<rocky> that last "bzr init" was the culprit
<gotgenes> rocky: http://paste.lisp.org/display/72693 Looks like you can just remove the branch and checkout directories
<rocky> ah cool
<rocky> another question ... if i have 2 branches which are actually near identical but have no common ancestry, how do i merge revisions 2 and 3 from branch X into branch Y ?
<gotgenes> Ah, dinnertime. ArrivederLa!
<jelmer> rocky: that's pretty tricky at the moment I think
<jelmer> it has come up a couple of times in the past
<jelmer> you mayt want to ask about it on the mailing list
<rocky> jelmer: well, i've tried simply doing "bzr merge -r 2..3 ../source-branch" to get just the revisions i want, it removes a source dir in the target branch for some odd reason (and my 2..3 range does not include removing a dir)
<rocky> i'm getting tempted to simply do "bzr diff -r2..3 ../source-branch > patch.txt; patch -p0 < patch.txt"
<rocky> which works just fine
<jelmer> rocky: that is probably the easiest thing to do at the moment I think
<jelmer> there aren't many tools for bzr that handle parallel imports at the moment
<rocky> that's ugly =P
<Hydrogen> well
<Hydrogen> you could use std{in|out}
<Hydrogen> instead of the file
<rocky> the base of what i'm trying to do actually is i have a trunk branch from an hg repo and i've added it to my own bzr repo and i've then made small modifcations to add the functionality i want ...
 * jelmer mutters something about revision id aliases
<Hydrogen> and then write yourself a bash alias
<rocky> then i hg cloned another tag of the hg branch and wanted to apply the same changes there
<Hydrogen> and do bzr-coolname revision1 revision2 source-branch
<rindolf> Hi all! I'm unable to build the RPM of bzr-svn : https://bugs.launchpad.net/bzr-svn/+bug/311712 - a similar problem happens with bzr-svn-0.4.16
<ubottu> Ubuntu bug 311712 in bzr-svn "bzr-svn-0.5.0~rc1 - python setup.py bdist_rpm fails" [Undecided,New]
<jelmer> rindolf, still there?
<rindolf> jelmer: yes.
<jelmer> rindolf, I think the fact that bzr-svn includes subvertpy is what is causing the problems here
<rindolf> jelmer: ah.
<jelmer> rindolf, If you build them separately and perhaps strip subvertpy out of bzr-svn, it may work better
<rindolf> jelmer: :S
<rindolf> jelmer: from where can I download subvertpy?
<jelmer> rindolf, launchpad.net/subvertpy
<rindolf> jelmer: I don't see a download link.
<rindolf> https://launchpad.net/subvertpy/+download
<jelmer> rindolf, There's no packaged release, you would need to fetch the bzr branch
<rindolf> jelmer: OK.
<rindolf> jelmer: how?
<jelmer> rindolf: e.g. "bzr branch lp:subvertpy subvertpy"
<rindolf> subvertpy/client.c:26:18: error: util.h: No such file or directory
<rindolf> subvertpy/client.c:27:16: error: ra.h: No such file or directory
<rindolf> subvertpy/client.c:28:16: error: wc.h: No such file or directory
<rindolf> That's what I get when I try to bdist_rpm subvertpy
<rindolf> jelmer: ping.
<jelmer> rindolf: you need to install the subversion development libraries
<rindolf> jelmer: I installed them.
<jelmer> rindolf, what location are they in?
<rindolf> jelmer: /usr/include/subversion-1/
<jelmer> rindolf, it looks like the RPM stuff doesn't work here either
<jelmer> It wasn't ever tested, it's just there by default in distutils
<rindolf> jelmer: OK.
<rexbron> james_w, jelmer: I have submitted the merge request on launchpad, is there more I should do to get it looked at?
<jelmer> rexbron, james_w is the bzr-builddeb maintainer :-)
<abentley> lifeless: www.squid-cache.org is down.
#bzr 2008-12-28
<james_w> rexbron: I return home tomorrow, I'll try and get to it soon
<smoothice> Hello... I'm getting a bzr-svn exception when I run any bazaar command. The only way around it is by running it with --no-plugins. I know some bug reports were submitted to Launchpad but they were reported to be fixed in previous versions. I'm having these problems with version 1.10.
<jelmer> smoothice: what's the exact backtrace?
<smoothice> Would you like me to pastebin?
<jelmer> please do
<smoothice> jelmer: http://pastebin.com/ma0212ae
<jelmer> smoothice, are you on Windows?
<smoothice> jelmer: No... Mac OS X 10.5.5
<jelmer> smoothice, what version of bzr-svn are you running?
<smoothice> jelmer: 0.4.16
<jelmer> smoothice, What URL is the repository at exactly?
<smoothice> jelmer: The repo has since been deleted... What is weird is that I've never used bzr-svn. I've been using SVN recently but not bzr-svn.
<smoothice> jelmer: So this has become a surprise when this began happening today.
<jelmer> smoothice: It's occuring because you have bzr-svn installed
<jelmer> smoothice, So it's expected that that operation fails, you're just surprised by how it fails?
<smoothice> jelmer: I'm surprised that it just starting happening today since I've never used bzr-svn.
<smoothice> jelmer: started*
<smoothice> jelmer: Any ideas? It just seems strangely random that it just started today... I upgraded to bzr 1.10 last night...
<jelmer> smoothice: Has anything else changed?
<jelmer> smoothice, So it's expected that that operation fails, you're just surprised by how it fails?
<smoothice> jelmer: I'm surprised _anything_ fails... I've never even used bzr-svn...
<jelmer> smoothice: That doesn't matter - if you have bzr-svn installed, bzr will try to open a locatioin with bzr-svn if the other means to open it fail
<jelmer> that's why you're seeing this particular error
<jelmer> What happens if you use --no-plugins? Does it give a different error?
<smoothice> jelmer: I never installed bzr-svn... is it installed by default?
<jelmer> smoothice, probably
<smoothice> jelmer: ok. should I uninstall it? and if so how would I go about doing that?
<jelmer> smootice: What happens if you use --no-plugins? Does it give a different error?
<smoothice> When I run bzr whoami with --no-plugins it runs successfully.
<jelmer> smoothice: But when you run the exact same command that previously failed with --no-plugins ?
<smoothice> jelmer: it works
<jelmer> smoothice, what command is that exactly?
<smoothice> jelmer: everything.. but I've been using whoami as a test
<jelmer> smoothice, does a .svn directory exist in the current directory
<smoothice> jelmer: Yes
<jelmer> smoothice, that explains why bzr-svn enters the game
<smoothice> jelmer: oh....
<smoothice> jelmer: that explains why it sometimes works and sometimes doesn't depending on the directory I'm in... So the solution is to rm that .svn directory?
<jelmer> smoothice: probably, yeah
<smoothice> jelmer: The thing is that I'm never going to need to use bzr-svn.. because I either use one or the other. Is there a way I can deactivate or uninstall bzr-svn?
<jelmer> smoothice, but will you ever need to use svn and bzr in the same directory?
<smoothice> jelmer: Not really... Any given project will either be svn or bzr... not both
<jelmer> smoothice, in that case I would just recommend removing whatever of the two you didn't need in this case
<jelmer> you can always disable bzr-svn using the --no-plugins argument
<smoothice> ok
<smoothice> jelmer: any way to pass noplugins automaitcally? or make it default?
<jelmer> smoothice: well, the problem here really is that either)
<jelmer> * there is a bug in bzr-svn when opening certain URLs
<jelmer> * you have a .svn directory laying around that points to an invalid Subversion repository URL
<smoothice> ok
<jelmer> smoothice: Do you have enough information to tell that either is the case?
<smoothice> jelmer: I think the combination of it all gave me bad luck... 1. old .svn dir 2. old url 3. bug
<paroneayea> hello
<paroneayea> so, I'm looking into bazaar
<paroneayea> it's interesting.. I'm currently a git user
<paroneayea> the one thing that seems to bother me is what seems to be a hardcoded link to launchpad
<paroneayea> which, it's great that launchpad helps support hosting free software projects like this
<paroneayea> but my wariness of gatekeepers kind of blips
<paroneayea> wondering if I'm missing something
<Peng_> What do you mean?
<Peng_> You don't *have* to use Launchpad.
<paroneayea> right
<paroneayea> just wondering.. there's builtin conveniences that encourage launchpad use.  Wondering if there's a way to decentralize them
<paroneayea> er
<paroneayea> :\
<paroneayea> hm.
<Peng_> What?
<paroneayea> never mind :)
<abentley> paroneayea: The hardcoded links to launchpad are provided via a plugin.  They are not a core part of the program.
<paroneayea> abentley: aha.  thanks.
<Peng_> Even if you don't like Launchpad, there's no real reason to remove the plugin though.
<bewst> Trying to get used to this bzr thing...
<bewst> so I do a bunch of commits to my local repo... that already makes me nervous because I don't have everything I've done backed up on the server...
<bewst> and then I bzr push the changes out (to my svn repo).  At that point I'd like to add an SVN checkin comment that closes the Trac ticket I've been working on.  Is there a way?
<maco> bzr says i have uncommitted changes. i'm pretty sure i havent changed it since my last "bzr pull" ...is a pull considered an uncommitted change?
<AfC> maco: no, it isn't
<maco> is there a way to see what the uncommmitted changes are?
<cammoblammo> maco: bzr status or bzr diff (if you want to see the details)
<maco> er...i dont understand how to read bzr status's output
<cammoblammo> It'll give you a list of files that have been modified, added, removed, and so on. If there are some surprises in there you can use bzr diff to see the details. That can be a little trickier to understand.
<cammoblammo> What exactly don't you understand?
<AfC> maco: `bzr status` and `bzr diff` are fairly fundamental, so it's a bit of a puzzle that you would be seeing something there that you don't understand [unless we are wildly misinterpreting your situation]
<maco> well all ive ever used of bzr are pull and commit...so...
<maco> but its listing like 200 files
<maco> and i'm 99% sure i havent changed even 1 file, let alone 200
<AfC> A not yet committed merge possibly (though that should be evident), or you did a `bzr uncommit` somewhere along the way and haven't done a matching `bzr revert` to get rid of the changes.
<AfC> (though why you are committing if you are only pulling is quite beyond me)
<maco> oh ok yes i did do a merge because pull gave errors
<cammoblammo> Are you syncing between different operating systems or file systems? I had a similar thing once---turned out it was line endings being changed.
<maco> so i have to commit after merge?
<maco> im sorry, im very newbie at vcs :(
<cammoblammo> Yes, because if you're mergng your changing the files that are coming to you. You're making hybrid files, so to speak. They're different to the ones originally on your machine, and they're different to the ones on the other machine.
<maco> oh
<maco> wait, will they have the <<<<<<<<<<<<<<<< and >>>>>>>>>>>>> lines in them then?
<bob2> if you made changes in the same places as the other people did
<bob2> then you need to resolve the conflict (ie pick a side or combine both sides)
<maco> and if i didnt make changes then i can just tell it to commit?
<cammoblammo> Presumably. My usage style leads to very little merging, so I'm always a little paranoid. You can check what changes were made with bzr diff, but for 200 files that could be a little tedious!
<maco> eh none of them were the one file i was working on
<maco> so ok thanks
<maco> so if i do pull more often, can i avoid merging?
<cammoblammo> If you pull before you start working on a file you'll minimise the chance you'll need to merge. Of course, if somebody else commits just before you do you might have to do a merge.
<cammoblammo> Committing frequently will also help. Make someone else merge instead!
<maco> why did i have to merge to begin with if i didnt edit all those files?
<maco> i branched a while ago, edited 1 file, and then didnt touch anything for a month
<maco> er, i committed after that 1 file
<fullermd> Erm.  It's not a matter of 'how often'.  You can only pull as long as you don't diverge.
<cammoblammo> Are you on Windows while others are using UNIX like OSes?
<fullermd> Uncommitted changes aren't technically divergance, but leaving them around while you pull is kinda skating on the edge.
<maco> cammoblammo: no, i'm on ubuntu and it's a gnome project, so i'd guess they're all on linux too
<cammoblammo> Have you tried bzr diff? Even if the output's a little difficult to parse, you might get a clue as to what's going on.
<maco> oo...um well i committed the merge now, but why does bzr log show rev 9726 and 9728 with no 9727?
 * fullermd is fairly certain it doesn't.
<maco> oh. heh, youre right. ok im just confused by the order it puts things. i'll go away now since bzr's not yelling at me anymore
<Kosjer> good morning
<Kosjer> got an odd and probably simple problem maybe someone could give an advice :)
<Kosjer> i am using bazaar 1.10 on osx. i am playing around a little at the moment to get used to. created a directory with 2 sml textfiles in a working directory and entered the directory into bazaar. changed files a little in text editor and always commited afterwards. then i tried out revert and uncommit. and there the odd thing starts. i added to one of the files the word "test" and commited. basically test should vanish after revert and u
<bob2> Kosjer: you got cut off after "after revert and "
<Kosjer> basically test should vanish after revert and uncommit. but strange part is if i use bzr uncommit the last log commit entry gots deleted. but the content of the text file remains with test. if i use bzr rever the test word vanishes. but aside file called TM98 Kopie.sml.~1~ appears in the work directory aside the original TM98 Kopie.sml. Is the behaviour of uncommit and revert regular?
<Kosjer> thanks ;))
<bob2> bzr uncommit will revert to the the "add" of the files
<Kosjer> the file got just altered. ii had state 1 then added a word to it and commited to state 2. so i thought with uncommit. i get state1 back
<fullermd> uncommit doesn't affect the working tree; it just pops the branch back to the state prior to commit.
<fullermd> revert [with no args] pops the working tree back to the state of the head of the branch.
<Kosjer> ahh so uncommit only affects the log. revert the files itself
<Kosjer> thanks fuller!
<fullermd> Similarly, you could say 'bzr revert -r-50', and that would change all the files back to the way they were 50 revs ago.
<fullermd> But the branch itself wouldn't be changed; those 50 revs you reverted past are still there; only the files in your working tree are moved around.
<Kosjer> ahhh oki
<fullermd> Think of it in terms of which commands affect the branch, and which affect the working tree, and it's reasonably easy to keep straight.
<fullermd> (and which affect the repository, but those are mostly implicit in affecting the branch)
<Kosjer> oki
<Kosjer> cool
<Kosjer> will play around a little more today. thanks a lot!
<eferraiuolo> I was looking for some help when using BZR with SVN
<eferraiuolo> For every operation I'm asked for my password on the SVN server
<eferraiuolo> I am connecting to it via HTTPS so I figure it's using Web-Dav
<eferraiuolo> How can I make things where I don't have to authenticate every single operation?
<eferraiuolo> If anyone has a way to help me with this, that would be great if you emailed me at: eferraiuolo@gmail.com
<a_c_m> whoops, i just did a bzr revert when i really didnt want to... is there anyway to get back the now gone changes?
<beuno> a_c_m, I believe that bzr saves the previous files as  filename~
<beuno> do an ls -a
<a_c_m> beuno: not this time... crap, luckly i think i have it cached in my browser :) i love firebug!! (it was a css file) so i'm just loosing comments
<beuno> a_c_m, how odd, it's suppose to do that everytime AFAIK
#bzr 2009-12-21
 * igc out for a few hours - bbl
<zekopeko__> hi
<zekopeko__> i was in here the other day with a truly messy bzr repo
<zekopeko__> so i was wondering how could one clean said repo of cruft?
<bob2> where cruft = unwanted branches?
<zekopeko__> if by branches you mean revisions then yes
<bob2> I don't
<zekopeko__> there is like a complete git repo and binary files
<zekopeko__> it's scary
<zekopeko__> and it's some 300mb with anon bzr branch
<zekopeko__> but the program is less when 1mb with icons
<zekopeko__> *then
<zekopeko__> could i take a good revision that is high and simply drop anything below that?
<zekopeko__> btw the repo is here: https://code.launchpad.net/gloobus
<poolie> zekopeko__: if it's really messy i'd just drop the history and re-import a snapshot of it
<poolie> then rename the old one to trunk-ol/d
<poolie> trunk-old*
<zekopeko__> i was thinking along those lines
<zekopeko__> is there some guide or something that could help me? i never used bzr but hate seeing this cruft
<poolie> i can look at the branch if you like but basically
<poolie> well,
<poolie> actually, i should check first - is this your project?
<zekopeko__> no
<zekopeko__> but i have somebody that has commit access
<poolie> ok
<poolie> have you talked to somebody on the project about cleaning it upL
<poolie> i don't mind helping you
<poolie> but it will be smoother if it's coordinated with others
<poolie> anyhow, what i eventually suggest you do is
<poolie> get a checkout of the branch
<DanRabbit> poolie: I'm on the Gloobus Project :)
<poolie> that was 1
<poolie> 2- 'rm -r .bzr' to remove the old history
<poolie> 3- remove the junk
<poolie> 4- 'bzr init; bzr add; bzr ci -m snapshot' to start a new history
<poolie> 5- rename the old trunk on launchpad
<poolie> 6- push this new branch and make it the trunk
<zekopeko__> you got that DanRabbit? :P
<DanRabbit> yep
<DanRabbit> .bzr directory here is 88 MB
<DanRabbit> lol
<poolie> does that make sense?
<DanRabbit> that it's 88 MB? not to me
<DanRabbit> what to do?
<DanRabbit> yep
<zekopeko__> sweet, thanks poolie!
<DanRabbit> yes, thankyou poolie
<poolie> happy to help
<poolie> hello spiv?
<spiv> poolie: hi
<poolie> just saying hi really
<poolie> going to close mail and start piloting in earnest soon
<spiv> poolie: hooray for piloting :)
<spiv> poolie: I'm busily replying to the deluge of review comments on the per-file merge patch
<spiv> poolie: it's great to get so much thoughtful feedback on a patch from so many people, but also a bit overwhelming.
<spiv> poolie: btw, I've been enjoying new progress reporting
<spiv> poolie: it was a bit disconcerting at first because my eyes had been trained to expect to see the info about 30 columns further right than it is now
<spiv> poolie: but now I've got used to that I've found I don't miss the bar at all
<lifeless> poolie: what time would you like beer?
<mwhudson> jelmer: man, wtf?
<mwhudson> (about codeplex)
<lifeless> mwhudson: ECONTEXT
<mwhudson> lifeless: https://bugs.launchpad.net/bugs/498925
<ubottu> Ubuntu bug 498925 in bzr-svn "assert svn_revprops.has_key(properties.PROP_REVISION_DATE) can fail" [Low,Triaged]
<mwhudson> Codeplex has a custom subversion implementation (on top of Visual
<mwhudson> SourceSafe or something?) that is kinda dodgy and inconsistent.
<mwhudson> my sense of order in the world didn't need to know about that
<lifeless> ah
<lifeless> just like google then ?
<Kilroo> Just for the record, I want to make it clear that I find it highly amusing that git and bzr can both take an existing subversion repository and push it to a new blank svn branch without needing shell access at either end, and svn itself apparently can't.
<Peng> lifeless: Google's svn implementation is dodgy?
<lifeless> Peng: "non standard"
<Peng> OK. :)
<poolie> lifeless: say six?
<poolie> spiv, that's good
<lifeless> poolie: ok
<mwhudson> lifeless, Peng: and a bit dodgy
<Peng> :D
<Peng> Aside from the odd responses to .bzr requests, and downtime, how is it dodgy?
<mwhudson> Peng: large cscvs imports never succeed
<mwhudson> bzr-svn seems to tickle the pain points much less
<Peng> Oh. Maybe they subcontracted it to SourceForge. ;-)
<mwhudson> heh
<poolie> spiv, would it be appropriate to raise NoSmartMedium if we can't connect to the smart server over http?
<poolie> ie we could potentially connect but we can't actually connect at this url
<spiv> poolie: Off the top of my head I think so, yes.
<spiv> I
<poolie> yes, it seems like it
<clausen> when I do:
<clausen> bzr info bzr+ssh://ClausenStrub@c-st.net/~/econ_bib.bzr
<clausen> I getbzr: ERROR: Not a branch: "bzr+ssh://ClausenStrub@c-st.net/~/econ_bib.bzr/".
<clausen> what does it mean?
<clausen> $ ssh ClausenStrub@c-st.net ls -a "~/econ_bib.bzr"
<clausen> .
<clausen> ..
<clausen> .bzr
<spiv> clausen: it means you probably don't have bzr 2.1.0b3 or newer on the server
<spiv> clausen: which is needed for /~/ to work in bzr+ssh URLs
<clausen> oh
<clausen> the client can't ask the server the version?
<spiv> clausen: try bzr+ssh://ClausenStrub@c-st.net/home/ClausenStrub/econ_bib.bzr/ (or whatever your home dir is)
<spiv> It can, but that's not really the issue.  The meaning of '~' is very much dependent on the server.
<spiv> It's not something that clients can calculate without help from the server.
<clausen> anyway, it's a completely unhelpful message
<clausen> it should say "file not found" or something
<clausen> but thanks for your help
<clausen> I really appreciat eit
<spiv> Yeah, that's true.
<clausen> we spent hours on it
<spiv> "Not a branch" really should have more explanation about why in it.
<clausen> yeah
<spiv> I'm fairly sure there's a bug about that somewhere.
<spiv> Sorry to hear it cost you so much time!
<clausen> is there an easy way to intercept the traffic?
<clausen> it would have been helpful to see the data on the wire
<clausen> with git, I can wrap ssh
<clausen> which I've found very helpful in the past
<spiv> "bzr -Dhpss" is often helpful
<spiv> As in, add -Dhpss to what ever bzr command you're running.
<spiv> It logs a bunch of stuff about the smart server conversation to ~/.bzr.log
<spiv> I've also used strace occasionally to trap read/write calls, which is how bzr will be communicating with the ssh subprocess
<spiv> And you can change the SSH implementation bzr tries with the BZR_SSH environment variable (and there's a config setting too).
<clausen> ah, same as git then :)
<clausen> (although it's not documented?)
<spiv> Which SSH wrapper do you use for git?
<clausen> I wrote a shell script that does "echo $*; ssh $*"
<clausen> but you could also use vee
<spiv> It should be documented somewhere, 'bzr help configuration' for instance mentions BZR_SSH
<clausen> bzr(1) doesn'
<clausen> bzr help isn't searchable?
<spiv> Hmm, that's odd, I wonder how the man page is generated.
<spiv> There's 'bzr help topics', but all of that content is in the HTML docs too.
<clausen> python in general has poor documentation tools
<clausen> (although I could just be ignorant)
<spiv> e.g. http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html#configuration-settings
<clausen> R has a similar philosophy, but seems to work better
<clausen> (eg: help.search())
<clausen> how did you navigate to that page?
<clausen> ah, you clicked on User Reference
<clausen> I guess I was expecting that to be many pages, and hence not searchable
<clausen> good to know :)
<spiv> clausen: there's a pretty functional search box at http://doc.bazaar.canonical.com/bzr.2.0/en/ too
<clausen> but it searches the whole site!
<clausen> you get the same result for many versions of the same document
<clausen> actually, I'm wrong about that
<clausen> it's doing something else
<clausen> anyway, searching "ssh" didn't find it
<clausen> (item number 33, actually)
<clausen> I guess the thing that's nice about man pages is you can search for "ENVIRONMENT"
<clausen> and you have a complete list
<spiv> Yeah, I don't know why the man page has an incomplete list.
<spiv> 'bzr help environment' ought to be up to date.
<clausen> ok, I'll submit a bug on that then :)
<spiv> (And ought to be what the man page uses for that section)
<spiv> clausen: thanks :)
<clausen> $ bzr help environment
<clausen> bzr: ERROR: No help could be found for 'environment'. Please use 'bzr help topics' to obtain a list of topics.
<clausen> you mentioned "configuration" before?
<spiv> Oh, 'env-variables' is the topic name.
<clausen> it includes BZR_SSH
<spiv> Yeah, that's a help topic too, but 'bzr help env-variables' is specifically just the environment variables.  'configuration' is a broader topic than just the environment variables, unsurprisingly :)
<clausen> is there a URL where i can browse the bzr source?
<clausen> (it's ironic that I can't find it!)
<spiv> There's a link on code.launchpad.net/bzr
<clausen> thanks
<clausen> it's hard-coded!
<clausen> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head%3A/bzrlib/doc_generate/autodoc_man.py
<clausen> no wonder it's unsynchronized
<clausen> the "bzr help env-variables" command is also hard-coded
<clausen> in _env_variables, which is defined in bzrlib/help_topics/__init__.py
<clausen> I must confess, I'm kind of freaking out about this
<clausen> bzr doesn't seem to have the rigour and elegance of a solid system
<clausen> (but, I suppose it will get better)
<spiv> Well, env-variables is as close to the canonical version as we have.
<poolie> that's a bit of a bug in that page
<poolie> it should just use the help topic
<spiv> Right.
<poolie> i'll file it
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/498952
<ubottu> Ubuntu bug 498952 in bzr "autodoc_man.py should use env-variables, not duplicate it" [Medium,Confirmed]
<clausen> $ bzr info blah
<clausen> bzr: ERROR: Not a branch: "/home/clausen/free-software/bzr/blah/".
<clausen> ^ should say "path not found"
<spiv> Yes.
<spiv> "Not a branch" is techinically correct, but not as helpful as it could be.
<clausen> agreed
<lifeless> note that a missing parent dir doesn't imply not a branch, it could be a missing plugin (e.g. bzr-svn)
<clausen> lifeless, of course, but the error message should explain
<clausen> lifeless, i.e. there should be different error messages for different reasons
<lifeless> clausen: also we search upwards
<clausen> I suppose the kosher way to do this would be to subclass errors.NotBranchError
<lifeless> I agree it could be improved, but I don't think its as shallow as perhaps you think it is
<clausen> and have things such as errors.NotBranchError.NoPlugin
<clausen> errors.NotBranchError.NoPath
<clausen> etc.
<spiv> clausen: hmm, I think actually just providing an extra string when instantiating NotBranchError
<lifeless> a typical branch lookup will catch 5 or 6 NotBranchError
<clausen> spiv, could be
<lifeless> which one is shown to the user will influence the ui
<spiv> clausen: (or the exception that lead to it, and have some common code to turn that into a string)
<lifeless> it doesn't currently.
<clausen> spiv, I suppose the question is: would anyone ever need to catch a special type of exceeption?
<clausen> spiv, I guess not
<spiv> clausen: right
<lifeless> NoPlugin woul be a prove-a-negative case.
<clausen> lifeless, yeah, I noticed that a lot of these exceptions are getting caught
<spiv> It's more providing an extra hint to the user, not a definitive diagnosis: e.g. 'Not a branch: "/foo/barr/baz/qux".  ("/foo/barr" does not exist)' would most of the time tell you what you wanted to know
<spiv> (although actually that particular case would be unlikely to have that much information without doing extra probing)
<clausen> (it would certainly have helped me!)
<clausen> (eg: I didn't know if I needed to point at .bzr)
<clausen> anyway, you've been very helpful
<clausen> thanks a lot!
<clausen> sleep time!
<clausen> bye!
<clausen> oh, nobody filed the bug yet... I guess I should before I go to sleep
<clausen> ah, it's #52865
<clausen> https://bugs.launchpad.net/bzr/+bug/52865
<ubottu> Ubuntu bug 52865 in bzr ""Not a branch" errors could be better when branch is missing." [Wishlist,Confirmed]
<poolie> spiv, is https://bugs.edge.launchpad.net/bzr/+bug/410332 like something you fixed recently? maybe a dupe?
<ubottu> Ubuntu bug 410332 in bzr "accessing a bzr:// branch with a revisionspec causes bzr to crash" [Medium,Confirmed]
<spiv> poolie: hmm, maybe
<spiv> poolie: I'll try to reproduce quickly
<spiv> poolie: ah, yep, still current, but a bit obscure
<spiv> poolie: oh, oops, sorry, it is fixed :)
<poolie> fail! no, win!
<poolie> :)
<gour> jelmer: morning, i opened a ticket for my yesterday's 'bzr dpush to github' problem - https://bugs.launchpad.net/bzr-git/+bug/498962
<ubottu> Ubuntu bug 498962 in bzr-git "KeyError(sha)" [Undecided,New]
<Adys> Is it possible to remember two different pushes?
<Adys> Eg every time I push, it pushes to both my own branch somewhere, and to a lp: branch
<spiv> Adys: you can probably use the automirror plugin to do something like that.
<spiv> I don't think there's anything builtin though.
<Adys> mm kay
<Adys> I'll be lazy then :)
<lifeless> Adys: spiv: bookmarks plugin
<lifeless> might be close-enough
<Adys> Meh, as i said I'll be lazy, was hoping for a quick&dirty command, its a temporary lp branch
<bialix> hello all
<rubbs> hello bialix.
<bialix> hi rubbs
<rubbs> how are you today?
<bialix> there is cold today
<bialix> hope you're better
<rubbs> It's cold here too. getting snowy as well.
<rubbs> but I"m pretty good other than that
<bialix> that's fine :-)
<nilg> hi, I'd like to revert undo a revision at some point in the past (10 revisions away from the current one), apparently the command would be:
<nilg> bzr . merge -10
<nilg> is that correct?
<nilg> (I'm scared to make a mistake...)
<nilg> or is it the number of the revision, like
<nilg> bzr . merge -3826
<nilg> ?
<rubbs> An possibly easier way to think about it (more steps but easier to understand) is this:
<rubbs> bzr branch project -r 3826 ./projectUndo
<rubbs> then
<rubbs> bzr merge projectUndo
<rubbs> I think that's correct... you may want to back things up just in case
<james_w> that will say "nothing to do"
<james_w> you want "bzr merge . -10..-11"
<james_w> merge the changes between the revision and the one before it
<james_w> i.e. undo those changes
<james_w> "bzr merge . -r -10..-11" of course
<rubbs> ah, thanks james_w. I haven't had to do it myself. Thanks for the correction
<nilg> james_w, the right command for me was "bzr merge . -r -11..-12", thanks!
<Solipsist> i just installed bzr and qt on mac but i cant find out where bazaar explorer and qbzr are installed
<bialix> Solipsist: run `bzr plugins`
<Solipsist> now that was totally obvious :)
<Solipsist> bzr: ERROR: [Errno 2] No such file or directory: '/Users/username/.bazaar/explorer'
<bialix> Solipsist: what is explorer version?
<bialix> I think this bug was fixed
<Solipsist> version is 0.9.0
<Solipsist> got it running
<Solipsist> a note from a new user: bzr is supposedly easier to use than git, my experience so far has been the opposite
<Solipsist> so im cloning a remote repos as id like to work distributed, pushing changes from my local repos back to the remote is "bzr push", right? local commits "bzr commit"?
<jelmer_> Solipsist: yep
<rubbs> Solipsist: as a member of doc team, I'm interested in the problems you had with bzr. Maybe I can get our team to address holes in the documentation
<Solipsist> rubbs: the first roadblock i encountered was to figure out how to run bzr explorer, as it was mentioned nowhere, even after extensive googling
<Solipsist> i tried using spotlight in osx to locate it or qbzr, no luck
<rubbs> Solipsist: I'll be sure to raise that issue up. We have had a few requests on better plugin documentation.
<Solipsist> a very concise guide for those of use new to bzr would be appreciated, i dont need a GUI but after having used git with gitx, ive come to find them extremely useful when looking through commits
<Solipsist> its not the plugin itself but "now that's bzr is installed, what do i do? where did all these applications go?"
<bialix> Solipsist: you've mixed package problems with ease of use the tool itself
<Solipsist> the mac os x package needs better documentation
<bialix> where explorer is the question to the maintainers of Mac installer
<rubbs> Solipsist: I'll have the mac people look into making it easier to get started from install.
<bialix> windows installer already provides the user with start menu item, desktop icon and quick launch item
<Solipsist> if this page explained what the package contained and how to launch and use each plugin it would have made things easier: http://wiki.bazaar.canonical.com/MacOSXDownloads
<Solipsist> rubbs: awesome!
<rubbs> The leader of the Doc team is also the main dev for Explorer, so I'll see what I can do to help him understand the problem. He's a good guy and easy to work with.
<rubbs> My suggestion is to actually raise a bug on launchpad and tag it with "doc." you can give a very brief description of the problem you had and we'll work hard to change that experience
<glen> hmm, why is bzr giving me such weird error: $ bzr mv 01_notes.php  01_notes.sql
<glen> bzr: ERROR: Could not move 01_notes.php => 01_notes.sql: UPGRADE/patches is not versioned.
<glen> bzr log 01_notes.php shows it's revision log, meaning it is versioned
<rubbs> glen: not sure what's going on there, but you can as a work around do a system mv first and then use the same command you were getting the error on.
<rubbs> so do : $ mv 01_notes.php 01_notes.sql
<rubbs> then do : $ bzr mv 01_notes.php  01_notes.sql
<rubbs> that will cause bzr to see that 01.notes.php doesn't exist, and there is a new file called 01_notes.sql. It assumes you moved it and updates the versioning accordingly
<glen> now even worse:
<glen> $ bzr mv 01_notes.php 01_notes.sql
<glen> bzr: ERROR: Could not rename 01_notes.php => 01_notes.sql: Path(s) do not exist: upgrade/patches/01_notes.php UPGRADE/patches/01_notes.sql
<glen> what the heck it capializes the path component named "upgrade" ?
<glen> $ bzr st
<glen> removed:
<glen>   upgrade/patches/01_notes.php
<glen> unknown:
<glen>   upgrade/patches/01_notes.sql
<glen> says it
<glen> after the last action
<glen> bzr-0:1.18-2.x86_64 is the version
<rubbs> any possibility of updating to 2.0?
<glen> i cloned: bzr clone lp:eventum, and the mv i want to do in upgrade/patches
<glen> ok, trying to upgrade
<rubbs> Hmm.. not sure what's going on here. I'm just a user, but the devs check this channel frequently, so just sit tight. someone should be able to help you better
<rubbs> ok, cool
<rubbs> I can help more with the 2.0 series. (only a little more mind you).
<glen> any clues is 2.0 having some different dependencies of external packages?
<rubbs> not sure.
<rubbs> what type of system are you on?
<glen> linux
<rubbs> ubuntu?
<glen> pld linux
<glen> 32bit/64bit behave the same, if that's any matter
<glen> i just suspect "upgrade" has some special meaning somewhere
<glen> i.e the mv command works ok elsewhere
<rubbs> could be
<glen>  $ bzr mv xmlrpc_client.php xmlrpc_client.sql
<glen> misc/xmlrpc_client.php => misc/xmlrpc_client.sql
<rubbs> I'm wondering if someone did something in Windows, and the case insensitivity is causing problems
<glen> can you test with your bzr?
<rubbs> sure just a sec.
<glen> anyway, 2.0.3 behaves the same way :(
<glen> maybe this is (also) the reason:
<glen> $ l upgrade UPGRADE -d
<glen> drwxr-xr-x 24 glen glen 4.0K 2009-12-21 17:49 upgrade/
<glen> -rw-r--r--  1 glen glen 8.1K 2009-12-03 11:49 UPGRADE
<glen> i.e the repository has lowercase and uppercase objects present
<rubbs> weird...
<rubbs> clone is taking a while. so I haven't tried it yet. but it's getting there
<glen> anyway, getting rid of the uppercased file "UPGRADE" in root "solved" the problem here
<rubbs> ok cool. I'm still going to test it to see what's going on
<glen> it's solved for me, likely bugreport should be filed, but i'm lazy this time so won't go trought the hassle of registering accounts for bugreporting etc
<rubbs> I'll go ahead and file one for you. I can reproduce the result
<glen> nice
<glen> if need some reference, then my commit is: http://bazaar.launchpad.net/~eventum-developers/eventum/trunk/revision/4012
<rubbs> thanks. I might put that in there.
<rubbs> glen: finally got around to submitting that bug and found that someone already has put one up: https://bugs.launchpad.net/bzr/+bug/368931
<ubottu> Ubuntu bug 368931 in bzr "Rename may fail when file and directory have the same name differing by case" [High,Confirmed]
<glen> i see
<onox> can I put multiple bug numbers in --fixes?
<james_w> you can pass --fixes as many times as you like
<onox> thx
<james_w> commit --fixes foo:1234 --fixes foo:2345 --fixes bar:4567
<chmac> Can I reassign existing revisions to a new person? I've changed my whoami to match launchpad...
<chmac> I was using chm@buna as my email, which is not valid, so I can't validate that address on launchpad to link those revisions to me
<jelmer_> chmac: Not without redoing the commits
<chmac> jelmer_: Ok, thanks
<Tak> yeah, I had the same issue as chmac
<chmac> Tak: Did you find a reasonable solution? It's only 10 or so commits that are not attributed to me on launchpad, so it really isn't a big issue for my case.
<Tak> no, I never did
<phinze> jam: ping from iowa city
<jam> hey phinze
<jam> keeping warm ?
<phinze> our radiators ensure that we're always either sweating or freezing, yes :)
<phinze> i was wondering if you had a moment to walk me through a particularly tricky (but relatively small) bzr dance
<rubbs> Iowa City? I'm originally from Decorah.
<phinze> rubbs: i'm a transplant, but i bet there are several in my office who would enjoy that... will pass along
<phinze> jam: msging you
<chmac> Is there a faster way to download a branch than just straight `bzr branch lp:wordpress/trunk`? It's taking an age to download all the history.
<chmac> I considered a lightweight checkout, but I'm going to commit back to a different branch, so I don't think that would work.
<chmac> I guess it's the price I have to pay the first time to get all the history... :-)
<rubbs> chmac: if you haven't downloaded it before, then not really... You could try bzr+ssh:// but it requires you to have an account and to have set up keys
<beuno> chmac, if you have your launchpad-login specified you will use the
<beuno> "smart server"
<beuno> which should be faster
<chmac> I've run launchpad-login already, so it might be using the smart server already...
<jam> chmac: you may also be running into auto-conversion issues.
<chmac> I'm online in Mexico City, it's not the fastest connection ever... :-)
<jam> It looks like wordpress is in --pack-0.92
<jam> if you have 2a locally, it will convert on the fly
<jam> which could be slow
<chmac> jam: I think my bottleneck is the download speed, I'm seeing 20-40kbs...
<jam> it is a ~50-60MB download
<jam> Judging by http://bazaar.launchpad.net/~vcs-imports/wordpress/trunk/.bzr/repository/packs/
<jam> I would expect it to be smaller in --2a, if/when it gets converted
<beuno> jam, I though we where going to convert all imports to 2a?
<beuno> mwhudson, did that ever happen?  &
<beuno> ^
<mwhudson> beuno: no, not yet
<beuno> mwhudson, is it still on the roadmap?
<mwhudson> beuno: yes, but in a pretty sparsely populated area of the map i guess
<beuno> heh, ok
<mwhudson> beuno: i just added it to https://dev.launchpad.net/CodeTeam#Code%20imports fwiw
<beuno> mwhudson, thanks
<amro> I'm having trouble breaking a lock, I tried the provided command and a few variations with no luck (http://amro.pastey.net/130496)
<beuno> amro, try: bzr break-lock bzr+ssh://sigrie/home/sigrie/projects/xflight/
<amro> beuno: that worked, thanks. I thought I tried that
<amro> what's up with the line provided by bzr? usually it's correct
<beuno> amro, there are some cases where it doesn't work well, I fail to remember in which ones  :)
<beuno> what version of zbr are you using?
<beuno> and both server and client
<amro> 2.0.0, repo is 2.0a I think
<amro> something like that
<beuno> on both sides?
<Adys> Repo is 2.0a yeha
<jam> chmac_away, beuno, mwhudson: wordpress does shrink to 20MB after 2a packing...
<Adys> that said, how do i upgrade from branch format 6 to branch format 7?
<jam> Adys: 'bzr upgrade'
<jam> or 'bzr upgrade branch'
<jam> as fmt 7 is the latest format
<Adys> cheers
<halstead|wccls> I have a repository which after 400 revisions had a huge amount of unneeded binary data committed into by accident. Another 20 or so commits have happened over that last few months before anyone noticed. What's the best way to excise the binary files without losing our rich revision history?
<beuno> halstead|wccls, you would have to rewrite history
<beuno> there's a plugin calles bzr-rewrite (IIRC)
<beuno> *called
<beuno> not sure how to use it
<beuno> and, you need to know that you will break compatibility with all existing branches
<halstead|wccls> I'll search on those terms. Thats for the lead. I thought maybe I could start a new branch and pull the first 400 revisions and then layer ont he later changes somehow without pull everything in.
<halstead|wccls> Thank you for the lead.
<beuno> halstead|wccls, you can also branch from the last good revision
<halstead|wccls> Braking compatibility with existing branches is not a problem for us. All our contributers can make a fresh branch.
<beuno> and merge in the good revisions
<beuno> will make history look wonky
<halstead|wccls> beuno, I will try that.
<phinze> beuno: (lurking for learning) would there be a way to "replay" the revisions rather than merging them all with one revision?
<phinze> a la 'bzr pull' would tack them onto the end?
<beuno> phinze, well, I'm sure there is a way, but I don't know how I would do it
<beuno> jam, is the expert on rewriting history  :)
<phinze> indeed, he saved the day for me once again today
<phinze> i believe bzr-rebase would be the tool that could do it, but how to use it, i know not
<phinze> so bzr branch -r$REVISION_BEFORE_BINARIES trunk trunk_sans_bin
<phinze> cd trunk_sans_bin; bzr merge ../trunk -r$REVISION_AFTER_BINARIES..
<phinze> bzr rebase --pending-merges
<phinze> i _think_ that might do it
<phinze> --pending-merges "Rebase pending merges onto local branch."
<beuno> that sounds about right, yes
<halstead|wccls> Thank you.
<phinze> halstead|wccls: np -- a bit of the blind leading the blind :) but i hope it works for you
<beuno> halstead|wccls, http://doc.bazaar.canonical.com/plugins/en/rebase-plugin.html
<poolie> hello jam
* poolie changed the topic of #bzr to:  Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Patch pilot: mbp | bzr 2.1.0b4 and 2.0.3 released
<jam> hey poolie
<jam> beuno, phinze: replay is probably what you want, but jelmer is the expert
<poolie> shall we talk?
<halstead|wccls> phinze, What effect is the double dot at the end having? bzr merge ../trunk -r$REVISION_AFTER_BINARIES..
<jam> sure
<poolie> skype/pots?
<jam> pots is always easier for me, but i've got skype, too
<phinze> halstead|wccls: it means "$REVISION_AFTER_BINARIES and every revision thereafter"
<poolie> k
<poolie> jam: strace yes|sleep 60
<chmac> jam: Not sure what conversion to 2a means. From what you said I'm thinking that it'll happen automatically at some point... :-)
<chmac> Plus, the new branch I request 2.9 will have a lot less history than trunk, so that'll be quicker
<spiv> chmac: 2a is the current repository format, it became the default in bzr 2.0.  "bzr upgrade" will upgrade an existing repo to it.
<chmac> spiv: Ok, so I could upgrade repos I've created myself. lp:wordpress/2.9 is an auto-imported repo so I'm guessing I can't modify it any more, or can i?
<chmac> https://code.launchpad.net/~chmac/wordpress/2.9
<chmac> If I rename the repo, or assign it to a team instead of me, will the import process continue to work?
<chmac> I noticed some other auto imported branches are ~vsimports/blah
<spiv> chmac: I think you can file a request (at https://answers.launchpad.net/launchpad) to get the import upgraded\
<chmac> I think it makes sense for the branch to be owned by a generic user rather than me, it's the wordpress/branches/2.9 release rather than my own version of it, my own version will be based off it
<spiv> chmac: ^ mwhudson
<chmac> I love the responsiveness of people on this channel, launchpad has a very human feel to it... :-)
<chmac> Oh, I'm on the wrong channel, DOH!
<chmac> Sweet, just updated bzr thanks to https://launchpad.net/~bzr/+archive/ppa
<mwhudson> spiv, chmac: hmm?
<spiv> mwhudson: see #launchpad, looks like intellectronica has taken care of things
<mwhudson> spiv: ah, ok
<chmac> Oh, yeah, sorry, I didn't follow up on that, intellectronica did indeed take care of it for me :-)
<chmac> I ran `bzr branch lp:~vcs-imports/wordpress/2.9 wp29` then `bzr rm wp29/wp-includes/js/tinymce/` then `bzr commit -m "blah"`, it gave me the next available revision number
<chmac> That might get confusing when a new commit comes into 2.9 as the numbers might be the same
<chmac> Is that the way things are supposed to work, my version number will only apply to my branch, or is there an alternative I'm missing?
<chmac> Can I specify my own version numbers as rchmac-1 or something?
<jam> chmac: revision *numbers* are a branch local number
<chmac> jam: Ok, so I can ignore it, the numbers might be the same but that doesn't matter, is that correct?
<jam> chmac: right
<chmac> jam: Ok, thanks :-)
<jam> numbers are a useful shortcut in the context of a branch
<jam> so you can say "did you get rev 10 of my branch", and someone can see that they are only at 8
<jam> etc
<jam> internally we have unique revision-ids
<jam> but they don't have obvious ordinal semantics
<jam> (bzr log --show-ids if you want the details)
<chmac> Ok, they're specific to the branch. I've seen the long gnarly revision ids, I'm guessing they're the globally unique id
<jam> yep
<chmac> Can I safely `cp -r branch1 branch2` and then work on them separately?
<chmac> I tried `bzr branch branch1 branch2`, then branch2 shows its parent as branch1, which is accurate. I really want to branch from lp but safe myself downloading it all again... :-)
<jam> chmac: create a shared repository
<jam> bzr init-repo .
<jam> bzr reconfigured --use-shared branch1
<jam> then all branches created underneath the repo
<jam> will share the storage
<jam> and you won't redownload everything
<jam> sorry'
<jam> 'bzr reconfigure ...'
<chmac> jam: Ok, I'll read up on those, sounds like what I want, thanks
<blueyed> I had local commits, which apparently got reverted when I wanted to revert the conflicts from "bzr up" (which I've thought would have been a "bzr merge"). Any chance to get those internal merge back from the internals of bzr?
<bob2> bzr heads
<chmac> bzr push --stacked-on=lp:~vcs-imports/wordpress/2.9 bzr+ssh://chmac@bazaar.launchpad.net/~wpflavours/wordpress/wpflavour-no-visual-editor
<chmac> bzr: ERROR: Not a branch: "/home/chm/W/Code/wpflavours/wpflavour-no-visual-editor/lp:~vcs-imports/wordpress/2.9/".
<bob2> bound branches can be awkward
<bob2> especially if you forget to commit before bzr up
<chmac> Am I overcomplicating maybe? Can I just `bzr push lp:~wpflavours/wordpress/wpflavour-no-visual-editor` and bzr will know that the code came from lp:~vcs-imports/wordpress/2.9 originally?
<spiv> chmac: I think you need to give the full bzr+ssh URL instead of lp: to --stacked-on
<chmac> spiv: Oh crap, I expanded the lp: in the wrong part of the command, DOH!
<blueyed> bob2: thanks so far.. have found a revision-id.. how can I apply this back now?
<chmac> spiv: Thanks, I'll try that, that's what I meant to do
<bob2> blueyed: first, back up everything so you don't lose what you have
<chmac> Took me long enough to figure out what lp: expanded to, then I put it in the wrong place!
<bob2> blueyed: then 'bzr branch -r revid:afdsdfasdfggsfg@rftwertert-243241234 . ../recovered'
<chmac> spiv: Looks like it's working, thanks :-)
<lifeless> bob2: 'bzr merge . -r revid:revid:afdsdfasdfggsfg@rftwertert-243241234' is easier
<bob2> hm
<blueyed> this is f*cking b0rked.. I'm getting blogs.moved.moved etc.. also when trying to merge the dead parent.
<blueyed> will have to resolve this by hand I fear.
<blueyed> this probably conflicts so much again, since I'm merging into a branch, where I had local changes made (and cherrypicked from), but the parent's ancestor had been changed.
<blueyed> Can I forbid bzr-svn to kick in when I only want to add a symlink (which points at at directory with .svn in it)?
<lifeless> blueyed: to add a symlink just run 'bzr add', not 'bzr add symlink'
<blueyed> lifeless: but I do not want to add all that .moved stuff..
<lifeless> blueyed: so clean it up first
<blueyed> ok, but the workaround does work.. will do add "add $DIR" then revert.
<spiv> blueyed: you can pass --no-recurse to add
#bzr 2009-12-22
<spiv> Gar, gnome-terminal just crashed.
<spiv> Hmm, an assertion error from vte in xsession-errors.
<mwhudson> ow
<chmac> `bzr branch lp:~vcs-imports/wordpress/2.9 wp29`, `cd wp29`, `bzr up` tells me the repository is at 11084, but there are new revisions in launchpad that it's not pulling down.
<chmac> I'm guessing I've misunderstood how branching / updating works. Any pointers?
<chmac> Hmm, maybe I need to merge...
<gutworth>  bzr pull
<chmac> gutworth: Aha, ok, thanks
<spiv> chmac: 'bzr up' is for making a checkout of a branch up-to-date.  You did 'bzr branch', so you simply have a branch, not a checkout.
<chmac> spiv: Thanks. I'm starting to wrap my head around those concepts... :-)
<spiv> chmac: hence why you need to 'pull'
<spiv> Odd, https://code.edge.launchpad.net/~johnf-inodes/bzr/serve-init/+merge/12938 hasn't been automatically marked as merged.
<poolie> jam, i guess you're asleep?
<poolie> feeding pqm...
<spiv> <pqm> nom nom nom
<jam> poolie: not asleep yet, just not near the machine
<jam> poolie: what's up?
<poolie> hi jam
<poolie> i was just thinking about your thing of getting changes in more quickly
<poolie> because a couple of relevant things came up today
<poolie> one being, could we test LockDir.peek
<poolie> and the other, should you check for existing users of the module featuers
<poolie> features*
<poolie> in both cases it would have some value- it's possible the test could fail, today or later
<poolie> but it's the kind of thing that tends to change something from being 5m into an hour, or an hour into a day
<lifeless> poolie: changing symbol names added the concern about checking for users of the symbols
<lifeless> poolie: So its clearly possible to do a 5m thing there :)
<poolie> ?
<lifeless> 15:45 < poolie> and the other, should you check for existing users of the module featuers
<poolie> so one thing could have been to take a smaller step
<poolie> of just changing the implementation not the name
<lifeless> yes
<chx> hi. how cna i do a commit after a merge w the merge tips as commit message?
<awilkins> What do you chaps use for requirements tracking? Standard issue tracker?
<lifeless> yes
<Solipsist> ive attempt to revert local changes using 'bzr revert' but keep getting this error message: bzr: ERROR: The file id "xxxx" is not present in the tree , what does it mean?
<spiv> Solipsist: if you're getting that and you aren't passing any arguments to 'bzr revert' then that would be a bug I think.  Which version of bzr?
<Solipsist> using v 2.0.3
<Solipsist> so i deleted a directory and now i want to restore it from the local repost
<Solipsist> being used to git, i tried bzr checkout, but that's a no go so i looked at the commands and tried bzr revert directory/, then just bzr revert
<Solipsist> is there a page describing bzr for us used to SVN, and lately GIT?
<spiv> Solipsist: 'bzr revert DIR' or just 'bzr revert' in a working tree are supposed to do that.
<spiv> Solipsist: so it sounds like you've hit a bug, which is a bit surprising but not impossible.
<spiv> Solipsist: so please do file a bug report
<Solipsist> ok, but filing a bug won't help me much right now, so what can i do to remedy this?
<Solipsist> i have no changes i wish to keep so i could throw away the working tree and restore it from the local repos ive created, the local repos has been updated from the remote with bzr pull
<Solipsist> i guess this whole bazaar concept of a branch confuses me, if i understand it correctly a branch is an actual filesystem directory structure?
<Solipsist> as im sure yoy know in GIT and CVS, a branch is a meta concept and two branches can be the exact same directory structure and you can switch between them without having to have separate sets of directories for each branch, it seems more natural to me
<ronny> currently yes
<Solipsist> currently?
<Solipsist> so i want to checkout the branch from my local repos?
<ronny> Solipsist: i overheard that git style branching is on the way
<Solipsist> that would be very welcome :)
<Solipsist> anyhow, i got a directory with a .bzr directory and a set of subdirectories, i want to restore the files in the subdirectories to those in the local repos
<Solipsist> so i type bzr checkout
<ronny> its bzr revert
<ronny> bzr revert reverts the workdir state
<ronny> bzr checkout makes a new workdir from a branch of any location
<Solipsist> ronny: look above, bzr revert throws an error
<ronny> cna you paste the complete output of bzr revert, also use the -v parameter to get it more verbose
<Solipsist> ronny: preferably not in a public channel, can i query you?
<ronny> i'd prefer here since im not sure if i can help
<ronny> well, make a private paste on paste.pocoo.org to begin with
<Solipsist> ronny: i appreciate the offer but i cant post it publicly, plus it's bad manners pasting a lot of text in an IRC channel
<ronny> Solipsist: start by making a private paste on paste.pocoo.org
<Solipsist> bzr seems to have issues with special characters in filenames when dealing with different file systems, HFS+ on this machine and ext3 on the machines of the other committers
<ronny> Solipsist: sounds like a unicode normalisation issue
<Solipsist> perhaps, never had the same issue with git
<mangerduchien> hi all
<mangerduchien> I am facing a problem with bazaar and proxy. I am using Ubuntu Karmic Koala (9.10) with bazaar version 2.0.2 and I configured my environment with http_proxy="myproxy". However bazaar do not take the proxy into account
<mangerduchien> Does anyone could help me ?
<Pilky> Am I right in thinking that bzr ships with Ubuntu by default?
<beuno> Pilky, it is not
<beuno> it's in main, but not included in the default install
<Pilky> right
<mangerduchien> bzr is in Ubuntu repository and the last version is 2.0.0. I was having the same problem with this version so I installed 2.0.2 that can be found on https://launchpad.net/bzr/2.0
<mangerduchien> but nothing changed
<jam> morning all
<mangerduchien> morning
<jam> mangerduchien: generally, we respect http_proxy, are you sure you 'export'ed it appropriately?
<jam> also, there is a bug in resolving lp: urls
<jam> that is only fixed in the 2.1 series
<jam> (xmlrpc needed custom code to handle proxies)
<mangerduchien> i am facing the lp: url problem
<mangerduchien> i have to use bazaar 2.1 ?*
<jam> 2.1.0b4 will fix it for you, but I don't think it is packaged
<jam> mangerduchien: well, the quick fix is to use "http://bazaar.launchpad.net/...." or "https://code.launchpad.net/..."
<jam> the latter redirects to the former
<jam> but lets you use  the short form
<jam> so I tihnk
<jam> bzr branch https://code.launchpad.net/foo
<jam> will evaluate to the same as
<jam> bzr branch lp:foo
<mangerduchien> i am trying to get : lp:~launchpad-pqm/launchpad/devel
<jam> mangerduchien: bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
<jam> or bzr branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
<mangerduchien> ok thanks, i'll try
<jam> if you have registered an ssh key
<jam> the latter should be faster
<mangerduchien> ok, it seems to work
<mangerduchien> thank you  very much
<jelmer> hi jam, mangerduchien
<mangerduchien> hi jelmer
<Davidbrcz> Hi all
<Davidbrcz> i'm a noob with bazaar
<Davidbrcz> i want to extract a spefic version of a project
<Davidbrcz> but i've not found in the doc a way do to it
<Davidbrcz> someone could help me ?
<mwhudson> Davidbrcz: bzr branch -r $revsion trunk old-version will work
<Davidbrcz> mwhudson, hum
<Davidbrcz> strange error
<Davidbrcz> i want to extract the first revision of this http://bazaar.launchpad.net/~sean-pringle/musca/dev/files
<Davidbrcz> i'v created a folder
<Davidbrcz> and the i did bzr init; bzr branch http://bazaar.launchpad.net/~sean-pringle/musca/dev/files
<Davidbrcz> but the second command gives me an error
<mwhudson> oh
<mwhudson> right, you want to do bzr branch http://bazaar.launchpad.net/~sean-pringle/musca/dev
<Davidbrcz> why oh ?
<mwhudson> not with the /files on the end
<Davidbrcz> ok
<Davidbrcz> i've got the current version
<Davidbrcz> and to get the first one ?
<Davidbrcz> hum
<Davidbrcz> i get it
<Davidbrcz> thx
<Davidbrcz> :)
<toabctl> hi. i have a question:
<toabctl> i want to merge abzr-branch with: bzr merge --pull lp:~mhall119/loco-directory/0.2-loco-events
<toabctl> the merge works, but when i commit i have to add the commit message and after the commit there is no message or something about mhall119, but he was the guy who made the changes.
<toabctl> can anybody help with this problem?
<mwhudson> toabctl: try bzr log --include-merges
<toabctl> mwhudson, that's it. thanks a lot!
<mwhudson> toabctl: bzr qlog (from qbzr) or bzr viz (from bzr-gtk) might be interesting too
<wgrant> If I look at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/gnome-chemistry-utils/lucid/revision/19, I see that there are two merges involved. If I click on one of the merges, it says that it was merged at revision 18.
<wgrant> Is that a Loggerhead bug?
 * beuno looks
<beuno> wgrant, it does look like a LH bug
<beuno> could you file it?
<wgrant> beuno: Sure.
<beuno> thanks
<wgrant> I've noticed it on a couple of other branches too, so it's probably universal.
<poolie> hello beuno, wgrant
<wgrant> Morning poolie.
<beuno> hey hey poolie
<beuno> wgrant, I have a suspicion on what it could be
<beuno> my next bug to fix is in bzr-upload, but I may tackle that one tomorrow
<wgrant> Bug #499614
<ubottu> Launchpad bug 499614 in loggerhead "Merged revision is one less than it should be" [Undecided,New] https://launchpad.net/bugs/499614
<wgrant> Hm, not long to go now.
<poolie> till 500k?
<mwhudson> hm, i was sure i'd fixed that...
<mwhudson> maybe it's time to update the loggerhead that launchpad uses
<poolie> hi jam, spiv, igc
<jam> hi poolie
<poolie> thanks for the reviews
<jam> poolie: thank *you* for doing mine :)
<jam> poolie: small update on the "set a larger socket size for transmission"
<jam> as near as I can tell
<jam> ssh itself will allow up to 2MB to be written to stdin
<jam> before it blocks
<poolie> k
<jam> well, at least our 'out.write()' gets to write about that much
<jam> certainly > 1MB
<jam> at least, after the last server side "I wrote XX bytes" I see 28 64kB reads on the local side
<poolie> jam, regarding update -r
<jam> and many of the writes finish in 0.000 s
<poolie> ok that's not surprising
<jelmer_> ooh, update -r is finally happening ? :-))
<poolie> i think this branch is worth adding regardless of where we think it will end up
<jam> poolie: I approved your changes
<poolie> jelmer_: https://code.edge.launchpad.net/~mbp/bzr/45719-update-r/+merge/16476 reviews welcome
<poolie> and hi
<jam> certainly it shouldn't block on internal disagreement, which I think blocked it so far
<jam> which is a bit silly
<poolie> you're definitely coming to vila's villa?
<jam> wow... fetching in 'groupcompress' order generated 70.5MB, vs 50MB fetching in 'unordered' ...
<jam> poolie: are you sure Calvin Rose's email isn't spam :)
<poolie> jam: i had to moderate it too
<poolie> which was a bit sad
<poolie> i did wonder
<jam> poolie: I realized you moderated it from the timestamp, which is why I brought it up
<poolie> jelmer, do you have any idea based on knowledge of cifs why in bug 498378, after renaming a directory, we don't immediately see it under the new name?
<ubottu> Launchpad bug 498378 in bzr "Lockdir disappeared after being renamed" [Medium,Incomplete] https://launchpad.net/bugs/498378
<jam> poolie: speaking of which, just checking that vila's villa is start Mon Jan 25, leave after Fri Jan 29th
<poolie> i can imagine there is some cache incoherency or something
<poolie> but if we know what specifically it is, we might be able to work around it
<poolie> correct
* lifeless changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: mbp | bzr 2.1.0b4 and 2.0.3 released
<lifeless> bombs away
<poolie> on testtools?
<lifeless> yes
<mwhudson> does "NotImplementedError: SilentUIFactory doesn't support make_output_stream" mean anything obvious to anyone?
<spiv> mwhudson: apart from the bleeding obvious?  Not to me :)
<mwhudson> darn
#bzr 2009-12-23
<lifeless> mwhudson: ui api changes
<lifeless> mwhudson: silentuifactory is generally regarded as testing only so if you're using it in production you may need to fix it.
<mwhudson> lifeless: all i was doing is calling run_bzr
<mwhudson> but ok
<mwhudson> anyway, i cribbed some code to set a ui factory and it works now
<lifeless> mwhudson: oh, so the default 'call run_bzr' breaks now? I'd really like it if you file a bug about that.
<mwhudson> lifeless: yes; ok
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/499637
<ubottu> Ubuntu bug 499637 in bzr "run_bzr() fails unless you set a ui factory" [Undecided,New]
<jelmer> poolie: No idea, sorry
<jelmer> in general, CIFS shares should have the same semantics as NTFS drives
<poolie> mwhudson: it does mean something to me
<poolie> mwhudson: it means that you're calling code that wants to do an output stream but you've asked it to be silent
<poolie> so you have to make up your mind :)
<poolie> or fix one of these things
<mwhudson> poolie: i haven't asked for it to be silent; that's the default
<poolie> spiv: bug 495023 is nice :)
<ubottu> Launchpad bug 495023 in bzr "Interrupting commit to smart server sometimes removes files" [High,Confirmed] https://launchpad.net/bugs/495023
<lifeless> poolie: I think you misread the no idea comment, it was from jelmer
<lifeless> poolie: and I think SilentUI should eat an output stream :)
<poolie> lifeless: no i didn't
<spiv> poolie: if by nice you mean "signals are die die die" :)
<spiv> s/are/argh/
<spiv> (weird typo!)
<scorp007> how do I change the submit branch that shows up in bzr info?
<lifeless> poolie: ok
<poolie> :)
<lifeless> poolie: ah I see, it made sense to the earlier comment ;)
<lifeless> scorp007: via bzr submit
<scorp007> oh
<scorp007> there's no such command? you mean send?
<lifeless> yes
<lifeless> poolie: and boom, it lands
<lifeless> james_w: I've blogged about getting started with bzr-builddeb
<lifeless> http://radar.oreilly.com/2009/12/the-best-and-the-worst-tech-of.html
<lifeless> I love the quote about scrum-as-practiced :)
<spiv> Launchpad should announce new merge proposals in this IRC channel.
<mwhudson> spiv: statik has a thingummy that does that
<mwhudson> (it works off email i guess)
<spiv> Yeah, something email triggered would do I suppose.
<spiv> I don't want to look after an IRC bot, I want someone else to do all the hard work :)
<mwhudson> i suggest you talk to statik then
<statik> yo
<mwhudson> !
<statik> all i had was a procmail rule the spit text at radix's publishbot
<statik> niemeyers mup supports the same interface
<mwhudson> poolie: where does make_uifactory_for_stream  live?
<mwhudson> oh hang on, maybe the checkout i'm grepping is out of date
<poolie> actually make_ui_for_terminal
<poolie> in bzrlib.ui
<mwhudson> ah ok
<poolie> you know what i mean :)
<mwhudson>     ui.ui_factory = ui.make_ui_for_terminal(
<mwhudson>         sys.stdin, sys.stdout, sys.stderr)
<mwhudson> doing this seems to work
<mwhudson> (i cargo culted that from some where else)
<poolie> jml, still around?
<jml> poolie, yes.
<Viper550> okay, used explorer to make a trunk "repository" on my hard drive for something, how do I push it up to lp?
<poolie> lifeless: first test against testtools trunk and it fails with an AttributeError :/
<lifeless> poolie: ugh :( pastebin ?
<poolie>     self.exception_handlers.insert(0,
<poolie> AttributeError: 'TestAdd' object has no attribute 'exception_handlers'
<Peng> Oh? In what, lp:bzr?
<lifeless> poolie: that indicates you have an old testtools version
<lifeless> poolie: definitely not trunk, or 0.9.2
<poolie> it does look like it
<poolie> i'm pretty sure i have trunk
<lifeless> python -c 'import testtools; print testtools.__file__'
<poolie> ah maybe i have jml's old trunk
<poolie> i thought you were going to check the version?
<poolie> https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/16525
<poolie> bit of a bug in lp that this can happen
<lifeless> that what can happen?
<poolie> that i can do 'bzr pull' in a checkout of testtools trunk, but not get what's the new trunk
<lifeless> yes
<poolie> this can be seen as a bug in putting the owner into the url
<lifeless> if jml had moved the branch you would have gotten an error
<poolie> right
<lifeless> I consider the bug to be bzr storing the resolved branch though
<spiv> Well, there can be more than one bug :)
<poolie> anyhow
<lifeless> spiv: true, but I *like* owner in url :P
<poolie> does it?
<lifeless> spiv: I'll agree to 'side effect'
<poolie> i guess it does, though it's possible i just used the full url originally
<poolie> anyhow
<poolie> i am glad this is in
<poolie> i'd like to tweak the display to show errors as they happen
<poolie> and that's better done not specific to bzr
<lifeless> poolie: yes, bzr branch lp:foo -> parent will be bzr+ssh://b.l.n/foo/~bar/baz
<poolie> assuming it can be merged
<lifeless> poolie: so, errors showing as they happen - change bzr's reporter to not use the 'current global ui factory' and instead cache the ui factory it is started with.
<poolie> ok
<poolie> that sounds good
<lifeless> poolie: tests running with silent ui are hiding reporting of things via note() - I saw this, but its an orthogonal change to the root class
<poolie> what's the connection?
<poolie> ah
<lifeless> if you run with --parallel=fork, the global ui isn't ever changed, and the current encoded behaviour can be seen. With a normal run, things get masked.
<lifeless> poolie: btw you can use the testtools packages in the beta ppa - or install the subunit releases ppa and get subunit and testtools from there.
<poolie> i know
<lifeless> poolie: I'm happy for you to run from trunk of these dependencies, just want to be sure you know its optional.
<poolie> but i may actually patch them
<poolie> so (barely) slightly easier to start with branches
<lifeless> poolie: sure. They both have bzr packaging branches, so you can patch with packages too :)
<lifeless> poolie: fwiw I run from packages on them, regardless of patched-or-not, it just works out easier overall, I think.
<poolie> definitely helps by the time there are binaries
<lifeless> Someone next year I'll do the 'include the failed test work area' patch
<lifeless> using the addOnException TestCase api to add a tarball detail
<lifeless> s/Someone/Sometime/
<lifeless> poolie: well, I find it has a bunch of benefits; I find out about things that would make packaging harder (such as files not included in the tarball) early;
<lifeless> I don't need to remember to set the python path
<poolie> true
<poolie> ok, maybe i'll build from them
<lifeless> and I don't need to futz with a local python install getting in the way in the future.
<poolie> k
<poolie> signing off soon
<lifeless> see you in the new year
<spiv> Ok, I'm off too.
 * lifeless sniffs
<lifeless> I can't tell from here
<lifeless> Peng: new test dependency
 * Peng nods
<lifeless> Peng: its in lucid, or the bzr-beta-ppa
<Peng> I've got it from source.
<lifeless> kk
<Fleabag> hi
<Peng> I like playing with --parallel, so I already needed it anyway. :P
<Peng> Besides, I don't run the test suite much.
<lifeless> Peng: :P
<Peng> I should probably RTFM, but: subunit is a superset of testtools, right? And bzr now always depends on testtools, but only uses subunit for --parallel, right?
<lifeless> subunit is orthogonal to testtools
<Peng> It doesn't depend on testtools?
<lifeless> it does
<lifeless> so its a superset in the same way that bzrlib is a superset of testtools :)
<Peng> Heh, okay.
<lifeless> subunit is: a protocol definition, serialiser in [languages], parser in [languages] and command line filters for the protocol.
<Peng> Oooh.
<lifeless> e.g. see libcppunit-subunit-dev - link that in and use it as your test reporter, and you can use subunit-filter,subunit-stats, subunit-tags etc with your favourite cppunit using test suite.
<lifeless> and even subunit-diff
<ronny> lifeless: is there any buildin sheduling  in subunit
<ronny> (i.e. choosing what tests get executed)
<lifeless> ronny: no, but it encourages an idiom of having unique ids for tests, and you can use subunit-ls to turn a stream into a \n separated list of test ids
<lifeless> which works very will with runners that support choosing based on test id (such as bzr, or zopes test runner)
<lifeless> ronny: however, the python 'subunit.run' module can select tests with whatever granularity you give it. It would be appropriate for that module to gain a --load-list feature, I think.
<lifeless> ronny: (wouldn't help non-python runners, but would be convenient for python folk)
<ronny> lifeless: im thinking in terms of 2-way communication in ad-hoc networks
<lifeless> ronny: subunit itself is unidirectional, but it should play nice in larger systems that do 2-way stuff (an example of which is vilas patch to bzr selftest --parallel to feed small chunks to the worker processes)
<ronny> at least thats what we want to build for py.test and possibly others
<lifeless> ronny: sure, I'd be delighted to see subunit as part of that
<ronny> lifeless: does it have separate message lines for collect/discover and run?
<lifeless> it doesn't have the first two concepts
<ronny> then there is little use for it
<lifeless> I think thats a premature opinion
<lifeless> for several reasons
<lifeless> firstly, subunit passes things it doesn't understand through, so you can embed it in other protocols without needing special out-of-band signalling
<lifeless> secondly, setup and control of a test process is a very different problem to machine readable output from the test process; its the latter that subunit provides (and pretty nicely now, I think).
<lifeless> lastly, setting up a remote process isn't a test protocol problem, its a remote execution problem, and there are plenty of tools to do that today, so I don't see why you'd want to write it again :)
<lifeless> the other test protocols around:
<lifeless> pandokia
<lifeless> tap
<lifeless> junit-xml
<lifeless> none of them provide for setting up a remote process
<lifeless> (pandokia in aggregate does, but not in its test description format)
<ronny> hmm
<ronny> i suppose i really ought to take another look
<ronny> discovery/feedback will be an important part tho
<lifeless> I never said it wasn't important :)
<lifeless> what do you mean by feedback
<lifeless> you said collect/discovery before
<ronny> lifeless: test nodes report the tests they discover, the node manager gives feedback on if they should run it
<lifeless> ronny: why do it that way?
<ronny> the set of tests that gets run depends on the platform/environment
<lifeless> sure
<lifeless> but that doesn't imply chatty protocols
<ronny> lifeless: well, parallelize test-runs over a ad-hoc network and it suddenly gets handy
<ronny> something needs to keep track of what tests had been executed
<lifeless> ronny: here is a different way: master node calculates all tests, inspects for machine requirements, partitions by available machines and their info
<ronny> thats a lot more tricky than just letting things happen and react according to that
<lifeless> anyhow.. here is how you can do the approach you have in mind with subunit easily
<lifeless> from the node send "available: id\n" to advertise a test that can be run
<lifeless> on the node read "run: id\n" to run a test, and EOF  to shutdown the node
<ronny> yes, thats along what i was thinking
<ronny> lifeless: feel like adding that as optional extension to subunit, so runners for other languages can add it?
<lifeless> on the master, hook each nodes output up to either a subunit.ProtocolTestCase or subunit.TestProtocolServer (if you are running twisted or asyncore you'll want the second)
<ronny> lifeless: we'll most likely be using execnet at least for the setup
<lifeless> to hook it up, use
<lifeless> parser = ProtocolTestCase(stream, passthrough=extra)
<lifeless> where extra is a closure with a write method,
<lifeless> that write method will get called with "available: id\n" and any other extensions you have.
<lifeless> and to kick if off with ProtocolTestCasse, do run(masterresultobject)
<lifeless> using the TestProtocolServer is slightly different, but not much.
<lifeless> you need to arrange to call lineReceived for it.
<lifeless> ronny: are you saying 'reserve the token "available" so that other folk doing similar things might choose the same token'?
<ronny> lifeless: yes
<lifeless> ronny: If so, I'm happy to note that your project is doing this in the subunit docs
<ronny> also the token run
<lifeless> ronny: subunit won't see the token run at all
<lifeless> ronny: subunit is unidirectional
<ronny> lifeless: just as note in the docs, so other folks know the feedback protocol
<lifeless> sure
<ronny> well, actually run and skip
<lifeless> ronny: why would you need skip ?
<lifeless> ronny: only tell it to run things you want it to run :)
<ronny> lifeless: then the collect/run parts would have to be async
<lifeless> I don't see the connection.
<lifeless> ronny: so, I think a document describing what you're doing and how it hangs together would be great; that could be either included in subunit, or referenced from subunits docs, depending on how you write it and what focus you put in it.
<lifeless> ronny: one thing I've been considering doing is making subunit easier to install with e.g. pip or easy_install.
<lifeless> ronny: I mention this in case ease of install comes up for you.
<ronny> lifeless: please do that, we'll most likely use virtualenvs
<ronny> lifeless: as far as i remember various testrunners execute tests as they find them, and dont collect the whole suite before starting test runs
<lifeless> ronny: only nose does that
<lifeless> ronny: you can use a lazy loader to do that in any unittest runner that can run a callable (e.g. via the test_suite idiom)
<ronny> thats why a skip directive would be helpfull
<lifeless> ronny: sorry, I still don't follow
<ronny> just report what you find as you go, and get feedback on if you should run the tests
<lifeless> ronny: yes, I get that, but I don't see why you need a skip directive on the control side
<ronny> i dont like having to guess the dont cases
<lifeless> seems like a waste to me, but sure, I can see how it would work
<ronny> i want to have a simple sync loop along while test=find_next() { report; read action; if action { run }}
<lifeless> I think that would be very slow
<lifeless> I'd do
<lifeless> tests = find_all()
<lifeless> advertise_tests(tests)
<lifeless> to_run = (read all run: commands)
<lifeless> tests.filter(to_run)
<lifeless> run_tests(tests)
<lifeless> well, with the last three lines in a loop
<ronny> lifeless: i dont want to tell them all to run at a time
<lifeless> read one or more run commands, execute, look for more
<lifeless> ronny: sure, but that is orthogonal to discovering them all at once, isn't it ?
<ronny> i like more granular events tho
<lifeless> ronny: I have some experience with this, having done --parallel and --parallel=ec2 for bzr; you really don't want to be waiting for network latency on each test
<ronny> hmk
<lifeless> if you have enough tests that multi machine parallelisation is worth doing, per test latency will kill your performance.
<lifeless> unless your tests are several times slower than that latency
<ronny> hmm, well, mine probably are, but other are most likely not
<ronny> lifeless: i just discovered that mine and holgers mindmodels rather differ (his already solved the latency stuff, i suppose other issues as well)
<lifeless> well, mail me :) or t-i-p, or something :)
<ronny> lifeless: yes, i'll get my mindmodel fixed, then i suppose start something on tip
<Kamping_Kaiser> hi all, sorry if this is covered in a faq:
<Kamping_Kaiser> can i pull in a file from a repository which *does not* share a common ancestor with my current branch?
<Kamping_Kaiser> (keeping history)
<spiv> Kamping_Kaiser: you can merge in an entire, unrelated branch.  bzr in general can't track revision history when cherrypicking just parts of revisions (like single files rather than all changes)
<Kamping_Kaiser> spiv: the branch is 1 script + a README, as long as the merge doesn't eat my existing README that would be fine for me.
<spiv> Kamping_Kaiser: cool
<spiv> Kamping_Kaiser: the trick then is "bzr merge -r0..-1 ../unrelated_branch
<spiv> "
<Peng> Kamping_Kaiser: The README will probably conflict. Anyway, even if it does get eaten, nothing's set in stone until you commit; you can just revert it.
<spiv> it'll probably give a path conflict about the README file; they'll both be there (one will be README, the other README.moved, probably)
<Kamping_Kaiser> spiv: if i understand that correctly, from revision 0 until latest revision?
<Peng> Kamping_Kaiser: Uh-huh.
<spiv> you can 'bzr mv' and/or 'bzr rm' things before committing of course to make sure they are how you want them.
<Kamping_Kaiser> Peng: re README, noted, I'll try and see what happens.
<Kamping_Kaiser> Conflict adding file README.  Moved existing file to README.moved.
<spiv> Kamping_Kaiser: right.  The zeroth "revision" is in a sense a common ancestor for all branches :)
<Kamping_Kaiser> *grin*
<Kamping_Kaiser> I'm interested that the existing readme is moved, rather then the new one.
<spiv> Yeah, I'm not sure why that choice was made.  Possibly a coin toss came up heads rather than tails when the implementer had to choose ;)
<Kamping_Kaiser> hehe.
<spiv> I must admit I tend to find it backwards to my expectations most of the time too.
<Kamping_Kaiser> I'll resist the urge to pontificate about what I think shoul happen instead, since I won't be offering patches ;)
<spiv> Kamping_Kaiser: you can always file bugs or post to the list :)
<spiv> Anyway, I'm off to bed.  I'm glad that that merge seems to have worked for you.
<Kamping_Kaiser> thanks for that, sleep well
<rubbs> Morning
<Viper550> okay, I got a local repository. I'm using Windows. How would I push it up to Launchpad?
<rubbs> Viper550: are you trying to contribute to a specific project?
<Viper550> yeah, trying to bring it up to my project
<rubbs> what is your project's name.
<Viper550> lp:~viper550/bbesque/platypus
<Viper550> I can explain the name "platypus" though :P
<rubbs> no need... just a sec, and I can help you out.
<rubbs> ok, so you've got a branch you want to push to the bbesque project. The simplest way to do that is to say "bzr push lp:~viper550/bbesque/branch-name" where branch name is whatever you want (platypus I think is what you got).
<rubbs> you will need to set up some ssh keys and get them working with pagent
<rubbs> do you know how to do that?
<rubbs> I could help you out with that if you don't
<Viper550> dunno
<rubbs> k... do you have putty installed?
<rubbs> if not go here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html and download the link under "A Windows installer for everything except PuTTYtel"
<Viper550> done
<rubbs> once you have the putty suite installed, you need to generate some ssh keys.
<Viper550> puttygen?
<rubbs> yep
<rubbs> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair?action=show&redirect=CreatingAnSSHKeyPair
<rubbs> let me know when you are ready for more info.  I'll brb.
<Viper550> done
<Viper550> rubbs: done the pagent part
<rubbs> Viper550: sorry about being away for so long.
<rubbs> so if you've added your keys to pagent and added the key to launchpad you should be able to just push to the location. like this: bzr push lp:~viper550/bbesque/branch-name
<Viper550> can it be done through a GUI?
<rubbs> yes
<Viper550> okay...how? I got Bazaar Explorer open with my local branch
<rubbs> I'm looking up exatly how to do it... shouldn't take me more than a sec
<rubbs> Viper550: when you push, you should be able to just put "lp:~viper550/bbesque/branch-name" into the "location" text field
<Viper550> bzr: ERROR: Parent directory of bzr push lp:~viper550/bbesque/platypus does not exist.
<Viper550> wait whoops
<Viper550> "You have not informed bzr of your Launchpad ID"
<rubbs> Oh, k... sorry forgot that step myself. just a sec I'll find out where yo uset that
<rubbs> under settings -> credentials
<rubbs> you need to have an entry like this:
<rubbs> [Launchpad]
<rubbs> host = .launchpad.net
<rubbs> scheme = ssh
<rubbs> user = patrick-regan
<rubbs> er... sorry others out there, forgot to pastebin
<jelmer_> rubbs: Running "bzr lp-login patrick-regan" should create that for you
<rubbs> jelmer_ I know, but he was asking on how to do this with bzr explorer
<LeoNerd> Is it possible to define an alias command including a shell fragment? e.g. I'd love to define   bzr diffstat =>  bzr diff | diffstat
<Viper550> yay got it
<rubbs> Viper550: cool glad you got it working. it should be easier from now on
<rubbs> come back if you have any other questions.
<Viper550> thanks :)
<rubbs> np
<rubbs> LeoNerd: I don't think that's possible
<rubbs> LeoNerd: you could alias that at the shell level though
<LeoNerd> Yeah, I know... but doing it in bzr itself would be cute :)
<rubbs> LeoNerd: agreed. I pretty sure it's not possible (at this point) though.
<LeoNerd> Ahwell.. no great problem..
<LaserJock> quick question: how do I set my commit email address on a directory basis?
<LaserJock> can I do it from the command line or do I have to mess with ~/.bazaar/locations.conf
<rubbs> LaserJock: use the --branch option on the whoami command
<rubbs> see "bzr help whoami" for more info
<LaserJock> rubbs: ah, I thought I could just be in the dir and run bzr whoami
<LaserJock> rubbs: switching to an actual branch in the dir and using --branch solved the mystery :-)
<rubbs> LaserJock: good to hear that helped.
<rubbs> the problem with whoami working on the dir level only is that you have to go out of a branch then to set it globally.
<rubbs> that and most people use the global email for most/all of their projects.
<rubbs> but I can see where you came up with that...
<rubbs> I'll see about the documentation... Maybe somethign needs to be clarified.
<LaserJock> rubbs: I guess I was going by "if there was a branch right here what would it use?"
<rubbs> LaserJock:
<rubbs> er... LaserJock: I see. I'll look into that
<LaserJock> does olive-gtk visualize the relationship between branches in a repo?
<rubbs> LaserJock: not as well as qlog or explorer (which uses qlog).
<rubbs> LaserJock: qlog is part of the qbzr plugin
<LaserJock> oh dang it, how do I make a file I just did a bzr add to untracked again? I haven't committed yet
<jpds> LaserJock: bzr remove --keep $file
<beuno> I forgot how much I liked bzrlib
<beuno> 90% of the time it's already solved a problem I'm trying to solve
<lifeless> \o/
<lifeless> merry christmas beuno
<beuno> hey lifeless
<beuno> merry christmas to you
<beuno> even more so considering you're in the future
<lifeless> -> plane to catch  :) ciao
<beuno> lifeless, have a great flight
<mneptok> Manny Krramer!
<jwhitley> is there an equivalent of git-filter-branch for bzr?  I can fast-export/fast-import, of course, but it'd be nice to stay in bzr if possible.
<jwhitley> use case: I have a repo which I've tried to deliberately keep fairly small.  I now realize that some time ago I inadvertently committed some directories with contents much larger than I'd like.
<rubbs> jwhitley: so really you just want to strip out some stuff from your history?
<jwhitley> It happens to be practical to rewrite the repo history (it's a personal and private repo, so far), FWIW.
<jwhitley> rubbs: yes, precisely.
<rubbs> just a sec... someone yesterday was asking the same thing. I'll look through my logs and see what the best answers where
<jwhitley> lovely, thanks.
<rubbs> jwhitley: http://irclogs.ubuntu.com/2009/12/21/%23bzr.html check the post from 20:40 (time) on. I think that may be what you're looking for
<jwhitley> rubbs: outstanding, just what I needed.  thanks!
<rubbs> np
<chromakode> hey bzr folks, are "oh no my repo is broken" inquiries acceptable here?
<chromakode> I am a bzr noob who upgraded a lp: branch, and managed to break it somehow.
<chromakode> le google is not currently turning up useful advice.
<chromakode> ah, you know what? I think I followed some bad bug report advice and changed a stacking branch to a non-stacking format
<gutworth> how is it broken?
<maxb> chromakode: If you explain more about what exactly you did and what's broken, someone here can probably help
<chromakode> thanks. didn't want to bug you if this was an inappropriate channel
<chromakode> any operation [upgrade,check] fails with "RepositoryFormatKnitPack4 ... is not a stackable format."
<chromakode> trying `push --overwrite` yields "(Bazaar pack repository format 1 with rich root (needs bzr 1.0)) is not a stackable format"
<gutworth> what's bzr info?
<maxb> stacking was added in 1.6, aka KnitPack5
<chromakode> I believe my original sin was running `bzr upgrade --rich-root-pack lp:myrepo`
<chromakode> (lp:myrepo was 2a, I believe)
<chromakode> gutworth, bzr info returns the same "(Bazaar pack repository format 1 with rich root (needs bzr 1.0)) is not a stackable format"
<maxb> and stacked?
<chromakode> maxb, yes.
<maxb> is this a public branch?
<chromakode> public how so?
<chromakode> it's on launchpad: lp:~chromakode/drizzle-interface/dbapi
<chromakode> so, my local branch was in a repo
<vadi21> I remember there being a "bzr release" command... but apparently I'm mistaken. What is the proper command name?
<chromakode> and I think what happened was that I needed to upgrade my repo. however, I googled and saw the `bzr upgrade --rich-root-pack lp:myrepo` command, which probably borked my remote format
<maxb> chromakode: Launchpad has a rather peculiar way of storing branches - it has a public and a writable copy. So it might be simplest for you to simply branch the public copy, which is still intact
<maxb> If you try accessing it over http, you'll end up at the public copy, since http branch access is unauthenticated
<vadi21> got it, bzr export
<chromakode> maxb, I think my local branch is in order, but it seems like any operations on the lp branch will break. should I just throw out the lp branch using the web interface, and remake it?
<maxb> chromakode: Either that, which will wipe metadata such as bug<->branch links, or subscriptions, or, you could delete just the branch files using an sftp client, and re-push
<chromakode> maxb, sounds good. so, just for the learning experience, my fault was downgrading the repo to a non-stacking format?
<maxb> Sounds like that
<maxb> Though one could say it's bzr's fault for not shrieking loudly and refusing
<chromakode> I might claim that if I wasn't a nice user ;)
<igc1> morning
<AfC> Does bzr-git do git SSH URLs?
<AfC> I tried the URL I was given [ ssh://<username>@git.gnome.org/git/gtk+ ] and Bazaar gave me a helpful error message about how I had to use bzr+ssh:// as the protocol
<AfC> So then I tried git+ssh and it didn't work.
<AfC> So presumably my answer is "no" but perhaps I'm missing something?
<RAOF> AfC: It does, yes.
<RAOF> I forget quite how I managed to make it happen, though.
<poolie> hi all
<RAOF> AfC: I'd guess you'd be after a URI of the form git+ssh://git@gitorious.org/~raof/banshee/gapless-work.git
<AfC> RAOF: Hm. I thought I'd tried that.
<poolie> afc: looking at the code, git+ssh should work
<AfC> poolie: ok, thanks!
 * AfC tries again
<AfC> Ok, so I have no idea what happened there. I did
<AfC> $ bzr branch git+ssh://afcowie@git.gnome.org/git/gnote/ master
<AfC> and it worked
<AfC> so... well, er
<AfC> thanks?
<AfC> :)
<AfC> [I had previously tried with the gtk+ URL and it crashed]
<AfC> [though I also tried a git:// URL and that crashed too]
<AfC> [so I'm guessing someone fixed something and did a release and got it into the PPA? Either way, thanks!]
<RAOF> Now all bzr-git needs is a way to specify non-master branches!
#bzr 2009-12-24
<Meliboeus> and a way to integrate submodules
<jelmer_> RAOF: s/bzr-git/bzr
<jelmer_> Meliboeus: ... and unfortunately that requires nested tree support in bzr itself
<RAOF> jelmer_: Does it really require full bzr support for that to pull a different HEAD from a git repository?  I don't care for colocated bzr branches, just for the ability to grab & push to different git branches.
<Meliboeus> jelmter_: exactly :-(
<Meliboeus> my words. I don't care if I loose the history on submodules...
<jelmer_> ROAF: Yes, there needs to be a way to address colocated branches in the Bazaar UI and API
<RAOF> Which is presumably not the same level of difficulty as _implementing_ colocated bzr branches, no?
<AfC> jelmer_: but why? On the Bazaar user side of things, we know about keeping different branches in different directories. I can easily checkout ~/vcs/gtk+/master and ~/vcs/gtk+/release-2.18.0 into different branch directories.
<AfC> [if I could just address the Git branch somehow]
<RAOF> Actually, I guess after being able to address them actually having colocated bzr branches should be pretty trivial, right?
<jelmer_> AfC: Yes, and the addressing a colocated branch is something that is in bzr core
<jelmer_> AfC: s/is/needs to be/
<AfC> jelmer_: oh.
<jelmer_> AfC: That's the main thing bzr-git is waiting for, the Bazaar UI needs to know about colocated branches and needs to pass that information down in the API (which is implemented, among other things, by bzr-git)
<jelmer_> RAOF: Yes, it's different from implementing colocated branches for native .bzr directories
<jelmer_> perhaps this is actually a good topic for the sprint in january
<poolie> bug 500000 has just come and gone
<ubottu> Launchpad bug 500000 in usplash "wrong aspect ratio boot splash on widescreen screen" [Undecided,New] https://launchpad.net/bugs/500000
<poolie> what a boring bug too
<gutworth> don't worry
<gutworth> there will be bug 6000000 and 70000000 and 10000000000000000000000000000000000
<ubottu> Error: Launchpad bug 6000000 could not be found
<ubottu> Error: Launchpad bug 70000000 could not be found
<ubottu> Error: Launchpad bug 10000000000000000000000000000000000 could not be found
<gutworth> bug 1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<gutworth> hmm
<gutworth> bug me not
<poolie> spiv, do you know about https://bugs.edge.launchpad.net/bzr/+bug/499817
<ubottu> Ubuntu bug 499817 in bzr "Not possible to commit because concurrent request limit reached (whatever that means)" [Undecided,New]
<pickscrape> Hi, I'm using bzr-svn for the first time with google code and am finding that I'm being asked for my username and password for every operation that interacts with the repository
<pickscrape> I'm running bzr 2.0.3 and bzr-svn 1.0.0 on a karmic system.
<pickscrape> I've found one bug that looks related but it's on an OSX system and talks of the OSX keychain, so I'm not sure how relevant it is.
<jelmer> pickscrape, hi
<jelmer> pickscrape: bazaar does not cache passwords yet
<jelmer> pickscrape: neither for bzr-svn nor for bzr itself
<jelmer> pickscrape: you can add a password manually in ~/.bazaar/authentication.conf
<Peng> jelmer: I'm never actually going to get around to it, but hypothetically, would you mind if I stole bzr-svn's caching code for Loggerhead? :D
<jelmer> Peng: not sure I follow - how would you like to use bzr-svn's caching code?
<jelmer> Peng: it's all quite svn-specific
<Peng> jelmer: OK, maybe not much more than the open_tdb method, but that'd still be useful. :)
<thewrath> hey all
<pickscrape> jelmer: thanks
<mtaylor> hey lovely people...
<mtaylor> bzr: ERROR: exceptions.ValueError: unknown object type identifier 60
<mtaylor> aroo?
<Peng> That's a known and I think fixed bug.
<poolie> mtaylor: bug 427736
<ubottu> Launchpad bug 427736 in bzr/2.0 "1.9->2a fetch from smart server causes "unknown object type identifier 60" in bencode" [Critical,Fix released] https://launchpad.net/bugs/427736
<poolie> fixed in 2.1.0b1 and 2.0.1
<mtaylor> poolie: awesome.
<mtaylor> chromakode: ^^^
<poolie> you should really go to 2.0.4 or 2.1b4
<poolie> uh
<poolie> that would be 2.0.3 i guess
<mtaylor> poolie: I hear grumbling that he was using 2.0.3 ... although what it really pointed out to me is that I needed to upgrade that branch. but just in case it's useful to you to know someone is experiencing it using 2.0.3
<chromakode> I
<chromakode> I'm that someone :)
<mtaylor> it's chromakode !
<poolie> hm
<poolie> if that's true, please reopen the bug
<poolie> it would be surprising
<poolie> but, software is often surprising
<chromakode> oh! it worked now!
<mtaylor> chromakode: yay!
<chromakode> perhaps lp lagged when he updated the branch
<mtaylor> are you pulling from http:
<mtaylor> ?
<chromakode> no, lp:
<poolie> but do you have an lp account?
<chromakode> yes.
<poolie> that can be either ssh or http
<mtaylor> well, that will resolve to http if you haven't told it your launchpad login ... but i'm guessing if you've every pushed from there you have...
<chromakode> it's over ssh
<mtaylor> cool
<mtaylor> yeah - I've been noticing a slight lag recently even over ssh
<mtaylor> which I've found ... annoying
<chromakode> what did you change, mtaylor?
<mtaylor> chromakode: I upgraded the remote branches to --2a
<chromakode> okay, so all hunky dory now :)
<mtaylor> yup
<chromakode> thanks poolie
<mtaylor> thanks poolie !
<poolie> you're welcome
<spiv> poolie: no, I'm not sure what's going on with bug 499817.  I've left a small comment.
<ubottu> Launchpad bug 499817 in bzr "Not possible to commit because concurrent request limit reached (whatever that means)" [Medium,Incomplete] https://launchpad.net/bugs/499817
<poolie> k
<poolie> have a happy holiday, i'm off
<spiv> poolie: you too :)
<Kamping_Kaiser> would it be possible to customise bzr (bzr-email?) to email a specific address when a particular file changes?
<Kamping_Kaiser> eg, debian/changelog
<chromakode> happy holidays poolie
<spiv> Kamping_Kaiser: I expect so
<spiv> Kamping_Kaiser: some hacking required presumably
<spiv> Kamping_Kaiser: or mail an address than runs a procmail recipe that greps the mail for the filename and remails accordingly ;)
<Kamping_Kaiser> spiv: the last item sounds like more effort then learning python to do the hacking properly ;)
<Kamping_Kaiser> thanks for the reply.
<Kamping_Kaiser> what package would i look for pythons 'tests' module? none of the results for 'apt-cache search python tests' seems relevant. ( and its required for bzr selftest)
<Peng> "tests" is?
<Peng> There's bzrlib.tests, the stdlib's unittest, and very recent bzr.dev requires testtools, but I dunno about "tests".
<Peng> Kamping_Kaiser: Ohhhh. I think that error comes from a plugin, trying to do a relative import of its own tests. IIRC it'
<Peng> Kamping_Kaiser: s fixed in a newer version. You can also do "bzr --no-plugins selftest" to disable all plugins.
<Kamping_Kaiser> Peng: so the bug is in the plugin?
<Kamping_Kaiser> I'll try without plugins for now, thanks.
<Peng> Kamping_Kaiser: Well you'd have to pastebin a traceback to be sure.
<Peng> Kamping_Kaiser: But I remember a plugin being a source of that error. Like I said, IIRC it's been fixed.
<Kamping_Kaiser> Peng: fastimport's redme suggests running 'bzr selftest fastimport', which is bombing out with:
<Kamping_Kaiser> bzr: ERROR: No module named tests
<Kamping_Kaiser> You may need to install this Python library separately.
<Kamping_Kaiser> so i assumed its a missing module ;)
<Kamping_Kaiser> looks like all the plugins loaded are doing this, fwiw.
<Peng> Kamping_Kaiser: Run with -Derror or check .bzr.log.
<Peng> Kamping_Kaiser: It's probably because it's always loading all of the plugins' test suites, whether or not you're running them.
<lifeless> Kamping_Kaiser: I'd guess fastimport's setup.py doesn't install the tests subpackage.
<lifeless> Kamping_Kaiser: or one of your plugins doesn't.
<Peng> Kamping_Kaiser: "bzr selftest -s bp.fastimport" should avoid loading any unnecessary tests.
<Peng> Are the prefix aliases documented anywhere?
<Peng> (I got "bp." by reading bzrlib/tests/__init__.py...)
<Peng> Anyway, bye!
<Kamping_Kaiser> thanks mate
<Kamping_Kaiser> lifeless: looks like its the cia plugin - 'bzr selftest -s bp.fastimport' runs fine, ' bzr -Derror selftest launchpad 2>&1 |pastebinit -' bombs out with http://pastebin.com/f231eb61f
<Kamping_Kaiser> i could believe it, cia stoped working for me a month or so ago.
<lifeless> Kamping_Kaiser: cia !- launchpad
<lifeless> Kamping_Kaiser: file bugs1
<lifeless> !
<Kamping_Kaiser> lifeless: on the cia blowing everything up, or everything else blowing up over cia?
<Peng> Kamping_Kaiser: FWIW, "bzr selftest foo" builds a list of all tests, and then filters it. "bzr selftest -s bzrlib.foo" just loads the tests starting with that prefix.
<Kamping_Kaiser> nod
<lifeless> Kamping_Kaiser: both.
<lifeless> Kamping_Kaiser: both are cia bugs I suspect.
<jelmer_> Kamping_Kaiser, you're running an old version of bzr-cia
<Kamping_Kaiser> jelmer_: ok, i'll get a new branch
<Kamping_Kaiser> jelmer_: ftr, the readme should probably suggest using the name 'cia' instead of letting me assume 'bzr-cia' will work ;)
<Kamping_Kaiser> jelmer_: thanks for the heads up re: version. launchpad selftets ok again, so cia's test failures are its own problem now :)
<lifeless> ngnight
<jelmer_> g'night lifeless
<Kamping_Kaiser> later mate
<rubbs> good morning #bzr
<thewrath> good morning
<thewrath> hey rubbs could you do me a favor?
<rubbs> I will do my best. what's up?
<rubbs> sorry, wrong button. I accedentally quit. If you said something before this (other than asking for help) I missed it
<thewrath> could someone go to here http://csse.usc.edu/research/CODECOUNT/ and download the 2009.10 and try to compijle it for me
<thewrath> 08:02 <+thewrath> i want to see if you are getting the same error
<thewrath> it is c++ code
<rubbs> sure... just a sec.
<thewrath> thank you so much
<Peng> rubbs: fwiw, you did not miss anything
<rubbs> Peng: thanks.
<thewrath> thank you rubbs
<rubbs> thewrath: ok, compiling now.
<rubbs> sorry for taking a while... slow connection
<thewrath> okay
<thewrath> tell me if you get a .exe file
<rubbs> k... I"m on Linux, so I'll get an executable, but it won't be an .exe file.
<thewrath> you sure?
<rubbs> yeah, I'll get an executable... but that executable won't work on Windows. If you need a windows binary... I'll see what I can do. I have a windows environment lying around
<rubbs> thewrath: this is the error I get: http://paste.ubuntu.com/345904/
<thewrath> so you dont have an executable?
<rubbs> no. no executable
<maxb> Are there any existing tools for rewriting branches off of a mainline, after said mainline has been replaced with one with different revids and fileids?
<rubbs> maxb: I'm not sure I understand. You have a main branch that you rewrote (possibly with rebase or something) and you want your other branches to reflect that?
<maxb> essentially
<maxb> Actually I had a main branch reflecting Ubuntu development that I synthesized, and now there is an official Ubuntu package branch
<rubbs> are these branches just going to be mirrors? or are you trying to keep changes in the branches while changing their history?
<maxb> I want to keep changes
<maxb> I realize this is a hard problem :-)
<maxb> However, I can probably hack bzr-rewrite into doing what I want, if there isn't a suitable tool already in existence
<rubbs> maxb: I'll admit that this problem is a little bit out of my expertise (sp?) range.
<rubbs> how many revisions are you wanting to keep in the branches?
<maxb> not that many, but I'd rather not recommit them manually
<maxb> I guess I'll hack on bzr-rewrite a bit
<rubbs> sorry, I couldn't help more.
<thewrath> rubbs: i have an older version i am going to check out
<rubbs> thewrath:  2007?
<thewrath> UCC v.2009.01
<thewrath> rubbs: you still around
<thewrath> if so what was that link you sent me
<rubbs> I'm around... just a sec I'll dig it up
<rubbs>  http://paste.ubuntu.com/345904/
<thewrath> okay i got cygwin working with c++
<thewrath> i got the same error thank you
<thewrath> i will report it to the usc code count people
<rubbs> cool
<rubbs> glad to have helped
<ruki> when i  upload to a branch on launchpad. does it replace the old copy of the file with the new one? cant i access my original old file?
<gutworth> ruki: bzr cat -rold_rev myfile
<nekohayo> hey there, if someone has a branch where he pushed a ton of commits of unrelated features (instead of making separate branches out of them), when merging, is it better to cherry-pick and do multiple merges?
<gutworth> your choice really
<nekohayo> ok
<nekohayo> thanks :)
<Tiibiidii> hi, i'm new to bazaar... it's better to keep versioned only the source directory for my projects, or it's better to keep versioned my entire IDE's workspace?
<Tiibiidii> afaik bazaar should get along fine with binary files, but i've never done any versioning, and so i'm not sure if it's too much of a overhead
<awilkins> Tiibiidii, I tend to work out which files it can regenerate and ignore them
<Tiibiidii> it <-- do you refer to the IDE?
<awilkins> e.g. - if I'm using Eclipse and / or Maven I ignore things like bin/ target/ .metadata/
<awilkins> Ye
<awilkins> Yes
<Tiibiidii> mhn
<Tiibiidii> shouldn't it be easy to version only the src files thus?
<awilkins> And your IDE project file, if it uses such a thing
<Tiibiidii> i mean: that way i should have to exclude manually the bin/ folder for every project
<awilkins> For Java I'm using Maven and that will regenerate an Eclipse project
<Tiibiidii> (sorry the dumb question: as i said i'm new)
<awilkins> Tiibiidii, I think there may be a default list of includes you can configure
<awilkins> .. or maybe not
<awilkins> The main problem with versioning binaries is the inevitable conflicts
<awilkins> e.g. - Visual studio timestamps binaries, so you NEVER get the same file twice, even with the same sources
<Tiibiidii> mhn
<awilkins> And of course, they are large, and unnecessary because you have the sources
<Tiibiidii> so, i think i'll version only the src/ directories
<Tiibiidii> awilkins, can i ask you another thing?
<awilkins> Sure
<Tiibiidii> if i'm not wrong
<Tiibiidii> there's a bzr command to rename a file/dir
<Tiibiidii> what happens if i rename that file manually?
<gutworth> bzr can guess that you did
<gutworth> usually
<awilkins> It will lose track of it.. this happens in other VCS systems too (except git).
<awilkins> There's `bzr mv --auto`
<awilkins> Which guesses
<awilkins> And `bzr mv foo bar --after` if you want to be explicit
<Tiibiidii> should i use `bzr mv --auto` after a manual move/rename or before?
<awilkins> After
<Tiibiidii> ok
<awilkins> Before there's nothing for it to guess about :-)
<Tiibiidii> and if i rename the directory back to the previous name?
<Tiibiidii> and if i rename the whole versioned directory (which i guess contains some .bzr files)?
<awilkins> Only the root directory contains a .bzr folder
<Tiibiidii> (and thank you very much for the answers so far :D )
<awilkins> It's not like SVN where there's a control dir in each directory
<Tiibiidii> root? do you mean $HOME ?
<awilkins> No, the root of the versioned tree
<Tiibiidii> mhn
<Tiibiidii> if i go to $HOME/whateverdirectory
<Tiibiidii> and then
<Tiibiidii> bzr init
<Tiibiidii> and then
<Tiibiidii> cd .. && mv whateverdirectory whateverdirectory2
<Tiibiidii> whateverdirectory is the root, right?
<kfogel> Tiibiidii: you should be fine; I don't think foo/.bzr knows foo's name
<kfogel> you can rename, move it around, whatever
<awilkins> Yup, confirm that
<Tiibiidii> ok
<kfogel> what *will* break is when you have branches inside a shared repository and you move them outside that shared repository
<awilkins> The only problem you get is if you move a branch that a checkout is attached to
<kfogel> Tiibiidii: but if you don't know what that means, don't worry about it
<kfogel> Tiibiidii: what awilkins said :-)
<gutworth> kfogel: how does emacs transition come?
<Tiibiidii> ok, thanks... in fact i don't know yet what a checkout is :-)
<gutworth> docs!
<Tiibiidii> last question (i think):
<Tiibiidii> if i move .bzr from the root to another (external from root) directory, does that dir becomes a new root and then bzr tries to guess the changes made to it?
<awilkins> That will break stuff
<gutworth> no, that will break
<Tiibiidii> ok :D
<kfogel> gutworth: arrrgh, waiting for a savannah.gnu.org admin to finally do https://savannah.gnu.org/support/index.php?107170
<Tiibiidii> thank you again
<kfogel> gutworth: IOW, it's going great, in the sense that we're ready to switch as soon as the admins pull the trigger; what's difficult is getting them to pay attention :-).
<awilkins> If you need to nest your content deeper, create new folders to hold it then move the root level folders down into them
<gutworth> I'm excited to push some emacs patches I've been cursing cvs with
<kfogel> gutworth: there's some ticket where they asked for volunteer admins; I'm going to go chime in there and say I'll help.  Whatever it takes to get this moving :-).
<Tiibiidii> <awilkins> If you need to nest your content deeper, create new folders to hold it then move the root level folders down into them <-- thank you... actually my use case is a bit more silly: i kept backupped some old versions of my code, and so i'm trying to find a painless and effortless way to version these in a unique root :D
<kfogel> abentley: mornin', sunshine
<gutworth> good look ten
<abentley> kfogel: good evening.
<gutworth> kfogel: why do you need read-only cvs?
<gutworth> couldn't you just impose a social block?
<kfogel> gutworth: not reliable enough -- Emacs has hundreds of devs
<gutworth> ah
<awilkins> I agree, I had to migrate a CVS for about 20 users and the only way to stop them committing is to chmod -w the files into oblivion
<kfogel> awilkins: :-)
<awilkins> "Use the SVN repo dammit!"   "But, but, but CVS!!!"
<awilkins> I shall face the same uphill struggle, no doubt, trying to get people to adopt DVCS systems
<kfogel> awilkins: and CVS is a pretty easy transition -- no adjustment of mental model needed.
<kfogel> dcvs is harder
<awilkins> Yeah, it took me about 2-3 days to get my head around the fact that merge was suddenly not incredibly painful
<awilkins> At least Bazaar allows them to pretend it's SVN
<awilkins> If only TBZR was as mature as TSVN   (but if wishes were horses...)
<awilkins> I'm stuck on one project that implements it's own DVCS system that's more like a patch-queue thing with no dependency management, stores changesets in Java BLOB files by shoving them into an SVN repo
<awilkins> It's very Wrong
<awilkins> It has a small excuse in that it started 5 years ago when git was in it's infancy... and the data it's versioning isn't source code, it's a graph of objects.
<gutworth> haha
<awilkins> But I sit there and think that plopping it into ordered plain text files gets you free DVCS support... and that making text files fast for read-operations (writes are relatively sparse) is less challenging than making the merge system it has work well
<awilkins> 'tis only about 5M objects or so
<awilkins> 1000 objects per file and you have a file tree that's reasonable on most OSs (even Windows/NTFS)
<kfogel> awilkins: sounds like you're describing the architecture of most DVCSs anyway :-)
<awilkins> kfogel, I did briefly think about trying to version the objects as 1st class objects in git by writing some new bits that didn't target the filesystem but the BerkeleyDB instance it's in... but I think it might challenge even git to be managing 5M discrete objects
<awilkins> And would also challenge me somewhat to write it :-|
<kfogel> awilkins: I dunno, it's supposed to be pretty scalable.  Now, on the other hand, it might challenge the local filesystem to do that :-).
<awilkins> NTFS would curl up and die
<awilkins> Small files get inserted into the Master File Table
<awilkins> You'd have to custom-format a partition for it
<awilkins> Even then I think it would suck
<awilkins> It's happy enough with 7000 files, my other project (the one that's successful) is working on trees that size
<awilkins> They could do with better merging... it's XML model files and line-based merging gets a bit confused sometimes
<awilkins> But that's  a job for when I have time
<Tiibiidii> uhm... can i ask a question?
<Tiibiidii> i did a commit
<Tiibiidii> it said:
<Tiibiidii> modified geotag/GeoApplication.form, modified geotag/GeoApplication.java
<Tiibiidii> , etc.etc.
<Tiibiidii> but then
<Tiibiidii> bzr status and bzr diff
<Tiibiidii> print nothing
<gutworth> that's because you commited something
<awilkins> They report the differences between the current state and the last commit
<gutworth> so there are no changes in your wc
<awilkins> Since you just committed, that's zero
<Tiibiidii> ahhh, ok
<Tiibiidii> thanks
<gutworth> I suggest you read the tutorial
<Tiibiidii> yeah, i read only the 5 minutes introduction... ^^
#bzr 2009-12-25
<Stavros> hello
<Stavros> how can i export my repo to a tarball for emailing?
<Stavros> there's a format like that, isn't there?
<Stavros> how can i generate a file from a repo?
<Stavros> anyone?
<Peng> Stavros: Wait, a copy of the working tree, or all of the Bazaar data as well?
<Peng> Stavros: For the former, "bzr export". For the latter, you can probably work something out with "bzr send" or "bzr bundle".
<Peng> Stavros: Though I'd probably just tar it up. (Excluding the contents of .bzr/repository/obsolete_packs, but not the directory itself.)
<Peng> Stavros: (And removing the working trees first.)
<jelmer> Tak, hi
<pecisk> hi people, is there any common suggestions about how to prepeare code from bazaar repo for publishing? Have to remove .bzr directory and that's it? Or something else I should look upon?
<jpds> pecisk: bzr export - should do the trick.
<pecisk> jpds, yeah, already found it, thanks :)
<Peng> The bzr-upload plugin may also interest you.
<toabctl> hi
<toabctl> is it possible to close lp-bugs with a commit-message?
<Peng> toabctl: No.
<toabctl> Peng, ok. thanks
<Peng> There was a little discussion about this just today... Not sure where, though.
<RenatoSilva> Merry Christmas
<RenatoSilva> hmm, it seems it's not: http://encyclopedia.thefreedictionary.com/merry+Christmas
<RenatoSilva> oops, wrong channel
<RenatoSilva> verterok: hi, Merry Christmas
<verterok> RenatoSilva: hi, Merry xmas to you too!
<RenatoSilva> thanks for merging
<verterok> RenatoSilva: np, apologize the delay :)
<verterok> RenatoSilva: FYI, I'll upgrade bzr-java-lib format to 2.0
<RenatoSilva> verterok: ok
<RenatoSilva> verterok: mvn test not found?
<GuyFromHell> So I have this file. it's in a previous revision. it's no longer in the current revision. Is the suggested way of retrieving said file using "bzr cat"?
<jpds> GuyFromHell: bzr cat -r NNNN filename ?
<GuyFromHell> jpds, right, just making sure i wan't missing anything
 * GuyFromHell shrugs. was hoping it'd just bring back the file but i'm not opposed to using redirection
<lifeless> bzr revert -r NNNN filename
<jpds> GuyFromHell: Maybe... what lifeless said.
<GuyFromHell> you can revert single files?
<GuyFromHell> interesting
<GuyFromHell> and shiny, i like it.
<jpds> $ bzr rocks
<GuyFromHell> hank you :)
 * GuyFromHell is more a git fanboy but bzr isn't bad ;)
<verterok> RenatoSilva: huh?
<verterok> RenatoSilva: oh, that comment is from a failed test with tarmac, sorry
<RenatoSilva> ah ok
<verterok> RenatoSilva: I'm trying to automate the landing of approved branches :)
<Stavros> hello
<Stavros> is there a way for me to package a repo as a file?
<Stavros> basically the equivalent of bzr branch <repo>, zip <repo>
<jpds> Stavros: bzr export.
<Stavros> jpds: that doesn't include metadata though
<Stavros> goddamnit, bzr keeps ruining my repo these days
<nyu> hi
<nyu> I made a commit using sftp://, nothing seriously big (few kiB at most), and it's been running for a looong while
<nyu> it says it's uploaded 60 MiB by now
<nyu> "Uploading data to master branch - Stage:Fetching revisions:Inserting stream:repacking texts:texts 34106/42307"
<nyu> should I be worried?
<gutworth> sftp sucks
<nyu> or is bzr just "tidiing things up"
<nyu> I don't mind leaving it several hours or days
<nyu> but I'm scared.  I hope it's not some weird bug
#bzr 2009-12-26
<gutworth> it's a limitation of sftp I believe
<Peng> nyu: Bazaar is indeed tidying things up.
<Peng> nyu: If you use bzr+ssh://, it can do this efficiently on the server-side, but since it's sftp://, this means downloading, tidying, and re-uploading data.
<nyu> Peng: ok, thanks
<Peng> If it didn't do this, performance would slowly degrade over time . . . . .
<Peng> Anyway, it only winds up packing 10% of the time.
<Peng> And it's usually only a little data.
<saedelaere> puh, i'am stuck with bzr branch and i don't know what sf.net is doing :D
<saedelaere> this is the output of my bazaar repo on sf.net
<saedelaere> http://www.pastebin.org/68796
<saedelaere> but somehow i can't browse the new branch with http://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/changes
<saedelaere> next thing is, i created this branch some days ago when i thought i was ready to release the next stable version.
<saedelaere> but then i made further changes in the main branch. how can i update the branch stable.081 to the latest revision?
<saedelaere> ok i see i can access my repo on sf.net via a ssh shell
<saedelaere> perhaps i can do it there.
<Peng> saedelaere: Push from the main branch to the stable branch.
<Peng> saedelaere: Or, depending on how you did things, pull.
<Peng> (depending on which is most convenient, I mean)
<bialix> hi Peng
<saedelaere> i'am confused. perhaps the best thing would be to start from the scratch with bazaar. especially because i made the main development in the root folder.
<Peng> bialix: Good morning. :)
<saedelaere> i mean nothing can happen to the local branch i have?!
<bialix> best wishes to all
<saedelaere> but what happens if i just delete the .bzr directory on sf.net
<saedelaere> do i need to run something like bzr-init ?
<bialix> to create new branch?
<saedelaere> no, to start from the scratch with my online repo.
<saedelaere> i started with bazaar like this
<saedelaere> http://doc.bazaar.canonical.com/latest/en/user-guide/solo_intro.html
<bob2> what are you trying to achieve?
<saedelaere> hm, i created a new branch with [bzr branch]
<saedelaere> it is located here
<saedelaere> bzr://christianrapp@tv-viewer.bzr.sourceforge.net/bzrroot/tv-viewer/stable.081
<bialix> saedelaere: you may want to create shared repo first with bzr init-repo
<bialix> hmm, I remember you, you still fighting with sf?
<bob2> does sf have any docs on how their bzr hosting works?
<saedelaere> i think the repo on sf.net is already a shared repo
<bialix> so make branches within that repo in subdirectories
<bialix> what's your problem?
<saedelaere> i want to be able to browse the branch stable.081 via loggerhead.
<saedelaere> but
<saedelaere> http://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/stable.081
<saedelaere> does not work
<saedelaere> but the branch exists
<bialix> http://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/changes
<bialix> tv-viewer is the branch
<bialix> not a shared repo
<bialix> stable.081 is also branch
<bialix> at least bzr info bzr://tv-viewer.bzr.sourceforge.net/bzrroot/tv-viewer/stable.081 wfm
<bialix> maybe sf.net does not support multiple branches in their loggerhead?
<bialix> saedelaere: I'd delete the branch from bzr://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer
<bialix> and keep there only shared repo
<bialix> and put your main branch to bzr://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/trunk
<bialix> saedelaere: do you have sftp/ssh access to your repo?
<saedelaere> ok this sounds interesting. and where do i put other branches? in /trunk
<saedelaere> bialix: yes, ssh
<bialix> other branches at the same level
<bialix> bzr://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/branchA
<bialix> bzr://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/branchB
<bialix> etc
<bialix> does it make sense for you?
<bialix> saedelaere: if you dare enough you can delete the branch from bzr://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/
<bialix> you need to delete directory bzr://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/.bzr/branch/
<bialix> and keep other directories inside .bzr intact
<saedelaere> ah ok, so now i go to my repo with ssh.
<saedelaere> how do i get my main branch fom /tv-viewer/ to /tv-viewer/trunk
<bialix> with bzr branch
<bialix> or push
<bialix> do you have local copy?
<saedelaere> yes local copy is here
<bialix> so delete the .bzr/branch, then push to trunk
<bialix> delete on server
<bialix> keep local
<saedelaere> ok first delete the directory then push to trunk,
<saedelaere> i'll try that, wait a second
<saedelaere> before i issue the command. should i delete the stable.081 directory first?
<saedelaere> bialix:http://www.pastebin.org/68805
<bialix> no, keep it
<bialix> it's a valid branch
<saedelaere> bialix: http://tv-viewer.bzr.sourceforge.net/bzr/tv-viewer/
<saedelaere> this is looking very good
<bialix> hooraah
<bialix> is it what you want?
<bialix> Peng: does loggehead understand nested branches?
<saedelaere> yes i think so
<bialix> :-)
<saedelaere> bialix: thank you very much
<saedelaere> ok one more question :D
<bialix> always happy to help
<bialix> try
<Peng> bialix: Like, one branch inside another?
<bialix> Peng: yep
<Peng> bialix: IIRC, it will work fine, but there obviously won't be any directory listing page showing the inner branch.
<Peng> bialix: So you'll have to enter the URL manually.
<saedelaere> when i now make changes to stable.081. e.g. for a bugfix release. will the changes also appear in the log history of the branch trunk?
<bialix> I guess the problem of saedelaere was somehow related to that fact
<bialix> saedelaere: no
<Peng> (Not sure if there's an open bug about that.)
<saedelaere> i think i should read more about  the concept of a shared repository.
<bialix> http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html#each-branch-has-its-own-view-of-history
<bialix> saedelaere: shared repository is just storage
<bialix> big black box where branches keep their revisions
<bialix> but every branch has its own history
<Peng> saedelaere: It is purely a storage optimization, not a "concept".
<bialix> yes
<saedelaere> ok, i see. but now for example. i have r100 in one branch and revision 100 in another . when releasing the program they will both have the same revision? but the contect can be totally different
<saedelaere> s/contect/content
<Peng> saedelaere: Internally, bzr uses revision IDs. The simple numeric revision numbers are only a convenience, and only apply to that individual branch.
<Peng> Have you read the tutorial?
<saedelaere> Peng: this one?
<saedelaere> http://doc.bazaar.canonical.com/latest/en/tutorials/tutorial.html
<Peng> I dunno. Whatever.
<saedelaere> i think so, but this was some time ago, and meanwhile bazaar worked as i needed it. but i will read it again
<saedelaere> so thanks again for all your help! i think i can manage it from here. have a nice day...
<Peng> You too. :)
<bialix> read the Zen document I've linked above
<maxb> Is anyone else running Ubuntu lucid (or for that matter something else) and getting "Module pygments was already imported from ...." warnings when running bzr?
<seldomrw2> hi there, I'm looking for help using bzr explorer on Windows
<seldomrw2> look like it canot find my ssh public key
<seldomrw2> anoyone?
<seldomrw2> I'm using open ssh on Windows, I managed to make bzr work from the command line by setting the HOME environment variable to my user folder, but the explorer cannot pick it up correctly
<bialix> heya GaryvdM!
<GaryvdM> Hi bialix
<GaryvdM> Belated Merry Christmas.
<bialix> and you too
<bialix> actually for me it will be Jan 7
<bialix> hope you're ok :-)
<GaryvdM> Ah Jan 7 = christmas for Eastern Orthodox Churches
<GaryvdM> I'm well. You?
<seldomrw2> sorry, would anyone be so kind to help me out?
<GaryvdM> seldomrw2: just got here. Please repeat you question
<GaryvdM> *your
<seldomrw2> I'm having issues with bzr explorer on Win, looks like it cannot pick up my ssh keys
<seldomrw2> I managed ot make bzr work from the command line by setting the HOME env var to my user folder
<seldomrw2> but not on bzr explorer
<bialix> GaryvdM: to much work for the end of the year
<bialix> still working
<bialix> have no time for hacking
<bialix> seldomrw2: are you running explorer form command-line or via shortcut?
<bialix> *from
<GaryvdM> seldomrw2: Where did you set that HOME var? If through Windows Computer properties Dialog, you will need to restart BE
<GaryvdM> bialix: I know the feeling. I worked right untill the 24th Dec. Going back to work tomorrow :-(
<bialix> if you said it working for you in command-line, will it work if you run bzr explorer from command-line?
<bialix> GaryvdM: :-(
<seldomrw2> nope
<bialix> does your ssh key required password?
<bialix> why don't you use ssh-agent?
<seldomrw2> it does. I cannot make ssh-agent run on Windows honestly
<bialix> well, honestly I'm using pageant on Windows
<seldomrw2> I mean it starts but then I cannot add my keys
<bialix> and paramiko (default ssh client for bzr)
<bialix> have no experience with openssh
<seldomrw2> I hadn't heard of paramiko
<bialix> are you running bzr.exe from installer?
<seldomrw2> I don't think it ships in the Win version though
<seldomrw2> yes, the Win installer
<bialix> paramiko bundled there by default
<seldomrw2> let me check
<bialix> paramiko is the python library
<bialix> https://launchpad.net/paramiko
<seldomrw2> I thought bzr was using the open ssh version I have installed along with git
<bialix> it should use paramiko by default
<bialix> but maybe you have to use env variable BZR_SSH=paramiko to force it
<seldomrw2> do you know how to configure it?
<seldomrw2> yes, will try
<bialix> GaryvdM: just buy book on Qt4 :-P
<bialix> GaryvdM: it's about C++ programming but now I finally learn the right way
<seldomrw2> bialix, looks like that env var does the job, is there a way to let bzr pick it up automatically ithout starting the explorer from a batch file?
<bialix> seldomrw2: set this var via Start - Settings - System ?
<bialix> Start - Settings - Control Panel - System
<bialix> then Advanced - Environment Variables
<maxb> Anyone around who happens to know the proper way to submit changes for bzr-rewrite?
<maxb> It seems that Launchpad MPs are not used there
#bzr 2009-12-27
<ronny> jelmer: sup, where are you?
<jelmer> ronny, hey
<jelmer> ronny, sitting next to Wouter in front of the stairs on the second floor
<ronny> oh, last time i ran across him you wherent around, i'll be right there
<AnAnt> how can I push tags ?
<jelmer> AnAnt: tags should be pushed when you push a branch
<AnAnt> ok, thanks
<sproaty> I created a new directory, done 'bzr init' there, pulled my latest branch/commits in, copied/pasted my modified files, commited and am getting an error on pushing.
<sproaty> http://paste.pocoo.org/show/159911/
<sproaty> I'm doing this because of "diverged branch" errors I'm getting, and doing conflict/resolved put all these "markers" in my python files
<sproaty> hmm, I may have fixed it.
<sproaty> done bzr branch instead of init/pull
<sproaty> phew yup that fixed it
 * sproaty wipes the sweat away
<Peng> sproaty: "bzr init" uses the default format, and the current one is incompatible with lp:~sproaty/whyteboard/development's format. "bzr branch" uses the same format as the soruce branch.
<sproaty> ah I thought so
<sproaty> I think I started to get this whole branches are diverged after committing to one branch, uncommiting and then pushing the old commit to another branch
<Peng> sproaty: All "branches are diverged" means is that both branches contain some revisions that the other does not.
<Peng> sproaty: This obviously has to be resolved with "merge" (or "uncommit" if you want...) before you can push and pull between them again.
<sproaty> Peng, I wasn't sure whether to trust merge, plus I played around a bit (after backing up my newly changed files) and it stuck all this <<<<<<<<TREE stuff into my files
<Peng> sproaty: Those are conflicts, because both sides changed the same thing.
<Peng> sproaty: Merge is perfectly "trustworthy". I mean, the worst that can happen is it does something annoying and you have to revert.
<sproaty> ah, so the changes it makes are "undoable"
<Peng> sproaty: All changes in the working tree can be undone.
<sproaty> Peng, good to hear
<Peng> sproaty: Even if they weren't, you could just branch a new copy and rm -rf the original.
<sproaty> glad it's all fixed now, anyway :)
<maxb> jelmer: Hi - how should I submit changes to bzr-rewrite? The branch on Launchpad asks that people not submit MPs there.
<Wellark[]> hi! I want to deploy a bazaar repository which is accessed with bzr serve
<Wellark[]> I want to create a server side hook or something which will check the signatures when ever a push or commit from checkout happens
<Wellark[]> and if the revisions are not signed or verifying the signatures fails the push must be rejected
<Wellark[]> I made i quick test just to notice that pre_commit hook is not run on push
<Wellark[]> and there's no pre_push hook
<Wellark[]> I'll start looking thourgh the bzr code later, but I wanted to ask if someone has some tips or pointers where to look
<Wellark[]> I've only looked at the hooks section of the user reference and only hook that looks promising is pre_change_branch_tip, but I don't know yet whether or not it can provide access to the revision signatures and is there any way to prevent the change from happening
<Wellark[]> but I'm optimistic :)
<Wellark[]> I could do this kind of server side verification with pqm, no?
<Pilky> am I right in thinking "bzr init --append-revisions-only" basically means you can't use commands like uncommit?
<Peng> Pilky: Probably. Of course, you *can* turn append_revisions_only off, and then do whatever the hell you want. :D
<Pilky> heh, just wondering what it does
<Pilky> there's a few options that aren't very well explained in help docs
<Wellark[]> Yes! I can access the new revisions on server side during a push in pre_change_branch_tip hook and reject the push if needed by raising some exception
<Wellark[]> sweet! :)
<__monty__> How do I checkout bzr.dev?
<jkakar> __monty__: You can use: bzr branch lp:bzr
<__monty__> I guess I need the ip adress of the repository for that? I tried "bzr branch http://bazaar-vcs.org/bzr/bzr.dev/ bzr.dev"  and it gives me  "ERROR: Not a branch: ..."
<__monty__> jkakar?
<__monty__> jkakar ?
<jkakar> __monty__: Hi. :)
<wgrant> __monty__: 'bzr branch lp:bzr' is all you need.
<jkakar> __monty__: wgrant is right.  Also, the space between the http://... and the bzr.dev is a problem in the command you tried.
 * jkakar steps away
<__monty__> Thanks for the help guys, :-)
#bzr 2010-12-27
<fullermd> darren: If that's the case, it's definitely a bug...
<darren> is anyone here a developer on it? :)
<fullermd> Probably someone who'll read the backlog if nothing else.  But if you could file a bug on it, that would be good.
<fullermd> If not, I can try to bang one up later.
<darren> no problem, I will :)
<lifeless> mgz: I've merged most of your stuff - thanks. The subst stuff I was still not happy with so I reverted that, and I tweaked smoe other minor bits, In particular the setup test I made os specific via MatchesAny - trivial to do ;)
<sobersabre> hi.
<sobersabre> Is there something like svn:keywords in bzr ?
<sobersabre> I want to embed revision number into the message  (something to signify revision numbe from the already build application)
<bob2> not in bzr
<bob2> I don't think any modern vc includes support for that
<sobersabre> bob2: why is it a bad idea to have such a feature ?
<bob2> hard to define what it should do, means more work for every file modification, then general feature mostly useless when you have atomic commits and easily accessible logs
<bob2> if you just want to include a revno in something, add that to your build process
<lifeless> sobersabre: bzr-keywords plugin
<lifeless> bob2: $
<rjek> Of course, adding interogation of bzr to your build process suddendly breaks everything when you make a release via bzr export.
<ciss> hi!
<ciss> does bazaar support a feature similar to place holders in subversion - that is, variables that are replaced in-code on a commit?
<ciss> found a plugin: "Bazaar Keyword Templating Plugin"
<jelmer_> hi ciss
<jelmer_> yep, that's the plugin for that
<ciss> jelmer_: i forgot to add the "never mind, found ..." to my last comment :)
<lifeless> mgz: hi; so yes some care will be needed
<mgz> lifeless: I'm just filing a bug.
<mgz> bug 694800 is what still needs addressing on trunk testrepository
<ubot5> Launchpad bug 694800 in Testrepository "Test suite failures in IDFILE tests if backslash in TMP path" [Undecided,New] https://launchpad.net/bugs/694800
<lifeless> thank you
<mgz> I need to do a little cooking now, but am around-ish for the next hour at least.
<lifeless> mgz: please try rev 133
<mgz> that works for backslashes, but I don't see why you need to be so baroque about it.
<mgz> spaces or other shell significant characters in the path will still be a problem due to the general design on composing bits of shell script.
<lifeless> wll
<lifeless> where we know its a path, we should indeed pass path element lists around
<lifeless> as I said to you when you first looked at it, I'm not attached to the implementation, nor the api
<lifeless> however I do have some clear goals, and I think the current code is closer to them
<lifeless> and easier to expand into the right thing
<mgz> lifeless: teeny note, the 'list' is just because it's my mailinglist email account, and doesn't need preserving in NEWS
<lifeless> mgz: what nom de code would you like?
<mgz> as per bzr whoami or "Martin [gz]" as disambiguation seems to work okay.
<lifeless> ok
<mgz> thanks!
<lifeless> which would you prefer
<lifeless> I don't generally put email addresses in NEWS, simply because of spammers and folks reaction to that
<lifeless> so I'm inclined to do 'Martin [gz]'
<lifeless> if thats ok
<mgz> I think that's what I've been using recently, I'm not terribly consistent.
<ovnicraft> hi guys, i ma trying to merge in my repo and get this error http://paste.pocoo.org/show/310507/
<ovnicraft> i see the limbo dir and get N things what i cant understand
<ovnicraft> how solve this and merge ok my repo?
#bzr 2010-12-28
<sobersabre> hi.
<sobersabre> I have installed bzr on windows.
<sobersabre> how do I run bzr explorer ?
<sobersabre> (I understand it is a part of bzr distribution)
<jelmer> sobersabre: it's a separate plugin
<awilkins> The Windows distribution puts a shortcut on the desktop by default
<awilkins> Or you can start it on the command line with `bzr explorer` , I think
<sobersabre> awilkins: thanks!
<sobersabre> I will try this.
<zyga> ./bzr/branch/location makes bzr choke when an editor adds EOL to the end of that file
<zyga> ack to fix that?
<zyga> lifeless: ^ ?
<DonDiego> moin
<DonDiego> i'm using the text-checker-plugin to avoid adding tabs and trailing whitespace and similar in commits
<DonDiego> but the pattern matching is driving me crazy
<DonDiego> [name Makefile.am]
<DonDiego> this appears to get ignored
<DonDiego> below i have "[name *]" with default actions
<DonDiego> tabs are allowed in Makefile.am but nowhere else
<DonDiego> but the first section never appears to get triggered
<DonDiego> any hints?
<hsn> is there way to convert repote repo (which i dont admin) to bzr?
<hsn> svn repo
<zyga> hsn: yes
<hsn> let launchpad to import it?
<zyga> hsn: if you have a project page you can add a source branch that is imported by launchpad from one of few foreign system
<zyga> hsn: svn and git are supported, I'm sure some others are too but I cannot remember the full list like that, I only used git personally
<hsn> it is one way or 2 way sync
<zyga> hsn: svn has some approval process I'm not familiar with
<zyga> hsn: it's just a pull, one way
<zyga> hsn: but you can use bzr to commit to a svn repo so your options are wider than just that
<zyga> hsn: what are you trying to do?
<hsn> need mediawiki in bzr
<zyga> it probably is already
<zyga> ok, so it's not
<zyga> https://code.launchpad.net/mediawiki
<zyga> hmm
<zyga> it seems you have to be the owner of the project to set it up
<zyga> hsn: you can use a local branch
<zyga> hsn: not bound to lp in any way
<hsn> i own one project in launchpad, i will import mediawiki there
<zyga> hsn: don't just import mediawiki there without a good reason
<zyga> hsn: unless your projects is mediawiki clone it does not make sense
<zyga> hsn: you can simply get a bzr branch of mediawiki locally
<zyga> and push it to mediawiki project in lp under your own name
<zyga> so bzr push lp:~yourname/mediawiki/name-of-your-branch
<zyga> you can convert the svn tree locally using bzr and bzr-svn package
<zyga> there are docs on how to do that but I suspect that you can just simply bzr get the svn url
<zyga> I don't know what's going to happen if you want to get all the branches, this would work for svn trunk
<hsn> i need 17alpha branch
<zyga> hsn: then bzr get that directly
<zyga> hsn: if you try it and get stuck please ask again
 * zyga goes to work in another screen
<Tak> any thoughts on http://paste.pocoo.org/show/310950 ?
<Tak> the odd thing is that I get that behavior when using libpython, but not at the command line or in a script
<jelmer> hi Tak
<Tak> hi! :-)
<Tak> happy solstice
<jelmer> Tak: thanks, you too :-)
<jelmer> Tak: what happens if you try without the extensions built?
<jelmer> I don't see what's going on, after having had a quick look
<jelmer> Tak: In general, calling the command implementations from other code is a bad idea. Any reason for not calling branch.pull() ?
<Tak> that's odd...locate tells me that extension only exists in my local bzrlib wc
<Tak> mmm, I was using the lower-level api before (branch.pull)
<lifeless> zyga: well, its not intended for editing; bzr switch will change it for you
<jelmer> Tak: What made you switch?
<jelmer> 'morning lifeless
<Tak> iirc, there were some instances where the command api was doing some error handling/special-casing that I didn't want to redo by hand
<Tak> so then I just went that way across the board
<zyga> lifeless: yeah but bzr colo hardcodes the _absolute_ path of the tree so I had to fix it after realizing I broke it with out-of-tree mv
<zyga> lifeless: it's a simple fix that would at the very least make the behaviour more aligned with what users might expect
<lifeless> you can fix it with bzr switch
<lifeless> and the bzr code as written needed absolute paths, older versions will fail if its a relative path, so we always write abs paths.
<lifeless> zyga: I don't know if you're aware, but you can actually have \n in filenames :(
<zyga> lifeless: then we should print the repr of the filename and still allow a newline _not_ to break this
<zyga> lifeless: or do you think that I should not be able to mv my colocated branch  without having it explode?
<servertood> Hello
<servertood> Does bzr support perforce style mainline branching strategy
<servertood> does it support it out of the box
<zyga> servertood: what do you mean by mainline branchinc strategy?
<servertood> well I have a team on perforce
<maxb> servertood: You should bear in mind that most people here, myself included, will have no idea what "perforce style mainline branching strategy" is
<zyga> servertood: I used p4 for a year and a half but I never used that term before
<servertood> ok well the basic mainline appraoch to branching is something they document as a workflow for using perforce
<servertood> I have a team on p4 and we want an open source scm that works the same
<servertood> or better....
<zyga> servertood: could you please describe the workflow?
<servertood> one sec
<servertood> theres a master doc
<servertood> Im not finding it atm - heres a basic setup http://www.vaccaperna.co.uk/scm/branching.html
<servertood> littel better http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html
<servertood> ok I found it
<servertood> http://www.perforce.com/perforce/papers/bestpractices.html
<zyga> servertood: so which point explains the strategy you mentioned?
<servertood> scroll down to where the heading says "mainline model"
<zyga> o
<zyga> so
<zyga> one question
<zyga> how big is your "mainline"
<zyga> :-)
<servertood> 250 MB?
<zyga> checkout or entire history?
<zyga> do you have binary files?
<servertood> some
<servertood> images etc
<servertood> We are going to lose the history because its all garbage history anyway
<servertood> the team that was using the repo all used the same user for all checkins
<servertood> so there are alot of binaries that dont need to be there because its a mess but I would say 100MB check out might be right
<servertood> but not a huge amount of files
<servertood> lots of jar files etc
<zyga> servertood: so I was in a similar situation
<zyga> and I have the following to say as bzr user
<zyga> 1) binaries will make you cry over bzr
<servertood> hm
<zyga> 2) if you switch vcs you should consider splitting the repo (say to libaries/projects/components)
<servertood> that sucks
<zyga> and have separate trees for that
<servertood> whats the issue with binaries
<servertood> just too slow
<zyga> once you have that you can use bzr and you will be happy, p4 is actually so brain dead that bzr runs circles around it
<zyga> they are not handled very well, the AFAIR official policy is that they are not important enough to be optimized for, if you want to version ISO files bzr will kill you
<servertood> ok but what about stuff like images for webcontent
<servertood> I dont want to version huge binaries
<zyga> it _will_ work
<servertood> right now theres some jars that may be 10 MB 50 MB stuff like that
<zyga> but bzr assumes pretty much that you have to fit all the tree in memory
<zyga> x2-x10
<servertood> hm
<zyga> depending on stuff it does and bzr version you use
<zyga> lifeless: ^^ please bash me for talking nonsense if I do
<zyga> anyway
<servertood> ok that sounds a little troublesome
<zyga> it works very well for source
<zyga> text
<zyga> for binaries
<servertood> so the work around again for binaries is
<zyga> it works but it's not the primary use case so you may get big memory usage
<servertood> so theres no - "hey for these file extensions dont load into memory..."
<zyga> servertood: p4 is a versioned FTP server, really
<zyga> servertood: no, for various reasons, it's not that simple
<servertood> so is there a workaround
<servertood> or is the workaround dont do it at all
<zyga> servertood: there's been many people coming in and asking for support but nobody stepped up to do it
<zyga> servertood: there is no need for a workaround, if your files are not that big then you will not notice it
<zyga> servertood: if you start versioning big stuff then 1) bzr was not designed to do that 2) dvcs is not a good idea 3) it will work if you have the memory
<servertood> ok so if I have a huge lib dir say for java
<zyga> servertood: then again, perhaps, if you already switch to a multiple-repository model you can keep something for such stuff
<servertood> 100-200 MB of jars
<servertood> thats going to screw me
<zyga> servertood: do you have to version them?
<servertood> no because Im going to switch to maven
<zyga> and not a manifest that says which version you actually need?
<servertood> and pull them down during the build
<servertood> but I have to version the project as it is right now
<zyga> servertood: I'm not in java world but versioning binaries is not a good idea, version the source and build it
<servertood> these are dependencies
<servertood> like I said Im going to pull them in from a remote repo during the build
<servertood> but for now
<zyga> I don't put my dependencies in my tree
<servertood> I have to version what I have
<zyga> I know java world is different
<servertood> which is a bucket of junk
<zyga> servertood: what you have to version is the actual _version_ of a binary, not the actual file
<servertood> I suppose I could refactor before I import
<servertood> maybe that makes more sense in this case
<zyga> servertood: there is little difference to saying that I need to bundle glibc and other stuff with my C project
<zyga> servertood: except that for Java and SVN/p4 it works (jars will execute) and works for proprietary jars
<zyga> servertood: there are two topics here though: how to work with bzr and how to design the infrastructure around janva (which I don't know about much)
<servertood> i can get rid of the dependent binaries
<servertood> but over time Im going to have non devs version word docs and god knows what
<servertood> so if this is really just for source - Im not sure its what Im looking for
<servertood> although I have remote teams
<servertood> initially Ill be working in non distributed client server type setup
<zyga> servertood: if your development process produces .docs then thats another mindset incompatibility
<servertood> does that help the performance at all?
<zyga> servertood: we would produce source files that get built to documentatino that can be versioned/compared/merged
<servertood> we have specifications that need to be versioned
<servertood> they are not produced by development
<zyga> servertood: I cannot teach you your work as you know best what is needed
<zyga> servertood: I can only say this
<zyga> servertood: bzr will work great for what it's designed for
<zyga> servertood: code
<zyga> servertood: and text
<servertood> ok
<zyga> servertood: if you do the transition in a smart way your overall development model will get more complex but more powerful
<zyga> servertood: if you do it in a naive way (bzr add . && bzr ci -m "yay") then you will not get anything inherintly better than p4
<zyga> servertood: apart from the hefty price for p4, what was it 1K/year?
<zyga> (per seat)
<servertood> its pricey
<zyga> and it sucks badly
<zyga> it's just a versioned FTP site
<servertood> The teams I have been working on for years have no issues with it
<zyga> they even ship pftpd, that versions files on uploads
<servertood> But Im not an SCM expert
<Tak> yeah, some of the guys I work with /rave/ about perforce
<zyga> servertood: people that were always in a cage don't know how it feels outside
<servertood> WHat I will say abvout it is
<servertood> it never got in my way
<zyga> servertood: eseentially each tool will work but current generation of vcses gives lots of new options that are just awesome for developers
<servertood> Thats what Im looking for
<zyga> I always found it buggy, slow, and mostly not different better than CVS
<servertood> A tool that supports branching more intuitively so you can work with the tool and not be afraid of fucking up the project
<zyga> you could go back and edit history
<zyga> change commit messages
<zyga> nothing was atomic
<servertood> well Im not sure IM going to get to nirvana in this first pass
<zyga> the GUI was just one gigantic script that often hangs if you are talking over a slow link
<zyga> and the whole "multisite" mess is insane
<zyga> :-)
<servertood> I think Im going to go whole hog
<servertood> and dump everythig in it
<servertood> and then refactor
<zyga> servertood: if you're open sourcing then perhaps giving people a look at the code and the layout will yield more educated answers
<servertood> and see how the performance is
<zyga> servertood: that's not a good idea
<zyga> servertood: then everyone will have to get that first commit you made
<zyga> servertood: it's not a centralized repo, you pay for the history
<servertood> even after I refactor?
<zyga> servertood: certainly
<servertood> ok
<zyga> servertood: do it the other way around
<zyga> servertood: start adding stuff to bzr
<zyga> servertood: while refactoring
<zyga> servertood: and if your tools support that, break stuff up early at component boundaries
<servertood> does bzr support allowing only access to parts of the tree to a user
<zyga> no
<servertood> this is a high security project
<zyga> none dvcs does
<zyga> it's not possible
<zyga> if I can get anything (any revision)
<servertood> so I have to have seperate repos for different access levels
<zyga> yes
<servertood> ok
<zyga> if you can get the whole history and work offline you have to have it locally, by then no security can exist
<servertood> right
<servertood> so...if Im not do dist devel
<zyga> ?
<servertood> should I just use a centralized model
<servertood> and not use bzr
<zyga> ah
<zyga> not really
<zyga> it depends on how you define security today
<servertood> I remember the days of clearcase when they said whatever you do
<servertood> dont enable multisite
<servertood> I know that this is built in out of the box now
<zyga> I don't know how you work, do you have a team of people that can access something that other team or teams cannot?
<zyga> ah clearcase
<zyga> the tumor of version control
<servertood> old days
 * zyga shrugs
<servertood> Well I actually
<servertood> have to control access at the level of the developer
<zyga> servertood: no dvcs has "mutisite", I hope you understand that
<servertood> yes I do
<zyga> servertood: and at the repository level?
<zyga> servertood: developers is not what you can control in dvcs
<servertood> well right now
<servertood> they have code separated by env
<zyga> servertood: you can only control the _trees_
<servertood> so you either get access to dev or SIT or UAT or prod but thats pointless
<servertood> I need to be able to say
<servertood> hey a report developer
<servertood> cannot access code that does ACH transactions
<zyga> important question:
<zyga> why not?
<zyga> is it "because the code has secret sauce?"
<servertood> I dont want them to be able to change it
<zyga> or "because I don't want him to screw up"
<zyga> ah
<zyga> that's easy
<zyga> change your model
<zyga> have a gatekeeper
<zyga> that reviews
<servertood> because its a doorway to fraud
<zyga> have branches
<zyga> that get reviewed and merged
<zyga> nobody but the gatekeeper can commit
<servertood> sure I guess your right
<zyga> so
<servertood> its just a high security env so
<zyga> you don't care that Joe developer got a _branch_ of Foo
<zyga> and changed somethng that broke it
<servertood> Actually having more eyes on the code could potentially reduce fraud
<zyga> you just crare that he could not get his code in the "blessed" branch of Foo
<zyga> so
<servertood> sure
<zyga> if you can get every part of the code accessible to everyone (or just to each emploee)
<zyga> then you are safe
<zyga> bzr and other dvcses will work for you
<servertood> so they create a branch
<servertood> do their dev
<servertood> merge into some other branch
<zyga> I don't know how you work
<zyga> but again
<servertood> but can they merge into all branches?
<zyga> for dvcses a very common and effective model
<zyga> is to have a reviewer
<zyga> so I make a branch of my project trunk
<servertood> whats stops them from merging into production
<zyga> hack it
<zyga> and post a merge request
<zyga> you can put whatever security/access around a _tree_
<zyga> so you can say that physically only that user or that grup can perform alterations in that tree (at filesystem level)
<zyga> if you can opernsource your project
<zyga> then launchpad will provide you an infrastructure
<zyga> with code reviews
<zyga> security access
<zyga> and all the good stuff
<zyga> teams
<zyga> users
<servertood> in my case that is not legal
<zyga> and so on
<zyga> so you cannot opensource your code as you intially said?
<servertood> my code?
<servertood> no I want open source tool for SCM
<zyga> ah
<zyga> I see
<zyga> anyway
<zyga> you can deploy your own infrastructure then
<servertood> legally I cant do that
<zyga> of have someone who will do it for you
<servertood> sure Im building a new env
<zyga> servertood: btw, what is your business about?
<servertood> I really cant say
<servertood> So if I have a release branch
<zyga> servertood: so to go back to the topic: you can setup security, you can have a working workflow and it will be arguably better than a worflow where once you get commit access you can do anything
<servertood> your saying I cannot prevent someone from merging into it
<zyga> no
<zyga> that's not what I'm saying
<servertood> ok sry
<zyga> bzr does not care about who is doing changes
<zyga> neither does any other system
<zyga> you just setup system users or other filesystel-level protection
<servertood> ok thats cool
<zyga> so code to /srv/bzr/something/trunk can be (for example) only changed by that user or that group
<mkanat> zyga, servertood: There is no official policy that binaries are "not important enough to be optimized for". In fact, there are people doing work to make bzr handle them better.
<awilkins> You exert security control on who is allowed to merge changes upstream into release branches
<servertood> sure
<servertood> at the filesystem level ok
<zyga> mkanat: I remember reading about one of the bzr devs commenting that binaries are not a priority so they are not treated differently than text - that's what I meant - if that's changed then I can only be more happy
<awilkins> I think there are "bigfile" plugins for git and mercurial that are in some kind of usable state now
<mkanat> zyga: It hasn't changed, but there is work underway to change it.
<zyga> mkanat: cool
<zyga> mkanat: can I help in any way?
<awilkins> In my experience, files up to around 100MB are alright on modern machines
<servertood> is there a bug open on it?
<mkanat> zyga: Yeah, very possibly.
<servertood> how many files up to 100MB?
<servertood> say I have a dir of 200 MB worth of binaries like 10-20MB each
<awilkins> I have several branches that consist of around 1.5GB of text data resources in text files about 60MB or more apiece
<awilkins> And they check out OK on a machine with 2GB of RAM
<servertood> really
<zyga> servertood: you might hit the memory wall when bzr repacks the data
<mkanat> zyga: I think jbowtie is doing the work on it, you should ask him.
<awilkins> It can get a little ... swappy at that point :-)
<servertood> lol
<zyga> mkanat: thanks, I'll ping him
<zyga> AFAIR repacking crosses file boundary and just sucks the tree in
<awilkins> On my home desktop with 6GB of RAM and a 64-bit OS it's just fine though :-0)
<speakman> anyone running Buildbot on bzr repo?
<zyga> then your ISO will kill a 6GB machine
<servertood> so this slow down
<awilkins> We have been using Maven for storing large binary build outputs in
<awilkins> But it's not entirely well suited to that either - more to library sized JAR files
<servertood> sure
<servertood> Im switching to maven
<mkanat> servertood: It's more about the size of individual files than the size of your whole repo, with bzr.
<servertood> really
<mkanat> servertood: It won't deal well with a 1GB binary, but it should be fine with a 100MB binary.
<awilkins> Enough people (p4 using game developers mostly) raise the "big binaries" issue recently to make it worth looking at
<awilkins> If you are using Maven, top tip - use Nexus, not Archiva.
<servertood> Im sure I dont have any files near 100MB
<awilkins> Nexus totally blows Archiva out of the water in terms of upload performance
<zyga> mkanat: it's been my experience that repacking _will_ kill your system at that poing (having any number of 100MB files)
<servertood> Im using Maven to build java
<Tak> yeah, we have big binary issues as well
<awilkins> What I'd like to see is a system that stores big non-mergy binaries on their SHA1 sum in a glorified FTP server
<Tak> YES
<awilkins> And you just refer to each binary you want in your build system by it's SHA1
<zyga> awilkins: that's not going to help you without pure shallow checkouts - assuming you still want dvcs
<awilkins> I mean, in the case of game dev, who goes with their old assets anyway?
<zyga> awilkins: I've been considering transitioning part of a very large p4 repo to anything else
<awilkins> You might want to build old CODE to find a bug, but who wants to go back to old ART?
<zyga> awilkins: and that's what it ultilmately boils down to, you cannot even copy the whole history to a single computer
<lousygarua> is there a way to download only a certain revision from a repository so i won't have to download the whole history of the project?
<zyga> lousygarua: in bzr? yes
<awilkins> lousygarua, Yes, you can do a shallow checkout
<zyga> lousygarua: you can setup lighweight checkout for example
<awilkins> ^^ or what he said
<zyga> awilkins: lightweigh is the same as shallow?
<zyga> I remember talks about doing history horizon but I don't know if that was implemented
<lousygarua> zyga: hmm, ok i will read about shallow/lightweight/whatever thanks
<zyga> so that you could see (and have) some history locally
<zyga> lousygarua: bzr reconfigure --help
<awilkins> Lightweight is like SVN - depends on the server
<zyga> awilkins: yes
<awilkins> TBH never really used shallow checkouts but I think they get used on Launchpad to save storage for user forks
<zyga> awilkins: and if bzr could just store binaries without processing (and holding them in memory) then bzr would be a perfect VCS for anyone apart from git hardcore users and people loving to rebase (I still do, darn)
<lousygarua> will a lightweight checkout store further revisions locally so it won't have to be SVN entirely?
<awilkins> lousygarua, No
<zyga> awilkins: lp uses stacked branches right? so you get same kind of data saving
<awilkins> stacked ... I think that's sort of what I may have meant
<zyga> awilkins: stacked is where you just have your history and go to the partent for the rest
<zyga> awilkins: lightweight is just a working directory accessing a remote branch
<zyga> awilkins: also lanchpad has repositories around projects to make identical revisions collapse
<awilkins> As I say... I don't use them myself ; I mostly use bzr-svn and straight bzr with a hidden folder shared repo and lightwieght checkouts of the branches therein
<speakman> How can I debug a plugin? How do I even check if it's run?
<zyga> but I'm not sure if that's exactly how lp.net handles code, ask in #launchpad for that
<zyga> speakman: print something in the module, worked for me :-)
<zyga> speakman: also bzr plugins -v will tell you it's there
<zyga> speakman: I had issues with putting something that cannot be imported by python (wrong name) as the plugin toplevel directory name
<speakman> zyga: ever run buildbot with bzr?
<zyga> speakman: no, sorry
<zyga> servertood: if you need some non lp.net hosting then you can either use track or redmine, both are quite excellent
<zyga> sorry trac
<Tak> if bzr had good binary handling, it would have been the hands-down winner for new vcs at my workplace
<zyga> Tak: I had the same problem
<speakman> zyga: seems like there's something wrong with locations.conf
<zyga> speakman: ?
<maxb> < zyga> awilkins: also lanchpad has repositories around projects to make identical revisions collapse
<maxb> No, it doesn't
<zyga> maxb: oh, how does it work then?
<maxb> stacked branches
<zyga> maxb: so branches are always stacked on their parents?
<speakman> zyga: my mistake - was prefixing config settings with a tab in locations.conf
<speakman> okay, this plugin installs on post_commit post_push and post_change_branch_tip
<speakman> I want it to trigger on a smartserver when new commits are pushed
<zyga> speakman: I'm not sure how that part works or how to debug that, I cannot help you much, sorry
<speakman> ok
<speakman> anyone else..?
<speakman> (the bzr --serve --inet is run as user 'bzr' and I'm editing in ~bzr/.bazaar/* )
<speakman> the option "recurse" seems to not be working for all plugins
<speakman> no, it's all working correctly
<speakman> now, which hooks are trigger by bzr --serve ?
<speakman> http://doc.bazaar.canonical.com/latest/en/user-reference/hooks-help.html#post-change-branch-tip
<speakman> "Called in bzr client and server after a change to the tip of a branch is made. post_change_branch_tip is called with a bzrlib.branch.ChangeBranchTipParams. Note that push, pull, commit, uncommit will all trigger this hook."
<speakman> doesn't seem so...
<speakman> BzrBranch7(filtered-172359628:///timespot/facelift-pure/)
<speakman> how is this suppose to match in locations.conf ?
<speakman> Seems like the smart server need a local path resolution fix
<speakman> BzrBranch7(filtered-172359628:///timespot/facelift-pure/)   --->    BzrBranch7(file:///srv/bzr/repo/timespot/facelift-pure/)
<servertood> hi
<servertood> I just setup a repo on my osx machine with notrees
<servertood> I want to create a working copy and add files to it do I have to access the repo with sftp even tho its local
<servertood> oh no I htink it worked at first when I referenced it on the filesystem it looked like it screwed up
#bzr 2010-12-29
<speakman> how do I get the path on the file system for a BzrBranch7 object?
<servertood> Hi I created a shared repo with -notrees
<servertood> is this a good idea when I use bzr explorer I see no files - does this mean I will never be able to browse the repo only working copies on the repo?
<speakman> branch.base did it...
<speakman> servertood: you can checkout a working tree with "bzr checkout"
<servertood> yeah I did that
<servertood> but in the gui bzr explorer when I select the repo
<servertood> I see no files I assume because I created it with notrees
<servertood> ok Im in explorer now and I commited files
<servertood> I guess I was expecting to see them in the main view
<servertood> I know see them in the pane to the bottom right under working tree
<servertood> if I bzr added a large number of files
<servertood> and realized I didnt ignore a certain file type
<servertood> is there a way to unadd them
<speakman> bzr rm --keep iirc
 * speakman still don't know how to get the file system absolut path of a repository from within bzr smart server
<speakman> lifeless: ping
<lifeless> hi
<lifeless> whats up?
<servertood> does bazaar come with an http repo browser?
<servertood> I havent run bzr server yet wasnt sure if that does it
<maxb> servertood: It's called loggerhead
<servertood> k
<servertood> ty
<servertood> Im not a python dude
<servertood> loggerhead plugin blows up saying paste.exception pkg is not there
<servertood> having no luck getting it installed any ideas
<servertood> easy_install wont install either saying its looking for python2.3
<servertood> I have python 3
<servertood> Im on osx
<speakman> lifeless: how do one get the file system path of a repo in a commit hook routine when bzr is running as a smart server?
<speakman> lifeless: the URL of the repo is somewhat obfuscated; filtered-172359628:///timespot/facelift-pure/
<speakman> lifeless: when committing directly to that repo, the URL is file:///srv/bzr/repo/timespot/facelift-pure/
<speakman> lifeless: the smart server is run as; 4155			stream	tcp	nowait	bzr	/usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/repo --allow-writes
<speakman> lifeless: I'm using it to send change notifications to Buildbot fwiw
<lifeless> speakman: you can unwrap that in python
<lifeless> have a look at the code
<lifeless> its a pseudo chroot to prevent config files or the VFS etc being used to attack the host file system
<speakman> lifeless: ok, I did give it a try but I couldn't figure where to do the unwrapping
<speakman> now getting some sleep, then I might give it another try
<speakman> g'nite
<jonnydee> hi, is there gui support for committing only part of the changes within a file? (Like it is possible with TortoiseHG / Mercurial)
<jonnydee> I am considering to switch from Mercurial to Bazaar
<jonnydee> Sorry, my notebook went into suspend mode. Did someone answer my question?
<lifeless> hi jonnydee
<lifeless> uhm
<lifeless> committing only some changes - no ui support for doing that in one operation
<lifeless> (AFAIK), but we'd like it
<lifeless> you can do it by hand using the 'shelve' functionality, which i think *is* exposed in the GUIs
<jonnydee> lifeliss, thanks for your response. so with shelve I would select the hunnks that shouldn't be committed, shelve them away, and then commit?
<jonnydee> s/lifeliss/lifeless
<speakman> lifeless: please have a look at (and maybe update) https://bugs.launchpad.net/bzr/+bug/270267
<speakman> $ bzr mv --after src/ts35_spec/window_ctrls.c src/window_ctrls.c
<speakman> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', 'ts35_spec-20080306092141-c3d3hfzalp83ngpc-1'
<speakman> reason: Parent not in inventory.
<speakman> And this is no SVN import or anything - pure bzr from the beginning
<speakman> how do I make bzr detect file moves?
<Tak_> did you try bzr mv --auto ?
<LeoNerd> You perform the move by   bzr mv old new
<LeoNerd> Or if you've already done that, try   bzr mv-id ...
<speakman> mv-iD?
<speakman> mv auto?
<Tak_>   --auto         Automatically guess renames.
<speakman> Tak_: didn't work
<LeoNerd> So mv-id it
<speakman> removed: src/ts35_spec/barcode.c
<speakman> unknown: src/barcode.c
<speakman> $ bzr mv-id
<speakman> bzr: ERROR: unknown command "mv-id"
<LeoNerd> Ohwait, just mv ;)
<LeoNerd> bzr mv  old new
<LeoNerd> and next time, just use that to rename the file in the first place
<speakman> $ bzr mv src/ts35_spec/barcode.c src/
<speakman> bzr: ERROR: Could not move barcode.c => src: src/ts35_spec/barcode.c is not versioned.
<speakman> LeoNerd: I use to. But this time I forgot.
 * LeoNerd nod..
<speakman> LeoNerd: Moving all files back to the originating place doesn't work either
<LeoNerd> bzr mv old new     as I said
<speakman> $ bzr mv --after src/ts35_spec/barcode.c src/
<speakman> bzr: ERROR: Could not move barcode.c => src: src/ts35_spec/barcode.c is not versioned.
<LeoNerd> Since old doesn't exist and new is unversioned, bzr will work out what happened
<LeoNerd> Give the full paths
<speakman> $ bzr mv --after src/ts35_spec/barcode.c src/barcode.c
<speakman> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', 'ts35_spec-20080306092141-c3d3hfzalp83ngpc-1'
<speakman> reason: Parent not in inventory.
<LeoNerd> bzr add src/
<speakman> $ bzr add src/
<speakman> adding src/barcode.c
<LeoNerd> bzr rm --keep src/barcode.c
<LeoNerd> Then you can 'mv' it OK
<speakman> $ bzr status
<speakman> removed: src/ts35_spec/barcode.c
<speakman> added: src/barcode.c
<speakman> $ bzr mv src/ts35_spec/barcode.c src/barcode.c
<speakman> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', 'ts35_spec-20080306092141-c3d3hfzalp83ngpc-1'
<speakman> reason: Parent not in inventory.
<LeoNerd> I'd be suspiscious of that "inconsistent delta" error...
<speakman> really...
<speakman> are there any patch-reader tools outthere?
<speakman> Trying to solve this by making a .patch-file to be applied into a new branched tree. But the files is gigantic and I'd like to get an overview of it.
<speakman> Something like gdiff for arbitrary patch file
<awilkins> Which OS?
<speakman> ubuntu 10.10
<speakman> bzr ver 2.2.1
<awilkins> Not sure.... you could just apply the patch and view it with gdiff?
<awilkins> Or you could shelve it in the tree you've got and unshelve it in the other tree?
<speakman> how do I move shelves?
<LeoNerd> Move it where..?
<LeoNerd> If you want to move the entire shelf with all its items, into a different workdir; I believe it's just a directory, so you can just 'mv' it
<speakman> move from branch to branch
<awilkins> Or you could render your current branch a checkout instead of a branch and switch it - but from the sound of it it might be too broken to allow that
<glyph> hey, did any of you guys catch the recent python-dev thread about maintenance branch workflow?
<theadib> hello, in order to check in which version a bug introduced I want to go from revision x (still working) to revision y (known not to work) step by step.
<theadib> what is the easiest way to do this. Currently I have a a checkout and branch from a launchpad project
<beuno> theadib, you can "bzr revert -r x"
<awilkins> theadib, `bzr bisect`
<awilkins> theadib, You might need to install the plugin ; if your "bad" property is testable in an automatic way you can even script it to locate the "bad" commit
<theadib> beuno, does this revert all changes until revision x?
<hsn> what is lp url for pushing branch into project which is not mine
<beuno> theadib, yes
<beuno> hsn, bzr push lp:~youruser/project_name/branch_name
<theadib> beuno, and what to do to go then to revision x +1?
<beuno> theadib, so, if X is tip
<beuno> you can do
<beuno> bzr revert -r -2
<beuno> then, bzr revert -r -3
<beuno> and so on
<beuno> that will step back one revision
<theadib> ok, thanks. How do I know which revision I am in? bzr info does not tell this information.
<beuno> theadib, right, you know because you specified it in the command  :)
<beuno> so you can either use -2, -3, -4
<beuno> or just substract one yourself
<applesoranges> hey
#bzr 2010-12-30
<cdbs> is bzr broken in Natty?
<cdbs> okay, got the bug
<lifeless> https is
<cdbs> lifeless: so is there a workaround?
<cdbs> I tried to branch using the bzr:// protocol
<lifeless> cdbs: I'm not sure; perhaps running with python2.6 ?
<lifeless> e..g python2.6 `which bzr` branch bzr://....
<thumper> lifeless: ping
<lifeless> hi?
<thumper> how do I create a transport from an existing transport?
<thumper> I want a directory under the existing transport
<thumper> (which is a shared repo)
<thumper> so I have repo.user_transport
<thumper> and I want a directory under that to create a branch in
<lifeless> t.clone(relpath)
<thumper> ta
<xanalogica> I'm looking for a way to move a working tree to a specific revision but cannot find it;   basically I want:    wt.update(revision_id=27)
<xanalogica> hmm, it looks like it might be clone(wt_rootpath, revision_id='........'), where you basically clone a specific rev *on top of yourself*.  Interesting.
<lifeless> if you want a specific rev
<lifeless> revert() is generally a sufficient answer
<xanalogica> I don't see that wt.revert() accepts a rev id or version though?
<lifeless> xanalogica: wt.revert(old_tree=wt.branch.repository.revision_tree(...))
<xanalogica> lifeless, thanks I have a working solution now, using revert().
<knighthawk> I'm trying to do a checkout of a branch from a central repo into a new branch on my local drive. when I type 'bzr checkout sftp://path/to/repos' I get error Not a branch. I'm guessing that has something to do with my local setup. but I'm not sure what.
<maxb> knighthawk: If you really are giving a path to a repository, then a repository is not a branch
<maxb> Try 'bzr info URL'
<knighthawk> its hanging
<knighthawk> bzr: ERROR: No repository present:
<knighthawk> that's when I point it at the branch. when I point it at the repos it hangs.
<maxb> hrm
<maxb> Could you give the URLs (un-obfuscated) of the branch and repo, so I have a better idea what's going on here?
<maxb> Also, running 'find -ls' in the repository and pastebinning the result would be helpful to understand what you have
<knighthawk> the branch is called grws its in a repos call bzr-repos sftp://repos.grdev.com/opt/bzr-repos/grws
<maxb> OK, can I see 'find /opt/bzr-repos/.bzr -ls' and 'find /opt/bzr-repos/grws/.bzr -ls' ?
<knighthawk> just a sec.
<knighthawk> http://fpaste.org/w5To/
<maxb> erm. That doesn't look so good. It's just an empty bzrdir, there's no repository there.
<knighthawk> http://fpaste.org/cjzg/
<maxb> That's a branch+tree alright, but it would seem that the repository that is supposed to be present at /opt/bzr-repos/ is missing
<knighthawk>  history | grep 'bzr init-repo'
<knighthawk>    21  bzr init-repo bzr-repos
<maxb> OK..... so it was there once, but is very much not there any more
<maxb> There should be an /opt/bzr-repos/.bzr/repository/ but there is not
<knighthawk> okay so is there a way for me to make /opt/bzr-repos a repo again without blowing away the branches inside of it?
<maxb> If the repository that was containing the data for the branches is lost, the branches are mostly useless now
<knighthawk> lovely.
<knighthawk> so I have a branch on my local machine.  will that help me restore anything?
<maxb> cd /opt/bzr-repos
<maxb> mv .bzr broken.bzr
<maxb> bzr init-repo .
<AfC> and then re-pull the content into those branches
<maxb> Then, locally, 'bzr push url://to/opt/bzr-repos/some-name-for-branch'
<maxb> The branches are primarily a pointer to the tip revision, plus a dictionary of tags
<maxb> If, by means of other push/pull operations, you cause the relevant revisions to be present in the recreated repository, the old branches will work again
<knighthawk> thanks guys I *never* would have figured that out.
#bzr 2010-12-31
<shakaran> Hi, How I can change the default python interpreter for bazaar? some .conf file?
<bob2> the shebang
<shakaran> bob2: thanks! works like a charm!
<chx> i am wondering whether there is any way to automatically commit? like, one save in the tree, one commit. inotify, i guess
<chx> ah inotify-cron, thanks :)
<LeoNerd> You don't really want automatic commit. The point of revision-based VCSes, is that you make a commit with a sensible message containing all the relevant changes, in one go
<idlecool> i have a local branch of a Open Source project on which i have made some changes, committed and pushed to lp: on my private branch.
<idlecool> what should i do to revert changes to match with the parent branch. (undo the changes which i have made.)
<idlecool> i had a bad practice to do bzr uncommit, bzr revert but i think there should be a more elegant way.
#bzr 2011-01-01
<BjornW> can somebody tell me the bzr equivalent of svn:externals?
<jelmer> hi BjornW
<jelmer> BjornW: nested trees would be the equivalent of svn:externals in bzr itself, but we're still working on it.
<jelmer> In the mean time, there are a couple of plugins that provide similar functionality
<jelmer> bzr-externals is probably the easiest one to use at the moment.
<BjornW> Thanks Jelmer. Installed bzr-externals plugin and going to test it tomorrow.
#bzr 2011-01-02
<jelmer> my latest project: https://launchpad.net/apache-bzr
<maxb> jelmer: intriguing... but what does it do that mod_wsgi cannot?
<jelmer> maxb: it's just one switch in a configuration file
<jelmer> IOW, it's easier to setup and the goal is to e.g. make it trivial to enable Wikkid/Loggerhead/Git for a bzr branch this way as well
<jelmer> it also doesn't require configuration per bzr dir, it allows you to just enable the smart server for /all/ bzr branches under e.g. a <Directory>
<bill__> Anybody here?  I have somehow broken my repository with a bad commit syntax
<Kamping_Kaiser> does bzr have no copy/cp function?
<Kamping_Kaiser> i can't seem to find one in help
<bob2> there's a spec on lp iirc
<bob2> er blueprint
<Kamping_Kaiser> mm, that makes me sad. ah well. thanks for the info
<bob2> https://bugs.launchpad.net/bzr/+bug/269095
<Kamping_Kaiser> thanks, i'll subscribe to it
 * maxb blinks, and wonders if it's actually possible that unshelve is completely broken in bzr.dev
<maxb> hmm, no. Same crash with 2.1 and 2.2
<LeoNerd> Is there a way to build a long report of changes; with full diff and commit message per revision...?
<LeoNerd> I was hoping that  bzr send   or  bzr bundle   would do it, but I can't see it
<luks> bzr log -p ?
<LeoNerd> Oh.. hehe..
<LeoNerd> OK that does it, thanks
<LeoNerd> It only has to be human-readable, not machine parsed so that'll do fine
#bzr 2011-12-26
<evanton> I am following this http://librelist.com/browser//cville/2010/2/9/migrate-repository-bzr-to-git/ and bzr fast-export failed with unknown command error, is there a problem with my bzr install?
<evanton> hmm, googling shows this is a bzr plugin, I probably shall investigate that deeper
<AuroraBorealis> what does this "bzr: error: paramiki.sshexception: lost ssh-agent" error mean :<
 * jelmer waves
#bzr 2011-12-27
<nixmaniack> hi, I'm getting permission denied while cloning one of the LP project
<lifeless> wgrant: around ?
<lifeless> bah
<mathrick> howdy
<jelmer> hey mathrick
<mathrick> will I be very sad down the road if I init my new tree with development-colo?
<mathrick> hey jelmer, did you have a nice christmas?
<mathrick> oh well!
 * mathrick adopts the init now, regret later approach
<jelmer> mathrick: sorry, lots of things going on here
<jelmer> mathrick: still there?
<mathrick> yep
<mathrick> jelmer: don't worry, there's not a lot of things in the tree yet, I can afford risking it for now
<jelmer> mathrick: it won't really eat your data, but the colo stuff in general isn't very polished yet
<mathrick> aye
<mathrick> how exportable is it in case a showstopper bug happens?
<jelmer> mathrick: very
<mathrick> ah cool, in this case I'm happy to help testing
<jelmer> bug reports are very welcome - please tag them with "colocated"
<jelmer> https://bugs.launchpad.net/bzr/+bugs?field.tag=colocated
<mathrick> will do
<mathrick> jelmer: is there an easy intro somewhere to outline colocated trees vs. bzr colo?
<jelmer> mathrick: not that I'm aware of
<jelmer> mathrick: there has been some effort to make bzr-colo with development-colo though afaik
<mathrick> ah, that'd be cool
<elmo> so, if I have foo/bar and baz/ (no files), if I ignore foo/** and baz/**, I see 'baz' in the 'unknown' output, and if I ignore 'foo' and 'baz', I see foo/bar in the 'unknown' output
<elmo> is there some variant that will ignore folders *and* their files?
<elmo> (I tried 'foo/' and 'baz/' too - no jazz)
<elmo> or do I really just have to ignore 'foo/', 'foo/**', 'baz/' and 'baz/**' ?
<mathrick> elmo: why'd you expect foo/** to have any effect on baz/ ?
<mathrick> I'm not sure I follow what you tried to achieve there
<elmo> mathrick: I'm looking for the best way to ignore a folder and any sub-folders/files
<elmo> mathrick: right now, it looks like I have to ignore both 'folder' and 'folder/**'
<elmo> mathrick: if that's the case, that's fine, I just wanted to make sure I wasn't being dense
<elmo> mathrick: sorry, my original explanation sucked
<mathrick> ah, ok
<mathrick> elmo: that might be the case, I don't know the exact details of ignoring; was just making sure you're not trying to do something that shouldn't work and confusing yourself :)
<lifeless> elmo: you can use a regex
<elmo> lifeless: e.g. "RE:^foo/.*" ?
<lifeless> bzr ignore 'RE:foo($|/.*)$'
<lifeless> erm, probably with the ^ too
<elmo> ok
<lifeless> elmo: however, ignored folders are not recursed into
<lifeless> elmo: unless they are already versioned, so most folk don't run into wanting/needing this
<elmo> lifeless: hmm, that's not what I'm seeing
<elmo> oh, yes it is, lala
<elmo> hmm
<lifeless> using your foo/bar + baz/ example, I would expect bzr ignore foo/ + bzr ignore ./baz
<lifeless> to do what you want
<lifeless> assuming foo is versioned, and baz isn't.
<elmo> lifeless: http://paste.ubuntu.com/785006/
<lifeless> elmo: will you be in budapest?
<elmo> lifeless: yes
<lifeless> cool
<lifeless> elmo: bzr ls -V -R -v lvm/archive
<lifeless> (versioned, recurse, verbose)
<elmo> ah
<elmo> so there are versioned files
<elmo> in that dir
<elmo> and that's enough to trigger a recurse
<lifeless> that implies the dir is versioned
<lifeless> the dir isn't in st, because it hasn't changed.
<elmo> ok, so I guess the .bzrignore came along after this was committed
<elmo> so if I bzr rm --keep lvm/archive, I guess I should be good
<lifeless> or before - bzr add <path> overrides ignores
<lifeless> if someone did bzr add lvm/archive/foo
<lifeless> bzr will do it.
<elmo> ok
<elmo> cool, thanks - I understand now
<lifeless> a plugin could be written to enforce 'if it is ignored it must not be versioned'
<lifeless> if that would be helpful to you
<elmo> no, it's fine - I don't mind them being versioned, and now I have a work around for the few cases where this pops up
<lifeless> cool
#bzr 2011-12-28
<jelmer> lifeless: so, I've been pondering doing a unity lens that uses bzr-search
<jelmer> lifeless: a problem with that appears to be that currently all indexes are scattered across different branches; have you considered a global cache, or perhaps meta cache?
<lifeless> jelmer: hiya
<jelmer> lifeless: hi
<lifeless> jelmer: needs a fast reachability oracle
<lifeless> the basic form of a search is: load the metadata for all specified terms; choose the most selective (least occurences), do a bitmap AND of -all- the hits in that index with the next least selective, rinse and repeat
<lifeless> so there are two issues with indices that cover more than the corpus for which hits are relevant
<lifeless> firstly, a term that is very rare in the chosen branch may be common in another, making the search slower than it would be with the current approach
<lifeless> secondly, we need to start filtering the index contents for revisions in the branch
<lifeless> one way to do this, is to index all the revisions as terms of the branch (url) or branch (tip) or ...
<lifeless> then have an implicit term added to all searches of the branch (url or tip or whatnot)
<lifeless> there is of course a different but also interesting search 'what branches match this search'
<jelmer> lifeless: ah, I see
<jelmer> lifeless: thanks
<lifeless> OR searches obviously need a more complex planner, I haven't written support for them yet
<lifeless> I'd be delighted to discuss approaches if you want to hack in this area
<lifeless> its pretty fun stuff
<jelmer> I would be interested in hacking on and discussing this stuff some more some time
<jelmer> about to fall asleep though, so perhaps some other time
<lifeless> cool
<lifeless> sleep well!
<jelmer> thanks for the explanation so far
<jelmer> thanks :) have a good day
<lifeless> I shall ... well evening :)
<lifeless> I have laptop, warm weather, beer.
<Movix> hello evereybody
<Movix> i'm new to bazaar and did not found any way to do what i'm looking for.
<Movix> I searched forums, tutorials and the online help and tried a lot the last days, but no chance.
<Movix> so i wonder if this could be the right place to ask some questions or if it's better to post on a forum.
<Movix> btw: i'am also new to VCS
<LpSolit> I have a question about Loggerhead: I would like it to list all changes between two revid (~700 changes), but it always displays 20 changes at once only. How can we force it to display the exact list I want?
<jelmer> LpSolit: I'm not sure if that is yet possible at the moment
<LpSolit> oh, ok :(
<jelmer> LpSolit: it shouldn't be too hard to patch it to do so though
<LpSolit> I wanted to generate a list with all changes made between two consecutive releases of our product
#bzr 2011-12-29
<Merwin_> Hi, do you know how I can bzr update update but only 1 commit ?
<Merwin_> I don't want to take all the new commits, juste one
<bob2> perhaps you want to cherrypick instead then
<Peng> If you only want the *first* revision, update takes an -r argument.
<Peng> First *new* revision, that is.
 * jelmer waves
<Movix> hello, i'm still unable to find the right folder and bazzar structure to handle my workspace. Is anybody here able to give 5 minutes please ?
<AuroraBorealis> sure
<Movix> ok, i make a short descrption of it
<Movix> i have a website cms that has modules. A module can have file in multpiple folder in the root of the cms, f.ex. /modules/modulesname, /themes/templates/modulesname, where the cms itself also has folders in these. A customer website now owns all files from the CMS plus the modules i need. how do i make things that i can make changes to a module that i can update within a customer site without having to branch the module developement from the core CMS branch ?
<Movix> sorry my english is bad, hope the question is clear
<Movix> i'm reading tutorials and other blogs to understand, tested a lot the past days but still no way to get what i'm expting
<AuroraBorealis> uhh
<AuroraBorealis> not sure what you are asking :<
<Movix> hmmm
<AuroraBorealis> why not just have one branch for...everything?
<Movix> because a nay point i'd like to have a folder with only the files related to a specific module
<Movix> at any point
<AuroraBorealis> i mean a branch can have multiple folders under it...
<Movix> You mean to have a root folder witch /cmscore and /mymodule ?
<AuroraBorealis> you can do whatever you want honestly
<AuroraBorealis> bazaar tracks folders
<Movix> assuming this, i'll have /cmscore/modules/, cmscore/themes on one hand, and /mymodule/modules/mymodule, /myodule/themes/templates/mymodule on the other.
<Movix> Now i'd like to release this to the server, both subfolders (cmscore/* and mymodule/*) have to be murged, and this is the point i stuck
<AuroraBorealis> i mean, if they are both in the same branch, it will merge them fine
<AuroraBorealis> i think you are talking about using different branches for stuff when you only need one
<Movix> hmmm
<AuroraBorealis> just have one branch
<AuroraBorealis> everything under it
<AuroraBorealis> and then merge it on the server when you update it
<Movix> so suppose i have multiple module in my branch, how do i make a correct revisionning of each of the modules ?
<AuroraBorealis> bazaar does that for you
<AuroraBorealis> it knows what revision each file is at :>
<Movix> ok, at this point i'll have to test again, thank you for your time.
<Movix> in other words i madethings more complex they need to be ?
<AuroraBorealis> i think so =P
<Movix> to track the various release can i also make local merges for a given release ?
<AuroraBorealis> you can use tags to help track stuff
<AuroraBorealis> but yeah you can do local merges and stuff
<AuroraBorealis> bzr is flexible
<Movix> me again, the way AuroraBorealis suggested me to go did not solve my problem. here (http://pastebin.com/Zc0mwP4E) a better (graphical) description of it, anyone can give me a hint ?
<LeoNerd> bzr: ERROR: ":branch" is not a valid location alias.
<LeoNerd> ^-- any way I can obtain a list of what -is- valid? I'm just about ready to give up guessing blindly
<LeoNerd> Ahhh.. :bound
<LeoNerd> also,  bzr help location-alias   answers my immediate question, FTR
<Movix> no chance to solve my problem http://pastebin.com/Zc0mwP4E, still nobody to put me on the right way ?
<Movix> grrr, i'll give up soon, wether my noobish approach (yes i'm new to VCS) or the functionnality itself does not allow tha task i want to. netherless i'm sure what i want is not so extraordinary
<Movix> it's not because i did not tried, i spent the last days with reading the net, testing, but no way
<jelmer> LeoNerd: yep, location-alias is indeed the right place
<mgz> squib squab squob
<jelmer> mgz!
 * jelmer is implementing nested trees
<jelmer> mgz: how was your christmas?
<fullermd> Well, apparently he had a pigeon with a little firecracker in it...
<mgz> jelmer sounds like he was inspired by staring at a decorated fur for days
 * mgz has had a nice few days of doing not much, apart from looking after sis's baby a bit
<jelmer> mgz: Ah, good
#bzr 2011-12-30
<cheater_> hi
<cheater_> i have a slight issue understanding something. i understand there can be two types of repositories that i have on my hard drive, one is a repository from which i can create new checkouts (and could act as a central repo) and another one needs the original repository to work. is that correct?
<AuroraBorealis> you are probably thinking about branches vs lightweight checkouts?
<cheater_> possibly
<AuroraBorealis> a branch has the entire history
<cheater_> how do i create either of them?
<AuroraBorealis> a lightweight  checkout doesn't have history
<cheater_> as in, the commands
<AuroraBorealis> or it could be a checkout of a repository, which means that it needs to access the repo to pretty much do anything
<cheater_> ah yes, i am probably thinking branch vs checkout
<cheater_> is there a reliable way to tell those two apart?
<AuroraBorealis> http://doc.bazaar.canonical.com/latest/en/user-reference/init-repository-help.html
<cheater_> let me look at that very quickly
<AuroraBorealis> http://doc.bazaar.canonical.com/latest/en/user-reference/checkouts-help.html
<AuroraBorealis> the difference between branches and a heavy checkout is the 'location' to where it commits
<AuroraBorealis> as in if its bound or not
<AuroraBorealis> not sure how to tell a branch from a checkout
<cheater_> would this not register in the branches registered somewhere in bzr metadata?
<AuroraBorealis> im sure it is
<AuroraBorealis> not sure if there is any nice command to tell
<cheater_> see i have four source trees here
<cheater_> i did a heavyweight branch just before the central server got hit by a meteorite
<AuroraBorealis> o.o
<cheater_> it's one of them and i need to figure out which
<AuroraBorealis> well
<cheater_> also, one of these trees which is what i have been working out of is a lightweight checkout
<AuroraBorealis> if its a lightweight checkout
<AuroraBorealis> then it WONT have history
<AuroraBorealis> the other 3 options it should still have history.
<cheater_> yeah
<AuroraBorealis> and it should not matter which one it is
<cheater_> if i go there and do cat .bzr/branch/branch.conf then it shows me bound = True and bound_location = sftp://whatever
<cheater_> that is evident of it being a lightweight checkout right?
<AuroraBorealis> not necessarilly
<AuroraBorealis> A checkout is created with the bzr checkout command (see âhelp checkoutâ). You pass it a reference to another branch, and it will create a local copy for you that still contains a reference to the branch you created the checkout from (the master branch). Then if you make any commits they will be made on the other branch first. This creates an instant mirror of your work, or facilitates lockstep development, where eac
<AuroraBorealis> h developer is working together, continuously integrating the changes of others.
<AuroraBorealis> However the checkout is still a first class branch in Bazaar terms, so that you have the full history locally
<AuroraBorealis> just means that when you commit, its gonna commit to the remote place first
<AuroraBorealis> and then commit locally
<AuroraBorealis> basically mimics svn in a way
<cheater_> so how can i tell if a checkout is lightweight?
<AuroraBorealis> try doing bzr log on it
<AuroraBorealis> i guess
<cheater_> where is the difference in meta data?
<AuroraBorealis> i am not that exierenced in bzr's internals so im not sure
<cheater_> what should it do? bzr log
<AuroraBorealis> well
<AuroraBorealis> bzr log wont work if its lightweight
<AuroraBorealis> cause it has no history
<AuroraBorealis> one sec let me try a lightweight checkout
<cheater_> thanks
<cheater_> i currently do not have any working bzr infrastructure so can't check myself
<jelmer> hi AuroraBorealis, cheater_
<cheater_> hi jelmer
<AuroraBorealis> it seems a lightweight checkout
<AuroraBorealis> just doesnt have a .bzr/repository folder
<cheater_> heh
<cheater_> all the source trees have that
<cheater_> funny!
<jelmer> AuroraBorealis: right, the point of a lightweight checkout is that is uses a branch/repository that is located elsehwere
<AuroraBorealis> yeah
<AuroraBorealis> he just lost his remote repository
<AuroraBorealis> but since none of his source trees are lightweight, they should still have all the history
<AuroraBorealis> up to the point from when they were last updated / merged / whatever
<jelmer> cheater_: what's the problem you're trying to solve exactly?
<cheater_> yeah there is actually no discrepancy in what commits they contain
<cheater_> as in all the source trees are up to date
<AuroraBorealis> <cheater_> i did a heavyweight branch just before the central server got hit by a meteorite
<AuroraBorealis> thats his problem
<AuroraBorealis> :>
<cheater_> jelmer: i have been working on a single-person project with just one main branch, using a "centralized" workflow with a bzr repo being available via sftp off a server, and a local checkout on my home computer
<cheater_> the server doesn't exist anymore
<cheater_> i want to resume my work
<jelmer> cheater_: you should be able to unbind your local branch, if it was a heavyweight checkout
<cheater_> just before the server went away i came in here anticipating it, and you guys told me to do some specific kind of checkout or branch
<cheater_> i guess you told me to do a branch
<cheater_> so i did
<cheater_> ok how do i do that jelmer?
<AuroraBorealis> bzr unbind probably
<cheater_> let me try that then
<jelmer> cheater_: if it's a heavyweight checkout, then "bzr unbind" should work
<cheater_> let me just make a copy of that dir
<cheater_> nice
<cheater_> i just added a file and committed
<cheater_> Committed revision 42.
<cheater_> funny thing given that i started reading the hitchhiker trilogy lately..
<cheater_> ok, great!
<AuroraBorealis> =P
<cheater_> and branching works too
<cheater_> amazing
<cheater_> thanks a lot guys
<AuroraBorealis> :D
<cheater_> there might still be some life left in this project
<AuroraBorealis> back it up again though :>
<cheater_> yeah it's backed up
<cheater_> raid is backup, right?
<sjamaan> Hi. I'm trying to find the bzr library API.  The link in the manual points to http://starship.python.net/crew/mwh/bzrlibapi/ but that's empty
<sjamaan> Anywhere else I can look?
<AuroraBorealis> well i meant on another server =P
<cheater_> AuroraBorealis: heheh, i was just kidding.
<gutworth> is there some option I can pass to disable the progress bar?
<beuno> gutworth, I think -q may do it
<gutworth> mm, too bad it's not global
<bob2> isn't there an env var?
<gutworth> BZR_PROGRESS_BAR beautiful
<Noldorin> hey wgz
<Noldorin> err, mgz :-)
<mgz> I'm... not really still awake
#bzr 2011-12-31
<Noldorin> mgz, how come? :-P
<mgz> because it's bed time, just trying to finish livecd backup
<mgz> (as you may have gathered, this does mean I am actually still awake, and mostly watching progress bars)
<Noldorin> mgz, ah, though you were an American for some reason.
<Noldorin> mgz, still want me to write that blog post about setting up bzr+ssh on windows? :-P
<Noldorin> might get some time tomorrow
<Noldorin> s/might/should
<Noldorin> s/tomorrow/weekend
<mgz> would be great if you could
<Noldorin> ok will do :-)
<Noldorin> back in the mood of blogging since recently
<Noldorin> so shouldn't be too hard
 * jelmer waves
<Movix> hi, is someone here  speaking french ?
<Movix> perhaps speaking german ?
<AuroraBorealis> how does branching work with colocated branches?
<AuroraBorealis> if i do 'bzr branch . "something" "
<AuroraBorealis> then it creates the branch inside the owrking tree inside of the .bzr/branches folder
<AuroraBorealis> anyone on irc? :>
<mgz> hic
<AuroraBorealis> hey
<AuroraBorealis> first off: i still need to fix the stuff we were working on, couldn't really come on cause my video card on windows decided to die hehe
<AuroraBorealis> second off:
<AuroraBorealis> mr Movix is trying to set up a sepcific workspace flow thingy, is it possible to have a branch that has branches underneath it?
<mgz> well, I'm just hanging around eating stollen, so can help out
<Movix> thx, i appreciate a lot
<mgz> Movix is the one with the cms/php complicated setup thing?
<Movix> oh ! seems so !
<AuroraBorealis> well it seems that it would just be solevd with a branch with branches underneath
<AuroraBorealis> and i see bzr has "split" which does that
<AuroraBorealis> but...then it wants to version the newly created branch
<mgz> what he's directly asking for is nested trees I think, which... is not fully implemented and still rather complicated
<AuroraBorealis> yeah.
<AuroraBorealis> it wants to version the repo files and stuff and that doesn't seem right
<mgz> what he really wants is probably just a less complex way of working
<Movix> ok, that reconciles me with bazaar, because i allready thought i'm to stupid for this stuff
<AuroraBorealis> i feel you would have this problem with any vcs honestly
<mgz> right.
<Movix> yes, i was afraid about it but came to this conclusion also
<AuroraBorealis> you could also use symlinks
<AuroraBorealis> but again there is windows, and the bug which i need to try and see if i can fix >.>
<mgz> subversion has reasonable support for integrating different related branches, but it's still fiddly to work on
<mgz> I think really, what you want is:
<mgz> * A pristine upstream branch of the cms
<mgz> * A branch from that, with your changes and modules
<Movix> at this point i have my first issue
<mgz> * A number of "known good" or release branches, which you don't work on directly
<mgz> then merge selectively downwards
<Movix> i do not want to have the cms files mixed up with the module files, or i need to have a simple way to extract only the module related files in order to make a module only release
<mgz> bzr export subdir works
<mgz> as does bzr merge, and selective revert
<mgz> eg
<mgz> you have branches Upstream, Development, and CurrentRelease
<Movix> i did not understood the selective reverts Martin allready suggested to me on launchpad
<Movix> yes i allready tested taht structure
<Movix> and it indeed comme the closest to what i expect
<mgz> if you want to update one module in CurrentRelease to what you have in Development, but won't want any of the other changes
<Movix> let me please say this in my own words to make sure i unterstood it well
<Movix> what do you mean by "any of the other changes" ?
<mgz> okay, give an example
<mgz> well, I'm imagining you just do all your own changes in Development currently
<mgz> so, you've updates module/x but also changed various other things in templates and maybe updated to the latest upstream version
<mgz> if you know which changes you want to land on an existing release in advance, you work on those in a seperate branch
<mgz> but even if you don't, you can merge or cherrypick merge just the changes to module/x without including all the others
<mgz> so, you don't need a seperate version control branch for each module and template
<mgz> which makes life complicated, as you then need to track everything seperately, but also record which versions of each branch work with which versions of other branches
<Movix> that's the point
<mgz> generally it's sufficient to just commit independant changes as seperate commits, and keep branches in a known-working state
<Movix> so i finaly made my life easier on one hand but complicated it on another
<mgz> people seldom care in practice about full dependency tracking for each tiddly component of a project, they just want a few known correct states
<Movix> i'm happy to see that most of my conclusions were not so weird
<mgz> so, you have a 'stable' or similar branch you want to keep existing versions, but perhaps selectively update certain things
<Movix> correct
<mgz> that you can do by just branching from an older revision, and cherrypicking or daggy fixing certain modules
<Movix> have to give a look at cherrypicking, i did not looked at it for now :(
<mgz> or, say, you want all your modules unchanged, but need to update the base cms to the latest minor version with security fixes
<mgz> all you need in that case, is your pristine upstream branch of the cms
<mgz> update and commit the new version, then `bzr merge -d StableRelease Upstream; bzr commit -m'Update to X.X.1'` or similar
<mgz> if upstream has multiple branches going at once, it still works, you just keep a branch for each series
<mgz> some of this is easier to do with pictures :)
<mgz> so, with merging backwards to stable like this, there are three basic options:
<mgz> * Merge the newer branch, revert every change you don't want, and commit
<mgz> * Cherrypick merge just the revision with the change (this is similar to just commiting the applied patch)
<mgz> * Do the fix on branch at a revision before stable diverged, then merge into both development and stable branches
<mgz> AuroraBorealis: so, is your gfx card fixed now? what's our next step?
<AuroraBorealis> well
<AuroraBorealis> its fixed now
<AuroraBorealis> but i think my disk might be screwed up cause i seem to be creating a lot of undeletable files
<AuroraBorealis> so i'm going to try and fix this before anything else
<AuroraBorealis> HOWEVER
 * mgz fears hardwar :)
<mgz> +e
<mgz> but I guess hard war too.
<AuroraBorealis> are colocated branches fully supported yet?
<mgz> yes, they need some ui work still, but go ahead and poke them/file bugs
<AuroraBorealis> because i'm not exactly sure how to create another branch inside of one
<mgz> that's... nested trees, not colocated branches?
<AuroraBorealis> i created a 'colocated branch' in bzr explorer
<AuroraBorealis> and the branches are stored in .bzr/branches
<mgz> colo is just about having one directory represent more than one branch
<Movix> that seems interesting to me
<AuroraBorealis> yeah, so shouldn't it be possible to have more then one branch in the same directory?
<Movix> for my needs^^
<AuroraBorealis> cause i thought thats how git does it
<mgz> in your case Movix, you're more likely to get deeply confused by colocation than find it useful I think
<AuroraBorealis> and then you use switch to switch between branches
<mgz> you need to keep in your head that you're only working on the development tree, and merging changes around
<Movix> may i post here what i understood from your suggestions to verify i understood it ?
<mgz> right, so, that all works AuroraBorealis, what aren't you succeeding tat?
<mgz> Movix: go for it
<AuroraBorealis> well creating a branch in a colocated branch
<AuroraBorealis> creates it in the wrong place it seems like
<mgz> `bzr switch -b newbranch` is all you need for a new branch in the same dir with a colo format
<mgz> it's in .bzr/branches under the hood, but you can address it with the funny comma syntax
<AuroraBorealis> yeah
<AuroraBorealis> that doesn't seem very..intitutive
<AuroraBorealis> i was trying to do "bzr branch . somenamehere"
<mgz> okay, so, file bugs/post to the mailing list about the bits you find confusing
<AuroraBorealis> and the fact that to create another branch you have to use switch xD
<mgz> you can do it with the branch command, but... the addressing is ugly
<mgz> need something like `bzr branch . file:,branch=newbranch`
<AuroraBorealis> hm =/
<mgz> the problem with what you tried is it works as a command meaning something else
<AuroraBorealis> yeah
<AuroraBorealis> it created a new branch
<AuroraBorealis> but it didnt do it in the way that colocated branches expected it
<mgz> I use exactly that with python and mercurial, branch from the (treeless) current dir into a new subdir (and create a tree)
<mgz> if that's a common issue, trapping it as a mistake and warning or something may be useful
<AuroraBorealis> as in you branch inside the .bzr/branches folder
<AuroraBorealis> directly?
<mgz> no
<Movix> to build my structure i do this
<Movix> bzr init bzr/cms
<Movix> bzr commit bzr/cms -m "Project init" --unchanged
<Movix> bzr branch bzr/cms /bzr/upstream
<Movix> bzr branch bzr/cms /bzr/dev
<Movix> bzr branch bzr/cms /bzr/currentRelease
<Movix> i copy my downloaded cms files into /bzr/upstream, do add and comit -m "cms version xy"
<Movix> now i have to push this to my paent branch bzr push /bzr/upstream /bzr/cms
<Movix> and can get his update in my dev branch bzr pull /bzr/cms /bzr/dev
<Movix> now i add my module files or do some work that once finished is comited bzr commit /bzr/dev -m "Mymod init"
<Movix> If i'm still wrong on these first steps i appologyse to have wasted your precious time
<mgz> Movix: roughly seems fine, some comments in a sec
<mgz> AuroraBorealis: no, it's something of a quirk with the python/hg setup, they have different development series bundled into one, so to get a tree for each version, I branch the whole lot into python/ without trees, then do (the hg version) branching python/ into python/2.7 to get just that branch with a tree
<AuroraBorealis> ah
<AuroraBorealis> interesting
<mgz> in bzr, there's really no good reason to create a new branch from the current directory to a subdir
<AuroraBorealis> yeah
<mgz> because we have shared repos
<AuroraBorealis> well i was just trying to see how you create another branch in a colocated dir
<mgz> yup.
<AuroraBorealis> i'll file a bug report on saying thats hard
<mgz> so, the right answer is switch -b, it's just not very obvious
<AuroraBorealis> also: where should i file documentation bugs?
<AuroraBorealis> yeah, i feel branch should be smart and do it correctly if its in a colocated branch
<mgz> against bzr generally. perhaps posting a selection of impressions to the list would be most useful
<AuroraBorealis> well i just notice that 'bzr new' is not on the online documentation at all
<AuroraBorealis> and then doing bzr new --help says "usage: bzr init-workspace [LOCATION] "
<AuroraBorealis> so that is wrong as well
<mgz> ...seems to be from bzr-explorer?
<AuroraBorealis> oh.
<AuroraBorealis> it even says that.
<AuroraBorealis> at the bottom.
<AuroraBorealis> well, i'll file that against explorer
<mgz> Movix: so, you don't need to do that empty commit at the start, and want to branch from upstream to dev, and from dev to currentRelease
<mgz> I'd suggest... unpack upstream release to bzr/upstream then bzr init and bzr commit there
<Movix> ok
<mgz> then branch that to bzr/dev then branch bzr/dev to bzr/currentRelease
<mgz> now copy across your working development file into bzr/dev and do `bzr st`
<mgz> check it looks sort of right, add anything you need to, commit
<mgz> you may want to look at `bzr ignore` before that, all three branches will want it probably
<mgz> (it's less important for upstream, as you may not need to build/test that locally)
<mgz> anyway, after that you can try merging those dev changes to currentRelease and reverting some of them
<mgz> remember you can always chuck some branches away, create new ones, branch from old revisions, and such like
<mgz> so should experiment as much as possible
<AuroraBorealis> thanks for the help, i'll try and fix my windows problems and get back to working on the memory stuff
<AuroraBorealis> but now, bed~
<Movix> thanks so far for your help, i go back testing
<mgz> feel free to keep bugging me
<Movix> (16:27:56) mgz: you may want to look at `bzr ignore` before that, all three branches will want it probably
<Movix> you meen i'll ignore the files issued from the CMS sources (or part of these) ? This does not work because there are issued and commited in the parent of bzr/dev
<mgz> no, I mean ignore anything you don't want versioned
<Movix> ok, i continue testing
<mgz> like stuff automatically created when running in place or whatever
<Movix> ok, understood this
<mgz> will just be nipping out with hound, should be back shortly
<Movix> mgz: Back again ?
<Movix> mgz: are you here ?
<mgz> Movix: back (briefly)
<Movix> yeah, i just want to say that i got a quite good result now
<Movix> the cherrypick is the way
<Movix> using the suggeested structure
<Movix> but when releasing a module branch /bzr/dev /brz/modulerelease.xy i have to cherrypick all changes to the branch that do not concern the module. that needs to relosve a lot of conflict on that path but finally i have a clean module release folder
<Movix> i guess i have to keep the message in the explorer when within bzr/dev that tells me not all changes are merged to the parent and never murge them. tu update to a new upstream release release, i delete contents of bzr/upstream and populate that folder with the new downloaded files and commit this. after that i grab it within the dev folder with a pull merge command.
<Movix> anyway, thank you a lot for your effort in understanding my bad english and the time you spent for my concerns
<mgz> I don't quite follow that, but you don't really want pull from dev to release
<mgz> you just want merge, either -r31..32 for one specific change, or all changes then reverting and subdirs you don't need, which remembers not to try and bring in those changes again
#bzr 2012-01-01
 * jelmer waves
#bzr 2012-12-24
<JPeterson> after "bzr switch -b name" how do i switch to "* (default)"?
<JPeterson> i tried "bzr switch default", "bzr switch", "bzr switch *"
<JPeterson> and 'bzr switch "(default)"'
<LeoNerd> Perhaps try   bzr switch ""  ?
<JPeterson> LeoNerd: i'mnot positibe thats intended because bzr branches doesnt indicate another branch
<jelmer> JPeterson: The asterisk indicates that you are already at that branch
<JPeterson> it seems to me that it's not designed to be able to switch back to (default) after at least one branch is created
<JPeterson> can i remove the second to last commit?
<jelmer> JPeterson: '(default)' doesn't have a name, so if you switch away from it it will be lost
<jelmer> JPeterson: you can create a name for it by using 'bzr switch -b newname'
<LeoNerd> I don't tend to use switch, anyway.. disk is cheap; if I want a new branch on disk I'll just create a new sibling directory
<LeoNerd> That way I don't have to play silly "make clean" tricks from time to time when files change, anyway
<LeoNerd> I find it a lot neater that way
<JPeterson> 2.6 fixed the primary shortcoming of not having branches
<JPeterson> however it seems like i cant remove previous commits or reorder commits, as with git rebase -i
<JPeterson> i would place that as the second shortcoming after branches
<fullermd> What is?
<LeoNerd> You can uncommit (bzr uncommit), and you can reply
<LeoNerd> replay
<LeoNerd> On the rare times I want to reorder some commits, I branch from the unwind point, then use "bzr replay" to replay commits into the right order
<JPeterson> ya
<JPeterson> launchpad should use git instead
<JPeterson> would save jelmer 5000 commits
<LeoNerd> But then I mostly work with bound branches, so such things would be a: rude, and b: largely unnecessary, as things hardly ever go into the trunk in the wrong order in the first place :)
<LeoNerd> Usually my reordering fixups are just for cases like having a spare commit that I made offline on the train over the top of a stale branch because I forgot to update my laptop before I left
<JPeterson> bzr uncommit returned
<JPeterson> Cannot expand "commit_data": Dicts do not support option expansion
<JPeterson> i dont see what that means though
<JPeterson> i dont see any effect of it
<jelmer> JPeterson: "bzr log" should show one revision less
<JPeterson> jelmer: thats without that message too
<JPeterson> i dont see an effect unique to that message
<jelmer> JPeterson: that message is just an error from a plugin hook that doesn't work I think
<JPeterson> allright
<k_sze> bzr is not checking SSL certificate for xmlrpc.launchpad.net. If I'm paranoid, how can I make it check?
<k_sze> In fact, why is it not checking the SSL certificate by default? This is a fresh installation of bzr on Mac OS X, using MacPorts.
<jelmer> k_sze: 2.5 should check SSL certificates IIRC
<jelmer> k_sze: what version are you using?
<jelmer> I'm not sure if it does it for xmlrpc.launchpad.net too, though
<k_sze> I have 2.5.1
#bzr 2012-12-25
<JPeterson> can i apply a git patch to bzr? including author and comment?
<JPeterson> is that in the git plugin?
<JPeterson> jelmer:
<jelmer> JPeterson: 'bzr git-apply' does some of that
<jelmer> JPeterson: it doesn't cope with new files at all though
<JPeterson> thx
<jelmer> (and is still very experimental in general)
<jelmer> JPeterson: in other words, use with care
<JPeterson> jelmer how do i bzr pull --rebase?
<JPeterson> i want to pull a remote branch to a new branch
<jelmer> there is 'bzr rebase --pull' I think, perhaps that's what you mean?
<JPeterson> so i created a new local branch to pull to
<JPeterson> so it's " --pull' I think, perhaps that's what you mean?
<JPeterson> [03:24] <JPeterson> so i create
<JPeterson> ops
<JPeterson> so it's "bzr rebase --pull lp:~john-peterson/calibre/context"?
<JPeterson> that returns "bzr: ERROR: no such option: --pull"
<jelmer> JPeterson: oh, actually I think the default 'bzr rebase does what you are asking about
<jelmer> (or maybe it just tells you to pull if pulling is possible?)
<JPeterson> ok i'll try "bzr rebase lp:~john-peterson/calibre/context"
<JPeterson> it returns
<JPeterson> Contents conflict in src/calibre/utils/fonts/subset.py
<JPeterson> that's unexpected because rebase will not consider conflicts
<JPeterson> how do i
<JPeterson> Resolve the conflict and run 'bzr rebase-continue'
<jelmer> JPeterson: I'm not sure I follow - rebase can cause conflicts in git too
<JPeterson> how do i force revert rebase?
<jelmer> "bzr rebase-abort"
<JPeterson> why not bzr rebase-continue?
<JPeterson> how do i resolve the conflict by using the remove version?
<JPeterson> *remote
<jelmer> JPeterson: if you mean to abort (iow, revert) the rebase, that's what 'bzr rebase-abort' does
<jelmer> JPeterson: 'bzr rebase-continue' will continue the rebase once conflicts have been resolved
<JPeterson> what i mean is ignore conflicts or use the remove version, and force it to complete
<JPeterson> bzr resolve; bzr rebase-continue
<JPeterson> return
<JPeterson> Remaining conflicts:
<JPeterson> Contents conflict in src/calibre/utils/fonts/subset.py.THIS
<JPeterson> bzr: ERROR: There are still conflicts present. Resolve the conflicts and then run 'bzr resolve' and try again.
<jelmer> JPeterson: see the help on 'bzr resolved'
<jelmer> JPeterson: you need to resolve the conflicts by editing the file, or explicitly specify what you want to happen to 'bzr resolve'
<JPeterson> so do i add a dot, as in and try again.
<JPeterson> [03:36] <jelmer> J
<JPeterson> ?ops
<JPeterson> as in bzr resolve .
<JPeterson> i did
<jelmer> JPeterson: that doesn't matter; 'bzr resolve' will only mark things as resolved if the conflict markers are gone *or* if you have specified an explicit action to take
<JPeterson> bzr resolve src/calibre/utils/fonts/subset.py.THIS
<JPeterson> now
<JPeterson> bzr resolve; bzr rebase-continue
<JPeterson> return
<JPeterson> Remaining conflicts:
<JPeterson> Contents conflict in src/calibre/utils/fonts/subset.py.THIS.THIS
<JPeterson> bzr: ERROR: There are still conflicts present. Resolve the conflicts and then run 'bzr resolve' and try again.
<JPeterson> it added another .THIS, compared to the previous message
<jelmer> JPeterson: you'd want to resolve the file itself, not its .THIS file
<JPeterson> bzr resolved src/calibre/utils/fonts/subset.py
<JPeterson> returns
<JPeterson> src/calibre/utils/fonts/subset.py does not exist
<JPeterson> 0 conflicts resolved, 1 remaining
<JPeterson> i'll try
<JPeterson> bzr uncommit -r-100
<JPeterson> and try rebase again
<JPeterson> maybe it will be easier to rebase forward
<jelmer> rebase is almost exclusively useful for rebasing a few trivial local changes on top of an upstream branch
<jelmer> it's not very advanced
<jelmer> JPeterson: ^
<JPeterson> jelmer: then i shouldnt use it checkout a remote branch
<JPeterson> then i should uncommit the local branch to before the remote branch and pull it
<JPeterson> jelmer: am i correct to assume that "bzr fast-export --plain .|git fast-import" will also convert bzr branches to git branches?
<jelmer> JPeterson: that will convert a bzr branch to a git branch; not sure what you mean by "also" though
<JPeterson> jelmer: how do i convert all bzr branches to git branches?
<JPeterson> jelmer: whats the --export-marks and --import-marks for in http://dgleich.wordpress.com/2011/01/22/convert-bazaar-to-git/
<JPeterson> why doesnt "man bzr fast-export" return what I want?
<JPeterson> where is the bzr fast-export manual?
<JPeterson> how do i access the repo from a different path?
<JPeterson> accessing the repo from "~/shared.hgfs/source/Programs/calibre/repo" return "bzr: ERROR: Not a branch: "/C:/Files/Source/Programs/calibre/repo/"."
<JPeterson> can i change something to a relative path? or do need to change the full path? in that case where?
<JPeterson> jelmer:
<JPeterson> it seems like it's
<JPeterson> cat .bzr/branch/location
<JPeterson> that is related to that message
<JPeterson> can i change
<JPeterson> file:///C:/Files/Source/Programs/calibre/repo/
<JPeterson> to
<JPeterson> .
<JPeterson> bzr switch context
<JPeterson> return
<JPeterson> bzr: ERROR: Not a branch: "/mnt/hgfs/shared/source/Programs/calibre/repo/,branch=context/".
<JPeterson> why? how do i fix it?
<JPeterson> the goal is to run "bzr fast-export --plain --git-branch=context|git fast-import"
<JPeterson> (from linux as running it from cygwin return "error: git-fast-import died of signal 11")
<JPeterson> jelmer if you wont answer this, then answer this how do i move a bzr repo?
<JPeterson> so that i can use it from another path
<JPeterson> i.o.w. how do i deal with .bzr/branch/location?
<JPeterson> where is the bzr 2.6 ppa?
<JPeterson> "sudo add-apt-repository -y ppa:bzr/ppa" didnt update it to 2.6
<JPeterson> ok it's "sudo add-apt-repository -y ppa:bzr/beta"
<JPeterson> bzr branches
<JPeterson> return
<JPeterson> bzr: ERROR: Not a branch: "/mnt/hgfs/shared/source/Programs/calibre/repo/,branch=context/".
<JPeterson> how does it come to that conclusion?
<JPeterson> so does "bzr switch context"
<JPeterson> it seems like "bzr switch --force context" works
<JPeterson> ah ok it needs to be "file:///mnt/hgfs/shared/source/Programs/calibre/repo/"
<JPeterson> can i export bzr commits to a git patch?
<mgrandi> piping bzr log to a file should create a patch file
<mgrandi> so like bzr log -r 1..5 > someFile.patch
<JPeterson> mgrandi: i want the comment, date, author
<JPeterson> with git patch i mean "git format-patch"
<JPeterson> the commit sha1 can be anything, it doesnt matter
<JPeterson> it would be surprising if there was not a way to do this
<JPeterson> because of how simple if would be
<mgrandi> what do you mean format-patch, not familiar with it
<mgrandi> like a patch file that you pass to git? or to patch
<mgrandi> ?
<JPeterson> it has patch, comment, date, author
<JPeterson> and parent commit sha1 which is not necessary
<JPeterson> so can i bzr fast-export a limited number of commits?
<mgrandi> probably, using the -r revisionspec thing
<JPeterson> the repo has many commits, 22k, and i only need the top 5
<mgrandi> so bzr whatever -r -5..-1
<JPeterson> the bzr fast-export manual doesn't say what -r does
<JPeterson> why would i expect it to export r to head rather than init to r?
<JPeterson> what's the revisionspec for the top five commits?
<mgrandi> it says   -r ARG, --revision=ARG
<mgrandi> it says to do bzr help revisionspec
<mgrandi> and i told you, it was -r -5..-1 =P
<mgrandi> also, this patch-format thing looks a lot like 'bzr testament --long"
<mgrandi> or bzr send / bzr email
<JPeterson> how can it be -r-1..-1? isn't that 0 commits?
<JPeterson> omg it returns
<JPeterson> warning: Not updating refs/heads/date (new tip bdf16f0ef570e6bb6e7e620899bee6f0edd69a81 does not contain 476e775c0e5ac5cb457f4c5ffe6a8ca50da662de)
<JPeterson> how do i rename a branch?
<LeoNerd> mv
<Peng> bzr nick may also interest you
<LarstiQ> JPeterson: if you have bzr-git, `bzr send` should have a git-format option iirc
<JPeterson> LarstiQ: thx
<JPeterson> bzr send --format=git
<JPeterson> return
<JPeterson>   File "C:/Program Files (x86)/Bazaar/plugins\git\send.py", line 121, in to_lines
<JPeterson> AttributeError: 'NoneType' object has no attribute 'splitlines'
<JPeterson> additional trace is
<JPeterson>   File "bzrlib\builtins.pyo", line 5824, in run
<JPeterson>   File "bzrlib\send.pyo", line 136, in send
<JPeterson>   File "bzrlib\merge_directive.pyo", line 348, in compose_merge_request
<JPeterson> bzr 2.6b1 on python 2.6.6 (Windows-7-6.1.7601-SP1)
<Munchor> Hello
<Munchor> Does bzr allow deleting commits?
<Munchor> I know that with git+github I can actually delete like the last X commits. Can I do that with bzr+launchpad?
<jelmer> Munchor: bzr uncommit
<Munchor> bzr uncommit;bzr uncommit;
<Munchor> that woudl delete 2 commits, right?
<Munchor> And jelmer, bzr uncommit removes local commits, not commits on Launchpad AFAIK
<LarstiQ> Munchor: bzr push --overwrite to launchpad will do that. Take note though that this will wreak havoc for anyone who already has a copy of what was on launchpad.
<Munchor> >wreak havoc
<Munchor> I don't fully understand that
<LarstiQ> Munchor: be not nice
<Munchor> I'm even more confused that
<LarstiQ> Munchor: if you delete some commits, and then start developing from there again, your branch will have diverged from what other people had
<LarstiQ> Munchor: so they can't simply `bzr pull` to get up to date
<Munchor> Ooh I see
<LarstiQ> and if they had done extra commits on top, merging their work in would resurrect the deleted commits
<LarstiQ> Munchor: it's not the end of the world, but it's good to be aware of
#bzr 2012-12-26
<creatorbri> Does anyone here know how to copy/duplicate a file in a repo, and preserve history on both files? Is this possible?
#bzr 2012-12-27
<[1]JPeterson> how do i set bzr whoami local to the current repo?
<jelmer> [1]JPeterson: bzr whoami --branch
<lifeless> or set it in ~/.bazaar/locations.conf
<lifeless> if you want a path prefix
<[1]JPeterson> thx
#bzr 2012-12-28
<pulb1> hey guys, does anybody know how to sync remote tags?
<pulb1> i changed tags localy but they won't be pushed to the remote branch
#bzr 2012-12-30
<Noldorin> hlmm
<Noldorin> does bzr have an equivalent of git cherry-pick?
<bob2> http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html
#bzr 2013-12-23
<pzn> I have an HD with filesystem error. some directories are weird. what is the filename of some file that exists in a bzr repository for me to search for?
<daveb_> When merging in a branch, its wanting to delete some files, but I cant find a commit in that merge that deletes those files :(
#bzr 2013-12-24
<tos9> Hey, I'm sure it's been asked/reported before, but anyone planning on uploading bzr to PyPI?
#bzr 2013-12-25
<razamatan> is there any way to shrink a bzr repo?  i'm fine w/ losing some history
#bzr 2013-12-27
<Munchor> Hi
<Munchor> How do I revert & delete commits?
<Munchor> I know I can use bzr revert -r to revert to revision X, but that doesn't remove the history-.
<Munchor> Oh it's with bzr push --overwrite, thx
#bzr 2015-12-21
<xzcvczx> is there a bzr command to get rid of the *.~#~ files?
<fullermd> There's a clean-tree command, I think it has an option for that.
<xzcvczx> oh --detritus?
<xzcvczx> sorry i completely skipped over that....
<xzcvczx> thanks
#bzr 2015-12-24
<valerio-bozzolan> How to force the deletion of a tag when push?
<valerio-bozzolan> I've tried --overwrite and --overwrite-tags and toghether but nothing
<fullermd> Can't do it with push.  You'd have to use tag --delete with -d.
<valerio-bozzolan> With `tag --delete myoldtag` I'm OK locally, but I can't push what I have locally
<valerio-bozzolan> The push --overwrite and --overwrite-tags say "No new revisions or tags to push." and it don't remove my tag remotely
<valerio-bozzolan> Any advice to force a rewrite of my remote trunk?
<fullermd> That's why you use the -d on tag to specify the remote branch.
<valerio-bozzolan> bzr tag --delete 1.7.0.2 -d lp:bus-torino
<valerio-bozzolan> Wow
<valerio-bozzolan> Really thanks. But why it does not work with bzr tag && bzr push?
<fullermd> Well, you wouldn't want push to remove tags somebody had set on the remote side that you didn't have locally.
<fullermd> And without versioned tags, there's no way to distinguish that case from the case where you're deleting something and trying to push it.
<valerio-bozzolan> Well, thanks! And if you visit Torino have fun with BusTO @ F-Droid.
<fullermd> What, go somewhere in the Real World?!  That's what IRC is for!   8-}
<valerio-bozzolan> But you are not AF*K* on a bus... there is also the virtual one
<valerio-bozzolan> OK stop us. Have a nice day!
