#bzr 2008-01-21
<awmcclain> Is there a reason why bzr for os x doesn't give any feedback during a branch operation?
<spiv> PyCon registration is open: http://us.pycon.org/2008/registration/
<spiv> awmcclain: no good reason, it's a bug
<spiv> awmcclain: (a bug that happens on all platforms)
<awmcclain> spiv: When I branched on linux, i got a status bar. At least when branching from svn...
<spiv> awmcclain: hmm, I don't think there should be any difference between mac and linux for status bars.
<awmcclain> spiv: I'll look into it.
<poolie> hello kiko
<kiko> hey poolie
<poolie> hi, are you home now?
<guillaumebokiau> trying to install with macports, but installing macports itself doesn't seem to work. (port: command not found)
<guillaumebokiau> any advice?
<poolie> guillaumebokiau, i think you need to install the macports dmg
<guillaumebokiau> which i did  :|
<poolie> guillaumebokiau, http://www.macports.org/install.php -- then you'll have a port command
<poolie> hm
<poolie> is it on your $PATH?
<poolie> you might need to start a new terminal window?
<guillaumebokiau> i even rebooted
<guillaumebokiau> what is $path ?
<guillaumebokiau> sorry, not very good at those things :/
<poolie> please type 'echo $PATH'
<poolie> into your terminal
<poolie> also, 'echo $0'
<poolie> (and press enter)
<guillaumebokiau> \Library\Frameworks\Python.framework\Versions\Current\bin:\bin:\sbin:\usr\bin:\usr\sbin
<poolie> see, http://guide.macports.org/#installing.shell
<poolie> guillaumebokiau, ok, that's probably your problem
<poolie> try the instructions there
<guillaumebokiau> ok, thx
<poolie> guillaumebokiau, did that work?
<guillaumebokiau> trying to figure this out :)
<poolie> guillaumebokiau, just for curiousity, why are you using macports rather than a dmg?
<poolie> did we not have one that would suit?
<guillaumebokiau> isn't the dmg for ppc ?
<guillaumebokiau> i'm on intel
<guillaumebokiau> 10,4
<poolie> ok
<poolie> yes, that's it
<igc> the dmg should be universal I think
<poolie> i mean, i wondered if that was the problem
<poolie> we need someone with a intel 10.4 mac to rebuild it
<guillaumebokiau> i tried with the ppc dmg anyway, but it didn't work
<igc> guillaumebokiau: yes, checking again, the 10.4 installer is only ppc only right now sorry
<guillaumebokiau> there's no other way to install it?
<guillaumebokiau> than with macports?
<igc> guillaumebokiau: running straight from source is really easy actually
<igc> simply untar and put the directory on your path
<igc> you'll need to install Python 2.4 or 2.5 separately
<guillaumebokiau> installed that
<igc> in not already installed
<igc> s/in/if/
<guillaumebokiau> er, what's my 'path' ?
<guillaumebokiau> (i'm really new to all this)
<igc> it's where your terminal looks for commands you type
<guillaumebokiau> that : \Library\Frameworks\Python.framework\Versions\Current\bin:\bin:\sbin:\usr\bin:\usr\sbin ?
<igc> you can create a file in your home directory to set it each time you start a terminal session
<bob2> guillaumebokiau: when you type "bzr", your shell looks in each of the directorys in the PATH variable (:-seperated) for that command
<igc> without setting a path just yet, let's test it works
<igc> unpack the tar.gz
<igc> change to the created directory and ..
<igc> type "./bzr version"
<guillaumebokiau> have a hard time following. where do I unpack?
<igc> anywhere you like ...
<igc> If you double-click ...
<guillaumebokiau> ok, it's on my desktop :)
<igc> cool
<igc> in a terminal, change into that directory
<igc> try "./bzr version"
<igc> guillaumebokiau: did that work?
<guillaumebokiau> hang on :)
<igc> the directory to change into is something like "Desktop/bzr-1.1"
<guillaumebokiau> ok, i'm there
<guillaumebokiau> ~/Desktop/bzr-1.1
<igc> great
<igc> does "./bzr" work?
<guillaumebokiau> yes!
<igc> sweet
<guillaumebokiau> cool
<igc> now let's put it on your path
<igc> type this:
<guillaumebokiau> yeah
<igc> PATH=~/Desktop/bzr-1.1:$PATH
<igc> then change to another directory and try "bzr"
<guillaumebokiau> it"s on the path when i echo it
<guillaumebokiau> working
<guillaumebokiau> great
<igc> ok, let's make it permanent
<igc> type "cd" to return to your home directory
<guillaumebokiau> done
<guillaumebokiau> should i copy the folder there?
<igc> with your text editor, create a file called ".prfile" if it doesn't already exist
<igc> oops ...
<igc> make that .profile
<igc> inside it put this text ...
<igc> PATH=~/Desktop/bzr-1.1:$PATH
<igc> export PATH
<igc> (that's it)
<igc> to test ...
<igc> start another Terminal, in a tab or new Window
<igc> type "bzr"
<igc> sound ok?
<guillaumebokiau> bzr command not found :(
<igc> ok ...
<igc> type "echo $PATH"
<guillaumebokiau> it's not in it
<bob2> maybe ~/.bashrc would be better, .profile is only sourced on "login"
<igc> good point
<bob2> depending on what os x considers login to be
<guillaumebokiau> i hav a .bash_profile file
<igc> guillaumebokiau: try putting those 2 lines in there then
<guillaumebokiau> k
<guillaumebokiau> ok, i got it working
<guillaumebokiau> pfew
<igc> good
<guillaumebokiau> i think the correct line was PATH="~/.bzr-1.1:${PATH}"
<guillaumebokiau> anyway, i thanks a lot
<igc> that ok
<igc> either syntax should work
<guillaumebokiau> you saved me :)
<igc> let us know if you need any more help
<igc> no problem
<ubotu> New bug: #184733 in bzr "Internal error running bzr selftest for bzr 1.1 on MacOS X 10.5.1" [Undecided,New] https://launchpad.net/bugs/184733
<guillaumebokiau> where does bazaar save local copies ?
<poolie> into .bzr in the top of the branch
<guillaumebokiau> not sure you understood the question :) if I run bzr branch http://bazaar.launchpad.net/~manfre/xpattern/xpattern-1.0 where does it land ?
<guillaumebokiau> ah, found
<guillaumebokiau> ok, sorry, i'm officially stupid
<poolie> right, into your working directory
<poolie> no problem, questions are welcome
<eean> how come it says Unable to load plugin 'bzr_svn_0_4_6' from '/home/ian/.bazaar/plugins' ?
<eean> when trying to do a bzr svn clone
<eean> I do have the plugin there
<spiv> eean: look in ~/.bzr.log
<spiv> eean: it should have a more detailed error
<eean> ImportError: The Subversion plugin must be installed as bzrlib.plugins.svn not bzrlib.plugins.bzr_svn_0_4_6
<eean> so I'll rename the directory I guess
<spiv> Right.
<eean> there it goes
<eean> I hear it doesn't have a memory leak anymore
<eean> appears so, so far
<eean> hmm
<eean> it is increasing in memory steadily :/
<spiv> eean: it depends on how new your subversion bindings for python are
<eean> aaaah
<eean> spiv: do you happen to know how new they have to be?
<eean> it is not using crazy amounts of memory like it used to, but its certainly still leaking.
<spiv> eean: SVN version of the as of about or week or so ago, IIRC
<eean> that would make sense that the subversion bindings would be to blame, I didn't understand how a python script could leak. so its probably something in the c bindings
<eean> haha crap
<spiv> eean: I think the bzr-svn README links to the relevant bug
<eean> riddell blogged before then that it had been fixed in bzr-svn
<spiv> eean: I think newer bzr-svn tries to workaround the worst of it, but obviously it can only do so much...
<eean> I see
<spiv> eean: yeah, see the first part of the FAQ in the bzr-svn source :)
<spiv> "bzr-svn can use a lot of memory cloning big branches when older
<spiv> versions of the python-subversion bindings are used. This memory leak
<spiv> has been fixed in the trunk of Subversion (r28544) and has been
<spiv> proposed for inclusion in Subversion 1.4.7.
<spiv> "
<eean> oh wow, its subversion itself to blame?
<spiv> eean: it's possible this fix has already been included hardy, I haven't checked...
<eean> well I use gutsy
<spiv> eean: right, the python bindings are made by the subversion guys.
<eean> ah ok
<eean> I can probably make due if I quit and redo every 100000 commits
<spiv> Yeah :)
<eean> before it would eat all my memory at about 1000
<eean> git svn is giving me shit, so this is a good time to switch ;)
<spiv> :)
<eean> I guess this bug has probably made bzr svn clone pretty robust at restarting
<eean> git svn couldn't deal with the svn server timing out, after about 30 minutes of cloning :/
<eean> pfft, or not. "bzr: ERROR: sqlite3.OperationalError: SQL logic error or missing database"
<spiv> eean: ooh, I haven't seen that one before.
<eean> http://pastie.caboo.se/141399
<eean> on resuming
<spiv> eean: could you file a bug report?  I expect jelmer would like to see that.
<eean>  /dev/sda8              44G   42G  1.7M 100% /home
<eean> might explain it :)
<spiv> eean: ah :)
<eean> will I be able to share this checkout with other devs?
<eean> I'm kind of worried that it appears to be downloading into ~/.bazaar
<spiv> eean: yes
<spiv> eean: the stuff in .bazaar is just a cache of the mapping between data the SVN repo and the data converted to bzr
<spiv> eean: if the cache is missing or incomplete, bzr-svn will just regenerate it as needed.
<eeanm> bah my laptop power cord got loose
<eeanm> spiv: did you say anything after 'yes'?
<spiv> eeanm: I did, I'll paste:
<spiv> 17:25 < spiv> eean: the stuff in .bazaar is just a cache of the mapping between data the SVN repo and the data converted to bzr
<spiv> 17:26 < spiv> eean: if the cache is missing or incomplete, bzr-svn will just regenerate it as needed.
<eeanm> um that mapping the hard part
<eeanm> um *isn't that mapping the hard part
<eeanm> at least when you're cloning a 2.5k LOC, 200 commit module from a SVN with >700000 commits
<bob2> yes, but people branching from your bzr repository won't need it, all they need is in the bzr repository
<eeanm> the mapping is a big chunk :|
<spiv> eeanm: people only need the mapping if they want to use the SVN repo
<eeanm> well yea
<spiv> eeanm: I can e.g. take your bzr branch, and make a branch off that, make some commits, and send those back to you, all without touching the upstream SVN repo.
<eeanm> suppose I could do it that way, but it'd be nice if folks could push to svn themselves
<spiv> They'll need the mapping then.
<eeanm> won't be such a big deal once this memory leak fix is availabe
<spiv> You can probably share the cache from your .bazaar directory.
<eeanm> sounds like bzr has their act more together then git, we try publishing a git svn repo, someone commited something that they didn't end up pushing to SVN, it totally screwed it up
<eeanm> would be nice to have feature branching in bzr that could be easily synced with svn
<eeanm> (that's what we were trying to do with git)
<poolie> eeanm, well, that should work through bzr-svn
<eeanm> dang the cache is up to 771 megabytes
<poolie> how big is the svn repo?
<eeanm> >700000 commits
<eeanm> 764k
<eeanm> I'm up to 421k
<eeanm> sqlite> select count( * ) from changed_path;
<eeanm> 3578513
<eeanm> probably has something to do with it :)
<eean> 529215/764151 woot
 * igc dinner
<eean> the svn clone is soo near completion, and now its just hanging apparently :)
<eean> erm
<eean> :(
<AfC> eean: Is the Subversion repository in question public? If it is, I'm sure people will be willing to attempt to replicate the problem.
<eean> yea, its KDE
<eean> ah ok cool
<eean> nevermind
<eean> now its "analyzing layout"
<eean> about 4 minutes there when it didn't respond, I was  worried :)
<eean> heh analyzing layout is going to take an hour or so it looks like. at least it doesn't leak memory.
<eean> ah no, that's not true, more like 15 minutes I bet, its already 1/7 done
<lifeless> hi
<lifeless> jelmer: sorry, missed that in backlog, only saw your ^^, what was it ?
<AfC> eean: You might want to reply to poolie's RFC about finer grained progress reporting on the mailing list today and note your experience of long waits without feedback
<asabil> hi all
<lifeless> hi
<lifeless> abentley: hi
<lifeless> abentley: how is sydney :)
<abentley> Quite nice.
<abentley> Weather's definitely superior to Toronto's.
<abentley> Although pretty similar to Toronto in summertime.
<thumper> lifeless: it is hot and muggy
<thumper> too hot and too muggy
<thumper> but that's from my Dunedin point of view
<abentley> This is the first sprint I've ever done without you, though, which is a bit wierd.
<abentley> thumper: Toronto in the summertime can be quite muggy, too.  We're on the edge of Lake Ontario, one of the Great Lakes.
<lifeless> thumper: unedin is easily as humid; its the heat that does it
<muffinresearch> Greetings chaps.
<muffinresearch> Are the London sprint dates set in stone? Just it clashes with SXSWi in part.
<muffinresearch> Though in any case I would try a pop along on the Monday if I can
<thumper> muffinresearch: what is SXSWi?
<muffinresearch> south by south west
<muffinresearch> http://sxsw.com
<muffinresearch> Is coming to the sprint, a good idea for people who want to start getting more involved?
<asabil> http://ifaedi.insa-lyon.fr/~asabil/bzr-viz-tags.png
<muffinresearch> Or is it more of a closed event for current core developers?
<eean> does bzr svn not follow svn moves?
 * eean looks at the website again
<jrydberg_> svn does not have move
<eean> um, yes it does
<jrydberg_> it has copy, iirc.
<eean> and move
<eean> but anyways
<eean> its possible either way
<Akheron> it has sime kind of add with history?
<eean> does bzr not follow them?
<eean> Akheron: yes
<jelmer> eean: svn only has copy+delete
<eean> that sounds awfully like moving to me
<eean> and there is a svn move command
<jelmer> eean: in order to be able to convert a copy+delete to a rename you have to prove there is only one copy of a file and that the original was removed
<eean> I don't care if its seen as a rename or not
<jelmer> "svn move" is an alias for "svn copy"+"svn delete"
<eean> but it thinks this 8 month old project is only a day old
<eean> since it was copied+deleted yesterday
<jelmer> it should follow copies of branches
<jelmer> (if you copy /trunk to /tags/2.0 it should recognize that)
<eean> ah ok, well it didn't. I'll double check the svn log
<jelmer> is this a public repository?
<eean> yes
<eean> svn://anonsvn.kde.org/home/kde/trunk/KDE/kdemultimedia/dragonplayer
<eean> well svn log tracks its history through all the reneames
<jelmer> ah, the KDE repository
<eean> this project is entirely post-CVS if that's what you're thinking :)
<eean> I heard that conversion messed some things up
<jelmer> At the moment the copy tracking only works for the current "branching scheme"
<eean> ah
<jelmer> by default that's the standard /trunk ; branches/* ; tags/* structure
<asabil> jelmer: is that what you wanted : http://ifaedi.insa-lyon.fr/~asabil/bzr-viz-tags.png ?
<eean> jelmer: can you add this as a known problem?
<jelmer> eean: We're trying to make that deal with other situations as well, but that won't happen until 0.5.0
<eean> cause I just wasted 3 hours last night, restarting bzr svn constantly :|
<jelmer> eean: There's already a bug for it
<asabil> (iirc I had a discussion yesterday with you and Schierbeck)
<eean> I mean, on the website
<jelmer> asabil: Ah, that looks quite nice
<jelmer> eean: will do, thanks
<asabil> jelmer: want a branch to give it a try?
<eean> cool thank you
<jelmer> asabil: any chance you can send an email to the bzr-gtk list?
<asabil> jelmer: I am not subscribed :/
<jelmer> asabil: Should be easy to do :-) Otherwise I can manually approve your email
<asabil> jelmer: I was subscribed a while ago
<asabil> but the list is very high traffic for me
<jelmer> asabil: it's a lot quieter these days :-/
<eean> jelmer: do you plan on optimizing how you use the sqlite database? I suppose personally I don't optimize until after I'm finished, so I can't blame you for not. :)
<eean> cause for KDE its 1.9gigs
<jelmer> eean: the focus so far has mostly been on correctness
<jelmer> eean: hopefully we can cache less in the near future
<rjek> corrections is paramount: performance is a bonus.  Especially in this sort of product.
<eean> right
<rjek> s/corrections/correctness/
<asabil> jelmer: https://code.launchpad.net/~asabil/bzr-gtk/viz-tags-fancy
<asabil> jelmer: please feel free to mail the list about it, if you want
<asabil> I am busy with other things right now sorry
<asabil> I edited the branch summary to point to the screenshot
<schierbeck> asabil: hello!
<asabil> hey schierbeck
<asabil> schierbeck: https://code.launchpad.net/~asabil/bzr-gtk/viz-tags-fancy
<schierbeck> i've just seen it, great job!
<schierbeck> are you on the mailing list?
<asabil> nop schierbeck
<asabil> please feel free to mail the list about it if you want
<asabil> and thanks :)
<schierbeck> i'm currently looking into some small changes, like decreasing the font size, having the tags stack horizontally so they're all visible, and using a single color for all tags
<asabil> decreasing the font size is as simple as
<asabil> tag_layout.set_markup("<small>" + tag + "</small>")
<asabil> instead of tag_layout.set_text(...)
<asabil> (but am not sure if you want to use tags)
<asabil> making the tags stack horizontally is a matter of changing x0 and leaving y0 fixed
<schierbeck> asabil: ok, i've made a few changes, they should be at http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/viz-tags
<asabil> schierbeck: did you try the code with many tags ?
<asabil> there is too much space between the tags I think
<schierbeck> asabil: only with two -- i'll check it out now
<asabil> but it looks nicer indeed
<asabil> there is just one issue
<asabil> I am not sure about using markups
<schierbeck> yeah, it screws up
<asabil> as it might blow up if ^evil^ developers decide to use pango markup in their tags :D
<schierbeck> asabil: we'll just escape the tag text
<schierbeck> we do that with the summary already
<asabil> if it is just about making the text smaller
<schierbeck> no, it's also about tooltips and such
<asabil> you can set the font directly
<asabil> oh ok
<cr3> how can I apply a bzr diff between releases 239 and 240 for example?
<luks> "apply"?
<cr3> bzr revert -r239..240?
<dato> cr3: bzr merge -r 239..240
<dato> or -r 240..239, depending on what you want
<cr3> dato: cheers, exactly what I was looking for
<ubotu> New bug: #183821 in bzr-svn "bzr branch fails with AssertionError in parse_revid_property" [Undecided,New] https://launchpad.net/bugs/183821
<schierbeck> asabil: try pulling again
<schierbeck> it seems to be working now
<asabil> imho it looks better
<asabil> :)
<schierbeck> asabil: would you be able to make the label have a single, common color?
<schierbeck> like a yellow, post-it-ish one?
<asabil> I am not sure if it is good idea
<schierbeck> i think it would be more aesthetically pleasing
<asabil> so we need to decide on a color then
<schierbeck> yup
<asabil> a hardcode color :p
<schierbeck> :D
<fullermd> You could make it a red/blue offset, and sell 30-cent cardboard/gel glasses, so people can see them in 3-D!
<schierbeck> :x
<schierbeck> there may lie a few usability issues right there... :)
<schierbeck> although it would be kick-ass!
<fullermd> I can just see the reviews, though...   "I liked bzr overall, but it felt like the tags were attacking me."
<schierbeck> fuck, i always seem to get excited about these projects when i'm studying... my exam is on wednesday!
<fullermd> Heck, that's _days_ away...  plenty of time   ;>
<schierbeck> fullermd: we'd still be less scary than git...
<fullermd> Yeah.  git would be 3-d, but would sneak up from behind you.
<schierbeck> yup, and it would hold you down until you iterated all available git commands
<jelmer> schierbeck: That sounds familiar...
<fullermd> "Say 'git-fmt-merge-msg'!  *SLAP*  SAY 'git-fmt-merge-msg'!!!"
<jelmer> for some reason the time I'm most productive is the days before I have a deadline or an exam or something
<schierbeck> jelmer: me too, it's just that i'm not studying
<schierbeck> everything else seems so damn interesting in comparison!
<fullermd> Well, I've got this project you could do some work on...  would cure that little problem RIGHT up   :p
<schierbeck> zzzzzZZZzzz
<schierbeck> huh.. what?
<schierbeck> :)
<jelmer> :-)
<schierbeck> jelmer: have you checked out my additions to asabil's whoop-cake awesome work?
<schierbeck> http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/viz-tags
<jelmer> not yet
<schierbeck> it's on the team repo, so you guys can write to it
<jelmer> thanks, will have a look
<schierbeck> :)
<asabil> schierbeck: you can pull from my branch
<asabil> the colour is yellow now
<schierbeck> cool!
<schierbeck> asabil: that looks great! i've merged it into the ~bzr-gtk branch
<schierbeck> you should be able to pull
<jelmer> schierbeck: ? Your branch you mean?
<schierbeck> http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/viz-tags
<Bwoaas> Hi all. I have a question regarding 'commit --local' in 0.90.0. When I use it, I keep getting conflicts, and now I am wondering if I am using it in the correct way.
<Bwoaas> Currently I do:
<Bwoaas> bzr co sftp://[snip]
<Bwoaas> bzr ci --local
<Bwoaas> bzr ci
<Bwoaas> and this is where I get conflicts
<asabil> schierbeck: can you pull again please ?
<schierbeck> asabil: sure
<asabil> not very sure if it looks better
<asabil> fell free to test it
<asabil> also maybe you want to delete the tag that I added and forgot to remove :
<asabil> :D
<asabil> the Woot tag
<schierbeck> cool!
<schierbeck> the holes could be a bit bigger, though
<schierbeck> jelmer: new patch sent to the ml, it's pretty trivial
<asabil> schierbeck: they don't look nice when bigger
<asabil> maybe you can try
<schierbeck> ok
<schierbeck> asabil: okay, i've made them a bit larger
<schierbeck> pull them in
<asabil> yep that's better :D
<schierbeck> do you think we can adjust the position of the hole?
<schierbeck> it's just a tad too high
<asabil> I think it looks perfect to me
<asabil> it is right in the middle
<schierbeck> yeah, could be i'm wrong -- such things depend on the screen and whatnot
<asabil> oO how can it be high ?
<schierbeck> asabil: many such things are psychological -- sometimes you need to bend things to make them look even
<asabil> :/
<schierbeck> :)
<asabil> oh and btw, I am not sure you needed a bzr merge
<asabil> you could have used bzr pull
<schierbeck> nah, you forgot to pull my merger
<schierbeck> i tried
<asabil> because there was no divergence
<schierbeck> look at the graph -- i had already merged with your branch once, hence there was a revision in my branch that wasn't in yours
<asabil> oh ok sorry
<asabil> didn't notice
<schierbeck> np :)
<ubotu> New bug: #178108 in bzr-svn "Implement SvnRepository.find_branches()" [Wishlist,Fix committed] https://launchpad.net/bugs/178108
<schierbeck> asabil: do you think the branch is ready to be merged into trunk?
<asabil> schierbeck: yep, I don't see any big issue
<schierbeck> then i'll make a merge request
<asabil> cool :)
<asabil> next time I might make the tags corner rounded :D
 * asabil is a bling addict
<schierbeck> asabil: i thought about it, too -- it would be cool
<schierbeck> btw, sign up for the mailing list
<fullermd> And it should be a cube!  That you can spin!
<asabil> schierbeck: the ML is too high traffic for me
<asabil> schierbeck: I was subscribed
<asabil> fullermd: lol
<schierbeck> it's not that high traffic atm...
<asabil> ok ok I will subscribe again
<jelmer> it's about 40 messages per month these days
<lifeless> jelmer: hi, sorry I haven't gotten you on pqm yet
<jelmer> 'morning lifeless
<jelmer> lifeless: no hurry; would be nice to be able to use pqm at some point though
<lifeless> jelmer: I'm in London this week; so we can chat in the same timezone (FSVO same)
<jelmer> ah, ok
<asabil> schierbeck: I am subscribed
<asabil> to bazaar@lists.....
<schierbeck> nah, it's bzr-gtk@lists.canonical.com
<asabil> ah oki
<asabil> done
<welterde> is there a command to view the gpg-signature of a commit?
<jelmer> welterde: not yet afaik
<welterde> jelmer: hmm... how strong is the authentication of the commits? eg. do they depend on a hash of the commit-data, on the previous commits?
<welterde> (like git for example)
<jelmer> welterde: afaik both
<welterde> hmm.. so manipulating a older revision would be detected?
<jelmer> yes
<jelmer> at the moment, there isn't any functionality to check signatures though
<welterde> but gpg-signatures are checked afair, or not?
<jelmer> I don't think they are either
<welterde> ah.. is an extra plugin
<lifeless> welterde: commit signatures do not transitively verify older history
<lifeless> welterde: this is deliberate
<lifeless> welterde: as it allows partial history environments to be verified
<yacc> Just wondering, is it possible to store the whoami value on a per project basis?
<lifeless> sure; you can probably set it in branch.conf; or url based in locations.conf
<welterde> lifeless: so no protection against a manipulated bzr branch?
<lifeless> welterde: uh, sure there is protection; just sign the commits for the history as well
<welterde> hmm... yeah... but besides that there is none?
<lifeless> I'm not sure what you're getting at
<welterde> if someones stops by and manipulates the unsigned history, that wouldnt be detected, right?
<welterde> (manipulates in a way the checkout changes)
<welterde> does bzr leak ip-addresses on any operation?
<lifeless> welterde: 'leak'?
<welterde> lifeless: like, being noted somewhere
<welterde> inside of commits or something like that
<lifeless> it may record them in your !/.bzr.log; and the commiter name is derived from your username and hostname by default
<welterde> which can be changed with bzr whoami
<lifeless> right
<welterde> lifeless: but signing one commit doesnt automaticly "sign" all of the commits before :/
<lifeless> right
<lifeless> you can bzr sign-my-commits though if you haven't been signing them
<welterde> and when the person, of whom the commits are, is not reachable?
<welterde> thus cant sign his commits?
<welterde> lifeless: and can i sign commits which just have a name?
<welterde> eg. from a cvs-import
<lifeless> sure; I'm off to dinner now, have fun
<Peng> welterde: You might also want to change your bazaar.conf/locations.conf/branch.conf to require signatures. See the docs.
<welterde> Peng: yeah... know that
<Enquest> is there a way to get some stats out of bazaar... Like how many lines of code has been changed the last day or period?
<james_w> Enquest: apart from 'bzr info' there is nothing that I know of.
<Enquest> maybe that would be a cool thing to get into it.
<james_w> However the example you mention could be approximated by piping something like 'bzr diff -rdate:yesterday' to diffstat
<james_w> I agree it would be interesting. It would work very nicely as a plugin I expect.
<beuno> Enquest, and there is a stats plugins which shows mostly per-user stuff:  http://bzr.arbash-meinel.com/plugins/stats
<elmo> Copying repository content as tarball...
<elmo> bzr: ERROR: Tags not supported by BzrBranch5('file:///home/james/scratch/trunk/'); you may be able to use bzr upgrade --dirstate-tags.
<elmo> why does bzr hate me?
<fullermd> It's your shoes.
<elmo> wtf
<elmo> if I rsync the entire dir, and bzr branch locally it works
<elmo> bzr makes me CRY
<Peng> elmo: Bzr version? Smart server? Shared repo?
<fullermd> Smart server, I suspect.
<elmo> bzr 1.0, bzr+ssh (so I guess smart?), and yes, shared repo I think
<fullermd> An incarnation of bug 173002.
<ubotu> Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,New] https://launchpad.net/bugs/173002
<Peng> Ah.
<Peng> Does that affect bzr+http too?
<fullermd> I presume it affects bzr+anything.
<elmo> shall I followup to the bug?
<fullermd> I dunno why your bzr 1.0 would try to make a branch5 branch, though.
<fullermd> It should go with the default, which is branch6.
<fullermd> Please.
<Peng> You may have been the person who said "no" last time I asked, but is there an easy way to "upgrade" from branc6 to branch5?
<Peng> branch6*
<elmo> I didn't create the repo on the other end
<fullermd> You can pull.  It may even not bother giving you an error if there are no tags.
<dysinger> Heh! morning.
<dysinger> Anyone in here on OS X Leopard? (I presume most of you are on Ubuntu/Debian.)
<dysinger> Jelmer I updated the wiki page several times last week.  I never did get it 100% right.  Hopefully I can keep bugging people on Leopard to try it out....
<dysinger> (it being bzr-svn)
<elmo> bah.  sorry, I somehow ended up on gutsy bzr instead of 1.0
<elmo> 1.0 works
<fullermd> Well, 1.0 works by coincidence.
<fullermd> It happens to use branch6 in its default format, so you don't hit the same problem.
<Peng> God, Canonical owns our souls. Bazaar, Ubuntu, Launchpad...
<fullermd> It's till a bug that it doesn't preserve the remote format.
<elmo> fullermd: ah, ok - so still follow up?
<dato> Peng: and that is ontopic how?
<Peng> dato: It's not. :)
<fullermd> He's fishing for bribes to keep quiet about it.
<fullermd> Maybe the common criticism is wrong; bzr needs MORE format changes, to keep those sort of bugs in the forefront and high on the priority stack   ;)
<schierbeck> jelmer: ping
<ubotu> New bug: #184898 in bzr "AttributeError: 'NoneType' object has no attribute 'abort'" [Undecided,New] https://launchpad.net/bugs/184898
<welterde> are gpg-signatures pushed yet?
<welterde> *over existing non-signed commits
<BasicOSX> Is there a way to test bzr's email plugin? I think my upstream smtp server is rejecting relaying, but I want to confirm. Some sort of debug output from the plugin?
<james_w> BasicOSX: you could look in ~/.bzr.log
<igc> morning
<luislavena> hello everybody.
<luislavena> is there a way (simpler) to change the commit messages? (4 or 5 revisions)
<aklaver> I asked yesterday about the location of the latest debs. Set my repositories to PPA. The problem is there does not seem to be a *.deb for Dapper.
<jelmer> dysinger: thanks for the wiki updates
<dysinger> jelmer np - I just wish it worked perfectly -
<jelmer> dysinger: what's not working?
<dysinger> for some reason ssl svn access through bzr dosen't work
<dysinger> neon installs, svn 1.5 installs, svn 1.5 + ssl works
<dysinger> but not bzr-svn ssl
<jelmer> even using the svn+https:// prefix?
<dysinger> n
<dysinger> I am just hoping for more people trying it soon.
<dysinger> It dumps out of python.
<jelmer> oh, what error?
<dysinger> some stack trace - I didn't study it closely.  I can go back to it soon and give specifics - it's nothing that was real clear to me what the problem was.
<dysinger> You can see from the wiki, I am using bzr-svn "stable" repo - is this ok?
<jelmer> dysinger: yeah, "stable" is just a symlink to the 0.4 branch
<jelmer> dysinger: seeing the backtrace may help debug this problem
<dysinger> ok hold on 2 minutes jelmer, i'll get it.
<jelmer> ok
<dysinger> I am installing again fresh
<dysinger> I spent time reading through the svn/neon INSTALL docs
<dysinger> so I think I have that part right
<dysinger> I think this is some sort of problem with Apple's python or something.
<jelmer> if it'
<jelmer> s giving you a python backtrace, chances are it may be a bzr-svn bug
<dysinger> ah ok
<dysinger> OK I have svn 1.5 + neon installed with openssl support - all check-swig-py tests pass.  svn --version reveals 1.5 with https support.  I can checkout https://svn.collab.net/repos/svn/trunk with svn 1.5 no problem.  No for the stack dump on bzr-svn
<dysinger> So just like it says in the wiki bzr checkout --lightweight http://svn.collab.net/repos/svn/trunk test works
<dysinger> jelmer notice no ssl
<dysinger> one sec and running ssl
<dysinger> jelmer I get
<dysinger> bzr checkout --lightweight \
<dysinger> >   https://svn.collab.net/repos/svn/trunk test
<dysinger> Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285.
<dysinger> Abort trap
<dysinger> The apple core dump pop up gives me this
<dysinger> http://pastie.caboo.se/141720
<dysinger> that's all - I don't know what to do know.
<dysinger> now
<dysinger> s/know/now/g
<dysinger> lolz
#bzr 2008-01-22
<dysinger> jelmer so I updated the wiki again with details
<dysinger> it _almost_ works on leopard - just not if you want svn+ssl
<Verterok> moin
<jelmer> re
<jelmer> dysinger: ok, that's not a bzr backtrace but a python-subversion one
<dysinger> hmmm
<dysinger> ok
<jelmer> dysinger: does "bzr branch" work with https:// ?
<dysinger> one sec
<dysinger> no same error on ssl
<dysinger> I wonder why it works with non-ssl and python-subversion
<jelmer> it looks like it may be a bug in the python bindings for the function that asks whether you would like to accept a specific SSL certificate
<dysinger> strange.  I already accepted the cert permanently earlier using straight svn
<jelmer> this function gets called before svn itself I think
<jelmer> dysinger: you may want to try commenting out line 54 of transport.py
<dysinger> sure
<dysinger> in svn ?
<dysinger> oh ok in bzr-svn
<dysinger> bummer http://pastie.caboo.se/141749
<dysinger> now it looks like libsvn_diff ???
<dysinger> it's calling libsvn_ra_local too
<dysinger> that's for a file:/// scheme
<dysinger> oh nevermind
<dysinger> I am reading too much into the stack without knowing python.
<jelmer> dysinger: are you sure line 52 is commented out?
<jelmer> sorry, 54
<dysinger> you said 54
<dysinger> y 54 #        svn.client.get_ssl_server_trust_file_provider(pool),
<jelmer> whoops
<jelmer> can you enable line 54 again and comment out 46 and 47?
<dysinger> the providers += lines ?
<dysinger> woot it is working.... :8
 * dysinger crosses fingers
<jelmer> ok, looks like it's time to file a bug in the subversion bug tracker
<dysinger> woot at least it works.
<dysinger> I'll just keep installing bzr-svn stable and svn 1.5 trunk from scratch until it's fixed.
<dysinger> it worked
<Verterok> igc, poolie: hi
<Verterok> reading the irclogs I recently found guillaumebokiau problems with the 10.4 dmg (ppc)
<Verterok> I'm trying to build it as universal, but I can't test it because I don't have a intel mac
<igc> hi Verterok
<igc> I can help with that
<Verterok> great! :D
<igc> I'm happy to test it on 10.4 on Intel on my laptop
<Verterok> do you have the developer tools installed?
<igc> hmm - not sure
<igc> I do have MacPorts installed from memory so that means yes?
<Verterok> let me check
<igc> and make and gcc both exist on my path fwiwi
<Verterok> http://www.macports.org/install.php says you should
<Verterok> maybe you can build it as universal, it's pretty easy using my scripts ;)
<igc> sure
<igc> where do I start?
<Verterok> if you have time to do it, of course :)
<igc> I can fit it in :-)
<Verterok> bzr branch http://freeshells.ch/~guillo/code/bundle-10.4/
<Verterok> and follow the building instructions ;)
<Verterok> the versions I'm using for the build are: bzr == 1.1, bzr-rebase == 0.3, bzrtools == 1.1.0, pycrypto == 2.0.1, paramiko == 1.7.1 and bzr-email == trunk
<igc> ok, I have the branch
<igc> I'll ping you if I have any questions
<Verterok> thanks a lot!
<poolie> Verterok, cool, thanks!
<poolie> igc, spiv, please work out about your trip...
<Verterok> poolie: happy to help, and write some python (instead of java) :D
<spiv> poolie: chatting now :)
 * poolie stops nagging
 * igc lunch - back later
<GoClick> Is there an official way to voice your support for something? I would REALLY appreciate a more complete textmate integration bundle for bazaar.
<GoClick> But I'm not programmer enough to assist with the project
<AfC> Verterok: bzr-eclipse is using the XML plugin, right?
<AfC> (asking only because https://blueprints.launchpad.net/bzr-eclipse/+spec/bazaar-java-client is kinda vague about it)
<Verterok> AfC: yes
 * AfC tries to find that.
<Verterok> actually the java lib under the hood is usingt it
<Verterok> AfC: you are right, I need to write a wiki page about this and link to the blueprint
<Verterok> Also, if you have any question, I'ld be pleased to answer
 * AfC has been studying Eclipse's platform. I've seen some crazy code bases in the past, but yikes.
<AfC> Nutso project of the week: Java editing in vi using Eclipse as a back-end http://eclim.sourceforge.net/
<Verterok> I look at it some time ago, it start a headless eclipse...who said vim is a lightweight editor? :)
<AfC> I've been trying to figure out how much of Eclipse can be used headless. It would seem "quite a lot"
<Verterok> I suppose all non-ui plugins
<AfC> ... the Anjuta guys want to add Java functionality; my suggestion to them was to see if they could hook into Eclipse for the introspection they'd need.
<AfC> Verterok: yeah. The question is are things like code-completion and hierarchy & outline abstracted out, or buried in the UI code.
<AfC> Anyway, off topic for this channel, sorry. I thought I'd have another poke at bzr-eclipse to see what I could learn by comparison.
<Verterok> private?
<AfC> Go ahead
 * AfC is getting ready to go out for coffee
<minghua> Is there a way to delete a versioned directory from a tree, and claim "don't touch this directory ever again", so that future merges won't generate conflicts regarding this directory?
<minghua> What I'm doing is complete rewriting a part of a project (the debian/ directory), while upstream is still making changes to that part occasionally.
<poolie> minghua, i think the cleanest way would be to rename theirs to eg debian.upstream
<poolie> and then make a new directory for yours
<minghua> Ah, so renaming is better than deleting, makes sense.
<minghua> poolie: Will try that, thanks!
<poolie> you're welcome!
<poolie> bzr rename support ftw :)
<igc> Verterok: looks like I'm missing some stuff (like setuptools). I want to wrap up some other work first so I'll have another go later today or tomorrow.
<Verterok> oh, I missed that :P
<Verterok> igc: thanks again!
<Verterok> I'm trying to fix my Xcode installation, it seems that 2.5 kill my libtool :(
<Verterok> igc: for building the mpkg, the deps are: setuptools == dev, py2app >= 0.3.6, bdist_mpkg >= 0.4.3. easy_install install all other dependecies.
 * Verterok heading to bed...
<Verterok> seeya!
<igc> seeya
<robsta> hi
<robsta> is it possible to migrate a project from one svn repo to another, using bzr-svn?
<TFKyle> robsta: I think tailor (http://wiki.darcs.net/index.html/Tailor ) would be a better fit for doing that, no idea how easy it'd be with bzr-svn though
<robsta> TFKyle: does tailor work without file-system access?
<TFKyle> robsta: yep
<TFKyle> (actually, if the server is subversion 1.4 or newer I think there's svnsync or something similar that does that)
<TFKyle> (more efficiently than tailor or bzr-svn I believe)
<robsta> looks like i'm asking the right people :)
<robsta> will check it out
<TFKyle> hmm, on the other hand: "You should not commit to, or make revision property changes in, the destination repository by any method other than 'svnsync'. In other words, the destination repository should be a read-only mirror of the source repository." in svnsync help init, not sure why though, might be reasonable to if you don't need to sync anymore afterwards
<AfC> robsta: bzr-svn is very powerful, but keep in mind that any non-native tool doing a transformation will always bear the risk of being lossy in some manner.
<AfC> tailor also counts as a non-native tool in this regard.
<AfC> robsta: can't you just `svn_dump` or `svnadmin dump` or some such?
<robsta> AfC: doesn't that require file-system access?
<robsta> well, on the source machine i have it
<AfC> robsta: (sorry, yes it does. I was making an assumption)
<robsta> svnsync wants special hooks set, can i do that via DAV?
 * igc night all
<Peng> Why not take this opportunity to switch to bzr? :)
<AfC> Peng: good show
<robsta> because garage.maemo doesn't support it
<yacc> Just wondering, can one host a complete project on launchpad? (Basically, do I need a sourceforge project first, or can I just host it on launchpad?)
<TFKyle> yacc: yep (well, partially - lp doesn't do web hosting apart from what launchpad provides itself)
<yacc> TFKyle: Well, that shouldn't be the biggest issue here ;)
<yacc> Ok, now I just need to refactor that pile of dung, so that my face does not flash red when thinking about publishing the code :)
<awilkins> Anyone want to talk about nested tree support?
<lifeless> LarstiQ: ping ^
<awilkins> Incidentally, are the Pyrex extensions used on Windows?
<lifeless> sure
<awilkins> Yeah, I just spent those 9 minutes installing Pyrex / MinGW and find out the .pyd files are there already :-)
<awilkins> Ah well, at least if I use a dev branch it'll run fast....
<lifeless> ;)
<lifeless> hi thumper
<thumper> lifeless: hi
<thumper> lifeless: how goes London?
<lifeless> cool
<jelmer> are there any functions for parsing "bugs" revision properties yet?
<lifeless> not sure
<ubotu> New bug: #185072 in bzr "checkout MemoryError" [Undecided,New] https://launchpad.net/bugs/185072
 * jelmer is trying to spend 5 spare minutes implementing a "bugs" tab in bzr viz
<lifeless> cool
<lifeless> how is larstiq these days?
<AfC> heh. I just spent "5 minutes" on something. 5 hours later...
<awilkins> Yeah, it always happens when you have a deadline for something else too
<awilkins> "Oh, if I spend 5 minutes implementing foo, it'll make doing bar a lot faster..."
<AfC> Well I have a deadline for sleep. See ya
 * awilkins slurps coffee
<awilkins> I may take a nap though, wifey kept me up snoring all night
<jelmer> lifeless: he's back on IRC but a bit busy with other things afaik
<jelmer> ok, little bit more than 5 minutes :-)
<jelmer> http://samba.org/~jelmer/bzr/bzr-gtk-bugs.png
<jelmer> hmm, likewise it should be possible to select the bug you've fixed using gcommit
<jelmer> lifeless: There doesn't happen to be some pygtk app that allows browsing launchpad bugs ?
<lifeless> there is bughelper, which is cli
<jelmer> ah, ok
<mtaylor> NoSuchRevision: KnitRevisionStore(VersionedFileStore('file:///home/mtaylor/src/ndb-connectors/.bzr/repository/')) has no revision mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x
<mtaylor> I was trying to do a bzr diff
<ubotu> New bug: #185086 in bzr "No easy way to access "bugs" revision property" [Wishlist,Triaged] https://launchpad.net/bugs/185086
<jelmer> mtaylor: Is this a repository originally imported from svn?
<mtaylor> jelmer: nope
<mtaylor> jelmer: this is a pure bzr repos
<mtaylor> so I also now get this, when I try to branch that branch to somewhere else:
<mtaylor> bzr branch devel develnew
<mtaylor> bzr: ERROR: The branch devel has no revision None.
<jelmer> mtaylor: which repository format?
<mtaylor> Shared repository with trees (format: dirstate or dirstate-tags or knit)
<lifeless> mtaylor: can you do a bzr check ?
<mtaylor> bzr check
<mtaylor> bzr: ERROR: Revision {mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x} not present in "revisions".
<lifeless> do you use NFS ?
<mtaylor> nope. this is on my laptop
<mtaylor> xfs
<lifeless> ok, bizarre
<lifeless> so here is what bzr hinks is going on
<mtaylor> this is not the first time this has happened to me
<lifeless> .bzr/repository/revisions.kndx does not list mtaylor...zz7x
<mtaylor> ok
<lifeless> but .bzr/branch/* does
<lifeless> are you using rsync to move data around or anything like that?
<mtaylor> nope. just normal bzr
<lifeless> if this is happening repeatedly, something is causing it not cosmic rays :)
<lifeless> you don't use 'rspush' ?
<mtaylor> nope. just push and pull and branch over bzr+ssh
<lifeless> was this revision the same one that the problem occured in before?
<lifeless> and are you able to upgrade to packs :)
<lifeless> the only likely thing I can think of is:
<mtaylor> I can certainly try  - but no, the last time this happened I just created a new repos, branched from pushed branches and manually added the diffs back
<jelmer> mtaylor: have you run xfs_fsr recently?
<mtaylor> jelmer: no. should I?
<jelmer> mtaylor: no, but apparently that could be a cause for corruption
<mtaylor> ah.
<jelmer> I see another report on the mailing list about corruption on XFS
<mtaylor> I did have my laptop power off due to battery death on the plane the other day
<jelmer> https://lists.ubuntu.com/archives/bazaar/2007q3/029036.html
<mtaylor> I would be very sad if that caused something to not be written to disk
<jelmer> It seems somewhat likely to me this is related to XFS since it's not that commonly used and I can't recall any corruption reports in the last year except from the one I just linked to
<jelmer> that may be a somewhat premature conclusion, though
<mtaylor> yeah.
<mtaylor> would it be helpful at all for me to tar up my repo and send it to someone?
<mtaylor> lifeless: should I be using packs for everything now?
<mtaylor> so, now I'm also getting this:
<mtaylor> AttributeError: 'NoneType' object has no attribute 'as_dict
<mtaylor> when I try to pull
<mtaylor> it seems to be in:
<mtaylor>  File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 445, in _parse_info
<mtaylor>     return read_stanza(info_file.readlines()).as_dict()
<mtaylor> lifeless: would a copy of my repos be helpful? it's a public project
<ubotu> New bug: #185095 in bzr-gtk "gcommit should provide ability to mark bugs as fixed" [Wishlist,Triaged] https://launchpad.net/bugs/185095
<lifeless> hi mtaylor sorry I was distracted by the boss :)
<mtaylor> lifeless: darn bosses
<lifeless> mtaylor: yes, packsa re good kthxbye
<mtaylor> :)
<lifeless> so your bug the only ting I can think of is:
<lifeless> append(revisions.knit)
<lifeless> append(revisions.kndx)
<lifeless> write(branch_data)
<lifeless> poweroff -> branch_data committed, revisions.knit not
<mtaylor> ahhh
<lifeless> AIUI xfs is very much against writing data to disk
 * mtaylor . o O ( 2pc between branch_data and revisions.knit )
<mtaylor> lifeless: that sounds reasonable
<mtaylor> lifeless: anyway you can think of to recover from this?
<lifeless> uhm
<CardinalFang> Custom tiny script to roll back that one change?
<lifeless> mtaylor: what format branch is it ? (bzr info -v and look for Branch Format)
<mtaylor> lifeless: that gives me a traceback
<mtaylor>   File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 445, in _parse_info
<mtaylor>     return read_stanza(info_file.readlines()).as_dict()
<mtaylor> AttributeError: 'NoneType' object has no attribute 'as_dict'
<lifeless> less .bzr/branch/format
<mtaylor> Bazaar Branch Format 6 (bzr 0.15)
<lifeless> oh!
<lifeless> ls .bzr/branch/lock
<lifeless> and .bzr/repository/lock
<lifeless> we have at least one latent bug here
<mtaylor> mtaylor@solace:~/src/ndb-connectors-borked/devel$ ls .bzr/branch/lock/
<mtaylor> held
<mtaylor> mtaylor@solace:~/src/ndb-connectors-borked/devel$ ls ../.bzr/repository/lock/
<mtaylor> held
<lifeless> ok, ls in the held dir too ?
<mtaylor> info
<lifeless> in both ?
<mtaylor> yes
<lifeless> ok, can you please file a bug about that backtrace
<mtaylor> yes.
<lifeless> you can get the whole trace from .bzr.log
<lifeless> separately
<mtaylor> which one?
<mtaylor> is this the bzr info -v produces a backtrace ?
<lifeless> bzr info -v failing
<mtaylor> ok
<lifeless> now, bzr thinks that this tree is locked
<mtaylor> oh
<mtaylor> well that's silly
<lifeless> its consistent with a poweroff failure and changes not being flushed to disk
<lifeless> bzr break-lock
<mtaylor>     return read_stanza(info_file.readlines()).as_dict()
<mtaylor> AttributeError: 'NoneType' object has no attribute 'as_dict'
<lifeless> should let you break them; if it doesn't (and it may not as the info -v failure is indicative of a problem) we will brek them by hand
<lifeless> rm the 'held' directories. That will let us start mutating the tree
<lifeless> now, we need to figure out the most recent commit
<lifeless> install the 'heads' plugin
<lifeless> (most recent commit that has been committed :)
<lifeless> we'll want to work on a copy of the tree not the tree itself.
<mtaylor> ok
<mtaylor> copy of the branch or copy of the whole repos?
<mtaylor> oh. nm... I've got a backup, I just tarred it up a second ago
<lifeless> k
<lifeless> now
<mtaylor> looking for heads plugin
<mtaylor> k gotit
<dennda> is it me or is the latest bzr you can get from your repo much faster than the one in ubuntus repos?
<mtaylor> dennda: the one in ubuntu is old
<mtaylor> dennda: it's not just you
<dennda> boy that is good news!
<mtaylor> lifeless: ok. I' ve done all of that
<mtaylor> lifeless: heads doesn't show my devel branch at all
<lifeless> I think you --all
<lifeless> *need*
<mtaylor> yup
<lifeless> now find a rev id you want to use
<lifeless> init a new branch (can be in the same repo if you like)
<lifeless> bzr pull -r revid:REVID ../oldbranch in the new branch
<lifeless> this will give you a healthy branch, and we need to just recover your most recent commit
<mtaylor> lifeless: it shows two entires for branch "devel"
<mtaylor> both of them show as (dead) revisions
<lifeless> thats because the graph is incomplete
<mtaylor> ok
<lifeless> are they both yours?
<mtaylor> yes
<mtaylor> and one of them is the one I would want
<lifeless> good
<lifeless> thne do the above
<mtaylor> bzr: ERROR: Revision {mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x} not present in "revisions".
<ubotu> New bug: #185103 in bzr "bzr info -v produces a traceback" [Undecided,New] https://launchpad.net/bugs/185103
<lifeless> that was in heads ?
<mtaylor> yes
<lifeless> hrm
<mtaylor> but was listed as dead
<lifeless> ok, lets try a different approach
<lifeless> :q
 * mtaylor is having fun with bzr today!!!
<lifeless> python
<lifeless> import bzrlib.repository
<lifeless> r = bzrlib.repository.Repository.open('.')
<lifeless> r.lock_read()
<lifeless> heads =  r.get_graph().heads(r.all_revision_ids())
<mtaylor> bzrlib.errors.NoRepositoryPresent: No repository present: "file:///home/mtaylor/src/ndb-connectors-borked/devel/"
<lifeless> use .. then :)
<mtaylor> oh, right
<mtaylor> du
<mtaylor> ok. I have a heads set
<lifeless> mtaylor: how big is it, and is ...7x in it ?
<mtaylor> lifeless: there are 7 elements, and no, ...7x is not there
<lifeless> good :)
<lifeless> ok, we can look at each commit with:
<lifeless> print r.get_revision(revid).message
<lifeless> one of the elements should be the previous commit on the damaged branch
<mtaylor> yes. there it is
<mtaylor> mtaylor@mysql.com-20080120223107-b1c4f5d4bez3g38h
<lifeless> ok, init another branch, pull that revid into it with the instructions from above
<mtaylor> I'm still getting the bzr: ERROR: Revision {mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x} not present in "revisions".
<lifeless> ok
<lifeless> echo '0 null:' > .bzr/branch/last-revision
<lifeless> then try
<fullermd> If you do it in the same repo, couldn't you just 'pull -rfoo .', and save possibilities of getting confused by the b0rked branch?
<lifeless> fullermd: yah
<mtaylor> ok. I tried pull -rfoo .
<mtaylor> and I got: bzr: ERROR: Revision {mtaylor@mysql.com-20080120222208-5vy3xpyzb0pl7lcj} not present in "44/configure.in-20070228020914-u2pk759xg7thauwf-13.kndx".
<mtaylor> and I tried echo '0 null:' > .bzr/branch/last-revision
<mtaylor> in the new branch and then pulling and that didn't work
<mtaylor> should I try echo '0 null:' > .bzr/branch/last-revision in the devel branch?
<jrydberg_> jelmer: if i use bzr-svn, do i get merge tracking? :)
<jelmer> jrydberg_: Yes
<jrydberg_> jelmer: how do you do that?
<jelmer> jrydberg_: bzr-svn stores the non-lhs parents in a svn property
<jelmer> well, not the parents itself but the parent revids
<jrydberg_> jelmer: cool.  do i still have to patch the python bindings?
<jelmer> jrydberg_: yes, unless you are on Debian Sid/Lenny or Ubuntu >= gutsy
<lifeless> mtaylor: I'm smeelling more and more data issues here
<lifeless> mtaylor: is the copy on launchpad healthy ?
<mtaylor> lifeless: yeah - I'm repulling that right now
<mtaylor> lifeless: you think just use that an apply individual changes by hand?
<lifeless> mtaylor: also, *really* move to packs: the non-append nature of that makes it much more robust against silly file systems (though not imune)
<lifeless> I think use that and copy your working tree over the top
<mtaylor> lifeless: ok. do I need to do anything to upgrade my lp repos?
<lifeless> bzr upgrade sftp://bazaar.launchpad.net ..../
<lifeless> sftp is important
<mtaylor> for the upgrade?
<mtaylor> oh, because lp doesn't have recent bzr
<lifeless> mtaylor: no, because bzr+ssh doesn't have an upgrade verb today :)
<LarstiQ> lifeless: 'meh' sums it up currently
<LarstiQ> awilkins: you wanted to talk?
<guillaumebokiau> Unable to obtain lock .bzr/checkout/lock
<guillaumebokiau> what now ?
<guillaumebokiau> I restarted the computer to no luck.
<guillaumebokiau> I deleted /held/ to no luck
<awilkins> LarstiQ: I was wondering how the nested trees were doing :-)
<jelmer> does "bzr break-lock" help?
<guillaumebokiau> ah, yes, thx
<LarstiQ> awilkins: at least from my side, not a lot of movement lately. But got an offer to tests on some reallife machines, so I'll be wanting to get back at it. Have to spend time in airports tomorrow, we'll see.
<guillaumebokiau> but when i commit now i get this :
<LarstiQ> awilkins: so the status is roughly, they exist but don't try to do too much with it if you're not willing to deal with breaking
<awilkins> LarstiQ: Ah, ok, I have some reasonably substantial VB6 projects with lots of use-of-common-library-but-not-linked-compiled-in
<guillaumebokiau> Committing to: /Users/guillaumebokiau/Sites/xpattern-1.0/
<guillaumebokiau> modified textpattern/lib/txplib_parse.php
<guillaumebokiau> -------------- This line and the following will be ignored --------------
<guillaumebokiau> modified:
<guillaumebokiau>   textpattern/lib/txplib_parse.php
<guillaumebokiau> unknown:
<guillaumebokiau>   bzr_log._4LcnW
<guillaumebokiau>   css/articles.css
<guillaumebokiau>   css/default.css
<awilkins> LarstiQ: So more testing material :-)
<guillaumebokiau>   textpattern/.DS_Store
<guillaumebokiau>   textpattern/config.php
<guillaumebokiau>   textpattern/publish/newtaghandlers.php
<guillaumebokiau> ~
<guillaumebokiau> ~
<guillaumebokiau> ~
<guillaumebokiau> ~
<guillaumebokiau> ~
<guillaumebokiau> ~
<LarstiQ> guillaumebokiau: woha, easy there
<guillaumebokiau> ~
<guillaumebokiau> ~
<luks> eek
<guillaumebokiau> ~
<guillaumebokiau> ~
<guillaumebokiau> "bzr_log.Q_aXL4" 13L, 275C
<guillaumebokiau> and it freezes or sthg
<guillaumebokiau> sorry for your ears :)
<LarstiQ> guillaumebokiau: please use a paste service if you got more than a few lines to show
<awilkins> You're lucky this channel doesn't kick for excess flood
<LarstiQ> awilkins: good, good :)
<LarstiQ> awilkins: does code move across those subtree boundaries often?
<guillaumebokiau> will do
<awilkins> LarstiQ: I think the commonest case is where I patch the library a bit and want some of the changes but not all pushed to the main branch
<awilkins> LarstiQ: Or maybe all
<LarstiQ> ah, ok
<awilkins> I've tried both common approaches - svn:externals and svn cp
<LarstiQ> awilkins: you're using svn as a backend?
<awilkins> awilkins: I'm using svn as my production VCS at present
<LarstiQ> and you'd want to keep it that way?
<awilkins> LarstiQ: I'm experimening with bzr because some of the things I'm having to do are very slow now
<awilkins> LarstiQ: The big one is this project where I'm having to do a lot of merging - in an automated manner, with possible trunk > branch merges followed by branch > trunk merges
<LarstiQ> ok
<awilkins> LarstiQ: No nested trees in that one though, but I'm shuddering at writing it for svn ; the problem is it's for an Eclipse application and the bzr-eclipse plugin is rather ... green
<awilkins> I might actually want to leverage bzr anyway to make the branch management easier
<LarstiQ> hey Zindar
<guillaumebokiau> anyone available to help me with the problem?
<LarstiQ> awilkins: how early in the process would you feel comfortable testing stuff out?
<beuno> awilkins, you can file bugs for any bzr-eclipse features you'd like. The developer is fairly active, he just needs stuff to do  ;)
<LarstiQ> guillaumebokiau: when does it freeze? Did you write a commit entry and save it?
<guillaumebokiau> yes, a couple
<awilkins> LarstiQ: I can find some time to set up a bzr repo and import some branches into it for my projects and the common library, and trty nesting it.
<guillaumebokiau> It seems I can uncommit though.
<guillaumebokiau> would that help : uncommiting the last commit?
<LarstiQ> awilkins: cool. I'll ping you when I have a current branch then.
<LarstiQ> guillaumebokiau: why would you do that?
<guillaumebokiau> In case it was the last commit that caused a problem
<awilkins> LarstiQ: I tried to branch it from launchpad but I got no joy, soes it need an upgrade or somehitng?
<guillaumebokiau> but no, that doesn't seem to solve it.
<LarstiQ> guillaumebokiau: I'm confused as to what your problem is, could you explain it once more please?
<awilkins> LarstiQ: I think I filed a bug for that
<LarstiQ> awilkins: what did you try to branch?
<awilkins> bzr-svn
<guillaumebokiau> I try commiting. It then does that error code I posted above
<guillaumebokiau> and creates a log
<guillaumebokiau> well, i don't even know if it is an error code
<LarstiQ> awilkins: be sure to name the resulting branch something like 'svn', that is, don't leave the - in the plugin name or it will not be seen as a valid plugin.
<awilkins> LarstiQ: Ah, the replay branch, sorry
<LarstiQ> guillaumebokiau: what exact error?
<LarstiQ> awilkins: now you're out of my league and into jelmer's, I don't know that much about bzr-svn :)
<awilkins> LarstiQ: Nothing to do with nested trees
<LarstiQ> awilkins: not directly at least, it may be a consumer of them
<awilkins> LarstiQ: That would be a potential use case, since I have the source in an SVN repo at present
<lifeless> guillaumebokiau: can you comit if you do 'bzr commit -m " message here" ' ?
<guillaumebokiau> ah, maybe i forgot the message
<guillaumebokiau> will try
<awilkins> LarstiQ: And no immediate chance of changing that ; this is a government dept. and I only just managaed to convert them to SVN 2 years ago (from the "bung it on a shared drive and pray" method)
<guillaumebokiau> ok, that was it. stupid me
<awilkins> LarstiQ: For reference, they had been considering either CVS or Visual SourceSafe for 6 months....
<guillaumebokiau> thanks lifeless and LarstiQ
<LarstiQ> awilkins: ah yes, the government is always fun :)
<LarstiQ> guillaumebokiau: np
 * LarstiQ goes afk for a while
<jelmer> awilkins: there is no reason to be using the replay branch at the moment
<jelmer> it's still a work in progress and doesn't provide any advantages over using the 0.4 branch
<awilkins> jelmer: Is improved speed not an advantage?
<awilkins> jelmer: Particularly since (AFAIK) it doesn't support a horizon.
<jelmer> awilkins: the replay branch is a work in progress, it's not finished yet
<jelmer> awilkins: it doesn't provide any advantages yet
<awilkins> jelmer: Yes, fair enough, I wasn't expecting to use it in production, I just wanted to look at the source
<awilkins> jelmer: Working replay would be a major plus point for bzr over the likes of SVK, which has replay but it doesn't work on Win32
<jelmer> awilkins: replay != history horizon
<awilkins> jelmer: It makes a lot of difference on larger trees
<jelmer> awilkins: or is the advantage of using svn_ra_replay() over a bunch of svn_ra_update() calls really that big?
<awilkins> jelmer: Yes, replay is not horizon, but without horizon, taking the full history of an SVN branch is a very prolonged task without replay
<awilkins> jelmer: SVK has enormous CPU demands even on fairly small trees (a few thousand XML files)
<awilkins> And that's perl, it's supposed to be astounding at that sort of thing
<jelmer> awilkins: what makes replay so fast then? afaik the only thing you save is 1 roundtrip per revision
<awilkins> awilkins: I'm going to have to measure it now, aren't I :-)
<xif> So what's the deal with keyword substitution implementation in bzr?
<jelmer> xif: there is none
<xif> the best I could find was this brain-dump: http://bazaar-vcs.org/KeywordExpansion
<jelmer> xif: there is a specification, but nobody is working on implementing it at the moment
<jelmer> yep, that's the one
<xif> jelmer: hm, sucks, why not?
<xif> surely you bzrers can see how useful it would be!
<xif> can I write it in Python?
<jelmer> xif: yes, but there's other important things as well...
<awilkins> jelmer: svnsync uses replay and it's very quick ; SVK doesn't and it't horribly slow and eats loads of CPU time on the client  - my observations are a bit empirical but I find it impractical on large changesets.
<jelmer> awilkins: svk probably does more than just fetch the revisions though
<awilkins> jelmer: That's kinda the point ; I'm not sure what it's doing but it's just fetching one atomic commit (for a lot of files, thanks), either as diffs or whole revisions, and applying it to a local repository
<xif> jelmer: can I write, in Python, an extension that adds this feature?
<jelmer> xif: probably, although it may be necessary to make some changes to the core of bzr as well
<jelmer> xif: it's probably a good idea to bring it up on the mailing list
<xif> jelmer: hm, really?  all we're talking about is a script that runs just before the commit and does a regexp replace on committed files.
<jelmer> xif: it's harder than that. You also don't want "bzr status" to report those files as modified
<xif> I could implement it with svn hooks if I wanted to, without touching the svn codebase or even writing an extension.
<jelmer> or "bzr diff" to show the lines with the keywords on them as changes
<jelmer> awilkins: it would surprise me if replay had a significant impact on the speed of bzr-svn
<xif> all I want is that if I commit a file that contains "$Rev: foo$", foo would be replace by the current revision before the commit.
<jelmer> you may be able to do that using a pre-commit, but I'm not sure whether such a hook is allowed to change the working tree
<xif> jelmer: thanks.
<jelmer> xif: afaik there's no way to do so with svn
<awilkins> jelmer: Hmm ; I guess it's an idea that's sticking in my head because it takes 5 minutes of CPU time to sync a single revision consisting of 1MB of XML spread across 708 files in SVK..... it would be quicker to export the files locally and check them in there, for heavens sake. I shall have to try bzr-svn and see how it compares on the same tasks
<jelmer> awilkins: is SVK using svn_ra_do_update() and not just svn_ra_get_file() ?
<jelmer> (708 roundtrips per revision instead of 1)
<awilkins> jelmer: Doesn't explain why it's pegging the CPU for 5 minutes, but i'll look at the source
 * awilkins head pounds from having to read perl
<Treeform> how is TortoiseBZR shaping out? looking at the page its still below bata quality! Is that true?
<bronger> What is the difference between svn2bzr and bzr-svn?
<jelmer> Treeform: yeah, it's a proof of concept and there's nobody actively working on it
<jelmer> bronger: svn2bzr works on svn dump files and does't require a patch python-subversion
<jelmer> bronger: bzr-svn requires a patched python-subversion but is better tested, allows pushing back to Subversion and actively maintained
<bronger> Thanks, but what is the difference as far as the resulting branch is concerned?
<jelmer> not much
<jelmer> the one created with bzr-svn allows you to make changes based on it and push those changes back into svn
<bronger> The problem is that I cannot access the SVN repository as an admin, so I have no dump;  I wonder whether this means that I "lose" anything.
<jelmer> bronger: bzr-svn allows working with a remote svn repository
<jelmer> svn2bzr does not
<bronger> Mmmh ... good (for me).  So, svn2bzr is for real migration then, and of no value if you actually want to keep SVN?
<Odd_Bloke> bronger: I also believe I'm correct in saying that Debian and so Ubuntu ship the ready-patched bindings, so you wouldn't have to do it yourself on those cases.
<bronger> Odd_Bloke: Yes, at least branchin works nicely.
<bronger> Speaking about Ubuntu ... adding the package sources for the current version (taken from Bazaar's HP), I lost bzr-svn because it wanted an older version of bzr.  It was not included into the repository, too.
<jelmer> bronger: the up to date bzr-svn package is "deb http://samba.org/~jelmer/debian/ unstable/"
<jelmer> bronger: svn2bzr is just older
<Treeform> jelmer, thanks
<schierbeck> jelmer: what do you think about the fancy-tags patch?
<schierbeck> ready for inclusion?
<jelmer> sorry, haven't had time to look at it yet
<schierbeck> np
<bronger> jelmer: Thanks, works nicely!
<Verterok> moin
<poolie> hi
<Verterok> poolie: hi
<Verterok> jelmer: Hi, do you have a few minutes?. It's a about bzr-svn and OS X 10.4
<jelmer> Verterok, sure
<Verterok> great!
<jelmer> abentley: what are your plans for bundlebuggy? Is it still being actively developed or in maintainance mode until launchpad takes over?
<Verterok> jelmer: I spent the last two days trying to compile the svn python-bindings with XCode-2.5 (the latest version for 10.4)
<Verterok> (I'll add a Tiger section in the wiki page tonight)
<ubotu> New bug: #185180 in bzr "Better messages when upgrade fails" [Undecided,New] https://launchpad.net/bugs/185180
<Verterok> the main problem is that Xcode-2.5 kill the libtool shipped with 2.4
<Verterok> after installing libtool from macports all worked like a charm :)
<asabil> schierbeck: ping ?
<Verterok> all this introduction is to tell that I'ld like to build a pkg for svn-1.5 + bindings for OS X
<jelmer> Verterok, ah, that would be awesome
<jelmer> the number of people that has been trying to use bzr-svn on Mac OS X has surprised me
<Verterok> jelmer: a friend need bzr-svn features to keep in sync with a svn repo (hosted by his client)
<abentley> jelmer: active development
<jelmer> abentley: Cool, thanks!
<Verterok> jelmer: he found the build a limitation to his deployment needs (around 7 workstations need to work with bzr-svn)
<jelmer> Verterok: if there's anything I can help with, please let me know.
<Verterok> jelmer: I don't know where to look for instructions about how subversion is packaged for OS X
<schierbeck> asabil: pong
<asabil> schierbeck: did you merge the fancy tags crack to the baseline ?
<schierbeck> asabil: not yet, i need another core dev to vouch in
<Verterok> jelmer: (last question) bzr-svn needs a complete subversion install or with the libs+bindings is enough?
<jelmer> Verterok: libs+bindings is sufficient
<jelmer> Verterok: there doesn't appear to be packaging data in svn's svn
<Verterok> oh, great!
<asabil> oh oki
<Verterok> jelmer: thanks,  I'll neeed  to get a collabnet user a search inside collbnet documentation
<asabil> maybe we can poke someone schierbeck ?
<schierbeck> oh, i'm not sure if jelmer has time for it >:)
<Verterok> jelmer: (real last question :-))  the libs+bindings can live side by side with a previous svn, like 1.4.4?
<jelmer> Verterok: I don't think they can live together with bindings form an earlier version
<jelmer> schierbeck: Sorry, hopefully I can have a look tomorrow
<jelmer> I have an exam tomorrow that I still need to do some final preparation for
<Verterok> jelmer: ok, thanks a lot!. good luck with your exam!
<schierbeck> jelmer: me too
<schierbeck> sucks...
<awilkins> What is it that the Pywin32 package contributes to running bzr on Windows?
<poolie> awilkins, from memory, we use it to take file locks, manipulate the terminal
<poolie> understand errno values
<poolie> stuff like that
<awilkins> Hmm, I've been running without it ... I wonder if it's responsible for some of the errors I've been seeing
<poolie> igc, hi
<igc> hi poolie
<spiv> And mark files hidden, I think?
<poolie> awilkins, if it's said to be optional but it doesn't work without it, that would be a bug, one way or the other....
<poolie> igc, quick call?
<igc> poolie: 10 minutes ok?
<poolie> sure, call my mobile when you're ready?
<igc> sure
<poolie> have you seen jam?
<poolie> is he away this week?
<poolie> s//today
<poolie> he has been answering mail i guess
<spiv> Yeah, he even reviewed some of my patches.
<jelmer> man, fate is cruel. I have an exam on unit testing on the thursday of the Bazaar sprint :-/
<CardinalFang> I added a simple patch/bug.  ubotu should have mentioned it by now.  https://bugs.launchpad.net/bzr/+bug/185191
<ubotu> Launchpad bug 185191 in bzr "add mnemonic diff to "commit" info {with patch}" [Undecided,New]
<CardinalFang> Heh.
<awilkins> I swear that thing waits until it sees you in channel before it talks....
<fullermd> AFAIK, it triggers off the bug mailing.  And I haven't gotten that bug yet, so...
<awilkins> I think it watches for urls
<awilkins> https://bugs.launchpad.net/bzr/+bug/185191
<ubotu> Launchpad bug 185191 in bzr "add mnemonic diff to "commit" info {with patch}" [Undecided,New]
<fullermd> Well, it grabs the URL's.  And bugs named by number.  Like, I could ask about bug 185190...
<ubotu> Launchpad bug 185190 in ubuntu "City (Pittsburgh) Associated w/ Wrong Timezone" [Undecided,New] https://launchpad.net/bugs/185190
<awilkins> bug replay
<awilkins> 185190
<fullermd> But it'll also announce the filed bug when the mail hits.
<ubotu> New bug: #185191 in bzr "add mnemonic diff to "commit" info {with patch}" [Undecided,New] https://launchpad.net/bugs/185191
<fullermd> Like so.
 * fullermd pets ubotu.
<ubotu> New bug: #129334 in bzr-svn "Unicode exception while branching" [Low,Fix committed] https://launchpad.net/bugs/129334
<schierbeck> asabil: try pulling from ~bzr-gtk/bzr-gtk/viz-tags with the --overwrite flag
<asabil> k
<schierbeck> i've dropped using markup for now, i'll just deal with the tooltips when i have to
<asabil> ok
<awilkins> !word
<ubotu> A comprehensive list of of Windows-equivalent applications in Linux can be found at http://www.linuxrsp.ru/win-lin-soft/table-eng.html and https://wiki.ubuntu.com/WhatWindowsUsersWant
<cpinto> hi all
<cpinto> i'm using bzr to be able to work disconnected from a subversion repo. after fetching the sources i did a bzr unbind. worked a little bit on them, committed stuff and i just did a bzr bind + bzr update as to update from the central repository. now I have a bunch of pending merges mixed with a few not yet merged changes to the code.
<cpinto> is there anyway to commit only the pending merges?
<ubotu> New bug: #185200 in bzr ""database is locked" bzr internal error" [Undecided,New] https://launchpad.net/bugs/185200
<fullermd> Not really, no.  That's why you commit before update   8-}
#bzr 2008-01-23
<cpinto> fullermd, it's not possible to push my local changes to svn if someone else committed code to the trunk
<fullermd> If you can dig up the revid of the last change, you could probably make a diff relative to it, save it off somewhere, apply in reverse (to get back to that state), commit it, then re-apply the diff to get back to the changed state...
<cpinto> ouch
<cpinto> still, as i said, i committed my local changes to my local branch and when I fetched stuff from subversion it was... reverted? hence the pending merges
<jelmer> cpinto: you can rebase before pushing
<fullermd> Well, if I were going to work disconnected like that, I'd do it in a full branch, instead of mixing things up by doing it halfway with local commits in the checkout.
<cpinto> yeah, I was reading about that plugin just now :-)
<cpinto> fullermd, what do you mean?
<fullermd> Well, when you have local commits that you 'update' into pending merges, you're basically doing the full distributed thing already, but without the cushion and tracking of having them in an explicit branch.
<fullermd> So if you do something like that 'update' with local changes, you end up with a bunch of mixed up stuff.
<fullermd> (should 'update' even LET you do that?  I'm not sure I'd agree with that...)
<fullermd> The goal behind that set of commands/workflow is to try to make working central-but-disconnected as near as possible like straight-central, without introducing the bump in complexity of thinking distributed.
<fullermd> I'm ambivalent about whether that's a succeedable goal.  Seems like something that will generally Work Just Fine, but occasionally get you twisted up worse because of the stuff it tries to hide.
<fullermd> (I sometimes wish there was another flag like --show-ids to 'status' that would show the revids of pending merges; would make it easier to backstep in situations like that.)
<fullermd> Of course, it's equally possible that I'm just a cranky misanthrope who should be ignored   :)
<cpinto> damned  hardwired shell shortcut hehe
<cpinto> anyway, i agree that update should make my changes "pending merges". but I'd like to have something to replay those merges
<cpinto> either that or having bzr-svn merge remote changes into my local branch (which I have to commit) and after I push my stuff to the trunk not creating a revision with the stuff I originally retrieved from subversion
<awilkins> I've been using svk for disconnected SVn work
<awilkins> This has the secondary benefit of working well with plain SVN clients
<awilkins> e.g. - the Eclipse SVN clients can be pointed at my SVK depot, but I can still pull / push
<awilkins> I'm prepared to be the merging possibly isn't as good (I'm damn sure it doesn't track renames as well)
<cpinto> awilkins, at some point i'd like to move everything onto either bzr or git. this stuff is just a minor nuisance but it's one of those minor things that build up and at some point you get tired of them
<awilkins> cpinto: I'm most enthused by bzr so far ; I do a lot of windows development and git just isn't up to it on windows
<cpinto> i'd say a proper workflow in bzr-svn wiki would help to avoid this stuff
<fullermd> Wow, I can make a total mess of conflicts in a simple cases of local commits too..
 * fullermd wanders off to create a bug report.
<cpinto> awilkins, the reason for picking up bzr instead of git is mostly due to the fact that the old bazaar borrowed a lot from tla, which is the first dvcs i used :-)
<cpinto> one cloud that's hanging over my head, is what will happen to bzr if canonical closes up shop
<awilkins> Hmm, I went from Visual Sourcesafe to SVN to SVK to Monotone|git|Hg|bzr
<awilkins> I've been trying DVCS tools because I admin a few SVN repos
<cpinto> yeek, vss is a nightmare... ever had to recover a vss repo? :-)
<awilkins> If canonical closes shop then people will fork bzr
<i386> cpinto: yeah man - fuuuck
<awilkins> cpinto: No, because you CANT recover a VSS repo
<i386> VSS is a nightmare
<i386> I did a VSS to Team Studio VCS conversion...
<awilkins> The analyze tool can tell you some of the forms of damage, but it can't actually fix things
<i386> we had to leave behind some of the version control history
<cpinto> awilkins, not so sure of that... it seems that canonical is the single big player using bzr (well, the samba team also uses it)
<i386> Do NOT store a 3 gb codebase in VSS
<i386> and have 100 developers working from it...
<awilkins> Let me fix that s/3 gb //
<awilkins> Never use VSS for anything
<awilkins> If VS Team VCS is even informed by the design of VSS I wouldn't touch it
<cpinto> i386, last year I was asked to convert 3 vss repos to subversion and had to say it couldn't be done. tried everything i could remember, including using old tools to convert from vss to cvs expecting to be able to then convert cvs to svn. no dice
<awilkins> In fact, since it's not OSS I wouldn't touch it either
<cpinto> the MS guys we had on site said they wouldn't do it either
<awilkins> cpinto: I've successfully converted VSS to SVN
<i386> ha
<i386> we had microsoft .NETs core team come to our company
<cpinto> awilkins, really? how did you do it?
<i386> to help us move to from 1.1 to 2.0... they told us it couldnt be done
<awilkins> I can't recall now, it was one of the scripts on tigris.org
<cpinto> awilkins, was it a perl tool?
<awilkins> I think it was perl, yes
<cpinto> awilkins: that one crashed on my repositories
<awilkins> cvs2svn is python
<awilkins> Ooh, they have a new one
<awilkins> http://www.pumacode.org/projects/vss2svn
<awilkins> pumacode ; sounds... fast and hungry
<awilkins> And it can convert repos without installing VSS :-) that's a plus
<cpinto> awilkins, right, that's the perl tool
<cpinto> woops
<awilkins> The reverse engineered thing that reads VSS repos is a new bit
<awilkins> The version I used was somewhere around v 0.22 I think
<cpinto> Released August 4, 2006
<cpinto> still nothing new
<awilkins> I used it in about 2004 I think
<cpinto> oh well, my shrink would be glad to see i'm over it now
<awilkins> Misery++ on the news today
<awilkins> The north of england is flooded
<awilkins> Heath ledger is dead
<awilkins> The market is plumetting
<awilkins> DOOOM!
<awilkins> vss2svn has changes all thw way up to Nov 2007
<awilkins> Meh "The engine of the world has been the US consumer ; now they need to save, who is going to do all the shopping?"
<awilkins> You can just imagine the World Bank airdropping Visa cards onto the midwest
<mtaylor> lifeless: I filed a bug about that thing earlier - #185103
<mtaylor> about the bzr info -v producing a traceback
<mtaylor> martin pool was starting to look in to it, but I told him you'd been working on it some already
<ubotu> New bug: #185211 in bzr-svn "bzr commit fails on imported branch when renaming a directory with non-ASCII-name" [Undecided,New] https://launchpad.net/bugs/185211
<bronson> Is it possible to integrate multiple svn repos using bzr?
<bronson> I'd like to import 5 different svn repos as different subdirs in my bzr repo.
<bronson> That way I can ensure I always have a single, consistent set of code.
<bob2> that's fine, but they'll be no more integrated than multiple bzr branches in the same repository would be
<bronson> Can I at least work on the branches side-by-side?
<bronson> It isn't like I need to abandon one branch in my working copy to work on another one?
<bob2> how do you mean "side-by-side"?  you could use "bzr switch", like you can with bzr branches.
<bronson> I mean, I'd like to have both branches checked out simultaneously.
<bronson> i.e. I have branch A mirrored from UpstreamSvnA, and branch B mirrored from SvnB.
<bob2> /home/bronson/somecode/ and /home/bronson/someothercode/?
<bronson> Yes.
<bronson> Probably more like /home/bronson/myrepo/somecode and /home/bronson/myrepo/someothercode
<bob2> sure, branches in the repository can be from different svn repositories
<bob2> ah, right
<bronson> Good to hear.
<bronson> OK, I'll give it a shot.
<bronson> bob2, thanks.
<bob2> you're welcome
<ubotu> New bug: #185224 in bzr "per-file message support into server: common config check {patch}" [Undecided,New] https://launchpad.net/bugs/185224
 * igc lunch
<ubotu> New bug: #185271 in bzr-gtk "empty branch causes exception for bzr viz" [Undecided,New] https://launchpad.net/bugs/185271
<jelmer> tags eyecandy \o/
<jelmer> http://samba.org/~jelmer/bzr/bzr-gtk-tags.png
<mtaylor> hey all... bzr: ERROR: File exists: '/~ndb-connectors/ndb-connectors/telco-6.3/.bzr.backup': mkdir failed: unable to mkdir
<mtaylor> oops. sorry
<mtaylor> wrong window
<mtaylor> HOLY CRAP. rich-root-packs is really, really fast
 * igc dinner
<lifeless> hi
<lifeless> mtaylor: :)
<ubotu> New bug: #185298 in bzr "`bzr whoami --branch joe@example.com` and lightweight checkout" [Undecided,New] https://launchpad.net/bugs/185298
<bzlm> A horse walks into a bazaar...
<bzlm> The bazaartender says:
<bzlm> "Why the long face?"
<lifeless> heh
<ushimitsudoki> Is bzr appropriate for managing your website, as in develop on local box and push to server? If so, is there a tutorial or similar available?
<bzlm> ushimitsudoki, bzr is appropriate as a version control system for managing your website.
<luks> bzr will help you with versioning the website, not with pushing it to the server
<ushimitsudoki> bzlm / luks: thank you ... i'm using bzr locally alright I think for a small project, and then read that some people were using it for their websites as well - just got curious about that (it never struck me to use version control for my website before)
<beuno> ushimitsudoki, I work at a web development company, and we use bzr through out all our websites
<luks> bzr is fine for versioning it, but 1) it won't push the actual website files to the server (which is probably what you want), 2) it will push the branch/repository (which is probably what you don't want)
<beuno> ushimitsudoki, what we did to overcome the problem luks mentioned is a custom PHP script that checks for the latest files modified in the commits and lets you upload them via a web interface via sftp
<ushimitsudoki> luks: what you are saying is matching up with what I had figured, I was just wondering if I was overlooking some options there
<ushimitsudoki> beuno: that is a good idea - a bit beyond me right now, but I grok the concept
<Peng> You can use the push-and-update plugin.
<luks> Peng: you still probably don't want 'bzr branch'-able data on the server
<beuno> ushimitsudoki, push-and-update works also, you just have to be careful not to allow access to .bzr with an .htaccess rule
<lifeless> luks: deny access to .bzr :)
<Peng> I use .htaccess and directory permissions to block access to it.
<ushimitsudoki> bueno / peng: I will look into the push-and-update plugin as well, sounds close to what i need
<Stavros> is the trac-bzr plugin good?
<lifeless> fsvo good
<Stavros> ?
<lifeless> it works apparently, but there are quite severe model problems in trac for working with DVCS
<luks> "works" is probably the right word to describe it
<Stavros> oh
<Stavros> lifeless: such as?
<lifeless> such as wanting a heirarcy of changed directories above branches, for the timeline
<Stavros> oh hmm
<Stavros> :/
<lifeless> but different branches don't have that innately, so you have to scan all branches and synthesis this view; which is expensive. svn by its model has this
<Stavros> i see
<Stavros> is there anything else i could use?
<Stavros> or do you know if trac will be changed in the future?
<lifeless> you can use trac-bzr
<lifeless> I'm just explainin the issues :).
<Stavros> it's just slower?
<Stavros> true :)
<lifeless> you could use cart,, though it is unmaintained now
<lifeless> or launchpad
<Stavros> hmm nah, i'll go with trac-bzr then
<Stavros> it's not open source :/
<Stavros> is it this? https://launchpad.net/trac-bzr
<lifeless> I think so ;)
<Stavros> good, thanks :)
<Stavros> what does bzr ci --fixes do exactly?
<ushimitsudoki> Alright I must reveal more ignorance: I'm trying to install the aforementioned push-and-update plugin. I created a plugin dir under ~/.bazaar and read the wiki on "How to Install a plugin", but I can't find a clear download link on the push-and-update Launchpad page. I did try "bzr branch http://...bzr-push-and-update/trunk", and I got a message that said "Branched 10 revisions", but I don't know where those files are. Please h
<Peng> Stavros: It marks the commit as fixing a bug.
<Stavros> Peng: regardless of the tracking system used?
<Peng> Stavros: The tracking system has to be defined somewhere.
<Stavros> so do i do just bzr ci --fixes 12?
<Stavros> Peng: hmm
<Peng> Stavros: No.
<Peng> Stavros: E.g. "--fixes lp:12345" (with the Launchpad plugin) says it fixed bug 12345 on https://launchpad.net/ .
<ubotu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<Peng> Yes, thank you, ubotu..
<luks> Stavros: it just records that bug with URL XXX is fixed by this commit
<luks> no other functionality
<Stavros> Peng: i am using the trac plugin, which is supposed to have some integration
<luks> I don't think there is a trac plugin that uses it
<Stavros> so every developer should have the plugin installed?
<Stavros> hmm
<Stavros> maybe i misread then
<luks> SVN has the advantage that it can run hooks on the server, so things like this are easy
<luks> and since trac doesn't support external API for changing tickets, it's not that easy to do from the client side
<bob2> ushimitsudoki: in a directory called "trunk" in the directory you ran "branch" in
<Stavros> there's this: https://lists.ubuntu.com/archives/bazaar/2007q2/026518.html
<luks> Stavros: what do you mean by 'this'?
<luks> it just explains how to configure trac urls
<Stavros> it mentions how to get trac integration
<luks> no, how to map project:XXX to http://trac.project.org/ticket/XXX
<Stavros> ah
<luks> you still need a tool to read http://trac.project.org/ticket/XXX from bzr and update the ticket
<Stavros> oh, i see
<luks> and I'm not aware of such tool
<Stavros> right
<luks> I was considering writing it, though
<luks> but that would mean I first have to install the xmlrpc trac plugin :)
<ushimitsudoki> bob2: thank you!
<lifeless> Stavros: 'bzr help bugs'
<Stavros> oh, thanks
<lifeless> (bzr help commit has a see-also of 'bugs')
<Stavros> ah yes
<bzlm> Peng, your nickname means "coin" in my native tongue.
<Vercingetorigex> hi
<Vercingetorigex> thI need help: there is a plug-in for Visual Studio of bazaar? Thanks
<lifeless> Vercingetorigex: hi, there is such a plugin but I don't know how mature it is
<lifeless> Vercingetorigex: google will probably find it
<Vercingetorigex> thanks so much
<lifeless> mtaylor: hi; yes packs are fast :)
<mtaylor> lifeless: they make me happy
<CardinalFang> ...fast for most verbs, anyway.
<awilkins> How's barnsley?
<lifeless> barnsley?
<statik> why does bzr-gtk suddenly only have a single revision in trunk, when the version I have locally has over 400? http://codebrowse.launchpad.net/~bzr/bzr-gtk/trunk/changes
<schierbeck> jelmer: ping
<luks> statik: it has only a single file, named README, read it :)
<lifeless> statik: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/.bzr/branch/last-revision
<lifeless> meh thats nuts
<statik> wow that is crazy
<lifeless> jelmer: why not just rename the branch ?
<statik> luks: I should have read that file though, thanks for the tip :) now I can get the latest code
<dato> or put one of those bazaar reference branches, if lp would allow doing it (eg. with sftp, I guess)
<dato> I think that'd be the best solution?
<statik> latest bzr.dev gives me errors trying to pull from a 1.0 smartserver
<statik> https://bugs.edge.launchpad.net/bzr/+bug/185394
<ubotu> Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Undecided,New]
<statik> any other info that I should supply?
<lifeless> statik: known defect, see the list, kthxbye
<ubotu> New bug: #185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Undecided,New] https://launchpad.net/bugs/185394
<statik> lifeless: ok, cool. I didn't find an open bug when I searched
<lifeless> statik: yah, we kindof assume folk following trunk follow the list too ;)
 * bzlm e inte i huset mer
<ubotu> New bug: #185401 in bzr-svn "crash on checkout from SVN WC w/ unicode name" [Undecided,New] https://launchpad.net/bugs/185401
<arkadini> whould somebody have an advice on how to split/refactor a file into a number of separate files with bzr?
<LeoNerd> Just split it. bzr can't track movements of lines within files.
<LeoNerd> If you're going to cut it into lots of small pieces, my suggestion may actually be add all the new pieces, then del the original
<LeoNerd> That way you don't have a false "mv" which isn't really true
<arkadini> no, just 1 into 2, 3 max but was hoping to preserve the history for all the "new" files...
<lifeless> arkadini: planned feature, not there yet sorry
<lifeless> LeoNerd: I don't think the mv is false; its not the whole story :)
<LeoNerd> Hrm...
<LeoNerd> But I'd prefer to in this case, ensure that a "merge" on the file definitely breaks and requires human intervention
<LeoNerd> No chance of it accidentally succeeding where it woudl actually be wrong
<arkadini> lifeless: fair enough, thanks
<brink_> What is the recommended umask?
<ernst> hi
<ernst> just started with bazaar and am trying to setup a central repo on a ftp
<ernst> I finished steps where I made a repo on my ftp and I checked out, and put the files from my project in my local repo.
<ernst> but now I want to commit, which gives me this error: Append/Restart not permitted, try again
<ernst> what can I do?
<fullermd> Stab your FTP server.
<ernst> with a knife you mean ... ?
<ernst> I know it accepts APPE and RETR.. I tried those command with a command line ftp
<fullermd> I like 1/2" rebar.  A knife could break...
<ernst> hehe. lol
<fullermd> But yeah, it's a pretty standard FTP failure mode.
<fullermd> FTP is a flipping mess of a protocol.  Can use use something like SFTP instead?  That would be the easiest fix...
<fullermd> Gaah.  "Can _you_ use".  Coffee.  Need coffee...
<ernst> nope.. only thing I can use is plain FTP :(
<fullermd> I think somebody once had it actually work with active FTP when it failed like that with passive; try using aftp://
<fullermd> I can't imagine _why_ that would make a difference, but it may.
<ernst> gonna try it now.
<fullermd> Then take the knife to your server admin for not having sftp   :p
<ernst> well. I can have sftp .. but it will cost me :(..
<fullermd> What bzr version/repo format are you using?
<ernst> I have version 1.0 and followed this steps: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#publishing-a-branch
<fullermd> 'k, so you'd be using packs.  I wondered if maybe they might not need append, but I guess it translates to that down the stack anyway.
<ernst> I see..
<ernst> well I started again and am now using aftp:// instead of ftp://
<fullermd> lifeless: ^^^  _Should_ packs be able to do without transport-layer append, and so be more FTP-friendly?
<ernst> first time though, using something like VCN
<brink_> Should the umask be 002?
<fullermd> brink_: I s'pose that depends on whether you want the umask to be 002   ;)
<brink_> It seems we get a lot of problems with permissions after changes are pushed.
<fullermd> The umask may affect perms when you 'bzr init'; in normal operation though, bzr bases off the existing perms in the .bzr/ dir.  It may affect working-tree files that are created, I'm not sure.
<brink_> We're getting a bit of a mutiny that wants to go back to subversion.  I want to prevent that.
<fullermd> Mmm.  Pushing via SFTP, and getting perm problems on directories?
<brink_> Yes.
<brink_> I have to fix it with chmod every once and a while.
<fullermd> OpenSSH's SFTP server doesn't allow setting setgid.
<fullermd> It silently strips the bits.
<brink_> Sounds evil.
<fullermd> If you can use bzr+ssh instead, that'll work.  And probably be faster.
<ernst> well.. aftp:// still didn't do the trick
<fullermd> You could cron a find .bzr/ -type d -print | xargs chmod g+s with some regularity and stave it off.
<brink_> Does bzr+ssh work well for branching too now?
<brink_> I suppose I could, but I don't want any flakyness.
<fullermd> It should, yeah.  There's a few quirks with branch format default and such, but it should work just fine.
<fullermd> I don't think I've used sftp since 0.13 or so, I moved everything to bzr+ssh
<brink_> I was wondering if the umask was one of the issues.
<ernst> do you have another tip  I can try fullermd??
<brink_> I've been using bzr+ssh except for branching, the sftp seems to be much faster.
<fullermd> Nah, that's the SFTP server "helping" you.
<fullermd> ernst: Not really, sorry   :(
<ernst> darn.. I wanted to use Bazaar since it works with plain ftp
<ernst> *should work* :)
<fullermd> ernst: It comes up with some regularity; some FTP servers just don't get along well.  There's no formal spec for attributes to support or ways of passing errors, so the FTP code is pretty DWIM-y.
<fullermd> brink_: Mmm.  Maybe you're using a shared repo, with a lot of unrelated projects/branches in it?
<brink_> No.  It's not a shared repo.
<fullermd> brink_: The smart server might still be doing its "send initial branch as a tarball of the repo" thing, which could end up sending a lot more data...
<ernst> btw.. I see that bzr makes the initial file on my ftpserver.. it just won't append to it
<fullermd> ernst: Do you know what software the server is running?
<ernst> how do I find ou?
<ernst> out
<fullermd> It may give a banner you can see from a FTP client.
<brink_> I've notice a few postings about permission problems on Linux, but not enough detail to figure out what the solution is.
<ernst> never mind.. found it -> it's ProFTPD 1.2.10
<fullermd> brink_: Most of them, AFAIK, end up being the "SFTP server stripping setgid" thing.
<brink_> Can I get away with a umask of 022?
<fullermd> Not really.  SysV filesystem semantics need the setgid on the dir to inherit the group ownership to the files under it.
<fullermd> You could put BSD on the server   ;>
<brink_> So what do most people do.   Set the umask to 002?
<brink_> Actually, the main server we're using is OS X.   So it's sort of BSD.
<brink_> We use Linux too though.
<ndim> POSIX ACLs could work around...
<fullermd> Hm.  I'm not sure what set of FS semantics OS X uses...
<ndim> ...potentially.
<brink_> I've heard ACLs could help.   I don't know how to set them up though.
<fullermd> I don't think bzr follows the umask for repo files; it bases it off the perms of the existing files/dirs.
<ndim> POSIX ACLs at least have an equivalent to setgid - but without needing the g+s bit.
<fullermd> Yeah, but that probably wouldn't invoke the FS side effect of g+s.
<brink_> I've tried setting the sticky bit.  It doesn't seem to help.
<fullermd> Yeah, sticky wouldn't help at all.  Might hurt.
<brink_> Is that so?  How come?
<fullermd> Because the semantics of the sticky bit on a directory is to not allow you to delete files you don't own, regardless of whether you have +w on the dir.
<fullermd> (hence its use on /tmp and the like)
<brink_> Even if you're a member of the group?
<fullermd> Group isn't relevant there.  It's all perms.
<brink_> So what's the proper way to setup the perms?
<fullermd> To delete a file, you need +w on the directory it's in.  Whether you get that via user, group, or other perms, doesn't matter.
<fullermd> Well, the proper way with SysV fs semantics is g+s, so files inherit group   :)
<brink_> Something like this?  chmod -R 2770 repo/
<fullermd> It's just that the sftp-server doesn't get along with that.
<fullermd> Yah.
<brink_> And this?   chown -R  root:repogroup repo/
<ernst> fullermd: are there any workflows with bzr that doesn't require a correct implementation of APP? ie . it only STOREs files?
<fullermd> ernst: I don't know; I don't know the code at that level.  I presume the transport level is translating stuff to appends.
 * fullermd nods at brink_.
<ernst> I see..
<fullermd> brink_: Then periodically g+s'ing directories (not files) would clean up the damage the sftp server does.
<fullermd> brink_: But really, bzr+ssh _is_ the better answer.  If it's significantly slower, that's probably a bug.  If you can come up with some numbers on specific cases, you should probably post it to the list so we can see what we can do.
<brink_> You believe it's only sftp that causes the damage.  Never bzr+ssh?
<fullermd> Yeah.  It's a specific problem; sftp-server strips the g+s bit when we ask for it.
<fullermd> bzr+ssh doesn't go through the sftp server; it runs a local 'bzr' invocation which talks to the filesystem.
<brink_> It's possible that bzr+ssh is fast for branching now.  I haven't tried branching with bzr+ssh in some time.
<brink_> Maybe sftp support should be disabled?
<LeoNerd> bzr+ssh is a lot faster than sftp, in my experience
<brink_> For pushes & pulls it's faster.   Not sure it is for branching.
<fullermd> Actually, sftp may work OK for packs; I don't think pack repos end up creating directories very often.
<fullermd> knit repos will until it finishes filling out the hash bucket dirs.
<fullermd> Maybe lock dirs still suffer from it; I don't know.
<brink_> How do I tell if I'm using packs or knits?
<fullermd> 'bzr info'
<brink_> Yes.  We've had lock dir issues.
<fullermd> But really, I wish we _did_ de-emphasize sftp more.  If there are perf bugs in the SS, they should be fixed, and sftp should be a "if you can't run bzr on the server, you can still use sftp", not a default choice.
<brink_> I'm knit format.  Is that old?  Can I upgrade it?
<fullermd> Packs came in with 0.92, and became default in 1.0.
<fullermd> So if you've got people using older versions, you'll need to stay with knits.  If everyone's keeping up, and is on 1.0 or 1.1, you could upgrade.
<brink_> If I upgrade will they fail gracefully?
<fullermd> Well, they'll fail by saying "WTF is this?  I don't know how to work with this."  That's sorta graceful.
<brink_> That's good enough.
<fullermd> Packs may end up slower on sftp, if you have a large history and slow connections, since they'll have to shuffle a lot of data around for repackings.
<fullermd> I think the SS protocols already do all that server-side.
<ubotu> New bug: #185458 in bzr "can't add files with certain unicode characters" [Undecided,New] https://launchpad.net/bugs/185458
<ernst> @fullermd: just using bzr branche with ftp doesn't work. still APPEND errors. Time to use a USB stick instead :( or pay anothe 2 euro 50 for sftp support.
<Peng> I have to use sftp on one large repo because the server's process Nazi always kills smart server repacks. :P :(
<Peng> ernst: Or find a decent host? Not that that's easy.
<fullermd> See?  Just proves my point that there's no problem that can't be solved by finding the right person, and beating the crap out of them   :]
<ernst> yeah that's true Peng.. only prob is, I'm happy with my host when it comes to just php + mysql + http hosting
<fullermd> So all we need is PHP bindings for bzrlib so we can write a PHP smartserver...
<ernst> lol :)
<brink_> My os x bazaar thinks it's version 0.18.   Is the macports version behind?
<Peng> Well, it is behind.
<Peng> 0.18 isn't ancient. It goes 0.18, 0.90, 0.91, 0.92, 1.0, 1.1.
<brink_> I see that the 1.0 dmg say's it's for leopard.  I have tiger.   1.1 seems to be for tiger, but it's experimental.
<brink_> Not sure what fink will get me.
<brink_> Looks like fink is 0.18-1
<brink_> Maybe I'll try the leopard one and cross my fingers.
<fullermd> 1.1 should be fine.
<ernst> how do I add the pgp key from the bazaar gutsy repo?
<ernst> I'm using ubuntu gutsy
<Peng> It says how on the website.
<ernst> tnx. I was looking at the wrong places..
<ernst> mm tobad . no version 1.1 out yet for ubuntu as .deb
<mtaylor> there's the ones in the ppa
<mtaylor> deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
<mtaylor> deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
<mtaylor> ernst: ^^
<ernst> thanx mtaylor .. that works :)
<mtaylor> great!
 * mtaylor really wishes that bzrtools, bzr-svn and bzr-gtk would be considered "core" plugins and released to that ppa when bzr is released
<mtaylor> but that's just me
<abentley> mtaylor: bzrtools is on ppa.
<mtaylor> abentley:   bzrtools: Depends: bzr (< 1.1~) but 1.1-1~bazaar1~gutsy1 is to be installed.
<mtaylor>   bzr-svn: Depends: bzr (< 1.0.1~) but 1.1-1~bazaar1~gutsy1 is to be installed.
<abentley> Yeah.  It's borken, but it's there.
<mtaylor> well yes. :)
<mtaylor> I meant more of a process thing rather than a physical need thing.
<abentley> Bzrtools 1.1 is on ppa, but the dependencies are messed up.
<mtaylor> oh, fun
<abentley> So that it wants bzr 1.0
<ernst> fullermd, I was saying I'm getting those Append / Restart errors with bzr.. well. filezilla ftp client can 't append either. I'm gonna contact my host.. this is nonsens
<fullermd> Nonsense?!  This is FTP!   ;p
<ernst> hehe. well my first guess is that they disabled resume
<fullermd> No, I think ProFTP is one of the ones that that issue is standard on.
<fullermd> I'm flabbergasted that they want to charge more for sftp, though.
<fullermd> After all the time I spent screwing with firewalls to try and get FTP working right, and all the gaping holes I had to open, I'd be thrilled to tears if NOBODY ever wanted to use it again and I could yank all that crap.
<ernst> yeah I couldn't agree more.. silly thing is though, they are saying that SSH has more risks. go figure
<Peng> But you can get those risks if you want to pay more?
<ernst> yeah..
<Peng> fullermd: What do you like for file servers? Just HTTP?
<ernst> but 2 euro 50 for SSH and SFTP is too much in my opinion
<fullermd> Well, I use NFS for file servers   ;)
<fullermd> But yeah, file distribution, I just use HTTP.  It's simple, it's ubiquitous...
<Peng> Har har. Ok.
<Peng> (Isn't NFS evil?)
<fullermd> Absolutely.
<ernst> and everyone can get to http :)
<fullermd> But I use it in sufficiently controlled situations that the evil is suppressed.
<ernst> well, thanks for all the help. I'm gonna await an answer from my host
<awmcclain> Hi all... Is the only way to get the current revision number of a file to slice up the output from bzr log FILENAME?
<jelmer> mtaylor: I've just uploaded bzr-svn to ppa
<mtaylor> jelmer: you are my hero
<jelmer> I hope to also upload to ppa from now on when I do releases
<jelmer> james_w: Is there some easier way to build for ppa than running "bzr builddeb --source --builder="dpkg-buildpackage -rfakeroot -S -sa" ?
<mtaylor> jelmer: I just do bzr bd -S
<mtaylor> and then I have in ~/.bazaar/builddeb.conf
<mtaylor> [BUILDDEB]
<mtaylor> builder = debuild
<mtaylor> source-builder = debuild -S
<mtaylor> quick-builder = sudo debian/rules binary
<mtaylor> orig-dir = ..
<mtaylor> and that works for me for ppa
<RainCT> Hey
<RainCT> what was the command to remove a lock?
<jelmer> bzr break-lock
<CardinalFang> Tee hee.
<RainCT> jelmer: thanks :)
<lamont> will bzr let me say 'bzr log - but only for commits that include changes to $FILE'?
<Peng> "bzr log file"?
<lamont> bzr: ERROR: extra argument to command log: <file>
<lamont> win
<lamont> otoh, if I only give it one file, it does better
<dato> right, only one file allowed
<Peng> Seriously? That sucks.
<dato> yet another bit of insight brought to you by Peng
<Peng> Also, the RIAA are jerks.
<fullermd> Hey!  I'm _sure_ I said it first!
<igc> morning
<mtaylor> abentley: so any chance of someone re-uploading bzrtools to ppa as a !bazaar2-gutsy1 release with the depends fixed?
<mtaylor> and by ! I meant ~
<abentley> poolie does that, and he'll be here a bit later.
<Peng> Isn't the point of PPA that multiple people have access to it?
<poolie> mtaylor, got it
<poolie> Peng, yes, anyone could do it, but i probably know more about it than aaron
<mtaylor> poolie: rock.
<poolie> abentley, i'm off the phone, i'll be there about 11
<Peng> Nice, "apt-get update" ran at 743 bytes/sec.
#bzr 2008-01-24
<igc> bbiab
<Verterok> moin
 * igc lunch
<warnk> running 1.1.0 - is bzr's bugtracker feature supposed to be storing bug metadata or running some sort of post to the bugtracker url?  i see a blueprint for bug metadata, docs sound like everything is implemented though
<spiv> warnk: have you seen http://doc.bazaar-vcs.org/bzr.1.1/en/user-guide/index.html#integrating-bazaar-with-bug-trackers ?
<spiv> warnk: basically, bzr gives you a standard way to mark a revision as fixing a bug, but it doesn't automatically try to interact with a bug tracker
<warnk> i did see that, on second looking though, just saw mention of installing a hook
<spiv> warnk: you could setup a cron job or bzr hook to automatically notice those revisions, and update your bug tracker, but there's nothing "out-of-the-box" you can use to do that.
<spiv> e.g. you'd need to write the hook yourself.
<warnk> spiv: i see now, section on bug tracker settings made it seem that http posts, w/e were part of the commit process
<warnk> yeah, looking into hooks now
<warnk> metadata on bugfixes isn't currently logged locally, is it?
<spiv> "bzr log" doesn't report it, no.
<spiv> It should
<spiv> (I think there's a patch to the bzr-gtk plugin to make it show it, though)
<warnk> a hook to use --fixes probably is too much, a little regex magic could make a really lame post-commit bug tracker though. interesting
 * igc heading off early today
<igc> till tomorrow all
<poolie> igc, have a good holiday
<igc> thanks
<lostylost> Could someone help me with this error?  bzr: ERROR: Unable to delete transform temporary directory D:/invoice/trunk/.bzr/checkout/pending-deletion.  Please examine D:/invoice/trunk/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done.
<lostylost> I am loathe to mess around as I am new to bzr and even version control
<lostylost> now there is a lock on my bzr repo as well
<Peng> Well, you can use "bzr break-lock" for that. That's not dangerous.
<lostylost> cheers
<Peng> (As long as you're sure no other process or user has it open..)
<lostylost> It happened after running bzr update after a local commit
<Peng> I've never heard of the pending-deletion thing, so I can't help.
<lostylost> no worries
<lostylost> it's been happening every time I uses local commits
<lostylost> instead of commiting to the main repo every time
<lostylost> not exactly what's on the lid
<Peng> If you use local commits a lot, perhaps you should use a branch.
<lostylost> I did
<lostylost> "bzr branch location" yeah?
<Peng> yes.
<lostylost> I went a bit trigger happy with the bzr mv at one stage
<lostylost> maybe that's the problem
<lostylost> I had to recover a missing revision after deleting those files with the HEADS plugin
<Peng> I'd be very surprised if that was the problem.
<lostylost> I would hope so really that it wasn't that
<Peng> lostylost: Err? I don't know about the HEADS plugin.
<lostylost> I don't really know much either
<lostylost> but I used it to recover the dead HEAD revision
<lostylost> my last local commit
<Peng> Recovering a revision? What happened to it?
<lostylost> well I messed around deleting those temporary files
<lostylost> thinking that it would just be in my repo and I could
<lostylost> bzr revert
<lostylost> but the revision disappeared from my log
<lostylost> one of the bzr developers was around on this channel and he referred me to the HEADS plugin
<lostylost> Now the same problem has occured but I am loathe to mess around with it too much
<lostylost> not really knowing what I am doing
 * bzlm e i huset
<ubotu> New bug: #185574 in bzr-svn "Checkout from WebDAV server fails" [Undecided,New] https://launchpad.net/bugs/185574
<jrydberg__> jelmer: there?
<ubotu> New bug: #185591 in bzr-eclipse "Files moved by refactoring not moved in bzr" [Undecided,New] https://launchpad.net/bugs/185591
<jelmer> jrydberg__: hi
<jrydberg__> jelmer: how do you suggest i work against a upstream svn repo?
<jrydberg__> jelmer: i keep a bzr-version of the trunk in the repo, and merge everything into that when i want to push upstream?
<jelmer> jrydberg__: yeah, that would be one way. Another would be to use a checkout
<jrydberg__> i want to use bzr's merge tracking
<jrydberg__> jelmer: bzr: ERROR: Repository KnitPackRepository('file:///exports/lithium/jrydberg/repository/.bzr/repository/') is not compatible with repository SvnRepository('svn://picnic1/sw')
<jrydberg__>     a common error?
<jelmer> jrydberg__: See the FAQ
<jelmer> jrydberg__: Basically, you need a rich-root(-pack) repo
<jrydberg__> jelmer: you said i could use a checkout.  what would that gain me compared to using subversion?
<jelmer> jrydberg__: the ability to "bzr merge" from bzr branches
<ubotu> New bug: #128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New] https://launchpad.net/bugs/128496
<brink__> Anyone know the tradeoffs between rich-root and pack-0.92?
<dato> brink__: the proper question would be "between knits and pack-0.92" or "between rich-root-pack and pack-0.92"
<dato> brink__: because rich-root is knits+rich-root
<brink__> Hmm.   Bzr help upgrade lists them as pack-0.92 and rich-root.   If the tool uses that vocabulary then it's a valid question.  No?
<jw2328> brink__, rich-root uses knits, which are a data format that makes bzr slower than with packs.
<jw2328> however packs require clients to have at least 0.92
<jw2328> also, rich root stores information that packs-0.92 does not. It is planned to transition to store this information by default at some point.
<jw2328> --rich-root-pack is the equivalent for packs.
<jw2328> I would recommend the latter if clients that access the repo are going to be recent versions (1.0 or even 1.1 I think)
<jw2328> if you need to support clients less than 0.92 then use a knit based format.
<brink__> Thanks.   I noticed that rich-root-pack is labeled as experimental on my current version of bazaar  (1.0rc1 on Ubuntu).
<jw2328> I would definitely recommend using packs if you can.
<mtaylor_> rich-root-pack good
<brink__> Is rich-root-pack safe?
<jw2328> well, don't let it get hold of any sharp objects.
<brink__> Most code is pretty dull.
<james_w> brink__, if you hang on a minute I'll give you a sensible answer
<brink__> Take your time.  I'm here.
<james_w> brink__, someone far more knowledgeable than me says that rich-root-pack in itself is safe, however upgrading from non-rich root is a little flaky.
<james_w> So, if you are starting a new project then start with rich-root-pack. If not then hang on until the converter is up to scratch.
<brink__> sounds like good advice.
<Bloguero__Connor> .motd
<Bloguero__Connor> hello, the program is called bzr or baz?
<Bloguero__Connor> downloaded from apt-get install bazaar (using Ubuntu), I get it as baz. Is it OK?
<beuno> Bloguero__Connor, bzr
<beuno> baz is old/abandoned
<james_w> Bloguero__Connor, apt-get install bzr
<Bloguero__Connor> beuno: Why do I get baz -V: Bazaar version 1.4.2 (thelove@canonical.com/dists--bazaar--1.4[bazaar--devo.cfg])
<Bloguero__Connor> OK
<lifeless> Bloguero__Connor: you've installed an old version of the software
<beuno> Bloguero__Connor, because it's called bazaar too
<lifeless> Bloguero__Connor: the new version is called 'bzr' - 'apt-get install bzr'
<Bloguero__Connor> OK, let me try again
<Bloguero__Connor> Yes, now I installed sbassi@JeOS1:~$ bzr version
<Bloguero__Connor> Bazaar (bzr) 0.90.0
<beuno> Bloguero__Connor, I'd recommend you install the latest version from PPA:   https://edge.launchpad.net/~bzr/+archive
<beuno> 1.1 has a _lot_ of improvements and storage format change
<beuno> so it's the safest bet
<Bloguero__Connor> IMHO, when you do "apt-get install bazar", you should get a warning that this is an old version and that the current is bzr. Just an opinion.
<beuno> Bloguero__Connor, well, I think baz is getting removed from Debian
<Bloguero__Connor> beuno: OK, thank you!!!!
<beuno> lifeless, how about in Ubuntu, wouldn't it make sense to remove it too?
<lifeless> beuno: yes; bazaar should be a migration package depending on bzr, baz
<dato> w00t
<dato> I built bzr 1.1 for sarge, because one user requested it
<dato> what a PITA, though
<lifeless> tchau
<Bloguero__Connor> dato: where is it located?
<dato> Bloguero__Connor: backports.org in a couple minutes
<dato> Bloguero__Connor: (the source, a couple minutes; binaries for i386 and amd64 should follow in a while)
<Bloguero__Connor> dato: binaries for 386 is enought for me :)
<beuno> lifeless, so I should send a mail to the list and see who/how/when?  might be good to have it done before Hardy releases
<dato> should ideally be done in debian as well
<beuno> dato, I think ASCIIGirl filed for removal already, we talked about it the other day as the package was orphaned
<james_w> beuno: it has been discussed with the Debian maintainer, so a bug with patch in Debian would be the best way of doing it.
<dato> beuno: I don't see it orphaned
<james_w> beuno, baz was orphaned?
<dato> bazaar-doc is orphaned
<dato> not bazaar
<TeTeT> is there a nice way to only merge certain files of a branch with another? e.g. all .xml and .png files, but not Makefile, .xsl and such?
<james_w> TeTeT, bzr merge ../branch/file
<beuno> dato, aaah, she might of missed that -doc bit
<TeTeT> james_w: for all files?
<james_w> TeTeT, oh, no, hang on.
<beuno> james_w, what dato said  :D
<james_w> TeTeT, yeah, I think so. shell expansion should help.
<james_w> TeTeT, try it. What's the worst that can happen?
<TeTeT> rm -rf, bzr branch
<TeTeT> or even bzr revert
<beuno> dato, seems she didn't finish bazaar-doc either, so I'll mail the list for Ubuntu and Debian
<brink__> How come apt-get upgrade only gets me up to 1.0.0.candidate.1?   Aren't we up to version 1.1?
<Bloguero__Connor> good bye!
<james_w> brink__, what repos are you using for that/
<brink__> Not the repos.   bzr --version tells me it's 1.0.0.candidate.1.
<TeTeT> james_w: thanks, http://paste.ubuntu-nl.org/53357/ did the job
<james_w> brink__, yeah, I mean where are you expecting to get the new version from?
<james_w> (Ubuntu, Debian, bazaar-vcs.org, PPA)
<brink__> Ubuntu
<james_w> hardy?
<james_w> TeTeT, great. Glad to know it works.
<luks> TeTeT: ouch, wouldn't it be better to merge it all and then revert files you don't want to get merged?
<dato> some ubuntu guy /queried me the other day, and it seemed he'd work into getting 1.1 into hardy
<james_w> luks, no, not if you want the rest of the changes later.
<TeTeT> luks: might be another good idea
<luks> bzr revert --forget-merges
<james_w> dato, I think the request has been filed, so next time an archive admin processes the queue it should sync and build.
<james_w> luks, true.
<TeTeT> the loops takes a while for 400+ pngs ...
<luks> this just doesn't seem right, because it must have produced a lot of unnecessary commits
<dato> ok. he was worring about sid only having the rc1, and I told him there hadn't been any code changes
<TeTeT> luks: yes, it produced around 20
<james_w> luks, TeTeT, can you just commit once at the end? Perhaps you will have to add --force to the merge.
<luks> yes, with --force
<TeTeT> james_w: haven't tried that
<brink__> I'm also trying to install it on tiger PPC without much luck.    Macports says the following dependencies failed to build:-bz2 python25 py25-crypto py25-hashlib py25-paramiko py25-zlib
<james_w> bzr ls --modified | grep -v png\$ | xargs bzr revert; bzr revert --forget-merges; bzr commit
<TeTeT> but honestly I don't mind having a commit for each individual file
<james_w> I'm done for the day. Bye all.
<acuster> hey all, how do I get a diff between an upstream svn server and my current bzr?
<acuster> I should have a two line change locally compared to the server
<acuster> I'd like to know what's going to happen if I to a bzr push against the remote server
<jelmer> acuster: bzr diff -rbranch:svn-url
<acuster> thanks
<acuster> one other point of confusion, I did one bzr branch from the svn server to a branch locally, and then branched that into a working directory
<acuster> why does bzr push from the working directory not push to the other local branch from which it came?
<acuster> it goes directly against the remote svn server
<acuster> i'm clearly missing a piece of the puzzle
<acuster> :-)
<dato> push from the working directory should have no default push location
<dato> so most likely you specified the svn server once?
<acuster> so can i have a push in the working directory go to the 'master' branch ? (or, what command do I read about to reset the push location?)
<dato> to reset, bzr push --remember someotherlocation
<beuno> acuster, you can also switch between where you push all you want, push once to the the local bzr branch, once to the svn, you can work as you like.  --remember will overwrite the default location, as dato mentioned
<acuster> thank you all. /me runs off to learn some more and see what happens
<brink__> Is it ok to store unrelated branches in a shared repository?
<brink__> Also,  can you delete branches within a shared repository?
<radix> brink__: yes and yes
<brink__> And you delete them simply with rm -rf  ?
<radix> brink__: yep.
<brink__> Nice.
<radix> brink__: the revision data will stay around in the repository, so you won't reclaim much space
<brink__> That's ok.  It isn't the space that bothers me.  Just the clutter.
<radix> maybe some day there will be some garbage collection that cleans it up
<brink__> I'm debating whether I should just have a directory with branches or a shared repo with branches.  All the branches are currently unrelated.
<luks> it won't bring you any benefit, and might slow some things down
<luks> but not much
<brink__> Any advantages for multiple users?
<luks> disadvantages
<luks> if two users want to commit to the same repository at the same time, they have to wait
<luks> it really makes sense to use shared repositories only for branches that share some revisions
<brink__> Sounds like a shared repo is a good thing for efficient storage of tags and dead branches, but not much else.
<luks> well, it's very useful if you have 20k revisions and a lot of feature branches
<luks> but if you have separate projects, it's better to have separate repositories for them
<brink__> Thanks.
<brink__> What's the best way to set permissions?  Is it 2770 or just 770?
<Debolaz> Are anyone here convertees from git or hg? I'm writing up a comparison of the various scms, and I was curious what made people switch.
<mw> not really, but the fact that i have to use them for some projects i'm involved with makes me appreciate bzr quite a bit
<brink__> I used hg for a bit.  I switched because I rename things on occasion and I thing bazaar handles it better.   Also, I found it easy to plugin diff tools.
<brink__> I think the diff plugin should be standard actually, rather than a plugin.  It's too useful to be a plugin.
<pickscrape> Quick question. I'm currently evaluating bzr as a svn replacement, and am importing a large (41k) revision repository.
<pickscrape> I'm already seeing the effects of the memory leak in the python bindings that is fixed in svn 1.5
<pickscrape> My question is, if the memory consumption gets too high, can I kill the process and get it to continue somehow?
<jelmer> pickscrape: yes, as long as you use a shared repository
<pickscrape> At my end? Or at the server end.
<pickscrape> (sorry, I've started looking at bzr *today* so I'm new to the terminology too).
<bob2> on your end (bzr init-repo --rich-root repo ; bzr branch svn:/// repo/branchname)
<pickscrape> Ah, so I need to init the repo first. I was just issuing the branhc command and having it create the repo for me.
<pickscrape> Thanks, I'll rectify that right away... :)
<fullermd> jelmer: Would it work too if you did an 'init ; pull' dance instead of 'branch'?
<jelmer> yeah, that would work as well
<jelmer> it would be nice if we could get bzr branch do create something that is resumable
<bob2> I'd've thought branch would be resumable with pull
<pickscrape> Am I able to do an entire repository, or do I need to just branch one subversion 'branch'?
<bob2> bzr svn-import
<pickscrape> Ah, thanks again
<asabil> pickscrape: the bzr-svn memory leak got fixed in ubuntu I think
<pickscrape> I'm using gentoo
<pickscrape> Though I am using the bzr overlay
<asabil> pickscrape: I am not sure your process will survive with a 41K revision and an unpatched memory leak
<jelmer> asabil: Not yet, there is a patch but no new package has been uploaded yet
<asabil> oh ok jelmer
<asabil> pickscrape: maybe you want to try to apply the patch first ?
<pickscrape> asabil: that's why I'm hoping I can stop and restart it periodically
<asabil> ok I see :) good luck
<pickscrape> The gentoo overlay laready applies a couple of patches to subversion. I won't why it doesn't apply this one too.
<pickscrape> s/won't/wonder/
<pickscrape> BTW I'm very impressed with the site. The workflows page in particular is something that I think other systems' sites are lacking
<pickscrape> The next step would be examples of how to set each of those workflows up. That would be extremely useful to newcomers such as myself :)
<asabil> jelmer: concerning the bug display you added to bzr-gtk
<asabil> wouldn't it be nice to have something like the current tags display in the branch graph ?
<jelmer> for fixed bugs you mean?
<jelmer> yeah
<asabil> yep
<AfC> jelmer: there was a fellow in here the other day reporting about using bzr-svn to clone KDE. Most of his problem (once he got over the lack of UI feedback at certain stages due to the monster size of what he was importing) was about disk space;
<jelmer> AfC: Yeah, I plan on getting rid of that eventually
<AfC> jelmer: specifically "why is it taking so much space on my home partition"; most everyone here was like "hey don't worry about it" but he was like "no, it's a GB, and it matters"
<pickscrape> The svk depot for the repo I'm trying to clone is 7.4G. It will be interesting to see how big it is when cloned by bzr.
<AfC> which was an interesting angle; he had the repo going somewhere else, but bzr-svn's (sqlite?) database of bzr id to svn id (sic?) mappings is (apparently?) in ~/.bazaar/whatevger
<AfC> and that was causing him concern.
<AfC> jelmer: I thought I'd raise it with you to ask if possible & suggest if it is
<antares> Hello!
<AfC> jelmer: that perhaps this database (sic) could be stored in the repository rather than in ~/.bazaar
<AfC> (ie something custom in .bzr/repository/)
<AfC> jelmer: Just a thought. That's it.
<jelmer> AfC: The problem then is what to do when somebody runs "bzr log svn://foobar/"
<AfC> jelmer: interesting.
<AfC> jelmer: (offer them a free lobotomy?)
<pickscrape> Perhaps a simple pointer in ~/.bazaar ?
<jelmer> AfC: Also, that means somebody could be using a lot of diskspace if they don't use repositories but multiple branches
<jelmer> and wasting a lot of time creating that cache every time
<AfC> jelmer: yeah, well. That's what hard links are for :)
<AfC> jelmer: (sometimes I think we offer too much flexibility in making share repository optional. So cool, but alas)
<pickscrape> svn-import is actually doing a lot better with memory than branch was.
<jelmer> pickscrape: probably because the cache is already partially filled
<jelmer> pickscrape: it uses the same python subversion bindings so it'll have the same memory leak
<pickscrape> ah right
<pickscrape> Is there an interactive commit tool for bazaar that lets you choose individual hunks (a la git-gui)?
<jelmer> "bzr gcommit" (from bzr-gtk) allows selecting individual files
<pickscrape> Yes, I've found that. It would be nice if it could do it on a per-hunk basis too.
<acuster> wohoo! My first commit from bzr into our svn!
<acuster> thanks jelmer for all the hard work!
<acuster> and to all the bzr folk
<jelmer> pickscrape: Feel free to file a bug report :-)
<jelmer> acuster: glad you like it
<acuster> :-)
<pickscrape> jelmer: will do :)
<spiv> jelmer: perhaps a compromise might be to emit a message the when a cache for a new SVN repo is created?  e.g. "Initialising SVN revision mapping cache in ~/.bazaar/subversion/foo..."
<jelmer> spiv: Yeah, that makes sense
<spiv> Just doing it when a cache is created probably isn't too chatty.
<spiv> And then for the rest of the time you'll get that nice, silent "Just Works" behaviour ;)
<acuster> well that turned into a minor disaster
<dato> disaster?
<fullermd> I call that 'normal'   ;)
<acuster> a two line change turned into a three part push that hit about a hundred files
 * acuster is back to svn merging the reverse diff
<acuster> I'm stressing bzr a bit beyond what it has seen before I think.
<ubotu> New bug: #185764 in bzr "Add support for defining the code to commit at the hunk level in gcommit" [Undecided,New] https://launchpad.net/bugs/185764
<jelmer> pickscrape: btw, it is possible to use bzr shelve to temporarily remove bits from the working tree that you don;t want to commit
<pickscrape> Individual parts of files?
<fullermd> diff hunks
<pickscrape> Cool.
<poolie> jam, standup tim
 * pickscrape marks down bzr shelve as something else to look at
<fullermd> Hmm.  Is bzr.dev supposed to work against 1.1 SS's again?
<acuster> is dir_conflicts.prej a bzr generated file?
<bob2> "prej" doesn't occur in the bzr source
<acuster> thanks, maybe it's svn then
<ubotu> New bug: #185772 in bzr "Ability to set two authors for a commit" [Undecided,New] https://launchpad.net/bugs/185772
#bzr 2008-01-25
<pickscrape> Is bzr-svn capable of coping with nested branches?
<pickscrape> Actually, let me clarify that
<pickscrape> A /branches directory that contains directories that contain branches.
<Odd_Bloke> pickscrape: I'd be surprised if it weren't.  Try it and see?
<pickscrape> I just did. It seems to pick up the directories as branches.
<Odd_Bloke> pickscrape: You may need to do some config-fu.
<pickscrape> The trouble is, early in the life of this repo branches were done the 'traditional' way. Then when we realised we had far too many we broke them down into categories. So over time the branch scheme has changed.
<pickscrape> Where is the branch management config set up?
<Odd_Bloke> ~/.bazaar/<something>.conf
<pickscrape> Thanks, I'll check it out.
 * Odd_Bloke isn't on a machine with bzr-svn installed, else he'd be more specific.
<fullermd> There's some command for it, I think.  branching-scheme or something?
<pickscrape> Thanks, I'll check it out after dinner :)
<pickscrape> Would I be right in thinking you can just tell bzr to import trunk only by pointing it at /trunk instead of the repository root?
<Verterok> moin
<bob2> pickscrape: I think you'd just use bzr branch for that, so yes
<mthaddon_> is there a way to specifiy an ssh key (identity file) for a one time bzr+ssh command?
<mthaddon_> or is that something that just has to be set for the user environment that's executing the command
<schierbeck> asabil: ping
<asabil> schierbeck: pong ?
<schierbeck> :)
<fullermd> Space Invaders?
<schierbeck> asabil: i've found a bug in the fancy-tags implementation
<asabil> oh ?
<asabil> can you elaborate please ?
<schierbeck> the size of the cell renderer isn't reported correctly when a revision is tagged
<asabil> you mean the height ? or width ?
<schierbeck> so if you have a branch with a single line of development, the tags will not fit on the allocated space
<schierbeck> width
<schierbeck> i'm not sure how to fix it
<fullermd> That's user error; not branching enough   ;>
<asabil> but you can resize the column
<schierbeck> nope
<asabil> I am not sure I see the problem
<asabil> let me try
<schierbeck> fullermd: :)
<schierbeck> create a branch with just one revision, and tag that revision
<schierbeck> perhaps sum up the widths of the labels as we create them
<asabil> ah ok I see
<asabil> yep, that would be the solution
<asabil> sorry, I didn't think about this possibility
<schierbeck> np, i'll try fixing it
<schierbeck> fuck
<schierbeck> the size is requested before the widget is drawn
<asabil> :/, that's something I hate about Gtk cell renders
<asabil> sorry I got to go to bed now
<schierbeck> okay, i'll see what i can do about it
<asabil> got to wakeup early tomorrow
<schierbeck> *myself
<schierbeck> good night
<asabil> good night to you too, thanks, and sorry for the trouble :/
<j1mc> hi all - simple question.  if i have several updated files being tracked by bzr, but just want to commit updates to one of them.  should i enter 'bzr commit -m "my message about my commit" /path/to/file.xml'  ....  or should i do 'bzr commit /path/to/file.xml -m "message about my commit"'
<Odd_Bloke> j1mc: AFAIK, either should work.
<spiv> j1mc: either way is fine
<j1mc> thanks...
<AfC> j1mc: although both will work given a competent option parsing implementation, the former is more likely to work in general (given the 4 billion different getopt implementations out there). I probably don't need to be so gunshy, but old habits die hard, I guess.
<jamesh> AfC: well, it only has to work with the getopt variant that bzr uses ...
<jamesh> look on the bright side: it could be using tla's getopt variant
<AfC> jamesh: sure
<j1mc> AfC: i went ahead with the second one because it seemed more straightforward to me.  "commit this patch, and here's the message to go with it"  it seems to have worked ok.
<AfC> j1mc: oh, once a Bazaar hacker said it was ok in their application, it was all good. I just mention this because I have been burned by (for instance) tools like ls on BSD systems not parsing options liberally.
<j1mc> thanks, AfC ... i'll keep it in mind.  :)
 * fullermd considers it Only Proper to give options before arguments.
<AfC> fullermd: lndeed :)
<j1mc> fullermd: well explained.  thanks.
<AfC> poolie: are you going to be at LCA next week?
<poolie> AfC, no, but jamesh, jml and spiv will be
<poolie> afc, i mailed you about london
<AfC> poolie: No, I just thought it would be easier to conclude that conversation in person.
<AfC> I'm about to reply; I just had to have a word with our Advisory Board first.
<lifeless> moin
<lifeless> http://ozlabs.org/~rusty/index.cgi/2008/01/07#2008-01-07 <- heh
<speakman> hi ppl :) Whats the --rich-root exactly? Is it default when init-repo >= 1.0?
<minghua> speakman: I don't think it's default.  You can read "bzr help formats" to know more.
<speakman> ok, according to "help formats" rich-root isn't experimental? can I use it in production then?
<speakman> or I think i'll stick to pack-0.92..
<speakman> Another question; on the "Centralized workflow" guide, the "Recommended branching" says mainline should go into /project and branches should go into /projects/branch (sort of)
<speakman> is the webviewer able to show it correctly then?
<speakman> anyone tried that with Trac?
<speakman> I can't get the logics in this...
<lifeless> speakman: stick with pack-0.92
<speakman> lifeless: thanks I will...
<lifeless> speakman: yes web viewers should be able to show it; I can't speakto trac - don't use it myself
<speakman> ok, but I can't get the logics about branching
<speakman> i'd like something like /myproject/trunk
<speakman> and for new features; /myproject/feature1
<speakman> and so on.. where is the "trunk" supposed to go using the recommended branching?
<speakman> I've setup bzr smart server (through inetd) on my server, and it's all reachable trhoung bzr://server/
<lifeless> jamesh: ping
<speakman> And now I'd like to make up a "policy" for projects and branches, but I can't figure out how the "Recommended Branching" works.
<lifeless> speakman: what is confusing about it
<speakman> where is the "trunk" supposed to go?
<speakman> directly under bzr://server/myproject ?
<speakman> and my feature branch under bzr://server/myproject/newfeature ?
<speakman> (I've made a init-repo --no-trees bzr://server)
<speakman> lifeless: any clue?
<lifeless> speakman: sure, you can do that
<speakman> can? what would you prefer?
<lifeless> I tend to do .../trunk and .../branch1 etc
<lifeless> because people know to look for trunk/MAIN/HEAD and similar names
<speakman> ok, same as me then... how do you init your repos then?
<speakman> yes, and I can see more logic in that too...
<lifeless> well the init-repo command you've already run is all you need to init the repo  - the repo is just a storage database; 'bzr init' makes a new project, and ('bzr push' and 'bzr branch') are how you make new branches of that project
<speakman> so, an "bzr init-repo --no-trees bzr://server" and then "bzr init bzr://server/myproject/trunk" makes /myproject/trunk using no-trees as well?
<lifeless> speakman: do this:
<lifeless> bzr init somewhere-on-local-disk
<lifeless> cd $somewhere-on-local-disk
<lifeless> import your code  - e.g. 'bzr import mysource.tar.gz'
<lifeless> or if you have the files on disk, just bzr add && bzr commit
<lifeless> then when you are ready, 'bzr push bzr://server/myproject/trunk'
<speakman> thanks, seems like a great option :)
<jamesh> lifeless: pong
<ubotu> New bug: #185869 in bzr-gtk "gcommit fails with central bzr smart server" [Undecided,New] https://launchpad.net/bugs/185869
<ubotu> New bug: #185875 in trac-bzr "no support for utf-8 in source files" [Undecided,New] https://launchpad.net/bugs/185875
<acuster> jelmer, hello. We are trying to undo a commit I made yesterday with bzr-svn onto an svn directory. The commit started by doing a full replace of trunk/ back to the revision from which I did the initial bzr checkout (I have been bzr pull'ing since then). Do you have any pointers for how we can figure out how to do this kind of Replace in a single svn commit?
<lifeless> jamesh: hi two things
<jelmer> acuster: Did you try to push a commit that contained a merge of trunk ?
<jamesh> okay
<jelmer> acuster: That would explain the replace of trunk/
<acuster> yes, possibly
<lifeless> jamesh: bzr register-branch is broken (bug 185861) and gnome-gpg is broken on hardy (I'm testing a fix now)
<ubotu> Launchpad bug 185861 in launchpad-bazaar "bzr register-branch command broken?" [Undecided,New] https://launchpad.net/bugs/185861
<acuster> what's a 'merge of trunk' ?
<lifeless> jamesh: where should I send a patch for the latter; and can you confirm the bug ?
<acuster> what commands do you hit svn with to do the 'replace' ?
<jamesh> lifeless: file a bug in launchpad (the source of gnome-gpg is maintained with Bazaar these days)
<jelmer> acuster: If you had a local branch that descended from svn and then merged some revisions from trunk later and then pushed that branch back into svn
<acuster> yes, that sounds exactly right
<lifeless> jamesh: k, it works for me, but I'm not sure about tests etc - need to generate a GNOME_KEYRING_RESULT_NO_MATCH value
<jamesh> lifeless: I've marked your register-branch bug as a dup
<acuster> (1) I branched svn to br1 (2) I branched br1 to br2 (3) I pulled lots of updates from svn into br1 and then pulled those into br2
<acuster> (4) I modified one file in br2
<jamesh> lifeless: it is a bad interaction between the code that redirects beta testers to edge.launchpad.net and the xmlrpc server
<acuster> (5) I pushed that change into br1
<acuster> at which point bzr complained and I did some merges I didn't fully understand
<speakman> jelmer: about gcommit - there is no backtrace (as told in the report). How can I make one?
<acuster> (6) then I pushed the change from br2 to br1 and from br1 back to svn
<jamesh> I'm glad I got xml-rpc to report OOPS numbers ...
<lifeless> jamesh: are we able to fix this? Seems rather bad to be broken in production
<lifeless> jamesh: if we could even work around it in bzr (by using edge always) that would be sufficient
<jamesh> lifeless: bug 181156 is about the underlying cause
<ubotu> Bug 181156 on http://launchpad.net/bugs/181156 is private
<acuster> jelmer, the question is how to do the replace in the same way that bzr-svn did it so we can fix things. ARe you using svn replace for that command?
<jamesh> and it can't be worked around in Bazaar
<jamesh> actually, using xmlrpc.edge.launchpad.net would probably work
<jamesh> assuming it is hooked up
<jelmer> speakman: Hmm, that's actually a good point. We may have to stop handling exceptions automatically in all cases
<speakman> jelmer: Yes, tracebacks aren't that bad.. :)
<jelmer> acuster: What exactly are trying to achieve?
<jelmer> acuster: Trying to undo what bzr-svn did?
<balor>  I've forgotten how to do a bzr diff during a bzr ci.  Could someone remind me of the command?  I think it was similar to bzr ci --diff but bzr ci --help does not document that.
<balor> bzr version 0.90
<jelmer> A diff inside of the commit message you mean?
<dato> balor: --show-diff, not sure if 0.90 has it
<balor> jelmer: no, a diff whilst I'm writing the changelof
<balor> dato: 0.90 seems to be missing that feature
<balor> dato: guess it's time to upgrade
<dato> balor: oh
<dato> if it's not what jelmer said
<dato> the answer is "you can't"
<dato> (and quite frankly it sucks)
<balor> dato: hmmm....I had thought there was a workaround
<acuster> jelmer, yes
<lifeless> jamesh: I'll test that shortly
<acuster> we are trying to get svn back to where it was keeping the history of all the files over the past three weeks
<acuster> not merely getting the files back to a good state
<jelmer> acuster: Replace can be done by removing a directory and copying an older version of it into the same place in the same commit
<jelmer> acuster: This is one of the reasons some people use rebase rather than merge when pushing to svn
<acuster> thanks
<acuster> 'removing a directory' is a svn remove or a filesystem remove?
<jelmer> svn remove I think
<jelmer> Maybe followed by a file system removed
<jelmer> bzr-svn does this without a working tree
 * acuster is not allowed to touch the svn with bzr any longer :-)
<acuster> thanks
<jelmer> sorry to hear that
<lifeless> jamesh: edge works
<speakman> Why is the Debian/Ubuntu repos unmaintained lately?
<jelmer> lifeless: Do packs handle the lhs parent being a ghost ?
<lifeless> jelmer: yes
<lifeless> jelmer: what happened to acuster ?
<lifeless> speakman: they are eing maintained; just differently
<jelmer> lifeless: bzr-svn preserves lhs history
<jelmer> lifeless: "bzr branch trunk foo; <hack-hack>; bzr merge trunk && bzr commit; bzr push" will alter lhs history
<jelmer> lifeless: bzr-svn will properly preserve that lhs history when pushing by committing on top of an older revision of trunk
<lifeless> jamesh: patch is on lp for you
 * jelmer adds an entry to the bzr-svn FAQ
<speakman> lifeless: currently no repo is touched since 9 jan. bzr-gtk is still at 0.90 and requires bzr < 1.0.
<lifeless> jelmer: ah, and because svn doesn't track merges folk get confused
<jelmer> lifless: yeah, exactly
<lifeless> jelmer: so we should really recommend they use 'bzr checkout' for svn branches they are going to commit to
<lifeless> for 'compatibility'
<jelmer> lifeless: Yeah, that may be a good idea
<lifeless> jamesh: we should add an xmlrpc call to say 'I have pushed to <X> branch'
<dato> riiight. and one of the main pluses of bzr-svn, offline workflow, goes to... the bin.
<dato> (as commit --local will end doing the same with the lhs history afaik?)
<lifeless> dato: not at all; commit --local will not do the same thing
<dato> no?
<lifeless> dato: when you are on line again, you get the new changes from trunk by doing 'bzr update'
<lifeless> dato: that will pivot your local work into a merge, preserving LHS
<jelmer> lifeless: The alternative would be to not necessarily always push on top of the lhs parent
<jelmer> lifeless: But then bzr needs to handle diff against non-lhs parents properly, otherwise pulling from that branch later will be problematic
<lifeless> jelmer: not sure what you mean; what does bzr not handle correctly?
<speakman> btw, how can I add suggestions to bzr on launchpad?
<speakman> Blueprints?
<jelmer> lifeless: storing diffs for a revision where the lhs parent is a ghost but one of the other parents is not
<jelmer> afaik weaves at least had problems with it, I'm not sure what the status of that is these days
<lifeless> speakman: we like suggestions to be sent to the mailing list; or you could use the answers.launchpad.net/bzr forum
<lifeless> jelmer: in packs that will degrade to a fulltext at the moment
<lifeless> jelmer: but anyway, its not needed - because a heavy checkout will DTRT
<jelmer> lifeless: sure, but people will still use push and it would be nice to do the right thing when we add support for svn:merge-info
<speakman> ok, just one more simple question right here; is it possible to *easily* make an "alias" as "lp:project" but to our local server "ourserver:myproject"?
<speakman> I've tried to read the source code for launchpad plugin, but it seemed really complex for this "simple" issue.
<lifeless> jelmer: patches to core appreciated :) - packs have two fields (compression tree, ancestry graph), but enforce the same rules on them that knits had
<jelmer> speakman: the launchpad plugin does more than register the "lp" namespace
<speakman> jelmer: yes I know, thats why it was hard to me (pretty new to python) to just pick out the "lp:" part...
<speakman> i'd like a "alias" feature for it, or simular
<lifeless> speakman: we'd like to add a url alias facility
<lifeless> speakman: but noone has contributed it yet.
<speakman> lifeless: exactly! thanks!
<speakman> I'm afraid i'm too much of a newbie python programmer yet to make one myself. :/
<ubotu> New bug: #185907 in bzr ""bzr pull --quiet" should not say "Using saved location ..."" [Undecided,New] https://launchpad.net/bugs/185907
<antares> Hi! Does anyone know if I can make bzr follow symlinks?
<lifeless> for versioing files?
<lifeless> no, bzr versions the symlink, not what is linked to - sorry
<antares> no way to make it work?
<lifeless> well it works as designed :) - if you have a link to /foo, we record that you have a link to /foo :)
<lifeless> I don't know what you are trying to do that that is s aproblem for, but I'm happy to try and help
<antares> Thanks! I buld my projects (websites) using several modules that I store in a special directory, I link those modules to the project when I need them
<antares> and if I add a feature in one module, autoomatically is added to all the projects that use that module
<antares> The problem is that I need to version these changes without having to start a bzr repo in all of them
<lifeless> well, I think using bzr is probably a better fit :)
<antares> using bzr for all the modules?
<lifeless> yah
<antares> ok, thank you for your help, but I can't do that, it would give more headaches
<mtaylor> w00t. I just actually upgraded bzr, bzr-svn and bzrtools from apt. Thanks guys!
<lifeless> mtaylor: :)
 * lamont wants a bzr option to have it chdir before doing anything.
<lifeless> lamont: why?
<lamont> so I can say 'bzr --chdir /foo/bar status'
<lamont> alternatively, a bzr status where the user running bzr doesn't have read access to some of the unignored _directories_ would be even more lovely
<lamont> although status wouldn't notice the changes there if that were true. hrm.
<Kinnison> lamont: bzr status /path/to/branch
<Kinnison> lamont: not good enough?
<lamont> Kinnison: that would do, I believe,  as long as it looks at /path/to/branch/.bzr, and not $CWD at all
<lamont> Kinnison: works well, I do believe
<lifeless> lamont: 'bzr st /foo/bar' kthxbye
<lifeless> lamont: always try the obvious thing first :)
<lamont> lifeless: give me a break... I'm still working on figuring out your^Wbzr's definition of "obvious"
<lifeless> lamont: thats because you've been using a nasty system :)
<lamont> lifeless: expect bugs to show up for things that don't behave correctly... bzrk for example... :)
<lamont> s/correctly/like I want/
<brink_> Is it possible to split a branch into two separate branches?
<mtaylor> brink_: what do you mean?
<brink_> I have two unrelated projects in the same branch.  One of them is getting big.  I'd like to have to separate smaller branches.   Is this possible?
<brink_> I meant "two separate smaller branches"
<mtaylor> brink_: yes
<mtaylor> brink_: see bzr split
<brink_> Thanks.   Is that the reason for the new rich-root-pack format?
<mtaylor> ahearo,.. dunno... but I will say the new rich-root-pack is teh r0xr
<brink_> r0xr?
<mtaylor> brink_: :) it's good
<brink_> I get a " bzr: command not found" when I try to create a branch on a remote repository.  I think it's because bzr isn't on the path of the remote machine.  The remote machine is a Macintosh.   Does anyone have any idea how to add bzr to the path that ssh uses?
<james_w> brink_, what protocol are you using?
<brink_> ssh+bzr
<james_w> brink_, so you need to get it so that 'ssh bzr rocks' works.
<asabil> brink_: you can use sftp:// (but that's suboptimal)
<brink_> No, I can't use that.  It always screws up the file and directory permissions.
<brink_> It seems that ssh doesn't pay attention to /etc/profile.    I don't know where ssh looks for the path.
<asabil> brink_: can't you just edit the ~/.profile of the user you are using to push ?
<mtaylor> IncompatibleRepositories: Repository KnitPackRepository('file:///var/www/bundlebuggy/ndb-connectors/.bzr/repository/') is not compatible with repository KnitPackRepository('http://bazaar.launchpad.net/%7Endb-connectors/ndb-connectors/devel/.bzr/repository/')
<mtaylor> _I_ know what the problem is here
<mtaylor> I upgraded http://bazaar.launchpad.net/%7Endb-connectors/ndb-connectors/devel to rich-root-packs and did not do that to file:///var/www/bundlebuggy/ndb-connectors yet
<mtaylor> but I must say, that error message really sucks
<brink_> I need to make bzr available to everyone who is going to use the server.
<brink_> I'm not sure how to make it so ssh can find it.
<lifeless> lamont: file bugs please!
<asabil> brink_: it uses the PATH env var of the user, the PATH is generally defined in /etc/environment , /etc/profile and ~/.profile
<brink_> It seems to not be responding to /etc/profile although that works for login shells.   Maybe I should try /etc/environment
<quicksilver> If bzr is interrupted by SIGINT (i.e. ctrl-C) it needs to sanitise the terminal again before terminatng.
<quicksilver> Otherwise if you C-C a password prompt you end up with a broken terminal.
<lifeless> mtaylor: indeed; sorry
<mtaylor> lifeless: that's ok.
<james_w> quicksilver, I believe there is a bug about that already.
<mtaylor> lifeless: it can't _all_ be perfect :)
<quicksilver> james_w: ah well, I thought I'd mention it while it was on my mind :P
<james_w> !bug 78379
<ubotu> Launchpad bug 78379 in bzr "When bzr (or subprocess) disables terminal echo, Ctrl+C should re-enable it" [Low,Confirmed] https://launchpad.net/bugs/78379
<james_w> quicksilver, yeah, thanks anyway, it's always good to check.
<brink_> Anyone know how to make the bzr+ssh protocol available to users of a Macintosh server?  ssh says it can't find bzr on the path.
<lifeless> brink_: you can set BZR_REMOTE_PATH; you can simulate what bzr does byL:
<lifeless> 'ssh host bzr help'
<lifeless> if that works, bzr should work with it
<brink_> It doesn't.  It gives me this:  bash: bzr: command not found
<mtaylor> anybody running hardy already?
<lifeless> mtaylor: yes
<mtaylor> lifeless: usable?
<lifeless> brink_: then 'bzr' is not in your path. or it is but python isn't so its not executable
<lifeless> mtaylor: mostly
<mtaylor> heh
 * mtaylor is stupidly upgrading his laptop right now
<lifeless> ;)
<lifeless> I'm writing an update to the index layer - more speed++
<brink_> Yes bzr isn't on my path.  The question is, how do I get bzr on my path.   The bzr+ssh protocol doesn't seem to pay attention to /etc/profile on osx.  Any thoughts?
<lifeless> brink_: ln -s bzr /usr/bin/ ?
<brink_> Hmm.   I suppose I could do that.    Will there be any other dependency issues?
<brink_> What do people typically do on osx?
<lifeless> brink_: no idea:)
<brink_> It seems like there should be some documentation on how to setup bazaar in addition to just using it.   If I figure it out maybe I'll send it in.
<lifeless> that would be awesome
<brink_> Assuming I figure it out correctly.
<mtaylor> do we have any sort of osx disk image installer thing ?
<lifeless> there is a dmg image I believe
<brink_> Is there a way to merge two separate (no common parent) branches kind of like the opposite of bzr split?
<dato> brink_: yes. bzr merge -r 0..-1 /path/to/other/branch
<brink_> Thanks.  I didn't realize merge could work with unrelated branches.
<laga> hello
<laga> i was just working on something and wanted to bzrcommit/diff and i got the following error message: http://www.pastebin.ca/872417
<laga> i don't remember changing anything wrt my bzr setup. does anyone have a hint?
<laga> when will there be debs for 1.1?
<beuno> laga, there already are
<beuno> are you using ubuntu or debian?
<beuno> laga, https://launchpad.net/~bzr/+archive   for Ubuntu
<laga> i'm using ubuntu gutsy and i have the bzr repo in my sources list
<beuno> laga, the PPA archive has 1.1
<laga> thanks, i'll try those
<beuno> welcome'
<ubotu> New bug: #186005 in bzr "adding iso-8859-1 paths on a UTF8 file system gives a harsh error	message" [Undecided,New] https://launchpad.net/bugs/186005
<laga> i still get the same error message even after the update. i guess i'll file a bug in launchpad and try to get some work done afterwards
<beuno> laga, can you paste the error message on pastebin?
<beuno> maybe we can help you out
<laga> http://www.pastebin.ca/872417
<laga> it's there
<laga> just found a bug report on launchpad which might be related
<laga> https://bugs.launchpad.net/bzr/+bug/109114
<ubotu> Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed]
 * laga has no clue what he's talking about, though :)
<laga> beuno: it happens whenever i commit or diff. i don't think i#ve changed anything in the brnach (except for changing a few files of course)
<beuno> laga, does it have many files or big ones?
<laga> 1359 files, 7.5M size
<beuno> doesn't make sense for bzr to run out of memory with that little
<laga> yes
<laga> especially since i have 615M free
<beuno> at least for committing, diff's can vary I guess
<laga> it happens almost immediately, too
<beuno> laga, this seems like something different
<beuno> could you file a bug in Launchpad?
<laga> sure
<beuno> thanks  :D
<laga> done
 * laga gets a fresh checkout and ports missing changes ;)
<beuno> laga, great, thanks for that. I'll try and catch another dev and see if he can take a look at it
<laga> beuno: great. thanks for the support :)
<laga> yay. i have just accidentally reverted my changes using meld because i mixed up directory order. i must be having a metaphorical bad hair day
<beuno> laga, ouch. And you hadn't committed?
<ubotu> New bug: #186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/186014
<laga> no. i was using meld because i couldn't commit in the first place :)
<laga> oh well, that's what i get for not paying attention. not much was lost
<beuno> laga, what about branching that repo locally and trying to work on a fresh branch?
<beuno> (fully local branch)
<laga> beuno: i've got a fresh branch already
<beuno> laga, but it's a checkout, no?
<beuno> checkouts are bound to their parents
<laga> well, i was using "bzr branch" i think
<beuno> oh, then you do have a fully local branch
<laga> hum
<laga> i'm not sure actually. i created this branch locally, then pushed to launchpad..
<laga> i need to polish my VCS skills. :) am i supposed to merge from launchpad or pull from there? or is there no difference at all?
<laga> in case someone else modified the branch on launchpad
<beuno> laga, if someone else modified, you'd have to merge
<beuno> I tend to try and pull first though, or do  merge --pull
<laga> oh, it'll error if someone else has done any modifications?
<beuno> laga, yeap, it will say you need to merge
<beuno> if there aren't any conflicts, you just commit the merge
<beuno> and you're up-to-date
<laga> i was just curious because i'm working on this branch from my laptop and from my desktop and i usually just push on both
<laga> yeah, right.
<laga> ah, now i remember. i didn't see the merge in the commit message at first and that's what confused me. in the end, everything turned out to be alright :)
<beuno> laga, things tend to work themselves out a lot with computers  :p
<laga> yes
<laga> that's why i has hoping bzr 1.1 would solve my weird error message. ;)
<beuno> laga, it's really odd that you would get that error, I have much larger branches in file sizes and quantity, even on some PCs with 512mb ram, and still don't hit the RAM hard enough to traceback
<laga> beuno: i'm just glad that bzr itself is still working on my box
<beuno> laga, do you have a grumpy box?
<laga> beuno: it's usually working fine. including RAM :)
<laga> if that's what you meant
<beuno> ah, bzr usually works fine on all enviroments, that's why I asked if you had a particularly grumpy box
<laga> i've just compiled mythtv three times in a row without errors while running virtualbox at the same time. it's fairly stable :)
<beuno> good, then we'll see if we can nail down that traceback as soon as possible
<laga> it's 100% reproducable as well. unless there's a bad block on the hard disk i don't see what could have broken it hardware-wise
<Lo-lan-do> Hi all
<Lo-lan-do> Is there a way to inject missing revisions into a repository?
<Lo-lan-do> I converted a baz archive to bzr, but some of the branches in there were based on branches in other baz archives, and apparently the baz-import didn't create the revisions in bzr
<Lo-lan-do> bzr check says:
<Lo-lan-do>     12 ghost revisions
<Lo-lan-do>     11 revisions missing parents in ancestry
<Lo-lan-do>     85 inconsistent parents
<Lo-lan-do> Is that fixable (I have the other baz archives at hand), or should I redo the conversion?
 * Lo-lan-do tries cloning all these branches into a single repository, which should then have all revisions
<Lo-lan-do> Hm.  bzr reconcile seems to help
<batoms> is there a way to set the ssh client in bazaar.conf
<batoms> something similar to export BZR_SSH=paramiko
#bzr 2008-01-26
<Debolaz> Are there any ways for multiple people to access repos on my machine through a single ssh account, but not let everyone have access to every repository?
<minghua> When I am in the commit log editor after running "bzr commit", "bzr diff" gives an error message about some locks and can't produce a diff.  Is this expected?  Is it possible to change this?  Should I report a bug?
<snod> hi, one question, can't bzr handle umlauts in filenames?
<snod> if have a bzr repo pushed to a sftp location and branched it via http and the umlaut is replace by two ##
<snod> i created the repo on a linux machine with utf8 and branched it on a mac os box
<lifeless> the mac file system does unicode NFD normalisation
<lifeless> bzr will preserve the umlaut happily - branch it onto e.g. a iso-8859-1 locale, or windows, or even utf16 and it should all work fine, but mac's give us grief
<snod> ah ok :) damn mac filesystem
<snod> ah i just found the unicode page on bazaar-vcs.org
<snod> so it doesn't work right now?
<lifeless> well, it should preserve the filenam when you go back to unix IIRC, it will depend on what bzr st shows
<lifeless> but yeah, expect some glitches I think :(
<lifeless> gotta run, ciao
<snod> cu and thanks for the help
<schierbeck> ping
<arne^> pong
<ubotu> New bug: #186194 in bzr "option to follow symlinks" [Undecided,New] https://launchpad.net/bugs/186194
<scorpioxy> Hey guys, i have a problem with the launchpad plugin it seems. On the launchpad page, it says that i can push using the lp:~username.... string, but doing that bzr errors out with a "cannot lock" error because it redirects to an http location. Is this is a bzr thing or is the launchpad page wrong?
<iKs> Hey !
<iKs> I'd like to know if it is possible to specify a port when you commit on bzr+ssh :)
<iKs> cause I'm behind a proxy and one of the only open port is 443
<iKs> so I have to commit through that :D
<iKs> I made my sshd listen on both port 443 and 22 but I need to specify it on the command line
<jelmer> afaik bzr+ssh://host:port/ should work
<iKs> hum OK
<iKs> thx
<Stavros> hello
<Stavros> is there a visual studio bzr plugin available?
<schierbeck> jelmer: ping
<jelmer> schierbeck, pong
<schierbeck> | *
<schierbeck>     *
<schierbeck>      *
<schierbeck>       | *
<schierbeck> hah!
<schierbeck> jelmer: do you have 2 minutes to talk about the viz?
<jelmer> :-)
<jelmer> sure
<schierbeck> i'm thinking about adding in the About window again
<schierbeck> i think it's important that it's there
<schierbeck> but should Olive and the viz share the same window?
<schierbeck> i kind of consider them different applications, which happen to reuse some of the same widgets
<jelmer> yeah, same here
<jelmer> Adding an about dialog would be a good idea
<schierbeck> the thing is, i consider the viz to be part of the core bzr-gtk, while Olive is more peripheral to me
<schierbeck> but then again, i'm not an Olive user myself
<schierbeck> i think they should have different About dialogues
<jelmer> I think there already is a bzr-gtk About dialog
<jelmer> we could just use that
<schierbeck> okay
<schierbeck> i'll hook up the menu to it
<schierbeck> jelmer: the current about dialog shows info on bazaar, not bzr-gtk
<jelmer> it should be adapted then
<schierbeck> done
<schierbeck> i'll push it to lp, 30 sec
<schierbeck> this version also reads in COPYING instead of just displaying "GPL v2" in the license window
<schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-about-dialog
<schierbeck> jelmer: do i need to send in a merge request? after all, we're the only two active devs atm
<fullermd> Ooh, people are touching viz?
<jelmer> schierbeck: well, a patch to the list would be useful in any case
<schierbeck> fullermd: :)
<schierbeck> jelmer: okay, i'll send it in
 * fullermd pimps for bug 183627.
<ubotu> Launchpad bug 183627 in bzr-gtk "viz crams revid onto your clipboard" [Undecided,New] https://launchpad.net/bugs/183627
<schierbeck> jelmer: sent
<schierbeck> fullermd: i'm not sure how to get around it
<schierbeck> the fields ought to be selectable
<fullermd> Selectable is great; it's the autoselecting part that's...   well, kinda offensive.
<schierbeck> fullermd: i know, i'm looking into having it not do it
 * fullermd nods.
<fullermd> It's not like it's a big thing.
<schierbeck> it's puzzling me atm
<fullermd> Just a rather irritating small thing.
<schierbeck> yup
<schierbeck> jelmer: at some point we need to talk about the Changes page
<schierbeck> i still think it's a good idea
<jelmer> schierbeck: ok, will have a look at your merge request later today
<schierbeck> thanks :)
<jelmer> schierbeck: I still don't, for various reasons
<schierbeck> fair enough, just as long as we can discuss it
<jelmer> Perhaps we can come to a compromise or something
<schierbeck> yup
<schierbeck> i'm thinking about perhaps getting rid of the Relations page, to cut down on complexity
<jelmer> It's not as much the complexity that I have problems with
<jelmer> It's the fact that it mixes metadata with contents in the same widget
<jelmer> a widget which is meant to be relatively small (sufficient to display that metadata)
<jelmer> and doesn't allow diffing against multiple parents
<schierbeck> the current version does allow diffing against multiple parents
<schierbeck> still haven't implemented the file list
<schierbeck> but it's coming
<jelmer> The file list is going to take up a fair chunk of space
<jelmer> more even than the metadata usually needs
<schierbeck> i'm thinking about using a toggle button to show and hide it
<jelmer> I would rather just have an optional diff widget below the metadata
<schierbeck> i don't think it'll be a real issue
<schierbeck> i think another widget *would* add to the complexity
<jelmer> It's separate of the metadata
<jelmer> The size is really going to be an issue
<schierbeck> would still introduce more content on the ui at the same time
<schierbeck> i think we should try it out before deciding on that; i really get a lot of requests for this feature
<schierbeck> besides, in the viz, the revisionview widget is as wide as the diff window itself is
<jelmer> I've tried your branch, and it really doesn't work well for large commits
<schierbeck> yeah, it needs the file selector widget
<jelmer> yes it would be as wide, but the metadata bit is supposed to be quite small
<jelmer> (in height, that is)
<schierbeck> the user can freely change the height if it becomes necessary
<schierbeck> i just think it's important to show the diff in a relevant context
<schierbeck> otherwise, changing parents would be confusing
<schierbeck> and besides, it doesn't harm; the extra tab takes up minimal space
<schierbeck> the diff is only loaded when the page has focus
<schierbeck> i think we should include it in a release -- if it gets a bad reception, we'll take it out again.
<jelmer> re
<jelmer> schierbeck: how would showing the diff below not be in the relevant context?
<jelmer> schierbeck: I think metadata and contents are conceptually different and should be displayed in a different area
<schierbeck> it would, but i just don't see how adding another main widget to the window will help
<jelmer> that also makes it possible to view the revision metadata and contets at the same time
<schierbeck> jelmer: i don't think our users think about it that way
<schierbeck> i just don't see the need
<schierbeck> and if we needed to display both metadata *and* content, we *would* run in to size problems
<jelmer> schierbeck: I doubt that, see giggle's layout for example
<schierbeck> jelmer: i hate giggle's layout :)
<schierbeck> way too crowded
<schierbeck> we should only display the absolutely necessary to the user
<jelmer> Well, giggle has more than this
<schierbeck> yup
<schierbeck> too much more
<jelmer> schierbeck: Just putting everything in tabs is confusing as well imho
<schierbeck> it's incremental complexity; the user chooses to see more
<jelmer> We could make the widget with the diff on the bottom of the screen detachable
<jelmer> so you get the same effect you have now
<jelmer> if you want to
<schierbeck> i think that would introduce a *lot* of complexity -- think the detachable menus in the GIMP
<schierbeck> it's just confusing
<schierbeck> but if the users want it, sure
<jelmer> yes, a lot of detachable things is confusing, but a couple doesn't hurt
<schierbeck> i think we should start out simple, and see how the user base reacts
<schierbeck> if they want a detachable widget, we'll create one
<schierbeck> but we need to start somewhere
<jelmer> ok, so let's leave that out of the picture for now then
<schierbeck> ok
<jelmer> in any case, the diff bit could be hideable
<schierbeck> yup
<schierbeck> but i still think we should go for minimal intrusion
<jelmer> That's not an argument for using a tab though..
<jelmer> we could just make the bottom widget hidden by default and add a button to enable showing it
<schierbeck> well, it's the solution that adds the least complexity to the startup view
<ubotu> New bug: #186238 in bzr "TB when cloning an SVN trunk into repo in "subversion" format" [Undecided,New] https://launchpad.net/bugs/186238
<schierbeck> i'd like the advanced users to be able to have an inline diff view, but not to bother newbies
<jelmer> schierbeck: if we hide the widget by default but add a toggle button to allow showing it, that's equilly intrusive as a tab
<schierbeck> jelmer: but when it's shown, it takes up much more vertical space
<schierbeck> making it hard to see the contents
<jelmer> schierbeck: Yes, but you could resize it any way you want
<schierbeck> perhaps we could add a toggle that switched between the two layouts
<schierbeck> jelmer: still, treeview + revisionsview + diffview
<schierbeck> "Show changes beneath revision info"
<schierbeck> if it's on, the tab disappears, and the diff view is shown at the bottom
<schierbeck> ?
<schierbeck> compromise?
<jelmer> schierbeck: Having more than one way to show it in this case doesn't make sense imho
<schierbeck> we'll, then we're in disagreement :)
<schierbeck> i like the tab approach the best, you the separate widget approach
<schierbeck> we really could use some more opinions
<jelmer> Conceptually the contents just aren't part of the metadata nor do they have the same size constraints
<schierbeck> jelmer: i really don't think that's going to be an issue
<schierbeck> in the context of the viz, it won't matter at all
<schierbeck> and we can just disable it anywhere else
<jelmer> fullmermd: ping
<bronger> My plan is to clone an SVN trunk as a local Bazaar branch.  This works, however, I cannot use it within a Bazaar repo.  Moreover, I cannot setup a Bazaar repo and clone a secondary branch of that SVN branch into this repo.  So, is it completely impossible to use shared repositories if subversion is involved?
<jelmer> bronger: what error do you get?
<bronger> It complains that the formats don't fit together.
<jelmer> bronger: see the FAQ, use bzr init-repo --rich-root-pack
<bronger> bzr: ERROR: Repository KnitPackRepository('file:///home/bronger/src/bobcat/.bzr/repository/') is not compatible with repository SvnRepository('https://svn.origo.ethz.ch/bobcat')
<bronger>  -- OR --
<bronger> bzr: ERROR: Repository KnitPackRepository('file:///home/bronger/src/bobcat/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/bronger/src/bobcat-svn-mirror/.bzr/repository/')
<bronger> Depending on what I do exactly.
<jelmer> schierbeck: There's no reason for the other tabs to be that large though
<jelmer> schierbeck: and it doesn't allow the metadata to be visible at the same time as the contents
<schierbeck> jelmer: i don't think we really need to show the metadata at the same time, and having the widgets next to each other will take up an unreasonable amount of space
<schierbeck> i just don't think it'll fit
 * jelmer tries
 * schierbeck waits :)
<schierbeck> jelmer: let's pick it up again tomorrow, i have to go
<schierbeck> see ya!
<ubotu> New bug: #127945 in bzr-svn "Integrate creating new branch functionality into standard push/branch" [Low,Triaged] https://launchpad.net/bugs/127945
#bzr 2008-01-27
<pygi> hello
<pygi> trying to configure bzr smart server
<pygi> I get this when I try to pull
<pygi> branch that is
<pygi> bzr: ERROR: Unknown branch format: "error\x01Generic bzr smart protocol error: bad request 'GET /libisofs-ng/.bzr/branch-format HTTP/1.1\\r'"
<jelmer> pygi: Looks like you are using http to access it??
<pygi> jelmer, yup
<pygi> jelmer, why wouldnt I be able to do that?
<jelmer> pygi: The smart server talks a custom protocol
<jelmer> use the bzr:// branching scheme
<pygi> jelmer, and no way I could make it use http? :P
<jelmer> pygi: No, you can use any HTTP server if you want http
<pygi> if I had access, then yes :)
<jelmer> pygi: ?
<pygi> jelmer, to apache I meant :)
<pygi> dont worry, I can just use bzr :)
<pygi> bzr protocol I meant :p
<pygi> ok, one more question
<pygi> I run bzr serve on a custom protocol
<pygi> how do I do branching/etc from that port?
<Odd_Bloke> pygi: 'bzr branch bzr://<host>:<port>/<path, I would expect.
<Odd_Bloke> I haven't used bzr serve in months though. :p
<pygi> hmmmm, connection refused
<pygi> I'll have to look into it
<pygi> thanks Odd_Bloke
<abentley> spiv: ping
<ubotu> New bug: #186285 in bzr "commit fails if the working tree contains an unknown file with undecodable name" [Undecided,New] https://launchpad.net/bugs/186285
<lifeless> hi
<i386> lifeless: hi
<snod> morning, are there bzr 1.1 packages for ubuntu gutsy available? the repository listed on the site still has 1.0
<dato> snod, try https://launchpad.net/~bzr/+archive/
<snod> ah thanks alot :)
<ubotu> New bug: #181773 in bzr-svn "Incorrect revision numbers in bzr:revision-id:v3-trunk1" [Undecided,New] https://launchpad.net/bugs/181773
<jelmer> hmm, does bzr have problems with hardlinks?
<jelmer> what sort of problems could a vcs have with hardlinks?
<radix> jelmer: multiple hardlinks to the same file within one branch?
<jelmer> radix: Why is that a problem?
<radix> jelmer: I'm just asking if that's what you're doing.
<jelmer> I somehow have the feeling I'm missing something obvious :-)
<radix> It sounds like it could definitely lead to some weird behavior, but I don't know, it depends what you're expecting.
<radix> jelmer: "hard links are scary" is the obvious thing :)
<jelmer> (-:
<dato> jelmer: do you mean hardlinks outside from .bzr only?
<dato> outside of*
<jelmer> dato: I'm adding support for bzr to etckeeper
<jelmer> dato: and it complains for git and hg when it sees hardlinks
<jelmer> I was wondering if it should do that for bzr as well
<radix> Imagine two files linked to the same resource. Merge from a branch that changes each of them in distinct ways.
<radix> hard links are generally a bad idea. :-)
<snod> i just wonder: has anybody tried to use bzr over sshfs?
<radix> snod: no, but I wouldn't want to, because sshfs is really unreliable (for me at least)
<radix> snod: I assume you're talking about the FUSE-using filesystem
<radix> I wonder why you'd want to use it instead of just pushing to bzr+ssh URLs
<snod> i don't want to commit every tiny change
<radix> tiny change?
<radix> why would you need to do that?
<snod> as far as i understand a push just pushed commited revisions?
<radix> yes.
<snod> *pushes
<radix> (you can also 'bind', which creates a checkout, which means committed revisions are automatically pushed)
<snod> so if i edit a file locally and have to try/execute/whatever it on a remote place i would have to do a commit for every change i do in the src file?
<radix> ok, so you want to try/execute/whatever it on a remote place. that wasn't clear.
<snod> :)
<asabil> you will need a bzr update
<asabil> on the remote side to update the tree
<radix> asabil: well, he doesn't even want to commit in the first place, so update isn't going to help either :)
<snod> i just ried bzr on an sshfs-mounted dir
<snod> gives me an error: bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'abort'
<radix> snod: well, like I said, I would avoid using sshfs because I've found it pretty unreliable, even for simple read-only stuff.
<snod> i will keep that in mind :)
<snod> (the error occurs on commit, init and add worked)
<asabil> snod: why don't you want to commit ?
<jelmer> wow, that was easy
<jelmer> etckeeper support for bzr in < 30 minutes
<snod> asabil: the changes are tiny like forgotten brackets or a misspelled word
<asabil> snod: those deserve commits as well
<asabil> snod: what you are trying to do will bring troubles upon you
<asabil> and it is exactly what makes Visual Source Safe so ... Unsafe
<ubotu> New bug: #159143 in bzr-svn "Handling of svn:author" [Wishlist,Triaged] https://launchpad.net/bugs/159143
<vila> radix: I use bzr over sshfs for months without nay problems (using -o workaround=rename solved the only problem I ever encountered)
<jelmer> hey vila
<jelmer> vila: do you happen to know how to retrieve a configuration variable for a specific section?
<vila> jelmer: from memory, it should be possible to query a ConfigObj object for a specific section and get a dict in return
<jelmer> vila: Ah, yep
<jelmer> Just found it
<jelmer> hmm, is it possible to change the tree from a pre-commit hook?
<jelmer> crap, apparentlynot :-(
 * jelmer files a bug
<ubotu> New bug: #186422 in bzr "Ability to modify the tree from a pre-commit hook" [Undecided,New] https://launchpad.net/bugs/186422
<bronson> I have a legacy svn tree...   I'd like to check a bzr project into a branch in that tree.
<bronson> Is there a good way of doing this?
<bronson> Normally I want to manipulate svn trees in bzr...   This time, though, I want the opposite.
<jelmer> bronson: I think "bzr svn-push" is what you're looking for
<bronson> jelmer: hm, probably.
<bronson> I'll have to read up on it.
<bronson> jelmer: "bzr: ERROR: These branches have diverged. Use the merge command to reconcile them."
<jelmer> bronson: You can't push to an existing branch
<bronson> But that doesn't really make sense since this branch has never existed in svn.
<bronson> The branch in svn is empty.
<jelmer> bronson: Empty is an existing branch
<bronson> Hm, I'm not understanding...  How am I supposed to set up the svn-push?
<jelmer> bronson: from inside of the bzr branch, run something like:
<jelmer> bzr svn-push svn://host/repository-path/branches/mynewbranch
<jelmer> where svn://host/repository-path/branches exists but "newbranch" doesnt yet
<bronson> Ah.  And then I populate mynewbranch with another bzr branch, then push it all back up to the host repo.
<lifeless> moin
<brink_> Does bzr split work?
<jelmer> hey lifeless
<igc> morning
<abentley> lifeless: morning
<lifeless> hey abentley
<lifeless> public holiday here, so I'm not really around :)
<abentley> When'd you get back?
<abentley> brink_: yes
<igc> hi lifeless (who isn't actually around) :-)
<igc> hi abentley
<abentley> Hi igc
<igc> abentley: still in Oz?
<abentley> Nope, got home yesterday.
<igc> cool. Hope you had a good trip
<abentley> It was good, and I'm glad I went.  I'm missing the warm weather.
<igc> :-)
<abentley> Went from a t-shirt to a fleece shirt and down jacket.
<brink_> abentley:  I can use split to remove a directory, but the directory turns into a totally messed up branch.   I've tried every combination of upgrades from pack-0.92 I could think of.   None of them seem to work.  I'm using 1.1o on OS X.
<abentley> In what way is it messed up?
<brink_> It's messed up like this: bzr 1.1.0 on python 2.5.1.final.0 (darwin)
<brink_> arguments: ['/opt/local/bin/bzr', 'commit', '-msplit']
<brink_> encoding: 'US-ASCII', fsenc: 'utf-8', lang: None
<brink_> plugins:
<brink_>   difftools            /Users/joe/.bazaar/plugins/difftools [unknown]
<brink_>   extmerge             /Users/joe/.bazaar/plugins/extmerge [unknown]
<brink_>   launchpad            /opt/local/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
<brink_>   lessdiff             /Users/joe/.bazaar/plugins/lessdiff [unknown]
<brink_>   multiparent          /opt/local/lib/python2.5/site-packages/bzrlib/plugins/multiparent.pyc [unknown]
<brink_> *** Bazaar has encountered an internal error.
<brink_>     Please report a bug at https://bugs.launchpad.net/bzr/+filebug
<brink_>     including this traceback, and a description of what you
<brink_>     were doing when the error occurred.
<abentley> Please use a pastebin for that.
<brink_> Sorry.  What's pastebin?
<abentley> ubotu: paste
<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)
<brink_> Here is the error http://paste.ubuntu-nl.org/53801/
<brink_> Basically, I did a bzr split <dir>, went into <dir> and did a bzr commit -m"split"
<brink_> It seems like bazaar decided all the stuff from the root needed to be renamed into the subdirectory.   When I do a commit on it then it chokes.
<abentley> brink_: I believe a bug is already registered for that.
<abentley> I'm looking it up
<brink_> Is there a work around?
<abentley> bug 185211
<ubotu> Launchpad bug 185211 in bzr "bzr commit fails on imported branch when renaming a directory with non-ASCII-name" [Critical,Confirmed] https://launchpad.net/bugs/185211
<igc> bbiab
<abentley> I'm not aware of one.
<brink_> I do not believe that any of my characters are non-ascii.
<abentley> The traceback is the same, isn't it?
<brink_> That may be, but if so the title of the bug is incorrect.  My characters are all ASCII.
<abentley> Well, I would say these look like two symptoms of the same underlying problem.
<abentley> brink_: I can't reproduce the bug here, btw.
<abentley> Not with split, I mean.
<brink_> Not sure I can make a smaller example.  I'll give it a try.
#bzr 2009-01-19
<lifeless> meep
<lifeless> Raw size 3461880213
<lifeless> Compressed size 141152371
<lifeless> Compressed size 508555
<lifeless> thats the inventories from my main bzr repo
<davidstrauss> Merging with no common ancestor is not working properly for me.
<lifeless> Jc2k: ^ guess what the bottom compressed size is from
<lifeless> davidstrauss: what it is doing
<davidstrauss> lifeless: http://fourkitchens.com/blog/2009/01/17/distributed-version-control-provides-streamlined-alternative-vendor-branches
<davidstrauss> lifeless: I'm trying the commented operation, but with "bzr merge --revision=1..-1 bzr://vcs.fourkitchens.com/drupal/6" as the merge
<davidstrauss> lifeless: And I get TONS of conflicts
<lifeless> if you run bzr init and add in a new tree,then the files have new identity
<lifeless> so when you merge, and they have the same path, its a file name conflict
<davidstrauss> lifeless: how can i force a common ancestor
<lifeless> start from trunk rather than by doing 'bzr init'
<davidstrauss> lifeless: that's impossible. the whole point of this procedure is that you've started your own project on its own
<lifeless> I'm sorry if I'm not being really helpful - I'm trying to understand what your blog post is about
<davidstrauss> lifeless: i want people who have drupal projects in bazaar branches to be able to migrate to using our drupal bazaar branch for upgrades
<lifeless> davidstrauss: ah
<davidstrauss> lifeless: despite having no established common ancestor
<lifeless> so the -r x..y syntax will force an ancestor of x
<davidstrauss> lifeless: yes, but we get tons of conflicts
<lifeless> but the /content/ of the trees is unrelated, I would expect tons of conflicts
<lifeless> do you know much about bzr internals?
<davidstrauss> lifeless: not for content IDs
<lifeless> ok, very quick primer so my answers will make sense to you
<m4v> hi, quick question, does bzr track file permissions?
<lifeless> m4v: execute bit only
<bob2> only execute
<davidstrauss> lifeless: is there a way to force bazaar to understand that file name match = content match?
<lifeless> m4v: see etckeeper for tracking full permissions, which supports bzr
<lifeless> davidstrauss: each object that bzr is managing has a path and a fileid. The fileid is the globally unique ID for the object
<davidstrauss> lifeless: I can see that now, but that doesn't really make it possible to efficiently merge without common ancestry
<davidstrauss> lifeless: I mean, there *has* to be a way to merge efficiently without common ancestry
<lifeless> davidstrauss: this is a 1:1 relationship in any tree - 1 path, 1 id.
<lifeless> davidstrauss: over time you can get many different paths having the same id - when things are renamed and so on
<lifeless> davidstrauss: so, to do a merge with an unrelated tree
<lifeless> davidstrauss: such that future merges can be no-brainers
<lifeless> davidstrauss: you have to replace the fileid of *every* file that is in the source tree and in the target tree, with the fileid from the sourcetree
<davidstrauss> lifeless: is there a way to do that automatically?
<lifeless> then you have to do a merge across the two file ids using the specified base, or else the old fileids local changes wil be lost
<davidstrauss> lifeless: Is there a way to do that branch-wide?
<lifeless> you need to identify the common revision in both branches as well
<m4v> lifeless: alright
<lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up
<davidstrauss> lifeless: identifying the common revision in both branches is already part of my procedure
<lifeless> davidstrauss: yes, but there is no way to tell bzr at the moment, you only manage to tell it 3 of the 4 coordinates needed
<davidstrauss> lifeless: so is there an efficient way to resolve the conflicts?
<garyvdm> vila: I managed to get qbzr to use CLIUIFactory rather than TextUIFactory.
<lifeless> davidstrauss: it is scriptable in python
<davidstrauss> lifeless: has it been scripted?
<lifeless> davidstrauss: in fact, writing a custom conflict resolver could do it during the merge to make it seamless
<lifeless> 11:21 < lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up
<davidstrauss> lifeless: what would the custom conflict resolver look like?
<davidstrauss> lifeless: would it be in python or a shell command?
<lifeless> davidstrauss: I think it would be a subclass of bzrlib.merge.Merge3Merger, though I haven't written a custom one myself
<lifeless> http://paste.ubuntu.com/106710/ <- knit vs gc compression
<lifeless> short story, 141MB to 0.5MB, but 10 times slower at extraction, at the moment
<davidstrauss> lifeless: what is gc compression?
<lifeless> davidstrauss: its a new delta compression I'm evaluation for bzr
<davidstrauss> lifeless: is there a way to specify an external merge tool that runs in the shell?
<lifeless> I think the extmerge plugin does this
<lifeless> note though that I don't think it will handle the file id changing that you need
<davidstrauss> ok
<lifeless> fundamentally this needs code written to support it
<davidstrauss> lifeless: I think this is one area git's architecture shines.
<davidstrauss> apparently
<lifeless> well its certainly simpler there, for git or hg
<lifeless> its the inode abstraction that makes it complex to handle parallel imports
<lifeless> I encourage you to file a bug, this is something we should put a canned answer to in the core
<davidstrauss> ok
<lifeless> for now, people that want to move onto your branch would be best served by:
<lifeless>  - pull your branch
<davidstrauss> lifeless: would that handle the file ID mismatches?
<lifeless>  - apply their local changes as a plain patch (bzr diff -r x..y | bzr patch)
<davidstrauss> ok
<lifeless> commit that patch
<lifeless> then they are descendants of your branches
<davidstrauss> lifeless: so, basically, start fresh
<lifeless> yes
<davidstrauss> lifeless: this seems similar to when you bzr bind after divergence
<lifeless> gc is faster at compression, sweet
<jelmer> we have a gc?
<davidstrauss> lifeless: https://bugs.launchpad.net/bzr/+bug/318620
<ubottu> Launchpad bug 318620 in bzr "When merging two branches without common ancestry, Bazaar provides no means to map file IDs" [Undecided,New]
<lifeless> jelmer: groupcompress
<lifeless> davidstrauss: thank you
<garyvdm> What do you guys think about merging a number of revisions that are currently the tip of your mainline, with an older revision, just for the sake of grouping them together?
<garyvdm> I think I better pastebin a dag to explain this..
<lifeless> garyvdm: you can do it if you want
<lifeless> it just makes it look like a merge of a branch
<garyvdm> Here is my dag just to make sure we are on the same wave length: http://pastebin.com/d23836559
<jelmer> lifeless, ah, that makes more sense (-:
<spiv> jelmer: bzr-svn is working well for me these days, btw.
<jelmer> spiv, cool
<spiv> jelmer: the current 0.5 tip seems to be quite reliable at pulling from python's and twisted's repos.
<spiv> jelmer: I have some hackery to submit to make it import faster, though :)
<spiv> (e.g. don't import subertpy all the time, etc)
<spiv> jelmer: it even does find_tags at a bearable speed now :)
<jelmer> spiv, patches for import improvements are more than welcome
<thumper> hi ho
<thumper> I just went bzr init, and bzr stat
<thumper> and got a traceback
<thumper> is this a known bug?
<thumper> bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'
<jelmer> thumper, do you have loom installed?
<jelmer> thumper, I think you need a newer version of loom
<thumper> plugin installed, yes
<thumper> using it, no
<jelmer> it wraps bzr status but doesn't cope with a new argument that has been added to status
<jelmer> even if you're not using it
<thumper> :(
<jelmer> the last revision of the loom trunk fixes it
<thumper> WTF?
<thumper> :-(
<thumper> bzr log --line -r-10..-1 now gives be non-mainline messages
<thumper> this is very new
<thumper> and I can't go --line --short, as that doesn't work
<jelmer> yeah, I can confirm that has changed since 1.11
<thumper> can we change it back?
<thumper> it is really annoying
<jelmer> I'm not sure it's intentional or a regression that is a side-effect of the recent work on log
<thumper> I don't think it is intentional
<jelmer> probably worth filing a bug about
<thumper> igc: my log --line now shows non-mainline revisions
<lifeless> jam: are you around by chance?
<igc> thumper: I thought jam has sent a quick fix to pqm for that but it looks like he hasn't
<igc> I'll do it now
<thumper> igc: that'd be grand
<igc> thumper: in the pqm queue now
 * igc lunch
<thumper> igc: fantastic
<igc> thumper: try bzr.dev now and let me know if it's still broken
<thumper> igc: ok
<mwhudson> oops, 700 unread emails on the bzr list
<S11001001> hello all
<S11001001> I am maintaining a Trac with some modifications (my.desktopdoctorsinc.com) using a Bazaar branch.  I'm in the process of rebuilding it with upstreamable changes (~30% of the code) separated out.  I've built a bzr-loom with 7 patches so far, mostly non-interdependent, and can probably get a few more into upstreamable state.  I tend to merge upstream at new releases, the changes are typically larger than the total of all changes in my
<S11001001> branch, and there are usually 2-3 conflicts.  Question is, would I be better off sticking with loom, or keeping separate ordinary branches for these changes?
<lifeless> either is fine
<thumper> igc: lp:bzr is a few revs behind by the look of it
<spiv> thumper: it's 3 hours behind, on average ;)
<thumper> spiv: funny man
<thumper> so when is bzr going to host trunk on LP?
<lifeless> http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench
<pygi> goooood morning
<poolie> hello pygi
<pygi> poolie, :)
<pygi> chapter 1 coming to your address this week :)
<davidstrauss> lifeless: http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem
<vila> hi all
<igc> hi vila
<davidstrauss> What is the status of nested trees?
<Lo-lan-do> They're full of birds?
<jml> davidstrauss: they aren't there yet. interest is being renewed though.
<davidstrauss> jml: The Drupal project is very interested in getting this support stable.
<davidstrauss> jml: So we can effectively consider Bazaar for module development on Drupal.org
<sdboyer> jml: like, very interested :)
 * fullermd frowns.
<fullermd> NEWS is looking a little odd.
<jml> sdboyer, davidstrauss: I *think* abentley intends to work on it very soon.
<jml> but I couldn't say for sure.
<fullermd> poolie: It looks like r3940 spuriously added a whole separate section on top of NEWS
<sdboyer> jml: well, our timeframe for making a vcs switch is anything but clear, but nested trees would be a _huge_ deal for us, so if part of the hold-up is having a really rigorous use case to put the code through, that's something we can provide
<jml> sdboyer: cool :)
<luks> can't https://launchpad.net/bzr-scmproj be used as an alternative?
<jml> maybe!
 * jml doesn't know anything about it.
 * igc dinner
<davidstrauss> bzr-scmproj looks kind of clunky
<poolie> davidstrauss: it's trying to do it in a kind of minimal but useful way
<vila> luks: Looks like gary merged a conflict in qbzr trunk, just deleting it seems enough though
<poolie> hello vila
<vila> hey !
<fullermd> poolie: Did you catch my above?
<poolie> about news, or about nested trees?
<poolie> i saw both
<poolie> i'm making 1.11final tonight, and then will merge back and fix the news
 * fullermd nods.
<fullermd> Just making sure IRC didn't eat it   :)
 * davidstrauss smiles in anticipation of 1.11
<fullermd> Shucks, that means I have to update the port...
<LarstiQ> sdboyer, davidstrauss: yeah, that would help
<davidstrauss> :-0
<davidstrauss> :-)
 * LarstiQ thinks he may need to rethink the current approach
<sdboyer> LarstiQ: great, we should definitely talk, then. cept probably not at 5am my time :)
<LarstiQ> sdboyer: k, I'm in utc+1/+#
<LarstiQ> 3
<davidstrauss> sdboyer: It's the same time here
<LarstiQ> sdboyer: currently in .nl
<LarstiQ> and some of my time in .fi
<fullermd> Heck, it'll be that time here in about 15 minutes   ;p
<davidstrauss> I think Drupal could survive without nested branch support by simply having checkouts for each module. It's just not as elegant.
 * LarstiQ nods
<sdboyer> sure. my interest in having nested branches really working prior to us beginning our coding work is that i'd rather do it all in one fell swoop
 * sdboyer is wary that delaying a piece like that until later could very well mean that by the time nested branches are ready, our coders have found other itches to scratch :)
<sdboyer> not essential for implementation, but probably wise.
<sdboyer> however, unlike davidstrauss, who has been talking about needing to go to bed for two hours, i actually AM going to bed :P
<fullermd> A lot of things are easier to setup than to re-setup..
 * sdboyer agrees with fullermd wholeheartedly
 * sdboyer waves g'night
<LarstiQ> poolie: the only other moves on nested trees has been scmproj, right?
<poolie> i think so
<LarstiQ> hmkay
<LarstiQ> poolie: and/but there is still interest in getting it done?
<LarstiQ> (well, I know I'd _like_ to have it, but progress has been meh)
<Peng_> Oh god. Now that bzr-svn can finally handle a certain pair of branches, bzr-search can't!
<Peng_> lifeless: ping
<poolie> LarstiQ: interested in working on it?
<poolie> i heard you had a branch that fixed some subtrees bugs?
<LarstiQ> poolie: I have a couple of small fixes. From time to time I try to merge bzr.dev, but with the 100k diffs, it's not the easiest thing to do and not very motivating
 * LarstiQ needs to put more regular time into it to move it forward
<LarstiQ> poolie: I'd very much like to get this moving somehow, yes.
<poolie> hm
<poolie> well, send them up and hopefully we can gradually reduce the problems
<poolie> do they fix failures when a subtree format is the default?
<LarstiQ> they fix failures on subtree formats, I don't know about specifically that being the default, but with bugs in the usage of subtrees, it's not ready for that yet anyhow
<poolie> i'm just wondering what tests you added to get failures
<poolie> or what you changed
<poolie> since the trunk test suite does not fail, it's presumably not testing everything
<LarstiQ> poolie: right, lp:~larstiq/bzr/nested-trees is a continuation from Aaron's branch
<LarstiQ> poolie: which is, afaik, the only place where work on by-reference trees is
<LarstiQ> poolie: and by reference is I think where the brunt of the usecases are
<Jc2k> lifeless: omg is that groupcompress!?!?!
<james_w> pretty amazing :-)
 * LarstiQ goes to lunch
<poolie> hello jc2k, james_w
<james_w> hi poolie
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test case-insensitivity in 1.11 (released 19 Jan) | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Jc2k> hi poolie
<Peng_> Whee
<Lo-lan-do> I can't seem to find a description of this "groupcompress" thingy that everyone seems to happy about.  Any pointer?
<james_w> Lo-lan-do: I don't think so. It's a new compression strategy for storage of texts inside packs (or anything else really)
<james_w> it's a different way of doing deltas than what is currently used, which gives a large compression win, but has trade-offs in other areas
<Lo-lan-do> Okay.  So smaller repository sizes, I guess?
<james_w> currently decompression time, and I imagine annotation time, but that may not change as packs already damaged that
<james_w> yes, *massively* smaller in the current implementation
<Lo-lan-do> A new storage format too, I suppose.  Will it be compatible with the current ones?
<james_w> but that is at a cost of a 200% increase in decompression time, which is unacceptable in my opinion
<Lo-lan-do> Um, yeah, sounds not-very-nice indeed.
<james_w> yeah, it's just a change in the internal compression, so it will be a new format, but not a watershed one or anything.
<Peng_> Can throwing more Pyrex/C at the problem improve decompression time?
<Peng_> (I guess not if it's all in zlib.)
<james_w> perhaps
<james_w> first thing will be to try limiting the delta chains. That will lose some of the win in terms of compression, but may still lead to a better overall format
<poolie> it's currently only for inventory data
<poolie> so the point is to speed up commit and extraction
<james_w> ah, I thought it was texts too
<poolie> the decompression time is something that still needs to be solved before we go ahead with ti
<poolie> it could be applicable
<james_w> yeah
<james_w> is there any plan to move away from XML inventories?
<poolie> to file texts too
<poolie> however, for reasons i don't want to go into right now, it has some troubles with big files
<poolie> ie it'll store too many full texts
<poolie> (well, arguably too many)
<poolie> Lo-lan-do: it'll be backward/forward compatible
<poolie> in the usual way
<Lo-lan-do> Thanks
<yml> hello
<yml> I thought it was possible to do a partial checkout of a bzr branch. I would like to create a branch with only a subfolder ot the complete bzr repository.
<yml> Is it possible ?
<luks> it isn't
<yml> Thank you for the confirmation
<beuno> yml, you should, however, be able to export a directory
<yml> beuno: how would you do this ?
<yml> I mean my branch is hosted on launchpad
<beuno> yml, ah. I guess you can only do that with local branches
<igc> night all
<yml> beuno: I see. Thank you for your help
<beuno> g'night igc
<yml> I will create a symbolic link to put the folder in my pythonpath
<edreamleo> Help!  Bzr is, all of a sudden, acting bizarrely.  It started reporting changed files, but bzr diff gives nothing and bzr commit said "useless commit"  I tried installing bzr 1.11 and 1.10 with no improvement.
<edreamleo> I just tried bzr branch bzr/1.10 from c:\ (I'm using XP) and bzr appeared to install, but now I see no installed folder.
<edreamleo> BTW, "changed" files happen just after a fresh bzr branch.  Is there a cache that should be cleared?
<Jc2k> you dont do bzr branch bzr/1.10 to install a new version..
<edreamleo> Jc2k.  True, I installed bzr 1.10 from a downloaded zip file.  But I wanted to use bzr to grab bzr sources, and that appeared to work.
<Jc2k> does the output of bzr status say "unknown:" and then a list of file?
<edreamleo> No.  bzr status says modified.  The actual file appears random, but compares binary equal to the file in other branches.
<Jc2k> how odd
<edreamleo> By "appears random" I mean the actual file that is reported varies from time to time, or rather, from branch to branch.
<edreamleo> Yes!  Odd indeed.
<Jc2k> i had some weirdness moving branches between linux, flash drive and windows but this was over a year ago
<edreamleo> At first I suspected bad memory.  But the oddness happens on all branches.  Maybe a bit got flipped in a central .bzr folder?
<Jc2k> not really sure, im not a dev and what bits of the code i know are related to the workingtree stuff
<Jc2k> *arent
<edreamleo> I wonder.  Does a fresh install change C:\Documents and Settings\HP_Administrator\.bzr ?  I suspect not.  Any reason not to trash this?
<edreamleo> Is there a trouble-shooting guide or FAQ?
<superm1> Hi guys.  I'm wondering how to push my tags to the main branch in LP without doing another revision.
<superm1> i can't appear to push because pushing requires a new revision
<Peng_> superm1: Push will push tags even if there are no new revisions.
<superm1> Peng_, is that only with newer versions of bzr?  I'm on hardy, so 1.3.1-1ubuntu0.1
<james_w> superm1: I'm not sure, how did you verify that the tags hadn't been pushed?
<Peng_> superm1: I don't think it's a new feature.
<superm1> james_w, i pulled from another computer that's regularly been pulling from that same branch
<james_w> ah, ok
<james_w> it's probably just broken then, I don't remember it changing
<superm1> okay, well surely i'll be doing another revision at some point from this branch then. the tags will get pushed up at that time at least
<Peng_> WFM in bzr.dev.
<Peng_> superm1: Does the LP branch support tags?
<Peng_> superm1: Does it have any tags currently?
<superm1> Peng_, oh you know what, i just tried to pull again and i *did* get the tag this time. it must have committed but there was just a delay before it was available
<Peng_> Oh.
<superm1> sorry for the chatter james_w and Peng_ but thanks for helping indicate that it should be working :)
<Peng_> superm1: If you're pulling from http://bazaar.launchpad.net/, there might be a (short) delay, yeah. There isn't one for bzr+ssh or sftp.
<superm1> Peng_, yeah i was pulling from http on the other computer, so that would explain it
<james_w> glad to know it works :-)
<james_w> there's a bug open about it not telling you what it's done
<james_w> "No revisions to push" should be extended to mention that it pushed some tags
<superm1> yeah that would be useful
<jelmer> james_w: Hi
<jelmer> james_w: Are you aware of any guides about using bzr-loom as alternative to quilt/dpatch for Debian packaging?
<james_w> jelmer: I'm not
<LarstiQ> beuno, mwhudson: similar to https://bugs.edge.launchpad.net/loggerhead/+bug/260547 when I try to run serve-branches proxied by an ssl apache site, links to ../changes or ../annotate drop back to http
<ubottu> Launchpad bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option" [Medium,Triaged]
<bvk> hi, is there any quick way to branch lp:bzr instead of std bzr branch lp:bzr ?
<LarstiQ> beuno, mwhudson: should I make a new bug, comment on that one, fix it if it is easy to do?
<bvk> it never gets finished for me :(
<LarstiQ> bvk: your two alternatives are the same?
<beuno> LarstiQ, fix it is always the first option  :)
<beuno> if not, I think a comment on the bug is useful
<LarstiQ> beuno: it is an area I'm rather unfamiliar with
<LarstiQ> but I'll have a go
<LarstiQ> beuno: any hints on where to start looking?
<jelmer> bvk, if you mean an alternative URL, try http://bazaar-vcs.org/bzr/bzr.dev
<bvk> LarstiQ, jelmer: no, i am looking for any tarbal with repository. is such a thing available anywhere?
<LarstiQ> bvk: specifically to get one copy of bzr.dev? I could generate a tarball for you
<jelmer> I'm curious though as to why branching lp:bzr doesn't work for you
<bvk> LarstiQ, jelmer: no, i tried both urls, lp:bzr and http://.../bzr.dev :-( but both timeout from my computer always :(
<LarstiQ> bvk: or do you mean, for a given launchpad branch, does it support downloading a snapshot tarball?
<bvk> LarstiQ: yes, that would be of great; thanks
<bvk> LarstiQ: no, my problem is 'bzr branch lp:bzr' always timesout and doesn't get finish. its too slow
<LarstiQ> bvk: ok, it would be good to solve that if possible, but a tarball is coming up for you
<bvk> LarstiQ: thanks LarstiQ
<LarstiQ> bvk: http://richtlijn.be/~larstiq/bzr.dev-20090119.tar.gz
<LarstiQ> bvk: that is my ~/src/bzr/bzr.dev as of now
<LarstiQ> bvk: the file is ~5M, if that is too big, I can make a tarball of it after a `remove-tree`
<LarstiQ> you would then have to `bzr co .` after unpacking and cding
<bvk> LarstiQ: 5MB is fine, i can easily download that.
<bvk> LarstiQ: Is the branch with full history is of only 5MB? Then why was bzr took more than half hour and still didn't complete :(
<Peng_> I think LarstiQ left out the repo.
<LarstiQ> hmm, good point, I recall it being 40~ ish
<bvk> well, i was looking for a branch with full history :(
<LarstiQ> bvk: it does seem to be so
<bvk> btw, is there any way to make a branch with partial history? say, like 50 days history?
<LarstiQ> meh, still not looking at the right place
<Peng_> bvk: No, there's not.
<LarstiQ> bvk: --stacked might help you
<LarstiQ> though it does not do it like that
 * Peng_ watches bzip2.
<Peng_> bvk: http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar -- it's almost 100 MB, and you'll have to run "bzr co .".
<Peng_> Ehh, http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.bz2 saves about 10 MB.
<LarstiQ> hth do I end up with a working standalonish branch but it's .bzr/repository is empty
<Peng_> .bzr/repository exists but is empty?
<Peng_> Maybe it's a stacked branch?
<LarstiQ> yeah, it is...
<LarstiQ> bvk: well. That explains why it is so small.
<LarstiQ> and why logging all took longer than expected
<Peng_> http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.gz saves almost as much as the bzip2 version, and I'm going to stop now.
<Peng_> Thank goodness I don't have p7zip, lrzip and lzma on that machine. ;)
<LarstiQ> :)
<LarstiQ> nullzip? ;)
<Peng_> "bzr branch"'s new progress bars are neat. Reminds me a bit of all the info git gives, only prettier. ;)
<LarstiQ> bvk: if you do continue downloading my tarball, you should end up with a stacked bzr.devc
<bvk> okay, i just found out that i was using bazaar 1.5, where as latest one is at 1.11
<Peng_> bvk: Ok, but 1.5 should work fine.
<Peng_> Well, it'll probably be slower and use more RAM than 1.11, but it'll *work*.
<bvk> i just did 'bzr co .' in LarstiQ's 5MB tree and i got 'Bazaar Branch Format 7 (needs bzr 1.6)\n' :-(
<bvk> i will upgrade my bzr and will try 'bzr branch lp:bzr' again
<Peng_> Well, 1.5 can branch from lp:bzr fine.
<Peng_> Or http://bazaar-vcs.org/bzr/bzr.dev/
<bvk> Peng_: my problem is that it takes too much time. I waited for half an hour and it didn't finish
<Peng_> Cool, lzma saves close to 20 MB, and that wasn't with the best compression.
<Peng_> bvk: You can't wait half an hour? What kind of Internet connection and computer do you have? Not some Pentium II on dial-up, right?
<Peng_> Ohnoes, bzr.dev has a new revision. Now my tarballs are out-of-date. :P
<bvk> Peng_: mine is macbook with 256Kbps internet
<Peng_> bvk: 256 Kbps? Yeah, that could do it...
<Peng_> ...It'd take you a long time to download 100 MB, wouldn't it?
<LarstiQ> bvk: my tarball should give you a workingtree of bzr.dev at a recent revision, plus .bzr/ bits to act as a stacked bzr branch
<bvk> Peng_: true...but its UI always made me think it hung and i would endup either killing it in the middle (impatient :D)
<LarstiQ> bvk: so if you extrac that, you can run the bzr _in there_ to branch with
<LarstiQ> just run path/to/extracted/bzr.dev/bzr branch ...
<Lo-lan-do> I usually try a "watch du -hs .bzr" when I wonder if it's stuck.
<Peng_> bvk: Well, it probably wasn't hung. And the next version (not today's 1.11) should have much a much more active progress bar when branching.
<LarstiQ> Lo-lan-do: did you see the progress indication that's not in 1.11?
<LarstiQ> Lo-lan-do: it succeeds in subjectively making me feel it's waaaay faster
<LarstiQ> Lo-lan-do: achieved by actually giving information :)
<Lo-lan-do> LarstiQ: I've grown used to just switching to another virtual desktop for a while :-)
<Peng_> Hmm, it's kind of creepy that the server lets me monitor how far along bvk's download is, and how fast it's going.
<Peng_> Lo-lan-do: You should try it. It's very nice. It gives a running count of the revisions downloaded.
<LarstiQ> Lo-lan-do: I picked up that skill when I was on cable. 8kbs up/down combined. Cable modem attached via serial to the pc. Best idea EVAR
<Lo-lan-do> Peng: I'm switching back and forth between 1.5 and 1.11rc1 these days, actually.
<Peng_> Lo-lan-do: 1.11 final is out. :D
<Lo-lan-do> 1.11rc1 seems nice, but the corresponding bzr-svn version takes half an hour for every operation I do on a branch bound to a remote SVN repo, so I often downgrade back to a version that "only" takes four minutes.
<Lo-lan-do> Not in Debian yet => it doesn't exist :-)
<Lo-lan-do> (I keep pestering jelmer about it, but I also try not to burn him out)
<jelmer> Lo-lan-do: :-)
<jelmer> Lo-lan-do, I'm trying to get 0.5rc2 out today, hopefully I can have another look at your performance regression after that
<Lo-lan-do> jelmer: I'm trying to single out a bug in svn-import, too :-)
<jelmer> Lo-lan-do, argh, and I just got the bug count in bzr-svn back to < 30 :-)
<LarstiQ> beuno: it looks to me like it may be a bit more complicated than trying to replicate the patch *somewhere*
<Lo-lan-do> jelmer: Okay.  Just ping me when it's < 29 then :-D
<beuno> LarstiQ, a comment on the bug about the https is fine then  :)
<beuno> you did install python-pastedeploy, right?
<LarstiQ> beuno: yup
<LarstiQ> beuno: and it's working fine for my http vhost
<LarstiQ> beuno: added a comment
<LarstiQ> lifeless: is bicyclerepair completely bitrotted?
<jelmer> any versionedfile API experts around?
 * LarstiQ hides
<jelmer> LarstiQ, nevermind, already found the problem
<jelmer> KnitCorruption caused by a text revision that has the same parent twice
<jelmer> Lo-lan-do, never mind me, it's actually at 27 already :-)
<Lo-lan-do> jelmer: Does 0.5rc2 change anything related to deleted files by any chance?
<jelmer> Lo-lan-do: some things - what's the error you're seeing?
<Lo-lan-do> bzr: ERROR: Unable to find file id for child 'editreleases.php' in 'gforge/www/project/admin' in <RevisionMetadata for revision 999, path branches/Branch_gforge in repository 'c3c08832-fc22-4c88-9867-b2b84583e700'>.
<jelmer> ah, good chance that's fixed in rc2
<Lo-lan-do> At first I suspected that there was a problem with repacking (since I seem to remember it happens on or near revisions 10^n), but that's apparently a different problem.
<Lo-lan-do> I'll try using http://people.samba.org/bzr/jelmer/bzr-svn/0.5 then, see if it helps.
<jinRooma> so if i push to an ftp server, does it upload every file, or just the modified and new ones?
<Peng_> jinRooma: It uploads the new revision data.
<jinRooma> Peng_, when you say revision data, do you mean the actual files from the project
<Peng_> jinRooma: No, I mean the data in .bzr.
<Peng_> jinRooma: Push doesn't deal with working tree files; it deals with revisions.
<jinRooma> ok i see. THe way i want to use it is, i work offline on my project, and i then synch it with the server on a daily basis
<Peng_> jinRooma: In answer to your question, it only uploads the new data.
<Peng_> (Well, it will sometimes download some of the old data, combine it into fewer files, and upload it again, but that shouldn't be a big deal.)
<jinRooma> I see, so bzr does do some analysis / comparison of local & remote, and make decisions based on this. its not just a dumb upload
<Peng_> jinRooma: Right.
<Peng_> Now, bzr isn't the fastest vcs ever, but you have to give it *some* credit. :P
<jinRooma> its the only vcs i have used, for some reason could not get my around sub version and cvs
<jinRooma> but im using it mainly for back up than versioning
<jinRooma> ... which is primitive but better than nothing
<jelmer> LarstiQ, any idea what could cause a versionedfile revision to end up with the same parent twice?
<jelmer> get_parent_map() seems to filter out the duplicate parent unfortunately, but add_lines() complains
<jinRooma> i should probably use rsync or some such for my needs
<LarstiQ> jelmer: I don't know, but yesterday I got my bzr.dev in a state where I can't revert because I have two parents or some such
<Peng_> Does anyone else care about my bzr.dev tarballs, or can I delete them now? bvk?
<bvk> Peng_: you can delete it now; thanks a lot
<bvk> :)
<Peng_> bvk: Alright.
<Lo-lan-do> jelmer: Back to 28, I'm afraid :-/
<Lo-lan-do> (Report sent, off for dinner, back later if you have any insights)
<jelmer> Lo-lan-do, :-(*
<jelmer> rocky, hi
<jelmer> rocky, I've worked around the bug you were seeing, but I think it's a bug in bzr.
<rocky> jelmer: heyo
<jelmer> (not committed to 0.5, as it degrades performance, especially on large trees)
<jelmer> http://samba.org/~jelmer/tmp/test-text-existance.diff
<rocky> hm
<jelmer> hopefully one of the australians can shed some light on the actual problem when they wake up
<rocky> hehe
<jelmer> alternatively, there's a one-line fix to bzr that will work around it without any performance regressions
<jelmer> Lo-lan-do, ENOBUGREPORT
<bvk> hi, is there any bzr plugin that would allow me to maintain bugs (and messages) within the code repository?
<jelmer> bvk, You mean something like be (BugsEverywhere)?
<jelmer> see bugseverywhere.org
<bvk> jelmer: well, i don't know about bugseverywhere; let me check it out
<jelmer> rocky, alternative test http://samba.org/~jelmer/tmp/fix-add-records-dupe-test.diff
<bvk> jelmer: yes, it is what i was looking for. thanks
<mwhudson> LarstiQ: i'd actually just noticed something similar the other day
<mwhudson> LarstiQ: file a bug, i guess
<Lo-lan-do> jelmer: http://bugs.debian.org/512325
<jelmer> Lo-lan-do, thanks, just found it
<jelmer> I'm trying an import now, at r6132 atm
<Lo-lan-do> I was puzzled by the fact that it copies something like 11k revisions even though there are less than 7k in the SVN repo.
<jelmer> Lo-lan-do, Some svn revisions probably cause multiple bzr revisions
<Lo-lan-do> I supposed that much.  Like, maybe some commits touched files in several branches at once.
<Lo-lan-do> Not very important anyway.
<flacoste> i've got a problem with bzr-svn repository
<jelmer> hi flacoste
<flacoste> hi jelmer!
<flacoste> I have a bzr-svn branch tracking Windmill repository
<flacoste> they moved to a failover server
<flacoste> and now I get the following error when I do bzr pull
<flacoste> http://svn.getwindmill.com/trunk is permanently redirected to http://svn.getwindmill.com/trunk/
<flacoste> bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Chemin '/windmill/!svn/vcc/default' non trouv\xc3\xa9", 175007)
<flacoste> i can load the URL in the browser fine
<flacoste> In English, the message reads "Path '...' not found"
<jelmer> flacoste, This fails for me as well:
<jelmer> svn ls http://svn.getwindmill.com/trunk/
<flacoste> hmm, yeah, they just found that out :-)
<flacoste> ok, it's probably an error on their end then
<flacoste> sorry for the noise
<jelmer> np
<jelmer> Lo-lan-do, did you remove the svn-cache as well as the bzr repository prior to trying the import?
<Lo-lan-do> Ah, damn.  No, I didn't.  Should I do that?
 * Lo-lan-do tries
<lifeless> -> LCA
<lifeless> jelmer: compressbench may interest you, for your xdelta apply/create code
<lifeless> Jc2k: did you see my gc stats?
<jelmer> lifeless, 'morning
<jelmer> Lo-lan-do, oh, never mind
<jelmer> Lo-lan-do, just reproduced it
<jelmer> lifeless, cool, I'll have a look
<jelmer> lifeless, still there?
<Jc2k> lifeless: yes
<jelmer> lifeless, quick question about knits
<Jc2k> lifeless: my reply was something like "omg thats groupcompress?!?"
<lifeless> Jc2k: :)
<jelmer> lifeless: what are the contents of node_refs ? The first part of the tuple are the parents of the text, what is the second?
<lifeless> jelmer: node refs in indices is a list of lists of keys
<lifeless> jelmer: for knit mapped packs
<lifeless> jelmer: if the knit is defined with parents=True, delta=True, then the node refs length is 2, the first element is parents, the second is the compression tree
<lifeless> jelmer: in all bzr repositories, the second must be either empty, or the first parent.
<Peng_> lifeless: "-> LCA"?
<lifeless> but its intended to be arbitrary
<lifeless> Peng_: linux.conf.au
<Peng_> Oh.
<lifeless> jelmer: just not implemented yet
<lifeless> jelmer: if delta=False, parents=True, the node refs length is 1, parents only
<lifeless> jelmer: and False False is length 0
<jelmer> lifeless, I'm seeing weird errors where add_record() crashes because the existing node_refs[1] contains the first parent and we're trying to add node_refs[1] that is an empty tuple
<lifeless> jelmer: finally, delta=True, parents=False, is unimplemented in knits today
<lifeless> jelmer: thats when one repository has a text compressed, and the other has a full text. The cross check is overly strict - that is a bug
<flacoste> jelmer: they fixed it, but now when I bzr pull, it's refetching everything
<Peng_> lifeless: I wanted to bug you about something: One of my bzr-svn branches makes "bzr index" die, with "Did not find ids set([some file IDs])".
<lifeless> Peng_: please file a bug
<Peng_> lifeless: Alright.
<lifeless> Peng_: I'll ask you to run some custom code based on the details in the bug report, but I have a plane to catch now, so can't do it interactively
<jelmer> lifeless, Ah, thanks!
<jelmer> flacoste, did the repository change in some way ? Did you upgrade bzr-svn?
<flacoste> jelmer: you mean the SVN repository, i don't think so, and I haven't update bzr-svn in a while
<flacoste> jelmer: actually, i don't know if it will create new BZR revisions
<flacoste> the message is
<flacoste> Initialising Subversion metadata cache in /home/francis/.bazaar/svn-cache/7915dd7d-006c-436d-aff2-976aa4ca8641
<flacoste> and then fetching all revisions
<flacoste> but if that metadata is keyed by hostname, then i guess it would be normal
<flacoste> to refetch everything
<lifeless> flacoste: thats the svn repo uuid
<flacoste> the question is, will this create new bzr revisions
<lifeless> flacoste: its stored in the repository
<lifeless> flacoste: and yes
<flacoste> ok, so copying the repository files should preserve the UUID?
<lifeless> flacoste: I'm not sure exactly where it is stored, so can't answer that
<flacoste> "It's a scripted mirror of the original repo, so it should be the same."
<lifeless> god, that could mean anything
<flacoste> they are using svnsync
<Jc2k> flacoste: by default svnsync would have a different UUID, but i have a hack on bzr-mirror to preserve the UUID
<flacoste> Jc2k: can this help me?
<flacoste> i mean can I use this to trick bzr-svn in considering the two UUIDs as identical
<Peng_> Wow, "bzr check" sure spams .bzr.log.
<Jc2k> flacoste: i dont know enough about what you are encountering
<Kittens> hm...
<flacoste> Jc2k: i have a bzr-svn branch of Windmil and the main server became unavailable, they had to switch to a failover mirror
<flacoste> Jc2k: now when I do a bzr pull, it refetches every revision although there should only be about 4 or 5 that I don't have
<Jc2k> ah.
<flacoste> and I get:
<flacoste> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<flacoste> but that's not accurate
<Jc2k> their failover mirror will have a different UUID; do you know if you can svnsync from their mirror?
<flacoste> i don't know, i could check
<flacoste> how would that help?
<jelmer> flacoste: Do you have any local changes? If not, you can just "bzr pull --overwrite"
<jelmer> flacoste, if you had a svn checkout I think you would get errors as well since the UUID of the repository changed
<flacoste> i don't, ok, i'll do this
<Lo-lan-do> Does svnsync preserve the uuid?
<jelmer> Lo-lan-do, not by default I think
<flacoste> jelmer: but will this break merging?
<Peng_> jelmer: With the fix for bug 308353, will bzr-svn create any particularly convoluted history?
<jelmer> flacoste, merging from where?
<ubottu> Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/308353
<Peng_> jelmer: Because that's what breaks bzr-search. :)
<flacoste> jelmer: for example, if I merge the new branch into one made from the previous repository
<Peng_> lifeless: Filed bug 318935.
<ubottu> Launchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New] https://launchpad.net/bugs/318935
<jelmer> flacoste, that will break, since they are fundamentally different repositories
<flacoste> damn
<flacoste> anyway to hack it?
<jelmer> flacoste: Fix the upstream repository
<flacoste> and is there an easy way to do this?
<Lo-lan-do> jelmer: You're right.  But one can hack the mirror's UUID by hand, according to http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt
<flacoste> using svnsync?
<flacoste> aha
<jelmer> flacoste, svnadmin setuuid can do that for you
<jelmer> Peng_, Not that I'm aware of
<guilhembi> vila: still there?
<flacoste> jelmer: setuuid is only a 1.5 command and they are running 1.4 :-(
<Lo-lan-do> flacoste: What about "vi db/uuid"?
<flacoste> Lo-lan-do: is that safe?
<Lo-lan-do> It may not be safe at all, I have no idea.
<flacoste> lol
<Lo-lan-do> It's just that the uuid seems to be stored there.
<Lo-lan-do> If it's *only* stored there, then my guess is that it's safe, but...
<LarstiQ> Lo-lan-do: seems like it's time for some experimenting! ;)
<Lo-lan-do> Yeah, I'm currently "experimenting" with grep -r :-)
<Lo-lan-do> Only one result.  db/uuid.
<Lo-lan-do> Maybe it is safe after all.
<LarstiQ> what about the svnadmin setuuid source?
<wgrant> Lo-lan-do: I edited db/uuid in a fresh repository recently, and it worked fine.
<Lo-lan-do> I'll read that too, although I don't really care for it (I was only asking about uuids out of curiosity).
<flacoste> http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html
 * Lo-lan-do deflects stuff to flacoste 
<flacoste> there is a solution ^^^
<Lo-lan-do> LarstiQ: The source code has so many layers of indirection I gave up.
<wgrant> I think one of my branches has suffered from bug #302698. Shall I just push my local copy, overwriting the remote branch?
<ubottu> Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698
<alevine> anybody have experience with bzreclipse? When I import a project by branching it, it seems to freeze
<guilhembi> vila: sent a mail. Bonne nuit!
<Necoro> hey - is it possible to get the branch status w/o invoking bzr? - or at least to implement such things in C f.ex.
<Necoro> because I want to display whether a bzr branch has been changed in my shell prompt
<Necoro> and invoking bzr for this is way too slow
<jelmer> Necoro, no you really need bzr for that
<jelmer> you may be able to use the bzr service stuff though
<Necoro> (I already managed to get rid of the "bzr nick" and "bzr revno" calls)
<jelmer> (keeps bzr running in the background and makes incremental calls faster)
<Necoro> "bzr service stuff" <-- sounds interesting ...
<Necoro> documentation somewhere?
<jelmer> launchpad.net/bzr-service I think
<Jc2k> jelmer: wow, someone already made the crack i was daydreaming about!!
<jelmer> Jc2k, the ssh stuff you mean?
<Jc2k> jelmer: no, bzr-service!
<jelmer> ahh
<jelmer> where someone is jam I think
<Necoro> hmm - bzr-service seems to be outdated though
<Jc2k> yes :(
<Jc2k> hmm, didnt take much to make it work again tho
<Necoro> I needed to deal a bit with imports ... but as I don't know the bzrlib API, this can only be counted as workaround
<Necoro> it's fast however
<Necoro> instead of using TCP/Unix Sockets/FIFOs one could also implement this using DBus
<Necoro> (at least for unix)
<mwhudson> bzr-service needs more unix crack related to pty's and pipes
<Necoro> which would also allow to omit explicitly starting the service ;)
<Jc2k> i just added an import bzrlib and killed the call trace.something and it worked
<sevenseeker> I have been making changes to various files and just noticed I accidentally deleted an entire directory
<sevenseeker> how do I restore it and keep my changes?
<mwhudson> does bzr revert directory-you-deleted work?
<beuno> mwhudson, I think that if the directory isn't there, bzr will barf
<beuno> maybe not barf, but not do what you'd expect  :)
<sevenseeker> aha, yes... I don't know what I fat fingered earlier but it works great
 * sevenseeker is embarrased
<sevenseeker> thanks
<Necoro> hmm ... my shell prompt now works ;)
<Necoro> though there are still some rough edges with bzr-service
<alevine> how can I import an authenticated svn repo into bzr? when I try I get a 401 error and when I add username@ I get a traceback
<Necoro> and I guess, I'll take the bzr-service client instead of bzr whenever possible ;)
<Necoro> should be much faster
<jelmer> alevine, prefix the URL with "svn+"
<alevine> jelmer, thanks so much. did i miss something in documentation?
<alevine> it says its deprecated
<alevine> or is it just the fact that it cant figure out that it's subversion because it is authenticated
<jelmer> alevine, yeah, it's deprecated - it's a workaround around a bug in bzr itself
<Necoro> perhaps bzr-service should get polished and directly integrated into bzr ... this will probably be sufficient to reduce the "bzr is sooo slow" voices a bit
<alevine> jelmer, good to know i really appreciate you being here to tell me that
<jelmer> alevine, np
<jelmer> Necoro, bzr-service has several issues, I think they're mentioned on the main page
<Necoro> jelmer: only "unsecure" and "works only on windows" ... if you accept the last one as "who cares", the first one should be easy to fix
<Necoro> s/only/not/
<jelmer> Necoro: bzr service will run under a different terminal
<jelmer> that causes several problems for e.g. the GUI tools
<jelmer> and I doubt it supports overriding environment variables right now
<Necoro> hmm ok
<alevine> jelmer, do you happen to know if branching an svn repo will download every file for every revision regardless of it has changed or not
<jelmer> alevine, It will not download files when they have not changed
<alevine> hm, ok. thanks
<thumper> igc: I've confirmed with bzr.dev that log --line doesn't show non-mainline revs for me now
<_raz_> does anyone know why the .bzr dir and files have a wrong mode in 1.10?
<_raz_> I cannot do a brnch or pull on the remote directory via ftp
<_raz_> as it seems, the files have no rights at all, directories only u+rwx
<_raz_> according to the launchpad tracker that was already fixed
#bzr 2009-01-20
<igc> morning all
<james_w> heh, oldest bzr bug: https://bugs.edge.launchpad.net/bzr/+bug/3708
<ubottu> Launchpad bug 3708 in bzr "progress indicators are often buggy" [Wishlist,Confirmed]
<james_w> (open bzr bug)
<lifeless> Peng_: are you around?
<poolie> james_w, woo, i wouldn't say it's fixed now but it should be when the new system is used by all transports i
<poolie> imo
<lifeless> heh, compressbench was compressing 22K copies of the same text. Oooops.
<mwhudson> bet that compressed fairly well
<lifeless> mwhudson: knits got it down to 141MB
<lifeless> mwhudson: which is an epic fail if you ask me
<lifeless> mwhudson: gc got it to 500K
<lifeless> I was wondering how it managed to work on my laptop when I only had 1.5GB free and the corpus is 3.4GB
<alevine> Is there any way to exclude directories from a checkout? I am trying to import a svn repo into bzr which has a directory of huge binaries.
<bob2> 'slowly'
<lifeless> bob2: btw I'm here
<lifeless> alevine: not really; you could filter a fastexport stream to remove them, or something like that I guess; are you using bzr-svn?
<alevine> lifeless, yeah I am. Tried a branch with --stacked but it said that was experimental and I couldnt branch after that
<alevine> And when I try to download the whole repo the connection inevitably fails
<lifeless> alevine: try branch -r 1 svn://foo bar; cd bar; bzr pull -r 2; bzr pull -r 3 etc
<lifeless> (use bigger gaps if you like)
<alevine> hehe, oy
<alevine> suppose that will probably work
<alevine> thanks
<lifeless> hi arjenAU
<arjenAU> lifeless: hey. in Tas @ LCA
<`mousey> I've been reading the bzr documentation and noticed this "Bazaar has out of the box integration with Bugzilla, Trac and Launchpad's bug tracker."
<`mousey> how can I integrate my bzr repo with my bugzilla system?
<`mousey> ohhh i found it after some digging around on the offline hel
<lifeless> arjenAU: me too
<`mousey> does anyone know if it's possible to load up an external diff tool when diffing revisions in tortoisebzr?
<lifeless> `mousey: I'm not sure sorry
<lifeless> markh: ^
<arjenAU> lifeless: yea found out... duh
<lifeless> arjenAU: :)
<poolie> hi lifeless
<poolie> so does that mean all the compressbench numbers are wrong?
<lifeless> yes
<lifeless> :(
<lifeless> I have no sense of the vector yet
<lifeless> clearing enough disk space to find out
<alevine> lifeless, so once I get this huge svn repository downloaded, will I be able to quickly branch a subdirectory of this new bzr repo (assuming those huge binaries are not ancestors of anything I am branching)
<lifeless> alevine: maybe; it depends on exactly how you are converting; you should read the bzr-svn docs some more I think. svn and bzr are verry differnet in what they consider a branch
<alevine> lifeless, I guess what I'm asking is this: if I have a regular bzr repo that I branch that has folders a and b. a has txt files and b has 800MB files
<alevine> if i then branch repo/a will that copy over all the 800MB files?
<lifeless> alevine: the terms 'branch' and 'repo' are not interchangable; but you used them as such above.
<lifeless> alevine: a branch is a branch, you can't 'branch' a subdir of a branch, unless that subdir is itself a seperate branch
<alevine> lifeless, so you're saying that you can't make a subdirectory of a branch into a branch?
<alevine> i think you inferred that but I dont want to assume
<poolie> hi igc
<poolie> jelmer: don't suppose you're around?
<vila> hi all
<vila> poolie: I rarely saw jelmer here so early :)
<poolie> yeah, but you know students and sleep cycles
<poolie> how are you, vila?
<vila> hehe, students
<vila> fine
<igc> hi poolie
<igc> hi vila
<vila> Hey Ian
<poolie> vila, igc, do you want to catch up before i go? (i'm leaving tomorrow morning)
<igc> poolie: sure
 * igc dinner
<vila> guilhembi: ping
<guilhembi> vila: pong
<Oli``> I've got a local repo bound to a remote one so when I commit locally the changes are automatically pushed up. That's great and I'd like to keep that but I'd also like to trigger a remote update at the same time... Is that something I can do?
<bob2> branch, not repo?
<Oli``> sorry yes
<Oli``> so a cross between binding and the push-and-update pluging, I guess
<speakman> hi folk, i've a question about merging; Lets say theres three people A, B and C which all have their own branch of the same project. What if A makes a change, which B merges directly from A and person C merges from both A and B (which both seems to have modified branches, not knowing it's the same commit). Now when person A finally merges some changes from person C, the bzr log of person A will look very ugly, something like circular merge commits. Ho
<speakman> I see alot of people joined lately. I'll paste my question again:
<speakman> hi folk, i've a question about merging; Lets say theres three people A, B and C which all have their own branch of the same project. What if A makes a change, which B merges directly from A and person C merges from both A and B (which both seems to have modified branches, not knowing it's the same commit). Now when person A finally merges some changes from person C, the bzr log of person A will look very ugly, something like circular merge commits. Ho
<markh> speakman: even though your message seems to have been truncated, you will probably need to come up with a test-case which demonstrates exactly how person a's log is ugly and explaining how you thing it should look instead.  That doesn't sound trivial, so it might be better suited on the mailing list...
<speakman> markh: Thanks for your comments. I think I'm too new to distributed versioning to really have an idea how it should look like. But in one of my current project, and web developing project, there will be like three or four parallell developers which I will randomly merge from to get their eventually changes.
<james_w> speakman: it won't end up circular
<speakman> And if I'm person A and person B just merged from me (and commited it to his branch) it will, when I merge from him next time, look like he had done some real changes.
<markh> speakman: is this a real problem you are seeing, or a theoretical problem you are concerned you might see?
<james_w> speakman: yes, there will be an extra revision which is B's merge from you
<speakman> markh: we havn't started really yet, but I did some test with three different branches on my local machine and it ended up like this.
<speakman> Actually; we're trying to find a suitable workflow for improving the phpBB3 code base for our own purpose (we're running a public forum which will customize the forum code to our needs)
<speakman> If anyone have a better idea how to manage the development, I'm really listening :)
<markh> speakman: as james_w says, the log will show the merge - is that your concern?
<speakman> (i'm also thinking of another option where there will be a PQM which handles merge of patches/bundles through a mailinglist/mail account. But I've never setup an PQM and I'm not 100% sure of how it's working)
<markh> if not, you will need to be more specific...
<speakman> markh: person A's log will show persons B's merge of person A, and the log from merge from person C will show his merge from both person A and person B. Alot of spam in the log, but no code change.
<speakman> I'll make a test right away, please hold on.
<markh> speakman: alternatively, do a log of bzr.dev or something similar, and identify the revisions you think are noise?
<speakman> This is how it could look: http://pastebin.com/f27a1b1d
<james_w> speakman: if you don't like that then alias "merge" to "merge --pull"
<markh> speakman: IOW, oerson B should have done a simple 'pull' instead of a merge as his branch doesn't seem to have diverged.  james_w: is that correct?
<markh> but if person b's branch had diverged, he would have checkins which would have been merged and would be shown.
<markh> (IOW, only merge when you have actual changes to merge)
 * markh thinks... :)
<james_w> or investigate rebase, but it's not really recommended
<speakman> oh, never though of "pull". What's the difference with "bzr pull" and "bzr merge --pull" ?
<james_w> merge --pull will do a merge if needed
<james_w> pull will tell you a merge is needed
<james_w> if the branches have diverged then a merge is required
<james_w> the only way to avoid the extra revisions is to re-write history
<speakman> oh, so the default action should actually be "bzr pull" for everyone?
<speakman> and use only "bzr merge" when really needed?
<james_w> depends how you look at it
<speakman> (this should *really* be included in the docs!)
<markh> speakman: yeah, and yeah, it should!
<james_w> if you always use "bzr merge" then your mainline records what happened to your branch
<james_w> if you ever use pull then it synchronises your branch to the other, so the mainline shows what happened to their branch
<speakman> I think the Docs are really good in general, but it lacks real world issues. Something like a web developing project example.
<james_w> either one of those could be desirable
<james_w> speakman: if you point to where you would have expected to find this in the docs we can fix it
<Peng_> lifeless: pong :P
<markh> bzr suffers from an "embarrassment of riches" in some respects - too many possible workflows...
<speakman> james_w: I guess somewhere close to the "Workflows"-section imo
<speakman> I think the Workflows-section is really good, but the "Real world examples" sounds like a section on its own
<markh> it could be said there are lots of scenarios, but not much in the way of real world guidance...
<speakman> I think web developing (in php) is pretty commong
<speakman> -g
<markh> I think what I do is pretty common too ;)
<markh> (which isn't that ;)
<speakman> And the mess PHP programming can result in, it's a pretty hard case too ;)
<james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#team-collaboration-distributed-style
<james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#pseudo-merging
<speakman> markh: I don't like PHP very much myself, but I really think it's one of the most wide spread languages and even used
<james_w> so the doc explains the recommended workflow
<james_w> which you didn't want
<james_w> it could perhaps do with more on the difference between merge and pull
<markh> james_w: well, I'm not sure I agree with that :)  In fact, I've heard jam argue that in many cases, asking every core developer to use a *checkout* of the trunk is best practice - particularly to avoid the whole "overwriting of history" thing which push can do and the details of which currently escape me...
<james_w> yeah, and that's in the doc
<james_w> if you have a trunk
 * speakman 's reading the docs...
<markh> the broader point is that for someone completely  new, the "best practice" isn't always clear - especially when coming from a VCS which only has *one* workflow :)
<james_w> true
<speakman> markh +1
<james_w> but you appear to have decided that you wanted the no-mainline approach
<speakman> Anyone knows how "git" handles this?
<james_w> you just wanted the less preferred "pull" workflow to go with that
<james_w> which isn't documented, to reduce the number of documented workflows
<speakman> I could go with a mainline, but then more people than me must be able to merge things into it.
<james_w> it does "merge --pull" by default
<speakman> The main problem is more that I need to introduce an easy way to real bzr newbies (and not very skilled users at all) to make use of bzr through the PHP development.
<speakman> The actual problem is the PHP language which seems too easy to start with, and therefor will never filter some sort of people out ;)
<markh> speakman: so *my* preferred approach is to have a nominated "trunk" which people do *checkouts* from into a local dir.  They then *branch* this local dir into another dir for performing changes, and make checkins to the second dir.  When ready, they merge the second dir back into the first.  This merge will leave an uncommitted merge into the initial checkout.  They then test the merged changes, and perform a "checkin" into this checkout of
<speakman> (this would probably never be a big issue if it was skilled C programmers)
<speakman> markh: your message got truncated after "into this checkout of..."
<markh> speakman: i doubt it has much to do with the language :)  If the developers may struggle with the dvcs concepts, you may be best "emulating" SVN with pure checkouts everywhere...
<markh> ... They then test the merged changes, and perform a "checkin" into this checkout of the trunk - the checkin then actually changes the remote trunk.
<speakman> markh: They've no clue what's SVN...
<markh> speakman: conceptually, a single "checkout" they use and perform a simple "checkin" to with a single set of changes might be easier to convey...
<speakman> But your example above seems like a way that could work...
<markh> which would change my example to avoiding the use of the second dir completely...
<speakman> How about setting up an PQM and make them "bzr send" their changes?
<markh> ie, just do a checkout, make changes, test, checkin.
<markh> speakman: that's more than I know about, but probalby something you might consider further down the track...
<speakman> markh: that seems like the easiest way, but then I could go with SVN as well right? :)
<markh> speakman: well, with svn you would be *limited* to that approach
<speakman> With SVN I could setup an SVN server which they could commit their changes to, which even handles authentication and ACL. A thing i really miss with bzr serve.
<markh> but the more advanced developers could still use branches and merging if you use bzr
<markvandenborre1> hi! we're deciding on a vcs to use here
<speakman> markvandenborre1: go with bzr :)
<markvandenborre1> and my colleague is wondering if there is some kind of visual studio 2k8 integration
<markh> markvandenborre1: not a functioning one I am aware of :)  However, there is a good "tortoise" for general integration with explorer, "file open" dialogs, etc...
<speakman> markh: point taken, next thing is to setup permissions for some users to commit checkouts to the mainline. That wouldn't be a problem if the mainline pulled them itself :)
<markvandenborre1> I can only find a reference to a google summer of code project from 2007
<markvandenborre1> but no code at first sight
<markvandenborre1> speakman: I'd love to, but I need cold hard technical arguments
<markvandenborre1> over svn
<markh> speakman: if the trunk is behind sftp for example, then it manages write access IIUC.  I've no clue about auth and the smart-server though...
<markvandenborre1> markh: you mean tortoisebzr?
<markh> markvandenborre1: look at the tortoisebzr project on launchpad - the code is very current and very active - by me :)
<markh> yes
<markvandenborre1> ah, I see
<markvandenborre1> nice
<speakman> markvandenborre1: IIUC?
<speakman> sry, markh
<markh> "if i understand correctly"
<markh> markvandenborre1: the 1.11rc1 binaries are stable and include tortoise...
<markh> (the 1.10 binaries have a somewhat broken tortoise :( )
<speakman> markh: leaving ftps access to each committer will make the whole repository very vulnerable. If bzr serve could make use of authentication what would work as a command filter making sure people can only do commits and nothing else.
<markh> speakman: I'm afraid I'm not familiar with the various server options or their auth at all...
<speakman> There is another option; using bzr as a CGI/WSGI interface. Then use Apache's own digest for authentication.
<speakman> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#id80
<speakman> sorry: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#serving-bazaar-with-fastcgi
<markh> to clarify, I've no actual *interest* or desire for knowledge in that either ;)
<speakman> (here at my company we use smart serve with inetd and it works really good, but then it's a local protected network)
<markh> yeah, I've too much experience in integrating NTLM authentication with various servers to find it remotely interesting... :)
<markh> I'd rather keep auth as officially "somebody else's problem"
<speakman> NTLM?
<markh> windows auth
<speakman> Windows? (kidding... :) )
<markh> :)
<speakman> I still think there should be a real world use case based on web developing in the docs.
<markvandenborre1> +1
<markvandenborre1> but then again, I'm too lazy to write that out myself
<markvandenborre1> (doing other work to help free software, though, like helping to organise FOSDEM)
<markvandenborre1> markh: thx for the helpful hint on tortoisebzr
<speakman> After this web project has start working in a great maner, I might write one. But until then I really need a working solution to start with :)
<markh> speakman: there are lots of working options - the most appropriate depends on lots of things though
<markh> popd
<markh> oops :)
<vadi2> bzr break-lock isn't working for me for some reason: http://paste.pocoo.org/show/100522/
<vadi2> I tried it several times, but it doesn't want to break
<markh> vadi2: there is no evidence there of you having run 'bzr break-lock lp-46717904:///~vadi-mapper-dev/vadi-mapper/main/.bzr/branch/lock '
<vadi2> It still says just error, unsupported
<vadi2> http://paste.pocoo.org/show/100523/
<markh> sorry, no idea :(
<Peng_> "bzr break-lock lp:vadi-mapper
<Peng_> Augh, I keep copying newlines.
<Peng_> vadi2: "bzr break-lock lp:vadi-mapper"?
<Peng_> The error message giving the wrong URL is either a known bug or was fixed a month or two ago.
<vadi2> ey that worked, thanks!
<Le-Chuck_ITA> Hi there. I made the mistake to bzr add a big directory of never changing binaries, and now I have a huge .bzr. How can I "unversion" the directory and drop it from the .bzr repository forever?
<james_w> Le-Chuck_ITA: was this in the last revision, or has it been going on for a while?
<Le-Chuck_ITA> it has been going on for a while
<Le-Chuck_ITA> james_w: googling around it seems that the easiest solution is to re-init the repository!
<james_w> there's not a good answer for that yet
<james_w> you could re-write the repository to remove that data, but the code hasn't been written yet as far as I know
<Le-Chuck_ITA> james_w: thanks at least now I know this... will be more careful next time.
<awilkins> You could rebase your repo
<awilkins> branch it at -r <disaster -1>
<Le-Chuck_ITA> awilkins: that won't make the .bzr smaller
<awilkins> Hmmph, I'm not thinking this through
<Le-Chuck_ITA> and I like to pass the .bzr along by email :)
<awilkins> Once you've eliminated the revision with teh binaries you can branch it off to a separate repo and send that instead.
<awilkins> But I'm now not sure rebase will do that :-(
<Le-Chuck_ITA> thanks I may try later but the history until now was "monotonic" in the sense that we didn't erase anything yet :) Thus if I throw it away I am just fine
<awilkins> That's certainly the easiest route :-)
<vila> jam: ping
<jonnydee> can anyone tell me when I should merge and when I should pull changes?
<jonnydee> in my case I have a development branch and branched from it a testing branch. now when the development branch evolved should I merge or pull the changes into the testing branch?
<jonnydee> as far as I understand it a pull does pulls in the changes from the development branch which results in two equal branches (assumed the testing branch has not evolved separately)
<jonnydee> while a merge will reflect the merge in the testing branch's history
<jam> vila: pong
<jonnydee> so I get two different branches because the testing branch shows in its history a merge.
<jonnydee> am I correct?
<ollie> hey guys i need a little help getting my head around setting up a bzr repo
<ollie> i have created /home/bazaar/repository/web/project/example.com/
<ollie> then bzr init in example.com
<ollie> i then do a checkout from a ssh user e.g. /home/developer1/dev/example.com
<ollie> I have apache setup so that i can view the dev version for my developers e.g. dev1.example.com
<ollie> which has a document root at /home/developer1/dev/example.com
<ollie> but I want to have branches in my repo e.g. /home/bazaar/repository/web/project/example.com/developer1/ /home/bazaar/repository/web/project/example.com/developer2
<ollie> which i am not sure how to do
<ollie> or in fact how i would manage the branch changes and merge them back into the trunk
<ollie> the idea is that every developer has their own space on the server to develop and then i can push from the trunk to a live server when i am happy with the changes
<ollie> so really just after some advise or pointers. Odly, there seems to be very little that a google returns on this
<visik7> what's the problem with trac on bzr ?
<ollie> see http://bazaar-vcs.org/TracBzr
<visik7> someone told me that DVCS aren't very manageable  with trac
<visik7> 'couse it's slow
<ollie> https://launchpad.net/trac-bzr
<davidstrauss> How do you start the QBzr bundled with the Mac OS X .dmg?
<visik7> bzr qbzr
<jonnydee> regarding my case I just explained, please let me just know what you would do...?
<visik7> trac or launchpad ?
<visik7> I can't decide
<shankhs> hi
<shankhs> I installed bzr but bzr is not working behind proxy with authentication.
<shankhs> what to do?
<garyvdm> shankhs: What os are you using?
<garyvdm> I know you can set the $http_proxy environment var on linux
<garyvdm> Not sure if it works on windows though.
<garyvdm> export http_proxy=http://username:password@host:port/
<ericvw> I am getting GPG verify error when using the PPA repository.  Has anyone else been getting this error?
<james_w> ericvw: it's signed now
<james_w> you could add the key to avoid MITM attacks
<ericvw> james_w: how can I do that?
<james_w> apt-key
<james_w> you can get the key from keyserver.ubuntu.com
<james_w> id is 8C6C1EFD
<james_w> you can then check the fingerprint at https://edge.launchpad.net/~bzr/+archive/ppa
<james_w> if you are using the "bzr" ppa that is
<ericvw> james_w: Sorry I am a bit new to using apt-key and adding sources to apt-get, so how do I use apt-key with keyserver.ubuntu.com?
<james_w> dunno :-)
<ericvw> interesting.  I'll search around a bit.  Thanks!
<ollie> I am having a few problems with bzr ignore. The directory I am trying to ignore is not versioned and has been added using bzr ignore config/*. shows in .bzrignore but when i do a bzr st the folder comes up as unknown and the files in config/* are not shown when i do a bzr ignored. This leads me to believe that it has not worked properly. My terminal output can been seen here http://pastebin.com/m7deae95e. Any ideas?
<james_w> ericvw: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xD702BF6B8C6C1EFD is where the key is
<garyvdm> ollie: bzr ingore config
<garyvdm> *ignore
<ollie> Warning: the following files are version controlled and match your ignore pattern:
<ollie> concrete/config
<james_w> wget -O - "http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xD702BF6B8C6C1EFD" | egrep -v "^<" | sudo apt-key add -
<james_w> ericvw: ^
<ericvw> I got it
<ericvw> james_w: thanks
<james_w> no problem
<garyvdm> ollie: bzr ignore ./config
<ollie> garyvdm: is it possible to remove a rule?
<ollie> i edit it using vi but it just seems to come back
<garyvdm> Ollie: I normaly just edit .bzrignore by hand
<ollie> yeah thats what i am doing weird
<garyvdm> ollie: Not sure why
<ollie> bzr ignore ./config/* that should just ignore the directory config in the root dir right?
<Peng_> Your shell should expand that to all of the files in config.
<ollie> yeah it does so ./config/site.php then ./config/site_theme_paths.php (great) then config (doh). If i manually remove the last one config it gets written back in
<ollie> it seems to be trapped in a loop
<ollie> :(
<ollie> cracked it :)
<ollie> still don't see why bzr ignore ./config/site.php doesn't work
<ollie> but hey
<ollie> garyvdm: thanks for the help :)
<garyvdm> ollie: Pleasure
<sevenseeker> I am having trouble serving up my branch with the dedicated 'bzr serve' server
<sevenseeker> client says 'foo' not a branch
<sevenseeker> rather bzr://foo/root
<sevenseeker> bzr info on server branch says it is the 'branch root: .'
<sevenseeker> I am following the instructions at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server
<davidstrauss> sevenseeker: bzr:// requires a domain name or IP address
<sevenseeker> I have an entry in my /etc/hosts file, plus I tried using IP... same results
<LarstiQ> sevenseeker: what command do you run on the server, from which directory? And what exact command do you run on the client?
<sevenseeker> ok, I had a relative path for the --directory directive, that was the problem.  I read about that but remembered incorrectly that it applied to only the bzr+ssh option
<igc> morning
<beuno> igc, hi!
<beuno> just FYI, your plugin for caching revnos has made me extremly happy
<beuno> haven't started testing it, but I will tomorrow
<igc> thanks beuno. I thought you'd like it
<igc> would it help under loggerhead?
<igc> or in combination?
<beuno> igc, it would ROCK in loggerhead
<beuno> if we had that, and I understood how to access merge points partially, we may be able to solve a lot of the performance issues
<beuno> as well as change the underlying madness I've been wanting to re-write
<igc> beuno: so I think our goal should be to make the two plugins complementary
<beuno> it was on my ToDO list to write exactly what you did, so I'm very happy that just popped out
<igc> I don't think we want to cache twice
<igc> in two separate places
<beuno> igc, absolutely
<gsuveg> bzr push:parent works only with developer version?
<igc> beuno: I'm also planning to extend it to store depth information and to keep the data in top sorted order, allowing me to make log go faster
<beuno> igc, this doesn't, OTOH, make the initial hit cheaper
<beuno> ie, I'll have to generate the full revision graph at least once
<igc> beuno: right, but you only get that once after the tip moves
<igc> s/top/topo/
<beuno> igc, how about caching the merge-points between them as well?
<james_w> gsuveg: you need a fairly recent version
<james_w> 1.10 perhaps
 * james_w waves to igc and beuno 
<gsuveg> Bazaar (bzr) 1.11
<igc> hi james_w
 * beuno waves back to james_w 
<gsuveg> ive this and dont wokrs :)
<igc> beuno: one step at a time :-)
<beuno> :)
<beuno> igc, if the tip changes, the cache gets invalidated?
<igc> beuno: I thought it was a good effort for a day's work
<igc> beuno: currently
<beuno> igc, it would of taken me over a week, so it's an amazing effort for a day IMHO  ;)
<beuno> anyway, I'll start diving into it tomorrow, and will try to actually contribute patches and other useful things
<igc> beuno: if there are no merge revisions in the new revisions, I'd like to append to the cache rather than wipe it but that's not done yet
<beuno> ah!  that sounds interesting
<beuno> igc, I wonder if I combined the partial revno access jam worked on, with this plugin, I can make an even bigger cut in performance
<igc> beuno: I'd expect so
<jam> igc: as long as the mainline doesn't change, you can always append to the cache
<jam> so even if you merge, etc
<jam> so if old_tip is in branch.revision_history() then you can append new values
<jam> that said, only the lazy_revno branch is able to compute just some of the numbers
<jam> so you wouldn't save any time with bzr.dev
<igc> the trouble is that with really large branches like emacs and OOo, no amount of "make the algorithm faster" competes with "just cache the end result"
<jam> igc: sure, there are just various ways to reduce the amount needed to cache, etc.
<beuno> jam, by "some of the numbers", do you mean "only mainline revnos"?
<jam> beuno: if you don't change the mainline revisions, dotted revnos never change
<jam> so if you append new mainline revisions
<jam> the existing dotted revnos won't change
<jam> only if you 'push' a new mainline would things change
<vila> igc: at one point though, you'll hit the "loading cache result" is longer than "calculating only some revnos"
<jam> right, vila. that was the goal to get to
<jam> but really hard to achieve from my experience
 * beuno is very happy that the revno performance topic is back on the table
<igc> jam, vila: right.
<jam> I *am* curious what effect my lazy_revno branch would have on your timing numbers
<igc> for emacs, revno-cache comes in at 5M or so
<jam> since I think for emacs it would actually do pretty darn good
<igc> load time in 1.1 secs on my laptop
<jam> as they don't (yet) have complex merging ancestry
<jam> IIRC
<igc> right: 100K revs, 93K on mainline
<igc> so some merges but nothing like mysql say
<vila> igc: hehe
<mwhudson> igc: how are you persisting the cache
<mwhudson> ?
<igc> mwhudson: simply as revno\trev-id\n, one per line
<mwhudson> ah ok
<igc> it's readable :-)
<jam> igc: You could easily use a btree to do so
<jam> btw
<beuno> how bad would it be to create files with the revid as their name, and the revno as their content?
<jam> and then you could look up a single value without having to read the whole thing
<jam> I think you still need the merge depth
<vila> igc: should be easy to index.. (jam was faster :P)
<beuno> ah, btree's accomplish that
<vila> beuno: you want to create 100k files ?
<mwhudson> i guess for large caches (ab)using sqlite might be faster
<mwhudson> or yes, a btree
<gsuveg> bye
<beuno> vila, well, I want to access a revid without going through a big list. 100k files is a side-product. But I get it, it's not good  :)
<igc> jam: yes, I still want and need to cache the merge depth too.
<jam> igc: https://code.edge.launchpad.net/~jameinel/bzr/lazy_revno
<jam> If you want to play around with what I worked on
<jam> You may want to wait for the next mirror, since I merged bzr.dev and resolved the conflicts
<jam> or get it from http://bzr.arbash-meinel.com/branches/bzr/1.6-dev/lazy_revno
<igc> thanks
<jam> I think it currently has some bugs wrt numbering of ghost revisions
<jam> Partly because internally we are a bit inconsistent about how we handle them and NULL_REVISION
<nDuff> BNF-Austin, howdy.
<BNF-Austin> hello, that you Duffy
<davidstrauss> BNF-Austin: Greetings from near Mopac & US-183
<nDuff> all, BNF-Austin is Basim Faris, one of the partners behind NossaTV (an early adopter of Bazaar, several years ago)
<nDuff> davidstrauss, heh -- I'm over by Braker and 183.
<BNF-Austin> i'm off 620, close to Lakeway. Working from home.
 * nDuff is only working with NossaTV on an occasional and informal basis these days, and thus in the process of introducing BNF-Austin &c. to community support resources.
<BNF-Austin> Thanks for all the work that you has gone into. bzr. It has been great to use over the years.  Duff suggested that I join, so that I can bug you guys, when i make beginner mistakes as I try to manage remote bzr instances... thanks ahead of time, I will do my best to avoid wasting your time.
<jam> igc: so in my quick (and limited) testing, doing:
<jam> 'ian.clatworthy@canonical.com-20090120040338-yxg0r2ab45lqtks9'
<jam> is virtually instantaneous (.407s versus .377s baseline overhead)
<jam> but 'v.ladeuil+lp@free.fr-20081205140447-vk9s1veaqyy3ch9t' is 1.7s versus 0.377s overheda
<jam> then again, get_revision_id_to_revno_map is 2.87s
<jam> igc: I would also imagine that you could insert your existing revno-cache into the LazyRevnoMapper code, to seed it with interesting points along the way
<igc> jam: do you know what overhead calculating the merge depth (vs not) has?
<igc> for something like log -rX.Y.Z, we generate the revno map as one step and then topo sort again later to get the merge depth
<igc> I'm wondering if saving the merge depth in the first step would slow that step down or not
<igc> I could then change log to ask the branch for the merge depth
<igc> or perhaps branch.get_topo_sort()
<igc> if it's already been done, we wouldn't need to do it again
<igc> revnocache may as well save the revno,revid,depth in topo sorted order if it knows it
<igc> and monkeypatch branch.get_top_sort() if we add that
<igc> jam:^
<igc> beuno:^
<igc> s/get_top_sort/get_topo_sort/
<beuno> igc, I think that if it saved the depth, then the partial access issue would be solved
<beuno> igc, I do have a question about the revnocache plugin: does it work both ways?  revid -> revno and revno -> revid?
<beuno> ie, does it work for bzr log -rX?
<beuno> s/work/come into play
<beuno> or just for converting revids intro revnos?
<igc> beuno: it monkeypatches branch.get_revision_id_to_revno_map
<beuno> I'm testing it a bit, but I don't seem to see a difference in doing bzr log -rX with or without the plugin
<igc> right. try log -rx.y.z
<igc> then try it again
<beuno> aha!
<beuno> it makes a big difference with dotted revnos
<igc> or better still status -rx.y.z (as log in the mainline has speed issues well beyond just finding the revid to log)
<beuno> so mainline revnos are cheap-ish?
<igc> yes, they are now and have been in bzr.dev for some time
<beuno> awesome, it cuts time in more than half
<beuno> igc, but I don't see a difference when running: bzr log -rX -v --long
<beuno> that shows dotted revnos, shouldn't it improve significantly as well?
<mwhudson> does it only cache one way?
<igc> beuno: see my email reply to Alex sent minutes ago
<igc> mwhudson: branch.get_revision_id_to_revno_map() goes one way, but it's used by the code that maps the other as well
<igc> the API return the full map, not just one value
<beuno> igc, I can't find it. Is it a reply to the plugin announcement?
<igc> yep.
<beuno> igc, did it go to the list?
<igc> beuno: sorry. it has now
<beuno> igc, that's great, thanks
<beuno> igc, I intend to use get_revision_id_to_revno_map in loggerheadlib, so this is still fantastic news for me  :)
<jam> igc: For calculating merge  depth, we already do it to compute the dotted revno
<jam> I would guess we could compute it without it, but for now we have it "free"
<igc> jam: cool. thanks
<jam> igc: the original goal of the lazy_revno branch was to replace the object returned by get_revision_id_to_revno_map
<jam> just fyi
<pickscrape> Is it possible to write a custom HPSS "procedure" in a plugin, and call it from a plugin at the client end?
<jbalint> hi
<jbalint> if i have a contents conflict, does this mean bzr thinks this is a binary file?
<igc> jam: poolie is travelling today and I don't know if lifeless is here or not?
<igc> jam: did you want a call?
<jam> sure, you want me to start it?
<igc> sure
<supergonzo> Hi. I'm looking for some advice :-) I have managed to get colleagues to use bzr at work. But we are all using different editors and I would like to make sure tabs are replaced with 4 spaces when they commit. Any hint on how to do that (if it is feasible) ?
<LarstiQ> jbalint: if it doesn't say Text conflict? Yeah, I think so.
<jbalint> LarstiQ: is there any way to find out why it thinks so? i've checked this file,e there is no zero bytes of anything above 7f and teh extesion is .xml
<LarstiQ> jbalint: iirc there is a heuristic that checks the first 1024 bytes for some binary related characters, \0 but maybe more
<nDuff> supergonzo, there's a plugin called "bzr-whitespace" you might look at. It's more for warning or preventing checkins when whitespace is broken than silently fixing it, though.
<jbalint> LarstiQ: right, but i'm guessing thats not the reason
<nDuff> supergonzo, ...err, looks like it's been renamed to bzr-text-checker.
<LarstiQ> jbalint: though it shouldn't trigger that, BOM perhaps?
<glatzor> hello james_w, how can I call bzr bd inside of a python script?
<jbalint> LarstiQ: i dont see it http://rafb.net/p/Lxtgiy61.html
<supergonzo> thx nDuff. But plugins need to be installed in either everyone's ~/.bazaar directory, right?
<glatzor> jaavaaguru, should I call the binary?
<nDuff> supergonzo, generally, yes. If you use a PQM, you can have it run that check before accepting a merge request.
<supergonzo> I'm the company's PQM :-) I'll have a look at that plugin or come up with a similar one. I should take a look at setting up a PQM too... that's one more thing on my 2009' todo list.
<LarstiQ> jbalint: neither do I
<LarstiQ> jbalint: if I add that file to a branch locally, it sees it as text
<LarstiQ> jbalint: how about the other version it is conflicting with?
<jbalint> LarstiQ: is there any logging or something that would say why?
 * LarstiQ looks at the code
<jbalint> LarstiQ: looks to be the same
<emmajane> beuno, Hello. :) I have a question about the upload plugin for bzr: I'm wondering if it is possible to only one sub-directory instead of the whole working tree?
<beuno> emmajane, hi!  interesting you should mention that, I talked to vila about that yesterday
<emmajane> heh :)
<beuno> it's not currently, it will in the future
 * emmajane nods
<beuno> want to file a bug?
<emmajane> can do.
<lifeless> http://paste.ubuntu.com/107500/
<lifeless> jam: ^ real figures
<jam> lifeless: what is the "corpus" you are using?
<jam> The current inventory xml?
 * igc breakfast
<jam> Or the ones I uploaded to tungsten? Or ???
<emmajane> beuno, Ok, it's pretty terse, but I've filed a bug. Hopefully it makes sense. :)
<Peng_> lifeless: ping
<lifeless> jam: my bzr repo's inventories
<lifeless> jam: haven't got the test solid enough to move onto the ones you uploaded yet
<lifeless> hi Peng_
<jbalint> what is file_id
<Peng_> lifeless: You pinged me a couple days ago? :)
<garyvdm> jbalint: Each file has a file_id that remains contain even if you rename the file.
<garyvdm> *constant
<jbalint> garyvdm: alright, and thats not changing if you have a new rev, right?
<jbalint> is there any way to show the id for a given file?
<garyvdm> right
<garyvdm> Not sure - other than through code.
<garyvdm> jbalint: bzr status --show-ids
<lifeless> Peng_: yesterday :)
<lifeless> Peng_: I was going to ask if bzr-search was fast enough again now
<lifeless> jbalint: bzr inventory --show-ids | grep filename
<jbalint> thanks!, so if i have 6636@bce1ec22-edf6-0310-a851-a6aae2aa6c29 , does the "6636@" represent something specific or is that just an arbitrary path of it
<davidstrauss> Is there a non-ancient RPM for RHEL5?
<lifeless> jbalint: they are uuids, no meaning at all
<jbalint> lifeless: sorry i meant the parts before uuid, with the "@" symbol
<lifeless> jbalint: its all the uuid
<mwhudson> igc: i wonder if you're going to end up caching the merge-sorted revision graph
<mwhudson> (i think this can be updated on the introduction of new revisions in O(number of new revisions)-ish)
<Peng_> lifeless: Oh. I dunno. I've only indexed a few small branches, so I haven't paid much attention.
<Peng_> lifeless: Wait, I did index like 30 small branches (switching from the old to new index format), but I don't remember how that went.
#bzr 2009-01-21
<davidstrauss> I got annoyed with the lack of up-to-date RHEL/CentOS RPMs and built some. Anything I should do with them?
<igc> mwhudson: yes. I'm looking to do that
<mwhudson> igc: cool :)
<mib_65qsfnbw> I installed bazaar but it seems that bzr dosent work behind proxy with authentication...Is there any way to make bzr work?
<bob2> does including the password in http_proxy work?
<jbalint> how do i cancel a merge? (bzr status stil shows all pending merges0
<mwhudson> jbalint: bzr revert
<mwhudson> bzr revert --forget-merges if you want to keep the text changes
<jbalint> ah, reverted already , needed that forget-merges. thanks
<mwhudson> revert . will revert the text changes but not the merges
<jbalint> ok
<mwhudson> 'revert' on its own does both
<jbalint> oh i see
<alf> hello, I just branched bzr.dev and tried to upgrade it to --1.9-rich-root but the upgrade just hangs with 99% CPU
<bob2> that might be a bug, but why a rich root format?
<alf> bob2: for no specific reason, just playing around
<alf> I have found https://bugs.launchpad.net/bugs/177874 but in that case there is an explicit error (and the bug its quite old)
<ubottu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Critical,Fix released]
<alf> ubottu: you read my mind :)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<davidstrauss> First stab at updated RHEL/CentOS packages: http://fourkitchens.com/blog/2009/01/21/bazaar-111-bzrtools-1110-rpms-red-hat-enterprise-linux-5-centos-5
<davidstrauss> They seem to work.
<jbalint> is file_id format depends on the repo/branch format?
<thumper> jbalint: I think so
<jbalint> would it ever change by branching?
 * igc lunch
<mib_65qsfnbw> bob2: i tried http proxy but its saying that bzr: ERROR: socket.error: (111, 'Connection refused')
<mib_65qsfnbw> bob2: also http://www.mibbit.com/pb/Z1UtTw
<mib_65qsfnbw> so i filed a bug report
<lifeless> would anyone object to my putting back the set_plugin_path on import of bzrlib?
<lifeless> its really annoying not having it
<beuno> hi lifeless
<lifeless> hi beuno
<beuno> what would be the consecuences of doing that?
<beuno> I know it breaks stuff not having it
<lifeless> I don't see any consequnces
<lifeless> bzr --no-plugins shouldn't be loading stuff anyhow, and there is an omplicit plugin path anyhow
<beuno> hard to object to that  :)
<jbalint> anybody have a tip on where to find svn2bzr? this page is leading nowhere  http://bazaar-vcs.org/svn2bzr
<mib_65qsfnbw> Please help me in getting this removed: http://www.mibbit.com/pb/Z1UtTw
<lifeless> mib_65qsfnbw: I'm not quite sure what you're asking
<mib_65qsfnbw> I installed bazaar but it seems that bzr dosent work behind proxy with authentication...Is there any way to make bzr work?
<lifeless> the lp: syntax doesn't work, but all our other http stuff should work fine
<lifeless> as far as I know that is
<mib_65qsfnbw> lifeless: i am newbie to this bzr thing can you be please more elaborative ( what is http stuff)?
<lifeless> I'm sorry, I have a very bad connection here; I'll let someone else elaborate
<lifeless> igc: perhaps you are around and could help mib_65qsfnbw ?
<mib_65qsfnbw> lifeless: fine thankyou
<jearl> mib_65qsfnbw: I believe that what lifeless is saying is that while you can't check out the code using bzr clone lp:geany
<jearl> mib_65qsfnbw: you might be able to check it out using
<jearl> mib_65qsfnbw: bzr clone https://code.launchpad.net/~vcs-imports/geany/trunk geany
<jearl> mib_65qsfnbw: my own checkout hasn't finished, so I can't be sure :)
<mib_65qsfnbw> jearl:  "bzr branch http://bazaar.launchpad.net/~vcs-imports/geany/trunk" this one wotked for me
<mib_65qsfnbw> I got it by googling
<mib_65qsfnbw> jearl: Ho would I know which packages can be got using the above command( bzr branch http://bazaar.launchpad.net/~vcs-imports/genay(or any othe app)/trunk )
<igc> lifeless, mib_65qsfnbw: can't help right now sorry (heading to the hospital for the rest of the day)
<igc> see everyone tomorrow
<thumper> if the cbranch command does a branch then checkout, is there a sbranch (or something) that does branch and switch?
<fullermd> mib_65qsfnbw: Well, all of them.  lp:whatever is just a shortcut that looks up the actual URL.  It's just figuring out what the URL is...
<fullermd> You can probably figure it out by looking at the project on LP with a browser.
<mib_65qsfnbw> fullermd: OK
<mib_65qsfnbw> gotta go I have a lecture to attend see you in 2 hours...
<jbalint> how do i get svn-import to create separate bzr branches for my svn branches? I just get on bzr branch with each svn branch and trunk in the bzr branch
<lifeless> jbalint: have you checked the faq?
<jbalint> this one? http://samba.org/~jelmer/bzr-svn/FAQ.html
<jbalint> i try separately --scheme and bzr svn-branching-scheme --set
<jbalint> but it seems each time i run svn-import it reverts it to none in ~/.bazaar/subversion.conf
 * AfC wonders why bzr is so slow on his (borrowed) Ubuntu system.
<AfC> I tried --no-plugins to see if that made a difference, but only about 0.08s
<AfC> (just taking times from .bzr.log)
<AfC> whereas bzr status on a 2 revision 5 file tree is taking 1.2s
<AfC> Maybe I just didn't notice, but it sure feels slower than my other system. All things are not equal, of course, but...
<AfC> bzr 1.11 from PPA
<fullermd> Does it have the C stuff compiled?  Maybe that's missing...
<lifeless> AfC: is it a bound branch ?
<lifeless> 1.2s smells like a network round trip on this network
<davidstrauss> The operation mysteriously permeated the air with the lingering stench of latency.
<davidstrauss> :-)
<AfC> fullermd: I wondered about that, but `dpkg -L` showed a bunch of .so files, so...
<AfC> lifeless: no. Just a straight up been-working-on-this-brand-new-branch-for-only-an-hour-or-two.
<AfC> lifeless: (on the assumption that it doesn't change, I'll show you later in case you care to poke it)
<AfC> lifeless: (you have better things to do)
<davidstrauss> What's the process for getting packages listed on the downloads page? I know I can technically edit it, but I'm curious if there's some procedure for vetting the sources.
<Ycros> hey guys, I'm trying to pull in an external (svn) library into my project, and I'm wondering if branching it with bzr-svn, upgrading my repo format to 1.9-rich-root and bzr joining it in is the sane approach, or if there's a better way
<lifeless> AfC: please do show me
<AfC> lifeless: will do. I'm up the hill right now, but next time I cross paths with you I'll mention it.
<AfC> Ycros: that's an interesting question; I imagine there's no right answer, so you're probably best off to try a few different ways and see what you end up with.
<AfC> Ycros: (and then you'll be the expert! Ta-da, sucker)
<Ycros> I'm trying things out now
<Ycros> I think bzr join --reference might be what I'm looking gor
<fullermd> Apparently, it's nested-tree-week on #bzr...
<Ycros> maybe... hmm. What I really want is something like svn:externals. I'm not just what join --reference just did, it looks like the external tree now appears as a bunch of unknown changes
<vila> hi all
<davidstrauss> vila: hi
<ralph> Hi, can a revision's comment be changed?  Like    rcs -mrev:msg   ?  In a corporate setting, for political reasons, this can be required.  Or, as just now, I've put in a very misleading comment.
<ralph> The manual makes no mention of it that I can find, and I fear it's not possible;  the message being part of a revision's unique key in some way?
<luks> it isn't
<luks> if it's the last revision, you can uncommit and recommit it
<luks> otherwise you can do some trickery, but you will end up with technically a different branch (at least since the changed revision)
<ralph> Will that muck others up?  I've done a `bzr push' with the wrong comments in?   At the moment, I'm planning to do several uncommits in turn, saving the diffs as a patch, and then work forward again.
<luks> if anybody has a mirror of the branch, they will end up with diverged branches
<luks> the uncommitted revisions will *look* the same, but they will be different for bzr
<ralph> Thanks luks.  Does that stop simple `bzr merge' from working?  There's just the two of us.  I push and he sends back to me occasionally.
<luks> it doesn't, but then you will have two copies of each revision in the branch
<ralph> k, think it's worth doing to clarify comments.
<fullermd> Including the one with the wrong message.  Kinda defeats the purpose, especially in a nuclear scenario.
<luks> if you are just two, you can maybe tell him to pull --overwrite
<luks> oh, right, forgot about that :)
<ralph> Thanks, will look into the --overwrite option.  Basically, if he's no local changes then he can just --overwrite.
<fullermd> If you can talk other people into --overwrite'ing, it doesn't have THAT wide an impact.  Where it really gets ugly is when they've already started work on top of the old stuff.
<luks> yep
<luks> btw, bzr replay from bzr-rebase can save you some time doing the uncomitting
<ralph> Thanks.
<vila> try again guilhembi.. I want to ping you :)
<guilhembi> vila: hello! Yesterday evening my internet connection went down, and this morning it just went up a few seconds ago.
<guilhembi> After a second reboot of the livebox
<vila> here you are !
<vila> change ISP :)
<guilhembi> vila: bah
<glatzor> hello james_w, is it possible to use bzr bd inside of a python script?
<james_w> hey glatzor
<james_w> you could import it and run the various parts
<james_w> unfortunately there is quite a lot of logic in the Command class
<james_w> or you could just run it under subprocess
<lampliter> are there any bzr plug-ins for netbeans?
<LarstiQ> yes, I believe so
<lampliter> interesting.  Any pointers?  Using Google didn't reveal anything terribly useful
<lampliter> for what it's worth, I discovered that Emacs plus tramp is bzr aware
<LarstiQ> hmm, don't see it on the wiki at BzrPlugins, not at launchpad.net/bazaar
<lampliter>  and is not listed at net beans
 * LarstiQ trwals the mailing list
<jelmer> I don't think it was in a usable state yet though
<LarstiQ> lampliter: people have certainly talked about it on the mailing list
 * LarstiQ fails to find anything concrete right now
<lampliter> okay, I'll check there
<beuno> jam, I know I said it already, but having --short as my default changed my life completely  :)
<jam> beuno: I'm glad you like it as much as I do
<jam> I wish we could get away with making it the default
<sjokkis> hi, i'm trying to create a branch of my files in trunk. am i supposed to copy the files using the filesystem, or is there some bazaar-command that eludes me here?
<jam> without encountering the "not similar to everyone else" problems
<jam> sjokkis: "bzr branch" ?
<sjokkis> i tried that, but it tells me that trunk isn't a branch
<sjokkis> "bzr: ERROR: Not a branch: "/blah/blah/project/trunk/"."
<sjokkis> so what gives, jam?
<beuno> sjokkis, what command are you running?   sounds like you're adding extra stuff to the path
<sjokkis> i ran "bzr branch . ../branches/port" from inside trunk
<sjokkis> i can do this from inside my local checkout, right?
<beuno> sjokkis, you probably shouldn't use .
<beuno> so if you're inside trunk,  bzr branch ../trunk ../branches/port
<sjokkis> i get the same error doing that
<sjokkis> i think this was originally imported from svn using the bzr2svn utility. if that matters
<sjokkis> eh, svn2bzr
<ollie> hey wondering fi anyone could give me any advice or thoughts on a workflow setup for web development
<ollie> i have setup a repository on a dev box and given each of my developers vhost enabled checkouts of the trunk of my project
<ollie> so everyone does updates and commits from their own checkouts
<ollie> this just gives some simple separation
<ollie> I have not looked into setting up branches yet
<ollie> I now want to publish this trunk to a live box. I thought i could just do my live site as a checkout of this trunk
<ollie> and then manually do a bzr update from the live box to get the latest revisions
<ollie> i would then setup bzrignore to ignore the server specific settings files
<ollie> wondering if this is a good approach or whether someone could suggest something more suitable
<ollie> doh nobodies home :(
<sjokkis> beuno, jam: neither of you guys can help me figure out how to do this?
<jam> sjokkis: sorry, I'm a bit distracted right now.
<jam> To start with, figure out where the actual branch is at
<jam> cd trunk; bzr info
<jam> It sort of sounds like things may not be what you think
<NfNitLoop> ollie: That sounds like a reasonable workflow.
<jam> like maybe the branch is "trunk/foo"
<jam> or the branch is "project" and "trunk" is just a directory underneath
<sjokkis> seems the branch is one level above trunk/
<sjokkis> so yeah, the branch is project/
<NfNitLoop> ollie: If you're not worried about having a working copy on your live site, you could just "bzr push" there instead of pulling from there.
<sjokkis> that's fucked up...
<NfNitLoop> OH, wait, by "live site" you mean you're checking out working code (PHP or something?) into a web site.
<ollie> NfNitLoop: yeah
<ollie> through the cms extra files e.g. images will be added
<sjokkis> jam: what's the best way to sort this out?
<ollie> so i think i will have to merge new changes in
<jam> sjokkis: it sounds like you may want to do another conversion, but using "bzr-svn" instead of svn2bzr
<jam> specifically, if you have the bzr-svn plugin installed
<jam> you then run "bzr svn-import" to do the conversion
<NfNitLoop> ollie: well, if all you're ever doing is 'bzr pull' from your "trunk" branch, you shouldn't need to do any merging.
<sjokkis> well i've already done quite a bit of work since i moved over to bzr, jam
<sjokkis> jam: so if possible i'd like to keep my current repository. or export it. something
<ollie> NfNitLoop: ok. One thing i was thinkning was giving my developers each a branch instead of them all doing checkouts of the trunk. However i havn't much experience with merging from one branch to another
<jam> there would certainly be ways to get your newer changes brought across
<jam> there are other things we could do
<jam> but I have the feeling you really don't want to have things in your current layout
<jam> and without re-converting, it will be problematic to merge between branches, etc
<sjokkis> well i'll be happy to create a new layout etc
<sjokkis> i just need to keep my history etc
<sjokkis> etc
<james_w> if I merge 2 unrelated branches by just creating the revision with the appropriate parents then I can continue to use both branches and merge between them, is that correct?
<james_w> it's only the UI that prevents me from doing this by forcing me to do a cherry-pick merge, which leaves the branches with distinct revision histories?
<jam> sjokkis: so what I would recommend would be to try a new conversion, and see if that gets the layout you want
<jam> (don't delete your existing one yet)
<jam> and then we'll look at carrying across your more recent changes
<sjokkis> jam: i don't have root on the machine my repo is on. can i do this on another machine and move the repo afterwards?
<jam> sjokkis: As far as I know you can
<jam> I'm not sure what access you need to the SVN repo, but I'm pretty sure just read access
<jam> as you can use bzr-svn with repos that you don't have write access to
<sjokkis> jam: actually screw this. it's a smallish project, and i'm the only one working on it. we can just copy the files manually
<sjokkis> and forget about the history
<ollie> should the .bzr file show up as modified under bzr st. I would of thought that bzr wouldn't include this in its version control
<Peng_> It doesn't track the ".bzr" directory.
<Peng_> It will track files like ".bzrignore" or ".bzr-whatever-you-want".
<ollie> hmm
<Peng_> You sure it's actually ".bzr", not some sort of case-manipulated variation, or some Unicode oddity?
<ollie> well i made it using bzr ignore ./config
<ollie> so i guess bzr would of created the file in the correct way
<Peng_> You mean the file ".bzrignore"?
<ollie> just suprised me that this is included in the version historuy
<ollie> ye
<ollie> s
<Peng_> Oh. Yeah, it's versioned.
<ollie> thats a problem as i need to ignore different things on different systems
<ollie> so is that not possible
<Peng_> ollie: You don't *have* to version it if you don't want to. 'bzr rm --keep .bzrignore && bzr ci .bzrignore -m 'oops, stop tracking .bzrignore'"
<Peng_> s/'/"/
<ollie> is bzr ci the same as bzr commit?
<Peng_> Yeah.
<Peng_> It's an alias.
<ollie> ok
<garyvdm> ollie: Why would you want to ignore different things on different systems?
<ollie> its complicated :(
<awilkins> Anything in the inventory already will continue to be tracked though
<awilkins> Regardless of your ignore settings. And whether you ignore them or not :-)
<jam> ollie: If you need to ignore things on different locations you can:
<jam> a) ignore the things in both places
<jam> (if you are ignoring foo in place X and bar in place Y, ignoring foo and bar doesn't hurt anything)
<jam> b) Use the global ignore file in ~/.bazaar/ignore
<jam> which you can customize based on the machine you are no
<jam> on
<ollie> ok brilliant thanks a lot jam
<jam> c) If you ignore something and the "bzr add X" it will still be versioned, because versioning something supersedes ignoring it
<jrwren> I'm a little confused on send/merge and the docs aren't helping. Can I do a send & merge entirely offline (sneaker net) if a co-worker and I have branches with a shared common ancestory?
<LarstiQ> jrwren: yes
<LarstiQ> jrwren: and provided you include enough information in your merge directives
<davidstrauss> jrwren: bzr send -o filename
<davidstrauss> jrwren: and then bzr merge filename
<jrwren> i did bzr send -r REVNOWEBOTHHAVE.. -o filename
<jrwren> it fails on merge
<Peng_> What's the error message?
<jrwren> http://pastebin.ca/1314855
<jrwren> that was supposed to be a readable version of revision number we both have...
<Peng_> Does he really have it? "bzr log -r revid:ben@ben-pc-20090121162140-gx1ag11qswfwp556"
<davidstrauss> ooh, traceback
<davidstrauss> that's not supposed to happen
<davidstrauss> jrwren: have you confirmed the issue in bzr 1.11?
<jrwren> i have not. I'll try it now.
<jrwren> nope, I don't have that rev in my branch.  AFAIK, that is the rev to which I'm trying to get.
<jrwren> i skipped moving to 1.11 because it is rc1 a few days ago. I guess I should have done it then.
<jrwren> same error with 1.11rc1 http://pastebin.ca/1314868
<jrwren> maybe I need to include more information in my merge directives, but I don't know what that might be.
<jam> jrwren: my guess is that you don't have a proper mirror of the branch you are trying to merge into
<jrwren> normally use a centralized workflow, we commit/update from the same branch in the same repo.
<jam> "send" needs 2 branches
<jam> (not by my choice)
<jam> so you need 1 branch which is exactly what you started from
<jam> and then another which is the new stuff
<jrwren> why does send need 2 branches? can I achieve similar behavior with 1 branch ?
<jrwren> ah...
<jrwren> so he can branch -r 323 (our shared last match) and use that as the shared branch ?
<jam> basically, abentley felt that people made too many mistakes when trying to use 1 branch, so opted to not allow it
<jam> jrwren: right
<jrwren> thank you.
<jrwren> jam: this is the 2nd time you were of HUGE help to me.
<jam> I'm not sure whether I hope it is the last or not :)
<jam> I hope you don't need the help, but I'm always happy to help
<beniwtv>  hi all... I'm trying to check out a branch that lives on one of my servers, doing a bzr branch http://url/nameofbranch/ but it gives me ERRROR: <url> not a branch. It traced down that bzr wants to access the .bzr dir that loggerhead doesn't export and gives 404. So now I would like to know how to configure loggerhead and bzr properly so I can get my branches? Is there anything I'm missing?
<davidstrauss> beniwtv: are you trying to check out from  loggerhead page?
<beniwtv> davidstrauss: yes *ducks?* :)
<davidstrauss> beniwtv: loggerhead does not give bzr the data it needs to branch
<davidstrauss> beniwtv: it's just a human-usable browser
<LarstiQ> beniwtv: are you running it behind apache?
<LarstiQ> beniwtv: in that case you can configure apache to redirect .bzr to the right place
<jelmer> beniwtv, there is a open bugreport in loggerhead about supporting this
<davidstrauss> beniwtv: you may also want to look at "bzr serve" to allow public branching
<beniwtv> LarstiQ: No, loggerhead only. Should I use it with apache? Any tutorials on this?
<beniwtv> davidstrauss: OK, thanks, I'll have a look at that
<davidstrauss> beniwtv: I typically use Loggerhead for human browsing and bzr serve behind xinitd for public branching.
<davidstrauss> beniwtv: And I run Loggerhead behind an Apache proxy
<beniwtv> davidstrauss: I see. However, I would need two ports, for loggerhead and bzr serve. So if I want to have only one port, is this possible? (I would like that for simplicity)
<stavros2> hello
<stavros2> how can i add the bzr ppa key so the repo is verified?
<LarstiQ> beniwtv: what I do, is run loggerhead on localhost:8080
<davidstrauss> beniwtv: Yes, you would need two ports
<davidstrauss> beniwtv: To run bzr serve and Loggerhead
<LarstiQ> beniwtv: and then use apache with ProxyPass for public access
<davidstrauss> LarstiQ: Yes, but how do you combine that with allowing public branching? That's why I run a separate bzr serve?
<beniwtv> LarstiQ, davidstrauss: OK, thanks... That will get me going I think :)
<LarstiQ> davidstrauss: well, our 'public' branching goes via sftp://
<davidstrauss> LarstiQ: But then it's not a smart server
<LarstiQ> davidstrauss: correct
<LarstiQ> (or bzr+ssh)
<davidstrauss> I think it would be difficult to secure public branching over bzr+ssh
<LarstiQ> davidstrauss: I would like to provide the convenience of branching from loggerhead urls
<davidstrauss> LarstiQ: agreed
<LarstiQ> davidstrauss: secure? You mean, control access of who branches what?
 * LarstiQ is in a different environment :)
<davidstrauss> LarstiQ: no, in terms of preventing anyone from changing the "public" account password, preventing port forwarding, etc.
<LarstiQ> davidstrauss: so, for that, I'd use apache rewriting for http://loggerhead/branch/.bzr/
<davidstrauss> LarstiQ: that would work
<LarstiQ> davidstrauss: that rings even less of a bell. My situation is a bunch of developers in two rooms fully trusting everyone.
<stavros2> can i authenticate bzr packages?
<davidstrauss> LarstiQ: I'm doing things like hosting repositories for Drupal development
<LarstiQ> stavros2: Bazaar releases are signed with gpg, is that what you mean?
<LarstiQ> davidstrauss: aah. Right.
<davidstrauss> When I say "public" branching, I mean by Joe Internet.
<stavros2> LarstiQ: well, apt is telling me that they can't be authenticated and won't upgrade them
<davidstrauss> No authentication
<LarstiQ> davidstrauss: yeah, handing out shell accounts to Joe Internet is less of an idea :)
<LarstiQ> stavros2: ah, apt. What repository are you using, the ppa?
<davidstrauss> http:// is also not a smart server, right?
<LarstiQ> davidstrauss: it can be with some work
<davidstrauss> LarstiQ: I mean right now
<LarstiQ> davidstrauss: doc/en/user-guide/http_smart_server.txt
<stavros2> LarstiQ: yes
<stavros2> LarstiQ: for intrepid
<davidstrauss> I do have Loggerhead and bzr set up so you can check out http://vcs.fourkitchens.com/drupal/6 as bzr://vcs.fourkitchens.com/drupal/6
<davidstrauss> It's not too much of a pain
<luke-jr> how happy is bzr-svn with back-and-forth type stuff?
<jelmer> luke-jr, you mean pushing back into svn and then pulling from svn ?
<jelmer> luke-jr, it's quite happy about that (-:
<luke-jr> actually, I mean using 'bzr diff;bzr commit' and then doing 'svn up; svn commit' ;)
<luke-jr> I noticed 'bzr diff' in a Subversion WC actually worked
<luke-jr> even after an extra 'svn commit'
<luke-jr> but does it update the .svn info when I 'bzr commit'?
<jelmer> yes
<luke-jr> nice
<luke-jr> if I 'bzr branch' from a svn URI, make a bunch of commits locally, then 'bzr push', do my commits get to Svn repo as if they happened when I committed them locally? ;)
<jelmer> yes
<luke-jr> and finally, will Bad Things (TM) happen if I tell bzr-svn not to use svn props for metadata?
<jelmer> luke-jr: You can't do that when working in a .svn checkout
<luke-jr> yes, different scenario
<jelmer> luke-jr, if you do a push without svn props ("bzr dpush") then if you have a second copy of your bzr branch, it won't be able to pull from svn ("Branches have diverged")
<luke-jr> I see :/
<jelmer> luke-jr, you can also use bzr-svn 0.5 and svn 1.5 on the server side
<luke-jr> ?
<jelmer> that can use svn revision properties, which don't show up in "svn diff" and commit notification emails
<luke-jr> ah
<luke-jr> even over HTTPS?
<jelmer> yes, the protocol is not relevant as long as it's Subversion 1.5 on the other side.
<ollie> whats the process for merging treeless repo branches into a trunk? i have say /web/project/trunk/blog/ and /web/project/branches/tim/blog and  /web/project/branches/lucy/blog. The devs do checkouts of their respective branches into apache enabled directories so they can see their work at http://dev.lucy.project.com.
<ollie> However I am not really clear on how I would merge the changes within the branches
<ollie> and whether using branches like this is really the right approach
<jam> ollie: well, you need a checkout to do a merge
<jam> so you could do:
<jam> bzr co /web/project/trunk
<jam> cd trunk
<jam> bzr merge /web/project/branches/tim/blog
<jam> bzr commit -m "bring in Tim's changes"
<jam> etc
<jam> I'm not 100% sure if you are trying to automate something, or if I'm missing what you need
<ollie> the key thing is it needs to be done from a checkout
<luke-jr> bzr: ERROR: Invalid http response for https://svn.openmethodscorp.com/svn/VXMLB/vxmlb/branches/CCXML/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<jam> igc: what are you doing awake?
<jam> :)
<luke-jr> how do I tell bzr my auth info? :/
<ollie> jam: finding it a little tricky to create this layout when i am not 100% sure how everything in bzr works
<LarstiQ> luke-jr: you can use ~/.bazaaar/authentication.conf
<jam> ollie: well, I don't really know what you are trying to accomplish either. What content is going to be where, and why are you merging individual's blog content back into trunk anyway?
<igc> jam: well I'd like to be asleep but it just isn't happening
<luke-jr> LarstiQ: use it how?
<ollie> i am basicially building a dev box and live box. The idea is that each developer can work on a project then i can merge them into a live version and push/pull/update that onto the live box
<jelmer> luke-jr: Please prefix your URL with svn+
<LarstiQ> luke-jr: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
<LarstiQ> luke-jr: specifically for svn, you could use svn against the repo, make sure it stores your credentials, and then bzr-svn will pick up on that
<LarstiQ> luke-jr: you can give it a hint with https://user@..
<LarstiQ> luke-jr: (or do that via authentication.conf)
<luke-jr> LarstiQ: I already am using svn against the repo, it didn't
<luke-jr> "The svn+ syntax is deprecated, use https://svn.openmethodscorp.com/svn/VXMLB/vxmlb/branches/CCXML instead."
<LarstiQ> luke-jr: *blink*
<LarstiQ> luke-jr: I meant the subversion application itself, say, "svn ls https://svn.openmethodscorp.com/svn/VXMLB/vxmlb/branches/CCXML"
<LarstiQ> luke-jr: bzr-svn can use the ~/.subversion credentials store
<luke-jr> LarstiQ: I already have been using subversion itself for months
<luke-jr> on this same branch
<LarstiQ> luke-jr: ok, then providing your username should be all you need to do.
<LarstiQ> luke-jr: if not, something has broken down (what versions of bzr and bzr-svn are you using?)
<luke-jr> bzr: ERROR: Permission denied: ".": OPTIONS of 'https://svn.openmethodscorp.com/svn/VXMLB/vxmlb/branches/CCXML': authorization failed (https://svn.openmethodscorp.com)
<luke-jr> 0.10 + 0.5
<LarstiQ> 1.10 I hope, not 0.10 :)
<jam> ollie: sorry, grabbed some food. Anyway...
<LarstiQ> luke-jr: how did you specify the username?
<luke-jr> yes, 1.10
 * LarstiQ has a look at the bzr-svn buglist
<jam> I would say users should generally have a checkout of 'live'
<luke-jr> LarstiQ: I put it in the URI, and removed it from the error for security
<jam> and then another place where they work on their content
<jam> when they want to publish they would do
<LarstiQ> luke-jr: ok, that should have done it. Something broke then.
<jam> cd live-checkout
<jam> bzr up
<jam> bzr merge ../my-work
<jam> bzr commit -m"Publish XXX"
<luke-jr> AHA
<luke-jr> wrong username :x
<deepjoy> .list
<luke-jr> is it possible to do a copy with bzr-svn?
<luke-jr> jelmer: LarstiQ: http://pastebin.com/m1231cf6c
<jam> poolie2: ping
<luke-jr> does 'bzr mv' work with bzr-svn right, or does it just add?
<luke-jr> meh
<luke-jr> bzr dpush at least doesn't send timestamps right â¹
<jml> LarstiQ: I haven't done anything
<LarstiQ> jml: k
<beuno> igc, you rock
<kfogel> In ReST format (on http://bazaar-vcs.org/Scenarios/Bugfix), how do I do a link to Scenarios/ReviewIncorporate?  Right now, the linking text is supposed to be "this one", and I've tried various syntaxes, most recently "[Scenarios/ReviewIncorporate this one]".
<jam> kfogel: I thought I updated that
<kfogel> jam: forgot that one
<jam> it would be `this one <Scenarios/ReviewIncorporate>`_
<kfogel> It's no problem, I should learn ReST anyway.  But the syntax references, of course, still refer to the moin syntax :-).
<jam> `text <hyperlink>`_
<kfogel> ah, forgot the underscore when I tried that one
<kfogel> jam: thx
<Kobaz> Repository branch (format: unnamed)
<Kobaz> is that bad?
<jam> Kobaz: not specifically. Most likely caused by using a 1.9 repo with a --pack-0.92 format branch
<jam> we just don't have a short name for it
<jam> bbiab
<Kobaz> i just did a init-repo and then an init
<Kobaz> and it created a branch with the unnamed format
<Kobaz> it's never done that before that i know of
<jsled> So â¦ we branched to early.  We have a release branch and a trunk branch, and we're double-commiting everything; there are definitely commits unique to both branches, however.  It seems that once we encountered one of these commits and didn't merge it over to the release branch, we lost the ability to properly do merges going forward.
<jsled> That is, every `bzr merge -r X..Y` just shows up as a normal ("diff|patch") commit rather than a subordinate "pending merge:".
<LarstiQ> right
<LarstiQ> jsled: are you in a position to do `bzr merge -r Y` instead?
<jsled> A) What's the actual condition that triggers this difference, and B) do we need to basically do an "empty" merge for each commit we *don't* want ot pull over to have bzr keep things straight, or is there a better way?
<jsled> LarstiQ: yeah, I'm thinking of doing a big "full" merge to keep all the meta-data straigth, then changing policy.
<jsled> Looking to confirm my mental model of how bzr's working, &c.
<LarstiQ> jsled: since bzr merge -r X..Y does not (would like to have that fixed) store any metadata, just brings across the diff.
<jsled> Well, I notice so long as a do them in sequence, it does at least treat them as subordinate merges.
<LarstiQ> that might be the case if you have X in your ancestry I guess
<jam> Kobaz: it should only do that if you supplied an option to the "init-repo" but did not do the same for the "bzr init"
<jsled> i.e, if trunk has rev 1,2,3 and branch was branched at '1'.  Then `merge -r 1..2` and `merge -r 2..3` both track.  As soon as a I skip one (or so it seems), then they're not.
<LarstiQ> jsled: this operation is called cherry picking btw (one form of), and recording them is a wishlist item.
<jam> (eg, "bzr init-repo --1.9 foo; cd foo; bzr init bar")
 * LarstiQ nods at jsled 
<jsled> LarstiQ: okay.  And we've used both -c and -r before:X..X, which I'm believing are equivalent.
<jsled> (maybe -c is just shorthand, even.  immaterial, really.)
<LarstiQ> jsled: for a range of 1, yes
<jsled> right, yeah.
<jam> igc, poolie1: Are you guys around?
<lifeless> hi jam
<jam> hi lifeless
<enigma> How do I make a branch without a working tree? I don't see an option to the branch command.
<enigma> So is it a two step process? "branch" followed by "remove-tree"?
<enigma> Is there a one-command way of making a branch without a working tree?
<delaney> Hi, I have a standalone project, inside a my lib folder there is a bunch of svn'd repositories.  I want to bzr the whole project but still have ability to do svn updates as needed for the libraries.  How do I set this up in bzr?
<enigma> I would create a bzr project and check in everything but the lib folder.
<enigma> Actually...check in an empty lib folder.
<enigma> you can leave the svn directories sitting in the lib folder and bzr should ignore them just fine.
<delaney> but i want local bzr version control on the libs as well
<enigma> You mean on the files in the svn checkouts in the lib folder?
<spiv> enigma: you can create the branch inside a repository made with "bzr init-repo --no-trees"
<enigma> spiv: OK. Thanks.
<enigma> Why not just run "svn export" from time to time and put those files into lib?
<enigma> Then you wouldn't have all those ".svn" directories littered about.
<enigma> And you don't have to worry about bzr-svn trying to do something with the .svn directories.
<mwhudson> i think the new bzr st output confuses meld
<luke-jr> any way to get 'rm' (not 'bzr rm') to not count as 'bzr rm'?
<mwhudson> luke-jr: you mean have bzr commit complain when files go missing?
#bzr 2009-01-22
<luke-jr> mwhudson: I mean when I 'rm a', 'bzr status' lists it as deleted and 'bzr commit' removes it from the repository
<luke-jr> I don't want that.
<luke-jr> rather, I want bzr to leave it alone like svn does
<lifeless> luke-jr: there isn't a global option for this at the moment. I wanted to make it be like svn but got shot down on the mailing list
<luke-jr> wtf â¹
<luke-jr> is there a not-so-global option?
<lifeless> luke-jr: you can supply --strict to commit, and it will cause missing files to be considered an error
<luke-jr> no way to automatically use --strict?
<luke-jr> wait, an error? â¹
<luke-jr> why can't it just ignore itâ
<ScottK> Is there a bzr command that just pushes back where the code was pulled from?
<lifeless> ScottK: bzr push :parent
<ScottK> lifeless: Thanks.
<lifeless> luke-jr: well its code, anything is possible. I'm just describing what the current code does, and that I wanted to make new files and missing files be treated symmetrically, but didn't manage to get consensus on the list for this
<lifeless> luke-jr: you're welcome to dig up that thread and post referring to it. Support from users would be good :P
<fullermd> You could automatically use strict by just setting up an alias.
<luke-jr> fullermd: an error blocks commits, I presume-
<luke-jr> I just want the files not present in my WC
<luke-jr> yet not delete them from the repo
<luke-jr> and still be able to commit changes
<mwhudson> oh well, that's less likely to win favour
<mwhudson> the idea of commit is that it records what's on disk
<luke-jr> it doesn't go trying to add my temp note files]
<luke-jr> -.-
<mwhudson> true, that's why i have commit --strict on by default...
<luke-jr> â¦
<luke-jr> so how do I get that?
<luke-jr> better an error than remove I suppose
<lifeless> luke-jr: there is a plan, for 'views' which will be a WT setting that says what files to have present on disk; when that is implemented you could use it to get rid of some files from disk without having commit remove them from the branch
<lifeless> luke-jr: its not implemented yet, I'm just letting you know that its planned
<delaney> is there anyway to make local commits the default with TortoiseBzr?
<lifeless> http://paste.ubuntu.com/108059/ - currnet knit vs gc with 1G corpus
<mwhudson> seems a bit better :)
<mwhudson> is the "how do we make gc stream" question addressed yet?
<NfNitLoop> are there known issues with bzr blame?
<NfNitLoop> I ran blame on a repo that I've branched from svn.
<NfNitLoop> bzr blame says a line was last changed in r1
<NfNitLoop> but when I svn blame the repo, I find otherwise.
<NfNitLoop> (yes, I know svn rev#s are different from bzr rev#s)
<NfNitLoop> What I seen in svn is that the line has been changed since it was created.   bzr blame leads me to believe that it has been the same since its initial revision.
<spiv> NfNitLoop: no issues like that.
<spiv> NfNitLoop: but bzr-svn will have recalculated all the diffs between revisions.
<lifeless> mwhudson: well, just compress on the fly
<spiv> NfNitLoop: and so it's possible that it's calculated a different (but equivalent) diff to svn for the same change to a file
<lifeless> mwhudson: (as one possible answer)
<NfNitLoop> OOOoooh.
<NfNitLoop> Yes, I see, spiv.  Thanks.
<NfNitLoop> The file was copied in svn.
<spiv> NfNitLoop: e.g. consider four lines "aabb" becoming "bbaa"
<NfNitLoop> and svn keeps the history through copies.
<NfNitLoop> and, IIRC, bzr doesn't?
<spiv> NfNitLoop: did "aa" get deleted and re-added, or did the "bb" lines get deleted and re-added :)
<spiv> NfNitLoop: oh, yes, that too.
<NfNitLoop> yeah, that's it.
<NfNitLoop> the diff is pretty simple.   one line's boolean is getting switched between "true" and "false".
<NfNitLoop> with no justification in comments or commit messages.
<NfNitLoop> Anyway, thanks for the help!
<luke-jr> does 'bzr mv' work with bzr-svn right, or does it just add?
<enkrates794> I filed a bug about a week ago and got a response asking for more info. I provided the info, but I'm not sure if I should do something else in launchpad to get a further response. Could someone take a look at the bug and let me know if I've missed something? https://bugs.launchpad.net/bzr/+bug/316196
<ubottu> Launchpad bug 316196 in bzr "Error adding iTunes library on OSX" [Undecided,Incomplete]
<alevine> what's the easiest way to make a personal bzr repo that can be shared (preferably over http)?
<alevine> with subversion I used the apache module
<tecan> i have problems with bzr
<nDuff> alevine, just push your repository to somewhere some web server is sharing
<nDuff> alevine, no special web server module needed.
<nDuff> alevine, (though if you want more performance, a "smart server" is available).
<tecan> suse came with bzr 1.8 but i installed 1.6 and now everything is more complicated
<alevine> nDuff, push it over...ssh?
<tecan> its probably python 2.6 issues
<alevine> thats very cool
<nDuff> alevine, ...it's fairly common to use SFTP for uploads (yes, pushes or bound commits) and let third parties use HTTP to download.
<asabil> alevine: you must know that http is way way slower than the smart protocols
<nDuff> tecan, could you be more specific about the issues you're seeing? "everything is more complicated" isn't very actionable. :)
<mwhudson> tecan: new bzr's work with 2.6, but 1.6 isn't very new
<alevine> nDuff, asabil: thanks, performance is not an issue, mostly just for myself and for sharing code every once in a while
<tecan> there is no where to download the latest tarballs ?
<tecan> 1.6 is the latest i can get the source to
<luke-jr> â¦
<nDuff> tecan, http://bazaar-vcs.org/
<nDuff> erk
<luke-jr> so what's the deal with file copies anyhow?
<luke-jr> such a simple feature has no progress for years?
<nDuff> luke-jr, merge semantics become *much* complicated when one supports copies -- such that one pretty much *has* to do unintuitive things some of the time.
<nDuff> luke-jr, there's a pretty good argument to be made that supporting features that require you to do unintuitive things is bad.
<nDuff> s/features/"features"/
 * igc lunch
<nDuff> luke-jr, ...I can see supporting copies inasmuch as "create a new file which looks at this old one for purposes of blame and log operations", and that's probably a pretty reasonable feature request...
<thumper> where can I find the default ignore list?
<thumper> as in the files that are ignored by default
<nDuff> luke-jr, ...but having merges not change the new version under any circumstances probably isn't end-user-intuitive behavior either.
<nDuff> thumper, ~/.bazaar/ignore
<thumper> nDuff: ta
<thumper> anyone know where the bzr svg icon lives?
<thumper> I want it for a presentation
<jam> http://bazaar-vcs.org/Icons I think
<jam> thumper: http://bazaar-vcs.org/LogoOptions
<thumper> jam: fantastic, ta
<thumper> jam: is there an svg without the text?
<jam> thumper along the bottom
<jam> bazaar192.svg?
<jam> or you can look here: http://bazaar-vcs.org/LogoOptions?action=AttachFile
<jam> there seem to be quite a few .svg files
<luke-jr> nDuff: screw merge stuff, that's secondary to actually recording a copy
<nDuff> luke-jr, ...if you tell users you'll record a copy but don't then give them the behavior they expect when merging between a branch where a copy happened and a branch where the file was changed (whatever that "behavior they expect" may be), that's just asking for surprised/unhappy users. Heck, there'd be likely folks who'd expect copy+rm to behave the same way as a mv -- lots of other SCMs do it that way, after all.
<nDuff> ...but anyhow, it's been discussed on list; see the thread [RFC] Tracking file copies
<luke-jr> cp+rm = mv
<nDuff> ...so are changes in the original going to impact copies on merge or not? (And, more to the point, will changes in the *copies* impact the *original* on cherrypick? If so, which copy?) "Only if the original has since been deleted" means you've got a new set of corner cases.
<nDuff> converting cp+rm to mv *only if the original was deleted within the same commit* is a reasonable behavior, but it's not quite the same thing as the generalization cp+rm=mv.
<luke-jr> changes to both copies could be merged
<luke-jr> creating conflicts if necessary
<nDuff> whether that's appropriate depends on why you did the copy. If you're copying a template out to create a new file you're going to modify, merging changes from the new versions back to the template is absolutely wrong behavior.
<luke-jr> yes, ok
<luke-jr> so cp+rm might not always be = mv
<luke-jr> so keep cp+rm separate from mv
<nDuff> anyhow, see the mailing list thread
<luke-jr> how about just having changes to a copied file depend on the copy changeset?
<luke-jr> IMO, cherry picking is a less needed feature than copying
<nDuff> luke-jr, well, you might ask jelmer how the spec is coming along sometime.
<thumper> is there a nice page explaining how to get bzr working with eclipse?
<thumper> I have some pug people asking
<thumper> and I don't use eclipse
<luke-jr> thumper: open a terminal and Alt-Tab
<luke-jr> (why anyone would use eclipse is beyond me, it sucks)
 * thumper looks strangly at luke-jr
<nDuff> there's a bzr plugin for Eclipse
<thumper> nDuff: yes there is
<thumper> nDuff: is it packaged for ubuntu?
<nDuff> ...though I haven't used it recently; last time I tried, it didn't support linked resources. (They've fixed that since, but not early enough for my purposes)
<thumper> is bzr-xmloutput?
 * thumper wishes for bzr-eclipse and bzr-xmloutput to live in the ~bzr PPA
<vila> hi all
<tecan>  ERROR: The user tecan has not registered any SSH keys with Launchpad.
<tecan> how do i fix this ?
<bob2> login via the web interface and add an ssh key
<tecan> where
<tecan> i dont see ssh anywhere
<tecan> oh o found it
<kiko-zzz> morning
<tecan> morneng
<awilkins> Where is the keyserver where Launchpad keeps it's PPA signing keys? The latest bzr packages are signed with keys I can't find and apt is refusing to associate with them :-)
<igc> ping vila
<vila> igc: pong
<igc> vila: any thoughts on jam's comments re log --include-merges option naming?
<igc> he voted tweak but I think we should get the name right first
<igc> in particular, how useful would depth control be?
<igc> e.g. ..
<igc> log -n1 => flat
<vila> which thread ? I'm a bit out of loop on log for the last few days :-/
<igc> log -n0 => fully nested
 * igc looks
<vila> I read that I think, I'd prefer --merge_depth to be: 0: flat, -1 fully nested or something like that
<fullermd> You mean depth like how many levels deep to show merges?
<vila> i.e. matching our internal merge_depth so that it can be used more broadly
<vila> fullermd: yes
<fullermd> That strikes me as way too fiddly.  It seems like you'd need really contrived cases for a user to actually know what to do with it other than "none" or "all".
<vila> I encounter the use case yesterday in a loom where I wanted mainline but at depth 1
<igc> vila:https://lists.ubuntu.com/archives/bazaar/2009q1/051802.html
<igc> fullermd: it a shame we don't have optional parameter values to options
<igc> then log --nested could mean all
<vila> and depending on the workflow you use I'm sure there are other such use cases *other* than mainline of full
<vila> s/mainline of full/mainline or full/
<fullermd> Well, you could add a --nest-level to supplement it.  That's not a major objection.
<igc> and log --nested=2 could mean show just 2 levels (total or beyond the mainline depending on one's thought pattern)
<fullermd> Yah, but it seems like it would have to be a very specific workflow, AND you'd have to know that it was universally followed.
<vila> igc: Ha ! That thread ! Exactly the one I wanted to comment in priority
<igc> fullermd: with PQM not showing the real author, I think was suggesting looking down just one level would be nice
<fullermd> IMO, by the time you have the need and environment to be able to do that level of control, you're in a position to also want much more control over the rest of the output too.
<vila> So, first of all, I still think we should refactor log to be able to pass parameters to log formatters *before* adding generic parameters to log
<vila> i.e. not all parameters all relevant for all log formatters
<igc> vila: I'm still not sure about that
<vila> Second: I think there are more ways to select and present the revisions than just mainline and full, in the broader perspective, any sub-graph may be interesting
<igc> vila: I think it ought to be simple for a plugin to define a new LogFormatter like "email" or "xml"
<vila> oops, forget Second for a moment then, let's discuss first first
<igc> and making every log-formatter see most parameters seems to be introducing complexity to the "create a new LogFormatter" process
<vila> IMHO LogFormatter deals mainly with formatting *one* revision and everybody tends to think about them only in that context
<vila> That's no the entire truth
<igc> vila: also, I think the immediate priorities need to be:
<vila> LogFormatter also deals wiht the graph of revisions they are presenting
<igc> * make it fast so people can use it on large projects
<igc> * provide the blatantly missing functionality (like log DIR)
<vila> igc: I understand your priorities, that's one reason I stepped back on refactoring log (the other main one being that I had an already full plate with other issues and my changes to log can stay private for the time being)
<vila> Regarding your priorities, "fast" can be done without refactoring, "DIR" I don't think so
<igc> vila: I'm not rejecting your idea, I just don't want to hold up improvements than are arguably orthogonal
<vila> igc: full agreement
<igc> vila: so returning to my UI question, I think fullermd's suggestion has merit: namely ...
<vila> but I think *some* of them are not that orthogonal :)
<igc> leave the option called --include-merges (and add --nest_level later)
<jelmer> luke-jr, That's a known bug in that rc, should be fixed in the 0.5 branch
<vila> My main concern is that IMHO we're introducing options that we may deprecate later or force some log formatters to handle things they don't want to care about
<igc> vila: but perhaps the LogFormatter constructor should take a nest_level now.
<igc> understood
<igc> but it's pretty damn easy given depth is a field in every record passed to a LOgFormatter to format
<vila> igc: nest_level to constructor sounds good to me
<igc> checking if n <= m isn't more complex than if prefer_merge_revisions IMO
<fullermd> Can't the formatters just eat whatever args you give them and only bother looking at the ones they care about?
<fullermd> It seems insane to have to explicitly add each possible arg, even if they'll never care about it...
<vila> if it's under log formatter control I'm happy enough, it means they can decide to handle the option or not, or even reject the option
<igc> but it implies lots of common filtering code repeated in each log formatter
<vila> fullermd: we are not there yet, but the idea is to pass unprocessed option to log formatter which in turn can pass back unprocessed option for error handling
<igc> rather than a log formatter having a clear responsibility, i.e. "format this record"
<vila> igc: that's why we want a base class with all the utilities !
<vila> You're back to reducing log formatter to "format this record" that's not their only responsibility IMHO
<igc> it is currently
<igc> they don't really so a graph ...
<vila> no it isn't : look at begin_log end_log
<igc> just a sequence of tuples (including a depth field)
<igc> begin_log and end_log are hooks as I understand them for opening/closing headers/footers, yes?
<vila> of course the LogRevision are called in sequence but that's also a part that could/should go under the lf responsability
<igc> and/or opening/closing resources perhaps
<vila> That's why I say the lf responsability is currently unclear, parts of it being implemented by the log module, I think that's wrong and blurry things
<vila> igc: Have a look at the xnloutput Log Formatter for example
 * igc looks
<vila> It's a lf that consider itself responsible for the whole log display, not only each individual revision display, because it must balance the xml flags for each level
<vila> so it must understand the whole graph (or tree if you prefer)
<vila> You can argue that it could just use depth as an attribute and just format the whole as just a sequence...
<vila> ...but that's not the point I'm trying to make :-)
<igc> right
<igc> so begin_log & end_log put out the <log> and </log> markers
<igc> the rest looks like the usual HTML formatting dance :-)
<igc> i.e. balancing of tags while outputting nested lists
<vila> i.e. taking care of the whole formatting not only of the "format this record"
<vila> that's my point
<vila> end-log do a bit more than just putting out the </logs>  (not <log>) marker, there is a stack to purge to
<igc> it's format-this-record-in-the-context-of-what-I've-seen-already and ...
<igc> unwind levels as we step outwards
<vila> you can stop there, you said context
<igc> vila: I guess I'm asking ...
<igc> why would passing more to the log formatter help it?
<igc> we don't pass through end-of-merge for example
<igc> vila: would that make things easier say?
<vila> what is end-of-merge ?
<igc> a True/False field generated by tsort.merge_sort (along with rev-id, depth & revno)
<igc> I suspect having it would help much
<igc> it's not until you see the *next* depth that xmlformat will know the amount of levels to unwind
<igc> s/would/wouldn't/
<vila> I think that giving more responbilities to lf, will make it easier them to access the data they need instead of relying on the log module to format them in a generic way
<vila> Being able to decide at the lf level what 'revision' parameter is valid or not sounds like a solution to several problems you tried to address recently
<vila> igc: Won't you be happier with get_view_revisions being specific to a log formatter ?
<igc> I'll be happier when get_view_revision goes!
<igc> it's a crap API!
<vila> I think that will make the include_merges parameter useless for example
<vila> igc: great, delegate to lf will make it less crap
<igc> true, but so will fixing it :-)
<igc> the mainline rev, revnos and include_merge parameters are all unnecessary IMO
<igc> Branch.iter_merge_revisions is the way forward I feel
<vila> except for the fact you need them to be reasonably fast, I entirely agree :)
<vila> i.e. they are implementation details
<vila> Branch.iter_merge_revisions ? IS there where you use a reverse parameter ?
<igc> jam wanted a reverse parameter to it and I've submitted a patch along those lines but ...
<igc> I'm not sold yet on reverse being meaningful at that level
<vila> Can we please, please, stop using 'reverse', 'forward' and 'backward' have a meaning by themselves 'reverse'... always makes me wonders
<igc> true
<igc> so currently, reverse in log & missing calls sort_by_depth
<vila> hmm, more than just that I think
<igc> That feels a bit too fancy for Branch.iter_merge_revisions where forward/backwards makes a lot more sense
<vila> off-topic forward without 's' and backwards with 's' always /
<vila> s!/!?!
<vila> lol, perl is noise :)
<igc> no, I meant forward/backward
<vila> ooh, you mean 'reverse' as used at UI level, I was meaning internally also
<igc> vlia: anyhow, I need to have dinner now
<igc> vila:^^
<vila> Enjoy your dinner :)
<igc> so you're ok with --include-merges at the UI level & preferred_depth at the LogFormatter API level?
<igc> vila:^
<vila> why preferred  instead of just depth ?
<vila> I'm ok for --include-merges
<igc> you're right, just depth is good
<igc> or levels
<vila> Overall: I'm globally ok with your modifications anyway, it's just that I think some of them may be simpler *after* refactoring and some of them may make refactoring *harder*
<vila> But since you'r the one spending the time on it, you get to choose :)
<igc> :-)
<vila> igc: And I'm perfectly fine that
<vila> igc: And I'm perfectly fine with that
<igc> cool - time to go. Thanks for the chat
<vila> You're welcome
<vila> jam: Ha ! Look who is blocking pqm now ! Welcome to the club :-)
<NET||abuse> hi guys.. basic usage question, i've a little project on my laptop, i'm concerned for the hardware, how do i clone up to my server for backup? can i just sftp copy the whole versioned directory(working copy i guess) straight up to the server?
<NET||abuse> or do i need to use a bzr instruction to do so?
<pygi> NET||abuse, either bzr branch whateva on server works, or you can sftp things
<pygi> or bzr push from local to server
<NET||abuse> hmm, ok
<NET||abuse> i'll have a look at it.
<NET||abuse> hmm, missing page in the bzr docs,, http://bazaar-vcs.org/Scenarios/NewProject
<pygi> NET||abuse, that Scenarios page is new :)
<pygi> we're yet to work on it ;)
<NET||abuse> so i can push to my server where it has no bzr repo setup, initi'd yet
<vila> herb: It looks like you're the only losa around, can you have a look at PQM please ?
<vila> herb: I meant when you come online...
<NET||abuse> hmm, ok so branch from my local to remote doesn't work,, i did bzr branch ./ svn+ssh://me@host/path/to/new/bzr/dir    and it throws error "bzr: ERROR: No repository present:"
<NET||abuse> What i'm looking to do is move my current standalone branch on my local laptop, up to a dir on my webserver, and then have that act as the main branch for my work, i will be opening it up to someone else next week, so need it up there, and also worried my laptop is about to croak
<NET||abuse> it's gotta a discreet nvidia NVS135M card in it, they're known to have issues, this is my 1st replacement from dell, the first one died and 5 engineer visits didn't fix it, so they just gave me whole new model, now last night during 10,000 bc :) the screen glitched like the last one had started to before it died...
<NET||abuse> not good.
<fullermd> I don't think you can branch into SVN...
<fullermd> I don't even know if branch CAN target somewhere remote.  Used to definitely not; can't remember if that was changed or not.
<fullermd> Generally you just push anyway.
<NET||abuse> umm, you see this is why i need to ask,, yeh, svn+ssh,, oops,, i'm not looking to push to svn, was looking to make a new bzr repo... so i just tried bzr ./ bzr+ssh://me@host/path/to/repo/to/create   and it didn't like it,, error unkown command 'server' connection closed: please check connectivity and permissions
<NET||abuse> unknown command wasn't 'server' just 'serve'   still the error stands...
<NET||abuse> so last effort,, i just tar.gz up the bzr repo directory,, then upload it.
<NET||abuse> extract it on the remote server then try to point my local to it.
<NET||abuse> or will they conflict? would i have to re clone/branch from the server back down to my local machine?
<fullermd> Unknown command serve?  That sounds like a *REALLY* old bzr on the far side...
<fullermd> Taring it up should work just fine for backing it up.
<NET||abuse> fullermd: yeh, the far side is the old LTS ubuntu, dapper i think?
<spm> vila: what seems to be the problem? One of your submissions appears to have succeeded about 20 minutes ago?
<vila> spm: thanks for looking in to it, it looked like last *jam* submission was blocking the pqm, mine was just waiting
<vila> spm: things seems fine now
<vila> spm: did you do anything ?
<spm> vila: cool. apart from looking? no. :-) Easiest fix I've done in ages :-)
<vila> spm: pqm is just afraid by you then :)
<spm> heh
<vila> Or may be *I* just misread or read too soon...
<spm> shrug - is no matter. when it gets stuck it's pretty easy to unstick - better to keep things flowing
<dr_barnowl> fullermd: You can branch into SVN
<dr_barnowl> fullermd: I had to "svn-versionize" a list of dated archive folders recently, which I did by committing them to bzr branches and pushing them to svn
<fullermd> Well, I know you can push them in.  I mean I don't think you can use _branch_ to do it.
<fullermd> (actually, I thought you couldn't use push either, and there was some other command to create one ab ovo)
<wgrant> You have to use bzr svn-push to create a new branch.
<clemente> In latest bzr.dev:  File "/home/w/bzr/oficial/bzrlib/ui/__init__.py", line 237, in make_ui_for_terminal:  UnboundLocalError: local variable 'cls' referenced before assignment
<vila> clemente: thanks, fix is on its way
<nua> hi I'm having real trouble starting the bzr server, it breaks and I get a traceback: http://pastebin.com/m66382410
<nua> I'm using the standard install for ubuntu 8.10
<nua> which reports to be bzr 1.6.1
<lifeless> thats a bug in bzr-dbus which has been fixed since that release
<lifeless> either uninstall bzr-dbus, or upgrade it, or have dbus running
<ScottK> Sounds like a good SRU candidate then.
<nua> hmm, now I'm just getting address already in use, I think that other attempt is still using it
<frk2> hello all
<frk2> had a question regarding the use of hooks in bazaar
<frk2> Im using a shared repository arch
<frk2> so basically everyone commits to a singular server
<frk2> to send commit notifications out do i have to configure bzr-email on every single desktop?
<frk2> configuring on the remote repo in .bzr/branch/branch.conf does not seem to work, configuring locally does
<lifeless> bzr-email on te server, and push via bzr+ssh should work just fine
<lifeless> gnight all
<frk2> but a bound commit does not
<frk2> lifeless,  i can try to push and see if that works. But I have the branch bound to the server- a commit does not help
<frk2> guess you have gone off to bed :) gnite
<Jc2k> frk2: you could try bzr-hookless-email as a workaround in the mean time
<frk2> Jc2k, whats that?
<Jc2k> frk2: it uses inotify (or just run it very frequently in cron) and looks at what changed and generates emails
<frk2> is it part of bzr tools now?
<Jc2k> no
<frk2> so get it from lp directly?
<Jc2k> bzr branch lp:bzr-hookless-email
<Jc2k> its not a plugin, so no need to put it in .bazaar/plugins or anything
<Jc2k> i've not used it myself, but i think debian are using it for their commit emails
<frk2> Jc2k, got it running- am guessing it uses sendmail or something to actually send the email
<Jc2k> frk2: its based on bzr-email, so imagine its the same kind of thing as that
<mtaylor> lifeless: coupla quick things about stacked branches... --stacked-on=lp:~mordred/wafflegrid/5.1-upstream doesn't work - doesn't recognize lp: syntax ... and also, that fails, so the push aborts, but not before it creates _something_ on launchpad
<nua> I add the bzr PPA and got the latest version, all working fine now
<nua> I was wondering how I require log-in to access the repositories if I'm using bzr serve? it seems like anyone can checkout the code
<frk2> nua, you do not, i think
<frk2> thats why its read obly
<frk2> only
<frk2> unless explicitly enabled
<frk2> i use bzr+ssh
<nua> ok, so I basically have to use bzr+ssh if I want authentication?
<nua> that's ok, but it means I get really ugly urls
<frk2> AFAIK, yes
<nua> would I create an ssh account for each collaborator (I'd rather not) or could I force them to use a single bzr user and authenticate on their ssh keys?
<nua> frk2: what about https?
<awilkins> nua: You can use http and your http server will take care of auth for you if you configure it
<nua> awilkins: ok thanks, I think I'll give that a go
<awilkins> nua: ssh also works with a single ssh user as long as you put each users public key on your authorized_keys file
<nua> awilkins: I think http sounds like the most sensible route
<awilkins> nua: It's very easy for read-only access
<awilkins> nua: It'll work out of a dumb http server ; write-access takes a little more work
<nua> awilkins: I can run a smart http server by using bzr+http:// right?
<awilkins> nua: You can _access_ a smart server by specifying bzr+http://
<awilkins> nua: To run one you need to configure the server to pass requests to bazaar through WSGI
<nua> awilkins: ok, but I can write to the sever over http/https?
<awilkins> nua: Yes, as long as the smart server is configured
<awilkins> Which web server are you using?
<nua> awilkins: I usually use apache or lighttpd... just looking at which to set up now
<nua> awilkins: do you know of any guides on how to set up bzr smart server and http?
<awilkins> I wrote the page at http://bazaar-vcs.org/ServerGuide/IIS
<awilkins> I think there are hints for apache in the docus somewhere
<awilkins> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id80
<nua> awilkins: yeah, just found that :)
<awilkins> I had to fix the code to make it work with IIS :-)
<awilkins> Half IIS's fault though
<vila> haaa, just finish talking with igc, saw lifeless less than an hour ago, now poolie is joining... Did I enter the TZ ? (Twilight Zone :)
<vila> Hi poolie :-)
<poolie1> hello vila
<igc> hi poolie
<igc> jam: thanks for the review re the dotted_revno_to_revision_id patch. Much appreciated
<poolie> hello igc, you're up late
<poolie> i think
<igc> poolie: my hours are all the place right now
<igc> 7am start yesterday, 6am finish, hospital visit in between
<igc> I sleep when I tired currently
<igc> jam: I'd also love a review of the iter_merge_sorted_revision patch if you have time/interest
<igc> poolie: re log --include-merges, I think I'd prefer log --levels N to control how many levels are displayed
<igc> N=0 would be "all of them"; N=1 would be a flat list
<igc> together with a shorthand of -n, I think it would work well ...
<igc> e.g. log -n1 seems better than log --no-include-merges
<igc> likewise log --short -n0 is easier than log --short --include-merges
<igc> also, when logging from a merge revision, it's the number of levels down that matters, not mainline vs merge revision display
<igc> poolie, jam: thoughts?
<igc> fullermd suggested having both --include-merges and nest_levels
<igc> once we have the latter though, the former seem redundant
<aquarius> I had a conflict in my branch when I merged another branch into it, on a file foo/bar/baz. I've done "bzr rm foo" (it doesn't need to be there any more), but bzr still says the conflict is present
<aquarius> how do I unconfuse it (and me)?
<poolie> poolie: that sounds nice, um
<poolie> i would have thought -n0 means "no" :-)
<poolie> actually seriously 0 means "none"
<poolie> also, being indented one level does not precisely correspond to "one step away" in the actions the user took
<poolie> though arguably it does when you pull the dag around a bit
<poolie> shorter options == better
<poolie> does that help at all?
<igc> poolie: I think 0 meaning all is ok; asking for zero levels isn't very useful :-)
<poolie> ah
<poolie> if you're counting from kind of column zero on the screen
<poolie> then yes
<igc> well, for log at least!
<igc> so I guess we can have n mean either total number of levels or number of nested levels
<igc> do you have a preference?
<igc> if # of nested levels, then -n0 means flat & we need a # or symbol for all
<igc> log -n all is actually ok btw
<igc> we don't have int options, just strings we parse into ints it turns out
<igc> poolie: ^^
<igc> n fact, -n all would work regardless of what exact semantics we gave the numbers
<poolie> igc, that makes sense, i think -n0 is nice and short to type to mean everything
<igc> me too
<poolie> so -n0 would be the default?
<igc> it's format specific
<igc> the -n just overrides the default
<igc> that way we keep c ompatibility for existing users
<poolie> ok
<poolie> sounds good
<igc> internally, -1 will mean "let the format decide" and it will be the default
<luke-jr> jelmer: which bug?
<bakunin> I'm trying out bzr on my Windows box towards our Subversion repository, but I haven't been able to find out how you specify username and password towards the subversion repository. Any pointers to documentation about this?
<luke-jr> jelmer: isn't the difference between "Fix Committed" and "Fix Released" that the latter is actually in a release?
<luke-jr> jelmer: BTW, any chance we can get a 'bzr svn-cp' or such that pushes a 'svn cp' upstream? >_<
<luke-jr> maybe represent it in bzr through a 'copied from' property or such
<luke-jr> (until it has proper copy support)
<vila> igc: catching up ! +1 +1 +1 for -n !! Including 0 for all
<igc> vila: thanks. I think it will work well
<vila> I also prefer that to having several options
<vila> igc: "internally, -1 will mean "let the format decide" and it will be the default" :-)
<vila> Let the format decide ftw ! :-)
<igc> and for backwards compatibility :-)
<vila> same boat ! More room to improve other lfs :-)
<nua> does this mean I need to edit the bzrlib source?? http://pastebin.com/m533f12af
<tro> bakunin: use the HTTP method of specifying username/password. ie: svn://username:password@svn.repo.com/path/to/repo/trunk
<awilkins> nua: I think the WSGI handler that is posted is a bit out of date
<awilkins> nua: When I upgraded on Windows I had to change the logging parameters
<bakunin> @tro Will the same work for a http URL?
<tro> bakunin: yes
<pickscrape> Given a revision ID, what is the quickest way in bzrlib to determine the number of parents that the revision has? (i.e. whether or not it is a merge)
<garyvdm> pickscrape: http://pastebin.com/d2ec223ca
<pickscrape> garyvdm: thanks for that
<poolie> vila: hello
<bakunin> tro: Thanks a lot. It worked. I guess this is how basic authentication is handled
<luke-jr> how do I get teh 'svn revno' with bzr?
<james_w> luke-jr: recent bzr-svn will put it in the output of "bzr log"
<luke-jr> james_w: programmically
<james_w> luke-jr: dunno
<james_w> luke-jr: take a look at bzr-svn's source for how it implements that
<luke-jr> :/
<james_w> show_foreign_revid perhaps
<luke-jr> s/programmically/from a shell script/
 * garyvdm wishes he could use python 3.0's nonlocal statement...
<lorph> is tortoisebzr usable yet
<garyvdm> lorph - I use it.
<garyvdm> Heh - He left allready :-(
<mrooney> I am using bzr-svn to attempt to branch a rather large svn repository, but it doesn't seem robust enough to ever make it the whole way through. Is there a way to continue/resume this process?
<mrooney> It seems to get a few thousand revisions in and then die and I have to start all over.
<james_w> hey mrooney
<mrooney> james_w: hey!
<james_w> you can "bzr branch -r 1000"
<james_w> then "bzr pull" 1000 revisions at a time
<mrooney> james_w: ahh that sounds perfect, so if I branch 1000 and then the next pull fails, what state is it left in, the original before that pull? or is it still broken?
<james_w> it should be left as it was before the pull
<james_w> bzr pull -r 2000
<james_w> bzr pull -r 3000
<james_w> etc.
<james_w> should stop it doing too much in one go
<mrooney> james_w: thanks so much, this seems good
<james_w> cool
<mrooney> I figured an easy way to back up our SVN repositories incrementally was just to branch once from another machine via bzr-svn, and then pull every night
<mrooney> james_w: does that sound sane?
<james_w> seems reasonable
<mrooney> excellent
<mrooney> It would also probably help if I wasn't doing this over wifi :)
<asabil> btw, does bzr have a way to see the diff/log of changes that where retrieved using a pull ?
<garyvdm> asabil: There is before you pull. You can use missing to see what revisions, and diff pull_branch for diff
<garyvdm> asabil: bzr does not remember what the tip revid was before the pull
<asabil> it would be really very useful if it did
<amanica_> asabil: you can tag it before you pull
<amanica_> or maybe we can do an implicit tag before pulling
<amanica_> eg BEFORE_LAST_PULL
<amanica_> maybe this would be possible to do with a plugin...
<lifeless> mtaylor: file a bug on the stacking-on failure please
<garyvdm> Is there a way to specify the bound branch?
<garyvdm> e.g. bzry push -d --bound_branch--
<lifeless> garyvdm: bzr bind <url>
<lifeless> garyvdm: oh; :master I think
<garyvdm> lifeless: re:bind Then I would need to bind every time I switch - which is often
<garyvdm> I'll check out :master
<garyvdm> :bound works - thats very cool
<knittl> hi! is there a way to stash commits like in git?
<bob2> shelve
<knittl> bzr shelve? i can't find it in the manpage
<knittl> and it doesn't work â¦ (binary files)
<lifeless> knittl: in used to be in a plugin, it recently got moved to core and fixed for binary files
<LarstiQ> knittl: which shelve is this with btw, shelf1 or `shelve` from 1.10 and up?
<lifeless> knittl: what bzr version do you have?
<LarstiQ> knittl: hi, btw :)
<knittl> hi LarstiQ :)
<knittl> 1.6.1 i got on my machine
<knittl> LarstiQ: i checked out blender (took hours)
<LarstiQ> knittl: got everything though?
<knittl> yup, i'm not missing a thing (till yet)
<knittl> -yet +now â¦ sounds better xD
<knittl> ok, i just bzr rm --keep the files, committed my changes and pulled
<knittl> weirdly enough it told me there was nothing to pull/merge, but before committing it told me there was a pending merge
<lifeless> knittl: that means you had done a merge
<knittl> lifeless: well, i didn't tell it to do a merge. but nevermind â¦ i'm only doing a little branch for a sideproject xD
<lifeless> knittl: check your bash history, I can pretty much guaranteed that 'bzr merge' is in there somewhere :)
<knittl> yes, but it aborted and told it couldn't merge because of uncommitted changes
<lifeless> knittl: it would do that after you'd made changes; such changes could have included an earlier attempt to merge
<knittl> ok, i see :)
<lifeless> one of the most obvious differences to git is that 'bzr merge' always waits for the user to commit the result - we don't autocommit
<lifeless> -> breakfast
<lifeless> Peng: btw, you should find bzr search lower on memory but not too much slower on indexing
<Peng_> lifeless: The new group_size stuff? Cool, how much lower?
 * Peng_ fires up "bzr -Dmemory index".
<lifeless> a lot lower for mysql trees :P
<lifeless> also loggerhead suggestions should be faster in format 2 search indices
<Peng_> Oh, cool.
<Peng_> Should suggestions in general be faster, or is it specific to LH?
<lifeless> faster in general
<Peng_> Bah, the progress bar is already off the side of the screen.
<lifeless> ugh
<Peng_> 9 minutes 14 seconds for bzr.dev. "VmPeak:   121356 kB"
<Peng_> That's awesome memory usage. It used to take decreasing the group_size to ~80 to do that.
<jelmer> luke-jr, you can get the svn revno with "bzr log -r -1"
<jelmer> luke-jr, "Fix released" means it's part of the main branch in the bzr world
<jelmer> luke-jr, wrt svn-cp, there is no way to make that work while bzr can't represent that internally
<Peng_> Nice, "bzr search aye" returns an excerpt from doc/en/user-guide/images/workflows_pqm.png. At least it didn't confuse my shell.
<jelmer> hi Peng_
<jelmer> Peng_, Did you get anywhere further with that bzr-svn+bzr-search issue you were seeing?
<Peng_> jelmer: I didn't try to.
<luke-jr> jelmer: bzr doesn't have arbitrary metadata?
<Peng_> Haha, "bzr search branch" on bzr.dev sure has a lot of results. :)
<luke-jr> jelmer: I'd rather not have to grep/sed on log -r -1
<jelmer> luke-jr: only revision properties, but they are set at commit time
<jelmer> luke-jr, and the amount of work to work around the fact that bzr doesn't have copies makes me think we should really just implement copy support in bzr first
<jelmer> luke-jr, sorry :-/
<Peng_> "bzr search branch" had 5311 results. FYI. :P
 * jelmer notices bzr-search is Peng_'s latest toy
<Peng_> jelmer: Well, I go through a lot of toys. :P
<luke-jr> jelmer: so implement copy support already :/
<luke-jr> jelmer: honestly, I'd benefit greatly from moving a number of my projects to bzr, but without copy support I can't :/
<knittl> is there a bzr move?
<luke-jr> yes
<jelmer> knittl, yes
<knittl> it's not bzr mv â¦ what is it?
<luke-jr> knittl: it is
<knittl> oh â¦ i must've mistyped it then â¦
<luke-jr> jelmer: supposedly the problem w/ copying is cherry-picking, but IMO copying is more important than cherry picking, so that problem should be deferred :/
<jelmer> luke-jr, fwiw, I agree with that (some copy is better than no copy)
<jelmer> and just having the history stored now means we can use it later when there is proper merge support (if ever, as that's a very hard problem to solve)
<knittl> can somebody help me with a concrete repo? (+branch)
<knittl> i'm still more used to git â¦ after all i'm a programmer and like it complicated xD
<jelmer> knittl, what's the problem?
<knittl> i can't get two directories pulled into b
<knittl> * -b +my branch
<Peng_> jelmer: Hg supports merging across copies.
<jelmer> Peng_: So what do they do when you copy a file and then merge in another branch that changes that file?
<jelmer> Do you merge it into both copies ? Or just into one?
<jelmer> If you base one source file on the other, you don't necessarily want the changes
<Peng_> jelmer: The other branch changed the original or the copy?
<jelmer> The other branch changed the original
<Peng_> jelmer: The changes are merged into both.
<Peng_> Cue Peng_ being proved wrong.
<lifeless> Peng_: 9 minutes is slower than usual to index though?
<Peng_> lifeless: I dunno. The group_size is 2000, and I'm not sure if I have numbers for that (and if I did, it would be for format 1).
<Peng_> lifeless: For group_size = 1000 from a couple months ago, it was 9m56s, so it's faster.
<Peng_> lifeless: So, I figure that if it is slower, it's not significant.
<knittl> hm, how do i get those folders into my branch? :-/
 * Peng_ /aways
<lifeless> Peng_: thanks,c ool
<jelmer> knittl, I'm not I understand completely what you're trying to do
<jelmer> knittl, if you're trying to import folders, just "bzr add" followed by "bzr commit" should be sufficinet
<knittl> jelmer: the folders already exist in the master branch
<knittl> but they are 'unknown' in my branch
<jelmer> knittl, so you want to do a cherry pick merge of those folders?
<knittl> i just want to have them in my branch :D
<lifeless> knittl: normaly you would just 'bzr merge master && bzr commit' to get something into your branch
<knittl> i only tried bzr merge till now
<knittl> it tells me there's Â»nothing to doÂ«
<lifeless> knittl: what is the *exact* command line you are running
<ivazquez|laptop> Given a bzrlib.branch.BzrBranch6, how do I get the revision of a file within?
<knittl> lifeless: bzr merge (master)
<knittl> master or not, the output is the same
<lifeless> ivazquez|laptop: you need a revision tree - so tree = branch.repository.revision_tree(branch.last_revision()); tree[tree.path2id('path')].revision
<ivazquez|laptop> Excellent, thanks.
<lifeless> knittl: the literal word master, or the URL ?
<knittl> lifeless: ok, i tried "master" after your advice. but i tried the url before and it doesn't change anything
<lifeless> knittl: does 'bzr missing URL' report anything?
<knittl> Â»you have 4 extra revisionsÂ« + the logs
<lifeless> knittl: ok, you have everything from that branch already; so either the folders you are talking about aren't versioned, or you've deleted them locally :)
<lifeless> knittl: are you able to give us some more data? Is it an open source project that we could go peek at the url ?
<knittl> i don't think i deleted them â¦
<knittl> sure â¦ lp:dnd or lp:~knittl/+junk/dnd
<lifeless> I'm on a terrible wifi network at the moment, one second while I wait for my packets to get through :)
<knittl> no problem â¦ i'm glad you help me understand bzr a little
<lifeless> https://code.edge.launchpad.net/~knittl/+junk/mtd ?
<lifeless> I can't see a dnd branch of yours
<ivazquez|laptop> Hrm. I'm getting "TypeError: unsubscriptable object" from tree[...].
<lifeless> ivazquez|laptop: oh sorry, tree.inventory[...
<ivazquez|laptop> Ah, thanks.
<knittl> lifeless: yes
<lifeless> knittl: so is this your branch without the folders, or the branch with the folders that you want to get into your current copy?
<knittl> it's my branch without the folders from dnd
<knittl> they got added in r12, my r12 differs â¦
<lifeless> ok
<lifeless> and where is the dnd branch?
<knittl> the dnd branch is just lp:dnd
<knittl> or what do you mean?
<lifeless> ok, got it. Now what are the folders you want?
<knittl> Data/{Models,Sounds}
<knittl> and i didn't remove them â¦ i looked at my history
<lifeless> your rev 15 merged his rev 12 that added the files, but your merge backed out his changes
<lifeless> I imagine you did something like 'bzr revert .' and then committed something
<lifeless> which will have kept the merge record but reverted all the code changes
<lifeless> this is easy to fix
<lifeless> are you still on rev 15?
<knittl> iirc i did bzr rm --keep because they were changed (oh damnit â¦)
<knittl> yup, i'm still on 15
<lifeless> ok, do  a 'bzr st' and make sure there are no pending changes - no pending merges or changed files
<knittl> no outputâgood  :)
<lifeless> now, 'bzr uncommit' and say yes when prompted.
<lifeless> then do 'bzr shelve --all'
<lifeless> you should now be on rev 14
<lifeless> do 'bzr st' again - is there any output
<Peng_> lifeless: Should "bzr search" use more memory when it finds tons of results?
<knittl> ok, output after uncommit is added [my files] and 1 pending merge
<knittl> bzr shelve --all
<Peng_> (Well, "more" = 88 MB, and "tons" = "5300")
<luke-jr> jelmer: when multiple possibilities are valid, Conflict
<lifeless> Peng_: probably, though that does seem excessive
<lifeless> knittl: 'bzr st' output after doing the shelve ?
<knittl> wops, that bzr shelve shoulda go into my shell xD
<knittl> shelve won't complete
<knittl> $ bzr shelve --all
<knittl> bzr: ERROR: Changes involve binary files.
<lifeless> odd
<lifeless> what bzr version do you have?
<knittl> 1.6.something
<knittl> 1.6.1
<lifeless> ok, when you get a chance upgrade, cause that is fixed
<knittl> that's the latest bazaar i get from the ubuntu repos
<lifeless> for now though, just take a copy of your new files somewhere
<Peng_> https://launchpad.net/~bzr/+archive
<knittl> okay
<lifeless> knittl: when you've taken that copy, run 'bzr revert'
<lifeless> knittl: and then 'bzr merge lp:dnd', if it merges without conflicts then do 'bzr commit'
<knittl> ok, i'll try
<knittl> ok, did that, worked fine :)
<lifeless> put your files back, run 'bzr add' then 'bzr commit'
<knittl> my files are still there â¦ now just the regular bzr add?
<knittl> great :)
<knittl> why is this so complicated? :p
<lifeless> well, its not normall :)
<lifeless> knittl: also, you may like to know that you can push to lp:~knittl/dnd/mtd
<knittl> :)
<knittl> lifeless: yes, i know that â¦?
<lifeless> cool (I just found it odd your branch was in +junk)
<knittl> oh yes, i just wanted to test â¦ maybe i'll move it to ~knittl/dnd later on
<lifeless> you can do that in the web ui I think
<lifeless> anyhow, http://bazaar-vcs.org/Download/ has newer versions of bzr for Ubuntu - just follow the link to the ppa
<knittl> yes, but that's not important atm. is long as i can pull/push and have all data xD
<knittl> $ bzr push
<knittl> Using saved location: bzr+ssh://knittl@bazaar.launchpad.net/~knittl/%2Bjunk/mtd/
<knittl> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<knittl> :-$
<lifeless> add --overwrite
<lifeless> that error is just a protection against mmistakes, but we redid that commit deliberately
<knittl> ok, i really need to get a newer version
<knittl> but that will hopefully be available in jaunty
<knittl> lifeless: got it all back to normal. thanks!
<knittl> i can always count on irc :)
<Peng_> "bzr search a" on bzr.dev takes 84 seconds (user time; realtime fluctuated), VmPeaks at 96 MB, and returns 12,429 results. :D
<wgrant> jelmer: Is that add_records() fix in bzr.dev the one to stop it complaining about knit corruption?
<jelmer> wgrant, it will stop a complaint if you run "bzr merge"
<jelmer> wgrant, it won't affects "bzr check"
<wgrant> jelmer: Right. Thanks for handling the bug quickly.
<enigma1> Hm...I just got an assert error with bzr-svn 0.5
<enigma1> I was pushing a tag back up to SVN.
<wgrant> jelmer: Is 0.5 stable now?
<wgrant> I thought it was still unreleased.
<enigma1> AssertionError: Unable to find direct lhs parent for <RevisionMetadata for revision 9707, path cpp-common/tags/0.11 in repository 'daff2dd8-1c3d-0410-9cd2-f6297dd8f964'>
<jelmer> wgrant: Yeah, it's not yet released (there's one rc out, another to follow soon)
<enigma1> No...this is off 0.5-trunk
<jelmer> enigma42, Any chance you can try after removing the local cache?
<jelmer> s/try/try again/
<jelmer> there was a bug similar to this fixed some days ago
<enigma42> jelmer: I'm a little nervous to clear the cache.
<jelmer> enigma42: Why?
<enigma42> Last time I cleared the cache, my svn branches got out of sync with the SVN server.
<enigma42> So, the latest revisions in bzr were in svn, but they weren't correlated.
<jelmer> enigma42: alternatively, you could just move it out of the way for now
<enigma42> True.
<jelmer> just to see if it helps
<enigma42> OK...let me try.
<enigma42> Um...I think my 0.5-trunk my be a little of of date, do you know when the bug was fixed?
<wgrant> jelmer: Is 0.5 in a PPA somewhere yet?
<jelmer> wgrant, there's a month old package in debian experimental
<jelmer> enigma42, I think about a week
 * wgrant shall update that and PPA it.
<jelmer> enigma42, if removing your cache causes issues, that would be a sign there's a lot more wrong..
<enigma42> jelmer: OK. So you think I should update to the latest 0.5-trunk, remove the cache, and try again?
<jelmer> enigma42: Please do - that should tell us if those problems are still there, and allow us to fix them
<enigma42> OK. Let me give that a go.
<enigma42> Oh...on a different note, why is the bzrtools in the PPA *way* out of date?
<enigma42> Is that hard to build?
<enigma42> Is that something I could build and email to someone?
<lifeless> Peng_: yes, thats not that useful :P - searching for multiple terms might be more useful :P
<lifeless> jelmer: where is bzr-git up to?
<lifeless> jelmer: [should the help be improved, is there meant to be a git:// urlspec?]
<jelmer> lifeless: I'm making sure dulwich is ready for a release
<jelmer> I blessed the current mapping as stable yesterday and renamed it appriopriately
<jelmer> The idea is to release a simple bzr-git in a couple of days
<jelmer> meanwhile I'm still working on optimization
<enigma42> jelmer: The most recent revision I'm seeing for the 0.5 tree is from Saturday, Dec 27. Does that sound right to you?
<jelmer> lifeless, I was hoping to receive comments about my local branches spec, that's the main thing important about URLs
<enigma42> jelmer: I'm pulling from: http://people.samba.org/bzr/jelmer/bzr-svn/0.5/
<jelmer> enigma42, no, the most recent one is from a couple of hours ago
<enigma42> Ack...nevermind.
<spiv> "[###################/] determining changes:analyzing repository layout:determining changes:copying revision:determining revisions to fetch:discovering revisions -2349/68866
<enigma42> Looked at the wrong end of the log. :-P
<lifeless> jelmer: I glanced at it
<spiv> "
<spiv> jelmer: that's an amusing progress line :)
<jelmer> spiv: bug in the new progress code :-(
<jelmer> spiv, btw, did you see my comments to your import patch?
<spiv> jelmer: yeah, I did.
<ivazquez|laptop> Taking a look at https://fedorahosted.org/packagedb/browser/0.3.x , how do I get 182 from the InventoryFile for AUTHORS?
<jelmer> hmm, ohloh seems to've released the sourcecode related to their vcs analysis
<lifeless> ivazquez|laptop: you map the revision back via the branch
<jelmer> and added hg support
<jelmer> unfortunately it's all ruby :-(
#bzr 2009-01-23
<ivazquez|laptop> Okay, branch..revision_id_to_revno() worked for that one. But it fails for files like README.
<lifeless> dotted revnos aren't handled by that api; I think there is another newer api
<lifeless> there has been some stuff on the list recently too, about this
<ivazquez|laptop> I'll take a look there then, thanks.
<enigma42> jelmer: Can I use the 0.6.0 release of subvertpy with bzr-svn 0.5-trunk?
<jelmer> enigma42, yes
<enigma42> jelmer: OK.
<enigma42> jelmer: Where do I install subvertpy?
<jelmer> enigma42, somewhere in your python path (./setup.py install usually does the right thing)
<enigma42> OK.
<enigma42> jelmer: Is there a way to install it unprivileged?
<enigma42> jelmer: LIke in "~/.python" or something like that?
<jelmer> enigma42, yeah, you can specify a different directory using the --root option
<jelmer> enigma42, but you'll have to set PYTHONPATH appropriately to use bzr-svn then
<enigma42> Oh, OK.
<lifeless> --homedir isn't it?
<enigma42> jelmer: OK. I use "checkinstall" to create a deb and installed it that way.
<Jc2k> lifeless: bzr + ssh, more specifically its SSHSuprocess objects. do you know why os.read(stdin.fileno()...) was preferred over sdin.read(.. ?
<Jc2k> lifeless: i have some questions about hooks too when you have some spare cycles
<lifeless> Jc2k: just ask
<lifeless> I'm at LCA, but will do my best
<lifeless> dunno wh we use os.read there, annotate may help?
<ivazquez|laptop> Aha, branch.get_revision_id_to_revno_map()[inv.revision].
<Jc2k> ah ok. os.read seems to return something, but maybe not as much as you asked for. in that regard stdin.read is nicer.
<Jc2k> lifeless: my question was about a plugin i threw together as "bzr-hookless-email reloaded"
<Jc2k> lifeless: i replied to a post on bazaar ml about bzr-hookless-email with my thoughts, it might be easier to look at that
<Jc2k> lifeless: basically im reusing Branch.hooks in a different context, and thats slightly evil of me but means that i have a way to make something like bzr-cia "just work" with a bzr-hookless-email type arrangement
<Jc2k> (out of process hooks)
<enigma42> jelmer: Great! The latest 0.5-trunk pushed and pulled just fine.
<jelmer> Great :-)
<enigma42> jelmer: Thanks for your help.
<ivazquez|laptop> Excellent. 4 down, 1 to go.
<enigma42> jelmer: OK. Same problem about branches diverging again.
<jelmer> enigma42, what is the error there exactly?
<jelmer> and what does e.g. "bzr missing" say?
<enigma42> Here's the symptom. Before I clear the cache, I can do a "push" or "pull" and there will be not changes.
<enigma42> Then I clear the cache.
<enigma42> Then it says they diverge.
<enigma42> It says I'm missing 40 revisions.
<enigma42> Basically, everything that has been committed since I first pulled down the branch.
<enigma42> So, SVN has all the revisions.
<enigma42> And the bzr branch has all the same revisions.
<enigma42> But the revision IDs don't match.
<enigma42> The IDs I'm getting from SVN are now different than the IDs in bzr.
<jelmer> enigma42: But it doesn't report that you have 40 *extra* revisions as well?
<enigma42> Yes.
<enigma42> I'm missing 40 and I have 40 extra.
<enigma42> Example:
<enigma42> From bzr:
<enigma42> revno: 73
<enigma42> revision-id: bhatpr@pbhat1-20090122095933-d3cmuadsx8jepmna
<enigma42> parent: bhatpr@pbhat1-20090122094625-kq5y49s9uqagx459
<enigma42> And from SVN:
<enigma42> revno: 73
<enigma42> revision-id: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:9671
<enigma42> parent: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:9670
<enigma42> So, somehow the ID got lost.
<enigma42> The branch format is: Standalone branch (format: rich-root-pack)
<enigma42> Does it need to be something like 1-9-rich-root?
<jelmer> no, that shouldn't matter
<jelmer> what subversion version is the server running?
<enigma42> It's svn 1.4 via collabnet
<jelmer> not recently downgraded or anything?
<enigma42> No.
<enigma42> It's about to be upgraded to 1.5 this weekend.
<jelmer> so bzr-svn uses svn file properties?
<enigma42> I'm thinking so.
<jelmer> enigma42: The repository is not public I assume?
<enigma42> Unfortunately, no.
<jelmer> enigma42: If you run e.g. "svn diff -c <last-svn-revnum> <url>", do you see any bzr-svn properties?
<enigma42> OK. Let me try.
<enigma42> No, I don't see any bzr-svn properties.
<enigma42> I'm going to try putting the old cache back in place real quick to see what happens.
<enigma42> Yeah. With the restored cache, it's happy again.
<jelmer> enigma42, if you run "svn log --xml --with-all-revprops" on the last revision, do you see any bzr properties?
<enigma42> Let me try.
<enigma42> Yeah.
<enigma42> They are showing up as revprops.
<enigma42> But bzr-svn thinks it's a 1.4 server because it complains about needing to upgrade to 1.5
<enigma42> jelmer: I tried using the ubuntu pastbin, but it's complaining about the xml.
<enigma42> jelmer: Want an email?
<jelmer> enigma42: No, thanks - I'm pretty sure this is related to the 1.4/1.5 logic
<enigma42> Oh, OK.
<enigma42> Let me know if you want more information.
<jelmer> enigma42, since when have you been using 0.5 ?
<enigma42> Well...the version I was using previously was checked out Dec 27.
<enigma42> But, I've used a variety of versions in the last several months.
<enigma42> Basically, I've been using bzr-svn since April.
<enigma42> I can't remember the first version I used.
<enigma42> It may have been 0.3.x...but I can't remember.
<jelmer> enigma42, and when was the first of these 20 revisions that are now out of sync?
<enigma42> Every revision commited to the branch since I checked out the branch on Jan 9
<enigma42> Using the version from Dec 27
<jelmer> enigma42, is there a bzr:see-revprops file property set on the branch root ?
<enigma42> Let me check.
<enigma42> Yes.
<enigma42> There is a bzr:see-revprops file property there now.
<enigma42> Is it possible to do a bzr log on a file property?
<enigma42> Ack.
<enigma42> I mean an "svn log" on a file property.
<jelmer> enigma42: no, I don't think that's possible
<enigma42> OK.
<jelmer> what are the contents of that property ? It should be a svn revno
<enigma42> It is: 9576
<enigma42> The lastest rev in subversion is: 9725
<enigma42> Little more info..
<enigma42> This project used to be in /trunk/backoffice/sys-data-analyzer
<enigma42> Then, as part of our transition to using bzr as a team, I did an "svn copy /trunk/backoffice/sys-data-analyzer /sys-data-analyzer/trunk"
<enigma42> Then, I did a branch on "/sys-data-analyzer/trunk" to build the bzr branch the rest of the team uses.
<enigma42> And I run a script to push changes back into svn for corporate compliance. ;-)
<jelmer> ah :-)
<enigma42> So, it's a branch has been moved in subversion. That branch had not previously been touched with bzr-svn until after I moved it.
<enigma42> And it has only been touched wtih the bzr-svn version from Dec 27
<jelmer> So what it seems to come down to is that bzr-svn should be looking at that bzr:see-revprops property (since this is svn 1.4)
<jelmer> and that property has the correct value
<jelmer> but it's not reading it for some reason
<enigma42> Is there some logging I can turn on?
<enigma42> Other than the transport stuff?
<jelmer> no, but this patch should add some:
<jelmer> http://samba.org/~jelmer/tmp/bzr-svn-revprop-mutter.diff
<enigma42> OK. Let me apply it.
<enigma42> OK.
<enigma42> It's patched....
<enigma42> Do you want me to move the cache out of the way?
<enigma42> Start with an empty cache?
<jelmer> yeah, please
<enigma42> OK....doing a bzr missing
<enigma42> OK...where should I look for the log?
<enigma42> It says I'm missing 43 revisions and I have 43 extra revisions.
<jelmer> check ~/.bzr.log
<enigma42> OK
<jelmer> that should give some extra data
<enigma42> Want me to pastbin it?
<jelmer> please do
<enigma42> OK...just a minute....I'll post it....
<enigma42> http://pastebin.ubuntu.com/108427/
<enigma42> OK...I'm going to put my old svn-cache back for now.
<enigma42> I've got to run....I'll be back on IRC tomorrow.
<jelmer> ah, I think I've got it
<enigma42> Cool!
<enigma42> I'll leave it logged in....
<enigma42> If you post a fix, I'll pull it down and try it out in a couple of hours.
<jelmer> enigma42, http://samba.org/~jelmer/tmp/fix-changes-root.diff
<enigma42> OK....let me try.
<jelmer> you'll need to revert the patch I posted earlier
<enigma42> OK.
<enigma42> I'll re-export from trunk.
<enigma42> OK...here goes....
<enigma42> REbuilding the cache....
<enigma42> Nice!
<enigma42> Branches are up to date!
<enigma42> Woohoo! :-D
<jelmer> cool :-)
<enigma42> Thank you so much!
<jelmer> Thanks for confirming, that was a pretty stupid bug
<enigma42> No problem. I'm happy I could help out. :-D
<enigma42> I'll do a full sync of all the different repos later and make sure all is well.
<enigma42> Thanks again.
<enigma42> I've been really pleased with 0.5
<jelmer> np
<enigma42> Following copies is great!
<enigma42> Well...I'm off for now....bye....
<thumper> is there a short cut to go to the bottom thread of a loom from the top thread?
<thumper> nm, found it
<thumper> down-thread [thread-name]
 * thumper has found a weirdness
<thumper> in locations.conf I have a default push location set with append path
<thumper> for one of my branches, I wanted this slightly different
<thumper> so `bzr push --remember xyz`
<thumper> however bzr tells me that value xyz is masked by locations.conf
<thumper> surely if I say --remember, it should override a default???
<mwhudson> thumper: --remember sets stuff in branch.conf and locations.conf wins over branch.conf
<mwhudson> there was a thread about this on the mailing list a few months back
<thumper> poos
<mwhudson> (i don't understand the reasoning)
<lifeless> interesting...
<lifeless> http://paste.ubuntu.com/108451/
<lifeless> jelmer: ^ may interest you. Thats invoking git-cat-file per object
<lifeless> morning kiko
<lifeless> jelmer: how are we meant to access the dulwich that is in bzr-git?
<lifeless> jelmer: b.p.git.dulwich ?
 * igc out for a few hours
<j^> why does the ppa repository for hardy remove bzrtools?
<rockstar> j^, once the updated bzrtools gets installed, then it won't remove them.
<vila> hi all
<mcfletch> PPA for Intrepid seems to have been broken (bzrtools is 1.10, bzr is 1.11).
<AfC> mcfletch: are you actively using something from bzrtools? If not, then you could un-install it [for now] and get around the problem\
 * AfC is using bzr 1.11 from PPA but didn't see your problem as I don't have bzrtools installed
<mcfletch> Hmm, interesting, aptitude was telling me it was "broken"... I actually switched back to 1.6 to commit the changes... will try again...
<mcfletch> Ah, I was reading the "recommended" as "required" and the second confirmation as a "you can't do that, choose something else"... guess I shouldn't updates software at 3am.
<mcfletch> thanks for the clue-stick.
<wgrant> jelmer: Using a fresh checkout with bzr-svn 0.5.0~rc1+bzr does work, unlike 0.4.16, and all that fails is a reconcile (check works fine, which is odd). I can then branch that existing local branch locally, and it will work fine. But then checking it out once it's pushed to LP fails with a 'No such file'. I'm very confused.
<Lo-lan-do> Hi all
<james_w> hi Lo-lan-do
<Lo-lan-do> We're debating the ol' git-vs-bzr debate for starting a new project, and I wondered how functional the bzr-git plugin was (or was expected to get soonish)
<james_w> Lo-lan-do: guess who's working on it :-)
<Lo-lan-do> jelmer?  Well, he'll be happy to get rid of me for bzr-svn, but maybe I'll switch to pester him on bzr-git :-)
<james_w> heh
<james_w> Lo-lan-do: it's kind-of functional now, and improving quickly
<james_w> Lo-lan-do: I'm not sure how differences in bzr and git limit it though
<Lo-lan-do> Does it work both ways?
<Lo-lan-do> ie, commit to git from bzr and vice-versa?
<james_w> not sure
<james_w> I imagine it will work like bzr-svn does
<fullermd> But with less svn-induced wonkiness, I should think.
<fullermd> The bzr and git data models are fundamentally so similar that there should be a lot fewer impedance mismatches.
<Lo-lan-do> I'll give it a try, I guess.  We've agreed to have both so far until we can test how interoperable they are.
<jonnydee> I've got a question regarding 'bzr join': after joining a tree, is the sub-tree fully contained in the parent branch? I mean can I remove the .bzr-directory of the joined tree?
<sjokkis> hi. i've made a branch of my project, and i want the branch to become the new trunk. what's the best way to do this?
<sjokkis> (the branch was made to port the project from c++ to c, so i don't think merging is viable)
<luks> 'trunk' in really unrelevant in bzr
<sjokkis> so just delete trunk and copy the branch so it's a new trunk?
<luks> what trunk?
<sjokkis> :(
<luks> it depends on your setup
<sjokkis> they're all just branches with different names, eh?
<luks> yes
<fullermd> Merging could still be viable.  Or you could mv away the old trunk and stick it in its place.  Or you could pull or push it over the existing trunk.  Or just advertise that the trunk is a different place now.  Or...
<sjokkis> fullermd: well the files have new names now that they're in c and not cpp
<luks> that doesn't really matter to bzr
<fullermd> Well, but you branched off that to start with, right?
<fullermd> So the only difference between merging and switching is that in one case, the bighugechange happens in one mainline rev, and in the other it's spread over N mainline revs.
<fullermd> (which isn't to say that you necessary _want_ to do it via merge; but it's just as viable an option, depending on details, as the others)
<jelmer> wgrant, you need the 0.5 branch, rather than the rc
<jonnydee> I tried to 'join' a tree but I get an error: "bzr:ERROR: Cannot join FooBar.  Trees have the same root". What am I doing wrong?
<poolie> we're chatting about the bzr home page; some notes are in gobby.ubuntu.com if anyone's interested
<sjokkis> what's the common way of creating tags in bzr? i'm used to copying to project/tags from svn, but it seems bzr just gives the current (or a specified) revision a name. is this how it's supposed to be done?
<wgrant> jelmer: I'm running r2355 at the moment; do I need later?
<jelmer> wgrant, no, I think that should be sufficient
<jelmer> wgrant, what's the error you're getting exactly
<wgrant> jelmer: On the checkout from LP:
<wgrant> bzr: ERROR: No such file: ('1123@2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:ivle%2Futil.py', 'svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132')
<jelmer> and the backtrace?
<wgrant> The checkout doesn't give one.
<wgrant> The reconcile on the original local copy does; do you want that?
<jelmer> ah, ok
<jelmer> wgrant, I'll try that here locally
<wgrant> jelmer: Thanks.
<bob2> sjokkis: with the tags command
<jelmer> wgrant, reconcile passes successfully here
<wgrant> jelmer: Huh. I'll try checking out again on another box.
<bond`> how can i export a revision with the original file dates?
<bob2> bzr doesn't version ctime/atime/mtime
<bond`> is this a planned feature?
<LeoNerd> I doubt it, for the complexities of making it work cross-platform
<Jc2k> it would probably confuse build systems, too
<bond`> so i have no possibility to see the original file time?
<bob2> what do you mean by 'original'?
<fullermd> Well, the time of commit is known.  So theoretically, export could set file mtimes to the time of last change.
<bond`> bob2: the time the file was changed
<fullermd> Of course, in any but very carefully crafted cases, the time of commit would be different from the mtime of the file when it was committed, and I'm pretty sure that isn't stored.  But do you really care about the difference?
<bob2> bond`: bzr log filename
<jam> vila: ping
<vila> jam: pong
<bond`> bob2: thats ok, i'd like to see something which 'svn export' or 'hg archive' does
 * fullermd points at bug 262261
<ubottu> Launchpad bug 262261 in bzr "Should use the revision timestamp when exporting" [Unknown,Confirmed] https://launchpad.net/bugs/262261
<bond`> fullermd: that's what i mean
<wgrant> jelmer: http://pastebin.com/d3e21e522 is what I get when reconciling a fresh checkout from svn trunk. It really works fine for you?
<jelmer> wgrant, a clean branch created from http://ivle.googlecode.com/svn/trunk/ using bzr-svn reconciles fine for me
<jelmer> wgrant, can you perhaps try a clean import, after removing ~/.bazaar/svn-cache ?
<wgrant> But... but...
<wgrant> jelmer: That's what I tried.
<jelmer> wgrant, and if you try with a newer bzr-svn?
<jelmer> I don't think there's actually any fixes recently that could affect this though..
<wgrant> jelmer: I looked at stuff post-2355, and it doesn't look relevant...
 * wgrant removes stuff from subversion.conf.
<jelmer> wgrant, I'm just trying to eliminate things that could cause it to work for me but not for you
<wgrant> jelmer: You're running bzr 1.11, or bzr.dev?
<jelmer> wgrant, bzr.dev
<wgrant> jelmer: OK, removing all svn-related config didn't work; trying with latest bzr-svn trunk now...
<sjokkis> hi, how do i go undo all changes i've done since the last commit?
<jelmer> sjokkis, "bzr revert"
<sjokkis> oh. that was simple. thanks
<wgrant> jelmer: It still doesn't work... Do we blame bzr 1.11?
 * wgrant should go to bed ~now.
<jelmer> wgrant, not sure :-( Is there any chance you can try with bzr.dev ?
<wgrant> jelmer: I'll hopefully try tomorrow (I'm gone for a week after that).
<wgrant> Thanks for your help!
<jelmer> k
<jelmer> np
<jdobrien> I had some trouble with my bzr installation and I can't figure out how to fix it
<jdobrien> sudo apt-get install bzr .... seems to work
<jdobrien> but then:  bzr
<jdobrien> bash: /home/john/bin/bzr: No such file or directory
<jelmer> looks like you have a dangling symlink there
<jdobrien> yeah i removed it
<jelmer> and you still get that error?
<jdobrien> yeah...im hunting for the symlink...it has to be somewhere
<jdobrien> found it
<jdobrien> :-)
<jdobrien> argh
<LarstiQ> hey jdobrien
<poolie> hi guys
<jdobrien> hi LarstiQ
<poolie> jdobrien: you may need to type 'rehash'
<jdobrien> hash -r?
<jelmer> hi LarstiQ, poolie
<LarstiQ> hey jelmer :)
<jdobrien> LarstiQ: thanks
<jdobrien> The following packages have unmet dependencies:
<jdobrien>   bzrtools: Depends: bzr (< 1.11~) but 1.11-1~bazaar1~intrepid1 is to be installed
<jdobrien> E: Broken packages
<jdobrien> hi poolie
<jdobrien> john@Monolith:/usr$ bzr version
<jdobrien> Bazaar (bzr) 1.11
<jelmer> kfogel, hi
<kfogel> jelmer: just responding to the web site summary mail
<jelmer> kfogel, Actually, I had a Subversion question
<jelmer> kfogel, I've been pulling my hair out trying to use svn_wc_process_committed()
<jelmer> kfogel, it seems to require that the files it's called on are already marked unchanged. Is that correct?
<kfogel> jelmer: can you ask me in #svn?  (and rephrase -- I confess I didn't quite understand the question :-) )
<kfogel> thx
<jelmer> kfogel, yeah, np
<jrwren> ERROR: selected file commit of merges is not supported yet.
<jrwren> Is that true?
<jrwren> just trying to bzr commit -x PathToExclude
<jelmer> jrwren, yes, that's correct - cherrypick merges are not yet supported
<jrwren> this is really hurting me now :(
<jrwren> plus its something my svn loving, bzr hating coworkers can hang over my head :(
<kfogel> https://savannah.gnu.org/support/index.php?106612  ("Preparation for switching Emacs from CVS to bzr on Savannah.")
<kfogel> thought people here might be interested
<Kobaz> ooooo
<Kobaz> people still use cvs?
<Lo-lan-do> They could have switched to GNU Arch...
<jelmer> kfogel: Nice!
<jelmer> kfogel: I've been wondering about the bzr support on Savannah, e.g. it would be nice if they could run loggerhead
<kfogel> jelmer: I think they do, but it's in beta
<kfogel> that's part of what I'm asking in that issue
<Lo-lan-do> A new loggerhead release with some of the proposed patches merged in would help, in that regard *hint* *hint*
<Lo-lan-do> (I'm probably going to become more and more annoying about loggerhead in the near future :-)
 * jelmer is eagerly waiting for the first non-start-loggerhead release..
<jelmer> kfogel:  Are you still looking for an editor for the scenarios on the wiki ? (Sorry, just catching up with list email)
<kfogel> yes!
<jelmer> kfogel, I'm happy to edit some of the scenarios about topics I'm familiar with
<kfogel> jelmer: an aggressive editor -- that is, one who can not only edit scenarios, but take out / add scenarios based on list discussion.
<kfogel> My initial list of scenarios is *not* to be treated as gospel.  quite the opposite.
<kfogel> jelmer: it sounds like when you say "edit" you mean what I think of as "write"
<kfogel> ?
<jelmer> kfogel: Yes, sorry
<kfogel> please do!
<kfogel> jelmer: the reason is that the other purpose (perhaps the real purpose?) of the scenarios is to help us figure out what stories bzr doesn't know how to tell yet.
<kfogel> For example, just trying to write the one-off bugfix scenario has exposed that we don't, actually, *have* a recommended way to go about this that everyone agrees on.
<kfogel> It's important to find that out.
<jelmer> kfogel: Ah, right
<kfogel> jelmer: so, you write the scenarios you feel comfortable with.  Then we see if people say "Wait, that's not how I'd do it!"
<jelmer> will do :-) I actually already see two existing scenarios I would object to..
<jelmer> I've added http://bazaar-vcs.org/Scenarios/ConvertFromSVN
<Peng_> How does one fix conflicting tags? Delete it and pull again?
<enigma42> Peng_: I just ran across that too.
<enigma42> I got a "conflicting tag" message when using bzr-svn.
<enigma42> I delete the tag from the repo, deleted it from svn, retagged the repo and then pushed.
<enigma42> It seemed fine until the second push.
<enigma42> When I got the message again.
<Peng_> I went ahead and deleted them. Blah.
<enigma42> jelmer: Any idea on how I could track down the "conflicting tag" error?
 * Peng_ does it to another copy of the branch too.
<enigma42> jelmer: How do I see what rev svn thinks the tag is pointing to?
<jelmer> enigma42, bzr tags --show-ids
<enigma42> So, I get this: 0.11                 svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:frame-broker/trunk:9425
<enigma42> SVN thinks the tag is set to 9425?
<enigma42> Is there a way to ask SVN to see revision project/tags/0.11 is pointing to?
<elmo> oh hai
<enigma42> jelmer: Oh...I think my issues is related to the bad id problem we found yesterday.
<elmo> # bzr ci -m "wut" alternatives/abort.7.gz
<elmo> bzr: ERROR: Not a branch: "/usr/share/postgresql/8.3/man/man7/abort.7.gz/".
<elmo> has anyone seen that?  i can't reproduce it locally
<enigma42> It looks like the revision id in svn is different than the revision ID in the bzr branch.
<jelmer> elmo, I think I've seen that
<jelmer> elmo, And caused by some plugin I had installed
<jelmer> elmo, What plugins are installed on the host where you get that error?
<jelmer> enigma42, Ah, that would explain it
<elmo> jelmer: just bzr tools
<elmo> ah, actually I can reproduce it locally
<elmo> let me try with bzr 1.11
<enigma42> jelmer: I'm re-branching off SVN...I'll see what happens...
<enigma42> jelmer: OK...Now I have a new issue: bzr: ERROR: The branch svn+https://sequoia.csd200a.com/svn/sequoia/frame-broker/trunk has no revision None.
<enigma42> So, it's refusing to make a branch.
<Peng_> ...
<jelmer> enigma42: That's most likely fallout from the problem we fixed yesterday (a tag referring to a nonexisting revision?)
<enigma42> So, I should be able to fixup the svn reprop?
<jelmer> enigma42, Any chance you can comment out the bit in bzrlib/builtins.py where it prints that message by catching NoSuchRevision?
<enigma42> jelmer: OK...let me try.
<Peng_> jelmer: I just hit bug 308353 again, with the latest trunk (more or less). :\
<ubottu> Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/308353
<enigma42> jelmer: Grabbing a source copy of bzr so I can comment it out.
<elmo> le sigh
<jelmer> Peng, which URL?
<elmo> jelmer: it's https://bugs.launchpad.net/bzr/+bug/128562, FWIW
<ubottu> Launchpad bug 128562 in bzr "bzr commit FILE breaks when given symlink as argument" [Medium,Confirmed]
<elmo> (and is still broken in bzr 1.11)
<jelmer> elmo, ahh
<Peng_> jelmer: Same URL (lighttpd-1.4.x)
<jelmer> Peng_, just doing a clean branch?
<Peng_> jelmer: No, "bzr pull".
<Peng_> Err, wait a minute. I hit *something*, but I'm not sure it's the same something.
<enigma42> jelmer: Do you want me to comment out the whole "except" block?
<enigma42> jelmer: It looks like it deletes the tree, prints the message, and raises a different error.
<Peng_> jelmer: Sorry, my mistake. It was just the bzr-search error I get. I forgot that it indexes the branch on "pull", and most of the traceback went off my screen.
<poolie> hello all
<poolie> abentley, if you're here -  http://bazaar-vcs.org/WritingPlugins used to advise people to merge their plugins into bzrtools
<poolie> i removed it
<poolie> it's an option but i don't think we want it to be a catch-all
<jelmer> enigma42, yes, please
<jelmer> enigma42, that should make it show the proper traceback
<jelmer> Peng_, Ah, so this is the same problem you reported a bug for earlier?
<abentley> poolie: Okay
<Peng_> jelmer: Yeah, it's nothing new. I just forgot that bzr-search kicks in on "pull".
<abentley> poolie: The desire was for bzrtools to become a collection of utilities so that people didn't have to spend forever installing new plugins.
<enigma42> jelmer: OK...I'll pastbin the traceback....
<abentley> poolie: shelf and heads have worked out that way, but few others.
<jelmer> Peng_, which reminds me, do you have a link to that bug?
<enigma42> jelmer: http://pastebin.ubuntu.com/108674/
<jelmer> enigma42, that looks like a problem in what you changed in builtins.py
<Peng_> jelmer: https://bugs.launchpad.net/bzr-search/+bug/318935
<ubottu> Launchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New]
<enigma42> jelmer: Oh..I see it...the exception was thrown before "branch" was assigned....
<jelmer> Peng_, Thanks
 * enigma42 is commenting out more stuff...
<enigma42> jelmer: Well that's strange...I cleared the cache and now I don't get an error.
<enigma42> jelmer: Must have been one of those bad ids stuck in the cache.
<enigma42> Oh wait...hold on...
<enigma42> I must have commented out too much stuff.
 * apw wonders if there is a command to bzr command line to show both the summary message and the diff for a commit in one go
 * enigma42 is changing the commenting again...
<enigma42> Ah ha! I figured it out....my python is a bit rusty... :-P
<enigma42> jelmer: OK...let me get this backtrace into the pastebin....
<Peng_> Oh, I just hit a bunch of conflicting tags in bzr-svn too.
 * mgedmin actually also wants what apw wants
<Peng_> jelmer: With the very latest bzr.dev, there are warnings about your "determining changes" progress bar.
<Peng_> One for every revision, in fact. :D
<mgedmin> so, can bzr do what 'git log -p' does, i.e. show the diff for every log revision?
 * Peng_ looks at apw and mgedmin.
<enigma42> http://pastebin.ubuntu.com/108697/
<jelmer> enigma42, thx
<poolie> mgedmin: iirc there's a patch to add that up now
<jelmer> mgedmin, not yet, but there's a patch waiting for inclusion
<mgedmin> nice
<poolie> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4972A474.3060303%40internode.on.net%3E
<poolie> you can test it!
<jelmer> poolie, After pulling bzr.dev I'm now getting the following error:
<jelmer> /home/jelmer/bzr/bzr.dev/bzrlib/ui/text.py:96: UserWarning: ProgressTask(1165/2000, msg='determining changes') is not the top progress task ProgressTask(1164/2372, msg='analyzing repository layout')
<jelmer> what does this mean exactly ?
<enigma42> jelmer: I'm looking at the revprops...in the svn repo.....It looks like the "base-revision" is not the same as the "rev-id" of the parent.
<jelmer> enigma42, the uuid is different?
<enigma42> Yeah....
 * davidstrauss is waiting for one of the 500 people in #git to not ignore him so he can write a balanced blog post comparing a git workflow to bazaar's.
<enigma42> name="bzr:base-revision">svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:frame-broker/trunk:9425
<jelmer> enigma42, Did the svn repository recently change its UUID ?
<enigma42> bzr:revision-id">emailaddress@somewhere.com-20090113191650-3swujyym2rdqlh0f
<enigma42> So, the revision ID isn't using the svn UUID at all.
<enigma42> Since the revision was pushed into SVN from bzr, I presume...
<jelmer> enigma42, yeah, but it refers to its parent revision
<enigma42> jelmer: How much of that log did you get? I tried to /msg it to you.
<jelmer> I saw some of it
<enigma42> Let me try little chunks....
<jelmer> enigma42: But the problem appears to be that the Subversion repository UUID has changed since that bzr-svn revision was committed
<jelmer> Could that be correct?
<jelmer> are you perhaps working on a svnsynced copy of the repo?
<jelmer> 'morning Ian
<jelmer> enigma1, did you see my messages here?
<enigma1> jelmer: The only thing that has changed is that I delete my svn-cache....and you fixed that bug around the ids.
<enigma42> jelmer: How do I find the SVN UUID?
<jelmer> enigma42: "svn info <repos-url>"
<enigma42> OK
<enigma42> jelmer: No...it looks like the subversion ID is the same.
<enigma42> jelmer: This is my guess...
<enigma42> What I saw yesterday before the bugfix was that bzr-svn was inventing rev-ids instead of using the ones that were stored in the revision properties.
<enigma42> So, somehow, when I tagged, the rev-id that had been invented was used instead of the rev-id that was stored in the SVN revision property.
<jelmer> enigma42, see privmsg
<poolie> jelmer:  the warnings mean there is probably a missing pb.finish() on the progress bar with those messages
<poolie> or, as in one other case, the finally is wrapped around an iterator, so it's firing asynchronously to the operation actually finishing
<poolie> i'm open to either fixing them up or silencing the warning
<poolie> we should do one or another before releasing
<jelmer> poolie, yeah, it's two progress bars working at once
<jelmer> A function that iterates over a set of revisions by calling a generator
<jelmer> that function has a progress bar
<jelmer> and the generator also has a progress bar
<enigma42> jelmer: OK...I fixed up the rev-id....trying to branch again....
<poolie> jelmer: ok, that's good to know
<poolie> because i was wondering whether we needed to support two of them updating at the same time
<poolie> the api is a bit unclear about whether it's meant to be a stack or not
<jelmer> poolie: it does make sense to only have one in this situation I guess
<poolie> jelmer: so is one of them nested inside the other?
<poolie> or, are they unsynchronized?
<poolie> and if so, how would you like them drawn in the text ui?
<phinze> okay, bazaar is confusing me today.  i have a local branch of a shared project branch i was working on (last pulled at 2117).  i made a commit (2118) locally and attempted to push, but the branches had diverged and bzr tells me to merge.
<jelmer> phinze, what does "bzr missing" report?
<phinze> so i merge with the project branch which pulls down three revisions that had made it in while i was working
<jelmer> poolie, I need to check
<phinze> then i commit the merge 'merged with project branch', (2119)
<phinze> and i push
<poolie> jelmer: just let me know
<enigma42> jelmer: Woohoo! Branched just fine. Going to try a push and pull for good measure....
<phinze> but now the three revisions i pulled down (from someone elses work) show up as sub-revisions from my commit
<phinze> 2117.1.1-3
<enigma42> jelmer: Great! It's working fine. The tags are now in-sync between the bzr branch and the svn repo. :-D
<enigma42> jelmer: Thanks again for your help. And thanks for showing me the "svn log --xml --revprops -r ___" trick.
<jelmer> enigma42, Np, thanks for helping get this bug fixed before 0.5.0!
<jelmer> phinze, yes, this is intentional behaviour of "bzr merge"
<Peng_> What determines whether bzr-svn will spend a bunch of time "determining changes" when pulling or not?
<enigma42> jelmer: I'm happy to help. Thanks for making bzr-svn! It lets some of us use a *real* VCS in a heavily centralized corporate environment!
<jelmer> Peng_, "determining changes" means it's walking history, that can be triggered by various things
<phinze> jelmer: okay, but say i didn't work that gets commited while i'm working to show up as a sub-revision when i merge... how would i change my workflow?
<phinze> *didn't want work
<phinze> perhaps i need to add to my workflow a mirror branch rather than just maintaining one local branch that i sync with the shared project branch...?
<phinze> or perhaps the best answer is, "don't worry about other commits showing up as sub-commits from your merge... get over it!" :)
<jelmer> phinze: Yeah, I think that summarizes it up well
<jelmer> Peng_, I fixed that bug
<Peng_> jelmer: Which bug?
<jelmer> Peng_, 318935
<jelmer> Peng_, bug 318935 I mean
<ubottu> Launchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New] https://launchpad.net/bugs/318935
<davidstrauss> Is there a way to automate bzr-search indexing on a server?
<davidstrauss> I mean, other than crontab.
<Peng_> jelmer: Oh. It was a bzr-svn bug?
<jelmer> Peng_, yep
<jelmer> Peng_, bug in the bugfix for that other bug :-)
<Peng_> jelmer: Heh, nice. Have you pushed it yet? Do I need to do anything, like delete the cache or recreate the branches?
<jelmer> Peng_, Yeah, it's been pushed. You need to recreate the branch and delete the cache.
<Peng_> Both? Awesome! :D
<Peng_> Thanks for fixing it.
<jelmer> poolie, I've fixed the progress bar issues
<poolie> ok
<jelmer> poolie, Simply by not using the inner progress bar, it wasn't adding much useful information anyway
<poolie> i'm totally open to changing or fixing the api if you need something richer
<poolie> ok
<jelmer> poolie, I think it needs to be richer, but I'm not entirely sure how :-)
<poolie> (:
<jelmer> poolie: I think at least it's important for progress bars that each step takes an equal amount of time
<poolie> or as near to it as you can get, allowing for environmental variations
<jelmer> poolie, the "Fetch phase X" thing where there's 4 phases that all take arbitrary amounts of time is very uninformative
<poolie> like obviously if you're doing disk io and network io the relative speeds will be unpredictable
<poolie> jelmer, i agree
<poolie> i think the "phase" thing is questionable
<poolie> the basic idea there is that we want the progress bar to appear just once for each command and fill monotonically from left to right
<poolie> rather than one bar for fetching and then another for building the tree
<jelmer> oh, ok
<poolie> so it's not a bad thing to want
<poolie> but i don't think the result is very satisfying
<poolie> this patch improved a couple of things: you see all the stacked tasks, so usually more than just "fetch 1/4"
<jelmer> I think I prefer separate bars but having bzr print a new line with what it's completed
<poolie> and also, (currently only for sftp) you get an indication of network io
<poolie> separate bars would be good
<jelmer> poolie, Yeah, I agree the new progress bar is an improvement
<Peng_> jelmer: Yay, it works. :)
<poolie> yay
<poolie> 'bzr serve --http' does what it should
<Peng_> bzr+http or Loggerhead?
<jelmer> or both ? :-)
<Peng_> Oh, thank goodness, those pb-related warnings don't go in .bzr.log.
<jelmer> Peng_, they're fixed in 2379
<Peng_> jelmer: Okay, thanks.
<poolie> Peng_: actually loggerhead, but beuno and jml are making loggerhead serve bzr+http
<poolie> so, this afternoon, hopefully both
<jml> just http to start with
<jelmer> that's a *really* neat thing to have
<poolie> and loggerhead will be (optionally) a plugin
<poolie> optionally meaning you can use it in the same way as before
<Peng_> #I'm being lazy here, but what was the summary of enigma42's tag conflict problem? I'm experiencing conflicts in some (but not all) tags, but I don't think
<Peng_> Peng is an idiot.
<Peng_> I didn't mean to send that. :)
<Peng_> Although it's true, but anyway, I was going to investigate it more first.
<jelmer> Peng_, It was related to a strange corner case bug caused by svn 1.4 on the server and bzr-svn not always looking at revision properties
<Peng_> Oh, I think it's because some are using "svn-v3" revids and some are using "svn-v4".
<jelmer> that primarily caused diverging branches
<Peng_> Oddly, the copy made 5 minutes ago is using more "svn-v3" ids.
<jelmer> Peng_: Can you please file a bug?
<Peng_> I wasn't using a 100% new repo; I "bzr branched" two (non-corrupt) branches into it.
<Peng_> Oh, "bzr log" shows a lot of svn-v3 ids too.
<DBO> you know what would rock?  If bzr could figure out when you move a file without having to use bzr mv
<DBO> mmhmmm mhmmm =)
<Peng_> I've kind of confused the situation by swithing out the repos too. Hmm.
<jelmer> Peng_, Yeah, it's correct there are svn-v3 ids there
<jelmer> Peng_, that's because there are revisions created with older versions of bzr-svn
<Peng_> jelmer: What do you mean? My branch is (almost) completely new.
<Peng_> You mean revisions in the svn repo pushed by older versions of bzr-svn?
<jelmer> Peng_, yes
<Peng_> It looks like it's all "svn-v3" except for the very newest revision.
<jelmer> Peng_, yeah, everything since the last revision pushed with bzr-svn 0.4.x will be a svn-v3 revision
<jelmer> Peng_, That bit seems to work fine
<Peng_> Okay.
<jelmer> except bzr-svn gets confused about what mapping to use for those tags apparently
<Peng_> Well, the more recent branch gets it right much more often.
<jelmer> more often is not good enough :-)
<Peng_> The new branch has: 22 tags (1 svn-v4, 1 bzr, 20 svn-v3), 20 of which it can map the revid to a revno, 2 of which show "?".
<jelmer> so for what tags do you get conflicts?
<Peng_> I've been doing lots of things to this repo today, so I don't even remember.
<Peng_> I think I got the conflicts on about 6 tags with the old branch and old repo.
<Peng_> jelmer: FWIW, pastebin of "bzr tags" on both branches: http://paste.pocoo.org/show/BIEg11uNyMGQ4Fr1phem/
<jelmer> Peng_, thanks
<jelmer> lifeless, ping
 * jml submits the branch for review.
<vila> jam: ping
<nxsryan> hi.. i'm trying to do brz branch lp:trac-bzr but i think i have an older version of bazaar that doesnt convert "lp
<nxsryan> oops
<nxsryan> hi.. i'm trying to do brz branch lp:trac-bzr but i think i have an older version of bazaar that doesnt convert "lp" into a URI
<nxsryan> can someone tell me what URI 'lp' stands for?
<vila> launchpad
<Peng_> nxsryan: You should upgrade bzr. You'd have to be on a really old version.
<nxsryan> sure but.. that's not a complete URI
<Peng_> nxsryan: What command did you run and what error message did you get?
<nxsryan> Peng_: i know i should but that's not an option at the moment
<Peng_> nxsryan: Bazaar does a bit of magic to turn it into a real URL.
<vila> what do 'bzr version' and 'bzr plugins' say ?
<nxsryan> # bzr branch lp:trac-bzr
<Peng_> nxsryan: lp:trac-bzr points to http://bazaar.launchpad.net/%7Etrac-bzr-team/trac-bzr/trunk/ or bzr+ssh://bazaar.launchpad.net/%7Etrac-bzr-team/trac-bzr/trunk/
<nxsryan> bzr: ERROR: Not a branch: /root/trac-bzr/lp:trac-bzr/
<nxsryan> Peng_: ah, nice, thank you
<Peng_> /root? *cough*
<Peng_> ...The Launchpad plugin has been around *forever*.
<nxsryan> hrm, bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 6 (bzr 0.15)\n'
<vila> nxsryan: what do 'bzr version' and 'bzr plugins' say ?
<nxsryan> i'm using 0.14
<vila> then, you need to upgrade to at least 0.15 at the message is hinting
<vila> but since 1.11 is out, please, just upgrade to that instead :)
<Peng_> Huh, lp: URIs are newer than 0.14?
<Peng_> Hmm, I think it was added in revision 2275.
<dereine> hi is it possible to update a certain branch without ssh access, just ftp
<vila> Peng_: I dont't know I have all releases available from 1.0 but not earlier
<vila> dereine: It should
<dereine> vila: i pushed to files onto the server
<dereine> then i tryed to use update
<dereine> but it didn't wokred
<Peng_> Yeah, it was added in revision 2275. Apparently it wasn't found NEWSworthy though.
<Peng_> But that would've been around 0.15 or 0.16.
<Peng_> Yeah, 0.15.
<vila> dereine: update updates your working tree from the branch, do you want pull instead ?
<poolie> jam, nice work on the locking patch
<dereine> vila: does pull changes the files itself?
<jam> vila: pong
<vila> dereine: pull updates your working tree yes
<jam> poolie: thanks. I don't really *like* doing it that way, but since we have been waiting a long time to actually do it the right way
<dereine> i will have a try thx
<jam> I figured we may as well do *something*
<poolie> beuno: if __name__ == 'bzrlib.plugins.loggerhead':
<jml> poolie: that won't work :(
<jml> try: from bzrlib.plugins import loggerhead; except ImportError: pass; else: ...
<jml> hmm. actually, that would work
<jml> silly me
<beuno> Peng_, loggerhead trunk needs you
<Peng_> Heh.
<Peng_> Oh, it just serves them as static files so far?
<jml> mwhudson: good morning. :)
<beuno> Peng_, yeap
<beuno> no smart server involved yet
<Peng_> Hmm, this conflicts with my setup. I have the branches available (with hpss) at /bzr, with LH at /loggerhead.
<beuno> Peng_, and how does this overlap?
<jml> Peng_: you mean the URLs that loggerhead gives are the static LH urls, not the smart /bzr ones?
<jml> because they should both quietly mind their own business wrt serving branches.
<Peng_> beuno: Loggerhead suggests branching it from /loggerhead.
<Peng_> I already handle this with redirects, but it's messy.
<beuno> Peng_, ah!
<beuno> so it should be configurable
<beuno> -ish
<Peng_> Well, I could do some ugly monkeypatch in serve-branches, so it already is "-ish". :D
<beuno> :)
<Peng_> Or I could just edit branch.py itself, of course, but that seems wrong.
<Peng_> Oh wow, monkeypatching actually works easily.
<beuno> well, it *is* loggerhead
<beuno> igc, ping
<Peng_> I was expecting the property bits to make it difficult to monkeypatch.
<Peng_> Yay, my evil monkeypatch worked.
<Peng_> beuno: Anyway, I haven't experienced any problems.
<beuno> Peng_, awesome
<beuno> and if you file a bug about maybe not exposing the URLs to branch from
<beuno> we'll get it done
<beuno> just for you
<Peng_> But I only tested /changes, /revision, and /annotate; not the other pages, or the .bzr serving itself.
<igc> hi beuno
<beuno> hiya igc. How are you?
<igc> not too bad
<beuno> I've been playing for quite a while with your plugin
<beuno> revnocache
<beuno> igc, are you up to explaining some concepts/code?   I'd like to pitch in a little bit if I can
<igc> sure
<beuno> you're using repository._old_get_graph
<beuno> to get the graph
<igc> I'm about to hack on it right now btw :-)
<beuno> awesome then!~
<igc> I'm doing whatever Branch.get_revision_id_to_revno_map() uses now
<beuno> I'm curious about you using that bit, since bzrlib has a big comment: """DO NOT USE. That is all. I'm serious."""
<igc> 'cause I'm monkeypatching it
<igc> Right
<igc> beuno: the current code is very short term hopefully
<igc> I have a patch up to Branch giving it a new method: iter_merge_sorted_revisions()
<igc> as soon as that lands, I'll look against it rather than the revo lookup hack
<igc> s/revo/revno/
<Peng_> beuno: Wait, what do you want me to file a bug about?
<igc> s/look/hook/
<beuno> Peng_, maybe hiding the branch URL?
<beuno> igc, so there's not other (good) way of doing this without patching bzrlib?
<Peng_> beuno: I like having to branch URL shown, I just want it to be different. :)
<beuno> Peng_, fair enough. What could we do to address your use case?  Use hpss by default?
<igc> beuno: not sure
<igc> but the right direction is caching the graph ...
<beuno> igc, absolutely
<igc> because then revno lookup, log, missing and friends can all "go fast"
<Peng_> beuno: I'm not sure what you could do to address my use case. :P
<beuno> igc, I'm trying to understand it in depth, so I can make it play nic with loggerhead
<igc> right now, it's only the first of these
<beuno> igc, in LH, to get the revision graph I do something like: http://paste.ubuntu.com/108777/
<igc> beuno: see I think you want iter_merge_sorted_revisions() as soon as it exists
<beuno> igc, I do!
<beuno> I'm stalking the ML waiting for that to land
<igc> beuno: I just posted an updated version a hour or so ago
<beuno> igc, I saw. Waiting for jam to be happy and approve  :)
<igc> beuno: please check that it's API is useful to you know that I've extended it as jam requested
<igc> s/know/now/
<beuno> igc, I'll go through the code now and add a comment
<igc> beuno: cool. If poolie is near-by, bug him to look at it too :-)
<beuno> igc, he's across the table from me. Not very awake, but here. I'll poke
<poolie> hello
<igc> poolie: ignore that poke if you're tired. I understand the value of sleep :-)
<beuno> igc, so this patch lets you limit the range of the graph you generate?
<beuno> IIUC
<beuno> by using revids?
<igc> beuno: yes
<beuno> igc, unless I request revnos?
<beuno> +        # Note: depth and revno values are in the context of the branch so
<beuno> +        # we need the full graph to get stable numbers, regardless of the
<beuno> +        # start_revision_id.
<igc> beuno: my goal is that, once loggerhead uses iter_merge_sorted_revisions(), it needs to do nothing else and it will get faster if revnocache is installed as well
<poolie> igc: i bet
<igc> beuno: so my patch now generates and caches (in memory) the full branch graph
<beuno> igc, I see. We currently cache the revision graphs in LH as well, using LRUCache
<igc> revnocache will complement that by saving/restoring the full graph, eliminating the calculation stage (except after a tip move)
<beuno> aha!  that's where it gets interesting
<beuno> we would load the graph from disk instead of re-generating it
<igc> yes - revnocache does not now
<igc> (with the right CACHING_STRATEGY configured)
<beuno> igc, I still get around 7sec to do 'bzr log -r X.Y.Z' on mysql-server
<beuno> with mergegraph strategy
<igc> right, because log is regenerating the graph!
<beuno> and a bit less with revno strategy
<beuno> ah!
<beuno> hence the patch
<igc> precisely
<igc> (and a follow-up refactor of log to call the new API)
<beuno> igc, ok, so for LH to take advantage of this, this patch has to land, and I have to switch LH over to using iter_merge_sorted_revisions
<igc> beuno: yes
<beuno> perfect
<beuno> just perfect
<igc> beuno: so my coming revnocache hacks are ...
<igc> 1. change the graph cache to drop the seqnum
<igc> 2. support chaining
<igc> The latter will let us store just the graph since the parent
<igc> and point to the parent cache if it's local
<igc> perfect for the usual mirror+feature-branches setup
<beuno> cool, so it'll be less expensive when the branch gets updated
<beuno> as long as it hasn't done merges?
<igc> right, and much less storage
 * poolie goes to look
<igc> beuno: tip moves aren't optimised yet, merges or otherwise
<beuno> igc, I do wonder why your patch still uses repository._old_get_graph
<beuno> igc, right, that was one of the things I thought I'd try to poke at, as soon as I figured out all of this. But you're already on it  :)
<igc> beuno: only because I wanted to ensure my monkeypatch was bug-for-bug compatible
<igc> beuno: actually, I've love it if you could optimise the tip move bit
<igc> (it's not high on my list yet)
<enigma42> jelmer: Ping
<jelmer> enigma42, pong
<igc> beuno: but you may want to wait a few hours until my next round of hacks ...
<enigma42> This has got to be the strangest error I've seen yet.
<beuno> igc, I could very well give it a try. It's past 9pm here, so not sure *when*, but it will be high in my list  :)
<enigma42> jelmer: bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack
<poolie> igc, you're refering to iter_merge_sorted_revisions?
<enigma42> Let me pastebin it.
<jelmer> enigma42, full backtrace?
<igc> poolie: yes
<igc> beuno: I'll put comments in the code and/or fire you an email about how to do it
<beuno> igc, FWIW, I changed LH from _old_get_graph to get_graph() without any consecuences  :)
<beuno> igc, that would be awesome
<enigma42> jelmer: http://pastebin.ubuntu.com/108782/
<igc> beuno: ok, it's saturday morning here so my time is limited
<igc> better get on with this hacking or it won't happen for a few days (long weekend here) :-)
<beuno> igc, oh, please don't feel imposed. I'll give it a quick whack and see if I can send a patch to your patch  :)
<enigma42> jelmer: This is bzr-svn 0.5 revno 2372
<poolie> the good thing about having an intense sprint in argentina is that people (and restaurants) _expect_ to eat dinner at 11pm :)
<jelmer> enigma42, when does this happen?
<igc> poolie: :-)
<enigma42> So, this is an svn repo that has been used by bzr-svn 0.4.x for a while.
<enigma42> This happens when branching.
<enigma42> This is the first time I've tried 0.5 on it.
<jelmer> enigma42, so it's a different repository
<jelmer> ?
<enigma42> Right. Not the one from before.
<enigma42> This is a new repo I haven't posted about before.
<enigma42> Coworker of mine was using bzr-svn 0.4 on it.
<enigma42> First symptom was...
<enigma42> Could pull down a branch just fine, but then could not make a local branch.
<enigma42> (with 0.4.x)
<enigma42> When trying to make the local branch, it complains about missing revisions.
<enigma42> So, I thought I would give it a try with 0.5-trunk to see what happens.
<enigma42> And that's the backtrace I posted.
<jelmer> enigma42: So this is an error trying to parse one of the bzr-svn file properties
<enigma42> OK.
<enigma42> jelmer: That doesn't sound very fixable...is it?
<enigma42> I guess what I mean is the file property is probably messed up....
<enigma42> Let me check to see if there are any revprops on this svn repo....
<jelmer> enigma42, it's not a revprop that is invalid, it's a fileprop
<enigma42> OK.
<enigma42> hughesw: This is your repo...when did you start having the problem?
<hughesw> monday. after updating to bzr 1.10 and bzr-svn 0.4.16 from the package on the bazaar site.
<hughesw> whoops
<jelmer> any chance you can try with a patch that shows a bit more information?
<enigma42> I'm happy to.
<enigma42> Send me the patch. :-)
<enigma42> (this patch would be against 0.5, right?)
<jelmer> yes
<jelmer> http://samba.org/~jelmer/tmp/fileid-fileprop.diff
<enigma42> OK....patching....
<enigma42> jelmer: Should I zap the cache?
<jelmer> enigma42, no
<enigma42> OK
<enigma42> jelmer: branching....there are some big files in this repo so it takes a while....
<hughesw> yeah the trunk of that repo is 52 MB...
<beuno> igc, maybe something like this: http://paste.ubuntu.com/108789/
<enigma42> jelmer: http://pastebin.ubuntu.com/108793/
<jelmer> Are you sure that's with the patch applied? it doesn't seem to trigger the exception handling
<poolie> (back to reading igc's patch thread)
<enigma42> jelmer: I'll double check to be sure. But I'm pretty sure...
<jelmer> enigma42, alternatively, can you run with BZR_PDB=1 as environment variable set?
<enigma42> Yup. I just double checked...it has the patch for sure.
<enigma42> OK.
<jelmer> enigma42, ah, sorry
<jelmer> enigma42, what did it print on the screen?
<jelmer> enigma42, rather than to .bzr.log ?
<enigma42> Just pasting.....
<enigma42> http://pastebin.ubuntu.com/108796/
<enigma42> Should I type anything at the Pdb prompt?
<hughesw> hey that looks remarkably similar to the error it was giving me when I tried to branch on my home machine with 0.4.16
<beuno> jml, http://people.samba.org/bzr/jelmer/bzr-gtk/trunk/
<poolie> igc, done
<igc> poolie: thanks
<poolie> jml: http://groups.google.com/group/fp-syd?hl=en
<enigma42> jelmer: Just let me know if you want me to send you more info.
#bzr 2009-01-24
<jelmer> enigma42, sorry, back now
<jelmer> enigma42, see privmsg
<jelmer> enigma42, sorry you seem to be hitting the jackpot of bzr-svn bugs :_(
<enigma42> jelmer: :-) No problem.
<enigma42> jelmer: I'm happy to report them so they won't be bugs anymore. :-D
<jfroy|work> might have seen this issue before myself
<jfroy|work> somewhat curious about it
<jfroy|work> I'm still using my alternate prefix hack to work around possibly invalid bzr-svn properties :/
<jelmer> jfroy|work, is there a bug open about that?
<jfroy|work> jelmer: never investigated in depth the problems. It's more of a speculative hack, in the sense that I used early versions of 0.5 at some point which may have written now-invalid properties.
<hughesw> it's really odd, old old versions of bzr-svn can pull down from this repo without issue (0.4.9 in hardy for instance) but 0.4.16 crashes when making local branches and it looks like enigma42's got 0.5 crashing on the actual svn branch
<jfroy|work> Until and if I can dump and reload the repository, there's no much else to be done.
<jelmer> jfroy|work, can you send me that hack? Should give me some idea as to what's going wrong?
<jfroy|work> jelmer: it's nothing like that. I merely changed the prefix from bzr to bz2, such that all previous bzr-svn attributes, including the potentially invalid alpha 0.5 ones, are effectively ignored.
<jfroy|work> Been using the last build of 0.4 for months with that modification without any issues.
<enigma42> jfroy|work: That hack is clever...I was wondering what I might be able to do for bad 0.4.x metadata.
<jfroy|work> enigma42: yeah, it worked remarkably well.
<jfroy|work> Forces people interfacing with that repository to use a custom branch of bzr-svn.
<jfroy|work> A better solution would be to add a property that bzr-svn could check first, say bzr:bzr-svn-prefix
<jelmer> jfroy|work, any chance you can try again with a vanilla bzr-svn 0.5 ? It would be nice to get this sort of thing fixed before 0.5.0
<jfroy|work> which it would read from the most recent revision. That way, the prefix for all clients could be changed by the repository itself, versus a code change.
<jfroy|work> jelmer: I'll give it a try.
<jfroy|work> What's your release schedule? I should get enough time to do a useful test next week.
<jelmer> Before the end of january basically
<jfroy|work> That's pretty tight, might not be able to generate good enough data. But we'll see.
<jfroy|work> I'll try to live a few days on mainline 0.5, and hopefully any issues will pop up.
<jfroy|work> Note that this isn't a case of just migrating from 0.4 to 0.5. The svn repository involved has pre-release 0.5 properties as well.
<jelmer> jfroy|work, Just doing a clone with bzr-svn should demonstrate that problem if you've hit it in the past
<enigma42> jfroy|work: I've been living on mainline 0.5 since mid-december. It's been good!
<enigma42> jfroy|work: revprops are the best!
<enigma42> jfroy|work: I was just able to fixup a metadata error this morning because I'm using revprops now.
<jfroy|work> enigma42: sadly the svn server we're using is still 1.4
<jfroy|work> no revprop for me :|
<enigma42> jfroy|work: We have a 1.4 server, but revprops are enabled.
<jfroy|work> oh?
<jfroy|work> I could have sworn that was a 1.5 feature
<enigma42> Yeah.
<enigma42> Well, we're hosted on collabnet.
<jfroy|work> Secret sauce huh
<enigma42> I guess.
<jfroy|work> bzr-svn is using properties on the root directory of branches, at least as far as I can tell.
<jelmer> jfroy|work, yes
<jfroy|work> on my repository, I mean
<jfroy|work> so they're not revprops. AFAIK Trac doesn't display revprops anywhere in its SCM browser module.
<jelmer> jfroy|work, I'm not sure what causes a server to support revision properties during commit
<jelmer> jfroy|work, bzr-svn just looks at what capabilities the server has
<jfroy|work> jelmer: neither am I
<jelmer> maybe a later 1.4 point release?
<enigma42> Since it's on collabnet, it could be some special svn code.
<LaserJock> anybody know if there's a branch format/bzr version chart or table?
<enigma42> I just read "bzr help upgrade"
<nDuff> "bzr help formats", "bzr help current-formats" and "bzr help other-formats" should be helpful; I don't know about a table.
<nDuff> ...both current-formats and other-formats include information on when the given formats were introduced
<LaserJock> nDuff: I don't have either of those
<LaserJock> just bzr help formats
<LaserJock> a table would be nice though, to decide whether to upgrade or not
<nDuff> in current versions, "bzr help formats" has textual guidance on whether to upgrade
<nDuff> ...it's also in a mailing list post somewhere, and I should be able to do a quick pastebin...
<nDuff> http://pastebin.ca/1316514
<LaserJock> hmm
<LaserJock> that's sort of helpful
<LaserJock> but it kind of assumes you standarize around a bzr version
<LaserJock> rockstar: around?
<rockstar> LaserJock, yes, but my wife is hungry, so not for long.
<rockstar> What's up?
<LaserJock> rockstar: do you know of any plan to have downloadable tarballs of bzr revisions?
<LaserJock> rockstar: seems like that would really speed up "branching" in some cases
<rockstar> LaserJock, what do you mean?
<rockstar> Do you want just a tarball of the current up to date bzr branch's working tree?
<LaserJock> rockstar: meaning, like github, you could select a revision and LP would give you a tarball to download
<LaserJock> no, not the working tree, the .bzr
<rockstar> Someone asked a question about that recently, but we hadn't talked about it at all.
<LaserJock> k
<rockstar> LaserJock, I don't see where the speed up really is there.
<LaserJock> just struck me as I sit here for an hour trying to branch something ;-)
<rockstar> Either way, you're downloading it.
<rockstar> LaserJock, what are you trying to branch?
<LaserJock> yeah, but bzr is a lot slower than just rsync/wget a tarball of .bzr
<LaserJock> rockstar: lp:gnome-app-install
<rockstar> LaserJock, it's taking you an hour to branch 637 revisions?
<LaserJock> something like that
<LaserJock> I'm not timing well
<LaserJock> I need to alias bzr to time bzr :-)
<rockstar> LaserJock, hm, I suspect there's something amiss here.  Without a shared repo, I can branch 1000 revisions relatively quickly.
<LaserJock> it's because it's in an ancient format I believe
<rockstar> LaserJock, ah, that might be.
<LaserJock> I seem to always hit on those
<LaserJock> I don't understand how I end up so cursed with bzr
<LaserJock> just my lot in VCS-life I guess :-)
<LaserJock> rockstar: can I do one of these new stacked branch thingies with it?
<LaserJock> or does the repo have to be in a certain format for that
<rockstar> Not if it's in an ancient format.  You need 1.6 or better.
<jelmer> jfroy|work, YOu had installed subvertpy manually as well right?
<LaserJock> man, I can't tell if it's frozen or something
<LaserJock> the "wheel" isn't spinning or anything
<rockstar> Yea, bzr does have issues with demonstrating it's actually doing something.
<enigma42> jelmer: Does "bzr svn-upgrade" move everything to revprops if possible?
<jelmer> enigma42, nope. There is a svn-set-revprops command that intends to do that, but it's hidden, experimental and doesn't have a testsuite yet.
<enigma42> OK.
<enigma42> Yeah, it will be nice to retrofit my svn repos to only use revprops.
<jelmer> enigma42,  bzr-svn will at least only use revprops for new revisions
<enigma42> Ignore some of that crufty data stuck in file properties.
<enigma42> jelmer: New error
<enigma42> jelmer: bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0xa41c8ac> has delta references to items not in its repository:
<jelmer> :-( Please pastebin
<enigma42> OK
<enigma42> jelmer: Oh...the branching worked great, BTW.
<enigma42> This was after branching from SVN was over.
<jelmer> ah, this is running "bzr check" ?
<enigma42> I did a local branch.
<enigma42> bzr branch svn-branch local-branch
<enigma42> specifically: bzr branch des-dw-harmony foobar
<enigma42> http://pastebin.ubuntu.com/108822/
<enigma42> My coworker tells me he's been seeing this error since he upgraded to bzr-svn 0.4.17 on Monday.
<enigma42> Actually...correction.
<enigma42> (03:24:58 PM) hughesw: monday. after updating to bzr 1.10 and bzr-svn 0.4.16 from the package on the bazaar site.
<enigma42> bzr-svn 0.4.16
<hughesw> yeah...
<hughesw> there's some revisions from a local branch that don't seem to have been pushed up to the repository
<hughesw> I can see the hughesw@hughesws2k8-20090121211631-kx8io79zatxfxjhc commit ID in my local trunk on my work machine, but it's not in the repository.
<jelmer> enigma42, what happens if you run "bzr check" in the original branch?
<hughesw> jelmer: when I did that with 0.4.16 it crashed on me.
<jelmer> hughesw, with what error?
<hughesw> let me check again
<jelmer> similar to the one pasted above?
<hughesw> sorry, the error's on a different machine, reproducing it here real fast.
<enigma42> jelmer: ...still running bzr check...
<enigma42> jelmer: see privmsg
<enigma42> This concerns me:
<enigma42>     20 ghost revisions
<enigma42>     20 revisions missing parents in ancestry
<enigma42>     12 inconsistent parents
<jelmer> ghost revisions are not necessarily bad, they are just revisions to which there are references but that are not present in the repository
<hughesw> check crashed on me again
<hughesw> I privmsg'd you jelmer
<jelmer> hughesw, thanks
<hughesw> it also crashes on 0.4.17 with the same message
<enigma42> jelmer: Oh...fwiw: I'm on bzr 1.11 with bleeding edge 0.5
<hughesw> since I updated to that with my home machine after it died the first time
<jelmer> lifeless, ping
<hayalci> Hi, I think it would be great if bazaar web page stated bazaar hosting options, like launchpad and savannah.
<hayalci> That info is presented nicely on git web site and it probably makes an impact
<Peng_> jelmer: FWIW, the repo from my old bzr-svn import said there was one ghost. The new one says there are no ghosts, but 158 inconsistent parents. :)
<Peng_> Inconsistent parents should not be created anymore, should they?
<lifeless> jelmer: jo
<jelmer> lifeless, in this error: http://pastebin.ubuntu.com/108822/
<jelmer> what are the "delta references" ? The delta parents ?
<jelmer> hi, btw :-)
<lifeless> they are basis texts for delta compression
<jelmer> so how can that error occur if that branch was created by just calling VF.add_lines() ?
<lifeless> should be impossible
<lifeless> unless its stacked; there was a bug in stacking at one point
<lifeless> could be a bug in the checking code I guess if it is checkin graph not delta fields
<jelmer> yeah, that's what I'm wondering
<jelmer> since the text revisions there are from a ghost revision
<jelmer> but the texts are actually there
<jfroy> how does one setup a remote branch so people that bzr send to it will get an email automagically?
<jfroy> I thought it would be enough to have an email setting in a properly configured localtions.conf section, but apparently not.
<jfroy> Ok, the setting in questionis child_submit_to
<jfroy> Doesn't seem to be a way to bulk set it on a group (or directory) of branches :|
<mikey_p> got a question about the internal workings of bzr+ssh, how does the directory to serve get passed to the remote machine?
<mikey_p> i.e. if I do bzr branch bzr+ssh://hostname/path/to/file all that gets passed to remote server as an ssh command is "bzr serve --inet --directory=/ --allow-writes"
<mikey_p> how does path/to/file get passed to the remote machine?
<fullermd> Over stdin after the server starts up.
<mikey_p> fullermd: then why the empty directory arg at startup?
<fullermd> Because serv takes an arg describing how high in the tree it's allowed to go.
<dereine> is there a tutorial how to use bazaar for web development automatic update of the checkout on a test server, which has only ftp acess
<AfC> dereine: not sure you need a tutorial for that. Just try doing it. Should work. You _might_ find the bzr-upload plugin of value.
<fullermd> Oh, there's training involved.  It takes some practice to get just the right angle for yanking out the fingernails of whoever setup a server with only FTP access.
<etenil> Hi there
<etenil> I'm used to subversion and just switched to bazaar
<etenil> I usually stored the stable releases of my projects as tags in the subversion directory, but I don't find the equivalent in bzr
<Peng_> "bzr tag"?
<etenil> really?
<etenil> I didn't see that in the doc
<Peng_> Bazaar supports tags, but they aren't implemented as directory copies as in Subversion.
<etenil> Oooooohhhh
<etenil> I've got the one paragraph
<etenil> seems I overlooked it ^^
<etenil> thanks a lot Peng_
<Peng_> :)
<etenil> er, that's a big documentation, for once I can't complain ;)
<jelmer> jfroy, child_submit_to is what you're looking for
<etenil> is it possible to fix a bug in a tag too
<Peng_> etenil: What? You can tag any revision you want to?
<etenil> I mean, if I make a stable release and then work on the next one. If I make a security fix on the stable one (tagged), how should I proceed then?
<etenil> if I commit the fixed old one, it's gonna interfere with the development of the new version.
<Peng_> "bzr branch -r tag:foo-1.2.3 foo.dev fix-vuln; cd fix-vuln; hackhack; bzr commit; bzr tag foo-1.2.3.1; cd ../foo.dev; bzr merge ../fix-vuln", maybe?
<etenil> thx peng_
<etenil> i'll have a further look.
<kfogel> I'm having a conversation with a GNU/Savannah admin over at https://savannah.gnu.org/support/index.php?106612, about converting the Emacs project over from CVS to bzr (which Emacs has decided to do, but hasn't actually done yet).  The admin says: "Given that bzr works on top of sftp, what's the point in having bzr even installed at Savannah?"
<Peng_> kfogel: To make it faster?
<LarstiQ> kfogel: administration and speed
<kfogel> I'm kind of new to bzr, so I'm not sure I understand that.  Does he mean that bzr clients can upload bundles (or something?) via sftp, and there need be NO bzr running on the server end?
<kfogel> Peng_, LarstiQ: thank you.  So one *can* do it the way he says, but it's inefficient?
<Peng_> kfogel: Sure, using plain old SFTP as the server works perfectly; it's just not as fast.
<kfogel> what kind of speed difference are we talking about?
<Peng_> I don't know. A lot of operations still don't take advantage of the smart server, making them almost as slow as SFTP.
<LarstiQ> kfogel: it varies with what exactly you are trying to do. But 'dumb' transports like sftp are used with only vfs operations like open(), stat(), read() and write(), on a .bzr level
<LarstiQ> kfogel: whereas with bzr on the server (bzr+ssh or as a daemon) you can do things like 'Branch.last_revision_info'
<kfogel> So there's a feature difference too?
<Peng_> kfogel: No.
<LarstiQ> well
<LarstiQ> there is, but not on this level
<LarstiQ> kfogel: I personally use sftp a lot.
<kfogel> Uh.
<kfogel> Would you ever recommend the sftp method for people who are *not* (and are not going to be) bzr experts?
<kfogel> :-)
<LarstiQ> kfogel: the main feature difference is that you can not run server side hooks with sftp, but you can when bzr is on the server
<Peng_> kfogel: It's faster to have the server read the files and send back the data you want than for the client to read the files over the Internet, even if the same information can be obtained either way.
<kfogel> I'm not referring to myself, but to the Savannah admins.
<kfogel> Peng_: makes perfect sense -- thanks.
<kfogel> LarstiQ: okay, good to know.  We do, in fact, need to run server-side hooks.
<kfogel> So sftp-only is a non-starter.
<LarstiQ> kfogel: my advice to the Savannah admin would indeed be to offer more than sftp-only, even though I get the 'no work for me' appeal as a sysadmin ;)
<kfogel> heh, sure :-)
<LarstiQ> kfogel: git afaik, but hg certainly, can also use dumb transports. But the users will lynch you if you are not running the daemon, since it is utterly slow otherwise.
<LarstiQ> kfogel: if he needs help btw, I'm willing to offer it
<kfogel> I seriously wonder why the tools even offer these options.  It's not worth the confusion to non-expert users.
<kfogel> LarstiQ: wow, thank you
<Peng_> LarstiQ: AFAIK, hg only supports dumb HTTP, not SFTP.
<Peng_> And the HTTP is probably read-only.
<LarstiQ> kfogel: you'd be surprised at the amount of users that only have an FTP server available to them :/
<kfogel> LarstiQ: if you are really interested (and this may mean a serious commitment), privmsg me your email addr and I'll make sure the Savannah admins have it.
<LarstiQ> kfogel: how serious a commitment?
 * LarstiQ does already have a fulltime job
<kfogel> LarstiQ: I don't know, really.  Maybe I'm being overly dramatic -- possibly Savannah just needs someone they can consult.
<Peng_> LarstiQ: The goons with black ski masks are already on their way to kidnap you. ;)
<LarstiQ> Peng_: hah! :P
<kfogel> LarstiQ: anyway, as a volunteer, you don't need to do more than you have time for, obviously.  So it's up to you!
<LarstiQ> kfogel: any irc channel I could hang out in?
<kfogel> LarstiQ: most of the activity is on the emacs-devel@gnu.org mailing list and on that bug ticket I referred to earlier.  The ticket has mail links.
<LarstiQ> ok
<LarstiQ> kfogel: I see the admin would also like a loggerhead init script
<Peng_> There is a Loggerhead init script.
<LarstiQ> Peng_: afaik that does not use server-branches?
<kfogel> LarstiQ: I'm about to let him know that you're offering some help.
<LarstiQ> kfogel: and I'm happy to see it's Debian based, I'll feel right at home ;)
<Peng_> It uses serve-branches.
 * LarstiQ tries the last attempt at fixing the router
<jelmer> Peng_, It doesn't abide by the Debian/Ubuntu policy though, so I ship a different one in the Debian package
<Peng_> jelmer: Oh? What's wrong with it?
 * jelmer looks for the list of problems he sent earlier
<jelmer> Peng_, Doesn't use start-stop-daemon but sudo, doesn't use the pidfile but greps through the process list (potentially killing user-started loggerhead processes), doesn't use /etc/default/loggerheadd but requires configuration in /etc/init.d/loggerheadd, init script blocks, assumes that if something is running on the configured loggerhead port it is loggerhead, ...
<Peng_> Heh.
<Peng_> Oh, your script uses start-loggerhead though.
<Lo-lan-do> I may have missed some context, but there's a branch with a mostly correct (if crude) initsript at http://bzr.debian.org/loggerhead/users/lolando/loggerhead/daemonise
<Peng_> Ergh, *another* one?
<Peng_> Someone needs to throw all of the Loggerhead init scripts in a blender and make a perfect one. :D
<jelmer> Peng_, Well, basically the equivalent of the Debian one that uses serve-branches instead of start-loggerhead
<jelmer> Lo-lan-do, I hope to merge yours once start-loggerhead is removed upstream and serve-branches has its own configuration file
<Peng_> Oh, ok.
<LarstiQ> so now we need someone to act as upstream.
<jelmer> beuno, IIUC this is what upstream intends to do
 * jelmer wonders if beuno is around
<beuno> jelmer, I'm really *not* here
<beuno> but
<beuno> serve-branches will have a config file soon
<beuno> and we will kill start-lh for evar
<jelmer> \o/
<beuno> and merge whatever you guys thing is the best deamonizer
 * Lo-lan-do cheers
<beuno> now, back to not being here...
<Lo-lan-do> This is not the beuno you are looking for.
<beuno> :)
<fullermd> We're all right there not with you on that!
<dereine> how can i pull and overwrite to the current state at a remote branch?
<jelmer> dereine, bzr pull --overwrite
<dereine> thx
<LarstiQ> jelmer: could pkg-bazaar-maint receive less spam maybe?
<jelmer> LarstiQ, how?
<jelmer> I'm all for it :-)
<LarstiQ> jelmer: disallowing non-subscribed posters?
<LarstiQ> or does that raise the bar unacceptably for drive by contributions
<LarstiQ> or maybe the spammers are already subscribing?
<jelmer> LarstiQ, yeah, that may be a good idea
<Goosey> hello. I am looking to use a DVCS as a local tool in an SVN environment, for ramping local changes/branches prior to SVN committing them. I am on windowsXP. Bazaar's good svn support and windows packages led me to give it a try, but I am having some issues.
<Goosey> If I do any local commits and then pull commits from the SVN repo, when I try to push I cannot and am advised to rebase
<Goosey> I installed the rebase plugin, but using it says there are no changes to rebase.
<Goosey> So I am a bit confused to what I am doing wronge or where to go next. :)
<Lo-lan-do> When you do local commits, you shouldn't normally be able to pull from SVN.  Did you mean you merged from SVN instead?
<Goosey> No, I mean 'bzr pull'
<Lo-lan-do> Maybe I'm missing something, but I think you can't pull when there have been commits both locally and remotely since the last common ancestor.
<Goosey> i am sorry, you are right. 'bzr pull' warns the branches have diverged, so i use 'bzr merge' to pull the changes in
<Goosey> and then a 'bzr commit' to commit the merge results
<Goosey> and finally 'bzr push' to the svn repo, which is where I get the 'please rebase' error
<Lo-lan-do> I see.  I don't know exactly how to fix that, but you may consider using another workflow that seems to work for me.
<Goosey> ok, which workflow do you use?
<Lo-lan-do> I have a bzr branch bound to svn, and other "floating" bzr branches based on it.
<Lo-lan-do> When I need to push stuff from a local branch to SVN, I merge that branch into the svn-bound branch and commit.
<Lo-lan-do> I do bzr update from time to time in the svn-bound branch to bring it up-to-date with what's in svn, and push or merge into the others according to the situation.
<Goosey> hmm i gave this setup a try but ran into the same issue, Lo-lan-do
<Lo-lan-do> Then I'm afraid I'm not enough of a bzr guru to be of significant help :-/
<Goosey> I did a SVNRepo bound branch 'A' and branched from that 'B'. Then I made some local commits into B, made some SVN repo commits from elsewhere, pulled those into A, merged those into B, and commited B, and on pushing B the error :/
<Goosey> am I missing a subtlety of how your workflow works?
<Lo-lan-do> Try merging B into A (or pulling) instead of pushing maybe.
<Goosey> ok that worked
<Goosey> iiiinteresting
<Lo-lan-do> I'll leave you with the wizards for the explanation, but in the meantime at least you can commit :-)
 * Lo-lan-do â sleep
<Goosey> enjoy sleep :_)
<cody-somerville> Hey
<cody-somerville> I can't install bzrtools from the bzr ppa
<cody-somerville> bzrtools: Depends: bzr (< 1.11~) but 1.11-1~bazaar1~hardy1 is to be installed
#bzr 2009-01-25
<graypoodle> hi, I am new to bzr. I have done init, add and commit. Now I am not able to push to launchpad. I am getting a whole lot of errors and finally a line asking me to mail to bazaar-ng@lists.ubuntu.com
<graypoodle> here's the pastebin http://dpaste.com/112651/
<Peng_> graypoodle: You're running a horribly ancient version of Bazaar. Upgrade.
<Peng_> graypoodle: I believe that specific bug has been fixed, too.
<Peng_> Though I doubt 0.11 is new enough to work with bzr+ssh://bazaar.launchpad.net even if it weren't for that bug.
<graypoodle> Peng it is 0.11-1.1 on debian. Then i guess the repo is outdated.
<Peng_> Yes, it is.
<Peng_> It's Debian; is that surprising? :P
<graypoodle> oh ok. i guess i will have to download the deb then.
<graypoodle> Peng_ 1.5-1~bpo40+1  is new enough
<graypoodle> ?
<Peng_> Well, it's a heck of a lot new*er*, but 1.11 is the latest.
<Peng_> I'm sure 1.5 would be fine on Launchpad, unless stacking gets involved somehow.
<graypoodle> whats stacking, if it is not too stupid to ask.
<Peng_> Ehh. A feature added in 1.6. :P
<graypoodle> aah. ok. thanks a lot Peng_ i am installing the deb now.
 * Peng_ is bad at describing things.
<graypoodle> oh darn. just find out that python 2.5 is required but i have 2.4
<Peng_> Bazaar supports 2.4 fine; if it requires 2.5, that's a problem with the deb.
<graypoodle> Peng_ installer complained while it gave an error about python-celementtree not being installed. Once I installed that, bazaar installed anyway. 2.5 was just a warning i guess.
<graypoodle> thanks a ton for the help. it works now.
<derekS> hi guys. quick question. is there any plans for subdirectory checkout/clone (like in svn)?
<jelmer> derekS, yes, there are plans for partial checkouts
<derekS> jelmer: nice! do we have an eta?
<jelmer> derekS, no idea
<derekS> another question. if i were to modify my local branch, and then do a pull from a remote branch, what happens exactly?
<jelmer> derekS, if you don't commit your local changes, bzr will merge in the remote changes
<jelmer> if you do commit, you'll get a diverged branches error
<derekS> jelmer: so it wouldn't be smart to make a cronjob to do the pull?
<jelmer> derekS: if you're also going to be working in that working tree, probably not
<abadger1999> I don't want to mess something up so will handle this situation:
<abadger1999> #cherrypick a merge
<abadger1999> cd bar
<abadger1999> bzr merge ../foo -r81..82
<abadger1999> do other work in both foo and bar branches.. making new commits.
<abadger1999> then merge the rest of the changes:
<abadger1999> cd bar; bzr merge ../foo
<abadger1999> Will that work out? Or can the cherrypicked merge cause conflicts if the files have been edited some more?
<graydog> i am trying to setup a script in init.d so that bzr server starts up on boot time. I know how to start the server. how do i stop it?
<spiv> graydog: SIGTERM :)
<graydog> spiv: hmmm. isn't there an option at the bzr server command line?
<spiv> graydog: no, but bzr doesn't have any daemonisation builtin either
<spiv> (although I'd like to implement that at some point)
<graydog> spiv: aah.
<graydog> spiv: so how is it run as  a server?
<spiv> graydog: so what ever you use to daemonise the server process ought to provide a way to terminate the process, or at least find its pid.
<spiv> Debian has a start-stop-daemon helper that can do that for you, IIRC.
<graydog> spiv: well i guess pkill will do for now. or the helper.
<graydog> thanks
<spiv> You're welcome.
<dereine> how can i checkout from a repo and overwrite all stuff that changed
<spiv> dereine: pull --overwrite, perhaps
<dereine> mh this didn't worked
<dereine> i had to revert to a specific revision
<dereine> i want to do the same as cvs update -C
<LarstiQ> Do you mean, you want to become an exact mirror of the branch you're pulling from, throwing away local uncommitted changes?
<spiv> pull needs a branch, rather than a checkout.  I'm not sure there's a way to make a checkout become a checkout of an earlier revision.
<LarstiQ> (that would be `bzr revert`)
<spiv> You can always use "bzr revert -r ..." to revert all or part of a working tree to a different revision, though.
<LarstiQ> dereine: I haven't used cvs in anger for over half a decade, so I'm a bit foggy on what update -C does :)
<dereine> spiv: thx
<dereine> spiv: i tryed bzr revert -r ... and this came back
<dereine> bzr: ERROR: No namespace registered for string: u'.'
<spiv> dereine: the "..." is meant to be filled in by you :)
<spiv> dereine: or maybe you just want plain "bzr revert"?  Either way, take a look at "bzr revert --help"
<dereine> spiv: revert to the current revision on the remote server
<spiv> Well, there's two different matters there, from bzr's perspective; "bzr revert" to undo any local uncommitted changes, then "bzr update" to update your checkout to be current with its master branch.
<spiv> (Assuming you have a checkout and not a branch; if you have a branch then you'll need to pull rather than update.)
<dereine> spiv: i have to learn allot
<dereine> what is the difference between a checkout and a branch
<garyvdm> A checkout does not have a copy of the repository.
<LarstiQ> garyvdm: ehm, no
<garyvdm> No?
<fullermd> A checkout is just a working tree on a branch.
<LarstiQ> garyvdm: you're thinking of a lightweight checkout
<spiv> dereine: http://bazaar-vcs.org/Checkout and http://bazaar-vcs.org/Branch are a bit verbose but say it better than I can at this time of night :)
<garyvdm> LarstiQ - oh
<LarstiQ> garyvdm: or the the bzrlib concept, as fullermd seems to do.
<LarstiQ> dereine: a checkout gives you the centralized workflow (commit goes directly to the master branch), a branch the decentralized one, where commiting and publishing a revision are decoupled.
 * fullermd certainly doesn't think in bzrlib...
<LarstiQ> dereine: you can convert the one into the other and vice versa.
<LarstiQ> fullermd: I've seen you submit patches ;P
<fullermd> Yeah, did you notice how they were rejected for knowing nothing about bzrlib?   :p
<LarstiQ> fullermd: I chose to ignore that for the sake of this argument ;)
<garyvdm> LarstiQ - so is you branch x y, cd y, bind x - then you have a checkout?
<garyvdm> s/is/if
<LarstiQ> garyvdm: yes
<LarstiQ> garyvdm: and bzr co x y; cd y; bzr unbind; gives you a branch
 * garyvdm has been using checkout with out even knowing....
<LarstiQ> or well, standalone or repository branch, not a bzrlib.branch.Branch
<spiv> dereine: the short answer is that if you used "bzr checkout" (or its alias, "bzr co"), you have a checkout, and if you used "bzr branch", you have a branch.
<spiv> dereine: (assuming you haven't used something like "bzr reconfigure" on the checkout/branch later)
<dereine> no sure
<dereine> i want to revert stuff i have done
<dereine> but revert to the state on a server
<spiv> Btw, "bzr info" can tell you what kind of thing you have (e.g. a "standalone branch")
<LarstiQ> dereine: does 'stuff i have done' include commits, or only uncommitted changes?
<dereine> both
<spiv> Uncommitted changes are easy; bzr revert.  If you have commits then I guess you have a branch, so you'll also need to do a "bzr pull --overwrite"
<aldolat> hi! I have a bzr lock on launchpad and I am unable to break it. can you help me?
<garyvdm> aldolat: Was the lock created by you are someone else?
<aldolat> by me
<garyvdm> What is the branch?
<aldolat> wait...
<aldolat> ~ubuntu-it-magazine/fcm-it/edizione-fcm-it/.bzr/branch/lock
<aldolat> https://code.launchpad.net/~ubuntu-it-magazine/fcm-it/edizione-fcm-it
<garyvdm> I think there is a bug with breaklock/lp when you specify a lock with breaklock
<garyvdm> Try breaklock branch
<aldolat> bzr breaklock branch ?
<garyvdm> yes
<aldolat> tried... nothing happened
<aldolat> try now to push
<LarstiQ> aldolat: what url do you give to break-lcok?
<aldolat> i tried the url bzr gave me...
<aldolat> but does not recognize it
<aldolat> wait a moment
<aldolat> it says
<aldolat> bzr: ERROR: Unsupported protocol for url "lp-46726096:///~ubuntu-it-magazine/fcm-it/edizione-fcm-it/.bzr/branch/lock"
<aldolat> bzr gives me that url but it does not recognize it
<aldolat> o_O
<garyvdm> What I was trying to say - is that you need to just specify the name of the branch - not the name of the lock that bzr reports
<garyvdm> e.g bzr breaklock lp:~ubuntu-it-magazine/fcm-it/edizione-fcm-it/
<LarstiQ> aldolat: remove the -42..
<LarstiQ> what garyvdm says
<aldolat> trying...
<aldolat> well, it's going :D
<aldolat> thank you, masters!
<garyvdm> bzrtool 1.11 still not in the ppa :-(
<garyvdm> *bzrtools
<aldolat> "Pushed up to revision 287."... thanks garyvdm and LarstiQ :D
<aldolat> going out...
<Peng_> Was that URL bug fixed?
<duckx> hy
<duckx> I was wondering was the current state of Foreign Branches ...
<duckx> I tried to checkout an SVN tree with bzr ... and well it misses the external references ...
<LarstiQ> that's more to do with lacking nested trees support in bzr than with bzr-svn
<LarstiQ> duckx: as a workaround you could use scmproj or config-manager
<duckx> Thx LarstiQ , I will have a look to config-manager ... but anyhow, it is a bit anoying to have to setup an extra thing to checkout a project ;)
<duckx> LarstiQ: is it an short time / long time goal to have it supported natively ?
<LarstiQ> duckx: loooong term
<duckx> -> it is a feature I want/like to have for a long time .. ;)
<LarstiQ> duckx: exactly
<LarstiQ> duckx: lp:~larstiq/bzr/nested-trees has not been progressing for a long term
<duckx> LarstiQ: it really blocking for big projects that deals with a lot of libraries
<LarstiQ> duckx: it would be very nice to have
<LarstiQ> s/term/time/
<garyvdm> Peng_: I'm not sure if it is logged as a bug? There is a question: https://answers.launchpad.net/launchpad/+question/35522
<duckx> LarstiQ: too bad ...
<duckx> I tried to manage an horde framework with bzr, and currently it can't be managed natively with bzr .... well the way I would like it to be managed ;)
<LarstiQ> duckx: now, if you're willing to help, I'd welcome that :)
<duckx> LarstiQ: I feel not good enough, to go deep in the bzr thing ... ;(
<duckx> I am an happy end user thought ...
<duckx> LarstiQ: ... but it is really blocker in on workflow ...
<duckx> Decentralizaition of svn trees ...
<duckx> Well, in a way I would like to just co an svn tree, do a few hacks, and submit them to the relevant project
<duckx> Only works half of the time currently due to the lack of external referencies support ;(
<duckx> I will probably make a post about it on the mailing list ...
<duckx> As I think it is blocker for many projects to migrate from an SVN tree to bzr ...
<LarstiQ> duckx: you can help in different ways, don't have to do the actual coding
<duckx> Is there a todo list around ?
<duckx> I feel like a happy hacker sometime, even thought the responsiveness of open source project is sometime really slow ;)
<LarstiQ> duckx: what is there is outdated I'm afraid.
<duckx> Ok, well, I will continue to read the mailing list ... May be something will inspire me one day ;)
<duckx> But currently i am on a few things ...
 * LarstiQ nods
<duckx> Getting synchronisation working with libsyncml on my samsung phone
<duckx> Getting UPNP working in pidgin ... well it currently sucks as hell ;)
<duckx> And for this I need a good VCS ;) i still think bzr is the one ..
<duckx> Well lets have a look @ config-manager ...
<LarstiQ> duckx: scmproj is more recent
 * duckx on co scmproj
<duckx> Any debian package around ?
<duckx> Thx for your help LarstiQ
<LarstiQ> duckx: hmm, don't think so
<duckx> ;)
<LarstiQ> (about scmproj debian packages)
<graydog> hi, i started bzr serevr with write acess and am pushing about 1 gb of files to it from a client. The server bzr process is running with 99.9% cpu load and the client gets stuck. ^c gives the output Cbzr: A nested progress bar was not 'finished' correctly. The files still seem to be uploading as df -h on the server shows the size increasing slowly.
<graydog> I am using bazaar v1.5 on the server. could that be the problem?
<jelmer> graydog, Yeah, I would suspect that to be fixed in newer versions
<graydog> jelmer: thanks
<Lo-lan-do> Is there a way to replicate a repository (or a set of branches) in one bzr command?
<MattCampbell> The bzr PPA for intrepid seems broken; it includes bzrtools 1.10 (which depends on bzr < 1.11) but also bzr 1.11.
<jelmer> Lo-lan-do, I think several people have tried to create plugins for that
<MattCampbell> So for now I'm installing bzr without bzrtools though aptitude gave this solution a negative score.
<Lo-lan-do> jelmer: I'll take that as a "no" then :-)
<thumper> Lo-lan-do: bzr init-repo creates a repository
<thumper> Lo-lan-do: not sure if that is what you are asking for
<thumper> Lo-lan-do: what type of set of branches are you wanting to create?
<Lo-lan-do> thumper: The question is how to fetch several (or all) branches from a remote repo into mine, in one command if possible.
<Lo-lan-do> I could of course loop over $(bzr branches), but I find it lacks elegance.
<Jc2k> Lo-lan-do: i wonder how hard it would be to adapt multi-pull...
<LarstiQ> Lo-lan-do: or scmproj maybe?
 * LarstiQ confesses he hasn't looked closely at scmproj yet
<gioele> what is the bzr repo for the 1.11 branch of bzrtools? shoud I use lp:bzrtools?
<thumper> gioele: it appears that the 1.11 branch of bzrtools isn't available
 * thumper pokes statik
<gioele> thumper: but it has been released as tar.gz http://launchpad.net/bzrtools/stable/1.11.0/+download/bzrtools-1.11.0.tar.gz
<thumper> gioele: yeah, but the packaging is dones by someone else
<gioele> I see
<gioele> it is a bit strange that bzrtools makes such a "messy" use of bzr and launchpad 8)
<fullermd> bzrtools isn't branched AFAIK...
<thumper> are there some docs somewhere that talk about bzr's use of http proxies?
<spiv> thumper: there's some mention in http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#authentication-settings relating to authentication bits.
<thumper> spiv: ta
<thumper> spiv: you back at work now?
<spiv> thumper: there probably should be more...
<spiv> Yep.
<thumper> spiv: how does bzr know to use the [proxy] section?
<spiv> I have no idea, unfortunately.
<spiv> Hmm, the top of the Authenication Settings explains, I think.
<spiv> It matches on whatever bits of the URL you specify, e.g. host, port.
<spiv> If you don't need auth, then I assume just setting $http_proxy in your environment would work too.
<spiv> Hmm, my laptop has started to lock up for no reason.
<spiv> I guess my laptop would rather still be in Hobart...
#bzr 2010-01-25
<keithy_> hmm I wont to install config manager on my laptop but I dont have gcc/develper tools loaded
<keithy_> want*
<timClicks> am attempting bzr pull --overwrite and am receiving
<timClicks> bzr: ERROR: Cannot lock LockDir(lp-64843152:///~flavour/sahana/sahanapy-trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<timClicks> is there anything I can do on my end? it looks like something to do with launchpad
<fullermd> DDTT(tm).
<fullermd> You're doing that in a checkout of the branch on LP, to which you don't have write access, so writing to it fails.
<versatiletech> I'm having issues with getting my linux user permissions right for someone on the outside to bzr push bzr+ssh:// in? Can someone point me to the right direction?
<fullermd> Well, what's wrong with 'em?
<fullermd> They need write into the branch, and its respository.
<versatiletech> hmm
<mkanat> In pre_change_branch_tip, what's the right way to get the email address of the committer? By parsing new_revid, or is there some better way?
<versatiletech> fullermd: I guess the ssh user needs to be in the same group as the bzr folder's group correct?
<fullermd> Well, that's one way to do it.  Another would be with world permissions.  Another possibility would be stepping outside the normal *nix permission system with some sort of ACL, if your system supports that.
<fullermd> But group is the normal solution, yes.
<versatiletech> right now the .bzr's group is proftp
<versatiletech> does the user's primary group need to be proftp?
<versatiletech> or can there secondary group be proftp?
<fullermd> No, they just need to be in it.
<versatiletech> cool
<versatiletech> let me try that
<fullermd> If you're on a system with SysV filesystem semantics, you probably want g+s on some of the directories.
<keithy_> is there a way to checkout such that you get just the files no scm behavuior
<keithy_> i.e checkout --lightweight
<keithy_> but more a deploy
<fullermd> You mean like export?
<fullermd> (of course, with no scm behavior, you can't do things like "update" either)
<MTecknology> bzr: ERROR: KnitPackRepository('lp-64843152:///~scripters/scripting/trunk/.bzr/repository')
<MTecknology> is not compatible with CHKInventoryRepository('lp-64843152:///~mtecknology/scripting/server-scripts/.bzr/repository')
<MTecknology> That's odd.. any ideas?
<fullermd> One side is a pack-0.92 or the like, the other is 2a.
<fullermd> Specifically, yours is 2a, and you're trying to move revs from that into the ~scripters one which isn't possible.
<MTecknology> fullermd: any way to make that work?
<fullermd> No.  Rich-root revs aren't compatible with poor-root repos.
<fullermd> So your choices are (a) Upgrade the far side, or (b) Redo changes in a poor repo.
<MTecknology> fullermd: I'm trying to push to a branch that doesn't exist
<versatiletech> assuming I do bzr remove MYCONFIGFILE.ext --keep, then bzr commit && bzr push-and-update. If someone else does a bzr pull, will their MYCONFIGGILE.ext be erased?
<fullermd> Mmm.  The error could be coming from trying to stack, I guess.
<fullermd> versatiletech: Yes.
<versatiletech> ouch
<versatiletech> any other options?
<fullermd> Not in-bzr, no.  A file's either extant in a rev or not.
<versatiletech> I guess what I could do is tell everyone to backup their MYCONFIGFILE.ext, then I bzr remove MYCONFIGFILE.ext --keep from the central repo. Then bzr ignore MYCONFIGFILE.ext.
<versatiletech> are bzr ignore's local?
<versatiletech> or if somebody bzr pull's they'll get the new ignore that was committed to the central repo?
<fullermd> Depends on whther the ignore file is versioned.
<versatiletech> k
<fullermd> Which it presumably is, if you're using the 'bzr ignore' command.
<wgrant> (by default it is)
<versatiletech> yeah I noticed that I couldn't ignore a versioned files
<versatiletech> file*
<versatiletech> Warning: the following files are version controlled and match your ignore pattern:
<versatiletech> application/config/database.php
<versatiletech> These files will continue to be version controlled unless you 'bzr remove' them.
<fullermd> Oh, you can put it in just fine.
<fullermd> bzr ignore just warns because the command doesn't DO anything.
<versatiletech> so basically it doesn't truly ignore the file unless I do bzr remove
<versatiletech> in other words if I make a change to database.php after doing bzr ignore to it, it will still be committed since it's versioned
<fullermd> The only thing that 'ignored' means is that 'add' won't add it when it walks across it, and 'status' won't show it as 'unknown'.
<fullermd> It doesn't affect anything else.
<versatiletech> ah
<versatiletech> k I got it now
<MTecknology> fullermd: any idea about this? http://paste.ubuntu.com/362361/
<MTecknology> 2 servers give me that; 2 servers work correctly
<fullermd> It means you don't have your public key setup right.
<MTecknology> none of the root users on any server have ssh keys published to launchpad
<MTecknology> I only want them to pull down the content - should need authentication..
<fullermd> If they've been lp-login'd, they'll always need authentication.
<MTecknology> I didn't think I did.. if they did how can I undo that?
<MTecknology> there's no /root/.bzr*
<fullermd> Going through sudo and using your original user's ~?
<MTecknology> OOPS
<MTecknology> fullermd: thanks :D
 * fullermd is a cheenius   8-}
<MTecknology> ya, you are
<ChrisMorgan> I've got bzr-gtk installed on my Ubuntu system but Nautilus integration isn't happening; the emblems are available but overlaying of files isn't happening.
<ChrisMorgan> Any idea why or what I should do to get it working?
<johnf> has 2.0.4 not hit pqm?
<fullermd> PQM committed "Release 2.0.4 final" on Thursday...
<johnf> my bad. Wasn't looking at the 2.0 branch
<poolie> hello all
<poolie> igc, hi?
<james_w> good morning sprinters
<poolie> hello james_w
<poolie> are you home now?
<james_w> no, I'm still in NZ
<hydratenaturally> i did something stupid...
<ChrisMorgan> Does anyone know how I can get nautilus integration via bzr-gtk working?
<hydratenaturally> using a hosted svn solution, i checked out the repo using bzr-svn, made some bzr --local committ's, went to make a big upstream committ, and when i did a bzr update it removed all my locally committed changes
<ChrisMorgan> hydratenaturally: I think that's one of the times for that famous saying, "Whoops."
<hydratenaturally> yeah...
<hydratenaturally> well, i'm just lacking the knowledge of bzr to go back and find my locally comitted changes
<hydratenaturally> i imagine a few commands here and there saves my life
<hydratenaturally> using debian or ubuntu by chance chris ? https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/287988
<ubottu> Ubuntu bug 287988 in bzr-gtk "Bzr Nautilus integration (Tortoise like)" [Undecided,Fix released]
<fullermd> Update didn't remove your locally committed changes, it pivoted them to be a pending merge.
<hydratenaturally> mm ok
<hydratenaturally> sigh so where is this pending merge
<fullermd> Check status.
<ChrisMorgan> hydratenaturally: ubuntu, amd64
<hydratenaturally> status says nothing
<fullermd> Then you did a revert or some such since the update.
<ChrisMorgan> hydratenaturally: the thing is it's not working.  It's meant to be in there (they've even got screenshots of it) but the emblems are not being overlaid as they should
<ChrisMorgan> hydratenaturally: `bzr log`?
<fullermd> Log by itself won't help after the pivot, the revs aren't in that branch's history anymore.
<ChrisMorgan> You may want just the last N revisions though, add -l20 for the last 20
<hydratenaturally> ugh i promise i didn't revert, here is a log of what happened http://pastie.org/793276
<ChrisMorgan> Ooh, another chris!  ;-)
<hydratenaturally> yeah, is there a way of reviewing only your --local committ's ?
<fullermd> Well, then either (a) there weren't any local commits in that branch, or (b) some weird bug exists hidden in bzr that nobody else has ever seen.
 * fullermd isn't better on (b).
<fullermd> Or betting, either.
<fullermd> You can use 'heads' (in bzrtools) to see if there are any dead heads in the repo.  Lost local commits would show up there.
<hydratenaturally> history | grep ci | grep local shows me making local committs, i maybe dellusional...
<fullermd> Or you may be making them in different checkouts.
<hydratenaturally> checked that
<hydratenaturally> heads doesn't say much, just something about my last upstream committ
<fullermd> You probably need heads --dead-only
<fullermd> I don't think it lists dead heads by default.
<hydratenaturally> still nothing
<fullermd> Is the repo shared with other branches/checkouts?
<hydratenaturally> nah, very vanilla
<hydratenaturally> remotely hosted on beanstalk
<hydratenaturally> did initial import with svn
<fullermd> Not the svn repo, your local bzr repo.
<hydratenaturally> nope
<hydratenaturally> no local branching or checkouts
<fullermd> Then there aren't any commits in the repo that aren't in the history in svn.
<hydratenaturally> bzr log shows none
<hydratenaturally> actually they're off by 1
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: (volunteers wanted?) | bzr 2.1.0rc1 and 2.0.4 have gone gold
<ChrisMorgan> Well, I got bzr/nautilus integration working.  sudo ln -s /usr/share/pyshared/bzrlib/plugins/gtk/nautilus-bzr.py /usr/lib/nautilus/extensions-2.0/python/ and then restart nautilus
<hydratenaturally> man this sucks....
<hydratenaturally> um where does bzr store committs with --local ?
<fullermd> The same place it stores any other revisions.
<hydratenaturally> how would i go about pursing that, to say look for one of these deleted files
<fullermd> Available evidence suggests there aren't any there, which means (since it takes heroic measures to remove things from a repo) there never were any.
<fullermd> If they don't show up in heads --all, they're not heads.  The only way they could not be heads would be to be in the ancestry of a branch in the repo.
<fullermd> Since you say there's only the one [pseudo-]branch (that checkout), it means either the revs aren't there (and so never were), or they're in the ancestry of that checkout (which is the same as the svn repo's).
<fullermd> Of course, it's _possible_ there's some bug somewhere along the line that's preventing them from showing up, and also prevented them from being left as pending merges in that update.
<fullermd> But it would be the first hint I've heard of such, after all the features have been around a long time, and I wouldn't know where to start looking for it.
<hydratenaturally> yeah i doubt it's a bug, probably something stupid i did
<fullermd> Well, start looking at the assumptions.
<fullermd> Check out info -v, for instance.
<fullermd> If it's not using a shared repo, there's no way some other branch could be interfering with the heads detection.  If it is, see what other branches are in it.  That can eliminate one question, one way or another.
<fullermd> See how many revs it lists being in the branch history, and how many are in the repository.  Being from svn, it's probably a linear history, so maybe they should match up?  Not sure how strong an indicator that might be.
<hydratenaturally> k odd, bzr info -v shows repository: 36 revisions
<hydratenaturally> but bzr log only shows me 30 revisions
<fullermd> What's the first line of info say?
<hydratenaturally> http://pastie.org/793293
<fullermd> 'k, take your right hand, and hold it about 2 feet away from your left cheek.
<hydratenaturally> yeah i'm stupid i get it
<fullermd> 8-}
<fullermd> Then look at how 'heads' lists two heads, with one of them flagged as the tip of the branch (checkout), and the other listed as dead.
<fullermd> What version of bzr are you running, BTW?  rich-root-pack suggests pre-2.0; an upgrade may be in order (not that it has any bearing on this issue; just a general query)
<hydratenaturally> this bug seems interesting
<hydratenaturally> https://bugs.launchpad.net/bzr/+bug/395514
<ubottu> Ubuntu bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge (dup-of: 113809)" [High,Confirmed]
<ubottu> Ubuntu bug 113809 in bzr "update performs two merges" [High,Confirmed]
<hydratenaturally> debian 2.0.3-1
<hydratenaturally> bzr-svn 1.0.0-1
<hydratenaturally> debian = bzr
<fullermd> Hm.  Maybe Debian makes local changes, or you had an older version when you made the checkout.
<fullermd> Anyway.
<fullermd> So that dead head is presumably the head of your local commits.
<hydratenaturally> ok, makes sense
<hydratenaturally> my bzr knowledge is lacking on how to merge those changes into my "working" head
<fullermd> So you can use 'merge' to setup a merge of them.
<fullermd> (of course, a lot of the merge info won't get into svn; unavoidable.  But the changes will, crumbed into one rev)
<fullermd> `bzr merge -rchris@camus-20100125091843-zdk7x8gxpdeq8s4l .`
<fullermd> (the trailing '.' is important)
<fullermd> Then the usual check/commit.
<hydratenaturally> ah ok didn't see revision-id there in heads -all
<hydratenaturally> chris@camus:~/projects/fashionbone/bzr-beanstalk$ bzr merge -rchris@camus-20100125091843-zdk7x8gxpdeq8s4l .
<hydratenaturally> bzr: ERROR: No namespace registered for string: u'chris@camus-20100125091843-zdk7x8gxpdeq8s4l'
<hydratenaturally> just wtf
<poolie> hydratenaturally: you need -r revid:christ@.... i think
<fullermd> OK, now I think you're lying about your bzr version too   :p
<hydratenaturally> chris@camus:~/projects/fashionbone/bzr-beanstalk$ bzr version
<hydratenaturally> Bazaar (bzr) 2.0.3
<fullermd> OK, maybe not.  I thought the DWIM was in 2.0....
<fullermd> But it looks like 2.1.  So what poolie said.
<hydratenaturally> can't get the right syntax
<hydratenaturally> chris@camus:id
<hydratenaturally> vice versa
<fullermd> No, -rrevid:chris@camus-20100125091843-zdk7x8gxpdeq8s4l
<fullermd> revid: tells bzr it's getting a revision id, then the string.
<hydratenaturally> ah
<hydratenaturally> ah it worked, awesome
<hydratenaturally> thanks for all the help guys, you save me oh so much pain
<fullermd> Don't forget to commit the merge, before you forget it's there and mix new work in with it.
<hydratenaturally> heh, course, i just rsync'd the whole dir to my raid1 "just in case"
<hydratenaturally> i'm so overtired at this point that....
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: igc | bzr 2.1.0rc1 and 2.0.4 have gone gold
<hydratenaturally> fullermd: thanks again
<fullermd> np
<hydratenaturally> i was about to take 2 xanax and have a drink
<hydratenaturally> i hear they call it the "jackson"
 * fullermd . o O ( Isn't that pretty much the same thing as using SVN anyway? ) O o .
<hydratenaturally> ahahahah
<hydratenaturally> i should tack on 10/hour to my rate to use subversion
<hydratenaturally> and 25/hour for cvs
<fullermd> How much for Clearcase?
<hydratenaturally> oh jesus
<hydratenaturally> free healthcare
<hydratenaturally> forever
<doctormo> What's the best way to diagnose bzrlib being used in a thread... I can't decide if it's just taking a while to get a transport, or if it's stalled dead.
<doctormo> I think it's the get transports that are freezing out
<doctormo> Man bzrlib is way worse than launchpadlib. at least lp is ok so long as your lp object is in the same thread. bzr just dies if is so much as sees threading being imported.
<doctormo> Worse, it dies by freezing without errors. locking up, charming.
<Raim> is there a short URL spec to refer to the parent/push branch from the command line?
<Kinnison> what are you trying to achieve?
<fullermd> :parent, :push
<Kinnison> are those urlspecs?
<Kinnison> coo
<lifeless> doctormo: this is patently false as we use threading ourselves
<fullermd> Not urlspecs, no.  Builtin aliases.
<lifeless> doctormo: do you have a ssce ?
<lifeless> sorry, sscce
<doctormo> lifeless: No, just rotten luck.
<lifeless> if you have a deadlock, gdb can be great at debugging it
<lifeless> you may have found a python bug, for instance.
<bialix> heya bzr!
<doctormo> lifeless: Possible, I'll have to look into it using gdb.
<doctormo> Time for bed now though...
<doctormo> thanks for your help
<epschern> can i set up tortoise bazaar in a way so someone with bzr 1.3.1 can access it? (think i had no voice when i asked before)
<blenderkid> hi. I did a mistake with bzr revert. I reverted all files instead of just one file. now the other files are lost. Is there a way to revert a revert?
<beuno> blenderkid, bzr makes a backup of the files when reverting
<beuno> try an ls -la in the dir
<blenderkid> a file with a ~1~ ?
<beuno> yes
<blenderkid> ahh good *puh*
<blenderkid> Do I just need to rename it?
<beuno> yeap
<blenderkid> thank you so much :)
<MTecknology> blenderkid: I think that little feature has probably been able to save countless hair pullings
<blenderkid> :D
<epschern> hm, can i somehow downgrade my repository format?
<fullermd> Depending on the exact pair of formats.  'down' and 'up' are arbitrary directions.
<epschern> well, the server has only 1.3.1 and sysadmin refused to upgrade... but our windows machines have newest tortoise bazaar
<epschern> i found now i can set the format on init... but don't want to lose all my commits so far
<fullermd> You can 'update' to rich-root-pack, which 1.3.1 can read.
<fullermd> Presumably, your current stuff is in 2a, which you can't move to a non-rich-root format.  But r-r-p will take you back to 1.0.
<bialix> vila, beuno: here?
<beuno> bialix, hey
<bialix> q about upload
<bialix> beuno: any ideas what's wrong: http://pastebin.com/d5aaaadc0
 * beuno looks
<beuno> bialix, no, there seems to be an error with the path somehow
<epschern> fullermd: i tried it but it failed: http://paste.debian.net/57608/
<beuno> does the branch have anything funky?
<bialix> I guess no
<beuno> bialix, maybe you could try trunk?
<bialix> trunk of the bzr-upload?
<bialix> ok, I'll try
<fullermd> epschern: Mmph.  Stupid upgrade.
<fullermd> epschern: You can work around it by 'init'ing a new branch in rich-root-pack format, then 'pull'ing from your 2a branch.
<bialix> beuno: upload trunk works for me
<bialix> beuno, vila: can you release it as 1.0.1?
<bialix> current version bundled into windows installer seems to be broken
<bialix> and it seems you know about it
<beuno> bialix, sure, I'll chat with vila about releasing soon
<bialix> ok
<epschern> fullermd: thanks a lot, that worked
<epschern> now i still hope cent-os or whatever the server has installed will upgrade their bzr version at some point so there won't be the deprecation message each time :)
<fullermd> Well, you can push and pull back and forth.  So you could use 2a in your branch on the machine with non-ancient bzr version, and just use r-r-p on the old box.
<epschern> i see
<epschern> might do that once i'm more used to it (just had to switch over from git)
<jelmer> poolie, lifeless, vila, jam: http://wiki.bazaar.canonical.com/BzrForeignBranches/Infrastructure
<vila> bialix: bzr-upload is supposed to talk to a server where *bzr* is not installed, trying to make it talk to a bzr *smart* server is... interesting but they have opposite aims: bzr-upload want to provide a remote file system abstraction, the smart server try to get away from the remote file system abstraction
<bialix> ÑÑ Ð¨ ÑÑÑÐ³Ð´Ð² Ð³ÑÑ ÑÐ°ÐµÐ· ÑÑÑÐµÑÑÐ²,
<bialix> so I should use sftp instead?
<bialix> hi vila
<vila> bialix: sftp sound better
<vila> bialix: hi :D
<bialix> ok, I understand you about abstraction
<bialix> maybe you need to puth this remark to upload's help
<bialix> *put
<lifeless> poolie: http://kitenet.net/~joey/blog/entry/a_clean_BTS_is_a_sign_of_a_sick_mind/
<lifeless> poolie: http://bethesignal.org/blog/2009/12/31/this-is-not-a-new-years-resolution/
<jelmer> poolie, https://code.edge.launchpad.net/~jelmer/tribunal/view-subunit/+merge/18006
<radoe_> Where should I report broken links in the online version of the user guide?
<rubbs> radoe_: make a bug report on lp, or mail the mailing list
<radoe> rubbs: report it simply against bzr or is there something  better suited for docs?
<rubbs> ah, report against bzr, but put 'doc' in the tags list at the bottom. Someone should take it up soon.
<radoe> rubbs: thx.
<rubbs> np
<micahg> with bzr-svn do I have to worry about branches not being from the same source when merging?
<micahg> with bzr-svn do I have to worry about branches not being from the same source when merging?
<maxb> micahg: The question is a little vague, could you clarify?
<micahg> I want to have a production and a devel branch in svn and import them both locally with bzr and push to svn with bzr svn
<micahg> I was wondering if they need a common ancestor to merge
<micahg> in bzr
<micahg> maxb: is that any clearer?
<maxb> They do need a common ancestor, but bzr-svn should deterministically import the common history i.e. it is _supposed_ to just work.
<micahg> maxb: if I branch the dev code in bzr and then bzr-svn push to the prod branch, will that take care of the common ancestry
<maxb> I think that bzr-svn will use various bzr* svn properties to record this such that bzr-svn on another computer can do the right thing
<jelmer> yes, it will
<poolie> jam: https://bugs.launchpad.net/bugs/512418
<ubottu> Ubuntu bug 512418 in launchpad-code "no "diff coming soon" message on new mp?" [Undecided,New]
<malibu> Hi there.. can anyone tell me how to see previous file versions in bazaar explorer?
<malibu> I'm selecting the file in the tree pane but can't figure out how to see the versions
<rubbs> malibu: ok, this may not be the only way, but I found a way to do it.
<malibu> cool, thanks
<rubbs> click on the browse button and it opens up a "file browser" You can then put a revision in the upper right corner
<rubbs> that should change it to the revision and the files should then open as that revision...
<malibu> ok mine opens up with WT:, which I suppose stands for working tree..
<rubbs> correct
<malibu> ok very cool.. thanks!
<rubbs> you can replace that with any revision spec. So like to get to the one just before you can put "-1" in
<malibu> ahh
<malibu> Still I wonder if there is a way to get a list of every revision for a file..
<rubbs> oh you mean like annotate?
<malibu> what is annotate?
<malibu> Sorry I'm a bit of a newB
<rubbs> np,
<rubbs> annotate will open the file and give you the revision that each line was changed last on
<rubbs> or do you mean just the lastest revision that file was changed?
<malibu> Well what I would like to see is a list of revisions that the file was changed on
<rubbs> ah.
<NfNitLoop> 'bzr log <filename>'.   Not sure how to do that in the GUI you're using.
<rubbs> so if fileA was changed on revision 2, 5, and 7 then you want to see 2, 5, 7
<rubbs> right?
<malibu> yes
<NfNitLoop> maybe right-click on the file?  IS there a "log" option in the context menu?
 * NfNitLoop will brb, fixing IRC daemon.
<rubbs> malibu: ok, easy.
<malibu> Right clicking on the file does not do anything, unfortunately
<rubbs> malibu: go browse then right click on file and hit "show log"
<malibu> ahh.. must be in browse
<malibu> I was trying to right click on the tree node for the file in the main window
<malibu> I get error  bzr+ssh://.... is not a local path
<rubbs> yeah, I have done that before. The reason he doesn't do that is the work that is needed in the browse window can be slow, so he didn't us it in that main view, because it could make the whole thing slow
<rubbs> this way if you need some of that history viewing, you just hit browse, but don't have all the slow-downs by default
<rubbs> the manage button opens an actaul file browser to the working tree
<NfNitLoop> NOW WITH MOAR BEEF.
<NfNitLoop> :p
<malibu> OK well I'm not sure if it will work for me..
<malibu> I get an error
<Kilroo> Hmm. Does a bound stacked branch actually even mean anything?
<thumper> Kilroo: I don't think so
<thumper> Kilroo: although I guess you could have a light weight checkout of a stacked branch
<Kilroo> I'm guessing the command I left running at work won't accomplish much then...
<thumper> Kilroo: but I don't think you can commit to that due to a known bug
<Kilroo> I'm trying to find a workaround for something
<thumper> which something?
<thumper> and where are you using stacking?
<Kilroo> Well, what I have set up (albeit not thoroughly tested) for one of the subversion repositories I need to work with is a treeless repository with one branch bound to the subversion repo, feature branches as needed, and a lightweight checkout elsewhere that I can switch around among them. Nothing stacked there, at least not so far.
<Kilroo> Unfortunately I can't do that with the another subversion repo I need to work with because revision 30 makes bzr run out of memory.
 * bialix looking for igc
<Kilroo> The command I left running when I departed from work today (which makes less and less sense to me the more I think about it) was a branch --bind --stacked from an svn checkout of the repository in question to a branch in a treeless repository.
<mwhudson> bound and stacked are basically orthogonal
<bialix> Kilroo: looks very funny
<Kilroo> I think what I was trying to get out of it almost makes sense...but not quite...
<bialix> mwhudson: does our beloved core devs sprinting again?
<mwhudson> bialix: yes, in france this time
<bialix> nice
<bialix> I suppose igc is not there
<mwhudson> bialix: right
<mwhudson> he got the ok from his dr to travel, but decided not to go this time
<Kilroo> What the heck would that do if it did make sense, come to think of it? Make a local branch from the subversion repo that would require a connection to it to do anything, have to be rebased to it any time it changed, and automatically commit to subversion when I committed locally?
<Kilroo> This is making my head hurt. I think I'm being ridiculous.
<bialix> mwhudson: thanks for the info. I have some q for him about explorer and translations. will hang around some time tonight
<Kilroo> Stupid revision where the whole blasted site including graphics and pdfs and logs and probably freaking archive files gets added all at once.
<mwhudson> bialix: yeah, i think he'll be on in a bit
 * bialix nods
<bialix> thanks
<mwhudson> bialix: oh
<mwhudson> bialix: except it's australia day today
<mwhudson> so he's probably not going to be around :/
<bialix> rats
<bialix> australia go forward!
 * bialix likes to think somewhere is summer right now, while outside his home is -25 celsius degrees
<Kamping_Kaiser> woo, public holidays :)
<NfNitLoop> Just had a loooong discussion w/ coworkers about branching/merging/SVNfail.
<NfNitLoop> (rather intelligent) coworker was asking how large companies handle large numbers of branches.
<NfNitLoop> I said hopefully not via svn. :p
<Kilroo> Heh.
<Kilroo> You know what's worse than svn?
<idnar> haha
<Kilroo> svn where instead of having a repo for the project and, say, a production branch and a development branch...you have two repos. One for production and the other for development. With everything at the repository root so you can't branch from it either.
<Kilroo> And at least one revision in the repository that's so big bzr runs out of memory trying to look at it, so you can't even get local branches working.
<NfNitLoop> oh god, yeah, you mentioned the prod/dev repos the other day.
<NfNitLoop> That's some special kind of fail.
<NfNitLoop> We actually do things mostly sanely around here.
<NfNitLoop> we've got a 4.0 branch (old)   a 5.0 branch (current stable) and a 6.0 (dev) branch.
<NfNitLoop> We do merges forward (->) most of the time.
<Kilroo> The one thing to be said in its favor is that we have the revision history and who committed what, which we didn't have with plain ftp.
<NfNitLoop> but every now and then someone does something that makes svn merging go all wonky.
<NfNitLoop> like, not merge from the root of the project.
<NfNitLoop> Or manually revert a change.
<Kilroo> Unfortunately the people who set it up apparently didn't think beyond stacking that on top of the ftp approach.
<Kilroo> And I seem to be the only person who ever uses commit messages.
<NfNitLoop> Heh.
<NfNitLoop> I'll say it again -- look for new work. :p
<Kilroo> I -want- to fix it.
<Kilroo> I think I actually have them convinced that it's worth it to let me take a break from developing new features to work on improving HOW we develop. Unfortunately I think I'm going to have to finish the two months-overdue database projects in my queue first.
<Kilroo> And because of the braindead way we have svn set up on the things that are using it now, switching to using it in a reasonable way is going to be as much of a hassle as switching to it in the first place was.
<Kilroo> And since I can't pull in the existing history using bzr because of the giant revisions, we may have to lose all the existing history instead of just half of it.
<NfNitLoop> Why would you have to lose history?
<NfNitLoop> would you be ditching SVN?
<Kilroo> I wish...no, there's two things to deal with.
<Kilroo> One, with development and production having thus far been separate repositories, I'm not sure there is any sane way to convert them into branches that can be treated like branches without pretty much ditching the history from one of them.
<Kilroo> Specifically, make production into the trunk, branch from it for development, paste development over top of it and commit all of those changes as "fixing this harebrained separate repositories business."
<Kilroo> The other problem is that the linux administrator seems to think we can migrate everything without either his intervention or root access to either the old repositories or where the new ones are going.
<NfNitLoop> should be able to as long as you have write access.
<Kilroo> As far as I've been able to determine, svn doesn't seem provide any means for performing the migration with those limitations, though.
<NfNitLoop> though you might need him to shut down the svnserv or whatever it's called, if that's how you're accessing it.
<NfNitLoop> anyway.
<NfNitLoop> This isn't #svn. :p
<Kilroo> At least, nothing I tried seemed to be working. However, branching using bzr-svn and then pushing to the new repository worked a treat.
<mkanat> Kilroo: So it's fastimport that's running out of memory, here, that you're talking about?
<Kilroo> mkanat: No, it's bzr-svn.
<mkanat> Kilroo: Oh. Have you tried bzr-fastimport?
<Kilroo> mkanat: currently I can't make any use of a solution that does not leave me capable of committing back to the current svn repository.
<mkanat> Ah.
<Kilroo> Yeah, fun stuff.
#bzr 2010-01-26
<mtaylor> what the crap?
<mtaylor> bzr: ERROR: exceptions.AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'
<mcr> I was hoping bzr serve would permit some kind of minor password authentication.
<mcr> I want to setup some people with TortoiseBZR because they are major lusers who can not cope with plink, etc. stuff.
<mcr> Is there some option for this?  I'll resort to IP address restrictions if I have to, but ...
<fullermd> No, the bzr:// protocol doesn't have any of that.  There've been occasional discussions on the list; I think somebody posted some WIP patches once.
<fullermd> You could try setting up the bzr+http:// smart server, and using HTTP auth via Apache etc.
<wgrant> Does Windows really still not have a good SSH story?
<fullermd> Oh, c'mon, just put the ball ON the tee for us, why doncha...
<keithy> is there a solution for nested projects as part of bzr yet?
<jam> lp:~canonical-bazaar/udd/hottest100/
<jam> lifeless, poolie, vila: ^^
<jam> lp:~canonical-bazaar/udd/hottest100/
<lifeless> lp:~canonical-bazaar/udd/hottest100/
<justdave> I created a branch with bzr clone, but I want to treat that branch as if it's the original source now, how do I remove the "parent repo" relationship from it?
<fullermd> You can edit it out of the branch.conf.  But what makes you think you need to?
<fullermd> 'parent' doesn't mean any sort of dependancy; it's just the default place that 'pull' looks to.
<justdave> when I try to pull from the new location from a client, it's giving me an error about being unable to write to the original parent
<fullermd> Being a parent branch will never make it try to write there.  That's something else; you have it bound, maybe.
<fullermd> What does 'info' say it is?
<justdave> oh, must be my client spewing that, because the error is about an https: repo, and the new repo shows it with a bzr+ssh: on the old location
<justdave> the client had formerly checked out from the old repo, and I was trying to update it with bzr pull --remember (new repo location)
<Peng> Try "bzr switch".
<justdave> ok, that almost works.
<fullermd> Yes, pull probably isn't what you want to do in a checkout there.
<justdave> my cleint's too old.
<justdave> client*
<Peng> Eep, too old for what? How old is it?
<justdave> Bazaar (bzr) 1.18
<justdave> repository format is 2a
<fullermd> 1.18 can grok 2a (but definitely not as well as a recent 2.0.x, true)
<justdave> bzr: ERROR: KnitPackRepository('file:///(local checkout)') is not compatible with RemoteRepository(bzr+ssh://(new repo)) different rich-root support
<Peng> Hm, can you "bzr upgrade" a checkout to a rich-root format?
<fullermd> That's not a bzr version problem; that's because your checkout is a poor-root format (e.g., pack-0.92 or the like), and the upstream you're wanting to move to is rich-root (probably 2a)
<lifeless> Peng: yes
<justdave> ok, so upgrading the local checkout first might work
<Peng> lifeless: Oh, nice. That makes sense, but it's kind of the thing I'd expect to blow up. :P
<Peng> justdave: It will work. Have faith! :D
<justdave> yeah, it's converting now
<lifeless> fullermd: cat /proc/cpuinfo :P
<timClicks> hi there, is there anything I can do to fix this?
<timClicks> bzr: warning: unsupported locale setting
<timClicks>   Could not determine what text encoding to use.
<timClicks>   This error usually means your Python interpreter
<timClicks>   doesn't support the locale set by $LANG (en_NZ.UTF-8)
<timClicks>   Continuing with ascii encoding.
<Peng> timClicks: sudo dpkg-reconfigure locales, or whatever it is.
<lifeless> timClicks: yes, make sure that you have po files for that locale.
<lifeless> timClicks: if thats turning up when you push, talk to the sysadmin of the server you are pushing to
<timClicks> okay, should be fine
<timClicks> is this a warning or an error?
<timClicks> is it fatal?
 * timClicks reads text... warning
<Peng> Also "Continuing". :D
<timClicks> :)
<Peng> Nah, it just means bzr won't give you Unicodey goodness.
<Peng> Other software is likely to complain about the same thing.
<timClicks> hrm
<timClicks> i don't have sudo rights to this machine
<Peng> So you really should fix it. It's not hard.
<Peng> Ah.
<Peng> ...If the sysadmin hasn't fixed this, maybe it's running a kernel vulnerable to those privilege escalation vulnerabilities? :D
<fullermd> lifeless: cat: /proc/cpuinfo: No such file or directory     :p
<Peng> Wait, why are we talking about /proc/cpuinfo?
<fullermd> timClicks: Are you sure that's a valid locale in your system in the first place?  Check `locale -a`.
<fullermd> I presume he's poking at my bug comments.  So I poke back   ;>
<lifeless> Peng: bug tracker fun
<timClicks> well, it's my own machine's locale
<timClicks> i've sshed into another
<timClicks> and am trying to run bzr within it
<fullermd> Sure, but locale names can differ by platforms.
<lifeless> Peng: what privilege escalation vulnerabilities?
<Peng> lifeless: Linux kernel. Past few months.
<fullermd> You have have en_NZ.UTF-8, while another platform may call it en_NZ.UTF8 or something.
 * Peng waves hands
<lifeless> Peng: for /locales/ ?
<lifeless> fullermd: they generally Just Work
<Peng> lifeless: No, so you can get root and fix the locales. :D
<fullermd> Well, using zh_CN locales makes you vulnerable to Google, doesn't it?   8-}
<Peng> (This is probably illegal and not actually recommended.)
<lifeless> Peng: oh, groan.
<lifeless> timClicks: you can also tell ssh not to pass all your env variables over
<Peng> Sorry. When I have nothing useful to say, I make bad jokes.
<lifeless> I don't recall how to do that offhand.
<Peng> grep LANG /etc/ssh/ssh_config
<fullermd> I'm pretty sure ssh doesn't pass locale stuff like that.  It would probably be in shell rc files on the other side...
<Peng> Ah, SendEnv apparently.
<fullermd> (leastwise, it never has for me)
<timClicks> lifeless: locally or from within ssh ?
<Peng> fullermd: It can, and it often does by default, depending on your distro.
<Peng> fullermd: The server doesn't necessarily care, though.
<lifeless> timClicks: see SendEnv in the ssh config as Peng says
<fullermd> AcceptEnv is off by default in sshd, looks like.
<poolie> jml, i want to know if i should be pushing tribunal stuff into trunk or what
<poolie> "i need to think about it" is totally acceptable of course
<Peng> fullermd: The manpage suggests Debian turns it on, though.
<fullermd> Mmph.  Damn crazy commie hackers...
<fullermd> I wish openssh would give some lovin' to cleaning up connection sharing infrastructure (apropos of nothing)
<jml> poolie, I'll think about it :)
<timClicks> hrm..
<timClicks> just checked locale -a
<Peng> fullermd: What's wrong with it?
<timClicks> and then  export LANG="en_GB.utf-8"
<fullermd> Ah, yeah.  UTF-8 vs utf-8 is one of those things I've seen vary a good bit, along with with/without "-".
<jelmer> jam: http://pastebin.ubuntu.com/363128/
<fullermd> Peng: Too manual.  I've got a lot of fudgery and manual work just to get it working in a few places.
<fullermd> Peng: If it would grow (a) detection and replacement of stale sockets, and (b) automatic spawning and backgrounding, that would fix things nicely.
<justdave> ok, conversion finished, now trying to "switch" tells me:
<justdave> bzr: ERROR: Cannot switch a branch, only a checkout.
<lifeless> justdave: pastebin bzr info somewhere please
<justdave> on the other hand, bzr pull --remember actually works now
<justdave> it's update
<justdave> d
<fullermd> ('course, on the list of software features needing polish, that winds up WAY below !@&$ suexec...)
<Peng> fullermd: Ahh, good point. My favorite part is the big race condition: if you start two SSH processes with no socket, the second one will start a connection, then error out because the other created the socket.
<mkanat> justdave: Oh, I was going to paste info about how to resolve your exact situation, after we switched.
<mkanat> s/paste/write/
<justdave> mkanat: yeah, was my checkout of bmo I was trying to update :)
<mkanat> justdave: Yeah, I figured.
<mkanat> justdave: It just takes a "bzr upgrade" then probably a "bzr bind" I'd guess.
<justdave> so the main trick is I need to update my local repo to 2a format first before trying to reparent it
 * mkanat nods.
<justdave> tells me "conflicting tags" though...  I get that a lot (because the current-production tag floats, and gets moved along with what's on the production server)
<justdave> is there a way to tell it "use the parent's version of the tags"
<justdave> ?
<mkanat> justdave: Oh, that's interesting. Are you using pull or update?
<justdave> pull
<fullermd> I think pull --overwrite will force overwrite the tags.
 * mkanat was just about to suggest that.
<mkanat> justdave: pull is only usually for unbound branches, though.
<mkanat> justdave: Usually for checkouts I use update.
<Peng> You can also "rm .bzr/branch/tags && bzr pull". :D
<justdave> I keep a local branch so I can work on stuff when I don't have internet
<justdave> push the whole thing back when I get online again
<mkanat> Makes sense.
<jelmer> jam: debian_bundle.changelog.Version
<bialix> hi jelmer
<jelmer> hey bialix
<bialix> what do you mean by: "qbzr command for importing svn/hg/git repositories? "
<bialix> from http://wiki.bazaar.canonical.com/BzrForeignBranches/Infrastructure
<bialix> jelmer: ^
<timClicks> :/ i have an error 13 (permissions) popping up. have used ssh to get into a machine and bzr refuses to do anything
<timClicks> can i do anything to help it along from my end?
<jelmer> bialix: a qbzr command that does svn-import/git-import
<jelmer> bialix: if you're familiar with those bzr subcommands
<bialix> jelmer: I've used svn-import
<bialix> jelmer: do you want to have generic dialog?
<bialix> e.g. Import wizard?
<bialix> there is also plain import command from bzrtools, what about it?
<jelmer> bialix: yeah, generic dialog
<jelmer> bialix: plain import is completely different
<bialix> jelmer:why?
<jelmer> bialix: for ease of use
<bialix> no, I've asked why about bzrtools' import
<jml> poolie, I'll try to devote some concentrated time to tribunal today
<jelmer> bialix: Why it is completely unrelated? It imports trees from directories or zip files
<bialix> or tarballs
<bialix> jelmer: if you have some sketch in the mind, can you send it to qbzr@googlegroups.com ? ascii art will be fine
<bialix> btw, what's the current status of bzr-gtk?
<lifeless> jml: we could do a conerence call after work, if you want
<jelmer> bialix: we should probably add the required infrastructure in Bazaar first
<jml> lifeless, thanks, but I've already got plans for this evening.
<bialix> that's great
<lifeless> jml: :P
<poolie> jml, actually i don't want to demand a lot of time from you
<poolie> just
<poolie> s//also, we can talk easily in london
<poolie> i feel a bit like i'm forking your project so just wanted some reassurance that you're ok with where it's going
<poolie> but you seemed to basically agree in sinny
<jml> poolie, ok. the context-switch overhead is basically my biggest blocker atm :)
<poolie> yeah i thought so
<poolie> just say "I trust you, poolie" and I'll continue :)
<jml> poolie, I trust you
<fullermd> Just don't sign anything in blood after saying that...
<bialix> evening igc
<lifeless> hi bialix
<bialix> heya lifeless!
<bialix> how you guys&
<bialix> ?
<lifeless> we're good; spriting at vila's place
<bialix> cool!
 * bialix waves at vila
<bialix> I will give a talk next saturday about using gettext in python, based on our work in qbzr and bzr-explorer
<bialix> want to chat with igc, but can't catch it here
<poolie> bialix: hello, he is here
<bialix> heya poolie
<poolie> hi there
<bialix> poolie, I know this is not any high or medium priority for bzr itself, but do you think we can just reuse our i18n work from bzr-explorer?
<poolie> in core bzr?
<poolie> i haven't looked at the code at all but i'd love to do it
<bialix> yes
<poolie> now would be an excellent time to do it in 2.2
<poolie> because we have time to shake out any problems
<poolie> can we do a tiny patch that starts adding it in?
<bialix> perhaps
<bialix> Ian has suggested to use special ZzzTranslations class which we can use for testing if we want to really test gettext stuff
<bialix> poolie: we can start with tiny patch
<bialix> just need to figure out what is the good target for it?
<bialix> error messages, maybe
<bialix> command helps kept in docstrings -- this will require serious rework
<jelmer> jam: https://edge.launchpad.net/+apidoc/
<poolie> jam, the url's like that because it's looking at docstrings in the running app aiu
<poolie> aiui*
<poolie> bialix: i think errors would be good
<poolie> i don't know what ZzzTranslations means
<bialix> anybody has idea what's wrong? http://doc.bazaar.canonical.com/plugins/en/push_and_update-plugin.html
<bialix> the link above from BzrPlugins page
<poolie> http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<bialix> poolie: zzz is special decorator wich used instead of real translations
<poolie> i guess that ian just renamed it
<bialix> oh
<bialix> poolie: so in the tests if we need to ensure we properly translate the string we can self.assertEqual('zz{{Hello}}', gettext('Hello'))
<bialix> igc: there is many links at http://wiki.bazaar.canonical.com/BzrPlugins which does not work now
<lifeless> poolie: https://bugs.edge.launchpad.net/launchpad-code/+bug/386596
<ubottu> Ubuntu bug 386596 in launchpad-code "pushing to a packaging branch can't create a new package" [Medium,Triaged]
 * vila waves back at bialix
<bialix> heya vila :-D
<lifeless> igc: can you paste the url for hte upstream bug report
<Ng> how can I do bzr annotate on a revision in the past, where subsequent revisions have renamed or removed the file in question?
<mzz> huh, I could've sworn "bzr ann -r<old> old/path/to/file" worked
<elmo> bzr annotate -r <old rev> <filename?
<mzz> unless I'm screwing up one of my arguments it fails with an "is not versioned" message
<bialix> Ng: use current name, you're in bzr, not in hg ;-)
<mzz> bialix: yes, but what if the file no longer exists?
<Ng> I
<Ng> I branched at the revision I care about and that worked ;)
<mzz> oh, yes, that's a workaround
<bialix> mzz: then I'd open qbrowse and launch qannotate from there ;-P
<bialix> hmm, bzr cat has the option --name-from-revision
<bialix> perhaps annotate should provides such option too
<bialix> care to file a bug?
<lifeless> mzz: it should use the path of the file in that revision
<lifeless> if it doesn't please file a bug
<mzz> well, it's possible I'm screwing up my arguments, but I don't think so
<mzz> lemme try with a test branch, just in case
<fullermd> Well, you wouldn't want it to ALWAYS use the path from the revision...
<mzz> yes, sometimes when I'm backtracking I want to see an annotate for a file that's still there
<lifeless> fullermd: its more sophisticated than that :P
<fullermd> Well, yeah, should be.  I'm not aware that it IS, though; seems I've run across it before.
<mzz> while simultaneously I can imagine wanting to annotate an old file while a different file with the same name is currently present
<mzz> that's probably pretty rare though.
 * mzz is filing
<mzz> err, or not. I wonder why my bug search missed this
 * fullermd is fliing.
<mzz> it's part of https://bugs.launchpad.net/bzr/+bug/255687
<ubottu> Ubuntu bug 255687 in bzr "log and annotate should work on removed files" [Medium,Confirmed]
<jbrouault> hi, the bzr join command fails with the error "File id {TREE_ROOT} already exists in inventory as InventoryDirectory...."
<jbrouault> is the python code given in https://answers.launchpad.net/bzr/+question/71563 safe to use to make it work ?
<lifeless> jbrouault: probably
<Peng> Always reassuring. :D
<jbrouault> lifeless: the parameter to set_root_id must be a "unique" string that's all ?
<lifeless> not "unique", Unique
<lifeless> there is a guid  generator in bzr that you should use
<lifeless> we use it to generate file ids
<maxb> How does changing the root id not involve rewriting all historical revisions?
<lifeless> maxb: why should it involve that?
<maxb> I thought file ids were recorded as part of revisions?
<lifeless> yes
 * fullermd suspects semantic clash.
<maxb> oh... is bzr's view of this operation somewhat as if you've mkdir'ed a fresh root in the resulting tree, and moved all the content of the tree being joined into it?
<fullermd> "changing the root id" can mean both "changing the file-id of the existing root (which requires rewriting whatever's based on that)" and "switching the root to be a different file{,-id}", which doesn't require rewriting any more than "bzr mv a b ; bzr mv c a" requires rewriting all the previous revs that had a.
<maxb> I think I begin to understand
<jbrouault> lifeless: ok thanks :)
<nyu> hi
<nyu> I want to branch from an SVN repository using -r parameter, I understand I should specify the bazaar rev number rather than the svn one, but I don't know how to figure it out without having the checkout first
<bialix> nyu: create shared repository, checkout everything, then create new local branch from desired revision
<bialix> is it OK for you?
<nyu> bialix: I wanted to branch only a subdir of the SVN repo.  can I get that at the end of this process somehow?
<bialix> it depends: do you need to push changes from local repo back?
<nyu> no
<nyu> fast-export?
<bialix> just branch from the desired subdir
<bialix> bzr branch http://svn/repo/dir/subdir
<nyu> bialix: problem is, in current head this subdir no longer exists
<nyu> taht's why I wanted to use -r
<bialix> then get everything, after that use fast-import-filter or split
<bialix> fast-import-filter should be the right thing
<bialix> or maybe you can run log (qlog) against svn repo, remember the revision number as bzr see it and then branch
<bialix> did you try it?
<bialix> it will be double conversion and maybe slow though
<nyu> bialix: you mean svn log or bzr log?
<bialix> bzr log
<nyu> on repo root or on removed subdir?
<bialix> on your trunk
<bialix> or parent dir of missing dir
 * bialix gotta go, waves bye
<adrien_> Hi,  I have one question concerning a migration from a subversion repository.
<lifeless> adrien_: then you should ask it :)
<adrien_> I fact I have screwed up the conversion process and the history is incomplete in generated bzr branches. However the final state of each branch is correct (same as in each svn branch)
<adrien_> lifeless: it's a long problem ...
<adrien_> So the question is: can I still hack on the branches with incomplete history and then later apply each patch on a correct bzr branch when I understand how to create it
<adrien_> or is this incomplete history problem a top priority problem that I really need to solve before even thinking about starting programming new features ?
<adrien_> thanks :)
<lifeless> you should probably fix it first
<adrien_> this may take a long time
<adrien_> I have thought about bzr rebase, but maybe this command only works on branches that share a common history
<lifeless> indeed, it prefers common history
<lifeless> you can in the worst case use 'bzr diff' + 'patch' to migrate across
<lifeless> it would depend on the amount of work you do
<adrien_> I see. It could even be automated and apply patches + commit iteratively. But then I would have to manage cases when files are created, and call bzr add before commiting.
<mzz> adrien_: that sounds like you're describing the "tailor" tool
<adrien_> can tailor import from bzr branches to bzr branches ?
<fullermd> I think so, as well as it can bzr->anything && anything->bzr anyway.
<lifeless> personally I would keep working on svn till the import is good
<phoenixz> I am workin on a large webbased project in a medium size company here. some 200 people are using it and I use bzr to manage the php source code. So far so good, but I want to be able to work on multiple versions of our system.
<phoenixz> that is to say, there is a 0.8 in production already, we must work on revisions there.. there is a 0.9 planned to be released next month, we must work on that to build it.. there is a 0.10 planned for in 2 months and also there we must be able to work on it to prepare it
<phoenixz> So Im thinking how to do that, I was thinking to have 3 repositories with their WTs, so I have project/0.8, project/0.9 andp project/0.10
<phoenixz> I also have the same structure on the server, where 0.10 is a checkout of 0.9, and 0.9 is a chekcout of 0.8
<phoenixz> In the 0.8 checkout we will only add bugfixes  (and also revision tags), which we can merge to the 0.9 and 0.10 checkout
<adrien_> lifeless: I think that I'll follow your advice. Unfortunately the subversion server is down so I took this opportunity to migrate to a distributed vcs. I'll try harder to convert our subversion history before going too far with the corrupted bzr branches.
<fullermd> phoenixz: Well, (a), 3 _branches_, not 3 _repositories_, and (b) that last sentence with the chain of checkouts doesn't make sense...
<phoenixz> Is this setup a good idea or am I totally off here?
<phoenixz> fullermd: sounds like Im off here :)
<phoenixz> fullermd: okay, so how would I take this up then?
<fullermd> Well, the first part was reasonable; just a terminological quibble.
<fullermd> The latter isn't really parseable; it's like saying "then I'll coffee wibble venetian blinds"
<phoenixz> fullermd: I agree with that I need 3 branches, but the thing is that I don't see ATM how I can have multiple WTs from multiple branches from one checkout
<adrien_> thanks to lifeless, mzz and fullermd for your advices :)
<fullermd> Right, that second clause right there; it makes me go all cross-eyed, because it doesn't make sense   8-}
<phoenixz> fullermd: Sure, make fun of me! :) anyway, how can I then, have only one checkout? because AFAIK, a checkout == branch, not? can I have multiple branches in one checkout?
<fullermd> Not that it's a bad way to set it up, or that it won't do what you want; it doesn't _mean_ anything.
<fullermd> "multiply branches in one checkout" is gibberish.  What is it you need to DO?
<phoenixz> fullermd: well, I think you need my glasses to see it :)
<fullermd> I mean, it sounds like you just want 3 branches.  So where does this extra layer of complication come from?
<phoenixz> fullermd: okay, let me rephrase.. is it possible to have multiple branches in one checkout?
<phoenixz> because AFAIK, it was not.. thats where the complication comes from
<fullermd> The answer has to be "no", because it's nonsensical.  You can't have ONE branch in a checkout.  Branches don't go in checkouts.
<phoenixz> fullermd: I need three branches of the same project (versions 0.8, 0.9, 0.10, and in the future also other versions) to work on
<fullermd> OK.  So far, so good.  Sounds like just what you'd want.
<phoenixz> fullermd: okay, Im using the wrong term then..  When I do bzr checkout, what is the .bzr directory called?
<phoenixz> fullermd: crap
<phoenixz> fullermd: when I do bzr branch originalrepo targetrepo... I'll have a new project directory with its own .bzr directory in it, right?
<fullermd> Nothing in particular, really.  ".bzr" I guess...
<phoenixz> fullermd: my bad, I'm a mess today with terminology
<fullermd> Right, you'll have a new branch (technically; socially, you may really just intend the second branch to remain a mirror of the first branch, but it's technically separate)
<fullermd> And terminologically, you'd "bzr branch originalbranch targetbranch", not [...]repo.  Repository is a different thing, which you generally don't touch explicitly.
<phoenixz> fullermd: alright.. So, I have a projects/kas directory, (kas is the projects name), I want to have projects/kas/0.8, projects/kas/0.9, and projects/kas/0.10 so that I can work on each version as needed..
<phoenixz> fullermd: so far, so good?
<phoenixz> fullermd: thing is, 0.8 can only contain bugfixes.. 0.9, in development can contain new stuff.. 0.10 will contain new stuff in another area of the project..
<fullermd> (phone; I'll read backlog)
<phoenixz> fullermd: Now, on the server, where we have the branches designated to be trunk, what would I d
<phoenixz> fullermd: sure, np, I'll keep writing
<phoenixz> Now, on the server, where we have the branches designated to be trunk, what would I do?
<phoenixz> would I also set up the same projects/kas/0.8, projects/kas/0.9 etc. layout? or is that, as I understood from you, overly complicated and should we only have one trunk?
<phoenixz> Because my next problem then is.. Im also working with other people on it, they'll have the same layout on their computers.. so if they make a 0.8 version fix, that needs to be sent a) to me, and b) to the server too.. if we all make changes to 0.8, 0.9 and 0.10, and we all merge those to that trunk, how can we separate the bugfixes for 0.8 and the new changes for 0.10? I can tag 0.8.x here on my computer, but AFAIK, the trunk repo on the server would contain
<phoenixz> all chages
<fullermd> OK, well, "trunk" is a purely social construct.  It's useful when there's essentially one branch, and everything is aimed to go there.
<fullermd> Here, you have something like 2.5 "trunks".  So using that term probably clouds more than it helps.
<fullermd> Basically, you've just got 3 branches, and you need at least some subset of people to work on all 3.
<fullermd> So...   well, it's pretty much the same as having 1 branch, and having a bunch of people work on it.  Just 3 times.
<fullermd> One central branch, everybody has a checkout of it.  Alternately, 1 branch that everybody pushes too.  The former's probably simpler to explain and manage.
<radoe> Hm, am I missing something or is there really no difference between "bzr version" and "bzr version -v"?
<LeoNerd> $ diff <( bzr version ) <( bzr version -v )      Gives me no output
<LeoNerd> So apparently not
<phoenixz> fullermd: ah, okay.. so basically, the setup with 3... master branches? on a central server, one for each version, is correct then?
<phoenixz> and every developer branches from one or more of those 3 to their own machine..
<phoenixz> fullermd: and then.. if we make a fix to 0.8, I'd like to send that fix also to 0.9 and 0.10.. if those are also branches from eachother, I can just push the changes from 0.8 to 0.9 then, correct?
<fullermd> 'push' in a metaphorical sense presumably; not in the sense of "bzr push" certainly.
<fullermd> Perhaps in a "bzr merge" way, depending on your topology.  Wouldn't make sense to me.
<phoenixz> fullermd: well, push / pull depend on which branch you are, and if you are taking it from another or sending it, not?
<phoenixz> fullermd: Anyway, the setup would be correct?
<fullermd> push/pull only work when the source branch is a superset of the target; that wouldn't be the case here.
<fullermd> But yeah; 3 branches, checkout/branch whichever is appropriate for what you're working on.
<phoenixz> fullermd: well, since the idea of "trunk" is more social, and branches are just copies with a shared history of eachother (i say that correctly?), I ought to be able to send (using push, pull, merge, whatever) from any branch to any other branch, no? practically, If I am A, my coworker B, the central "trunk" C... then if I have something on A0.8, I can push it to C0.8, and then send it to C0.9 and C0.10, right?
<phoenixz> and from there, b0.9 could receive that change from B0.9
<phoenixz> and from there, B0.9 could receive that change from C0.9
<phoenixz> (fixed)
<fullermd> push/pull don't make sense, because the result is to make the destination branch identical to the source.  If you wanted that, you wouldnt' want 3 branches in the first place.
<fullermd> merge probably doesn't make sense either, because it requires fully connected graphs.  Same problem.
<fullermd> Doing a 'bzr merge' that actually does a cherrypick is more likely.
<fullermd> That's functionally identical to manually making the change in each branch, though it does give you some help with doing so.
<phoenixz> fullermd: so in that case, if I have on the "trunk" the versions 0.8, 0.9, etc.. How can I send fixes from 0.8 to 0.9?
<phoenixz> fullermd: basically, if 0.9 is a branch of 0.8, everything that was added to 0.8 AFTER the branch can be considdered a fix and could be sent to the 0.9 branch
<phoenixz> fullermd: changes from 0.9 would NOT have to be send back to 0.8 because they are not related to the 0.8 version
<phoenixz> fullermd: same thing goes for 0.9 and 0.10.. How could I somehow send these fixes to the versions above? 0.8 > 0.9 > 0.10
 * fullermd shrugs.
<fullermd> That becomes a project topology question.  It's a way to go; it's just not one that makes visceral sense to me.  If it works for you, then run with it.
<phoenixz> fullermd: well, thats the thing.. AFAIK, it would work.. but Im wondering if its the best way to go, and because of that Im asking if it is.. If its not, how could I do this better?
<phoenixz> fullermd: I need to get the code bases of each version separated as to not mix new functionalities with fixes.. but at the same time I don't want to do work double.. If I fix somehting in 0.8, I'd like to send it to 0.9 without having to redo all that work..
<phoenixz> fullermd: how would you recommend to do this then?
<fullermd> I wouldn't want to prejudice you.  There are as many opinions on that as there are developers, MULTIPLED by projects.
<fullermd> If you're mentally, socially, and technically comfortable with declaring that 0.9 will always include everything 0.8 does...   well, then that'll probably work for you.
<fullermd> I wouldn't be; I consider that the two branches go off in their own directions, and from the branch point neither is ever again a layer on top of the other.
<fullermd> But I'm neither you, nor working on your project.
<phoenixz> fullermd: Well, how would you do it then, when you find problems in version A, which have 100% shared code with B.. you fix A, you'd fix B separately?
<phoenixz> fullermd: and again, NOFI, I'm just asking your opinion here
<fullermd> But I'd never have 100% shared code.  If I did, I wouldn't have A and B, I'd just have A.
<fullermd> Unstable branches always get changes that aren't appropriate for the stable branch, and vice versa.
<fullermd> If that doesn't happen for you, then it can work.  It's just a different world from where I sit, so I can't have much of an opinion.
<phoenixz> fullermd: okay, thanks for your opinion, everybody can always add their ideas I guess.. More opinions can only result in better decisions being made..
<fullermd> All you can do is try it and see how it works.
<fullermd> Keep merging 0.8 into 0.9, 0.9 into 0.10, and do it until it breaks down.  Then figure out what else to try.
<fullermd> It's not like starting out that way commits you to sticking with it forever after all.
<phoenixz> How can I change the default push path without actually pushing?
<phoenixz> fullermd: nah, maybe we'll change this later on, who knows.. but I'd prefer starting out good than having to realize 6 months later that we've been on a very bad road..
<beuno> phoenixz, you can edit ~/.bazaar/locations.conf
<beuno> or and/or
<beuno> yourbanch/.bzr/branch/branch.conf
<phoenixz> beuno: yeah, just found it myself as well.. thanks anyway!
<AnAnt> can one add post commit/receive... hook scripts in bazaar ?
<phoenixz> AnAnt: AFAIK, yes, you can
<phoenixz> AnAnt: not too much time to look it up now, but try google > "bzr hook scripts"
<rockstar> AnAnt, yes, you can.
<AnAnt> thanks
<mrooney> hey all, if bzr svn-import is spewing "inconsistent details in skipped record", is this a problem or can I expect to have a usable repository at the end?
<jam> mrooney: if you look at one, and the difference appears to be () versus [] in one location, then you can likely ignore it (and this is the most likely case)
<mrooney> jam: hm, it seems to be more parens or something: http://bzr.pastebin.com/d3e0aefed, any thoughts?
<jam> mrooney: the first one has ..... , ((( and the other has ....., ([(
<jam> ignore it
<lifeless> file a bug so we can fix it :)
<mrooney> lifeless: certainly! in bzr or bzr-svn?
<boombatower> where can I find documentation of the parameters for the pre_commit hook
<boombatower> I can find a paragraph summary, but no documentation of paramters
<boombatower> I am fairly sure I found it once, thanks in advance
<khmarbaise> Hi...i have a little problem with pushing changes back to launchpad...
<khmarbaise>  bzr push lp:~n-launchpad-soebes-de/doxygen-maven-plugin/trunk
<khmarbaise> bzr: ERROR: Cannot lock LockDir(lp-64789904:///~n-launchpad-soebes-de/doxygen-maven-plugin/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<khmarbaise> Someone an idea ?
<cody-somerville> khmarbaise, Have you done 'bzr launchpad-login' yet?
<khmarbaise> yes i did...
<cody-somerville> khmarbaise, ah
<cody-somerville> khmarbaise, You can't push to that branch. Its an import.
<khmarbaise> Hm..Do you know what i have to do now so that i can push back the changes to launchpad ?
<cody-somerville> khmarbaise, You'll have to push to a different location. Are you trying to migrate your svn repository to bzr on launchpad?
<khmarbaise> It's already migrated ..
<boombatower> any help on say...how I can get the branch/repository name from pre_commit hook...assuming local, or master variables
<boombatower> but can't find documenation on what they are
<cody-somerville> khmarbaise, Right. I just didn't know if you expected your changes on launchpad to be synced back to your svn repository or not :)
<cody-somerville> khmarbaise, Now that we have that out of the way, what you can do is push to a different location or you can move your import to a different location and then you can push.
<khmarbaise> cody-somerville: sync back to svn that might a good idea..but that can be done later..
<khmarbaise> cody-somerville: How can a create a different location ?
<cody-somerville> khmarbaise, By giving the branch a different name or by making the branch owned by a team you're a member of. So either 'lp:~n-launchpad-soebes-de/doxygen-maven-plugin/<NEW NAME HERE>' or 'lp:~<DIFFERENT OWNER HERE>/doxygen-maven-plugin/trunk'. You can also push the branch to a different project but I don't think thats what you're looking for.
<cody-somerville> You'd replace the text between the brackets (e.g. < and >) with the actual value you wish to use.
<khmarbaise> cody-somerville: I have created a new "series" on lp and pushed the changes to launchpad...
<pynonoir> Hello again, I need to convert a svn repository with a non-classical layout. I have tried for a few hours with svn2bzr but I think it would require too much work (like defining a new BranchCreator object in python). Now I have some hope that bzr fast-export-from-svn could do the job but I'm completely lost somewhere between exporters filters and importers
<pynonoir> the svn repository layout is described here: http://pastebin.com/d3c681c20
<pynonoir> I would like to create a bzr branch for, say, feature2 and feature2b
<pynonoir> the best I could do with svn2bzr is to create a bzr branch for feature2, but the history of this branch starts when I created this feature branch with the "svn cp" command
<pynonoir> any idea of how to do this with fast-export/fast-import ?
<Stavros> hi
<Stavros> does anyone know how i can dpush to github? it's driving me crazy :/
<thumper> igc: you around?
<Stavros> bzr-git with github, anyone?
<thumper> Stavros: why would it be different to bzr-git with elsewhere?
<thumper> not that I've used it personally
<Stavros> thumper: it wouldn't, but i can't get it to work
<Stavros> actually, it works, it just gives an error message that make me think it wasn't
<Stavros> so ignore me
#bzr 2010-01-27
<mkanat> mwhudson: Hey hey. Have there been any more hangs of loggerhead?
<mkanat> mwhudson: That is, since my last comment in the bug.
<mwhudson> mkanat: not sure, let's ask spm!
<mwhudson> spm: hello
<mkanat> mwhudson: Okay! :-)
<spm> mwhudson: yo!
<spm> mkanat: hey hey!
<mkanat> spm: Hey hey. :-)
<spm> of course asking me when I'm back after a 4 day weekend is cruel....
<mkanat> spm: lol
<mwhudson> mkanat: nothing in the log since the 19th
<mkanat> mwhudson: Well, that's an improvement.
<mkanat> mwhudson: Perhaps we should close the extant bug with a slightly updated summary, and open a new one for these different hangs.
<mwhudson> grar
<mwhudson> mkanat, spm: hello again
<spm> yo
<mkanat> <mkanat> mwhudson: Perhaps we should close the extant bug with a slightly updated summary, and open a new one for these different hangs.
<mwhudson> i guess that makes some sense
<mkanat> mwhudson: Okay. I'll do it.
<boombatower> is a setup.py and such required for bzr plugin...it seems not since I can run my plugin from home dir without one...but online docs says that you should run the setup command when installing
<boombatower> is that just a good case since most/many have a setup
<boombatower> or is it required
<mwhudson> mkanat, spm: again again?
<Peng> boombatower: You can dump it in the plugins directory however you want. It doesn't have to be setup.py.
<spm> mwhudson: wet string problems?
<boombatower> Peng: ok, thx
<mwhudson> that last one was just me typing the wrong thing :(
<mwhudson> spm: but yes
<Peng> Wet strings?
<spm> Peng: is how NZ is connected to the intartubes. on good days, all 5 strings are in operation. some days they dry out.
<mwhudson> spm: my isp disconnected me two days early before our move
<mwhudson> so i'm connected via 3g
<spm> that was generous of them!
<mwhudson> which is freaking slow
<spm> heh
<mwhudson> ~dial up speed
<igc> hmm
<spm> mwhudson: so... it's an improvement from what you had before?
<mwhudson> spm: i don't think someone from .au can be _that_ smug
<mwhudson> spm: if you were in finland or japan or something...
<spm> mwhudson: it's taken *decades* of practice to get this smug. Rightly or wrongly is irrelevant.
<mwhudson> spm: point conceded
<spm> hahahahaha
 * igc lunch
<micahg> how do I make bzr svn only commit locally until I push?
<james_w> micahg: you need to unbind
<micahg> is there a way to get a bzr-svn branch so that I have the history locally?
<james_w> micahg: did you use "bzr branch?"
<micahg> james_w: no, I ran bzr init on an svn checkout
<james_w> ah
<james_w> you've just created a bzr branch with none of the history from svn then
<micahg> james_w: how can I import?
<micahg> I can see with bzr log
<james_w> if you use "bzr branch svn-checkout bzr-branch" then you will have the whole history locally
<micahg> thanks james_w
<micahg> james_w: is there a way to have both .svn and .bzr control the folder?
<Peng> micahg: Depends on what you mean.
<Peng> micahg: You've done that already -- they're just completely independent.
<micahg> well, when I branched the svn checkout, I get no svn dir
<Peng> That is correct. You got a bzr branch.
<Peng> You do know that bzr can operate directly on svn checkouts, right?
<Peng> cd svn_checkout; bzr status
<Peng> Obviously that doesn't give you local history, though.
<micahg> I tried that, but the history isn't local
<micahg> right...
<luke-jr> james_w: Peng: pretty sure not
<luke-jr> 'bzr init' in a Subversion WC just activates bzr-svn
<spm> micahg: do you mean that bzr would have the .svn/ in it's tree and vice versa; svn would have the .bzr in it's?
<micahg> spm: i guess so
<Peng> luke-jr: Not what?
 * micahg was just hoping to add local history to my svn checkout
<spm> micahg: ew! :-)
<luke-jr> Peng: it wouldn't create an independent Bazaar branch
<luke-jr> micahg: bzr branch svn://.../
<micahg> hmm, it's not going to overwrite when I push, will it?
<Peng> luke-jr: That is correct.
 * micahg was reading the FAQ and got scared
<luke-jr> micahg: Subversion doesn't allow overwrite, and even if it was a Bazaar upstream, you'd need to put --overwrite
<luke-jr> pushing will just push the commits up
<luke-jr> but if you're going to push, you should probably configure the Subversion server to allow Bazaar to fudge the commit dates
<micahg> does it push all the commits as one or individual ones?
<micahg> what do you mean fudge commit dates?
<ronny> micahg: by defaul svn enforces the commit date to equal the time it was commited to svn, but allowing bzr to edit them would allow to fit them to the time you commited them in bzr
<poolie> hi
<poolie> https://bugs.launchpad.net/bugs/497595
<ubottu> Ubuntu bug 497595 in launchpad-code "some/all branches can't be accessed over http while launchpad is readonly?" [Undecided,New]
<Peng> Nice.
<Peng> ...I just got an OOPS opening that bug! :D
<Peng> Oh, it's read-only now? Is it supposed to OOPS, though?
<lifeless> Peng: no
<lifeless> #launchpad
<bialix> heya bzr
<Peng> lifeless: :D
<poolie> hi igc
<poolie> could you fix https://bugs.edge.launchpad.net/bzr/+bug/512835
<ubottu> Ubuntu bug 512835 in bzr "doc overview doesn't distinguish 2.1 from trunk" [Medium,Confirmed]
<poolie> you could probably do it a bit faster than me
<igc> poolie: sure
<poolie> thanks
<jml> poolie, you've probably noticed, but I've transfered tribunal maintainership to you. hope the delay hasn't sucked the momentum out of thing.
<jml> s
<poolie> not at all
<lifeless> jml: I don't think it has, from my obsservation
<poolie> i'm flattered
<poolie> thanks
<poolie> wish you were here
<jml> good to hear.
<jml> poolie, thanks :)
<mkanat> The upstream Bugzilla migration to bzr is pretty close now.
<mkanat> We have our server all set up and configured, I just have to get a Bugzilla release out of the way so that we don't have that hanging over us immediately after we switch.
<mkanat> I wrote a script that will sync a single bzr commit back to CVS, also, for a particular branch.
<mkanat> So we'll be using that to mirror stuff back to CVS.
<mkanat> It's here, right now, in somewhat-incomplete form: https://bug517131.bugzilla.mozilla.org/attachment.cgi?id=423332
<poolie> mkanat: woo
<mkanat> :-)
<mkanat> I also wrote a silly plugin that makes sure that the committer is identical to the currently-logged-in user, which is here if anybody ever wants it: http://bzr.mozilla.org/bzr-plugins/enforcecommitter/files
<mkanat> (This works for us because our SSH user names are all email addresses.)
<mkanat> The plugin breaks uncommit, though. :-(
<mkanat> Which is probably okay for us, but I didn't know how to deal with the uncommit case well.
<lifeless> mkanat: you could check to see if the new tip  is in the ancestry (when the username does not match)
<mkanat> lifeless: Ohh, that's a good idea.
<mkanat> lifeless: What's the fastest and most canonical way to do that? revid_to_revno or whatever it's called?
<mkanat> Also, pulling the username out of the revid seemed hacky, but I didn't see any other way to get it for an uncommitted change.
<lifeless> mkanat: branch.repository.get_revision(revid).committer/authors
<mkanat> lifeless: Rock!
<mkanat> lifeless: The API docs don't list the members of each class, only the methods.
<mkanat> Ohhh, no, they do!
 * mkanat totally missed that.
<lifeless> maybe not consistently, but we try
<mkanat> Yeah. repository is there in BzrBranch.
<mkanat> "committer" and "authors" aren't there in Revision, though.
<lifeless> ok
<lifeless> so I won't fix that right now
<lifeless> but if you file a bug, tagged doc, saying that the members of Revision are not in the API docs someone will likely do it
<mkanat> lifeless: Okay. :-)
<MTecknology> My cron task keeps giving me this - No handlers could be found for logger "bzr" - I haven't been able to figure out why yet
<MTecknology> I'm doing bzr pull..
<ronny> MTecknology: that usually happens if bzr fails to hook in a logfile for the logger due to permission errors
<ronny> MTecknology: unfortunately i dont remember the file position
<MTecknology> ronny: ~/.bzr.log?
<ronny> MTecknology: possible
<MTecknology> ok... sudo must not be running this in the users environment
<MTecknology> thanks
<Morbus> g'day. i've created a pre-commit bzr plugin hook, and placed it in the *branch server*'s system-wide plugin directory, as I want it applied to all commits.
<Morbus> how can i tell if it's being called, when it doesn't seem like it's working? ;)
<lifeless> jam:
<lifeless> 01:23 < pitti> lifeless: python -c 'import apport.crashdb; help(apport.crashdb)' describes the CrashDatabase of apport
<Morbus> my .bzr.log shows that its checking the plugin directory that i placed it in, but not that it's being called or anything.
<lifeless> 01:23 < lifeless> pitti: thanks
<lifeless> 01:23 < pitti> lifeless: in essence, you init it with a .db filename (sqlite), and keep calling check_duplicate()
<lifeless> 01:23 < lifeless> pitti: does it really need a db ?
<Morbus> i've placed it in usr/lib/python2.4/site-packages/bzrlib/plugins/example.py - should it be its own dir?
<lifeless> Morbus: well, *commit* is not seen by servers, as they generally only see people pushing
<lifeless> Morbus: so you probably want a Branch pre tip change hook
<Morbus> lifeless: how does the email plugin work then?
<Morbus> i have an the bzr-email plugin, on the branch server, sending out commit messages.
 * Morbus looks at the source.
<lifeless> Morbus: branch post tip change hook
<Morbus> so, as the plugin is written now, with pre-commit, i'd have to force all my committers to put it on their machines?
<lifeless> jam: 01:25 < pitti> lifeless: look at /usr/share/pyshared/apport/report.py, def crash_signature()
<lifeless> Morbus: yes
<Morbus> lifeless: http://bazaar.launchpad.net/%7Ebzr/bzr-email/trunk/annotate/head%3A/emailer.py
<Morbus> could you tell me what line the emailer is doing this post tip change hook thing?
<Morbus> oh, it's in http://bazaar.launchpad.net/%7Ebzr/bzr-email/trunk/annotate/head%3A/__init__.py
<Morbus> i see it. line 94.
<Morbus> lifeless: thanks for the help
<mistrynitesh> after branching out kubuntu-docs from launchpad, when I give 'bzr status' it shows most of the files under 'removed' a few under 'modified' and a few under 'unknown', but this is not the case when I see them at launchpad.net using web-interface
<lifeless> Morbus: my pleasure
<lifeless> mistrynitesh: right affter branching it shows changes ? thats unusal
<mistrynitesh> I am quite a noob at bzr
<mistrynitesh> when I give 'bzr branch lp:kubuntu-docs' it asks for the password, then downloads the files and gives the message: branched 160 revisions
<mistrynitesh> so I guess its good till then
<mgedmin> just a second ago I said to myself, happily: "bazaar rules!  I can commit these modifications I made on the production server into the local checkout and then pull them into my main branch"
<mgedmin> and then bazaar crashes with an internal error so I can't commit :(
<mgedmin> it's quite an old version (1.3.1, ubuntu hardy)
<beuno> mgedmin, it's very old, any answer will probably come with "upgrade to a newer version"
 * mgedmin has a definition of "stable software" which means "the version in the last Ubuntu LTS and the version in debian stable both work reasonably well"
 * fullermd includes "doesn't crash" in his definition   8-}
<mgedmin> that's part of "works reasonably well" in my book
 * mgedmin finds a workaround
<maxb> LTS / stable is valuable... but sometimes using years-old versions of software just isn't the right thing to do
<mgedmin> true
 * maxb glares at his company's oldstable boxen
<mgedmin> then again yak-shaving is also not always the right thing to do
<maxb> Well... PPAs rock too :-)
<mgedmin> when you're debugging a problem and you use a debugging tool and then modify a debugging tool and then use a version control system to remember the modifications, adding a ppa and upgrading the version control system just overflows my stack
<mgedmin> strangely, going on irc and talking about it doesn't
<mgedmin> I'm not complaining, mind
<mgedmin> well, okay, I am complaining ;)
<mgedmin> I just don't expect/want anybody to do anything about it
<mgedmin> the problem will be solved naturally as time passes and new debian/ubuntu lts'es come out
<fullermd> "...  so then I had to hack my new Asus motherboard to add some toggle switches, so I could toggle in a bootloader...   and THEN I finally could read the recipe I wanted in the first place."
 * awilkins used a PPA when he backported patches to MythTV
<awilkins> An automatic way of doing PPA versions just by slapping a button on a Bazaar branch page would be awesome
<awilkins> Patch, push, PPA
<froze> Hello all, new to bzr - been using svn for years, like what I see. I have a question, my apologies in advance if is redundant. Is there any way to make a bzr repo talk to an svn checkout?
<rubbs> froze: I'm not understanding your question, what are you trying to do?
<LenZ> froze: Welcome to bzr :)
<rubbs> oh yeah, welcome
<LenZ> froze: You can use bzr to talk with a remote SVN repo as if it were a SVN client, if that's what you mean.
<bialix> talk to an svn checkout... heh
<LenZ> froze: There is a bzr-svn plugin for that.
<LenZ> froze: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<awilkins> froze, You can use Bazaar on an SVN checkout if you have the bzr-svn plugin, although you may find it more useful to take a Bazaar checkout of a Bazaar branch of a branch of the SVN repo ..
<froze> sorry, got called away. I was hoping for the reverse, I have acounts on machines where svn is avail but not bzr, I have data in a bzr repo, I would like to access the bzr repo with an svn client. Tried searching, but only get accessing svn host with bzr client, not hte other way around.
<awilkins> Ah, no, I don't believe there is such a thing - you want an SVN server for Bazaar repositories
<awilkins> There is such a thing for MS TFS AFAIK, but not Bazaar
<awilkins> froze, what kind of machines are these accounts on?
<awilkins> froze, you can in principle just run Bazaar from your home folder as long as the machines meet the requirements
<froze> pretty much what I suspected. seems to me that this feature would allow for almost fully transparent migration of svn users to the bzr world.
<froze> HPC acounts on DOE and DOD machines that restrict what software you can use etc...
<awilkins> froze, Ah, so things like "noexec" set on the home folder?
<awilkins> froze, Bazaar will work from the pure Python so if you can run scripts it may be doable
<froze> no, just regulations on use. don't want to violate the terms of use as these machines are essential to my research.
<fullermd> With certain machine owners, you don't worry so much about 'noexec' on the partition, as following the policy to prevent 'exec' on YOU   :p
 * awilkins goes to catch his train
<awilkins> .quit
<froze> fullermd: is that a "In Soviet Russia..." joke reference?
<fullermd> Not explicitly, though it is the same pattern.
<LenZ> froze: Well, you could probably cheat, depending on how "advanced" your svn users are :) Rename the bzr binary to "svn" and configure it to perform checkins on the remote repo directly :)
<froze> LenZ: That would be an option on my local machines, I was looking for a way around remote site use restrictions - as I like the decentralized VCS concept.
<LenZ> froze: I'm not aware of a plugin that would make bzr mimic a SVN server.
 * froze wonders how hard that would be to code up...
 * froze slaps self in face *too much work to do already* ;-)
<fullermd> Well, you could use bzr-svn to push your bzr stuff into a svn repository, and use that as the "branch" for working from where you only have svn...
<fullermd> And keep using bzr on real bzr stuff elsewhere; just use the svn to interface.
<jelmer> LenZ: There is some initial work in bzr-svn to support a "bzr svn-serve" command
<jelmer> LenZ: it's incomplete though
<LenZ> jelmer: Awesome :)
<lifeless> jam: welcome to the warrm
<jam> :)
<lifeless> jam: http://www.handdrawngames.com/DesktopTD/Game.asp earlier versions, same author; includes multiplayer
<jam> lifeless: http://www.popcap.com/games/free/pvz/
<lifeless> jam: yah
<NfNitLoop> So Ubuntu (KDE?) has this bzr tray notification thing going on...   and I'm not quite grokking the reason for it.
<NfNitLoop> I do 'bzr commit', and it tells me... that I just committed.
<NfNitLoop> I do 'bzr pull' and it tells me that there are new revisions in my local branch.  (No, really?)  :p
<Kamping_Kaiser> sounds like something a gui has setup (iirc olive does that)
<RAOF> NfNitLoop: If there are other people on the network, and they've got bzr-avahi loaded you'll also get notifications of *their* commits.
<NfNitLoop> RAOF: Aaaaah, ok. That's cool.
<Kamping_Kaiser> that would be cool at a dedicated hackathon i can imagine it driving me insane at something like lca
<NfNitLoop> Yeah, I'm sortof all for *reducing* the number of interrupts in my workday. :p
<NfNitLoop> I already get e-mail and coworkers popping in and support requests and going down the garden path of some tangentially related bug... :p
#bzr 2010-01-28
<mtaylor> lifeless: did you have an example of using bzr-builddeb in your subunit slides for some reason?
<mtaylor> lifeless: I remember seeing a usage of bzr bd on someone's slides, and I remember it looking like a better workflow than what I currently use with bzr bd... but I didn't write it down
<dutchie> is there a way to have hooks propagated to all the repositories?
<mtaylor> dutchie: if you are asking what I think you are, then no
<mtaylor> dutchie: but it's possible that you are asking a question to which the answer is yes :)
<dutchie> well, am I?
<EdWyse_Mobile> What would you recommend as a public html frontend for bazaar in CentOS 5.4?
<Peng> EdWyse_Mobile: Loggerhead?
<EdWyse_Mobile> Thanks Peng. Loggerhead doesn't lend itself very well to centos as most of the dependencies aren't installed, plus I hate to have another service running. I'd prefer either a python cgi or php script if they exist. Any other possibilities?
<Peng> Dunno if they're maintained, but bzrweb and bzr-webserve
<Peng> Loggerhead is the main choice, though, and its dependencies aren't a big deal to install.
<spiv> I think you could run loggerhead as a CGI
<spiv> You just need to find a WSGI thing that runs as a CGI.
<igc> hi all
<Peng> That would be hilariously slow.
<Peng> And inefficient. And probably chew inodes unless you disable the caches.
<EdWyse_Mobile> Looks like redmine does what I want. It's ruby...
<lifeless> dutchie: Not sure what you are asking
<lifeless> mtaylor: no, I didn't. But  can give you a better bd workflow if you need ;)
<lifeless> poolie: if you up and want company, I'm breaking fast now
<EdWyse_Mobile> FYI, if someone wants a non-loggerhead frontend, I just installed Redmine and it's working beautifully. It's nice and snappy and it doesn't run as it's own service so it could be implemented on shared-hosting situations. It does require ruby though.
<Peng> Oh, I forgot about Redmine. Oops.
<Peng> You can do Loggerhead with FastCGI/etc. if you want to.
<Peng> just fyi
 * igc dinner
<bialix> heya bzr
<poolie> hi all
<bialix> hi poolie!
 * bialix waves at poolie :-D
<igc> hi poolie, bialix
<bialix> hi igc :-)
<jam> igc: vincent's ready for you to call
<igc> jam: it crashed because of not enough bandwidth. Maybe try again?
<igc> trying ...
<jam> igc: yeah, try again
<jam> vincent's video is a bit off
<jam> just a sec
<jam> igc: still waiting if you can try again
<igc> jam: it claims its starting
<jam> igc: I don't think its ringing on this end
<dutchie> OK, I didn't really explain what I wanted very well last night
<dutchie> what I want is to write a hook that automagically ends up being run for everyone who has a branch
<jam> igc: also, vila doesn't seem to see you as online
<igc> jam: crashed again. I'll reboot and try again
<jam> igc: k, see you in a few
<bialix> hi jam, vila_
 * vila_ waves !
<jam> morning bialix
 * bialix waves back :-D
<igc> vila: hooray!
<poolie> igc, can you answer https://answers.launchpad.net/bzr/+question/98910
<jam> lifeless: news_merge_files = NEWS
<lifeless> igc: gnight
<igc> lifeless: night
<bvk> hi, does bzr-cia plugin work over http_proxy ?
<jelmer> bvk: Hi
<jelmer> bvk: It uses the Python xmlrpclib module, I'm not sure if that uses http_proxy
<poolie> jam, can you tell https://code.launchpad.net/~ed-marsfire/bzr/giveback/+merge/18180 how to run tests easily on windows?
<rocky> i feel like i'm missing something stupid, how do i determine the active revision of the "working tree" i'm in?
<rocky> revision/versino
<rocky> *version
<keithhub> bzr revno
<fullermd> 17
<phoenixz> How can I make a checkout without generating the WT?
<phoenixz> so that basically, I end up with only the .bzr directory?
<mzz> phoenixz: branching into a no-tree repository does what you want, I think
<mzz> assuming you don't mean "checkout" in the way bzr uses the term
<phoenixz> mzz: oh crap, BRANCH! :)
<phoenixz> mzz: branch, my bad..
<mzz> although hmm, I wonder what "bzr checkout" inside a no-tree repo does
 * mzz checks
<phoenixz> mzz: I'd figure, it would generate the WT, no?
<mzz> looks like it does
<mzz> you can just branch and then bind
<mzz> or if you don't want the repo separate you can branch or checkout and then use bzr reconfigure to nuke the working tree, afaik
<phoenixz> mzz: nah, the --no-tree option was what I was looking for
<mzz> and bzr branch takes a --no-tree argument, actually. I didn't know that.
<phoenixz> mzz: no? I thought you just told me to use the --no-tree option to branch... :P
<mzz> phoenixz: no, I meant with init-repo
<mzz> which is a rather roundabout way to do what you want
<phoenixz> mzz: ah... well, branch works perfect for me! :)
<SpamapS> so. I think I did something really dumb.. its hard to explain, but it all happened on launchpad so hopefully we can figure it out...
<SpamapS> I merged in some changes from one branch..
<SpamapS> then decided I didn't want them, so to undo it, I did
<SpamapS> bzr revert -r $prev_revision
<SpamapS> then bzr commit
<SpamapS> now.. when I go to merge those changes from before.. they won't merge, I presume because they've already been merged in...
<SpamapS> so.. can I somehow tell merge to ignore those two cancelling revision?
<SpamapS> s
<NfNitLoop> bzr revert --forget-merges
<NfNitLoop> Oooh.
<NfNitLoop> you did a commit without doing --forget-merges.
<NfNitLoop> You've basically "blocked" that merge.
<SpamapS> yeah thats what I'm afraid of
<NfNitLoop> What you can do...
<NfNitLoop> is apply those changes again as a new commit.
<NfNitLoop> bzr diff -r x..y | patch -p0 (I think?)
<NfNitLoop> bzr commit
<NfNitLoop> though...
<SpamapS> so the changes I want are in lp:~coryb/gearmand/time-order ... and I want to apply them to their parent branch (lp:gearmand) .. what are my x/y values then?
<NfNitLoop> if this branch is local (i.e.: not public) and that commit wasn't long ago, you may just want to fix history.
<SpamapS> no it gets worse.. because I did this in my branch, which was merged to trunk.. so now trunk blocks the merge too.. :-P
<NfNitLoop> doh.  Yeah, fun!  :p
<SpamapS> I'm fine w/ creating a patch to do it..
<SpamapS> just don't know what the x/y should be
<NfNitLoop> make a branch of lp:gearmand.
<NfNitLoop> x = revision before your changes.  y=last revision with your changes.  assuming they're all sequential.
<Kilroo> I'm confused as all get out by this conversation.
<SpamapS> I just got a suggestion to use  diff -c # for the changes I want...
<SpamapS> Kilroo: me too :(
<Kilroo> Compared to this, my trying to figure out what a stacked bound branch would do and whether a lightweight checkout of a bound --no-trees branch is what I really want at work seems...well, ok, the stacked bound branch still seems pretty odd.
<maxb> Rather than going via a patch, I would have hoped that bzr merge -r x..y would do the job
<NfNitLoop> SpamapS: that only works if all of your changes are in one commit.
<SpamapS> hmmm lets see..
<NfNitLoop> -c N is short for -r (n-1)..n
<NfNitLoop> Oh, hmm.
<NfNitLoop> merge can supposedly take an -r ...
 * maxb looks at those branches in bzr qlog and gets very confused
<NfNitLoop> but you can't cherrypick so I'm not sure what it does.  I guess it just does the equivalent of diff|patch
<maxb> SpamapS: What are the commit messages of what you actually want to merge here?
<maxb> oh... I think I see
<SpamapS> maxb: I want the entire contents of lp:~coryb/gearmand/time-order  merged into lp:gearmand ... sans rev103 and rev104 from lp:~clint-fewbar/gearmand/tokyo
<SpamapS> so really, what I want are the changes that lp:~coryb/gearmand/time-order did, up until the last merge point w/ trunk ...
<SpamapS> *that* seems like it would be easy to get
<NfNitLoop> "the entire contents" is a bit vague for a merge.  contents after revision N is more helpful.
<NfNitLoop> or revisons X..Y
<NfNitLoop> but if you've done some merging into that branch while you were developing you may have to do your merge in a few chunks now.
<NfNitLoop> merge in x1..y1, then x2..y2
<maxb> I'm thinking something like:  bzr merge -r -4..-1 ../corybtimeorder
<NfNitLoop> around all of the holes that you don't want.
<maxb> let me test this
<SpamapS> I just want to diff that branch with trunk up to revision 316 ..
 * SpamapS is trying furiously to un-cross his eyes
<Kilroo> What if you branch from before the shenanigans happened and then merge in revision ranges around the edges of the flargle?
<Kilroo> Or is that what you're talking about already?
<SpamapS> oh that sounds like one approach.. bzr branch revno:316:lp:gearmand ?
<SpamapS> then merge into that... and use the diff as a patch?
<Kilroo> Well, I don't think that was actually what I meant, but it sounds promising.
<SpamapS> bzr branch -r before:317 lp:gearmand gearmand-trunk-b4tc
<Kilroo> I was thinking more along the lines of branch from before the screwup, then merge in the changes you actually wanted in the right order, skipping the stuff that you wish you hadn't done.
<Kilroo> And make that the new main branch. But it occurs to me that I have absolutely no clue how that would affect the trunk that already merged what you did before.
<Kilroo> I'm still very new to all this stuff.
<maxb> SpamapS: I think you want: bzr branch lp:gearmand; bzr branch lp:~coryb/gearmand/time-order; cd gearmand; bzr merge -c -3 ../time-order; (resolve conflicts, commit); bzr merge -c -1 ../time-order; (resolve conflicts, commit)
<SpamapS> maxb: will try that..
#bzr 2010-01-29
<maxb> The ideal thing to do here would be for Brian Aker to uncommit the last two merges, and redo them not merging the backout
<SpamapS> hm
<SpamapS> maxb: your solution may have, if nothing else, produced the correct diff. ;)
<maxb> Actually the other option which might have been quite neat is:
<maxb> Branch the tokyo branch just before the merge + backout
<maxb> Merge time-order into that
<maxb> Merge the result into trunk
<SpamapS> maxb: wouldn't that still result in those changes not going into trunk?
<maxb> I think the key thing is that you would have recommited the delta in the new merge revision, which wouldn't be in the current trunk
<maxb> hmm
<maxb> It doesn't do what I thought it would
<SpamapS> Flat out.. the message here is.. do not commit from a revert w/o --forget-merges ... :-P
<Kilroo> So incidentally
<SpamapS> http://doc.bazaar.canonical.com/latest/en/user-guide/undoing_mistakes.html#reverting-to-the-state-of-an-earlier-version
<SpamapS> Did it based on this ...
<maxb> --forget-merges would not have helped you
<SpamapS> no? so the moral of the story is, use uncommit
<maxb> uncommit would have been more appropriate in this use case, yes
<SpamapS> i think in reading it..
<SpamapS> I didn't want to believe that it would be that easy. ;)
<SpamapS> so used to perforce.. :-P
<Kilroo> if I do something like 'branch --bind http://subversion/repository svnbranch' in a --no-trees shared repository, and then 'checkout --lightweight svnbranch lwco', what should happen to the subversion repository when I commit in lwco?
<Kilroo> I think I generalized my paths a little more than I meant to, but...eh. Does the question even make sense?
<maxb> I would suggest that committing to a bound branch ought to commit the changes to the upstream svn repo
<Kilroo> I hope you're right.
<Kilroo> Of course, unfortunately, the repos for which it would be the most helpful if that works the way I want it to, it doesn't matter because there's a revision bzr can't look at without running out of memory.
<NfNitLoop> actually I think I saw someone in here say that that will give you an error.
<NfNitLoop> you can't commit to a branch that's bound to a bound branch.
<NfNitLoop> IIRC.
<Kilroo> But it's a lightweight checkout.
<NfNitLoop> and?  It's still a checkout (bound branch)
<NfNitLoop> oh.
<NfNitLoop> Hrmm.  Yeah, I think it still applies.
<NfNitLoop> I dunno, I'm only guessing.
<NfNitLoop> try it! :p
<Kilroo> Yeah, that's pretty much what I'm gonna have to do
<Kilroo> possibly tomorrow
<Kilroo> ...assuming that I actually have commit access to any of the subversion repos that don't have revisions that choke bzr
<NfNitLoop> SpamapS: Uncommit would have worked if you only had local history.
<NfNitLoop> but once it's out in the wild, you can't uncommit it from other people's repositories.
<NfNitLoop> so you just have to create a new revision with the same content.
<SpamapS> Yeah we were working pretty fast.. ;)
<NfNitLoop> SpamapS: so did you get it resolved?
<mtaylor> GAAAAAAAAAHHHHHHHHHHHHHHHHHHHH
<mtaylor> $ bzr branch bzr+ssh://bazaar.launchpad.net/~drizzle-developers/pkg-drizzle/trunk /home/hudson/hudson/workspace/drizzle-build-debian-packaging
<mtaylor> Branched 29 revision(s).
<mtaylor> except:
<mtaylor> on a different machine:
<mtaylor> $ bzr pull bzr+ssh://bazaar.launchpad.net/~drizzle-developers/pkg-drizzle/trunk
<mtaylor> Now on revision 37.
<mtaylor> why the crap am I seeing different versions of the branch over ssh ?
<NfNitLoop> does that machine have 8 local revisions?
<mtaylor> NfNitLoop: the top one is doing a clean branch ... and is also getting an older version of the branch
<NfNitLoop> oh.  Yeah, that's not good.
<mtaylor> wow. if I do it on the top machine _from a different account_ I get the right number of revs
<NfNitLoop> sounds like there's some load-balancing going on and maybe one of them got a stale version of the branch.
<mtaylor> it would be so great if there were a location I could pull from on my build servers after I've pushed to launchpad that would get the version I just pushed...
<NfNitLoop> host your own? :p
<mtaylor> yeah...
<maxb> mtaylor: https://code.launchpad.net/~drizzle-developers/pkg-drizzle/trunk <-- there's an error there
<Peng> mtaylor: Is one of your LP accounts in ~drizzle-developers?
<Peng> mtaylor: Oh, the stacked-on branch is owned by you?
<Peng> mtaylor: Launchpad keeps two copies of branches, one for people who can write to it, and one for people who can't. Maybe only one of them is busted.
<Peng> Or...maybe it's something completely different! :D
<mtaylor> maxb, Peng: yeah  ... also, thumper is looking in #launchpad
<Peng> Ah. :D
<igc> hi all
 * igc dentist - bbl
<lifeless> moinish
<GaryvdM> Hi igc.
<igc> hi Garyvdm
<GaryvdM> Do you want to review changes for be, or should I just push?
<GaryvdM> igc: ^ fix for bug 513138
<ubottu> Launchpad bug 513138 in bzr-explorer "Versioned filter still shows non-versioned files" [Medium,Confirmed] https://launchpad.net/bugs/513138
<igc> garyvdm: just push is fine
<igc> you know the qbrowse widget better than I :-)
<GaryvdM> Ok - cool.
<GaryvdM> igc: done. I think you are going to have a smack your forehead moment when you see the fix :-)
<igc> thanks garyvdm: consider forehead suitably smacked :-)
<igc> on the first bit at least ...
<igc> on the second bit, what's the reason for it?
<igc> garyvdm: ^
<igc> switching pages perhaps?
<GaryvdM> igc: The default in qbrowse is to show versioned and non versioned, but not ignored.
<GaryvdM> igc: So in be, we need to set it to whatever the combo defaults to
<GaryvdM> because it is different to the qbrowse default.
<igc> ah - ok
<GaryvdM> ok - bye
 * igc dinner
<jam1> morning igc
<igc> hi jam
<igc>   File "./check-hottest.py", line 143, in main
<igc>     output_stream = ui.ui_factory.make_output_stream(encoding_type='exact')
<igc> AttributeError: 'TextUIFactory' object has no attribute 'make_output_stream'
<igc> jam: ^^^
<igc> any ideas?
<Peng> I think that's been fixed.
<Peng> bzrlib.ui.text.TextUIFactory.make_output_stream certainly exists for me.
 * Peng shrugs
<Peng> Looks like a new feature, lp:bzr r4880 (2009-12-09)/.
<lifeless> igc: run with 2.1
<jam> igc: right, make_output_stream is a 2.1-ism, probably your system bzrlib is 2.0
<igc> jam: it is. I have 2.2 on my path but that doesn't seem enough ...
<jam> igc: in PYTHONPATH ?
<igc> no, just PATH
<jam> igc: right, it has to be in PYTHONPATH or we won't use that bzrlib
<lifeless> igc: PATH doesn't a ffect loading of python modul,es
<jam> export PYTHONPATH=/home/igc/dev/bzr/bzr.dev
<igc> jam, lifeless: better now thanks
<napster> t
<napster> Hello everyone. I'm new to bazaar. Can anyone help me to learn the basics of bzr...
 * jam looks around to see who the current LOSA is
<mthaddon> o/
<jam> hey mthaddon, I had to bump a tag, and need to get that value propagated through pqm
<jam> it requires running some "bzr pull --overwrite" on a couple of branches
<jam> on the pqm machine, going to the 2.1 branch and running: bzr pull --overwrite http://bazaar.launchpad.net/~jameinel/bzr/2.1.0rc1-dev
<jam> and then pulling that into the branch on launchpad itself
<jam> which may just be "bzr push --overwrite lp:bzr" from that same directory
<lifeless> igc: yo?
<igc> lifeless: hi
<lifeless> want to skype up?
<lifeless> or happy as you are ? :)
<igc> lifeless: absolutely
<lifeless> igc: vila will be a few minutes
<igc> lifeless: ready on my end
<lifeless> vila: my flighttomorrow is at  07:40 CET
<lifeless> vila: how long will a cab to the airport take ?
<igc> lifeless: bug #513225
<ubottu> Launchpad bug 513225 in launchpad-registry "upstreamreport missing branch icon for vlc" [Undecided,Incomplete] https://launchpad.net/bugs/513225
<napster> I've created a project in launchpad and have bzr installed on my system. The project folder with source code is in my /home/Public folder. What is the next step to initiate the trunk?
<maxb> napster: The quick answer?  bzr init; bzr add; bzr commit -m "Initial revision."   At some point you should plan on reading the docs to learn how a shared repository can make branching easier
<maxb> s/easier/faster/
<napster> maxb, I don't get :(  I'm really new to bazaar. Can you explain a bit?
<maxb> What in particular would you like more detail on?
<napster> maxb, I've just created a project in launchpad. I think there should be some url in the init commands, Am I right?
<Peng> napster: You need to create your branch locally. Then you can push it to Launchpad, bzr lp-login (if necessary) and "bzr push lp:~whatever"
<napster> ok, now it seems ok...
<rubbs> napster: when you created a project on LP you made a place for your local repo to go, you need to create your project localy first and then do a bzr push lp:~directory/to/project
<rubbs> this will "push" your repo up do LP, that will start the repo right on LP
<napster> rubbs, Then I'll get a remote repo right?
<rubbs> no, DCVS's have remote and local repos, you do all your work on your local repo, and when you "push" you more or less overwrite the remote repo (although that's not a good word, maybe update is better)
<rubbs> the idea is to never be directly connected to a remote repo unless you are updating.
<rubbs> that way you can do work away from a network and at the same time as someone else.
<rubbs> napster: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
<rubbs> it talks about mercurial, but the concepts are very similar to bzr
<rubbs> that's the article that helped me understand how bzr, git, and mercurial works.
<napster> rubbs, tnx mate :)
<rubbs> np
<napster> Path(s) are not versioned: I see this error when I've added some files and dir to my already inited,added project directory
<napster> How to fix this?
<rubbs> do you just want everything in your repo to be added?
<rubbs> if so you can just run bzr add in the root of your repo, it will add everything in for you
<rubbs> napster: this is another decent tutorial to help more specifically with bzr: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/tutorial.html
<rubbs> http://doc.bazaar.canonical.com/en/ <- this can usually help you out too.
<rubbs> and as always, if you have questions, we are more than willing to help here too :D
<napster> rubbs, Actually how to add a directory to my project dir?
<rubbs> so you have a directory already there and you want it tracked? or you want to add a directory that isn't there yet?
<napster> rubbs, second one...
<rubbs> ah, that's a little easier. while you are in the project dir, do this "bzr mkdir ./dirname"
<napster> rubbs, But i've created one using "mkdir /nc/img" and then moved some files to it...!
<Peng> I love 2a over nosmart+http. Of course you need to make a dozen 64k requests to figure out you have nothing to pull!
<Peng> </semi-whiny>
<rubbs> napster: oh. so you have the new dir img and you want bzr to add it to the project
<napster> rubbs, yes
<rubbs> is there any files/directories in your project you *don't* want added?
<napster> rubbs, the file inside /img too
<napster> rubbs, Nothin "not to be added"
<rubbs> ok, easiest is to just be in your project and do "bzr add" that will automatically recurse and add every file that isn't already added.
<rubbs> also, you can say "bzr help add" to see what kinds of things add can do
<napster> rubbs, done, but error exists...
<rubbs> hmm. that's strange. you get the "Path(s) not versioned?" what version of bzr are you running (first line of output from "bzr version")
<napster> rubbs, Bazaar (bzr) 2.0.2
<rubbs> napster. have you commited since you ran bzr init?
<napster> rubbs, that means run bzr commint?
<napster> rubbs, that means run bzr commit?
<rubbs> yes
<napster> the error shown up when i try to commit
<napster> bzr commit "Added some icons"
<napster> Committing to: /home/napster/Public/netchat/
<napster> aborting commit write group: PathsNotVersionedError(Path(s) are not versioned: "Added some icons")
<napster> bzr: ERROR: Path(s) are not versioned: "Added some icons"
<napster> ^^ pls take a look
<rubbs> oh... bzr needs the -m flag when commiting. Try this "bzr commit -m 'Added some icons'"
<napster> rubbs, ohhh... I'm really sorry...
<rubbs> no problem. it's all about learning
<napster> rubbs, :)
<rubbs> best way to learn is to make mistakes
<rubbs> ;)
<Peng> Unless your mistake is so bad that you die. Then other people learn, but it's not so good for you.
<napster> rubbs, ;)
<rubbs> Peng: ha... I suppose, I'll add that caveat next time I say that.
<rubbs> napster: did that help?
<jml> hey sprinters
<jml> any of you know where bzr-builder gets the sourcepackage name from?
<napster> rubbs, Absolutly
<rubbs> napster: great!
<napster> rubbs, I didn't say thanks because I need your help again.... :)
<rubbs> haha, no problem, what's up?
<lifeless> jml: the changelog
<jml> lifeless, thanks.
<lifeless> de nada
<napster> rubbs, I'm really new to all such things. I need a software which should be maintained as a opensource project.
<napster> rubbs, :)
<rubbs> are you atempting to make your own from scratch, or are you trying to contribute to an open source project that has already been started?
<napster> rubbs, Pls add my nick when you talk :) ... I'm trying to create on from scratch. I searched in launchpad, but can see similar projects in java
<rubbs> napster: sorry forgot to add your name earlier. Have you read the launchpad help docs? They are pretty helpful on how to launch and maintain a project.
<napster> rubbs, I'm on the help/tutorial pages for a while :)...
<napster> rubbs, Is it harder to post a project on lp, if I've already a bzr branch on my local system?
<Peng> No?
<Peng> Wait, what are we talking about?
<napster> Peng, About hosting a new project
<rubbs> napster: the way to post your project is to set up the project and then do "bzr push lp:~/username/projectname/branchname"
<lifeless> ~username
<rubbs> er... should be ~username not ~/username
<rubbs> thanks lifeless
<napster> rubbs, and the branchname?
<napster> rubbs, may be main?
<Peng> Well, you could name it lp:~username/projectname/rubbs_is_awesome if you wanted to, but something like "main" or "trunk" is common.
<napster> Peng, Thats nice :)
<rubbs> Peng napster naming something rubbs_is_awesome is most definately not recommended ;), mostly because it wouldn't be true.
<napster> rubbs, lol
<Peng> Since when have software products had accurate names? :D
<rubbs> Peng: good point
<napster> I've tried to push my local branch to lp, but seems happened nothing...! What to do??
<Peng> napster: What makes you think nothing happened?
<Peng> napster: Pastebin the command you ran and its output.
<napster> Peng, http://pastebin.com/m76cdcacd
<napster> Peng, I can't see a branch named main in the launchpad site :(
<Peng> napster: It exists: https://code.launchpad.net/~subinsebastien-gmail/netchat/main
<napster> Peng, Why its not trunk?
<Peng> napster: What do you mean?
<napster> Its not the trunk branch right?
<Peng> napster: If you want it to be set as the development focus branch or something, that's a separate step on LP's website.
<napster> Peng, yes, how?
<Peng> No idea! Should be pretty obvious.
<chrisboom> ok. using windows bazaar
<chrisboom> im a idiot, btw
<chrisboom> im getting this message you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again
<chrisboom> what do i do?
<napster> Peng, I've set it. If we have only one branch, a search would return it and suggest to set as development focus branch
<lifeless> mtaylor: pandora .98 in testing
<napster> Why there should be a number of branches? What is the purposes?
<MattCampbell> What's the status of nested tree support in bzr?  I mean something similar to svn's externals.
<MattCampbell> I'd even be happy with something analogous to the Chromium project's depot tools (which support svn and git).
<napster> rubbs, Peng lifeless Thanks a lot for you help. I think I'm covering the first learning curve and will continue... tnx once agin... :) see you later....
<rubbs> napster: goog luck. glad to have helped
<napster> rubbs, see you..
<rubbs> chrisboom: are you using bzr via the windows commandline?
<VSpike> Hi.  I have project tree, and I want to split a chunk of it out into a new, related project ...
<chrisboom> nope
<chrisboom> im using bazaar explorer
<chrisboom> think we need a good tutorial out there for using explorer to simply log in to a launchpad id, set up ssh and start going
<VSpike> Logically it's a sub-tree, in that the first project will depend it, but it can't reside in a directory below the first project because of restrictions of the dev env.
<VSpike> My questions are, what is the status of Nested Trees, and is there a way to move the files into a new project but keep their history from the first project?
<rubbs> chrisboom: did you do anything to the .bzr folder or name anything .bzr?
<chrisboom> how do i set up ssh on windows?
<rubbs> VSpike: I'm not entirely sure of the status of Nested trees, but you could look here: http://wiki.bazaar.canonical.com/NestedTreesDesign that might help
<rubbs> chrisboom: do you have putty installed?
<chrisboom> nope
<VSpike> I already have main/lib and main/web, for example.. with main/lib being a component sub-project of main/web .. but I just handle the relationship manually
<rubbs> chrisboom: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html click on the installer
<chrisboom> ok, downloading that
<chrisboom> now what?
<rubbs> chrisboom: it should install putty, and pagent.
<rubbs> chrisboom: you need to run puttygen
<chrisboom> cool
<rubbs> puttygen will create an ssh key for you
<chrisboom> which i enter into launchpad?
<rubbs> chrisboom: yes
<rubbs> chrisboom: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<chrisboom> ok, added the public key
<rubbs> chrisboom: ok, then open your key with pagent
<rubbs> pagent will have a small icon in the systray
<MattCampbell> I'm just starting to use bzr (and version control in general) for a project which has many dependencies on open-source packages, some of which I've modified for this project and many of which I haven't.  It seems that importing the source trees for these packages into the project's main repository is a suboptimal solution, even though some other projects (e.g. Mozilla) do that.
<MattCampbell> If I were using svn, I'd use externals, at least for the third-party packages that have svn repositories.
<rubbs> chrisboom: when pagent has the ssh key loaded, you can use bzr with ssh.
<chrisboom> kl
<chrisboom> it worked!
<rubbs> MattCampbell: there are lots of requests for externals, but IIRC there is no support for externals in bzr.
<rubbs> chrisboom: awesome
<rubbs> MattCampbell: I could be wrong.
<MattCampbell> Any suggestions in the meantime?
<VSpike> MattCampbell: see the NestedTrees link above - it's supposed to be bzr's answer to externals, I believe
<rubbs> MattCampbell: I'm not sure, but i think that the nested trees is supposed to help (I know they are getting closer to full support).
<VSpike> Just trying to ascertain the status, because AFAICT that is a design document, and doesn't explain status
<rubbs> MattCampbell: VSpike  IIRC bzr explorer (the beta version) has some rudimentary way of doing it.
<rubbs> I'm not sure though
<MattCampbell> So that's only in the GUI tool right now?
<rubbs> I've gtg to lunch, but keep asking questions, someone here is bound to help you ;)
<rubbs> MattCampbell: I think so, but I'm unsure. This is really not my area of expertise
<MattCampbell> OK, I see two tools that implement something like nested trees, config-manager and bzr-scmproj.  It seems that bzr-scmproj is more actively developed.  So does anyone here know of any advantages of config-manager?
<pynonoir> Hi. I'm still trying to convert my svn repository to bzr branches. However the svn repository layout is not a classical one and I think it can't be done with either svn2bzr.py or fast-export-from-svn
<mzz> pynonoir: I'd expect bzr-svn (the foreign branch support) to be your best choice at this time
<pynonoir> So first I would like to be sure that it can't be done
<mzz> pynonoir: but I haven't looked into this recently, so an even better choice may be available
<mzz> oh wait, *not* a classical one
 * mzz cannot read
<pynonoir> no pb
<mzz> hmm, at some point the repository layout was pluggable
<mzz> I don't know if that went anywhere though.
<mzz> I'd stick around in here and wait for someone to show up who knows about that
<pynonoir> The last time I tried bzr-svn was not able to import the repo
<pynonoir> Then I had other ideas. One of them would be to use mercurial as an intermediate
<pynonoir> But I'm not sure it would work better, at least the hg-->bzr part
<pynonoir> I'm also looking for some informations about bzr internals, at least to know if there is in theroy a working solution for me
<pynonoir> for example, how does bzr knows that two bzr branches share a common history before doing a merge
<mzz> bzr revisions all have an internal (globally unique) id. They also know the id (or ids) of their parent.
<mzz> bzr-svn works by constructing fixed bzr revision ids for a given svn repository url and revision number, basically.
<mzz> so if you convert the same svn repo more than once using bzr-svn you get the same revision ids, so bzr knows they're actually the same branch
<mzz> when I looked into bzr-svn in the past you could modify the repository layout it assumed, but I don't know if it still supports that
<pynonoir> then would it be possible to convert each branch of a svn repo, one after another ?
<mzz> (doing that would affect the revision ids it generates)
<mzz> you don't normally want that, because you'd lose the relation between the revisions (those parent ids I mentioned)
<mzz> err, relation between the *branches*
<pynonoir> that's what I was afraid of
<mzz> I suspect bzr-svn can be hacked up to do this, but I don't know how hard that would be, or if there is an easier solution.
<pynonoir> ok, I note bzr-svn in my todo list :)
<pynonoir> mzz: so you think that the relations between branches must be analyzed at once, while creating a new bzr shared repository for all imported branches ?
<mzz> pynonoir: bzr-svn can handle this (for multiple repository layouts, last time I checked, although possibly not for yours)
<pynonoir> Ok, I'm going to check right now. Thanks :)
<mzz> it can do branches separately, but if the layout assumptions it makes change you want the generated ids to change too, or you get insane conflicting branches
<gerard_> hey
<rubbs> hey
<Peng> hey
<Peng_> hey
<gerard_> anything new for bug #113809?
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<gerard_> I'm beginning to think the whole update command is in need of a redesign/rewrite
<gerard_> it sometimes changes the repo I'm updating from
<gerard_> also, the fact that "bzr update; bzr revert" loses all local changes is REALLY counterintuitive
<gerard_> it should go back to the situation before the update in my opinion
<gerard_> also, "bzr pull" on a bound branch should not pull from the saved location but from the location of the bound branch
<NfNitLoop> gerard_: yikes!  How would it change the repo you're updating from?
<NfNitLoop> gerard_: "bzr revert" is defined as reverting your working tree... I don't find it very counterintuitive.  It's the same as in SVN and other SCMs.
<gerard_> so what command should I use if I mess up fixing a conflict after update?
<gerard_> it's really scary to have no backup
<NfNitLoop> *nod*   That's one of the weak points of that workflow.
<NfNitLoop> If you do development in a standalone branch, you can commit first.  Then merge.
<NfNitLoop> and if your merge goes poorly, you can revert to your last commit.
<NfNitLoop> The latter workflow is how distributed development goes.  The prior is just allowing the same workflow that people are used to in SVN.
<NfNitLoop> (You have the same problem in SVN.)
<gerard_> you say I can "revert to your last commit"
<gerard_> don't think so
<gerard_> the revert will make my branch a copy of the one I updated from
<gerard_> I'm using the centralized with local commits
<gerard_> workflow
<gerard_> though I'm beginning to wonder if anyone else does
<NfNitLoop> I do.
<gerard_> because some things are buggy as hell
<gerard_> if you have some local commits and local changes update will mess up severely
<NfNitLoop> Oh, hrmm.
<NfNitLoop> Yeah, I try to avoid that case.   What does it do?
<NfNitLoop> I would assume it tells you that you've diverged from the parent branch?
<gerard_> no, you get conflicts with your own work
<gerard_> it's really confusing
<gerard_> that's the bug #113809 I mentioned
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<gerard_> it will do two merges, and if the first one is a conflict it will then finds conflicts in the conflicts
<gerard_> you end up with files like file.moved.moved
<gerard_> trying to fix that case now
<gerard_> it's going ok but one of the testcases doesn't want to cooperate
<gerard_> the first merge it is supposed to do doesnt work in that case or something
<gerard_> I'm beginning to expect a bug in the merge code
<NfNitLoop> by "it will do two merges" do you mean "it will do a merge for each locally-committed revision"?
<NfNitLoop> Because that's what I would expect.
<gerard_> NfNitLoop: it will merge your local changes into the master and merge that into your local commits
<gerard_> if your local changes conflict with the master, the conflicts will conflict with your local commits
<gerard_> I'm trying to swap the order of merges around
<gerard_> so it should first merge your local changes with your local commits (the simplest merge possible) and then merge that into the master
<gerard_> the reason for the first merge is that instead of "local commits" you should be able to read "the commits on the branch this lightweight is bound to"
<hersonls> Hi, i need export a revision with python lib bzrlib
<hersonls> but i need have a repo Tree
<hersonls> i import from bzrlib import tree
<hersonls> but i dont know how create a Tree object
<gerard_> hersonls: is that the ultimate problem you want to solve?
<hersonls> someone know?
<gerard_> maybe you can tell us what you want to achieve in the end?
<hersonls> ok
<hersonls> i want export a revision like "bzr export . /tmp/project" with python
<gerard_> ah
<hersonls> tanks, i found!
<hersonls> from bzrlib.workingtree import WorkingTree; w = WorkingTree.open('.');
<hersonls> :)
<gerard_> ah, good job :)
<gerard_> you could try looking in the tests/blackbox dir of bzr
<gerard_> for lots of small tests/examples
<hersonls> its work! :)
<hersonls> from bzrlib.export import export; export(w, '/tmp/test');
<hersonls> great!
<gerard_> hehe
<gerard_> yeah, I like bzrlib, really easy to use
<MattCampbell> I've read about vendor branches in cvs and svn, a way to version-control an upstream package that has no public version control, and more importantly, one's modifications to that package.  Is there a similar best practice for bzr?
<MattCampbell> There are even scripts to help maintain such branches for other VCSes, e.g. John Goerzen's vcs-load-dirs scripts, which support hg and git but not bzr.
<gerard_> MattCampbell: have a "clean" branch with the upstream code and a private one?
<gerard_> and them merge from the clean one into the private?
<MattCampbell> Right.  Now when a new upstream version comes out, how do I update the clean branch from the upstream archive?
<gerard_> just untar the new version over the old one and then commit
<gerard_> sometimes merge.merge_inner doesn't merge anything?
<gerard_> graph.is_ancestor doesn't work?
<pynonoir> Hi again. I'm playing with bzr svn-import (from bzr-svn, right ?). I still have some problems importing the svn repository with my not-so-standard layout
<pynonoir> I've edited ~/.bazaar/subversion.conf, and added a layout for the repository
<mzz> oh hey, I thought that'd be harder than editing a config file
<mzz> shows how out of date I am
<pynonoir> :)
<pynonoir> mzz, it seems so be harder, because I get nothing interesting with that
<mzz> strange.
<pynonoir> so either my config file is wrong, or it works but I don't get what I expect
<pynonoir> I have set-up a small svn repository with the same layout
<pynonoir> to do some tests on 9 revisions only
<pynonoir> I can provide the url if someone has the courage to try...
<pynonoir> the repo should be located here:    svn://ion.wizzi.net/sandbox
<pynonoir> maybe I need to send my question to bzr-svn guys...
<hersonls> someone know how i can get the revision number of working tree with bzrlib?
<gerard_> hersonls: maybe self.get_parent_ids()[0] ?
<gerard_> ahh, I think I fixed the update performs two merges bug
<gerard_> it now performs the merges in a logical order, and also stops if the first merge has a conflict
<gerard_> running all selftests now
<hersonls> gerard_, return the 20100114122424-xzieq8r43ttzo8lg
<hersonls> gerard_, i want some like  "revno: 4"
<gerard_> hersonls: Branch.get_revision_id_to_revno_map ?
<hersonls> gerard_, but, i have the WorkingTree object, not a Branch
<gerard_> workingtree.branch ?
<hersonls> gerard_, tanks man
<hersonls> gerard_, but return a dicionary, what the way to get only current revn?
<gerard_> there may be a shorter way, but you could try workingtree.branch.get_revision_id_to_revno_map[workingtree.get_parent_ids()[0]]
<gerard_> it really looks like there should be a better way
<gerard_> I'll check the source again
<hersonls> i think in this
<hersonls> and think if have another way, but tanks
<gerard_> workingtree.get_root_id ?
<gerard_> gmm
<gerard_> workingtree.branch.revision_id_to_revno
<gerard_> :p
<gerard_> what's "bzr update -r" supposed to do?
<IslandUsurper> is that a new option for update?
<IslandUsurper> it's not in 2.0.2
<rubbs> I don't see any help on the command with an -r option
<gerard_> someone added it, and I'm rewriting the update command
<gerard_> I think it still works, at least the tests do
<gerard_> I'll just hope the tests are good enough then
<gerard_> what would update -r do with local changes?
<IslandUsurper> I would expect it to try to merge, like regular update. Which version you're updating to shouldn't matter
<IslandUsurper> that's assuming, of course, that update -r tells it to get changes up to the specified revision
<gerard_> regular update is a monster
<gerard_> it's not just an inverted merge
<IslandUsurper> hmm, are these local changes committed or not?
<gerard_> not committed
<IslandUsurper> never mind, they shouldn't be
<IslandUsurper> from a user's perspective, I would still expect update to deal with local changes the same way, with or without -r set
<gerard_> true
<gerard_> it is a little weird though
<gerard_> imagine a master with an additional commit, a bound branch with an additional local commit, and a lightweight checkout of that branch
<gerard_> what would update -r2 do?
<gerard_> (from the lightweight)
<IslandUsurper> (Disclaimer: I've not looked very hard into bzr's code.)
<gerard_> (Disclaimer: Me neither)
<IslandUsurper> fair enough
<gerard_> what is most important is what you would expect
<IslandUsurper> update still looks like a pull or a merge to me
<gerard_> the description of update is "prepares your working tree for a commit to the master"
<gerard_> or something very close
<gerard_> so the final goal is to have something that has both your latest changes and those from master
<IslandUsurper> for local commits, though, they are temporarily uncommitted until you're back in sync with the master
<gerard_> are they?
<IslandUsurper> conceptually
<IslandUsurper> remember, I haven't really looked at the code
<IslandUsurper> but the end result is that your local commits end up in a pending merge into the latest changes from master
<gerard_> I'd expect any uncommitted changes to turn into some invisible local commit, and then a merge would happen between that commit and the master
<gerard_> IslandUsurper: right
<IslandUsurper> and no matter how messy the merge gets, the working tree is passed to the lightweight checkout
<gerard_> yeah
<gerard_> and what happens to any "new" commits on the bound branch?
<IslandUsurper> they look like a pending merge too, with the uncommitted changes being the tip of that merge
<gerard_> like I have it working now is that first the new changes from the branch are merged with your local changes (stop here if there are any conflicts) and then the changes from master are merged into that
<pynonoir> mzz, the import from the svn repo seems to work now !
<mzz> pynonoir: ah, good. What fixed it?
<pynonoir> mzz: with bzr-svn. You (almost) saved my life
<IslandUsurper> gerard_, there ought not be any conflict between local commits and the changed working tree
<gerard_> IslandUsurper: that's right
<pynonoir> mzz: not sure what fixed it. I think I may have typed too many white spaces in the subversion.conf layout
<gerard_> anyway, it seems we conceptually agree what bzr update should do
<gerard_> I'll have something to eat, and clean up my patch that should prevent uncommitted local changes from conflicting with your local commits
<IslandUsurper> yeah. ok
<pynonoir> mzz: I still need to check some thinks on the real svn repo, but looks good.   svn merge are not taken into account, but I can live with that
<pynonoir> mzz: one last question. svn2bzr allowed to define a mapping between svn commiter logins and a bzr-style author names with e-mails. I can't find this option with svn-import
<mzz> pynonoir: sorry, I'd have to dig through the documentation, and I'm already doing something else
<pynonoir> mzz: ok, I'll try harder to find it :)
<pynonoir> mzz: thanks again
<mzz> np
<magcius> I accidentally tried to do "bzr up" to pull
<magcius> And I got a confusing message.
<mzz> I'd expect "Working tree is up to date", but I might be confused.
<magcius> "Tree is up to date at revision 11848."
<mzz> or yes, that.
<mzz> apparently I've been brainwashed enough that I don't find it confusing.
<magcius> Could you make it say, if nothing changed, "If you meant to pull new revisions, do bzr pull"
<magcius> Because I thought it meant there was no new revisions./
<mzz> and/or mention what branch it's up to date relative to?
<magcius> Huh?
<magcius> Sorry, I don't use bazaar, I just deal with it.
<mzz> if it had mentioned what branch it was checking you would've noticed that wasn't the branch you meant to pull from
<magcius> Oh. Does "branch" mean the same thing as "repository"?
<mzz> no
<magcius> I'm very confused by what "branch" means in bzr.
<mzz> "repositories" aren't interesting in bzr land other than as an (important!) optimization.
<magcius> So a "branch" in bzr is a "repository" in git?
<mzz> well, I'm very confused by what pretty much anything means in git :)
<mzz> but that wouldn't surprise me.
<magcius> repository is a holder for objects.
<mzz> you can stick (even unrelated) branches in a repository and they'll share storage
<magcius> Then what are 'stacked branches'?
<magcius> What do you call those as shorthand?
<mzz> if you don't use a shared repository operations like "bzr branch path/to/some/local/branch" have to copy all history
<magcius> bzr's overloading of the word "branch" confuses me.
<mzz> I haven't actually used stacked branches other than very indirectly through launchpad
<mzz> so I don't call them anything, sorry.
<magcius> Alright.
<mzz> there's documentation on what's what, but if you're like me you might find it useful to look at "bzr info" for some things and peek in the .bzr directory.
<mzz> a branch really isn't much, just a revision id (identifying the head revision), tags, and a few settings
<magcius> And the branch I would be up'ing from would be . and the thing I'm trying to pull from is the remote?
<mzz> I'm assuming you got the branch you're working on through "bzr branch http://blah", and you didn't explicitly set up a repository?
<mzz> (I can't answer your question until you either answer mine or run "bzr info" for me :)
<mzz> "bzr up" updates the working tree from its branch, but if you got the branch from "bzr branch" the working tree and branch are both sitting right in ".", and you have to do something weird to get the branch ahead of the working tree.
<mzz> so yeah, "bzr up" doesn't do anything interesting, and your suggestion to make that message better sounds good to me.
<magcius> mzz, alright
<mtaylor> bzr up is only really useful if you're doing lightweight checkouts
<mzz> there are some weird situations where it's useful, like if you managed to push to this branch through a protocol that didn't update the working tree.
<mzz> but that's not all that common.
<NfNitLoop> isn't it?  push over ssh or sftp doesn't update the WC.
<NfNitLoop> and that's how I always push.
<maxb> Usually in such circumstances, you push to a branch without a WT at all
<NfNitLoop> touche.
<mzz> exactly.
<mzz> I forgot if it even lets you push if there is a wt, but I'm pretty sure it warns about leaving the wt stale if it does
<NfNitLoop> that may be new.
<NfNitLoop> I don't think it used to.
#bzr 2010-01-30
<wgrant> I recall seeing it a couple of years ago, so it has been around for a while.
<keithy> any progress on nested trees
<keithy> why is this site here http://whybzrisbetterthanx.github.com/
<NfNitLoop> because the people who run .github.com think git is better?
<pynonoir> Hi. Is there a way to do a fast-export | filter | fast-import of a bzr branch to a bzr branch without modifying internal revisions ids (to keep to possibility to do merges) ?
<thumper> pynonoir: can I ask why you want to?
<lifeless> time to fly
 * lifeless flap flap flaps
<pynonoir> thumper: I'm trying to import a svn repo since last week. Thanks to mzz, I found a solution involving "bzr svn-import"
<thumper> ok
<thumper> cool
<pynonoir> thumper: but commiter names are still svn login names
<thumper> ah, yes
<pynonoir> and I would like to replace them by real e-mail adresses
<thumper> right, that I don't know
<thumper> you probably want to poke jelmer
<thumper> there may be some magic you could feed into bzr-svn to provide that info
<pynonoir> yes I wrote an "answer" question on launchpad
<pynonoir> the other possibility would have been to export the branches, rewrite the commiter name, and then export it back to bzr
<pynonoir> but then I think it will make the different branches somewhat incompatible
<thumper> pynonoir: yeah, you don't want to revisions with the same id pointing to different data
<thumper> pynonoir: best to get the info in when the revisions are being created
<pynonoir> thumper, sure, I will wait either jelmer or for an answer on launchpad
<thumper> ok, cool
<pynonoir> thanks
<mzz> heh, he's giving me way more credit than I deserve, all I did was wave vaguely in the direction of bzr-svn
<pynonoir> mzz, I tried for more than a week with svn2bzr. Then I began to read and modify the source code of fast-export-from-svn. So ni, you saved me a lot of time
<gerard_> hey
<napster> How to list all files tracked by bzr?
<Peng> napster: bzr inventory
<Peng> napster: Also probably some permutation of "bzr ls"
<napster> Peng tnx :)
<MattCampbell> Is there an RPM package of bzr 2.0 for RHEL/CentOS 5?
<mkanat> MattCampbell: Not that I know of, but you can rebuild the Fedora one.
<mkanat> MattCampbell: That's what I do.
<mkanat> MattCampbell: Oh actually, wait, nevermind, I think it's in rpmforge now.
<MattCampbell> I think I'd rather build from source than mix RPM repositories (am already using EPEL).
<MattCampbell> though really, I'd rather run Ubuntu on these servers.
<mkanat> MattCampbell: You could use yum-priorities.
<MattCampbell> already got the SRPM, running mock now
<mkanat> Okay.
<mkanat> You might have to do "rpm -i --nomd5" on the srpm if it doesn't work.
<pynonoir> jelmer: Hi. Can svn-import replace subversion login names by e-mails during svn-import ?
<Peng> bzr-fastimport certainly can...
<pynonoir> Peng: from what I tested fast-export-from-svn cannot export branches
<pynonoir> maybe I'm wrong
<jelmer> pynonoir, hi
<jelmer> pynonoir, no, replacing authors is not supported (and cannot be supported)
<jelmer> it would break referential integrity
<jelmer> the only way to support that would be to support changing committers in bzr revisions
<pynonoir> then why bzr-fastimport can ?
<jelmer> pynonoir, it doesn't do generate deterministic revisions
<jelmer> s/do//
<pynonoir> jelmer, I have modified bzr-svn to do this and imported my old svn repo. The result looks fine. What are the risks ?
<pynonoir> I thought it was an option that I was not able to find. So I looked at "committer:" in the source files and replaced the commiter by a new string
<jelmer> pynonoir: The risk is repository corruption
<jelmer> Bazaar assumes that revisions that are referred to by the same revision id have the same contents
<jelmer> please do not distribute any revisions created by your modified bzr-svn
<pynonoir> I wasn't going to distribute that ugly hack
<Kilroo> What's the hack do?
<Kilroo> Oh, something to do with committer strings. Ok.
<pynonoir> Kilroo, it replaces svn commiters logins by e-mails for bzr
<Kilroo> Ah.
<Kilroo> I need to figure out the best way to watch for progress on the out of memory issue...
<zubin71> hi i am currently attempting a bzr pull and i am behind a proxy server; how do i do it? it shows "connection timed out" when i try
<zubin71> please help
<jelmer> pynonoir: ideally bazaar should support a way to annotate a commit with a new committer or commit message
<pynonoir> jelmer: ok so until this is possible the only thing to do now is to import my branches, keep the old svn logins and continue from that ?
<jelmer> pynonoir: yes, unfortunately. When support for updating the committer and commit message is added to Bazaar you should be able to update the existing revisions.
<pynonoir> jelmer: ok, thanks for the advices. Importing branches was my top priority and that part is solved. Changing commiter strings was just a cosmetic issue.
<mgedmin> so, can I see the history of two related branches at once with bzr viz?
<unic0rn> hi
<unic0rn> i'm using bzr 2.0.4 and i have a small issue with my branch sitting on vfat partition
<unic0rn> i've just moved back to linux, and if i'll copy whole branch directory to my home dir, it works fine
<unic0rn> but if i'll create symlink to that directory in my homedir, bzr status displays all files as modified, and i cannot commit
<unic0rn> any ideas?
<unic0rn> bzr: ERROR: [Errno 1] Operation not permitted: '/fll/sda4/devel/as3/projects/tiramisu/.bzr/repository/upload/a0y830g7imodklgnfkpm.pack
<unic0rn> that's what i'm getting
<pynonoir> does vfat support symlink ?
<unic0rn> no, but that's a symlink on ext2 partition mounted from loop
<unic0rn> pointing to a directory on vfat partition
<unic0rn> which i have write access to
<unic0rn> file from the error message gets created, but it has zero length
<pynonoir> then you need an answer from one of the bzr expert here :)
<unic0rn> i think it somehow gets confused by the fact that it's inside /home/uni/tiramisu but some system call probably returns full path to vfat partition as /fll/sda4/...
<unic0rn> because bzr info returns parent branch as being /home/uni/eris when i'll copy whole directory
<unic0rn> but when i'm inside symlinked /home/uni/tiramisu, parent branch is being returned as /fll/sda4/...
<unic0rn> hmm
<unic0rn> lemme check something
<unic0rn> same error if i'll cd /fll/sda4/... and try to commit there.
<pynonoir> i was going to ask this...
<unic0rn> the only difference i can see are +x flags on all files on vfat
<unic0rn> perhaps that's an issue
<unic0rn> no idea
<unic0rn> it shouldn't matter i think
<pynonoir> so it is a linux bzr branch (don't know if branches structures are system dependant, I guess they are not)
<pynonoir> you moved it on a vfat external hard drive
<pynonoir> and then you cannot work directly on it
<unic0rn> nope. it's a branch created under windows
<unic0rn> and now i've switched OS to linux but i'm still keeping my data on vfat partition, as a matter of fact, linux boots from image files on vfat as well
<unic0rn> that's why i would prefer to use files there directly rather than to copy them to my homedir on ext2, which resides inside image file
<unic0rn> and when i copy that branch created under windows to my homedir, it works
<unic0rn> but from within vfat partition mounted under linux, it doesn't
<unic0rn> it's not actually symlink issue, because after entering that directory directly, it's same error
<pynonoir> maybe a problem of locking file access
<unic0rn> hmm
<unic0rn> but why it displays all files as modified?
<unic0rn> and when i copy that dir to my home, it's all fine
<unic0rn> it returns crap only from within vfat partition
<pynonoir> well, i'm not a bzr expert. This may be a bug, or not...
<pynonoir> anyway you know a workaround (not using vfat)
<unic0rn> http://wklej.org/id/271375/txt/
<unic0rn> yeah, but that workaround isn't the best option. i may format 2gb partition to ext3 and use it to store sources there, but i would prefer them to be accessible from windows, just in case.
<unic0rn> and yes, i know there are ext2/3 drivers for windows, but that's just another workaround to workaround that shouldn't be neccessary in the first place
<pynonoir> maybe (just maybe), the bzr status tries to perform a lock on the directory just in case you decide to modify files during the check
<unic0rn> i think i've found it. need to check
<unic0rn> it's some access issue. it works under root, unfortunately i was unable to find a solution for it. changing uid and gid won't work with remount, so i would have to rebuild initrd to change those options
<unic0rn> so i'll probably copy sources to ext2
<timClicks> I've received a conflict on a massive locale file, is there a bzr command that says 'cross fingers & use the most recent commit and overwrite the old'
<timClicks> i don't speak french, so i have no idea which version is correct
<jelmer> timClicks, hi
<timClicks> jelmer: hello :)
<jelmer> timClicks: filename.OTHER will contain the version that the other side had
<timClicks> oh, so a simple mv & bzr resolve will work
<jelmer> timClicks: just overwrite the original file with that
<jelmer> timClicks: yep, exactly
#bzr 2010-01-31
<RyNy_> new to bzr and have a few questions
<RyNy_> anyone there?
<saullawl> uhh
<saullawl> I can try to help, lol
<RyNy_> very basic questions
<saullawl> Alright, shoot
<saullawl> :)
<RyNy_> I'm running lamp but want want to run Bazaar Explore for Mac, can I connect via ssh to my server?
<saullawl> It should be possible
<saullawl> So long as Bazaar Explore is an X11 app on the mac
<saullawl> You'd have to set up X11 forwarding on the SSH server and the SSH daemon.
<RyNy_> lost me, sorry what's x11
<wgrant> RyNy_: Why do you want to connect to the server? Is the branch there?
<saullawl> Xorg
<RyNy_> Yes, I'm using bzr to version control an install of LAMP running drupal
<wgrant> RyNy_: In Bazaar Explorer, try checking out a path like bzr+ssh://user@server/path/to/branch
<RyNy_> wgrant: my LAMP install is on AWS EC2 and uses a private key. Does Bazaar Explorer support ssh + private keys?
<wgrant> RyNy_: It relies on Bazaar, which relies on your operating system's SSH stack.
<RyNy_> wgrant: sounds like it's possible then? Is there any documentation for my needs?
<wgrant> RyNy_: http://wiki.bazaar.canonical.com/Bzr_and_SSH
<RyNy_> wgrant: cool. Let me try. Much appreciated!
<RyNy_> wgrant: do I need to have both Bazaar and Bazaar Explorer installed on both my server (LAMP) and my desktop (Mac)?
<wgrant> RyNy_: You need Bazaar on both ends, but Bazaar Explorer need only be on the desktop.
<RyNy_> wgrant: thanks again
<RyNy_> stuck here. trying to install QBzr but the help doc is rather vague: http://wiki.bazaar.canonical.com/QBzr
<RyNy_> Am I missing something on this page? There's the source tarball and a universal Windows installer. No Mac installer.
<Kamping_Kaiser> If i want to acces the 'bzr info' and 'bzr status' of a repo from a python script, should i import bzr libs and call them, or is a system() call going to wokr just as well?
<Kamping_Kaiser> something tells me its a silly question. oh well
<wgrant> Kamping_Kaiser: Why not import bzrlib? That's surely going to be easier.
<Kamping_Kaiser> wgrant: thats what i suspected, thanks.
<lifeless> Kamping_Kaiser: they provide different interfaces; using the lib should be pretty easy.
<Kamping_Kaiser> oh right. I'll go and have a look at what goodies bzrlib can do. thanks both :)
<wgrant> annotate is lieing to me.
<elmo> you started it
<wgrant> :(
<lifeless> wgrant: how so?
<wgrant> lifeless: In lp:~wgrant/launchpad/sprb-new-model-columns, annotate says that lib/lp/soyuz/model/sourcepackagerecipedata.py:130 was added by me in r8911. But the 8910->8911 diff doesn't show that.
<mgedmin> aieeee
<mgedmin> ran out of disk space and bzr dropped my commit message on the floor
<mgedmin> subversion would've at least left a svn-commit.tmp lying around
 * mgedmin hates being forced to re-type things
<gerard_> hey
<napster> Hello all...
<gerard_> who wrote update -r ?
<gerard_> I don't really get it
<Peng> What's not to get?
<Peng> Err, does that sound rude?
<Peng> It's for updating to a particular revision instead of the tip.
<gerard_> yeah, but normally update performs a merge...
<gerard_> so when you specify a revision, I expect it to merge with that revision
<gerard_> and merging with something in your own history shouldnt have any effect
<gerard_> :p
<Peng> But that wouldn't be useful, so it doesn't do that. :P
<gerard_> that's not really a reason...
<gerard_> it doen't feel like it should be part of the update command
<Peng> I don't feel like thinking about merging, but it probably makes sense. :P
<gerard_> what you'd want is pull . --local -r 1 --overwrite
<mzz> merging with something in your own history should have an effect, afaict.
<gerard_> it should?
<mzz> yeah, I think you want pull.
<mzz> what if I make a change, decide it's stupid, and want to commit a new revision with the change reverted?
<gerard_> bzr revert?
<mzz> then again, it's not like I use update often.
<gerard_> oh, not
<mzz> and I can't think of a use case for update -r off the top of my head at all.
<gerard_> what do you guys use for working with several people with a central repository?
<gerard_> just merge & push?
<Peng> gerard_: That's what I use, but it's not a super-busy project.
<gerard_> what I dislike from the merge & push is that the merge should have it's parents swapped somehow
<gerard_> because you otherwise have to summarize other peoples changes
<gerard_> also, i like to be able to review all the changes I'm going to commit
<Peng> Wait, how does it prevent you from reviewing changes?
<gerard_> hmm
<gerard_> well, if you only want to have one branch on your own computer
<gerard_> you'd have to merge the new changes from the master into your own, and then push
<gerard_> so you'll see then changes the other people made
<gerard_> the*
<gerard_> and when you commit & push you mess up the history
<gerard_> it won't be as nicely linear with sidetracks
<Peng> gerard_: Yeah...you shouldn't do that.
<mzz> for a pretty history I suspect it's preferable to merge your own changes into a separate "trunk" branch than vice versa.
<mzz> you *can* do crisscross merging like you're suggesting but the resulting history tree won't be quite as pretty.
<gerard_> in fact update does what I like it to do
<gerard_> the only problem is the double merge bug, and the fact that update; revert will lose all local changes
<gerard_> I spotted another duplicate for that bug #113809 btw
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<gerard_> yeah, I'll keep spamming that until it's fixed ;)
<shakaran> hi, I have a user with hardy and making a branch says: bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<shakaran> how to fix it?
<Peng> shakaran: What version of bzr is the user running?
<Peng> shakaran: If it's something really old (in this case, pre-1.6), the user could install a more recent version from the PPA, https://launchpad.net/~bzr/+archive/ppa
<shakaran> the user says that it have: Bazaar (bzr) 1.3.1
<shakaran> I send the ppa, I am waiting his answer
<lifeless> *yawn*
<shakaran> Peng: yep, it works for the user. Thanks
<mkanat> Hey mwhudson.
<dvheumen> the Bazaar site seems to be unreachable, do you guys know that?
<dvheumen> okay, and now it works again :P
<alamati> Hi all
<alamati> when I want push I got this error:
<alamati> zr: ERROR: Cannot lock LockDir(lp-64863248:///~alamati/opencd/opencd/.bzr/branchlock): Transport operation not possible: readonly transport
<alamati> can you help me?
<alamati> what do I do?
<Peng> alamati: It's an svn import. It's read-only.
<alamati> ya, its svn import,
<alamati> what do i do?
<alamati> I switch from SF to launchpad
<Peng> What are you trying to do? Do you want your revisions to wind up in https://opencd-fa.svn.sourceforge.net/svnroot/opencd-fa? Are you gong to get rid of the svn repo, and want the Launchpad branch to be the main location?
<Peng> alamati: You can push to another location on Launchpad.
<alamati> I want to wind up my project in SF, I want to continue developing in launchpad, I imported it to launchpad
<alamati> peng: where I push? what mean another location?
<Peng> Wherever. lp:~alamati/opencd/pengismyhero or whatever you want.
<alamati> you mean that I enter this command:
<alamati> bzr push lp:~alamati/opencd/
<alamati> ?
<Peng> No.
<Peng> Well, almost.
<Peng> bzr push lp:~alamati/opencd/something
<alamati> what is something?
<Peng> Whatever you want.
<alamati> So I must create new branch in launchpad?
<Peng> That's what I'm suggesting.
<Peng> It's possible there are other options, like turning the import into a regular branch, but I don't know how, and this is easy.
<Peng> You could even rename the other branch out of the way and then give the new one the same name.
<alamati> alamati@ThinkPad:~/opencd$ bzr push lp:~alamati/opencd/OpenCD
<alamati> Using default stacking branch /~alamati/opencd/opencd at lp-64863248:///~alamati/opencd
<alamati> Created new stacked branch referring to /~alamati/opencd/opencd.
<alamati> Is this true?
<Peng> Yes?
<Peng> It's not lying. :P
<alamati> :D
<Peng> The new branch will probably catch on fire if you rename or, worse, delete lp:~alamati/opencd/opencd.
<Peng> If it's just a rename, it might not break, and it's fixable. If it's a delete, ehh, hope you've got another copy of the data.
<Peng> I dunno if Launchpad prevents you from doing dangerous things or fixes them.
<alamati> this was my first push, after this any one can obtain new revisions?
<Peng> alamati: What do you mean? Anyone can obtain a copy of it, yes.
<Peng> alamati: You can even set it as the development focus branch so "lp:opencd" will redirect to it instead of hte old branch.
<Peng> alamati: Although people who already have a copy will need to "bzr pull --remember lp:opencd".
<alamati> Oh, where is my new rev? there are not in changes http://bazaar.launchpad.net/%7Ealamati/opencd/opencd/changes. why?
<Peng> alamati: Because that's not where you pushed.
<Peng> alamati: http://bazaar.launchpad.net/%7Ealamati/opencd/OpenCD/changes
<alamati> I confused
<Peng> I tend to cause that, yes.
<alamati> really thanks, dear peng, but how I can merge this two branches?
<Peng> I don't know.
<alamati> hummm
<mkanat> Is there a way to change branch options like append-revisions-only on remote branches?
<mwhudson> mkanat: hitchhiker
<mwhudson> :/
<mkanat> hitchhiker?
<mwhudson> mkanat: abentley's thing that allows you to poke around at the vfs layer
<mkanat> Oh ugh.
<Peng> It's like a basic sftp client, only for bzr's vfs.
<Peng> There's no method in the API to change append-revisions-only?
<Peng> s/the API/bzrlib/?
<mwhudson> oh i guess you can use .set_config_option or something
<mkanat> Oh, hitchhiker is actually pretty cool! :-)
<Peng> Indeed. :D
<mkanat> This is particularly handy because I can't get a prompt on this server.
<mkanat> mwhudson: Did you see my questions on the memory leak bug?
<mwhudson> mkanat: not sure i saw the most recent ones
<lifeless> reconfigure should do this to
<lifeless> patches needed ;P
<mkanat> Yeah, just a generic --set-option or something for reconfigure would be nice.
<mkanat> Is there a way to differentiate a "bzr up" from a "bzr co" or "bzr push" in pre_change_branch_tip?
<mkanat> Maybe I should just use pre_commit instead.
<lifeless> mkanat: what are you trying to do
<mkanat> lifeless: I'm trying to make sure that on the server, when somebody commits a change, the "committer" is always set to the logged-in SSH user.
<lifeless> an no, pre_change_branch_tip doesn't know about user level operations like up/co/push
<lifeless> mkanat: pre_change_branch_tip is what you need for that
<mkanat> lifeless: Yeah, the problem is that if somebody tries to do "bzr up" on the server itself, it fails.
<lifeless> mkanat: so, perhaps 'don't do that' ?
<mkanat> lifeless: Yeah, that's possible. The problem was actually updating the plugin itself on the server. :-)
<lifeless> mkanat: I generally suggest plugins look for a config option to enable them
<mkanat> Yeah.
<mkanat> I was considering that as a possibility, too.
<lifeless> or you could look at the branch path
<mkanat> Oh, that's a good idea, if it's going to stay just a mozilla.org plugin.
<lifeless> it will get userspace-chrooted but you can map to the local path
<keturn> oh, I found the bug entry.  I can't figure out how to configure authorization for smartserver because smartserver has no auth mechanisms.
<keturn> that explains it.
<EdWyse_Mobile> Is there an easy way to change a commit message a few revisions back? I started working with redmine and if I say bug "#n" it will mark it, but if I leave off the hash mark ('#'), it doesn't. I accidentally left it off a few revs back. It's not a big deal, but it would be nice to have it look right.
<Peng> EdWyse_Mobile: No.
<Peng> There are ways, but not very easy, and it would change the ID of the revision and its descendants.
<EdWyse_Mobile> Ok, thanks.
<EdWyse_Mobile> I know I could just make diffs for each rev, uncommit to the one before the one I want to change, check out, patch, commit... Way too much work for aesthetics.
<Peng> Yeah...it's possible to automate it more, but that's basically the end result.
<mkanat> Made a nice little bzr-to-cvs sync script here, if anybody ever wants it: http://bzr.mozilla.org/bzr-plugins/bzr-to-cvs/files
#bzr 2011-01-24
<jelmer> hey peitschie
<poolie> hi all
<mkanat> Hey poolie.
<poolie> hi max
<mkanat> poolie: Can I /msg you?
<poolie> sure
<mkanat> Cool.
<peitschie> hiya jelmer :)
<peitschie> hi poolie
<vila> hi all !
 * fullermd waves.
<vila> _o/
<vila> jelmer: ping
<catphish> is there anywhere i can find a list of wireprotocol commands?
<catphish> specifically i want to know which ones constitute a write request
<Nazcafan> hello
<Nazcafan> how do I get color diffs with bzr diff?
<Nazcafan> ah, found it
<Nazcafan> cdiff
<Nazcafan> take care
<Peng> catphish: You'd probably have to read the source dode.
<Peng> code*
<catphish> Peng: thanks, I thought that might be the case, was just hoping to same some time :)
<fullermd> Well, you could just build a list of all of 'em, then script up running them all against something you don't have write access to, and see what blows up   ;)
<Peng> haha
<m4rku5> hey, is it possible to "abuse" signed commits for authentication? i.e. only allow commits from certain users (and only if they signed them)?
<fullermd> Conceptually?  Sure.  I don't think anybody's implemented such a thing though.
<fullermd> I'm not sure that qualifies as abuse, though; sounds like something that's Just Fittin'.
<m4rku5> yeah it fits, but it sure was not the original purpose of signed commits
<m4rku5> I'm still thinking about how to implement per project authorization for a shared smart-server (i.e. it is hosting multiple projects and I don't feel like giving everyone ssh access)
<fullermd> Are you trying to prevent malice or stupidity?
<catphish> m4rku5: i'd say the easiest way is with ssh keys and a wrapper script
<catphish> rather than signed commits
<catphish> im implementing a shared repo with ssh and http ACLs
<m4rku5> catphish, i was thinking about that, how would you do that ? match the part of the url before .bzr/smart?
<m4rku5> oh what ssh and http?
<catphish> m4rku5: on ssh you need a wrapper that knows what access you have and runs the appropriate bzr serve commands
<catphish> with http, yes, you detect the string before .bzr/smart and inject that as the branch name
<catphish> i spent a whole day figuring that part out
<m4rku5> yeah but with https only (which is what i am planning) you would need to use different auth. backend depending on the path before .bzr/smart
<catphish> with http you use http basic auth
<m4rku5> yeah ive got it setup to use basic auth via htpasswd atm
<m4rku5> and i was thinking about ways to have per project access
<catphish> well that's fine isn't it?
<catphish> you can use htpasswd like that
<m4rku5> yeah well at the moment it is: you have access everywhere or nowhere
<catphish> you can use htaccess filesto set that up
<m4rku5> if i had used apache i could ;) using lighttpd right now, which I think might be a problem
<catphish> i don't know
<catphish> never used acl in it
<catphish> my implementation is based on a custom ruby server
<ccxCZ> a question about hooks if I may, I want to do equivalent of push_and_update, only for specific repository and on a server side preferably
<ccxCZ> is post_change_branch_tip the right hook for that?
<ccxCZ> did anybody implement this yet?
<jam> morning vila
<vila> morning jam !
 * vila lower volume damn it
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.2.3 is frozen, time to build the installers ! (rm vila)
<ccxCZ> would you guys help me writing a hook for bzr?
<ccxCZ> s/writing/write/
<ccxCZ> I want to update (lightweight) checkout upon a commit to specific branch, serverside
<ccxCZ> now first thing that would be handy would be some good API docs. So far I googled this: http://naesten.dyndns.org:8080/bzrlib-docs/bzrlib.html
<ccxCZ> how do I get some useable object from the checkout's path?
<vila> ccxCZ: have a look into builtins.py, best source of examples
<vila> open_containing_*(path)
<ccxCZ> ah, checkout == WorkingTree in bzr lingo
<pickscrape___> Hi, a colleague of mine just encountered bug 400351 using bzr 2.2.2. Should I reopen the bug, and what is the best way for him to recreate his dirstate? (Oh, and bzr check --tree triggers the same error).
<ubot5> Launchpad bug 400351 in Bazaar "bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: reports" [Undecided,Fix released] https://launchpad.net/bugs/400351
<ccxCZ> when using b.c.Config / BranchConfig, do I have to flush changes somehow?
<ccxCZ> or use locking, for that matter
<lifeless> vila: around?
<pickscrape> Hi, a colleague of mine just encountered bug 400351 using bzr 2.2.2. Should I reopen the bug, and what is the best way for him to recreate his dirstate? (Oh, and bzr check --tree triggers the same error).
<ubot5> Launchpad bug 400351 in Bazaar "bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: reports" [Undecided,Fix released] https://launchpad.net/bugs/400351
<jelmer> pickscrape: just getting rid of the .bzr/checkout directory and then running 'bzr co' IIRC
<pickscrape> jelmer: thanks, I'll get him to give that a try tomorrow.
<maxb> jelmer: Hi. I seem to be experiencing some odd test failures with bzr-git (maverick and below) and dulwich (karmic) in ~bzr/proposed. Do you think you could eyeball the buildlogs and see if they are at all meaningful to you?
<jelmer> maxb: looking
<jelmer> maxb: is this based on the packaging in debian or completely independent?
<maxb> it is based on debian, the changes are few, if any
<maxb> None for bzr-git, just some minor tweaks for dulwich/karmic
<jelmer> maxb: the version of C git used is too old I think
<jelmer> hmm
<jelmer> no, that's not it
<jelmer> maxb: sorry, I don't know what's happening there. I haven't those errors before, either.
<maxb> Ok :-)
<jelmer> *seen
<maxb> The bzr-git problem doesn't reproduce on my local maverick box, which could make debugging "interesting"
<jelmer> have you tried on a karmic vm?
<maxb> I don't have VMs conveniently to hand, perhaps I'll try in a pbuilder chroot
<Rcart> Hello. I've pushed a branch to lp:~id/ubuntu/etc/etc, and i want to remove the quilt patch that i applied to that branch. So, i follow these steps to try to make it: get the branch, cd the branch, quilt pop thepatch.patch, but here says: "No patches deleted" and the patched files still keep patched. Sorry if this isn't the correct place to ask.
<Rcart> Any suggestion trying to unpatch the files?
<maxb> Rcart: The quilt metadata in the branch may be incorrect, is my best guess
<Rcart> maxb: Ok, i have another branch (of the same package) that would like to replace the pushed branch on lp, can i do that?
<maxb> replace it completely, including history? (quite a major/destructive change?)
<Rcart> no, just replace the patch in the branch
<maxb> Then I don't understand what you're saying, sorry, because your two last lines appear to imply different things
<maxb> It might be easier if you gave links to the two branches on Launchpad to illustrate the situation
<Rcart> Ok, here's the branch: lp:~rcart/ubuntu/natty/bittornado/fix-420387
<Rcart> i want to remove the las patch that i aplied before pushing the branch
<Rcart> when i get my branch i LP, i cannot remove the patch (quilt pop patchname.patch) and says: "no patches deleted"
<Rcart> because i cannot remove the patch, i get an original branch from bittornado: bzr branch lp:/ubuntu/bittornado
<Rcart> and the, created a patch that would replace the patch in the LP branch
<maxb> erm, why are you creating .dpatch files in a quilt-managed project?
<maxb> updating Standards-Version in an Ubuntu package is wrong
<maxb> oh, sorry, ok, the packaging in debian is a bit mad, and uses .dpatch naming
<Rcart> yeah yeah, the reviewer in the branch told me that too, that's why i've worked in a new patch to fix the corrections
<Rcart> i just followed the naming, the patch i quilt format (:
<Rcart> is*
<maxb> You should not remove the CVS directory, it does no harm, and unnecessary deviation from debian is to be avoided
<maxb> You certainly shouldn't only remove one CVS directory of the many throughout the tree
<maxb> So, am I understanding right that you now have a replacement change in a fresh branch off lp:ubuntu/bittornado, and you wish to blow away the existing contents of lp:~rcart/ubuntu/natty/bittornado/fix-420387, replacing it with your new fresh branch?
<maxb> If so, bzr push --overwrite is what you're looking for
<Rcart> yeah, i got that correction from the comments of users in the branch
<Rcart> any consequences replacing the branch in LP ?
<maxb> If there was any likelyhood your existing changes had been merged anywhere or others were basing changes of their own on them, it would be undesirable
<maxb> In this case it should be fine
<Rcart> the branch is proposing for merge, but needs fixes, so i think according to what you say that there's no problem (:
<Rcart> maxb: btw, i removed the CVS directory because when trying to use debcommit command, it was complaining about .cvs directory
<Rcart> so, taking advantage of the occasion, what's the difference between bzr commit and debcommit?
<maxb> debcommit wraps bzr commit, providing a commit message suggested from the changes to debian/changelog
<Rcart> maxb: but when i was trying to use debcommit, this was complaining about the CVS directoy and just worked when i removed it, but when i used bzr commit there was no problem, what do you think was the problem?
<maxb> debcommit does not *only* work for bzr, it aims to detect the version control system in use and behave appropriately
<Rcart> maxb: Ok, thanks a lot for your help.
<jam> morning poolie
<jam> that is, if you've recovered from your flight back by now
<lifeless> jam: we was around earlier
<poolie> hi jam, i am back and i'm doing ok
<jam> poolie: good to hear
#bzr 2011-01-25
<poolie> hi
<mkanat> Hey poolie. :-)
 * AfC is wondering why the Inserting stream: Estimate keeps growing slowly. Can't you just cache the current history size in the tip record?
<fullermd> It's just checking to see if you're paying attention   ;)
<lifeless> AfC: it grows as we find more stuff you don't have
<AfC> lifeless: Right. I get that. But
<AfC> lifeless: would it be possible to a) cache total size (any commit knows this) +
<AfC> lifeless: or s/size # of revisions or.../
<AfC> lifeless: + b)  express a % of that size that's been reached?
<AfC> ie, just express the total target; if we get there zooooooooom fast, great! if we chug slowly, well, fine
<lifeless> its not obvious to me how to make that work with the arbitrary DAGs that occur
<lifeless> including partial history scenarios
<AfC> but showing a/b of a moving target is ... well, anyway I wouldn't be here offering the thought otherwise
<AfC> {shrug} just do revision count?
<AfC> anyway
<lifeless> so revision count
<lifeless> we send revisions last
<lifeless> doing revision count results in no change for 95% of the push/pull, then a sudden blat and its done.
<lifeless> I'm not saying the current impl is ideal
<AfC> lifeless: no informatio of "this tip := this many texts" or something like that?
<AfC> (if not, pity)
<AfC> anyway, if there was something reasonably static that isn't known at  *download* time but IS known at (say) *commit* time then perhaps it would be "more" useful...
<AfC> as a y in x/y
<lifeless> so, if you include a vector clock in the rev
<lifeless> purely informational
<AfC> yeah
<lifeless> we could in principle use it - but the problem is that the db storing texts etc is not one dimensional
<AfC> well, fair enough
<AfC> pity though
<lifeless> so there is no local reference to tell us if we have 0% or 100% of each vector until we do graph traversal
<AfC> thanks for taking the time to explain
<lifeless> its possible something can be done - but as I say, its non obvious to me what shape that would take
<vila> hi all
<inada-n> Hi, all.
<inada-n> https://bugs.launchpad.net/bzr/+bug/172383
<inada-n> Is this bug still in bzr?
<inada-n> My fellow worker can successfully add decomposed dirname recursively with bzr-2.3b5 on HFS+.
<vila> inada-n: Hey Naoki ! AFAIK, there are still grey areas there, so tell him to report any bug it encounters
<inada-n> OKey. I'll ask him to use bzr-2.3b5 continually.
<vila> inada-n: thanks
<TheSaw> Greetings
<sobersabre> hi
<sobersabre> I've got merging question.
<sobersabre> I have 2 branches not related to each other. let's assume both are local master branches.
<sobersabre> let's name their folder /b1, /b2
<sobersabre> I want to create a folder /stuff
<sobersabre> and to merge under it both b1 and b2, so I have ls /stuff: b1, b2,
<sobersabre> but so that b1,b2 are the contents of /b1, /b2
<sobersabre> hopefully all the commits are inside the rev. history of /stuff
<sobersabre> is this possible ?
<vila> sobersabre: yes
<vila> :)
<maxb> Quick question, what format are b1 and b2 in?
<maxb> In particular whether they are rich-root or poor-root
<vila> in b1 : bzr join b2 (with recent enough bzr formats as maxb points out)
<vila> sobersabre: 'join' will put b2 contents directly in b1 so move stuff around in subdirs if you prefer
<maxb> I'm slightly unsure what would happen if both branches originated in poor-root formats
<vila> maxb: further merges won't work very well IIRC
<maxb> But, would the join even work?
<vila> I think so
<vila> ...or not but in this case there should be an error message
<maxb> bzr: ERROR: File id {TREE_ROOT} already exists in inventory as InventoryDirectory('TREE_ROOT', u'p1', parent_id='tree_root-20110125133320-07vztq0cyp7mymdc-1', revision=None)
<vila> O_o
<vila> format ?
<maxb> that was attempting to join two pack-0.92 subdirs into a 2a
<vila> ouch, cross-format ! now you're naughty
<maxb> jelmer: Hi. So, the reason for the bzr-git test failures is that bzr core has changed from emitting "Created tag foo." on stdout to emitting it on stderr in 2.3
<maxb> jelmer: And the dulwich test failures appear to be because urlparse actually behaves differently there
<vila> maxb: jelmer is on the move these days, he will be hard to reach
<maxb> np, I'll file bugs too, was just opportunistically continuing a conversation from yesterday
<vila> ok, I wanted to make sure you were waiting in vain ;)
<maxb> File bug 707438 and bug 707434 ftr
<ubot5> Launchpad bug 707438 in Dulwich "dulwich.client.get_transport_and_path sensitive to change in Python's urlparse.urlparse behaviour, causes test failures on <= karmic" [Undecided,New] https://launchpad.net/bugs/707438
<ubot5> Launchpad bug 707434 in Bazaar Git Plugin "bzr-git tests fail against bzr <= 2.2" [Undecided,New] https://launchpad.net/bugs/707434
<jam> morning all
<jam> I'm just giving Empathy a try, so sorry if I miss notifications, etc.
<jam> hey vila, can you send me a tell? I want to make sure I get it
<vila> jam: morning jam !
<vila> one more without your nick
<jam> I think it pops up a little bubble, rather than playing a noise, and I tend to just ignore it. :(
<vila> by the way, do you have a patch for the wt2 failing test ? I saw a brief mail exchange with jelmer but can't find a mp for it
<jam> vila: no mp, I just posted something to the mailing list, and wanted to get feedback on it
<jam> I can turn it into something, I guess
<jam> wow... I'm installing all of the launchpad dependencies, and suddenly *all* of my theming died
<vila> sounds unrelated from this side of the ocean...
<jam> well, going back into "Appearance" fixed it all back
<jam> vila: I would think it would be unrelated, except launchpad-dependencies installs about 50 packages
<jam> and messes with your /etc/hosts and all sorts of stuff
<jam> (rocketfuel-setup)
<vila> yeah, too much to chew at once :)
<jam> vila: https://code.launchpad.net/~jameinel/bzr/wt-case-insensitive/+merge/47423
<vila> waiting for lp to refresh...
<vila> it's failing on OSX too
<jam> vila: refreshed
<jam> Please test it on Mac OSX
<jam> I'm currently logged into Ubuntu, so I can't guarantee that the change fixes it for Windows
<jam> but if it does for OSX, then I'm pretty sure
<jam> vila: do you remember how to configure gwibber for status.canonical.com?
<vila> can you remind me the -s invocation ?
<jam> I rebuilt my install, to give it more space
<jam> vila: "bzr selftest -s bt.per_workingtree case_sensitive"
<vila> fixed :)
<vila> jam: aproved
<jam> vila: I seem to remember I needed to add a special ppa to get status.canonical.com to work, but I don't remember what it was
<vila> oh, yeah, sorry miss that
<vila> I use gwibber-bugs-unstable here
<vila> and install gwibber, gwibber-service and gwibber-service-statusnet
<vila> 2.91.2-0maverick1 for all of them
<jam> vila: ppa:gwibber-bugs/unstable ?
<vila> I don't remember the precise invocation
<vila> the url I have is http://ppa.lp.net/gwibber-bugs/unstable so yeah, this should work
<maxb> Hm. I am noticing that for directories, loggerhead displays the revision and timestamp of when they were created as the "last changed"
<maxb> I suppose that figuring out the last change in a subtree is possibly non-trivial in bzr?
<jam> maxb: correct
<maxb> I wonder if it would actually be more accurate to show nothing in the last-changed columns in loggerhead there
<jam> maxb: we don't store a recursive 'last-modified' by directory
<jam> it would be faster :)
<maxb> The thing is, being told that the "src" directory of your active project last changed n revision 2 in 2003 is manifestly a lie
<jam> maxb: that was the last time that the directory object itself was changed
<jam> not a lie
<jam> just probably not what people expect
<vila> maxb: almost all the file systems I know of do the same...
<jam> vila: true enough. 'ls' reports similar info
 * maxb is attempting to sell bzr at work, and is anticipating complaints vs. svn
<vila> poor reason to do it too, but still, kind of explain why we did the same
<maxb> What does change a directory other than creating it?
<vila> maxb: adding, removing, renaming a file
<maxb> *ah*
<vila> at least on file systems
<maxb> hmm
<maxb> bzr seems to consider changes to children don't count at all
<vila> yes, like file systems: mkdir -p foo; cd foo ; touch bar ; ls -al; sleep 60 ; touch bar; ls -al; cd ..
<jam> maxb: vila should have said "adding, removing, renaming *the directory*"
<vila> jam: adding a children *to* the directory isn't seen as a change ? Argh
<jam> vila: nope
 * vila bangs head and EOD
<jfkw> Using Gentoo Linux package emacs-vcs, lightweight checkout bzr trunk, 117M. For the last week or so bzr pull's have been gigantic, sometimes GB.
<jfkw> #emacs suggested I ask here. Have deleted checkout and am rerunning, will see if building tree runs quicker.
<jfkw> Fresh checkout worked very well. Any tip I can pass along to other Gentoo users about why the checkout might have gotten to that state?
<maxb> jfkw: Are you pulling over a smart or dumb transport?
<maxb> i.e. what is the pull source URL
<cody-somerville> abentley, Hey
<abentley> cody-somerville, hey.
<cody-somerville> abentley, What would make bzr-pipeline's sync-pipeline think a new branch needs to be created for a pipe? Its currently failing for me trying to create a new pipe that already exists remotely.
<abentley> cody-somerville, if there's no pipe with the correct name in the remote pipeline, it creates it.
<cody-somerville> $ bzr sync-pipeline
<cody-somerville> Creating new pipe "sg-2.x"
<cody-somerville> bzr: ERROR: Branch in the way at bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/sg-2.x/.
<abentley> cody-somerville, Right.
<cody-somerville> I've already synced sg-2.x before as you can see
<abentley> cody-somerville, No, that demonstrates that you've push or synced it, and if you only pushed it, then it won't be part of the remote pipeline.
<cody-somerville> abentley, Well, I did sync it.
<cody-somerville> abentley, so should I just delete the sg-2.x branch on launchpad?
<abentley> cody-somerville, what's another pipe in the remote pipeline?
<cody-somerville> bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/misc-oem-patches/ is the pipe before sg-2.x
<jfkw> maxb: /usr/portage/distfiles/bzr-src/emacs-trunk $ bzr info Lightweight checkout (format: 2a) Location: light checkout root: . checkout of branch: bzr://bzr.savannah.gnu.org/emacs/trunk/ shared repository: bzr://bzr.savannah.gnu.org/emacs/
<maxb> hmm, so it is a smart server
<maxb> In that case, this goes beyond my knowledge
<abentley> cody-somerville, does "bzr show-pipeline" show the exact same list as "bzr show-pipeline bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/misc-oem-patches/" ?
<cody-somerville> abentley, Yes except for the new pipe I'm trying to sync called default-lb-root-command-to-sudo-linux32-for-i386
<abentley> cody-somerville, is that at the beginning of the pipeline?
<cody-somerville> abentley, no, after the first
<abentley> cody-somerville, I can't see anything wrong with your setup.  I guess this is a bug that I didn't know about.
<cody-somerville> abentley, Anything I can do to debug?
<abentley> cody-somerville, run "bzr missing" to compare your local and remote copies of sg-2.x
<cody-somerville> I had to use "bzr missing :push" and I have 2 extra revisions locally
<abentley> cody-somerville, could you re-run sync-pipeline with "bzr -Derror"?
<cody-somerville> http://pastebin.ubuntu.com/558218/
<abentley> cody-somerville, thanks.  I don't think I can do much more without a way to reproduce it.  I'm guessing they're big branches?
<cody-somerville> nope
<abentley> cody-somerville, okay, could you upload exact copies of your pipes to devpad?
<cody-somerville> abentley, using sync-pipeline? lol
<abentley> cody-somerville, no, file-by-file exact copies.
<cody-somerville> abentley, okay if I upload a tarball?
<abentley> cody-somerville, sounds good.
<abentley> cody-somerville, include the shared repository, if there is one.
<cody-somerville> abentley, okay, all uploaded to my home dir on devpad
<abentley> cody-somerville, thanks.  I've been mirroring the remote pipeline.  Give me a sec to verify it.
<cody-somerville> abentley, hmm... I'm going through the code in pdb
<cody-somerville> abentley, for some reason, remote_manager.list_pipes() is only returning the first pipe in the pipeline
<abentley> cody-somerville, and the first pipe is "live-build"?
<cody-somerville> abentley, yup
<cody-somerville> (Pdb) p remote_pipes
<cody-somerville> [(u'live-build', RemoteBranch(bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/live-build/))]
<abentley> cody-somerville, indeed, live-build does not link to the next pipe in the pipeline.
<abentley> cody-somerville, I am going to update the branch.conf in "live-build".
<cody-somerville> I wonder what could have caused that.
<cody-somerville> abentley, btw, I really enjoy using pipeline (even though I'm still figuring out the best ways to use it).
<abentley> cody-somerville, I would guess a new copy of live-build was pushed at some point.
<abentley> cody-somerville, I'm glad.  That's certainly a big pipeline you've got goingl.
<abentley> cody-somerville, anyhow, I think it's fixed.  Please try sync-pipeline.
<cody-somerville> abentley, since it seems like the other pipes in the pipeline have all the info about the rest of the pipeline, maybe it would be possible for sync-pipeline to figure out how to repair the remote pipeline in cases like this?
<abentley> cody-somerville, yes, it should.  Right now, it doesn't even notice the inconsistency, though.  I've got a bug for that.
<cody-somerville> abentley, Does it look like I'm using pipes right? What I'm doing is creating a new pipe for each patch I create on top of upstream like in the example.
<cody-somerville> abentley, I think having the ability to rebase would be useful FYI
<abentley> cody-somerville, yes, it looks like you're using it "right", but I don't do packaging, so please let me know if my ideas are impractical.
<cody-somerville> abentley, I'm not using this so much for managing the packaging but instead patches directly against upstream that I want to submit upstream
<cody-somerville> abentley, I have a single pipe at the end that I use to maintain my changes to the debian packaging provided by upstream and document changes made in my pipes.
<cody-somerville> I think I might want to start modify the changelog in each individual pipe and then merging the changelog as I go along so that when I remove a pipe (say upstream accepted it), I can easily merge out the changelog entry along with any straggling delta.
<abentley> cody-somerville, do the patches depend on one another?
<cody-somerville> abentley, most don't
<abentley> cody-somerville, I'm not sure pipeline is the correct tool, then.  I would try to maintain independent patches as separate branches.  What do you like about pipeline for what you're doing?
<cody-somerville> abentley, bzr pump :-)
<cody-somerville> abentley, and bzr sync-pipeline
<cody-somerville> abentley, and bzr show-pipeline
<cody-somerville> abentley, and bzr add-pipe is fast
<cody-somerville> abentley, and I can decide where in the pipeline I want my patch to be very easily
<cody-somerville> abentley, and can easily see the changes introduced in a range of pipes
<abentley> cody-somerville, so for your use case, it would be good to have a tool designed to manage an integration branch.
<cody-somerville> and I know that pipes closer to the top are closer to upstream's branch and pipes lower in the pipe are further diverged.
<abentley> cody-somerville, where each patch was an independent branch, but they still all got merged into the integration branch in a pump-like operation.
<cody-somerville> abentley, I like how I only have one directory with everything in it
<abentley> cody-somerville, pipeline could be that tool, but the UI could become a nightmare if done poorly.
<abentley> Which is why I haven't done it yet.
<cody-somerville> I personally think pipeline should become a part of bzr
<abentley> cody-somerville, apparently they're looking at something like that.
<abentley> cody-somerville, You can also get fast branching by explicitly using a shared repository and a lightweight checkout.
<abentley> cody-somerville, you can get branches-all-in-one-directory with the "bzr-colo" plugin.
<abentley> cody-somerville, not to discourage you from using bzr-pipeline, just to let you know that not everything is pipeline-specific.
<cody-somerville> ok
<abentley> cody-somerville, In fact, I tried to use existing tech wherever I could.
<abentley> cody-somerville, anyhow, is sync-pipeline working properly now?
<cody-somerville> abentley, yup
<abentley> cody-somerville, great.
<vanguard> I have some tags in my branch that I do not want, I removed them but they come again and again through pull/push. What can I do?
<maxb> vanguard: the only way to get rid of a tag is to explicitly delete them from all branches in which they exist
<vanguard> and not pull/push in the meantime?
<vanguard> how do I get rid of the tag in lp?
<maxb> bzr tag -d lp:foo --delete tagname
<vanguard> maxb: thanks, I'll try that. I just have the branches on three machines myself, +lp + whoever else ... endeavor to go :D
<maxb> woo, fixed dulwich except on lpia
<jam> maxb: what's funky about lpia?
<jam> (just wondering why it would be fixed everywhere but there)
#bzr 2011-01-26
<maxb> jam: It's a LP bug. It's failed to publish a build-dep on lpia
<maxb> nooo, new bzr-git failure on hardy
<quotemstr> How can I merge changes HEAD-2 and HEAD-3 in the history?
<chx> hi. if i use --hardlink but then edit a file ... how can i make sure my editor breaks the hardlink?
<bob2> depends on the editor
<chx> i see. can nano do it? can a file system configured to do it, in general ?
<bob2> no
<bob2> to (b)
<bob2> dunno if nano can/does by default
<lifeless> there is an ldpreload hack to break them
<chx> lifeless: FL-COW?
<fullermd> Urp.  Bookmarks is broken with .dev   :(
<damd> hi.  i have a weird problem which only happens when i use vc-bzr in emacs, but maybe someone here can help me anyways?
<damd> when i do "C-x v =" on a file in emacs (bzr diff equivalent) i get: bzr: ERROR: [Error 2] The system cannot find the file specified
<damd> however, when i do "bzr diff that/file.el" in cmd.exe it works just fine
<damd> any ideas?
<Tak> can you find out what actual filename emacs is using?
<Tak> i.e. is it just trying to do `bzr diff file.el`
<damd> i've tried to look in the source code, reluctant to modify it, but what the hell, what's the worst thing that can happen... let me check
<Tak> well, if it logs someplace or something...
<damd> it doesn't
 * Tak not familiar with emacs nor vc-bzr
<damd> i noticed just now that if the file has no changes, everything works as expected saying "no changes found" or similar
<damd> so it's something that happens when it determines that there are changes
<damd> okay, i think i've found the problem and it must be on emacs's side
<damd> "Running bzr diff --diff-options -c vc-bzr.el in background... done"
<damd> i don't think the working directory is correct
<damd> therefore it can't find vc-bzr.el
<damd> actually, i guess that's not the problem, since it works right when there are no changes
<damd> okay, running the same command that emacs uses in cmd.exe gives me the same error abut a file not being found
<damd> i'm guessing that this file is "diff"
<vila> damd: sounds pretty weird
<vila> damd: --diff-options without options for a given diff is suspicious
<damd> vila: i wrote a patch for vc-bzr-diff which takes care of it
<vila> damd: bzr has an internal diff, so I suspect having --diff-options triggers using an external 'diff' which it doesn't find
<damd> exactly
<vila> ha good
<vila> damd: the fact that you're using windows may make the bug more obvious too
<damd> i would have pushed the patch immediately if i had the time/ability to test it properly
<vila> damd: are you running emacs from source or from a official release ?
<damd> from weekly windows builds
<vila> I see
 * vila should really switch to vc and stop using dvc if only for test purposes
<damd> vc is really nice when you get the hang of it
<vila> I haven't use it for years
<damd> why do all things emacs have so ugly logos?
<damd> the emacs logo itself, the gnu logo, and now the DVC logo, christ that's bad
<damd> http://download.gna.org/dvc/dvc.png
<vila> aw, come on there are not that bad :)
<damd> the DVC logo is probably one of the worst logo's i've seen :|
<vila> actually the dvc is a nice variation of the emacs one (when you like the later ;)
<damd> they've literally _forced_ it to look like it says DVC on that gnu head
<damd> actually, that's what they did with the emacs logo as well... forced it to look like a gnu and now it looks like neither a gnu nor emacs
<vila> well, the oldest logo I can remember for emacs was a kitchen sink :)
<damd> yeah, i've seen that, but at least that wasn't official :P
<vila> hmm, as official as it can be as this time: http://www.emacswiki.org/emacs/EmacsIcons
<vila> I think even Lucid Emacs was using the kitchen sink icon, at least I was using lucid in these times so that's probably where I remember the icon from
<damd> i thought only some "funny" distros shipped emacs with that icon
<damd> this is the emacs icon that is the default in windows: http://www.emacswiki.org/pics/static/CarbonEmacsPackageIcon.png
<vila> yeah, this one has been around for ehat... ~ 10 years ?
<vila> ha no, the pencil was added at some point
<damd> no idea, i only started using emacs about five years ago
<damd> honestly, if i were to create an emacs logo, i wouldn't know where to start, but i _would_ know where to _not_ start and that is with the current gnu thing
<vila> hehe
<damd> enough senseless ranting for now!
<vila> mwahaha, best wallpaper ever : http://i.imgur.com/RxlwP.png
<damd> see, even the wallpapers are ugly :(
<vila> lol
<vila> scratch this itch !
<damd> yeah
<mgz> http://paste.ubuntu.com/558550/ <- that's a lot of PointlesslyBreakThings lines.
<mgz> do I need to add a tests for all of the ones that get fixed, or just trust people not to write broken code in future...
<vila> mgz: hellllo !
<mgz> hey vila!
<vila> mgz: what's the context ?
<mgz> bug 707954
<ubot5> Launchpad bug 707954 in Bazaar "bzr mv cause ERROR: exceptions.UnicodeEncodeError" [Low,In progress] https://launchpad.net/bugs/707954
<vila> str(xx) considered harmless ?
<vila> harmful I meant
<mgz> http://paste.ubuntu.com/558552/ <- example test.
<mgz> str(any_path) is harmful, yup. bzr uses unicode for paths.
<vila> ha ! yeah, so my last memories was running away crying from the rename exceptions
<vila> adding tests to ensure we cover all code paths there will be ideal
<vila> second to that would be to get rid of the str() harmful calls, but finding them and fixing them without tests may be tricky
<vila> so to come back to your initial question, if you can add a test for every call your fix: perfect
<vila> trying to avoid future errors... no idea on how to do that (the tests should be a good defense anyhow)
<mgz> I'm guessing not to blackbox though.
<vila> depends which layer you want to test
<mgz> well, ideally lower if I'm covering all those.
<vila> yup, my  memory tells me the relevant code is indeed lower
<mgz> it's WorkingTree.move ._determine_mv_mode .rename_one
<vila> have a look at the related exceptions too, that's where I started crying
<mgz> yeah, they're a bit of a mess.
<vila> at one point I got lost because exceptions were raised when trying to format an exception
<mgz> as is the general code for displaying errors about paths, eg bug 388437
<ubot5> Launchpad bug 388437 in Bazaar "notbrancherror doesn't show non-ascii paths correctly" [Medium,In progress] https://launchpad.net/bugs/388437
<vila> related to that,
<mgz> ^I need to fix some of this in another branch anyway
<vila> the unicode exceptions have an attribute with the faulty string but it's not displayed by default
<mgz> yeah, that'll be worth doing on top.
<vila> I was wondering if we could catch them in the bzr script (or wherever the exceptions are caught).. you see the point
<mgz> yup.
<vila> I'm still awfully jet lagged so you type too fast for me ;)
<mgz> so... where are WorkingTree methods tested?
<vila> did you see the bash_completion failures on windows ?
<vila> per_tree ?
<vila> bt.per_tree, bt.per_workingtree
<mgz> ah, yeah.
<vila> or may be these ones aren't :-/
<vila> I'd so love to add a 'raise' somewhere that would make all the relevant tests fail...
<mgz> ^nope.
<vila> -s bp.bash_completion -> 4 failures
<vila> can you reproduce that ?
<mgz> it's not really worth testing at all on windows though, and I thought wasn't.
<mgz> "Missing feature 'bash executable' skipped 12 tests."
<mgz> so, unlikely to get them.
<vila> well, I thought that too, but babune was happy with them before...
<vila> hmm
<vila> jam: around ?
<mgz> testing a cygwin bash under the windows python isn't very worthwhile.
<jam> hi vila
<vila> jam: hello !
<jam> I'm currently on windows, but I ran the test and it gave "missing bash executable"
<vila> can you run -s bp.bash_completion in your windows setup... damn
<jam> I'll try and check into it a bit
<jam> I run the win32 python under cygwin
<jam> so I would have thought path would be correct
<vila> rats, babune has no log about the features and skipped tests :(
<mgz> 2.7 logs skips sensibly now, but the win slave is on 2.6 right?
<jam> strange
<jam> running python manually, I see cygwin in the path
<jam> and running "p = subprocess.Popen('bash -c "echo hello"', shell=True)" works
<jam> ah, it's the probe
<jam> it specifically probes for the exact name "bash" in the path
<jam> so it won't find "bash.exe"
<vila> haaaa ! doxxx fix !
<jam> so why is it finding it for vila
<vila> in its mergetools proposal gordon tweaked osutils.find_executable_on_path, with weird bits for windows I didn't fully understand
<vila> so my guess is that it makes it find exes that weren't found previously
<vila> using a trick that is *not* used when calling the exe, so the probe succeeds now (it was failing before) and the tests now failed (they were skipped before)
<jam> vila: yep
<jam> vila: well, I wouldn't be surprised if the tests fail because it isn't compatible
<vila> which means babune reports skipped tests as successful ones... :-/
<jam> more than just because it can't find it
<vila> true
<jam> vila: right, the code in test_bashcomp.py looks to be using the exact path to 'bash'
<jam> and not using shell=True
<vila> hmm, not using shell=True is harmless on unices ?
 * vila never uses shell=True
<mgz> hm, I don't know how to hit some of these branches.
<vila> mgz: scary ;)
<mgz> ...the test just above where I'm adding these looks totally bogus too
<mgz> self.assertRaises((errors.InvalidNormalization, UnicodeEncodeError),
<mgz>             tree.rename_one, 'a', u'ba\u030arry')
<mgz> what the hell kind of check is that? it will *always* be raising the second exception, which If A Real User Did It, would print a big ugly traceback.
<wash> Do the latest versions of bzr-svn support any form of setting SVN properties (specifically, svn:eol-style and svn:mime-type)?
<vila> mgz: this makes sense
<vila> mgz: that's what the bug you're fixing is about
<maxb> wash: No, there is no way to explcitly edit user svn properties through bzr-svn
<vila> mgz: except that we now know that it's a bug and not an expected behavior
<wash> maxb: *nods* Thanks
<jam> mgz: check the annotate on that file. I probably wrote that code about 3-4 years ago
<jam> back when I was working on supporting normalization inside bzr
<jam> I know it pre-dated dirstate
<jam> which was what, 0.15 ?
<mgz> yeah, it's old, and I'm not even sure why the UnicodeEncodeError is checked for from the history
<vila> jam: are you sure it hasn't been modified when the rename exceptions have been introduced ?
<mgz> possibly for when unicode paths aren't supported at all? it's unclear.
<vila> my gut feeling is that UnicodeEncodeError has been added at this point in time
<jam> vila: could have been. I wouldn't be surprised if the test was saying "must raise InvalidNormalization" and someone decided to be lazy and have it raize Unicode
<vila> mgz: you may want to check the InvalidNormalization one
<vila> jam: yup, that's my feeling
<jam> mgz: also note, I personally have stopped trying to fight that fight since getting normalization during status is pretty difficult to make it perform well
<jam> and I ran into people on Windows not having normalized filenames
<jam> because Japanese windows wanted to use all wide characters in the filename
<mgz> NF(K)* is pretty deadly, but that's the K.
<mgz> messes up kana as well as ï¼¦ï¼µï¼¬ï¼¬ï¼·ï¼©ï¼¤ï¼´ï¼¨ characters
<vila> wow, nicely displayed here :)
<mgz> something still needs to be sorted jam, because macs seem stuck in limbo wrt unicode at the moment in bzr
<maxb> NFK* is evil madness
<jam> mgz: Oh the system is pretty hosed at the moment. NFC is  better than NFK, (AIUI) though I didn't know it back in the day
<jam> however, *I personally* have stopped trying to fight for it. I'd be happy to review stuff
<leonardr> i have a bzr question for anyone who can help
<cody-somerville> leonardr, no one can at the moment as you haven't asked your question ;)
<leonardr> cody: ah, that's the problem. i never asked my question
<leonardr> i'll explain it in abstract terms but here's the merge proposal of the branch: https://code.launchpad.net/~leonardr/lazr.restful/encode-xhtml-field/+merge/47536
<jam> leonardr: I believe the standard line is: "Just ask the question, don't ask to ask", but honestly it is pretty ingrained in us that a polite interruption is the rigth thing to do...
<leonardr> i do not want to get side tracked on this discussion, but to set the record straight, my first utterance was an introduction and i immediately proceeded to start writing the question
<jam> I suppose in IRC you want short communication because everyone has to type? Not sure why that became standard
<leonardr> the last release of this package was at revision 164
<leonardr> we're now at revision 166, and i need to do a point release based on revision 164
<leonardr> i can just do a release off my branch
<leonardr> but i'd like to merge it in to the mainline so that it will be easy to find later
<maxb> That all sounds correct.... where's the question? :-)
<leonardr> my current plan is to revert to revision 164, commit, merge my branch, commit, do the point release, and then re-merge the code from revisions 155 and 156
<leonardr> is there a better way, or is that it?
<maxb> eek
<jam> leonardr: reverting is probably not what you want
<mgz> just branch from -r 164
<vila> leonardr: just create a branch at...
<leonardr> lp:~leonardr/lazr.restful/encode-xhtml-field is a branch from -r 164
<vila> leonardr: -r 164, do your release stuff (including commitS)
<vila> leonardr: then merge your point release on top of your trunk resolving conflicts
<vila> leonardr: this will reflect the exact history of what you did, pretty clean IMHO
<leonardr> vila: my problem with that is that there will be no revision in trunk that corresponds to the release
<maxb> There will be no *mainline* revision in trunk which corresponds to the release
<vila> leonardr: it will and you can tag it
<leonardr> vila: ok, what do i tag?
<vila> leonardr: the tip in your release branch *before* merging it to trunk
<leonardr> vila: thanks, that was the missing piece
<vila> leonardr: if you look at bzr history, you'll see that the tags are never on the mainline, always on a dotted revno
<maxb> .... in a PQM-managed project, which this is not
<vila> maxb: right, but this shouldn't be a problem either
<maxb> Not a problem, but it does make the statement that tags are never on mainline not applicable here
<vila> ho !
<vila> right, my remark applied to bzr history *ONLY*
<jam> maxb, vila: well *some* tags are on the mainline, for people like me that didn't like having to pre-tag before sending it to pqm, but we changed away from that because it was a real PITA to maintain. :)
<maxb> Ah, the bzr history of bzr
<vila> maxb: ouch, right, I missed the ambiguity there :-/
<maxb> leonardr: So, is this making sense? :-)
<leonardr> maxb: not at all :)
<jam> but yes, leonardr, I would tag your release branch, and then merge it, and not try to tag the trunk mainline
<leonardr> ok, i'll do that and let you know how it goes
<vila> jam: as can be seen in bzr-0.{7,8,11,13,14,15,16,17,18,90} ? :-D
<jam> vila: did you just run bzr log to find that ?
<vila> bzr tags
<jam> or 'bzr tags'
<jam> vila: some of those are "?" tags
<vila> all of them
<jam> so those were before we merged release branches back into trunk
<jam> but I still wanted to track them once we finally got tags
<jam> vila: actually, only bzr-0.0.5 is a mainline revno.
<jam> I think I did the work to have the tag on the release branch mainline
<vila> yup, and plan0merge-dev >_<
<jam> vs my local branch that got merged into the release branch, which was then eventually merged on the mainline
<jam> vila: I don't have plan0merge-dev tag
<jam> so that must have been one of yours
<vila> plan-merge-dev
<jam> I do have "plan-merge-dev" and "plan-merge-ab"
<maxb> leonardr: short version: bzr branch -r 164 lp:lazr.restful lazr.restful-0.15.x; cd lazr.restful-0.15.x; bzr merge lp:~leonardr/lazr.restful/encode-xhtml-field; bzr commit; <Standard release procedures, which ought to involve bzr tag>; cd ....../branch-or-checkout-of-trunk; bzr merge ....../lazr-restful-0.15.x; bzr commit; bzr push
<jam> vila: interesting that plan-merge-dev is a (vila) commit
<jam> :)
<vila> I don't think so
<leonardr> maxb: ok, i'll let you know if i get unexpected results, but if the bzr tag works it should be fine
<vila> jam: it's from pqm and plan-merge-ab from aaron
<maxb> leonardr: One specific point to note - to ensure trunk's history is not confusing, it's important to merge the release branch into trunk, and not vice versa
<vila> jam: both from 200712
<jam> vila: it *is* a pqm revision, but it was a (vila) requested one :) I honestly don't know what the idea is
<leonardr> maxb: sure. that's what i do usually, so it's no problem
<jam> nor do I *really* care
<leonardr> (except it's usually not a release branch)
<jam> though it would be nice to be able to prune/hide tags
<jam> 100 tags is getting a bit big, the 1000s of tags in an emacs branch is pretty overwhelming
<maxb> hrm. bzr help does not tell you what the options are for tags --sort=???
<vila> jam: weird... I never used tags until being RM...
<jam> maxb: probably a bug in the help system. If you don't specify that an option can be supplied without the prefix, then it doesn't document the values
<tedg> Hey, I'm getting a really odd Bazaar error: "ValueError: could not convert string to float: /bfa.ko"
<jam> vila: "bzr.dev" is now properly failing the bash_completion tests
<tedg> Any clue on how to get back to a running state from that?
<maxb> tedg: Do you have a traceback with that?
<jam> tedg: doesn't look like a float to me :)
<jam> can you give more of a traceback
<tedg> Traceback (most recent call last):
<tedg>   File "/usr/bin/bzr", line 139, in <module>
<tedg>     exit_val = bzrlib.commands.main()
<tedg>   File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 1203, in main
<tedg>     _register_builtin_commands()
<tedg>   File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 182, in _register_builtin_commands
<tedg>     import bzrlib.builtins
<tedg> Not much...
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<tedg> bug 708063
<ubot5> Launchpad bug 708063 in bzr (Ubuntu) "bzr crashed with ValueError in _register_builtin_commands(): could not convert string to float: /bfa.ko" [Undecided,New] https://launchpad.net/bugs/708063
<vila> tedg: ouch, sounds like a .pyc corruption no ?
<vila> tedg: does 'bzr version' works ?
<vila> tedg: or 'bzr info'
<tedg> vila, No, neither of those work.
<vila> tedg: right, so your install is... damaged ?
<tedg> vila, Which pyc should I delete?
<tedg> I can just remove the package and reinstall?
<vila> tedg: well, yes
<vila> tedg: but you may have a deeper issue there, .pyc files don't get corrupted randomly on well-behave machines ;)
<vila> tedg: python-2.7 on lucid ??
<tedg> vila, Yeah, it's odd.  But none the less, it works after the reinstall.
<tedg> tedg, No on Natty
<tedg> vila, ^ :)
<vila> tedg: so InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) is misleading ?
<tedg> vila, It's correct.  That is what I used to install, then I upgraded.
<vila> bah, of course, DistroRelease: Ubuntu 11.04 is the one I should have looked at
<vila> tedg: anyway, good to know you're out of trouble
<vila> I'll mark this bug invalid
<tedg> Yes, thank you vila.  I already marked it so.
<vila> tedg: you rock, lp-cant-refresh sucks ;)
<tedg> vila, It's not really a LP specific problem.  The web in general sucks :)
<vila> tedg: shooting the messenger :)
<mgz> okay, get this baby reviewd time.
<vila> mgz: :)
<vila> jam: do you know a way to look at the pending jobs for the package importer ?
<jam> vila: define "look at"
<jam> http://package-import.ubuntu.com/status/ tells you what is pending
<jam> and what is currently running, etc.
<vila> it currently says 0 but tail -f progress_log shows it keeps adding some
<vila> so I guess my question is: what's the difference between outstanding jobs and pending jobs
<jam> vila: when the package importer doesn't have explicit packages to import, it then spins checking random packages for consistency
<vila> ha, I haven't seen that code yet then
<jam> so "Outstanding" means it has seen new .deb files that need to be imported
<vila> I'm working on mass_import.py
<jam> otherwise it is just poking around doing sanity checks
<vila> right, and it never stops doing that
<vila> so I think I will stop poking at this code and start looking at testing it before deploying...
<mgz> hm, have a feeling there was something else I was going to say in the mp but can't remember it.
<jam> vila: your mail host is blocking emails from me
<jam> vila: Remote host said: 550 Too many spams from your IP (98.139.52.70), please visit http://postmaster.free.fr/ [RCPT_TO]
<jam> and the page they link me to is in French, so I really don't know what to do
<jam> (well, click the English button...)
<vila> to put their spam filters were the sun doesn't shine ?
<jam> it looks like they are blocking all email from some of the mail.*.yahoo.com servers
<jam> at least, the IP they give resolves to: nm6-vm0.bullet.mail.ac4.yahoo.com
<jam> which is a bit hard for me to workaround.
<jam> I can send mail directly from my IP, but that is usually blacklisted because it is a comcast account
<jam> (or whatever the rules are. It is a "home" account, which is often blanket blocked)
<maxb> heh :-/ So apparently bzr-git/hardy has *never* worked
 * maxb wonders whether it's still worth doing hardy in ~bzr PPAs
<vila> jam: try using my canonical address ?
<jam> maxb: I believe hardy is still in its support window
<maxb> Yes, but that's not *quite* the same question :-)
<jam> vila: I'm just resending to make sure it works, but it was a note about the bash completion failures from sometime last night
<maxb> oh, just a moment
<maxb> Did hardy default to apt installing recommends?
<vila> maxb: that's not the highest priority, if people are happy with hardy (instead of lucid), they are probably happy with whatever bzr version they have
<mgz> jelmer needs more imaginative branch names.
<mgz> he's submitted like, five different things called lazy something this month.
<mgz> vila: I'm going to have to put up a 2.3 branch that just messes with imports as I've not had time to work on the transport hook and 2.3 is past beta
<jam> mgz: for your Unicode changes, isn't it just moving when the error occurs? I thought the exception formatter still treats everything via str()
<mgz> I cheated.
<mgz> in this case, it gets safely upcast to unicode, then BzrError.__str__ encodes it to utf-8
<mgz> I've got some other work that makes unicode things happen sensibly all the way down to bzrlib.trace
<mgz> so, mojibake not UnicodeError
<mgz> I'll add a note about this to the mp.
<jam> well, its an improvement
<catphish> does bzr have a native grep function?
<catphish> (preferably in the CLI)
<jam> catphish: there is a 'bzr-grep' plugin
<vila> mgz: meh, why don't you just target 2.4 ?
<catphish> jam: thanks, hopefully that'll do what i want :)
<mgz> because I left a horrible hack in the code!
<vila> mgz: with my blessing, send any complaint my way :)
<mgz> hm, doesn't look like too many hits.
<vila> mgz: you're referring to transport hook hack right ?
<mgz> right.
<vila> mgz: so nothing worth backporting to 2.3, target 2.4 :)
<mgz> I'll put a mp up with some import changes and we'll see.
<mgz> ...I actually intended that last mp to go to 2.3 as well, given it didn't change any interfaces, but perhaps 2.4 is safer.
<vila> mgz: yup
<vila> EODing, bye all
<mgz> bye!
<maxb> What is the name of the format defining the :param foo: constructs in bzr docstrings?
<lifeless> maxb: epydoc restful ?
<maxb> thanks
 * jelmer waves
<james_w> hi jelmer
<james_w> are you at LCA?
<jelmer> hi james
<jelmer> no, I'm in Seattle
<james_w> ah yeah
<maxb> jelmer: Hi. I've now discovered that bzr-git has in fact never ever been compatible with hardy's ancient python-tdb. I'm thinking of uploading a bzr-git/hardy to the ~bzr PPA with the Recommends: python-tdb dropped, and the default cache format hardcoded to sqlite even if python-tdb is installed.
<jelmer> maxb: sounds reasonable
<jelmer> maxb: I wonder how useful it would be to have bzr-git on hardy if it's never been packaged for hardy though
<maxb> great. This bzr-git/dulwich update has been an epic :-/
<jelmer> maxb: is it really an update? have we ever hard bzr-git/dulwich available for hardy?
<maxb> Well, we had previous versions in the PPA for hardy
<jam> maxb, jelmer: Note that until fairly recently we still had production machines in LP on Hardy. However, they've all been transitioned to lucid, AFAIK
<jam> I think LP itself went to lucid nov/dec last year
<maxb> and there was much rejoicing :-)
<jam> In Sept, there was "Don't use 2.6-isms because we are still running hardy"
<jam> Oct 13th was the transition, it looks like
<jam> anyway, that makes supporting Hardy much less interesting from at least Launchpad's standpoint
<jelmer> maxb: that function in dulwich was never unit tested earlier
<jelmer> maxb: (and bzr-git does its own patching of urlparse)
<jam> mgz: do you need me to submit your non_ascii patch?
<mgz> jam: I can do it. you have any opinion on whether it should have NEWS?
<jam> it should have news
<jam> I don't know that it merits whatsne
<jam> whatsnew
<mgz> will do that and push.
<jam> Possibly, since it is a user-visible change, but definitely NEWS
<jam> mgz: for your get_transport() change, this is all mechanical, right? You are just changing "from bzrlib.transport import get_transport" to "from bzrlib import transport"
<mgz> it is.
<mgz> diff in email is a little wrong because I suck, but I repushed the branch with a less screwed up first revision
<jam> mgz: that one looks  fine to me as well
<mgz> pushed the first one. I'll let vila look at the other in the morning if he likes before pushing.
<sinzui> I am interested in getting https://bugs.launchpad.net/bzr-gtk/+bug/707482 fixed. Is anyone minding bzr-gtk about
<poolie> hi mgz, sinzui
<poolie> sinzui, it seems like you're most of the way there
<sinzui> I can make this fix if someone agrees I am on the right path
 * poolie looks
<poolie> so which value is wrong?
<poolie> i guess line_no?
<sinzui> poolie: ganonnate's line_no and revno I think. UI is pretty simple, so changing the column types to int is probably right. Since gtktreeview reuses columns for layout when making a tree, casting to str() may be required
<jam> hi poolie
<poolie> sinzui, it's strange it's not failing before
<poolie> i wonder if maverick's pygtk automatically casts or something?
<poolie> i didn't think it did that
<poolie> hi jam, how are you?
<sinzui> pygtk 2.22+ behaves more like gtk
<jam> poolie: doing well. Nice to see you online, though I worry it means you aren't sleeping all that well.
<sinzui> poolie: There was a lot of implict goodness in pygtk that is lost as we gtk moves to 3 where there will be a standard api for all bindings
<poolie> :) mm, i woke a bit before 7, which is pretty reasonable
<poolie> sinzui, so, since i can't reproduce it, i suggest you change just lineno to type int and see what hapens
<sinzui> poolie: but this brings up the crucial question what gtk and python is bzr-gtk targeting?
<jam> strangely I've been waking up at just about exactly 6:51 since I got back. Not getting *up* mind you, but waking up.
<jam> sinzui: we're certainly still targetting python 2 for the moment (unless you mean gtk v 3?)
<sinzui> poolies casting with str() is very backward compatible with gtk2. changing the column types is not
<poolie> ah
<poolie> well, would we ever use a non-int line number?
<sinzui> the early liststores had limited column types, which I believe is why the class uses just astring
<sinzui> poolie: we care if we resorted the lines. We wont in this case
<jam> I'm pretty sure line_no will always be an int, but revno will often be a str
<jam> if it is hard to set a column type to int in older code, just go str, since as you mention, sort order doesn't matter
<sinzui> thanks. I will put a branch together. I will also test the other widgets so that this class of error is fixed in a single effort
<poolie> sinzui, ping me if you get stuck
<sinzui> thanks
<jam> poolie: have you seen the recent updates I did to the package-importer under-losa control discussion?
<poolie> jam, can you join #ubuntu-meeting
<poolie> no
<jam> poolie: rt #39614 and bug #589521
<ubot5> Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521
<jam> summarizes my thoughts on it
<poolie> ok, thanks
<jam> short summary is that it needs a fair amount of development done before we can really give up direct access
<poolie> elliot's suggestion at dallas, which i agree with, is that we should do things ourselves rather than handing it over
<jam> (and i wonder if that effort would be better spent integrating it with the vcs-import stuff)
<poolie> i thought i said that's what we'd do, and we'll just rely on them for low-level stuff
<poolie> keeping the os running etc
<jam> poolie: note that both the bug and the rt have expanded from "nagios integration" into "move to a new server completely controlled by losas"
<lifeless> giving up direct access is a bit separate :)
<lifeless> (I'm lending support, I hope)
<poolie> thanks for the pointer; i'll look at it
<poolie> the udd meeting is starting now; let's be there
<jam> lifeless: it is technically separate, but the discussion on the RT was that we don't want to integrate with nagios, we want to move you to a new server and take away all control. Not that it has to be done that way. :)
<lifeless> so the new server thing
<lifeless> thats because its on a borrowed box that is labelled 'landscape backup db server'
<jam> oh, I understand why
<jam> just mentioning that one rt got taken over by about 5 different things that they wanted to do
<lifeless> :)
<nhandler> So does anyone know why I am unable to push to lp:classbot/devel (on Launchpad) (doing so causes bzr to crash): ErrorFromSmartServer: Error received from smart server: ('error', "We are missing inventories for revisions: [StaticTuple('nhandler@ubuntu.com-20100920220053-yztqc4i042olpvnp',)]")
<lifeless> poolie: I'd like to talk loggerhead (voice) a little when you have a timeslice spare
<poolie> nhandler, at the broadest level i think someone has pushed bad data into it
<poolie> lifeless, sure, let me finish things heer
<james_w> IIRC that error is something to do with stacking
<poolie> could it be renaming the stacked branch causes that?
<poolie> :/
<poolie> maybe we should ban that
<james_w> nhandler, try "bzr pack lp:classbot/devel" and then try again
<james_w> bug 437003
<ubot5> Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003
<lifeless> I suspect an old bzr client actually
<lifeless> we had some bugs in this area
<nhandler> james_w: That did it. You rock! (but now I have no excuse for not fixing a few outstanding bugs in classbot ;) )
<james_w> heh, we can probably break it again if you like ;-)
<nhandler> james_w: Nah, that is alright. Thanks again.
<jam> poolie, lifeless: bug 437003 covers it pretty well. It is autopack across pack files where the inventories aren't in the group being repacked.
<ubot5> Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003
<jam> it is caused by stacking interacting oddly with autopack
<jam> where you got the inventory in the past, but then get the revision, and then autopack without getting the original pack file in the group
<lifeless> jam: is historydb optional in loggerhead?
<jam> no
<lifeless> poolie: ^
<jam> you don't need the *plugin*
<jam> but it changes how things are stored on disk
<jam> you certainly could rewrite things until you got to that point
<jam> but it isn't written that way
<lifeless> jam: what I mean is
<lifeless> jam: can trunk loggerhead be used with the performance profile of the loggerhead we use in lp
<jam> lifeless: no
<jam> which I tried to convey, but probably just got woryd
<jam> wordy
#bzr 2011-01-27
 * vila woke up one hour later than yesterday, one more week and the jet lag will be sorted out :-(
<lifeless> jam: no worries
<jam> vila: you should definitely not be up now :)
<vila> jam: indeed :-/
<vila> jam: nice summary in bug #589521, thanks for that
<ubot5> Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521
<fullermd> vila: Sorted out?  What's wrong with things like they are?  It sounds like a perfectly sensible schedule to me   :p
<vila> fullermd: the truth is, the arguments with wife and daughters tend to be easier to manage under this schedule...
<fullermd> See?  Come to the dark side...
<lifeless> mkanat: hey, you said the other day that b.l.n had the wrong theme?
<mkanat> lifeless: Yeah.
<lifeless> mkanat: I meant to ask what you mean by that, but got local interrupts
<mkanat> lifeless: I'll see if I can show you.
<mkanat> lifeless: This page has the wrong CSS: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/view/head:/.bzrignore
<mkanat> lifeless: Because this file is in fact missing: http://bazaar.launchpad.net/static/css/view.css
<lifeless> what css should it have?
<mkanat> lifeless: That CSS exists in the actual branch.
<mkanat> lifeless: But it is a 404 on bln.
<lifeless> let me just nab someone
<poolie> mkanat, i don't suppose you would have any time left to actually measure trunk (without historydb) vs 1.18 performance on a large branch?
<mkanat> poolie: I might. I have 2.15 hours left.
<mkanat> I mean, 2 hrs and 15 minutes.
<poolie> facts might bring a merciful death to this thread
<mkanat> poolie: I don't think anybody ever said that history_db was slower.
<poolie> robert thinks that john said it would be slower if the db was not enabled
<mkanat> poolie: I didn't see that on the list.
<lifeless> mkanat: jam said this:
<lifeless> Old     New     Action
<lifeless> 10s     30s     First request of a branch in a project that has not been
<lifeless>                previously seen. (slower)
<lifeless> (amongst other things)
<lifeless> note that none of our projects have been previously seen
<mkanat> lifeless: That's with history_db enabled or without?
<lifeless> and a 30s request will be killed
<lifeless> mkanat: with
<mkanat> lifeless: Okay, we're not talking about that situation, then.
<mkanat> lifeless: That situation would already be handled by what you'd do to enable history_db on codehosting.
<lifeless> mkanat: he also said that without the plugin, it uses plain bzr apis
<mkanat> lifeless: Which it does now.
<lifeless> so will be slower than before as well
<mkanat> lifeless: He said that there is some difference there from before history_db? Because the branch you're currently running uses plain bzr apis.
<mkanat> Oh, I may be seeing what he means.
<poolie> ?
<poolie> is it that it's removed caching code that would have helped in 1.18?
<mkanat> I'm still reading over the code.
<mkanat> poolie: I believe so, yes.
<mkanat> I'm not sure how much that actually matters, though.
<mkanat> What I don't know is how to turn off history_db to test.
<lifeless> remove the plugin
<lifeless> the historydb change is the following:
<mkanat> lifeless: It's a part of loggerhead.
<lifeless>  - discard all the caching apis
<lifeless>  - switch to raw bzrlib apis
<poolie> ok, so istm it would be a worthwhile use of time to measure whether trunk-minus-hdb is in fact slow
<jam> lifeless, mkanat: 30s is slower for the first request on a project when it has to convert the full ancestry to the cached form. Note that it can incrementally build the cache, so even if the thread is killed it will eventually succeed.
<lifeless>  - have a *bzrlib* plugin that makes those apis faster.
<jam> Also note, it is only for Emacs sized projects. bzr is a few seconds, IIRC
<mkanat> Yeah, launchpad also seems to be a few seconds, in my testing.
<mkanat> And yeah, even if history_db can't write to the disk, it will create its cache in memory.
<jam> history_db was pulled into the loggerhead codebase
<lifeless> jam: ah, k
<mkanat> So I suppose history_db is always enabled.
<jam> and 10s would become *every* request if you remove all the caching
<lifeless> so, this is really a bit of a distraction; unless its a no brainer: < a day of work, including getting up to speed, its not suitable for a maintenance squad at this time.
<mkanat> jam: That would happen basically if I just don't specify "--cache", right?
<jam> mkanat: I don't remember from the command line, tbh
<poolie> the question is: is there anything you could do in ~1 day that will get it at least no worse than 1.18?
<mkanat> poolie: I suspect that for the actual average use case, it is already no worse than 1.18.
<mkanat> poolie: With the scale of codebrowse, it's likely that current stable will be rebuilding caches quite a bit.
<poolie> ok
<mkanat> poolie: This is just my suspicion, though, not a proven fact.
<jam> poolie: I think the most immediate thing would be to teach Launchpad to shared caches between projects
<jam> at which point you'll hit a couple timeouts, but afterwards everything should be better
<poolie> mkanat, i'm wondering if we can do some measurements to get more confidence in whether that is true or not
<mkanat> poolie: Yeah, I could do that, for sure.
<poolie> jam, i know, but it seems like that is going to be more than a day of workL
<mkanat> poolie: I have a loggerhead load tester already.
<jam> poolie: it *should* just be changing the path to not include the branch name, just the project name
<mkanat> poolie: Let me do a test right now.
<jam> won't be shared between users, but probably pretty good
<jam> but I don't fully understand the codehosting remapping, etc.
<lifeless> jam: would that permit leakage from private projects
<jam> lifeless: revision id and revno stuff
<lifeless> e.g. if someone has the revid for a private project, makes that a ghost in their branch of same project
<jam> no revision information
<jam> lifeless: the cache is just the graph of revnos and revision_ids, it doesn't cache the actual content
<lifeless> jam: revids are sensitive too, given they include email addresses
<jam> so if you have the revision id, then you have all the information you're going to get
<jam> lifeless: but you just said you *have* it
<lifeless> right, thats one scenario
<jam> since you are making it a ghost
<mkanat> Okay, so I think that disabling the on-disk caching of historydb involves commenting out two lines.
<lifeless> the other one is it likely to expose a revid when it shouldn't.
<mkanat> Then it should cache in memory.
<lifeless> e.g. due to bugs
<poolie> mkanat, let's try it!
<mkanat> poolie: Okay, going to try it now.
<lifeless> remember
<lifeless> to test it with a stacked branch and HTTP backend
<mkanat> poolie, lifeless, jam: Another option is to have codebrowse cache everything in one directory, in one file.
<lifeless> for apples to apples comparison
<poolie> well
<poolie> his hardware and load is undoubtedly not exactly the same
<mkanat> My load tester creates significantly more load than codebrowse experiences.
<poolie> but perhaps we can get some data
<mkanat> Okay, I can already tell you that if you disable the on-disk cache, yes, trunk is slow.
<mkanat> I don't even have to run the tester.
<mkanat> Getting information for ViewUI: 15.945 secs
<poolie> on emacs?
<mkanat> On launchpad.
<poolie> ok, and you're confident that's representative?
<poolie> if so, that means we can't just deploy trunk
<mkanat> jam: I imagine that if we used loggerhead's normal configuration where there's only one history_db.sql file for all branches combined, then it would become unmanageably large, on codehosting?
<poolie> we would need to do whatever it is to get historydb in use
<mkanat> poolie: Yeah--what I didn't realize was that history_db was always being enabled, in my earlier tests.
<mkanat> poolie: Even if you don't specify a cache directory, loggerhead creates a temporary one when you start it.
<poolie> and the question then is: can that task be made sufficiently small to do it ahead of doing other loggerhead work
<mkanat> poolie: It's all infrastructural work on codehosting, AIUI.
<poolie> so it does cache to disk at the moment? but in a different form
<mkanat> poolie: No, your current stable loggerhead does not cache to disk.
<mkanat> poolie: But trunk always does.
<lifeless> uhm
<lifeless> My understanding is that it uses sqlite caches still
<lifeless> mwhudson: ^
<mkanat> lifeless: It *can*.
<mkanat> lifeless: I don't think codebrowse has that enabled.
<mwhudson> i'm pretty sure it does
<lifeless> so am I
<poolie> it seems like changing it to write historydb caches into the same place should not be too traumatic
<mkanat> Yeah.
<jam> mkanat: I don't think it would become unmanageable, but probably bigger, and after that first attempt, probably faster.
<mkanat> Actually, that wouldn't be a problem at all, if you are already using the on-disk cache.
<poolie> jam, so it would be better to use larger caching scopes, but doing it per branch would be ok?
<poolie> it won't die on the first access?
<mkanat> Yeah, so you could actually just deploy history_db now.
<jam> mkanat: no, loggerhead always cached to disk, it always created a temp one, even before history_db
<mkanat> jam: Hmm, except that I could always make loggerhead re-generate its branch caches before history_db, with enough simultaneous access.
<mkanat> jam: It looked to me like it was only using the lru_cache.
<mkanat> (Unless you configured it to use the on-disk cache.)
<jam> mkanat: it just happened to regen the cache all the time
<jam> if you don't specify a cache, one is created that only lasts the lifetime of the process, and then is thrown out
<mkanat> jam: Oh indeed.
<poolie> (separately, lifeless, is deletion of the /beta api near enough we should worry?)
<jam> poolie: I have to double check the code a bit. but I believe it will populate the cache file incrementaly, so even if it was killed in the first request, the second one will succeed for any given branch
<poolie> or maybe the 18th?
<lifeless> poolie: in principle we're not adding anything to it
<mkanat> jam: In that case, history_db sounds like a net win with little infrastructural work required.
<lifeless> jam: well the second request may be to a different instance
<jam> lifeless: but the disk cache is in the same location
<jam> aiui
<lifeless> I find the hand wave on infrastructure work scary.
<jam> using the same cache that loggerhead is using today
<mkanat> lifeless: Why would you?
<mkanat> lifeless: It's just a new file in the same directory.
<mkanat> lifeless: That's the extent of the change that would happen.
<poolie> jam: is historydb broken or unfinished or dangerous in any regard?
<mkanat> lifeless: Out of curiosity, do both processes currently use the same on-disk cache directory?
<lifeless> yes
<lifeless> they do
<jam> poolie: I don't know of anything specifically broken
<jam> caveat code has bugs
<lifeless> which is one thing jam highlighted as being a concern
<poolie> sure
<jam> probably nothing worse than the existing code
<poolie> and rollouts are hard
<poolie> but, we still need to get through them
<lifeless> mkanat: I find it scary because handwaving around a bit of core plumbing is somewhat cavalier
<lifeless> mkanat: when one considers all the bits that can - and have - gone wrong in the past.
<mkanat> lifeless: Are you talking about infrastructure or about the internal architecture of loggerhead?
<lifeless> mkanat: infrastructure
<lifeless> and architecture
<mkanat> lifeless: Okay. Are you using (or do you have) sqlite 3.7? If you use a WAL, I bet both processes would be fine accessing the same cache.
<lifeless> I haven't looked at the risk of disclosure for private branches other than my brief queries here
<mkanat> lifeless: Risk of disclosure in what way?
<mkanat> lifeless: history_db, when we're just talking about loggerhead, is only a backend change.
<lifeless> bugs disclosing revision ids not in the branch being accessed
<poolie> but, i think at the moment we're not talking about having a shared cache?
<lifeless> mkanat: I realise that its a backend change.
<lifeless> poolie: one of jams caveats was slower initial scans w/out a shared cache.
<mkanat> But we would have a shared cache.
<lifeless> sigh
<mkanat> Because we'd have only one cache.
<lifeless> I'll come back to this, I feel that the point is ....> over there
<lifeless> doing a bunch of work to assess whether its small enough, based on guesses - is at best a guess. Right now, I still wouldn't confidently ask curtis or julian to take this on within maintenance scope
<mkanat> lifeless: It doesn't sound like any code work is required.
<lifeless> if I'm over concerned about the risk, its because of a history of problems.
<poolie> it's like a major version bump in a dependency
<poolie> perhaps one that has caused trouble in the past
<mkanat> Yeah, sure. I mean, there's still the testing thing that I just talked about on the list.
<mkanat> I'm fully with you on that.
<lifeless> mkanat: I don't know that I've claimed code work; the same engineers do code and integration - everything except deploy & server ops.
<lifeless> mkanat: its an integrated team leading right up to the ops team
<mkanat> lifeless: Okay. What do you mean by "integration"?
<lifeless> for me to say to curtis or julian that its in scope for maintenance, I'd want to be quite confident that there is < 12 hours work asessing, measuring, qaing on staging, deploying & dealing with the fallout.
<poolie> lifeless, how would you handle an upgrade to some other component we depend upon?
<poolie> there may well be some that are over 12h
<lifeless> poolie: if its small a maintenance team just does it. If its not a feature squad gets assigned it - as will happen to python2.7
<poolie> ok
<lifeless> now, someone devs may scratch an itch and get python2.7 workable on dev machines, but actually upgrading prod etc requires considerable care.
<poolie> sure
<lifeless> 12h is an arbitrary figure
<poolie> ubuntu upgrades are another case that comes to mind
<poolie> istm we have the option of trundling along 1.18.x until we get time to safely do a bigger deployment
<lifeless> right, they were traumatic, and we're doing them differently next time - separating OS and dependencies; we'll go to py 2.7 *before* the next OS upgrade.
<lifeless> so that we're in place.
<poolie> but we'd probably prefer not to do major development that's duplicating what's been done in an upstream later release
<lifeless> poolie: I don't see that as an option; I see that as the /only/ option given the info I've got about whats up.
<poolie> max has said, rightly or wrongly, that he doesn't think there's any more low hanging fruit for performanec
<poolie> so, i don't think we can usefully schedule small blocks on this
<mkanat> Talking about actual development of loggerhead, that is.
<mkanat> Which would be a separate issue from rolling out this one.
<poolie> and if we're going to schedule a big block, we might as well start it by getting historydb running
<mkanat> lifeless: Without tests, I can't say how much time deployment would take. But if you also start changing *any* branch significantly, my answer would be the same.
<poolie> since we know that will probably help alot
<mkanat> lifeless: If everything goes fine, I suspect it will take no longer than a normal rollout, perhaps an hour or two more.
<mkanat> lifeless: The worst that could happen--that I can predict now--is that the two processes may need separate cache directories so that they don't lock each other out.
<lifeless> mkanat: so, I'm aiming at 10 minute downtime windows; thats a factor of 12 more than 'ok'
<lifeless> mkanat: or maybe you don't mean downtime window ?
<mkanat> lifeless: I don't see any downtime happening.
<mkanat> lifeless: Yeah, I mean total maintenance work time.
<mkanat> lifeless: To do the rollout.
<poolie> it seems like we should easily be able to run it in parallel
<poolie> since it's readonly etc
<mkanat> poolie: history_db gets written to quite a bit.
<lifeless> all this is fine
<lifeless> BUT ITS WORK.
<poolie> logically readonly
<lifeless> who is going to do it? what if the guess is wrong? whats the impact on load? will the machine thrash?
<mkanat> poolie: Yeah.
<poolie> indeed
<mkanat> lifeless: The machine should use considerably less memory with history_db than it does now.
<lifeless> I mean, I'm totally fine with whatever plan, my point has *never* been that its crap, its been that *we need to do work to make this usable in prod*
<lifeless> effort
<lifeless> time * energy.
<poolie> lifeless, the point is, i don't see that there is any other sensible next step other than deploying this
<mkanat> lifeless: In an ideal situation, the rollout requires no attention from anybody--it would just be a standard merge and push.
<lifeless> which btw, this conversation is sapping for me.
<poolie> i'm not saying you have to do it right now
<poolie> but there's no point discussing how to make it possible to do other things off 1.18
<mkanat> lifeless: I totally understand. :-)
<lifeless> poolie: But thats not what I argued *for*. I argued that other than oops fixing, which there are plenty of sensible things to do in the current lp branch, we're not going ot be undertaking major works for 6-9 months, based on my knowledge of jml's pipeline.
<poolie> ok
<poolie> so again we come back to assumptions
<lifeless> do you agree that nearly 20K unhandled exceptions a day is a little bad?
<poolie> max thinks it is not easy to fix oopses in the current branch
<mkanat> Ah, I wouldn't exactly say that.
<lifeless> and do you agree that historydb is an *operational unknown*?
<mkanat> It was easy to fix the "no such revision" one.
<mkanat> lifeless: Actually, now that I understand it, I only agree minimally.
<mkanat> lifeless: Because codebrowse is already using on-disk caches.
<poolie> lifeless, i'm only spending time on this because i think it needs to be improved and i want to see us take the best course on it
<mkanat> lifeless: This is just another on-disk cache.
<lifeless> mkanat: which we have several deployment options for
<lifeless> a) per branch
<lifeless> b) shared cross branch
<lifeless> c) memory only
<lifeless> d) huge one
<lifeless> e) ...?
<mkanat> lifeless: Right, and (d) requires no code work at all.
<lifeless> we've seen locking issues with sqlite already
<poolie> so we have some undelivered work in trunk
<poolie> we all agree that actually deploying it will take work
<lifeless> a) would be equivalent to our current cache story in terms of disk, but higher upfront scans and no benefit cross-branch
<lifeless> etc
<mkanat> lifeless: (d) is essentially what codebrowse is doing right now.
<lifeless> mkanat: I thought a) was
<mkanat> lifeless: Nope--one file in one directory.
<lifeless> mwhudson: ^ cache per branch, right ?
<mwhudson> there would be little point in doing (a)
<mwhudson> lifeless: currently?
<lifeless> yes
<mwhudson> not sure actually
 * mwhudson checks
<mkanat> lifeless: At least, AIUI.
<poolie> mwh, for my education, where are you checking to find out?
<mwhudson> poolie: lib/lp/launchpad_loggerhead/app.py in the launchpad tree
<mkanat> Oh right, launchpad-loggerhead.
<poolie> mwhudson, i don't have that directory...
<mwhudson> lifeless: it's one per branch currently
<mwhudson> poolie: -lp/ sorry
<mkanat> poolie: It's a separate project, lp:launchpad-loggerhead
<mwhudson> mkanat: not any more it's not
<mkanat> mwhudson: Oh! didn't know.
<lifeless> mwhudson: I don't have that directory, for whatever reason
<mwhudson> poolie: lib/launchpad_loggerhead/app.py
<lifeless> right
<lifeless> so,  back to facts, we're deployed with (a) today
<lifeless> shared between two instances
<mkanat> lifeless: Ahh.
<lifeless> with some threads each
<mkanat> Yes, in that case, history_db would be different.
<poolie> ok, and are you saying that historydb is going to be slower in that setup?
<mkanat> poolie: No, just different.
<mwhudson> lifeless: changing to one cache per <whatever> would be very easy
<lifeless> jam says initial scan is thrice the time, subsequent operations are faster
<lifeless> mwhudson: I know, but its all time
<lifeless> mwhudson: for a maintenance squad without your context
<lifeless> mwhudson: who will be writing up what they figure out like crazy
<mwhudson> lifeless: less time than this conversation has been going on for
<mwhudson> lifeless: sure, they are welcome to talk to me :)
<lifeless> mwhudson: sure feels like it; or are you serious ?
<mwhudson> lifeless: sorry, not quite sure i understand
<lifeless> mwhudson: 'less time than this conversation has been going on for'
<mkanat> lifeless: I'm pretty sure he was serious.
<mwhudson> lifeless: yes, i was serious about that
<lifeless> ok
<mwhudson> it's a few lines
<lifeless> + a test run :)
<lifeless> + qa to make sure it behaves
<lifeless> anyhow
<mwhudson> yeah
<mwhudson> sadly, a test run won't make any difference, but yes
<lifeless> poolie: so whats your proposal thats different to what I've suggested?
<mkanat> mwhudson: Where's the on-disk cache setup in app.py? I only see "self.graph_cache = lru_cache.LRUCache(10)".
<mwhudson> lifeless: this diff will switch to using a single cache http://pastebin.ubuntu.com/558839/
<lifeless> poolie: or are you trying to say I've got a bad axoim or assumption?
<poolie> lifeless: keep both branches as they are
<lifeless> mkanat: cachepath =
<mkanat> lifeless: Ah, thanks.
<poolie> if there's genuinely low fruit in 1.18, do that
<poolie> file a bug saying "should upgrade to trunk"
<poolie> do that in a safe way, but don't be scared of it
<mwhudson> mkanat: the BranchWSGIApp constructor
<mkanat> mwhudson: Yeah, I found it. :-)
<lifeless> poolie: I'm not scared of it; honestly.
<lifeless> I'm assessing how long its taken mwhudson to do this in the past
<lifeless> the things that have gone wrong in the past
<mkanat> lifeless: Okay, I'm starting to agree with you more now that I see how codebrowse currently runs.
<lifeless> and our pipeline of stakeholder requests
<mkanat> lifeless: I was under the impression that it was doing (d).
<poolie> it's fine if it stays in the pipeline until it's a priority
<lifeless> mkanat: god no, it would be flattened in an instant
<mkanat> lifeless: That's sort of what I thought, yeah. :-)
<mwhudson> lifeless: i'm not so sure about that actually
<lifeless> mwhudson: that was humour
<mwhudson> you might have some locking related fun
<mwhudson> ok
<lifeless> I'm pretty sure we do benefit from the caches
<mkanat> lifeless: That's possibly resolvable by WAL, but that would indeed be infrastructural and integration work for sure.
<lifeless> but I'm also sure there is friction in there
<lifeless> which needs time and attention to detail
<mkanat> lifeless: Okay. Out of curiosity, are you sure because you have tracebacks, or just because you suspect?
<lifeless> poolie: I don't think putting it in the pipeline as a given makes sense; saying 'do something to make codebrowse better' is something we should put in the pipeline; one concrete thing we can do there is productionise and deploy history db
<lifeless> mkanat: have seen the odd thing go by
<mkanat> lifeless: Okay.
<lifeless> mkanat: such as sqlite lock contention errors
<poolie> it's essentially already on the kanban towards the right hand side
<lifeless> poolie: I have to disagree.
<mkanat> lifeless: I think that it would probably be sensible and manageable to do oops fixing on trunk and 1.18 both simultaneously, and then schedule trunk rollout for a few months away.
<mkanat> Or on ~launchpad-pqm/devel and trunk.
<lifeless> poolie: theres a bunch of work been done on it, yes. But no team has been pushing it forward; its a new-situation for whomever comes along.
<poolie> lifeless, because... it's not that far to the right if deployment hasn't been thoroughly considered?
<mkanat> lifeless: If you limit the changes to just oops-fixing until trunk is ready, I think you'd be fine.
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=fixing
<poolie> if jam's willing (not too scarred by lp-serve) we could ask him to do it with help from mwh and it would not be new
<lifeless> poolie: that, plus what I said, plus the work done hasn't been done with a view to the whole lp story around this; its been somewhat siloed off
<lifeless> poolie: if you want to do that, that would be awesome; don't underestimate it though - I mean, you know how gung ho I am about stuff generally, right ?
<poolie> heh
<lifeless> poolie: this is *it can be done and there is a pie on the line collins* being concerned.
<poolie> :)
<mkanat> lifeless: Given codebrowse's history, I don't blame you.
<poolie> so in a way i would be ok with saying "this is really not a good fit, let's throw it out"
<mkanat> lifeless: Also given the fact that right now, it's far more stable than it's ever been.
<poolie> ideally, if we had a specific reason for that
<lifeless> so if you want to do that, say so; if we leave trunk as-is, I'll setup a separate project to get code reviews and bugs visible to the lp team until we're converged.
<poolie> but, if it's done and we don't think there's anything actually wrong, we just find it hard to deploy
<poolie> that just seems like a bad reason
<poolie> if true, it seems to mean some bugs can just never be fixed :(
<lifeless> poolie: we have a similar set of reliability and robustness concerns around soyuz
<poolie> do we ultimately want to get historydb running or not?
<mkanat> poolie: I would think so.
<poolie> i'd be fine with deciding that it was just a spike experiment and we want to take another go at it, if that's what we really think
<lifeless> compared to loggerhead, which has - I think - one person familiar with it still on the lp team, soyuz has 4 folk familiar with it, so we can actually react quickly to issues
<lifeless> from my perspective, its an experiment until either a) a feature squad is given codebrowse improvements as a card, and agrees that historydb is the way forward, or b) someone else does the work necessary to get it live
<mkanat> It's too bad I don't have enough time left to stick around and help with the rollout.
<lifeless> I can't prejudge what the feature squad engineers will decide makes sense
<lifeless> [well I can, but I'd hate it if someone did that to me, so I don't do it to them]
<poolie> mkanat, it seems like organizing rollouts is a pretty hard thing to do unless you are actually full time on the lp team
<mkanat> lifeless: That's understandable. That might just be re-having a conversation that's already been had, though, from back when jam originally proposed history_db.
<lifeless> mkanat: it may be a nobrainer
<mkanat> lifeless: Sure. But I understand that the specific application to LP is still something to discuss.
<lifeless> I'm just being clear about what I can commit to confidently.
<mkanat> lifeless: Sure, I totally understand.
<mkanat> The primary thing that a designer has to deal with is the fact of uncertainty.
<lifeless> yup :)
<poolie> are there any concerns about trunk other than that the deployment may be very bumpy (and i realize that may be a very large conrcern)
<mkanat> Yeah. It's something that a lot of people don't understand. They try to predict an unpredictable future. :-)
<mkanat> poolie: Unpredictable problems that I can't imagine now, based on the fact that there have been a lot of changes.
<lifeless> poolie: I haven't done a rev by revision review because I think thats a waste of time.
<poolie> s/bumpy/& laborious whatever
<lifeless> poolie: once the card size is assessed as being > maintenance bucket, it goes into the queue.
<lifeless> poolie: history db alone is enough to do that for me
<poolie> ok
<poolie> so i propose to file a bug saying that historydb ought to be tried out and deployed
<poolie> if in the course of trying it out, it seems that it is not a good solution, or too much work, or whatever
<poolie> we can mark the bug wontfix and then pull it out of loggerhead's trunk
<mkanat> poolie: Where would it be tried out, though? There's no edge.
<lifeless> who will do the trying out ?
<lifeless> mkanat: we do have bazaar.qastaging.launchpad.net
<mkanat> lifeless: Oh, okay.
<lifeless> thats in the qa pipeline
<mkanat> lifeless: Which...is a redirect loop.
<poolie> do you mean 'who will work on the bug' or 'how will we test it'?
<lifeless> poolie: who, now how.
<lifeless> s/now/not/
<poolie> does that matter?
<poolie> it's a thing we can do to make lp better
<poolie> either a squad will do it, or someone else
<lifeless> well
<lifeless> from my perspective this is a feature bug as I've said many times before
<lifeless> that means it won't get a maintenance squad timeslice
<mkanat> lifeless: You know...there is another option, here.
<mkanat> lifeless: You could just live with the OOPSes until you switch to trunk.
<lifeless> I'm not clear what you want to have happen, given the constrains we have.
<poolie> we are getting timeouts on some pages
<lifeless> mkanat: I'm particularly unhappy with that idea because they generally mean a user has had a bad experience
<mkanat> lifeless: That's true. BTW, do you have analysis of them yet?
<poolie> it seems at least possible that the most efficient way to fix them is to move to loggerhead trunk
<lifeless> mkanat: yes, the connection reset one is 16K a day
<poolie> or, there may be other fixes
<lifeless> mkanat: the others are largely below the fold
<mkanat> lifeless: Oh! That just happens when somebody closes their browser.
<lifeless> mkanat: yes
<mkanat> lifeless: Okay. So that would be the primary one to fix, and the others could wait.
<poolie> really?
<lifeless> mkanat: yes
<mkanat> lifeless: Okay. That would be easy to fix both on trunk and 1.18.
<poolie> i mean obviously, it can happen there, but is that really happening 16k/day?
<lifeless> next highest one is
<lifeless>  61 error: [Errno 104] Connection reset by peer
<lifeless>   31 http://0.0.0.0:8081/%7Evcs-imports/busybox/main/changes (Unknown)
<lifeless>        OOPS-1852CBB1307, OOPS-1852CBB1810, OOPS-1852CBB188, OOPS-1852CBB1990, OOPS-1852CBB2626
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBB1307
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBB1810
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBB188
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBB1990
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBB2626
<lifeless> poolie: its in the daily reports
<mkanat> lifeless: That's the stability-checking script that the losas run.
<poolie> what i mean is, there are other things that can generate econnreset
<lifeless> poolie: the cause may be misanalysed, but
<poolie> or eof
<lifeless> 15332 error: [Errno 32] Broken pipe
<lifeless>    Bug: https://launchpad.net/bugs/701329
<lifeless>    Other: 15332 Robots: 0  Local: 0
<lifeless>    7604 http://0.0.0.0:8080/%7Evcs-imports/busybox/main/changes (Unknown)
<lifeless>        OOPS-1852CBA1, OOPS-1852CBA10, OOPS-1852CBA100, OOPS-1852CBA1000, OOPS-1852CBA1001
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBA1
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBA10
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBA100
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBA1000
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1852CBA1001
<mkanat> poolie: It would happen with bots.
<lifeless> so we see 16K +- 2K a day of errno 32, and < 100 of errno 104
<lifeless> fixing the 16K one *may* expose some timeout cases
<lifeless> this is another reason to just stay focused on stabilisation
 * mkanat nods.
<lifeless> poolie: so it seems to me you want to push this branch forward
<poolie> so it seems likely to me that the epipe error is loggerhead seeing the connection closed by haproxy
<poolie> we don't really know what caused haproxy to close it
<lifeless> what I'll do then, is make a new project, pull the lp loggerhead stuff into that, which will get changes to that branch under review and bugs per the lp policy a home
<mkanat> poolie: Yeah, that sounds likely right.
<poolie> (incidentally log correlation stuff would be useful here, but maybe just less(1) is enough)
<lifeless> if and when trunk gets into lp we can consolidate the projects again
<poolie> lifeless, yeah, i would like to push it forward
<lifeless> I've spent enough time on this discussion, I'm going to stop now. We're not going forward, and the bits I'm describing don't affect anyone else.
<poolie> (copious time and all that )
<poolie> well, i'm sorry it was frustrating
<poolie> i think it was actually useful to get a few things explicit where people had different ideas in their head
<mkanat> lifeless: I think that just fixing the oopses on the LP branch seems a reasonable solution.
<lifeless> the frustrating bit is the handwave around resources
<lifeless> mkanat: thats what I've been asking for! :)
<lifeless> mkanat: I've been *offering* lp developers doing maintenance and triage on the main loggerhead project
<poolie> well, i've watched/tried to help jam spend ~6m getting his work deployed
<lifeless> but not with the unknown in trunk
<mkanat> lifeless: Yeah, that seems fine. I don't even think that most of those fixes need to go into loggerhead trunk.
<poolie> so i may not be pessimistic _enough_, but i think i'm at least fairly pessimistic
<mkanat> lifeless: At least, the oops fixes.
<lifeless> mkanat: I doubt that that will happen with trunk as different as it is :(.
<lifeless> we'll see
<mkanat> lifeless: Yeah. As long as you just stick to OOPS fixing, though, I don't think trunk would be missing out.
<lifeless> mkanat: it builds up debt
<mkanat> lifeless: And then when the feature squad has time in six months or so, merging them back in as appropriate could be done.
<mkanat> lifeless: True.
<lifeless> mkanat: at a certain point trunk will then be unfeasible to merge
<mkanat> lifeless: Well, hopefully we'd just be talking primarily about two fixes.
<lifeless> I don't know if that will happen or not; I hope it doesn't.
<mkanat> lifeless: Which should be small patches.
<lifeless> my bigger concern is community
<poolie> i will at least have a look at bug 701329
<lifeless> noone will be maintaining loggerhead per se
<ubot5> Launchpad bug 701329 in Launchpad itself "error: [Errno 32] Broken pipe" [Critical,Triaged] https://launchpad.net/bugs/701329
<mkanat> lifeless: Yeah. And there are outstanding review requests.
<lifeless> right
<lifeless> which I was aiming to solve by cunning :)
<poolie> and the other
<mkanat> lifeless: Ahhh, I see. :-)
<lifeless> mkanat: by having lp developers maintain the project, the various queues would be driven to zero: bug triage, code review
<mkanat> lifeless: Right.
<lifeless> mkanat: but doing that is contingent on it being straight forward, which an unusable trunk is not. (Yes, I know the nuance there)
 * mkanat nods.
<mkanat> lifeless: I think we'll just have to delay that for 6-9 months.
<lifeless> so, i think this is a bit sad. Shrug.
<mkanat> lifeless: And then at that point it can happen.
<poolie> canonical put time & money into historydb
<poolie> i really think we should either clearly decide it was wrong, or finish it
<mkanat> poolie: I think we're all in agreement about that.
<mkanat> poolie: It's just a question of when it will happen.
<lifeless> are we not allowed to say 'it was a spike, its not finished, put it to the side and perhaps later' ?
<lifeless> thats what francis was saying
<mkanat> lifeless: I think unmerging it would revert a lot of good refactoring that happened along with it.
<lifeless> mkanat: I agree, I think thats a shame. But perhaps better than 6-9 months without maintainer?
<mkanat> lifeless: Hmm.
<poolie> lifeless, well, yes, we're allowed, but
<lifeless> besides, its not lost per se, its mergable if/when someone decides they have the time.
<poolie> things being hard to change doesn't seem like a very satisfying reason to do that
<lifeless> this is all about resourcing.
<mkanat> lifeless: I think 6-9 months without a maintainer would be no different than it was in 2010.
<poolie> i'd be happier to say that if it turned out the design was actually bad
<lifeless> its a sunk cost
<lifeless> it wasn't resourced with a budget up front
<poolie> it's true it's a sunk cost
<lifeless> spm: 15:55 < mkanat> lifeless: This page has the wrong CSS: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/view/head:/.bzrignore
<lifeless> 15:55 < mkanat> lifeless: Because this file is in fact missing: http://bazaar.launchpad.net/static/css/view.css
<lifeless> 15:55 < lifeless> what css should it have?
<poolie> the question is, now that the code is there, does the cost of deploying it exceed the benefit we would get from deploying it?
<lifeless> 15:56 < mkanat> lifeless: That CSS exists in the actual branch.
<poolie> if deployment is very hard that may well be true
<lifeless> spm: can you look at how the /static/ path is accessed and see if perhaps we have something bong going on?
<spm> okidoki.
<lifeless> poolie: I don't see that thats the question. its a question sure, but *the* question is, where does completing that work fall in the queue for the various folk that might do it.
<mkanat> lifeless, poolie: My vote is to fix the two OOPSes on ~launchpad-pqm/loggerhead/devel, then wait 6-9 months, stabilize trunk, and then have the LP team maintain trunk.
<lifeless> poolie: its 6-9 months away for LP; even if it was the very best thing since sliced bread it would still be 6-9 months away
<spm> actually... I might even be able to hazard a guess as to what/where/why this fault exists....
<lifeless> poolie: *unless* it becomes a stakeholder priority, *or* is small enough for a maintenance squad to handle.
<mkanat> lifeless: I don't think it's a terrific emergency.
<lifeless> poolie: I've not argued its wrong or bad or whatever. But polish and doing it well matters a great deal.
<mkanat> lifeless: codebrowse sucks far less than it used to, already.
<poolie> i guess the axiom i have here is that zero timeouts is a priority, and that historydb is said to be the best way to get there
<lifeless> because if we get it wrong the costs are huge
<poolie> in that case it should not be shelved for so long
<poolie> perhaps there are less-risky ways to get there
<mkanat> poolie: Yeah. I think that "priority" in this case simply means 6-9 months.
<lifeless> zero timeouts are a policy
<mkanat> poolie: I think the least risky way would be to hire somebody to work on loggerhead.
<poolie> even just re-doing similar work but with stepwise deployments are a good idea
<lifeless> and I'm keen on those
<lifeless> things that are too big go into the feature queue to do, even timeouts.
<poolie> s/are a good idea/could be a safer course
<lifeless> which this falls into IMNSHO
<mkanat> lifeless: Are you with me on the "fix the two oopses then maintain trunk later" plan?
<lifeless> mkanat: I"m with you on fix the two oopses
<lifeless> mkanat: I hesitate to commit to the maintain trunk later plan, because it presupposes the outcome of a feature squad looking at this stuff
<mkanat> lifeless: Okay. In that case, "roll out history db in 6-9 months and then see how things go from there".
<lifeless> 'assign a feature squad to work on loggerhead performance in 6-9 months and see what happens'
<mkanat> lifeless: Sure, sounds great. :-)
<lifeless> pending flacoste and jml agreeing on priority/timeline
<lifeless> one obvious tactical move for such a squad is to pick this up (if noone has done it in spare / volunteer time in the interim)
<poolie> ok, so now back to the big one
<poolie> in that plan are we ok to leave lp on 1.18 and trunk a bit free-floating
<mkanat> poolie: Yeah.
<poolie> or shall we say what's in trunk was an experiment that's semi-abandoned, and move it aside?
<lifeless> thats to you guys
<lifeless> if you want maintainers from the lp team, no. If you don't care about that (indefinitely), yes.
<lifeless> It *was* an experiment and in the absense of maintainers, sure it must be considered abandoned.
<mkanat> poolie: I don't think it should be moved aside.
<mkanat> poolie: I suspect that in 6-9 months, the best thing for LP's feature team to do will be to stabilize and roll out trunk.
<lifeless> I don't have a particular investment in either answer; I have a strong bias towards having things be maintained when possible, and code that noone is looking after be clearly abandoned.
<lifeless> but its not 'my' project
<mkanat> lifeless: It was effectively abandoned before I started working on it, we'd just be putting it back into that state.
<mkanat> Well, besides the work that jam did on history_db, which was substantial. But nobody was fixing bugs.
<lifeless> mkanat: which is a shame, no ?
<mkanat> lifeless: It is, but it's also just a fact, and I'm okay with waiting 6-9 months for it to be resolved.
<mkanat> lifeless: I would love to keep working on it; that would be the most ideal solution given infinite resources. :-)
<lifeless> just for clarity, you think its better for users to have a nonresponsive project with some cool stuff unreleased in trunk than a responsive project with a 'future' branch earmarked for a later examination ?
<lifeless> mkanat: I'm assuming, perhaps incorrectly, that you're not going to be doing regular maintenance in your spare time.
<mkanat> lifeless: I think that trunk is probably stable and usable by everybody except LP.
<mkanat> lifeless: Yeah, unfortunately because I also maintain Bugzilla and some other stuff, I don't have a lot of spare bandwidth to do other free projects.
<lifeless> mkanat: I didn't say anything about the code quality
<lifeless> mkanat: or stability.
<lifeless> mkanat: which is totally understandable... I have the same quandry myself/
<mkanat> lifeless: I think it honestly wouldn't be that hard, if you're just doing simple OOPS fixes, to apply them both to trunk and the LP branch. But I also suspect that some of those OOPS fixes will not be quite so wanted on trunk.
<mkanat> lifeless: I could fix the issues and do the backports myself, with one more block of hours.
<lifeless> mkanat: we really want the lp team to get stuck into all the crannies
<mkanat> lifeless: Okay. If that's the immovable object, then I think the *simplest* solution is the one that we have proposed and agreed on.
<lifeless> the previous silo structure led to the state loggerhead was in 2010; bringing you in had great results but has left loggerhead out on the cold
<mkanat> lifeless: I would say that loggerhead is a separately-maintained modular dependency, not a silo.
<lifeless> what I want is the following:
<lifeless> mkanat: 'bugs', 'code', 'soyuz' etc - those were the silos
<lifeless> mkanat: lp team substructure
<lifeless> mkanat: we've just reorganised into squads with a project wide remit
<mkanat> lifeless: Yeah...that's a conversation that you and I already had. :-)
<lifeless> right ;)
<lifeless> so
<lifeless> what I want is:
<mkanat> lifeless: (BTW, I think that having developers flexible is good, but I think the individual components should still have assigned individual designers.)
<lifeless>  - a place for changes to the LP loggerhead to go for code review that code.launchpad.net/launchpad-project/+activereviews will pick up
<lifeless>  - ditto bug reports for bugs.launchpad.net/launchpad-project/+bugs
<lifeless>  - a clear and simple policy for what to do with changes to the project vis-a-vis upstream for developers. One of 'nothing', 'land upstream and do a release', 'file a patch upstream will review it'
<lifeless> if those three constraints are met, I will be satisifed. It may not be the globally best thing for canonical / bazaar / loggerhead, but I'll be confident that it will get acted on.
<lifeless> if any of them are not met, I'm confident it will become a spotty mess.
<poolie> it's already in /bazaar
<poolie> we read code reviews etc
<poolie> if lp developers put up changes i'm sure they will be piloted
<mkanat> lifeless: That sounds sensible. So I suppose what you could do is develop against launchpad-pqm/devel, and submit merge proposals against the trunk, but not have anybody assigned to do them.
<lifeless> there are multiple code branchces in that project that are not landed and approved
<mkanat> lifeless: Then at least when somebody was interested, they could go and look at the active MPs against trunk.
<lifeless> mkanat: with noone on the other end, that seems a bit noddy
<mkanat> lifeless: It's at least a method of making a queue to handle for the future.
<poolie> lifeless,  i have actually read them and they're not easily landable
<poolie> they could be bumped to wip
<lifeless> then they probably should be
<lifeless> jam: https://code.launchpad.net/~mnordhoff/loggerhead/history_db/+merge/25381
<mkanat> lifeless: Also, if you make the target reviewer ~bzr, eventually somebody will come along and do them.
<lifeless> mkanat: well, I'm assuming (because these are there) that that isn't the case.
<mkanat> lifeless: We could say that the Bzr team maintains loggerhead's upstream (without anybody actually assigned to do the work) and Launchpad maintains the launchpad-pqm branch.
<mkanat> lifeless: Oh, the reason those are there is that the default reviewer for loggerhead is wrong.
<mkanat> lifeless: It should be ~bzr instead of ~loggerhead-team, or whatever it is now.
<poolie> i think i added canonical-bazaar to that team
<poolie> or at any rate we can
<lifeless> so
<lifeless> corollaries
<lifeless> because lp is limited
<lifeless> I need a project in launchpad-project
<mkanat> lifeless: Ultimately I think we're just talking about what will happen for the next 6-9 months.
<lifeless> that can be a new one, launchpad-loggerhead repurposed, or loggerhead itself.
<lifeless> mkanat: I don't see this as timeboxed, unless we get rid of loggerhead
<mkanat> lifeless: I can't imagine the feature squad deciding that anything is that valuable besides stabilizing and deploying trunk.
<mkanat> lifeless: At which point the LP branch and trunk will become the same.
<lifeless> mkanat: sure
<lifeless> but they could still work off of a branch and let trunk be approximately unmaintained
<lifeless> or they could be doing releases
<mkanat> lifeless: Sure. But either way, there's no difference between the plans, after the 6-9 month timeframe.
<lifeless> sure there is
<mkanat> lifeless: You're positing the possibility that history_db never becomes trunk?
<lifeless> yes
<lifeless> and
<lifeless> that perhaps bazaar will maintain loggerhead
<mkanat> lifeless: Okay. So that bzr will maintain loggerhead seems somewhat likely.
<mkanat> lifeless: That history_db will never be trunk seems very unlikely.
<lifeless> or that what launchpad needs will be so unsuitable for trunk that trunk maintainers reject it
<lifeless> my crystal ball is broken
<mkanat> lifeless: Sure, but I have a bit more intimate knowledge of loggerhead and the problems it's faced, so I feel fairly confident in these predictions.
<mkanat> lifeless: Here's another possibility.
<mkanat> lifeless: You could merge ~launchpad-pqm/devel into 1.18.
<mkanat> lifeless: You could maintain 1.18 and do regular releases of it.
<mkanat> lifeless: Then LP would maintain the stable branch and bzr would maintain the trunk.
<mkanat> lifeless: That seems like a pretty reasonable solution for everybody.
<lifeless> mkanat: AIUI bzr don't have the cycles or domain experience to maintain loggerhead comfortably. IMBW.
<mkanat> lifeless: Ah, I think many of the devs have some casual knowledge of it.
<poolie> i think we're as well placed as lp, aside from being smaller
<poolie> i don't know
<poolie> i think you said you felt lp devs would be unwilling to work on it unless trunk was moved away
<mkanat> Yeah, poolie reviewed most of my code, jam did history_db, and some other folks submit patches from time to time and have done reviews.
<lifeless> I was extrapolating from my third constraint
<lifeless> poolie: ^
<poolie> i'm not sure i understand it
<poolie> is it "where do i send my patches?" or "what do i do with third-party patches?"?
<lifeless> how should I approach doing my changes
<poolie> understand lp's running 1.18; do changes off that; ask someone experienced to review them
<poolie> it doesn't seem particularly harder than requesting changes in lazr.restful or bzr or whatever
<poolie> s//proposing
<lifeless> lps review and bug ui lets us down here, but sure
<lifeless> I don't think you can propose merges cross-project
<lifeless> poolie: does patch pilot work off of https://code.launchpad.net/bazaar/+activereviews ?
<poolie> wow
<poolie> obviously not :)
<poolie> but, i was contemplating that last week
<lifeless> spm: any joy?
<lifeless> poolie: I think you need to decide how you want to hang it together; if you want to maintain loggerhead - great, we'll send you patches, and bugs, and so on.
<lifeless> poolie: I understood you to be focusing on udd + treading water
<lifeless> poolie: so it seems a bit inconsistent to me for you also be to be picking up maintenance of this, which was effective unmaintained for quite some time.
<lifeless> poolie: but its up to you
<mkanat> lifeless: I think loggerhead is an important part of bzr adoption.
<lifeless> poolie: I just don't want to be held captive to this outstanding work, and want a clear answer whether you would like the lp team to pickup maintenance (subject to the constraints I'm operating under)
<lifeless> poolie: I feel like every time we reach an agreement, its snatched away one email later
<spm> lifeless: too many other things exploding atm to get a look at beyond logging into the likely problematic server
<lifeless> spm: should we rt it ?
<lifeless> spm: or would that just be throwing hay into a barn fire?
<spm> well, aiui (need to confirm) static files are served off crowberry directly. if guava has been updated; yet not crowberry, then this sort of mismatch seems possible.
<lifeless> spm: yeah, thats what I'd expect needs checking
<poolie> i just want to get it to improve in the most efficient way possible
<poolie> i have been doing reviews on it
<poolie> as have others
<lifeless> we've spent 2 hours of three people - 6 man hours discussing the most efficient way.
<mkanat> poolie, lifeless: I'll leave you guys to decide this. I think having bzr maintain trunk and LP maintain 1.18 is probably a good idea.
<mkanat> I'm out for the night, now. :-) Goodnight!
<poolie> night
<poolie> :(
<mkanat> poolie: Did you want me to stick around?
<poolie> no, go
<poolie> i'm just annoyed this is getting stuck
<mkanat> poolie: Okay.
<mkanat> poolie: It's only stuck if you disagree that bzr should maintain trunk.
<mkanat> Anyhow, I'm out. :-)
<mkanat> Night!
<poolie> lifeless, do you think having bzr maintain trunk (as we have been, at a low level) is feasible?
<poolie> i guess that still leaves launchpad bugs meaning it's hard for lp devs to see the queue
<lifeless> well
<lifeless> as I said
<lifeless> I need an LP queue
<lifeless> for lp devs to review lp changes
<lifeless> and ditto bugs
<poolie> how about if we just leave them where they are
<poolie> and if lp developers are not getting reasonable turn around on their reviews, we deal with that?
<poolie> so far, bzr people have been doing reviews, and lp people have not been proposing them
<lifeless> poolie: I don't understand
<lifeless> lp changes to the lp loggerhead will be reviewed by lp devs
<lifeless> if they go upstream, if thats desired and there is an upstream, then having reasonable turnaround is indeed important
<poolie> ok, so you stated your constraints; what are mine?
<poolie> i think it's very unfortunate to be letting historydb bitrot because nobody will schedule time to deploy it
<poolie> but that is not really a constraint
<poolie> i am also concerned that we will make these rearrangements and then nobody will actually work on it, therefore leaving things actually worse off
<poolie> again, not a constraint
<spm> lifeless: so yes. /static is served off crowberry directly. both http or https. I guessing we have revno X on crowberry for LH, and X + Y on guava - hence the mismatch.
<lifeless> spm: but loggerhead runs on guava?
<spm> yup
<lifeless> I can has fix?
<spm> sorry, I don't understand?
<spm> we fixed it this way to stop codebrowse being overwhelmed serving static content
<lifeless> can you not serve it staticly from guava?
<spm> we did. it was bad.
<lifeless> oh
<lifeless> that surprises me
<lifeless> serving it out of loggerhead would be poor
<lifeless> but apache on guava?
<lifeless> spm: are you sure it was static on guava, not being handled by lh ?
<spm> it was being handled by lh on guava. there is no apache on guava. ?
<spm> I'd suggest apache on guava be unwise - just to solve a css file woe.
<lifeless> ok
<lifeless> I had no idea there wasn't one there
<spm> if you give me a bit I may even be able to enunciate why :-)
<lifeless> can you check the revno's ?
<lifeless> spm: is there an LP tree on crowberry we can point into instead of the one we do now, that would be more up to date?
<spm> sourcecode/loggerhead/loggerhead/static <== guava is 178, crowberry is 176.
<spm> revno 12263 vs 12177
<lifeless> and is there a view.ss on guava?
<lifeless> view.css
<spm> ahhh. codebounce is in nodowntime.
<lifeless> spm: so, we need an additional nodowntime deploy to a dir on crowberry, and apache pointing at that.
<lifeless> ?
<spm> I wouldn't call codehost a nodowntime deplot?
<spm> deply too
<spm> deploy 3
<lifeless> spm: (after we confirm a view.css exists on guava)
<spm> -rw-r--r-- 2 loggerhead loggerhead 519 2011-01-14 11:05 ./css/view.css <== guava
<lifeless> spm: what I mean is
<lifeless> codehosting cannot be nodowntime yet (rt something or other)
<lifeless> can we have a separate lp tree on crowberry
<lifeless> which would be*in* the nodowntime set
<lifeless> and apache would be pointed into that tree
<spm> just for static files? Ahhh I see. clever.
<lifeless> or apache on guava. your call :P
<spm> heh
<spm> yeah - I like that idea. bit ugly and heavyweight, but the alts are worse.
<spm> lifeless: oki. new 'launchpad-static' now on codehost; about to switch the softlinks to point into there....
<spm> and live
<spm> http://bazaar.launchpad.net/static/css/view.css <== looks good
<lifeless> spm: thanks!
<jelmer> 'morning
<damd> hi.  i'm working on a bzr branch here where i have revisions up to 4 and now i've made uncommitted changes to r4.  now i'd like to sort of "throw away" the changes in r4 and make the current state the new r4.  how would i do that?
<damd> i.e. i already have an r4, but i'd like to replace that r4 with the current uncommitted state which builds on r4.
<jelmer> damd: 'bzr uncommit'
<jelmer> followed by a new commit
<damd> okay, so my changes won't be lost that way?
<damd> they weren't, great, thanks
<damd> i just did a "bzr pull" and there was a conflict in a file.  now i've fixed that conflict.  so is everything swell now?  i'm worried that maybe i have to take some extra action to prevent e.g. a "merge" commit from appearing in the log once i commit, like the stuff that happens in mercurial unless you rebase.
<jelmer> damd: you'll have to run "bzr resolved" to let bzr know you've resolved the conflict (it will tell you this when you try to commit)
<damd> oh, okay, thanks
<jelmer> damd: we only create merge commits if you've actually done a 'bzr merge' invocation. 'bzr pull' will never create a merge commit
<damd> great!
<maxb> The behaviour isn't unlike Mercurial, for that matter
<Tak> isn't it not unlike mercurial?
<maxb> I suppose the difference is that "bzr pull" complains, whereas "hg pull" just reports (+1 heads) and leaves you with multiple local heads
<damd> if i remember correctly, in mercurial if you hg pull you need to make a "merge commit"
<damd> to avoid that you "hg pull --rebase"
<damd> but then again, i never bothered learning it properly
<Tak> you only need to do a merge commit if you have to do a merge
<damd> yes, of course
<maxb> It sounds to me that you are overly focused on avoiding merge commits
<damd> not overly focused, it's just that virtually every project i've worked on urge you to not make merge commits
<lifeless> in what VCS
<maxb> damd: I have noticed this too. Have any of those projects given a decent explanation as to why they urge that?
<damd> git (conkeror), hg (work) and now bzr (emacs)
<damd> maxb: ugly logs basically
<maxb> also git (postgresql)
<damd> no, i mean i worked on conkeror
<Tak> most git-using projects hate merge commits ime
<Tak> I haven't had any complaints from projects using other vcss
<damd> the only merge commits i find in emacs are the ones where they merge emacs-23 (bug fixes) to emacs-trunk (new features)
<maxb> So they don't have feature branches?
<damd> they have those too, but those merges are very rare
<Tak> but that's also because git makes a merge commit for EVERYTHING
<maxb> ?
<jelmer> Tak: it only makes a merge commit if a fast-forward isn't possible
<maxb> much like bzr
 * Tak shrug
<jelmer> maxb: bzr pull never makes a merge commit, bzr merge always makes a merge commit
<Tak> I feel like it happens a lot more often for me with git
<jelmer> maxb: or rather, sets the working tree up for a merge commit
<jelmer> maxb: that's different from the way git pull works
<maxb> OK, perhaps it is more accurate to say that the default way git pull works creates merge commits in much the same scenarios as a user of bzr would
<jelmer> maxb: I don't think that's true. In a lot of situations it's surprising that "git pull" creates a merge commit.
<maxb> Really? My understanding was that git pull will create a merge commit in exactly the same situations that bzr pull will say "branches diverged, you need to merge"
<jelmer> maxb: that assumes that a merge is actually what the user wants, which (at least I found) is often not true.
<jelmer> maxb: fwiw bzr can do the same thing using 'bzr merge --pull'
<quicksilver> jelmer: bzr merge --pull has the disadvantage of replacing your mainline revision numbering with the other branches revision number, doesn't it?
<maxb> No, it doesn't do that
<maxb> Oh
<maxb> I suppose it could
<jelmer> quicksilver: yes, but that's a problem with pull in general if the other branch has merged your tip and has additional revisions
<glen> does bzr support git like merges, so that original commit is preserved from merge?
<quicksilver> jelmer: yup.
<quicksilver> jelmer: just checking I understood :) We go to some lengths to keep monotonically increasing revision numbers on our branches
<jelmer> glen: yes
<glen> jelmer: any hints? :)
<jelmer> glen: how do you mean?
<maxb> quicksilver: You know about append_revisions_only, right?
<quicksilver> maxb: nope.
<jelmer> quicksilver: in general I think landing feature branches as merges is a good idea. it nicely groups them
<quicksilver> jelmer: agreed.
<maxb> quicksilver: It's a per branch setting to say "never change my existing mainline history"
<glen> jelmer: well. i did bzr merge ../path/to/branch, and when i did bzr commit, i had to type again commit message, but i'd like that commit messages that i merged get auto added, currently my commit after merge looks like i did the commit myself
<quicksilver> maxb: ah, interesting. Would stop a class of stupid error.
<maxb> That's the point of it, yes
<quicksilver> maxb: still, it's never a problem to pivot the branch by repulling the right revision and push --overwriting it.
<jelmer> glen: The merge has a reference to the revison that was merged
<quicksilver> maxb: the worst thing that happens is redmine gets terribly confused
<glen> jelmer: do you know is that merge rev visible in launchpad too?
<quicksilver> (it assumes, and caches, monotonically increasing revisions)
<jelmer> glen: much like in git, which also doesn't copy commit messages
<maxb> quicksilver: Huh. Sounds like its bzr integration wasn't exactly well thought through :-/
<jelmer> glen: launchpad's main branch page just shows the mainline revisions (so the merge revisions, not the revisions that were merged by those merge revisions)
<quicksilver> maxb: well, let's call it a known deficiency ;)
<glen> jelmer: ah, i see now. it's only in bazaar browser (http://bazaar.launchpad.net)
<quicksilver> maxb: we use loggerhead as well
<quicksilver> maxb: but we use redmine for issue tracking and it's convenient for the issue tracker to be able to see the repo
<maxb> quicksilver: Of course, if redmine auto-set append_revisions_only on all of the branches managed under it, it *could* assume that :-)
<maxb> jelmer: Hi, can we discuss bug 707170? My thought was that for the branches to be in the state they are, some software component must have done something wrong, and bzr-git seemed like the likely culprit
<ubot5> Launchpad bug 707170 in Bazaar Git Plugin ""Cannot add revision(s) to repository: missing text keys" branching lp:dulwich and alioth packaging branch into same shared repo" [Undecided,Incomplete] https://launchpad.net/bugs/707170
<jelmer> maxb: can you explain why though? bzr-git didn't touch the broken commit at all
<maxb> jelmer: Perhaps I'm misunderstanding, but I was interpreting that error as there being one revision-id that has bzr-style text-revision ids for some files in one branch, but bzr-git ones in the other
<maxb> So unless bzr core managed to rewrite the text-rev ids, the problem must be in bzr core?
<maxb> erm
<maxb> * So unless bzr core managed to rewrite the text-rev ids, the problem must be in bzr-git?
<jelmer> maxb: that one revision id was created by bzr core though - bzr-git hasn't touched it
<maxb> That's interesting. Does this hint at a potential bzr core bug, then?
<jelmer> it seems more likely to me that e.g. dpush has updated the working tree incorrectly and thus caused bzr core to create a commit with the wrong text revisions
<catphish> am i correct in thinking that the only way to set up hooks in bzr is to write a python plugin?
<jelmer> catphish: yes
<jelmer> there is a simple wrapper plugin that calls out to the shell but it doesn't cover all hooks, and requires per-branch configuration
<catphish> i might write my own wrapper that calls out to the shell
<catphish> i need to be able to define hook shell scripts on a per-repository basis
<catphish> http://people.samba.org/bzr/jelmer/bzr-shell-hooks/trunk/
<vila> jam: good morning !
<vila> jam: I'm looking at your reset-checkout proposal and I'm wondering what will happen if they are existing conflicts ?
<vila> jam: I smell bogus edge cases here
<CardinalFang> Hi all.  In Ubuntu, I'm interested in updating a package, but the source-package-branch is out of date with the current shipping package.  I heard I should mention it here, and ask for advice.
<maxb> What is the source package name?
<CardinalFang> "couchdb"
<CardinalFang> lp:ubuntu/natty/couchdb
<vila> https://bugs.launchpad.net/udd/+bug/653312
<maxb> Via http://package-import.ubuntu.com/status/ and the linked https://bugs.launchpad.net/udd/+bug/653312 I infer that a fix is not likely to be forthcoming in the immediate future, and therefore you would be best advised to do an update using the traditional methods for now
 * vila nods
<CardinalFang> maxb, vila, thank you.
<jam> vila: honestly, I don't really care about those edge cases much. for conflicts, it probably leaves them alone
<jam> this is more about "my dirstate is corrupted, fix it"
<vila> jam: my point is not to fix every edge case but let the user know some may exist (reviewing)
<vila> jam: you care at least enough to offer the ability to restore the merge parents though, I don't want users to be fooled
<vila> jam: this is a great addition, so let's publicize what it reallt does
<jam> I'm not sure I want it to be particularly public. Since it is a 'repair something broken' tool. I don't want people to think it happens often
<jam> it has happened just often enough and the workaround is clumsy
<vila> jam: I' all for leaving it hidden, what I mean (already written in the not-yet-posted review) is that when the repair succeeds, a warning should tell the user about limitations
<vila> jam: review posted
<vila> jam: spoiler: BB:tweak ;)
<sobersabre> hi.
<sobersabre> I have a q which may sound a bit trollish. but it's not.
<sobersabre> what was the idea behind STARTING bzr  ?
<sobersabre> I mean it is python. there was python project already (hg)
<jam> sobersabre: technically we were first, I believe
<jam> certainly the start date is very close
<damd> also, bzr is GNU
<jam> sobersabre: we talked about joining at one point. I think the primary sticking point was copyright, followed by some disagreements about structure. We wanted to be abstract and support multiple concrete formats, etc.
<LeoNerd> There was also a lot of history in baz, the Canonical fork of tla; Tom Lord's Arch..
<LeoNerd> A C reimplemetnation of the orignal GNU arch; a revision control system written in shell scripts (I kid ye not)
<LeoNerd> There's no code sharing between baz and bzr, but bzr was started by a lot of the same developers who first worked on baz; shares some of the ideas and concepts... at least initially
<LeoNerd> .oO( Except for cherrypicking... </bitter> )
<sobersabre> jam: thanks.
<sobersabre> now bzr q.
<sobersabre> :)
<sobersabre> I want to take a branch with all its history, and put it into a subfolder of another (unrelated branch), with all the branch's history, and mold them together into 1 branch.
<sobersabre> I saw a plugin "merge-into",
<sobersabre> is there a way to do it without giving birth to a hedgehog and avoid using this plugin ?
<damd> ...
<maxb> sobersabre: You want 'bzr join'
<maxb> sobersabre: However, first please check the format of the two branches
<maxb> If they are both poor-root type, this may be an issue
<sobersabre> maxb: I am on 2a formats.
<sobersabre> on both branches.
<sobersabre> thanks for join.
<maxb> In that case, bzr join should just work
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.2.3 is officially out ! (rm vila)
<bialix> heya GaryvdM
<GaryvdM> Hi bialix!
<bialix> I have couple of questions to re windows-installers branches
<GaryvdM> ok
<bialix> I'd like to merge Naoki's patches
<bialix> but wonder if we need 2 separate branches for bzr 2.2.x and 2.3.x
<bialix> Naoki's improvements are definitely for 2.3 only, IMO
<bialix> GaryvdM: ^
<GaryvdM> bialix: I should be possible to code it so that you can define different versions for 2.2 and 2.3 in the same branch
<vila> I'd say focus on 2.3, but that's just me :)
<GaryvdM> Hi vila
<bialix> bonsoir vila
<vila> hey GaryvdM, hello bialix
<vila> I'm tweaking qbzr tests so they can be run with --parallel=fork
<vila> I just succeeded and will send an mp :)
<bialix> GaryvdM: for 2.3 there is used tag:bzr-2.3b1, it does not sound right for me
<GaryvdM> Whether that is the best way to do it or to have different branches - I'm not sure.
<GaryvdM> yes - that should be 2.3b5!
 * bialix wonders how Gary built the latest installers
<GaryvdM> Hmm - let me boot the vm I built on and check. I may have forgotten to push
<bialix> GaryvdM: on the other hand the changes are straightforward, and I think we may want to upgarde TortoiseOverlays to latest version for all bzr versions
<bialix> and removing unused w.exe is not big eal
<bialix> and removing unused w.exe is not big deal
<bialix> GaryvdM: I need you final word
<GaryvdM> ok
<GaryvdM> bialix: I would rather not change to much in 2.2. If there are bugs that people are complaining about, then yes, but otherwise I think rather stick to the known.
<GaryvdM> brb - nature call.
<vila> . o O (Strange name for a phone...)
<GaryvdM> Ah - not phone. That's slang for the toilet :-)
<vila> hehe, I know :)
<vila> ./bzr selftest -s bzrlib.plugins.qbzr --parallel=fork ===> Ran 153 tests in 2.271s
 * bialix remember the walk to Chateau de La-Hulpe
<vila> instead of Ran 153 tests in 4.161s
<vila> hmm, at least windows popping all over the place are more fun
<bialix> yep
<vila> they pop all together with --parallel=fork
<bialix> jumping jack
<vila> anyway, patch is up for review
<vila> bialix: exactly :)
<GaryvdM> vila: thanks for the patch. I
<bialix> GaryvdM: if we don't want to change 2.2 installers then I think we need to create separate branch for 2.2 installers
<bialix> GaryvdM: will it be too much trouble for future 2.2 releases?
<bialix> for you?
<vila> keep in mind that the cadence will slow down for 2.2 once 2.3 is out
<GaryvdM> vila: I want to review the excepthookwatcher stuff carefully - so I'll review in the morning when I have a fresh brain :-)
<bialix> I know, but you just released 2.2.3
<vila> GaryvdM: sure
<GaryvdM> vila: There is a bug in the qbzr test where a failing test can cause others to fail, when there is nothing wrong. I suspect you changes may fix that (well hoping).
<vila> bialix: indeed and the next planned release is 2.3.0, then 2.3.1 then 2.4b1 and only then and if needed 2.2.4
<GaryvdM> bialix: I don't think thats nessary - I'm going to look now.
 * fullermd is bummed that we never had a 1.1.2.3.5
<vila> . o O (CVS lovers....)
<bialix> oh, I thought we left 1.1.1.1.1.1.1.1 numbers long ago
<vila> well, we avoid them so far but who knows, may be someone will find a good use :D
<bialix> GaryvdM: this change https://code.launchpad.net/~songofacandy/bzr-windows-installers/remove-unused-wexe/+merge/44708 affects Inno Setup script, that's shared between bzr installers
<fullermd> It's not CVS lovers, it's math geeks   :p
<vila> yeah, yeah, stop pretending :-P
<GaryvdM> bialix: oh - ok I see what you mean now.
<bialix> GaryvdM: well, it's possible to extend issgen.py to allow using different templates for different bzr releases
<bialix> if you want I can look into this
<GaryvdM> bialix: maybe different branches is easier
<bialix> although it increases complexity of the tool with almost no value
<bialix> so yes different branches might be easier
<GaryvdM> vila: do you have 1 branch, or different branches for the mac installer?
<vila> 1 branch per series + trunk
<vila> this sometimes requires some cherry-pick and always require careful merging for config.py (which defines what version of which plugin is packaged)
<vila> but otherwise it works flawlessly ensuring that we don't try to do too much in older releases
<bialix> Ian made it a bit better for windows installers, IMO
<GaryvdM> vila: Has the merging caused any errors in the past?
<vila> not that I know of but I am a noob there having built what... 4 or 5 installers
<GaryvdM> ok - I'm asking to just try get a feel for what works.
<vila> The nice thing with separate branches is that you have a clean history of the releases and what installer modifications went from one branch to the other
<vila> weird, -s bp.plugins.qbzr succed but running the full test suite still fail some qbzr test...
<vila> test isolation related problem probably
<vila> hey poolie !
<GaryvdM> vila: I Think thats problem I was talking about just now. Is it a treewiget test?
<vila> yup
<vila> re-running
<vila> GaryvdM: bzrlib.plugins.qbzr.lib.tests.test_treewidget.TestTreeWidgetSelectAll.test_commit_selectall
<vila> GaryvdM: bzrlib.plugins.qbzr.lib.tests.test_treewidget.TestTreeWidgetSelectAll.test_add_selectall
<vila> GaryvdM: ha ha, tricked by a leaking excepthookwatcher.pyc
<GaryvdM> vila: :-) I've done that before
<GaryvdM> vila: I've just discovered another reason why it happens (and no surprise, it involves a global variable)
<vila> GaryvdM: I'll need to update my submission
<vila> GaryvdM: which one ?
<GaryvdM> vila bp.qbzr.lib.util.loading_queue
<vila> overrideAttr(bp....util, 'loading_queue', None) in the relevant setUp should fix it
<GaryvdM> Yes - but I also want to investigate a but as it may need a try...finally somewhere.
<vila> overrideAttr is good at avoiding try/finally if you need to purge this queue, addCleanup may help too
<GaryvdM> vila: The "missing try...finally" is in the code, not the tests, but I will also add your suggestion for an extra level of test isolation protection.
<vila> GaryvdM: oh I see
<vila> RuntimeError: cannot join thread before it is started... never saw this one :)
<vila> GaryvdM: so, I updated my mp but  the 2 failures are still there...
<GaryvdM> vila: I should have a fix soon :-)
<vila> yeah !
<vila> I'm pretty close being able to run bzr selftest *without* --no-plugins or BZR_PLUGINS_PATH tricks
<vila> I'm pretty close being able to run bzr selftest *without* --no-plugins or BZR_PLUGIN_PATH tricks
<vila> GaryvdM: I added a self.assertEqual(None, util.loading_queue) which didn't trigger
<GaryvdM> Oh
<vila> double checking
<GaryvdM> Merging you mp now...
<GaryvdM> vila: both you fix + mine now in lp:qbzr
<GaryvdM> *your
<vila> pulled, running
<vila> GaryvdM: still 2 failures :-/
<GaryvdM> vila: the same tests?
<vila> exact some ones, yes
<GaryvdM> AssertionError: not equal:  a = [] b = ['changed'] ?
<vila> both fail because they miss unversioned-with-ignored
<vila> no
<GaryvdM> vila: Please pastebin error.
<vila> http://paste.ubuntu.com/559265/
<GaryvdM> Ty
<GaryvdM> vila: any tips on how to reproduce?
<vila> bzr selftest --parallel=fork
<vila> :-/
<vila> that is: the whole test suite
<GaryvdM> ok
<vila> I can try to isolate a bit more but this is never trivial
<GaryvdM> :-/
<vila> GaryvdM: one possible cause is that the tests pass when run sequentially because another test is doing some init that is missing when run in parallel
 * GaryvdM runs grep global . -r
<GaryvdM> vila: Does it fail if you run bzr -s bp.qbzr --parallel fork?
<vila> no
<GaryvdM> Ok - same for me
<vila> and meither if I run bzr selftest -s bp.qbzr.lib.tests.test_treewidget.TestTreeWidgetSelectAll.test_commit_selectall
<vila> so s/init/something/ above
<poolie> jam?
<jam> hi poolie
<mathrick> jelmer: any plans to add support for darcs repos?
<mathrick> I can see how that might be tricky, given the completely opposite ways darcs and bzr look at trees and patches
<poolie> jam, when you said "going on the 26th, or more like the 23rd sounds like it works better for me" which month was that?
<jam> poolie: The 9th isn't possible, as you know. Going the week ahead would work for me, but you didn't list it as a possibility.
<jam> going the direct week after would be bad
<jam> because my wife has to do late-night phone calls
<jam> so 2 weeks after or 1-2 weeks before is ok
<jam> Or put in sequence:
<poolie> i understand now
<jam> Apr 25 good, May 2nd good for me, May 9, 16 bad for me, May 23rd good again
<poolie> ok, and the 30th of May good too?
<vila> GaryvdM: I got the failures wi th'bzr selftest' even without --parallel=fork, weird
<GaryvdM> vila: I have a suspicion. I'm making a branch with a whole bunch of trace.mutters to check.
<jam> poolie: yeah, should be fine.
<jam> Lina says she'll have a definite schedule first week of Feb
<vila> jam, poolie: 30th of May won't be good at my place, too close to Marie's exams
<jam> poolie: I'm off for now. I really feel like we should be pushing to get history-db deployed for loggerhead. I can't say there won't be any regressions, but other than initial import speed, everytime I hit something, I end up making it 10x faster than the current production code.
<jam> I realize it shouldn't be my priority to work on it
<jam> and I'll try to stop poking after today
<poolie> it's always really disappointing to leave good work undeployed
<poolie> and looking back on my mail, i think that we did basically have a deal with lp that if you did this, they'd deploy it
<poolie> for various reasons, some good some bad, some due to you and me not pushing it, that wasn't followed through
<jam> poolie: I def see how not having a good test suite hurts being able to maintain the software, though.
<jam> because when I make changes, I know that the things *I'm currently testing* are ok, but I don't know about far-reaching implications
 * vila nods frantically
<jam> vila: what are you doing here ?
<jam> :)
<GaryvdM> vila: lp:~garyvdm/qbzr/debug_select_all_test - But I think we should stop now.
<vila> jam: fighting jetlag by hopefully reversing the pattern from these last days, staying up later to sleep between 1 and 6AM
<jam> I guess yesterday you were waking up at this time?
<jam> Anyway, i'll lurk for another 15min or so, but then I'm going to be away till tomorrow.
<poolie> jam, i know what you mean about tests
<poolie> jam, i'm so happy you got the things merged and the tests passing
<poolie> i'm fine for you to push it as a 20%-type thing
<vila> jam: roughly yes but then I couldn't sleep until 6AM...
<poolie> i do think that as well as getting it technically ready you will need to work on lining it up to be deployed
<poolie> ie: do they have any concerns about the approach; are we able to deploy it on staging (etc) to test it;
<lifeless> jam: I think history db is really nice
<lifeless> jam: I'm keen to see it live; we're working within a bunch of constraints that were not really present a year ago - and if present would have given a much stronger focus to moving things forward.
<poolie> anyhow, so getting a thread (maybe a new thread) about what those constraints are may be good
<poolie> or maybe a lep
<vila> GaryvdM: ok, trying it now but I agree we should stop
<poolie> that's kind of more important than the actual speed
<poolie> it could be 100x faster, but if it will not be deployed that just makes it more sad
<lifeless> so
<lifeless> broadly they are
<lifeless>  - limit work in progress by the lp squads, no more dancing all over the map
<GaryvdM> vila: ok - Goodnight
<lifeless>    which implies not accepting handoffs that haven't been slotted in - help folk to self service instead
<GaryvdM> Goodnight all
<vila> GaryvdM: see you, I'll send a mail with the failure result
<lifeless>  - data driven / operational excellence - analyse and fix the oopses we're getting
<lifeless>    also add loggerhead to the page performance report
<lifeless>  - we need to get timing data in the loggerhead oopses
<lifeless>  - iterate until the picture is clear about /what/ is wrong in terms of coarse user experience
<lifeless> e.g. it may be that what we're really suffering is sqlite cache file contention cross-thread within single loggerhead processes
<lifeless> at each point, we broadly want to do the single thing that will solve the most observable issues
<lifeless> (think pareto analysis)
<poolie> so: _should_ john push on this, or is it going to be too hard to get it deployed without active help from a squad?
<jam> lifeless: I don't mind pushing a bit, but things get blackholed so often. I don't really know *how* to push lp-serve, for example. It is in an rt, and at that point... I poke at francis and poolie?
<lifeless> jam: so its live on qastaging ?
<lifeless> jam: AIUI ?
<jam> lifeless: yes
<lifeless> jam: in which case, hammer it until you're happy its robust
<jam> lifeless: done
<lifeless> jam: look in the qastaging OOPS report summaries for anything related to it
<jam> it faild at one point
<lifeless> jam: and then file an RT for production
<jam> as near as I can tell it was because it wasn't restarted as part of the deploy code
<jam> I've filed an RT for staging, which is "stuck"
<jam> handed off to SPM, I believe, and then ... I don't knwo
<jam> knw
<jam> know
<lifeless> spm: ping
<lifeless> jam: staging is irrelevant for getting it on production
<poolie> so to answer the general question, you just need to ask them, or me
<spm> lifeless: hola
<lifeless> spm: ^ jam's rt - do you know where that is at?
<spm> waiting for me to get around to it
<spm> currently I've got 3 LS ones (variants on the same theme) and an ISD one ahead in terms of getting things done; as well as the edge redirector excitement.
<jam> spm: any idea on timeframe for that?
<jam> Is it possible to just upgrade that to rollout onto production, if it isn't necessary to roll out on staging first?
<jam> Mostly I'm trying to get *some* momentup
<jam> momentum
<spm> no idea unf. I spent purty much all of yesterday completely reactive to alerts. got maybe 15-20 mins to spend on RT's.
<jam> and I thought staging would at least get stuff moving.
<lifeless> jam: so, for clarity
<jam> But if the round-trip-to-get l-osa time is the block
<lifeless> jam: the pipeline ordering is production<-qastaging<-staging
<jam> then I'm happy to skip steps
<lifeless> jam: if its been checked on qastaging, its totally ready to move forward
<lifeless> jam: we only have to check *db schema changes* on staging
<jam> lifeless: that wasn't the info I heard
<jam> since qastaging was "we'll blow it away often"
<jam> vs "public people test stuff on staging"
<lifeless> jam: same for staging
<lifeless> no
<lifeless> qastaging and staging have the same lifetime guarantees (none)
<jam> lifeless: *developers* test on qastaging and 3rd parties use staging (from all the conversations I've overhead)
<lifeless> jam: where did you get the info, so I can correct it
<jam> heard)
<jam> lifeless: the bug import discussions
<jam> etc
<lifeless> 3rd parties are permitted to play with either qastaging or staging
<lifeless> developers test db schema stuff on staging, and (approximately) all other things on qastaging
<lifeless> things that we can we put behind a feature flag w
<jam> also comments saying that if qastaging breaks, no big deal, and I haven't heard that for staging
<lifeless> its a huge deal
<lifeless> if qastaging is broken we cannot deploy
<lifeless> the entire qa workflow breaks down
<poolie> because there is only one qastaging for the whole site
<poolie> over the rainbow, it would be modularized enough you could run something representative on a dynamically-allocated domain
<jam> see y'all tomorrow (if you're around :)
<vila> jam: cu !
<lifeless> mmm
<lifeless> I don't think thats a great idea poolie
<poolie> oh?
<lifeless> we have many complex parts, its all to easy to bring up a shiny short lived instance
<lifeless> its the heavyness of the whole thing that lets us learn about issues in qa
<lifeless> its only by having a 250GB db behind it that we can see various query change impacts, for instance.
<lifeless> mkanat: btw the css is fixed
<mkanat> lifeless: Great!
#bzr 2011-01-28
<lifeless> mkanat: hi
<mkanat> lifeless: Hello.
<lifeless> mkanat: do you know if we've deployed your fix for https://bugs.launchpad.net/loggerhead/+bug/643497 yet ?
<mkanat> lifeless: I've never seen that bug before.
<mkanat> lifeless: Oh wait.
<mkanat> lifeless: Yes, you have deployed that.
<mkanat> lifeless: That is a dup.
<lifeless> spm: ping
<lifeless> spm: is it possible that nagios etc are generating 7K requests a day per loggerhead instance?
<lifeless> spm: including direct, and via ha proxy and via apache
<poolie> ok, out for a bit
<spm> lifeless: not that I'm seeing - I did a grep on check_http on prod-1, and only saw ~ 15 an hour. Tho ... now the brain engages, we have two. behind a haproxy. which does it's own separate check. betcha dollars to peso's....
<AfC> Gotta love proxies. "Yes, the web site is responding. And rapidly at that!" "With what?" "Dunno. Does 404 mean anything to you?"
<chx> how can i see changes made in a branch, no merges?
<AfC> $ bzr status --no-pending
<chx> AfC: i mean, the already committed changes to the branch
<chx> AfC: log shows the branch the commit "branch nick" and whether it's a merge or not, i juts want a cumulative diff for the commits to the current branch , no merges.
<AfC> $ bzr diff -r -2..-1
<chx> ahhhh
<chx> ancestor:
<chx> gotcha!
<AfC> Oh. You're asking about relative to _another_ branch. You didn't say that.
<AfC> Yes, ancestor:../mainline (or whatever) is very useful indeed
<chx> mmm beautiful
 * chx staples the diff to a pink slip and mails to his boss
<chx> just as i thought...
<chx> very useful indeed.
<jelmer> good morning #bzr
<GaryvdM_work> chx: also, if you have a submit branch set, submit: is a short cut for ancestor:<path to submit>
<vila> GaryvdM_work: http://paste.ubuntu.com/559415/ (sorry I forgot to mail this yesterday)
<vila> goooood morning jelmer !
<chx> GaryvdM_work: good to know. next time i need to fire a developer based on his (non) work i can use that :D
<GaryvdM_work> vila: thanks - My suspicion  was wrong, but I now have a better idea where to look.
<vila> GaryvdM_work: excellent !
<vila> GaryvdM_work: feel free to poke me at anytime if you want more tests, I know how hard it is to debug something any mean to reproduce and this one seem like a damn stealth bug
<vila> poolie: hey !
<GaryvdM_work> vila: did you sleep well?
<vila> GaryvdM_work: I *slep* which is a huge progress :D
<vila> slept, rats
<vila> I still feel a bit like crap, but that's at 8pm instead of 11 or 12...
<vila> poolie: well done with the kanban stuff, I just found a bug that I forgot to mark fixed released !
<vila> poolie: the card give links for both the bug and the branch ! Awesome !
<vila> poolie: when are the pages updated ?
<jelmer> hi vila, poolie, Gary!
<GaryvdM_work> Hi jelmer
<vila> maxb: any update about SRU/MRE for 2.2.3 ?
<maxb> update?
<vila> maxb: what is left to be done, where are we ?
<vila> lp:~maxb/ubuntu/maverick/bzr/sru/ doesn't include 2.2.3 and
<maxb> I don't think anyone has tackled updating the packaging for 2.2.3 yet. I could look into that over the weekend
<vila> lp:ubuntu/maverick/bzr/ is still at 2.2.0
<vila> maxb: that would be awesome
<mgz> morning all.
<jelmer> hi mgz
<vila> maxb: tell me if I can help here
<vila> hi mgz
<maxb> NB lucid is in SRU freeze at the moment
<maxb> Although we somehow seem to have not started discussing SRUing lucid, even though it's the LTS
<vila> maxb: from your explanations I thought we should start with maverick
<poolie> hi vila, jelmer, gary, maxb
<vila> maxb: which is 2.2 and that's the one I mostly interested in, lucid is only at 2.1
<poolie> vila, at the moment i built the kanban on my laptop and uploaded it
<maxb> Well, we need to include maverick, certainly
<poolie> i might see about running it somewhere more central
<poolie> let's say roughly daily for now
<vila> poolie: daily is fine by me to start with but if we can target hourly it will be better in the long run
<GaryvdM_work> Hi poolie, maxb, mgz!
<maxb> Lucid is going to need a SRU sooner or later to clear up those pesky references to the LP beta API that got left in
<maxb> Because the LP beta API is supposed to expire on the death of Karmic
<vila> maxb: sure, I'm forgetting lucid, but I'd like maverick first
<vila> meh
<maxb> (i.e. in three months)
<vila> I'm *not* forgetting
<vila> maxb: And I'm not *that* concerned about LP beta API, there are other clients and I suspect LP will have to take them into account even after we manage the lucid SRU
<maxb> mm
<maxb> https://launchpad.net/+apidoc/
<maxb> Warning has been given
<vila> maxb: I've landed the relevant patches on all releases for bzr, *we* are ready
<poolie> vila, i'd just need to get the dependencies installed on devpad or whatever
<poolie> at the moment it is staff-only
<maxb> oh - neat
<poolie> it might be better off public, if we omitted private bugs
<maxb> right, byebye, I should go to the office now
<vila> maxb: enjoy !
<poolie> jelmer, are you back at work today or just saying hi?
 * vila set mode +just_say_hi
<vila> :)
<jelmer> poolie: I'm back at work
<poolie> vila, really all references to beta are gone? just recently?
<poolie> welcome back; i wondered if you would help vila push our srus through?
<poolie> also, i'm going to the developer membership board on monday evening utc to ask for ppu for bzr
<poolie> maybe you should too?
<vila> poolie: yes, but we may need to cut releases for 2.1 and 2.0,
<vila> poolie: but 2.2 first
<jelmer> poolie, vila: Sure, I'd be happy to
<poolie> vila, bzr.2.2 in bzrlib/plugins/lp_api still has hardcoded urls for the beta service root
<poolie> they probably shouldn't be hardcoded at all but they may predate lplib facilities to get them
<vila> meh, for 2.2.3 ?
<poolie> in 2.2 tip
<vila> haaaaa beta not edge !
<vila> maxb: ^ I was wrong
<poolie> yes, there are two similar but different things
<poolie> edge, and beta
<poolie> edge is a bit more urgent
<vila> edge is done
<poolie> there's a separate bug about beta
<vila> hmm, and I suspect we have no tests about whether we use 1.0 supported features :-/
<poolie> hm
<poolie> i don't think we have any tests about interaction with lp
<poolie> which would be the main way to catch it
<vila> <shudder/>
<poolie> in theory you can statically check against the wadl, but not so easily in python, or with the approach lplib takes
<vila> poolie: The more I think about it, the more I feel the launchpad plugin should not be in core but part of launchpad itself
<vila> poolie: this way we could stop worrying about 1) testing it properly 2) being compatible with launchpad
<vila> poolie: we will still package it in our installers and other packagers should be warned to do it too if/when we switch
<poolie> mm
<poolie> we still need to work out how to test it
<poolie> but it does create some special cases by being in the tree and yet a plugin
<poolie> i would probably test it by having an environment variable giving the service root to test against
<poolie> and making the tests skip if that's not set
<vila> poolie: so lp devs can test it properly ? Sounds fine to me and could even be set on babune if/when I manage to run a local lp vm
<vila> but that's still significantly more work for me than for an lp dev
<poolie> anyone who changes the plugin code, or things it relies on, needs to test it
<poolie> if we use a variable, they can test it either locally or against staging
<poolie> if it makes minimal assumptions about what will be in the instance
<GaryvdM_work> vila: how long does it take for you to run the whole test suit?
<vila> GaryvdM_work: < 10 minutes with ---parallel=fork
<vila> poolie: meh, where are you :(
<jelmer> vila: is there a bug # for the SRU?
<GaryvdM_work> vila: Is there a way to run the test suit across multiple computers?
<GaryvdM_work> --parallel=cluster :-)
<vila> jelmer: bug #687653 will be a good candidate for 2.2.3
<ubot5> Launchpad bug 687653 in Launchpad itself "infinite recursion trying to format NotBranchError" [Critical,Fix released] https://launchpad.net/bugs/687653
<vila> GaryvdM_work: there is a plugin for that named ec2 something
<GaryvdM_work> Oh - cool
<vila> GaryvdM_work: without plugins it's ~5 minutes
<GaryvdM_work> vila: cool - I have managed to reproduce
<vila> GaryvdM_work: cool !
<jelmer> vila: I've pushed a branch to lp:~jelmer/ubuntu/maverick/bzr/proposed-2.2.3
<vila> jelmer: rock&roll
<vila> branching
<vila> jelmer: the test were run and passed during build right ?
<jelmer> they should have been, but the package did build fairly quickly. Let me double check
<vila> debian/rules contains a selftest invocation at least
<vila> jelmer: regarding bug #704647 does  http://paste.ubuntu.com/559471/ looks correct to you ?
<ubot5> Launchpad bug 704647 in Ubuntu Distributed Development "lp-propose default target doesn't work for packaging branches" [High,Fix released] https://launchpad.net/bugs/704647
<vila> jelmer: I needed it to lp-propose a bug branch
<vila> jelmer: i.e. not related to  a packaging branch
<vila> jelmer: and should I attribute the lag since your 'Let me double-check' as an indication that something went wrong ?
 * jelmer looks
<jelmer> vila: no, I'm waiting for the package to build
<jelmer> vila: +1 on that patch
<vila> ha good, not so fast then ;)
<vila> jelmer: ok, I'll make a proposal for it then
<vila> jelmer: I'll take your branch as a base to see if you added tests for it (unlikely as it seems to be closely tight to lp anyway :-/)
<jelmer> vila: no, there aren't any tests for this code unfortunately :-/
<vila> jelmer: np
<vila> jelmer: https://code.launchpad.net/~vila/bzr/704647-lp-propose/+merge/47790
<jelmer> vila: +1, thanks!
<jelmer> heh, we voted Approve within 3 seconds of each other :-)
<vila> jelmer: my pleasure
<vila> hehe
<vila> but I sent it to pqm first !
<jelmer> :)
<vila> GaryvdM_work: any news ?
<vila> jelmer: any news ?
 * vila sets mode +any_news
<jelmer> vila: what kind of news are you looking for?
<vila> jelmer: the test were run and passed during build right ?
<vila> jelmer: I'm waiting for your feedback to nominate bug #687653 for SRU
<ubot5> Launchpad bug 687653 in Launchpad itself "infinite recursion trying to format NotBranchError" [Critical,Fix released] https://launchpad.net/bugs/687653
<vila> jelmer: or did I misunderstood something ?
<jelmer> vila: yeah, that's a good one for the SRU
<jelmer> garr, looks like I should enable swap on my laptop again.. it goes bonkers without it
<vila> jelmer: I want to say that the tests passed during build, hence my question :)
<vila> jelmer: buy a real desktop ;)
<jelmer> vila: I've got one.. it's just not the machine I was running the tests on :-)
<vila> oooh, you mean the build is still running ?
<jelmer> vila: looks like there was actually one failing test
<vila> which one ?
<jelmer> vila: the packaging required 'test' to be specified in DEB_BUILD_OPTIONS, it didn't enable them by default. I've fixed that now, too.
<jelmer> vila: the test_locale issue we fixed last week. I'm cherrypicking the fix.
<vila> jelmer: you rock, don't forget to fire a mp for lp:bzr/2.3 too
<vila> good morning jam !
<jelmer> hi John!
<jam> hi vila
<jam> and jelmer
<jam> Peng: if you're around, I had a loggerhead Q for you
<exarkun> http://buildbot.twistedmatrix.com/builders/lucid32-py2.6-select/builds/513/steps/bzr/logs/stdio
<exarkun> I dunno if that's the same basic problem as https://bugs.launchpad.net/bzr/+bug/701940 or not.  It happened in the same place under (one supposes) roughly the same circumstances.
<exarkun> It looks kind of similar, in that the error seems to be about a missing .pack file.  But it's not reported /exactly/ the same way.
<jelmer> bug 701940
<ubot5> Launchpad bug 701940 in Bazaar "Pack moved to obsolete_packs, but still referenced in pack-names" [High,In progress] https://launchpad.net/bugs/701940
<vila> exarkun: what bzr version are you using, this bug is fixed in 2.2.3 (released), 2.3.0 (unreleased) and trunk
<exarkun> vila: I'm using 2.2.3
<exarkun> The one packaged for lucid in http://ppa.launchpad.net/bzr/ubuntu/
<vila> that's bad :( File a new bug mentioning 701940
<exarkun> okay, will do
<vila> IIUI, issuinga 'bzr pack' locally should work around the problem
<vila> the weird thing is that it occurs on a buildbot instance which should do commits by itself, only pulls no ? Ha, wait, there may be concurrent pulls there..
<vila> s/issuinga/issuing a/
<vila> s/should do/shouldn't do/
<exarkun> vila: Yes, it is concurrent.
<vila> exarkun: 'bzr pack' during happy hours :-}
<vila> and definitely file a bug
<vila> exarkun: no-on is pushing there with a different bzr version right ?
<exarkun> right
<exarkun> it's only pulls
<vila> exarkun: so forcing 'bzr pack' should reduce the occurrence of the bug
<exarkun> vila: Once?  Once in a while?  Before any pull?
<vila> exarkun: well, depends on how often it occurs, *between* the pulls if there is such a time slice
<exarkun> This is the first time I've seen it happen, over probably about a month of operation.
<exarkun> But that probably just means a hidden variable suddenly changed and the probability when from ~0% to ~100%
<vila> or two pulls were identical ?
<exarkun> They're probably usually identical, I guess
<jelmer> that's what the other bug was related to, too
<exarkun> There's two builders on the machine using a shared repository
<exarkun> So when a build is triggered they both probably try to pull exactly the same thing into it
<vila> a more drastic workaround would be to use one shared repo by builder until the bug is fixed :-/
<exarkun> if it turns out to happen with much frequency, I'll probably do that
<exarkun> if not, I'd rather leave it in this configuration and keep reporting bugs :p
<exarkun> someday it will have to work right, right?
<vila> exarkun: that's more valuable for us :) Yeah, definitely
<vila> mention that in the bug too (2 builders probably pulling the same revisions) that may help
<exarkun> okay
<exarkun> vila: 'bzr pack' doesn't look like it can deal with the state the repository is in now, though
<exarkun> Maybe you didn't mean that it would fix the state, just that it would help after I manually fix the state
<vila> yup
<vila> exarkun: do you need help to fix the state ?
<exarkun> I think it's fixed, I moved the .pack from obsolete_packs into packs and the other files into indices
<exarkun> And then 'bzr pack' worked
<vila> perfect thne
<exarkun> and filed bug 709349
<ubot5> Launchpad bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [Undecided,New] https://launchpad.net/bugs/709349
<vila> oh ! didn't link the nick and the lp login name :)
<exarkun> :)
<vila> jelmer: can I nominate the bug for the sru now ?
<jelmer> vila: tests *still* running
<vila> jelmer: oh my...
<vila> . o O (Who said "a laptop is good enough for bzr dev" :-)
<jelmer> hehe
<jelmer> vila: it's passed
<jelmer> vila: ... and I've pushed
<vila> cool, thanks a lot, I should really do this myself, I'll look at your branch anyway
<maxb> My laptop is good enough for bzr dev :-)
<jelmer> argh, python 2.7 has broken bzrtools
<jelmer> "ReadError: empty header" from bzrtools
<jelmer> 'evening max
<maxb> jelmer: yeah, I think I filed that bug already
<maxb> bug 708268
<ubot5> Launchpad bug 708268 in BzrTools "bzrtools testsuite has python 2.7 incompatibility" [Undecided,New] https://launchpad.net/bugs/708268
<kire> any ideas if bzr 2.3 will get to lenny backports (I am currently unable to install a decent ubuntu release on my server)?
<jelmer> kire: please request a backport using the normal channels
<kire> okay
<maxb> kire: The standard debian backports rules prevent it being updated until squeeze releases and testing thaws
<vila> Soo, I have a jubany VM, with a first package tracking its depedencies (ouch, based on hardy so bzr-2.1.1 so far)
<jelmer> maxb: of course, squeeze should be out soon. before 2.3 hopefully (or is that too hopeful?)
<maxb> I tend to the cautious where Debian stable is concerned
<vila> maxb: by the way, bug #687653 has been nominated for the 2.2.3 sru, thanks to jelmer providing a branch
<ubot5> Launchpad bug 687653 in bzr (Ubuntu) "infinite recursion trying to format NotBranchError" [Undecided,New] https://launchpad.net/bugs/687653
<jelmer> abentley: hi
<vila> I wasn't able to create to nominate for maverick, some weird lp backtrace about not being owner and as such lacking permissions
<vila> s/to create//
<abentley> jelmer, hi.
<jelmer> abentley: bzrtools' tests/upstream_import.py has some strange code that appends more data to a tarfile that is already present
<jelmer> (around line 125)
<abentley> jelmer, is this related to the 2.7 incompatibility?
<jelmer> abentley: Removing that code unbreaks bzrtools' tests on python2.7, but I wonder why it's there in the first place.
<kire> maxb, thanks (and of course i meant 2.2.3, not 2.3 but my question is answered anyway :))
<jelmer> abentley: yep
<abentley> jelmer, I don't know the answer right away, and I'm taking the rest of the day off for a trip.  I'll look into it, though.
<jelmer> abentley: thanks, no hurry
<vila> Oh, for the record, the vm use a 32GB HDD but the package importer currently uses ~90GB. Most of it being logs, debug files and maybe some working trees that could be re-created
<Peng> jam: Obviously, i wasn't around. :P Feel free to ask me anything, but I may or may not know the answer.
<jam> Peng: did you see the discussion about the launchpad team taking stewardship for loggerhead?
<jam> (I think most of the *discussion* took place on launchpad-dev, but some summary stuff showed up on bazaar@)
<Peng> jam: No. I've been doing an even worse job reading my email than following bzr/lh/lp. :P
<Peng> I think someone mentioned it here a week ago, though?
<jam> Peng: anyway, Launchpad is trying to take more direct responsibility for code they rely on, loggerhead being one of those things
<jam> at the same time, loggerhead "trunk" is not 100% ready to be just deployed on launchpad
<jam> so they wanted to move it 'to the side' as a future-work branch
<jam> I didn't know how much that would specifically affect you, since you've run some bleeding edge loggerhead stuff
<Peng> Ergh, I'm not awake yet... And like I said, I've fallen out of bzr/lh/lp.
<Peng> Why isn't LH trunk usable for LP? Because it's, well, a not-always-stable trunk branch?
<Peng> jam: Thanks for the heads-up. I'll dig into the list archives today.
<jam> Peng: not-always-stable, and without tweaking the launchpad side of things, history-db is an initial perf regression
<jam> (once caches are filled, it is generally a big win, but the first load is slower than the existing code)
<jam> Peng: looking at it, the launchpad branch of loggerhead also has some site-specific customization. But the "launchpad code team wants to start with a stable base" is the big thing they want to move trunk to the side for
<jam> I've been poking at it a bit, because I'd really like to see my code deployed
<jam> and I've been given some leeway to push on that
<Peng> ISTM, even if the LP folks mangle trunk for a while, I could just pull future, no?
<Peng> This is encouraging me to finally update LH, which I haven't done in a while, so I'll feel like I really deserve to have input on this. :P
#bzr 2011-01-29
 * maxb wonders what the right time to drop support for Karmic's launchpadlib is
<exarkun> bzr: ERROR: Pack 'db549700446f894b61fdcd7f71d550d1' already exists in GCRepositoryPackCollection(CHKInventoryRepository('file:///var/lib/buildbot/twisted/.bzr/repository/'))
<exarkun> oh hey I've seen this before apparently
<jelmer> exarkun: are you running with spiv's fix?
<maxb> Hm. I think bzr launchpadlib integration has been broken in 2.2 since the switch to not use edge
<exarkun> jelmer: running 2.2.3 from the ppa
<Zer> Howdy.. I'm trying to do a bzr svn-import (on Windows, as it happens...), and it's giving me "bzr: ERROR: No repository present: file:///T:/" when I give it T:\Test\ ... any idea why?
<exarkun> Zer: Hi.  You're probably just messing with svn-import for fun, but in case this is related to our earlier conversation, we actually have some specialized goals beyond just a vanilla conversion. :)
<Zer> Well, the syntax looked like Git's
<Zer> so I figured, how different could it possibly be :)
<Zer> but, fair enough
<maxb> What exactly *is* T:\Test ?
<maxb> A svn repository? A svn working copy?
<Zer> a local svn repo
<Zer> yeah working copy
<Zer> What's odd is it checks the parent directory instead
<maxb> Right. Don't do that :-)
<Zer> Ah...
<Zer> I suppose a local copy wouldn't have the full history in any case
<maxb> If you want to import svn history, you need to give it a repository. Because a working copy stores no history
<Zer> on SVN anyway. Been on Git too long, I hadn't remembered
<maxb> Though admittedly that error sucks
<gour> hiya...i use fossil for my personal projects, but consider that bzr is the most sane amongst {bzr,hg,git,svn} and wonder which one(s) among bzr{git,hg,svn} plugins are to good enough to be used for (simple) collaboration with the projects?
<jelmer> gour: what kind of collaboration?
<gour> jelmer: like applying some patches and commiting to the 'official' repo
<jelmer> gour: both bzr-git and bzr-svn should be sufficient for that
<gour> jelmer: that's great ot hear. thanks
 * gour uploaded package to bzr-git to AUR (archlinux's user repo)
<jelmer> gour: cool
<gour> jelmer: thank you for working on those plugins..much better to stay with bzr and use 'em instead of 'native' tools
<zap> Hello! I have a strange situation: A few days ago I pulled a project's revision 2755, but now I can't follow the tip because log shows the revision 2755 is completely different from mine! Does bzr support canceling out commits?
<mgz> yes.
<mgz> it's generally considered bad form to do it on public branches.
<mgz> provided you don't have any changes you want to keep in your local mirror, just do:
<mgz> `bzr pull --overwrite`
<mgz> and maybe whine at the branch maintainer so they don't do it again.
<zap> Aha, thank you.
<major> are the sources to baz no longer accessble?
#bzr 2011-01-30
<quotemstr> Let's say I make commits (from Base) C1, C2, and C3 and submit them each to an upstream project as a patch. I realize there's an error in C1 and make a fourth commit, C4, to fix it. How can I generate a new patch that includes the changes of C1 and C4 without C2 and C3?
<quotemstr> Do I just have to back everything else out and rebase?
<lifeless> commit it in a branch just for c1+c4; merge that to trunk, send [c1,c4] as the patch
<quotemstr> Ugh. Making a non-stacked branch takes forever.
<quotemstr> Thanks.
<wildintellect> so I'd like to checkout a copy of an svn repo, work on it a bunch pushing changes to a lp bzr repo, and when I'm done in a few weeks merge back into svn
<wildintellect> http://doc.bazaar.canonical.com/latest/en/user-guide/svn_plugin.html seems close but bzr push sends to svn when I would want it to my lp repo for now
<wildintellect> maybe I should just do an svn checkout then bzr init over the top of the same directories
<wildintellect> using bzr to manage my branch work and when done use svn to merge it back into the svn repo?
<wildintellect> guess that would lose the commit history
<Kamping_Kaiser> and make it hard to merge
<Kamping_Kaiser> wildintellect: change your push target while you work on it
<wildintellect> I think I wasn't reading that page close enough
<wildintellect> can I have different push locations for each bzr branch I make?
<Kamping_Kaiser> wildintellect: check the docs for push_location and submit_branch. (parent_location should be the svn repo)
<sobersabre> hi
<sobersabre> Is there a way to track file permissions with bzr ?
<sobersabre> (I know it's "metadata", but still)
<spiv> sobersabre: not built-in.  There are tools like etckeeper though.
<sobersabre> spiv: hmmm... nice tool. does it source current permissions into some kind of text file and then processes it to ensure the perms are intact ?
<jelmer> sobersabre: yep, basically
<sobersabre>  jelmer ok.
<knittl> is bzr able to perform cross project merges?
<knittl> ok, it can
<jml> ed
<jelmer> jml: old school!
<jml> heh
<jml> I have no idea why I typed that in this channel.
<sobersabre> hi. where I can read about how to do something like bzr status from within python script.
<sobersabre> I want to detect changes/additions/removals.
<sobersabre> ther must be some kind of api aournd. right ?
<beuno> sobersabre, yeah
<beuno> let me dig that up for you
<beuno> sobersabre, http://wiki.bazaar.canonical.com/Integrating_with_Bazaar
<sobersabre> beuno: I am on windows. I have bzr installed, I tried import bzrlib, and it didn't manage.
<beuno> has nice examples
<beuno> and this is the api documentation: http://people.canonical.com/~mwh/bzrlibapi/
<beuno> I don't know anything about python in windows, so can't help you there
<mgz> sobersabre: you want to install the bazaar for your python version, not the all-in-one bundle
<mgz> that will put it in your site-packages dir so you can import it.
<mgz> ie 'bzr-2.2.3.win32-py2.6.exe' not 'bzr-2.2.3-setup.exe'
<sobersabre> mgz: thanks, man. I did install the right version for "my" python (2.5)
<sobersabre> for some reason bzrlib is not loadable.
<mgz> does C:/Python25/Lib/site-packages/bzrlib exist? (adapt for your pythong location)
<mgz> ...I type 'pythong' way too much.
<sobersabre> I wear pythongs once in a while.
<sobersabre> anyway, I have no bzrlib in the site-packages dir.
<sobersabre> even though I did install bzr-2.2.1.win32-py2.5.exe
<mgz> uninstall and try again, it's possible something got screwed up.
<awilkins> sobersabre, Eclipse problems?
<sobersabre> awilkins: what do u mean?
<awilkins> Ah, wrong distro, sorry
<sobersabre> it is an evening, the sun is down...
<sobersabre> moon is visible.
<awilkins> The exe bundle has some issues with the bzr-xmloutput plugin and hence the bzr-eclipse plugin
<sobersabre> awilkins: hm... distro ?
<mgz> pay attention in the installer to where it's putting the files.
<sobersabre> oh!
<sobersabre> hm...
<sobersabre> I do have that plugin (but not on this computer).
<sobersabre> is it possible I will have eclipse plugin punishment,
<sobersabre> but not on the computer it is installed on ?
<mgz> you might have a zombie python install somewhere, or a screwed up registry setting.
<sobersabre> :-/
<sobersabre> mgz any ideas what setting ?
<sobersabre> path ?
<awilkins> I have at least one bug for the Eclipse plugin, but it only occurs when your project folders are nested more than 1 deeper than your workspace
<sobersabre> python* ?
<mgz> well, just try uninstall/reinstall to start with
<sobersabre> ok... it's scary.
<mgz> that does a "find where python is" step, if it gets it wrong, then we can go digging
<sobersabre> mgz: I have just rebooted. what step were you talking about?
<sobersabre> off a webpage or something ?
<mgz> uninstall your current bzr. then reinstall. may as well use 2.2.3 while you're at it.
<sobersabre> beuno: about windows, as you can see "Me and you are of the same blood"
<mgz> and look at what paths it's using in the process.
<sobersabre> mgz: I didn't see 2.2.3 for py 2.5 on win the last time I installed...
<mgz> it's new-ish.
<mgz> http://launchpad.net/bzr/2.2/2.2.3/+download/bzr-2.2.3.win32-py2.5.exe
<sobersabre> alrightie.
<sobersabre> I used the main canonical page last time...
<sobersabre> so where can I look at to see how to answer your 'find where python is' q ?
<sobersabre> I know where the python is.
<sobersabre> it's in D:\Python25
<mgz> the installer doesn't ask you, it looks for itself.
<sobersabre> hm, now I can practically SEE the files are being copied and compiled to D:\Python25\Lib\site-packages\bzrlib
<sobersabre> feels good.
<sobersabre> let's see it works too.
<mgz> make sure it's beliefs and yours coincide
<mgz> okay, that sounds good.
<mgz> -' dammit.
<mgz> sobersabre: import works now?
<sobersabre> mgz: oh, it does!
<sobersabre> I like.
<sobersabre> :)
<sobersabre> I am one happy geek now.
<sobersabre> preparing a deployment fab.
<sobersabre> it's my 2nd month with python at work, and I like it.
<sobersabre> too much.
<mgz> so, to get started, you want something like:
<mgz> from bzrlib.workingtree import WorkingTree
<mgz> tree = WorkingTree.open_containing(directory)[0]
<sobersabre> mgz I don't do anything like that :)
<sobersabre> I prefer to use the long names.
<mgz> then you can inspect the working tree, and see bzrlib.status for what the ui does.
<sobersabre> mgz I think it is better to use changes. it gives an iterable thing.
<sobersabre> I will count what I want. if the counter is > 0 it's the time to act.
<AdamDV> Any known issues with bzr doing a checkout over sftp with a password protected rsa key?
<sobersabre> basically there's: changes.has_changed
<sobersabre> :)
<mgz> if that's all you need then fine, status does some more work on top of that as well.
<sobersabre> mgz: the problem with status is its result.
<sobersabre> I don't want to print out something.
<sobersabre> I need to do or not do something depending on the changes.
<mgz> I was suggesting you read the code, not used it as-is.
<mgz> iter_changes may be all you need.
<mgz> AdamDV: as in, does it work, or as in, are there known security issues?
<mgz> if you just want to know if it works, try it and see.
<AdamDV> Well, right now its looking like it does not.
<AdamDV> Even though I've used *without* a password protected key before.
<AdamDV> Let me pastey the errors.
<sobersabre> AdamDV: I think you should be more asking about paramyko. I remember it did have some troubles with default values long ago.
<sobersabre> paramyko is the module for ssh communication.
<sobersabre> bzr is just using it.
<sobersabre> (unless the same people who develop bzr also work on paramyko)
<sobersabre> AdamDV: did you look at the code of paramyko you're running ?
<AdamDV> http://pastebin.com/pvn4p8X3
<AdamDV> I did not?
<AdamDV> it works fine connecting to ssh.
<AdamDV> BUt yes, it looks like a paramiko problem.
<AdamDV> And if sftp+password key arent going to work, what other options do I have? Use a password-less key?
<sobersabre> AdamDV: also, what kind of network media are you on with this operation ?
<AdamDV> network media?
<AdamDV> As in how I'm connecting?
<sobersabre> Ethernet, WiFi, analog modem ?
<AdamDV> I'm on WiFi in Toronto, server is on ethernet in Dallas.
<sobersabre> AdamDV: what OS ?
<AdamDV> I'm on Maverick, servers on Lucid
<sobersabre> ok.
<AdamDV> 10.04.1 is the server, to be specific.
<sobersabre> on the client: does ifconfig show you any errors ?
<AdamDV> Nope.
<sobersabre> TX/RX ...
<sobersabre> ?
<sobersabre> sure ?
<AdamDV> I was using this yesterday, without a password on the key. We re-imaged the server and I re-generated my key and added a password, now its not working :)
<mgz> bug 647916 is similar, check the last comment there?
<AdamDV> Lemme pastebin ifconfig
<ubot5> Launchpad bug 647916 in Bazaar "Push command fails with "Garbage packet received" error" [Undecided,Incomplete] https://launchpad.net/bugs/647916
<AdamDV> http://pastebin.com/2gh1VPsq
<sobersabre> mgz: I looked at it...
<AdamDV> Oh.
<AdamDV> That could be it.
<AdamDV> My shell is not bash, its actually a custom internal shell we use here.
<AdamDV> *changes back to bash*
<mgz> sounds likely.
<sobersabre> AdamDV: I would not use anything non-standard to debug such problem.
<sobersabre> and, permission denied is kinda interesting.
<sobersabre> Are you sure the user you're using to run this has access to /home/adam/.ssh/id_rsa ?
<sobersabre> AdamDV: is it possible it is chmodded 600, but belongs to ... a different user ?
<AdamDV> Changing to bash on my server user fixes the problem.
<sobersabre> AdamDV: is it possible your "supershell" uses the same UID you have as user 'adam' ?
<sobersabre> I mean it DOESN'T use it.
<AdamDV> As in server user id is the same as my local user id?
<mgz> <AdamDV> Changing to bash on my server user fixes the problem. <- good good.
<maxb> It sounds to me that AdamDV's custom shell is not supporting the invocation of sftp on the server properly
<AdamDV> Yea. Its a 100 line shell written in PHP for the secretarys to use.
<sobersabre> maxb: I know how this can happen:
 * maxb runs away screaming
<sobersabre> the "supershell" prints out too many lines of output.
<sobersabre> I mean too many chars of output.
<AdamDV> maxb: Yea.
<sobersabre> AdamDV: can you make your logon shell quieter ?
<AdamDV> ?
<AdamDV> I'd rather use BASH anyway :)
<sobersabre> AdamDV: if you can - do, if you cannot - make sure the shell shuts up upon invokation.
<sobersabre> I remember having added lots of stats upon logon (with colors, etc.) this made sftp inoperable.
<AdamDV> I have no control over the development of our shell, unfortunatly. If I did, it wouldn't exist..
<sobersabre> I'm off, mgz thank you!
<AdamDV> Thank you for your help mgz and sobersabre
<AdamDV> :)
<mgz> bye both.
 * AdamDV idles
<major> okay, so I may be in for a heck of a pickle... I have some fairly old Bzr repositories which where converted from TLA using baz-import .. a while ago..
<major> was trying to work at upgrading them, and a bzr log in them claims that it can not locate an ARCH-1 revision near the end of the log
<MTecknology> http://dpaste.com/370125/ <- any idea why this happens when I try to pull a branch?
<jelmer> major: what version of bzr are you using? and what's the exact error message?
<jelmer> MTecknology: the local branch doesn't support a particular feature that the remote branch uses
<jelmer> MTecknology: you can upgrade the local branch and try again
<jelmer> the error message could admittedly use some work..
<MTecknology> oh.. thanks :)
<MTecknology> works perfect now
<major> bzr version 2.2.2
<major> bzr: ERROR: Revision {Arch-1:email@domain--project%package--1.0^Cversion-0} not present in "KnitRepository('file:///home/user/devel/user.bzr/repository/')".
<major> erm
<major> erm
 * major sighs.
<major> that ^C shouldn't be there
<major> it is has '--' in that spot
<major> I tried to hide the email addresses and accidentally mangled the error a touch
<jelmer> major: was the revision present originally?
<jelmer> missing revisions ("ghosts") were pretty common in baz
<major> well, it didn't used to give this error...
<major> and the original repositories where converted from TLA
<major> I suspect they where external archives..
<jelmer> the original repository  (the bzr one converted from baz) doesn't give that error?
<major> they where all TLA archives, and still are
<major> I still have them
<major> they where retained for historical purposes
<major> baz was only used during baz-import, back when it was still part of the bzrtools
<jelmer> it'd be interesting to see if that revision was actually present in baz
<jelmer> or if it wasn't present and older baz/bzr simply didn't mention it
<major> well, I can definately look at it
<major> and it is definately there
<major> it just isn't actually in the bzr repository
<major> is there any documented way to fix ghosts like this?
<jelmer> major: baz-import shouldn't have created a ghost if the revision was present in the original baz repository
<major> what if the revision was in a separate tla archive?
<major> though its location was registered
<jelmer> major: no idea (I've never used baz)
<major> hmm
<lifeless> it will create ghosts
<lifeless> it doesn't traverse archives
<lifeless> you need to import each archive
<lifeless> if I'm remembering correctly
<major> hmm..
<major> I suppose that feels mostly right..
<major> just makes this pretty.. well .. funky
<major> I don't suppose importing the parent repository ontop of the already converted repository will make it "just work" ?
<jelmer> major: importing it elsewhere and then running "bzr fetch-ghosts <new-repo>" from the original repo should work
<jelmer> where new-repo is the bzr repo created from the parent baz repo
<major> nifty
<jelmer> emphasis on /should/, I've never tried that before
<lifeless> major: yes, it should just work.
<lifeless> emphasis on the should
<major> heh
<major> well, I have a number of backups of this stuff already
<lifeless> we haven't done much tla imports for about 5 years :)
<major> yah ..
<major> trying to revive a project that hasn't been touched in almost that long
<lifeless> cool
<Ramosa> does bazaar have the same issues as mercurial with tagging.. that a tag actually does an invisible commit, and that you can't edit history easily of past revisions ?
<jelmer> Ramosa: a tag doesn't do an invisible commit, it's just a named pointer to a particular revision
<jelmer> Ramosa: history can't be edited, but you can rewrite it
<major> well .. it is chugging away at this, hopefully it all works...
<major> will likely take all day to do all these repositories though
<major> but that is better than losing the history
<jelmer> whoa.. that's really slow :-(
<major> well, a lot of repositories to fix, with a lot of branching inside of them
<major> I suspect the SCM history alone could be used for an interesting white paper on development work-flow
<jelmer> hehe
<major> the original sources started off in RCS, later converted to CVS, then pulled into Arch via cscvs (a tool to compute change-sets within CVS)
<major> from there a number of developers created branches from the original Arch archives, and then those where converted to bzr via baz-import
<major> and a few developers developed from multiple locations, which in Arch gives them unique global identifiers
<major> really not certain if it could get much more chaotic
<poolie> hello all
<jelmer> g'morning poolie
<poolie> hi there jelmer
<quotemstr> How can I write a revisionspec that means 'since this branch was forked from its parent'?
<quotemstr> (And I mean without looking that point up beforehand, of course.)
<quotemstr> Ah, ancestor:, maybe.
<jelmer> quotemstr: yeah, generally ancestor:
<quotemstr> But I still hae to type out the parent branch in that case. Ahwell.
<quotemstr> Hrm. bzr log -r ancestor:./../trunk.. seems to not be pegging the CPU and not making any forward progress
<mwhudson> jelmer: lp:bzr-hg seems to have a pdb.set_trace() in it
<cbz> is there a bzr concepts/internals guide?
<jelmer> mwhudson: oh, whoops
<jelmer> mwhudson: I'm about to land a branch that fixes 75% of the hg imports
<mwhudson> jelmer: \o/
<spiv> quotemstr: ancestor::parent
 * jelmer waves to spiv
<spiv> Good morning :)
<quotemstr> Thanks.
<quotemstr> So ':parent' is magical.
<mwhudson> it's a location alias i think the name is
<mwhudson> there are a few
<mwhudson> :push and :submit are others
<quotemstr> spiv: That doesn't DTRT at all.
<quotemstr> It gives me some random commit from today.
<spiv> quotemstr: perhaps :parent isn't what you expect?  Check 'bzr info'
<quotemstr> Actually, after bzr log -r ancestor::parent.., I get "bzr: ERROR: Start revision not found in left-hand history of end revision.
<quotemstr> parent is set correctly.
* spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.2.3 is officially out ! (rm vila)
<spiv> Oh, log is fussy like that.  abentley added some new revision specs that help with that.
<quotemstr> Wuh? Why *wouldn't* that work?
<quotemstr> And why do you need new syntax to make it work?
<spiv> mainline: is the revspec I'm thinking of.
<spiv> I agree, I think log should cope, but currently it doesn't.
<spiv> For non-trivial history exploration I tend to use 'bzr qlog' (from the qbzr plugin) or 'bzr viz' (similar thing in the bzr-gtk plugin).
<quotemstr> Ah. Anything native for OS X or Win32?
<quotemstr> (Well, I can use X with both. It's just a pain.)
<spiv> qbzr looks pretty slick on Win32 at least (it and bzr-explorer and some other plugins are bundled in the bzr installer for that platform)
<spiv> IIRC it works ok on OS X too, although there may be some fiddly dependencies that I'm ignorant of.
<quotemstr> Thanks. I'll take a look.
<quotemstr> I'm leery of GUIs generally though.
<major> use a good solvent
<mwhudson> we does my checkout of lp:loggerhead whinge about not being able to break locks when i run bzr up?
<mwhudson> i suspect the fact that it appears to be making three connections to bazaar.launchpad.net is related
<jelmer> ugh
<jelmer> what's so special about it that it needs 3 connections?
<mwhudson> don't know
<mwhudson> the working tree is out of date with the local copy of the branch now
<mwhudson> hm, unbind/bind fixed it
<spiv> mwhudson: :(
<lifeless> mwhudson: note that I'm about to push 1.18 to trunk, or something like that
<monkey_d_luffy> how can I "fork" my project at a particular revnum?   I tried branch but then why I try to commit changes I get an error "bound branch ... is out of date".   Basically what I want is a copy-paste of everything at a chosen revnum, so that it can stay independent.
<spiv> monkey_d_luffy: "bzr branch -r REVNO"
<monkey_d_luffy> but that didn't work...
<spiv> How did it go wrong?
<monkey_d_luffy> that's the problem I'm having now
<spiv> Your error says "bound branch" though, which isn't something that "bzr branch" (by itself) could give.
<spiv> Did you use "bzr checkout" instead, or perhaps "bzr bind" or "bzr reconfigure" after "bzr branch"?
<monkey_d_luffy> I did a branch of my project    bzr branch -r 60   trunk  trunk_new                    then I renamed both directories.   And now when I try to do a commit in my new dir, I get that error
<monkey_d_luffy> it could have been a checkout, but I'm pretty sure it was a branch... will try again then
<spiv> Hmm.  Well, you should be able to "bzr unbind" (or "bzr reconfigure --tree") to change it.
<spiv> And "bzr info" can tell you what it is now.
<monkey_d_luffy> I did a bzr info now... it was a checkout after all :|
<monkey_d_luffy> so a branch makes it completely independent from the parent branch (which may even be deleted) correct?
<spiv> Yes.
<monkey_d_luffy> ok thansk
#bzr 2012-01-23
<poolie> hi all
<lifeless> ola
<poolie> lifeless, what new laptop disk did you buy?
<lifeless> poolie: the intel 320?300? GB one
<poolie> '520 series' or something?
<lifeless> yeah
<lifeless> poolie: SSDSA2CW30
<poolie> k thanks
 * poolie deletes stuff instead
<lifeless> http://www.betterit.com.au/scripts/prodview.asp?idproduct=265748
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer
<poolie> vila, hi?
<vila> hi all !
<poolie> jelmer, wgz, hi?
<poolie> i might make mgz be pilot this week as it's mostly jelmer that needs reviews
<poolie> i'll let you settle it
<poolie> vila, maybe you could just send a note about the ppas and other releases
<poolie> *srus
<poolie> mm
<vila> hmm, yeah, our ppas need some love, maxb ?
<vila> hello mgz !
<mgz> morning all
<mgz> jelmer: do you want to swap pp this week?
<mgz> the alternative is we just do a morning or something reviewing your branches
<jelmer> mgz: I think that might be better
<jelmer> mgz: though I'd also be happy to swap this week if you prefer ?
<mgz> nope, just swapping a morning seems fine to me
<jelmer> ok, let's do that then
<mgz> oi, jelmer, vila, why am I talking in /query to both of you...
<mgz> jelmer -> in here
<jelmer> mgz: ohai
<fullermd> I knew you were all talking about me behind my back   :(
<mgz> so, this is LANG=C with bzr-svn bascially?
<vila> fullermd: just look the other side :)
<jelmer> mgz: yeah
<jelmer> mgz: UnicodeFilenameFeature is present, but libsvn fails to actually encode non-ascii filenames
<mgz> if there's an obvious worked-before and fails-now, might be best to just file a bug and subscribe me.
<jelmer> mgz: will do
<jelmer> for now, I'll just set LC_ALL=en_US.UTF8 while running the bzr-svn testsuite..
<mgz> the clearest issues will be with stuff that used to fail early, but now works till it tries outputting something
<mgz> which is pretty easy to get around with paths, as can convert to urls
<vila> mgz: for the record, I looked a bit at the server tests failing on osx
<vila> the change where the failures started on babune is a red herring, if I try again with an older revision, it fails too
<vila> so either I changed some setup on the osx slave (can't imagine what) or I installed some os update which broke something (no help from google there either)
<mgz> hm.
<vila> the code where it breaks has been introduced to support ipv6 years ago and seem to closely match the example in the python docs...
<mgz> jelmer: aha, I understand from bug 920444 description
<ubot5> Launchpad bug 920444 in Bazaar "locale.getlocale() returns ascii locale even though UnicodeFilenameFeature is present" [High,Confirmed] https://launchpad.net/bugs/920444
<mgz> there bzr-svn tests relying on out process svn for things I take it
<mgz> or... just bypassing python I guess is the point
<mgz> changing the feature is the obvious way forward
<jelmer> mgz: it's all in the same process, but indeed bypassing python
<mgz> I'm unsure if a different feature making the current one stricter would be best
<mgz> without running the tests that need unicode filenames under LANG=C we then only rely on explict subprocess tests
<jelmer> hmm
<mgz> but it's annoying for you to have to work out which tests need a full locale set on nix
<jelmer> mgz: these tests are multiplied
<mgz> and possibly worse than that for parametrised tets
<mgz> +s
<jelmer> mgz: against some implementations they need setlocale(), against others they don't
<mgz> right.
<mgz> well, it's not that they need setlocale so much as they need a unicode locale.
<mgz> in-process libsvn as a locale set, it's just not one that can be used for non-ascii names.
<mgz> (in this case)
<mgz> out of process things potentially break if a unicode locale is given, but they don't call setlocale()
<jelmer> mgz: right, I mean they need a call to setlocale() to set it to a non-ascii encoding
<mgz> but you can't go changing the locale as a library
<vila> jelmer: quick questions about udd: 1) can I upgrade jubany to builddeb trunk (jubany has revno 650, trunk has revno 708) 2) pristine-tar fix for suse bzip2 seems to be in 1.17 (or 1.16 but some later commits seem to be related so 1.17 seems safer) jubany currently uses 1.11ubuntu1~0.IS.8.04 what is needed ?
<jave_> I get a "conflicting tags" error, and I'm trying to understand how to debug it.
<vila> jelmer: i.e. in an ideal world, I can update bzr-builddeb to trunk, someone in the know package pristine-tar 1.17 for lucid-cat and no additional package import failures are introduced :-D
<jelmer> mgz: right, but we can from the bzr script (which is also whats runs the testsuite)
<jelmer> mgz: another alternative is for subvertpy to override the locale before each libsvn call
<jelmer> mgz: though that might have too much overhead, I'm not sure
<jelmer> vila: I think upgrading pristine-tar i safe
<vila> I think so too, but who did packaged it for -cat ?
<jelmer> vila: I don't think it's packaged for -cat yet, I can do that
<mgz> jelmer: we can ignore the user's configuration sure, but it's better to not do that, even for just the testsuite
<vila> we use 1.11.*IS.* on jubany but lucid package only 1.00 so I suspect someone packaged it in the past (imbw)
<vila> jelmer: and about bzr-builddeb ? Are there fallouts to be expected or is it safe to upgrade ?
<vila> jelmer: and that would be great if you package 1.17 for -cat !
<vila> 1.17 is already in sid and wheezy, it's weird it's not in precise yet...
<jelmer> vila: I think it's safe to upgrade
<jelmer> vila: lamont did the backport last time, so I think getitng a new pristine-tar should just be a matter of filing an RT
<vila> jelmer: cool, I'll do that then
<vila> jelmer: exellent, I'll file one
<vila> rt filed
<fullermd> vila: BTW, did you get whatever you needed out of that pycurl Q the other day?
<vila> fullermd: well, the underlying question was: does freebsd have a known place to store/share root ssl certs, so far I found... let me find it back
<vila> /usr/local/share/certs/ca-root-nss.crt
<vila> fullermd: can you confirm that ?
<fullermd> That's part of ca_root_nss.
<fullermd> There is (intentionally) no CA list in the base system.
<vila> ok, let me rephrase/expand the question:
<vila> we now implement ssl cert validation in the http urllib implementation, do achieve that, we need a list of cas
<fullermd> curl (with default build options) pulls in the NSS root list, though that can be disabled.
<vila> python doesn't provide one so we need some platform specific defaults
<vila> I filed bug #920455 by the way
<ubot5> Launchpad bug 920455 in Bazaar "ssl cert verification needs better defaults for all supported platforms" [High,Confirmed] https://launchpad.net/bugs/920455
<vila> fullermd: so, bzr should pulls this list too ?
<fullermd> Right.  There isn't one.  Now, probabilistically most desktops probably have ca_root_nss installed, considering how many things wind up pulling it in, and curl default does.  But a flip in OPTIONS, and the latter doesn't.
<fullermd> You could just use it if it's there, and not if it's not.
<vila> fullermd: so, if bzr was using /usr/local/share/certs/ca-root-nss.crt as the default value *and* does the needed magic in the packaging for pulling the NSS root list, the world would be a better place ?
<vila> err, if it's not there we can't use it and we can't verify certs either, that's supported by setting ssl.cert_reqs=none though
<vila> is it an issue to add that as a packaging dep ?
<vila> i.e. the idea is that we relied on pycurl before the fix but that not verifying certs with urllib is still a security issue
<vila> now we can verify (controlled by 2 options: ssl.ca_certs=<path>, ssl.cert_reqs=<your choice>) the certs but of course we need the right roots for that
<fullermd> Mmm.  Lemme think about that.
<fullermd> It does pull in perl...
<fullermd> Of course, all the smart people already have that on their system, so it doesn't much matter.
<fullermd> I think I'd want to make it OPTIONal, since there's that contingent of security nuts who won't accept installing it.
<vila> perfect
<vila> security nuts will setup their own ssl.ca_certs *anyway*
<fullermd> I'll mull it a bit.  Gotta conference call I have to go try now to gnaw off my own limbs to escape...
<vila> fullermd: no hurry, that's for 2.5.0 anyway
<vila> fullermd: on the other hand, the security nuts were probably using pycurl before that ;)
<fullermd> Well, or monotone   :p
<fullermd> Right.  Let see how well I can avoid talking in this stupid call...
 * fullermd wanders off.
<vila> :)
<quicksilver> if I undelete I file just by pulling it out of a previous version with bzr cat, then of course it's a fresh file with no history.
<quicksilver> if I pull it out with bzr revert -rVERSION is that the same?
<quicksilver> or does it regain its history then?
<james_w> quicksilver, that will regain the history
<quicksilver> james_w: good news, thank you!
<quicksilver> james_w: so that is the 'right' way to undelete, I guess. How could I simply "prove" to myself that it has regained history. Is "bzr log filename" a good way?
<james_w> quicksilver, I think that should work
<quicksilver> thanks again
<vila> quicksilver: 'bzr st --show-ids' cannot lie :)
<quicksilver> vila: hmm but what to compare to? a checkout of an old version I make?
<vila> quicksilver: that or a 'bzr st -c <old> --show-ids' where <old> is a revision where this file was changed
<quicksilver> I didn't know about the -c argument
<quicksilver> i've only been using bzr for 6.5 years
<quicksilver> thanks vila
<vila> quicksilver: hehe
<sinzui> jelmer, I have a fix for a bzr-gtk issue I saw this morning. https://code.launchpad.net/~sinzui/bzr-gtk/precise-diff-0/+merge/89759
<jelmer> sinzui: thanks, I'll have a look
<jelmer> sinzui: bug 914363 is no longer private
<ubot5> Launchpad bug 914363 in bzr (Ubuntu) "bzr crashed with TypeError in __new__(): object of type 'NoneType' has no len()" [Undecided,Confirmed] https://launchpad.net/bugs/914363
<sinzui> fab
<sinzui> I am not sure I fixed that.
 * sinzui checks
<sinzui> Well maybe I did.
<sinzui> jelmer, yes I did fix that bug. There is a lot of warnings on stderr though about invalid matrix (not invertible)
<jelmer> sinzui: cool
<jelmer> sinzui: I have to run out for a bit, will do a review when I get back
<sinzui> thanks
<exarkun> bzr 2.4.2, 13 minutes to check out a branch, http://buildbot.twistedmatrix.com/builders/winxp32-py2.6/builds/1867/steps/bzr/logs/stdio
<wgz> exarkun: that looks like 4 minutes, have you got the .bzr.log instead?
<wgz> at least the checkout step says 'elapsedTime=257.125000' so something else must have been going on for the rest of it.
<exarkun> could be.  it's not clear which timestamps to trust.
<exarkun> it definitely took a long time though.
<wgz> making your script do BZR_LOG=/some/file/builder/can/attach would be grand
<exarkun> The .bzr.log might be available, I'll let you know.
<exarkun> I don't think that's possible.
<wgz> that's a shame. I thought buildbot was pretty fancy.
<exarkun> ha.
 * jelmer wonders if there is a particular reason buildbot uses checkout vs say, export
<exarkun> I expect some bzr experts could greatly improve buildbot's bzr support code.  buildbot supports half a dozen or more version control systems, mostly with... creative solutions, constructed by people who are more knowledgeable about buildbot than about the particular version control system.
<jelmer> exarkun: yeah, looking at the source code it seems like just "bzr export" should be sufficient
<exarkun> unfortunately I don't think that bzr/buildbot integration improvements will make it onto my top 10 any time soon
<exarkun> even paying attention to this terrible performance is actually a terrible diversion from my actual priorities right now...
<LarstiQ> wgz: I fixed some pypy failures ->  Ran 27060 tests in 2322.926s ; FAILED (failures=42, errors=69, known_failure_count=53)
<exarkun> here's the end of the log, paste.debian.net/153385
<LarstiQ> an improvement on FAILED (failures=55, errors=8397, known_failure_count=28)
<exarkun> I don't know if it actually overlaps the build I linked to though
<exarkun> This kinda seems hopeless.  I should probably give up and go back to work.
<wgz> LarstiQ: good work, was that mostly changes to test cases themselves?
<LarstiQ> wgz: yes
<wgz> hm, sadly exarkun's log doesn't seem to actually include the checkout...
<wgz> it's just modifying an existing tree
<poolie> hi LarstiQ, wgz
<poolie> yawn
<wgz> is it that early poolie? :)
<lifeless> wgz: 0840 for him
<lifeless> wgz: but jet lag :)
<poolie> wgz, 0840 isn't early but waking up at 0430 is
<poolie> :(
#bzr 2012-01-24
<sidnei> anyone around to help me pushing a bzr branch to github?
<sidnei> im getting an error: http://paste.ubuntu.com/814914/
<sidnei> jelmer, ^
<poolie> hi sidnei
<sidnei> heya poolie
<poolie> i don't recognize that
<poolie> suggest you just file a bug
<sidnei> oki.
<sidnei> i assume if i do a fast-export it won't be compatible with doing dpush after that?
<jelmer> sidnei: I would suggest trying lp:bzr-git (asuming you're running precise)
<sidnei> jelmer, as in, the branch not the package
<sidnei> jelmer, slightly different error
<sidnei> jelmer, http://paste.ubuntu.com/814962/
<jelmer> sidnei: try adding ,branch=master to the end of the URL
 * jelmer wonders if we should do that by default
<jelmer> we used to, but that's slightly inconsistent with git itself
<sidnei> jelmer, seems to be progressing
<sidnei> jelmer, failed at the end, but seems to have pushed fine http://paste.ubuntu.com/814968/
 * jelmer waves
<vila> hi all !
<AuroraBorealis> hi
<AuroraBorealis> can i ask where bazaar explorer gets the 'names' it uses for its branches? i think its bzr nick but setting it doesn't seem to change anything
<mgz> morning
<poolie> hi mgz
<AuroraBorealis> brb
<jelmer> ready to hang out when you are :)
<wgz> hm, does someone need to setup the thingy?
<vila> chromium is up, waiting for the hangout to start
<wgz> vila: easy to miss notification top right
<vila> got jelmer's one
<wgz> sad robot.
<jelmer> wgz: :(
<jelmer> vila: looks like my pre-merge trick backfired
<vila> :-/
<vila> how so ?
<jelmer> vila: lp:bzr/2.5 is slightly ahead of bzr.dev, so feed-pqm won't suggest my branch for submission
<vila> yeah, you landed your commit builder fix there ;)
<mgz> just had a thought, where did the fsync changes land, and when is it enabled?
<mgz> 2.4b5 and for all systems it seems
<jelmer> that sounds about right
<mgz> I wonder if that's the cause of exarkun's weird slowness yesterday evening
<mgz> windows arguably doesn't want it on by default, as ntfs is less flakey than nix filesystems
<mgz> anyway, getting distracted, back to dealing with the weather
<futch> hello, is it possible to change the history log of a bzr repo without using the rewrite plugin? (just out-of-the-box means) - without causing harm to the repos itself, of course
<jml> hey
<jml> colo
<jml> that's what I want to talk about. I hear it's in a state for end users to try out?
<mgz> futch: sure, just branch from the last revision you want, then replay or flatten changes by cherrypicking changes across
<mgz> jml: jelmer will have more for you, but basically yes
<jml> cool.
<jml> where do I start?
<mgz> `bzr init --development-colo` for testing, there's a branch to flatten that into the existing format which hasn't landed yet
<mgz> then er... see <https://lists.ubuntu.com/archives/bazaar/2012q1/074217.html>
<jml> mgz: are there recipes for migrating existing directory-style set ups into colo?
<mgz> good question, I think no, but there's a bug for `bzr reconfigure` to do... something
<mgz> bug 919227
<ubot5> Launchpad bug 919227 in Bazaar "reconfigure --colocated" [Medium,Confirmed] https://launchpad.net/bugs/919227
<henninge> Hi!
<henninge> What could make bzr ignore information in locations.conf?
<henninge> I created a locations.conf to specify a push location but bzr push keeps insisting that "no push location" is specified.
<henninge> (This is on OS X but so far that has not been a problem ;)
<jelmer> hi henninge
<henninge> Hey jelmer ;)
<jelmer> henninge: how are you, enjoying your new job?
<henninge> Very much, thank you!#
<jelmer> henninge: cool :)
<jelmer> henninge: "bzr config" should tell you what it thinks the push location is, and where it got it from.
<henninge> oh, right
<henninge> I am not the one using OS X, btw ...
<henninge> jelmer: bzr config returns the expected values, as configured in locations.conf.
<henninge> jelmer: http://paste.ubuntu.com/815496/
<jelmer> henninge: hmm, that's really odd
<jelmer> what's the command being run - just "bzr push" ?
<henninge> yes
<henninge> Inside a lightweight checkout of a branch, both located inside the repository.
<henninge> Pushing directly from the branch is no different.
<jelmer> henninge: and specifying a location works?
<henninge> yes
<henninge> jelmer: I have to say that I have not been entering the commands myself but have been given instructions through skype chat ...
<henninge> But I doubled checked that he did it correctly.
<jelmer> henninge: it's a mystery to me what's happening here
<henninge> jelmer: ok, we'll work with specifiying the location for now.
<jelmer> henninge: I'm about to EOD - can you perhaps file a question/bug about it?
<henninge> jelmer: I will, after I have tried it myself, I mean, really myself. ;-)
<henninge> jelmer: Enjoy your EOD
<jelmer> henninge: if you feel like debugging this then the most useful thing to look at would probably be bzrlib/push.py - just stepping through the main function there
<henninge> ok
<jelmer> henninge: thanks!
<SamB> is it just me, or has bzr recently radically shortened the output it gives when an exception occurs?
<SamB> whatever is going on, the following is a bit *too* short:
<SamB> Pulling branches/v8.2 from svn://scm.gforge.inria.fr/svn/coq/branches/v8.2
<SamB> open_branch() got an unexpected keyword argument 'possible_transports'
<wgz> SamB: that's bug 902539
<ubot5> Launchpad bug 902539 in Bazaar Windows Installers "TypeError: open_branch() got an unexpected keyword argument 'possible_transports'" [Undecided,New] https://launchpad.net/bugs/902539
<wgz> you need to update to bzr-svn 1.1.2
<SamB> The exception message doesn't tell me (a) *what* exception occured, (b) *where* it occured, (c) whether it was fatal, or (d) any indication as to what component(s) may need attention
<SamB> wgz: I guessed it might be something like that
<wgz> is this on the console or in bzr-explorer, what platform, what version of bzr, installed how?
<SamB> but, didn't exceptions used to give a lot more information?
<wgz> it certainly should be prompting you to report a bug.
<wgz> find you .bzr.log and the block this error occurred in and paste it?
<wgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<SamB> I guess the exception might be getting swallowed or something ...
<wgz> running `bzr version` will tell you where .bzr.log is
<SamB> but I still think it's too terse
<wgz> it's wrong, but without more details I don't know the cause :)
<SamB> hmm
<SamB> I think it might be from too long ago to be in .bzr.log :-(
 * SamB was looking at mail from cron
<vila> SamB: too long ago in .bzr.log ? That would mean a pretty intense usage or some high verbosity from bzr ;)
<SamB> okay, no, that can't be it
<SamB> my third-latest email has one of those in it ...
<SamB> hmm
<SamB> !pastebinit
<ubot5> pastebinit is the command-line equivalent of !pastebin - Command output, or other text can be redirected to pastebinit, which then reports an URL containing the output - To use pastebinit, install the Â« pastebinit Â» package from a package manager - Simple usage: command | pastebinit -b http://paste.ubuntu.com
<wgz> the whole of .bzr.log isn't needed
<wgz> just copy out the part that you find that error in
<SamB> I know, it just sounds more convenient than opening a pastebin site in my browser, given the amount of RAM available
<SamB> http://paste.debian.net/153495/
<SamB> I think multi-pull is eating the exception
 * SamB looks for a command that compactly lists important details about bzr and plugins, like the proper exception output, only without the exception/traceback
<wgz> yup, seems like it
<SamB> I can see why it might not want to *just* fail, but this sure doesn't seem right, either!
<wgz> try `bzr -Dno_apport --no-plugins assert-fail`
<SamB> the trouble with that is that it doesn't list plugin versions :-)
<wgz> but `bzr help commands` will tell you what multi-pull comes from so who to file the bug against
<SamB> I got that from "bzr help multi-pull"
<wgz> ^ah, remove the --no-plugins then
<SamB> handy command, that
 * SamB wonders why zsh doesn't know about it
<SamB> hmm, didn't this used to show the paths to the plugins?
<wgz> `bzr plugins --verbose` should.
<SamB> I guess I could tell from the traceback if it really mattered, though
<wgz> ^commands added just to cause a internal error aren't of general interest :)
<SamB> you might be surprised
<SamB> if someone is thinking "I know it shows this information when it fails", they might like a way to make it fail
<wgz> SamB: so, did you file a bug somewhere?
<SamB> wgz: am doing so
<wgz> yell if you need help.
<thomi> Hi - qbzr seems really broken in precise - I often get crashes with 'bencode' in the stack trace. I'm filing a bug about it, but I wonder if there's any additional information I can provide that might be useful.
<wallyworld> poolie: bzr is quite borked on precise atm. i've filed one bug about bzr unshelve but bzr switch appears to have the same issue. are you guys able to look into it?
<thomi> hi wallyworld - you too huh?
<wallyworld> hi thomi. yeah.
<thomi> I've got: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/921267
<ubot5> Error: launchpad bug 921267 not found
 * wallyworld looks
<wallyworld> thomi: is that the right bug nr?
<thomi> yeah
<wallyworld> it must be private
<thomi> it's currently marked as private since there's a stack trace.... I didn't realise that meant private only to me... but that would make sense
<wallyworld> yep
<thomi> wallyworld: try now
<wallyworld> when you file using apport, that's what happens
<wallyworld> thomi: mine is a different issue- a missing ListOption attribute on a config object
<thomi> :(
<Kamping_Kaiser> hi, i just ran 'bzr revert --no-backup -r -30' instead of using -r ..30 by mistake. am i out of luck, or can i get back rev 30 somehow?
<jelmer> Kamping_Kaiser: "bzr revert -r30" ?
#bzr 2012-01-25
<Noldorin_> hey folks
<Noldorin_> is poolie back yet? :-)
<poolie> i am here
<Noldorin_> poolie, hi
<Noldorin_> i'll try and catch you tomorrow, as it's a bit late here
<Noldorin_> was just wondering if you were back from holidays
<Noldorin_> had some dev related questions
<Noldorin_> regarding some time ago
<Noldorin_> ta
<vila> hi all !
<vila> poolie: around ?
<poolie> hey
<vila> hurrah !
<poolie> just had a chat to thomas, all is well
<vila> poolie: looking at your udd patch for list_packages
<poolie> thanks
<vila> poolie: or rather, since I approved it, looking at deploying (shutting down the importer right now)
<poolie> i also would have guessed that it was a change on lp
<poolie> thus my original bug title
<poolie> hard to know
<vila> poolie: long story short: there are recent import failures for pristinetar, did you requeue these manually ?
<vila> poolie: if not, end of the interruption, if yes, I won't have to search why they were requeued ;)
<vila> poolie: ?
<poolie> vila, i did not do that
<vila> k, thanks
<poolie> ...
<poolie> maybe at the rally?
<poolie> it's a blur
<poolie> i don't think so
<vila> nope, more recent
<vila> no big deal either
<poolie> let's check shell history :)
<poolie> though, really, it ought to log something
<vila> yeah...
<vila> I'm rsync the logs and will look at the package ones
<vila> rsync'ing
<vila> jelmer: quilt not installed breaks the importer (I just deployed bzr-builddeb 2.8.2) :-/ Will file a rt ticket, what is needed ? Just quilt or some more ?
<poolie> vila, as well as filing an rt, nag the vanguard in #is
<vila> poolie: will do
<vila> but usually when I do that I'm pushed back to file an rt ticket ;)
<poolie> vila, or, finish converting it to juju :/
<vila> doing things in order will hopefully helps :)
<poolie> ;)
<vila> poolie: list_packages succeeded \o/ (no new packages apparently)
<poolie> great
<vila> jelmer: does your commit hook for quilt needs to crash when quilt is not installed ? Can't it disaplay a far red blinking warning instead ?
<vila> jelmer: additionally, is there a config option to disable it (or any other way) ?
<vila> jelmer: and finally, is there a minimum version required for quilt ?
<poolie> good night all, that's it for me
<vila> good night poolie !
<vila> jelmer: rt filed, quilt installed, imports succeeded, want some names to check it worked as intended ?
<mgz> morning
<vila> heya mgz !
<vila> jelmer: pakages that failed without quilt and have now succeeded: http://paste.ubuntu.com/816262/
<vila> jelmer: quilt-0.48-5 has been deployed on jubany
<vila> jelmer: and look at that... I was wondering how to avoid nexuiz-data endlessly re-trying while we investigate while it seem to be in an endless loop and it too failed with quilt, problem solved ;)
<rcsheets> I am getting an operation not permitted error when trying to push. http://pastebin.com/m7JvUbRv
<rcsheets> the file referenced in the error message does not exist.
<rcsheets> in the branch i'm pushing *from*, that file (and the entire directory it's in) has been moved up a directory. perhaps that's confusing bzr?
<mgz> rcsheets: hm, it really doesn't exist? I'd expect ENOENT rather than EPERM then
<mgz> there were some changes to chmod on trunk recently to ignore errors, but that was related to running against ntfs and other filesystems that don't support unix file modes
<rcsheets> this is on ext4
<rcsheets> stat: cannot stat `/srv/bzr/ffm-gms/trunk/cron/cron_customer_order_daily_email.php': No such file or directory
<rcsheets> actually i just noticed that from the destination branch, looking at 'bzr log', it seems like it worked
<rcsheets> but i can't do an update
<vila> rcsheets: which directory doesn't exist exactly ?
<rcsheets> Part of the most recent set of changes was moving public/cron/ to cron/
<vila> and which bzr version are you using ?
<rcsheets> bzr 2.2.4
<vila> hmpf, good to know, not tempted to upgrade to our latest stable that is 2.4 ? :-P
<rcsheets> i'm stuck for the moment on ubuntu maverick, but i can install a backport or just throw a new version into /opt
<vila> k
<mgz> okay, so it's being created as part of the merge, then can't be chmoded
<mgz> I'd check the perms on the parent directory of the branch you're pushing to
<vila> I would start by checking the permissions of all directories
<vila> mgz: :)
<rcsheets> i will chown them all to myself
<vila> hold on
 * rcsheets holds on
<vila> can you check first so we have a reasonable understanding ?
<rcsheets> yes
<rcsheets> the /srv/bzr/ffm-gms/trunk directory itself is owned by another user, but mode 775 and i'm in the group.
<vila> and below that ?
<rcsheets> looking
<vila> hey bialix !
<bialix> hi vila!!!
<bialix> hi mgz!
 * mgz bops bialix 
 * vila looks at his zoo postcard ;)
<bialix> :-D
<rcsheets> several other parts of the tree are owned by another user, but again i'm in the group and there are group write permissions
 * bialix is happy to say hello to bzristas
<vila> bialix: :)
<rcsheets> there is nothing in the whole tree below /srv/bzr/ffm-gms/ that i cannot write to
<mgz> rcsheets: the other possibility is... the cron directory is getting created on merge? because you moved it?
<vila> rcsheets: weird, try chown'ing and retry but I'm not fully confident it will work (on the other hand, I'm known for being rather pessimistic for bugs I don't fully understand ;)
<rcsheets> ok
<rcsheets> i will tar up what i have now, in case i need to restore it later
<vila> mgz: and ? ( a move requires write access on both dirs but that's still write access)
<vila> rcsheets: did you check perms under the '.bzr' directory ?
<rcsheets> vila: yes i checked for anything not owned by me, using find. it found many things under .bzr owned by the other user, but with group write access.
<rcsheets> group=admin throughout the directory structure, and i am in that group
<vila> great
<rcsheets> now that i own everything, it seems to work fine
<rcsheets> yeah, that did it
<vila> weird
<rcsheets> indeed. well, thanks!
<vila> until now, the issues we had with group perms always involved an sftp server ignoring bzr requests for group bits
<vila> unless fullermd remembers otherwise... never overestimate alzheimer ;-D
<rcsheets> i can retry using the latest bzr from my backup of the repository, if it would be helpful
<mgz> bialix: there are a few qbzr/bzr-explorer things I think that need to happen before 2.5, I wonder if you have any other suggestions
<mgz> 1) make filesystem watcher disabling work, and make it only watch versioned files
<vila> rcsheets: it's an issue with the working tree so it will useful only if you backed it up with the right perms
<mgz> 2) fix some exception encoding stuff once bzr has a mechanism for it
<mgz> 3) check if colo branches break anything too badly
<rcsheets> vila: i backed it up using "tar cf file.tar directory" as root. i *think* tar defaults to preserving all the ownership/permissions if you're root, but i may be wrong.
<mgz> I'll do some of that at least next week.
<vila> rcsheets: nope, that's my belief too
<rcsheets> it looks like it preserved everything
<rcsheets> i'll untar it somewhere else
<fullermd> The thing with sftp was that it filtered out the setgid bit.
<vila> rcsheets: file a bug then so we can keep track of the issue
<rcsheets> vila: i thought i'd check first to see if the bug still exists in the most recent release.
<vila> fullermd: yup, but did you ever encounter a case where the group bits were not respected while *not* using an sftp server ?
<vila> rcsheets: yup, exactly
<rcsheets> k
<fullermd> Not I.  But I wouldn't hit an issue even then, since I use a sane system that doesn't need that setgid crap anyway  ;p
<vila> hehe
<vila> mgz, bialix: from the top of your joined heads, how does the bzr installer build the ccurl-ca-buble.crt file and where is it stored ?
<vila> geee
<vila> curl-ca-bundle.crt
<vila> bubble...   lovely tyop
<bialix> vila: I've got it from mozilla
<vila> bialix: as in: got in once and never rebuild it ?
<bialix> it was stored along bzr.exe or inside lib/
<bialix> vila: well, I updated it several times in 2007-2008 I think when I maintained windows build
<vila> bialix: ok
<bialix> mgz: I was disconnected, if you said something before vila asked us about cert, please, repear
<bialix> mgz: I was disconnected, if you said something before vila asked us about cert, please, repeat
<rcsheets> vila: everything worked fine using 2.5b5
<vila> rcsheets: \o/
<bialix> vila: what's up with cert?
<vila> bialix: the urllib implementation can now verifies certs as long as some root certificates are provided... same issue you had with pycurl, I'm trying to gather how to find them for all platforms now
<Riddell> I just noticed that debian bug 641019 is fixed
<ubot5> Debian bug 641019 in pristine-tar "pristine-tar does not work with tar files made by openSUSE" [Normal,Fixed] http://bugs.debian.org/641019
<vila> Riddell: hello !
<rcsheets> fixed bugs are the best kind of bugs
<Riddell> so UDD should be workable with KDE tars, I guess it needs a sync
<vila> Riddell: yup, I've filed rt #50455
<bialix> vila: right. because bzr switched to urllib as default and it did not check certificates, I think that's why cert bundle wasn't updated for a looong time
<vila> bialix: ???
<Riddell> vila: lovely
<vila> bialix: urllib will be the default httpS implementation in 2.6 only
<bialix> vila: long time ago in far far galaxy
<vila> bialix: are you saying the windows installer don't carry pycurl anymore ?
<vila> doesn't
<Riddell> vila: I'll look at getting p-t 1.16 into precise when I get a chance
<bialix> I think so
<bialix> vila: yep, exactly
<vila> Riddell: that's lucid we need for jubany but getting >= 1.17 in precise won't hurt !!
 * vila coughs
<vila> mgz: ^^
<Riddell> yeah, needs backporting too
<vila> Riddell: I didn't check if 1.16 was enough but 1.17 seem to carry additional fixes
<mgz> sorry, was off responding to naoki's mp, unfortunately that's just the kind of change that won't work
 * mgz catches up
<mgz> bialix: will paste what I said in /query
<bialix> mgz, Riddell: I fear new filesystem watcher in explorer do more harm than help
<mgz> heh, I bet the certs we ship still have that dutch registrar in then.
<bialix> mgz: I think the best we can do before bzr 2.5 is out is make it disabled by default and provide config option for brave hearts
<mgz> there are six or so bug reports that I think are filesystem watcher related
<bialix> mgz: yes :-(
<Riddell> bialix: more problems from it?
<mgz> it's mostly down to two things,
<bialix> Riddell: mgz>	there are six or so bug reports that I think are filesystem watcher related
<mgz> it watches *everything* in the tree, including the .bzr dir, which can confuse other parts of bzr
<bialix> on windows it triggers Access is denied error tooooo often
<Riddell> bialix: I found it a big help for using explorer, if I have to use refresh all the time I find it no better than command line
<mgz> and on windows watching counts as a soft-lock
<bialix> that's limitation of filewatcher in Qt
<Riddell> bialix: but if there are problems then maybe it's more bother than it's worth
<mgz> I think that just limiting to versioned files should fix nix at least, then we can leave enabled there
<bialix> Riddell: I think we hit the limitation barrier of Qt itself here
<Riddell> to be fair on Qt it is limited by the operating system :)
<mgz> there are ways around the windows issues, eg
<mgz> moving a file in explorer should unwatch any children first, then rewatch after moving
<mgz> but just making the disable/enable work should be the first thing
<bialix> Riddell: right
<Riddell> I'd love to help but I'm behind on kubuntu stuff because this accident I had has made me slower so I doubt I'll get to it
<mgz> Riddell: your occasional opinion is all I'll bug you for :)
<bialix> me too
<mgz> is there anything else we think has to be done for qbzr or bzr-explorer before 2.5?
<bialix> mgz: back to your list: what do you mean by 2) fix some exception encoding stuff once bzr has a mechanism for it
<bialix> mgz: and 3) check if colo branches break anything too badly -- do you mean new colocated support in the core from jelmer?
<mgz> ah, er bug 599860 and any other things that will need fixing to once bzrlib changes how it does some trace encoding stuff
<bialix> because old bzr-colo stuff is used to work
<ubot5> Launchpad bug 599860 in Bazaar Explorer "UnicodeDecodeError with BzrError containing localised error message from OS" [Medium,Confirmed] https://launchpad.net/bugs/599860
<mgz> ^and right, jelmer's core colo things
<vila> mgz: you can probably add some ssl cert bundle building or disable cert verification or all lp users will whine
<bialix> mgz: re 599860: I can do a simple workaround by catching Unicode error there and try stringify
<mgz> hm, you mean exposing the conf option as a checkbox or something vila?
<vila> jelmer: around ?
<vila> mgz: I mean if we don't provide a valid bundle all https connections will fail
<mgz> bialix: for that bug, it's less about fixing the symptom and more making sure that once the core bzr stuff changes explorer doesn't break
<vila> so either we provide it or we set the ssl.cert_reqs option default value to none
<bialix> mgz, vila: http://wiki.bazaar.canonical.com/BzrWin32Installer#id20
<bialix> out-of-date a bit, but that's what I did back in 2008
<mgz> thanks bialix
<vila> thanks bialix
<vila> stereo effect :)
<bialix> we should check whether that still work with bzr.dev exe building
<vila> mgz: doxxx may need to do the same for the osx installers
<bialix> nice stereo
<vila> mgz: I'm working on bug #920455 so I need to know what path to use
<ubot5> Launchpad bug 920455 in Bazaar "ssl cert verification needs better defaults for all supported platforms" [High,Confirmed] https://launchpad.net/bugs/920455
<vila> mgz, bialix: I probably should reuse bzrlib.transport.http.ca_bundle.py for that (and for now)
<bialix> vila: at least that used to work
<jelmer> vila: yup
<vila> jelmer: (requeing ;)  seen my messages about quilt for udd ?
<jelmer> vila: scrolling up now..
<bialix> mgz: I'd be happy to prepare qbzr/explorer for bzr 2.5 with you.
<jelmer> vila: you can use quilt-smart-merge=False to disable it
<vila> jelmer: in the package itself I presume ? (given the name with - instead of _ ;)
<jelmer> vila: yes
<vila> jelmer: won't work for jubany
<vila> jelmer: but keep reading, quilt has been deployed I don't need to disable at a global level anymore
<jelmer> vila: given it's a package dependency, I'm not sure if it's really necesary to cope better with quilt being missing as it should always be there
<mgz> bialix: that would be great
<vila> jelmer: dependency of bzr-builddeb ?
<jelmer> vila: yes
<vila> of course, I agree then
<vila> jelmer: will teach me to deploy unpackaged packages ;)
<jelmer> heh, indeed ;)
<mgz> bialix: hm, mind if I just cherrypick the treewidget fix to 0.21 rather than rebasing? having the first branch landed and not wanting the last one there makes things a bit more confusing
<mgz> will add the news after the cherrypick
<bialix> mgz: anything is fine for me
<mgz> doing that now, will propose so the diff passes by you
<vila> Riddell: cjwatson just mentioned he did sync pristine-tar 1.17 in precise ;)
<mgz> dammit, this feature moving is just annoying me now
<vila> mgz: rather than two months ago you mean ? :-D
<Riddell> vila: lovelyness
<mgz> I should update to latest beta, that backward import I think
<bialix> mgz: feature moving?
<mgz> ha! now on 2.5b5 and... different error ;_;
<mgz> plugins/qbzr/lib/tests/test_spellcheck.py", line 25, in <module> class _PyEnchantFeature(Feature):
<mgz> TypeError: Error when calling the metaclass bases __init__() takes at least 5 arguments (4 given)
<mgz> I should just get a 2.4 install so I'm running the right versions against each other
<mgz> okay, tests pass on 0.21
 * mgz reverts to .po
 * vila out for lunch
<mgz> ga, I hate news
<mgz> added it to a released section, needed to make a new one
<jelmer> vila: hmm, I'm just looking at some test failures in debian
<jelmer> it's not a problem if read() in bzrlib/tests/test_test_server.py line 77 raises a 104 error (connection reset by peer) ?
<bialix> mgz: thanks
<mgz> bialix: I think I got all the bits right in the end, but yell if you see anything I messed up
<vila> mgz: hehe, welocme to the club ;)
<vila> jelmer: let me have a look
<vila> jelmer: trunk ?
<vila> jelmer: ha, *that* read :-/
 * bialix just re-read the description of qbzr on lp: "A simple Qt cross-platform frontend for some of Bazaar commands" and thought how many of that is still true? simple? some commands?
<vila> jelmer: my take here is that we should go back to where this code was introduced and split new tests instead of messing with the existing ones
<vila> jelmer: the modifications were based on an assumption that has been proved wrong repeatedly and their intent has never been clear to me
<mgz> how do you do that neat tracked-in-0.22 series thing in launchpad?
<vila> jelmer: add the fact that these tests tend to succeed for many known (and some more unknown) races to blurry the area...
<vila> jelmer: but which tests do you see failing ?
<bialix> mgz: click on Target to series
<bialix> mgz: select trunk and desired series
<Riddell> bialix: and it should11:27 < Tm_T> dpkg: error processing /var/cache/apt/archives/plasma-dataengines-addons_4%3a4.8.0-0ubuntu1~oneiric1~ppa1_amd64.deb (--unpack): trying to  overwrite '/usr/share/kde4/services/plasma-engine-kdeobservatory.desktop', which is also in package plasma-widget-kdeobservatory  4:4.7.4-0ubuntu0.1
<Riddell> oh sorry
<mgz> ah ah, trunk
<Riddell> bialix: and it shouldn't mention Qt, that's an implementation detail
<bialix> Riddell: I'm sorry I'm not quite understand
<Riddell> bialix: "A simple Qt cross-platform.." Qt can be removed from there, it doesn't matter what widget toolkit you use what matters is the end result
<mgz> ...pasted the wrong thing Riddell?
<bialix> Riddell: right, that's true, it's simple implementation detail
<Riddell> mgz: yes, I shall now remove my stupid thinkpad touchpad with a stanley knife
<Riddell> bialix: how about "A user friendly GUI to Bazaar commands and guided usage" ?
<bialix> mgz, vila: I'd like to commit my workaround for bug https://bugs.launchpad.net/qbzr/+bug/912344
<ubot5> Launchpad bug 912344 in Bazaar "Bazaar explorer crashes when in browse and I try to show annotate on a file" [High,Confirmed]
<bialix> although that's clearly bug in bzrlib, but we can workaround it in qbzr itself
<mgz> I'm still not used to middle-click paste, I'm alwasy trying to open a new tab but end up in a search for whatever's on (one of) my clipboard at the time
<bialix> Riddell: good. But what do you mean by "guided usage"?
<bialix> Riddell: but I think your description is better suited to Bazaar Explorer
<mgz> something along the lines of Riddell's suggestion would work for qbzr
<vila> bialix: workaround seems fine
<Riddell> bialix: oh right maybe that's what I'm thinking of
<mgz> just need to get across the point that it's guis for individual commands
<jelmer> vila: test_handle_request_closes_if_it_doesnt_process is failing
<Riddell> bialix: then maybe "A user friendly cross-platform GUI to Bazaar features"
<vila> jelmer: yup, known but rare spurious one
<bialix> Riddell: !
<jelmer> vila: is there any reason getting a 104 error there is invalid?
<Riddell> bialix: what's that ment to mean? :)
<bialix> Riddell: that mean: yes, that's good one
<Riddell> oh nice, go me :)
<vila> jelmer: long story short: can't say. I was against closing in handle_request as it broke the known working model...
<bialix> "go me"?
<mgz> bialix: while I have you, on an unrelated issue, are you aware of anything in bzr-explorer that can cause it to open lots and lots of connections to the same server?
<vila> jelmer: *why* it breaks (as revealed by this failure) is unknown to me
<mgz> bialix: Riddell is pleased you liked his suggestion
<bialix> mgz: I think that's because we have separate codebase for inspecting working tree status + working tree widget + what's is not submitted to the parent branch
<mgz> but that's still only two or so connections right?
<bialix> mgz: my own opinion on this is that there should be a dedicated process to do all bzr heavy-lifting, while bzr-explorer itself should be a thin frontend, like a browser
<bialix> mgz: I've once described  my thoughts on this topic back in April or May 2011, but I haven't had enough spare time to implement this wild and heavy idea
<bialix> mgz: that too many connection error also could be triggered in qlog alone
<mgz> ha, yes... what causes the error to be raised rather than just opening lots of connections though?
<bialix> mgz: bzr-explorer re-fresh status from time to time, so I suppose it re-open the branch many times
<bialix> connection just is not re-used
<bialix> mgz: yes, the branch should be reopened on refresh, otherwise in some corner cases we lost track of actual changes
<bialix> like switching light checkout to another branch behind GUI
<bialix> would you like me to find my old rant?
<mgz> bialix: that would be nice, doesn't seem to be on the bzr list?
<bialix> mgz: would you like to be listed in AUTHORS.txt list of qbzr with your full name, rather than [gz] ?
<bialix> mgz: I found it, May 3, 2011. I see it in qbzr ML, should be in bzr ML as well
<mgz> bialix: I'm fine with either
<vila> bialix: he won't tell you but I'm sure he prefers [gz] ;)
<bialix> vila: that was my suspicious too
<bialix> mgz: https://lists.ubuntu.com/archives/bazaar/2011q2/072377.html
<mgz> thanks bialix
<bialix> mgz: actually, I still think it could help, but in the same time it will require too much efforts
<bialix> maybe re-using part of TortoiseBzr, but it too tight coupled to windows
<mgz> well, we can leave till after 2.5 at least
<bialix> maybe using python standard (in 2.6) processing library would help (a lot)
<bialix> I meant "processing"
<bialix> or it's called now "multiprocessing"
<bialix> mgz: do you have a favorite tree?
<bialix> we need codename for 0.22
<vila> bonzai ? :-D
<bialix> it's not a specie, it's a form
<vila> rats, for once the tyop was also a pun ;)
<mgz> hm.
<mgz> alder?
<bialix> wrong word
<bialix> sold!
<mgz> apparently the one round here is alnus glutinosa or black alder.
<bialix> nice
<mgz> heh, and on the wikipedia page vila, it has a 'Bonsai' section
<vila> lol, I'm on the wiki page but not there yet ;)
<bialix> this summer I saw exhibition of bonsai trees, it was nice. no alder unfortunately
<mgz> bialix: after a qbzr (or bzr-explorer) release, who does the packaging for debian/ubuntu?
<bialix> not me
<bialix> I'm not sure who make packages now
<bialix> who does the packaging for other bzr products?
<mgz> someone who's name begins with J and ends with elmer does bzr itself,
<mgz> perhaps I can twist his arm into doing or helping me with qbzr and explorer, if he doesn't already.
<mgz> right, lunch time for me.
<LarstiQ> mgz: http://packages.qa.debian.org/q/qbzr.html points at http://packages.debian.org/changelogs/pool/main/q/qbzr/current/changelog which says mister Elmer and Andrew Starr-Bochicchio
<LarstiQ> lately at least
<smoser> is this a known error:
<smoser> $ bzr branch lp:~orchestra/orchestra/odev
<smoser> You have not informed bzr of your Launchpad ID, and you must do this to
<smoser> write to Launchpad or access private data.  See "bzr help launchpad-login".
<smoser> bzr: ERROR: Target directory "" already exists.
<smoser> why would target directory be ""
<smoser> ?
<vila> smoser: sounds familiar but only for quite recent bzr versions, I think jelmer already fixed it
<smoser> this is precise "right now"
<smoser> $ dpkg-query --show bzr
<smoser> bzr     2.5.0~beta5-3ubuntu1
<vila> jelmer: can you confirm ? ^
<mgz> LarstiQ: thanks, now do I need to bug you to propose your pypy test fixes? :)
<jelmer> vila: no, that's not actually fixed yet but it's on my radar
 * mgz drives jelmer nuts with non-review review comments
 * jelmer_ drives jelmer nuts by not being entirely awake today.
 * vila throws nuts
<mgz> meh, not a list admin, can't approve my message with too-large attachments
<vila> use smaller attachments ;)
<mgz> that means downloading, compressing, and reattaching, but yeah, is probably sanest
<vila> you really need to send such a big attachment ?
<LarstiQ> the limit isn't that high iirc
<vila> which list ?
<LarstiQ> mgz: no, I should have some time today
<LarstiQ> mgz: between work/study/renovating there isn't much to go around
<vila> in the good old days, merge proposals came with their associated bundle... and could be quite large
<LarstiQ> vila: hmm, true
<mgz> internal one, but 6MB was pretty large
<mgz> LarstiQ: don't let me stop your carpentry
<LarstiQ> mgz: no worries, I need a break from it :)
<wgz> ouch, a ValueError on missing certs dir? that's not nice
<fullermd> Hey, it's not making a value judgement.
<fullermd> Or, wait, I guess it is...
<LarstiQ> wgz: at the end of bzrlib.hashcache.HashCache.read there is a comment we should use try/finally, is there a reason we're not doing so?
 * wgz checks
<wgz> I think just that it was a pain to reindent everything and I didn't hit any cases that actually threw on the intervening lines
<wgz> technically things could, but only with broken files I think
<lifeless> well, that never happens :P
<wgz> :)
<wgz> if the error results in bzr exiting anyway, closing the file you're reading from promptly is less important
<vila> wgz: Straight ValueError ? Or ConfigValueError  (the later should give proper info to the user) ? Do we need blackbox test for that maybe ?
 * vila off
<wgz> vila: you changed one of them in your ssl defaults branch anyway
<vila> wgz: right, IIRC I *removed* one possible cause of ValueError leaving only a ConfigValueError but imbw
<wgz> dammit, I just tried to use vi on this box
<wgz> I clearly can't segment my life properly.
<lifeless> wgz: bzr is used as a library too though
<LarstiQ> wgz: what I have so far, minus tar export changes, is at lp:~larstiq/bzr/bzr-pypy
<lifeless> wgz: so 'exit this call' != 'exit the process'
<LarstiQ> wgz: there is more work in a similar vein to do still, so not sure about proposing it for merging
<lifeless> LarstiQ: does it work?
<lifeless> LarstiQ: is it in the right direction?
<LarstiQ> lifeless: yes, no NEWS entry written yet
<lifeless> do that and merge IMNSHO
<LarstiQ> lifeless: ok. While I think on how to formulate that entry I can squash more test failures :)
<wgz> yeah, I agree, am always a propose-first news-last person myself
<wgz> when I remember news that is.
#bzr 2012-01-26
<vila> helllo !
<mgz> morning all!
<fullermd> Oh, not again.  I just dealt with a morning yesterday  :(
<vila> mgz: 182.926  safe_decode() called on an already-unicode string: u'Jonathan Riddell <jriddell@ubuntu.com>'
<vila> mgz: on jubany, expected ?
<mgz> yes.
<vila> k
<mgz> combination of safe_decode being a bad idea and debian.changelog api switch I'm guessing.
<mgz> didn't really need to highlight Riddell there, not his fault he's unicode :)
<Riddell> :)
<mgz> jelmer: bug 922121 looks like one for you too, can do a s/\.inventory/\.get_inventory()/g in qbzr?
<ubot5`> Launchpad bug 922121 in Bazaar Explorer "Starting Bazaar explorer the 1st time: GitWorkingTree.inventory AttributeError" [Undecided,New] https://launchpad.net/bugs/922121
<jelmer_> mgz: not really, foreign trees don't have inventories
<mgz> did it never work then, rather than being related to api movings?
<jelmer_> mgz: bzr-git did provide something which resembled an inventory at some point, when it was still part of the API
<mgz> I swear I've done `bzr explorer some-git-repo` in the past, but maybe not.
<jelmer_> mgz: it never provided the full thing, which was one of the reasons why I wanted to remove inventory
<jelmer_> mgz: but it might have done some things, sufficient to get explorer working
<LarstiQ> mgz: hmm, maybe I shouldn't have picked you as a reviewer, now bzr-core doesn't show up
<mgz> I can add everyone else too
 * mgz goes mp hunting
<mgz> done.
<LarstiQ> yay!
<AuroraBorealis> i posted an update to this bug, no idea if it will help https://bugs.launchpad.net/bzr/+bug/855155
<ubot5`> Launchpad bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [High,Confirmed]
<vila> jelmer_, mgz: pristine-tar 1.17 deployed on jubany but 2 new bugs, see #is for some details :-/
<vila> Riddell: ^
<mgz> AuroraBorealis: thanks, might try and look at that over the weekend
<AuroraBorealis> i'm afraid it might not be useful because i'm not getting the inconsistant delta error anymore
<AuroraBorealis> but the tree is still in a very weird state where it thinks everything is conflicting
<mgz> vila: #is doesn't seem to be logged and I'm not in there.
<vila> mgz: then join, I'll paste
<jelmer_> vila: it just seems to be an issue with the backport of pristine-tar
<mgz> I guess I'd better just add #launchpad and #is to my autojoin, but am determined to stay in single figures
<LarstiQ> mgz: move to a hexadecimal base for some breathing room?
<mgz> alt+a already seems to do something, but I'm not sure what
<vila> mgz: marking you away ?
<mgz> vila: I hope not
<vila> that's what it does here ;)
<mgz> ...apparently moves you to the last 'active' window, wheree're last someone spake
<vila> jelmer_: http://package-import.ubuntu.com/status/lxc.html#2012-01-26%2017:07:04.101838
<jelmer_> vila: is that with bzr-builddeb trunk?
<vila> jelmer_: yes
<vila> jelmer_: but not bzr trunk if that matters
<jelmer_> vila: it probably makes sense to disable 'quilt-smart-merge' in the importer
<vila> jelmer_: oh, by the way, I've requeued all multipletarballerrors and only a few have failed (for a different reason) so we're down to 452 import failures
<jelmer_> vila: we'll likely have to throw them away in the future and reimport them :-/
 * vila blinks
<vila> which ones ?
<jelmer_> vila: the multitarball ones
<vila> is it that bad ?
<jelmer_> yes
<vila> shudder, I'm tired
<vila> I meant the branches we push are not usable ?
<jelmer_> vila: they're somewhat usable, but have too much data (some revisions imported lots of times, for example)
<vila> k
<jelmer_> vila: this is what I mentioned the other day when you asked about the multi tarball status
<vila> right, but I understood that they will still failed so was a bit surprised
<vila> but back to disabling quilt-smart-merge, I thought it was: set in tree, default in bazaar, so no way to disable globally right ?
<jelmer_> ah, I see
<jelmer_> vila: no, you can disable it in the per-user config of bzr-builddeb as well
<jelmer_> vila: ~/.bazaar/builddeb.conf
<vila> so it's ~conf/tree/bazaar.conf ?
<jelmer_> vila: what do you mean?
<vila> the order the conf files are used
<jelmer_> vila: it's roughly debian/bzr-builddeb.conf, debian/bzr-builddeb.conf.local, ~/.bazaar/builddeb.conf
<jelmer_> sorry
<jelmer_> vila: it's roughly debian/bzr-builddeb.conf.local, debian/bzr-builddeb.conf, ~/.bazaar/builddeb.conf
<vila> hmm, so we can only disable by default right ?
<vila> or do you mean there is little chance yet that anybody set it anyway ?
<jelmer_> vila: yeah, you wouldn't really want to set this on a per-tree basis I think
<jelmer_> except perhaps to disable it as it's enabled by default
<vila> a lot of imports have already succeeded with it enabled (I've monitored a few ans see the [quilt xxxx] messages
<vila> I mentioned the above as I thought it may be an edge case you wanted to fix as ISTM this is working well so far
<vila> well, anyway, think about it and tell me what you want tomorrow, I'm crashing ;)
<jelmer_> vila: I think we should disable it for the imports, it just slows them down without any benefit
<jelmer_> vila: thanks for the headsup about lxc though
<jelmer_> vila: I suspect it's a broken tree, but I'll look into it
<vila> jelmer,mgz: last thing, freebsd failed several tests for trunk (http://babune.ladeuil.net:24842/view/%20High/job/selftest-freebsd/lastFailedBuild/#showFailuresLink)
<vila> they are all caused by an invalid ssl.ca_certs path which my fix should address
<vila> I did test it for freebsd
<vila> but the same issue will be encountered everywhere we run the test suite or want to connect with https... that really needs to be addressed before 2.5.0
<lamalex> is there a way to build a binary package from a recipe locally?
<jelmer_> lamalex: hi
<jelmer_> lamalex: somewhat - you can use bzr builder to build a source package and then use the normal package build tools to build a binary package from that
<lamalex> jelmer_, how do you build from a source package?
<lamalex> sorry, im not a packager by any means
<james_w> lamalex, "dpkg-source -x <package>.dsc; cd <package>; debuild" would be one way
<james_w> if I have a cronjob that runs "bzr pull" and the branch is getting updated but not the tree, what might be the cause?
<jelmer_> james_w: there is a post_pull / post_branch_tip_change hook that fails?
<jelmer_> I would expect you to be mailed a traceback by cron in that case though
<james_w> I don't think so
<james_w> oh, I don't think cron mail is connected to anything in this case :-)
<james_w> it's a remote server
<james_w> when I run pull by hand nothing fails at least
<jelmer_> james_w: it might be related to encoding stuff, for example
<jelmer_> james_w: if you have a way to read your mailbox on the remote machine, it might be worth a short to look there
<james_w> there's no mail for the user with the cron job
<jelmer_> hmm
<jelmer_> beats me - "bzr up" runs without problems?
<james_w> actually
<james_w> I think something else is resetting the tree
<james_w> oh
<james_w> it's a lightweight checkout
<james_w> that's probably not going to work too well
<poolie> hi jelmer_, james_w, wgz
<james_w> hi poolie
<wgz> hey poolie
#bzr 2012-01-27
<niemeyer> Hello everybody
<niemeyer> Is there any way to tell bzr pull something like --overwrite-my-local-tags-only
<niemeyer> ?
<wgz> I can't quite guess from the name...
<wgz> ah, you maybe mean, no new revisions, just get the tags updated?
<niemeyer> wgz: Yeah, don't do something crazy with my branch, but overwriting tags that point to different revisions is fine
<wgz> `bzr pull -r0 BRANCH` should work.
<wgz> -r1 might be safer as it'd tell you before pulling in tags from an unrelated branch
<niemeyer> wgz: Not sure I see where you're coming from
<niemeyer> wgz: This doesn't really pull the tag changes?
<niemeyer> wgz: I mean conflicting tags
<niemeyer> wgz: Which are currently only pulled down with --overwrite
<niemeyer> wgz: Which unfortunately has other side effects well beyond pulling tag replacements
<wgz> hm, the check for tags may happen at a later stage
<wgz> and tag conflicts are another fun thing altogether
<wgz> hm, no does work
<wgz> so, it's only the conflicts case then to worry about
<niemeyer> wgz: Yeah, that's exactly the problem I'm trying to solve :(
<niemeyer> wgz: I need to overwrite tags commonly, but using --overwrite all the time is not nice
<niemeyer> It's just waiting for the day it will _actually_ overwrite something, unintendedly
<wgz> file a bug, it doesn't seem quite as rabbit hole-ish as other tag related requests.
<fullermd> You could just make an alias that deletes all your tags, then pulls   8-}
<niemeyer> wgz: Thanks, will do
<niemeyer> fullermd: This is part of the Go language's standard installation tooling
<niemeyer> fullermd: I'm not keen on putting such an ugly hack there
<niemeyer> It's what enables people to use Bazaar to host Go packages
<niemeyer> The reason they have to override the tags is that Go allows people to tag which revision of the branch a given release of Go should pull
<niemeyer> and this of course means the tags have to be overwritten every now and then
<wgz> how about replacing .bzr/branch/tags with an empty file as an ugly hack? :)
<fullermd> Are you sure you need the pull to update the tags?  I mean, you don't really care about the tags locally, as long as you have the right rev, right?
<niemeyer> fullermd: It pulls the changes, and updates to the given revisoin
<fullermd> And I think -r on pull resolve the rev as the remote side things of it.  So maybe "yeah, my local tags list is out of date, but the rest still works" is a usable step.
<wgz> and yeah, does seem like there should be a neater solution to that particular issue, which I'll leave to fullermd
<fullermd> Oh, neat solutions are _totally_ not my baliwick   8-}
<fullermd> Unless you mean neat in the sense of "Hey, neat, I didn't know my elbow bent that way!"
<niemeyer> fullermd: It doesn't pull from remote until requested.. it may shift revisions around multiple times though
<niemeyer> LOL
<niemeyer> fullermd: We can talk eyebrows later, but I have to find a solution to that first. :)
<fullermd> Right, but I think the resolution would happen on the far side's view.
<fullermd> So, e.g. `bzr pull -rtag:FOO where://ever` would look at that remote side for tag 'FOO', turn that into a revid, then pull that revid down and set the tree to it.
<jelmer_> niemeyer: bug 681792  ?
<ubot5`> Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [Medium,In progress] https://launchpad.net/bugs/681792
<niemeyer> jelmer_: YES
<fullermd> (tag FOO existing locally pointing to some other rev would make it kvetch about the tags not matching, but that would be after it set everything to the 'right' rev anyway)
 * niemeyer +1s.. or subscribes.. or thumbs ups, or whatever the me too of the day is
<wgz> +affectsmetoo
<niemeyer> jelmer_: Man, and it's in your plate too
<wgz> has the plus, and affects, and me too.
<niemeyer> jelmer_: I'm afraid you won't want to see my name anymore.. ;-)
<jelmer_> niemeyer: hehe
<jelmer_> niemeyer: at least you're not adding more bugs to the list this way.. ;-)
<jelmer_> niemeyer: so, that bug actually has a branch attached that fixes it (IIRC the emacs folks asked about it). It just lacks tests, but we can add those and make sure it ends up in 2.5/precise.
<jelmer_> niemeyer: IOW, it shouldn't be more than an hour of two of work additional. How much do you need it?
<niemeyer> jelmer_: Just added the explanation to the bug
<niemeyer> jelmer_: I need it badly.. everybody that is using the "go" or "goinstall" standard tools now from Go are running "--overwrite" on their branches often
<niemeyer> Without even realizing
<jelmer_> niemeyer: ok
<wgz> meh, nearly got to bed an hour ago
<niemeyer> wgz: :)
<niemeyer> Btw, on a half-related side note, how do I check if e.g. http://launchpad.net/project has a branch associated with it programatically? Can I poke in lp.net/project/.bzr or something?
<jelmer_> niemeyer: you can use the Launchpad API to see if it's got a development focus branch
<niemeyer> jelmer_: Is there a non-api way with a trivial http get?
<niemeyer> jelmer_: E.g. if /project/.bzr/location.conf 404s it's not there
<niemeyer> jelmer_: Or is it more magic than that?
<jelmer_> niemeyer: I guess something like that would work too. Perhaps http://code.launchpad.net/PROJECT/.bzr/branch-format ?
<jelmer_> (assuming the project is public, etc)
<niemeyer> jelmer_: Perfect
<niemeyer> jelmer_: Thanks
<niemeyer> That's for the go tool as well.. I have to improve the handling of series
<jelmer_> ah, no launchpad API library for go yet ? :)
<niemeyer> jelmer_: Oh, we have a fairly complete one actually :)
<niemeyer> jelmer_: http://goneat.org/lp/lpad
<jelmer_> ah
<jelmer_> neat
<niemeyer> jelmer_: The documentation is a bit messy because they've made a change in godoc that is mixing up some methods, but that's being fixed already
<niemeyer> jelmer_: But the reason I'm looking for something simpler is that it'd be too much to use that in the go tool
<niemeyer> jelmer_: I just want to disambiguate the case of lp.net/project/a/b/c
<jelmer_> ah, I see
<niemeyer> jelmer_: It could be a branch at lp.net/project with /a/b/c, or a series branch at lp.net/project/a, with a /b/c directory
<niemeyer> jelmer_: A quick get on the branch-format you pointed to solves the question
<niemeyer> Profit!
<AfC> Just filed a UX bug; is there a tag I should add?
<achiang> hello, can someone please remind me how to bypass bzr's builtin ignore file and force it to commit binary .so files?
<achiang> oh, i just edit ~/.bazaar/ignore
<achiang> i wonder if that is auto-created the first time i use bzr?
<AfC> If you add & commit an ignored file, it won't be ignored
<achiang> bzr init ; bzr add ; bzr commit in an existing directory with foo.so files will skip the .so files (obviously due to ~/.bazaar/ignore)
<achiang> i haven't tried directly doing: bzr add foo.so
<mwhudson> achiang: directly doing bzr add foo.so will add the file
<achiang> mwhudson: thx. i was just being lazy, i suppose. :)
<vila> hey guys !
<mgz> morning!
<vila> mgz: hey !
<vila> mgz: ping, pm ?
<mgz> thanks vila
<wgz> http://stackoverflow.com/questions/4145123/whats-the-right-way-for-a-python-twisted-program-to-validate-an-ssl-certificate
<LeoNerd> Mmmm.. async. SSL. Always fun
<vila> wgz: this doesn't really give an easier solution for windows than getting the curl bundle (as far as my reading went)
<vila> so far
<mgz> indeed, that's the point.
<mgz> and (without bothering the man in here) if that's what g-lyph says I'm inclined to believe it's true
<vila> mgz: err, not sure I follow, you conclusion is to do what ?
<vila> s/you/your/
<mgz> cry?
<mgz> well, add the nix style certs to the all-in-one installer at least
<vila> I don't get it, with the code we have already in place, all we need is a single bundle with all the cert roots in there, ha ok
<vila> I agree it's not a super clean solution but it will at least avoid blocking everybody
<vila> paranoiac users can still chose to opt-out trivially and we'll find a better way later
<mgz> I'm not sure I know of any good twisted introductions
<mgz> has always been obtuse, despite the reasonable amount of documentation and such like
<mgz> 2.5 needs from __future__ import with_statement right?
<mgz> ...yes, check it yourself lazy
<mgz> morning jelmer
<jelmer_> ohai mgz
<jelmer_> my irssi highlights seems to be b0rked :(
 * mgz strips jelmer_'s underscore
<jelmer_> hah, good point
<mgz> having the same nick and name is simple at least
<mgz> realised in mp comment I have confusing style by referring to John and Vincent... but then also Larstiq. Mixing up names and nicks is bad form.
<jelmer> mgz: I think you'll find it's LarstiQ :P
 * jelmer stops being pedantic
 * LarstiQ cringes
<mgz> larsty-queue?
<mgz> I wonder what the most painful way to pronounce it is :)
<LarstiQ> mgz: oh there are many
<mgz> can't top qt and gnome whatever.
<LarstiQ> jelmer: one of these I might switch to all lowercase, but I'm afraid that won't stop people from occasionally capitalising the l
<jelmer> :)
<mgz> jelmer: so, I'm doing review stuff now (though vila has already bashed a fair bit), want to hop on mumble or similar?
<sidnei> hi folks, i'm seeing a traceback with tarmac in precise, which smells like maybe some api change: http://paste.ubuntu.com/818744/
<mgz> sidnei: bug 917733
<ubot5`> Launchpad bug 917733 in Tarmac "AttributeError: 'NoneType' object has no attribute 'cmdline_overrides'" [Medium,In progress] https://launchpad.net/bugs/917733
<sidnei> aha
<mgz> ...which has actually been merged into 2.5
<mgz> there's also a tarmac branch though, which explains the in progress
<sidnei> i guess it wasn't released in precise yet though?
<jelmer> mgz: sounds good - mumble it is
<mgz> nope. there are also enough things like this that I'm wondering if leaving it to 2.5 final won't be a bit long
<mgz> ha, talking to myself.
 * mgz goes back to humming
<jelmer> mgz: sorry
<jelmer> mgz: I was talking to myself too
<jelmer> mgz: my laptop (which I was using solely for mumble) suspended because it hit ten minutes of "inactivity"
<jelmer> argh,not again
<mgz> jelmer: sus... right
<jelmer> I was talking about the same thing as last time too :)
<mgz> :D
<mgz> it's a curse!
<mgz> jelmer: that might be sign for lunch
<jelmer> heh
<jelmer> good point
<jelmer> back in a bit
<mgz> hm, cake might be a bit too lemony
<mgz> bug 903696 is pretty popular
<ubot5`> Launchpad bug 903696 in bzr-gtk (Ubuntu) "bzr-notify crashed with SIGSEGV in g_return_if_fail_warning()" [Medium,Confirmed] https://launchpad.net/bugs/903696
<jelmer> WHY am I in three independent IRC channels where people are talking about cake?
 * jelmer feels like he has missed a memo, or something
<mgz> :)
<mgz> it's all gone now
<mgz> jelmer: mumble again?
<mgz> heh:
<mgz>     def destroy_branch(self, name=None):
<mgz>         """See BzrDir.create_branch."""
<jelmer> mgz: okay
<jelmer> mgz: hehe
<mgz> neither BzrDir.create_branch nor BzrDir.destroy_branch actually exist any more
<mgz> as they've been moved up to ControlDir
<mgz> so, the current error message for the destroy branch no branch branch branch branch branch
<mgz> sorry, got carried away
<mgz> is: 'Not a branch: "": location is a repository.'
<mgz> and destroy_branch is documented as taking None (that should be 'the empty string' now, right?)
<mgz> for name for the default branch
<mgz> same in create_branch
<vila> jelmer, mgz : pfew, finally, I think I found the pristine-tar last blocking issue: pbzip2 needs to be upgraded on jubany...
<mgz> jemler: https://lists.ubuntu.com/archives/bazaar/2012q1/074286.html
<vila> yeah jemler, no wonder his filters won't catch it ;)
<mgz> jelmer: ;_;
<hariom> I want to download a repository that is password protected. Is there any way to send username and password in a single command (eg: username:password@someserver/repo)
<mgz> hariom: in the context of what protocol? http?
<hariom> mgz: https. I am currently using something like: bzr branch bzr+https:// ...          I want to add username and password also
<mgz> hariom: what you probably want is to add the details to your authentication.conf
<hariom> mgz: Actually I am doing it to automate my program pulling the repo and setup the system. I can't expect my user to modify authenticate.conf
<hariom> mgz: bzr branch <scheme>://<user>:<password>@host:port/path
<hariom> I guess this should do. Just read the doc
<mgz> it does work, bar possibly a few edge cases you probably won't hit
<mgz> but putting the auth in the location isn't really ideal
<jelmer> vila: hi
<jelmer> vila: is there an easy way to do RegistryOption perhaps?
<dandrader> hello! how can I merge two commits into one in bzr? Like the equivalent to "git commit --amend" or "git rebase -i" and then selecting "squash"
<mgz> LarstiQ: yell when you've pulled in the change for the bzr-pypy branch and I'll land it
<mgz> dandrader: if they're the two you've just done, you can uncommit twice then commit
<mgz> otherwise there's the bzr-rebase plugin for more complex stuff
<dandrader> mgz, ok, thanks!
<SpamapS> When using merge-upstream, I got some of these:
<SpamapS>   Conflict adding files to plugins-src.  Moved to root.
<SpamapS> I'm a bit confused how to deal with them
<LarstiQ> SpamapS: is merge-upstream from bzr-builddeb?
<SpamapS> yes
<LarstiQ> SpamapS: do you have some more context on those conflicts? Maybe `bzr status` output?
<SpamapS> These look like just new files, not sure why there is a conflict
<SpamapS> http://paste.ubuntu.com/819191/
<SpamapS> theres the full bzr status
<SpamapS> I'm inspecting the contents of the branch.. cmp'ing to an untar of the imported tarball.. and it all looks good
<SpamapS> so maybe this is just a weirdness of merge-upstream ?
<LarstiQ> SpamapS: for the plugins-src conflict, the only thing I could think of is that in one tree a file got added with the same path (but different file-id) as a file in the other tree
<LarstiQ> but for the license files that doesn't make sense
<SpamapS> LarstiQ: whats odd to me is that the resulting contents are perfect, so I don't know why it thinks there is any conflict
 * LarstiQ looks at the code
<LarstiQ> oh hey, there is `bzr help conflict-types`
<LarstiQ> SpamapS: it's the Missing parent conflict
<SpamapS> LarstiQ: ahh so merge expected that there would be a revision for that file, but there wasn't?
<SpamapS> I'm pretty sure its ok.. and won't break.. much. :)
<LarstiQ> SpamapS: no, the file is added to a directory in branchA and deleted in branchB
<LarstiQ> SpamapS: that is, that _directory_ has been deleted
<SpamapS> ah, ok, so there's no parent for the directory itself.
<SpamapS> this sort of makes sense. :)
<LarstiQ> SpamapS: if you look at the history you can probably figure out which dir those files got added to that is now gone
<SpamapS> LarstiQ: from what I'm seeing, they all got added to the root
<SpamapS> LarstiQ: unless rsync is broken too.. it verifies that the contents of the tarball, and the contents of my working copy, are identical
<LarstiQ> SpamapS: but if you're happy with their current location that would mainly be to satisfy your curiosity
<LarstiQ> SpamapS: yeah
<LarstiQ> wgz: pulled, confirmed it's fine under pypy, and pushed
<LarstiQ> wgz: should I not change writes to build_tree_contents?
<wgz> LarstiQ: I wouldn't bother, as generally there are also bigger things that would be worth changing with old tests
<wgz> and then you're rewriting it, which risks breaking the test
<LarstiQ> wgz: right
 * LarstiQ nods
<wgz> LarstiQ: sent. now, off to quiz, bye!
<LarstiQ> wgz: ciao!
<LarstiQ> wgz: oh, and thanks :)
<sidnei> jelmer, filed bug #922800 about the bzr-git vs github issue, before i forget
<ubot5`> Error: Launchpad bug 922800 could not be found
<jelmer> sidnei: thanks
<jelmer> sidnei: is there a particular reason it's private?
<sidnei> jelmer, launchpad decided so? i didn't pick private.
<jelmer> sidnei: ok, just checking
 * jelmer changes to public
<Noldorin_> hi jelmer
<jelmer> hi Noldorin_
<jelmer> how's it going?
<Noldorin_> good thanks...
<Noldorin_> you?
<jelmer> alright too
<Noldorin_> jelmer, how's progress on... things? :-)
<LarstiQ> jelmer: ehm, get_get_config should be test_get_config?
<jelmer> LarstiQ: whoops
<jelmer> LarstiQ: I noticed it in the per_branch tests, and then I still copy-n-paste it incorrectly..
<jelmer> Noldorin_: Hacking on colocated branches, mostly
<wgz> came third.
<Noldorin_> jelmer, ah okay :-)
<Noldorin_> jelmer, will they be in 2.5 final then?
<Noldorin_> they look pretty mature now
#bzr 2012-01-28
<berdario> Hello, I was reading about the move to colocated branch as default: https://lists.ubuntu.com/archives/bazaar/2011q1/071911.html
<berdario> I'm quite curious, since I've never used colocated branches with bzr (though I have experience with git and hg)
<berdario> in particular... I read most of the thread, but I haven't understood what was the final decision
<berdario> and the roadmap seems outdated: http://wiki.bazaar.canonical.com/Roadmap
<berdario> it's january 2012, and we still don't have bzr 3.0...
<berdario> then, if I understood correctly, one of the main reasons for the move to colocated branches would be to avoid having to do huge recompiles in C-like projects when creating a new branch
<berdario> (but there doesn't seem to be much consensus around that: some peoples were worried about under-recompiles when switching colocated branches)
<berdario> I find myself comfortable with separate branches... do you suggest I should start using colocated branches instead?
<wgz> nope, not if you don't have a reason to
<berdario> wgz, ok... so I shouldn't worry about it at all?
<wgz> I think worrying would certainly be an overreaction :)
<berdario> lol, ok :)
<wgz> the wiki does look like it needs a little pruning
#bzr 2012-01-29
<eigentor> I am trying to understand how branching works in bazaar compared to git
<eigentor> I know git, but I don't know bazaar
<eigentor> I checked out a remote directory
<eigentor> So should I have got all branches on my local machine now?
<chromaticwt> is bzr an official gnu project, or canonical?
<chromaticwt> s/,//
 * SamB would tell chromaticwt that, inexplicably, bzr is an official GNU project
 * SamB reports a bug against bzr, knowing full well that it is actually a bug in zsh
<RenatoSilva> what bug SamBB
<RenatoSilva> SamB
<SamB> https://bugs.launchpad.net/bzr/+bug/923380
<ubot5`> Launchpad bug 923380 in Bazaar "zsh completions for "bzr help" miss non-command topics" [Undecided,New]
<bob2> eigentor, nope
<bob2> you can of course check out other branches if you like
<bob2> but the url you got refers to one branch
#bzr 2013-01-21
<jam> james_w: when you're around, I have some questions about lp:~james_w/charms/precise/tarmac
<vila> mgz: ping
<vila> mgz: I commented on bug #11011320 , can't reproduce unless I specify --no-plugins which... is expected since the lp: resolving is done by the launchpad plugin
<ubot5> Error: Launchpad bug 11011320 could not be found
<vila> yeah, bug #1101320 easy tyop to detect no ?
<ubot5> bug 1101320 in Bazaar "Using bzr config with --directory and --scope fails with lp: url " [Medium,Incomplete] https://launchpad.net/bugs/1101320
<vila> mgz: so my memory was to blame last time I said "Oh, this command doesn't resolve", it does resolve indeed
<mgz> hm, I'm reasonably sure I tested with 2.6b2, but what I have here right now is 2.5.1 apparent
<mgz> lyu
<fullermd> Shoot, we've all been working for years to find a programmatic way to correct your tpyos   :p
<jelmer> surely there aren't that many ways you can have typos in the word 'typos'
<vila> tyoppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp damn cat !
<fullermd> "Oh, look," says vila, "a challenge!"
<jelmer> you have trained your cat well, if he can get that close to spelling "typos"
<vila> virtual cats are very smart ;)
<vila> ...and don't let my daughters ever know I pretended to have a cat ;)
<mgz> vila: completely fresh quantal machine
<mgz> $ bzr version
<mgz> Bazaar (bzr) 2.6b2
<mgz> ...
<mgz> $ bzr config --scope=branch -d lp:bzr
<mgz> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/bzrlp:bzr/".
<fullermd> Finish fixing bug 1072513, and they won't hear it from me  ;p
<ubot5> bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513
<vila> bug #947049
<ubot5> bug 947049 in Fluidity "gmsh2triangle renumbering is broken" [Medium,Fix released] https://launchpad.net/bugs/947049
 * vila sighs
<vila> if you can't even trust doc/en/release-notes ...
<mgz> some people love mixing up bug numbers :)
<vila> bug #957049
<ubot5> bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Fix released] https://launchpad.net/bugs/957049
<vila> bingo !
<fullermd> It's probably just one of those weird ambiguities of en   ;p
<mgz> there we go, that's why I asked you the other day, I thought it rang a bell :)
<vila> spaking of bingo, Christoph Walz is even better in Djan unchained ;)
<vila> mgz: yeah, but neurons are a bit confused about which bugs were fixed...
<vila> *speaking
<vila> *Django (wich a slient D)
<vila> *silent
<vila> gee, I'm at my best...
<vila> fullermd: I know... but my fear is that this bug is gonna be a pain to fix :-/ And I've yet to find a couple of hours to confirm that...
<fullermd> Well, sure.  If it _wasn't_ going to be a pain, I'd have bugged someone else   ;p
<vila> hehe
<fullermd> I've discovered it's a self-reinforcing bug, though.  It's been there for _years_, and apparently nobody ever noticed when it bit them (or at least, didn't characterize and report it)
<vila> mgz: so, fix is in 2.5.2 and bzr.dev only
<fullermd> But I've had at least 2 incidents in just the couple months since I winnowed it out, where it's gotten in my way.
<vila> fullermd: urgh, so indeed, will be be a pain ;-/
<fullermd> So my theory is that it happens exponentially more often the more I talk about it.
<vila> ban fullermd with prejudice
<vila> rats, fail
<fullermd> Now I just need to get that bot finished...
<vila> mgz: time for 2.6b3 ? ;-D
<mgz> just trying to confirm the fix...
<vila> mgz: ooooh, there is a test for it ;)
<Stavros> hello
<Stavros> is bzr-git unmaintained?
<Stavros> jelmer: you wrote it, didn't you?
<jelmer> Stavros: yes, but I'm no longer working on it
<Stavros> oh, why not?
<jelmer> that doesn't necessarily mean it's dead, though I don't think there have been many other contributions since
<Stavros> hm
<jelmer> Stavros: moved on to other things
<Stavros> too bad, it's a very important plugin
<Stavros> it allows me to use bzr regardless of what others use :/
<Stavros> git's porcelain is driving me insane, bzr is the sanest dvcs i know
<jelmer> it's not going anywhere, the code is still there
<Stavros> jelmer: yeah, but i can't push because of the gpgsig bug
<Stavros> read: i can't use the work repo with bzr
<Stavros> that's too bad
<jdahlin> It seems that there are an issue related to renames in bzr fastimport, are there any good alternatives to fastimport when I'd like to export a bzr repository?
<LarstiQ> jdahlin: export in what sense? There is `bzr export`, but that doesn't sound like what you're after
#bzr 2013-01-22
<Stavros> hello
<Stavros> i'm trying to push to bitbucket with a git format, and bzr is acting as if i'm using --force
<Stavros> is there a way to stop that?
<dmemdfd> Hi all. I've got a main bazaar repo on a remote machine A and on another remote machine B I've got a clone of such repository.  Now I need to swap the roles, i.e. repo on machine B should become main one while that on machine A should become the clone. Is there any simple way to accomplish this? Do I have to edit config urls of bazaar only or have to do something else?
<xnox> dmemdfd: on machine A - $ bzr pull --remember url://hostB/path/to/repo
<xnox> done
<xnox> you may want to push tip from a to b first, to make sure b has everything.
<dmemdfd> xnox: thanks!
<dmemdfd> xnox: sorry (bazaar beginner!) now that I've made machine A "pointing" to machine B, how can I convert repo on machine B as main repo so that when I run update working tree is updated to latest revision (maybe empty url in bzr config) ?
<xnox> on remote hosts working tree does not auto-update
<xnox> either do $ bzr up on host B to "refresh it"
<xnox> or get rid of working tree on host B all together with $ bzr remove-tree
<xnox> or use http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<xnox> dmemdfd: ^^^^
<dmemdfd> xnox:thanks for your help!
<xnox> to remove pull reference on host b, you can edit .bzr/branch/branch.conf
<xnox> but it really doesn't matter =)
<xnox> it's all "distributed" anyway =)
<dmemdfd> actually typing bzr up, it tries to get commits from A (which is now supposed to be a clone of A) because B is still configured as a clone of A...do I have to erase branch.conf content at all?
<dmemdfd> (sorry...supposed to be a clone of B of course)
<xnox> yeah, it will. Yeah just remove parent url from branch.conf.
<vila> xnox: and he felt... before I could mention 'bzr config --remore parent_location' which avoids editing branch.conf
<xnox> vila: i totally did not know that trick =)
<jdahlin> hi, are there any alternatives to fast-export when exporting a bzr repository?
<vila> xnox: that's what you get for helping people ;-)
<xnox> jdahlin: exporting for what purpose? (e.g. one can simply push using bzr-svn / bzr-git / bzr-hg) and or use rewrite plugin etc.
<vila> jdahlin: fast-import from the other dvcs ?
<jdahlin> xnox: exporting a repository to git
<jdahlin> there are bugs/issues with bzr-fastimport that prevents me from using it (improper rename handling afaict)
<jdahlin> bzr: ERROR: Unable to update remote HEAD branch. To update the master branch, specify the URL git://localhost/Users/johan/bzr/repo-git,branch=master.
<jdahlin> that's what I get when using bzr dpush, any ideas?
<jdahlin> on the server side I get; [71689] error: Could not read e244837180c5c3761c7a16944ef5aa7eb8f56848 [71689] fatal: bad tree object e244837180c5c3761c7a16944ef5aa7eb8f56848
 * jdahlin looks at jelmer
<jelmer> hi jdahlin
<jelmer> jdahlin: you have to specify the branch to push to, that's why it's suggesting that URL
<jelmer> xnox: \o/ you have plans to work on bzr-git?
<xnox> jelmer: in my limited free time. but yeah. I will still via bugs/code review, but i'd like to be able to manage bugs at least =)
 * xnox has some local forks of bzr-git & dulwich......
<jelmer> I'd be keen to see the improvements to dulwich (there's also #dulwich, btw)
<jdahlin> jelmer: actually, I switched over to using a git remote helper, which is a lot faster (2-3 minutes instead of ~1h)
<Wiz_KeeD> hey guys!
<Wiz_KeeD> can anyone please tell me why this happens?
<Wiz_KeeD> http://pastie.org/5825338
<xnox> Hello =)
<xnox> Wiz_KeeD: not really bzr issue, but ubuntu. What's the output of $ apt-cache policy qbzr ?
 * xnox has qbzr installed fine on raring.
<Wiz_KeeD> http://pastie.org/5825430
<Wiz_KeeD> it's in the paste xnox
<xnox> ok. let me test that.
<Wiz_KeeD> could it be because of the mirror?
<xnox> Wiz_KeeD: dunno. almost finished creating precise install.
<Wiz_KeeD> okay
<xnox> Wiz_KeeD: works fine here. Please enable precise, precise-updates and precise-security repositories. apt-get update and try again.
<xnox> maybe there is something weird going on.
<xnox> Can you try "$ apt-cache policy python-qt4 " for me?
<Wiz_KeeD> yes
<Wiz_KeeD> my brother fixed it by using aptitude and downgrading
<Wiz_KeeD> but i want to find out more about this
<Wiz_KeeD> http://pastie.org/5825621
#bzr 2013-01-23
<chinoto> How do I uncommit, but maintain the state of the working tree?
<lifeless> bzr uncommit
<chinoto> well, I tried that, but "bzr st" isn't showing them
<chinoto> ...ok what the heck?!?
<chinoto> I just tried it again and it all of a sudden worked as expected >.<
<chinoto> lifeless: that was weird... thanks
<lifeless> np:)
<chinoto> how do I un-add a file?
<chinoto> without deleting it
<LeoNerd> bzr rm --keep
<chinoto> ah, I was trying to use revert
<LeoNerd> revert undoes editing a file
<chinoto> I figured it might undo the added state as well :D
<lifeless> it does
<lifeless> bzr revert added-file will unadd it
<lifeless> or it used to; may have been changed
<chinoto> and remove it from the filesystem
<lifeless> it didn't use to have that behaviour
<chinoto> perhaps our version is flaky/old
<lifeless> i'm slowly getting more and more out of date ;)
<lifeless> chinoto: no, more likely my info is less current
<lifeless> I haven't tracked the commit feed for a few years now
<chinoto> well, that was messy
<jml> I got this error when trying lp-propose from my Mac: bzr: ERROR: [Errno 185090050] _ssl.c:340: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
<atc3030> atc3030@atc3030-buildserver:~/android/cm-10.1_optimized/projects/gcc-linaro$ bzr branch lp:gcc-linaro/4.7
<atc3030> You have not informed bzr of your Launchpad ID, and you must do this to
<atc3030> write to Launchpad or access private data.  See "bzr help launchpad-login".
<atc3030> Segmentation fault (core dumped)/81258
<atc3030> atc3030@atc3030-buildserver:~/android/cm-10.1_optimized/projects/gcc-linaro$
<atc3030> How can I fix/get around this?
#bzr 2013-01-24
<LeoNerd> Easiest way (in a shell script) to obtain the branch path for a lightweight checkout?
<fullermd> Probably something under 'config' to spit it out?
<mgz> config doesn't seem to know, but info has what I guess you want, just not in a simple form
<LeoNerd> Yah; I know I could use  bzr info | sed -n s/...../p
<LeoNerd> but that's a bit icky
<mgz> not seeing a nicer way unfortunately
<mgz> well, you could poke internals
<mgz> cat .bzr/branch/location should be reasonably safe
<LeoNerd> Oh, that looks good enough
<LeoNerd> It's just a script wrapper of mine.. I just want to check if it is "TRUNK" for sanity purposes, and bail out if not. So that sohuld be fine
<LeoNerd> grep /TRUNK `bzr root`/.bzr/branch/location >/dev/null || ....
#bzr 2013-01-25
<mgz> morning!
<jelmer> sup mgz!
<mgz> hey jelmer!
<mgz> ...there were two verification-needed bugs for the oneiric sru? annoyance...
#bzr 2013-01-26
<muep> I got myself a copy of a project with bzr co and made some changes to it which I would like to send back upstream. In case I do not wish to create a new public repository, what would be the most appropriate way to get a patch file that I could send?
<muep> just running bzr diff produces at least a plain patch, but is there anything which'd maybe let me commit my work first and then send patches with commit messages and other metadata?
#bzr 2013-01-27
<lifeless> muep: you can use bzr bundle to create a rich patch
<muep> lifeless: thanks, I'll read about that
#bzr 2014-01-20
<mgrandi> is there any workaround atm for bzr throwing a bit that libsvn is different then what it expects?
<mgrandi> on mac os x
<jelmer> mgrandi: uninstall bzr-svn
<mgrandi> hmm, this is on a mac so it came preinstalled, do i just delete some file in the plugins directory?
<jelmer> mgrandi: yeah, remove the 'svn' directory from 'plugins'
<mgrandi> it was also throwing a fit over subvertpy
<mgrandi> so i removed tht
<mgrandi> "bzr: ERROR: No module named subvertpy"
<mgrandi> why is it requiring svn? its just a plain bzr repo..
<mgrandi> found it, its because it was also installed to .bazaar/plugins as well as /Library/Python/2.6/site-packages/bzrlib/plugins >.>
#bzr 2014-01-21
<__marco> can I grep a file to search exactly when something was removed?
<__marco> something like: bzr grep -r branch:../branch1.../ line removed
<__marco> I know that the -r syntax is wrong but I don't know also how to specify the versions between two branches
<fullermd> Never messed with grep.  I always just did a log -p and then searched in less.
<rozzin> Hm. I was thinking maybe "bzr log -r annotate:..." might have been able to do that.
<rozzin> Doesn't look like it, though.
<fullermd> Would be hard to describe something removed like that, I'd think.
<fullermd> Plus the issue with overspreading diffs, etc.  I always looked a little crosseyed at annotate:.
<SamB> yeah, afaik "git blame" can't tell you "something was deleted here since the surrounding lines changed", either. (It'd be kind of nice if it could.)
<mgrandi> i haven't evern seen that in a 'blame' command, cause the entire file could be 'deletions'....
<mgrandi> i thought it was more for just 'who put this line here' sort of thing
<fullermd> Defining or declaring or asking about things going away seems harder all around than things coming in.  I'll bet there are philosophical resolutions if somebody wanted to take enough time to hash it all through.
<fullermd> Not sure about making it practical though.
<mgrandi> it seems like it would be a separate command, it would be so much data to see all at once seeing deletions and regular 'blames' all at once
<fullermd> An interesting ontological exercise though, I imagine.
<rozzin> Sure enough "bzr revert -r$REV_WITH_LINE; bzr log -r annotate:..." does tell me that the line in question "does not exist in branch"....
#bzr 2014-01-23
<Wiz-KeeD> hey guys
<Wiz-KeeD> anyone around
<Wiz-KeeD> ?
<Wiz-KeeD> hello jam
<Wiz-KeeD> Can someone please tell me, when I make a push to a branch and it makes some automated merges leaving messages inside the actual files
<Wiz-KeeD> How do I detect those in the branch? it's messing up my code and I want to resolve it
<jam> Wiz-KeeD: we don't ever "automated merge" when doing push. Do you mean during "bzr merge" ? Or "bzr pull" ?
<bob2> you shouldn't push to things with working copies
<jam> generally, you use "bzr status"
<Wiz-KeeD> bob2, i shouldn't?
<jam> hmmm.. maybe we do with local push, that was a special case
<Wiz-KeeD> That's how I deploy my code to the server
<bob2> it in fact refuses by default
<bob2> Wiz-KeeD, that's a terrible idea
<Wiz-KeeD> bob2 how so? what would be your suggestion?
<Wiz-KeeD> to transfer the local code to the server
<bob2> because of the above
<Wiz-KeeD> i just use bzr push-and-update
<Wiz-KeeD> that's it
<bob2> also the fact that you /edited things on the server/
<bob2> then pushed upon it
<Wiz-KeeD> hmm I might have done that but did revert --no-backup
<Wiz-KeeD> Then what would be the ideal solution?
<bob2> let me guess
<bob2> php?
<Wiz-KeeD> wrong guess :))
<Wiz-KeeD> python
<bob2> deploying python via this method is absurd
<bob2> since you're missing the './bin/python setup.py develop' or './bin/pip install -e .' step
<Wiz-KeeD> I don't understand
<Wiz-KeeD> I deploy personal code to a server regarding modules of a framework that get loaded by that framework on the server
<Wiz-KeeD> And any changes I make and test locally I will eventually have to push onto the server for production
<Wiz-KeeD> Might not be the best method but I don't see how that is absurd really, maybe I'm missing something
<achiang> hello. i have a large branch that i do not want to re-clone from launchpad. i made changes in this branch and pushed them to LP, then submitted a merge, and it was approved
<achiang> now, i want to start from a pristine trunk, and do a bzr merge from lp:~achiang/project/proposed-branch
<achiang> and then push the merged trunk to lp:project
<achiang> is there a way to get back to "trunk" using my local, modified branch?
<fullermd> Was it branched off trunk in the first place?
<achiang> yes
<fullermd> Try pull.
<achiang> ?
<achiang> so bzr pull lp:project ?
<achiang> inside the modified branch?
<fullermd> Just bzr pull should be enough.
<achiang> i get "no revisions or tags to pull"
<fullermd> See what bzr missing lp:project has to say.
<achiang> simply says that my local branch has 5 extra revisions, but trunk has not changed since i last cloned/pulled
<fullermd> Mmm.  OK, let me check this then.
<fullermd> You branched lp:project, then made 5 commits on top of it.  Pushed them to lp:~achiang[...].
<achiang> i suppose i could just push to lp:project, but something weird in me wants to ensure that trunk gets a merge commit...
<fullermd> Now you want to take a prisine lp:project, merge lp:~achiang[...] into it, commit the merge, then push that?
<achiang> fullermd: yes you understand correctly. is that weird for me to want?
<fullermd> Eh.  Not particularly.  6.5 of one, half a baker's dozen of the other.
<achiang> in git, it would resolve to the same thing anyway... what they call a fast forward merge (or whatever)
<fullermd> The q&d answer is probably do to a pull --overwrite to force your local branch back to pure trunk, then do the merge/ci/push.
<achiang> but i guess i'm used to seeing merge commit in bzr workflows
<achiang> oh, nice. i'll do the --overwrite
<fullermd> Naturally.  'cuz bzr may have smoked whatever git was on, but it didn't inhale   ;p
<achiang> ugh, that screwed up my tree
<achiang> because i had stuff in a subdirectory that wasn't tracked by bzr
<fullermd> If it's gonna be a long-term repeated action, better solution would be to setup a local shared repo and keep one branch as pristine trunk, using additional locals for the work branches.
<achiang> yah. that's what i'm about to do
<fullermd> Precious stuff?
<fullermd> If not, you can just do some rm and/or revert dancing.
<achiang> i'm recovered now... rm -rf subdir/ ; bzr revert ; bzr status => clean :)
<fullermd> I said it first!  That means I still get the credit!
<achiang> i can show you my bash history timestamped to an ntp-synced machine :P
 * achiang now does cd .. ; mv local trunk ; bzr branch trunk local
<achiang> fullermd: thanks for the help, much appreciated
<fullermd> I'd setup the repo first, to save all the I/O on your poor disk.
<achiang> it was ok. only took a few seconds for the local branch
<fullermd> I blame the TAI/UTC offset for that vile attempt to snake the credit away from me.  Durn leap seconds.
<achiang> the reason the branch is huge is because of media files in the tree
<achiang> i guess that was fast enough to clone locally
<achiang> that, plus PCIe SSD
<fullermd> Well, it's doubling the repo space used.
<fullermd> (since it's now storing the whole history twice)
<achiang> oh, i see
<fullermd> One shared repo will stop that.  Plus make any future "branch lp:project/whatever"'s way faster, since they'd only need to grab revs you don't already have.
<achiang> got it
<fullermd> init-repo to set it up, then reconfigure --use-shared in the branches to switch them over to using it.
#bzr 2014-01-26
<zaratustra> hey, how would I acquire bazaar 2.6b2 for windows? only 2.6b1 is linked
<zaratustra> yeah, thanks for nothing.
<Peng> np
#bzr 2015-01-19
<ychaouche> Hello
<ychaouche> If I checkout a branch from launchpad then commit to it, it will commit to launchpad right ? (bzr checkout)
<ychaouche> No need to push ?
#bzr 2015-01-21
<jjjj> Anybody awake?
#bzr 2015-01-22
<blahdeblah> Hi. Is there a way to do partial commits a-la "git commit -p"?  The best I've been able to find so far is to "bzr shelve" the bits I don't want, selectively keep the bits I want to commit, commit them, then unshelve, rinse, and repeat, which is a bit tedious; "bzr shelve" also doesn't allow splitting of diffs like "git add -p" does.  Any better ideas?
<riderirc> anybody awake?
<mgrandi> mmhmm
<riderirc> Does anyone actually respond to bugs reported on launchpad?
<LeoNerd> About 70% of the planet, most likely
<riderirc> I have a rather severe problem (bzr check crashes), and nobody's responded to a bug posted in the beginning of December 2014.
<mgrandi> link to the bug report
<mgrandi> plz
<riderirc> https://bugs.launchpad.net/bzr/+bug/1399773
<ubot5> Launchpad bug 1399773 in Bazaar "'bzr check' crashing" [Undecided,New]
<riderirc> It's like fsck crashing - shouldn't happen, and you're screwed when it does...  :-)
<mgrandi> hmm
<mgrandi> yeah, i think thats exactly the case
<mgrandi> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///root/ww/.bzr/repository/') has no revision username@domain.com-20120314181329-cpt4dhp0ou1b66k2
<riderirc> I need to some way to make the repo consistent (and usable) again, even if I lose certain revisions
<mgrandi> So its obviously missing a revision and ....therefore fails the check
<riderirc> but I don't want to discard the entire revision history
<mgrandi> do you have any other copies of the repo?
<riderirc> unfortunately, no.
<mgrandi> and that username is weird...username@domain.com ? lol
<riderirc> I replaced my actual email addr with that placeholder.
<mgrandi> ah
<mgrandi> if you check in the /root/ww/.bzr/ folder, do you have a 'obsolete packs'?
<mgrandi> folder
<riderirc> I was beginning to wonder if bzr devel had just gone completely dead...
<riderirc> let me check
<mgrandi> canonical seems to of shifted...to other things at the moment
<mgrandi> but bzr is more or less in a good state, software can always be improved, etcetc
<riderirc> I've been resisting switching to git, but you know, this kind of thing makes me question my choice.
<mgrandi> lol, git has this problem to
<riderirc> yeah, but honestly it's still pretty buggy...
<riderirc> for sure, but the git dev team is pretty quick to respond
<mgrandi> read about how KDE almost lost _all_ of their git repos cause git does 'mirrors' without checking pack files?
<mgrandi> yeah, git does have the benefit of the entire kernel team behind it pretty much
<riderirc> thus its primary attraction, I think...
<riderirc>  /root/ww/.bzr/repository/obsolete_packs/ has 61 files in it
<mgrandi> well the thing is bzr is telling you whats wrong, it cant find the revision, so it doesn't know what else to do, other then magic
<mgrandi> i wonder if that revision is in there, one sec
<mgrandi> jelmer: do you know of a way to make bzr look in obsolete_packs for missing revisions to fix a repo?
<mgrandi> I have been messing around with the bzr pack format but i dont have anything yet that can just 'insert' a revision in the right spot
<mgrandi> let me find my script that lists the revisions at least
<riderirc> cool
<mgrandi> git loves its simplicity and the revisions are just text files haha
<riderirc> btw I appreciate your help; I've been checking in here regularly for weeks but nobody's generally awake  :-)
<mgrandi> yeah, they are all eurofolk
<fullermd> You could setup a strawman copy of the repo with the "obsolete" packs in the main location.
<mgrandi> im not a core developer but i like bazaar so i hang out here when i can
<mgrandi> the mailing list would probably be better too, since a lot of people get that, even if they are not on irc all the time (like me lol)
<riderirc> FWIW: here's the pack layout: http://pastebin.com/75QbcHWz
<riderirc> .{r,s,t,c,i}ix files omitted from the obsolete listing.
<mgrandi> well, here is my script that i had, i modified it so it can work on * files
<mgrandi> http://paste.pound-python.org/show/t1ARpUd5Ks4ZOmx61zHn/
<mgrandi> try calling it like "python2.7 print_out_index_keys.py <REPO_FOLDER>/.bzr/repository/obsolete_packs/*.rix
<mgrandi> and then search that file for the revision that bazaar says its missing in your bug report
<mgrandi> with the filled in email =P
<mgrandi> if you find it in there then hopefully its in one of the .pack files in obsolete_packs
<riderirc> I ran it, but I'm going to have to have a quick look at the script as it crashed...
<riderirc>   File "print_out_index_keys.py", line 56, in printOutIndexKeys
<riderirc>     print("noderef: {}, keyelements: {}, len: {}, rowlength: {}".format(noderef_val, keyelements_val, len_val, rowlength_val))
<riderirc> ValueError: zero length field name in format
<mgrandi> lol guess python2.6 doesn't like the {}
<mgrandi> http://paste.pound-python.org/show/TgvP4QYTQ0l0xuhAHemj/
<mgrandi> try that maybe
<mgrandi> just added indexes to make it happy
<riderirc> yeah, I actually don't use "".format() in 2.x, rather I use ""%(tuple,)  :-)
<mgrandi> yeahh, im a python 3 guy
<riderirc> I suppose I really should change one of these days...  too many of the 2-3 changes seem pedantic rather than reality based though
<riderirc> it annoys me, so I stick with 2.x
<fullermd> They all seem nuts to me, so I stick with 5.x  ;p
<riderirc> anyway, I gave field numbers to each {} for format and it happily spit out data.  I'm going to check for the missing revisionu
<riderirc> if the revision is in the pack file, how the heck can it be 'missing' unless it's a bzr bug that failed to actually put it in there?
<riderirc> it's not as if someone rm'ed a discrete file.
<fullermd> bzr doesn't look at obsolete_packs
<fullermd> Could happen via FS corruption, as one offhand guess.  A bit flip somewhere could make it seem like a different id.
<mgrandi> yeah
<fullermd> I'd expect internal checks to notice that; you could just check the md5's of the pack files.
<mgrandi> It _should_ look in obsolete_packs
<riderirc> at any rate, the output from your script doesn't appear to include the missing rev.  (your_script > output_file ; grep 20120328004955 output_file)
<fullermd> But if it happened in memory, it wouldn't be found at that level.
<fullermd> (of course, that couldn't happen, or you'd have gotten an ECC error message.  Right?)
<riderirc> there's nothing from the year 2012 showing up at all in the output
<mgrandi> how new is that revision
<riderirc> fuller: one would hope
<mgrandi> hmm..2012..
<mgrandi> so there have been commits since then? like a decent number?
<riderirc> and the issue just showed up recently
<riderirc> probably not a gigantic number
<mgrandi> cause stuff gets put into obsolete_packs after bzr runs a 'pack', but if you commited something, and it gets lost before it repacks, then there is no 'backup' in obsolete_packs
<mgrandi> and did you make sure to run it against *.rix ? aka the astrik
<mgrandi> not just one .rix file
<riderirc> yes, it # grep checking.file rixcheck  | wc -l
<riderirc> 11
<riderirc> it checked 11 of them
<mgrandi> so what are the dates in the backup files? like 2014/2015?
<mgrandi> that the output gives you
<riderirc> so what actual gets put in the obsolete packs anyway (when bzr pack is run) ?
<mgrandi> its sort like git, when you commit stuff they get placed in different packs, and information about them (rix, six, tix, etc)
<mgrandi> when you repack, it consolidates all the different ones  in 'repository', and places them all into one, and moves the old ones back into obsolete_packs
<riderirc> 38 revisions, ranging from 20130118054022 to 20141223012333
<mgrandi> sorta how git does it. git has basically a 'file' for every commit, but it can also repack them into one giant file so it doesn't have to search 8000 files to find the right thing
<riderirc> ( grep @ rixcheck  | awk -F- '{print $2}'|sort )
<mgrandi> so im confused on how you have commits from 2013 but nothing earlier in the backup? is this imported from svn or something?
<mgrandi> dunno how that revision is just not there
<riderirc> no, it's been bzr since day 0
<riderirc> hmm, let me check something
<blahdeblah> Repeating yesterday's question: Is there a way to do partial commits a-la "git commit -p"?  The best I've been able to find so far is to "bzr shelve" the bits I don't want, selectively keep the bits I want to commit, commit them, then unshelve, rinse, and repeat, which is a bit tedious; "bzr shelve" also doesn't allow splitting of diffs like "git add -p" does.  Any better ideas?
<mgrandi> you can always try cding into the directory where the repo is (normally), and run 'bzr revision-history'
<mgrandi> that prints out just revision ids, does that print out the 2012 date?
<mgrandi> I think git shelve is the only thing, its a bit easier with the GUI version of shelve (qshelve)
<mgrandi> err bzr shelve
<blahdeblah> mgrandi: OK - thanks
<riderirc> aha!
<fullermd> Somebody once wrote a 'record' plugin, mirroring darcs record, which allows similar things.
<riderirc> looks like someone pivoted out the old directory...
<fullermd> (darcs records does, I mean; I don't know for sure whether the bzr record did, but I assume so, since that's kinda the point)
<riderirc> python print_out_index_keys.py /root/oldww/ww/.bzr/repository/obsolete_packs/*.rix > rixcheck-old
<riderirc> bijngo
<riderirc> bingo
<fullermd> I suspect it's lost in the mists of time and compatibility by now, though.
<mgrandi> wait, so someone copied the repo to another folder?
<riderirc> looks like they pivoted the /root/ww directory out
<mgrandi> (and git -p is basically doing a magical shelve -> unshelve thing after commit anyway behind the scenes)
<riderirc> that's what happens when you let monkeys in the kitchen
<mgrandi> so does that repo work?
<mgrandi> as in bzr check doesn't complain? =P
<mgrandi> cause i can't find an easy way to insert that revision into the pack file, bzrlib is big =P
<riderirc> hmmm
<riderirc> bzr: ERROR: No WorkingTree exists for "file:///root/oldww/ww/.bzr/checkout/".
<riderirc> so, it's rather messed up looking
<mgrandi> think you can just run 'bzr checkout'
<mgrandi> it has the history but no actual checkout
<fullermd> If you can get it working in another branch, you could just pull both into the same repository.  Or possibly use 'reconcile'.
<mgrandi> unrelated: commit.Commit().commit()
<mgrandi> lolol
<riderirc> but it's not a branch, so I can't perform a checkout
<riderirc> it's evidently a repository
<mgrandi> well create a directory, run 'bzr branch <repo_folder>'
<fullermd> Can't branch a repo.
<fullermd> But you can 'init' an empty branch in it, and then 'pull' a revid you know is in the repo into it.  Creepy, but valid.
<mgrandi> wait so its just a repo with no branches in it?
<riderirc> yes, some bozo evidently moved out the .bzr repository directory
<fullermd> Even betterer and creepier, you might could 'branch' the b0rked branch into that repo, and assuming it has all the revs the b0rked one is missing, it would cleanly pull in all the new ones, and leave you with a full history.
<riderirc> the worst thing is that there are some large files that were checked in, so bzr check takes ages to run.  I'll fiddle with it a little bit.   At least I have a better idea of what's going on.
<riderirc> Are you guys on regularly?
<fullermd> On?  Pretty much always.  Responsive?  That varies a lot...
<mgrandi> wait cna you not list the branches that are in a repo if it has no active branches?
<fullermd> ML might be a better option, especially with stuff like this that has a lot of state to communicate.
<fullermd> List branches with no branches?  Stop smoking coffee grounds   ;p
<fullermd> You can list heads, anyway.
<mgrandi> yeah
<mgrandi> run 'bzr heads --all'
<riderirc> I may be back with another question about a damaged branch that 'bzr split' exploded
<mgrandi> that lists all the heads, and then you can branch one of those right?
<fullermd> Not sure.  You can certainly init an empty branch and pull it.  Dunno whether you can branch it from an empty.
<riderirc> there is no bzr heads unless that's a plugin
<fullermd> It's in bzrtools
<riderirc> that sounds familiar
<mgrandi> might be a separate package, but its included in every install i've done
<mgrandi> but yeah, you can create a folder, 'bzr init .' to init an empty branch, then 'bzr pull -r <REVISION_ID>' and it will basically recreate the branch
<mgrandi> and you get revision_id from 'bzr heads --all', cause it wont list dead branches by default
<mgrandi> and then once you do fix it, be sure to 'bzr branch' it to somewhere else so this doesn't happen again lol
<riderirc> bzr heads is doing something; we'll see what it spits out.
<riderirc> well, it's too slow; I'll check on it tomorrow morning.
<riderirc> Thanks again for the help...
<mgrandi> ok, good luck, post on the ML if you have more questions
#bzr 2015-01-24
<mr_george> My company server is doing maintanance, and I have a very large repository and don't want to keep the whole thing. Is there any easy way to create an archive of the last 10 revisions that can be quickly pushed onto the main repo later?
<Peng> You might be looking for "bzr bundle".
<mr_george> Peng: that looks right, Thanks, I'm reading the docs now...
#bzr 2016-01-26
<DrZ> Hi everyone. I'm trying to start using my Bazaar again.
<DrZ> I think Ive an issue with ssh because I got this error
<DrZ> Transport operation not possible: http does not support mkdir()
<DrZ> So I generated a new SSH key
<DrZ> uploaded to launchpad.net the public part
<DrZ> I still get the error
<DrZ> Is this all im missing ?  IdentityFile  /home/me/.ssh/id_rsa_launchpad
<DrZ> Seems to make no difference
<Peng> DrZ: bzr help launchpad-login
<Peng> DrZ: If you haven't configured your LP username, "lp:" URIs will use HTTP, not SSH.
<DrZ> So this was outputted
<DrZ> Setting ssh/sftp usernames for launchpad.net.
<DrZ> Still same error when I try commit
<DrZ> I don't get it
<DrZ> I configured my name earlier
<fullermd> You'll have to change the push (or maybe bound, by your ref to commit) location of the branch to the writable transport.
<Peng> "bzr info" on the branch?
<Peng> ^
<DrZ> So I ran bzr info and I got a popup for my SSH password. Entered that.
<DrZ> Seems to return the repo info now
<DrZ> Added to list of known hosts
<DrZ> Same error though when I try commit
<DrZ> I havent used the repo in a long while. Would that cause any issues?
<fullermd> You still need to change the saved locations.  Doing a lp-login doesn't change what's in existing branches.  See the info output.
<DrZ> Do I put something into locations.conf in the .bazaar folder ?
<DrZ> Location:
<DrZ> shared repository: bzr+ssh://bazaar.launchpad.net/+branch/photofiltre-lx/
<DrZ> repository branch: bzr+ssh://bazaar.launchpad.net/+branch/photofiltre-lx/
<DrZ> I ran this - bzr info lp:photofiltre-lx
<Peng> Run "bzr info" with no arguments in your *local* copy of the thing.
<Peng> (or run "bzr info path/to/your/local/thing"
<DrZ> Ohhhhh XD
<DrZ> Sry completely misunderstood.
<Peng> See, this is the problem with DVCSes. I say "The Branch" and it's ambiguous what i mean. ;P
<DrZ> Hehe :)
<Peng> If we all used Subversion... :D
<DrZ> checkout of branch: http://bazaar.launchpad.net/~photofiltrelx/photofiltre-lx/main/
<DrZ> That is the location output
<DrZ> Eww, Subversion just reminds me of every coding job I've had thus far. :D
<DrZ> Companies love SVN o_O
<fullermd> Not all companies.  Some love VSS.
<Peng> Perfoooooooorce
<fullermd> To say nothing of Clearcase...
<Peng> The way to change the checkout to bzr+ssh is with 'bzr reconfigure --bind-to lp:~photofiltrelx/photofiltre-lx/main' I think?
<fullermd> I was gonna say just 'bzr bind lp:photofiltre-lx'
<Peng> ah
<fullermd> (assuming that's the lp:whatever you originaly co'd it with)
<fullermd> Maybe bind doesn't just reset by itself?
<Peng> Or get out a text editor and go digging in .bzr/checkout ;D
<Peng> fullermd: I dunno
<fullermd> It'd be in .bzr/branch   :p
<fullermd> Well, if it doesn't, you can just unbind and then bind lp:foo I guess.
<DrZ> Hum.. Will I try the bind command?
<DrZ> SweeEEEeeeEEeeeEEEeeeTTTTT!!! xD
<DrZ> Why didn't ye just say that in the first place ;) :D
<DrZ> Thanks guys!
<DrZ> Commit went though
<DrZ> Anyone have experience with Git import into Bazaar?
<fullermd> Not really.  I'd guess the fast-import route would be the best bet?
<DrZ> Cool. Thanks!
#bzr 2016-01-31
<colonolGron> hello
<colonolGron> i am not too familiar with bazaar yet. i have once contributed to a project ( https://code.launchpad.net/~g-bluehut/ubuntu-terminal-app/whitespacefix/+merge/228807 ) now i did an `bzr branch https://launchpad.net/ubuntu-terminal-app` and then a `bzr log|grep bluehut' but it seems like my change cant be found like this? although on the webpage it seems to be merged?
#bzr 2018-01-22
<LeoNerd> marioxcc: No. I usually do that by creating new sibling directories with  .BRANCHNAME  suffixed on their names
<LeoNerd> You can easily create one with e.g.  bzr push ../This-Thing.BRANCH
<marioxcc> LeoNerd: Ok.
<marioxcc> LeoNerd: In the time before you reply I found a âbzr-colâ for âco-locatedâ branches. This seems to be what I want, except that it seems to be dead (last release is from 2012 I think).
<marioxcc> Are you aware of something like it?
<LeoNerd> Nope. Though I don't really use anything like that
<LeoNerd> I prefer to have different working trees, because I tend to have lots of derived tempories (i,e. compiled code and the like), so I like to keep them in different places too
<marioxcc> LeoNerd: Ok, thanks.
<Walex> marioxcc: LeoNerd: checkouts can approximate that, as in http://doc.bazaar.canonical.com/bzr.2.7/en/user-reference/checkouts-help.html
<Walex> there is: "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch."
<jelmer> LeoNerd: colocated branches in the git/mercurial style are supported by default in bzr >= 2.5, but the syntax for addressing them is still a bit annoying ("file://blah,branch=foo")
#bzr 2018-01-23
<LeoNerd> Ah. hmm
<LeoNerd> I didn't know those :) OK
#bzr 2018-01-24
<jelmer> Walex: those links are to localhost :)
#bzr 2018-01-27
<Walex> jelmer: oops.... http://www.sabi.co.uk/blog/drafts2.html?110817#110817 http://www.sabi.co.uk/blog/18-one.html?180106#180106
