#bzr 2007-12-01 <jelmer> schierbeck: yes, though I can try to change that <schierbeck> that would be great -- i have a one-line patch that fixes a crasher in the mainline version of the viz <schierbeck> i'm not sure if it needs to go through the review process -- even if it doesn't, i'm not able to push <jelmer> schierbeck: ok, it's now at ~bzr-gtk/bzr-gtk/trunk <schierbeck> wow, that was fast <schierbeck> do you think i should push the revision? <schierbeck> it's just removing an import of a now nonexisting file <jelmer> yeah, sounds good to push without review <jelmer> so now the main branch is at ~bzr-gtk/bzr-gtk/trunk you could start pushing your own approved revs :-) <schierbeck> nice :) <Peng> What order are the sections ("BUG FIXES", "IMPROVEMENTS", etc.) in NEWS in? <Odd_Bloke> Peng: I'd suggest looking at NEWS to find out. :p <GuyIncognito> Newbie question: I'm working on a project with the "Decentralized with shared mainline" workflow. I want to "fork" the project into two different development efforts. I guess this would be "making a new revision"? But what is going to happen when people start pushing their changes back to the mainline from the two different branches? Is there a best practises for this, or am I going about it the wrong way? <GuyIncognito> * sorry I meant to say "This would be 'making a new branch'?" <Odd_Bloke> GuyIncognito: What you would do is 'branch' the shared mainline into a separate branch. You would then 'merge' changes from that branch back into the mainline. <GuyIncognito> Old_Bloke: OK. What happens if several people want to work on the new branch? <Peng> Odd_Bloke: Seems to be arbitrary. <fullermd> GuyIncognito: You can have multiple shared branches, instead of just one. Just set up the second similar to the first. <Odd_Bloke> GuyIncognito: Well, any given branch can be treated as centralised. That is to say you could branch 'mainline' to 'feature-1' and then have people use 'feature-1' using any of the listed workflows. * Peng adds a reference to the bzr branch to the trivial bug he's been working on. :O <Peng> I feel kinda bad about polluting the big important list of branches with something trivial. <Peng> But it also has taken a few commits and continued to be modified, at least a little. <GuyIncognito> fullermd, Odd_Bloke: Thanks! <Odd_Bloke> GuyIncognito: No worries. :) <JordanC> Hyello <JordanC> Does anyone else have problems with Launchpad & olive? <JordanC> I try to grab from there or push and I get "unexpected response" <abentley> The location for bzr-gtk has just moved to ~bzr-gtk/bzr-gtk/trunk <JordanC> ? <abentley> ? <JordanC> Were you talking to me? <abentley> Yes. I thought that might be relevant to you. <JordanC> Hmm <JordanC> Still wondering why no SVN on launchpad :P <abentley> Still wondering why no SVN on list of "once-popular products that no one's using" <JordanC> ...no-one's using SVN? <abentley> No one should be. <JordanC> (I know of at least 30 off the top of my head) <JordanC> Well, i've had nothing but problems with bazaar -_- <abentley> I'm sorry to hear that. <fullermd> It probably saw svn installed on the system and got huffy. <abentley> So what protocol are you using to retrieve bzr-gtk? <JordanC> I'm trying to use olive at the mo <abentley> Same source tree. <JordanC> Can i get bzr-gtk via yum <abentley> No idea. The Bazaar project has debs, but I don't think any rpms. <JordanC> Yeah, I have it <JordanC> But there's no GUI <JordanC> It's just tools <JordanC> And I'm using KDE :P <JordanC> bzr-gtk is a plugin for Bazaar that aims to provide GTK+ interfaces to most Bazaar operations. <fullermd> Can probably do a quick grep through yum list (or is it yum search? I can't remember) to see if it's in its standard repo. <abentley> The Bazaar project has debs FOR BZR-GTK, but I don't think any rpms. <JordanC> Well, no app is shown <JordanC> lessee <abentley> I know what bzr-gtk is. I am one of the contributors. <fullermd> If it's not in the 'official' yum db, I haven't heard of anywhere else offering RPMs (which doesn't mean much since I don't track that, but...) <JordanC> Oh dude <fullermd> If it's not there, it's probably easiest (for experimenting, anyway) to just grab a copy manually and stick it in your personal plugins dir. <JordanC> Now I have to install nautilus <JordanC> No way am I using bazaar <JordanC> :X <fullermd> You don't have to for bzr-gtk itself; some package may be listed with it. I sure don't have nautilus around. <abentley> Nautilus is not a hard dependency of bzr-gtk. <JordanC> Man, good <JordanC> Cause it's nowhere near as good as Konqi :/ <JordanC> Anyhow <fullermd> Is that some new-fangled version of 'ls'? ;p <JordanC> What is just, the long and short of it -- how do I make it easier just to commit without having to fanny around? :P <JordanC> It's getting annoying when there's GUI's that don't work and bazaar is similar to arch <abentley> I'm not sure what you mean about guis that don't work. <JordanC> Olive doesn't work <fullermd> That's a bit off my turf. I always just use the CLI; only thing I generally use -gtk for is an occasional viz. <JordanC> Won't let me commit, won't let me pull <JordanC> Can't connect to servers <abentley> Well, commit works for me. <JordanC> Using olive? <JordanC> Okay, well if this is the case maybe I'm not getting the connection URL's correct <fullermd> You'd probably have to be a little more specific about what you're trying to commit/pull and what servers :p <JordanC> What's the actual URL you need to specify <JordanC> My project on launchpad is photoncrm <JordanC> And the advised path is ~jordancdarwin/photoncrm/modules/ <abentley> JordanC: yes, using olive. <Odd_Bloke> So 'bzr+ssh://williamsmith@example.net/~jordancdarwin/photoncrm/modules/' for pushing. <Odd_Bloke> JordanC: ^ <fullermd> For writing it, I think it would be something like bzr+... what Odd_Bloke said. <JordanC> Still <JordanC> When I use that, I get "Cannot read response from server" <JordanC> And for pulling? <fullermd> Mmm. I get a bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~jordancdarwin/photoncrm/modules/" when I try branching it. <JordanC> bzr push bzr+ssh://williamsmith@example.net/~jordancdarwin/photoncrm/modules <JordanC> That's what I get given <JordanC> Haha <JordanC> Yeah, it just crashed <abentley> Well, it looks like there really is no branch there. <JordanC> " This branch has not been published yet." <fullermd> So LP has the branch listed, but not really there. I don't know LP well enough to know how you do that, or fix it. <fullermd> I've never created a LP branch except by pushing it. <JordanC> Why is it that after some errors, GTK will actually not allow me to click buttons, but use the keyboard instead? Argh, frustrating <JordanC> Hmm <JordanC> Unsupported protocol for url "bzr push bzr+ssh://williamsmith@example.net/~jordancdarwin/photoncrm/modules" <JordanC> Everything is fine <JordanC> Hang on <JordanC> Why is it pasting that <JordanC> Okay, here we are <JordanC> Unknown error <JordanC> end of file reading from server. <JordanC> :) <abentley> The bzr+ssh protocol has poor diagnostics. <abentley> Try using sftp instead. <JordanC> In olive? <abentley> Sure. <JordanC> Same error <abentley> Just switch sft for bzr+ssh in the URL. <JordanC> Yeah, I know how to do it ;-) <abentley> Sorry "sftp". <abentley> Okay, can you log into launchpad? <JordanC> Already done <abentley> e.g. using an sftp client? <JordanC> Yes <JordanC> Works fine <abentley> And you're using the same user-id? <JordanC> yup <abentley> Sound like you need to talk to someone in #launchpad, then. <bialix> jam: ping <gdoubleu> I can't remember, bzr branch lp:/// support is in bzr proper correct? Not bzrtools? <fullermd> gdoubleu: Technically, I think it's in the launchpad plugin, but that's shipped with bzr. <imbrandon> anyone got any clues on this error ( trying to use bzr-svn ) <imbrandon> http://paste.ubuntu.com/2392/ <imbrandon> *hopes some is awake at this hour* <AfC> imbrandon: Upgrade to >= 0.92 and try again <AfC> imbrandon: (1.0rc1 would be better) <imbrandon> AfC: ok , is it in hardy or do i need to compile <imbrandon> i'm running gutsy with all -backports/-updates <AfC> imbrandon: I haven't the faintest idea what a gutsy, hardy, or whingy are, but if you look on the Bazaar website you'll find that they have an apt repo that Debian derived distributions can use. <imbrandon> AfC: rockin ok, ( fwiw they are the ubuntu codenames ) <imbrandon> gutys being the latest stable , anyhow thanks, i'll try that <imbrandon> gutsy* * AfC is heaping scorn on the idea a) of codenames, and b) that Debian and Ubuntu people seem to expect that anyone else would have the faintest fucking clue what the hell they are talking about <imbrandon> no i dident *expect* you to know, sorry for the assumtion, bzr being another canonical project i assumed the right hand would know about the left hand, but assuming makes an ass+u+me , wont happen again <AfC> Anyway, 0.93 ^W 1.0rc1 is just out, and you'll probably do well to give it a try as it's 3-4 months (and 3-4 releases) newer than what you were using. The Bazaar hackers continue to move at an astonishing rate and problems encountered in a version that's that old are likely long since resolved. <imbrandon> k <JordanC> Hey dudes <JordanC> :) <imbrandon> ello JordanC <dato> siretart: so, as a person who's fought with Recommends... ;) what's your opinion on having bzr recommend: bzrtools, and suggest: bzr-gtk, bzr-svn <dato> siretart: I think bzrtools is on the verge of not being appropriate for recommends, but only on the verge :) <siretart> dato: I would argue this way: <siretart> dato: would you expect a typical bzr user to also install bzrtools? <siretart> if yes -> recommends, if no ->suggest <siretart> (I'd vote in favor of it) <dato> yeah, me too. I think it'd be useful for it to be available by default. <dato> I'm also revamping the description. <siretart> great, thanks <dato> jam, vila: I would also like to know whether you think python-pycurl should still be pulled by default when installing bzr (in Debian, and possibly in ubuntu), or it's better to leave it out now. <dato> siretart: do you have any idea why on earth we Suggest: libxml2-utils? <siretart> dato: no idea. maybe lifeless knows? <dato> maybe. the changelog is not helping. <james_w> /usr/bin/xmllint, /usr/bin/xmlcatalog <james_w> I'm not sure what either of those would be for. <james_w> hi all btw. <dato> hi james_w <dato> oh, no jelmer <dato> siretart: http://dpaste.com/26427/ <james_w> dato: conclicts <james_w> "yet able to adapt to many workflows, reliable, and easily extendable." is a little uncomfortable, I would suggest dropping the "yet". <dato> james_w, thanks, fixed (both). <james_w> dato: it's good, thanks for doing it. <vila> "no special software the server is needed" ? "no special software is needed on the server" <dato> the intention was "no special software *in* the server is needed" <vila> regarding pycurl, there are two http implementations in bzr: one based on pycurl, the other on urllib <dato> yes <vila> if pycrul is the default if present <dato> yeah, I know. <vila> the major difference is that pycurl verifies ssl certificates <dato> the question was, whether to make installing bzr in a system also pull pycurl in <dato> iow, what do you feel that would be a better default: pycurl available or not <james_w> dato: I would think available. <vila> dato: I'm a bit biased since I rewrote most of the urllib ;) <james_w> also looking again I think vila's "no special software is needed on the server" is better. <dato> ok, done <vila> frankly I don't know if pycurl should be pulled or not. When people want certificate verification pycurl is mandatory (today), if they don't want certificate verification pycurl should be avoided (by forcing the use of urllib) <james_w> of course the best solution would be to get vila enough spare time to add certificate validation to urllib. <dato> vila: avoided? <vila> james_w: ;-) <james_w> yeah, pycurl wont let you access a site with a self-signed certificate for instance, so you have to force urllib to access it. <vila> dato: no hhtps connection can be issued if certificate verification fails (included self-signed certificates) <vila> and also if your installation is screwed or the site use an unknown CA <vila> since urllib makes no verification... it's usable. *And* I will provide the necessary hooks to allow urllib to cope with the situations above <dato> so, maybe not pull pycurl, and leave a note in README.Debian on when it could be useful? <dato> maybe downgrade it to suggests <dato> ah, I meant to mention in the description what paramiko is useful for <vila> you stop doing that ? <vila> put it back and add an equivalent section for pycurl maybe ? <dato> stop doing what? there was never any place in the debian packagin explaining what was paramiko needed for <vila> s/if your installation is screwed/& regarding the certificates/ <vila> I heard at least two reports (or three) where the ca-certificates package were not installed even when pycurl was (or liburl, or curl, whatever ;) <vila> s/liburl/libcurl/ <vila> err, waitaminute, james_w, *you* had a case where ca-certificates not installed no > <vila> s/>/?/ <james_w> vila: yeah, I've tried to see why, but I'm couldn't see it. <vila> dato: sry, misunderstood you, I thought you said you *was* doing, I think it will be a good idead to do so. <vila> james_w: I think I sent you an email afterwards with some hints (after looking a bit myself) <vila> Subject: ca-certificates as a bzr dependency <vila> To: James Westby <williamsmith@example.net> <vila> Date: Wed, 21 Nov 2007 12:01:48 +0100 <james_w> vila: yeah, thanks. <vila> AAARGH silly posting addresses here :-( <vila> so sorry :( <dato> is paramiko needed to push over bzr+ssh? <james_w> vila: no problem, there are plenty of other places to harvest it. <james_w> and the '+' is a good anti-spam device anyway. <vila> really ? I was wondering about that cause my spam level have never been too high and I tend to always use + addresses <vila> dato: checking... <vila> dato: yes it is <dato> thanks <dato> bbiab <dato> (maybe it'd should be a dependency then) <dato> bbiab <james_w> vila: my MTA's logs show loads of rejects to williamsmith@example.net, which I think is a great help. <vila> amazing... I thought there were clever enough to include + as a valid component... or may be the clever ones think that people using + are naturally anti-spam ;-) <vila> regarding urllib's certificate verification, I have a branch whith an https test server using the ssl module provided by python2.6 (after dirty port of bzr to python2.6) <vila> this branch is on the back burner for now because that module is currently under work in 2.6, 3k and as a package for py2.3->2.5, so it's bit hard to find the right version ;-) <vila> 2.6, 3k and the package being at different levels last time I checked... <james_w> vila: apparently 0% of my current spam folder (1700 messages) is to that address, > 90% of ham is to that address. <james_w> do other countries have the real SPAM, i.e. the meat product? <vila> Not that I know of ;-) <james_w> ah, you're missing out. <abentley> vila: What's it used or? The ssh connection can be through openssh, and the protocol is our own. <vila> abentley: try: <vila> from bzrlib.transport import ssh <vila> except errors.ParamikoNotPresent: <vila> # no paramiko. SmartSSHClientMedium will break. <vila> pass <vila> in smart/medium.py <vila> ? <abentley> Perhaps it's used for something, but I would have thought not. <vila> me too, that's why I checked, I'm as surprised as you, may well be a bug <abentley> I guess we'll just have to harass spiv. <vila> spiv: ^ <ubotu> New bug: #173274 in bzr "Allow pre-export hooks" [Undecided,New] https://launchpad.net/bugs/173274 <jelmer> abentley: your announcement of bzrtools 1.0 doesn't mention switch being merged into core. Did it make it into 1.0rc1? <abentley> Actually, I did mention switch. <abentley> Oh, drat. <abentley> I meant "switch", not "shelf". <abentley> Okay, I've fired off a correction. <jelmer> ah, that explains it :-) <Peng> Huh. Now that I'm using bzr.dev, I don't want to bother installing 1.0rc1. <abentley> Yeah, I'm chronic that way. <abentley> I did have to revert to 1.0rc1 temporarily, to make sure bzrtools 1.0.0 works with it. <abentley> Which you can do with "bzr revert -r branch:http://bazaar-vcs.org/bzr/bzr.1.0/" <Peng> What the hell is wrong with Firefox? It refuses to download GPG signatures. /me wgets the bzrtools .sig file. <jelmer> so why's bzr.dev still claiming it's 0.93 ? shouldn't that be 1.0.1 ? <Peng> NEWS was updated but I guess nobody got around to updating the version number. <Peng> And now they're off for the weekend? <Peng> Going from an installed copy of 0.92 to 1.0rc1 is a 291 KB pack. :) <Peng> Hm, it's not possible to branch a dirstate branch into an (empty) pack repo? <Peng> Oh, never mind. <Peng> dirstate-with-subtree. <Peng> Yes, "KnitRepository" is super-useful information. <Peng> jelmer or something: Who runs doc.bazaar-vcs.org? The docs need to be updated. 1.0rc1 links to packrepo.html but it's still a 404. <james_w> Peng: I think one of poolie, jam or lifeless should be able to update it. <Peng> Okay. <Peng> jam or lifeless or someone: http://doc.bazaar-vcs.org/latest/developers/ needs to be rebuilt. 1.0rc1's "help formats" links to packrepo.html, but it's still knitpack.html on the server. It would also be nice if there was a 301 redirect from knitpack.html to packrepo.html. <Peng> Am I still connected? <dato> jelmer: re REJECT, possibly the XS-* field has to be installed in the archive, not only in incoming, for it to work; so try again tomorrow <james_w> Peng: no :) <Peng> That was weird. <Peng> I lost my connection to the Internet, but the DSL light on the modem was still on. Then while I'm reconnecting to all the IRC networks, the last one, Freenode, recovers. <Peng> Weird. <Nafallo> not really... <Peng> Yes it is. <Nafallo> why? <Peng> How can I get disconnected without either the modem or computer being aware of it? <Nafallo> did you get a new IP? <Nafallo> ah <Peng> Nafallo: Nope. But since my account was shuffled around, I've stopped getting new IPs anyway. <Peng> (The one time it's gone down since it was shuffled, anyway.) <Nafallo> well, your PPPoE can disco without line-sync go down, and your computer is only aware of connectivity to the modem. <Nafallo> as far as freenode go, you never reached the TCP timeout. <Peng> Not PPPoE anymore. "ENET ENCAP". <Peng> My hostname changed from saying "dyn" to "dhcp" and now I get crappier IPs. <Nafallo> nice :-) <Peng> I got a new modem too, because apparently mine should've burned out years ago. I'm still using the old one because I don't want the (minor) downtime. I was just about to switch it out before the connection started working again. <Peng> Anyway, back on topic. Not like anything's happening... <dato> jelmer: ping <sommer> hello, I checked out the ubuntu-hardy docs branch from LP... I then changed my "name" and "Display Name" in LP and I can no longer commit <sommer> I think the local version is still using the old name <sommer> is there a way to change that without re-downloading? <lifeless> Peng: which branch? the one took to hg? basically I'd like to know how we compare <lifeless> Peng: are we still so slow you would have moved? <Peng> lifeless: Can you rebuild the docs? Or poke someone who can? <lifeless> I'll see what I can do <Peng> Thanks. <james_w> sommer: you probably want to use 'bzr bind' with your new username in the URL. <sommer> james_w: ah... I'll try that <Peng> Let's see how long it takes to extract a 1.3 GB .tar. <lifeless> Peng: obviously for these tests I want you to upgrade the branch to packs <Peng> 1 minute and 3 seconds! <sommer> james_w: genius that worked. Thank you very much <Peng> Hmm. I had like 8 copies of the data, and removed all of it except for 1 copy (well, there are still 2 copies of the bzr repo), and it looks like I took the copy I was experimenting with with it. <Peng> What makes something a shared repo vs. a non-shared repo? The presence of a branch in the same dir? <lifeless> .bzr/repository/shared-storage <Peng> Ah. <Peng> Bah, should've just checked. <Peng> Now, let's see how long it takes to convert to packs. <Peng> (even worse, pull into a new branch, building a new working tree) <Peng> Think I have time to brush my teeth? <Peng> Well, let's see if I can brush my teeth in time, then! <Peng> BRB. <Peng> Hmm. It might work well to use git for ~/local instead of bzr. Since it doesn't track renames, I don't have to try to. <Peng> Wait, I do like being able to do renames, though. <lifeless> rofl <Peng> I like being able to do renames when I want to, but I don't want to have to think about them when I don't. <lifeless> commit --automatic is what you want <lifeless> as we delete automatically today <lifeless> you can do: <lifeless> bzr add; bzr commit; <lifeless> and you'll get a new snapshot <lifeless> no thought. <Peng> Oh, gosh. It only took 9 minutes. <Peng> Now, why am I swapping so badly? <Peng> Better now. I guess bzr had just used a lot of RAM. <Peng> lifeless: Wow. 17 seconds user time. Slightly higher sys than with hg, I think. :P <Peng> lifeless: Now, it's gotten larger since this old copy was made, so it would be slower (no idea how much), but if bzr was this fast in August, I never would've switched to hg. * Peng wanders off. Star Trek. <lifeless> Peng: cool <lifeless> Peng: btw, histor shouldn'y slow it down noticably for commits anymore, only total count of files/size of changed files. <Peng> lifeless: Cool! <Peng> lifeless: Same with hg. <Peng> Meh. The problem with me is also that the files I'm committing keep getting larger, so even if history doesn't slow it down, the diffs will. * Peng wanders off. <dato> jelmer: btw, you were the second approver of my small patch to NEWS, maybe you could merge it? http://bundlebuggy.aaronbentley.com/request/<20071129185051.GA12330%40chistera.yi.org> <abentley> lifeless: ping #bzr 2007-12-02 <lifeless> abentley: pon <abentley> So I started hacking on per-file base selection yesterday, and I found a locality-of-reference problem. <lifeless> ok <abentley> The file content is stored in the versionedfile. The file type is stored in the inventory. <abentley> So to do it absolutely correctly, I'd have to retrieve all the trees for the selected revisions. <abentley> Because the selected revision may not be a file-- it may be a directory, symlink or tree reference. <lifeless> ok <lifeless> I see <lifeless> now, if the kind is the same on both tips <lifeless> does that make it easier ? <abentley> In fact, we're already assuming it's a file on both tips. Otherwise, we wouldn't need a williamsmith@example.net. <lifeless> so if its the same on both tips <lifeless> 3-way merge says that if the base is a different kind <lifeless> -> we'd treat is as empty of the same kind ? <abentley> Not quite. We'd still emit foo.BASE in the correct kind. But wrt the file merge, yes. <lifeless> now symlinks and dirs have an existing empty text for their revisions <abentley> AFAIK, correct. <abentley> So we can shortcut the kind check 99% of the time. <lifeless> so; and I realise this is hacky; <lifeless> if doing a 3-way custom base on two currently-file-texts, w.get_lines(custom_base) will give us [] when the kind has changed. <abentley> I hate to have it shortcutted 99% of the time, though. It makes me fear the full path won't get adequately tested. <lifeless> are you doing custom bases for symlinks and dirs too? <abentley> No. Those will get handled by the standard merger, which also handles inventory issues such as renames and executability. <abentley> I don't think those things change enough to require the same care as text files. <lifeless> so I guess I'm saying; if we're only doing custom base on (text, text) pairs; and get_lines(custom_base) will always return a suitable set of lines, ([] when the common base has a different kind), then its not a shutcut situation <abentley> By shortcut, I mean that we're avoiding retrieving the file kind from the relevant inventory. <abentley> But in the case where it's [], we will have to do so. <lifeless> I don't see that we ever need the file kind for the base if the parents are both texts; other than to write foo.BASE. <abentley> Right. But we will have to write foo.BASE. <lifeless> ok <lifeless> so lets look at that <lifeless> we write foo.BASE when we ended up doing a merge right <abentley> Right. <lifeless> now, will we avoid doing 'merges' sometimes with custom file bases ? <abentley> No, but if the BASE is not a file, we will do a two-way merge between THIS and OTHER. <lifeless> which is where [] is useful because it's just a clean degradde. <abentley> A clean what? <lifeless> degrade <lifeless> it's what 3-way degrades too <abentley> Okay. <lifeless> hmm, one sec local interrupt <lifeless> back <lifeless> wondering if we will ever get base == left or base == right with custom merge bases <lifeless> I think we can <lifeless> consider this <lifeless> at the graph level we have two lca's <lifeless> so we recurse <lifeless> its easy then for at the file level for one side to be purely an extension of the other for a single file <lifeless> so when we are considering that single file we'll not need to merge at all <lifeless> I'm going to think out lout now <lifeless> and enumerate what I think the possible cases are <lifeless> * Base is one side (common I suspect in criss-cross merges; many files won't be actually unmerges) <lifeless> * Base is the revision the graph level base had <lifeless> * Base is another inventory <lifeless> s/another inventory/from &/ <lifeless> done <lifeless> abentley: ^ <josep17> buenas noches <josep17> desde venezuela <abentley> lifeless: I would expect base==left or base==right to be rare. But I would imagine we can get it. I'm not sure why it matters. <abentley> We need a general solution. <abentley> Sure, I can hack up something gross to do per-file bases, but I think you ought to consider how an upcoming repo format could give us cheap access to file kind, symlink target, and maybe execute bit. <abentley> Right now, I'm re-implementing annotate merge, and it's going swimmingly. <jelmer> dato: resubmitting bzr-svn fixed it <jelmer> dato: your upload of 0.4.4-2 hadn't been processed yet, apparently <abentley> jelmer: Have you noticed that the bzr-gtk test suite is completely borked if run as part of the bazaar test suite? <lifeless> abentley: I'm pretty sure I hit it all the time. <lifeless> abentley: anyhow, our current format can give use kind/target/execute quite cheaply <lifeless> abentley: just use the same parse-a-delta-fragment logic. <abentley> Oy. Can't we do up a format where that works by design instead of being a tremendous hack? <lifeless> abentley: yes, both the ones poolie and I have been fiddling/mailing about will work by design <abentley> Awesome. <lifeless> abentley: but they largely formalise useful properties we have been able to leverage from the current format. <lifeless> abentley: I have been thinking that content object information should be pushed down to the per file graph anyhow; as metadata on the node <abentley> Well, I know the new format will do comparisons much faster, but that sounds like it would slow them down. <lifeless> abentley: I'm thinking some duplication actually <lifeless> abentley: but also there is locality of data possibilities. <lifeless> abentley: this would be a 2nd or 3rd iteration out. <lifeless> abentley: one possibility is: <abentley> Oh, by "pushing down", I thought you'd be taking it out of the inventory. <lifeless> kind + exec + content in the 'knit' <lifeless> inventory has parent + name + pointer to the knit version <lifeless> 'knit' index can pull kind + exec into it. <lifeless> abentley: the open things in my mind about whether this makes sense are what datum we actually need at the same time <abentley> For our tree-manipulation functions, we generally use inventory and file texts simultaneously. <abentley> When building a tree, to create a file, we need file_id, name, parent, kind, execute bit, and content basically simultaneously. <abentley> That's not a hard requirement. TreeTransform could work efficiently if you learned names, parents and file-ids in one pass, and everything else in a second pass. <lifeless> abentley: so its the case of status/diff when the last-mod is different and the value is the same that would be hurt <lifeless> abentley: -> how common is that <lifeless> (assuming we don't want false positives for st <lifeless> another possibility here though is to decouple the metadata graph from the content graph <abentley> This is assuming we're not diffing against a DirstateRevisionTree? <lifeless> right <abentley> So we wouldn't have the md5sum in the inventory? <lifeless> so you'd have (fileid, parentid, name, content-pointer[revid, validator]) as a graph <lifeless> and (kind, exec, content) as a graph <abentley> I'm not sure at all how common that is. Merges can produce it, though. <lifeless> you'd have a sha1, but not of the lines, of the lines & kind and exec bit <lifeless> this would for instance, allow us to start only storing one copy of 'COPYING' etc, depending on how we want to take it. <lifeless> this is all still wildly speculative <abentley> I don't think kind is a big concern. If it changes, we definitely need to get all the data. <abentley> I dunno, though. I think having all the data in the inventory might well be a win. <lifeless> I'd like to be in a position to experiment <abentley> Just because there are many operations that just want to know which files changed. <lifeless> write some arbitrary benchmarks outside bzr that simulate access patterns and the like <lifeless> maybe this is something we can reason about in march <abentley> Also, some stats on real trees might help us answer these questions about what's common better. <lifeless> abentley: indeed. So having an analyser that can report what a transformed tree would look like would be good <abentley> I'm not sure what you have in mind. The PreviewTree thing? <lifeless> nah <lifeless> just a script to take a branch <lifeless> and break it out into the things I'm talking about, without doing disk transformations, just in-memory, and report <abentley> Oh, to simulate a changed repo format? <lifeless> right <jelmer> lifeless: what breaks about it? <jelmer> s/lifeless/abentley/ <jelmer> ah, I see <lifeless> meh <lifeless> sorry about disappearing; what did I not respond to <Odd_Bloke> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- <Odd_Bloke> 05:03:21 -!- lifeless [williamsmith@example.net] has quit [Read error: 113 (No route to host)] <Odd_Bloke> 05:15:45 -!- lifeless [williamsmith@example.net] has joined #bzr <Odd_Bloke> Oops, got the trackbar. <Odd_Bloke> But yeah, nothing. :p <lifeless> thanks <alecwh> hello, I'm considering using bazaar for a project of mine... we're using subversion right now, because subversion is offered on Google Code, and Gna! (http://gna.org). Are there any free repository hosts that our GPL program can use (using bazaar)? <beuno> alecwh, sure, https://launchpad.net/ <beuno> it also works as a bug tracker <beuno> (and a bunch of other stuff) <alecwh> no way... it hosts a free bazaar repository? that's awesome. <alecwh> how do I set it up? <alecwh> https://code.launchpad.net/phpns/ <alecwh> This is our project <alecwh> Register branch? <beuno> alecwh, let me fetch you a how-to real quick <Peng> Hmm. I just started using LP a bit. I should look into the launchpad plugin. <beuno> alecwh, https://help.launchpad.net/FeatureHighlights/BazaarHosting might help a bit <beuno> but you basically just push to the right address with bzr <beuno> and the branch gets created <beuno> the folks at #launchpad might be able to give you more details though <beuno> it's a bit over 5am here, so I'm going to bed <beuno> good luck :D <alecwh> ok, thanks a lot bueno. ;_ <alecwh> ;) <Peng> Might be even simpler using lp: URIs. <Peng> New Pyrex release. <alecwh> How do I import a subversion repository into a bazaar repository? <Peng> alecwh: You could use bzr-svn. <alecwh> what does that do? <Peng> alecwh: bzr-svn can even allow pushing from bzr to svn. It's pretty neat. <Peng> alecwh: Well, for one thing, it imports svn repos into bzr repos. <alecwh> yeah, that's what I'm looking for. =D <alecwh> how does that look like? <alecwh> the bash command. <Peng> Not sure. <Peng> "bzr branch" might do it. <Peng> Read the docs. <alecwh> ok, thanks Peng. =) <lifeless> alecwh: www.bazaar-vcs.org/svn IIRC <alecwh> This page does not exist yet. You can create a new empty page, or use one of the page templates. <alecwh> lifeless: I got that error. <lifeless> alecwh: there is a link on it <lifeless> alecwh: to BzrSvn :) <alecwh> ok, thanks lifeless. I'll read over it. <JordanC> Hey there <JordanC> Tried to get things working with olive, but no dice/ <alecwh> hey JordanC. =D <Odd_Bloke> JordanC: Define 'no dice'. :p <alecwh> Odd_Bloke: It didn't work. <Odd_Bloke> Yeah, I got that much. :p I was hoping for something a little for specific. :D <Odd_Bloke> s/for/more/ <JordanC> I came in here a while back, and yeah <Odd_Bloke> JordanC: Are you using Olive or bzr-gtk? <JordanC> I spoke to some developers, and they said that because of the SSH factor, I can't connect to launchpad using olive <Odd_Bloke> Ah, OK. <Odd_Bloke> Have you looked at QBzr? <JordanC> Hmm, lesee <JordanC> KDE Bazaar proggy? <Odd_Bloke> JordanC: http://bazaar-vcs.org/QBzr <luks> no, in two ways <Odd_Bloke> Qt, not KDE. <luks> not a program, not kde <JordanC> Damnit <ronny> yo <ronny> is there a way to get more easy to parse output from bzr ? <ronny> (im parsing the status output for an ide, an its really tricky to get it together atm) <Odd_Bloke> ronny: There's an xmloutput plugin, I believe. <Odd_Bloke> ronny: https://edge.launchpad.net/bzr-xmloutput <Odd_Bloke> ronny: Which IDE were you thinking of? <abentley> luks: I'm looking at your patch more carefully now. <luks> thanks :) <abentley> I think a nicer way to extract the name would be to have a pattern that only matches if there's "name <email>", and if it fails to match, just return the original string. <ronny> Odd_Bloke: pida <luks> well, I think returning "email" from short_author is better than "<email>" <luks> unless you want to match "(name )?<email>", which is exactly what the patch does <abentley> I think that's highly unlikely. <ronny> Odd_Bloke: right now we parse the command output, cause the subsystem for python-api based vcs tools is basically nonexistant <luks> abentley, "<email>" is the use case from the bug report <ronny> the bad thig is - we get wrong data sometimes, but cant figure the exact source, cause the bzr output aint nice to parse (so the parser is tricky) <abentley> Also, I don't know if lazy_regex was meant to be used in new code. <abentley> I thought it was just to make existing code faster. <abentley> And I really doubt there's a performance win by using it. <luks> but what's the point of compiling a regular expession you are not going to use <luks> sure, it's not a big win, but there is a lot of small things like this <abentley> There's no win, there's loss in compiling a regular expresion. I was talking about not williamsmith@example.net. <luks> hm? you mean parsing the string manually? <abentley> no, just using re.match <luks> that compiles it every time you use it <abentley> Right. <luks> so about 3k times for log on bzr <ronny> actually its cached <abentley> luks: I really doubt that performance difference is observable. <ronny> the more often a re is used, the more sense it makes just to compile it <ronny> but the difference is only small, cause all re's u use are cached in re._cache <luks> abentley, I mean, bzrlib already has code to delay regex compilation, pre-compiled regex is faster than re.match, there is a patch that use it -- why make is slower? even if the difference is small <abentley> Because it's clearer to just write re.match <abentley> Takes fewer lines. Doesn't require people to grok lazy_regex. <ronny> hmm - how does lazy_regex work ? <luks> compiles the regex when it's first used <luks> *first time <ronny> im more intrested how the store works <ronny> cause i doubt it has any notable gain compared to re.match <abentley> ronny: It allows the "lazy_compiled" patterns to be substituted for really compiled patterns-- that's what it's for. <abentley> So you can fix import slowness without rewriting the module. <ronny> "import slowness" ? <abentley> regexes that compile at import time reduce cause latency problems for programs like Bazaar. <abentley> You run bzr, it imports a whole bunch of modules, they compile a whole bunch of regexes, and then, finally, it starts doing what you asked. <ronny> hmm - why do you guys need so many regexes ? <abentley> The libraries we import need them. <abentley> (well, they *have* them. *need* is debatable) <ronny> btw - any timeframe when bzr will be as fast as hg ? <abentley> For example ConfigObj has regexes that produce a noticeable compile delay. <abentley> ronny: It depends what you're talking about. With the packs format, commit speed is pretty similar. With the smart server, pull time is similar. <abentley> status has been comparable for some time now. <ronny> ah - so its mostly cause bzr has tonns of other operation modes ? <abentley> Well, it depends what operation you want to speed up. <ronny> all i care for is fast sync and fast commit <abentley> I think 1.0 will give you that. <ronny> hmm - i didnt exactly use bzr for quite some time <ronny> does it still try hide the existence of multiple heads (for example by allways enforcing merges) <abentley> I think we've got the pieces in place to support good performance for most commands. <abentley> I don't know what you mean by hiding the existence of multiple heads. <abentley> But in some cases, the commands must be updated to take advantage of them. <ronny> last time i used it it dodnt allowme to hae multiple heads in my repo <abentley> Repositories typically have many heads due to people uncommitting revisions. <abentley> But we don't have multiple heads for a single branch. Instead we allow multiple branches per repository. <ronny> hmmk - thats a problem for me <abentley> Why? <ronny> enforces me to split one semantical branch into multiple branches if more than one person is working on that <abentley> No, they can use heavyweight checkouts. <Odd_Bloke> ronny: That's what you're doing with multiple heads anyways... <abentley> That lets them commit locally. <abentley> And then sync up with the main branch when they're ready. <ronny> damn - how many modes of operation does bzr have ???? <abentley> We support a range from svn-like to fully distributed. <ronny> hmm - having too many choices tends to be confusing <abentley> Well, we have three: a "tree" has a branch and working copy at the same location. A "heavyweight checkout" has a branch in one location and the working copy is at different location, but has a local copy of the branch to act as cache. A lightweight checkout is like a heavyweight checkout with no local cache. <alecwh> I just created a bazaar branch at launchpad (https://code.launchpad.net/~alecwh/phpns/devel), and now I want to upload my project (which is in /var/www/devel) to the repository. In the terminal, my working directory is /var/www/devel, and I gave the command: bzr push bzr+ssh://williamsmith@example.net/~alecwh/phpns/devel , but it doesn't seem to be working. I get the error: bzr: ERROR: Not a branch: /var/www/devel/ , can anyone help me upload <luks> cd /var/www/devel; bzr init; bzr add; (check if it added only files you want); bzr commit <luks> and then you can use bzr push <luks> http://doc.bazaar-vcs.org/bzr.0.92/en/mini-tutorial/index.html#putting-files-under-version-control <alecwh> ok, I'll try that. will 'bzr add' add every single directory and file inside /var/www/devel? <lifeless> moin <alecwh> moin? <lifeless> alecwh: yes, add adds recursively, obeying your ignore rules <alecwh> thanks lifeless. I've got one more question: when I was using svn, every 'commit' you made actually uploaded your changes to the online repository. Is this not the case with bazaar? <lifeless> alecwh: if you have a checkout it acts like svn <alecwh> a checkout? <lifeless> alecwh: that is, if you do 'bzr checkout bzr+ssh://williamsmith@example.net/~alecwh/phpns/devel local-dir-name' <lifeless> then you can cd local-dir-name, and do <alecwh> that will download the project, right? <lifeless> 'bzr commit', which will commit back to bzr+ssh://williamsmith@example.net/~alecwh/phpns/devel, just like svn <alecwh> oh. <beuno> alecwh, or, when you want to send all your commits, just use "bzr push" <lifeless> alecwh: if you have a separate 'branch' though, then your commits are performed just on your machine <alecwh> ok, that makes sense. <alecwh> https://code.launchpad.net/~alecwh/phpns/devel <beuno> (when using branches instead of checkouts) <alecwh> I just finished uploading everything... <lifeless> alecwh: and then when you want them to be in bzr+ssh://williamsmith@example.net/~alecwh/phpns/devel, you do 'bzr push bzr+ssh://williamsmith@example.net/~alecwh/phpns/devel' (bzr will remember the push location the first time, so you don't need to type it every time0 <alecwh> how do I make it so every time I 'commit' it will update this repository? <lifeless> alecwh: bzr bind bzr+ssh://williamsmith@example.net/~alecwh/phpns/devel <alecwh> ok lifeless, that worked. =D <alecwh> I was using 'cia.vc', which puts a bot inside your channel on freenode, and then it will post a message inside the channel whenever a commit/change is made. Is there something like this for bazaar? <lifeless> alecwh: there is a plugin for bzr to announce to cia <lifeless> alecwh: you can also subscribe to the branches on launchpad <lifeless> alecwh: or install bzr-email to send emails to arbitrary email address's on commits <alecwh> ok, cool. Do you know what the plugin was called? I'm just looking for it... <lifeless> http://www.google.com/search?q=bzr+cia&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a <lifeless> 3rd and 4th hits look relevant to me <alecwh> https://launchpad.net/bzr-cia <alecwh> lifeless, uhm, how do I get the plugin? =P <beuno> alecwh, with bzr, of course :D <alecwh> https://code.launchpad.net/~jelmer/bzr-cia/main <alecwh> is this the one I'm looking for? <beuno> alecwh, yeap <alecwh> bzr branch http://bazaar.launchpad.net/~jelmer/bzr-cia/main? <alecwh> use that command? <beuno> alecwh, yeah, you download it with that command <alecwh> ok, done. =D <alecwh> I think I got it now <beuno> now, follow the instructions in: https://launchpad.net/bzr-cia <lifeless> success; we have a 1.0 build on dapper-amd64 <lifeless> i386 testing now <lifeless> brb foodstuff time <dato> jelmer: very well <dato> jelmer: btw, I guess there is no way to convert from svn a trunk and a branch, if I somehow say which revisions from the trunk are merges from the branch, right? <jelmer> dato: only if you can go back in history and set some magic svn properties <dato> jelmer: can I a dump of the repository, load it locally, set the properties there, and redump? that ought to work? <jelmer> dato: yes, but you would want to change the uuid <dato> ok. is there a document explaining what properties I should set? <jelmer> and pulling from the original in the future may be problematic <jelmer> http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping <jelmer> basically, you'd want to set the bzr:ancestry:vX-SCHEME property <lifeless> dato: is it really worth doing? why not just do a merge after the conversion? <dato> jelmer: it's a one-time conversion <dato> lifeless: I seem to find a strange pleasure fiddling with the tools. <lifeless> dato: :) <dato> jelmer: ok, thanks for the link. I'll try to do it. also, I svn-import trunk didn't work for me yesterday, but the packaged version worked fine. I'll try again tomorrow. finally ;), changing the UUID is just a matter of editing the dumpfile by hand, or? <jelmer> dato: the trunk branch for bzr-svn is highly experimental <jelmer> dato: 0.4 is the branch that is packaged <jelmer> dato: yep, editing the dumpfile should be all that's needed to change the uuid <abentley> lifeless: What do you consider a good way to decide if something should be a separate module or not? <abentley> I was expecting plan_merge to be bigger than it is, which is why I originally did it. <lifeless> abentley: I don't have a good rule; sometimes I get there and combine; sometimes I start in the same module and split. <vila> wtf ? test_revision.TestIsAncestor.test_is_ancestor is failing just under the comment: <vila> # NB: if you see an assertion error here, its probably access against <vila> # an unlocked repo. Naughty. <abentley> I guess by analogy, I'd think if merge3 has its own module, then annotate merge can have one, too. <vila> the problem is I'm working on http response parsing rewrite and I can't find any link >-/ <vila> Worse, the same test on bzr.dev@3059 fails too, midnight bug ? <vila> and on top of that, I see (when doing bzr missing in my bzr.dev branch) revno: 3061, deprecate bzrlib.revision.is_ancestor <vila> Ran 9939 tests in 437.020s <vila> FAILED (failures=1, known_failure_count=5) <vila> bah, time to sleep anyway, a bit frustrating though <vila> not failing anymore in williamsmith@example.net... at least.... <lifeless> jelmer: where is bzr-gtk for 1.0 ? <lifeless> abentley: oh it can have one if you think it should; I was asking the question. <abentley> Sure, and I've actually decided to move them into versionedfile and merge. <abentley> Just because there's so much related stuff in those modules. <jelmer> lifeless: phanatic is doing release management these days, I'll ping him by email #bzr 2007-12-03 <abentley> lifeless: What sort of thing would you like to me to put in the developer guide? <abentley> And why this, rather than the many other things we're constantly adding to the codebase? <lifeless> abentley: because I remembered to think about it. <abentley> Well, it seems like it would be onerous to do this for everything. <abentley> But where should it go, and what should it say? <abentley> It doesn't seem to belong under "domain classes". <abentley> Also, I've just found an optimization that gets it about as fast as the old implementation. <abentley> On knits. <lifeless> cool <lifeless> ok 1.0rc1 debs are up; including dapper <abentley> Oh, cool. <abentley> lifeless: Can you give me some guidance on the documenation? I'm otherwise ready to re-submit. <lifeless> abentley: one sec, email frenzy <abentley> Okay. <jelmer> lifeless: no bzr-svn debs ? would be nice to have them up, at least for gutsy <lifeless> jelmer: hmm, I'll see how far I get; I go on leave in two days <lifeless> abentley: ok, with you know. <abentley> Fire away. <lifeless> so if the answer is 'there is no developer docs 'about merge' at the moment, then you're good - don't worry,. <lifeless> starting something that covers the design, motivation, tricks n tips etc for people writing to the collection of apis that combine to make up 'do merge' would be nice at some point., <abentley> I don't remember writing any, so there probably aren't any. <lifeless> I can't see any at a glance in doc/developers * lifeless -> food <abentley> Okay. Thanks. <abentley> igc: Hi. <igc> hi abentley <abentley> Would you be able to review my criss-cross documentation? http://williamsmith@example.net%3E <abentley> jam was a bit concerned about the style. <igc> abentley: sure <abentley> The bit about merge --weave being slow on packs may be obsolete soon. <igc> ok <Peng> Could someone mark https://bugs.launchpad.net/bzr/+bug/172612 as fixed? The patch is in bzr.dev now. <ubotu> Launchpad bug 172612 in bzr "new commit is overly verbose" [Low,Confirmed] <lifeless> done <Peng> Thanks. <lifeless> bbs <jml> lifeless: have you written up anything in English describing the scenario stuff in bzrlib.tests? * igc lunch <lifeless> jml: no <poolie> jml, i know a bit about it, i can possibly describe it in documentation <poolie> in fact, i did write something in HACKING, you could look at that <jml> poolie: I'll take a look. <lifeless> I should finish my in-file tweaks. <poolie> questions welcome <lifeless> might do that tomorrow <lifeless> poolie: patch sent <jml> how do you actually use DVC to commit? <jml> add a log entry and then hit C-c C-c in the log buffer apparently. <jml> seems kind of backwards. <vila> jml: cou can hit 'c' in a dvc-diff or dvc-status buffer, it will open a buffer for the commit message and there you can hit C-c C-c <jml> vila: ahh, ok <jml> vila: I guess seeing as I review a diff before I commit anyway, that makes sense. <vila> jml: yeah the dvc-diff buffer is handy, since it's based on diff-mode you can also very easily revert any hunk by using C-c C-a or mark the files for selective commit <glatzor> hi, is there a document that covers running a bzr server using sshd? <luks> you don't need to run a bzr server there <luks> just install bzr on the server and bzr will run it on the remote side over ssh <glatzor> luks: is there a way to limit the ssh access on the server? <glatzor> luks: I don't want to allow full ssh access on my machine. <luks> um, I'm not sure <glatzor> for my subversion server I use the command option in the key configuration: command="/usr/bin/svnserve -R -t -r /srv/subversion" <glatzor> ui, you are releasing 1.0 today? congratulations! <mwhudson> glatzor: you can use something similar for bzr too <mwhudson> i think it's "bzr serve --inet --allow-writes", but i'm not completely sure <Peng> --directory=/ too. <Peng> (And maybe even something else that gets cut off the edge of the screen.) <dato> jelmer: sorry, I
{'channel': 'bzr', 'month': 12}