| lifeless | fta: just commit them | 00:00 |
|---|---|---|
| lifeless | fta: then pull them onto B, uncommit, and keep editing | 00:00 |
| fta | i used to do that but it's not very handy | 00:01 |
| lifeless | fta: what would you like to be able to do | 00:02 |
| lifeless | ? | 00:02 |
| fta | both A and B push to a central repository (not a working tree), so i have to uncommit there :( | 00:03 |
| lifeless | well, you can just push --overwrite | 00:03 |
| lifeless | when you're done on B | 00:03 |
| lifeless | or push to a temp branch in the central repo, rather than your trunk | 00:03 |
| fta | but if someone else pushed on central, it breaks | 00:04 |
| lifeless | use a temp branch for sure then | 00:04 |
| fta | i would like to export uncommitted changes from A to B or vice versa, without going to central, yet with preserving the resolve/conflicts facilities | 00:05 |
| fullermd | merge --uncommitted would do that. | 00:05 |
| fullermd | (though you can get ugly going back and forth with it; doing it once would be reasonable) | 00:05 |
| fullermd | It would similarly benefit from a super-shelf that used real revisions to hold the shelved stuff. | 00:06 |
| fta | A and B are owned only by the same user, central is shared | 00:06 |
| awilkins | fta: I have a repo on a thumb that I commit to ; if I need to put that in a central repo I push from there | 00:06 |
| awilkins | fullermd: Isn't "loom" a sort of super-shelf? | 00:07 |
| lifeless | fta: uncommitted changes have no real representation in bzr | 00:07 |
| lifeless | other than 'working tree' | 00:07 |
| lifeless | fta: do you have NFS or similar between these two machines? | 00:07 |
| lifeless | I think there is a valid use case here, in two different dimensions, but we don't have a good offering today | 00:08 |
| lifeless | and it will take thought to avoid making a bad one :P | 00:08 |
| lifeless | the two dimensions are collaborative conflict-resolution-in-N-steps | 00:08 |
| fta | i used commit/uncommit/push override for a while, i ended up with lost commits. i also used scp/rsync between A and B, better but not very handy. | 00:08 |
| lifeless | and helping people deal with transient commits more easily, I feel the two combined would do what you want | 00:09 |
| lifeless | jam: so did I get a review of log ? | 00:10 |
| jam | lifeless: I certainly hope so | 00:10 |
| jam | I did it last night | 00:10 |
| lifeless | ah yes found it | 00:10 |
| lifeless | thanks | 00:10 |
| lifeless | I've done one of your btree patches | 00:11 |
| lifeless | other shortly | 00:11 |
| fullermd | fta: merge --uncommitted would be much more handy than scp/rsync... | 00:11 |
| jam | lifeless: I didn't get a chance to play with the toy, I've been debugging the fetch issues | 00:11 |
| lifeless | jam: I integrated bzr-search with my patch last night - bzr log -m "\brobert\b" went from 12 seconds to 4 seconds | 00:11 |
| jam | nicely done | 00:11 |
| fullermd | awilkins: Not really, especially if you're not already using looms and on top of one... | 00:12 |
| lifeless | jam: primary fetch issue is no streaming verb | 00:12 |
| lifeless | jam: that I know of | 00:12 |
| lifeless | (I mean, other than being-silly-with-object-lifetimes) | 00:12 |
| jam | yeah, but there are oddities in the specifics | 00:12 |
| jam | branch locally is 2+ times faster | 00:12 |
| awilkins | fta: How about * Branch to no-trees repo in USB thumb * A and B take checkouts of branch in thumb * commit when changing location and take thumb with you * update at the location you moved to * keep working ? | 00:13 |
| fta | fullermd: thanks. i'll give it a try for a while. thing is i'm an avid user of --remember so push/pull/merge are going to central by default.. merge --uncommitted will force me to specify A or B each time. | 00:13 |
| fullermd | fta: Aliases and/or the bookmarks plugin can be a help there. | 00:14 |
| awilkins | fta: This works well for me (I was pushing and pulling between network shares on my laptop and desktop for a while and I too got my knickers in a knot) | 00:15 |
| lifeless | jam: try with btrees :P | 00:18 |
| fta | awilkins, i'm not organized enough to depend on usb ;) it will stay connected on the other side, or i will simply forget. I expect bzr to do that for me as i can reach always reach A from B (reverse is not true) | 00:20 |
| fta | fullermd, yep, one more alias, i like that | 00:20 |
| awilkins | fta: How about keeping the branch on A and taking a checkout of it on A and B | 00:22 |
| awilkins | If you use a heavy checkout you can still commit to one offline and merge it later | 00:22 |
| awilkins | Here's one - operations on network shares on windows are treated just like local filesystems ; to the point where the client will do things like copy files from the tree rather than unpacking them from the content texts ; copying from the tree is slower over a network drive in many cases | 00:36 |
| awilkins | It will also do heinous things like repacking an 11MB repo over a 256KBit/s link | 00:36 |
| bob2 | you're using smb over adsl? | 00:37 |
| awilkins | bob2: VPN | 00:37 |
| awilkins | bob2: and cable not DSL (256 kbit is my upstream) | 00:38 |
| awilkins | Short of setting up an HPSS (or even just SFTP), would it be possible to have a --network option or similar that had it do things like * not update remote tree when pushing * not repack * not copy files from remote branch but unpack them from local content texts | 00:40 |
| fullermd | Well, if it helps, it would repack the 11MB repo over a 256Kb link if you were using SFTP too ;) | 00:40 |
| awilkins | fullermd: That's nasty too :-) | 00:41 |
| awilkins | I had the Windows bzr+ssh support all nicely patched and IT services refused to open port 22 | 00:42 |
| awilkins | Alas, I've not quite cracked HPSS over IIS 6 (works nicely with IIS 7) | 00:42 |
| fullermd | Well, it would repack the 11MB repo over a 256Kb link with bzr+ssh too... I mean, how consistent can you GET! | 00:42 |
| awilkins | Yes, but the repack happens locally with an HPSS | 00:43 |
| fullermd | No it doesn't. | 00:43 |
| awilkins | Urgh! | 00:43 |
| awilkins | You mean even on HPSS it pipes 22MB of data to the client? | 00:43 |
| awilkins | (and from | 00:43 |
| fullermd | Oh, no. I'm sure there's enough missing entropy that it can compress down to 21.5MB or so. | 00:44 |
| awilkins | Surely that's a bug - it's hardly high-performance-optimized if the thing is asking the client to do all the work and abusing its bandwidth | 00:44 |
| fullermd | FSVO 'bug'. | 00:45 |
| awilkins | What happens if you access a MySQL repo over bzr+ssh and it decides to repack? Grit your teeth and wait a day? | 00:45 |
| awilkins | (AFAIK you can just abort and nothing is hurt) | 00:46 |
| bob2 | yes | 00:46 |
| awilkins | Yuck | 00:46 |
| fullermd | Well, if you get a big enough repo, you'll only ever have to do it once, 'cuz a repack verb (or better, elimination of a need for one) will have been added before it finishes... | 00:46 |
| bob2 | hahaha | 00:47 |
| awilkins | Why the hell would a client get to decide that the server needs to repack? | 00:47 |
| awilkins | Screw repack verb, it's the servers job to manage it's own damn storage | 00:47 |
| fullermd | That's crazy talk. Next you'll be saying the client shouldn't have to understand the low-level details of the server's repo format. | 00:48 |
| awilkins | You could just have the server play back bzr-fast-export tapes :-) | 00:48 |
| awilkins | Heck, you could write bzr HPSS servers for git | 00:49 |
| * fullermd summons jelmer :p | 00:49 | |
| * awilkins summons Bahamut | 00:49 | |
| fullermd | See, if bzr-git just gets fast enough, we can just use central git repos and avoid all that unnecessary HPSS work. | 00:49 |
| * fullermd repacks a repo while waiting for the cutscene to finish. | 00:50 | |
| bob2 | you just need a hpss-optimisation montage | 00:50 |
| * awilkins takes 7 damage | 00:50 | |
| fullermd | Gotta remember to stop by a commit-point. | 00:51 |
| * awilkins takes a USB key and commits in the field | 00:53 | |
| lifeless | awilkins: spiv has a patch to repack remotely | 00:54 |
| awilkins | Is it part of HPSS? | 00:54 |
| lifeless | awilkins: but note that repack only repacks small packs most of the time; to repack the deep history of mysql you need to commit 10 times as many revisions as there are already | 00:54 |
| lifeless | awilkins: yes, but not merged to bzr.dev yet | 00:54 |
| lifeless | awilkins: so, to trigger a repack of the deep mysql history, commit, oh, 500000 times | 00:55 |
| awilkins | I have a branch I'm using to deploy .jar files ; it only has about 10 revs and it go repacked into one pack over the VPN which is my 11MB case :-) | 00:55 |
| lifeless | awilkins: ok, the next repack of those 10 will occur at 100 revs | 00:56 |
| lifeless | and then at 1000 | 00:56 |
| awilkins | I hope the deltas are nice and small now then, it's mostly one 1.2 MB jar that's changing incrementally | 00:56 |
| awilkins | Would you get better packing by unzipping archives and them packing them> | 00:57 |
| lifeless | a zip compresses badly unless you use --rsyncable, and as we don't use rdiff, we don't gain much then (though we may gain some - I haven't tested) | 00:57 |
| lifeless | jars are zips | 00:57 |
| lifeless | (delta compress obviously) | 00:58 |
| lifeless | so yes, deltaing the contents would probably be a size win; though .java files may be questionable etc | 00:58 |
| * AfC wonders a bit why someone would ship .jar files with a version control system (unless this is a matter of using it to deploy artifacts to a production system, but even then) | 01:04 | |
| awilkins | Because it's easier to just have my users `bzr pull` than expect them to download an archive, unpack it, and not wipe out any of their own little scripts and things | 01:05 |
| ToyKeeper | Some of the stuff ronny brought up would be nice to have in bzr... like repo-level pull/push, and the ability to make new branches implicitly (like... "hg up -r 123 ; hack hack; hg commit" would make a new head) | 01:08 |
| ToyKeeper | A repo-level vis tool would be nice too. | 01:08 |
| awilkins | I thought extending switch would be good | 01:09 |
| awilkins | Let switch also push a new branch | 01:10 |
| awilkins | bzr switch bar --branch | 01:10 |
| ToyKeeper | Instead of switching branches in-place like in that .wmv earlier, I find myself keeping an 'active' symlink in the repo to point at the branch I want to use. That doesn't quite work the same, though. | 01:10 |
| awilkins | bzr switch bzr --branch -r 123 | 01:10 |
| bob2 | hm, how about bzr switch --create newbranch? | 01:11 |
| awilkins | THat might be clearer | 01:11 |
| fta | fullermd, seems i can't merge --uncommitted from a bzr+ssh url | 01:11 |
| bob2 | what's the rationale for not just commiting all these changes? | 01:12 |
| awilkins | fta: sftp may work | 01:12 |
| bob2 | not wanting them to show up in logs? no automatic handling of syncing multiple branches? | 01:12 |
| fta | awilkins, same, "is not a local path" | 01:13 |
| lifeless | awilkins: branch --switch would be my preference | 01:13 |
| lifeless | ToyKeeper: bzr viz can do multiple branches | 01:13 |
| fullermd | Oh, I forgot about that. WT access doesn't work remotely... | 01:13 |
| fullermd | Well, so much for THAT beautiful idea. | 01:14 |
| bob2 | that would be complicated with branch's existing positional arguments | 01:14 |
| lifeless | ToyKeeper: but repos are just storage access, not semantic; I can buy 'viz all branches under URL' | 01:14 |
| awilkins | lifeless: Would you include the current "sibling" logic that's in switch ; this seems to be something that those git people really like, the one-element-name of branching | 01:14 |
| bob2 | bzr branch --switch . ../newfeature, and loses switch's "sibling" support | 01:14 |
| lifeless | awilkins: yes, there is a bug open to propogate that | 01:14 |
| lifeless | also, are you aware of cbranch | 01:14 |
| lifeless | which already does much of this | 01:14 |
| awilkins | No | 01:15 |
| lifeless | ToyKeeper: we have 'repo' level push/pull with multi-push/multi-pull | 01:15 |
| awilkins | cbranch is not mentioned on the BzrTools page | 01:16 |
| * markh hopes to hear someone lamenting the lack of a -r option to 'bzr up'... | 01:18 | |
| * awilkins found that really counter-intuitive after using SVN for so lon | 01:18 | |
| markh | me too - and I have a patch - which is why I'm hoping to hear someone complain ;) | 01:19 |
| markh | I resurrected a patch that was initially targetted at version 1.3! I fear it will similarly languish now... | 01:24 |
| markh | would it do that in response to 'bzr up -r'? ;) | 01:26 |
| fullermd | Oh, yeah, we need a VSS mode. %bzr commit Warning: This setting will store your changes without any corruption. Are you sure you want to proceed? (y/n) | 01:26 |
| jam | lifeless: bzr+ssh:// uses the _create_pack_from_packs code, isn't that the same as local? | 01:26 |
| markh | actually, my first response to a merge was "OMG, why does bzr think 1/2 this file is in conflict?". lifeless kindly then pointed out '--reprocess' which has become invaluable for me | 01:27 |
| awilkins | I liked the merge I did from a branch that didn't even have a shared ancestry (but was a very similar tree) :-) | 01:28 |
| markh | I've seen the awesomeness of bzr merging since then ;) | 01:32 |
| awilkins | My users are getting to like it | 01:32 |
| awilkins | Time for sleepsicles | 01:46 |
| lifeless | markh: if its not in bundlebuggy, it won't get reviewed | 01:50 |
| lifeless | being attached to a bug report is essentially useless | 01:51 |
| markh | ok, I'll try that - thanks | 01:51 |
| lifeless | jam: were you happy with my reply-to-your-review? | 02:02 |
| lifeless | jml: please send your addCleanup improvements to bzr, or is that done ? | 02:11 |
| === bigdog is now known as _bigdog | ||
| lifeless | is there an operator.attrsetter I wonder... | 02:12 |
| lifeless | bope | 02:13 |
| lifeless | nope | 02:13 |
| lifeless | there should be | 02:13 |
| ToyKeeper | Hmm, speaking of not using launchpad features... where should I send changes to bzr-merge-into? | 02:13 |
| bob2 | functools.partial + setattr! | 02:14 |
| lifeless | oh eep | 02:14 |
| jml | lifeless: they were approved, but maybe not landed? | 02:14 |
| ToyKeeper | It appears to be jam's plugin, but I'm not sure what he uses for merge requests. | 02:15 |
| jml | lifeless: I don't have commit privs. | 02:15 |
| lifeless | self.addCleanup(functools.partial(setattr, bzrlib.btree_index, '_PAGE_SIZE'), original_size) | 02:15 |
| lifeless | bob2: ^evil | 02:15 |
| lifeless | ToyKeeper: I'd file a bug and attach a branch and propose for merging | 02:16 |
| ToyKeeper | I did. | 02:16 |
| lifeless | cool | 02:16 |
| === toytoy_ is now known as toytoy | ||
| ToyKeeper | It was a month ago, and there was no response, so I thought maybe it needed to go through BB or some other channel. | 02:17 |
| lifeless | oh | 02:17 |
| lifeless | hey may not be subscribed to the branch; when reviews were added that was not set as the default | 02:17 |
| lifeless | drop him a mail ;) | 02:18 |
| ToyKeeper | ... just came to mind because of the mention earlier about not attaching patches to bug reports. :) | 02:18 |
| lifeless | ToyKeeper: yah, plugins are not all in BB though | 02:19 |
| lifeless | I saw some merge-into work last week or so | 02:19 |
| lifeless | possibly he just missed your patch? | 02:19 |
| jml | lifeless: do you want me to chase up whether the patch landed or do you want to? | 02:20 |
| lifeless | jml: no need | 02:20 |
| jml | ok. | 02:20 |
| * jml goes away | 02:20 | |
| lifeless | 11:15 < lifeless> self.addCleanup(functools.partial(setattr, bzrlib.btree_index, '_PAGE_SIZE'), original_size) | 02:20 |
| lifeless | ^ thats too evil anyhow | 02:20 |
| ToyKeeper | Hmm, the last rev looks like it implements part of what I changed. I'll bug him about it later. | 02:23 |
| jam | ToyKeeper: I certainly don't remember seeing any patches/branches for bzr-merge-into | 02:29 |
| jam | lifeless: Your response to the log review was fine | 02:29 |
| jam | lifeless: I would like a little bit more feedback on the btree stuff | 02:30 |
| ToyKeeper | jam: https://bugs.launchpad.net/bzr-merge-into/+bug/252188 | 02:30 |
| ubottu | Launchpad bug 252188 in bzr-merge-into "subdir is always from repo root, not current dir" [Undecided,In progress] | 02:30 |
| jam | ToyKeeper: hm... never saw that one. But I think it is already "fixed" | 02:30 |
| jam | when I changed it to support the "canonical" form | 02:30 |
| jam | ToyKeeper: can you check? | 02:30 |
| jam | ToyKeeper: I think I did it by doing "WT.open_containing(join(this_location, subdir)) rather than the other way around | 02:32 |
| jam | which also lets you do | 02:33 |
| ToyKeeper | jam: Just checked, and trunk r7 seems to fix that issue. | 02:33 |
| ToyKeeper | I fixed a couple other things too: I made the subdir parameter optional (default to basename of LOCATION), and added missing '\n's on the output. | 02:34 |
| lifeless | jam: well, I'm happy - thus the :tweak | 02:34 |
| lifeless | I've replied and said roughly that | 02:35 |
| jam | lifeless: sure, just trying to get some ideas about how to actually update it | 02:35 |
| lifeless | righto | 02:35 |
| lifeless | uhm, see if my mail helps | 02:35 |
| lifeless | otherwise, I'm probably missing what you're asking :) | 02:35 |
| jam | ToyKeeper: sure, I'll merge it and then revert out the one change, it will probably conflict anyway | 02:36 |
| jam | ToyKeeper: did you ever "request a review" ? Or just propose it for merging? | 02:37 |
| jam | lifeless: And BB is still much better for code reviewing, as you can see the whole diff | 02:37 |
| lifeless | jam: you're probably not subscribed to the branch fully | 02:37 |
| jam | Though I guess abentley is improving that | 02:37 |
| lifeless | jam: yeah it is | 02:37 |
| jam | lifeless: yeah, I just "subscribed" to my branch | 02:38 |
| jam | ToyKeeper: though you didn't add tests for your functionality :) | 02:38 |
| ToyKeeper | Hmm, I haven't used LP's code review features much yet. I thought making a merge request automatically requested review from the owner of the target branch. | 02:39 |
| jam | well, it would probably send me an email if I was subscribed to the branch | 02:42 |
| jam | (which i am now) | 02:42 |
| jam | but it isn't quite the same | 02:42 |
| jam | request-review is a bit more focused on a specific person to review | 02:42 |
| jam | as opposed to "anyone who is around" | 02:42 |
| jam | anyway, your changes are merged | 02:43 |
| ToyKeeper | I know they're pretty trivial changes... I had forgotten all about it until lifeless said something to remind me. | 02:44 |
| ToyKeeper | Anyway, thanks for the plugin. It's handy. :) | 02:46 |
| ToyKeeper | Now I just need a way to do the opposite of merge-into... split a subdir into a new branch with only that subdir's history. | 02:47 |
| jam | ToyKeeper: with or without rebasing? | 02:47 |
| jam | There is already "bzr split" which is a core command (it may only be exposed if you have -subtree formats) | 02:47 |
| jam | But it still preserves *all* history | 02:48 |
| jam | as you can't do otherwise without regenerating the history for those files | 02:48 |
| ToyKeeper | Doesn't matter to me. 'bzr split' plus 'bzr remove-revision' would be fine, except the latter doesn't work. | 02:48 |
| jam | i don't know what 'remove-revision' would even be trying to do | 02:49 |
| ToyKeeper | It's at http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/ | 02:50 |
| jam | ToyKeeper: that wouldn't do what you want anyway | 02:51 |
| jam | It is only a "garbage collect" for unreferenced revisions | 02:51 |
| jam | these are all referenced | 02:51 |
| ToyKeeper | Ah. | 02:51 |
| jam | as part of the history of the split out branch | 02:51 |
| jam | You would really need to rebase, in which case the split out project could no longer be merged back into the old project | 02:52 |
| jam | which is still good enough for what some people want | 02:52 |
| jam | it wouldn't be strictly hard to do, though you have to get a little bit tricky at merge times | 02:52 |
| fullermd | Well, if you rebuilt the history with the same file-id's, you could do a null-merge right off the bat, and it would work going forward. | 02:52 |
| jam | fullermd: yeah, I think so, but I wouldn't bet on it :) | 02:53 |
| fullermd | Well, I've used --file-ids-from to do similar things on a smaller scale. | 02:53 |
| ToyKeeper | Yeah. I just wanted to break a branch into pieces, because it included things which shouldn't have been together. | 02:53 |
| jam | lifeless: your final review is what I was looking for, thanks | 02:53 |
| jam | ToyKeeper: then again, it would still be in the history of the parent project, unless you regenerated all of *those* revisions | 02:54 |
| lifeless | jam: cool | 02:55 |
| ToyKeeper | I've occasionally seen svn people put every project into a giant shared repo, with /repo/trunk/project*/... seems better to do one repo per project instead. | 02:56 |
| ToyKeeper | I ran into something like that in bzr, and wanted to split the projects into completely independent repos. | 02:57 |
| lifeless | I'd really like to be able to do bzr search -s "foo -bar" | 03:15 |
| lifeless | but I need to think some more about how to do that elegantly | 03:15 |
| lifeless | food first | 03:15 |
| jam | lifeless: would you want a way to "refine" searches interactively | 03:16 |
| lifeless | jam: like loggerhead does ? :) | 03:17 |
| jam | union, intersection, etc | 03:17 |
| jam | give me the revisions that match X | 03:17 |
| jam | and then the subset that also match Y | 03:17 |
| lifeless | meh, I meant to type 'bzr log -s "foo -bar"' | 03:17 |
| jam | and as you mentioned | 03:17 |
| jam | but *don't* match bar | 03:17 |
| lifeless | jam: I am happy with google level complexity in the searches | 03:18 |
| lifeless | jam: which is not much | 03:18 |
| lifeless | jam: 'bzr search robert -collins' already works | 03:18 |
| lifeless | back in 10, must eat food | 03:18 |
| lifeless | so | 03:33 |
| lifeless | jam: bzr search - I want to grow search types of date: (with before/after) and revision: etc, as well as handling NEWS and src/Makefile.am to match paths | 03:34 |
| lifeless | ETIME | 03:34 |
| rocky | jelmer: what is "bzr svn-branching-scheme" for exactly? :) | 03:43 |
| jelmer | rocky, it's what determines what in the repository bzr-svn considers a branch (a place where bzr revision can be found) | 03:43 |
| jelmer | changing it will break your existing imports though (you'll get DivergedBranches errors) so you'd want to stay away from it | 03:44 |
| jelmer | it'll be replaced by something simpler in 0.5 | 03:44 |
| rocky | well, the output from: bzr svn-branching-scheme https://dev.serverzen.com/svn/cluemapper/ClueMapper shows just ClueMapper which is odd since ClueMapper isn't a branch | 03:44 |
| jelmer | rocky, it determines what branching scheme it'll use based on what location you branch | 03:46 |
| jelmer | you'd probably want "bzr svn-branching-scheme https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk" | 03:47 |
| jelmer | since you're branching trunk | 03:47 |
| rocky | right | 03:47 |
| === wantok is now known as kgoetz | ||
| lifeless | man | 05:49 |
| lifeless | I want marks so bad | 05:49 |
| * lifeless starts on marks | 05:50 | |
| * RAOF_ ponders what "marks" could mean in a lifeless-bzr context... | 05:50 | |
| mwhudson | is it missing an apostrophe and "lovely hair" ? | 05:50 |
| === RAOF_ is now known as RAOF | ||
| lifeless | https://lists.ubuntu.com/archives/bazaar/2008q3/044481.html | 05:52 |
| * RAOF brushes his lovely hair. | 05:53 | |
| fullermd | Shoulder length or longer? | 05:53 |
| RAOF | About sholder length. Slightly longer. | 05:54 |
| spm | lifeless: (ref 'marks' vs hair) - sounds (hand wavy) loosely like my experience with svn merge conflict handling via eclipse? Sorta thing. ??? | 05:57 |
| * RAOF contends that his internet will _eventually_ connect to lists.ubunut.com. | 05:57 | |
| mwhudson | ubunut ? | 05:58 |
| RAOF | Yeah. It's like ubuntu, but for squirrels. | 05:58 |
| mwhudson | cool | 05:58 |
| fullermd | So there are lots of long-term support releases, but you can't remember where you buried them? | 05:59 |
| lifeless | spm: I don't know what your experience is | 05:59 |
| jml | lifeless: marks? | 06:03 |
| RAOF | Heh. | 06:03 |
| jml | oh, link | 06:03 |
| * jml reads | 06:03 | |
| RAOF | Yes! I have lists.u.c connection. | 06:04 |
| lifeless | jml: what do you think | 06:14 |
| jml | lifeless: I think you should have someone who follows you around finishing the awesome stuff you start :) | 06:15 |
| RAOF | That does look rather cool. | 06:16 |
| lifeless | jml: that would be nice | 06:17 |
| jml | lifeless: the design looks pretty good to me. | 06:17 |
| jml | lifeless: IIUC, there are multiple named subsets of changes, one of which is selected? | 06:18 |
| lifeless | some of which are | 06:19 |
| lifeless | -Mreviewed,tests | 06:19 |
| jml | lifeless: right, so what I mean is that I could select the 'tests' set of changes? | 06:20 |
| lifeless | yes | 06:20 |
| lifeless | or exclude it | 06:20 |
| jml | right. | 06:21 |
| lifeless | I'd love a web review ui for this | 06:21 |
| * jml is busy on other Bazaar hosting issue | 06:21 | |
| jml | *issues, rather | 06:21 |
| lifeless | well | 06:22 |
| lifeless | it needs core code first | 06:22 |
| lifeless | but as an end goal | 06:22 |
| lifeless | imagine going to launchpad | 06:22 |
| lifeless | doing half a review | 06:22 |
| jml | yeah, that'd be sweet. | 06:23 |
| jml | or in emacs | 06:24 |
| lifeless | ya | 06:29 |
| jml | lifeless: the plugin I should use to perhaps improve my push speed, what was it called again? | 06:53 |
| lifeless | index2 | 06:59 |
| lifeless | which needs pybloom as well | 06:59 |
| loxs | folks, probably i dont write it right, but I can't create a branch... i use the following syntax: bzr branch trunk/ tags/version1.6 | 08:54 |
| lifeless | and what happens? | 08:55 |
| loxs | in windows bzr: ERROR: Not a branch: "D:/MyProject/MyProject/" | 08:56 |
| lifeless | well, is it a branch? | 08:56 |
| loxs | I have no idea, I'm a newbie :) | 08:57 |
| loxs | I init-ed the project | 08:57 |
| loxs | and commited it | 08:57 |
| lifeless | ok | 08:57 |
| loxs | now I want to create a branch | 08:57 |
| lifeless | where did you init ? | 08:57 |
| loxs | in the directory containing trunk/ | 08:57 |
| lifeless | so the directory containing trunk is your first branch | 08:58 |
| lifeless | init creates a branch | 08:58 |
| lifeless | (the first one in a project) | 08:58 |
| loxs | so how do I create a branch tags/version1.6? | 08:58 |
| lifeless | bzr branch <path to your current branch> tags/version1.6 | 08:59 |
| lifeless | what does bzr info show ? | 08:59 |
| loxs | ok, parent of bersion1.6 doesn't exist | 08:59 |
| loxs | after I create the dir tags, to I add it via bzr add? | 09:00 |
| lifeless | no | 09:00 |
| loxs | then I just md and create the branch? | 09:00 |
| gour | loxs: reading of http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#concepts might help you | 09:01 |
| loxs | I read that, but it's quite general :( | 09:02 |
| lifeless | loxs: yes, you mkdir dir tags if it doesn't exist | 09:02 |
| lifeless | loxs: then branch <current branch> tags/version1.6 | 09:02 |
| loxs | and when I commit, the version1.6 branch won't go to the central repo? | 09:04 |
| loxs | hm, I think I start to understand the concepts now | 09:04 |
| loxs | ok, thanks folks | 09:04 |
| gour | it's not svn ;) | 09:05 |
| loxs | yeah, i'm starting to realise it gour :) | 09:07 |
| gour | loxs: yesterday, i tried for the first time bzr-svn...it's great. now i can use bzr to fetch from svn repos :-) | 09:08 |
| gour | loxs: it's much more flexible when you get in. you'll see. good luck ;) | 09:08 |
| loxs | thanks :) | 09:09 |
| shodges | hey all, is there an equivalent to "svn status -u"? I want to see the changes on the remote branch before I pull them | 09:09 |
| shodges | for bazaar, of course :) | 09:10 |
| RAOF | shodges: I'm not entirely sure what 'svn status -u' does. 'bzr missing' will give you the log between the current tree and the remote tree, though. | 09:17 |
| RAOF | (bzr missing will check against the default pull branch, or you can 'bzr missing $OTHERBRANCH') | 09:18 |
| lifeless | RAOF: or diff -rbranch:other | 09:19 |
| lifeless | shodges: or status -rbranch:other | 09:19 |
| gour | missing might be the right thing... | 09:22 |
| shodges | thanks everyone, i'll have a play around | 09:22 |
| shodges | ok i've had a go, bzr missing is definitely useful, but what I want right now is something that will tell me which files have been modified, rather than the pending commits | 09:34 |
| lifeless | shodges: 'bzr st -rbranch:URL' | 09:34 |
| lifeless | shodges: as I said before :P | 09:35 |
| shodges | yeah i thought so too lifeless, so i tried bzr status -rbranch, and i it threw a nasty stacktrace | 09:36 |
| lifeless | really? | 09:36 |
| shodges | i typed: "bzr status -rbranch:../test/src" | 09:37 |
| shodges | which is a modified local branch i created for testing this out on | 09:37 |
| lifeless | can you pastebin the traceback? | 09:37 |
| shodges | sure can, just a sec | 09:37 |
| shodges | this is the traceback: http://pastebin.com/d29ae0346 | 09:39 |
| gour | shodges: can you upgrade bzr? | 09:41 |
| luks | gour: will not help | 09:42 |
| luks | it's an old bug | 09:42 |
| luks | (design issue) | 09:42 |
| gour | luks: using absolute path? | 09:42 |
| luks | no, -rbranch: is broken | 09:43 |
| gour | ahh | 09:43 |
| shodges | gour, i tried an absolute path as well, same output | 09:43 |
| * gour wonders why would lifeless recommend it then | 09:44 | |
| shodges | i could try upgrading bazaar, but would i assume if the break is in my .bzr index then it will still throw the same error? | 09:47 |
| shodges | I found a work-around: bzr merge --preview ../test/src | grep "===" | 09:47 |
| shodges | not elegant, but does the job | 09:47 |
| gour | shodges: at least, you can create alias for it :-) | 09:54 |
| shodges | good idea gour :) i like "bzr missing" tho, will find them both useful in the future | 09:56 |
| shodges | thanks for the help everyone | 09:56 |
| lifeless | hmm | 10:00 |
| lifeless | Its not a design bug | 10:00 |
| lifeless | just needs to be fixed | 10:00 |
| lifeless | either by upgrading the lock, allowing status to read from two sources, or similar | 10:01 |
| === jrydberg_ is now known as jrydberg | ||
| luks | lifeless: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/35853 | 10:05 |
| lifeless | FF just bit it | 10:06 |
| lifeless | I only saw the start of the page | 10:06 |
| luks | jam had a similar fix for it, never merged too | 10:06 |
| luks | I'm personally surprised that broken code is considered better than working code, even if following a bad design, but it's not my decision :) | 10:07 |
| lifeless | uhm | 10:07 |
| lifeless | you have a choice of break | 10:07 |
| lifeless | broken on read only media | 10:07 |
| lifeless | and broken when pull-is-needed | 10:08 |
| lifeless | so its not 'broken vs working' | 10:08 |
| lifeless | its 'broken in case A vs broken in case B' | 10:08 |
| lifeless | and I think you're being rather judgemental saying the design is broken, when its not clearly a design issue | 10:08 |
| jml | hello #bzr | 10:08 |
| luks | lifeless: I was told that by jam and abentley | 10:09 |
| luks | lifeless: the code needs to be rewritten to allow reading from remote repositories | 10:09 |
| jml | I've got a branch, and I want to take one of the revisions and get rid of it. | 10:09 |
| lifeless | luks: uhm I don't know if you're aware, but saying 'bad design' provokes a certain response | 10:10 |
| lifeless | which is either agreement, or defense. I think the design is fine, thus you are getting defense | 10:10 |
| lifeless | if you have a specific issue in the design, that would be worth talking about | 10:10 |
| lifeless | jml: tip ? | 10:10 |
| luks | lifeless: if two core devs tell me that it's was a bad choice to allow write operation on RevisionSpec, then I think it is a bad design | 10:10 |
| jml | lifeless: is that a plugin? | 10:11 |
| lifeless | jml: no, I'm asking if the revision is the tip revision | 10:11 |
| jml | lifeless: oh, no. | 10:11 |
| lifeless | in which case rebase is probably your easiest bet | 10:11 |
| jml | lifeless: I know about uncommit :) | 10:11 |
| lifeless | there was a thread recently | 10:11 |
| * jml searches | 10:12 | |
| lifeless | luks: you've just doubled the granularity from 'bad design' to 'write operations on revisionspec is a bad design choice' | 10:12 |
| lifeless | thats massively more informative | 10:12 |
| lifeless | anyhow, as another core dev, I don't think it was a bad choice | 10:12 |
| lifeless | I don't think its ideal | 10:12 |
| lifeless | and I think we can do better | 10:12 |
| lifeless | but given the constraints of the time, and the performance issues around the area, I think it was the right choice at the time | 10:13 |
| luks | of course I meant the 'bad design' before only regarding to write operations in revisionspec | 10:13 |
| luks | sorry for not beeing clear enough | 10:13 |
| lifeless | I had no idea what you meant | 10:13 |
| lifeless | and given, at last count, something over 50% of the core is ascribed to me by gannotate, a little clarity really helps :) | 10:14 |
| luks | :) | 10:14 |
| jml | also, another thing I'd like to do is review the diff of each commit in a range of revisions | 10:15 |
| luks | well, anyway, I fully understand that there are better ways to fix it, but I don't understand why reject the lock upgrading as an interim fix | 10:15 |
| lifeless | luks: because it breaks another not-uncommon use case - doing status in a tree where you can't write lock the repository | 10:15 |
| jml | I guess it wouldn't be too hard to whip up a script | 10:15 |
| lifeless | jml: yeah, or merge + commit-reviewed each individually | 10:16 |
| luks | lifeless: it's already broken in that case | 10:16 |
| jml | lifeless: well, it's more that I just want to look at them one by one | 10:16 |
| luks | so it would be no worse | 10:16 |
| lifeless | luks: how is it broken ? | 10:16 |
| luks | lifeless: try bzr st -r branch:path/to/different/repo/branch if you don't have write acces to the local tree | 10:17 |
| lifeless | luks: I didn't say tree, I said repository | 10:17 |
| lifeless | luks: and I'm not talking about -r usage, plain ol 'bzr st' | 10:17 |
| luks | lifeless: my patch used lock_write only if the revisionspec requires it | 10:17 |
| luks | so in plain bzr st it would use lock_read | 10:18 |
| luks | and in case lock_write is not available, st -rbranch is broken anyway | 10:18 |
| luks | so yes, there are still cases where it's broken, but it would fix the main use case | 10:19 |
| lifeless | luks: well, I've just replied with a small change to allow status to work | 10:29 |
| luks | hm, as_revision_tree is a good idea | 10:30 |
| lifeless | probably < 2 hours work if you're interested in doing it, and its straight forward | 10:31 |
| lifeless | or even 'as_tree' | 10:32 |
| lifeless | for a possibly better/more useful interface | 10:32 |
| luks | I realise that, but there are some cases where the remote branch instance is required as well | 10:32 |
| luks | so it would need one more interface for those cases | 10:32 |
| lifeless | for status? | 10:33 |
| luks | no | 10:33 |
| lifeless | well, details then, and I can comment | 10:33 |
| luks | what I was primarily interested in was adding a global lock around diff | 10:34 |
| luks | I see that revisiontree has _repository, which would be enough, but that's private | 10:34 |
| lifeless | what do you need a repository object for ? | 10:34 |
| luks | oh, wait, I don't | 10:35 |
| luks | yeah, you are right | 10:35 |
| luks | I will probably look into this over weekend | 10:35 |
| luks | as_revision_tree is really a good way to solve this | 10:36 |
| lifeless | I think I'd call it as_tree | 10:39 |
| lifeless | to allow real and revision tree objects | 10:39 |
| * jml gets confused by rebase | 10:45 | |
| lifeless | jml: it is confusing | 10:52 |
| lifeless | jml: you want replay | 10:52 |
| lifeless | jml: and to skip the revision you don't want | 10:53 |
| lifeless | jml: or just do cherry pick merges all the way up | 10:53 |
| * jml finally has a happy branch | 11:07 | |
| jml | this is the danger of learning in front of Idol | 11:08 |
| gour | are looms better than using rebase? | 11:08 |
| jml | gour: yes. | 11:08 |
| luks | they are something different | 11:08 |
| jml | fsvo 'better' :) | 11:09 |
| jml | lifeless: so, I've got a testresources branch without those licensing changes. do you want any other changes before re-review? | 11:16 |
| === gour is now known as gour|away | ||
| lifeless | uh, anything else I said my mail | 11:27 |
| lifeless | jml: if there isn't a NEWS file, we should add one that describes how existing users need to change their resources to accomodate the patch | 11:28 |
| * jml adds one and resubmits | 11:35 | |
| gnomefreak | how would i remove a push i made. i used uncommit but now i need to merge them but i dont want that push to be htere | 11:40 |
| gnomefreak | there | 11:40 |
| luks | you can push --overwrite | 11:40 |
| luks | but double check you are not overwriting something you don't want to | 11:41 |
| gnomefreak | will try it | 11:42 |
| luks | also, this is a bad thing to do on a public branch | 11:42 |
| luks | if there is a possiblity other people have branched/pulled from it | 11:42 |
| ^_- | hm | 11:50 |
| ^_- | what's the main difference between a repository created with --no-trees and one that isn't? | 11:50 |
| ^_- | er rather | 11:53 |
| ^_- | what's the advantage and disadvantage of creating a repository with --no-trees ? | 11:53 |
| siretart | you have no trees, that is, you save space for the checkouts, and branching is a bit faster, since you don't need to build them | 11:55 |
| ^_- | siretart, so this should be used for central servers? | 11:55 |
| ^_- | er would be best used | 11:55 |
| lifeless | ^_-: or if you want to reuse a single tree | 12:02 |
| lifeless | which C style languages often want to | 12:03 |
| lifeless | because compilation is slow | 12:03 |
| ^_- | heh | 12:05 |
| luks | lifeless: can I please get a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1219921582.6859.3.camel%40nemo%3E (it's really trivial, and introduced by your change)? | 12:16 |
| Peng_ | Is it just me, or is bzr-search broken on bzr.dev? | 12:51 |
| lifeless | shouldn't be broken, works for me | 12:51 |
| Peng_ | Hmm | 12:51 |
| Peng_ | I just pulled bzr.dev and bzr-svn for the first time since yesterday or so, and bzr-search exploded. | 12:51 |
| Peng_ | bzr.dev r3652 (the log filtering stuff) broke it. | 12:53 |
| Peng_ | If I revert to the revision before that, it's fine. | 12:54 |
| james_w | where's the heads plugin? | 12:55 |
| Peng_ | Where? | 12:55 |
| james_w | I can't find it on the plugin page, nor via google | 12:55 |
| Peng_ | james_w: Oh. bzrtools, apparently | 12:56 |
| james_w | ah, thanks | 12:56 |
| Peng_ | It was merged into bzrtools in May. | 12:57 |
| thumper | lifeless: is there a package for bzr-svn? | 13:05 |
| thumper | or anyone for that matter | 13:06 |
| thumper | jelmer: ? | 13:06 |
| Jc2k | thumper: there is one in PPA i think | 13:06 |
| thumper | Jc2k: thanks | 13:06 |
| thumper | Jc2k: which one? | 13:06 |
| Jc2k | thumper: https://launchpad.net/~bzr/+archive | 13:07 |
| thumper | Jc2k: thanks | 13:07 |
| Peng_ | lifeless: r3652 breaks bzr-search on another computer too (where I have the exact same plugins, but..) | 13:07 |
| james_w | Peng_: with a traceback, or just "not work"? | 13:16 |
| Peng_ | Hm | 13:19 |
| Peng_ | james_w: Just "Unable to load plugin 'search'" | 13:20 |
| james_w | Peng: -Derror? | 13:20 |
| beuno | the traceback goes to .bzr.log (hi) | 13:21 |
| Peng_ | Yeah, I was just looking at .bzr.log. Hold on, I'll pastebin. | 13:21 |
| james_w | bey beuno | 13:22 |
| james_w | I find -Derror more convenient, but they both work | 13:22 |
| Peng_ | http://paste.pocoo.org/show/83610/ | 13:22 |
| beuno | james_w, aaah, interesting. It is much more convinient | 13:22 |
| Peng_ | I've never used -Derror before. I'll try to remember it. | 13:23 |
| lifeless | Peng_: you need 3653 perhaps ? :) | 13:24 |
| lifeless | Peng_: sorry, rev 55 | 13:24 |
| lifeless | Peng_: and then you can try log -m '\bfoo\b' and go oooo at speed | 13:24 |
| lifeless | luks: can you drop me a mail please | 13:25 |
| lifeless | luks: I will review tomorrow | 13:25 |
| luks | lifeless: thanks | 13:25 |
| Peng_ | lifeless: Eh? | 13:25 |
| lifeless | Peng_: bzr-search rev 55 | 13:25 |
| lifeless | Peng_: committed 8 or so hours back; grab it :) | 13:25 |
| Peng_ | I am on that revision, though I didn't know it. | 13:26 |
| lifeless | hmm | 13:27 |
| Peng_ | I pulled bzr-search at the same time as bzr-svn and bzr.dev, and the first time I pulled, there was a traceback, but I wasn't able to reproduce it. | 13:27 |
| lifeless | all the references I can find ot make_search_filter are _ prefixed in bzr-search rev 55 | 13:28 |
| lifeless | Peng_: try 'bzr update' or 'bzr revert' in your search branch | 13:28 |
| lifeless | I bet the tree is out of date, if search was borked | 13:28 |
| Peng_ | lifeless: You are correct. | 13:29 |
| Peng_ | Now it works. | 13:29 |
| Peng_ | How did that happen? I needed to run "bzr update". I guess that traceback did it? | 13:29 |
| lifeless | so pull updates branch, then tree | 13:30 |
| lifeless | I bet that search crashed on the branch update after the tip changed, before the tree is update | 13:30 |
| lifeless | d | 13:30 |
| Peng_ | Hah, the exact same thing happened when I pushed the new revisions of bzr-search to the other computer. | 13:32 |
| Peng_ | Same traceback, and it didn't run "update". | 13:32 |
| Peng_ | But I ran update and now it's okay. | 13:32 |
| lifeless | now | 13:32 |
| lifeless | grab an indexed branch | 13:32 |
| lifeless | and run bzr log -m '\bSEARCHTERM\b' | 13:33 |
| Peng_ | I guess I shouldn't update software while it's running. | 13:33 |
| lifeless | try it again with --no-plugins | 13:33 |
| lifeless | the traceback was because I pushed rev 54 yesteday | 13:33 |
| lifeless | which added log -m support with my custom branch | 13:33 |
| Peng_ | I was on rev 53. | 13:34 |
| lifeless | then bzr.dev broke than when the reviewed code landed | 13:34 |
| Peng_ | I think. | 13:34 |
| lifeless | where you? I doubt it | 13:34 |
| Peng_ | Yeah, I was. | 13:34 |
| lifeless | oh | 13:34 |
| lifeless | I forgot 55 was trivial | 13:34 |
| lifeless | yeah 53 would do it | 13:34 |
| Peng_ | ok | 13:34 |
| lifeless | its just a case of 'you ran trunk' | 13:34 |
| Peng_ | :) | 13:35 |
| lifeless | anyhow | 13:36 |
| lifeless | how does the log acceleration work for you ? | 13:36 |
| Peng_ | I don't have any large branches with indexes. | 13:36 |
| lifeless | ah, k | 13:37 |
| lifeless | should still be faster on small branches | 13:37 |
| Peng_ | On one branch, it takes ~0.7 seconds either way. | 13:37 |
| lifeless | oh yeah, thats under threshold :P | 13:37 |
| Peng_ | It bothers me that you can do "bzr pull -v", but if there's a traceback at the wrong time, you'll have no idea you pulled anything. | 13:39 |
| lifeless | mmm | 13:40 |
| lifeless | probably has to do with how pull -v is hooked in | 13:40 |
| Tak | is it recommended to use --hardlink when branching locally? | 13:48 |
| ricardokirkner | hi. I am trying to check out a project from launchpad, and I am getting a connection timeout (I am behind a http proxy). I have set up the http_proxy variable, so I dont understand why I am gettig the timeout. how can I debug this issue? | 14:30 |
| techtonik | ricardokirkner: add -Dhttp to command line | 14:33 |
| techtonik | also bzr help global-options | 14:33 |
| lifeless | ricardokirkner: is your proxy squid 2.6stable23 or less ? | 14:37 |
| techtonik | lifeless: How can I specify proxy for bzr+ssh connection? | 14:44 |
| lifeless | techtonik: bzr+ssh doesn't use http at all | 14:44 |
| lifeless | techtonik: it uses ssh | 14:45 |
| techtonik | I know. | 14:45 |
| ToyKeeper | techtonik: I'd suggest using ~/.ssh/config to configure bzr+ssh details. | 14:45 |
| techtonik | I am on windows. | 14:45 |
| techtonik | My proxy supports CONNECT, but I need to bzr somehow to use it. | 14:45 |
| lifeless | techtonik: unless you can find a ssh http-tunnel (there are some) for windows ... | 14:46 |
| ricardokirkner | lifeless, might be.. it's squid for sure. i don't know about the version | 14:48 |
| lifeless | ricardokirkner: there was a bug in squid, which we fixed, that is exacerbated by bzr's use of range requesws | 14:49 |
| techtonik | That's bad. Without proxy bzr+ssh worked without problems without any special tools except pageant for storing keys (I suppose through paramiko). Now I just need to specify proxy. Should I fill a bug report? | 14:49 |
| lifeless | ricardokirkner: it leads to very long delays in someoperations | 14:49 |
| lifeless | ricardokirkner: alternatively, if you've logged into launchpad, it may be trying to use bzr+ssh and if you have a firewall preventing ssh, timing out on that - so not http related at all | 14:50 |
| ricardokirkner | should I try to log out from launchpad? I am logged it, but haven't yet uploaded my ssh key | 14:51 |
| lifeless | ricardokirkner: you ran 'bzr launchpad-login' ? | 14:52 |
| lifeless | techtonik: uhm, you can file a bug, but there isn't anything bzr can do - here's why | 14:52 |
| lifeless | techtonik: we already support bzr+http and plain http - they proxy just fine. | 14:52 |
| ricardokirkner | lifeless, no.. do I need to do that in order to branch a lp project? | 14:53 |
| ricardokirkner | is it not possible to branch a project without having a user in lp? | 14:53 |
| lifeless | techtonik: bzr+ssh, to tunnel over http proxy, will need ssh support, and bzr calls out to ssh, its not something bzr has any deep control over | 14:53 |
| lifeless | ricardokirkner: its totally possible, I was just trying to check I understood your setup; if you _have_ logged in with bzr to lp, you can get a different network protocol used | 14:53 |
| ricardokirkner | lifeless, ok. no I haven't logged in | 14:54 |
| lifeless | ricardokirkner: so ifyou have not run launchpad-login from bzr, then its going to be using plain http I expect | 14:54 |
| ricardokirkner | via bzr | 14:54 |
| ricardokirkner | I am logged in in the web ui | 14:54 |
| lifeless | ricardokirkner: make sure you have exported the http_proxy and https_proxy variables | 14:54 |
| lifeless | techtonik: anyhow, its not the proxy that is the problem, its any related firewall :) | 14:56 |
| Tak | if I unbind, then rebind, what happens to the uncommitted changes in my local branch? | 14:57 |
| techtonik | lifeless: i am using SVN without any problems and even without any additional tunnels. i am wasting yet another day trying to push a change with bzr =( | 14:58 |
| techtonik | If I use https it fails - Transport operation not possible: http does not support mkdir() | 14:58 |
| techtonik | If I use bzr+ssh - it also fails with 10060 timeout. | 14:59 |
| lifeless | techtonik: svn+ssh would have exactly the same problem. What bzr service are you pushing to ? | 15:00 |
| techtonik | launchpad | 15:00 |
| techtonik | http://bazaar.launchpad.net/%7Etechtonik/codeblocks/devpak-plugin | 15:01 |
| jelmer | james_w, Sorry, I couldn't leave the merge-upstream-branch code alone; it's now updated against latest bzr-builddeb trunk | 15:03 |
| james_w | jelmer: well, no need to be sorry, I'm not going to complain about that. | 15:03 |
| james_w | I'll merge the four outstanding branches when I get a free minute, thanks for your help. | 15:04 |
| jelmer | james_w: Cool, thanks! | 15:04 |
| james_w | and I'll subscribe to the branches so that I don't miss things again. | 15:04 |
| === evarlast is now known as stinkyGrant | ||
| === stinkyGrant is now known as evarlast | ||
| ricardokirkner | lifeless, ok, the proxy setting was fine, because I could branch the project using the http address directly, instead of using the lp: address | 15:09 |
| ricardokirkner | so, maybe using lp: uses a non-http port? (which is surely filtered by our firewall) | 15:09 |
| Necoro | ricardokirkner: iirc, if you are "logged in" into LP on your machine, it uses bzr+ssh instead of http | 15:11 |
| lifeless | ricardokirkner: it does a XMLRPC check, which is https, first. | 15:11 |
| lifeless | I'd bet that that is what failed | 15:12 |
| lifeless | ricardokirkner: or you're logged in :) | 15:12 |
| ricardokirkner | so, if i am logged into the web ui, then it tries to do bzr+http | 15:12 |
| ricardokirkner | ok | 15:12 |
| Peng_ | lifeless, james_w and beuno: Since I forgot to mention it, thanks for the help with bzr-search earlier. :) | 15:12 |
| ricardokirkner | I will try to log out from launchpad.net | 15:12 |
| ricardokirkner | thank you | 15:12 |
| Necoro | ricardokirkner: no | 15:12 |
| Necoro | logged in on your machine | 15:12 |
| Necoro | i.e.: having run launchpad-login | 15:13 |
| ricardokirkner | Necoro, ok, I didn't login using launchpad-login | 15:13 |
| ricardokirkner | so that's not the problem | 15:13 |
| Necoro | ricardokirkner: than it is probably as lifeless said ;) | 15:13 |
| ricardokirkner | I will check it on some other machine that is not behind the firewall... I guess it's a firewall related problem | 15:13 |
| orospakr | Hey, how does one refer to a given commit in a project across all branches? It seems that commit numbers differ (even for the same commit!) depending on what branch you're on. | 15:24 |
| Necoro | orospakr: use the rev-id | 15:25 |
| onox | how can I remove just a specific revision? for example I have rev 1,2,3,4 and I want to have rev 1,2,4 | 15:26 |
| orospakr | ah, I see | 15:26 |
| orospakr | onox, nuclear launch codes? ;) | 15:26 |
| onox | lol, no | 15:27 |
| onox | I just want to get rid of some revisions that contain some .tar.gz files | 15:27 |
| onox | is that possible? | 15:28 |
| abentley | onox: Revisions are states. The state of revision 4 is based on the state of revision 3. So you would have to create a new revision 3, with only the changes made in revision four. | 15:29 |
| abentley | You can do that with merge, e.g. "bzr merge -c 4 ../my-old-branch". | 15:29 |
| uws | abentley: ...but that isn't tracked. Is merge tracking planned? | 15:31 |
| uws | for cherry-picking, that is. | 15:31 |
| abentley | uws: Yes. | 15:31 |
| uws | it would be GREAT to have for many projects. | 15:32 |
| onox | abentley: how can I do merge revisions 4 and 6? -c 4,6 doesn't seem to work | 15:37 |
| abentley | You want to combine revisions 4 and 6 into one revision? | 15:37 |
| onox | no, just 2 merges | 15:37 |
| uws | onox: just do it twice | 15:37 |
| uws | merge -c4; merge -c6 | 15:37 |
| onox | then bzr complains about uncommitted changes | 15:37 |
| uws | commit in between | 15:38 |
| uws | in bzr, you need to commit your merges | 15:38 |
| ToyKeeper | well, it's possible to merge more than once without committing between... but strongly discouraged. | 15:38 |
| onox | I want to do 1 commit of (in this case) 2 pending merges | 15:38 |
| uws | onox: afaik, you can't do that with cherry picking, only with regular merges | 15:38 |
| onox | hmm | 15:39 |
| abentley | onox: That would mean committing 4 and 6 as one revision. | 15:39 |
| onox | yes | 15:42 |
| onox | if I use -c I don't see "pending merges" in bzr stat | 15:42 |
| abentley | onox: That is true. | 15:43 |
| abentley | You are creating a new revision, as I said from the start. | 15:44 |
| abentley | In this cause, merge is just a way of applying the changes you made in 4 & 6. | 15:44 |
| ToyKeeper | Is the cherrypick merge data recorded but not used? | 15:46 |
| ToyKeeper | ... because, if not, you could just apply the patch from r4 and then apply the patch from r6, and commit. It'll look like an entirely new revision, but ... it would anyway. | 15:46 |
| abentley | ToyKeeper: No, the cherrypick merge data is not recorded. | 15:47 |
| onox | so with bzr there's no way to get rid of a specific rev? | 15:53 |
| ToyKeeper | You could uncommit it, if it's on top. Or possibly do something clever with rebase. | 15:54 |
| onox | rebase command doesn't exit | 15:54 |
| ToyKeeper | ... exist? | 15:54 |
| onox | yes, exist :p | 15:54 |
| ToyKeeper | It's at 'bzr branch lp:bzr-rebase', I think. | 15:55 |
| abentley | onox: There's no way to get rid of a specific rev while keeping the following revs. | 15:55 |
| abentley | rebase command has the same effect as merge -c. Which is also true in Git. | 15:56 |
| onox | is it possible to just merge the revisions of some directory of some branch? | 15:56 |
| onox | it seems it's possible, but bzr stat doesn't show "pending merges" | 15:57 |
| abentley | onox: Correct. | 15:57 |
| onox | why no "pending merges"? | 15:57 |
| onox | because it cherrypicks again? | 15:59 |
| abentley | onox: A "pending merge" is only shown when you apply all changes. | 15:59 |
| onox | and why not if I apply all changes to some directory? | 15:59 |
| abentley | Because that would mean you applied all the changes, and then removed the changes that didn't apply to that directory. | 16:01 |
| abentley | And when someone merged from you, it would remove all those other changes. | 16:02 |
| onox | is it safe to just merge everything, remove some .tar.gz files I don't want, and then commit? | 16:06 |
| jam | vila: in trying to follow lifeless's response about the trie. He uses the abbreviation "HP" do you think he means "PH" for Partion Hashing? Since that seems to be the closest term I've found in the paper he referenced | 16:07 |
| Hydrogen | so.. | 16:07 |
| lifeless | jam: hash partition | 16:07 |
| jam | lifeless: sure, but the only place the abbreviate is PH not HP, though they say each node tracks its "hash partition" | 16:07 |
| jam | anyway, you didn't define the term :) | 16:07 |
| Hydrogen | I'm trying to create a bzr branch from a svn+ssh login'd server on windows. I've installed bzr-svn and bzr, but when I run the command bzr crashes... is there a way to make it not crash? :) | 16:08 |
| jam | which made the paragraph a bit tricky, but to understand it anyway, I'll read the paper | 16:08 |
| abentley | onox: You should not make any unnecessary changes when merging. That can mess up later merges. So merge, commit, remove, commit. | 16:08 |
| jelmer | Hydrogen, what versions? | 16:08 |
| onox | abentley: k, thx for the advice | 16:08 |
| jam | On first pass, I agree that HP doesn't look like it plays well with partial updates and a "canonical" representation | 16:08 |
| Hydrogen | bzr 1.6b3... maybe I should update to 1.6 final :) | 16:09 |
| vila | jam: he said " The tree we build is essentially a tree of hash partitions" at the start of the paragraph he first mentioned HP | 16:11 |
| Hydrogen | mm, still crashing after updating | 16:12 |
| Hydrogen | 1.6 final | 16:12 |
| vila | lifeless: ho, you're still there ! Are you still in AU ? | 16:12 |
| lifeless | yes | 16:13 |
| jam | ah, k | 16:13 |
| jam | I guess that part didn't "stick". | 16:13 |
| jam | I *did* read it | 16:13 |
| jam | Hydrogen: can you give any more info than "it crashes" Like run with -Derror and pastebin a traceback? | 16:15 |
| jam | ubottu: paste | 16:15 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 16:15 |
| Hydrogen | well, I would, except the silly windows crash handler pops up without being helpful | 16:15 |
| jam | Hydrogen: so you are getting something like a segfault? Rather than a traceback + exception | 16:16 |
| Hydrogen | yea | 16:16 |
| jam | sounds like something wrong with the svn bindings | 16:16 |
| jam | as we don't have a lot to segfault in the bzr code | 16:16 |
| jam | Hydrogen, jelmer: Could it be an issue with the subversion libraries? | 16:17 |
| jam | Does 'bzr-svn' on windows bundle the subversion library? | 16:17 |
| jelmer | jam: I'm not sure, haven't ever tried it. Mark packaged it | 16:17 |
| jam | Hydrogen: my initial guess would be lib/dll skew. Where bzr-svn is compiled against say svn-1.4 and you are using 1.5 | 16:17 |
| Hydrogen | hmm | 16:18 |
| Hydrogen | that could very well be it | 16:18 |
| jam | jelmer: there doesn't seem to be a 0.4.11-svn, just 0.4.9 | 16:18 |
| jam | Does 0.4.9 *work* with 1.6? | 16:19 |
| jelmer | no, it won't | 16:19 |
| jam | jelmer: but would it segfault? | 16:19 |
| jelmer | I think mark packaged it as part of bzr itself though | 16:19 |
| jelmer | jam, It would probably warn you first | 16:19 |
| Hydrogen | hmm, using svn 1.4.6 or 1.5.0, both crash | 16:19 |
| jam | jelmer: I know he brought in some other stuff, I didn't think he included bzr-svn, I could be wrong | 16:19 |
| Hydrogen | however, I may not have the python-subversion bindings... but not sure where to put them | 16:19 |
| jelmer | Hydrogen, what did you install exactly? | 16:20 |
| Tak | btw, I'm successfully using bzr 1.5 with the bzr-svn windows package and svn 1.5 | 16:20 |
| Hydrogen | bazaar is in c:\program files\bazaar; subversion is in c:\program files\subversion :) | 16:20 |
| uws | bzr 1.6.x + bzr-svn works well with svn 1.4 as well | 16:20 |
| jam | Tak: that is the 0.4.9 version of bzr-svn? | 16:20 |
| Hydrogen | I have 0.4.10 of bzr-svn | 16:21 |
| Tak | 0.4.10 | 16:21 |
| Tak | I also have the python subversion bindings installed | 16:21 |
| Hydrogen | bzr-svn-0.4.10-svn-1.4.6-setup-0.exe | 16:21 |
| jam | Tak: here did you get that from? | 16:22 |
| Hydrogen | where do I install the python subversion bindings to :) | 16:22 |
| Tak | jam: which? | 16:22 |
| jam | 0.4.10 | 16:22 |
| jam | I don't see it on the LP download page | 16:22 |
| jam | so I'm wondering where it is | 16:22 |
| jelmer | Hydrogen, 0.4.10 won't work with bzr 1.6 | 16:22 |
| Hydrogen | ah | 16:23 |
| Hydrogen | I need 0.4.9 then? | 16:23 |
| jam | Ah, it seems someone has "unofficial builds": http://d5190871.u44.websitesource.net/bzr-svn/ | 16:23 |
| jelmer | Hydrogen, no, 0.4.11 | 16:23 |
| Hydrogen | oh | 16:23 |
| Hydrogen | okay | 16:23 |
| Hydrogen | :) | 16:23 |
| jam | Hydrogen: no, you need 0.4.11, but either way they shouldn't be segfaulting | 16:23 |
| Tak | http://d5190871.u44.websitesource.net/bzr-svn/ , linked from the Subversion page | 16:23 |
| jelmer | Hydrogen, there's no need for python subversion bindings to be installed anymore | 16:23 |
| Hydrogen | okay | 16:23 |
| jelmer | Yeah, that's Kevin Lights' page | 16:23 |
| Hydrogen | thanks | 16:23 |
| jam | I'm hesitant to trust a website at "d5190871.u44...." | 16:23 |
| Hydrogen | I'll grab the new version | 16:23 |
| jam | sure looks like a scammer :) | 16:23 |
| jam | Hydrogen: unfortunately, 0.4.11 doesn't seem to be packaged yet | 16:24 |
| jelmer | markh, ping | 16:24 |
| jam | markh is in AU time, and is probably sleeping right now | 16:24 |
| jelmer | ah, ok | 16:24 |
| jelmer | Mark did say he intended to package bzr-svn | 16:24 |
| jelmer | and we spent some time improving things in bzr-svn on Windows | 16:24 |
| Tak | pff, timezones | 16:25 |
| Tak | jam: it's linked from http://bazaar-vcs.org/BzrForeignBranches/Subversion#windows-setup | 16:25 |
| Hydrogen | jelmer: It can't be too impossible to build though, right? :) | 16:26 |
| jam | Tak: yeah, I found it that way. I'd rather have "official" builds :) | 16:26 |
| jelmer | Hydrogen, if you have a C compiler, it should be doable | 16:26 |
| Hydrogen | huzzah | 16:26 |
| Hydrogen | we're safe then! | 16:26 |
| Tak | hmph, I spent about 5min trying to build it on cygwin, then gave up and went back to bzr1.5 | 16:26 |
| jam | jelmer: well, and the svn dev libraries | 16:26 |
| jam | and some other bits | 16:26 |
| jam | jelmer: so the 1.6-setup.exe just gives "Default plugins" which is a 7.2MB install, but doesn't give any more details. | 16:27 |
| jelmer | ah | 16:27 |
| Tak | afaict, no svn plugin dir was created by the 1.6 installer | 16:28 |
| jelmer | according to Mark's announcement, bzrtools, qbzr and bzr-svn are included in the setup for the rc | 16:32 |
| jelmer | (1.6rc3) | 16:32 |
| Hydrogen | well, that didn't help :) | 16:47 |
| jelmer | Hydrogen, what did you try? | 16:52 |
| Hydrogen | downgrading to 1.6rc3 with the bundled one | 16:53 |
| jelmer | still segfaults? | 16:53 |
| Hydrogen | aye | 16:53 |
| jelmer | are you trying to checkout a public svn branch? | 17:02 |
| Hydrogen | It crashes on a public or a not public | 17:03 |
| Hydrogen | well | 17:03 |
| Hydrogen | a public (anonsvn) or one that requires svn+ssh credentials | 17:04 |
| === mark1 is now known as markh | ||
| jam | markh: what are you doing awake? | 17:34 |
| awilkins | How hard would it be to make the HPSS 100% smart? (at the moment a large percentage of it is still dumb, i.e. makes plain HTTP GET requests) | 17:41 |
| abentley | The HPSS does not make HTTP GET requests, because it runs on multiple protocols, including http(bzr+http:) ssh (bzr+ssh:) and direct tcp(bzr:) | 18:04 |
| jam | abentley: I think it still does a couple GET requests for stuff like .bzr/branch-format | 18:07 |
| jam | awilkins wants "bzr branch" to only POST to .bzr/smart | 18:07 |
| jam | with no other GET requests | 18:07 |
| awilkins | That's essentially it | 18:07 |
| jam | apparently IIS 6 is hard to configure correctly | 18:07 |
| awilkins | Having problems getting it to run on IIS 6 because it's awkward to get it to serve files AND direct requests to QSGI | 18:08 |
| awilkins | WSGI | 18:08 |
| abentley | awilkins: And this behavior is observed with bzr+http, not the autodetection? | 18:08 |
| abentley | jam: i would have expected those to go over the HPSS vfs layer. | 18:08 |
| awilkins | abentley: Yes, I've got a proxy sniffer and I can demonstrate it's behaviour ( I think I posted a session as an attachment to an IIS bug) | 18:08 |
| awilkins | The other option I have is to patch PyISAPIe which is the extension I'm using to serve it | 18:09 |
| awilkins | There is supposedly a mechanism to "pass to next handler" which could be used, but I'm a bit rusty on C and exposing it in Python | 18:09 |
| abentley | jam: But in fact, if HPSS is making a cacheable request, it would make sense for it to use a GET. | 18:10 |
| jam | awilkins: just to mention, it may be easier to have the "wgsi" server serve out GET requests | 18:10 |
| Okkin | Hi, | 18:10 |
| awilkins | jam: That would also be a reasonable idea | 18:11 |
| jam | awilkins: is there any chatter on GET after the initial connection? | 18:11 |
| Okkin | How can I get a pending merge message to use it as my commit message ? | 18:11 |
| jam | (I don't think HTTP transport as-a-medium changes the HPSS requests back into HTTP ones, but I was hoping for confirmation) | 18:11 |
| abentley | jam: Ooh, branch-format being the bzrdir format file. | 18:12 |
| awilkins | jam: I'll set an HPSS up on my local box and trace a few sessions | 18:12 |
| jam | abentley: right | 18:13 |
| abentley | I guess it makes me a bit nervous to start posting before we even know we're looking at a Bazaar control directory. | 18:13 |
| jam | Okkin: "bzr log -r-1 ../old-branch" ? | 18:14 |
| jam | abentley: though if you already have "bzr+" ... | 18:14 |
| jam | certainly we don't do a different access | 18:14 |
| jam | for bzr+ssh or bzr:// | 18:14 |
| Okkin | jam: the merge came from a merge directive file | 18:14 |
| Okkin | jam : I fdon't have acces to the branch it came from | 18:15 |
| jam | Okkin: ATM, we don't have a good way to grab it, you could "bzr branch . ../other; cd ../other; bzr pull --overwrite ../merge_directive; bzr log -r -1" | 18:15 |
| jam | It isn't great by any means | 18:15 |
| jam | but it would get you there | 18:15 |
| jam | Okkin: there is an alternative | 18:15 |
| jam | just a sec | 18:15 |
| jam | grab the revision_id from the merge directive (it is in the top) | 18:15 |
| jam | and do | 18:15 |
| jam | bzr log -r revid:XXXXX | 18:15 |
| Okkin | jam : ok I'm trying | 18:16 |
| abentley | jam: if you have a CGI script "http://example/foo.cgi", POSTING to "http://example/foo.cgi/.bzr/branch-format" will usually invoke it. | 18:17 |
| jam | abentley: well we GET that URL, not POST | 18:17 |
| jam | but I would imagine it is still invoked | 18:17 |
| rockstar | abentley, did you ever finish your work with PreviewTrees? | 18:17 |
| abentley | jam: awilkins is proposing that we post to it. | 18:18 |
| abentley | rockstar: No. | 18:18 |
| jam | rockstar: it was pending a review from Ian, who is only just now out of hospital, and he didn't seem to think my :approve was enough :) | 18:18 |
| abentley | jam: actually, I've just been slack. | 18:18 |
| jam | abentley: I'm pretty sure he is proposing that we post to .bzr/smart | 18:18 |
| jam | and use smart requests | 18:18 |
| jam | to do the probing | 18:18 |
| abentley | jam: Before looking at .bzr/branch-format? | 18:18 |
| rockstar | jam, abentley, doh! I can see the functionality being helpful. | 18:19 |
| jam | abentley: Again, we don't look at files before bzr+ssh:// or bzr:// | 18:19 |
| jam | we probe using the smart server | 18:19 |
| jam | So for "bzr+http://" we could do the same | 18:19 |
| jam | I agree that doing so for "http://" isn't as reasonable | 18:19 |
| abentley | jam: The possibility of accidental damage seems much lower over bzr: or bzr+ssh. | 18:19 |
| Okkin | jam: Too bad, it's not working | 18:20 |
| jam | The possibility for accidental damage over "bzr+http://" isn't very high | 18:20 |
| jam | Okkin: what is happening? | 18:20 |
| Okkin | jam: bzr: ERROR: exceptions.ValueError: list.index(x): x not in list | 18:21 |
| jam | Okkin: sounds like an old bug which has been fixed | 18:21 |
| jam | are you using "--short" or "--long" for log | 18:21 |
| jam | And what version of bzr? | 18:21 |
| abentley | jam: We can POST to a random CGI script. That seems troubling to me. | 18:22 |
| Okkin | jam: bzr 1.6 | 18:22 |
| Okkin | jam: I follow exactly your command | 18:23 |
| Okkin | jam: no --short or --long | 18:23 |
| jam | Okkin: that is *after* doing the merge? | 18:26 |
| jam | weird, because it would have needed to pull the revision in | 18:26 |
| Okkin | jam:yes | 18:26 |
| jam | let me check | 18:26 |
| Okkin | jam: I can see the begining of the message in the pending merges section of "bzr status" | 18:26 |
| jam | crummy, I forgot about the -rrevid: bug when revision_id isn't in your ancestry... | 18:27 |
| jam | Okkin: ok, here's a nasty workaround | 18:27 |
| jam | bzr commit -m "bogus" | 18:27 |
| jam | bzr log -r revid:XXX | 18:27 |
| jam | bzr uncommit | 18:27 |
| jam | It will work fine | 18:28 |
| jam | just is unfortunate | 18:28 |
| Okkin | jam: lol good idea | 18:28 |
| Okkin | jam: It worked, thanks a lot | 18:32 |
| gour|away | jelmer: hello. just saw your email that you cannot reproduce #261878...any hint what to do? | 18:39 |
| === gour|away is now known as gour | ||
| awilkins | HPSS on IIS 6 : I think that protocol behaviour may have changed by the time 1.6 was out | 18:44 |
| awilkins | I just ran a bzr ls bzr+http:// and it was all /smart requests | 18:45 |
| jam | awilkins: I would guess "bzr ls http://" would have an initial GET and then the rest would be smart requests | 18:46 |
| awilkins | jam: Nope, it does the smarts first | 18:47 |
| jam | that certainly could be something new | 18:47 |
| jam | in 1.6 or so | 18:47 |
| awilkins | jam: Then it hits branch-format, pack-names, indices | 18:47 |
| awilkins | THe "meat" of the request is non-smart | 18:48 |
| jam | awilkins: so even if the smart request *succeeds* it still does non-smart requests? | 18:48 |
| awilkins | jam: Looks that way | 18:48 |
| jam | that is a bit surprising | 18:48 |
| awilkins | jam: I'm not sure it's succeeding, theres a lot more hits | 18:49 |
| awilkins | jam: Tell you what, I'll trace both and upload the sessions to a file bin | 18:49 |
| jam | awilkins: I have a strong suspicion it failed | 18:49 |
| * awilkins cannot understand why it works fine for explicit bzr+ but not for plain | 18:49 | |
| Peng_ | Is there a 1.6-subtree format? If so, due to bug 262333, is it identical to 1.6-rich-root? | 18:50 |
| ubottu | Launchpad bug 262333 in bzr "--1.6-rich-root uses wrong serializer" [Critical,Confirmed] https://launchpad.net/bugs/262333 | 18:50 |
| awilkins | http://filebin.ca/uahmt/bzr_smart_ls.saz | 18:51 |
| awilkins | http://filebin.ca/uahmt/bzr_smart_ls.saz | 18:52 |
| awilkins | Bum | 18:52 |
| awilkins | http://filebin.ca/eywnh/bzr_dumb_ls_smart_server.saz | 18:52 |
| jam | awilkins: and .saz is? | 18:52 |
| awilkins | These are zip archives with a little website in each | 18:52 |
| awilkins | .saz "session archive zip" the output of Fiddler2 which is an MS proxy debugger | 18:53 |
| awilkins | The sessions are straight from a branch of lp:bzr/1.6 on windows doing an ls on IIS 7.0 on Vista, running a BZR HPSS via PyISAPIe in tandem with a dumb service via traditional "serve them files" | 18:56 |
| awilkins | The branch is the current tip of lp:bzr-java-lib | 18:57 |
| jam | awilkins: well, it gets to the point where it finds the Branch.last_revsion via smart requests | 18:57 |
| jam | and the containing repository | 18:57 |
| jam | but then it seems to connect a second time | 18:57 |
| jam | when opening the repo | 18:57 |
| awilkins | Hmm. | 18:57 |
| jam | so it finds a RemoteBranch and a RemoteRepository | 18:58 |
| jam | grabs RemoteBranch.last_revision_info() | 18:58 |
| jam | and then re-opens a Repository | 18:58 |
| jam | directly | 18:58 |
| jam | and grabs the last-revision content | 18:58 |
| awilkins | Why does it step up the tree to the repo? The first session doesn't | 19:00 |
| jam | awilkins: care to put some debug statements in bzrlib, or are you using the standalone? | 19:00 |
| awilkins | jam: I don't use the standalone, can't hack it | 19:00 |
| awilkins | That was from a branch ; my installed version is getting the "pycurl read bytes notimplementederror" problem | 19:00 |
| awilkins | Suggestions where to shove debug? | 19:01 |
| jam | awilkins: the interesting command here is going to be BzrDir.open_containing_tree_or_branch | 19:02 |
| jam | awilkins: and the actual probing is in bzrdir.py around line 779 for "open_from_transport" | 19:03 |
| awilkins | find_format ? | 19:04 |
| jam | and at line 1604 is where it is supposed to be probing for the smart format | 19:04 |
| jam | RemoteBzrDir should be the first object it probes for | 19:05 |
| jam | line 2591 is where it is actually POSTing to the remote host | 19:08 |
| jam | in the medium.protocol_version() is the first POST | 19:08 |
| jam | which I see happening | 19:08 |
| jam | and getting a valid response | 19:08 |
| jam | hmm... it would seem the auto-probe does something weird | 19:09 |
| jam | in that it probes, finds a RemoteBzrDir | 19:09 |
| jam | but then using a regular Transport object for the final format.open() | 19:09 |
| jam | awilkins: so, the actual Transport object is different between "http://" auto probing | 19:11 |
| jam | and "bzr+http://" | 19:11 |
| awilkins | Ok, that's weird | 19:12 |
| jam | HTTPTransport.get_smart_medium() returns 'self' | 19:12 |
| jam | because technically it can proxy the POST commands | 19:12 |
| jam | but it *doesn't* use the VFS | 19:12 |
| jam | of the smart server | 19:12 |
| jam | awilkins: so one possibility | 19:13 |
| jam | is to edit bzrlib/transport/http/__init__.py | 19:13 |
| jam | @ line 172 in "get_smart_medium()" | 19:13 |
| jam | and change that to | 19:13 |
| jam | from bzrlib.transport import remote | 19:13 |
| jam | return remote.RemoteHTTPTransport(self.base, http_transport=self) | 19:14 |
| jam | awilkins: that should prevent you from getting mixed GET and POST | 19:14 |
| jam | the way it stands if you use plain "http://" | 19:14 |
| jam | it will serve all FS requests via plain http | 19:15 |
| jam | but any smart protocol requests via POST .bzr/smart | 19:15 |
| jam | If you use bzr+http:// then even the FS requests go through POST | 19:15 |
| awilkins | That seems to cause infinite recursion | 19:15 |
| jam | abentley: what do you think, it almost seems valid to do it this way, as you say "cachable things get requested directly". But I can understand why in messes up awilkins | 19:16 |
| jam | awilkins: you might also need to supply "_from_transport" | 19:16 |
| jam | so it would be | 19:16 |
| jam | RemoteHTTPTransport(base, self, self) | 19:16 |
| jam | or put a bit cleaner | 19:17 |
| awilkins | bzr: ERROR: exceptions.AttributeError: 'RemoteHTTPTransport' object has no attribute 'should_probe' | 19:17 |
| jam | RemoteHTTPTransport(base, self, http_transport=self) | 19:17 |
| jam | awilkins: that's just a bug in RemoteHTTPTransport, I'll check in a sec | 19:17 |
| jam | awilkins: change line 46 of bzrlib/transport/remote.py | 19:18 |
| jam | to: class RemoteTransport(transport.ConnectedTransport, medium.SmartClientMedium): | 19:18 |
| jam | so that it looks the same as HTTPTransport | 19:18 |
| jam | (that may break some of the super(self).__init__ calls | 19:18 |
| jam | but we'll try it first | 19:19 |
| abentley | jam: It seems unnecessarily complex to have bzr+http and http behave differently in smart mode. I would prefer using real HTTP, not VFS, but it's not critical. | 19:19 |
| jam | abentley: well, obviously awilkins prefers if we can get all-VFS | 19:19 |
| jam | since IIS6 doesn't like doing both | 19:19 |
| jam | and our WSGI server doesn't implement GET requests | 19:19 |
| awilkins | The alternative is to work out how to "pass" the request to the next handler in the ISAPI extension I'm using | 19:20 |
| awilkins | Which I think means changing the C code for it | 19:20 |
| abentley | jam: If IIS6 is going to be a thorn in our side, I can support using all-VFS. | 19:21 |
| awilkins | Although I've not seem definitive documentation for it my hypothesis is that you need to call ServerSupportFunction with HANDLE_URL (or whatever the magic const is) | 19:21 |
| abentley | jam: But it seems kinda strange to forbid plain http. | 19:22 |
| awilkins | IIS 6 does support multiple "wildcard" handlers in a chain (including itself, one presumes) so it shouldn't be impossible | 19:22 |
| jam | awilkins: of course, you could just say: "use bzr+http://" if you want all smart requests | 19:22 |
| jam | and use "http://" for "mixed" mode | 19:23 |
| jam | awilkins: do you have a bug open for this, it seems worthwhile to add some commentary | 19:23 |
| jam | about what we've found | 19:23 |
| jam | I also think that RemoteHTTPTransport *not* subclassing SmartClientMedium is a plain bug | 19:24 |
| awilkins | jam: Yes, that is a viable workaround for me now I've discovered it forces all-smart | 19:24 |
| jam | that just hasn't bit us yet | 19:24 |
| awilkins | jam: ServerGuide/IIS discusses this now a little | 19:24 |
| awilkins | IMHO it's more a bug in IIS 6 vs 7, or a missing feature opportunity in PyISAPIe | 19:25 |
| jam | awilkins: sure, though I would also like it documented about "mixed mode" since it is unclear whether it is intentional or a bug | 19:25 |
| awilkins | Bug going up now | 19:27 |
| awilkins | The other possible nasty frig would be to allow it to use URLS that ended /smart.bzr | 19:34 |
| awilkins | Because IIS6 can field things with file extensions, just not blunt ended URLs | 19:34 |
| awilkins | Bug #262366 | 19:38 |
| ubottu | Launchpad bug 262366 in bzr "Smart server uses mixed mode for HTTP URIs" [Undecided,New] https://launchpad.net/bugs/262366 | 19:38 |
| fbond | Hi, I don't really get what the record command is for. I've been using looms for a while and I've never touched record. | 19:44 |
| fbond | Anyone care to explain it? | 19:44 |
| mwhudson | fbond: it's like 'commit' for the whole state of the loom | 19:44 |
| fbond | So I can pull an entire loom after I've recorded? | 19:44 |
| mwhudson | fbond: given that the code hasn't been written yet for much of the stuff to do with sharing looms, it's a bit of an oddity right now | 19:45 |
| mwhudson | fbond: that's the idea, at least | 19:45 |
| fbond | mwhudson: Ah. | 19:45 |
| fbond | mwhudson: So it might fit with future commands like "pull-loom"? | 19:45 |
| mwhudson | fbond: and merge-loom! (which would be pretty cool) | 19:46 |
| fbond | mwhudson: merge-loom sounds scary. I, for one, am not that interested in parallelizing conflicts. :)A | 19:59 |
| mwhudson | i'm not entirely sure what it would mean | 19:59 |
| === mw is now known as mw|lunch | ||
| abentley | fbond: pull-loom already exists, as "pull". | 20:03 |
| abentley | This is why you have to record your loom before pull works. | 20:04 |
| kiorky | jelmer: ping | 20:06 |
| Leonidas | is there a way to specify a date for a commit? | 20:07 |
| kiorky | jelmer: i may have a bug for you with the bzr svn plugin | 20:07 |
| kiorky | jelmer: when pulling from svn i got : http://www.friendpaste.com/quxKN9rQ | 20:07 |
| kiorky | jelmer: look for the 'tgz' file | 20:08 |
| kiorky | jelmer: i think this is this one causing the trouble | 20:08 |
| kiorky | jelmer: someone of my team commits a 'tgz' in the tags directory ... | 20:08 |
| fbond | abentley: Does pull bring in every thread from the loom? | 20:08 |
| kiorky | jelmer: *s/commits/commited/ | 20:08 |
| abentley | fbond: I believe so. | 20:08 |
| fbond | abentley: So what does record actually --well-- record? Does it mean "the current state of the loom is the state that I would like pullers to receive." ? | 20:09 |
| kiorky | jelmer: so the repo is something like trunk/ branches/ tags/a tags/File.tgz , moreover i tried to move the tgz elsewhere, but the problem persists | 20:09 |
| kiorky | jelmer: (problem is that i cant pull from svn anymore :p) | 20:09 |
| abentley | fbond: Yes. At least, when people ask when they should record, lifeless says "right before you push". | 20:10 |
| kiorky | jelmer: i removed .bzr/branch/tags, then re pull, it seems to be working, can you confirm it is safe ? | 20:12 |
| fbond | abentley: Hmm. I probably don't use looms that way. I'm wondering what the overall workflow that ends with "record" followed by "push" looks like. | 20:12 |
| kiorky | jelmer: if you want a full bug report for that problem, just tell me. | 20:12 |
| kiorky | jelmer: but i m a bit in a hurry for now. | 20:12 |
| abentley | fbond: I have no idea. This is an aspect of looms that I find frustrating. | 20:13 |
| Leonidas | or is there a way to specify a commit timestamp via bzrlib. I cannot find the implementation of workingtree.commit | 20:30 |
| Leonidas | (neither does IPython) | 20:30 |
| james_w | mutabletree.commit | 20:31 |
| james_w | I think | 20:31 |
| james_w | but yes, you can | 20:31 |
| jam | Leonidas: "commit(timestamp=seconds, timezone=seconds_offset)" | 20:32 |
| jam | It forwards the **kwargs on to bzrlib.commit.Commit.commit | 20:32 |
| jam | where you can see the actual argument | 20:33 |
| jam | and later on the | 20:33 |
| jam | if timestamp is None: timestamp = time.time() | 20:33 |
| Leonidas | james_w: yeah, I just found it after digging deeper, thanks. | 20:33 |
| Leonidas | jam: thanks, that was what I was looking for. | 20:33 |
| === mw|lunch is now known as mw | ||
| hsn_ | can i push entire shared repo by single command? | 22:20 |
| hsn_ | i would like it for backups | 22:20 |
| jam | hsn_: there is a multi-push command provided by bzrtools, IIRC | 22:21 |
| lifeless | abentley: do you have bzr-search installed? | 22:26 |
| abentley | lifeless: I don't think so. | 22:26 |
| lifeless | ok, cool | 22:26 |
| jam | /cheer | 22:32 |
| jam | I just made "bzr branch bzr+ssh://" about 3x faster on my local machine | 22:33 |
| jam | turns out we were doing bad things with string reallocations during readv | 22:33 |
| jam | *very* bad things | 22:33 |
| mwhudson | yay, in some sense | 22:33 |
| mwhudson | yay for the improvement, not so much for the fact of the bug | 22:33 |
| jam | Yeah, it might even make a 1.6.1 in my book | 22:34 |
| jam | As it may solve a lot of the regression in fetch | 22:34 |
| lifeless | jam: cool | 22:35 |
| lifeless | jam: we have another regression too, marked critical in malone | 22:35 |
| james_w | yeah, I was going to ask about that. | 22:37 |
| pickscrape | malone? | 22:37 |
| lifeless | launchpad bugs | 22:38 |
| james_w | not sure whether we'll end up with 1.6 or 1.7 in Intrepid, but I'd like to keep track of important bugs in case it's the former | 22:38 |
| pickscrape | As in Bugsy Malone? | 22:39 |
| jam | lifeless: which one, I see a few Critical bugs | 22:39 |
| jam | The "wrong serializer" I'm not sure that we can actually fix | 22:39 |
| jam | since it would break anyone who is *using* 1.6-rich-root repos | 22:39 |
| jam | I think we would actually have to create a new repo format, and recommend people switch to it | 22:40 |
| lifeless | jam: the missing revision knits to packs | 22:40 |
| jam | lifeless: Upgrading encounters revision not present, that one I knew about, and you need to use bzr 1.5 to upgrade | 22:40 |
| jam | because it uses .join() | 22:40 |
| jam | and then you can reconcile | 22:40 |
| jam | and things will be happy | 22:40 |
| lifeless | its still a pretty severe regression | 22:40 |
| lifeless | I mean, same logic, people can use 1.5 to pull | 22:41 |
| lifeless | :) | 22:41 |
| jam | lifeless: what would you suggest, you got rid of VF.join() and VF entirely | 22:41 |
| jam | I don't think we want to always request full texts | 22:41 |
| lifeless | jam: the bug has suggestions at the end of it | 22:41 |
| jam | Or is this the other regression | 22:41 |
| jam | Where Revision objects would have 'delta' entries | 22:41 |
| jam | Because we have the same problem with the old "Knits are referencing an delta entry that isn't in the file revision history" | 22:42 |
| lifeless | well, I'm not entirely sure what do to; I'm thinking perhaps to make checK+reconcile on knit repos fix this | 22:42 |
| lifeless | Revision objects having delta entries | 22:42 |
| jam | we fixed bug 217701, though I suppose it may have regressed again | 22:43 |
| jam | (not that it is creating deltas, but that we are having problems fetching them) | 22:43 |
| jam | Ah, maybe it is because You and I changed the knit => pack fetcher | 22:44 |
| jam | If it is *only* revisions.knit, I would be fine with changing that one to use "include_delta_closure=True" | 22:44 |
| jam | fullermd: any chance you could test the patch I just uploaded? | 22:49 |
| jam | jaypipes: ping | 22:49 |
| jaypipes | jam: pong. still haven't upgrade to 1.6 yet. But I do have the .bzr.log to send you... | 22:50 |
| jam | jaypipes: sure, but I think I just wrote a patch which may help the performance for 1.6 | 22:51 |
| jam | At least over the local network | 22:51 |
| jam | it drops my "bzr branch" time by about 1/3rd | 22:51 |
| jaypipes | wow, that's awesome. Code in 1.6 already? | 22:51 |
| jam | jaypipes: well, it would be 1.7 now :) | 22:52 |
| jam | But no, I just proposed it on the mailing list | 22:52 |
| jam | If it is valid | 22:52 |
| jam | I might do a 1.6.1 for it | 22:52 |
| jam | jaypipes: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48B71D9E.6080104%40arbash-meinel.com%3E | 22:52 |
| jam | is the patch if you care to follow its status | 22:52 |
| jam | I'm trying to get someone who specifically saw the problem | 22:53 |
| jam | to test it | 22:53 |
| jam | lifeless: on the good side, it makes bzr branch locally 2x faster than bzr1.5 as well | 22:53 |
| jam | well, over bzr+ssh | 22:53 |
| jam | branch locally was already faster | 22:53 |
| lifeless | jam: its only that one | 22:59 |
| lifeless | (only that knit) | 22:59 |
| jam | lifeless: care to comment on my possible patch | 23:01 |
| lifeless | for fetch ? | 23:02 |
| jam | lifeless: yes | 23:02 |
| jam | basically, just force revisions and signatures to use fulltexts | 23:02 |
| jam | since they should anyway | 23:02 |
| jam | also, you would probably have more knowledge for the discussion on bug #257637 | 23:02 |
| jam | I'm off for now | 23:02 |
| lifeless | gnight | 23:03 |
| bratsche | Is there an easy way to see what revision is the current ancestor of a particular branch? | 23:33 |
| mwhudson | abentley: yay for the 3661 landing | 23:34 |
| abentley | mwhudson: Yay indeed. | 23:35 |
| mwhudson | only two more horrific bugs i can think of (the stacked branch over hpss and wrong serializer ones) | 23:37 |
| rocky | jelmer: got a new error with bzr 1.6 + bzr-svn 0.4.11 today .... http://cluebin.appspot.com/pasted/1001 ... not sure if it's specific to bzr-svn tho | 23:46 |
| james_w | http://www.ubercart.org/docs/developer/629/bazaar | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!