[00:09] <igc> morning
[01:52] <db-keen> the user guide describes two methods of starting a repo, one with init and one with init-repo and a nested branch. How should I choose which one to use?
[01:52] <lifeless> init creates a branch
[01:53] <lifeless> init-repo creates a shared repo which may contain branches
[01:53] <lifeless> branches do not need a shared repo, they will have their own if no shared one is available
[01:53] <lifeless> just start with init and get used to bzr, worry about shared repositories once you are familiar with the tool
[01:55] <jdong> db-keen: the advantage of shared repos is that multiple branches can share a common storage of their history, which saves local disk space and lowers the cost of retrieving another related branch over a slow network connection
[01:55] <jdong> but as lifeless said, first familiarize yourself with the operation of bzr without repos, then repos will be an easy tool to learn
[02:47] <db-keen> I don't see a move command, how do you move a file?
[02:47] <jelmer> bzr mv
[02:47] <db-keen> nevermind, I found it
[02:49] <andresj> hello! how can I install bzr-1.2 in ubuntu gutsy? I added the ppa repository and `apt-get update`, and tried to install it, but there is a conflict... bzrtools needs <bzr-1.2
[02:59] <tchan> bzrtools-1.2.0 works just fine with bzr-1.2
[03:00] <db-keen> bzrtools 1.2.0 isn't in the ppa repository
[03:04] <andresj> tchan: bzrtools--oh db-keen already said it :)
[03:04] <poolie> andresj, it'll be up soon
[03:04] <andresj> when was bzr-1.2 released?
[03:07] <poolie> last friday
[03:16] <andresj> I see :)
[03:19] <db-keen> I've got this: bzr: ERROR: Generic bzr smart protocol error: <Fault 8002: 'error'>
[03:19] <db-keen> however it looks like the operation (push) succeeded
[03:24] <jml> db-keen: that's from pushing to Launchpad, right?
[03:25] <jml> db-keen: how did you invoke bzr to get that message?
[03:25] <db-keen> bzr push bzr+ssh://db-keen@bazaar.launchpad.net/~db-keen/rush/site
[03:28] <andresj> I created a repository with '--no-trees' and created a branch in the same place. Then, from the repository, run `bzr commit . main` to have a place to do the development. Then I created a file and added it, and tried to commit it. But it throws a traceback and an error... "bzrlib.errors.NoSuchRevision: KnitPackRevisionStore(VersionedFileStore('file:///.../.bzr/repository/')) has no revision ...@....com-20080220032150-zkhw0oui4mdlelzb"
[03:28] <andresj> (I replaced some parts with ... to not reveal personal details :))
[03:35] <andresj> mm... fixed in 1.2 :)
[03:38] <abentley> andresj: Basically until bzrtools 1.2 gets uploaded, you have to choose between bzr 1.2 and bzrtools.
[03:38] <dle> Hi.  I'm wondering if anyone knows why the version of bzr distributed with Ubuntu 7.04 (Feisty) is stuck way back at 0.15.0?
[03:39] <dle> I do know of the ppa rep., btw.
[03:39] <beuno> dle, because packages don't get updated on final versions
[03:39] <beuno> just security updates
[03:39] <lamont> dle: because feisty hasn't accepted uploads since it released, would be my first guess
[03:40] <abentley> Additionally, feisty is out of date, and not an LTS release.
[03:40] <andresj> And because gutsy is the stable ubuntu now
[03:40] <dle> Mm, good points.
[03:40] <abentley> So backports are unlikely.
[03:41] <dle> I notice that ppa has a nice fresh bzr for fesity but not bzr-svn.
[03:41] <beuno> dle, and, of course, you have ppa's, so it's probably not worj the extra work
[03:42] <beuno> s/worj/worth
[03:42] <beuno> agh, it's late
[03:44] <beuno> poolie, you wouldn't happen to be around, would you?  I was about to mail the list about the "bazaar" package in hardy, and what the chances where that is was bzr == bazaar instead of baz == bazaar
[03:46] <beuno> it's past feature freeze now, but maybe we can still push the change it considering it's LTS. Many people come into the channel wondering why "bazaar" isn't what they expect
[03:48] <lifeless> beuno: we need to patch bazaar to recommend bzr
[03:48] <lamont> beuno: well, if people quit spelling it 'bazaar'.... :-)
[03:48] <lifeless> beuno: as a transition; there was a thread on debian-devel a while back about this.
[03:48] <lifeless> beuno: ideally the entire set of transitions is this:
[03:48] <dle> beuno: Just a few m. ago, I installed bazaar first, before figuring out that it was not bzr.
[03:49] <lifeless> step 1) 'bazaar' source package stops producing 'bazaar' binary, instead produces 'baz' binary. New 'bazaar-meta' source package produces 'bazaar' binary, which depends on both baz and bzr packages
[03:50] <lifeless> step 2) - a release later - the 'bazaar' binary stops depending on 'baz', and starts recommending various additional useful plugins.
[03:51] <beuno> lifeless, and what are the chances that that transition and start for hardy?  I expect Debian to take a bit longer, but considering this is going to be an LTS...
[03:52] <lifeless> beuno: we can definitely do step 1 immediately
[03:52] <lifeless> beuno: possibly depending on bzr and recommending baz would be sufficient, and allow 'bazaar' to be in main with the recommended 'baz' in universe.
[03:53] <db-keen> how do I branch a specific directory from another branch?
[03:53] <beuno> lifeless, sounds great
[03:53] <beuno> db-keen, you can't (yet)
[03:53] <db-keen> that's really killing my enthusiasm
[03:54] <db-keen> is it planned for the near future?
[03:54] <lifeless> db-keen: very few (none) of the modern VCS's support this.
[03:54] <beuno> lifeless, so I can scratch that off my "to-bug" list, or do you want me to file a bug for it?
[03:54] <lifeless> db-keen: in fact we do support it via a two-step process already; but I'd like to understand what you want it for
[03:54] <lifeless> beuno: I'd like you to do it :)
[03:59]  * beuno waits for ubotu to brag about the bug report
[04:00] <db-keen> lifeless: In this particular instance, I was trying to branch just the ruby bindings to a program written in C. I don't care about the C source files, and I'm not going to compile them myself, I only want to modify the ruby side of the bindings
[04:00] <db-keen> why checkout the whole thing?
[04:01] <lifeless> db-keen: generally we'd say that if you want to do that the ruby bindings should be a separate tree
[04:02] <lifeless> db-keen: there are a variety of reasons for this, but at the heart of it we generate a single transaction for each commit at the top of the tree
[04:03] <lifeless> db-keen: being able to work on only a subset of the files is a desired feature; but in terms of network traffic and work-during-commit - neither of those will change at all.
[04:05]  * beuno is off to bed, g'night all
[04:05] <ubotu> New bug: #193576 in bzr ""bazaar" package should point to bzr instead of baz" [Undecided,New] https://launchpad.net/bugs/193576
[04:32] <db-keen> how do I undo bzr add?
[04:33] <db-keen> (I haven't committed yet)
[04:33] <spiv> db-keen: bzr rm --keep
[04:51] <lifeless> poolie: Thats a full day for me, two merge/review requests sent in, 1 branch merged. Stacking moving along well. Tchau.
[04:51] <poolie> lifeless, quick call about this first?
[04:52] <lifeless> sure
[05:34] <jml> does paramiko's log go to .bzr.log?
[05:43] <poolie> jml, no, we need a patch to do that
[05:43]  * jml uses the One True Patch instead
[05:44] <jml> +        import pdb; pdb.set_trace()
[05:44] <poolie> "pp
[05:44] <poolie> in vim
[06:17] <poolie> is it really necessary for bzrtools to refuse to run with newer bzrsL
[06:47] <abentley> poolie: I can't predict what will happen to bzrlib from release to release.
[06:48] <abentley> During the 1.5 release cycle, the requirements for locking changed between different release candidates.
[06:50] <abentley> bzr 1.2 had two API breaks.  How can I predict whether they would have affected bzrtools?
[06:53] <poolie> i think that should be handled by having the new bzr release declare that it breaks bzrtools
[06:53] <poolie> i'm not a debian packaging expert, but i think that would be a better match
[06:54] <abentley> Wouldn't the result be the same?  You still wouldn't be able to install bzr without removing bzrtools.
[06:55] <poolie> it gets you away from making predictions
[06:55] <poolie> you just declare the breakage when it happens
[06:55] <poolie> so there are 3 main cases
[06:55] <poolie> 1- both
[06:56] <poolie> 1- both of them are uploaded about the same time; an upgrade gets you both of them
[06:56] <poolie> 2- there's a lag before getting bzrtools released and packaged, but the old one still works
[06:56] <poolie> 3- there's a lag but the old one is broken
[06:56] <poolie> declaring that it will not work with later versions disallows 2
[06:57] <poolie> i'm talking btw about the debian-level rules
[06:57] <poolie> or that's what i'm looking at now
[06:57] <poolie> i guess you also have a check in bzrtools itself?
[06:58] <abentley> Yes, there are checks in bzrtools itself.
[06:58] <poolie> btw good point about bug priority vs ordering
[06:58] <abentley> Thanks.  I do see your point about case 2.
[07:01] <abentley> I guess my one hesitation about that approach is that it doesn't work in cases where the add-on is not packaged by the same team.
[07:02] <abentley> But if you're willing to test the one-older version of bzrtools with bzr to make sure that it's not broken, we can try it that way.
[07:03] <poolie> well
[07:03] <poolie> i might ask a packaging expert about it firsnt
[07:04] <abentley> Sure.  We'll also want to disable the automatic version warnings for the packaged version.
[07:04] <abentley> poolie: Did you have any further thoughts about moving BB to Canonical hardware?
[07:04] <poolie> if bzrtools will give a warning, then the package should probably warn you too
[07:06] <poolie> so, moving it to the DC will probably have a lot of setup cost
[07:07] <abentley> poolie: If we test that the old bzrtools isn't broken, I think it's reasonable not to warn.  But it's up to you.
[07:07] <poolie> because IS is not really oriented towards running ad hoc apps
[07:08] <poolie> i did have another idea, which was to put it on a vhost somewhere
[07:08] <poolie> do you still think it's a good idea/worth spending time on?
[07:10] <abentley> I think it could reduce the connectivity problems and make the home page load faster, but probably wouldn't address the "aaron just broke it" and "aaron didn't know it was broken" issues.
[07:10] <poolie> right
[07:11] <poolie> so, what fraction of outages do you think each one is?
[07:13] <abentley> In terms of duration, I think "didn't know it was broken" is maybe half of it, with connectivity being another third.
[07:15] <abentley> I break it the most often, but for the shortest length of time.
[07:20] <poolie> so it probably would be worth the trouble to move it?
[07:22] <jamesh> blame turbogears
[07:23] <abentley> I think so, but it's close.
[07:24] <abentley> jamesh: Someone mentioned I should talk to you about the lp: transport, but I don't remember why.
[07:24] <abentley> I've been thinking it makes sense to make it into a straight-up directory service rather than a transport.
[07:24] <jamesh> abentley: that sounds like something lifeless would say
[07:25] <abentley> jamesh: Yes, I think it was him.
[07:25] <Peng> Doesn't bazaar-vcs.org have very restricted access to the server, and don't you guys have problems getting attention from the sysadmins?
[07:25] <jamesh> abentley: and I agree.  The main reason we converted it to a transport was to delay the branch resolution til after get_transport()
[07:25] <jamesh> i.e. when the branch is used
[07:26] <abentley> Oh, good I asked, then.  Why do we need to delay the branch resolution 'till then?
[07:27] <jamesh> abentley: because get_transport() should not block on network access
[07:27] <jamesh> (so I was told)
[07:27] <poolie> Peng, it's fairly tightly controlled
[07:29] <jamesh> abentley: e.g. get_transport('http://example.com/') shouldn't cause a DNS lookup on example.com or attempt to connect to that server
[07:29] <abentley> jamesh: I think we need to revisit that rule, because doing the lookup immediately would reduce the pain of that indirection.
[07:30] <jamesh> and there was apparently a bunch of code that expects get_transport() to be cheap
[07:31] <abentley> Well, I should get some sleep, but let's talk about this again.
[07:31] <jamesh> okay
[07:32] <jamesh> I should be online roughly 2 hours after the other .au guys :)
[08:13] <thekorn> good morning, I've got a problem, I'm using bzr on two different versions of ubuntu (hardy and gutsy)
[08:13] <thekorn> since yesterday's update of bzr in hardy I cannot acces my bzr branches in gutsy anymore
[08:13] <thekorn> it seems the branch format changed
[08:14] <thekorn> is there any way to fix this
[08:16] <poolie> thekorn, the default format for new branches changed
[08:16] <poolie> we shouldn't be automatically updating any existing branches
[08:16] <poolie> you can control it with parameters to init, init-repo, etc
[08:16] <poolie> you probably want --knits
[08:16] <poolie> hth
[08:18] <thekorn> poolie: but automattically changing the branch format is a little bit harsh IMHO
[08:18] <poolie> that's my point, we have not
[08:19] <thekorn> without aksing the user
[08:19] <thekorn> ok
[08:19] <poolie> i have to go now, if you have other questions and no one can answer here, please mail bazaar@lists.ubuntu.com
[08:19] <poolie> night
[08:20] <thekorn> poolie: ok, thanks
[09:49] <awilkins> jelmer: I ran that pull all night and it's finally finished....
[09:51] <awilkins> jelmer: 9250 revisions, pulled 100 at a time. I'm not sure there's a great reduction in size over SVN, this is about 2/3 of a 1.5GB repo and the .bzr tree is 1.3GB
[09:51] <awilkins> And it's only 9250/13000 revisions
[09:52] <awilkins> But hey, it all worked, no KeyError exceptions, wahey.
[10:07] <awilkins> jelmer: Branching it runs the memory use up to 620MB at peak, and a fair chunk of CPU time, but it works too.
[10:17]  * awilkins waits for the interminable sloth that is the NTFS filesystem to finish
[10:22] <jelmer> awilkins: ah, great :-)
[10:22] <jelmer> awilkins: that really sounds like the windows build of python-subversion doesn't actually have that patch applied, btw
[10:26] <matholio> could bzr be used to manage configuration files ?
[10:27] <matholio> I have a handful linux boxen which I want to have identical config files.
[10:31] <mwhudson> uh, do the bzrtools-1.2 debs conflict with bzr-1.2
[10:32] <dato> the package in sid doesn't; I'm not sure what the package in PPA was based on.
[10:45] <awilkins> jelmer: You could be right, I've just downloaded that package and run a binary compare on the one in site-packages and there are some differences.
[10:48] <awilkins> Peng: I've tried to import bzrlib on IronPython 2 alpha 8 but fallen at the first hurdle, it goes into an infinite loop defining a function in trace.py
[10:55] <johnny> does anybody maintain a bzr branch that contains many of the existing plugins? or would that be a bad idea/
[10:55] <matholio> I'm trying to use bzr to manage config files but I'm not sure I have it right.
[10:56] <matholio> first I init a folder : cd /foo/etc; bzr init
[10:56]  * bob2 just did "cd /etc ; sudo bzr init ; sudo bzr add ."
[10:56] <bob2> but then found I didn't actually want to version a lot of them
[10:57] <matholio> bzrignore
[10:57] <matholio> bob once you have commited them how to you use them on another system ?
[10:57] <awilkins> jelmer: I am an idiot ; it's managed 230 revisions using 360MB, which previously would have run it up over 1GB or even popped the stack
[10:58] <awilkins> jelmer: Note to self ; make a list, check it twice.
[10:58] <bob2> matholio: you can copy the .bzr dir to another one
[10:58] <awilkins> jelmer: It's still far from perfect though, 300 revisions has it up over 500MB, something I suspect, is still leaking in htere.
[10:58] <bob2> awilkins: does bzr-svn pack things after the import?
[10:59] <awilkins> bob2: Yes, it just packs as it goes like normal bzr
[10:59] <jelmer> awilkins: That's not necessarily a bzr-svn problem though, may be regular bzr problem given the size of your tree
[10:59] <awilkins> bob2: I've also branched it ; all revisions are now in a single pack and it's still 1.3GB
[10:59] <bob2> ah, ok
[11:00] <awilkins> jelmer: Yes, it could well be ; I'd guess that with CPython being a reference counter they should either find or write some leak detection tools for it :-)
[11:01] <awilkins> bob2: There are a lot of binaries in there so it may well be the nature of the source material
[11:01] <awilkins> Visio diagrams in particular
[11:01] <bob2> ahh
[11:01] <awilkins> jelmer: I think those patches have made it a lot faster too
[11:02] <awilkins> bob2: We've only recently moved to an XML format instead of Visio
[11:29]  * awilkins swears violently because he just deleted his branch by accident instead of the old one that didn't work
[11:29]  * awilkins looks forward to another multi-hour pull from svn :-(
[11:29] <awilkins> Ah well, not like I'm really working on it :-)
[13:22] <awilkins> Woot, I got bzrlib to import on IronPython
[13:23] <awilkins> Any tips on how to make it run the test quite from a python console?
[13:54] <arnarl> I'm getting some "ObjectNotLocked: KnitPackRepository(...path...) is not locked" after I upgraded form 1.0 to 1.2
[13:54] <arnarl> google didn't yield anything interesting
[13:55] <arnarl> anyone know what could be causing this or point me in a direction where I can find out what it is?
[13:55] <Peng> awilkins: Cool. How much work did it take?
[13:55] <fullermd> arnarl: I'd start with plugins.
[13:55] <arnarl> ok
[13:56] <Peng> Oh, good point. arnarl: Try with --no-plugins
[13:56] <Peng> arnarl: .bzr.log may also say something useful.
[13:56] <arnarl> will do, the problem seems to intermittent as it works after a few retries
[13:56] <arnarl> but I probably have some outdated plugins
[13:57] <johnny> how do you folks work with multiple devs on a project who want to use specific sets of plugins?
[13:58] <abentley> awilkins: what commands are producing this error?
[13:59] <abentley> sorry, arnarl: what commands are producing this error?
[13:59] <arnarl> I was trying to run push and push_and_update
[14:01] <awilkins> Peng: Well, I had to patch a module.
[14:01] <awilkins> Peng: But the test suite isn't running because of the platform checks
[14:02] <arnarl> (works without plugins though, so I'm guessing its a problem on my side)
[14:02] <awilkins> Peng: os.platform == 'cli' on IronPython
[14:02] <awilkins> Not sure what it would read on IronPython/Mono (if such a thing exists)
[14:03] <jelmer> I would guess cli as well
[14:03] <jelmer> since mono is technically cli too
[14:03] <awilkins> jelmer: That would be my interpretation, which means you have to answer "does Mono on *nix support the platform features that are checked off) like "signal"
[14:04] <awilkins> Although a first apatch will be to change all == 'win32' to "in ['win32, 'cli'] and run the tests again :-)
[14:04]  * awilkins goes about getting a branch
[14:05] <jdong> >>> platform.system()
[14:05] <jdong> 'cli'
[14:05] <jdong> my os doesn't contain a platform attribute on ipy
[14:06] <jdong> whoa cool, you can call all of .NET from ironpython
[14:06]  * jdong instantiates a System.Windows.Form....
[14:07] <jdong> grr it doesn't take ctrl+D
[14:07] <awilkins> Meh, the 'doze console is lame
[14:08] <awilkins> I always miss ^U
[14:08] <jdong> raise SystemExit seems to be the only way
[14:08] <awilkins> ctrl-Z <enter> should work
[14:08] <jdong> quite a silly way to exit out of a shell
[14:08] <jdong> awilkins: yeah but Linux captures that
[14:08] <awilkins> Doh
[14:08] <jdong> well ctrl+V ctrl+Z enter
[14:08] <jdong> I guess that would work
[14:10] <jdong> nope that is captured too
[14:11] <awilkins> You pythonics would know this : would you expect the answer to "does this class have __getattribute__?" to be true if it didn't have it, but the parentclass did?
[14:12]  * awilkins has submitted a ticket to the IronPython issue tracker because IronPython generates code that doesn't think so.
[14:38] <awilkins> Anyone else getting "Expected a boundary" errors?
[14:47] <grutte_pier> awilkins: to your __getattribute__ question: I would say: yes
[14:48] <grutte_pier> If B is a class derived from A, then the relation 'B is an A' holds
[14:49] <awilkins> That would be my interpreation too ; Liskovs substitution principle n'all.
[14:56] <grutte_pier> however the function hasattr() would work only on an instance of the class, not the class itself i guess
[14:57] <grutte_pier> correction: it works on the class definition itself as well
[15:08] <awilkins> grutte_pier: Oh yes, classes are not quite classes in Python, it's more like JScript (as far as I perceive it)
[15:09] <ubotu> New bug: #193685 in bzr "bzr 1.2.0: MemoryError when file size ~1M" [Undecided,New] https://launchpad.net/bugs/193685
[15:10] <awilkins> Naah, I don't beleive it, it's been versioning 50MB files for me today.
[15:31] <Peng> He's on Solaris. Maybe that platform has some really weird problem?
[15:31] <Peng> Or he has 10 MB of RAM...
[15:37] <schwuk> I'm using the PPA, but I can't install bzrtools:  bzrtools: Depends: bzr (< 1.2~) but 1.2-1~bazaar2~gutsy1 is to be installed
[15:58]  * lamont wonders if folks would like his packaging for bzr/bzrtools for dapper/edgy
[16:02] <schwuk> I'd be happy with bzrtools working for Gutsy (from PPA)
[16:07] <lamont> schwuk: I don't have upload privs  to the ppa, but I'll find someone to fix0r it.
[16:07] <schwuk> lamont: you are a gentleman, sir
[19:38] <jkakar> So, I just committed a revision, tagged it and then uncommitted it, which resulted in the tag being left bound to a revision reported as '?'.  Is this behaviour expected?
[19:38] <jkakar> Or rather, is this a bug?
[19:40] <fullermd> I wouldn't think so.
[19:40] <fullermd> The ? would be because it doesn't have a revno, not being in the current branch ancestry.  Try it with "bzr tags --show-ids", it should show the revid.
[19:41] <Bloguero__Connor> hi, I prepared a patch (using bzr send -o user1code.patch) and send it to another user. How this user should use that file to merge it into his tree?
[19:42] <fullermd> Bloguero__Connor: "bzr merge usercode1.patch".  Or maybe 'pull', if that's the intended use.
[19:42] <Bloguero__Connor> what is the difference beteen merge and pull?
[19:43] <fullermd> The short answer is "pull is for updating a mirror, merge is for merging in someone else's changes to a branch you're developing on"
[19:43] <Bloguero__Connor> fullermd, thanks
[19:52] <luislavena> hi everybody
[19:54] <luislavena> wondered if some of the bzr-svn guys are around?
[19:54] <jelmer> luislavena, hi
[19:55] <luislavena> jelmer: hi there :)
[19:56] <luislavena> jelmer: is true that svn 1.4.7 will include backported patch to make bzr-svn compatible without big hacking?
[19:56] <luislavena> since I'm aware of 1.5, but is a real pain get svn env building on windows...
[19:57] <jelmer> luislavena: No, only 1.5.0 will
[19:57] <jelmer> 1.4.7 will include a memory leak fix, but misses some other changes
[19:58] <luislavena> jelmer: so there will be no chance of getting an official build of python bindings until 1.5
[19:58] <jelmer> luislavena: yes, correct. However, most Linux distributions already include the required changes in their svn 1.4 packages and there are windows builds
[19:59] <luislavena> I'm asking this since every time I tried get svn build on windows, was a real nightmare...
[19:59] <luislavena> and the windows builds link against msvcr80, not the same msvcrt python uses...
[19:59] <jelmer> the one on http://d5190871.u44.websitesource.net/bzr/ ?
[20:00] <luislavena> oh, is up again!, last time I checked was down!
[20:01] <luislavena> who did it? I want to send a big thank you... :)
[20:02] <jelmer> luislavena: Kevin Light is to thank for them :-)
[20:03] <luislavena> jelmer: Oh, I'm so anxious to test it on windows... enjoyed on linux... now I'll be in heaven!
[20:06] <luislavena> jelmer: thank you for the data, the website should be updated with this.. or at least give hosting for the file... :)
[20:07] <jelmer> it's already mentioned on the bzr-svn wiki page
[20:08] <luislavena> jelmer: great, just checked... but I my mouth is faster than my hands... sorry about that
[20:10] <luislavena> is bzr-svn compatible with 1.2?
[20:10] <luislavena> just checking... just to be sure.
[20:10] <jelmer> maybe
[20:10] <ubotu> New bug: #193779 in bzr "bzr+ssh on Win32 dies in paramiko with EOFError" [Undecided,New] https://launchpad.net/bugs/193779
[20:10] <jelmer> I haven't checked yet
[20:11] <luislavena> jelmer: I'll be your guinea pig then...
[20:13] <awilkins> luislavena: jelmer: It seems to be compatible
[20:13] <luislavena> awilkins: thank you for the info :)
[20:13] <awilkins> It managed pulling 1.3GB of revisions.. and some minor pushes
[20:13] <awilkins> Since there are no api deltas between 1.1 and 1.2 (according to changelog) then I would expect it to work
[20:15] <abentley> awilkins: There are two API breaks listed in my copy of NEWS.
[20:16] <abentley> I doubt either would affect bzr-svn, though.
[20:16] <jelmer> awilkins: wow, ok. That would be a first, I think :-)
[20:16] <awilkins> Ah, I see, whoever uploaded the sources didn't relink to the 1.2 changelog
[20:17] <awilkins> Naughty nuaghty
[20:17] <jelmer> bzr has steadily broken bzr-svn each release until now :-)
[20:17] <awilkins> Humph, there isn't even a 1.2 changelog on the same link pattern as 1.1
[20:18]  * awilkins stops trusting the wiki editor
[20:18]  * luislavena agree with awilkins
[20:18] <luislavena> some housekeeping must be done :P
[20:20] <awilkins> THe memory usage in 1.2 is much better than 1.1, it makes bzr-svn almost usable on large trees :-)
[20:22] <foom> nobody updated the summary of new wonderful features in 1.2 either.
[20:23] <jelmer> awilkins: that still surprises me somewhat, none of the entries in NEWS seem related to decreased memory use
[20:24]  * awilkins isn't knocking it
[20:26] <luislavena> mm, is bzr branch supposed to work over password protected svn:// repositories?
[20:26] <awilkins> luislavena: Do a password-required thing with the svn client and cache your auth
[20:27] <awilkins> luislavena: Or use svn+ssh and ssh-agent
[20:27] <foom> (or use svn 1.5 I think jelmer said?)
[20:27] <luislavena> awilkins: already did, but svnserve.conf states "anon-access = none" .. and bzr branch failed
[20:28] <lifeless> moin
[20:28] <luislavena> awilkins: needed to change it to read for it to work... and was working with svn ci and others
[20:29] <lifeless> foom: hi
[20:29] <lifeless> foom: have you filed a bug ? :)
[20:30] <awilkins> Hmm, I agree that bit is a bit flaky.... using 1.5 is out for me until it releases, and also the wider ecosphere of svn tools releases.
[20:30] <foom> lifeless: Nope. But when I retry everything on bzr 1.2 I'll file bugs this time.
[20:30] <awilkins> 1.5 breaks the WC format again, I can't risk fubaring all my Eclipse plugins given that my current project has so many source control automations
[20:31]  * awilkins really wants to use bzr
[20:31] <lifeless> foom: thanks
[20:31] <lifeless> awilkins: 1.5?
[20:31] <awilkins> They do a lot of heinous branching and merging
[20:31] <awilkins> svn 1.5
[20:31] <lifeless> awilkins: oh, right
[20:31] <awilkins> Bah, can't branch bzr.dev from launchpad
[20:31] <awilkins>  Revision {('robertc@robertcollins.net-20070321041435-lyb7a2hxgb1547mj',)} not present
[20:32] <lifeless> we're correcting that at the moment
[20:32]  * awilkins is thankful
[20:32] <awilkins> does 1.2 work?
[20:32] <lifeless> we had a unreconciled repository floating around. bad booboo
[20:33] <awilkins> I just want to start trying to patch it up to support IronPython better
[20:36] <awilkins> Does launchpad support putting branches in a shared repo with the originating projec tyet?
[20:36] <luislavena> awilkins: tried what you said aboud anon-access and auth for a repo... bzr branch still yell at me...
[20:37] <luislavena> awilkins: I need to set anon-access = read in svnserve.conf for the repository so bzr can access it... even that authentication is being stored in subversion.
[20:37] <lifeless> awilkins: oh hmm, bzr.dev should be fine
[20:37]  * luislavena is using a copy of the server with svnserve (subversion smart server)
[20:38] <lifeless> awilkins: awilkins can you try branching bzr.dev from http://bazaar-vcs.org/bzr/bzr.dev please.
[20:38] <awilkins> lifeless: No probs
[20:39] <luislavena> jelmer: this should be a problem of python bindings or bzr-svn?
[20:39] <luislavena> bzr branch svn://localhost/repo/trunk repo-trunk output:
[20:39] <luislavena> bzr: ERROR: Permission denied: ".": Can't get password
[20:39] <awilkins> lifeless: I was using the lp:bzr link before
[20:42] <jelmer> luislavena: what version of the bindings and bzr-svn are you using?
[20:43] <lifeless> awilkins: it worked ok ?
[20:43] <luislavena> jelmer: the bindings indicatd in the BzrSvn wiki page and the bzr-svn package from there too (0.4.7)
[20:44] <jelmer> luislavena: this is a windows-specific issue in bzr-svn, which has been fixed in the development branch
[20:44] <awilkins> lifeless: It's still going
[20:44] <awilkins> I only have 2MBit/s bandwidth here
[20:44] <jelmer> luislavena: however, the development branch has some severe performance regressions atm
[20:45] <luislavena> jelmer: no problem, I can live with the anon-access issue for the time being :)
[20:45] <luislavena> jelmer: wanted to know before submit a bug report...
[20:45] <luislavena> don't want to waste your time or any other developers with duplicated bugs.
[20:46] <awilkins> lifeless: Same error
[20:47] <awilkins> lifeless: I'm branching inside a --rich-root-pack repo, is that effecting it?
[20:48]  * awilkins tries outside in a fresh folde
[20:48] <lifeless> awilkins: that will be causing it to rewrite the data; and I know there are bugs in that rewrite process
[20:50] <awilkins> Heh, different error in clean folder
[20:50] <awilkins> bzr: ERROR: Could not install revisions:
[20:50] <awilkins> pqm@pqm.ubuntu.com-20080220014008-9appc9kw4rjg8v1k
[20:51] <lifeless> doing bzr branch http://bazaar-vcs.org/bzr/bzr.dev test-bzr
[20:51] <lifeless> just worked for me
[20:51] <lifeless> do you have a web proxy?
[20:52] <lifeless> actually, just try again, we may have raced with each other
[20:52] <awilkins> There is a transparent proxy here, ISP flavoured
[20:52]  * awilkins goes
[20:54] <lifeless> it shouldn't be an issue actually
[20:54] <lifeless> we've made our primary files cacheable
[20:54] <awilkins> Looks healthier so far
[20:54] <awmcclain> Hi all.. I'm transitioning my team from SVN to bazaar. I'm looking to split up our current SVN trunk into a few sub branches in the bzr repo. I'm trying to make branching as painless as possible. Is there a way to export, say, just the last 30 revisions of an SVN directory into a new bzr branch?
[20:59] <awilkins> lifeless: Branched 3228 revision(s).
[21:01] <awilkins> lifeless: And trying to branch it into a --rich-root-pack repo produces the robercollins error
[21:03] <awilkins> lifeless: Trying the same with a pack0.92 repo works fine
[21:11] <lifeless> awilkins: please file a bug; not sure where the fault lies
[21:25] <ubotu> New bug: #193804 in bzr "Branching bzr.dev to rich-root-pack causes error" [Undecided,New] https://launchpad.net/bugs/193804
[21:29] <abentley> awilkins: You realize your changes won't be mergeable if you do them in a --rich-root-pack repository?
[21:31]  * awilkins is now using pack0.92 because you can't branch to a rich-root-pack anyway
[21:50] <ubotu> New bug: #193814 in bzr-svn "find_repository on local disk does network traffic" [Undecided,New] https://launchpad.net/bugs/193814
[21:54] <jelmer> lifeless: Stop reading my mind!
[21:54] <jelmer> I was five seconds away from committing a fix for that bug when you filed it :-)
[21:54] <fullermd> He doesn't need to _stop_; he just needs to do a better job of it   :p
[21:55] <bob2> or read the fix out of your mind, too
[22:04] <lifeless> jelmer: :)
[22:04] <lifeless> jelmer: it just makes you look responsive :)
[22:17] <igc> mornng
[22:35] <boolegue> hello
[22:37] <boolegue> anybody to answer question ?
[22:43] <awilkins> No, we're all dead
[22:43]  * awilkins moulders
[22:44] <boolegue> do dead answer bzr question ? ^^
[22:44] <dato> boolegue: just ask your question and stay around for a while
[22:44] <boolegue> ok
[22:48] <boolegue> I renamed and moved to a different directory a file that was versioned, now I want to tell bzr about this and used bzr mv oldfile newfile
[22:48] <boolegue> but it fails
[22:48] <awmcclain> I'm looking to split up our current SVN trunk into a few sub branches in the bzr repo. I'm trying to make branching as painless as possible. Is there a way to export, say, just the last 30 revisions of an SVN directory into a new bzr branch? (sorry about the repost, my internet died since I asked earlier)
[22:49] <boolegue> I get something like bzr: ERROR: Could not rename newfile => oldfile is not versioned.
[22:49] <dato> boolegue: try `bzr mv --after oldfile newfile`
[22:50] <boolegue> -- after dont 't improve things
[22:50] <boolegue> same result
[22:50] <boolegue> but bzr status tells oldfile has removed
[22:51] <boolegue> as removed
[22:51] <bob2> did you run "bzr mv --after filename directory/filename"?
[22:51] <boolegue> I used full relative paths
[22:53] <bob2> did mv say anything?
[22:53] <boolegue> something like bzr: ERROR: Could not rename newfile => oldfile is not versioned.
[22:54] <bob2> does "bzr status" show the file as newly added, in it's new location?
[22:55] <boolegue> I tried without and with newfile added to bzr, same result
[22:55] <bob2> oh, is the dir added?
[22:55] <fullermd> The simple answer is just mv it back to the old location, then bzr mv it to the new.
[22:56] <fullermd> (that doesn't necessarily do much to answer "why isn't it working as-is, which it should", but it does get you to Point B)
[22:58] <boolegue> actually, with newfile versioned, I get bzr: ERROR: Could not move olfile => newfile: newfile is already versioned.
[22:59] <boolegue> by versioned here I mean added
[22:59] <fullermd> Yeah, you don't want to do that.
[23:01] <boolegue> I am using version 1.1 on os x 10.5.2
[23:06] <boolegue> looks like adding the new directory but not its content worked
[23:06] <boolegue> with bzr add --no-recurse
[23:07] <bob2> "bzr mkdir" is handy, too
[23:07] <boolegue> but status shows oldfile as removed, is it normal ?
[23:08] <bob2> it should only show up in "renamed:"
[23:09] <boolegue> it doesn't :-/
[23:09] <boolegue> oldfile is removed and newfile is added, status said
[23:10] <bob2> fullermd's right, mv it back to it's original location, then "bzr mv oldfile newdir/newfile"
[23:11] <boolegue> ok but I have actually about 100 files !
[23:12] <bob2> did their filenames change or just their location?
[23:12] <boolegue> both
[23:12] <boolegue> a painfull task without bzr helping
[23:13] <bob2> well, you'll need to run "bzr mv --after oldfilename dir/newfilename" the same way you ran the original bzr mv
[23:18] <bob2> hm, maybe vcs-load-dirs would be the way to go
[23:18] <bob2> or reverting and starting over (all the mvs would at least be in your shell history)
[23:19] <boolegue> after doesn't change anything
[23:20] <boolegue> but wait, now even bzr mv isn't working while it was 5 minutes ago after adding the newdir only
[23:21] <bob2> oh, you need to "bzr rm --keep" hte incorrectly "added" ones first
[23:21] <boolegue> I don't get it
[23:21] <boolegue> I did
[23:22] <boolegue> the new dir and file is reported as unknown
[23:23] <fullermd> The dir needs to be known.  You can't add a file inside a non-added dir, or move a file into a non-added dir.
[23:24] <boolegue> that seems intuitive, is --no-recurse the right option ?
[23:24] <bob2> yes
[23:27] <boolegue> ok so how about I revert to the old source tree, then bzr mv, then replace the tree with actual tree (newdir/newfile is a modified oldfile)
[23:27] <boolegue> ?
[23:31] <johnny> how do you guys handle sharing a set of plugins among a project with multiple users?
[23:34] <lifeless> poolie: yesterday I said:
[23:34] <lifeless> 15:51 < lifeless> poolie: Thats a full day for me, two merge/review requests sent in, 1 branch merged. Stacking moving along well. Tchau.