mgz | morning | 08:10 |
---|---|---|
vila | hi | 08:11 |
=== zyga is now known as zyga-food | ||
=== zyga-food is now known as zyga | ||
vila | james_w: ping, around ? | 14:39 |
james_w | vila, yep | 14:50 |
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:51 |
james_w | vila, you are now | 14:52 |
vila | thanks | 14:52 |
vila | james_w: wow, and jam too, you're reading my mind or was that from someone else ? | 14:53 |
james_w | vila, i saw your comment elsechannel | 14:57 |
vila | you rock ;) | 14:57 |
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? | 15:59 |
hallyn | (i was surprised it didn't do it autmoatcially, figured ther emight be a reason :) | 16:00 |
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:08 |
weigon | I went with repo.get_graph().heads(repo.all_revisions()) ... but that takes quite some time to complete | 16:09 |
jelmer | weigon: there is something slightly faster I think | 16:22 |
weigon | jelmer: I wonder how the revisions are indexed and if that can be utilized | 16:31 |
jelmer | weigon: any access to the revision graph should already use just the indexes afaik | 16:32 |
weigon | jelmer: any idea how to speed it up? | 16:43 |
jelmer | weigon: check out what 'bzr heads' does | 16:56 |
weigon | jelmer: *doh* it is all there ... | 17:16 |
weigon | jelmer: thx | 17:16 |
=== r0bby is now known as robbyoconnor | ||
jelmer | maxb: you're still occasionally contributing to the bzr package, should I consider you one of its maintainers? | 20:07 |
=== mbarnett` is now known as mbarnett | ||
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:20 |
thumper | are you using shared repositories? | 23:21 |
jimis | thumper: I think so, yes | 23:21 |
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:22 |
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:23 |
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:24 |
thumper | oh it is possible, but every action will include network which will be very slow | 23:25 |
thumper | lifeless: care to comment? | 23:25 |
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:27 |
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:28 |
* thumper shrugs | 23:29 | |
thumper | ok | 23:29 |
lifeless | jimis: it will performance very poorly. | 23:42 |
lifeless | jimis: whats the actual problem you are trying to solve ? | 23:42 |
jimis | launchpad answer 205318 | 23:43 |
jimis | https://answers.launchpad.net/bzr/+question/205318 | 23:43 |
jimis | just trying various ways other then the obvious, to incrementally backup everything. | 23:44 |
jimis | lifeless: Ideally when I'll have to restore from backup, I'll be able to re-convert to non-stacked. | 23:45 |
jimis | this will possibly be slow but it will only happen once, hopefully never :-p | 23:46 |
lifeless | jimis: I think you have a flawed model about how stacked works. | 23:47 |
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:48 |
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:49 |
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:50 |
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:51 |
lifeless | you can use your rsync of the per-branch directories to grab them and their metadata. | 23:52 |
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? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!