[00:00] poolie: ok. I actually think it's pretty straight forward to add deep history support to usertest so I'll do that today after kicking off a conversion [00:00] poolie: I think its interesting to have deep linear too; because many conversions will be like that [00:01] sure [00:01] and in the short term, most huge histories will be conversions [00:01] yes, my repo came from svn, so it's essentially linear [00:10] i guess for ease of understanding the results we need to pick one main case to graph [00:11] I would say rather that we should be repeating on the same graph [00:11] we might have N big graphs to test, all different [00:11] testing N could be good, i'm just a bit concerned that if we produce too much output data it will not be read [00:12] well whats the audience [00:12] will the audience read 1, or N, or none ? [00:14] right now I don't look at usertest daily [00:15] I only look at such things when I'm a) deciding what to put in my pipe, and b) evaluating how I'm doing with my current changes [00:16] if you have someone who is trying to do a) on any of a number of scales, N graphs is little harder to read that 1, and better at detect regressions caused while operating on code for the case of b) [00:16] I'll wager that you have a similar use pattern [00:17] but that Ian, who is focusing on a) in a broad sense, daily, looks at it quite frequently. [00:28] http://www.smh.com.au/articles/2008/02/05/1202090393959.html <- hmm [00:29] i'm fixing a merge conflict to merge, and jam has a todo asking for the trace file to be line buffered so you can more easily read it [00:29] should i do a trivial change to have a debug option to turn that on, or yagni? [00:30] the trace file is buffered right now right? [00:30] for performance [00:30] yes [00:30] up to several kb, whatever is the python default [00:30] I've had no trouble tailing it [00:31] but if we change it yes, it should be a flag [00:32] oh, actually the comment is wrong, it is always line buffered [00:32] which is fine [00:32] thanks Teddy! :) [00:32] lol [00:35] hi, i'm looking at converting from svn to bzr. Does bzr support svn style properties? [00:35] mattimustang: I answered your question before; did you not see the answers ? [00:35] sorry i missed it and lost it in scollback :( [00:36] so it doesn't support arbitrary properties like svn? [00:36] 10:39 < lifeless> some yes [00:36] 10:40 < lifeless> is this for 3rd party extension, or for file-ending support on windows etc? [00:36] 10:40 < lifeless> (that is are you asking about 'generic stuff' or specific features) [00:36] 10:41 < foom> it doesn't support keywords or eol-style [00:36] 10:41 < lifeless> foom: yet; I have a plan. [00:36] thx [00:37] I have custom properties aside from what svn uses (keywords eol-style etc) [00:37] per file or per commit ? [00:37] per file [00:37] file metadata like unix permissions, owner, group [00:38] ok [00:38] well I'm designing a plugin to store those precise attributes [00:38] with a lookaside structure from the core [00:39] * jelmer wakes up [00:39] we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...} [00:40] this isn't entirely ideal, but making arbitrary properties DTRT all the time is rather tricky, when you have to consider performance-at-alarge [00:40] i really need the metadata to stay with the file it belongs to [00:40] yes, what I describe does that [00:40] files have uuid [00:40] if files move I don't want to have to update some other manifest elsewhere [00:40] a rename does not change the uuid (which we call file_id) [00:42] lifeless: wouldn't it make more sense to store it in a . file in the root of the tree? [00:43] jelmer: that makes it a user file [00:43] I wouldn't want to check out a 30000-revision branch with several thousand files that each have a couple of properties set [00:43] jelmer: remember the trouble with altering the representation of .bzrignore [00:43] so store it in a \0 file in the root of the tree? :) [00:44] a) we reject that filename, b) its the same problem [00:44] lifeless: .bzr/repository/fileprops.knit would be ok as well [00:45] jelmer: a knit? wtf [00:45] that's also how i'd like to see .bzrignore support [00:45] ed [00:45] well, a knit or a pack or whatever [00:45] it can be in the pack file as well, depending on your repository type [00:45] jelmer: in the broad sense you are saying 'this should be in the core' [00:45] lifeless: Yes, I am. [00:46] jelmer: and thats fine, I want to get something up and working as a plugin, then when its stable, design an appropriate extension to core to do it well. [00:46] lifeless: ah, ok. I hadn't seen you say that anywhere yet. That makes sense though. [00:46] as a plugin the goal is to work and be decoupled from repository format [00:47] figure out all the data needed, how it changes, what it needs. then design good storage. [00:47] so I'm thinking it will be slowish as a plugin, but easy to tweak [00:48] I would really like to avoid a "bzr setprop" kind of UI for setting these things btw [00:48] oh I cannot tolerate that ui [00:48] never happen [00:49] ok :-) [00:49] I mean, see my comments re the shell hook stuff [00:49] what would propose then? [00:50] lifeless: I think being able to write python should not be a requirement for being able to write bzr hooks. [00:50] mattimustang: well I made a suggestion, or do you mean about how to activate this feature for a branch ? [00:51] jelmer: I think our hooks and hg/svn hooks are different beasts. [00:51] lifeless: For commonly used hooks, those should definitely be in python. [00:51] jelmer: our hooks are gateways into the core library; like svn's baton passing. [00:51] well my original question was does bzr support it and it seems that it doesn't [00:51] the stuff you want should be done by specific adapters [00:51] s/commonly/installable/ [00:51] mattimustang: it has arbitrary properties that can be set per commit; you can build out what you want easily there [00:52] how would you do that per file then? [00:52] lifeless: For example, we check whether a commit message contains a specific line here at a svn repository [00:52] mattimustang: I already described it; you seem to think it wouldn't work. [00:53] lifeless: most people know shell and can write a two-line shell script that checks a commit message is valid. [00:53] jelmer: thats fine; do an adapter like I posted to the list for running make check. Then most users can write such a two line shell script [00:53] jelmer: this is entirely different from trying to write a FFI to shell for our hooks. [00:54] so that is still using svn main repo for checkins and hook script. ok that is fine i can understand that approach but what about going purely bzr? [00:54] mattimustang: huh? what I described was using bzr [00:54] my 2 line shell script for doing that exact function is actually a 116 line python script. :) [00:54] lifeless: Which thread was this? I don't think I've seen that. [00:56] 43 lines of which are a function called "get_cmd_output" which I use to call "svnlook log" and "svnlook changed", since the server doesn't have python 2.4 (and thus the subprocess module), and popen.* are terrible [00:56] you mention posting a pre-commit-check hook in the "Enhancing hooks" thread, but I can't find it [00:56] jelmer: 1202182868.659.144 [00:56] Config.get_user_section api [00:57] "(11:39:13 AM) lifeless: we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}" is that what you are talking about? [00:57] mattimustang: yes [00:57] ok [00:58] lifeless: I don't see how that is all that different from my shell hooks plugin [00:58] poolie: I did intend to have bzr-log-rss as part of the bzr project. I just wanted to allow someone else to have access aswell. I did the same thing for bzr-pqm-devel since James didn't want to be in ~bzr [00:58] got it [00:59] jelmer: I didn't claim it was. [00:59] jelmer: Ian posted work to create a generic FFI for our python hooks. [00:59] jelmer: I think that that is a bad idea. [01:00] lifeless: ahhh, ok. I see your point. [01:01] in short - some hooks that work well available for shell - great. [01:01] all hooks in shell - are you insane? [01:03] you think multiple fork+exec's for common operations would be a performance problem? [01:03] * fullermd is insane. [01:03] jamesh: we'll only pay that when someone has chosen to use a shell hook [01:03] lifeless: right, and there's not always an obvious conversion between python types and shell types.. [01:04] jamesh: so no, because we can and should also make it really easy to write absolutely trivial python hooks - by providing base class hook implementations that do most of the grunt work [01:04] lifeless: one thing that would be nice would be to centralise the hook registration APIs [01:04] lifeless: rather than doing some on SmartTCPServer.hooks, some on Branch.hooks, etc [01:04] jamesh: even when done centrally, those hooks would still only apply to some objects [01:05] jamesh: like the two like 'check a regex in the commit message' should be in python, about 8 lines - import regex, import a currier that takes a plugin name and looks for config stuff with that prepended, and then a simple 'get regex, execute it, return' [01:05] jelmer: I realise that. [01:05] jamesh: I don't actually like a single global registry; what is better about it ? [01:06] lifeless: well, the current system kind of works against lazy_import [01:07] lifeless: if I want my plugin to hook the SmartTCPServer, then every invocation of bzr is going to import bzrlib.smart.server once my plugin is installed [01:07] OTOH we wouldn't need lazy_import if python imports didn't suck so much [01:07] so I have on my todo list to fix that for bzr [01:07] and a pretty good idea about how [01:08] what else? [01:08] there's already packages which implement lazy module importing [01:08] lifeless: I guess that's my main complaint. A central hooks registry was a solution to that, but you've obviously thought of some alternatives that might be better [01:09] pkg_resources entry points? [01:09] lifeless: actually, the other one is discoverability of hooks [01:10] jamesh: I'd like bzr help plugins/hooks to dump them all [01:10] okay [01:10] jamesh: I think thats thats nicer because it allows plugins to add hooks themselves too [01:11] (not that a central place prohibits that, but because it doesn't lend it self to it quite as nicely if you think about it this way) [01:11] at the moment you have to dig through the code to find out where to register your hook, what the name of the hook is, and what arguments it should expect [01:11] yes, that sucks [01:11] also debug.debug_flags has the same problem === jam_ is now known as jam [02:39] * igc food === mw is now known as mw|out [04:04] * spiv -> late lunch [04:13] Can I not join ~bzr-log-rss-devel please? I get enough spam from Launchpad as is. [04:15] by spam, I mean bugs on bzr-eclipse, bugs on bzr-webserve, branchfeed, etc. [04:15] These are not projects I have ever been interested in. [04:35] when i "man bzr" i get this weird output http://www.pastebin.ca/893506 [04:35] Aloha, that's wierd, me too [04:36] but if I have my terminal maximized, it doesn't happe [04:36] *happen [04:37] Aloha, you should report the bug to the Ubuntu package (might also happen in Debian, dato?) [04:38] ok [04:38] Aloha, that would be https://bugs.launchpad.net/ubuntu/+source/bzr/ [04:38] beuno, thnx [04:39] I'm going to bed now, I swear :D g'night all [04:39] Aloha, thanks for filing it! [04:39] abentley: I've got a question about the bundlebuggy workflow... that's the pqm, right? so once a merge is approved there, it gets merged to the tree? [04:39] mtaylor: No, they are separate systems. [04:40] ok. so what happens once a merge is approved on bb? [04:40] mtaylor: A person with clearance submits it to PQM. [04:41] abentley: so there's still a manual step there then [04:41] mtaylor: Indeed, and frequently more. [04:41] Because many patches need to have conflicts fixed before they can merge cleanly. [04:41] ah [04:41] ok [04:42] and then the PQM system is the one that runs the unit tests before pushing to the tree, no? [04:42] bug filed [04:42] Yes. Technically it merges, runs unit tests, then commits. [04:42] cool. makes sense [04:43] The conflict issue has gotten a lot better since we started doing NEWS alphabetically, though. [04:44] So submit-from-bb isn't completely out of the question. [04:44] I tell you what, changelogs and news files really screw with merges in general :) [04:44] mtaylor: Someone should write a merge algorithm for NEWS and CHANGELOG files. [04:44] you could almost have bb submit and then ask for a re-submit if the merge didn't work. [04:44] abentley: I totally agree. I'd be in favor of that! [04:45] abentley: my debian/changelog files are always a problem [04:45] mtaylor: Great. Let me know when you have something >;) [04:45] :) [04:45] so bzr-pqm is just the submit-to-pqm plugin though, right? Is pqm itself released? [04:45] Yes it's an open project. [04:48] http://people.ubuntu.com/~robertc/pqm/ [04:48] abentley: awesome. thanks [04:49] is there any support for plugging file-type-specific merge algorithms into bzr? === asac_ is now known as asac [04:50] bob2: No, but you can write your type-specific merge so that it falls back to merge3. [04:50] General merge algorithms are pluggable. [04:51] ah [04:51] neat [04:52] abentley: so what if bob2 wrote a file-type merge algorithm, and I wrote a debian/changelog algorithm, and I had both file types in my tree? [04:52] mtaylor: Obviously, it doesn't scale. [04:52] :) [04:53] I did some work on per-file merge algorithms, but I didn't nearly finish it. [04:53] I'd say I'd think about it further, but I'm like 12 deep on my stack of non-essential work at the moment anyway [06:07] poolie: a fix for bug 185394 is on the list, if you'd like to review it [06:07] Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,Fix committed] https://launchpad.net/bugs/185394 [06:09] Oooh. Purdy. [06:32] thanks spiv === jam_ is now known as jam [10:20] herro [10:21] how do you get a diff of the local tree and the repository that includes any new files added locally? [10:22] mazzanet: have you commited those files ? [10:23] i don't have commit access to the repository [10:23] ie. i'm making a patch [10:24] diff should do it just fine in general (though it won't for binary files). [10:24] "bzr diff" will show the difference between your current checkout and the main thing [10:24] The usual answer, though, is jut to commit in a local branch. Then you can send a merge directive and keep all your metadata. [10:25] but this new-fangled distributed thing means you can create your own branch ;) [10:25] bzr diff isn't including the new files [10:25] Did you 'bzr add' them? [10:25] (bzr add will work even if you can't commit) [10:25] really? [10:25] crazyness [10:27] cheers [10:27] *dances* [10:29] bob2??? [10:30] Bob2!!! [10:31] jblack: Oh, hey there. Didn't see you come in. [10:31] I came in on tippy-toes. ;) [11:35] cprov too! wow [11:36] jblack: hi James. Good to see you again. [11:36] * jblack gets amazed by the people he sees when he crawls out from under his rock [11:36] hi jblack [11:36] Hey jamesh [11:38] jblack: and bob2 still has the hair ... [11:38] and denies that he plays goon of fortune [11:38] Heh. === mrevell is now known as mrevell-lunch === doko_ is now known as doko [12:47] jblack: Hi. [12:50] Hi [12:51] Aloha. [12:51] What colour rock have you been hiding under? [12:52] A black one, of course [12:52] it sounded funnier in my head. [12:52] Heh. [13:00] heh [13:01] hey jblack how's it going? === mrevell-lunch is now known as mrevell [13:29] hi [13:29] Pretty good. [13:31] New bug: #189567 in bzr "output to a terminal should default to using /usr/bin/pager" [Undecided,New] https://launchpad.net/bugs/189567 === zmanuel is now known as z-man === mw|out is now known as mw === _emgent is now known as emgent === brilliantnu1 is now known as brilliantnut === kiko is now known as kiko-fud === weltende is now known as welterde === statik` is now known as statik [15:12] anyone awake? [15:12] how can I get bzr to mark files with the current revision number? [15:13] hmmhh... like $rev$ or something? [15:14] yeah [15:14] synic: short answer, no [15:14] longer answer... http://bazaar-vcs.org/KeywordExpansion [15:14] you might look at "bzr version-info" [15:14] k [15:14] heh [15:14] But it is more about putting it into another file [15:14] ATM we don't change files for you on commit [15:15] alright [15:15] hmmhh... in future... is it possible to lock files? [15:16] if branch is checkouted [15:19] (or binded) [15:36] So I once had infinity rattle off a zillion commands at me explaining how to do this, but short term memory's always the first to go... [15:37] I've got a tree where I maintain an internal patch to upstream sources. new tarballs appear periodically, and I want to just incorporate that stuff and keep my set of changes on top. [15:37] infinity said there was a "maintaining a patch" section in the docs, but I can't find it [15:37] he mumbled about doing lots of imports from tarballs, but that seems to blat the whole tree out with the upstream files. [15:39] HI! I always swap "infinity" and lifeless in my head [15:39] hi lifeless [15:39] they're both so eternal [15:40] Spads: there is http://bazaar-vcs.org/TrackingUpstream [15:41] And I know there is "bzr import" provided by bzrtools [15:41] Generally, I would say you want to have a pristine branch of upstream [15:41] which your work is derived from in another branch [15:41] and then you go to upstream [15:41] update to the latest tarball [15:41] commit [15:41] then go to your branch [15:41] merge in the changes [15:42] commit [15:42] go on with your life [15:42] http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html [15:42] also describes that workflow [15:42] only with "upstream" being in svn [15:42] okay, this is close to what we were doing already. I may have misheard him as it sounded like he was talking about everything in-place [15:42] Spads: he has a plugin to do that [15:43] but I don't think it is fully released yet [15:43] ahaaaa [15:43] Last I read was that it needed a bit of polish, and should be released within the next month or so === kiko-fud is now known as kiko [16:19] hi... I have a local branch binded with a branch on a remote server. I'm using bzr+ssh URI. When commiting, I'd like the remote working directory to be updated at the same time... is it possible? Right now I have to issue commit locally, wait till it's finished and issue "bzr update" command on the remote server (I want to skip that 2nd part) [16:22] muszek: you can use the push-and-update plugin for that [16:25] jelmer: thanks [16:48] can I specify the path that I want to run bzr commant at? something like "ls -A /var/www" shows me stuff in a specified directory (not the one I'm currently at). Say I'd like to run something like "bzr update /var/www/myapp" [16:50] bzr update /var/www/myapp should work [16:50] muszek, yes, you can ;) [16:51] damn... It does work... I must have messed up something before. thanks and sorry guys. [16:51] Hi guys, I have a noob Q: I have a project on two machines that has a settings file that differs for these machines. Everything else is the same and needs to be kept in sync. [16:51] muszek, no worries ;) [16:51] Wonko, you can ignore that settings file [16:52] Wonko, bzr ignore [file] [16:52] But the settings file might change in the non-specific parts , is there a better way maybe? [16:52] thought about ignoring, but it seemed unelegant ;) [16:53] Wonko, perhaps you might want to split settings file to two separate files? One common, and one specific? [16:53] Wonko, and just ignore the common one? :) [16:54] @pygi: that sounds like a good idea. Mercurial has something called "Mercurial Queues" that allow me to "plug in" patches, which would sound ideal for my case. Does bzr have something like that? [16:55] ( Hg stuff: -> http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 ) [16:55] Wonko, gimme a moment to read it pls [16:55] I'm still thinking about where to move to from CVS, bzr or Hg (or maybe darcs) .. [16:55] sure, take your time, and THANKS! [16:59] Wonko, per-se, I don't think bzr has something similar, however I believe a plugin like that could be written [17:00] k, thanks so far! [17:01] Wonko, thank you, and dont hesitate to ask if you have more questions :) [17:01] i wish there was a way to have both, at once. [17:02] a revision history of the changes i actually made, *and* a sensible split into patches of the same changes [17:02] foom, that approach doesnt scale .... i.e. see darcs :) [17:02] pygi: ...just because darcs doesn't scale doesn't mean what i want is impossible. :) [17:03] true that foom :P [17:03] foom, you could write a bzr plugin that does that, anyway [17:03] no i couldn't [17:03] maybe someone could [17:03] hehe :) [17:04] but i don't even have a precise enough idea of what I want it to do to start. [17:08] is there a quick fix for a corrupted dirstate? [17:08] mine appears to be corrupt and i can't do anything on my tree [17:10] a quick fix would be "bzr branch " [17:10] but filing a bug report about that is probably a good idea, too [17:10] and we'd appreciate it :) [17:12] branching doesn't work [17:12] #186014 [17:12] Bug #186014 [17:12] Launchpad bug 186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/186014 [17:13] branch fails with the same error as e.g. diff? [17:14] pretty much everything fails [17:14] except for bzr info [17:14] and bzr log [17:14] umm, I'm pretty sure branch used to work [17:14] the last comment on that bug give the traceback [17:15] for branch [17:16] hmm [17:16] rm -r broken/.bzr/checkout && bzr branch broken fixed [17:17] but obviously backup the broken one before [17:19] but then i lose track of the my recent uncommitted changes on the tree [17:20] batoms: after that, you can move the .bzr/checkout from the new tree into the old one. [17:21] that did the trick, thanks [17:21] maybe there should some hidden command to regenerate the dirstate from scratch [17:22] jelmer: so i ran bzr svn-push, and it's been running for about 20 minutes so far, and I have no idea what it's doing or if it's going to work; is there any way to have it print some debugging info about what it's doing? [17:22] foom: If you run it with -Dcommit, it should write debug info to .bzr.log [17:22] sorry, ~/.bzr.log [17:22] luks: The reason why branch breaks here now is that branch uses the local tree if it can to accelerate the process. [17:23] luks: Perhaps we could hang it off 'reconcile'. [17:59] anyone knows some good article with arugments for using version control systems? [18:11] luks, foom: push should work fine with a broken dirstate, so we didn't have to delete .bzr/checkout (though we would have had to replace it). [18:24] hmmhh... trying to get bzr-svn work... and windows stuff is not aynmore located in http://home.comcast.net/~klight/bzr/ === abadger1999 is now known as abadger_afk [19:11] What is the proper way to migrate from git to bzr? The git plugin throws a scary traceback when I try to branch a local git repo. Tailor adds a gross SHA1 hash to the beginning of the commit messages. [19:12] ah, bzr-git has a separate branch with pull support. [19:12] marked "VERY EXPERIMENTAL", though... [19:13] should be fine for one-time conversion, I guess [19:13] (that is, not incrementally sync the git branch) [19:15] hello everybody [19:15] anyone knows why the smart server reports format unnamed when asked for info? [19:16] bzr info . (pack-0.92) [19:16] bzr info bzr://localhost => format: unnamed [19:35] luks, yikes, it won't even load. [19:35] AttributeError: 'GitRepository' object has no attribute 'base' [19:36] luislavena, you must have a pre 1.0 version of bzr, probably 0.9 [19:36] (on the smart server) [19:36] s/0.9/0.90 [19:36] beuno: nop, both 1.1 [19:37] anyway, i'm running on the same machine :P [19:37] oh, btw, windows... :D [19:37] luislavena, does "bzr version" output the same in both? [19:38] luislavena, oh, and you probably have to provide a full path to the smart server [19:40] beuno: mmm, I chdir to the path I want to share... and all the other information it returns seems ok... [19:40] (shared repository, branch info, even the push location) [19:43] beuno: nop, still the same, even with --directory pointing the same location. [19:43] weird, but it works. [20:06] http://rafb.net/p/0k9wig17.html [20:06] um... wtf? [20:07] so, he did a bzr merge from a merge directive... then did a bzr revert, then a bzr pull, then a bzr commit [20:07] and this is the resulting change [20:11] mtaylor: looks like the pull only brought in revision data, not text data === kiko is now known as kiko-afk === Gwaihir_ is now known as Gwaihir [20:45] New bug: #189709 in bzr "added-but-not-commited files which are removed go into weird limbo" [Undecided,New] https://launchpad.net/bugs/189709 === jam_ is now known as jam [21:15] hi, anybody familiar with the cvsps-import tool? [21:15] i'm not sure if i have enough to make it happen, or i'm missing something [21:15] my cvs fu is weak after years of not using it [21:36] johnny: sure what problem are you having though ? [21:36] exactly how much access to the cvs tree do i need? [21:36] since it doesn't seem to support :ext: or :pserver: [21:37] AIUI a copy of it [21:37] it needs to extract the ,v files [21:37] because you are converting history [21:37] I think you can use the non-local protocols if you --use-cvs or something. [21:37] so, not just a checkout ? [21:38] Probably a lot slower, though. [21:39] johnny: you can try --use-cvs as fullermd says [21:39] and no, it does not operate off of a checkout, it operates off of the repo === mw is now known as mw|food [21:40] syntax ? [21:43] I've always used it on local paths [21:44] well, i am working with a codecoop repository [21:44] a sf clone kinda thing [21:44] the nightly does seem to have a CVSROOT dir in it [21:45] Doesn't, you mean? [21:45] it does [21:45] untar that backup somewhhere then :) [21:45] yeah.. lemme try again [21:45] Oh. Yeah, working off that would be a lot quicker than trying to do it remote :) [21:45] i had problems with it [21:45] we're only talking less than 1000 revs, so either way.. no big deal [21:45] no complicated branching [21:45] etc [21:46] time is not an issue [21:48] here's what i have [21:48] ohnny@beep ~/projects/redemmas $ ls infoshopkeeper-scm-2008-02-06/ [21:48] CVS CVSROOT infoshopkeeper [21:49]