* poolie looks | 00:01 | |
poolie | ok | 00:13 |
---|---|---|
mwhudson | the bzr-builder "parser" is a little sad making | 00:25 |
james_w | oi! | 00:30 |
mwhudson | james_w: hi :-) | 00:31 |
mwhudson | it' | 00:31 |
james_w | hi mwhudson :-) | 00:31 |
james_w | output from "bzr merge": | 00:32 |
james_w | deleted misc | 00:32 |
james_w | ... | 00:32 |
james_w | Path conflict: misc / misc | 00:32 |
james_w | "bzr st": | 00:32 |
james_w | removed: | 00:32 |
james_w | misc/ | 00:32 |
james_w | ... | 00:32 |
james_w | conflicts: | 00:32 |
james_w | Path conflict: misc / misc | 00:32 |
james_w | ls misc*: | 00:33 |
james_w | No matches: misc* | 00:33 |
james_w | what sort of conflict is that? | 00:33 |
spiv | james_w: exciting? confusing? There are lots of adjectives ;) | 00:35 |
james_w | mwhudson: I don't have anything specifically against using a "proper" parser, I'd just like it to pass the tests, or equivalent ones | 00:35 |
james_w | It's not inexperience that led to that implementation | 00:36 |
james_w | spiv: I'd say both of those apply | 00:36 |
james_w | I've no idea how to resolve it, or even why I thinks I need to | 00:36 |
mwhudson | james_w: it would be nice if there was a grammar for recipes i think | 00:36 |
james_w | yes | 00:37 |
mwhudson | it's not that the current parser is bad, but it's a bit of a blob | 00:37 |
mwhudson | separate lexing and parsing might be nice | 00:37 |
james_w | and then it would be nice if the parser was generated from that, so it was confirmed to be nice | 00:37 |
mwhudson | but maybe that's ott for something simple | 00:37 |
mwhudson | james_w: my use case is wanting to rewrite the branch references in a recipe | 00:38 |
james_w | lexing is hard in this case | 00:38 |
mwhudson | i guess line.split() is a fair approximation of what's possible actually :) | 00:39 |
james_w | yes | 00:40 |
james_w | plus, "bzr tag 'a tag'" would lead to some issues | 00:40 |
james_w | and spaces in URIs may be a bit of a pain with bzrlib | 00:40 |
mwhudson | %20 ftw i guess | 00:41 |
mwhudson | but you can't put a space in the url of a branch on launchpad so... | 00:41 |
james_w | true | 00:42 |
james_w | the issue is that bzr transports take strings, and there's no way to tell if whether it is escaped or not | 00:42 |
james_w | e.g. https://bugs.edge.launchpad.net/bzrtools/+bug/310631 | 00:44 |
ubottu | Ubuntu bug 310631 in bzrtools "bzr patch doesn't understand query strings in URLs" [Undecided,New] | 00:44 |
mwhudson | james_w: i think bzrlib generally assumes that urls are escaped | 00:45 |
mwhudson | so that looks like a straight up bug | 00:46 |
mwhudson | hm, i guess you're right, it's a bit muddled | 00:53 |
james_w | bzrtools is doing urlutils.normalize_url() on the path, which might be wrong | 00:55 |
james_w | not doing it might give other problems though | 00:55 |
mwhudson | no, it's the split path and get that's messing things up | 00:56 |
mwhudson | >>> urlutils.normalize_url('http://python.org/?arg=value') | 00:56 |
mwhudson | 'http://python.org/?arg=value' | 00:56 |
james_w | ah | 00:57 |
james_w | that bug's all over the place in my code then | 00:58 |
mwhudson | well | 00:58 |
mwhudson | i don't know what the right fix is | 00:58 |
mwhudson | i guess httptransport's .get() is broken | 00:59 |
mwhudson | but fixing it might break other stuff | 00:59 |
mwhudson | james_w: bzrlib.transport.Transport._unsplit_url says in the docstring | 01:02 |
mwhudson | Build the full URL for the given already URL encoded path. | 01:03 |
mwhudson | but then escapes the path anyway | 01:03 |
=== r0bby_ is now known as r0bby | ||
lifeless | jam: https://ec2-sshd.dev.java.net/ | 02:26 |
mwhudson | james_w: still here? | 02:46 |
james_w | yep | 02:47 |
mwhudson | james_w: where in the world are you at the moment? ;) | 02:49 |
james_w | home | 02:49 |
james_w | physically, if not temporally. | 02:49 |
mwhudson | yikes | 02:49 |
mwhudson | james_w: we have this need to rewrite the branch urls in a recipe | 02:49 |
james_w | yes | 02:50 |
mwhudson | partly this relates to the way we plan to store the recipe for the moment, but we'll also need it to inject the credentials for building from private branches | 02:50 |
mwhudson | james_w: i think it makes sense for this code to be part of bzr-builder | 02:51 |
james_w | yep, in some form | 02:51 |
mwhudson | james_w: i'm not sure whether the input to this functionality should be the recipe text or the BaseRecipeBranch | 02:52 |
mwhudson | the problem with starting with the latter (and attacking the manifest generating code i guess) is that you'll lose comments and formatting | 02:52 |
james_w | not sure offhand | 02:52 |
james_w | it would be possible to preserve that | 02:53 |
james_w | fugly, but possible | 02:53 |
mwhudson | unless you make the parser smarter | 02:53 |
mwhudson | yeah | 02:53 |
james_w | preserving comments is probably something we should do anyway | 02:53 |
mwhudson | if you take the text as input, you can probably just remember where the branch urls came from and string manipulate them out | 02:54 |
mwhudson | james_w: preserving comments in the manifest, you mean? | 02:54 |
james_w | yeah | 02:54 |
mwhudson | ok | 02:54 |
mwhudson | well that's an argument towards making my changes more "core" and less of a parallel hack i guess | 02:54 |
mwhudson | which is probably a good thing | 02:55 |
james_w | yeah | 02:55 |
james_w | I dread the code to preserve though | 02:56 |
james_w | I think we might need to change the model to make it palatable | 02:56 |
james_w | or maybe not too much | 02:56 |
mwhudson | it's not clear to me where you'd put comments in the model | 02:57 |
james_w | perhaps a new instruction that's a null, but stores the comment? | 02:58 |
mwhudson | james_w: i guess | 03:02 |
mwhudson | james_w: edge cases galore though | 03:03 |
mwhudson | james_w: spot the difference! http://pastebin.ubuntu.com/337738/ | 03:03 |
james_w | them the rules! :-) | 03:04 |
spiv | mwhudson: makes perfect sense ;) | 03:04 |
james_w | we could fix that case if you want to file a bug though | 03:04 |
james_w | try putting 3 spaces in the middle line though :-) | 03:05 |
mwhudson | oh and you can't have comments at the end of significant lines | 03:05 |
mwhudson | james_w: i noticed the mandatory two space indent, at least that gets around some of python's complexity here :) | 03:06 |
james_w | that's one of Mark's :-) | 03:06 |
mwhudson | heh heh | 03:06 |
mwhudson | james_w: is not being able to put comments at the end of a line a feature? | 03:09 |
mwhudson | it leads to some slightly strange error messages | 03:10 |
james_w | I don't think it is | 03:10 |
mwhudson | ok | 03:10 |
* mwhudson gets his bug filing hat on | 03:11 | |
mwhudson | james_w: https://bugs.edge.launchpad.net/bzr-builder/+bug/487174 reminds me to ask you what the branch ids are for | 03:12 |
ubottu | Ubuntu bug 487174 in bzr-builder "Doesn't enforce uniqueness of branch ids" [High,Triaged] | 03:12 |
james_w | revno:<id> | 03:15 |
james_w | and derivation when we implement that | 03:15 |
mwhudson | james_w: oh, in the debversion? | 03:19 |
james_w | yeah | 03:19 |
mwhudson | makes sense | 03:20 |
mwhudson | james_w: i filed three bugs, i guess you got emailed about them | 03:22 |
james_w | I do, thanks | 03:23 |
treeform1r | it keeps asking me for password how can i unbind | 03:24 |
treeform1r | if it says i am unbound? | 03:24 |
treeform1r | i type "bzr unbind" - it asks me for passwrod - why? | 03:26 |
treeform1r | i type it in | 03:26 |
treeform1r | it says i am unbound allready | 03:26 |
treeform1r | how can i just work locally? | 03:26 |
mwhudson | james_w: i worry a bit about the interaction of # and the run command | 03:29 |
mwhudson | treeform1r: what does bzr info say? | 03:29 |
* igc lunch | 03:47 | |
gbbzr | anybody know why bzr is stuck at 1.x in the Fedora repos, even though the package was updated in June of this year? | 05:00 |
poolie | gbbzr: no, but you could ask on the list | 05:27 |
poolie | abadger i think is involved with it but he's not here now | 05:27 |
jml | hello | 05:36 |
jml | does Gordon Tyler hang out on IRC? | 05:37 |
spiv | jml: I think he does, sometimes | 05:39 |
spiv | jml: nick is dOxxx I think, maybe +/- an x | 05:40 |
jml | spiv, thanks. | 05:41 |
bignose | I see references to “No handlers could be found for logger "bzr"” in various search results | 06:30 |
bignose | but no real clue as to why it would suddenly start happening. | 06:30 |
bignose | I gather it's to do with the fact that logging hasn't been properly initialised, but why would that suddenly start happening without a change in Bazaar for several weeks? | 06:31 |
spiv | bignose: perhaps because bzr couldn't open ~/.bzr.log? | 06:37 |
spiv | (or wherever 'bzr --version' says the log file ought to be) | 06:37 |
bignose | argh | 06:38 |
spiv | bignose: IIRC a relatively common cause is 'sudo bzr' | 06:38 |
bignose | why does that file occasionally get owned by root | 06:38 |
bignose | well, grumble mumble bumble. | 06:38 |
spiv | I *think* there's a bug report about that somewhere, although off the top of my head I'm not sure what bzr can do about it. | 06:39 |
bignose | perhaps a FAQ entry would be good on that. | 06:39 |
spiv | Well, I suppose bzr could emit a clearer warning. | 06:39 |
bignose | yes, that too. | 06:39 |
bignose | it would be good to say explicitly that Bazaar doesn't have the permission it needs to its own log file. | 06:40 |
spm | spiv: so THAT's what that means. I've been happily ignoring it till now. face? please meet palm. Gah. I should have just asked... lala me | 06:46 |
spiv | spm: heh | 06:48 |
* spm emails losas with this fine tidbit of info | 06:48 | |
spiv | It's bug 354843 FWIW | 06:50 |
ubottu | Launchpad bug 354843 in bzr "better handle failure to open ~/.bzr.log - Bzr should be smart about who owns ~/.bzr.log" [Medium,Triaged] https://launchpad.net/bugs/354843 | 06:50 |
spiv | (And I just marked two other bugs as dupes of that!) | 06:50 |
spiv | Oh hmm we have two 'Critical' bugs, I hadn't noticed that. | 06:56 |
jml | I really, really want to depend on launchpadlib.uris | 07:28 |
spiv | jml: sounds a bit like an ad campaign for a cleaning product... "launchpadlib... you can depend on it!" | 07:36 |
jml | heh | 07:36 |
vila | hi all | 07:37 |
vila | spiv: I don't think #461992 is critical, a 700MB *VM* that can't co a 1GB file... gee, increase the VM ram... | 07:39 |
vila | jml: ECONTEXT, I'm sure launchpadlib.uris is great why advertising it here ? :D | 07:41 |
vila | s/great why/great BUT why/ | 07:41 |
vila | Here I go, ruining my first joke of the day with stupid typos... not even a good joke... | 07:42 |
jml | vila, because I could delete code from bzrlib.plugins.launchpad | 07:42 |
vila | ha! And you fear the consequences :) | 07:42 |
jml | vila, well, bzr can't have a hard dep on launchpadlib, realistically | 07:42 |
vila | yeah, but I thought the plan was to make it a soft one | 07:42 |
jml | vila, also, launchpadlib.uris was added to launchpadlib mere hours _after_ the last version of launchpadlib was released | 07:43 |
vila | LOL | 07:43 |
vila | Gimme the new toys ! | 07:44 |
jml | it was released last in October | 07:44 |
vila | argh | 07:44 |
jml | there's been a whole release of Ubuntu since then. | 07:44 |
vila | jml: don't get me wrong, there are very good reasons to use the new toys :) | 07:45 |
MvG | Hi! Is there some public official way to have bzrlib determine the relation between two revisions? I'm thinking along the lines of Branch._revision_relations, preferably with the caching Repository.__heads as the backend graph. | 07:47 |
spiv | MvG: I guess doing g = repo.get_graph(); heads = g.heads([revA, revB]) gives you that info with reasonable caching. | 07:52 |
spiv | MvG: I think it would be reasonable to promote _revision_relations to a public API somewhere, although it probably doesn't belong on branch. | 07:53 |
MvG | I think so, too. | 07:53 |
MvG | I guess I'll write a mail requesting that. Last time I wrote such a mail, I was told the function I requested already exists (Repository.iter_reverse_revision_history), so I thought I'd ask here first this time. :-) | 07:54 |
spiv | MvG: so what I'd do then is rely on _revision_relations and file a bug about promoting it | 07:54 |
spiv | Heh. | 07:54 |
spiv | Well, it's possible that it already does and I just haven't thought of it :) | 07:54 |
spiv | If it does, then presumably I can remove _revision_relations and cut down on duplicated code ;) | 07:54 |
spiv | Hmm, I think it probably makes sense a method on Graph. | 07:55 |
spiv | I suppose Graph.find_difference sort of gives you the same thing. | 07:56 |
spiv | Dunno what the performance of that is lie. | 07:57 |
spiv | like, rather. | 07:57 |
spiv | There's Graph.is_ancestor, which gives you part of the info. | 07:58 |
MvG | Graph.find_difference does much more: it seems to list all revisions which are ancestor of one head but not of the other. Way too much overhead. | 07:58 |
spiv | But no equivalent method that I can see. | 07:59 |
MvG | Graph.is_ancestor is implemented in terms of heads, so using heads directly to determine both directions should cut my costs by hald at least. | 07:59 |
spiv | _revision_relations is also implemented in terms of heads. | 07:59 |
MvG | Yes, that's how I found it. | 07:59 |
spiv | But only makes a single heads call, of course. | 07:59 |
spiv | Anyway, a patch to move _revision_relations to Graph with a public name makes sense to me. I'd happily review a patch to do that, presumably we'd want to add unit tests for it though. | 08:00 |
MvG | spiv: Why to graph, not to repository? Repository.__heads is a special caching graph instance, and reusing that instance seems benificial to me. | 08:07 |
spiv | MvG: Repository.get_graph() should already be caching, so I don't think there's a practical difference | 08:12 |
MvG | Repository.get_graph() does cache the graph itself, while Repository._heads does cache results from heads requests directly. | 08:13 |
spiv | Well, I suppose __heads is specially optimised for heads() lookups. | 08:13 |
spiv | But if it's that useful I would think it should be cached on graph rather than the repository. | 08:14 |
spiv | MvG: Actually Repository doesn't have __heads/_heads, you're looking at CommitBuilder I think | 08:15 |
spiv | MvG: which probably explains why there's no code that resets the _heads cache during Repository.unlock, and probably also ensures the memory impact of that cache will be small :) | 08:16 |
MvG | spiv: You're right. I guess I'm too used to Java, with its one class per file paradigm. | 08:17 |
jml | On https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth/+merge/15853, poolie points out that the patch will cause launchpadlib to be loaded whenever bzr is loaded | 08:18 |
MvG | OK, so we assume that caching all heads requests might be too expensive, and furthermore that we can get at a reasonable caching graph using Repository.get_graph(). In this case a method in Graph would really be the better alternative, I guess, yes. | 08:18 |
spiv | MvG: right | 08:18 |
jml | I thought plugins were loaded lazily | 08:18 |
jml | if they aren't, how can I do a conditional lazy import? | 08:19 |
spiv | MvG: if you find with that that performance isn't good enough, then we can always try to think of ways to do better :) | 08:19 |
spiv | jml: they can't be; otherwise how can a plugin e.g. decorate a builtin command the way bzr-loom does? | 08:19 |
spiv | jml: however, plugins can and should use lazy_import themselves | 08:19 |
jml | spiv, ok. that's good to know. | 08:20 |
jml | spiv, how do I do a lazy import that behaves like the one in the patch? | 08:20 |
spiv | jml: in my ideal world, a plugin's __init__ would register commands or hooks or whatever it needs to do, and have the rest of the code lazy imported. | 08:20 |
* spiv looks | 08:20 | |
spiv | jml: so, you want lp-mirror to only exist if the dependency is available? | 08:21 |
spiv | jml: why not make it always exist, but give an error if the dependency is missing? | 08:21 |
spiv | jml: I think that might be a nicer UI too, it seems more discoverable to me | 08:22 |
jml | spiv, I guess I could do that. | 08:22 |
spiv | "Why don't I have lp-mirror, I have the launchpad plugin!" | 08:22 |
spiv | jml: and in that case, the lazy import can just be a good ol' fashioned local import in the run method of that Command if you like. | 08:22 |
jml | spiv, I can imagine it being a little confusing to have lots of available commands that you can't actually use. | 08:22 |
spiv | Well, let's worry about that when we have lots rather than one? | 08:23 |
* igc dinner | 08:23 | |
spiv | I can imagine making some infrastructure for that, maybe provide something like "bzr plugins --check-deps" that plugins can hook into? | 08:24 |
spiv | But we already have this situation with e.g. SFTP support without causing much drama. | 08:24 |
spiv | (If you don't have paramiko I believe attempts to use sftp:// URLs will give you a relatively friendly error about needing paramiko) | 08:25 |
spiv | Anyway, I'd argue it's no more confusing than commands simply not existing even though you think you've installed the plugin that provides it. | 08:26 |
jml | OK | 08:26 |
spiv | (Or with a bundled plugin, that you think you've installed the version bzr that bundles the plugin that provides it... see, confusing ;) | 08:27 |
spiv | jml: I'll add a brief note about my opinion to the review for posterity | 08:28 |
MvG | spiv: I guess I'd rather return a number (e.g. -1, 0, 1) instead of a string, as numbers are cheaper to compare. Opinions? | 08:31 |
spiv | MvG: strings are almost as cheap to compare, especially if they are literals that contain strings that can be Python identifiers, because those strings are interned | 08:32 |
spiv | MvG: so the comparison in that case is basically just a pointer comparison | 08:33 |
spiv | MvG: I'd be happy have module-global constants for those strings, I think. | 08:33 |
spiv | MvG: but I really doubt that the cost of that comparison will be significant compared to the cost of the underlying heads call! | 08:33 |
MvG | Probably true, yes. | 08:34 |
spiv | MvG: If you measure a performance problem, I'd be very happy to look at the measurement and figure out improvements, though :) | 08:34 |
spiv | MvG: but I strongly advise against micro-optimisations that impact code clarity without evidence that they'll have a significant effect. | 08:34 |
MvG | Agreed. Didn't know about Python cheaply comparing such things. | 08:35 |
MvG | spiv: would you agree that the plural in "_revision_relations" is wrong? There is only one possible relation between any two given revisions. | 08:36 |
spiv | MvG: yes | 08:37 |
spiv | MvG: I've no idea why I never noticed that before :) | 08:37 |
spiv | MvG: as far as Python cheaply comparing such things, I've skipped over a bunch of mostly unimportant details about how CPython compares ints and how it compares strs... But the general rule of measure before guessing about optimisations certainly applies :) | 08:39 |
spiv | MvG: I'll happily chat about CPython implementation trivia sometime if you like, but not tonight :) | 08:40 |
MvG | spiv: I guess I also had some concerns about typos in literals on the part of the caller, but constants take care of this. By the way, is there some python idiom to declare a constant as opposed to a variable? | 08:42 |
spiv | MvG: CONSTANT = 'value' | 08:48 |
spiv | MvG: rather than: variable = 'value' :) | 08:49 |
MvG | But python doesn't enforce constantness on these, does it? | 08:49 |
spiv | No, but it doesn't enforce constantness on anything, more or less :) | 08:49 |
spiv | Except the evaluation of 1+1, and I've seen an extension module to change that ;) | 08:50 |
MvG | spiv: By the way, I sent my mail requesting the method: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/64622 | 08:50 |
spiv | MvG: thanks! | 08:50 |
sjamaan | I'd like to make a checkout (or branch) of only a subdirectory in a repo. Is that possible? | 09:14 |
MvG | sjamaan: I'm no expert, but I'd guess no. I assume you'd have to branch the whole tree, then you could split of a subdirectory into a separate project if you want to. | 09:17 |
MvG | Although I assume that if you split, changes to that subdir are at least more difficult to merge back into the whole tree. Dunno, though. | 09:18 |
sjamaan | Can I keep updating the subtree from the main repo? | 09:25 |
sjamaan | (I've never used SPLIT before) | 09:25 |
sjamaan | ie, can pull fetch data from a subdir in a branch? | 09:26 |
jml | spiv, I'm pushing up a new version that makes the change you've suggested. | 09:29 |
jml | very. solwly. | 09:29 |
jml | (well, after I upgrade it. man, isn't that just the gift that keeps on giving?) | 09:30 |
jml | spiv, pushed. | 09:46 |
=== weigon_ is now known as weigon | ||
TeTeT | I run into a problem on karmic when pushing to LP, http://pastebin.ubuntu.com/337892/ | 10:02 |
TeTeT | it says different rich-root support | 10:02 |
TeTeT | I assume I need to upgrade the LP branch | 10:17 |
=== jelmer_ is now known as jelmer | ||
spiv | TeTeT: right | 10:43 |
spiv | TeTeT: generally "bzr upgrade lp:FOO" should Just Work. | 10:44 |
TeTeT | spiv: can I still access the branch from hardy then with the new format? | 10:57 |
=== gdmfsob is now known as mishok13 | ||
spiv | TeTeT: you need bzr 2.0 (or at least 1.18), which I don't think is in hardy's backports yet, but we have a backport in the PPA: https://edge.launchpad.net/~bzr/+archive/ppa | 11:40 |
TeTeT | spiv: ok, so I rather branch on merge on hardy then, so it stays compatible, thanks | 11:42 |
spiv | TeTeT: if you create your repo with --pack-0.92, it'll be the same format as that branch on Launchpad | 11:49 |
TeTeT | spiv: I do that for init-repo? | 11:51 |
spiv | TeTeT: yep | 11:58 |
TeTeT | spiv: thanks for your help! | 12:06 |
spiv | TeTeT: not a problem, glad I could help. | 12:07 |
spiv | jml: are you sure you pushed? I don't see any new revisions | 12:19 |
spiv | jml: oh, it's stacked on the old, non-rich-root, bzr trunk, so boom: https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth | 12:20 |
spiv | jml: I think bzr and launchpad can take equal credit for that snafu ;) | 12:20 |
=== Meths_ is now known as Meths | ||
vila | jam, jam1, jam*: ping | 13:32 |
=== CardinalXiminez_ is now known as CardinalFang | ||
=== thunderstruck is now known as gnomefreak | ||
jam | vila: pong | 14:47 |
jam | sorry, pidgin disconnected and didn't want to reconnect until I restarted it | 14:47 |
vila | bad pidgin :) | 14:48 |
vila | jam: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 is up for windows tests | 14:50 |
vila | ./bzr selftest -s bt.test_osutils.TestTerminal should now pass | 14:50 |
vila | but see cover letter for my requests ;-) | 14:51 |
__monty__ | Is it a good idea to have a hand at some low priority bugs to get more python experience? | 14:51 |
vila | __monty__: sure | 14:51 |
rubbs | __monty__: sure. The devs here are really good at helping you through the process of getting it included too. | 14:52 |
jam | __monty__: you might look for the "easy" tag | 14:52 |
jam | if people haven't grabbed them all already | 14:52 |
jam | I think there might also be "trivial" ? | 14:52 |
jam | vila: so, one of the primary reasons to use stderr is because progress bars go to ... stderr | 14:52 |
jam | so even if you redirect stdout | 14:53 |
jam | you still would like to know the term width, to draw a progress bar | 14:53 |
__monty__ | Thanks for the quick replies. | 14:53 |
jam | that said, I guess the test suite wants to have stdout width | 14:53 |
jam | which means... it sounds like we should have a flag | 14:53 |
rubbs | __monty__: I would suggest a trivial tag at first. just to get your first patch in. Then once you get the hang of how to get something in go for something bigger. | 14:53 |
rubbs | that's what I did at least | 14:53 |
vila | jam: bzr help also needs the terminal width but outputs on stdout... | 14:54 |
vila | and so does log --line | 14:55 |
jam | sure | 14:55 |
jam | though what should those do when redirected to a file? | 14:55 |
jam | log --line, I would probably expect to go full width | 14:55 |
vila | use None and not cut lines | 14:55 |
jam | bzr help... probably we want to keep it wrapped at a reasonable width | 14:55 |
vila | yup | 14:55 |
jam | since otherwise the full help texts becomes super long | 14:55 |
jam | or the text editor wraps it in an ugly way | 14:56 |
vila | long story short, that's what BZR_COLUMNS is for | 14:56 |
vila | to come back to windows, using stderr or stdout shouldn't matter since it should not be called anymore | 14:57 |
vila | you had some tests with and without redirection, how do they behave now ? | 14:58 |
vila | with --subunit and tee IIRC | 14:58 |
jam | vila: but that is an ugly way to do it | 14:58 |
jam | BZR_COLUMNS=20 bzr command foo > | 14:58 |
jam | espec on windows | 14:58 |
jam | where you can't inline it | 14:59 |
jam | set BZR_COLUMNS=40 | 14:59 |
jam | bzr command foo > | 14:59 |
jam | set BZR_COLUMNS= | 14:59 |
jam | I would like to have a better answer than that | 14:59 |
jam | but yes, I'll run the tests | 14:59 |
vila | yeah I know, poolie filed a bug about using -O to set options without polluting the global options namespace. Fom there having some rules to go from env variables to options should filled the gap. At least for things like BZR_PLUGIN_PATH and BZR_COLUMNS | 15:00 |
vila | so you can use say bzr -OBZR_COLUMNS=46 command | 15:01 |
vila | or bzr -OBZR_PLUGIN_PATH=-site selftest \o/ | 15:01 |
jam | vila: test suite passes on windows when run manually and when run redirected | 15:01 |
jam | oops | 15:01 |
jam | spoke too soon | 15:01 |
jam | test_falls_back_to_COLUMNS | 15:02 |
jam | fails | 15:02 |
jam | when redirected | 15:02 |
jam | 42 != None | 15:02 |
jam | vila: you have: getattr(sys.stdout, 'isatty', None) before the COLUMNS check | 15:03 |
jam | so I think that test would fail on Linux when redirected as well | 15:03 |
vila | yeah, so that test is bogus | 15:03 |
vila | COLUMNS makes sense only for a tty | 15:04 |
jam | vila: as said before, stderr may be a tty even if stdout isn't | 15:04 |
jam | ... :) | 15:05 |
vila | hmm | 15:05 |
vila | I;m tempted to reply ESCOPE :-) | 15:06 |
=== vds1 is now known as vds | ||
jam | so, I want my test suite to pass | 15:08 |
jam | I don't really care about the answer here | 15:09 |
jam | what we've had has been just fine for me for a long time | 15:09 |
vila | jam: pushing a fix | 15:09 |
jam | I would be a little concerned about fixing something that isn't broken | 15:09 |
jam | but apparently for others it is ? | 15:09 |
vila | well, the main problem was pagers and the lack of overriding solution | 15:10 |
vila | I think the proposed fix make things clearer | 15:10 |
vila | to address the stdout/stderr I think we need yet another pass on all uses and disambiguate the API by explicitly requesting for either stdout or stderr, the windows heuristic sounds brittle otherwise | 15:11 |
vila | what if stderr is redirected and not stdout ? | 15:12 |
jam | vila: right, so 'bzr log --line | less' is different than 'bzr log --line > file', but I don't think there is a way to detect the difference | 15:12 |
jam | vila: unlikely to have stderr redirected and not stdout | 15:12 |
jam | and if it does, then progress bars do crazy things | 15:12 |
vila | OMFG how did they implement pipes 8-/ | 15:12 |
vila | jam: never say unlikely on IRC, fullermd is never far away.... | 15:13 |
jam | we've had similar issues with encodings based on "| less" versus "> file" | 15:13 |
jam | because on windows | 15:13 |
jam | standard file encoding | 15:13 |
jam | != standard terminal encoding | 15:13 |
ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 15:13 |
jam | which is crazy | 15:13 |
jam | oh, and it isn't filesystemencoding either | 15:13 |
vila | !triggers ubottu ? | 15:13 |
ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 15:13 |
jam | vila: yeah | 15:14 |
jam | so you can say !paste | 15:14 |
jam | but only at the beginning | 15:14 |
jam | !paste | 15:14 |
ubottu | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic | 15:14 |
jam | !pastebinit | 15:14 |
ubottu | pastebinit is the command-line equivelent of !pastebin - Command output, or other text can be redirected to pastebinit, which then reports an URL containing the output - To use pastebinit, install the « pastebinit » package from a package manager - Simple usage: command | pastebinit | 15:14 |
jam | interesting | 15:14 |
jam | hard to parse "pastebin it" | 15:14 |
jam | I thought it was "pastebin init" at first | 15:14 |
jam | anyway | 15:14 |
jam | vila: do what feels good to get things passing | 15:15 |
jam | we've probably spent far too much time versus the utility already | 15:15 |
jam | (my feeling is, we're going to get it wrong, probably fairly often. whatever decision we choose) | 15:15 |
vila | jam: agreed, fix pushed, can you check it works for you | 15:15 |
jam | vila: all tests pass | 15:16 |
vila | on the other hand, people have complained regularly about the lack of pager support, now we have *some* support | 15:16 |
vila | jam: Courtesy url for votes: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 | 15:17 |
vila | :D | 15:17 |
vila | you assigned bzr core devs on #154129 , what do you mean by that ? | 15:17 |
jam | we all worked together on implementing 2a | 15:19 |
jam | so we all get credit | 15:19 |
jam | bug #154129 | 15:19 |
ubottu | Launchpad bug 154129 in bzr "pack should recompress objects, optimise layout, etc" [Medium,Fix released] https://launchpad.net/bugs/154129 | 15:19 |
jam | well, at least I didn't feel I should be the only one getting credit, and once the number is greater than 1, there isn't a clear value to put three | 15:19 |
vila | jam: nevermind, I thought it was still open | 15:19 |
jam | vila: merge approved, witha bit of a mini rant for posterity | 15:23 |
vila | lol | 15:23 |
vila | jam: good summary.... I'll put https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 in some commit message so you'll get true posterity :^) | 15:25 |
__monty__ | Would this: https://bugs.launchpad.net/bzr/+bug/257170 be a good bug for a beginner? | 15:26 |
ubottu | Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed] | 15:26 |
fullermd | Hmm? Somebody summon me with an 'unlikely'? :p | 15:30 |
jam | __monty__: probably. I think it is already slightly fixed when there is an exception, but it probably would be good to write out "bzrlib.__version__" on startup always. | 15:30 |
jam | fullermd: your summoning time has gotten slow recently :) | 15:31 |
jam | well, today at least | 15:31 |
__monty__ | jam: By startup you mean? | 15:31 |
fullermd | Well, you've never met me, so you'll have to take my word for it, but TRUST me; I NEED my beauty sleep :p | 15:31 |
vila | fullermd: sleep is for ? | 15:32 |
jam | __monty__: the bug is that when the bzr process starts, we log the command line arguments, but we don't put version info into the log file | 15:32 |
jam | fullermd: sort of a Shrek1 sort of thing? (by night one way, by day another) | 15:32 |
__monty__ | jam: So it doesn't have anything to do with bzr log ? | 15:33 |
jam | __monty__: correct | 15:33 |
jam | this is about .bzr.log | 15:33 |
jam | not 'bzr log' | 15:33 |
fullermd | Of course, in this case I won't contest the unlikely. Being a csh user, I don't get to adjust stderr without touching stdout :p | 15:33 |
__monty__ | To work on bzr bugs, which source release should I get? | 15:35 |
=== beuno is now known as beuno-lunch | ||
Pilky | ouch: http://www.reddit.com/r/programming/comments/acsad/bazaar_blows_goats/ | 15:49 |
Pilky | I sort of agree with the gist of his launchpad comment and the cold start slowness, but the rest of it sounds like "It isn't what I'm used to, waaah" | 15:50 |
=== abentley1 is now known as abentley | ||
jam | fullermd: why is that the case on csh? | 16:32 |
__monty__ | Should I get the stable or the developer release of the source code to work on bugs? | 16:38 |
=== beuno-lunch is now known as beuno | ||
jelmer | __monty__, the code from bzr.dev ideally | 16:43 |
fullermd | jam: You mean historically? Dunno. Just how it is. | 16:45 |
jam | fullermd: is it just that the syntax doesn't let you? | 16:45 |
jam | __monty__: for this, the stable code would be ok, but bzr.dev is fine, too | 16:45 |
fullermd | Oh, yes. It's one of the standard csh-whynot-isms. | 16:45 |
fullermd | You can dup it onto stdout, and that's about it. | 16:46 |
NfNitLoop | so... I seem to get the impression that bzr-svn stores more metadata than git-svn when you push back into the upstream svn repo... | 16:47 |
NfNitLoop | is that true? Anyone know off-hand? | 16:48 |
NfNitLoop | Ok, I'll ask Google. :) | 16:49 |
jelmer | NfNitLoop: yes, that's true - bzr has more metadata than git | 16:51 |
NfNitLoop | I know bzr stores the non-linear history metadata as svn properties... is that what's missing in git? | 16:52 |
NfNitLoop | It may be a bit academic. If git-svn lets me work with our SVN repo that bzr-svn won't (because at some point in its history there was a file with backslashes in its name)... I may just suffer through using git. | 16:57 |
Tak | bzr-git < git-svn < svn ? ;-P | 16:59 |
NfNitLoop | ya, ew. | 17:00 |
NfNitLoop | :p | 17:00 |
jelmer | NfNitLoop: That's one thing | 17:00 |
jelmer | NfNitLoop: Other things are: file ids, revision ids and revision properties (none of which git has) | 17:00 |
Pilky | Tak: why not throw hg in there and do bzr-hg < hg-git < git-svn < svn :p | 17:00 |
NfNitLoop | ah, I knew git didn't do file IDs... it doesn't even store the revision ID!? | 17:01 |
NfNitLoop | that seems odd. | 17:01 |
Pilky | Tak: if you tried hard enough you might be able to get cvs in there somewhere | 17:01 |
fullermd | git revision id's are entirely derivable from the contents of the revision. | 17:01 |
NfNitLoop | so if you then do an update you might start getting conflicts with branches that have already merged the changes? | 17:01 |
NfNitLoop | aaah. | 17:01 |
NfNitLoop | ok, that's fine then. | 17:01 |
jelmer | NfNitLoop: I'm not sure what the status of backslash support is | 17:01 |
NfNitLoop | in git? I guess I'll see when git gets to that revision. :p | 17:02 |
Tak | Pilky: I guess that would depend on whether hg or git have a cvs wrapper | 17:02 |
Tak | speaking of which, I pulled down someone's inadvertent commit of an RCS dir to our svn repo the other day | 17:03 |
jelmer | NfNitLoop: in bzr | 17:03 |
jelmer | NfNitLoop, bzr-svn supports backslashes fine | 17:03 |
NfNitLoop | jelmer: ah, I'm subscribed to the bug about it. haven't seen any traffic lately. | 17:03 |
=== deryck is now known as deryck[lunch] | ||
__monty__ | Is there a bug which you would advise for a newb? | 17:58 |
jelmer | __monty__: try looking for bugs triaged trivial in launchpad | 18:09 |
__monty__ | Any of them? | 18:10 |
__monty__ | Such as: https://bugs.launchpad.net/bzr/+bug/239523 | 18:10 |
ubottu | Ubuntu bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed] | 18:10 |
jelmer | yeah, all bugs tag trivial *should* be doable for people looking to contribute to bzr for the first time | 18:12 |
jelmer | feel free to ask for mentoring here or on the mailing list | 18:12 |
RenatoSilva | verterok: hi | 18:13 |
__monty__ | What are the responsibilities of a mentor? | 18:13 |
jam | __monty__: it isn't quite an official thing. Just that you can ask for help/questions and we'll try to help you | 18:19 |
__monty__ | Oh ok. | 18:19 |
RenatoSilva | verterok: ok np :) | 18:30 |
=== deryck[lunch] is now known as deryck | ||
jam | __monty__: I should also mention our PatchPilot program: http://wiki.bazaar.canonical.com/PatchPilot | 19:19 |
jam | Which is where we have people specifically working on helping people land their patches | 19:19 |
johnjosephbachir | hello | 19:47 |
__monty__ | hi | 19:47 |
johnjosephbachir | how do i make a new remote branch? this equivalent from subversion does not work: bzr branch http://example.com/foo http://example.com/bar | 19:48 |
johnjosephbachir | do i make the new branch locally and then push it? | 19:48 |
beuno | johnjosephbachir, yes | 19:48 |
johnjosephbachir | there isn't a more direct way? | 19:48 |
beuno | johnjosephbachir, bzr init REMOTE_LOCATION | 19:49 |
beuno | but you can't do it via http | 19:49 |
beuno | you will need ssh | 19:49 |
johnjosephbachir | how about webdav? | 19:49 |
johnjosephbachir | bueno what would be the command for ssh? | 19:49 |
johnjosephbachir | okay, i just did it the push-from-local way, and it worked in seconds -- so i guess bzr was smart about using the remote repo, hoorary | 19:52 |
johnjosephbachir | sorry for the newb question | 19:52 |
rubbs | johnjosephbachir: don't be sorry for newb questions. If anything it gives those of us on the doc team something to consider | 19:55 |
rubbs | ;) | 19:55 |
johnjosephbachir | thanks | 19:55 |
rubbs | np | 19:55 |
=== EdwinGrubbs is now known as Edwin-lunch | ||
jml | spiv, I don't supposed you fixed it? | 20:09 |
=== BasicPRO is now known as BasicOSX | ||
dOxxx | *sigh* cable outages suck :P | 20:43 |
=== SteveA_ is now known as SteveA | ||
rubbs | dOxxx: yes, cable outages do suck. What caused yours? | 21:08 |
dOxxx | we've had a bit of a winter storm here, so I guess it's causing trouble with the wires | 21:08 |
dOxxx | don't know for certain though | 21:08 |
rubbs | ah, you in the midwest? | 21:09 |
rubbs | I used to live in Iowa | 21:09 |
dOxxx | nope, Toronto | 21:09 |
rubbs | ah, gotcha. | 21:10 |
rubbs | I live in Ohio now so we're about to get one too. | 21:10 |
dOxxx | Enjoy! :) | 21:12 |
dOxxx | hmmm... might be cutting out again soon | 21:12 |
dOxxx | ominous pauses | 21:13 |
rubbs | haha | 21:14 |
fullermd | Winter... yeah, I remember hearing about that, years ago... | 21:15 |
phinze | ack! my shelf! http://gist.github.com/252861 | 21:49 |
phinze | hmm looks like it's bug 389674 | 21:50 |
ubottu | Launchpad bug 389674 in bzr "exception encountered when unshelving" [Undecided,New] https://launchpad.net/bugs/389674 | 21:50 |
phinze | This is because the conflict handling code has not been fully updated to avoid using Tree.inventory. -- abentley | 21:51 |
phinze | i'm looking at the shelf-1 file, which is in 'Bazaar pack format 1' | 21:54 |
phinze | i feel like i know where the evil conflict is, but i don't know how many lines to delete :P | 21:55 |
phinze | eh, feels like i'm about 10 minutes short of finding docs on the format, but it's small enough that it's faster for me to manually re-apply the changes | 21:58 |
phinze | sure | 21:59 |
phinze | that worked | 21:59 |
jelmer | what exactly are the release plans for bzr 2.1? Should lucid have 2.1? | 22:11 |
spiv | jml: at 11pm? No :) | 22:11 |
jml | spiv, what are you replying to, excatly? | 22:11 |
spiv | jml: <jml> spiv, I don't supposed you fixed it? | 22:11 |
jml | spiv, oh ok. I wasn't online at 11pm, so I was a bit confused. | 22:12 |
poolie | hi all | 22:28 |
mdt | I'd like to back up my repositories (weekly using a cron script) to a remote backup service. Anybody know how to do this? With CVS I just copied the files in the central repository to the remote server using rsync. | 22:43 |
gioele | mdt: you can do that with bzr as well | 22:45 |
mdt | New to Bazaar so don't rly know how/where data is kept, even | 22:46 |
gioele | just rsync the .bzr directory of the repository | 22:46 |
gioele | I have a repository at /srv/backup/ | 22:47 |
gioele | that directory contains a .bzr sub directory | 22:47 |
gioele | I use rsync --archive --partial --partial-dir=.rsync-partial --delete-delay --progress -i /srv/backup/ remote:~/backup-bzr | 22:49 |
fijal | hi | 22:49 |
fijal | I'm looking for bzr benchmarks | 22:49 |
poolie | fijal: http://bazaarvcs.wordpress.com/tag/benchmark/ | 22:49 |
poolie | to start with | 22:49 |
fijal | er | 22:50 |
fijal | ok | 22:50 |
fijal | let's be more specific | 22:50 |
fijal | I look for bzr performance benchmarks | 22:50 |
spiv | poolie: fijal is a pypy dev, I think | 22:50 |
fijal | correct | 22:50 |
poolie | you want to test bzr under pypy vs elsewhere? | 22:50 |
fijal | yop | 22:50 |
poolie | check out https://launchpad.net/bzr-usertest | 22:51 |
spiv | And thus wants to make C extensions for performance obsolete ;) | 22:51 |
poolie | which runs various macrobenchmarks | 22:51 |
poolie | ooh, welcome :) | 22:51 |
fijal | does it come with "a standard repository"? | 22:51 |
poolie | there are some in-tree microbenchmarks but they tend to rot | 22:51 |
poolie | fijal: no, it runs on your choice of repository | 22:51 |
poolie | since the test data would be large | 22:51 |
poolie | possibly we should put some snapshots in its download files | 22:51 |
fijal | can I have one large repository please :) | 22:51 |
spiv | fijal: lp:mysql :) | 22:52 |
poolie | bzr branch lp:mysql | 22:52 |
poolie | :) | 22:52 |
fijal | ok | 22:52 |
poolie | hi spiv too | 22:52 |
spiv | Good morning :) | 22:52 |
fijal | well, it's sort of hard to look for pure-python benchmarks | 22:52 |
fijal | which are *not* template languages | 22:52 |
spiv | Haha | 22:52 |
spiv | I can believe that :) | 22:52 |
mdt | so does the .bzr directory contain all the info required to reproduce all the files in my project? I mean if I simply copy that dir recursively onto a brand new machine somewhere I'll be able to check out my project from it? | 22:53 |
fijal | for example mostly everybody moved to C | 22:53 |
fijal | side question - what's the ratio of oldstyle vs newstyle classes in bzr? | 22:53 |
fijal | (I'm too lazy to check) | 22:53 |
spiv | Practically all new. | 22:53 |
fijal | good | 22:54 |
fijal | this is completely unlike twisted | 22:54 |
spiv | Indeed :) | 22:54 |
fijal | which has practically all old | 22:54 |
spiv | We've depended on python >= 2.4 since bzr began. | 22:54 |
spiv | Twisted didn't have that luxury :) | 22:54 |
fijal | right | 22:55 |
spiv | (glyph just cited some 1.5.2 docs at me in a recent review of a patch I just did for Twisted!) | 22:55 |
mdt | @gioele ty | 22:56 |
igc | morning | 22:57 |
fijal | ok | 22:58 |
fijal | since it | 22:58 |
fijal | 's midnight I'll actually go to bed | 22:58 |
fijal | I'll try to make some benchmarks tomorrow then | 22:59 |
gioele | just wondering, how long does it take to branch lp:mysql? | 22:59 |
spiv | fijal: oh, lp:mysql-server is actually the large branch I think, I'm not sure there's actually a lp:mysql | 23:04 |
spiv | gioele: well, lp:mysql-server is ~450M of history, although it's still in 1.9 format | 23:11 |
Peng | gioele: You didn't make the destination repo 2a, did you? | 23:13 |
gioele | Peng: everything is pack-0.92 | 23:13 |
gioele | Peng: couldn't I do that with 2a? I don't see why | 23:22 |
* jelmer waves to igc, spiv, Peng and gioele | 23:22 | |
igc | hi jelmer! | 23:23 |
gioele | lifeless: ping | 23:23 |
lifeless | hi? | 23:24 |
gioele | lifeless: may I ask you something (in a query) about the la_AU locale? | 23:24 |
gioele | hi jelmer | 23:25 |
jelmer | la_AU... is that what I think it is? | 23:25 |
lifeless | jelmer: lingua latina | 23:25 |
spiv | jelmer: hi :) | 23:25 |
lifeless | the AU is a nonsense due to posix being naffed | 23:25 |
lifeless | gioele: sure, or you can ask here. | 23:25 |
gioele | oh, well, OK | 23:25 |
Peng | gioele: It's just that trying to convert lp:mysql-server to 2a over the network ends in unhappiness. | 23:26 |
lifeless | its not particularly private :> | 23:26 |
gioele | I'm trying to create a locale as well (English language with European LC_*) | 23:26 |
gioele | how did you test it? | 23:26 |
lifeless | built packages, installed, ran shit. | 23:27 |
lifeless | uhm, the xlib thing is the most tricky bit - gnome apps *ignore* xlib's locale support | 23:27 |
gioele | did you sudo cp la_AU into /usr/lib/locales? | 23:27 |
lifeless | so | 23:27 |
lifeless | no | 23:27 |
gioele | ok, I suppose I'll have to bzr-debuild some packages :) | 23:28 |
lifeless | I patched gdm, libc6, libx11 | 23:28 |
gioele | lemme write that down | 23:28 |
lifeless | these days you shouldn't need to patch gdm | 23:28 |
gioele | these days? why? | 23:28 |
lifeless | its been rewritten and no longer has a whitelist of locales. | 23:28 |
gioele | ah, ok, one down | 23:28 |
gioele | what should be done in libx11? | 23:29 |
lifeless | there is a long list of keyboard processing stuff | 23:29 |
lifeless | so you will need to pick a locale that works, find all references to it, and clone them to your new one. | 23:30 |
lifeless | locales: why conflating data with different dimensions is a bad idea. | 23:30 |
lifeless | breakfast time | 23:32 |
lifeless | gioele: I blogged about this at the time, with links to my patches | 23:32 |
lifeless | two separate blog posts I think, cause I realised libx11 was broken after the first patch. | 23:33 |
gioele | lifeless: I read those, this is the reason I'm here asking these questions :) | 23:33 |
gioele | the fact is I can't find a link to the libx11 issue | 23:33 |
lifeless | hmm | 23:33 |
spiv | poolie: no, I'm not on emacs-devel | 23:34 |
lifeless | gioele: https://bugs.edge.launchpad.net/ubuntu/+source/libx11/+bug/423569 https://lists.ubuntu.com/archives/karmic-changes/2009-June/002209.html https://edge.launchpad.net/ubuntu/+archive/primary/+files/libx11_1.2.1-1ubuntu1.diff.gz | 23:35 |
ubottu | Ubuntu bug 423569 in libx11 "la locale support was reverted in merge from debian" [Undecided,Confirmed] | 23:35 |
lifeless | poolie: you pung on a patch; I'll probably look at it in the new year. | 23:35 |
poolie | k | 23:35 |
poolie | is not urgent | 23:35 |
poolie | just shows up in my activereviews page | 23:35 |
lifeless | its bzr-email, right? get jam to review | 23:35 |
lifeless | he has done a lot in that plugin as well | 23:35 |
lifeless | or andrew :) - its a team branch I think, and I feel no special urge to control it | 23:36 |
gioele | lifeless: thank you, the libx11 part does not look difficult at first sight (now that you dig into it ;)) | 23:38 |
johnjosephbachir | anyone here have much experience with split/join/ nested trees ? | 23:40 |
xnox | Does a "$bzr checkout lp:project" have full branch history? | 23:42 |
spiv | xnox: yes | 23:42 |
xnox | But it is bound? | 23:42 |
spiv | RIght. | 23:42 |
spiv | If you run "bzr info", you'll see that the repository for it is local rather remote. | 23:43 |
xnox | Ok. And I can run $bzr reconfigure to change from a regular branch to bound | 23:43 |
xnox | Can a checkout still have :parent, :push and :submit? | 23:44 |
xnox | Or bound to two places? | 23:44 |
spiv | It can only be bound to one place. | 23:46 |
spiv | Otherwise you'd have to deal with confusing situations like "bzr commit" successfully updating one place but failing on the other. | 23:46 |
xnox | get it =) and confusing | 23:47 |
spiv | Well, I guess in that case lock_write() each place first might be ok... but you get the idea :) It's complex enough! :) | 23:47 |
spiv | I believe a checkout "has" :parent etc, because actually those belong to the branch, so they are looked up on the bound branch if you have a checkout. | 23:48 |
spiv | So they work, but I think they belong to the branch rather than checkout itself. | 23:49 |
spiv | I'm not 100% certain about that. | 23:49 |
xnox | I'll try to make a :parent :push and then reconfigure as bound | 23:50 |
gioele | goodnight | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!