| kfogel | http://paste.lisp.org/display/72266 | 00:00 |
|---|---|---|
| Peng_ | kfogel: bob2's probably right. It's probably a distro package. | 00:01 |
| kfogel | Peng_: ah | 00:01 |
| Peng_ | Or you could've manually installed it in the past, I guess. | 00:01 |
| kfogel | indeed, it is | 00:01 |
| kfogel | I just tried 'apt-get install bzrtools' and it told me I have the latest version | 00:02 |
| kfogel | So, I want to override that with a dev version, right? | 00:02 |
| spiv | kfogel: perhaps try "bzr co lp:bzrtools ~/.bazaar/plugins/bzrtools" to get the current development version of that plugin (to match the development version bzr). | 00:02 |
| kfogel | spiv: would the more bzr-ish thing to do be to branch that instead of cp? | 00:02 |
| spiv | Or run the tests without plugins. | 00:02 |
| spiv | Well, if you're not planning on editing it, it doesn't really make a difference :) | 00:03 |
| kfogel | spiv: hmmm. Shouldn't the tests run without plugins by default? I mean, if bzr's own test suite depends on something in an external package (bzrtools), then... then bzrtools isn't really external, in a sense. | 00:03 |
| spiv | bzr's test suite doesn't depend on plugins. | 00:03 |
| Peng_ | kfogel: It runs the tests suites of plugins. | 00:03 |
| kfogel | oh... | 00:04 |
| spiv | But if plugins are loaded, they can add their own tests to the "bzr selftest" test suite. | 00:04 |
| kfogel | huh | 00:04 |
| spiv | So that the plugins can have tests that can use all the shiny test infrastructure in "bzr selftest" :) | 00:04 |
| kfogel | running LC_CTYPE= LANG=C LC_ALL= ./bzr --no-plugins selftest -1v 2>&1 | sed -e 's/^/[ascii] /' | 00:06 |
| jelmer | poolie, np | 00:07 |
| kfogel | Okay, bigger question this time: I've got a draft fix for bug 306394 (still writing test, so there will be more commits). But I'd like to show my branch to the world. Currently, the branch is on my laptop. I went to launchpad.net and clicked "Register a branch", figuring that I'd be able to publish my branch over in launchpad that way. But the form requires that I supply a "Branch URL", i.e., that my branch already be hosted somewhere | 00:20 |
| kfogel | on the public Net. | 00:20 |
| ubottu | Launchpad bug 306394 in bzr "bzr status should not ignore all other command line arguments if when passing non-existent file" [Undecided,Confirmed] https://launchpad.net/bugs/306394 | 00:20 |
| kfogel | Am I doing something wrong? | 00:20 |
| Peng_ | kfogel: Erm, it's entirely possible to push branches to LP, but I'm not sure how you do it. It might just be "bzr pusl lp:~kfogel/bzr/bug-whatever" or something, without registering it first. | 00:21 |
| Peng_ | push* | 00:21 |
| kfogel | hmmm, that would be nice | 00:21 |
| Peng_ | Sorry, but I've never done it. :P (I host all my branches on my server and let LP mirror them.) | 00:21 |
| spiv | kfogel: what Peng_ said. | 00:22 |
| garyvdm | kfogel: you need to set up a ssh key on launchpad | 00:22 |
| poolie | thumper: ^^ | 00:23 |
| spiv | kfogel: you don't need to register the branch on launchpad's web ui first (but it doesn't hurt if you do) | 00:23 |
| garyvdm | and then bzr push lp:... | 00:23 |
| kfogel | garyvdm: bzr launchpad-login kfogel | 00:23 |
| kfogel | bzr: ERROR: The user kfogel has not registered any SSH keys with Launchpad. | 00:23 |
| kfogel | See <https://launchpad.net/people/+me> | 00:23 |
| kfogel | heh | 00:23 |
| kfogel | garyvdm: seems so | 00:23 |
| garyvdm | https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair | 00:24 |
| poolie | kfogel: if it's just a fix for this, it's more straightforward atm to just send the bundle to the mailing list, with [merge] in the subject | 00:24 |
| poolie | soon i believe there'll be a process in lp to say 'here's the bundle for this bug' | 00:24 |
| kfogel | poolie: that would be straightforward, but part of my goal here is to learn what bzr/lp is like for larger development too | 00:24 |
| spiv | kfogel: "bzr send --mail-to bazaar@lists.canonical.com", assuming you've committed the change. | 00:24 |
| kfogel | poolie: also... Well, for example: I've committed one fix, and have some questions about writing the test, and so I wanted to be able to point people to the branch as it stands so far, so they'd have context for my question. | 00:25 |
| kfogel | I *could* do it all with patches on the mailing list. But I'd much rather do it The Right Way. | 00:25 |
| Peng_ | Bundles *are* the right way of proposing a change to bzr, though having a public branch isn't a bad thing, especially if you want to collaborate with other people on it. | 00:27 |
| Peng_ | (Well, sending a merge request. It doesn't technically have to be a bundle.) | 00:27 |
| poolie | ok, so then pushing to lp is a good idea | 00:28 |
| poolie | btw, thanks for actually looking at that bug! | 00:28 |
| kfogel | Peng_: ok. What would I do with the bundle -- post it as an attachment to my mail, or upload it somewhere? (I noticed that bundles don't have a cleartext log msg, although the diff is cleartext.) | 00:28 |
| kfogel | poolie: np :-) (though I misunderstood it the first time, oops) | 00:28 |
| Peng_ | kfogel: Yeah, attach it to a mail with a subject starting with "[MERGE", so it'll be tracked by BundleBuggy. (Though if it's just a rough draft, use "[RFC]" or something instead if it's not worth tracking.) | 00:29 |
| kfogel | Peng_: is BundleBuggy active for all projects, or just bzr? | 00:31 |
| Peng_ | kfogel: Bundle Buggy is FOSS (right?), and a few other projects are hosted at http://bundlebuggy.aaronbentley.com/ | 00:33 |
| Peng_ | (Mostly bzr-related.) | 00:33 |
| kfogel | Peng_: So BundleBuggy is set up outside Launchpad (right now), okay. | 00:34 |
| Peng_ | Launchpad has merge proposal stuff too now, but Bundle Buggy hasn't gone away. | 00:35 |
| mwhudson | Odd_Bloke: dude, you need to spend less time on identica | 00:37 |
| Odd_Bloke | mwhudson: Or maybe you need to spend more. | 00:38 |
| Odd_Bloke | No, you're probably right. | 00:38 |
| mwhudson | i went for lunch, hit refresh and had a page of you :) | 00:38 |
| Odd_Bloke | mwhudson: You're welcome. :p | 00:39 |
| === BasicPRO is now known as BasicOSX | ||
| === Hydrogen_ is now known as Hydrogen | ||
| kfogel | huh. bzr Makefile doesn't have an "install" rule. ? | 01:15 |
| kfogel | oh, there's an INSTALL file | 01:16 |
| garyvdm | Would there be a performance difference between calling repo.get_revisions 1 revision at a time, and calling repo.get_revisions for a number of revisions. | 01:16 |
| garyvdm | I've got some code in qlog that calls repo.get_revisions 1 revision at a time, but it's not a trivial change to batch the calls. | 01:17 |
| spiv | kfogel: I generally just run bzr from my checkout of bzr.dev. | 01:18 |
| spiv | kfogel: and when I'm not trying to use the bleeding edge, I just rely on the ubuntu packages in the PPA. | 01:18 |
| spiv | garyvdm: yes, there would be. | 01:19 |
| jml | poolie: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/280595 <-- know anything about that one? | 01:19 |
| ubottu | Launchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [High,Triaged] | 01:19 |
| spiv | garyvdm: imagine for example that the branch you're doing qlog is on a high-latency network link. | 01:20 |
| spiv | garyvdm: but even locally I think you'll see some improvement. | 01:20 |
| garyvdm | spiv: that just the case I'm trying to improve. | 01:20 |
| spiv | jml: possibly those branches are victims of #291046 ? | 01:22 |
| jml | bug 291046 | 01:23 |
| ubottu | Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [High,Fix committed] https://launchpad.net/bugs/291046 | 01:23 |
| jml | spiv: I don't know. :) | 01:23 |
| spiv | jml: i.e. they are actually broken branches, and the problem is only noticed at mirroring time because bzr clients wouldn't have necessarily noticed on the first push. | 01:23 |
| spiv | jml: or, in more practical terms, | 01:23 |
| spiv | jml: does "bzr check" on the hosted branches pass? | 01:24 |
| jml | spiv: make things really clear for me. what would a "yes" answer imply, what would a "no" answer imply? | 01:24 |
| spiv | jml: Or more cheaply, maybe check what branch and repo formats are? | 01:24 |
| poolie | jml, all i know is what spiv/abentley said | 01:25 |
| jml | poolie: thanks. | 01:25 |
| spiv | If the branch format is not stackable and the repo format is, then it is probably a victim of 291046. | 01:25 |
| spiv | If so, then as people start using 1.11 these issues should start going away (because clients won't be making broken half-stacked branches anymore). | 01:26 |
| jml | branch: Branch format 7 | 01:28 |
| jml | repository: Packs 5 (adds stacking support, requires bzr 1.6) | 01:28 |
| jml | spiv: no such luck. | 01:29 |
| spiv | jml: drat | 01:29 |
| spiv | jml: no idea, then. | 01:29 |
| jml | (although, of course, there's no guarantee that the branches with those names are the same branches as those triggering the bug.) | 01:29 |
| jml | spiv: leonard's branch has the symptoms you describe | 01:31 |
| spiv | jml: ok, so it explains some cases. | 01:35 |
| jml | spiv: well, the other branches I sampled are no longer failing with that error message. | 01:35 |
| jml | spiv: I'm marking the bug as Invalid on launchpad's side. | 01:35 |
| spiv | jml: sounds reasonable. | 01:37 |
| garyvdm | spiv: Is it ok if I bug you with some questions about loading revisions? | 01:50 |
| spiv | garyvdm: that's ok. | 01:50 |
| garyvdm | spiv: Changing to "batch loading" is going to be a bit of work because qlog can open branches from different repos at the same time. | 01:52 |
| garyvdm | currently we go through each repo and see if we can load it from that one, else go to the next one. | 01:52 |
| garyvdm | see http://bazaar.launchpad.net/~qbzr-dev/qbzr/threadless-throbber/annotate/564?file_id=liblogmodel.py-20080624153442-csesbwmxg0s8db2x-1 | 01:53 |
| garyvdm | line 880 | 01:53 |
| garyvdm | I think I can write some code using graph functions to work out which repo a revision comes from. | 01:54 |
| spiv | garyvdm: so why not ask the first repo for all revisions, then the next repo for any that are still missing, etc.? | 01:54 |
| garyvdm | Because if there is 1 revision that is not in the first repo, get_revisions raises and exception | 01:55 |
| garyvdm | and you don't get the other revisions | 01:55 |
| spiv | Oh, get_revisions raises. Unfortunate. | 01:55 |
| spiv | So, first, please file a bug about that, because it would be a useful feature to add :) | 01:56 |
| garyvdm | Ok | 01:56 |
| spiv | So yes, you can use get_parent_map first to find out which repos have the revision. | 01:57 |
| garyvdm | Maybe we could implement a stackedRepo class like we have a StackedGraph class | 01:57 |
| spiv | revision*s* | 01:57 |
| spiv | Well, there's already Repository.add_fallback_repository, but that requires that you have a stacking-capable repo to start with. | 01:58 |
| garyvdm | This is my real question: Currently I call QtCore.QCoreApplication.processEvents() which keeps the gui responsive, inbetween each revision that we load | 01:59 |
| garyvdm | So if we are loading revisions over a slow network, the gui does not lock up. | 02:00 |
| spiv | But a loop like "revs = []; revisions_to_get = set(self.revisions); for repo in self.repos: revs_in_repo = repo.get_parent_map(revisions_to_get).keys(); revs.append(repo.get_revisions(revs_in_repo)); revisions_to_get.difference_update(revs)" wouldn't be too bad, and is fairly easy. | 02:01 |
| spiv | Ah. | 02:01 |
| spiv | bzrlib doesn't really have any facility for co-operating with an event loop. | 02:01 |
| garyvdm | If I changed get_revision to be a generator, rather than return a list at the end, would I get what I am looking for? | 02:02 |
| spiv | A bit. | 02:02 |
| spiv | It'd certainly be better than not doing that, but you'd still have lengthy stalls in the GUI depending on how long it takes for network requests to be answered. | 02:03 |
| spiv | I'd recommend keeping the GUI event loop in a separate thread, I think. | 02:03 |
| garyvdm | Which we have to some degree. | 02:03 |
| spiv | (Using a generator is a good idea regardless) | 02:04 |
| garyvdm | Some devlopers are insistent that we don't use threads. | 02:04 |
| spiv | Yeah, I saw that mentioned the other day. | 02:04 |
| spiv | I don't think there's much choice. Parts of bzrlib are fundamentally blocking. | 02:05 |
| spiv | So if you don't want that blocking to affect your GUI, you need separate threads (or even separate processes, if you like). | 02:05 |
| garyvdm | Can you explain to me: are there a number of revisions stored in one file, or is each revision in its own file on the disk? | 02:06 |
| spiv | bzrlib will try to stream results as quickly as possible, which will tend to keep the periods it blocks low-ish, in common conditions. | 02:06 |
| spiv | In current formats, there are multiple revisions in one file. | 02:06 |
| garyvdm | Is there an api to find out which revisions are in the same file as another revisions? | 02:07 |
| spiv | I sympathise with wanting to avoid threads, I don't like them either. But I do think they're probably your best option here. | 02:07 |
| spiv | There is, but it's format-dependent... why do you want to know? | 02:08 |
| spiv | bzr doesn't fetch the entire pack file in a single operation. | 02:08 |
| spiv | (usually) | 02:08 |
| garyvdm | Oh | 02:08 |
| spiv | We do readv requests etc. | 02:08 |
| spiv | I strongly suggest not trying to second-guess bzrlib's fetch logic :) | 02:09 |
| garyvdm | I was thinking - If we have opened that file, we might as well read the other revisions in there. I'll take your advice though. | 02:09 |
| spiv | Also, over smart-server protocols (like bzr+ssh) the exact file layout is irrelevant. (Well, a bit. But that's increasingly true) | 02:10 |
| spiv | Yes, that's the sort of thing that bzrlib does already :) | 02:10 |
| spiv | And it works much better if you ask for all the revisions you want in a single call! :) | 02:10 |
| garyvdm | Ok - Thanks for the info - I'm going to start with making get_revisions a generator - and see how that works.. | 02:11 |
| spiv | Cool. repo.get_parent_map is a good way to find out what revisions that repo has, in case I didn't already mention that. | 02:12 |
| spiv | But it'd be even better to get us to improve get_revisions -- if you peek at the implementation, you'll see it'd be pretty easy for us to improve it to take a "missing_ok=True" flag. | 02:12 |
| garyvdm | Ok - thats a cool idea. | 02:13 |
| spiv | garyvdm: or, you could even use repo.revisions.get_record_stream directly. | 02:13 |
| garyvdm | Ok | 02:13 |
| spiv | garyvdm: take a look at how bzrlib.repository.Repository._get_revisions calls it. | 02:14 |
| spiv | garyvdm: which would be even more appropriate for you, actually, because that streams the revisions one-at-a-time, rather than batching them up. | 02:14 |
| garyvdm | Yes - and that would be easy to do. | 02:15 |
| garyvdm | spiv: Out of interest: I was looking for where repo.revisions gets set, but I could not find it. do you know where that happens? | 02:16 |
| spiv | garyvdm: depends on the format. | 02:19 |
| garyvdm | Oh - ok | 02:19 |
| spiv | For pack repos, it happens in KnitPackRepository's __init__, for instance. | 02:19 |
| garyvdm | Makes sense now. | 02:20 |
| rocky | jelmer: any luck on the svn issue i reported earlier ? :) | 02:20 |
| garyvdm | spiv: Thank you very much for your time. | 02:20 |
| spiv | garyvdm: not a problem. Glad I could help! | 02:20 |
| jml | spiv: hi | 02:28 |
| jml | spiv: is this the bug that you just fixed: http://paste.ubuntu.com/86710/ | 02:29 |
| spiv | jml: no | 02:38 |
| jml | bugger. | 02:39 |
| mwhudson | looks like a client bug | 02:42 |
| mwhudson | SEP field UP!! | 02:42 |
| jml | mwhudson: yeah. https://bugs.edge.launchpad.net/bzr/+bug/308822 | 02:44 |
| ubottu | Launchpad bug 308822 in bzr "bzr+ssh says "has no revision", sftp doesn't complain" [Undecided,New] | 02:44 |
| === Spaz is now known as AnalougeKiwi | ||
| igc | hi all | 03:55 |
| igc | markh: hi | 03:55 |
| markh | igc: hi ian! I was going to ask you about the ramifications of not having eol config stored per-branch... | 03:56 |
| igc | markh: well, IMO, it's not done-done until per-branch storage/merging/etc. is supported | 03:58 |
| markh | ultimately I guess I want to know what happens to the branches where we don't want this to happen. If I just need it for 1 or 2 projects, will that screw anything else? | 03:58 |
| markh | right :( | 03:58 |
| markh | any eta on that? | 03:59 |
| markh | From the mailing list it seems that Alex sees this as a showstopper - I'm trying to determine how true that is (or if it is true, when I should again get my hopes up :) | 03:59 |
| igc | markh: it depends. It *was* supported by it was backed out by Robert because quite a few people were unhappy with how it was done, i.e. by having a .bzrrules file in the tree | 04:00 |
| igc | s/by/but/ | 04:00 |
| markh | heh - presumably not any windows devs in that bunch :) So is that actively being worked on, or it it in the never-ending-queue? | 04:01 |
| igc | so we need to get agreement on *where* to store the settings, e.g. under .bzr/checkout/rules, say. | 04:01 |
| igc | I can easily support an agreed place. Supporting propagation and merging of settings is more complex though. | 04:01 |
| igc | Well, more complex if it's somewhere special outside the working tree | 04:02 |
| igc | that's the bit Robert agreed to do, but he'll be busy on the CHK stuff first I suspect | 04:02 |
| markh | ok - so we don't really have any idea when I can get my hopes up again? ;) | 04:03 |
| igc | In the short term, if we got a location agreed, then developers could easily add the rules for just the trees they cared about | 04:04 |
| igc | the rules wouldn't propagate BUT that may not be a big deal. | 04:04 |
| markh | is there a practical use case for this EOL work *without* such a place? | 04:05 |
| igc | Adding/editing .bzr/checkout/rues (say) would then be part of the project setup process I guess | 04:05 |
| igc | markh: I think so. Many Windows would want EOL support enabled for all trees wouldn't they? | 04:06 |
| igc | markh: If so, adding settings to BZR_HOME/rules will work | 04:07 |
| igc | and that's supported now | 04:07 |
| markh | umm - ultimately that might be correct - but I'm not sure what the impact on *existing* bzr windows users would be | 04:08 |
| markh | so yeah - I see it useful for people who only ever want windows trees - but I'm being selfish atm and working out if it will be any good for *me* :) | 04:08 |
| markh | it may well be fine - but if, eg, bzr.dev moved to the new format and I locally enabled that rule, I'm not sure what the impact on the existing trees might be | 04:10 |
| markh | if the only impact was suddenly all my .py files in bzr.dev and elsewhere got \r\n, that would probably be ok | 04:11 |
| lamalex | can I undo a bzr revert? | 04:11 |
| markh | lamalex: you should find the revert created '~1~' like files with the original contents | 04:14 |
| lamalex | ok, so is there a bzr way to move them back? | 04:15 |
| markh | lamalex: not within bzr - just use mv/cp/etc | 04:15 |
| igc | markh: well, my plan is to get something basic supported first without ruling out a better solution later. Even that will take some work. | 04:16 |
| markh | (not that I'm aware of anyway) | 04:16 |
| markh | igc: that sounds reasonable - I'm not sure how it would be dogfooded, but there are lots of things I'm not sure about :) | 04:17 |
| markh | (in case you can't tell, I'm quite keen to get this capability to open up a number of possibilities to use bzr where I can't today...) | 04:20 |
| === AnalougeKiwi is now known as Spaz | ||
| mtaylor | has any progress been made on nested branches? | 05:53 |
| vila | hi all | 07:00 |
| poolie | hello vila! | 07:07 |
| poolie | mtaylor: some; there's a patch from larstiq that improves them | 07:07 |
| poolie | there's also a recent plugin from bialix that supports this kind of function in a simpler but less integrated way | 07:07 |
| mtaylor | poolie: when you say improves them... does that mean they exist currently? I must not have been paying attention :) | 07:41 |
| poolie | they do exist but are experimental/buggy | 07:44 |
| LarstiQ | mtaylor: if you ping me later on I can give you a rundown on what the status is | 08:13 |
| LarstiQ | unfortunately, not very active | 08:13 |
| * LarstiQ will get back to that later too, afk for now | 08:13 | |
| === tga_ is now known as tga | ||
| rocky | jelmer: no luck on the bug we discussed yesterday i suppose? | 11:37 |
| rocky | perhaps something i can help with? | 11:37 |
| ronny | hi | 12:49 |
| ronny | bzr kinda put me into a headache situation, its the only vcs that can't point a workdir to something different that tip | 12:50 |
| ronny | also the whole pulling history to a branch enforces a merge stuff | 12:52 |
| ronny | its kidna hard to abstract that into a model that fits git/hg/bzr/darcs as well | 12:52 |
| ronny | hmm | 12:56 |
| ronny | well, just ignoring bzr would kill my issues, but that wont help users of my lib | 12:57 |
| luks | what else could a working tree point to? | 13:01 |
| ronny | other revs | 13:02 |
| luks | other revs of what? | 13:02 |
| ronny | works pretty well in git/hg/monotone | 13:02 |
| ronny | of that branch | 13:02 |
| ronny | well, those also allow more than one head | 13:02 |
| luks | bzr pull -r X . --overwrite | 13:02 |
| fullermd | That's not exactly the same thing :p | 13:02 |
| ronny | luks: doesnt that just kill stuff? | 13:03 |
| luks | of course, because doesn't have multi-head branches | 13:03 |
| fullermd | You don't have to have multi-head branches to support update -r. | 13:03 |
| ronny | then its not helpfull | 13:03 |
| ronny | it helps | 13:03 |
| fullermd | You just need to follow through every 8 months or so when somebody picks up the patch and updates it, posts it to the mailing lists, and listens to the crickets chirping. | 13:03 |
| luks | what would it do if you commit to such a tree? | 13:03 |
| ronny | usually the next thing people want to do it a dagy patch | 13:03 |
| ronny | luks: add a new head | 13:04 |
| fullermd | Fail. So what? | 13:04 |
| luks | I'd imagine it creates working_tree_rev+1 | 13:04 |
| luks | which is exactly the same as creating a new branch | 13:04 |
| luks | which is what the pull -r command does | 13:04 |
| fullermd | git doesn't have multi-head branches either. It's still useful to fling the WT around. | 13:04 |
| luks | but you need to remember the pointer to the original branch | 13:04 |
| fullermd | No. Wrong. pull -r makes it absurdly difficult to get BACK. | 13:04 |
| ronny | fullermd: gits "brances" are just references into the repo | 13:05 |
| luks | ronny: so are bzr branches | 13:05 |
| ronny | its not exactly the same | 13:05 |
| luks | ronny: the only difference is that in git it's a file, in bzr it's a directory with a few files | 13:05 |
| ronny | luks: in git i can easly repoint my workdir, in bzr, well - i have to do studd | 13:06 |
| ronny | *stuff | 13:06 |
| luks | that's something different | 13:06 |
| luks | you can have a lightweight checkout and repoint it | 13:07 |
| fullermd | Not nearly as easily as you can with git. | 13:07 |
| ronny | thats my issue with bzr | 13:07 |
| ronny | tonns of modes that are all less easy than just the other stuff | 13:07 |
| fullermd | Branches as primary entities make some things a lot nicer and some things a lot uglier. | 13:08 |
| ronny | thats why its not easy to abstract it away | 13:08 |
| fullermd | But neither decision really has anything to do with update -r. | 13:08 |
| luks | if they would be the same, why would we need to many VCSes? | 13:08 |
| luks | *so | 13:08 |
| pygi | we don't need them ... | 13:08 |
| pygi | its about humans ;) | 13:08 |
| fullermd | Because every VCS except $MY_CHOICE sucks, of course :p | 13:08 |
| pygi | fullermd, I disaagree | 13:09 |
| fullermd | See? That's why you're wrong! | 13:09 |
| luks | I could personally see bzr update -r to make the working tree "read only" | 13:09 |
| luks | but I can't imagine how to handle commit to such a tree | 13:09 |
| ronny | fullermd: you see my hell ? | 13:09 |
| pygi | fullermd, I am not wrong | 13:09 |
| ronny | luks: multiple heads | 13:10 |
| LarstiQ | pygi: dude, sarcasm | 13:10 |
| fullermd | There are various possibilities that could be pursued. But they're not necessary to the core feature; they can be additions. | 13:10 |
| pygi | LarstiQ, :P | 13:10 |
| * pygi hides | 13:10 | |
| pygi | LarstiQ, dude, lack of sleep xD | 13:10 |
| luks | ronny: doesn't help if there is no branch pointing to them | 13:10 |
| LarstiQ | pygi: np :) | 13:10 |
| pygi | LarstiQ, how ar eyou doing? :) | 13:10 |
| fullermd | update -r is useful even if you can't commit based on it. Not AS useful, certainly, but it still has useful properties. | 13:11 |
| ronny | luks: well, they are just heads in a branch | 13:11 |
| ronny | or at least heads in a repo | 13:11 |
| LarstiQ | pygi: good, good, back in the Netherlands after losing my passport in Finland, I'm good :) | 13:11 |
| luks | ronny: unreferenced heads are exactly what bzr pull -r X --overwrite . would produce | 13:11 |
| fullermd | And making update -r work is "easy"; making commits work on it is hard, and doubly hard since there isn't an agreement on how it SHOULD work. | 13:11 |
| ronny | hg/git/monotone manage that kind of stuff pretty well | 13:11 |
| pygi | LarstiQ, ah, sorry to hear about losing that stuff | 13:11 |
| LarstiQ | pygi: apparently it's possible to fly with just a police statement | 13:12 |
| fullermd | Well, mtn is a special case. | 13:12 |
| fullermd | LarstiQ: Sure, you demolish a few buildings, and they'll fly you around with no papers at all. | 13:12 |
| pygi | LarstiQ, heh, well, they can't keep you in Finland forever :P | 13:12 |
| LarstiQ | pygi: no, but yesterday they let me know the passport has been found and reside at the Immigration Unit of the police in Espoo, so they're luring me back to pick it up ;) | 13:13 |
| ronny | fullermd: mtn istn that special, the history structure is pretty semilar, just the metadata is really good | 13:13 |
| pygi | LarstiQ, ... | 13:13 |
| pygi | LarstiQ, cant they just send it? | 13:13 |
| ronny | well, bzr is the one that creates the most conceptual issues for my abstraction | 13:14 |
| LarstiQ | pygi: I haven't asked, imo sending documents like that around is a bad idea. | 13:14 |
| fullermd | It's not that it's "good", it's that its worldview permits those sort of situations naturally. | 13:14 |
| fullermd | 's not the case elsewhere (except maybe in hg; I can't keep track of the weird things they half-do at any given point in time) | 13:15 |
| ronny | hg and git both permit that kind of thing | 13:16 |
| ronny | well, and darcs/camp are kinda special | 13:16 |
| fullermd | You can't have multi-head branches in git. | 13:16 |
| fullermd | You can just make new branches easier. | 13:16 |
| fullermd | That's not a difference in kind. | 13:17 |
| ronny | fullermd: but the repo thats on your workdir can have multiple heads more easy, and you can just update to an old rev and commit | 13:17 |
| luks | that's the "making new branches easier" point | 13:17 |
| fullermd | Right, but that's no different conceptually than the way you'd do the same thing in bzr. It's just a much smoother process in git. | 13:18 |
| fullermd | In mtn, it's a different conceptual process. | 13:18 |
| ronny | it needs a new dir in bzr | 13:18 |
| luks | it needs a new file in git | 13:18 |
| ronny | thats something thats entirely impractical to me | 13:18 |
| luks | really, the only difference is that bzr is beeing explicit about creating new branches | 13:18 |
| * fullermd points at the difference between "concept" and "implementation". | 13:18 | |
| ronny | luks: all of my workdir stays in the same stuff | 13:19 |
| LarstiQ | ronny: same with bazaar | 13:19 |
| fullermd | It may LOOK almost identical between git and mtn, but conceptually it's very different. It may look very different between git and bzr, but conceptually it's almost identical. | 13:19 |
| LarstiQ | unless you meant something different with workdir | 13:19 |
| ronny | LarstiQ: uh how ? they cant have more than one head | 13:19 |
| ronny | so its rather tricky, needs a repo around, and tracking of stuff in the repo to make that branch tick like i want | 13:20 |
| ronny | that makes the whole workflow more complicated | 13:20 |
| fullermd | I don't certainly wouldn't argue against the proposition that the inability to have multi-branch bzrdirs is a big failing in bzr. It is. | 13:20 |
| fullermd | I'm not even sure what we're arguing about. | 13:21 |
| * fullermd obviously needs coffee. | 13:21 | |
| === abentley1 is now known as abentley | ||
| === bac_afk is now known as bac | ||
| === vednis is now known as mars | ||
| Lo-lan-do | Hi all | 15:16 |
| Lo-lan-do | Am I mistaken, or is the parent_location defined in locations.conf not overridden by the one in branch.conf? | 15:16 |
| abentley | Lo-lan-do: That is correct. locations.conf always overrides branch.conf, because you control locations.conf, but may not control branch.conf. | 15:42 |
| alsuren | is there an interactive version of the add command? | 15:44 |
| Lo-lan-do | I see. The problem is that branch.conf moves automatically when the repository or its layout changes, but I have to update locations.conf by hand. | 15:45 |
| abentley | Lo-lan-do: There are certainly some problems with this approach, but the alternatives generally involve making the configuration mechanism more complicated. So we've shied away from them so far. | 15:47 |
| Lo-lan-do | Other problem is that it makes "bzr push --remember $url" fail to work as advertised. | 15:48 |
| Lo-lan-do | (Which is my main gripe, really, I can live with updating my configuration when revamping my repository) | 15:49 |
| abentley | Lo-lan-do: It should *warn* you that it's failing to work as advertised, though. | 15:50 |
| komputes | Any idea when bzr 1.10 will be posted as a windoze executable? No worries, it's not for me, I would never join the dark side ;) | 16:22 |
| \sh | jelmer: hi again...ok, now I got a traceback regarding my problem from yesterday :) http://paste.ubuntu.com/87158/ | 16:24 |
| marcoil | Is there some place I can get info on ghost revisions? | 16:25 |
| Peng_ | komputes: The build machine is having problems, so..."eventually, probably". | 16:35 |
| === Mario__ is now known as pygi | ||
| * \sh needs to rush home... | 16:39 | |
| davidstrauss | Is there a guide to making unit tests for Bazaar? | 16:39 |
| komputes | Peng_: hmmm, can we upgrade that to "eventually, definitely" or "oh look it's built, look on LP" ;) | 16:42 |
| * komputes can dream... | 16:42 | |
| === sdboyer-laptop_ is now known as sdboyer|sprint | ||
| kfogel | I'm about to mail bazaar@l.c.c with a question about my fix-in-progress for bug #306394. Is there something special I should put in the subject line so that the bug tracker notices the mail? | 17:24 |
| ubottu | Launchpad bug 306394 in bzr "bzr status should not ignore all other command line arguments when passed a non-existent file" [Undecided,Confirmed] https://launchpad.net/bugs/306394 | 17:24 |
| kfogel | sort of like that? :-) | 17:25 |
| fullermd | The bug tracker doesn't watch the list. | 17:27 |
| Odd_Bloke | kfogel: If you're attaching a patch/merge directive and want it to be voted on, the subject should start with "[MERGE". | 17:28 |
| === enigma1 is now known as enigma42 | ||
| kfogel | Odd_Bloke: I'm not proposing it for merge yet. I'm just asking a question, but it would be good to have the thread tracked by the bug tracker. That's what I'm not sure how to do (or even if it is automated). | 17:29 |
| Odd_Bloke | kfogel: You could CC it to the bug. | 17:29 |
| kfogel | Odd_Bloke: aaaaaaaah (enlightenment). Thanks, I'll look for how to do that. | 17:30 |
| kfogel | Odd_Bloke: just wrote this in #launchpad: | 17:42 |
| kfogel | How do you CC a bug in Launchpad? Neither the generic bug tracker landing page nor the specific bug page (in this case, https://bugs.edge.launchpad.net/bzr/+bug/306394) documents what address one would mail in order to have the email become a comment in the ticket. (Over in #bzr, Odd_Bloke just told me to CC a bug, and I'm trying to figure out how.) | 17:42 |
| ubottu | Launchpad bug 306394 in bzr "bzr status should not ignore all other command line arguments when passed a non-existent file" [Undecided,Confirmed] | 17:42 |
| === ameoba_ is now known as ameoba | ||
| LarstiQ | kfogel: also, if you do send a bundle that bundlebuggy will track (and provided you mention the bug), the bug and thread will be tracked from http://bundlebuggy.aaronbentley.com/ | 17:45 |
| LarstiQ | kfogel: so consider sending it as [RFC] instead of [MERGE] | 17:46 |
| kfogel | LarstiQ: so let me make sure I understand: I'm going to put "[RFC]" on the subject, and CC the bug number. Other than that, I just write the mail as usual. | 17:48 |
| fullermd | kfogel: It's like <number>@bugs.launchpad.net | 17:48 |
| kfogel | fullermd: thank you (yes, over in #launchpad someone said same) | 17:49 |
| LarstiQ | kfogel: yup, that will make it show up in bundlebuggy and on the launchpad bug | 17:50 |
| LarstiQ | kfogel: (bundlebuggy tracks if patches are merged, and provides a review queue) | 17:50 |
| kfogel | LarstiQ: there's no bundle in my mail; instead, it points to a change pushed up to a personal branch. | 17:52 |
| LarstiQ | kfogel: that should result in manual tracking, which is a bit more work but fine | 17:53 |
| LarstiQ | kfogel: of course, if you feel it is premature to go this far, no need to | 17:53 |
| LarstiQ | just expanding on what infrastructure is in place | 17:53 |
| kfogel | thanks | 17:55 |
| === sdboyer-laptop_ is now known as sdboyer|sprint | ||
| === ja1 is now known as jam | ||
| nDuff | Does bzrlib need the ids passed into WorkingTree.add to be a real dict (able to, for instance, enumerate its keys), or can it be any object with its __getitem__ overridden to determine an ID based on the name? | 19:17 |
| abentley | nDuff: WorkingTree.add does not use dictionaries of any kind. | 19:29 |
| abentley | nDuff: WT.add takes a list of files and an optional list of file_ids (and an optional list of file kinds). | 19:31 |
| abentley | nDuff: Supplying a real list, rather than a generator or some sort of fake container is definitely recommended. I suppose it's possible that other containers might work. | 19:33 |
| nDuff | abeaumont, it's the dict of file_ids that I'm considering faking; I have no reason to provide anything other than a real list wrt. the files. | 19:34 |
| * nDuff backs out that "no reason" bit | 19:34 | |
| nDuff | ...when doing a smart_add, for instance, I'd like to be able to generate IDs for things without having known that the recursive add was going to include them. | 19:34 |
| abentley | nDuff: There is no dict of file_ids for WT.add | 19:37 |
| nDuff | ...hrm, you're right, looking at the API docs. Could have sworn that somewhere else there was documentation to the effect that there was a dict. | 19:38 |
| abentley | nDuff: Howerver, have a look at smart_add's action parameter. | 19:39 |
| === Hydrogen is now known as __hy_dr_og_en__ | ||
| nevans | I'm getting an error with the new bzr unshelve: ERROR: No such file: None | 19:41 |
| rocky | jelmer: hey ... the tag issue with bzr-svn has now shown up on another repo for me ... the issue we discussed yesterday ... is there anyway i can help with it? | 19:43 |
| rocky | at some point i intend on coming intimately familiar with the bzr-svn code... but atm i'm just too busy | 19:43 |
| Jc2k | jelmer: ping | 19:52 |
| === __hy_dr_og_en__ is now known as Wasserstoff | ||
| abentley | nevans: What do you get if you run unshelve -Derror? | 19:56 |
| nevans | abentley: I get the same stacktrace as is here: https://bugs.launchpad.net/bzr/+bug/309097 | 20:02 |
| ubottu | Launchpad bug 309097 in bzr "bzr unshelve fails with "No such file: None"" [Undecided,New] | 20:02 |
| === Wasserstoff is now known as Hydrogen | ||
| jelmer | Jc2k, pong | 20:17 |
| jelmer | rocky, Not aware of what's causing it yet, I probably just need to spend some more time investigating it | 20:20 |
| jelmer | hmm | 20:40 |
| jelmer | bzr: ERROR: Transport error: [Errno 40] Too many levels of symbolic links: u'/home/jelmer/bzr/bzr-git/dulwich/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/ | 20:40 |
| jelmer | git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.bzr/branch-format' [Errno 40] Too many levels of symbolic links: u'/home/jelmer/bzr/bzr-git/dulwich/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/. | 20:40 |
| jelmer | plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.bzr/branch-format' | 20:40 |
| Jc2k | jelmer: lol :) | 20:44 |
| nDuff | Is there a better way than setting os.environ['BZR_EMAIL'] for bzrlib applications to change the active user ID? | 20:45 |
| Torne | is it expected that doing bzr co on a remote svn branch with 19000 revisions will make my bzr eat all my ram and fall over after a couple hours? :) | 20:57 |
| Torne | i've never used bzr-svn before adn this might have been a rather ambitious choice | 20:57 |
| jelmer | Torne, larger repositories have been handled with bzr-svn | 20:59 |
| jelmer | Torne, older versions may use memory a bit more aggressively though | 21:00 |
| Torne | hm | 21:00 |
| * nDuff sets the username via the BranchConfig, which seems to be a better fit. | 21:00 | |
| Torne | it's not particularly up to date, now that i check | 21:00 |
| Torne | bzr 1.5 and bzr-svn 0.4.10 | 21:01 |
| jelmer | nDuff, if you do a commit in bzrlib you can specify the committer | 21:03 |
| mwhudson | jelmer: ;) | 21:04 |
| nDuff | jelmer, ahh -- sorry 'bout that. I'll make a note to check the generated API docs (rather than the Integrating with Bazaar page) before asking about things here. | 21:04 |
| nDuff | ...actually, the API docs don't make that very clear either. | 21:05 |
| jelmer | nDuff, no need to be sorry, I don't think it's very easy to find atm | 21:05 |
| nDuff | (at least, not http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.mutabletree.MutableTree.html#commit) | 21:05 |
| nDuff | is there somewhere else I should be looking? | 21:06 |
| === doko__ is now known as doko | ||
| * nDuff finds bzrlib.commit.Commit, and understands a little more. | 21:12 | |
| nevans | abentley: I was able to (easily) repro the unshelve bug on a new branch (details in LP bug) | 21:16 |
| abentley | nevans: Cool, thanks. | 21:16 |
| nevans | BTW: I wonder, why not store the shelf as just "plain old" revisions on an anonymous branch in the repo? then unshelve could be as simple as merging that revision (and revert --forget-merges, because the shelf "branch" is irrelevant). | 21:21 |
| nevans | not that I really know what I'm talking about. ;) | 21:21 |
| fullermd | I was thinking that way in my mental meanderings back before the new shelf was written. | 21:27 |
| fullermd | It has other neat side-effects too, like that you can conceptually throw the shelved bits around between branches easily, even send merge directives of them. | 21:27 |
| nevans | yep. | 21:28 |
| fullermd | I think it would require doing rather more work than shelve currently does, though. | 21:29 |
| nevans | fullermd: well, that would probably answer my "why not...?", then. :) | 21:29 |
| fullermd | Sorta a long way about; shelve a change, make a snapshot based on that change, then later use that snapshot to re-create the change. | 21:30 |
| dman13 | is there a good way to convert a simple bzr repo to an svn repo? no branches and merges, just a history of changes | 21:32 |
| awilkins | You just have to push it in | 21:32 |
| awilkins | It even works well with barnches a | 21:32 |
| awilkins | branches and tags | 21:32 |
| dman13 | I tried, but it complains that I need to merge first. Then the merge fails due to no common ancestry | 21:33 |
| awilkins | There's a particular syntax, I've got a script doing it (converting a large archive of old crap into a neat version history) | 21:34 |
| dman13 | am I doing something wrong, or do I just need a newer version? (bzr 1.3, bzr-svn 0.4.9) | 21:34 |
| awilkins | The boss wants it SVN but bzr is so much quicker I can test and iterate v.fast | 21:34 |
| awilkins | And then push to SVN when done | 21:34 |
| dman13 | :) | 21:34 |
| dman13 | that's basically what I need to do | 21:34 |
| dman13 | I started with bzr, and now have the svn repo on the central server | 21:35 |
| awilkins | I'm using bzr 1.9 and the tip of the 0.4 branch of bzr-svn built against the svn 1.5 libs | 21:35 |
| awilkins | I'm just pushing to a local file:/// repo ; I can copy it to the server later | 21:35 |
| dman13 | I was using a file:// repo to test the results before I do anything to the server | 21:36 |
| dman13 | what are the necessary parameters? | 21:36 |
| awilkins | you want `bzr svn-push -d <source_branch> $baseurl/$projectname/branches/$branchname | 21:38 |
| awilkins | ("branches" has to exist) | 21:38 |
| awilkins | I have an empty folder layout for my initial revision which I import into the repo | 21:40 |
| dman13 | yeah, I still get bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 21:40 |
| dman13 | trying bzr merge results in: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 21:41 |
| kiorky | merge then force commit | 21:41 |
| kiorky | then repull | 21:41 |
| kiorky | it must be ok | 21:41 |
| awilkins | You might need a newer build... | 21:41 |
| awilkins | jelmer ? | 21:41 |
| LarstiQ | ehm, I'd try looking at what the branches involved actually are | 21:41 |
| kiorky | i dont remember the force switch, see with bzr help | 21:41 |
| dman13 | the one branch/repo was created with bzr; it has contents and history | 21:42 |
| dman13 | the other repo is a newly created svn repo | 21:42 |
| dman13 | there is no common ancestor ... but that's okay because the svn repo is empty; I just want to push the history from bzr to svn | 21:43 |
| dman13 | I'll try to get the latest bzr + bzr-svn installed to try it | 21:44 |
| jelmer | dman13, you're trying to push to the repository root? | 21:49 |
| dman13 | jelmer: I created trunk/ branches/ and tags/ in the root of the svn repo | 21:50 |
| dman13 | jelmer: I was trying to push to trunk/ | 21:50 |
| jelmer | dman13, so it's correct it's giving that error | 21:50 |
| jelmer | dman13, since /trunk already has history, and that history diverges from the branch you're trying to push | 21:51 |
| dman13 | okay, now I understand. That's what the manual meant about automatically creating directories. | 21:53 |
| dman13 | now it worked, I just don't have branches/ and tags/ but that isn't so important (they can just be created in a later revision) | 21:54 |
| dman13 | there's no way to not lose the original timestamps, is there? | 21:54 |
| jelmer | dman13, there is, see the bzr-svn FAQ | 21:56 |
| dman13 | that requires server-side access to reconfigure the svn repo, doesn't it? | 21:58 |
| jelmer | yes | 21:59 |
| jelmer | but there's no other way to override the timestamp with svn | 21:59 |
| dman13 | that's what I figured. | 21:59 |
| dman13 | and, IMO, that part of the purpose of the repository: to maintain that information without allowing tampering | 21:59 |
| dman13 | thank you for explaining what I was doing wrong! | 22:00 |
| awilkins | Why did bzr not do what git does and hash the revision as a revid? What's the history of the design there? | 22:17 |
| awilkins | I quite like the property of git that two identical revisions independantly comitted ARE the same revision | 22:17 |
| awilkins | (is that actually true? I'm just rolling dieas around my head?) | 22:18 |
| awilkins | Another thought - would file-id that was an SHA hash of the original file help prevent content conflicts? | 22:18 |
| fullermd | Well, yes, but, independently committing two identical revisions is for all practical purposes impossible :p | 22:19 |
| awilkins | Hmm, I suppose if you hash the timestamp that's true | 22:19 |
| fullermd | AIUI one implementational reason is that we need the revision id before we have all the pieces to calculate a hash. | 22:19 |
| fullermd | It hashes everything. The timestamp, committer, log message, etc. | 22:19 |
| awilkins | And the revid? | 22:19 |
| awilkins | So bazaars revision hashes include the revid? | 22:19 |
| fullermd | I don't know. | 22:20 |
| spiv | Which revision hashes? | 22:20 |
| fullermd | I think I heard that one place the revid id used is in storing the file texts... | 22:20 |
| awilkins | I dunno, I heard it had hashes | 22:20 |
| spiv | Oh, right. Yes, it does, in the revision metadata. | 22:20 |
| * awilkins needs to regrok the internal design a bit more | 22:20 | |
| spiv | As an integrity check, basically. | 22:21 |
| awilkins | Yes, not the primary key like git | 22:21 |
| spiv | See e.g. "bzr testament" | 22:21 |
| awilkins | How about the identical-files-have-identical-fileid thing? | 22:23 |
| awilkins | If you say, added the same file in two branches at the same path, that would be a content conflict | 22:23 |
| awilkins | But if they were identical I'd say that was pretty much a non-conflict | 22:23 |
| spiv | You can do "bzr add --file-ids-from ../other-branch" | 22:23 |
| awilkins | Whee, so you can | 22:24 |
| fullermd | And then there's the occasionally-brought-up path-tokens idea... | 22:24 |
| spiv | There are some plans to allow file-ids to converge (and diverge, for when you split a file in two). | 22:24 |
| awilkins | My idea would Just Work (tm) though, as long as the files where identical on addition | 22:24 |
| spiv | (What fullermd just said) | 22:24 |
| spiv | Which isn | 22:25 |
| spiv | 't always true, and would give false positives. | 22:25 |
| awilkins | Yes, the split-converge idea would bring better feature parity with SVN | 22:25 |
| awilkins | What, if the fileid was a SHA hash of the initial file state, two identical files would always have the same fileid | 22:26 |
| spiv | As a trivial example, Python packages often have __init__.py files that often start their history as empty files. | 22:26 |
| awilkins | Ah | 22:26 |
| awilkins | Emptiness | 22:26 |
| awilkins | Hash of the content plus path? | 22:26 |
| spiv | Just because the content is the same doesn't imply that the files have the same identity to the user across history. | 22:26 |
| awilkins | Also a good point :-) | 22:27 |
| garyvdm | Hi spiv. I got batched loading of revisions in qlog working. On a 1.9 repo - it's about 50% quicker :-). But on a 1.6 repo - it slower :-( | 22:27 |
| spiv | And ditto for having the same initial content and path in two different branches -- branches that you may later join. | 22:27 |
| spiv | garyvdm: huh! | 22:28 |
| spiv | garyvdm: slower total, or just slower to start returning results? | 22:28 |
| garyvdm | spiv: Slower total. | 22:28 |
| spiv | garyvdm: are the repositories you're comparing packed to a similar degrees (i.e. how many files in .bzr/repository/packs)? | 22:28 |
| spiv | 1.9 does have a much better index format. | 22:29 |
| spiv | But I'm surprised that doing things that way would make 1.6 worse. | 22:29 |
| garyvdm | I think so. They were both recently branch bzr.dev's | 22:30 |
| garyvdm | I write a test that just does revision loading to test it more accuratly | 22:30 |
| spiv | awilkins: it would be great if bzr did notice that two files with different IDs were conflicting at the same path, and made it easy for you know that and to resolve that. | 22:31 |
| davidstrauss | Where can I read about adding unit tests to my patch? | 22:33 |
| davidstrauss | I have no idea what system bzr uses. | 22:33 |
| spiv | awilkins: I mean, bzr is recording strictly more information than git, so it could in principle use the same heuristics as git. Or we can try to do better, because we have more data :) | 22:33 |
| spiv | davidstrauss: http://doc.bazaar-vcs.org/latest/en/developer-guide/HACKING.html http://doc.bazaar-vcs.org/latest/developers/testing.html | 22:33 |
| davidstrauss | spiv: thanks | 22:33 |
| fullermd | Of course, the alternate perspective on that is that git relies on the heuristics, so the devs have incentive to make them work well. | 22:34 |
| spiv | davidstrauss: it's basically using the Python standard library's unittest module, but with lots of little extensions (which is after all what xUnit is designed to allow). | 22:34 |
| davidstrauss | spiv: makes sense | 22:35 |
| spiv | fullermd: right. | 22:35 |
| fullermd | This leads into my theory that, in any project, you should carefully decide what the most important part is, and then never write any code to do it. | 22:35 |
| spiv | fullermd: I'm less convinced by that bit :P | 22:35 |
| davidstrauss | Is it possible to change the merge algorithm when updating a checkout? | 22:35 |
| fullermd | Pfft. It's a great labor-saving device. Makes project management a lot less contentious. | 22:36 |
| fullermd | More seriously, though, you can see side effects of its corrolaries in bzr. | 22:36 |
| fullermd | Who else has even a shadow of our capability in supporting dumb servers? arch, maybe? I don't think anybody else. | 22:37 |
| spiv | davidstrauss: "bzr help update" says yes :) | 22:37 |
| davidstrauss | Cobalt-2:~ straussd$ bzr help update | 22:37 |
| davidstrauss | Purpose: Update a tree to have the latest code committed to its branch. | 22:37 |
| davidstrauss | Usage: bzr update [DIR] | 22:37 |
| davidstrauss | Options: | 22:37 |
| davidstrauss | -v, --verbose Display more information. | 22:37 |
| davidstrauss | -q, --quiet Only display errors and warnings. | 22:37 |
| davidstrauss | -h, --help Show help message. | 22:37 |
| davidstrauss | spiv: where? | 22:38 |
| fullermd | bzr blows everybody away in dealing with crappy network models. As a [not technically, but socially] necessary result, our network handling is crappier than everyone else. | 22:38 |
| spiv | davidstrauss: oh, what version of bzr? | 22:38 |
| davidstrauss | spiv: 1.10 | 22:38 |
| * fullermd peers at spiv. | 22:38 | |
| spiv | Oh, look at that, the loom plugin... | 22:38 |
| fullermd | Even bzr.dev doesn't have any --merge-type there. Pls send bundles back from your future-bzr 8-} | 22:38 |
| spiv | It turns out that "bzr up" is a totally different command if you have bzr-loom installed. | 22:39 |
| spiv | Hmm. | 22:39 |
| spiv | davidstrauss: sorry for the confusion! | 22:39 |
| davidstrauss | What does bzr-loom do to bzr update? | 22:39 |
| spiv | Nothing, it adds an "up-thread" command. | 22:39 |
| spiv | And I typed "bzr help up" | 22:39 |
| spiv | And didn't read the result closely enough! | 22:40 |
| spiv | I just saw the "--merge-type=ARG" option and ran off to IRC with false information... | 22:40 |
| fullermd | Oh well. Who believes anything on IRC anyway? | 22:41 |
| fullermd | It's not authoritative until it's on Wikipedia... | 22:41 |
| spiv | davidstrauss: it seems like a reasonable feature to add. You *might* be able to use "bzr remerge" on a conflicted file from and update, though. I'm not sure. | 22:41 |
| spiv | dav | 22:41 |
| davidstrauss | spiv: but you can't safely merge when you have uncommitted changes | 22:42 |
| fullermd | I would be a little surprised, I think... | 22:42 |
| davidstrauss | BTW, bzr is working pretty well for the Drupal code sprint. | 22:42 |
| spiv | davidstrauss: well, "bzr remerge" is designed to let you redo a part of an uncommitted merge with a different merge algorithm. | 22:42 |
| davidstrauss | spiv: does remerge work when you get conflicts from an update? | 22:43 |
| fullermd | Now, if conflicts were coming about because of local commits, you've got a back door. But we already had the --local mock-fest :) | 22:43 |
| davidstrauss | fullermd: by my decree, we're not using local commits. | 22:43 |
| spiv | davidstrauss: But I'm not sure if that works for checkout conflicts too. Try it, it'll either work or just give an error. :) | 22:43 |
| spiv | fullermd: I actually think --local is a nice idea, despite all the bugs :( | 22:44 |
| fullermd | My guy would say that it wouldn't work. | 22:44 |
| spiv | fullermd: yeah, that's my guess too. But it's worth checking. | 22:44 |
| fullermd | Oh, I do too, in a way. I think it's a really handy crowbar to have around. I just don't think it's a suitable day to day tool. | 22:44 |
| spiv | davidstrauss: cool, glad to hear it. | 22:44 |
| fullermd | (even bug-free) | 22:45 |
| fm | could someone look at http://pastebin.ca/1288113 | 22:45 |
| spiv | davidstrauss: does drupal use bzr? | 22:45 |
| spiv | fm: looks like a URL ;) | 22:45 |
| davidstrauss | spiv: not yet | 22:45 |
| fm | which editor is called when doing a bzr ci without -m? | 22:45 |
| davidstrauss | fm: your EDITOR environmental variable | 22:46 |
| spiv | fm: $EDITOR, unless $BZR_EDITOR is set. | 22:46 |
| fullermd | $BZR_EDITOR or the config'd editor or $VISUAL or $EDITOR or random-guesses. | 22:46 |
| davidstrauss | fullermd: random guesses? | 22:46 |
| fullermd | davidstrauss: for editor in ['/usr/bin/editor', 'vi', 'pico', 'nano', 'joe']: | 22:47 |
| fullermd | (or another list on win32) | 22:47 |
| davidstrauss | fullermd: joe? | 22:47 |
| fm | spiv davidstrauss fullermd thanks sadly none of these are there on opensuse 11.1 | 22:47 |
| fullermd | It's sorta a pico-ish emacs, from what I recall. | 22:47 |
| * fullermd peers at fm. | 22:47 | |
| fullermd | *vi* isn't there?? | 22:47 |
| mlh | maybe it's vim | 22:48 |
| mlh | (one to add to the list?) | 22:48 |
| fm | /usr/bin/vi -> /bin/vim | 22:48 |
| mlh | so vi is there | 22:48 |
| fullermd | (mind, I always just Assume(tm) that any *nix user has $EDITOR set. Maybe I'm a little atavistic that way.) | 22:49 |
| fm | ok so vi is there in fact but nevertheles "bzr: ERROR: [Errno 13]" is what i am getting without a -m | 22:49 |
| fm | i am using bzr 1.10 | 22:49 |
| spiv | fm: weird. | 22:49 |
| awilkins | fullermd: I think only CVS and Visual SourceSafe like dumb servers as much as Bazaa | 22:50 |
| spiv | fm: do you have a /usr/bin/editor ? | 22:50 |
| fm | fullermd: which source file are you quoting? | 22:50 |
| spiv | And is it executable? | 22:50 |
| awilkins | Of course, VSS fucks it up. Badly. | 22:50 |
| * fullermd frowns. | 22:50 | |
| fm | spiv: no i do not have that | 22:50 |
| fullermd | Errno 13 is EACCESS | 22:50 |
| spiv | fullermd: yeah, I just figured that out too. (At least on x86 linux...) | 22:51 |
| mlh | ah I thought my German wasn't that bad :-) | 22:51 |
| fullermd | It catches ENOENT, but not EACCES. What could that be failing on? Bad perms on the temp file maybe? Kinda odd. | 22:51 |
| spiv | fullermd: or trying to run a file without the 'x' bit set. | 22:51 |
| mlh | it's not unknown for /tmp to go restricted perms due to some sysadmin error | 22:51 |
| fm | fullermd: spiv the only way i found the error was reading the trace in .bzr.log nobody thinks about missing editor when getting perm denied. I thought my repo had a wrong permission | 22:52 |
| mlh | like untaring in /tmp | 22:52 |
| fullermd | Could be. Sounds like an odd thing to come across. We should catch it along with ENOENT, though. | 22:52 |
| fullermd | fm: See bzrlib/msgeditor.py; _run_editor() | 22:52 |
| spiv | fm: I'm pretty sure that error is due to one of the editors bzr is trying to run not actually being executable. | 22:52 |
| spiv | fm: we should fix bzr to catch this error | 22:52 |
| mlh | It'd be could to actually spit out the args to subprocess in the exception too | 22:53 |
| spiv | mlh: yeah | 22:53 |
| mlh | one of my pet hates with exceptions in python and java | 22:53 |
| fm | i am known at suse for bzr bugreports ;) | 22:53 |
| kfogel | vila: regarding bug #211852: it isn't clear from your comment whether that means you're working on it or not, but... I can hope, right? :-) | 22:53 |
| ubottu | Launchpad bug 211852 in bzr "bzr log should accept multiple files" [Wishlist,Triaged] https://launchpad.net/bugs/211852 | 22:53 |
| spiv | fm: but to solve your immediate issue, let's find which editor executable on your system isn't executable :) | 22:54 |
| fullermd | Easier, to solve the immediate issue, just set $EDITOR | 22:54 |
| spiv | fm: so "echo $BZR_EDITOR $VISUAL $EDITOR" is empty? | 22:54 |
| fm | spiv: yes it is | 22:55 |
| fm | spiv: i have vi and nano installed and both are executable | 22:57 |
| spiv | fm: hmm, and you don't have an "editor = something" line in ~/.bazaar/bazaar.conf ? | 22:57 |
| fullermd | And /usr/bin/editor? | 22:58 |
| fm | editor = "" | 22:58 |
| spiv | Ah :) | 22:58 |
| * fullermd blinks. | 22:58 | |
| fullermd | Wow. | 22:58 |
| fm | is in my ~/.bazaar/bazaar.conf thanks alot | 22:58 |
| spiv | Ok, EACCESS isn't quite what I would expect from that situation. | 22:58 |
| fm | how did it get there? | 22:58 |
| spiv | But that isn't totally surprising either. | 22:58 |
| spiv | I have no idea! | 22:58 |
| dman13 | spiv: sure, if you use os.system() ... the empty "command" means the shell treats the first argument as the executable | 22:59 |
| dman13 | (I don't know which underlying system call bzr is using for that) | 22:59 |
| fullermd | Sounds like another thing we should specifically trap... | 23:00 |
| spiv | dman13: bzr uses subprocess.call to run the editor. But I wouldn't expect the system give EACCESS rather than ENOENT. | 23:01 |
| fullermd | spiv: See, proves my earlier point! Writing log messages is important, and if nobody had written any code to do it, we wouldn't be having this problem ;p | 23:01 |
| fm | just printing a message your editor ("") cannot be run would be good for me | 23:01 |
| spiv | fm: right. | 23:01 |
| dman13 | spiv: some forms of subprocess parse a string to find the executable ... right? | 23:01 |
| spiv | fm: AFAICT, nothing in bzrlib will set the editor option in your config file automatically. | 23:02 |
| spiv | fm: so whatever set it wasn't bzr itself. (Possibly a confused user, possibly an insane plugin? I really have no idea what might do that!) | 23:03 |
| spiv | dman13: right -- hence why I'd expect ENOENT rather than EACCESS. :) | 23:03 |
| spiv | dman13: but what I expect has very little to do with what happens :) | 23:03 |
| fm | i have no idea how it got there i have been playing with bzr for some time 0.6 or something, maybe it did back then. I did not even know this file exists so i am pretty sure i haven't it inserted there myself ... | 23:03 |
| dman13 | spiv: unless you told/let subprocess pass the string to a shell | 23:03 |
| spiv | Yeah, it's possible that older versions of bzr might have done something silly. | 23:04 |
| dman13 | spiv: it doesn't prevent using the risky forms of execution | 23:04 |
| fm | thanks alot | 23:04 |
| spiv | dman13: no, we pass an argv not a shell command. | 23:05 |
| dman13 | spiv: okay, then I agree with your expectations. | 23:05 |
| spiv | dman13: strace shows the EACCES comes from the execve in the child process | 23:06 |
| dman13 | spiv: interesting. | 23:07 |
| dman13 | spiv: now I wonder if it is possible to create a file with the empty string as its name ... | 23:08 |
| dman13 | no, that yields Errno 2: no such file or directory | 23:09 |
| dman13 | :) | 23:09 |
| spiv | Right, ENOENT, as expected ;) | 23:09 |
| mlh | ~but ... | 23:11 |
| mlh | is "" interpreted sometimes as current dir? | 23:12 |
| mlh | ./. gives EPERM though | 23:12 |
| mlh | oh here we go | 23:14 |
| mlh | strace ./"" ... | 23:14 |
| mlh | execve("./", ["./"], [/* 27 vars */]) = -1 EACCES (Permission denied) | 23:14 |
| fullermd | That's trying to exec a directory. Seems an odd way to react to an empty string thouhg. | 23:14 |
| spiv | Hmm, treating "" as meaning the cwd would explain EACCES. | 23:15 |
| jml | poolie1: hi | 23:51 |
| jml | poolie1: what did you guys end up deciding re upgrading the bzr.dev branch's format? | 23:52 |
| spiv | jml: poolie1 isn't around today/tomorrow | 23:53 |
| spiv | jml: (except for beer) | 23:53 |
| Peng_ | Upgrade it to 1.9-rich-root! :D | 23:54 |
| jml | spiv: ahh thanks. | 23:54 |
| jml | spiv: perhaps you can answer my question? | 23:54 |
| spiv | I don't remember any decision being made. | 23:54 |
| AfC | Peng_: :) | 23:55 |
| spiv | My guess is it's probably fine to upgrade it to 1.6, but if we do we should keep a pack-0.92 mirror for a while for e.g. hardy users. | 23:55 |
| spiv | fm: I submitted a patch to improve the error handling in your situation: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081217235314.GA24352%40steerpike.home.puzzling.org%3E | 23:56 |
| jml | spiv: ok. I'll chase it up with poolie next year then. | 23:56 |
| Peng_ | A 1.9 mirror would be nice too. | 23:56 |
| jml | yeah. | 23:57 |
| spiv | jml: I'd be ok with a checkbox in Launchpad for "please upgrade the format for this mirror" ;) | 23:57 |
| Peng_ | That would be neat. | 23:57 |
| jml | spiv: you mean "mirror this branch, but in 1.9 instead of whatever it is"? | 23:58 |
| spiv | jml: right. | 23:58 |
| jml | spiv: that'd be kind of cool. | 23:58 |
| spiv | jml: (or the appropriate 1.9 variant for rich-root/subtree :/ ) | 23:58 |
| jml | spiv: atm, we have quite hardcore restrictions on mirroring branch's that have the same URL | 23:58 |
| Peng_ | How useful would it be? Why not just upgrade the source branch? | 23:59 |
| jml | and, when you guys start hosting your code on Launchpad, it'll be even trickier since we don't let you mirror branches from Launchpad onto Launchpad. | 23:59 |
| spiv | Right, but why does that matter (I'm not thinking that Launchpad should mirror one URL in both original *and* latest formats!)? | 23:59 |
| jml | spiv: ummm, I thought you were. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!