| beuno | mwhudson, someday, we'll need to clear out all those merge proposals for loggerhead | 00:24 |
|---|---|---|
| beuno | I feel very bad for all the unused code :( | 00:24 |
| igc | morning | 00:24 |
| hazmat | is it possible (via bzr-svn) to set a file property | 00:25 |
| mwhudson | beuno: yeah, me too | 00:26 |
| * hazmat wonders if a web browser on a bzr repository can be fast | 00:33 | |
| lifeless | I feel so fumble fingered on this new keyboard | 00:39 |
| RAOF | lifeless: Is that your new envy-inducing laptop of supreme power? | 00:41 |
| lifeless | yes | 00:41 |
| lifeless | its not actually /that/ fast | 00:41 |
| lifeless | as its a mobile edition, its relatively slow clock rate (2.13Ghz, idling at 1.2Ghz) | 00:42 |
| lifeless | but the memory is really nice | 00:42 |
| lifeless | and the SSD is pretty zippy | 00:42 |
| RAOF | And it's quad-core, isn't it? | 00:42 |
| lifeless | bzr selftest --parallel=fork took 6 minutes | 00:42 |
| lifeless | 2 core, with threads so linux sees 4 cpus | 00:42 |
| RAOF | Aaah. Still, 8gb of ram must be all sorts of fun. | 00:44 |
| lifeless | yes | 00:44 |
| lifeless | once i finish bugfixing ubuntu-vm-builder I'm going to make a lucid VM for lp patches | 00:44 |
| lifeless | I've got 20G free, which is strange | 00:45 |
| lifeless | I had a 60GB disk in my old laptop | 00:45 |
| lifeless | rsynced across, and I have 86G used | 00:45 |
| === verterok_ is now known as verterok | ||
| lifeless | there is 5 GB in a recovery partition I didn't have the heart to blow away, and 1GB in swap, just in case it really wants it | 00:46 |
| Meths | What laptop is this? | 00:47 |
| lifeless | Meths: my new one | 00:47 |
| Meths | make/model? | 00:48 |
| lifeless | x201s | 00:48 |
| lifeless | i7 640, 8G ram, 128G samsung SSD | 00:48 |
| Meths | pretty sweet | 00:49 |
| lifeless | yeah :) | 00:49 |
| poolie | a separate vm so that it doesn't mess with your general system configuration? | 00:50 |
| lifeless | yeah | 00:50 |
| lifeless | I dont' want pgsql and apache running when I'm flying to $destination | 00:50 |
| lifeless | and i'd forget to shut em all off if I had them installed-and-running by default | 00:50 |
| poolie | mm me too | 00:50 |
| hazmat | is it possible (via bzr-svn) to set a file property | 00:51 |
| jelmer | hazmat: no | 00:56 |
| === jelmer_ is now known as jelmer | ||
| poolie | james_w, we'd especially like to get it in for https://bugs.edge.launchpad.net/bzr/+bug/521989 | 01:35 |
| ubottu | Ubuntu bug 521989 in bzr "errors when importing WorkingTree on a thread due to signals" [Undecided,Confirmed] | 01:35 |
| james_w | ah, hi | 01:36 |
| james_w | is it bugfix only? | 01:36 |
| poolie | our x.y.z, z>0 releases will always be bugfix only | 01:39 |
| james_w | poolie: could you send me a mail and I will look tomorrow? IRC is too easy to forget. | 01:39 |
| poolie | fsvo 'always' i guess :) | 01:39 |
| james_w | should be a 2 minute job for me in that case | 01:39 |
| poolie | thanks, i will | 01:39 |
| james_w | yeah, there's bugfix an there's bugfix :-) | 01:39 |
| poolie | sent | 01:56 |
| hazmat | loggerhead needs alot of love | 02:00 |
| mwhudson | hazmat: yeah | 02:02 |
| hazmat | mwhudson, is there anyone with dedicated time on loggerhead? | 02:02 |
| mwhudson | hazmat: as much as anyone, it's me, but i've been doing other things lately | 02:03 |
| poolie | doesn't max? | 02:05 |
| lifeless | doesn't max what? | 02:05 |
| mwhudson | poolie: true | 02:06 |
| poolie | have some time on loggerhead | 02:06 |
| poolie | i don't know if that's still true | 02:06 |
| hazmat | a couple things worth looking at.. switching out to chamelon for page templates, use an aggregate js file, slimming down the html by using css. | 02:12 |
| Peng | Another new templating language? Sounds fun. | 02:12 |
| mwhudson | Peng: it's another implementation of the same one | 02:12 |
| hazmat | its a page template engine, almost entirely compatible with the existing templates | 02:12 |
| Peng | Oooh. Neato. | 02:12 |
| mwhudson | god knows simpletal isn't very nice | 02:12 |
| hazmat | its mostly faster because it compiles out to python code, instead of a using a template engine interpreter | 02:13 |
| Peng | FWIW, I wrote code to use Yahoo!'s aggregate JS file for YUI. Nothin' for Loggerhead's JS, though. | 02:13 |
| hazmat | it would be nice if loggerhead didn't have to scan the repo and (re)build a cache to serve, but its not clear if that can be worked around, i assume that's mostly to avoid xml parse | 02:15 |
| lifeless | hazmat: we don't use xml these days | 02:16 |
| Peng | hazmat: Patches welcome. :P | 02:16 |
| hazmat | hmm.. so perhaps the loggerhead whole history cache is uneeded | 02:16 |
| Peng | Seriously, though, re-evaluating that is on the to-do list. | 02:16 |
| hazmat | i notice trac-bzr doesn't bother with it.. it actually seems reasonably fast on a small repo | 02:16 |
| Peng | Not all repos are small. | 02:17 |
| hazmat | Peng, i no.. i'm using the launchpad repo as my test case for performance analysis of loggerhead. | 02:17 |
| hazmat | s/no/know | 02:17 |
| === mnepton is now known as mneptok | ||
| Peng | <3 | 02:17 |
| hazmat | is there a way i can see what a pull will bring in without actually doing it | 02:59 |
| Peng | hazmat: "bzr missing" | 03:00 |
| hazmat | Peng, thanks | 03:00 |
| Peng | hazmat: That shows what both pull and push would do. See "bzr help missing" for the arguments to pass if you only want to see one or the other. | 03:01 |
| Peng | poolie: pm? | 03:01 |
| Peng | Eep. | 03:03 |
| Peng | I broke poolie. :( | 03:04 |
| fullermd | Now you have to take his place. | 03:06 |
| parthm | i looking at bug #304320 seems easy enough to add --clean-obsolete-packs option | 03:19 |
| ubottu | Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,Confirmed] https://launchpad.net/bugs/304320 | 03:19 |
| parthm | in order to actually delete the dir contents i am thinking of adding an additional parameter to transport.delete_tree that allows skipping delete for container | 03:21 |
| parthm | http://pastebin.com/JbaQhzxD | 03:21 |
| parthm | this should ensure that if the operation is terminated for some reason .bzr/repository/obsolete_packs folder is still there. is this a reasonable approach? | 03:21 |
| spiv | parthm: I think that's reasonable. You should add a per_transport test for the new param. | 03:30 |
| lifeless | mm | 03:30 |
| parthm | spiv: thanks for the pointer. i will add the per_transport tests. | 03:30 |
| lifeless | there is functionality to delete the contents of obsolete_packs already | 03:30 |
| lifeless | Please don't use the transport api to get at the private functionality of the repository - use that existing code instead. | 03:31 |
| xnox | Hello. How to use keywords plugin? I can't understand where do i need to place rules file | 03:32 |
| parthm | lifeless: where can I find this function? bzrlib.repository? | 03:32 |
| lifeless | parthm: bzrlib.repository.repofmt/pack_repo.py - somewhere in there | 03:37 |
| lifeless | obsolete packs is cleaned out when we do a pack - right before we do the pack. | 03:37 |
| parthm | lifeless: i see a private method, repofmt.pack_repo._clear_obsolete_packs. | 03:37 |
| lifeless | yup | 03:37 |
| lifeless | its a private task :) | 03:37 |
| lifeless | add a parameter to the pack() call - something like 'assume_disk_will_write_immediately' or the like - its very risky deleting obsolete_packs folder, we really don't want people using this in API code in a casual manner | 03:38 |
| lifeless | its particularly unsafe to use over SFTP/HTTP/NFS | 03:38 |
| parthm | lifeless: i agree, i have added this to the pack command help. | 03:39 |
| parthm | http://pastebin.com/JbaQhzxD | 03:39 |
| parthm | assume_immediate_write sounds like a good way to do it. | 03:39 |
| lifeless | parthm: on the transport change, which might be nice in and of itself, how about 'children_only' rather than 'skip_container' | 03:41 |
| lifeless | container isn't used elsewhere in the docs for transports | 03:41 |
| parthm | yes. children_only sounds good. maybe i should file it as a bug so it can be tracked separately. | 03:41 |
| lifeless | sure | 03:41 |
| parthm | i was wondering if it makes sense to have a --clean-obsolete-packs-only option. pack can sometimes be time consuming. this would give the user to just remove obsolete packs without going through pack process. | 03:42 |
| lifeless | sure | 03:44 |
| lifeless | there may be a bug on that even | 03:44 |
| parthm | I notice that only RepositoryPackCollection has a _clean_obsolete_packs method and not KnitPackRepository. both have the pack method. whats the different between the two? | 04:02 |
| spiv | RepositoryPackCollection is not an implementation of the Repository interface | 04:05 |
| spiv | It's an implementation of ._pack_collection of (pack format) repositories. | 04:05 |
| spiv | So, the difference is different layers. | 04:05 |
| parthm | spiv: ah. i get it. so repository.pack internally maintains _pack_collection which it calls pack on. thanks. | 04:08 |
| AfC | Anyone know off hand the Subversion equivalent of `bzr revert`? Is there one? | 06:04 |
| mwhudson | AfC: svn revert -R . ? | 06:05 |
| AfC | hm | 06:06 |
| AfC | oh | 06:06 |
| AfC | how did I not see that. Grrr | 06:06 |
| AfC | sorry. Thanks mwhudson | 06:06 |
| lifeless | mwhudson: 'bzr revert' | 06:14 |
| Peng | Yeah, use bzr-svn. :D | 06:14 |
| parthm | i am planning to add tests for bug #304320 to tests.blackbox.test_pack http://pastebin.com/C51qWKUH | 06:55 |
| ubottu | Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,In progress] https://launchpad.net/bugs/304320 | 06:55 |
| parthm | is the pack operation guaranteed to generate packs? | 06:55 |
| parthm | i am thinking of doing a transport.list_dir() and making sure its len is 0 | 06:56 |
| parthm | with --clean-obsolete-packs | 06:56 |
| lifeless | parthm: its not guaranteed, no - but pragmatically thats fine | 07:03 |
| lifeless | just do two commits, then a pack. | 07:03 |
| lifeless | (because one commit would be fully packed already) | 07:03 |
| lifeless | if, in future, we change bzr to auto clean when we can tell things have hit disk or whatever, we can change the test. | 07:04 |
| parthm | lifeless: right now when are the obsolete packs cleared? | 07:05 |
| lifeless | parthm: when bzr packs | 07:05 |
| parthm | lifeless: ok. i will go with the two commits approach. thanks. | 07:06 |
| vila | hi all! | 07:32 |
| parthm | vila: hi | 07:35 |
| parthm | is there a way to put a print in a test case and view it? selftest -v doesn't seem to do it. | 07:40 |
| vila | parthm: if you're running blackbox tests, keep in mind that stdin/stdout/stderr are redirected.... | 07:44 |
| vila | parthm: which also means you can't put pdb breakpoints in the code run by the inner run_bzr | 07:45 |
| parthm | vila: yes. i am using the blackbox tests. right now i just dump the info i need into a temp file but i think that a very crude way. | 07:46 |
| vila | parthm: try to write whitebox tests instead :) | 07:48 |
| parthm | vila: ok. thanks :) | 07:48 |
| vila | parthm: they are generally far more precise and easier to debug too :) | 07:49 |
| === dcoles_ is now known as dcoles | ||
| dcoles | jelmer_: Just to check I'm understanding you correctly with that bug, bzr serve --git _can't_ serve bzr branches? Only bzr-git ones? | 08:15 |
| igc | hi vila | 08:43 |
| vila | hi Ian | 08:43 |
| * igc dinner | 08:54 | |
| === nlisgo_ is now known as nlisgo | ||
| jelmer_ | dcoles: yes | 09:03 |
| dcoles | jelmer_: Ah. OK. | 09:04 |
| dcoles | Then my other bug was when you try and serve git branches in a shared repo | 09:05 |
| dcoles | I'll make a working test and then report that. | 09:05 |
| === weigon_ is now known as weigon | ||
| === jelmer_ is now known as jelmer | ||
| MvG | lifeless: I just read your comment about the news_merge plugin in https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045 | 11:56 |
| MvG | Hadn't known there was such a plugin. Does pqm make use of it? I assume it does. | 11:56 |
| MvG | What got me worried was the fact that the launchpad merge preview reported conflicts. I guess this is difficult to avoid right now, because the per-branch configuration isn't versioned. So launchpad users would have to configure each of their branches, which requires a lot of UI and work. | 11:56 |
| MvG | I think it would be better if one could configure the plugin in such a way that it works on all branches. To me that sounds like an application of the proposed .bzrmeta directory. Has this been discussed before? | 11:56 |
| MvG | BTW: That config issue makes me think of another thing I've been repeatedly thinking about recently: handling of ZIP files. | 12:05 |
| MvG | There is quite a number of file formats out there that are ZIP under the hood, but handled as a single document by some application, and usually have a file name extension other than ZIP. Examples are Microsoft OOXML, Google KMZ, Apple iWork formats, JAR files, and so on. | 12:05 |
| MvG | I often would have wished for a plugin to handle these things as a single ZIP in a working tree, but as a directory of members inside the branch. I guess I'd wish for morege conflicts to cause directory layout in the working tree as well, until those conflicts are resolved. | 12:05 |
| MvG | I don't have the time to implement this, but I'd still be interested in your opinion. Do you think this useful? Feasible? How would you want to configure such a plugin? Can you think of use cases likely to cause trouble I haven't thought of yet? Do you know of any efforts in that direction? | 12:05 |
| * igc night | 12:22 | |
| === salgado_ is now known as salgado | ||
| dipnlik | hello, anyone here using zsh? | 12:28 |
| MvG | dipnlik: not me, but I'm still curious why you're asking. | 12:32 |
| dipnlik | MvG: i'm having autocomplete issues when i'm on a repository folder | 12:33 |
| MvG | I'm the one maintaining bash-completion-plugin. | 12:34 |
| dipnlik | cd ~/my-repo ; bzr st <tab> gives me an error | 12:34 |
| MvG | I haven't looked at how zsh completion works, but I would assume that it should be possible to extens my plugin for zsh if there is need and some help. | 12:34 |
| dipnlik | bzr: ERROR: Not a branch: "/Users/dip/my-repo/.bzr/branch/": location is a repository | 12:34 |
| * MvG is looking at the zsh completion script right now. | 12:35 | |
| MvG | OK, the zsh completion works on file names, not only command arguments. In that case, sensible autocompletion is harder, and also slower because it usually requires a call to bzr. | 12:36 |
| MvG | dipnlik: If the path only contains a repo and no branch or working tree, then running the status command, the only completion to "st" that I can see, doesn't make too much sense, does it? | 12:38 |
| MvG | dipnlik: zsh does execute "bzr ls --versioned", which should give you the same error message. | 12:39 |
| MvG | Of course, if you want to print the status of some file in some subdir, that would be a different thing... | 12:39 |
| dipnlik | i'm on a repo with some branches on it | 12:40 |
| dipnlik | i only wanted to autocomplete the branch name for the bzr ls command | 12:40 |
| MvG | In my opinion, the zsh completion is either too clever, or not clever enough. | 12:42 |
| dipnlik | that's what I think too | 12:42 |
| MvG | For bash for example, I only complete command arguments, but not file and directory names, as for the latter the built-in completion tends to be better. Therefore this kind of problem doesn't occur with my bash completion. | 12:42 |
| MvG | s/command arguments/command options/ | 12:43 |
| dipnlik | that's nice | 12:43 |
| dipnlik | so, I think it's more a zsh problem than a bzr problem, right? | 12:44 |
| MvG | I think it's a problem of whoever wrote the zsh completion script. | 12:44 |
| MvG | Which seems to be Steve Borho in 2005. | 12:45 |
| dipnlik | ouch >.< | 12:45 |
| MvG | Judging from the log, the script is unmaintained since then. | 12:46 |
| luks | isn't Steve Borho a TortoiseHG developer? :) | 12:47 |
| MvG | The bash script shipped with bzr is in an equally bad shape, which caused me to write the bash plugin in the first place. | 12:47 |
| MvG | luks: There is some evidence to that fact on the web, yes. Can't say I know, though. | 12:50 |
| luks | yes, he is | 12:50 |
| luks | so there is probably little interest in fixing the script :) | 12:51 |
| dipnlik | MvG: any chance of a simple hack to at least avoid the error message? | 12:51 |
| MvG | dipnlik: Sure: redirect errors to null in _versionedFiles: fileList=(${(ps:\0:)"$(bzr ls --null --versioned 2>/dev/null)"}) | 12:52 |
| dipnlik | MvG: i think I'll need more details to use that :( | 12:54 |
| MvG | OK, dipnlik. All I have is a bzr source tree checkout, which contains a file contrib/zsh/_bzr which in turn contains the completion instructions. | 12:54 |
| MvG | You should have a copy of that file somewhere on your system, probably in a path mentioned in $fpath. | 12:55 |
| MvG | You need to find and edit that file. | 12:55 |
| MvG | Lines 48-53 of that file describe a function _versionedFiles, where line 50 does a bzr ls invocation. | 12:56 |
| MvG | After the --versioned but before the )"}) you insert a space and 2>/dev/null | 12:57 |
| MvG | Then you restart your zsh, and see if things work. | 12:57 |
| dipnlik | will try that, thanks a lot | 12:58 |
| MvG | Out of curiosity: what makes you use zsh? | 12:59 |
| dipnlik | trying it out of curiosity and because it fixes my main problem with bash: the command history | 13:00 |
| dipnlik | let's say i have two bash tabs on terminal, one with tail something and other where I type all the commands I use | 13:00 |
| dipnlik | if I exit the "main tab" then exit the "tail tab", all history on the main tab is gone | 13:01 |
| MvG | dipnlik: "shopt -s histappend" should fix this for bash. | 13:02 |
| dipnlik | zsh promises to do other things better, but for now it isn't really THAT better | 13:04 |
| dipnlik | oh-my-zsh also makes some promises | 13:04 |
| luks | MvG: oh, thank you for that! | 13:14 |
| MvG | The histappend? I think it should be standard on any system. It is on Gentoo. | 13:14 |
| luks | yeah | 13:15 |
| luks | I always hated that it overwrote the file, but I just accepted it as a fact | 13:15 |
| edakiri | I have a 'parent' directory magically appearing. Is it from bzr? | 13:17 |
| luks | appearing after what action? | 13:17 |
| luks | it's not any stadnard bzr directory | 13:17 |
| edakiri | i don't know. i just made another new repo and it did not happen. init add commit : are candidates. You answered my question, I think. | 13:19 |
| dipnlik | are bzr vs. git discussions allowed here? i'm still not that into any of these but git seems to be overly complicated | 13:21 |
| jelmer | dipnlik: as long as they're discussions not flamewars :-) | 13:23 |
| jelmer | dipnlik: we'd be happy to discuss the differences in features of both systems and the advantages/disadvantages | 13:24 |
| dipnlik | jelmer: yay | 13:25 |
| edakiri | has someone published/posted comparisons of efficiency scaling with history depth and repository size? I know git did have trouble scaling to large repository sizes within a module | 13:26 |
| dipnlik | i've seen comparisons and maybe git is technically better, but bzr is targeted for users, and that's a GREAT advantage | 13:28 |
| dipnlik | problem is: "everyone" is using git :( | 13:31 |
| dipnlik | so I don't know if I learn both or if I go with the flow | 13:32 |
| MvG | dipnlik: There is a bzr completion script shipped with zsh (4.3.10 in my case) which seems to be different and slightly more up to date than that shipped with bzr itself. So maybe you should file a bug report with zsh, after ensuring your script actually comes from a plain zsh setup. | 13:34 |
| MvG | lifeless: wrt my messages somewhere up there: just filed https://bugs.launchpad.net/bzr/+bug/546899 | 13:37 |
| ubottu | Ubuntu bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Undecided,New] | 13:37 |
| dipnlik | MvG: i'm on zsh 4.3.9, which comes with OSX. edited /usr/share/zsh/4.3.9/functions/_zsh as you told me and it at least doesn't show the errors anymore, it helped a lot :) | 13:39 |
| edakiri | dipnlik: have you seen comparisons of the scaling behaviour? I'm thinking of a graph that shows how memory consumption and processing time vary with varying code size or history. | 13:46 |
| luks | dipnlik: from my experience, most people from "everyone" that are using git don't *really* know how to use git | 13:50 |
| dipnlik | edakiri: no I didn't, not really into which is better on the long run but since I'm only starting with version control and don't have big projects, that's not an issue for me (at least for now) | 13:52 |
| dipnlik | luks: what do you mean? I think I want to *really* know how to use either git or bzr, just not sure which i'll definitely use | 13:54 |
| dipnlik | also, github looks really great, maybe that is why "everyone" uses git | 13:55 |
| luks | dipnlik: I mean that most people using git are using git just because it's popular | 13:56 |
| luks | no any other reason | 13:57 |
| dipnlik | luks: i'm using bzr because it seems it's easier but still not sure if I try to get used to git or not. what do you think? | 14:01 |
| dipnlik | it's nice to use popular tools sometimes | 14:01 |
| MvG | My biased experience on git vs. bzr: 1. git pickaxe approach for history examination is nice. 2. git having to add stuff before committing is annoying, but commit -a helps. 3. bzr commands are much closer to svn and therefore easier for newbies, I think. 4. bzr send feels much easier than git patch formatting stuff. 5. I like the clear distinction between repo, branch and working tree bzr offers, to each its own dir. That way you can have multiple bran | 14:15 |
| luks | dipnlik: git allows you to very easily screw things up | 14:24 |
| luks | dipnlik: other than that, it's not that bad | 14:24 |
| dipnlik | MvG: 1 and 4. i've no idea /o\ 2. here on bzr i have to add new files before commiting 3 and 5. agreed | 14:25 |
| luks | dipnlik: after you fully understand bzr, it should be easy to use git | 14:25 |
| MvG | 2. only if they are new, not if they are just edited. The latter is much more frequent in most cases. | 14:27 |
| dipnlik | MvG: ouch, adding edited files is weird. is there a good reason for that? | 14:29 |
| luks | dipnlik: git uses a thing called 'index' | 14:30 |
| luks | it contains changes that are meant to be committed | 14:30 |
| luks | you can change a file, git add it, change it again but only the first version will be committed unless you add it again | 14:30 |
| luks | git add is really very different from bzr add | 14:31 |
| MvG | and diff compares indexed state to working tree by default, so after the add but before the commit, a diff without options shows you nothing. | 14:31 |
| oly | hi, can someone explain this error / how i can fix it ? | 14:31 |
| oly | bzr: ERROR: Revision {('filehandler.py-20100312144733-dlv7tjsgt7fubqdc-1', 'om@om-20100319173025-gugcm11qrsdlksij')} not present in "CHKInventoryRepository('file:///home/om/Ubuntu%20One/reprap/software/pyreplicator/.bzr/repository/')" | 14:31 |
| MvG | oly: What command did you execute? | 14:32 |
| oly | i well i tried a merge it said my tree was out of date so i tried a bzr update | 14:32 |
| oly | and got that message | 14:32 |
| MvG | oly: can you pastebin your whole session, starting at the first command causing the out of date error message? | 14:33 |
| oly | http://pastebin.com/dKfL6323 | 14:34 |
| oly | theres not really anything to it though | 14:34 |
| oly | is there a way i can force a merge it may overwrite what ever is causing the issue then | 14:35 |
| MvG | oly: Can you also add the output of "bzr info"? | 14:36 |
| MvG | oly: As far as I can tell, you are on a lightweight checkout, and the branch associated with that checkout was modified in some incomatible way since you created the checkout. | 14:36 |
| oly | http://pastebin.com/LGzyJrch | 14:37 |
| oly | could be, i do move between ubuntu lucid and karmic so the versions of bzr are likely different | 14:37 |
| MvG | OK, my assumption was wrong. | 14:37 |
| MvG | oly: I guess I'd first make a copy of that whole directory, just to be safe. Then I'd try to create a lightweight checkout of the branch head: "bzr co --lightweight . prhead" or similar. If that succeeds, I'd diff those two. | 14:40 |
| MvG | oly: The diff should show you both differences in the working tree format, possibly caused by different bzr versions, as well as the differences you'd wish to commit. | 14:42 |
| oly | hum it checked out okay | 14:43 |
| MvG | oly: Passing -Derror to commit will print a back trace, which might give us additional information as to what revision it expects and why it isn't there. | 14:43 |
| oly | diff pyreplicator/ /home/om/Ubuntu\ One/reprap/software/pyreplicator/ | 14:43 |
| oly | is that how i should do the diff ? | 14:43 |
| oly | i usually use meld and am only comparing individual files | 14:44 |
| MvG | diff -ur pyreplicator pyhead | 14:44 |
| MvG | or prhead, or whatever you have named it. | 14:44 |
| MvG | I'd be particularly interested in anything mentioning the .bzr/checkout subdirectory | 14:45 |
| oly | is that on the new checkout | 14:46 |
| MvG | It should exist in both places. | 14:48 |
| MvG | And differences might be an indication of what's causing your error. | 14:48 |
| bialix | jelmer: ping | 14:52 |
| jelmer | bialix: hey | 14:54 |
| bialix | heya | 14:55 |
| oly | http://pastebin.com/M9RCxdAD | 14:55 |
| bialix | jelmer: does bzr-svn supports tags a-la bzr tags? | 14:56 |
| oly | does not look like theres anything noticably different other than the source files | 14:56 |
| oly | which is why i am trying to commit them :p | 14:56 |
| bialix | jelmer: see Bug 546906 | 14:56 |
| ubottu | Launchpad bug 546906 in bzr-scmproj "crash for svn branches" [Undecided,New] https://launchpad.net/bugs/546906 | 14:56 |
| bialix | jelmer: any suggestion how I should fix this in scmproj? | 14:56 |
| jelmer | bialix: yep, it does | 14:56 |
| bialix | jelmer: apparently other_branch.tags.get_tag_dict() where other_branch is svn://xxx does not | 14:58 |
| dipnlik | well, i'm leaving, thanks a lot for the help everyone, i'll stick with bzr and bzr-svn :) | 14:58 |
| jelmer | bialix: only if you have a branch layout for which it is not known where the tags should be | 14:59 |
| bialix | jelmer: oh | 14:59 |
| bialix | jelmer: cause Guessed repository layout: TrunkLayout(0), guess layout to use: CustomLayout(['trunk/libavcodec'],[]) | 14:59 |
| bialix | that's it? | 15:00 |
| jelmer | bialix: TrunkLayout(0) puts all tags in tags/ | 15:00 |
| jelmer | bialix: for a custom layout it's not known where to put the tags | 15:00 |
| bialix | jelmer: so... maybe I just should catch that error and suppress it? | 15:01 |
| MvG | oly: Those u1conflict files look suspicious to me. | 15:01 |
| MvG | Any idea where they might come from? How do they differ from those without the .u1conflict extension? | 15:02 |
| oly | okay, i dont think there in the repository at leat they should not be | 15:02 |
| oly | there cause when there is a sync error between my two computers | 15:03 |
| oly | they are generally the same file but a different version that did not sync | 15:03 |
| MvG | oly: I guess some such sync error garbled your working tree or branch. | 15:03 |
| jelmer | bialix: it depends on what you're trying to do :-) | 15:04 |
| oly | ah, i did wonder if it could be todo with the file sync | 15:04 |
| jelmer | bialix: if you're pulling from that branch, I would just ignore the tags | 15:04 |
| MvG | oly: Safe thing would be, clone your branch and apply the source tree diff manually, without touching the .bzr dir. | 15:04 |
| bialix | jelmer: I'm checking if I need to pull first | 15:05 |
| oly | okay or maybe easier, can i just revert to the online copy ? | 15:05 |
| oly | and hit save in my editor again for the newer versions and then commit ? | 15:05 |
| * bialix waves at amanica | 15:09 | |
| amanica | hi bialix :-) | 15:09 |
| bialix | hi dude | 15:09 |
| MvG | oly: Revert to online using "pull --overwrite" might work, but I'd not feel as sure with that. | 15:09 |
| oly | okay, will have a play see what else i can break :) | 15:11 |
| MvG | oly: In my experience, synchronization of bzr branches using other sync tools is a bad idea. Didn't work out for me with unison either. Sooner or later you happen to modify things at one end but forget the other, and then a file-based sync easily breaks stuff. I'd suggest synking using bzr pull instead. | 15:11 |
| MvG | I meant modify at both ends and forget to sync in between. | 15:12 |
| oly | okay, | 15:12 |
| oly | yeah i asked some one about it a while ago if it was likely to cause problem they suggest it would be okay | 15:12 |
| oly | but apparently not :p | 15:12 |
| MvG | is should be if you keep things strictly sequential, but that's hard. | 15:13 |
| oly | yeah, anyway fixed | 15:14 |
| oly | i had a better idea | 15:14 |
| oly | move the .bzr folder to tmp, then copy the .bzr from a newely checked out copy | 15:15 |
| oly | then run the commit :) | 15:15 |
| MvG | That's fine. | 15:16 |
| oly | simple and seems to work which is what i like :) | 15:16 |
| MvG | When a merge proposal into bzr.dev was reviewed "Needs Fixing" by one person and has status "Needs review", do I have to resubmit the proposal after fixing the issue, or should I simply wait? | 15:21 |
| MvG | https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045 in particular. | 15:22 |
| oly | Thanks for the help by the way MvG :) | 15:22 |
| MvG | np | 15:22 |
| Peng | Um...I'm not sure. You can push again and the merge proposal will be magically updated. | 15:24 |
| Peng | You can also file a new merge proposal, and that will magically handle everything too. | 15:24 |
| MvG | Peng: thx. I noticed the magic update. I guess I'll wait a while, see if waiting is enough. After all, "Needs Fixing" sounds less problematic than "Resubmit", which is a possible review comment as well. | 15:28 |
| === salgado is now known as salgado-lunch | ||
| Peng | Is it a bug that urlutils.local_path_from_url barfs on a "readonly+file://" URL? | 16:07 |
| bialix | Peng: I don't think it's the correct URL to use in local_path_from_url | 16:28 |
| bialix | readonly+ is the prefix for bzr transport | 16:28 |
| Peng | Ohh? | 16:32 |
| Peng | Hmm. | 16:32 |
| Peng | Do readonly transports have a copy of the URL without that prefix, then? | 16:32 |
| Peng | Plus, IIRC the prefix is kept in Branch.base. | 16:32 |
| bialix | Peng: IIRC readonly transport is the wrapper for plain transport | 16:40 |
| bialix | so yes, there should be copy of URL w/o readonly+ somewhere inside | 16:41 |
| MvG | jam: Do you think I should mark bug 546899 as affecting PQM as well? | 16:56 |
| ubottu | Launchpad bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Wishlist,Triaged] https://launchpad.net/bugs/546899 | 16:56 |
| jam | MvG: reasonable to do so, I'm not really sure what would be done about it | 16:56 |
| jam | it is more that bzr's pqm setu | 16:56 |
| jam | it doesn't really affect bzr-pqm itself | 16:56 |
| jam | so on second thought | 16:56 |
| jam | maybe add bzr | 16:56 |
| jam | but don't add bzr-pqm | 16:56 |
| MvG | Hmmm... hadn't known there was a bzr-pqm in addition to "plain" pqm... :-) | 16:58 |
| jam | ah, sorry | 16:58 |
| jam | pqm is the robot | 16:58 |
| jam | bzr-pqm is a plugin to submit to the robot | 16:58 |
| MvG | And the robot should be the more likely one to complain about broken news, right? | 16:58 |
| MvG | s/broken/conflicting/ | 16:59 |
| jam | regardless, adding 'bzr' might be reasonable, but it is probably more of a sysadmin thing than a bug in the program itself | 16:59 |
| MvG | There is no sysadmin subproject, is there? | 16:59 |
| MvG | Come to think of it, it already DOES affect bzr, because news_merge is part of the bzr.dev source tree. | 17:02 |
| === deryck is now known as deryck[lunch] | ||
| === salgado-lunch is now known as salgado | ||
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| === radoe_ is now known as radoe | ||
| jelmer | jam: hi | 18:31 |
| jelmer | jam: So, BtreeIndex seems very slow adding new entries after ~200k entries | 18:32 |
| Peng | 200k entries? Are you doing something evil? :D | 18:32 |
| jelmer | I would never do evil things. | 18:32 |
| Peng | You use libsvn. :P | 18:33 |
| jelmer | So does Google. | 18:33 |
| jelmer | And Google doesn't do evil. | 18:33 |
| jelmer | Ergo, I don't do evil. | 18:34 |
| jelmer | QED :_P | 18:34 |
| Peng | Ah! Your logic is flawless. | 18:34 |
| hazmat | hmm.. trac-bzr performs just as poorly as loggerhead on large repos | 21:11 |
| hazmat | worse actually | 21:11 |
| mwhudson | the cache isn't just there because i'm an idiot :) | 21:11 |
| hazmat | mwhudson, its interesting to see how performant bzr can be for a web ui without building a complete secondary index | 21:12 |
| mwhudson | hazmat: the biggest problem is revision numbering | 21:12 |
| hazmat | mwhudson, i've disabled the dir ancestry stuff (dir rev appears as latest of contents), and i'm running it through repoze.profiler atm... | 21:13 |
| hazmat | mwhudson, yeah.. i think thats what i'm seeing now.. still not 100% though | 21:13 |
| MvG | hazmat: what version of trac-bzr? | 21:15 |
| hazmat | MvG, trunk, with trac 0.11.7 | 21:15 |
| hazmat | trying it out on the launchpad repo | 21:15 |
| hazmat | 110k revs it looks like | 21:16 |
| hazmat | page loads are about 10s when it touches bzr | 21:16 |
| jam | jelmer: the code dumps data to disk | 21:16 |
| jam | you can look at the builder parameter "dump keys at" | 21:16 |
| MvG | hazmat: OK, thats a large number of revisions for sure. What page are you referring to? | 21:17 |
| mwhudson | hazmat: there is this bzr-historycache plugin that might help | 21:17 |
| hazmat | MvG, mostly any browser pages below the root.. but the timeline also but thats mostly because theirs a few k changesets in the last 30 days. | 21:18 |
| hazmat | mwhudson, my end goal is to see if bzr can do a fast web interface, the first thing i'm trying to reason is if a cache is required for that | 21:19 |
| MvG | hazmat: OK, in browser my first bet would be dir revision calculating, but assuming you deactivated all effects of that, conversion of revids to dotted revnos is my next best bet. | 21:19 |
| mwhudson | hazmat: ok, i can tell you that you will have a problem with revision numbering for off-mainline revisions without some kind of cache | 21:19 |
| MvG | hazmat: My current belief is that it is, but in many scenarios a in-memory cache would suffice. | 21:20 |
| lifeless | igc has a plugin for that | 21:20 |
| hazmat | MvG, yeah.. mwhudson mentioned that as well.. it does appear to be that (revid->revno mapping) | 21:20 |
| MvG | lifeless: caching those revs? | 21:20 |
| jelmer | jam: Thanks | 21:20 |
| jelmer | jam: I tried to reproduce it with a trivial script but I can't for some reason :-/ | 21:20 |
| === salgado is now known as salgado-afk | ||
| MvG | hazmat: If you want to dig closer into improving trac-bzr using caches, we should have a longer talk. | 21:23 |
| MvG | I've spent some time already thinking about how I'd do this, what kind of info I'd whish to cache, and what kind of features that'd allow for trac-bzr. | 21:23 |
| hazmat | MvG, if it can't work without caches, i'm going to try and spend time on improving loggerhead, i'm definitely up for the discussion though | 21:24 |
| jelmer | jam: Also, I'm interested in looking at using bzr-based formats for bzr-svn | 21:24 |
| jelmer | jam: basically something like the revisions VF together with some bzr-svn specific indexes, how would I go about doing that? | 21:25 |
| lifeless | MvG: yes | 21:25 |
| jam | so, it depends | 21:27 |
| jam | I'm working on refactoring the code to do something like that for annotations | 21:27 |
| jam | so if you're willing to wait, it should be easier | 21:28 |
| hazmat | mwhudson, MvG as you both suggested, its definitely the string_rev (6s, 2.5s on two of the calls), although one of the calls to get_changeset also takes 2.5s. | 21:28 |
| jelmer | jam: I'm happy to wait | 21:28 |
| jelmer | jam: This is intended for 2.3 ? | 21:28 |
| MvG | My current idea is three caches, most easily explained in terms of relational database tables. | 21:29 |
| MvG | One would be for the whole shared repo, and contain one line per revision. With date, revid, maybe some internal primary key, parents. | 21:29 |
| MvG | Second would be per branch, with dotted revno, merge point, next rev on path to that merge point, index in the order "bzr log -n0" would print it. | 21:29 |
| MvG | Third would be for dirs, in order to determine svn-style last modifying revisions. For this I'd order revisions in a tree, with full fileid to revid mapping only for power of two history length, and relative information for others, to keep the amount of data down. | 21:29 |
| MvG | Both the well-defined "next" (child) revision and the "dir last modified" revision info are highly svn-like, but I think it useful nevertheless. | 21:31 |
| jam | probably in the 2.2 series | 21:31 |
| jam | b1 is only this week | 21:31 |
| lifeless | MvG: 'what revs a fileid is present in' should be answerable pretty fast from 2a repos | 21:31 |
| MvG | lifeless: using what API? | 21:31 |
| lifeless | the chk maps; probably not well exposed today. | 21:32 |
| MvG | Because what trac-bzr does right now already looks painfully slow | 21:32 |
| hazmat | so just using revid, and sans the svn:style dir revs, the performance is passable.. genshi floats to the top in the profiler now ;-) | 21:33 |
| MvG | lifeless: can you give me a fully qualified name pydoc will accept? | 21:33 |
| lifeless | MvG: bzrlib.inventory.CHKInventory | 21:33 |
| MvG | hazmat: So there is hope still. :-) | 21:33 |
| lifeless | MvG: its not a trivial thing; I'm saying that our core db format should be ok at this point | 21:33 |
| lifeless | so there will be somethinking needed | 21:33 |
| lifeless | and api improvements to show it 'publically' | 21:34 |
| Peng | MvG: Loggerhead could use the same thing. | 21:34 |
| MvG | Peng: Loggerhead is already making massive use of caching. | 21:35 |
| mwhudson | <MvG> One would be for the whole shared repo, and contain one line per revision. With date, revid, maybe some internal primary key, parents. | 21:35 |
| mwhudson | MvG: no point caching that, get_revision is plenty fast | 21:35 |
| Peng | MvG: Yes but it sucks. :D | 21:35 |
| MvG | And I found the implementation there so unreadable that I decided not to copy it to trac-bzr. | 21:35 |
| Peng | MvG: Exactly! | 21:35 |
| MvG | mwhudson: The initial string-based lookup already feels wrong, I'd have expected faster access using e.g. a 64bit internal identifier. But maybe I'm wrong here. | 21:37 |
| mwhudson | MvG: bzr has pretty efficent code for mapping strings to "stuff" | 21:38 |
| MvG | Another thing to note is that for the dir to rev cache, I'd need to store for every revision the appropriate ancestor relative to which differences are noted. | 21:38 |
| mwhudson | sure, some kind of hyperoptimized binary data type key value store might be faster | 21:38 |
| mwhudson | but not much and not enough to be worth the pain of keeping the cache up to date imho | 21:39 |
| MvG | So that's one more item to store with each rev, not branch-dependant, and not suitable for the main bzr repo. | 21:39 |
| MvG | Or do you know of an efficient API to 1. tell me the history length of a given rev and 2. find a preceding history element with a given history length? | 21:40 |
| MvG | lifeless: Looking at CHKInventory, I realize that 'what revs a fileid is present in' is not the question I'm asking. | 21:43 |
| lifeless | MvG: what quewstion are you asking? | 21:43 |
| MvG | Rather this: Given revision r, what's the latest element in the history of r where the dir d looks like it does at revision r, i.e. all files had the same contents, names and so on. And for that mainline revision, is there a sideline revision where it already looked the same as well, and if so, recurse down that sideline, until I get to the earliest revision that made the dir what it is today. | 21:45 |
| MvG | s/latest/earliest/ | 21:46 |
| MvG | and "today" only if r is the tip, otherwise "what it is in r". | 21:46 |
| MvG | The problem is that I have to deal with multiple revisons of multiple files, which scales badly. | 21:47 |
| hazmat | basically you want the latest rev of the children of a directory at a given rev | 21:47 |
| MvG | One solution is walking history, looking at deltas, see when things were last modified. The other is looking at last modifications of files and trying to relate them via the graph. Neither is really cheap. | 21:48 |
| lifeless | MvG: you can paraphrase that as 'find the end of the subgraph with the closest (topologically speaking) changes to any fileid under (d,r)' | 21:48 |
| MvG | lifeless: To get the semantics clear: do you mean the "subgraph of changes" and the "end which is topologically closest"? | 21:49 |
| lifeless | subgraph of the revision graph | 21:50 |
| lifeless | bzr doesn't store changes | 21:50 |
| lifeless | and yes to the second question | 21:50 |
| lifeless | anyhow, I've speculated in the past about having a 'subtree revisionid' as well as the 'this item changed' revisionid on directories. | 21:51 |
| MvG | lifeless: Still, it's not it. If I branch, modify one file on one graph and another file on another graph, then merge the two, then I want the merge, even as it touches neither file, because only the merge makes the dir what it is. | 21:51 |
| lifeless | we don't have one today; such a thing would be a) constant, b) derivable | 21:51 |
| lifeless | MvG: you would get the merge under the definition I offered | 21:51 |
| MvG | The I still misunderstood the definition... let me have another look, it's getting late here... | 21:52 |
| MvG | With "subgraph of changes" I meant the subgraph by taking only the nodes that contain changes to a subtree. Was that your intention? | 21:53 |
| lifeless | no | 21:53 |
| lifeless | subgraph of the fullgraph | 21:53 |
| MvG | Restricted on what criterion? | 21:53 |
| lifeless | having the same contents of the subtree | 21:54 |
| MvG | Ah! | 21:54 |
| lifeless | conversely, the adjacent revisions must change the subtree | 21:54 |
| lifeless | Anyhow, this is something that you could cache. | 21:55 |
| lifeless | but I'd try to build a fast implementation of it first; if only so that your cache loading will be efficient :P | 21:55 |
| jelmer | jam: ah, cool | 21:56 |
| MvG | I know how to derive this informations by walking all deltas. That's the incremental way to do things, in contrast to recursing on directory tree structure from files to the root. | 21:56 |
| jelmer | jam: Is there anything I could play with yet? | 21:56 |
| MvG | But deltas feel more expensive than I would like. How expensive are they, when I don't actually calculate text differences, but just request the list of touched files? | 21:57 |
| jam | jelmer: it is still pretty early, but the code is up at lp:~jameinel/bzr/2.2.0b2-pack-collection | 21:58 |
| jam | and eventually lp:~jameinel/bzr/2.2.0b2-contained-pack | 21:58 |
| jam | It is pulling the "PackCollection" out of "RepositoryPackCollection" | 21:58 |
| MvG | What has me worried is the amount of data. Every commit would change the revid of the root. In most projects most commits would touch the src subdir. That's a lot of modifications, which made me think of this tree organization. | 21:59 |
| Mez | btw, I'll be (as long as it's approved) doing an "introduction to bzr" in a future Linux Format :D | 21:59 |
| lifeless | MvG: deltas are very fast | 22:01 |
| lifeless | MvG: we can walk 30K in a few seconds | 22:01 |
| MvG | Glad to hear that, then I'll be using those. | 22:01 |
| lifeless | specifically iter_changes | 22:01 |
| lifeless | there is a repository api to do iter_changes of many revisions | 22:02 |
| MvG | I plan to make the trac-bzr caching highly modular, to separate data generation from data access from data storage, and all of these from the rest of trac-bzr. Maybe that way parts of it can be useful to others as well, in a plugin to be shared with loggerhead or who else might be interested. | 22:06 |
| meoblast001 | hi | 22:07 |
| MvG | The only thing I now need is a lot of free time to implement this, which I don't currently have. | 22:07 |
| meoblast001 | with fast-export, how does one string a file/directory from a tree? | 22:07 |
| lifeless | MvG: make the bits bzr plugins then, IMO | 22:16 |
| lifeless | AfC: btw, 'bzr revert' in an svn checkout does what 'bzr revert' in a bzr branch would do | 22:16 |
| lifeless | AfC: you signed off too fast the other day, but I was about to answer your question with 'bzr revert' :P | 22:17 |
| AfC | lifeless: sure. I'm not using bzr-svn though, but thanks | 22:17 |
| MvG | lifeless: dunno. AT least for trac-bzr development, having them as part of that code base is easier, and avoids having to deal with a possibly misisng plugin. But I'll keep a bzr plugin future in mind, to ensure it can be moved one day. | 22:17 |
| === davidstrauss_ is now known as davidstrauss | ||
| millun | hi, just wondering... first time with Bazar explorer.... initiated a project... for a php thing in ~/work/bzr/tr. should i move there content of /var/www/tr/ or ../www/tr/* ? | 22:45 |
| dvheumen | hey lifeless, got a question for you for the high level locking hooks | 22:49 |
| === Peng___ is now known as Peng_ | ||
| lifeless | dvheumen: shoot | 22:54 |
| dvheumen | well, I'm wondering if there's any way to find out if a lock that's already active is a read or write lock. I'm kind of lost in the lockable_files/lock_dir and all the locking mechanism directly or via transport | 22:55 |
| lifeless | dvheumen: so lockable_files are always write locks | 22:57 |
| lifeless | dvheumen: read locks don't have a lock object | 22:57 |
| dvheumen | okay ... let me have a look at the code to see if that's all I needed ... | 22:58 |
| lifeless | but most importantly | 22:58 |
| lifeless | Branch etc always know what sort of lock they have | 22:58 |
| lifeless | queryable via e.g. is_read_locked() and is_write_locked() | 22:58 |
| dvheumen | I cannot find is_read_locked anywhere, and is_write_locked is only available for repository ... (or I'm grepping the wrong way ...) | 23:01 |
| dvheumen | anyways, maybe it's good to give you some context: I'm trying an initial implementation of the hooks in classes MutableTree, Branch and Repository. And I was working on triggering the callbacks on lock_{read, write, tree_write} and that's not too difficult. But for unlock and break I need to know whether I am breaking a read or a write lock, so how would you go about this? | 23:04 |
| dvheumen | lifeless: ^ | 23:06 |
| lifeless | dvheumen: why do you need to know ? | 23:07 |
| lifeless | dvheumen: and secondly, you know, in unlock, what the lock type was | 23:07 |
| lifeless | dvheumen: within each object type,t hat is. | 23:08 |
| lifeless | dvheumen: as for break, you can't break a high-level locked object anyhow, it always refers to a stale disk lock | 23:08 |
| dvheumen | lifeless: I was planning on reporting the type of lock during the triggering of the callbacks | 23:08 |
| dvheumen | okay, so there's no (sensible) thing as a broken lock hook for high level locks? | 23:09 |
| lifeless | well, there may be, but its not part of the lock/unlock sequence | 23:09 |
| lifeless | in aprticular there isn't a break-lock for read locks. | 23:10 |
| poolie | hello all | 23:10 |
| dvheumen | okay, so I'll scratch that. | 23:10 |
| dvheumen | hi | 23:10 |
| lifeless | dvheumen: as for the type - check the details of e.g. RemoteRepository.unlock | 23:11 |
| lifeless | dvheumen: you can see it knows the lock type | 23:11 |
| GaryvdM | Hi all | 23:15 |
| dvheumen | yeah I've seen the _lock_mode for repository before. And I now discover that there is peek_lock_mode for Branch | 23:15 |
| GaryvdM | I'm looking for info on the different exit status that bzr returns. | 23:15 |
| GaryvdM | I've greped the docs, and googled, but not found any thing. | 23:16 |
| GaryvdM | From testing: 0 = success | 23:16 |
| dvheumen | lifeless: okay, I think it's clear. Do you think there's any value in returning the LockResult instance that is used for the low-level lock hooks? (At least, I think it's still available, but I don't think it makes much sense.) | 23:17 |
| lifeless | no | 23:17 |
| lifeless | a) SvnRepository etc won't have them | 23:17 |
| GaryvdM | 1 = has diff (from diff) | 23:17 |
| lifeless | b) not all Bzr repos have them either | 23:17 |
| dvheumen | aha okay | 23:17 |
| lifeless | dvheumen: peek_lock_mode probably isn't what you want | 23:17 |
| GaryvdM | 2 = result has conflicts | 23:17 |
| GaryvdM | 3 = error | 23:17 |
| GaryvdM | Any thing I'm missing? | 23:18 |
| dvheumen | lifeless: isn't it? What's wrong with peek_lock_mode? I have seen that sometimes control_files are shared with the repository, but then the locking mechanism is shared too right? | 23:18 |
| lifeless | dvheumen: they don't track read locks | 23:18 |
| lifeless | dvheumen: in the general case | 23:19 |
| lifeless | dvheumen: uhm, that said - whatever works | 23:19 |
| lifeless | we haven't managed to delete self.control_files yet. | 23:19 |
| verterok | lifeless: hi, I'm tetsing xmloutput with latest bzr.dev, and I'm getting a bunch of this errors: http://pastebin.ubuntu.com/401439/ any ideas? | 23:22 |
| GaryvdM | bla - I was looking in the wrong place. Found some of what I was looking for @ bzr help diff | 23:22 |
| verterok | *testing | 23:22 |
| dvheumen | okay, well, I think that's enough info for me to continue with (some) implementation of the hooks. Is there any documentation on locking? (because I couldn't find much) | 23:22 |
| lifeless | verterok: thats fun | 23:27 |
| lifeless | verterok: I haven't been tracking bzr closely recently, so I can't really comment. poolie ^ ? | 23:27 |
| verterok | lifeless: :) | 23:27 |
| lifeless | verterok: AFAIK there is still only one branch reference around | 23:28 |
| verterok | lifeless: ok, I can poke vila, as this is tests stuff ;) | 23:28 |
| lifeless | so its got to be some sort of bug/regression in the way you're using bzrlib - unintentional I presume. | 23:28 |
| verterok | thanks | 23:28 |
| verterok | lifeless: found the problem, target_branch is now a kwarg :) | 23:42 |
| lifeless | did we move its position ? | 23:44 |
| lifeless | if so thats an api break, if we haven't done a stable release with the change we can fix it | 23:45 |
| dash | oh jelmer | 23:46 |
| dash | a checkout made using bzr-svn is exhibiting the behaviour described in #380069 | 23:47 |
| dash | would you like me to do things to figure out what happened? :) | 23:47 |
| dash | i'm using bzr 2.1 and bzr-svn 1.0.2 | 23:48 |
| dash | hup! too late. I did bzr up in another branch in the same repo and the problem went away. | 23:51 |
| verterok | lifeless: looks like it was moved. revno 5085 | 23:51 |
| dash | that's really annoying. | 23:51 |
| verterok | lifeless: hmmm, sorry it was a kwarg, but now a new kwarg is before it | 23:52 |
| * verterok brb | 23:52 | |
| lifeless | verterok: yes thats a move | 23:55 |
| lifeless | verterok: file a bug, and a patch please! | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!