| spiv | Good morning | 00:56 |
|---|---|---|
| spiv | news_merge should be active on PQM now | 00:57 |
| poolie | hiya spiv | 01:12 |
| poolie | yay! | 01:12 |
| poolie | mkanat: hi? | 02:07 |
| mkanat | poolie: Howdy! | 02:07 |
| poolie | hi there | 02:07 |
| poolie | are you free to work on some loggerhead bugs now? or perhaps already doing so? | 02:07 |
| mkanat | poolie: Yeah, I could do some. :-) | 02:08 |
| mkanat | poolie: Not at this exact second, but probably today or tomorrow. | 02:08 |
| poolie | ok | 02:12 |
| poolie | i was just reminded by seeing a notice of another hang the other day | 02:12 |
| poolie | wbn to either get to the bottom of it, or go to a multiprocess thing | 02:12 |
| poolie | or both | 02:12 |
| mkanat | poolie: Yeah, for sure. | 02:13 |
| mkanat | poolie: The multiprocess thing is a big project, though. | 02:13 |
| poolie | well, actually fixing things is more satisfying | 02:17 |
| mkanat | poolie: Absolutely! | 02:17 |
| mkanat | poolie: I've done so many small, focused hang fixes that would all have been obsoleted if we just had a better architecture. | 02:17 |
| poolie | hm | 02:18 |
| mkanat | poolie: Except for one deadlock, the hangs that I've fixed haven't really been hangs--they've just been the system getting overloaded. | 02:18 |
| poolie | i wonder if someone else could work with you on changing the process architecture | 02:18 |
| poolie | hm | 02:18 |
| mkanat | poolie: Ultimately I suspect it's something that would be most efficiently done by one developer. | 02:18 |
| poolie | perhaps | 02:18 |
| mkanat | poolie: The codebase isn't so large that it would have to be a team effort, I think. | 02:19 |
| poolie | it would be nice to at least get review of it by someone else | 02:19 |
| mkanat | poolie: I'm not saying that that one developer has to be me. | 02:19 |
| mkanat | poolie: Oh, absolutely. | 02:19 |
| mkanat | poolie: One reviewer and one developer would probably be a good match. | 02:19 |
| poolie | mkanat: ok, let's do it | 02:46 |
| mkanat | poolie: Sweet! | 02:46 |
| mkanat | poolie: I'll start feasibility studies probably today or tomorrow. | 02:46 |
| poolie | if possible keep it isolated in wsgi stuff as much as is sensible so we can switch that layer later | 02:46 |
| poolie | and let's think about supportability/traceability stuff | 02:46 |
| poolie | like keeping oops reporting, perhaps something to show where time is spent | 02:47 |
| poolie | but mostly, see if you can get the basic switch done | 02:47 |
| poolie | have fun | 02:47 |
| poolie | don't go silent | 02:47 |
| mkanat | poolie: Okay. :-) | 02:47 |
| mkanat | poolie: Because we're switching from a threading model to a process model, though, there will be a lot of stuff that isn't in the WSGI layer. | 02:48 |
| mkanat | poolie: Since we will be removing locks, and we can't share variables anymore. | 02:48 |
| poolie | ok | 02:48 |
| poolie | perhaps you could explain this in a mail rather than to me | 02:48 |
| poolie | probably we should talk about that in mail | 02:48 |
| mkanat | poolie: Okay. I will as soon as I get further into finding out what's actually require.d | 02:51 |
| mkanat | *required | 02:51 |
| jbowtie | I'm thinking of wrapping the docstrings in builtins.py in gettext calls in order to enable translation of at least the help text. Am I overlooking anything obvious? | 03:20 |
| jbowtie | It should work for class docstrings; would have to be more complicated if we used method docstrings in the help output. | 03:21 |
| lifeless | performance | 03:25 |
| lifeless | it depends on what you mean | 03:27 |
| lifeless | if you mean 'pass the help text to gettext when rendering help' - that should be fine. | 03:27 |
| jbowtie | lifeless: well you still need to mark the strings for translation. | 03:28 |
| lifeless | why? | 03:28 |
| jbowtie | lifeless: So that they end up in the POT file? | 03:29 |
| lifeless | there are other ways of doing that | 03:29 |
| lifeless | we know all things to translate via introspection | 03:29 |
| lifeless | jbowtie: _() will run afunction for every string at load time for the system, its a terrible overhead | 03:30 |
| jbowtie | I'd be happy to know what those are, all the programs I translate use gettext. | 03:30 |
| lifeless | jbowtie: for command in commands: text = command.help(); line = command.run._im_co.__line__ ... | 03:31 |
| * lifeless is handwaving | 03:31 | |
| lifeless | jbowtie: in C _() is free because the code is not executed unless you go down the code path; thats not the case for python. | 03:32 |
| lifeless | static attributes are executed at module time. | 03:32 |
| jbowtie | lifeless: Well then maybe we shouldn't be using docstrings for documentation? | 03:32 |
| jbowtie | I'm just concerned that currently I can't translate bazaar via Launchpad. | 03:33 |
| lifeless | jbowtie: why not? they are designed for it | 03:33 |
| lifeless | jbowtie: so, definitely doable; some glue needed. | 03:33 |
| jbowtie | Handwoven glue that will need to be run every time a docstring changes? | 03:34 |
| jbowtie | I'm just dubious, everything ends up getting patched to gettext eventually, or programs end up not getting translated. | 03:35 |
| spiv | Well, like whatever bit of gettext that extracts _() syntax into POT files needs to be re-run when those strings change. | 03:35 |
| spiv | It's just that rather than having a "extract _() calls in source into list of translatable strings" step, we'd have "run $handwave that has no runtime penalty in Python" step. | 03:36 |
| mkanat | lifeless: Is Launchpad using a multi-threaded or multi-process server, right now? | 03:38 |
| lifeless | mkanat: multi threaded | 03:38 |
| spiv | We could even look at automating that step, e.g. PQM updating the set of strings to translate in Launchpad after every merge. | 03:38 |
| mkanat | lifeless: Okay. Have you guys done any investigation on moving to multi-process, or are you scaling OK with multi-threaded? I'm starting to investigate possibilities for loggerhead. | 03:39 |
| lifeless | mkanat: we have 12 or so machines running lp itself | 03:40 |
| jbowtie | All right, I'll go look at the source for xgettext for a while. | 03:40 |
| lifeless | mkanat: I have concerns about performance with threads and am investigating single-threaded instances (one request at a time) - because we already have a solid layer 7 proxy handing stuff to the backends | 03:41 |
| lifeless | we could point that at loggerhead very easily | 03:41 |
| lifeless | mkanat: e.g. tell paste to use 1 thread only and run up 4 loggerhead instances | 03:41 |
| lifeless | mkanat: no need, in such an approach, for any multi-process glue. | 03:41 |
| lifeless | mkanat: I have a bias against multi process wsgi; U1 tried that had it was a fairly bad experience for them. | 03:42 |
| mkanat | lifeless: So I've heard, but I didn't really get any details on what the trouble was. | 03:42 |
| lifeless | me neither | 03:42 |
| lifeless | anyhow the big thing for me is that we already have a multi-process multiplexing system | 03:43 |
| lifeless | we don't need two. | 03:43 |
| lifeless | for the launchpad deployment of loggerhead, that is. | 03:43 |
| mkanat | lifeless: Hmm. | 03:43 |
| lifeless | the simplest way to get one process per request is to drop the thread count to 1 and tell ha proxy to send to 4 instances (or however many we decide to use) | 03:43 |
| mkanat | lifeless: That certainly would be less work. | 03:44 |
| mkanat | lifeless: Although that doesn't get us process management. | 03:44 |
| lifeless | mkanat: what does 'process management' mean | 03:44 |
| mkanat | lifeless: Well, say, the ability to tell when a process is hung and kill it, and then spawn another process. | 03:45 |
| mkanat | lifeless: It's something that could be done with sysadmin work. | 03:45 |
| mkanat | lifeless: But it's nicer to just have it in the app. | 03:45 |
| lifeless | ah, 'spawning' was the name of the thing that gave u1 grief, IIRC | 03:45 |
| mkanat | lifeless: Right, that's the only major multi-process WSGI server. | 03:45 |
| mkanat | lifeless: But it's been years since U1 used that, and there have been a lot of Spawning releases since then; it's a very active project. | 03:45 |
| lifeless | long term I'd like to be able to share the bazaar.launchpad.net load with the rest of the servers; with safeguards for rogue stuff | 03:46 |
| lifeless | but thats -long- term, we're nowhere near ready for that | 03:46 |
| mkanat | lifeless: You mean make loggerhead part of the normal server pool? | 03:47 |
| lifeless | mkanat: anytihng that makes it easier to switch between paste, paste-w/1-thread, spawning, and in-lpnet-appservers is a good investment | 03:47 |
| lifeless | mkanat: yes, just another wsgi site in the app | 03:47 |
| lifeless | in the middle tier | 03:48 |
| mkanat | lifeless: Okay. | 03:48 |
| mkanat | lifeless: Who would I ask about what the U1 problems were with Spawning? | 03:48 |
| lifeless | what tz are you in? | 03:48 |
| mkanat | lifeless: Pacific | 03:49 |
| mkanat | America/Los_Angeles | 03:49 |
| lifeless | statik: would be a good entry point | 03:49 |
| lifeless | he's not leading the team anymore but he'll know who was involved | 03:49 |
| mkanat | lifeless: Great, thanks. :-) | 03:49 |
| mkanat | lifeless: So from your viewpoint on the Launchpad technical side, what you'd like to see from loggerhead is a framework that makes it easier to fit it into whatever WSGI configuration you want to use. | 03:50 |
| lifeless | I think that that would be a wise thing to work on | 03:52 |
| lifeless | I think fixing the hangs is important too, because a hang is a user not getting a response. | 03:53 |
| mkanat | lifeless: The hangs are a scaling problem. | 03:53 |
| mkanat | lifeless: Or a deadlock problem. | 03:53 |
| lifeless | and I think fixing the performance is also important | 03:53 |
| mkanat | lifeless: Both of which are fixed by having multiple processes. | 03:53 |
| lifeless | mkanat: deadlocking on what? | 03:53 |
| mkanat | lifeless: Depends. | 03:53 |
| mkanat | lifeless: Last deadlock I fixed (it was several months ago) as I recall was in cache access. | 03:53 |
| lifeless | so, bzr serve itself is threaded. | 03:54 |
| mkanat | lifeless: I'm just saying in general that the hangs are either a performance problem or a deadlock problem. | 03:54 |
| lifeless | mkanat: so by perf problem you mean 'not a hang, just slow' ? | 03:54 |
| mkanat | lifeless: I mean either, really. | 03:54 |
| mkanat | lifeless: Oh, yes, I see what you mean. Yes. | 03:54 |
| mkanat | lifeless: It's so slow that it might as well have hung. | 03:55 |
| lifeless | ok | 03:55 |
| lifeless | and the actual hangs are generally deadlocks | 03:55 |
| mkanat | lifeless: Well, there generally aren't actual hangs. | 03:55 |
| mkanat | lifeless: I fixed one deadlock. | 03:55 |
| mkanat | lifeless: Also, bzr itself is not thread-safe. | 03:55 |
| lifeless | so | 03:55 |
| lifeless | bzr needs to be threadsafe | 03:56 |
| lifeless | or move to aprocess model for 'bzr serve', itself. | 03:56 |
| mkanat | lifeless: That seemed like a pretty low priority, making all of it thread-safe to the degree that loggerhead would need. | 03:56 |
| lifeless | mkanat: the thing is that we support 'bzr serve' so if loggerhead has an issue with bzr thread safety, so does bzr. | 03:56 |
| mkanat | lifeless: Nobody runs a persistent bzr serve. | 03:57 |
| lifeless | mkanat: yes, they do :) We get discussion from time to time. | 03:57 |
| lifeless | mkanat: even if they don't, while we claim it as a supported feature... | 03:57 |
| lifeless | mkanat: I'm not saying you shouldn't change loggerhead models | 03:57 |
| lifeless | I'm just saying that poolie has a strong desire and incentive to have the core be solid and robust | 03:58 |
| mkanat | lifeless: Okay. | 04:02 |
| === timchen119 is now known as nasloc__ | ||
| mkanat | lifeless: I didn't get the impression that global thread-safety across all of bzr was going to happen within the next few years. | 04:11 |
| mkanat | lifeless: And even if you make "bzr serve" thread-safe, that doesn't make loggerhead thread-safe. bzr serve doesn't need to run the annotate code, for example. | 04:12 |
| mkanat | At least, as far as I understand things. | 04:12 |
| lifeless | mkanat: I'm not aware of many if any remaining unsafe things | 04:14 |
| lifeless | mkanat: I think the right thing to do is ask poolie | 04:14 |
| mkanat | lifeless: Okay. In any case, I don't think that multi-threaded server is a good future for loggerhead (or for any Python web app). | 04:16 |
| mkanat | lifeless: I think that either your 1-thread solution or Spawning is probably a good way forward. | 04:16 |
| lifeless | mkanat: sounds reasonable to me; for spawning I'd really want to know we're going to be able to jump on it when it dies. | 04:16 |
| mkanat | lifeless: Dies as a project, or...? | 04:17 |
| lifeless | one problem with spawning is that if the parent process has any threads, fork() becomes (sadly) dangerous | 04:17 |
| lifeless | mkanat: the server | 04:17 |
| mkanat | lifeless: Okay. So the parent just has to be single-threaded. | 04:17 |
| lifeless | mkanat: yeah, which can be hard to enfoce. | 04:17 |
| mkanat | lifeless: Well, but I have complete control over the entire application, so it shouldn't be too much of a problem. | 04:19 |
| AfC | We run persistent bzr serve :) | 04:20 |
| mkanat | AfC: Okay. :-) Under a high load? | 04:23 |
| AfC | mkanat: no, not really | 04:23 |
| mkanat | Yeah. I think loggerhead is the only high-load multi-threaded application that interacts with bzr. | 04:24 |
| === Ursinha is now known as Ursinha-zzz | ||
| * poolie reappears | 04:52 | |
| poolie | lifeless: as i said to mkanat when i started, i don't think mpm vs internal fixes are either or | 04:53 |
| poolie | except in the sense that you choose one of them to work on at any particular moment | 04:53 |
| lifeless | yeah | 04:54 |
| lifeless | makes sense to me | 04:54 |
| poolie | having spent X amount of timing doing fixes within a single-process multithread model | 04:55 |
| poolie | perhaps we should now alternate | 04:55 |
| mkanat | That makes sense. | 04:56 |
| poolie | that pyutil patch looks nice, spiv | 06:12 |
| poolie | i haven't read it closely yet | 06:12 |
| spiv | Oh good :) | 06:13 |
| spiv | I was starting to wonder if it was too much of a yak shave, but the repetition of a bug-prone idiom was really grating. | 06:14 |
| poolie | ok | 06:14 |
| lifeless | spiv: thank you | 06:14 |
| poolie | i'm going to try to interactively test my launchpad dkim/gpg fixes branch | 06:15 |
| poolie | then go back to stale lock detection | 06:15 |
| poolie | ubuntu mounted (using LABEL=) my snapshot of home, not the real home | 06:15 |
| poolie | which made things a bit interesting | 06:15 |
| poolie | thus my sudden disappearance | 06:15 |
| spiv | Getting an interactive test environment running for that sounds a bit intimidating. | 06:15 |
| spiv | Heh, tricky! | 06:15 |
| poolie | mm it might be | 06:15 |
| poolie | wgrant pointed me to doc/mailbox.txt | 06:16 |
| poolie | which might be a good way to test it | 06:16 |
| poolie | we'll see | 06:16 |
| poolie | in theory i can tell it to just pull mails from a directory, or get a test to run from a canned mail | 06:16 |
| spiv | *nod* | 06:16 |
| spm | istr there's a bzr/gnome plugin that will update a desktop flag/alert that there are/aren't branches updated? Does that tool or one like it 1. access codehost bzr+ssh; 2. on a regular schedule? or more randomised? 3. thundering herd? ie all checks at once, vs randomly spread over the given period? | 07:07 |
| spm | Or possibly something else. But evil is happening. https://lpstats.canonical.com/graphs/CrowberryLoadAverage/20100921/20100922/ | 07:08 |
| spm | it seems to be the same bunch of branches too; fwiw. | 07:08 |
| spiv | Wow, interesting. | 07:09 |
| poolie | is that maybe vila's bzr-gardener? | 07:11 |
| vila | hi all | 07:24 |
| vila | hmm, me ? | 07:25 |
| poolie | no, not you | 07:25 |
| poolie | hi vila | 07:25 |
| vila | let see, I have ~350 branches I think, and it takes a while to query them all | 07:26 |
| vila | wow, *something* is happening indeed :) | 07:26 |
| spm | vila: yeah, not you :-) | 07:26 |
| vila | regarding bzr-gardener, it's not optimized at all so far, but should *reduce* the load on the server ultimately by doing *less* queries | 07:27 |
| vila | spm: so roughly the load has doubled right ? | 07:28 |
| spm | vila: yeah | 07:28 |
| vila | spm: was there an update around this point ? lp or bzr / | 07:28 |
| vila | ? | 07:28 |
| vila | crowberry == code.lp.net right ? | 07:29 |
| spm | yup | 07:29 |
| spm | and no, no code update | 07:29 |
| spm | I think. checking... | 07:29 |
| spm | no. not since the release. | 07:30 |
| poolie | thanks for feeding my patches up spiv | 08:06 |
| poolie | the break-lock may fail pqm, i forget | 08:07 |
| spiv | That's ok, I'm curious to see what the failures are if there are any, and also I figure it might give news_merge a chance to show if it's working. | 08:07 |
| spiv | Although maybe those merges cause a bunch of NEWS entries to appear under 2.3b1 that will need to be moved to 2.3b2... | 08:08 |
| spiv | (not so much due to news_merge as due to letting branches sit unmerged for so long) | 08:08 |
| poolie | ah it was a conflict, but not in news | 08:09 |
| poolie | but it should be good now | 08:10 |
| vila | spiv: yeah, that's why I gave the warning to the Patch Pilot, may be you missed it ? | 08:11 |
| spiv | vila: apparently! | 08:14 |
| spiv | It's not a big deal to fix them up just after they land. | 08:14 |
| spiv | And easier than fixing them up before, thanks to the way LP reviews work :/ | 08:14 |
| vila | yeah.. we still need to fix the root problem but until then a single patch to fix the NEWS entries wfm | 08:16 |
| spiv | An option for news_merge to force new entries to be put in the latest release seems good, except for the times when you want to change older releases (merge from 2.x -> 2.x+1, or fixing typos, etc) | 08:17 |
| vila | spiv: I see "Simplify connect_ssh/sftp error" in the pqm queue, great, I was about to report that babune repeatedly fail in test_bad_connection_ssh so if something is still wrong after your patch we hopefully know it soon | 08:18 |
| vila | spiv: or allow a "floating" release so that you can insert the entries either in bzr-2.2.1 or bzr-next | 08:19 |
| vila | or bzr-dev whatever | 08:19 |
| spiv | vila: yeah, I'm still not 100% comfortable with it, but after sleeping on it I think the best way to get comfortable is to get it in trunk and battle-tested. | 08:19 |
| vila | spiv: I've run it across all platforms with success as mentioned in the mp, it's better than the actual (and faulty) access to e.errno | 08:20 |
| spiv | vila: or provide a way to override the always-add-to-newest behaviour per landing... | 08:20 |
| spiv | Yeah, I think it's ok, I'm just still bugged by the fact that I don't understand the intent of the old code. Probably that's because the old code was wrong :) | 08:21 |
| vila | bzr-next *is* always-add-to-newest, if you don't use it... you don't use it :) | 08:21 |
| spiv | Sure. | 08:22 |
| vila | spiv: it could be that the old code was relying on a bug in the test code... | 08:22 |
| spiv | Heh. | 08:22 |
| vila | the comment can be read as: "We are time dependent here, let's catch it" | 08:23 |
| vila | or rather | 08:24 |
| vila | it may have been inspired by a time dependent behaviour | 08:24 |
| spiv | Yeah, that's true. | 08:33 |
| vila | poolie: I'm a bit stuck on the SRU process, bug #528041 seems to imply that I need to propose a branch (and lifeless mentioned disjoint history :-/) plus pitti replied with: "please upload" | 08:44 |
| ubot5` | Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 145)" [Undecided,Confirmed] https://launchpad.net/bugs/528041 | 08:44 |
| vila | poolie: both of which are close to chinese to me :-( | 08:45 |
| vila | for the former I mean that building the same kind of branch as lifeless did is | 08:45 |
| lifeless | vila: ? | 08:54 |
| bialix | spiv: why not approving the patch for 2.0 as well? | 08:56 |
| vila | lifeless: I'm lost in the dependencies between the branch you created there, the bzr stable branches and the bzr packaging branches | 08:56 |
| vila | lifeless: oh, and I forgot the debian branches | 08:57 |
| lifeless | vila: oh; sorry ;P | 09:00 |
| bialix | bonjour vila! | 09:01 |
| vila | bialix: _0/ | 09:01 |
| === spike_ is now known as spikeWRK | ||
| bialix | never seen before this acronym: aTdHvAaNnKcSe | 09:02 |
| fullermd | 's not an acryonym, just a visual joke. | 09:02 |
| * bialix thinks vila had too big head today | 09:02 | |
| vila | bialix: hehe, easier to decode with the caps :) | 09:02 |
| vila | bialix: _./ | 09:02 |
| bialix | rotfl | 09:02 |
| bialix | \o_ | 09:03 |
| fullermd | \o/ ^o^ /o_ /o\ | 09:04 |
| bialix | a gull? | 09:04 |
| fullermd | (it's fun to stay at the...) | 09:04 |
| vila | poolie: and on the overall releases, it seems that many things depends on the debian branches being updated, yet, I'm still unclear about which releases debian really cares about (my best guess so far is 2.1/2.2/2.3 though I think they carry only two of them :) | 09:05 |
| poolie | vila: packages.debian.org/bzr | 09:05 |
| bialix | heya poolie | 09:05 |
| poolie | hi bialix | 09:06 |
| vila | poolie: ha, cool, I've mailed the debian packagers for bzr but I'm still waiting for an answer, this is indeed part of it ;) | 09:06 |
| poolie | vila mind you that doesn't exactly answer the question | 09:06 |
| poolie | i guess it's 2.1, 2.2, 2.3 | 09:06 |
| vila | amazingly 2.3b1 is already there | 09:07 |
| vila | ha, right, jelmer did that | 09:08 |
| poolie | i wonder when natty opens, or whether it's already open | 09:08 |
| wgrant | It can't open until Maverick's released. | 09:08 |
| wgrant | We'd like to change that, but it's Hard. | 09:08 |
| poolie | ah i thought so | 09:09 |
| poolie | ok, i'm going to head off | 09:09 |
| vila | jelmer: pingaling | 09:09 |
| vila | GaryvdM: stop reading my thoughts | 09:20 |
| GaryvdM | ???? | 09:20 |
| GaryvdM | Hi all | 09:20 |
| vila | GaryvdM: Naoki just committed on bug #641557 | 09:20 |
| ubot5` | Launchpad bug 641557 in TortoiseBZR "error while trying to run command via context menu (affected: 2, heat: 12)" [Critical,Fix committed] https://launchpad.net/bugs/641557 | 09:20 |
| vila | GaryvdM: I was thinking about you and it's irritating to see you arriving just as this second as if you were reading my thoughts *again*. I told you to not do that anymore ! | 09:21 |
| GaryvdM | 1. Develop mind reader. 2 Use mind reader. 3. ????? 4. Profit | 09:22 |
| GaryvdM | *2. Use mind reader on vila | 09:22 |
| vila | yeah, yeah, they all say that ! That's not because I'm not paranoid that they aren't all after me ! | 09:22 |
| vila | GaryvdM: more seriously, I was updating http://wiki.bazaar.canonical.com/Releases/2.2.1, you're currently building the windows installers right ? | 09:23 |
| fullermd | I'm paranoid. But am I paranoid ENOUGH? | 09:24 |
| vila | fullermd: never | 09:24 |
| fullermd | That's just what I expected you to say! | 09:24 |
| GaryvdM | vila: Yes - Sorry - I ment to do that, but got side tracked. | 09:24 |
| vila | fullermd: did you notice those black helicopters *behind* you ? | 09:24 |
| vila | fullermd: no need to turn around, they do that too so they are *still* behind you | 09:24 |
| vila | GaryvdM: no need to be sorry ! | 09:25 |
| * fullermd nods wildly at vila. | 09:25 | |
| vila | lol | 09:25 |
| fullermd | 's why I lay on my back. Then I only have to worry about the black subterrines. | 09:25 |
| vila | Oh, I'm fine on this side... mines you know | 09:26 |
| vila | Who build the OSX installers ? Gordon ? I can't remember his IRC nick. Someone ? | 09:27 |
| spiv | bialix: only because I didn't see it in the queue, it turns out it was the very last thing on the +activereviews page because someone else had already voted Approve | 09:38 |
| spiv | bialix: I just changed the status to Approved for you | 09:38 |
| === bialix_ is now known as bialix | ||
| knittl | what exactly is stored in a versionedfile/text-object? each line with: text of that line, author, date? or just text + revid? | 09:49 |
| knittl | for current format if that changed over time | 09:50 |
| bialix | vila: Gordon is doxxxx (not sure about qty of Xs) | 10:00 |
| thumper | hey | 10:00 |
| vila | bialix: ha right, of course, thanks ! | 10:00 |
| thumper | http://doc.bazaar.canonical.com/developers/integration.html comes from where? | 10:00 |
| thumper | I've got a request for some extra examples for that page | 10:00 |
| bialix | thumper: lp:bzr-alldocs | 10:00 |
| bialix | thumper, sorry | 10:01 |
| vila | in the source tree you mean ? | 10:01 |
| thumper | I'd really like examples for getting a diff for a revision | 10:01 |
| bialix | thumper: it's inside bzr.dev/doc/developers | 10:01 |
| thumper | and a diff for a revision for a particular file | 10:01 |
| thumper | also, how do I get a revision id from a revno? | 10:01 |
| thumper | for a branch? | 10:01 |
| vila | Branch.dotted_revno_to_revision_id ? | 10:03 |
| vila | thumper: could be costly | 10:04 |
| thumper | vila: I'm only dealing with mainline revisions | 10:04 |
| fullermd | If it's non-dotted, there's another method, which is oodles cheaper. | 10:04 |
| thumper | does that make it easier? | 10:04 |
| vila | thumper: Branch.get_rev_id | 10:05 |
| vila | thumper: in the worst case the whole ancestry graph is loaded :-/ | 10:06 |
| dlee | What's the quickest way (when no one at the server end is awake) to determine the version of an svn server? I just read the bit about metadata pumped into svn by bzr when the upstream svn server is 1.4. | 10:06 |
| === bigjools is now known as bigjools-afk | ||
| Glenjamin | dlee: programaitcally? | 10:07 |
| Glenjamin | it's in the footer of the webdav repo browser usually if thats good enough | 10:07 |
| dlee | Ah, embarrassing - and yeah good enough. I'd looked in lots of places but not with a browser to the svn path | 10:08 |
| thumper | vila: what is the history optional param to the get_rev_id method? | 10:10 |
| vila | thumper: no idea :) Let me see | 10:11 |
| Glenjamin | it'd be useful if you added an example of how to turn the input from the revision option into a revision_id :) | 10:14 |
| Glenjamin | or does it do that itself? I didn't check | 10:14 |
| vila | thumper: shame it's not documented nor used a lot :-/ It seems to be a simple list with the revids int it indexed by revno -1 | 10:15 |
| vila | s/int/in/ | 10:15 |
| vila | thumper: but almost no callers use it | 10:16 |
| thumper | heh | 10:16 |
| vila | thumper: do you intend to use it a lot for the same branch or is it just one call here and there ? | 10:16 |
| thumper | I intend to be able to walk back through history in jumps of say 20 revisions | 10:17 |
| thumper | for display on a web page | 10:17 |
| thumper | I could just have the revision history cached actually | 10:18 |
| thumper | as webapp overhead | 10:18 |
| thumper | it wouldn't be too bad | 10:18 |
| * thumper thinks of loggerhead | 10:18 | |
| thumper | perhaps not so much of a good idea | 10:18 |
| thumper | lets skip caches I think | 10:18 |
| thumper | vila: primarily for page or site history for wikkid | 10:19 |
| thumper | how do you get commit history for a single file? | 10:20 |
| vila | thumper: the clean way or the dirty way ? :D | 10:21 |
| thumper | actually, I might put down the laptop and watch Chuck :) | 10:21 |
| thumper | vila: clean please | 10:21 |
| thumper | efficient | 10:21 |
| vila | thumper: hehe, the dirty is efficient ;) | 10:21 |
| vila | but, well, wikkid context, so focus on single files, no dir contents involved and you always start with a known path/file-id | 10:22 |
| vila | thumper: correct ? | 10:22 |
| thumper | yep | 10:22 |
| thumper | seriously though, I'm walking away ;0 | 10:23 |
| thumper | laptop is back in the office now | 10:23 |
| thumper | and the warmth is in the lounge | 10:23 |
| thumper | caio | 10:23 |
| vila | thumper: ok, np, I've starting playing around with wikkid | 10:23 |
| thumper | cool | 10:23 |
| Glenjamin | http://wikkid.biz/ ? | 10:23 |
| vila | thumper: more as a user but with some opinoins :) | 10:23 |
| vila | Glenjamin: lp:wikkid | 10:23 |
| Glenjamin | oh wow, that sounds clever | 10:24 |
| vila | Glenjamin: yeah, thumper is :) | 10:24 |
| GaryvdM | thumper: I've been refactoring qlog's internals. One of the things I have done is separate the cache form the state, so that it can be used more easily in a web environment (I had loggerhead in mind). | 10:26 |
| GaryvdM | thumper: One of the things it can do is show a history view, filtered by file id. | 10:27 |
| GaryvdM | or file ids | 10:27 |
| GaryvdM | thumper: so it my be use full to you. | 10:27 |
| GaryvdM | My refactored code is here: lp:~garyvdm/qbzr/log_refactor/ | 10:28 |
| GaryvdM | thumper: It's maybe to soon to use for your purposes, but please keep it in mind. | 10:29 |
| GaryvdM | thumper: If you take a look, look at lib/loggraphprovider.py | 10:30 |
| GaryvdM | thumper: You would cache a LogGraphProvider for the branch, and a FileIdFilter per file, and then create a GraphProviderFilterState per request. | 10:33 |
| bialix | hey GaryvdM | 10:41 |
| GaryvdM | Hi bialix. | 10:41 |
| bialix | should I do the release of 0.19.2 tonight? | 10:41 |
| GaryvdM | I don't mind doing it. | 10:42 |
| xrmx | hello, what does this mean? bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 0] Error | 10:42 |
| bialix | GaryvdM: please, land your latest patch | 10:42 |
| GaryvdM | ok | 10:43 |
| bialix | xrmx: it depends on your URL | 10:44 |
| xrmx | bialix, bzr branch lp:wikipbx , works in my machine, does not work on a chroot | 10:44 |
| bialix | hmm | 10:44 |
| xrmx | bialix, chroot can ping outside world | 10:44 |
| bialix | maybe because you need to run bzr lp-login on chroot? | 10:45 |
| GaryvdM | bialix: Done | 10:45 |
| Glenjamin | shouldn't do to branch | 10:45 |
| bialix | GaryvdM: thanks | 10:45 |
| bialix | xrmx: smells like a bug | 10:45 |
| xrmx | bialix, my chroot is base debian squeeze plus apt-get install git bzr | 10:46 |
| xrmx | bialix, bzr 2.1.2 | 10:46 |
| Glenjamin | can you post the ~/bzr.log ? | 10:47 |
| GaryvdM | setting bzr lp-login would require copying you ssh key to the chroot | 10:47 |
| GaryvdM | Ah - I think I know what is wrong... | 10:48 |
| xrmx | Glenjamin, http://pastebin.com/8QShrp9w | 10:48 |
| * GaryvdM finds bug | 10:48 | |
| GaryvdM | xrmx: Maybe try bzr branch http://bazaar.launchpad.net/~wikipbx-dev/wikipbx/trunk | 10:49 |
| xrmx | GaryvdM, that works fine thanks | 10:50 |
| knittl | what exactly is stored in a versionedfile/text-object? each line with: text of that line, author, date? or just text + revid? (latest format version if that matters) | 10:51 |
| GaryvdM | xrmx: I think your bug has a similar cause to bug 634466 | 10:53 |
| ubot5` | Launchpad bug 634466 in Launchpad Bazaar Integration "bzr branch lp:subvertpy fails as it gets a private branch url. (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/634466 | 10:53 |
| GaryvdM | xrmx: Please log a bug: https://bugs.edge.launchpad.net/launchpad-code/+filebug | 10:54 |
| GaryvdM | knittl: Disclaimer: I'm not fimilar with the internals of versionedfile. What I'm saying is based on my knowledge of the api. | 10:56 |
| knittl | GaryvdM: that's ok. versionedfile is just an API | 10:56 |
| knittl | and it's more than nothing :D | 10:56 |
| GaryvdM | knittl: I think that it only stores the text. | 10:56 |
| GaryvdM | The revid is in the reference to the versionedfile object. | 10:57 |
| knittl | how can the text be mapped to revisions? | 10:57 |
| knittl | let me explain shortly what i got so far, maybe you can fill in the missing bits. i'm going top down | 10:58 |
| knittl | revision object: stores message, time, committer, branchnick, random revid (mail+time+random) | 10:58 |
| knittl | plus a sha1 of the inventory | 10:59 |
| knittl | and parents of course | 10:59 |
| GaryvdM | right | 10:59 |
| knittl | inventory maps file_ids to canonical paths | 10:59 |
| knittl | so there is no composite pattern, an inventory cannot contain another inventory | 11:00 |
| knittl | also stores the executable bit per path but that's unimportant compared to the other stuff | 11:00 |
| knittl | correct? | 11:01 |
| GaryvdM | Think so | 11:01 |
| knittl | file_ids do not change. ever | 11:01 |
| GaryvdM | right | 11:02 |
| knittl | i think inventory also stores some hash of the files, but that will not matter for our simple case (without verifying content) | 11:02 |
| knittl | so, how will an revision+inventory get the right version of the file? | 11:02 |
| knittl | that's the bit i don't understand | 11:03 |
| GaryvdM | I'm looking at the code for RevisionTree.get_file | 11:03 |
| xrmx | GaryvdM, bug filed at https://bugs.edge.launchpad.net/launchpad-code/+bug/644244 | 11:04 |
| ubot5` | Launchpad bug 644244 in Launchpad Bazaar Integration "can't bzr branch lp:wikipbx from chroot (affected: 1, heat: 6)" [Undecided,New] | 11:04 |
| GaryvdM | Revision tree knows it's revid | 11:04 |
| GaryvdM | And we give it a file id | 11:04 |
| knittl | so a revisiontree = state of an inventory? | 11:04 |
| GaryvdM | That calls self._repository.iter_files_bytes((revid, fileid)) | 11:05 |
| knittl | ok, but the files have to store the revid of each line/change? | 11:05 |
| knittl | otherwise you cannot reconstruct a particular version | 11:05 |
| GaryvdM | Revision tree is a abstraction of a inventory, + file texts. It has the similar api to a WorkingTree, and others | 11:06 |
| knittl | that does not really answer my question | 11:08 |
| lifeless | knittl: the strict answer to your question is 'no, they do not' | 11:09 |
| lifeless | there are many ways to implement that api | 11:10 |
| knittl | lifeless: ok. then how can we reconstruct an exact version of a file for a given revision/inventory/'whatever you call it' | 11:10 |
| GaryvdM | My understanding is that there is an index to say (revid, fileid) -> where it is stored, and where it is stored just has the text - no knowledge of the revid it's for. | 11:11 |
| GaryvdM | lifeless know much more than me :-) | 11:11 |
| * lifeless is going to sleep | 11:11 | |
| lifeless | GaryvdM has it right | 11:11 |
| knittl | GaryvdM: yes. but fileids do not change. so how can you map from revid -> fileid? | 11:11 |
| knittl | because fileids stay the same over all revisions | 11:11 |
| knittl | if the contents of a file change, its id stays the same | 11:12 |
| knittl | that's the part i am confused about | 11:12 |
| GaryvdM | You start with a revid and a fileid and ask for the text. You don't start with the text, and get the revid. | 11:12 |
| knittl | GaryvdM: yes | 11:12 |
| knittl | you have a revision (revid) and the filename (which looks up the fileid in the inventory) | 11:12 |
| knittl | then what? how do i get the correct version of the file? | 11:13 |
| GaryvdM | You allready have the revid - to get the text, you can call RevisionTree.get_file | 11:14 |
| GaryvdM | The fact that the fileid may have only been edited by a previous revision is handled by the api. | 11:15 |
| knittl | so a file stores revids -> text? | 11:15 |
| knittl | * a versionedfile contains multiple revisions? | 11:16 |
| GaryvdM | I *think* a versionedfile object stores (revid, fileid) -> text | 11:16 |
| knittl | and then maps revid -> state of file | 11:16 |
| knittl | well, you access a versionedfile 'textstore' (?) via its fileid | 11:17 |
| knittl | so it only needs to map revid -> text | 11:17 |
| GaryvdM | Ok - my be wrong there | 11:17 |
| knittl | independent of weave/groupcompress/delta/snapshot storage? | 11:17 |
| knittl | and that is what i was saying all along: 'text' objects (versionedfile) map revid -> lines/state/text | 11:18 |
| GaryvdM | VersionedFile is a very low level api. I'm not sure what you are trying to achive, but would recommend maybe working with I higher level api, e.g. RevisionTree | 11:19 |
| * GaryvdM reads the VersionedFile code | 11:19 | |
| knittl | not interested in 'working with an api' | 11:19 |
| knittl | i'm interested in the inner workings and low level storage mechanisms | 11:19 |
| knittl | (still, because i haven't managed in weeks to fully understand and nobody in here could properly explain the bazaar object/storage model) | 11:20 |
| GaryvdM | Ok - Then I'm the wrong person to answer - sorry. | 11:21 |
| spiv | knittl: the low-level storage in the current format is pretty complex, aside from the revision/inventory/versionedfile abstractions that you are starting to know your way around, you need to understand packs, groupcompress and possibly the CHK maps depending on what you want to know. And I suppose for completeness I should mention the btree indices for the stores. | 11:29 |
| knittl | spiv: yeah, i noticed it's complex, because nobody knows it xD | 11:29 |
| spiv | knittl: it's not so much that nobody in here can properly explain it as that to do so takes quite a bit of time :) | 11:29 |
| knittl | spiv: but tell me, am i right with my understanding of versionedfile? | 11:30 |
| knittl | versionedfile (accessed by fileid) stores revid -> content | 11:30 |
| spiv | That the key into the 'texts' versionedfile is 'fileid'? No. | 11:30 |
| knittl | or revid -> changes (depending on the storage format) | 11:30 |
| spiv | The key into that versionedfile is (file id, rev id) | 11:30 |
| knittl | but a versionedfile only contains a single file? | 11:31 |
| spiv | No. | 11:31 |
| knittl | what then? | 11:31 |
| spiv | The API is actually called VersionedFiles | 11:31 |
| spiv | Plural. | 11:31 |
| knittl | with single file i mean: all versions of a file over time | 11:31 |
| knittl | versionedfile.py here (singular) | 11:31 |
| spiv | Or rather the VersionedFiles class is the preferred abstraction. | 11:32 |
| knittl | which contains multiple versionedfile objects? | 11:32 |
| knittl | anyways, let me try again :D | 11:33 |
| knittl | to get the contents of a file for a particular revision i'm using (fileid, revid) | 11:34 |
| knittl | so somewhere inside file (text) storage there has to be a place to store the revid? | 11:34 |
| spiv | None of the APIs of VersionedFiles return a VersionedFile object. That's not the key to understanding this. | 11:34 |
| knittl | let's not talk about concrete implemantions of that api | 11:35 |
| spiv | I need to go in a moment, but I'll quickly reiterate what I described the other day. | 11:35 |
| spiv | Say you have a revision, and want the contents of the file known as 'doc/manual.txt' in that revision. | 11:35 |
| knittl | yes | 11:36 |
| knittl | i only know of that file because it's stored in the inventory for that revision | 11:36 |
| spiv | You have the revision already, so you know the revid. | 11:37 |
| spiv | So you can lookup the inventory for that revision by using that rev-id as the key for the 'inventories' store | 11:37 |
| knittl | but i don't know the filename | 11:37 |
| knittl | yes, and from the inventory i get fileid from filename | 11:37 |
| spiv | (or if you want to view the repository as a unified keyspace, by looking up ('inventories', rev-id) as the key) | 11:37 |
| spiv | Then you ask the inventory object for the inventory entry for that path, 'doc/manual.txt' | 11:38 |
| spiv | That inventory entry will have, among other attributes, a file-id and a "revision_id" | 11:38 |
| knittl | revid is the same as the revisions revid? | 11:38 |
| spiv | That "revision_id" might be the same as the revision id you already have, but for instance if the file hasn't changed in recent revisions it'll be some older ID. | 11:39 |
| knittl | ok | 11:39 |
| spiv | So you can't assume its value, you have to check the inventory for it. | 11:39 |
| knittl | but it's a revid that can be mapped to a revision | 11:39 |
| knittl | it's 'last changed revid' for a file | 11:39 |
| spiv | Then you can use that (file-id, revision-id) pair as a key in the 'texts' store | 11:39 |
| spiv | To get the bytes of the contents of that file. | 11:40 |
| spiv | It's not 'last changed revid' necessarily. | 11:40 |
| knittl | spiv: why not last changed? you said if it didn't change in the last revision it will be an older one | 11:40 |
| spiv | It may often happen to coincide with that, but in fact nothing in the implementation requires it matches the ID of any stored revisions at all. | 11:40 |
| knittl | filid+revid = content | 11:41 |
| spiv | knittl: maybe the file contents were reverted | 11:41 |
| knittl | spiv: so it could be any revid? not even existing? what's the sense in that | 11:41 |
| spiv | knittl: maybe an import from a foreign system stored things slightly differently to the default implementation in bzrlib | 11:41 |
| spiv | knittl: it's just an random, unique value — like rev-id is. | 11:41 |
| knittl | but again i ask: fileid+revid = content. so i need to store the revid for lines of text? | 11:42 |
| knittl | spiv: does it usually match a revision rev_id or is that unlikely? | 11:42 |
| spiv | I don't know what "I need to store" means here. | 11:42 |
| knittl | to be able to map from id -> content i need to store both id and content | 11:42 |
| spiv | It usually does, but I wouldn't rely upon it. | 11:42 |
| spiv | (it might match a revision not present in this repo, for instance) | 11:43 |
| knittl | id in an index and content in a binary file | 11:43 |
| spiv | What do you mean when you say "id" here? | 11:43 |
| knittl | in that case fileid+revid | 11:44 |
| spiv | I've described already exactly how to access the content, model-wise. | 11:44 |
| spiv | (the exact bytes on disk are of course involve many more details) | 11:44 |
| spiv | We call that a key | 11:44 |
| knittl | i didn't ask about exact bytes | 11:44 |
| knittl | filestore maps (fileid,revid) -> content? | 11:45 |
| spiv | The 'texts' store does that, yes. | 11:45 |
| spiv | As I'm pretty sure I've said at least three times now :/ | 11:46 |
| knittl | good. didn't i ask that ages ago? | 11:46 |
| spiv | And didn't say that ages ago? | 11:46 |
| knittl | and if it maps (which it does you tell me) | 11:46 |
| spiv | s/say/I say/ | 11:46 |
| knittl | it needs to store fileid, revid and content | 11:46 |
| knittl | right? | 11:46 |
| knittl | that's what i want to know … | 11:46 |
| spiv | What did you think I meant by "look up" and "use as a key", I wonder? | 11:47 |
| knittl | spiv: i asked several times, and you always denied and put it in different wordings | 11:47 |
| knittl | you said: »no, it blah« | 11:47 |
| knittl | i'm just confused about this overly complex system | 11:47 |
| spiv | If I contradicted you, it's because you're using terminology inconsistently with how we use it. | 11:48 |
| spiv | Which is only going to lead to confusion and frustration, so please be patient if I insist on being precise. | 11:49 |
| knittl | because it's easier for me to understand 'text store stores file id, rev id, content' than to say 'bla, api, maps, key, …' | 11:49 |
| knittl | i'm sorry, if i sound rude, but it's not easy to grasp all that | 11:49 |
| spiv | 'stores file id, rev id, content' is just too imprecise. | 11:49 |
| knittl | why? it stores all of them, and then establishes a mapping | 11:50 |
| Glenjamin | but these are low level APIs, they're not supposed to be easy to grasp - they're abstracted away from the user/developer by APIs/UIs that are | 11:50 |
| spiv | It doesn't suggests to me that they are stored together as a composite value, rather than that 2 of those are used to map to the other. | 11:50 |
| knittl | Glenjamin: hg uses revlogs (easy), git uses hashes with references to other hashes (also easy) | 11:50 |
| Glenjamin | but neither are a feature | 11:51 |
| spiv | We'd usually say the texts store stores, well, texts, or content if you like. | 11:51 |
| knittl | is format 2a the same as knitpack format? | 11:51 |
| spiv | And the key for a text is the (file id, rev id) pair. | 11:51 |
| knittl | spiv: and some index stores the ids and maps it to the store | 11:51 |
| spiv | No, 2a is quite different to knitpack. | 11:51 |
| knittl | where can i find docs on 2a? | 11:52 |
| knittl | http://doc.bazaar.canonical.com/latest/developers/packrepo.html | 11:52 |
| spiv | knittl: well, I think you can see simplifying it to "stores file id, rev id, content" is omitting important structural details. | 11:52 |
| spiv | 2a == groupcompress packs + CHK inventories. | 11:53 |
| knittl | where's the documentation/explanation of 2a? | 11:53 |
| knittl | http://doc.bazaar.canonical.com/latest/developers/groupcompress-design.html 2a? | 11:54 |
| spiv | See RepositoryFormat2a in bzrlib/repofmt/groupcompress_repo.py | 11:54 |
| knittl | spiv: reading thousands of sourcecode lines does not help me to understand, i'm sorry. i've already read function names, comments, … | 11:55 |
| spiv | That's a description of the "groupcompress" part, that doesn't cover the CHK inventories | 11:55 |
| spiv | knittl: Well, there are docstrings that say relatively useful things like "A CHK repository that uses the bencode revision serializer." | 11:55 |
| knittl | http://doc.bazaar.canonical.com/latest/developers/inventory.html | 11:55 |
| spiv | Which isn't immensely helpful, but it gives some pointers. | 11:55 |
| spiv | As does the classes it in turn references. | 11:56 |
| spiv | Anyway, I must go. | 11:56 |
| knittl | ok, thanks | 11:56 |
| spiv | I'm sorry you feel it's overly complex, but fortunately or otherwise we didn't write it for your comprehension ;) | 11:56 |
| spiv | Good luck, until tomorrow perhaps ;) | 11:56 |
| knittl | there should be documentation nevertheless | 11:57 |
| knittl | i want to understand the version control system i'd trust my data | 11:57 |
| spiv | (back very briefly) So you understand exactly how your filesystem turns your data into bytes on media? And partition tables? ;) | 12:00 |
| spiv | Ok, really gone :) | 12:00 |
| knittl | no, but i understand partition tables | 12:01 |
| knittl | and i guess there's documentation for filesystems | 12:01 |
| knittl | which format does not change every 2 months | 12:01 |
| GaryvdM | knittl: Thats 1. rude, 2. no longer true. 2a is more than a year old, with a commitment to stay as the default for much longer. | 12:03 |
| vila | Hoping to get help from people by constantly bashing their work, way to go ! | 12:03 |
| knittl | GaryvdM: it was true for the past | 12:03 |
| knittl | also i found a lot of 'in development formats' | 12:04 |
| knittl | so i'm wondering | 12:04 |
| knittl | vila: well, there is no 'documentationy' documentation which explains the inner workings, which i find very sad | 12:04 |
| vila | EPARSE, I'm not an native english documentationy means ? | 12:05 |
| knittl | vila: it's a made up adjective from 'documentation' | 12:05 |
| knittl | for me comments in source code do not count as documentation | 12:06 |
| vila | then we don't have a documentation suited to your needs | 12:06 |
| knittl | … which i find very sad | 12:06 |
| vila | we know that | 12:06 |
| vila | (both that we don't have this documentation and that you're sad) | 12:07 |
| knittl | yes, i said it twice already | 12:07 |
| Hydrox | is there at least a plan to add documentation? | 12:07 |
| vila | oh of course there is a plan | 12:07 |
| vila | see https://bugs.edge.launchpad.net/bzr/+bugs | 12:08 |
| vila | 2000 are open, 200 of high priority, now is that plan part of these 200 ? I'm not sure | 12:08 |
| vila | This is a GPL project, everybody is welcome to scratch his own itch, and a lot of people are... without this documentation so far | 12:09 |
| vila | Don't get me wrong, I asked the same question very early after joining the project thinking it will help me to start quicker | 12:10 |
| knittl | vila: i could only write documentation if i understood the internals | 12:10 |
| vila | Well, I didn't start quicker but that wasn't a blocking factor either | 12:10 |
| vila | knittl: I didn't ask you to | 12:11 |
| knittl | didn't say that | 12:11 |
| Hydrox | vila, do you write documentation about the things you add to bzr (other the code comments)? | 12:15 |
| vila | Hydrox: when needed yes, most of my time is spent fixing bugs though, so generally it means making the code respect what the doc says ;-) | 12:16 |
| vila | Hydrox: most of our doc is also targeted at users, mozt of the bzr hackers hang around here and on the mailing list where most of the internal knowledge is shared via discussions, merge proposals, etc. Nobody felt the need to summarize to put that into proper documentation, but any start will certainly be warmly welcome | 12:18 |
| === Meths_ is now known as Meths | ||
| === bigjools-afk is now known as bigjools | ||
| vila | jelmer: Pingaling | 14:17 |
| rocky | jelmer, hey are you following setuptoolsbzr at all ? | 14:23 |
| Fuu | nice, bazaar install crashed windows explorer :) | 15:35 |
| vila | Fuu: file a bug mentioning versions (OS, bzr, etc), that's unheard of AFAIK | 15:37 |
| Fuu | i'll do that | 15:37 |
| Fuu | it wasnt why i came here though, just joined before even attempting to install :) | 15:38 |
| vila | Fuu: you're welcome in all cases ;) | 15:38 |
| Fuu | thank you | 15:38 |
| jelmer | vila: hi | 15:38 |
| jelmer | rocky: hi | 15:38 |
| vila | jelmer: hey ! | 15:39 |
| jelmer | rocky: no, what about it? | 15:39 |
| vila | jelmer: so my ping was about the new bzr releases and their impact on debian | 15:45 |
| vila | jelmer: I see you already packaged 2.3b1 and I'm wondering what else needs to be done | 15:46 |
| vila | jelmer: 2.2.1 for sid, 2.1.3 for squeeze and 2.0.6 for lenny-backports ? | 15:47 |
| vila | jelmer: I'm not a debian expert, just reading: http://packages.debian.org/search?keywords=bzr :-D | 15:47 |
| vila | jelmer: and also, may be more important, are the debian branches in sync with the packaging branches on lp ? Do they share the same history ? etc | 15:49 |
| vila | jelmer: and before I ask for the ponny, feel free to update http://wiki.bazaar.canonical.com/Releases/2.2.1 (and 2.0.6, 2.1.3 and 2.3b1 though I already updated the later) | 15:50 |
| vila | jelmer: where is my ponny ? | 15:50 |
| ara | hello all! | 16:06 |
| ara | I am getting this error when pushing a new branch: | 16:06 |
| ara | > Using default stacking branch /~ubuntu-qa-website-devel/ubuntu-qa-website/trunk at lp-97781328:///~ubuntu-qa-website-devel/ubuntu-qa-website | 16:06 |
| ara | bzr: ERROR: KnitPackRepository('lp-97781328:///~ubuntu-qa-website-devel/ubuntu-qa-website/trunk/.bzr/repository') | 16:06 |
| ara | is not compatible with | 16:06 |
| ara | CHKInventoryRepository('lp-97781328:///~ubuntu-qa-website-devel/ubuntu-qa-website/wordpress-theme/.bzr/repository') | 16:06 |
| ara | different rich-root support | 16:06 |
| ara | any ideas? | 16:06 |
| jam | ara: one of them is in 0.92 format, the other is in 2a format, which are not directly compatible. (upgrading to 2a is a one-way upgrade) | 16:13 |
| jam | it looks like trunk is in 0.92, and the one you are trying to create is in 2a | 16:13 |
| jam | either: | 16:14 |
| jam | a) Get trunk to upgrade to 2a | 16:14 |
| jam | b) rework so that you're local stuff is in 0.92, and then push that to a new branch | 16:14 |
| ara | how do I a) | 16:14 |
| ara | ? | 16:15 |
| ara | bzr --upgrade 2a? | 16:15 |
| jam | ara: "bzr upgrade --format=2a lp:ubuntu-qa-website" | 16:15 |
| ara | jam, thanks a lot! | 16:15 |
| jam | (though --format=2a is now the default for upgrade) | 16:15 |
| ara | the process crashed :( | 16:21 |
| ara | http://pastebin.ubuntu.com/497788/ | 16:22 |
| ara | I can report the bug, if it is interesting | 16:22 |
| fullermd | I believe that's a bug in 2.2.0, fixed in 2.2.1. | 16:24 |
| ara | fullermd, can I use a bzr daily build to test? | 16:25 |
| fullermd | If it's new enough, I guess. It's probably just as easy to use 2.2.1 though. | 16:26 |
| maxb | 2.2.1 isn't in the PPA yet, so a good option might be to branch the release branch and build it | 16:27 |
| maxb | bzr branch lp:bzr/2.2 && cd 2.2 && python setup.py build_ext -i && ./bzr whatever | 16:27 |
| jam | ara, fullermd: I just changed and https://edge.launchpad.net/~bzr/+archive/proposed | 16:27 |
| jam | seems to say that the packages haven't been uploaded yet | 16:27 |
| jam | ara: is this your personal project ? (you have direct admin access?) | 16:27 |
| ara | jam, I do have admin access | 16:28 |
| jam | if you want to join me to the group, I can upgrade it for you, and then leave group | 16:28 |
| ara | jam, OK, is jam your lp id? | 16:28 |
| jam | jameinel | 16:28 |
| ara | jam, added | 16:29 |
| jam | ara: working on it | 16:35 |
| ara | jam, thanks! | 16:35 |
| jam | ara: hmmm it is giving me permission denied errors | 16:36 |
| ara | jam, weird, as the owner is ubuntu-qa-website-devel and you are now part of it... | 16:37 |
| jam | yeah, but I'm getting the same error elsewhere, still investigating | 16:37 |
| jam | ara: I'm guessing it might have had something to do with the new URLs that thumper worked on (bazaar.launchpad.net/+branch/ubuntu-qa-website vs ~ubuntu-qa-website-devel/ubuntu-qa-website/trunk) | 16:42 |
| jam | I don't know that for sure | 16:42 |
| jam | but I got it working | 16:42 |
| ara | thanks! | 16:43 |
| jam | ara: I'll let you know when the upgrade finishes | 16:43 |
| ara | jam, cool :) | 16:43 |
| jam | ara: looks to have completed | 16:48 |
| ara | jam, thanks a lot, will try now the push | 16:51 |
| === beuno is now known as beuno-lunch | ||
| jeremyw | Hello all. | 17:08 |
| ara | jam, it worked, thanks! | 17:10 |
| jam | ara: happy to help | 17:10 |
| jeremyw | I'm writing a thing wrapper to some choice VCS systems and I'm wanting to add Bazaar support to my application. I've read the integration wiki page but one thing it doesn't talk about is repository creation. | 17:12 |
| jeremyw | I'd really like to understand the moving parts a little better. Anyone got a minute to help me understand what a bzr repository is composed of? | 17:13 |
| jeremyw | Basically, I'll be creating server-side repositories that will only be accessed via a network server and NEVER locally. | 17:13 |
| Glenjamin | jeremyw: is your wrapper for the client or the server? | 17:14 |
| fullermd | jeremyw: Be sure you're ascribing the right level of meaning to 'repositories'... | 17:14 |
| jeremyw | Where I've gotten to at this point is I've found bzrlib.builtins.cmd_init_repository.run(). | 17:14 |
| jeremyw | fullermd: That's what I'm learning is that I think my terminology is different than what bzr uses. | 17:14 |
| Glenjamin | i think you actually want a bzrdir | 17:14 |
| jeremyw | Glenjamin: This would be a library uses on the server for things like repository creation and repository browsing. For simplicity, let's just pretend I was writing a repository browser. (That being said, please don't try to get me to use XXX repository browser as this is just an example scenario.) | 17:15 |
| jeremyw | Glenjamin: Yeah. I see that being used in the function mentioned above. | 17:16 |
| Glenjamin | but repository browser XXX is great! D: | 17:16 |
| jeremyw | haha | 17:16 |
| jeremyw | Glenjamin++ | 17:16 |
| fullermd | I always worry about projects to create wrappers like that. It's sure to wind up being an ugly force-fit to one system or another... | 17:16 |
| jeremyw | Well, this tool needs to create repositories that can be accessed remotely by users but also accessed locally via my API to do things like creating the repository browser. | 17:17 |
| Glenjamin | jeremyw: http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/core_concepts.html | 17:17 |
| jeremyw | fullermd: Well, I'm trying to do less wrapping and more direct bzrlib usage. | 17:17 |
| Glenjamin | admittedly its not exactly clear on repositories | 17:17 |
| jeremyw | Right now, I just subprocess.Popen to "bzr init PATH". ;) | 17:17 |
| Glenjamin | if speed isn't an issue, thats likely to cause the least surprises | 17:18 |
| jeremyw | Glenjamin: That's what I'm seeing right now...everything I've seen (docs/examples/etc) barely talk about repositories. | 17:18 |
| Glenjamin | basically, bazaar doesn't have the repository concept in the same way as other VCSes | 17:18 |
| fullermd | I mean wrapping in a conceptual sense. In svn, frex, you have to take a lot of care where you put a repository, because you can't do anything outside of one, and can hardly to anything between them. | 17:18 |
| jeremyw | Glenjamin: Well, I'd still rather do this in a Pythonic way so I'll likely use bzrlib.builtins.cmd_init_repository.run() but I'm wondering if that is ideal/performant. | 17:19 |
| Glenjamin | a repository is simply somewhere revisions are stored, normal branches just have their own repo | 17:19 |
| jeremyw | fullermd: Understood. | 17:19 |
| fullermd | Whereas in bzr, it's totally different. Meanwhile, in bzr, you have a branch granularity you center around, whereas in svn-land branches practically don't exist, and you deal with semi-arbitrary subdivisions of the repository. | 17:19 |
| Glenjamin | in most cases, the repository concept in other VCSes maps to a bazaar branch | 17:19 |
| Glenjamin | sort-of | 17:19 |
| jeremyw | That's what rockstar was telling me. | 17:19 |
| Glenjamin | i think that calling bazaar commands is likely to be the safest option, maybe going one level down and using the API the command wraps | 17:20 |
| Glenjamin | but no lower | 17:20 |
| jeremyw | Cool. Now if I wanted to understand these terms a little better and how they interact, where should I start? | 17:21 |
| vila | from fullermd wiki page I'm searching vainly for a few minutes | 17:22 |
| Glenjamin | I'm only really familiar with the concepts from using it i think | 17:22 |
| jeremyw | I'm reading that wiki page and the integration page. | 17:22 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief | 17:22 |
| fullermd | The Length-ier discussion linked at the bottom has some inter-VCS comparisons at the end too, which may be useful. | 17:23 |
| vila | yeah, this one, damn ff | 17:23 |
| jeremyw | fullermd: Thanks man. I appreciate it. | 17:23 |
| Glenjamin | are there other articles like this? I'm about to introduce 40 or so students to bazaar with a centralised smart server next week | 17:23 |
| Glenjamin | in previous years we gave them svn+tortoise, and i want something less rubbish. | 17:24 |
| jeremyw | I agree that wrapping vcs is usually bad but my project practically requires it. I have a tool that will support N VCS systems so I need a way to do this stuff programmatically. | 17:24 |
| fullermd | Glenjamin: I've got those SpotDocs covering general concepts (which I still need to do some weed-whacking on the editing of), the interactions of push/pull/merge/etc, and how the rev numbering and history structuring affects things. | 17:26 |
| fullermd | If my tuits would stop being all rectangular... | 17:26 |
| jelmer | vila: sorry, I was interrupted bny breakfast | 17:29 |
| vila | jelmer: sure, and since it was a long one, you had to take a nap :-D | 17:29 |
| jelmer | vila: >-) | 17:29 |
| vila | jelmer: kidding :) | 17:29 |
| jelmer | vila: What are the lp branches you were referring to? | 17:30 |
| fullermd | Mmmm... nap... | 17:30 |
| jeremyw | fullermd: By a quirk of history and naming, that whole conglomeration (Repository, Branch, and Working Tree) is often colloquially called a "branch". | 17:30 |
| jeremyw | Loving it. :) | 17:30 |
| vila | jelmer: the lp:ubuntu/xxx/bzr | 17:30 |
| fullermd | jeremyw: In retrospect, sure, it's lovable. When I started using bzr, and vented some epic ranting about it on #bzr, not so much :p | 17:31 |
| vila | jelmer: well, the lp:~bzr/unbuntu/<distro>/bzr to be precise | 17:31 |
| jelmer | vila: No, they're different. lp:debian/xxx/bzr would be the ones matching those on bzr.debian.org, except they have the same contents but different revision data | 17:31 |
| vila | jelmer: argh | 17:31 |
| vila | hence my question :-/ | 17:32 |
| jeremyw | fullermd: Well, I was speaking more about how that summed up what you were saying in here. :) | 17:32 |
| jelmer | vila: james_w might be able to fix that | 17:32 |
| jelmer | james_w: ^ | 17:32 |
| vila | jelmer: fixing as in updating/rewriting the debian branches ? | 17:33 |
| jelmer | vila: making the lp:debian/ branches use the ones from bzr.debian.org directly rather than having it create them from scratch based on the source packages | 17:34 |
| vila | jelmer: ha, right, yeah good first step, but the disjoint history will remain. | 17:35 |
| vila | jelmer: and which bzr releases are supposed to find their way in the debian world ? 2.3b1 has, but what about 2.2.1, 2.13 and 2.0.6 ? | 17:35 |
| vila | 2.1.3, I don't care (yet) about 2.13 | 17:36 |
| fullermd | I do. Can I have 2.13 right now plz? | 17:37 |
| vila | fullermd: bzr pull --from-future lp:bzr/2.13 | 17:41 |
| vila | fullermd: you may encounter ENOTIMPLEMETEND though... | 17:41 |
| * jeremyw expects to be a bzr expert after reading these four pages... | 17:41 | |
| jeremyw | ;) | 17:41 |
| fullermd | bzr: ERROR: exceptions.ReversedEntropyArrow | 17:42 |
| roryy | bug 202374 might actually be easy \o/ | 17:42 |
| ubot5` | Launchpad bug 202374 in Bazaar "pull and update should accept --show-base (affected: 0, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/202374 | 17:42 |
| roryy | except for the tests, maybe, and all the error checking | 17:43 |
| roryy | oh well | 17:43 |
| vila | fullermd: ha cool, so --from-future has been implemented, the error you're seeing should be shallow | 17:43 |
| fullermd | Oh, very shallow, if you perceived it from 4 dimensions. Just infinitely deep in 3 :p | 17:44 |
| vila | get new glasses :-D | 17:44 |
| vila | I heard good things about 3D ones.. should work there too I'm sure (otherwise they wouldn't be talking so much about them) | 17:45 |
| fullermd | What, you suggest Klein bottle lenses? | 17:46 |
| vila | yeah | 17:48 |
| fullermd | Well, it would be a unique look, I guess. The chicks would dig it. | 17:48 |
| vila | dogs too | 17:51 |
| maxb | jelmer: So, for the immediate series of releases, should I wait until 2.2.1 lands in a debian branch before I do the PPA packaging, or should I go ahead with the PPAs anyway? | 17:54 |
| fullermd | jeremyw: Well, that's the goal :) Understanding the foundations, working out what various commands yield, or what should be done to achieve a given end-state, _should_ (at least in theory) be a fairly straightforward exercise. | 17:55 |
| fullermd | jeremyw: And those pages are a (sadly time-limited) attempt of mine to lay out those bricks. | 17:55 |
| vila | maxb: my gut feeling is that you should go ahead, but we need a better short/middle/long (dunno) term solution | 17:56 |
| === beuno-lunch is now known as beuno | ||
| maxb | oh urgh | 17:59 |
| maxb | the bzr ppa brances are a complete mess | 18:00 |
| maxb | The debian packaging history and the udd parallel import have been merged together | 18:00 |
| vila | maxb: which means you can merge from debian branches but ignore everything except the debian dir ? | 18:01 |
| vila | maxb: or worse ? | 18:01 |
| maxb | which means the history is an evil incomprehensible mess | 18:01 |
| vila | maxb: ha :-/ | 18:02 |
| vila | maxb: dir you tried bzr qlog bzr-* ? It helps a bit | 18:03 |
| maxb | Also, the debian experimental branch contains a .bzrignore.THIS.THIS file, which is just silly :-) | 18:03 |
| vila | operator error :-/ | 18:03 |
| vila | maxb: bzr qlog bzr-maverick bzr-lucid bzr-karmic bzr-jaunty bzr-hardy | 18:06 |
| vila | maxb: ^ is not *that* bad | 18:06 |
| maxb | is just about bearable, yes | 18:06 |
| maxb | not what I'd call pleasant, though | 18:06 |
| === Ursinha is now known as Ursinha-lunch | ||
| vila | maxb: yeah :-/ | 18:07 |
| maxb | Hmm, I definitely need to talk to jelmer, as he seems to have switched from using bzr merge to using bzr merge-upstream for branch maintenance with 2.3b1 | 18:07 |
| maxb | Is there a quick way to test if two branches have any revisions in common? | 18:08 |
| vila | maxb: ok, let me know if you're blocked or need anything, I'm about to EOD but I may pass around later | 18:09 |
| dash | maxb: /join #tmlabs | 18:09 |
| vila | maxb: just a sec | 18:09 |
| dash | maxb: oops | 18:09 |
| dash | wrong button | 18:09 |
| dash | maxb: bzr missing will tell you | 18:09 |
| maxb | dash: I don't want missing, I want bzr not-missing :-) | 18:09 |
| dash | heheh | 18:09 |
| * fullermd . o O ( bzr gnissim ) | 18:10 | |
| maxb | Also I want people to have not applied different merge structures to the hardy ppa branch vs the maverick ppa branch | 18:10 |
| jeremyw | fullermd: I apprecite it. | 18:25 |
| fullermd | jeremyw: Were they helpful? | 18:28 |
| jeremyw | fullermd: I just got out of the shower. I'll be reading in about half an hour. I'll let you know. Will you be here for a bit? | 18:28 |
| fullermd | (unfortunately not really aimed directly at your problem, but ...) | 18:28 |
| fullermd | Oh, good. My writing hates stinky people 8-} | 18:29 |
| fullermd | I'll probably be around for a little while, yah. | 18:29 |
| jeremyw | No sweat...you're not on the hook or anything. Just hoping not to miss you when I give my feedback. ;) | 18:31 |
| === deryck is now known as deryck[lunch] | ||
| fullermd | Well, I'll be in IRC even if I'm snoozing up a storm, so I'll have it in logs if nothing else. | 18:35 |
| fullermd | (if I logged out, who knows what vila would say about me behind my back...) | 18:36 |
| GaryvdM | fullermd: That's why I wget and grep irclogs.ubuntu.com...... ;-z | 18:38 |
| shakaran | Hi, I did "bzr bind lp:myproject" now my bazaar repository works like subversion (centralized mode). I want revert to distributed mode, how to make it? | 19:14 |
| LeoNerd | bzr unbind | 19:14 |
| === Ursinha-lunch is now known as Ursinha | ||
| shakaran | just that? I have many member on the team, Should they have bzr unbind too? | 19:14 |
| LeoNerd | bzr unbind undoes the bzr bind operation | 19:15 |
| LeoNerd | It's a setting on your particular branch. If they have a checkout/branch of their own, theirs is independent of yours | 19:15 |
| shakaran | thanks LeoNerd | 19:15 |
| === deryck[lunch] is now known as deryck | ||
| === khmarbaise_ is now known as khmarbaise | ||
| === Meths_ is now known as Meths | ||
| ellimistd_ | How can I download a specif old revision from launchpad? | 21:48 |
| ellimistd_ | *specific | 21:48 |
| mwhudson | ellimistd_: bzr get <branch-url> -r $old_rev | 21:48 |
| ellimistd_ | great, thanks | 21:52 |
| maxb | jelmer: Hi, are you around? (wanted to talk about debian packaging) | 22:03 |
| jeremyw | fullermd: Just finished reading your docs...they helped a lot. Thanks. | 22:36 |
| jelmer | maxb: hi | 22:36 |
| jelmer | maxb: somewhat | 22:36 |
| maxb | jelmer: hi. I'd like there to be a branch which I can use as a basis for PPA packages of 2.2.1, but so far I've held off preparing a 2.2.1-1 for sid and asking for sponsorship, on the basis that it's probably easier for someone to just do, than to review | 22:40 |
| maxb | What's your thoughts on that? | 22:40 |
| maxb | Also, I note that with 2.3b1, it looks like you've changed to using 'bzr merge-upstream' to integrate new upstream versions into the packaging branches for Debian | 22:41 |
| maxb | Also, what's the general criteria on Debian pkg-bazaar membership, and would it make sense for me to request membership if I'm working on this sort of stuff? | 22:42 |
| jelmer | maxb: A sponsorship request for sid would be futile - squeeze is frozen | 22:43 |
| jelmer | maxb: Yeah, you're more than welcome to join the pkg-bazaar team | 22:43 |
| maxb | sid is already ahead of squeeze | 22:43 |
| maxb | Therefore I assumed sid was being kept up to date regardless of the freeze making it less important than usual | 22:44 |
| jelmer | maxb: That's because of unfortunate timing - I uploaded to sid less than 24 hours before squeeze was frozen. | 22:45 |
| maxb | aha | 22:46 |
| maxb | In that case, is there intent to put 2.2.1 into sid, or will we now leave sid alone until squeeze has released? | 22:47 |
| poolie | hello maxb, jelmer | 22:50 |
| jeremyw | fullermd: ping | 22:50 |
| vishy | I did 'bzr init' and then i create branches via bzr branch, which creates a subdirectory. | 22:56 |
| vishy | I accidentally did a bzr pull <branch> in the parent directory | 22:56 |
| vishy | any way to revert it? | 22:56 |
| vishy | bzr revert doesn't seem to do anything | 22:57 |
| maxb | 'bzr init' creates a new empty branch. 'bzr branch' creates a new branch copying from somewhere else. Doing what you said suggests you may have some confusion between 'bzr init' and 'bzr init-repo' | 22:57 |
| vishy | maxb: ah | 22:58 |
| vishy | i think you are correct | 22:58 |
| vishy | maxb: thanks for the help | 23:11 |
| jeremyw | Let's pretend I was a hosting company for Bazaar. If I understand correctly, 'bzr init-repo' will create a directory that will contain branches. 'bzr init' will create a directory that is a branch. It seems the former would let the users of the repository create/use as many branches as they want/need while the later will only allow one branch. Is this correct? | 23:16 |
| jeremyw | The more I think about it, the less it makes sense but I had to ask. | 23:16 |
| mkanat | jeremyw: Yep, you're right. | 23:17 |
| ddaa | jeremyw: well that's a way of seeing it | 23:24 |
| ddaa | bzr init-repo creates a shared repository | 23:25 |
| ddaa | bzr init (and bzr push, bzr branch, etc.) create a branch, if the branch is located in a shared repo, it will use the history store of the shared repo, instead of using a branch-specific store. | 23:26 |
| ddaa | IMO, whether you allow creation or one or multiple branches is not a property of init-repo | 23:26 |
| ddaa | However, using a shared repository has a strong impact on access contral. | 23:27 |
| jeremyw | I'm learning here so bear with me. I think the analogy of me being a Bazaar hosting tool makes the msot sense. The usage pattern I see is: You create a repositroy on the server and N number of users will access this repository by cloning it and pushing to it. | 23:27 |
| ddaa | well | 23:27 |
| ddaa | strictly speaking, in bzr you don't clone a "repository" | 23:27 |
| jeremyw | Well, you clone a branch. | 23:27 |
| jeremyw | So if I wanted to allow a repository to have N branches, I'd need a shared repository right? | 23:28 |
| ddaa | yup | 23:28 |
| ddaa | that's what shared mean | 23:28 |
| ddaa | "shared history store for multiple branches" | 23:28 |
| ddaa | not "shared by multiple users", that's an orthogonal kind of sharing | 23:28 |
| jeremyw | I got you. | 23:29 |
| ddaa | as a commercial hosting, you could also use stacked branches, and a custom bzr+ssh server that optimize new branch uploads without giving write access to everything to every user | 23:31 |
| ddaa | actually, that's exactly what launchpad does :-) | 23:31 |
| jeremyw | Nice...that's something I'll look into as well. | 23:36 |
| jeremyw | Well, I don't plan on being a Bazaar host but at the same time, the needs of my project were easier to explain that way. | 23:37 |
| ddaa | well, there's definitely a niche for "github for bzr" | 23:41 |
| ddaa | launchpad is too complicated and featurful/confusing for some people | 23:42 |
| jeremyw | When you have a shared repository, is there still a default branch? | 23:42 |
| ddaa | default branch? | 23:42 |
| ddaa | there's no such thing in bzr | 23:42 |
| jeremyw | Well, 'bzr init' creates a default branch doesn't it? | 23:42 |
| ddaa | no, it creates a branch | 23:42 |
| ddaa | I have no idea what you mean by "default branch" | 23:43 |
| jeremyw | Oh yeah...it's named the same as the parent dir. | 23:43 |
| jeremyw | Doh. | 23:43 |
| jeremyw | ddaa: I'm probably mixing terms here. My fault. | 23:43 |
| ddaa | well no, it's named the same as the directory of the branch | 23:43 |
| ddaa | because well, that's what the name of a branch is, the url of its directory | 23:43 |
| jeremyw | That's what I meant. Sorry. | 23:43 |
| ddaa | and no, bzr init-repo does not create branch at the root of the repository | 23:44 |
| ddaa | you could probably set up something like that, and it would probably work, but I'm not sure you can even achieve it using the command line, without moving stuff in and out of .bzr by hand | 23:45 |
| jeremyw | I wonder if a shared repository is necessary. Let's say I created a repository the same way 'bzr init' did. I could create another repository the same way and fill it with the contents of another branch riht? | 23:45 |
| jeremyw | So I wouldn't need to have a shared repository. | 23:46 |
| ddaa | yeah, we call that a "standalone branch" | 23:46 |
| ddaa | that's a branch with its own non-shared .bzr/repository | 23:46 |
| ddaa | the key object in bzr is the branch | 23:47 |
| ddaa | repositories are just support for branches | 23:47 |
| jeremyw | But you can still create a branch from another branch. | 23:47 |
| ddaa | why "still"? | 23:47 |
| ddaa | a shared repo is never necessary | 23:47 |
| jeremyw | Too many concurrent conversations. | 23:47 |
| ddaa | it's just a nice optimization | 23:48 |
| jeremyw | I got you. | 23:48 |
| jeremyw | Cool. | 23:48 |
| jeremyw | Well, this has been enlightening. | 23:49 |
| jeremyw | ddaa: I appreciate explaining things to me. | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!