[00:17] <abentley> mwhudson: I think we have to introduce a new format to fix that serializer problem.
[00:18] <lifeless> if people have used it, for sure
[00:19] <lifeless> abentley: can we just rename 1.6-rich-root 1.6-subtrees, and add 1.6-rich-root?
[00:20] <abentley> lifeless: I don't think it makes sense to call it 1.6 if it wasn't introduced in 1.6
[00:20] <lifeless> abentley: true
[00:20] <lifeless> abentley: I was thinking 1.6.1
[00:21] <abentley> lifeless: Yeah, that would be tolerable, I think.
[00:21] <abentley> I'll have to go back and see whether it ever claimed not to support subtrees.
[00:23] <abentley> lifeless: It claims not to support subtrees, but has a serializer that does.  I think it's a lost cause.
[00:23] <lifeless> agreed
[00:23] <lifeless> lets make it say its bad in 1.6.1
[00:23] <lifeless> and get 1.6.1 out there asap; intrepid is in feature freeze, and has 1.6
[00:23] <abentley> You know, it's funny how little I hear about the Ubuntu dev cycle.
[00:24] <abentley> Anyhow, I agree we should do that.
[00:40] <fullermd> jam: Well, the upgrade completes, and it seems to work out right...
[00:42] <awilkins> Can Bazaar do client cert auth over http(s)?
[00:44] <lifeless> awilkins: I don't know, but if you can find the right magic to give pycurl, I can help you hook it in
[00:45] <awilkins> CAn it do basic/digest?
[00:45] <awilkins> I really can't open this up too far ; I now have IIS 6 running an HPSS (as long as you don't want any dumb service too!)
[00:46] <fullermd> jam: check is happy (of course, it was happy on the knit before too)
[00:47] <awilkins> Options for IIS 6 are - SSPI (not an option here), basic, digest, anonymous. You can also restrict connections to specific IPs, domain names, and posession of a client certificate
[00:49] <awilkins> You can map client certs to user accounts which would be one way of enforcing ACL
[00:50] <lifeless> awilkins: https + basic yes, I think we support digest already too
[00:50]  * elmo growls at #262450
[00:51] <awilkins> lifeless: That's great
[00:51] <awilkins> I must sleep but I can try configuring that tomorrow. I'll probably update my WSGI gateway script to support multiple repos too
[00:55] <awilkins> bug  #262450
[00:55] <awilkins> bug #262450
[01:25] <mlh> bug 262450
[01:36] <jelmer> kiorky, hi
[01:38] <jelmer> kiorky, it looks more like a bzr problem to me
[01:38] <jelmer> kiorky, the tgz file appears to contain a newline
[01:44] <LarstiQ> hey jelmer
[01:45] <jelmer> hi LarstiQ
[01:45] <LarstiQ> are you in .nl?
[01:45] <jelmer> yep
[01:45] <LarstiQ> jelmer: I failed in letting you know there was a python-nl meeting today :/
[01:47] <jelmer> LarstiQ, well, I was busy this evening anyway
[01:47] <jelmer> LarstiQ, how was the meeting?
[01:47] <LarstiQ> jelmer: great!
[01:47] <LarstiQ> jelmer: steve pointing me out swamped me with people for the rest of the evening though ;)
[01:47] <jelmer> (-:
[01:47] <LarstiQ> but that was partly what made it good, talking to lots of people
[02:32] <abentley> jam: Thanks for all the reviews.
[02:41] <jam> abentley: yeah, well I'm the 1.7 RM , I figure I need to get the review queue down, right?
[02:41] <jam> abentley, lifeless: So I just had jaypipes test my patch with the mysql tree
[02:42] <jam> and it drops the "bzr branch" time from 80+minutes down to 23min
[02:42] <jam> So I'd like to get that patch, and a possible patch for the bug lifeless mentioned
[02:42] <jam> and do a 1.6.1
[02:42] <jam> probably 1.6.1rc1
[02:42] <jam> Are you guys able to review it so I can get it turned around by tomorrow?
[02:43] <abentley> jam: my time isn't really my own 'till next week.
[02:44] <lifeless> jam: make sure they're in BB?
[02:44] <lifeless> jam: I'll do a review pass after lunch
[02:44] <jam> The fetch regression is
[02:44] <jam> I'll polish the other fetch bug
[02:44] <jam> bugfix and submit it
[02:44] <lifeless> jam: theres a critical format bug too;
[02:44] <lifeless> jam: 1.6-rich-root isn't
[02:45] <jam> lifeless: except that is a finalized format
[02:45] <jam> I don't think we can do anything but change the name to it
[02:45] <jam> as people are already using it as-is
[02:45] <lifeless> jam: we have to remove it
[02:45] <lifeless> jam: have bzr complain, and introduce a good one, because it won't work correctly for people
[02:45] <jam> I'm pretty sure people have already upgrade to it, I think I have at least one branch here
[02:46] <jam> I can understand "complain and ask to upgrade" or whatever
[02:46] <jam> but I think we need to leave it as a "supported" format
[02:46] <jam> (I don't care a lot for my own branch, as I can trivially get rid of it)
[02:46] <jam> but it has made it to an official release
[02:47] <lifeless> jam: no, we don't have to keep it supported
[02:47] <lifeless> its a brown paper bag bug
[02:48] <lifeless> I think we have to let people upgrade away from it sure, to prevent data loss, but it won't push or pull properly
[02:48] <jaypipes> jam: awesome work, mate :)  91 minutes -> 23 minutes.
[02:48] <jam> lifeless: that was more my point
[02:49] <jam> I would really like it if someone else could take over that one
[02:49] <jam> I don't have a lot of "work" time left today
[02:49] <lifeless> jam: right
[02:49] <jam> I'm mostly just sending in fixes I've already done
[03:06] <jam> lifeless: would you be able to do a patch for a --1.6-real-rich-root ?
[03:08] <lifeless> maybe, I'll see what I can do
[03:08] <jam> k
[03:08] <jam> worst case I'll get to it tomorrow
[03:08] <lifeless> no promises - I've got a few too many balls in the air this week
[03:08] <jam> but the turn-around time for reviewing a patch is a bit long
[03:08] <jam> with everyone gone
[03:09] <jam> I might give a poke at it right now
[03:09] <jam> to catch your post-food reviews
[03:12] <jam> abentley: just to be clear, we should use serializer v6, right?
[03:13] <abentley> jam: yes.  It needs to be the same serialiser as rich-root-pack uses.
[03:14] <jam> abentley: interestingly the docstring for RichRoot5 *does* say it supports external refs
[03:14] <jam> Maybe a copy paste bug?
[03:14] <jam> ah, it means Stacked branches rather than subtrees
[03:14] <abentley> RichRoot5?  We have one ofthose?
[03:14] <jam> "external lookups" confused me
[03:15] <jam> abentley: RepositoryFormatKnitPack5RichRoot is the class
[03:15] <abentley> jam: yeah, I find that one a bit confusing too.
[03:16] <jam> "results in non-truncated ghosts after reconcile" doesn't really seem to characterize it
[03:17] <jam> also, "get_matching_bzrdir" returns "bzrdir.make_format(development1-subtree)" what is up with that?
[03:18] <abentley> jam: RepositoryFormatKnitPack5RichRoot was copied/pasted from Development1, perhaps a bit too quickly.
[03:28] <StyXman> hi all. I just converted a svn repo into a bzr ... repo? I didn't use the --tree option. the faq says I should bzr co, but when I try I get: bzr: ERROR: No repository present: "file:///home/mdione/src/projects/psync/new/"
[03:41] <Verterok> Hi StyXman, using bzr-svn?
[03:51] <jam> lifeless: there are 3 patches for 1.6.1 review, which should all be in BB
[04:11] <lifeless> jam: what was teh 1.5 mysql clone time?
[04:30]  * Peng_ notices this discussion.
[04:34] <Peng_> Shush, Bundle Buggy. I know I don't have voting rights. It was a joke!
[04:58] <ptx> hi all. got a quick bzr question... is there a way to list branches / tags that are present in a remote repository?
[04:59] <ptx> (remote shared repo)
[05:00] <bob2> bzr branches url
[05:01] <ptx> ah I guess I need a more recent version of bzr then... my ubuntu got 1.3.1
[05:01] <ptx> bzr: ERROR: unknown command "branches"
[05:02] <ptx> thanks for the info. will try a later version.
[05:02] <Peng_> Actually, it's a part of the bzrtools plugin.
[05:02] <ptx> oh
[05:03] <ptx> thanks. going to d/l and check it out.
[05:03] <bob2> ah, sorry
[05:42] <jam> lifeless: "bzr branch lp:mysql-server" was ~90 minutes with bzr1.5, ~80 ish with 1.6, and 23min with the patch
[05:43] <jam> also, what is your feeling about --1.6-rich-root and renaming the old format?
[05:43] <lifeless> jam: we don't want users reading docs that say '1.6-rich-root' and getting the broken on
[05:43] <lifeless> one
[05:44] <jam>  ok, so you prefer --1.6-rich-root-broken and new and improved --1.6-rich-root?
[05:44] <lifeless> I prefer
[05:44] <lifeless> --1.6-rich-root-broken
[05:44] <lifeless> or better yet, the broken one not registered at all
[05:44] <lifeless> and --1.6.1-rich-root
[05:44] <jam> I think we at least have to register it as a repo format
[05:44] <jam> but we may not need to do a bzrdir format
[05:45] <jam> I'll try that route
[05:46] <lifeless> yes, thats right
[05:49] <Peng_> So it would be possible to upgrade from the broken format, but it wouldn't be visible in any way, outside of the code? That sounds nice.
[05:49] <Peng_> Or...I dunno. :)
[05:50] <Peng_> How easy was it to create something in the 1.6-rich-root format? "branch --stacked" from some rich-root-pack branch?
[05:52] <jam> lifeless, abentley: hmm... we have some stacking tests that assume stacking formats are all the same
[05:52] <jam> and development-subtree uses serializer 7
[05:52] <jam> versus 1.6-rich-root using 6
[05:52] <jam> (the new one)
[05:52] <lifeless> Peng_: yeah
[05:52] <jam> Should I just disable the development-subtree from being tested?
[05:52] <lifeless> Peng_: ebrownbag
[05:53] <lifeless> jam: uhm, no, lets fix it right
[05:53] <lifeless> jam: or it will just bite us later
[05:53] <jam> k, it is only "test_stack_checks_compatibility" at the moment
[05:53] <jam> But I'll poke at it a bit
[06:06] <jam> ah, the problem is that "development" still uses serializer 5
[06:32] <RAOF> Ow!  bzr, kindly don't consume 650Mb res.
[06:35]  * RAOF watches as bzr attempts to consume more memory than all other processes combined.
[06:35] <fullermd> Well, if you're just going to leave it lying around where bzr can find it...
[06:35] <lifeless> RAOF: what are you doing, and what version precisely?
[06:35] <RAOF> Oooh, so close.  It made it up to 998MB res.
[06:36] <RAOF> There shall be a brief haitus while my system is paged back in...
[06:36] <RAOF> bzr versoin 1.6, running "bzr multi-pull" in a repository with...6 branches
[06:37] <RAOF> lifeless: I heard bzr 1.6 had a memory problem.  I wasn't aware that extended up to 1gb resident :)
[06:38] <lifeless> RAOF: actual released version?
[06:38] <RAOF> lifeless: As packaged in Ubuntu Intrepid, yes.
[06:38] <lifeless> RAOF: same repository format?
[06:39] <RAOF> Yup.  All pack-0.92
[06:39] <lifeless> damn
[06:39] <lifeless> thats just wrong, it shouldn't spike like that
[06:40] <lifeless> can you reproduce with bzr.dev?
[06:40] <RAOF> It seems like each branch was stacking its own memory on the last; as if there was no GC going on.
[06:40] <RAOF> Let's have a try with bzr.dev.
[06:42]  * RAOF rather wishes firefox wouldn't spawn so many empty windows
[06:43] <RAOF> lifeless: The easiest way to run bzr.dev will be to just run 'bzr' from my branch, right?
[06:44] <lifeless> yes
[06:56] <RAOF> Progress bars almost uniformly suck.
[06:57] <RAOF> bzr's is no exception :(
[06:57] <lifeless> yes
[06:57] <lifeless> progress is ard
[06:57] <RAOF> Which is why they always suck.
[06:59] <RAOF> Yay!  We now have bzr.dev head.
[07:01] <RAOF> ...and we're up to 600Mb resident before it gives any output at all.
[07:02] <lifeless> RAOF: please file a bug
[07:02] <RAOF> And we break the 1/2 of my physical memory barrier!
[07:02] <lifeless> RAOF: having enough data to reproduce will be important
[07:02] <lifeless> also, hit ctrl-\
[07:02] <lifeless> and get a back trace
[07:03] <RAOF> Ah.  While bzr is multi-pulling.  Check.
[07:04] <RAOF> Hm.  That's new and different.  I've never used pdb before.
[07:05] <lifeless> later all, sluggish stuff
[07:06] <jml> RAOF: really?
[07:06] <jml> RAOF: let's switch lives
[07:06] <RAOF> Heh.
[07:11] <RAOF> Oh, that's rather interesting.  It seems that the horrible memory use requires the presence of non-branch directories.
[07:12] <gour> jelmer: hello, in regard to bug #261878 the problem is that svn can fetch the repo...
[08:40] <jonnydee> Hi :) I just wanted to ask if somebody could maybe set the importance of https://bugs.launchpad.net/bzr/+bug/255656 to at least medium? I fear that this bug gets forgotten, otherwise, in spite of the availability of a bugfix branch from lifeless. Our set up at work requires us to use a windows network drive for hosting our repository. And it's really an annoying bug...
[10:03] <jelmer> gour, svn doesn't fetch as much data as bzr-svn, it just fetches the last revision
[10:52] <gour> jelmer: still, i can do svn log and see the history...the point is that for quite some time i fetch and update pandoc repo and build the package, but bzr-svn fails to replace the need for svn
[10:52] <jelmer> gour, the problem appears to be that the svn server is unreliable
[10:52] <jelmer> gour, bzr-svn has to do far more requests than svn
[10:52] <jelmer> since it fetches every revision in history
[10:53] <jelmer> and the server occassionally fails with http errors
[10:55] <gour> i understand bzr-svn does more...however, i'd like to use bzr instead of svn and dunno what to do in this case
[10:56] <jelmer> gour, the problem really is in the reliability of google code, that's out of my control :-(
[10:57] <jelmer> if you're trying to do a one time import, you can branch into a shared repository and repeat when it fails
[10:57] <gour> well, i want to constantly fetch from the repo..
[10:57] <LarstiQ> jelmer: how well do stacked bzr-svn branches work?
[10:58] <jelmer> gour, as long as you're ok with retrying occasionally, that shouldn't be a problem
[10:58] <jelmer> LarstiQ, they're not layered appropriately enough in bzr yet for it to work well
[10:59] <gour> jelmer: ok. let me try to re-do and continue with that process
[11:00] <jelmer> LarstiQ, they do work, but all files have to be fetched individually atm, which doesn't make the process any faster
[11:01] <LarstiQ> jelmer: ah
[11:07] <Jc2k> .wg 3
[11:07] <Jc2k> gah
[11:07] <Jc2k> fail
[11:09] <jelmer> 'morning Jc2k :-)
[11:13] <Jc2k> morning jelmer :)
[11:19] <gour> jelmer: the problem is that if i retry with 'bzr pull', bzr says it's not a branch, so i've to try 'bzr branch' again which fails
[11:19] <gour> jelmer: it looks like catch-22
[11:21] <lifeless> gour: bzr init' then pull
[11:21] <uws> Is it possible to extract a part of a branch into a new branch?
[11:21] <uws> E.g. I have this "subproject" that I want to promote to a real project
[11:21] <lifeless> jonnydee: I think its merged and fixed in 1.6
[11:21] <lifeless> uws: bzr split
[11:22] <uws> lifeless: what will happen with revisions touching both files inside and outside this subproject directory?
[11:23] <lifeless> uws: it keeps all the history, as that lead into the project
[11:23] <lifeless> uws: it just creates a fork in the road, where one side is the subdir, and the other side is all but the subdir
[11:23] <uws> lifeless: so basically it's a new branch, removes everything not in that dir, and moves everything in that dir to the branch root?
[11:23] <lifeless> yes
[11:24] <lifeless> which lets you merge branches from before the split smoothly and so on
[11:24] <uws> lifeless: Ok thanks. will investigate
[11:25] <uws> lifeless: the "move" line in bzr status is a bit strange
[11:25] <uws> renamed:
[11:25] <uws>   subproject =>
[11:25] <uws> perhaps a / at the end helpt ;)
[11:25] <uws> helps*
[11:26] <lifeless> :P
[11:26] <lifeless> this is rarely used; please do file bugs :)
[11:28] <uws> lifeless: I cannot be bothered in this particular corner case ;)
[11:28] <lifeless> ok
[11:31] <jelmer> lifeless, this is how I ended up solving the sharing of VirtualSignatureFiles btw
[11:32] <jelmer> lifeless, A project "bzr-foreign" that is joined to both bzr-svn and bzr-git
[11:32] <lifeless> jelmer: and you merge from it twice?
[11:32] <jelmer> lifeless, yeah
[11:32] <lifeless> kk
[11:33] <jelmer> it's not optimal - by-reference nested trees would be awesome! - but good enough for now
[11:51] <jonnydee> lifeless: I just have had a look at the source code of 1.6 -- it seems like the bugfix is not merged inti bzr 1.6...
[12:41] <gour> jelmer: don't know how many times i've tried, but 'pull' fails 100%
[12:43] <gour> jelmer: here is the trace of bzr pull http://rafb.net/p/myafQi40.html
[12:56] <jonnydee> Hi, when I try to push a new branch to a repository on a windows network share thaen this command fails with a "bzr: ERROR: Could not acquire lock "B:/ProjektM/vendor/.bzr/checkout/dirstate""
[12:57] <jonnydee> Is it a bug? BTW, the branch seems to be pushed to the network share. I can checkout from there
[12:58] <james_w> that's just failing to create the working tree
[12:58] <jonnydee> but a lock seems to exist anyway and I have todo a  break-lock
[12:58] <james_w> OS locks are used for that, meaning that the share probably doesn't support them
[12:59] <fta> the builddeb plugin changed the default result-dir to ".." and the help message refers to --result-dir to change it but it doesn't seem to work. I get bzr: ERROR: no such option: --result-dir
[12:59] <jonnydee> but when I browse the working tree on the share it exists...
[12:59] <james_w> fta: try --result please
[13:00] <fta> james_w, seems ok, the help is wrong then.
[13:00] <fta> thanks
[13:00] <james_w> fta: thanks, I'll fix it for the next upload.
[13:01] <james_w> fta: are you setting --result back to ../build-area?
[13:01] <fta> it's building...
[13:06] <fta> james_w, well, didn't work for me. I wanted to revert to the previous default, ie, keep debs in ../build-area but if i set --result=../build-area , i get a traceback when it tries to move the files on themselves, which is obviously wrong.
[13:06] <james_w> fta: ah, thanks, I'll fix that too.
[13:06] <fta> either there should be a test to detect src = dst, or a way to disable that move
[13:06] <james_w> yeah, I'll do the former I think
[13:07] <jonnydee> lifeless: are you aware that bug 255656 is not merged in 1.6?
[13:17] <jonnydee> lifeless: sorry, if I'm bothering you, but I'm trying to convince my development team to use Bazaar and I am constantly experiencing problems with using a network share (which is our setup); the last error I stumbled over today is: bzr: ERROR: Could not acquire lock "B:/ProjektM/vendor/.bzr/checkout/dirstate" when I pushed a new branch.
[14:03] <james_w> fta: http://bzr.debian.org/pkg-bazaar/bzr-builddeb/2.0 has a fix if you need it.
[14:10] <lifeless> jonnydee: the bugfix is approved; it may not be in 1.6, but I was sure it was in bzr.dev. If its not I'll make sure it this week
[14:11] <lifeless> as for the lock problem, well, its after 11pm for me right now, way to tired to be thinking about it
[14:11] <lifeless> jonnydee: please file a bug to provide a discussion point about it
[14:15] <StyXman> hi all. I just converted a svn repo into a bzr ... repo? I didn't use the --tree option. the faq says I should bzr co, but when I try I get: bzr: ERROR: No repository present: "file:///home/mdione/src/projects/psync/new/"
[14:22] <james_w> jelmer: I just merged your directory branch, should it check whether bzr-svn is available before trying to checkout Vcs-Svn?
[14:25] <Stellaris> Hey, I am currently looking into how to ignore certain files from being monitored and got the User Guide open. I don't understand how the syntax for ignoring files down a file tree works (recursive stuff). I've got a .bzrignore file created.
[14:26] <james_w> StyXman: hi, what command did you use to do the conversion?
[14:27] <james_w> Stellaris: if you "bzr ignore dir/subdir/file" it will add an entry to the file, which should give you a hint
[14:27] <Stellaris> james_w: ah, thanks, will try that
[14:37] <Stellaris> james_w: thanks!
[15:08] <jelmer> james_w: Hi
[15:09] <jelmer> james_w: Yeah, it may be nice to check whether bzr-svn is present and give a more understandable error
[15:09] <jelmer> james_w: Otherwise, it'll just say "Not a branch" if you try to check out a svn branch
[15:16] <beuno> hey mwhudson
[15:16] <beuno> can you take a look at: https://code.edge.launchpad.net/~beuno/loggerhead/1.6.1/+merge/806
[15:16] <beuno> when you have time?  :)
[15:23] <abentley> lifeless: do you remember why cloning, unlike other operations, inits the branch and tree formats itself?
[15:23] <abentley> lifeless: For Pre-split-out bzrdirs.
[15:30] <rocky> jelmer: ever see anything like this ?  http://cluebin.appspot.com/pasted/1201   (bzr 1.6 final, bzr-svn 0.4.11 final, svn 1.4.6)
[15:34] <sabdfl> do i need to do anything with a branch to get the new b-tree index capability?
[15:34] <sabdfl> bzr upgrade is saying it has nothing to do
[15:35] <Jc2k> rocky: https://bugs.launchpad.net/bzr-svn/+bug/250480
[15:36] <rocky> Jc2k: awesome, thanks
[15:36] <jelmer> Jc2k, I'm pretty sure this is different
[15:36] <rocky> oh
[15:36] <jelmer> since this is about a revision object, not a file text revision
[15:36] <Jc2k> ah
[15:38]  * Jc2k has definitely seen NoSuchRevision before, though
[15:38] <james_w> hi sabdfl, I'm not sure the b-trees in bzr.dev are hooked up to a format yet, certainly not a default one.
[15:39] <james_w> jelmer: is a "try: import bzrlib.plugin.svn; except ImportError:" suitable for that?
[15:39] <rocky> jelmer: in that paste ... ClueMapper-rocky is a regular bzr branch of ClueMapper-trunk which is a bzr-svn checkout ... and "repo" is a "bzr init-repo -1.6-rich-root" repo
[15:39] <jelmer> james_w, yep, that should take care of it
[15:39] <james_w> jelmer: cool, I'll add it
[15:39] <jelmer> rocky, The revision it fails on, what sort of revision is that?
[15:40] <Kinnison> The btree stuff is wired up as --btree-plain and --btree-rich-root etc.
[15:40] <Kinnison> but they're not default afaict
[15:41] <rocky> jelmer: i'm not sure, how do i tell?
[15:41] <dudus> I want to use bzr to version some college papers also I want to have a central repository on a server where I commit all changes so I have a backup if something bad happens. I'll be the only user... Should I use this binded mode?
[15:41] <jelmer> rocky, that revision id, is that of a revision in the current branches' history (iow, does "bzr log --show-ids" list it?)?
[15:41] <jelmer> dudus, yeah, that sounds like the right approach
[15:42] <james_w> jam: are you familiar with git's recursive merging? Does/could bzr do something similar? Would it help at all?
[15:42] <rocky> jelmer: yes it does
[15:42] <rocky> jelmer: http://cluebin.appspot.com/pasted/1002
[15:42] <sabdfl> Kinnison: does --development include that?
[15:43] <dudus> james_w: thx
[15:43] <jelmer> rocky, Any chance you can paste the full "bzr log --show-ids" output?
[15:43] <jelmer> rocky, this looks like a bug in bzr not being able to cope with ghosts
[15:43] <rocky> sure
[15:44] <jelmer> rocky: Thanks for finding so many bugs :-)
[15:45] <rocky> lol
[15:45] <emmajane> How is the CVS integration? It's not as good as SVN, right?
[15:45] <rocky> jelmer: http://paste.plone.org/23470
[15:45] <Kinnison> sabdfl: Not sure, sorry
[15:45] <emmajane> (just in a session at DrupalCon, Lenz Zimmer is talking about bzr, we're all stoked)
[15:45] <jelmer> emmajane: yeah, correct
[15:45] <Kinnison> sabdfl: btree-plain is just pack-0.92 with btrees turned on
[15:46] <Kinnison> iirc
[15:46] <jelmer> emmajane: it's possible to do a one-way conversion, roundtripping is not possible
[15:46] <fbond> abentley: Hm.  Not sure about push/pull with loom.  Doesn't seem to take the recorded state of the loom into acount at all (from what I can tell).
[15:46] <james_w> emmajane: it's not as good as svn, no. There's no "foreign branch" plugin like bzr-svn, but there are several reasonable converters
[15:46] <fbond> abentley: Rather, it pulls from the currently selected thread (I think).
[15:46] <jelmer> rocky: Thanks
[15:46] <emmajane> Thanks, jelmer and james_w.
[15:47] <jelmer> rocky: This does indeed look like a bug in the ghosts handling
[15:47] <abentley> fbond: Are you pulling from a loom into a loom?
[15:47] <emmajane> git has sub-projects, is there an equivalent in bzr?
[15:47] <fbond> abentley: in fact, it's not clear to me that `bzr record` has any value at all, currently.
[15:47] <fbond> abentley: yes
[15:48] <rocky> jelmer: if/when you need me to switch to the bzr-svn branch lemme know
[15:48] <fbond> abentley: I have two looms that are mirrors of each other, but one is beind the other.
[15:48] <fbond> abentley: Be nice to have a single command that brings all the changes from one into the other (in all threads).
[15:48] <abentley> fbond: That's suprising.  last time I tried pull, it was definitely broken.
[15:50] <fbond> abentley: You are surprised it's still broken, then?
[15:51] <abentley> fbond: It was broken because it was trying to behave as pull-loom.  I would have thought when it was fixed, it would have.
[15:52] <fbond> abentley: Well, I'm currently using 1.3.1...
[15:53] <james_w> emmajane: "nested trees", there's experimental support for them, but nothing solid yet. I hope it will be a 2.0 feature, i.e. this year.
[15:54] <fbond> abentley: In any case, I can pull one thread at a time by moving through threads on each end before pulling.
[15:54] <emmajane> thanks, james_w
[15:55] <rocky> bzr has no equiv of svn:externals right ?
[15:56] <emmajane> (Lenz Grimmer, I think I had the last name wrong.)
[15:57] <Jc2k> rocky: aiui.. it has by-value nested trees, but not by-reference trees in 1.6 (svn:externals are by-reference)
[15:57] <Jc2k> *by-reference nested trees
[15:59] <rocky> what does a "smart server" mean within the context of bzr? (in relation to just a "server")
[16:00] <dudus> when should I use bzr init and when to use bzr init-repo to create a central repository?
[16:00] <rocky> dudus: i just learned that "bzr init" doesn't create a central repository ... it merely turns the directory into a bzr-versionable dir ;)
[16:02] <dudus> in the second exemple in this link it uses init to create the central one !?! http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#publishing-a-branch
[16:02] <StyXman> james_w: sorry for dissapearing. bzr svn-import <path to repo>
[16:05] <james_w> StyXman: and you were in /home/mdione/src/projects/psync/ when you ran that?
[16:05] <james_w> StyXman: what directory are you running the "co" command in?
[16:05] <emmajane> statik: Lenz says hello. :)
[16:07] <StyXman> james_w: no, in /home/mdione/src/projects/psync/new/
[16:08] <StyXman> err, in another dir, actually. so the question is, how should I do it?
[16:08] <abentley> dudus: No, it uses init-repo to create a central repository.
[16:08] <james_w> StyXman: have you moved anything around since running "bzr svn-import"?
[16:08] <Jc2k> rocky: smart server implies not dumb, e.g. vanilla http is dumb
[16:09] <StyXman> james_w: actually I copied the .bzr dir in trunk
[16:09] <james_w> StyXman: ah, that's probably not a good idea
[16:10] <StyXman> thing is, if I do a svn-import it creates the whole svn tree: trunk, branches/* and tags/*
[16:10] <james_w> do you just want "trunk"?
[16:10] <StyXman> in the parent of all those there's a .bsr
[16:11] <StyXman> james_w: idealy I want all the history, but trunk is enough
[16:11] <StyXman> s/bsr/.bzr/
[16:11] <james_w> can you put the .bzr dir back where it was?
[16:11] <StyXman> james_w: yah, I only copied it
[16:12] <james_w> ah, can you delete what you copied then?
[16:12] <StyXman> yeha, it's throw-away'able :-P
[16:13] <StyXman> done
[16:13] <james_w> now "cd trunk; bzr checkout ."
[16:14] <StyXman> takes time :)
[16:14] <StyXman> there, thanks
[16:15] <StyXman> now, i have lots of .bzr dirs
[16:15] <james_w> have you got what you want now?
[16:15] <StyXman> psyc/.bzr, psync/trunk/.bzr, psync/tags/*/.bzr, etc
[16:16] <james_w> yep, they are each branches
[16:16] <james_w> except for psyc/.bzr which is the "shared repository" that holds the actual revision data
[16:17] <StyXman> aha
[16:18] <StyXman> ok, I'll have to re-read the user reference then... thanks james_w
[16:43] <Jerky_san> hello
[16:44] <Jerky_san> I have a question or 2
[16:45] <Jerky_san> what permissions are required to the .bzr folder and its sub folders if you are going to do http?
[16:45] <rocky> Jc2k: the reason i'm asking is because i was wondering about serving up a bzr repo from my python wsgi app (i'm a python programmer) in a R/W fashion ... does the standard wsgi app allow that?
[16:46] <rocky> (i'm aware of the missing auth problem)
[16:46] <Jc2k> rocky: not a dev, so dunno
[16:48] <james_w> Jerky_san: if you are just serving the files out over http then any permissions that allow your web server to read the files is enough
[16:48] <Jc2k> gour: ping
[16:49] <Jerky_san> danke james
[16:50] <Jerky_san> my other question is if i use htaccess to restrict who can see whats in the folder i seem to get an eror that says  ERROR: pycurl.error: (65, "necessary data rewind wasn't possible")
[16:50] <Jerky_san> *error
[16:51] <Jerky_san> i thought it had to do wtih permissions to folders/files so i did a test folder and 757 permissions to all files and folders..
[17:10] <Jerky_san> bleh this error is so wierd ._.
[17:16] <Jc2k> gour: bzr branch http://bzr-mirror.gnome.org/bzr/pandoc/trunk pandoc
[17:16] <Jc2k> gour: ping me when you have it, i dont like having non gnome svn stuff on there
[17:18] <Jc2k> gour: it really was just googlecode being flakey, i had to use bzr pull -r50, bzr pull -r100, bzr pull -r150 and eventually it got there
[17:28] <jelmer> rocky, still there?
[17:28] <rocky> jelmer: yes
[17:28] <jelmer> rocky, what was the URL of your svn repo again?
[17:29] <rocky> https://dev.serverzen.com/svn/cluemapper
[17:29] <jelmer> and the specific branch on which the error occurred?
[17:30] <rocky> jelmer: well, this was against a local bzr branch that branched off of cluemapper/trunk checkout
[17:30] <rocky> err
[17:30] <rocky> cluemapper/ClueMapper/trunk
[17:30] <jelmer> thanks
[17:36] <Jerky_san> welp i figured my error out.. apparently the file pycurl.pyd causes it if you attempt to connect through https
[18:15] <nihilocrat> hello
[18:16] <nihilocrat> I'm wondering if there's a way of intentionally ignoring any conflicts that come up in a particular file
[18:20] <gour> Jc2k: got it. thanks a lot ;)
[18:27] <james_w> nihilocrat: ignoring them how?
[18:28] <james_w> committing the conflicted version? always using your current version? always using the version you merged?
[18:49] <nihilocrat> always using the version that the parent branch has
[18:49] <nihilocrat> so
[18:49] <nihilocrat> file.OTHER
[18:55] <Verterok> nihilocrat: 'bzr revert file', should do the trick
[18:58] <lixomancem> Hello. I just installed 1.6 on windows and restarted my computer. When I right-click somewhere and choose "bzr init" a window pops up with the message "UnrecognizedCommandError: init". The same happens with the "bzr checkout" option, but not with the "bzr branch" option. What can I do?
[19:00] <james_w> nihilocrat: there's no automatic way to do that, you can just move file.OTHER over the top of file in those cases though
[19:07] <nihilocrat> k, I'll just write a shell script
[19:07] <nihilocrat> thanks for the input though
[19:20] <Spaz> hmm
[19:20] <lixomancem> Hello. I just installed 1.6 on windows and restarted my computer. When I right-click somewhere and choose "bzr init" a window pops up with the message "UnrecognizedCommandError: init". The same happens with the "bzr checkout" option, but not with the "bzr branch" option. What can I do? I can run bzr init on the command line, but there are orhter commands that do not work then, like bzr add...
[19:20] <lixomancem> ...for instance.
[19:20] <Spaz> is there any plugin to bzr that can add RCS tags (or something similar) to files on commit?
[19:20] <Spaz> it would be useful for me
[19:30] <jelmer> Spaz, yeah, the keywords plugin should be able to do that
[19:59] <Spaz> jelmer, hm
[20:20] <jam> 1.6.1rc1 has been released, packages are building in the beta-ppa now
[20:25] <vila> jam: you rock ! You deserve a good week-end at least :D
[20:28] <jam> thanks vila
[20:29] <jam> vila: did you get your patch submitted?
[20:29] <vila> I'm preparing the submission for  -s aliases
[20:30] <vila> oh, and just seen your approve for but '55 select/poll' bug, I will fire both
[20:30] <vila> s/but//
[20:30] <vila> yeah, no but ! :D
[20:33] <jam> vila: well, no ifs ands or buts, but I guess there is an and in there ...
[20:33] <jam> :)
[20:33] <vila> :)
[20:33] <abentley> jam: Where are we in the 1.7 release process?
[20:34] <abentley> s/release process/development cycle
[20:34] <jam> abentley: feature freeze is supposed to be today
[20:34] <jam> rc1 next friday
[20:34] <jam> final the next week
[20:34] <jam> wait, I think I bumped it back a bit
[20:34] <jam> 25th, 2nd, 8th
[20:35] <jam> I'll probably end up going back to the original
[20:35] <jam> so we don't end up with 1.6.1 and 1.7 on the same day
[20:35] <abentley> jam: :-)
[20:35] <jam> time based releases sneak up on you when you end up with 5 release candidates and a .1 release
[20:36] <jam> at least poolie and spiv will be back next week to see all the carnage I've caused
[20:36] <jam> abentley: is there anything you would like to get into 1.7
[20:37] <abentley> jam: That push cleanup I sent in is the only pressing thing.
[20:38] <jam> abentley: well, I at least gave it a once-over and it seemed fine
[20:39] <jam> but I didn't poke at it enough to really give a review yet
[20:39] <abentley> I've got about 6 threads left in my PreviewTree loom, but that can easily slip to 1.8
[20:39] <jam> abentley: It would be *really* nice if you could review my merge patch
[20:39] <jam> I really wanted that in 1.7
[20:39] <jam> and it has sat around for about 2+ weeks
[20:40] <abentley> jam: Okay, I will review it by next Wed.  Please harass me if I don't.
[20:40] <jam> k
[20:40] <jam> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48936560.6040106%40arbash-meinel.com%3E
[20:40] <jam> Just in case you feel like you have some time
[20:45] <jam> vila: don't forget that next week is going to be feature freeze, and you and Verterok offered to be OSX test guardians
[20:46] <vila> yeah, I was waiting a bit for some feedback but I will submit as is and we'll continue
[20:46] <jam> vila: feedback on what?
[20:46] <jam> whether you are the padawan  or the master?
[20:47] <vila> lol, no, this has been sorted out :)
[20:47] <jam> I think with 1.7rc1 in slightly more than 1 week, you're running out of time to wait for feedback
[20:48] <vila> To make the permission tests pass we implemented a _mac_mkdtemp to fix OSX strange idea to assign temp dirs group permissions to a group the user is not a member of...
[20:49] <vila> That means one chown call at each creation, since bzr doesn't really need the abitility to set the group sticky bit I was wondering about making that a feature instead and skip the tests instead
[20:50] <vila> well a single instead should be enouhg
[20:50] <vila> enough
[20:50] <vila> pfew
[21:04] <Jerky_san> is there a way for when you do a push to set what permissions you want the files to have?
[21:04] <Jerky_san> since when i push them the new files get permissions that can only be read by ftp but not http
[21:10] <Peng_> jam: There's a typo in 1.6.1's NEWS, about the readv perf improvement: "we know always request full texts"
[21:34] <Verterok> jam: thanks for the reminder (of the freeze)
[21:45] <Verterok> vila: I've been strugling, with bzr-eclipse. I'll try to catch up with the os x test during this weekend
[21:51] <fbond> Hi.
[21:52] <fbond> How can I make lp: work over https instead of ssh?
[21:52] <fbond> I keep getting permission denied but I have no intention of using ssh on this machine.
[21:56] <ElianaTamerin> Can I set up bzr on shared host w/o SSH?
[21:58] <fbond> ElianaTamerin: how do you upload files to your shared host?
[21:58] <ElianaTamerin> ftp
[21:58] <fbond> You can bzr push over FTP.
[21:59] <ElianaTamerin> what does that involve?
[21:59] <fbond> Others can get read-only access via HTTP.
[21:59] <fbond> ElianaTamerin: Nothing complicated.  Works out of the box as well as SSH, etc.
[21:59] <ElianaTamerin> hmm, not idea, it's a project with multiple devs
[21:59] <ElianaTamerin> ideal*
[22:00] <fbond> ElianaTamerin: I doubt you can spawn long-running process in a limited shared hosting environment, so everyone that wants write access to the repo needs write access to the machine.
[22:00] <fbond> (If long-running process are okay, you can probably use the smart server.)
[22:01] <fbond> ElianaTamerin: Can you give other devs FTP access, too?
[22:01] <ElianaTamerin> yes, I can
[22:01] <fbond> That'll be the way to go, I guess.
[22:01] <ElianaTamerin> would they need to keep a local build of bzr to push from?
[22:02] <fbond> ElianaTamerin: I'm not sure I understand your question.  The other devs would also be using bzr, right?
[22:02] <ElianaTamerin> correct
[22:02] <fbond> ElianaTamerin: So what do you mean by "a local build of bzr"?  I assume they have bzr installed on their local machines.
[22:02] <ElianaTamerin> that was my question
[22:03] <ElianaTamerin> if they had to have bzr installed
[22:03] <fbond> Oh, yes, they would have to install bzr to use it.
[22:03] <fbond> (Like every other VCS that I am aware of.)
[22:03] <ElianaTamerin> and one last question, would the platform matter? if one used win, and another used mac, another *nix, would there be any issues?
[22:03] <ElianaTamerin> on their local computers, that is
[22:04] <fbond> bzr is designed to be cross-platform.
[22:04] <ElianaTamerin> wonderful
[22:04] <fbond> If it doesn't work well on any of those machines, it's a bug.
[22:04] <fbond> Now, I don't use those platforms, so I can't personally say how good support currently is.
[22:04] <fbond> But cross-platform support is an explicit goal of the project.
[22:04] <ElianaTamerin> alright, I'll give it a go and see how it works
[22:04] <fbond> ElianaTamerin: Great, good luck!
[22:05] <jam> abentley: I'm getting an "unexpected success" trying to merge 1.6.1 into bzr.dev, something about the "test_sprout_upgrades_to_rich_root" which expects it to be an Incompatible repo
[22:06] <jam> I think because the 1.6.1 *should* auto-upgrade now
[22:06] <jam> Do you thnik that is correct?
[22:06] <abentley> jam: yes.
[22:07] <jam> ok, I'll remove the "expect_failure" then
[22:07] <abentley> That test was how I discovered the format issues.
[22:08] <jam> k
[22:08] <jam> The error was a bit odd
[22:08] <abentley> poolie should really have written one like it, and then we wouldn't be brown-bagged.
[22:08] <jam> AssertionError: Unexpected success.  Should have failed: Rich root format should be sprout-compatible
[22:09] <jam> Because it is unclear what the actual failure message is versus what is actually expected
[22:09] <jam> anyway
[22:09] <jam> i need to get going
[22:10] <abentley> jam: not sure how to fix in the general case.  I have to go too.
[22:32] <rocky> jelmer: any luck on my problem? :)
[22:32] <jelmer> rocky, sorry, that's a bzr problem, not a bzr-svn one
[22:32] <rocky> jelmer: oh yeah?
[22:32] <rocky> does it have a issue #?
[22:33] <jelmer> rocky: not sure, let me check
[22:33] <jelmer> rocky, didn't you file a bug about bzr shelve giving NoSuchRevision?
[22:33] <rocky> nope
[23:22] <jelmer> rocky, still there?
[23:34] <springdale> Hi, I would love to use a gui tool for diffs between revisions of files. Is there some way to use meld or how would I do it?
[23:57] <springdale> I found this "--using=meld" somewhere but it does not seem to do anything.