| === jelmer_ is now known as jelmer | ||
| === _thumper_ is now known as thumper | ||
| === SamB_ is now known as SamB | ||
| === Logan__ is now known as Logan_ | ||
| === jam1 is now known as jam | ||
| rindolf | Hi all. How can I remove old and no-longer-needed data from .bzr? Something like "git clean -dxf" or "svn cleanup". | 11:53 |
|---|---|---|
| zyga | rindolf: what do you mean? | 11:54 |
| zyga | rindolf: ignored files that you don't add to the repository? | 11:54 |
| zyga | rindolf: bzr clean-tree --help; maybe? | 11:54 |
| rindolf | zyga: no, the junk/cruft inside the ".bzr"/dot-bzr. | 11:54 |
| zyga | ah | 11:54 |
| zyga | bzr pack --clean-obsolete-packs ; should do it | 11:54 |
| rindolf | Thanks! | 11:56 |
| rindolf | zyga: thanks, let me try. | 11:56 |
| rindolf | zyga: OK, I did it and it was time consuming and .bzr is still 296M whereas the working copy directories are 150M. | 12:02 |
| zyga | rindolf: well, bzr keeps all history so it's well expected that the history folder (.bzr) is larger than the working copy | 12:03 |
| rindolf | zyga: but that's not the case for it in .git. | 12:03 |
| zyga | rindolf: there is no other cruft to remove I'm afraid, bzr keeps the history and a few indices to find the data | 12:03 |
| zyga | rindolf: it is | 12:03 |
| zyga | rindolf: git keeps the history just as bzr | 12:03 |
| rindolf | zyga: at least not usually. | 12:03 |
| zyga | rindolf: I don't believe you are correct, unless you do "shallow" clones that ignore all the history apart from the few most recent changes | 12:04 |
| zyga | rindolf: bzr can do that too | 12:04 |
| zyga | rindolf: you can create a lightweight checkout of an existing branch that will *not* keep the history locally | 12:04 |
| zyga | rindolf: depending on how you work that might be useful to you | 12:04 |
| rindolf | zyga: OK. | 12:05 |
| LeoNerd | Since the current state is inferred from the history that got us here, information theory states that the history is necessarily at least as large as the state itself | 12:06 |
| zyga | rindolf: you can do a lightweight checkout with bzr checkout --lightweight URL | 12:06 |
| * zyga thinks that sliding history window would be a nice backup feature if bzr scaled well for large binary files | 12:07 | |
| rindolf | LeoNerd: I think git compresses the history though. | 12:07 |
| zyga | anyway, back to work | 12:07 |
| zyga | rindolf: bzr does as well | 12:07 |
| zyga | rindolf: you might be using an older format that has less efficient compression, you can run bzr upgrade --2a; to get the latest format; then re-do the pack command as above | 12:08 |
| zyga | rindolf: if you had started with an older repository format this will usually save some space | 12:08 |
| rindolf | zyga: thanks. | 12:09 |
| rindolf | zyga: «The branch format Meta directory format 1 is already at the most recent format.» | 12:09 |
| zyga | rindolf: then that's the best bzr can do for you now | 12:10 |
| rindolf | zyga: OK, thanks. | 12:12 |
| === mbarnett` is now known as mbarnett | ||
| fullermd | git gc does gc unref'd revs, which bzr pack doesn't. Usually not a huge difference, but special cases can make it bigger. | 15:25 |
| fullermd | ('course, git clean _is_ straight analogous to bzr clean-tree; it's a WT operation, not a history one) | 15:26 |
| zyga | fullermd: is there are way to 'git gc' in bzr from the command line? | 15:31 |
| fullermd | The part that does repacking/recompressing/whatnot, sure, that's what bzr pack does. The part that gc's stuff, no. | 15:33 |
| achiang | hello, i have 2 separate trees: call them 'code' and 'tests'. i'd like to merge tests => code and have both code and tests in a single branch | 21:53 |
| achiang | is there a way to do this while preserving the history of 'tests' | 21:53 |
| achiang | is it as simple as a bzr merge? | 21:53 |
| achiang | hm, no. | 21:55 |
| achiang | maybe it's bzr join ? | 21:55 |
| achiang | http://stackoverflow.com/questions/9849466/how-to-combine-repositories-into-a-single-one-in-bazaar | 21:57 |
| jelmer | achiang: yep, bzr join sounds like what you are looking for | 21:57 |
| achiang | i can't figure out the join syntax though, even after looking at the help | 21:57 |
| achiang | https://answers.launchpad.net/bzr/+question/71563 | 22:00 |
| achiang | if i have modern bzr (post 12.04), do i need to do anything specific to get rich-root? | 22:01 |
| achiang | uh, i have branch format 7, whatever that means | 22:03 |
| achiang | oh, ok. and repository format 2a | 22:04 |
| achiang | hopefully that's good enough to try join | 22:04 |
| achiang | jelmer: any clues? | 22:06 |
| fullermd | Plenty. Rich root worries are mostly a pre-2.0 thing. To use join you'd just stick one branch under another and then run the command on it. | 22:07 |
| fullermd | And then commit it, of course. Join is really just a bit of sugar around merge. | 22:07 |
| jelmer | what fullermd says :) | 22:08 |
| achiang | hm. ok | 22:08 |
| fullermd | Well, in that case, fullermd also gets a 20 foot high pile of gold coins delivered to his front door today ;p | 22:09 |
| achiang | confused... :-/ http://pastebin.ubuntu.com/6764485/ | 22:11 |
| achiang | fullermd: any ideas what i did wrong above? | 22:14 |
| SamB | zyga: often, git *does* manage to scrunch histories up enough to take less space than the working tree. (This is obviously easier on projects with shorter histories.) | 22:15 |
| fullermd | Do those branches have any shared history? | 22:16 |
| achiang | fullermd: they really shouldn't | 22:16 |
| achiang | fullermd: no, they do not have any shared history | 22:16 |
| fullermd | Well, that says they have the same root id. Which I guess without shared history means they're old enough to have come from pre-rich-root branches, which all have the same root. | 22:17 |
| fullermd | So I guess your best bet is to just use merge, then mv all the files into a subdir. | 22:17 |
| achiang | i tried that and got a different error | 22:18 |
| fullermd | At one time there was a plugin called merge-into or something that would automate it, but I think it was abandoned when join came around, so I doubt it still works. | 22:18 |
| fullermd | IWBNI merge had an arg that could do that... I think a unicorn is scheduled to deliver it next week. | 22:19 |
| achiang | oh wait | 22:19 |
| achiang | i screwed up my cp -a before | 22:19 |
| achiang | let me try again with fresh branches | 22:19 |
| achiang | i bet it will work | 22:19 |
| fullermd | You can just use 'branch' instead of cp to do it. | 22:19 |
| fullermd | e.g., (cd trunk ; bzr branch ../tests) | 22:19 |
| achiang | ok, will try that | 22:23 |
| achiang | fullermd: ok, it works much better when you do not overwrite .bzr/ in the containing tree ;) | 22:30 |
| fullermd | Oh, yes, that might have bad side effects. | 22:30 |
| achiang | thanks | 22:32 |
| zyga | SamB: this is true of bzr as well, both use compression | 22:39 |
| achiang | i have a local branch that takes a long time to pull. i'd like to update this branch with the contents of another test branch that's been pushed up to LP (but not merged into trunk yet). | 22:50 |
| achiang | is there a way to do so without introducing an actual merge in my local branch? | 22:50 |
| achiang | maybe it's bzr merge --pull | 22:52 |
| achiang | yay, that did it | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!