[00:00] mwhudson: I mean when I 'rm a', 'bzr status' lists it as deleted and 'bzr commit' removes it from the repository [00:00] I don't want that. [00:00] rather, I want bzr to leave it alone like svn does [00:03] luke-jr: there isn't a global option for this at the moment. I wanted to make it be like svn but got shot down on the mailing list [00:03] wtf ☹ [00:03] is there a not-so-global option? [00:03] luke-jr: you can supply --strict to commit, and it will cause missing files to be considered an error [00:04] no way to automatically use --strict? [00:04] wait, an error? ☹ [00:04] why can't it just ignore it⁇ [00:04] Is there a bzr command that just pushes back where the code was pulled from? [00:04] ScottK: bzr push :parent [00:04] lifeless: Thanks. [00:06] luke-jr: well its code, anything is possible. I'm just describing what the current code does, and that I wanted to make new files and missing files be treated symmetrically, but didn't manage to get consensus on the list for this [00:06] luke-jr: you're welcome to dig up that thread and post referring to it. Support from users would be good :P [00:08] You could automatically use strict by just setting up an alias. [00:09] fullermd: an error blocks commits, I presume- [00:09] I just want the files not present in my WC [00:09] yet not delete them from the repo [00:09] and still be able to commit changes [00:10] oh well, that's less likely to win favour [00:10] the idea of commit is that it records what's on disk [00:11] it doesn't go trying to add my temp note files] [00:11] -.- [00:11] true, that's why i have commit --strict on by default... [00:11] … [00:12] so how do I get that? [00:12] better an error than remove I suppose [00:14] luke-jr: there is a plan, for 'views' which will be a WT setting that says what files to have present on disk; when that is implemented you could use it to get rid of some files from disk without having commit remove them from the branch [00:14] luke-jr: its not implemented yet, I'm just letting you know that its planned [00:46] is there anyway to make local commits the default with TortoiseBzr? === kiko is now known as kiko-zzz [01:07] http://paste.ubuntu.com/108059/ - currnet knit vs gc with 1G corpus [01:09] seems a bit better :) [01:09] is the "how do we make gc stream" question addressed yet? [01:10] are there known issues with bzr blame? [01:10] I ran blame on a repo that I've branched from svn. [01:10] bzr blame says a line was last changed in r1 [01:10] but when I svn blame the repo, I find otherwise. [01:11] (yes, I know svn rev#s are different from bzr rev#s) [01:12] What I seen in svn is that the line has been changed since it was created. bzr blame leads me to believe that it has been the same since its initial revision. [01:12] NfNitLoop: no issues like that. [01:13] NfNitLoop: but bzr-svn will have recalculated all the diffs between revisions. [01:13] mwhudson: well, just compress on the fly [01:13] NfNitLoop: and so it's possible that it's calculated a different (but equivalent) diff to svn for the same change to a file [01:13] mwhudson: (as one possible answer) [01:14] OOOoooh. [01:14] Yes, I see, spiv. Thanks. [01:14] The file was copied in svn. [01:15] NfNitLoop: e.g. consider four lines "aabb" becoming "bbaa" [01:15] and svn keeps the history through copies. [01:15] and, IIRC, bzr doesn't? [01:15] NfNitLoop: did "aa" get deleted and re-added, or did the "bb" lines get deleted and re-added :) [01:15] NfNitLoop: oh, yes, that too. [01:15] yeah, that's it. [01:17] the diff is pretty simple. one line's boolean is getting switched between "true" and "false". [01:17] with no justification in comments or commit messages. [01:18] Anyway, thanks for the help! [01:35] does 'bzr mv' work with bzr-svn right, or does it just add? === jfroy|work is now known as jfroy === jfroy is now known as jfroy|work [02:17] I filed a bug about a week ago and got a response asking for more info. I provided the info, but I'm not sure if I should do something else in launchpad to get a further response. Could someone take a look at the bug and let me know if I've missed something? https://bugs.launchpad.net/bzr/+bug/316196 [02:17] Launchpad bug 316196 in bzr "Error adding iTunes library on OSX" [Undecided,Incomplete] [02:19] what's the easiest way to make a personal bzr repo that can be shared (preferably over http)? [02:19] with subversion I used the apache module [02:22] i have problems with bzr [02:23] alevine, just push your repository to somewhere some web server is sharing [02:23] alevine, no special web server module needed. [02:23] alevine, (though if you want more performance, a "smart server" is available). [02:23] suse came with bzr 1.8 but i installed 1.6 and now everything is more complicated [02:23] nDuff, push it over...ssh? [02:24] its probably python 2.6 issues [02:24] thats very cool [02:24] alevine, ...it's fairly common to use SFTP for uploads (yes, pushes or bound commits) and let third parties use HTTP to download. [02:24] alevine: you must know that http is way way slower than the smart protocols [02:25] tecan, could you be more specific about the issues you're seeing? "everything is more complicated" isn't very actionable. :) [02:25] tecan: new bzr's work with 2.6, but 1.6 isn't very new [02:25] nDuff, asabil: thanks, performance is not an issue, mostly just for myself and for sharing code every once in a while [02:28] there is no where to download the latest tarballs ? [02:28] 1.6 is the latest i can get the source to [02:31] … [02:32] tecan, http://bazaar-vcs.org/ [02:32] erk [02:35] so what's the deal with file copies anyhow? [02:35] such a simple feature has no progress for years? [02:37] luke-jr, merge semantics become *much* complicated when one supports copies -- such that one pretty much *has* to do unintuitive things some of the time. [02:37] luke-jr, there's a pretty good argument to be made that supporting features that require you to do unintuitive things is bad. [02:37] s/features/"features"/ [02:42] * igc lunch [02:42] luke-jr, ...I can see supporting copies inasmuch as "create a new file which looks at this old one for purposes of blame and log operations", and that's probably a pretty reasonable feature request... [02:43] where can I find the default ignore list? [02:43] as in the files that are ignored by default [02:43] luke-jr, ...but having merges not change the new version under any circumstances probably isn't end-user-intuitive behavior either. [02:46] thumper, ~/.bazaar/ignore [02:50] nDuff: ta [02:56] anyone know where the bzr svg icon lives? [02:56] I want it for a presentation [02:59] http://bazaar-vcs.org/Icons I think [02:59] thumper: http://bazaar-vcs.org/LogoOptions [02:59] jam: fantastic, ta [03:01] jam: is there an svg without the text? [03:01] thumper along the bottom [03:01] bazaar192.svg? [03:02] or you can look here: http://bazaar-vcs.org/LogoOptions?action=AttachFile [03:02] there seem to be quite a few .svg files [03:30] nDuff: screw merge stuff, that's secondary to actually recording a copy [03:33] luke-jr, ...if you tell users you'll record a copy but don't then give them the behavior they expect when merging between a branch where a copy happened and a branch where the file was changed (whatever that "behavior they expect" may be), that's just asking for surprised/unhappy users. Heck, there'd be likely folks who'd expect copy+rm to behave the same way as a mv -- lots of other SCMs do it that way, after all. [03:34] ...but anyhow, it's been discussed on list; see the thread [RFC] Tracking file copies [03:34] cp+rm = mv [03:36] ...so are changes in the original going to impact copies on merge or not? (And, more to the point, will changes in the *copies* impact the *original* on cherrypick? If so, which copy?) "Only if the original has since been deleted" means you've got a new set of corner cases. [03:38] converting cp+rm to mv *only if the original was deleted within the same commit* is a reasonable behavior, but it's not quite the same thing as the generalization cp+rm=mv. [03:38] changes to both copies could be merged [03:39] creating conflicts if necessary [03:39] whether that's appropriate depends on why you did the copy. If you're copying a template out to create a new file you're going to modify, merging changes from the new versions back to the template is absolutely wrong behavior. [03:40] yes, ok [03:40] so cp+rm might not always be = mv [03:40] so keep cp+rm separate from mv [03:40] anyhow, see the mailing list thread [03:41] how about just having changes to a copied file depend on the copy changeset? [03:43] IMO, cherry picking is a less needed feature than copying [03:50] luke-jr, well, you might ask jelmer how the spec is coming along sometime. [03:52] is there a nice page explaining how to get bzr working with eclipse? [03:52] I have some pug people asking [03:52] and I don't use eclipse [03:55] thumper: open a terminal and Alt-Tab [03:55] (why anyone would use eclipse is beyond me, it sucks) [03:55] * thumper looks strangly at luke-jr [03:55] there's a bzr plugin for Eclipse [03:55] nDuff: yes there is [03:56] nDuff: is it packaged for ubuntu? [03:56] ...though I haven't used it recently; last time I tried, it didn't support linked resources. (They've fixed that since, but not early enough for my purposes) [03:56] is bzr-xmloutput? [03:58] * thumper wishes for bzr-eclipse and bzr-xmloutput to live in the ~bzr PPA === mark1 is now known as markh [07:12] hi all [07:38] ERROR: The user tecan has not registered any SSH keys with Launchpad. [07:38] how do i fix this ? [07:40] login via the web interface and add an ssh key [07:41] where [07:41] i dont see ssh anywhere [07:43] oh o found it [07:48] morning [07:52] morneng === kiko-zzz is now known as kiko [08:34] Where is the keyserver where Launchpad keeps it's PPA signing keys? The latest bzr packages are signed with keys I can't find and apt is refusing to associate with them :-) [08:38] ping vila [08:38] igc: pong [08:38] vila: any thoughts on jam's comments re log --include-merges option naming? [08:39] he voted tweak but I think we should get the name right first [08:39] in particular, how useful would depth control be? [08:39] e.g. .. [08:39] log -n1 => flat [08:39] which thread ? I'm a bit out of loop on log for the last few days :-/ [08:40] log -n0 => fully nested [08:40] * igc looks [08:40] I read that I think, I'd prefer --merge_depth to be: 0: flat, -1 fully nested or something like that [08:40] You mean depth like how many levels deep to show merges? [08:41] i.e. matching our internal merge_depth so that it can be used more broadly [08:41] fullermd: yes [08:41] That strikes me as way too fiddly. It seems like you'd need really contrived cases for a user to actually know what to do with it other than "none" or "all". [08:42] I encounter the use case yesterday in a loom where I wanted mainline but at depth 1 [08:42] vila:https://lists.ubuntu.com/archives/bazaar/2009q1/051802.html [08:43] fullermd: it a shame we don't have optional parameter values to options [08:43] then log --nested could mean all [08:43] and depending on the workflow you use I'm sure there are other such use cases *other* than mainline of full [08:43] s/mainline of full/mainline or full/ [08:43] Well, you could add a --nest-level to supplement it. That's not a major objection. [08:44] and log --nested=2 could mean show just 2 levels (total or beyond the mainline depending on one's thought pattern) [08:44] Yah, but it seems like it would have to be a very specific workflow, AND you'd have to know that it was universally followed. [08:45] igc: Ha ! That thread ! Exactly the one I wanted to comment in priority [08:45] fullermd: with PQM not showing the real author, I think was suggesting looking down just one level would be nice [08:45] IMO, by the time you have the need and environment to be able to do that level of control, you're in a position to also want much more control over the rest of the output too. [08:45] So, first of all, I still think we should refactor log to be able to pass parameters to log formatters *before* adding generic parameters to log [08:46] i.e. not all parameters all relevant for all log formatters [08:47] vila: I'm still not sure about that [08:47] Second: I think there are more ways to select and present the revisions than just mainline and full, in the broader perspective, any sub-graph may be interesting [08:47] vila: I think it ought to be simple for a plugin to define a new LogFormatter like "email" or "xml" [08:47] oops, forget Second for a moment then, let's discuss first first [08:48] and making every log-formatter see most parameters seems to be introducing complexity to the "create a new LogFormatter" process [08:48] IMHO LogFormatter deals mainly with formatting *one* revision and everybody tends to think about them only in that context [08:49] That's no the entire truth [08:49] vila: also, I think the immediate priorities need to be: [08:49] LogFormatter also deals wiht the graph of revisions they are presenting [08:49] * make it fast so people can use it on large projects [08:49] * provide the blatantly missing functionality (like log DIR) [08:50] igc: I understand your priorities, that's one reason I stepped back on refactoring log (the other main one being that I had an already full plate with other issues and my changes to log can stay private for the time being) [08:51] Regarding your priorities, "fast" can be done without refactoring, "DIR" I don't think so [08:51] vila: I'm not rejecting your idea, I just don't want to hold up improvements than are arguably orthogonal [08:52] igc: full agreement [08:52] vila: so returning to my UI question, I think fullermd's suggestion has merit: namely ... [08:52] but I think *some* of them are not that orthogonal :) [08:53] leave the option called --include-merges (and add --nest_level later) [08:53] luke-jr, That's a known bug in that rc, should be fixed in the 0.5 branch [08:54] My main concern is that IMHO we're introducing options that we may deprecate later or force some log formatters to handle things they don't want to care about [08:54] vila: but perhaps the LogFormatter constructor should take a nest_level now. [08:54] understood [08:55] but it's pretty damn easy given depth is a field in every record passed to a LOgFormatter to format [08:55] igc: nest_level to constructor sounds good to me [08:56] checking if n <= m isn't more complex than if prefer_merge_revisions IMO [08:56] Can't the formatters just eat whatever args you give them and only bother looking at the ones they care about? [08:57] It seems insane to have to explicitly add each possible arg, even if they'll never care about it... [08:57] if it's under log formatter control I'm happy enough, it means they can decide to handle the option or not, or even reject the option [08:57] but it implies lots of common filtering code repeated in each log formatter [08:58] fullermd: we are not there yet, but the idea is to pass unprocessed option to log formatter which in turn can pass back unprocessed option for error handling [08:58] rather than a log formatter having a clear responsibility, i.e. "format this record" [08:58] igc: that's why we want a base class with all the utilities ! [08:59] You're back to reducing log formatter to "format this record" that's not their only responsibility IMHO [08:59] it is currently [08:59] they don't really so a graph ... [08:59] no it isn't : look at begin_log end_log [08:59] just a sequence of tuples (including a depth field) [09:00] begin_log and end_log are hooks as I understand them for opening/closing headers/footers, yes? [09:00] of course the LogRevision are called in sequence but that's also a part that could/should go under the lf responsability [09:00] and/or opening/closing resources perhaps [09:01] That's why I say the lf responsability is currently unclear, parts of it being implemented by the log module, I think that's wrong and blurry things [09:02] igc: Have a look at the xnloutput Log Formatter for example [09:03] * igc looks [09:04] It's a lf that consider itself responsible for the whole log display, not only each individual revision display, because it must balance the xml flags for each level [09:04] so it must understand the whole graph (or tree if you prefer) [09:05] You can argue that it could just use depth as an attribute and just format the whole as just a sequence... [09:06] ...but that's not the point I'm trying to make :-) [09:06] right [09:06] so begin_log & end_log put out the and markers [09:06] the rest looks like the usual HTML formatting dance :-) [09:07] i.e. balancing of tags while outputting nested lists [09:08] i.e. taking care of the whole formatting not only of the "format this record" [09:08] that's my point [09:10] end-log do a bit more than just putting out the (not ) marker, there is a stack to purge to [09:10] it's format-this-record-in-the-context-of-what-I've-seen-already and ... [09:10] unwind levels as we step outwards [09:10] you can stop there, you said context [09:11] vila: I guess I'm asking ... [09:11] why would passing more to the log formatter help it? [09:11] we don't pass through end-of-merge for example [09:12] vila: would that make things easier say? [09:12] what is end-of-merge ? [09:13] a True/False field generated by tsort.merge_sort (along with rev-id, depth & revno) [09:13] I suspect having it would help much [09:13] it's not until you see the *next* depth that xmlformat will know the amount of levels to unwind [09:14] s/would/wouldn't/ [09:14] I think that giving more responbilities to lf, will make it easier them to access the data they need instead of relying on the log module to format them in a generic way [09:16] Being able to decide at the lf level what 'revision' parameter is valid or not sounds like a solution to several problems you tried to address recently [09:17] igc: Won't you be happier with get_view_revisions being specific to a log formatter ? [09:18] I'll be happier when get_view_revision goes! [09:18] it's a crap API! [09:18] I think that will make the include_merges parameter useless for example [09:18] igc: great, delegate to lf will make it less crap [09:19] true, but so will fixing it :-) [09:20] the mainline rev, revnos and include_merge parameters are all unnecessary IMO [09:20] Branch.iter_merge_revisions is the way forward I feel [09:21] except for the fact you need them to be reasonably fast, I entirely agree :) [09:21] i.e. they are implementation details [09:22] Branch.iter_merge_revisions ? IS there where you use a reverse parameter ? [09:22] jam wanted a reverse parameter to it and I've submitted a patch along those lines but ... [09:22] I'm not sold yet on reverse being meaningful at that level [09:22] Can we please, please, stop using 'reverse', 'forward' and 'backward' have a meaning by themselves 'reverse'... always makes me wonders [09:23] true [09:23] so currently, reverse in log & missing calls sort_by_depth [09:24] hmm, more than just that I think [09:24] That feels a bit too fancy for Branch.iter_merge_revisions where forward/backwards makes a lot more sense [09:25] off-topic forward without 's' and backwards with 's' always / [09:25] s!/!?! [09:25] lol, perl is noise :) [09:25] no, I meant forward/backward [09:26] ooh, you mean 'reverse' as used at UI level, I was meaning internally also [09:26] vlia: anyhow, I need to have dinner now [09:26] vila:^^ [09:26] Enjoy your dinner :) [09:27] so you're ok with --include-merges at the UI level & preferred_depth at the LogFormatter API level? [09:27] vila:^ [09:28] why preferred instead of just depth ? [09:28] I'm ok for --include-merges [09:28] you're right, just depth is good [09:29] or levels [09:29] Overall: I'm globally ok with your modifications anyway, it's just that I think some of them may be simpler *after* refactoring and some of them may make refactoring *harder* [09:29] But since you'r the one spending the time on it, you get to choose :) [09:29] :-) [09:30] igc: And I'm perfectly fine that [09:30] igc: And I'm perfectly fine with that [09:30] cool - time to go. Thanks for the chat [09:30] You're welcome [09:45] jam: Ha ! Look who is blocking pqm now ! Welcome to the club :-) [09:51] hi guys.. basic usage question, i've a little project on my laptop, i'm concerned for the hardware, how do i clone up to my server for backup? can i just sftp copy the whole versioned directory(working copy i guess) straight up to the server? [09:51] or do i need to use a bzr instruction to do so? [09:52] NET||abuse, either bzr branch whateva on server works, or you can sftp things [09:52] or bzr push from local to server [09:52] hmm, ok [09:52] i'll have a look at it. [09:59] hmm, missing page in the bzr docs,, http://bazaar-vcs.org/Scenarios/NewProject [09:59] NET||abuse, that Scenarios page is new :) [09:59] we're yet to work on it ;) [10:02] so i can push to my server where it has no bzr repo setup, initi'd yet [10:06] herb: It looks like you're the only losa around, can you have a look at PQM please ? [10:06] herb: I meant when you come online... [10:08] hmm, ok so branch from my local to remote doesn't work,, i did bzr branch ./ svn+ssh://me@host/path/to/new/bzr/dir and it throws error "bzr: ERROR: No repository present:" [10:10] What i'm looking to do is move my current standalone branch on my local laptop, up to a dir on my webserver, and then have that act as the main branch for my work, i will be opening it up to someone else next week, so need it up there, and also worried my laptop is about to croak [10:11] it's gotta a discreet nvidia NVS135M card in it, they're known to have issues, this is my 1st replacement from dell, the first one died and 5 engineer visits didn't fix it, so they just gave me whole new model, now last night during 10,000 bc :) the screen glitched like the last one had started to before it died... [10:11] not good. [10:18] I don't think you can branch into SVN... [10:20] I don't even know if branch CAN target somewhere remote. Used to definitely not; can't remember if that was changed or not. [10:20] Generally you just push anyway. [10:28] umm, you see this is why i need to ask,, yeh, svn+ssh,, oops,, i'm not looking to push to svn, was looking to make a new bzr repo... so i just tried bzr ./ bzr+ssh://me@host/path/to/repo/to/create and it didn't like it,, error unkown command 'server' connection closed: please check connectivity and permissions [10:29] unknown command wasn't 'server' just 'serve' still the error stands... [10:30] so last effort,, i just tar.gz up the bzr repo directory,, then upload it. [10:30] extract it on the remote server then try to point my local to it. [10:30] or will they conflict? would i have to re clone/branch from the server back down to my local machine? === asac_ is now known as asac [10:34] Unknown command serve? That sounds like a *REALLY* old bzr on the far side... [10:35] Taring it up should work just fine for backing it up. === awilkins is now known as dr_barnowl [10:39] fullermd: yeh, the far side is the old LTS ubuntu, dapper i think? [10:39] vila: what seems to be the problem? One of your submissions appears to have succeeded about 20 minutes ago? [10:40] spm: thanks for looking in to it, it looked like last *jam* submission was blocking the pqm, mine was just waiting [10:40] spm: things seems fine now [10:40] spm: did you do anything ? [10:41] vila: cool. apart from looking? no. :-) Easiest fix I've done in ages :-) [10:41] spm: pqm is just afraid by you then :) [10:41] heh [10:42] Or may be *I* just misread or read too soon... [10:43] shrug - is no matter. when it gets stuck it's pretty easy to unstick - better to keep things flowing [10:48] fullermd: You can branch into SVN [10:49] fullermd: I had to "svn-versionize" a list of dated archive folders recently, which I did by committing them to bzr branches and pushing them to svn === Pieter_ is now known as Pieter [10:54] Well, I know you can push them in. I mean I don't think you can use _branch_ to do it. [10:54] (actually, I thought you couldn't use push either, and there was some other command to create one ab ovo) [10:57] You have to use bzr svn-push to create a new branch. [11:00] In latest bzr.dev: File "/home/w/bzr/oficial/bzrlib/ui/__init__.py", line 237, in make_ui_for_terminal: UnboundLocalError: local variable 'cls' referenced before assignment [11:19] clemente: thanks, fix is on its way [11:37] hi I'm having real trouble starting the bzr server, it breaks and I get a traceback: http://pastebin.com/m66382410 [11:37] I'm using the standard install for ubuntu 8.10 [11:38] which reports to be bzr 1.6.1 [11:42] thats a bug in bzr-dbus which has been fixed since that release [11:42] either uninstall bzr-dbus, or upgrade it, or have dbus running [11:48] Sounds like a good SRU candidate then. [11:52] hmm, now I'm just getting address already in use, I think that other attempt is still using it [12:02] hello all [12:02] had a question regarding the use of hooks in bazaar [12:06] Im using a shared repository arch [12:06] so basically everyone commits to a singular server [12:07] to send commit notifications out do i have to configure bzr-email on every single desktop? [12:07] configuring on the remote repo in .bzr/branch/branch.conf does not seem to work, configuring locally does [12:13] bzr-email on te server, and push via bzr+ssh should work just fine [12:13] gnight all [12:13] but a bound commit does not [12:14] lifeless, i can try to push and see if that works. But I have the branch bound to the server- a commit does not help [12:14] guess you have gone off to bed :) gnite [12:22] frk2: you could try bzr-hookless-email as a workaround in the mean time [12:22] Jc2k, whats that? === dr_barnowl is now known as awilkins [12:23] frk2: it uses inotify (or just run it very frequently in cron) and looks at what changed and generates emails [12:24] is it part of bzr tools now? [12:24] no [12:24] so get it from lp directly? [12:25] bzr branch lp:bzr-hookless-email [12:25] its not a plugin, so no need to put it in .bazaar/plugins or anything [12:25] i've not used it myself, but i think debian are using it for their commit emails [12:31] Jc2k, got it running- am guessing it uses sendmail or something to actually send the email [12:32] frk2: its based on bzr-email, so imagine its the same kind of thing as that [12:33] lifeless: coupla quick things about stacked branches... --stacked-on=lp:~mordred/wafflegrid/5.1-upstream doesn't work - doesn't recognize lp: syntax ... and also, that fails, so the push aborts, but not before it creates _something_ on launchpad [12:55] I add the bzr PPA and got the latest version, all working fine now [12:56] I was wondering how I require log-in to access the repositories if I'm using bzr serve? it seems like anyone can checkout the code [12:58] nua, you do not, i think [12:58] thats why its read obly [12:58] only [12:58] unless explicitly enabled [12:58] i use bzr+ssh [12:59] ok, so I basically have to use bzr+ssh if I want authentication? [12:59] that's ok, but it means I get really ugly urls [13:00] AFAIK, yes [13:00] would I create an ssh account for each collaborator (I'd rather not) or could I force them to use a single bzr user and authenticate on their ssh keys? [13:07] frk2: what about https? [13:12] nua: You can use http and your http server will take care of auth for you if you configure it [13:13] awilkins: ok thanks, I think I'll give that a go [13:13] nua: ssh also works with a single ssh user as long as you put each users public key on your authorized_keys file [13:14] awilkins: I think http sounds like the most sensible route [13:15] nua: It's very easy for read-only access [13:15] nua: It'll work out of a dumb http server ; write-access takes a little more work [13:15] awilkins: I can run a smart http server by using bzr+http:// right? [13:16] nua: You can _access_ a smart server by specifying bzr+http:// [13:16] nua: To run one you need to configure the server to pass requests to bazaar through WSGI [13:17] awilkins: ok, but I can write to the sever over http/https? [13:17] nua: Yes, as long as the smart server is configured [13:18] Which web server are you using? [13:18] awilkins: I usually use apache or lighttpd... just looking at which to set up now [13:19] awilkins: do you know of any guides on how to set up bzr smart server and http? [13:19] I wrote the page at http://bazaar-vcs.org/ServerGuide/IIS [13:19] I think there are hints for apache in the docus somewhere [13:20] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id80 [13:20] awilkins: yeah, just found that :) [13:21] I had to fix the code to make it work with IIS :-) [13:21] Half IIS's fault though [13:26] haaa, just finish talking with igc, saw lifeless less than an hour ago, now poolie is joining... Did I enter the TZ ? (Twilight Zone :) [13:26] Hi poolie :-) [13:29] hello vila === poolie1 is now known as poolie [13:33] hi poolie [13:33] jam: thanks for the review re the dotted_revno_to_revision_id patch. Much appreciated [13:33] hello igc, you're up late [13:33] i think [13:34] poolie: my hours are all the place right now [13:34] 7am start yesterday, 6am finish, hospital visit in between [13:35] I sleep when I tired currently [13:36] jam: I'd also love a review of the iter_merge_sorted_revision patch if you have time/interest [14:09] poolie: re log --include-merges, I think I'd prefer log --levels N to control how many levels are displayed [14:10] N=0 would be "all of them"; N=1 would be a flat list [14:10] together with a shorthand of -n, I think it would work well ... [14:11] e.g. log -n1 seems better than log --no-include-merges [14:11] likewise log --short -n0 is easier than log --short --include-merges [14:12] also, when logging from a merge revision, it's the number of levels down that matters, not mainline vs merge revision display [14:12] poolie, jam: thoughts? [14:13] fullermd suggested having both --include-merges and nest_levels [14:13] once we have the latter though, the former seem redundant [14:13] I had a conflict in my branch when I merged another branch into it, on a file foo/bar/baz. I've done "bzr rm foo" (it doesn't need to be there any more), but bzr still says the conflict is present [14:14] how do I unconfuse it (and me)? [14:14]