lifelessfullermd: there is one particular vicious bug, which abentley suggested a great fix for00:00
lifelessbut noone has executed it00:00
fullermdI take exception to commands doing totally different things.  Special cases are bad.00:00
lifelessfullermd: I agree with you00:00
fullermdEspecially when every other VCS has an 'update' command that goes between a WT and its Branch (or whatever equivalent that VCS has)00:01
lifelessfullermd: well, git doesn't, hg doesn't do wt <-> branch (it does something different again), svn and cvs's updates are behaviourally identical to bzr's00:02
lifeless(modulo the 'check out new files' aspect.00:02
fullermdWell, git re-abuses 'checkout' for that.00:03
fullermdAnd hg's update DOES update the WT to something based on the branch.00:03
fullermdAnyway.  I totally don't have the time or the energy for the whole co/bb discussion.00:04
lifelessit changes the working copy to  a revision00:04
lifelessfullermd: ok00:04
lifelessfullermd: I want to get to the bottom of it some day00:04
fullermdsven_oostenbrink: Are you going to be around for a while yet?00:04
lifelessI think we should fix the polish bugs we have first00:04
fullermdOh, totally.  I wouldn't keep grumping about it if I didn't want to get it dealt with eventually   :)00:05
fullermdI certainly agree that some of the behaviors (like that two-merge-update) are flat-out bugs, and need to be fixed irregardless of other issues.00:05
=== davidstrauss_ is now known as davidstrauss
fullermdsven_oostenbrink: I have some discussions of 'mainline' I can put together and post up, but it's 18:00 and I reallyseriouslydesperately wanna go have lunch.  So it'll be a while.00:07
lifelessmwhudson: so at this point you forward your confirmation mail to plans@tripit.com and magic happens00:07
phoenixzfullermd: another thing.. since this is a DVCS.. if I want to have a backup of my work, I only need to have a copy of the .bzr directory, right?00:08
fullermdphoenixz: Yeah.  Though realize that every branch (or at least, every shared repo) is a 'backup' too.  We commonly back up branches via 'push'   ;)00:09
fullermdphoenixz: See above about mainline.00:09
dashphoenixz: to emphasize this fact, note that pushing to a remote branch does not create or modify the remote branch's working tree. :)00:10
phoenixzgottit, get some food, don't want you to starve to death, who else will help me out here? :)00:10
fullermdSomebody else, who won't get into an argument with lifeless in the middle of it?   8-}00:11
phoenixzdash: yeah, I was basically talking about branches with WT that would not contain changes..00:11
fullermdphoenixz: BTW, you say that AboutUsingRepositories link as well, yse?00:17
phoenixzfullermd: yeah, saw it, will give it a read in a moment00:17
Peng_jam: I might not have recompiled all of the extensions before the "merge" error. I'll see if I can reproduce it.01:36
Peng_jam: Ehh, I'll follow up in an email.01:38
Peng_jam: Short answer: I can't reproduce the errors. Looks like I did forget to recompile.01:44
lifelessjames_w: around?01:47
jfroy|workjelmer: is there a way to push to a local (e.g. file) svn repository with bzr-svn?01:48
jfroy|workis seems there's no way to separate the branch name / path from the repository URL / path01:48
wgrantjfroy|work: WFM with file:// URLs.01:51
wgrantWorks for me.01:51
wgrantAnd it also seems to work with just a normal absolue path.01:51
jfroy|workwell yeah, if you want to push to another bazaar branch01:52
jfroy|workI'm trying to push from bzr to a local svn repositoru01:52
wgrantHow does it complain when you try? It works fine for me.01:53
jfroy|worknot a branch or directory already exists01:54
wgrantThat's from 'bzr push /path/to/repo/path/to/subpath'?01:54
jfroy|workdpush fails, push works01:54
jfroy|work(I was trying to use dpush)01:54
jfroy|workOk, that's a new one01:55
jfroy|workbzr: ERROR: [Errno 24] Transaction cleanup failed01:55
wgrantNew to me also.01:56
mwhudsonlifeless: i wonder if tripit is going to understand the air nz itinerary in pdf i just mailed it...02:03
lifelesspossibly :P02:05
mwhudsonhm, it seems like it did, but now i can't find it online02:05
mwhudsonah, just took a while02:06
jfroy|workso I just don't see how to use dpush02:06
jfroy|work(I really don't want the metadata)02:07
lifelessjfroy|work: file a bug :)02:07
jfroy|workit won't create the branch if it doesn't exists, and when it does, its error message stating I should pass --overwrite ends in failure because it doesn't have an overwrite option!02:07
lifelessmwhudson: indeed, it did better than for me; it thinks I stay in chch :P02:08
lifelessI guess I should tell them somehow02:08
lifelesswhich is odd vause their detailed view is right02:08
mwhudsonit even coped with the hotel confirmation02:10
mwhudsonlifeless: i think they might be using memcache or something a bit much02:10
mwhudsontaking the "eventually consistent" to extremes02:10
lifelessmwhudson: we have longer lag than you saw, I think02:13
jfroy|workwell, having more luck pushing to a svnserve-ed repository02:15
igcmaxb: re storing git refs in bzr nicks, I'd like to explore the idea. Storing the value exactly probably isn't the best choice but having a deterministic mapping is a great idea02:23
lifelessigc: do you mean the object sha, or the human reflog name?02:27
igclifeless: human name02:27
Peng_Either something odd has happened, or lp:~jameinel/bzr/2.1-static-tuple-chk-map has really helped Loggerhead's memory usage.03:04
* igc food03:07
* fullermd wouldn't rule out 'both', just on GP :p03:07
jfroy|workso I don't understand fast-export :|03:08
jfroy|workno matter what bzr branch I export, it always seems to re-import it as trunk03:08
jfroy|workahhh, 0b03:15
jfroy|workdo I need to re-export marks (whatever those are) if I have more than 2 branches to export and import?03:19
jfroy|workor do I need --export-marks only for the first export-import, and only need to use --import-marks for all subsequent export-imports?03:20
mwhudsonspiv, lifeless: so i think the smart server doesn't handle unicode paths very well03:39
lifelessmwhudson: backtraces, details, please.03:40
mwhudsonlifeless: run bzr serve --allow-write somewhere03:41
mwhudsonbzr push bzr://localhost/b%C3%A903:41
mwhudson--> http://pastebin.ubuntu.com/299462/03:42
mwhudsonon the server side, Transport.__init__ is seeing a 'base' of filtered-41598608:///b\xc3\xa9/03:46
lifelessyup thats wrong03:46
mwhudsoni think sftp has different bugs like this :(03:47
mwhudsonis there some way i can see what's going over the wire easily?03:49
mwhudsonhuh nosmart+bzr:// works finer03:51
fullermdphoenixz: http://bazaar-vcs.org/MatthewFuller/AboutMainline04:00
mwhudsonthe path is sent across the wire unescaped04:07
mwhudsonhttp://pastebin.ubuntu.com/299476/ fixes things, maybe04:10
Peng_This "pretend the screen is 65,536 columns wide" thing is causing problems. :\04:10
Peng_Including test failures. :D04:11
spivmwhudson: hmm04:12
Peng_(And yes I'll file bugs, once I verify that that's what's responsible.)04:12
spivmwhudson: seems plausible I guess04:13
lifelessmwhudson: in fact u1 have rolled back to paste, spawning was too much fail :)04:13
spivmwhudson: I wonder about paths sent in responses, but one problem at a time...04:13
lifelessPeng_: ubuntuone04:13
mwhudsonlifeless: ugh04:16
mwhudsonlifeless: oh well, my business with other things saved me some pain there i guess04:16
mwhudsonspiv: uh yes i guess so04:18
Peng_How should environment variables be handled in tests? If you change one, will it be automagically fixed when the test ends?04:18
mwhudsonspiv: which smart verbs respond with paths?04:18
mwhudsonPeng_: there is certainly some support in testcase for that04:19
lifelessPeng_: many common ones are automatically saved and restored04:19
Peng_"common ones"?04:19
lifelessplugins path, email, HOME, editor etc04:20
lifelesssee bzrlib.tests04:20
Peng_They're fixed after every test? So it's okay to mess with them?04:23
lifelessthe set that are isolated, yes04:24
lifelessthose that aren't, you should call the isolation helper on first04:24
arjenAUahoy my beloved bzr magicians04:25
arjenAUi come to you in search of enlightenment.04:25
arjenAUlifeless: stay put you, i'm a happy user!04:25
lifelessI was doing pirate04:25
arjenAUI need something akin to a hardlink in a branch04:25
* fullermd is a couple doves short of a sixpack.04:25
lifelessin the ahoy theme04:25
arjenAUoh righty04:25
arjenAUlifeless: ideas?04:26
arjenAUso I need a file in 2 or 3 directories, and keep 'em in sync. no risk of divergence. a straight link would do it, if bzr can grok that.04:27
lifelessarjenAU: bzr can version symlinks04:27
arjenAUok so I'd have a main and secondary... that would do. just not hardlinks? and I presume the symlinks break on windows or did you use the magic API to use it on NTFS?04:28
arjenAUi don't need win, just curious ;-)  NTFS supports symlinks but win doesn't use 'em04:28
lifelesswe degrade on windows04:29
lifelessthere is a plugin04:29
lifelessto do something more than we do04:29
arjenAUlifeless: no worries. ok so symlinks. ok out of the box or do I need to set anything to make this jive?04:29
lifelessln -s foo bar04:29
lifelessbzr add04:29
arjenAUsounds sane as usual. ok04:29
arjenAUthen, can I get conflicts on a bzr pull if I didn't have any local changes that weren't pushed?04:30
lifelesssorry, rephrase that wont04:30
lifelessI don't understand the question :)04:30
arjenAUI do a bzr pull and I get conflicts, even though I have no local divergence afaik04:30
lifelessyou may have local changes04:31
lifelesssuch as files that are ignored in a subdirectory04:31
arjenAUnot on those files.04:31
lifelessor uncommitted edits to a file04:31
arjenAUi've seen this a few times ove rlast week or so. using 2.004:31
arjenAUwell jaunty ppa04:31
arjenAUit's honestly files I have not touched.04:32
lifelesscould you, for a while, do 'bzr st; bzr pull'04:32
lifelessand when it happens file a bug with the output of those two commands - the order matters ;)04:32
spivmwhudson: lots of them04:32
arjenAUlifeless: rigthy. can I nicely back out of the current state totry that again. revert?04:32
jamlifeless: I don't remember it happening for files, but if you delete a directory, then you can get a conflict if there are temp files lying around04:32
jamPeng_: I would like to think 'static-tuple-chk-map' helps mem, but I wouldn't have expected it to effect loggerhead04:33
lifelessjam: yes, thats why I mentoned ignored iles in subdirs04:33
Peng_jam: Hi. :)04:33
lifelessarjenAU: no, because we don't have the exact state any more04:33
jamlifeless: I'm currently trying to get meliae to perform 'compute_referrers' on a 500MB dump file w/ 5.6M objects.04:34
spivmwhudson: list_dir obviously, but also I think various opening verbs can e.g. BzrDir.find_repositoryV3 and Branch.get_config_file and probably several others.04:34
jamThe problem is that a dict holding 5.6M entries is 200MB by itself...04:34
Peng_jam: Well, Loggerhead does read data that comes through bzrlib.chk_map.04:34
jamPeng_: for iter_changes?04:35
arjenAUlifeless: ehm. so to get rid of the mess, I did bzr revert then bzr clean-treeto be sure I didn't have build leftovers. then bzr pull says no rvisions to pull.... so it's just the local checkout that's the issue now, right? what command? or did I go foul somewhere04:35
Peng_jam: No clue. I know it hits iter_ancestry, but I forget how.04:35
lifelessarjenAU: well, thats the thing, we don't have the state that caused the conflicts04:36
lifelessarjenAU: so we need to wait for it to happen again04:36
lifelessarjenAU: thus my asking you to do 'bzr st; bzr pull' from here on in, to capture more detail when it happens again.04:36
mwhudsonspiv: list_dir agrees on the encoding with that via a local transport fwiw04:36
jamarjenAU: so if you get conflicts, 'bzr revert' should restore you to the pristine state, however, as lifeless says, determining what got you there in the first place would be useful04:37
arjenAUyes I get that, but I don't understand the situation I now have in my tree.04:37
mwhudson>>> get_transport('bzr://localhost').list_dir('.') == get_transport('/home/mwh/tmp').list_dir('.')04:37
spivThat's good.04:38
Peng_jam: Loggerhead caches a copy of the revision graph. . .04:38
jammwhudson: yeah, I would use list_dir() as a guideline for how paths should be encoded04:38
jamPeng_: revision graph comes from the indices04:38
jamI thought it also cached the per-revision deltas04:39
mwhudsonyeah, it does04:39
jamand that could certainly come from chk_map04:39
mwhudsonthough not in ram very much i think04:39
arjenAUjam: if you need graph magic, look at http://openquery.com/blog latest entry, you may find useful.04:39
spivmwhudson: oh, and of course the various error responses that contain paths04:39
spivmwhudson: e.g FileExists04:40
Peng_jam: FYI, I just ran "bzr selftest" on bzr.dev + 2.1-static-tuple-chk-map + statictuple-pickling, and there were no failures (related to ST, anyway)04:41
mwhudsonnow get_transport('bzr://localhost').mkdir('b%C3%A9bbb') creates a directory with the escaped path :(04:43
spivmwhudson: :(04:43
spivmwhudson: so clients today are sometimes sending utf-8 bytes and sometimes sending urlutils.escape'd?04:46
mwhudsonspiv: it seems that way04:47
mwhudsonspiv: at a guess bzrlib.remote and bzrlib.transport.remote are different04:47
spivmwhudson: is it varying by verb only?04:47
mwhudsonspiv: not sure04:48
mwhudsonspiv: actually04:48
spivIf it's just a difference between VFS verbs and not, that's not too bad04:48
mwhudsonspiv: what do you mean by that question? :)04:48
spivI mean, for every verb X, do clients consistently send paths a particular way?04:49
mwhudsonspiv: i don't think there are cases where the same verb is called with varying levels of escaped-ness04:49
igclifeless, jam: any hints on where I should look to solve bug 441125?04:49
ubottuLaunchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/44112504:49
mwhudsonspiv: right, yes, afaik04:49
spivThat's what I'd expect (and hope)04:49
lifelessigc: isn't it a dupe?04:49
spivIf so, that's not insurmountable.04:49
igclifeless: not sure. It's well beyond my knowledge area04:50
spivEspecially if the split is exactly VfsRequest/everything-else04:50
spivmwhudson: so bzrlib.remote calls something that seems to intentionally unquote the url before transmission04:51
mwhudsonspiv: if you say so, i've become a bit lost among the various objects & methods04:52
jamlifeless: so if I understand the exception, it is triggering because an inventory is referring to a file key  (file_id, revision) which is *not* present in the repository04:52
jamsorry igc^^04:52
jamwhich is certainly bad-mojo04:53
jamis this a stacked branch?04:53
igcjam: yes04:53
lifelessspiv was fixing a bug like this yesterday04:53
lifelessor so04:53
jamand does reconcile fail on the base?04:53
igcjam: reconcile on the trunk works ok04:53
spivmwhudson: specifically RemoteBzrDir._path_for_remote_call invokes _SmartClient.remote_path_from_transport invokes the medium's remote_path_from_transport04:53
igcjam: it's only on the stacked branch it fails04:53
spivmwhudson: both implementions of that make a urlutil.relative_url and urlutils.unquote it.04:54
igcjam: branching from there gives a branch on which reconcile works04:54
jamigc: so one possibility is to probe through all of the inventories to find one that references this text key04:54
igcjam: can comparing the log -v -p on the orginal branch and the created branch gives the same results04:54
jamit is certainly possible that this inventory is 'unreferenced'04:54
spivmwhudson: where bzrlib.transport.remote uses RemoteTransport._remote_path which appears to rely on whatever Transport._combine_paths does04:55
jam(or, not in the ancestry)04:55
mwhudsonspiv: ah right04:55
jam_text_refs is built up by walking *all* chk pages, IIRC04:55
jamnot  just chaining from revisions => inventories => chk_pages04:55
mwhudsonspiv: so a cheap hack would be to have VfsRequest override translate_client_path to unescape again?04:56
jamhold on... maybe not. Maybe only ones that are referenced via an inventory04:56
spivlifeless, jam, igc: The bug lifeless is thinking of that I fixed is bug 437626, I think04:56
ubottuLaunchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix committed] https://launchpad.net/bugs/43762604:56
jamit looks like unreferenced ones are just streamed out directly, without being parsed.04:56
mwhudsonspiv: https://code.edge.launchpad.net/~mwhudson/bzr/escape-smart-server-requested-paths fwiw04:57
spivlifeless, jam, igc: which didn't affect 2a repos, if that helps04:57
igcspiv: thanks04:57
jamhowever, that doesn't mean we have the *revision* for that inventory04:57
igc(it does)04:57
lifelessjam: unrefed ones shouldn't be copied though04:57
lifelessjam: except for the adjacent ones, and those we don't want the texts for04:57
spivmwhudson: I think so04:58
igcjam, lifeless: so does that imply reconcile is looking at extra data it doesn't need to?04:58
spivmwhudson: or not apply your escaping04:59
spivmwhudson: whatever works is fine by me, though :)04:59
lifelessigc: possibly yes04:59
mwhudsonspiv: is it sane to have vfs requests have different rules than the others?04:59
spivmwhudson: we'll need tests, obviously, and I should add some text about this to network-protocol.txt04:59
jamigc: it is possible to have inventories in the repository that aren't referenced by the branch. it is further possible for those to be borked.05:00
spivmwhudson: well, they already do AIUI?05:00
jamhence why I suggested you walk all inventories and find out which one thinks it knows something about the given file_key05:00
mwhudsonspiv: i guess05:00
mwhudsonfixing it would require defining a whole new tranche of verbs05:00
spivmwhudson: the long term plan is to remove the vfs requests anyway, so if there's cruft that's restricted to just them I'm fairly comfortable with that05:01
jamfor inv in b.repository.iter_inventories([k[0] for k in b.repository.inventories.keys()]):05:01
spivmwhudson: and as far as cruft goes this is pretty minor, happily.05:01
jam  if file_key in inv:05:01
mwhudsonspiv: true enough05:01
jam    print inv.revision_id05:01
mwhudsonspiv: where are the vfs verbs tested?05:03
mwhudsonjust in the generic transport tests applied to RemoteTransport?05:05
spivmwhudson: mainly those, yeah05:05
spivmwhudson: there's also a little bit SmartServerRequestHandlerTests in test_smart_transport05:05
spivmwhudson: most of the newer verbs are more rigorously tested in test_smart05:06
mwhudsonspiv: i guess an appropriate test for this is to have a RemoteTransport onto a directory, mkdir('%C3%A9'), and then check list_dir via a LocalTransport matches?05:10
mwhudsonspiv: can i get you to write that? :-)05:11
igcjam: thanks for the code snippet. That saved me ages I'm sure ...05:13
igcjam: I get 202 matches on that file-id and the rev-id is one of them05:14
igci.e. rev-id failing in the KeyError exception05:14
igcjam: make that 280 matches sorry05:14
spivmwhudson: I suppose so, although it's not my ideal way to spend a Friday afternoon ;)05:14
* mwhudson is all confused again :(05:15
spivmwhudson: but yes, that sounds like a good test to have05:15
spivmwhudson: oh, except I'd back it onto a MemoryTransport :)05:15
mwhudsonspiv: https://bugs.edge.launchpad.net/bzr/+bug/45876205:47
ubottuLaunchpad bug 458762 in bzr "smart client inconsistent about escaping of paths to the surprise of the smart server" [Undecided,New]05:47
mwhudsonspiv: can i assign that to you?05:47
spivmwhudson: no05:48
spivmwhudson: because I just did :)05:48
mwhudsonspiv: ok :)05:48
spivmwhudson: thankks05:48
mwhudsonspiv: np05:49
mwhudsonspiv: i'm glad the problem turned out to be fairly simple in the end05:49
=== AfC1 is now known as AfC
jkakarlifeless: I've written a command to upgrade Bazaar branches on Launchpad.  I'm not sure it's working.  Do the formats here make sense: http://pastebin.ubuntu.com/299569/07:01
lifelessjkakar: lp has a bug where it doesn't update the reported format07:05
lifelessjkakar: bzr info nosmart+<url>07:05
jkakarlifeless: Ah ha, I was wondering about that.07:05
jkakarlifeless: Woot: http://pastebin.ubuntu.com/299574/07:07
lifelessits been upgraded :)07:07
jkakarIt's probably a good time to make the first release of AutoLP.07:08
lifelessautolp ?07:08
jkakarI want a place to collect Launchpad commands.  I already have several scattered about.07:08
lifelessand there is another one as well that the lp folk made07:08
lifeless(that meaning rockstar/jml/abentley I think, though I'm hazy)07:09
jkakarI didn't know about lptools, will check it out, thanks.07:09
lifelessit has a review-notifier which is nifty07:09
lifelesson my TODO to package it07:09
wgrantMight want to add lptools to the lpx project group.07:09
lifelesssurely launchpad ?07:09
wgrantA new officially-sanctioned project group for launchpadlib-using applications.07:10
jkakarLaunchpad Extensions, similar to the tx project group for Twisted.07:10
lifelessseems totally weird to me to not use the launchpad group07:10
wgrantThey are not part of LP.07:10
wgrantTo they should not be part of LP.07:11
lifelessyou're repeatin yourself but not making a case07:11
wgrantThey are not part of LP in the real world, so why should they be part of LP on LP?07:11
lifelessthe launchpad project group isn't just launchpad.net07:11
jkakarI like having a way to separate "Launchpad the moving parts of the service" from "The set of tools that work with Launchpad".07:12
lifelessit needs to be shrunk if thats what its meant to be an exact match for07:12
lifelessjkakar: I can see that07:12
lifelessproject tags FTW07:12
jkakarYeah. :)07:12
wgrantRight. lpx is brand new, and things haven't been sorted out yet.07:12
* lifeless sighs over data models07:13
lifelessso limiting07:13
igclifeless: the reconcile problem seems to come down to parent_map(text_refs) not finding all parents07:13
igclifeless: so maybe we aren't collecting things correctly for a stacked branch?07:14
lifelessigc: reconcile runs in unstacked mode07:14
lifelessigc: because it has to enforce 'this repo is internally consistent'07:14
igcgroupcompress_repo.py, line 128907:14
igctext_refs has 5024 items07:15
lifelessigc: do you perhaps mean 'reconcile is not fully up to date with the setup of stacked repositories'07:15
igcparent_map returns a dict with 4875 keys07:15
igcI may mean that, still fumbling my way through07:16
lifelessI'm done for the day btw07:16
lifelessshould have been, oh, 3 hours back. But I'm bad at 8 hour days07:16
igclifeless: sorry. not great timing I know07:16
igclifeless: I'll update the bug report and look more on Monday07:17
lifelesswin 3207:18
vilahi all07:21
vilalifeless: win 32... 2000 ? XP ? Vista ? :-P07:21
igchi vila07:25
lifelesswgrant: its a shame that bzr, and various things with lp support won't ever be able to be in lpx :P07:30
wgrantlifeless: This is why we need project tags.07:35
bialixoh! my favorite subject: project tags07:35
* bialix looks at irclogs07:36
lifelesswgrant: I know :)07:36
lifelesshi vila07:36
igclifeless: I'm seeing *much* better memory usage having dropped the cache size down to 1 by default, along with the latest bzr trunk with jam's improvements07:53
igclifeless: you may want to retry a netbeans import when you get a chance07:54
lifelessigc: I'll teach you the cache mantra eventually ;)07:54
igcit helped at the time :-)07:54
igcbut I'm really pleased it's mostly not needed now07:55
lifelesshows the performance?07:55
lifelessgc costs a lot :)07:55
igcwell, better or medium to large projects07:55
igcit's slower on smaller projects but not by a big amount07:56
spivigc: nice07:56
igcspiv: well, turning off a cache is simple - jam and you guys did the hard yards making the core fast enough that it wasn't helpful!07:57
igcspiv: but thanks :-)07:57
* igc dinner08:18
lifelessvila: forward your trip booking mail to plans@tripit.com, should create an itinery :)08:21
vilalifeless: yup, I'm trying to sort out the email used first, but thanks for the t[r]ip :)08:21
vilalifeless: next time, treat me as spiv but with a '+' instead of '-' !08:22
loxs_wrkwhat do I need to do in order to revert some file to the state from the previous revision08:25
lifelessvila: I wasn't sure if they were magic oryou had to configure it08:26
lifelessloxs_wrk: bzr revert -r -2 FILE08:27
vilalifeless: '+' is the "standard" magic char, spiv cheats :-P08:27
vilabah, I can't find the merge accounts anymore, will just delete the othr08:28
vilabug 353370 upsets babune a lot, do you I need to submit a proposal to revert revnos 4766 and 4764 or can I just go ahead  ?08:54
ubottuLaunchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,In progress] https://launchpad.net/bugs/35337008:54
lifelessjames_w: you has bugs11:13
james_wlifeless: you has responses to bugs11:13
lifelessjames_w: also a merge request on -builder; would love to have a todo-to-merge for it for Monday11:13
lifelessjames_w: thanks11:13
lifelessjames_w: did you only just comment? I don't see bugmail..11:15
james_wabout an hour ago11:15
james_wfor "needs -sa" I said "eh?"11:16
james_wbzr-builder currently builds native packages to sidestep tarball issues11:16
james_wso you shouldn't have an issue11:16
james_wfor "invalid email address" I said that I couldn't see how it happened given the code11:17
james_wthough I didn't look that closely11:17
james_wknowing what $DEBEMAIL $DEBFULLNAME $MAIL $NAME $EMAIL were in your environment11:18
lifelessdch -a gets something more 'sane' (though still not great)11:19
james_wthis uses a port of dch's algorithm, so it should give the same behaviour11:19
james_wI can believe that we made a mistake in porting though11:19
lifelessI saw, it doesn't.11:19
lifeless$ echo a $DEBEMAIL b $DEBFULLNAME c $MAIL d $NAME e $EMAIL11:19
lifelessa b c /var/mail/bobthebuilder d e11:19
james_w$MAIL looks wrong to me11:19
james_wor not11:20
james_wI wonder where Javier got MAIL from, dch doesn't seem to use it11:21
lifelesslooks fine to me11:21
lifelessits the maildir for the user11:21
lifelessI can't imagine it ever being useful for email address detection11:21
lifelessbzr has a pretty complete heuristic itself, built in11:22
james_wyeah, I wanted the same as dch though11:22
james_wI thought that would be less surprising11:22
lifelessso the mail thing was a distraction11:22
james_wusing bzr stuff as a fallback before the "guess based on socket.fqdn" though11:22
lifelesstook me a bit of time to realise that it wasn't lp api's giving me grief :)11:23
lifelessthe merge proposal is more interesting to me than the bug now [as I has workaround]11:23
lifelessits lightly tested as there doesn't seem to be any test support for lp apis11:25
lifeless[and cody gave me a chunk of the code in one hit]11:25
james_wyeah, I'm reviewing that now11:25
james_wlifeless: if you could respond to the other bug I would appreciate it11:27
* james_w doesn't like incomplete bugs11:27
lifelessjames_w: I thought I replied to both11:28
lifelessyeah, I did11:30
lifelessjust bugmail slowness11:30
lifelessreally, smtp==www, should be instant :)11:30
james_wlifeless: review done11:48
james_wthanks for working on this11:49
bialixbzr guru I have a question about bzrdir.sprout12:02
bialixBug 45891412:03
ubottuLaunchpad bug 458914 in bzr-scmproj "pget clone all revisions from shared repository instead of revisions belong to .scmproj branch" [High,Confirmed] https://launchpad.net/bugs/45891412:03
bialixI have following code in scmproj to clone control branch12:03
bialixthis code using sprout12:04
bialixas result it does not filter out unrelated revisions when cloning branch12:04
bialixbut get entire shared repo12:05
bialixwhat I'm doing wrong?12:05
vilabialix: why don't you use branch.fetch() instead ? And why does your comment talks about creating a working tree for force_new_repo ?12:10
bialixI dunno, that code was written by amanica12:10
bialixI don't understand how sprout works12:10
bialixthat code invoked this way: http://pastebin.com/d41766d3d12:11
bialixare you asking about comment after force_new_repo=True ?12:12
bialixvila: ^12:12
bialixthe idea was is to create standalone branch always, regardless of presence of shared repo12:13
vilabialix: especially when sprout has a _create_tree_if_local parameter...12:13
bialix_create_tree has leading underscore, therefore it's private API12:13
bialixlast time you was very hard that gary using private api in qbzr12:14
vilameh, no underscore, sorry typo12:14
bialixthat code was written last winter, perhaps bzrlib evolved since then12:14
vilarhaa, I wasn't hard at all ! You misunderstood my intent, but nm12:15
vilabialix: you may want to use the revision_id parameter too12:16
vila        if revision_id is not None, then the clone operation may tune12:16
vila            itself to download less data.12:16
vilabialix: your caller certainly can get that from br_from.last_revision_info12:18
bialixvila: hmmm12:22
bialixvila: so I need to change my clone fuinction?12:25
vilaI'd say so...12:26
bialixso I need to make function as     def _clone_to_local_url(br_from, revisions_id, to_url, accelerator_tree=None):12:28
bialixvila: ^, right?12:28
bialixand pass revision_id to sprout?12:29
vilarevision_id, no 's' , but yes, I'd try that12:29
=== mrevell is now known as mrevell-lunch
vilabialix: do you have any evidence that this bug is recent or was it always there but unnoticed ?12:29
bialixmy coworker just today discovered this12:31
bialixI think it was there always12:31
bialixbut he has non-standard scmproj project clone12:32
bialix.scmproj should be standalone tree, we forcing this12:32
bialixbut he made by hands this branch using shared repo12:32
bialixso it's not very critical but I'd like to fix it12:32
* bialix trying what vila suggested12:34
vilaPeng: ping !12:34
bialixPing: peng12:34
vilaPeng: just noticed bug #458743 and bug #45874112:35
ubottuLaunchpad bug 458743 in bzr "terminal_width fix causes progress bar hideousness when piped to "less"" [Undecided,New] https://launchpad.net/bugs/45874312:35
ubottuLaunchpad bug 458741 in bzr "terminal_width fix causes test failures with subunit" [Undecided,New] https://launchpad.net/bugs/45874112:35
vilaPeng: I've been bitten by the problem in another way and I just proposed lp:~vila/bzr/353370-notty-no-term-width12:36
vilaPeng: your feedback will be highly welcome12:36
vilaPeng: oh, and more info at bug #35337012:36
ubottuLaunchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,Fix committed] https://launchpad.net/bugs/35337012:36
bialixvila: branch.py suggests that I can obtain rev_id tip by br_from.last_revision() call. ok?12:38
vilabialix: yup12:38
=== weigon__ is now known as weigon
bialixvila: many many thanks12:42
bialixit working12:42
vilabialix: \o/12:43
bialixall hail vila!12:43
* bialix mutters: that's new ajax lp made me crazy12:46
Peng_vila: AIUI (skimming things) your patch drops the no-TTY width from 65,536 to 256. My terminal is ~130 columns wide, so it should still get spammed, just a lot less.12:48
Peng_vila: Is that correct?12:48
vilaPeng: not only, it changes the way is obtained in more cases12:48
vilaPeng: not only, it changes the way the width is obtained in more cases12:48
vilaPeng: can you try it ?12:49
vilaerr, which Peng are you ? Peng or Peng_ ? :)12:49
Peng_Oh look, I have $COLUMNS. 183? Didn't remember it was that high.12:50
Peng_vila: Both.12:50
Pengvila: ...And neither!12:50
vilaRight, so if you set COLUMNS, it's obeyed. Period.12:51
Peng_OK, both of my computers have $COLUMNS. If it works, I don't really care about the details. :P12:51
Peng_vila: I'll grab a copy of your branch.12:52
vilaok, I'll grab some food then :-)12:52
* SamB_XP still wishes bzr paid attention to SIGWINCH12:52
vilaSamB_XP: patches welcome !12:54
SamB_XPheck, I'm not even sure I made sure there was a bug about it!12:54
vilaSamB_XP: see.... :-D12:55
bialixvila: thanks again, you my hero12:56
Peng_That brings it to 4 branches I have merged to my bzr.dev. :D12:57
Peng_vila: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one.13:00
Peng_vila: when piped to less, anyway13:02
Peng_vila: This is an improvement, obviously, but it's still worse than the old code.13:02
vilaPeng: with or without COLUMN being set ?13:04
Peng_vila: with13:06
vilaPeng: and is the value coherent with your terminal ?13:06
vilai.e. <=13:06
Peng_vila: Yes.13:09
vilaPeng: you said earlier that COLUMNS was set to 183 and your terminal ~130, right ?13:10
vilaanyway, try to either *not* set COLUMNS or set it to a value that is *less* than your terminal width13:11
vilaPeng: regarding #458741, can you tell me how to reproduce that ?13:12
Peng_vila: I just sent an email. All I did was "bzr selftest --parallel subprocess".13:13
Peng_vila: Well, to be exact I did "bzr selftest --parallel subprocess pending".13:14
* Peng_ runs off to watch TV. I'll check in at ad breaks, though.13:14
vilaok, I can reproduce now, that's fixed with my patch13:15
Peng_Ohh, why is there always an ad break right when I get up?13:15
vilaPeng: at your next break, can you precisely tell me what width your terminal is, what COLUMNS value you use and if you still experience a problem13:15
Peng_vila: 183, 183, and which problem? The selftest one? I'll check.13:15
vilathe selftest one is fixed, just checkd it13:16
Peng_vila: Yeah, I can confirm it.13:16
Peng_vila: Which problem do you want me to check?13:17
vilaYou said: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one.13:17
vilaI can't reproduce that13:18
Peng_vila: Oh. ...Show's back.13:18
Peng_vila: Anyway, that's with latest-everything, including your branch. And 3 others, but they shouldn't break this.13:18
vilaghaaa, I want a recipe to reproduce !!! :D13:19
vilaha, got it, if COLUMNS >> terminal_width I can see that, but if I use COLUMNS==terminal_width it's not the case, please double check13:19
vilaand if COLUMNS >> terminal_width, well, it's kind of expected, if the terminal issue a linefeed, there is no way bzr can uses carriage returns to erase the current line (since it has become the previous line...)13:21
=== mrevell-lunch is now known as mrevell
vilahmm, so, to be pedantically precise, the bug occurs if you set COLUMNS=terminal_width+2, so there probably is a off-by-one error somewhere13:23
vilaPeng: but it also very probably means COLUMNS is not set the way you think it is :)13:23
Peng_vila: $COLUMNS is right.13:30
Peng_vila: Also, like I said, it only happens when I pipe to less.13:30
Peng_vila: ....Now I can't reproduce it.13:30
vilaPeng: haaaaa, I prefer that :-) THanks !13:31
Peng_vila: Sorry, I was wrong. I can reproduce it.13:31
Peng_vila: It works fine if I do "COLUMNS=183 bzr pull -v | less -F", but fails if I just do "bzr pull -v | less -F". Even though $COLUMNS is 183 anyway.13:32
Peng_Sorry. :P13:32
vilaenv | grep COLUMNS13:34
vilavila:~/src/bzr/releases/2.0 :( $ echo $COLUMNS13:34
vilaPeng: Can you try COLUMNS=18213:35
Peng_vila: "export COLUMNS=182; bzr pull -v | less -F" works.13:35
vilaPeng: amazing isn't it ?13:35
vilaso it's *another* off-by-one error somewhere else13:36
Peng_vila: Bu I told you, 183 works. Sometimes.13:36
Peng_vila: "export COLUMNS=183; bzr pull -v | less -F" works too. Augh!13:37
Peng_vila: Ah-ha! "echo $COLUMNS" works, but "env" doesn't list COLUMNS.13:39
vilaseems related to 'shopt -s checkwinsize' in my .bashrc13:39
Peng_vila: $TERMCAP does include the columns, though.13:39
Peng_Although I only have $TERMCAP inside of screen, but that's mostly where I run bzr anyway, so it's not a big deal.13:40
vilaPeng: I'm pretty sure we are chasing a different bug here...13:43
Peng_vila: I dunno. What are we talking about?13:45
vilaoff-by-one errors bewtween terminal width and COLUMNS13:46
vilabefore my patch COLUMNS wasn't obeyed, so you didn't see these bugs13:46
Peng_So, um, hmm. Since it turns out I don't actually have $COLUMNS ("echo" lies), where does that put me?13:50
Peng_It's using the default of 156?13:50
vilaecho doesn't lie, try 'shopt' and search for checkwinsize13:51
vilaif you do echo $COLUMNS and get something, so does bzr13:51
Peng_vila: echo really does lie. $COLUMNS is not listed in "env", or Python's os.environ.14:00
Peng_...I hate computers. :P14:00
* vila kills some more chickens14:02
nyulifeless: thanks!14:19
=== weigon_ is now known as weigon
phoenixzfullermd: Good morning!15:13
phoenixzfullermd: Just finished reading the other document you wrote15:13
phoenixzfullermd: I have to say, still not sure on how the init-repo thing works, though it seems cool..15:22
dleeTrying to use Bzr against an svn repo at http://opensource.adobe.com/svn/opensource/flex/sdk:  flex/sdk is the path in it, and it's from there laid out in "trunk" layout.  Read-only access requires no password, and this works with svn; but bzr insists on asking for one.15:57
dleeI gather that this is because bzr tries to determine layout by examining the root, but I must not have read access that far up.  Is there a solution to this?15:58
jelmerdlee: specify the layout manually15:58
dleeI've tried messing with ~/.bazaar/subversion.conf but it didn't help.  I may not have done that correctly.15:58
jelmerand disa ble the cache15:59
dleeCan I use bzr co/branch or do I need bzr svn-import?15:59
dleeThe latter has a layout parameter; the former two don't I think15:59
jelmeryou can set the layout in subversion.conf16:00
jelmere.g. layout = trunk016:01
dleeThe 0 is new to me :) tried without.16:01
jelmerit shouldn't be necessray16:02
dleeMy subversion.conf is just the [uid] line, layout=trunk (with or without 0), and locations = http://opensource.adobe.com/svn/opensource16:03
jelmerdlee: you'll also need to disable the cache16:05
jelmerdlee: 'use-cache = False'16:05
dleein subversion.conf?16:06
jelmeryeah, in the uuid section16:06
dleeHmm...still wants a user name.16:07
dleetried co and svn-import, trying to check out both trunk and just flex/sdk16:07
jelmercan you send it ia sigquit and see what code path is tryuoing to access the repo root16:07
jelmer(apologies for my spelling today)16:07
dleeIn the debugger, but I haven't been here before... what do you want from here?16:09
cellofellowI need to install bzr on a Mac that I don't have admin rights too. Is there some way I can do that?16:10
Peng_cellofellow: Worst case, run from source.16:10
jelmerdlee: 'bt' will print a backtrace16:11
Peng_cellofellow: You've tried the installer, and it failed without admin rights? http://bazaar-vcs.org/MacOSXDownloads16:12
cellofellowPeng_: it asked for them but I didn't just click cancel and see what happened.16:15
cellofellowif I click cancel it doesn't continue to the install16:15
cellofellowsource it is I guess16:17
dleeTrying to sift out what matters... should I be suspicious at seeing "self._cached_revnum = self.transport.get_latest_revnum()"?16:17
cellofellowor just don't use it, I can commit from my laptop.16:17
dleeLooks like it happens when bzr tries to get the latest revnum.  Iirc, pasting large text chunks isn't appreciated in here, or I could paste some of the backtrace.16:20
Peng_dlee: Use a pastebin.16:24
james_wis there a way to do a backwards merge?16:27
james_wuse case:16:27
james_wshared trunk with disconnected workflow16:28
james_wif there is a collision in pushing to the trunk then I get told the branches have diverged16:28
james_wif I merge trunk then it changes the left hand history of trunk16:28
james_wthe "correct" way to do it is to get another copy of trunk, update it, and then merge in16:29
james_wbut that's a faf16:29
james_wif I could do "bzr merge", but just put the revision parents the other way around then I could do it in one directory couldn't I?16:29
james_wTak: there's no need to rebase, and in fact I don't want to16:30
dleePeng_ / Jelmer: I made a pastebin - never done that before either.16:31
Peng_dlee: What's the URL?16:32
jelmerdlee: looks like we try to open the repository root at the moment when we try to figure out the last revision number16:35
jelmerdlee: that's not really necessary, please file a bug16:35
jelmersorry, gtg - breakfast16:36
dleenp and thanks16:36
phoenixzI have varios SVN repositories containing various implementations of one and the same inhouse developed framework. Simplified, I have repo A with the framework itself, as trunk, branches and tags, from there copied (using SVK), in repo B project B1, B2 and B3, and I have repo C with projects C1 and C2... When making updates to the framework while working in repo C, project 1, I merge those changes back to the framework in Repo A. When I have updates to the16:41
phoenixz framework in repo A, I merge those changes to all projects in repos B and C.. I want to change from SVN / SVK to BZR. How can I import all these works from SVN / SVK to BRZ, keeping all the histories but also keeping the abilities to merge in between the various projects?16:41
phoenixzI know, SVN cannot copy cross-repository, but SVK can. Which is one of the reasons why I used SVK in the first place. Now, SVK is pretty much a dead project, and I want to jump ship, BZR seems like the perfect choice for me, but I would not want to loose the ability to merge in between projects..16:45
jelmerphoenixz: hi16:47
phoenixzjelmer: hi16:47
jelmerphoenixz: yes, if I understand your situation correctl bzr-svn should be able to handle that16:48
jelmerphoenixz: please note that you shouldn't be using the 'bzr dpush' command when attempting something like this16:48
phoenixzjelmer: I don't even know what dpush is or does, yet.. :)16:49
jelmerphoenixz: in that case, don't worry about it :-)16:49
jelmerphoenixz: dpush is the bzr-svn equivalent of "push but don't set svk:merge"16:49
phoenixzjelmer: haven't found dpush in bzr help commands..16:49
phoenixzjelmer: a question here..16:50
phoenixzso in subversion, I have varios projects16:50
phoenixzeach project has a trunk, development branches and tags16:51
phoenixzpretty common way to work in SVN16:51
phoenixzI use this framework within different companies16:51
phoenixzfor each company I have multiple projects that use that framework16:51
phoenixzfor each company I have one SVN repository that contains the projects16:52
phoenixzlike, /svn/companya/projecta/ (where companya is an SVN repo)16:52
phoenixzHow do I set this up in BZR?16:52
phoenixzBecause AFAIK, BZR has each branch being its own thing16:53
phoenixzthere is a shared repo directory16:53
phoenixzwhere I can keep those branches together16:53
phoenixzso I figure, for each company, I would make a shared repository16:53
phoenixzand in there I would place directories for each project16:54
phoenixzand in those project directories, I would place the branches for each project16:54
phoenixzjelmer: does this make sense in BZR? or did I get it totally wrong?16:54
dleeJelmer: Re: getting svn latest revno querying at repo root unnecessarily:  Bug #459187 filed.16:55
ubottuLaunchpad bug 459187 in bzr "Unnecessary request for userID/password on bzr co/branch/svn-import from svn repo" [Undecided,New] https://launchpad.net/bugs/45918716:55
MethsCan bzr import from CVS?16:56
Methsnm, found bzr-cvsps-import16:58
jelmerdlee: Thanks17:01
jelmerMeths: you may also want to check out cvs2svn's fastexport option17:01
jelmerphoenixz: yeah, that should work17:01
jelmerphoenixz: I would recommend sticking to the standard layout for svn inside of those branch container directories17:02
jelmerphoenixz: because bzr-svn will automatically regonize what is a branch in that case17:02
phoenixzjelmer: another question.. Does BZR know if different branches are related? I suppose it does, but if I make a branch of a branch of a branch, etc etc.. will the last branch still know its related to the first one17:03
phoenixzI know, noob questions.. :)17:03
jamMeths: or use 'cvs2bzr' from the 'cvs2svn' suite. Which will create a 'fast-import' stream, that you can import using 'bzr fast-import'.17:03
jelmerphoenixz: yes, it will know if different branches are related17:04
phoenixzjelmer: is it also possible to branch a sub directories? like, I have a project A with sub directory lib.. I want a branch of only lib, is that possible too?17:04
jelmerphoenixz: partial checkouts are possible but the related history with the partent branch will not be recognized17:06
Methsjelmer: jam: thanks.  How does bzr fast-import work?  bzr help fast-import isn't implemented17:10
jelmerMeths: you need the bzr-fastimport plugin17:10
jelmerphoenixz: I'm out for the day. If you have more questions, please mail the list and cc me17:11
vilamorning jam !17:11
phoenixzjelmer: thanks lots for the help so far!17:11
vilajam: I could spend a better week-end if I could land https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/1383217:12
jamhey vila17:12
jamI'm technically on vacation again today17:12
jamthough I found a way to shrink mem by another ~50MB or so, so I can't stay away :)17:12
vilajam: ach, sorry again, but hey you're here again :)17:12
jamI'm not sure about trusting COLUMNS when isatty() is false17:13
Takjelmer: btw, I figured out what the issue was with bzr-svn/subvertpy/md-bzr17:13
vilajam: well, the more I dig, the more I see COLUMN being set even when you don't touch it :-)17:13
jamcertainly under 'less' you probably don't want to truncate17:13
jameven though Peng does17:13
vilaJust try it in a terminal...17:13
jamvila: I'm pretty sure the terminal likes to set COLUMN / COLUMNS or whatever17:13
jamas a hint17:14
vilabash too17:14
jamvila: well bash has to get it from the terminal, rigth?17:14
TakI wasn't invoking PyEval_InitThreads17:14
jamor perhaps it uses SIGWINCH, or TIO or whatever17:14
vilaI dunno, surely they talk to each other, but that makes it even more reliable17:14
jamvila: right, and my point is if I do "bzr XXX > file"17:15
jamshould it be paying attention to that?17:15
jamalso note that for our purposes17:15
jamsys.stderr.isatty is probably more relevant17:15
jamI don't think we ever truncate stdout17:15
jamvila: can you verify that last statement?17:15
vilalet's not open more cans than necessary....17:15
vilalog --line is one know truncate case17:16
jam(stdout being valuable information that the command is generating, versus 'progress' etc information that can be truncated on a whim)17:16
jamvila: so my direct preference is "revert the 'bugfix"17:16
jammy second preference is "just set it to 256"17:16
jammy third is 'lets have a discussion and actually get this right"17:17
vilasetting to 256 when using a tty is bad, I know that for sure17:17
vilaok, so I'll revert the offending revnos and wait more feeedback on the patch17:17
Peng_jam & vila: <317:18
jamvila: but isatty() is False17:18
jamOr am I missing something17:18
vilajam: ECONTEXT17:18
jam(11:16:57 AM) vila: setting to 256 when using a tty is bad, I know that for sure17:19
jamYou are setting it to 256 when "isatty()" is returning false17:19
jamhence "using a tty" but the system is telling us you aren't17:20
vilaI was replying to: <my second preference is "just set it to 256">17:20
jamvila: I'm saying "set it to 256 when isatty() is False"17:20
jamI should have typed it all out, I guess17:20
vilaha ok, yes, that's what the patch does17:20
jamI was trying to say "change 65536 => 256"17:20
jamvila: and a bunch of other stuff17:20
jamMy point is there is a one line 65536 => 256 change17:21
jamthat seems to cover what you really need17:21
vilahaaaa, I started with that, but them I realized there was other problems and that wasn't enough17:21
vilaso, it's either, revert or fix them all17:22
vilawell, for some values of all...17:22
jamvila: which is my point about (3)17:23
jamif we are going to spend significant time on it, lets do it the right way17:23
jam(and i feel stuff like checking sys.stderr is part of that, possibly handling SIGWINCH, possibly a few things)17:23
vilajam: ok, I thought I did that but by all means, let's discuss it widely :)17:24
jam $COLUMNS concerns me, because doing something like:17:24
vilawow, wow, wow :)17:24
jambzr log --line > file17:24
jamseems like it shouldn't truncate17:24
jamshould bzr log --line | less?17:24
jamshould we truncate a progress bar, but not log --line17:24
vilayeah, the truth is I started thinking COLUMNS wasn't set behind my back but *always* by the user, I'm less sure about that now17:25
jamvila: well if you resize your window17:26
jamCOLUMNS is usually updated to match17:26
jamit just isn't updated 'on-the-fly' while the program is running17:27
jamhence SIGWINCH17:27
vilaI thought you had to use termios, not COLUMNS for that... It appears I was wrong (still not completely sure, try:)17:27
vilatry: env| grep COLUMNS17:28
vilathen echo $COLUMNS17:28
vilathen under python look at os.environ['COLUMNS']17:28
=== beuno is now known as beuno-lunch
jamvila: I'm currently on Windows, which has fairly fixed column width for cmd.exe17:32
jamI can try it, I suppose17:32
jamecho "$COLUMNS" is empty for me17:33
vilaAch, windows, yeah, I have some pending questions there too... as pointed in some bugs bzr behaves differently wrt redirections on windows and linux...17:34
jamvila: well, there you have to also worry about '\r\n' and setmode(binary) etc.17:35
vilajam: on OSX: http://paste.ubuntu.com/299876/17:37
jamvila: pretty17:37
jamI like how it ends in a frown17:37
vilaon jaunty: http://paste.ubuntu.com/299877/17:38
jamhmm. same result17:38
vilaon FreeBSD: http://paste.ubuntu.com/299879/17:40
vilasome result too, except when set by the user, COLUMNS is not seen by python...17:40
vilaI suppose *bash* knows about COLUMNS in some kind of way17:40
Peng_Oh, good, my weird results aren't unique.17:51
jamvila: go start enjoying your weekend17:56
vilajam: yeah, revert sent to pqm, I'll poke babune later :)17:57
vilajam: thanks, enjoy yours too when you decide it :)17:57
=== beuno-lunch is now known as beuno
jfroy|workjelmer: ping-a-pong18:43
=== cellofellow is now known as undefined
=== undefined is now known as Guest33850
=== Guest33850 is now known as cellofellow
Takif I set a command's outf to something other than stdout, will the file be closed automagically when the command is gced or no?19:18
Takhmm, it looks like "no"19:23
=== thunderstruck is now known as gnomefreak
bialixfullermd: ping19:55
=== asac_ is now known as asac
Kmoskmos@kmos:~/packages/apport$ bzr push lp:apport20:31
Kmosbzr: ERROR: Cannot lock LockDir(lp-46086288:///~apport-hackers/apport/trunk/.bzr/branchlock): Transport operation not possible: readonly transport20:31
RenatoSilvaIf I cerate an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and merge all-features into trunk, will only the new commits CONFLICT_N be merged from all-features into trunk?20:31
Kmosbreak-lock doesn't work20:31
RenatoSilva* If I create an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and then merge all-features into trunk, then will only these new commits CONFLICT_N be merged from all-features into trunk?20:32
KmosRenatoSilva: don't repeat yourself20:32
RenatoSilvaKmos: Strictly speaking, I didn't ;)20:33
=== dorins_ is now known as wave
Takhmm, if I have something in ~/.bazaar/plugins that I have a different version installed systemwide, will my local plugin override, or will there be a conflict?21:10
lifelesslocal wins21:20
=== MTeck-ricer is now known as MTecknology
james_whi lifeless22:18
james_wthanks for making the changes22:18
james_wI haven't reviewed the incremental diff, but I don't foresee any problems22:19
james_wI just replied before seeing the mail that you had made them22:19
lifelessso I made the bits *I* consider a must given the things the review discussion uncovered22:20
lifelessI haven't change print to mutter, or other such things22:20
james_was I said, I'm happy to take over if you are willing to block on me22:20
lifelessWell, I'm running from a homedir install now22:21
lifelessnot going to block regardless22:21
james_wbut as you are asking me to maintain the code I am wary of merging it with things that I can see being problematic22:21
lifelessso, I don't think there are things remaining that are problematic, just differnet22:21
lifelesswith the sole exception of the oauth file22:21
lifelessand I think that all of that should be in launchpadlib *anyway*22:22
lifelessits fugly the way the setup stuff is cargo culted around22:22
james_wI pointed to the API for that22:22
=== wave is now known as testlongnick
james_wdid you take a look at whether it matched?22:22
lifelessno, its saturday ;P22:23
lifelessand I don't understand enough to know if it matches or not.22:23
james_wfair enough22:23
lifelessthe whole launchpadlib thing is rather opaque to me22:23
lifelessthe pydoc is epic epic epic fail22:23
lifelessand the total inability to work and test with it offline (Without a multi-hundred mb separate download & apache locally) is a real disincentive to learn more22:24
lifelessso there is also a bit of passive resistance to learning more:P22:24
james_wpydoc launchpadlib.launchpad22:25
james_w /login_with22:25
james_wif you are interested22:25
lifelessso this is actual code and documented ;)22:25
lifelessso, login_with looks fine, but given that I know nothing about the failure modes, internals, required facilities, expected conventions...22:27
james_wthe only issue with it is that it puts the cache in "launchpadlib_dir"22:27
lifelessmy approval doesn't mean much22:27
james_wand currently the cache is broken with multiple processes22:28
lifelessOh, I really hate the cache22:28
lifelessit shouldn't need one.22:28
lifelessDamn silly idea, HTTP caches are extremely hard to get right.22:28
lifelessbuild the API by introspecting the wsdl and compiling python from it; then ship the resulting static API, which is fully documented and faster22:29
lifelessI say HTTP caches are hard to get right after years as squid-core :), its an informed opinion.22:29
lifelessalso, if you need an HTTP cache for a web services API to work, the API design is broken and will perform problematically [because of cache seeding overhead at a minimum]22:32
james_wbug 459418 filed as due dilligence22:33
lifelesswhat else, oh, require write access means you can't use launchpadlib as a very restricted user, or [for instance] to grab backup data during system restore when nothing is mounted writable22:33
ubottuLaunchpad bug 459418 in launchpadlib "Cache is broken with multiple processes" [Undecided,New] https://launchpad.net/bugs/45941822:33
james_wI can now go back to moaning about how login_with is broken with a clear conscience22:34
james_wanyhow, I shall make some time to merge your code at some point22:35
james_wthanks again22:35
lifelessthat would be excellent22:35
lifelessI'd lke to be running a packaged bzr-builder22:37
lifelessthe less string the easier to get OSA's to run the service ;)22:38
jfroy|workuuuuarg oops22:51
* jfroy|work hides in shame22:51
jfroy|workdefeated by too many tabs, once agao22:51
jfroy|work*again. I apologize.22:51
jfroy|workjelmer: ok I have the weirdest problem with bzr-svn22:59
jfroy|workwell, it seems to me that way. I have a completely clean repository with no bzr: props or revprops and no svn:mergeinfo or svk:merge props.23:00
jelmerjfroy|work: are you psychic? I just returned back to my computer after being away for half a day and you ask within a couple of seconds :-)23:00
jfroy|workand a straight bzr branch of the trunk branch in that repo yields a bazaar branch with a number of sha1 mismatch errors23:01
jfroy|worklol :p23:01
jfroy|workno, I'm pretty sure I'm not :p23:01
jfroy|workbasically, we're migrating a project from a repo with a bunch of projects in it to a brand new repo dedicated to only one project23:02
jfroy|workso I 1) branched using bzr the trunk and the current active branches from the old svn repo 2) pushed trunk (with the push merged revision option enabled) to a simulation blank svn repo 3) dumped that 4) ran a filter on the dump to strip every revprop and prop starting with bzr: (as well as svn:mergeinfo and svk:merge) 5) loaded that filtered dump into a new repo and 6) branched the trunk from that repo23:04
jelmerdid you change the UUID or throw away the cache?23:04
jfroy|workthat should yield a clean bzr branch, shouldn't it?23:04
jfroy|workpretty sure I did23:04
jfroy|work~/.bazaar/svn-cache/ and ~/.bazaar/subversion.conf23:05
jfroy|workAnd I get a "Initialising Subversion metadata cache" message when branching23:05
jfroy|workI'm guessing the only thing left that could trip bzr-svn are copy nodes it's trying to interpret23:06
jfroy|workI don't think there's anything that can be done about those23:06
jelmercan you reproduce the problem on a small repo?23:07
jfroy|workI have no idea how to reproduce this23:08
jfroy|workoi, wait a second...23:09
jfroy|workthese are the sha1 mismatches23:10
jelmercan you pastebin the backtrace?23:10
jfroy|workno backtrace23:10
jfroy|workthis is output by bzr check23:11
jfroy|workAll of those files are symbolic links23:11
jfroy|workI think this is the problem23:11
jelmerah, that might make sense23:11
jelmerThat should be a relatively trivial bzr-svn bug23:11
jfroy|workthose 4 files are all empty with Property svn:special set to *23:11
jfroy|workand the content set to "link Versions/Current/ATF"23:12
jelmerwe're just filling in a different sha1 in the inventory as we put in the versionedfiles23:12
jelmerjfroy|work: can you file a bug?23:12
jelmerjfroy|work: :-)23:12
jfroy|worklet me try to repro with a simple repo23:12
jelmerjfroy|work: I have some long flights coming up, might give me something to do :-)23:13
jfroy|workThat would be incredibly awesome :)23:13
jfroy|workreproduced with a one commit repo23:17
jfroy|workjelmer: https://bugs.launchpad.net/bzr-svn/+bug/45944023:22
ubottuLaunchpad bug 459440 in bzr-svn "bzr-svn sha1 mismatches on symbolic link files" [Undecided,New]23:22
jelmerjfroy|work: awesome, thanks23:23
jfroy|workjelmer: oh, I've found another minor issue23:26
jfroy|workif you create a brand new repo and push a branch to <repo url>/trunk, you won't get any tags (but branches will show up if you have push merged revisions)23:27
jelmerjfroy|work: please file a bug for that one as well23:27
jelmerjfroy|work: and thanks :-)23:27
jfroy|workif, however, you create a revision 1 with svn that creates the standard layout, then push --overwrite, then you'll get tags23:27
jfroy|workI'm guessing it doesn't detect that the repo is using the standard layout23:28
jfroy|workprobably needs a "repo is at revision 0, I should make the standard layout first" special case23:28
jelmerI suspect it's because we have a different code for "create this branch" vs "push revisions to this existing branch"23:29
ubottuLaunchpad bug 459444 in bzr-svn "Pushing to a blank repository does not push tags" [Undecided,New]23:33

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