[00:32] abentley: yay for DTRT for pipes [00:32] abentley: switch-pipe :prev, then merge --uncomitted :next :) [00:39] thumper: see, I'd prefer that to just be 'switch :prev' like it is in loom :) [00:40] lifeless: actually if I just did a switch :prev, then that would have worked too [00:40] ah! [00:40] lifeless: but since I had already typed `bzr prev` which I have aliased to `switch-pipe :prev` [00:41] it seemed easer [00:41] easier [01:14] hi all [01:23] hi igc [01:23] i forgot what i was going to ask you :) [01:23] :-) [01:27] poolie: was it about bug 539587? [01:27] Launchpad bug 539587 in null "search broken on bazaar.canonical.com web site" [Undecided,Invalid] https://launchpad.net/bugs/539587 [01:27] yes! i just realized that too :) [01:27] or maybe about the RT request? [01:28] no, about the site search [01:31] poolie: I can't recall changing anything about search search fwiw [01:46] http://jderose.s3.amazonaws.com/clouds_450p_5.ogv [01:48] whoops, wrong tab. ;) [02:14] poolie: so if you're totally happy with my sketch we can skip talking about it [02:16] i am happy actually [02:17] i don't have any objections and i think they would all be great things to do [02:17] and we will do at least some of them [02:17] i wouldn't say it's an exhaustive list of everything we will do, or be asked to do [02:17] btw do you have any brilliant ideas about https://bugs.launchpad.net/bugs/522637 [02:17] Ubuntu bug 522637 in bzr "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Confirmed] [02:43] hi people [02:43] I just noticed a 'dent about conceptual differences between hg and bzr [02:44] is there a doc somewhere to point them at? [02:49] http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-hg-users.html maybe [02:53] poolie: ta [02:55] thumper, yeah, whoever wrote bzr-pipeline was reading my mind :-) [02:56] :) [03:16] * igc lunch [03:51] spiv, igc, lifeless: perhaps the day has come to use a script to flip all bugs from triaged->confirmed? === spiv_ is now known as spiv [03:53] poolie: well, it's not causing me any direct pain that I've noticed, but if it's bugging you then go ahead :) [04:00] poolie: fwiw, a one-off bug spam like that isn't a big deal for me. [04:09] poolie: if you do that, please send a mail saying 'starting' and another saying 'stopped' [04:09] so I can just delete all bugmail in the intervening period [04:09] heh [04:11] imbni there was a wikipedia-like concept of 'this is a minor edit' [04:12] otherwise no objections? [04:13] * lifeless shrugs/ [04:16] putting pqm failures as attachments (not inline) in the comment stream might just be the killer feature for direct pqm integration [04:16] because it would mean the person who queues/approves the merge need not be in the loop to fix the failures [04:24] poolie: yes, that would be awesome [04:32] grabbing late lunch [06:31] huh [06:31] I run bzr upgrade on this branch, and it tells me "This may take some time. Upgrade the repositories to the same format for better performance." [06:32] i think that bug got fixed [06:32] running bzr 2.1.0 here [06:33] would the fix have been after that? [06:33] not that it's a big deal, just a little confusing [06:48] I don't think that was fixed in 2.1. [06:59] hi all ! [07:00] <_Andrew> Hi, I was wondering if anyone knew if this kind of thing exists in bzr and what it's called. I want to copy a file so that changes are tracked and applied to both the original file and the cloned file? [07:24] it does not [07:43] <_Andrew> doh :( [07:44] not sure that any dvcs does that [07:50] I think I heard once that hg has copy support. How much it DOES with it, I don't know. [07:52] <_Andrew> I think it's quite a useful feature because there is a situation where I want to update from a parent however the file I want to update needs to be split up so that the functionality is in one file and the html is in another. If I had a copy function then I think it should be able to still apply the parents updates. [07:52] <_Andrew> I'll look around. Maybe someone else is working on this for bzr [07:53] Well, sure it's useful. But it's not just the devil being in the details; he brought along 10,000 of his closest friends too, and they're having a raucous party. [07:53] <_Andrew> hehe [07:53] Conceptually, git's psuedo-ignoring of files has a chance of DTRT there. [08:17] hm, bzr tags in a branch of emacs upstream repo from http://bzr.savannah.gnu.org/r/emacs/trunk/ takes about 25 seconds.... [08:49] * igc dinner [08:55] hi, i'm thinking of versioning my project's libraries... [08:55] i read this: http://stackoverflow.com/questions/1710027/can-should-i-put-3rd-party-libraries-in-version-control [08:55] and they suggest that, while libraries should be versioned, it's better if they are in a different branch [08:55] so i looked at nested trees... [08:56] i could create one with split or branch of the library subdirectory [08:56] (is there any difference between these 2 commands?) [08:56] and then i could even join the subdirectory [08:57] the main purpose of "join" (if i'm not wrong) is that the commit on the parent tree, are recursed into the subtree [08:57] split and join are still experimental afaik [08:57] no [08:57] uh [08:57] i'm asking myself if i should branch it into a subdirectory or joining it however... [08:58] what do you use to version your libraries? [08:58] the internet [08:58] lol? [08:58] split and join don't really help with vendor branches [08:58] mhn [08:59] why do you say that? [09:00] (however please note that mine's a java project... and afaik in java world is quite common to not use the latest and greates version of an external library... just look at maven) [09:00] I guess join could help, actually [09:00] (so i'm not urged to update my lucene to 3.0 :) ) [09:00] don't java people just use maven for this? [09:00] many do... [09:03] ( i haven't really used it yet... i'm not even doing this for work: it's an university project... and i'm thinking of versioning my libraries only now that i've to leave this project to another guy, so at least he'll start with this problem already solved) [09:03] Tiibiidii: you can use either bzr-externals plugin or bzr-scmproj plugin [09:03] there is no built-in support for nested trees yet [09:03] mhn, i read about those... but it seems they were used a solution for when nested trees weren't yet supported [09:03] so split works, but join is not AFAIK [09:03] ah [09:04] that's strange [09:04] i mean: i should have a quite stable version of bzr [09:04] not a bleeding edge one... [09:04] I don't understand [09:04] and yet if i type "bzr help join" it doesn't warns anything about it not being implemented yet [09:05] jelmer: can i rebase part of a tree? i'm trying to work out why bzr is crashing during a rebase. it seems to do the first 2-3 commits, then bomb out [09:06] Tiibiidii: today join works as merge of subtree into parent tree. This is not what nested tree should be IMO [09:06] Kamping_Kaiser, No, there's no way to do a partial rebase at the moment. [09:06] * bialix waves at jelmer [09:06] hey bialix [09:07] heya jelmer [09:08] bialix: ok, thank you... i didn't really delved into nested trees documentation... however that's good news, right? (at least for my use case) [09:09] however do you suggest i should only split/branch it... or should i split+join it? [09:09] jelmer: ok. I'll leae that branch alone for a while. [09:09] split+join would be an incredibly pointless operation... [09:09] why do you want to use them at all? [09:10] you want to check out specific revs of your vendor branches [09:10] because using an integrated bzr tools seems more appropriate than using an external plugin like scmproj :) [09:10] Tiibiidii: what is your use case? [09:10] Tiibiidii: oh, c'mon [09:10] project, with some folders (most important among them: src/ and test/ ) [09:11] and then an unversioned lib/ folder [09:11] i want to version it [09:11] but i would prefer to version it in a separate branch [09:13] however fullermd, why do you say it's pointless? i mean: it's even suggested as an use case here: http://wiki.bazaar.canonical.com/NestedTreesDesign#id20 [09:13] (however, thank you all for the hints this far) [09:14] First off, that's a design doc for discussions about how to implement a feature, not anything remotely related to what the commands do in bzr. [09:14] So trying to take anything in it as suggesting things to do with bzr is chimeric. [09:15] uh... my bad: i thought that since split and join were present in bzr 2.0 they were working as in that doc [09:15] Not at all. [09:15] join implements "by-value" nested trees, which basically means it's equivalent to merging the other branch and mv'ing everything into the subdir. [09:16] using bzrlib, what is the (easiest) way to determine the last revision that modified a particular file? [09:16] A useful thing, but nothing at all like "by-reference" nesting, where you link to an existing but kept separate branch. [09:16] only really concerned with mainline revisions [09:16] ok [09:16] And split is a dangeous command, because your intuition about it usually doesn't match what it actually does. [09:17] uhm [09:17] You think of it as "take the history of just this subdir and make a branch of it" [09:17] yes [09:17] But that's a destructive operation. [09:17] (given that lib/ until now isn't yet versioned, that's not really a problem for me) [09:17] What it does is the same as "bzr branch existing new ; cd new ; rm ; mv ; bzr ci" [09:18] oh [09:18] Yeah, so it has no applicability there anyway. [09:18] (actually, split + join might have really scary consequences, since it would merge rm'ing everything, I think. But at best, it's an expensive no-op.) [09:18] rm <-- why does it do this? [09:19] Because if it didn't, you wouldn't end up with a branch looking like it was based at that subdir, you'd just have a copy of the existing branch. [09:25] mhn, using "bzr branch --use-existing-dir lib" would do what i'm aiming for? [09:25] No, that's a trick for saving transfer in certain cases. [09:25] If lib isn't versioned, none of this is meaningful. [09:26] (and if it's a versioned dir in a branch, you couldn't "branch" it anyway) [09:26] What's in it that you're trying to jump through all these hoops in the first place, rather than just add'ing it to the branch it's already in? [09:27] they taught me that adding big binary blob in a VCS (even modern ones, aka: after-CVS) isn't not a good thing [09:27] but since i want to version my libraries, i'd prefer to keep them separated [09:27] Well, it's not. But why do you want to... well, I guess it doesn't matter. [09:28] lol [09:28] why do i want to version my libraries? [09:28] Yeah. It's nutbar. [09:28] But if you want to, you want to. Retarded or brilliant, that's your problem, not mine :p [09:29] mhn [09:29] are you saying you don't version your libraries? [09:29] Just make 'em their own branch, and worry about burning the bridge of externals/scmproj/nested-branches when and if you come to it. [09:30] Well, what libraries? 3rd party stuff I happen to link, like libX11 or gtk or something? No. [09:30] My own stuff? Of course not. I version the source. [09:30] mhn, well... [09:30] If I wanted to do the former, I'd use vesta :p [09:31] if it where libX11 or gtk i probably wouldn't version it.... [09:31] i mean: that ones are quite common [09:31] on the other hand, sax, lucene, pdfbox, etc. are not [09:32] i mean: that ones are quite common <-- i mean for the target system... i guess one doesn't have the lucene .jar laying aroung if he's not developing something with it [09:33] See, that sounds more like you don't care about _versioning_ them, you're just trying to come up with a _deployment_ mechanism. [09:33] yes... but by versioning something it should even be easier to deploy it, no? [09:34] bzr pull, compile, and run [09:34] I doubt it. Would be a lot less efficient than `fetch -o- | tar xvf-` [09:34] fetch -o- ? [09:35] Well, "wget -o-" if you don't have fetch. Whatever. [09:35] mhn [09:35] so you mean [09:35] bzr pull, fetch, tar xvf, compile and finally run? [09:36] * fullermd shrugs. [09:36] No reason the fetching couldn't be part of the compile process. [09:36] uhm [09:36] make's all about building dependancies, after all. Fetching is a form of building :) [09:37] But in any event, I have a violent antipathy to use of VCS's as deployment mechanisms. Other people here don't have my pathology, so they might have more cogent advice. [09:37] but fetching is a complicated process, i mean: by fetching the latest version libraries something is almost guaranteed to break [09:37] mhn ok [09:37] i could even use maven [09:38] but that imho is overkill (at least for now) [09:38] Well, I was thinking in the sense of you providing a tarball like you'd provide the branch. [09:38] (and i would've to learn yet another tool) [09:39] mhn that's probably what i'll end up to :) [09:39] (i mean: for the only lone guy who'll continue my work that's not a problem... otherwise i should kept the tarball updated with the latest library changes) [09:45] however thank you all for the help [09:49] in the end i guess that for my next project i'll use maven and version the .pom [09:49] and for now i'll version my nbproject/project.properties that contains the libraries list [09:49] (i haven't versioned yet my ide config directory since i'm fairly certain that the next guy will use eclipse, and so the netbeans files will be of no use to him... and so i preferred to avoid cluttering my branch) === dcoles_ is now known as dcoles [12:00] Hi. Is there a way to have a setUp that runs only once for multiple tests. In the setup, I'm creating a tree, and in the tests, I do some read only operations. [12:03] This is my test: http://bazaar.launchpad.net/~garyvdm/qbzr/538735-treewidget-filter-ignored/revision/1212 At the moment, its one test. I want to split it up, so that I can see if more than one Is going to fail. [12:22] GaryvdM: hi [12:23] GaryvdM: AFAIK, no [12:23] what's the problem? [12:24] bailix: Hi. I only want to create the tree once for performance reasons. [12:26] ok, I see [12:27] GaryvdM: you can try to override __init__ but I think this is not recommended way [12:27] maybe vila knows? [12:28] :-) [12:28] GaryvdM: you can't [12:29] heya vila [12:29] the main reason is to ensure that bugs don't propagate from one test to the other [12:29] bialix: hey :) [12:29] Hi vila [12:29] So should I just split it up, and not worry about performance? [12:30] GaryvdM: otherwise you may want to look at lp:testresources which intent to address that [12:30] GaryvdM: exactly [12:30] * GaryvdM looks [12:30] GaryvdM: the long term plan is to be able to have wt fully supported in memory so we don't have to pay the IO penalty [12:31] Thats cool. [12:32] GaryvdM: and sorry for not replying to your mail about 'QBzr test I just wrote' :-( It still flagged as 'needs to be acted upon' though... [12:33] vila: No problem. I just wanted to let you know I made some progress. [12:34] Recently, I've been writing lots of tests for qbzr :-) [12:34] GaryvdM: That's great ! [12:35] GaryvdM, bialix : Out of curiosity, how do you hack on qbzr ? Always using the trunk version ? Switching between branches ? [12:37] Vila: Mostly, just on trunk. For big features I create a feature branch. [12:38] GaryvdM: and how do you *use* that feature branch ? swapping the installed one with yours ? [12:43] vila: I have a dir structure like this: http://pastebin.org/116211 [12:44] vila: When I'm deving, I export BZR_PLUGIN_PATH=~/qbzr/wd/ [12:45] All editing happens in ~/qbzr/wd/qbzr/ [12:46] Poor mans co-located branches. [12:47] * GaryvdM -> lunch [12:47] GaryvdM: beware: you have two featureA branches :-) [13:24] Vila: It would be cool for plugin authors to be able to do somthing like BZR_PLUGIN_PATH=;qbzr=~/qbzr/featureA [13:25] I'm sure that I would do feature branches more if I could do that. [13:25] GaryvdM: how about BZR_PLUGINS_AT=qbzr@~/qbzr/featureA ? [13:25] GaryvdM: let me see if I can write a quick patch for that [13:26] Vila: Yes, Thats the idea. [13:26] GaryvdM: here you are: https://code.edge.launchpad.net/~vila/bzr/82693-plugin-at-path/+merge/21547 [13:26] :-P [13:26] :-) [13:26] GaryvdM: tests and feedback welcome (I'm not sure ~ is supported, but it should be easy to add) [13:29] bbia === mrevell is now known as mrevell-lunch [13:42] vila: I'm using colo plugin [13:44] before colo plugin I've used just light checkout of several branches in shared repo. so it was almost the same as colo, but separated in 2 directories [14:00] Hi vila. bialix said while you were away: http://pastebin.org/116280 [14:13] oops === mrevell-lunch is now known as mrevell === salgado is now known as salgado-lunch [16:13] hi, how can i clone all of these branches? https://code.edge.launchpad.net/~mwhudson/pypy/ [16:14] bialix, GaryvdM: I thought I read somewhere that it was possible to use ctfl-F for searching in qblame but no luck so far... [16:15] bialix, GaryvdM: Did I dream or is it part of a wip ? [16:16] xorAxAx: There is no trivial shortcut. You'd have to make a list and do each one. (Into a shared repository, obviously) === beuno is now known as beuno-lunch [16:16] maxb: how do i ensure that it is a shared repo?` [16:17] A shared repo is what you create using 'bzr init-repo' [16:20] maxb: and how do i clone into the shared repo? [16:20] Any branch newly created under the directory of a shared repo will use it [16:20] ah, magic [16:20] ok [16:21] Note that this is just a storage/bandwidth optimization, to avoid storing/transferring the common history between branches multiple times [16:23] wget -nv -O- "https://code.launchpad.net/pypy/+branches" | html2text -ascii -nobs -width 300 | sed -nr 's/.* (lp:[^ ]+) .*/\1/p' [16:23] xorAxAx: ^ may be of use to you [16:23] cool! === IslandUsurper is now known as IslandUsurperAFK === beuno-lunch is now known as beuno === IslandUsurperAFK is now known as IslandUsurper [17:05] vila: lp:~garyvdm/qbzr/annotate_find [17:06] vila: wip [17:08] vila: wip because I want to make that ui change to all browse dialogs before I land it. If you don't mind that, It is compleatly usable. [17:10] GaryvdM: I'll try it (and hope I'll remember to track when it lands...) that's my most wanting feature [17:10] GaryvdM: well, that and being able to do bzr qblame :-P [17:12] vila: That branch also has a gotoline (ctrl-g), but no command line option. [17:12] GaryvdM: I see that, cute :) [17:13] err, I can't type anything in Goto Line box [17:13] * GaryvdM looks [17:14] .. but got a nice error dialog if I press the Go button about: invalid literal for int() with base 10: '' :-D [17:14] incremental search.... rhaaaa lovely [17:15] hmm, no short-cut for previous/next ? [17:18] vila: For me I can type numbers into the goto line box. [17:18] vila: I get that error I type nothing in. [17:18] GaryvdM: Do you have a numeric keypad or are you typing from the upper row ? [17:19] neither works in my case anyway [17:19] :-( Keypad does not work. Using upper row. [17:19] weird [17:20] GaryvdM: you checked your num-lock right ? [17:21] pasting doesn't work either, that kind of rules out a keyboard problem [17:21] vila: I'm just doing : [17:21] self.line_edit.setValidator(QtGui.QIntValidator(1, sys.maxint, self.line_edit)) [17:22] GaryvdM: Anyway, it's already useful as-is, I usually *know* the line number because it's there in an emacs buffer but generally I'm searching for some text, so incremental search is a real plus [17:22] vila: I'll make a note about that. [17:23] GaryvdM: commeting this line is enough to make it work ;) [17:24] But you should also bind to the Go button ;) [17:24] Yes [17:26] Hmm, I have go.setShortcut((QtCore.Qt.Key_Enter)) , but it's not working [17:29] hmm, I think you should do that on text entry [18:40] Any bzr-svn people around? [18:47] ascii_phil, yep [18:50] bzr-svn is refusing to do a commit because it would change the mainline history. I think the commit should be a straight append. Is there any way to tell what changes bzr-svn wants to make to the history without actually doing it? [18:51] The commit is going from a local Bazaar repository to a remote Subversion repository. [18:56] ascii_phil: What does "bzr missing" say ? [18:59] Three extra local revisions, no extra remote revisions. The first of the three local revisions is a merge from another local Bazaar branch that's been pushed to a different Subversion branch. [19:00] That may be confusing. I have two bzr branches: one synced with a project's trunk and another synced with a branch of that project. [19:03] I did some work in the dev branch, pushed it to svn, merged the dev work into the bzr trunk, then pushed the merge into the svn trunk. Following that, I pulled from the bzr trunk into the bzr dev branch (maybe I didn't need to do that?) and put another two commits into the dev branch. Now the bzr dev branch won't push to the svn dev branch. === radoe_ is now known as radoe [19:24] is there an equivalent to "git format-patch origin/HEAD" in bzr? [19:25] timClicks: bzr send is the analogous command [19:25] james_w: ty [19:31] ascii_phil: strange, sounds like that shoudl work. Try 'bzr vis' and see if it reveals some non-linear history? [19:34] It looks reasonable. Lemme take a snapshot. [19:39] Here's what `bzr vis` gives me: http://imgur.com/cM1gK.png . [19:41] so those blueish/purplish dots were done in another branch, then merged in to this branch. [19:41] were either of the 2 revisions after those from SVN? [19:41] Oh, wait, you said you merged from trunk into your dev branch. [19:42] so those colored dots are from trunk. [19:42] I merged those 8 blue dots from this branch into the trunk. Then I pulled from the trunk back into this branch. [19:43] ah, that's why. [19:43] Now I think I see the problem. bzr had no problem stuffing what were toplevel commits into a merge commit, but that's not compatible with Subversion. [19:43] because the history in trunk has a different order from the history in your branch. [19:44] So I'd be okay in this case if I *didn't* pull the merge back from the trunk. [19:44] right. By pulling trunk, then trying to push it to your dev branch, you'd be reordering the history in your dev branch to look as if it were trunk. [19:44] right. Instead, *merge* back from trunk. [19:44] the merge from trunk will be appended to the end of your history, and that can be pushed back to SVN. [19:45] FYI... you CAN push this to svn if you use a --force (or --override?) flag, but bzr-svn stops you because that sort of history is REALLY wacky to read in a SVN repository. [19:45] so bzr-svn is just trying to protect you in that respect. [19:46] Your other option is to just delete your dev branch and re-create one from trunk. [19:47] Yeah, the error message includes an option to change to let it go ahead, but I really don't want to rewrite the Subversion commit history. [19:47] good call. :) [19:54] Awesome. I rewound the branch's history, did a merge from the trunk instead of a pull, and was able to push my new commits up to the Subversion branch. [19:54] Thanks! [19:54] no problem. [21:00] has anyone tried to install bzr on apache with mod_fcgid? [21:00] all i get is (146)Connection refused: mod_fcgid: read data from fastcgi server error. [21:07] paris: Erm... install bzr on apache with mod_fcgid to do what? [21:07] serve out a branch? [21:08] if got a base directory that has /admin and /code, admin for cgi script, code for all sub dirs [21:09] and beneath that are the results of init, so not sure if u'd consider that a branch or not, still wrapping my head around this concept [21:10] paris: what happens when you run bzr-smart.fcgi from the command line [21:10] so code/projects/myproject/stable, code/projects/myproject/dev [21:10] well, before you try to wrap your head around the concept, what are you trying to accomplish? [21:10] it complains that request_uri isn't set, which seems like an acceptable error [21:10] we have a svn repo, and want to gradually convert [21:10] (repos), want to have central repo capabilities, but allow for distributed local copies [21:11] as well as play around with foreign branching to accomodate current build tools [21:11] paris: Much eaiser to serve branches with sftp [21:11] wanting to serve through apache to use existing auth methods [21:12] paris: I see [21:12] right now, its all on a nfs, so we could access directly, but i'd like to do everything through http(s) [21:13] paris: what happenes if you run bzr-smart.fcgi from the command line? [21:13] the only sense i can make of that error, is the script is firing properly, which i dont know if is due to mod_fcgid compatability or a configuration error on my part [21:13] I'm trying to branch from launchpad and I am behind a http/s proxy - do I need to build bzr 2.1 for this to work? [21:13] it complains that request_uri isn't set, which seems like an acceptable error [21:14] paris: please paste bin the whole error. [21:15] i think i made progress, had to chmod +x the fcgi file [21:15] bzr: ERROR: Server sent an unexpected error: ('error', "Can't extract file(s) to egg cache\n\nThe following error occurred while trying to extract file(s) to the Python egg\ncache:\n\n [Errno 13] Permission denied: '/.python-eggs'\n\nThe Python egg cache directory is currently set to:\n\n /.python-eggs\n\nPerhaps your account does not have write access to this directory? You can\nchange the cache directory by setting the PYTHON_EGG_ [21:15] looks like i need to do some environment cleanup [21:16] if anyone has access to that wiki page, be nice to add a note to chmod the fcgi script, though I assume people are familiar with fastcgi would expect it to be known [21:18] paris: url? [21:18] for wiki page... [21:18] http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html#pushing-over-bzr-http [21:19] paris: Ah that doc is from the bzr source. [21:26] also not sure why python_egg_cache set env isn't being passed down to python ( i added a shebang at the top of the fcgi to point to python, so perhaps its not inheriting system env? ), but i chowned /.python-eggs and it works now [21:43] so for the svn plugin, am i able to run something like, "bzr branch http://my.svn.repo", and if i commit, it goes local, and if i push it goes to the bzr repo, but if i commit, it goes to svn? [21:43] assuming bzr branch is done beneath the init-repo [21:45] What? [21:45] commit and push are the same as any other bzr branch. === salgado is now known as salgado-afk [21:59] i guess i asummed that you could branch off of a svn branch, and work on it locally [21:59] and only "push" the changes to svn when you wanted to [21:59] You can. [21:59] put pushing, would go to ur bzr branch [21:59] where submitting would go to svn [22:00] Pushing goes to the parent branch. I'm not sure what exactly you're asking. If the parent branch is an svn branch, that is where it will go. [22:00] gotcha [22:02] you can even do: svn -> bzr -> 2nd-bzr-branch -> push back to original SVN repo. [22:02] yeh, for some reason i wasn't thinking about the branch in the middle [22:02] It works quite nicely. :) [22:02] so our "central "repo, would branch svn [22:02] then u branch that branch [22:03] going to be quite the ride trying to get our CI servers to use bzr, but i'm really liking how its all setup [22:49] paris: what CI do you use? [22:54] lifeless: quickbuild [22:55] we've had luntbuild, played with hudson/bamboo/cruisecontrol, etc but they are too simple [22:57] wow [22:57] you must have pretty intesnse hneeds - hudson is extremly capable of just about anything [22:59] lifeless: how heavy is hudson? could I run a master and slave in 360MB of ram (assuming test suites take negligible amounts)? [22:59] I used to think hudson was great, but I've grown somewhat disenchanted with it now it takes 20 minutes to restart, because it's sitting there parsing all of its on-disk XML [22:59] I haven't directly used the others; I know a bamboo dev, but I don't imagine that menans a lot - the lead time on infrastructure changes could be pretty big in dev-cycle time [22:59] bob2: dodgy [23:00] bob2: would depend on how many plugins you have I suspect [23:00] maxb: set a retention policy for jobs is one workaroundl; the other is to wait for em to fix it :P [23:01] lifeless: dang [23:01] 360MB is barely enough to run a browser [23:01] :P [23:02] having build configurations with inheritance, is very powerful [23:03] we can just create a new configuration to follow our svn naming pattern, and depending on where we place it, it can do deployments, release management, etc [23:03] haha, just wanted to not pay a lot to host it [23:03] intersting [23:03] uhm, I suspect there is something /like that/ in oe of the job parameterisation things [23:04] bob2: we're currently running it on a cheap linode, and its happy enough [23:04] bob2: I'm currently doing the migration to move it into the dc [23:04] paris: anyhow, we'll be delighted to help you get it using bzr [23:04] (it == quickbuild) [23:05] lifeless: thanks :), its really just a matter of some ant scripts with command line, i tend not to depend on gimmies from CI systems because it locks you into their build process [23:05] let alone take the time to build a plugin to support a new VCS [23:07] ok, time to fly. ciao. [23:22] hello all [23:22] Morning. [23:32] hi spiv [23:32] ascii_phil, still there? [23:34] morning [23:35] how do I find out the last revision id that a particular file was modified in? [23:35] mainline revision id is fine [23:35] thumper: bzr log some/file? [23:35] Peng: using bzrlib? [23:35] I don't care about the history, or what changed [23:36] just the revision id of the last change [23:36] Sorry, I dunno. [23:38] thumper: Something like: [23:38] tree.inventory[tree.path2id(path)].revision [23:39]