| ronny | lifeless: im going to build the api's of the filesystem draft pep on top of hg, svn, bzr and git for viewing revisions/building commits | 00:00 |
|---|---|---|
| lifeless | to build a commit, use tree.commit() | 00:01 |
| ronny | thats what i use now | 00:01 |
| lifeless | or if you like, you can use branch.get_commit_builder, which is a lower level API; under some specific circumstances it would be easier (e.g.. if you have a delta to apply) | 00:02 |
| lifeless | I'm not sure what you mean when you say 'building commits' though | 00:02 |
| lifeless | generally, if you have a tree on disk, its just 'tree.commit("foo")' and you're done | 00:03 |
| lifeless | I don't really get why that requires /any/ bookkeeping | 00:03 |
| ronny | open a revision as a 'filesystem', do highlevel operations, commit the results | 00:03 |
| ronny | this is a repo op that doesnt involve workingtrees | 00:03 |
| ronny | for normal commits all i do is wt.commit | 00:04 |
| ronny | the workdir apis work quite well | 00:04 |
| ronny | now im dealing with creating and viewing history | 00:04 |
| lifeless | ok | 00:05 |
| lifeless | so for viewing history, the same readonly api as wt's have should work | 00:05 |
| lifeless | unless you're doing remote operations nearly any api will be plenty fast | 00:06 |
| ronny | i plan to keep a larger distinction betwen network ops and local ops | 00:07 |
| ronny | and i need to figure what the heck to do with bzr repos, they actually do matter in some situations | 00:08 |
| lifeless | if you want to be able to do arbitrary operations to create commits, MemoryTree should be fine - but it may be incomplete. Its a test helper, which, while correct, is not complete. It only does what we have needed it to do so far. | 00:09 |
| lifeless | TreeTransform - I am not extremely familiar with it, but it is the core workhorse for merge/revert/checkout style operations. | 00:09 |
| === verterok_ is now known as verterok | ||
| ronny | transform seemed pretty painfull to use | 00:10 |
| lifeless | Using a TreeTransform on top of a revisiontree has a commit method these days, and as long as you use bzr 1.18 there are good checks that the deltas it commits will be consistent | 00:10 |
| ronny | it seems to make absolutely no sense, and the implementation is quite scarry | 00:11 |
| lifeless | As I say I'm not extremely familiar with it. Its model is to assign a unique id for every operation in the transform, accumulate your changes, then check everything is consistent. | 00:11 |
| lifeless | There is some confusion between fileids (inodes) and transform ids (temporary to the operation) | 00:12 |
| lifeless | My tendancy, if I wanted to present a tree like interface, would be to improve MemoryTree | 00:12 |
| ronny | yeah, it seems more workable | 00:15 |
| jam | spiv: are you around? | 00:42 |
| === kiko is now known as kiko-afk | ||
| spiv | jam: I am. | 01:00 |
| poolie | hullo spiv | 01:00 |
| jam | hey spiv | 01:00 |
| spiv | poolie: good morning | 01:00 |
| jam | Just wanted to let you know that I'm interested in reviewing whatever you have for the inventory delta code | 01:01 |
| jam | (as I finally got the bundle stuff finished) | 01:01 |
| jam | I can review your last patch more thoroughly | 01:01 |
| jam | or you can resubmit something if you've had a chance to look at why it wasn't actually being active | 01:01 |
| lifeless | jam: I had a question | 01:02 |
| spiv | jam: review what I have, please. | 01:02 |
| lifeless | the serializer that you use, what format does it actually output? xml? | 01:02 |
| lifeless | [and if so, /which/ xml?] | 01:02 |
| jam | spiv: ok. I still know that it doesn't actually work, but I can look over the code assuming it does :) | 01:02 |
| spiv | jam: I'm digging into why it doesn't seem to be used today, but it shouldn't make a large difference to the patch... | 01:02 |
| jam | lifeless: xml v7 | 01:02 |
| jam | IIRC | 01:02 |
| lifeless | jam: Are you using CHKrepo._serializer.write_to_string ? | 01:03 |
| jam | it is fairly obvious in the patch, because I had to change away from being v5 | 01:03 |
| jam | lifeless: write_inventory_to_string, yes | 01:03 |
| lifeless | I have a proposal | 01:03 |
| lifeless | make that not work | 01:03 |
| lifeless | and instead make CHKRepository.get_inventory_xml work | 01:03 |
| lifeless | or at least, change the method to say that it gives xml | 01:04 |
| jam | as in documentation or as in changing it to | 01:04 |
| jam | write_inventory_to_xml_string | 01:05 |
| lifeless | CHKRepository wasn't meant to output xml ever | 01:05 |
| lifeless | so this is kindof a backdoor | 01:05 |
| lifeless | One I understand the need for, at least until we get a semantic delta based bundle | 01:05 |
| jam | right | 01:06 |
| lifeless | I think it would be good to make it more explicit about whats going on | 01:06 |
| jam | With spiv's code close to landing, I'd like to make a bundle which is a "GenericStream" | 01:06 |
| lifeless | and the method that seems clearest to me is the repo.*inventory_xml* set of functions | 01:06 |
| jam | which then knows how to stack on another repo, etc. | 01:06 |
| lifeless | jam: I think that would be lovely; I've wanted to do that for ages too :) | 01:06 |
| jam | lifeless: i suppose. Though the bundle code was already dealing with "target_format.serializer.write_inventory(source_format._serializer.read_inventory(bytes))" | 01:07 |
| jam | we need a reasonably efficient generic stream implementation, which I think Andrew is getting close to | 01:07 |
| lifeless | jam: its not clear that xml is involved there; I'd like it to be clear that it is xml. | 01:07 |
| jam | so I'm a bit concerned about the deprecation dance of introducing a different name for the same function | 01:08 |
| lifeless | Its up to you. | 01:08 |
| lifeless | I realise its not immediately-in-scope. | 01:08 |
| lifeless | that said, other folk who use this API will be surprised when huge amounts of IO are done to satisfy 'write_inventory_to_string' | 01:09 |
| jam | well, given that it is inherently a whole-tree operation | 01:11 |
| jam | regardless of whether it is XML or not... | 01:11 |
| lifeless | jam: well, its a thought | 01:15 |
| lifeless | ust trying to deter people from using it | 01:15 |
| jam | lifeless: so what we need is a code level "did you really mean to do this check". :) | 01:16 |
| jam | Issue a warning when vim saves the file | 01:16 |
| lifeless | that would be lovely | 01:18 |
| lifeless | perhaps a code test for uses of that function | 01:18 |
| spiv | We should rename get_bytes_as, I think. | 01:29 |
| lifeless | to? | 01:30 |
| spiv | Something else ;) | 01:31 |
| spiv | it returns more than bytes... | 01:31 |
| lifeless | it shouldn't | 01:32 |
| lifeless | it should always be returning a bytestring | 01:32 |
| spiv | It already returns lists of bytes ('chunked') | 01:32 |
| lifeless | mm | 01:32 |
| spiv | My inventory-delta patch further (ab)uses it to return inv deltas. | 01:32 |
| lifeless | oh | 01:32 |
| lifeless | I'd rather you didn't do that | 01:32 |
| lifeless | doing that doesn't fit with the layering | 01:33 |
| lifeless | If you'd like more bandwidth to discuss, we could have a call; I'd be extremely happy to help find a good home for the deserialisation call that is needed | 01:35 |
| spiv | Well, it wouldn't be a big deal to add a new method to just InventoryDeltaContentFactory. | 01:39 |
| lifeless | spiv: so CF are meant to be just about byte storage and transport | 01:39 |
| lifeless | you should pass the bytes they transfer to something that knows how to handle them | 01:39 |
| lifeless | IDCF sounds like a layering mistake in the first place | 01:40 |
| spiv | But for in-process streams I don't want to serialise down to bytes and back. | 01:40 |
| lifeless | right, so don't! | 01:41 |
| spiv | I'm not ;) | 01:41 |
| lifeless | it sounds like you'e using a byte transport mechanism though | 01:41 |
| lifeless | which is where the layers are confused. | 01:41 |
| spiv | Well, I'm using "record streams", which appear to actually be "content factory streams". | 01:42 |
| spiv | What mechanism would you expect? | 01:43 |
| lifeless | may I call? | 01:45 |
| spiv | lifeless: sure, but give me a minute | 01:46 |
| lifeless | record streams are for transfer of bytes | 01:46 |
| lifeless | inventory deltas have a in memory representation (though I was thinking we should make an object for them, just recently) | 01:47 |
| lifeless | when we stream inventory components using content factories, we are streaming ytes | 01:48 |
| lifeless | and we [de]serialise on both sides | 01:49 |
| spiv | lifeless: you can call now | 01:50 |
| EricInBNE | hihi....so what is the status of bzreclipse? | 02:39 |
| EricInBNE | eg - what doesnt it support | 02:39 |
| EricInBNE | (coming from a svn POV) | 02:40 |
| lifeless | EricInBNE: I'm not sure | 02:46 |
| lifeless | what does svn support ? :) | 02:46 |
| EricInBNE | commit, merge, show history, revgraph, revert, etc | 02:49 |
| EricInBNE | lifeless, BzrEclipse says: update supported (very basic) | 02:50 |
| EricInBNE | what does that mean | 02:50 |
| lifeless | I'm not sure - I don't use eclipse often | 02:51 |
| lifeless | folk do use it - you could drop guilherme an email if you need more detail than the wiki page has | 02:51 |
| EricInBNE | ah - it doesnt support authentication | 02:51 |
| EricInBNE | cheers | 02:53 |
| Jemsquash | Does anyone know when there is going to be an update for the bzr eclipse plugin so that it will work with the Galileo release? | 03:05 |
| lifeless | Jemsquash: I don't - could you file a bug on it? | 03:05 |
| Jemsquash | Yes I can. | 03:06 |
| poolie | it looks like the nightlies still don't have all the right extension libraries | 03:14 |
| poolie | i wonder if the releases are missing them too - that could cause some performance problems | 03:14 |
| poolie | anyhow putting head down now | 03:14 |
| lifeless | time for your nap? | 03:16 |
| poolie | nice idea | 03:16 |
| poolie | i'm going to dream of long release cycles | 03:16 |
| poolie | and drool a bit onto an editor | 03:16 |
| === timchen1` is now known as nasloc__ | ||
| === TDJACR is now known as NotTheDJ | ||
| === NotTheDJ is now known as NotADJ | ||
| lifeless | \o/ very close now | 04:27 |
| lifeless | dirstate children-of-removed-dirs + dirstate-C version to go, and we're golden | 04:27 |
| RenatoSilva | I've downloaded bzr 1.17-1 windows installer, but bzr version is reporting 1.17 (msising the "-1") | 04:32 |
| lifeless | thats correct | 04:32 |
| lifeless | the installer suffix is the installer suffix | 04:32 |
| lifeless | 1.17.1 would be 1.17.1-1 | 04:32 |
| RenatoSilva | ah ok | 04:33 |
| RenatoSilva | I'd never grok that | 04:33 |
| lifeless | if the installer has a bug you get 1.17-2 | 04:35 |
| lifeless | if bzr has a bug you get 1.17.1-1 | 04:35 |
| RenatoSilva | ok | 04:35 |
| RenatoSilva | how to list saved locations? I know I asked this before, but I can't recall | 04:36 |
| lifeless | bzr info? | 04:37 |
| RenatoSilva | thanks | 04:39 |
| RenatoSilva | now, I have a problem on applying a patch built with bzr send | 04:39 |
| RenatoSilva | ok solved | 04:41 |
| RenatoSilva | How to merge with a patch without having to commit? | 04:42 |
| RenatoSilva | I mean, imagine you commit 2 new revisions, then bzr send -o patch.diff, then in the target branch, you bzr merge patch.diff, but you get uncommitted changes. You have to commit something like "merge with xyz" | 04:44 |
| lifeless | thats right | 04:44 |
| RenatoSilva | But actually you just want to put the 2 new revisions in the top of the tree | 04:44 |
| lifeless | if you want that, do bzr pull | 04:44 |
| RenatoSilva | lifeless: thanks! | 04:53 |
| lifeless | EODing | 07:30 |
| crisb | hi, i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch | 08:22 |
| crisb | can anyone give me some pointers in order to figure out whats happening? | 08:22 |
| crisb | from the bzr.log i can see its running bzr check --branch http://localhost:47422 and returning "ERROR no branch found at specified location" - which seems to be the point of the test? | 08:26 |
| crisb | i can see from netstat that it seems to still be listening on that port but when i try bzr check myself i get "Unable to handle http code 504: Gateway Time-out" | 08:32 |
| crisb | should it still be listening at this point? | 08:32 |
| spiv | lifeless: btw, that mysql branch with the slow get_parent_map HPSS requests is 1.9: https://code.edge.launchpad.net/~mysql/mysql-server/mysql-next | 08:49 |
| AfC | Did the dotted revno numbering scheme change recently? I know jam and others have talked about it. | 08:52 |
| spiv | AfC: I don't think so. | 08:52 |
| AfC | Then I think that loggerhead thing on your launchpad site is buggy. | 08:53 |
| AfC | Someone [else] mentioned this URL when closing a bug http://bazaar.launchpad.net/~afcowie/java-gnome/mainline/revision/654.1.3 | 08:53 |
| AfC | that web page says "This revision was merged to the branch mainline in revision 654." | 08:54 |
| spiv | Hmm, odd. | 08:54 |
| AfC | but that's not true; this revision was merged to 'mainline' later, in 655 as it happens. | 08:54 |
| AfC | http://bazaar.launchpad.net/%7Eafcowie/java-gnome/mainline/revision/655 | 08:54 |
| AfC | note appropriate commit message. | 08:54 |
| spiv | Right, that does sound like a loggerhead bug. | 08:55 |
| spiv | Care to file it? Or I can do it if you like, I'm at the bug tracker atm anyway. | 08:55 |
| AfC | [I was hoping it was a case of "Bazaar upstream has changed numbering, but my bzr / bzr viz hasn't" but the commit messages give it away (even without comparing revids] | 08:55 |
| AfC | spiv: if you would | 08:55 |
| AfC | I'm about to step out | 08:55 |
| spiv | AfC: sure. | 08:55 |
| * AfC admits that he doesn't use loggerhead | 08:56 | |
| AfC | (or launchpad, for that matter) so I appreciate you confirming that this was a glitch. | 08:56 |
| spiv | Not a problem. | 08:57 |
| AfC | spiv: incidentally, now that those URLs are out there (apparently), should bzr change its dotted revno scheme, then you might want to consider changing the URL scheme in use above, perhaps to http://bazaar.launchpad.net/~afcowie/java-gnome/mainline/revno/655.1.3 or something | 08:58 |
| AfC | just something to mull over | 08:59 |
| AfC | (or put in a wizard mod_rewrite rule, or...) | 08:59 |
| spiv | lifeless: ah, the slow get_parent_map is probably the C extension regression bialix just reported! | 09:00 |
| spiv | Yeah, that's true. We'll definitely need to tread carefully if we do change the scheme to avoid too many disruptions. | 09:00 |
| spiv | Silently giving different pages would probably be worse than 404ing, too. | 09:01 |
| AfC | spiv: at the end of the day, this is what HTTP 301 Moved Permanently is for; if you had some code that understood both schemes then you could use a redirect like that (ie 301 from .../revision/654.1.3 to .../revno/655.1.3/ in this contrived example) | 09:05 |
| AfC | spiv: [we just went through that when we moved our blog] | 09:06 |
| === AfC is now known as AfC|out | ||
| spiv | The revision/... scheme also allows revids, so just changing "revision" to "revno" in the URL might not be quite right. Just "rev" might do, though. | 09:08 |
| spiv | AfC|out: https://bugs.edge.launchpad.net/loggerhead/+bug/405686, btw | 09:09 |
| ubottu | Launchpad bug 405686 in loggerhead "Revision page for a dotted revno has incorrect "was merged into" revision" [Undecided,New] | 09:09 |
| spiv | AfC|out: thanks for the report. | 09:09 |
| AfC|out | spiv: sure. Glad I noticed. Just a little glitch. | 09:11 |
| ronny | lifeless: aware of any bts for subvertpy? i have it crashing my unittests here and jelmer is missing | 09:36 |
| luks | https://bugs.launchpad.net/subvertpy ? | 09:37 |
| ronny | ok, im blind and need coffee | 09:37 |
| crisb | i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch can anyone give me some pointers in order to figure out whats happening? | 09:42 |
| spiv | crisb: I'd love to but I'm about to log off for the day :( | 09:43 |
| spiv | crisb: hopefully someone else will turn up soon, otherwise you can file a bug or post to the list. | 09:43 |
| crisb | spiv: cheers :) | 09:49 |
| Kinnison | Is there an easy way to alter my whoami information based on which directory I'm in? | 09:52 |
| Kinnison | e.g. to have ~/work say "Daniel Silverstone <dsilvers@simtec.co.uk>" but ~/personal be "Daniel Silverstone <dsilvers@digital-scurf.org>" ? | 09:52 |
| spiv | Kinnison: yes | 09:53 |
| Kinnison | spiv: can I ask for a pointer to the right bit of docs, or else an example? | 09:53 |
| spiv | Kinnison: put an "email = Daniel Silverstone <dsilvers@simtec.co.uk>" line in a [/home/dsilvers/work] section of ~/.bazaar/locations.conf | 09:53 |
| spiv | And similarly for ~/personal, of course :) | 09:54 |
| Kinnison | thanks | 09:54 |
| spiv | I do exactly that myself. Well, with slightly different directories and identities ;) | 09:54 |
| Kinnison | oddly | 09:54 |
| Kinnison | :-) | 09:55 |
| poolie | spiv, nice catch there | 10:40 |
| poolie | :) hello kinni | 10:40 |
| crisb | i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch can anyone give me some pointers in order to figure out whats happening? | 10:59 |
| jelmer | abentley, hi | 11:42 |
| jelmer | abentley: "bzr shell" currently repeats the previous command on empty commands, that's intentional I presume? | 11:42 |
| spiv | poolie: bialix caught it, originally. | 11:55 |
| spiv | (assuming you mean the broken C extension import) | 11:55 |
| bialix | accidentally | 11:57 |
| Kinnison | poolie: hihi | 11:57 |
| ronny | jelmer: found the issue | 11:57 |
| jelmer | ronny, cool, what was it? | 11:58 |
| ronny | jelmer: appearantlz svn does an abort if the path in get_file starts with a / | 11:58 |
| bialix | jelmer: IIUC it's default behavior of std python cmd lib | 11:58 |
| jelmer | ronny: subvertpy should be taking care of that | 11:58 |
| jelmer | ronny, perhaps we don't yet in that particular situation | 11:58 |
| ronny | well, now you know, so it will get fixed | 11:58 |
| jelmer | ronny: What version of subvertpy are you using? | 11:58 |
| ronny | jelmer: im tracking your bzr version | 11:59 |
| jelmer | ronny, we're already canonicalizing | 12:00 |
| jelmer | ronny, hence my question about what version you are running | 12:00 |
| jelmer | ronny, actually, I can reproduce it now - thanks | 12:01 |
| SiDi | Hello. I'm trying to push to a lp bzr repo from behind a proxy using corkscrew, and i'm getting this error : bzr: ERROR: Connection closed: please check connectivity and permissions. Any idea what this means ? :/ | 12:11 |
| amanica1 | SiDi: its trying to go through ssh | 12:12 |
| amanica1 | which is probably blocked by your proxy | 12:12 |
| amanica1 | I mean it doesn't try to go through the proxy, and is blocked by your firewall | 12:13 |
| spiv | SiDi: the TCP connection is being closed (or failing to connect?) on bzr | 12:13 |
| SiDi | Alright | 12:13 |
| SiDi | So i'm doing something wrong, i guess :/ | 12:14 |
| spiv | Push to lp is via ssh, as amanica1 says. | 12:14 |
| amanica1 | I'm not sure if lp supports pushing over bzr+https | 12:14 |
| awilkins | SiDi: You need to ask your network admin to open port 22 for you | 12:14 |
| spiv | So if you can ssh bazaar.launchpad.net, bzr should work. | 12:14 |
| spiv | amanica1: not yet, unfortunately | 12:14 |
| spiv | if "ssh bazaar.launchpad.net" doesn't work (even with your lp username added), then bzr can't work either. | 12:15 |
| SiDi | awilkins: my network admin is a guy who thinks a QoS allowing 3KB/Sec when there are 6MB available and 100 people on the network (and its a residence, not an office) is a good idea :p | 12:16 |
| SiDi | ok thanks for the infos | 12:17 |
| SiDi | Im gonna stab my network admin >_> | 12:17 |
| ronny | jelmer: you got twitter by any chance? | 12:30 |
| jelmer | ronny, yeah, http://twitter.com/ctrlsoft | 12:30 |
| ronny | k | 12:35 |
| luks | jelmer: wow, I've just seen the svn send format. thanks a lot for finishing that! | 12:40 |
| abentley | jelmer: Actually, I think it's the default behaviour. But I'm okay with changing it to do nothing, like bash. | 12:48 |
| jelmer | luks: No problem, thanks for starting that. | 12:57 |
| jelmer | luks, I've also done a "bzr send --format=git" based on the svn send format | 12:57 |
| jelmer | luks, Which creates "git am"-compatible patches, although as one concatenated file at the moment rather than individual attachments. | 12:58 |
| jelmer | abentley: Thanks - I'll file forward the Debian bug then. | 12:58 |
| lifeless | jelmer: what does the svn send format do? | 13:03 |
| jelmer | lifeless, send svn-like diffs without bzr-specific metadata | 13:04 |
| jelmer | lifeless: Including mentioning the svn revision numbers that the delta's of individual files are against | 13:05 |
| lifeless | cute | 13:05 |
| === mrevell is now known as mrevell-lunch | ||
| === abentley1 is now known as abentley | ||
| thekorn | hi, is there a release of bzr-gtk somewhere for jaunty (ideally in a PPA) which works with bzr 1.17? | 14:16 |
| thekorn | I get a lot of messages like """Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0)""" when using bzr from the ~bzr team ppa | 14:17 |
| === mrevell-lunch is now known as mrevell | ||
| === abentley1 is now known as abentley | ||
| jelmer | LarstiQ, ^ | 14:38 |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === nevans1 is now known as nevans | ||
| OllieR | Is it normal for bzr to be uploading 3000kb to commit a one character text change? | 15:35 |
| === hal_away is now known as hal | ||
| * dobey pleas for help | 16:10 | |
| bialix | OllieR: perhaps your commit triggers repack | 16:10 |
| OllieR | bialix: what on earth does that mean? | 16:11 |
| bialix | are you aware of `bzr pack`? | 16:11 |
| bialix | current repository formats store committed data in the form of "packs" | 16:13 |
| bialix | every new commit add new "pack" | 16:13 |
| bialix | when there is many pack files in repository it should be repacked otherwise things become slower than needed | 16:13 |
| bialix | commit or push or pull can trigger automatic repack of repository | 16:14 |
| === kiko-afk is now known as kiko | ||
| bialix | unfortunately in remote repo case bzr do repack on client side, i.e. it has to download big amount of data, repack it into single file and upload it back | 16:15 |
| bialix | OllieR: hth | 16:15 |
| bialix | repacking on server side should be implemented in recent bzr versions, but I don;t know for sure | 16:16 |
| bialix | dobey: if you want to ask it's better to just ask in IRC. somebody will answer or not | 16:17 |
| awilkins | It repacks server side as long as you're using a smart protocol | 16:19 |
| bialix | I suppose it was fixed recently | 16:20 |
| awilkins | Dumb protocols... I think it still repacks over the wire. Which is a bummer when your dumb protocol is a windows fileshare over VON | 16:20 |
| awilkins | VPN | 16:20 |
| bialix | why it's bummer? | 16:21 |
| awilkins | Because VPN is slow | 16:21 |
| awilkins | (well, over my 512Kbit/s upload, repacking a 70MB repo is | 16:21 |
| awilkins | I usually get someone in the office to do a repack locally before I touch it if I see the packing start | 16:21 |
| fullermd | NEWS says the server-side autopack was in 1.9, so it's been around a while (doesn't help on dumb transports of course, but not much does) | 16:22 |
| dobey | bialix: yeah. i'm just trying to understand what to ask, because i'm not sure if it's a bzr issue or a lp issue | 16:22 |
| bialix | may be some sort of server-side daemon that repack onsite will help with VPN? | 16:22 |
| awilkins | bialix: That would be a reasonable idea. I call it "users". | 16:23 |
| bialix | haha | 16:23 |
| dobey | but basically, i can't seem to push a branch to launchpad successfully that is stacked on a 2a branch | 16:23 |
| fullermd | "bio-cron" :p | 16:23 |
| awilkins | It would be nice.... we serve some of the branches out of an IIS box and sometimes I think it would have been nice to just have that since it has a smart server. | 16:23 |
| bialix | Neo: the Matrix has you... | 16:24 |
| eydaimon | bzr plugins lists blow 1.11 | 16:25 |
| eydaimon | Loggerhead web viewer for Bazaar branches. | 16:26 |
| eydaimon | but when I do bzr serve --htt[ | 16:26 |
| eydaimon | http evenI get errors | 16:26 |
| awilkins | I'm currently racking my brains thinking about porting Mercurial pbranch to Bazaar.... there must be an easier way than reading the pbranch.py file and trying to trans-code it to bzrlib | 16:26 |
| eydaimon | bzr help blow does say This provides a new option "--http" to the "bzr serve" command, that ... | 16:26 |
| bialix | pbranch instead of loom? | 16:29 |
| bialix | awilkins: is not bzr-pipeline is another alternative to loom? | 16:32 |
| ronny | jelmer: what are the plans for doing all lower level workdir operations of git in dulwich? | 16:34 |
| eydaimon | what's the easiest way to track one particular file and see revisions only for that file? | 16:36 |
| eydaimon | I don't want to have to do bzr log on it, check revision, and keep doing diffs by hand. it's tedious | 16:37 |
| bialix | bzr log FILE? | 16:43 |
| eydaimon | as I said, bzr log only tells me that the file has changed | 16:44 |
| eydaimon | I'd easily like to be able to navigat the revisions and see what has changed | 16:45 |
| eydaimon | which means bzr log FILE ... look... bzr diff revno... bzr log FILE ... look ... bzr diff other_revno... etc | 16:45 |
| abentley | eydaimon: log can also show diffs, if you want. | 16:45 |
| === abentley is now known as abentley-lunch | ||
| awilkins | bialix: bzr-pipeline is stacked branches, like loom | 16:46 |
| eydaimon | ok, thanks | 16:46 |
| bialix | bzr log -p FILE | 16:46 |
| awilkins | bialix: I have two ways to what I want ; add parallel featues to pipeine or port pbranch | 16:46 |
| bialix | or bzr qlog FILE ;-) | 16:46 |
| bialix | I have not tried pipeline yet, but from abentley announce I was under impression it's more than stacked branches | 16:47 |
| eydaimon | the annoying thing is I have to keep track of all the revisions since I only want to look at what's changed between them | 16:47 |
| * awilkins pulls the latest version of bzr-pipline | 16:48 | |
| dobey | guess it's a lp issue mostly | 16:49 |
| lllama | Hello everyone. I've started making some changes to a program that I'd now like to work on as a branch. I've yet to commit the stuff I've changed, so was wondering what the best way would be to go about doing this. | 16:49 |
| awilkins | lllama: Are you working in a free standing branch or a checkout? | 16:50 |
| lllama | awilkins: checkout | 16:52 |
| lllama | awilkins: but I can unbind if required. | 16:53 |
| awilkins | lllama: If you unbind, you are now working in a branch - you might want to do `bzr nick project.fix-my-bug` or another sensible name before you commit. | 16:54 |
| awilkins | lllama: I tend to work with a local no-trees repository containing all the related branches I'm working on, and use lightweight checkouts and `bzr switch` to move between them. | 16:56 |
| awilkins | lllama: Other people make their parent folder a shared repository, and keep a "trunk" checkout for merging, and branch from that for work packages. | 16:57 |
| lllama | awilkins: Interesting. I've got a remote no-trees repo, so I could look into something similar. | 16:57 |
| lllama | awilkins: If I unbind though can I copy the dir (keeping the uncommited changes as a result) and then revert the existing branch to back them out? | 16:58 |
| awilkins | You should be able to do that, yes | 16:59 |
| awilkins | Or branch your existing folder to your new "trunk" branch | 16:59 |
| awilkins | e.g. cd .. ; bzr branch work trunk ; cd work ; bzr commit -m "My Changes" | 16:59 |
| awilkins | (presuming "work" is the existing folder with changes in it" | 17:00 |
| === hal is now known as hal_away | ||
| lllama | I tried that but I don't get the uncommited changes in the new branch (natch). Just wondering whether there's a better procedure. I could do with a little rethink of my repo layout methinks. It's a little flat ATM.. | 17:02 |
| awilkins | lllama: You keep the old folder as your work branch, and the new one is your "trunk" branch | 17:02 |
| awilkins | lllama: The not-getting-the-changes is intentional in this case :-) | 17:03 |
| lllama | awilkins: of course. Thanks for the help. I'll look into 'switch' as well. | 17:06 |
| awilkins | lllama: You're welcome | 17:07 |
| === JamalFanaian is now known as JamalFanaian|afk | ||
| ronny | lifeless, awilkins: btw, if bzr is basically inode based, shoudn't there be a rather simple way to expose commit building/tree changing as if it was a posix fs | 17:37 |
| awilkins | ronny: Not sure about that, I think Subversion is sort of like that but I have the impression that the undergarments of Bazaar are rather different | 17:39 |
| LarstiQ | jelmer: hmm? the context of that '^' was a bit scarce | 17:40 |
| ronny | well, i'll gradually put complete in-memory filesystems on top of hg, bzr, svn and git based on the api"s of the fraft spec for the new filesystem apis | 17:40 |
| ronny | *draft | 17:40 |
| jelmer | LarstiQ, sorry | 17:40 |
| jelmer | LarstiQ, somebody was asking about bzr-gtk in the PPA's | 17:40 |
| jelmer | LarstiQ, are you doing those or johnf? | 17:40 |
| LarstiQ | jelmer: I haven't been doing them | 17:41 |
| LarstiQ | jelmer: it seems you and jam have, I can pick those up | 17:42 |
| LarstiQ | jelmer: although I'm not really a user of bzr-gtk nowadays | 17:42 |
| jam | LarstiQ: bzr-gtk hadn't done a release in long enough, that I don't think anyone was doing them :) | 17:43 |
| franck_ | hello there, does anybody know how to use the --nested options ??? | 17:43 |
| franck_ | i can't find the option with 1.3 and 1.17 release (ubuntu jaunty) | 17:43 |
| * LarstiQ heads out | 17:48 | |
| === abentley-lunch is now known as abentley | ||
| === kiko is now known as kiko-fud | ||
| abentley | franck_: I think you're talking about features that are still in the planning phase. | 18:14 |
| abentley | awilkins: I'm open to supporting parallel pipes, I just haven't really needed it. | 18:23 |
| awilkins | abentley: I'm scratching my head ans starting at a pipe called "parallel" ATM :- | 18:24 |
| awilkins | staring | 18:24 |
| awilkins | I don't think the Mercurial lot are 100% decided on what to do either, it's clear that people want features like this but they've notarrived at the mbest way to do it yet. | 18:25 |
| awilkins | I found a page where they compare 4 ways of doing it. And pbranch credits loom for inspiration! | 18:26 |
| awilkins | http://mercurial.selenic.com/wiki/PatchHandlingUnificationRFC | 18:27 |
| awilkins | I think the worst thing is that "get_(next|prev)_pipe" becomes a bit awkward instantly | 18:28 |
| awilkins | They just resort to moving around on names only | 18:28 |
| franck_ | abentley: ok it's that i've seen with more search on mailing list, by the way do you know a good method in order to merge already versionned branches within a new versioned project, i need that cause i got some libraries wich are managed via bzr, but i can't add them only if i delete .bzr folder within module... | 18:39 |
| awilkins | franck_: `bzr help join` ? | 18:40 |
| franck_ | awilkins: many thanks i haven't seen that, i'm gonna try it ! | 18:41 |
| === hal_away is now known as hal | ||
| macinjosh | I'm new bazaar can i ask a question? | 19:04 |
| macinjosh | I've read a lot of documentation and cannot find an answer | 19:05 |
| macinjosh | I have a repository on a web server with a checkout that are the files actually being served as as a website, if another developer changes those files being served is there a way to commit those changes? | 19:06 |
| LarstiQ | macinjosh: `bzr commit`? I'm not sure what you're asking | 19:07 |
| macinjosh | well i only have FTP access | 19:07 |
| macinjosh | I do not have shell access to this server | 19:08 |
| awilkins | macinjosh: you can commit via FTP but it's not the ultimate in effciency | 19:08 |
| LarstiQ | macinjosh: preferably, imo, you would not edit at the website, but only deploy to it | 19:09 |
| awilkins | macinjosh: And note that this does not necessarily change the working tree on the server to match your commit | 19:09 |
| macinjosh | yeah I realize that, we're working with a web designer who doesn't use or want to user version control :-( | 19:09 |
| macinjosh | I've tried this: bzr commit ftp://josh@mywebserver.com | 19:10 |
| macinjosh | and i get this error bzr: ERROR: Path(s) are not versioned: "ftp:/josh@mywebserver.com" | 19:10 |
| awilkins | macinjosh: Does the tree correspond to the root of the FTP home on the server? | 19:11 |
| macinjosh | yes the .bzr folder is at the root of the FTP home | 19:12 |
| awilkins | macinjosh: Oh, hang on, you're trying to commit that file | 19:12 |
| awilkins | macinjosh: You want to commit the changes to the folder, remotely, via FTP? | 19:12 |
| awilkins | macinjosh: Which OS are you using as your client? | 19:13 |
| macinjosh | yes, but not changes to the .bzr folder if thats what you are thinking. The changes would be in versioned folders like public_html | 19:13 |
| macinjosh | im on mac os x, the server runs redhat | 19:13 |
| macinjosh | these are the files/directories in the FTP home .bzr .bzrignore public_html views www models | 19:16 |
| macinjosh | changes will be made in public_html views www and models | 19:16 |
| LarstiQ | macinjosh: can you ssh into the server, and run bzr there? | 19:16 |
| LarstiQ | macinjosh: the checkout needs to be updated anyway | 19:17 |
| macinjosh | in need to commit those from my machine into the repository in .bzr | 19:17 |
| macinjosh | no i don't have shell access (its a shared server) | 19:17 |
| awilkins | macinjosh: The only other way to do it I can think of is ... i) run a smart server on the server ii) mount the folder into your local filesystem | 19:17 |
| macinjosh | ok, thanks | 19:18 |
| macinjosh | you've been helpful. bye | 19:18 |
| === ja1 is now known as jam | ||
| === kiko-fud is now known as kiko | ||
| === hal is now known as hal_away | ||
| reggie | hey bzr devs | 19:53 |
| reggie | i just branched 4 svn branches into bzr and uploaded them to lp. now I need to inform bzr that they are fully merged | 19:53 |
| reggie | is null-merge the only way to do that? | 19:53 |
| jelmer | reggie, full merged in what sense? | 19:54 |
| jelmer | reggie, and what do you mean by null-merge? | 19:54 |
| reggie | well, since svn doesn't support true merging, in the sense that newer branches have the changes I want them to have from older branches | 19:54 |
| reggie | null merge meaning do the merge and then revert the changes | 19:55 |
| reggie | and since the merge from one branch to another will likely find all sorts of conflicts and I'm going to revert them anyway, I can just tell bzr to merge it "any way it can" right? | 19:56 |
| * LarstiQ blinks | 19:57 | |
| === JamalFanaian|afk is now known as JamalFanaian | ||
| beuno | poolie, let me know when you're around | 20:17 |
| LarstiQ | reggie: if the branches share ancestry, then merge will know about merged changes, and not bork on lines already being added | 20:21 |
| === CardinalFang is now known as Guest3645 | ||
| === hal_away is now known as hal | ||
| lifeless | moin | 21:16 |
| agrippa | any idea when https://bugs.launchpad.net/bzr/+bug/98836 will be fixed? | 21:27 |
| ubottu | Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] | 21:27 |
| === hal is now known as hal_away | ||
| lifeless | agrippa: likely after 2.0; it is very important to us to fix | 21:35 |
| lifeless | but the core devs have a full plate already | 21:35 |
| agrippa | lifeless: When will 2.0 be? | 21:35 |
| lifeless | very soon :) | 21:36 |
| agrippa | lifeless: Can't use bzr on any of our Windows shares, and all we have are Windows file servers :( | 21:36 |
| lifeless | agrippa: :( | 21:36 |
| lifeless | agrippa: bzr only uses OSLocks on the working tree copy | 21:36 |
| agrippa | lifeless: And git is good and all, but our designers here will not like it | 21:36 |
| agrippa | lifeless: And I like bzr's compatibility with opendiff | 21:37 |
| agrippa | and comparing revisions is easy since I don't have to type in a stupid hash | 21:37 |
| lifeless | agrippa: you should be able to use bzr by using either checkouts from a central branch, or local branches on each machine | 21:37 |
| agrippa | lifeless: Well, I've had no such luck on this version on OS X 10.5.7 | 21:41 |
| agrippa | lifeless: bzr co, bzr status, bzr init, bzr branch won't work | 21:43 |
| lifeless | agrippa: is the location you're checking out to on the server, or on the local disk? | 21:44 |
| agrippa | agrippa: local disk | 21:44 |
| lifeless | agrippa: then its not bug 98836 :) | 21:44 |
| ubottu | Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836 | 21:44 |
| agrippa | lifeless: Hmm, could be something else? I found a similar bug that was marked a duplicate of 98836 that matched my issue | 21:45 |
| agrippa | lifeless: I am also getting the Errno 45 | 21:45 |
| lifeless | which dup were you looking at? | 21:46 |
| agrippa | lifeless: This is the one I originally found: https://bugs.launchpad.net/bzr/+bug/31006 | 21:48 |
| ubottu | Launchpad bug 31006 in bzr "dirstate file locking doesn't work on smb mount on osx - bzr add, bzr status, and bzr commit fail over a SMB share (dup-of: 98836)" [High,Confirmed] | 21:48 |
| ubottu | Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] | 21:48 |
| lifeless | so, that is on an smb mount | 21:48 |
| lifeless | but you just said you were checking out onto local disk | 21:48 |
| agrippa | Yeah | 21:48 |
| agrippa | Well, onto local disk, from an smb mount | 21:49 |
| lifeless | does the source have a working tree itself? | 21:49 |
| lifeless | (If you just created it by doing bzr init, or bzr branch, then it probably does) | 21:50 |
| agrippa | I believe so, I originally created a repo from a Windows machine with bzr init and then tried checking out from OS X | 21:51 |
| lifeless | o | 21:51 |
| lifeless | ok | 21:51 |
| agrippa | then I added all the files in there and committed | 21:51 |
| lifeless | so, here's whats happening | 21:51 |
| lifeless | [I think] | 21:52 |
| lifeless | a backtrace would help diagnose to be sure. | 21:52 |
| lifeless | I think bzr is trying to read lock the source tree, to read its files from disk | 21:52 |
| reggie | thanks everyone who responded. I got my merge all fixed up | 21:52 |
| lifeless | this isn't particularly helpful in your case | 21:52 |
| agrippa | How do I do a backtrace? | 21:53 |
| lifeless | so, if you don't need the working copy on that central branch, running (from the machine that created it), 'bzr remove-tree', will get rid of the source tree and files, and then bzr won't try to lock it | 21:53 |
| lifeless | run with -Derror | 21:53 |
| === JamalFanaian is now known as JamalFanaian|afk | ||
| lifeless | kfogel: bug 405595 - you might like to weigh in with your opinion | 21:55 |
| ubottu | Launchpad bug 405595 in bzr "bzr-svn on Windows does not support Subversion 1.6 format" [Undecided,New] https://launchpad.net/bugs/405595 | 21:55 |
| agrippa | lifeless: Do you want me to run that on the repo located on the Samba share? | 21:56 |
| lifeless | agrippa: yes | 21:56 |
| agrippa | Alright | 21:56 |
| kfogel | lifeless: I have no strong opinion; either solution seems fine for now, though eventually the auto-upgrade seems like the right thing to do. | 22:03 |
| agrippa | lifeless: Want me to paste the output into here? | 22:06 |
| lifeless | agrippa: sure, or a pastebin | 22:18 |
| agrippa | http://pastebin.com/m718a691f | 22:19 |
| lifeless | agrippa: you need to run this from a machine that is working :) | 22:20 |
| lifeless | agrippa: or are none of them working? | 22:21 |
| agrippa | Oh, I can do that too | 22:21 |
| beuno | lifeless, re: bug 405972 | 22:21 |
| ubottu | Launchpad bug 405972 in bzr "Pushing a new stacked branch to the Launchpad project does 18 VFS calls" [Undecided,New] https://launchpad.net/bugs/405972 | 22:21 |
| lifeless | beuno: yes | 22:21 |
| beuno | I see 2 VFS calls for branches with tags | 22:21 |
| beuno | not 18 | 22:21 |
| beuno | which is why I filed that bug | 22:21 |
| lifeless | beuno: yes, and no | 22:22 |
| lifeless | beuno: do to any vfs calls takes about 16 calls in setup | 22:22 |
| beuno | :) | 22:22 |
| lifeless | its why doing any vfs based operations is so expensive | 22:22 |
| lifeless | we have to read .bzr/branch-format, .bzr/branch/format, .bzr/repository/format, .bzr/branch/branch.conf, .bzr/repository/pack-names, etc etc | 22:22 |
| beuno | I see | 22:23 |
| beuno | why do I only see 1 or 2 VFS calls sometimes then? | 22:23 |
| lifeless | beuno: if you enable the back-trace-on-vfs stuff, which we had enabled previous | 22:23 |
| lifeless | you'd see that the backtrace for the earlier vfs calls comes from tags.set_tags_dict, or something like tat | 22:24 |
| beuno | lifeless, sure, what knob do I have to twirl to do that? | 22:24 |
| lifeless | beuno: -Dhpssvfs | 22:24 |
| lifeless | or set that in your config | 22:24 |
| beuno | thanks | 22:25 |
| beuno | I already have hpss | 22:25 |
| lifeless | it was on by default, but folk felt it was too noisy | 22:25 |
| beuno | I'll add vfs | 22:25 |
| beuno | let's try this again then with that enabled | 22:26 |
| lifeless | this will produce a backtrace at the point vfs access is triggered | 22:26 |
| beuno | yeah, I remember those | 22:27 |
| beuno | they sure where noisy, but if it helps pin point the issues and someone is working on it, it's good noise :) | 22:27 |
| beuno | hrm, with hpssvfs, it doesn't give me the counts | 22:28 |
| beuno | lifeless, http://paste.ubuntu.com/235454/ | 22:29 |
| beuno | it does seem to go through tags | 22:29 |
| agrippa | don't know if I got anything useful for you lifeless | 22:31 |
| lifeless | agrippa: well if the command worked, your mac checkout should work now | 22:32 |
| agrippa | http://pastebin.com/m6d29d96d | 22:32 |
| lifeless | agrippa: try checking out on your mac machine again now | 22:33 |
| lifeless | beuno: thus, its tags :) | 22:33 |
| agrippa | with branch or co? | 22:33 |
| lifeless | agrippa: either | 22:33 |
| lifeless | beuno: hpssvfs and hpss are separate flags; they don't imply each other | 22:34 |
| agrippa | lifeless: Wow, that worked. | 22:35 |
| lifeless | agrippa: you just need to make sure your branches on the mount don't have trees, and it should keep working | 22:35 |
| beuno | ah | 22:36 |
| beuno | thanks lifeless | 22:36 |
| beuno | do you know when spiv's branch is landing? | 22:36 |
| lifeless | yes, but it doesn't matter | 22:36 |
| lifeless | the right question is 'when will launchpad be running with spiv's branch' | 22:37 |
| agrippa | lifeless: So is this a bug or just the way bzr works? | 22:37 |
| lifeless | agrippa: needing OS Locks is a design defect we'll be fixing. Using them at the moment is situation-normal. | 22:37 |
| lifeless | agrippa: we made the [wrong] assumption that OS locks were in fact a reasonable and reliable tool to use. | 22:37 |
| agrippa | lifeless: So in the future, it should be possible to have trees on the mount? | 22:39 |
| lifeless | agrippa: yes, once we fix the bug about OS Locks | 22:41 |
| agrippa | lifeless: Thanks a bunch, man. I think I might be able to get my coworkers to start with Bazaar soon enough then. I'm tired of flashFile1000000.flah | 22:42 |
| poolie | beuno, hi, i'm here now | 22:44 |
| beuno | poolie, hi | 22:44 |
| lifeless | agrippa: cool. Please do drop in with any more questions, there is usually someone around. | 22:44 |
| beuno | poolie, want to talk about the website today? | 22:45 |
| poolie | yes, very much | 22:45 |
| poolie | i was hoping to catch kiko first... | 22:45 |
| beuno | poolie, sure, I'm on the hpone now anyway | 22:45 |
| lifeless | the hpone eh | 22:50 |
| poolie | like an iphone but better | 22:51 |
| poolie | lifeless/spiv, are these "%d byte part read" things really necessary? | 22:52 |
| poolie | they use a lot of space... | 22:52 |
| lifeless | poolie: turn off -Dhpss :P | 22:57 |
| lifeless | (yes, I think they are. We want to gather detailed data when people are gathering data) | 22:58 |
| awilkins | lifeless: Are OS locks going to be removed for 1.18 ? | 22:58 |
| awilkins | lifeless: Or 2.0 ? | 22:59 |
| lifeless | awilkins: no | 22:59 |
| lifeless | probably no | 22:59 |
| poolie | awilkins: only if you send a patch :) | 22:59 |
| awilkins | Waah | 22:59 |
| awilkins | Shelve just doesn't work on Windows until you kill them off | 22:59 |
| poolie | lifeless: making things so verbose that people turn them off is missing the point | 22:59 |
| poolie | my question really is, what kind of thing do they help you debug? | 23:00 |
| awilkins | Which means no pipeline or anything else that needs shelf to work | 23:00 |
| poolie | john had some kind of patch towards addressing that particular problem | 23:00 |
| poolie | i think it was hard to refactor transform(?) to fix it | 23:01 |
| awilkins | poolie: Yes, last commit to the lp mirror of that was in February AFAIR | 23:01 |
| poolie | therefore he stopped | 23:01 |
| lifeless | poolie: the command line output is very minimal | 23:02 |
| poolie | i think that is an improvement to the code but it's arguably better to change the locking model to avoid the whole thing | 23:02 |
| poolie | the .bzr.log output is definitely not | 23:02 |
| lifeless | poolie: how many people are really looking in .bzr.log all the time? | 23:02 |
| awilkins | OS locks have never been a good idea, they are just to inconsistent | 23:02 |
| awilkins | I remember maintaining code that used semaphores specifically for that reason | 23:03 |
| lifeless | poolie: I want to be able to say to someone who files *any* bug based on the command line output of -Dhpss: 'please attach the log from that run', and get enough detail to identify and fix it | 23:03 |
| awilkins | Anyway, sleepytime | 23:03 |
| poolie | awilkins: that's great, i thought the same thing, but... | 23:03 |
| poolie | lifeless: right therefore my question about what kind of bug that helps with | 23:04 |
| lifeless | poolie: I don't think I saw that question | 23:04 |
| awilkins | Maybe I'll look at it on the train tomorrow (not that it'll do much good :-) ) | 23:04 |
| poolie | 08:00 poolie: my question really is, what kind of thing do they help you debug? | 23:08 |
| poolie | lifeless: ^^ | 23:08 |
| lifeless | poolie: They have helped in the past find interactions between buffer layers | 23:09 |
| lifeless | like the TCP ack/psh issue | 23:09 |
| poolie | by, say, showing that it starts reading tiny little buffers? | 23:09 |
| lifeless | yes | 23:09 |
| lifeless | do we need them every time? no | 23:09 |
| lifeless | unfortunately, I can't say when we will need them in advance :(. It may be that spiv who has done much more networking over the last few months will say 'I haven't looked at these for ages, we can dump them' | 23:10 |
| poolie | k thanks | 23:10 |
| lifeless | however, in terms of bug round trips, I really prefer a single large debug hammer to repeated incrementally larger requests | 23:11 |
| lifeless | if what you really want is to know when bzr does lots of round trips, perhaps we could give you [and other folk that want a feel] a dedicated ui-only reporting flag | 23:12 |
| lifeless | -Dnosy :P | 23:12 |
| poolie | possibly for bug reports we want -Deverything | 23:13 |
| lifeless | (which could show a range of different summary numbers) | 23:13 |
| poolie | oh i see we do already have -Dhpssdetail | 23:17 |
| poolie | i thought we might | 23:17 |
| === nevans1 is now known as nevans | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!