| === tommieb is now known as t0mm13b | ||
| jam | spiv: I cheated, I submitted each one as being proposed to the previous one, rather than bzr.dev | 00:38 |
|---|---|---|
| poolie | jam, good point about testing the readdir change | 00:46 |
| poolie | i had not yet done it | 00:46 |
| igc | poolie, jam: http://bazaar-vcs.org/Benchmarks | 01:49 |
| igc | lifeless, spiv, vila: ^^^ | 01:49 |
| spiv | igc: the numbers for samba are pretty weird! | 01:52 |
| igc | spiv: very. fastimport does an implicit pack at the end so maybe there's an obscure bug in that | 01:53 |
| igc | spiv: or maybe samba's trunk is very dull vs other branches? | 01:54 |
| spiv | Also that the fully packed size is an order of magnitude smaller that git, unlike in the other tests. | 01:54 |
| poolie | igc, i saw that earlier | 01:56 |
| poolie | maybe before your changes | 01:56 |
| igc | poolie: yep, new figures | 01:56 |
| poolie | http://bazaarvcs.wordpress.com/2009/10/08/bzr-size-benchmarks/ | 01:56 |
| SamB_XP | are they pretty figures ? | 01:56 |
| igc | poolie: the early hg figures were 'du -sb' instead of 'du -sh' - we're even more impressive now! | 01:58 |
| poolie | ? | 02:03 |
| poolie | oh, ignoring gas at the end of the files | 02:03 |
| igc | yeah, real vs apparent size | 02:03 |
| igc | actual size taken on disk is more meaningful IMO | 02:04 |
| poolie | yes | 02:04 |
| SamB_XP | not just your opinion! | 02:04 |
| SamB_XP | in actual practice, too! | 02:05 |
| mwhudson | wow yeah, those samba numbers are cracful | 02:13 |
| === abentley1 is now known as abentley | ||
| lifeless | poolie: hai | 02:57 |
| lifeless | igc: interesting | 02:59 |
| igc | hi lifeless | 02:59 |
| lifeless | igc: its not clear to me what the 'bzr branch' column means | 02:59 |
| igc | lifeless: see 'how we tested' | 02:59 |
| lifeless | I have | 03:00 |
| igc | lifeless: maybe it needs a different column heading? | 03:00 |
| igc | so it's what a user gets when they grab just the trunk | 03:00 |
| lifeless | step four in the process looks like one command | 03:00 |
| lifeless | 'bzr trunk only' | 03:01 |
| lifeless | or something, would be clearer | 03:01 |
| igc | ok | 03:01 |
| lifeless | it would be good to have a comparison figure for that too with hg/git | 03:01 |
| lifeless | I realise that that is trickier to accomplish in git/hg | 03:01 |
| lifeless | so I wouldn't suggestspending mondo time on it | 03:02 |
| lifeless | ayhow, those numbers are very encouraging; the samba project figure is a bit disappointing | 03:02 |
| lifeless | I presume that fast-import is cleaning obslete now? | 03:02 |
| igc | lifeless: I'm wondering if it's a bug in fast-import? or pack? | 03:02 |
| igc | yep | 03:03 |
| igc | lifeless: it does a pack at the end and then deletes the obsolete packs | 03:03 |
| lifeless | igc: repository-details may help diagnose | 03:03 |
| d1b | lifeless: figure out that group-pack problem re large binary files ? | 03:33 |
| d1b | / else. or should i file a bug. | 03:33 |
| RenatoSilva | Is losing secondary comments the only disadvantage of bzr revert --forget-merges when merging branches? | 03:37 |
| AfC | Is there a magic way to use meld when going through a conflicting file? | 03:42 |
| AfC | I realize that `bzr diff --using meld` does just that, but in the case of a conflict I'm trying to figure out if there's a better way to use it than manually doing | 03:43 |
| AfC | $ meld src/bindings/org/gnome/gtk/LinkButton.java.THIS src/bindings/org/gnome/gtk/LinkButton.java.OTHER | 03:43 |
| AfC | as I just did | 03:43 |
| lifeless | d1b: the one where I explained bzr is operating as designed ? | 03:51 |
| lifeless | d1b: you can file a wishlist bug on that if you like | 03:51 |
| jam | lifeless: what is that, no deltas between pack files? | 03:56 |
| jam | hey igc, the numbers look interesting. very good except for samba looking a bit crazy | 03:56 |
| igc | jam: yeah. I was hoping you'd get curious and tell me why :-) | 03:57 |
| jam | igc: I'd need the source data | 03:57 |
| jam | I thought there was something about samba copying a bunch of v3 or v4 stuff into another tree | 03:58 |
| jam | it may be that we end up tracking those separately | 03:58 |
| jam | and not getting the right cross-file compression | 03:58 |
| jam | igc: is the data accessible somewhere? | 03:59 |
| lifeless | jam: no, N identical parallel files | 03:59 |
| jam | jelmer: ^^ can you comment about the shape of the samba tree? | 03:59 |
| igc | jam: I'll push the imported repo somewhere and email you the location | 03:59 |
| bob2 | RenatoSilva: out of interest, why? | 04:00 |
| igc | jam: also http://bazaar-vcs.org/BzrPopularity is interesting | 04:00 |
| RenatoSilva | bob2: because I want to use it :) | 04:02 |
| jam | lifeless: you're talking about d1b's issue, right? (or samba?) | 04:02 |
| RenatoSilva | bob2: but I wonder if I'm doing WOP | 04:03 |
| lifeless | jam: both possibly | 04:03 |
| lifeless | jam: but intending to speak on dib's | 04:03 |
| bob2 | RenatoSilva: don't know what that means | 04:04 |
| jam | lifeless: so the idea is that multiple identical files aren't getting fully de-duped? | 04:04 |
| jam | igc: i agree. Interesting that we are above hg, and the 39k there is close to the 36.7k that downloaded bzr-setup 1.13 | 04:04 |
| RenatoSilva | bob2: http://uncyclopedia.wikia.com/wiki/Workaround_Oriented_Programming | 04:05 |
| bob2 | RenatoSilva: what are you working around? | 04:05 |
| lifeless | ja80MB images/movies | 04:05 |
| lifeless | jam: 80MB movie files; separate file ids | 04:06 |
| RenatoSilva | bob2: I don't know, that's why I wonder :) | 04:06 |
| igc | jam: right: the 39k is the combination of the different Windows installers | 04:06 |
| igc | roughly | 04:06 |
| bob2 | RenatoSilva: why are you reverting the merge metadata to begin with? | 04:06 |
| jam | lifeless: yeah, and we explicitly cap a group based on file-id | 04:06 |
| RenatoSilva | bob2: the Portuguese version is so much better description :) http://desciclo.pedia.ws/wiki/Programa%C3%A7%C3%A3o_Orientada_a_Gambiarras | 04:06 |
| jam | igc: I mean that popcon says 39k for installs, and we have ~39k downloads | 04:07 |
| lifeless | jam: we did use too much memory though | 04:07 |
| jam | lifeless: how much? | 04:07 |
| jam | I would expect at least 160MB | 04:07 |
| jam | since they aren't likely to zlib well | 04:07 |
| wgrant | Note that popcon isn't reliable at all. | 04:07 |
| jam | wgrant: as in a margin of error of 100%, or 20% | 04:08 |
| wgrant | jam: Potentially thousands of percent. | 04:08 |
| AfC | I have no idea why you are counting downloads. I mean, other distros? People who don't have popcon installed? | 04:08 |
| jam | I was mostly commenting about how close the numbers were | 04:08 |
| wgrant | jam: It's optional, and well hidden in the installer. | 04:09 |
| jam | AfC: number of downloads of the windows installer is probably pretty accurate, since there is one "canonical" source | 04:09 |
| wgrant | jam: So not only will most people not have it turned on, those that do will be a very skewed sample. | 04:09 |
| RenatoSilva | bob2: I'm not reverting, but since I knew about --forget-merges, I thought it was nice when the merge commit can summarize all the work done during the secondary branch | 04:09 |
| bob2 | RenatoSilva: that's what happens when you don't --forget-merges | 04:10 |
| lifeless | jam: intwo swap n a 2400MB vm or something like that | 04:10 |
| jam | lifeless: would it be a repack? | 04:10 |
| lifeless | jam: no, single commit | 04:10 |
| jam | hmm... something funny then | 04:11 |
| lifeless | sorry, that was a 400MB vm I meant to type, damn hotel latency | 04:11 |
| jam | I did quite a bit of testing w/ a 120MB text file | 04:11 |
| jam | though that zlib'd very well | 04:11 |
| AfC | jam: well, I can tell you that one of the biggest reasons that Sun screwed up Java was that they restricted mirroring *specifically* so that they could count downloads. That alone probably cost them the existence of .Net. | 04:11 |
| AfC | jam: But in Open Source we don't count users because we *cannot*. ~10 distros with significant user bases, all of which have broad mirror networks. Corporate installations with no outside connectivity. | 04:11 |
| AfC | you know all that of course | 04:11 |
| AfC | which is why I was *flabbergasted* to see Emma mention that was on your website. | 04:12 |
| jam | AfC: we phone home :) | 04:12 |
| jam | wait... no we don't | 04:12 |
| aglauser | Hi, new bzr user here (Windows) | 04:13 |
| aglauser | A quick question about .bzrignore, if I may. | 04:13 |
| lifeless | shoot | 04:14 |
| spiv | aglauser: sure | 04:14 |
| aglauser | I can't seem to work out the syntax for ignoring an entire subdirectory, with out ignoring other directories with the same name | 04:14 |
| jam | aglauser: ./path/to/subdir | 04:14 |
| jam | needs a '/' | 04:14 |
| jam | you can use './foo' to get one at the top level | 04:14 |
| RenatoSilva | bob2: as I said, I'm not reverting. But it seems to me that the only diff is that I lose the secondary revision info. That is, it's just like the diffs introduced by the merge were made directly in trunk | 04:15 |
| aglauser | Does the /**/ glob still work, or was that only older versions? I'm at 2.x | 04:15 |
| fullermd | RenatoSilva: No, you ARE reverting. You're just not reverting the _files_. All you're doing is building up hurt against future merges. | 04:15 |
| bob2 | RenatoSilva: it is unclear to me why you're doing this, but ok | 04:15 |
| jam | aglauser: ** should work | 04:15 |
| fullermd | I mean, if you don't want to track merges, you can just use CVS :p | 04:15 |
| bob2 | RenatoSilva: new versions of bzr already hide the merged revisions in log output, if that is your concern | 04:16 |
| RenatoSilva | bob2: and that seems nice to me when e.g. your secondary branch has only one commit or all the changes can be summarized on a single commit comment | 04:16 |
| RenatoSilva | fullermd: huh??? | 04:16 |
| bob2 | RenatoSilva: which is what bzr does already | 04:16 |
| bob2 | RenatoSilva: 'bzr log' on 1.18+ iirc | 04:16 |
| RenatoSilva | fullermd: I'm NOT reverting. I'm writing on IRC. I'm talking about an idea. I'm not even running bzr. So huh? | 04:16 |
| fullermd | Well, I'm not putting 2 level teaspoons of arsenic in my coffee either, but I wouldn't expect people on IRC to tell me it's a good idea if I suggested it :p | 04:17 |
| fullermd | ... well, OK, maybe they would... | 04:17 |
| SamB_XP | fullermd: tell me who so I can avoid them! | 04:18 |
| aglauser | Thanks, it seems I've got the right pattern now. I think the ./ was the key | 04:18 |
| RenatoSilva | bob2: ok, but I want to know of any other problems IF I use --forget-merges | 04:19 |
| bob2 | RenatoSilva: you lose all the merge metadata | 04:19 |
| bob2 | RenatoSilva: I don't understand why you would do it at all | 04:19 |
| spiv | RenatoSilva: you lose bzr's record that those revisions are already merged. So it's no better than applying a diff with patch. bzr uses the revision history to calculate merges, so if you forget that data then bzr can't calculate merges as usefully... which means you will get unnecessary conflicts. | 04:20 |
| spiv | Because the next time you merge that branch, or another branch that does incorporate those revisions, bzr will think it needs to reapply those changes, because it has no record of them being merged. | 04:21 |
| RenatoSilva | bob2: bob2: my main, current reason is that I have branches with a single commmit. When I merge them I think the merge look in qlog is useless. It's a single commit and would be cleaner to have it only in the trunk line, just like I never had used another branch, but committed directly into trunk. The secondary branch was just a sandbox. | 04:22 |
| Peng_ | RenatoSilva: You could use "pull" instead of "merge", I suppose. | 04:23 |
| spiv | So use pull, or even "bzr merge --pull". | 04:23 |
| bob2 | or fix qlog to work like log | 04:23 |
| SamB_XP | bob2: that would hardly be a fix! | 04:24 |
| fullermd | Actually, qlog already IS collapsed by default... | 04:24 |
| spiv | Right, there's no reason why qlog couldn't have a heuristic to hide single-revision branches from the mainline by default (I'm surprised it doesn't already). | 04:24 |
| jam | spiv: it defaults to hiding everything until you click the twisty | 04:25 |
| spiv | But if the concern is literally "I want the new revision to be directly on the end of the existing history", then that's what pull is for, so I'd say use that. | 04:25 |
| RenatoSilva | spiv: those conficts only if I try to merge the updated secondary branch again, right? But in my case I'd delete the branch right after merging. But ok, it's the same as diff + patch, which seems easier btw :) | 04:25 |
| jam | I happen to disagree with RenatoSilva's analysis that it is "worthless" | 04:25 |
| jam | but perhaps.. | 04:25 |
| RenatoSilva | Peng_: I use pull when I can, but sometimes I need merge | 04:25 |
| lifeless | RenatoSilva: I think you should do this if it makes you happy. | 04:26 |
| lifeless | RenatoSilva: understand that *if* you have other people building on the source branch, you will be creating future conflicts when you do this. | 04:26 |
| RenatoSilva | bob2: and the branches with a single commit, well when I change them I tend to uncommit and commit again... | 04:26 |
| lifeless | bob2: Peng_: fullermd: spiv: This is a great example of one of the use cases in my history-edting manfesto | 04:26 |
| spiv | lifeless: *nod* | 04:27 |
| RenatoSilva | jam: what's worthless? | 04:27 |
| jam | lifeless: I'm curious if you saw http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html from today | 04:31 |
| jam | its what I did to get the static-tuple stuff up for review | 04:31 |
| jam | breaks the changes into diffs post-facto, *and* preserves annotations | 04:31 |
| * RenatoSilva gave up of using rebase, ihrc the timeline becomes unordered (the rebased revision is greater in number, but older in date o.O ) | 04:31 | |
| * RenatoSilva suffers the uncommit syndrome | 04:32 | |
| * RenatoSilva starts to realize that he just can't fight against the merge fact | 04:32 | |
| spiv | jam: and interestingly they still appear on https://code.edge.launchpad.net/bzr/+activereviews | 04:32 |
| jam | spiv: they are on the bzr project, and I requested bzr-core review them | 04:33 |
| spiv | jam: although it's a shame that the ordering isn't dead-obvious, but it's not hard to discover. | 04:33 |
| jam | spiv: yeah, I submitted them "in order" | 04:33 |
| jam | so if you go by the "22 hours ago" vs "10 hours ago" you can use that as a guide :) | 04:33 |
| jam | also it is sorted correctly in my view, but I see them in the "I am waiting on" section. | 04:34 |
| lifeless | jam: I hadn't no | 04:35 |
| lifeless | not much time to read during sprints | 04:35 |
| spiv | jam: you also get forward and back links, of a sort, on the individual branch pages. | 04:35 |
| jam | spiv: ah sure, because I requested to merge it into the other branch | 04:35 |
| jam | it is unfortunate I'll probably have to do the "merged" manually | 04:36 |
| spiv | jam: "proposal or merging into X", and "N branches proposed for merging into this one" | 04:36 |
| jam | but that is worth having small diffs for review | 04:36 |
| lifeless | jam: thats what I want loom to manage | 04:36 |
| jam | lifeless: the main thing is doing it at the *end* after I've done all the work in a dogpile | 04:37 |
| lifeless | jam: yes | 04:37 |
| jam | especially when exploring, it is hard to figure out what your separations are going to be (at least for me) | 04:37 |
| jam | also, it allows avoiding the "spurious merges" between the loom threads | 04:37 |
| lifeless | jam: I'm saying loom should support post hoc separation | 04:38 |
| jam | lifeless: sure | 04:38 |
| jam | I think the main difference is that loom would probably want to start from the 'upstream' thread, and I was more branching from downstream | 04:39 |
| jam | I think 'up' does basically what I was doing with my merges | 04:39 |
| lifeless | jam: I don't see why it would :) | 04:39 |
| RenatoSilva | are plugins written to 1.x fully compatible with bzr 2.0? | 04:40 |
| SamB_XP | RenatoSilva: depends | 04:40 |
| jam | RenatoSilva: many, but I wouldn't say all | 04:41 |
| SamB_XP | but mostly they can be easily made to work | 04:41 |
| SamB_XP | if they worked for a recent 1.x | 04:41 |
| jam | 1.18 vs 2.0 is "as big" of a difference as 1.17 vs 1.18 | 04:43 |
| jam | interestingly enough 2.0 vs 2.1 will be a bigger difference | 04:43 |
| jam | but we are changing numbering systems | 04:43 |
| RenatoSilva | jam: iirc I use xmloutput and bzr-email only | 04:43 |
| jam | so it is actually 2.0.0 vs 2.1.0 | 04:43 |
| RenatoSilva | jam: will wait a bit more then :) | 04:43 |
| jam | RenatoSilva: bzr-email works fine | 04:43 |
| jam | xmloutput... I know we bundle it with the windows installer | 04:44 |
| jam | so there should be *a* version that just works | 04:44 |
| lifeless | RenatoSilva: move to 2.0.0 as soon as you can ;) | 04:44 |
| * igc lunch | 04:44 | |
| RenatoSilva | jam: with the windows installer? not in 1.x right? Can't remember of it being listed there | 04:46 |
| RenatoSilva | jam: I submitted some fixes to xmloutput that were merged but not release,d it is still in 0.8.3. So either you have a modified version in 2.0 or the 0.8.3 or trunk has no need to change in 0.8.3 right | 04:47 |
| jam | RenatoSilva: I think we started with 2.0 | 04:47 |
| jam | RenatoSilva: we packaged "bzr-xmloutput-release = 0.8.5" | 04:47 |
| jam | not sure what makes you say it is still at 0.8.3, but there is a tag in the branch @ 0.8.5 | 04:47 |
| RenatoSilva | jam: you're from canonical right? it would be nice if you release your private, improved version of bzr-email. The one currently there is a bit simple | 04:48 |
| jam | RenatoSilva: I don't know of a "private, improved version" | 04:48 |
| jam | I use the stock version from "bzr branch lp:bzr-email" | 04:48 |
| RenatoSilva | jam: release 0.8.5???? let me check that, I thought I was subscribed to the branch.... | 04:48 |
| jam | but yes, I' min canonical | 04:48 |
| RenatoSilva | jam: e.g. public bzr-email does not have html, and does not allow customization of body/subject, and does not work for me without a patch | 04:49 |
| jam | RenatoSilva: I thought I saw something about html being mentioned on the mailing list, but I've never used it or seen it | 04:50 |
| jam | RenatoSilva: "doesn't work for you" ? | 04:50 |
| jam | have you proposed the patch? | 04:50 |
| RenatoSilva | jam: the emails sent by LP when you change branches are done by something similar to bzr-email, but not released to the public | 04:50 |
| lifeless | RenatoSilva: LP's code is public | 04:51 |
| lifeless | RenatoSilva: its not a bzr plugin though | 04:51 |
| RenatoSilva | jam: something about TLS | 04:51 |
| jam | RenatoSilva: grab the latest from the bzr-email branch | 04:51 |
| jam | I'm pretty sure that is fixed | 04:51 |
| jam | may not be in a tarball, etc | 04:51 |
| jam | though it is packaged for Karmic ( I checked with james_w just a couple weeks ago) | 04:51 |
| RenatoSilva | jam: this is the patch to make it work: https://code.launchpad.net/~renatosilva/bzr-email/ignore-tls | 04:52 |
| RenatoSilva | jam: I don't know if you mean what's done here | 04:53 |
| jam | http://bazaar.launchpad.net/~renatosilva/bzr-email/ignore-tls/revision/40 | 04:54 |
| jam | though you build on top of that, so obviously something is different in your situation | 04:54 |
| RenatoSilva | jam: see bug https://bugs.launchpad.net/bzr-email/+bug/388723 | 04:59 |
| ubottu | Launchpad bug 388723 in bzr-email "SSL error on starttls()" [Undecided,New] | 04:59 |
| RenatoSilva | jam: it's a hand shake error, maybe and likely server problem, but I thought it would be nice to allow users not being affected by such broken servers | 05:01 |
| RenatoSilva | jam: so I created the disabling option, it's working fine with me now. | 05:01 |
| RenatoSilva | latest version of bzr-xmloutput is 0.8.4, from where did you get 0.8.5 to pack together with 2.0? | 05:13 |
| RenatoSilva | https://launchpad.net/bzr-xmloutput | 05:13 |
| lifeless | poolie: gnight; we can try to hook up sunday avo or something | 05:19 |
| lifeless | poolie: or perhaps my morning (7hr from now) | 05:19 |
| mneptok | lifeless: you're not in AUS/NZ? | 05:28 |
| poolie | ok | 05:42 |
| RenatoSilva | thanks all | 05:42 |
| poolie | wow nice work igc | 05:43 |
| poolie | you should send that to the bazaar list too | 05:43 |
| igc | poolie: which bit? | 05:53 |
| poolie | the benchmarks and the mail about them | 05:53 |
| igc | ok | 05:54 |
| poolie | if you want to | 05:54 |
| poolie | hi spiv | 05:54 |
| spiv | poolie: good afternoon | 05:55 |
| poolie | how's stuff? what are you up to? | 05:55 |
| spiv | I'm reading through jam's patch flood. | 05:56 |
| spiv | I'm greatly looking forward to cutting our memory consumption! | 05:56 |
| igc | spiv: me too! I was hoping you'd choose to review those patches (with your Python internals knowledge) | 05:57 |
| spiv | Also used -Drelock to squash a simple (and probably not very wasteful in practice) relock in cmd_missing, mainly to see what it feels like. I'm going to leave -Drelock on in my bazaar.conf for a while and see if that encourages me to squash some easy bugs. | 05:58 |
| spiv | It's a bit depressing that almost every command trips it, though. | 05:58 |
| spiv | I'm particularly wondering about extending the -Drelock thing to allow writing test assertions about it. | 05:59 |
| spiv | I don't know that we really want to explicitly add "assertNoRelockingHappened" or whatever to lots of individual tests, but it would be nice to find and easy-yet-firm way to drive it towards zero instances. | 06:00 |
| spiv | But maybe blackbox tests could test for that by default, and then individual tests or test cases could opt out? | 06:01 |
| spiv | Oh, and I spent some time (re)reading the summary of the London meeting. | 06:03 |
| d1b | lifeless: no. | 06:21 |
| d1b | the one where it took 11 minutes to commit the large files into the bzr repo. | 06:22 |
| d1b | also most 4 times longer than the time to copy the files. | 06:22 |
| d1b | however, i am tempted to go and have a look at the code, and submit a patch for where a file is sufficiently large to store and make comparisons against a sha1 or similar hash of the file. | 06:23 |
| poolie | spiv, could you review jam's cix patch, if you didn't alread? | 06:23 |
| d1b | that obviously will require other changes to ensure that the binary files are kept avilable for the various locations in the repository (if one changes the others shouldn't etc.). | 06:24 |
| poolie | d1b, you're committing a rename of a large file? | 06:24 |
| d1b | poolie: it was a worst case senario i ran bzr 2 against, 5 167mb video files. | 06:24 |
| d1b | the files were identical | 06:25 |
| poolie | under different names? | 06:25 |
| d1b | poolie: yes. | 06:25 |
| poolie | k | 06:25 |
| poolie | probably best to start by profiling it and looking at the developer docs on profiling | 06:26 |
| d1b | poolie: lifeless already has a kcachegrind / valgrind dump thingy. | 06:26 |
| d1b | poolie: a workaround would be to not try to group-compress large binary files. | 06:27 |
| spiv | poolie: ok | 06:36 |
| poolie | cool | 06:38 |
| igc | spiv: what's .bzr/upload for? any ideas? why would there be a xxxxxx.reconcile file in there? | 06:51 |
| igc | poolie: ^^^ | 06:52 |
| spiv | igc: do you mean .bzr/repository/upload ? | 06:58 |
| spiv | igc: it's where pack files are created initially. Once all the content has been added and the pack file finished, then they are moved from upload/ to packs/ and then added to pack-names. | 06:59 |
| spiv | igc: similarly indices. | 07:00 |
| igc | spiv: thanks | 07:00 |
| spiv | igc: the name they are given in upload/ has a suffix that varies depending on which code path created it. *.reconcile is made by the ReconcilePacker (or the GC variant, etc) | 07:00 |
| igc | spiv: right. so a crash of reconcile leaves a xxx.reconcile file there. It makes sense now | 07:01 |
| spiv | igc: which is a long-winded way of saying "you probably hit ^C or similar during a 'bzr reconcile' at some time :)" | 07:01 |
| igc | spiv: nah, reconcile is falling over for keybuk | 07:01 |
| spiv | Ah, right. | 07:01 |
| spiv | Yes, that'd do it. | 07:02 |
| igc | i can reproduce it | 07:02 |
| arjenAU | lifeless: i am going to kick you later for being too smart a nerd. | 07:03 |
| arjenAU | lifeless: ok so skipping the nistallation bit... how do I actually use the bzr-hg tool. commands, syntax on bzr branch, whatever?? | 07:05 |
| vila | hi all | 07:21 |
| igc | bbiab | 07:44 |
| poolie | nice post there | 08:00 |
| poolie | arjenAU: basically you can just urls to hg repositories | 08:00 |
| poolie | there are no new commands | 08:00 |
| arjenAU | poolie: ok so back one step. how do I install the sucker | 08:14 |
| arjenAU | poolie: all these plugins are lacking in docs. I'm not a python person | 08:14 |
| poolie | are you on ubuntu? | 08:14 |
| poolie | i think it's in the ppa? | 08:14 |
| arjenAU | hmm didn't show up in synaptic. I am on the PPA | 08:15 |
| poolie | no, it's not | 08:15 |
| arjenAU | I grabbed the tarball and did python thingie build and then install. no worky | 08:15 |
| bialix | hello all | 08:15 |
| bialix | igc: what is scary numbers for Samba import? | 08:15 |
| poolie | bialix, this one i think: https://launchpadlibrarian.net/21176883/gwibber.64x64.png | 08:16 |
| poolie | blah | 08:16 |
| poolie | http://bazaar-vcs.org/Benchmarks | 08:16 |
| bialix | yes, benchmarks | 08:16 |
| bialix | and why Firefox trunk bigger than import? | 08:16 |
| bialix | questions, questions... | 08:16 |
| poolie | different packing maybe? | 08:16 |
| bialix | or trunk is branch + tree? | 08:17 |
| bialix | and import is treeless? | 08:17 |
| bialix | somebody should explain | 08:17 |
| bialix | really guys | 08:18 |
| poolie | well, reply to ian and ask | 08:18 |
| bialix | if it's even for me wtf -- then you can expect many gibes from outside | 08:19 |
| poolie | there is a page of details but it doesn't say what trunk only is | 08:19 |
| * poolie burned out | 08:19 | |
| poolie | good night | 08:19 |
| bialix | night | 08:19 |
| wgrant | Why does the bzr home page now say "rockin'" and give a nonsensical user count? | 08:27 |
| bialix | where? | 08:29 |
| wgrant | Near the bottom, just above the anonymous logos. | 08:30 |
| bialix | ah see | 08:30 |
| wgrant | I recognise them, but I imagine most will not... | 08:30 |
| * bialix don't know what is purple cog icon means | 08:31 | |
| * bialix as well as globe | 08:31 | |
| bialix | I dunno, emmajane and igc constantly improving this page | 08:32 |
| bialix | there is branch with page source | 08:32 |
| wgrant | The purple thing is GNOME Do, the globe is Gwibber. | 08:35 |
| bialix | clearly Gnome/Ubuntu centric point of view | 08:35 |
| * bialix goes away for my work on windows xp | 08:36 | |
| bialix | :-P | 08:36 |
| mneptok | bialix: do you know of any Windows software projects using bzr? if so, suggest they be added. | 08:38 |
| igc | hi bialix | 08:43 |
| igc | bialix: I just run the commands. Exactly what pack does under the covers is outside my depth of knowledge | 08:44 |
| igc | bialix: but fast-import imports a whole repository while 'branch' just grabs the revisions referenced by trunk | 08:45 |
| bialix | mneptok: it should be a BIG project right? no I don't know | 08:45 |
| mneptok | bialix: not necessarily. but something at least noteworthy. | 08:46 |
| bialix | igc: I suppose Bazaar Import size is the size of treeless shared repo? and trunk is the sizer branch with tree? | 08:46 |
| bialix | mneptok: oh, I know many. QBzr per example. It will count? | 08:46 |
| bialix | PhotoBatch, Leo editor | 08:47 |
| bialix | there is page with links to these projects | 08:47 |
| mneptok | bialix: ask emmajane or igc :) | 08:47 |
| igc | bialix: import size is just repo size - see "how we measured" link | 08:47 |
| bialix | du -sh? | 08:48 |
| igc | bialix: branch size is still just the .bzr size - there's no point comparing the working tree as it's the same across each tool | 08:48 |
| bialix | that's nice that I know what du is | 08:48 |
| bialix | but this is not windows utility | 08:48 |
| igc | h=human readable | 08:49 |
| igc | s=summary (don't show each subdirectory) | 08:49 |
| bialix | will be much simpler if you just wrote in plain english | 08:49 |
| igc | the plain english bit is the directories being compared :-) | 08:50 |
| bialix | mneptok: http://bazaar-vcs.org/WhoUsesBzr | 08:50 |
| bialix | igc: then I'm bad in english today. Sorry and nm | 08:51 |
| maxb | bzr qlog is amazing, but its revision sorting algorithm is a bit suboptimal. It seems to optimize keeping the trunk revisions consecutively displayed, at the cost of vastly increasing the horizontal space used for the graph | 08:55 |
| bialix | maxb: this is because in bzr mainline is special | 08:56 |
| bialix | igc: also I think 36K windows downloads is extreme. | 08:57 |
| bialix | igc: for most releases this number is order of magnitude smaller | 08:57 |
| bialix | I dunno why 1.13.1 so big, but it seems pretty wrong for me | 08:57 |
| wgrant | Attempting to put correct numbers there is an exercise in foolishness. | 08:57 |
| bialix | I agree | 08:58 |
| bialix | I dunno why there is need numbers | 08:58 |
| bialix | foolishness is good word | 08:58 |
| * wgrant should probably check the list for similar complaints. | 08:58 | |
| bialix | recent thread is 42,000 too much | 08:59 |
| ploum | Hello | 09:02 |
| ploum | I've a big problem | 09:02 |
| ploum | I cannot create repository on my http server anymore | 09:02 |
| ploum | I receive : | 09:02 |
| ploum | bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-3102421996:///'.") | 09:02 |
| igc | bialix: would your company be interested in putting your logo on our home page? | 09:07 |
| spiv | ploum: there's a bug about that, with a workaround: | 09:11 |
| spiv | ploum: https://bugs.edge.launchpad.net/bzr/+bug/348308 and the workaround is in comment #8 | 09:11 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] | 09:11 |
| ploum | funny, I was already subscribed to this bug but it was so old | 09:12 |
| ploum | thanks for the info | 09:12 |
| bialix | igc: unlikely :-) | 09:15 |
| bialix | we are very small company working in narrow niche | 09:15 |
| igc | bialix: we're happy to promote companies and projects using Bazaar there | 09:16 |
| igc | bialix: but QBzr is probably too close to Bazaar itself sorry | 09:16 |
| igc | bialix: i.e. users won't see it as a separate project to Bazaar | 09:17 |
| igc | bialix: by user, I mean typical home page visitor | 09:17 |
| bialix | igc>bialix: but QBzr is probably too close to Bazaar itself sorry -- I know, it was joke | 09:21 |
| bialix | igc: for my company the problem is we made embedded systems not software per se | 09:21 |
| bialix | so we have hardware which you can take in hands | 09:21 |
| bialix | software is just companion | 09:22 |
| igc | bialix: ah - ok | 09:22 |
| igc | night all - have a good weekend | 09:24 |
| bialix | bye | 09:24 |
| spiv | igc: g'night | 09:26 |
| igc | night spiv | 09:27 |
| === JaredWigmore is now known as JaredW | ||
| faldridge | can anybody help me understand the difference between bzr checkout svn+ssh://foo.com/foo vs bzr svn-import svn+ssh:///foo.com/foo? | 10:34 |
| faldridge | the main reason for my question is that I've tried the former approach twice on a history-rich svn repo and I've gotten failures both times, so I'm considering trying the other approach. | 10:35 |
| faldridge | but I don't understand the example at <http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html> on using svn-import | 10:36 |
| asabil | hi all | 10:42 |
| faldridge | hi | 10:42 |
| bialix | faldridge: can you tried to simply `bzr branch svn+ssh://foo.com/foo`? | 10:42 |
| bialix | faldridge: the main author of bzr-svn is jelmer | 10:43 |
| bialix | faldridge: always when I need a copy of svn repo of upstream I'm just running bzr branch | 10:43 |
| faldridge | bialix: I have not tried that; it wasn't listed on the bzr-svn plugin doc. What does that do differently than bzr checkout? | 10:44 |
| bialix | bzr branch will create bzr mirror of svn repo | 10:44 |
| bialix | I think it's similar to svn-import | 10:44 |
| bialix | what is the product of bzr checkout I really don;t know | 10:45 |
| bialix | can you show me the output of bzr info -v in the your checkout? | 10:45 |
| bialix | pastebin? | 10:45 |
| faldridge | bialix: I can't right now; the bz checkout svn+ssh method is also reaaaaaaally slow, and I'm in the middle of trying to grab a different history rich svn repo right now.... | 10:46 |
| bialix | ah | 10:46 |
| faldridge | bialix: is the bzr branch method faster? I could always kill the process and try it | 10:46 |
| bialix | I dunno, really | 10:47 |
| bialix | I don't expert in bzr-svn | 10:47 |
| bialix | in theory branch and checkout should be the same speed | 10:47 |
| faldridge | bialix: ok, but do you know if doing bzr branch on an svn repo is significantly slower than bzr branch on a bzr repo? | 10:48 |
| bialix | yes | 10:48 |
| bialix | because it converts from svn to bzr format on the fly | 10:48 |
| faldridge | right, thought so. | 10:48 |
| naoki | history horizon is strongly required by bzr-svn users. | 10:49 |
| bialix | history horizon? | 10:49 |
| faldridge | I really want to manage my local branches of svn-based projects with bzr, but the slowness and erratic failing may be a deal-breaker. | 10:50 |
| naoki | bzr use single connection. svn use a connection per revision. | 10:50 |
| bialix | it's not implemented yet | 10:50 |
| naoki | So bzr branch from remote svn comsumes long time. | 10:51 |
| bialix | faldridge: try to catch jelmer later (after several hours) | 10:52 |
| faldridge | bialix: will do, thanks | 10:52 |
| faldridge | naoki: is there a reason bzr doesn't use multiple connections? | 10:52 |
| naoki | I don't know. | 10:55 |
| faldridge | possibly because it doesn't need them unless pulling from an svn repo | 10:56 |
| jackalborn | i have a quick question if anyone is around | 11:01 |
| bialix | shout | 11:02 |
| jackalborn | i was wondering if it was possible to create a centralized model using my web page on godaddy as a server with bazaar | 11:02 |
| jackalborn | and if so if there was any information i could read about how to go about setting it up | 11:03 |
| jackalborn | that anyone knew of | 11:03 |
| bialix | what is godaddy? | 11:03 |
| faldridge | bialix: a popular web host | 11:03 |
| jackalborn | oh sorry, i mean to say my web host | 11:03 |
| bialix | what access do you have to it? | 11:04 |
| jackalborn | full as far as i know | 11:04 |
| bialix | http/ftp/sft/ssh? | 11:04 |
| jackalborn | lemme see | 11:04 |
| jackalborn | http/ftp/ssl/ssh? | 11:05 |
| bialix | can you install bzr there? | 11:05 |
| jackalborn | it uses MySQL databases | 11:05 |
| bialix | bzr don't use MySQL | 11:05 |
| bialix | there is 2 modes to access bzr branches: over dumb transport (http/ftp) and over smart server (bzr/bzr+ssh/bzr+hhtp) | 11:06 |
| bialix | the latter require bzr installed on your host | 11:06 |
| bialix | the former does not | 11:06 |
| bialix | if you have ssh then you have sftp IMO, sftp is also dumb transport | 11:07 |
| bialix | dumb trabsport access is usually slower as you understand | 11:07 |
| bialix | dumb transport access is usually slower as you understand | 11:08 |
| jackalborn | is one dumb transport better over another? | 11:08 |
| bialix | http is read-only | 11:08 |
| bialix | ftp is not really recommended | 11:08 |
| bialix | sftp is good enough because it's based on SSH connections | 11:08 |
| bialix | I'd say sftp for write access, and http for read-only | 11:09 |
| jackalborn | sounds do able | 11:10 |
| bialix | ftp is often works but sometimes there is quircks with different ftp servers implementations | 11:11 |
| jackalborn | looks to me like using SSH requires me to move my website to a new server and update site code / hurt my brain | 11:12 |
| bialix | jackalborn: just remember there is no special ACL support | 11:12 |
| bialix | so everything exposed via public_html will be readable by anyone, usually | 11:12 |
| jackalborn | i'm sorry i dont even know what ACL is :/ | 11:12 |
| jackalborn | ah got it | 11:13 |
| jackalborn | so the other option is setting up a machine at home and putting bzr on it and having it act as a central server? | 11:14 |
| bialix | ACL == access control list | 11:14 |
| bialix | I'm not sure what is central server for you | 11:15 |
| jackalborn | i see | 11:15 |
| bialix | how many people will work with it? | 11:15 |
| jackalborn | i've only ever used CVS and a little SVN so this is kinda new to me | 11:15 |
| jackalborn | 5 or less i'm suspecting | 11:15 |
| jackalborn | probably 3 for now | 11:15 |
| bialix | it should be private repo? | 11:17 |
| jackalborn | well i dont want just anyone coming along and walking off with our assets or code | 11:17 |
| jackalborn | if thats what you mean | 11:17 |
| bialix | there is bzr_access script to setup restricted access to smart server | 11:17 |
| bialix | jackalborn: so you need restricted access for your team | 11:18 |
| bialix | either via sftp and don't expose it via http | 11:18 |
| bialix | or via bzr+ssh | 11:18 |
| bialix | in any case sftp/ssh | 11:19 |
| jackalborn | gotcha | 11:19 |
| bialix | I've used ftp in the past | 11:19 |
| bialix | to communicate with autsourcers | 11:19 |
| jackalborn | but straigh ftp is no dice right? | 11:19 |
| bialix | it works good enough | 11:19 |
| bialix | it depends | 11:19 |
| bialix | how good is your ftp server | 11:19 |
| bialix | bzr require append access | 11:20 |
| bialix | or this is called feature? | 11:20 |
| jackalborn | i dont realy know honestly | 11:20 |
| bialix | raname support and so on | 11:20 |
| bialix | *rename | 11:20 |
| bialix | it will be easier for you to just try | 11:20 |
| jackalborn | yeah | 11:20 |
| bialix | bzr init ftp://... | 11:20 |
| bialix | bzr push ftp://... | 11:20 |
| jackalborn | i'll have to go about setting it up then | 11:21 |
| bialix | with any small history | 11:21 |
| jackalborn | so really its just making a folder on the ftp and having bzr access it? | 11:21 |
| bialix | yep | 11:21 |
| jackalborn | wowo | 11:21 |
| jackalborn | will that should be an eaasy test then | 11:21 |
| bialix | you can even setup password for ftp access in authentication.conf config file | 11:21 |
| bialix | so you don't need to type it everytime | 11:22 |
| jackalborn | sounds good | 11:23 |
| jackalborn | thank you very much for your help | 11:23 |
| bialix | always happy to help (tm) | 11:23 |
| jackalborn | i look forward to testing this out when i get the guts to once again wade into the horrors that is working with my web server. first thing in the morning :) | 11:24 |
| jackalborn | thanks bialix, have a good night | 11:24 |
| bialix | bye, it's a still day for me | 11:24 |
| sender | how should I proceed if I need a branch inside a branch? | 11:42 |
| bialix | just branch and all | 11:42 |
| sender | bialix: what I have now is one branch containing everything, I use split to move a directory from that branch to a separate branch. can I just run pull in the subbranch and then commit in the main branch? | 11:46 |
| bialix | are you asking about Nested Trees support? | 11:47 |
| sender | bialix: I guess so :) | 11:47 |
| bialix | it's not implemented yet | 11:47 |
| bialix | there is plugin that emulates it | 11:47 |
| sender | ok, interesting | 11:47 |
| sender | scmproj, right? can this be used in prod? | 11:50 |
| bialix | I'm the author and use it in production | 11:50 |
| bialix | there is many rough edges | 11:50 |
| bialix | but you can pull in subbranch and then commit | 11:50 |
| bialix | it's far from ideal | 11:50 |
| bialix | honestly | 11:51 |
| bialix | it's more like meccano | 11:51 |
| bialix | but it really works | 11:51 |
| sender | ghehe :) i like meccano | 11:52 |
| sender | Someone here tries to do this with split and join... I guess these are more configuration tools, and not the way to do Nested right? | 11:53 |
| bialix | split and join is the part of Nested Trees | 11:54 |
| bialix | scmproj is indifferent to split and join | 11:54 |
| bialix | scmproj works on the set of branches | 11:55 |
| bialix | you can define how you want to lay out your branches and then run some commands for all your branches in one go | 11:55 |
| bialix | you can "construct" your own command | 11:56 |
| bialix | it's a bit similar to how git works with submodules | 11:56 |
| sender | do you define a sort of recipe? | 11:57 |
| bialix | no | 11:57 |
| bialix | there is generic command project-command or pcmd | 11:57 |
| bialix | you supply one or several bzr commands to it, using some templates and then it runs your commands for each branch | 11:58 |
| sender | sounds good | 11:58 |
| bialix | e.g. to get bzr status for all branches you run: bzr pcmd st | 11:58 |
| bialix | to get latest log message: bzr pcmd "log -r-1 --short" | 11:58 |
| bialix | and so on | 11:58 |
| bialix | under the hood scmproj just cd to each branch and run the command there | 11:59 |
| bialix | so you get N separtate results for N branches, not 1 integrated result | 11:59 |
| bialix | this is major limitation | 11:59 |
| bialix | Nested Tress should work seemless | 12:00 |
| bialix | Nested Tress should work seamless | 12:00 |
| sender | ok, sounds workable though | 12:00 |
| bialix | one my working project consist 3 branches | 12:01 |
| bialix | 1 main branch | 12:01 |
| bialix | 1 library | 12:01 |
| bialix | 1 interface headers to communicate with another program | 12:01 |
| bialix | if your branches is more or less separate, then you don't have much troubles | 12:02 |
| sender | ok, ive got one repo, pulled 2 branches in | 12:03 |
| sender | now what? :) | 12:03 |
| sender | bzr pcmd st gives, error: not a branch | 12:03 |
| bialix | to start with scmproj: first you need to initialize configuration | 12:03 |
| bialix | bzr pinit PATH | 12:04 |
| bialix | it will create .scmproj directory with branch inside it | 12:04 |
| bialix | there is project.cfg | 12:04 |
| bialix | you need to describe your components in project.cfg | 12:04 |
| bialix | at least you should specify RELPATH for each component | 12:04 |
| sender | ok, that's the source? | 12:05 |
| bialix | source? | 12:05 |
| bialix | what do you mean? | 12:06 |
| sender | where you are branching from | 12:06 |
| bialix | BRANCH_URL is source | 12:06 |
| sender | ok, what is RELPATH? | 12:06 |
| bialix | local relative path of each branch root | 12:06 |
| bialix | relative to directory where .scmproj resides | 12:06 |
| sender | ofcourse, thnx :) | 12:07 |
| sender | So RELPATH is mandatory, I guess BRANCH_URL can come from bzr info? | 12:08 |
| bialix | sender: http://pastebin.com/d42cfdd5f | 12:08 |
| bialix | RELPATH is mandatory for all local operations | 12:08 |
| bialix | BRANCH_URL is mandatory to clone existing project, update it or push it back | 12:09 |
| sender | ok, got it right now | 12:09 |
| bialix | you can have one branch right in the root of your project with RELPATH = . | 12:09 |
| bialix | I find this handy | 12:10 |
| sender | that's great | 12:10 |
| sender | this has so much potential | 12:10 |
| bialix | it's easy as lego | 12:10 |
| sender | meccano, lego ;) | 12:10 |
| bialix | and somewhat limited as I said | 12:10 |
| bialix | right | 12:10 |
| bialix | you saw logo? | 12:11 |
| sender | logo writer? | 12:11 |
| sender | bzr pcmb st now gives me # Done. | 12:11 |
| bialix | no, picture of scmproj: https://launchpad.net/bzr-scmproj | 12:11 |
| sender | let's try pull | 12:11 |
| sender | ghehe :) | 12:11 |
| bialix | bzr pcmb st now gives me # Done. <-- so there is no components defined | 12:12 |
| sender | oh :/ | 12:12 |
| bialix | edit project.cfg | 12:13 |
| bialix | this is first thing you need to do to setup project as a whole | 12:13 |
| sender | http://pastebin.com/d6221495 | 12:13 |
| bialix | it should be http://pastebin.com/d32e2e632 | 12:14 |
| bialix | component is mandatory keyword | 12:14 |
| sender | ok | 12:14 |
| flo_hns | hello all. I'd like to setup a hook on my bzr server to forbid pushes by commiter with a badly set email address. What hook should i use ? the doc is very scarce... | 12:15 |
| sender | easy fix... bzr pcmd st now shows me clear output about my branches | 12:15 |
| bialix | sender: good | 12:16 |
| sender | bialix, missing works fine, now pull | 12:16 |
| lifeless | moin | 12:16 |
| sender | works great, awesome! | 12:17 |
| bialix | flo_hns: pre_change_branch_tip I suppose | 12:17 |
| bialix | hi lifeless | 12:17 |
| bialix | sender: cool | 12:18 |
| * bialix goes for lunch | 12:18 | |
| flo_hns | bialix: ok thanks, I'll try it. and how can I cancel a push ? possibly with an error message ? shoud I return false, or call something ... ? | 12:18 |
| lifeless | arjenAU: ? | 12:18 |
| sender | bialix: thanx a lot! | 12:18 |
| lifeless | mneptok: Montreal | 12:19 |
| bialix | flo_hns: ask lifeless, he is guru | 12:20 |
| arjenAU | lifeless: for a non-python person, installing a plugin is a non-trivial process. I do it once in many months and thus I have absolutely no idea what to do. and then there's no docs on what I get. plus it didn't actually install afaics (jaunty from lp dl of hg-bzr). | 12:21 |
| flo_hns | lifeless: hello. I'd like to add a hook to my server, to forbid pushes by commiters who have a badly set email. which hook should I override, and how can I cancel a push from there ? | 12:22 |
| arjenAU | lifeless: the README does not tell me anything. | 12:22 |
| arjenAU | lifeless: but you're a nice guy and you do great work. but please bridge the gap to lesser gods ;-) | 12:22 |
| bialix | sender: bzr pci will commit entire project + .scmproj config | 12:24 |
| lifeless | arjenAU: hmm I try to write docs about it in plugins :) - which plugin was this that didn't ell you anything? | 12:25 |
| lifeless | flo_hns: bzr help hooks | grep pre_tip_change | 12:25 |
| lifeless | flo_hns: there are docs there | 12:26 |
| arjenAU | lifeless: hg-bzr. just the README of the tarball saying what to do to get it installed would be fab. I think it's about 2 lines. except it didn't work on my jaunty. the install phase did not install anything in the bzrlib/plugins dir. | 12:27 |
| flo_hns | lifeless: indeed :) thanks! | 12:27 |
| arjenAU | lifeless: I did sudo python setup.py install or whatever the py was | 12:27 |
| lifeless | arjenAU: ah; well please file ugs, thoug jelmer is really the dude for bzr-hg these days; I last touched it years ago | 12:27 |
| lifeless | s/ugs/bugs | 12:27 |
| arjenAU | lifeless: hum. the amount of effort involved in filing a bug for this kind of basic stuff.... yes I know i'm spending time on the whinge also | 12:28 |
| lifeless | arjenAU: use the email interface :) | 12:29 |
| lifeless | subject: <> | 12:29 |
| lifeless | to: new@bugs.launchpad.net | 12:29 |
| lifeless | affects bzr-email | 12:29 |
| lifeless | done | 12:29 |
| arjenAU | lifeless: that's intersting. so how does it know which project | 12:29 |
| lifeless | blah blah blah | 12:29 |
| arjenAU | lifeless: ah. that makes it more handy | 12:30 |
| === mrevell is now known as mrevell-lunch | ||
| zombor | hi, im trying to install 2.0 on xubuntu 8.10, but when i add the repo and apt-get update, it says "Ign https://launchpad.net intrepid Release" | 13:40 |
| zombor | any idea why? | 13:40 |
| zombor | if i use synaptic, i get "GPG error: https://launchpad.net intrepid Release: The following signatures were invalid: NODATA 2Failed to fetch https://launchpad.net/~bzr/+archive/dists/intrepid/main/i18n/Translation-en_US.bz2" | 13:44 |
| === mrevell-lunch is now known as mrevell | ||
| Mez | bzr: ERROR: KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/.bzr/repository/') | 14:11 |
| Mez | is not compatible with | 14:11 |
| Mez | KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/trunk/.bzr/repository/') | 14:11 |
| Mez | different rich-root support | 14:11 |
| Mez | Can someone explain? | 14:11 |
| Mez | (this is me trying to branch something. | 14:11 |
| beuno | Mez, sure | 14:12 |
| beuno | you'the branch you're trying to get is a newer format | 14:12 |
| beuno | and you have a local shared repository with an older format | 14:13 |
| Mez | coool. bzr upgrade on the repo seems to have worked. | 14:14 |
| beuno | :) | 14:14 |
| Mez | or not ... | 14:15 |
| * Mez upgrades trunk too | 14:15 | |
| Mez | [##############- ] Copying content into repository.:Transferring revisions 0/668 | 14:15 |
| Mez | stuck :( | 14:15 |
| beuno | Mez, what does .bzr.log say about it? | 14:16 |
| Mez | 83.758 Resizing the inventory entry cache from 23074 to 50752 | 14:16 |
| Mez | grrr | 14:17 |
| Mez | 11.620 creating repository in file:///home/mez/development/bzr/io/mobilefun/projects/trunk/.bzr/. | 14:17 |
| Mez | 16.626 Resizing the inventory entry cache from 10240 to 23074 | 14:17 |
| lifeless | Mez: be patient | 14:17 |
| Mez | 83.758 Resizing the inventory entry cache from 23074 to 50752 | 14:17 |
| beuno | lifeless, hi! | 14:17 |
| lifeless | Mez: it will ive an update only at 100 rev s | 14:17 |
| beuno | lifeless, do you know if we already have a bug about bzr not inviting you to upgrade when it you try to interact with 2a? | 14:18 |
| lifeless | beuno: do you mean 'bzr should invite' ? | 14:18 |
| * beuno has +filebug open, and is not afraid to use it | 14:18 | |
| beuno | lifeless, well, something better than: | 14:18 |
| beuno | 08:11 < Mez> bzr: ERROR: KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/.bzr/repository/') | 14:19 |
| beuno | 08:11 < Mez> is not compatible with | 14:19 |
| beuno | 08:11 < Mez> KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/trunk/.bzr/repository/') | 14:19 |
| beuno | 08:11 < Mez> different rich-root support | 14:19 |
| lifeless | beuno: I don't think we do | 14:19 |
| * beuno files it | 14:19 | |
| Tak | is there any situation when upgrading would be bad? | 14:20 |
| Tak | (at the point when that error is encountered) | 14:20 |
| beuno | Tak, well, maybe you end up upgrading trunk, and other users with older versions of bzr can't access it anymore | 14:21 |
| beuno | but, well, this becomes a chicken and egg problem at some point | 14:21 |
| Tak | right - if you can't pull from your other branch, *something* has to happen | 14:21 |
| Tak | I'm wondering if bzr should just go ahead and do the upgrade | 14:22 |
| beuno | lifeless, maybe bug 53271 represents it? | 14:22 |
| ubottu | Launchpad bug 53271 in bzr "Should suggest 'bzr upgrade' when giving error about unsupported format" [Medium,Confirmed] https://launchpad.net/bugs/53271 | 14:22 |
| Mez | lifeless: It just feels like it's taking WAYYYYY too long. | 14:26 |
| beuno | Mez, how big is the branch? | 14:28 |
| lifeless | beuno: no, I don't think it does | 14:28 |
| lifeless | Mez: strace it; don't interrupt :) | 14:28 |
| Mez | 931M ... :( | 14:29 |
| beuno | Mez, relax, it will take a while | 14:30 |
| Mez | hasn't taken this long to branch before though.... | 14:30 |
| Mez | and strace isn't giving ANY output | 14:31 |
| Mez | tell a lie, now it does. | 14:31 |
| beuno | Mez, the new format needs to do a few extra things | 14:32 |
| beuno | it's *much* faster and smaller, but it needs to do a lot of heavy lifting to convert | 14:32 |
| Mez | beuno: so it's going to take this long every time I branch ? | 14:32 |
| beuno | Mez, no, the upgrade is a one-off thing | 14:33 |
| beuno | Mez, what version of bzr are you using? | 14:33 |
| Mez | beuno: 2.0.0. | 14:33 |
| spiv | It's more that it has to extract and decompress all the data from the old format, and the old format is a bit slow. Normally when you branch bzr can just copy rather than extracting then recompressing, but obviously it can't do a straight copy when converting formats. | 14:34 |
| beuno | Mez, great, so you just need to bite the bullet this time, then it should be much faster than before | 14:34 |
| Mez | beuno: though if I don't upgrade trunk it'll do this every time? I cna't upgrade te trunk branch until everyone's moved to new bzr. | 14:35 |
| beuno | Mez, no, if you have you're local repository upgraded, you can interact with older formats | 14:35 |
| liel_ | Hello | 14:36 |
| lifeless | Mez: once you upgrade, everyone else has to | 14:38 |
| lifeless | Mez: its in the docs;) | 14:38 |
| liel_ | I tried to upload my code to a branch in Launchpad, but bzr returned an error: "bzr: ERROR: These branches have diverged. ". What does it mean? | 14:40 |
| Mez | lifeless: so I'm about to fuck over the other devs? | 14:40 |
| Mez | because I'm using karmic and they're not ? | 14:40 |
| lifeless | Mez: if they don't have 1.16, yes. | 14:40 |
| beuno | Mez, you're just upgrading locally though, no? | 14:41 |
| lifeless | Mez: 2a requires rich-root repositories to push into, it can downgrade seamlessly with any -rich-root format. | 14:41 |
| * Mez shrugs | 14:41 | |
| lifeless | Mez: if they don't have -rich-root then you're doing a one-way transition | 14:41 |
| Mez | they seem to have 2.0.0 themselves :D | 14:41 |
| beuno | liel_, that you need to bring in changes made remotely with "bzr merge REMOTE_BRACH" | 14:41 |
| james_w | Mez: you don't have to upgrade to the 2.0.0 format | 14:41 |
| lifeless | beuno: a local upgrade past the -rich-root transition means 'cannot push to the network without upgradingg it too' | 14:41 |
| lifeless | beuno: you will want to memorise that :) | 14:42 |
| beuno | lifeless, I thought the case was the other way around | 14:42 |
| liel_ | james_w: I recived: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified" | 14:42 |
| beuno | local in 0.92, remote in 2a | 14:42 |
| lifeless | beuno: local 0.92, remote 2a, you can push, can't pull. | 14:43 |
| liel_ | What this message mean? my English is weak so it is hard for me to understand this message | 14:44 |
| muffinresearch | in loggerhead I'm finding that shared branches don | 14:45 |
| muffinresearch | I'll try again - in loggerhead branches from a shared repo can't be checked out | 14:46 |
| muffinresearch | is that a known limitation? | 14:46 |
| beuno | muffinresearch, you're using loggerhead to serve branches? | 14:46 |
| muffinresearch | in as far as it is displaying a message with the command for checking out branches over http | 14:48 |
| beuno | muffinresearch, it is not a known bug, but I have my suspicions of why that is... | 14:48 |
| muffinresearch | beuno - it works for me with standalone branches but not for ones that are in a shared repo | 14:48 |
| beuno | muffinresearch, could you file a bug for it? | 14:49 |
| muffinresearch | sure will do | 14:49 |
| beuno | thanks | 14:49 |
| spiffyte1h | The bzr-svn how-tos tell me to start with "bzr init-repo --default-rich-root reponame", but bzr 1.5 on Debian is giving me "ERROR: no such option: --default-rich-root" | 14:59 |
| jelmer | spiffyte1h: 1.5 is pretty old; I suspect it would support --rich-root-pack | 15:03 |
| jelmer | spiffyte1h: but I would also recommend installing a newer version of bzr and bzr-svn | 15:03 |
| spiffyte1h | Ah, but that would be too easy! It's much more fun working within the ancient confines of Debian Stable on your company's dev server :) | 15:04 |
| muffinresearch | beuno https://bugs.edge.launchpad.net/loggerhead/+bug/447229 | 15:06 |
| ubottu | Launchpad bug 447229 in loggerhead "Checking out branches from a shared repo results in 'No repository present' error" [Undecided,New] | 15:07 |
| spiffyte1h | jelmer: --rich-root-pack worked fine, thanks! | 15:08 |
| beuno | muffinresearch, thanks | 15:08 |
| tsmith | i <3 bzr | 15:28 |
| tsmith | it's the greatest thing since cvs | 15:28 |
| faldridge | jelmer: could you explain the difference between just doing a bzr branch, doing bzr checkout on an svn repo, and using bzr svn-import on an svn repo? | 15:34 |
| faldridge | s/bzr branch/bzr branch on an svn repo/ | 15:34 |
| jelmer | faldridge: 'bzr branch' clones a single branch in the repository | 15:37 |
| jelmer | faldridge: 'svn-import' imports multiple branches in the repository | 15:37 |
| jelmer | faldridge: 'bzr checkout' clones a single branch and binds to it | 15:37 |
| jelmer | faldridge: (if you commit to a bound branch, your local changes automatically end up in that branch too) | 15:38 |
| faldridge | ah, so for the initial pull, bzr branch and bzr checkout would produce nearly the same results? | 15:38 |
| jelmer | faldridge: yes | 15:38 |
| Peng_ | The end result of "bzr svn-import" is no different than manually running "bzr branch" once for each branch. Right? | 15:39 |
| faldridge | jelmer: what I'm seeing and I'm guessing it's unavoidable is that doing a bzr checkout on a history-rich svn repo takes forever in some cases and fails altogether in one other case. | 15:39 |
| faldridge | and from your answer that svn-import would just take even longer | 15:39 |
| jelmer | Peng_: yes (preceded by the initialisation of a shared repo) | 15:39 |
| faldridge | s/answer/answer it seems/ | 15:39 |
| jelmer | faldridge: yes, copying history in svn is slow | 15:39 |
| jelmer | faldridge: In the case where it fails altogether, how does it fail? | 15:40 |
| Peng_ | jelmer: Err, right. Oops. | 15:40 |
| faldridge | two different errors messages in two tries. Let me try again now and I'll let you know (it might be a little while) | 15:40 |
| phinze | hmm api confusion here... i have an instance of a branch i just sprouted, and i'd like to push to the default location | 15:40 |
| phinze | new_branch.push(new_branch.get_push_location()) | 15:40 |
| phinze | i'm missing a step there | 15:40 |
| jelmer | phinze: you need to push to a Branch instance (push location is a string) | 15:41 |
| jelmer | phinze: perhaps something like: | 15:41 |
| jelmer | new_branch.push(Branch.open(new_branch.get_push_location())) ? | 15:41 |
| phinze | there it is, thanks jelmer :) | 15:41 |
| faldridge | jelmer: would not having commit access hinder my ability to do a binding pull on an svn repo? | 15:42 |
| phinze | hmm, not quite: "NotBranchError: Not a Branch: (url of remote push location)" | 15:42 |
| phinze | this is a new push branch location | 15:42 |
| jelmer | faldridge: if you're pulling into a branch that's bound to a svn repo that you don't have access to, that would be a problem (since you can't upload new revisions) | 15:42 |
| jelmer | phinze: ah | 15:43 |
| jelmer | phinze: In that case you might need branch.bzrdir.sprout() IIRC | 15:43 |
| faldridge | jelmer: ok, I'm trying the bzr branch method. | 15:43 |
| phinze | jelmer: ok will try that | 15:43 |
| jelmer | phinze: assuming the target exists as a directory: | 15:44 |
| phinze | push_location is "bzr+ssh://..." style | 15:45 |
| jelmer | phinze: t = get_transport(new_branch.get_push_location()); new_branch.bzrdir.create_clone_on_transport(t) | 15:45 |
| phinze | heyo, that worked... new_branch.create_clone_on_transport(get_transport(new_branch.get_push_location()) | 15:52 |
| phinze | such a big API, i get lost easily, thanks jelmer :D | 15:52 |
| faldridge | jelmer: using bzr branch to produce an unbound mirror worked. The curious thing to me, though, is that I don't have commit access on the repos in which I was able to produce a bound mirror | 15:56 |
| jelmer | faldridge: If you would commit in a bound branch bzr would attempt to put your commits in the original svn repository as well | 15:58 |
| jelmer | faldridge: and that would fail, since you don't have commit access | 15:58 |
| faldridge | jelmer: what if I made a local branch of the bound branch and committed on it? Would that fail as well? | 15:59 |
| jelmer | faldridge: no, that would succeed - since it wouldn't try to push the data to the svn branch | 16:02 |
| jelmer | faldridge: alternatively, you can also unbind the bound branch | 16:02 |
| jelmer | faldridge: "bzr unbind" | 16:03 |
| faldridge | great, thanks! | 16:03 |
| faldridge | thanks so much for your help. I really, really hate svn's branching/merging syntax so you've been a lifesaver! | 16:03 |
| NEBAP|work | can somebody tell me which project management tool has bazaar support? I've found some few month ago, but now I couldn't find any of them .. | 16:30 |
| Tak | project management tool? | 16:31 |
| NEBAP|work | hmm, don't know how I should describe it in another way. Are there any webapps out there that support bazaar? (I remember a name like track, but seems to be wrong) | 16:32 |
| visik7 | loggerhead | 16:33 |
| NEBAP|work | ah ok | 16:34 |
| NEBAP|work | is that the only one? | 16:34 |
| jrwren | launchpad? | 16:35 |
| jrwren | launchpad is open source now... run LP. | 16:35 |
| NEBAP|work | ?? | 16:36 |
| NEBAP|work | so you can install launchpad on your own server? | 16:36 |
| Tak | oh yeah, trac has a bzr plugin as well, right? | 16:37 |
| NEBAP|work | ah that's the one I found ^^ | 16:38 |
| NEBAP|work | Tak: thank you | 16:38 |
| NEBAP|work | project management ^^ | 16:38 |
| Tak | launchpad is probably better integrated with bzr | 16:38 |
| Peng_ | Redmine supports bzr. | 16:39 |
| phinze | is there a way to list the diff being stored on a shelf? bzr unshelve --dry-run just shows me the modified files like `bzr st` which isn't very useful | 16:39 |
| Tak | hey - the pydoctor doc link has disappeared from http://bazaar-vcs.org/Documentation | 16:39 |
| phinze | aha appears there is a bug regarding this: https://bugs.launchpad.net/bzr/+bug/317896 | 16:41 |
| ubottu | Launchpad bug 317896 in bzr "bzr unshelve --dry-run should produce a diff" [Undecided,Confirmed] | 16:41 |
| NEBAP|work | Tak: but launchpad seems to be a bit overloaded for my needs ^^ | 16:41 |
| Tak | ok | 16:42 |
| NEBAP|work | any experiences with redmine? | 16:43 |
| NEBAP|work | or is it possible to use only a few features from launchpad? | 16:43 |
| NEBAP|work | e. g. source browser and issue tracking | 16:44 |
| phinze | NEBAP|work: use redmine+bzr heavily where i work | 16:44 |
| NEBAP|work | phinze: so? Can you recommend it? | 16:45 |
| phinze | seems to work out ok, the source browser sort of sucks -- we use loggerhead separately for that | 16:45 |
| NEBAP|work | ok ^^ | 16:46 |
| phinze | the only limitation that gets me is the fact that you have to link one branch to one project to integrate commit messages with issue updates | 16:46 |
| NEBAP|work | then it seems to better make a small bug tracker and use loggerhead as the source browser is the most important feature for me .. | 16:46 |
| phinze | so when i commit to the project foo branch and have a message like "hey i'm done, closes #1234"... it has to be an issue that exists in project foo | 16:47 |
| phinze | so depending on how many projects you're dealing with you may run into that | 16:47 |
| NEBAP|work | k | 16:47 |
| NEBAP|work | thank you :) | 16:47 |
| phinze | np | 16:47 |
| phinze | if you end up trying it and have questions, feel free to ping me | 16:48 |
| NEBAP|work | thank you :D | 16:49 |
| NEBAP|work | does launchpad use loggerhead? | 16:51 |
| Peng_ | Yes. | 16:52 |
| NEBAP|work | k | 16:53 |
| NEBAP|work | phinze: does the redmine source browser support syntax highlighting? Sadly the online demo isn't available .. | 16:53 |
| Peng_ | Loggerhead supports syntax highlighting. :D | 16:54 |
| lifeless | does loggerheads rpc support mean we can use bzr+http with http://b.l.n | 16:54 |
| Peng_ | (That is, Loggerhead has 30 lines of code to run stuff through Pygments if it's available.) | 16:54 |
| NEBAP|work | k | 16:55 |
| phinze | NEBAP|work: i believe redmine source browser can run stuff through coderay... but like i say, it's not the best thing in the world, which is why we use a separate instance of loggerhead | 16:55 |
| NEBAP|work | couldn't find any screenshots of loggerhead, but I'll check loggerhead at first | 16:55 |
| Peng_ | NEBAP|work: You can play around with Launchpad's instance: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/ | 16:56 |
| NEBAP|work | phinze: ok thanky you :D | 16:56 |
| Peng_ | lifeless: b.l.n doesn't support it. | 16:57 |
| NEBAP|work | k, will check that at first :D | 16:57 |
| NEBAP|work | does it need additional apps, or will it run in any python environment? | 16:57 |
| Peng_ | NEBAP|work: It requires some Python libraries. | 16:58 |
| * Peng_ points at the README | 16:58 | |
| NEBAP|work | k thanks, hopefully I can get it running on my webspace .. | 16:58 |
| lifeless | Peng_: thanks | 16:59 |
| Peng_ | lifeless: Loggerhead itself supports it, though. Seems to be broken in trunk, hmm. | 17:00 |
| NET||abuse | hey guys... made a mistake, was trying to ignore a set of log files, but not the containing directory,, but ended up removing the directory, then re-adding it,, then committing and pushing up to another laptop... now on that other laptop,, i have a lot of var.moved logs.moved and cache.moved files.. want to get rid of them ... easy way? | 17:01 |
| Peng_ | b.l.n handles .bzr through Apache. I guess nobody thought of pointing .bzr/smart over to Loggerhead. | 17:03 |
| lifeless | Peng_: I'm not sure we should willy nilly ;) | 17:03 |
| lifeless | Peng_: but I'd love it if you were to file a bug saying we should consider it | 17:04 |
| Peng_ | lifeless: I'm busy right this second, but sure. | 17:07 |
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| Peng_ | (FYI, it was only broken when using "bzr serve --http", and I just fixed it.) | 17:30 |
| Peng_ | lifeless: I'll add a comment to bug #165087. | 17:36 |
| ubottu | Launchpad bug 165087 in launchpad-code "Cannot branch from bzr+http URLs" [Low,Triaged] https://launchpad.net/bugs/165087 | 17:36 |
| lifeless | thanks! | 17:44 |
| jfroy|work | jelmer: updated 342065 with a new backtrace | 18:08 |
| === sidnei_ is now known as sidnei | ||
| === deryck[lunch] is now known as deryck | ||
| niemeyer | Greetings! | 18:34 |
| niemeyer | Congrats on 2.0! | 18:34 |
| niemeyer | Was just looking at the upgrade procedures, and was wondering about something regarding migration of Launchpad branches | 18:35 |
| niemeyer | Is it the case that ~team/project/trunk cannot be used anymore? | 18:36 |
| niemeyer | Assuming that this was the place the old branch was held | 18:36 |
| james_w | I believe so, but someone else will be able to confirm | 18:42 |
| jam | niemeyer: so you *can* upgrade in place, but it often causes more headaches than downloading, upgrading locally, unsetting the dev focus, pushing a new trunk, and setting the new branch as the dev focus | 18:43 |
| james_w | doesn't upgrading in place break branches that are stacked on the focus? | 18:46 |
| jam | james_w: IIRC it means they must be upgrade, but lifeless claims you can upgrade them once the dev focus has been upgraded | 18:53 |
| james_w | ah, ok | 18:53 |
| bialix | vila: ping | 18:58 |
| jam | bialix: vila generally has stopped working about 2hrs ago | 18:59 |
| bialix | hello jam | 18:59 |
| bialix | ok | 18:59 |
| mneptok | lifeless: any plans for US travel? | 19:07 |
| niemeyer | jam: I see, thanks | 19:09 |
| niemeyer | lifeless: So is that the case? Can they be upgraded in place after the stacking base has been upgraded? | 19:09 |
| jam | mneptok: well, he was in Canada this week... but I believe he explicitly avoids the US. Doesn't like being fingerprinted, etc. | 19:11 |
| === beuno-lunch is now known as beuno | ||
| Tak | heh | 19:12 |
| lifeless | niemeyer: yes you can upgrade after | 19:17 |
| lifeless | mneptok: no, back homeward bound in 2 ours | 19:17 |
| lifeless | *hours* | 19:17 |
| lifeless | mneptok: where are you at the moment ? | 19:17 |
| niemeyer | lifeless: That's awesome! | 19:20 |
| jfroy|work | yay | 19:22 |
| jfroy|work | fast-export | fast-import will work to create a new branch out of a borked branch | 19:23 |
| jfroy|work | (bortked -> ghosts and sha1 mismatches) | 19:23 |
| Peng_ | Oh, cool. | 19:24 |
| SamB_XP | jfroy: of course, it will have no relation to the previous branch ... | 19:24 |
| jfroy|work | SamB_XP: which is fine | 19:25 |
| jfroy|work | (in this case0 | 19:25 |
| jfroy|work | *) | 19:25 |
| SamB_XP | just pointing out the obvious in case it had escaped anyone's thinking somehow | 19:26 |
| SamB_XP | 'twould be a harsh truth to realize a day or so later ;-) | 19:29 |
| jfroy|work | yeah | 19:29 |
| jfroy|work | My goal at this point is only to un-borked the main development branch of the project, ditch every other branch and go from there. | 19:30 |
| SamB_XP | hmm ... it would be kind of cool if fast-export could do several branches at once ... | 19:31 |
| SamB_XP | ... or can it ? | 19:31 |
| mneptok | lifeless: Albuquerque, New Mexico | 19:56 |
| emmajane | lifeless, he's as far away from snow as possible. | 20:06 |
| === mnepton is now known as mneptok | ||
| === tro|| is now known as tro | ||
| === JaredWigmore is now known as JaredW | ||
| Tak | actually, albuquerque is up in the mountains, isn't it? | 20:46 |
| mathepic | I asked this yesterday but nobody had a solution | 20:52 |
| mathepic | I'm trying to use colordiff as a bzr diff backend | 20:52 |
| mathepic | But I'm on windows with cygwin | 20:52 |
| mathepic | so it doesn't seem to recognize it (colordiff is not an executable) | 20:52 |
| lifeless | you'll need to either use bzr from cygwin | 20:55 |
| lifeless | or have a batch /command script that runs colordiff | 20:55 |
| mathepic | Running it from cygwin doesn't solve the problem | 20:56 |
| mathepic | $ bzr diff --using colordiff === modified file 'Makefile' bzr: ERROR: colordiff could not be found on this machine | 20:57 |
| mathepic | Can't post multiple lines very well | 20:58 |
| mathepic | I opened up colordiff with emacs | 20:58 |
| mathepic | it is a perl script | 20:58 |
| lifeless | mathepic: running from cygwin won't help: | 20:58 |
| lifeless | you need a *cygwin version* of bzr | 20:59 |
| mathepic | Oh | 20:59 |
| lifeless | normal bzr uses win32 python that uses CreateProcess | 20:59 |
| mathepic | Will that have any significant drawbacks on performance? | 20:59 |
| lifeless | *cygwin* bzr uses cygwin python which uses fork/exec | 20:59 |
| mneptok | Tak: it is. ABQ is at ~5.5feet elevation | 20:59 |
| lifeless | mathepic: I'm not sure of the performance implications; jam, who has signed off, may know. | 20:59 |
| Tak | *10^3? | 21:00 |
| lifeless | mathepic: but you can create a .cmd script to run colordiff | 21:00 |
| mathepic | I hate windows so much... | 21:01 |
| * Tak at literally 5.5ft | 21:01 | |
| mathepic | What would the batch script contain | 21:02 |
| mathepic | Since I can't access colordiff unless I'm in cygwin | 21:03 |
| mathepic | I guess I can just run "bzr diff | colordiff", but I was hoping to get an alias that would achieve the same thing | 21:04 |
| idnar | what about bzr cdiff? | 21:06 |
| mathepic | bzr diff --using "perl /bin/colordiff" doesn't work with colors | 21:06 |
| mathepic | nor does bzr cdiff | 21:06 |
| idnar | ah | 21:06 |
| mathepic | I'm thinking cdiff isn't compatible with windows | 21:06 |
| mathepic | Is there any alternative to "colordiff" for colorize diff | 21:10 |
| mathepic | under cygwin | 21:10 |
| lifeless | mathepic: I repeat, you'll need a command script | 21:25 |
| lifeless | crate one and it should be fine | 21:25 |
| lifeless | as to what it contains, 'perl.exe colordiff $1 $2' or something like that | 21:25 |
| lifeless | I have to go, got a plane to catch. | 21:26 |
| malept | hi, I'm attempting to use smart server support in loggerhead with a repository. `bzr info` on the repository is fine, but on the branch it gives me "No repository present: chroot://[something]". I'm kind of at a loss as to how to debug this. | 21:26 |
| zsquareplusc | or "bash -c colordiff" | 21:26 |
| lifeless | malept: its a bug, it was discussed earlier today with someone else; I don't remember more sorry | 21:29 |
| malept | lifeless: discussed in here? | 21:29 |
| lifeless | yes | 21:30 |
| lifeless | ciao | 21:30 |
| malept | lifeless: have a good flight | 21:30 |
| mathepic | zsquareplusc, that almost worked but colordiff starts wanting me to input text | 21:30 |
| zsquareplusc | mathepic: yes, and does piping not work? "|"? | 21:31 |
| mathepic | Yeah the piping will work, I'm just trying to get an alias | 21:31 |
| Peng_ | malept: I don't know what's going on there. I'd expect you to hit bug #348308, but this is something different. | 21:32 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 | 21:32 |
| * zsquareplusc has not yet used aliases | 21:32 | |
| Peng_ | malept: Do you mind filing a bug? https://bugs.edge.launchpad.net/loggerhead | 21:34 |
| Peng_ | malept: Oh, you/someone did. https://bugs.edge.launchpad.net/loggerhead/+bug/447229 | 21:34 |
| ubottu | Launchpad bug 447229 in loggerhead "Checking out branches from a shared repo results in 'No repository present' error" [Low,Triaged] | 21:34 |
| malept | Peng_: yeah, just found it in the irc logs from today | 21:35 |
| Peng_ | Ah. I didn't see the discussion; when was it? | 21:36 |
| Peng_ | Never mind, grepped. | 21:36 |
| davidstrauss | What unit testing framework does bzr use? | 21:36 |
| malept | :) | 21:36 |
| davidstrauss | lifeless: ^^ you would know :-) | 21:37 |
| malept | Peng_: I had already patched my fastcgi loggerhead script to deal with the smart server jail bug (using your monkeypatch) | 21:37 |
| Peng_ | malept: Ah. | 21:38 |
| Peng_ | davidstrauss: Bazaar uses Python's unittest, plus (optionally) subunit and/or testtools. | 21:39 |
| malept | Peng_: speaking of my fastcgi script, would it be useful if it was distributed with loggerhead? | 21:39 |
| davidstrauss | Peng_: Is that built into Python? | 21:39 |
| malept | davidstrauss: unittest is, for sure | 21:40 |
| davidstrauss | ok, cool | 21:40 |
| * davidstrauss is about to force unit testing on bcfg2. | 21:40 | |
| Peng_ | subunit & testtools are not. | 21:40 |
| Peng_ | malept: Waitwait. A FastCGI script? Neat! Can I see it? :D | 21:41 |
| LarstiQ | davidstrauss: and convenience classes/methods built on top of unittest | 21:41 |
| malept | Peng_: sure, mind if I PM you the link? | 21:41 |
| Peng_ | malept: ok | 21:43 |
| maxb | Hi. Would someone be able to guide me to an example of using bzrlib to get a list of all rev-ids in a branch? | 21:59 |
| maxb | Or alternatively, what is the best way whether to check whether rev-id is contained within the history of a branch | 22:03 |
| maxb | I don't suppose anyone here is familiar with where in the qbzr code the algorithm for ordering revisions in qlog lives? | 22:12 |
| SamB_XP | maxb: there was a bug about how to check whether a revision is in the history of a given branch ... | 22:14 |
| SamB_XP | ... it has the word "predicate" in the title, I believe | 22:14 |
| luks | maxb: regarding the list of all revision-ids: branch.repository.get_ancestry(branch.last_revision()) | 22:16 |
| maxb | Ah - I found branch.get_revision_id_to_revno_map() and was attempting that | 22:17 |
| maxb | It seems rather sloooow though | 22:18 |
| SamB_XP | it would be, yes | 22:18 |
| luks | and the revisions in qlog are topologically sorted | 22:19 |
| luks | which is in bzrlib.tsort | 22:19 |
| luks | (unless you mean the actual graph layout, not just the ordering) | 22:19 |
| SamB_XP | luks: perhaps he was hoping to stick something in to order by commit date when possible ;-) | 22:20 |
| maxb | SamB_XP: exactly :-/ | 22:27 |
| SamB_XP | I guessed this because I have often wished that bzr viz had such an option | 22:28 |
| maxb | toposort with a preference for commit date where feasible would make the history much more readable in many cases | 22:28 |
| maxb | So, on the "is it in the history" question, basically I've discovered bzr fastimport has a bug where it discards tags which aren't on the left-hand history | 22:29 |
| luks | well, sorting by date would require making the graph flat | 22:29 |
| maxb | So I'm trying to rewrite its "is this tag in this branch" logic to respect all the history, not just the left-hand | 22:29 |
| maxb | luks: "flat" ? | 22:29 |
| luks | a simple list | 22:30 |
| maxb | I don't require that it be completely date-ordered. | 22:30 |
| luks | otherwise you would need arrows on the lines, because they could be directed both up and down | 22:30 |
| luks | how would it work? | 22:30 |
| maxb | I just want it to be date-ordered where topological constraints do not dictate otherwise | 22:31 |
| luks | the only point where you possibly chance choose the ordering is a merge point (node with multiple parents) | 22:32 |
| luks | er, have a chance | 22:32 |
| luks | to | 22:32 |
| luks | but of course that would break the mainline concept | 22:33 |
| maxb | ? | 22:35 |
| maxb | It's perhaps worth noting that this comes into its own and is only really relevant when viewing the graph of a repository - i.e. many heads to the graph | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
