[02:06] I had a local project versioned with bazaar, and now I want to push it to launchpad. Unfortunately I didn't realize that my local system had versioned some very large data files (multi-GB) which never changed. Is there a way to push only the recent revisions, or to somehow push the changelog without having to upload all those files to launchpad? [02:19] jfcaron1: not trivially [02:20] Can I just "unversion" the whole directory and start anew? [02:21] jfcaron1: the easiest thing to do is to throw away the existing history, yes. Another option is to create a new history without the unwanted parts, I think you can use the bzr-rewrite plugin to do that, or otherwise the bzr-fastimport plugin can do it (dump the history; filter it; reimport it). [02:22] jfcaron1: (to throw away the existing history I'd suggest 'bzr export' it to a clean directory, then 'bzr add' etc there.) [02:22] spiv: I installed bzr-rewrite to use the rebase command, but I don't understand the syntax. [02:23] spiv: Will that make an entire new local copy of all the files, even the non-versioned ones? [02:24] What if I just delete the .bzr directory? [08:04] morning [08:05] hi [08:06] how are you today jelmer? [08:12] mgz: not great, actually [08:12] mgz: are we standing up today? [08:14] hm, I think we should be [09:18] do i really have to merge for rescuing commits from some obsolete branch? [09:18] or is there something like git's cherry picking? [09:19] i actually found http://wiki.bazaar.canonical.com/CherryPick, but this one also talks about merging [09:24] tbf: what's confusing you? just that the interface uses the merge command? [09:26] mgz, i just want to rescue some single commits from some obsolete branch [09:26] a cherrypick is just applying the changes from a set of revisions [09:26] mgz, but i don't like how bzr creates merge commits for that cherry picks [09:26] you could do that by taking a diff of the changes that you want then using patch, [09:26] mgz, that drops timestamps and and forces me to retype the commit message [09:27] but `bzr merge -rA..B` is a handy tool that uses the bzr smarts [09:27] ah, so you really want to rebase changes. [09:27] look at the rebase plugin === mmrazik is now known as mmrazik|lunch === yofel_ is now known as yofel === slank` is now known as slank === slank is now known as Guest61577 === mbarnett` is now known as mbarnett === Lasall42 is now known as Lasall === deryck is now known as deryck[lunch] [16:53] in bzrlib, i've been looking at builtins, most commands aquire a lock, but when i look at the individual functions, it looks like they have decorators that automatically aquire locks === deryck[lunch] is now known as deryck [17:29] bjp: the decorators release the lock on function exit [17:30] if you want to do more than one thing that requires a lock, it's therefore more efficient to explictly grab the lock at the start, then do the operations [17:40] k, i thought that might be the case [17:41] does doing multiple operations within a lock perform them over the same ssh connection (as opposed to opening a new ssh connection for each one) ? [17:50] bjp: there's a possible_transports argument you can give on branch creation to reuse the transport [17:51] but just keeping the same branch object around is also enough if you're only working with one [17:56] i'm working with a tree object [17:56] hopefully this speeds my script up a ton [17:56] when i get it all worked out === idnaria is now known as idnar === Guest61577 is now known as slank === slank is now known as Guest70664 [21:09] the operations in bzrlib spit out a lot of ssh debug output, can i turn that off? [21:36] bjp: like what? generally ssh is used as a subprocess and its output doesn't reach the bzr terminal [21:39] stuff like this: pastebin.com/yHJs1XJW [21:42] huh, fun, never seen that before. aparrently comes from paramiko [21:43] yea, i never saw it until i started testing my script with bzrlib [21:45] I suspect you need to do something with logging [21:45] are you using `with bzrlib.initialize(): ..` to wrap your program? [21:45] no [21:45] is that needed? [21:48] strictly, no, but depending on what you need from bzrlib (logging, for instance) you diverge from what the bzr script does without it [21:48] i don't do anything with bzr logging, but i use python's logging [21:49] I suspect that's how the paramiko log stuff it getting through, bzr would send it to .bzr.log [21:49] you can probably just look at how paramiko uses the logging module and forward just 'paramiko' to a null handler or something [21:51] or set up a default logging handler that goes somewhere, and only catch your local bits for putting on the terminal, or so on [21:53] weird, even if i set level to ERROR i still see all paramiko junk [21:53] try calling enable_default_logging() from bzrlib.trace and see if that magically makes it vanish [21:53] (might also mess with your logging, but worth an experiment) [21:54] no change [21:55] hmm i removed bzrlib.initialize, and my loglevel settings take effect [21:57] hm, less, that probably overwrites them for the contained logic [21:57] s/less/yes/ [21:58] but apparently not you handler that shows things on stdout [21:59] well i wasn't using initialize before, if i drop it and explicitly set paramiko's logger to ERROR, i only see my logger [21:59] that'll do then [23:16] how can I tell bzr to export all but one file (the deploy script itself performing bzr export)?