beunomwhudson, someday, we'll need to clear out all those merge proposals for loggerhead00:24
beunoI feel very bad for all the unused code  :(00:24
hazmatis it possible (via bzr-svn) to set a file property00:25
mwhudsonbeuno: yeah, me too00:26
* hazmat wonders if a web browser on a bzr repository can be fast00:33
lifelessI feel so fumble fingered on this new keyboard00:39
RAOFlifeless: Is that your new envy-inducing laptop of supreme power?00:41
lifelessits not actually /that/ fast00:41
lifelessas its a mobile edition, its relatively slow clock rate (2.13Ghz, idling at 1.2Ghz)00:42
lifelessbut the memory is really nice00:42
lifelessand the SSD is pretty zippy00:42
RAOFAnd it's quad-core, isn't it?00:42
lifelessbzr selftest --parallel=fork took 6 minutes00:42
lifeless2 core, with threads so linux sees 4 cpus00:42
RAOFAaah.  Still, 8gb of ram must be all sorts of fun.00:44
lifelessonce i finish bugfixing ubuntu-vm-builder I'm going to make a lucid VM for lp patches00:44
lifelessI've got 20G free, which is strange00:45
lifelessI had a 60GB disk in my old laptop00:45
lifelessrsynced across, and I have 86G used00:45
=== verterok_ is now known as verterok
lifelessthere 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 it00:46
MethsWhat laptop is this?00:47
lifelessMeths: my new one00:47
lifelessi7 640, 8G ram, 128G samsung SSD00:48
Methspretty sweet00:49
lifelessyeah :)00:49
pooliea separate vm so that it doesn't mess with your general system configuration?00:50
lifelessI dont' want pgsql and apache running when I'm flying to $destination00:50
lifelessand i'd forget to shut em all off if I had them installed-and-running by default00:50
pooliemm me too00:50
hazmatis it possible (via bzr-svn) to set a file property00:51
jelmerhazmat: no00:56
=== jelmer_ is now known as jelmer
pooliejames_w, we'd especially like to get it in for https://bugs.edge.launchpad.net/bzr/+bug/52198901:35
ubottuUbuntu bug 521989 in bzr "errors when importing WorkingTree on a thread due to signals" [Undecided,Confirmed]01:35
james_wah, hi01:36
james_wis it bugfix only?01:36
poolieour x.y.z, z>0 releases will always be bugfix only01:39
james_wpoolie: could you send me a mail and I will look tomorrow? IRC is too easy to forget.01:39
pooliefsvo 'always' i guess :)01:39
james_wshould be a 2 minute job for me in that case01:39
pooliethanks, i will01:39
james_wyeah, there's bugfix an there's bugfix :-)01:39
hazmatloggerhead needs alot of love02:00
mwhudsonhazmat: yeah02:02
hazmatmwhudson, is there anyone with dedicated time on loggerhead?02:02
mwhudsonhazmat: as much as anyone, it's me, but i've been doing other things lately02:03
pooliedoesn't max?02:05
lifelessdoesn't max what?02:05
mwhudsonpoolie: true02:06
pooliehave some time on loggerhead02:06
pooliei don't know if that's still true02:06
hazmata 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
PengAnother new templating language? Sounds fun.02:12
mwhudsonPeng: it's another implementation of the same one02:12
hazmatits a page template engine, almost entirely compatible with the existing templates02:12
PengOooh. Neato.02:12
mwhudsongod knows simpletal isn't very nice02:12
hazmatits mostly faster because it compiles out to python code, instead of a using a template engine interpreter02:13
PengFWIW, I wrote code to use Yahoo!'s aggregate JS file for YUI. Nothin' for Loggerhead's JS, though.02:13
hazmatit 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 parse02:15
lifelesshazmat: we don't use xml these days02:16
Penghazmat: Patches welcome. :P02:16
hazmathmm.. so perhaps the loggerhead whole history cache is uneeded02:16
PengSeriously, though, re-evaluating that is on the to-do list.02:16
hazmati notice trac-bzr doesn't bother with it.. it actually seems reasonably fast on a small repo02:16
PengNot all repos are small.02:17
hazmatPeng, i no.. i'm using the launchpad repo as my test case for performance analysis of loggerhead.02:17
=== mnepton is now known as mneptok
hazmatis there a way i can see what a pull will bring in without actually doing it02:59
Penghazmat: "bzr missing"03:00
hazmatPeng, thanks03:00
Penghazmat: 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
Pengpoolie: pm?03:01
PengI broke poolie. :(03:04
fullermdNow you have to take his place.03:06
parthmi looking at bug #304320 seems easy enough to add --clean-obsolete-packs option03:19
ubottuLaunchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,Confirmed] https://launchpad.net/bugs/30432003:19
parthmin order to actually delete the dir contents i am thinking of adding an additional parameter to transport.delete_tree that allows skipping delete for container03:21
parthmthis 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
spivparthm: I think that's reasonable.  You should add a per_transport test for the new param.03:30
parthmspiv: thanks for the pointer. i will add the per_transport tests.03:30
lifelessthere is functionality to delete the contents of obsolete_packs already03:30
lifelessPlease don't use the transport api to get at the private functionality of the repository - use that existing code instead.03:31
xnoxHello. How to use keywords plugin? I can't understand where do i need to place rules file03:32
parthmlifeless: where can I find this function? bzrlib.repository?03:32
lifelessparthm: bzrlib.repository.repofmt/pack_repo.py - somewhere in there03:37
lifelessobsolete packs is cleaned out when we do a pack - right before we do the pack.03:37
parthmlifeless: i see a private method, repofmt.pack_repo._clear_obsolete_packs.03:37
lifelessits a private task :)03:37
lifelessadd 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 manner03:38
lifelessits particularly unsafe to use over SFTP/HTTP/NFS03:38
parthmlifeless: i agree, i have added this to the pack command help.03:39
parthmassume_immediate_write sounds like a good way to do it.03:39
lifelessparthm: on the transport change, which might be nice in and of itself, how about 'children_only' rather than 'skip_container'03:41
lifelesscontainer isn't used elsewhere in the docs for transports03:41
parthmyes. children_only sounds good. maybe i should file it as a bug so it can be tracked separately.03:41
parthmi 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
lifelessthere may be a bug on that even03:44
parthmI 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
spivRepositoryPackCollection is not an implementation of the Repository interface04:05
spivIt's an implementation of ._pack_collection of (pack format) repositories.04:05
spivSo, the difference is different layers.04:05
parthmspiv: ah. i get it. so repository.pack internally maintains _pack_collection which it calls pack on. thanks.04:08
AfCAnyone know off hand the Subversion equivalent of `bzr revert`? Is there one?06:04
mwhudsonAfC: svn revert -R . ?06:05
AfChow did I not see that. Grrr06:06
AfCsorry. Thanks mwhudson06:06
lifelessmwhudson: 'bzr revert'06:14
PengYeah, use bzr-svn. :D06:14
parthmi am planning to add tests for bug #304320 to tests.blackbox.test_pack http://pastebin.com/C51qWKUH06:55
ubottuLaunchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,In progress] https://launchpad.net/bugs/30432006:55
parthmis the pack operation guaranteed to generate packs?06:55
parthmi am thinking of doing a transport.list_dir() and making sure its len is 006:56
parthmwith --clean-obsolete-packs06:56
lifelessparthm: its not guaranteed, no - but pragmatically thats fine07:03
lifelessjust do two commits, then a pack.07:03
lifeless(because one commit would be fully packed already)07:03
lifelessif, 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
parthmlifeless: right now when are the obsolete packs cleared?07:05
lifelessparthm: when bzr packs07:05
parthmlifeless: ok. i will go with the two commits approach. thanks.07:06
vilahi all!07:32
parthmvila: hi07:35
parthmis there a way to put a print in a test case and view it? selftest -v doesn't seem to do it.07:40
vilaparthm: if you're running blackbox tests, keep in mind that stdin/stdout/stderr are redirected....07:44
vilaparthm: which also means you can't put pdb breakpoints in the code run by the inner run_bzr07:45
parthmvila: 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
vilaparthm: try to write whitebox tests instead :)07:48
parthmvila: ok. thanks :)07:48
vilaparthm: they are generally far more precise and easier to debug too :)07:49
=== dcoles_ is now known as dcoles
dcolesjelmer_: 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
igchi vila08:43
vilahi Ian08:43
* igc dinner08:54
=== nlisgo_ is now known as nlisgo
jelmer_dcoles: yes09:03
dcolesjelmer_: Ah. OK.09:04
dcolesThen my other bug was when you try and serve git branches in a shared repo09:05
dcolesI'll make a working test and then report that.09:05
=== weigon_ is now known as weigon
=== jelmer_ is now known as jelmer
MvGlifeless: I just read your comment about the news_merge plugin in https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/2204511:56
MvGHadn't known there was such a plugin. Does pqm make use of it? I assume it does.11:56
MvGWhat 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
MvGI 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
MvGBTW: That config issue makes me think of another thing I've been repeatedly thinking about recently: handling of ZIP files.12:05
MvGThere 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
MvGI 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
MvGI 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 night12:22
=== salgado_ is now known as salgado
dipnlikhello, anyone here using zsh?12:28
MvGdipnlik: not me, but I'm still curious why you're asking.12:32
dipnlikMvG: i'm having autocomplete issues when i'm on a repository folder12:33
MvGI'm the one maintaining bash-completion-plugin.12:34
dipnlikcd ~/my-repo ; bzr st <tab> gives me an error12:34
MvGI 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
dipnlikbzr: ERROR: Not a branch: "/Users/dip/my-repo/.bzr/branch/": location is a repository12:34
* MvG is looking at the zsh completion script right now.12:35
MvGOK, 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
MvGdipnlik: 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
MvGdipnlik: zsh does execute "bzr ls --versioned", which should give you the same error message.12:39
MvGOf course, if you want to print the status of some file in some subdir, that would be a different thing...12:39
dipnliki'm on a repo with some branches on it12:40
dipnliki only wanted to autocomplete the branch name for the bzr ls command12:40
MvGIn my opinion, the zsh completion is either too clever, or not clever enough.12:42
dipnlikthat's what I think too12:42
MvGFor 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
MvGs/command arguments/command options/12:43
dipnlikthat's nice12:43
dipnlikso, I think it's more a zsh problem than a bzr problem, right?12:44
MvGI think it's a problem of whoever wrote the zsh completion script.12:44
MvGWhich seems to be Steve Borho in 2005.12:45
dipnlikouch >.<12:45
MvGJudging from the log, the script is unmaintained since then.12:46
luksisn't Steve Borho a TortoiseHG developer? :)12:47
MvGThe 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
MvGluks: There is some evidence to that fact on the web, yes. Can't say I know, though.12:50
luksyes, he is12:50
luksso there is probably little interest in fixing the script :)12:51
dipnlikMvG: any chance of a simple hack to at least avoid the error message?12:51
MvGdipnlik: Sure: redirect errors to null in _versionedFiles: fileList=(${(ps:\0:)"$(bzr ls --null --versioned 2>/dev/null)"})12:52
dipnlikMvG: i think I'll need more details to use that :(12:54
MvGOK, 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
MvGYou should have a copy of that file somewhere on your system, probably in a path mentioned in $fpath.12:55
MvGYou need to find and edit that file.12:55
MvGLines 48-53 of that file describe a function _versionedFiles, where line 50 does a bzr ls invocation.12:56
MvGAfter the --versioned but before the )"}) you insert a space and 2>/dev/null12:57
MvGThen you restart your zsh, and see if things work.12:57
dipnlikwill try that, thanks a lot12:58
MvGOut of curiosity: what makes you use zsh?12:59
dipnliktrying it out of curiosity and because it fixes my main problem with bash: the command history13:00
dipnliklet's say i have two bash tabs on terminal, one with tail something and other where I type all the commands I use13:00
dipnlikif I exit the "main tab" then exit the "tail tab", all history on the main tab is gone13:01
MvGdipnlik: "shopt -s histappend" should fix this for bash.13:02
dipnlikzsh promises to do other things better, but for now it isn't really THAT better13:04
dipnlikoh-my-zsh also makes some promises13:04
luksMvG: oh, thank you for that!13:14
MvGThe histappend? I think it should be standard on any system. It is on Gentoo.13:14
luksI always hated that it overwrote the file, but I just accepted it as a fact13:15
edakiriI have a 'parent' directory magically appearing.  Is it from bzr?13:17
luksappearing after what action?13:17
luksit's not any stadnard bzr directory13:17
edakirii 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
dipnlikare bzr vs. git discussions allowed here? i'm still not that into any of these but git seems to be overly complicated13:21
jelmerdipnlik: as long as they're discussions not flamewars :-)13:23
jelmerdipnlik: we'd be happy to discuss the differences in features of both systems and the advantages/disadvantages13:24
dipnlikjelmer: yay13:25
edakirihas 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 module13:26
dipnliki've seen comparisons and maybe git is technically better, but bzr is targeted for users, and that's a GREAT advantage13:28
dipnlikproblem is: "everyone" is using git :(13:31
dipnlikso I don't know if I learn both or if I go with the flow13:32
MvGdipnlik: 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
MvGlifeless: wrt my messages somewhere up there: just filed https://bugs.launchpad.net/bzr/+bug/54689913:37
ubottuUbuntu bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Undecided,New]13:37
dipnlikMvG: 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
edakiridipnlik: 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
luksdipnlik: from my experience, most people from "everyone" that are using git don't *really* know how to use git13:50
dipnlikedakiri: 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
dipnlikluks: 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 use13:54
dipnlikalso, github looks really great, maybe that is why "everyone" uses git13:55
luksdipnlik: I mean that most people using git are using git just because it's popular13:56
luksno any other reason13:57
dipnlikluks: 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
dipnlikit's nice to use popular tools sometimes14:01
MvGMy 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 bran14:15
luksdipnlik: git allows you to very easily screw things up14:24
luksdipnlik: other than that, it's not that bad14:24
dipnlikMvG: 1 and 4. i've no idea /o\ 2. here on bzr i have to add new files before commiting 3 and 5. agreed14:25
luksdipnlik: after you fully understand bzr, it should be easy to use git14:25
MvG2. only if they are new, not if they are just edited. The latter is much more frequent in most cases.14:27
dipnlikMvG: ouch, adding edited files is weird. is there a good reason for that?14:29
luksdipnlik: git uses a thing called 'index'14:30
luksit contains changes that are meant to be committed14:30
luksyou can change a file, git add it, change it again but only the first version will be committed unless you add it again14:30
luksgit add is really very different from bzr add14:31
MvGand 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
olyhi, can someone explain this error / how i can fix it ?14:31
olybzr: 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
MvGoly: What command did you execute?14:32
olyi well i tried a merge it said my tree was out of date so i tried a bzr update14:32
olyand got that message14:32
MvGoly: can you pastebin your whole session, starting at the first command causing the out of date error message?14:33
olytheres not really anything to it though14:34
olyis there a way i can force a merge it may overwrite what ever is causing the issue then14:35
MvGoly: Can you also add the output of "bzr info"?14:36
MvGoly: 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
olycould be, i do move between ubuntu lucid and karmic so the versions of bzr are likely different14:37
MvGOK, my assumption was wrong.14:37
MvGoly: 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
MvGoly: 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
olyhum it checked out okay14:43
MvGoly: 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
olydiff pyreplicator/ /home/om/Ubuntu\ One/reprap/software/pyreplicator/14:43
olyis that how i should do the diff ?14:43
olyi usually use meld and am only comparing individual files14:44
MvGdiff -ur pyreplicator pyhead14:44
MvGor prhead, or whatever you have named it.14:44
MvGI'd be particularly interested in anything mentioning the .bzr/checkout subdirectory14:45
olyis that on the new checkout14:46
MvGIt should exist in both places.14:48
MvGAnd differences might be an indication of what's causing your error.14:48
bialixjelmer: ping14:52
jelmerbialix: hey14:54
bialixjelmer: does bzr-svn supports tags a-la bzr tags?14:56
olydoes not look like theres anything noticably different other than the source files14:56
olywhich is why i am trying to commit them :p14:56
bialixjelmer: see Bug 54690614:56
ubottuLaunchpad bug 546906 in bzr-scmproj "crash for svn branches" [Undecided,New] https://launchpad.net/bugs/54690614:56
bialixjelmer: any suggestion how I should fix this in scmproj?14:56
jelmerbialix: yep, it does14:56
bialixjelmer: apparently other_branch.tags.get_tag_dict() where other_branch is svn://xxx does not14:58
dipnlikwell, i'm leaving, thanks a lot for the help everyone, i'll stick with bzr and bzr-svn :)14:58
jelmerbialix: only if you have a branch layout for which it is not known where the tags should be14:59
bialixjelmer: oh14:59
bialixjelmer: cause Guessed repository layout: TrunkLayout(0), guess layout to use: CustomLayout(['trunk/libavcodec'],[])14:59
bialixthat's it?15:00
jelmerbialix: TrunkLayout(0) puts all tags in tags/15:00
jelmerbialix: for a custom layout it's not known where to put the tags15:00
bialixjelmer: so... maybe I just should catch that error and suppress it?15:01
MvGoly: Those u1conflict files look suspicious to me.15:01
MvGAny idea where they might come from? How do they differ from those without the .u1conflict extension?15:02
olyokay, i dont think there in the repository at leat they should not be15:02
olythere cause when there is a sync error between my two computers15:03
olythey are generally the same file but a different version that did not sync15:03
MvGoly: I guess some such sync error garbled your working tree or branch.15:03
jelmerbialix: it depends on what you're trying to do :-)15:04
olyah, i did wonder if it could be todo with the file sync15:04
jelmerbialix: if you're pulling from that branch, I would just ignore the tags15:04
MvGoly: Safe thing would be, clone your branch and apply the source tree diff manually, without touching the .bzr dir.15:04
bialixjelmer: I'm checking if I need to pull first15:05
olyokay or maybe easier, can i just revert to the online copy ?15:05
olyand hit save in my editor again for the newer versions and then commit ?15:05
* bialix waves at amanica15:09
amanicahi bialix :-)15:09
bialixhi dude15:09
MvGoly: Revert to online using "pull --overwrite" might work, but I'd not feel as sure with that.15:09
olyokay, will have a play see what else i can break :)15:11
MvGoly: 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
MvGI meant modify at both ends and forget to sync in between.15:12
olyyeah i asked some one about it a while ago if it was likely to cause problem they suggest it would be okay15:12
olybut apparently not :p15:12
MvGis should be if you keep things strictly sequential, but that's hard.15:13
olyyeah, anyway fixed15:14
olyi had a better idea15:14
olymove the .bzr folder to tmp, then copy the .bzr from a newely checked out copy15:15
olythen run the commit :)15:15
MvGThat's fine.15:16
olysimple and seems to work which is what i like :)15:16
MvGWhen 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
MvGhttps://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045 in particular.15:22
olyThanks for the help by the way MvG :)15:22
PengUm...I'm not sure. You can push again and the merge proposal will be magically updated.15:24
PengYou can also file a new merge proposal, and that will magically handle everything too.15:24
MvGPeng: 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
PengIs it a bug that urlutils.local_path_from_url barfs on a "readonly+file://" URL?16:07
bialixPeng: I don't think it's the correct URL to use in local_path_from_url16:28
bialixreadonly+ is the prefix for bzr transport16:28
PengDo readonly transports have a copy of the URL without that prefix, then?16:32
PengPlus, IIRC the prefix is kept in Branch.base.16:32
bialixPeng: IIRC readonly transport is the wrapper for plain transport16:40
bialixso yes, there should be copy of URL w/o readonly+ somewhere inside16:41
MvGjam: Do you think I should mark bug 546899 as affecting PQM as well?16:56
ubottuLaunchpad bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Wishlist,Triaged] https://launchpad.net/bugs/54689916:56
jamMvG: reasonable to do so, I'm not really sure what would be done about it16:56
jamit is more that bzr's pqm setu16:56
jamit doesn't really affect bzr-pqm itself16:56
jamso on second thought16:56
jammaybe add bzr16:56
jambut don't add bzr-pqm16:56
MvGHmmm... hadn't known there was a bzr-pqm in addition to "plain" pqm... :-)16:58
jamah, sorry16:58
jampqm is the robot16:58
jambzr-pqm is a plugin to submit to the robot16:58
MvGAnd the robot should be the more likely one to complain about broken news, right?16:58
jamregardless, adding 'bzr' might be reasonable, but it is probably more of a sysadmin thing than a bug in the program itself16:59
MvGThere is no sysadmin subproject, is there?16:59
MvGCome 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
jelmerjam: hi18:31
jelmerjam: So, BtreeIndex seems very slow adding new entries after ~200k entries18:32
Peng200k entries? Are you doing something evil? :D18:32
jelmerI would never do evil things.18:32
PengYou use libsvn. :P18:33
jelmerSo does Google.18:33
jelmerAnd Google doesn't do evil.18:33
jelmerErgo, I don't do evil.18:34
jelmerQED :_P18:34
PengAh! Your logic is flawless.18:34
hazmathmm.. trac-bzr performs just as poorly as loggerhead on large repos21:11
hazmatworse actually21:11
mwhudsonthe cache isn't just there because i'm an idiot :)21:11
hazmatmwhudson, its interesting to see how performant bzr can be for a web ui without building a complete secondary index21:12
mwhudsonhazmat: the biggest problem is revision numbering21:12
hazmatmwhudson, 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
hazmatmwhudson, yeah.. i think thats what i'm seeing now.. still not 100% though21:13
MvGhazmat: what version of trac-bzr?21:15
hazmatMvG, trunk, with trac 0.11.721:15
hazmattrying it out on the launchpad repo21:15
hazmat110k revs it looks like21:16
hazmatpage loads are about 10s when it touches bzr21:16
jamjelmer: the code dumps data to disk21:16
jamyou can look at the builder parameter "dump keys at"21:16
MvGhazmat: OK, thats a large number of revisions for sure. What page are you referring to?21:17
mwhudsonhazmat: there is this bzr-historycache plugin that might help21:17
hazmatMvG, 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
hazmatmwhudson, 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 that21:19
MvGhazmat: 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
mwhudsonhazmat: ok, i can tell you that you will have a problem with revision numbering for off-mainline revisions without some kind of cache21:19
MvGhazmat: My current belief is that it is, but in many scenarios a in-memory cache would suffice.21:20
lifelessigc has a plugin for that21:20
hazmatMvG, yeah.. mwhudson mentioned that as well.. it does appear to be that (revid->revno mapping)21:20
MvGlifeless: caching those revs?21:20
jelmerjam: Thanks21:20
jelmerjam: 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
MvGhazmat: If you want to dig closer into improving trac-bzr using caches, we should have a longer talk.21:23
MvGI'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
hazmatMvG, 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 though21:24
jelmerjam: Also, I'm interested in looking at using bzr-based formats for bzr-svn21:24
jelmerjam: basically something like the revisions VF together with some bzr-svn specific indexes, how would I go about doing that?21:25
lifelessMvG: yes21:25
jamso, it depends21:27
jamI'm working on refactoring the code to do something like that for annotations21:27
jamso if you're willing to wait, it should be easier21:28
hazmatmwhudson, 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
jelmerjam: I'm happy to wait21:28
jelmerjam: This is intended for 2.3 ?21:28
MvGMy current idea is three caches, most easily explained in terms of relational database tables.21:29
MvGOne would be for the whole shared repo, and contain one line per revision. With date, revid, maybe some internal primary key, parents.21:29
MvGSecond 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
MvGThird 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
MvGBoth 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
jamprobably in the 2.2 series21:31
jamb1 is only this week21:31
lifelessMvG: 'what revs a fileid is present in' should be answerable pretty fast from 2a repos21:31
MvGlifeless: using what API?21:31
lifelessthe chk maps; probably not well exposed today.21:32
MvGBecause what trac-bzr does right now already looks painfully slow21:32
hazmatso 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
MvGlifeless: can you give me a fully qualified name pydoc will accept?21:33
lifelessMvG: bzrlib.inventory.CHKInventory21:33
MvGhazmat: So there is hope still. :-)21:33
lifelessMvG: its not a trivial thing; I'm saying that our core db format should be ok at this point21:33
lifelessso there will be somethinking needed21:33
lifelessand api improvements to show it 'publically'21:34
PengMvG: Loggerhead could use the same thing.21:34
MvGPeng: 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
mwhudsonMvG: no point caching that, get_revision is plenty fast21:35
PengMvG: Yes but it sucks. :D21:35
MvGAnd I found the implementation there so unreadable that I decided not to copy it to trac-bzr.21:35
PengMvG: Exactly!21:35
MvGmwhudson: 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
mwhudsonMvG: bzr has pretty efficent code for mapping strings to "stuff"21:38
MvGAnother 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
mwhudsonsure, some kind of hyperoptimized binary data type key value store might be faster21:38
mwhudsonbut not much and not enough to be worth the pain of keeping the cache up to date imho21:39
MvGSo that's one more item to store with each rev, not branch-dependant, and not suitable for the main bzr repo.21:39
MvGOr 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
MvGlifeless: Looking at CHKInventory, I realize that 'what revs a fileid is present in' is not the question I'm asking.21:43
lifelessMvG: what quewstion are you asking?21:43
MvGRather 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
MvGand "today" only if r is the tip, otherwise "what it is in r".21:46
MvGThe problem is that I have to deal with multiple revisons of multiple files, which scales badly.21:47
hazmatbasically you want the latest rev of the children of a directory at a given rev21:47
MvGOne 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
lifelessMvG: 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
MvGlifeless: To get the semantics clear: do you mean the "subgraph of changes" and the "end which is topologically closest"?21:49
lifelesssubgraph of the revision graph21:50
lifelessbzr doesn't store changes21:50
lifelessand yes to the second question21:50
lifelessanyhow, I've speculated in the past about having a 'subtree revisionid' as well as the 'this item changed' revisionid on directories.21:51
MvGlifeless: 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
lifelesswe don't have one today; such a thing would be a) constant, b) derivable21:51
lifelessMvG: you would get the merge under the definition I offered21:51
MvGThe I still misunderstood the definition... let me have another look, it's getting late here...21:52
MvGWith "subgraph of changes" I meant the subgraph by taking only the nodes that contain changes to a subtree. Was that your intention?21:53
lifelesssubgraph of the fullgraph21:53
MvGRestricted on what criterion?21:53
lifelesshaving the same contents of the subtree21:54
lifelessconversely, the adjacent revisions must change the subtree21:54
lifelessAnyhow, this is something that you could cache.21:55
lifelessbut I'd try to build a fast implementation of it first; if only so that your cache loading will be efficient :P21:55
jelmerjam: ah, cool21:56
MvGI 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
jelmerjam: Is there anything I could play with yet?21:56
MvGBut 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
jamjelmer: it is still pretty early, but the code is up at lp:~jameinel/bzr/2.2.0b2-pack-collection21:58
jamand eventually lp:~jameinel/bzr/2.2.0b2-contained-pack21:58
jamIt is pulling the "PackCollection" out of "RepositoryPackCollection"21:58
MvGWhat 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
Mezbtw, I'll be (as long as it's approved) doing an "introduction to bzr" in a future Linux Format :D21:59
lifelessMvG: deltas are very fast22:01
lifelessMvG: we can walk 30K in a few seconds22:01
MvGGlad to hear that, then I'll be using those.22:01
lifelessspecifically iter_changes22:01
lifelessthere is a repository api to do iter_changes of many revisions22:02
MvGI 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
MvGThe only thing I now need is a lot of free time to implement this, which I don't currently have.22:07
meoblast001with fast-export, how does one string a file/directory from a tree?22:07
lifelessMvG: make the bits bzr plugins then, IMO22:16
lifelessAfC: btw, 'bzr revert' in an svn checkout does what 'bzr revert' in a bzr branch would do22:16
lifelessAfC: you signed off too fast the other day, but I was about to answer your question with 'bzr revert' :P22:17
AfClifeless: sure. I'm not using bzr-svn though, but thanks22:17
MvGlifeless: 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
millunhi, 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
dvheumenhey lifeless, got a question for you for the high level locking hooks22:49
=== Peng___ is now known as Peng_
lifelessdvheumen: shoot22:54
dvheumenwell, 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 transport22:55
lifelessdvheumen: so lockable_files are always write locks22:57
lifelessdvheumen: read locks don't have a lock object22:57
dvheumenokay ... let me have a look at the code to see if that's all I needed ...22:58
lifelessbut most importantly22:58
lifelessBranch etc always know what sort of lock they have22:58
lifelessqueryable via e.g. is_read_locked() and is_write_locked()22:58
dvheumenI cannot find is_read_locked anywhere, and is_write_locked is only available for repository ... (or I'm grepping the wrong way ...)23:01
dvheumenanyways, 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
dvheumenlifeless: ^23:06
lifelessdvheumen: why do you need to know ?23:07
lifelessdvheumen: and secondly, you know, in unlock, what the lock type was23:07
lifelessdvheumen: within each object type,t hat is.23:08
lifelessdvheumen: as for break, you can't break a high-level locked object anyhow, it always refers to a stale disk lock23:08
dvheumenlifeless: I was planning on reporting the type of lock during the triggering of the callbacks23:08
dvheumenokay, so there's no (sensible) thing as a broken lock hook for high level locks?23:09
lifelesswell, there may be, but its not part of the lock/unlock sequence23:09
lifelessin aprticular there isn't a break-lock for read locks.23:10
pooliehello all23:10
dvheumenokay, so I'll scratch that.23:10
lifelessdvheumen: as for the type - check the details of e.g. RemoteRepository.unlock23:11
lifelessdvheumen: you can see it knows the lock type23:11
GaryvdMHi all23:15
dvheumenyeah I've seen the _lock_mode for repository before. And I now discover that there is peek_lock_mode for Branch23:15
GaryvdMI'm looking for info on the different exit status that bzr returns.23:15
GaryvdMI've greped the docs, and googled, but not found any thing.23:16
GaryvdMFrom testing: 0 = success23:16
dvheumenlifeless: 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
lifelessa) SvnRepository etc won't have them23:17
GaryvdM1 = has diff (from diff)23:17
lifelessb) not all Bzr repos have them either23:17
dvheumenaha okay23:17
lifelessdvheumen: peek_lock_mode probably isn't what you want23:17
GaryvdM2 = result has conflicts23:17
GaryvdM3 = error23:17
GaryvdMAny thing I'm missing?23:18
dvheumenlifeless: 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
lifelessdvheumen: they don't track read locks23:18
lifelessdvheumen: in the general case23:19
lifelessdvheumen: uhm, that said - whatever works23:19
lifelesswe haven't managed to delete self.control_files yet.23:19
verteroklifeless: 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
GaryvdMbla - I was looking in the wrong place. Found some of what I was looking for @ bzr help diff23:22
dvheumenokay, 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
lifelessverterok: thats fun23:27
lifelessverterok: I haven't been tracking bzr closely recently, so I can't really comment. poolie ^ ?23:27
verteroklifeless: :)23:27
lifelessverterok: AFAIK there is still only one branch reference around23:28
verteroklifeless: ok, I can poke vila, as this is tests stuff ;)23:28
lifelessso its got to be some sort of bug/regression in the way you're using bzrlib - unintentional I presume.23:28
verteroklifeless: found the problem, target_branch is now a kwarg :)23:42
lifelessdid we move its position ?23:44
lifelessif so thats an api break, if we haven't done a stable release with the change we can fix it23:45
dashoh jelmer23:46
dasha checkout made using bzr-svn is exhibiting the behaviour described in #38006923:47
dashwould you like me to do things to figure out what happened? :)23:47
dashi'm using bzr 2.1 and bzr-svn 1.0.223:48
dashhup! too late. I did bzr up in another branch in the same repo and the problem went away.23:51
verteroklifeless: looks like it was moved. revno 508523:51
dashthat's really annoying.23:51
verteroklifeless: hmmm, sorry it was a kwarg, but now a new kwarg is before it23:52
* verterok brb23:52
lifelessverterok: yes thats a move23:55
lifelessverterok: file a bug, and a patch please!23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!