[00:05] <alperkanat> hey there.. i want to migrate to bazaar from svn... but i can't import the code to a new bzr repository.. can someone please help me ?
[00:10] <alperkanat> any help for bzr-svn ?
[00:10] <alperkanat> it always keep looking for .bzr directory inside the subversion repository
[00:12] <cody-somerville> You can easily import from svn into bzr using launchpad
[00:14] <Pieter> .. is there a performance regression in 'bzr blame' from 1.5 to 1.7?
[00:19] <Pieter> anyway, http://pastie.org/280554
[00:21] <lifeless> Pieter: there could be; 1.6 made some significant refactoring of deepguts
[00:21] <Pieter> pretty serious difference, 8x slowdown
[00:21] <lifeless> Pieter: tried to keep everything balanced; may not have completely succeeded
[00:22] <lifeless> Pieter: oh, no, thats less likely
[00:22] <lifeless> Pieter: big project, deep history ?
[00:22] <Pieter> yes, samba
[00:23] <lifeless> wheee that sucks
[00:24] <lifeless> if you could file a bug, that would be great; I'm in the middle  of some social stuff atm
[00:24] <Pieter> let me try
[00:24] <Pieter> i'm not too fond of bug trackers :)
[00:25] <lifeless> you might like to try the btree based repo format (--development2) just landing in bzr.dev right now
[00:28] <Pieter> (bug 275303)
[00:29] <lifeless> Pieter: thank you
[00:36] <lifeless> Pieter: so the index that the current pack-* formats use is bisection-searched
[00:36] <lifeless> Pieter: and this due to a number of things isn't very good, even though its better than the pre-pack formats
[00:37] <lifeless> Pieter: the --development2 format, replaces the index layer with a B+Tree; and that is quite possibly going to be the thing that suddenly chews up huge amounts of time
[00:37] <lifeless> erm, fix the thing that chews up time
[00:37] <lifeless> (because, during 1.6/1.7 some heuristics were added that can cause a full index read (think table scan) unnecessarily, because its faster in some cases
[00:39] <Pieter> hmm, ok
[00:39] <Pieter> I'm not going to run a -dev version though ;) I'll wait a bit
[00:39] <lifeless> its landed I think, just checking the merge result
[00:40] <lifeless> sure; not expecting you to run one, just noting that you could give it a spin and see :P
[00:40] <lifeless> yes, its landed
[00:41] <bb-bzr> does anyone have a minute to answer some nubi questions with using bzr?
[00:43] <lifeless> sorry, just popping away
[00:43] <lifeless> ciao guys
[00:55] <bb-bzr> I had a question about branches in general... if I have a mirror branch that has recently pulled in changes from some feature branch foo; at which point foo will no longer be used, is there a reason that I shouldn't just remove the whole foo branch from the disk?
[01:16] <alecwh> ﻿Hello, I downloaded the package "bzr-gtk", and I don't see anything changed in the Nautilus File Browser. What am I supposed to see? I'm on Ubuntu Hardy.
[01:29] <spiv> bb-bzr: usually no important reason
[01:29] <bb-bzr> so there won't be any orphaned data in a repository if i nix a branch?
[01:29] <spiv> bb-bzr: as you can see with e.g. "bzr viz" all the revision data from foo is present in the mirror branch.
[01:30] <bb-bzr> yah I see that using qlog
[01:30] <bb-bzr> or viz
[01:30] <bb-bzr> so i guess if there is some case where a diverging set of branches would resolve down to a feature branch would be the only case where it would become an issue and in that case I could just figure something else out?
[01:31] <spiv> bb-bzr: so usually the only reason to keep the foo branch around on disk is if you want a convenient way to refer to those revisions later
[01:31] <bb-bzr> ahh
[01:31] <bb-bzr> i usually work on a defect or feature on its own branch, so have lots of branches that have short lifetimes
[01:32] <bb-bzr> I am used to just killing them once merged, but wanted to make sure this wouldn't be an issue in bazaar
[01:32] <spiv> Yeah, just remove them in that case.  That's what I do.
[01:32] <spiv> alecwh: I don't think the nautilus extension is enabled by default
[01:33] <alecwh> what would I see then? I don't notice any differences
[01:33] <bb-bzr> spriv: thanks much man, busy setting up bazaar for my company and writing a developers guide and wanted to make sure I was not recommending something goofy
[01:34] <spiv> alecwh: also, /usr/share/doc/bzr-gtk/README.Debian for the hardy version of bzr-gtk says that it isn't even packaged in that version.
[01:34] <spiv> alecwh: IIRC it adds emblems to versioned files & directories.
[01:34] <spiv> alecwh: http://bazaar-vcs.org/bzr-gtk links to some screenshots
[01:34] <alecwh> that's... it? and can I easily add support?
[01:36] <spiv> alecwh: the README that comes with bzr-gtk explains how you can enable the nautilus integration (although obviously not with the hardy packaging of it)
[01:37] <spiv> alecwh: in addition to emblems, I believe it adds options to the right-click context menus, e.g. "View Changes..."
[01:40] <spiv> alecwh: note that a lot of what bzr-gtk provides is accessible without nautilus, type "bzr help gtk"
[01:51] <alecwh> spiv: thanks a lot!
[02:29] <Odd_Bloke> http://amix.dk/blog/viewEntry/19350 looks interesting.
[02:30] <Odd_Bloke> Unfortunately, I'm using a LiveCD ATM, so can't really play with a bzr convertor.
[06:13] <chandlerc> jelmer: i have an odd crash report
[06:14] <chandlerc> but i can't really file a bug, because it fixed itself
[06:14] <chandlerc> and i am happilly using bzr-svn better now than ever before
[06:14] <AfC> "Self healing systems"
[06:14] <chandlerc> but in case someone else runs into it, I was using neon compiled against OpenSSL, and getting segfaults (with no python backtrace or anything) while pushing to a repository
[06:15] <chandlerc> another machine wasn't despite the same bzr, bzr-svn, and repository
[06:15] <chandlerc> the other machine was using gnutls, so i recompiled neon against it here, and everything works
[09:19] <_J_m_D_> any insights on bzr vs svn?
[09:21] <_doomster_> _J_m_D_: in what context?
[09:24] <_J_m_D_> looking for a general versioning system - not only for code but for all kinds of files. Will be used for online colaboration
[09:25] <_J_m_D_> many heavy files (3D-graphics) will be used
[09:28] <_doomster_> how about the intended users? BZR makes it easier to do detached development of private branches, with SVN you can also create and maintain branches, but you need to maintain them in the same repository, i.e. give everyone access.
[09:30] <_J_m_D_> I like the concept of bzr in that respect. Seems like each team member can do his own "local development" and synchronize to the central repository only "when needed". Is that correct?
[09:30] <_doomster_> right.
[09:30] <_J_m_D_> (I am a version vontrol noob)
[09:31] <_J_m_D_> at the moment IDE integration is not a big issue. But file browser integration (shell integration) for windows would be nice - like tortoise for svn.
[09:31] <_doomster_> tsvn is damn sweet, true.
[09:32] <_J_m_D_> anlything similar available for bzr?
[09:32] <_J_m_D_> anything*
[09:32] <_doomster_> not that I was aware of, but I'm a bzr noob myself. I'm an svn veteran though.
[09:32] <luks> http://bazaar-vcs.org/TortoiseBzr
[09:32] <luks> but obviously not as mature as tortoisesvn
[09:33] <_doomster_> :)
[09:33] <_J_m_D_> mmm, seems very nice
[09:34] <_J_m_D_> doomster - so what is your impression so far with bzr compaired to svn?
[09:35] <doomster> I'd rather not make a statement, because I really haven't used it enough.
[09:37] <_J_m_D_> is anyone aware of some issue that makes bzr inferior to svn?
[09:37] <doomster> As far as SVN is concerned, it is a very simple too without too many bells and wistles, but it is solid and does its job. I'm looking for the possibility to efficiently maintain detached branches, and BZR offers that. Further, there are many users to BZR, so it's rather well supported.
[09:37] <doomster> *tool
[09:39] <luks> partial checkouts are a reason why you might like svn more, but it depends on the project
[09:39] <_J_m_D_> from what I´ve learned bzr is more flexible as to the choice of available workflows compaired to svn, where as svn is more widespread and thus has more 3rd party tools. But I guess bzr is catching up, right?
[09:42] <doomster> actually there is one thing that might bite you with large binary files. When you prepare a directory for local work, you retrieve the current state via SVN but you retrieve the whole history via BZR, which takes significant amounts of time. I think (someone here will probably help out) that you can ignore parts of the history though, in order to preserve bandwidth.
[09:45] <_J_m_D_> regarding binary files - how are revisions made (whether svn or bzr)? Is the whole file saved again and again, or is some binary change-tracking-magic going on only storing incremental changes even to binary files?
[09:46] <Peng_> _J_m_D_: Most VCSes (including bzr and svn) use delta compression, but they also store full copies occasionally to improve performance.
[09:46] <Peng_> Bazaar's delta algorithm is line-based, isn't it?
[09:46] <luks> _J_m_D_: it uses text-based (splits the text to blocks on lines) delta compression
[09:47] <_J_m_D_> delta compression would then be like "store only the changed bytes of the file" or something similar?
[09:47] <luks> SVN uses a specialized binary delta compression for binary files
[09:47] <Peng_> _J_m_D_: Right.
[09:47] <luks> yes
[09:47] <_J_m_D_> oki - thnx
[10:10] <krokosjablik> Hello, question to bzr 1.3 (in hardy): the parent of my branch has been changed, how can I adjust my brunch? Or merge with the changed parent and just push?
[10:10] <doomster> brunch - mjam-mjam... ;)
[10:11] <krokosjablik> ﻿doomster: ﻿have I to look in man pages for the mjam-mjam option ;)
[10:22] <krokosjablik> ok, my solution was just to adjust the property "push_location"  in "<myBrunch>/.bzr/branch/branch.conf
[11:59] <awilkins> jelmer: ?
[12:59] <bob2> krokosjablik: 'bzr push --remember someurl' will work, too
[13:00] <krokosjablik> ﻿bob2: Many thanks!
[13:16] <jelmer> awilkins: hi
[13:17] <jelmer> chandlerc: please file a bug
[13:17] <jelmer> chandlerc: sorry, hadn't read the rest of your lines yet
[14:41] <LarstiQ> beuno: since the last merge of bzr.dev into nested-trees :)
[14:41] <LarstiQ> beuno: tree._iter_changes -> tree.iter_changes was easy enough to spot
[14:43] <LarstiQ> beuno: but tree.case_sensitive looks a bit harder, it only seems to be defined on working trees (which makes sense), I hope not to get into working vs revision problems there, will have to try.
[19:46] <LarstiQ> jfroy: I see some of your changes made it the bzr-svn 0.4 branch, how far away are you from having Keychain working?
[19:46] <jfroy> LarstiQ: it's working perfectly fine in bzr-svn
[19:47] <jfroy> The work is complete.
[19:47] <LarstiQ> cool
[19:47] <jfroy> It requires no modifications to svn either
[19:47] <jfroy> (and works fine with the version bundled with 10.5)
[19:48] <jfroy> I'm currently working on Keychain integration in bzr itself (lp:~jeanfrancois.roy/bzr/keychain-auth-rdonly)
[19:48] <jfroy> still at the experimental stage
[19:49] <LarstiQ> ooh, I should round up some of my mac users and point them to your work :)
[19:49] <jfroy> The branch works, but it's a huge ugly hack :p
[19:50] <jfroy> the work in bzr-svn was released with 0.4.12 (I think)
[19:50] <jfroy> .13 maybe
[19:50] <jelmer> 0.4.13
[19:50] <jfroy> thanks you :p
[19:50] <jfroy> *thank
[19:50] <jelmer> and thanks again for that work, btw ! :-)
[19:51] <jelmer> nabend LarstiQ
[19:52] <LarstiQ> navond jelmer :)
[19:52] <chandlerc> jelmer, was you're comment saying to not file the bug?
[19:52] <jelmer> chandlerc, yep
[19:52] <chandlerc> is this a known deficiency in the OpenSSL neon lib?
[19:53] <jelmer> chandlerc, filing a bug against neon may be a good idea though
[19:53] <chandlerc> fun times
[19:53] <jelmer> (not against bzr-svn though, which was what I was first thinking about)
[19:53] <chandlerc> ahh, yea, clearly not there
[19:54] <chandlerc> jsyk, the only remaining issue i have with actively using bzr-svn and googlecode is the 401 error not flipping from https to svn+https
[19:54] <chandlerc> i think i already filed a bug for that a while back
[19:54] <jelmer> chandlerc, yeah, that's been reassigned to bzr
[19:54] <jfroy> jelmer: oh, I noticed something odd while working on the keychain stuff in bzr. I did a merge or pull command from one bzr branch to another locally (2 local branches in a shared repo), and a file:/// svn RA connection was opened (or was tried), according to .bzr.log :p
[19:54] <chandlerc> but by specifying the svn+ i'm pulling and pushing and even merging conflicts across multiple machines now w/o issue! =]
[19:54] <jelmer> jfroy, it probably tried to open a file:// using svn
[19:54] <chandlerc> very happy about that
[19:54] <jelmer> chandlerc, cool
[19:55] <jelmer> jfroy, That's fine though - svn repositories can exist locally
[19:55] <jfroy> jelmer: yeah, not a big deal
[19:55] <jfroy> indeed
[20:25] <Kosjer> hi got a short question about the update from bzr 1.5 to bzr 1.7 on osx 10.5 . the installer is sayin the following warning note:  If you have installed a previous version of this bundle, please remove /usr/bin/bzr manually (the executable is located in /usr/local/bin/ since 1.4). so is it enough to manually delete in /usr/local/bin/  the bzr file? is that all? and then the updater could be run?
[20:27] <Kosjer> or have other files to be be removed too?
[20:30] <LarstiQ> Kosjer: I'm not certain, but I think that notice is to ensure there isn't an old leftover /usr/bin/bzr that comes earlier in the path than /usr/local/bin/bzr
[20:30] <LarstiQ> Kosjer: in which case, yes, that would be enough
[20:31] <Kosjer> larstiq ahhh true. i was unsure about the note. but i remember vaguely that on the switch to i guess 1.5 there was already the removal. tried it right now without any removal and it worked. updated nicely. all fine now :) thanks!
[20:32] <LarstiQ> Kosjer: good to hear
[20:51] <Kosjer> thanks and good night
[21:10] <alperkanat> is there authentication for bzr ? i want to setup a centralized server available over http using nginx..
[21:10] <alperkanat> so i guess i shall provide http authentication ?
[21:11] <jakobb> alperkanat: I know from experience at least that http authentication works
[21:11] <jakobb> you can even set a user/password in your personal rc files, such that you don't have to type them over and over again
[21:12] <alperkanat> is there some other choices like path authentication ? i may want to make some repos available to the public.. or read access is available to the public and write needs auth.. etc ?
[21:12] <alperkanat> jakobb: what rc files ?
[21:12] <jakobb> as long as you don't need redirection to get to the url, things should work fine
[21:13] <jakobb> alperkanat: the authentication.conf file in the .bazaar/ dir
[21:14] <alperkanat> hmm i haven't seen it in the docs
[21:14] <jakobb> it is definitely there, but I remember that you have to look hard for it
[21:15] <jakobb> It don't remember all the details, because I use hg nowadays mostly :P
[21:17] <jakobb> alperkanat: http://tinyurl.com/4zl6ae
[21:18] <alperkanat> jakobb: thanks
[22:30] <lifeless> moin
[22:31] <funkyHat> Where is the upload location for upload stored?
[22:32] <funkyHat> It keeps trying to upload to the old location although I've manually told it to upload to a new location
[22:34] <james_w> funkyHat: did you use --remember?
[22:49] <funkyHat> ah, I feel silly now :)
[22:50] <funkyHat> thanks