[08:10] <mgz> morning
[08:11] <vila> hi
[14:39] <vila> james_w: ping, around ?
[14:50] <james_w> vila, yep
[14:51] <vila> 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] <james_w> vila, you are now
[14:52] <vila> thanks
[14:53] <vila> james_w: wow, and jam too, you're reading my mind or was that from someone else ?
[14:57] <james_w> vila, i saw your comment elsechannel
[14:57] <vila> you rock ;)
[15:59] <hallyn> 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] <hallyn> (i was surprised it didn't do it autmoatcially, figured ther emight be a reason :)
[16:08] <weigon> 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] <weigon> I went with repo.get_graph().heads(repo.all_revisions()) ... but that takes quite some time to complete
[16:22] <jelmer> weigon: there is something slightly faster I think
[16:31] <weigon> jelmer: I wonder how the revisions are indexed and if that can be utilized
[16:32] <jelmer> weigon: any access to the revision graph should already use just the indexes afaik
[16:43] <weigon> jelmer: any idea how to speed it up?
[16:56] <jelmer> weigon: check out what 'bzr heads' does
[17:16] <weigon> jelmer: *doh* it is all there ...
[17:16] <weigon> jelmer: thx
[20:07] <jelmer> maxb: you're still occasionally contributing to the bzr package, should I consider you one of its maintainers?
[23:20] <jimis> 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] <thumper> are you using shared repositories?
[23:21] <jimis> thumper: I think so, yes
[23:22] <jimis> you mean if the branch is in a directory where init-repo has run?
[23:22] <jimis> if so then yes
[23:22] <thumper> then stacking will make no difference at all
[23:22] <thumper> as it is already sharing revisions
[23:23] <jimis> thumper: as it is now I have locally all metadata from the lp:project, which is too much
[23:23] <jimis> by converting to stacked I was hoping to rid this space and have only local changes
[23:23] <jimis> local branches etc
[23:24] <thumper> you really don't want to stack on a remote branch
[23:24] <thumper> ever
[23:24] <jimis> I know, bad past experience :-)
[23:24] <jimis> so it's not possible
[23:24] <jimis> ?
[23:25] <thumper> oh  it is possible, but every action will include network which will be very slow
[23:25] <thumper> lifeless: care to comment?
[23:27] <jimis> 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] <jimis> anyway just playing here to find the best backup method, I'll let you know after experimenting :-)
[23:28] <thumper> jimis: how about push to launchpad?
[23:28] <thumper> that is a pretty good backup
[23:28] <thumper> and saves you 100% disk space
[23:28] <jimis> 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] <thumper> ok
[23:42] <lifeless> jimis: it will performance very poorly.
[23:42] <lifeless> jimis: whats the actual problem you are trying to solve ?
[23:43] <jimis> launchpad answer 205318
[23:43] <jimis> https://answers.launchpad.net/bzr/+question/205318
[23:44] <jimis> just trying various ways other then the obvious, to incrementally backup everything.
[23:45] <jimis> lifeless: Ideally when I'll have to restore from backup, I'll be able to re-convert to non-stacked.
[23:46] <jimis> this will possibly be slow but it will only happen once, hopefully never :-p
[23:47] <lifeless> jimis: I think you have a flawed model about how stacked works.
[23:48] <lifeless> 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] <lifeless> something like bzrlib.repository.Repository.open('remotepath').fetch(bzrlib.repository.Repository.open('localpath'))
[23:49] <lifeless> 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] <lifeless> you can seed the back up repository by cloning lp:gcc from Launchpad directly to your backup server.
[23:50] <jimis> ah that would be ideal
[23:50] <lifeless> if you have 400MB of local branch commits, I'd be amazed. I suspect you actually have 20 or 30MB tops
[23:50] <lifeless> its just not compacted.
[23:51] <jimis> even less probably of raw text data, that's why I was hoping to generate minimum traffic
[23:51] <lifeless> bzr will be reasonably efficient at incremental backups.
[23:51] <lifeless> What I'm describing will get all the revisions
[23:52] <lifeless> you can use your rsync of the per-branch directories to grab them and their metadata.
[23:54] <jimis> so I'll clone lp:gcc on my backup server, and then only rsync my branch subdirs, ignoring root .bzr.
[23:54] <jimis> Right?