[00:00] <jonoxer> http://pastebin.com/d3b0caad4
[00:01] <jonoxer> I've seen references to a couple of other tools that specifically do repo conversion, but not found the scripts themselves (docs point to defunct pages, etc)
[00:02] <lifeless> 32 or 64 bit python build ?
[00:03] <jonoxer> 32
[00:03] <lifeless> ok
[00:03] <jonoxer> Aha, I hadn't thought of that
[00:03] <lifeless> so, it physically can't fill swap to run out of memory
[00:03] <lifeless> it could be
[00:03] <lifeless> a) some form of fragmentation; in which case continuing from where it left off may work
[00:04] <lifeless> b) a single object too big to handle (we currently require any single text to be < ~1/3 usable memory)
[00:04] <jonoxer> Mmm, I'll give it a try on a 64 bit machine
[00:04] <lifeless> c) a bug
[00:05] <jonoxer> It'll take half the day to find out if that helps though!
[00:05] <lifeless> jonoxer: I'd try continuing in the first instance
[00:06] <lifeless> jonoxer: did you run 'bzr branch' ?
[00:06] <lifeless> jonoxer: if so, cd to the output dir, run 'bzr reconfigure --branch', then 'bzr pull svn://.....'
[00:06] <jonoxer> lifeless: problem is I don't know what commit it failed on. The progress bar vanishes when it does the traceback, and unless I was looking at that exact moment I wouldn't know. Is there a way to find out?
[00:07] <lifeless> jonoxer: you don't need to know :P
[00:07] <jonoxer> Ahh, I see
[00:08] <lifeless> thats the sort of housekeeping bzr is meant to do for you
[00:09] <Peng_> In the future, you could also set up a loop to pull, say, 1000 revisions at a time.
[00:10] <jonoxer> Woot! It started again, and thinks it only has 8435 revs to pull, so it must be going from the point it died. Thanks lifeless
[00:10] <jonoxer> Peng_: good idea
[00:10] <spiv> jonoxer: if you're not already doing so, you could try running the latest bzr-svn release.  I think some major memory leaks have been fixed.
[00:11] <spiv> jonoxer: did you figure out your problem from Friday?  (file permissions?)
[00:11] <Peng_> That's right. (The leaks were more svn's fault than bzr-svn's, but in any case, the situation has been improved with svn 1.5 or the latest bzr-svn release.)
[00:12] <jonoxer> spiv: not yet, the sftp error was a good clue but I was away in Sydney on the weekend shooting a new TV show (lots of fun) and just got home at 1am today, so I haven't had a chance to try again yet
[00:15] <lifeless> poolie: you've marked 282402 as invalid; I don't think its invalid - its just a faulty try:finally: rather than a try:finally:except: block on WT.commit.
[00:15] <poolie> bug 282402
[00:16] <lifeless> poolie: this may have contributed to other commit bugs, where exceptions damaged the dirstate
[00:16] <poolie> are you sure?
[00:16] <lifeless> mutabletree.py has @needs_write_lock\ndef commit(...)
[00:17] <lifeless> I think that should be altered to call
[00:17] <lifeless> (looking for method name)
[00:17] <lifeless> uhm, I think its self._reset_data()
[00:17] <lifeless> in the event of an exception
[00:19] <lifeless> poolie: I am sure that we shouldn't save changes to the dirstate if the commit is cancelled; I'm reasonably sure the same applies to errors
[00:19] <poolie> yes, you're right
[00:45] <davidstrauss_> I have a question about the "decentralized with shared mainline" workflow. After branching, it seems like "bzr commit" would only be local, but the diagram on the workflows page shows "bzr commit" going back to the central repository.
[00:45] <davidstrauss_> Is there a page with clearer documentation of the workflow?
[00:55] <spiv> aaaa
[00:57] <spiv> davidstrauss_: well, if the users have a checkout of the shared mainline (in addition to their other branches), then commit in that would go back to the central location.
[01:17] <davidstrauss_> spiv: But what if it's a branch?
[01:17] <lifeless> davidstrauss_: the point of a branch is not to flow back automatically
[01:17] <davidstrauss_> http://bazaar-vcs.org/Workflows#head-ca3ccf73574776b36453b2213789731549e54167
[01:17] <davidstrauss_> lifeless: yes, but what's the proper way to send your changes back from your branch to the shared mainline?
[01:18] <lifeless> davidstrauss_: have a checkout of the mainline; merge your changes and commit
[01:18] <lifeless> davidstrauss_: (which is exactly what a maintainer of a non-shared mainline would do, but you're able to do it yourself because its shared)
[01:26] <lifeless> why does bzr.dev only have an IMPROVEMENTS section in NEWS?
[01:33] <davidstrauss_> Is there a way to have Bazaar default to local commits?
[01:41] <lifeless> davidstrauss_: I am going to guess that you're trying to avoid having both a branch and a checkout of the mainline
[01:42] <davidstrauss_> lifeless: yes
[01:42] <lifeless> davidstrauss_: probably because of disk space used/wanting to reuse build products
[01:42] <davidstrauss_> lifeless: no, it's mostly an interest in limiting complexity
[01:42] <lifeless> davidstrauss_: anyhow, 'bzr unbind' will temporarily convert a heavyweight checkout to a regular branch
[01:42] <lifeless> just 'bzr bind' will restore the binding
[01:43] <lifeless> myself, I'd use a single working tree but still have two branch objects, because its handy when offline to be able to see exactly what the mainline looked like
[01:52] <davidstrauss_> lifeless: thank you. your comments really help develop my team's bazaar workflow
[01:53] <lifeless> davidstrauss_: my pleasure
[01:56] <davidstrauss_> lifeless: What is the process for improving this documentation on the Bazaar website?
[01:56] <lifeless> davidstrauss_: I believe that that page is versioned in the bzr tree, in doc/ somewhere
[01:56] <davidstrauss_> ok
[01:57] <lifeless> davidstrauss_: *if* it is, then a patch to that. If its not, then edit the wiki page directly/mail the list if you are not sure you'd be improving it :>
[01:59] <ferringb> lifeless: don't suppose you know what gurantees there are for revision_history()?  specifically ordering of the resultant sequence?
[01:59] <lifeless> ferringb: Branch.revision_history ?
[01:59] <ferringb> yep
[01:59] <lifeless> ferringb: its strictly the left hand history
[01:59] <ferringb> ok
[02:00] <lifeless> ferringb: its a bad api to use though -
[02:00] <ferringb> alternatives?
[02:00] <lifeless> -Devil will report on its use
[02:00] <lifeless> ferringb: Repository.get_graph()
[02:00] <ferringb> guessing that's not just left hand?
[02:01] <lifeless> ferringb: there are various other alternatives; what are you doing, perhaps I can be more specific :P
[02:01] <ferringb> trac-bzr
[02:01] <lifeless> timeline view?
[02:01] <ferringb> among other things
[02:01] <lifeless> so the graph object returned should have enough methods on it
[02:01] <lifeless> but there are also iter_ methods on branch and repository
[02:02] <ferringb> one thing I was playing with for speed reasons was pulling revision_history, finding the rev from the inventory object I get file path2id, then limiting the revs I inspect for changes via starting at that rev
[02:02] <ferringb> don't suppose oyu have a specific method to recommend in that case?
[02:03] <lifeless> well
[02:04] <lifeless> iter_revision_deltas should be solid
[02:04] <lifeless> but the basic speed problem is deep within bzrlib
[02:04] <ferringb> heh.  my next question was going to be "how fast is it" ;)
[02:04] <lifeless> the inventory representation is not conducive to fast delta generation
[02:04] <lifeless> see log -v for instance
[02:04] <lifeless> anyhow, I'm working on that at the moment, in my repository branch
[02:05] <ferringb> yeah, I skanked my current code out of log -v's implementation actually
[02:05] <ferringb> then got bit by the lefthand nature of revision_history
[02:06] <ferringb> aside from loggerhead, any other sources you're recommend (alternatively api walkthroughs rather then docs)?
[02:06] <ferringb> *you'd.  english and I are not getting along it seems
[02:08] <lifeless> log -v and loggerhead are likely the most tuned things around today
[02:08] <lifeless> oh
[02:08] <lifeless> bzr-search too
[02:09] <lifeless> bzr-search has some stuff thats ten times faster than regular bzrlib
[02:09] <ferringb> delta searching, or
[02:09] <lifeless> it generates multiparent deltas on every revision to determine what to index
[02:10] <ferringb> denormalizes it into a cache I'm guessing
[02:10] <lifeless> nope
[02:21] <Peng_> Oh, you rebased the 'repository' branch?
[02:22] <lifeless> Peng_: huh?
[02:22] <lifeless> Peng_: don't think so, previous work was merged
[02:23] <Peng_> Eh. I just pulled it (for the first time in like a year), and there are removed revisions.
[02:23] <lifeless> Peng_: do you mean the revno has dropped ?
[02:24] <lifeless> Peng_: if so thats just because it had run way ahead of bzr.dev's revno, and when bzr.dev merged it, and I pulled back, we're back along with bzr.dev's revnos.
[02:25] <Peng_> Oh. If you pulled back from bzr.dev to it, that messes with what's on the left-hand side of the graph or whatever the term is, right?
[02:25]  * Peng_ shrugs.
[02:26] <lifeless> Peng_: if I had rebased you would have had a diverged-branches message
[02:27] <Peng_> Oh. Right. Sorry, my mistake in using the wrong term.
[02:29] <jonoxer> spiv: I've done more testing to figure out the permissions problem, and I'm stumped. Unless the repo is owned by the user doing the push it just won't work. Even with the user in the correct group and "chmod -R 775 repo" done. It's like bzr+ssh and sftp methods are ignoring group membership.
[02:29] <jonoxer> I'll see if I can get any more clues
[02:29] <Peng_> Isn't there an OpenSSH bug about ignoring group ownership or permissions or something?
[02:30] <lifeless> jonoxer: openssh's sftp-server ignores the sticky bit
[02:30] <Peng_> ...What he said.
[02:30] <jonoxer> Aha, that sounds exactly like the problem
[02:30] <lifeless> more specifically
[02:30] <lifeless> it masks it out on chmod() calls made over the wire
[02:33] <jonoxer> Any good / bad experiences with vsftpd? Any particular suggestions for an sftpd to use for a bzr repo?
[02:34] <lifeless> jonoxer: bzr+ssh should work though, because sftpd isn't involved
[02:34] <jonoxer> lifeless: that seems to exhibit the same problem, but I'll try again with a clean setup in case I've broken things with all my mucking around
[03:28] <jonoxer> Success: starting from scratch with a clean repo and setting group write perms and the sticky bit makes bzr+ssh work for me   :-)
[03:28] <jonoxer> thanks lifeless
[03:28] <bob2> for an ldap account?
[03:29] <jonoxer> That test used local users, I'll test now with LDAP users...
[03:30] <jonoxer> ...and it works
[03:33] <lifeless> my bet: sftp borked the sticky bit, then you tested bzr+ssh after and it was already broken
[03:34] <jonoxer> lifeless: certainly plausible
[03:34] <jonoxer> This'll work nicely anyway, since all the devs are already in LDAP
[03:34] <arjenAU> jonoxer: horay!
[03:36] <spiv> jonoxer: excellent
[03:36] <jonoxer> To ease the svn-bzr transition I'm thinking of doing something like the discussion above with a shared mainline and personal branches. That way devs can operate the mainline the same way we currently use svn, with their branches giving the added bzr flexibility
[03:36] <poolie> hm, vila has no valid gpg key?
[03:41] <spiv> jonoxer: sounds good
[03:41] <jonoxer> I don't want to change their workflow too much in one go so if I can swap out svn for bzr and just tell them "instead of svn commit, from now on do bzr commit" etc that's step 1. Then getting them working in personal branches and merging to mainline is step 2, etc
[03:47] <poolie> hm so apparently there is no way at all to persuade gpg to trust me just a bit
[03:47] <poolie> short of patching it i suppose
[03:48] <lifeless> poolie: how to do you mean?
[03:48] <poolie> to encrypt to an expired key
[03:48] <lifeless> poolie: is it your key?
[03:48] <poolie> it's vila's key
[03:48] <lifeless> yah no
[03:48] <lifeless> he has to update the expiry date and resign it
[03:48] <poolie> he'll just have to wait til he makes a new one
[03:49] <poolie> can you renew it?
[03:50] <lifeless> I'm pretty sure he has to do it
[03:55] <poolie> heh, 'you'!=you
[03:55] <poolie> i meant, i was wondering if it's possible for the owner to renew an expired key, not would you please do it for me :)
[03:56] <poolie> and yes you can > http://www.gnupg.org/gph/en/manual/c235.html#AEN328
[03:57] <lifeless> oh yes, owners can
[03:57] <lifeless> thats why  I said he has too :>
[03:58] <lifeless> to
[04:10] <poolie> you should now be able to get to kerguelen btw
[04:10] <poolie> except that i have two sessions open
[04:48] <jonoxer> I've started writing a little "svn to bzr without pain" guide as I work through things. It's not really about the tech aspects of moving repos, more about the process of replacing one workflow with another. Rough beginning here: http://jon.oxer.com.au/svntobzr/
[04:48] <jonoxer> I'll flesh it out / fix things as I go. Maybe eventually it'll be useful to someone
[05:12] <lifeless> jonoxer: cool
[05:13] <jonoxer> lifeless: It might sound backwards, but I actually find it good to write docs while I'm trying to figure things out rather than later when I'm an "expert" and have too many subconscious assumptions
[05:20] <lifeless> jonoxer: you only learn something once
[05:20] <poolie> jonoxer: that's a great idea
[05:21] <teratorn> jonoxer: no I reckon that's pretty smart... I have a theory that the people most knowledgeable about a piece of software are often the least capable of understanding what new users need in terms of documentation
[05:21] <poolie> overall what are you finding good or bad so far?
[05:23] <jonoxer> poolie: I haven't found anything inherently bad so far, all the badness I've experienced has been related to migration. I'm coming to BZR with a lot of baggage (mental and infrastructure) to convert
[05:25] <jonoxer> The good is definitely slick branching/merging. Other things like having full local history are nice, but I haven't felt the benefits yet
[05:29] <lifeless> poolie: NEWS is a little odd at the moment
[05:29] <lifeless> poolie: its missing all the normal sections
[05:29] <poolie> because i added a main heading but no sections?
[05:29] <lifeless> yah
[05:30] <lifeless> I think its likely to promote merge conflicts; and it definitely won't work with my auto editing script
[05:34] <lifeless> poolie: its also very confusiong
[05:34] <lifeless> poolie: because - do I use API BREAKS
[05:34] <lifeless> or CHANGES
[05:34] <lifeless> or INTERNALS or what
[05:34] <lifeless> I don't know what the current intended sections are anymore
[05:34] <poolie> they're different things
[05:35] <poolie> how would having the headers help if you don't know what they mean? :-)
[05:35] <lifeless> I would have a menu
[05:35] <lifeless> all the headings are approximations anyhow; there was a thread about reducing them recently
[05:36] <lifeless> as it is I'm grovelling through the file to find what was used 'recently' and hoping its correct
[05:37] <poolie> anyhow
[05:37] <poolie> API breaks are things that will break plugins (etc) currently using the api
[05:37] <lifeless> poolie: uhm, I do know what an API BREAK is
[05:37] <poolie> INTERNALS similar but without implying the code will break - eg when it's deprecated
[05:38] <lifeless> poolie: but as far as I can tell we now call them 'api changes'
[05:38] <poolie> CHANGES are things that users need to know about - fe that there's a new format or a default has changed
[05:38]  * lifeless thinks poolie has missed lifeless' point
[05:38] <lifeless> I know what should be included under each header
[05:40] <poolie> you asked "do i use ... or what"
[05:41] <lifeless> poolie: there are N headers in used through NEWS
[05:41] <lifeless> and M < N that we have decided to use
[05:42] <lifeless> I need to determine which of the N headers are members of M to determine the menu that I have available to categorise my change.
[05:42] <lifeless> poolie: but this whole conversation is moot; I've stabbed in the dark and review can catch it. What I'd like is for us to always include all the sections when a new version is opened.
[05:59] <Peng_> That is usually done.
[05:59] <Peng_> It didn't always used to be, but I think it has for the last few releases.
[05:59] <lifeless> Peng_: define 'it' please
[06:00] <Peng_> :P
[06:00] <Peng_> Including all of the sections when adding a new version to NEWS.
[06:00] <lifeless> ah yes
[06:01] <poolie> i'll just do it now...
[06:01] <lifeless> poolie: thank you, I'd really appreciate that
[06:02] <Peng_> Oh, I don't think it has always been done recently.
[06:03] <Peng_> Or maybe annotate is just confused.
[06:04] <lifeless> Peng_: cat -r would be the easiest way to tell
[06:04] <lifeless> Peng_: annotate will be confused, because the headers are not unique
[06:04] <Peng_> I was gonna use annotate to see which -r to cat.
[06:08] <poolie> lifeless: i see a thread where I suggested creating the headings at the start of the release ;-)
[06:08] <poolie> i don't see any discussion of which headings should be there
[06:08] <poolie> um
[06:08] <lifeless> poolie: cool, consider this a + 1 :P
[06:08] <poolie> i just didn't do it
[06:08] <lifeless> poolie: I felt the previous conversation was angsty
[06:08] <lifeless> poolie: and I didn't mean for that
[06:08] <poolie> agree on both counts
[06:09] <poolie> anyhow..
[06:09] <poolie> i think the main point of them is so that people know how far through the file they ought to read - whether they're a user, a developer, etc
[06:10] <lifeless> poolie: the script I am writing, to autoupdate NEWS, can be simpler if it doesn't need to understand 'dev area' vs 'rest of file'
[06:10] <lifeless> poolie: that is, if it can just look for the first matching header
[06:10] <poolie> i'm saying that i do consider the ordering of headers to matter
[06:10] <poolie> they shouldn't just be alphabeticalized
[06:10] <lifeless> poolie: agreed, I don't think they should be either. I think the items should be alpha though
[06:11] <poolie> unless of course we add numeric prefixes or something to let that work
[06:11] <poolie> the items within each category, sure
[06:11] <lifeless> poolie: so my intent with the script is to never create headers
[06:11] <lifeless> poolie: which avoids the ordering of headers question
[06:11] <poolie> would it help if i made them more verbose, like "user-visible changes"?
[06:11] <lifeless> poolie: it might help readers
[06:11] <poolie> will there be no headers, or will they come from somewhere else?
[06:12] <lifeless> poolie: I want the headers to be seeded by the RM
[06:12] <poolie> i was also thinking of helping developers know where to put their news
[06:12] <poolie> ok
[06:12] <lifeless> poolie: then the script just inserts items under a header
[06:12] <poolie> how does the script know where to file them?
[06:12] <lifeless> the items will be (section, content) tuples
[06:15] <lifeless> so it just has to scan for the header matching section
[06:15] <lifeless> then scan for an item that comes after content, or the end of the section
[06:15] <lifeless> and insert there
[06:16] <poolie> lifeless, http://paste.ubuntu.com/56894/
[06:17] <lifeless> poolie: the remote change seems unrelated
[06:17] <poolie> it is
[06:18] <lifeless> poolie: the headers list is ok, I do feel we perhaps have too much granularity; but thats a separate discussion
[06:26] <lifeless> spiv: I haven't seen your patch to usertest; is it my eyesight?
[06:44] <poolie> meow
[07:02] <mlh>  jonoxer: you want setgid not sticky to preserve group
[07:02] <mlh> chmod g+s ...
[07:05] <jonoxer> mlh: oops, yes, corrected in my local copy (along with some other things about repo creation)
[07:07] <jonoxer> Thanks
[07:10] <vila> hi all
[07:16] <mlh> jonoxer: you may have this fxed too, but you'll need chmod -R g+wX MyRepo (note additional uppercase X meaning do x if x for user otherwise not)
[07:32] <lifeless> wow
[07:32] <lifeless> thats quite a difference
[07:32] <lifeless> real    0m5.555s
[07:32] <lifeless> real    0m3.006s
[07:32] <jonoxer> mlh: that sounds reasonable. I didn't need it (AFAIK only write privs matter in the repo, other than execute on dirs of course)
[07:36] <lifeless> poolie: I'm done for the day
[07:51] <Peng_> What's the 5.5 -> 3.0 second difference?
[07:52] <lifeless> see the list
[07:57] <Peng_> Oh! Cool. Thanks.
[08:05] <sabdfl> lifeless: is that split inventory work trunked?
[08:17] <mwhudson> sabdfl: no
[09:12] <lifeless> sabdfl: most of it isn't, its not suitable for trunk yet - still developing good answers and designs; every bit that is solid is in trunk or in review for trunk
[09:21] <poolie> hey vila, sabdfl
[09:25] <sabdfl> howdy
[11:02] <Kamping_Kaiser> hi all. i'm using bzr 1.5 on debian lenny, and its crashing trying to branch from launchpad. coudl someone look at this ( http://paste.debian.net/19120/ )and let me know if i should be filing a bug. (i see dbus/x11 errors, so itsprobably relevent that i'm trying to use it via ssh)
[11:07] <luks> Kamping_Kaiser: looks like the dbus plugin is broken, try to uninstall it
[11:11] <Kamping_Kaiser> luks: i'm trying it out, i'll let you know if it works
[11:11] <Kamping_Kaiser> i'll also try removing the gtk plugin
[11:11] <luks> that shouldn't be necessary
[11:11] <luks> just the dbus one
[11:13] <Kamping_Kaiser> luks: removing the dbus plugin makes the checkout work, thanks. i'll check debians bts
[11:19] <Kinnison> Anyone here use/work-on the loom plugin?
[11:20] <Kamping_Kaiser> luks: thanks for the help, i'll file a bug with debian - should i also file one in launchpad?
[11:21] <luks> Kamping_Kaiser: I don't know, it's likely it's already fixed in the latest version
[11:21] <Kamping_Kaiser> luks: roger.
[13:45] <gorgapor> although it's a know problem, can anyone suggest a workaround to the permissions issues with bazaar+sftp? right now we have a cron job going in and fixing the permissions every minute, which seems to me like an ugly hack
[13:46] <bob2> is using bzr+ssh an option?
[13:48] <gorgapor> well, all of our developers have ssh access to the server, is the setup on the client end any different?
[15:37] <james_w> jelmer: hey, there are a few duplicates of bug 271636 coming in from apport, do you know what the issue is going to be?
[18:34] <gour> hi, short question...how is bzr good in keeping binary files? (i'm thinking to put my wammu's with phonebook entries under vcs)
[19:42] <Peng_> gour: Sure, why not?
[19:43] <Peng_> gour: Remember that compressed formats like JPEG won't compress well and may delta badly, so you might waste some disk space, but it's not like anything will explode.
[21:40] <arjenAU> hmm
[21:41] <arjenAU> adding a tag on its own is not regarded as a change?
[21:41] <arjenAU> had to to commit --unchanged to get it pushed
[21:47] <jam> arjenAU: I think doing "bzr push" will push it anyway, even though it says "nothing to push"
[21:47] <arjenAU> jam: look that's not shiny ;-)
[21:47] <arjenAU> so I just made an empty commit for it. but that's not pretty either
[21:52] <Peng_> Yeah, new tags will be pushed even if it says "Nothing to push".
[21:52] <Peng_> Tags are unversioned, and pushing/pulling them is a bit messy.
[21:52] <Peng_> IMO, they feel rather tacked on.
[22:21] <lifeless> jam: ping
[22:21] <lifeless> jam: I wonder if you saw my repository stats mail; I know you have been doing repo size analysis ..
[22:22] <arjenAU> Peng_: well here's the thing. while launchpad recommends branching for a release, it's actually just as sane to tag it. thats actually how mysql used to do it with bitkeeper and it works very well. easy to find, easy to use.
[22:33] <lifeless> poolie: I've stopped the usertest run that was going... 7.5G    work_root_for-bzr.inv-branchAndFix
[22:33] <lifeless> I'll either have a faster fetch up today, or remove the 'inv' flavoured tool for now
[22:33] <poolie> hey lifeless
[22:34] <poolie> do you want to reenable the cronjob?  i put in a mutex
[22:34] <lifeless> great, doing so
[22:34] <lifeless> will they backlog or just exit early?
[22:34] <lifeless> [crontab reenabled]
[22:49] <jam> lifeless: my analysis was done by looking at the output of -Dhpss and determining how many bytes were transferred after .iix, not exactly what you are looking for
[22:50] <lifeless> jam: oh! ok
[23:22] <mlh> what's a PPA?
[23:23] <beuno> personal package archive
[23:23] <beuno> archive for .deb files
[23:23] <beuno> which Launchpad provides
[23:24] <mlh> thanks beuno
[23:24] <beuno> :)