[08:10] morning [08:11] hi === zyga is now known as zyga-food === zyga-food is now known as zyga [14:39] james_w: ping, around ? [14:50] vila, yep [14:51] james_w: I'd like to have a ppa on ~udd to replace ~vila/+archive/pkgimport but I'm not an udd admin :) [14:52] vila, you are now [14:52] thanks [14:53] james_w: wow, and jam too, you're reading my mind or was that from someone else ? [14:57] vila, i saw your comment elsechannel [14:57] you rock ;) [15:59] hi - when i do 'bzr merge someothertree' it quilt pops all patches. then doesn't re-push them. is there any reason not to simply quilt push -a again before checking in? [16:00] (i was surprised it didn't do it autmoatcially, figured ther emight be a reason :) [16:08] I'm trying to find a (performant) way to find all the heads in a repo. I'm actually looking for loose ends after a "uncommit" or "pull --overwrite" [16:09] I went with repo.get_graph().heads(repo.all_revisions()) ... but that takes quite some time to complete [16:22] weigon: there is something slightly faster I think [16:31] jelmer: I wonder how the revisions are indexed and if that can be utilized [16:32] weigon: any access to the revision graph should already use just the indexes afaik [16:43] jelmer: any idea how to speed it up? [16:56] weigon: check out what 'bzr heads' does [17:16] jelmer: *doh* it is all there ... [17:16] jelmer: thx === r0bby is now known as robbyoconnor [20:07] maxb: you're still occasionally contributing to the bzr package, should I consider you one of its maintainers? === mbarnett` is now known as mbarnett [23:20] Can I convert a branch of an lp:project in a local repo, to a stacked one so I can save space, but without re-branching? [23:21] are you using shared repositories? [23:21] thumper: I think so, yes [23:22] you mean if the branch is in a directory where init-repo has run? [23:22] if so then yes [23:22] then stacking will make no difference at all [23:22] as it is already sharing revisions [23:23] thumper: as it is now I have locally all metadata from the lp:project, which is too much [23:23] by converting to stacked I was hoping to rid this space and have only local changes [23:23] local branches etc [23:24] you really don't want to stack on a remote branch [23:24] ever [23:24] I know, bad past experience :-) [23:24] so it's not possible [23:24] ? [23:25] oh it is possible, but every action will include network which will be very slow [23:25] lifeless: care to comment? [23:27] thumper: I hope I'll not do *any* action after converting to stacked. My plan is to do it in a dup copy of the original repo: 1)convert to stacked 2)back it up 3)rm -rf stacked-repo :-) [23:27] anyway just playing here to find the best backup method, I'll let you know after experimenting :-) [23:28] jimis: how about push to launchpad? [23:28] that is a pretty good backup [23:28] and saves you 100% disk space [23:28] thumper: I push what I want to be seen, but too many junk branches I don't want to push [23:29] * thumper shrugs [23:29] ok [23:42] jimis: it will performance very poorly. [23:42] jimis: whats the actual problem you are trying to solve ? [23:43] launchpad answer 205318 [23:43] https://answers.launchpad.net/bzr/+question/205318 [23:44] just trying various ways other then the obvious, to incrementally backup everything. [23:45] lifeless: Ideally when I'll have to restore from backup, I'll be able to re-convert to non-stacked. [23:46] this will possibly be slow but it will only happen once, hopefully never :-p [23:47] jimis: I think you have a flawed model about how stacked works. [23:48] jimis: if you want to run efficient backups of the whole repo to another site, push the whole repo there; a small python script can push all the heads in one network transaction. [23:48] something like bzrlib.repository.Repository.open('remotepath').fetch(bzrlib.repository.Repository.open('localpath')) [23:49] stacking won't give you the ability to restore reliably, because one missing revision can render a branch unusable; and it will incur a per-branch overhead of 10 or so network round trips. [23:50] you can seed the back up repository by cloning lp:gcc from Launchpad directly to your backup server. [23:50] ah that would be ideal [23:50] if you have 400MB of local branch commits, I'd be amazed. I suspect you actually have 20 or 30MB tops [23:50] its just not compacted. [23:51] even less probably of raw text data, that's why I was hoping to generate minimum traffic [23:51] bzr will be reasonably efficient at incremental backups. [23:51] What I'm describing will get all the revisions [23:52] you can use your rsync of the per-branch directories to grab them and their metadata. [23:54] so I'll clone lp:gcc on my backup server, and then only rsync my branch subdirs, ignoring root .bzr. [23:54] Right?