| Keybuk | freaky | 00:23 |
|---|---|---|
| Keybuk | now doing a bzr fast-import, having fixed other bugs, I'm left with four files missing from the output repository | 00:23 |
| Keybuk | except the log shows them being added to the inventory | 00:23 |
| mwhudson | igc: are you here? | 00:27 |
| jml | spiv: are you around today? | 00:32 |
| jml | vila: can you land that loom patch or do you want me to do it? | 00:41 |
| spiv | jml: I am | 00:42 |
| spiv | (when I'm not busy making myself coffee) | 00:43 |
| jml | spiv: can I hit you up for a 20 min skype call on server-side logging? | 00:43 |
| spiv | Sure. | 00:43 |
| jml | spiv: just dial me when you get online | 00:44 |
| DnaX | hi | 00:57 |
| DnaX | how can i remove last commit to the remote repo? | 00:57 |
| Keybuk | hmm | 00:58 |
| Keybuk | this actually looks like a bzr bug itself | 00:58 |
| DnaX | wonderful.... | 00:59 |
| Keybuk | because the damned inventory is certainly queued to be committed :-/ | 01:00 |
| DnaX | Keybuk: thank you ;) | 01:03 |
| Keybuk | DnaX: ? | 01:04 |
| Keybuk | DnaX: I wasn't talking to you - I was just talking to the air :p | 01:04 |
| DnaX | XD OMG... | 01:04 |
| Keybuk | DnaX: though I can answer your question ;) | 01:10 |
| Keybuk | bzr uncommit | 01:10 |
| Keybuk | bzr push --overwrite | 01:10 |
| cafuego | How do I make bzr list the "unknown files" it whines about when trying to commit? | 01:12 |
| DnaX | Keybuk: thank you, really now! ;) | 01:12 |
| Keybuk | cafuego: bzr ls --unknown | 01:12 |
| cafuego | ta | 01:12 |
| spiv | cafuego: or even just "bzr unknowns" :) | 01:13 |
| spiv | Keybuk: that doesn't sound good | 01:13 |
| cafuego | Ok look, that entire mysql source tree isn't supposed to be there ;-) | 01:13 |
| Keybuk | spiv: I'm trying to debug enough bzrlib to work out why the file doesn't appear - but not having much luck :-/ | 01:13 |
| spiv | Keybuk: igc is likely to be around in an hour or two, if you want to talk fast-import stuff with him | 01:14 |
| spiv | Keybuk: And/or I can try to help your debugging now | 01:14 |
| Keybuk | spiv: well, so I'm tracing through fast-import generic_processor.py | 01:16 |
| Keybuk | I can see the file in modify_handler() | 01:16 |
| Keybuk | it gets a file id | 01:16 |
| Keybuk | (a new one generated) | 01:16 |
| Keybuk | an inventory is made | 01:17 |
| Keybuk | well, inventory.make_entry() | 01:17 |
| Keybuk | it's an InventoryFile | 01:17 |
| Keybuk | lines seems to have the one line in it | 01:17 |
| Keybuk | and it gets added to self.inventory | 01:17 |
| Keybuk | yet, it doesn't show up in the commit :-/ | 01:18 |
| * spiv looks | 01:19 | |
| Keybuk | it's always the same four files | 01:19 |
| spiv | Anything special about those files? Wacky file names or something? | 01:20 |
| Keybuk | nope | 01:21 |
| Keybuk | no different than the surrounding | 01:21 |
| Keybuk | but it's always the same four files | 01:21 |
| Keybuk | in the same commit | 01:21 |
| spiv | I'm not familiar with fastimport, but it sounds a bit odd that new files would go through something called modify_handler? | 01:22 |
| spiv | Ah, hmm, that does appear normal. | 01:22 |
| Keybuk | hmm, the only odd thing is that one of the files shares a blob with another maybe? | 01:28 |
| spiv | bzr-fastimport doesn't appear to use the regular commit APIs, for speed reasons I guess. | 01:30 |
| spiv | I wonder if it's skipping something important... | 01:30 |
| Keybuk | dunno | 01:32 |
| Keybuk | the same mark gets re-used in several other places just fine :-/ | 01:32 |
| Keybuk | what's particularly weird | 01:34 |
| Keybuk | they are 4 of the last 5 entries of a particular commit | 01:34 |
| Keybuk | oh | 01:36 |
| Keybuk | hmm | 01:36 |
| Keybuk | iiiiinteresting | 01:36 |
| Keybuk | they don't show up on the mainline at all | 01:36 |
| Keybuk | I missed that entirely | 01:36 |
| Keybuk | the commit doesn't even appear | 01:36 |
| spiv | So that revision ID isn't in the generated repository? | 01:37 |
| Keybuk | it seems to be treating some tags as branches | 01:38 |
| meoblast001 | hi | 01:38 |
| meoblast001 | are there any bots like CIA for bazaar? | 01:38 |
| Keybuk | hmm | 01:38 |
| Keybuk | in fact | 01:38 |
| Keybuk | the export has commit refs/tags/... a lot | 01:39 |
| nDuff | ...okay, this is odd -- I'm deleting and immediately re-adding a directory (with the same id) in bzrlib; an os.listdir() between the two confirms that it's removed from the filesystem, but the wt.mkdir() fails on account of the directory already existing. | 01:39 |
| nDuff | meoblast001, I'm not familiar with CIA; is it a PQM? | 01:39 |
| Keybuk | except for <= 057, they appear as branches, not tags | 01:39 |
| nDuff | meoblast001, if so, Bazaar had PQMs long before... well, pretty much anyone else that I know of. | 01:39 |
| bob2 | meoblast001: bzr-cia | 01:39 |
| meoblast001 | CIA is a bot that chills in IRC and talks about commits | 01:39 |
| spiv | (Gosh, there's some scary code in bzr-fastimport...) | 01:40 |
| meoblast001 | isnt bzr-cia still in productions | 01:40 |
| nDuff | ahh | 01:40 |
| spiv | meoblast001: well, there's a bzr-email plugin | 01:40 |
| meoblast001 | hmm | 01:40 |
| meoblast001 | if you go into #wxwidgets or Anynet #alientrap you'll see what im talking about | 01:40 |
| Keybuk | ooooh, the first commit refs/tags/058 has no from: line | 01:41 |
| meoblast001 | heres an example <CIA-17> RR * r57426 wxWidgets/interface/wx/filename.h: Correct AssignTempFile docs | 01:41 |
| Keybuk | and that's where the master branch in the bzr import begins | 01:41 |
| spiv | meoblast001: and there's https://launchpad.net/bzr-cia | 01:41 |
| meoblast001 | is CIA downloadable? | 01:41 |
| meoblast001 | the daemon | 01:41 |
| spiv | You mean the thing that runs http://cia.vc/ ? | 01:42 |
| meoblast001 | yeah | 01:42 |
| spiv | meoblast001: cia.vc links to http://code.google.com/p/cia-vc/source/checkout for the source code | 01:43 |
| meoblast001 | ok thanx | 01:43 |
| meoblast001 | wonder if there's a deb package | 01:43 |
| spiv | Keybuk: ok, I'm out of my depth in fastimport now :) | 01:45 |
| spiv | Keybuk: hopefully igc will be around soon if you're still stuck... | 01:45 |
| Keybuk | I'm actually starting to think this is a git fast-export bug | 01:46 |
| TDT | I'm currently using git, but after a bit of an introduction yesterday and today on it -I'm interested in trying out bzr and seeing how well it works for a few of my projects, and if all goes well to move over to bzr totally. I was curious if there was a good way to import a git repository (including history, changes, etc) into bzr without writing a script to do it. | 01:46 |
| Keybuk | TDT: git fast-export | bzr fast-import | 01:47 |
| spiv | Yeah, fast-export/import is the best option I know of. You'll need to install the bzr-fastimport plugin. | 01:47 |
| TDT | Keybuk: Awesome, thank you for the help on that. Ill check out both commands and will likely give it a try very soon. Are there also any good books, like something like Git from the Bottom Up - which helped for a good intro? | 01:48 |
| spiv | TDT: http://doc.bazaar-vcs.org/latest/ is pretty good | 01:51 |
| TDT | spiv: Thanks, I will definitely start at this link then :) Thanks everyone for the help, and sorry for the newbiesh questions. | 01:53 |
| spiv | TDT: not a problem | 01:54 |
| meoblast001 | are there any alternatives to CIA? | 02:05 |
| * markh wonders what happens when you butter memory... | 02:44 | |
| NfNitLoop | ??? | 02:44 |
| markh | revision 3887 apparently butter's memory usage :) | 02:48 |
| Peng_ | Buttered RAM would probably smell pretty bad. | 02:52 |
| * markh wonders if that revision is the reason for the funny smells here recently... | 02:53 | |
| meoblast001 | hi | 03:16 |
| meoblast001 | how do you force unlock a branch? | 03:16 |
| seb_kuzminsky | "bzr log" accepts a --log-format=ARG option... where is ARG described? | 03:16 |
| jml | meoblast001: bzr break-lock <url> | 03:16 |
| meoblast001 | thanx | 03:17 |
| NfNitLoop | seb_kuzminsky: it seems to accept the formats listed below it. | 03:18 |
| NfNitLoop | (line, long, short) | 03:18 |
| seb_kuzminsky | ok, thanks | 03:18 |
| seb_kuzminsky | i was hoping for something like "%m" for the log message, "%u" for the user who committed, etc | 03:18 |
| seb_kuzminsky | oh well ;-) | 03:19 |
| NfNitLoop | That does seem like what one would expect in such an argument. | 03:20 |
| seb_kuzminsky | that's ok, i *still* love bzr ;-) | 03:20 |
| NfNitLoop | me too! :) | 03:20 |
| igc | hi all | 03:39 |
| NfNitLoop | igc: h'lo | 03:41 |
| mwhudson | hi igc | 03:41 |
| tansell | hi guys, someone gave a talk at OSDC about making command line python fast (using bzr as an example). Anyone got a link to it? | 05:15 |
| spiv | I gave that talk. I haven't put it online yet. | 05:23 |
| spiv | The paper should be in the printed handout, though. | 05:23 |
| spiv | You can mail me at andrew.bennetts at canonical.com and I'll send you a link when I get it online (next couple of days most likely). | 05:24 |
| bob2 | were OSDC talks recorded? | 05:26 |
| spiv | No. | 05:33 |
| vila | hi all | 06:59 |
| vila | jml: I'll land that loom patch later today | 06:59 |
| vila | spiv: can you have a look at '[MERGE] Fix stacking tests applicability' discussion and give feedback on the intent of the test_push_with_default_stacking_does_not_create_broken_branch test ? | 07:01 |
| igc | hi vila | 07:17 |
| vila | hi Ian | 07:17 |
| spiv | vila: hi | 07:17 |
| spiv | vila: jam's summary is correct | 07:18 |
| vila | spiv: hmm, but how an unstackable branch format can automatically upgrade ? | 07:19 |
| spiv | vila: the source branch doesn't change | 07:20 |
| spiv | But the *new* branch that is created by the push can be in a different format if the user passed --stacked, or if there's a default stacking policy at the target. | 07:20 |
| kfogel | vila: should I poke at you about those log bugs (211852, 97715) or are they not part of your goals right now? | 07:21 |
| kfogel | hmmm. maybe if I say the bugs properly, the chan bot will DTRT: | 07:21 |
| kfogel | bug #211852 | 07:22 |
| ubottu | Launchpad bug 211852 in bzr "bzr log should accept multiple files" [Wishlist,Triaged] https://launchpad.net/bugs/211852 | 07:22 |
| kfogel | bug #97715 | 07:22 |
| ubottu | Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715 | 07:22 |
| spiv | The former part already existed before my recent change that added that test. My change made the latter case consistent with that (and fixed a serious bug in the process, because otherwise the repository only contains stacked revisions but the branch isn't stacked, so the branch is broken). | 07:22 |
| vila | kfogel: you can poke at me or look at the '[RFC] About log [-v] [--deep] [file|dir]*' thread in bazaar ML | 07:22 |
| kfogel | vila: oh -- thank you, somehow I missed that. Will go look. | 07:23 |
| spiv | vila: looms are problematic, because unlike other branch formats there's no format to upgrade to that supports stacking *and* loom data. | 07:23 |
| vila | spiv: haaa, right, I like that | 07:24 |
| spiv | vila: so I'm not sure what should happen if you try to push a loom in that situation. Probably the loom plugin needs to add a stacking-capable loom branch format. | 07:24 |
| vila | I can live with 1 failing test until loom become stackable | 07:24 |
| vila | spiv: that's one point | 07:24 |
| vila | the second one is that the test shouldn't fail anyway :-) | 07:25 |
| spiv | Why not? Looms are broken in this case, I think, so why shouldn't a test fail? | 07:25 |
| spiv | Are you arguing that looms shouldn't be broken? | 07:25 |
| vila | Because an unstackable format (provided by a plugin) may remain like that and never provide a stackable alternative | 07:26 |
| vila | spiv: but I don't think there is urgency to address that | 07:26 |
| kfogel | vila: thread linked to from the issues now | 07:27 |
| spiv | I think plugins that add something as fundamental as a branch format have to accept that will happen, unless they track new development in bzr.dev pretty closely. | 07:27 |
| vila | kfogel: great, if you have feedback from the emacs side, don't hesitate to crosspost | 07:27 |
| spiv | So, the most correct thing a loom can do atm is upgrade to a stacking-capable non-loom format in that case, I think. I think that'd be ok. | 07:28 |
| kfogel | vila: I'll at least link to the emacs-devel thread from the issues, so people can reach the context if they want it. The only "feedback" in that thread is that people want the features -- no surprise there. | 07:29 |
| vila | spiv: nice ! I don't know enough about loom and stackable format myself though :-/ | 07:29 |
| spiv | vila: well, how does the test fail atm? | 07:29 |
| vila | kfogel: the 'log DIR' itself is subject to various interpretations at least | 07:30 |
| vila | spiv: traceback in the thread, raises UnstackableBranchFormat | 07:30 |
| kfogel | vila: yeah, I was wondering if that might be the case. | 07:31 |
| kfogel | (Hadn't really thought about it deeply; I know how SVN behaves in this case, but SVN is sufficiently different from bzr that prior thought like that doesn't always help.) | 07:31 |
| spiv | vila: incidentally, I see there's already a BzrBranchLoomFormat7 | 07:32 |
| spiv | vila: (and it passes the test) | 07:32 |
| vila | as opposed to loom1 and loom6 ? Let me check... | 07:33 |
| vila | oh, you mean without my loom patch ? | 07:34 |
| vila | does that mean loom7 is stackable ? | 07:35 |
| spiv | vila: I think I have a fix for loom | 07:35 |
| vila | spiv: great !! | 07:35 |
| spiv | vila: just delete the implementation of clone in LoomSupport | 07:35 |
| vila | spiv: hmmm, the one you were suspicious about sometime ago ? | 07:36 |
| spiv | vila: it hard codes the format, rather than delegating to the bzrdir like clone is supposed to AFAICT | 07:36 |
| spiv | vila: Yes, exactly. | 07:36 |
| spiv | vila: (see also my posts a while back about the exact contract for clone and bzrdirs...) | 07:36 |
| vila | spiv: deleting clone() is enough to make all tests pass (at least the ones that were failing when I wrote the two patches) | 07:41 |
| vila | spiv: summary: looms are stackable (jml, I will not land that patch finally :-), I'll update my bzr patch to leave the push test as is | 07:42 |
| spiv | vila: I guess that means there's no explicit unit test that source_branch.clone(target_bzrdir) delegates the choice of branch format to the target bzrdir rather than the source branch. | 07:45 |
| vila | spiv: though one... I still had in mind the time where pushing a loom turned into a regular branch (or did I dream that ?)... | 07:49 |
| spiv | vila: well, is there a test about that? ;) | 08:06 |
| vila | spiv: lol | 08:06 |
| vila | spiv: we'll get there, we'll get there... | 08:06 |
| vila | at least the one you define just above, even if it sounds hard to reach, is, IMHO, a very valuable goal | 08:07 |
| spiv | vila: although, I'd expect that case to be ok atm (except when upgrading-for-stacking gets involved) | 08:07 |
| spiv | vila: ooh, there's a test_sprout_uses_bzrdir_branch_format already, but no equivalent for clone | 08:08 |
| vila | spiv: I'm re-reading that push test carefully now, I didn't realize branch_builder has the capability to create file contents too | 08:08 |
| spiv | (looking in branch_implementations still) | 08:08 |
| spiv | vila: make_branch_builder is very useful :) | 08:09 |
| vila | yeah, jam already told me, but so far I has seen it used to build revision graphs without real content | 08:09 |
| vila | right, I think your comment is right (if 'remote' is not stacked *AND* is missing the...) and may be the test can handle more cases gracefully (i.e. accepting a remote branch not stacked but containing the fulltext reccord...) | 08:13 |
| vila | yet another far-too-late review by vila :) | 08:13 |
| spiv | I'm not sure what you mean by handling more cases gracefully? | 08:14 |
| vila | checking that fulltext record is present whether or not the branch is stacked ? | 08:18 |
| vila | err, no, checking that the branch isn't broken whether or not it's stacked | 08:19 |
| vila | baah, may not be worth the effort until we really have to handle such a case | 08:19 |
| spiv | Isn't that what the test does? | 08:20 |
| vila | I mean accepting a format that is neither stackable nor upgradable to a stackable format | 08:20 |
| vila | which we may not want to accept anyway | 08:21 |
| spiv | Again, isn't that what the test does? :) | 08:21 |
| spiv | It doesn't actually assert that the new branch is stacked, just that the new branch works. | 08:22 |
| vila | As long as we don't accept "a format that is neither stackable nor upgradable to a stackable format", yes it is | 08:22 |
| spiv | No, there's nothing in the test code about that (although the docstring may be misleading). | 08:23 |
| spiv | (Misleading for describing the current behaviour rather than the required behaviour) | 08:23 |
| vila | Indeed, "there's nothing in the test code about that" | 08:24 |
| spiv | The test doesn't assert anything about whether the new branch is stacked. It makes sure that the new branch doesn't suffer from missing data (as happens with an unstacked branch wrongly used with a stacked repository) | 08:24 |
| spiv | Which is exactly what you're asking for, as far as I can tell :) | 08:25 |
| vila | yes, I'm thinking out aloud :) | 08:25 |
| vila | The last point that makes me uncomfortable is that we are excluding some formats at the start and plugins will never be able to do that (this is quite unrelated to that specific test) | 08:26 |
| vila | I understand why we do that here, but the general problem remains | 08:27 |
| vila | I encountered it several times already when features are not directly testable (transport.can_roundtrp_chmod_bits() or that kind of stuff) | 08:28 |
| spiv | Yeah, there is a general problem there. | 08:29 |
| vila | thanks for the explanationS (and fixes) about that test, I've enough understanding now to update my submission | 08:30 |
| spiv | I think it's not so bad, though. | 08:30 |
| spiv | Some new scenarios (e.g. the various loom branches) need to be considered to decide if they're applicable or not. | 08:31 |
| spiv | If you're lucky, clear criteria for automatically skipping some scenarios will become obvious. | 08:31 |
| spiv | But the main thing is to avoid writing a test and then accidentally having it *not* apply to something it should. | 08:32 |
| spiv | Just because that's very frustrating :) | 08:32 |
| vila | I think my beliefs were wrong about looms, most of the decisions are already delegated to the associated branch formats, deleting clone() goes one step further in the right direction | 08:32 |
| vila | spiv: Exactly, that's why I fight against selftest --no-plugins :-) | 08:33 |
| vila | and it turns out things are not that bad, I currently have a bunch of plugins which are all passing the tests | 08:34 |
| vila | that includes gtk, qbzr, loom (yeah !!), upload, usertest, webdav, xmloutput (still 1 failure), bookmarks, difftools, bzrtools (err, not anymore wtf ?) :) | 08:36 |
| spiv | vila: ah, but what about svn? :) | 08:39 |
| spiv | It was bzr-svn loading halfway through the suite that was causing me grief, especially as that version didn't like bzr.dev (it wanted 1.10 only). | 08:39 |
| spiv | So random things started giving API version errors. | 08:40 |
| vila | my problem with svn is that I run tests from the same directory for OSX/ubuntu and we don't have a way to use platform-specifc extensions | 08:40 |
| vila | some goes for bzr itself (I run the python modules only, never the compiled extensions, well almost never) | 08:40 |
| vila | s/some/same/ | 08:41 |
| spiv | vila: set your $BZR_PLUGIN_PATH differently on the two platforms? | 08:41 |
| vila | spiv: that's exactly what I want to avoid :) | 08:41 |
| vila | Oh, I can do that for svn only... | 08:41 |
| spiv | bzr-svn 0.5 has the C extensions split into a separate package. | 08:41 |
| spiv | So you could install that part ("subvertpy" IIRC) system-wide, and keep sharing the rest of bzr-svn between platforms. | 08:42 |
| vila | ok, will try that next time (hmmm, more OSX tweaking to install subvertpy may be ? I'll look) | 08:43 |
| vila | spiv: but don't let me retain you that long I thought you were on leave :) | 08:43 |
| spiv | :) | 08:43 |
| * spiv wanders off | 08:43 | |
| AfC | Is it deliberate that you can merge into a branch that isn't up to date? | 08:48 |
| * AfC seems to frequently run into problems where I have working trees that are out of date, don't realize it because I didn't run `bzr status` this time, do a `bzr merge`, then make a mess, then make an even bigger mess when I try `bzr update` and suddenly KABOOM *.moved | 08:49 | |
| AfC | If merged refused to if the Working Tree wasn't up to date, I think I would be spared this. | 08:50 |
| AfC | Am I missing something obvious? | 08:50 |
| vila | kfogel: excellent cross-linking between bugs and mailing lists threads ! | 08:53 |
| vila | AfC: you may want to file a bug, but I think the use case is that you may want to merge several times from different branches and do a single commit | 08:54 |
| AfC | You can do that? | 08:56 |
| AfC | I could have sworn there was a must commit this before merging that sorta thing going on. | 08:57 |
| AfC | Anyway. | 08:57 |
| AfC | I will file one. | 08:57 |
| mgedmin | I have a rather messy Subversion repository; and I'd like to extract the history of a single file and put it into bzr | 10:19 |
| mgedmin | what's a good way to achieve that? | 10:19 |
| mgedmin | I don't expect bzr-svn to cope with that | 10:20 |
| mgedmin | I suppose I could write a shell (or perl, or python) script to svn checkout ever interesting revision and commit it to bzr | 10:21 |
| mgedmin | but I see no way to pass all the relevant metadata to bzr commit | 10:21 |
| mgedmin | for some reason I think I'd like to have historical commit dates | 10:21 |
| mwhudson | it's easy enough in the api, i think | 10:21 |
| spiv | mgedmin: I think svn2bzr can do some filtering | 10:21 |
| mwhudson | so write a python script instead of a shell script, or a plugin that adds --date to commit, i guess | 10:22 |
| spiv | mgedmin: or you could try filtering an dump of the svn repo (I think the svn admin tools might be able to do that) | 10:22 |
| mgedmin | svndumpfilter aborts in the middle with an incomprehensible error message | 10:22 |
| * mgedmin looks at svn2bzr | 10:24 | |
| AfC | I imagine using Bazaar directly in Python would actually be the solution to a lot of problems, but I don't know of a good introduction to the API from a simple use case perspective - for example, something that would be just a few lines that would be in the neighbourhood of what mgedmin wants to do. | 10:25 |
| igc | spiv, vila: I'm calling it a week. Enjoy your holidays heaps and see you next year! | 10:43 |
| mgedmin | fwiw, the bzr commit --date idea would work perfectly here | 10:45 |
| mgedmin | oh yay bzr-svn is reliable as ever: AttributeError: 'SvnWorkingTree' object has no attribute '_transport' | 10:48 |
| vila | igc: Thanks ! I'll be back shortly after Christmas and before 1 Jan. Happy Christmas to you and your family though :-) | 10:49 |
| mwhudson | wt = bzrlib.workingtree.WorkingTree.open('.') | 10:49 |
| mwhudson | wt.commit(... args ... ) | 10:49 |
| mgedmin | looks like https://bugs.launchpad.net/bzr/+bug/264548 | 10:50 |
| ubottu | Launchpad bug 264548 in bzr-svn "AttributeError: 'SvnWorkingTree' object has no attribute '_transport' during branch" [Undecided,Fix released] | 10:50 |
| * mgedmin tries bzr push servername:path-relative-to-home, gets an error, and starts reading 'bzr help push' to figure out the syntax for pushing over SSH | 10:54 | |
| vila | spiv: if you still there, what was the subject line for the thread about exact contract for clone and bzrdirs ? | 10:54 |
| AfC | bzr+ssh://server/absolute-path-to-branch | 10:54 |
| mgedmin | thank you | 10:54 |
| mgedmin | I found bzr help urlspec via bzr help topics | 10:55 |
| AfC | (assuming Bazaar installed on target system, of course) | 10:55 |
| mgedmin | but I only knew to look because I once tried to submit a patch for it | 10:55 |
| mgedmin | and found that someone had submitted a better patch | 10:55 |
| mgedmin | which was eventually included | 10:55 |
| AfC | yeah, it'd be nice if ssh syntax just worked. Alas. | 10:55 |
| mgedmin | I'd suggest listing 'urlspec' in the "See also" list at the bottom of 'bzr help push' | 10:55 |
| mgedmin | I don't mind using bzr+ssh, but I'd like better discoverability | 10:56 |
| mgedmin | consider my today's rambling on this channel an unasked-for usability test ;) | 10:56 |
| mgedmin | a 6 second pause of 'bzr ci' before it spawns an editor is definitely unpleasant | 12:26 |
| mgedmin | I'm reconsidering using branches bound to launchpad | 12:26 |
| === jelmer is now known as Guest70117 | ||
| Jc2k | hey Guest70117 :P | 13:23 |
| === Guest70117 is now known as jelmer | ||
| jelmer | hey Jc2k :-) | 13:24 |
| Jc2k | jelmer: when you have a spare 5 minutes could you sanity check the way im generating a pack in bin/dul-daemon | 13:25 |
| === lamont` is now known as lamont | ||
| jelmer | Jc2k, Yeah, I think so. | 13:30 |
| jelmer | Jc2k, It would be nice to factor out the code in write_pack_data() that writes to a file object | 13:30 |
| jelmer | since that's now duplicated in dul-daemon | 13:31 |
| Jc2k | jelmer: *nod* | 13:31 |
| Jc2k | i have a bug with it atm. some of the trees arrive at the other end corrupted somehow. not them all, though :( | 13:32 |
| jelmer | that's not good | 13:36 |
| Jc2k | no | 13:39 |
| === sdboyer-laptop_ is now known as sdboyer-laptop | ||
| === fta_ is now known as fta | ||
| LeoNerd | What's the easiest/lightest way to tell if cwd is somewhere inside a bzr checkout. Don't care where the root is. | 14:58 |
| LeoNerd | CVS and SVN are a little easier, because I can just test -d CVS or test -d .svn | 14:58 |
| Tak | search upward for a .bzr? | 14:59 |
| LeoNerd | This is in a little shell script, so ideally as light as possible would be good. bzr revno >/dev/null seems reasonable | 15:00 |
| spiv | LeoNerd: 'bzr root > /dev/null 2>&1' then check the exit code | 15:01 |
| LeoNerd | Ahyes.. that's probably lighter | 15:01 |
| LeoNerd | Oh.. bzr-svn gets in the way | 15:01 |
| spiv | 'bzr --no-plugins root > /dev/null 2>&1' ;) | 15:01 |
| * Kinnison just looks upwards for a .bzr | 15:02 | |
| LeoNerd | At work we use CVS and SVN, and personally I use bzr. Since I can never remember which I'm using in a checkout, I've written a tiny bin/vc script | 15:02 |
| LeoNerd | It just hunts for the most likely candidate, then exec()s it | 15:02 |
| LeoNerd | Ah, that's much nicer | 15:02 |
| spiv | At some point jelmer will succeed in making bzr a better svn client than svn ;) | 15:02 |
| Tak | hasn't he? :-P | 15:03 |
| Kinnison | LeoNerd: http://rafb.net/p/Dq7hil79.html | 15:03 |
| Kinnison | LeoNerd: that's what I use in my zsh prompt-building stuff | 15:03 |
| LeoNerd | Ooooh.. Shoving it in PS1 | 15:03 |
| LeoNerd | That would be awwwwwesome | 15:03 |
| * Kinnison grins | 15:03 | |
| * Kinnison has vcs, nick/branch, revno, and status summary in his prompt | 15:04 | |
| Tak | that is pretty slick | 15:04 |
| spiv | Kinnison/LeoNerd: I guess if you wanted to be really fancy you could make that look for .bzr/checkout rather than just .bzr (assuming you really only care about checkouts) | 15:04 |
| Kinnison | spiv: mine can spot repos and tell you about them too | 15:04 |
| === lamont` is now known as lamont | ||
| LeoNerd | spiv: Existence of a .bzr is good enough | 15:04 |
| spiv | LeoNerd: but what if you want to version bzr branches in svn? ;) | 15:05 |
| spiv | (answer: then you get what you deserve!) | 15:05 |
| Kinnison | LeoNerd: E.g. http://users.pepperfish.net/dsilvers/vcsshot.png | 15:05 |
| LeoNerd | spiv: Then I type bzr or svn specifically | 15:05 |
| LeoNerd | vc just execs the "most likely" choice | 15:05 |
| spiv | LeoNerd: :) | 15:05 |
| LeoNerd | vc ci -m "Changed stuff" | 15:05 |
| Tak | that seems ... busy | 15:07 |
| Kinnison | Tak: ? | 15:07 |
| Tak | crowded? cluttered? | 15:08 |
| Kinnison | my prompt? | 15:08 |
| Tak | yeah | 15:08 |
| pickscrape | I have a question about BB. Say I have branch A which contains 1 new revision, and branch B which is based on branch A and contains one additional revision | 15:17 |
| pickscrape | If I submit branch B, BB complains that it doesn't know about all revisions that B is based on (correctly). If I submit A first and then B, BB notices and even tells me in B's merge page that the patch is based on the A patch. | 15:18 |
| pickscrape | That's all fine and works well | 15:18 |
| pickscrape | My current scenario looks more like this though. Say I have A and B, each with one revision, but independent. | 15:18 |
| pickscrape | And they are both submitted | 15:18 |
| pickscrape | But then I submit branch C, which is based on both A and B with some more of its own. Is BB able to pick up referenced revision from multiple other submissions? | 15:19 |
| Kinnison | Tak: I typically have full-screen terminals. so it takes up less room (relatively) than you might think. | 15:19 |
| Tak | ah, that would help | 15:20 |
| Kinnison | I figured that a 1680x1050 example wouldn't be quite as acceptable though | 15:21 |
| LeoNerd | Oh.. if only you could do async/lazy stuff in PS1 | 15:40 |
| LeoNerd | Then I'd have it print the clean/dirty status of the checkout, in a way that didn't slow it down | 15:40 |
| LeoNerd | [bzr] vs [bzr*] | 15:40 |
| Kinnison | mmm | 15:40 |
| Kinnison | that'd be lovely | 15:40 |
| * Kinnison wonders if zsh could do that | 15:40 | |
| rockstar | zsh can move mountains. | 15:41 |
| Kinnison | true | 15:41 |
| * Kinnison ponders | 15:41 | |
| LeoNerd | You'd have to go back later on and update the screen afterwards | 15:43 |
| Kinnison | aye | 15:44 |
| Kinnison | but zsh knows where the prompt is | 15:44 |
| Kinnison | because it can erase the rprompt and return it | 15:44 |
| sven_ | hi! if i run 'bzr log --show-ids -r2682.1.4..2682.1.4', shouldn't it print just revision 2682.1.4? | 15:44 |
| sven_ | for me, it prints the latest revision instead | 15:44 |
| sven_ | sorry, it prints all revisions | 15:47 |
| sven_ | i'm using bzr 1.10 | 15:47 |
| LeoNerd | Kinnison: I think this is likely to end badly.. E.g. big CVS checkouts might take some time to determine clean/dirty status | 15:50 |
| Kinnison | LeoNerd: zsh has proper and complex job control | 15:51 |
| LeoNerd | Ya.. but I mean... I wouldn't want to rely on the not-yet-answered status of the prompt | 15:52 |
| LeoNerd | currently it's just a stat() check, so I know I can rely on it, and it's quick | 15:52 |
| Kinnison | (bzr?) => (bzr) or (bzr*) after update | 15:54 |
| Kinnison | ? | 15:54 |
| Kinnison | that'd make it clear | 15:54 |
| Kinnison | but anyway, it's all moot unless you can alter an already displayed prompt | 15:55 |
| EdwinGrubbs | If I run "bzr annotate" and the line I'm interested in is from revision 5005.3.1, how do I find the revision that merged in 5005.3.1 without just searching through a log of the range of revisions that I'm guessing will contain the one I'm interested in? | 16:02 |
| EdwinGrubbs | rockstar: ^^^^ ? | 16:22 |
| rockstar | EdwinGrubbs, no idea. | 16:25 |
| EdwinGrubbs | rockstar: :-( | 16:26 |
| rockstar | EdwinGrubbs, I never use annotate. Sowwy. :( | 16:26 |
| pickscrape | EdwinGrubbs: I find qbzr to be really useful when history-digging | 16:28 |
| pickscrape | Try bzr qannotate. | 16:29 |
| enigma42 | jelmer: With 0.5 trunk, I'm seen a routine "bzr pull" from SVN take 7 min and 40 sec (pulling no changes), whereas with 0.4.16 it took approx 15 seconds. | 16:31 |
| enigma42 | jelmer: Is there a way I could see where bzr-svn is spending all the time? | 16:31 |
| enigma42 | jelmer: It gets hung up in "Pull phase 0/2" | 16:31 |
| === guilhembi is now known as guilhembi|vacati | ||
| enigma42 | jelmer: I reran the "pull" with "-Dtransport". It looks like the plugin is making several hundred "svn get-dir" calls as part of the pull. | 16:44 |
| ronny | hi | 17:28 |
| ronny | anyone aware if there is a extraction of the lib that handles parsing the bzr cli arguments? | 17:29 |
| luks | I don't think there is | 17:29 |
| ronny | hmm, maybe im blind, but is there any wsgi adapter to have smart-serving from within a wsgi app? | 17:32 |
| luks | ronny: what's a wsgi adapter? there is a wsgi application, is that not enough? | 17:39 |
| ronny | luks: i cant find the wsgi app in bzr.dev, am i looking at the wrong place? | 17:41 |
| ronny | ok, just found it in transports | 17:42 |
| luks | ronny: bzrlib.transport.http.wsgi | 17:42 |
| luks | yeah | 17:42 |
| ronny | hmm | 17:47 |
| jam | Is Marius Kruger lurking around here somewhere? | 18:26 |
| awilkins | ronny: Theres an example of using the wsgi in ServerGuide/IIS on the wiki | 18:57 |
| vila | jam: I think Marius nick is AmanicA | 19:07 |
| AmanicA | yes thats me | 19:07 |
| vila | jam: no I'm not there anymore, merry Christmas anyway :-) | 19:07 |
| vila | AmanicA: hi :) | 19:07 |
| AmanicA | hi | 19:07 |
| jam | hey AmanicA, I just wanted to ask a quick question about http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640812130437k59ecab49g6b49b9a8248117bb%40mail.gmail.com%3E | 19:08 |
| jam | I'm ready to merge it | 19:08 |
| jam | but I wanted to know if you need "StringIO.StringIO()" or whether "cStringIO.StringIO" would work. | 19:08 |
| jam | In general, the reason we used the former is bogus, so we should only be using the latter. | 19:08 |
| jam | (StringIO.StringIO() will cast its internal variable up to a Unicode string if it thinks it needs to, but that is generally not behavior we want.) | 19:09 |
| AmanicA | oh, I probably copied it from some other bzr code | 19:09 |
| AmanicA | so i dont have a reason | 19:09 |
| jam | ok | 19:09 |
| jam | I'll switch it around and submit | 19:09 |
| AmanicA | thanks | 19:09 |
| jam | btw, hi vila | 19:09 |
| AmanicA | and thanks for merging it! | 19:09 |
| jam | vila: btw, I reviewed your stacking test patch, but accidentally hit submit early | 19:10 |
| jam | wait for the second email | 19:10 |
| eydaimon | any plans to add neatbeans support? (plugin) | 19:10 |
| ronny | awilkins: k, thx | 19:13 |
| mtaylor | stacking rules | 19:22 |
| mtaylor | thanks all | 19:22 |
| mtaylor | is there a way to push something in 1.6 format to launchpad, but tell it not to stack on anything? (I want it to be a stacking source itself, and the default launchpad branch is still in non-1.6 format) | 20:00 |
| nDuff | Will any of the upcoming changes (ie. "views") make it easier to divorce on-disk and in-store file representations to the point of having more than one in-store object for a given in-filesystem one? I have a tree-structured file format which is better represented for to the merge algorithm and such as being a directory tree rather than a single file (the format is such that generating IDs that persist during document restructurings and conten | 20:48 |
| nDuff | t changes is straightforward). Right now I have a bunch of bzrlib code that handles serialization/deserialization and write the whole thing out to the underlying filesystem for the working tree... but it's probably not all that portable to (say) Windows, where I'd be hitting pathname-length restrictions; it'd be nice if the whole thing could be bzrlib calls without the need to get the FS involved. | 20:48 |
| awilkins | Why do some pushes want to lock the source branch, and some don't? | 21:08 |
| awilkins | I have a repository on a write-only media that I'm pushing to another disk and some of the folders it refuses to push because it's trying to lock the source branch. | 21:10 |
| awilkins | Aha, I think I get it ; it's trying to set the push_location | 21:17 |
| awilkins | Let me just check that. | 21:18 |
| NfNitLoop | I love being able to continue committing to bzr when our svn server goes down. :p | 21:18 |
| NfNitLoop | (which it just did.) | 21:19 |
| * awilkins wonders why he just doesn't copy the whole shebang wholesale to a writable drive and do it there. | 21:19 | |
| NfNitLoop | awilkins: what about branching/pulling from the destination? | 21:20 |
| awilkins | That could work, but more of a fiddle for new branches | 21:20 |
| awilkins | I've just copied the folder to a writable drive and I'll run the same script there | 21:21 |
| awilkins | Just don't want to lose newer revisions | 21:21 |
| NfNitLoop | lose newer revisions? | 21:21 |
| awilkins | Yes, the target repo may have more revisions than the old one | 21:22 |
| NfNitLoop | aah, then you don't want push anwyay. | 21:22 |
| awilkins | Why not? | 21:22 |
| awilkins | push is fine, doesn't overwrite newer revisions | 21:22 |
| NfNitLoop | really? I thought if you tried to push to something that had newer revisions it would tell you to merge first. | 21:22 |
| awilkins | These have no tree | 21:23 |
| LarstiQ | you two are saying the same thing | 21:23 |
| LarstiQ | or well, almost | 21:23 |
| * NfNitLoop tests. | 21:23 | |
| LarstiQ | when diverged, push won't overwrite unless you tell it to. When the remote is a superset, there is nothing to do. | 21:24 |
| awilkins | The read-only repo is because our mighty IT overlords decided that external USB media were a security risk and reduced all non-expensive-encrypted drives to read-only mode | 21:24 |
| * LarstiQ blinks | 21:24 | |
| LarstiQ | so you can only write to expensive-encrypted drivers? | 21:25 |
| awilkins | I say expensive-encrypted because apparently TrueCrypt volumes are not as good as £64-for-2GB McAffee super-super-drives | 21:25 |
| awilkins | Hence "expensive" | 21:25 |
| LarstiQ | right | 21:25 |
| awilkins | The 16GB one is £360 | 21:25 |
| awilkins | What's that in USD....$534 | 21:26 |
| NfNitLoop | ... | 21:27 |
| NfNitLoop | I hope they pay you well. :) | 21:27 |
| awilkins | I'm just moving the data onto my laptop drive and serving it up from a smart server. | 21:27 |
| awilkins | Although having it on a thumb was mucho convenient | 21:27 |
| NfNitLoop | LarstiQ: ah, yes, I forgot the case where the destination is a superset of the push source. | 21:27 |
| NfNitLoop | awilkins: do they allow outbound ssh connections? | 21:28 |
| NfNitLoop | once you've got it copied to a personal server, you can always just keep work & home in sync via the network. | 21:28 |
| awilkins | That's one idea, but my upstream at home sucks and I don't really want to keep my power-hungry desktop running all day | 21:29 |
| awilkins | Bah, the pushes had succeded anyway | 21:29 |
| awilkins | It was just throwing errors about updating the push target on the branches that had none | 21:29 |
| awilkins | I'm just going to manually start a bzr:// server on the laptop and bind heavy-co on the desktop to it | 21:30 |
| NfNitLoop | that works. | 21:31 |
| === abentley1 is now known as abentley | ||
| fullermd | Step 4 of http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/12353 gives an amusing (well, to those not doing it) result of git's move heuristics... | 22:01 |
| awmcclain | Is it possible to configure bzr to automatically pass off conflicts to a user-defined shell command? | 22:01 |
| fullermd | Don't think so. You could parse the output of 'conflicts' maybe... | 22:02 |
| awmcclain | fullermd: No conflict hook, I'm thinking, right? | 22:03 |
| LarstiQ | I don't think so | 22:04 |
| awilkins | What it really needs is an alternate-merge-hook | 22:04 |
| awilkins | Or merge plugins | 22:04 |
| awilkins | I'm doing it after the fact with a script and an external tool | 22:05 |
| LarstiQ | merge types at least are pluggable | 22:06 |
| awilkins | Isn't that a "whole merge" thing? | 22:07 |
| LarstiQ | awilkins, awilkins: what do you do in your scripts? | 22:07 |
| LarstiQ | awilkins: yes | 22:07 |
| awilkins | merge ; check for conflicts ; for each conflict { try external merge tool } ; try auto-resolve ; check for conflicts ;if conflicts then gconflicts | 22:08 |
| LarstiQ | ah, ok | 22:09 |
| awmcclain | awilkins: Ooo... care to share your script? | 22:12 |
| awilkins | awmcclain: It's powershell, that useful to you? | 22:13 |
| awmcclain | awilkins: Not really, but I could port it to bash. | 22:13 |
| awilkins | http://pastebin.ubuntu.com/88808/ | 22:14 |
| * LarstiQ could port that to python | 22:15 | |
| awmcclain | awilkins: What's bzr qcommit? | 22:16 |
| awmcclain | awilkins: (Thank you, btw) | 22:16 |
| awilkins | A command from the qbzr plugin | 22:16 |
| awilkins | Commit with pretty interface | 22:16 |
| awmcclain | awilkins: Gotcah. | 22:16 |
| awmcclain | awilkins: "Quick commit? I want that!" | 22:16 |
| awilkins | There is some domain-specific fluff in there | 22:17 |
| awilkins | On looking, I also see optimizations peeking out at me | 22:18 |
| awmcclain | awilkins: Yeah, not too bad. What's BC3? | 22:18 |
| awilkins | Beyond Compare 3 ; http://scootersoftware.com | 22:19 |
| awilkins | Payware that I'm reasonably happy about coughing up for | 22:20 |
| awilkins | only $19 a seat, cheaper in bulk | 22:20 |
| awmcclain | Ah yes. | 22:20 |
| awilkins | Well, it used to be | 22:20 |
| awilkins | Bit more for the pro versions now | 22:20 |
| cr3 | is there a way to upgrade my bzr branches on Launchpad: Format <RepositoryFormatKnit1> for bzr+ssh://cr3@bazaar.launchpad.net... is deprecated - please use 'bzr upgrade' to get better performance | 23:16 |
| cr3 | nevermind, it seems that bzr upgrade over sftp should work | 23:30 |
| spiv | cr3: bzr upgrade over bzr+ssh should work too, with a reasonably recent client. (It won't be any faster than sftp, though.) | 23:36 |
| cr3 | spiv: it went pretty fast over bzr+ssh, so I suppose that means my version isn't recent enough. it's been running for a while over sftp, so I'll just sit tight | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
