| james_w | hey vila | 00:00 |
|---|---|---|
| james_w | welcome back, good to see you | 00:00 |
| jam | lifeless: the problem is that once you sign up for a bazaar-vcs account, the first link it gives you is your personal page, and then you follow it and it wants to create it for you. | 00:06 |
| jam | So the *sign-up* procedure encourages it | 00:06 |
| lifeless | yes | 00:07 |
| lifeless | I wonder which page to edit to fix that | 00:07 |
| jam | lifeless: I'll try to ping newz tomorrow to ask | 00:08 |
| jam | lifeless: do you think there might be an obvious way to make the 'three_level' test go faster? | 00:09 |
| jam | 60s for a test is a bit ugly | 00:09 |
| jam | I guess it is 68s, and iter_all is 81s | 00:09 |
| lifeless | well | 00:09 |
| lifeless | make the code faster :) | 00:10 |
| jam | I'm at least tempted to profile it and see if there is anything obvious | 00:10 |
| lifeless | on the dirstate corruption | 00:11 |
| lifeless | the change I'm proposing for locks should help that too :P | 00:11 |
| jam | there are lots of ways around it | 00:12 |
| jam | just getting rid of the write-in-place will help | 00:13 |
| jam | however we go about it | 00:13 |
| jam | assuming it is the truncate() causing the problem | 00:13 |
| lifeless | yah | 00:14 |
| lifeless | thats true | 00:14 |
| technomancy | does bzr support inline branches? | 00:20 |
| lifeless | I don't know what that means | 00:21 |
| technomancy | it means creating a new branch in the same directory and being able to switch between them without changing directories | 00:22 |
| bob2 | no to git-style branches, yes to switching one working copy between branches in a repository | 00:25 |
| technomancy | gotcha | 00:25 |
| lifeless | technomancy: we have a bzr switch command that can switch branches in a single working dir | 00:26 |
| lifeless | technomancy: and we have cheap branches (they are 'bare' - no source files) | 00:26 |
| technomancy | so if I've got my own branch checked out in one directory and a friend's checked out in another, I can't exactly just "bzr diff" them, can I... how does that work? | 00:27 |
| lifeless | bzr diff -r branch:otherdir | 00:28 |
| technomancy | aha; thanks! | 00:28 |
| technomancy | I heard Emacs was planning on migrating to bzr, does anyone know how that's going? | 00:32 |
| technomancy | nobody in #emacs seems to know; heh. | 00:32 |
| mwhudson | there's a bzr mirror of the emacs trunk | 00:33 |
| technomancy | yeah, but afaik that's still all unofficial | 00:33 |
| mwhudson | and i think there are some performance concerns, at least some of which are fixed | 00:33 |
| mwhudson | but i guess right now a whole lot of nothing is happening :) | 00:33 |
| technomancy | right; it sounded like they were waiting for some more perf fixes... Emacs is one of the oldest extant projects in any version control system, so it makes sense that it would be a good deal more taxing than your average launchpad project. =) | 00:34 |
| mwhudson | it's not actually that big | 00:35 |
| mwhudson | it's only 80k mainline revisions or something | 00:35 |
| mwhudson | which, yeah, is on the large end, but it's nothing compared to OOo :) | 00:35 |
| technomancy | interesting. Yeah I was thinking more in terms of years than any actual measurements I had read. | 00:36 |
| mwhudson | oh probably yes | 00:37 |
| technomancy | can you diff with a branch straight from launchpad that you haven't checked out locally yet? | 01:13 |
| technomancy | oh wait, I think I can figure that out. | 01:13 |
| technomancy | yup, that worked | 01:14 |
| technomancy | is there any way to automate file downloads when you cut a new release in launchpad, or do you have to create your tar/zip files manually and upload them through the web interface? | 01:16 |
| james_w | technomancy: that last question may be better asked in #launchpad | 01:17 |
| technomancy | oh, of course | 01:17 |
| james_w | I don't know the answer myself, sorry | 01:17 |
| lifeless | jam: don't suppose you are still around ? | 03:06 |
| === mw is now known as mw|out | ||
| jml | lifeless: got an eta for reviewing https://code.edge.launchpad.net/~jml/testresources/tests-meaning-cleanup? | 03:44 |
| lifeless | 'soon' | 03:52 |
| lifeless | whee | 03:58 |
| lifeless | 10 second saving on cold-cache stat | 03:58 |
| jml | lifeless: fair enough | 04:04 |
| jml | lifeless: also, 10s on cold-cache is pretty good. | 04:04 |
| jml | lifeless: if you have a look at the TODO file I've added, then that'll unblock me for further work. | 04:05 |
| lifeless | jml: 1m5 to 53 seconds | 04:05 |
| lifeless | jml: k | 04:05 |
| jml | lifeless: does the saving translate to hot-cache? | 04:06 |
| lifeless | maybe | 04:08 |
| lifeless | call for testers coming this afternoon | 04:08 |
| jml | heh | 04:08 |
| jml | lifeless: well, I'm offline until this evening. maybe I'll talk to you then. | 04:08 |
| lifeless | okies | 04:11 |
| === samurai is now known as samiam | ||
| xshelf | can you have the bazaar mailing list available on www.opensubscriber.com | 04:50 |
| xshelf | it really has a cool (soothing) interface to reading mailing lists | 04:50 |
| xshelf | anyone here personally interested in brz-perforce-bzr interface? | 04:51 |
| * jamesh hasn't had to use p4 since 2001 and is happy to keep it that way | 04:54 | |
| lifeless | xshelf: you can probably get bazaar on opensubscriber yourself | 04:55 |
| xshelf | lifeless: The mail I send to bazaar for subscription requires auth confirmation which opensubscriber does not support | 04:55 |
| xshelf | lifeless: So, the list maint needs to bypass confirmation for this mail address | 04:56 |
| lifeless | oh | 04:56 |
| jamesh | I guess that is a way of only archiving lists with admin approval | 04:57 |
| xshelf | you can also reply to author or group with that interface | 04:58 |
| xshelf | with Yahoo supporting only 15 filters, I run out of filter space if I subscribe to multiple lists! | 04:59 |
| xshelf | Hence, I prefer a one stop shop of reading lists | 05:00 |
| mwhudson | man we're going to get a lot of mail when aaron gets back and restarts bb | 05:30 |
| bob2 | gmane! | 05:40 |
| === wantok is now known as `6og | ||
| chmac | I'm not clear from http://bazaar-vcs.org/NestedTreeSupport on the status of nested tree support. I'm reading posts from early 2007 which say it's "soon"... | 06:34 |
| chmac | Can anyone give me a more up to date view? | 06:34 |
| chmac | Ok, this seems like what I'm after http://bazaar-vcs.org/NestedTreeProgress | 06:36 |
| chmac | Last update was May 07 though, anyone know if any progress has been made since then? | 06:37 |
| beuno | chmac, yeah, that hasn't happened yet | 06:37 |
| beuno | you can ping LarstiQ | 06:37 |
| beuno | and make him feel guilty about it | 06:37 |
| beuno | that's what I do | 06:37 |
| chmac | :) | 06:37 |
| chmac | LarstiQ: Nested Tree support? When's it gonna happen? :) | 06:37 |
| beuno | maybe even email the list to get the subject re-started | 06:38 |
| chmac | beuno: I'm considering bzr vs svn for a new project. | 06:38 |
| chmac | It's managing WordPress installations, and keeping the up to date | 06:38 |
| chmac | So I was thinking to use nested trees to keep the plugins up to date | 06:38 |
| beuno | chmac, well, we have something really cool, which is the "bzr-upload" plugin | 06:38 |
| chmac | I only need very basic support, to add a nested tree, to update it to the latest version, and then to roll it back to a previous version if necessary | 06:38 |
| chmac | beuno: Cool, let me check that out... | 06:39 |
| beuno | which will let you upload *just* the working tree, and *just* what has changed since the last upload | 06:39 |
| beuno | right, nested trees don't currently work, so I wouldn't go down that path just yet | 06:39 |
| chmac | beuno: Ok, bzr-upload looks very interesting | 06:40 |
| chmac | It would allow me to keep the code in one central location, and push updates selectively to remote hosts | 06:40 |
| beuno | chmac, and not just because I'm onw of the authors. It actually works :) | 06:40 |
| chmac | That might bypass my need for nested trees, as I could simply push plugins separately | 06:40 |
| chmac | :) | 06:40 |
| beuno | chmac, yeap, that's the idea. Mainly aimed at web-dev | 06:40 |
| chmac | https://launchpad.net/bzr-upload/+download: | 06:41 |
| chmac | No download files exist for this project. | 06:41 |
| beuno | chmac, yeah, we haven't made an official release (will soon) | 06:41 |
| beuno | so, to install it: mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload | 06:42 |
| beuno | if you're on linux | 06:42 |
| chmac | Ubuntu :) | 06:42 |
| beuno | cool, the above should work then | 06:42 |
| beuno | and you're set | 06:42 |
| chmac | beuno: Will it allow me to push a previous revision without rolling back my "working copy" ? | 06:43 |
| beuno | chmac, yeap, just specify -r X | 06:43 |
| chmac | :) | 06:43 |
| beuno | and, if you find you need features that aren't there, file bugs, we'll get it done :) | 06:43 |
| chmac | beuno: Now that's what I want to hear! :) | 06:44 |
| chmac | It's checking out now... | 06:44 |
| chmac | beuno: Will it support ssh host definitions? So sftp://blah/some/path/ ? Automatically picking up my ssh key and so on? | 06:47 |
| chmac | beuno: When I run `bzr help upload` the first line is "Unable to load plugin 'upload' from '/home/me/.bazaar/plugins'" | 06:48 |
| chmac | Yet it outputs the help just fine... | 06:48 |
| beuno | chmac, how odd... | 06:48 |
| beuno | can you take a peak in ~/.bzr.log? | 06:49 |
| beuno | you should have a traceback | 06:49 |
| chmac | beuno: http://pastebin.com/d4cc40f5f | 06:51 |
| beuno | chmac, what version fo bzr are you using? | 06:51 |
| beuno | smells old | 06:51 |
| chmac | Bazaar (bzr) 1.3.1, latest in Ubuntu 8.04 | 06:51 |
| beuno | chmac, hrmm... mind filing a bug that it doesn't work with 1.3.1, and upgrading to 1.6rc3? https://launchpad.net/~bzr/+archive | 06:52 |
| chmac | beuno: Happy to file a bug. It does actually produce the output ok though. | 06:53 |
| chmac | Shall I try a test upload to see if it works? | 06:54 |
| beuno | chmac, yeah, it will work. It's the "auto" feature that won't. | 06:54 |
| chmac | Ok | 06:54 |
| beuno | chmac, I'll file the bug, don't worry | 06:54 |
| beuno | upgrade, and the message will be gone | 06:54 |
| chmac | beuno: Ok, great, if you need anything else from me, just let me know | 06:54 |
| beuno | chmac, you've already found a bug, plenty help already :) | 06:55 |
| chmac | :) | 06:55 |
| beuno | chmac, bug #259647 if you want to subscribe | 06:57 |
| ubottu | Launchpad bug 259647 in bzr-upload "auto feature doesn't work with older bzr versions and tracebacks" [Undecided,New] https://launchpad.net/bugs/259647 | 06:57 |
| chmac | beuno: nice, just subscribed, and running `apt-get update` to install the latest bazaar, thanks for all this | 06:59 |
| beuno | chmac, happy to help, and, especially, welcome new users :) | 06:59 |
| chmac | Looks like the Thai ubuntu mirror is out of date, time to find an alternative... | 07:01 |
| beuno | it should download from PPA, not ubuntu mirrors | 07:01 |
| chmac | beuno: Yeah, but the `apt-get update` was failing because of a mirror issue | 07:02 |
| chmac | Seems to be running ok now against Taiwan :) | 07:02 |
| jpds | chmac: A list of Ubuntu archive mirrors may be found here: https://launchpad.net/ubuntu/+archivemirrors | 07:03 |
| chmac | jpds: System > Software Sources has a neat tool which checks the mirrors and determines which one is fastest, turns out Taiwan is faster than Thailand in Bangkok :) | 07:03 |
| beuno | yeah, I use brazil | 07:04 |
| jpds | chmac: Oh, that's neat. Didn't know that. | 07:04 |
| beuno | chmac, I'm off for the night. Good luck with that, and feel free to hang around here and ask questions. Everyone is very friendly here :) | 07:10 |
| chmac | beuno: Thanks again :) | 07:11 |
| gour | morning | 07:24 |
| gour | is there release date scheduled for 1.6? | 07:24 |
| thumper | gour: btw, doing a branch of ghc inside a shared repo (generating a tree) takes about 6s without hardlinks | 07:26 |
| * thumper is away | 07:26 | |
| gour | thumper: heh | 07:26 |
| markh | kinda off-topic, but can anyone lend me a clue about how I can filter launchpad bugmail using gmail? It doesn't recognize the mail as coming from a list | 07:27 |
| markh | (its bzr bugmail I most need to filter, which is why the question isn't completely off-topic ;) | 07:28 |
| chmac | Anyone familiar with the bzr upload plugin around? | 09:57 |
| chmac | beuno said it leaves a file on the server to track what version was last uploaded. I'd like to see a demo of that file, where it's placed, the filename, and so on... | 09:58 |
| mwhudson | chmac: i guess you can go bzr upload bzr+ssh://localhost/tmp/test and look in /tmp/test :) | 10:03 |
| mwhudson | (or however it works) | 10:03 |
| chmac | mwhudson: Hadn't thought of doing it to localhost, that's an idea... :) | 10:05 |
| chmac | Turns out it's crashing on my machine, I'm not running a late enough version of bzr | 10:07 |
| chmac | Upgrading caused hassle earlier, I'll try it again... | 10:07 |
| chmac | If I grab bazaar from ppa.launchpad to get the latest version, I can't also get bzr-svn there can I? | 10:11 |
| chmac | When I try to install the latest bzr it's failing because bzr-svn depends on it, but there's no newer version of bzr-svn | 10:12 |
| mwhudson | i uninstalled the bzr-svn package and stuck trunk in ~/.bazaar/plugins/svn | 10:15 |
| chmac | mwhudson: Is it that easy? | 10:23 |
| chmac | I love me some bazaar... :) | 10:23 |
| MvG | Hi! I'm looking for some features in bzr, and would be interested to learn if they are available already, or if not, if they have been discussed before, and what you know about the status of them. | 10:27 |
| MvG | One would be a way to merge distinct branches. Say you have two projects that started as independent branches, but they grow together with interdependence in both directions, so they should be merged into a single source tree. Is there a way to do so which would maintain the revision history of both parts from before the merger? | 10:28 |
| uws | MvG: i thought there was a (kludgy) trick for that | 10:29 |
| MvG | The second would be an analogous to the "svn cp" command. When you refactor a file, it makes sense to have two files descend from a common previous file, so that again lines in both files can be attributed to revisions before the split. Is there any way to achieve this in bzr? | 10:29 |
| uws | MvG: Something with "use the null revision as the merge parent" methinks | 10:30 |
| MvG | uws: Would that work with rich root repos, where even the root dir has a file id? Do you know how I would formulate that on the command line? | 10:30 |
| MvG | cd tmp | 10:32 |
| MvG | Sorry, wrong window... | 10:32 |
| chmac | I'm getting this error when trying to check out bzr-svn: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/.bzr/repository/packs/bffc0ecb67b4c56b089ca948c85597dc.pack: Expected a boundary (nDMiLeDyiK0rv.WGnkX:) line, got '' | 10:33 |
| chmac | Any suggestions? | 10:33 |
| uws | MvG: Something like bzr merge /path/to/other/branch -r 0..12345 where 12345 is the tip of the other branch | 10:36 |
| uws | MvG: backup/try first, it might do strange things | 10:36 |
| MvG | uws: At least on a test repo that looks very promising. -r 0..-1 would be the generic way. Thanks a lot, that will be helpful! | 10:38 |
| uws | MvG: yw. | 10:38 |
| uws | MvG: let me know if you know about the "cp" thing :) | 10:39 |
| MvG | uws: Sure. | 10:40 |
| MvG | chmac: "bzr branch http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4" works for me, with current bzr.dev. Was that the command you tried? You might try branching http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead. | 10:42 |
| chmac | MvG: That wasn't the command I tried, I was trying `bzr co lp:bzr-svn ~/.bazaar/plugins/bzr-svn/` | 10:42 |
| chmac | But I'm trying your command now | 10:42 |
| chmac | I'm also reading https://bugs.launchpad.net/bzr/+bug/198646 | 10:43 |
| ubottu | Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] | 10:43 |
| chmac | It looks like bazaar can cause issues with firewalls, I'm in Thailand, so everything runs through a transparent proxy | 10:43 |
| chmac | I'm trying to run the command via tsocks, but that doesn't seem to be working either... | 10:43 |
| MvG | chmac: You can register an ssh pubkey with launchpad, then the lp: branches will convert to bzr+svn, which might work better. | 10:44 |
| chmac | MvG: That sounds like a plan... | 10:44 |
| chmac | I'll be in Australia on Sunday and will probably not have this issue, but the ssh option is probably sensible anyway... | 10:44 |
| gnomefreak | what does bzr: ERROR: Path(s) are not versioned: debian/changelog mean? see: http://pastebin.mozilla.org/520727 for changelog | 10:45 |
| gnomefreak | it looks perfect to me. i get it when trying to commit changelog | 10:46 |
| MvG | If this transp. proxy is repeatedly causing you trouble, I would probably start looking for ways to avoid it when the need arises. Most of the ideas I can think of right now do require a host on the outside through which you can relay things, though. | 10:46 |
| MvG | gnomefreak: It means that the file is not under control of bzr. If you just created it (like it seems), you should call "bzr add debian/changelog" first. | 10:47 |
| MvG | gnomefreak: "bzr status" is useful to tell you about files not yet added. | 10:47 |
| gnomefreak | i found issue | 10:48 |
| gnomefreak | i forgot to add debian/ | 10:48 |
| chmac | Woohoo, it worked via tsocks after all :) | 10:48 |
| chmac | Gotta love ssh! :) | 10:48 |
| gnomefreak | will commit take several files at a time if i list them "bzr commit rules control"? | 10:49 |
| MvG | gnomefreak: Sure. Why not simply say "bzr commit" to commit all your changes in one bunch? | 10:49 |
| gnomefreak | MvG: what changelog on a separate commit | 10:50 |
| gnomefreak | i want | 10:50 |
| gnomefreak | not what | 10:50 |
| MvG | Does anybody know whether bundlebuggy is ill? Haven't been able to reach it lately, connections always time out. | 10:51 |
| MvG | uws: Found http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/45083 by Martin Pool which says the feature is wanted, but not yet implemented. Still hunting for the references. | 10:55 |
| MvG | jelmer: How does bzr-svn handle copied files from svn? Do you have an elegant way of representing the copy, whcih would be suitable for non-svn use cases as well? | 10:59 |
| MvG | Oh, I guess not, as you are the author of http://bazaar-vcs.org/BzrFileCopies and the corresponding https://launchpad.net/bzr/+spec/filecopies is marked "not started". uws, I think that sums it up so far. | 11:01 |
| uws | MvG: I'm not the author of that page :) | 11:16 |
| MvG | uws: No, sorry, that was addressed to jelmer. | 11:17 |
| MvG | Should have been more clear. | 11:17 |
| uws | MvG: it's ok. | 11:18 |
| uws | thanks for the pointer | 11:18 |
| MvG | http://bazaar-vcs.org/DraftSpecs/PathTokens seems worth reading as well. | 11:18 |
| MvG | lifeless: Your path tokens approach, are they intended to replace file ids? Or be an additional tool along file ids for cases where file ids don't get the job done by themselves? | 11:26 |
| lifeless | MvG: replace | 11:57 |
| lifeless | MvG: or more accurately, implement copy in the file id model | 11:57 |
| MvG | I believe I can see the issue in both your use cases, but I have doubt that a single approach would be fit to address them both. | 11:58 |
| MvG | As I understand it, the file tokens for copy would depend only of the history of the files involved, whereas the working with different trees in the parallel import scenario would be based on some user configuration, ore some perhaps costly automatic search for a common ancestor. | 12:00 |
| MvG | For copy/merge, a DAG of file ids might serve as a token. I have some ideas how to implement this, although I don't know how they would agree with the current infrastructure. But I can see no way to generalize this for parallel imports. | 12:04 |
| MvG | lifeless: If I want to put some ideas into words, should I do so in the wiki, or add comments on launchpad, or discuss them here? | 12:06 |
| lifeless | MvG: well for parallelimports tokens would work by allowing a join to take place at the first time both trees are examined | 12:08 |
| lifeless | the mailing list is probably the best place to describe thoughts on this | 12:09 |
| MvG | lifeless: Ah, so you don't want to seamlessly handle distinct imports in all commands, but instead want a single command to join the trees, which does specialized work, and continue from there handling things as two related branches, right? | 12:10 |
| MvG | I'm starting a mail to the list. Thanks. | 12:11 |
| lifeless | MvG: actually, I mean that 'merge OTHERIMPORT" | 12:14 |
| lifeless | will see separate tokens for conflicting file paths | 12:14 |
| lifeless | and depending on what we decide works best UI wise, with either have an option to enable, or disable, joining the tokens where the file path conflicts exist | 12:15 |
| lifeless | when you commit that merge, you will have created a join in the per-file dags, and subsequent merges in either direction will not conflict | 12:15 |
| MvG | Makes sense. | 12:16 |
| lifeless | this should be fast - the number of token changes in two parallel imports will be 1 each, and user friendly | 12:16 |
| MvG | How about this case: I have a private parallel import, and for some reason I want to merge that branch into an official branch, not the other way round, and continue working on these two in that fashion. So I myself would want to join the DAGs, but it wouldn't make much sense to push these joins anywhere, as noone else can make any use of the IDs from my private branch in any case. I would want a "private, unpushable join". Do you consider this scenar | 12:19 |
| lifeless | it cut off at 'do you consider this scenar' | 12:20 |
| MvG | ... this scenario to be of any relevance at all? | 12:22 |
| lifeless | well | 12:22 |
| lifeless | I don't really understand the scenario | 12:23 |
| lifeless | you want to merge a private branch into the official branch | 12:23 |
| lifeless | but you don't want to merge your history? | 12:23 |
| lifeless | ignore implementation details for now | 12:23 |
| lifeless | (file ids & file tokens are implementation details) | 12:23 |
| lifeless | MvG: still there? | 12:26 |
| MvG | lifeless: been AFK ... catching up now. | 12:28 |
| MvG | I want to merge the history, but I want to filter which part of the history I publish, I think. | 12:30 |
| lifeless | can you be more specific? | 12:30 |
| lifeless | (I'm still not understanding the use case) | 12:31 |
| MvG | Let's try a set of examples. | 12:31 |
| MvG | I create a branch "checkout" from an upstream repo and a branch "tarball" from a tarball. | 12:31 |
| MvG | I do "cd checkout; bzr merge ../tarball" or some such. | 12:32 |
| MvG | Now when I do "bzr log", I want to see a forked hiostory for the files, as they come from the tarball and the checkout. | 12:32 |
| lifeless | sure | 12:33 |
| MvG | But when I push the branch, I might wish the option of hiding all the joins, so people think that files changed in the tarball were modified by me, and files just present in the tarball were newly added by me. | 12:33 |
| lifeless | well the forked history would show that anyway | 12:34 |
| MvG | The forked history would register a different branch from which files have been merged, up to the initial import of the tarball. | 12:34 |
| MvG | On my system at least. | 12:34 |
| MvG | Gotta go now, I'll write the mail later today, and include this scenario for discussion once I have thought more about it. | 12:35 |
| lifeless | showing a fork and showing you as having made changes/added files are not mutually exclusive options | 12:35 |
| lifeless | anyhow, I think you could do revert --forget-merges after doing a merge to mainline; not sure why you would want to | 12:37 |
| cyberco | Hi! One of my branches (actually the trunk) has a parent branch ('bzr info' says so) that it doesn't need (since it is itself the trunk). Can I remove the parent branch? | 13:16 |
| james_w | cyberco: only by editing .bzr/branch/branch.conf currently | 13:18 |
| LarstiQ | not that it's particulary important to do so. | 13:18 |
| cyberco | james: ok, sounds a little dangerous (being new to bzr). I guess it won't do any harm there is still a parent (that doesn't exist anymore), will it? | 13:23 |
| LarstiQ | cyberco: no, it is only used as a default for things like `bzr pull` when you don't supply any arguments. | 13:24 |
| cyberco | ok, that's no problem then | 13:24 |
| LarstiQ | indeed :) | 13:24 |
| LarstiQ | cyberco: in case you want to change it, bzr pull --remeber some/other/branch would do it. | 13:25 |
| LarstiQ | cyberco: maybe not for trunk, but will come in handy for others. | 13:25 |
| cyberco | another question. On the server I've branched my trunk to 'workbranch'. Then I branched it to my local machine using sftp. But when I try to push my changes back to the 'workbranch' on the server I get the message: "This transport does not update the working tree" | 13:26 |
| LarstiQ | cyberco: right | 13:26 |
| LarstiQ | cyberco: if you don't need the working tree there (and I suspect you don't), then I'd blow it away on the server with `bzr remove-tree` | 13:27 |
| cyberco | larstiq: which means that the files will be removed but not the bzr info? | 13:28 |
| LarstiQ | cyberco: exactly. | 13:28 |
| cyberco | cool | 13:28 |
| LarstiQ | cyberco: in the case you did want to have a working tree there, the message is harmless, .bzr is still updated. You can `bzr up` on the server to update the working tree, or use a plugin like push-and-update to do that everytime you push. (Or bzr-upload if you don't want .bzr, say, website deployment) | 13:29 |
| cyberco | Yes, that was what I figured, but I don't need a 'working tree' on the server, so I thought that was a lot of hassle. But, alas, things work wonderful now! Thanks for your help | 13:32 |
| cyberco | I'm really impressed with bazaar | 13:32 |
| LarstiQ | thanks :) | 13:33 |
| gour | LarstiQ: lifeless anyone free to share some point with main ghc dev (JaffaCake in #ghc) ? | 13:33 |
| LarstiQ | gour: I'll join, but I can't guarantee anything | 13:33 |
| gour | LarstiQ: ok. | 13:33 |
| grutte_pier | has anyone experience in setting up a http bzr repository protected by an .htaccess file? | 13:34 |
| LarstiQ | gour: in general, there are more eyes in here, so I would recommend asking questions here. But I recognize the value of hopping over to their community for help. | 13:34 |
| LarstiQ | gour: I just wish I was better at giving it. | 13:34 |
| gour | yes, but let's take whatever opportunity which arises | 13:34 |
| LarstiQ | ok | 13:36 |
| cyberco | how are commit rights normally arranged? By standard OS file access control? | 13:38 |
| LarstiQ | cyberco: yes. | 13:39 |
| LarstiQ | grutte_pier: not me. | 13:40 |
| grutte_pier | cyberco: from the hasseling I'm having now with .htaccess I would say yes | 13:41 |
| fbond | Heya, svn has --stop-on-copy to show log from branch point forward. Does bzr have anything like that? | 13:42 |
| grutte_pier | my problem is that even with a authentication.conf file, I keep getting a 401: Authentication requested error,that bzr doesn't deal with... | 13:42 |
| moya | I need to publish branches over http, I can not find documentation about it in the user guide, any hints ? | 13:44 |
| fbond | I guess I can use `bzr log -r ancestor:foo..`. | 13:46 |
| grutte_pier | moya: same here! I think you'll need the WebDAV plugin to do that | 13:46 |
| grutte_pier | moya: you are not coincidentally trying to protect you're branches by a .htaccess + .htpasswrd file are you? | 13:47 |
| grutte_pier | moya: https://launchpad.net/bzr.webdav | 13:48 |
| moya | grutte_pier: yes I am | 13:48 |
| moya | grutte_pier: using LDAP instead of .htpasswd file | 13:48 |
| james_w | you want people to be able to push over http as well? | 13:48 |
| moya | james_w: yes, I'd like everything possible available over http | 13:49 |
| LarstiQ | grutte_pier: access the branch by http://user@host/... | 13:49 |
| james_w | yeah, you need either webdav, or the smart server | 13:49 |
| grutte_pier | LarstiQ: that gives an error as well: PathNotChild: Path 'http://host' is not a child of path 'http://user@host': user name mismatch | 13:53 |
| * LarstiQ blinks | 13:54 | |
| grutte_pier | maybe host is not allowed to be a www. adres? | 13:55 |
| cyberco | grote_pier:) Do you have links where these "commit rights" access-issues are described? | 14:00 |
| LarstiQ | grutte_pier: what version of bzr are you using, and can you pastebin the traceback for that? | 14:00 |
| grutte_pier | cyberco: no links yet | 14:02 |
| grutte_pier | LarstiQ: version 1.5... but I've been having the problems with all previous versions | 14:02 |
| grutte_pier | LarstiQ: I'm not sure what a 'pastebin' means..... :( | 14:03 |
| LarstiQ | grutte_pier: http://rafb.net/paste/ | 14:03 |
| grutte_pier | LarstiQ: great facility ;) http://rafb.net/p/7cPcjb41.html | 14:06 |
| LarstiQ | grutte_pier: there are tons of these pastebins around, rafb is just the one I can remember | 14:07 |
| Leonidas | hi, am am trying to use the api of bazaar and wanted to ask you guys how to get the permissions of a file in bzr. | 14:09 |
| LarstiQ | Leonidas: I'm not sure what you mean. | 14:15 |
| LarstiQ | Leonidas: do you mean, what are the unix permissions of a file in a historical revision? | 14:15 |
| Leonidas | LarstiQ: Now, when I have a revtree I can get a files contents via a StriongIO object. But I'd also like to get the special attributes like link, executable etc. | 14:16 |
| LarstiQ | Leonidas: ah ok, right, those we do track. But everything other than executable we do not. | 14:16 |
| robsta | ping Jc2k | 14:16 |
| Leonidas | I think exacutable and link is the only thing I need to know anyway. | 14:17 |
| Leonidas | There is revtree.is_executable, but what about links? | 14:17 |
| Jc2k | robsta pong | 14:19 |
| === mw|out is now known as mw | ||
| LarstiQ | Leonidas: is there one specific file you are interested in, or do you need to handle all files? | 14:20 |
| robsta | hi Jc2k, i'm trying to reach bkor for 2 days now, to help out with the bzr/svn maintainter script workaround, but to no avail | 14:20 |
| robsta | Jc2k: any alternative? | 14:21 |
| Leonidas | LarstiQ: I just need it for one file at the moment (I the future I might better use a cache for this, but first I wanted to get it working). | 14:21 |
| grutte_pier | LarstiQ: same story for test release 1.6 | 14:21 |
| LarstiQ | Leonidas: well, there are iter_entries type apis for the latter. | 14:22 |
| LarstiQ | Leonidas: revtree.kind(fileid) | 14:29 |
| LarstiQ | grutte_pier: ok, back to your problem | 14:29 |
| Leonidas | LarstiQ: thanks, I'm trying but I am struggling a bit with IPython, it somehow chokes on exceptions. | 14:30 |
| LarstiQ | Leonidas: you can %pdb in ipython for dropping you into a debugger when that happens, but can you provide some more info? | 14:31 |
| LarstiQ | grutte_pier: https://bugs.edge.launchpad.net/bzr/+bug/245964 looks ort of similar | 14:31 |
| ubottu | Launchpad bug 245964 in launchpad-bazaar "nosmart+http interacts badly with http redirects" [Critical,Fix released] | 14:31 |
| Leonidas | LarstiQ: well, it seems to be rather IPython related: http://paste.pocoo.org/show/82797/ | 14:32 |
| LarstiQ | Leonidas: wuh | 14:32 |
| LarstiQ | Leonidas: it barfs on getcwd()? | 14:32 |
| Leonidas | LarstiQ: oh, indeed. | 14:34 |
| LarstiQ | grutte_pier: is there a redirect going on perhaps? | 14:34 |
| grutte_pier | LarstiQ: yep, there is... this looks indeed very familiar | 14:34 |
| Leonidas | LarstiQ: I have deleted the directory it was in. Just fixed it by chdiring somewhere else. | 14:34 |
| LarstiQ | Leonidas: ok :) | 14:35 |
| Leonidas | Mhh, that might explain my earlier troubles with it. Sometimes I delete branch folders from one of my numerous screen sessions. | 14:36 |
| grutte_pier | LarstiQ: when taking another close look at my traceback, the remarks in bug 245964 make sense as well | 14:41 |
| ubottu | Launchpad bug 245964 in launchpad-bazaar "nosmart+http interacts badly with http redirects" [Critical,Fix released] https://launchpad.net/bugs/245964 | 14:41 |
| grutte_pier | LarstiQ: in the bug they speak of some comparison and indeed the error in my traceback, is that http://host/.bzr/smart is compared with http://user@host/ .... without the additional .bzr-path | 14:42 |
| grutte_pier | LarstiQ: it makes sense that something is going wrong there, because they are simply different paths | 14:43 |
| grutte_pier | LarstiQ:with nosmart+http the same problems happens with .bzr/smart replaced with .bzr/branch-format | 14:44 |
| LarstiQ | grutte_pier: well, foo/.bzr/etc is a a child of foo/, our problem is that foo isn't foo. | 14:45 |
| LarstiQ | grutte_pier: I'm not exactly sure why that arises. | 14:45 |
| LarstiQ | grutte_pier: and I really need to go out and buy breakfast | 14:45 |
| * LarstiQ heads to the AH, oh no, aldi. | 14:45 | |
| LarstiQ | grutte_pier: I'll get back to you on this. | 14:46 |
| Necoro | hey :) | 15:16 |
| Necoro | every time I push via FTP - all .bzr files which are altered get the permissions 0600 ... | 15:16 |
| Necoro | but this blocks access from the HTTP-server | 15:16 |
| Necoro | so I can't pull via http any more | 15:16 |
| Necoro | is it possible to make bzr change the default permissions to 0644 ? | 15:17 |
| beuno | james_w, hi | 15:50 |
| james_w | hey beuno | 15:52 |
| beuno | how's it going? | 15:52 |
| james_w | good thanks, you? | 15:52 |
| beuno | pretty good too | 15:53 |
| beuno | I'll be in London again next week, if you want to/can drop by :) | 15:54 |
| james_w | ah cool | 15:54 |
| james_w | next week isn't great for me though, sorry | 15:54 |
| beuno | no worries, next time (which, for now, seems to be october) | 15:55 |
| james_w | cool | 15:55 |
| james_w | you're travelling a lot? | 15:55 |
| beuno | heh, yeah, seems like it's going to be like this for quite a while | 15:56 |
| LarstiQ | beuno: how so? | 15:57 |
| beuno | LarstiQ, hi. Well, I have 3 trips already planned from here to december, and a few "maybes" | 15:57 |
| LarstiQ | I see. | 15:58 |
| beuno | everytime I start to complain about 14 hour plane trips, I remember australian folks do 24+ :) | 15:59 |
| jam | Necoro: I don't think we chmod over ftp, but I could be wrong | 16:12 |
| jam | if we *do* then setting the permissions on the '.bzr/' directory itself should cause us to set permissions on files correctly. | 16:13 |
| jam | But my guess is that it is an ftp server thing, and something outside of bzr's control | 16:13 |
| jam | beuno: I'm a bit surprised their bringing you to London so often, I suppose it depends if you enjoy it or not whether I should be congratulating you or expressing sympathy :) | 16:14 |
| Necoro | jam: on my local branch the permissions are correct | 16:14 |
| Necoro | so - perhaps it is really a server thing | 16:14 |
| jam | Necoro: TODO: jam 20051215 ftp as a protocol seems to support chmod, but | 16:14 |
| jam | ftplib does not | 16:14 |
| jam | Necoro: but I also see a "SITE CHMOD" command | 16:15 |
| jam | So it seems that the server *might* support chmod | 16:15 |
| beuno | jam, heheh, well, I *do* enjoy the sprints. Actual plane flights, not as much, but I'm getting used to them. I guess my work needs more high bandwidth interaction | 16:15 |
| jam | Necoro: we generally set permissions based on the .bzr/ directory | 16:15 |
| jam | beuno: just hack on the plane, right? | 16:15 |
| jam | lifeless does that | 16:15 |
| jam | you can get some interesting work out of him before/after sprints | 16:15 |
| jam | Necoro: so if the .bzr/ directory is set 700 we will create files as 600 | 16:16 |
| jam | if it is 777 we should create files as 666 | 16:16 |
| beuno | yeah, I really have to start upgrading to business class, where they have plugs for laptops | 16:16 |
| jam | Necoro: that, of course, requires the ftp server to support both stat and chmod | 16:16 |
| jam | Necoro: hm... I see a possible problem. It seems that our code doesn't detect ftp permissions correctly, but it does try to *set* them. :( | 16:17 |
| jam | vila: ping, just curious if you know about the SITE CHMOD work | 16:17 |
| beuno | jam, all debs uploaded, moving on to docs tweaks | 16:30 |
| jam | /cheer | 16:30 |
| jam | I guess I should announce then | 16:39 |
| beuno | jam, yeah, and possibly blog about it? warn people this is the last RC, so, speak now or forever hold your complaints | 16:56 |
| Odd_Bloke | jelmer: I just got http://paste.ubuntu.com/39158/ when attempting to commit to the Python Applications Packaging Team's SVN repo. | 17:06 |
| Odd_Bloke | I get much the same when I commit locally and attempt a push (same SVN exception). | 17:06 |
| jam | Odd_Bloke: it looks like a directory isn't there any more, are you sure the URLs are all correct still | 17:09 |
| jam | beuno: I suppose | 17:09 |
| jam | I just feel a bit like I'm hammering people with 5 release candidates | 17:09 |
| jam | when it is typically only 1 | 17:09 |
| jam | the fact that I've released 4 of them in < 1 week | 17:09 |
| fullermd | Well, you could have hammered then with 4 releases in a week instead. That would have gotten plenty of attention... | 17:10 |
| jam | beuno: also there is a trivial bit incorrect with 1.6rc5, the date in NEWS is wrong. I don't know if it is worth doing anything about it. | 17:10 |
| luks | rc6 with a changelog bugfix! :) | 17:11 |
| === kiko is now known as kiko-phone | ||
| Odd_Bloke | jam: This was on a fresh checkout of a freshly created folder. | 17:11 |
| fullermd | Then rc7 for the changelog bug of forgetting to put rc6 in the changelog. | 17:11 |
| === mw is now known as mw|brb | ||
| beuno | jam, I'm sure people will forgive an incorrect date in NEWS :) | 17:12 |
| jam | luks, fullermd: Well, Peng teased me that there will be a 1.6rc7, so I need to avoid that one :) | 17:14 |
| jam | I'll just skip to 1.6rc8 | 17:14 |
| moya | I have created a repo with bzr init-repo --no-trees in /srv/bzr and published that dir via web using dav, when I try to access it bzr complains with: ERROR: Target directory http+webdav://localhost/bzr/ already exists, but does not have a valid .bzr directory | 17:15 |
| fullermd | That would make perfect sense, actually. | 17:16 |
| fullermd | If you skipped rc6 too, that would make the 5th rc in the week, and 1.6 is 8/5. | 17:16 |
| jam | fullermd: exactly :) | 17:16 |
| beuno | jam, patch sent. I'm moving to the office, will put together a draft on what the script should do and send it to the list. Then I move on to stuff I need to do in these channels --> | 17:18 |
| fullermd | Mmmm. 1.6 stopped using some of the smart server verbs we were using, right? | 17:18 |
| jam | fullermd: right | 17:18 |
| beuno | (moving to the office == 15 minutes AFK) | 17:18 |
| jam | beuno: I thought you just ignored the .bzr dir rather than deleting it | 17:19 |
| Odd_Bloke | There is a /www/policy.txt in the SVN repo, but I don't know why it's looking at it (as I'm in a completely different place). | 17:19 |
| Odd_Bloke | jelmer: jam: ^ | 17:19 |
| fullermd | Would that be why a remote missing is taking over a minute to a 1.5 server now, instead of the merely absurd 25 seconds 1.5 takes? | 17:19 |
| fullermd | It seems to churn for a very long time before the "You are missing xyz revisions" line. | 17:20 |
| beuno | jam, it created problems last time. lamont implied it didn't get added, but it did last time I tried, so I'm adding it just in case | 17:20 |
| jam | beuno: you sure you did both -I.bzr and -i.bzr ? | 17:21 |
| beuno | jam, I did what the PPA docs say: debuild -S -sa -i -D | 17:22 |
| jam | beuno: I thought lamont's recommendation was to do | 17:22 |
| jam | debuild -S -sa -i -D -I.bzr -i.bzr | 17:22 |
| jam | Or at least, he configured it to do that in his ~/.something | 17:23 |
| luks | why not use bzr-builddeb for the packages? | 17:23 |
| jam | luks: a few reasons | 17:23 |
| beuno | jam, I didn't quite understand that part, so I went down a different path. I'll be happy to go over the docs with him if he has time | 17:23 |
| jam | 1) We add the intermediate compiled .pyx => .c files so people don't need pyrex to build the bzr source | 17:23 |
| jam | And AFAIK bzr-builddeb doesn't allow adding intermediate files | 17:23 |
| dato | jam: "-i" alone should be enough | 17:24 |
| luks | the packages are built against the release tarball, aren't they? | 17:24 |
| jam | dato: well, lamont came and complained that it wasn't | 17:24 |
| dato | jam: ok, but odd :-) | 17:24 |
| luks | and the tarball already contains the compiled .c files | 17:24 |
| jam | luks: 2) There was something about bzr-builddeb interacting poorly with orig.tar.gz | 17:24 |
| jam | luks: I though bzr-builddeb worked against the *bzr* tree, not a tarball | 17:24 |
| luks | bzr-builddeb has many workflows | 17:25 |
| jam | dato: and according to beuno just now, it also failed | 17:25 |
| luks | but as most software isn't in bzr, it would be weird requirement to use a bzr tree | 17:25 |
| jam | luks: I think we would *like* to use bzr-builddeb, and if someone can put something together that actually works, we probably *would* use it. | 17:25 |
| beuno | jam, dato, I may have done something else wrong, which made -i do something else, but I'd rather stick with an extra step that works 100% of the time for now. We can always improve | 17:25 |
| luks | jam: well, I use bzr-builddeb for some PPA packages and it works all fine | 17:26 |
| luks | jam: maybe I'll take a look at it | 17:26 |
| jam | luks: *I* would appreciate that a lot | 17:29 |
| Odd_Bloke | Bwahaha, I win. | 17:32 |
| Odd_Bloke | I had branching scheme issues. | 17:32 |
| * LarstiQ hands Odd_Bloke the washing machine! | 17:32 | |
| === mw|brb is now known as mw | ||
| Leonidas | What is the number that is stored in Revision.timezone? It seems to be seconds, right? | 17:42 |
| Leonidas | (seconds from UTC) | 17:42 |
| * fullermd would presume so. | 17:43 | |
| fullermd | At least, until some random place gets a bug up their behind and decides to make their TZ offset sub-second... | 17:44 |
| vila | jam: not sure what you're referring to, I fixed some bugs in the ftp transport but Christophe Troestler (IRC nick anyone ?) also made some modifications I didn't review | 18:22 |
| beuno | vila, hi! | 18:23 |
| vila | beuno: hi ! I will be back far more often starting in 37 hours :-D | 18:24 |
| vila | beuno: I need to reply to a couple of mails regarding bzr-upload (as in: I read them but didn't find the time to reply) | 18:25 |
| beuno | vila, yay! Welcome back, you've been missed | 18:26 |
| vila | thanks | 18:26 |
| vila | I think I'm so excited I prefer to hide :-) (kidding, I need to finish a project in record times but I came back from vacations with fully charged batteries :) | 18:28 |
| Verterok | mornin' all | 18:30 |
| beuno | hey Verterok | 18:30 |
| Verterok | beuno: hey there | 18:30 |
| beuno | Verterok, home yet? | 18:31 |
| Verterok | beuno: still @ work...but leaving in ~ 2hs | 18:31 |
| Verterok | beuno: (mini)sprint at you office? :D | 18:32 |
| beuno | Verterok, absolutely! I'll be here | 18:32 |
| Leonidas | When I have a file id, how do I get the revision in which it was last modified? | 18:32 |
| Leonidas | for example I have pointtec-20061130215532-730mabsm1q6n7007-1 | 18:33 |
| Leonidas | Now I'd like to get a revision that contains the file. | 18:34 |
| beuno | Leonidas, I can't dig into it right now, but you should peak into how loggerhead does it | 18:36 |
| === kiko-phone is now known as kiko | ||
| jam | vila: well the "SITE CHMOD" lines are attributed to a commit from you | 19:14 |
| jam | namely 3508.1.1, "Fix ftp transport so that it handles the 'mode' parameter when provided" | 19:14 |
| jam | Leonidas: Do you already have a tree? | 19:15 |
| jam | revtree.inventory[file_id].revision | 19:15 |
| Leonidas | jam: yeah, I do. thanks. I was peeking into bzrlib.builtins.cmd_file_id_path which is using WorkingTree. | 19:17 |
| jam | Leonidas: unfortunately, for a working tree you have to grab the "basis_tree" | 19:17 |
| jam | bt = wt.basis_tree() | 19:17 |
| jam | bt.lock_read() | 19:17 |
| jam | bt.inventory[file_id].revision | 19:17 |
| jam | bt.unlock() | 19:17 |
| Leonidas | jam: it is not a problem, I don't want to use the workingtree anyway :) | 19:18 |
| === thumper_laptop is now known as thumper | ||
| beuno | what do I need to fiddle with in locations.conf to commit with different email addys in different locations? | 19:51 |
| jam | beuno: 'bzr whoami --branch' | 20:03 |
| jam | You just set "email = ..." I believe | 20:03 |
| vila | jam: ok, so you're referring to my fix. What's up ? | 20:07 |
| jam | vila: I'm just trying to figure out what is going on, since it appears that we don't *stat* over ftp, so we get a bogus mode, and then try to chmod incorrectly. | 20:09 |
| jam | Someone earlier was saying that over ftp he was getting 700 for everything | 20:09 |
| jam | which meant when he uploaded, it broke modes for http access | 20:09 |
| vila | jam: hmm, weird, two things: | 20:10 |
| vila | 1- I thought bzrlib always provides 755 or 644 by default (without stat'ing) | 20:11 |
| vila | 2- ftp servers can restrict chmod usage | 20:11 |
| vila | or set an umask | 20:11 |
| beuno | jam, thanks | 20:12 |
| vila | but that's from memory, if there is a bug report I could look into fixing it anyway (very sooon 8-) | 20:12 |
| jam | vila: *I* thought we provided None by default | 20:12 |
| jam | No bug report that I know | 20:12 |
| Necoro | vila, jam: Files uploaded via a normal ftp-program results in 644 | 20:13 |
| beuno | lifeless, ping me when you're up, I'm preparing 1.6.1 | 20:15 |
| Necoro | ok - using zsh's ftp client also results in 644 | 20:15 |
| Necoro | so I assume it is a bzr issue | 20:15 |
| vila | jam: if we provide mode=None, then we don't call SITE CHMOD... | 20:15 |
| jam | vila: I thought we provide None unless we successfully *stat* | 20:16 |
| vila | Necoro: can you file a bug report please, I'll look into it | 20:16 |
| jam | but our ftp.stat() returns st_mode = S_REG | 20:17 |
| jam | or | 20:17 |
| jam | st_mode = S_DIR | 20:17 |
| Necoro | vila: ok | 20:17 |
| jam | and nothing about the actual permissions | 20:17 |
| jam | Necoro, vila: My guess is that we should see "mode == 000" and then fall back to None | 20:17 |
| vila | jam: I know, it's a faked stat, but where do you see 'we provide None unless we successfully *stat*' | 20:18 |
| jam | vila: "BzrDir._find_creation_modes" | 20:18 |
| jam | st = self.transport.stat('.') | 20:18 |
| jam | try/except TransportNotPossible | 20:18 |
| jam | if not posisble "_dir_mode = None" | 20:19 |
| jam | else | 20:19 |
| jam | _dir_mode = (st.st_mode & 07777) | 00700 | 20:19 |
| jam | vila, Necoro: So explicitly this is the problem. | 20:19 |
| jam | The stat succeeds | 20:19 |
| jam | but doesn't return a valid mode | 20:19 |
| jam | so we fall back to 0700 | 20:19 |
| jam | We could simply do | 20:19 |
| jam | if st.st_mode & 07777 == 0: self._dir_mode = None | 20:20 |
| vila | that's nasty because I thought transport.stat() was used to know wether or not a path is a dir, I was not aware it was used to get permissions | 20:21 |
| jam | vila, Necoro: This should be a reasonable fix: http://pastebin.com/d66e4426c | 20:21 |
| jam | vila: In other places it is used for size | 20:21 |
| jam | Not sure when that is used any more | 20:21 |
| Necoro | jam: I'll give it a try | 20:21 |
| vila | webdav will suffer from the same problem as will the smart server then (that's where I stole the idea to implement it in webdav) | 20:22 |
| Necoro | jam: what version of bzr is this diffed against? | 20:23 |
| jam | Necoro: bzr.dev | 20:23 |
| Necoro | because the patch fails with 1.6rc3 | 20:23 |
| jam | Necoro: odd, I see exactly the same code | 20:24 |
| jam | slightly different offset | 20:24 |
| jam | Necoro: starts at 648 in bzr-1.6rc3 | 20:25 |
| jam | line 648 | 20:25 |
| * Necoro will just patch by hand ;) | 20:25 | |
| jam | vila: smart server issues a real stat request | 20:26 |
| jam | and returns stat.st_mode directly | 20:26 |
| jam | so it includes file modes. | 20:26 |
| jam | well, it uses "self._backing_transport.stat()" | 20:26 |
| jam | but 99% of the time backing_transport is Local | 20:26 |
| jam | well Chroot(Local()) | 20:27 |
| * vila scratches his head | 20:28 | |
| Necoro | jam: works now | 20:29 |
| Necoro | should I still file the bug? | 20:29 |
| jam | Necoro: so please file a bug | 20:29 |
| jam | and include that as a patch | 20:29 |
| jam | so we don't forget about it | 20:29 |
| jam | and then poke vila in 37 hours so that he fixes ftp's stat :) | 20:29 |
| jam | In the mean time, let him get his "private" work done, so he doesn't start working for us late | 20:30 |
| jam | :) | 20:30 |
| vila | make that 34.5 hours :-D | 20:31 |
| Necoro | bug #259855 | 20:33 |
| ubottu | Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Undecided,New] https://launchpad.net/bugs/259855 | 20:33 |
| jam | Thanks Necoro | 20:49 |
| Necoro | thank you jam for the patch | 20:49 |
| === mw is now known as mw|food | ||
| teratorn | is there any easy way to append some more changes to the last commit? | 21:12 |
| teratorn | (before its pushed or pulled, of course) | 21:12 |
| luks | bzr uncommit / bzr commit | 21:15 |
| teratorn | yeah, I already knew about that :/ | 21:17 |
| LarstiQ | teratorn: so what did you want different? | 21:18 |
| teratorn | just a simple command "append-commit" or the like... so I don't have to fumble with copying commit messages, etc | 21:19 |
| teratorn | one other thing.. bzr shelve/unshleve is great and all, but is there a way to do hunk cherry-picking at commit time, instead of having to do a separate shelve operation first? | 21:21 |
| * LarstiQ wonders why people suddenly keep asking for that | 21:21 | |
| jam | teratorn: there is the "bzr-interactive" plugin, which allows "bzr commit -i" | 21:21 |
| teratorn | often times I have a mass of changes, but I will make little "side changes" (docs, comments, etc), that should just be committed immediately and forgotten about | 21:22 |
| teratorn | jam: interesting, thanks | 21:22 |
| LarstiQ | now, if my browser didn't freeze out on me, I could try to look up if there is an ammend style plugin to do the uncommit/commit dance. | 21:23 |
| Necoro | where is the problem with doing two commits? | 21:24 |
| Necoro | and stating in the commit message that it counts as an ammendment to the previous one? | 21:25 |
| Peng_ | Uh-ohs. SimpleTAL exceptions in Loggerhead. | 21:25 |
| teratorn | it's dumb... other developers shouldn't be burdened processing two commit messages/diffs when one is best | 21:25 |
| teratorn | see e.g. "darcs amend-record" | 21:25 |
| Peng_ | Coinciding with a spike in resource usage too. | 21:25 |
| LarstiQ | teratorn: I thought there was something like that, but I can't find it atm. | 21:26 |
| teratorn | LarstiQ: well I'll keep my eye out.. thanks | 21:26 |
| teratorn | I imagine writing a plugin to do it wouldn't be hard | 21:26 |
| LarstiQ | teratorn: right, fairly trivial even. | 21:27 |
| fullermd | I think there might be something in bzr-gtk or one of the GUIs that does it. | 21:27 |
| fullermd | There was a hunk of discussion/work on saving uncommit'd logs at least, which is part of the process. | 21:27 |
| * LarstiQ watches http://gigo-ice.org/scm/bazaar/plugins/docdiffdemo.htm in the interim | 21:28 | |
| mwhudson | Peng_: hmm | 21:31 |
| Peng_ | Oh hi | 21:32 |
| Peng_ | This page does it: http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/changes?start_revid=1185.33.49 | 21:33 |
| Peng_ | Augh, I can't copy and paste from my log files when you people make 20 requests! :( | 21:34 |
| Peng_ | Anyway, it just says it can't concatenate str and None. | 21:34 |
| mwhudson | what | 21:34 |
| mwhudson | Exception: cannot concatenate 'str' and 'NoneType' objects | 21:34 |
| mwhudson | hm | 21:34 |
| mwhudson | it's in the source too, which makes it easier to find :) | 21:35 |
| Peng_ | Oh. | 21:36 |
| Peng_ | OK then. That should make it easier to track down. The log file didn't give any context. | 21:36 |
| Peng_ | (FWIW, the error was repeated 3 times.) | 21:36 |
| Peng_ | That revision has no branch nick. | 21:37 |
| Peng_ | Yeah, none of them do. | 21:38 |
| mwhudson | yeah, it's a branch_nick problem indeed | 21:38 |
| bkor | Jc2k: when robsta is around, tell him I have an email address | 21:50 |
| mwhudson | Peng_: fixed | 21:51 |
| Peng_ | mwhudson: Cool. Thanks. :) | 21:51 |
| mwhudson | np, thanks for mentioning it | 21:51 |
| Peng_ | Could any other places have that issue? | 21:51 |
| Jc2k | bkor: will do | 21:57 |
| bkor | Jc2k: I have no idea what the hell he's pinging me for (I prefer people just either asking outright, or staying online 24/7) | 21:58 |
| beuno | mwhudson, are you up to doing a review today, so we can release a 1.6.1 with fixes to the template browse.pt and adding --port and --host flags to serve-branches? | 21:58 |
| mwhudson | beuno: sure | 21:59 |
| mwhudson | Peng_: maybe :) | 21:59 |
| mwhudson | Peng_: nowhere totally obvious suggested by grep | 21:59 |
| Jc2k | bkor: he's wanting to move his css gtk engine into svn.gnome.org sing the same method as uws did for gnome-specimen | 22:01 |
| Lani78 | Hi, I'm trying to learn bzr and I've now created a central and shared repository on my server. First I created a local repo: | 22:01 |
| Jc2k | bkor: so he needs you do to the honour with killing trunk and copying his branch to trunk | 22:01 |
| Lani78 | bzr init-repo --trees . | 22:01 |
| Lani78 | then the remote on my server: bzr init-repo --no-trees sftp://centralhost/srv/bzr/ | 22:02 |
| bkor | Jc2k: I forgot what I did for uws | 22:02 |
| Lani78 | I can add files, and commit them just fine, and get them from another computer later, so it all works :) | 22:02 |
| Jc2k | bkor: delete drunk and then move the bzr-playground branch in its place | 22:02 |
| Jc2k | *trunk | 22:02 |
| Lani78 | BUT, where does it physically store my data? | 22:03 |
| Jc2k | bkor: for http://svn.gnome.org/svn/gtk-css-engine/ | 22:03 |
| Jc2k | bkor: i can get the blog post uws made with notes if it is helpful | 22:03 |
| Lani78 | the folders that I create in /srv/bzr are completely emtpy... ;) | 22:03 |
| Peng_ | Lani78: Do they have a .bzr directory? | 22:04 |
| Lani78 | nope | 22:04 |
| Lani78 | but the data must be somewhere on the server as I could get the files from another computer ;) | 22:04 |
| Peng_ | Yeah, it's in ".bzr". | 22:05 |
| Lani78 | but not on the server... I just told you. not in /srv/bzr anyway... If not "ls -l" has changed... | 22:06 |
| Jc2k | ls -a | 22:06 |
| Lani78 | ah! | 22:06 |
| Lani78 | hehe | 22:06 |
| Lani78 | da*n | 22:06 |
| Lani78 | Thanks :) | 22:07 |
| Lani78 | Now I feel safe again ;) I think that I should go to bed and get some sleep ;) | 22:07 |
| === mw|food is now known as mw | ||
| Lani78 | Ok, my next question now that we have that out of the way ;) | 22:09 |
| Lani78 | I created the central shared repository with: bzr init-repo --no-trees sftp://centraluser@centralhost/srv/bzr/ | 22:10 |
| Lani78 | if I changed my mind now, and I want a separate shared repository for every project. can I just move all of the contents in /srv/bzr/.bzr into a subfolder, like /srv/bzr/project1 | 22:11 |
| Lani78 | I only have one project at this time | 22:11 |
| Necoro | Lani78: using "bzr branch" should make more sense, I think | 22:13 |
| Necoro | though using it in a subdirectory of a repository will not do what you think it'll do ... | 22:14 |
| Lani78 | No, that is why I changed my mind and want a repository for every project | 22:14 |
| Lani78 | Atleast that is what I think that I want and what was recommended on another wiki page when I found it ;) | 22:15 |
| Necoro | Lani78: but I doubt copying .bzr directories is the way to go | 22:15 |
| Lani78 | Ok. But to make it easy for me know, if I just want to start over, then all I have to do is to remove all the .bzr directories, locally and on my server, right? | 22:16 |
| Necoro | then you'll lose all bzr-related information | 22:17 |
| Lani78 | yes, but that's fine, I can start over now, I only just begun. | 22:17 |
| Lani78 | It's a lot of new terminology and techniques to grasp for a former Microsoft Visual SourceSafe guy... ;) | 22:19 |
| Necoro | Laney: given that /A is a shared repos with projects /A/b and /A/c - and you want to split ... I would do: bzr branch /A/b /tmp/b && bzr branch /A/c /tmp/c && rm -rf /A && mkdir /A && mv /tmp/[bc] /A/ | 22:19 |
| Necoro | though perhaps there is an easier approach ... | 22:20 |
| pickscrape | How may people does Canonical employ to work on bzr full time? | 22:20 |
| Lani78 | Necoro: ah ok, I think that made sense | 22:20 |
| Necoro | Lani78: because for the shared repository, there is a .bzr in /A and in /A/b and /A/c ... | 22:22 |
| Necoro | so just copying the one in /A won't work, I assume | 22:22 |
| Lani78 | Yes, and now I don't wont any in /A, just in /A/b and /A/c | 22:23 |
| Necoro | yeah - my branch and move approach above should handle this ... | 22:24 |
| Lani78 | Yup :) | 22:24 |
| Necoro | perhaps "bzr split" might work too ... but this only a guess | 22:24 |
| Lani78 | I will try that, but I have not fully grasped this working tree stuff yet but hopefully it will come to me eventually, I will start with just doing it as the tutorial says and see what the result becomes :) | 22:24 |
| Peng_ | "split" is for when you want to break off one directory in a branch into its own branch. It has nothing to do with shared repos. | 22:25 |
| Peng_ | Lani78: You don't need to throw out your history if you just want to reorganize your shared repos. | 22:25 |
| Lani78 | Peng_: ok? Necoro gave me an example of creating temporary branches? | 22:26 |
| Lani78 | (11:19:19 PM) Necoro: Laney: given that /A is a shared repos with projects /A/b and /A/c - and you want to split ... I would do: bzr branch /A/b /tmp/b && bzr branch /A/c /tmp/c && rm -rf /A && mkdir /A && mv /tmp/[bc] /A/ | 22:26 |
| lifeless | beuno: pong | 22:37 |
| beuno | lifeless, good morning | 22:37 |
| beuno | I promised 3 things for LH 1.6.1 | 22:37 |
| beuno | 1) fix template | 22:37 |
| beuno | 2) --port flag for serve-branches | 22:38 |
| beuno | and 3) --host ? | 22:38 |
| beuno | 2) and 3) are done, and 1) is 3/4 there | 22:38 |
| lifeless | --prefix | 22:45 |
| beuno | lifeless, --prefix for what, sorry? | 22:47 |
| lifeless | beuno: see michael's mail to me | 22:48 |
| lifeless | beuno: did you find it? | 22:53 |
| beuno | mwhudson, can you clarify that a bit for me? --prefix should be appended before path? (serve-branches, line 79) | 22:53 |
| beuno | lifeless, I don't quite get what needs to be plugged | 22:54 |
| lifeless | I have loggerhead on localhost, apache in front mapping host/bzrview -> loggerhead | 22:54 |
| lifeless | loggerhead can figure out host magically, but not that /bzrview == '.' | 22:55 |
| beuno | lifeless, so you would add --prefix /bzrview? | 22:55 |
| lifeless | beuno: something like that | 22:56 |
| beuno | not sure what paste does with the PrefixMiddleware, so I'm kinda in the dark | 22:56 |
| lifeless | mwhudson_: welcome to the internets | 22:56 |
| mwhudson | lifeless: :/ | 22:57 |
| mwhudson | lifeless: it's my laptop acting up this time | 22:57 |
| lifeless | heh | 22:57 |
| lifeless | mwhudson: beuno needs guidance | 22:57 |
| lifeless | 07:53 < beuno> mwhudson, can you clarify that a bit for me? --prefix should be appended before path? (serve-branches, line 79) | 22:58 |
| beuno | mwhudson, this is refered to: | 22:58 |
| beuno | >> We use port 8000, and map http://www.squid-cache.org/bzrview/ not / | 22:58 |
| beuno | > | 22:58 |
| beuno | > serve-branches is meant to autodetect this from apaches forwarded | 22:58 |
| beuno | > requests. | 22:58 |
| mwhudson | lifeless, beuno: no, it's for the prefix middleware constructor | 22:58 |
| beuno | It only detects the hostname automatically (by X-Http-Forwarded-Server), | 22:58 |
| beuno | you have to specify the hostname in the construction of the | 22:58 |
| beuno | PrefixMiddleware object (or via a --prefix command line option we should | 22:58 |
| beuno | add...). | 22:58 |
| beuno | mwhudson, so it takes more parameters? | 22:59 |
| mwhudson | beuno: yes | 22:59 |
| * beuno looks for paste docs | 23:00 | |
| mwhudson | beuno: read it's source/docstrings, perhaps, | 23:00 |
| beuno | mwhudson, thanks. I see it has a prefix value, simple enough | 23:02 |
| beuno | lifeless, mwhudson, does this look good enough? http://beuno.com.ar/random/lh.png | 23:30 |
| lifeless | FINE | 23:30 |
| lifeless | fine :) | 23:30 |
| mwhudson | beuno: +1 | 23:31 |
| beuno | \o/ | 23:31 |
| * beuno commits and pushes for review | 23:31 | |
| === mw is now known as mw|brb | ||
| beuno | lifeless, http://bazaar.launchpad.net/~beuno/loggerhead/1.6.1/revision/220?compare_revid=215 (see changes to serve-branches) | 23:43 |
| beuno | will that make you happy? | 23:43 |
| mwhudson | beuno: "Port Loggerhead should listen on. 8080 is the default one." | 23:46 |
| mwhudson | is a bit clunky | 23:46 |
| mwhudson | maybe just | 23:46 |
| mwhudson | "Port Loggerhead should listen on (default 8080 is the default." | 23:46 |
| rocky | hm, any reason NEWS.html hasn't been updated to reflect the latest bzr rc releaes? | 23:47 |
| mwhudson | "Port Loggerhead should listen on (defaults to 8080)." | 23:47 |
| beuno | mwhudson, fair enough. it did feel odd. Any other changes to the other strings? | 23:49 |
| mwhudson | i think it's ok | 23:50 |
| mwhudson | lets see what lifeless says | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
