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:06 |
---|---|---|
spiv | jfcaron1: not trivially | 02:19 |
jfcaron1 | Can I just "unversion" the whole directory and start anew? | 02:20 |
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:21 |
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:22 |
jfcaron1 | spiv: Will that make an entire new local copy of all the files, even the non-versioned ones? | 02:23 |
jfcaron1 | What if I just delete the .bzr directory? | 02:24 |
mgz | morning | 08:04 |
jelmer | hi | 08:05 |
mgz | how are you today jelmer? | 08:06 |
jelmer | mgz: not great, actually | 08:12 |
jelmer | mgz: are we standing up today? | 08:12 |
mgz | hm, I think we should be | 08:14 |
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:18 |
tbf | i actually found http://wiki.bazaar.canonical.com/CherryPick, but this one also talks about merging | 09:19 |
mgz | tbf: what's confusing you? just that the interface uses the merge command? | 09:24 |
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:26 |
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 | 09:27 |
=== 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] | ||
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 | 16:53 |
=== deryck[lunch] is now known as deryck | ||
w7z | bjp: the decorators release the lock on function exit | 17:29 |
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:30 |
bjp | k, i thought that might be the case | 17:40 |
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:41 |
w7z | bjp: there's a possible_transports argument you can give on branch creation to reuse the transport | 17:50 |
w7z | but just keeping the same branch object around is also enough if you're only working with one | 17:51 |
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 | 17:56 |
=== idnaria is now known as idnar | ||
=== Guest61577 is now known as slank | ||
=== slank is now known as Guest70664 | ||
bjp | the operations in bzrlib spit out a lot of ssh debug output, can i turn that off? | 21:09 |
w7z | bjp: like what? generally ssh is used as a subprocess and its output doesn't reach the bzr terminal | 21:36 |
bjp | stuff like this: pastebin.com/yHJs1XJW | 21:39 |
w7z | huh, fun, never seen that before. aparrently comes from paramiko | 21:42 |
bjp | yea, i never saw it until i started testing my script with bzrlib | 21:43 |
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:45 |
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:48 |
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:49 |
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:51 |
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:53 |
bjp | no change | 21:54 |
bjp | hmm i removed bzrlib.initialize, and my loglevel settings take effect | 21:55 |
w7z | hm, less, that probably overwrites them for the contained logic | 21:57 |
w7z | s/less/yes/ | 21:57 |
w7z | but apparently not you handler that shows things on stdout | 21:58 |
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 | 21:59 |
mark06 | how can I tell bzr to export all but one file (the deploy script itself performing bzr export)? | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!