=== ja2 is now known as ja1 === ja1 is now known as jam === wgrant__ is now known as wgrant [03:24] there is connection time out ERROR when I use *bzr push URL* under the proxy [03:24] but I could connect the URL in browser [03:25] I also set the enviroment variable http_proxy correctly, so what is the matter? [03:36] xiaohui: is it an lp: URL? ISTR a bug about the XML-RPC query that does not using the proxy. [03:36] xiaohui: the other common problem is that http_proxy needs to look like "http://host:port/", not just "host:port". [03:38] yeah , the URL is https://code.launchpad.net/~MY_LANUCHPADID/PROJECT/name [03:38] Ah, so two things: [03:39] and I have set the right http_proxy [03:45] spiv: Is there some difference between http and https by using the bzr === ja1 is now known as jam [03:51] Is there a way to perform a command on every file under bzr control, while ignoring files that aren't? [03:53] bzr ls --recursive | xargs command [03:53] xiaohui: sorry, my network dropped out [03:53] spiv, you there? what are the two things you mentioned above? Thank you [03:53] oh, it doesn't matter [03:53] :) [03:54] xiaohui: so, that URL will redirect bzr, the actual URL for writing to the branch is bzr+ssh://~MY_LAUNCHPADID/PROJECT/name [03:54] xiaohui: Er, [03:54] bln ;) [03:54] xiaohui: ... is bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPADID/PROJECT/name I mean :) [03:55] (I can't blame that typo on a network dropout!) [03:55] so, how could I push then? [03:55] The other thing I was going to say is that typically you'd just use lp:~MY_LAUNCHPADID/PROJECT/name as a shorthand for that. [03:56] bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPADID/PROJECT/namebzr push [03:56] Gar, [03:56] bzr push bzr+ssh://bazaar.launchpad.net/~MY_LAUNCHPADID/PROJECT/name [03:57] you mean I should replace the *https * to *bzr+ssh* [03:57] And replace code.launchpad.net with bazaar.launchpad.net [03:57] oh , I will try it [04:01] spiv: I had use the lp:~MY_LAUNCHPADID/PROJECT/name beforre , but it had the same ERROR [04:07] opps, it cannot works [04:07] xiaohui: bzr+ssh needs port 22 open [04:08] how to open the port 22 [04:08] xiaohui: it will depend on your firewall/system administrator [04:09] xiaohui: if you're in an office environment, talk to your system administrator, ask for port 22 opened to 'bazaar.launchpad.net' [04:09] xiaohui: in a home environment it should be a setting on your firewall/modem/router [04:09] mwhudson: bzr+https writing please :) [04:10] thank you lifeless. Another question, how can I completely remove bzr from a directory? I have done bzr remove * to get all files to the unknown state, but I need to remove .bzr from any subdirectories. [04:10] lifeless: how does that work with auth? [04:11] or just find them and delete them manually? [04:11] thank you ,lifeless [04:11] lifeless: [is there a way to specify a high port for a bzr+ssh urlspec if that's the workaround? I would have guessed bzr+ssh://host.example.com:12345/... but presumably if not then .ssh/config is entirely reasonable to use instead] [04:11] distatica: find . -name ".bzr" | xargs :) [04:12] AfC: either should work [04:12] mwhudson: https - certificate, or basic or digest [04:12] mwhudson: apache ends up doing the auth, just like ssh in bzr+ssh [04:12] lifeless: so for launchpad we could tell people to generate a certificate and upload it to their profile? [04:13] lifeless: ok, was wondering if there was a way through bzr. That worked great. thanks again [04:13] distatica: anytime [04:13] mwhudson: we could, but using basic auth (safe over https) and their lp password would be easier [04:13] ah right [04:13] well, "not a 3.0 goal" [04:14] * mwhudson goes back to git imports [04:14] mwhudson: 'stretch goal' :P [04:14] (man I hate that term) [04:14] lifeless: we need stretch goals like we need holes in the head [04:15] mwhudson: they are what let us shit? [04:15] [if you don't eat you dont ...] [04:43] box [04:43] circle [04:44] triangle [04:46] tetracontakaidigon (there, take that) [04:47] [which seems an awful lot of trouble just to say 42-gon] [04:47] lifeless , if I don't use the http_proxy, do I need to use the bzr+ssh? [04:48] xiaohui: if you want to push to launchpad, you need to use bzr+ssh. the 'lp:' short syntax expands to bzr+ssh [04:49] that is a terrible thing [04:49] xiaohui: um, so, do you follow that http:// and bzr:// are different protocols [to accomplish the same goal of transporting (in this case, receiving) revisions]? The "receiving" part is important; you can't use those to push revisions. That's where (for example) bzr+ssh:// comes in. It is the Bazaar network protocol, but tunnelled over SSH (and invoking a bzr --server instance on the far side one-time). [04:50] xiaohui: ssh is very secure, its a standard protocol. [04:50] do you know how to set the proxy for ssh? BTW, I use ccproxy for proxy the http [04:51] xiaohui: you may be able to use socks in your environment. I don't know what ccproxy is [04:51] Afc: yeah I see [04:51] [there are corner case scenarios whereby you can push over HTTP and Bazaar, but both have ... weaknesses ... whereas SSH is the standard for providing secure connections (in practice, actually, it's more used for the authentication and access part) [04:52] whereas (say) raw HTTP PUT and bzr (pushing) would imply that the server end is configured to allow such connections & to do something with them. [04:52] Which would be silly, because then anyone or anything could "push" to your repo. Bad. So {shrug} we ride over ssh, letting that handle the logging in part] [04:54] (which is all bog-standard and widely accepted) [04:55] lifeless: when I use *ssh https://launchpad.net* ,it return 'cannot resove the hostname' [04:55] xiaohui: if you want to test ssh, use something like 'ssh bazaar.launchpad.net' [04:56] lifeless: Oh, I should learn something about ssh [04:57] lifeless: how to use the socks for ssh [04:58] xiaohui: I don't know, I don't have firewalls blocking me [04:58] xiaohui: socks is a way to proxy many things, and *if* your operating system and firewall support it you could use it. [04:58] xiaohui: but that is really up to you [04:59] xiaohui: you haven't told use anything about your environment, so I have to be very vague in trying to help you [04:59] xiaohui: because just about anything could be wrong [05:00] lifeless:I am working on Debian lenny [05:00] xiaohui: ok. And why do you need a proxy? [05:00] and I use an ccproxy as the http proxy server on the WinXP [05:01] ok, ccproxy lists SOCKS as a supported protocol [05:01] lifeless: I am working in an LAN of my school [05:01] lifeless: yeah ,ccproxy support socks proxy [05:02] http://www.debian-administration.org/articles/449 refers to a thing called tsocks [05:02] http://packages.debian.org/lenny/tsocks [05:03] there may be other things that will get your debian machine using socks [05:03] [like I say, I don't have a need to use socks myself, so I don't know what will or won't work for you] [05:04] lifeless: thank you very much [05:04] I will learn something about ssh [05:04] ok [05:04] thanks ,lifeless :) [05:04] we'll be here to offer more guidance once you can get ssh to connect to bazaar.launchpad.net via socks [05:07] lifeless: :) [05:25] lifeless, spiv: streaming pull is totally awesome, thanks guys :) [05:29] mwhudson: :) [05:30] pushing a new stacked branch is still a bit chatty, but i guess you know that [05:31] Yeah, getting slowly better though. === bob2 is now known as Guest37195 [06:01] mwhudson: should be 22 round trips [06:01] mwhudson: if its not, upgrade your server :) [06:01] lifeless: funny you should suggest that... [06:02] mwhudson: did you have thoughts on minilanguage for the server? [06:02] lifeless: not really [06:09] spiv: how are you going [06:09] spiv: haven't heard boo from you this week :( [06:13] lifeless: alright, although I seem to be fighting off headaches a bit more than I'd like [06:13] :( [06:13] you need some fresh air! [06:13] going to the release party tonight? [06:13] lifeless: I have an updated patch for checking for parent inventories. [06:14] I'm very close to a api permitting 'get me a repository ready for making a branch on' [06:14] James Squire, isn't it? Tempting! [06:14] which is about as far as I could push the refactoring without 'big questions' [06:14] Yeah, I can imagine :) [06:15] finding holes in the refactored code [the code is fine, the definition was less so, and as that was just refactored - well you know the mess and cluster of bugs we started with] [06:15] I think it'll be a quiet night and try to get to sleep early for me, though. [06:15] so i'm now tweaking to make the behaviour be something I'm happy with [06:15] I'm not going to the release, slug is frida [06:15] y [06:16] I'm seeing Jerry Springer: The Opera on Friday. [06:16] *blink* [06:17] I had no idea that even existed [06:17] Yeah, that was pretty much my reaction. Then I found it starred David Wenham... [06:18] I vant a vull report [06:18] I'll do my best. [06:38] Jerry Springer: The Opera caused a record number of complaints when it was on the bbc in the uk [06:39] many before it was screened and most from people who hadn't watched it [06:39] not a very pretty sight :( === thekorn_ is now known as thekorn [07:07] spiv: found a stacking upgrade bug [07:08] spiv: may fix bug $whatever [07:10] ok, time to go - ciao! [07:12] lifeless: cool. ciao [07:45] lifeless: heh, "initialize_on_transport_ex" [07:47] better names whileuwait [09:34] lifeless, was about to propose upgrading loggerhead to --dev6-rr, but, bug #365433 [09:34] Launchpad bug 365433 in bzr "Must end write group before releasing write lock on CHKInventoryRepository" [Undecided,New] https://launchpad.net/bugs/365433 [09:35] and hi :) [09:35] You mean upgrading lp:loggerhead? [09:35] Or just a copy of it? [09:36] Peng_, well, it *could* be lp:lh :) [09:36] but that's up for discussion [09:37] mwhudson, Peng_, how would you feel about that ^^ [09:37] assuming it actually worked :) [09:37] How do we feel about upgrading lp:loggerhead? [09:37] we will most likely won't (or shouldn't) do it before bzr 1.14 gets rolled out in Launchpad next week [09:38] Peng_, yes [09:39] Personally, I'm being very conservative about dev6, but that's just my possibly-somewhat-misinformed opinion, and I don't think anyone else should necessarily follow it. [09:40] Peng_, well, we want the format to kick ass [09:40] so we have to test it [09:40] right? [09:40] it's this chicken and egg thing [09:41] With all of the bugs being actively fixed, and the fact that it's a big upgrade with can be wonky about ghosts and stuff, and the discussion about changing how upgrading to rich-roots works, I'm not planning to use it soon. [09:42] OTOH, dogfooding is good, so I'm feeling bad about that. [09:42] heh [09:42] well [09:42] I'm all for testing upgrading different things to dev6rr, but I'm not interested in using it in production. [09:42] It *is* a beta format, yaknow. [09:43] I don't want to do it at the expense of making it more painful to work on LH, so it's either unanimous or no-go [09:43] Well, unless it broke, it wouldn't be very painful. [09:43] Oh, right, the rich-root upgrade. Still, I don't mind that. [09:44] it will mean you need to have it rich-root locally as well [09:44] Yeah. [09:45] But I can always use 1.9-rich-root if I'm afraid of dev6rr. :D [09:45] haha [09:45] true [09:46] Yeah.Like I said, there's that discussion about changing how upgrading to rich-roots works. I don't understand if matters or not, so I'm personally blocking on it until I do. [09:46] Err, s/^Yeah,// [09:46] Backspace fail. [09:46] sure [09:46] to some extent [09:46] upgrading LH was under 2 minutes [09:46] so if the format changes [09:47] it's not really too painful to re-upgrade [09:47] brb [09:53] Take everything I say today with a small grain of salt. I'm feeling extremely apathetic and unmotivated. [09:53] Still, I am interested in testing dev6rr (until the first branch I tried failed, which kind of killed the mood...), but I'm wary of using it in production yet. [09:54] Peng_, sure, we'll come back to it as time goes by [09:54] for starters, I couldn't upgrade locally [09:54] and launchpad doesn't support it yet [09:55] so it's al least a few weeks away [09:55] You couldn't upgrade locally? [09:55] Woah! I just tried upgrading that branch again, and it worked! [09:56] Wasn't there a fix for ghosts, recently? Maybe it was that. [09:57] Peng_, bug #365433 [09:57] Launchpad bug 365433 in bzr "Must end write group before releasing write lock on CHKInventoryRepository" [Undecided,New] https://launchpad.net/bugs/365433 [09:57] beuno: no, let's not make lp:loggerhead a development format [09:58] ok ok, so everyone except me is sane [09:58] grrr, why won't bzr+ssh trigger a bzr-email run! [09:58] * LarstiQ SMASH [09:58] I didn't say *that*. I'm hardly sane, I just happen to disagree with you on this. :D [10:01] Hmm, is it just me, or does dev6rr make check & reconcile much faster? :D [10:03] it should do everything faster :) [10:03] Wuh-ohs, bzr-search doesn't like the branch, though. [10:08] The branch seems to work otherwise, though. :) http://bzr.mattnordhoff.com/loggerhead/pytz/pytz-2008f.dev6rr/ === thekorn_ is now known as thekorn [10:10] Indexing with the Python version of _btree_serializer works. [10:10] spiv: you still awake? [10:12] LarstiQ: yep [10:12] LarstiQ: somewhat distracted by imminent dinner, though :) [10:13] spiv: I'm struggling with the smart server executing my email hook, and you seemed to be clued in bug 211967 ;) [10:13] Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Fix released] https://launchpad.net/bugs/211967 [10:13] spiv: ah, eet smakelijk! :) [10:17] LarstiQ: the things I'd check are a) is the plugin that adds the hook actually getting loaded [10:17] LarstiQ: and b) is that plugin registering a post_change_branch_tip hook? (post_commit won't work for you, for example) [10:18] spiv: right, I'll have to read some code to see what 'post_commit_push_pull' actually does [10:19] Anyone in Oregon? [10:19] * awilkins is going to be in Bend, OR for a week [10:19] LarstiQ: IIRC, the only hooks you can rely on in the server context are {pre,post}_change_branch_tip [10:20] LarstiQ: (and even then only if the client is 1.5+ or so) [10:20] spiv: 1.14rc2+, so that should be fine [10:20] spiv: k, thanks [10:21] LarstiQ: "commit", "push" and "pull" aren't actions that a smart client will trigger on the server, but updating the branch tip is. [10:22] LarstiQ: (Well, unless a post_change_branch_tip has a hook function registered that then does a push!) [10:30] can I use loggerhead to subscribe to changes to a single file? [10:34] jml: Subscribe how? [10:38] If you mean the Atom feed, it seems that you can't. [10:38] Hm, I thought that was possible. [10:39] Oh, cripes. My bzr+http server is running an old copy of bzr.dev thanks to a bug, which means it doesn't know about development6-rich-root. Sigh. [10:39] RSS [10:39] that's what I meant [10:41] (Bug 348308, hinthint. :D ) [10:41] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [Undecided,New] https://launchpad.net/bugs/348308 [10:45] jml: finding changes to a file is moderately expensive [10:46] (and possibly loggerhead goes about it in a fairly daft way) === mthaddon_ is now known as mthaddon [11:06] cd .. [11:07] Sigh... damn focus grabbers [11:12] talden@iron:~/porn$ [11:12] Talden: where are you in nz? [11:13] Hamilton [11:13] * mwhudson is in palmerston north [11:14] Getting cold down there yet? [11:14] night before last was pretty damn cold [11:15] first frost of the year [11:15] We should be due for the regular morning fog - not yet though. [11:20] Peng_: time for me to do something about that bug I gues [11:20] * Peng_ hugs spiv [11:21] Hmm, I can't branch that branch anyway. Something or other in groupcompress dies. [11:21] I can pull, just not branch. :\ [11:34] spiv: it does get loaded, and called, but my section in locations.conf doesn't match [11:36] spiv: ok, solved, thanks :) [11:39] beuno: I am pro dogfooding but: I wouldn't move mainlines to a beta format [11:39] beuno: move to rich root now (see my thread on bazaar@ for details of what is involved - its not a no-brainer) [11:40] lifeless, sure, sounds like a saner upgrade path [11:40] Peng, mwhudson, are you guys ok to moving to 1.9-rich-root? [11:41] beuno: mmmmmmmmmmmmm [11:41] beuno: you need to upgrade all stacked branches before you update the trunk [11:41] argh [11:41] beuno: so it's a bit hostile to our part time contributors [11:41] mwhudson: beuno: you should both read my posts about this on bazaar@ [11:42] mwhudson: has to bbe done sometime [11:42] LarstiQ: oh, right, yes [11:42] LarstiQ: the URLs on the server aren't so helpful... [11:43] ah man, i'm behind on the list again, after having caught up with it on tuesday [11:45] mwhudson: that's ok, I hear that rebase is a fast and drawback-free way to catch up! [11:47] spiv: is that the one where i read the most recent mail and delete the rest? [11:48] mwhudson: not sure, but that doesn't sound like a bad strategy anyway... [12:14] I just tried to do a commit, and forgot that there was a 10GB file in the repo [12:14] when I hit ctrl-C it just hung, so I killed it using kill [12:15] now I'm slightly scared that I could lose a lot of data [12:16] or already have: bzr status hangs and grinds away at my hard drive [12:16] stop, copy the repo if you have enough disk [12:17] does bzr log show that commit? [12:17] no [12:17] *plugs in his external hard drive* [12:20] once it's copied, what should I do? [12:41] bob2: what now? [12:48] alsuren: I would suspect that status is hashing the huge file [12:48] if you "bzr rm --keep huge_file" it might work [12:51] with bzr1.14, replacing a file with a directory does not generate the same (API level) log output whether i remove the file with 'rm' or with 'bzr rm'. is there any reason to this ? [12:51] *removes the lock* [12:51] (and remove with 'rm' crashes with < 1.14) [12:52] pmezard: start by filing a bug [12:52] should it be considered a bug ? [12:52] alsuren: move the file out of the tree, so that bzr *can't* read it [12:52] pmezard: any crash is a bug [12:52] the crash is fixed in 1.14 [12:52] pmezard: ok, kk [12:53] but the fix seems to introduce a different behaviour [12:53] what is different in the api ? [12:53] alsuren: and after moving it, do 'bzr rm --keep path' to tell bzr not to version it [12:54] lifeless: with bzr rm, iter_changes() yields for paths and kind: (None, u'd') (None, 'directory'), then (u'd', None) ('file', None) [12:55] lifeless: and with 'rm': (u'd', u'd') ('file', 'directory') and (None, u'd/a') (None, 'file') [12:55] lifeless: (ah yes, i am also adding a file to the newly created dir in the same commit) [12:56] Hi! I'm again looking at https://bugs.launchpad.net/bzr/+bug/248932 for which I wrote http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/56725 about a week ago, without much of a reply so far. [12:56] Launchpad bug 248932 in bzr "reconfigure --standalone raises IncompatibleRepositories" [High,Confirmed] [12:56] lifeless: to summarize 'bzr rm' yields: remove file, add dir, add file in dir [12:57] lifeless: while 'rm' yield: change file into dir, add file in dir [12:57] not a big deal, just unexpected [12:57] bbl === jelmer is now known as Guest11060 [12:58] pmezard: thats expected [12:58] pmezard: here is why: [12:58] bzr rm removes the fileid - think 'inode' [12:58] rm does't remove the fileid [12:58] jelmer had responded here on IRC while I had been away, pointing out similarity to "bzr upgrade". I'm not sure I agree, so I've got this question for you: Would you expect "bzr reconfigure --standalone" to use current default formats, or rather the format used by the former shared repository? I'd expect the latter, I believe. [12:58] so bzr thinks its the same object changing state [12:59] MvG: I'd expect the latter [13:00] In that case, I think there is not overly much code to be shared between "bzr upgrade" and "bzr reconfigure" I think. [13:02] I'd say, write any code needed, and we can look for similarities and refactor during review [13:02] Am I right that symbols starting in an underscore, like Repository._format, are considered private and should not be accessed outside their class? [13:02] but upgrade is different - it needs to plan an upgrade path rather than just change state/location [13:02] MvG: generally yes. But more specifically read docstrings [13:03] MvG: because python has no 'friends' / 'protected' / 'private' we can't write code 'private to bzrlib' substantially more clearly than 'private to module' or 'private to class' [13:03] MvG: which is why a lot of _FOO's are used from other modules within bzrlib [13:04] the only thing that is definite is that an _FOO should only be used by client code or plugin code if they are willing to track and change their code each time we change it...which we feel free to do on _FOO's. [13:04] The patch at http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/56725 lists which ones I'm actually thinking of. Grepping the corresponding sources for occurrences in docstrings right now... [13:06] MvG: definitely don't add getter/setters for _format [13:06] OK, saves me some work, so I'm glad. :-) [13:06] MvG: a) _format reflects whats on disk, setting it would be semantically odd [13:06] and b) its private-to-bzrlib so its fine for it to be used whereever [13:07] BzrDir._format doesn't reflect what's on disk if there is no repository within the current .bzr dir. [13:07] yes it does, because it reflects the fact that the .bzr dir is e.g. a metadir, or an svn control dir or whatever [13:07] Thus setting that makes sense prior to creation of a non-shared repo. [13:08] Ah yes, sorry, you are right. [13:08] MvG: BzrDir._format.repository_format = foo is what you are doing? [13:08] Right now, yes. [13:08] MvG: you might consider [13:08] And I want to massage that code so far it has a chance to get merged. [13:09] originaldir.open_repository()._format.initialize(new_bzrdir) [13:09] I do have the repo open... initialize on an existing dir should work? Will try that. [13:09] thats the API :) [13:10] as long as the target bzrdir has no repository [13:10] so 'add a repository to this branch which currently shares one' is: [13:10] refs = branch.tags.get_tags.dict.keys() + branch.last_revision_id() === Guest11060 is now known as jelmer [13:10] repo = branch.repository._format.initialize(branch.bzrdir) [13:11] for ref in refs: [13:11] repo.fetch(branch.repository, ref) [13:11] fini === jelmer is now known as Guest88546 [13:11] (and it might be nice to supply an appropriate bit of logic to delete the repository in the event of failure) [13:13] Good point, but not urgent. === elmo is now known as canonical_millba === Guest88546 is now known as jelmer [13:47] Is there something like trac for bazaar instead of svn? [13:48] Trace with the bzr plugin? [13:48] *Trac [13:48] Loggerhead? Launchpad? [13:48] lifeless: ok, got it, thanks [13:50] oh I didn't know there was a bzr plugin. Thanks! [14:01] lifeless: Thanks to your hints I improved my patch: http://rafb.net/p/nTSrQQ25.html [14:01] Do you think this has a chance being merged? Should I submit a merge request? [14:01] awilkins: launchpad doesn't seem to have a wiki engine ... [14:01] (for tickets or wiki pages) [14:03] How would I figure out whether a formerly lightweight repo requiores rich roots when reconfigured to standalone? [14:03] * SamB hasn't used trac with the VCS support, so wouldn't miss anything in using it with bzr even without a bzr plugin ... [14:03] Is there some API to delete a repository inside a .bzr dir, or should I access the file system directly if reconfigure fails to import form the shared repo? [14:04] MvG: lightweight -- I thought that didn't have a repository ? [14:04] SamB: There's a wiki for Launchpad dev at dev.launchpad.net, but I'm not sure what relationship it bears to the actual Launchpad code [14:04] that is, not in it's own directory [14:04] * MvG is waiting for sourceforge to include trac-bzr with their trac setup... [14:05] SamB: That's the reason I wrote "formerly lightweight": It is lightweight, you want to reconfigure it to a standalone branch, so you have to choose a suitable repo format. [14:07] lifeless: Up there you wrote "refs = branch.tags.get_tags.dict.keys() + branch.last_revision_id()" for importing. Why do you need the tags, shouldn't they all be ancestors of the last revision id? [14:16] jelmer: ping [14:17] I'm trying to split off a sub-directory into its own repo, and I'm very confused. [14:17] thumper: pong === canonical_millba is now known as elmo [14:18] jelmer: LP is soon to use bzr 1.14, and I'm wondering which revnos for dulwich and bzr-git we should use for best performance given we aren't using bzr.dev [14:18] what is the proper workflow for bzr split? [14:20] bzr split proj; bzr commmit; ... what do I need to do in order to make proj a nested branch, rather than just an ignored folder? [14:22] thumper: It should be possible to allow bzr-git trunk to be used with bzr 1.14 if we disable some features if bzr doesn't provide them [14:22] thumper: but pull from remote git branches won't be possible with 1.14 [14:23] thumper: (just "fresh" clones) [14:29] Can I get the selftest to keep its temporary files, so that I can have a look at the file system situation where the error occurred? [14:32] thumper: still there? [14:33] MvG: no, they don't have to be [14:33] MvG: lightweight checkout ? - tree.branch.repository ;) [14:33] MvG: I have tosleep, can't chat much mor tonight [14:34] OK... I might get a merge request on the way in the meantime. [14:42] thumper: looks like I was wrong about 1.14, it already has my patch for update_revisions [15:18] jelmer: sorry, dragged into another meeting [15:18] jelmer: I can wait for 1.15 to upgrade bzr-git and dulwich [15:21] jelmer: however I am interested in your suggestions for sizes of git branches that are supportable with bzr-git on 1.14, and 1.15, and future === jelmer is now known as Guest6259 === thunderstruck is now known as gnomefreak === Guest6259 is now known as jelmer [16:15] is brisbane-core in bzr.dev ready for testing? === thekorn_ is now known as thekorn [16:20] max_r: yes [16:20] --development6 [16:29] I've got two merge requests waiting in BB. I'd be happy to answer any questions that arise while I'm here on IRC. [16:32] MvG: feedback/review is generally done over email [16:33] OK. Last time I sent a patch asking for feedback, I got none per mail but some here on IRC, including yours... :-) [16:33] I might have a look at the reconfigure one at some point [16:35] They both concern reconfigure. [16:35] sorry, the incompatible revisions one [16:38] Thanks. That's the more important one for me as well. === abentley1 is now known as abentley [21:41] hello everybody [21:42] i was wondering if bazaar can use some CGI on remote website for a certain repository [21:42] ? [21:42] is something like that done, does anyone know? [22:30] Dejan: to do what? [22:34] bob2 to push/pull [22:34] why do you want to involve a cgi? [22:34] to do writes ovver http without webdav? [22:35] yes [22:35] and quite often people have only one account to access their hosted website [22:36] so they would setup a CGI script there to be used by VCS [22:36] there are some who can use this [22:36] fossil project for an example [22:36] (by Sqlite guys) [22:36] dunno if such a thing exists [22:36] there's less pressure in a dvcs, since you only need one person able to push to that repository [22:38] true [22:38] can i use ftp to push, but users would use http to pull? [22:39] because i do not want to give my ftp access details to anyone [22:39] :D [22:40] Dejan: yes you can push via ftp and pull via http [22:42] jearl, excellent [22:42] ty guys, i will try that [22:42] i appreciate your help [22:42] Dejan: Yes, this makes bzr the easiest (and cheapest) to host of all of the DVCSes. [22:43] jearl, i think this CGI i talked about would make it a #1 choice for some users [22:43]