jelmerChrisMorgan: this is caused by bzr probing for the smart server00:02
ChrisMorganThat went over my head :-)00:03
ChrisMorganJust agree that it didn't work :P00:03
spivChrisMorgan: when bzr sees a http:// URL, it'll first try POST to $url/.bzr/smart with a smart server request.  jelmer is saying that for some reason this probe is preventing bzr-svn from being able to do its own probe and take over.00:09
ChrisMorganShall I put that in my bug report or let you two comment it?00:10
spivChrisMorgan: (maybe the server is rejecting the bzr smart server probe with a slightly unusual HTTP response code, or something like that)00:10
spivChrisMorgan: well, please file a bug if you haven't already00:10
spivChrisMorgan: we've have a few along these lines before, no need to paste my generic explanation into the bug :)00:11
ubottuLaunchpad bug 506196 in bzr-svn "SVN checkout failing with empty authentication details" [Undecided,New]00:12
spivChrisMorgan: you may be able to workaround it by prefixing svn+ to the URL?00:13
spiv(Or perhaps by prefixing nosmart+ come to think of it...)00:14
ChrisMorganI'll leave you to comment that addition then.  I've already posted mine.00:16
ChrisMorganNevertheless, it's still a bug :-)00:16
ChrisMorganIf it works with svn it should work with bzr :-)00:16
ChrisMorganThanks though, I really wanted all the information so I can revert to Django 1.1 if I needed to while off-line00:17
spivThanks for reporting the bug :)00:17
ChrisMorganSVN is slow... now I've made it to revision 500/7768...00:18
spivYeah, it's not really designed to send you the complete history :)00:19
ChrisMorganFor some things I'd just want a lightweight checkout, this time I do really want it all.00:25
lifelessI thought someone already maintained a django bzr collection of branches00:28
ChrisMorganOver 2000...00:31
ChrisMorganI have heard of it... I dunno00:31
ChrisMorganIt's been used for benchmarks00:31
poolieChrisMorgan: it might help if you attach the log from running01:39
pooliebzr co log+http:/otauhaotnhu01:39
poolieif you haven't already01:39
jfroy|workjelmer: have you had a chance to look at that new bzr-svn exception I'm hitting?02:04
* igc lunch02:13
idnaris there a better way to change a commit message than uncommit + commit?03:58
fullermdThere's not a simpler way for simple cases (that I know of)04:01
fullermdAny 'better' way would be functionally equivalent in the end, anyway.04:01
idnarI guess I mean "easier" ;P04:01
idnaranyhow, no big deal04:01
spividnar: easier in what way?  Open an editor with the old commit message I guess?04:03
idnarsomething like that04:04
spivIt'd be nice to have something like that, maybe commit --redo or something.04:04
spivuncommit's useful for more than just changing the commit message, of course.04:04
idnaror even just avoid the risk of including uncommited changes or whatever04:04
idnarironically, darcs has a command (amend-record) that lets you include additional changes but doesn't let you change the patch name04:05
jampoolie: I like the new "always report if it came from a user-defined source" version04:36
pooliethanks, sent04:40
pooliejam, i think our patch-landing latency is improving for developers as well as new contributors since mooloolaba04:40
pooliewhich is good04:40
poolieno room for complacency though04:40
pooliecan someone help me work out where to write a test for bug 456077?04:50
ubottuLaunchpad bug 456077 in bzr "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [Medium,In progress] https://launchpad.net/bugs/45607704:50
poolieor maybe it doesn't really need one04:50
lifelesspoolie: sure04:50
lifelessso what do we want, a ui.note when getting a stream with a different format?04:51
pooliei guess in per_interrepository04:51
pooliemore broadly, when the fetch is going to be noticeably slow04:51
lifelessso the stream interface is tested on repository, not interrepo04:52
lifelessand thats where the code would live, so I'd write the test there.04:52
lifelessas for 'when it will be slow' - there isn't a guaranteed metric for that.04:53
poolieand will all fetches go through the stream interface?04:53
lifelessso to me that means writing per-case tests.04:53
lifelesspoolie: all the bzr <-> bzr ones do now04:53
lifelessit was one of the major achievements spiv and I had last year04:54
lifelessconcretely we expect getting a revision-delta style stream to be painful on non-CHK repositories04:55
poolieok, so you could possibly override InterRepository, but that's not actually expected to be done04:56
lifelesssvn/git/hg fetches do that04:56
lifelessthey provide specific optimisers at the moment I believe.04:56
pooliei wonder if a warning is useful there04:57
lifelessthey could move to using the streaming interface at some future point.04:57
poolieprobably not04:57
lifelesspossibly it is, but it won't help mysql:)04:57
lifelessand the place to put it would be in the SVN or whatever InterRepo class anyhow, I think.04:57
pooliewell, i was thinking of putting it in the base interrepo class04:58
pooliebut, as you point out, that is no longer where the variation is04:58
lifelessfetch.py does this04:59
lifeless            source = self.from_repository._get_source(04:59
lifeless                self.to_repository._format)04:59
poolieyes i see04:59
lifelessbut its the repo _get_source that will actually know its going to be slow.04:59
poolieso we have a StreamSource or RemoteStreamSource locally05:01
lifelessin repository.py05:01
poolieand i guess that can give the warning...05:01
lifelessthere is a bunch of logic that may call into05:01
poolieah yes05:01
lifelessthat *that* function is the one that does the hard work.05:01
poolieand that's not overridden in the remote case05:02
lifelessnote that with fetch from bzr+ssh, this code block will execute on the smart server.05:02
lifelessbut you can use the current 'stderr shows on the client' 'feature' to let users see the warning anyway, for now.05:02
lifelesspoolie: right, nothing is overridden in the remote case; the entire object is proxied05:03
pooliethe comment on get_convertable... says "the source is using CHKs" but this actually seems to cover all different-format cases?05:07
pooliethanks very much05:08
pooliedo you recall if the deprecation warning patch landed already?05:08
lifelesssorry no05:08
pooliei guess this won't work over bzr+http or tcp until we have a way to remote ui operations05:12
lifelessif you were willing to bump the stream format05:13
lifelessyou could do a step towards the progress-in-streams stuff I've speculated on05:13
lifelessand include a substream of type 'warning'05:13
lifelesson push operations the RemoteStreamSink would see that and show it locally, on pull operations the StreamSink would get it from the network and show it.05:14
pooliealternatively we could make sure the logic runs on the client05:14
pooliebut that seems a bit messy05:14
lifelessyou'd have to duplicate it - cause it to run twice05:14
lifelessand you wouldn't know about config or environment on the server, so you'd be guessing05:15
pooliei guess we could make the client give this warning if it receives a stream of inventory-delta?05:15
poolieregardless of why the server decided to send that?05:15
lifelessspecifically you'd want to make the Sink do that, if its not running inside a server, and RemoteSink to do it if it observes it going past.05:16
lifelessits a little crude, but it will do05:16
pooliedo you think that's better?05:18
poolieit seems possibly better to me05:18
lifelessI think it will work now, as a stderr output would. It would work in tcp and http as you noted, so thats better05:18
lifelessOTOH deltas can be very fast chk<->chk so perhaps there will be some false positives in the future.05:18
pooliei'd kind of rather deal with the false positive05:22
lifelessthen do that :)05:22
lifelessif there are are any05:22
PengIsn't there some bug about dirstate when you upgrade to a rich-root format?05:26
PengShould I...do something, or is it fine?05:26
lifelessPeng: nada05:26
Pengit's fine?05:27
Pengjelmer: ping05:27
poolieso, u05:29
pooliefetching from 2a into 1.14-rr does seem to use InterDifferingSerializer05:29
pooliewhich does not seem to use streams05:29
poolieor, not in a  straightforward way05:30
* poolie looks05:30
lifelessoh, locally?05:32
lifelessI'd check with spiv at this point.05:32
lifelessspiv: ^05:32
lifelessI was fairly sure that even that remnant had been dropped, but apparently not.05:32
spivIt's only used for local fetches.05:33
spivSee InterDifferingSerializer.is_compatible, it returns False if either side has a URL starting with file:///05:33
spiv(And only if the serializers differ, etc.)05:34
spivSomewhere, possibly just a mailing list thread, there's a list of things we need to fix to be able to drop IDS completely.05:35
spivIIRC it was progress indication and worse speed/memory for local fetches (although the speed/memory was partially addressed?).05:35
Pengerk, now I can't unping him.05:40
=== arjenAU2 is now known as arjenAU
pooliespiv actually it's false if either of them is not local05:51
pooliebut iswym05:51
poolieso it seems that we need a warning in both ids and streaming05:51
spivIDS is duplication, after all.05:54
pooliei'd like to add blackbox tests to make sure i'm actually covering the right things05:54
lifelesspoolie: well, I'd really be inclined to write tests close to the code06:22
lifelesspoolie: but I know we have differing opinions on this ;)06:22
poolieto me the risk here is not so much that my call to warning is wrong06:23
pooliebut that the code is not reached at all06:23
poolieas it was not in my/our first attempt06:23
poolietherefore i want an integration test that checks that06:23
pooliespiv, i'm going to merge 2.0 back to trunk, which will carry some of your cleanup changes06:29
pooliejust so you know06:29
doctormoi'm having some trouble threading bazaar when gtk is running... without the threading bzr works but locks up gtk, but with threading bzr hits Branch.open(remote_branch_url) and doesn't do anything afterwards in that thread.06:30
doctormodoesn't even end.06:30
spivpoolie: sure06:30
spivpoolie: I think you'll find that the cmd_annotate change from 2.0 can be discarded, but that the test that is added ought to be kept.06:30
poolieoh ok06:30
pooliethat conflicted06:30
pooliewhy should it be discarded?06:31
spivThe command_cleanup branch included the cmd_annotate fix, but using add_cleanup rather than try/finally.06:31
poolieit looks like an improvement, trunk still does it without cleanups06:31
spivThe change in trunk was the try/finally for the tree lock IIRC.06:31
pooliebut we want to end up with it using cleanups in trunk, don't we?06:31
spivpoolie: right; I mean discard the 2.0 version and keep it as it is in trunk :)06:32
spivdoctormo: hmm06:32
spivdoctormo: I doubt most of bzrlib is threadsafe06:33
doctormospiv: AWOS: don't use threads it won't work?06:33
spivdoctormo: so your gtk program can use threads, but you should take care to only call bzrlib from a single thread.06:33
poolieoh i see06:34
doctormospiv: OK, I think I may be able to wrangle the mental image, I think it's changing the ui outside the thread.06:34
lifelessspiv: our own server is multithreaded06:35
spivlifeless: yeah06:35
lifelessdoctormo: bzrlib should be pretty safe as long as you only use a given object from the same thread.06:35
lifelessdoctormo: so you can use two threads, or N, but don't pass a (say) Branch opened from one thread to another thread.06:36
spivlifeless: but we don't share objects between threads...06:36
spivlifeless: it's simpler just to say "don't use multiple threads" :P06:36
spivlifeless: but you're right.06:36
lifelessspiv: yes, I'm trying to rephrase what you said in a slightly less restrictive way ;)06:36
doctormolifeless: Don't use threads unless you know how to control leaks.06:37
lifelessdoctormo: uh, I think thats a very different statement ;)06:37
lifelessfor all that it may be wise06:37
Penglifeless: I can't land things in bzr-loom.06:39
lifelessPeng: aren't you in ~bzr yet?06:39
Penglifeless: No.06:39
Penglifeless: About once a month you suggest it, but then none of us (including me) follow up. :)06:39
lifelessyou can now06:40
Penglifeless: Cool, thanks. I'll land it.06:40
lifelessand you're now in ~bzr. welcome to the firehose06:41
StevenKPeng: Are you the same Peng that hangs around in #linode, too? :-)06:42
PengStevenK: Yes.06:43
chrispitzeri want to check out from a bzr branch, but I don't want the new working copy to be a bzr repo - just a working copy.06:54
chrispitzerI think there's a command for this...06:54
chrispitzerbut I can't find it06:54
ChrisMorganchrispitzer: I think you want a lightweight checkout then.06:55
Pengchrispitzer: You don't want a local copy of the history? You're looking for "bzr checkout --lightweight" or "bzr branch --stacked", depending on whether you want a checkout or branch.06:55
ChrisMorganbzr co --lightweight06:55
lifelesschrispitzer: note that this will be very slow over the internet07:00
vilahi all07:07
ChrisMorganlifeless: but only for things like log, annotate, etc. Diff shouldn't take longer, commit will take just as long.  That's right isn't it?07:08
lifelessChrisMorgan: no07:10
lifelessdiff will take longer07:10
lifelesscommit will take longer07:10
ChrisMorganFor a checkout?07:11
lifelessa lightweight one, yes07:11
lifelessdiff on a heavyweight one shouldn't be affected07:11
ChrisMorganParticularly though, why will diff take longer?  Doesn't a lightweight checkout still have the latest revision?  What would need to be looked at in the network?07:11
spivChrisMorgan: a lightweight checkout doesn't have its own copy of the original version to compare to07:11
lifelesscommit on a heavyweight one will be slightly affected07:12
spivChrisMorgan: it has to fetch that from the repository, so diff will be slower if the repository is not local.07:12
lifelessChrisMorgan: say your round trip time is 100ms07:12
ChrisMorganSo it's not like an SVN checkout.07:12
spivChrisMorgan: rigth07:12
spivright, rather07:12
ChrisMorganI thought lightweight made it that way.07:12
ChrisMorganstacked branch is the same then I presume?07:12
spivWell, it's like SVN only more extreme :)07:12
lifelessChrisMorgan: diff on a lightweight checkout will open the branch ~(600ms) and repository ~(400ms) before doing anything locally07:12
lifelessChrisMorgan: so thats about a second of overhead, before you consider the cost of getting out basis files where a difference is detected07:13
spivStacking will at least keep some of the repo locally.07:13
ChrisMorganAnd why, oh, /why/ do you have "lightweight" checkouts and "stacked" branches if it's the same thing?07:13
lifelessChrisMorgan: lightweight makes it roughly like CVS checkouts07:13
spivBut stacking isn't really designed for this case (yet).07:13
ChrisMorganI'm not really familiar with CVS... I tried it once for some Drupal work and haven't got over the shock yet.07:13
spivChrisMorgan: it'd be nice to collapse them, but at the moment they serve different needs07:13
lifelessChrisMorgan: stacked branches can diverge07:13
spivChrisMorgan: there's a huge thread on the mailing list on (broadly) this topic atm :)07:14
lifelessChrisMorgan: checkouts can't(*), so they aren't really the same thing at all.07:14
ChrisMorganYeah, but is the only difference between a checkout and a branch that the first is bound?07:14
lifelessthe only difference between 'bzr checkout oo' and 'bzr branch oo' is that the former binds to the source whereas the latter sets the parent to the source07:14
lifelesscheckout --lightweight doesn't create a local repo at all and replaces the local branch object with a branch reference pointing at the source07:15
pooliehi vila?07:30
vilapoolie: hey !07:30
poolievila, i think we're meant to talk07:30
vilapoolie: yup, I started the day with a crashed desktop (and was lucky enough to reboot the host only after suspending the guest...) but things seem to be ok now07:31
bialixhello all09:11
lifelesswin 3809:14
lifelesshi bialix09:14
bialixhey lifeless, what's 38?09:15
igchi bialix!09:16
* igc dinner09:16
bialixhi Ian09:16
spiv_bialix: the number of the irssi window he failed to switch to (he meant to type /win 38)09:16
bialixbtw, igc, I've update explorer translation template09:16
doctormoI'm still having odd problems with threading, could a kind person look over the code quickly and see if they spot any dumb mistakes?09:22
doctormohttp://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/nautilus-groundcontrol.py from line 162 to 17509:23
doctormoand http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py the entire file is probably of interest.09:23
=== spiv_ is now known as spiv
aquariusbzr's launchpad plugin doesn't, currently, help with the creation of new projects, and I'm looking at hacking on it so that it does so. Was this left out for a reason?09:29
spivaquarius: no, and we'd welcome improvements to the plugin09:36
spivaquarius: (originally it was because Launchpad didn't have launchpadlib when the plugin was created, just a couple of XML-RPC methods)09:37
aquariusah, cool.09:37
aquariusatm, all my small projects live in my svn server, because setting up a launchpad project is a pain by comparison with typing four svn commands :)09:38
aquariusbut typing "bzr lp-new-project projectname description" in a folder to make it an LP project would get over that hump quite nicely09:39
lifelessaquarius: this may involve hacking on lp09:40
aquariuslifeless, really? launchpadlib lets me create projects, I think?09:41
lifelesscoverage of exposed apis can be pretty hit and miss09:41
aquariusshould do. if it doesn't I shall whine mightily at leonardr :)09:41
aquariusif I've got a plugin in the system plugins folder and a plugin with the same name in my local plugins folder, the local one will override the system one, yes?09:42
lifelessmtaylor: you really should release a new pandora build if you're talking on it.09:43
lifelessmtaylor: the version I packaged in debian is way old now09:43
lifelessaquarius: ywa09:45
jszakmeisterbialix: Hi!  I have a quick question about scmproj...09:58
bialixheya jszakmeister! sure09:59
jszakmeisterHow do you work on a local branch and merge the result back in?09:59
bialixmerge locally and then push10:00
bialixmaybe I misunderstood your question?10:00
jszakmeisterLet's say I have a trunk of library that's in the workspace created by scmproj...10:00
jszakmeisterI want to create a branch of trunk for that library, make the change, and get it reviewed by the team.  Does scmproj support that sort of workflow?10:01
bialixUsually we're creating new alt for this, and put new branch under that alt10:02
bialixthen merging 2 alts when ready10:02
bialixbut alts is half way to deprecation10:02
jszakmeisterThat's what I thought. :-)10:03
jszakmeisterDo you envision some other way of doing this?10:03
bialixinstead of alts you may want to use just new branch of project config10:03
bialixbut today alts are still supported10:03
bialixand sometimes they are much easier10:03
bialixI'll remove alts once I will have new layout format with snapshots ready10:04
jszakmeisterI had that thought as well.  But the one project I'd like to use it for is massive.10:04
jszakmeisterI'd rather not have a whole second tree, if I can avoid it.10:04
bialixnew branch of project config is much closer to what nested trees should be10:04
bialixjszakmeister: in the past I've tried to create something like bzr-colo now10:05
bialixtoday I'd suggest using bzr-colo plugin10:05
jszakmeisterI saw that on the list... looks interesting!10:05
bialixI've played with it yesterday and it really in good shape10:05
bialixdespite version 0.0.110:05
bialixI'm not sure yet I will want to provide tight integration with colo in scmproj10:06
bialixjszakmeister: if you have only branch for one component then I'd use alts today, publish your branch on the server for review, then merge alts10:07
bialixto merge alt from server you need: bzr pcmd "merge {BRANCH_URL}" --alt XXX -i your_library10:07
bialixthere --alt XXX will be your alt (corresponding to your new branch)10:08
jszakmeisterYeah, but I don't want to head down a path thats going to be deprecated.10:08
bialixlook at http://bialix.com/scmproj/docs/howto.html10:08
jszakmeisterI'd rather say "we can't do that right now" instead.10:09
bialixhmm, it's so strong for me10:09
jszakmeisterThe backend is actually in Subversion, so they have other choices.10:10
bialixyou're underestimate the power of pcmd10:10
bialixI don't see the full picture of yours10:11
jszakmeisterThey have everything in a Subversion backend, and have been using externals to manage the tree.10:11
jszakmeisterBut it's a PITA.10:12
jszakmeisterPlus, the backend is old (before SVN had merge tracking)...10:12
doctormoI'm going to bed now, thanks for the help before, although the problems remain I'm sure it's a simple fix.10:12
jszakmeisterIt'd be nice to switch them to Bazaar and bzr-svn, but we don't *have* to10:12
jszakmeisterThat was the next one on my list to examine. :-)10:13
jszakmeisterThe nice thing about scmproj is pcmd10:13
jszakmeisterand the fact that you can run operations on everything.10:13
jszakmeisterSo, bzr-colo... works for more than just trying to get colocated branch support for one "project"?10:15
jszakmeisterI thought, from the name, it was really just trying to handle multiple branches of the same project.10:17
bialixbzr-colo provides git-style workflow10:19
bialixmultiple [feature] branches of the same project10:19
jszakmeisterYeah, that's what I thought... which is very nice!10:20
jszakmeisterI just need something more along the lines of scmproj for the other projects though.10:20
bialixalong the lines?10:20
jszakmeisterSorry... I should use better English: "something like scmproj"10:21
bialixno, that's me10:21
bialixwell, scmproj is nice when you have set of loosely related components10:23
bialixor when you have common library for several projects10:24
jszakmeisterThat's exactly our case.10:24
bialixI have no experience with svn:externals though10:24
jszakmeisterBe happy that you don't. :-)10:24
bialixjust read the docs10:24
bialixbut I mean maybe I'm lack some knowledge10:24
bialixthe good thing about small company/startup is that you can choose any vcs you want10:25
bialixbut you have to admin it yourself too10:25
bialixjszakmeister: I'm planning to add some tips about merge in scmproj10:27
bialixor maybe I should finally implement it as separate command10:28
jszakmeisterThat would be great (either one!)10:28
bialixthere is enough special cases user have to care10:28
jszakmeisterI completely missed the merge docs the first time around10:28
bialixyour position re alts is very strong, I did not expect people can get it this way10:29
bialixthanks for feedback!10:29
jszakmeisterYou're welcome!10:29
bialixif you have any suggestions or more question: I'll be happy to hear them10:30
bialixtoday my own experience drives the development of scmproj, but I can miss some other POV10:31
jszakmeisterI'm actually trying to write a few things down, but I believe I will have some suggestions for scmproj.10:32
vilatestr failiing doesn't seem to be implemented despite being mentioned in README.txt10:35
vilaOf course that the one I was interested in :D10:35
spivvila: failing to fail is still a failure, right? ;)10:35
vilaspiv: yes, I'm whining about failing to sucessfully fail :)10:37
vilaerr, wrong channel for my remark about testr >-)10:37
lifelesswell, it will get my attention :P10:38
lifeless#testrepository if you want the 'right channel'10:38
bialixhi vila10:53
vilahi bialix10:53
quicksilversupposing bzr+ssh://remote-a and bzr+ssh://remote-b are two different branches which share 99.9% of their revision history.11:14
quicksilverand they're large enough that they're slow to branch afresh.11:14
quicksilverand I already have a local branch of remote-a11:14
quicksilverwhat's the quickest way to get a local branch of remote-b?11:14
fullermdIs your local branch of remote-a in a shared repo?11:15
RAOFquicksilver: Have remote-a branched in a shared-repository (initialised with “bzr init-repo”) and then branch remote-b into the same repo.11:15
quicksilverfullermd: no, but if that's the right answer then in future I will arrange for it to be so :)11:15
RAOFI'm pretty sure you can reconfigure remote-a to be in a shared repository.11:16
fullermdWell, you could fudge without it.  But you'd be wasting near double the space, from 2 copies of the history.11:16
fullermdYes, you can.  init-repo a repo around it, and use 'reconfigure' to move its history into it.11:16
* fullermd sprinkles a few more pronouns into that sentence just for kicks.11:16
RAOFMetasyntactic variables FTW!11:16
quicksilverfullermd: cool.11:18
quicksilverdoes 'bzr info' show when you've done it right, I.e. when it is using the shared-repo properly?11:22
fullermdIt does.11:22
quicksilverOK. I bzr init-repo . to create my first shared repo.11:27
quicksilverthen I bzr branch bzr+ssh://remote-a remote-a to populate it with the first branch11:28
quicksilverand it freezes only a second or so in, saying:11:28
quicksilver[#########|          ]    103KB   100KB/s | Fetching revisions:Get stream sourc11:28
fullermdWell, you already have the first branch locally, don't you?11:28
quicksilveroh, it's unfrozen11:28
quicksilverwas a good 60 seconds though11:28
quicksilverfullermd: yes, I do. I was faking a clean start to (a) make sure I understood the process and (b) as a basis for explaning it to colleagues11:29
fullermdI've been trying to fake a clean start for years, but I haven't managed to burn all copies of the....11:29
fullermdNevermind.  Didn't say anything.11:30
quicksilverI think some kind of insect is trapped inside the bzr process now. chk:chk it's going.11:37
quicksilverperhaps a baby bird.11:37
fullermdThat's the buzzer.  Hence the name.11:37
fullermdchk:chk means there's a small sliver of paper stuck between the hammer and the bell.  You probably need to empty out the bit bucket.11:39
quicksilverOK, the results are in.11:41
quicksilvera clean branch of one of these branches took 4m3011:41
quicksilverthe first branch into a shared-repo took 13m5611:41
quicksilverbut then a subsequent branch (a similar but different branch) took 45 seconds11:42
quicksilverdefinitely better11:42
quicksilverthat's quite apart from the disk space savings, which were pretty close to the 'ideal' 50%11:43
quicksilverbut to be honest disk space isn't what I care about11:43
quicksilverit's branch time.11:43
fullermdYeah.  But they go hand in hand.11:43
quicksilverand making a new local branch took only 4 seconds11:44
quicksilver(mind you it only took 23 seconds without shared repos)11:45
quicksilveronly takes 5 seconds to branch something which was previously local into the shared repo11:56
quicksilverbit suspiciously fast that ;)11:56
quicksilverHmm. Trying transfer another previously local branch in has pushed a python process up to 2.2G resident11:58
quicksilverthat doesn't sound very good.11:59
quicksilverand eventually died with Python(31106) malloc: *** mmap(size=1268281344) failed (error code=12)11:59
quicksilver*** error: can't allocate region11:59
quicksilver*** set a breakpoint in malloc_error_break to debug11:59
quicksilverI'm not sure I believe this is working right12:05
quicksilverIt's not downloaded 100M for this branch, which is basically everything.12:05
quicksilverthat doesn't seem like the shared-repo bit did its stuff12:06
quicksilvercould it be a problem that the remote formats are all pack-0.92?12:09
persiaOut of sheer curiosity, if I just want a copy of the source, ought I expect bzr branch ${foo} or bzr export ${foo} to generate less network traffic?12:15
lifelesspersia: often branch12:18
lifelessthough export has been improved a lot in 2.112:19
lifelessexport will read less, but do more roundtrips before 2.112:19
lifeless[proportional to tree size]12:19
persiaInteresting.  Thanks.  I had wondered about using export as a super-lightweight branch for review and delete, but I think I won't do that :)12:20
quicksilverOK. I can't even 'bzr upgrade' this particular branch in place12:25
quicksilverI conclude this is somehow a 'corrupted' branch.12:25
lifelessquicksilver: I'm going to sleep now, but I suggest yous tart giving details12:33
lifelessquicksilver: as I can't infer anything from the comments you've been making, and corruption is extremely rare12:33
quicksilverlifeless: well the details are only just beginning to come clear to me.12:36
quicksilverWe have many branches of one basic codebase.12:36
quicksilverOne of them, it turns out, is behaving anomalously.12:36
quicksilverOn the server its' 300M whilst the others are 100M (I don't know if this is relevant, but it's odd)12:36
quicksilverand any attempt to 'branch' it causes a python out-of-memory error.12:36
quicksilverI also have a local copy on this machine, which is a couple of months old12:37
quicksilveralthough I presumably downloaded that successfully at the time, any attempt to branch that branch locally gives the same error.12:37
quicksilverand any attempt to 'bzr upgrade' it to a more modern format, same error.12:37
quicksilverok, I got the uploader of that branch to push a fresh copy, and I managed to branch that fresh copy13:04
quicksilverbut it took ages (maybe that's just consistent with the weirdly inflated size) and there is something odd about it13:04
quicksilverStandalone tree (format: unnamed)13:04
vilaquicksilver: try 'bzr info -v', unnamed means you're using an unusual combination13:08
vilado the same for the remote branch13:08
vilaif the repository formats are different, it's likely the slowness is due to the on-the-fly conversion13:09
quicksilver       control: Meta directory format 113:11
quicksilver  working tree: Working tree format 613:11
quicksilver        branch: Branch format 613:11
quicksilver    repository: Packs containing knits without subtree support13:11
quicksilvervila: how would I have "got into" an unusual combination? And how do I get out of it again?13:13
vilawell, using a shared repo is one way13:13
quicksilverI did briefly experiment with shared repos13:14
quicksilverbt I'm not using one here13:14
vilaok (bzr info should tell you anyway)13:14
quicksilverand as I remarked earlier, 'bzr upgrade' crashes in this branch.13:14
vilathat's bad, what does 'bz check' says ?13:14
quicksilverrunning it now...13:16
quicksilverseems to take a little while13:16
vilathat's expected13:17
quicksilverok I'll let you know when it's finished, and eat a sandwich13:19
quicksilvervila:   3927 revisions13:22
quicksilver  3468 file-ids13:22
quicksilver   330 inconsistent parents13:22
vilayup, that's bad enough, do 'bzr reconcile'13:23
vilasorry if you already reply to that but what bzr version are you using ?13:24
quicksilvervila: 2.0.2 on the server 2.0.1 on my client13:25
vilaok, not the latest but good enough13:25
vilaany reason to keep using 0.92 as your repo format ?13:26
quicksilver(although the developer who created / pushed this apparently broken branch is only on 1.13.113:26
quicksilver(and we have another developer who is also on 1.13.113:26
quicksilverbut they could both be told to upgrade.13:26
maxbquicksilver: To clarify, it's an 'unnamed' format because it's pack-0.92 repo/branch combined with Bazaar 2's tree format. bzr 2.x likes to give you the latest tree format even if it doesn't fit into one of the canned names which for {repo, branch, tree} combinations.13:26
quicksilvermaxb: *nod* interesting.13:27
vilathat would allow you to use 2a which will be more compact and faster across the network too13:27
quicksilvervila: I had been thinking about upgrading the repo format13:27
quicksilvervila: in fact it was this train of thought I had13:27
quicksilver"Hmm should use bzr better, let's learn about shared repos and upgrade our repo formats"13:27
quicksilverI was following that train of thought and experimenting with some of our branches when I discovered this broken one.13:27
quicksilverreconciliation only took 3 minutes. That's a relief.13:28
vilaboth should make a significant difference, but upgrading to 2a requires a 'bzr  check; bzr reconcile' anyway, so you're on the right track :)13:28
vilaredo 'bzr check' to be on the safe side :)13:28
maxbRequires? Or just a sensible precaution?13:29
quicksilverthe branch size has doubled again13:29
quicksilverfrom 300M to 600M13:29
vilacheck you /bzr/reposiroty/obsolete_packs13:29
vilarhaa, .bzr/repository/obsolete_packs content, gee13:30
quicksilverI ran bzr check in another branch13:30
quicksilverone which, as far as I knew, was fine.13:30
quicksilverit also has the same 330 inconsistent parents13:30
quicksilveryup. 278M in obsolete_packs.13:31
quicksilverpersonally I still think it's suspicious this branch is 3x as large as the others13:31
vilaat least...13:32
vilayeah, but 3x is better than 6x13:32
quicksilverit does have quite a few changes relative to the others, but not *that* many.13:32
vilaerr, I mean, it shoudn't be 3x13:32
quicksilverI am in the process of re-running bzr check13:32
quicksilvervila: OK, it now passes bzr check.13:37
quicksilver(which took 6 minutes to run)13:37
quicksilverbut it's odd that even the branches I consider "OK" have the same inconsistent parents.13:37
quicksilverI'm going to try to bzr upgrade this branch now I think13:37
vilayou want to run 'bzr reconcile' in all these branches13:38
quicksilveryes, I see that13:38
quicksilverso what does inconsistent parents mean? A problem has been lurking which by luck hasn't bitten us before?13:39
quicksilverand now in this branch for some reason it's biting us13:39
vilamost probably, it's hard to say for sure from here :-/13:40
vilaIt could also be unrelated, IIRC there was several weird cases were you could end up with inconsistent parents, not all of the same gravity13:40
quicksilverwell if bzr upgrade works now, where it didn't work before, then I guess I have "fixed" something"13:41
quicksilverif not, then it's still broken.13:41
quicksilverand I still wonder what event in branch history made the size triple13:41
quicksilverif needs be, I'll binary chop the revisions13:41
vilayou can try eyegrepping 'bzr log -n0 -v'13:42
vilaIt could be some binary file...13:42
vilaWe had a case where someone embedded a whole $DVCS_TOOL repo during several revisions, modified at each revision... ended up with quite a big repo13:43
quicksilvernervously watches Python's resident size increase13:45
quicksilverlast time it hit 2G and then died with a malloc error13:45
vilaquicksilver: well, 2.1 includes some related fixes you may want to try...13:46
quicksilvervila: do I need to bzr reconcile on ther server and also get everyone to bzr reconcile on each client?13:46
quicksilver(that or pull clean branches, presumably)13:46
viladepending on your experiences you may prefer one way or the other, it depends on too many things to have  single answer13:47
quicksilvervila: slight reluctance to use beta versions in production, but if you strongly advise it I'd follow your advicee.13:47
vilaif you end up with smaller repo and that people use shared repos, you may end up downloading it >1 times13:48
quicksilverOK, there she goes.13:48
quicksilverpython resident space > 2G13:48
quicksilvermalloc failure coming shortly.13:48
quicksilverPython(31916) malloc: *** mmap(size=759209984) failed (error code=12)revisions13:49
quicksilver*** error: can't allocate region13:49
quicksilver*** set a breakpoint in malloc_error_break to debug13:49
vilasomething fishy is going on here, first the 3x increase, now the > 2G mem footprint, that's really really far from the 100M size you're mentioning :-/13:49
viladoes that come with a traceback ?13:49
quicksilverno, in fact, in didn't even kill python13:50
quicksilverit just printed that message13:50
quicksilverits RSS has dropped to a more "reasonable" 400M and the upgrade claims to still be running13:51
=== mrevell is now known as mrevell-lunch
vilawow, let it run then !13:53
quicksilverah, eventually13:53
quicksilverPython(31916) malloc: *** mmap(size=691982336) failed (error code=12)revisions:13:53
quicksilver*** error: can't allocate region13:53
quicksilver*** set a breakpoint in malloc_error_break to debug13:53
quicksilverbzr: out of memory13:53
quicksilverI think the long pause was actually the process of freeing enough memory to print the error message :-/13:53
quicksilverno traceback I'm afraid.13:54
quicksilvervila: I have a plan to try to branch an old revision which doesn't have the problems and then successively pull forward, how does that sound?13:54
vilagood, as long you can identify the faulty revision...13:56
quicksilvervila: further clue.13:59
quicksilveror is it14:00
* quicksilver tries to get facts straight14:00
maxbWhat exactly is an 'inconsistent parent'? What's it inconsistent with?14:01
quicksilverI was able to "bzr branch bzr+ssh:/remote-bad-branch bad-branch14:02
quicksilverI was then also able to "bzr branch bad-branch bad-branch-copy"14:02
quicksilverbut since I did reconcile I can't even do that14:03
SamB_XPmaxb: what is the exact error you're getting ?14:03
quicksilverI can't even locally copy the branch with bzr branch14:03
quicksilverbefore the reconcile, I could, and it only took 30 seconds or so to boot.14:03
maxbSamB_XP: None, just interested in understanding more about bzr's guts14:03
SamB_XPwell, where did you see the term then?14:04
quicksilverin my report, SamB_XP14:04
quicksilverwhen I bzr check'ed my odd branch.14:04
SamB_XPI was puzzled about why maxb had asked about a single consistant parent -- I've only ever heard it in the plural before14:05
SamB_XPer. *inconsistant14:05
quicksilverOK, I have confirmed by double-checking.14:06
quicksilverI can locally branch the un-fixed branch14:06
quicksilverbut locally branching the 'fixed' (reconciled) branch gives the out of memory error.14:06
quicksilveruse a DVCS for 4 years and never encounter a single problem, but when I hit a bug, boy is it a painful one :-/14:11
quicksilvervila: OK, I found a sufficiently old branch not have the 'size inflation'.14:21
quicksilvervila: guessing that might be related, I'm going to reconcile + upgrade from this old revision and see how that goes.14:21
vilaand from a complete branch, did you see anything suspicious in the following revs (with 'bzr log -n0 -v') ?14:22
quicksilverI'm currently use a bash for loop to give me a copy of every intermediate revision14:23
quicksilverso I can see where the size inflation is14:23
quicksilverthe bzr log -n0 was rather long to look at...14:24
CaMasonI've got a branch which I've been using as my 'trunk'. To move this to a different physical location, can I just move the repo?14:29
rubbsCaMason: best way is to just branch it to the new location then delete the old one.14:30
rubbsCaMason: I knoticed that the actual repo (on my windows machine) wouldn't work if it wasn't in it's old path for some reason.14:30
CaMasonok. That maintains all of the branch history yes?14:30
rubbsbut if I branched it and deleted the old one it worked.14:31
CaMasonsounds good14:31
quicksilvervila: OK. Using an old branch revision which doesn't suffer the size inflation, the sequence check/reconcile/upgrade worked.14:35
quicksilvervila: so I am inclined to consider the size inflation to be related to this bug, somehow14:35
vilathat would be really weird14:36
quicksilvervila: I note taht format 2a does seem to be about 1.5x larger than pack-0.9214:36
quicksilveris that expected?14:36
quicksilverI don't really mind.14:36
vilalarger ? Certainly not, check /obsolete_packs again14:36
quicksilverright. roger that.14:37
quicksilverlooking good.14:37
quicksilverabout 80% the size?14:37
quicksilver20% smaller, i.e.14:37
quicksilvernow I'm going to try to pull into this "good" branch from the other14:37
vila20% smaller is a bit deceiving but still smaller, we've seen more savings14:39
vilaquicksilver: do that on a copy if you don't mind :)14:39
vilaI thought you made several branches to identify the size inflation ?14:40
quicksilveryes, I have many many branches14:40
quicksilverand yes, I made a copy :)14:40
quicksilverin fact, I did this check/reconcile/upgrade experiment on revision 89614:40
quicksilverI started that *before* I learn that revision 915 was the last revision not to suffer size inflation.14:41
quicksilverso what I'm doing now is, (in a copy) pulling into my upgraded 896 from 91514:41
quicksilverthat went fine, apparently.14:41
vilaso what's in 916 ?14:41
quicksilverunfortunately it's a massive merge14:42
quicksilver39 merged revisions14:42
vilahow many files ? Any binary ?14:42
quicksilveryes there is a binary file in there. It's 1.3 megabytes14:42
quicksilver(and a few smaller binary files) (and many many text files)14:42
quicksilverI believe this is about to crash14:43
vila1.3M is not big, search for > 50M14:43
quicksilverPython process up to 1G resident and climbing.14:43
quicksilverpretty sure there are no files that big.14:43
vilaany chance to publish these branches ?14:43
quicksilvernot really :(14:46
quicksilver4 years of private code history.14:46
quicksilvertwo python memory errors but the bzr pull is still running so I'll let it try.14:48
vilaquicksilver: still using 2.0.3 ?14:49
quicksilver2.0.1 in fact14:50
vilaquicksilver: trying with bzr.dev is worth it I think, try pinging jam to get his opinion though he made most of the memory fixes14:50
jammorning vila14:50
jamno opinions here14:50
jamlet me read14:50
vilamorninbg jam14:50
quicksilvervila: well knock me down with a feather14:50
* vila stop chewing while typing14:50
jamyou guys have been chatting for a long time...14:51
quicksilvervila: despite two scary looking memory errors, the bzr pull has succeeded.14:51
jamcare to summarize?14:51
quicksilverjam: painful out of memory errors doing certain operations with a particular branch14:51
vilayup, quicksilver is encountering memory errors (no traceback, direct from python) while pulling 0.92 branches14:51
quicksilverjam: including: errors when branching, errors when merging, errors when trying to 'bzr upgrade'14:51
vilathat's with bzr-
jamquicksilver: no traceback even with -Derror?14:52
jam(and nothing in ~/.bzr.log ?)14:52
quicksilverjam: comparing my branches en-masse, these errors seem to be co-incident with the repository size on disk jumping from 100M to 300M at a particular revision14:52
vila<quicksilver> Python(31916) malloc: *** mmap(size=691982336) failed (error code=12)revisions:14:52
quicksilverand I don't believe there is a good reason for the size jump; I don't think we added then deleted a 50M binary file or anything of that nature.14:53
jamquicksilver, vila: allocating 691MB in a single shot?14:53
quicksilverother errors with slightly different numbers14:53
vilano, more like 200M14:53
vilahaa, the malloc hyes14:53
jamquicksilver: 64-bit machine?14:53
quicksilverPython(32408) malloc: *** mmap(size=1267761152) failed (error code=12)14:53
quicksilver*** error: can't allocate region14:53
quicksilver*** set a breakpoint in malloc_error_break to debug14:53
quicksilverPython(32408) malloc: *** mmap(size=759758848) failed (error code=12)xts:texts14:53
quicksilver*** error: can't allocate region14:53
quicksilver*** set a breakpoint in malloc_error_break to debug14:53
quicksilverjam: core2, so technically yes, but running OSX 10.5, so in practice I believe it counts as 32 bit.14:54
jamquicksilver: just run 'python' and see what it says14:54
quicksilvernote that those two errors I just pasted occurred during a bzr pull which appears to have succeeded!14:54
jamI'm not sure about mac, but on Windows I get:  [MSC v.1500 32 bit (Intel)]14:54
quicksilverit spewed out that malloc stuff but still ran to completion.14:54
quicksilverPython 2.6.4 (r264:75706, Nov 12 2009, 09:19:07)14:56
quicksilver[GCC 4.0.1 (Apple Inc. build 5488)]14:56
quicksilvernot much help there.14:56
jamquicksilver: import sys14:56
jam12 == 32-bit, 24 == 64-bit14:57
quicksilvervila: so, that bzr pull which appeared to succed, has jumped the repo size to 470M (from 80M)14:57
vilabam 400M14:58
quicksilvervila: admittedly some more crap has appeared on obsolete_packs which I could remove, but there is still 250M in packs14:58
vilaso 170M increase14:58
quicksilveryes, or roughly 3x14:58
vilaand that's with your upgraded branch right ? So 2a format ?14:58
quicksilver80->250M is quite consisten with the 100M -> 300M I had in pack-0.9214:59
quicksilveryes, this is with 2a format14:59
quicksilver find . -size +1000 | xargs ls -lh15:00
quicksilverthe only files > 500K are one 500K jpeg and a few .pack, .cix, .tix files15:00
vilaquicksilver: that may not be enough, you may have to bisect in the merge revisions15:01
quicksilverin particular, one killer .pack of 192M and one of 55M15:01
vilabut those are in .bzr not committed in your branch right ?15:01
quicksilverthere are no large files in the working tree15:02
vilaquicksilver: it's really weird to see the same size increase in 0.92 and 2a that use very different conpressions algorithms15:02
quicksilver(that jpg of 500K is the largest)15:02
quicksilverI'll knock up a script to bisect all the merge revisions15:03
vilain the mean time, 'bzr log -r-2..-1 -n0 -v' may be less huge15:03
vilathan it was for the whole branch15:03
rubbsisn't there a bisect plugin already?15:03
rubbsI've used it before15:03
jamrubbs: there is15:04
quicksilverIm' not actually going to bisect15:04
quicksilverI'm lazy15:04
quicksilverI'm just going to branch ever intermediate revision and look at the disk spaces they use15:05
jamvila, quicksilver: well, if you are versioning binary files like .jpg, it isn't like we can get tremendous size improvements15:05
jamquicksilver: are you running from source?15:05
quicksilverjam: I don't think the binary files are the issue here15:05
jamI just want to check that you built the extensions15:05
quicksilverthey are small and change rarely.15:05
quicksilverI'm running from macports, which kind-of-source15:05
jamThe 2a pure-python compressor doesn't do nearly as good of a job as the C version15:06
vilajam: a review of https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 will be highly appreciated15:06
jamquicksilver: I think it compiles extensions, though15:06
vilajam: but the size increase was there for 0.92 too...15:06
jamvila: so I think he has more data15:06
jambut the question is how much should it increase15:06
jamquicksilver: the loop over pull is often a good indicator15:06
quicksilverwhat do you mean?15:07
* vila needs to reboot, bbiab15:07
quicksilverjam: of course it's only a hunch that the weird out of memory errors I have seen are related to this sudden lurch in repo sizes.15:09
quicksilverjam: but we have many many branchs, some live, some dead, and we use bzr a lot15:10
quicksilverand it's just on one particular branch that we have this strange issue15:10
quicksilver...and that's the branch with the inflated repo size.15:10
jamquicksilver: there are a few different ways it could happen, old code or new code15:14
jamthe new format hasn't been super-tuned for memory performance during pack15:14
jamit is better for getting data out, commit, etc15:15
jambut 5x the size of the largest file wouldn't suprise me15:15
jamthat doesn't quite explain 1GB that you pasted earlier, though.15:15
quicksilverunderstood, but as far as I know there are no large files.15:15
jamPython(32408) malloc: *** mmap(size=1267761152) failed (error code=12)15:15
quicksilverunless you think a 500k jpg is large?15:15
jamquicksilver: no I'm talking 100+MB files15:15
* quicksilver nods15:16
quicksilverok well there's another python memory error15:16
quicksilverlooks like I may have found the precise revision that causes it15:16
* quicksilver reviews changelog for that revision15:16
jamvila: personal impression, 'bzr resolve' is a bit confused as to what it wants to be, and it is hard for me to give a clear-cut answer for it15:16
quicksilverit is also odd that these memory errors can occur but the branch still succeeds15:17
jamquicksilver: that is quite surprising to me as well15:18
jamI do believe that the OS is the one reporting the error15:18
jamand not python15:18
jambut if the OS is not returning NULL on a bad malloc15:18
jamsomething is weird15:18
vilaright, but what about the rest ? I said to poolie this morning that 1) I targetting 2.2 so no hurry, but no review means I'm stuck 2) I'll try to do a summary mail about the main aims of this work but that mp is just a first step15:19
jamquicksilver: http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/malloc.3.html15:19
jamYou might look at setting one of the ENV vars15:19
quicksilverok, so it looks like part of this is myfault15:19
quicksilveror at least one of my developer's faults :P15:20
jamquicksilver: what's up?15:20
jam(custom plugin?)15:20
quicksilverthere is a 691 megabyte text file in this revision15:20
* vila bets for a bzr branch committed into the branch15:20
quicksilver(which he deleted in the next revision)15:20
jamwell, that explains the bloat :)15:20
quicksilverand it *probably* explains the bugs too15:20
quicksilverin that that was probably causing out of memory errors all over the shop.15:21
jamquicksilver: well it explains why we would try to malloc a huge range15:21
jamI'm not sure why it succeeds but complains about malloc, etc.15:21
vilaquicksilver: time to teach about 'bzr uncommit' in cases like this15:21
jamvila: and it would be good to have a "bzr nuke-this-frickin-file"15:22
quicksilverso, what is the most efficient way to change history?15:22
vilaquicksilver: history being immutable, you can't just take that revision out of the repo, you'll have to recreate that branch with15:22
jamquicksilver: rebase15:22
vilaquicksilver: yeah bzr-rebase, jam finishes my sentence :)15:23
jamI think it is called "bzr-rewrite" as the plugin name15:23
jambut "rebase" or "replay" would be the commands you'd want15:23
quicksilverthat will let me replay a bunch of revisions, including their commit messages, leaving out some detail?15:25
quicksilverhttp://wiki.bazaar.canonical.com/Rebase ?15:26
=== mrevell-lunch is now known as mrevell
vilaquicksilver: https://launchpad.net/bzr-rewrite15:27
vilabut yes, that's the idea15:27
jamquicksilver: yeah, the plugin changed names15:27
jamwell sort of15:27
jamI don't think he has finished migrating15:27
jambecause debian hasn't changed his package name15:28
jamso I think you have to "bzr co lp:bzr-rewrite rebase"15:28
jamwhich is... odd :)15:28
quicksilverthere is a bzr-rebase 0.53 in macports15:29
quicksilverthe description at http://wiki.bazaar.canonical.com/Rebase does not suggest to me it can actually change revisions15:30
quicksilversounds like it just changes tree shape15:30
quicksilver(I've changed tree shape in the past by carefully chosen back-and-forth merges)15:30
jamquicksilver: the idea of rebase is "take a commit that looks like X, and create a new commit with the same delta, but applied to a different base"15:32
jamSo the idea is that for the branch where he added and removed the file15:32
jamyou would rebase the commit after removing the file15:32
jamonto the commit before adding the file15:32
jamnote that it requires rebasing all revisions that follow15:32
jamwhich is... unfortunate15:32
quicksilverah, so you "coalesce" the two revisions which add+remove the file into one15:33
quicksilverwhich makes the file vanish from history entirely15:33
quicksilverand then you have to replay the rest of history after that.15:33
jamquicksilver: right15:33
quicksilverthe first part I could do easily enough by hand.15:33
quicksilverthe annoying part is replaying history15:33
quicksilverespecially if I want to maintain the merge shape15:33
quicksilveralthough, bzr bundle is enough to maintain commit messages isn't it?15:34
quicksilverno, bzr bundle will have a note of the missing revision15:34
quicksilverand complain it's not there.15:34
quicksilverin fact I can't see how do to this by hand.15:38
quicksilverin a way which preserves the merge points with external revisions15:38
quicksilver(of which there are many)15:38
jamquicksilver: I believe you can rebase --include-merges15:38
jambut yeah, it is quite tricky to do by hand15:38
quicksilverwell I'm installing bzr-rebase now15:39
gerard_hey all, any reason for the terminal window you get when launching Bazaar Explorer on windows?15:40
quicksilverjam: OK I've installed bzr rebase, I've read the bzr rebase documentation, and I still don't understand what I'm supposed to do. I don't see how to tell it to ignore/coalesce the bad revisions.15:42
jamgerard_: lack of developer time to get rid of it :)15:42
=== SteveA_ is now known as SteveA
jamit isn't terribly hard, but I ran into version compatibilty problems when i tried15:43
jam(py2.6 + pyqt4.5 + py2exe didn't like to play well together)15:43
jamit shouldn't be hard to fix as those seem to have gotten sorted out15:43
gerard_jam: ah ok15:43
gerard_it might just annoy me enough to get rid of it15:44
jamgerard_: Quick note, you want to set up a 'py2exe' target in bzr's setup.py that uses "window = ['bzr-explorer.py']"15:45
jamand then implement a bzr-explorer.py that is running the equivalent of "bzr explorer $ARGS"15:45
jamI can give some more help if you want to work on it.15:45
jamit is something I would *like* to get to, but not enough tuits yet :)15:45
quicksilverI see no alternative but to work carefully up through the revision history and re-apply partial diffs, being sure to re-merge wherever there was a merge15:55
vilaquicksilver: I never used it myself but I was almost sure it was included in bzr-rewrite, jam, could I be confused with something in bzr-fastimport instead ?15:56
quicksilverwe surely can't be the first people to ever need to change history in this way ;)15:58
jamquicksilver: I don't know what 'bzr replay' or 'bzr rebase' supports. I know there is an "include-merges" flag.15:58
gerard_jam: thx, I'll keep that in mind, I might have some time tonight15:58
quicksilverjam: yes, I see the merge options, but I don't see how to start it off by saying "pretend this bit never happened"15:59
vilaquicksilver: Be also aware that the branch you are re-building should become the reference and that no-one should merge a poisoned branch into it...15:59
quicksilvervila: yes, need to expunge all poisoned branches.16:01
quicksilvervila: but first I need to build a good one16:01
quicksilverI wonder if a careful bit of shelving is enough16:02
jamquicksilver: so create a branch that is just before the add16:05
jamthen tell bzr-replay to replay the revision just after16:05
jamor create a branch just after16:05
jambzr uncommit16:05
jambzr  rm bad-file16:06
jambzr commit -m "new rev without bad file"16:06
jamthen bzr replay everything after that16:06
jam(or rebase)16:06
quicksilverright. That makes perfect sense.16:06
jamthe specific syntax isn't great, and I'm never quite sure whether rebase is "apply this to that" or "apply that to this"16:06
quicksilverbzr rebase takes a branch as its only parameter16:07
jamquicksilver: doesn't it take --revision (-r) as well?16:07
jamvila: quick question16:07
jamfor Copyright headers16:07
* vila afk for ~ ok16:07
jamwhen would you collapse to 'range' notation?16:07
jamwould you collapse 2007, 2008, 2009 or only at 2007, 2008, 2009, 2010 ?16:08
jamI certainly wouldn't collapse 2007, 2008 => 2007-200816:08
vilaNever said I will, but I've seen multi-lines copyright just after you mentioned the problem16:08
jamalso, should it be "2007-2010" or "2007 - 2010"16:08
vilaI thought range notation ought to be avoided but IANAL and I forgot why16:09
jamvila: I thought so too, but poolie just submitted a patch with ranges16:09
jamand I have to say, it looks a lot nicer than 2005-2010 expanded16:10
jam-# Copyright (C) 2005, 2006, 2007, 2008, 2009 Canonical Ltd +# Copyright (C) 2005-2010 Canonical Ltd16:10
vilaand the multi-line occurrence was from a source I thought was valid and serious when I read it16:10
vilayeah, not sure lawers care about nice looking :)16:10
jamok, for now I'm using >= 4 years as the collapsing point16:11
vilaso, afk for ~<1h starting now :)16:11
jamvila: enjoy your time off :)16:12
jam"In the cases of derivative works it is recommended to indicate a range of years for a work (although this is not required by law)."16:12
jamI haven't found anything about not using "-"16:13
quicksilverjam: hm. Of coruse. The uncommit version leaves the uncommited revision in the repo :)16:14
quicksilverjam: so my large file is still there, just in an orphaned revision.16:14
jamquicksilver: yep, but fetching out of that repo won't16:14
quicksilverIIRC there is no way to remove orphaned revisions.16:14
jamquicksilver: well there is the "create a new repo and fetch"16:14
jambut *today* we don't have a "bzr gc" command.16:14
jamquicksilver: also note that after replay you'll have the same objects 2x in the repo16:16
jamso you'll probably want to do it in a temp repo16:16
jamand then create a pristine repo from that16:16
quicksilveryou mean if I were using shared repos?16:16
quicksilverI'm not, at the moment, although way back at the beginning of this conversation I was trying to switch to them :)16:16
jamI'm not 100% sure how replay works16:17
jamI'm guessing it does leave the "from" revisions in the local repo16:17
jamagain, fetching out of there won't propagate them16:17
* quicksilver nods16:17
quicksilverok, so I have my clean repo at revision "N+1" with the altered revision not to commit that horrible file.16:18
quicksilverI want to bring it up to the most recent version16:19
quicksilverI bzr rebase <path/to/most/recent> ?16:19
jamquicksilver: you have reached the limit of my rebase knowledge16:20
* quicksilver nods16:20
quicksilverwell I'm trying it16:20
jamI think you'll have to somehow say you don't want N16:20
quicksilverthat's the part I don't get, yes :)16:20
jamso "bzr rebase -r N+1..-1 path/to/old/brancH"16:20
quicksilverI think it might be --onto16:20
quicksilverbzr rebase --onto N+1 path/to/most/recent16:21
quicksilvercertainly bzr rebase /path/to/most/recent gives the familiar malloc error16:21
quicksilverOK I'm pretty sure that was wrong, since it's given hundreds of conflicts which are wrong16:23
quicksilvermaybe I want to be *in* the recent branch16:23
quicksilverand bzr rebase relative to the fixed branch16:23
quicksilvermaybe I just want to wait to jelmer to appear :)16:23
salgadojam, around?  I was just wondering if there's anything else I need to do to get my fix for bug 308122 through review...16:28
ubottuLaunchpad bug 308122 in bzr "No reliable way to show shelved changes" [Medium,In progress] https://launchpad.net/bugs/30812216:28
=== beuno is now known as beuno-lunch
quicksilverpossiblye https://bugs.launchpad.net/bzr-rewrite/+bug/329951 is what I need16:41
quicksilverbut that's an open wishlist :)16:41
ubottuLaunchpad bug 329951 in bzr-rewrite "support squashing commits" [Wishlist,Triaged]16:41
davidstraussI'm having trouble with bzr-svn. I need it to use a Subversion 1.5+ client, but the OS X install appears bundled to 1.4.16:42
davidstraussI have Subversion 1.6 installed to my Mac.16:43
* vila back from garage, talk about a time-off it's freezing outside :)16:57
maxbquicksilver: I think the bzr-rewrite code for choosing merge base revisions is a bit dodgy when rebasing merge commits16:57
quicksilvermaxb: I have managed to get bzr replay to do something useful17:02
quicksilverbut only one revision at a time17:02
quicksilverand it throws out of memory errors17:02
quicksilverbut they don't appear to *matter*17:02
quicksilverit still works.17:02
maxbIt does not help that bzr replay is a hidden command17:03
quicksilverso by sitting in the "fixed" dir which has the bad commit removed17:04
maxbWhy only one revision at a time, though?17:04
quicksilverI can do "bzr replay -rX.Y.Z ../newest-ver"17:05
quicksilvereach time I do that, it brings in that actual changeset17:05
quicksilverbut nothing older17:05
quicksilverso I need to do that for each value of X,Y,Z17:05
quicksilverstill if it works, I can do that mechanically17:05
quicksilverI have the list of revisions.17:05
quicksilverhowever, I have a conflict because I missed one17:07
quicksilverI did that deliberately to check my understanding of what it was doing17:07
quicksilvermissing one really does miss out that change17:07
quicksilverYes, this actually does seem to work!17:08
quicksilverwell let's see what happens when we get to the first merge revision though17:08
quicksilverthat's what matters17:08
quicksilvermaxb: hmm this may actually work. bash for loop reapplying revisions one by one. I've found another 'evil' one which is using up all my python memroy though17:15
quicksilvernot sure why this one is evil.17:15
quicksilverack repo size up to 470M again :(17:17
quicksilverclean branch just to check, maybe that's orphaned revisions.17:17
quicksilverok, clean copy is still only 80M17:19
quicksilverI'll shift to useing that17:19
quicksilverhmm. I seem to have got to a critical point where every single replay is upsetting it, by making it thing about the large file17:21
quicksilverbut it *is* working.17:21
=== thunderstruck is now known as gnomefreak
vilaquicksilver: someone may have merged the poisoned revision17:22
quicksilvervila: well the poisoned revision hasn't come back yet17:23
quicksilvervila: (using repository size as the proof)17:23
vilaquicksilver: sry for the noise then, I thought you were saying it was back17:23
quicksilvervila: well it's coming back as an orphaned revision.17:24
quicksilvervila: something keeps bringing it back into .bzr/repository17:24
quicksilvervila: but, because it's not referenced by any version in my history, if I do a clean branch or push it vanishes.17:24
quicksilverunfortunately it makes every replay slow17:27
quicksilverbecause I have to replay each revision independently, and each replay is 'worrying' about that huge file in some way I don't understand17:27
quicksilveror maybe not.17:28
quicksilverthey're going faster now.17:28
quicksilverAh, but in a critical way they're not working.17:29
quicksilverthey're not actually recognising merges as merges.17:29
quicksilverOK, so replay isn't the right tool.17:31
quicksilverso maybe rebase is17:32
quicksilverbut I really don't understand how17:32
Adysis there a command for cleaning up all the .~1~ files?17:47
Adysother than find and xargs rm17:47
quicksilvervila: I've established that "replay" neveer seems to replay merginess in the way I want, so it's presumably the wrong tool.17:47
quicksilvervila: It's possible that rebase may be the right tool17:48
quicksilverbut I can't work out how to use it.17:48
vilaquicksilver: I don't use it myself, let's try to ping jelmer17:48
viladamn he's not online17:49
quicksilverreplay replays simple commits (no merge involved) fine17:50
quicksilverpreserving the author, the message, etc17:50
quicksilverI wonder if it preserves the ID17:50
maxbIt would be erroneous to preserve the revid17:51
quicksilverOK, so other merges from this branch would be broken17:51
ronnyquicksilver: talking about bzr-svn? full roundtrip is supported by using svn revision properties and/or storing metadata in rich-root17:51
quicksilveror at least will need the same kind of fixing.17:51
quicksilverbut fortnuately I don't have any of those17:51
maxbronny: No, not bzr-svnhere17:51
quicksilverronny: no. Just trying to use rebase to rewrite history.17:52
quicksilvervila: I will keep an eye open for jelmer.17:52
maxbquicksilver: rebase won't rebase merge revisions either, at least rebase's official versions17:52
maxbI have a branch pending that I need to cast a final eye over and submit to jelmer17:52
quicksilvermaxb: you mean it won't rebase them preserving their "merginess" ?17:52
quicksilverreplay will replay them as naive diffs17:52
quicksilverbut that doesn't solve hte problem - it means later merges will conflict all over the shop17:53
maxbThe trunk bzr-rewrite's rebase starts by picking out a leftmost path, and only ever rebasing revisions on that path17:53
maxbI have no idea why anyone would want that17:53
maxbSo I rewrote it17:53
quicksilverI don't actually understand the connection between what I want to do and what rebase's docs claim it is for17:54
quicksilverbut jam + vila suggested it.17:54
quicksilverthe docs for rebase look to describe something which simple re-pivots an existing history17:54
jamsalgado: It looks like you've covered our requests, I'll merge it17:54
quicksilverwhich you can actually just do with back-and-forth merging17:54
jamI think the delay is just that it isn't always clear when someone has done work17:54
quicksilveralthough some might consider that inconvenient17:54
quicksilvermaxb: do you understand the probelm I'm trying to solve though?17:54
maxbI think I do17:55
salgadojam, great, I can't wait to have the feature available in a release. thanks a lot!17:55
=== beuno-lunch is now known as beuno
maxbWhat's the proper URL for the bzr pqm status page?17:59
=== mrevell is now known as mrevell-dinner
Pengmaxb: http://pqm.bazaar-vcs.org/ ?18:00
maxbwiki/BzrDevelopment links to the SSL version of that, which then triggers a SSL error since the certificate is for canonical.com18:00
maxbMaybe I should just edit the wiki page to point to the plain-http url?18:01
* Peng shrugs18:08
PengI usually use the SSL version (I'm weird), but I linked to the non-SSL version because it came up first in my browser history.18:09
Pengmaxb: ...The HTTPS version redirects to the HTTP version...18:10
maxbPeng: Not if your browser complains about the SSL certificate first.18:10
Pengmaxb: Well yeah. My point was, it seems HTTP is canonical.18:10
Peng(No pun intended. Although it was probably a bad choice of word anyway.)18:11
vilamaxb: but if you accept and makes a security exception *then* it redirects18:11
Pengmaxb: For whatever it's worth, editing the wiki sounds good to me.18:11
vilamaxb: it's probably a typo in the wiki as https makes no sense here18:12
Pengmaxb: Also, grepping my IRC logs, everybody (including core devs) uses http.18:13
maxbright. wiki amended.18:13
quicksilvermaxb: I think I'm going to solve it by a mixture of replay (when it's a plain revision) and careful manual merging to exact revids (when it's a merge)18:18
quicksilvermaxb: I only have 40-odd revisions to go through18:18
maxbThe only alternative I can think of would require some tweaks to the rebase sourcecode18:20
quicksilverit's quite painful when I have a major conflict though18:20
quicksilver(which was already resolved by the developer concerned"18:20
quicksilverI wish there was a way to say "give me the working tree state of this revid, without actually 'pull' ing it.18:21
quicksilverbecauase I"m courrnetly not seeing a simple way to 'get' his conflict resolution.18:21
quicksilvermaxb, vila: any clever suggestions?18:23
maxbI'd be tempted to avoid doing this manually at all costs18:24
maxbPerhaps trying to write some code using bzrlib if need be18:24
maxbI wonder if 'bzr rebase -r (revno after problem).. ../original-branch' would work out18:24
maxbUsing --include-merges, and my branch of bzr-rewrite (lp:~maxb/bzr-rewrite/rebase-merges-properly)18:25
quicksilvermaxb: with the working directory being the 'fixed' branch?18:25
quicksilvermaxb: I've not used python in anger ever (I've dabbled, and I can read it, but that's not he same as being comfortable enough to knock up a quick bzrlib script ;)18:26
vilaquicksilver: hmm, did you look at fastimport ? I'm not sure it has been implemented but I think their was talk about that scenario (excluding a file from history)18:26
quicksilvervila: I took a brief look and it seems to require writing an exporter to tweak the history.18:27
maxbCouldn't you just fast-export the revisions after the problem and fast-import them onto the fixed branch?18:27
quicksilvermaxb: well I'm on a train now so I'm not going to try downloading your launchpad now :)18:27
maxbquicksilver: If you have a branch of lp:bzr-rewrite, there's only about 6 more revisions in mine18:28
quicksilvermaxb: I don't. I'm using the 0.53 bzr-rebase from macports18:29
vilaI think bzr-rewrite is python only so you should be able to install it from source in your $HOME/.bazaar/plugins18:30
maxbIt's 539KB to branch, if you want18:30
vilamaxb: ^ ?18:30
maxbthe size of the branch, should quicksilver choose to download it18:31
vilamaxb: sry, my question was: is it python-only ?18:31
quicksilveroh, that is quite small, even over 3G.18:33
maxbYes, it's python-only18:33
maxbquicksilver: So, it would actually be more like: in a branch of the original branch: bzr rebase --always-rebase-merges -r (first revno to rebase).. ../the-fixed-branch18:39
quicksilverhow will bzr cope with having two plugins with same name? will the one in ~/.bazaar/plugins take priority over the globally installed one?18:39
quicksilvermaxb I think I've symlinked it in; is there an easy way to confirm I have your version?18:45
quicksilverah, bzr puglins -v18:45
quicksilvermaxb: bzr: ERROR: no such option: --include-merges18:54
quicksilverbzr oh, always-rebase-merges?18:54
quicksilvernot what you said the first time.18:54
quicksilverbut now I'm confused; you say to run it in a branch of the original?18:54
quicksilverI thought I was supposed to run it in the fixed one?18:54
quicksilvermaxb: whose numbering scheme should I use for the -r?18:56
maxbYou should run it in a fresh branch of the original18:56
quicksilverah. I'm getting trouble because the repo formats differ.18:57
quicksilverwhich is a bit of a problem because I was never able to "bzr upgrade" the original18:57
quicksilverthat was one of the symptoms of the bug.18:57
quicksilverhowever my new fixed one has been upgraded18:57
maxbrebase is a little weird. It basically does a pull --overwrite of the "other branch" and then re-adds rebased forms of some revisions of the branch you ran it in on top of that18:57
quicksilversince at one stage I thought that might fix the problems.18:57
quicksilvermy original branch is stuck in pack-0.9218:58
quicksilverso, I need to make a pack-0.92 version of the 'fixed' one18:58
quicksilverhow do I ask for a specific format?18:58
* quicksilver rebranches from a branch in old format.19:04
=== khmarbaise_ is now known as khmarbaise
=== khmarbaise_ is now known as khmarbaise
rubbsGot a friend here whose given me a problem I'm not sure how to best solve. He's looking to version a bunch of managerial documents, and only wants certain people to have access to it. I mentioned making them all wikis so they are versioned, but he said they need to be offline and some are spreedsheets. He was trying to tell me he wanted to use bzr, but I told him at best he'd have to separate all his managerial documents into a separate repo and20:06
rubbsHe keeps wanting a per-file authorization within bzr... I don't think that possible though20:06
rubbsMy other issue is that most of these docs will be binary... so versioning them is going to get big.20:07
luksbzr doesn't handle authorization at all20:07
rubbsI didn't think so... I also told him that due to the distributed nature once it was branched it's out of his control anyway20:07
beunorubbs, I think someone was working ona plugin for that20:08
beunonot sure where it got20:08
rubbsI tried to tell him that a CMS might be better, but he said that they didn't version attached files. (I havent vetted that claim yet)20:09
lukswell, he can use bzr to manage history of the documents20:09
luksbut then needs some layer to make them available to users20:10
=== salgado is now known as salgado-afk
rubbsI'm thinking of having bzr behind a CMS,20:11
rubbsso luks I think you got the best idea.20:11
luksI'm sure some existing CMS can make static documents available to users with per-file access20:13
luksI've never tried, but it doesn't seem as a rare problem20:13
rubbsyeah... I'm thinking he wants these users to have the ability to checkout old verstions too :( This is a hard one... I'm gonna keep diggin20:14
luksyeah, that would be more complicated20:15
rubbsyeah. I guess he's just brainstorming... so I don't know how crutial this is yet.20:16
quicksilvermaxb: bzr rebase -r... ../fixed-branch wants a revision number relative to the 'current' branch20:41
quicksilveri.e. the original branch20:42
quicksilveroh eys, that's what you said20:42
quicksilvermaxb: No revisions to rebase20:42
quicksilverit says.20:42
quicksilverOK, I have another approach.21:14
quicksilverI need to be able to accept a merge but reject all its changes21:15
quicksilverI'm sure I remember reading about that one day21:15
quicksilverah, bzr revert .21:15
quicksilverYES. I think this works.21:18
quicksilverno, it doesn't.21:18
quicksilverjelmer: was looking for you earlier. Trying to find a good way to rewrite history.21:19
quicksilverAh. Pebkac.21:24
quicksilvermy solution does work.21:24
quicksilverIt's a bit painful but it works.21:24
quicksilvervila, maxb, jam : I have a solution :)21:24
mkanatWhat's the best way to sync a bzr branch back to CVS?21:49
mkanatkiko: ping ^^^ (The above question is our primary hold up on actually switching now.)22:03
lifelessvila: http://junit.sourceforge.net/doc/faq/faq.htm#tests_722:06
vilalifeless: been there, seen that, not an *expected* failure only an test using assertRaises22:07
quicksilverok that's odd.22:07
MFenhow do i fix not compatible because "different rich-root support" during a merge?22:08
quicksilverwhy would a bzr merge explictly create 'OTHER' files?22:08
quicksilverinstead of a proper conflict?22:08
lifelessMFen: you have to upgrade22:08
quicksilverside effect is if I "bzr revert ." the file gets deleted.22:08
MFenlifeless: is it definitely me that has to upgrade and not the other person? i thought i was recent, but i'm not positive22:08
lifelessquicksilver: if the files are not textually mergable22:08
MFeni'm at 2.0.322:08
lifelessMFen: if you are merging, and get that error, then you need to upgrade the repository that your data is stored in to a rich root capable format - e.g. 2a, the default in the 2.0 releases22:09
MFenlifeless: i'm not sure whether that means the other guy's remote branch, my local branch, or even the remote trunk.  is there a way to inspect the version?22:10
lifelessbzr info22:10
lifelessvila: its the closest I've found so far22:10
quicksilverlifeless: I mean, it actually displays +N /path/to/file.OTHER when I merge22:10
lifelessquicksilver: then someone add file to the branch and you already have it in your branch22:10
lifelessthey haven't edited your file, they started over22:11
vilalifeless: yeah, me too :-/22:11
MFenlifeless: ok, bzr info -v on my local branch shows        control: Meta directory format 122:11
MFen (and some other versions of stuff too)22:11
quicksilverlifeless: ah right. another botched merge.22:11
lifelessMFen: whats the top line22:11
quicksilverdamn I need sleep.22:11
quicksilverwill come back to this tomorrow.22:11
MFenStandalone tree (format: unnamed)22:11
vilalifeless: but from there I got the feeling that I was chasing a ghost22:11
lifelessMFen: bleh :P22:11
lifelessMFen: whats the Repository line then22:11
MFen    repository: Packs containing knits without subtree support22:11
lifelessso your format can't do rich roots22:13
lifelesswhomever you are merging from can.22:13
lifelessthis is a one-way transition22:13
lifelessand it occurs by default in 2.022:13
MFenlifeless: ok. i don't know what to do. i'm at 2.0.3 so whatever was supposed to occur doesn't seem to have occurred22:14
lifelessMFen: run 'bzr upgrade'22:14
lifelessit will migrate your data22:14
MFenlifeless: you are an enlightened gentleman. thank you.22:15
lifelessMFen: np :P22:18
lifelessvila: xfail - try this: change the <failure> to <xfail> but keep the exception type and everything else22:24
pooliehi vila, lifeless22:28
lifelesshi poolie22:28
poolielifeless: of course you're welcome to use my screenshot22:29
pooliei hope it may do more stuff before your talk but no promises22:29
poolieif not, then i have a ~24 hour flight, that always seems good for hacking22:29
poolieassuming one gets a decent seat22:29
jamhi lifeless and poolie22:39
pooliehi jam22:40
jampoolie: so... the SilentUIFactory stuff strikes again22:40
lifelesshi jam22:40
jamrunning the 'unshelve --preview' stuff passes manually22:40
jamunless you redirect to a file22:40
jamthen 100 test fail22:40
pooliejam, oh, really?22:41
jamlifeless: did you see my message about testr?22:41
pooliedo you mean if the stdout of selftest is redirected?22:41
jampoolie: yeah, because ShelfUi now calls make_output_stream22:41
pooliethat's quite a bug22:41
pooliei was hoping to do that soon after finishing the mysql cross-format-fetch bug22:41
pooliejam, it seems like a separate bug if the code under test can even ever be influenced by redirection of the test output22:42
jamwell, without that, we would have hooked up the diff to write to stderr I think22:42
jamwell, stdout22:42
jamand just never generated the diff22:42
lifelessjam: found it22:42
jamof course, I just ran without redirect, and 14 tests fail...22:42
pooliei don't really understand, but did you send mail about this already?22:43
jamI'm not sure why the tests would have passed before22:43
jamI sent main to the review list22:43
jamthat I can't land it because tests fail22:43
jambut since I'm PP I figured I should try to debug it22:43
poolieok i'll look in a sec22:43
jamof course, it *also* fails because of a mismatched lock count, which makes the test results pretty hard to read22:44
dutchieI tried to "bzr mv chapter6.tex maintenance.tex" but it said "bzr: ERROR: Specified file "maintenance.tex" is outside the current view: chapter6/chapter6.tex". WTF is going on?22:44
jam(and I can't redirect to a file :)22:44
jamdutchie: you have a view specified22:44
jamwhich limits what files will be effected by commands22:44
jamso you don't commit/etc files outside of that22:44
dutchiehow do I un-specify it?22:44
jamI don't know *why* you have a view22:44
jambut check "bzr view"22:44
jambzr view --delete --all22:45
dutchieok, thanks22:45
jamor just22:45
jambzr view --delete22:45
jampoolie: so if I do this: http://paste.ubuntu.com/355766/22:48
jamthe test suite passes22:49
jambasically, it is just 'delay calling make_output_stream()' until we actually try to write the diff22:49
jamand since 99% of the tests don't, and the ones that do already set everything up correctly22:49
jamit works22:49
jamlifeless: oh, and 'testr failing' doesn't exist... :)22:50
spivGood morning.22:50
jampoolie: right, the failure is that the default ui is Silent which doesn't support make_output_stream22:50
jam(especially when redirected)22:50
jamthis avoids trying to grab an output stream at all22:50
jam(which is decent if it isn't going to be used)22:51
jampoolie: btw, I don't think 'make_output_stream' is particularly clear on who is supposed to close it.22:52
jammaybe I'm wrong22:52
lifelessjam: yeah,  I'll write that one this afternoon :P22:52
jamlifeless: so having a "testr load -v" would be nice22:52
jamif it could do the progress bar stuff22:52
pooliejam, so22:59
pooliewhich test is this?23:01
pooliejam, sorry, another call now23:01
poolieistm that setting that globally will just make the diffs go to selftest's stdout23:01
pooliewhich would be weird23:01
jampoolie: 'bzr selftest -s bt.test_shelf' with salgado's patch23:02
jamthe code as written23:02
jamalways calls make_output_stream in ShelfUI's constructor23:02
jameven if it never generates a diff23:02
poolieoh i see23:02
jamif a file isn't passed in23:02
jamso the tests that did care about the diff23:02
jampassed a file23:02
poolieand there are some tests that assume that if it isn't going to create a diff, they can use the default ui23:02
pooliei see23:02
jamand ones testing the behavior made sure the factory was available23:03
poolieok i see23:04
poolieso istm that if the tests want to install a Silent factory, it should probably discard output?23:04
pooliethat would be correct for these tests at least23:05
jampoolie: for code that existed before make_output_stream, I think we would have just written to stdout23:05
mkanatpoolie: Hey, do you know of any really good ways to mirror a bzr repo back to CVS after each commit to bzr?23:05
mkanatpoolie: That's the only thing we really need help with, right now, for Bugzilla.23:05
jammkanat: you could look at a "post_branch_tip_changed" hook23:06
mkanatjam: Yeah, I know what hook I'd use.23:06
jammkanat: then i would just have a co-located cvs repo and bzr repo23:06
mkanatjam: What I was hoping to find was some code that already does what I want.23:06
jamand the post-change hook would update & commit in a loop23:06
mkanatjam: That's not possible.23:06
jamnot possible?23:06
mkanatjam: Well, yeah, that's what I was thinking of doing, sort of.23:06
jamoh, there was also a plugin a while back that provided a cvs *view* of a bazaar repository23:06
mkanatjam: Yeah, but that won't work, for sure. :-)23:06
jamso you could "cvs co :pserver:/path/to/bzr23:07
jambut you couldn't commit to it23:07
mkanatjam: I know, I wish I could just use bzrcvsserve.23:07
jammkanat: trying to allow commits to cvs *and* bzr *and* have the bzr commits auto-mirrored back to cvs are going to be a real pain23:07
mkanatjam: There will be no commits to CVS.23:07
jammkanat: then what is wrong with cvsserve ?23:07
mkanatjam: The path to the CVS repo can't change.23:08
jammkanat: so cheat23:08
chxhi. bzr shelve and unshelve is very very cool but is there a way to specify my own id? would mesh with the ticketing system very well.23:11
mkanatBasically, I need to copy the bzr repo's contents into a CVS directory, do "cvs add" in a loop until there are no more ? outputs, then do "rm; cvs rm" for any files that don't exist in the bzr repo, and then properly mark and binary files, and then get the log message, and then commit to CVS.23:12
mkanatAnd I need to do it for one bzr commit at a time.23:12
chxhi. bzr shelve and unshelve is very very cool but is there a way to specify my own id? would mesh with the ticketing system very well. (sorryfor repea but it seems i asked in the middle of a netsplit)23:12
lifelesschx: no, there isn't.23:24
lifelesschx: I believe you can make a comment though, or description.23:25
lifelessor something like that23:25
chxyes but that's not something i can specify to bzr unshelve23:25
chxbut i guess i can write two handy lil shell scripts that fix this23:25
lifelesschx: you could improve unshelve so that you could say unshelve --description bug-4523:26
chxlifeless: that'd require me coding python :P23:26
chxlifeless: some other time :)23:27
lifelessits not contagious ;)23:27
chxno but i do not have the time23:27
chxlast i tried it was a breeze to code python23:27
chxso to quote Jeff Eaton, I am Py-curious :)23:27
=== pgalbraith is now known as CaptTofu
chxyeah, last i tried (it was the first serious try really) i whipped a two way gateway in 40 min between skype and konversation....23:37
chxmessages travelling on d-bus :)23:38

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