[12:05] <AfC> Peng, nilton: there is a mans whereby you can transparently, internally redirect a http:// request to a mod_python running a Bazaar server instance. It's purported to work from http:// although that may still be a bug.
[12:05] <AfC> Good morning
[12:52] <Alien|Freak> is there a guide for importing an svn tree to bzr?
[12:54] <jelmer> Alien|Freak: not really - what sort of information are you lookjing for?
[12:54] <Alien|Freak> history
[12:55] <Alien|Freak> it's just one project really.. but I want to import the history from an svn repo to a bzr repo
[01:06] <jelmer> Alien|Freak, the bzr-svn plugin has a svn-import command that can do that
[01:20] <Verterok> moin
[02:22] <lifeless> ~
[02:30] <jdub> hey folks
[02:30] <jdub> bzr-rebase is still not available in gusty
[02:30] <jdub> which is problematic for folks already using bzr-svn
[02:44] <jdub> hrm
[02:44] <jdub> so i've installed bzr-rebase from debian
[02:44] <jdub> but get the following on svn-upgrade:
[02:44] <jdub> Using saved location: http://svn.automattic.com/wordpress-mu/trunk
[02:44] <jdub> bzr: ERROR: Repository KnitRepository('file:///home/jdub/src/wordpress/wpmu/.bzr/') is not compatible with repository SvnRepository('http://svn.automattic.com/wordpress-mu')
[02:44] <jdub> 
[02:45] <jdub> (which is the same as what i get with merge)
[02:45] <jdub> oh, rm
[02:45] <jdub> shared repo
[02:47] <jdub> jelmer: ping
[02:47] <jelmer> 'morning jdub :-)
[02:47] <jdub> hi :-)
[02:47] <jelmer> The local repository has to be upgraded to a newer format ('bzr upgrade --dirstate-with-subtree')
[02:48] <jdub> hrm, is there a reason why bzr upgrade doesn't change to that by default?
[02:49] <jelmer> that format is only required by subtrees, which aren't the supported yet
[02:49] <jelmer> and it's not the default format
[02:49] <jdub> oh, another problem -> bzr-svn recommends bzr-rebase >= 0.2
[02:50] <jdub> debian only has 0.1
[02:50] <jdub> am i safe? :)
[02:51] <jelmer> jdub: No, I'd recommend using the branch of bzr-rebase for now
[02:51] <jelmer> also, it looks like gutsy is two releases behind for bzr-svn :-/
[02:52] <jdub> i can just branch those into ~/.bazaar/plugins, right?
[02:52] <jelmer> yep
[02:53] <jelmer> lifeless: Any chance we can update that before gutsy?
[02:54] <jdub> https://code.launchpad.net/~jelmer/bzr-svn/trunk <- this branch?
[02:55] <jelmer> nope - that's the next unstable release series, 0.4 is http://people.samba.org/bzr/jelmer/bzr-svn/0.4
[02:55] <jdub> https://code.launchpad.net/~jelmer/bzr-rebase/trunk <- for rebase? :)
[02:56] <jelmer> yup (-:
[02:56] <jdub> ok
[03:02] <jelmer> I think lp:bzr-rebase and lp:bzr-svn as urls should work as well
[03:12] <spiv> Yeah, they do.
[03:13] <jdub> currently doing svn-upgrade, will report :-)
[03:21] <jdub> boh
[03:21] <jelmer> jdub: something broke?
[03:22] <jdub> http://en.pastebin.ca/735991 <- yeah
[03:26] <jelmer> thanks
[03:28] <jelmer> jdub: Argh, this has actually regressed because I don't have rebase here locally so it's not running the testsuite.
[03:29] <jelmer> jdub: I'll see if I can fix rebase and release 0.2 tomorrow. Should've been done earlier..
[03:29] <jelmer> jdub: Should I email you once I get this fixed?
[03:30] <jdub> not wildly pressing, i'm just pottering around with relaxing maintenance things atm 8)
[03:30] <jdub> but i would like to do some more work on blogo some time ;)
[03:31] <jdub> i guess the pressing part of it is that gusty could really do with this stuff updated
[03:31] <jelmer> well, it needs to happen anyway and I keep postponing it
[03:32] <jelmer> and yeah, would be nice to have it in gutsy
[03:33] <jelmer> time for some sleep first though
[03:33] <jelmer> g'night!
[03:34] <jdub> ciao :)
[03:34] <jdub> thanks again
[03:45] <abentle1> jdub: in case it's not clear, dirstate-with-subtree is a watershed, and not currently supported.  So don't convert a shared repo to it unless all the branches are bzr-svn branches.
[03:47] <jdub> abentle1: ah, ok. in this case, they are (or branches of bzr-svn)
[09:15] <nick125> Is there a way to setup a centralized bzr repositority over HTTP without WebDAV?
[09:25] <vila> nick125: for read-only access, yes, just serve the .bzr directory and you're done
[03:07] <jelmer> james_w: were you working on git-like support for branches?
[03:49] <hsn_> you mean more branches in one directory? thats pretty evil
[03:50] <jelmer> hsn_: Yes, it is. I wouldn't want that to be in bzr as default (because it will be confusing for a lot of users)
[03:50] <jelmer> but it can be pretty useful for C projects
[03:50] <jelmer> or large projects
[03:50] <jelmer> I now have 10 working trees, all of which take up a lot of space (C files and object files)
[03:51] <hsn_> jelmer: dispace is cheap
[03:51] <hsn_> human work isn't
[03:51] <jelmer> Why does it cost human work?
[03:52] <jelmer> also, disk space is actually a problem on my machine
[03:52] <jelmer> 640 Mb per Samba tree * 10 trees = 6 Gb
[03:52] <jelmer> that's a fair share of my 80Gb notebook disk
[03:53] <luks> but do you always use only one branch?
[03:53] <jelmer> no, I work on all of these in parallel
[03:54] <luks> and how would you build them in parallel with git-like branches?
[03:54] <hsn_> you can use shared repos
[03:54] <luks> this is why I personally don't like it
[03:54] <luks> I prefer to have multiple branches ready to use
[03:54] <jelmer> hsn_: it's not the history that is the problem
[03:54] <jelmer> it's the working tree
[03:56] <hsn_> whats are benefits of git model vs lightweight checkouts and shared repo?
[03:56] <jelmer> luks: when I switch, the build system takes care of building the few files that are different
[03:57] <jelmer> hsn_: Each lightweight checkout is still 640 Mb for me
[03:57] <vila> does that include uncommitted changes ?
[03:57] <jelmer> vila: in git you have to commit changes before switching to a different branch, but I guess you could shelve them in bzr
[03:58] <vila> how does that play with makefiles ?
[03:59] <vila> every file which has a non-empty diff between branches get touched ?
[04:00] <jelmer> yes, and rebuild
[04:00] <vila> can't you just get that with the right merge commands ?
[04:00] <jelmer> generally, I only tend to have a few percent of the files changed between branches
[04:01] <jelmer> vila: you're right in that it shouldn't be too hard to implement
[04:01] <jelmer> just changing last-revision of the working tree
[04:01] <jelmer> and then updating the working tree
[04:02] <vila> 'revert -r' followed by  'merge --remember' should address quite a good part of the cases no ?
[04:03] <jelmer> I don't think you'd want to do a merge
[04:03] <jelmer> there are also a couple of other things - such as being able to list the possible branches
[04:03] <luks> what about tree-less branches + one checkout?
[04:04] <vila> luks: that's what we are talking about
[04:04] <jelmer> luks: that works, but impossible to push at once
[04:04] <hsn_> you cant checkout into directory with checkout?
[04:05] <vila> jelmer: I agree that the '-r rev' parameters should be assisted
[04:05] <vila> jelmer: what do you mean 'impossible to push at once' you're pushing in one branch at a time
[04:06] <james_w> jelmer: I was looking at it. It's not easy though.
[04:06] <james_w> jelmer: (there is now git-stash to allow you to switch with changes in the working tree).
[04:07] <jelmer> james_w: should be quite simple - what problems did you hit?
[04:09] <james_w> jelmer: there are things like what it means to push in to a branch that is using this system, do you have a default thread that it goes to, or the one that is currently checked out.
[04:09] <james_w> (I use thread to try and avoid overloading the branch term).
[04:10] <james_w> and from the branch API it is hard to know what the operation is.
[04:10] <jelmer> james_w: Is your work-in-progress published somehwere?
[04:10] <james_w> jelmer: no, it's just playing around at the moment. Would you like to see it anyway?
[04:11] <jelmer> james_w: yes, please
[04:14] <james_w> http://jameswestby.net/bzr/threads/dev/
[04:14] <james_w> There's no ui to it, just look at threads.py and tests/
[04:15] <jelmer> thanks
[04:16] <james_w> I'm not sure but I think it might need to provide a Branch, Repository and WorkingTree, CommitBuilder and others.
[04:16] <james_w> or at least API changes may be needed.
[04:17] <james_w> tests/test_threads.py is where the interesting stuff is.
[04:17] <james_w> At the moment it is written for quilt style, but it could be adapted for git style.
[04:18] <jelmer> hmm, I was thinking of something much simpler
[04:19] <jelmer> UI only really, perhaps only a new branch format
[04:19] <james_w> I would be interested in your ideas, I'm all for simplicity.
[05:27] <bialix> jelmer: switch command in bzrtools -- may be this is answer for your question?
[05:44] <jelmer> bialix: partially, I'd like to have the branches in one directory, otherwise it's impossible to propagate them
[05:44] <bialix> I use repo-push plugin for this task
[05:56] <vila> bialix, jelmer, james_w : It looks like you're all having specific  workflows that share many bits, that may be worth documenting if only to understand what can be reused and what should added to bzr (core or plugins)
[05:57] <bialix> I don;t use switch, but use repo-push a lot to sync my branches at work and at home via USB d=flash disk
[05:58] <vila> jelmer: Is that what you called 'impossible to push at once' ?
[05:58] <vila> jelmer: just trying to understand
[05:59] <jelmer> vila: there's no way to push a set of 10 branches to a remote machine at once
[05:59] <vila> jelmer: only because you don't have the UI you mean ?
[06:37] <Qhestion> has anyone used the bazaar plugin for eclipse?
[06:44] <hsn_> :raises hand
[06:53] <Qhestion> hsn: does it work? *sceptical look*
[06:53] <Qhestion> oops, misspelled your name... for highlighting only: hsn_
[06:54] <Odd_Bloke> Qhestion: It's still in alpha/beta, so probably suck-it-and-see is the only way you're going to find out whether it does what you need...
[06:54] <Qhestion> wrong
[06:54] <Qhestion> the other way is asking
[07:00] <Odd_Bloke> Qhestion: The last commit to trunk was 2 days ago.  The odds of someone having used it in the last 2 days being in-channel to answer your question are fairly low.
[07:00] <Qhestion> maybe
[07:00] <Qhestion> but chances are
[07:00] <Qhestion> and i didnt say "latest version"
[07:00] <Qhestion> i just wanted an overall impression
[07:01] <Qhestion> i mean - chances are that even the dev of it is here
[07:01] <Qhestion> i alread had such situattions
[07:01] <Odd_Bloke> !weekend
[07:01] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[07:02] <Qhestion> oh forgot that...
[07:02] <Odd_Bloke> The dev is Verterok, who's not in channel ATM.
[07:02] <Qhestion> ok, thank you
[07:02] <Qhestion> but it anyway was just a try
[07:03] <Qhestion> i think i will stick to the console and come back in half a year...
[07:03] <Qhestion> this is what i know, and i know that works :)
[07:03] <Qhestion> k, cu
[09:05] <sri> yo
[09:07] <hsn_> element tree is part of python2.5?
[09:07] <nick125> hsn_: Yup.
[09:09] <hsn_> i am updating wiki windowsinstall page to python 2.5, it seems to be easier
[09:09] <hsn_> less packages needed than for python2.4
[09:37] <schierbeck> jelmer: ping
[09:37] <jelmer> schierbeck, pong
[09:37] <schierbeck> can i ask you something about the viz?
[09:37] <jelmer> sure
[09:38] <schierbeck> it seems weird to me that one must specify the branch being visualized with set_branch()
[09:38] <schierbeck> when will you ever use the viz without a branch?
[09:38] <schierbeck> wouldn't it be more reasonable to specify it in the constructor?
[09:38] <hsn_> maintainer of bzr for win32 around?
[09:38] <jelmer> schierbeck: The idea is that eventually it should be possible to visualise a set of branches (like gitk --all)
[09:39] <jelmer> hsn_: that's bialix I tihnk
[09:39] <jelmer> schierbeck: but I don't think being able to pass it to the constructor is a bad idea
[09:39] <schierbeck> jelmer: i'm looking at extracting the treeview into its own file
[09:40] <schierbeck> and having to define a set_branch() there, too, seems a bit much
[09:41] <jelmer> schierbeck: feel free to remove it if you think that makes sense
[09:41] <schierbeck> ok :)
[10:50] <ubotu> New bug: #152746 in bzr "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [Undecided,New]  https://launchpad.net/bugs/152746