[00:12] lifeless: aware of a simple way for automated installs of different bzr versions? [00:13] bzr branch? [00:13] (im trying to refactor anyvc's tests to check multiple versions of the different vcs's if possible) [00:14] ronny: just don't install bzr, if you are using bzrlib, set PYTHONPATH, if you are running the command line, just run the bzr in the source tree [00:14] hmk [00:16] rationale - bzrlib isn't versioned, short of lots-of-magic-with-eggs, you can't have more than one installed at a time [00:36] igc: hi [00:38] hi jelmer [00:40] igc: You mentioned on the list you're working on a patch to support custom rules [00:41] jelmer: just about to. See http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/51347 [00:42] jelmer: let me know if that sounds ok to you [00:46] igc: I like the flexibility [00:46] igc: though it also means local configuration is *always* required when using keywords/eol-conversions [00:47] igc: and this doesn't e.g. allow for use of rules set in svn [00:47] jelmer: can you explain further? [00:47] igc: How do filters interact with diff -r x..y? [00:47] jelmer: I was hoping we could ... [00:48] do something like "rules_location = svn:..." [00:48] lifeless: diff should apply to the canonical text, not the text in the working tree [00:48] igc: ah, hmm [00:48] igc: that seems like overkill though, as you would set that to the same location you've just checked out [00:48] external diff tools are an issue though [00:49] igc: ok; I was just considering the case of dealing with versioned files [00:49] igc: and that would require on-line access to the svn repo [00:49] versioned rules [00:49] I'm still extremely nervous about them, I don't think its thought out enough [00:50] IMHO ideally rules should be a per-tree versioned setting, while not being part of that tree itself. [00:50] and access to them abstracted away [00:51] jelmer: my concerns are about things like 'merge' when the rules change [00:51] do we read via old rules and write via new correctly? and what if they conflict [00:51] (that's non-trivial to achieve though, so I understand we should support look at other solutions in the short term) [00:51] s/support// [00:52] or pull, as a simpler case to analyse [00:52] igc: I'm really glad the core filter support has landed [00:52] jelmer: my immediate concern is to support something better than "just global" rules [00:52] lifeless: thanks [00:52] igc: Yes, I agree [00:53] jelmer: while allowing you ... [00:53] to do something smarter when you can [00:53] igc: so, the main thing I'm worried about is if we introduce things now that will prevent the utopian situation I mentioned earlier from happening [00:54] igc: putting a magic .bzrrules file in the tree would make it very hard to get to that situation at some point [00:54] igc: Your current proposal doesn't appear to [00:54] jelmer: I feel the rules_location setting solves many problems. It's a technical solution that still needs good guidelines around it, of course [00:55] jelmer: but I'm convinced that we just can't answer everyone's desires here [00:55] igc: Sure, I understand. I think the current proposal is reasonable [00:56] I like the concept that bzr won't magically handle the versioned file in the tree before we are ready to do that [00:57] lifeless: me too [00:57] jelmer: are there tweaks to my proposal that would help you? [00:58] jelmer: btw, there's no default - if rules_location isn't set, then just global rules apply [00:58] jelmer: importantly though, rules_location can be set in locations.conf and re-used across a bunch of branches [00:59] igc: No, I don't think there's much that can be done to support bzr-svn other than moving to per-tree (but not in-tree) rules [01:00] igc: My main worry was your proposal would add a in-tree .bzrrules with a magic meaning (much like .bzrignore), since that would pretty much prevent moving to per-tree rules in the future [01:01] jelmer: so perhaps tree.conf is what you want? [01:02] jelmer: there will be no magic .bzrrules file, though some projects may decide to put their rules in such a file and set rules_locations to pint to it, of course. *But* it's just a path - it could be called anything and put anywhere [01:02] s/pint/point/ [01:03] igc: For svn, the rules would have to be a property of a Tree object, including RevisionTree objects [01:03] jelmer: my expectation is that many people (e.g. me) will put rules in the shared-repo directory, i.e. above the branch directories [01:04] jelmer: from memory, the API for looking up rules is on Tree, because rules are path dependent [01:05] igc: But they're not stored as part of a Tree atm [01:06] bzr-svn can import rules for historic svn revisions, but it isn't involved for the working tree [01:06] igc: please make info [-v?] print out the rules config [01:06] jelmer: right [01:06] lifeless: shall do [01:07] I just mean the value of the pointer, not all the rules - just thinking fordebugging with users [01:07] lifeless: yes, that's what I thought you meant [01:07] :) [01:08] james_w: ping [01:14] igc: anyway, even if we can't import rules from svn yet, we can support svn keywords now (-: Thanks! [01:20] jelmer: well, keeping in mind that our keywords aren't a one-for-one match with svn's ones, yes [01:22] igc: Yeah, but filters should allow the bzr-svn plugin to provide a svn-keywords Contentfilter that does [01:23] jelmer: absolutely true! [01:24] igc: (I didn't mean to come across as negative wrt filters btw, I like how they're shaping up so far) [01:24] * jelmer gets some sleep [01:25] night jelmer, and thanks for the input/feedback - much appreciated [01:27] hi lifeless [01:27] james_w: can you pastebin your hackjob, or something [01:30] http://paste.ubuntu.com/135726/ [01:35] james_w: how did it perform [01:35] I've no idea [01:35] I was just running the testsuite and looking at the failures === Ampelbein is now known as ampelbein [01:53] bzr branch foo/ bar/ && bzr loomify bar/ === ampelbein is now known as Ampelbein [01:53] cd bar/ && bzr create-thread spam && hack hack hack && bzr commit [01:54] What now needs to be done so that I can get changes from bar/ to foo/ such that foo/ doesn't need the loom plugin? [01:54] if I generate a patch bundle from bar/ at the above point, will that patch bundle have problems in foo/ (which has no loom plugin)? [01:57] bignose: bzr switch spam && bzr push foo/ [01:57] okay. so the revision data won't depend on the loom plugin? [01:58] in particular, can I make a patch bundle from bar/ and give it to the owner of foo/ who doesn't use looms? [01:59] yes [01:59] thanks. [02:00] if I want to avoid surprises for the owner of foo/, are there any actions I should avoid so they don't get messages about incompatibilities caused by the loom? [02:03] nope [02:03] the loom won't pollute an existing branch [02:04] great, thank you. [02:04] if you push to a new url, you'll get a new loom, if you push to an existing branch, it pushes the current thread of the loom to that branch [02:04] jelmer: are you around, by any chance? [02:05] if you 'bzr send' it does the normal thing, of getting the revisions from the target branch common ancestor through to the current tip [02:05] with loom, I often do 'bzr send -r thread:..-1' to get a cherrypick of the current thread only [02:07] doesn't ‘bzr send -r thread:’ do the same thing? (i.e. I thought the end-of-range defaulted to the tip) [02:08] er [02:09] bignose: Please use ascii quotes, or I can' read it [02:09] nnnggg [02:09] * bignose curses IRC for not preserving character encoding information [02:09] why does the main branch of dulwich now have revision ids that look like bzr-git revids? [02:09] mwhudson: jelmer has gone to sleep, I don't know the answer :P [02:10] mwhudson: could be because someone used git as a branch-sanitise tool? [02:10] bignose: oh, its at my end, its not IRC per se, but still :( [02:10] lifeless: it's still IRC that doesn't carry the information :-( [02:12] anyhow, you'll need to say again, s..> t á d<... wasn't helpful for me [02:13] doesn't 'bzr send -r thread:' do the same thing? (i.e. I thought the end-of-range defaulted to the tip) [02:14] unfortunately different commands behave differently [02:14] this has been discussed and is not resolved [02:15] bignose: what do you mean, "preserving"? [02:15] bignose: are you proposing that each message should have a Charset: header? [02:16] SamB: I'm proposing that a text medium should declare the encoding of its content, yes. [02:17] now, having "use UTF-8" in the RFC would be nice, I admit ;-) [02:17] * emmajane waves [02:21] hi, does anyone know how i can have my launchpad bzr code mirrored onto sourceforge? [02:32] ub3rst4r: well you can probably just push there [02:32] I don't know much/anything about the sourceforge bzr support; it would be nice if the sourceforge folk were to hang out here :) [03:08] * igc lunch [03:12] kfogel: ping [03:19] hi all [03:22] * emmajane waves to poolie [03:22] but then opts for sleep. [03:23] hi there [03:23] koalas soon i promise [03:23] YAY! [03:23] i had some apparent jaunty usb failures [03:23] but i have them downloaded now :) [03:23] poolie, stupid ubuntu. ;) [03:23] heh [03:23] apparently koala photos will be better supported next time [03:23] gettin' between me and koala pictures! [03:24] * emmajane chuckles. [03:25] aight. sleep time! [03:25] * emmajane waves === Spaz is now known as Kittens === Kittens is now known as Spaz === Ampelbein is now known as ampelbein [04:04] lunching [04:08] What's the command to get the revision number of the working revision? (NOT the revisions at head like revno gives) [04:09] awmcclain: I'm not sure what you mean by "the working revision" if not head? Oh, is this a checkout? [04:09] spiv: Yes. [04:10] Hmm, I'm not sure if there is a command that does that. [04:11] Really? [04:11] Ug. [04:11] There certainly should be... [04:11] * awmcclain cries [04:12] * AfC freely admits he doesn't have a clue what is being probed here. [04:19] awmcclain: FWIW, the code to get that revision number would be something like from bzrlib.bzrdir import BzrDir; tree = BzrDir.open('.').open_workingtree(); revid = tree.get_parent_ids()[0]; print tree.branch.revision_id_to_revno(revid) [04:19] awmcclain: bzr log --show-ids -r -5.. | grep -C `bzr revision-info`, or something like that [04:20] lifeless: ooh, tricksy. [04:20] :> [04:24] spiv: I'm assuming no meetup today; I'm nearly done with commit, so will either be tackling one of the interesting network bits, or tomorrow [04:25] Hmm, actually, I think log still uses the tip from branch rather than the tree? [04:25] yes [04:28] We really should have a tree: revspec or something. [04:29] eys [04:47] not sure if I'd class this as a bug, per-se, but was a tad unexpected: Have a .bzr dir that is chmod 750 (some of the files controlled are sensitive). did a bzr upgrade and wound up with backup.bzr being 755. Strictly that was also the umask (0022), but my gut feel is the right thing would be to maintain permissions. ??? [04:48] spm: if you want it fixed, file a bug :) [04:48] lifeless: heh. yes. I nearly did, but thought I'd canvass opinion first. :-) [05:06] i'd agree it's a bug [05:46] lifeless: pong [05:52] so David Reitter is someone in the emacs community? [05:56] lifeless: bug 305006 I haven't release 1.13.1 how did Dorin get it to report the bug? Any idea? [05:56] Launchpad bug 305006 in bzr "shelve fails on win32 with "Could not acquire lock"" [Undecided,Fix committed] https://launchpad.net/bugs/305006 [05:57] nm, except for the doc changes it's in lp [06:03] lifeless: the name doesn't ring a bell, actually [06:03] BasicOSX: I think they mean 1.13rc1 [06:03] BasicOSX: which doesn't have all of 1.13.0 :P [06:04] kfogel: oh, well he's playing with emacs and filing a cluster of bugs [06:04] :-( [06:04] some of which are flailing-new-user stuff and some are good [06:04] I was hoping someone in the same TZ and community could lend a hand [06:05] lifeless: filing launchpad bugs or bzr bugs? === r0bby_ is now known as r0bby [06:05] bzr bugs [06:16] ciao for the day [06:51] night lifeless [06:58] hi all [07:01] * igc dinner [07:03] hello vila [07:14] bug 347130 [07:14] Launchpad bug 347130 in bzr "test_msgeditor.MsgEditorTest.test__run_editor_EACCES breaks noninteractive test suite" [Undecided,New] https://launchpad.net/bugs/347130 [07:14] poolie: that's bug that breaks non-interactive test suite, looks to be related to another bug on how the VISUAL vs EDITOR is choosen [07:26] BasicOSX: thanks [07:26] interesting [07:27] so it fails when VISUAL is set and EDITOR is unset? [07:27] I had other words, but interesting fit it too [07:27] :) [07:27] yes [07:27] if EDITOR is set and VISUAL unset we are ok [07:31] I keep typing bzr-get update bzr, apt, sheesh [07:44] BasicOSX: :) [07:50] ok [07:50] relatively early night for me [07:51] BasicOSX: bug 347130 is probably pretty easy but if it will still take a little while [07:51] Launchpad bug 347130 in bzr "test_msgeditor.MsgEditorTest.test__run_editor_EACCES breaks noninteractive test suite" [Undecided,New] https://launchpad.net/bugs/347130 [07:51] so i'm not going to do it right now [07:52] thanks for filing it though [07:52] poolie: np, unset VISUAL and I'm good [07:52] I'm adding notes to bzr.dev releasing so I don't forget === thekorn_ is now known as thekorn [10:16] mwhudson: hi [10:26] hi [10:26] i'm getting these wierd ssh auth failures on the 6th minute of the hour [10:26] and only then [10:27] http://rafb.net/p/GprFbL61.html [10:27] i can't wrap my mind around it to find a starting point [10:28] halp! [10:38] guess everybody's asleep [11:18] does bzr in jaunty now do notifications? [11:20] bzr-gtk does [12:09] I would like to show the history of a file that has only had renames and no content changes, how can i do this with bzr? [12:12] did you try bzr log already? [12:17] jdobrien: does "bzr log -v filename" do what you want? [12:21] james_w: that works...thanks [12:21] cool [12:22] (the -v is just to show what changed (renames etc) it's slower, but it helps to make sure you know what you are getting) [12:48] Hmm, bzr seems to freeze when trying to pull the bzr repo: [12:49] It get stuck at [#| ] http > 508kB 4kB/s | Pull phase:Copying revision texts:Copied record 17/288 [12:49] Is this my end, the server or something in the middle? [12:50] cammoblammo: I only have some guesses, but... http://bazaar-vcs.org/bzr/bzr.dev/? What version of bzr are you running? Got a proxy? [12:52] Peng_: Yes, that's the URL. I'm running 1.14dev, no proxy. Hmm, I seem to be having a similar issue with another project that uses bzr. [12:57] Ah well, it's bed time now. I'll try again in the morning, that magical time when bugs disappear and computing nirvana awaits. [12:57] cammoblammo: Good night. :) [12:59] :-) [13:00] am reading up on Bzr and I am very interested in the "Decentralized with human gatekeeper model" [13:00] was wondering if there were any examples of how to set this up? [13:01] did you check out the user manual? [13:01] yeah did [13:01] can I run you through some of my doubts bob2 [13:02] ? :) [13:02] you can ask the channel, someone might know :) [13:02] ok you asked for it [13:02] so say I was the gatekeeper and I set up a repository and setup a TRUNK or Main Branch and multiple branches for each developer [13:03] now how do developers manage to update their own branches from a. The MAIN branch or b. Each other's branches directly? [13:04] and when they are done completing a feature that needs merging into the MAIN branch.. how do they submit a Merge request? [13:04] they can merge from each other or the trunk [13:04] best to stick with the trunk if possible [13:04] they can send you a merge request or a url for you to merge from - the end result is pretty much the same [13:05] ok so you are saying I should make it a process to only allow features updated when they are in the main branch? [13:06] so developers cannot share code between each other's branches without going through the main branch and hence a merge request process? [13:06] is that correct bob2 [13:06] ? [13:06] they can, if they want [13:06] it might make merging harder for you [13:07] ok I think I like the process where they submit their merges to the MAIN branch from which we can all UPDATE our branches [13:07] what about the "request to merge"? [13:08] Are you talking about them PUBLISHING their branches on Launchpad and then we can merge from there? [13:08] can they not send me an e-mail using that bzr send feature or something? [13:08] just wondering what is the better option? [13:08] no, I'm not [13:09] ok what you saying then ? :) [13:09] they can send you a merge request (with bzr send), or they can just send you a url to pull from [13:09] I guess they could send you a lp url, if you're using lp [13:09] we are all working on the same machine [13:09] but different UNIX accounts [13:09] so I can really merge between branches locally [13:10] that's just a particularily boring url then :) [13:10] what do u mean? [13:10] Bundle Buggy was mentioned in that model to help review the changes etc [13:11] nevermind [13:11] I was thinking when a developer is ready he might send me this e-mail that shows all his changes etc... and I can code review it before I merge it into our MAIN branch [13:11] sure [13:11] yeah but how does bzr help me do this? [13:12] Can you give me an idea? [13:12] I don't know what you mean [13:12] the developer can send you an email, telling you which branch they would like you to merge [13:12] you merge it, run the tests, look at the diff, then commit it if you're happy [13:13] you can use bundlebuddy to help with that stage, if you like, but it's not essential [13:13] Hmmm [13:13] bundlebuddy helps in which stage sorry - merge, diff or test ? [13:14] dont you think I should do a diff before I perform a merge? [13:14] keeping track of merge requests [13:14] :) [13:14] of course you should [13:14] 'bzr merge' just changes your working copy [13:14] the merge is not commited until you commit [13:15] ok and the bzr merge command is issues in the TARGET branch you want to merge into yeah? [13:15] yes [13:15] bzr help merge [13:15] I suppose I got to look at the merge command [13:15] hahah yeah [13:15] I think I will setup a dummy project and test all these scenarios out on them [13:16] oh and one more thing... say I just merged a developer's branch into the TRUNK or MAIN branch... and want to update my branch with his changes... is that another merge from my branch? [13:17] wondering if my own changes that I am working on will get affected in this situation? [13:17] and how BZR deals with conflict resolutions? [13:18] if YOURBRANCH was up to date with TRUNK before you merged SOMEONEELSESBRANCH into TRUNK, then you can jus do a 'bzr pull' in YOURBRANCH to bring it up to date [13:18] it drops conflict markers in the files, and leaves the this, other (and sometimes base) versions for you to merge manually [13:19] ok [13:19] man have to play around with it now. [13:19] :) [13:19] cheers bob2 [13:19] thanks [13:19] no worries [13:20] bob2: last one :) [13:21] should I be creating ONE repository or multiple repositories with one for each developer? [13:21] which one is a better model you reckon? [13:21] depends [13:21] I was initially thinking... one repository - multiple projects - each project with multiple branches [13:22] you can't (easily) do access control within a repository [13:22] ok [13:22] so if I wanted to be the only one who could COMMIT changes to the MAIN branch.. is that just with UNIX permissions? [13:23] or is there a way of doing it in bzr? [13:23] setting up some sort of roles in bzr [13:23] unix permissions [13:23] but as above [13:23] k [13:23] I'm sure there's some addon to do something fancier [13:24] so u think its better to have separate repositories for each developer and then one for MAIN repository holding the GOLD copy for the project? [13:24] that make sense? [13:26] The point of a shared repository is to prevent disk space from being wasted when you have multiple branches of a project. You should use one repo per project, unless you need more for access control. [13:27] (In that case, if everyone has bzr 1.6 or newer, using stacked branches will help.) [13:30] Peng: so now if I have a single repository then how do I implement access control? [13:30] how do I stop other developers to have READ ONLY access to the MAIN branch? [13:31] so they cannot COMMIT their changes directly without a review process [13:31] just use single branches [13:31] and no repository [13:31] I thought I always have to setup a repository ? [13:32] no [13:33] so bob2 ... are you saying I just setup directories in their account homes where I can do a bzr init and then bzr branch? [13:33] so there is no need for a repository [13:33] yes [13:33] well, you'll do init once [13:33] then branch all the rest from that [13:33] you think it would be a good idea to just create a different UNIX user for the MAIN branch? [13:33] say something like bzruser [13:33] :) [13:34] no [13:34] ok [13:34] just wondering what will happen when I merge the developer's files to this main repository... it would have their owner names on it ? [13:34] you could, but it seems like overengineering to begin with [13:35] you mean branch, not repository, I think [13:35] yes [13:35] I think you should just have a go [13:35] make a simple branch, then make some other branches from it and try merging, and using 'bzr log' [13:35] yeah... its just the access control that I am worried about to be honest [13:35] why? it's simple [13:36] I am worried that after merging the file might have the developer's ownership.. say I ADDED new files from his branch to MAIN... then I am pretty sure he can anytime go straight to the MAIN branch and modify stuff [13:37] no [13:39] k let me test it out... will let you know if I have any dramas then [13:58] Good day. I've a directory that contains a heap of branches. I'm curious if there's a handy way to query the default pull location for each of these all-at-once, rather than checking individually. [14:01] persia: You mean from the shell or what? I'd probably just use something evil with find and grep on .bzr/branch/branch.conf (.bzr/branch/parent on really old branches), or hack something together with bzrlib. [14:02] Peng, From the shell would be ideal. I was just about to hack something up with for and grep, but thought I'd ask to see if someone else already wrote a plugin first :) [14:05] Ah. [14:09] Peng, Thanks anyway. `for i in */.bzr/branch/branch.conf; do echo -n $i:; grep push_location $i; done | grep 7Epersia` does what I wanted :) [14:16] vila: good morning [14:16] * persia decides `for i in */.bzr/branch/branch.conf; do grep push_location $i > /dev/null && echo $i | cut -d/ -f1; done` is even more useful, and wanders off, happy. [14:16] igc: just a quick check if you are still around. I was going to work on iteritems if nothing else came up, but I wanted to make sure you had not done it [14:16] jam: Hi jamm quick call ? [14:17] hey vila, give me ~5 minutes, but yeah [14:17] ok [14:24] vila: I'm ready for my phone call, Mr. Ladeuil [14:25] :) [14:25] Was grabbing the phone already :) [14:44] does anybody know if bzr 1.6 and 1.9 are compatible? i have a repo that i'm needing to move back and forth from two machines that have those versions installed... === ampelbein is now known as Ampelbein [14:51] hunmonk: Bazaar is more or less always compatible. Just use disk formats that both versions support (i.e. not 1.9). [14:52] guys if someone sent me a request to merge their changes for a certain rev no... would I be able to do a diff and check my trunk vs the rev no commit copy in their local branch? [14:53] or should I first do the merge for the revno they supply and then do a diff before I commit to trunk? [14:53] Peng: any suggestions as to what is the better approach? [14:54] CBro2007_: I'm not fully awake and don't understand what you said. :P [14:54] great [14:54] :) [14:54] say I am the gatekeeper for the trunk copy or MAIN branch [14:54] you are a developer who just completed a feature [14:55] you want me to MERGE a given rev no from your branch... not the latest one [14:55] do I first do a DIFF to see what is being merged ? [14:55] Or do I first merge it and then do a Diff later? [14:56] CBro2007_: I'd do the latter. You can always "bzr revert" if you don't like it. [14:56] so bzr revert goes ahead and removed the merge? [14:56] or reverts to the last committed copy? [14:56] Um. [14:57] Um? [14:57] :) [14:58] I suppose if I first do a merge then there will be nothing to diff against? [14:59] or I can probably diff against the LATEST COMMITTED branch [14:59] "bzr revert" reverts any uncommitted changes, including uncommitted merges. [14:59] copy [14:59] hmmm [14:59] FYI, you can do "bzr merge --preview" to show what doing a merge would do. [14:59] ah thats helpful [14:59] ok cool [15:00] thanks [15:01] Like I said, I would personally do "bzr merge" first, diff, fix conflicts, etc., and commit, or "bzr revert" if I don't like it, but you should do whatever works for you. [15:01] how do conflicts show? [15:01] does it come up in the merge command? [15:02] "bzr merge" will yell at you, and put conflict markers in the files, and create .{THIS,OTHER,BASE} files. "bzr status" will show it as well. [15:02] ok [15:02] thanks [15:03] Try it and see. :D [15:03] don't think that should be the case most of the times as we will be hopefully working on different features [15:03] but you never know [15:03] CBro2007_: Bazaar will also refuse to commit conflicted files. [15:03] So it's really hard to miss. :P [15:03] will try and commit the copies in trunk before any merges etc === Ampelbein is now known as ampelbein [15:20] Hey Peng_ [15:21] I tried this.... I added a new file from the developer's branch and did a bzr add then commit [15:21] then from the trunk I went : [15:21] bzr merge -r 6 /home/dev/dcrepo/ --preview [15:22] I don't see the NEW file in my working directory after this merge [15:22] do you know why that is? [15:22] I am trying to get a certain revision number from his branch.... as he has done more commits AFTER rev 6 [15:22] anyone got any ideas why merge doesn't work here? === ampelbein is now known as Ampelbein [15:26] CBro2007_: "merge --preview" doesn't change your working tree. It's just a preview. [15:26] yeah just realized that now [15:26] :) [15:26] sorry [15:26] Okay. [15:26] thought it does the merge + gives a preview [15:28] Peng_: I also noticed that you have to ADD new files with bzr add [15:28] so then i am thinking I will have to make it a rule that developers check bzr status [15:28] and then do adds etc [15:28] Checking bzr status and bzr diff before committing is always a good idea. [15:29] yep [15:38]