[00:12] <ronny> lifeless: aware of a simple way for automated installs of different bzr versions?
[00:13] <lifeless> bzr branch?
[00:13] <ronny> (im trying to refactor anyvc's tests to check multiple versions of the different vcs's if possible)
[00:14] <lifeless> 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] <ronny> hmk
[00:16] <lifeless> 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] <jelmer> igc: hi
[00:38] <igc> hi jelmer
[00:40] <jelmer> igc: You mentioned on the list you're working on a patch to support custom rules
[00:41] <igc> jelmer: just about to. See http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/51347
[00:42] <igc> jelmer: let me know if that sounds ok to you
[00:46] <jelmer> igc: I like the flexibility
[00:46] <jelmer> igc: though it also means local configuration is *always* required when using keywords/eol-conversions
[00:47] <jelmer> igc: and this doesn't e.g. allow for use of rules set in svn
[00:47] <igc> jelmer: can you explain further?
[00:47] <lifeless> igc: How do filters interact with diff -r x..y?
[00:47] <igc> jelmer: I was hoping we could ...
[00:48] <igc> do something like "rules_location = svn:..."
[00:48] <igc> lifeless: diff should apply to the canonical text, not the text in the working tree
[00:48] <jelmer> igc: ah, hmm
[00:48] <jelmer> igc: that seems like overkill though, as you would set that to the same location you've just checked out
[00:48] <igc> external diff tools are an issue though
[00:49] <lifeless> igc: ok; I was just considering the case of dealing with versioned files
[00:49] <jelmer> igc: and that would require on-line access to the svn repo
[00:49] <lifeless> versioned rules
[00:49] <lifeless> I'm still extremely nervous about them, I don't think its thought out enough
[00:50] <jelmer> IMHO ideally rules should be a per-tree versioned setting, while not being part of that tree itself.
[00:50] <jelmer> and access to them abstracted away
[00:51] <lifeless> jelmer: my concerns are about things like 'merge' when the rules change
[00:51] <lifeless> do we read via old rules and write via new correctly? and what if they conflict
[00:51] <jelmer> (that's non-trivial to achieve though, so I understand we should support look at other solutions in the short term)
[00:51] <jelmer> s/support//
[00:52] <lifeless> or pull, as a simpler case to analyse
[00:52] <lifeless> igc: I'm really glad the core filter support has landed
[00:52] <igc> jelmer: my immediate concern is to support something better than "just global" rules
[00:52] <igc> lifeless: thanks
[00:52] <jelmer> igc: Yes, I agree
[00:53] <igc> jelmer: while allowing you ...
[00:53] <igc> to do something smarter when you can
[00:53] <jelmer> 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] <jelmer> igc: putting a magic .bzrrules file in the tree would make it very hard to get to that situation at some point
[00:54] <jelmer> igc: Your current proposal doesn't appear to
[00:54] <igc> 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] <igc> jelmer: but I'm convinced that we just can't answer everyone's desires here
[00:55] <jelmer> igc: Sure, I understand. I think the current proposal is reasonable
[00:56] <lifeless> 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] <igc> lifeless: me too
[00:57] <igc> jelmer: are there tweaks to my proposal that would help you?
[00:58] <igc> jelmer: btw, there's no default - if rules_location isn't set, then just global rules apply
[00:58] <igc> jelmer: importantly though, rules_location can be set in locations.conf and re-used across a bunch of branches
[00:59] <jelmer> 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] <jelmer> 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] <igc> jelmer: so perhaps tree.conf is what you want?
[01:02] <igc> 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] <igc> s/pint/point/
[01:03] <jelmer> igc: For svn, the rules would have to be a property of a Tree object, including RevisionTree objects
[01:03] <igc> 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] <igc> jelmer: from memory, the API for looking up rules is on Tree, because rules are path dependent
[01:05] <jelmer> igc: But they're not stored as part of a Tree atm
[01:06] <jelmer> bzr-svn can import rules for historic svn revisions, but it isn't involved for the working tree
[01:06] <lifeless> igc: please make info [-v?] print out the rules config
[01:06] <igc> jelmer: right
[01:06] <igc> lifeless: shall do
[01:07] <lifeless> I just mean the value of the pointer, not all the rules - just thinking fordebugging with users
[01:07] <igc> lifeless: yes, that's what I thought you meant
[01:07] <lifeless> :)
[01:08] <lifeless> james_w: ping
[01:14] <jelmer> igc: anyway, even if we can't import rules from svn yet, we can support svn keywords now (-: Thanks!
[01:20] <igc> jelmer: well, keeping in mind that our keywords aren't a one-for-one match with svn's ones, yes
[01:22] <jelmer> igc: Yeah, but filters should allow the bzr-svn plugin to provide a svn-keywords Contentfilter that does
[01:23] <igc> jelmer: absolutely true!
[01:24] <jelmer> 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] <igc> night jelmer, and thanks for the input/feedback - much appreciated
[01:27] <james_w> hi lifeless
[01:27] <lifeless> james_w: can you pastebin your hackjob, or something
[01:30] <james_w> http://paste.ubuntu.com/135726/
[01:35] <lifeless> james_w: how did it perform
[01:35] <james_w> I've no idea
[01:35] <james_w> I was just running the testsuite and looking at the failures
[01:53] <bignose> bzr branch foo/ bar/ && bzr loomify bar/
[01:53] <bignose> cd bar/ && bzr create-thread spam && hack hack hack && bzr commit
[01:54] <bignose> 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] <bignose> 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] <lifeless> bignose: bzr switch spam && bzr push foo/
[01:57] <bignose> okay. so the revision data won't depend on the loom plugin?
[01:58] <bignose> 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] <lifeless> yes
[01:59] <bignose> thanks.
[02:00] <bignose> 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] <lifeless> nope
[02:03] <lifeless> the loom won't pollute an existing branch
[02:04] <bignose> great, thank you.
[02:04] <lifeless> 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] <mwhudson> jelmer: are you around, by any chance?
[02:05] <lifeless> 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] <lifeless> with loom, I often do 'bzr send -r thread:..-1' to get a cherrypick of the current thread only
[02:07] <bignose> doesn't ‘bzr send -r thread:’ do the same thing? (i.e. I thought the end-of-range defaulted to the tip)
[02:08] <mwhudson> er
[02:09] <lifeless> bignose: Please use ascii quotes, or I can' read it
[02:09] <bignose> nnnggg
[02:09]  * bignose curses IRC for not preserving character encoding information
[02:09] <mwhudson> why does the main branch of dulwich now have revision ids that look like bzr-git revids?
[02:09] <lifeless> mwhudson: jelmer has gone to sleep, I don't know the answer :P
[02:10] <bignose> mwhudson: could be because someone used git as a branch-sanitise tool?
[02:10] <lifeless> bignose: oh, its at my end, its not IRC per se, but still :(
[02:10] <bignose> lifeless: it's still IRC that doesn't carry the information :-(
[02:12] <lifeless> anyhow, you'll need to say again, s..> t á d<... wasn't helpful for me
[02:13] <bignose> doesn't 'bzr send -r thread:' do the same thing? (i.e. I thought the end-of-range defaulted to the tip)
[02:14] <lifeless> unfortunately different commands behave differently
[02:14] <lifeless> this has been discussed and is not resolved
[02:15] <SamB> bignose: what do you mean, "preserving"?
[02:15] <SamB> bignose: are you proposing that each message should have a Charset: header?
[02:16] <bignose> SamB: I'm proposing that a text medium should declare the encoding of its content, yes.
[02:17] <SamB> now, having "use UTF-8" in the RFC would be nice, I admit ;-)
[02:17]  * emmajane waves
[02:21] <ub3rst4r> hi, does anyone know how i can have my launchpad bzr code mirrored onto sourceforge?
[02:32] <lifeless> ub3rst4r: well you can probably just push there
[02:32] <lifeless> 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] <lifeless> kfogel: ping
[03:19] <poolie> hi all
[03:22]  * emmajane waves to poolie 
[03:22] <emmajane> but then opts for sleep.
[03:23] <poolie> hi there
[03:23] <poolie> koalas soon i promise
[03:23] <emmajane> YAY!
[03:23] <poolie> i had some apparent jaunty usb failures
[03:23] <poolie> but i have them downloaded now :)
[03:23] <emmajane> poolie, stupid ubuntu. ;)
[03:23] <poolie> heh
[03:23] <poolie> apparently koala photos will be better supported next time
[03:23] <emmajane> gettin' between me and koala pictures!
[03:24]  * emmajane chuckles.
[03:25] <emmajane> aight. sleep time!
[03:25]  * emmajane waves
[04:04] <lifeless> lunching
[04:08] <awmcclain> What's the command to get the revision number of the working revision? (NOT the revisions at head like revno gives)
[04:09] <spiv> awmcclain: I'm not sure what you mean by "the working revision" if not head?  Oh, is this a checkout?
[04:09] <awmcclain> spiv: Yes.
[04:10] <spiv> Hmm, I'm not sure if there is a command that does that.
[04:11] <awmcclain> Really?
[04:11] <awmcclain> Ug.
[04:11] <spiv> 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] <spiv> 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] <lifeless> awmcclain: bzr log --show-ids -r -5.. | grep -C `bzr revision-info`, or something like that
[04:20] <spiv> lifeless: ooh, tricksy.
[04:20] <lifeless> :>
[04:24] <lifeless> 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 <dunno> tomorrow
[04:25] <spiv> Hmm, actually, I think log still uses the tip from branch rather than the tree?
[04:25] <lifeless> yes
[04:28] <spiv> We really should have a tree: revspec or something.
[04:29] <lifeless> eys
[04:47] <spm> 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] <lifeless> spm: if you want it fixed, file a bug :)
[04:48] <spm> lifeless: heh. yes. I nearly did, but thought I'd canvass opinion first. :-)
[05:06] <poolie> i'd agree it's a bug
[05:46] <kfogel> lifeless: pong
[05:52] <lifeless> so David Reitter is someone in the emacs community?
[05:56] <BasicOSX> lifeless:  bug 305006 I haven't release 1.13.1 how did Dorin get it to report the bug? Any idea?
[05:57] <BasicOSX> nm, except for the doc changes it's in lp
[06:03] <kfogel> lifeless: the name doesn't ring a bell, actually
[06:03] <lifeless> BasicOSX: I think they mean 1.13rc1
[06:03] <lifeless> BasicOSX: which doesn't have all of 1.13.0 :P
[06:04] <lifeless> kfogel: oh, well he's playing with emacs and filing a cluster of bugs
[06:04] <BasicOSX> :-(
[06:04] <lifeless> some of which are flailing-new-user stuff and some are good
[06:04] <lifeless> I was hoping someone in the same TZ and community could lend a hand
[06:05] <kfogel> lifeless: filing launchpad bugs or bzr bugs?
[06:05] <lifeless> bzr bugs
[06:16] <lifeless> ciao for the day
[06:51] <poolie> night lifeless
[06:58] <vila> hi all
[07:01]  * igc dinner
[07:03] <poolie> hello vila
[07:14] <BasicOSX> bug 347130
[07:14] <BasicOSX> 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] <poolie> BasicOSX: thanks
[07:26] <poolie> interesting
[07:27] <poolie> so it fails when VISUAL is set and EDITOR is unset?
[07:27] <BasicOSX> I had other words, but interesting fit it too
[07:27] <poolie> :)
[07:27] <BasicOSX> yes
[07:27] <BasicOSX> if EDITOR is set and VISUAL unset we are ok
[07:31] <BasicOSX> I keep typing bzr-get update bzr, apt, sheesh
[07:44] <vila> BasicOSX: :)
[07:50] <poolie> ok
[07:50] <poolie> relatively early night for me
[07:51] <poolie> BasicOSX: bug 347130 is probably pretty easy but if it will still take a little while
[07:51] <poolie> so i'm not going to do it right now
[07:52] <poolie> thanks for filing it though
[07:52] <BasicOSX> poolie:  np, unset VISUAL and I'm good
[07:52] <BasicOSX> I'm adding notes to bzr.dev releasing so I don't forget
[10:16] <jelmer> mwhudson: hi
[10:26] <gmarselis> hi
[10:26] <gmarselis> i'm getting these wierd ssh auth failures on the 6th minute of the hour
[10:26] <gmarselis> and only then
[10:27] <gmarselis> http://rafb.net/p/GprFbL61.html
[10:27] <gmarselis> i can't wrap my mind around it to find a starting point
[10:28] <gmarselis> halp!
[10:38] <gmarselis> guess everybody's asleep
[11:18] <apw> does bzr in jaunty now do notifications?
[11:20] <james_w> bzr-gtk does
[12:09] <jdobrien> 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] <SamB> did you try bzr log already?
[12:17] <james_w> jdobrien: does "bzr log -v filename" do what you want?
[12:21] <jdobrien> james_w: that works...thanks
[12:21] <james_w> cool
[12:22] <james_w> (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] <cammoblammo> Hmm, bzr seems to freeze when trying to pull the bzr repo:
[12:49] <cammoblammo> It get stuck at [#|                  ] http >    508kB     4kB/s | Pull phase:Copying revision texts:Copied record 17/288
[12:49] <cammoblammo> Is this my end, the server or something in the middle?
[12:50] <Peng_> 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] <cammoblammo> 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] <cammoblammo> 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] <Peng_> cammoblammo: Good night. :)
[12:59] <cammoblammo> :-)
[13:00] <CBro2007_> am reading up on Bzr and I am very interested in the "Decentralized with human gatekeeper model"
[13:00] <CBro2007_> was wondering if there were any examples of how to set this up?
[13:01] <bob2> did you check out the user manual?
[13:01] <CBro2007_> yeah did
[13:01] <CBro2007_> can I run you through some of my doubts bob2
[13:02] <CBro2007_> ? :)
[13:02] <bob2> you can ask the channel, someone might know :)
[13:02] <CBro2007_> ok you asked for it
[13:02] <CBro2007_> 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] <CBro2007_> now how do developers manage to update their own branches from a. The MAIN branch or b. Each other's branches directly?
[13:04] <CBro2007_> and when they are done completing a feature that needs merging into the MAIN branch.. how do they submit a Merge request?
[13:04] <bob2> they can merge from each other or the trunk
[13:04] <bob2> best to stick with the trunk if possible
[13:04] <bob2> 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] <CBro2007_> 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] <CBro2007_> so developers cannot share code between each other's branches without going through the main branch and hence a merge request process?
[13:06] <CBro2007_> is that correct bob2
[13:06] <CBro2007_> ?
[13:06] <bob2> they can, if they want
[13:06] <bob2> it might make merging harder for you
[13:07] <CBro2007_> 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] <CBro2007_> what about the "request to merge"?
[13:08] <CBro2007_> Are you talking about them PUBLISHING their branches on Launchpad and then we can merge from there?
[13:08] <CBro2007_> can they not send me an e-mail using that bzr send feature or something?
[13:08] <CBro2007_> just wondering what is the better option?
[13:08] <bob2> no, I'm not
[13:09] <CBro2007_> ok what you saying then ? :)
[13:09] <bob2> they can send you a merge request (with bzr send), or they can just send you a url to pull from
[13:09] <bob2> I guess they could send you a lp url, if you're using lp
[13:09] <CBro2007_> we are all working on the same machine
[13:09] <CBro2007_> but different UNIX accounts
[13:09] <CBro2007_> so I can really merge between branches locally
[13:10] <bob2> that's just a particularily boring url then :)
[13:10] <CBro2007_> what do u mean?
[13:10] <CBro2007_> Bundle Buggy was mentioned in that model to help review the changes etc
[13:11] <bob2> nevermind
[13:11] <CBro2007_> 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] <bob2> sure
[13:11] <CBro2007_> yeah but how does bzr help me do this?
[13:12] <CBro2007_> Can you give me an idea?
[13:12] <bob2> I don't know what you mean
[13:12] <bob2> the developer can send you an email, telling you which branch they would like you to merge
[13:12] <bob2> you merge it, run the tests, look at the diff, then commit it if you're happy
[13:13] <bob2> you can use bundlebuddy to help with that stage, if you like, but it's not essential
[13:13] <CBro2007_> Hmmm
[13:13] <CBro2007_> bundlebuddy helps in which stage sorry - merge, diff or test ?
[13:14] <CBro2007_> dont you think I should do a diff before I perform a merge?
[13:14] <bob2> keeping track of merge requests
[13:14] <CBro2007_> :)
[13:14] <bob2> of course you should
[13:14] <bob2> 'bzr merge' just changes your working copy
[13:14] <bob2> the merge is not commited until you commit
[13:15] <CBro2007_> ok and the bzr merge command is issues in the TARGET branch you want to merge into yeah?
[13:15] <bob2> yes
[13:15] <bob2> bzr help merge
[13:15] <CBro2007_> I suppose I got to look at the merge command
[13:15] <CBro2007_> hahah yeah
[13:15] <CBro2007_> I think I will setup a dummy project and test all these scenarios out on them
[13:16] <CBro2007_> 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] <CBro2007_> wondering if my own changes that I am working on will get affected in this situation?
[13:17] <CBro2007_> and how BZR deals with conflict resolutions?
[13:18] <bob2> 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] <bob2> it drops conflict markers in the files, and leaves the this, other (and sometimes base) versions for you to merge manually
[13:19] <CBro2007_> ok
[13:19] <CBro2007_> man have to play around with it now.
[13:19] <CBro2007_> :)
[13:19] <CBro2007_> cheers bob2
[13:19] <CBro2007_> thanks
[13:19] <bob2> no worries
[13:20] <CBro2007_> bob2: last one :)
[13:21] <CBro2007_> should I be creating ONE repository or multiple repositories with one for each developer?
[13:21] <CBro2007_> which one is a better model you reckon?
[13:21] <bob2> depends
[13:21] <CBro2007_> I was initially thinking... one repository - multiple projects - each project with multiple branches
[13:22] <bob2> you can't (easily) do access control within a repository
[13:22] <CBro2007_> ok
[13:22] <CBro2007_> 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] <CBro2007_> or is there a way of doing it in bzr?
[13:23] <CBro2007_> setting up some sort of roles in bzr
[13:23] <bob2> unix permissions
[13:23] <bob2> but as above
[13:23] <CBro2007_> k
[13:23] <bob2> I'm sure there's some addon to do something fancier
[13:24] <CBro2007_> 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] <CBro2007_> that make sense?
[13:26] <Peng_> 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] <Peng_> (In that case, if everyone has bzr 1.6 or newer, using stacked branches will help.)
[13:30] <CBro2007_> Peng: so now if I have a single repository then how do I implement access control?
[13:30] <CBro2007_> how do I stop other developers to have READ ONLY access to the MAIN branch?
[13:31] <CBro2007_> so they cannot COMMIT their changes directly without a review process
[13:31] <bob2> just use single branches
[13:31] <bob2> and no repository
[13:31] <CBro2007_> I thought I always have to setup a repository ?
[13:32] <bob2> no
[13:33] <CBro2007_> 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] <CBro2007_> so there is no need for a repository
[13:33] <bob2> yes
[13:33] <bob2> well, you'll do init once
[13:33] <bob2> then branch all the rest from that
[13:33] <CBro2007_> you think it would be a good idea to just create a different UNIX user for the MAIN branch?
[13:33] <CBro2007_> say something like bzruser
[13:33] <CBro2007_> :)
[13:34] <bob2> no
[13:34] <CBro2007_> ok
[13:34] <CBro2007_> 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] <bob2> you could, but it seems like overengineering to begin with
[13:35] <bob2> you mean branch, not repository, I think
[13:35] <bob2> yes
[13:35] <bob2> I think you should just have a go
[13:35] <bob2> make a simple branch, then make some other branches from it and try merging, and using 'bzr log'
[13:35] <CBro2007_> yeah... its just the access control that I am worried about to be honest
[13:35] <bob2> why?  it's simple
[13:36] <CBro2007_> 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] <bob2> no
[13:39] <CBro2007_> k let me test it out... will let you know if I have any dramas then
[13:58] <persia> 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] <Peng_> 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] <persia> 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] <Peng_> Ah.
[14:09] <persia> 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] <jam> 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] <jam> 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] <vila> jam: Hi jamm quick call ?
[14:17] <jam> hey vila, give me ~5 minutes, but yeah
[14:17] <vila> ok
[14:24] <jam> vila: I'm ready for my phone call, Mr. Ladeuil
[14:25] <jam> :)
[14:25] <vila> Was grabbing the phone already :)
[14:44] <hunmonk> 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...
[14:51] <Peng_> hunmonk: Bazaar is more or less always compatible. Just use disk formats that both versions support (i.e. not 1.9).
[14:52] <CBro2007_> 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] <CBro2007_> or should I first do the merge for the revno they supply and then do a diff before I commit to trunk?
[14:53] <CBro2007_> Peng: any suggestions as to what is the better approach?
[14:54] <Peng_> CBro2007_: I'm not fully awake and don't understand what you said. :P
[14:54] <CBro2007_> great
[14:54] <CBro2007_> :)
[14:54] <CBro2007_> say I am the gatekeeper for the trunk copy or MAIN branch
[14:54] <CBro2007_> you are a developer who just completed a feature
[14:55] <CBro2007_> you want me to MERGE a given rev no from your branch... not the latest one
[14:55] <CBro2007_> do I first do a DIFF to see what is being merged ?
[14:55] <CBro2007_> Or do I first merge it and then do a Diff later?
[14:56] <Peng_> CBro2007_: I'd do the latter. You can always "bzr revert" if you don't like it.
[14:56] <CBro2007_> so bzr revert goes ahead and removed the merge?
[14:56] <CBro2007_> or reverts to the last committed copy?
[14:56] <Peng_> Um.
[14:57] <CBro2007_> Um?
[14:57] <CBro2007_> :)
[14:58] <CBro2007_> I suppose if I first do a merge then there will be nothing to diff against?
[14:59] <CBro2007_> or I can probably diff against the LATEST COMMITTED branch
[14:59] <Peng_> "bzr revert" reverts any uncommitted changes, including uncommitted merges.
[14:59] <CBro2007_> copy
[14:59] <CBro2007_> hmmm
[14:59] <Peng_> FYI, you can do "bzr merge --preview" to show what doing a merge would do.
[14:59] <CBro2007_> ah thats helpful
[14:59] <CBro2007_> ok cool
[15:00] <CBro2007_> thanks
[15:01] <Peng_> 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] <CBro2007_> how do conflicts show?
[15:01] <CBro2007_> does it come up in the merge command?
[15:02] <Peng_> "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] <CBro2007_> ok
[15:02] <CBro2007_> thanks
[15:03] <Peng_> Try it and see. :D
[15:03] <CBro2007_> don't think that should be the case most of the times as we will be hopefully working on different features
[15:03] <CBro2007_> but you never know
[15:03] <Peng_> CBro2007_: Bazaar will also refuse to commit conflicted files.
[15:03] <Peng_> So it's really hard to miss. :P
[15:03] <CBro2007_> will try and commit the copies in trunk before any merges etc
[15:20] <CBro2007_> Hey Peng_
[15:21] <CBro2007_> I tried this.... I added a new file from the developer's branch and did a bzr add then commit
[15:21] <CBro2007_> then from the trunk I went :
[15:21] <CBro2007_> bzr merge  -r 6 /home/dev/dcrepo/ --preview
[15:22] <CBro2007_> I don't see the NEW file in my working directory after this merge
[15:22] <CBro2007_> do you know why that is?
[15:22] <CBro2007_> I am trying to get a certain revision number from his branch.... as he has done more commits AFTER rev 6
[15:22] <CBro2007_> anyone got any ideas why merge doesn't work here?
[15:26] <Peng_> CBro2007_: "merge --preview" doesn't change your working tree. It's just a preview.
[15:26] <CBro2007_> yeah just realized that now
[15:26] <CBro2007_> :)
[15:26] <CBro2007_> sorry
[15:26] <Peng_> Okay.
[15:26] <CBro2007_> thought it does the merge + gives a preview
[15:28] <CBro2007_> Peng_: I also noticed that you have to ADD new files with bzr add
[15:28] <CBro2007_> so then i am thinking I will have to make it a rule that developers check bzr status
[15:28] <CBro2007_> and then do adds etc
[15:28] <Peng_> Checking bzr status and bzr diff before committing is always a good idea.
[15:29] <CBro2007_> yep
[15:38] <CBro2007_> Peng_: If developers wanted to UPDATE their sandboxes or branch with the TRUNK copy how would they go about doing that?
[15:38] <CBro2007_> with the Merge again?
[15:39] <Peng_> CBro2007_: Yeah.
[15:40] <CBro2007_> whats the PULL option there for?
[15:40] <CBro2007_> would that be something they should be using?
[15:40] <Peng_> Erm.
[15:40] <CBro2007_> or just the normal merge?
[15:40] <Peng_> "Merge" is there to merge changes from another branch into your branch. "Pull" is there to update your copy of another branch.
[15:40] <CBro2007_> I am not sure I understand the --pull option
[15:41] <CBro2007_> is pull a seperate command?
[15:41] <CBro2007_> because the local branches are really copies of the TRUNK branch
[15:41] <Peng_> There's a "bzr pull" command and a "--pull" option to the merge command.
[16:22] <aelkner> does anyone know how to find out what version of a branch is actually installed on a machine?
[16:23] <aelkner> when i do bzr revno or bzr log, it shows me what's in the repository
[16:23] <aelkner> but i haven't, nor do i want to at this time, done a bzr up
[16:24] <aelkner> but it want to figure out which version of the code is actually there
[16:24] <aelkner> does anyone know how i can determine that?
[16:25] <exarkun> 'bzr version-info'?
[16:25] <aelkner> that worked, thanks
[16:26] <aelkner> what's the intention with the difference between revno and version-info?
[16:26] <Kinnison> mmm interesting. I never knew of that particular difference
[16:26]  * Kinnison ponders integrating that into his prompt
[16:27] <aelkner> is there a version of bzr log that takes into account the currently loaded revision number?
[16:28] <aelkner> ir do i need to do bzr log -r 'revision number returned from bzr version-info'
[16:28] <exarkun> bzr log -r `bzr version-info --custom --template="{revno}"` maybe
[16:30] <aelkner> that seems hostel to the user, doesn't it?
[16:30] <aelkner> i mean, shouldn't the commands work against what is actually on the machine?
[16:30] <aelkner> rather than what's in the repository?
[16:30] <Kinnison> revno talks about the branch
[16:31] <Kinnison> Where version-info talks about the working tree
[16:31] <aelkner> but bzr log only talks about the branch
[16:32] <aelkner> wouldn't it be nice to have one that talks about the working tree?
[16:32] <Kinnison> Given you can know the version numbers you care about, what are you trying to achieve?
[16:33] <aelkner> it's not that i can't achieve what it need, using the version-info command to get the revision number
[16:33] <aelkner> it's just that it would be great if there was a command that gave you what bzr log gives you
[16:34] <aelkner> but only up to the revision number that the working tree has
[16:34] <Kinnison> Oh I see
[16:34] <Kinnison> wtlog () { bzr log -r1..$(bzr version-info --custom --template="{revno}") "$@"; }
[16:34] <Kinnison> something like that?
[16:35] <aelkner> i'm not sure what you mean by that
[16:36] <aelkner> i know that's a shell script
[16:36] <aelkner> but i don't know how you mean that it would be used
[16:36] <aelkner> if one is at a command prompt
[16:36] <Kinnison> oh it creates a shell function "wtlog" which when called, automatically gives bzr log the right -r1..blah to only give you the log for the working tree
[16:37] <aelkner> issuing the command bzr log --working_tree would be nice to be able to do
[16:38] <Peng_> Better would be a revision spec, so you could do e.g. "bzr log -r tree:".
[16:42] <aelkner> it just seems unfortunate that the default commands would tell the user about the repository and not the working tree
[16:42] <Peng_> aelkner: The branch, not the repository.
[16:42] <aelkner> sorry, true enough
[16:43] <aelkner> s/repository/branch for my previous comment
[16:45] <aelkner> if one want to know about the branch and not the working tree, i could see forcing them to supply the branch url
[16:45] <aelkner> but then again, others may find that to be a hassle
[16:45] <aelkner> so i guess it's a trade-off
[17:02] <aelkner> Peng_: i sinned and failed to mention that i was dealing with a light checkout and not a branch
[17:03] <aelkner> with branches, bzr revno and log DO show the version that's on the machine
[17:03] <aelkner> and not what
[17:03] <aelkner> and not in the branch in the repository
[17:04] <Peng_> They always show the branch tip. It's just that with lightweight checkouts, the branch tip and the current revision of the working tree are often different.
[17:04] <Peng_> They can be in regular branches though.
[18:35] <bitmonk> howdy, i'm trying to branch via bzr+ssh protocol, with bzr 1.6.1 at both ends, and i get an error regarding rich-root support, because 'bzr branch' seems to be creating a KnitPack.  what can i do to avoid this?
[18:41] <bitmonk> there is a bug that the message could be clearer, but i'm not sure i need that fix to move on ;)
[18:45] <Peng_> bitmonk: Are you trying to branch into a shared repository?
[18:47] <bitmonk> Peng_: nope, just from one into a deployment location.
[18:48] <Peng_> bitmonk: Well, you could create a rich-root repo and branch into it (e.g. "bzr init-repo --rich-root-pack"), or create a standalone rich-root branch and pull into it (e.g. "bzr init --rich-root-pack").
[18:48] <Peng_> bitmonk: "bzr branch" should be less brain-damaged, of course. I don't know if it's been improved in more recent releases.
[18:49] <bitmonk> yah i was thinking along those lines, i haven't seen this before, oddly.  i just created a new shared repo on the server and branched from another shared repo to start a new project based on another's code.  then, on dev server, tried to branch the new location right alongside a branch of the old.
[18:50] <bitmonk> ah it just occur to me, i made the other branches from http and just push over ssh.
[18:50] <bitmonk> thanks for help, maybe i will get some time and i can help test and improve further.
[18:52] <Peng_> bitmonk: FWIW, as of current bzr.dev, "bzr branch" is smart enough to create a branch in the right format, at least locally.
[18:52] <bitmonk> i'll try to find a place to test that, thanks, and look forward to a new stable release.
[18:53] <bitmonk> seems to me it must be the protocol handler in this case, because i'm not running any kind of smart server, just straight apache access to the flat repo files.
[18:53] <bitmonk> but, eh, i'm full of conjecture.
[18:54] <mwhudson> jelmer: hello
[19:04] <stianse_> I have installed two plugins that both override/decorate the commit command. But it seems like only one of the can be active.
[19:05] <stianse_> Is it supported to have two plugins overriding the same command? How?
[19:05] <stianse_> Both plugins use "commands.register_command(cmd_commit, decorate=True)"
[19:15] <mtaylor> if I do this: bzr branch lp:drizzle/mordred  ... is there any reason it couldn't default to pulling over HTTP, or to falling back to http if ssh auth fails?
[19:15] <mtaylor> I don't actually need ssh auth to work for that branch to succeed, after all
[19:19] <Peng_> With how everything is structured, I bet that would be difficult to do.
[19:19] <jelmer> mwhudson: you were looking for me yesterday?
[19:20] <Peng_> Hmm, it would be neat if there was an "lp+http" URL scheme though.
[19:21] <bitmonk> does lp have branches that require authentication to read?
[19:21] <jam> bitmonk: yes
[19:21] <LarstiQ> Peng_: hmm, does the lp directory service have any say in retrying?
[19:22] <jam> bitmonk: they are called "private" branches, I know there are a couple projects that make use of them, though I think it is done on a per-project basis
[19:23] <mwhudson> jelmer: still am :)
[19:23] <mwhudson> jelmer: why does lp:dulwich have completely new, bzr-git-ish, history?
[19:25] <mwhudson> LarstiQ: i don't think to, the directory service basically just gets the chance to turn one url into another
[19:25] <mwhudson> aiui
[19:25] <mwhudson> well, "url"
[19:28] <LarstiQ> mwhudson: feh
[19:28] <LarstiQ> mwhudson: although, since it isn't storing the unexpanded form right now, it doesn't matter too much
[19:30] <jelmer> mwhudson: ah
[19:30] <jelmer> mwhudson: it was dpushed into git
[19:30] <jelmer> mwhudson: and so the revision ids changed as bzr-git doesn't do round-tripping yet
[19:32] <mwhudson> jelmer: any particular reason?
[19:32] <jelmer> mwhudson: for dpushing into git?
[19:32] <mwhudson> yes
[19:32] <jelmer> mwhudson: cooperation with the pyrite folks who are interested in using and hacking on dulwich rather than on their own homegrown code
[19:32] <mwhudson> ah, ok
[19:34] <mwhudson> jelmer: so i need to upgrade the version of bzr-git in launchpad's source code, because of the _lock_count thing in bzr 1.13
[19:34] <mwhudson> jelmer: will bzr-git trunk, dulwich trunk and bzr 1.13 work together ok?
[19:34] <jelmer> mwhudson: yeah
[19:34] <jelmer> mwhudson: bzr-git trunk should support bzr.dev and 1.13 at the moment
[19:34] <mwhudson> jelmer: ok
[19:34] <mwhudson> thanks
[19:37] <mwhudson> jelmer: i'll just have to smile sweetly at the OSAs to get them to run pull --overwrite a couple of times :)
[19:39] <jelmer> mwhudson: whoops
[19:39] <jelmer> mwhudson: sorry, I wasn't aware this was causing that much more work for you
[19:39] <jelmer> mwhudson: at least it shouldn't happen again in the future
[19:39] <mwhudson> jelmer: no worries
[19:40] <LarstiQ> mwhudson: how are git import plans faring?
[19:40] <mwhudson> jelmer: it's just a shame that i only noticed after you'd gone to bed last night
[19:40] <mwhudson> LarstiQ: mostly wrangling dependencies :)
[19:40] <LarstiQ> mwhudson: I see :)
[19:41] <mwhudson> LarstiQ: the code to do the import is mostly written, there's some ui work
[19:42] <mwhudson> but that shouldn't be hard
[19:42] <mwhudson> so maybe it'll be done for the april rollout
[19:43] <LarstiQ> cool
[19:43] <jelmer> mwhudson: just curious, do you handle git branches specially or is it just like mirrorring a native Bazaar branch ?
[19:44] <mwhudson> jelmer: nope, "pull"
[19:44] <jelmer> ah, neat
[19:44] <mwhudson> will do the same for bzr-svn sooner or later
[19:45] <mwhudson> (probably we'll do something where new imports use bzr-svn and old ones continue to use cscvs)
[19:46] <jelmer> mwhudson: ah, neat
[19:50] <mwhudson> jelmer: how's bzr-svn 0.5 working?
[19:50] <mwhudson> ^ out
[19:50]  * LarstiQ needs to file a bug on bzr-svn, sigh
[19:51] <LarstiQ> which means making a test repo to reproduce the bug we're seeing on a proprietary repo
[19:51] <LarstiQ> jelmer: I'm not sighing about bzr-svn, honest! :)
[19:54] <jelmer> LarstiQ: is this the bug we were debugging earlier?
[19:54] <jelmer> mwhudson: 0.5 is working out pretty well
[19:55] <LarstiQ> jelmer: nope!
[19:55] <LarstiQ> jelmer: same project though
[19:56] <LarstiQ> jelmer: but now it's push failing with an assert
[19:57] <jelmer> mwhudson: I'm thinking of doing a 1.0 quite soon (perhaps together with 1.15)
[19:58] <jelmer> LarstiQ: is there a bug open yet? I might be able to fix something based on the assertion..
[19:59] <brink> I hate to ask, but is there a way to convert a bazaar repository to git?   I've tried the latest tailor, but it appears to be broken.
[20:01] <luks> bzr fast-export | git fast-import ?
[20:01] <mwhudson> jelmer: cool
[20:01] <LarstiQ> jelmer: nafaik. I'll look through the bugs. (Of course, it's never me but always a colleague who triggers bugs)
[20:02] <brink> luks:  Do you know where I can get the fast-export plugin?
[20:02] <LarstiQ> brink: try bzr-git and hack on it if it doesn't meet your requirements? ;)
[20:02] <brink> larstiQ: bzr-git would if it worked.  It crashes and burns too.
[20:03] <LarstiQ> brink: http://bazaar-vcs.org/BzrPlugins in general, lp:bzr-fastimport in specific iirc
[20:04] <newz2000> hi, I accidently added some files I didn't want to add. I haven't commited yet though, can I un-add them?
[20:05] <jelmer> brink: any chance you can file a bug against bzr-git if you didn't get it to work?
[20:05] <LarstiQ> newz2000: bzr rm (--keep or --force) the files in question
[20:05] <newz2000> ah, thanks
[20:09] <brink> jelmer:  Oops.  It was git-bzr that crashes and burns.  I haven't tried bzr-git.     Can bzr-git actually convert a bzr repo to a git repo?
[20:11] <thumper> morning
[20:11] <LarstiQ> there is a git-bzr?
[20:11] <jelmer> brink: yeah, although it will only work for relatively small branches atm
[20:12] <jelmer> brink: and you need a patch for bzr to push from bzr into git
[20:12] <LarstiQ> Pieter: aha! :)
[20:13] <Pieter> hmm?
[20:13] <brink> jelmer:  So I just pull bzr-git and installed it.   But bazaar tells me it is unable to load git from the plugins directory.
[20:14] <mwhudson> brink: you need bzr 1.13
[20:14] <jelmer> brink: in particular for being able to push into git you need bzr.dev and my dpush patch posted to the list yesterday
[20:15] <LarstiQ> Pieter: I wondered who that pieter of git-bzr was.
[20:16] <Pieter> ah :)
[20:16] <brink> jelmer:  I'm at version 1.2.   I'll update it.
[20:30] <brink> jelmer:  bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev  give me an internal error.   That's after installing the latest bzr1.13.
[20:30]  * LarstiQ blinks
[20:30] <LarstiQ> brink: could you pastebin that?
[20:32] <brink> jelmer: http://pastebin.com/m30ee2bd7
[20:33] <LarstiQ> brink: ok, bzr-git shouldn't mess with other bzr invocations
[20:34] <LarstiQ> brink: either install dulwich (which you'll need for git interaction later on) or disable the bzr-git plugin momentarily (usually accomplished by moving the plugin away)
[20:38]  * jelmer back in ~40 min
[20:47] <LarstiQ> brink: did that help?
[20:49] <brink> LarstiQ:  I was able to download the latest development release by moving bzr-git and I installed Dulwich.   Not sure what to do next though.
[20:51] <LarstiQ> brink: let me dig up jelmer's patch
[20:52] <LarstiQ> brink: I suppose he meant http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49C6A5B7.1050105%40vernstok.nl%3E
[20:53] <LarstiQ> brink: so, in bzr.dev: `bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C49C6A5B7.1050105@vernstok.nl%3E`
[20:54] <LarstiQ> ok
[20:55] <LarstiQ> brink: in case you missed it, 21:53:02 < LarstiQ> brink: so, in bzr.dev: `bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C49C6A5B7.1050105@vernstok.nl%3E`
[20:59] <brink> LarstiQ:  It seems to have merged and installed successfully.   Do you know the command to try the conversion by any chance?
[21:02] <LarstiQ> brink: `bzr dpush path/to/git/branch` I think
[21:03] <LarstiQ> brink: but this guess isn't hindered by any actual experience with bzr-git ;)
[21:03] <LarstiQ> hmm, that sentence works better in Dutch
[21:04] <brink> LarstiQ:  It seems my version of Dulwich is too old.  http://pastebin.com/m3050c87f
[21:07] <LarstiQ> hmm
[21:07] <LarstiQ> brink: http://samba.org/~jelmer/dulwich/ doesn't list any later release
[21:07] <brink> LarstiQ:  Can't say much about the dutch.  I only know how to ask for beer in Dutch.  But that sentence works pretty well in English.  I think I'll use it in the future.
[21:08] <LarstiQ> brink: a useful skill too :)
[21:08] <thumper> Hi people, I've got lots of this type of directory in /tmp bzr-limbo-dxujgp
[21:09] <thumper> I am using some code for preview trees
[21:10] <thumper> is bzr not cleaning up after itself?
[21:10] <brink> LarstiQ: In most languages yes.  But I've never met a dutch bartender who didn't speak fluent English along with several other languages.
[21:11] <LarstiQ> brink: we're bad like that, sorry :/
[21:12] <LarstiQ> thumper: could be, limbo does indeed sound like TreeTransform, employed by preview trees afaik.
[21:12] <brink> LarstiQ:  Well, it still seems polite to make the attempt in the local tongue even if it isn't necessary.
[21:12] <james_w> thumper: your code may not be cleaning up the TreeTransform in all cases
[21:12] <thumper> james_w: what do I need to do?
[21:12] <LarstiQ> brink: I agree, and replying in a different language is something that makes language learning harder for me.
[21:12] <thumper> james_w: the code is lp:mad
[21:12] <james_w>     def finalize(self):
[21:12] <james_w>         """Release the working tree lock, if held, clean up limbo dir.
[21:12] <james_w>         This is required if apply has not been invoked, but can be invoked
[21:12] <james_w>         even after apply.
[21:12] <james_w>         """
[21:13] <LarstiQ> brink: (I'm slowly learning Finnish, their English is also good enough usually)
[21:16] <LarstiQ> brink: since you're running bzr.dev anyway, could you try a development version of dulwich?
[21:16] <thumper> james_w: thanks, I'll add that to my bug report.
[21:17] <james_w> aren't you the author? :-)
[21:17] <thumper> yes
[21:17] <thumper> james_w: but I'm not getting to it right now
[21:17] <thumper> james_w: I have other things to do
[21:17] <james_w> sure
[21:17] <brink> LarstiQ:  I tried.  Bazaar failed with an internal error.   http://pastebin.com/m7e8d920a
[21:21]  * LarstiQ investigats why the os module might not have fdatasync
[21:22] <LarstiQ> brink: are you on !unix?
[21:22] <LarstiQ> brink: ah, OSX
[21:23] <LarstiQ> brink: this reminds me of a Firefox/sqlite thread on fsync
[21:24] <LarstiQ> brink: so, `python -c 'import os; print os.fdatasync'` will fail if I'm right, does `python -c 'import os; print os.fsync'` work?
[21:24] <jelmer> SamB: ping
[21:25] <jelmer> SamB: you'll need a newer dulwich than the last release
[21:25] <jelmer> s/samb/brink/
[21:26] <jelmer> brink: this is all still very much alpha code
[21:26] <LarstiQ> jelmer: he's got that
[21:26] <LarstiQ> jelmer: but fdatasync does not exist on OSX
[21:26] <jelmer> ah, yuck
[21:26] <jelmer> does it have os.fsync() ?
[21:27] <LarstiQ> jelmer: http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch03lev1sec13.html
[21:27] <LarstiQ> jelmer: it does in C afaik. But it's behaviour is different.
[21:28] <jelmer> LarstiQ:     All four of the platforms described in this book support sync and fsync. However, FreeBSD 5.2.1 and Mac OS X 10.3 do not support fdatasync.
[21:28] <jelmer> LarstiQ: so I guess we should fall back to fsync if fdatasync is not available
[21:28] <LarstiQ> jelmer: see http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ for example
[21:28] <LarstiQ> jelmer: yeah
[21:29] <stianse_> trying one more time before asking on the mailing list: is it possible to have two plugins installed that decorate the commit command?
[21:29] <LarstiQ> stianse_: yes, but could be tricky.
[21:29] <brink> LarstiQ:  That is right.  It fails.  I'm on OS X.    I also have Linux boxes here too that I could try.
[21:29] <stianse_> LarstiQ: Do you have a possible solution?
[21:29] <LarstiQ> brink: for a short term workaround, that should give better results.
[21:30] <stianse_> It's a shame if I have to choose one between several plugins that  I need
[21:30] <LarstiQ> stianse_: is this a developer or user oriented question?
[21:31] <LarstiQ> stianse_: for the former there has been discussion on the list that might be interesting
[21:31] <stianse_> LarstiQ: I'm writing a new plugin
[21:32] <stianse_> LarstiQ: Perhaps I should try to digg in the archive then. I've not subscribed but I guess I can find some archive on the web
[21:32] <LarstiQ> stianse_: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/52239/match=decorate+plugin iirc
[21:40] <LarstiQ> jelmer: boohoo, I get a different assert.
[21:42] <stianse_> LarstiQ: Sorry, but I'm not sure if I fully understand. Does that link describe a proposal of changes in bzrlib or a way to solve the problem that works today?
[21:44] <LarstiQ> stianse_: proposal of changes
[21:44] <LarstiQ> stianse_: if you're adding something another plugin isn't also doing, then you should be good for now I think
[21:45] <stianse_> I want to add a new option to the commit command. But I also have the interactive-plugin installed which also adds an option to that command.
[21:46] <stianse_> That does not seems to work.
[21:46] <jelmer> stianse_: the trick is that plugins that decorate don't simply import cmd_commit from bzrlib.builtins
[21:47] <dash> is there a way to get bzr-svn to remember svn passwords?
[21:47] <jelmer> dash: see the bzr-svn FAQ
[21:47] <dash> gasp, a faq
[21:47] <dash> i will do so. :)
[21:48] <dash> hmm. the one at http://samba.org/~jelmer/bzr-svn/FAQ.html ?
[21:49] <jelmer> dash: oh, I removed that from the FAQ, sorry
[21:49] <jelmer> dash: so, basically, you can either make sure Subversion caches the password somehow
[21:49] <bob2> haha
[21:49] <jelmer> dash: and bzr-svn will then also use the password
[21:49] <dash> right, ok
[21:49] <jelmer> dash: or alternatively you should be able to use bzr's infrastructure for stored credentials
[21:51]  * LarstiQ looks at his subvertpy bugreport
[21:51] <poolie> hello LarstiQ, all
[21:51] <LarstiQ> moin poolie :)
[21:51] <poolie> what do you say in dutch?
[21:52] <stianse_> jelmer: Sorry, some english problems:) Do you mean that a plugin should or should import bzrlib.builtins?
[21:52] <stianse_> jelmer: because both plugins I look at now defines a cmd_commit class that inherits from builtins.cmd_commit
[21:52] <LarstiQ> poolie: as a goodmorning greeting?
[21:53] <stianse_> jelmer: both register with commands.register_command(cmd_commit, True)
[21:53] <jelmer> stianse_: I mean how they retrieve the original class they use as base class
[21:53] <stianse_> jelmer: but only one of the plugins are in effect
[21:54] <jelmer> stianse_: what do you mean with "in effect" ?
[21:56] <stianse_> jelmer: I'll explain: the interactive plugin adds the option "-i" to the commit command.
[21:56] <stianse_> jelmer: The bzr-text-checker adds the option "--text-checker-warn-only" to the commit command.
[21:57] <stianse_> jelmer: but only the option from the interactive plugin is valid
[21:57] <jelmer> stianse_: but both extend and register the commit command ?
[21:57] <jelmer> stianse_: and are loaded at the same time?
[21:57] <stianse_> jelmer: yes
[21:58] <jelmer> stianse_: in that case you can't just import cmd_commit
[21:58] <jelmer> stianse_: but you need to do something like bzr-nm does
[21:59] <stianse_> jelmer: ok. perhaps I'll get some tips if I look in the source code of bzr-nm
[22:00] <jelmer> stianse_: bzr branch is at http://people.samba.org/bzr/jelmer/bzr-nm/trunk
[22:02] <stianse_> jelmer: thanks. i'll see if this solves the problem
[22:03] <jelmer> stianse_: IIRC you need to call bzrlib.commands.get_cmd_object
[22:06] <BasicOSX> Someone with op please /topic 1.13.1 released 23 Mar
[22:10] <LarstiQ> BasicOSX: it didn't get through to the announce list yet?
[22:10] <BasicOSX> not yet
[22:15] <joschan> hi, what can i do, i added files that should not be added, but did not yet commit? is there an "unadd"?
[22:15] <spiv> joschan: "bzr remove"
[22:15] <spiv> (you can even "bzr revert")
[22:16] <joschan> thank you!
[22:17] <spiv> BasicOSX: btw, I don't think the topic is protected in this channel
[22:17] <stianse_> jelmer, LarstiQ:  seems like I got it. at least bzr help commit shows options from both plugins
[22:17] <bob2> it is not
[22:17] <BasicOSX> heh. ok
[22:18] <stianse_> jelmer:  used what's in bzr-nm except from adding decorate=True to the register_command call
[22:19] <Glenjamin> is anyone else seeing a lot of "Unable to read from standard input" messages using bzr on windows?
[22:19] <Glenjamin> it doesnt seem to affect anything, but i suspect something somewhere is closing stdin
[22:25] <jelmer> stianse_: cool
[22:27] <stianse_> jelmer: By the way, is this considered a workaround or the correct way of doing it?
[22:28] <stianse_> Because if this should work, both plugins need apply this approach
[22:29] <stianse_> jelmer: I was just wondering if I should commit a patch to for instance the interactive plugin or keep the changes locally if they are hackish
[22:39] <lifeless> hai, I has net
[22:40] <bob2> ph33r
[22:40] <emmajane> \o/ for innnnernets
[22:42] <jelmer> stianse_: no, this is the proper way
[22:45] <lifeless> now, foods
[22:48] <stianse_> jelmer: good to know, thanks
[22:48] <jelmer> stianse_: If you can submit a merge request for bzr-interactive, that would be nice :-)
[22:49]  * igc breakfast
[22:49] <stianse_> jelmer: I was just about to commit actually :)
[23:23] <lifeless> spiv: shall we pair today?
[23:24] <spiv> lifeless: yeah
[23:27] <spiv> lifeless: I don't have much preference about venue
[23:29] <lifeless> spiv: Lynne is out all day, so here works well for me.
[23:32] <spiv> lifeless: ok, I'll head to Epping then.
[23:43] <mwhudson> are there any known sillinesses with push --overwrite over bzr+ssh from bzr.dev to bzr 1.12?
[23:46] <spiv> mwhudson: not off the top of my head (certainly nothing specific to --overwrite springs to mind)
[23:46] <mwhudson> it just says "fetch up to rev {git-v1:f9b8c7c7aef07f8a7c1646f4f87089ebaea537c3}"
[23:46] <mwhudson> in .bzr.log
[23:47] <mwhudson> i guess i should have said -Dhpss
[23:47] <spiv> Yes.
[23:48] <spiv> Or echo "debug_flags = hpss" >> ~/.bazaar/bazaar.conf
[23:48] <mwhudson> ah right
[23:48]  * mwhudson makes it so, kills and restart
[23:48] <mwhudson> s
[23:49] <mwhudson> spiv: it seems to be appending 100 bytes at a time
[23:50] <mwhudson> 139.403  hpss call w/body: 'append', '/~launchpad-pqm/dulwich/devel/.bzr/repository/upload/x8ptbehx7d83ijydfcqn.pack', '' ('B110\n\n\x1f\x8b\x08\x00\x00\x00\x00\x00\x02\xff\x95\xcc\xc1\r'...)
[23:50] <mwhudson> 139.403                116 bytes
[23:53] <spiv> mwhudson: I'm fairly sure that's not specific to --overwrite.
[23:53] <mwhudson> spiv: probably not
[23:53] <mwhudson> spiv: it's surely very slow though :)
[23:53] <spiv> mwhudson: Basically, upgrade the server, kthxbye ;)
[23:53] <mwhudson> spiv: not helpful
[23:54] <spiv> mwhudson: is this a stacked branch?
[23:54] <mwhudson> i guess it's too late for anything else now though, given that 1.13 is out\
[23:54] <mwhudson> spiv: don't think so
[23:54] <spiv> Hmm, I guess devel/ is the dev focus, so probably not.