| NfNitLoop | there are a few others. Glosi, volapuk, ido, interlingua... | 00:00 |
|---|---|---|
| NfNitLoop | Klingon. ;) | 00:00 |
| jam | I was thinking you should learn Arabic, because then people can't pretend that they can read what you write | 00:01 |
| jam | Or have the characters installed on their system (yet) | 00:01 |
| Odd_Bloke | Pfft, Elvish is just as good for that. | 00:01 |
| jam | Odd_Bloke: can you type it in chat, so I can see? | 00:01 |
| Odd_Bloke | No, because neither of us have the appropriate fonts installed (and I'm using irssi). :p | 00:02 |
| jam | Odd_Bloke: well, I probably have the right fonts installed, irssi might get tricky | 00:02 |
| Odd_Bloke | Well, http://www.kevnet.com:9000/LOTR%20TEXT/images/tengwar.jpg has an example of some of the characters. | 00:03 |
| jam | عرابي | 00:03 |
| Odd_Bloke | But those are all consonants, because the vowels in a word are expressed using what are essentially accents. | 00:03 |
| === epsy is now known as rolf_mao | ||
| jam | Odd_Bloke: that is the system used in Arabic | 00:04 |
| jam | Only they *usually* leave the accents off | 00:04 |
| jam | (Except for in super special texts like the Qur'an) | 00:04 |
| Odd_Bloke | http://www.geocities.com/tengwar2001/pubs.htm has font packs for the Tengwar at the bottom. | 00:05 |
| Odd_Bloke | And examples of its use above that. | 00:05 |
| Odd_Bloke | Anyhow, I'm going to return to watching Doctor Who. | 00:05 |
| NfNitLoop | does Tengwar have a unicode character mapping? : ) | 00:06 |
| NfNitLoop | last I heard, fonts for it just mapped to ascii (english) letters. | 00:06 |
| Odd_Bloke | NfNitLoop: I don't know anything more than the abstracts of a Google search told me, but its not in the official standard. </lying about watching Doctor Who> | 00:09 |
| NfNitLoop | Esperanto characters are within the Latin-3 charset. (and thus, unicode, too.) And I think I read that Klingon speakers have an unofficial unicode range. | 00:12 |
| mbt | Last I knew, Klingon used the private use area of Unicode in fonts that support it. | 00:13 |
| NfNitLoop | ah, that's right, "private use area". | 00:13 |
| NfNitLoop | my unicode knowledge is a bit rusty. :) | 00:13 |
| spiv | jam: oh, and thanks for all those reviews | 00:14 |
| jam | spiv: happy to, sorry I didn't get to all of them. | 00:15 |
| jam | I'm off for the night, *babytime*, see you all around | 00:16 |
| Odd_Bloke | Stop! *babytime* | 00:18 |
| dberkholz | i'd like to merge two repositories that were totally independent. trying bzr merge asked for a base, and i'm not really sure what it's getting at | 00:34 |
| james_w | hi dberkholz | 00:35 |
| james_w | bzr merge -r0..-1 will allow you to do that, it specifies that you want revision 0 as the base, i.e. the null revision that all branches have in common. | 00:35 |
| james_w | and with that I'm off to bed. Night all. | 00:35 |
| poolie | night james | 00:39 |
| lifeless | abentley: pong | 00:44 |
| lifeless | james_w: hi | 00:45 |
| poolie | hello lifeless | 00:45 |
| Odd_Bloke | Man, cliffhangers suck. | 00:45 |
| dberkholz | james_w: thanks! | 00:45 |
| abentley | lifeless: I'd like to make an optimized fetcher for pack-0.92 to rich-root-pack. | 00:45 |
| abentley | Can you suggest an approach? | 00:46 |
| abentley | Pack.pack seems a little too granular... | 00:46 |
| lifeless | abentley: I think VersionedFiles will correct the performance of plain to rich roots with packs | 00:47 |
| abentley | Okay. You're planning to get that in this cycle anyhow, right? | 00:48 |
| lifeless | yes | 00:48 |
| lifeless | this week I hope | 00:48 |
| abentley | Okay, so I'll reassess whether that's necessary then. | 00:48 |
| lifeless | if you do want to do one, I would subclass Packer | 00:49 |
| lifeless | you'd need to change the main driver function | 00:50 |
| lifeless | as you won't be able to copy the revisions blind, nor the inventories | 00:50 |
| igc | bbiab | 00:58 |
| lifeless | poolie: one_five is missing | 01:31 |
| poolie | just add it if you want to use it... | 01:33 |
| lifeless | ok | 01:43 |
| === i386_ is now known as i386 | ||
| lifeless | poolie: abentley: jam: think its tasteful to expose the transactional ability of a repository? | 02:12 |
| lifeless | e.g. packs can safely request unordered streams | 02:12 |
| lifeless | but knit repos need ordered streams | 02:12 |
| abentley | lifeless: My gut reaction is that it's not tasteful, but I could be convinced. | 02:15 |
| lifeless | ok | 02:16 |
| lifeless | so in requesting from a smart server | 02:16 |
| lifeless | unordered will perform better because it can linear-scan the pack files into the stream | 02:16 |
| lifeless | but unordered requires much more IO and buffering when inserting into a knit style repository | 02:17 |
| lifeless | also with direct access the same difference will show up | 02:18 |
| lifeless | abentley: so the problem I need to solve is how to get the right ordering flag in the requests | 02:33 |
| lifeless | abentley: without duplicating all the fetch logic | 02:34 |
| abentley | For what purpose? Not fetch? | 02:36 |
| abentley | It has to be insertion, or else atomicity or the lack of it in the target is irrelevant. | 02:39 |
| abentley | Which in most cases is fetch. So I don't understand what "without duplicating all the fetch logic" means. | 02:40 |
| lifeless | for fetch | 02:43 |
| lifeless | well | 02:43 |
| lifeless | for the same model/serialisation fetching between two repositories | 02:43 |
| lifeless | if both are knits/weaves we need topological ordering | 02:44 |
| lifeless | if the target is packs we want unordered | 02:44 |
| lifeless | which lets the source optimise reads | 02:44 |
| jam | lifeless: I'm willing to break abstractions when necessary | 02:47 |
| jam | as long as there are tangible benefits | 02:47 |
| lifeless | jam: I've been thinking about find_difference | 02:48 |
| lifeless | jam: I think a profitable avenue is to consider reframing the halting problem as 'determine the relative graph height' | 02:49 |
| jam | lifeless: well, I have code now that performs fairly reasonable on bzr.dev | 02:50 |
| jam | for find_unique, talking <100ms for all merge nodes | 02:50 |
| jam | well, on average | 02:50 |
| lifeless | jam: that seems slow to me | 02:59 |
| lifeless | jam: and I bet it is doing more work than needed if it is essentially tracking all the nodes independently | 02:59 |
| jam | lifeless: only interesting tips | 03:00 |
| jam | but sure | 03:00 |
| jam | I can't say that there is a lot less you could genuinely do | 03:00 |
| abentley | lifeless: I understand the benefit of optimizing read order. I don't understand the problem with doing that via Interrepository. | 03:00 |
| lifeless | abentley: RemoteRepository | 03:01 |
| lifeless | abentley: for pushing into a RemoteRepository the selected RemoteRepository will be the same regardless of the actual disk format | 03:02 |
| abentley | gotcha. | 03:03 |
| abentley | Well, like I said, it was a gut instinct. If that's the most practical way to proceed, go ahead. | 03:07 |
| abentley | But the way RemoteRepository masks the real repository is a continuing problem. | 03:07 |
| * AfC waves to jam | 03:09 | |
| lifeless | abentley: my instinct isn't to do so either; but I do need to solve the problem eventually; using topological ordering everywhere will impair pack performance | 03:18 |
| lifeless | ok full test run with join() out of use | 03:18 |
| abentley | Well, we could just always do unordered and make the luddites suffer :-) | 03:19 |
| lifeless | I seriously considered that | 03:20 |
| lifeless | however the pathological cases for that really are pathological | 03:20 |
| igc | reviewing abentley's patches now | 04:28 |
| === RAOF_ is now known as RAOF | ||
| lifeless | spiv: my versioned_files branch on lp/puc | 06:30 |
| spiv | lifeless: ta | 06:32 |
| lifeless | puc will obviously be more up to date | 06:32 |
| * mtaylor is away: I'm not here right now | 06:45 | |
| poolie | lifeless: hi, want to talk when you're done? | 06:58 |
| lifeless | lets talk now | 07:00 |
| lifeless | night all | 08:57 |
| jave | hello | 10:57 |
| jave | I'm new to bazaar | 10:57 |
| jave | I have made a local copy of the emacs bzr repos and made some changes | 10:57 |
| jave | how do I get the diff between my local branch and the emacs repos? | 10:58 |
| jave | I tried for instance: bzr diff --old HEAD --new emacs-winprop | 10:58 |
| james_w | jave: does "bzr diff -r submit:" do what you want? | 11:00 |
| jave | ill try, its rather slow | 11:01 |
| jave | I'm using bzr 1.3.1 dsitributed with fc8 | 11:02 |
| Kinnison | Hi, I'm about to embark on some Linux kernel development work and I need to revision control it. While 'git' is the obvious choice, I'd prefer bzr if possible since i'm used to it. How well does bzr cope with linux-kernel size trees and will loom cope with it too? | 11:02 |
| jave | james_w: submit: seems to do the thing, Thanks ! | 11:04 |
| james_w | hi Kinnison | 11:05 |
| james_w | I've never tried bzr on a kernel size tree, so I can't say for sure I'm afraid. | 11:05 |
| Kinnison | :-( | 11:10 |
| Kinnison | I hate git | 11:10 |
| spiv | Kinnison: well, people have imported emacs and openoffice into bzr, so it at least doesn't explode out-right. | 11:36 |
| spiv | I don't have any actual numbers for you though. | 11:36 |
| james_w | do the autotest tests include the kernel? | 11:38 |
| igc | james_w: the usertest ones do (if that's what you mean) | 11:47 |
| james_w | hi igc | 11:47 |
| igc | hi | 11:48 |
| james_w | yes, that's what I meant. | 11:48 |
| igc | Kinnison: we currently include a snapshot of the kernel in our performance testing but it's a historyless repo | 11:49 |
| igc | Kinnison: if you get a copy of the kernel (with history) imported into Bazaar, please let us know and we'll then start including that in the testing we do | 11:50 |
| igc | for details on the tests I run, see the bzr-usertest plugin | 11:51 |
| igc | you should also find bzr-fastimport useful for doing the migration, though it might be have a few bugs | 11:52 |
| igc | james_w: have did your OpenWeek session go? | 11:52 |
| igc | s/have/how/ | 11:52 |
| james_w | it was ok thanks. Not many questions though. | 11:54 |
| Kinnison | igc: I don't care about the kernel's history, it's more for managing a series of patches I need to write | 12:00 |
| Kinnison | igc: I figured loom made sense for that | 12:00 |
| james_w | Kinnison: I would imagine that bzr add in the tarball and then loom would probably be ok. | 12:01 |
| Kinnison | james_w: That's what I'm hoping, but I'm making a copy of the git repo just in case | 12:02 |
| Kinnison | One thing git has going for it is that it filled my 10Mbps pipe | 12:04 |
| Kinnison | I've never seen bzr manage that | 12:04 |
| james_w | igc's usertest results show all tested commands taking under a minute, with only 4 taking over 30 seconds, and only 5 over 11 seconds. | 12:05 |
| Kinnison | Well, I have a crappy slow HDD so we'll see :-) | 12:11 |
| Kinnison | OTOH, 4GiB of RAM helps | 12:12 |
| Kinnison | Hmm, if bzr st takes too long I'll have to remove it from my prompt | 12:13 |
| spiv | 4GiB will definitely help with bzr st... | 12:14 |
| semslie | http://domscripting.com/blog/display/41 | 12:20 |
| Kinnison | It's merrily committing and thus chewwwing all my CPU and disk :-( | 12:22 |
| Kinnison | Oh, updatedb is running | 12:22 |
| Kinnison | grr, that took 5 minutes, thanks updatedb | 12:24 |
| Kinnison | otoh, bzt st takes around 1.5s, so kudos to the team | 12:24 |
| Kinnison | Okay, can I reconfigure a branch into a repository, or do I have to pull/branch it into one? | 12:27 |
| mwhudson_ | i think maybe bzr.dev can reconfigure it | 12:27 |
| mwhudson_ | i can't remember if that bit landed | 12:27 |
| * Kinnison updates then, my bzr.dev mirror is at r3334 | 12:28 | |
| === mwhudson_ is now known as mwhudson | ||
| igc | night all | 13:38 |
| === bigdo3 is now known as bigdog | ||
| fbond | Hi, any opinions or work-arounds for https://bugs.launchpad.net/bzr/+bug/214894 ? | 15:26 |
| jam | bug #214894 | 15:27 |
| jam | Where is ubotu? | 15:27 |
| jam | fbond: you can do "bzr pull . --overwrite" | 15:27 |
| jam | and after that "bzr push" should work | 15:27 |
| fbond | jam: and a fix is forthcoming? | 15:28 |
| fbond | jam: have my repos/branches suffered any permanent damage (I assume not)? | 15:28 |
| jam | fbond: nothing serious, you just used an older version of bzr (probably a *long* time ago) | 15:29 |
| jam | which allowed the history to wander | 15:29 |
| jam | see bug #177855 | 15:29 |
| jam | https://bugs.edge.launchpad.net/bzr/+bug/177855 | 15:29 |
| fbond | jam: So is it enough to run bzr check on the remote branch and then push to it again? | 15:30 |
| jam | fbond: you shouldn't need to run bzr check even | 15:31 |
| jam | upgrading the remote branch would also fix it, though. | 15:31 |
| fbond | jam: Okay, `bzr pull . --overwrite' should be run on the remote branch, then? | 15:31 |
| jam | fbond: I think so | 15:32 |
| jam | It has been a while since I worked on this | 15:32 |
| jam | if you want, please post your results to bug #177855 | 15:32 |
| fbond | I assume that `bzr pull . --overwrite' just rewrites the branch's revision history... | 15:32 |
| jam | fbond: correct | 15:33 |
| jam | it just needs to be regenerated so that it is "canonical" | 15:33 |
| fbond | jam: Hmm, that didn't seem to work. I'm trying `bzr reconcile' (as is mentioned in #177855). | 15:33 |
| fbond | Or maybe I need to be running these on the local branch (not the remote one)... | 15:34 |
| jam | fbond: just as a help, can you run "bzr info" on both branches and pastebin the results? | 15:37 |
| fbond | Which pastebin? | 15:39 |
| fbond | jam: Should I use pastebin.ubuntu.com? | 15:41 |
| jam | fbond: that is fine | 15:44 |
| fbond | http://pastebin.ubuntu.com/8758/ | 15:49 |
| fbond | jam: I cleansed some URLs and paths and things, hopefully I didn't screw that up. | 15:50 |
| fbond | So the remote branch is bzr+ssh://user1@host1/home/user1/project/ | 15:50 |
| jam | fbond: yeah, no problems with the urls | 15:51 |
| jam | I wanted to see the other info | 15:51 |
| jam | namely the "format:" lines | 15:51 |
| fbond | jam: That's what I figured. | 15:51 |
| jam | fbond: just a sec, phone call | 15:52 |
| fbond | jam: Take your time. | 15:52 |
| abentley | jam: AFAIK, reconcile doesn't currently adjust revision history. | 15:56 |
| jam | abentley: no it doesn't, I was going to work on that right now | 15:57 |
| jam | :) | 15:57 |
| jam | Since we have 4+ bugs reporting the same thing | 15:57 |
| abentley | Cool | 15:57 |
| jam | we probably need to fix it | 15:57 |
| abentley | your bug comment about reconcile is a bit misleading, though. | 15:58 |
| jam | abentley: well I thought I wrote "we need to do X" | 15:58 |
| jam | not that "X" works | 15:58 |
| jam | abentley: but I can see how my comment is misleading | 15:59 |
| jam | I'll post a followup | 15:59 |
| jam | abentley: where do tests for "check" go? There isn't a 'test_check.py' | 16:00 |
| jam | or maybe this is a branch impl test? | 16:00 |
| abentley | I don't know. | 16:01 |
| jam | I haven't worked in the check/reconcile code for a while | 16:01 |
| jam | And I know Odd_Bloke was sticking his fingers in there recently | 16:01 |
| Peng | jam: You don't actually advocate forbidding http://host/branch/subbranch, right? | 16:02 |
| jam | Peng: I actually *like* it, but if you are going to forbid "http://host/repo" being a branch, then it seems the other should be gone as well | 16:02 |
| fbond | jam: Hmm, so I guess I can just push over sftp:// and things will work, eh? (`bzr pull . --overwrite' doesn't seem to do anything useful for me). | 16:02 |
| jam | fbond: can you do "bzr push --overwrite" and see if that works? | 16:03 |
| jam | I'm thinking the code path may not anymore | 16:03 |
| fbond | jam: Sure thing... | 16:03 |
| jam | The problem is it detects "nothing changed" and then doesn't actually fix things up | 16:03 |
| jam | abentley: "knit or dirstate" is Branch5, right? | 16:03 |
| jam | Branch6 would report "dirstate-tags" | 16:03 |
| jam | IIRC | 16:03 |
| fbond | jam: I get the same AssertionError with push --overwrite | 16:04 |
| abentley | Right. | 16:04 |
| Peng | jam: Well, I think having "http://host/repo" be a branch makes it hard to discover when you're just browsing the web server, but there's no need to bother banning it, especially at the cost of nested branches. | 16:04 |
| jam | fbond: you're on a Linux machine, right? | 16:04 |
| fbond | jam: yep, RHEL on the server, Hardy on my workstation. | 16:04 |
| jam | Peng: mostly just for "consistency", if people want to disallow nesting branches, etc | 16:04 |
| jam | fbond: ok, I'll give you a snippet of code that will get things working again, and then I'll go try to fix reconcile and check | 16:05 |
| fbond | jam: okay, thanks! | 16:05 |
| fbond | lifeless: BTW, I am holding off on any loom workflow docs until some enhanced automation is in place to support the "quilt replacement"-style workflow. | 16:07 |
| fbond | lifeless: It would just feel a little silly to recommend that people do so much manual work to move around the loom after committing new changes to a low thread. | 16:07 |
| fbond | lifeless: So, please do keep my posted if anything changes with this, and I'll be happy to document how I use things. | 16:08 |
| jam | fbond: http://pastebin.ubuntu.com/8766/ | 16:09 |
| jam | save it as a "cleanup.py" | 16:09 |
| jam | and then run it in your local branch | 16:09 |
| jam | afterwards, bzr push should work | 16:09 |
| jam | fbond: let me know if it works/doesn't work | 16:12 |
| jam | we can attach it to the bug as a current workaround | 16:12 |
| fbond | jam: no, didn't do anything (and didn't produce any output)... | 16:13 |
| jam | fbond: hmm.... | 16:13 |
| jam | fbond: just to make sure things are valid: from bzrlib import branch b = branch.Branch.open('.') b.lock_read() try: orig_revno, last_rev = b.last_revision_info() real_revno = len(list(b.repository.iter_reverse_revision_history(last_rev))) if orig_revno != real_revno: print "Changing revno from %s => %s" % (orig_revno, real_revno) b.set_last_revision_info(real_revno, last_rev) finally: b.unlock() | 16:15 |
| jam | sorry | 16:15 |
| jam | http://pastebin.ubuntu.com/8768/ | 16:15 |
| jam | fbond: also, can you try running that and replacing '.' with the url of the branch you are pushing to? | 16:16 |
| fbond | jam: local: not changing revno, both match at 404 | 16:18 |
| jam | fbond: ok, that is a bit odd | 16:18 |
| jam | fbond: and 'bzr push' still fails with the assertion error? | 16:18 |
| fbond | jam: remote: not changing revno, both match at 381 | 16:19 |
| jam | fbond: ah, at least local and remote disagree on the revno | 16:20 |
| jam | something weird is happening, though | 16:20 |
| fbond | jam: yep, push gives: AssertionError: 403 != 404 | 16:20 |
| jam | ok, that is, at least, a little bit different | 16:20 |
| fbond | jam: local and remote disagree because I have ~20 revisions I'm trying to push out :) | 16:20 |
| jam | fbond: any chance I could see these branches directly? | 16:21 |
| fbond | They are not publicly accessible at the moment (and contain some amount of proprietary code). | 16:21 |
| fbond | I don't think folks would be happy with me if I shared them. | 16:22 |
| jam | fbond: well, something weird is happening, I guess I can write some more python code for it | 16:22 |
| jam | (I certainly wouldn't ask for making them public, just personal access) | 16:22 |
| jam | but I won't push | 16:22 |
| fbond | jam: Yeah, I follow you. | 16:22 |
| jam | support by remote is just a pain | 16:23 |
| fbond | jam: I've done it myself, I know what you're talking about.. | 16:23 |
| jam | fbond: I just realized I was lock_read() the branch, the set_last_revision_info would fail anyway :) | 16:23 |
| fbond | jam: Ah. | 16:24 |
| jam | that wasn't the problem, but it would have been | 16:24 |
| jam | fbond: http://pastebin.ubuntu.com/8775/ | 16:31 |
| jam | fbond: give that a shot, and tell me what it spits out | 16:31 |
| fbond | jam: okay, I'm dealing with an unrelated crisis, be right back with you ;) | 16:36 |
| jam | fbond: np | 16:36 |
| fbond | jam: I get bzrlib.errors.NotBranchError; it complains about the parent branch (which differs from the push branch). | 17:01 |
| jam | fbond: ah, I noticed that, I thought it was a bit weird that one had a '.' and the other had a '-' | 17:02 |
| fbond | Looks like this: | 17:02 |
| jam | fbond: change the line "get_parent()" to "get_push_location()" | 17:02 |
| fbond | Okay, that's what I thought. | 17:02 |
| fbond | jam: it's running; I'll let you know when it finishes. | 17:06 |
| fbond | jam: Now I'm getting LockContention | 17:09 |
| jam | fbond: ...? can you paste the traceback | 17:10 |
| jam | that seems weird | 17:10 |
| jam | fbond: but you can change the "lock_write()" to "lock_read()" | 17:10 |
| jam | since I don't actually mutate any data | 17:10 |
| fbond | jam: okie dokie | 17:10 |
| fbond | jam: It ran for a while before reporting this. | 17:10 |
| === TFKyle_ is now known as TFKyle | ||
| * mtaylor is back (gone 10:47:19) | 17:33 | |
| jam | welcome back mtaylor | 17:35 |
| mtaylor | jam: thanks! | 17:35 |
| === BasicPRO is now known as BasicOSX | ||
| fbond | jam: now I only see No handlers could be found for logger "bzr" (no other output) | 18:31 |
| fbond | jam: This was running the script against my local branch. | 18:31 |
| fbond | If it modified the branch, it would've printed something, right? | 18:32 |
| jam | fbond: I think so, you might try adding a "from bzrlib import trace; trace.enable_default_logging()" at the top | 18:54 |
| jam | just to see what it wants to log | 18:54 |
| jam | fbond: otherwise I'm pretty confused. It seems the two repositories disagree on something, but so far I haven't found anything that they disagree on :) | 18:55 |
| === Necoro_dM is now known as Necoro | ||
| fbond | jam: That makes me think that the two repositories don't disagree so much as 1.3.1 may be backwards incompatible with the remote server or repository. | 19:06 |
| fbond | Is it possible? | 19:06 |
| david_kofsky | How do I merge two branches with no shared history? | 19:07 |
| jam | david_kofsky: generally " bzr merge -r 0..-1 ../other/branch" | 19:08 |
| jam | it sort of depends what you are trying to do, but that at least forces the merge to finish | 19:08 |
| fbond | jam: would it help to have the repositories to look at? | 19:09 |
| fbond | jam: they are each >200M (I assume they can't be compressed much) | 19:09 |
| jam | fbond: well, simple ssh access would be sufficient | 19:11 |
| jam | you can even run 'screen' so that you can track everything I do | 19:11 |
| jam | It would make things a bit easier for me to debug. | 19:11 |
| fbond | jam: Which screen feature allows that? | 19:13 |
| jam | fbond: me being on the same screen page as you | 19:14 |
| jam | -x | 19:14 |
| jam | allows multiple connections to the same screen | 19:14 |
| jam | You can even follow along as I go | 19:14 |
| fbond | Hang on. I'll admit I'm uncomfortable with the idea; nothing personal, of course. Using screen doesn't prevent you from opening another connection, of course. | 19:16 |
| fbond | In any case, give me just a minute... | 19:16 |
| jam | fbond: of course | 19:16 |
| jam | though you can set up ssh so that I can only connect to "screen -xRR" | 19:17 |
| jam | or something | 19:17 |
| jam | I believe you can do: | 19:17 |
| fbond | jam: yeah, that's what I figured. | 19:17 |
| jam | command="/usr/bin/screen -xRR" ssh-rsa ... | 19:19 |
| jam | in the .ssh/authorized_keys file | 19:19 |
| jam | You can use my public keys from launchpad, and then remove access when we're done | 19:20 |
| jam | or whatever | 19:20 |
| jam | Just letting you know what makes it easiest for me | 19:21 |
| jam | We can try to keep going back and forth, but certainly something weird is going no | 19:21 |
| jam | on | 19:21 |
| jam | fbond: I did put together a branch which implements 'bzr reconcile' in case you want to try it | 19:25 |
| jam | I would ask that you start from bzr.dev and then bzr pull --overwrite from http://bzr.arbash-meinel.com/branches/bzr/1.5-dev/reconcile_rev_history_177855 | 19:25 |
| mathrick | hmm, why exactly doesn't bzr revert ask for confirmation? | 19:25 |
| jam | mathrick: in general, you can't lose modifications with revert | 19:25 |
| mathrick | howso? | 19:26 |
| jam | as it saves backups for files which are modified | 19:26 |
| mathrick | ah | 19:26 |
| mathrick | I didn't know that | 19:26 |
| jam | ~ files | 19:26 |
| jam | It doesn't do it for all files, if it believes you could regenerate it. | 19:26 |
| jam | So, for example, if you 'bzr merge ../other/branch; bzr revert' | 19:26 |
| jam | it will just revert without a backup | 19:27 |
| jam | because it assumes you can just merge again | 19:27 |
| mathrick | jam: but if the files had any other changes besides the merge, it'll back up? | 19:27 |
| jam | mathrick: yes | 19:27 |
| mathrick | jam: also, as I'm working on that script for syncing, I have two questions: 1) it does fast_host.push(mainline), shouldn't it also push in the other direction? | 19:29 |
| mathrick | jam: and 2) do you want copyright on the initial code you gave me? (I will be publishing it once it's a bit more mature and featureful) | 19:30 |
| jam | mathrick: not a big deal | 19:31 |
| mathrick | ok, cool | 19:31 |
| jam | you probably want to "fast_host.pull()" | 19:31 |
| jam | Just because there are assumptions about which side is "fast" to access | 19:31 |
| mathrick | jam: yeah, but I was right about it being only a one-way sync? | 19:32 |
| jam | push only syncs in one direction, yes | 19:32 |
| mathrick | are there any specific recommendations as to which should go first (push or pull)? | 19:33 |
| jam | mathrick: shouldn't really matter. I would tend to favor the one you expect to change the most | 19:33 |
| mathrick | jam: hmm, actually, pull will only incorporate changes that can be committed directly onto the current tip, which means that _any_ situations in which there are independent commits on both between syncs results in a conflict, no? | 19:35 |
| mathrick | jam: do you recon it'd be beneficial to have it attempt a merge automatically? | 19:35 |
| mathrick | or just resolve every such case manually? | 19:36 |
| mathrick | I intend it to run every 5 or so minutes, so I don't really expect the periods between syncs to be very long, but it could still happen | 19:36 |
| jam | push and pull will both error for diverged branches, yes | 19:37 |
| jam | the only problem is if one side is technically a merge of the other | 19:37 |
| jam | but I wouldn't expect that to be a specific problem for you | 19:37 |
| jam | as you sort of *want* that to happen :) | 19:37 |
| mathrick | yeah, manually or not, I still need the tree to be merged in the end :) | 19:38 |
| jam | mathrick: as for auto-merging.... | 19:38 |
| jam | you need an actually tree on disk to do a merge | 19:38 |
| jam | actual | 19:38 |
| mathrick | I just need to work out which of them is "the" tree | 19:38 |
| mathrick | jam: yeah, that might be a problem | 19:38 |
| jam | and it seems like these are mostly just branches in a repository | 19:38 |
| jam | you could always create one in /tmp, tec. | 19:38 |
| jam | etc. | 19:38 |
| jam | I'm not a huge fan of auto-merging | 19:38 |
| mathrick | okay, so I won't do that for now at least, and will decide how to tackle that later | 19:39 |
| jam | and you'll still need to 'bzr pull' on the client | 19:40 |
| mathrick | yeah | 19:40 |
| mathrick | the issue of having a canonical tree is kinda icky, let's not think about it just yet :) | 19:41 |
| mathrick | jam: btw, here's a sort-of current snapshot of it at work: http://sei.meidokon.net/ :) | 19:41 |
| mathrick | I'm currently reworking the table weaver to yield more aesthetically pleasing results | 19:42 |
| jam | mathrick: pretty, planning on releasing this publicly? | 19:44 |
| mathrick | jam: yep | 19:44 |
| mathrick | that's why I asked about copyrights | 19:44 |
| jam | heck, if you want to give me credit, go ahead | 19:44 |
| mathrick | :D | 19:45 |
| jam | But for something like this, I don't really care | 19:45 |
| mathrick | okay, I will credit you in AUTHORS | 19:45 |
| mathrick | btw, taking LogFormatter and making it into something that can output multiple-column HTML tables is not exactly trivial | 19:46 |
| mathrick | it might make sense to release HtmlTableWeaver as a separate plugin on its own | 19:47 |
| SeWPKiP | hi all! | 20:01 |
| SeWPKiP | would someone be able to help me out with a weird problem? | 20:03 |
| SeWPKiP | I played around with pagaent today and can't get my windows box to connect anymore .. to any bzr location | 20:03 |
| SeWPKiP | re-installing bzr and clearing away all files in ..my profile/application/data/bazaar also didn't help | 20:04 |
| mathrick | SeWPKiP: did you clear pageant's files? | 20:08 |
| mathrick | in particular, stored keys / locations? | 20:08 |
| mathrick | also, did you try connecting to any locations manually (ie. with putty)? | 20:08 |
| SeWPKiP | mathrick: that's for responding! | 20:13 |
| SeWPKiP | i didn't know i had to. any idea where those files are? | 20:13 |
| mathrick | SeWPKiP: I dunno if you have to, but that's what I'd suspect off-hand | 20:16 |
| mathrick | SeWPKiP: look in my profile/application/data/pageant or similar | 20:16 |
| mathrick | possibly in my profile/ssh or so | 20:16 |
| SeWPKiP | still looking but can't find anything like that | 20:17 |
| mathrick | SeWPKiP: okay, do you still have pageant running? | 20:19 |
| SeWPKiP | no i don't | 20:19 |
| SeWPKiP | also, restarted the computer | 20:19 |
| mathrick | SeWPKiP: did it help? | 20:20 |
| SeWPKiP | well, i tried all that before coming here | 20:20 |
| mathrick | ah | 20:21 |
| mathrick | well then, try launching pageant again, and see if it has any keys remembered | 20:21 |
| SeWPKiP | nope,didn't work either | 20:21 |
| SeWPKiP | it hasn't remembered a thing | 20:21 |
| SeWPKiP | i'm just guessing that pageant is the problem - because that's the most recent thing i did | 20:21 |
| mathrick | SeWPKiP: hmm, odd, and yeah, it seems so | 20:21 |
| SeWPKiP | well, that and branching between local folders | 20:21 |
| mathrick | SeWPKiP: try connecting with putty first | 20:22 |
| SeWPKiP | that works | 20:22 |
| SeWPKiP | plink works as well | 20:22 |
| mathrick | SeWPKiP: okay, does bzr give you any error? | 20:22 |
| SeWPKiP | yep | 20:23 |
| SeWPKiP | it's ERROR: Conection Closed: please check connectivity and permissions | 20:23 |
| mathrick | ah | 20:23 |
| SeWPKiP | and try -Dhpss if further diagnosis is required | 20:23 |
| SeWPKiP | so, pulled up the log | 20:23 |
| mathrick | SeWPKiP: okay, open cmd.exe, and do what it tells you to | 20:23 |
| SeWPKiP | ok | 20:23 |
| mathrick | ie. run bzr -Dhpss ls ssh://foo@bar/baz/ | 20:24 |
| SeWPKiP | i sent you the result | 20:25 |
| SeWPKiP | oops | 20:25 |
| SeWPKiP | i sent you the result | 20:25 |
| mathrick | huh | 20:26 |
| mathrick | SeWPKiP: yeah, I got it | 20:26 |
| mathrick | it *should* work | 20:26 |
| mathrick | SeWPKiP: please give me the exact line you gave it | 20:26 |
| SeWPKiP | bzr -Dhpss ln bzr+ssh://name@location/foo | 20:26 |
| SeWPKiP | just ssh:// wouldn't work | 20:26 |
| mathrick | ah, right | 20:27 |
| mathrick | SeWPKiP: is the location public? | 20:27 |
| SeWPKiP | no it isn't .. | 20:27 |
| SeWPKiP | but other people can access it, no problem | 20:27 |
| mathrick | SeWPKiP: I meant I wanted to try precisely the line you used, to see why it was complaining about bad arguments | 20:28 |
| SeWPKiP | thanks for that, but that's not possible | 20:28 |
| mathrick | bzr -Dhpss ls bzr+ssh://bzrserve@megumi.local/home/bzrserve/repo/faktoid/ <-- that works just fine for me | 20:29 |
| mathrick | (and no, it's not public either) | 20:30 |
| mathrick | SeWPKiP: hmm, is what you pasted me *all* it outputs? | 20:31 |
| SeWPKiP | yes, it's not helpful at all | 20:31 |
| mathrick | ah, I guess not, you quit with excess flood | 20:31 |
| mathrick | SeWPKiP: please use pastebin.com or similar | 20:31 |
| mathrick | to make sure I can see it all | 20:32 |
| SeWPKiP | ok, brb | 20:32 |
| SeWPKiP | trying to use the --serve comand now | 20:38 |
| SeWPKiP | to pinpoint ssh as the problem | 20:38 |
| SeWPKiP | yeah it clearly is ssh .. i mean, just using --serve works | 20:42 |
| SeWPKiP | really really odd | 20:42 |
| mathrick | SeWPKiP: okay, what happens if you uninstall pageant? | 20:48 |
| SeWPKiP | that's not an option | 20:51 |
| SeWPKiP | it's just a single binary | 20:51 |
| SeWPKiP | seems like there are some weird ssh certificates lying around or something.. just can't find them | 20:51 |
| SeWPKiP | and bzr won't tell me what it's doing | 20:51 |
| === cprov is now known as cprov-afk | ||
| === ja2 is now known as jam | ||
| abadger1999 | abentley: Do you still know how the trac-bzr plugin works or have you purged all knowledge from your memory? | 22:39 |
| abentley | abadger1999: I have some foggy recollections. | 22:49 |
| tro | is bzr-svn compatible with bzr 0.4? | 22:50 |
| tro | i mean ... the latest bzr? 1.4? | 22:50 |
| abadger1999 | abentley: In class BzrRepository(versioncontrol.Repository) there are some references to self.repo | 22:51 |
| abadger1999 | but I dont see that self.repo is created anywhere. | 22:52 |
| abadger1999 | Do you remember what was going on with that? | 22:52 |
| abentley | abadger1999: No, I don't remember. I had a look at the file and I couldn't see how it would have worked. | 22:58 |
| abadger1999 | abentley: Okay. At least I don't feel like I'm missing some special trick :-/ | 22:58 |
| abadger1999 | Thanks for looking. | 22:58 |
| abentley | You're thinking of the line in parse_rev? | 22:59 |
| abentley | That line is probably a fossil-- it was introduced by Marien Zwart, which was before I worked on it. | 23:00 |
| abadger1999 | yeah, parse_rev(), next_rev(), and rev_older_than() | 23:00 |
| abadger1999 | Okay. I'll just cut that logic out of parse_rev(). | 23:01 |
| tro | i'm trying to push a bzr branch into an svn repo with the bzr-svn plugin, but i need to be able to specify the username to use in svn. is that possible? | 23:22 |
| bob2 | put it in the url? | 23:24 |
| * tro headdesks | 23:24 | |
| tro | of course! | 23:24 |
| tro | thanks | 23:24 |
| poolie | hello | 23:29 |
| beuno | morning poolie | 23:31 |
| poolie | hello beuno | 23:36 |
| igc | morning all | 23:47 |
| beuno | mornin' igc | 23:48 |
| lifeless | >hate my isp atm< | 23:53 |
| beuno | aaaaand good morning lifeless :) | 23:53 |
| beuno | javierder, ping | 23:58 |
| igc | abentley: bb is down again for me - 550 Internal Server Error | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
