[02:06] <jfcaron1> 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] <spiv> jfcaron1: not trivially
[02:20] <jfcaron1> Can I just "unversion" the whole directory and start anew?
[02:21] <spiv> 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] <spiv> jfcaron1: (to throw away the existing history I'd suggest 'bzr export' it to a clean directory, then 'bzr add' etc there.)
[02:22] <jfcaron1> spiv: I installed bzr-rewrite to use the rebase command, but I don't understand the syntax.
[02:23] <jfcaron1> spiv: Will that make an entire new local copy of all the files, even the non-versioned ones?
[02:24] <jfcaron1> What if I just delete the .bzr directory?
[08:04] <mgz> morning
[08:05] <jelmer> hi
[08:06] <mgz> how are you today jelmer?
[08:12] <jelmer> mgz: not great, actually
[08:12] <jelmer> mgz: are we standing up today?
[08:14] <mgz> hm, I think we should be
[09:18] <tbf> do i really have to merge for rescuing commits from some obsolete branch?
[09:18] <tbf> or is there something like git's cherry picking?
[09:19] <tbf> i actually found http://wiki.bazaar.canonical.com/CherryPick, but this one also talks about merging
[09:24] <mgz> tbf: what's confusing you? just that the interface uses the merge command?
[09:26] <tbf> mgz, i just want to rescue some single commits from some obsolete branch
[09:26] <mgz> a cherrypick is just applying the changes from a set of revisions
[09:26] <tbf> mgz, but i don't like how bzr creates merge commits for that cherry picks
[09:26] <mgz> you could do that by taking a diff of the changes that you want then using patch,
[09:26] <tbf> mgz, that drops timestamps and and forces me to retype the commit message
[09:27] <mgz> but `bzr merge -rA..B` is a handy tool that uses the bzr smarts
[09:27] <mgz> ah, so you really want to rebase changes.
[09:27] <mgz> look at the rebase plugin
[16:53] <bjp> 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
[17:29] <w7z> bjp: the decorators release the lock on function exit
[17:30] <w7z> 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] <bjp> k, i thought that might be the case
[17:41] <bjp> 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] <w7z> bjp: there's a possible_transports argument you can give on branch creation to reuse the transport
[17:51] <w7z> but just keeping the same branch object around is also enough if you're only working with one
[17:56] <bjp> i'm working with a tree object
[17:56] <bjp> hopefully this speeds my script up a ton
[17:56] <bjp> when i get it all worked out
[21:09] <bjp> the operations in bzrlib spit out a lot of ssh debug output, can i turn that off?
[21:36] <w7z> bjp: like what? generally ssh is used as a subprocess and its output doesn't reach the bzr terminal
[21:39] <bjp> stuff like this: pastebin.com/yHJs1XJW
[21:42] <w7z> huh, fun, never seen that before. aparrently comes from paramiko
[21:43] <bjp> yea, i never saw it until i started testing my script with bzrlib
[21:45] <w7z> I suspect you need to do something with logging
[21:45] <w7z> are you using `with bzrlib.initialize(): ..` to wrap your program?
[21:45] <bjp> no
[21:45] <bjp> is that needed?
[21:48] <w7z> 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] <bjp> i don't do anything with bzr logging, but i use python's logging
[21:49] <w7z> I suspect that's how the paramiko log stuff it getting through, bzr would send it to .bzr.log
[21:49] <w7z> you can probably just look at how paramiko uses the logging module and forward just 'paramiko' to a null handler or something
[21:51] <w7z> 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] <bjp> weird, even if i set level to ERROR i still see all paramiko junk
[21:53] <w7z> try calling enable_default_logging() from bzrlib.trace and see if that magically makes it vanish
[21:53] <w7z> (might also mess with your logging, but worth an experiment)
[21:54] <bjp> no change
[21:55] <bjp> hmm i removed bzrlib.initialize, and my loglevel settings take effect
[21:57] <w7z> hm, less, that probably overwrites them for the contained logic
[21:57] <w7z> s/less/yes/
[21:58] <w7z> but apparently not you handler that shows things on stdout
[21:59] <bjp> 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] <w7z> that'll do then
[23:16] <mark06> how can I tell bzr to export all but one file (the deploy script itself performing bzr export)?