[00:26] New bug: #179314 in bzr "bzr reconfigure ctrl-C errors inappropriately" [Undecided,New] https://launchpad.net/bugs/179314 [00:26] New bug: #179316 in bzr "bzr reconfigure is not order-safe" [Undecided,New] https://launchpad.net/bugs/179316 [00:53] ddaa: what does 'remote' mean for branches ? [00:54] lifeless: context? [00:54] lp [00:54] https://code.edge.launchpad.net/~lifeless/squid/squid3-trunk [00:54] not copied on vostok [00:54] oh foo [00:55] what do I have to change to make it 'mirrored' and wouldn't 'not-mirrored' or 'reference-only' or something be clearer ? [00:55] either 1. edit branch details 2. if that does not work delete the branch 3. if that's not desirable ask an admin to poke the db [00:56] I was meaning what db values :) [00:56] branch details does not have a field for remote/mirror [00:56] the should be a Branch.type column or somesuch now. [00:57] with corresponding BranchType in c.l.i.Branch [00:57] about the naming, I guess it would be better yes [00:57] file a bug :) [00:58] there's an annoying failure mode of changing the branch type in the UI that prevented from enabling it [00:58] hosted -> mirror -> hosted can have unexpected effects [00:58] don't have to allow all [00:58] just allow mirror/remote [00:59] sure [00:59] sure... remote came up after that was considered [00:59] not sure if it makes sense to allow as well [00:59] since we should also delete data on mirror->remote [01:00] unless the various front-ends just ignore remote branches [01:00] then it should be okay, I think [01:02] how do I tell it to mirror ? [01:02] https://code.edge.launchpad.net/~lifeless/squid/squid3-trunk [01:02] (next mirror: disabled) [01:03] found it [01:04] ok thanks [01:05] lifeless: just saw your bug report. Am very surprised that reconfigure would delete the repository if fetch failed. [01:06] abentley: it may have just scribbled over the branch but left the repository intact [01:06] ls .bzr/ [01:06] branch branch-format branch-lock checkout README repository [01:06] either way though, the target should be fully prepared before the local tree is altered I think [01:07] Ideally, the whole thing would be atomic. [01:07] Hey folks, I am following the mini tutorial. Everything worked great up until I pushed to my server. The directory gets created in the right place, however there are no files. I have created and modified the file locally, commited it (twice), and pushed it three times now, no files still. [01:07] using sftp provided by openssh server. [01:08] distatica: if there is a .bzr directory it has worked [01:08] there is no directory [01:08] distatica: push isn't supposed to create any files. [01:08] distatica: your editable files are not created on push [01:08] oh wait, there is too [01:08] ohh [01:08] so where are the files stored? Always locally? [01:09] The files are always local, for whatever machine bzr is running on. [01:10] oh, so if I switch to another computer then there's no way to get the files, without having them uploading seperately? [01:11] sorry, I'm used to SVN, I usually hope between computers and use it and my server for moving between machines. But there's some things I don't like about the subversion setup. It's harder ot make multiple projects for one. [01:11] erm, hope == hop [01:12] If you switch to another computer, you'll branch from a remote copy. [01:12] distatica: All of the data is stored in the .bzr directory. [01:12] That will download everything you've committed, and recreate the working files from the committed data. [01:16] heh, I'm trying to see how this works, but I get an unknown branch format using the debian stable binary [01:16] debian etch* [01:18] distatica: You're using 1.0 on your other machine? [01:18] 0.11.0 [01:18] Dude. [01:18] That's like 75 years old. [01:18] lol [01:19] I don't doubt it, I think my grandfather worked a bit on etch packages. [01:19] I'm installing the one from the site now. [01:19] I was just trying to test it quickly [01:21] The two current repo formats were introduced in 0.15 and 0.92. I'd be kinda surprised to find a branch in the wild that was compatible with 0.11. [01:22] (0.15 is only from April, but still.) [01:25] Peng: "dirstate" used the same branch and repo format as "knit", so they were network-compatible with bzr back to 0.8. [01:26] Is there anything like trac (or a plugin for trac) for bzr? Or at least some other way to browse the source through a browser (prefer with syntax color) [01:26] It was only with "dirstate-tags" that we broke compatibility with older-than 0.15 [01:27] abentley: Oh, ok. [01:27] There are actually quite a lot of branches in older formats out there. [01:27] So that's why it's called "dirstatE". [01:27] distatica: There's Loggerhead, but it's pretty heavyweight (TurboGears). There's also bzr-webserve and bzrweb. Probably a Trac plugin too. [01:28] There is a trac plugin, but I don't recommend it. It's slow because trac and bzr have fundamentally different formats. [01:30] Peng: I don't see TurboGears as especially heavy. It's just a dependency and the install is dead easy. [01:30] Good to know though, since this is for shared hosting. [01:30] abentley: FWIW it took about 6 hours to install turbogears on freebsd 5.5 [01:30] decent shared hosting (ruby on rails, php, python) but shared nonetheless. [01:30] man-hours [01:31] lifeless: Ouch. Why? [01:31] the dependency chain is deep [01:31] something like 20 deeper module [01:32] the ports tree only ships python 2.4 stuff for some, 2.5 for others, default python version is 2.5. [01:32] freaking mess, I had to hand-update half the ports [01:32] the ports use eggs not source tarballs, so projects that hadn't uploaded 2.5 eggs were bustificated too [01:32] I've done several clean installs lately, and I don't think they took longer than 10 minutes. [01:32] Can't find a whole lot about this bzrweb, found one site that looked like it's the one, but internal server errors. [01:33] and the PEAK stuff just is too new to be packaged on BSD at all. [01:33] distatica: what operating system are you using ? [01:33] Ah. This was just easy_installing, with no manual intervention. [01:33] lifeless: windows 2000 here, XP on the other machine, and debian etch on the server (local server, pretty much just a POS to do my bidding) [01:34] * fullermd glances at the turbogears port. [01:34] distatica: etch should have a good turbogears package. [01:34] Yeah, it looks messy. [01:34] lifeless: was interested in the other two, to see how they work and if they would run on my shared host. [01:34] installing dependencies is out of the question there. [01:35] distatica: You can install apps, but not their dependencies? [01:35] I can't install apps. I can install scripts, for viewing on the Internet. [01:35] PHP, Python, Ruby, but I can't just install python dependencies no. [01:36] A [01:38] abentley: that's why I'm looking for more information on those two programs, I'm not sure if they're full blown web servers (obviously one is, but does it have any useful code, for my needs?) or a script that actually reads the .bzr directory. [01:40] I don't think any of them are CGI scripts, if that's what you mean. [01:40] yeah, that's another (better) way of putting it. [01:40] One of them is a bzr plugin, IIRC. [01:41] Anything that views bzr repositories is going to need bzrlib, but bzrlib doesn't need to be *installed*, per se. [01:42] You can usually just stick a symlink to bzrlib in the root directory of the program that uses it. [01:42] that sounds like a neat trick [01:43] back later [01:44] ok, thanks for the help [01:45] New bug: #179325 in bzr "error with "bzr gcommit": 'NoneType' object has no attribute 'abort'" [Undecided,New] https://launchpad.net/bugs/179325 [01:46] lifeless: Actually, doesn't look like anybody's really maintaining it. It's a couple versions back, and hasn't had any real work since before 2.5 became default :| [01:53] Loggerhead? [02:15] Low-prio idea: Anything against generalizing the default-push-branch, default-pull-branch, bind branch, etc., concept to just letting us create branch nicknames, where some nicknames like "push" etc. have special uses? Not sure how many people link one project to a number of branches, but if this is a common use case, it could make sense. [02:36] well, loggerhead was a good suggestion, didn't take too much time either, thanks. Looks nice. [02:44] Peng: I think fullermd was talking about FreeBSD TurboGears. [02:45] dlee: I tried that before with a VCS UI called Fai, and I found it very confusing. Always having to remember which aliases are set in which tree is not a good thing, IMO. [02:46] Could be set in bazaar.conf too I suppose [02:52] dlee: I think global aliases are a much better idea. But that is no longer an extension of the push/parent/submit location idea. [02:52] touche [02:53] Just don't use ^ to indicate aliases or zsh users will take you. All the good metacharacters are gone. [02:53] s/take/hate [02:56] leading @ ? I haven't thought this part out much. [02:58] I suppose a leading : could work too, unless there's an OS-specificism I've never seen [03:00] Anyway...just a random thought, caused by my working to make bzr look unbelievably easy to some folks here that don't use version control much or at all yet. So far, I've achieved short branch names via bzr serve on a LAN; you use a VPN to get to it if outside, but once there, a dotless server name resolves (probably via Windows means), so branch names like bzr://servername/projname are possible. Good enough. :) === b6sfca_ is now known as b6sfca [03:14] FWIW, hg uses branch aliases exactly like that. [03:22] Hi all. [03:24] Suppose I "bzr rm" a file and them commit. How can I then see the history for that file? [03:24] "bzr log foo" says "bzr: ERROR: Path does not have any revision history: foo" [03:30] CardinalFang: It looks as though there's no direct way. You'd have to check out an earlier version of the tree, or resurrect the file. [03:30] * CardinalFang boggles. [03:30] well... that's not a hugely common operation [03:31] Obviously, that should be fixed. [03:31] hey abentley, I have a bzr-git that does pull [03:31] not very fast, or very correctly [03:31] but it does kind of works [03:31] ddaa: Hehe, but still, great. [03:32] just added some sqlite so it runs out of memory later [03:36] anybody know if there's a good way to get the results of bzr log for a deleted file? [03:36] so like, if you wanted to find out when a file was deleted? [03:40] * Peng looks up at CardinalFang ten minutes ago. [03:41] mtaylor: The answer was that there isn't really a good way right now. "You'd have to check out an earlier version of the tree, or resurrect the file." [03:42] * Peng wanders off. [03:42] * CardinalFang pokes mtaylor [03:42] * Peng at two words per minute. [03:42] * mtaylor rubs himself where he got poked [03:42] CardinalFang: did I miss the conversation about this? :) [03:43] Yes. Sorry. [03:43] mtaylor: You came in a couple minutes after it--so close I did a double take and looked to see if you two were different people :) [03:43] how funny [03:44] hi CardinalFang [03:47] ddaa: Wait, you're trying to make it run out of memory later? [03:48] I mean later as in "not as early" [03:48] lol. Gotcha [04:39] there seems to be a minor inefficiency in our repo format: when the x bit changes, it seems the file text is stored once more. [04:40] or maybe I misinterpret the bzr check output [04:40] checj is rubbish :) [04:40] well, check and the install_revisions code [04:48] lifeless: Did you see my new merge algorithm? I'm still quite excited. [04:51] abentley: don't think so; if its in bazaar-ng I'll see it wednesday [04:51] or thuesday [04:52] Ah, you're been getting my mail because it's cc'ed to you. I thought you were reading the list. [04:53] In the non-criss-cross case, it behaves like 3-way. [04:53] In the criss-cross case, it should behave better than "weave". [04:57] So I think it could make mesh-merging basically painless. [05:00] good [05:13] hey [05:14] so after reviewing all the other DVCS I really like BZR. However I cannot seem to get Python 2.5 on Leopard and Patched Subversion 1.4 and bzr-svn to work. It's %@#$ing killing me after 24 hours of &%*ing around with it. [05:15] I like BZR UI - it's better than GIT. Help me out here. I have to work with SVN users. [05:15] I have carefully compiled Subversion patched like bzr-svn says to. Insalled it to /usr/local [05:17] in fact - here is my pastie of notes of EXACTLY what I have done http://pastie.caboo.se/133164 [05:17] It's killing me. If BZR can't operate with svn EASILY then I have to toss it out. [05:18] After my careful install - all I get is [05:18] "Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details. [05:18] Unable to load plugin 'svn' from '/Users/tim/.bazaar/plugins'" [05:19] BZR by itself is cool. I like it better than GIT. I wish this would just work. [05:19] Thanks for any help. [05:20] there may be more detail in ~/.bzr.log [05:20] ok one sec [05:22] I appologize I am a Java & Ruby nerd. I don't speak the snake. [05:22] http://pastie.caboo.se/133165 [05:23] lines 8-15 [05:23] http://pastie.caboo.se/133166 <- I think I have my path right for my custom subversion [05:24] try python -c 'import svn; print svn.__file__' [05:24] http://pastie.caboo.se/133167 [05:25] thats the svn its loading [05:26] You can see from http://pastie.caboo.se/133164 that I did in fact apply the patches. It did infact install to /usr/local/lib/svn-python/ and I symlinked it to where I think python likes it better (site-packages) [05:26] You also need a fairly recent version of the official Python bindings to the [05:26] Subversion libraries. At the moment, the svn plugin only works with [05:26] Subversion 1.5 (trunk). The python-subversion (not python-svn!) package [05:26] thats from READ [05:26] ME [05:27] hmm - must have glossed over that. [05:27] I went straight to the bottom of http://bazaar-vcs.org/BzrForeignBranches/Subversion [05:27] Under Requirements and Subversion 1.4.3 w/ patch [05:28] jelmer: ^ [05:32] It's a bummer to have to go grab /trunk subversion to get this to work. That makes it harder for me to convince my team to switch. :/ [05:32] but I appreciate the help [05:32] once you build it once they can use binaries surely? [05:32] Even if it's for my fun only. [05:33] The OS X Leopard installer is so slick to for BZR 1.0 [05:33] slick too [05:40] * dysinger compiling [05:45] dysinger 1.5 coming out soon? [05:45] I don't know - is it ? [05:46] I was joking about "dysinger copiling", as if you were a software product. [05:46] ah :) [05:47] I'm done with bzr-git hacking for this year. [05:48] all my stuff is pushed on launcphad [05:48] enjoy [05:48] nice [05:48] Well 1.5 trunk svn compiles ok but make chek-swig-py bombs [05:52] I'm afraid I can't help with that. My preferred platform has suitably patched bindings. [05:52] bzr selftest svn fails :/ [05:52] ddaa: Cool. [05:53] My preferred platform has 8 cores at 3GHZ and 16GB ram :) [05:53] (new mac pro) [05:53] ddaa: what's interesting and in Git? [05:53] xorg [05:53] kernel [05:53] samba [05:53] small stuff nobody uses like that ;) [05:54] Yeah, so basically stuff I don't really have disk space for. [05:54] well, git itself [05:54] it's small enough [05:55] though it does produces a >1GB git-cache [05:55] all because bzrlib is too dumb to figure out inventory entry revisions by itself :( [05:56] so while I have you guys here. What makes BZR better than GIT? I like the UI better but it's not a compelling enough reason not to use GIT by itself. [05:56] lesse [05:56] The SVN integration thing is not working for me even with 1.5 [05:56] it works on windows [05:56] yes that's a plus [05:56] generally, it's more user-oriented [05:57] yeah I like the UI better [05:57] good user interface is not skin deep [05:57] like in git git-checkout means like 3 different things [05:57] I believe it support more workflows naturally, actually bzr in extremely flexible [05:57] s/in/is/ [05:58] (make a branch, switch working branches and replace files with original) [05:58] really, bzr strong points all revolve around the user experience [05:58] I don't like that - I like bzr's simple commands. [05:59] it's *designed* to be nice to use [05:59] while git is designed to be incredibly fast [05:59] I like that I can push without having to set hooks or export a "bare" repository. I like that I can push to sftp with no setup. [06:00] I just can't get it to work with SVN :/ [06:00] honestly, it's more a problem with svn [06:00] yeah by itself BZR is very cool. [06:00] jelmer had to write a bunch fixes to the python bindings [06:00] I just have to work with remote svn - everybody uses svn. [06:00] and they need to go through svn release process. [06:01] * dysinger understands [06:01] dysinger: if you do not have commit access, you could use launchpad's code import service. [06:01] that does not work all the time, and that only import trunk, but that's often enough. [06:02] oh, if you're a company [06:02] that would work for personal and open source projects but not for client's code. [06:02] ddaa: is git-over-http supported? Or do I need to do the initial clone in git? [06:02] abentley: it needs a local git [06:03] I've been ranting a lot the past few days about how git:// is going to be a pain to support [06:03] or git/http for that matter [06:03] so, if you're a company [06:03] you can talk to Canonical to get professional support for bzr. [06:04] Or you can run Ubunut in Parallels :-) [06:04] s/Ubunut/Ubuntu [06:04] oh, yes, that's a way to make bzr-svn easier :) [06:04] Ubunut is fine [06:07] I know there's been discussion about packaging bzr-svn for Mac. [06:08] But I don't think it's happened yet. [06:10] ddaa: Feature request: progress bar for fetch. [06:10] bzrlib bug [06:11] What's that? [06:11] could be worked around using a custom interRepository [06:11] InterDifferingSerializer is the thing that lacks the progress bar [06:12] I run Ubuntu all over the place - mostly Xen. It's a great OS - but mostly because it came from great roots - debian. [06:12] duuude. That's my "last chance, you better be desperate" InterRepository that I wrote a month ago. [06:13] well, that's a perfect fit for this [06:13] I guess a custom InterRepo could be more efficient, but that's too much dark magic for me. [06:14] Just support .revision_tree() and a couple other things and it works [06:15] Well, we'll have to see about overcoming this dark magic thing at some point. [06:16] It works, sure, but it does whole-tree operations where it should really be doing per-change operations. [06:16] well.. the thing is git does not give us changes... [06:16] at least it's not it's natural medium [06:17] I guess it would be faster if we asked changes from git and fed them to bzrlib [06:18] Anyhow, it's still chugging away. [06:18] if you are trying it on git, do not run it all the whole history at first [06:18] it take a looooong time [06:19] it's fast enough for the 1000 first mainline revs [06:19] but at some point the inter-repo starts slogging seriously [06:21] Oh. Stopped. [06:21] So what, pull in groups? [06:21] with the recent optimizations, that should not make a huge difference [06:22] My latest commit does a good job of keeping the memory inflation slow. [06:22] Just use less data if you just want to play with it. [06:22] An interrepo that makes small write groups would be nice too. [06:23] So it could be interrupted in progress without losing the work. [06:23] like bzr-svn [06:24] That's interesting. [06:24] Of course, each write group is actually a pack, so you wouldn't want to do it too often. [06:24] doesn't bzr repack automatically? [06:25] I'm imagine that making small write groups would be less time-efficient, but that should not cause significant space waste. [06:25] Repack is on certain operations only. [06:26] IIUC [06:26] So after conversion, the next time you pulled, it would repack everything into one pack. [06:26] well, not big deal to add a repack at the end of the fetch [06:27] large numbers of packs reduces the efficiency of indexes a lot. [06:28] time efficiency, I should say. [06:29] anyway, there's a lot to gain now by making the interrepo smarter. [06:30] The viz is nice and zippy, though. [06:31] But I could have sworn that Git provided tree-delta output. [06:31] it certainly does [06:32] it's just that I would have no idea how to use it :) [06:34] also, it's more natural to start by working of trees and blobs [06:34] which are the building blocks of git [06:36] Well, earlier you said "the thing is that git does not give us changes..." [06:37] well [06:37] For my defence, it's 7:30 am here [06:37] I might not be entirely lucid [06:39] hehe [06:41] "git diff -p --raw --binary --full-index A B" might be something to look at [06:43] I think maybe branching from git should produce a Bazaar branch. What do you think? [06:43] sure [06:43] just found it easier to make pulling work at first [06:43] We're not going to support writing to git for a while anyhow, right? [06:44] that's a good working assumption [06:44] I would not bet on it when jelmer gets active, though :) [06:46] abentley: though you really should be working off my stable branch [06:46] the one with a test suite that actually passes :) [06:49] have fun, beddy time now [06:49] G'night. [06:50] ahah, just when I said that, my pull of all git just completed :) [06:50] you missed... [06:50] 17:49 -!- ddaa [n=ddaa@canonical/launchpad/ddaa] has quit ["Leaving."] [06:50] 17:49 < abentley> G'night. [06:50] 17:50 -!- ddaa [n=ddaa@canonical/launchpad/ddaa] has joined #bzr [06:51] Gratz [06:55] ddaa: got lightweight checkouts working [06:56] just needed a stub format, I guess? [06:56] Right. [06:56] checkouts of ? [06:56] lightweight checkout from a git repo [06:57] ddaa: And a cloning_metadir [12:46] New bug: #179368 in bzr "bug in lighttpd 1.4.18 makes bzr loop or issue too many requests" [Medium,In progress] https://launchpad.net/bugs/179368 [13:45] I'm having trouble getting pycrypto installed on a mac, will bzr+ssh do the same thing as sftp? [13:48] not afaik, I think bzr+ssh uses bzr's smartserver over ssh, where sftp just uses the sftp subsystem of ssh to transfer the branch [13:52] hrm, well I was able to checkout and commit over bzr+ssh without (knowingly) running smartserver [13:53] bzr+ssh will run the smart server on it's own, you just need to have bzr installed on the remote machine [13:53] so it seems bzr+ssh would work for me but I don't know if I'm missing anything by not using pycrypto [13:54] I see [13:54] I guess it uses openssh on mac [13:54] bzr+ssh? [13:54] pycrypto is only needed for paramiko, which is a python ssh-client implementation [13:54] bzr+ssh, sftp, anything ssh related [13:55] I can't use sftp because pycrypto isn't installed [13:55] and I'm having issues getting pycrypto installed =( [13:55] atleast sftp uses openssh or putty if it can find them I think, otherwise it tries using paramiko which uses pycrypto [13:55] well, just use bzr+ssh if it works for you [13:56] guess so, doesn't python have a psuedo package management system? setuptools or something? think I could install pycrypto with that? [13:57] setuptools isn't part of python itself, but you could try using it/easy_install if pycrypto's on pypi [13:57] what problems are you having with pycrypto btw? [13:58] `setup.py build` can't build [13:58] I run ubuntu myself but am borrowing my friends mac so we can get bzr setup [13:58] mind pastebinning the error? [13:59] macports failed miserably, python2.5, bzr and paramiko installed nicely but pycrypto has issues... [13:59] (http://rafb.net/paste is a good one if you don't know of any) [13:59] cool, one sec [14:01] Mm, I'm afraid I can't capture all of the output but after doing setup.py build > log, log tells me to check my Xcode version [14:01] I'm going to do that realy quick [14:01] brb [14:35] 'morning [14:42] hi === b6sfca_ is now known as b6sfca [16:56] TFKyle: Bazaar always uses Paramiko for the sftp protocol, even if the ssh connection uses OpenSSH or PuTTY. [17:12] hmm, I remember being able to branch from sftp:// before without having paramiko installed, parts of paramiko are in bzr or? [17:14] abentley: hmm, I remember being able to branch from sftp:// before without having paramiko installed, parts of paramiko are in bzr or? [17:14] (though that was back in the 0.1x days, havn't tried it recently without paramiko installed) [17:14] I can't see how that would be possible. [17:15] looking at the 1.0 sftp transport indeed it looks like it does need paramiko [17:27] guess I was remembering wrong, sorry [17:27] np [20:21] any reports about bzr 1.0 corrupting pack repos? [20:22] my 2 repos are corrupted [20:22] hmm, does cherrypicking merges (merge -c) "lose" history? [20:23] -r lose history, never used -c [20:24] bother [20:25] i think that -c is just syntax sugar for -r [20:25] right, so probably the same deal [20:37] bzr: ERROR: Revision {joerg@debian.org-20071229214821-h9rkdipixra914oe} not present in "". [20:37] ^-- umm - what? [20:38] (from trying to merge a bundle) [20:41] elmo: Your bundle is based on a revision not present in your repository [20:42] hsn_: I'm not aware of any corruption issues with pack repos. Please file bug reports. [20:43] abentley: ah, double bother. so don't cherry-pick with bundles then? [20:43] elmo: unless you're generating old bundles, cherry-picking should be fine. [20:44] abentley: 'old bundles'? [20:44] Format 0.9 or earlier. [20:45] abentley: I'm using bzr 1.0 on both sides, so I assume not [20:45] Not unless you're trying to. [20:45] So when you generate a merge directive, the contents of the bundle are whatever's needed to install the revisions into your submit branch. [20:45] abentley: the 'master' tree I'm trying to bzr merge into is at r993 or something. the other side, the guy has a bunch of changes, up to r1009. I want to bzr send, just revision 1009. which is what I tried, and what I failed - should that have been possible? [20:46] (as in, I did bzr send -r 1008..1009) [20:46] That should have been possible. [20:47] bzr doesn't love me today. [20:47] So what was the command you issued? [20:47] to send? [20:47] bzr send -r 1008..1009 -o /some/filename [20:47] then 'bzr merge /some/filename' on the other side [20:47] And what was your submit branch? [20:47] 'submit branch'? [20:48] The first argument to bzr send [20:48] * dato guesses "none" [20:48] it is the branch that you want to submit your changes to. [20:49] and then the default value got used, and maybe that was an intermediate branch which had up to r1008 or so [20:49]