#bzr 2007-08-28 * Starting logfile irclogs/bzr.log <fabbione> test <fabbione> good :) <lifeless> kthxbye <brmassa> guys, i forgot to redit my personal info when reinstalled my system and now some commits are considered as another person. how can i fix it? <Peng_> brmassa: Uncommit them. <Peng_> Unfortunately. <brmassa> !!! really? <ubotu> Sorry, I don't know anything about really? - try searching on http://bots.ubuntulinux.nl/factoids.cgi <Peng> Haha. Nice, ubotu. <Lo-lan-do> Hi all <Lo-lan-do> I'll paste this http://paste.debian.net/35561 now, in order not to lose the URL for when jelmer comes around. <lifeless> brmassa: yes, we don't support editing commits; doing that essentiall changes data that is meant to be irrevocable. <brmassa> hmmm <brmassa> i was thinking about "merging commiters" or alias... <brmassa> something like this... <Lo-lan-do> lifeless: Irrevocable, but still uncommittable :-) <brmassa> lifeless, i saved my gpg on my pendrive. once i reinstalled my ubuntu, how can i import them back? launchpad keeps complaining.. <fullermd> Well, uncommit doesn't revoke it. It just deports it ;) <lifeless> brmassa: uhh, dunno what you mean <lifeless> mvo: grats <mvo> hey lifeless, thanks <kanhaiya_kk> NamNguyen: Hi <kanhaiya_kk> good morning <NamNguyen> kanhaiya_kk: hello <kanhaiya_kk> Actually , yesterday due to network prob. i cant clear my points <kanhaiya_kk> NamNguyen: i tried this "bzr check http://+1-905-866-7687/~ignu/water" from .17 m/c <kanhaiya_kk> NamNguyen: but how to open that file here ? <NamNguyen> kanhaiya_kk: what file? <kanhaiya_kk> means any file from water dir. ? <NamNguyen> kanhaiya_kk: bzr check is different from bzr checkout <NamNguyen> please try again with bzr checkout <kanhaiya_kk> okay wait <kanhaiya_kk> NamNguyen: yes, now i can edit file.. <NamNguyen> good <kanhaiya_kk> after this i have to do bzr commit and then bzr rspush na ? <kanhaiya_kk> NamNguyen: but then also i have confusion. before i tried bzr branch on .17 machine and now im trying bzr checkout. what is the difference in both commands ? <lifeless> branch makes a new line of developemnt, checkout works on the existing branch like svn or cvs do <NamNguyen> kanhaiya_kk: one follows centralised model, the other (branch) follows decentralised model <kanhaiya_kk> okay..means bzr checkout is right for me. <kanhaiya_kk> good <kanhaiya_kk> but still....one sec <AfC> Unless, of course, you don't have write access to the branch you're checking out, in which case you end up doing decentralized development anyway. <lifeless> NamNguyen: uhm, thats a confusing way to describe it. Because in a cental model using 'branch' is the way to make a new (centralised) branch. <kanhaiya_kk> sorry.....confusion is increasing <NamNguyen> lol <kanhaiya_kk> :( <lifeless> NamNguyen: 'branch' is useful in both centralised and decentralised scenarios. 'checkout' is also useful in both workflows though it is strongly biased towards centralisation. <kanhaiya_kk> after checkout.and after doing editing.when i do commit...it is giving me some errors. <kanhaiya_kk> some write_lock errors. <NamNguyen> lifeless: branch is not necessary after you have a bzr init on the working dir, am i correct? <lifeless> NamNguyen: EPARSE <spiv> kanhaiya_kk: right, HTTP is read-only. <AfC> Yet another one burned by read only checkouts. {sigh} <kanhaiya_kk> so how should i commit changes to my main servere ? <AfC> kanhaiya_kk: if you don't mind being adventurous and learning a few new concepts, <kanhaiya_kk> hmmm <lifeless> kanhaiya_kk: SFTP probably is easiest. <NamNguyen> kanhaiya_kk: use sftp <kanhaiya_kk> im ready for anything...actually, here im learning very new things <lifeless> kanhaiya_kk: use a SFTP URL to your branch. <kanhaiya_kk> means no commit...directly sftp <kanhaiya_kk> ? <NamNguyen> kanhaiya_kk: you tried to use http://192.168.xxx.16/~ignu/water <AfC> kanhaiya_kk: wait a sec - a) is this an existing public project or are you starting fresh, b) do you have ssh access to the server in question <AfC> ? <NamNguyen> now try it with sftp://192.xxx.xxx.16//home/~ignu/water <NamNguyen> erm, i missed a public.html in that URL <lifeless> a better usel might be sftp://192.168.xxx.16/~/public_html/water <AfC> lifeless: sftp assumes ssh privs, right? So why would you not recommend bzr+ssh:// ? <lifeless> AfC: less dependencies. <kanhaiya_kk> NamNguyen: i tried this bzr rspush sftp://+1-905-866-7687/~/public_html/water <kanhaiya_kk> but getting error bzr: ERROR: Invalid rsync path u'sftp://+1-905-866-7687/~/public_html/water/'. <lifeless> AfC: don't need bzr installed on the remote end. This is therefore easier to get started, and bzr+ssh can be added in easily. <fullermd> Well, he's got bzr on the server since he's (or was the other day) update'ing the WT there. <kanhaiya_kk> AfC: yes this is existing project and ssh is also working <lifeless> fullermd: I don't know these thigns :) <AfC> ~ doesn't work over the wire, does it? As I recall, you need to use absolute path names <fullermd> lifeless: Well, you have a life, and don't watch IRC all night ;) <lifeless> AfC: sftp://host/~/foo works. <lifeless> I believe its documented in bzr help <AfC> lifeless: how about that <lifeless> we treat /~/ as 'dont cd at the remote end' <fullermd> Yah. bzr+ssh doesn't interpolate ~'s, but sftp does. * fullermd stabbies bzr+ssh a few times. * AfC finds having sftp actually working a bigger "dependency" than installing bzr on the target server, so has never used it <lifeless> AfC: sftp is on by default if ssh is IME <AfC> Probably just gun shy from the bad old days. Certainly ssh.com's ssh2 didn't have it on by default, and it was a pain in the ass to get working <NamNguyen> kanhaiya_kk: sorry i've never used rspush, my guess is your URL could probably be changed to rsync://... instead of stfp:// if you're going to use rsync? <AfC> Whatever - never would need to use sftp anyway, given the fact that I can invoke the server via ssh <spiv> kanhaiya_kk: why are you using "rspush" instead of "push"? <lifeless> AfC: oh yes well. openssh for th win :) <AfC> lifeless: indeed. <AfC> kanhaiya_kk: any luck writing to an sftp:// URL yet? <NamNguyen> kanhaiya_kk: bzr checkout sftp://192.168.xxx.16/~/public_html/water <AfC> spiv: because he has a certain plugin package installed, which vastly inflates the command namespace, which causes new users to agonize over which command they're supposed to use, which inevitably leads to people not realizing a) what the core commands were and b) that they had all the power needed all along <spiv> AfC: thanks for answering the meta-question ;) <fullermd> Or perhaps because he was pointed at it because of his desire to have an up-to-date WT on the server. <AfC> fullermd: that certainly would be a useful capability. I was quite saddened when I was told by the developer that it would never be included in bzr, even though it seems a natural thing to do automatically and transparently if you already have bzr+ssh as a transport. <Peng> Holy crap. You know that file bzr takes like 35 seconds to diff? Hg takes 8. <poolie> Peng, it would be interesting if you could merge that C patience diff patch recently posted and measure that <Peng_> poolie: Yeah, it would probably help. <Peng_> I have to admit I just Tailored that branch over to hg, and the .bzr repo is on another partition, but I could check it. * Peng_ wanders off. * igc dinner <ubotu> New bug: #135234 in bzr "Checkout should record relative paths (dir move problem)" [Undecided,New] https://launchpad.net/bugs/135234 <glogiotatidis> hello <glogiotatidis> is everyone available to help me with a prob? <glogiotatidis> everyone = anyone ;) <glogiotatidis> I am using bzr push sftp://host/path to push a repo <glogiotatidis> and bzr claims to have commited a branch <glogiotatidis> but only .bzr exists on host/path <glogiotatidis> am i doing something wrong? <fullermd> No, that's what's supposed to happen. <fullermd> (you _are_ pushing a branch, not a repo) <glogiotatidis> but if I bzr push /tmp/site pushes everything <glogiotatidis> when I use sftp acts like this <Kinnison> The sftp transport does not support working trees <Kinnison> where the local file transport does <fullermd> Local pushes will create working trees, because it's reasonable to manage them that way. Remotely, it's not. <Kinnison> so pushing over sftp will not update/create a working tree <glogiotatidis> ok and how can I push a dir remotely? <Kinnison> a dir? <Kinnison> Do you mean with working tree? <glogiotatidis> yes * Kinnison can think of ways to bodge it, but nothing official <Kinnison> You could ssh to the machine afterwards and do a bzr update <fullermd> The nearest official way would just be to use bzr on the server to co/update it, either manually or via a hookish method like push-and-update. <glogiotatidis> hmm I got it <glogiotatidis> what I want to do is to update my website on my hosting provider <glogiotatidis> is there a way you use to do that? (maybe better than this?) <fullermd> Well, my websites get updated via make(1) and install(1)... <fullermd> If you've got shell access and bzr installed there, the above will work. Failing that, rsync is probably your easiest bet. <glogiotatidis> ok I will try this, thanks for your help! <yoavb> hi, I installed bzr v0.15 and am trying to migrate my svn repository to it using svn2bzr.py (v0.6) <AfC> yoavb: step 1: upgrade to bzr >= 0.18. <yoavb> I got deprecation errors and then crashed, should it resolve this? <yoavb> This was the error: ./svn2bzr.py:426: DeprecationWarning: bzrlib.branch.initialize was deprecated in version 0.8. <yoavb> os.makedirs(branch_path) <yoavb> ./svn2bzr.py:91: DeprecationWarning: bzrlib.branch.BzrBranch5.working_tree was deprecated in version 0.8. <yoavb> branch.__wt = branch.working_tree() <yoavb> Traceback (most recent call last): <yoavb> File "./svn2bzr.py", line 575, in ? <yoavb> if __name__ == "__main__": <yoavb> File "./svn2bzr.py", line 568, in main <yoavb> svn2bzr(dump_file, opts.args[1] , creator_class, <yoavb> File "./svn2bzr.py", line 501, in svn2bzr <yoavb> File "./svn2bzr.py", line 362, in run <yoavb> elif node_kind == "dir": <yoavb> File "./svn2bzr.py", line 428, in add_dir <yoavb> self._branches[unpref_path] = branch <yoavb> File "./svn2bzr.py", line 91, in _new_branch <yoavb> branch.__wt = branch.working_tree() <yoavb> File "/usr/lib/python2.4/site-packages/bzrlib/symbol_versioning.py", line 121, in decorated_method <yoavb> return callable(self, *args, **kwargs) <yoavb> File "/usr/lib/python2.4/site-packages/bzrlib/branch.py", line 1486, in working_tree <yoavb> raise NoWorkingTree(self.base) <yoavb> bzrlib.errors.NoWorkingTree: No WorkingTree exists for file:///tmp/repository/butils/. <lifeless> yoavb: please use a paste bin rather than pasting such things in the discussion channel. Also read what AfC said to you. <lifeless> night all <mwhudson> night lifeless <Hattory> hi, I wanted to know as I can contribute to the translation of the Italian homepage: http://bazaar-vcs.org/PaginaIniziale <Hattory> There are some errors <Odd_Bloke> What's the accepted way of sanitising Unicode strings so they can be displayed on an ascii-encoded output? <Hattory> i want to edit the italian homepage.... i can take as reference the English hompage? I can translate all? <AfC> Hattory: (unless the page itself is locked,) the Bazaar website is a wiki so you can just go ahead and edit it <Hattory> it's open ;D....... i look other hompage (fr, ja ecc...) and they have not translate all.... therefore I wanted to know what I could make <Hattory> Therefore I can write every thing? <Lo-lan-do> jelmer: Following your advice, I tried to upgrade my bzr-svn branch, but I ran into problems. <Lo-lan-do> jelmer: http://paste.debian.net/35561 <jelmer> Lo-lan-do: how public is that repository, could I download a copy of it from somewhere? <Lo-lan-do> The SVN repo cannot be accessed anonymously unfortunately, but I can upload my branch somewhere if that helps. <Lo-lan-do> I'll upload a tarball of the branch, with the code and the .bzr dir (but not the .bzr.backup) <Lo-lan-do> Uploading to http://mirobole.placard.fr.eu.org/~roland/tmp/gforge-trunk+bzr.tar.gz -- ETA 15:30 UTC (half an hour, give or take a few minutes) <ssh_rdp> Hi, Is the bazaar encrypted branch (SoC2007 Project) usable now? <bigon> hi <bigon> I have a question, is it possible to add a post-commit hook on a remote branche? <jelmer> Lo-lan-do: thanks <Lo-lan-do> jelmer: Upload complete. Beware, it's 119 MB. <ollie> stupid question maybe, but should applying a v0.9 bundle on win32 using 0.18 work? <ollie> doing "bzr merge foo.bundle" results in: "Nothing to do" <ollie> searching for "bundle" in the bug tracker didn't result in any hits that looked promising <jelmer> ollie: Means all revisions have already been merged <ollie> jelmer: I don't see them in the log <jelmer> hmm, not sure then <jelmer> what does 'bzr missing path-to-bundle' output ? <ollie> bzr: ERROR: Not a branch C:/.../file.bundle/ (from "bzr missing file.bundle") <dato> ollie: do you mean a 0.9 or 0.90 bundle? <hsn_> ah, bzr still at rc1 <ollie> dato: # Bazaar revision bundle v0.9 <dato> okay <ubotu> New bug: #135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New] https://launchpad.net/bugs/135320 <Lo-lan-do> Hey, whacky idea: is there a bzr-baz plugin in the works? :-) <jelmer> Lo-lan-do: there was a spec for it at some point <jelmer> but I don't think there is anybody working on it <james_w> abentley: thanks. <ollie> can anyone suggest a way to test if a bundle is ok? I've got a bundle generated on windows that I've tried to merge on both windows and os x; using 0.18 on windows and bzr.dev on os x; both tell me there's nothing to do <james_w> ollie: how did you generate the bundle, i.e. what command and arguments did you use? <ollie> james_w: I didn't -- a submitter sent it to me <ollie> as it turns out, after a couple hours of head-banging, I noticed my editor say its encoding is x-UTF-16LE-BOM <ollie> which seems to be the issue <ollie> since saving as utf-8 at least tells me line endings aren't \n <ollie> "nothing to do" isn't the greatest error message, though <james_w> there is a hidden command called 'bundle-info', try running that and seeing if it reports that there are actually revisions in it. <ollie> on os x, using bzr.dev I get told it's an unsupported bundle version <ollie> though, when I try to merge it, I get told it won't because of a missing revision (locally) <ollie> on windows, using 0.18 (from the installer), it says there's no such command <james_w> so you now have a different response on osx? <ollie> sorry, I thought I'd said I was using bzr.dev on os x and 0.18 on win32 <ollie> trying to indicate it's not working anywhere (for me) <james_w> if you read the bundle and find the revision id of the final revision then you can see if it has been installed in your repository by running bzr log -r revid:<revid> in the branch that you are trying to merge in to. <james_w> you said "both tell me there's nothing to do", but a missing revision is not "nothing to do" <ollie> yes, I did say that -- I've fed 3 bundles into 2 different versions of bzr <ollie> 1: x-UTF-16LE-BOM encoding; 2: saved as utf-8; 3: line-endings converted from \r\n -> \n <ollie> w/1: "nothing to do"; w/2: wrong line ending; w/3: can't apply because revision is missing <ollie> sorry if I sound short -- I'm frustrated and I don't think there's anything that can be done to actually apply this bundle <ollie> anyway, thanks for trying to help, james_w <james_w> no problem. <james_w> if you just want to apply then patch will do so. <james_w> 3 sounds like you have been sent on a bundle that is based on a revision that only you user has. <james_w> if you look at the parent id of the last revision in the bundle it should be one of your revisions if you want to apply it using bzr. <ollie> james_w, yeah, it just took a lot of doing to get that far -- and I was surprised that rather than be told the input was bad, bzr said "nothing to do"; also, it's a bit surprising that "bzr merge bundle" says it can't because of the missing parent, but bundle-info says the bundle version isn't supported <ollie> I mean, if merge can figure out it can't apply the bundle -- surely there's some level of support there ;-) <james_w> bundle-info was broken for a while because it is hidden command, and only Aaron used it. <ollie> ah, ok <james_w> I think that you are getting "nothing to do" because the bundle parser skips stuff that it doesn't understand, and you ended up with nothing, and so got "nothing to do" <james_w> would you like to file a bug explaining the issues you are having, and telling us how the output could have been more helpful? <ollie> skips stuff it doesn't understand is pretty crummy <james_w> I guess bundle with no revisions should get and extra message, "nothing to do, empty or corrupt bundle?" <bwinton> So, XML is pretty crummy too? :) <ollie> sure, i'll file a bug; I mean from a expectation point of view, if it doesn't like it, it should say so -- not just pretend it doesn't exist ;-) <james_w> it's just working how patch does, so that you can for instance merge from an email without having to extract the right bits. <siretart> hi EtienneG. <EtienneG> siretart ! <EtienneG> how ya doin' ? <siretart> how are you? <siretart> :) <siretart> thanks fine! <EtienneG> I am not so bad <siretart> are you working on getting bzr 0.90 to gutsy? <siretart> I've notice that it is in debian for some time <lifeless> mroning <lifeless> james_w: have you had someone do the release stuff you need done ? <james_w> morning lifeless. <james_w> Aaron merged everything, I'm building the release now, so I will need someone to upload, will you be available? <lifeless> james_w: sure thing <james_w> lifeless: http://jameswestby.net/bzr/bzr-0.90.tar.gz <james_w> and http://jameswestby.net/bzr/bzr-0.90.tar.gz.sig please <lifeless> on it <lifeless> james_w: done <james_w> lifeless: thanks. * ..[topic/#bzr:james_w] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz * ..[topic/#bzr:james_w] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz | Complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d * ..[topic/#bzr:james_w] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d <james_w> lifeless: there is an item on the checklist to update doc.bazaar-vcs.org. I guess that may be important here with Ian's docs in directories change going in. Are you able to do it or should I ask someone else? <lifeless> Uhm, I'm not sure where it is; poolie is most knowledgable <james_w> thanks, I'll speak to him. <abentley> ollie: When you give merge a URL, it tries to open it as a bundle. If that fails, it tries to open it as a branch. Evidently your bundle was in a branch that you were up-to-date with. #bzr 2007-08-29 <abentley> It doesn't say "nothing to do" if it can't find anything mergeable. <lifeless> abentley: perhaps it could say '%URL is already fully merged.' <abentley> Sure. <lifeless> good morning btw <ollie> abently, no, it was a bundle it couldn't read; when I opened the bundle in my editor and resaved it as utf-8, I progressed to being told it didn't have \n line-endings; when I changed it to line endings, I was told a parent revision was missing <ollie> or maybe I'm misunderstand, but based on the progression, that wasn't the scenario <cprov> lifeless: ping <lifeless> pong <cprov> lifeless: I'm running bzr-pqm from gutsy and getting this error: <cprov> BzrBadParameterUnicode: Parameter content is unicode but only byte-strings are permitted. <cprov> bzr 0.18.0 on python 2.5.1.final.0 (linux2) <cprov> arguments: ['/usr/bin/bzr', 'pqm-submit', '-m', '[r=kiko] Fix #134345 (ppa-tos page), #135186 (ppa page typo), #135385 (configuration files fixes for ppa) and fix poppy to store upload with g+w permission.'] <lifeless> cprov: 'bzr plugins' -> pastebin <cprov> lifeless: have you seen it before ? how can I workaround it ? <lifeless> run the one from lpdebs probably <cprov> lifeless: https://pastebin.canonical.com/53/ <cprov> lifeless: right, I have missing upgrades from lpdebs. I hope they will fix the problem. (sorry, I should have checked before). Thanks <RainCT> hi <RainCT> I just started pushing something to a new branch in Launchpad but then I realized that I forgot to commit and aborted it (Ctrl + C). Now I get bzr: ERROR: File exists: u'/~rainct/freevial/testing/.bzr': mkdir failed: unable to mkdir each time I try to push it again, and on Launchpad on the branch's page it says Launchpad could not mirror this branch 41 seconds ago. The error was: Not a branch:. I've tried with --use-exist <lifeless> RainCT: you disturbed it during the initial setup <lifeless> RainCT: better to let it finish, then commit, then push again to add the additional data :) <lifeless> anyhow, this should fix it <lifeless> python <lifeless> >>> import bzrlib.bzrdir <lifeless> >>> d = bzrlib.bzrdir.BzrDir.open('sftp://bazaar.launchpad.net/~rainct/freevial/testing') <lifeless> >>> d.create_branch() <abentley> ollie: So you are saying the directory your bundle was in was not a branch? <abentley> And not inside a branch? <RainCT> lifeless: the "d = ..." says bzrlib.errors.NotBranchError: Not a branch: <cprov> lifeless: just for the record, bzr-pqm (0.13~20070226-0ubuntu2) from lpdebs is working correctly. <ollie> abentley, sorry, I guess I misunderstood. the current working directory from which I tried to merge a bundle created by someone else one a separate machine was itself a branch. <abentley> When you got "Nothing to do", it's because it was merging that branch. <ollie> ok, because it failed to read the bundle <abentley> Right. <abentley> lifeless makes a good point that it should be clearer about what it's merging. <ollie> it would have been uber-helpful if it had stated that it was unable to make any sense of what I gave it <abentley> On http, that would mean no branches would ever work. <abentley> Not to say we can't do better, of course. <ollie> not being burdened by any implemenation details, it seems completely counterintuitive to pass something to merge and be told there's nothing to do (when you're looking at the bundle in your editor and can see that there is stuff) <abentley> Well, that can also happen with bundles you've already merged, so the "editor" test isn't very conclusive. <igc> morning <lifeless> RainCT: ok <lifeless> RainCT: you need to login via lftp or sftp and delete everything in that dir <lifeless> RainCT: then you can replace the d = line with <lifeless> d = bzrlib.bzrdir.BzrDir.create('sftp....') <lifeless> and do d.create_repository <lifeless> d.create_branch() <lifeless> - first one should have been do d.create_repository() <abentley> igc: morning <igc> morning abentley <igc> morning lifeless <ollie> abentley, no, I understand that, but I'm not speaking the abstract -- I'm talking about a scenario where the code didn't exist in the target repo and the conversation (between bzr and I) consisted of my saying "merge it" and it saying "you're good to go!" <RainCT> lifeless: and how can I connect to it? (does LP even allow it?) <ollie> anyhow, I don't mean to beat a dead horse ;-) <lifeless> RainCT: 'sftp bazaar.launchpad.net' <lifeless> RainCT: or lftp sftp://bazaar.launchpad.net <abentley> lifeless: You wrote the hooks stuff, right? <lifeless> yah <abentley> I'm not finding a lot of documentation on how it's supposed to be used. <abentley> Add an entry to the Branch dict? <abentley> via a plugin? <lifeless> abentley: you want a plugin to add a new hook type, or to hook into one of the hooks ? <abentley> Hook into one of the hooks. (post-push). <lifeless> Branch.hooks.install_hook() <lifeless> plus <lifeless> e.g. <lifeless> Branch.hooks.install_hook('post-push', hook_function) <lifeless> and to name it, which is a UI convenience <RainCT> lifeless: ok. deleted it, and python continued saying it isn't a branch, but it seems now I can push to it. Thanks :D <lifeless> Branch.hooks.name_hook(hook_function, 'my-do-x') <lifeless> RainCT: cool <lifeless> abentley: these are on the base clsas of BranchHooks <abentley> So you install it and then name it? <lifeless> yeah <lifeless> naming is optional <abentley> Does it predate registries? <lifeless> its just so that when pb's are showing hooks running, that slow hooks are shown as english rather than as the object's __str__ <abentley> Sure. <lifeless> abentley: No, it didn't seem like a good fit <lifeless> I guess each hook e.g. 'post-push' could be considered a registry <abentley> Yeah. I guess I see why you did it that way. <abentley> if you were doing it in one fell swoop, it would be something like Branch.hooks.register_hook('post_push', my_push_hook, "My push hook") <lifeless> yeah. install_hook could sanely take a text_name=None parameter to allow that <lifeless> the name_hook method came a release after hooks were added <abentley> Ah. <lifeless> so I added a separate method so that plugins can do <lifeless> if get_attr(Branch.hooks, 'name_hook', None): Branch.hooks.name_hook(...) <abentley> yeah, that's a bit of a lack in python's introspection. <lifeless> you can get at the signature I believe, but its just not as easy or quick <lifeless> you need the introspect module which has heinous dependencies IIRC <abentley> Hmm. <abentley> When you say Graph.heads should not be on a single-key graph layered on a multi-key graph, why do you say that for heads specifically? <lifeless> Well heads was under discussion <lifeless> but more generally part of the work to tune packs is going to be ensure we don't spend a chunk of time just tupling and detupling things <abentley> Do you think the same thing for find_unique_lca? <lifeless> so the low level key for the revisions GraphIndex is (revision_id, ) <lifeless> and the Graph object is key agnostic from what I recall - or nearly so. <lifeless> that is, it really works on key_type:[key_type ...] - <lifeless> so just passing in the right key type should allow everything to fit together nicely <abentley> Okay. <lifeless> on text indices the low level key is (file_id, revision_id) <lifeless> so theres more work involved in converting every get_parent request from get_parents(revision_id) - it goes to iter_entries([(file_id, revision_id)] ) and then that gets stripped on return to give a node with parents as (revision_id,), and finally that is restored to just revision_id at the top level adapter <abentley> Graph isn't the One True implementation of its interface. There's no need to assume such translation. <lifeless> I realise that; what John was proposing had that translation. <lifeless> my reply to him was pointing out that we should avoid it, in however he structured his api. <abentley> I would really like to have Graph.heads for use in reconcile, which is why I ask. <lifeless> definately use it <abentley> And it seems like the only code you actually have a problem with is "g = graph.Graph(entry_vf)" <lifeless> reconcile is repository format specific <lifeless> so theres no impact on packs by using it like that <lifeless> bbiab, grabbing breakfast <abentley> lifeless: Would a VersionedFile.get_graph() method satisfy you? Then different VersionedFile implementations can specify their Graph implementation. <sandrot> is there a changelog available for .90 : <sandrot> ? <abentley> sandrot: There is the NEWS file. <sandrot> k so I have to branch <sandrot> or get tar <sandrot> 'pulling' from another person means that the person I'm pulling from needs to have his branch accessible to me via ssh on his own box or via a server he can 'push' or upload to right? <abentley> pulling works on any of the protocols we support: http, sftp, ftp, bzr, bzr+ssh or local files. <lifeless> abentley: the problem is the keys that should be returned <lifeless> abentley: in many respects I want to stop using VersionedFile where dataset partitioning isn't helpful <sandrot> Mmm, thanks. I was just thinking that because I keep myself behind a firewall (blocking ssh) in order to have someone pull to me I have to make my branch available to my server which accepts ssh (or other protocols), meaning that in order for me to share my branch I need to push first <abentley> lifeless: Surely untupling in VersionedFileGraph.heads isn't expensive. <lifeless> abentley: if it occurs only at the interface surface it isn't a problem <lifeless> occuring all the way down is a problem <abentley> Right. <abentley> So doing vf.get_graph() would allow us to avoid doing it all the way down. <lifeless> ok <lifeless> I guess my hesitation is trying to avoid the vf interface except where it clearly makes sense. Which is probably over-exaggerated at the moment. So vf.get_graph sounds fine. <lifeless> Hmm, I think what I want to achieve is decoupling 'file history' vs 'text construction'. <lifeless> file history queries tend to be one off operations, not part of large things like 'branch' 'checkout' etc <abentley> That's fair. <lifeless> text construction tends to be part of things like merge, and thats where the artificial VF interface causes roundtrips. <lifeless> text insertion likewise, though we can queue that to avoid round trips more effectively <bartt> Are nested repositories working? <bartt> I don't seem to be able to add a nested repository. <bartt> E.g. bzr add path/to/nested/repository only reports # of ignored files <abentley> lifeless: You are the person who wants to select graph ancestors on a per-file basis, though. <abentley> bartt: You cannot add a tree into another tree. <lifeless> abentley: I don't think I'm the *only* person :). <abentley> Yes, but surely doing VersionedFileGraph.find_unique_lca is the obvious approach. <lifeless> abentley: per file lookups can be grouped though <lifeless> thats the obvious approach, and as long as the repo its being queried on is local it will perform fine <abentley> And at present, the repo being queried is always local. <bartt> abentley: I thought that nested tree support was added in 0.15? <igc> So more reviews today from me starting with abentley's TreeTransform rollback one <abentley> bartt: No, only support code. It is not complete. <igc> abentley: were you planning to tweak anything following Kuno's feedback or should I review it as is? <bartt> Thanks abentley <abentley> igc: The only thing is that I should handle errors creating the pending-deletion directory the same way as errors creating limbo are handled. <igc> abentley: I was hoping you'd say that <igc> I'll go ahead and review and ask for that tweak <abentley> Okay. <sandrot> What exactly does a repo with or without "trees" mean? what exactly is a tree? <abentley> Thanks. <lifeless> igc: I'm going to profile commit performance with packs today. <sandrot> erm, what is a tree in the context of a shared repo <igc> lifeless: great. I'll push my latest code this morning in case it's of interest <lifeless> igc: I'm focused on repository interactions immediately. <igc> np <lifeless> I want to see how slow the repo layer is <lifeless> or has to be <lifeless> igc: also, how should we collaborate; I'm working in packs; I can spin off patches for bzr.dev easily. <lifeless> but not for your branch as easily <lifeless> my patches should be small but frequeny. Does this work for you ? <igc> lifeless: I'm still a few days away from using the commit-candidates branch effectively ... <lifeless> righto <poolie> abentley, what igc said about the merge queue goes for me to <igc> I need to get commit changed to incremental vs 'build from scratch' first <poolie> too <abentley> poolie: Glad to hear it. I think we have the right intentions, it's just a juggling act. <igc> so lifeless, if you can keep pushing hard on packs and getting bzr.dev closer to using them, I'm good with that <sandrot> what does a 'tree' mean in the context of a shared repo...what happends to branches in a repo when I run init-repo --trees versus init-repo --no-trees ? <abentley> sandrot: A tree is the directory (and subdirectories) that contain your source code in editable form. See bzr help working-trees. <sandrot> abentley: thanks, I'm just finding it now actually <sandrot> I read a lot of shared repo docs but didn't read http://people.ubuntu.com/~ianc/doc/en/user-reference/bzr_man.html#repositories yet <sandrot> seems that a working tree is similar to svn's working copy <abentley> The big difference is that SVN's working copy is never in the same location as a branch or a repository. In Bazaar, the SVN layout is called a 'checkout'. <abentley> A lightweight checkout, to be precise. <sandrot> Mmm, I always assumed the working copy was the copy of code you're currently working on. So when I checkout a branch my checkout is now a 'working copy' <abentley> In SVN, that's the only way of getting a working copy. But with Bazaar, "branch", "init" and "push" can also create objects with working trees. <sandrot> push doesn't create a working tree thought right? you can checkout or branch from a pushed location <abentley> When you push to a local location, it creates a working tree, and yes, you can checkout or branch from a pushed location. <abentley> Push always creates a branch, and on local locations, it also creates a working tree. <abentley> creates *or updates* I should say. <ubotu> New bug: #135421 in bzr "different exit code for internal errors" [Wishlist,Triaged] https://launchpad.net/bugs/135421 <abentley> igc: Shouldn't NEWS.html be up somewhere on doc.bazaar-vcs.org? <igc> yes <igc> abentley: it looks like doc.bazaar-vcs.org is yet to be upgraded following the 0.90 release ... <igc> poolie has done this in the past for the RM <igc> I'm pretty sure I have permissions now so I can do it I think <abentley> Do we even have a link to NEWS in the documents? I tried a few guesses at the URL... <abentley> but it was 404 city, baby. <igc> see http://people.ubuntu.com/~ianc/doc/ for what 0.90 will look like ... <igc> clicking on "Release Notes" takes you to NEWS.html <abentley> Beauty. <abentley> We gotta turn that TOC into a sidebar or something. <abentley> Any progress with getting the pretty version of the docs online? <igc> abentley: see http://people.ubuntu.com/~ianc/pretty_docs/ for the current pretty-docs output as well <igc> by 'current', I mean a snapshot from a week or so back of course <abentley> Sure. * netjoined: irc.freenode.net -> kubrick.freenode.net <lifeless> spiv: ping - calls? <lifeless> poolie_: I see 3 failures <lifeless> and one of those is due to the failure to isolate CFLAGS * igc lunch <poolie_> lifeless, only 3? <poolie_> hm <poolie_> have you pushed to your knits branch recently? <poolie_> because that's where i pulled from <lifeless> poolie_: its one commit behind <poolie_> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ right? <lifeless> http://people.ubuntu.com/~robertc/baz2.0/repository is the canonical location <poolie_> lifeless, i'll check that one then <lifeless> one thing that concerns me ian, for commit performance <lifeless> is that we're three times slower than hg, but I'm seeing our gzip time as dominating <lifeless> at 80% of profiled time <abentley> lifeless: Potentially, you want to store uncompressed knit records, and then gzip the whole container. <abentley> Maybe faster, probably better compression. <lifeless> abentley: I'd love to know precisely what git's packing algorithm is <lifeless> I think I'm saying 'there is something wrong' when hg's commit is faster and our time is in gzip <lifeless> not that I disagree with your point <poolie_> lifeless, ok, in that branch i have only 2 failures <tonyyarusso> Hi, I'm not familiar with version control systems at all (yet), and I was wondering if someone could either explain or give a link to a good explanation of how bazaar compares to things like SVN, CVS, and git. <jeremyb> istr that bzr's wiki has a really good explanation <jeremyb> i think wikipedia has something too <jeremyb> +comparison for both <jeremyb> http://bazaar-vcs.org/SCMComparisons <jeremyb> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software <jeremyb> http://better-scm.berlios.de/ <tonyyarusso> jeremyb: Cool, thanks <abentley> tonyyarusso, jeremyb: The better-scm site is pretty useless. I would avoid it. <jeremyb> hah * jeremyb is reading http://better-scm.berlios.de/to-avoid/ <jeremyb> not that i would ever consider using MS Visual SourceSafe anyway <abentley> I was unable to convince the author that baz and bazaar are difference VCSes. <jeremyb> heh <abentley> So Bazaar is listed under "Arch", completely inappropriately. <jeremyb> yeah, i see it doesn't have it's own listing in the sidebar <jeremyb> never heard of vesta before <jeremyb> "Note: related to Bazaar, is Bazaar-NG, which is written from scratch by the same parent company. It aims to offer some advantages over Bazaar, but is not an Arch implementation, nor is it compatible with Bazaar. A tool is available to convert Bazaar repositories into Bazaar-NG, but not the other way around. <tonyyarusso> Looks like git is sort of specialized and limited-use, CVS is becoming obsolete, and if I was going to learn something it should be Bazaar, Subversion, or both. Does that sound accurate? <jeremyb> "CVS is becoming obsolete" yes from some perspectives :) <tonyyarusso> Well, it lacks a number of features listed for other ones, and others (like Subversion) are listed as improvements on it. <jeremyb> git, bazaar, *and* mercurial not or :) <tonyyarusso> I know O'Reilly has a Subversion book - is there a comprehensive guide for Bazaar yet? <jeremyb> tonyyarusso: oh, sorry i misread. i thought that abentley provided the quote in jest. i will provide a better answer :) <jeremyb> CVS is becoming obsolete by most standards although is occasianally used for new projects and has some diehard fans <fullermd> CVS is long since obsolete. What it is, is _known_. People have decades of history in it, and know it inside and out. That's worth something. <jeremyb> right <jeremyb> i wouldn't say git is specialized or limited use but it does have quirks and it's got some small hurdles for windows users. git and mercurial both have support for syncing with svn. git has more mature biderectional support. bzr has not quite stable support for writes to svn last i heard and i think the read support is better. afaik mercurial doesn't have any <abentley> I was not joking. He cannot get his facts straight. If you read that site, you will know less about version control than you did beforehand. <jeremyb> abentley: i thought that tonyyarusso's line quoting the site was you talking <jeremyb> superficially bzr, hg, and git all implement the same principles but there are variations * jeremyb tries to remember the good (or at least i remember people saying it was good) bzr/hg blog post <jeremyb> abentley: well both his bazaar and bazaar-ng links redirect to bazaar-vcs.org so it shouldn't be too hard to convince him that they are the same. but convincing him that he used the wrong link might be a challenge <jeremyb> abentley: how recently did you try to convince him? the arch page has an almost 2 year old timestamp <abentley> I've got no interest in trying to convince him any further. He's demonstrated that he will just ignore inconvenient facts. He's not worth thinking about. <jeremyb> hah, that site has an empty irc channel <jeremyb> abentley: i was just wondering * jeremyb ponders <jeremyb> i was sure CVS allowed copies retaining history for the original and the new file. (people file bugs to get those copies done for the mozilla repo all the time) his comparison says CVS doesn't support them... <mdmkolbe> I enjoy learning new systems and I've just come off of learning and using darcs at an intermship. I've learned to like the distributed model (I'm a former svn user), and am looking for a system to use on my own projects. (I'll have compile and install at as a non-root accout.) I'm consiering mercurial, bzr and git. Can anyone point to or give a good comparisen of these? <jeremyb> they all can be installed in your home dir * jeremyb wonders what's happening with forest (or was that hg?) <jeremyb> mdmkolbe: what OS? <mdmkolbe> jeremyb: both linux (as non-root) and windows/cygwin (but I administer that system so root isn't such an issue) <jeremyb> hrmm <jeremyb> git isn't supported as well on windows but i've never tried it (i think there's some performance issues too but neither of those are based on recent data) <jeremyb> mdmkolbe: depends how much time you have. personally i'd just try them all <jeremyb> on a small scale not for a real project <jeremyb> (i have used git and mercurial a bit not so much bzr) <mdmkolbe> jeremyb: I'm a motivated learner except that school has started and my brain is filling up to the point where I'm discovering the need to choose what I will and won't learn (which is sad, but I guess it's part of getting older.) <AfC> mdmkolbe: my personal response to your question about which version control system to use is in http://research.operationaldynamics.com/blogs/andrew/software/version-control/git-is-like-cvs.html <jeremyb> whoa, git is like cvs? <fullermd> jeremyb: CVS doesn't. Manual mucking around in the repository does. Sorta. * jeremyb reads <jeremyb> fullermd? <jeremyb> doesn't what? ohh, moves? <fullermd> Yah. <lifeless> fullermd: well it can record moves as well as git can <fullermd> Harsh. * lifeless is both trolling and completely serious, simultaneously * jeremyb understands <lifeless> food time <jeremyb> fullermd: well, for mozilla, it's automated to the point where you hand a script a text file with source and destination on a single line seperated by a space and it takes care of everything * mdmkolbe puts one more stroke in the tally for bzr after reading <fullermd> Yeah, but what it takes care of is still a mess. And CVS doesn't know anything about it. You just sorta have the history of the file available. <mdmkolbe> What repository format does bzr use? (I ask b/c of the claims in http://keithp.com/blog/Repository_Formats_Matter.html) <AfC> mdmkolbe: a constantly improving one <AfC> mdmkolbe: And I disagree with Keith (who is, incidentally, a good friend of mine); tool usability is what matters. <AfC> mdmkolbe: and despite the rather appealing-at-first-glance notions inside Git, I have LOST DATA with Git and NEVER LOST DATA with Bazaar. <mdmkolbe> to summarize the linked article "git is good b/c each file is writting once then never touched again; hg is bad b/c it appends to the files on each commit" <mdmkolbe> AfC: heh, that kind of puts Keith's claims in perspective <AfC> mdmkolbe: we've all read it. Most of the people here are _also_ good friends with Keith. <fullermd> I'm not. I'm a poor pathetic outsider, clutching at windowsills and begging for scraps of bread. * AfC goes out for coffee * fullermd hits up AfC for spare change on the way. <mdmkolbe> How well does bzr support "software archiology"? One of the troubles with darcs I found was that of trying to track down the historical context of a change (that introduced a bug I'm attempting to fix) that isn't always captured by the patch dependancy graph. <jeremyb> hg has a built in function to do a binary search for the bug <jeremyb> i don't remember who else has what <mdmkolbe> jeremyb: ?! <jeremyb> all have pretty good history viewing tools <jeremyb> mdmkolbe: ? <jeremyb> mdmkolbe: you know what a binary search is, right? <mdmkolbe> jeremyb: yes, but that's not something I expected from a VC system. You just point it at 'make' and your program and ask it to recompile until the search find the change causing the bug? <jeremyb> i've never used it * jeremyb looks <jeremyb> http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension <mdmkolbe> jeremyb: thx for the link <jeremyb> sure <fullermd> darcs is a special case there, since it doesn't do historical context... <jeremyb> darcs drives me nuts!!! <fullermd> I always say, why drive when it's close enough to walk ;) * jeremyb thinks... * jeremyb knows he's missing something... <jeremyb> who's brian o'sullivan? <jeremyb> something wrong with his repo <jeremyb> or at least the web frontend <jeremyb> http://hg.serpentine.com/mercurial/hg/book/book/convert/book/book/book/book/book/book/book/ <fullermd> /bork/bork/bork? <igc> mdmkolbe: if you haven't seen them already, http://bazaar-vcs.org/BzrWhy lists several blog posts explaining why Bazaar is better than most alternatives (in our opinion) <jeremyb> oh, ooops <jeremyb> brian o'sullivan and that repo are both hg <abentley> Nice guy, though. Wish he were on our team. <poolie_> mdmkolbe, there is a bazaar bisect extension which might be more to the point <poolie_> there is also iirc 'darcs trackdown' which i think was the first system to have it <lifeless> poolie_: there was an IBM paper on this at LCA 2004 <lifeless> describing the technique for tracking down gcc regressions automatically <poolie_> based on cvs <lifeless> yes <poolie_> ok, so darcs may have been the first to generalize and automate it <poolie_> or maybe not <poolie_> lifeless, btw where you wishing for a different behaviour in vim ^O? <poolie_> maybe that was someone else? <lifeless> dunno <poolie_> anyhow, g; takes you to the place you last changed the text <lifeless> yup * fullermd didn't know that. <fullermd> I usually fake it with undo. <jeremyb> heh * jeremyb has done the faking as well <jeremyb> any of ya'll actually work for canonical? <jeremyb> who's mccormickit.com? <mdmkolbe> where is the repo for bzr? is there a web front-end? (I mean the repo for the source to bzr) <jeremyb> yes <mdmkolbe> I couldn't find it from the bzr website (maybe I'm just looking in the wrong place) * jeremyb is finding it <jeremyb> http://bazaar-vcs.org/bzr/ * jeremyb looks some more <jeremyb> having trouble finding a frontend hosted by the main project but i see 2 front ends for the main repo <jeremyb> http://codebrowse.launchpad.net/~bzr/bzr/trunk <jeremyb> http://goffredo-baroncelli.homelinux.net/bazaar/bazaar-NG-dev * jeremyb remembers a better frontend for git, bzr or hg but is having trouble finding it <lifeless> jeremyb: yes, some of us work for canonical * jeremyb runs across https://blueprints.launchpad.net/bzr/+spec/ignore-versioned-files <lifeless> https://code.launchpad.net/~bzr/bzr/trunk is the launchpad mirror of bzr.dev <lifeless> http://codebrowse.launchpad.net/~bzr/bzr/trunk <lifeless> is a web ui to browse it <thumper> does bzr diff require a checkout? <jeremyb> haha <jeremyb> thumper: you already have a copy locally. <thumper> jeremyb: no, I don't <thumper> I have a branch <thumper> perhaps I should have said WorkingTree <thumper> lifeless: how come I can't do "bzr diff -r-3..-1" on a branch without a working tree? <spiv> thumper: https://bugs.launchpad.net/bzr/+bug/6700 <ubotu> Launchpad bug 6700 in bzr "bzr diff -r 10..20 http://foo" unsupported" [High,Confirmed] <thumper> spiv: so a working tree is needed? <thumper> arse <lifeless_> 15:20 < lifeless> thumper: patches gratefully arsed <lifeless_> 15:21 < lifeless> igc: ^ remember this bug ? :) <lifeless_> 15:22 < lifeless> ok, thats 9ish hours, I'm calling it a day. <lifeless_> 15:22 < lifeless> igc: poolie and I think a gzipless repo might be an interesting test, so I'm going to overhaul the knitversionedfile code some more tomorrow <igc> lifeless: yes, haven't forgotten it :-) <thumper> lifeless: :) unfortunately I have other priorities right now <igc> lifeless: yes, an interesting test indeed <igc> thumper: FWIW, lifeless gave me that bug on my first amy08@example.org. :-( It's still on my list but behind performance work <thumper> igc: as long as it isn't forgotten :) <igc> thumper: no risk of that :-) <mdmkolbe> thx all for your help <AfC> Eeek. What does "Not running as bzrlib.plugins.gtk, things may break." mean? <AfC> [bzr 0.90.0, bzr-gtk 0.90.0] <AfC> ... and indeed, `bzr viz` crashes. <dato> AfC: that the bzr-gtk plugin is not installed in a directory named just "gtk" <AfC> Yes it is... er, no its not. Typo on my part. Shit. <AfC> Called it "bzr" not "gtk". That was stupid... <AfC> (in ~/.bazaar/plugins) <AfC> dato: thanks <dato> np <tolonuga> can anyone edit http://doc.bazaar-vcs.org/bzr.dev/server.htm and replace ":1234" with ":4155"? thanks. <jeremyb> tolonuga: looks like it's generated from this file: http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20070825182243-a3w20rpadbfz8euc?file_id=server.txt-20060913044801-h939fvbwzz39gf7g-1 <jeremyb> tolonuga: so, anyone that can checkin there... <tolonuga> ok, thanks. unfortunatly I can't checkin, I'm only a stupid user looking at docs and finding tiny issues. will open a bug if noone responds here, so the issue is not forgotten. <mwhudson> tolonuga: you could send a bundle to the mailing list, that's the usual way for things like this * igc dinner <tolonuga> how can I create a mail in bundle format from a local commit? preferable something I can cut&paste into my mail app - I don't want bzr to send email itself. <fullermd> bundle will spit out a bundle on stdout; you can redirect that into a file, then attach it. <tolonuga> ah, thanks! <markvandenborre> I'm looking into using bzr to manage a few django (web framework) projects I am working on together with a friend <markvandenborre> I would regularly be working offline (on the train) <igc> night all <markvandenborre> up-to-date code would be needed on each of our machines, plus an external webserver <Odd_Bloke> igc: Night! Thanks for the merges. :) <markvandenborre> what kind of workflow would you recommend? <Odd_Bloke> markvandenborre: You could just use a centralised workflow, because you can commit locally when working offline... <markvandenborre> ok, will be investigating that path <markvandenborre> Odd_Bloke, thx a lot! <Odd_Bloke> markvandenborre: That's not necessarily the only/best one to use though. <Odd_Bloke> But it would work. <markvandenborre> Odd_Bloke, I figured I would really need a feature like local commits because of my long train commutes <markvandenborre> Odd_Bloke, you think that would be the easiest way to get started with bzr? <Odd_Bloke> markvandenborre: If it makes sense in your situation, then do it. :p <markvandenborre> :) <markvandenborre> is it bad policy to setup a central repository for web projects on a production webserver? <markvandenborre> it's not a leaky php server, and only running sshd and apache, but still... <markvandenborre> I can imagine it's not a good thing to have both on the same server, even if it's very well managed <markvandenborre> any thoughts? <markvandenborre> would it be better to put the bzr repository on a physically separate machine? <dato> lifeless: I'm uploading 0.90-1 to debian. I guess some ubuntu person will have to make sure it makes through UVF. <fullermd> markvandenborre: That sounds like a site policy question. bzr certainly wouldn't care. It's not hard to move stuff around later if you change your mind... <markvandenborre> fullermd, yes, it is a site policy question... trying to be careful about setting things up with minimal overhead, but still safe <markvandenborre> fullermd, your remark about easy of moving is definitely interesting! <markvandenborre> thx! <fullermd> As a handwavy position statement, I tend to think that if a server gets cracked, the VCS history is probably one of the least interesting things on it... <markvandenborre> you're probably right about that <fullermd> (situations change cases, of course, but as a general rule) <fullermd> I'm all about putting all your eggs in one basket, and watching that basket like a hawk ;) <markvandenborre> now on a machine without php, with only 80 and 22 open, that might be a sound policy <markvandenborre> you're probably right that I'm too paranoid <fullermd> On the flip side, if there's no particular reason
{'channel': 'bzr', 'month': 8}