| mathrick | lifeless: nothing wrong with pigs! They're really smart | 00:00 |
|---|---|---|
| lifeless | RickCogley: to run locally ? | 00:00 |
| lifeless | mathrick: sure; I just didn't mean to say that to poolie, complement or not. | 00:00 |
| RickCogley | yes, I have some shell and perl scripts which I'm thinking of making available, and I would like to let people download them and use them. But as painlessly as possible on my side. I.e. the latest version is "just there" for people to get. | 00:02 |
| poolie | hello | 00:02 |
| * bialix waves | 00:02 | |
| poolie | hello bialix | 00:03 |
| poolie | did you actually mean to ping at all? | 00:03 |
| bialix | you? me? not. lifeless is | 00:03 |
| === tomtom is now known as Guest69613 | ||
| poolie | sorry that line was directed to lifeless | 00:04 |
| poolie | just saying hello to you | 00:04 |
| lifeless | poolie: hi | 00:04 |
| lifeless | I was confused by your comment not to use fix committed | 00:04 |
| lifeless | I've just reread the guidelines and see now that we've changed our process | 00:04 |
| poolie | yup | 00:04 |
| poolie | i don't think the distinction is reliable | 00:05 |
| poolie | cause things may bounce from review etc | 00:05 |
| poolie | also launchpad may get rid of the distinction | 00:05 |
| poolie | there is a thread about it | 00:05 |
| lifeless | are we able to search for 'in progress with commit in a branch' though ? | 00:06 |
| lifeless | I know mpt's opinion on this | 00:06 |
| lifeless | ah yes, I thought it was recent | 00:08 |
| lifeless | anyhow, its trivia | 00:09 |
| lifeless | I will adjust | 00:09 |
| lifeless | poolie: I would like to note though, that in progress is also unreliable, as people can flit from one thing to another | 00:10 |
| poolie | to me 'in progress' ought to mean 'some work has been invested in this' | 00:12 |
| poolie | therefore all else being equal, there is a higher return in finishing it off | 00:13 |
| poolie | just how valuable the work is, is a bit hard to capture in an enum | 00:13 |
| lifeless | a dial would be nicec | 00:13 |
| lifeless | I think you have it on the spot there | 00:13 |
| lifeless | to me 'fix committed' is 'nearly there' | 00:13 |
| lifeless | whereas 'in progress' would be 'I think I can' | 00:13 |
| lifeless | if that makes sense | 00:14 |
| lifeless | [I'm not arguing to use F-C, just saying I see the issue and feel frustrated that LP is such a coarse model of how thins work] | 00:16 |
| Peng | lifeless: I dunno if it was taken -- it probably was, though. I just don't use it as much anymore. Too many other Pengs around. | 00:27 |
| poolie | lifeless: i desire a similar thing for mps too | 00:28 |
| poolie | ie to sort them into 'needs lots more work' and 'pp should jfdi' | 00:28 |
| * poolie is getting back into bug 456077; it's now working but needs to suppress the warning during upgrade | 00:29 | |
| ubottu | Launchpad bug 456077 in bzr/2.0 "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [High,In progress] https://launchpad.net/bugs/456077 | 00:30 |
| poolie | happily the tests now automatically detect that the message is printed there and shouldn't be | 00:30 |
| poolie | spiv, hi? | 00:42 |
| spiv | Hey. | 00:44 |
| poolie | coffee? :) | 00:45 |
| thumper | poolie: just had one thanks | 00:45 |
| spiv | Always :) | 00:45 |
| poolie | so | 00:45 |
| poolie | we could actually have coffee or catch up, if vincent will let you | 00:46 |
| poolie | also just wanted to see how you were getting on | 00:46 |
| poolie | bialix: i think the import tariff stuff is promising | 00:47 |
| bialix | poolie: about adding gettext to bzr core | 00:47 |
| poolie | we can check if we're actually as lazy as we want to be | 00:47 |
| bialix | gettext is loading mo file from disk and parse it | 00:47 |
| spiv | Hmm. Today or tomorrow? Tomorrow would probably work better for me. | 00:47 |
| bialix | poolie: so we can make it lazy till we need translations actually | 00:48 |
| bialix | poolie: maybe some sort of lazy_registry will help | 00:49 |
| bialix | poolie: I need to think about it | 00:49 |
| lifeless | tomorrow avo I can do | 00:49 |
| lifeless | bialix: for gettext, I think lazy is pointless | 00:49 |
| poolie | bialix: is this to avoid loading the .mo file, or loading gettext itself? | 00:49 |
| lifeless | bialix: either we use it, and we'll need it on every invocation, or we don't use it and don't need it. | 00:49 |
| bialix | lifeless: not so fast! | 00:49 |
| bialix | poolie: to read/parse mo | 00:50 |
| bialix | lifeless: you don;t need gettext when you run status and it prints no results, right? | 00:50 |
| poolie | good point | 00:50 |
| bialix | today bzr has very long startup | 00:50 |
| bialix | comparing to hg, you know | 00:50 |
| lifeless | bialix: we long stuff even in that case. | 00:51 |
| bialix | maybe mo parsing won't be significant | 00:51 |
| poolie | right, we want to pull that down, not add to it | 00:51 |
| lifeless | bialix: and some of what we log is stuff that we'd also output under other circumstances | 00:51 |
| poolie | so we need to draw a line as far as what is translatted | 00:51 |
| poolie | i'm not sure that mutter stuff should be | 00:51 |
| poolie | though that's true there is not a clear distinction between internal and user-facing messages | 00:51 |
| poolie | yte | 00:51 |
| poolie | yet* | 00:51 |
| bialix | no sense to write translated strings to .bzr.log at all | 00:52 |
| lifeless | I agree we want to reduce the startup time; I'm just saying that *if* we start doing translations, we should expect to pay the gettext library load time + mo parsing on 99% of invocations | 00:52 |
| poolie | well | 00:52 |
| bialix | you won't be able to understand bug reports :-P | 00:52 |
| poolie | we should aim to make it fast enough that even if it is loaded, it doesn't kill us | 00:52 |
| poolie | :) | 00:52 |
| lifeless | poolie: agreed. | 00:52 |
| poolie | making the test suite pass under LANG=ru would be nice | 00:53 |
| poolie | i don't think it does now | 00:53 |
| lifeless | my point is simply that lazy only applies usefully when you *can* avoid work | 00:53 |
| poolie | yep | 00:53 |
| poolie | a bit like caching | 00:53 |
| lifeless | oh, and, also like caching, doing lazy is itself work. | 00:53 |
| bialix | lifeless: actually gettext.py has some cache inside | 00:53 |
| bialix | but it search the disk anyway every time | 00:54 |
| bialix | it will be slow on windows | 00:54 |
| bialix | we can just subclass GNUTranslations class and make it lazy to load mo | 00:54 |
| bialix | then we pay penalty only on each string that should be translated | 00:55 |
| lifeless | I think this is a case for benchmarking | 00:56 |
| bialix | poolie: btw, about your recent ui changes, we may want to make the note/info metods to write translated strings only to termina; | 00:56 |
| bialix | and english to .bzr.log | 00:56 |
| poolie | interesting | 00:56 |
| bialix | this is very important IMO | 00:56 |
| poolie | maybe | 00:56 |
| poolie | i think we need to detangle the log from the ui a bit more | 00:56 |
| poolie | perhaps logging everything done to the ui makes sense | 00:56 |
| poolie | but it's still a bit weird atm | 00:57 |
| bialix | I'm not quite understand | 00:57 |
| poolie | so | 00:57 |
| poolie | for example, some tests that want to know about messages to the user look in the equivalent of .bzr.log | 00:58 |
| poolie | inside the test | 00:58 |
| poolie | this is a bit weird | 00:58 |
| poolie | some of the methods in trace.py are to do with logging, and some with user interaction | 00:58 |
| poolie | this kind of thing | 00:58 |
| bialix | I don't follow | 00:58 |
| bialix | we should not run tests with real translations | 00:59 |
| bialix | rather with zzz pseudo translations, which was invented by igc | 00:59 |
| poolie | ok | 00:59 |
| poolie | at the moment some tests fail just because we expect system exceptions to be in english | 01:00 |
| bialix | gettext is only half of the i18n and l10n | 01:00 |
| bialix | ah, yes | 01:00 |
| bialix | OSError stuff | 01:00 |
| bialix | yep, they are done so inside python itself | 01:00 |
| bialix | btw, this was changed only in 2.5 | 01:01 |
| bialix | 2.4 always prints english | 01:01 |
| bialix | at least for me | 01:01 |
| poolie | i agree we don't want the tests to know about every possible translation | 01:01 |
| bialix | also there will be desire to localize dates in bzr log | 01:02 |
| bialix | I have no idea how to test such things properly | 01:02 |
| poolie | it will take some creativity | 01:03 |
| poolie | i'm suggesting as a first step we avoid any accidental dependency on english in the tests | 01:03 |
| bialix | or just disable it for selftest | 01:03 |
| bialix | btw, in qbzr we don't enable gettext when we run selftest | 01:04 |
| bialix | ditto for bzr-explorer | 01:04 |
| poolie | james_w: if there's something you think would be a much better main focus than merge/resolve, please do speak up | 01:56 |
| james_w | I think it has its merits | 01:57 |
| james_w | and is a focus that will bring something to all stakeholders | 01:57 |
| poolie | k | 01:58 |
| poolie | i think so too | 01:58 |
| poolie | if there are particular bugs you can nominate them too at any point | 01:59 |
| poolie | spiv, i'm sure you understand this but it's not quite clear in your recent mails | 03:04 |
| poolie | which is that some things like os.read need special handling but can be handled correctly | 03:04 |
| poolie | whereas some just cannot be done correctly | 03:05 |
| poolie | perhaps clarifying this is less useful than just fixing the bug though :) | 03:05 |
| spiv | poolie: right | 03:21 |
| spiv | poolie: so until_no_eintr is currently correctly handling basically that case for us, read from a pipe | 03:22 |
| spiv | Unfortunately it seems all the other uses are broken. | 03:23 |
| spiv | That said, siginterrupt side-steps the whole mess for us quite nicely. | 03:24 |
| poolie | k | 03:24 |
| poolie | it may not work on all platforms | 03:24 |
| poolie | but it may cover enough of them | 03:24 |
| spiv | Yeah. | 03:28 |
| mwhudson | there are only three platforms anyway these days! | 03:33 |
| herbtea | hello all | 03:34 |
| spiv | mwhudson: hardy, karmic and lucid? | 03:34 |
| poolie | lol | 03:34 |
| mwhudson | poolie: not quite what i meant, but that'll do | 03:35 |
| * fullermd looks disgruntled :p | 03:35 | |
| mwhudson | fullermd: os x is almost like freebsd, right? | 03:36 |
| * mwhudson runs away and stops trolling | 03:36 | |
| lifeless | mwhudson: contagious huh ;> | 03:36 |
| fullermd | Don't mach me hurt you! | 03:36 |
| poolie | actually more seriously perhaps we should only run ppas for them | 03:36 |
| poolie | if that made it any easier | 03:37 |
| poolie | it's probably not much easier though | 03:37 |
| poolie | abentley: i guess you're asleep? | 03:37 |
| abentley | poolie, hi. | 03:37 |
| poolie | hi | 03:37 |
| poolie | i was just running tests in a bzr 2.0 branch | 03:37 |
| lifeless | 2230 or so, I'd guess. | 03:37 |
| poolie | and bzrtools's fail | 03:37 |
| poolie | because it checks the version when running the command, not when running the tests | 03:38 |
| poolie | so i was just thinking about this | 03:38 |
| lifeless | poolie: there is a test_selftest test that fails with bzrtools; its not really bzrtools fault though. I'm sure you are seeing more, I'm just mentioning one that I saw this morning. | 03:38 |
| poolie | it's not really urgent | 03:38 |
| poolie | this is different | 03:38 |
| poolie | essentially it runs its tests regardless of bzr version, but they can't possibly pass on 2.0 | 03:39 |
| poolie | so anyhow | 03:39 |
| poolie | - it's interesting not to grumble until someone actually uses the command | 03:39 |
| poolie | kind of cleaner than failing to load | 03:39 |
| poolie | - iwbni this was done through the standard channels, perhaps | 03:39 |
| poolie | - iwbni if the tests also skipped, or refused to load, if the commands aren't going to run | 03:40 |
| abentley | poolie, I see. The version mismatch checking is only done with the commands now, because people complained about bzrtools warning them when they were running irrelevant commands. | 03:40 |
| poolie | yeah | 03:40 |
| poolie | it's quite nice actually | 03:40 |
| poolie | perhaps that should be the standard thing | 03:40 |
| poolie | obviously it is a bit more difficult for plugins that act through hooks | 03:41 |
| abentley | I was just about to say that. | 03:41 |
| abentley | I guess I can add a version check to the bztools test_suite method. | 03:41 |
| poolie | and return []? | 03:42 |
| poolie | (semantically not literally) | 03:43 |
| poolie | anyhow separately, teddybears, i would like a way to cancel some user warnings systematically | 03:43 |
| poolie | istm it would be clean to give the uifactory a list of ones that have been squelched | 03:43 |
| poolie | then upgrade() can squelch the cross-format fetch warning for the duration of its run | 03:43 |
| abentley | poolie, no, I'd probably just emit a warning. I wouldn't want to interfere with actually testing bzrtools. | 03:46 |
| lifeless | one thing that occurs to me | 03:47 |
| lifeless | if you're doing per command version locking | 03:47 |
| poolie | ok, but at least some of the tests can't possibly pass, because they will examine the bzrlib version then fail | 03:47 |
| lifeless | is that you could use the test suite to tell you when commands break, and only change those commands to be requiring new versions | 03:47 |
| poolie | so we could say they are expected to fail | 03:47 |
| poolie | that would be interesting | 03:47 |
| poolie | at the moment this is the same check across all commands, but applied at invocation time | 03:48 |
| poolie | but you could do that | 03:48 |
| lifeless | put an attribute on the class; define a base value so most classes don't need to set it, sort of thing. | 03:48 |
| poolie | right | 03:49 |
| poolie | it would be interesting to consider how to do this for other things | 03:49 |
| poolie | in principle you could only complain about bzr-svn when you actually try to use a svn repo | 03:49 |
| abentley | lifeless, it's an interesting idea, but would it be useful? Most people will not have mismatches, assuming they use packaged versions. | 03:49 |
| poolie | it may be overkill | 03:50 |
| poolie | what i would like to get to is to get myself out of the habit of always testing with --no-plugins | 03:50 |
| poolie | by removing snags when they appear | 03:50 |
| lifeless | abentley: it would make it easier for devs to run with plugins enabled during test runs of core | 03:50 |
| lifeless | abentley: s/would/might/ | 03:50 |
| abentley | lifeless, so you would disable the tests for a command if there was a version incompatibility? | 03:51 |
| lifeless | abentley: I think gracefully show that the incompatibility is there, rather than hard-fail | 03:52 |
| lifeless | abentley: so to upgrade bzrtools, one would change the version lock, and they would start executing, and failing if there is a problem. | 03:52 |
| abentley | lifeless, yes, but what about the functions used by those commands? Those typically also have tests, and would not be version-locked. | 03:52 |
| lifeless | abentley: two angles occur to me: How often do they actually break? And perhaps you will get patches. | 03:53 |
| abentley | lifeless, and it's the functions that are likely to be incompatible. Most of the commands are thin wrappers. | 03:53 |
| abentley | lifeless, breaks have become pretty unusual, both in commands and in functions. | 03:54 |
| poolie | so perhaps you could just relax the maximum-version limit? | 03:56 |
| poolie | in this case i'm actually going back to an earlier version | 03:56 |
| poolie | so if it's marked incompatible, it probably really is | 03:56 |
| poolie | which is fine | 03:56 |
| poolie | but i just want the tests to do something clean | 03:56 |
| poolie | like report a missing dependency | 03:56 |
| === [1]herbtea is now known as herbtea | ||
| abentley | poolie, I'm thinking of relaxing the limit during test runs. In my testing 2.0 passes with bzrtools trunk when I do that. | 03:59 |
| abentley | poolie, I can relax the minimum-version limit, but I canna predict tha futurre, so changing the maximum-version limit is riskier. | 04:00 |
| poolie | yeah it's tough to say if it's better to get some false alarms or to get users complaining about weird attributeerrors when it does go out of date | 04:01 |
| spiv | How about emitting a warning about possible version-mismatch only when an error occurs? | 04:03 |
| poolie | could be good | 04:04 |
| spiv | Ideally only on TypeErrors and AttributeErrors, but probably other kinds will happen sometimes. | 04:04 |
| spiv | It depends on if the breakage is "doesn't even run" or "starts to run then leaves a broken mess" | 04:05 |
| spiv | If the latter can occur, you really do want to bias towards fail early. | 04:05 |
| herbtea | hi all, I'm a new bazaar user and I'm using explorer and I hope somebody can answer a question for me | 04:10 |
| herbtea | I've created a shared repository with a trunk | 04:10 |
| herbtea | added project directory and files from a new project | 04:11 |
| herbtea | so far so good | 04:11 |
| herbtea | when I click on the Local Changes tab for this repository there is a message " No parent location defined yet", what do I need to do to define the parent location? | 04:12 |
| spiv | Typically that's automatically set when you first 'bzr pull', or when you create a branch by doing 'bzr branch URL' | 04:16 |
| spiv | I'm not sure that it makes sense to set it for your case, but if you want to I'd guess that pulling from another location would do it. | 04:16 |
| spiv | (I'm not sure how to use explorer to do that, sorry) | 04:17 |
| abentley | poolie, lifeless, I've made the change in the 2.0, 2.1 and trunk series. | 04:18 |
| herbtea | spiv: thanks for the info. Still not 100% clear on the best process for setting up my project for versioning | 04:19 |
| poolie | abentley: which one? | 04:20 |
| herbtea | spiv: I did a bzr init-repo on a top level dir, then a bzr init on the trunk | 04:20 |
| herbtea | spiv: I then added my proj dir and files to the trunk and did a commit | 04:21 |
| spiv | (I'm a bit curious about why you thought you should set that location?) | 04:21 |
| herbtea | which location? | 04:21 |
| spiv | Well, you asked "what do I need to do to define the parent location?", which suggests you thought you should set it. | 04:22 |
| herbtea | yes | 04:22 |
| spiv | But that's a tangent to your current question, so ignore that if you like. | 04:22 |
| herbtea | I'm getting what appears to be an error message in explorer | 04:22 |
| herbtea | explorer says "No parent location defined yet" | 04:23 |
| spiv | The init-repo, init, add, then commit sounds good. | 04:23 |
| spiv | Ok, sounds like something that could be improved in explorer. | 04:23 |
| abentley | poolie, disabling the version check while commands are running. | 04:24 |
| herbtea | so, this is all local, I have a server that I want to be the main project repository, do I simply copy this top level dir I just created to the server? | 04:24 |
| spiv | Ah, ok. You can do that, although you'll want to 'bzr remove-tree' on the server afterwards to be tidy. | 04:25 |
| herbtea | ok, just the rev history on the server? | 04:26 |
| spiv | Or, you can 'bzr init-repo' the location on the server, then 'bzr push' your trunk to server | 04:26 |
| spiv | Right. | 04:26 |
| herbtea | kewl | 04:26 |
| herbtea | using the locations.conf, is there a way I can specify the parent location of a branch? | 04:26 |
| spiv | IIRC it's set in the branch's own .bzr/branch/branch.conf, but it might be possible to set it in locations.conf too | 04:27 |
| spiv | It would be the 'parent_location' option. | 04:27 |
| herbtea | thanks, I'll give that a go and see if that clears the error message in explorer | 04:28 |
| herbtea | thanks for your help spiv :) | 04:28 |
| bialix | garyyyyyy | 04:28 |
| herbtea | bye all | 04:29 |
| * bialix -> zzz | 04:36 | |
| === mordred_ is now known as mtaylor | ||
| Leemp | Question: Is there a good private hosting system for bzr? Eg, a software suite you can install that matches some of the feature sets Github and BitBucket provide? | 05:29 |
| Leemp | Ie, i need it private and not public.. so Launch won't work for me.. sadly. | 05:30 |
| bob2 | you can run launchpad yourself if you like! | 05:32 |
| bob2 | there's bzr-trac, too | 05:32 |
| lifeless | you can also pay for private launchpad hosting | 05:41 |
| lifeless | if you want | 05:41 |
| Leemp | lifeless: !? They're doing that now? | 05:44 |
| Leemp | lifeless: Last i checked, ages ago, they weren't heh. | 05:44 |
| poolie | Leemp, https://answers.edge.launchpad.net/launchpad/+faq/208 | 05:45 |
| poolie | says beta but it's in production | 05:45 |
| Leemp | poolie: Ah, still a bit expensive when compared to Git/HG it seems though | 05:47 |
| Leemp | poolie: Or are they offering different plans eventually/now, than they list in that faq | 05:47 |
| Leemp | And i wonder if that's per project.. | 05:48 |
| poolie | per project | 05:48 |
| Leemp | Ouch :o | 05:48 |
| poolie | not that it's not per user or per repo | 05:48 |
| poolie | or per project group, i would imagine | 05:49 |
| poolie | s/not/note | 05:49 |
| bob2 | depending on what project means, that's competitive with github at least | 05:49 |
| Leemp | bob2: Well it depends on size i suppose. For me though, a personal small developer, $5/mo gets me 5 projects iirc on github. | 05:50 |
| bob2 | 5 repositories | 05:50 |
| Leemp | Separate issue tracking for each one, etc | 05:50 |
| Leemp | bob2: Does launchpad group all the features it provides per repo? or per "project"? .. We're getting cross terms anyway heh. | 05:51 |
| Leemp | bob2: Eg, would i still have 5 separate issue trackings, and whatnot, with launchpad? Or only a single issue tracking, for a single "project"? | 05:52 |
| poolie | Leemp: i suggest you mail them or ask in #launchpad | 05:52 |
| Leemp | poolie: Righto, conversation slid that way i guess :) | 05:53 |
| Leemp | So on the bzr side of things | 05:53 |
| Leemp | There's a trac mod, and i can run launchpad myself. | 05:53 |
| poolie | right | 06:02 |
| poolie | spiv, lifeless, can i have a quick review on the ui_factory side of https://code.edge.launchpad.net/~mbp/bzr/456077-cross-format-fetch/+merge/20041 | 06:03 |
| poolie | ie adding a show_user_warning(warning_id, **) that can be turned off by a flag | 06:03 |
| spiv | poolie: looks ok to me | 06:07 |
| spiv | I'll add a slightly longer review to the proposal :) | 06:08 |
| poolie | thanks | 06:10 |
| RyNy_ | having a problem branching from LaunchPad | 06:11 |
| poolie | k | 06:11 |
| RyNy_ | This is my error | 06:11 |
| RyNy_ | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 06:11 |
| spiv | RyNy_: pastebin the full error? | 06:12 |
| RyNy_ | Sorry, how? | 06:12 |
| spiv | RyNy_: paste it into http://pastebin.com/, then share the resulting URL here | 06:13 |
| RyNy_ | Spiv: sorry how do I get more of an error? That's all I see in Terminal. | 06:15 |
| RyNy_ | This is the command: bzr branch lp:~pantheon-developers/projectmercury/bcfg2 /var/lib/bcfg2 | 06:15 |
| spiv | RyNy_: interesting, often there's more text than that | 06:16 |
| spiv | RyNy_: could you paste the most recent section of you ~/.bzr.log, then? | 06:17 |
| poolie | RyNy_: at a guess your ssh command to connect is not working | 06:17 |
| poolie | what does 'ssh bazaar.launchpad.net' do? | 06:17 |
| RyNy_ | spiv: there's not anything more in the log file. | 06:20 |
| RyNy_ | I also had this error on a different server trying to branch from the same source: | 06:21 |
| RyNy_ | bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~pantheon-developers/projectmercury/bcfg2/". | 06:21 |
| Peng | That's correct. It's not. | 06:22 |
| Peng | That branch does not exist,. | 06:23 |
| RyNy_ | Peng: What am I doing wrong? Is it the ~ ? | 06:23 |
| RyNy_ | Peng: If it is any help here is the URL for the project: https://code.launchpad.net/projectmercury | 06:24 |
| Peng_ | RyNy_: The only existing branch in that project is lp:~pantheon-developers/projectmercury/trunk (which you can also refer to with the shorthand lp:projectmercury) | 06:26 |
| RyNy_ | Peng: Thanks, so the branch doesn't exist. I see that now by looking at the project site at LaunchPad. | 06:28 |
| RyNy_ | Question: I suppose if it did exist then it would appear on that URL under the branches tab, right? | 06:29 |
| Peng | Uh-huh. | 06:29 |
| RyNy_ | Peng: Cool. I do see a bcfg2 file at http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files. | 06:31 |
| RyNy_ | Suppose if I were to guess what the correct path should be, it would be http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files/head%3A/bcfg2/ | 06:32 |
| Peng | What are you trying to do, exactly? | 06:32 |
| spiv | Correct path for what? | 06:32 |
| Peng | Those two URLs are for the Loggerhead web viewer running in bazaar.launchpad.net. | 06:32 |
| spiv | That's a correct path for viewing the 'bcfg2' directory of the ~pantheon-developers/projectmercury/trunk branch via the web viewer. | 06:33 |
| spiv | But it's not a valid location to use with 'bzr branch' | 06:33 |
| RyNy_ | I'm trying to branch from Project Mercury, which is a high performance Drupal installation. I'm following the install directions, but they broke on that branch command. | 06:34 |
| Peng | "bzr branch lp:projectmercury" | 06:34 |
| RyNy_ | You can see the install directions at: http://groups.drupal.org/node/50408 | 06:34 |
| Peng | Where are these instructi -- thanks. :D | 06:34 |
| spiv | RyNy_: my guess is those instructions are out of date | 06:35 |
| spiv | RyNy_: I think someone probably renamed (or deleted?) the ~pantheon-developers/projectmercury/bcfg2 branch | 06:35 |
| RyNy_ | I commented where I got stuck. Search on the page for bzr branch lp:~pantheon-developers/projectmercury/bcfg2 /var/lib/bcfg2 | 06:35 |
| poolie | spiv, could it be that https://bugs.edge.launchpad.net/bzr/+bug/280608 has already been fixed by you? | 06:35 |
| ubottu | Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,In progress] | 06:35 |
| spiv | poolie: it could be! | 06:36 |
| spiv | poolie: off the top of my head, I'm not certain. I have certainly touched code in that area, and may well have fixed that. | 06:37 |
| spiv | poolie: but I couldn't be sure without trying to reproduce, I think. | 06:37 |
| RyNy_ | ubottu: sorry, what that directed to me? Launchpad bug 280608 | 06:38 |
| spiv | poolie: I'd guess about 70% likely to have fixed that | 06:38 |
| ubottu | Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,In progress] https://launchpad.net/bugs/280608 | 06:38 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 06:38 |
| spiv | RyNy_: no, that bug was for me | 06:38 |
| spiv | RyNy_: right, I see your comments | 06:38 |
| spiv | RyNy_: the simple fact is that there is currently no lp:~pantheon-developers/projectmercury/bcfg2 branch | 06:39 |
| RyNy_ | Spiv: ok so I'm not loco, just bad branching instructions? | 06:39 |
| Peng | RyNy_: Well, out-of-date instructions. | 06:39 |
| RyNy_ | That helps I suppose. Just have to wait for the instructions to be updated or better. | 06:39 |
| RyNy_ | Thanks for your help. | 06:40 |
| spiv | RyNy_: right. I expect they were good once, but have gone stale because that branch has gone | 06:40 |
| spiv | RyNy_: If I had to guess, | 06:40 |
| spiv | RyNy_: I would try either using lp:projectmercury branch instead, and if that fails, using the 'bcfg2' inside that branch instead. | 06:40 |
| spiv | RyNy_: but that's just guesswork :) | 06:40 |
| spiv | RyNy_: also, the errors you've pasted into that wiki page have the extra text I was looking for before when you first joined this channel. Argh! :) | 06:41 |
| spiv | (Even though that turned out to be unimportant) | 06:42 |
| poolie | :) | 06:42 |
| RyNy_ | Spiv: sorry the wiki comments were from a couple nights ago. If you were to guess the correct bcfg2 path, what would it be? | 06:43 |
| spiv | RyNy_: well, https://code.launchpad.net/~pantheon-developers/projectmercury/ only shows one branch | 06:44 |
| spiv | RyNy_: and as you've noticed that branch has a bcfg2 directory (as you can see at the http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files/head%3A/bcfg2/ link) | 06:44 |
| spiv | RyNy_: so there aren't many options; probably those instructions either expect that entire branch, or that subdirectory of that branch, or something that isn't there at all. | 06:45 |
| RyNy_ | Spiv: so is the command I'm looking for bzr branch lp:~pantheon-developers/projectmercury/trunk/bcfg2 /var/lib/bcfg2 | 06:46 |
| spiv | RyNy_: I don't know | 06:47 |
| spiv | RyNy_: Actually | 06:47 |
| spiv | RyNy_: I know it's not that command, because that's not a branch | 06:47 |
| spiv | RyNy_: (you can't 'bzr branch' a subdirectory of a branch) | 06:47 |
| spiv | RyNy_: You might need "bzr branch lp:projectmercury" /var/lib/bcfg2 | 06:48 |
| spiv | er, | 06:48 |
| spiv | "bzr branch lp:projectmercury /var/lib/bcfg2" | 06:48 |
| Peng | RyNy_: Ask the Project Mercury people or, failing that, someone else who knows what bcfg2 is. | 06:49 |
| spiv | Or you might need "bzr branch lp:projectmercury /tmp/projectmercury && cp -a /tmp/projectmercury/bcfg2 /var/lib/bcfg2" to just grab that subdirectory | 06:49 |
| spiv | Or maybe something else; I really don't know. | 06:50 |
| Peng | RyNy_: Try spiv's suggestions first, of course, but you should still report to them that their docs are out-of-date. | 06:50 |
| RyNy_ | Cool, on the branches page of their LaunchPad page that is the only branch. I'll contact them again and see if I can get some help. | 06:50 |
| RyNy_ | You guys have been very helpful. Thanks! | 06:51 |
| spiv | You're welcome. | 06:51 |
| Peng | :) | 06:51 |
| === RickCogley is now known as RickCogley_ | ||
| poolie | spiv, can you suggest anything to https://answers.launchpad.net/bzr/+question/102270 ? | 07:21 |
| === RickCogley_ is now known as Rick_Cogley | ||
| === Rick_Cogley is now known as rickcogley | ||
| === rickcogley is now known as RCogley | ||
| === RCogley is now known as RickCogley | ||
| vila | hi all ! | 07:25 |
| * fullermd waves at vila. | 07:25 | |
| vila | fullermd: \o_ | 07:26 |
| fullermd | vila: BTW, fix to paramiko port committed {to,yester}day, so the unadorned port won't break with setuptools. | 07:26 |
| fullermd | Now if only a new version of paramiko would be released that didn't crap on pycrypto... | 07:26 |
| vila | fullermd: good to know ! | 07:29 |
| vila | I dislike that kind of workaround otherwise as I tend to forget.... what was I speaking about ? | 07:29 |
| fullermd | Eh? Who're you? | 07:29 |
| spiv | poolie: sure | 07:33 |
| spiv | poolie: (short answer: post_branch_tip_change + TipChangeRejected) | 07:33 |
| spiv | I mean, s/post/pre/, of course | 07:35 |
| poolie | thanks | 07:35 |
| * poolie fixed a bug with 7 dupes, that's a nice feeling | 07:35 | |
| * spiv finishes for the day, time to swim | 07:38 | |
| poolie | me too | 07:38 |
| poolie | cheerio | 07:38 |
| poolie | hi vila, bye vila | 07:38 |
| spiv | poolie: oh, that looks like a nice bug to have fixed! | 07:39 |
| spiv | I might review that later tonight. | 07:39 |
| * spiv -> really gone | 07:39 | |
| vila | poolie: lol | 07:39 |
| vila | lifeless: pong ? | 08:21 |
| poolie | hi vila | 09:23 |
| vila | poolie: Are you back or a poolie's clone ? :D | 09:24 |
| poolie | really here | 09:24 |
| ronny | hi, where can i get something like rebase? | 09:24 |
| poolie | my desktop is a bit sad | 09:24 |
| vila | good ;) | 09:24 |
| poolie | ronny: bzr-rewrite | 09:25 |
| vila | ronny: lp:bzr-rebase ? | 09:25 |
| vila | ronny: right, lp:bzr-rebase redirects to https://edge.launchpad.net/bzr-rewrite anyway | 09:26 |
| ronny | hmm | 09:27 |
| ronny | i reverted to using diff, pull --overwrite;patch | 09:28 |
| lifeless | vila: I was thinkin we should finish the parallel stuff | 09:32 |
| vila | lifeless: <shudder> I'd love too... What TZ are you in these days ? | 09:34 |
| lifeless | GMT+12 more or less | 09:34 |
| vila | NZ ? | 09:34 |
| lifeless | waking early in .au | 09:35 |
| Kamping_Kaiser | very early | 09:36 |
| vila | AFAIR, your main objection was about compatibility with EC2-like setups, I still have to investigate how I can test that locally (I haven't even look at --parallel=?? damn, bzr help selftest doesn't even mention the possible values :-/) | 09:37 |
| * bialix waves at vila | 09:38 | |
| vila | bialix: _o/ | 09:38 |
| bialix | _o> | 09:39 |
| vila | lol | 09:39 |
| fullermd | Offsides. 5 yard penalty. | 09:39 |
| vila | fullermd: I'm affraid neither bialix nor I can undesrtand that :D | 09:40 |
| poolie | i'd like to do something that suggests missing commands be installed from plugins | 09:42 |
| poolie | i think we talked about this before | 09:42 |
| vila | poolie: with beuno I think | 09:42 |
| fullermd | vila: Oh, it doesn't really mean much. | 09:43 |
| vila | poolie: AFAIR lifeless and beuno talked about some kind of registry but I now wonder if a bzr-guess-like approach couldn't be easier | 09:46 |
| lifeless | the registry is built | 09:50 |
| lifeless | just needs populating | 09:50 |
| lifeless | Thats why I wrote the plugin metadata scanner | 09:50 |
| lifeless | in principle, all you need to do is: | 09:51 |
| lifeless | - write a plugin which hooks command not found (like -guess does) | 09:51 |
| lifeless | - give it a static dict of metadata | 09:51 |
| lifeless | - write a script to analyse the plugin metadata for as many plugins as you can get your hands on and shove it into that dict every now and then, | 09:51 |
| lifeless | vila: yes, that was my main objection. | 09:52 |
| lifeless | [parallel] | 09:52 |
| poolie | yeah | 09:56 |
| poolie | though {'rebase', 'https://launchpad.net/bzr-rewrite'} would solve 50% of it ;-) | 09:57 |
| lifeless | sure | 09:57 |
| lifeless | I would support someone starting that way | 09:58 |
| lifeless | though bzr branch lp:plugin-info is pretty easy too | 09:58 |
| lifeless | I'd finish it off myself, but its not top of my TODO pile | 09:58 |
| Kamping_Kaiser | wonder why pulling lp:bzr on consecutive days can give me file conflicts | 10:09 |
| * Kamping_Kaiser blames rouge pixels | 10:09 | |
| bob2 | any local diffs? | 10:19 |
| Kamping_Kaiser | nope. | 10:26 |
| Kamping_Kaiser | i'm doing an 'mr up', and theres almost always 1 or 2 bzr repos conflict out (or not apply their changes). i've not dug into mr to discover if it has a timeout of some sort on doing updates | 10:26 |
| Kamping_Kaiser | even with an update, i find it odd to wind up with conflicts | 10:27 |
| bob2 | ah, not bzr itself? | 10:27 |
| Kamping_Kaiser | todays conflict was lp:bzr | 10:27 |
| Kamping_Kaiser | i don't know how bzr is called by mr to do the update though | 10:27 |
| johnf | Is there an easy way to have the working tree updated on the server when using bzr+ssh where all the work is done server side? | 10:56 |
| vila | johnf: lp:bzr-push-and-update | 11:02 |
| johnf | vila: I just realised that it does actually do what I want. I misread it before, thanks | 11:02 |
| johnf | vila: isn't that client side? | 11:24 |
| vila | johnf: it is | 11:25 |
| vila | oooh, you mean you want the tree to updated automatically like with some hook ? | 11:25 |
| johnf | I was after something that worked on the server so that I don't have to reply on my users having a plugin installed | 11:25 |
| johnf | yes | 11:25 |
| vila | hmm | 11:25 |
| johnf | or even it could just push on the server to a different location | 11:25 |
| johnf | but somewhere on the server I want an up to date working tree | 11:26 |
| johnf | maybe I can get automirror to do what I want | 11:27 |
| vila | could be | 11:27 |
| vila | I don't know about pre-canned solutions for that myself, but others may | 11:27 |
| gioele | hello | 13:17 |
| bialix | hello | 13:23 |
| jml | hi | 14:39 |
| jml | I'm writing a plugin | 14:39 |
| jml | it's designed to replace a hook that Twisted is using to require all trunk commits to add "news fragment files" | 14:40 |
| jml | I figure that pre_change_branch_tip is the right kind of hook | 14:43 |
| jml | but I'm not sure whether in that hook I should check each new revision individually, or whether I should check the result of the whole | 14:44 |
| Lo-lan-do | Hi all | 14:52 |
| Lo-lan-do | Remind me again how I fetch ghost revisions from another repository that has them? | 14:52 |
| jelmer | Lo-lan-do, bzr fetch-ghosts | 15:15 |
| Lo-lan-do | Aha, thanks. | 15:17 |
| jelmer | jml: I'm not sure I understand your question correctly | 15:18 |
| jelmer | jml: but it'll be called only once if you pull in a lot of revisions into mainline, for example | 15:21 |
| abentley | jam: around? | 15:43 |
| muffinresearch | on the subject of pre_change_branch_tip is there an easy way of introspecting the type of change made e.g, push, commit, uncommit etc? | 15:45 |
| muffinresearch | sorry meant post_change_branch_tip not pre | 15:46 |
| jelmer | muffinresearch, you can register to individual hooks for those | 15:46 |
| muffinresearch | jelmer: This is running on the server rather than the client. | 15:47 |
| lifeless | the server doesn't know in that case | 15:47 |
| jelmer | muffinresearch: does post_change_branch_tip run on the server ? | 15:47 |
| lifeless | jelmer: yes | 15:47 |
| jelmer | ah, nice | 15:47 |
| lifeless | jelmer: (another reason to use it in zeitgeist :P) | 15:48 |
| jelmer | lifeless, actually for zeitgeist you'd want client side hooks since that's where your zeitgeist daemon is running | 15:49 |
| lifeless | jelmer: that hook runs on both sides | 15:49 |
| lifeless | I was meaning if you push to your laptop from somewhere | 15:49 |
| jelmer | ah, right | 15:50 |
| muffinresearch | Right now I'm looking at the revnos to work out if it's a commit which feels a bit clunky. | 15:52 |
| === salgado is now known as salgado-lunch | ||
| mathrick | jelmer: poke? | 16:00 |
| jelmer | mathrick, hello | 16:00 |
| mathrick | did you see the crasher about map.read() not being a method I ran into yesterday? | 16:00 |
| jelmer | yeah, that'd already been fixed just not pushed yet | 16:01 |
| jelmer | see lp:dulwich | 16:01 |
| mathrick | ah | 16:01 |
| mathrick | good then | 16:01 |
| mathrick | and the other bug about annotate? This one I filed properly in launchpad | 16:02 |
| mathrick | https://bugs.launchpad.net/bzr-git/+bug/526792 this one | 16:02 |
| ubottu | Launchpad bug 526792 in bzr-git "Revision not present error in annotate" [Undecided,New] | 16:02 |
| mathrick | poolie said it looked like a bug that's been fixed already in bzr itself, but I'm pretty up to date | 16:02 |
| * mathrick notes he still doesn't understand how the new package structure for bzr is supposed to work, so far it seems to mean no new versions for karmic and no gains | 16:03 | |
| jelmer | mathrick: that looks like a bzr core bug to me | 16:09 |
| mathrick | ok, how do I diagnose it then? | 16:09 |
| jelmer | mathrick, what do you mean with new package structure? | 16:12 |
| mathrick | the thing where PPA no longer gets packages | 16:12 |
| mathrick | I think it's supposed to be replaced by main repo uploads, except that I get none in karmic | 16:13 |
| mathrick | so overall I'm left out in the cold | 16:13 |
| jelmer | mathrick: I think Gary has just fixed the PPA | 16:17 |
| mathrick | oh, lemme take a look | 16:18 |
| mathrick | jelmer: I might be confused, but last time I complained about it, I got told it was in the middle of a policy change and there was a thread I didn't have the time to read properly | 16:19 |
| jelmer | mathrick: My understanding was also that the idea was to just have recent versions of bzr in backports for older Ubuntu releases | 16:20 |
| jelmer | but I'm not involved in that part of Bazaar, so I'm not sure what the status or exact plans are | 16:20 |
| jelmer | poolie should know more, we should ask him when he's back | 16:22 |
| mathrick | right | 16:22 |
| mathrick | mathrick@hatsumi:~/elisp/dist/dvc$ bzr log lp:bzr -r 4797.19.2..-1 | 16:22 |
| mathrick | bzr: ERROR: Start revision not found in left-hand history of end revision. | 16:22 |
| mathrick | huh? | 16:22 |
| mathrick | what does that mean? | 16:22 |
| mathrick | it means it wants me to say -n0, but that's a crappy error message | 16:23 |
| jelmer | mathrick, please file a bug | 16:24 |
| mathrick | yeah, doing that now | 16:24 |
| vila | mathrick: please explain what you were trying to achieve with that command | 16:25 |
| jelmer | mathrick, thanks | 16:25 |
| jelmer | vila: do you happen to know what the status/plans for bzr in the backports for older Ubuntu releases is? | 16:25 |
| mathrick | vila: see everything that happened on the main bzr branch since 2.1.0 got released | 16:25 |
| mathrick | I started with tag:bzr-2.1.0 and that's the revision it corresponds to | 16:25 |
| vila | jelmer: AIUI, it's hapening. slowly | 16:27 |
| jelmer | mathrick: you should also be able to just use tag:2.1.0 rather than the version number | 16:27 |
| mathrick | jelmer: I did that, but thought the error was because of that at first | 16:28 |
| jelmer | mathrick: although admittedly that isn't an excuse for giving such a bad error message | 16:28 |
| mathrick | which is why I switched to the explicit revno | 16:28 |
| mathrick | but that doesn't help anything, since that's completely not what bzr was complaining about | 16:28 |
| jelmer | vila: ah, thanks. This is mainly waiting for SRU's to get approved? | 16:28 |
| vila | the bad error message is a consequence of an optimization... abstraction leak ftl :-/ | 16:29 |
| vila | jelmer: that's what I understand yes | 16:29 |
| mathrick | why does it error out when I want to start with a merge anyway? | 16:32 |
| mathrick | vila: oh | 16:32 |
| vila | mathrick: if you have a up-to-date bzr.dev, 'bzr missing lp:bzr/2.1' will better answer your question I think | 16:32 |
| mathrick | I don't, which is why I didn't do it locally | 16:33 |
| mathrick | I love that bzr lets me ask questions about remote repos | 16:33 |
| mathrick | and I get annoyed each time git tells me I don't need that because it's not as "efficient" | 16:33 |
| mathrick | vila: so there's no way to give two explicit locations to bzr missing? | 16:35 |
| * mathrick thinks absolutely everything should accept a location or -d | 16:35 | |
| vila | mathrick: the only trick I can think of then is using 'bzr qlog lp:bzr/2.1 lp:bzr' :-/ | 16:35 |
| mathrick | that's such a boon when trying to nagivate a forest of branches you need to find a specific change in, but don't want or need to download | 16:36 |
| vila | mathrick: please meet bialix about generic -d :-D | 16:36 |
| mathrick | heh | 16:36 |
| mathrick | can I file a bug about it, or is there one already? | 16:37 |
| vila | mathrick: note that the qlog trick allows you to navigate at will and should clearly shows what each branch is missing from the other | 16:37 |
| mathrick | yeah, a browser in this situation is probably the best option | 16:38 |
| mathrick | but the point stands | 16:38 |
| mathrick | seriously, operating on arbitrary locations is to bzr what rebase -i is to git | 16:38 |
| vila | mathrick: I don't remember of hand, if you have good arguments, feel free to file a new one, it's sometimes easier to de-dupe | 16:38 |
| mathrick | ie. the reason to switch | 16:38 |
| vila | mathrick: I agree with -d, I think it could be implemented quite easily but it may require checking all commands for consistency | 16:39 |
| jelmer | mathrick: did the annotate error occur with a recent version of bzr? what does "bzr check" say? | 16:42 |
| mathrick | speaking of killer features, it should be mentioned in bold on the "reasons to switch to bzr" page | 16:42 |
| mathrick | jelmer: 2.1.0 | 16:42 |
| mathrick | lemme try | 16:42 |
| mathrick | https://bugs.launchpad.net/bzr/+bug/527878 | 16:49 |
| ubottu | Launchpad bug 527878 in bzr "All commands should accept an explicit location or -d" [Undecided,New] | 16:49 |
| mathrick | jelmer: http://pastebin.com/2mhRe15K | 16:52 |
| mathrick | btw, it's a colocated repo, that is I'm using bzr-colo with it | 16:52 |
| x_dimitri | how does one set one's identity per banch using qconfig? | 16:52 |
| jelmer | mathrick: does bzr reconcile fix it perhaps? | 16:53 |
| mathrick | I can try | 16:53 |
| mathrick | what's "inconsistent parents" btw? | 16:53 |
| mathrick | hmm | 16:53 |
| jelmer | text revision parents that aren't set correctly | 16:53 |
| mathrick | I think it just got confused | 16:53 |
| mathrick | http://pastebin.com/aFEbpfbM <-- is that supposed to happen? | 16:55 |
| mathrick | ~/Dev/ is my shared repo | 16:55 |
| jelmer | mathrick: that looks ok | 16:59 |
| jelmer | mathrick: Does annotate work now? | 16:59 |
| mathrick | nope, though I'm hitting several bugs at once it seems | 16:59 |
| mathrick | nope, same bug, and a couple of other ones | 17:00 |
| jelmer | mathrick: what other ones? | 17:02 |
| === beuno is now known as beuno-lunch | ||
| mathrick | sorry, apparently I need a new battery for my laptop | 17:25 |
| mathrick | did anything happen since <mathrick> nope, same bug, and a couple of other ones ? | 17:25 |
| jelmer | mathrick, yeah, I asked what other bugs you were hitting? | 17:32 |
| mathrick | jelmer: ah, the impossibility of annotating a file that's not currently in the working tree (ie. removed or renamed) | 17:32 |
| jelmer | mathrick, doesn't -r allow you to do that? | 17:33 |
| mathrick | nope | 17:33 |
| mathrick | jelmer: http://pastebin.com/6VkcBi8J | 17:38 |
| jelmer | does bzr check still report errors? | 17:38 |
| GaryvdM | mathrick: Hmm annotate -r does not work on a deleted file. Thats a bug. qannotate works though. | 17:39 |
| mathrick | sec | 17:39 |
| mathrick | GaryvdM: oh, interesting | 17:40 |
| mathrick | jelmer: yep, still 201 inconsistent parents | 17:40 |
| mathrick | which I still don't quite understand what are | 17:41 |
| jelmer | mathrick: "bzr reconcile" should fix those.. | 17:41 |
| mathrick | but apparently it didn't :\ | 17:41 |
| mathrick | I did it again, just to be sure, and it still didn't fix anything | 17:45 |
| mathrick | and apparently I can't clone from it either | 17:47 |
| mathrick | though curiously enough, I can branch within the colocated workspace | 17:48 |
| mathrick | so it might have something to do with the colocated branches, bzr branch . /tmp/test errors out with revision not present, but bzr branch colo:trunk /tmp/test works | 17:49 |
| === salgado-lunch is now known as salgado | ||
| ubuntujenkins | Hi guys I am working with the ubuntu manual project and we are going to capture screen shots for all 40 languages that it is translated in. We are in the process of devleoping a program to deal with them. We were thinking of setting up a bzr branch to with subfolders for each language and within those one for each chapter. How ever we would like our program (quickshot) to only pull the folder for the relevant language. is | 18:15 |
| ubuntujenkins | this possible? or will I have to make forty branches? | 18:15 |
| mathrick | ubuntujenkins: AFAIK, no, at this point it's not possible to pull a partial repo | 18:15 |
| mathrick | it's a requested feature, but it's not trivial to implement in bzr, which is fundamentally organised around the notion of the tree as the atomic unit of change | 18:16 |
| ubuntujenkins | ok thanks mathrick that was a very fast response. forty branches it is | 18:16 |
| mathrick | ubuntujenkins: nested branches is the name of the feature that'll eventually lead there, but it's still not there to be enabled by default | 18:17 |
| ubuntujenkins | do we know when it will be avalible? | 18:17 |
| === beuno-lunch is now known as beuno | ||
| fullermd | Mmmm. I think that's slightly misleading... | 18:18 |
| mathrick | fullermd: if it is, please correct me :) | 18:18 |
| * mathrick apologises for any factual errors | 18:18 | |
| fullermd | Nested branches don't let you pull around parts of branches, they just make it easier to lay out multiple branches. | 18:19 |
| ubuntujenkins | so i am right I can't do nested branches yet? I wish you could | 18:19 |
| mathrick | ah, yeah, but with nested branches + splits it'd be possible to get a layout that pretty mimics the desired effect | 18:19 |
| fullermd | Well, you can manually put one branch "inside" another. That works fine; just that the "outer" branch doesn't know anything about the "inner" one. | 18:20 |
| ubuntujenkins | that seams point less some people have requested that we have it possible to pull one huge branch so that they can compile the manual in multiple languages. | 18:21 |
| fullermd | Right, that's what nested trees would give you; it would automate bundling all 40 (or however many) branches together in a particular layout. | 18:22 |
| ubuntujenkins | but I coun't pull them as one big one right? | 18:23 |
| fullermd | With nested trees, you would be able to. You can't now, no. | 18:23 |
| mathrick | ubuntujenkins: small spelling nitpicks: "however", "pointless", "seems" (seams is a different, unrelated word) | 18:23 |
| fullermd | (well, you can multi-pull to sorta fake it, but I presume you actually mean 'branch' when you say 'pull' there, not the actual 'pull' command) | 18:24 |
| ubuntujenkins | I ment pull all 40 branches as if it was one big branch | 18:25 |
| mathrick | ubuntujenkins: you can't do it now, but you could with nested branches, which are not finished yet | 18:27 |
| mathrick | in other words, no you can't, sorry | 18:27 |
| ubuntujenkins | cool thanks for your help guys sorry I got a bit confused in the middle of all that. | 18:27 |
| fullermd | There are... things that it's pointless to say after you /part. | 18:27 |
| * fullermd goes back into his hole | 18:28 | |
| mathrick | heh | 18:28 |
| * fullermd blinks. | 18:30 | |
| fullermd | It's Thursday? The heck? What happened to Tuesday? | 18:30 |
| vila | alzheimer again.... | 18:31 |
| * fullermd sighs. | 18:31 | |
| fullermd | Once again, the world fails to conform to my expectations. This is becoming a serious problem. Somebody needs to be taken to task. | 18:31 |
| vila | hehe | 18:32 |
| jam | hi abentley, sorry I was out this morning with a sick child | 18:33 |
| jam | hey vila | 18:33 |
| vila | hey jam! | 18:33 |
| abentley | jam, hi. | 18:38 |
| abentley | I was wondering whether you had any insight into the memory consumption issue I posed about in canonical-bazaar. | 18:38 |
| jam | haven't gotten to that folder yet, let me go check | 18:39 |
| jam | so... this is with 2.1? | 18:40 |
| jam | initial branch was specifically cut by about 50% for branching launchpad in the 2.1 series | 18:40 |
| jam | abentley: the other possibility would be to try changing the fetch to be "unordered" rather than "groupcompress" | 18:41 |
| jam | oh, and is this client-side, server-side? local branching? | 18:41 |
| abentley | jam, this was branching using bzr.dev 5051, from Launchpad to local over bzr+ssh. | 18:42 |
| jam | and IIRC lp uses 64-bit python, which averages 50-100% more memory consumption than 32-bit python | 18:42 |
| abentley | jam, the memory consumption I experienced was on my laptop which runs 32-bit Ubuntu. | 18:42 |
| jam | abentley: k, so the memory consumption you were seeing was on the client side? | 18:42 |
| jam | and do you know *when*? | 18:42 |
| jam | it could be during fetch, or it could be during building the working tree | 18:42 |
| jam | for example | 18:43 |
| jam | or if you know what stage of fetch | 18:43 |
| abentley | It was steadily increasing during fetch. The highest I saw was 600m+ | 18:43 |
| jam | I *do* know some places that could be trimmed a bit more, but was trying to figure out the tradeoffs | 18:43 |
| jam | abentley: then how did you figure 1.8GB peak ? | 18:43 |
| abentley | jam: I saw it at 1.8, but it was finishing up, and I can't swear whether it was writing pack files or what. | 18:44 |
| jam | k | 18:44 |
| jam | do you know if the codebase has large files? | 18:44 |
| abentley | I do know it was before the message about building a working tree was printed on my terminal. | 18:44 |
| jam | like say a ~400MB file in there? | 18:44 |
| abentley | But the system was thrashing a lot at that point. | 18:44 |
| jam | the repacking code is specifically a bit wasteful of memory sometimes | 18:45 |
| jam | hence 'unordered' could fix it as it wouldn't try to pack-on-the-fly as much | 18:45 |
| abentley | I can say the size of the repo is 571 M and the total size of the standalone branch, including working tree is 609M | 18:47 |
| abentley | So the largest a file could be would be 38M | 18:47 |
| === deryck is now known as deryck[lunch] | ||
| jam | abentley: well, it could be 600M and you just have a whole bunch of 10byte files :) | 18:47 |
| jam | oh sorry, I missed that last part | 18:48 |
| jam | sure | 18:48 |
| jam | seems odd | 18:48 |
| jam | is there a lot of history? (how many revisions, etc) | 18:48 |
| jam | how wide is the tree? | 18:48 |
| abentley | jam, it's a conversion from bzr-svn, so the history might be wacky. | 18:48 |
| abentley | jam, are you able to see the branch page? If so, you are a "bzr expert" and can download it for yourself. | 18:50 |
| jam | I don't think I am, but I can check | 18:51 |
| jam | abentley: nope, permission denied | 18:52 |
| abentley | jam: i can mirror it to devpad for you, if it helps. | 18:53 |
| jam | abentley: would make it easier for me to test, yes | 18:53 |
| jam | preferably an exact copy using lftp if you could | 18:53 |
| jam | so that we don't run into 'slightly different pack layout' issues | 18:54 |
| abentley | jam, I'm using hitchhiker. | 18:57 |
| jam | that's fine | 18:57 |
| jam | I just mean a mirror of the push side | 18:57 |
| jam | rather than 'bzr branch' | 18:57 |
| abentley | jam, mirrored to: ~abentley/economist | 18:59 |
| jam | hmm... there only seems to be 1 pack file, is that true on the hosted side? | 19:05 |
| BasicOSX | Is there a way to convert a "bzr co sftp://host/repo" to a "bzr branch sftp://host/repo" ? | 19:07 |
| jam | BasicOSX: bzr unbind | 19:07 |
| BasicOSX | jam: that's awesome ty | 19:07 |
| abentley | jam, yes. | 19:09 |
| GaryvdM | jelmer: is this the latest dulwich branch with debian packaging: http://bzr.debian.org/users/jelmer/dulwich/unstable/ ? | 19:14 |
| GaryvdM | (I could not find any others, but it worries me that it is in your user folder, not some where else.) | 19:16 |
| x_dimitri | how does one do the equivalent of "bzr whoami --branch USER_DETAILS" with qconfig? | 19:20 |
| GaryvdM | x_dimitri: you can't at the moment. | 19:20 |
| x_dimitri | GaryvdM: :-( | 19:20 |
| GaryvdM | x_dimitri: There is bug logged. | 19:21 |
| x_dimitri | GaryvdM: :-) | 19:21 |
| mathrick | speaking of which, is there something like bzr config? | 19:23 |
| GaryvdM | Nope | 19:23 |
| mathrick | it'd be a bit nicer than mucking around with text files, especially for per-branch settings, which require you to type the full path in ~/.bazaar/bazaar.conf | 19:24 |
| NfNitLoop | So I was watching this talk by Linus to Google about git. And he seemed to be adamant about the fact that git hashes all of its contents so that it can be verified. (no disk corruption, no tampering.) | 19:25 |
| NfNitLoop | bzr doesn't do something similar? | 19:25 |
| NfNitLoop | I mean, if I do 'bzr check' and there was corruption or tampering, it'd find it, no? | 19:25 |
| mathrick | NfNitLoop: yes and no | 19:26 |
| mathrick | it hashes everything, but by default doesn't require signing | 19:26 |
| mathrick | so you can't actually *verify* anything unless it's signed | 19:26 |
| mathrick | but the same is really true for git | 19:27 |
| mathrick | long story short: everything git has, bzr has too | 19:27 |
| mathrick | at least as far as being tamper-proof goes | 19:27 |
| NfNitLoop | Oh. Where does it store these hashes? | 19:28 |
| mathrick | NfNitLoop: bzr actually is a bit better, since git is tied to sha1. So if collision attacks against sha1 are found, like for md5, you're screwed. Whereas with bzr it'd be a matter of providing another hash algorithm to be used | 19:28 |
| NfNitLoop | what do you mean you can't "verify" anything unless it's signed? I just mean verify that someone who gives you version {id} is actually the same as version {id} that you have, or had in the past. | 19:28 |
| mathrick | NfNitLoop: in the repository, it's a property of the changeset | 19:29 |
| GaryvdM | NfNitLoop: It stores them in the repo with the revision properties. | 19:29 |
| NfNitLoop | aah. And that hash includes the hashes from its parents? | 19:29 |
| mathrick | yes | 19:29 |
| NfNitLoop | awesome. | 19:29 |
| NfNitLoop | Yeah, Linus's talk seemd a bit ... inaccurate in places. | 19:29 |
| GaryvdM | NfNitLoop: you will see it if you do bzr cat-revision -r x | 19:29 |
| NfNitLoop | He claimed git was the only thing to do that. | 19:29 |
| mathrick | NfNitLoop: git isn't particularly more secure than anything else | 19:30 |
| mathrick | bzr and hg do that, monotone gets even more paranoid | 19:30 |
| mathrick | darcs hashes too | 19:30 |
| mathrick | really, it's the easiest way to do it if you're making a DVCS, so I'd be surprised to see anyone else do it differenetly | 19:30 |
| GaryvdM | NfNitLoop: that talk is old. | 19:30 |
| mathrick | s/et/t/ | 19:30 |
| NfNitLoop | I thought it was given this month. | 19:31 |
| mathrick | GaryvdM: but it was just as untrue when he said that :) | 19:31 |
| GaryvdM | Yes | 19:31 |
| mathrick | NfNitLoop: if so, it must be a new one | 19:31 |
| mathrick | the google talk he gave is, dunno, 1.5 years old? | 19:31 |
| GaryvdM | NfNitLoop: was it the one at google? | 19:31 |
| NfNitLoop | yeah. | 19:31 |
| GaryvdM | May 2007 | 19:32 |
| NfNitLoop | Oh yeah. | 19:32 |
| NfNitLoop | Someone only just recently posted it to a blog I read. (HackerNews). | 19:32 |
| NfNitLoop | so it was dated this month on the blog, but yeah it's from 2007. | 19:32 |
| NfNitLoop | still, even then some of what he said didn't seem that accurate. | 19:33 |
| mathrick | NfNitLoop: Linus is a prick, to use the technical term, and it's not entirely uncommon to sacrifice accuracy to increase the emotional value of what he says | 19:33 |
| mathrick | so you need to take that into account when you read / listen to anything by him | 19:34 |
| mathrick | *uncommon for him | 19:34 |
| GaryvdM | Is he git? (excuse the pun) | 19:34 |
| GaryvdM | *Is he a git? | 19:34 |
| mathrick | you could say so :) | 19:35 |
| mathrick | personally I think it's a real pity he grew to be the face of much of the FLOSS | 19:35 |
| mathrick | because we really have people who are just as smart, and aren't unbearable, obnoxious pricks | 19:35 |
| NfNitLoop | Heh. | 19:37 |
| GaryvdM | Jelmer told me that he name git git as a tribute to Andrew Tridgell. | 19:38 |
| GaryvdM | *named | 19:38 |
| rubbs | I heard he named it after himself... but I could be hearing it wrong | 19:39 |
| rubbs | I've got to learn git for a new job... it seems that you have to use some convoluted workflows to get it to work right. | 19:40 |
| rubbs | that could just be me too. | 19:40 |
| mathrick | rubbs: nope | 19:41 |
| NfNitLoop | I played around with it a bit because a coworker really likes it. Much prefer bzr's simplicity/flexibility. | 19:42 |
| mathrick | that seems to be the essence of Linus's products. You use them the way Linus meant them to be used, or not at all | 19:42 |
| mathrick | everyone else be damned | 19:42 |
| mathrick | I don't understand why it needs to be so complicated, but it is | 19:42 |
| rubbs | I just don't care for the colocated branches or the index. | 19:43 |
| mathrick | it has some good features, like colocated branches (though they are incredibly confusing if you don't know about them) and rebase -i | 19:43 |
| mathrick | but we already have bzr-colo and rebase -i is a political issue, really | 19:44 |
| NfNitLoop | My officemate is reading http://hginit.com/ and trying to figure out why he should bother with DSCMs. | 19:44 |
| mathrick | rubbs: colocated branches are incredibly useful in certain scenarios | 19:44 |
| NfNitLoop | I'm apparently not that great at articulating it. | 19:44 |
| rubbs | NfNitLoop: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ | 19:44 |
| === deryck[lunch] is now known as deryck | ||
| rubbs | that's the article that really convinced me | 19:44 |
| mathrick | namely, when you don't want to / can't afford to reconfigure everything to use a branch in another dir | 19:44 |
| rubbs | also for Hg, but easily adapted to any DVCS | 19:45 |
| mathrick | NfNitLoop: it's not obvious at first, so it's understandable | 19:45 |
| rubbs | mathrick: oh I'm sure it's useful, and in many ways I can see why, but I don't really need to worry about it. | 19:46 |
| mathrick | NfNitLoop: you can tell him that DVCs are better because make collaboration easy in a way that's natural for humans, not in a way that's somewhat easier for your sysadmin to setup | 19:46 |
| mathrick | not to mention they're easier to setup to boot | 19:46 |
| ubuntujenkins | how do I merge lp:~ubuntu-manual/quickshot/screenshots-de into lp:~ubuntu-manual/quickshot/screenshots-ump? | 19:47 |
| mathrick | rubbs: sure, I haven't used them until recently, when I had to work on a git project, but then I actually got hooked up, because said project happens to depend on several external config files pointing to the right place, and with colocated branches I can just switch in-place to test if a bug is upstream or the result of my hacking | 19:47 |
| GaryvdM | ubuntujenkins: | 19:48 |
| GaryvdM | bzr branch lp:~ubuntu-manual/quickshot/screenshots-um | 19:48 |
| GaryvdM | If you have not allready | 19:48 |
| GaryvdM | cd screenshots-um | 19:48 |
| ubuntujenkins | yep I have the branches on my computer | 19:48 |
| mathrick | you can also say bzr merge lp:~ubuntu-manual/quickshot/screenshots-de -d lp:~ubuntu-manual/quickshot/screenshots-ump | 19:48 |
| GaryvdM | bzr merge lp:~ubuntu-manual/quickshot/screenshots-de | 19:48 |
| mathrick | but if you have them locally, then just do what GaryvdM says | 19:49 |
| GaryvdM | mathrick: you cant merge into a remote branch | 19:49 |
| mathrick | no? | 19:49 |
| NfNitLoop | mathrick: He's arguing that with merge-tracking in SVN that you can do all of this in SVN too... which I'm not quite sure how to counter. | 19:49 |
| mathrick | you should be able to | 19:49 |
| GaryvdM | ubuntujenkins: resolve conflicts | 19:49 |
| NfNitLoop | other than the fact that it "feels" more natural to create lots of branches with bzr. | 19:49 |
| ubuntujenkins | well I get the error bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 19:49 |
| GaryvdM | ubuntujenkins: commit | 19:49 |
| NfNitLoop | since it's easier, and doesn't pollute the central repo. | 19:49 |
| mathrick | NfNitLoop: except it's an afterthought for svn, and even svn devs admit it's not quite ready for production use yet | 19:50 |
| NfNitLoop | mathrick: Oh really? | 19:50 |
| mathrick | NfNitLoop: bzr is easier, faster, less buggy and produces smaller trees | 19:50 |
| GaryvdM | ubuntujenkins: ah, hold on a sec, let me have a look at the contents | 19:50 |
| NfNitLoop | mathrick: How is it not ready for production use? That's how we do merges here. | 19:50 |
| mathrick | NfNitLoop: and svn STILL doesn't give you offline commits | 19:50 |
| mathrick | NfNitLoop: it has many failure modes | 19:50 |
| NfNitLoop | mathrick: Right. He conceded that point. | 19:50 |
| GaryvdM | mathrick: merge needs a working tree, which bzr does not touch if the branch is remote | 19:51 |
| NfNitLoop | mathrick: any idea where I might find a list of those? *googles* | 19:51 |
| ubuntujenkins | thanks GaryvdM its suprising how confusing this gets | 19:51 |
| mathrick | offline commits are awesome, not because you necessarily have to be on a plane all the time, but because it really means you can start a repo absolutely anywhere, at any time | 19:51 |
| mathrick | GaryvdM: ah | 19:51 |
| mathrick | ubuntujenkins: you'll get used | 19:52 |
| mathrick | NfNitLoop: with self-contained repos, all I need to share my repo with you is email. I can literally just zip my tree and send it to you, and have done so many times | 19:52 |
| mathrick | and if I ever get on a plane or train, which I occasionally do, I can work on everything I have branched, even if I haven't planned for this | 19:53 |
| NfNitLoop | mathrick: Yep. He's already agreed that that is nice. | 19:54 |
| mathrick | and most of the time, bzr repos are still smaller than svn's checkouts :) | 19:54 |
| NfNitLoop | But he's pointed out that everyone says that DSCMs are SOOOooo much better at merging without giving concrete examples of how. | 19:54 |
| mathrick | lemme see if I can find it | 19:54 |
| NfNitLoop | and he's claiming that svn 1.5+ basically handle merging well enough now. | 19:55 |
| ubuntujenkins | basically screenshots-ump contains a folder for each language, screenshots-de contains a folder for each chapter I need to be able to merge screenshots-de into screenshots-ump/de (GaryvdM | 19:55 |
| NfNitLoop | Hell, using bzr is simpler just because it remembers parent/push branches. having to 'svn merge http://repo/path/path/to/branch/blah" is a pain in itself. :p | 19:56 |
| mathrick | NfNitLoop: btw, I don't know if what I said about hashes and tamper-proofness is true for svn. It's not a DVCs, so it might very well not have that built-in | 19:56 |
| mathrick | NfNitLoop: yeah, that is a good point | 19:56 |
| GaryvdM | ubuntujenkins: will you need to merge one lanuage in to another? | 19:56 |
| mathrick | http://portal.acm.org/citation.cfm?id=1572196&dl=GUIDE&coll=GUIDE&CFID=77717344&CFTOKEN=95162572 <-- heh | 19:57 |
| GaryvdM | ubuntujenkins: to do what you asked, you need to do: | 19:58 |
| ubuntujenkins | Garyvdm I will have another branch for each language. The idea is they are collated into one giant branch with a folder for each language. | 19:58 |
| GaryvdM | The one big branch is where you want to end up? | 19:59 |
| NfNitLoop | mathrick: Oh I'm sure it doesn't for svn. | 19:59 |
| GaryvdM | ubuntujenkins: to do what you asked, you need to do: | 20:00 |
| GaryvdM | screenshots-ump/ $ bzr merge screenshots-de -r 0..-1 | 20:00 |
| GaryvdM | screenshots-ump/ $ bzr mv screenshots-de screenshots-ump/de | 20:00 |
| GaryvdM | and commit | 20:00 |
| mathrick | NfNitLoop: another thing is that svn doesn't really look at the whole tree, only at the changed files. So you can actually get unbuildable trees from two tested patches, even though the commits are supposed to be atomic | 20:00 |
| ubuntujenkins | GaryvdM thanks I will give it a go | 20:00 |
| mathrick | NfNitLoop: that can get very tricky, particularly when you do more extensive merges | 20:00 |
| GaryvdM | ubuntujenkins: and after you have done that, look at bzr qlog, which will give you a better understanding of what you have done. | 20:01 |
| mathrick | NfNitLoop: and SVN still doesn't let you commit if you don't have commit access to the repo, which might, or might not be a problem for you in particular. But in general making people unable to version they changes just because they're not blessed is stupid and will eventually come to bite you when you don't expect it | 20:03 |
| mathrick | because you brough someone from another team to look at some particular problem, or whatever | 20:03 |
| NfNitLoop | *nod* being able to commit a change and then share it regardless of central repo permissions is quite nice. | 20:08 |
| NfNitLoop | but in the corporate world not exactly desired. | 20:08 |
| NfNitLoop | (shhhh). ;) | 20:08 |
| NfNitLoop | http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync | 20:08 |
| mathrick | it's mostly a strawman, because it doesn't influence the central repo in any way | 20:09 |
| NfNitLoop | So I found the --reintegrate option there and pointed the coworker at it. | 20:09 |
| mathrick | you just get to collaborate the same way you can speak to each other without going through your manager | 20:09 |
| NfNitLoop | apparently you have to tell SVN which *direction* your merging, and after reintegrating w/ trunk your feature branch can't be merged anymore. | 20:09 |
| NfNitLoop | that's basically a deal breaker for me, at least. | 20:09 |
| NfNitLoop | you're* | 20:10 |
| GaryvdM | NfNitLoop: With bzr, you also give merge a direction. | 20:10 |
| NfNitLoop | eh? | 20:11 |
| GaryvdM | But the not being able to remerge in svn does suck | 20:11 |
| NfNitLoop | you just say: bzr merge source [dest] | 20:11 |
| NfNitLoop | but in SVn you have to specify --reintegrate if [dest] is trunk, from which source had been branched. | 20:12 |
| GaryvdM | dest$ bzr merge source | 20:12 |
| NfNitLoop | whereas bzr figures it out. | 20:12 |
| NfNitLoop | and any other sane DSCM. | 20:12 |
| mathrick | NfNitLoop: oh man, this is cumbersome as hell | 20:12 |
| mathrick | bzr just keeps track of all that for you | 20:13 |
| mathrick | so the whole thing is down to one command: bzr push | 20:13 |
| NfNitLoop | yup. | 20:15 |
| mathrick | "In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again." <-- seriously? | 20:15 |
| mathrick | that's stupid | 20:15 |
| mathrick | so there you have it | 20:15 |
| mathrick | you *still* can't merge properly | 20:15 |
| fullermd | Wow. That's special. | 20:15 |
| mathrick | it's slightly less retarded now | 20:15 |
| mathrick | NfNitLoop: so tell your coworker that this kills the most common use for branches: branching out releases and fixing bugs on them while keeping the development in trunk without giving up the bugfixes | 20:17 |
| mathrick | you normally do it by cd release-1.0; hack hack hack; bzr commit; bzr push | 20:17 |
| mathrick | and presto, trunk has the same fix now | 20:17 |
| mathrick | I can't see how you could possibly do that with the broken svn model | 20:18 |
| GaryvdM | ubuntujenkins: were you successful? | 20:21 |
| ubuntujenkins | GaryvdM yes and no still working on it | 20:21 |
| ubuntujenkins | GaryvdM I have achived what I wanted to, bzr mv didn't work but I found a way to do thanks for your help | 20:33 |
| GaryvdM | Good | 20:33 |
| GaryvdM | ubuntujenkins: did you look at qlog? | 20:34 |
| ubuntujenkins | erm should it be in .bzr? I think I did something wrong as I have no .bzr | 20:37 |
| ubuntujenkins | o I do have .bzr | 20:38 |
| GaryvdM | ubuntujenkins: run it in the branch that you did the merge in | 20:38 |
| GaryvdM | screenshots-ump/ $ bzr qlog | 20:38 |
| ubuntujenkins | bzr: ERROR: unknown command "qlog" is what I get I have a bad felling :-( | 20:39 |
| GaryvdM | sudo apt-get install qbzr | 20:39 |
| GaryvdM | ubuntujenkins: ^ to install it | 20:39 |
| ubuntujenkins | just installing it now. | 20:40 |
| ubuntujenkins | wow thats a shiny way of showing the changes :) | 20:43 |
| ubuntujenkins | I shall set up another branch and give it ago agian thanks GaryvdM | 20:44 |
| GaryvdM | :-) Hopefully it will help you to understand things better | 20:44 |
| NfNitLoop | (whoops, was afk for a bit) | 20:55 |
| NfNitLoop | mathrick: actually, I'm pretty sure you couldn't do 'cd release-1.0; hack; bzr commit; bzr commit | 20:55 |
| NfNitLoop | er, bzr push | 20:56 |
| NfNitLoop | the trunk would have diverged by then, and a push would complain. | 20:56 |
| NfNitLoop | you'd have to do a merge into trunk. | 20:56 |
| NfNitLoop | but yeah, being able to have long-lasting branches that don't break when you do a reintegrate is a good thing. :p | 20:56 |
| alex-weej | halp! i installed bzr fastimport from launchpad with: "python setup.py install" and it worked, but when i run bzr fastimport or bzr fast-import it whinges about it being an unknown command | 20:57 |
| NfNitLoop | alex-weej: it may have installed under a different Python version's package lib. | 20:59 |
| NfNitLoop | is bzr using the same version of python that 'python setup.py install' used? | 20:59 |
| NfNitLoop | (try python -v ; bzr version) | 21:00 |
| alex-weej | i haven't configured it otherwise -- everything is stock ubuntu 9.10 | 21:00 |
| alex-weej | 264, on both | 21:00 |
| mathrick | hmm, is there an env variable to tell bzr not to warn about dumb terminals? | 21:01 |
| alex-weej | does bzr have a cache of commands or something? | 21:01 |
| GaryvdM | alex-weej: no, it get's them from the plugins each time it runs | 21:02 |
| alex-weej | damn this is blocking my work -- anyone have any working way of converting a git repo to a bzr one? | 21:02 |
| GaryvdM | alex-weej: bzr-git? | 21:02 |
| alex-weej | that can do migration? | 21:03 |
| GaryvdM | Yes, you can even push back to git later. | 21:03 |
| rioch | I've committed a change but not pushed it, but since then made some more changes. If I undo the commit, will I lose my changes? I want to recommit everything under the one change. | 21:06 |
| GaryvdM | rioch: That will work. | 21:07 |
| GaryvdM | rioch: Just *do not* revert after you uncommit. | 21:08 |
| tasslehoff | Hey. I've tried bzr for the first time today, after git-on-windows frustrations. I followed the git-svn example in the docs to checkout trunk and create a work branch. <hack-commit-hack-commit>, then merge changes from work to trunk. In the merge, is it possible to make bzr do the same commits to trunk that I did to work, instead of doing one big commit? | 21:08 |
| rioch | I will uncommit, and then commit again, that right? | 21:08 |
| tasslehoff | hmm. did anyone understand that? :) | 21:08 |
| GaryvdM | rioch: Yes | 21:08 |
| rioch | thanks | 21:08 |
| GaryvdM | tasslehoff: Yes. do bzr push <svn location> | 21:09 |
| alex-weej | ok this is really f***ed up, i just installed bzr-git and now i get bzr git | 21:10 |
| alex-weej | bzr: ERROR: unknown command "git" | 21:10 |
| alex-weej | why is bzr doing this to me!? :( | 21:10 |
| GaryvdM | alex-weej: There is no bzr git command, but,,, | 21:10 |
| tasslehoff | GaryvdM: great. this will work if I followed "A Simple Example" from http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/svn_plugin.html? | 21:11 |
| GaryvdM | alex-weej: with bzr-git, you can do bzr branch <url to git branch> | 21:11 |
| alex-weej | if it's a local file, how does it know it's git | 21:11 |
| GaryvdM | alex-weej: Not sure. | 21:11 |
| GaryvdM | I think it looks for a .git folder. | 21:12 |
| alex-weej | dulwich has something to do with git i guess | 21:12 |
| alex-weej | alex@whoosh:~/Desktop/XPRESbzr$ bzr branch /home/alex/Work/Geo-Net/XPRES/Code | 21:12 |
| alex-weej | bzr: ERROR: dulwich.errors.ChecksumMismatch: Checksum mismatch: Expected 6378e115d5922cf04385f515f5b3627b61971843, got 54524545000051b6002d3120340a736861726500 | 21:12 |
| GaryvdM | alex-weej: Yes, dulwich is a library that bzr-git uses | 21:12 |
| alex-weej | ok so it knows it's a git repo, it's just bailing for some reason :( | 21:13 |
| GaryvdM | jelmer: Any ideas ^ | 21:13 |
| === salgado is now known as salgado-afk | ||
| GaryvdM | tasslehoff: Do bzr log/bzr qlog. If you do bzr push, What you see in log will end up in svn. | 21:16 |
| tasslehoff | GaryvdM: thanks. | 21:16 |
| GaryvdM | tasslehoff: Provided what you have has not diverge from the svn branch | 21:16 |
| GaryvdM | alex-weej: that error suggests that the branch is corrupt | 21:17 |
| alex-weej | git seems to still work OK with it with no warnings | 21:17 |
| * alex-weej is just pushing git to svn and branching the svn repo instead | 21:18 | |
| GaryvdM | alex-weej: I'm not sure then | 21:18 |
| tasslehoff | GaryvdM: ok. | 21:18 |
| guilhembi | jam: hello! I have a 425MB file in my shared repo, "repository/uploads/something.reconcile" (I ran "bzr reconcile" yesterday), can I remove it? | 21:25 |
| alex-weej | if i have a branch already in "mybranch" can i just create a folder, bzr init-repo, and copy "mybranch" in as-is? | 21:35 |
| alex-weej | actually that defeats the purpose | 21:35 |
| alex-weej | how do i do this properly ;) | 21:35 |
| GaryvdM | alex-weej: after you move the branch, do bzr reconfigure --use-shared | 21:36 |
| GaryvdM | in the branch | 21:37 |
| GaryvdM | Or | 21:37 |
| GaryvdM | bzr branch in the shared repo, then remove the old branch. | 21:37 |
| alex-weej | GaryvdM, reconfigure worked fine, thanks | 21:57 |
| jam | guilhembi: yes | 22:02 |
| jam | it is a temporary pack file for the reconcile work | 22:02 |
| guilhembi | jam: thanks! | 22:02 |
| jam | 'upload' is a staging area | 22:02 |
| jam | so if nothing is actually writing to the repo, the files there are trash | 22:02 |
| guilhembi | ok | 22:03 |
| jam | i'm surprised it was left behind without us cleaning it up | 22:03 |
| jam | was there an error while running reconcile? | 22:03 |
| guilhembi | the command did return "0", no error. | 22:03 |
| guilhembi | Tomorrow I'll set up a "check -v" job, to verify the state of the repo. | 22:05 |
| guilhembi | jam: thanks again. Off to bed. | 22:05 |
| jam | sleep well | 22:06 |
| x_dimitri | I've just done a qdiff on over 50 files. It displays the diff for each file in turn. How do I terminate the entire process without having to go through all the files? | 22:22 |
| GaryvdM | crtl-c | 22:23 |
| x_dimitri | that doesn't work | 22:23 |
| x_dimitri | in fact, I've cloed the terminal from which I ran the command | 22:23 |
| x_dimitri | ...closed the terminal... | 22:24 |
| x_dimitri | the qdiff gui keeps popping up for each file | 22:24 |
| GaryvdM | Oh - qdiff | 22:24 |
| GaryvdM | did you do a command line gobbing? | 22:25 |
| poolfool | Is there a C interface into bzrlib? | 22:25 |
| x_dimitri | got it. I used ps to find it's parent process and killed that | 22:25 |
| GaryvdM | i.e. bzr qdiff foo*? | 22:25 |
| x_dimitri | GaryvdM: nope, I actualyl ran bzr qlog, then did a diff from the qlog gui | 22:25 |
| GaryvdM | x_dimitri: Thats odd. | 22:26 |
| x_dimitri | how so? | 22:26 |
| GaryvdM | I don't know why its doing that | 22:26 |
| GaryvdM | x_dimitri: Could you describe the steps to reproduce that? | 22:27 |
| x_dimitri | ok, l'll give it a try | 22:27 |
| x_dimitri | commit a couple of new files, perhaps 100 :-) | 22:28 |
| x_dimitri | do "bzr qlog" | 22:28 |
| x_dimitri | in teh qlog gui, double-click on the line that records the commit | 22:29 |
| GaryvdM | x_dimitri: I get one window for all the files. | 22:29 |
| x_dimitri | hmm... | 22:29 |
| x_dimitri | thats' different... | 22:30 |
| x_dimitri | let me have a look again | 22:30 |
| GaryvdM | x_dimitri: are you maybe using --using meld or something else? | 22:30 |
| x_dimitri | yes | 22:31 |
| x_dimitri | I'm using meld | 22:31 |
| GaryvdM | Ah ok. I know about that, I hope to fix soon. | 22:31 |
| GaryvdM | The built in diff will open one window. | 22:32 |
| x_dimitri | yup, you're right. Using the builtin diff shows all in one window | 22:32 |
| x_dimitri | well, at least I know how to stop the 'infinite' windows when using meld | 22:33 |
| GaryvdM | Night all | 22:59 |
| jam | abentley: reply to the list. But basically they have a 300+ MB .sql.gz and a 180MB .sql.gz | 23:14 |
| jam | and it is in --rich-root-pack and not --2a | 23:14 |
| jam | anyway, I'm off for now. | 23:15 |
| jam | But if they remove those files completely, their repo goes from 570MB to ~30MB, etc. | 23:15 |
| jasonlife | if I follow the centralized workflow, what is the good way to handle central repo? After I clone from the central repo and fix a bug in a branch of my local repo, do I have to push the branch to central repo? | 23:21 |
| GungaDin | Hi | 23:24 |
| GungaDin | I have one branch which is a checkout of a remote branch... is it possible to reflect changes in the remote branch without committing them, in the other branch? | 23:25 |
| NfNitLoop | Huh? | 23:26 |
| NfNitLoop | You want to commit directly to the remote branch, but not locally? | 23:26 |
| spiv | GungaDin: what do you mean by "changes in the remote branch"? | 23:27 |
| GungaDin | I want the checkout to reflect the remote branch without having to commit all the time and updating in the checkout. | 23:28 |
| spiv | Oh ok. It sounds like you don't want to use a checkout at all. | 23:28 |
| poolie | jasonlife, typically you will have a checkout of your central trunk | 23:28 |
| spiv | You just want an ordinary branch that you can do "bzr pull" in. | 23:28 |
| poolie | merge your feature changes into that, and commit | 23:28 |
| poolie | and then everyone will see them | 23:29 |
| jasonlife | poolie: Is it normal create branch in central repo? For example, my software periodically release new version.. Do I have create new branch for each version on central repo? | 23:37 |
| jasonlife | Do I have to | 23:38 |
| poolie | jasonlife, it depends on whether you do bugfix updates to those releases | 23:43 |
| poolie | but yes, it's probably a good idea to make a new central branch for each release | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!