| ubotu | New bug: #179314 in bzr "bzr reconfigure ctrl-C errors inappropriately" [Undecided,New] https://launchpad.net/bugs/179314 | 00:26 |
|---|---|---|
| ubotu | New bug: #179316 in bzr "bzr reconfigure is not order-safe" [Undecided,New] https://launchpad.net/bugs/179316 | 00:26 |
| lifeless | ddaa: what does 'remote' mean for branches ? | 00:53 |
| ddaa | lifeless: context? | 00:54 |
| lifeless | lp | 00:54 |
| lifeless | https://code.edge.launchpad.net/~lifeless/squid/squid3-trunk | 00:54 |
| ddaa | not copied on vostok | 00:54 |
| lifeless | oh foo | 00:54 |
| lifeless | what do I have to change to make it 'mirrored' and wouldn't 'not-mirrored' or 'reference-only' or something be clearer ? | 00:55 |
| ddaa | 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:55 |
| lifeless | I was meaning what db values :) | 00:56 |
| lifeless | branch details does not have a field for remote/mirror | 00:56 |
| ddaa | the should be a Branch.type column or somesuch now. | 00:56 |
| ddaa | with corresponding BranchType in c.l.i.Branch | 00:57 |
| ddaa | about the naming, I guess it would be better yes | 00:57 |
| ddaa | file a bug :) | 00:57 |
| ddaa | there's an annoying failure mode of changing the branch type in the UI that prevented from enabling it | 00:58 |
| ddaa | hosted -> mirror -> hosted can have unexpected effects | 00:58 |
| lifeless | don't have to allow all | 00:58 |
| lifeless | just allow mirror/remote | 00:58 |
| ddaa | sure | 00:59 |
| ddaa | sure... remote came up after that was considered | 00:59 |
| ddaa | not sure if it makes sense to allow as well | 00:59 |
| ddaa | since we should also delete data on mirror->remote | 00:59 |
| ddaa | unless the various front-ends just ignore remote branches | 01:00 |
| ddaa | then it should be okay, I think | 01:00 |
| lifeless | how do I tell it to mirror ? | 01:02 |
| lifeless | https://code.edge.launchpad.net/~lifeless/squid/squid3-trunk | 01:02 |
| lifeless | (next mirror: disabled) | 01:02 |
| lifeless | found it | 01:03 |
| lifeless | ok thanks | 01:04 |
| abentley | lifeless: just saw your bug report. Am very surprised that reconfigure would delete the repository if fetch failed. | 01:05 |
| lifeless | abentley: it may have just scribbled over the branch but left the repository intact | 01:06 |
| lifeless | ls .bzr/ | 01:06 |
| lifeless | branch branch-format branch-lock checkout README repository | 01:06 |
| lifeless | either way though, the target should be fully prepared before the local tree is altered I think | 01:06 |
| abentley | Ideally, the whole thing would be atomic. | 01:07 |
| distatica | 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 |
| distatica | using sftp provided by openssh server. | 01:07 |
| lifeless | distatica: if there is a .bzr directory it has worked | 01:08 |
| distatica | there is no directory | 01:08 |
| abentley | distatica: push isn't supposed to create any files. | 01:08 |
| lifeless | distatica: your editable files are not created on push | 01:08 |
| distatica | oh wait, there is too | 01:08 |
| distatica | ohh | 01:08 |
| distatica | so where are the files stored? Always locally? | 01:08 |
| abentley | The files are always local, for whatever machine bzr is running on. | 01:09 |
| distatica | oh, so if I switch to another computer then there's no way to get the files, without having them uploading seperately? | 01:10 |
| distatica | 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 |
| distatica | erm, hope == hop | 01:11 |
| abentley | If you switch to another computer, you'll branch from a remote copy. | 01:12 |
| Peng | distatica: All of the data is stored in the .bzr directory. | 01:12 |
| abentley | That will download everything you've committed, and recreate the working files from the committed data. | 01:12 |
| distatica | heh, I'm trying to see how this works, but I get an unknown branch format using the debian stable binary | 01:16 |
| distatica | debian etch* | 01:16 |
| Peng | distatica: You're using 1.0 on your other machine? | 01:18 |
| distatica | 0.11.0 | 01:18 |
| Peng | Dude. | 01:18 |
| Peng | That's like 75 years old. | 01:18 |
| distatica | lol | 01:18 |
| distatica | I don't doubt it, I think my grandfather worked a bit on etch packages. | 01:19 |
| distatica | I'm installing the one from the site now. | 01:19 |
| distatica | I was just trying to test it quickly | 01:19 |
| Peng | 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:21 |
| Peng | (0.15 is only from April, but still.) | 01:22 |
| abentley | Peng: "dirstate" used the same branch and repo format as "knit", so they were network-compatible with bzr back to 0.8. | 01:25 |
| distatica | 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 |
| abentley | It was only with "dirstate-tags" that we broke compatibility with older-than 0.15 | 01:26 |
| Peng | abentley: Oh, ok. | 01:27 |
| abentley | There are actually quite a lot of branches in older formats out there. | 01:27 |
| Peng | So that's why it's called "dirstatE". | 01:27 |
| Peng | distatica: There's Loggerhead, but it's pretty heavyweight (TurboGears). There's also bzr-webserve and bzrweb. Probably a Trac plugin too. | 01:27 |
| abentley | There is a trac plugin, but I don't recommend it. It's slow because trac and bzr have fundamentally different formats. | 01:28 |
| abentley | Peng: I don't see TurboGears as especially heavy. It's just a dependency and the install is dead easy. | 01:30 |
| distatica | Good to know though, since this is for shared hosting. | 01:30 |
| lifeless | abentley: FWIW it took about 6 hours to install turbogears on freebsd 5.5 | 01:30 |
| distatica | decent shared hosting (ruby on rails, php, python) but shared nonetheless. | 01:30 |
| lifeless | man-hours | 01:30 |
| abentley | lifeless: Ouch. Why? | 01:31 |
| lifeless | the dependency chain is deep | 01:31 |
| lifeless | something like 20 deeper module | 01:31 |
| lifeless | the ports tree only ships python 2.4 stuff for some, 2.5 for others, default python version is 2.5. | 01:32 |
| lifeless | freaking mess, I had to hand-update half the ports | 01:32 |
| lifeless | the ports use eggs not source tarballs, so projects that hadn't uploaded 2.5 eggs were bustificated too | 01:32 |
| abentley | I've done several clean installs lately, and I don't think they took longer than 10 minutes. | 01:32 |
| distatica | Can't find a whole lot about this bzrweb, found one site that looked like it's the one, but internal server errors. | 01:32 |
| lifeless | and the PEAK stuff just is too new to be packaged on BSD at all. | 01:33 |
| lifeless | distatica: what operating system are you using ? | 01:33 |
| abentley | Ah. This was just easy_installing, with no manual intervention. | 01:33 |
| distatica | 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:33 |
| * fullermd glances at the turbogears port. | 01:34 | |
| lifeless | distatica: etch should have a good turbogears package. | 01:34 |
| fullermd | Yeah, it looks messy. | 01:34 |
| distatica | lifeless: was interested in the other two, to see how they work and if they would run on my shared host. | 01:34 |
| distatica | installing dependencies is out of the question there. | 01:34 |
| abentley | distatica: You can install apps, but not their dependencies? | 01:35 |
| distatica | I can't install apps. I can install scripts, for viewing on the Internet. | 01:35 |
| distatica | PHP, Python, Ruby, but I can't just install python dependencies no. | 01:35 |
| jelmer | A | 01:36 |
| distatica | 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:38 |
| abentley | I don't think any of them are CGI scripts, if that's what you mean. | 01:40 |
| distatica | yeah, that's another (better) way of putting it. | 01:40 |
| abentley | One of them is a bzr plugin, IIRC. | 01:40 |
| abentley | Anything that views bzr repositories is going to need bzrlib, but bzrlib doesn't need to be *installed*, per se. | 01:41 |
| abentley | You can usually just stick a symlink to bzrlib in the root directory of the program that uses it. | 01:42 |
| distatica | that sounds like a neat trick | 01:42 |
| lifeless | back later | 01:43 |
| distatica | ok, thanks for the help | 01:44 |
| ubotu | New bug: #179325 in bzr "error with "bzr gcommit": 'NoneType' object has no attribute 'abort'" [Undecided,New] https://launchpad.net/bugs/179325 | 01:45 |
| fullermd | 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:46 |
| Peng | Loggerhead? | 01:53 |
| dlee | 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:15 |
| distatica | well, loggerhead was a good suggestion, didn't take too much time either, thanks. Looks nice. | 02:36 |
| abentley | Peng: I think fullermd was talking about FreeBSD TurboGears. | 02:44 |
| abentley | 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:45 |
| dlee | Could be set in bazaar.conf too I suppose | 02:46 |
| abentley | 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 |
| dlee | touche | 02:52 |
| abentley | Just don't use ^ to indicate aliases or zsh users will take you. All the good metacharacters are gone. | 02:53 |
| abentley | s/take/hate | 02:53 |
| dlee | leading @ ? I haven't thought this part out much. | 02:56 |
| dlee | I suppose a leading : could work too, unless there's an OS-specificism I've never seen | 02:58 |
| dlee | 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. :) | 03:00 |
| === b6sfca_ is now known as b6sfca | ||
| Peng | FWIW, hg uses branch aliases exactly like that. | 03:14 |
| CardinalFang | Hi all. | 03:22 |
| CardinalFang | Suppose I "bzr rm" a file and them commit. How can I then see the history for that file? | 03:24 |
| CardinalFang | "bzr log foo" says "bzr: ERROR: Path does not have any revision history: foo" | 03:24 |
| abentley | 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 | |
| ddaa | well... that's not a hugely common operation | 03:30 |
| abentley | Obviously, that should be fixed. | 03:31 |
| ddaa | hey abentley, I have a bzr-git that does pull | 03:31 |
| ddaa | not very fast, or very correctly | 03:31 |
| ddaa | but it does kind of works | 03:31 |
| abentley | ddaa: Hehe, but still, great. | 03:31 |
| ddaa | just added some sqlite so it runs out of memory later | 03:32 |
| mtaylor | anybody know if there's a good way to get the results of bzr log for a deleted file? | 03:36 |
| mtaylor | so like, if you wanted to find out when a file was deleted? | 03:36 |
| * Peng looks up at CardinalFang ten minutes ago. | 03:40 | |
| Peng | 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:41 |
| * 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 | |
| mtaylor | CardinalFang: did I miss the conversation about this? :) | 03:42 |
| CardinalFang | Yes. Sorry. | 03:43 |
| dlee | 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 |
| mtaylor | how funny | 03:43 |
| mtaylor | hi CardinalFang | 03:44 |
| abentley | ddaa: Wait, you're trying to make it run out of memory later? | 03:47 |
| ddaa | I mean later as in "not as early" | 03:48 |
| abentley | lol. Gotcha | 03:48 |
| ddaa | 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:39 |
| ddaa | or maybe I misinterpret the bzr check output | 04:40 |
| lifeless | checj is rubbish :) | 04:40 |
| ddaa | well, check and the install_revisions code | 04:40 |
| abentley | lifeless: Did you see my new merge algorithm? I'm still quite excited. | 04:48 |
| lifeless | abentley: don't think so; if its in bazaar-ng I'll see it wednesday | 04:51 |
| lifeless | or thuesday | 04:51 |
| abentley | Ah, you're been getting my mail because it's cc'ed to you. I thought you were reading the list. | 04:52 |
| abentley | In the non-criss-cross case, it behaves like 3-way. | 04:53 |
| abentley | In the criss-cross case, it should behave better than "weave". | 04:53 |
| abentley | So I think it could make mesh-merging basically painless. | 04:57 |
| lifeless | good | 05:00 |
| dysinger | hey | 05:13 |
| dysinger | 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:14 |
| dysinger | I like BZR UI - it's better than GIT. Help me out here. I have to work with SVN users. | 05:15 |
| dysinger | I have carefully compiled Subversion patched like bzr-svn says to. Insalled it to /usr/local | 05:15 |
| dysinger | in fact - here is my pastie of notes of EXACTLY what I have done http://pastie.caboo.se/133164 | 05:17 |
| dysinger | It's killing me. If BZR can't operate with svn EASILY then I have to toss it out. | 05:17 |
| dysinger | After my careful install - all I get is | 05:18 |
| dysinger | "Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details. | 05:18 |
| dysinger | Unable to load plugin 'svn' from '/Users/tim/.bazaar/plugins'" | 05:18 |
| dysinger | BZR by itself is cool. I like it better than GIT. I wish this would just work. | 05:19 |
| dysinger | Thanks for any help. | 05:19 |
| lifeless | there may be more detail in ~/.bzr.log | 05:20 |
| dysinger | ok one sec | 05:20 |
| dysinger | I appologize I am a Java & Ruby nerd. I don't speak the snake. | 05:22 |
| dysinger | http://pastie.caboo.se/133165 | 05:22 |
| lifeless | lines 8-15 | 05:23 |
| dysinger | http://pastie.caboo.se/133166 <- I think I have my path right for my custom subversion | 05:23 |
| lifeless | try python -c 'import svn; print svn.__file__' | 05:24 |
| dysinger | http://pastie.caboo.se/133167 | 05:24 |
| lifeless | thats the svn its loading | 05:25 |
| dysinger | 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 |
| lifeless | You also need a fairly recent version of the official Python bindings to the | 05:26 |
| lifeless | Subversion libraries. At the moment, the svn plugin only works with | 05:26 |
| lifeless | Subversion 1.5 (trunk). The python-subversion (not python-svn!) package | 05:26 |
| lifeless | thats from READ | 05:26 |
| lifeless | ME | 05:26 |
| dysinger | hmm - must have glossed over that. | 05:27 |
| dysinger | I went straight to the bottom of http://bazaar-vcs.org/BzrForeignBranches/Subversion | 05:27 |
| dysinger | Under Requirements and Subversion 1.4.3 w/ patch | 05:27 |
| lifeless | jelmer: ^ | 05:28 |
| dysinger | 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 |
| dysinger | but I appreciate the help | 05:32 |
| lifeless | once you build it once they can use binaries surely? | 05:32 |
| dysinger | Even if it's for my fun only. | 05:32 |
| dysinger | The OS X Leopard installer is so slick to for BZR 1.0 | 05:33 |
| dysinger | slick too | 05:33 |
| * dysinger compiling | 05:40 | |
| abentley | dysinger 1.5 coming out soon? | 05:45 |
| dysinger | I don't know - is it ? | 05:45 |
| abentley | I was joking about "dysinger copiling", as if you were a software product. | 05:46 |
| dysinger | ah :) | 05:46 |
| ddaa | I'm done with bzr-git hacking for this year. | 05:47 |
| ddaa | all my stuff is pushed on launcphad | 05:48 |
| ddaa | enjoy | 05:48 |
| dysinger | nice | 05:48 |
| dysinger | Well 1.5 trunk svn compiles ok but make chek-swig-py bombs | 05:48 |
| abentley | I'm afraid I can't help with that. My preferred platform has suitably patched bindings. | 05:52 |
| dysinger | bzr selftest svn fails :/ | 05:52 |
| abentley | ddaa: Cool. | 05:52 |
| dysinger | My preferred platform has 8 cores at 3GHZ and 16GB ram :) | 05:53 |
| dysinger | (new mac pro) | 05:53 |
| abentley | ddaa: what's interesting and in Git? | 05:53 |
| ddaa | xorg | 05:53 |
| ddaa | kernel | 05:53 |
| ddaa | samba | 05:53 |
| ddaa | small stuff nobody uses like that ;) | 05:53 |
| abentley | Yeah, so basically stuff I don't really have disk space for. | 05:54 |
| ddaa | well, git itself | 05:54 |
| ddaa | it's small enough | 05:54 |
| ddaa | though it does produces a >1GB git-cache | 05:55 |
| ddaa | all because bzrlib is too dumb to figure out inventory entry revisions by itself :( | 05:55 |
| dysinger | 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 |
| ddaa | lesse | 05:56 |
| dysinger | The SVN integration thing is not working for me even with 1.5 | 05:56 |
| ddaa | it works on windows | 05:56 |
| dysinger | yes that's a plus | 05:56 |
| ddaa | generally, it's more user-oriented | 05:56 |
| dysinger | yeah I like the UI better | 05:57 |
| ddaa | good user interface is not skin deep | 05:57 |
| dysinger | like in git git-checkout means like 3 different things | 05:57 |
| ddaa | I believe it support more workflows naturally, actually bzr in extremely flexible | 05:57 |
| ddaa | s/in/is/ | 05:57 |
| dysinger | (make a branch, switch working branches and replace files with original) | 05:58 |
| ddaa | really, bzr strong points all revolve around the user experience | 05:58 |
| dysinger | I don't like that - I like bzr's simple commands. | 05:58 |
| ddaa | it's *designed* to be nice to use | 05:59 |
| ddaa | while git is designed to be incredibly fast | 05:59 |
| dysinger | 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. | 05:59 |
| dysinger | I just can't get it to work with SVN :/ | 06:00 |
| ddaa | honestly, it's more a problem with svn | 06:00 |
| dysinger | yeah by itself BZR is very cool. | 06:00 |
| ddaa | jelmer had to write a bunch fixes to the python bindings | 06:00 |
| dysinger | I just have to work with remote svn - everybody uses svn. | 06:00 |
| ddaa | and they need to go through svn release process. | 06:00 |
| * dysinger understands | 06:01 | |
| ddaa | dysinger: if you do not have commit access, you could use launchpad's code import service. | 06:01 |
| ddaa | that does not work all the time, and that only import trunk, but that's often enough. | 06:01 |
| ddaa | oh, if you're a company | 06:02 |
| dysinger | that would work for personal and open source projects but not for client's code. | 06:02 |
| abentley | ddaa: is git-over-http supported? Or do I need to do the initial clone in git? | 06:02 |
| ddaa | abentley: it needs a local git | 06:02 |
| ddaa | I've been ranting a lot the past few days about how git:// is going to be a pain to support | 06:03 |
| ddaa | or git/http for that matter | 06:03 |
| ddaa | so, if you're a company | 06:03 |
| ddaa | you can talk to Canonical to get professional support for bzr. | 06:03 |
| abentley | Or you can run Ubunut in Parallels :-) | 06:04 |
| abentley | s/Ubunut/Ubuntu | 06:04 |
| ddaa | oh, yes, that's a way to make bzr-svn easier :) | 06:04 |
| ddaa | Ubunut is fine | 06:04 |
| abentley | I know there's been discussion about packaging bzr-svn for Mac. | 06:07 |
| abentley | But I don't think it's happened yet. | 06:08 |
| abentley | ddaa: Feature request: progress bar for fetch. | 06:10 |
| ddaa | bzrlib bug | 06:10 |
| abentley | What's that? | 06:11 |
| ddaa | could be worked around using a custom interRepository | 06:11 |
| ddaa | InterDifferingSerializer is the thing that lacks the progress bar | 06:11 |
| dysinger | 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 |
| abentley | duuude. That's my "last chance, you better be desperate" InterRepository that I wrote a month ago. | 06:12 |
| ddaa | well, that's a perfect fit for this | 06:13 |
| ddaa | I guess a custom InterRepo could be more efficient, but that's too much dark magic for me. | 06:13 |
| ddaa | Just support .revision_tree() and a couple other things and it works | 06:14 |
| abentley | Well, we'll have to see about overcoming this dark magic thing at some point. | 06:15 |
| abentley | It works, sure, but it does whole-tree operations where it should really be doing per-change operations. | 06:16 |
| ddaa | well.. the thing is git does not give us changes... | 06:16 |
| ddaa | at least it's not it's natural medium | 06:16 |
| ddaa | I guess it would be faster if we asked changes from git and fed them to bzrlib | 06:17 |
| abentley | Anyhow, it's still chugging away. | 06:18 |
| ddaa | if you are trying it on git, do not run it all the whole history at first | 06:18 |
| ddaa | it take a looooong time | 06:18 |
| ddaa | it's fast enough for the 1000 first mainline revs | 06:19 |
| ddaa | but at some point the inter-repo starts slogging seriously | 06:19 |
| abentley | Oh. Stopped. | 06:21 |
| abentley | So what, pull in groups? | 06:21 |
| ddaa | with the recent optimizations, that should not make a huge difference | 06:21 |
| ddaa | My latest commit does a good job of keeping the memory inflation slow. | 06:22 |
| ddaa | Just use less data if you just want to play with it. | 06:22 |
| ddaa | An interrepo that makes small write groups would be nice too. | 06:22 |
| ddaa | So it could be interrupted in progress without losing the work. | 06:23 |
| ddaa | like bzr-svn | 06:23 |
| abentley | That's interesting. | 06:24 |
| abentley | Of course, each write group is actually a pack, so you wouldn't want to do it too often. | 06:24 |
| ddaa | doesn't bzr repack automatically? | 06:24 |
| ddaa | I'm imagine that making small write groups would be less time-efficient, but that should not cause significant space waste. | 06:25 |
| abentley | Repack is on certain operations only. | 06:25 |
| abentley | IIUC | 06:26 |
| abentley | So after conversion, the next time you pulled, it would repack everything into one pack. | 06:26 |
| ddaa | well, not big deal to add a repack at the end of the fetch | 06:26 |
| abentley | large numbers of packs reduces the efficiency of indexes a lot. | 06:27 |
| abentley | time efficiency, I should say. | 06:28 |
| ddaa | anyway, there's a lot to gain now by making the interrepo smarter. | 06:29 |
| abentley | The viz is nice and zippy, though. | 06:30 |
| abentley | But I could have sworn that Git provided tree-delta output. | 06:31 |
| ddaa | it certainly does | 06:31 |
| ddaa | it's just that I would have no idea how to use it :) | 06:32 |
| ddaa | also, it's more natural to start by working of trees and blobs | 06:34 |
| ddaa | which are the building blocks of git | 06:34 |
| abentley | Well, earlier you said "the thing is that git does not give us changes..." | 06:36 |
| ddaa | well | 06:37 |
| ddaa | For my defence, it's 7:30 am here | 06:37 |
| ddaa | I might not be entirely lucid | 06:37 |
| abentley | hehe | 06:39 |
| ddaa | "git diff -p --raw --binary --full-index A B" might be something to look at | 06:41 |
| abentley | I think maybe branching from git should produce a Bazaar branch. What do you think? | 06:43 |
| ddaa | sure | 06:43 |
| ddaa | just found it easier to make pulling work at first | 06:43 |
| abentley | We're not going to support writing to git for a while anyhow, right? | 06:43 |
| ddaa | that's a good working assumption | 06:44 |
| ddaa | I would not bet on it when jelmer gets active, though :) | 06:44 |
| ddaa | abentley: though you really should be working off my stable branch | 06:46 |
| ddaa | the one with a test suite that actually passes :) | 06:46 |
| ddaa | have fun, beddy time now | 06:49 |
| abentley | G'night. | 06:49 |
| ddaa | ahah, just when I said that, my pull of all git just completed :) | 06:50 |
| lifeless | you missed... | 06:50 |
| lifeless | 17:49 -!- ddaa [n=ddaa@canonical/launchpad/ddaa] has quit ["Leaving."] | 06:50 |
| lifeless | 17:49 < abentley> G'night. | 06:50 |
| lifeless | 17:50 -!- ddaa [n=ddaa@canonical/launchpad/ddaa] has joined #bzr | 06:50 |
| abentley | Gratz | 06:51 |
| abentley | ddaa: got lightweight checkouts working | 06:55 |
| ddaa | just needed a stub format, I guess? | 06:56 |
| abentley | Right. | 06:56 |
| lifeless | checkouts of ? | 06:56 |
| abentley | lightweight checkout from a git repo | 06:56 |
| abentley | ddaa: And a cloning_metadir | 06:57 |
| ubotu | 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 | 12:46 |
| sandrot | I'm having trouble getting pycrypto installed on a mac, will bzr+ssh do the same thing as sftp? | 13:45 |
| TFKyle | 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:48 |
| sandrot | hrm, well I was able to checkout and commit over bzr+ssh without (knowingly) running smartserver | 13:52 |
| luks | bzr+ssh will run the smart server on it's own, you just need to have bzr installed on the remote machine | 13:53 |
| sandrot | so it seems bzr+ssh would work for me but I don't know if I'm missing anything by not using pycrypto | 13:53 |
| sandrot | I see | 13:54 |
| luks | I guess it uses openssh on mac | 13:54 |
| sandrot | bzr+ssh? | 13:54 |
| luks | pycrypto is only needed for paramiko, which is a python ssh-client implementation | 13:54 |
| luks | bzr+ssh, sftp, anything ssh related | 13:54 |
| sandrot | I can't use sftp because pycrypto isn't installed | 13:55 |
| sandrot | and I'm having issues getting pycrypto installed =( | 13:55 |
| TFKyle | atleast sftp uses openssh or putty if it can find them I think, otherwise it tries using paramiko which uses pycrypto | 13:55 |
| luks | well, just use bzr+ssh if it works for you | 13:55 |
| sandrot | guess so, doesn't python have a psuedo package management system? setuptools or something? think I could install pycrypto with that? | 13:56 |
| TFKyle | setuptools isn't part of python itself, but you could try using it/easy_install if pycrypto's on pypi | 13:57 |
| TFKyle | what problems are you having with pycrypto btw? | 13:57 |
| sandrot | `setup.py build` can't build | 13:58 |
| sandrot | I run ubuntu myself but am borrowing my friends mac so we can get bzr setup | 13:58 |
| TFKyle | mind pastebinning the error? | 13:58 |
| sandrot | macports failed miserably, python2.5, bzr and paramiko installed nicely but pycrypto has issues... | 13:59 |
| TFKyle | (http://rafb.net/paste is a good one if you don't know of any) | 13:59 |
| sandrot | cool, one sec | 13:59 |
| sandrot | 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 |
| sandrot | I'm going to do that realy quick | 14:01 |
| sandrot | brb | 14:01 |
| jelmer | 'morning | 14:35 |
| sandrot | hi | 14:42 |
| === b6sfca_ is now known as b6sfca | ||
| abentley | TFKyle: Bazaar always uses Paramiko for the sftp protocol, even if the ssh connection uses OpenSSH or PuTTY. | 16:56 |
| TFKyle | hmm, I remember being able to branch from sftp:// before without having paramiko installed, parts of paramiko are in bzr or? | 17:12 |
| TFKyle | abentley: <TFKyle> hmm, I remember being able to branch from sftp:// before without having paramiko installed, parts of paramiko are in bzr or? | 17:14 |
| TFKyle | (though that was back in the 0.1x days, havn't tried it recently without paramiko installed) | 17:14 |
| abentley | I can't see how that would be possible. | 17:14 |
| TFKyle | looking at the 1.0 sftp transport indeed it looks like it does need paramiko | 17:15 |
| TFKyle | guess I was remembering wrong, sorry | 17:27 |
| abentley | np | 17:27 |
| hsn_ | any reports about bzr 1.0 corrupting pack repos? | 20:21 |
| hsn_ | my 2 repos are corrupted | 20:22 |
| elmo | hmm, does cherrypicking merges (merge -c) "lose" history? | 20:22 |
| hsn_ | -r lose history, never used -c | 20:23 |
| elmo | bother | 20:24 |
| hsn_ | i think that -c is just syntax sugar for -r | 20:25 |
| elmo | right, so probably the same deal | 20:25 |
| elmo | bzr: ERROR: Revision {joerg@debian.org-20071229214821-h9rkdipixra914oe} not present in "<bzrlib.knit.KnitGraphIndex object at 0x2b03534e0c50>". | 20:37 |
| elmo | ^-- umm - what? | 20:37 |
| elmo | (from trying to merge a bundle) | 20:38 |
| abentley | elmo: Your bundle is based on a revision not present in your repository | 20:41 |
| abentley | hsn_: I'm not aware of any corruption issues with pack repos. Please file bug reports. | 20:42 |
| elmo | abentley: ah, double bother. so don't cherry-pick with bundles then? | 20:43 |
| abentley | elmo: unless you're generating old bundles, cherry-picking should be fine. | 20:43 |
| elmo | abentley: 'old bundles'? | 20:44 |
| abentley | Format 0.9 or earlier. | 20:44 |
| elmo | abentley: I'm using bzr 1.0 on both sides, so I assume not | 20:45 |
| abentley | Not unless you're trying to. | 20:45 |
| abentley | 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 |
| elmo | 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:45 |
| elmo | (as in, I did bzr send -r 1008..1009) | 20:46 |
| abentley | That should have been possible. | 20:46 |
| elmo | bzr doesn't love me today. | 20:47 |
| abentley | So what was the command you issued? | 20:47 |
| abentley | to send? | 20:47 |
| elmo | bzr send -r 1008..1009 -o /some/filename | 20:47 |
| elmo | then 'bzr merge /some/filename' on the other side | 20:47 |
| abentley | And what was your submit branch? | 20:47 |
| elmo | 'submit branch'? | 20:47 |
| abentley | The first argument to bzr send | 20:48 |
| * dato guesses "none" | 20:48 | |
| abentley | it is the branch that you want to submit your changes to. | 20:48 |
| dato | and then the default value got used, and maybe that was an intermediate branch which had up to r1008 or so | 20:49 |
| abentley | dato: It can't be none if the send succeeded. | 20:49 |
| dato | abentley: none explicitly mentioned in the command line, I meant | 20:49 |
| elmo | oh, I see | 20:49 |
| elmo | so I need to bzr send with a submit branch of what I call 'master'? | 20:49 |
| abentley | The submit branch is used to decide what revisions are needed in the bundle. | 20:49 |
| abentley | It needs to have a subset of the revisions in master. | 20:50 |
| dato | abentley: (as a side note, mergin such bundle causes a cherrypick anyway, no? that is, that no merged revision show up in commit) | 20:50 |
| abentley | dato: It depends on whether you have the cherrypick base. | 20:50 |
| abentley | If it is possible to do a non-cherry-pick merge, bzr will. | 20:51 |
| elmo | ok, so using a submit branch worked, thanks | 20:51 |
| abentley | great. | 20:52 |
| elmo | of course, it's still a cherry pick, so my unsubtle attempt to work around losing merge history failed entirely ;-) | 20:52 |
| dato | under what circumstances is that possible? the picture I have in mind is master "r1 - r2", feature "r1 - r2 - r3 - r4", bzr send -r 3..4 | 20:52 |
| abentley | A scenario where it's possible is master "r1-r3", feature "r1 - r2 - r3 - r4", bzr send -r 3..4 | 20:53 |
| abentley | elmo: I believe bzr 1.1 will attempt to download the missing revisions from your submit branch for you. | 20:54 |
| elmo | abentley: the missing revisions aren't in the submit branch though, and I don't actually want them - if you see what I mean? | 20:55 |
| abentley | It will install them into your repository so that the cherrypick works. | 20:56 |
| dato | elmo: "don't actually want them" <-- in your branch, you wouldn't mind them being in your repository | 20:57 |
| abentley | It won't do a full merge or anything. | 20:57 |
| elmo | aha! | 20:57 |
| elmo | I see what you mean. that'd be lovely | 20:57 |
| dato | abentley: what happens if you later merge the full branch? (r993 .. r1009) | 20:58 |
| abentley | Well, a three-way merge doesn't do *too* badly if you haven't changed the bits you cherrypicked. | 20:58 |
| abentley | Especially if you merge --reprocess. | 20:59 |
| abentley | If you've changed the bits you cherrypicked, you'll get conflicts. | 21:00 |
| abentley | elmo: I'm sorry that we can't yet represent a cherrypick in our metadata. It is something we plan to support. | 21:02 |
| elmo | abentley: no problem, it's a relatively minor detail - if it's on your (collective) radar to fix, I'm more than happy | 21:02 |
| hsn_ | !pastebin | 21:14 |
| ubotu | pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) | 21:14 |
| hsn_ | abentley: http://paste.ubuntu-nl.org/50171/ | 21:16 |
| * dato wonders *why* *on* *earth* reporting malicious content in that pastebin is done *just by following a link* | 21:19 | |
| hsn_ | because spam bots will self-cancel? | 21:20 |
| dysinger | So sorry to interrupt any conversations. Just wanted to ask more questions. I think I have pretty much exhausted all reasonable attempts at pushing / pulling to svn with a mac and bzr 1.0. I can't do any direct imports either both branches of svn2bzr are broken on my 128MB 6 month old repository. So I have yet to find a way to use my existing project in bzr that's not a time-sync and hassle for me (being new to bzr). Just some feedback | 21:21 |
| jelmer | hi dysinger | 21:22 |
| jelmer | dysinger: you were the guy having problems patching python-subversion, no? | 21:22 |
| dysinger | The patch applied cleanly to 1.4 subversion but then I just kept getting "No Python bindings for Subversion installed. See the bzr-svn README for details. Unable to load plugin 'svn' from '/root/.bazaar/plugins'" | 21:23 |
| dysinger | So I tried 1.5 trunk last night but it didn't compile so smooth. | 21:23 |
| dysinger | I really like BZR so this isn't critique | 21:23 |
| jelmer | There were a couple of people that reported that installing a patched subversion on Mac OS X would install to a differnet location | 21:23 |
| jelmer | can you run the following: | 21:24 |
| dysinger | I tried patching and installing it to $HOME like I do everything else and I also did /usr/local with same result. | 21:24 |
| jelmer | python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler" | 21:25 |
| dysinger | OS X Leopard comes with libsvn and svn for python 2.5 preinstalled. I tried to make sure my path was straight so that my /usr/local bindings loaded first | 21:25 |
| dysinger | I get False from that - I have been using it as a test from your source. | 21:25 |
| jelmer | and does this give a location you expect: | 21:26 |
| dysinger | y | 21:26 |
| jelmer | python -c "import svn.delta; print svn.delta.__file__" | 21:26 |
| dysinger | gives me /usr/local... | 21:26 |
| jelmer | dysinger: did building subversion rerun SWIG? | 21:27 |
| dysinger | I am trying to gather notes and be helpful if I can too. I always do that on my blog (mostly ruby stuff) http://dysinger.net so if I can figure it out and put together a bash-notes script I will post it there. I am trying to do this without macports, fink etc - I prefer from scratch. | 21:28 |
| * jelmer wonders if the Subversion sources comes with prebuilt versions of the Python bindings | 21:28 | |
| dysinger | Yes I rebuilt SWIG and ran the SWIG tests. | 21:28 |
| dysinger | before install | 21:28 |
| jelmer | did you run install-swig-py ? | 21:28 |
| dysinger | y | 21:28 |
| dysinger | (testing it before hand) | 21:29 |
| dysinger | 1.5 trunk fails those tests | 21:29 |
| dysinger | 1.4 is fine. | 21:29 |
| jelmer | and grepping for svn_delta_invoke_txdelta_window_handler in /usr/local/ returns the right python file? | 21:29 |
| dysinger | this installs libsvn* in /usr/local/lib along with SWIG stuff in /usr/local/svn-python/ | 21:29 |
| dysinger | one sec | 21:29 |
| jelmer | how are you trying to run bzr to make sure that it loads the right bindings? | 21:30 |
| dysinger | just trying to branch something | 21:30 |
| dysinger | like bzr branch http://macromates.com/svn/Bundles/trunk/ textmate-bundles | 21:30 |
| dysinger | and it always gripes about the bindings | 21:31 |
| jelmer | dysinger: it probably loads the system-provided bindings for python-subversion then though | 21:31 |
| jelmer | rather than the ones in /usr/local | 21:31 |
| dysinger | I went to the bzr_svn code in __init__ and pulled out your checks and just did them at the command line | 21:31 |
| dysinger | and it always fails no matter what I do | 21:31 |
| dysinger | I checked my PYTHONPATH too | 21:31 |
| dysinger | jelmer: I think you are right. | 21:32 |
| jelmer | can you try setting the PYTHONPATH manually? E.g.: PYTHONPATH=/usr/local/lib/svn-python python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler" | 21:32 |
| dysinger | but python -c "import svn.delta; print svn.delta.__file__" returns the right file | 21:32 |
| dysinger | yes give me a minute to reinstall 1.4 like I had it. | 21:32 |
| jelmer | it may actually be loading the python file from the right location but the corresponding shared library from the wrong location. or something. | 21:33 |
| dysinger | y | 21:33 |
| jelmer | dysinger: still there? | 21:38 |
| dysinger | y | 21:38 |
| dysinger | sorry re-installing it real quick | 21:38 |
| * dysinger feels stupid now. | 21:40 | |
| dysinger | oh man I think I figured it out and I am an embarrassed dumb-ass - lol - sorry - in my efforts to automate everything via a script and deprive myself of sleep, I wasn't applying the patch correctly :/ | 21:40 |
| dysinger | sorry | 21:40 |
| jelmer | :-/ | 21:42 |
| jelmer | well, at least you did find it now :-) | 21:42 |
| lifeless | just highlights the need for a package IMO :) | 21:42 |
| dysinger | gaahhh I wasted sooo much time on that. | 21:42 |
| jelmer | afaik phanatic and erik are working on that | 21:43 |
| dysinger | y I will paste my notes on my blog asap and you can pull them off for mac folks if you want. | 21:43 |
| jelmer | dysinger: feel free to just add a link to the wiki | 21:43 |
| dysinger | k | 21:43 |
| jelmer | hi schierbeck | 21:54 |
| jelmer | schierbeck: There was somebody from the tango team around a couple of days ago | 21:54 |
| jelmer | Asking about icons for bzr-gtk | 21:55 |
| jelmer | There is a thread about it on the bzr-gtk mailing list, any input would be welcome :-) | 21:55 |
| schierbeck | jelmer: hi! | 21:55 |
| schierbeck | yeah, i talked to a guy named Cube some time ago | 21:56 |
| dysinger | well I feel less like a dumbass now. It still doesn't work. I don't want to waste a bunch of your time. Could you look at my notes and results here http://pastie.caboo.se/133339 for a second ? | 21:56 |
| schierbeck | he started working on some icons, but he never really got around to finishing them | 21:56 |
| dysinger | I wonder if it's the patch? I see everything installs correctly. The patch doesn't complain. It finds the right svn.delta.__file__ but it doesn't have the svn_delta_invoke_txdelta_window_handler | 22:01 |
| * dysinger sighs | 22:10 | |
| jelmer | schierbeck: yep, that's the one | 23:05 |
| jelmer | schierbeck: he sent mail to the list, did you see it? | 23:06 |
| schierbeck | jelmer: yup | 23:07 |
| schierbeck | was busy with exams and all the christmas stuff | 23:07 |
| schierbeck | we really need those icons | 23:07 |
| jelmer | no worries :-) | 23:07 |
| jelmer | Some comments would be nice though | 23:07 |
| sam1234 | Hello people? Can I ask some question about bazaar? | 23:09 |
| jelmer | sure | 23:11 |
| sam1234 | ok. So I have a problem with user id... | 23:12 |
| sam1234 | bzr whoami MyName tell my name | 23:13 |
| sam1234 | but... | 23:13 |
| sam1234 | When i tried to change it, for example: bzr whoami MyNewName | 23:13 |
| sam1234 | commits, that I have done still have my old name. | 23:14 |
| jelmer | yes, it only works for commits you are doing since the chance | 23:14 |
| jelmer | you can not alter existing commits | 23:14 |
| sam1234 | I have spend some time to find some solutions, but with no result. The problem... | 23:16 |
| sam1234 | for me is that when I change my e-mail, then people that try to contact me by my old e-mail will be confused | 23:16 |
| jelmer | sorry | 23:17 |
| jelmer | that's the way it works | 23:17 |
| sam1234 | I looked at .bzr directory but changing something by hand result error. | 23:18 |
| sam1234 | Do you know some VCS that don't have this limit? | 23:18 |
| jelmer | sam1234: even if bazaar would uspport it | 23:19 |
| jelmer | how would it be able to do that? | 23:20 |
| jelmer | I don't think there are any other systems out there that do support it | 23:20 |
| sam1234 | Sorry, I don't know much about VCS, that's why ask. This is feature that could be usful for me, but isn't so important. | 23:22 |
| sam1234 | So if this can't be done, I still can live. | 23:23 |
| sam1234 | Name is constant, only e-mail will be changed. | 23:23 |
| sam1234 | thanks for you time jelmer. Best regards. | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!