| lifeless | vila: ping | 01:04 |
|---|---|---|
| vila | lifeless: zzz pong zzz | 01:06 |
| lifeless | vila: your patch is wrong :) | 01:06 |
| lifeless | vila: because it decodes a fs output which may not be utf8 | 01:06 |
| lifeless | vila: which is why we should fix tree.get_symlink_target | 01:07 |
| vila | lifeless: isn't tree a revision tree here ?? | 01:08 |
| lifeless | no | 01:08 |
| === VSpike_ is now known as VSpike | ||
| jelmer | yay | 01:16 |
| jelmer | after more than a year, I finally have a current copy of samba in bzr again | 01:16 |
| lifeless | cool | 01:21 |
| lifeless | spiv: are we getting together? | 02:19 |
| spiv | lifeless: not today, I'd be keen to pair tomorrow though. | 02:45 |
| * spiv is off to lunch | 02:45 | |
| === ja1 is now known as jam | ||
| johnf | when running a hook I don't suppose the current revno gets put into the environment somewhere? | 03:07 |
| lifeless | johnf: a shell hook or python hook? | 03:09 |
| lifeless | the former I dunno, the latter - its available via the api | 03:09 |
| johnf | lifeless: shell | 03:09 |
| johnf | yeah I just ran env as a hook and there is nothing there | 03:10 |
| johnf | might have to do something evil with builddeb pre-export and pre-build hooks using a temporary file | 03:11 |
| lifeless | are they not python hooks? | 03:11 |
| johnf | Basically I want access to the revno inside the build dir | 03:11 |
| johnf | probably | 03:12 |
| lifeless | Are they fired by builddeb itself? | 03:12 |
| johnf | let me see | 03:12 |
| lifeless | if they are fired by builddeb, use the bzr Hook infrastructure instead | 03:12 |
| lifeless | change the shell hooks to be hooks in that infrastructure, then you can write your hooks in pythn | 03:13 |
| johnf | builddeb has a run_hook method which uses popen so I'm guessing they don't use the hook infrastructure | 03:13 |
| pjz | is it possible that I lost content if I had files in mworking dir when I typed 'bzr rebase' ? | 03:33 |
| pjz | they seem to be gone | 03:33 |
| pjz | which makes me a bit unhappy | 03:33 |
| thumper | what is the way to create a new branch in format say 1.9 format using bzrlib? | 03:36 |
| lifeless | thumper: look at builtins.py, cmd_init | 03:40 |
| === TheMuso_ is now known as TheMuso | ||
| pjz | any chance that my content that looks lost is really stored somewhere else? | 03:43 |
| pjz | how do I list branches? | 03:44 |
| lifeless | pjz: bzr branches [optional url] | 03:44 |
| lifeless | pjz: you may have shelved it | 03:45 |
| lifeless | pjz: or it could be a dead head (bzr heads --dead) | 03:45 |
| pjz | lifeless: ah! bzr heads --dead found it! now... how do I bring it back? | 03:46 |
| lifeless | pjz: you can pull it or merge it, using -r revid:REVISIONID | 03:48 |
| pjz | lifeless: how can I change the parent branch of a checkout? | 03:54 |
| pjz | lifeless: b/c the repo it's in has a bogus parent branch set, so trying to pull -r it tries to pull that bogus parent branch and fails | 03:54 |
| lifeless | pjz: bzr unbind | 03:56 |
| lifeless | pjz: or bzr switch | 03:56 |
| lifeless | unbind stops it being a checkout, but if the parent is deleted you can get around that | 03:56 |
| lifeless | oh | 03:56 |
| lifeless | pjz: "bzr pull . -r revid:REVID" | 03:56 |
| pjz | lifeless: ah! thanks muchly! | 03:59 |
| pjz | lifeless: is there a doc that describes how to use branches of a project on launchpad correctly? Like I registered and created a branch to push to, but got into trouble not knowing how to rebase up once the upstream branch advanced some | 04:00 |
| lifeless | pjz: why would you rebase? | 04:00 |
| lifeless | pjz: with bzr people generally just merge from trunk | 04:00 |
| pjz | lifeless: uh... how else do I movemy work to top of tree? | 04:00 |
| pjz | lifeless: ah, okay | 04:01 |
| lifeless | rebase seems to be a very git thing | 04:01 |
| lifeless | most other vcs's don't need it anywhere near as much | 04:01 |
| pjz | well, they do it differently | 04:02 |
| pjz | everytime you do an 'update' in svn or cvs, that's really a rebase of your working tree onto the trunk | 04:02 |
| lifeless | pjz: you can do 'bzr update' too, when you have a checkout of trunk | 04:03 |
| lifeless | that pivots your work into a pending merge on the old tip of trunk | 04:03 |
| pjz | lifeless: okay, so anyway, is there a 'usual-workflow' doc of bzr & launchpad somewhere? | 04:04 |
| pjz | lifeless: so what should my initial checkout be of? my branch? or the trunk? | 04:04 |
| lifeless | I don't think there is; there are ones for bzr | 04:04 |
| lifeless | and launchpad just expects any normal use of bzr | 04:04 |
| pjz | lifeless: ah, okay. is there a good bzr workflow doc somewhere then? | 04:04 |
| lifeless | doc.bazaar-vcs.org has the users guide, reference manual etc | 04:04 |
| lifeless | in short though, its usually | 04:05 |
| lifeless | bzr branch trunk myfeature | 04:05 |
| lifeless | hack and commit in myfeature | 04:05 |
| Peng_ | Ehh, is it possible to set "log --levels N" for all commands that show logs, not just "log"? | 04:05 |
| lifeless | if trunk changes, cd myfeature, bzr merge $trunk; bzr commit -m 'merge trunk' | 04:05 |
| lifeless | when the feature is done, | 04:05 |
| lifeless | cd trunk; bzr merge $myfeature; bzr commit -m 'myfeature is finished' | 04:05 |
| lifeless | pjz: both cvs and svn can do merges as well as updates btw :) | 04:06 |
| pjz | lifeless: oh, so I have to keep a trunk tree and a branch tree both around? | 04:06 |
| lifeless | pjz: either that or use bzr switch to move a checkout between branches | 04:06 |
| lifeless | with a checkout its | 04:07 |
| lifeless | bzr branch trunk myfeature; cd $checkout; bzr switch myfeature; hack commit etc; bzr switch trunk; bzr merge myfeature && bzr commit -m 'feature done' | 04:07 |
| lifeless | pjz: if its a small project, just have a couple of trees, if its big like emacs/python etc, you'll want a shared repo setup (bzr init-repo /src/repo --no-trees), which means that making new branches will not setup working trees | 04:08 |
| lifeless | pjz: and then you'd use switch | 04:08 |
| lifeless | pjz: this is a bit of a wart on our UI, and we're discussing at the moment how to fix this while still keeping the things we love (that branches have real url's mainly) | 04:09 |
| lifeless | pjz: does this make sense? | 04:10 |
| pjz | lifeless: mrm, yeah, somewhat | 04:11 |
| thumper | ?!? Ignoring request for a stacked branch as repository already exists at the destination location. | 04:14 |
| thumper | it lies | 04:14 |
| thumper | I supplied --stacked-on | 04:14 |
| lifeless | thumper: you're pushing somewhere that has a repo already | 04:16 |
| thumper | lifeless: no I'm not | 04:16 |
| thumper | lifeless: I'm pushing to launchpad | 04:16 |
| lifeless | thumper: no chance that you had a partial push already at that url with a repo and no branch? | 04:16 |
| thumper | none at all | 04:17 |
| thumper | the branch didn't exist before | 04:17 |
| lifeless | then file a bug | 04:17 |
| pjz | lifeless: so you still haven't told me how to set the parent branch of a checkout | 04:17 |
| thumper | lifeless: what does walking content mean when inserting stream? | 04:18 |
| lifeless | pjz: pull --remember | 04:18 |
| lifeless | thumper: its a progess message from the guts | 04:18 |
| thumper | lifeless: handy | 04:18 |
| pjz | lifeless: thanks muchly | 04:20 |
| pjz | lifeless: for all the help | 04:21 |
| lifeless | pjz: my pleasure | 04:21 |
| pjz | lifeless: and I think things will be nicer when you can address branches in the same repo | 04:21 |
| pjz | lifeless: which should be fairly easy - just pick some separator char or path or something | 04:21 |
| pjz | lifeless: so file://foo/bar/baz/.bzr/onebranch means 'in repo file://foo/bar/baz, branch onebranch' | 04:22 |
| pjz | lifeless: b/c the real cool thing about URLs is that they can be virtual :) | 04:22 |
| lifeless | pjz: so, you can already, 'bzr switch' for instances knows to lookup relative to the current branch | 04:23 |
| lifeless | pjz: but yes we need to do something to make this better | 04:23 |
| pjz | lifeless: also once you get this you should be able to do things like add /parent and /push subpaths to the branch to make them addressable | 04:24 |
| pjz | lifeless: er, to the branch URI | 04:24 |
| lifeless | pjz: what do you mean? | 04:24 |
| pjz | lifeless: well so if I have a branch 'feature1' from a trunk 'trunk', and 'feature1' has a subbranch called 'bugfix1', I could maybe merge it all the way to the trunk by just doing a merge with feature1/parent instead of having to remember trunk's URL | 04:26 |
| lifeless | so at the moment | 04:26 |
| lifeless | if I have three branches | 04:26 |
| lifeless | /trunk, /feature1, /bugfix1 | 04:27 |
| lifeless | and a checkout of bugfix1 | 04:27 |
| lifeless | I can do | 04:27 |
| lifeless | 'bzr switch trunk' | 04:27 |
| lifeless | to go direct to trunk without remembering the url | 04:27 |
| lifeless | repositories are just storage to bzr, we don't need to make them more than that to get nicer paths | 04:28 |
| lifeless | what it needs though is the core performance stuff we're working on for 2.0 finished | 04:28 |
| lifeless | then I and others can spend some serious time on UI | 04:28 |
| pjz | lifeless: how do you list what branches are in a repo? | 04:29 |
| lifeless | bzr branches | 04:29 |
| lifeless | which looks at . | 04:29 |
| lifeless | unless you give it a url | 04:29 |
| pjz | lifeless: wow, I get a blank line when I run that | 04:29 |
| pjz | lifeless: so I have no branches? | 04:29 |
| pjz | or one with an empty name? | 04:29 |
| lifeless | one with an empty name I'd say | 04:29 |
| lifeless | as it defaults to looking in . :) | 04:30 |
| pjz | lifeless: so I've got a branch named '', a parent branch of http://trunk and a push-branch of lp:mybranch | 04:31 |
| pjz | lifeless: aaand a submit-branch of the old absolute path to ., that changed when I renamed what .. calls . | 04:32 |
| pjz | any way I can update the submit path? | 04:35 |
| pjz | er, submit branch | 04:36 |
| lifeless | bzr submit branch-to-submit-against --remember | 04:36 |
| lifeless | erm | 04:36 |
| lifeless | s/submit/send | 04:36 |
| pjz | lifeless: any way to do it without actually doing a send? | 05:09 |
| lifeless | pjz: you can edit the config setting directly | 05:10 |
| lifeless | its the submit_branch setting (and see bzr help configuration for details on the configuration stuf) | 05:11 |
| cody-somerville | wow | 06:08 |
| cody-somerville | bzr just caused me a lot of data loss | 06:08 |
| lifeless | orly? | 06:08 |
| cody-somerville | I was trying to get bzr to recognize that I had moved some directories around | 06:09 |
| cody-somerville | as I had moved a ton of directories in the cwd into a new, unversioned directory called desktop-guide | 06:09 |
| cody-somerville | I did bzr --after libs/ desktop-guide/ | 06:09 |
| cody-somerville | and then when I went to try to move something else into desktop-guide, it told me desktop-guide was already versioned | 06:09 |
| cody-somerville | so I did bzr status and saw that bzr had moved libs to desktop-guide | 06:10 |
| cody-somerville | not desktop-guide/libs/ | 06:10 |
| cody-somerville | so I did bzr revert libs/ to undo that | 06:10 |
| cody-somerville | and so bzr deleted desktop-guide and brought back libs <g> | 06:10 |
| cody-somerville | not quite what I wanted at all | 06:10 |
| lifeless | that is what you asked it to do | 06:10 |
| lifeless | bzr revert is not 'undo the last command' | 06:10 |
| lifeless | its 'put things back to the way they were in the last commit' | 06:11 |
| cody-somerville | Right | 06:11 |
| cody-somerville | I thought it would bring back libs/ | 06:11 |
| cody-somerville | not delete desktop-guide | 06:11 |
| cody-somerville | I understand why it did | 06:11 |
| lifeless | it should ahve created backup files | 06:12 |
| lifeless | and they are probably in libs | 06:12 |
| cody-somerville | oh weird | 06:13 |
| cody-somerville | Its like it merged the two directories together | 06:13 |
| lifeless | night all | 06:44 |
| vila | hi all | 07:22 |
| cody-somerville | When will bzr work with python2.6? | 07:23 |
| gour | hi, what's going on with bzr lately (considering both gnome and python 'missed' it)? | 07:24 |
| cody-somerville | nvm | 07:26 |
| cody-somerville | I had hardy ppa enabled and not jaunty | 07:26 |
| cody-somerville | gour, to answer your question, I heard they were working on a revolutionary new storage engine or something that is super fast and takes up very little disk space | 07:26 |
| gour | cody-somerville: i must say that i played a lot with bzr (after moving from darcs), but have tendency to go back seeing (too) many format options in bzr not being able to settle on something :-( | 07:28 |
| cody-somerville | gour, why? It doesn't really affect you or me. | 07:28 |
| RAOF | cody-somerville: That'd be brisbane-core, which, if I understand it correctly, will allow the devs to fix all the bugs I care about, and implement (almost) all the features I care about. | 07:29 |
| cody-somerville | indeed | 07:30 |
| gour | cody-somerville: well, it does not impress one - storage format is one of the important issues for VCS | 07:30 |
| gour | cody-somerville: and in the meantime most major players will migrate....and it will be extremely difficult to get 'em back | 07:31 |
| cody-somerville | gour, Right and bazaar is continuing to innovate in that area providing you and me with improved performance and more features transparently | 07:32 |
| RAOF | To a certain extent, as long as bzr-git works, I don't much care. | 07:37 |
| cody-somerville | So what features are you interested in RAOF? | 07:38 |
| RAOF | So, I'd like, in no particular order: push to not push a minimum of 1Mb of data, at a rate < 10K/sec (roundtripping to .uk!). 'bzr externals' type support. Pull to nearly saturate downstream bandwith (less roundtrippin' to UK!) | 07:42 |
| RAOF | Some other random stuff that I can't remember right now, too. | 07:42 |
| Peng_ | RAOF: What version of bzr do you run? There were push & pull improvements in 1.12 or 1.13. | 08:12 |
| Peng_ | (or both?) | 08:12 |
| RAOF | Peng_: 1.13; Jaunty default. | 08:24 |
| igc | hi vila | 08:26 |
| igc | vila: I'm seeing 2 test failures running 'bzr selftest groupcompress' in brisbane-core | 08:27 |
| igc | vila: do you know if anyone is working on fixing those? | 08:27 |
| vila | igc: there is a python version of gc that should land soon, what failures are you seeing ? | 08:28 |
| igc | test_insert_record_stream_existing_keys | 08:28 |
| vila | igc: by the way, I just fixed 3 more failures in test_commit_with_revision_id_record_iter_changes | 08:29 |
| igc | once for groupcompress and once for groupcompress-graph | 08:29 |
| vila | ha yes, those ones, no, nobody is on it yet AFAIK | 08:30 |
| enquest | I'm following http://bazaar-vcs.org/BazaarForWebDevs | 09:00 |
| enquest | this line does not work python setup.py build_ext -i | 09:00 |
| enquest | there is not setup file created when you get the branch bzr branch https://launchpad.net/bzr-push-and-update bzr_push_and_update | 09:00 |
| vila | enquest: forget it, that's a typo, this is not needed | 09:02 |
| enquest | maybe somebody wants to change it http://bazaar-vcs.org/BazaarForWebDevs | 09:03 |
| enquest | thxs | 09:04 |
| vila | enquest: hit refresh :) | 09:05 |
| enquest | :) | 09:05 |
| vila | and the command should really be: bzr branch https://launchpad.net/bzr-push-and-update push_and_update | 09:05 |
| vila | note: no leading 'bzr_' for the plugin directory name | 09:05 |
| === thekorn_ is now known as thekorn | ||
| ronny | yo | 09:46 |
| ronny | is there any command that will tell me what history i'll get if i pull/merge with a remote? | 09:46 |
| Kinnison | What you will get? | 09:47 |
| Kinnison | the 'missing' command might be what you're after | 09:47 |
| Kinnison | type 'bzr help missing' and take a look at the usage | 09:47 |
| vila | igc: ping | 09:50 |
| igc | hi vila | 09:50 |
| ronny | hmm | 09:51 |
| igc | vila: I've got to run sorry - dinner | 09:51 |
| igc | bbl | 09:51 |
| vila | igc: there is a thred in bazaar@lists.canonical.com about these failures: VF.insert_record_stream() with duplicates in stream | 09:51 |
| vila | igc: so jam is indeed aware of the problem and already working on possible solutions, sorry I didn't make the link sooner | 09:52 |
| ronny | oh dammit | 09:52 |
| ronny | it doent tell me about all changes, but only the last merge | 09:52 |
| vila | ronny: bzr missing | 09:52 |
| ronny | vila: yes, exactly that one ... | 09:53 |
| ronny | only shoes the latest merge in the remote, not all of the changes | 09:53 |
| vila | ronny: hmm, bzr version ? | 09:54 |
| ronny | 1.13.1 | 09:54 |
| vila | by alll the changes you mean merged revisions ? | 09:56 |
| ronny | i want to see all revs | 09:56 |
| ronny | not just merges | 09:56 |
| vila | bzr pull -v should still show all merged revisions :-/ igc is working on log and changed some defaults, you may be seeing a side-effect here | 09:58 |
| vila | ronny: if you got the the revision range you're interested into (from missing) you can still do: | 09:58 |
| vila | bzr log <remote_branch_url> -r <revision_range> --levels 0 | 09:59 |
| lifeless | ronny: bzr missing --include-merges | 10:19 |
| ronny | lifeless: the description of that in the help is DAMN confusing and missleading | 10:26 |
| ronny | "--include-merges Show merged revisions." - my first tought about that was "hu? it shows the merges already" | 10:26 |
| fullermd | That sounds like mtn-thinking carryover. | 10:28 |
| vila | ronny: how would you make the distinction between the merging revision and the merged revisions ? | 10:30 |
| === thekorn_ is now known as thekorn | ||
| vila | ronny: is 'Show all revisions in addition to the mainline ones.' clearer ? | 10:34 |
| ronny | vila: yes, that would be very good | 11:11 |
| ronny | fullermd: well, mtn was my first dvcs | 11:11 |
| ronny | (and the first vcs i could actually use nicely, cause svn is a clusterfuck) | 11:11 |
| fullermd | I'm not saying it's bad, just that mtn --no-merges and bzr --include-merges talk about completely different things... | 11:15 |
| fullermd | Emergent both, kinda. | 11:15 |
| Theuni1 | owd | 11:36 |
| Theuni1 | Here is a question that might be a bit more general than just Bazaar. But I'm wondering: in a central environment (company) it sounds strange that DVCS can't manage multiple branches that belong to the same project and make sure that a developer never can delete history: pushes always seem to be just mere file system accesses so I as a developer can also just go ahead and delete that branch and any history of it. | 11:38 |
| Theuni1 | Is there a practice in Bazaar to avoid this? | 11:38 |
| Theuni1 | I'm also suspicious that LP does part of that job, but that's a no-go as it's not open source. | 11:39 |
| SamB | what? never throw branches that didn't work out?? | 11:41 |
| SamB | if you have to worry about that happening, I think you need to pay your people more ;-P | 11:42 |
| Edulix | hi | 11:45 |
| Peng_ | Theuni1: You can totally nuke stuff on Launchpad. | 11:45 |
| Edulix | so I do bzr pull, and it downlads a new revision. without messing with the revno, how to do a bzr diff between the last revision and current one? | 11:45 |
| Edulix | bzr diff -1.. or something like that? | 11:46 |
| LeoNerd | Theuni1: It sounds like you're worrying about intentional deletes from, say, an audit perspective; rather than accidental ones during normal workflow | 11:46 |
| Peng_ | Edulix: bzr di -c -1? | 11:46 |
| Peng_ | Edulix: That shows what changes were introduced by revision -1 (aka the most recent revision). | 11:46 |
| Edulix | Peng_: thanks | 11:48 |
| bob2 | Theuni1: ask on the list | 11:48 |
| spiv | Theuni1: you can always deny developers direct write access to the central branches, and make them go via a gatekeeper tool like PQM (https://launchpad.net/pqm). That's probably overkill, and with DVCS it will always be possible for a dev to make a non-central branch that you don't even know exists. | 11:57 |
| njpatel | Hey, is there something like svn:externals for bzr? | 12:46 |
| james_w | njpatel: not yet | 12:46 |
| james_w | well, there is, but not production quality | 12:46 |
| james_w | hopefully in a month or two that will change as Aaron is working on it | 12:47 |
| njpatel | james_w: hey! I thought as much :) | 12:47 |
| njpatel | cool, it would be pretty useful | 12:47 |
| vila | igc: back ? | 12:47 |
| === thekorn_ is now known as thekorn | ||
| spiv | lifeless: fresh comment on http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html btw | 12:54 |
| igc | vila: hi | 12:55 |
| vila | igc: groupcompress has evolved quite a bit with the introduction of the python implementation, I'm about to push it to bcc | 12:55 |
| vila | bbc even | 12:57 |
| igc | vila: can you merge my code cleanups easily? | 12:57 |
| vila | I don't think so | 12:57 |
| vila | igc: let me try | 12:58 |
| igc | vila: thank-you | 12:58 |
| vila | igc: :-/ conflicts all over the place as I fear | 12:59 |
| vila | The main part you modified has been split into implementation specific classes and some of your points were already addressed, the conflicts are a total mess | 13:00 |
| igc | vila: it shouldn't be too hard, though messy, to apply the changes by hand | 13:03 |
| igc | vila: most of them are assert -> AssertionError | 13:03 |
| igc | and some variable renaming & docstring corrections | 13:04 |
| vila | I'm about to start again on the assertions | 13:04 |
| igc | vila: I guess I can apply them tomorrow by hand | 13:05 |
| igc | but I'd appreciate any you knock off tonight | 13:05 |
| vila | igc: I think it ill be eaiser for you to see what still applies tommorow, I'll try to see what I can do until then | 13:06 |
| igc | vila:np | 13:07 |
| Theuni1 | spiv: pqm seems to be overkill indeed, as handling *many* small projects with it seems to have too much overhead. | 13:08 |
| Theuni1 | bob2: I probably will. | 13:08 |
| Theuni1 | spiv: Actually I kinda also worry about accidental deletes. Not so much toolwise (although bzr push did at some point screw up branches on LP having to delete them) but more from the perspektive that e.g. in Subversion creating or deleting a branch is a managed operation under SCM perspective. | 13:09 |
| Theuni1 | Which allows me to get notified when new branches get created destroyed. One of the purposes of DVCS obviously is not having to do that, but I think it might be a worthwhile scenario to support if wanted. | 13:09 |
| spiv | Theuni1: if you require that all access is via a smart server, you could do that. | 13:10 |
| Theuni1 | spiv: interesting. that was one of the answers i hoped for. i find the documentation of the smart server a bit lacking. ;) | 13:10 |
| Theuni1 | I'll digg deeper into the smart server then. | 13:10 |
| spiv | Theuni1: well, except that there's no way to delete branches via the smart server yet (or with the "bzr" command in general) | 13:11 |
| Theuni1 | I'm fine with that for now. :) | 13:11 |
| spiv | Theuni1: but if/when the command does, the smart server should export a hook point you can use to find out about | 13:11 |
| Theuni1 | Can the smart server export multiple branches of multiple shared repositories? | 13:11 |
| spiv | The basic tool you probably want is the "post_change_branch_tip" hook. | 13:11 |
| spiv | Yes, it just serves a filesystem. | 13:12 |
| Theuni1 | Even more interesting. | 13:12 |
| Theuni1 | I wonder whether I'm blind or the docs are evading me. | 13:12 |
| spiv | (Or a bzr transport, in fact, you could write your own virtual fs...) | 13:12 |
| Theuni1 | I'm happy not to write too much tool-stuff myself. ;) | 13:12 |
| spiv | Some caveats: the smart server still allows arbitrary file-level operations that won't trigger any hooks, so someone could still delete stuff and what have you by scripting with bzrlib. | 13:13 |
| Theuni1 | I didn't quite get the ending of that sentence. | 13:13 |
| spiv | (Although we're getting closer to being able to turn that off; most of the operations are now done through higher-level network RPCs rather than file RPCs) | 13:13 |
| Theuni1 | spiv: Exactly those higher-level RPCs is what I'm looking for. | 13:14 |
| spiv | Well, you don't really want to be dealing with RPCs, you want to use the hooks. | 13:14 |
| spiv | post_change_branch_tip is the one you want. | 13:14 |
| Theuni1 | Right. | 13:14 |
| Theuni1 | But you need to make your own abstraction over the file RPCs to achieve that ;) | 13:14 |
| spiv | Also, you want to set append_revisions_only in your branches' branch.conf probably | 13:14 |
| spiv | The caveat about the file RPCs is just to say that it isn't watertight yet. | 13:15 |
| spiv | It will be. | 13:15 |
| Theuni1 | Would the smart server be able to enforce that for all branches it handles? | 13:15 |
| * spiv -> gone | 13:15 | |
| Theuni1 | spiv: thanks a lot! | 13:15 |
| Theuni1 | Even if there's stuff in the future, I'm happy to hear about the direction you're going.\ | 13:15 |
| Theuni1 | I'll look into the smart server. | 13:15 |
| === abentley1 is now known as abentley | ||
| === thekorn_ is now known as thekorn | ||
| === jelmer is now known as Guest67595 | ||
| === Guest67595 is now known as jelmer | ||
| jelmer | moin | 14:33 |
| === ja1 is now known as jam | ||
| ivangarcia | hi guys, I'm having a problem when pushing the code of my project | 14:55 |
| ivangarcia | i got this error | 14:55 |
| ivangarcia | bzr launchpad-login chaos.proton | 14:55 |
| ivangarcia | bzr: ERROR: Connection error: curl connection error (SSL certificate problem, verify that the CA cert is OK. Details: | 14:55 |
| ivangarcia | error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed) | 14:55 |
| ivangarcia | on https://launchpad.net/%7Echaos.proton/%2Bsshkeys | 14:55 |
| ivangarcia | any help ? | 14:55 |
| james_w | it looks like you need to make curl aware of the CA certificate | 14:56 |
| vila | ivangarcia: try installing ca-certificates > | 14:56 |
| ivangarcia | hmm, I have slackware, is there a package for it? | 14:58 |
| vila | ivangarcia: I don't know, but then you'd better search what ssl implementation curl is using and whether or not there is such a thing as CA certificates installed system wide | 15:04 |
| ivangarcia | thks vila | 15:05 |
| vila | ivangarcia: if you don't care about certificate validation, you can also just use the urllib based http implementation instead of the pycurl one | 15:05 |
| vila | ivangarcia: if you find the certificates but can't make curl/pycurl find them, you may want to look into bzrlib/transport/http/ca_bundle.py which gives some hints (mostly used on windows, but should apply in your case too) | 15:11 |
| vila | ivangarcia: roughly, you make the env variable CURL_CA_BUNDLE points to the appropriate ca-bundle.crt file (*finding* that file is left as an exercise ;-) | 15:12 |
| jam | vila: did you spend time working on resolving Ian's cleanup patch? Or should I go ahead and do that? | 15:23 |
| vila | jam: I'm doing it as I replace the assertions, go fix InterDiffering ;-) | 15:24 |
| jelmer | vila: Submitted a fix for 256612 >-) | 15:26 |
| jelmer | bug 256612 I mean | 15:26 |
| ubottu | Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612 | 15:26 |
| vila | jelmer: will look into it | 15:31 |
| jelmer | vila: thanks | 15:38 |
| jam | vila: do you have a quick list of the test that is failing because of "inter-differing"? | 15:38 |
| jam | I think I have a fix, and just don't want to wait for everything to finish | 15:38 |
| vila | jam: -s bt.per_repository.test_fetch.TestFetchSameRepository.test_fetch_to_knit3 (for the 2 errors) | 15:41 |
| vila | jam: -s test_fetch.Test1To2Fetch.test_two_fetch_changed_root -s test_fetch.TestFetch.test_fetch_incompatible (for the 2 failures) | 15:42 |
| jam | vila: the "test_fetch_to_knit3" has been fixed, I'll work on the other | 15:57 |
| vila | jam: yeah :) | 15:57 |
| jelmer | igc: are you at PyCon? | 16:09 |
| mwhudson | jelmer: no | 16:14 |
| jam | vila: the other two tests now pass | 16:20 |
| jam | So I've fixed the 4 cases above | 16:20 |
| jam | any others? | 16:20 |
| igc | jelmer: Brisbane and about to go to sleep :-) | 16:21 |
| jam | igc: it is what, 5am there? | 16:22 |
| jam | ah, I guess only 1:30am | 16:22 |
| vila | jam: let me see... 4err, 3fail - 2err -2fail -2err, that leaves only the asserts :) | 16:24 |
| jelmer | igc: ahh :-) | 16:24 |
| igc | jam: 1.24 :-) | 16:25 |
| * jelmer isn't used to seeing Australians on IRC around dinner time :-) | 16:26 | |
| vila | jelmer: dinner at 17h26 ? :-) | 16:26 |
| igc | jam: trying to put the eol issue to bed. It just refuses to die because every man and their dog has an opinion :-) | 16:26 |
| jam | igc: at least their cats leave you alone :) | 16:26 |
| igc | small mercies | 16:26 |
| jelmer | vila: traditionally dinner time in .nl is around 6 | 16:27 |
| jam | igc: for what its worth.... I think your final "native" and "native:crlf" for people that really need it is a decent proposal. | 16:27 |
| jelmer | vila: not that I ever eat before 8 :-) | 16:27 |
| jam | I'm not 100% sure that the content filtering stack is 100% right, but it is probably good enough for what we want | 16:27 |
| jam | (I think I would rather register a handler for the property name (eol) and then have it passed the value, and it returns the actual filters at that time) | 16:28 |
| jam | but hey, you wrote it :) | 16:28 |
| jam | I didn't | 16:28 |
| igc | anyhow, I just need lifeless to not block releasing a 1.14 format and to get a majority consensus on eol naming and it's done and dusted | 16:28 |
| igc | jam: there is a fallback method that does exactly that: value -> stack | 16:28 |
| jam | of course, I can throw a big wrench, should it be called "eol" :) | 16:28 |
| igc | thanks to jelmer bugging me about it | 16:29 |
| jam | igc: yeah, but it is a bit cludgy versus doing that from the beginning | 16:29 |
| igc | jam: you get both - dictionary lookup + lookup function - and can use whatever makes the most sense | 16:29 |
| igc | jam: and it's internal-ish | 16:30 |
| igc | getting UI consensus is the harder issue it seems | 16:30 |
| phinze | is there a way to prevent users from committing changes directly to certain files in a branch | 16:30 |
| jam | igc: its internal ish, but hard to change for compatibility reasons | 16:31 |
| igc | anyhow, time for bed | 16:31 |
| phinze | and only letting them be changed by merges? | 16:31 |
| igc | night all | 16:31 |
| jam | phinze: no | 16:31 |
| jam | what is your use case ? | 16:31 |
| * phinze is having trouble in dev group with constant mistakes of people committing changes to a shared library too far downstream | 16:31 | |
| jam | phinze: so the issue is that in a distributed system, you don't really have any control over individuals machines ... | 16:32 |
| jam | Providing a way to help people realize they didn't actually want to modify something | 16:32 |
| jam | is something we would be interested in | 16:32 |
| jam | but ultimately, the point of distrbuted VCS is that people get to do what they want | 16:33 |
| phinze | right, but when they push to a shared location we can yell at them | 16:33 |
| phinze | the hooks are there in order to examine changed files pre-commit and conditionally reject, no? | 16:33 |
| jelmer | jam: was there a conclusion about whether subtrees (even in disabled form perhaps) were going to make it into the bbc format? | 16:35 |
| vila | jelmer: both patches reviewed | 16:36 |
| vila | jam: try -s bt.interrepository_implementations | 16:37 |
| vila | jam: 14 errs and counting :) | 16:37 |
| jelmer | vila: thanks, much appreciated | 16:37 |
| jam | jelmer: the serializer will support subtrees | 16:39 |
| jam | the "supports_subtrees" flag will probably be set to False | 16:39 |
| jam | vila: are those new, or ones we just didn't see before? | 16:40 |
| vila | new they all say 'KnitPackRepository' object has no attribute 'supports_tree_reference' so probably related to your last fixes | 16:40 |
| vila | jam: also -s test_fetch.Test1To2Fetch.test_fetch_ghosts errors with KnitPackRepository('file:///tmp/testbzr-lKx3YV.tmp/bzrlib.tests.test_fetch.Test1To2Fetch.test_fetch_ghosts/work/tree/.bzr/repository/') has no revision ('ghost-parent',) | 16:43 |
| jelmer | jam: neat | 16:43 |
| vadi2 | Hi. It seems the 64bit package for intrepid from the ppa is not installable, there is an error: http://paste.pocoo.org/show/110454/ | 16:45 |
| phinze | jam: so re above, conceptually are the pieces there for me to tie together to have a pre-commit hook on a certain shared branch that checked modified files and rejects commits if protected files are modified and the commit is not a merge? | 16:51 |
| phinze | not a merge from a certain branch even | 16:52 |
| jam | vila: yeah, I had a typo in there "target.supports..." rather than "target._format.supports" | 17:13 |
| jam | weird that the other tests started passing | 17:13 |
| vila | grr, C-w is cut damn it, not close window, or vice-versa... | 17:17 |
| jam | vila: yeah, I ran into that with ^L, which is refresh in a lot of windows, but is "clear the screen" in Pidgin | 17:17 |
| jam | I had the problem because there was something about Vim + Ubuntu that was causing it to not draw all characters all the time | 17:18 |
| jam | so ^L was needed to actually show the local content | 17:18 |
| jam | anyway, 3915 should fix those intertree test failures | 17:18 |
| vila | I have less problems under OSX :) | 17:19 |
| vila | I mean, I *still* have the problem with M-w and clower-w but M-w is copy :) | 17:19 |
| vila | s/clower/clover|apple|whatever/ | 17:19 |
| vila | jam: and no more asserts | 17:21 |
| jam | vila: so intertree all pass here | 17:21 |
| vila | jam: I'll push as soon as the test pass | 17:21 |
| jam | sorry interrepo | 17:21 |
| vila | jam: I pulled, full test suite running | 17:22 |
| vila | jam: and also running in the branch I started for the asserts, I'll appreciate if you could have a look at them for typos or better descriptions once I merge them in bbc | 17:23 |
| vila | so virtually we have a bbc passing tests :) | 17:24 |
| jam | ah, virtual test suites :) | 17:28 |
| rryan | Hi -- (I hope it's ok to ask bzr questions in here) I'm working on Mixxx, and we use Launchpad. We're migrating to using bzr from svn on sourceforge. | 17:30 |
| rryan | We have a release branch that all our developers are working on, but when any of us do merge/commit/push to both pull in changes from upstream and push local changes to the LP release branch, the history view on LP replaces the merged log entries with the 'merged' message from the developer that did the merge. How can I prevent this? | 17:31 |
| Kinnison | The branch you pushed had the merged message as its commit | 17:32 |
| Kinnison | that's expected | 17:32 |
| Kinnison | It's only if you drill into that revision that you'd see the individual commits | 17:32 |
| Kinnison | If you want to see what the merge actually merged, then get your developers to write more useful merge change messages :-) | 17:34 |
| Kinnison | consider https://code.launchpad.net/~aranha/aranha/mainline (one of my personal projects) | 17:34 |
| Kinnison | all the commits are merges | 17:34 |
| Kinnison | because I work on branches, and a robot merges that branch onto mainline | 17:34 |
| rryan | Kinnison : yea I see that -- when I push, its like I replace the remote branch's history with the history with respect to my branch. | 17:35 |
| Kinnison | indeed | 17:35 |
| vila | jam: you still fail the -s test_fetch.Test1To2Fetch.test_fetch_ghosts | 17:35 |
| Kinnison | I strongly recommend the use of a robot-controlled mainline | 17:35 |
| Kinnison | I think launchpad may even be able to help with that | 17:35 |
| rryan | Kinnison : when I use git, for example, the remote HEAD shows its history with respect to itself. And when I push to it, it shows all of the local commits I made, and a 'merging from upstream' message, but since the merge from upstream was already in upstream, it keeps those log messages in the history as they occured. | 17:36 |
| Kinnison | rryan: the history of what you merged is still present, it's just not rendered by default | 17:36 |
| rryan | Kinnison : I know, I see that I can drill down to the merged branch to see the previous commits. What I'm wondering is, can I use bzr in such a way that it won't take other people's commits out of the main branch history? | 17:37 |
| luks | rryan: there is really no technical difference, it's just a display issue | 17:38 |
| Kinnison | always merge into the mainline, don't merge the mainline into you? | 17:38 |
| Kinnison | So have your mainline branch, then have a feature branch you work on | 17:38 |
| Kinnison | then you pull your mainline, merge your feature, and push your mainline | 17:38 |
| Kinnison | that way you don't disturb the mainline history | 17:39 |
| rryan | Kinnison : Ah... now I see why that is happening. Thanks a lot for your help | 17:39 |
| rryan | I'll switch to using it that way | 17:39 |
| Kinnison | OOI, any launchpadders here right now? | 17:40 |
| * Kinnison is wondering how to upgrade a branch which is a mirror | 17:40 | |
| vila | jam: assert cleanup pushed as 3916 | 17:40 |
| jam | vila: /cheer, I'm fixing up that test, I understand why it is failing | 17:40 |
| vila | jam: yeah :) Thanks, you make my day end nicely | 17:42 |
| vila | jam: I may pass around later, but no promise... | 17:42 |
| jam | rryan: there is a flag "append_revisions_only" that you may be interested in. | 17:44 |
| jam | You can set "append_revisions_only = True" in branch.conf | 17:44 |
| jam | and then the bzr client will refuse unless you merge to mainline first | 17:45 |
| jam | (it will refuse the 'push') | 17:45 |
| beuno | mwhudson, ^^ | 17:45 |
| beuno | how do you upgrade branches that are mirrored? | 17:45 |
| jam | beuno: upgrade the source branch | 17:45 |
| jam | the mirror script auto-detects | 17:45 |
| mwhudson | right | 17:45 |
| rryan | jam : I see -- thanks | 17:45 |
| jam | and wipes and starts over | 17:45 |
| beuno | ah | 17:46 |
| Peng_ | Very bandwidth-efficient. :P | 17:46 |
| jam | Peng_: especially when you upgrade the repository for 100 shared branches... | 17:46 |
| Peng_ | jam: Auto-stacking is a big help. | 17:46 |
| jam | which then takes enough bandwidth that lp times out trying to mirror 1 of them :) | 17:46 |
| mwhudson | well | 17:46 |
| vila | when in doubt... use more bandwidth ? | 17:46 |
| Kinnison | jam: noted, thanks | 17:47 |
| * Kinnison won't upgrade the source repo until his new colo box is in place | 17:47 | |
| Kinnison | so a few weeks of annoying messages so far | 17:47 |
| Kinnison | and a few weeks left :-( | 17:47 |
| Kinnison | Thanks | 17:47 |
| Peng_ | How gigantic is the repo? It's not a big deal. | 17:48 |
| Kinnison | Oh this is not big | 17:48 |
| Kinnison | but I can't upgrade the source repo until I can upgrade bzr on the colo box (which is using packaged bzr so I have to do the OS upgrde, which means the new machine really) | 17:48 |
| jam | Kinnison: so any more LP will stack mirrored branches, so it isn't as big of an issue | 17:48 |
| Kinnison | jam: nod. | 17:48 |
| jam | however, that wasn't the case 1-2 years ago when I upgraded my repo | 17:49 |
| jam | from knits => packs IIRC | 17:49 |
| bialix | jelmer: ping, have a question about rebase | 17:49 |
| jam | and that caused LP to timeout on mirroring all of my branches | 17:49 |
| Kinnison | aye, I'm still on knits in this repo | 17:49 |
| Peng_ | It won't stack them if they're in a pre-1.6 format (both the repo and branches). | 17:49 |
| Kinnison | Is it now possible to branch with a horizon then? (talking of stacking) | 17:50 |
| bialix | jam: hi | 17:50 |
| jam | hi bialix | 17:50 |
| jam | I just met Andrew | 17:51 |
| bialix | jam, jelmer: can you suggest something about error http://paste.ubuntu.com/141559/ | 17:51 |
| bialix | jam: :-) | 17:51 |
| jam | I don't really know about the rebase plugin | 17:51 |
| bialix | jam: but errors come from bzrlib | 17:51 |
| jam | it sounds like it is setting "kwargs={'author':XXX} and author=YYY" | 17:51 |
| bialix | rebase try to write original author with --author option | 17:52 |
| bialix | my problem occurs when I'm trying to rebase the same branch several times | 17:52 |
| bialix | jam: I'll try to look for the kwargs, as you said. | 17:53 |
| bialix | jam: are you still at PyCon? | 17:53 |
| jam | bialix: yep | 17:54 |
| bialix | :-) | 17:54 |
| jam | vila: ok, that fetch test is now fixed, committing once the subset tests finish | 18:03 |
| vadi2 | It seems the 64bit package for intrepid from the ppa is not installable, there is an error: http://paste.pocoo.org/show/110454/ | 18:05 |
| Peng_ | So, who wants a really trivial patch to a couple error messages in brisbane-core? :D | 18:16 |
| NfNitLoop | Awww. Just saw the news that Python is going with Hg. :/ | 18:27 |
| NfNitLoop | according to the post, "few (except Canonical employees) seem to like Bzr." | 18:27 |
| NfNitLoop | !? | 18:27 |
| NfNitLoop | Does Bzr have an image problem I'm unaware of? :) | 18:27 |
| LeoNerd | I dunno.. I tend to pick tools on their merits, not their popularity | 18:28 |
| NfNitLoop | Yeah, I agree. | 18:28 |
| NfNitLoop | (though buy-in can't be completely dismissed in a DSCM.) | 18:28 |
| Peng_ | LeoNerd: Popularity is a factor. Popular tools are more likely to be improved and maintained. | 18:29 |
| Peng_ | LeoNerd: And people will write better converters to new, better VCSes. :D | 18:30 |
| jelmer | wait, mercurial is a VCS? I thought it was just the name of one of Bazaars repository formats ;-) | 18:30 |
| Peng_ | Ouch. | 18:30 |
| jelmer | (Although I guess this is a good reason to improve bzr-hg a bit more..) | 18:32 |
| vila | jam: @bbc ./bzr selftest -x '(?i)loom' ==> OK (known_failures=14) | 18:33 |
| * vila goes back cooking | 18:33 | |
| Peng_ | vila: Congrats. | 18:33 |
| * vila pass to jam ;-) | 18:34 | |
| jelmer | niice | 18:37 |
| bialix | jelmer? | 18:44 |
| Peng_ | He was here 10 minutes ago, fwiw | 18:44 |
| jelmer | bialix: hi | 18:44 |
| bialix | hi jelmer | 18:44 |
| bialix | did you saw my pastebin about 40 min ago about rebase error? | 18:45 |
| bialix | may be you can suggest something how to workaround it | 18:46 |
| bialix | jelmer: http://paste.ubuntu.com/141559/ | 18:46 |
| bialix | I've tried to rebase the same branch several times, because I want to throw away some revisions | 18:46 |
| jelmer | bialix: I've pushed a change that I think should fix it | 18:50 |
| jelmer | bialix: also, removing revisions from a branch isn't really the purpose of rebase | 18:51 |
| bialix | can I run rebase-continue, or should I start my rebase again from the original branch? | 18:51 |
| jelmer | rebase-continue should work | 18:51 |
| bialix | jelmer: but rebase do the right thing | 18:51 |
| bialix | I mean it can remove revisions | 18:51 |
| bialix | btw, jelmer, while I'm here. To rebase one revision e.g. N I should use syntax -r N..N+1 | 18:52 |
| bialix | i.e. your plugin don't use last number | 18:52 |
| bialix | is it intended? | 18:52 |
| bialix | when I need to rebase tail of the branch I have to use -r N.. | 18:53 |
| bialix | it's not obvious from rebase doc | 18:53 |
| bialix | jelmer: I found very neat usage for rebase to perform cherrypicking with history | 18:56 |
| bialix | IIUC, I've got almost the same result as git cherrypicking does | 18:56 |
| jelmer | bialix: different from "bzr merge -c" ? as that's all that rebase does, basically | 18:57 |
| bialix | yep ,different from merge -c | 18:58 |
| bialix | I've started heavily using daggy fixes | 18:58 |
| bialix | and rebase in help here | 18:58 |
| bialix | it seems your fix helps, and rebase-continue going forward | 19:00 |
| bialix | jelmer: big thanks | 19:00 |
| bialix | jelmer: you save my day, many many many thanks. rebase is great tool to remove revisions, it does the right thing! | 19:03 |
| bialix | even if you don't plan to use it this way | 19:03 |
| bialix | :-) | 19:03 |
| jelmer | bialix: how is rebase behaving different from "bzr merge -c" though? | 19:04 |
| jelmer | bialix: as "bzr merge -c" is basically what it's doing under the hood | 19:04 |
| bialix | rebase allows me to keep the log messages | 19:04 |
| bialix | sometimes I'm cherrypicking several revisions in a row | 19:04 |
| jelmer | ah, ok | 19:05 |
| bialix | rebase helps because it does the boring job: transplate revisions meta-data | 19:05 |
| bialix | it's a huge gain for me | 19:05 |
| bialix | in the past I've often copy-pasted log messages when I've committed cherrypick. Now I can use rebase | 19:06 |
| bialix | it's incredible | 19:06 |
| jelmer | cool :-) | 19:08 |
| bialix | rebase --onto rocks :-) | 19:10 |
| bialix | btw, what was main reason for --onto in first place? | 19:11 |
| jelmer | bialix: being able to rebase onto a revision not the last revision on your current branch | 19:13 |
| bialix | you mean upstream branch, I guess | 19:14 |
| jelmer | yeah | 19:18 |
| bialix | jelmer, I can write small recipe how I do cherrypick with rebase. Actually I will write it for my Russian bzr blog. I can translate it if you like to put it somewhere into rebase cookbock | 19:22 |
| jelmer | bialix: I'd rather not encourage people to use rebase that way | 19:24 |
| jelmer | bialix: instead, bzr replay should be used (but can't handle conflicts yet) | 19:24 |
| bialix | hmm, | 19:25 |
| bialix | replay missing --onto | 19:25 |
| bialix | what the intended usage of replay? | 19:25 |
| bialix | and where it different from rebase? | 19:26 |
| jelmer | bialix: replay is intended for exactly that - replaying specific ranges of revisions on top of a different parent revision | 19:28 |
| jelmer | bialix: rebase is intended to replay the extra revisions your local branch has on top of an upstream branch | 19:28 |
| bialix | if I need to move range of revisions back in the history | 19:29 |
| bialix | for me both rebase . --onto and replay do the same | 19:30 |
| bialix | I need to play with replay, never used it before | 19:31 |
| bialix | rebase . --onto == does not require additional branch | 19:31 |
| jelmer | jam: ping | 21:13 |
| jam | hey jelmer | 21:13 |
| jelmer | jam: hi | 21:13 |
| jelmer | jam: So, I'm looking at adding a new Revision serializer | 21:14 |
| jelmer | jam: So that we can get rid of the _escape_commit_message hack in bzr-{git,svn,hg} | 21:14 |
| jam | jelmer: basically, it probably just needs to be something on bzrlib.chk_serializer.pack_revision | 21:15 |
| jelmer | jam: Should this just be a matter of adding write_revision() / write_revision_string() / read_revision() / read_revision_string() onto CHK_Serializer ? | 21:15 |
| jam | or something along those lines | 21:15 |
| jam | jelmer: probably, though I would probably make it a class independent | 21:15 |
| jam | and test it directly | 21:15 |
| jam | and then hang it onto CHK_Serializer | 21:15 |
| jelmer | jam: CHK_Serializer base classes from something in xml_serializer, is that historical, or is there actually still XML involved? | 21:15 |
| jam | ultimately, we'll probably have to watch out for some of the 'fetch' code | 21:15 |
| jam | which may not be casting all the way up to Revision objects | 21:15 |
| jam | jelmer: we still *can* go to xml, and we do in some odd circumstances that we would eventually like to get rid of | 21:16 |
| jam | certainly we still use the Revision xml | 21:16 |
| jam | since we don't have another format yet :) | 21:16 |
| jelmer | jam: Right, but there's nothing fundamentally depending on the fact that a Serializer would use XML for revisions? | 21:16 |
| jam | jelmer: there might be code that doesn't realize the formats can be different, but there *shouldn't* | 21:16 |
| jelmer | jam: I haven't looked at the internals of CHK inventories yet, what sort of encoding do they use? | 21:17 |
| jelmer | or is there some place where I could read about that? | 21:17 |
| jam | bzrlib.inventory.CHKInventory.to_lines() might be what you are looking for | 21:18 |
| jam | if not there | 21:18 |
| jam | bzrlib.chk_map.py | 21:18 |
| jam | in general, null terminated strings | 21:18 |
| jelmer | thanks | 21:18 |
| jam | CHKInventory._entry_to_bytes is the serialization of individual InventoryEntries | 21:18 |
| jelmer | (I'm asking since it seems to make sense to use something similar) | 21:18 |
| jam | sure | 21:18 |
| jam | we did get to the point of using '\n' termination | 21:19 |
| jam | to be easier on the eyes/line-based deltas | 21:19 |
| jam | but for what you are doing, I think null-based strings would be reasonable | 21:19 |
| jam | jelmer: oh, and I might recommend grouping content that is likely-to-change separate from content that is 'likely-to-be-the-same' | 21:20 |
| jam | but I can think about that once you've done some work | 21:20 |
| jelmer | I don't think there would be a lot in revision data | 21:20 |
| jelmer | that stays the same | 21:21 |
| jelmer | perhaps the committer / revision properties (with "author" and "nick") | 21:21 |
| jelmer | I would expect the revision id to change pretty much 100% of the time :-) | 21:21 |
| jelmer | parent ids and commit message also change fairly often I would imagine | 21:21 |
| jelmer | vila: ping | 21:34 |
| BasicOSX | LP hates me today: Timeout error (Error ID: OOPS-1186H2211) | 21:41 |
| ubottu | https://devpad.canonical.com/~jamesh/oops.cgi/1186H2211 | 21:41 |
| thumper | BasicOSX: this should be fixed with the rollout | 22:11 |
| thumper | BasicOSX: it is still slowish to do the revision count query | 22:11 |
| thumper | BasicOSX: for the release after this we are rejigging the internals to use a special cache for the counts | 22:12 |
| thumper | BasicOSX: which should kill the timeouts on this page for once and for all | 22:12 |
| BasicOSX | I liked that LP just hated be :-P | 22:12 |
| BasicOSX | %s/be/me/g | 22:12 |
| thumper | BasicOSX: I could add some special hate code if you like if you tell me your lp-id | 22:14 |
| thumper | BasicOSX: although it might not get past review :P | 22:14 |
| BasicOSX | >8-) | 22:14 |
| awmcclain | Hi all... is there a way for me to remerge? I merged in some changes on a file I've been editing and accidentally saved over the changes. I don't want to revert my changes since I'd lose my edits. | 22:34 |
| mwhudson | rockstar: https://code.edge.launchpad.net/~mwhudson/loggerhead/js-cleanup/+merge/5087 | 22:34 |
| mwhudson | awmcclain: there's a 'remerge command' which might do what you want | 22:34 |
| awmcclain | mwhudson: Is that new since 1.9? | 22:34 |
| mwhudson | awmcclain: no, it's ancient | 22:35 |
| awmcclain | Great. THank you! | 22:35 |
| awmcclain | Oh, also, since we got into a huge hassle with this this morning... what's the best method of undo-ing a bzr add? | 22:35 |
| rockstar | awmcclain, bzr revert? | 22:35 |
| mwhudson | or bzr rm --keep | 22:36 |
| awmcclain | rockstar: Doesn't revert remove the file, though? | 22:36 |
| mwhudson | i'm pretty sure reverting an addition doesn't remove the file | 22:36 |
| rockstar | awmcclain, it only works if you haven't committed though. In that case, do what mwhudson says. | 22:37 |
| alevine | is there any way to set a parent location as permanent...so if I do bzr push without any options it always pushes to that location? | 22:46 |
| mwhudson | alevine: --remember | 22:47 |
| mwhudson | alevine: but the default location for push is the push location, not the parent location | 22:48 |
| alevine | mwhudson, thanks. what is the parent location? | 22:48 |
| mwhudson | alevine: the default for pull/merge | 22:48 |
| alevine | thanks | 22:49 |
| awmcclain | Even though sometimes I hate it, I have to say, I love, love, love bzr. | 22:49 |
| igc | morning | 23:00 |
| jelmer | 'moin Ian | 23:01 |
| lifeless | hi igc | 23:07 |
| igc | hi lifeless, jelmer | 23:08 |
| igc | bbl | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!