| Jc2k | Pieter: there are ~520 repos with commits varying from 200 to 25,000 | 00:01 |
|---|---|---|
| lifeless | moin | 00:06 |
| Jc2k | lo lifeless | 00:07 |
| james_w | hi lifeless | 00:07 |
| lifeless | Jc2k: you can do 'bzr pack && rm .bzr/repository/obsolete-packs/*' | 00:07 |
| Jc2k | already done that | 00:07 |
| awilkins | lifeless: Isn't it about 0600 there? | 00:08 |
| lifeless | 0908 | 00:08 |
| awilkins | Ah, it's tomorrow | 00:08 |
| awilkins | Last we spoke it was 2200 at you | 00:08 |
| Jc2k | (before i rm'd the obsolete packs it was about 10gb bigger) | 00:08 |
| lifeless | yes, it usually comes after yesterday :) | 00:08 |
| awilkins | It's only just today here.... :-) | 00:08 |
| lifeless | Jc2k: is that across all repositories? | 00:08 |
| lifeless | Jc2k: are there working trees | 00:09 |
| lifeless | Jc2k: try a break-down per project | 00:09 |
| Jc2k | *overloads* | 00:09 |
| lifeless | :) | 00:09 |
| lifeless | back in a little bit grabbing breakfast | 00:09 |
| Jc2k | lifeless: all my figures are for all 520ish repos as one | 00:09 |
| Jc2k | lifeless: there were some working trees (mostly trunk), but i think i squished em | 00:09 |
| lifeless | so, one mergarepo ? | 00:10 |
| Jc2k | no | 00:10 |
| awilkins | jam: Want to talk about my patch for #240910 ? | 00:10 |
| Jc2k | 520 repos | 00:10 |
| Jc2k | /srv/bzr/module1, /srv/bzr/module2 | 00:10 |
| lifeless | phew :) | 00:10 |
| Jc2k | and i did du -s -m /src/bzr/ :p | 00:10 |
| Jc2k | *srv, even | 00:11 |
| lifeless | Jc2k: oh, you've deleted the obsolete packs dirs | 00:11 |
| lifeless | Jc2k: you need to keep the directory around, only delete the contents | 00:12 |
| Jc2k | oh | 00:12 |
| Jc2k | >_< | 00:12 |
| lifeless | james_w: ^ | 00:12 |
| lifeless | otherwise it will cry when it next tries to autopack | 00:12 |
| * Jc2k rejigs his script to do lots of mkdir :) | 00:12 | |
| lifeless | so | 00:13 |
| lifeless | I think I can say where the size is | 00:13 |
| lifeless | you have very many tags | 00:13 |
| lifeless | and each tag in the way its beinig brought across is a separate branch, which is to say: | 00:13 |
| lifeless | thetagdir | 00:13 |
| lifeless | .bzr | 00:13 |
| lifeless | .bzr/format | 00:13 |
| lifeless | .bzr/branch | 00:13 |
| lifeless | .bzr/branch/format | 00:13 |
| lifeless | .bzr/branch/lock | 00:13 |
| lifeless | .bzr/branch/branch.conf | 00:13 |
| lifeless | .bzr/branch/last-revision | 00:13 |
| lifeless | so the first thing we could do is use --apparent | 00:14 |
| lifeless | the second thing is to turn the tags into actual tags in trunk | 00:14 |
| lifeless | jelmer: ^ this is planned, yes? | 00:14 |
| mwhudson | beuno: hello | 00:15 |
| lifeless | Jc2k: https://bugs.edge.launchpad.net/bzr-svn/+bug/81102 | 00:16 |
| ubottu | Launchpad bug 81102 in bzr-svn "Tag support" [Wishlist,Triaged] | 00:16 |
| lifeless | Jc2k: I'll bet that starting with just a --apparent on your script makes things look better (because you are no longer measuring how inefficient ext3 is) | 00:16 |
| * jml will see the sydney sprinters soon | 00:17 | |
| Jc2k | lifeless: where do i stick this magical --apparent? on du ? | 00:18 |
| lifeless | Jc2k: yes | 00:18 |
| Jc2k | kk | 00:18 |
| lifeless | jml: I'm hacking intensly here, ring me if you need shit | 00:18 |
| lifeless | Jc2k: it tells du to sum the visible size, not the blocks/extents allocated | 00:18 |
| Jc2k | i see | 00:19 |
| lifeless | if the apparent size is also ridiculously high we can look for bad deltas etc | 00:20 |
| Pieter | Jc2k: how did you repack the git repos? | 00:20 |
| lifeless | but if its not then I'm going to stick by my tags theory | 00:20 |
| james_w | Jc2k: we could probably come up with a pretty simple script to convert the tags to bzr tags after the fact. | 00:21 |
| Jc2k | Pieter: everything is here | 00:22 |
| Jc2k | http://live.gnome.org/JohnCarr/Git | 00:22 |
| Jc2k | james_w: it would have to cope with getting run repeatedly | 00:22 |
| james_w | Jc2k: yup | 00:22 |
| Pieter | Jc2k: you might want to repack the bigger repos with a higher --window. see http://vcscompare.blogspot.com/2008/06/git-repack-parameters.html | 00:23 |
| lifeless | a couple of notes on size | 00:24 |
| lifeless | we have a plan to change to a better delta format | 00:24 |
| lifeless | we know from testing we can halve the effective size of the pack repository contents doing this | 00:24 |
| lifeless | (this is all on the list, I can find pointers) | 00:24 |
| lifeless | I think using a larger window is a bit like cheating, because most users won't repack themselves (or know to), and further the automatic packing git has recently added won't use this higher window - and the higher window has a cost | 00:26 |
| lifeless | unless one is in a storage crisis, disk space is unlikely to be a determining factor on whether something is pleasant/effective to use | 00:26 |
| lifeless | oh, finally - we're just about to land the work to allow not downloading all the history anyway, which makes repository size even more moot | 00:27 |
| * Jc2k is looking forward to stacked branches | 00:27 | |
| Jc2k | lifeless: still 30gb | 00:35 |
| * Jc2k heads for bed | 00:37 | |
| lifeless | Jc2k: ok | 00:47 |
| lifeless | Jc2k: could you do a project-by-project - | 00:47 |
| lifeless | du -s -m --apparent bzr/* ? | 00:47 |
| lifeless | and mail me or something | 00:47 |
| lifeless | bkor: or you, if Jc2k is gone :) | 00:48 |
| Pieter | Jc2k: your gtk+ repo e.g. goes down from 250MB to 70MB if you repack more tightly | 00:54 |
| Pieter | Jc2k: so you might be able to decrease that 6GB significantly | 00:54 |
| devnotes | Hi, I'm having a problem creating a branch when running bazaar on Windows, can someone help? | 01:12 |
| lifeless | sure | 01:13 |
| devnotes | when I execute "bzr branch lp:do" I get the following error: | 01:13 |
| devnotes | Permission denied (publickey). | 01:13 |
| devnotes | bzr: ERROR: Connection closed: please check connectivity and permissions (and tr | 01:13 |
| devnotes | y -Dhpss if further diagnosis is required) | 01:13 |
| devnotes | Any thoughts? | 01:13 |
| lifeless | I think you've done 'bzr launchpad-login' | 01:13 |
| devnotes | Sorry, not following you. | 01:14 |
| lifeless | but your username is wrong, or you don't have pagent running | 01:14 |
| lifeless | ok | 01:14 |
| lifeless | lp:do is a directory service url | 01:14 |
| devnotes | ok | 01:14 |
| lifeless | this does a lookup over the web for the real url | 01:14 |
| devnotes | ok, so I am typing the wrong value then? | 01:15 |
| lifeless | if you have told bzr what your launchpad username is, the real url is something like bzr+ssh://bazaar.launchpad.net/someuser/someproject/somebranch | 01:15 |
| lifeless | if you have not told bzr what your launchpad username is, you get given anonymous access via http | 01:15 |
| lifeless | can you run 'bzr launchpad-login' please | 01:16 |
| devnotes | it replies with nickp-developernotes | 01:17 |
| devnotes | sorry, that is 'nickp-developernotes' specifically. | 01:17 |
| lifeless | ok | 01:17 |
| lifeless | is that your launchpad account name? | 01:17 |
| devnotes | well, my "name" on launchpad is "developernotes", but I believe I use an email address to actually login. | 01:18 |
| lifeless | launchpad can be confusing | 01:18 |
| lifeless | is https://edge.launchpad.net/~nickp-developernotes you ? | 01:18 |
| devnotes | yep, that's me | 01:19 |
| lifeless | ok | 01:19 |
| lifeless | so, to access bzr+ssh you need to have ssh working | 01:19 |
| lifeless | there are a number of possible problems | 01:19 |
| devnotes | ok | 01:19 |
| lifeless | one is that the ssh agent is not working | 01:19 |
| devnotes | I provided my account on the webpage with my ssh key I have generated before. | 01:20 |
| devnotes | ssh agent local on windows? | 01:20 |
| lifeless | another (recently added one) is that your key is one of those generated by a buggy version of ssh, and has been blacklisted. | 01:20 |
| lifeless | there are others | 01:20 |
| lifeless | but lets check for the agent first | 01:20 |
| devnotes | ok | 01:20 |
| * spiv hops on a train | 01:20 | |
| lifeless | do you have pagent (the putty ssh agent) or some other agent that you use to unlock the ssh key? | 01:21 |
| * mwhudson finds a bug in simpletal :/ | 01:21 | |
| lifeless | or do you get asked a passphrase and type it in? | 01:21 |
| devnotes | no, do I need to download putty? | 01:21 |
| lifeless | no, I don'tthink we need it | 01:21 |
| devnotes | asked a passphrase when I do what? | 01:21 |
| devnotes | execute the branch command? | 01:21 |
| lifeless | yes | 01:22 |
| devnotes | no, it just replies with the error right away | 01:22 |
| mwhudson | oh well, it's not too bad | 01:22 |
| lifeless | devnotes: ok. I think you have a passphraseless key that is blacklisted. Uhm, how to check for this. | 01:22 |
| lifeless | devnotes: stand by a second, I will see if I can confirm this for you | 01:23 |
| devnotes | ok | 01:23 |
| lifeless | ssh-vulnkey +sshkeys | 01:24 |
| lifeless | Not blacklisted: 2048 26:59:18:ae:09:6b:fc:e6:47:98:ff:7d:8a:30:5d:cc nickp | 01:24 |
| lifeless | ok | 01:24 |
| lifeless | your key is fine | 01:24 |
| devnotes | ok | 01:24 |
| lifeless | so, I would guess bzr is not finding your key correctly | 01:25 |
| lifeless | can you run bzr --version | 01:25 |
| lifeless | there will be a log file location listed in the output | 01:25 |
| lifeless | can you look inside that log file | 01:25 |
| lifeless | hopefully there will be some clues | 01:25 |
| lifeless | jam: you use windows right? any help? | 01:25 |
| lifeless | markh: ^ | 01:25 |
| devnotes | what information do you want from the .bzr.log file, it's very long | 01:26 |
| lifeless | well have a look down the bottom | 01:27 |
| lifeless | see if it says anything about agents/keys/errors | 01:27 |
| lifeless | or you could remove the file | 01:27 |
| lifeless | and run the failing command again | 01:27 |
| lifeless | then open it and it will have just that commands errors | 01:27 |
| devnotes | 0.111 bzr arguments: [u'branch', u'lp:do'] | 01:28 |
| devnotes | 0.112 looking for plugins in C:/Users/Nick/AppData/Roaming/bazaar/2.0/plugins | 01:28 |
| devnotes | 0.112 looking for plugins in C:/Program Files/Bazaar/plugins | 01:28 |
| devnotes | 0.132 encoding stdout as sys.stdout encoding 'cp437' | 01:28 |
| devnotes | 2.352 ssh implementation is OpenSSH | 01:28 |
| devnotes | 3.594 Traceback (most recent call last): | 01:28 |
| lifeless | please post that sort of thing http://pastebin.com/ in future - its faster and easier to read. | 01:29 |
| devnotes | sorry, I'll do that now | 01:29 |
| lifeless | no problem | 01:29 |
| devnotes | http://pastebin.com/m3db7eeaa | 01:30 |
| lifeless | devnotes: ok, one good thing here is we now know the ssh its using | 01:30 |
| lifeless | devnotes: so we can debug a little deeper ourselves | 01:30 |
| lifeless | devnotes: please do: | 01:30 |
| lifeless | "ssh nickp-devnotes@bazaar.launchpad.net" | 01:31 |
| poolie | hello lifeless | 01:31 |
| lifeless | you should see something like: | 01:31 |
| lifeless | hi poolie | 01:31 |
| lifeless | No shells on this server. | 01:31 |
| lifeless | Connection to bazaar.launchpad.net closed. | 01:31 |
| devnotes | Permission denied (publickey). | 01:32 |
| devnotes | do I need to execute this from cygwin? | 01:33 |
| poolie | that conuts as success | 01:33 |
| lifeless | devnotes: its fine as is | 01:33 |
| lifeless | devnotes: now, we need to figure out if it is trying your ssh key and it doesn't match, or if its not finding your key | 01:34 |
| lifeless | devnotes: please try | 01:34 |
| lifeless | "ssh -v nickp-devnotes@bazaar.launchpad.net" | 01:34 |
| lifeless | the output will be long | 01:35 |
| lifeless | we're looking for lines like: | 01:35 |
| devnotes | yep, what are you looking for? | 01:35 |
| lifeless | debug1: Connection established. | 01:35 |
| lifeless | debug1: identity file /home/robertc/.ssh/identity type 0 | 01:35 |
| lifeless | debug1: Offering public key | 01:36 |
| lifeless | debug1: Server accepts key | 01:36 |
| lifeless | - but you could just copy and paste everything to pastebin and I'll look at it for you | 01:36 |
| devnotes | mines says "identity file /home/Nick/.ssh/identity type -1" | 01:36 |
| abentley | lifeless: What is the behavior of BzrDir.sprout supposed to be when the source bzrdir doesn't have a branch? | 01:37 |
| devnotes | http://pastebin.com/m770894d7 | 01:37 |
| lifeless | abentley: I chose rather arbitrarily to have it make a branch (because sprout is meant to make a new line of development). | 01:38 |
| lifeless | abentley: it could reasonably be defined to error instead | 01:38 |
| devnotes | huh? | 01:38 |
| lifeless | devnotes: the lines with abentley: in front of them are a seperate conversation | 01:38 |
| abentley | lifeless: understood. | 01:39 |
| devnotes | gotcha ;-) | 01:39 |
| lifeless | devnotes: I think the -1 indicates an error | 01:39 |
| lifeless | devnotes: please try again, with -vv instead of -v, and post the output | 01:40 |
| fullermd | I think type -1 indicates an RSA key... | 01:40 |
| fullermd | debug1: identity file /home/fullermd/.ssh/identity type 0 | 01:40 |
| fullermd | debug1: identity file /home/fullermd/.ssh/id_rsa type -1 | 01:40 |
| fullermd | debug1: identity file /home/fullermd/.ssh/id_dsa type 2 | 01:40 |
| lifeless | fullermd: | 01:41 |
| lifeless | debug1: identity file /home/robertc/.ssh/id_rsa type 1 | 01:41 |
| * fullermd ponders. | 01:41 | |
| fullermd | Ah, I don't have an id_rsa. Weird. I thought I did. | 01:41 |
| lifeless | fullermd: :) | 01:41 |
| lifeless | fullermd: thanks thats very helpful | 01:42 |
| fullermd | So, yeah, looks like no user keys at all. | 01:42 |
| lifeless | devnotes: can you look in your .ssh directory | 01:42 |
| lifeless | devnotes: you should have a file called 'id_rsa', if you don't, then we have identified the problem and can look at how to fix | 01:43 |
| fullermd | Well, either id_rsa or id_dsa should work. But with a -1 on both (and on identity, which is the v1 key)... | 01:43 |
| lifeless | fullermd: https://edge.launchpad.net/~nickp-developernotes/+sshkeys | 01:44 |
| lifeless | fullermd: I wasn't guessing as to file name :) | 01:44 |
| devnotes | http://pastebin.com/m606ae93a | 01:44 |
| fullermd | lifeless: Ack! You r hax0red him! | 01:44 |
| devnotes | inside my .ssh folder I have 3 files. | 01:45 |
| devnotes | id_rsa, id_rsa.pub, known_hosts | 01:45 |
| lifeless | devnotes: ok | 01:45 |
| lifeless | devnotes: for some reason ssh is not finding them | 01:46 |
| lifeless | devnotes: is it possible you have two folders called .ssh ? | 01:46 |
| devnotes | I'll do a search | 01:46 |
| devnotes | yes, I can see two right now, one in "C:\cygwin\home", another in "C:\Users" | 01:47 |
| lifeless | ok | 01:47 |
| lifeless | as an experiment, please try copying the id_rsa and id_rsa.pub files to the other .ssh folder | 01:48 |
| devnotes | the dir "C:\cygwin\home" only contains a known_hosts file | 01:49 |
| lifeless | after copying them, try | 01:49 |
| lifeless | "ssh nickp-devnotes@bazaar.launchpad.net" | 01:49 |
| devnotes | crap, just found another folder called ssh, note there is no period in front of it. | 01:50 |
| devnotes | two different directories.... | 01:50 |
| lifeless | well | 01:50 |
| lifeless | to start with, the .ssh folder that has known_hosts only | 01:50 |
| lifeless | that is the one to copy the two files I named into | 01:50 |
| devnotes | files copied, now what? | 01:52 |
| lifeless | "ssh nickp-devnotes@bazaar.launchpad.net" | 01:52 |
| devnotes | It asked me for a passphrase this time, 3 times actually, I am trying to remember my password and then I got "No shells on this server. Connection to bazaar.launchpad.net closed." | 01:53 |
| lifeless | devnotes: excellent | 01:54 |
| mwhudson | well, that means you connected successfully | 01:54 |
| lifeless | devnotes: now run your original bzr command and it should work | 01:54 |
| lifeless | devnotes: something in your setup has changed, but I don't know what. ssh, the secure transport we use, thinks your home directory has moved | 01:55 |
| devnotes | thanks a million! | 01:56 |
| lifeless | happy to help | 01:57 |
| devnotes | so when I execute "bzr branch lp:do" it takes awhile and comes back with "branched 371 revision(s), where did those go? | 01:58 |
| lifeless | "dir do" | 01:58 |
| devnotes | got it....I was looking for another directory for some reason | 01:59 |
| devnotes | do I need to cd into that dir to execute the push then? | 01:59 |
| lifeless | yes | 02:00 |
| poolie | yes we should print that | 02:02 |
| poolie | the destination directory name | 02:02 |
| devnotes | does the transfer normally take a while, it's been spinning with 0/4 for a while now | 02:04 |
| poolie | it can take a while, it depends on how much history is there | 02:04 |
| devnotes | gotcha | 02:06 |
| jml | lifeless: I've got a subunit branch for you to review at lp:~jml/subunit/split-right | 02:12 |
| lifeless | $ bzr break-lock | 02:48 |
| lifeless | Killed | 02:48 |
| lifeless | ouch | 02:48 |
| lifeless | having set a ulimit -v I can't alter it! | 02:48 |
| spiv | Heh. | 02:49 |
| lifeless | I'm doing some scaling testing on bzr | 02:50 |
| lifeless | as part of background idling tasks | 02:50 |
| lifeless | and its fun: | 02:51 |
| lifeless | h$ bzr pull http://bazaar-vcs.org/bzr/bzr.dev | 02:51 |
| lifeless | Fatal Python error: PyString_InternInPlace: strings only please! | 02:51 |
| lifeless | Aborted | 02:51 |
| lifeless | exsqueeze me! | 02:51 |
| mwhudson | oof | 02:52 |
| abentley | spiv: I have a test to ensure that cloning a format produces the same format on the output. | 03:20 |
| abentley | This test fails when the source repository is a RemoteRepository. | 03:21 |
| abentley | Do you have an idea how I should fix the test? | 03:21 |
| poolie | lifeless: wee! | 03:22 |
| poolie | i doubt if you will reliably get a clean MemoryError | 03:22 |
| spiv | abentley: there are already some tests like that in the suite | 03:22 |
| poolie | lifeless: also, i suspect there is already a practical limit on heap allocation at not much more than 2g | 03:22 |
| * spiv echoes the "wee!" | 03:23 | |
| poolie | well, on a 32bit machine, i guess yours is using 64bit userspace | 03:23 |
| spiv | abentley: are you cloning to somewhere on the same transport? Obviously you can't clone a RemoteBzrDir to a LocalTransport :) | 03:23 |
| lifeless | poolie: you do actually | 03:24 |
| lifeless | File "bzrlib/progress.py", line 435, in clear | 03:24 |
| lifeless | self.to_file.write('\r%s\r' % (' ' * (self.width - 1))) | 03:24 |
| lifeless | MemoryError | 03:24 |
| lifeless | for instance | 03:24 |
| lifeless | clearly the exact point that the error occurs will not always be where the leak is though :) | 03:24 |
| poolie | mm | 03:24 |
| abentley | spiv: Yes. To ../transport | 03:24 |
| poolie | i guess it may happen that the large allocation fails but there's enough to allocate stuff when doing the exception | 03:25 |
| poolie | lifeless: was that from running the test suite or actual use? | 03:25 |
| lifeless | poolie: actual use | 03:25 |
| lifeless | poolie: so the basic idea is to pretend to have a smaller machine | 03:25 |
| lifeless | we'll see what users with smaller machines see | 03:25 |
| lifeless | but not have to thrash on swap to find out | 03:25 |
| abentley | spiv: It doesn't seem like this was meant to be the point of the test. | 03:26 |
| lifeless | poolie: having found a use case that fails, normal analysis tools start to become relevant | 03:26 |
| spiv | abentley: what does "same format" mean in this context? | 03:26 |
| abentley | Same repository format. | 03:27 |
| abentley | It's about making sure the on-disk format matches. | 03:27 |
| spiv | abentley: so there's test_sprout_from_hpss_preserves_format in repository_implementations already, which seems like a related test. | 03:30 |
| spiv | abentley: it uses bzrdir.BzrDir.open(self.get_vfs_only_url(...)).open_repository() to always get a non-Remote object when it wants to inspect the on-disk format. | 03:31 |
| spiv | abentley: I think that's a reasonable way to do it. | 03:31 |
| spiv | abentley: will that work for you? | 03:31 |
| abentley | Sure, thanks. | 03:31 |
| spiv | np | 03:32 |
| abentley | spiv: Wait. | 03:32 |
| poolie | i'm going to do a couple more mails then go back into finishing the versionedfiles merge | 03:32 |
| spiv | Hmm? | 03:32 |
| poolie | thanks for your answer lifeless | 03:32 |
| abentley | get_vfs_only_url is only implemented on remote objects? | 03:32 |
| lifeless | abentley: its a test suite helper method | 03:32 |
| spiv | No, it's on TestCaseWithMemoryTransport | 03:32 |
| lifeless | abentley: the test suite has three transports: readonly, branch/reopsitory (the default), and vfs-only | 03:33 |
| lifeless | vfs-only is the backing transport for the Remote* objects used by the server side | 03:33 |
| lifeless | so you can peek at what is going on | 03:33 |
| abentley | Okay. | 03:33 |
| abentley | Does get_vfs_only_url work when the bzrdir format is not RemoteBzrDirFormat? | 03:36 |
| lifeless | it should always be set | 03:38 |
| abentley | Got it. | 03:38 |
| abentley | lifeless: Sprout doesn't create the branch until the fetch is complete. Do you think that's an important behavior? | 03:39 |
| abentley | It would be easier for me if I could just set stacking before fetching. | 03:39 |
| lifeless | I think its important that we don't have a branch object other people could open and get the wrong repository/no repository error | 03:40 |
| lifeless | how that is achieved I am not too concerned by | 03:40 |
| lifeless | you can set stacking on a repository directly, by calling the add_fallback_repository method before the fetch is done | 03:41 |
| abentley | lifeless: Yes, I see this, and doing this in the repository acquisition policy is the other option I'm contemplating. | 03:41 |
| poolie | hm, mhammond is seeing much slower plain http pull than i am on linux, even for a similar repository | 03:43 |
| poolie | maybe there is something about his repo | 03:43 |
| === thumper_laptop is now known as thumper | ||
| jam | lifeless: I use windows, but I use pageant or cygwin's openssh | 03:59 |
| jam | lifeless: I don't know how to configure paramiko to use keys without pageant | 03:59 |
| === kiko is now known as kiko-zzz | ||
| lifeless | jam: you like like to idle in #gnash for a bit, or abentley, or both of you - project migrating to bzr | 04:08 |
| Scoobert | noob with question | 04:09 |
| abentley | lifeless: I got an email from you, but I couldn't really understand the bit about state. | 04:09 |
| lifeless | abentley: I was referring to where the conversion data was | 04:09 |
| lifeless | in case it was bad or needed tweaking or whatever - jam wrote the converter in question | 04:10 |
| abentley | That was on rookery? | 04:10 |
| lifeless | tungsten | 04:10 |
| lifeless | I put the tarball of the output repository + branches on rookery | 04:10 |
| lifeless | anyhow, I'm hand holding during my tz | 04:10 |
| lifeless | but if one of you could lurk there your tomorrow it would be good, I think | 04:11 |
| lifeless | Scoobert: shoot | 04:11 |
| Scoobert | k | 04:11 |
| lifeless | Scoobert: (generally, don't wait, just ask :)) | 04:11 |
| Scoobert | two developers add something to the end of the same module(happens alot on a virgin project)... = conflict for just about any VCS ... why oh why | 04:12 |
| abentley | Okay. | 04:12 |
| lifeless | Scoobert: do you mean, you have a file like (say) foo.c | 04:13 |
| lifeless | Scoobert: and dev one adds a function to the bottom | 04:13 |
| lifeless | Scoobert: and dev two, in their own branch, adds a function to the bottom | 04:13 |
| lifeless | Scoobert: and then when you merge, there is a big conflict? | 04:13 |
| Scoobert | precicely, lifeless. | 04:13 |
| Scoobert | any way to avoid? (i love bzr btw) | 04:14 |
| lifeless | Scoobert: so, its because we treat files as text, rather than some more abstract thing that means 'C source code' | 04:14 |
| Scoobert | of course...and thank goodness it's true since we version more than mere code. | 04:16 |
| Scoobert | but wish one could configure a merge algo to ignore conflicts at the EOF, or at least treat them as 'special' conflicts. | 04:16 |
| lifeless | Scoobert: if we knew it was C code we could say 'dev 1 added funcX' and 'dev2 added funcY' so there is no conflict | 04:16 |
| lifeless | as it is yeah, we see an insertion at EOF from two people and it conflicts | 04:17 |
| lifeless | uhm, generally anywhere between functions this concept of two-insertions shouldn't conflict would be nice (if they had no identical lines, for instance) | 04:17 |
| Scoobert | for instance I script out all the stored procs for my DB at the end of each day and VC them. I'm glad bzr recognizes any and all differences in that case | 04:18 |
| lifeless | perhaps file a bug. we do have pluggable merge methods so its possible for someone to experiment with this | 04:18 |
| Scoobert | all right. Thanks. | 04:19 |
| lifeless | abentley: where can people get hitchhiker? | 04:19 |
| lifeless | nvm found it | 04:20 |
| abentley | lifeless: I've added some fun stuff since I announced it, e.g. non-interactive mode. | 04:21 |
| lifeless | abentley: we have to reverse engineer the hosting facility on savannah | 04:21 |
| abentley | lifeless: Oh, fun. | 04:22 |
| lifeless | you can ls right ? | 04:22 |
| abentley | lifeless: Sure. | 04:23 |
| abentley | See help for a list. | 04:24 |
| lifeless | thanks, it helped | 04:33 |
| mwhudson | i should write a plugin that shows a bazaar branch in loggerhead | 04:39 |
| mwhudson | any funky ideas for the names of the plugin or command ? | 04:40 |
| lifeless | serve --http? | 04:41 |
| mwhudson | that works i guess | 04:42 |
| mwhudson | especially as we should make loggerhead actually serve up the .bzr files | 04:42 |
| mwhudson | lifeless: do you have an example of adding an option to a command in a plugin that i can crib from? | 04:45 |
| abentley | lifeless: I just fixed some bugs in hitchhiker's "info", "cat" and "get" commands as of revno 16. | 04:45 |
| lifeless | abentley: cool, I think we're done for now though, no write access -> not much to do | 04:46 |
| abentley | lifeless: This is the first public bzr: server I've seen, so it's kinda fun to play with. | 04:47 |
| lifeless | ah :) | 04:47 |
| mwhudson_ | lifeless: do you have an example of adding an option to a command in a plugin that i can crib from? | 05:13 |
| mwhudson_ | ^ did that get a reply? | 05:13 |
| lifeless | mwhudson_: oh yes; uhm, in this case I'd decorate the command I think (see the thread with jml re 'status' in loom) | 05:14 |
| lifeless | mwhudson_: but I have written a plugin somewhere that actually introspects the command and adds an option | 05:14 |
| lifeless | mwhudson: GET AN INTERNET | 05:15 |
| mwhudson_ | grrrrrrr | 05:15 |
| lifeless | mwhudson_: oh yes; uhm, in this case I'd decorate the command I think (see the thread with jml re 'status' in loom) | 05:15 |
| lifeless | mwhudson_: but I have written a plugin somewhere that actually introspects the command and adds an option | 05:15 |
| lifeless | don't remember the name of it :P | 05:15 |
| mwhudson_ | heh | 05:15 |
| mwhudson_ | i'll look at loom | 05:15 |
| jml | mwhudson_: it's worth reading the thread too. | 05:16 |
| jml | mwhudson_: you should note your findings and submit them as a doc patch. | 05:16 |
| lifeless | ok found it | 05:16 |
| lifeless | old_format_type = builtins.get_format_type | 05:17 |
| lifeless | builtins.get_format_type = get_format_type.decorate_get_format_type( | 05:17 |
| lifeless | old_format_type) | 05:17 |
| lifeless | # XXX: This is ugly, fix bzrlib to make it cleaner. Right now changing the | 05:17 |
| lifeless | # parser does not help because the old name is bound into the Options array for | 05:17 |
| lifeless | # each command. | 05:17 |
| lifeless | for command in commands._get_cmd_dict().values(): | 05:17 |
| lifeless | if isinstance(command.takes_options, (set, list)): | 05:17 |
| lifeless | for option in command.takes_options: | 05:17 |
| lifeless | if not isinstance(option, bzrlib.option.Option): | 05:17 |
| lifeless | continue | 05:17 |
| lifeless | if option.type == old_format_type: | 05:17 |
| lifeless | option.type = builtins.get_format_type | 05:17 |
| lifeless | yes, I know pastebin, sosueme | 05:17 |
| mwhudson_ | oh well, that's a bit more complicated than i need i think | 05:19 |
| lifeless | that alters a option for many commands that use it | 05:19 |
| lifeless | my suggestion of decorating was intentional | 05:19 |
| lifeless | abentley: how does one tell a branch to preserve history / | 05:20 |
| lifeless | abentley: (as in ,where is the doc to tell someone what to do) | 05:20 |
| abentley | It's in bzr help configuration. | 05:21 |
| abentley | append_revisions_only | 05:21 |
| abentley | (If I understand the question) | 05:21 |
| lifeless | so, its 'edit .bzr/branch/branch.conf and insert append_revisions_only=True' ? | 05:21 |
| lifeless | (I want to tell rob savoye to do this on trunk) | 05:21 |
| abentley | lifeless: yes. | 05:23 |
| lifeless | thanks | 05:23 |
| abentley | lifeless: also, you can set it when you create the branch. | 05:23 |
| abentley | bzr init --append-revisions-only | 05:24 |
| lifeless | abentley: conversions though, don't have new branches :) | 05:26 |
| abentley | lifeless: It looks like BzrDir.clone is supposed to clone branch references verbatim. This suggests it's not a good basis for 'bzr push', and probably explains a bug with pushing from lightweight checkouts. | 05:34 |
| lifeless | abentley: well, its meant to preserve the state yes; its definitely related to the occasional bug with push; what should be happening is that the opened branch's bzrdir is used to clone() from | 05:35 |
| lifeless | but for some reason sometimes people clone() from the tree's bzrdir - which is ok for cloning the checkout, but erroneous for push (which should only be working on the branch) | 05:36 |
| abentley | lifeless: but if you clone from the branch's bzrdir, you won't get a tree. | 05:37 |
| lifeless | thats true | 05:39 |
| abentley | It seems like if we used sprout instead, then clone could life up to its name. | 05:41 |
| lifeless | we could; though doesn't that confuse too - push is used to publish a branch, not to make a new line of development ? | 05:42 |
| mwhudson_ | lifeless: this is where i've got to: http://pastebin.ubuntu.com/21320/ | 05:45 |
| === mwhudson_ is now known as mwhudson | ||
| lifeless | mwhudson: looks like it will work | 05:48 |
| lifeless | mwhudson: unlike your internet | 05:48 |
| abentley | lifeless: Yeah, but any branch is potentially a new line of development. cp -r was the original "bzr branch". | 05:55 |
| abentley | There's a small amount of policy that branch should handle and push should not. But they basically do the same thing. | 05:56 |
| abentley | lifeless: I'm especially running into weirdness because bzrdir.open_branch().repository may or may not be the same as bzrdir.open_repository + fallbacks. | 06:02 |
| abentley | And if I'm cloning the root of a shared repo with stacked branches, I think I'm completely SOL. | 06:04 |
| lifeless | well, even without stacking, branch.repository is not guaranteed to == branch.bzrdir.open_repository | 06:05 |
| abentley | lifeless: Sure. It's the partial revisions I worry about. | 06:08 |
| abentley | Fetching a revision when you don't have all the texts for its tree. That kind of thing. | 06:08 |
| lifeless | abentley: Can you expand on that? Do you mean a single repository that has a revision but not the matching text deltas ? | 06:09 |
| abentley | Yes. Because the text deltas are older than that revision, so they're in the stacked_on repository. | 06:10 |
| lifeless | I think I'm misunderstanding; the text deltas are surely precisely the same ages as the revision | 06:13 |
| === yacc__ is now known as yacc | ||
| yacc | Does hadoop start one and the same map tasks on multiple nodes concurrently? | 06:56 |
| lifeless | ? | 06:56 |
| yacc | oops, wrong channel ;( | 06:58 |
| kumi2 | heh | 06:58 |
| kumi2 | I was also going to ask something irrelevant, but you beat me to it | 06:58 |
| yacc | kumi2, sorry. | 06:59 |
| yacc | kumi2, I cheated, I only slept 2hours, so it's really unfairly easy for me to say something stupid :-P | 07:00 |
| kumi2 | :) | 07:03 |
| Pieter | I hate it when that happens | 07:14 |
| dholbach | good morning | 07:37 |
| dholbach | can somebody tell me how in a bound branch with local commits I'd find out the timestamp of the last 'pushed commit'? | 07:37 |
| lifeless | bzr missing ? | 07:38 |
| dholbach | lifeless: do you know what in bzrlib I'd need to look for? I just don't know how to distinguish between a local commit and a 'pushed commit' - I'd prefer if the operation was light-weight :) | 07:47 |
| lifeless | dholbach: there really isn't a difference, except one is not in the master branch | 07:48 |
| lifeless | dholbach: distributed system, symmetrical behaviour etc | 07:48 |
| lifeless | e.g. bzr log MASTERURL and bzr log LOCALURL and see the difference | 07:49 |
| dholbach | HRM | 07:49 |
| dholbach | to not hammer the main branch of 5-a-day-data (where lots of people commit the bugs they worked on to) we used commit (either forced or if the last commit was 60+ minutes ago) - now we pondered using local commits instead and 'pushed commits' every 60+ minutes instead | 07:51 |
| lifeless | does just commit not work ? | 07:52 |
| dholbach | it does, it's just a problem if you use the 5-a-day client on two machines, where local commits might work better | 07:53 |
| lifeless | why would they work better? | 07:54 |
| dholbach | I guess you don't get conflicts that easily :) | 07:54 |
| lifeless | Well, I'm looking for some statement of problem from you | 07:54 |
| lifeless | so we can discuss | 07:54 |
| dholbach | right now calling the tool just adds stuff to a text file, every 60+ minutes it does a commit | 07:55 |
| lifeless | it sounds like 'we are seeing conflicts when we commit a lot from different machines' is your problem | 07:55 |
| lifeless | is it one text file for everyone | 07:55 |
| lifeless | or one per user | 07:55 |
| lifeless | or one per bug | 07:55 |
| lifeless | or ..? | 07:55 |
| dholbach | one per user, in one branch | 07:56 |
| lifeless | whats the 60 minute delay for? | 07:56 |
| dholbach | we had a lot of problems with locks on bzrlp | 07:56 |
| dholbach | we have nearly 120 committers and 5000 revisions in the last 5 months | 07:57 |
| lifeless | so | 07:58 |
| lifeless | the general thing to reduce concurrency is to add branches | 07:58 |
| lifeless | rather than delaying commits | 07:58 |
| dholbach | OK | 07:58 |
| lifeless | why do you have one branch ? | 07:58 |
| dholbach | I wanted to make it easy to make statistics from just getting one branch :) | 07:58 |
| lifeless | so this is for stats | 07:59 |
| lifeless | not for people to not tread on each other? | 07:59 |
| dholbach | I agree we could change it to branch-per-person | 07:59 |
| lifeless | so | 08:00 |
| dholbach | http://daniel.holba.ch/5-a-day-stats/ is what I generate from the one branch | 08:00 |
| lifeless | lp can list the branches for you | 08:00 |
| lifeless | a small script can easily merge every branch that has new commits by using lp to determine that | 08:00 |
| lifeless | and you then have one branch with all your people | 08:00 |
| dholbach | I'll look into changing that | 08:01 |
| lifeless | screen scrape https://code.edge.launchpad.net/5-a-day-data | 08:01 |
| dholbach | especially with the Global Bug Jam coming up in early August, I'd like to have that situation fixed :) | 08:01 |
| lifeless | oh, this would be interesting to toss bzr-search at | 08:02 |
| lifeless | to answer 'who fixed X' :P | 08:02 |
| dholbach | it's not necessarily about "Who fixed it?" but "Who made bug report X better?" :) | 08:02 |
| dholbach | hi mvo | 08:03 |
| lifeless | well | 08:03 |
| lifeless | who touched X | 08:03 |
| dholbach | right-o | 08:03 |
| lifeless | have you seen bzr-search? | 08:03 |
| mvo | hi dholbach | 08:03 |
| dholbach | lifeless: no, not yet | 08:03 |
| lifeless | abentley: API question for you; do you think having VF.get_sha1s return a dict would be better? | 08:04 |
| lifeless | abentley: seems it would be more useful to me, for stacking | 08:04 |
| lifeless | dholbach: read planet. | 08:04 |
| abentley | lifeless: Yeah, that's more likely useful. Or at least key/val pairs. | 08:05 |
| lifeless | abentley: I'll change it to a dict I think, sha1s's are small | 08:06 |
| === thumper_laptop is now known as thumper | ||
| lifeless | dholbach: http://advogato.org/person/robertc/diary/87.html | 08:11 |
| dholbach | I'm playing with it right now :) | 08:11 |
| dholbach | lifeless: NICE | 08:12 |
| dholbach | still it says "Unable to load plugin 'search' from '/home/daniel/.bazaar/plugins'" | 08:12 |
| lifeless | dholbach: does it? | 08:13 |
| dholbach | yeah | 08:13 |
| lifeless | dholbach: what bzr version do you have? | 08:13 |
| dholbach | 1.3.1-1ubuntu0.1 | 08:13 |
| lifeless | garh | 08:13 |
| lifeless | get 1.4 | 08:13 |
| lifeless | or 1.5 | 08:13 |
| dholbach | get it into hardy! | 08:13 |
| lifeless | or 1.6b | 08:13 |
| dholbach | at least it should be in hardy-backports | 08:13 |
| dholbach | or something | 08:13 |
| lifeless | we have a ppa | 08:13 |
| lifeless | with builds for hardy | 08:14 |
| dholbach | that's not the same :) | 08:14 |
| lifeless | I know | 08:14 |
| lifeless | anyhow, that just means it won't update the index on push/pull/commit | 08:14 |
| lifeless | you can run 'bzr index' to incrementally update | 08:14 |
| dholbach | yeah | 08:14 |
| dholbach | good night lifeless | 08:17 |
| lifeless | I was sayin gnight to poolie :) | 08:17 |
| lifeless | I have much to do still | 08:17 |
| dholbach | ah ok :) | 08:18 |
| === thekorn_ is now known as thekorn | ||
| === weigon__ is now known as weigon | ||
| Jc2k | morning all | 09:34 |
| matkor | Hi ! | 09:39 |
| matkor | is there any way to bzr cp file (to other location in same branch ) ? | 09:39 |
| Peng | No. | 09:40 |
| lifeless | hi Jc2k | 09:42 |
| lifeless | matkor: not yet, it is planned in some regard | 09:42 |
| Jc2k | hi lifeless, just grabbing the du thing now | 09:42 |
| lifeless | Jc2k: can you do du -s -m --apparent bzr/* | 09:42 |
| lifeless | Jc2k: :) | 09:42 |
| lifeless | Jc2k: I would like that, compared with git - then we can see if the pattern is consistent | 09:42 |
| lifeless | Jc2k: or perhaps there are some outliers | 09:42 |
| Jc2k | lifeless: jesus wept, gimp is 10gb | 09:46 |
| lifeless | ahha! | 09:46 |
| lifeless | and how big is the git gimp | 09:46 |
| Jc2k | one sec | 09:47 |
| lifeless | so this would be useful: | 09:47 |
| lifeless | bzr size, git size, ratio | 09:47 |
| lifeless | in a tabular form | 09:47 |
| lifeless | the worst ratio is the first one we should look at | 09:47 |
| Jc2k | bzr, http://pastebin.ca/1050900 | 09:47 |
| * Jc2k runs command to get git foo | 09:48 | |
| AfC | Jc2k: whoa | 09:56 |
| * AfC admits that he was very concerned about the revelation that bzr-svn operates in a manner that creates (was it file properties?) that are visible to other users of an underlying Subversion repository. That doesn't seem to be the sort of thing that is likely to impress people. | 09:58 | |
| AfC | Jc2k: by the way, I thought you did a really nice job with http://gnome.unrouted.co.uk/ | 10:04 |
| Peng | What does bzr-svn do? | 10:06 |
| AfC | Peng: read the thread around http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/41686/focus=42933 . Dear Dr Winder is a tad persistent for my tastes, but he and Ben seem to be pointing out a behaviour that could lead to bad PR for Bazaar. | 10:18 |
| AfC | (though I cannot think, off hand, what bzr-svn could do differently given its long declared mission of storing full Bazaar branch information in a foreign repository) | 10:19 |
| Peng | Oh. | 10:21 |
| Pieter | Jc2k: did you get my notes on git's repack? | 10:39 |
| lifeless | Pieter: why do you have to supply an option? | 10:45 |
| Pieter | the default has a low setting. it can be ok for smallish repo's, but you get a lot better results witha higher --window | 10:45 |
| lifeless | so why isn't the default higher? | 10:47 |
| Pieter | because it takes longer | 10:47 |
| lifeless | (what is the impact on people of telling them to do this | 10:47 |
| lifeless | (so that it can be evaluated more deeply than just 'it can be foreced to do XXX' | 10:47 |
| Pieter | the default was mostly just a guessed value, as nobody had done any benchmarks before | 10:48 |
| Pieter | but you typically only need to do it once for a repository, after that people shouldn't repack --aggressive anymore | 10:48 |
| lifeless | bzr tries to manage this so most users never need to run pack at all | 10:49 |
| Pieter | git autopacks every xx commits too | 10:49 |
| lifeless | though folk seem to be working around a couple of perf bugs by running pack :( | 10:49 |
| Pieter | you just need to do it the first time because git-svn doesn't produce good packs | 10:50 |
| lifeless | yes, I know - they brought that in after bzr released a packs repository, AFAIK | 10:50 |
| Pieter | There had been some patches, but there was a lot of resistance for auto-repack from older git users | 10:50 |
| Pieter | because it can take some time to do, they wanted to do it themselves | 10:51 |
| lifeless | what was the objection ? | 10:51 |
| lifeless | ah, raced with you :) | 10:51 |
| lifeless | so with bzr some folk have said it should be manual | 11:00 |
| lifeless | but to date, once I point out its amortising latency noone has objected further :) | 11:01 |
| Pieter | :D | 11:02 |
| lifeless | one of the big differences ibetween bzr and git that I can see is the size of the remote api | 11:04 |
| lifeless | git is extremely minimal, but we allow all branch operations - create/delete/commit/push/pull/uncommit/diff/cat/etc over the wire from the standard client | 11:04 |
| Peng | hg is minimal too: http://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol | 11:08 |
| lifeless | yup | 11:08 |
| lifeless | this makes doing adhoc queries harder without a web UI running | 11:08 |
| lifeless | as well as making various scripts etc more complex | 11:08 |
| Peng | ISTM though that hg has had an effective smart protocol for ages, while bzr is still working on clunking together something complicated and inefficient. | 11:10 |
| Peng | Which is rude to say, but it's the impression I've been getting. | 11:10 |
| Peng | And, the reason is that you (and that's a collective "you") weren't focusing on the smart protocol for a long time, and are trying to create something feature-rich and robust. | 11:11 |
| === kiko-zzz is now known as kiko | ||
| Peng | But still; hg's decision seems to have worked out decently for them. | 11:11 |
| Peng | Yeah...I don't know why I just said all that. | 11:14 |
| gour | moon phase? | 11:15 |
| lifeless | appearances matter :P | 11:15 |
| lifeless | so bzr works very well with no smart server, hg requires one to scale decently | 11:15 |
| lifeless | hg's wire protocol only scales if you keep the heads() list small | 11:16 |
| lifeless | and yes, we're now writing a full smart server and the tension is getting the smallest possible set of methods | 11:16 |
| Peng | gour: Yeah. That works. | 11:16 |
| lifeless | because more than are needed is bloath | 11:17 |
| lifeless | but not enough is slow | 11:17 |
| gour | Peng: ;) | 11:17 |
| lifeless | if we required a streaming protocol, it would be a lot easier | 11:17 |
| lifeless | (git does this AFAICT) | 11:17 |
| lifeless | but we wanted to tunnel cleanly over http | 11:18 |
| Peng | If you created a minimal API, would that ruin dumb server performance? | 11:18 |
| lifeless | no, abstract interfaces for the win | 11:19 |
| lifeless | (and we have a minimal interface, just too minimal, and done a bit naively - first cut) - we're improving that release by release | 11:20 |
| liw | mmm. bzr performance. I should do some more torture. | 11:24 |
| Jc2k | AfC: its bzr-mirror.gnome.org now :) you should join #gnome-bzr | 11:25 |
| gour | any chance for gnome to embrace bzr? | 11:26 |
| Jc2k | gour: all i have to say is, bzr-mirror.gnome.org works, git-mirror.gnome.org... resolves to 127.0.0.1.. :P | 11:27 |
| gour | :-D | 11:27 |
| gour | what about projects like postgresql, wxwidgets...? any of them talk about migration? | 11:28 |
| Jc2k | AfC: btw, im not concerned about the use of properties at all. i think its awesome. obviously revision properties would be better... | 11:30 |
| Jc2k | AfC: but if you look at gnome-specimen in loggerhead, you see how it preserved some data that svn would ahve thrown away | 11:31 |
| Jc2k | AfC: spot the commit that was done in SVN: http://bzr-mirror.gnome.org:9876/gnome-specimen/trunk/changes | 11:31 |
| lifeless | liw: running that 22GB repository is interesting | 11:38 |
| lifeless | liw: I think we need to disable one of the internal caches, or make it LRU or something | 11:38 |
| Jc2k | lifeless: i did my ratio the wrong way around but i actually found a bunch of repos where Git sucks ass | 11:39 |
| Jc2k | lifeless: 1mb of gnome-cookbook BZR to 37MB of Git gnome-cookbook | 11:40 |
| liw | lifeless, I have about three months' worth of daily snapshots of Debian/Ubuntu mirrors, I was thinking that it would be fun to build a repo with all those source packages... | 11:40 |
| Jc2k | lifeless: on the other hand, my git mirror of f-spot is 11mb and my bzr mirror is 482mb.. | 11:41 |
| lifeless | Jc2k: please do | 11:41 |
| lifeless | meh, liw please do | 11:41 |
| lifeless | Jc2k: ok | 11:41 |
| Jc2k | i wonder | 11:41 |
| lifeless | Jc2k: lets get some more figures behind this | 11:41 |
| Jc2k | f-spot i could have cocked up | 11:41 |
| lifeless | Jc2k: the revision count for each import | 11:41 |
| Jc2k | *checks* | 11:41 |
| liw | lifeless, "meh"? | 11:41 |
| lifeless | Jc2k: (perhaps bzr-svn is getting more history) | 11:41 |
| lifeless | liw: meh at nmistyping names :) | 11:41 |
| liw | lifeless, ah | 11:42 |
| lifeless | Jc2k: and get the tag count for each project | 11:42 |
| Jc2k | yup, f-spot i cocked up | 11:42 |
| Jc2k | some of the ones i did manually at first had working trees | 11:44 |
| Jc2k | lifeless: you have google docs? i'll throw this on a google docs spreadsheet? | 11:47 |
| Jc2k | lifeless: don't suppose you know the foo to get total revisions in a git repo and a bzr repo? | 11:49 |
| Peng | Does "bzr pack" fix un-optimal things, like if fulltexts appear more frequently than they should for some reason (like bzr-fastimport)? | 11:49 |
| james_w | Jc2k: bzr info -v lists the revision counts I believe | 11:49 |
| Peng | Like, does it re-encode/reprocess things, or just shuffle data around? | 11:50 |
| james_w | Jc2k: for a single branch "git rev-list | wc -l" will do it I think | 11:51 |
| Jc2k | gah, too brain dead to splice the output of bzr info -v | 11:54 |
| Jc2k | and i have many branches for the git mirrors in some cases | 11:54 |
| lifeless | Peng: bzr pack does not do that [yet] | 12:07 |
| lifeless | Jc2k: I can get gdocs | 12:07 |
| lifeless | Jc2k: for bzr, I was suggesting 'bzr revno' | 12:08 |
| Pieter | james_w: that revision count sometimes doesn't correspond to the number of commits "git log" gives btw | 12:24 |
| james_w | why not? | 12:24 |
| Jc2k | Pieter: i got your notes, but right now i'm more interesting in getting my mirrors to work than packing them tbh ;) | 12:27 |
| Pieter | james_w: I don't know, I just noticed it | 12:28 |
| kiko | hey | 12:42 |
| kiko | this bzrlib thing | 12:42 |
| kiko | who wrote it? | 12:43 |
| lifeless | kiko: some randoms | 12:50 |
| kiko | lifeless, I have to say, it's just blown me away as to how cool it is. and I don't ever say that! | 12:51 |
| lifeless | kiko: excellent :) | 12:51 |
| kiko | lifeless, I think these randoms know that they are doing | 12:56 |
| kiko | lifeless, what's the easiest way to print the last log message committed to a working tree? | 12:59 |
| mwhudson_ | tree.branch.repository.get_revision(tree.branch.last_revision()).message i think | 13:01 |
| * mwhudson_ zzzs | 13:01 | |
| lifeless | tree.last_revision() | 13:01 |
| lifeless | but yes | 13:01 |
| kiko | mwhudson_, ah, thanks. | 13:02 |
| gour | kiko: invoke "bzr log -r last:1" :-) | 13:03 |
| kiko | gour, I am a bzrlib maven. I don't mess with no commandline!! | 13:03 |
| cyberix | Is bazaar going to have a sprint at europython this year? | 13:19 |
| lifeless | cyberix: I don't think so, because the bzr folk that would be likely to go are going to GUADEC, and the dates are the same | 13:27 |
| lifeless | (bzr core folk I mean). obvisouly anyone is welcome to organise seomthing : | 13:28 |
| lifeless | :) | 13:28 |
| cyberix | The ones at europython are going to be my first sprints ever, I'm not even sure what they are | 13:38 |
| cyberix | I've been told that it is about people coding rapidly together | 13:38 |
| lifeless | yah | 13:39 |
| cyberix | I use bzr so it might be more interresting to me than some arbiray web framework | 13:39 |
| jelmer | cyberix, afaik larstiq was going to europython this year | 14:10 |
| lifeless | night all | 14:30 |
| lifeless | Verterok: is beuno feeling better? | 14:30 |
| lifeless | Jc2k: I'll try to catch up with you tomorrow morning | 14:31 |
| Jc2k | lifeless: kk | 14:31 |
| Jc2k | night | 14:31 |
| jaypipes | statik: http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ | 14:43 |
| statik | jaypipes: hurrah! i'm trying to post something about it now too | 14:47 |
| jaypipes | statik: this coming within the hour from Giuseppe: http://datacharmer.blogspot.com/2008/06/from-bazaar-to-sandbox-in-5-moves.html | 14:48 |
| beuno | lifeless, howdy :) | 14:51 |
| beuno | slept 12 hours, everything is looking better now | 14:51 |
| jam | beuno: /cheer | 14:51 |
| beuno | hey jam! | 14:51 |
| beuno | jam, are we going to have a "This week in Bazaar", well, this week? | 14:52 |
| jam | beuno: we should, statik agreed to it | 14:53 |
| jam | we'll probably be mostly talking about the above announcement | 14:53 |
| beuno | oh, it's official? col! | 14:54 |
| beuno | *cool | 14:54 |
| jam | beuno: yeah, about 3-6 months of the last year has been working on that | 14:54 |
| jam | nice to have it mostly public now | 14:54 |
| beuno | yeah, it got delayed too, didn't it? | 14:55 |
| beuno | (blog seems down to me) | 14:55 |
| jam | well, official announcements always seem to | 14:55 |
| jam | beuno: both blogs open for me | 14:55 |
| gour | jay! new bigger customer for bzr | 14:56 |
| === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta2 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ | ||
| beuno | odd, doesn't open here | 14:57 |
| jaypipes | gour: indeed, indeed. :) | 14:58 |
| gour | what about postgresql? still cvs? | 14:58 |
| jam | gour: last I checked | 14:58 |
| jam | which was ~6 months ago | 14:58 |
| gour | they're nice potential customer...i was thinking about wxwidgets lately as well | 14:59 |
| beuno | jam, I suppose congratulations are in order, your work payed off (and I suppose statik's too) | 14:59 |
| jam | thanks | 15:00 |
| jam | yeah, statik was really the power broker here | 15:00 |
| jam | I just did the conversion | 15:00 |
| jam | and we've been supporting them as they hit hiccups | 15:00 |
| * gour congrats to all | 15:00 | |
| jam | Its actually quite good to have a group like them, as it starts pushing at our seams | 15:00 |
| gour | jam: what do you think about postgresql and wxwidgets? | 15:01 |
| jam | gour: I like both of them :) I have no idea what their community is like, or how open they are to suggestions about VCS | 15:01 |
| jam | I was on postgres a long time ago | 15:01 |
| jam | (the mailing list) | 15:02 |
| gour | sqlite? | 15:02 |
| statik | i've heard some mild inquiries about postgres, we sure would be happy to help them convert if there is someone in the postgres dev community that wants to work with us | 15:02 |
| jam | gour: the big problem is that I'm a developer/user, and not really a politician. Statik is the guy to go to, if you want someone to do what you want :) | 15:02 |
| statik | sqlite would be interesting too, but I think most dev there is done by one person | 15:02 |
| gour | sqlite is CVS | 15:03 |
| james_w | hi jam | 15:03 |
| james_w | hi statik | 15:03 |
| james_w | congratulations | 15:03 |
| jam | hi james_w | 15:03 |
| jaypipes | jam: we like pushing on the seams. ;) | 15:04 |
| statik | thanks! all i did was talk, jam did the real work :) | 15:04 |
| gour | statik: get gnome & xfce for now ;) | 15:04 |
| statik | yes, several people are going to GUADEC to help, and that gnome-bzr mirror is pretty nice | 15:05 |
| jam | statik: politics out-weigh technology every time. | 15:06 |
| Jc2k | gnome isn't going to be easy, a lot of the core people are already distracted by Git | 15:08 |
| gour | same with gtk | 15:11 |
| === abentle1 is now known as abentley | ||
| gour | btw, i use haskell and moved to bzr from darcs...haskell community still sticks to darcs although e.g. ghc has problems with it | 15:12 |
| jam | gour: did you try darcs "2"? | 15:15 |
| jam | I at least thought I heard it had changed some fundamental bits to work better | 15:15 |
| jam | I do wish we could have their cherrypicking support | 15:15 |
| jam | just haven't figured out how to represent it well in a snapshot model | 15:16 |
| gour | jam: see top of http://bugs.darcs.net/ it happened in the week when i was seriously evaluating bzr ;) | 15:17 |
| jam | "No I don't think so, it is a non-local problem" | 15:18 |
| jam | ouch | 15:18 |
| jam | gour: I forgot that the comments are in reverse order... a bit hard to read actually | 15:19 |
| jam | I guess if you are following the issue tracker, the thing you want to read is at the top | 15:19 |
| Jc2k | gour, statik, jam: on Git vs Bzr in GNOME, best read is: | 15:19 |
| Jc2k | http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00064.html | 15:20 |
| abentley | statik, jam: contrats. | 15:20 |
| Jc2k | http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00062.html | 15:20 |
| Jc2k | http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00169.html | 15:20 |
| gour | jam: i had similar (read: serious issues in darcs-1 as well) - that's why i'm here now ;) | 15:22 |
| jam | anyone know how to tell pidgin that you really want your tab back where it was (in the other window)? | 15:23 |
| jam | I guess the best I found was to add another tab, so the tab bar shows... | 15:24 |
| jam | then you can drag it | 15:24 |
| jam | gour: glad to have you :) | 15:26 |
| semslie | thanks for the links Jc2k. I've been looking out for something like that. | 15:27 |
| gour | however, availability of gui tools, good win32 support etc. are some add-ons (useful to my peer devs) why bzr is chosen | 15:27 |
| Jc2k | semslie: the whole thread amused me. | 15:28 |
| Jc2k | semslie: behdad misunderstands bzr-svn very badly and says it cant do stuff it can a lot, for example | 15:30 |
| Jc2k | semslie: behdad also threatens to take his ball in at one point, too | 15:30 |
| semslie | I'm looking forward to reading it. kilner and I have been using bazaar against a subversion repository via bzr-svn for a month or two now so I'd like to compare notes with what I've experienced. | 15:35 |
| semslie | Jc2k: my experience has been good on the whole, with one or two edge cases that confused me but were understandable given the nature of using a dvcs against a centralised one. | 15:37 |
| Verterok | lifeless: hi, sorry for the delay (just 1h :P ) | 15:38 |
| Jc2k | semslie: i'm a big fan of bzr-svn, hence http://bzr-mirror.gnome.org :) | 15:38 |
| beuno | mornin' Verterok | 15:38 |
| Verterok | beuno: g'mornin' | 15:38 |
| vila | hi all | 15:39 |
| vila | yeah for a new project using bzr :) | 15:40 |
| semslie | Jc2k: me too, but I also feel that the whole experience could be even better. bazaar impressed me so much that I'll take crashes against svn with a pinch of salt and work out how to get around them, but it would be nice to see that experience become smoother. | 15:40 |
| beuno | hey vila | 15:42 |
| vila | hi beuno, currently working on bzr-upload :) | 15:42 |
| beuno | vila, oh, very cool | 15:43 |
| beuno | that needs to be made more public ASAP ;) | 15:43 |
| beuno | jelmer even has a deb ready for that as soon as we give him the green light | 15:43 |
| vila | beuno: wow, I need to find some more free time then :) | 15:45 |
| beuno | vila, I haven't lost any data with it, ever. That seems a good enough | 15:46 |
| beuno | symlinks thingie could be patched, and some other tweaks | 15:47 |
| beuno | but most people can use it as-is I think | 15:47 |
| james_w | Jc2k: thanks for the links. I thought one of your posts was the best that I read. | 15:55 |
| Jc2k | james_w: :) which one? | 15:55 |
| vila | beuno: I have a half-working version for a more robust full upload (half-working cause it triggers a bug in bzrlib, or said otherwise, I overused some function), but that gave the hints for a full working one. Once done, I'll address chmod bits | 15:55 |
| james_w | does this work with the tools? Does that? Are we going to have a centralised with offline access model? or a gatekeeper?... <- that one | 15:55 |
| Jc2k | ah :) | 15:56 |
| james_w | good things to be asking, but it didn't seem to have any effect. | 15:56 |
| Jc2k | james_w: for the whole thread behad just seemed to crying "i want git" and not really responding too well to anything that wasnt "i agree" | 15:57 |
| Jc2k | i fear that the DVCS discussion at GUADEC will be similar | 15:57 |
| james_w | yup | 15:57 |
| Pieter | It'll be decided the GNOME-way | 15:58 |
| james_w | it seems like there is a fair chance that it ends up with svn sticking around and then everyone using that as a backend, with some modules going off and doing there own thing if the leaders desire. | 15:58 |
| Pieter | which is "let's wait a few dozen more years" | 15:58 |
| Jc2k | Pieter: i wish GNOME had a BDFL. right now its a free for all at the individual modules level, with seemingly no real goals for the project as a whole. | 16:00 |
| beuno | vila, great, I'll be spying on your LP branch | 16:00 |
| Pilky | statik, jam: congrats on the MySQL announcement | 16:00 |
| Jc2k | plus stuff like, how many canvas libraries do we need? | 16:01 |
| statik | thanks! | 16:01 |
| vila | beuno: ok | 16:01 |
| statik | Pilky: I saw someone was converting BazaarX to work with Git, the cross-pollination is pretty neat :) | 16:01 |
| Pilky | yeah, I'm meant to be talking with him today to see how we're going to manage all of this | 16:02 |
| vila | the more people collaborate, the less they waste energy bashing each other tool :) | 16:02 |
| Pilky | because the idea is that they'll share the majority of the same code | 16:02 |
| Pieter | as long as they don't call it GitX :) | 16:03 |
| Pilky | and the UIs should be almost identical, except for where git and bzr differ | 16:03 |
| Pilky | heh, it's called Gitty | 16:03 |
| Pieter | good | 16:03 |
| Pieter | cause GitX is mine | 16:03 |
| Pilky | heh | 16:03 |
| Pilky | of course the bar has been set now with Versions so having more people working on the same code is going to help quite a lot | 16:04 |
| * vila thinks jam can detect every mispelled 4 letters word beginning with h :-) | 16:06 | |
| Pieter | looks like gitty doesn't do anything yet | 16:06 |
| Pilky | Of course it complicates things quite a bit with regards to hosting the projects | 16:06 |
| Pilky | Pieter: yeah, Colin (the guy who's working on it) couldn't commit to github through his company's firewall yesterday | 16:07 |
| Pilky | it would be nice to try and closely brand BazaarX and Gitty together in the long run | 16:08 |
| Pilky | especially as they're going to be virtually the same app | 16:08 |
| Jc2k | Pilky: stick it in SVN, and use git-svn and bzr-svn :) | 16:09 |
| Pilky | Jc2k: I've considered that, also comes down to how the project will be structured | 16:09 |
| Pieter | I wouldn't work on a git/bazaar gui project that uses svn | 16:10 |
| Jc2k | im sure there are plenty of git people who wouldnt use a git GUI that was hosted in bzr. | 16:11 |
| Pilky | I'd prefer not to, but it's going to be complicated either way | 16:11 |
| Pieter | my git-bzr works perfectly fine for my needs | 16:13 |
| Pieter | i can just do git bzr pull / git bzr push | 16:13 |
| Pieter | http://frim.frim.nl/GitX6.mov btw | 16:13 |
| Pilky | in theory all that would need to happen is references to BZRCore would need to be replaced with GITCore | 16:14 |
| pasky | Pieter: doesn't git log by default hide merges? | 16:14 |
| Pieter | no | 16:14 |
| Pilky | unfortunately there's a few areas where I work around bzr for speed | 16:14 |
| Pilky | Pieter: looks nice | 16:17 |
| Pilky | looks like it only does browsing at the moment | 16:17 |
| Pieter | yes | 16:18 |
| Pilky | I guess Gitty and GitX will appeal to different groups atm, depending on what they want from a GUI | 16:19 |
| Pieter | Vienna:m pieter$ time bzr branch lp:mysql-server/5.0 | 16:19 |
| Pieter | bzr: ERROR: Target directory "5.0" already exists. | 16:19 |
| Pieter | real0m19.882s | 16:19 |
| Pieter | nice how it takes 20 seconds to give that error | 16:19 |
| Pilky | I haven't got branch history planned for BazaarX until 0.5 | 16:19 |
| Pieter | I first want to add multiple branch support / multi repo support.. then look at a gui for committing and perhaps blaming | 16:20 |
| pasky | Pieter: oh, right I was confused | 16:21 |
| Pilky | yeah, we're going from the committing side of things first | 16:21 |
| Pieter | and I want to do some fancy things like a rebase -i frontend | 16:22 |
| Pilky | hmm | 16:22 |
| === gour_ is now known as gour | ||
| Pilky | we've got some interesting stuff planned, for example I want to try and us FSEvents to automatically do bzr mv | 16:23 |
| Pilky | so you can rename a file in an editor, or the finder and BazaarX will detect that and do the bzr mv for you | 16:23 |
| Pieter | ah | 16:23 |
| Pieter | luckily git doesn't need that | 16:23 |
| Pilky | but I believe git doesn't have quite as comprehensive as system for doing moves and renames, correct? | 16:24 |
| LeoNerd | But then doesn't git get very upset if you rename and modify a file at the same time? | 16:24 |
| Pieter | (I thought FSEvents only works on the directory level? so you don't get any info on which file was changed) | 16:24 |
| Pieter | the renaming stuff works ok in most situations | 16:25 |
| Pilky | nope, I believe it works on the file level as well | 16:26 |
| jelmer | Pilky, That seems like something that would be useful to bazaar in general | 16:26 |
| jelmer | Pilky: I.e. as a separate plugin, independent of a particular GUI | 16:26 |
| Pieter | Mercurial has it already | 16:26 |
| Pieter | you can just take that | 16:26 |
| Pilky | remember, it's used for notifying time machine and spotlight for informing them when to update | 16:26 |
| Pilky | jelmer: we may run it as a background process | 16:27 |
| Pieter | Pilky: time machine doesn't use kernel info, and spotlight doesn't use fsevents | 16:27 |
| Pilky | ? | 16:27 |
| Pilky | FSEvents were created for spotlight | 16:27 |
| Pieter | no, they are separate | 16:28 |
| Pilky | they were added in Tiger, but made public in Leopard | 16:28 |
| james_w | Jc2k: from the wiki you may want to remove the claim that bzr has never had a regression. | 16:28 |
| Pieter | fsevents is a userlevel interface that is less powerful, spotlight has its own kernel access | 16:29 |
| Pilky | Pieter: if they don't use FSEvents then what do they use, seems stupid to have 3 separate file system notification systems | 16:29 |
| Pieter | Pilky: yeah, they probably did it because you can't get file notifications with fsevents | 16:29 |
| Pilky | hmm, so it's all the same system, just with different levels of access | 16:32 |
| asabil | has there been any suggestion about changing the bzr branch/pull/push output ? | 16:34 |
| asabil | because the way it is now, it gives the illusion that bzr is very slow | 16:35 |
| Pieter | Pilky: you can use the kernel interface, but you need root for that | 16:37 |
| Pilky | yeah, not ideal | 16:38 |
| Pieter | you could just put it in with the applescript exploit | 16:38 |
| LarstiQ | cyberix: I'll be at EP, if you want to meet up. | 16:41 |
| dato | LarstiQ: not sure if you're making DebConf, but I'm not making it myself | 16:41 |
| dato | LarstiQ: and hi!, of course :) | 16:41 |
| Mez | w00t - best ever function ever | 16:44 |
| Mez | bzr shelve works on svn branches | 16:45 |
| Pilky | Pieter: by the looks of things, using kQueue is going to be the best way to do it | 16:47 |
| LarstiQ | dato: I'm not, alas. Extremadura though, that I should be able to make :) | 16:50 |
| LarstiQ | Mez: cool :) | 16:50 |
| dato | LarstiQ: nice. I should *so* bury in shame if I don't make Extremadura myself ;) | 16:51 |
| LarstiQ | dato: if that happens, I'll come look you up :P | 16:52 |
| dato | *g* | 16:52 |
| Mez | LarstiQ, cept it thinks everything done by svn:keywords is a change | 16:54 |
| jelmer | Hi dato, LarstIQ, Mez | 16:58 |
| jelmer | Mez: that's a known bug unfortunately - bzr needs to support keywords first | 16:58 |
| Mez | jelmer, yeah... and it wont let you only shelve from a single file/dir | 16:59 |
| jelmer | Mez: Hmm, I thought that worked | 17:00 |
| jelmer | Mez: Do you get an error or something? | 17:00 |
| * LarstiQ dines | 17:02 | |
| Mez | jelmer yeah | 17:07 |
| Mez | File "/home/mez/.bazaar/plugins/svn/branch.py", line 106, in unprefix | 17:07 |
| Mez | assert relpath.startswith(self.get_branch_path()) | 17:07 |
| Mez | AssertionError | 17:07 |
| vila | beuno: more robust full upload done, look, test, report, enjoy :) | 17:08 |
| * beuno pulls | 17:09 | |
| jelmer | Mez: Ah, thanks | 17:10 |
| vila | beuno: It should now be possible to upload even if the remote dir is "dirty". bzr-upload will just clear its way. Of course that may be destructive, but that's the point :) | 17:10 |
| Mez | jelmer, hope it helps | 17:11 |
| jelmer | Mez: Any chance you can file a bug? | 17:11 |
| beuno | vila, as in, delete all files unrelated to the tree? | 17:11 |
| Mez | jelmer, am in the middle of a massive merge.. | 17:11 |
| vila | beuno: no, not *that* destructive :) Only the files or dirs that are in the way | 17:11 |
| beuno | vila, can you enlighten me on what "in the way means"? | 17:12 |
| vila | the cases I had in mind was files renamed into dirs and vice-versa. These cases would have triggered weird errors | 17:12 |
| vila | "in the way" == "files or dirs that needs to be deleted because we want to upload dirs or files at the same location" | 17:13 |
| vila | -2s/renamed/changed/ | 17:13 |
| beuno | vila, ah, seems reasonable | 17:13 |
| beuno | very cool | 17:13 |
| vila | symlinks will have to be handled in the same way if/when we want to support them | 17:14 |
| beuno | I may attempt to fix that, although I've been secretly waiting for jelmer to run into that bug enough time for him to attempt to first :p | 17:15 |
| jelmer | I did look into adding support for that | 17:15 |
| jelmer | but gave up when I couldn't find a function to create them in the Transport interface | 17:15 |
| vila | beuno: *Now* I can't imagine a scenario anymore where a full upload will not allow restoring a clean state remotely | 17:16 |
| beuno | vila, so you're happy-ish for more people to start using it? | 17:17 |
| vila | yup | 17:17 |
| beuno | yay! | 17:17 |
| beuno | I'll writeup a blog post/email later on | 17:17 |
| james_w | go team! | 17:18 |
| jelmer | vila/beuno: Time to file that ITP? | 17:18 |
| beuno | jelmer, go! | 17:18 |
| vila | the lack of chmod bits may still bit some people, but that's far less important than getting a remote dir totally screwed up | 17:18 |
| beuno | vila, I have a few branches with work done on bzr-upload, but they are either unfinished, or don't have tests yet, so I'd rather stop pushing more untested code then get that in. Hopefully I'll be able to make some time for it soon | 17:19 |
| vila | which could happen, for example, if two people try to upload at the same time, two branches that have diverged and contain some kind changes | 17:19 |
| beuno | vila, that's what patches are for :) | 17:19 |
| pasky | Has anyone ever made any detailed comparison of patience diff and the classic Meyers diff? Like taking a corpus of commits and comparing the two diff outputs and judging the difference for sensibility? | 17:19 |
| vila | beuno: on that subject, I was already wondering if it's time to have more branches for the plugin so that we can experiment more freely and then merge the official branch when ready | 17:20 |
| pasky | or is there just anecdotal evidence available? | 17:20 |
| vila | beuno: so create your branches and I'll review them | 17:20 |
| vila | jelmer: excuse my ignorance, but was is an ITP ? :) | 17:21 |
| beuno | vila, ok, will clean some of them up. I just want to be able to provide code changes with tests as well | 17:21 |
| james_w | pasky: jam is most likely to know of anything like that, he's done a lot of tweaking. | 17:22 |
| beuno | vila, Intent To Package in Debian. It's basically telling everyone that you're going to be packaging that software | 17:22 |
| vila | beuno: good. On the dry-run option, I've looked at the existing tests and I may able to refactor them so that you can reuse most of them | 17:22 |
| vila | s/may able/may be able/ | 17:22 |
| beuno | vila, ah, that would be cool. I couldn't find a way to do that without duplicating the tests that it affected and pass on the dry-run option | 17:23 |
| vila | beuno: the idea is to separate the setup/exercise/verify/teardown parts. setup and teardown are already down, exercise and verify should be separated so that you can reuse the exercise part, do your own upload (with --dry-run option) and do your own verify | 17:25 |
| vila | s/already down/already done/ | 17:25 |
| vila | and yes, I'd like to be able to amend my commits like I fix my typos in IRC :) | 17:26 |
| gour | like darcs' amend-record? | 17:26 |
| fullermd | `bzr sed` ;) | 17:27 |
| beuno | haha | 17:28 |
| beuno | vila, that sounds perfect. Like always, you rock | 17:28 |
| * gour thinks statik rocks too bringing demanding customers to bzr | 17:29 | |
| statik | thanks :) | 17:29 |
| pasky | james_w: thanks for the hint ;) | 17:31 |
| pasky | i'll ask when i see him around | 17:31 |
| === kiko is now known as kiko-fud | ||
| awilkins | jam: Ping? | 17:34 |
| bkor | has someone seen http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html ? the table is hard to read, it is about bzr using 2.8 times more storage than git | 17:34 |
| jelmer | I think that's from Pieter in this channel | 17:42 |
| Pieter | yeah | 17:51 |
| jelmer | statik: Congrats! Really awesome to see MySQL aboard | 17:57 |
| cyberix | LarstiQ: sure, why not | 18:00 |
| === kiko-fud is now known as kiko | ||
| engie | Hi. Has anyone come across systems for avoiding stale comments by associating them with a section of the file & a revision, then getting the VCS to flag them up on commit if there are any changes in that section? | 18:09 |
| bkor | Pieter: did you get feedback from bzr devs why it is so big? | 18:09 |
| jelmer | I think we need to remove the comments indicating we're smallest from that wiki page | 18:10 |
| jelmer | or at least more clearly indicate they're not very representative | 18:11 |
| Jc2k | NO | 18:11 |
| jelmer | Jc2k, ? | 18:11 |
| Jc2k | i have git, svn and bzr for all GNOME. for some modules bzr gets caned badly, but i've also got some where bzr canes git. | 18:11 |
| Jc2k | the no was a protest at my laggy wifi connection on this train :p | 18:12 |
| Jc2k | i will post figures when i have verified all things are fair | 18:12 |
| jelmer | ah, ok | 18:12 |
| jelmer | Actually looks like there already is a comment up there | 18:13 |
| jelmer | Jc2k, it would be interesting to see in what situations one of the two is better | 18:13 |
| gour | ...and why | 18:14 |
| gour | :-) | 18:14 |
| Jc2k | i seem to remember gnome-games making git-svn suffer | 18:14 |
| jelmer | beuno: Are you a DD? | 18:21 |
| beuno | jelmer, no. Do you need a sponsor? | 18:22 |
| jelmer | beuno, yep | 18:22 |
| beuno | I can get you one :) | 18:22 |
| * beuno goes fetch a DD | 18:22 | |
| beuno | hrm, out for lunch | 18:23 |
| jelmer | no hurries | 18:23 |
| jelmer | bzr builddeb http://bzr.debian.org/pkg-bazaar/bzr-builddeb/unstable/ | 18:23 |
| jelmer | will build the package | 18:23 |
| beuno | alright, I'll drag her in here as soon as she's back | 18:24 |
| jelmer | thanks | 18:24 |
| beuno | cool, thanks jelmer :) | 18:24 |
| jelmer | I'll be away tonight, will be back in ~5 hrs | 18:24 |
| beuno | jelmer, np, that will give her some time to review | 18:27 |
| Pieter | Jc2k: but, you didn't repack those repositories at all | 18:28 |
| Pieter | or, without any --window flag | 18:29 |
| Pieter | bkor: I think general consensus was that bzr can still do a lot in generating better packs | 18:29 |
| Ng | is it just me or did the progress bar on branching code go away? | 18:39 |
| beuno | mwhudson__, while working on the new theme I found a few more issues with my clean url branch. So I'll delay that a bit more until I solve those too | 18:46 |
| === mwhudson__ is now known as mwhudson | ||
| awilkins | jam: Ping? | 19:26 |
| pygi | hey strangy, what's up?:) | 19:26 |
| strangy | just bzr cloned my subversion repo | 19:26 |
| strangy | :) | 19:26 |
| strangy | from assembly | 19:26 |
| strangy | assembla | 19:27 |
| strangy | pygi: and you? | 19:29 |
| pygi | strangy, working on some articles =) | 19:29 |
| Jc2k | Pieter: i did git --bare gc --prune --aggressive | 19:31 |
| engie | Hi. Is there a recommended way to abort a commit from a pre_commit hook in a plugin? | 19:31 |
| mwhudson | beuno: what issues? | 19:32 |
| Jc2k | Pieter: am i expected to know how gc works sufficiently to correctly balance alien arguments like --window and --depth to suit each one of the 520 modules? | 19:32 |
| beuno | mwhudson, with revision comparison | 19:32 |
| beuno | in /revision | 19:32 |
| beuno | it uses revid to compare | 19:32 |
| beuno | and we're using revnos now | 19:32 |
| mwhudson | beuno: did you try _my_ zpt.cleaner_urls branch? | 19:32 |
| mwhudson | i think i fixed that | 19:33 |
| beuno | mwhudson, ah, I merged that into my branch, but it didn't travel all the way into my new theme one because it encountered 16 conflicts, which made me revert :) | 19:33 |
| beuno | cool then | 19:33 |
| mwhudson | heh | 19:33 |
| beuno | I'll merge those in and fix the remaining issue with next/prev | 19:34 |
| Jc2k | Pieter: and your still missing the point that we can learn from the differences between an out of the box git mirror and an out of the box bzr mirror and fine cases where both projects can be optimized | 19:34 |
| Jc2k | Pieter: i presume the reason that git doesnt pack more agressively by default is for speed? | 19:34 |
| mwhudson | beuno: paper over the issue, i think you mean :) | 19:34 |
| Jc2k | Pieter: also, how often am i meant to set the git gc cronjob to run? | 19:35 |
| beuno | mwhudson, paper over? | 19:36 |
| mwhudson | beuno: sorry, just as i said in my mail, navigation is kind of messed up in loggerhead anyway | 19:36 |
| mwhudson | i'm not expecting you to fix that :) | 19:36 |
| beuno | ah, heh | 19:37 |
| beuno | right, I wasn't familiar with the expression | 19:37 |
| mwhudson | oh, sorry | 19:37 |
| beuno | so, yes, patch it up the best way possible until we do something sensible with that | 19:38 |
| beuno | btw, this may seem like an odd question | 19:39 |
| beuno | you wouldn't happen to know a revision in the bzr tree that has multiple merge points (merged from in LH), would you? | 19:40 |
| mwhudson | >2 parents? | 19:40 |
| mwhudson | there are a couple, i think, i went looking for them a while back | 19:40 |
| Lo-lan-do | G'day all | 19:41 |
| beuno | I'd be happy with 2. I want to test something, but I went back ~20 pages and couldn't find any | 19:41 |
| Lo-lan-do | Is there a mostly stable web interface for bzr? | 19:42 |
| Lo-lan-do | I hear about loggerhead, but I don't see much activity on the webpage, and it's not in Debian... | 19:42 |
| Lo-lan-do | (Or Ubuntu, I guess) | 19:43 |
| beuno | Lo-lan-do, me and mwhudson have been working on it like crazy the past month or so | 19:43 |
| Lo-lan-do | Yay :-) | 19:44 |
| beuno | Lo-lan-do, https://edge.launchpad.net/loggerhead | 19:44 |
| beuno | get trunk, it's the latest and greatest | 19:44 |
| mwhudson | beuno: all mainline commits have 2 parents :) | 19:44 |
| beuno | mwhudson, not according to LH: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes | 19:45 |
| * mwhudson gets confused by graph iter_ancestry | 19:45 | |
| mwhudson | beuno: no, really: each mainline commit has two parents: the previous mainline commit and the revision being merged | 19:46 |
| Lo-lan-do | beuno: Is there an online demo somewhere? | 19:46 |
| beuno | Lo-lan-do, not of the current trunk, but, well, Launchpad runs it | 19:46 |
| mwhudson | Lo-lan-do: http://bzr-mirror.gnome.org:9876/mango/trunk/ | 19:47 |
| beuno | ah | 19:47 |
| beuno | it seems we do :) | 19:47 |
| beuno | mwhudson, is that running your wsgi branch? | 19:47 |
| mwhudson | beuno: yes | 19:47 |
| Lo-lan-do | mwhudson: Tha,ks | 19:47 |
| beuno | mwhudson, very cool. I should merge that into one of the branches I'm working on so I can start punching wholes in it | 19:48 |
| Pieter | Jc2k: you're expected to know that if you're converting a 6GB repo, yes | 19:50 |
| === mw is now known as mw|food | ||
| beuno | mwhudson, but we don't show both parents in LH, do we? | 19:50 |
| Pieter | Jc2k: after that, you should never have to run gc --agressive again | 19:50 |
| beuno | mwhudson, right, well, LH doesn't show it | 19:50 |
| mwhudson | well, the left hand parent is shown in an implicit way i guess | 19:50 |
| Pieter | Jc2k: and git gc will be performed automatically, you don't need to do that yourself | 19:50 |
| db-keen | I've made several unrelated changes, how can I hold back, and not commit modified versions of certain files? | 19:51 |
| engie | db-keen: Have you tried the bzr shelve command? | 19:51 |
| beuno | mwhudson, ok. But we have a loop for "merged in" and "merged from", so I was wondering in what cases that actually loops | 19:51 |
| mwhudson | db-keen: yes, bzr ci path will commit only changes under path/ | 19:51 |
| mwhudson | beuno: oh right | 19:52 |
| mwhudson | hang on, i can give you a list of revids | 19:52 |
| Pieter | Jc2k: you can just take a window of 100 for everything if you want | 19:52 |
| db-keen | engine: that looks like what I want, thanks! | 19:52 |
| Jc2k | Pieter: but git packed automatically as it imported, so why is it so important to pack it again? | 19:52 |
| mwhudson | beuno: http://pastebin.ubuntu.com/21464/ | 19:53 |
| Pieter | Jc2k: because the packs that git-svn produces are suboptimal | 19:53 |
| mwhudson | (14 parents??) | 19:53 |
| Jc2k | Pieter: is that considered a bug that will be fixed? | 19:53 |
| Pieter | no | 19:53 |
| beuno | mwhudson, that's it, thanks :) | 19:53 |
| Pieter | if it would repack every time in between, it would cost a lot of time | 19:54 |
| Pieter | so it's better to just do it once at the end | 19:54 |
| mwhudson | beuno: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/robertc@robertcollins.net-20060503100143-94b0e2f638dbbb8d seems a good example | 19:55 |
| mwhudson | (but you have to use merge --force to get this to happen i think so it's going to be rare) | 19:55 |
| beuno | mwhudson, Please try again - Sorry, there was a problem connecting to the Launchpad server. | 19:56 |
| mwhudson | odd | 19:56 |
| beuno | (nicer errors) | 19:56 |
| mwhudson | it worked for me | 19:56 |
| beuno | there, refresh 3 or 4 times and it got it | 19:56 |
| mwhudson | :/ | 19:56 |
| Jc2k | Pieter: as im mirroring, over time would the backs because sub optimal again? | 19:56 |
| Jc2k | *packs | 19:56 |
| beuno | mwhudson, when are you deploying zpt on LP? | 19:56 |
| Jc2k | (thanks for answering me btw, the git mirror has been a pain so far) | 19:57 |
| mwhudson | beuno: should be next wednesday | 19:57 |
| Jc2k | (and no one in GNOME seems to know the right way to do things) | 19:57 |
| beuno | mwhudson, gather some before-statistics, so we can compare :) | 19:57 |
| mwhudson | heh, probably a good idea | 19:58 |
| beuno | ok, cool. Multiple parents doesn't break the new theme | 19:58 |
| Pieter | Jc2k: once the pack has been optimized, subsequent normal git-gc's will behave properly | 20:00 |
| Pieter | Jc2k: you just need to do this once | 20:00 |
| Jc2k | cool | 20:00 |
| Lo-lan-do | Hm. Seems like loggerhead isn't as straightforward as I had expected. | 20:03 |
| Lo-lan-do | I guess I'll wait for someone to package it (hi jelmer :-) | 20:04 |
| blueyed | Hi. I have a bzr branch, which mirrors a CVS repo (using tailor). I've committed a previous rev. from a derived branch to the CVS branch and when the change came back, it caused a conflict with a newly added file ("conflict adding file ..."). That shouldn't happen, or is this expected? | 20:04 |
| Jc2k | Lo-lan-do: hehe, it was really easy for me ;) | 20:05 |
| jam | statik: this-week time | 20:05 |
| statik | i'll call you now | 20:05 |
| Lo-lan-do | Jc2k: I'm getting errors about a "peak" module, even though I have the python-decoratortools package installed | 20:05 |
| beuno | Lo-lan-do, you branched trunk? | 20:06 |
| beuno | you need python-sqlite, python-simpletal | 20:07 |
| beuno | and turbogears | 20:07 |
| beuno | python-turbogears to be precise | 20:07 |
| Lo-lan-do | Yup, I have all of these. | 20:09 |
| Lo-lan-do | Branched from http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/ | 20:09 |
| beuno | Lo-lan-do, can you paste the full traceback? | 20:09 |
| Lo-lan-do | http://pastebin.com/d603a4b67 | 20:10 |
| beuno | Lo-lan-do, try installin python-pkg-resources | 20:11 |
| Lo-lan-do | Already there | 20:11 |
| mwhudson | Lo-lan-do: you could try lp:~mwhudson/loggerhead/wsgi-ify | 20:11 |
| Jc2k | Lo-lan-do: i am using wsgi-ify, which is why i said it was really easy :) | 20:12 |
| * Lo-lan-do installs python-pastewebkit | 20:14 | |
| mwhudson | python-paste should suffice | 20:14 |
| mwhudson | (at least that's the package name in hardy) | 20:14 |
| Jc2k | mwhudson: python-pastedeploy is needed too | 20:15 |
| mwhudson | Jc2k: is it? | 20:15 |
| Jc2k | on etch, yes | 20:15 |
| mwhudson | hmm | 20:15 |
| Lo-lan-do | python-paste isn't enough, apparently (on sid) | 20:15 |
| mwhudson | what fails without it? | 20:15 |
| Jc2k | mwhudson: i can remove it and get you a traceback if you like? | 20:16 |
| Lo-lan-do | ImportError: No module named paste | 20:16 |
| beuno | Lo-lan-do, right, python-paste is needed :) | 20:16 |
| Lo-lan-do | Now I get http://pastebin.com/df82c6d0 | 20:16 |
| Lo-lan-do | beuno: That was with python-paste, but without python-pastewebkit | 20:16 |
| mwhudson | that's strange | 20:16 |
| mwhudson | Lo-lan-do: maybe try putting | 20:17 |
| mwhudson | import logging.handlers | 20:17 |
| mwhudson | at the top of start-loggerhead.py ? | 20:17 |
| mwhudson | Lo-lan-do: but also try using the new serve-branches.py script | 20:17 |
| Lo-lan-do | Adding the import works | 20:18 |
| beuno | mwhudson, I saw you started work for a bzr plugin :) | 20:18 |
| mwhudson | beuno: yeah, it's pretty brainless | 20:18 |
| mwhudson | Lo-lan-do: ah, ok | 20:18 |
| * mwhudson adds that to his branch | 20:18 | |
| mwhudson | Lo-lan-do: but you may want to use serve-branches.py anyway :) | 20:19 |
| beuno | mwhudson, thoughts on *just* showing side by side diffs in the new theme? Currently we process and write out the diffs twice. Once for side by side, and once for unified. Would doing that get me killed? | 20:20 |
| Lo-lan-do | Hm. For some reason, Iceweasel displays the XML as is. | 20:20 |
| mwhudson | beuno: not by me | 20:20 |
| mwhudson | Lo-lan-do: oh hang on | 20:21 |
| === mw|food is now known as mw | ||
| mwhudson | i think i forgot to push a fix | 20:21 |
| beuno | mwhudson, we can re-add that option later on, with my ajax branch, since we will request only what the user wants | 20:21 |
| mwhudson | beuno: though i would if picking the unified view would make more sense | 20:21 |
| mwhudson | the side-by-side view tends to extreme wideness | 20:22 |
| mwhudson | Lo-lan-do: please pull again, you want revision 204 | 20:22 |
| beuno | well, I'm a vimdiff man, so I prefer side by side, no matter the width. I can leave both, just thought we could make the transition with just one, and then re-add it later on with ajax-goodness | 20:24 |
| Lo-lan-do | mwhudson: Better, thanks. | 20:24 |
| mwhudson | beuno: i don't have a strong opinion | 20:25 |
| Lo-lan-do | Although I suppose I'm still going to whine: could you only regenerate cached data if no revisions have been added? | 20:25 |
| mwhudson | beuno: only displaying one does make a lot of sense i think | 20:25 |
| mwhudson | Lo-lan-do: pardon? | 20:25 |
| Lo-lan-do | Otherwise it can take quite some time between startup and operational status | 20:25 |
| mwhudson | Lo-lan-do: oh i see | 20:25 |
| mwhudson | Lo-lan-do: no | 20:25 |
| mwhudson | basically | 20:26 |
| mwhudson | loggerhead needs to merge sort the revision graph when it starts up | 20:26 |
| mwhudson | i suppose it could cache this somewhere... | 20:26 |
| Lo-lan-do | That's going to be a problem if I want to integrate it into a GForge plugin... | 20:26 |
| mwhudson | why would you be restarting it frequently? | 20:27 |
| Lo-lan-do | Even if it only took one second per branch, there can be hundreds or thousands of branches... | 20:27 |
| Lo-lan-do | To take new project and branches into account? | 20:27 |
| mwhudson | you don't need to restart to do that | 20:28 |
| Lo-lan-do | Unless there's a way to run loggerhead as a CGI, but then startup time is even more important. | 20:28 |
| mwhudson | well, you do if you use a config file, but that's a bad idea :) | 20:29 |
| mwhudson | Lo-lan-do: are you auto generating a loggerhead.conf at the moment? | 20:29 |
| Lo-lan-do | At the moment I'm getting my first instalce of loggerhead to run so I can play with it, that's all :-) | 20:29 |
| mwhudson | ok | 20:29 |
| mwhudson | well, if you use the serve-branches.py version, it will pick up new branches as they are added just fine | 20:30 |
| Lo-lan-do | But I'm all in favour of a daemon that needs no restarts, if one can add/remove branches to it. | 20:30 |
| mwhudson | but it's bound to the file system | 20:30 |
| Lo-lan-do | fam or something? | 20:31 |
| mwhudson | if the information about what branches you have is somewhere else, you'll need to write some (simple) code | 20:31 |
| mwhudson | Lo-lan-do: hah, no, nothing that fancy | 20:31 |
| mwhudson | it's lazy, it doesn't create the branch views until the first view of a branch | 20:31 |
| mwhudson | (which does mean the first view of a branch can be slow) | 20:32 |
| Lo-lan-do | Okay, so no list of existing branches? | 20:32 |
| mwhudson | i think bzr needs to change a fair bit before we can get away from that, sadly | 20:32 |
| mwhudson | Lo-lan-do: right | 20:32 |
| mwhudson | Lo-lan-do: it's what's running on http://bzr-mirror.gnome.org:9876/ | 20:32 |
| Lo-lan-do | Okay. I suppose I'll generate links with "bzr branches" in the background. | 20:33 |
| mwhudson | that is just serve-branches.py running from the directory that contains all the repositories | 20:33 |
| Lo-lan-do | Oh, hey, an f-spot branch. I guess I can abandon mine :-) | 20:34 |
| * mwhudson goes to to breakfast and stuff | 20:34 | |
| abentley | beuno: Showing only side-by-side diffs will get you killed by me. | 20:39 |
| abentley | Having to always switch it is annoying enough. | 20:39 |
| beuno | abentley, even if I bring it back in the next release? | 20:40 |
| beuno | it's stupid how it's done now, and wastes ton of resources | 20:40 |
| abentley | beuno: So wouldn't it make more sense to stop it wasting resources? | 20:41 |
| beuno | abentley, yes. I have a branch for that, but it's too big of a change to land it this release | 20:42 |
| abentley | You'll waste more resources with ajax. | 20:42 |
| beuno | and why is that? | 20:42 |
| abentley | Because the expensive part is performing the sequence matching, and that only needs to be done once. | 20:42 |
| abentley | But if you ajaxify it, you | 20:42 |
| abentley | will throw away the sequence. | 20:43 |
| === sii` is now known as sii | ||
| beuno | abentley, well, today, we generate each diff twice per file changed per page. With ajax, we'll only generate it once, and when you actually want to see the diff to that file | 20:43 |
| beuno | so, I think we'll get a big win overall, even by doing sequence matching twice | 20:44 |
| abentley | The expensive part of generating a diff is the sequence matching. | 20:44 |
| mwhudson | abentley: no, it's rendering all that html :) | 20:45 |
| abentley | And avoiding retrieving the texts twice doesn't hurt either. | 20:45 |
| beuno | right, bzr is not an issue at all here | 20:45 |
| mwhudson | the actual getting the diff out of bzr is not the problem today in loggerhead | 20:45 |
| * mwhudson really goes to have breakfast now | 20:45 | |
| abentley | mwhudson: Diff generation is O(n^2). Is generating HTML? | 20:45 |
| beuno | 3sec to generate a 30k line diff, 30sec to make it HTML | 20:45 |
| Lo-lan-do | mwhudson: What if a branch disappears? Will serve-branches.py remove it from its cache and the list? | 20:45 |
| beuno | abentley, ^ | 20:46 |
| abentley | beuno: ^ | 20:46 |
| beuno | heh, I don't follow :) | 20:46 |
| beuno | you're talking about the cost of generating in bzr, right? | 20:47 |
| abentley | HTML generation ought to scale linearly. File diffing scales with the square of the number of lines. | 20:47 |
| abentley | So in the worst case, File diffing will always be slower. | 20:48 |
| beuno | I understand that theoretically, but, in practice, in out big-case scenario (36k line diff), bzr takes 3 seconds to generate it, and it takes us over 30 seconds to make that HTML | 20:49 |
| abentley | beuno: This is with simpletal? | 20:50 |
| beuno | abentley, yes | 20:50 |
| abentley | How is the HTML being generated? | 20:50 |
| beuno | it's 1.40m with KID | 20:50 |
| beuno | abentley, mapping the diff object generated by LH with the template | 20:51 |
| abentley | It sounds like taking a more direct approach would be appropriate. | 20:52 |
| beuno | I'm working on the new theme now, where I'm trying to improve that | 20:52 |
| beuno | abentley, direct as in not using a template? | 20:52 |
| abentley | beuno: Using a template only for the icing, using list.append(string) for generating the HTML. | 20:53 |
| mwhudson | Lo-lan-do: the listing is always done with os.listdir(), so yes | 20:53 |
| mwhudson | Lo-lan-do: it will stay in the cache (currently, at least, this much would be fixable) | 20:54 |
| Lo-lan-do | Hmm. That sounds quite interesting. | 20:54 |
| engie | Hi. What's the best way to tell which of two revision numbers (as strings) is the latest? | 20:54 |
| beuno | yes, that's something I'd like to try eventually, or use a non-xml based templating engine for those bits. But, well, we have bigger problems at the moment, so we're trying to get those out of the eay first | 20:54 |
| Lo-lan-do | Surely the cache expires after some time, right? :-) | 20:54 |
| mwhudson | engie: you can't | 20:54 |
| mwhudson | Lo-lan-do: nope! | 20:54 |
| mwhudson | Lo-lan-do: this is probably not ideal | 20:55 |
| mwhudson | engie: in general | 20:55 |
| abentley | engie: You can only do that when the revnos are in the same branch and have no dots. | 20:55 |
| engie | mwhudson, abentley: OK, thanks | 20:55 |
| abentley | Then, the larger number is more recent. | 20:55 |
| komputes | hey guys, I have a project I'm working on, but every time i pull all the files that were executable loose the executable bit. | 20:56 |
| komputes | which means every time i pull it I have to chmod u+x those files. does anyone know why this is happening, how to circumvent this without ignoring the file all together. | 20:57 |
| mwhudson | komputes: well, that shouldn't be happening | 20:58 |
| komputes | mwhudson: I doubt that one of the other project members are playing a trick on me | 20:59 |
| mwhudson | but bzr does track the execute bit | 20:59 |
| jam | james_w: Elliot mentioned that you had a screencast, is that something I can link publicly for "this week" ? | 21:00 |
| komputes | mwhudson: does the fact that ownership of the file changes from user to user have anything to do with the error i'm having? | 21:00 |
| statik | jam: http://www.theregister.co.uk/2008/06/19/mysql_dumps_bitkeeper/ | 21:01 |
| komputes | statik: very nice ;) | 21:02 |
| Lo-lan-do | mwhudson: Is all the caching in serve-branches.py done in memory? | 21:04 |
| mwhudson | Lo-lan-do: not all of it, but a fair chunk yeah | 21:05 |
| mwhudson | memory usage has been a bit of a problem with loggerhead, but so far the blame's more been on the rendering than this caching | 21:05 |
| Lo-lan-do | Hmm. There's definitely going to be problems with that on a forge. | 21:06 |
| mwhudson | well it's a problem on launchpad too, so we're actively working on it :) | 21:06 |
| Lo-lan-do | Glad to hear it :-) | 21:08 |
| Lo-lan-do | Also, the RSS/atom link gives me Internal Server Error. | 21:09 |
| Lo-lan-do | But apart from that, I'm quite impressed, and I'm eager to see it stabilised and deployable :-) | 21:10 |
| awilkins | Verterok: Aha, you are here | 21:10 |
| awilkins | How's that xmlrpc stuff going? Want an enthusiatic dogfooder? | 21:10 |
| mwhudson | Lo-lan-do: the atom feed i fixed just now | 21:10 |
| Lo-lan-do | mwhudson: http://pastebin.com/d1e6721d0 for the error | 21:10 |
| mwhudson | Lo-lan-do: yeah, that one ;) | 21:10 |
| mwhudson | pull again | 21:10 |
| Lo-lan-do | No revisions to pull. | 21:11 |
| mwhudson | darnit | 21:11 |
| mwhudson | i hadn't pushed it, pushing now... | 21:11 |
| Verterok | awilkins: Hi :) | 21:11 |
| Verterok | awilkins: it's going quite good, I just implemented error reporting in xml :D | 21:12 |
| Lo-lan-do | Yay, it works :-) | 21:13 |
| awilkins | Verterok: My users are running into the lethargic performance of the plugin ; if it's stable enough, I'll take an order of 6 to go .... | 21:13 |
| awilkins | Verterok: Well, I'll try it out on their data, and if it blows up, I'll try to fix it. | 21:14 |
| Verterok | awilkins: I'm using it in a daily basis (dogfooding, as you said) | 21:14 |
| awilkins | Verterok: Sounds good - is the performance up? Is the XMLRPC a socket-based server? | 21:15 |
| Lo-lan-do | mwhudson: Also, a link to go "up" one directory would be welcome. | 21:15 |
| awilkins | Verterok: More to the point, are there public branches :-) | 21:15 |
| === dpm_ is now known as dpm | ||
| mwhudson | Lo-lan-do: hm, good idea | 21:16 |
| mwhudson | Lo-lan-do: file a bug? :) | 21:16 |
| Verterok | awilkins: regarding performance, the bzr-java-client testsuite runs in aprox 45 sec. against the CLI ~4min :D | 21:16 |
| Verterok | the current server is a extension of the python SimpleXMLRPCServer | 21:16 |
| Verterok | awilkins: yes, there are public branches... | 21:17 |
| awilkins | Verterok: I bet the differential on Windows is even greater ; it doesn't like to start processes. | 21:17 |
| awilkins | Verterok: Are they on lp? | 21:17 |
| Verterok | awilkins: I didn't test it on windows yet, so your help is more than welcome :) | 21:17 |
| Verterok | awilkins: should be on lp...let me check | 21:18 |
| Verterok | awilkins: oops, I keep pushing to my server, I'll push the xmlrpc branch to lp in a sec. | 21:18 |
| === kiko is now known as kiko-afk | ||
| Verterok | awilkins: I must go for 30min, I'll push as soon I finish this | 21:19 |
| awilkins | Roger roger | 21:19 |
| * Verterok heads to a boring meeting | 21:21 | |
| Lo-lan-do | mwhudson: http://pastebin.com/d21742d3 | 21:23 |
| mwhudson | Lo-lan-do: i'm not sure something so simple will work in all cases | 21:24 |
| mwhudson | Lo-lan-do: maybe it should, though! | 21:24 |
| === yacc_ is now known as yacc | ||
| Lo-lan-do | Seems to work here, although only when in a branch. I can't go up to /gforge/ if I'm in /gforge/patched/ for instance (the branch is at /gforge/patched/foo/) | 21:26 |
| Lo-lan-do | http://pastebin.com/d769c9742 fixes that :-) | 21:31 |
| Lo-lan-do | (Proof of concept, needs tuning, and so on) | 21:31 |
| aldolat | hi there! :) | 21:34 |
| Lo-lan-do | mwhudson: http://pastebin.com/d2e6819e4 and I'll stop bugging you about it :-) | 21:35 |
| aldolat | can I delete a project of mine in LP? | 21:35 |
| strangy | aldolat: no .. you must make a ticket for that | 21:36 |
| strangy | and that annoys me | 21:37 |
| aldolat | this is not good... an admin of a project should have the possibility to do that | 21:38 |
| aldolat | imho :) | 21:38 |
| strangy | i agree but in this case it does not have that permission | 21:39 |
| aldolat | clear & simple :D | 21:39 |
| aldolat | thx. bye! ;) | 21:42 |
| engie | Is there a command that tells me what the revision number would become if I committed right now? | 21:52 |
| beuno | engie, I suppose bzr revno + 1 | 21:53 |
| beuno | (not a command really) | 21:53 |
| engie | OK, thanks | 21:53 |
| james_w | hi jam. I'd prefer not to link it publicly from it's current location. Could we defer it for a week? | 21:56 |
| Verterok | awilkins: still around? | 21:56 |
| engie | Is there a recommended way to abort a commit from a pre_commit hook in a plugin? | 21:57 |
| engie | At the moment I throw an uncaught exception and it's pretty messy | 21:58 |
| engie | This is to do some code sanity checking before committing | 21:58 |
| lifeless | morning everyone | 21:59 |
| vila | strangy: and how about *renaming* a project ? For hysterical raisins the webdav plugin is called bzr.webdav, I'd prefer bzr-webdav.. | 21:59 |
| vila | hi lifeless | 21:59 |
| Verterok | mornin' lifeless | 21:59 |
| mwhudson | engie: i think raising an exception is the way | 22:00 |
| mwhudson | if you raise a subclass of BzrCommandError (i think it's that one) the message wll be displayed nicely | 22:00 |
| engie | mwhudson: OK, I'll grep for that and have a go | 22:01 |
| strangy | vila: i don't know ... i created a test project on launchpad just to test it .. and then i could not delete it, instead i had to make a ticket | 22:01 |
| strangy | vila: that is all i know ... | 22:01 |
| vila | strangy: ok, thks | 22:01 |
| awilkins | Verterok: Yes, just lurking intermittently | 22:06 |
| Verterok | awilkins: ok, I just pushed to lp both branches xmloutput+xmlrpc and java-client+xmlrpc | 22:07 |
| Verterok | awilkins: https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc | 22:07 |
| Verterok | and https://code.launchpad.net/~guillo.gonzo/bzr-eclipse/java-client-xmlrpc | 22:07 |
| Verterok | awilkins: I'm going to create the bzr-java-client project, so we can work on this as the "bzr-java team" :) | 22:08 |
| statik | james_w: have you considered or tried uploading your screencast to archive.org? | 22:10 |
| statik | i've never tried with video | 22:10 |
| james_w | hi statik, no, but I saw a recommendation that it could be good idea. | 22:11 |
| awilkins | Verterok: Go bzr-java team :-) | 22:11 |
| james_w | I also considered ShowMeDo. | 22:11 |
| * awilkins goes out to pcik capes | 22:11 | |
| james_w | statik: had any luck creating any? | 22:11 |
| Verterok | awilkins: go team! :D | 22:12 |
| statik | awilkins: are you working on netbeans or eclipse? | 22:12 |
| awilkins | statik: Eclipse (3.2) | 22:13 |
| statik | awesome | 22:13 |
| awilkins | Blarrgh, ate too many jelly beans and have a serious sugar headache | 22:14 |
| lifeless | abentley: I'd love a get_mpdiffs that included deletes | 22:14 |
| abentley | lifeless: You mean actually including the deleted text? | 22:15 |
| lifeless | yes | 22:15 |
| lifeless | like NewText | 22:15 |
| lifeless | but GoneText | 22:15 |
| lifeless | for a couple of use cases; the immediate one is to index it | 22:16 |
| abentley | Well, I think it could be arranged. The text builder would ignore it, of course. | 22:16 |
| lifeless | but annotate has this limitation of being hard to identify deleted lines with it | 22:16 |
| Verterok | statik: there some folks working on IDEA, and I think a Netbeans related mail reached the list a few weeks ago | 22:17 |
| abentley | lifeless: For a multi-parent diff, mpdiff is kinda arbitrary about which parent it assigns lines to. | 22:17 |
| lifeless | abentley: re loggerhead speed; we have a C differ, and bzr's core has been hammered on for speed - template engines may have had less detailed work done on them | 22:17 |
| lifeless | abentley: for my index needs thats fine, I don't care about ParentText, only New + Gone | 22:18 |
| lifeless | (and New is all I can get today, I was just speculating about moving to using mpdiffs and this seemed a useful dicussion to have | 22:18 |
| abentley | I think it would be fine, as long as it was optional. | 22:19 |
| lifeless | beuno: is there new bling to peek at? | 22:20 |
| mwhudson | beuno: ping | 22:25 |
| beuno | lifeless, I've got the javascript for it done, need to integrate it into LH, which will be in a few hours when I finish cursing with the new theme | 22:25 |
| beuno | mwhudson, pong | 22:25 |
| lifeless | beuno: awesome! | 22:25 |
| mwhudson | beuno: ok, still working on theme stuff then, that's what i was going to ask :) | 22:25 |
| mwhudson | beuno: i think i may try finishing off zpt.cleaner_urls then | 22:25 |
| mwhudson | beuno: as i really really really want to merge it and wsgi-ify today | 22:26 |
| beuno | mwhudson, yes. I'm working on the diff view, which is quite complicated to get right | 22:26 |
| mwhudson | beuno: i can believe that, and it's not something i can help with | 22:26 |
| beuno | mwhudson, oh, cool. If you could, that would be great. If not, I'll do that after this | 22:26 |
| mwhudson | beuno: whereas i think i can fix up the urls just fine | 22:26 |
| mwhudson | if with a bit of cursing | 22:26 |
| beuno | mwhudson, perfect. I've got 2 gfx guys sitting here hearing me curse, and proposing new ways to structure the HTML every 20 minutes :) | 22:27 |
| mwhudson | :) | 22:27 |
| beuno | I have a few ideas on how to improve the diff generation code (LH's, not bzr's), but it will need a few days work, so I'm deferring that for later on | 22:28 |
| mwhudson | beuno: if it helps at all, i seriously recommend stealing stuff wholesale from trac's diff view | 22:28 |
| mwhudson | beuno: if that means we lose side-by-side for now, *shrug* | 22:28 |
| mwhudson | (imo) | 22:28 |
| jam | james_w: that's fine, he just commented on it in this_week, and I thought I could link it, but we can link it later | 22:28 |
| beuno | mwhudson, yes, the trac is great for unified diff, but I think more people will scream at us if we loose side-by-side than with unified. Of course, eventually we'll have both | 22:30 |
| beuno | mwhudson, emailed you what the current diff looks like | 22:36 |
| mwhudson | beuno: the "<< previous" looks funny | 22:40 |
| mwhudson | beuno: but it looks fine | 22:40 |
| beuno | mwhudson, yes, I'm not going to show a previous if there is none, so I removed the CSS bit, which made it ugly looking :) | 22:41 |
| mwhudson | ok :) | 22:41 |
| beuno | I was trying to dump the diff text directly without having to go line by line, to speed it up, but it's going to be impossible without changing large amounts of code | 22:43 |
| beuno | so I'm back to doing it with the line-by-line approach | 22:43 |
| Verterok | awilkins: I forgot to mention, the xmlrpc java-client dependencies are available at: http://guille.beuno.com.ar/maven-repo/ | 22:44 |
| mwhudson | fair enough for now | 22:44 |
| mwhudson | i agree that it would be really good to change this though | 22:44 |
| beuno | mwhudson, FWIW I'm getting a lot of those LP timeouts on LH | 22:49 |
| === mario__ is now known as pygi | ||
| * mwhudson takes a peek at the machine | 22:49 | |
| beuno | I'm hammering http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/bialix@ukr.net-20070922162037-d1ym5gbli9utowto mostly, if it helps | 22:51 |
| beuno | (hammering == accessing every ~5 minutes) | 22:51 |
| mwhudson | that sounds like a load even loggerhead should be able to cope with :) | 22:51 |
| mwhudson | the machine seems a bit busy but nothing bonkers | 22:51 |
| mwhudson | it runs too many services, that's the big problem | 22:52 |
| beuno | I haven't been able to see that page in a while now | 22:52 |
| === kiko-afk is now known as kiko | ||
| mwhudson | hmm! | 22:53 |
| lifeless | vostok still? | 22:54 |
| mwhudson | yeah, for just a little longer | 22:54 |
| lifeless | I don't think its too many services | 22:54 |
| awilkins | Verterok: Ta | 22:54 |
| lifeless | I think its inefficient services that will expand to use the resources available | 22:54 |
| lifeless | and then crash anyway | 22:55 |
| mwhudson | lifeless: well, ok | 22:55 |
| james_w | hey! http://article.gmane.org/gmane.comp.version-control.subversion.devel/101669 | 22:55 |
| lifeless | pedants-R-us at your beck and call | 22:55 |
| mwhudson | but it's not just loggerhead though :) | 22:55 |
| mwhudson | the puller hits it pretty hard too | 22:55 |
| lifeless | I love this: | 22:56 |
| lifeless | SILENTLY upgrade your working copy, which means that previous | 22:56 |
| lifeless | versions of Subversion will no longer be able to read it. | 22:56 |
| lifeless | see, this is why I think what we do is _better_ | 22:56 |
| awilkins | It's not the first time | 22:56 |
| lifeless | abentley: your bzrdir change, is just a conf file? | 22:56 |
| lifeless | awilkins: oh, I know :) | 22:56 |
| awilkins | It's a shame, because it restricts you to using older CLI clients until your GUI clients catch up | 22:57 |
| abentley | lifeless: Yes. | 22:57 |
| lifeless | abentley: then I think its ok to add it without bumping the format, but subsequent changes are likely to need a bump | 22:58 |
| abentley | lifeless: agreed. | 22:58 |
| * beuno makes a voodoo doll shaped like IE7 and starts poking it with needles | 22:58 | |
| lifeless | abentley: is the new file cloned? | 22:58 |
| abentley | lifeless: no. | 22:58 |
| * mwhudson wanders off to a different computer for a call | 22:59 | |
| mwhudson | beuno: loggerhead got restarted, the link should work now | 22:59 |
| beuno | mwhudson, it does, thank you | 23:00 |
| jam | beuno: I just got it to work as well | 23:01 |
| jam | that doesn't seem like a particularly huge diff | 23:01 |
| lifeless | 7 methods to go | 23:01 |
| engie | I'm working on my first bzr plugin - https://launchpad.net/bzr-stale-comments . The idea is to put RevNo: X into docstrings and other comments which shows the revision number that the comment and associated code block is valid for. The plugin detects these and fails the commit if the code has been updated but not the comment. It is only just working, with no real semblance of testing, | 23:02 |
| lifeless | engie: cool | 23:03 |
| lifeless | engie: sounds interesting | 23:03 |
| beuno | jam, I don't think it's the diff, it may be the multiple parents, but I'm just guessing | 23:05 |
| === spiv_ is now known as spiv | ||
| === _thumper_ is now known as thumper | ||
| awilkins | Verterok: I'm getting "unable to load plugin" | 23:48 |
| Verterok | awilkins: using bzr-eclipse/trunk? | 23:49 |
| awilkins | Verterok: Just in the bzr client | 23:49 |
| awilkins | Verterok: Installed xmloutput.xmlrpc as "xml" in the bzr plugins folder and it says "Unable to load plugin xml" at the start of every call | 23:50 |
| awilkins | bzr Unable to load plugin u'xmloutput' from u'C:/Users/Adrian/AppData/Roaming/bazaar/2.0/plugins' | 23:50 |
| Verterok | awilkins: do you have bzr.exe or a full python install? | 23:50 |
| mwhudson_ | awilkins: bzr -Derror rocks | 23:50 |
| mwhudson_ | should get you a more useful traceback | 23:50 |
| Verterok | mwhudson_: thanks ;) | 23:51 |
| awilkins | Verterok: Full python install, I even just built the 1.6b2 to see if it was that | 23:53 |
| awilkins | "No module named errors" | 23:53 |
| Verterok | awilkins: maybe a typo in my rush to push the lastest changes... | 23:54 |
| Verterok | awilkins: let me double-check this | 23:54 |
| Verterok | awilkins: heh, I renamed a module form errors to xml_erros and left a errors.pyc behind | 23:55 |
| Verterok | that's the reason it "works for me" (tm) | 23:55 |
| Verterok | :P | 23:55 |
| mwhudson_ | ouch | 23:55 |
| awilkins | Fixed | 23:56 |
| igc | morning | 23:57 |
| Verterok | awilkins: great, (it was in service.py) here too...pushing the fix to lp | 23:57 |
| Verterok | mornin' igc | 23:58 |
| lifeless | igc: http://www.theregister.co.uk/2008/06/19/mysql_dumps_bitkeeper/ | 23:58 |
| igc | hi Verterok | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!