| poolie | igc, spiv: call now | 00:00 |
|---|---|---|
| schierbeck | jelmer: could i get you to review the latest seahorse-integration? | 00:04 |
| lifeless | finally | 00:14 |
| lifeless | core vf files passing tests with finished largely gone | 00:15 |
| poolie | wtg! | 00:15 |
| jelmer | schierbeck: sure, one sec | 00:17 |
| schierbeck | jelmer: okay, another iteration coming your way -- we'll land this tonight! | 00:38 |
| jelmer | schierbeck: feel free to just merge - I voted bb:tweak | 00:38 |
| schierbeck | okay | 00:39 |
| jelmer | ather than bb:resubmit | 00:39 |
| jelmer | I trust you are able to remove that one line :-) | 00:39 |
| schierbeck | hehe :) | 00:42 |
| schierbeck | jelmer: by the way, i've got this in the works: lp:~dasch/bzr-gtk/branchview-selected-row-color/ | 00:42 |
| jelmer | we seem to be better on track than bzr.dev this week though ;-) | 00:43 |
| schierbeck | it adds a stroke of white around the line graph when selected | 00:43 |
| schierbeck | jelmer: yeah, they seemed panic-stricken | 00:43 |
| jelmer | schierbeck: any chance you can have a look at my mime patch? | 00:44 |
| schierbeck | jelmer: sure | 00:44 |
| schierbeck | jelmer: i've got an actual patch icon, if you'd like it | 00:47 |
| schierbeck | tango styled and everything | 00:47 |
| schierbeck | i see you use the bazaar icon | 00:47 |
| jelmer | yep | 00:48 |
| schierbeck | jelmer: i'll mail it to you | 00:50 |
| lifeless | lunch break for me | 00:55 |
| schierbeck | jelmer: can you receive over irc? | 00:56 |
| schierbeck | f00k it, i'll jsut mail them | 00:56 |
| * igc reviewing spiv's patch for #207558 now | 00:58 | |
| schierbeck | jelmer: this is also a possibility: http://tango.freedesktop.org/User:Dobey#Tango_Icon_Theme_Icons_.28CC-By-SA_2.5.29 | 01:00 |
| schierbeck | jelmer: oh, just found where i got the icons i sent you from: http://www.quantum-bits.org/?page_id=3 | 01:01 |
| jelmer | schierbeck: ah, thanks | 01:18 |
| * igc reviewing spiv's nosmart+ decorator patch | 01:41 | |
| * schierbeck is going to bed | 01:49 | |
| igc | abentley: yes, please merge that | 01:52 |
| abentley | Already in PQM | 01:52 |
| igc | sorry I missed the assert issue - here's to jam's good catch on that one | 01:52 |
| igc | great | 01:52 |
| ubotu | New bug: #211122 in bzr "bzr help cherrypick would be useful" [Wishlist,Triaged] https://launchpad.net/bugs/211122 | 02:05 |
| === mw is now known as mw|out | ||
| * igc reviewing the arch-independent site directory patch now | 02:14 | |
| lifeless | garh test_35_wait_lock_changing | 02:21 |
| lifeless | _so_ fragile | 02:21 |
| poolie | lifeless: you can kill it | 02:23 |
| poolie | i think my branch to add another exception class makes it possible to write a much cleaner test but i have not yet done so | 02:24 |
| poolie | spiv: nosmar +1 from me too | 02:24 |
| spiv | poolie: ok, that's enough good enough for me. Thanks! | 02:25 |
| poolie | this should be rarely used anyhow | 02:25 |
| poolie | we hope | 02:25 |
| spiv | Right. | 02:25 |
| lifeless | I was hoping for http-bzr | 02:28 |
| lifeless | just for cool factor | 02:28 |
| poolie | ? | 02:28 |
| poolie | surely that would be the opposite? | 02:28 |
| lifeless | http minus bzr :) | 02:28 |
| poolie | oh i see | 02:28 |
| lifeless | standards, pfft | 02:29 |
| poolie | presumably we should use the unicode MINUS SIGN which looks almost but not quite like a dash? :) | 02:29 |
| lifeless | I'm so totally unsure that that would be valid in the scheme | 02:29 |
| spiv | lifeless: it might not be valid, but "standards, pfft" ;) | 02:30 |
| lifeless | indeed | 02:34 |
| lifeless | though being able to type it in++ | 02:34 |
| poolie | it will avoid people using it accidentally :) | 02:35 |
| === kiko is now known as kiko-zzz | ||
| * poolie is merging the test progress fix | 02:51 | |
| abentley | lifeless: could I get your feedback on my "Playing with Stacked Branches" post? | 03:07 |
| poolie | yeah for some reason gmail thinks the time is 'undefined' | 03:09 |
| poolie | i wonder if i should reboot google? :) | 03:09 |
| matthewlmcclure | abentley: do you have a moment to discuss cygwin/symlinks (re: bug 209281)? | 03:13 |
| ubotu | Launchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,Invalid] https://launchpad.net/bugs/209281 | 03:13 |
| abentley | matthewlmcclure: Sure. | 03:14 |
| matthewlmcclure | i'm not sure how to proceed since several people have expressed concerns. here are the concerns i understand: | 03:14 |
| matthewlmcclure | (1) you'd like "nice" pathhames, e.g., 'old' and 'new' | 03:15 |
| matthewlmcclure | (2) martin disliked forking a process to dereference the 'new' symlink | 03:15 |
| matthewlmcclure | (3) i want a windows diff program to find the files it needs to diff; and it can't dereference directory symlinks or understand cygwin full paths | 03:16 |
| matthewlmcclure | (4) you said you thought my original patch addressed (3) in the wrong place | 03:17 |
| matthewlmcclure | re: (4) do you have a suggestion where is the right place? | 03:17 |
| abentley | _try_symlink_root | 03:18 |
| matthewlmcclure | it seems to me also that (1) and (3) are fundamentally in conflict, but maybe you have a better idea than anything i've come up with | 03:18 |
| abentley | They aren't in conflict. You just make a copy of the file with a nice name. | 03:19 |
| matthewlmcclure | ah, right... i can do that; it's a reasonable compromise, but it doesn't address: | 03:19 |
| matthewlmcclure | ( 5) i'd like the right side of the diff to be the working copy (so it can be tweaked in the diff program) | 03:20 |
| abentley | Well, we could provide that as an optional mode, and sacrifice (1) in that case. | 03:21 |
| abentley | But mainly, we shouldn't be creating symlinks if we don't want to use them. | 03:22 |
| matthewlmcclure | ok... i understand now that your primary concern is not to create the symlinks if they'll only be dereferenced | 03:24 |
| abentley | That's right. | 03:25 |
| matthewlmcclure | so we have a choice: ( a) copy the right side files and get nice pathnames, or ( b) use the working tree directly and get editability | 03:25 |
| matthewlmcclure | there's a precedent for ( a) on native Windows | 03:26 |
| abentley | The dereferencing was far more involved than fixing it at the source would be. | 03:26 |
| abentley | matthewlmcclure: Personally, I would prefer to make a) the default, and b) an optional mode. | 03:26 |
| matthewlmcclure | ok... i'll do ( a) in one patch, and worry about an option for ( b) separately | 03:26 |
| abentley | Well, maybe I'm being hasty. | 03:27 |
| abentley | You're the first person to ask for this. | 03:27 |
| abentley | Both a) and b) are analogous to our existing Unix behavior. | 03:27 |
| abentley | a) is the same as our windows behavior. | 03:28 |
| lifeless | abentley: sure | 03:28 |
| abentley | Yeah, let's do --use-real-path as a second step. It should affect both Cygwin and Windows. | 03:28 |
| abentley | lifeless: thanks. | 03:29 |
| matthewlmcclure | ok, will do. | 03:29 |
| matthewlmcclure | thanks for your time | 03:29 |
| abentley | matthewlmcclure: no problem | 03:30 |
| markh | noob question: Say I pull a "pristine" tree from a public server, then pull a "working" directory from that pristine tree. If I made a bundle from the "working" tree, the bundle references the local path to that pristine tree. Is that a problem? Do I need to tell 'bundle' what the real public tree is? | 03:35 |
| markh | eg, if I want to send the bundle to the bazaar list as a merge request ;) | 03:36 |
| abentley | didn't Google just unleash some sort of "customize your time" thing? | 03:44 |
| Peng | They also announced their partnership with Virgin to set up a colony on Mars. | 03:47 |
| abentley | markh: You should put the public location in the merge directive, either by specifying it, or by setting the "public_branch" config value on your local copy. | 03:47 |
| markh | abentley: ah, config value makes sense - thanks | 03:47 |
| abentley | np | 03:49 |
| abentley | poolie: I've written a nanny script for Bundle Buggy to restart it if it gets a lock error. | 04:03 |
| abentley | Obviously, this is a stopgap. | 04:03 |
| poolie | yay | 04:03 |
| poolie | thanks | 04:03 |
| abentley | No problem. | 04:03 |
| abentley | I'm going to try moving it to Postgres, which I've wanted to do anyhow. | 04:04 |
| lifeless | so | 04:06 |
| lifeless | sqlite does document its locking policy; like I said I think there is something crackful in the python bindings; they open new transactions implicitly AFAICT. | 04:06 |
| abentley | lifeless: It could be. | 04:28 |
| abentley | It could also be a hung thread, right? | 04:29 |
| ubotu | New bug: #211139 in bzr "add reports partial success incorrectly" [Undecided,New] https://launchpad.net/bugs/211139 | 04:31 |
| lifeless | abentley: possibly; if it is a hung thread one would expect contention in posgresql too | 04:42 |
| lifeless | abentley: I would like bb to continue to support sqlite; pgsql is a lot harder to deploy | 04:42 |
| abentley | I don't intend to stop supporting sqlite, but I want to use postgres for myself. | 04:43 |
| lifeless | cool | 04:45 |
| abentley | But schema migrations are way too painful in sqlite. | 04:45 |
| lifeless | they are ? | 04:46 |
| abentley | Sure. In order to add a foreign key column, you have to create a new table with the new schema, copy the data over from the original, delete the original, rename the new one into place, and re-create some indices. | 04:48 |
| lifeless | weird; sqlite supports alter table ... add column | 04:54 |
| abentley | lifeless: Yes, but as far as I can tell, that doesn't support foreign key relationships. | 04:54 |
| lifeless | it supports anything create table supports | 04:55 |
| lifeless | http://www.sqlite.org/lang_altertable.html | 04:55 |
| abentley | I have tried it. I couldn't get it to work. | 04:57 |
| abentley | Note that the foreign key relationship is not specified as part of a column definition. It's some kind of suffix on the CREATE TABLE command. | 04:59 |
| lifeless | what syntax are you using | 05:00 |
| abentley | It has been a while since I tried it. | 05:01 |
| abentley | What would you suggest? I've got an sqlite prompt open. | 05:01 |
| abentley | Here's something that doesn't work: ALTER TABLE vote ADD COLUMN dogbert INTEGER, FOREIGN KEY(dogbert) REFERENCES tg_user; | 05:03 |
| markh | so, while playing around locally, a couple of my local branches show "public branch" and "submit branch" values have been remembered as "related branches". How do I remove or change them? | 05:04 |
| lifeless | so abentley, before trying to debug it, why are you using foreign key there at all - sqlite doesn't support foreign keys last I heard it. | 05:04 |
| lifeless | http://www.sqlite.org/omitted.html | 05:05 |
| abentley | It certainly acts like it does, | 05:05 |
| abentley | https://pastebin.canonical.com/3816/ | 05:06 |
| lifeless | theres nothing in there that suggests anything more than accepting the syntax | 05:08 |
| abentley | Well, I would like to add more columns that give such an impression. | 05:09 |
| abentley | Enforcing the constraint would be kinda nice, too. | 05:11 |
| markh | and depending on what I try, I can manage to get my bundles showing both 'target_branch' and 'source_branch'. Am I correct that I just want target_branch pointing at the public branch and no value for 'source_branch'? | 05:14 |
| lifeless | http://www.justatheory.com/computers/databases/sqlite/ | 05:15 |
| lifeless | abentley: I think the add column syntax is infact invalid | 05:15 |
| lifeless | abentley: but i'm not sure immediately how to work around that | 05:15 |
| abentley | markh: If you are not publishing branches, you want no value for source branch. | 05:18 |
| markh | abentley: thanks | 05:19 |
| abentley | the submit_branch is remembered by merge and send, the public_branch is remembered by send only. | 05:19 |
| markh | how can I "unremember"? | 05:19 |
| abentley | There is not "unremember". You may be better off just editing ./bzr/branch/branch.conf | 05:20 |
| markh | it only seems to remember first time | 05:20 |
| markh | ok | 05:20 |
| abentley | markh: If you want it to remember when it already has a remembered value, you can supply --remember. | 05:20 |
| markh | ah - thanks | 05:20 |
| abentley | But by default we assume it's a temporary override. | 05:20 |
| markh | I do remember seeing that now - my head is kinda exploding still though :) | 05:21 |
| abentley | lifeless: The page you gave already says that columns with unique constraints and primary keys can't be added. I think they just forgot to mention foreign keys. | 05:22 |
| lifeless | abentley: sounds plausible | 05:26 |
| RAOF | jml: Incidentally, hooray for bzr-svn. | 05:56 |
| jml | oh? | 05:57 |
| RAOF | After the initial branch, it makes working with banshee much nicer. | 05:57 |
| jml | ahh :) | 05:58 |
| jml | I need a new plunger :( | 05:58 |
| spiv | jml: yours has taken it's final plunge? | 05:58 |
| jml | I just got a mouthful of wet coffee grinds | 05:58 |
| RAOF | Mmmm, coffee grounds! | 05:58 |
| fullermd | Yeah, it sucks when they get soggy; all the crunch is lost. | 05:59 |
| jml | heh heh | 05:59 |
| Angelic13 | i'm having trouble getting "bzr viz" to work on my Windows machine. i keep getting the error "PyGTK not installed". PyGTK *is* installed, and i'm able to run use it in a python shell. | 05:59 |
| Angelic13 | i'm also having problems installing tortoiseBZR that might be related. when i try to do so, it says it can't find bzrlib and it needs to be in PYTHONPATH. i've tried setting this to several different things and can't get it to work. should this be set to "C:\Program Files\Bazaar" or something else? | 05:59 |
| jml | Angelic13: I'm no Windows expert, but your PYTHONPATH should be set to the directory that contains 'bzrlib' | 06:00 |
| fullermd | Angelic13: How did you install bzr? | 06:00 |
| Angelic13 | and what does bzrlib look like in windows? | 06:00 |
| Angelic13 | i see a bzrlib in python/Lib/site-packages/bzrlib | 06:01 |
| Angelic13 | this only has a plugins directory and nothing else though, so i'm not sure if that's what it wants | 06:01 |
| jml | *interesting* | 06:01 |
| Angelic13 | fullermd: i believe i installed it with the bzr installer. it's been somet ime | 06:01 |
| fullermd | I think this comes up with some regularity from using the standalone installer... | 06:02 |
| Angelic13 | c:\Progam Files\Bazaar has the program files, and it has a lib directory, but nothing called bzrlib in there | 06:02 |
| Angelic13 | i've searched through the whole system, and the only place there's a bzrlib is the directory in site-packages | 06:02 |
| Angelic13 | trying an install again with the python bzr installer | 06:04 |
| jml | that sounds like a broken install to me. | 06:04 |
| jml | (note: I have never used Bazaar on windows) | 06:04 |
| fullermd | No, I think that's what you get with the standalone installer. | 06:04 |
| jml | fullermd: really? | 06:04 |
| bob2 | is it py2exed or something? | 06:04 |
| jml | fullermd: where does it find the libs? | 06:04 |
| fullermd | With that, it doesn't use any external python stuff, it's all bundled up together. And that doesn't work with external stuff like bzr-gtk etc. | 06:04 |
| jml | ahh | 06:04 |
| jml | so what do you do if you want to use plugins? | 06:05 |
| Angelic13 | ah this intaller put some more stuff into the bzrlib directory | 06:05 |
| * fullermd doesn't use Windows either; just going by what he's seen here and on the list | 06:05 | |
| Angelic13 | maybe that's what i needed | 06:05 |
| * fullermd nods at Angelic13. | 06:05 | |
| Angelic13 | i used bzr-setup-1.3.exe before i think | 06:05 |
| Angelic13 | i just used bzr-1.3.win32-py2.5.exe now | 06:06 |
| Angelic13 | okay yay i can import bzrlib now ^_^ | 06:06 |
| Angelic13 | that must have been the problem. i didn't see any documentation anywhere saying to stay away from that particular installer though | 06:06 |
| fullermd | Yah. AIUI, that installs normal python stuff. | 06:06 |
| Angelic13 | ok installing tortoisebzr worked. bzr viz still isn't working, but perhaps another reinstall of pygtk will help | 06:07 |
| Angelic13 | still can't get bzr viz to work, but tortoisebzr seems to work for now, so i guess that's good enough | 06:20 |
| bob2 | if you start a python shell, can you import bzrlib and pygtk? | 06:21 |
| Angelic13 | yes | 06:24 |
| Angelic13 | but bzr viz keeps saying PyGTK isn't installed | 06:24 |
| Angelic13 | right now i have bzr-gtk in "c:\Documents and Settings\user\Application Data\bazaar\2.0\plugins\gtk", and i *think* that's right | 06:25 |
| spiv | Angelic13: I think that's right. If it wasn't, you'd get a different error (bzr: ERROR: unknown command "viz") | 06:26 |
| Angelic13 | moving it to "C:\Program Files\Bazaar\plugins\gtk" doesn't seem to work | 06:26 |
| Angelic13 | that is, it isn't working in the same way | 06:27 |
| Angelic13 | also can't run scripts/olive-gtk directly :/ | 06:33 |
| kgoetz | hi all. how can i bring a branch in line with a new upstream head? i want to blow away any unknown files/changes/pending merges etc and replace it | 06:36 |
| abentley | kgoetz: bzr revert; bzr pull --overwrite | 06:46 |
| Angelic13 | hmm seems like i had to download libglade separately and put it into my gtk directory. that was missing from some of the docs. | 06:48 |
| Angelic13 | so now i can run olive with scripts/olive-gtk | 06:48 |
| Angelic13 | but bzr viz still doesn't work | 06:48 |
| kgoetz | abentley: thanks. | 06:49 |
| Angelic13 | ah but olive crashes with a GtkWarning *sigh* | 06:49 |
| bob2 | bzr gtk only claims to require glade, gtk and bzr | 06:49 |
| Angelic13 | bazaar-vcs.org/bzr-gtk only says you need bazaar and pygtk though | 06:50 |
| Angelic13 | in the windows install section | 06:50 |
| Angelic13 | this is the most informative doc i've found so far http://faq.pygtk.org/index.py?req=show&file=faq21.002.htp | 06:53 |
| abentley | poolie: The nanny just restore BB successfully for the first time. | 07:01 |
| Peng | What breaks BB exactly? | 07:01 |
| poolie | abentley: way to go | 07:28 |
| spiv | abentley: great! You may now enjoy your local timezone ;) | 07:29 |
| spiv | igc: have a good holiday | 08:28 |
| igc | thanks spiv | 08:28 |
| AfC | What could one have done to do a merge, commit it - but not have the revisions consisting of the contributed patch not appear in the history? | 08:56 |
| fullermd | cherrypick, or revert --forget-merges | 08:57 |
| AfC | (I had to do the merge again, resolve a conflict, and then the contributor's branch showed up - but all the files were otherwise present) | 08:57 |
| AfC | yes, it said something about cherry pick. | 08:57 |
| AfC | What would have caused that? | 08:57 |
| AfC | I just did the usual | 08:57 |
| AfC | bzr merge ~/Desktop/contributed.patch | 08:57 |
| fullermd | That being a merge directive? | 08:58 |
| AfC | yeah | 08:58 |
| AfC | "merge request" :) | 08:58 |
| fullermd | Then it would come from the person making it, making it as a cherrypick. | 08:59 |
| AfC | AH | 08:59 |
| AfC | (really) | 08:59 |
| AfC | (huh?) | 08:59 |
| AfC | Wait a minute. I did the same | 08:59 |
| AfC | bzr merge ~/Desktop/contributed.patch | 08:59 |
| AfC | both times. | 08:59 |
| AfC | It was only after I had committed it and run `bzr viz` that I realized something was wrong | 09:00 |
| AfC | doing it a second time resulted in the revisions showing up. | 09:00 |
| fullermd | I would guess you did something in between that filled in enough of the 'missing' revs that it could be applied directly. | 09:00 |
| AfC | (I realized something was wrong when I tried to see the parents of the merge, and saw only one) | 09:00 |
| AfC | fullermd: fair enough, but | 09:00 |
| * AfC is horribly confused, and his confidence is shaken. | 09:00 | |
| fullermd | Well, that's why I'm here :) | 09:02 |
| fullermd | Remember that when you merge a MD, it's not the same as merging the branch; in the latter case, you do the merge you ask for, but in the former, you do the merge that the MD creator asked for. | 09:11 |
| AfC | Actually, I'm 3/4 way to being serious. I did a merge, and it decided NOT to merge the revisions. This is astonishing to someone who has been, for better or for worse, been trained by Bazaar in its behaviour. | 09:11 |
| AfC | Hm. | 09:11 |
| fullermd | Well, if it's doing a cherrypick, it can't merge the revisions, because there's nowhere for the graph to hook up. | 09:11 |
| igc | night all. I'm away on leave until the 14th now so happy Bazaar'ing while I'm gone. :-) | 09:12 |
| fullermd | If you look in viz, what I suspect you'll see is that one of the revs in that merge has a parent that wasn't in your graph at the time of your previous attempt. | 09:12 |
| AfC | This is one of the reasons the terminology behind "merge directive" has always distressed me. It's not a directive, because contributors cannot «tell» me to do anything. It's a patch, and I am considering it for merging, or not. | 09:12 |
| AfC | fullermd: no. It shows no parents whatsoever. | 09:12 |
| fullermd | Urr? An unrelated branch? | 09:13 |
| AfC | I wish I knew what happened, so I could tell this contributor not to do whatever they did again. Better yet, I wish Bazaar wouldn't have permitted it in the first place. | 09:13 |
| AfC | fullermd: EXACTLY | 09:13 |
| AfC | changes got committed, but not revisions. | 09:13 |
| AfC | I carried on as normal, no problem, la ti da | 09:13 |
| * fullermd goes cross-eyed. | 09:14 | |
| fullermd | Start over. | 09:14 |
| fullermd | An unrelated branch would have revisions with number like 0.1.x. | 09:14 |
| fullermd | That's the only way (aside from the left path, of course) you ever get revs with no parents; at the start of an unrelated merge-in. | 09:14 |
| AfC | Whatever. Grab the branch yourself and look: | 09:14 |
| AfC | bzr viz bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ | 09:14 |
| AfC | revno 461.1.1 | 09:15 |
| AfC | Where are the revisions of the contributed patch? | 09:15 |
| AfC | The code delta is there, for sure. | 09:16 |
| AfC | But I had to do the merge _again_ revno 465 to make the revisions appear. | 09:16 |
| fullermd | It's called 461.1.1. That means that when you did that merge, you were at rev 461. | 09:17 |
| AfC | I would be thrilled if I could identify what I [presumably] did wrong. | 09:17 |
| fullermd | But if you look at the revs when the merge worked, the merge revs are 463.x.x, which means those revs are children of rev 463. | 09:17 |
| fullermd | Thus, where you did that merge the first time, you didn't have the revs in your branch, that were the parents of the revs to be merged. | 09:17 |
| fullermd | Thus, they couldn't be attached into the tree 'normally', and become a cherrypick. | 09:18 |
| AfC | Hm. | 09:18 |
| fullermd | That means the cause is probably not actually the sender requesting a cherrypick in the MD creation, but rather that your branch was 'old' where you did the merge. | 09:18 |
| AfC | Hm | 09:18 |
| AfC | Yes, ok, I can see that. | 09:19 |
| AfC | weird | 09:19 |
| AfC | {shrug} | 09:19 |
| fullermd | It speaks highly of the quality of your contributors that they keep so up to date, that _you're_ the one behind ;) | 09:19 |
| AfC | so what gets me is that those revisions didn't "appear" (or whatever) when I subsequently merged it to 'mainline' at 464 | 09:19 |
| AfC | fullermd: nah, I had a 'cairo' branch lying around, and so did it there. I evidently forgot to pull from mainline first. | 09:20 |
| AfC | Still. | 09:20 |
| fullermd | Because it was too late at that point; when you committed 461.1.1 (or 462 as it was called on the branch when you merged it), those revs couldn't be hooked to the tree, so they weren't included. | 09:20 |
| fullermd | So when you got around to merging it in in mainline:464, there was no longer any link to them to be reconnected. | 09:21 |
| AfC | So I merged a second time to "fix" it, but is there something else I should have done instead? | 09:21 |
| fullermd | Well, the 'rightest' thing would have been to stop when it told you it was cherrypicking, and figure out whether that was what should be happening. | 09:21 |
| AfC | [this will teach me not to do integration merges on 'mainline', but anyway] | 09:22 |
| AfC | fullermd: ah | 09:22 |
| AfC | fullermd: interesting. | 09:22 |
| fullermd | Once that's committed and stuck onto mainline (and you don't want to uncommit and dump that rev), there's no way to rewrite the rev to say "Oh, this was a parent of mine". | 09:22 |
| * spiv isn't really here, but as a drive-by comment, this sounds like surprising behaviour, so probably there's a bug to be fixed somewhere. Probably the original "bzr merge ..." should have made more fuss about the fact that the base revision referenced in the merge directive wasn't present? | 09:22 | |
| AfC | spiv: I think so | 09:22 |
| fullermd | Well, it's tricky. Cherrypicks can be intentional. | 09:23 |
| AfC | spiv: I think that's where I got off track | 09:23 |
| spiv | (and optionally, maybe, provide a way to say, "no, this isn't a cherrypick, just a ghost..."?) | 09:23 |
| fullermd | I don't think MD's explicitly say whether they were intended to be cherrypicks. | 09:23 |
| AfC | fullermd: put another way, I haven't knowingly done a "cherrypick" since, oh, 0.91 | 09:23 |
| AfC | Well, mostly I'm glad to hear that it wasn't Vreixo who screwed up, it was me. I can handle that. | 09:23 |
| fullermd | Well, that goes back to the 'directive' part; when you merge a MD, the 'intention' is expressed by the person making it. | 09:24 |
| * spiv -> really gone | 09:24 | |
| spiv | AfC: :) | 09:24 |
| AfC | fullermd: ... which is ass-backwards for anything other than a bot receiving it. | 09:24 |
| fullermd | Using 'send -rx..y' can express an intent to cherrypick (in the case that rev 'x' isn't in the upstream already) | 09:24 |
| AfC | fullermd: I hadn't realized that cherry picks were that far along. I gather there is still a way to go, however. | 09:25 |
| AfC | fullermd: (it's that whole partial implementation thing you and I were talking about, I think) | 09:25 |
| fullermd | Well, it's where they've been since... I dunno. 0.6 or something. | 09:25 |
| AfC | _really_ | 09:25 |
| AfC | Hm | 09:25 |
| fullermd | Pretty much the same place they are in everything but darcs. | 09:25 |
| AfC | Well. | 09:25 |
| AfC | fullermd: so that branch is now "safe", you think? | 09:26 |
| fullermd | "bzr send -ofile -rx..y ; cd $UPSTREAM ; bzr merge file" gives the same result as "cd $UPSTREAM ; bzr merge -rx..y $OTHER" | 09:26 |
| AfC | fullermd: yeah, ok, I can buy that | 09:27 |
| fullermd | Oh, yes. That -2 rev may have wacky files compared to what you wanted, but the branch is fine. | 09:27 |
| AfC | Then "fix merge bug" is a surprisingly accurate commit message, it seems :) | 09:27 |
| AfC | fullermd: thank you for your time. | 09:28 |
| fullermd | Prescient :) | 09:28 |
| ubotu | New bug: #211209 in bzr "bzr 1.3 fails with a ValueError" [Undecided,New] https://launchpad.net/bugs/211209 | 10:16 |
| === mwhudson_ is now known as mwhudson | ||
| VSpike | Anyone got any ideas how I can work around this? https://bugs.launchpad.net/bzr/+bug/181855 | 11:56 |
| ubotu | Launchpad bug 181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Medium,Confirmed] | 11:56 |
| VSpike | the annoying thing is, I'm sure this worked a couple of weeks back | 11:58 |
| VSpike | I'm beginning to wish I hadn't chosen bzr to work with a visual studio project... there's no working VS integration yet afaik, cygwin bash + cygwin bzr has the above bug, cygwin bash + windows bzr has problems with sftp and doesn't work, and the windows command line is loathsome | 12:00 |
| VSpike | you could argue that the mistake was using visual studio/windows rather than bzr and I probably wouldnt put up much of a fight | 12:01 |
| VSpike | hmm the original reporter got no answers at all on the cygwin list | 12:14 |
| === kiko-zzz is now known as kiko | ||
| muszek | hi | 12:59 |
| muszek | http://pastebin.us/?show=m2d341b75 <-- bzr died when I tried bzr revert. Please help, I need to revert. | 12:59 |
| muszek | Bazaar (bzr) 1.1.0.candidate.1, Debian Sarge (package from backports.org) | 13:00 |
| AfC | muszek: you might do well to just install Bazaar manually. 1.1.0rc1 is a bit old. | 13:01 |
| AfC | muszek: (assuming no one has a Debian package of bzr 1.3) | 13:02 |
| muszek | AfC: the one from hardy probably wouldn't install, right? | 13:03 |
| AfC | muszek: you won't know until you try. | 13:03 |
| muszek | rgr | 13:03 |
| AfC | muszek: We don't use Ubuntu at our company, sorry. | 13:03 |
| muszek | AfC: what do you use? (just curious, feel free to ignore me) | 13:04 |
| AfC | muszek: we run Gentoo on our systems | 13:06 |
| AfC | Anyway, good luck to you | 13:06 |
| * AfC heads to bed. | 13:06 | |
| muszek | AfC: thanks, good night | 13:06 |
| ignas | hi | 13:06 |
| ignas | how do I find out whether remote branch format matches the local branch format? | 13:07 |
| ignas | my commits are taking ages ... | 13:07 |
| AfC | ignas: bzr info URL | 13:08 |
| AfC | bzr info . | 13:08 |
| ignas | :/ can't do that while commiting apparently | 13:09 |
| AfC | :( | 13:09 |
| ignas | so i'll have to look at it in 5 minutes | 13:09 |
| ignas | and it's a 1 line change in .bzrignore :/ | 13:09 |
| AfC | ignas: for what it's worth, I'd encourage you to maintain a branch locally and work there and commit there. You can then push your changes to the remote repo separately. That should work much better for you. | 13:10 |
| ignas | AfC: release managing requires a lot of pushing | 13:10 |
| AfC | ... and if you have to merge, well, {shrug} you merge. | 13:10 |
| ignas | so i actually need my changes to appear in the remote repository | 13:10 |
| ignas | as soon as I do them | 13:10 |
| AfC | ignas: you've got a modern 3rd generation distributed revision control system at hand. You would do well to take advantage of it. | 13:11 |
| ignas | when developing - yes i can work on an isolated branch | 13:11 |
| ignas | but i need to do the push after merging and it is taking way too much | 13:12 |
| AfC | I assume you've got bzr 1.3 on both sides and that you are pushing via bzr+ssh. If not, try upgrading and changing protocols. | 13:12 |
| ignas | hmm Repository branch (format: unnamed) | 13:12 |
| ignas | remotely | 13:12 |
| ignas | and Checkout (format: dirstate-tags) | 13:13 |
| ignas | locally | 13:13 |
| ignas | what should i do to fix that? | 13:13 |
| ignas | and no it's not 1.3, it's the version that is available as debs for ubuntu gutsy... | 13:13 |
| ignas | 1.0 i think | 13:14 |
| ignas | though maybe i should switch to bzr PPA instead of using the old deb package repository | 13:14 |
| AfC | ignas: well that's your first problem, depending on Ubuntu to give you up to date software. The hackers here maintain a "PPA" (whatever that is) which gives you more modern packages. | 13:14 |
| luks | ignas: don't use bzr+ssh url for `bzr info` | 13:15 |
| AfC | As for what to do, after upgrading to Bazaar >= 1.3.0, run something like `bzr upgrade` (probably `--default` on a test branch and see if that helps. | 13:15 |
| luks | bzr+ssh hides the real format | 13:15 |
| ignas | and what about the remote repository? | 13:15 |
| ignas | luks: oh | 13:15 |
| AfC | luks: how strange | 13:15 |
| ignas | makes sense | 13:16 |
| AfC | ignas: upgrade it too | 13:16 |
| ignas | you can use bzr+ssh with old versions of bzr | 13:16 |
| AfC | ignas: (again, modulo testing and backups etc) | 13:16 |
| ignas | Repository branch (format: pack-0.92) | 13:17 |
| luks | that's the problem then | 13:17 |
| ignas | if i want to upgrade a repository not just the branch | 13:17 |
| luks | upgrade your local repository | 13:17 |
| ignas | i should run bzr upgrade in the repository | 13:17 |
| luks | yes | 13:17 |
| ignas | will it upgrade all the branches inside? | 13:18 |
| luks | not sure about that | 13:18 |
| ignas | hmm, bzr upgrade says it's the most recent format already | 13:19 |
| luks | what version of bzr? | 13:19 |
| ignas | 1.0 | 13:19 |
| ignas | so it seems i will have to fix apt sources :/ | 13:19 |
| luks | hm | 13:19 |
| ignas | this makes sysadmins so much more enthusiastic about bzr ;) | 13:20 |
| luks | what does bzr info say in the local repository? | 13:20 |
| ignas | the remote repository | 13:20 |
| ignas | i have a local checkout | 13:20 |
| ignas | of a branch that is in a shared repository on a remote server | 13:20 |
| luks | no local repository? | 13:20 |
| luks | then you need to upgrade the checkout | 13:21 |
| ignas | no, don't need it, i am working on a single checkout at the moment | 13:21 |
| luks | the remote side is already using pack-092, which is the most recent format | 13:21 |
| ignas | hmm | 13:21 |
| ignas | i see | 13:21 |
| ignas | bzr upgrading local one | 13:21 |
| ignas | neat, would have never managed to find out which one | 13:22 |
| ignas | pack-092 or dirstate-tags is more recent | 13:22 |
| ignas | you should call the next version gruntmaster-6000 ;) | 13:24 |
| AfC | {grin} | 13:25 |
| ignas | yippie it's only 60 seconds not 5 minutes! | 13:27 |
| luks | still too slow | 13:28 |
| ignas | i know, i have a weird sense of humor ;) | 13:28 |
| luks | I'd try to use sftp instead of bzr+ssh | 13:28 |
| ignas | it messes up permissions on the remote repository | 13:29 |
| luks | oh | 13:29 |
| awilkins | Does bzr+ssh use the smart server or something faster? | 13:29 |
| bob2 | smart server | 13:29 |
| AfC | awilkins: more or less by definition, that is the smart server. | 13:29 |
| luks | the problem is that the smart server isn't that smart | 13:29 |
| bob2 | smarter than sftp, less smart than...a brick | 13:30 |
| luks | with packs it usually does more requests then dump sftp | 13:30 |
| luks | than | 13:30 |
| bob2 | or dumb http | 13:30 |
| AfC | awilkins: (you can also get to it by running one full time, ie bzr:// ) | 13:31 |
| bob2 | (for the intiial checkout, at least) | 13:31 |
| awilkins | Oh yes, familiar with that, just wondered if bzr+ssh was the same thing | 13:31 |
| AfC | awilkins: for some operations it is slower, but for many operations (notably, most of the uploading and data comparison cases) it is faster. | 13:31 |
| luks | yes, it's the same procotol over a different transport layer | 13:31 |
| ignas | bzr website sounds a lot more optimistic about these kinds of issues ;) | 13:32 |
| awilkins | Well, I'd be optimisitic if I was so much faster than CVS and SVN :-) | 13:33 |
| ignas | emm, difficult to do, especially when repository is 70 megs, and an svn checkout is a few hundered kilobytes and the connection is around 10 kb/s | 13:35 |
| awilkins | ignas: Well, ok, that's less wonderful. | 13:35 |
| awilkins | ignas: But things like grabbing a checkout of 13,000 files over a local network kick it's ass. | 13:36 |
| ignas | emm - what about the distributed part | 13:36 |
| ignas | like - some team members in US, some in Lithuania, and the server is in UK ;) | 13:37 |
| awilkins | That also kicks ass. | 13:37 |
| bob2 | except for the latency! | 13:37 |
| ignas | not when you tell them to try out a checkout from bzr ;) | 13:37 |
| bob2 | rsync ftw. | 13:37 |
| awilkins | Although my interactions with Lithuania are limited to storing my coke-and-hookers funds | 13:37 |
| ignas | so you are suggesting making the initial checkout using rsync and only then using bzr? | 13:38 |
| ignas | as in - bring a checkout to sprint on a usb stick and make everyone copy it | 13:39 |
| ignas | instead of 5 guys making a branch from the central repository | 13:39 |
| awilkins | Because of the "distributed" thing, that works just as well as all getting grabbing a branch from central server | 13:41 |
| awilkins | Better, if your sneakernet bandwidth is high but your network bandwidth is low | 13:41 |
| bob2 | well, not suggesting, but rsync is really quite awesome for copying data, and afaik bzr is not faster than it, yet, for the intial checkout | 13:42 |
| ignas | just that - you can give the svn url using irc, and have them all with a check out faster than 2 guys can copy something from 1 usb stick :/ | 13:42 |
| luks | depends on how many files you have there | 13:43 |
| luks | svn can be pretty slow on large trees | 13:43 |
| ignas | yes, but bzr is slow on large histories | 13:44 |
| ignas | and apparently we have a huge history with a moderate tree ... | 13:44 |
| ignas | and it's not the network apparently | 13:45 |
| ignas | svn checkout reaches the speed of like 50 kb/s | 13:45 |
| TFKyle | schierbeck: hmm, looking at the new seahorse integration in bzr-gtk, wouldn't it be fine to rely on dbus's autostarting (ie. just using get_object, or calling the stuff to autostart it on org.freedesktop.DBus if that isn't compatible enough) instead of checking if it's currently running/the name is owned currently in dbus? | 13:45 |
| ignas | bzr up - does not use the network compared to that ... | 13:45 |
| awilkins | A use case for history horizons | 13:45 |
| TFKyle | mm, also get an exception with current bzr-gtk trunk when seahorse is running | 13:46 |
| ignas | an svn checkout is 2 minutes 20 seconds, bzr up with no changes is 30 seconds :/ | 13:47 |
| muszek | I've just upgraded to 1.3 and bzr still dies (I was writing ~half an hour ago about bzr revert failing). I've also tried commiting (to see if I can revert on another machine), but it also fails. http://pastebin.us/?show=d12b0633a | 13:47 |
| bob2 | muszek: what does 'bzr check' say? | 13:49 |
| muszek | bob2: one sec | 13:49 |
| TFKyle | (on bzr visualize, ah it's calling discover with an empty string) | 13:49 |
| muszek | bob2: http://pastebin.us/?show=d2387e94d | 13:50 |
| === mrevell is now known as mrevell-lunch | ||
| TFKyle | (hmm, just when bzr visualize'ing the bzr-gtk branch though) | 13:55 |
| TFKyle | also, looks like bzr sign-my-commits was designed to give people RSI :P | 13:56 |
| bob2 | muszek: that sounds like disc corruption or bzr bug | 13:56 |
| bob2 | TFKyle: does it work with gpg-agent? | 13:56 |
| TFKyle | probably, don't have it running atm though | 13:56 |
| bob2 | ah | 13:56 |
| bob2 | no whinging then :P | 13:56 |
| muszek | bob2: prior to that error, I ran two scripts on the whole dir... one that changes ownership and permissions, other converts "leading spaces to tabs"... I haven't ran them in a while - possibly since I've started using bzr couple of weeks ago... and I haven't excluded .bzr from being messed by that script :/ | 13:57 |
| TFKyle | also hmm, sign-my-commits seems to be signing with my main email for the key rather than the email I used for the commits | 13:57 |
| bob2 | yaga | 13:57 |
| andihit | when I use bzr, can I checkout only one sub-dir of my repo? when I have some dir in my repository, and on some other PC i want clone only one directory from my repo - is that possible? | 13:59 |
| bob2 | not directly | 13:59 |
| bob2 | and not like svn | 13:59 |
| bob2 | but 'bzr split' is something related (you could split to a seprate branch) | 13:59 |
| spiv | andihit: there was talk at a recent London sprint to add a feature for that | 14:00 |
| spiv | andihit: there's a rough plan for implementing it, but it's still some time away from being ready | 14:00 |
| andihit | hm, I'm currently reading the "BzrVsGit"-wiki, it says 'Directories are branches. In Git they are branch containers where you switch to different views.' <-- that means, every directory is a branch. and that means, I can't checkout one specific branch? | 14:01 |
| luks | perhaps there is a terminology confusion | 14:02 |
| bob2 | you can checkout one specific branch, but in a repository, not all directories are branches | 14:02 |
| luks | in your previous question by 'repo' you meant an actual bzr repository, or a branch? | 14:02 |
| TFKyle | ah, hmm | 14:02 |
| spiv | andihit: in bzr, each branch has its own directory on disk. That doesn't imply that each directory is a branch :) | 14:03 |
| === mrevell-lunch is now known as mrevell | ||
| andihit | hm then rewrite the sentence ;) | 14:04 |
| andihit | k thx | 14:04 |
| ignas | hmm, bzr up from a remote branch is 30 seconds, bzr up locally takes like 1 second, downloading a file get's me 50kb/s, ssh feels sluggish, can i assume that bzr is doing a lot of connections and a lot of round trips | 14:05 |
| ignas | thus is very sensitive to latency problems | 14:05 |
| spiv | ignas: there's work on the smart server protocol to reduce round tips | 14:06 |
| spiv | round trips, rather | 14:06 |
| spiv | ignas: also, make sure your branch/repo are in pack format, not knit | 14:06 |
| spiv | The knit format tends to require many many round trips. | 14:06 |
| ignas | they are in pack format now | 14:06 |
| ignas | have bzr upgraded everything on both sides | 14:06 |
| TFKyle | schierbeck: another thing, would it be sane to just check that the key belonging to the signature is the same as one of the ones in opengpg.MatchKeys(email_address)? (or possibly comparing the fingerprints) | 14:20 |
| schierbeck | TFKyle: i've sent in a patch already | 14:25 |
| schierbeck | i call dbus.validate_bus_name('org.gnome.seahorse') | 14:27 |
| TFKyle | 'k | 14:28 |
| === mw|out is now known as mw | ||
| === weigon_ is now known as weigon | ||
| === hexmode` is now known as hexmode | ||
| brokencycle | hi! | 17:24 |
| gioele | hello | 17:25 |
| brokencycle | i've just tried to convert a CVS repository, but now I'm stuck using the output. bzr info says "shared repository", but i'm unable to "get" or "branch" from it. | 17:28 |
| gioele | brokencycle: a shared repo is an empty place where you can put branches | 17:30 |
| gioele | branches are *inside* a shared repo | 17:30 |
| gioele | (empty from a logical POW, it contains a log of small bookkeeping files from a practical POW) | 17:31 |
| brokencycle | thank you! now i got the "right" contents, but the naming inside the shared repository is not-so-good... need to export/import into a different shared repo to fix it, right? | 17:32 |
| gioele | brokencycle: I'm sorry but I know nothing of the current cvs-to-bzr tools :( | 17:33 |
| brokencycle | no problem, your hint got me a big step forward already. Thank you! | 17:34 |
| poolfool | brokencycle: which CVS to BZR tool are you using? I hope to move a CVS repo to BZR some time soon, so your input is pretty valuable to me right no. | 17:34 |
| poolfool | brokencycle: /s/no./now./ | 17:35 |
| gioele | what is the difference between the trunk and the dev branches? | 17:35 |
| brokencycle | well, i only found 'cvsps-import' (I only need to go one-way, so 'tailor' would be really overkill). | 17:35 |
| gioele | (of bzr I mean) | 17:35 |
| brokencycle | btw, the need for 'cvsps' could/should find some mentioning in the plugin's description. I only learned about it when I first tried to do the import, and failed. | 17:37 |
| brokencycle | I'm on bzr 1.2, if that matters. | 17:38 |
| poolfool | brokencycle: I remember someone on IRC mentioning one tool (I think tailor) working better then the other. IE. one tool was no longer in development. | 17:38 |
| LeoNerd | CVS is an acronym. bzr isn't. | 17:38 |
| poolfool | Yea I should get better control of that shift key, I have a bad habit of adding caps in the wrong place. | 17:39 |
| gioele | brokencycle: what matters most is not the bzr version but the repository format version current default format is ok, older (pre 0.92 formats) are difficult to use with external tools | 17:43 |
| brokencycle | that should not be relevant since i'm converting from CVS - so the bzr part of it should get created as recent as the "underlying" bzr allows. | 17:44 |
| gioele | I never used tailor, but it has a very large user base, with some heavy user. I would use such a big and tested tool instead of ad-hoc smaller programs | 17:44 |
| gioele | brokencycle: yes indeed | 17:44 |
| brokencycle | I also never used tailor, but assumed that it has a huge list of dependencies that I don't want/need on the target machine... the 'ad-hoc progam' is, at least, created by one of the core bazaar developers, as far as I can see: http://bazaar-vcs.org/BzrPlugins (~ 2 thirds down the page). | 17:46 |
| gioele | will running bzr.dev overwrite something on the repository where it is used? | 17:58 |
| pmezard | brokencycle: do you need it to be incremental ? | 18:00 |
| brokencycle | ? | 18:00 |
| brokencycle | pmezard: do you mean, if i want to repeat the conversion process to import more and more CVS commits? | 18:01 |
| pmezard | yes | 18:01 |
| brokencycle | If so, the answer is no. :) | 18:01 |
| pmezard | did you try cvs2svn ? | 18:02 |
| brokencycle | No. Then I would also need SVN, right? | 18:02 |
| brokencycle | And then i could import from there? | 18:02 |
| pmezard | i think there was some work on a bzr backend | 18:02 |
| pmezard | by reusing git fast-import format | 18:02 |
| brokencycle | I'd like to avoid having to drag along too many other systems. In this case, I'm only versioning /etc, wanting to keep the history. | 18:04 |
| rysiek|pl | hi guys | 18:04 |
| rysiek|pl | this is an emergency: is there a way of UN-reverting? | 18:04 |
| rysiek|pl | I just might have lost a few hours worth of work -_-' | 18:04 |
| LeoNerd | Look for the FOO.~1~ files | 18:05 |
| LeoNerd | Or ~2~ or whatever number it gave them | 18:05 |
| rysiek|pl | phew | 18:05 |
| LeoNerd | When you "revert", any changed files get backed up to ~somenumber~, whatever is the next free number | 18:05 |
| * rysiek|pl stops hiperventilating and dives into the filesystem | 18:05 | |
| LeoNerd | find . -name '*.~1~' | 18:07 |
| rysiek|pl | yeah, just done that ;) | 18:07 |
| brokencycle | @poolfool: thanks - I didn't check the development status of the plugin... but even then, maybe I've already "fixed" it, by editing something in the guts of .bzr. Will keep an eye on it. | 18:09 |
| rysiek|pl | wtf... there were some pending local commits... and seems like THOSE changes were lost | 18:10 |
| rysiek|pl | shit. they ARE lost! | 18:11 |
| poolfool | brokencycle: Yea ... I did a little looking at taylor vs cvsps and I think I want cvsps to bring over all of my history including branches ... talor looks to just do the root (head?) branch as a patch set. | 18:11 |
| rysiek|pl | why the heck does bzr backup the uncommited files, but CLEANS the locally-commited changes? | 18:11 |
| rysiek|pl | or am I missing something again | 18:11 |
| gioele | rysiek|pl: what kind of working tree is that? checkout? branch? | 18:12 |
| rysiek|pl | checkout | 18:12 |
| gioele | bound or unbound? | 18:13 |
| rysiek|pl | bound | 18:13 |
| brokencycle | I just found out that I probably don't want to use tailor because there's no port of it to OpenBSD. For cvsps, there is... simplifies things quite a bit (probably). | 18:13 |
| rysiek|pl | (i think) | 18:13 |
| rysiek|pl | gioele: checkout of branch: sftp://mike@(...) | 18:13 |
| rysiek|pl | I am reading the manpages but cannot find the info is there a way to get my locally commited changes back | 18:15 |
| rysiek|pl | why on earth does revert destroy locally COMMITED(!) changes by *default*?.. | 18:15 |
| gioele | because revert thinks that you want to revert to what is consider the base: the remote branch you're bound to | 18:18 |
| rysiek|pl | ok, but it keeps backups of the changed files. neat. | 18:18 |
| rysiek|pl | but WHY OH WHY doesn't it keep some kind of backups of locally commited changes? | 18:18 |
| rysiek|pl | one would think that locally commited changes - simply because they *are commited* - should be considered more... hmm... permament? | 18:19 |
| gioele | they are | 18:19 |
| rysiek|pl | ? | 18:19 |
| gioele | but revert is more "going back to revision X, pass over everything" | 18:19 |
| jelmer | rysiek|pl: revert does not destroy committed changes | 18:20 |
| gioele | still it should backup everything it throws away, committed or not | 18:20 |
| rysiek|pl | jelmer: those were locally-committed changes | 18:20 |
| jelmer | only uncommitted changes | 18:20 |
| jelmer | rysiek|pl: what was the exact command you were running? | 18:20 |
| rysiek|pl | jelmer: well, the situation here is: I had two revisions committed locally; I made some additional changes and was ready to commit to the master branch | 18:21 |
| rysiek|pl | jelmer: bzr ci ... -> woosh, some conflicts emerged | 18:21 |
| rysiek|pl | jelmer: I hadn't had time to resolve those, so I thought I simply revert (to the last LOCALLY committed revision) | 18:21 |
| rysiek|pl | jelmer: bzr rever | 18:21 |
| jelmer | rysiek|pl: that is the latest local revision at that point | 18:22 |
| jelmer | rysiek|pl: I think "bzr update" is not doing what you expect it to | 18:22 |
| rysiek|pl | jelmer: woosh - my changes from the two locally-committed revisions are gone, and I only have backups of the latest, uncommitted changes | 18:22 |
| jelmer | rysiek|pl: it updates the local branch tip to the master branch tip and adds the extra local revisions as pending merges | 18:23 |
| rysiek|pl | jelmer: yeah, I know that | 18:23 |
| rysiek|pl | jelmer: so? I lost my locally-committed revisions because they became pending merges? | 18:23 |
| rysiek|pl | jelmer: after an update, that is? | 18:23 |
| jelmer | rysiek|pl: yes, because revert throws away pending merges | 18:24 |
| rysiek|pl | so they are completely gone, are they | 18:24 |
| rysiek|pl | *aren't | 18:24 |
| jelmer | no, they're still hidden in the repository | 18:24 |
| jelmer | the heads plugin may be able to retrieve them | 18:24 |
| rysiek|pl | this is the point where you can save a man's life | 18:24 |
| rysiek|pl | 'kay, on it | 18:24 |
| rysiek|pl | anybody knows if the heads plugin is packages somewhere (bzrtools?) for ubuntu gusty | 18:25 |
| jelmer | it's not packaged | 18:25 |
| rysiek|pl | ok | 18:26 |
| gioele | rysiek|pl: it is easy to install "mkdir ~/.bazaar/plugins; bzr co --lightweight where-is-heads ~/.bazaar/plugins/heads" | 18:26 |
| poolfool | jelmer: Um for the cheap seats here ... if I 1) checkout from somewhere sftp://fool@... (call it r1) , 2) make some changes and commit changes #bzr commit (call it r1.1) , 3) make some more changes but 4) accidentaly do a revert #bzr revert my local copy will be back to r1 ... is that what happened to rysiek|pl ? | 18:27 |
| rysiek|pl | poolfool: 1. r1.1 is a local commit | 18:28 |
| jelmer | poolfool: no | 18:28 |
| rysiek|pl | poolfool: plus there is a 3.5 step | 18:28 |
| rysiek|pl | poolfool: 3.5) bzr update | 18:28 |
| jelmer | poolfool: this can only happen to you if you use "bzr commit --local" | 18:28 |
| poolfool | jelmar: while 'bound' to the remote repo? | 18:29 |
| jelmer | poolfool: yes | 18:29 |
| gioele | mind if I file a bug about this? | 18:29 |
| jelmer | gioele: about what exactly? | 18:29 |
| poolfool | So is it step 3.5 #bzr update , that was the problem command? Now the 'local commits' are pending in limbo, yet the 'heads' plugin may save the day? | 18:30 |
| gioele | jelmer: local commits thrown away without a backup when update/revert is used | 18:30 |
| rysiek|pl | jelmer: about not asking the user "man, you ARE going to lose those pending merges: ..." | 18:30 |
| jelmer | gioele: what would the bug be exactly? revert throws away pending merges? update adds local commits as pending merges? | 18:31 |
| rysiek|pl | just asking would suffice, as that would be the point were I would jump, hit n, Ctrl+C and/or the master power switch | 18:31 |
| rysiek|pl | gioele, jelmer: maybe a feature request | 18:31 |
| gioele | jelmer: the problem is that revert is *deleting* stuff without telling the user about that and without saving what it is tossing away | 18:31 |
| jelmer | gioele: revert throwing away pending merges makes a lot of sense in 90% of other situations | 18:32 |
| rysiek|pl | gioele, jelmer: "during revert, if there are any pending merges, ask the user if he knows those pendng merges will be deleted" | 18:32 |
| gioele | jelmer: better safe than sorry | 18:32 |
| jelmer | rysiek|pl: For unbound branches throwing away pending merges without asking does make sense | 18:33 |
| rysiek|pl | and there can always be a config option"do not ask about blah blah" | 18:33 |
| gioele | revert has backups, what is wrong with extending them to pending merges? | 18:33 |
| rysiek|pl | jelmer: I am not saying it doesn't | 18:33 |
| jelmer | rysiek|pl: It would be really annoying if "bzr revert" started asking about throwing away pending merges | 18:34 |
| rysiek|pl | jelmer: I am only saying that it might save some people some loose hairs and stress | 18:34 |
| jelmer | rysiek|pl: I understand the problem but I think the problem is with update rather than revert | 18:34 |
| rysiek|pl | well then, update saying "local commits are now pending merges, watch with that revert, mind you" | 18:34 |
| gioele | jelmer: what is the problem with throwing away pending merges *and* doing backups? | 18:35 |
| rysiek|pl | are there any docs for heads? | 18:35 |
| jelmer | gioele: backups are already done | 18:35 |
| rysiek|pl | jelmer: where ;) | 18:35 |
| rysiek|pl | bzr heads shows nothing | 18:35 |
| rysiek|pl | ok, --all | 18:36 |
| rysiek|pl | jelmer: I only have ONE out of TWO local commits | 18:37 |
| rysiek|pl | and have no idea whatsoever how to get it re-merged | 18:37 |
| jelmer | rysiek|pl: bzr merge -rrevid:<revid> | 18:37 |
| jelmer | where <revid> should be printed by "bzr heads" | 18:37 |
| jelmer | rysiek|pl: heads only prints the latest commit | 18:37 |
| rysiek|pl | ok, thanks | 18:37 |
| rysiek|pl | jelmer: so the pre-last is lost? or by reverting (meh...) to the one I get the pre-last, too? | 18:38 |
| jelmer | rysiek|pl: by merging the latest you get the latest-1 as well | 18:38 |
| fullermd | No, heads only shows the heads. The prior one isn't a head, it's an ancestor of that one. | 18:38 |
| rysiek|pl | ah, right | 18:39 |
| rysiek|pl | fingers crossed | 18:43 |
| johnny | so what's the recommended bzr web frontend these days? | 18:45 |
| rysiek|pl | bzr: ERROR: No location specified or remembered | 18:48 |
| rysiek|pl | bzr merge ... ./ or bzr remerge ? | 18:48 |
| jelmer | rysiek|pl: try . | 18:48 |
| gioele | johnny: http://www.lag.net/loggerhead/ | 18:49 |
| rysiek|pl | ok, done. | 18:49 |
| johnny | that is the recommended one? i see bzr-webserver being updated more recently | 18:49 |
| johnny | i like the ui of loggerhead, but the fact that i can't figure out how to not making it run as it's own user is weird | 18:49 |
| johnny | and not as root that is :) | 18:50 |
| rysiek|pl | worked! | 18:50 |
| rysiek|pl | jelmer, gioele: thanks a lot! I could have been banging my head against the wall on this for the next 3hrs, and then probably having to re-write it from scratch | 18:51 |
| jelmer | rysiek|pl: ah, cool | 18:52 |
| jelmer | rysiek|pl: one thing that would perhaps help is if "bzr revert" could tell you the command to apply the pending merges again | 18:52 |
| rysiek|pl | yup | 18:52 |
| rysiek|pl | jelmer: in fact, anything that would *hint* on the fact that you might lose (well, almost ;) ) your local commits would suffice | 18:54 |
| muszek | I have my local repo binded to a repo on an external server. is there some neat command to update a remote working tree when I commit? | 18:54 |
| rysiek|pl | jelmer: problem is with the obscurity of the problem - "local commits" becoming "pending merges" | 18:54 |
| jelmer | rysiek|pl: update already does | 18:55 |
| jelmer | rysiek|pl: at the point your commits become pending merges they're no longer local commits | 18:55 |
| jelmer | muszek: try the push-on-update plugin | 18:55 |
| rysiek|pl | ok, so I am the fool. whatever, I am just happy to have my changes back | 18:55 |
| muszek | jelmer: ty | 18:55 |
| jelmer | rysiek|pl: right, that's why I mentioned this is actually a problem of update | 18:56 |
| ubotu | New bug: #211412 in bzr "bzr should never throw away changes without making backups" [Undecided,New] https://launchpad.net/bugs/211412 | 18:56 |
| rysiek|pl | methinks that's a wee bit too broad, will get rejected :/ | 18:56 |
| jelmer | gioele: what would you like bzr to do on revert then though? SHould it write a bundle filewith the pending merges in it? | 19:03 |
| rysiek|pl | ok, just need to make sure: | 19:03 |
| rysiek|pl | I have those local commits in again, and some new changes | 19:03 |
| gioele | jelmer: that would be cool | 19:03 |
| rysiek|pl | I want to commit all to master branch - bzr commit should do the trick, right? | 19:03 |
| gioele | jelmer: but a simple cp of all the changed file is enough | 19:03 |
| jelmer | gioele: that's going to kill performance though | 19:03 |
| jelmer | gioele: all changed files are already backed up | 19:03 |
| gioele | jelmer: --no-backups then | 19:04 |
| johnny | gioele, have you set up loggerhead? | 19:04 |
| gioele | jelmer: As a user I would never trade safety for performance | 19:05 |
| gioele | johnny: no | 19:05 |
| gioele | jelmer: if you fear performance issues, then make a non default --slow-but-safe global option for bzr, I'll enable it | 19:06 |
| jelmer | gioele: that's simply deferring the decision of what to do to the user | 19:06 |
| jelmer | gioele: and will still get it wrong in a lot of cases | 19:06 |
| jelmer | gioele: my point also was that it's update that's throwing things away | 19:07 |
| jelmer | since it's removing local commits | 19:07 |
| rysiek|pl | jelmer: humm... bzr help commit yields this at the end | 19:07 |
| rysiek|pl | jelmer: (As a general rule, when in doubt, Bazaar has a policy of Doing the Safe Thing.) | 19:07 |
| rysiek|pl | jelmer: The Safe thing here would be AT LEAST asking the user | 19:08 |
| rysiek|pl | jelmer: it doesn't hurt much to hit 'y' from time to time, but it saves time (lives? ;) ) | 19:08 |
| jelmer | rysiek|pl: that's true for update, not for revert | 19:08 |
| rysiek|pl | jelmer: whatever! I don't really care if it's in revert or update | 19:08 |
| jelmer | rysiek|pl: also, bzr doesn't have interactive stuff on purpose | 19:09 |
| rysiek|pl | jelmer: I do care, however, that it's *somewhere*, as if I would get such info from update OR revert I would stop | 19:09 |
| gioele | jelmer: I agree with rysiek|pl: I don't care. I want my data back ;) | 19:09 |
| gioele | how many ppl are going to came here asking for what rysiek|pl asked? | 19:10 |
| jelmer | gioele: that's why I suggested "bzr revert" should tell you the merge command to readd those pending merges | 19:10 |
| rysiek|pl | jelmer: and that would be just ideal, IMHO | 19:10 |
| gioele | jelmer: but then, as you said, that would be interactive and not needed in 90% of the cases | 19:10 |
| johnny | so... loggerhead anybody? | 19:10 |
| gioele | I think that silently doing the backups is the safest way | 19:11 |
| jelmer | gioele: no, it's simply an extra line of output from revert | 19:11 |
| gioele | jelmer: and it will not be read | 19:11 |
| rysiek|pl | gioele: it will | 19:12 |
| rysiek|pl | gioele: after I run the command, I read the output | 19:12 |
| rysiek|pl | gioele: ESPECIALLY when I have lost something | 19:12 |
| gioele | rysiek|pl: no you don't | 19:12 |
| gioele | you read messages *after* you've lost something | 19:12 |
| gioele | the line appears *before* | 19:12 |
| rysiek|pl | gioele: thing is: it is *not* lost | 19:12 |
| gioele | wait, I got lost | 19:13 |
| rysiek|pl | gioele: I just needed some third-party plugin to tell me the exact revid of the "lost" commits | 19:13 |
| rysiek|pl | gioele: thing is: | 19:13 |
| rysiek|pl | gioele: 1. bzr ci --local once or twice | 19:13 |
| rysiek|pl | gioele: 2. /code code code/ | 19:13 |
| rysiek|pl | gioele: 3. bzr up /local commits become pending merges here/ | 19:14 |
| gioele | ok, I got it | 19:14 |
| rysiek|pl | gioele: 4. oops, a conflict - revert /pending merges are "lost", but the changes are kept.. well, somewhere ;) / | 19:14 |
| gioele | rysiek|pl: an hell from an help-line pow ;) | 19:15 |
| rysiek|pl | gioele: now, if revert had just told me: those pending merges were "lost", you can re-merge them with bzr merge -revid:<blah> | 19:15 |
| rysiek|pl | gioele: I wouldn't even come here :) | 19:15 |
| rysiek|pl | so technically, the changes aren't lost, I just did not know how to get them back - and I needed a third-party plugin to get on this | 19:16 |
| rysiek|pl | plus info on how to use it. that's exactly what printing "you can re-merge blah blah" would give me :) | 19:17 |
| * rysiek|pl EOF | 19:17 | |
| gioele | as long as the change are store somewhere, and accessing them does not require an external plugin (the revid can be outputted by revert itself I think), that is a perfect solution | 19:18 |
| rysiek|pl | yup | 19:18 |
| * rysiek|pl had a deja-vu - something has changed in the Matrix, I guess | 19:19 | |
| ubotu | New bug: #211434 in bzr "revert should tell the user what pending merges were thrown away" [Undecided,New] https://launchpad.net/bugs/211434 | 19:25 |
| mathiaz | Hi - I'd like to be able to create (and then send) an email containing the diff and the log message for a specific revision in a bzr branch. Is there a command/plugin that does this ? | 19:52 |
| johnny | thereis an email plugin on the site | 19:52 |
| johnny | in the plugin section | 19:52 |
| poolfool | johnny: Were you asking about loggerhead vs bzr-web? | 20:00 |
| johnny | vs bzr-webserve | 20:00 |
| johnny | ist here just bzr-web? | 20:00 |
| mathiaz | johnny: thanks. | 20:01 |
| poolfool | Johnny: Sorry 'web-serve' ... I use 'web-serve' for personal use, very low traffic, but a great tool to graphicly check some things. | 20:01 |
| poolfool | johnny: I am pretty sure launchpad(sp) is using loggerhead. | 20:01 |
| === doko_ is now known as doko | ||
| johnny | poolfool, have you setup loggerhead yourself? | 20:14 |
| poolfool | johnny: sorry no ... loggerhead is a little to complex for me. web-serve gives me the features I need. | 20:16 |
| johnny | loggerhead runs fine for me.. i just want it to run under my webserver | 20:18 |
| johnny | instead of as it's own user :( | 20:18 |
| johnny | a web thing that doesn't do any file system writing. should be able to run like every other webapp i have | 20:18 |
| poolfool | Um ... how do you start loggerhead? | 20:18 |
| johnny | ./start-loggerhead :) | 20:19 |
| johnny | but that's not the way i want to run it | 20:19 |
| johnny | but it does work | 20:19 |
| poolfool | so ... start-loggerhead is a perl script? | 20:19 |
| johnny | python | 20:19 |
| johnny | why would it be perl? turbogears is in python | 20:19 |
| poolfool | sorry python .... | 20:19 |
| poolfool | Maybe you can tell what I am trying to debug in the background? | 20:19 |
| mxpxpod | I ran into this problem when checking out an svn repo: https://bugs.launchpad.net/bzr-svn/+bug/206728 | 20:21 |
| ubotu | Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix committed] | 20:21 |
| mxpxpod | but when I grab the 0.4 branch of bzr-svn, I can't use it with 1.3 | 20:21 |
| mxpxpod | does anyone know the relevant change to fix bzr-svn for 1.3? | 20:22 |
| johnny | ? | 20:22 |
| johnny | err poolfool ? | 20:22 |
| poolfool | johnny: I am working on some perl in the background ... work. | 20:22 |
| poolfool | johnny: Ok, probably not a good answer, but http://docs.turbogears.org/1.0/mod_python | 20:23 |
| poolfool | Johnny: Use Mod_perl with apache to run loggerhead ? | 20:23 |
| johnny | i don't use apache | 20:24 |
| johnny | fastcgi is prolly the method i'll go with | 20:24 |
| johnny | i found docs for it | 20:24 |
| johnny | but they don't make sense without understanding turbogears | 20:24 |
| johnny | maybe the people in #turbogears will be more helpful this time | 20:25 |
| poolfool | Johnny: So you are actually looking to better understand turbo gears so you can change the UID of the process running loggerhead? | 20:25 |
| johnny | but it seems that channel is more for people developing turbogears apps, not helping people deploy random turbogears apps | 20:25 |
| poolfool | Johnny : Check out this link http://irclogs.ubuntu.com/2008/02/09/%23bzr.html ... I think you may want to watch for 'mwh' | 20:34 |
| poolfool | johnny: Are you trying to run your loggerhead on a low port? Something under 256? | 20:40 |
| schierbeck | jelmer: ping | 20:50 |
| jelmer | schierbeck: pong | 20:50 |
| schierbeck | jelmer: okay, it looks like we have two options regarding seahorse | 20:51 |
| schierbeck | 1) call DiscoverKeys() before trying to get any info -- unknown keys will then appear in the local database, but marked as missing | 20:51 |
| schierbeck | 2) call ListKeys() to get a copy of the local key database and check it ourselves -- this could be bad for memory consumption, however | 20:52 |
| schierbeck | hmm, wait a minute -- i think i have a better solution | 20:53 |
| schierbeck | give me 5 | 20:53 |
| mxpxpod | jelmer: perhaps you can help me with https://bugs.launchpad.net/bzr-svn/+bug/206728 | 20:58 |
| ubotu | Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix committed] | 20:58 |
| mxpxpod | jelmer: where in the 0.4 branch was that fix committed? | 20:58 |
| jelmer | mxpxpod: the best way to find it is to run "bzr annotate" on the news file and see when the line that announces that bug has been fixed was last changed | 20:59 |
| mxpxpod | jelmer: ah, thanks | 21:00 |
| jelmer | mxpxpod: rev 1031 apparently | 21:00 |
| jelmer | schierbeck: looks like a "Find when bug X was fixed" item in viz cuold also be useful :-) | 21:00 |
| === kiko is now known as kiko-afk | ||
| schierbeck | jelmer: yup. submit a bug for it? | 21:01 |
| jelmer | no gpg here :-( I'll try to remember to file one later today | 21:02 |
| schierbeck | jelmer: i think i've finally cracked the key availability issue | 21:03 |
| gioele | wow, bundle buggy is cool | 21:05 |
| jelmer | schierbeck: cool, how? | 21:06 |
| schierbeck | jelmer: i use MatchKeys() | 21:07 |
| schierbeck | first i was a bit afraid, because the docs said it could take a while to return, but that's apparently not true if i give a complete key id | 21:07 |
| jelmer | schierbeck: what is "pattern" exactly? | 21:10 |
| schierbeck | jelmer: not sure | 21:10 |
| schierbeck | i'll ask | 21:10 |
| jelmer | the fact it fetches remote keys also worries me a bit though if it doesn't yet, I guess we're fine for now | 21:11 |
| schierbeck | jelmer: it only searches the local database | 21:14 |
| jelmer | schierbeck: I would actually expect seahorse to handle optional fetching of the keys itself | 21:14 |
| jelmer | when you call GetKeyField() | 21:14 |
| schierbeck | yeah, but apparently it doesn't | 21:14 |
| johnny | poolie, i was trying not to run it on a port at all, just be picked up by the webserver | 21:15 |
| mxpxpod | jelmer: thanks, that worked | 21:18 |
| schierbeck | jelmer: okay, i've sent in a revised patch | 21:35 |
| schierbeck | this one really simplifies things | 21:36 |
| === RAOF_ is now known as RAOF | ||
| * Peng kicks the PPA. | 21:43 | |
| Peng | Has everything in the PPA ever been compatible? | 21:44 |
| jelmer | I think bzrtools is not compatible with the rest or something atm | 21:44 |
| jelmer | Odd_Bloke: ping | 21:44 |
| Peng | bzr-svn for Gutsy is only 0.4.6. | 21:45 |
| Peng | bzrtools WFM. | 21:45 |
| jelmer | Peng: oh, right. I stopped uploading bzr-svn to the other distros because of .orig.tar.gz checksums mismatching | 21:46 |
| Peng | Huh. | 21:47 |
| jelmer | bzr builddeb generates tarballs with different timestamps for the files | 21:48 |
| jelmer | that causes different checksums on the tarball | 21:49 |
| jelmer | and ppa refuses uploads of the same filename with different checksums | 21:49 |
| jelmer | that means I can only upload once (to hardy), other uploads are refused | 21:49 |
| jelmer | schierbeck: what does pattern match on? | 21:53 |
| jelmer | schierbeck: only on key ids or on names as well? | 21:53 |
| === kiko-afk is now known as kiko | ||
| ubotu | New bug: #211523 in bzr "lack of repository upload progress indication" [Undecided,New] https://launchpad.net/bugs/211523 | 22:10 |
| wardi_ | question for a windows user: is tortoisebzr ready for non-developers? | 22:15 |
| jelmer | wardi_: not really at this point | 22:16 |
| wardi_ | bummer, I really don't want to tell her to use svn | 22:16 |
| jelmer | beuno: ping | 22:17 |
| schierbeck | jelmer: key ids and emails | 22:17 |
| schierbeck | jelmer: i'm not sure of the efficiency, but at least we'll only call it once per key | 22:18 |
| schierbeck | jelmer: i guess we could devise a solution where we could match a whole batch of id's, if that's more efficient | 22:19 |
| wardi_ | (again for a windows user): Is Olive a usable alternative to tortoisebzr? I think she's coming from wincvs or somesuch | 22:19 |
| schierbeck | but that would require us to call it asynchronous, which raises other issues | 22:19 |
| beuno | jelmer, pong | 22:32 |
| mlh | wardi_: someone on the mailing list recommended qbzr | 22:33 |
| mlh | as being the most mature/easy to use/complete (<-- one or more of those; I forget which) | 22:33 |
| jelmer | beuno: any news on the nautilus disable patch? | 22:33 |
| beuno | jelmer, I'm a bit stuck on where to implement the global disable | 22:34 |
| jelmer | beuno: Would it be ok with you if I made those two small additions and sent it in? | 22:34 |
| beuno | jelmer, sure, go ahead, although I've got the per-branch bit thing down, just haven't figured out where to move the global disable in the UI | 22:34 |
| jelmer | beuno: ah, ok | 22:35 |
| jelmer | beuno: I wasn't sure where to put that either yet | 22:35 |
| jelmer | beuno: There's no way to add items to the Nautilus Preferences dialog as far as I can see | 22:36 |
| beuno | jelmer, that's my problem :) | 22:36 |
| beuno | we can not have it for now if you want, and I'll send the patch in a while | 22:36 |
| jelmer | beuno: Yeah, that would be nice; at least it's an improvement over the current situation. | 22:37 |
| beuno | jelmer, sure, I'll send the patch in a few hours if that's ok. On the other hand, if you're in a hurry, go ahead and do it yourself | 22:37 |
| jelmer | beuno: I'm not in that much of a hurry :-) | 22:37 |
| jelmer | thanks for looking into this stuff | 22:38 |
| jelmer | schierbeck, phanatic: I'd like to do a release this weekend | 22:38 |
| beuno | jelmer, my pleasure! I'm happy to be helping out | 22:38 |
| jelmer | would that be ok with you, or do you think there's other pending stuff that needs to be fixed? | 22:38 |
| schierbeck | jelmer: i'd like to land my bug page fixes, and do a cleanup of the revision view | 22:39 |
| schierbeck | but if there's not time for it, that's okay | 22:39 |
| jelmer | schierbeck: I think it's possible to get your bug page fixes in before then | 22:39 |
| jelmer | schierbeck: what exactly would you like to fix in the revisionview? | 22:39 |
| schierbeck | jelmer: i'd like to pull each page into its own FooPage class and use proper signalling to update them | 22:40 |
| schierbeck | and i'd like to use symbolic names for the pages, like GENERAL_PAGE, SIGNATURE_PAGE etc. | 22:41 |
| phanatic | jelmer: i'm fine with a release. do you want to do it? | 22:41 |
| rysiek|pl | gtg, cu all | 22:42 |
| rysiek|pl | jelmer: thanks for your help | 22:42 |
| jelmer | schierbeck: symbolic names where exactly? | 22:42 |
| jelmer | phanatic: Sure, it's been a while but I'll happily let somebody else do it if they're interested :-) | 22:42 |
| schierbeck | jelmer: just use constants that map a symbolic page name to an integer denoting that page's position in the notebook | 22:43 |
| schierbeck | jelmer, phanatic: i think we should also have gannotate use the general page only, instead of the entire notebook | 22:43 |
| schierbeck | jelmer, phanatic: by the way, i just sent in a crash-fix | 22:47 |
| phanatic | i'll try to catch up with all patches tomorrow (at least i hope so). i was just following the mailing list, but haven't tried the new features yet... | 22:48 |
| beuno | vila, ping | 22:52 |
| beuno | bzr: ERROR: No such file: '/home/beuno/public_html/test_upload/.bzr-upload.revid': [Errno 2] No such file | 22:52 |
| beuno | is that an expected failure? | 22:53 |
| jelmer | schierbeck: hmm, seahorse slows viz down really really badly here | 22:53 |
| jelmer | schierbeck: it takes >2 seconds to select a revision if the signature is from a missing key | 22:54 |
| jelmer | schierbeck: trusted keys seem to work better | 22:54 |
| schierbeck | jelmer: i'll have a look | 22:56 |
| schierbeck | jelmer: it's pretty fast here | 22:57 |
| beuno | vila, got it, needed to use --full for the first time. You rock! I'm going to polish a few bits of it now, and start using it internally :) We might be almost ready to release a beta | 22:58 |
| schierbeck | jelmer: that must be MatchKeys() then | 22:58 |
| jelmer | schierbeck: How many keys do you have in your local seahorse database? | 22:59 |
| schierbeck | but it should only happen once for a key | 22:59 |
| schierbeck | only 66... guess that's why | 22:59 |
| jelmer | ah | 22:59 |
| jelmer | I've got >2000 | 22:59 |
| schierbeck | hmm | 22:59 |
| schierbeck | jelmer: still, it will only happen once for a key. after the release we should work towards an asynchronous solution | 23:00 |
| lifeless | spiv: ping | 23:18 |
| jelmer | schierbeck: it really makes viz unusable for me | 23:22 |
| schierbeck | jelmer: should i add a "Disable signature checking" option in the menubar? | 23:23 |
| jelmer | schierbeck: I'd rather avoid that sort of workaround but get the code right in the first place | 23:23 |
| jelmer | schierbeck: would it be possible to only determine the signature when the signature tab is viewed, for example? | 23:23 |
| schierbeck | yeah, it would | 23:24 |
| schierbeck | i did that for the changes page | 23:24 |
| schierbeck | let me have a look | 23:24 |
| jelmer | that would help things a lot | 23:25 |
| jelmer | schierbeck: also, do we validate the testament yet? | 23:25 |
| schierbeck | jelmer: nope, we need to do that | 23:25 |
| schierbeck | i'm not sure what will be sufficient | 23:25 |
| beuno | jelmer, finishing something with the upload plugin, and I'll review my changes and send 'em over | 23:26 |
| schierbeck | jelmer: i'll add the symbolic page names -- comparing with integers is really ugly | 23:26 |
| jelmer | beuno: cool, thanks | 23:27 |
| schierbeck | jelmer: i'm having some smtp trouble | 23:33 |
| schierbeck | there | 23:34 |
| schierbeck | think evolution just f00ked up | 23:34 |
| schierbeck | jelmer: okay, it's sent | 23:35 |
| schierbeck | along with a crash fix | 23:35 |
| lifeless | yay all tests pass | 23:42 |
| Kinnison | s'always good | 23:45 |
| * Kinnison pats lifeless on the head | 23:45 | |
| Kinnison | lifeless: Do you have any recommendations for C based test suite managers? I've been using 'check' but it's a bit clunky | 23:46 |
| lifeless | well | 23:46 |
| lifeless | check with my subunit patch is kinda nice | 23:46 |
| lifeless | the gnome one doesn't seem any better or worse to me as a programmer, but its less mature and has less features | 23:47 |
| schierbeck | Kinnison: i've heard good things about the new gtester, but that's part of glib | 23:48 |
| schierbeck | at least as far as i know | 23:48 |
| lifeless | schierbeck: isn't that the gnome one I was referring to ? | 23:48 |
| Kinnison | lifeless: subunit patch? | 23:48 |
| schierbeck | lifeless: probably, not sure if they have an older framework | 23:48 |
| Kinnison | schierbeck: I've only had issues with that and vala (well, libgee really) | 23:49 |
| poolie | hello Kinnison | 23:55 |
| lifeless | Kinnison: there is a patch for check in subunit | 23:55 |
| poolie | lifeless, spiv: call scheduled for 5m | 23:55 |
| poolie | as there is only spiv and me i propose to call you directoly | 23:56 |
| poolie | unless robert wants to come | 23:56 |
| spiv | poolie: sounds good to me | 23:57 |
| lifeless | I want to talk with spiv | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!