| jml | poolie: hi | 00:16 |
|---|---|---|
| poolie | jml, hi | 00:21 |
| Odd_Bloke | Moin. | 00:22 |
| jml | poolie: I was thinking about branches last night. | 00:22 |
| jml | Odd_Bloke: g'day | 00:22 |
| poolie | jml, btw i'm on leave today | 00:22 |
| jml | poolie: oh. | 00:22 |
| poolie | i will be around a bit | 00:22 |
| jml | poolie: in that case I'll talk to you about branches tomorrow :) | 00:22 |
| poolie | :) | 00:22 |
| poolie | i am going to check on my stacking merge for a bit though | 00:22 |
| poolie | there are still some test failures in the top of robert's loom | 00:23 |
| * jml nods sagely | 00:23 | |
| poolie | unless he somehow fixed them | 00:23 |
| poolie | mm | 00:23 |
| poolie | i wish it was done | 00:23 |
| Odd_Bloke | jml: Hey. :) How's it going? | 00:25 |
| jml | Odd_Bloke: well, actually. | 00:25 |
| jml | Odd_Bloke: I'm experimenting to see if rememberthemilk is better than emacs for my nefarious purposes. | 00:26 |
| === edcrypt is now known as edcrypt_ | ||
| Odd_Bloke | poolie: When you're next free, I'd like to have a chat. :) | 01:26 |
| poolie | Odd_Bloke: how about this time tomorrow? | 01:27 |
| Odd_Bloke | poolie: Sure, that should be fine. | 01:28 |
| tro | with bzr-loom, is it possible to merge the changes in the upper thread down? when i use combine-thread it just tosses my changes | 02:03 |
| spiv | tro: you could do "bzr merge -rthread:THREAD-NAME" | 02:03 |
| tro | ah | 02:03 |
| tro | i'll try that. what does bzr record do? | 02:04 |
| spiv | It saves the state of the loom (i.e. the current threads and what revisions they are at). | 02:05 |
| tro | when would i use it? after commits? or only when i move from one thread to another? | 02:05 |
| tro | bzr merge -rthread:initial | 02:05 |
| tro | bzr: ERROR: No location specified or remembered | 02:05 |
| spiv | Just before pushing, basically. | 02:05 |
| tro | ah ok | 02:06 |
| tro | the same error occurs when i do just "bzr merge -r thread:" | 02:07 |
| spiv | Oh, | 02:07 |
| spiv | "bzr merge -rthread:initial ." | 02:07 |
| spiv | Merge needs a location, not just a revisionspec. | 02:07 |
| spiv | I just tested, and that does work. | 02:08 |
| tro | indeed. thanks | 02:08 |
| tro | loom comes in useful, when working with source inside an environment, which is tedious to set up | 02:09 |
| spiv | The idea with record is that eventually it'll facilitate merging looms; i.e. if someone branches off your loom, and makes changes including adding/combining threads, you'll be able to merge their loom state back into yours nicely. | 02:09 |
| tro | o neat | 02:09 |
| spiv | I don't think that's fully ready yet, but looms are already very useful :) | 02:09 |
| tro | is there a reason why creating a new thread and then merging it back into the original results in the revision number having not one but two more decimal points? | 02:10 |
| tro | ie. rev 1 -> rev 2 -> rev 2.1.1 > rev 3 | 02:11 |
| tro | 2 is the branch point | 02:11 |
| spiv | tro: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers | 02:11 |
| tro | ok thanks | 02:11 |
| spiv | It's not specific to looms, that's how bzr revision numbering works in general. | 02:12 |
| ozzloy | please help http://pastebin.org/49528 what am i doing wrong? | 02:48 |
| RAOF | ozzloy: You're merging from the wrong directory. | 02:50 |
| ozzloy | so i am | 02:50 |
| RAOF | bzr push sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/avk/itms ... Merging from remembered location sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/itms/ | 02:50 |
| spiv | ozzloy: as RAOF says, there's a missing "avk/" in the remembered location. Do "bzr merge --remember sftp://ozzloy.lifeafterking.org/~/public_html/avk/itms" | 02:51 |
| ozzloy | hooray! | 02:53 |
| ozzloy | that was a tad slow, but yay! | 02:53 |
| ozzloy | something to work on tomorrow. thank you! | 02:53 |
| === Linnk is now known as Tank|Away | ||
| hypatia_ | Probably tedious licencing question: does Bazaar really regard its logo as GPL? There have been uploads to Wikimedia on that basis: http://commons.wikimedia.org/wiki/Image:Bzr.jpg http://commons.wikimedia.org/wiki/Image:Bzr_icon_64.png | 03:17 |
| hypatia_ | The logo files no longer seem to be in the source tarballs and the bazaar-vcs.org website seems to be all rights reserved. | 03:18 |
| Odd_Bloke | hypatia: Why do you ask? | 03:22 |
| === FBI is now known as Suiseiseki | ||
| === Suiseiseki is now known as Suigintou | ||
| hypatia | Odd_Bloke: A couple of reasons, all related to Wikimedia Commons. If those files aren't Free, they can't be on Commons, that's one reason. The other is that if the logo is GPLed, Commons should use the SVG version. | 03:24 |
| hypatia | The current justification for them being on Commons is that, apparently, as of the beginning of 2008 they were included in the tarball of Bazaar itself, which has a LICENCE file saying it's GPL. The logo files are no longer in the repo that I can see. | 03:26 |
| hypatia | If they ever were, I have not searched the history yet. | 03:26 |
| spiv | hypatia: FWIW, I don't see a logo in the bzr-1.1 tarball, which was released mid-Jan 2008. | 03:29 |
| jelmer | hmm, would be nice to have some clarification about that | 03:29 |
| hypatia | spiv: I am currently running bzr log on your laptop, so we'll see. | 03:29 |
| jelmer | bzr-gtk still ships them | 03:29 |
| spiv | Heh. | 03:29 |
| spiv | Unfortunately poolie isn't around today. | 03:30 |
| Odd_Bloke | If they aren't free, they should be. | 03:30 |
| spiv | Odd_Bloke: yeah | 03:30 |
| hypatia | They are not in Ubuntu's .deb of bzr. | 03:30 |
| Odd_Bloke | Else Debian'll have to package bzr as IceMarket. | 03:30 |
| jelmer | any nested tree gurus around? | 03:31 |
| spiv | Odd_Bloke: heh | 03:31 |
| jelmer | The serializer appears to forbid reference_revision to be None, but other parts of the code seem to assume that's a valid value | 03:31 |
| jelmer | LarstiQ_: pingz0rz? | 03:31 |
| Odd_Bloke | Is packages.ubuntu.com being unresponsive for anyone else? | 03:38 |
| bob2 | yes | 03:40 |
| Odd_Bloke | OK, I just found an Ubuntu mirror and looked at the diff.gz, which saved time. :p | 03:41 |
| lifeless | moin | 05:06 |
| Verterok | hi lifeless | 05:06 |
| hypatia | Looks like the bzr repo has never contained the logo. | 05:21 |
| chandlerc | how can you do a non-destructive revert after adding a file you don't want versioned? | 05:25 |
| spiv | bzr rm --keep FILE | 05:26 |
| chandlerc | --keep might be a nice flag for bzr revert | 05:27 |
| chandlerc | but thanks, that worked like a charm | 05:27 |
| spiv | Although bzr rm will not delete the file if bzr thinks there might be uncommitted changes to it. | 05:27 |
| mwhudson | hi lifeless | 05:28 |
| chandlerc | will bzr revert? | 05:28 |
| chandlerc | that would be unfortunate default behavior, but it was what the help indicated would happen | 05:28 |
| chandlerc | =/ | 05:28 |
| spiv | bzr revert won't delete an uncommitted file either (You can test for yourself with "bzr init foo; cd foo; echo hello > hello.txt; bzr add; bzr revert") | 05:29 |
| chandlerc | ahh | 05:30 |
| chandlerc | the basic "bzr help revert" didn't indicate that behavior clearly to me | 05:30 |
| chandlerc | but good to know! =] that's what i wanted it to do, and I had done it once, and the output seemed to indicate it was deleting files, so I was concerned | 05:30 |
| spiv | The help text talks a bit about how it will make a backup of the file "if appropriate", which sort of hints that it's careful not to destroy your work. | 05:31 |
| spiv | But yeah, it could be clearer. | 05:31 |
| chandlerc | yea, i read the creating a backup to mean it *would* destructively modify the file, which is why it needed a backup | 05:32 |
| chandlerc | and in this case, i added a *very* large directory, so going through and renaming stuff would have been... messy... ;] | 05:33 |
| lifeless | spiv: ping | 05:37 |
| spiv | lifeless: pong | 05:37 |
| lifeless | you're about to get mail ;) | 05:37 |
| ozzloy | spiv: RAOF: thanks, btw | 05:41 |
| lifeless | spiv: its queued | 05:41 |
| Odd_Bloke | abentley: Am I right in thinking that you had some work on merge directive support in PQM somewhere? | 05:41 |
| spiv | ozzloy: not a problem | 05:41 |
| lifeless | spiv: mail should have reached you:) | 05:51 |
| Odd_Bloke | If someone could add me to the list of people allowed to post to bazaar-commits, it'd be appreciated. | 06:13 |
| === arjenAU2 is now known as arjenAU | ||
| lifeless | poolie: ping | 07:34 |
| === doko__ is now known as doko | ||
| chandlerc | what provides bzrlib.knit.* stuff? | 08:40 |
| lifeless | chandlerc: how do you mean 'provides' ? | 08:40 |
| chandlerc | i'm getting an ImportError | 08:40 |
| chandlerc | i have bzr 1.6b2 installed.. wondering if i need some additional libraries | 08:41 |
| lifeless | chandlerc: you probably have a 1.6b3 version of some plugin | 08:41 |
| chandlerc | hrm | 08:41 |
| chandlerc | annoying... trying to follow a release branch of bzr-svn, but don't really want to be quite so bleeding edge with bzr itself | 08:42 |
| chandlerc | highly annoying as the released version doesn't work with 1.6b2 and contains a couple of bugs fixed in the release branch | 08:45 |
| ToyKeeper | That reminds me... I've been meaning to fix my dual bzr/bzr.dev install setup so it doesn't try to use the wrong version of plugins. | 08:51 |
| ToyKeeper | IIRC there was an article on an easy way to do that, if I can find it. :) | 08:52 |
| lifeless | jelmer: ^ see chandlerc's comment :P | 08:54 |
| lifeless | ToyKeeper: basically, don't use ~/.bazar/pluings for ones that hace trouble, instad link them to bzrlib/plugins/ in the version you want them for | 08:54 |
| lifeless | ToyKeeper: our export a bZR_PLUGINS_PATH | 08:54 |
| LarstiQ_ | jelmer: pongzorz | 08:58 |
| lifeless | Odd_Bloke: ping | 09:06 |
| lifeless | poolie: piong | 09:06 |
| Odd_Bloke | lifeless: Pong. | 09:09 |
| Odd_Bloke | poolie is on leave today, so probably isn't around. | 09:10 |
| beuno | mwhudson, check out bug #237914 | 09:15 |
| ubottu | Launchpad bug 237914 in loggerhead "please provide downloadable and applicable diffs" [Medium,Confirmed] https://launchpad.net/bugs/237914 | 09:15 |
| beuno | :) | 09:15 |
| AfC | Odd_Bloke: how'd you go with that PHP snippet? | 09:18 |
| Odd_Bloke | AfC: I looked at it, thought "I'll do this later" and haven't got around to doing it yet. :p | 09:19 |
| lifeless | Odd_Bloke: your review requests titled 'The Diff' are context-free. I'm told if you don't set a title a sensible one is chosen | 09:20 |
| AfC | Odd_Bloke: most of it is actually about creating a listing of repositories, branches, and/or empty directories as you'd expect in a normal server generated index page. The "There's a branch here" part was pretty easy". | 09:20 |
| Odd_Bloke | lifeless: I've been adding "The diff" via "Add a comment/review" just before using the "Request a review" button. I'll use the "Request a review" whiteboard for the diff in future. | 09:23 |
| Odd_Bloke | lifeless: Apologies. | 09:23 |
| lifeless | Odd_Bloke: the problem is the tmail topic | 09:23 |
| lifeless | Odd_Bloke: thumper says not to use the whiteboard | 09:23 |
| lifeless | thumper says you are setting a subject; don't do that. | 09:24 |
| lifeless | its a bug that there isa field there IMO | 09:24 |
| Odd_Bloke | I took my prompting for adding the diff from https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296 | 09:25 |
| Odd_Bloke | But in future I'll leave the subject empty. | 09:25 |
| AfC | Odd_Bloke: oh, I just realized that without the Apache config the .php I sent you is probably totally lacking in context. So, http://rafb.net/p/WihwmF64.html | 09:30 |
| lifeless | Odd_Bloke: thumper agrees that it is all his fault, and he sucks | 09:31 |
| abentley | Odd_Bloke: Here's my last work: http://code.aaronbentley.com/bzr/pqm | 09:42 |
| ChristopheT | Hi! What is considered to be a good web interface for bzr repositories? I found "bzrweb" (http://mccormick.cx/dev/bzrweb/index.py/repositories) and webserve (https://launchpad.net/bzr-webserve). | 10:14 |
| beuno | ChristopheT, Loggerhead is probably the most complete one | 10:15 |
| beuno | https://launchpad.net/loggerhead | 10:15 |
| bob2 | or launchpad itself! | 10:15 |
| james_w | hey beuno | 10:16 |
| beuno | morning james_w | 10:17 |
| james_w | are you in the office? | 10:17 |
| beuno | james_w, yeap, got here a while ago | 10:18 |
| beuno | are you here too? | 10:18 |
| james_w | yeah, I'm hiding away in the back corner. | 10:19 |
| beuno | ah, you sneaked in! I got here 9am-ish, and I'm right by the door | 10:19 |
| Odd_Bloke | lifeless: Hurrah! | 10:28 |
| Odd_Bloke | abentley: Thanks. :) | 10:28 |
| lifeless | Odd_Bloke: ? | 10:35 |
| Odd_Bloke | 08:31:19 < lifeless> Odd_Bloke: thumper agrees that it is all his fault, and he sucks | 10:35 |
| lifeless | right | 10:35 |
| === Tank|Away is now known as Linnk | ||
| mtaylor | hey all - quick question... given a revision id, is there a _sensilble_ way to find out the tags applied to the tree _after_ that revision? | 10:40 |
| lifeless | jelmer: ping | 10:40 |
| mtaylor | like, if we tag releases and want to be able to determine if a particular patch went in to a particular release... | 10:42 |
| lifeless | mthaddon: log can show tags I believe | 10:42 |
| lifeless | meh mtaylor I mean | 10:42 |
| mtaylor | lifeless: yes... it can | 10:43 |
| mtaylor | lifeless: but that makes the process ... bzr log | less ... find commit, scroll back in output looking for tags... | 10:43 |
| lifeless | mtaylor: I suggest you fle a bug wishlist wise :) | 10:44 |
| mtaylor | hehe | 10:44 |
| mtaylor | ok | 10:44 |
| mtaylor | :) | 10:44 |
| james_w | mtaylor: would 'bzr log -rrevid:foo.. | grep "tags: " | cut -d" " -f2' be considered sensible? | 10:44 |
| james_w | mtaylor: but I agree that it would be a good thing to have | 10:45 |
| james_w | hi lifeless | 10:45 |
| mtaylor | james_w: well, I've just come across another snag... | 10:59 |
| mtaylor | james_w: if I later merge from a different tree (in this case, say I'm in the 6.2 release branch and I occasionally merge up changes from the 6.1 branch) | 11:00 |
| mtaylor | then I see those 6.1 tags in my bzr log output in the 6.2 ... which would lead me to believe that the fix is "in" 6.1.11 | 11:00 |
| mtaylor | this is silly | 11:00 |
| james_w | mtaylor: true | 11:01 |
| james_w | are you mainly interested in a single tag when you do this, or are you looking for all tags? | 11:02 |
| james_w | doing it for one tag (or a list of them) is easy enough. | 11:03 |
| mtaylor | I think if I could pass a revspec to bzr tags, this would be cake | 11:03 |
| mtaylor | like | 11:03 |
| mtaylor | bzr tags -r2512.78.7.. | 11:04 |
| james_w | asking "what tags is this revision an ancestor of?" is probably straightforward as well, I'm not familiar enough with the branch.tags interface though. | 11:04 |
| james_w | I'm not sure about adding that to tags, as it would seem to be to be "list all tags that are in this revision range", not "list all tags that have the start of this range as an ancestor", which means I would expect it to return the same as the grep expression. | 11:05 |
| james_w | mtaylor: http://pastebin.com/f3b0c221d | 11:29 |
| james_w | try putting that as ~/.bazaar/plugins/which_tags.py and then run "bzr which-tags -rrevid:foo" | 11:30 |
| traduffe | hello, is there any example of post_change_branch_tip for doing anything on the repository server when a new commit arrives through a push? | 11:31 |
| traduffe | it works when i commit locally, but when i push nothing happens. i have also tried using bzr serve to no avail | 11:32 |
| traduffe | (commit locally on the server that is) | 11:32 |
| mtaylor | james_w: awesome... trying now | 11:34 |
| traduffe | perhaps it is related to the message "This transport does not update the working tree of" - i get that with both bzr+ssh://, sftp:// and bzr:// (what transport am i supposed to use?) | 11:34 |
| mtaylor | traduffe: your repository on the server should probably be created with --no-trees | 11:35 |
| james_w | traduffe: remote transports won't do that for you. | 11:36 |
| james_w | traduffe: your hook doesn't do what you want, or it isn't exectued at all? | 11:36 |
| traduffe | james_w: it is not executed at all | 11:37 |
| james_w | mtaylor: I still think a wishlist bug would be valuable, as I think this should be done right, and done in the core. | 11:37 |
| mtaylor | james_w: cool. I'll file one if I get a chance today | 11:38 |
| james_w | traduffe: I'm not familiar with hooks, so I'm not sure what to look at, sorry. | 11:38 |
| james_w | traduffe: what version are you using? | 11:38 |
| james_w | traduffe: server and client? | 11:38 |
| james_w | mtaylor: great, thanks | 11:38 |
| traduffe | james_w: version 1.5 | 11:39 |
| traduffe | at both sides (from the ppa launchpad repo) | 11:39 |
| james_w | traduffe: I don't know what to say, sorry. Hopefully someone with a clue will pipe up. | 11:41 |
| traduffe | ok! | 11:41 |
| lifeless | Jc2k: ping | 11:55 |
| Jc2k | lifeless: pong | 12:03 |
| lifeless | Jc2k: wondering if we can et your procmail recipe | 12:18 |
| Jc2k | eh, its not procmail | 12:18 |
| lifeless | or whatever it is :) | 12:19 |
| Jc2k | wget http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/download/6/mirror.py-20080624200612-su5368kmi8ua94bd-5/mirror.py?file_id=mirror.py-20080624200612-su5368kmi8ua94bd-5 | 12:19 |
| * Jc2k blinks at the url :) | 12:20 | |
| Jc2k | see the actions/ folder for how the {svn,bzr,git} mirrors are created/updated | 12:21 |
| lifeless | Jc2k: thanks! | 12:22 |
| mwhudson | yuck | 12:22 |
| lifeless | Jc2k: we're looking at making an in-conference mirror | 12:23 |
| lifeless | Jc2k: what do you think? | 12:23 |
| pygi | lifeless, ping | 12:23 |
| mwhudson | (at the url, it's too late to be clicking things) | 12:23 |
| lifeless | pygi: hi | 12:23 |
| pygi | lifeless, tell gnome people to stop being ignorant, and mentioning gitorious only in git context | 12:23 |
| lifeless | pygi: right, clearly its portable to bzr :) | 12:24 |
| pygi | lifeless, also tell them that if needed, gitorious can fully support bzr in a two-weeks timeframe | 12:24 |
| pygi | and it will, as I mentioned in my blog post, through rvcs | 12:24 |
| pygi | somebody just gotta get me the reason to do it | 12:24 |
| pygi | lifeless, what me and Jc2k mentioned is far more important ... coming up with the plan on how to do all things needed for the migration | 12:25 |
| lifeless | pygi: well, I'm doing the things | 12:25 |
| Jc2k | lifeless: an onsite mirror? if we can get the bandwidth for an initial pull | 12:25 |
| Jc2k | onsite branching, with bzr-avahi | 12:25 |
| Jc2k | shit the bed. | 12:25 |
| lifeless | Jc2k: shipping a firewire drive from london | 12:25 |
| lifeless | Jc2k: just need a machine to plug the thing into | 12:26 |
| Jc2k | lifeless: i'm bouncing up and down like a giddy goat | 12:26 |
| lifeless | Jc2k: ok, cool | 12:26 |
| pygi | lifeless, anyway, just wanted to mention that =) | 12:26 |
| pygi | if they have any problems, direct them to me xD | 12:26 |
| lifeless | pygi: thanks! will do | 12:26 |
| * pygi goes back to hacking... | 12:27 | |
| beuno | james_w, let me know when you're hungry :) | 12:32 |
| lifeless | beuno: are you still in england? | 12:32 |
| beuno | lifeless, yeah, I got sidetracked into working on other stuff :) | 12:33 |
| beuno | so I'm here til saturday | 12:33 |
| lifeless | dang | 12:34 |
| lifeless | I arive sunday | 12:34 |
| beuno | yeah, all the fun starts when I leave | 12:34 |
| beuno | that *always* happens :p | 12:34 |
| james_w | beuno: I was just thinking the same thing. What is there to do for food around here? | 12:34 |
| beuno | james_w, there's pizza express, the cafe that's mostly for takeaways, or other pubs that I'm always unable to find | 12:35 |
| beuno | lifeless, how's Guadec? | 12:35 |
| === acuster is now known as avc_afk | ||
| lifeless | good; intense | 12:35 |
| beuno | are you giving any bzr talks? | 12:35 |
| lifeless | yes, in 40 minutes | 12:42 |
| beuno | lifeless, good luck | 12:47 |
| beuno | I'm off to lunch! | 12:47 |
| lifeless | thanks! | 12:47 |
| lifeless | Jc2k: hi | 12:50 |
| lifeless | Jc2k: you moved a module to svn recently, for use with i10n right ? | 12:50 |
| Jc2k | did i? | 12:52 |
| * Jc2k blinks | 12:52 | |
| lifeless | or maybe it was someone else.. | 12:52 |
| lifeless | Jc2k: it was gnome-specimen | 13:08 |
| lifeless | uws: ping | 13:09 |
| lifeless | http://uwstopia.nl/blog/2008/06/gnome-specimen-now-in-gnome-svn | 13:11 |
| lifeless | ^ - so , danilo is looking at making this work straight out of i10n | 13:11 |
| === avc_afk is now known as acuster | ||
| sven | hi! i get a traceback when running 'bzr annotate file.OTHER' while merging, if file is removed locally and modified in the other branch | 13:42 |
| sven | i can reproduce it with this: http://pastebin.com/m3837d47e | 13:42 |
| sven | using bzr 1.5 | 13:43 |
| sven | and also 1.6b3 | 13:44 |
| _paneb | i created a branch locally, added some code, and pushed it to a remote repository. when i ssh into the remote machine, the remote branch has no working tree - is this normal? | 13:47 |
| lifeless | sven: please file a bug | 13:47 |
| sven | lifeless, ok | 13:47 |
| lifeless | _paneb: yes, totally normaly - other people can branch from this | 13:48 |
| _paneb | ok | 13:55 |
| _paneb | ok now i have my local mirror of the remote (trunk). i want to create a new branch for a new feature. i do bzr branch trunk feature-X locally against my mirror branch. when i do bzr log in feature-X, the branch nick is still 'trunk' | 13:57 |
| jelmer | yes, because the commits were created in that branch | 13:58 |
| bob2 | the nick affects future commits | 13:58 |
| bob2 | 'bzr nick' will show you what it will be recorded as | 13:58 |
| _paneb | ah | 13:59 |
| _paneb | ok, thanks | 13:59 |
| MvG | I just wondered, is there a way to have a single working tree switch between different branches? | 13:59 |
| LarstiQ_ | MvG: bzr switch | 13:59 |
| MvG | Use case: large compiled project and I'm working on multiple features. | 13:59 |
| bob2 | yes, with the 'bzr switch' command | 13:59 |
| LarstiQ_ | MvG: which is useful in exactly that usecase, yes :) | 13:59 |
| * MvG is reading switch help | 13:59 | |
| MvG | Ah, so I create a lightweight checkot initially, and then use switch to change the branch. Nice. Thanks! | 14:01 |
| guilhembi | abentley: hello! could you please post an update in support issue 2413? A colleague hit a criss-cross merge where the merge3-per-file bzr version gives seemingly bad content conflicts, as we had already observed, and which is a problem you were working on. | 14:05 |
| sven | lifeless, ok, i filed https://bugs.launchpad.net/bzr/+bug/246573 | 14:06 |
| ubottu | Launchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Undecided,New] | 14:06 |
| MvG | jelmer: Are there any news in bzr-svn regarding fetching history explicitely for the given branch, as opposed to implicitely for each history request not contained in the cache? | 14:08 |
| guilhembi | abentley: the colleague is Sven who is on this channel, by the way. | 14:08 |
| lifeless | sven: tanks! | 14:09 |
| guilhembi | abentley: he used the "bzr merge --mysql" plugin to kill those conflicts, | 14:09 |
| _paneb | and finally, how do i create a release (export) from the remote trunk, given that it has no working tree? | 14:09 |
| jelmer | MvG: not particularly | 14:09 |
| guilhembi | abentley: but this feels a bit anxious, as one cannot be sure that all of them were incorrect. So we're looking forward to the full solution. | 14:09 |
| jelmer | MvG, I've kept my svn-1.5 branch up to date with the 0.4 branch and started looking into the logic behind all this and then got distracted | 14:09 |
| sven | hi guilhembi and lifeless! yes, would be very nice to have a solution to this! the merge --mysql thing is good, but i have to go through all the content conflict files and check the result... | 14:11 |
| MvG | jelmer: Understandable. As long as it isn't forgotten completely, that should be all right. | 14:11 |
| MvG | jelmer: Especially as current 0.4 branch seems to work with svn-1.5 as well, there is not that much of a hurry. | 14:12 |
| bob2 | _paneb: normally you'd use your local version of it, but bzr export takes a branch argument | 14:12 |
| _paneb | bob2, ok, i'll use the local branch, but i did pass the branch to export | 14:13 |
| bob2 | _paneb: and what happened? | 14:13 |
| _paneb | bob2, i inverted the branch name and archive names :P | 14:14 |
| LarstiQ_ | jelmer: you pinged me for something? | 14:25 |
| jelmer | LarstiQ_, yeah, nested tree support | 14:25 |
| jelmer | LarstiQ_, What's the status ? :-) | 14:25 |
| LarstiQ_ | jelmer: the same as in London afaik | 14:25 |
| jelmer | LarstiQ_, Also, do you know whether it's possible to nest another branch | 14:25 |
| jelmer | without specifying a revision in that branch | 14:25 |
| === LarstiQ_ is now known as LarstiQ | ||
| jelmer | or, to word it differently, is it possible to nest the tip of another branch rather than a specific revision | 14:26 |
| LarstiQ | jelmer: as in, always pull the latest version? | 14:26 |
| jelmer | yeah | 14:26 |
| LarstiQ | jelmer: I don't think so | 14:27 |
| jelmer | crap, that makes nested trees unusable for svn:externals :-/ | 14:27 |
| LarstiQ | you think? | 14:27 |
| LarstiQ | jelmer: ime svn:externals are mostly pinned at a specific revision. | 14:27 |
| jelmer | It is possible to pin them, but almost nobody uses the pinning | 14:28 |
| LarstiQ | still would like to update once in a while of course | 14:28 |
| LarstiQ | jelmer: hmmm, our experiences conflict :) | 14:28 |
| jelmer | in particular because the revision an external is pinned to is annoying to update | 14:28 |
| jelmer | you have to update the external | 14:28 |
| LarstiQ | propedit it? | 14:29 |
| jelmer | yeah | 14:29 |
| jelmer | well, at least that makes it easy to decide whether to wait for nested trees before I introduce that new mapping format... | 14:31 |
| LarstiQ | ok, let met dig through the code a bit. | 14:33 |
| awilkins | jelmer: Hello, was that log informative at all for the bindings? | 14:34 |
| jelmer | awilkins, yeah, I just haven't had much time to look into them yet :-/ | 14:40 |
| jelmer | though some may be fixed now because of the move away from fs access | 14:41 |
| === tale is now known as tethridge | ||
| jelmer | awilkins, Yeah, any chance you can run it again? | 14:46 |
| jelmer | the number of errors should've gone done quite a bit | 14:46 |
| LarstiQ | jelmer: fs access? | 14:46 |
| jelmer | LarstiQ: Rather than using a working copy to create revisions for testing | 14:46 |
| jelmer | we now talk directly to the database | 14:46 |
| LarstiQ | jelmer: ok, I'm severely lacking context | 14:47 |
| jelmer | LarstiQ: this is in bzr-svn | 14:47 |
| LarstiQ | jelmer: that I understood :) | 14:47 |
| jelmer | LarstiQ: using a working copy to build revisions is quite slow | 14:47 |
| jelmer | (an actual directory in the file system we modify and then commit in) | 14:47 |
| jelmer | mainly because svn sleeps in between operations to avoid funny timestamp business | 14:48 |
| jelmer | instead, we now just talk to the Subversion repository directly without using a working copy | 14:48 |
| === Christop` is now known as ChristopheT | ||
| LarstiQ | jelmer: an svn working copy? | 14:48 |
| jelmer | LarstiQ: yes | 14:49 |
| jelmer | Bazaar doesn't have working copies, only working trees :-P | 14:49 |
| awilkins | jelmer: I'll run it later, this isn't my build machine | 14:50 |
| LarstiQ | jelmer: oh feh terminology ;P | 14:50 |
| MvG | jelmer: Current bzr.dev and bzr-svn 0.4 repeatedly fail to branch the inkscape repo for me: http://rafb.net/p/fvOeJD27.html | 14:51 |
| MvG | Looks like the server became impatient and dropped the connection, but I would expect bzr-svn to reestablish connection at least once before giving up. | 14:52 |
| jelmer | MvG: Reconnecting would be a job of the svn client library imho | 14:53 |
| jelmer | MvG: The problem is that we don't have a good way to determine why an operation fails | 14:53 |
| jelmer | the same error code is returned for everything that fails when using the webdav transport | 14:54 |
| MvG | jelmer: We could examine the error message, serach for "connection.*closed" or some such. | 14:54 |
| MvG | Ugly, I know. | 14:54 |
| jelmer | The error message is useless since that can be localized | 14:54 |
| MvG | :-( | 14:54 |
| MvG | Still a dropped connection would differ from most other errors in that retrying the exactly same operation again would succeed. | 14:55 |
| jelmer | Yeah, but that would mean adding fallback code everywhere and that seems too much for a workaround like this | 14:56 |
| MvG | So how would you suggest I proceed? Try to implement reconnects, fall back to using svn without bzr, or bug the subversion lib devs trying to get reconnects and/or sensible error messages there? | 14:56 |
| jelmer | well, simplest solution would just be to run the command again and let bzr-svn continue where it stopped | 14:56 |
| jelmer | but in the end the subversion lib should be fixed first | 14:57 |
| chandlerc | jelmer: any clue on using the 0.4 bzr-svn branch with bzr 1.6b2? | 14:57 |
| MvG | Which I did before I wrote about "repeatedly failing" up there. | 14:57 |
| jelmer | chandlerc: You need a newer version of bzr than 1.6b2 | 14:57 |
| chandlerc | =/ | 14:58 |
| jelmer | MvG: Try the command again as a user I mean | 14:58 |
| chandlerc | jelmer: where would i get it from? i'd rather not run bzr right off the tip of development | 14:59 |
| chandlerc | (if i can even do that) | 14:59 |
| MvG | jelmer: I already deleted the branch directory and restarted the branch command from the command line. As the shared repository was still in place I had hoped it would continue there, but it seems that wasn't enough. | 14:59 |
| jelmer | chandlerc: You would need bzr.dev for the 0.4 branch at the moment | 14:59 |
| jelmer | MvG: If the shared repo is still there, it should be continuing | 15:00 |
| jelmer | MvG: Does "bzr info" in the repo say those revisions are there? | 15:00 |
| MvG | jelmer: 0 revisions. The last message from bzr-svn was "determining changes". No status message afterwards yet, seems to be still working. Not much network traffic either. | 15:03 |
| jelmer | MvG: it may've saved the cache though | 15:04 |
| MvG | jelmer: Yes, the cache should be complete. Command just died again. Next time around I guess I'll wireshark things. | 15:05 |
| Odd_Bloke | Woo, I have merge-directives working in PQM. | 15:09 |
| Odd_Bloke | In a 'has worked once for me' type of way, before anyone gets too excited. :p | 15:09 |
| jelmer | Odd_Bloke: W00t! Congrats :-) | 15:09 |
| === mw|out is now known as mw | ||
| Odd_Bloke | Almost entirely Aaron's work. | 15:10 |
| chandlerc | jelmer: is running bzr.dev viable? ie, is it stable enough to use day to day? | 15:13 |
| chandlerc | jelmer: i would gladly run the released bzr-svn and avoid all of this, but there are bugs fixed since then that I depend on. ;] | 15:14 |
| jelmer | chandlerc: yeah, I've been doing so for the last two and a half years without any problems whatsoever | 15:14 |
| jelmer | Odd_Bloke: Still, this is nice to finally have | 15:14 |
| Odd_Bloke | jelmer: Yeah. :) | 15:15 |
| MvG | jelmer: OK, the network is busy all the time with PROPFIND requests. Not much of throughput, so it didn't show up on my network usage docklet. I got a gdb stack trace somewhere in between, and it lists ra_get_dir as the function called from python, but as the error message indicates _fetch_switch instead, I'd rather assume the issue to occur in the switching code. Can you reproduce the issue? | 15:21 |
| jelmer | MvG, what's the url exactly? | 15:23 |
| MvG | jelmer: http://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk is the branch, http://rafb.net/p/fvOeJD27.html my error command line and error message. | 15:24 |
| jelmer | MvG: You know about -Dtransport? | 15:27 |
| MvG | jelmer: In theory yes. Should I try to get a log for this? | 15:28 |
| jelmer | MvG: I suspect this is just the server being a pain | 15:29 |
| jelmer | so far everything is working smoothly here though | 15:29 |
| MvG | jelmer: Do you have any idea what bzr-svn is doing all the time here? It prints a progress bar about determining what revisions to fetch, that bar vanishes about halfway through, and afterwards I see nothing and the code calls those get_dir things and issues PROFIND requests for various dirs. SHouldn't all that information be available form the log? | 15:31 |
| jelmer | MvG: It's figuring out what revisions are present in Subversion and which ones are missing in bzr | 15:31 |
| jelmer | MvG, it needs to look at the file properties of a path to figure out what its revision id is | 15:32 |
| MvG | So basically it's asking the server for each and every dir in the tree to tell it what files are present and what revisions IDs they have? I thought revision IDs were a bzr thing. | 15:33 |
| jelmer | MvG: It's only looking at the file properties of the branch itself | 15:34 |
| jelmer | so /trunk usually | 15:34 |
| jelmer | MvG: But revision ids have to be preserved when pushing revisions into Subversion | 15:34 |
| MvG | jelmer: My wireshark capture says otherwise. | 15:34 |
| jelmer | and they're stored in file ids | 15:34 |
| jelmer | s/file ids/file properties/ | 15:34 |
| MvG | I see. Still looks like something was going wrong here. | 15:35 |
| jelmer | MvG: It's doing requests for get_dir() on things other than branch paths? | 15:35 |
| Odd_Bloke | Was just debugging why PQM wasn't accessing remote source locations when using merge directives. I hadn't actually created the remote branch. >.< | 15:35 |
| MvG | It's difficult to match network traffic to function calls, or trace the lib calls in some sensible way, but I think so. | 15:36 |
| MvG | As it was running get_dir at some arbitrary point during all those PREOFIND requests, I'd assume get_dir to be the source of at least most of those. And as I'd assume get_dir to only issue a handful of such requests, I think there is either a bug in get_dir or it's being called repeatedly. | 15:37 |
| jelmer | MvG: get_dir() is being called repeatedly | 15:37 |
| jelmer | MvG: It's probably called awfully often but hopefully only doing a single request each time | 15:38 |
| MvG | jelmer: I have the -Dtransport log ready. Opening RA connection to repo root, then a long break, then a list of unsupported properties immediately followed by the traceback. | 15:38 |
| LarstiQ | isn't that worse than doing more requests less often? | 15:38 |
| jelmer | LarstiQ: There is no way you can get multiple results out of get_dir() | 15:39 |
| MvG | jelmer: Why is it called awfully and there are PROPFINDs for different dirs when you are only interested in the file properties of the branch itself? Or do you mean all files within the branch as well? | 15:40 |
| jelmer | MvG: It's called for each revision in which the branch path changed | 15:40 |
| MvG | more requests less often would seem like less overhead. | 15:40 |
| jelmer | MvG: I'm pretty sure it's not called for the files inside of the branch | 15:40 |
| jelmer | MvG: Though they are returned by get_dir() | 15:40 |
| Odd_Bloke | Right, I'm done for the day. | 15:40 |
| Odd_Bloke | I'll send the merge directives patch in tomorrow, I want to make sure I'm not too tired when checking through it. | 15:41 |
| Odd_Bloke | Also I think I'm beginning to become one with this chair. | 15:41 |
| MvG | jelmer: Your branch still progressing smootly? I've reproduced the problem several timjes here in that time, so if it survived up to now, it's likely to continue to its completion. | 15:41 |
| jelmer | MvG: yeah, it works fine here | 15:41 |
| jelmer | I'm actually updating an existing branch | 15:42 |
| jelmer | I'll try a fresh one | 15:42 |
| jelmer | MvG: Can you pastebin that .bzr.log file somewhere? | 15:42 |
| MvG | jelmer: Strange. You're on svn 1.5? | 15:42 |
| jelmer | yeah, Subversion 1.5 (not the svn 1.5 branch) | 15:42 |
| MvG | jelmer: No difference there. Which makes the different behaviour even stranger. | 15:43 |
| MvG | jelmer: http://rafb.net/p/H2WMRd54.html | 15:45 |
| === thekorn_ is now known as thekorn | ||
| Pieter | lifeless: bzr.dev is ~25MB in git, which might be a better comparison than the NEWS file, so if the 0.4:0.6 ratio then keeps up, you're looking at ~18MB for bzr.dev | 15:50 |
| lifeless | Pieter: yes, I did a test run with more data and got 16MB for the texts | 15:50 |
| lifeless | totally untuned yet though, I think I can probably get higher and make some different tradeoffs with better compressor heuristics | 15:51 |
| lifeless | been doing talks and stuff since | 15:51 |
| abentley | guilhembi: jam would be the best person for that, since he's working on the issue right now. | 15:52 |
| jam | lifeless: as an aside (i'm *really* trying to get the merge stuff done right now :). How long of a delta chain are you allowing, and how does that impact decompression speed | 15:52 |
| lifeless | jam: well, decompresion is decompress(); parse-delta; copy-bytes-from-basis | 15:53 |
| lifeless | jam: so the IO and decompression size emittied is really the cactor, *not* the length of the chain | 15:53 |
| lifeless | currently 60% of reconstruction is in cStringIO.readlines | 15:54 |
| lifeless | so I'm going to eliminate that call altogether for the basis | 15:54 |
| MvG | jelmer: I've managed to extract the HTTP requests from my network capture: http://rafb.net/p/Mc5IIX11.html | 15:55 |
| jelmer | MvG: they're not very useful without the calls that call them | 15:56 |
| jelmer | s/call/cause/ | 15:56 |
| jam | lifeless: another aside... we may want to consider a pyrex extension to split a string on '\n', since we can't use string.splitlines() | 15:56 |
| lifeless | jam: right; or just not do splitting :P | 15:57 |
| jam | split('\n') strips the final '\n' out, so we can't strictly use that eihre | 15:57 |
| jam | lifeless: well, once we rewrite the apis to allow that | 15:57 |
| tro | i'm using bzr-loom 1.3 with bzr 1.5 on python 2.5 on windows. when i merge changes from a thread immediately above the current using merge -rthread:above it merges fine, but then when i up-thread i have to merge again for some reason. | 15:57 |
| tro | this results in some strange looking merge graphs in bzr vis | 15:57 |
| tro | the merge doesn't change any files, because i just transfered all the changes from the upper thread into the lower one, so shouldn't moving back up not change anything? | 15:57 |
| lifeless | tro: well, once you've merged the thread above, you don't need that thread anymore, right ? | 15:57 |
| tro | lifeless: but i do. i have more stuff to change. the merged stuff is just the immediate changes needed by the lower thread | 15:58 |
| lifeless | tro: there is an open bug about this actually, its mainly UI love, to 'fast forward' the thread for you | 15:58 |
| lifeless | tro: oh, so you're not merging everything from the thread above? | 15:58 |
| tro | lifeless: i'm merging everything, but i'd like to continue working on that thread after i've merged. the upper thread is potentially a big feature that i'd like to merge incrementally into the stable thread (lower) as i get work done on the upper | 15:59 |
| tro | i guess i have to create a new thread for every such merge? | 15:59 |
| lifeless | tro: as a workaround yes | 16:00 |
| tro | ok, thanks. i'll search and subscribe to the bug | 16:00 |
| lifeless | just merge; commit; create-thread thing; switch old-thread' bzr combine-thread | 16:00 |
| tro | speaking of combine-thread, i think it's a little misleading. i would expect that operation to merge my changes into the lower thread, but instead if just tosses them. it's a good thing i tried it out on a test branch first before using it for real :) | 16:02 |
| tro | maybe it should just be renamed to delete-thread? | 16:03 |
| tro | i can't seem to find the bug. maybe my search-fu isn't up to launchpad's par. what should i be looking for? bzr-loom returns nothing | 16:03 |
| tro | oh. i should be looking in the bzr-loom launchpad, of course, not bzr | 16:04 |
| MvG | jelmer: I'm running the command through gdb and pdb to find out more about the causes. "determining revisions to fetch" has 19219 to go, but is done after 8576. strange. | 16:08 |
| jelmer | MvG, new clone breaks here as well | 16:08 |
| jelmer | MvG: that may make sense, if the branch was created in that revision for example | 16:09 |
| MvG | Is there any decent way to figure out what python function invoked a given native C function? Like who called ra_get_dir? The gdb stack trace isn't much help, and my pdb breakpoints seem to have missed the invocation. | 16:10 |
| MvG | jelmer: Unlikely for trunk, but possible. | 16:10 |
| jelmer | MvG: There are gdb macros that allow you to print the python stack from within gdb | 16:11 |
| jelmer | MvG, another possibility is that you already had the revisions up to 8576 | 16:11 |
| jelmer | MvG, alternatively you can just add more mutters | 16:12 |
| MvG | I somehow doubt that the gdb macros will be much use, as most function call parameters seem to be optimized out. | 16:13 |
| jelmer | they work fine here | 16:14 |
| jelmer | hmm, the knits files don't appear to be written to disk anymore | 16:14 |
| MvG | jelmer: I've got a high-priority issue here. I guess I'll be looking at the inkscape issue later on again. If you can find more about it by then, I'd of course be more than happy. | 16:15 |
| jelmer | MvG, k | 16:16 |
| lifeless | MvG: I know that ted succeeded with inkscape | 16:19 |
| lifeless | MvG: And that it was _slow_ due to sf.net | 16:19 |
| lifeless | MvG: perhaps you could branch his converted branch as starting point | 16:19 |
| MvG | lifeless: With current bzr-svn and bzr.dev starting from scratch? Might well be that the slowness is mostly due to sf.net, but still its annoying that bzr-svn is so much slower than svn itself. Prevents people from switching to bzr. | 16:20 |
| MvG | lifeless: I guess I could, but I coluld also start from my svn checkout, or from the lp mirror, as I don't intend to push any changes. | 16:20 |
| lifeless | MvG: we traced it - sf.net was taking many seconds per request | 16:21 |
| MvG | Still, I'm usually more interested in fixing issues that I encounter than in working around them. | 16:21 |
| lifeless | MvG: they have some scaling issues | 16:21 |
| lifeless | MvG: I agree; using --stacked will help somewhat, when al lthe pieces have landed | 16:21 |
| jelmer | MvG: a large part of slowness in bzr-svn is due to bzr itself | 16:24 |
| mtaylor | bzr: ERROR: bzrlib.errors.ReadingCompleted: The MediumRequest '<bzrlib.smart.medium.SmartClientStreamMediumRequest object at 0xb787a68c>' has already had finish_reading called upon it - the request has been completed and no more data may be read | 16:28 |
| mtaylor | that ring any bells with anyone? | 16:29 |
| === jaypipes_mysql is now known as jaypipes | ||
| lifeless | mtaylor: thats usually a second-order error | 16:31 |
| lifeless | mtaylor: I believe spiv has posted some stuf about debugging that | 16:31 |
| jelmer | MvG: Found the error | 16:33 |
| jelmer | for some reason we're trying to update between 10643<->10643 | 16:33 |
| jelmer | and the sf.net server doesn't like that :-P | 16:33 |
| MvG | jelmer: Will you write a fix? | 16:34 |
| jelmer | I'm looking into how hard it is | 16:34 |
| jelmer | It appears to be caused by tricky changes | 16:34 |
| jelmer | A /inkscape/trunk (von /trunk/inkscape:10642) | 16:34 |
| jelmer | D /trunk/inkscape | 16:34 |
| MvG | Sounds like one would want a test case for such tricky situations, and ensure that test fails unless the fix is in place. | 16:38 |
| jelmer | yeah, I always do that for regressions | 16:39 |
| mtaylor | lifeless: I'm getting an error from search... | 16:43 |
| jelmer | jam, lifeless: What's the plan for 1.6? | 16:44 |
| mtaylor | lifeless: http://pastebin.com/m6bd9746e | 16:44 |
| jelmer | MvG, Hmm, I spoke too soon | 16:54 |
| jelmer | MvG: it has to do a fresh checkout in that case so it's correct behaviour | 16:54 |
| MvG | jelmer: Requesting update for the same revision is correct behaviour? | 16:55 |
| jelmer | MvG: Yes, iff you specify start_empty=True | 16:55 |
| jelmer | that basically means "send me all the data in this revision" | 16:55 |
| jelmer | jam: ping? | 17:27 |
| jam | jelmer: ?? If it is about 1.6, I don't really know what the plan is. I'll try to bring it up at the next standup meeting. My best guess is that we are waiting for Stack to land, and Martin is working on that ATM | 17:29 |
| jelmer | jam: Ah, thanks | 17:29 |
| jelmer | jam: The other question was about my ignore patch | 17:29 |
| jam | sure | 17:29 |
| jam | I think the functionality *belongs* as a 'tree.add_ignore' | 17:30 |
| jam | That doesn't meanit has to happen now | 17:30 |
| jelmer | jam: You voted tweak - what tweak would you like to see exactly? | 17:30 |
| jam | bzrlib.ignores.XXX is much better than wallowing i ncmd_ignore | 17:30 |
| Odd_Bloke | That was my first thought when I glanced at the patch. | 17:30 |
| jam | jelmer: I would *like* to see it moved to Tree | 17:30 |
| jam | if you feel that is too much, than I probably would just approve | 17:30 |
| jelmer | jam: Ah, ok - thanks | 17:31 |
| jelmer | I agree MutableTree is a better place | 17:31 |
| jam | Odd_Bloke: then you should be participating in the code reviews more :) | 17:31 |
| jelmer | Odd_Bloke, Do you have voting rights yet? | 17:31 |
| jam | jelmer: anyone can send a 'bb:approve' even if bb doesn't track it :) | 17:32 |
| Odd_Bloke | jelmer: Nope. | 17:32 |
| jam | jelmer: also, just to be sure, you should check the rules as far as adding a .bzrignore if it doesn't exist, etc. I think you did, but it was something that just popped into my head | 17:32 |
| jelmer | jam: There isn't anything else as far as I can tell | 17:32 |
| jam | And the tree should be write locked while all of this is happening | 17:32 |
| jelmer | jam: there are existing functions for parsing the ignore file but they ignore the order | 17:32 |
| jelmer | jam: since they use set() | 17:33 |
| jam | jelmer: sure, but there *is* a WT._get_ignore_list or something similar | 17:33 |
| jam | which uses ignores.XXX to do its work for it | 17:33 |
| jam | I'm not 100% sure why I chose a set back then, but probably to remove duplicates | 17:34 |
| jelmer | jam: It does make sense when using the ignores file | 17:34 |
| jam | jelmer: I have a favor to ask. Can you try submitting a branch for me? | 17:42 |
| jam | I've had this patch since 1.4, and when I try to submit it | 17:42 |
| jelmer | jam: Sure | 17:42 |
| jam | I see it show up in the PQM queue, but then it disappears without a success/failure | 17:42 |
| jam | http://bzr.arbash-meinel.com/branches/bzr/1.4-dev/non_utf8_77657 | 17:42 |
| jam | I suppose I should try pinging lifeless to have him check if I'm segfaulting PQM or something weird | 17:43 |
| jelmer | Maybe weird interaction with redirects? | 17:45 |
| jam | that branch shouldn't redirect | 17:45 |
| jam | it is just a plain apache share of the directory | 17:45 |
| jelmer | jam: It's a look branch | 17:46 |
| jelmer | s/look/loom | 17:46 |
| jam | ?? | 17:46 |
| jam | ah, I guess I need to get rid of that | 17:46 |
| jelmer | I don't have looms installed and I get: | 17:47 |
| jelmer | bzr: ERROR: Unknown branch format: 'Bazaar-NG Loom branch format 6\n' | 17:47 |
| jam | kk | 17:47 |
| jelmer | Does pqm have looms? | 17:47 |
| jam | It seems that locally it is not | 17:47 |
| jam | I'll try nuking it and re-pushing | 17:47 |
| * jelmer files a bug on PQM | 17:47 | |
| jam | ok, I just resubmitted it as a normal branch | 17:48 |
| jelmer | jam: if you have time, any chance you can look at bug 244306 ? | 17:55 |
| ubottu | Launchpad bug 244306 in bzr "push hook not executed for new branches" [Undecided,New] https://launchpad.net/bugs/244306 | 17:56 |
| jelmer | I'm considering whether push hooks *should* be executed for new branches | 17:56 |
| jam | jelmer: ATM, time is not something I have much of, I would probably say that post-changed-branch-tip should probably fire, I'm not sure if 'push' should | 17:56 |
| jam | I suppose if you created it via "bzr push ..../new-branch" | 17:57 |
| jam | it would seem a bit odd if the hook didn't fire | 17:57 |
| jam | but would it fire for | 17:57 |
| jam | bzr branch . .../new-branch | 17:57 |
| jam | L | 17:57 |
| jam | ? | 17:57 |
| jam | jelmer: is there a specific use-case you have in mind? | 17:57 |
| jelmer | jam: I have a push hook that sets public_branch in ~/.bazaar/locations.conf when I push a branch | 17:58 |
| jelmer | It's a bit annoying to always have to push twice to get that to work | 17:58 |
| jelmer | I'll just use post-changed-branch-tip for now | 17:59 |
| jam | jelmer: I would probably say that running "bzr push .../new-branch" should fire the trigger | 17:59 |
| jam | And not firing would thus be a bug | 17:59 |
| jam | jelmer: so... I agree it is a bug, I don't have any time to fix it myself :) | 18:01 |
| jelmer | jam: Thanks | 18:02 |
| jelmer | jam: I wasn't asking for a fix :-) I was unsure about how to fix this so your comments are much appreciated | 18:02 |
| jelmer | jam: I just realized this would also help eliminate svn-push | 18:17 |
| jelmer | jam: Would it make sense to add a "BzrDir.import_branch()" function ? | 18:18 |
| jam | jelmer: This eliminates svn-push because it allows you to tell the local branch to 'pull --overwrite' ? | 18:18 |
| jam | And I'm not sure what you are trying to do with 'import_branch' | 18:19 |
| jelmer | jam: At the moment cmd_push() has its own logic for creating a new branch | 18:19 |
| jam | now, if this was a *pre* push hook | 18:19 |
| jam | that would make sense for svn-push | 18:19 |
| jelmer | jam: So creating a BzrDir.import_branch() would allow the implementation of BzrDir to override the way the branch was created | 18:19 |
| jam | jelmer: I don't think I would call it 'import_branch'... | 18:20 |
| jam | And the logic in cmd_push is because of a dispute between lifeless and I | 18:20 |
| jam | basically, if the repository exists, create a branch and fetch | 18:20 |
| jam | if not, push works a bit differently | 18:20 |
| jelmer | and it would allow it to take care of running the push hook, rather than putting the logic of running the push hook in cmd_push(which would be ugly) | 18:20 |
| jam | (I wanted to change sprout()/clone() to always create the target branch and fetch, his argument was it creates a branch temporarily that is not the final valid value.) | 18:21 |
| jam | (So instead, it only does that when the target repo already exists.) | 18:21 |
| jelmer | ah | 18:21 |
| jam | the idea was to support resuming in a limited way | 18:22 |
| jam | though with packs it all goes away anyway | 18:22 |
| jelmer | so what about something like BzrDir.clone_new_branch() rather than BzrDir.import_branch() ? | 18:22 |
| jam | (packs have an all-or-nothing approach.) | 18:22 |
| jam | jelmer: I would love to have cmd_push cleaned up and split into nice helper functions | 18:24 |
| jam | I think what you are asking would only change the "elif br_to is None" logic | 18:24 |
| jam | which is the case when there is a BzrDir and a Repository, but no branch | 18:25 |
| siretart | I need to branch from an repository via http with an broken repository. However bzr fails because pycurl fails to verify it | 18:25 |
| siretart | is there some way to ignore this error? | 18:26 |
| jam | siretart: urlib+http:// | 18:26 |
| jam | is the workaround for now | 18:26 |
| jam | well, urlib+https:// | 18:26 |
| siretart | bzr: ERROR: Unsupported protocol for url "urlib+https://svn.aspectc.org/repos/Puma/trunk" | 18:27 |
| jelmer | jam: yeah, I agree | 18:27 |
| jelmer | jam: I'll give this some more thought, thanks for the comments | 18:28 |
| jam | siretart: well there youhave to ask jelmer, since it seems to be an interactiong with svn and https | 18:28 |
| siretart | jelmer: does bzr-svn work at all with urlib? | 18:28 |
| jelmer | siretart: try svn+https://svn.aspectc.org/repos/Puma/trunk | 18:28 |
| siretart | aah, much better! | 18:29 |
| siretart | thanks | 18:29 |
| jelmer | vila, ping | 18:30 |
| tolstoy | Is there any way to "tag" a branch remotely, or is there a super fast way to do it outside of that? | 18:31 |
| jam | tolstoy: 'bzr tag -d path/to/branch' ? | 18:32 |
| tolstoy | I want to create release branches over a lot of projects all at the same time, but need to tag the branch point. If I didn't need to tag, I'd just bzr branch sftp://blah/head/project sftp://blah/branch/prject. | 18:32 |
| tolstoy | jam: I think that requires running on the same machine as the repo you're branching. | 18:33 |
| tolstoy | (We're using a source-of-truth model.) | 18:33 |
| tolstoy | (Baby-steps....) | 18:33 |
| tolstoy | If I run on the actual server, branch will generate "working trees" which I don't want. | 18:34 |
| jam | tolstoy: I just tested it with bzr+ssh and it worked | 18:35 |
| jam | I would expect -d to be fine with sftp:// as well | 18:35 |
| jam | tolstoy: is the 'no-working-trees' flag set on the server? | 18:36 |
| jam | touch .bzr/repository/no-working-trees | 18:36 |
| jam | if it isn't | 18:36 |
| jam | that should prevent working trees via 'bzr branch' (bzr co still creates them) | 18:36 |
| tolstoy | Hm. Okay. There's a LOT of projects up there. I'll see if I can get bzr+ssh working instead of sftp. | 18:36 |
| jam | tolstoy: it worked via sftp as well | 18:37 |
| jam | I don't know why it wouldn't be working for you | 18:37 |
| tolstoy | jam: Hm. Okay, I'll try it again. | 18:37 |
| tolstoy | It might be that I did this before, then did a bzr pull, and got the "no revisions to pull" message, and just assumed the tags didn't come back. | 18:39 |
| tolstoy | Or a permissions issue. Oy. | 18:39 |
| jam | tolstoy: you can also try "bzr tags -d XXX" | 18:40 |
| jam | which shows you what tags are on the branch | 18:40 |
| tolstoy | Yep. The command succeeded, now to double-check. | 18:40 |
| jam | tolstoy: and I would create the 'no-working-trees' file on the "blah" server, btw | 18:41 |
| tolstoy | Okay. I'll add that to my list. It seems like a good idea. | 18:41 |
| jam | I'm /away for a bit | 18:42 |
| tolstoy | Thanks for your time! I'm super happy my company is using BZR. I feel like we've leapfrogged a bunch of other companies. | 18:42 |
| === sdboyer_ is now known as sdboyer | ||
| tolstoy | Yep. Remote tagging is working. | 19:08 |
| tro | how come bzr-loom isn't listed as one of the plugins on the bzrplugins wiki page? | 19:09 |
| ozzloy | http://pastebin.org/49698 how do i getrid of this? | 19:19 |
| luks | ozzloy: get rid of what? | 19:21 |
| luks | if you mean the working tree thing - http://bazaar-vcs.org/FAQ#head-927e36ce76d7ee3a9ef59baaf6aa839fc46c36aa | 19:22 |
| ozzloy | luks: every time i push, bzr says i need to upgrade. when i upgrade, it tells me the branch format is already the most recent. | 19:22 |
| luks | ozzloy: I'm afraid you can't ugprade working trees over network | 19:23 |
| luks | but you probably shouldn't have the working tree on server anyway | 19:24 |
| ozzloy | luks: http://pastebin.org/49700 | 19:24 |
| ozzloy | this is on the server | 19:24 |
| luks | ozzloy: bzr --version? | 19:24 |
| ozzloy | http://pastebin.org/49701 | 19:25 |
| ozzloy | 0.11.0 | 19:25 |
| ozzloy | maybe i need a backport | 19:25 |
| luks | and the format sais it needs at least 0.15 | 19:25 |
| luks | *says | 19:25 |
| luks | but 0.11 is really ancient, you should upgrade anyway :) | 19:25 |
| luks | or, since you don't use the working tree remotely, just remove it | 19:26 |
| ozzloy | luks: i use the server to share between my laptop and work computer | 19:27 |
| luks | ozzloy: but do you share the working tree or only the branch? | 19:28 |
| ozzloy | luks: i'm new to distributed version control. i'm unclear on the distinction | 19:28 |
| luks | ozzloy: branch are the data inside .bzr, working tree are the actual files you can see | 19:29 |
| luks | having the working tree on servers is usually useless, because you don't _work_ on the server | 19:30 |
| luks | you only push/pull data from the .bzr dir | 19:30 |
| ozzloy | ah | 19:30 |
| ozzloy | but isn't that what i did? push? | 19:30 |
| luks | ozzloy: yes, but you have files outside of the .bzr dir you don't use | 19:31 |
| ozzloy | so i should just delete them? | 19:32 |
| luks | if you are sure you don't have any local changes on the server, I'd so `bzr remove-tree` | 19:32 |
| luks | but you will need to upgrade bzr to do that | 19:32 |
| ozzloy | i'll have to go to #debian for that | 19:32 |
| ozzloy | hooray stable! | 19:32 |
| luks | I'm sure debian backports have recent bzr | 19:33 |
| ozzloy | (crusty) thanks for the suggestion. | 19:33 |
| luks | as there is a lot of debian people here | 19:33 |
| ozzloy | and for the help | 19:33 |
| ozzloy | although it actually seems to be working fine. i've already pushed and merged changed between the computers | 19:33 |
| ozzloy | i just get that message every time | 19:33 |
| luks | ozzloy: exactly :) | 19:34 |
| luks | bzr will not the remote working tree, so it's outdated and then it complains | 19:34 |
| luks | er, will not touch | 19:34 |
| ozzloy | icic | 19:34 |
| ozzloy | would upgrading help with the speed of the pushes and merges? | 19:34 |
| ozzloy | because those are kinda slow | 19:35 |
| luks | you _could_ fix it with one simple trick even without upgrading bzr, but I 'm not going to tell you that | 19:35 |
| luks | ozzloy: that depends on your local bzr version | 19:35 |
| ozzloy | heh, thanks for teasing me then. | 19:35 |
| luks | ozzloy: ideally you should upgrade bzr to 1.x and upgrade the branch | 19:35 |
| luks | there was a new format introduced in 0.92 (I think) which speeds up pushes/pulls especially over sftp | 19:36 |
| === sdboyer_ is now known as sdboyer | ||
| ozzloy | luks: back-ports has version 1.5 | 19:43 |
| ozzloy | and the upgrade finished | 19:43 |
| Qhestion | hi. how can i make bazaar add all files in the current directory/subdirectories, without ignoring any files? | 19:55 |
| jam | Qhestion: 'find dir -print0 | xargs -0 bzr add' ? | 19:56 |
| jam | Qhestion: if you explicitly list a file, bzr will add it regardless of the ignore list | 19:56 |
| jam | so you could also do "bzr add foo foo/*" | 19:57 |
| jam | just depends what is easier for you | 19:57 |
| Qhestion | no that seems not to work | 19:57 |
| Qhestion | once make finishes is will try the first version | 19:57 |
| jam | Qhestion: the 'find' or the 'bzr add foo/*'? Also, can you give platform, etc? | 19:57 |
| Qhestion | "bzr add foo/*" seems not to work | 19:58 |
| jam | Qhestion: note that the second one doesn't recurse into subdirs of foo | 19:58 |
| jam | you have to explicitly list all the files | 19:58 |
| Qhestion | Python 2.5.dunno, Ubuntu 8.04 | 19:58 |
| Qhestion | explicitly listing all files is... not possible, because i have LOTS of files (it took me half an hour to compile this thingy and now i want to back it up) | 19:58 |
| jam | If you are using zsh, you should also be able to do "bzr add foo/**/*" | 19:59 |
| jam | If it is just .o files, you could also edit ~/.bazaar/ignore and remove the .o from your global ignore | 20:00 |
| Qhestion | O_o this time it worked | 20:00 |
| jam | Though I honestly would recommend not adding compiled output. | 20:00 |
| Qhestion | dunno what went wrong the last time (hours ag), but "bzr add ./*" did it | 20:00 |
| jam | As conflicts in .o files would be a pain | 20:00 |
| Qhestion | jam: its just temporary | 20:00 |
| ChristopheT | Hi. We are a small group of developers and push our branches (via sftp) to a directory with the sgid set (so everybody in the group can write to the repository). However, bzr does not properly propagates the sgid on its directories. What can we do? | 20:12 |
| fullermd | bzr does. sshd doesn't. | 20:14 |
| fullermd | If you use the smart server via bzr+ssh or something, it'll work. | 20:14 |
| tolstoy | ChristopheT: What we did was make sure everyone's default group in the server was "bzr", and that our umasks were at least 002. | 20:17 |
| === Pieter is now known as GitBot | ||
| ChristopheT | tolstoy: Unfortunately, this is a machine used by many other people with several projects on it... | 20:18 |
| tolstoy | Yeah, we have a dedicated machine for the repos and all associated tasks. | 20:21 |
| ChristopheT | That also means I can't install myself the bzr smart-server on it :( | 20:22 |
| === GitBot is now known as Pieter | ||
| jam | ChristopheT: well, I could write a simple plugin that would disable bzr trying to set the mode on files over sftp, but that would only effect people who had the plugin installed | 20:50 |
| ChristopheT | jam: thanks but I do not see how that will solve my problem. The sgid bit is set on the server and not respected when .bzr is pushed. My problem is _not_ that the sgid bit is not propagated (as https://bugs.launchpad.net/bzr/+bug/50568). | 20:54 |
| ubottu | Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] | 20:54 |
| ChristopheT | If I create a dir from sftp, it is created with the right sgid bit. | 20:56 |
| jam | ChristopheT: what happens is bzr does "chmod xxx" on all files after it creates them | 21:02 |
| jam | this bit gets *removed* by sftp | 21:02 |
| jam | my plugin would basically disable the chmod | 21:02 |
| jam | so as long as the files get created with the right umask, | 21:02 |
| jam | they will respect the sgid bit | 21:02 |
| jam | or, I should say, directories will still have the sgid | 21:03 |
| jam | bit | 21:03 |
| jam | and thus files underneath will have the appropriate group | 21:03 |
| jam | ChristopheT: put another way. When you do 'bzr push' we do "mkdir XXX; chmod 2775 XXX", which gets interpreted by sftp as mkdir XXX; chmod 775 XXX | 21:03 |
| jam | and strips the sgid bit | 21:04 |
| jam | then when we create a file underneath XXX/ , the containing dir doesn't have the sgid bit set, so the files created use the user's default group | 21:04 |
| jam | ChristopheT: I could be wrong, but i'm pretty sure your problem *is* bug #50568 | 21:04 |
| ubottu | Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568 | 21:05 |
| ChristopheT | jam: you are correct, I just tried and indeed chmod strips the sgid bit :( | 21:05 |
| jam | yep, good ol' openssh | 21:06 |
| ChristopheT | Maybe we should add our voice to http://marc.info/?l=openssh-unix-dev&m=117745562123264&w=4 | 21:06 |
| jam | I don't know *why*, I think it is a protection mechanism | 21:06 |
| jam | so you can't sgid things you shouldn't | 21:06 |
| jam | unfortunately, it strips it from things that you *should* | 21:06 |
| ChristopheT | not propagating is a protection, not not leaving the ones that are set on the server side... | 21:06 |
| ChristopheT | BTW, why does bzr use chmod? | 21:07 |
| jam | ChristopheT: to try to get around users with a bad umask set | 21:08 |
| jam | Sort of a damned if you do, damned if you don't | 21:08 |
| jam | By default creating a directory will use the user's umask | 21:08 |
| jam | so if they have 022 | 21:08 |
| jam | then directories won't be group writable | 21:08 |
| jam | so we chmod | 21:08 |
| jam | but then they lose the sgid bits | 21:08 |
| jam | So *one* answer is to force users to set there umask (which they may want 022 for normal work, and only 002 for bzr work in certain directories), and not chmod. | 21:09 |
| jam | An *easier* solution is to use bzr+ssh and something like bzr_access to set your umask for bzr connections | 21:09 |
| jam | but that doesn't seem to help *you* as you don't have appropriate admin rights on this machine | 21:09 |
| ChristopheT | I'll try to convince the admin to install the smart-server (but he is put off by the fact that no debian package exists) | 21:12 |
| jam | ChristopheT: sudo apt-get install bzr | 21:12 |
| jam | I don't see how hard that is | 21:12 |
| jam | bzr+ssh just requires *bzr* to exist on the server | 21:12 |
| jam | (and for you to have the ability to run "ssh host bzr serve --inet" | 21:13 |
| jam | I certainly hope that jelmer has been keeping up with the debian packaging :) | 21:13 |
| pygi | sooooo folks, who here has time to talk with me about topics that should be included in hopeful bzr book? :) | 21:14 |
| jam | ChristopheT: http://packages.debian.org/search?keywords=bzr | 21:14 |
| * jelmer needs sponsors | 21:14 | |
| * jam hides :) | 21:14 | |
| ChristopheT | For chmod, isn't the better to try: if a created dir has >= the right permissions or has a suid or sgid bit, do not touch it; otherwise chmod? | 21:14 |
| jelmer | hi pygi | 21:14 |
| jam | ChristopheT: there are a lot of possible heuristics which could be attempted, but if the g+w bit isn't set, sgid doesn't help much | 21:15 |
| pygi | hi jelmer :) | 21:15 |
| jam | you get the right group | 21:15 |
| jam | but the group still can't write | 21:15 |
| jam | I thought we had a "stat + if bits not right chmod" | 21:15 |
| === sdboyer_ is now known as sdboyer | ||
| jam | ChristopheT: ah, we don't do that for sftp, because of adding an extra round trip issues. We probably could, and patches for that would certainly be reviewed | 21:16 |
| jam | Especially if it only effected mkdir, since we do that infrequently, versus for all file creation, which we do somewhat more often | 21:18 |
| jam | (ie, effecting 1 time in 1000 means you can do a bit more work each time) | 21:18 |
| jam | (without impacting the overall work done much) | 21:19 |
| ChristopheT | Yes but one can then warn the user and use a default decision (either no chmod -- the sanest IMHO since if the sgid bit is set, this is for a reason, but tell tu use umaks id the bit g+w is not set -- or do chmod anyway and use an option --no-chmod to override that -- but forgetting this will screw up things). | 21:19 |
| jam | If the user has the wrong umask... if chmod you get files with the wrong group, though probably read permissions on the files (aka, you can still use it), or if you don't chmod you get no 'w' for the directory, so other people can't put new files there (aka, you can't use it at all) | 21:20 |
| jam | ChristopheT: again, if you care deeply, I'm happy to review a patch to the sftp code. It is all contained in bzrlib/transport/sftp.py | 21:21 |
| jam | And you want to look at the "def _mkdir()" function specifically | 21:21 |
| jam | You probably should also discuss it on the mailing list | 21:21 |
| jam | to ensure that people generally agree. | 21:21 |
| jam | One man's 'just work's heuristic is often another's "it is very broken" | 21:21 |
| pygi | lifeless, how did the bzr talk went? | 21:22 |
| ChristopheT | jam: if the administrator agrees to install bzr, if he does not agree then I'll try to change the mkdir logic (hopefully the bug will be fixed in sftp itself) | 21:35 |
| jam | ChristopheT: well, it has existed for... 3+ years now, I don't know that the openssh guys are really going to change anything | 21:35 |
| ChristopheT | BTW, the part of the server we have access to is in a chroot environment. Any hint about what I have to tell him to do? | 21:36 |
| jam | ChristopheT: well, python2.5 and bzr need to be available in the chroot | 21:40 |
| jam | but no, I don't have a lot of personal experience with getting software working under a chroot | 21:41 |
| jam | I know you can run bzr from source or from your personal home directory | 21:41 |
| jam | as long as python etc are available | 21:41 |
| ChristopheT | Does bzr creates new _directories_ after the initial push? | 21:46 |
| jam | ChristopheT: for new-format (pack) repositories, it only creates lock directories which should be cleaned up during unlock | 21:47 |
| jam | older ones used multiple levels for storage, but that is no longer the case. | 21:47 |
| jam | anyway, bbiab, restarting my machine | 21:49 |
| ChristopheT | I guess moreover that bzr does not chmod any existing directories after their creation, right? (For the short run, then I can change the sgid by hand -- we are using righ-root-pack.) | 22:00 |
| === bac is now known as bac|away | ||
| poolie | jam, hi | 23:11 |
| mwhudson | <insert question about branch7 landing here> | 23:11 |
| poolie | mwhudson: see my mail "update on stack merging" | 23:12 |
| mwhudson | poolie: ahah, thanks | 23:13 |
| === bac|away is now known as bac | ||
| jelmer | poolie: what are the plans for 1.6 ? | 23:15 |
| jelmer | days, weeks, months ? :-) | 23:15 |
| poolie | jelmer, days, immediately the stacking branch is landed, which will be as soon as all the tests pass | 23:17 |
| jelmer | poolie: Thanks! | 23:17 |
| jml | good morning Bazaar. | 23:18 |
| jam | poolie: hi | 23:26 |
| poolie | hi jam, shall we talk? | 23:28 |
| jam | just a sec, talking with #bzrlp guys | 23:29 |
| jam | also, I'm on linux right now, so by-phone is probably better than by-skype | 23:29 |
| === bac is now known as bac|away | ||
| poolie | sure, just ping me when you're ready | 23:30 |
| jam | poolie: I'm probably available for a call now | 23:35 |
| poolie | ok | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
