| ronny | lifeless: aware of a simple way for automated installs of different bzr versions? | 00:12 |
|---|---|---|
| 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:13 |
| 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:14 |
| 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:16 |
| jelmer | igc: hi | 00:36 |
| igc | hi jelmer | 00:38 |
| jelmer | igc: You mentioned on the list you're working on a patch to support custom rules | 00:40 |
| igc | jelmer: just about to. See http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/51347 | 00:41 |
| igc | jelmer: let me know if that sounds ok to you | 00:42 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| igc | lifeless: me too | 00:57 |
| igc | jelmer: are there tweaks to my proposal that would help you? | 00:57 |
| 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:58 |
| 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 | 00:59 |
| 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:00 |
| igc | jelmer: so perhaps tree.conf is what you want? | 01:01 |
| 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:02 |
| 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:03 |
| igc | jelmer: from memory, the API for looking up rules is on Tree, because rules are path dependent | 01:04 |
| jelmer | igc: But they're not stored as part of a Tree atm | 01:05 |
| 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:06 |
| 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:07 |
| lifeless | james_w: ping | 01:08 |
| jelmer | igc: anyway, even if we can't import rules from svn yet, we can support svn keywords now (-: Thanks! | 01:14 |
| igc | jelmer: well, keeping in mind that our keywords aren't a one-for-one match with svn's ones, yes | 01:20 |
| jelmer | igc: Yeah, but filters should allow the bzr-svn plugin to provide a svn-keywords Contentfilter that does | 01:22 |
| igc | jelmer: absolutely true! | 01:23 |
| 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:24 | |
| igc | night jelmer, and thanks for the input/feedback - much appreciated | 01:25 |
| james_w | hi lifeless | 01:27 |
| lifeless | james_w: can you pastebin your hackjob, or something | 01:27 |
| james_w | http://paste.ubuntu.com/135726/ | 01:30 |
| 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:35 |
| === Ampelbein is now known as ampelbein | ||
| bignose | bzr branch foo/ bar/ && bzr loomify bar/ | 01:53 |
| === ampelbein is now known as Ampelbein | ||
| bignose | cd bar/ && bzr create-thread spam && hack hack hack && bzr commit | 01:53 |
| 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:54 |
| lifeless | bignose: bzr switch spam && bzr push foo/ | 01:57 |
| bignose | okay. so the revision data won't depend on the loom plugin? | 01:57 |
| 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:58 |
| lifeless | yes | 01:59 |
| bignose | thanks. | 01:59 |
| 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:00 |
| lifeless | nope | 02:03 |
| lifeless | the loom won't pollute an existing branch | 02:03 |
| 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:04 |
| 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:05 |
| bignose | doesn't ‘bzr send -r thread:’ do the same thing? (i.e. I thought the end-of-range defaulted to the tip) | 02:07 |
| mwhudson | er | 02:08 |
| 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:09 |
| 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:10 |
| lifeless | anyhow, you'll need to say again, s..> t á d<... wasn't helpful for me | 02:12 |
| bignose | doesn't 'bzr send -r thread:' do the same thing? (i.e. I thought the end-of-range defaulted to the tip) | 02:13 |
| lifeless | unfortunately different commands behave differently | 02:14 |
| lifeless | this has been discussed and is not resolved | 02:14 |
| SamB | bignose: what do you mean, "preserving"? | 02:15 |
| SamB | bignose: are you proposing that each message should have a Charset: header? | 02:15 |
| bignose | SamB: I'm proposing that a text medium should declare the encoding of its content, yes. | 02:16 |
| SamB | now, having "use UTF-8" in the RFC would be nice, I admit ;-) | 02:17 |
| * emmajane waves | 02:17 | |
| ub3rst4r | hi, does anyone know how i can have my launchpad bzr code mirrored onto sourceforge? | 02:21 |
| 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 :) | 02:32 |
| * igc lunch | 03:08 | |
| lifeless | kfogel: ping | 03:12 |
| poolie | hi all | 03:19 |
| * emmajane waves to poolie | 03:22 | |
| emmajane | but then opts for sleep. | 03:22 |
| 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:23 |
| * emmajane chuckles. | 03:24 | |
| emmajane | aight. sleep time! | 03:25 |
| * emmajane waves | 03:25 | |
| === Spaz is now known as Kittens | ||
| === Kittens is now known as Spaz | ||
| === Ampelbein is now known as ampelbein | ||
| lifeless | lunching | 04:04 |
| awmcclain | What's the command to get the revision number of the working revision? (NOT the revisions at head like revno gives) | 04:08 |
| 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:09 |
| spiv | Hmm, I'm not sure if there is a command that does that. | 04:10 |
| awmcclain | Really? | 04:11 |
| awmcclain | Ug. | 04:11 |
| spiv | There certainly should be... | 04:11 |
| * awmcclain cries | 04:11 | |
| * AfC freely admits he doesn't have a clue what is being probed here. | 04:12 | |
| 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:19 |
| spiv | lifeless: ooh, tricksy. | 04:20 |
| lifeless | :> | 04:20 |
| 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:24 |
| spiv | Hmm, actually, I think log still uses the tip from branch rather than the tree? | 04:25 |
| lifeless | yes | 04:25 |
| spiv | We really should have a tree: revspec or something. | 04:28 |
| lifeless | eys | 04:29 |
| 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:47 |
| 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. :-) | 04:48 |
| poolie | i'd agree it's a bug | 05:06 |
| kfogel | lifeless: pong | 05:46 |
| lifeless | so David Reitter is someone in the emacs community? | 05:52 |
| BasicOSX | lifeless: bug 305006 I haven't release 1.13.1 how did Dorin get it to report the bug? Any idea? | 05:56 |
| ubottu | Launchpad bug 305006 in bzr "shelve fails on win32 with "Could not acquire lock"" [Undecided,Fix committed] https://launchpad.net/bugs/305006 | 05:56 |
| BasicOSX | nm, except for the doc changes it's in lp | 05:57 |
| 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:03 |
| 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:04 |
| kfogel | lifeless: filing launchpad bugs or bzr bugs? | 06:05 |
| === r0bby_ is now known as r0bby | ||
| lifeless | bzr bugs | 06:05 |
| lifeless | ciao for the day | 06:16 |
| poolie | night lifeless | 06:51 |
| vila | hi all | 06:58 |
| * igc dinner | 07:01 | |
| poolie | hello vila | 07:03 |
| BasicOSX | bug 347130 | 07:14 |
| ubottu | 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 |
| 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:14 |
| poolie | BasicOSX: thanks | 07:26 |
| poolie | interesting | 07:26 |
| 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:27 |
| BasicOSX | I keep typing bzr-get update bzr, apt, sheesh | 07:31 |
| vila | BasicOSX: :) | 07:44 |
| poolie | ok | 07:50 |
| poolie | relatively early night for me | 07:50 |
| poolie | BasicOSX: bug 347130 is probably pretty easy but if it will still take a little while | 07:51 |
| ubottu | 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 |
| poolie | so i'm not going to do it right now | 07:51 |
| 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 | 07:52 |
| === thekorn_ is now known as thekorn | ||
| jelmer | mwhudson: hi | 10:16 |
| 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:26 |
| gmarselis | http://rafb.net/p/GprFbL61.html | 10:27 |
| gmarselis | i can't wrap my mind around it to find a starting point | 10:27 |
| gmarselis | halp! | 10:28 |
| gmarselis | guess everybody's asleep | 10:38 |
| apw | does bzr in jaunty now do notifications? | 11:18 |
| james_w | bzr-gtk does | 11:20 |
| 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:09 |
| SamB | did you try bzr log already? | 12:12 |
| james_w | jdobrien: does "bzr log -v filename" do what you want? | 12:17 |
| jdobrien | james_w: that works...thanks | 12:21 |
| james_w | cool | 12:21 |
| 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:22 |
| cammoblammo | Hmm, bzr seems to freeze when trying to pull the bzr repo: | 12:48 |
| 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:49 |
| 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:50 |
| 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:52 |
| 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:57 |
| cammoblammo | :-) | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| CBro2007_ | now how do developers manage to update their own branches from a. The MAIN branch or b. Each other's branches directly? | 13:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| CBro2007_ | bob2: last one :) | 13:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| Peng_ | (In that case, if everyone has bzr 1.6 or newer, using stacked branches will help.) | 13:27 |
| 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:30 |
| 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:31 |
| bob2 | no | 13:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| bob2 | no | 13:37 |
| CBro2007_ | k let me test it out... will let you know if I have any dramas then | 13:39 |
| 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. | 13:58 |
| 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:01 |
| 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:02 |
| Peng_ | Ah. | 14:05 |
| 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:09 |
| 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:16 |
| jam | hey vila, give me ~5 minutes, but yeah | 14:17 |
| vila | ok | 14:17 |
| jam | vila: I'm ready for my phone call, Mr. Ladeuil | 14:24 |
| jam | :) | 14:25 |
| vila | Was grabbing the phone already :) | 14:25 |
| 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:44 |
| === ampelbein is now known as Ampelbein | ||
| Peng_ | hunmonk: Bazaar is more or less always compatible. Just use disk formats that both versions support (i.e. not 1.9). | 14:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| CBro2007_ | Um? | 14:57 |
| CBro2007_ | :) | 14:57 |
| CBro2007_ | I suppose if I first do a merge then there will be nothing to diff against? | 14:58 |
| 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 | 14:59 |
| CBro2007_ | thanks | 15:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| === Ampelbein is now known as ampelbein | ||
| CBro2007_ | Hey Peng_ | 15:20 |
| 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:21 |
| 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:22 |
| === ampelbein is now known as Ampelbein | ||
| 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:26 |
| 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:28 |
| CBro2007_ | yep | 15:29 |
| 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:38 |
| Peng_ | CBro2007_: Yeah. | 15:39 |
| 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:40 |
| 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. | 15:41 |
| aelkner | does anyone know how to find out what version of a branch is actually installed on a machine? | 16:22 |
| 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:23 |
| 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:24 |
| exarkun | 'bzr version-info'? | 16:25 |
| aelkner | that worked, thanks | 16:25 |
| 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:26 | |
| aelkner | is there a version of bzr log that takes into account the currently loaded revision number? | 16:27 |
| 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:28 |
| 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:30 |
| Kinnison | Where version-info talks about the working tree | 16:31 |
| aelkner | but bzr log only talks about the branch | 16:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| aelkner | i'm not sure what you mean by that | 16:35 |
| 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:36 |
| aelkner | issuing the command bzr log --working_tree would be nice to be able to do | 16:37 |
| Peng_ | Better would be a revision spec, so you could do e.g. "bzr log -r tree:". | 16:38 |
| 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:42 |
| aelkner | s/repository/branch for my previous comment | 16:43 |
| 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 | 16:45 |
| aelkner | Peng_: i sinned and failed to mention that i was dealing with a light checkout and not a branch | 17:02 |
| 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:03 |
| 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. | 17:04 |
| === apw is now known as cafetiere | ||
| === cafetiere is now known as apw | ||
| 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:35 |
| bitmonk | there is a bug that the message could be clearer, but i'm not sure i need that fix to move on ;) | 18:41 |
| Peng_ | bitmonk: Are you trying to branch into a shared repository? | 18:45 |
| bitmonk | Peng_: nope, just from one into a deployment location. | 18:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:52 |
| 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:53 |
| mwhudson | jelmer: hello | 18:54 |
| 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:04 |
| 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:05 |
| 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:15 |
| 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:19 |
| Peng_ | Hmm, it would be neat if there was an "lp+http" URL scheme though. | 19:20 |
| 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:21 |
| 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:22 |
| mwhudson | jelmer: still am :) | 19:23 |
| mwhudson | jelmer: why does lp:dulwich have completely new, bzr-git-ish, history? | 19:23 |
| 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:25 |
| 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:28 |
| 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:30 |
| 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:32 |
| 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:34 |
| mwhudson | jelmer: i'll just have to smile sweetly at the OSAs to get them to run pull --overwrite a couple of times :) | 19:37 |
| 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:39 |
| 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:40 |
| mwhudson | LarstiQ: the code to do the import is mostly written, there's some ui work | 19:41 |
| mwhudson | but that shouldn't be hard | 19:42 |
| mwhudson | so maybe it'll be done for the april rollout | 19:42 |
| 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:43 |
| mwhudson | jelmer: nope, "pull" | 19:44 |
| jelmer | ah, neat | 19:44 |
| mwhudson | will do the same for bzr-svn sooner or later | 19:44 |
| mwhudson | (probably we'll do something where new imports use bzr-svn and old ones continue to use cscvs) | 19:45 |
| jelmer | mwhudson: ah, neat | 19:46 |
| 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:50 | |
| 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:51 |
| jelmer | LarstiQ: is this the bug we were debugging earlier? | 19:54 |
| jelmer | mwhudson: 0.5 is working out pretty well | 19:54 |
| LarstiQ | jelmer: nope! | 19:55 |
| LarstiQ | jelmer: same project though | 19:55 |
| LarstiQ | jelmer: but now it's push failing with an assert | 19:56 |
| jelmer | mwhudson: I'm thinking of doing a 1.0 quite soon (perhaps together with 1.15) | 19:57 |
| jelmer | LarstiQ: is there a bug open yet? I might be able to fix something based on the assertion.. | 19:58 |
| 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. | 19:59 |
| 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:01 |
| 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:02 |
| LarstiQ | brink: http://bazaar-vcs.org/BzrPlugins in general, lp:bzr-fastimport in specific iirc | 20:03 |
| 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:04 |
| 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:05 |
| 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:09 |
| 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:11 |
| jelmer | brink: and you need a patch for bzr to push from bzr into git | 20:12 |
| LarstiQ | Pieter: aha! :) | 20:12 |
| 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:13 |
| 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:14 |
| LarstiQ | Pieter: I wondered who that pieter of git-bzr was. | 20:15 |
| Pieter | ah :) | 20:16 |
| brink | jelmer: I'm at version 1.2. I'll update it. | 20:16 |
| 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:30 |
| brink | jelmer: http://pastebin.com/m30ee2bd7 | 20:32 |
| LarstiQ | brink: ok, bzr-git shouldn't mess with other bzr invocations | 20:33 |
| 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:34 |
| * jelmer back in ~40 min | 20:38 | |
| LarstiQ | brink: did that help? | 20:47 |
| 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:49 |
| LarstiQ | brink: let me dig up jelmer's patch | 20:51 |
| LarstiQ | brink: I suppose he meant http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49C6A5B7.1050105%40vernstok.nl%3E | 20:52 |
| LarstiQ | brink: so, in bzr.dev: `bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C49C6A5B7.1050105@vernstok.nl%3E` | 20:53 |
| LarstiQ | ok | 20:54 |
| 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:55 |
| brink | LarstiQ: It seems to have merged and installed successfully. Do you know the command to try the conversion by any chance? | 20:59 |
| LarstiQ | brink: `bzr dpush path/to/git/branch` I think | 21:02 |
| 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:03 |
| brink | LarstiQ: It seems my version of Dulwich is too old. http://pastebin.com/m3050c87f | 21:04 |
| 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:07 |
| 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:08 |
| thumper | I am using some code for preview trees | 21:09 |
| 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:10 |
| LarstiQ | brink: we're bad like that, sorry :/ | 21:11 |
| 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:12 |
| LarstiQ | brink: (I'm slowly learning Finnish, their English is also good enough usually) | 21:13 |
| 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:16 |
| 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:17 |
| * LarstiQ investigats why the os module might not have fdatasync | 21:21 | |
| LarstiQ | brink: are you on !unix? | 21:22 |
| LarstiQ | brink: ah, OSX | 21:22 |
| LarstiQ | brink: this reminds me of a Firefox/sqlite thread on fsync | 21:23 |
| 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:24 |
| jelmer | SamB: you'll need a newer dulwich than the last release | 21:25 |
| jelmer | s/samb/brink/ | 21:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| LarstiQ | jelmer: boohoo, I get a different assert. | 21:40 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| dash | hmm. the one at http://samba.org/~jelmer/bzr-svn/FAQ.html ? | 21:48 |
| 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:49 |
| * 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:51 |
| 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:52 |
| 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:53 |
| jelmer | stianse_: what do you mean with "in effect" ? | 21:54 |
| 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:56 |
| 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:57 |
| 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:58 |
| stianse_ | jelmer: ok. perhaps I'll get some tips if I look in the source code of bzr-nm | 21:59 |
| jelmer | stianse_: bzr branch is at http://people.samba.org/bzr/jelmer/bzr-nm/trunk | 22:00 |
| stianse_ | jelmer: thanks. i'll see if this solves the problem | 22:02 |
| jelmer | stianse_: IIRC you need to call bzrlib.commands.get_cmd_object | 22:03 |
| === abentley1 is now known as abentley | ||
| BasicOSX | Someone with op please /topic 1.13.1 released 23 Mar | 22:06 |
| LarstiQ | BasicOSX: it didn't get through to the announce list yet? | 22:10 |
| BasicOSX | not yet | 22:10 |
| === bob2 changed the topic of #bzr to: Bazaar version control system | 1.13.1 released 23 Mar | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| 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:15 |
| joschan | thank you! | 22:16 |
| 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:17 |
| stianse_ | jelmer: used what's in bzr-nm except from adding decorate=True to the register_command call | 22:18 |
| 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:19 |
| jelmer | stianse_: cool | 22:25 |
| stianse_ | jelmer: By the way, is this considered a workaround or the correct way of doing it? | 22:27 |
| stianse_ | Because if this should work, both plugins need apply this approach | 22:28 |
| 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:29 |
| lifeless | hai, I has net | 22:39 |
| bob2 | ph33r | 22:40 |
| emmajane | \o/ for innnnernets | 22:40 |
| jelmer | stianse_: no, this is the proper way | 22:42 |
| === spm_ is now known as spm | ||
| lifeless | now, foods | 22:45 |
| 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:48 |
| * igc breakfast | 22:49 | |
| stianse_ | jelmer: I was just about to commit actually :) | 22:49 |
| lifeless | spiv: shall we pair today? | 23:23 |
| spiv | lifeless: yeah | 23:24 |
| spiv | lifeless: I don't have much preference about venue | 23:27 |
| lifeless | spiv: Lynne is out all day, so here works well for me. | 23:29 |
| spiv | lifeless: ok, I'll head to Epping then. | 23:32 |
| mwhudson | are there any known sillinesses with push --overwrite over bzr+ssh from bzr.dev to bzr 1.12? | 23:43 |
| 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:46 |
| mwhudson | i guess i should have said -Dhpss | 23:47 |
| spiv | Yes. | 23:47 |
| 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:48 |
| mwhudson | spiv: it seems to be appending 100 bytes at a time | 23:49 |
| 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:50 |
| 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:53 |
| 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. | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!