GRiDpoolie, is there a specific test (or test type) you recommend i look at as a pattern for creating the large-file-add test? is the shell-like interface appropriate?00:01
pooliehi grid, i think that would be a reasonable way to do it00:02
=== krow_ is now known as krow
GRiDok, i suppose it makes sense to add it to blackbox/test_add.py even00:06
=== med is now known as med_out
poolieso, pros and cons00:13
poolieusing shell-like tests:00:14
poolie - tests most of the stack integrated together00:14
poolie - therefore catches integration bugs00:14
poolie - and also is slower00:14
poolie - is a somewhat less precise mechanism for setting things up and evaluating them00:15
poolie - requires less prior knowledge00:16
poolieso... for a first patch overall it's pretty good00:16
poolieif you wanted to cover dozens of different cases probably using api tests would be better00:16
GRiDok thanks. tomorrow (fri) is the first chance i'll get to write some code so i'll see how it goes, maybe have some questions.00:58
pooliei hope you enjoy it, ask here on the list if you want01:17
TiffanyAngel87Suppose I have some revision X and it's ruining my life, how do I revert just those changes?04:30
AfCTiffanyAngel87: and X is not the latest revision?04:40
TiffanyAngel87AfC: correct04:40
AfCTiffanyAngel87: you have to commit the "reverse" of what that revision introduced.04:41
AfCTiffanyAngel87: you do that by using merge, backwards:04:41
AfCif X is 4704:41
AfC$ bzr diff -r 46..4704:41
AfCshows you the change set introduced by (resulting in) that revision (state)04:42
AfCTiffanyAngel87: right?04:42
TiffanyAngel87with you so far04:42
AfCso, to get rid of it, you merge the inverse. You can first see that with04:43
Noldorinjelmer, hi?04:43
AfC$ bzr diff -r 47..4604:43
AfC(note the + and - inverted)04:43
AfCbut to do it, use merge04:43
TiffanyAngel87then patch -p0?04:43
AfCno merge:04:43
AfC$ bzr merge -r 47..4604:43
AfC[that's implicitly "from this branch"]04:43
AfC$ bzr merge -r 47..46 /path/to/branch04:43
TiffanyAngel87I'll give it a try. Thanks!04:44
AfCwould have pulled that delta from somewhere else04:44
TiffanyAngel87the reverse merge is effectively the same as the diff and patch, right?04:44
AfCI'll let someone else answer that; my belief is that there's more to it than that04:44
AfCie, merge can be (dramatically) smarter about base revisions, ancestors, etc04:45
AfCThere's a reason we don't throw history away in Bazaar land04:45
TiffanyAngel87cherrypicks don't carry their history though, right?04:45
TiffanyAngel87well, I'll try it :)04:45
AfCDon't forget to `bzr commit` the merge once you've reviewed its impact;04:46
AfCand `bzr revert --no-backup` if you screwed up and need to retry.04:46
AfCTiffanyAngel87: no, cherypicks don't, but they merge logic can still be [much] smart about what to do and how to apply the delta [especially normal forward cherry picks]04:47
TiffanyAngel87makes sense04:47
TiffanyAngel87AfC: I think that worked. And no conflicts thank god. thanks04:48
=== vila_ is now known as vila
poolievila, hello?05:53
pooliethomi: hello?05:53
vilahi all !05:53
vilathomi: hi, thanks for your work on the system config file, can we talk about it here or is it too late for you (what TZ are you in by the way ?) ?06:03
thomiI'm in New Zealand, so +1200 I think (or maybe +13? +11?)06:03
thomiby all means...06:03
thumper+13 in summer06:04
* thumper leaves06:04
thomiThank you thumper.06:05
vilathomi: I haven't look in details so far, but roughly the missing parts are:06:05
vila1) I suspect the tests are not isolated yet and use the real /etc/bazaar.conf if it exists (instead of one specific to tests)06:06
vila2) the 'bzr config' command needs to taught about this new file (which means some heavy lifting)06:07
vila3) I'd strongly prefer if this new config file were implementing the planned features  (path matching mainly) rather than duplicating the actual bazaar.conf06:07
vila(3) could be simplified as a first step by duplicating branch.conf instead and forget about path matching as a first step06:08
* thomi thinks06:12
vilathomi: roughly, it means, the new file can be used for any options without any section06:14
vilathomi: will that match your intended use ?06:14
thomisure, I'm just hacking this for fun, we don't need this for sloecode...06:15
vilaha, cool :)06:16
thomiso the plan regarding "bzr config" is to make the confi command use the new file, and then at some point in the future port the config command to use the new Stack API?06:16
thomi...or do we port bzr config to the Stack-based API now?06:17
vilathat would be a different merge proposal, but yes, the plan is to move to the stack-based API asap06:18
vilaI haven't considered doing it so far because I wanted to migrate all the existing options first06:18
vilabut your proposal triggered a new way to think about the whole issue and may be we can use the system wide config to drive the introduction of the new features06:19
thomi...but won't moving to the stack-based API give you access to the new system config file? I'm not sure what needs to be done for (2) in that case...06:20
vilabzr config has a few needs that are not covered yet06:21
vilafrom the top of my head: iterating all options returning (config-id, section, name, value)06:22
thomiokay, that makes sense.06:27
thomijust to make sure I'm not missing something, PathMatcher does not currently exist, right?06:28
vilathere are various candidates PathMatcher, URLMatcher, AbsolutePathMatcher, RelativePathMatcher06:30
vilaI don't think we need all of them ;)06:30
vilabut from a user point of view they address different needs06:31
thomiokay - I think I need to read the devnotes a couple more times :) I'll start by refining the unit tests and seeing how I can modify bzr config06:32
thomiShould be able to make some progress this weekend.06:33
vilacool, I'll try to define a clearer roadmap for the missing bits and work on migrating more options myself06:34
* vila hunts coffee06:35
thomiOn an unrelated note, is there an example someone can point me at of calling loggerhead to render *part* of an HTML page? I.e.- calling it from within another WSGI app?06:36
thomiIt must be do-able because LP does it for merge proposals, but launchpad code makes my head hurt.06:36
pooliethomi: so lp is doing not in-process in a wsgi app, but from the client06:37
poolieproxied through the app server06:37
poolieit requests a diff url06:37
thomiahh, that'd be why it looked odd. So is it something that's not currently easy to do in loggerhead?06:38
pooliefrom what i know of the structure i'd think it should be pretty possible06:39
pooliedepending on just what part it is that you want to get out06:39
poolieif it currently only serves one monolithic page for, say, annotate, and you want to get just part of it , you might need to refactor it06:39
thomiwell, I'd like everything, but rendered within a sloecode page...06:39
poolieso, with sloecode navigation stuff inserted into the loggerhead page?06:40
thomiyeah, or rather loggerhead inserted into a sloecode page ;)06:41
thomiso how does LP do it for the diffs on merge proposals... I assume those diffs are created by loggerhead.06:46
maxbI don't think they are06:56
thomioh, ok, cheers.06:57
pooliehi vila07:04
pooliedo you want to chat?07:04
vilayup, if my network agrees with that reasonable task ;)07:05
pooliejelmer: hi?07:14
poolievila, so re http://doc.bazaar.canonical.com/devnotes/configuration.html compatibility07:37
pooliei agree we want to change section names07:37
vilaand delete some07:37
poolieright, more precisely we want to use sections to describe when the value applies, not what the key is07:38
pooliehowever, it seems pretty feasible to migrate while using the current files07:38
pooliei'd really rather not put users through a flag day07:38
vilame neither07:38
vilabut we can support haveing both files defined07:38
vilaand even create one from the other07:39
vilaand even update the old one in parrallel (that one is probably overkill ?)07:39
poolieso istm the common case will be that people just simply have a bazaar.conf07:40
pooliewith a default section, without bookmarks or aliases07:40
vilatrying to address all issues while keeping the same file gave me headaches and I never came to a satisfying solution either07:41
poolieand the simplest thing in that case is to just leave it alone07:41
vilaleave it alone and handles the new one or leave it alone and change its semantic ?07:42
pooliedon't create a new file, just keep reading and writing the current location07:42
pooliesupport having this kind of section marker as a backward compatibility feature or something07:43
poolietoo hard?07:44
vilamy gut feeling is that it will make the code more complex with no guarantee that the end result will work correctly07:44
vilaroughly, we make assumptions about the file content and semantics that allow us to be lazy07:45
vilaas soon as you require looking at the file content to define the semantic, you lose the lazyness07:46
pooliewhat do you mean?07:46
vilait matters less if we guarantee that we will read the file only once but we're not there yet07:46
vilaI mean: using [DEFAULT] as a backward compatibility marker means the file needs to be read first before deciding how we want to interpret it (not mentioning that it forbids using 'DEFAULT' as a valid path)07:47
poolieok, so what i had in mind was07:48
pooliethe per-user file is called bazaar.conf07:48
pooliewe match sections by path in there07:48
poolieor, perhaps [path ...]07:49
pooliethere's an api that will let the bookmarks and aliases plugins find other things07:49
pooliefind values from other sections07:49
vilaright, but it's far easier to let the old file implements the old semantics and the new file provides the new ones07:50
vilathen people can decide when they want to switch07:51
vilaand we can deprecate bazaar.conf in 2.6 or 2.707:51
pooliei don't think that's a thing people want to make a decision about07:51
vilausing new features is a decision07:52
lifelessdeprecate bazaar.conf?07:52
pooliethat's vincent's proposal07:53
pooliewhat do you think?07:53
lifelessseems like a lot of people will need to change their config07:55
=== vila_ is now known as vila
poolievila, so, i'm kind of -1 unless it's really necessary, and i'm not convinced yet that it is really necessary07:58
poolieplease don't land it until i am convinced07:58
pooliei think there are other things we can do towards this that don't require that migration07:58
poolielike, getting rid of config-variable-specific apis, and updating callers to use stacks?07:59
vilayes, that's what I refer to as 'migrating existing options'07:59
poolieonce we do that, we should be pretty much set to read them from a global file, the command line, or environment variables?08:02
vilalast time I looked at env variables the use cases seem to be that *multiple* env variables for *one* config option is the rule rather than the exception, but nothing blocking08:03
vilacommand line will be ok08:03
vilaadding a global file (as in system-wide ?) without addressing the compatibility sounds like a waste of time08:04
vilaensuring single read/write of a given config file can also be done first (if only to free our minds about the related issues)08:05
vilabecause it means we'll have to do the work twice08:06
vilaand the users too08:06
vilanow, the migration to new files can probably be automated for the most common cases if not all08:07
poolieif you're suggesting adding a global file with a structure we later have to deprecate, that does seem like a waste, but i don't see why that would be needed08:07
vilaI thought *you* were suggesting a system-wide file with the same semantics as bazaar.conf :)08:09
pooliei don't think we would need to handle the corner cases of bazaar.conf in the global one08:10
vilaright, that's why I suggested to make the system-wide conf file more like branch.conf: a single no-name section08:11
vilato start with08:11
vilabut an obvious use case would be define aliases there...08:12
poolieso then i think we'd have to update the alias code to look in both places08:12
poolieor, maybe add an api with a backwards-compatibility thing08:12
vilaor even better, let the config file define this kind of semantic so the backwards-compatibility tricks are easier to define and manage overall and clearer for users that could be pointed at the doc associated to the config file itself :)08:13
vilabut let's discuss about that later when things are clearer08:14
vilajust keep in mind that I'm fully aware that introducing new files and deprecating old ones is not easy/use-friendly, should be done with care and the costs/benefits balanced against keeping the same files08:17
poolieso step 0 is to send a roadmap and then step 1 is to migrate the existing callers08:17
poolieok :)08:17
vilapoolie: in short: I damn well know the issues and I'm eager to convince you :)08:17
poolieok :)08:17
pooliethe other thing that would be really helpful now is your attention to http://package-import.ubuntu.com/status/08:18
poolieconfig stuff is a good feature, and good for enabling other stuff, but not top of the list08:19
vilajam: hello !08:20
jammorning vila08:21
pooliehi jam, welcome back08:23
jamhi poolie08:23
* vila biab08:24
cheateri've done multiple changes to a file which i'd like to put into separate commits. how can i do that?08:26
AuroraBorealisremove one set of changes, commit, add the second changes back , commit08:27
cheateris there no way to edit the diff i'm committing?08:27
AuroraBorealisprobably not.08:27
AuroraBorealisand i dont think there is a way to do that in any versioning system08:28
AuroraBorealisyou can select what files that have changes get commited but not certain changes in a file.08:28
cheaterthat sucks :(08:29
AuroraBorealiscommit more often i guess!08:29
AuroraBorealisalso, is there a way to make the mac version of bzr explorer have a dock icon?08:30
AuroraBorealisits a one liner, but i have no idea where the program starts08:30
pooliecheater, use bzr shelve08:32
poolieor install bzr-interactive and i think it adds a commit -i08:32
cheateroh let me try that!08:32
jelmerhi jam, welcome back :)08:32
AuroraBorealisbecause its annoying to have the default python icon in the dock =/08:33
jelmerpoolie: pong08:35
pooliehi jelmer08:35
pooliei think i was just saying hi08:35
cheaterso what would i do? bzr shelve file, edit changes to just leave in the ones i need.. and then bzr ci.. and then how do i get my changes back?08:35
pooliebzr unshelve08:36
cheatergreat - let me try that08:36
cheaterwow bzr shelve is really great08:39
cheaterthanks a lot for the tip!08:39
cheaterAuroraBorealis: look, bzr is better than any other VCS :)08:40
AuroraBorealisi didn't know it allowed you to choose what changes08:40
cheateryep! pretty cool! :)08:40
cheaterbtw, i wrote a lightweight text editor for use with bzr commits08:44
cheateri just do bzr ci, enter my message, then press Ctrl-D (or Ctrl-C) to abort). It doesn't do anything else and doesn't display any user interface, etc.08:45
cheateri find it better than nano and vim for this purpose, and you don't have to use -m (using -m means that you can't just press up and enter to commit new changes)08:45
vilaso, wanting to file a bug for making tags fetching optional for 2.4.0, I see we have 3 critical bugs ?09:02
vilajelmer: bug #771184 sounds like the one I'm after09:08
ubot5Launchpad bug 771184 in Bazaar "option to disable/enable fetching of all tags" [High,Confirmed] https://launchpad.net/bugs/77118409:08
jelmervila: ah, yep09:09
vilajelmer: do you know the fetch code enough to fix it ?09:09
vilajam: or may be you do ?09:10
jmlmgz: Would really appreciate you looking over https://code.launchpad.net/~jml/testtools/unprintable-assertThat-804127/+merge/7053009:12
jamvila: enough to make fetching tags optional, or enough to fix the underlying bug?09:13
vilaanyway, I've marked #771184 as critical and targeted to 2.4.0 so we don't release without fixing it09:13
vilajam: enough to make fetching tags optional09:13
vilajam: so we can fix the underlying issue for 2.4.1 or trunk09:14
vilajam: I don't understand the details but the underlying issue seemed to be tricky enough to require more time. I don't want to block the release for that09:15
Noldorinhi jelmer09:19
jelmervila: Yeah, I think I know the fetch code well enough, though I'm also trying to finish off my current WIP09:19
jelmerhi Noldorin09:19
Noldorinjelmer, haven't had any time to investigate that bzr-git issue yet really..... have you?09:20
jelmerNoldorin, no09:21
Noldorinjelmer, might have some time tomorrow. was going to ask...09:21
Noldorinjelmer, you said to test "part" of the r47 commit. how do i do this?09:21
jelmerNoldorin, creating a new revision with some of the changes present in r47 and seeing if that gives the same problem09:24
jelmerthen doing that until you can narrow down which combination of changes triggers the bug09:24
Noldorinjelmer, i would have to create a whole new branch, no?09:27
Noldorinjelmer, because just adding a new revision still leaves the old r47 and this gets pushed...09:29
Noldorinwell, i tried indeed.09:29
jelmerNoldorin: yeah, you would have to have these changes instead of your current r4709:30
Noldorinjelmer, ok, thanks for confirming :-)09:31
Noldorinjelmer, bit mor time tomorrow, so we'll see! good night for now09:31
jelmerNoldorin: g'night09:40
spivjml: don't be shy, just call the branch f---ing-assertThat ;)09:40
jmlspiv: :)09:50
* mwhudson wishes for hunk splitting in shelve09:51
LeoNerdIf shelve can't cope I usually revert and vimdiff09:53
cheaterwill anything bad happen if i edit a file that is shelved?09:53
jmlspiv: What I'd like to say about supporting unicode across Python 2 & 3 is unprintable.09:57
james_wmwhudson, you know you can set it up to allow you to edit hunks to achieve that?09:58
mwhudsonjames_w: no!09:59
* james_w searches09:59
james_wbug 70871609:59
ubot5Launchpad bug 708716 in Bazaar "config change_editor is undiscoverable" [Low,Confirmed] https://launchpad.net/bugs/70871609:59
james_wbug 78187110:00
ubot5Launchpad bug 781871 in Bazaar "change_editor for bzr shelve is still not documented enough" [Medium,Confirmed] https://launchpad.net/bugs/78187110:00
james_wmwhudson, id:4D417FEE.3070409@ukr.net10:01
james_wmwhudson, I think you edit the whole file to look like what you want after shelve completes, and it ignores any previous decisions you made in that file10:03
james_wI may be wrong though10:03
cheateris it possible to have one editor in bzr for commit messages, and another "general" editor?10:11
LeoNerdSeriously people...10:57
LeoNerdbzr co $URL; edit stuff; bzr ci --local because I'm on the train.. bzr push => "ERROR: No push location known or specified"10:57
LeoNerdWould it be -that- much work to have this specialcase default to "Oh I'll just push up to the branch" since bzr info knows full well what it is10:57
LeoNerdI don't think in $N years I have -ever- bzr checkout'ed anything that I ever wanted to push anywhere else other than back to its branch.10:58
jelmerLeoNerd: please file a bug10:59
* fullermd cues round 73 of bound-age.10:59
LeoNerdWhere do bugs go these days?10:59
jelmerLeoNerd, http://bugs.launchpad.net/bzr/+filebug10:59
LeoNerdHrmmm... needs login..11:00
jelmerfullermd, I'm also not sure how useful bound branches are anymore these days11:00
jelmerthey seem to cause a lot of confusion for new users11:00
LeoNerdI use them almost exclusively11:00
fullermdThey sound very useful, as that's what LeoNerd is wanting.11:01
LeoNerdI want to work against my centralised repo server; the same workflow model as CVS or SVN11:01
fullermdMe, I'm quite the opposite.  I can't remember the last time I wanted a bound branch, but I use checkouts all the time.11:01
LeoNerdTo be honest, I mostly treat bzr as a "better svn", which has real branches/tags/renames/...11:01
LeoNerdAh, turns out to have been filed already.11:02
ubot5Ubuntu bug 539996 in Bazaar "bzr push should default to parent branch if that's writable" [Wishlist,Confirmed]11:03
LeoNerdover a year ago11:03
spivLeoNerd: "patches welcome" :)11:06
LeoNerdI find that rarely to be the case.11:06
LeoNerdI usually ask for a feature and then do nothing until someone official upstream says "please send a patch"11:06
LeoNerdas in the past I've wasted lots of time and effort building patches that don't get accepted11:06
jelmerLeoNerd, that's a different issue11:07
jelmerLeoNerd, bug 539996 is a different issue from what you were describing I mean11:07
ubot5Launchpad bug 539996 in Bazaar "bzr push should default to parent branch if that's writable" [Wishlist,Confirmed] https://launchpad.net/bugs/53999611:07
LeoNerdBut to the outsider it's never clear if a feature is missing intentionally, or simply because nobody happens to have got around to it yet11:07
LeoNerdThat looks the same, no?11:07
jelmerLeoNerd: That's also another issue :)11:07
spivLeoNerd: at least I didn't say "patches accepted" :P11:08
jelmerLeoNerd: you want "bzr push" to default to the *master* branch, which is different from the parent branch (which is the location a branch was "forked" from)11:08
LeoNerd.. oh.11:08
LeoNerdOK. I'll write another one11:08
jelmerLeoNerd, I'd be interested in talking about patches and discussion around them11:09
spivLeoNerd: obviously it can be a good thing to discuss what you're doing with the people that will need to approve before sinking too much effort into it, to make sure you're not doing something that will never be taken11:09
LeoNerdspiv: Yes. I usually try11:10
LeoNerdQuite often nobody replies ever11:10
spivLeoNerd: "patches welcome" was just meant to be a shorthand for that.  If you like, "feature suggestions and discussion about proposed patches also welcome."11:10
spivYeah, that's a tough problem.11:10
LeoNerdthose are -massively- different11:10
jelmerLeoNerd, I've had similar issues in the past, but I think the process has improved significantly since11:10
LeoNerdI am quite happy to talk, discuss, rant, foam-at-the-mouth about the feature(s) I happen to want or the bugs or whatever..11:10
spivIf you invent a way to solve the finite amount of time developers have, well, we wouldn't need to ask for help with fixing bugs ;)11:11
LeoNerdBut I pointblank-refuse to write a single line of code unless someone semiofficial at least vaguely hints at "we will consider a fix if you supply one"11:11
spivI agree that's wise11:11
spivAnd if at first you get silence, make more noise (if you want, giving up is also fine!).  Sometimes the right person is just really busy that week.11:12
LeoNerdDepends on the project.. I have features/bugs/etc.. outstanding in some places for -years- unreplied11:13
spivI think bzr is increasingly defaulting to "well none of the core devs care strongly either way, so if you want to write that patch go ahead and we'll accept it (if it meets the quality requirements etc)"11:13
spivOh yes, me too.11:13
spivIt depends very much on the project.11:13
spivWhether your bugs/posts languish or get responses is a fairly good indicator for how pleasant it will be for you to work with that community, I think.11:15
LeoNerdDoesn't fill me with confidence then.. :/11:15
LeoNerdBut then some aren't quite my problem. I have a bug open on FreeBSD that's basically in a state of "I really don't care, but I can't support your platform until this is fixed"11:16
fullermdThings vary a lot there.11:16
fullermdI submit port updates a lot, and they rarely take more than a couple days.  And occasionally single-digit hours.11:17
LeoNerdThis isn't a simple ports issue11:17
fullermdMeanwhile, I've got a 3-line manpage patch that's coming up on its 3rd birthday, without evidence of a glance.11:17
LeoNerdThis is a "er.. your kernel API is lacking a feature"...11:17
LeoNerdI wrote a unit test and documentation and everything.. Just no -actual- implementation11:17
LeoNerdBut I handwaved in vague terms how it should be doable11:17
fullermdYes, but my point is that when the only things required is "patch ; cvs ci", the response time varies enormously (even before counting the random factors).11:19
fullermdGetting somebody interested enough to write the code is an even larger can  ;)11:19
spivLeoNerd: that is a shame.  Not that long ago I had a perfectly good (and complete) patch sit around for months and months in a project bug tracker, despite promises it would be looked at "soon" or "in a couple of weeks" and it was deeply frustrating.11:21
LeoNerdOh, I don't usually expect people to write code11:22
LeoNerdI'm quite happy to write it _after_ I have the vague commitment that they might acutally consider it11:22
LeoNerdI just dno't like that large upfront investment on such risky odds of return11:23
LeoNerdIts' basic economics :)11:23
spivYes, very sensible! :)11:23
fullermdI usually figure I might as well go for it.  If it just gets taken, I look smart.  If it languishes for years, eventually someone else will hit the problem, and I can point at the long-waiting solution and be all smug.11:24
fullermdKinda win-win   :)11:24
spivFWIW, the bzr team does try to be aware of these problems and fix them.  We've spent a bunch of effort making sure the patch review queue never grows too long, and that bugs aren't left as "new" indefinitely, etc.11:24
spivLeoNerd: hmm, and although it's not explicitly written down, I think it's part of the Patch Pilot role (which rotates weekly) to be someone you can talk to get a "yes we'd be interested in that patch / no we wouldn't" indication for something you might want to write.11:25
spivLeoNerd: it might be a good idea to make that fact explicit and visible :)11:26
LeoNerdfullermd: That only really works if the cost of writing the patch is small. I have a ~50line change to make to the core of the BSD kernel's kqueue handling. Kernel dev. requires a very large initial investment in setting up the dev. environment, virtual machnie, etc...11:26
LeoNerdAgain economically, it's a large outlay of capital on a risky venture11:26
spivLeoNerd: I'll ping poolie about that, thanks for prompting the idea.11:26
LeoNerdspiv: Hehe.. Oh; I'm not complaining about bzr specifically here; just open source in general. :) But if you guys can manage to be above-average, then great.11:27
cheateri'm still fairly annoyed at bzr not really working well when my internet access is faulty11:27
cheateri'll even get corruption11:28
spivLeoNerd: yes, we'd like to be :)11:28
cheateror rather, the checkout goes into an unworkable state that's probably non-trivial to fix11:28
cheateris there a way to convert my checkout done with sftp:// to bzr+ssh:// ?12:57
cheateri really don't want to re-download half a gigabyte of stuff12:57
exarkuncheater: Do you have a shared repository?12:59
LeoNerdThe checkout -data- is the same13:01
LeoNerdThe URL used to access it is transient13:01
LeoNerdvim .bzr/branch/branch.conf  :%g/sftp/bzr+ssh/13:01
LeoNerder..  :%s/13:01
cheaterLeoNerd, is that really all?13:02
cheateri have noticed that, but i was wondering if there's any caveats13:03
cheaterif it's this easy that's great13:03
LeoNerdI've done it loads of times13:03
LeoNerdNever broken anything for me13:03
cheaterthank you13:03
exarkunI guess a way to do it without editing the config directly is 'bzr pull --remember newurl'13:04
LeoNerdYah, but that only updates the pull location13:05
fullermdIf you're talking a _checkout_, you want 'switch'.13:05
LeoNerdI often end up with three locations13:05
LeoNerdparent, pull, push13:05
LeoNerd.oO( because of that stupid bug )13:05
cheateryeah it's a checkout13:08
cheaterwould you say that bzr+ssh is more durable/robust than sftp?13:13
cheaterit certainly seems *faster*13:13
jelmercheater, it is faster, because the transport is not "dumb"13:16
jelmercheater, It should generally be as reliable as bzr+ssh13:17
cheatersftp you mean?13:18
cheateri'm having problems with the transport handling, e.g. if i ctrl-c out of a bzr update or commit i get runaway processes that keep spamming my console13:19
jamcheater: the only time I've seen an advantage with sftp was on a *very* low-powered CPU machine on a fast local network.13:19
cheateri'll see in the future whether bzr+ssh does the same13:19
jamcheater: can you describe/paste "spamming" ?13:19
cheatersure, i'll ctrl-c out when bzr is doing something, and then when i'm back in my shell i continuously get prompts for the password written out, and an information that the authentication failed (probably because the password doesn't get entered because there's nothing connected to the stdin)13:21
cheateri can't paste it right now but let me try to reproduce it13:21
jamand is that with bzr+ssh or sftp13:22
cheaterit's with sftp. i have just started using bzr+ssh.13:22
jamI believe we tried to block ssh from receiving the ^C immediately, so that when connected, we can clean up more-cleanly13:22
jam(we try to unlock, etc, and if SSH has been terminated, we can't do any of that.)13:22
cheatersometimes when i ^C i get bzr: interrupted13:23
cheaterit seems to be handling it well then13:23
cheaterbut sometimes i get a python trace with KeyboardInterrupt13:24
cheateraha, no it doesn't13:24
cheateri have just triggered it13:24
cheaterlet me test a bit more13:29
cheaterah yes, and it also messes up my terminal prompt13:31
cheaterhappens with both bzr+ssh and sftp13:32
cheaterjam ^13:33
jamcheater: as mentioned above, we trap SIGINT to let the ssh subprocess die "gracefully" under certain circumstances13:35
cheaterthat's ok - it would be nice if you could make it not break my terminal though =)13:35
jamcheater: don't kill it before typing your password, and it won't spam your terminal :)13:36
cheateri want my money back :)13:37
jamcheater: use ssh keys instead of passwords13:39
cheateri know. can i have my $0 back though? ;-)13:39
fullermdI'm afraid your argv[0] has already been spent  :p13:48
jamjelmer: how are you submitting your branches? I see the 'commit message' change, and the branches in pqm, but it doesn't tell me that you are sending it to pqm. (which 'feed-pqm' does.)13:53
=== med_out is now known as medberry
jelmerjam: I am actually using feed-pqm13:58
jelmerjam: ah, local changes from when I was hacking on hydrazine (I had the lp comment thing commented out)13:59
jelmerreverted now13:59
jelmerjam: thanks for those reviews14:00
=== medberry is now known as med_out
mwhudsonjelmer: hi?14:42
jelmermwhudson: hey14:43
jelmerhow's the sprint going?14:43
mwhudsonjelmer: do you know what is required to implement imports of non-master git branches in lp?14:43
mwhudsonjelmer: it14:44
mwhudsonjelmer: it's going well, pretty intense14:44
jelmermwhudson: I sent an email to the bazaar list about that two days ago14:44
mwhudsonjelmer: ah ok14:44
jelmermwhudson, https://lists.ubuntu.com/archives/bazaar/2011q3/073304.html14:44
* mwhudson hasn't been reading email14:44
* mwhudson reads14:44
mwhudsonjelmer: ah ok, so it's actively in progress then?14:46
jelmermwhudson, yup14:49
mwhudsonjelmer: great14:49
jelmermwhudson, though help is of course always welcome14:49
mwhudsonjelmer: any idea of an eta?  a few weeks?14:49
mwhudsonjelmer: heh, well...14:49
mwhudson(linaro cares about this though, so there is a slight possibility of help...)14:49
jelmermwhudson: Presumably a few weeks, but there are probably a few too many things I have in progress at this point14:51
mwhudsonah ok14:51
jelmermwhudson: It's good to know this is important for linaro, that helps when deciding what to finish next.14:51
mwhudsoni'll keep on asking then :)14:52
jmlmgz: \o/15:38
* mgz is just commenting on unprintable-assertThat-80412715:39
jmlmgz: cool, thanks.15:39
=== vila_ is now known as vila
jmlmgz: I've reviewed your patch.15:50
jmljust one question.15:50
mgzjml: answered, and nearly done on review.15:58
=== med_out is now known as medberry
=== beuno is now known as beuno-lunch
=== medberry is now known as med_eatz
=== Ender is now known as JasonO
=== beuno-lunch is now known as beuno
=== med_eatz is now known as med_afk
=== med_afk is now known as med_out
=== yofel_ is now known as yofel
hexspritenew to bzr, is common for bar diff on lightweight branch to consume 1meg on a medium size repo for each time i run it with no caching etc?21:34
hexspritedownloads 1meg that is from remote21:34
jimisif the branch is lightweight, it always fetches from remote21:39
fullermdLightweight checkout, you mean?  Yes, it's always gotta transfer stuff down.21:39
fullermdReally, on anything but local disk or a rather fast LAN, lightweight checkouts are usually not gonna be a great idea.21:40
jimishexsprite: latest releases (2.4 for sure, not sure about 2.3) have fixed some bugs that download much less data in some cases21:45
jimismaybe you want to check them out21:45
hexspriteahh this machine is ubuntu 10.4… ancient ;)21:46
jimisbut still nothing is cached when it's lightweight21:46
jimisHow do I commit specific changes in a branch different than the one I'm on (i.e. without doing bzr switch)?22:33
RenatoSilvahow do I commit without any message22:39
jimisRenatoSilva: did you try bzr commit -m ""?22:40
RenatoSilvajimis: nham, that's boring :P I want to be cool :P22:41
RenatoSilvajimis: even if I have to bzr commit --type-much-more-huh. Now serious, I just think that there is indeed and option rather that yours22:42
RenatoSilvajimis: *an option, maybe I'm not recalling correctly22:43
=== med_out is now known as medberry
fullermdjimis: merge --uncommitted ?23:01
jimisfullermd: nice one. But from all changes I need to pick 2 files23:09
fullermdmerge --uncommitted /this/file ?  :p23:10
jimishmmm I thought that "bzr merge" took a branch location as argument...23:11
jimisand based on the help I assumed it would be the branch to commit *to*23:11
jimisfullermd: so how would I write the command, to commit uncommitted changes of file F to branch B?23:12
fullermdYou can point it directly at a file in the branch as well.23:20
fullermd(alternate answers; merge then revert everything else.  Or, shelve all but the files you want, then merge.  Or, commit just those files, branch from that, then uncommit that.  Or...)23:20
jimisthanks fullermd23:25
jimiswhat I did:23:25
jimisbzr switch B   (I didn't know this would preserve uncommitted changes)23:25
jimisbzr commit F1 F223:25
jimisbzr switch A   (switch back)23:26
jimis(now only the rest of the changes are there)23:27
fullermdOh, yes.  That works too.  I presumed you had individual branches.23:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!