caravelgood evening, people. Is there any ftps plugin as yet ? (is this blueprint still actual ? https://blueprints.launchpad.net/bzr/+spec/tls-and-ssl-support)00:25
lifelesscaravel: we don't really work off of blueprints00:27
lifelesscaravel: I don't think ftps has been implemented, https is defintely supported - that blueprint is totally inaccurate.00:28
caravellifeless: fair enough - thanks for your answer - that's about all I found on the subject really, googled a few times already over the past weeks00:28
lifelesscaravel: we support sftp which is:00:29
lifeless - faster00:29
lifeless - simpler00:29
lifeless - more widespread than ftps00:29
lifelesscaravel: and we support https00:29
lifelessand bzr+ssh, which we recommend00:29
caravelbut unsupported by FileZilla Server -- which is extremely popular ;-)00:29
lifelessI suggest you file a bug00:30
lifelessthe core dev team work largely off bug backlogs00:31
lifelessrather than specs00:31
lifelesswe use spec when planning complex things with unpredictable interactions.00:31
caravellifeless: I guess it's not a wide requirement anyway -- fedora 13 here, could I bazaar over some ftps mount transparently ?00:33
caravel(just a thought)00:33
lifelesscaravel: you should be able to push/pull over an ftps fuse mount, yes.00:35
lifelesscaravel: performance will be less than ideal though - pushing and pulling is dealing with a database afterall00:35
caravellifeless: thanks - not looking for performance, rather trying to obtain from our web dev that he commits his code for himself, shares it, permit some backup... fuse should do, if bzr does't time out too fast ?00:37
caravelthere is no real infrastucture, so the idea would be to usie a (temporary) lenny server... as a bzr client to sync code from his FZ/win over fuse/ftps. Arrhmm, can this make sense ?00:40
AfC1I'd never heard of Filezilla before, but one of my clients yesterday had a problem with it's sftp implementation, whereas Nautilus's "connect to server" (via "SSH"/sftp) worked fine.00:44
=== AfC1 is now known as AfC
lifelessthe bane of my life00:46
lifeless[11630.844206] iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000.00:47
lifelesscaravel: anyway00:47
lifelessuhm, you can use any workstation - say yours - to run a bzr server on00:48
lifelessif you're doing network mounting, good ol smb will interoperate happily with windows00:48
lifelessI'm assuming your web dev is on windows00:48
mkanatlifeless: Ugh--what kind of wireless card do you have?00:50
lifeless6000 series00:51
mkanatlifeless: Hmm. I guess they're relatively new.00:51
lifelessmkanat: arrandale00:52
mkanatlifeless: Oh, yeah.00:53
lifelessmkanat: whats worse though00:53
lifelessmkanat: is that the kernel fails to reset some stuff when the microcode fails00:53
lifelessso you have to rmmod + modprobe00:53
lifelessfix is partly in maverick00:53
lifelessthe restart bug affects all iwl cards00:53
mkanatlifeless: That's really obnoxious. I've had a laptop that that happens on.00:54
lifelessbut you have to have a firmware issue too for it to actually annoy you00:54
mkanatI've had it happen where, randomly, I start up and the card doesn't work, also.00:54
caravellifeless: yes, he runs on windoz, there is no perpetual server online besides the production, hosted web server -- and some windoz machine at his place00:56
caravelbzr fits great with our needs because of its various topologies00:57
caraveleach is in a different part of the country, rather poor and unreliable bandwidth. soon we'll get a couple of servers, but for now00:58
caravelI found easily LftpFS but it's read-only... anyway, getting waaaay off topic. My concern here was how bzr would handle this type of link00:59
lifelesscaravel: as a push/pull target fine01:00
lifelessyou can't work on a fuse fs directly though because they don't support OS locks properly01:00
caravel"OS locks" what do you mean ?01:01
lifelessoperating system locks01:02
caravellifeless: ok I'm with you, but in my case, only one app will access the fuse link so it should not matter?01:02
caravelI'm cautious because while setting up passive and active ftp w(o encryption, I found bzr a bit "delicate" and quite far from the verbose mode.01:04
caravelopening a passive ftp to a badly (NAT & FZ ports) configured server, did hang bzr apparently01:05
caraveldisclaimer: was running bzr's windoz client01:09
caravelas soon as the server & router config were rectified, it rocked but I had a few timeouts (while other FTP clients have just no issues)01:12
spivlifeless: did you see https://bugs.launchpad.net/bugs/595473 ?01:25
ubot5Launchpad bug 595473 in Bazaar "paramiko not installed on PQM ? (affected: 1, heat: 6)" [Critical,Confirmed]01:25
caravelcan bazaar explorer / kde take advantage of kio (cf. kio-ftps) ?01:27
spivIt would be nice to find out the list of missing features PQM gets when doing 'bzr selftest'.01:27
spivcaravel: someone recently added a gio transport for bzr, I don't recall seeing the same for kio though.01:28
caravelspiv: thanks01:35
* caravel finds it real hard to google about such a popular VCS's feature01:36
spivpoolie: cute way to make simple graphs: http://webnumbr.com/bzr-in-progress-bugs01:51
pooliehi spiv01:57
pooliespiv oh wow that's brilliant01:57
spivpoolie: yeah, it's very nifty02:00
spivThe API is cute too.02:00
spiv(Although the AJAX on bugs.launchpad.net/foo makes it awkward to actually get at the interesting numbers, you have to use the +bugtarget-portlet-bugfilters-stats URL)02:01
pooliespiv, hi03:07
pooliespiv, i wonder if you can use +text?03:07
pooliebut i guess that would break it's xpath parsing03:07
pooliespiv, how could you have used read not recv if you tested it locally?03:08
pooliere bug 59547303:08
ubot5Launchpad bug 595473 in Bazaar "paramiko not installed on PQM ? (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/59547303:08
spivYeah, not sure.  With that URL I still got to point and click on a cute table ;)03:08
spivThat half of the if/else is only used via SFTP (when faking a paramiko Channel, which is socket-like, for use with paramiko's SFTPClient)03:09
spivSo, I tested the bzr+ssh with and without paramiko locally03:09
spivAnd trusted that the test suite would catch problems in SFTP if I broke that.  Which it did, except on PQM for some reason.03:10
spivI *guess* PQM is lacking paramiko... I wonder if it's lacking anything else.  It would be nice to see the list of selftest "features" it doesn't have.03:11
poolieonce subunit is working you should be able to get that out03:14
poolieof the list of skipped tests03:14
spivWell, in some ways the list of unavailable features is more useful.03:14
spivMaybe babune could provide a matrix of feature vs. builder....03:15
pooliei mean the skip messages should tell you which features they're missing03:15
pooliespiv, so in one place you used recv but in the other it was still read?03:15
spivOh, right, by implication.  Yes.  It's a bit harder to tell which out of hundreds of skips "should" skip.03:15
poolieperhaps we could use subunit tags or something03:16
lifelessthat reminds me03:16
lifelessspm: ping03:16
lifelessspm: in balleny, in the pqm bzr chroot, please do 'python2.4 -c import paramiko'03:16
lifelessI was wondering03:16
lifelesswould it be useful to attach the stdout and stderr to all responses03:16
lifelessnot just failures03:16
poolielifeless, i got stdout and err for a merge conflict failure03:16
lifelesspoolie: the group by stuff I'd like to do would collate the skips for you03:16
lifelesspoolie: was it ok ?03:16
poolielifeless, the stderr seems to have lost all its newlines03:17
poolieaside from that it's ok03:17
spivpoolie: not exactly.  I added a new path to handle the fact that SSHSubprocessConnection now might either have a socket or two pipes as its underlying connection03:17
spivpoolie: and this object provides a "recv" method so that it can be used with SFTPClient; in that recv implementation in the "if I have a socket" code path I typoed "self._sock.read" rather than .recv.03:18
spmlifeless: worked fine03:19
spivspm: huh!03:19
spm(pqm-amd64)pqm@balleny:~$ python2.4 -c "import paramiko"03:20
spmii  python-paramiko                              1.6.4-1.1                                    make SSH2 connections with python03:20
spivlifeless: do you have a recent subunit trace from PQM?  Does that show if that test is being skipped?03:21
lifelessspiv: what test.03:22
spivArgh, vila didn't put it in the bug.  /me scrolls back...03:23
spivlifeless: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh03:24
spivspm: does the chroot have openssh-client?03:24
spmspiv: nope03:24
spmI'm guessing that's a pls install? :-)03:25
lifelessneed an rt ?03:25
spivSo it would have fallen back to paramiko for SSH in that test, and thus not hit that code.03:25
spmlifeless: for the record, yes, but will get it installed in parallel03:25
lifelesswe should add that to the build-deps too, for the packaging, so that that test gets run.03:25
lifelessspiv: tag, you're it.03:25
spivlifeless: for the rt?03:25
lifelessYes, if thats ok :)03:25
spivlifeless: sure03:25
lifelessI've forwarded you the subunit trace btw03:26
poolieah so you interactively tested only bzr+ssh, which doesn't call SSHSubprocessConnection.recv?03:27
spivRight, because that's just for SFTP.03:28
poolieso it might be worth testing sftp interactively now?03:28
spivI was aware that I was changing code used by the SFTP client, but assumed the test suite would cover me...03:28
poolieto check it performs as expected, and to use lsof to check it's actually got a socketpair?03:28
pooliemm so the good thing is that it does, but not on pqm03:28
pooliegood on babune for catching it03:28
spmspiv: lifeless: installed03:29
spivspm: thanks!03:29
spiv(And by installing openssh-client on PQM, we're possibly shifting the coverage gap to the pure-paramiko codepath, although I think that's an inherently less risky one)03:29
pooliei guess we could add a specific test for recv that doesn't count on having sftp but that may not be worthwhile03:29
poolieideally the test suite would be such that adding dependencies only turns on new tests and doesn't remove any other coverage03:30
poolieie if we have an external test we'd run both with paramiko and external03:30
spivIt would be nice to fix that gap (per_ssh_vendor tests?), but doesn't feel like a very high priority to me.03:30
poolieat least for some representative fraction03:31
poolieprobably not03:31
pooliethings like this have happened before03:31
pooliemeaning variation based on testing with or without paramiko03:31
pooliebut it's probably not top of the stack03:31
spivReally, things worked pretty well in this instance: babune caught the bug quickly, and it got fixed very quickly.03:32
pooliethat was good03:32
spivObviously far from ideal, but defense in depth is good :)03:32
pooliei don't think this is a catastrophe03:32
pooliebut interesting to dig into03:33
poolie*in to03:33
spivspm: RT filed, #3994103:38
spmspiv: ta03:38
caravelthanks & good night03:56
lifelessjam: around at all? lazy object question for you04:20
jamlifeless: what's up?04:31
lifelessI was wondering if we had something that proxied after it loads04:38
lifelesseven though thats not the common case because of perf concerns04:38
lifelessfor formats that open disk resources it would be convenient04:38
lifelessjam: ^04:40
jamlifeless: ScopeReplacer._should_proxy04:41
jamlifeless: might not be fine grained enough yet04:42
lifelessso I mean04:42
lifeless'a lazy object proxy'04:42
lifelessyes, its too broad.04:42
lifelesshmm, I'm nearly done with a _LazyObjectGetter approach04:42
lifelessI'll see how it looks, gimme 2 minutes04:42
lifelessjam: http://pastebin.com/PHMrCSxk04:51
lifelessjam: I think this looks ok, simple to use.04:52
lifelessjam: what do you think04:52
lifelessjam: I'll propose it, you can assess later :)05:38
lifelessjam: to be clear, I don't care if you do/don't look at this in particular05:43
lifelessjam: I'm just closing up the conversation I started with you about the lazy import facilies aspect of it.05:44
mkanatHow do I make bzr forget that I added a file, in my current working tree?06:29
mkanatAhh, figured it out.06:30
lifelessmkanat: bzr revert file06:33
lifelessmkanat: or bzr rm --keep06:33
mkanatlifeless: Yeah, --keep --new was what I figured out.06:33
mkanat(It was a bunch of files in a directory, some of which needed to stay.)06:33
lifelessrevert tries very hard to be safe06:34
lifelesstakes  backups of stuff that isn't in a commit06:34
=== radoe_ is now known as radoe
vilahi all07:28
vilalifeless: hey ! Quick chat about looms ?07:38
vilalifeless: So, what do you have in mind about the merges in a loom (vague to not pre-suppose anything) ?07:40
lifelesschange up-thread to skip a thread if no conflicts occur07:41
lifelessand use the result (PreviewTree or whatever) of merging up to merge into the next thread, and so on.07:41
lifelesswhen a conflict happens, annotate to find the thread that causes the conflict, and:07:42
lifeless - if its trunk [thread 0], ignore all the other threads07:42
lifeless - otherwise  try the thread causing the conflict -> the thread we'd reach and if that works its conflicting due to the merge output07:43
lifeless - etc - working down a list to refine the conflict07:43
lifelessdo a merge of only the threads involved in the conflict07:43
lifelessso the number of merges will go way down, per thread07:44
lifelessthis will make merging a loom to a loom better07:44
lifeless because common case if you don't touch a thread explicitly, it won't change revid07:44
lifelessunlike today where it changes all over the place07:44
lifelessoh also07:45
lifelessdo all merges for 'does it conflict' detection in memory07:45
vilaHmm, I think I mostly got it but need to think a bit about it07:45
lifelessso we're insulated from pyc file staleness and the like07:45
vilaon a related subject: how do *you* undo up-thread ?07:49
lifelessrevert and or revert-loom and or uncommit07:50
vilawell, up-thread --auto <thread> (yeah --auto is automatic now, but)07:50
vilaha, revert-loom, missed that one. No uncommit-loom though07:53
vilapoolie, poolie, where are you ?07:54
vilalifeless: ok, food for thought on that subject, thanks. That looks promising as it addresses my main problem there (commits that "partly" look useless) but I need to draw some picture to better understand it.07:56
vilalifeless: about PQM, 2 things:08:00
vila1) Is news_merge configured now ? I suspect poolie couldn't land some patches because of that (and I had to merge locally a couple of mps too).08:01
vila2) I didn't get a failure email for submitting your broken branch (see my comment on the mp)08:02
lifelessnews_merge can't be configured on branches yet08:02
lifelessso 1) no08:02
lifelessnag spiv08:02
vilaoh, and 3) Do we plan to install update_copyright on pqm too ?08:02
lifeless2) see my comment in th e mp08:03
lifeless3) No plans that I know of, and I think it would be wrong anyway; pqm doesn't write code, coders do.08:03
vilahmm, good point about 3 but my workflow with loom suffers from that:08:04
vilasince I have the plugin installed, merging bzr.dev triggers such updates and merging  the threads up make the copyright update bubble up08:05
vilafor files I didn't touch myself08:05
spivupdate_copyright sounds a bit too eager.08:05
vilalifeless: well, I need another way to address that08:05
vilaspiv: Did you catch it proposing wrong updates ?08:05
vilaspiv: nagging: see lifeless remark above about configuring branches for news_merge (I don't get it though)08:06
spivI haven't used it myself.08:07
vilaspiv: then what do you mean by eager there ?08:07
spivvila: he means that it enabling news_merge ought to be something we can set in the branch, rather than setting in the PQM user's global conf08:07
spiv(Which especially makes sense if you consider that merging a branch that adds a NEWS entry generally should add it to the current release when merged by PQM)08:08
vilaha, yeah, inserting in the right release would be nice, but a useful first step will be to have it work for bzr.dev08:09
spivvila: triggering updates when you haven't changed the file sounds dubious to me08:09
spivvila: e.g. what if a file in bzr.dev was reverted to a 2009 version for some reason.08:09
spivSo, "eager" in the sense it will sometimes trigger when it shouldn't.08:10
lifelessits a bug in th eplugin08:10
lifelessvila: I suggest you fix the plugin08:10
lifelesscommit knows that a file showing in 'bzr st' can be unchanged against one parent08:10
vilaspiv: its history will still mention a change in 201008:10
lifelessso the plugin should never change copyright headers in that caase08:10
lifelessits breaking the per-file merge graph too08:10
vilameh, I fail to see what is breaked here, the copyright line is a line, its changes are recorded like any other line08:12
lifelessthe line should only change when the file has been changed by the user08:12
lifelessvila: per file merge graph convergence - you're familiar with it ?08:13
vilathe copyright changes converge, I can't imagine a conflict occuring there that can't be trivially resolved08:14
lifelessyou said08:14
lifeless19:05 < vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging  the threads up make the copyright update bubble up08:14
lifeless19:05 < vila> for files I didn't touch myself08:14
lifelessthat is the problem08:14
lifelessif I change a file08:14
lifelessand you bzr merge me08:14
vilaIt's arguably close to embed VCS data into a file which is a Bad Idea, but these lines are there for lawyers anyway08:14
lifelessand commit08:14
lifelessthen do per-file log of that file08:14
lifelessyour merge commit will not show up08:15
lifelessif your update copyright plugin makes the file get edited in that commit08:15
lifelesseven if you haven't changed it08:15
lifelessthen it will fail on branches merged in different years08:16
lifelesse.g. if I have a branch in december 201008:16
lifelessno changes in 2011 to a given file08:16
lifelessand you merge it in jan 201108:16
lifelessupdate copyright should not (and for the laywers, perhaps 'must not') change the file08:16
lifelessuntil you actually do something copyrightable to it08:16
lifelessif you had this fixed, I don't think you'd have made the complaint08:16
lifeless19:05 < vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging  the threads up make the copyright update bubble up08:17
lifeless19:05 < vila> for files I didn't touch myself08:17
spivIt would be interesting to setup a project that kept the copyright line and licence boilerplate on disk via a content filter, and left the canonical texts free of them.08:17
vilahmm, and changing the copyright line isn't copyrightable ? Quite possible08:17
lifelessvila: its not a created work, its mere data08:18
lifelessOh, I bet you could create a work consisting of opyright lines08:18
lifelessbut as we use it08:18
lifelessvila: anyway, I don't really care.08:18
lifelessvila: AFAICT fixing the bug I mention will fix the bug you mentioned.08:18
lifelessvila: and you asked for a fix.08:18
vilalifeless: I see your point, sounds reasonable is what I meant with my last remark08:19
vilai.e. the plugin should only trigger if *I* introduce a change in the left-hand parent only08:20
vilaand for the record, jam wrote the plugin, not me :)08:20
vilaDoesn't mean I can't fix it either ;)08:21
lifelessI think its intended to update if anyone changes the file08:21
lifelessbut it shouldn't detect an unedited merge as a change.08:21
vilayup, it should restrict to the changes introduced by the committer, so yes, too eager08:23
vilalifeless: regarding https://code.edge.launchpad.net/~vila/bzr/595587-fix-test-tariff/+merge/27859, you said: 'it would be nice to have just one list of such variables.' but what other list are you talking about ? And 'such variables' being 'variables that subprocess want to respect from the unless explicitly set otherwise (i.e. ignoring the resets in bt.TestCase._cleanEnvironment') ?08:27
lifelessvila: well its all tied together right08:28
lifelessthere are variables we want to reset08:28
lifelessthere are ones we want to affect the test suite (except for tests that know better)08:28
lifelessand so on08:28
lifelesswe seem to be adhocing it08:28
lifelessso that when someone does something new - like the tarif - it needs manual adjustmnet08:28
vilaso you'd like that list to come from a method close to bt.TestCase._cleanEnvironment and documented ?08:29
lifelessor attribute on bzrlib.tests08:29
lifelessor something08:29
vilayeah, or attribute, ok08:29
lifelessI'd just like to remove the duplication08:29
lifelessrather than N lists all slightly different08:30
lifelessI'd like Y canonical lists that express the intent08:30
vilaN ==2 so far right or did I missed one ?08:30
lifelessI think its much larger than that08:30
vilalifeless: ok, I'll try to look into that. No objection to make that in a different mp ?08:31
lifelessoh, I thought that was clear08:32
lifelessI just commented08:32
lifelessI wasn't expecting it to be done :)08:32
vilaI wanted to make sure I understood your intent :)08:33
vilaI agree that we lack documentation about the impact of env vars, that sounds like a godd plan to address that08:33
lifelesswhile you're here08:36
lifelessabentleys branch to do more cleanups of ui factories08:36
lifelessspiv: ^ vila; ^08:36
lifelessthat branch seems stalled; I'm happy to change it in the direction I proposed; noone else seems to really have an opinion08:37
lifelessI'd like one of you to express an opinion :)08:37
spivlifeless: Hmm, I don't have an opinion on that :)08:39
lifelessI'm happy to polish08:39
lifelessBut I don't want to make it worse ;)08:39
spivI'm not sure how much of an issue calling clean_up twice or before initialize is likely to be in practice.08:40
spivAnd other than a vague "yes it's nice to have less globals" feeling your suggestion doesn't feel significantly better or worse to me.08:41
lifelesswell I'll tweak and land then08:42
vilalifeless: I haven't looked deeply, but some holes in the implementation have been mentioned, I don't really care *how* they are addressed as long as they are.08:42
lifelessas a second reviewer08:42
spivBut I did have "Needs Fixing" vote that should be addressed ;)08:42
bialixheya bzr10:29
bialixvila: thanks for your help10:29
vilabialix: you're welcome10:29
pooliehi there bialix, vila10:32
bialixgood day poolie!10:32
bialixpoolie: can I start working on --path-encoding option for diff?10:33
vilahey poolie !10:33
bialixyour comment about true output encoding is puzzled me10:33
pooliebialix, so there's a couple of things basically10:41
pooliefirst, i don't understand when you would want the paths to be in a different encoding to other non-file-content output10:41
pooliesecond, i think i'd like to get to something about generally detecting whether we shoud use the terminal encoding or something else10:42
pooliebialix i didn't propose it for merge yet but https://code.edge.launchpad.net/~mbp/bzr/340394-encoding-option adds a general output_encoding option10:43
pooliemaybe i should just propose that10:43
pooliebialix, https://code.edge.launchpad.net/~mbp/bzr/340394-encoding-option/+merge/2791310:45
CaMasonHi guys. I have a trunk with lots of commits. Some of these commits were project releases11:09
CaMasonI'd like to have a 'release' branch. Would it be possible to merge in from certain revisions to create the release 'tag' in the release branch?11:09
CaMasonI assume it's a case of creating the branch from an early revision, and then merging with -r x..y ?11:10
bialixpoolie: sorry, I' afk for a while. bbl11:11
poolieCaMason, typically you'd just merge everything up to that point, ie -r x11:12
poolieor -r y11:12
pooliebut aside from that, yes11:12
poolieor if you wanted you could just tag them within that main branch11:13
poolieif you've not already done so11:13
CaMasonpoolie, yeah tagging was one option. We'd like to have a seperate release branch though11:22
pooliek, so then i'd suggest11:24
poolietag them in the trunk11:24
pooliethen merge across each tag and commit it11:24
poolieinto the release branch11:24
bialixpoolie: re: first, i don't understand when you would want the paths to be in a different encoding to other non-file-content output11:28
bialixpoolie: on Windows filenames should be in ANSI encoding to be compatible with GNU patch, while terminal encoding is OEM11:29
bialixso if I want to save diff in a file, I want it to use ANSI encoding11:29
pooliebut to me this is really the second point, that saving to a file needs a different encoding to the terminal11:30
poolienot that you want different encodings for the filenames vs the other content11:30
pooliethe case of UCS-2 is illuminating i think11:30
poolieyou would never want to mix ANSI and UCS-2 within the diff headres11:31
bialixfor me this is the first point, because windows is 2-encodings system11:33
pooliei have to go now11:33
bialixI don't understand your desire about UCS-2, but as discussion in my merge proposal reveals, this is exceptional case11:33
pooliei'll try to explain it on email later11:34
pooliegood night!11:34
bialixgood night and have a good weekend!11:34
vilapoolie: good night and good week-end !11:34
vilabialix:  :)11:34
bialixvila: :-)11:34
=== nlisgo_ is now known as nlisgo
marsilainenhi all13:30
marsilainenI don't understand the '--no-trees' option that you can use to 'bzr init-repo'13:31
marsilainenI'm not sure when to use --trees and when to use --no-trees... so I guess I don't understand what a 'working tree' is?13:31
asabilmarsilainen, working tree is the tree of files that you are using bzr on13:37
marsilainenok, so when would I want --no-trees?13:37
asabil--no-trees is generally used in servers hosting bzr repos/branches where you don't want to waste disk space13:38
marsilainenright, but don't they need the tree of files in order to serve them?13:38
asabilin which case bzr will just create the .bzr folders13:38
asabilmarsilainen, nope, because when you do a bzr branch it just needs the .bzr folder13:39
marsilainenso in the .bzr folders, are contained all the checked-in revisions of the files anyway?13:39
asabilyes, and they are efficiently compressed/packed there13:39
marsilainenso if I'm serving the files up, it doesn't really matter whether I specify --trees or --no-trees I guess?13:40
marsilainenI think I understand now anyway, thanks13:40
asabilmarsilainen, serving the files or the bzr branch ?13:41
marsilainenthe bzr branch I guess13:43
marsilainenso that people can get it with 'bzr branch http://myserver/bzr/blah'13:43
asabilit's better if you use --no-trees I guess13:47
asabiland maybe setup loggerhead there13:47
marsilainenis there any bzr gui which can work on a branch held remotely?14:08
maxbmarsilainen: The other thing to bear in mind is that trees/no-trees on a *repository* is a *default* that is applied to *new branches* being created within that repository14:08
marsilainenmaxb: ok, sure, thanks14:09
maxbmarsilainen: Define 'work on a branch' ? What kinds of work do you want to do?14:09
marsilainenI want to be able to do things like gui diff between revisions as well as commits etc14:10
marsilainenwhen doing web development it makes sense to have the working trees on the web server machine (ie. remote) so that I can test changes before commit etc14:10
maxbIt is impossible to commit without a working tree existing somewhere14:11
marsilainenyes, I understand that14:11
marsilainenthis is a different question to my one earlier about --trees etc14:11
maxbI don't *think* that it's possible to commit remotely - i.e. you need the bzr client doing the commit to be running on the machine where the tree is14:11
marsilainenI suppose I could mount my working tree from the remote machine onto my local machine14:12
marsilainenand then use it like that?14:12
marsilainenso then I could use olive or whatever locally14:12
maxbThat should work, though if the network connection is not particularly fast or low-latency, it might be more practical to commit locally and push/pull changes14:13
marsilainenit's hard to do that when you're doing active web dev though14:14
marsilainenbecause you make a small change and want to see what effect that has14:15
marsilainencommiting each time would be a major pain14:15
CaMasonI need to revert some changes of a file, but keep others. Is there a way I can do some sort of interactive merge with the HEAD on a single file?14:32
maxbCaMason: The only thing I can think of is to do the merge, and then use shelve to interactively remove some of the changes14:56
CaMasonmaxb, I used shelve :)14:56
sven_sandbergvila, hi!15:07
vilasven_sandberg: hey ! How did it end up ?15:07
sven_sandbergvila, i eventually ^C-ed the bzr pull15:08
vilain the shared repo ?15:08
sven_sandbergvila, then i ran bzr pack manually. surprisingly, this took only 34 minutes15:08
sven_sandbergvila, yes15:08
sven_sandbergvila, then i ran bzr pull, and it was fast15:08
sven_sandbergvila, then i ran bzr pack again, and it took 34 minutes again15:08
vilahmm, sounds like the repack succeeded earlier then no ?15:09
sven_sandbergvila, this was a lot faster than when i did 'bzr pull' and it implicitly called bzr pack15:09
vilahow many pack files do you have now ?15:10
sven_sandbergvila, now i have 815:10
vilaand more importantly *when* did they get created ?15:10
sven_sandbergvila, 7 around 3 MB, and on 358 MB15:10
sven_sandbergvila, the 7 small ones were created quite soon after i started bzr pack yesterday. the big one was created when i ran 'bzr pack' after having ^C-ed 'bzr pull'15:11
vilaho, chances are only the big one is referenced then15:12
vilajam: What's the magical formula to look at the pack-names content ?15:12
sven_sandbergvila, what does that mean? the others are temp files that can be removed?15:12
vilajam: sorry, first of all: heello !15:13
jamvila: bzr dump-btree [--raw] .bzr/repository/pack-names15:13
jamhi vli15:13
jamhi vila15:13
vilasven_sandberg: try the above command and !paste the result15:13
ubot5For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.15:13
vilasven_sandberg: I meant, please, what with my manners today....15:13
jamsven_sandberg: please include --raw15:14
jam bzr dump-btree --raw .bzr/repository/pack-names15:14
jam(*I* prefer the raw form)15:14
sven_sandbergvila, :-)15:14
sven_sandbergvila, http://paste.ubuntu.com/451622/15:14
vila. o 0 (Come on jam, that's bits not meat)15:15
jamsven_sandberg: so the other 7 files are not referenced, as Vila suspected15:15
jamvila: without raw it converts it to tuples, etc.15:15
jamwhich, personally, puts too many () in the output :)15:15
vilajam: hehe, try lisp :)15:16
jamsven_sandberg: yeah, I'm aware of that, having tried to hack on gnucash some time ago15:16
jamanyway, the extra files...15:16
jamI believe it is probably from doing ^C during an autopack15:16
jamit leaves the newly fetched content there, not yet referenced.15:16
sven_sandbergjam, so should i remove those files?15:17
jamsven_sandberg: you are *allowed* to, I don't think they'll hurt anything15:17
jamif you do, you can remove the same-named files from .bzr/repository/indices15:17
jamnow... as to why it took so long to do it as an autopack vs a 'bzr pack'15:17
jamthe only thing I can think of off-hand is something like peak memory consumption / memory fragmentation15:18
jamit is doing the same operation15:18
jambut it is possible the fetch still was holding on to some memory15:18
jamhmm... I suppose it is also possible that an 'optimize' flag was set incorrectly... but I doubt it would account for hours vs .5hour15:19
sven_sandbergjam, ok, so it's not doing something wildly different just because the repository was in a slightly different state?15:19
jamsven_sandberg: shouldn't be15:21
jamif anything, it should be doing *more* work for 'bzr pack' because it always looks at all files15:21
jamit is a bit of a shame we couldn't have poked the old one a bit harder to see why it was taking so long15:21
vilaA NotApplicable test failing...15:41
jamvila: well remember, any given test can have multiple outcomes if the addX gets called.15:42
jam(cleanups particularly tend to cause errors after success/skip)15:42
vilainvestigating but TestNotApplicable is raised during setUp and the failure is during the test itself...15:43
=== Adys_ is now known as Adys
=== beuno is now known as beuno-lunch
mgzneed to do something about my growing shelf here...17:36
mgztime for some 'needs to be in initial branch or not' triage17:37
=== beuno-lunch is now known as beuno
chxis there a way to 'sneak peak' into a shelve, ie extract the diff of a shelve?19:43
vilachx: bzr unshelve --preview n19:57
lifelessmgz: hi21:06
=== oubiwann is now known as away
=== away is now known as oubiwann
mgzlifeless: hey22:05
lifelessso, your branch ?22:06
mgzdone watching poor football, back to that22:06
mgzI'll push where I am then enumerate the remaining shelves22:06
mgzit's all edge-of-edge cases now, so some of these probably don't need resolving right now22:07
mgzokay, 5: use cp* rather than mbcs... might commit this, though it's not reliably testable22:08
mgz4: use Python 3 style namespace-including exception names. can wait.22:09
mgz3: let BaseExceptions propogate when stringifying errors... can wait I think, as doesn't fix it for Python 322:10
mgz2: a test for another stringifying thing not addressed for Python 3, don't need it.22:11
mgz1: first crack at a per-line regexp matcher. can probably wait as well.22:11
mgzonly other thing to do is module renaming, which I was saving for last.22:12
lifelessI'm keen to land stuff22:14
lifelessso if you need feedback on anything, let me know22:14
mgzokay, I'll do the moving now and resubmit rather than fiddling more22:14
lifelessif you think you'll want to undo anything you've done22:20
lifelessthen polish it more22:20
lifelessbut I get the sense you just want to add more, not change your mind on approach22:20
mgzyeah, I've been trying to keep all this as private functions for the moment, so it's at least possible to rearrange some of the specifics later22:24
lifelessworks for me22:24
mgzokay, done, tests pass on four implementations22:30
lifelessI'm *really* happy you've done this work22:32
mgzhm, resubmit didn't do what I thought it was going to22:35
james_wmgz: what are you working on?22:35
mgzjust yellowed the existing comments22:35
mgzjames_w: making the tracebacks Python 2 produces correctly encodable to UTF-8 by testtools22:36
james_woh, coo22:36
mgzit's sort of a back port of the Python 3 traceback/string behaviour22:36
james_wlifeless: are you looking for testtools to be a repository of matchers as well as the basic functionality?22:37
lifelessjames_w: I'm happy for matches to go there22:37
lifelessjames_w: I'm also happy for someone to start and run a dedicated matcher project, which could own the base class22:37
james_wok, I might start submitting them22:37
lifelessthere is such a thing in java, its a shame that their python port was so unpythonic22:37
james_wI think AND and NOT would be useful, though I can appreciate that they have their problems.22:39
james_wbut I've written a couple of generally applicable ones that I could submit22:39
lifelessuntil someone gets the activation energy up to run a dedicated project22:40
lifelesswhich I think would be good btw22:40
lifelesstesttools is happy to be a home22:40
mgzI'd sort-of like testtools to grow them rather than splinter it off as a new thing22:40
lifelessmatching can be very useful outside tests22:44
lifelessif someone was passionate about using them in - say - a generic object diff facility in IDEA22:45
lifelessor whatever22:45
lifelessI'd be happy to say 'here, enjoy'22:45
lifelesswhile noone is passionate and driving them as a specific thing, I think testtools devs caring for them is great22:45
mgzokay, review is in your inbox lifeless.22:52
mgzand, as always, scanning the diff I just spot a sentence with the meaning reversed22:53
mgzPython 3 StringIO does *not* expect bytes22:53
lifelessseen the recent email thread on p-d ?22:53
mgzyeah, I was reading that and thinking of you.22:54
davidstrausslifeless: If you have a minute, I've run into a very funny merge tracking issue: http://pastie.org/private/vtc9hydx3iyn6nhft7ehiq23:21
lifelessdavidstrauss: wow that is fun23:22
davidstrausslifeless: how is missing able to know what's common but not merge?23:23
lifelessI would guess that you have merged in something with an ambiguous base23:23
lifelessso that bzr is recursing back23:23
lifelessand you've managed to find a failure mode for that23:23
davidstrausslifeless: In any case, "Branches have no common ancestor" is false.23:23
lifelessthis is worth a bug; you can manually merge with -r 2397.. to work around23:23
fullermdSeems to me I've seen that before...23:24
lifelessdavidstrauss: right, but that no common ancestor really means 'didn't find an *acceptable* common ancestor'23:24
fullermdbug 48338823:24
ubot5Launchpad bug 483388 in Bazaar "merge lies about lacking common ancestors when it has multiple choices (affected: 2, heat: 4)" [Medium,Confirmed] https://launchpad.net/bugs/48338823:24

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