davidstrausswhat is the fake shell used for locking down bzr access?00:04
davidstraussi know there's a popular one00:04
lifelesssavanah use a thing called rsh00:08
lifelessnot your grandfathers rsh00:08
lifelessthere is a contrib/ script in bzr's source tree too00:09
jbowtieI seem to have an issue where the repository is lying to me about its contents.00:40
jbowtieSpecifically, repository.has_revisions() is returning a revision that I'm pretty sure is not in the repository.00:40
jbowtieThis is a probably a result of a bug in my plugin, but I don't know how to debug it.00:41
lifelessare you accessing the repo via a stacked branch ?00:41
jbowtieNo, it's a normal branch. Possibly its not correctly reflecting the repository contents however.00:43
lifelesscan you share a bit more context about what your plugin wants to do and whats going on00:44
jbowtieSure, it's a plugin for using Team Foundation Server as a foreign VCS.00:46
jbowtieI've had import working for a while and have been working on getting round-tripping viable.00:47
jbowtieSo I pushed some revisions into TFS last night, pushed another one this morning.00:47
jbowtieIn between there were some updates, (about 18 revisions or so)00:48
jbowtieAttempting to pull those revisions however, says "nothing to pull".00:48
jbowtieNormally I just call target_repository.has_revisions with the list of revision ids from the source repository.00:49
jbowtieBut the target is telling me that it has those 'missing' revisions even though that's pretty likely to be false.00:50
lifelessthe target is a bzrlib native repo00:50
lifelessthe source is TFS accessed via your plugin00:51
lifelessthe revisions you want to fetch are the new ones in TFS00:51
lifelessin the target00:51
lifelessyou can do00:51
lifelessbzr cat-revision -r revid:<revision id>00:51
lifelessto quickly get at a revision from the command line00:51
lifelesspoolie: are you still caring for the kanban board?00:53
jbowtielifeless: Hmm.... ERROR: u'revision' is not present in revision00:55
lifelessyou have a revision called revision ?00:55
jbowtieNo, sorry, I ommitted the actual revision id at the end of error message.00:56
lifelessso bzr doesn't think its there00:56
lifelessif you open up python00:56
lifelessand do from bzrlib import repository00:56
lifelesstarget = repository.Repository.open('pathtorepo')00:56
lifelessyou can see what is going on a bit more closely00:57
jbowtieI suspect that has_revisions might be giving me spurious results. I'll do some more delving and see if I can narrow down the problem a bit more.00:58
jbowtieThanks for pointing out cat-revision, that should help with investigating.00:59
lifelesspoolie: you might like http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/01:06
jbowtielifeless: Heh, I typed "cat revision" earlier instead of 'cat-revision'.01:15
jbowtieSo the missing revisions are in the bzr repository, but aren't reflected in the corresponding branch.01:16
jbowtieSo what does that mean?  Has my branch history been corrupted? Has my plugin missed the fact that the branches diverged? Possibly should have caught it at the last push?01:20
lifelessbranches have a single tip01:21
lifelesswhat is the tip revision of your bzr branch01:21
jbowtieIs there an easy way to get that from the command line/01:24
spivBranch history is different to the repository.  A revision can be in the repository but not in the branch's ancestry.01:24
lifelessbzr revision-info01:24
lifelessbzr log -r -1 --show-ids01:25
jbowtieThe tip's what I expect, the last revision that was pushed.01:26
lifelessso you've pushed something01:26
lifelesstell me what happens in TFS01:27
lifelessif you push something01:27
lifelessand someone else pushes stuff after01:27
lifelessdo they have to merge your thing first01:27
lifelessor does the TFS server merge for them01:27
lifelessor is TFS not distributed01:27
lifelessso it actually just counts new work as new commits01:27
jbowtieTFS isn't distributed.01:27
jbowtieOK, so my working theory is that the branches diverged after push #1, push #2 should have failed as they were divergent but succeeded anyway.01:31
lifelesspush 2 probably shouldn't have succeeded01:32
lifelessbecause you haven't incorporated the content of the other changes01:33
lifelesswhat you probably want to happen is to have had bzr give you a diverged branches error, made the user (you) merge TFS, commit, and then push suceed01:33
jbowtielifeless: Exactly.01:35
lifelessit sounds like you've got an impressively close system there01:36
jbowtieThanks, just waiting on legal to approve putting it on Launchpad.01:38
jbowtieSo is there a way to 'fix' my branch history?01:42
lifelessthis is the risk when buliding foreign interfaces :)01:43
lifelessthe revids are uuids01:43
lifelessso their meaning is pretty hard to change01:43
lifelessits why svn ones are hashes01:43
lifeless(and so are git and hg ones)01:43
jbowtieWell, I know that - I was thinking I could reparent the revs to simulate a merge.01:43
lifeless(their representation in bzr I mean)01:43
lifelessI can think of two routes01:44
spivlifeless: did you get a failure from pqm for the socketpair patch?  Or should I send it myself and receive a failure directly? :)01:44
lifelessdo a manual merge - 'bzr merge -r revid..revid .' of the things that god skipped over01:44
lifelessspiv: oh, we nuked the merge queue01:44
lifelessabout 1101:44
lifelessso please send01:44
spivAh, I thought I'd seen you say you'd requeue.  Will send.  I assume PQM is all happy now?01:45
lifelessI was01:46
lifelessthen the u1 pqm claimed to have blown up01:46
lifelessso I was up to 1:30 getting a handle on that and forgot01:46
spivThat's ok :)01:46
lifelessjbowtie: then when you commit that merge you'd end up with what TFS has and after that it would be all ok01:46
lifelessjbowtie: alternatively, you could nuke your repo and pull fresh from TFS01:46
jbowtielifeless: OK, I'll try the merge first, I really want to avoid nuking the repo again if I can help it. I've done that often enough developing this thing.  :)01:52
jbowtielifeless: Thanks, the manual merge appears to have done the trick!  I'll probably nuke the repository over the weekend anyway but I feel much more confident about repository integrity using my plugin.02:14
poolielifeless, hi, yes i still care for and about the kanban board02:54
lifelesspoolie: I was asking because it seemed a little stale03:07
poolieany bit in particular?03:12
lifelessyou and spiv seem to be looking at fetch perf03:25
lifelessnot jam and I03:25
lifelessI've hesitated to take my name off that; I have updated the pqm and loom branching stuff as it progressed03:25
pooliemm i don't know if single user assignment is a good match03:25
poolieperhaps we should have it unassigned03:26
lifelessI think from mary's perspective yes - team accountability03:26
pooliealso their ui fails unless you have a gravatar attached to your canonical email address03:26
lifelessthats odd03:27
poolienot fails as in crashes, just fails to be very useful03:27
lifelessyes, I got that ;)03:28
lifelessits odd that they'd not cater for people wanting private photos ;)03:28
lifelessanyhow, I like the brevity of kanban03:30
lifelessI was hoping it was just a little stale and not given up on03:30
lifelesswhich it was/is - so thats great.03:30
pooliei like the brevity too03:31
pooliei don't love this specific ui03:31
poolieit seems a bit slow and klunky03:31
lifelessI'm moving some things that appear stalled into backlog03:31
lifelessshout if you think thats wrong, and I'll put em back03:32
pooliespiv did you manually test the socketpair thing?04:00
spivI did.04:00
lifelessdoes inetd use pipes or socketpairs04:01
lifelessand more broadly04:01
lifelessshould we file a bug on launchpad-code to use socketpairs04:01
poolieneither, inetd directly connects the server to the socket04:01
spivinetd uses neither04:01
lifelessor less broadly04:01
lifelessentirely unrelatedly04:01
lifelessshould we make sure launchpad-code connects its twisted daemon that is doing ssh with the subprocess bzr via a socketpair04:02
pooliebug 595331 classic title :)04:02
ubot5Launchpad bug 595331 in QBzr "All button blows up (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/59533104:02
pooliesee the problem is04:02
poolieyou should be pushing the Any button04:02
spivHeh :)04:02
lifelessI can't find the Any key04:02
pooliespiv, lifeless, you can get decent coverage of this kind of thing by running it under wine04:03
poolieah, i guess it would depend on having an external ssh accessible under wine04:03
pooliebut that should be possible04:03
poolie'this kind of thing' meaning will it blow up without socketpairs on windows04:03
spivWell, in this case you can temporarily hack in "import socket; del socketpair" too04:04
spiver, "del socket.socketpair"04:04
spiv(And we already have the BZR_SSH variable for exercising the paramiko code path, which was also changed)04:05
lifelessI find it interesting04:06
lifelessthat all of (me, jam, poolie) have immediately assumed there are going to be issues validating/working on windows ;)04:06
lifelessand that spiv seems to have taken them all into consideration04:06
pooliei was commenting more in response to john's review04:07
pooliei don't anticipate there being platforms that have the python module but not the feature04:07
pooliethough it probably can happen04:07
lifelessyou may have missed it04:07
lifelessbut I grilled spiv about windows last night04:07
lifelesswith a similar sort of angle to the questions04:08
lifelessfor all that they were different04:08
lifelessI'm not offering any conclusion, I just found this an interesting thing04:08
spivWell, it's a good habit to ask "what about Windows", because we don't get as much automatic testing there.04:09
poolieif in doubt just run it04:10
spiv(I mean both because PQM doesn't test windows, and because fewer bzr devs run bzr on windows day-to-day)04:10
poolieyou may not be able to easily/quickly run the whole suite but you can fairly easily run one module of tests04:10
pooliei often do that04:10
spivGood idea, thanks for the reminder :)04:10
lifelesswine is amazingly good these days04:12
pooliemm pinot04:12
lifelessdid you see the http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/ link ?04:15
poolielifeless, i did, and that makes sense06:18
poolieone thing i would add is that tests can become write-once06:19
poolieie they're there, they pass, you don't want to break them but you also may not often actually improve them06:19
pooliei don't think shell-like tests are the ultimate but that patch definitely made the tests cleoaner06:20
pooliei'd like to work out how to test tribunal06:20
pooliewhat kind of tests would be most useful06:20
parthmlifeless: ping06:52
pooliehi parthm06:58
lifelessparthm: hi06:58
parthmhi poolie, lifeless06:58
lifelesspoolie: tests that catch bugs ;)06:58
parthmlifeless: in the context of jams test (https://code.launchpad.net/~parthm/bzr/250451-better-url-for-break-lock/+merge/27187) i was wondering if 10 or 30 s timeout sounds ok to you06:59
parthmthats the only thing pending on that patch now before i can put it for review07:00
poolielifeless, mm i might wait until i have an idea of typical bugs and then see what to do07:00
poolieat the moment most of them are lack of understanding of how something will interact with gtk07:01
vilahi all07:03
parthmvila: hi07:05
lifelessparthm: I'm easy either way07:12
lifelessparthm: we can always change our mind later07:12
parthmlifeless: sounds fine. I will put it for review with the current value of 30s. thanks.07:13
assadis thr any software which could show differennt revisions side by side. something like meld.07:14
lifelessassad: you can use meld07:19
spivassad: well, you could always use meld :)  But there's also 'bzr qdiff' (from the qbzr plugin), for instance.07:19
pooliehi vila07:20
parthmassad: also, bzr diff --using=meld ... you can set up an alias if you use it frequently.07:22
assadok thank you guys07:23
poolielifeless, did my 'gnuness' branch bounce?07:30
vilapoolie: hmm, I forgot that one, no probably it get killed when pqm was wipped07:30
lifelesspoolie: when did you submit it07:31
poolieyou did, 20 hours ago07:31
lifelessno, it got zapped07:31
vilalifeless: pretty sure it was just after I submitted the broken one that got cancelled07:31
=== radoe_ is now known as radoe
lifelesscleared out the stuff I'd submitted when the  base64 thing was noticed07:32
lifelessthere was some confusion about who was resubmitting07:32
lifelessThat is, I was confused, noone else stood a chance ;)07:32
lifelessvila: oh hai07:33
lifelessvila: my loom support branch07:33
poolieok, re-sent07:33
lifelessvila: please check the most recent commit on it; minor stuff07:33
vilalifeless: on bzr ? loom ? both ?07:34
lifelessoh, as soon as I push it07:34
lifelesshas an open, approved mp07:34
lifelessI want to land a little bit more.07:34
lifelessok, should be there now07:34
lifelessvila: rev 529907:35
lifelessvila: loom trunk has its stuff already07:35
vilalifeless: updating diff07:35
lifelessvila: just diff -c lp:~lifeless/bzr/loomsupport ;)07:36
lifelessvila: I'm asking for incremental07:36
vilalifeless: updating, ooooh upstream up to thread.... Thanks abentley !!07:37
vilalifeless: byt the way, you mentioned several times something about.... noisy merges in a loom, my leaking-tests loom has lots of those, can you explain a bit more what you have in mind and does it apply there ?07:38
vilas/upstream/up-thread/ silly typo07:38
lifelessvila: I'm rather tired after last night07:40
lifelessvila: my tomorrow first thing I'd be delighted to discuss it more07:40
vilalifeless: ok, no problem, I wanted to ask for some time but keep missing the right window07:41
lifelessvila: so, the loomsupport change is ok ?07:48
vilalifeless: yup, except for the NEWS entry order07:48
lifelessvila: whats wrong with the NEWS entry order?07:48
vila'branch' < 'knit'07:49
vilano ?07:49
lifelessI was asking for the incremental change to be reviewed07:49
lifelessnot the entire branch07:49
lifelessI will fix that07:49
lifelessbut it would have saved you some time :)07:50
vilathe incremental change seemed obscure at first glance s//from_/ :)07:50
lifelessI wonder if diff -c should show the commit message too07:50
spivwebnumbr.com is really cute07:55
vilalifeless: maybe, but maybe fixing the tests so that calling make_from_branch_and_tree wasn't necessary (dunno if this makes sense anyway) would have resulted in an easier to read change, as long as it works, I don't care that much07:55
mlhspiv: nice! the big G had something similar but the sources were (much) more constrained07:56
lifelessvila: i think being able to do default format stuff is good too07:56
vilalifeless: sounds perfectly reasonable07:57
spivThe interface for creating a graph is quite neat, and the API is pretty cute too.07:57
mlhrrd graph would be good as well07:57
mlhbut it is a good api07:57
vilalifeless: I was speaking as a lazy reviewer not as a pedantic tester :-)07:58
mlhsuggestion submitted07:59
* mlh goes back to work07:59
lifelessspiv: hmmm, open bugs in bzr, boom.08:07
lifelessas in , should be trivial08:07
lifelessthe ajax d-feats it08:09
vilaparthm: you didn't pushed your latest changes, but my last vote was tweak anyway, so please land08:09
parthmvila: the diff shows the latest. anything missing?08:12
spivlifeless: yeah, you have to be cunning :/08:12
lifelessI've filed a ticket08:12
parthmvila: i will land it. thanks for the review.08:12
spivHeh, the "average" function in the API appears broken... it sums N data points ok, but they seem to have forgotten the "divide by N" step.08:14
vilaparthm: weird, sorry for the noise, I didn't see the push in the mp comments and didn't check the diff itself08:15
vilaparthm: well, I meant, I *still* don't see the push in mp comments :)08:15
vilaspiv: growth ! growth ! That's the only important thing !08:16
parthmvila: yes. it i don't see it inline either. its 5293 'cleaner handling of lock_url display.' ... maybe a bug due to needs review -> wip -> needs-review transition.08:17
vilaparthm: no worries08:17
parthmvila: or maybe a feature for wip :)08:18
vilaparthm: features like that are bugs :)08:19
vilaparthm: can file one against lp-code ?08:19
* vila insert 'you' above08:19
parthmvila: will do.08:19
vilahmm, almost aligned ;)08:19
parthmvila: bug #595392 .. feel free to add to it in case i have missed out something.08:33
ubot5Launchpad bug 595392 in Launchpad Bazaar Integration "commit not seen inline during needs-review->wip->needs-review transition (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/59539208:34
vilaparthm: perfectly clear :)08:35
=== assad is now known as assad|lunch
RunePhilosofpoolie, could you please take a look at bug 367545 again.09:18
ubot5Launchpad bug 367545 in Bazaar "Huge memory usage for bzr branch/checkout (affected: 5, heat: 21)" [High,Confirmed] https://launchpad.net/bugs/36754509:18
bialixheya bzr09:43
bialixbonjour vila09:43
vilabialix: privet Sacha :)09:45
bialixvila: I'm about to tweak right now09:46
bialixmy I beg you to land that patch then?09:46
vilabialix: sure, push your changes and ping me09:47
vilabialix: I wasn't sure you had a working pqm setup09:48
bialixvila: I don't have one09:48
bialixand poolie latest patch infers I should use Hydrazine09:48
bialixI'm afraid of this beast09:48
jszakmeisteranyone seeing crazy memory usage during a pack operation?09:51
jszakmeisterRight now, it's looking like 17.5x-20x the file size when repacking texts. :-(09:52
vilajszakmeister: crazy is too subjective :-/09:52
vilasize of which file ? The biggest pack ?09:52
jszakmeisterI'm re-creating a problem that we saw with another repo...09:53
jszakmeisterI'm using a single file, file.bin, and completely changing it's contents every commit...09:53
jszakmeisterand it has 100m of binary data in it.09:53
jszakmeisterIt *seems* to be relative to the size of that file.09:54
vilaAFAIK repack shouldn't consume insane amount of memory anyway, commit is still about ~x3 IIRC09:54
jszakmeisterYeah, that's what I thought too... but it's definitely real high when repacking texts. :-(09:55
vilajszakmeister: so what is the peak memory ? 2GB ?09:55
jszakmeisterYeah, depending on when the process gets sampled, I see anywhere from 1.75 to 2.0GB.09:56
vilaI know jam has some way to track this but I don't remember if there is an env variable for that09:56
vilachecking with him later in the day seems the best option09:56
jszakmeisterFor a 100MB file.  I'm going to try this with a larger one and see how it changes, but I'm pretty sure it'll grow.09:57
bialixvila: ping-ping, ring a bell :-) code tweaked, bzr.dev merged, news conflicts resolved, pushed to lp. ready to land!09:57
jszakmeistervila: For max memory consumption you mean?09:57
jszakmeisterThat'd be helpful if he does!09:57
vilabialix: sent to pqm09:59
vilajszakmeister: yes09:59
vilajszakmeister: and even a plugin (meliae) to investigate09:59
jszakmeisterNeat.  BTW, that figure was the "real memory" used.  I think the actual VM size is larger.10:03
bialixvila: commit message slightly out-of-date, sorry, I forgot about it10:04
vilabialix: ? Show unicode filenames in diff headers using terminal encoding sounds fine to me10:06
bialixno more "on Windows-only"10:08
vilaha, rats, well the NEWS entry is correct, that's the most important10:12
* bialix bbl10:26
raphinkHi there10:56
raphinkwhen setting up a shared repository with bzr, I put a 02770 right on the top folder10:56
raphinknow when users add directories, they have the right group, but they don't inherit the "g+w" bit, so other members of the group don't have write access to the contents of this new directory10:57
raphinkis there a way to do this?10:57
fullermdWhat do you mean by 'add directories'?  As in push in new branches?10:58
raphinkor just add a directory inside a branch10:58
fullermdYeah, I'm pretty sure bzr doesn't have any builtin support for inheriting permissions like that.10:59
raphinkwell I think this has to be done using unix permissions10:59
fullermdIt does for stuff under .bzr/, but new bzrdirs, not so much.10:59
raphinkCVS seems to force the permission inheritance when adding a directory with "cvs add"10:59
fullermdIn the working tree?  I'm pretty sure it doesn't...11:01
raphinkwell I just tried11:02
raphinkI have a repository in /cvsroot/test11:03
raphinkwhen I do a "mkdir /cvsroot/test/toto" , it gets drwxr-sr-x11:03
raphinkbut if I do it with cvs add11:03
raphinkit gets drwxrwsrwx11:04
fullermdThat's in the repository, not the WT.11:04
raphinkwell CVS add works directly in the repository, for sure11:04
fullermdbzr inherits inside the repo (though there's no mirror of the tree structure in the repo layout in non-antique formats of course)11:04
raphinkmy point is that when I do a CVS add, it seems to not only do a mkdir on the repository, but force the inheritance of the parent dir11:04
raphinkwhen you say inside the repo, you mean locally?11:05
fullermdWherever a repo is touched.11:05
raphinksay, in bzr, I do a branch of my repo11:05
* fullermd thinks we're talking past each other...11:05
raphinkI do a bzr add on a directory11:06
raphinkand I commit it11:06
raphinkthen I push it back to the parent branch11:06
raphinkI won't get the same result I can get with CVS, which is that this repository will have g+w so the other members of the group can commit to it11:06
fullermdIt will if the repo has perms right.  bzr WILL inherit those perms on new pack files etc.11:06
fullermdAt one time I knew exactly which dir it grabbed from.  But I don't bother remembering, I just `find .bzr -type d -print | xargs chmod g+w` or its immoral equivalent.11:07
raphinkyou mean you have a hook on the server to do that?11:08
fullermdNo, I mean I do that manually when I setup the repo in the first place.  bzr preserves the g+w on new files it makes in the repo.11:08
raphinklet me see11:09
raphinkthank you for your help already fullermd11:11
raphinkhmm I just tried again11:14
raphinkthe whole repo is g+w and g+s11:15
raphinkit's a shared repository11:15
raphinkI'm pushing back my branch11:15
raphinkwhich ends up in $reporoot/branches/mynewbranch11:15
raphinkand it doesn't inherit g+w11:16
fullermdPaste a ll of the file?11:17
raphinkdrwxr-sr-x 3 rpinson    scm_spp 4,0K 2010-06-17 12:14 testraphink11:17
raphinkand the parent dir is11:17
raphinkdrwxrwsr-x 166 rchalumeau scm_spp 12K 2010-06-17 12:14 /cvsroot/spp/sppcpp/.bzrroot/branches/11:17
fullermdOK, so we're talking past each other.11:18
raphinkwhat do you mean?11:19
fullermdbzr preserves perms on files inside the repo, like [...]/.bzr/repository/packs/*11:19
fullermdYou're talking about perms on a [new] branch, which don't inherit.11:19
raphinkso new branches cannot be shared?11:19
fullermdbzr doesn't touch those at all; it's all determined by the system via umask etc.11:19
raphinkbut if I add a dir in an existing branch, then it will work11:20
fullermdYes, those are all internal objects in the revision, which get stored in packs in the repo, which bzr DOES set perms on.11:20
fullermdFor instance, if instead of pushing a new branch, you'd pushed your changes onto the existing branch.11:21
raphinkso then we have to setup shared branches with g+w and use these for merges11:21
raphinkfor the group11:21
raphinkother created branches will remain with individual rights, while these can be used for group purposes, right?11:21
fullermdGenerally, branches fall into one of two categories: (1) long-lived shared branches, and (2) short-lived individual branches.  And those perms aren't a problem for either, since in the first place you'd just blat a g+w over them manually once and forget it.11:22
fullermdIt's only with relatively transient branches that you still want multiple people writing on that you get into trouble.11:22
fullermdYou could try fiddling with things so that when bzr is invoked (I'm assuming you're all going over bzr+ssh) it sets the umask to allow group writes.11:23
fullermdThough that's a little dangerous on GP, and wouldn't be suitable if that weren't the only config being used on the box of course.11:23
raphinkthanks for the clarification11:23
raphinkI'm afraid the categories for the devs are not that clear ;-)11:24
fullermdYou could setup a cron job to just g+w all the branches under a given dir Every So Often(tm).11:24
fullermdbzrtools has a 'branches' command, so you could `cd /where/ever && bzr branches | xargs chmod -R g+W`11:25
fullermdOr just forget about subtlety and g+w the entire dir tree under the repo point.11:25
rom1hi there11:26
raphinkfullermd: rom1 is the dev having this issue11:26
raphinkI was just proxyfying the conversation11:26
raphink(I'm the sysadmin in charge of the forge)11:27
rom1hi fullermd11:28
rom1thx for the tips11:28
fullermdWell, if working on branches that should be g+w is the only thing bzr is invoked for, wrapping around it and resetting the umask can be a viable solution.11:28
fullermdJust stick a 'bzr' shell script in some dir ahead of the real bzr in $PATH with contents like   umask 002 && /real/bzr "$@"   in it11:29
raphinkthat might be an option, thank you fullermd11:33
rom1thx a lot fullermd ! now i have to reconsider some stuff in our way of working...11:34
fullermdFor that matter, if it's a forge, often the ONLY use of the accounts is to access bzr stuff, so you could just setup such a umask as the default.11:34
fullermdReconsideration of working methods is awesome.  It LOOKS like real work, but it's way more fun   ;)11:35
rom1sure it is...11:35
fullermdAlways an interesting back and forth between adjusting your approach to fit the tool, and adjusting the tool to fit your approach.11:36
rom1Above all when we have a ten years habit on CVS... It is a really deep change11:37
fullermdDefinitely.  I had that habit myself.  Sneaking into back alleys...   dressed in rags...  manually editing files in the repo on dark nights when nobody could see...11:38
* fullermd whimpers.11:38
fullermdBut I'm clean now, I swear.  I haven't used CVS in, like, days.11:38
rom1lucky man... [long whisper]11:39
vilaraphink: which protocol do you use to push ?11:58
raphinkvila: bzr+ssh12:11
Lo-lan-doHi all12:58
Lo-lan-doI'm getting lots of conflicts when merging a branch after a directory was renamed…12:59
Lo-lan-doDetails: a few files changed in ./gforge/foo in branch 5.0, ./gforge renamed to ./src in branch trunk with a gforge->src symlink, merging from 5.0 into trunk.13:00
Lo-lan-doIs that expected?  Can it be avoided?  Is it related to the symlink?13:01
=== bouncingzip is now known as mgz
spivLo-lan-do: sounds odd, renames like that shouldn't produce lots of conflicts13:14
spivLo-lan-do: perhaps the files were deleted and readded by mistake, rather than renamed?13:14
spivI wouldn't expect the symlink to be related, but then I wouldn't expect lots of conflicts from your description either.13:15
Lo-lan-doIt may be relevant that both branches are bound to an SVN repository.13:15
spivAh, I think maybe in that case they do show up as delete/add pairs rather than renames :/13:15
spivThe output from the merge command (and "bzr status" afterwards) should make it clear if it's just a rename or if things have been deleted and added.13:16
Lo-lan-doRight.  bzr log -v --long tells me that it's a remove/add indeed :-/13:17
fullermdYou could try a 'status' on the rev that did the move too.13:17
marsilainenhi all13:18
marsilainenI'm pondering the best way to set up my source server13:19
Lo-lan-dofullermd: Same thing.  Okay, I'll blame the rename in SVN.13:19
Lo-lan-doThanks, I'll cope somehow.13:19
marsilainenI'm wondering whether it's best to use bzr, sftp, http, or something else for the transport mechanism13:19
marsilainenam I right in assuming that mostly people use sftp these days?13:19
marsilainenI'm wanting a gatekeeper type of workflow btw13:20
Lo-lan-domarsilainen: /me uses bzr+ssh://13:20
marsilainenI'd like people to be able to get a branch anonymously though13:20
marsilainenso doesn't that rule out bzr+ssh?13:20
Lo-lan-doYou can have the same repo available through both bzr+ssh and http13:21
fullermdNot quite necessarily, though in practice generally.  Doesn't mean you can't use bzr+ssh on the writing side of course.13:21
marsilainenso is it generally best to allow people to get the code via http, then send changes to me and I commit them using ssh or whatever?13:22
marsilainenI guess that all sounds sensible13:22
Lo-lan-doWhat's generally best is to find a way that sticks so your workflow.  Many scenarios are possible, pick your preferred one :-)13:23
marsilainenI guess this sort of workflow/scenario is quite common, but I couldn't find a tutorial which went through it13:23
marsilainenanyway, I'll go with that13:24
marsilainenthanks for the help13:24
Lo-lan-doBased on your description, my choice would probably be to have a local branch bound to a bzr+ssh branch that's also accessible through http.13:24
Lo-lan-doBut you may prefer pushing by hand rather than binding, or using sftp instead of bzr+ssh, or lots of other variants.13:25
marsilainenI don't know what binding is, so I'll have to look into that13:25
Lo-lan-doIt's sometimes called heavyweight checkout.13:26
fullermdIf bzr+ssh works, you almost certainly will want to use it instead of sftp.  Dumb protocols are dumb.13:26
marsilainenok, so yes, that looks like what I want13:29
marsilainenso, local branch bound to mainline over bzr+ssh, and http access to the same mainline13:29
marsilainenhaving so many choices is very flexible, but knowing which is the right one to use for a given scenario is quite a challenge :)13:30
vilaspiv: Still up ? Have a look at babune, your last patch broke :-/13:32
vilaspiv: more precisely FAIL: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh13:36
vilaspiv: which makes me wonder if we trigger another bug in paramiko13:36
mgzmaybe just a tyop, vila?13:44
mgzreturn self._sock.read(count) <- should be recv?13:44
mgz...doesn't explain how it got past pqm though...13:44
vilamgz: people reading above my shoulder and pretending *they* found the bug are so irritating :-)13:45
spivmgz: yes, that looks likely13:45
* mgz takes all the credit13:45
vilaspiv: indeed, s/read/recv/makes the test pass, tell Vincent you really need to sleep now :)13:46
spivThis is a code path that would only be used with sftp, not bzr+ssh13:46
spivI'm not sure why that isn't failing on PQM13:46
vilaspiv: that's the scary part yes13:46
spivPerhaps PQM doesn't have paramiko?13:47
vilaspiv: that's the scary part yes :-)13:47
spivvila: so it is indeed my bedtime13:47
vilaI'll pqm the fix, feel free to investigate when you wake up13:48
spivvila: but I "vote approve" the typo fix, and please file a bug about PQM not catching it13:48
vilaspiv: I'll do13:48
mgzvila: has jam's observation about _probe_bzrdir got you anywhere new with the leaking tests?13:57
vilamgz: It clarify my suspicion which helped a lot, I'm tearing the smart server in reusable parts right now while spiv is sleeping :)13:58
vilamgz: the hangs themselves are due to my incomplete modifications13:59
vilamgz: I need to roll them back and restart with the new test server infra14:00
sven_sandberghi! i have a shared repository (2a) with a few mysql trees in. i am now trying to pull a revision from our central repository (also 2a), and after it has downloaded ,it's taking hours. it's the same with bzr 2.0.2 and bzr 2.2b3 (pulled from lp this morning).14:00
sven_sandbergthe status message is currently 'Fetching revisions:Inserting stream:repacking texts:texts 242291/637888'14:00
sven_sandbergother people tried the same pull without problems14:01
sven_sandbergany idea what is going on? is my local repository broken?14:01
mgzvila: I'd really be very tempted if you're feeling rewritey to set it up in such a way as you can spawn rather than thread the server it at the drop of a flag14:01
vilasven_sandberg: this sounds like a conversion happening on the fly14:01
fullermdNo, it's repacking.  That can take a while if it's a big repository...14:01
sven_sandbergfullermd, so is it somehow trying to optimize my repository? is it possible to turn this off and do it later when i have time?14:02
mgzthere was talk about TerminateThread being used, but that's really not safe, unlike killing child processes14:03
Lo-lan-doYou can do it preemptively, but I'm not sure you can disable it.14:03
vilasven_sandberg: except if it's the *first* repacking since the conversion which is weird anyway14:03
fullermdI don't think you can disable it through the CLI; some code level frobbing can do it.14:04
sven_sandbergvila, it's the first time i see this after we upgraded to 2a. but i have been pulling successfully without this happening many times14:05
vilamgz: forking will kill perfs on windows, even on Unix it  may be costly, plus some tests except to be able to share some data with the server (that's not super clean, but that's the way it is)14:05
vilasven_sandberg: have a look at the .bzr/repository/packs directory sorting the file by size14:05
mgzI agree it's probably not a solution we want, but having it as an easy switch in the test at least makes narrowing down certain issues easier14:06
fullermdsven_sandberg: It does tiny repacks fairly often, and minor repacks less often, and major repacks not so often, and gigantic repacks rarely.  So the ones you've seen to date are probably over before you notice 'em.14:06
vilasven_sandberg: you may be repacking the biggest file which takes time14:06
mgzhaving some problematic subset of server tests forking for the moment would be workable14:07
sven_sandbergfullermd, i see, makes sense14:07
sven_sandbergvila, there are 35 files, and the biggest one is 299 MB14:07
sven_sandbergfullermd, would it be a reasonable feature request to add an option to CLI to turn this off?14:08
sven_sandbergi mean, i don't even know if it's doable...14:09
vilasven_sandberg: the rule is to pack each set of 10 files into a bigger one, just knowing that there is 35 files doesn't tell me enough14:09
vilasven_sandberg: *not* packing would have a pretty bad impact on performance14:09
vilasven_sandberg: I don't think you'll run into the same problem soon, otherwise the solution is to repack each night preventively14:10
vilasven_sandberg: but if that's the first time you encounter the problem, I don't think it's worth it14:10
sven_sandbergvila, i see. the file sizes are, in MB (rounded), 299 38 34 19 17 10 4 3 3 3 3 3 2 2 2 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 014:13
sven_sandbergvila, how do i repack preventively?14:13
Lo-lan-do35 files can hold about 100000 revisions.14:13
vilasven_sandberg: 'bzr pack'14:13
Lo-lan-doEr, make that 10000, sorry.14:14
xapantuhi all !14:15
xapantuIs it possible to execute a script after each comit ?14:15
sven_sandbergvila, thank you!14:16
xapantubecause I would like that a file was updated with thz bzr revision number to each commit.14:16
xapantudo you have any idea ?14:16
xapantuThanks ! :)14:16
mgzlook at the docs for post commit hooks14:17
vilaxapantu: embedding VCS info in versioned files is rarely a good idea, but have a look at post commit hooks and 'bzr version-info'14:18
mgzbut... it sounds more like you want the... wassit... right, what vila said14:18
mgzwhat's the term for the $$ thing cvs does?14:18
xapantuok, thanks !14:18
vilamgz: see ? I can look above your shoulder too :-P14:18
vilayeah, there is that too, lp:bzr-keywords ?14:19
mgzthanks :)14:19
xapantubut I would like to do this on all branch : e.g. : if another developer checkout the branch, he doesn't have the hooks, does he ?14:19
Lo-lan-doxapantu: Note that .bzr/branch/last-revision already has the last revision number14:19
vilaxapantu: then let's step back a bit, what are you trying to achieve ?14:20
xapantui would like to do a dialog window with the revision14:20
xapantuInkscape do this with a makefile but it is very slow....14:21
mgzso, when the program is built, you want the revno in the about window, say?14:21
fullermdYou want to do that as part of the build process rather than as keywords anyway.14:22
fullermdKeywords are most applicable when you care about file-level stuff.  You want tree-level stuff for that.14:23
vilaxapantu: exactly what fullermd said14:24
xapantulike on this page : http://wiki.bazaar.canonical.com/KeywordExpansion ?14:24
xapantuI am reading it...14:24
fullermdOtherwise all you'll find out is "this file that contains the keyword was last updated at time/rev XYZ, even though the rest of the tree has had 600 commits since then"14:25
xapantuok, I am going to try with keywords.14:25
vilathat's the file-level approach14:25
vila... :)14:26
mgzare we talking inkscape here? if so, just working out what's slow with the current makefile and fixing it is probably the right answer14:26
fullermdAlso, keywords aren't really usable with bzr.14:26
vilaxapantu: bzr version-info --template 'var = {revno}\n' --custom14:27
vilaxapantu: start with the above, redirect to whatever file you see fit, running that *can't* be that slow :)14:27
xapantuok, I am going to add this to my makefile, thank a lot :)14:28
assadis there a meld like tool for windows? besides bzr qdiff14:39
sven_sandbergvila, fullermd, i need an estimate on how long time this will take... will it go through any more slow stages after "Fetching revisions:Inserting stream:repacking texts:texts" ?14:42
vilasven_sandberg: the longest ones should be chk and texts, IIRC texts came after chk, if you don't sign your revisions (I think you don't), that should be the last long step14:44
sven_sandbergvila, good. yes, it already went through chk. so that's good news. thank you!14:44
vilasven_sandberg: right, just repacked by bzr repo, that should be it14:44
=== Meths_ is now known as Meths
vilasven_sandberg: can you come back when it's finished to tell us how many packs you end up with and their sizes ?14:46
vilasven_sandberg: oh, and all of that occurs without mounted file systems right ?14:46
sven_sandbergvila, sure14:46
sven_sandbergvila, how do you mean, without mounted file systems?14:47
vilasven_sandberg: the repository is on a local file file system or a mounted one ?14:47
sven_sandbergvila, local14:47
assadcan we collapse all the little revisions into one?14:49
vilaassad: merge ?14:49
assadvila, i made several commits with small changes. i want them to collapse those revisions into one14:50
assadin my own branch14:51
vilaassad: bzr uncommit -r<rev_before_first_commit> ; bzr commit -m 'The whole shebang'14:52
assadvila, thanks14:52
vilaassad: try that in a scratch branch in case you chose the wrong revision14:53
assadvila, ok14:53
LeoNerdOr, branch -r<firstrev>; merge14:53
vilaassad: or do several uncommit and use bzr diff to check14:53
sven_sandbergfullermd, vila, how hard would it be to hack the source to turn off repacking? can i just comment out something?14:53
vilaLeoNerd: He wants to get rid of the commits14:53
LeoNerdHrmm.. Well... merge shoudl show them on the history as a single commit14:54
assadyeah. the revisions are unnecessarily piling up due to small changes and commit14:54
vilaLeoNerd: Agreed, that was my first proposal :)14:54
vilasven_sandberg: not that hard, but the penalty will strike back quickly: you don't want to query 100s of indices14:55
vilasvaksha: I understand that it's blocking you right now, but the next occurrence could be in several weeks or months14:56
vilasvaksha: argh, sorry14:56
vilasven_sandberg: : I understand that it's blocking you right now, but the next occurrence could be in several weeks or months14:56
vilaxchat: stop losing my settings !!!14:57
guilhembivila: sven_sandberg wanted to do an important merge today, he's blocked for hours now waiting for the repack to finish;14:58
vilaguilhembi: I realize that see above, I'm looking...14:58
guilhembihe would be fine with disabling repack, doing his merge, and re-renabling repack after the merge and doing "bzr repack".14:58
guilhembivila: merci beaucoup14:59
vilaguilhembi: An alternative would be to branch outside of the shared repo14:59
vilaguilhembi: work there, and pull the branch back once done14:59
vilasven_sandberg: that should even be doable *while* the repack is going on14:59
guilhembisven_sandberg: so that means15:00
guilhembicd your_shared_repo15:00
guilhembibzr branch first_tree /other/dir/out/of/shared/repo/first_tree # should take a few minutes15:00
vilasven_sandberg: sorry for the Murphy's law striking  :-/15:01
jammorning all15:01
guilhembibzr branch second_tree /other/dir/out/of/shared/repo/second_tree # should take a few minutes15:01
jamhey vila15:01
vilahey jam !15:01
guilhembisven_sandberg: and then15:01
guilhembicd /other/dir/out/of/shared/repo/second_tree15:01
guilhembibzr merge /other/dir/out/of/shared/repo/first_tree15:01
vilajam: what's the fastest way to disable auto-repack ?15:01
vilasven_sandberg: the first tree can stay in the shared repo, the only branch that needs to be outside the repo is the one you want to commit to15:03
vilajam: something like : http://paste.ubuntu.com/451111/ ?15:05
vilajelmer: some mps are harder to land than others.... :)15:08
jamvila: I think you need to do it in the groupcompress repo15:09
jamvila: nm, that would do fine15:09
vilajam: no autopa... ok15:10
jamI'll also note, you should be able to ^C an autopack15:10
jamit will want to do it on the next fetch15:10
jambut I think the data is already present.15:10
jelmervila: :-))15:10
jam(maybe not, I'll check quickly)15:10
jamI take that back, it looks like 'pack-names' isn't saved until after the autopack finishes15:11
vilajam: what do you take back ? 'data is already present' or 'be able to ^C' (the former I think)15:12
jamvila: if you interrupt autopack, it reverts the whole fetch15:13
jampack-names isn't updated until the fetch + autopack is completed15:13
vilamakes sense from the user point of view15:13
sven_sandbergvila ,jam, i can confirm that; i tried to pull, then did ^C when i noticed it's slow, and then it went back to the original state. next time i pull it tries to do the same thing.15:14
vilasven_sandberg: ok , did the workaround unblocked you ?15:15
sven_sandbergvila, i'm tryingi the out-of-shared-repo approach but it's slow. i have now ^C'ed the repack but it's still running (cleaning up?) at 100% CPU15:16
sven_sandbergvila, ok, i the repack stopped now and the 'bzr branch repo out-of-shared-repo' terminated. so i'm ready to do some work now15:17
sven_sandbergvila, jam, fyi, it left a lot of bzr-index-HEXNUMBER files in /tmp/ after i did ^C during repack15:18
vilasven_sandberg: when you'll came back to your shared repo, you can 'bzr pack' before pulling15:22
vilajam: I think the simplest way to address the issue here would be an option to disable autopack on-demand15:23
vilajam: a noisy one that will yell: "Watch out ! I need packing ! Gimme my bzr pack soon !"15:24
vilajam: so sven_sandberg can ^C the autopack and use the option as long as he needs it and issue the 'bzr pack' at the end of the dat15:25
sven_sandbergvila, yes that would be perfect solution for me15:25
thropehi - trying to use bzr+ssh from windows... have the following problem15:29
thropeSSHException: Error reading SSH protocol banner15:29
thropeany ideas? do I need to install anything else for ssh access on windows15:29
thropecould it be the nonstanadard port causing problems?15:30
jamthrope: that looks like it is able to connect to the remote host, but the remote host isn't offering ssh on that port15:30
jamare you sure 2222 is the correct ssh port for that machine?15:30
thropeive had it working with tortoise svn and svn+ssh15:31
thropeand I can connect with putty from the same winows machine on port 2222 (just checked)15:31
thropeoh wait it works now15:32
thropewill it use putty keyagent?15:32
jamthrope: paramiko will, yes15:39
jamvila: any thoughts on the thread timeout issues?15:40
thropecool thanks - i think it was something funny with windows firewall15:40
vilajam: didn't you get my reply ?15:40
jamvila: well, I replied to your reply :)15:40
vilaha, let me check15:41
jamdo you think that the client has legitimately closed the connection, and the server wasn't informed?15:41
jamooh. another interesting possibility. What if on Windows if you read from a closed socket it tells you, but if you read and *then* the socket closes (without any data) you timeout15:42
jam(with the hard 2-min timeout)15:42
vilajam: I think the client closed yes15:42
vilajam: I suspect that the smart server lacks one check I added in my test server which is that the socket returned by accept shouldn't touched at all and the smart server is trying to read anyway which blocks15:43
vilajam: the problem is: during the "serving" phase doing accept() followed by recv() is the normal (and wanted) behavior, but in the "shutdown" phase that should be accept() ; am_I_still_serving() ? then recv() otherwise die15:45
vilajam: doing that ensure there is no racing threads, which left the question: Why didn't the server react to the client closing the socket ?15:46
jamvila: which is my proposed: "if the socket is closed after recv() starts, then it doesn't get informed until after the hard/soft timeout"15:48
vilajam: on windows that is, things works as expected (at least by me :) on lucid/py26, karmic/py2[456]15:48
jamwhich is a complete guess15:48
vilajam: yes, and that's why I thanked you in my first reply :) I was expecting some difference between the smart server and my test server but didn't know which15:49
jjannHi. How do I revert all changes made by a given revision? (ie do something like what 'hg backout' does with mercurial)15:49
jamjjann: bzr merge -r X..X-115:49
macomost recent commit? bzr uncommit15:49
jamjjann: bzr merge . -r X..X-115:50
macoalso, bzr revert15:50
jamthe '.' is significant15:50
vilajam: I've been side-stepped by a combination of lifeless and spiv patches rendering my loom unsusable until I fix some other failures :-.15:50
jjannmaco: no, not most recent, and 'revert' doesn't do that15:50
jjannjam: thanks15:50
vilajelmer: and one more Request for non-PQM managed branch :-P15:55
jelmervila: argh16:08
jelmervila: problem is I'm much more used to submitting lp branches these days16:08
vilajelmer: yeah, yeah, they all say that :)16:09
mhall119hi, I've got a question16:17
mhall119two developers working on a project, can they use bzr+ssh to push/pull from the same location?16:18
mhall119if they have to ssh in as different users?16:18
macomhall119: if theyre on the same team...16:18
macoand the location is a team location16:18
mhall119what do you mean team location?16:19
mhall119I'm not using Launchpad16:19
mhall119just a server with ssh access16:19
bialixmhall119: look at bzr_access script in src/contrib16:21
mhall119or would I be better off using bzr serve?16:21
mhall119where woudl I find this src/contrib?16:22
bialixlook into bzr release tarball16:23
bialixdirectory contrib/16:23
mhall119oh, ok16:23
mhall119I just have bzr installed16:23
marsilainenmhall119: I think that usually unix group permissions are used16:24
marsilainenso you put both developers in the same unix group16:24
mhall119will it create files with g+w?16:25
mhall119because default umask makes them g+r only16:25
marsilainenand then make sure that the group has appropriate permissions to the files16:25
marsilainenyou probably need some special umask, not sure16:25
marsilainenI think it's in the docs somewhere16:25
mhall119hmmm, can you specify a umask for a particular directory?16:25
marsilainenmaybe it needs a 'sticky' bit on the dir at the top of the repository or something16:26
marsilainenI don't know the details, but I believe that's how people do it16:26
mhall119I tried that, that just makes new files belong to the same group, but doesn't give them write access16:26
marsilainenmhall119: "On many unixes setting the permissions of the base directory to 02770 will allow the group to access the repository, and will let the group ownership be inherited when new directories are created underneath."16:27
marsilainenthat was from: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial16:27
mhall119thanks marsilainen16:28
vilamhall119: it would be simpler to use a single user but two ssh keys16:29
marsilainendepends on the situation innit16:30
mhall119well, that didn't work...16:44
mhall119second user doesn't have permission to push changes16:44
marsilainenwell, there is probably something more you need to do then...16:44
Lo-lan-doYou could also play with setfacl16:45
mhall119the problem is that when user1 pushes a new branch, it's rwxr-sr-x on the new directory16:46
mhall119and rw-r--r-- on the files that it creates16:47
marsilainenmhall119: this looks like a howto of sorts: http://profarius.com/content/creating-your-own-bazaar-server16:47
mhall119looks like all the same steps I did16:49
Lo-lan-doYou need either umask 002 or some acls.16:50
mhall119but can I umask only that directory?16:50
Lo-lan-doNope, umask is a property of a process.16:51
Lo-lan-doIt's generally set by the shell.16:51
mhall119and, since I"m using ssh, it'll have to be set on my users16:51
Lo-lan-doRight.  Or you could write a bzr wrapper that calls umask then bzr.16:52
=== beuno is now known as beuno-lunch
ovnicrafthi folks, i am trying update my repos from lp, so i have this error http://pastebin.ca/188515417:22
ovnicraftsays maybe a bug in bzr17:22
jelmerovnicraft: can you please file a bug against bzr with as much info as possible?17:25
jelmerovnicraft: it does indeed look like a bzr bug of some sort17:25
ovnicrafti see the bug confirmed in bzr gubs17:25
ovnicraftset milestone 2.217:26
ovnicrafti think the bug is really important to people who upgrade 2a version the branchs17:28
ovnicraftmissing references to chk root keys, says the error, itcan be fixed with new set info user in repo or somthing like that?17:29
ovnicrafti need the changes from lp17:29
mhall119okay, i'm just going to make a single user to share17:31
mhall119I don't want to make drastic changes to user's umasks just for this17:31
jelmerovnicraft: sorry, I'm not familiar with the specific bug. You'd probably want to talk to one of the bzr folks17:31
jelmervila: Is your branch hung?17:32
vilajelmer: I don't think so17:33
ovnicraftjelmer, yes i see the bug info en is pointed to 2.2 release maybe talk with bzr folks can help to fix now or help to fixe17:33
mmestnikHello, I'm working with bzr over samba and there was a problem calling chmod.17:41
mmestnikI've asked in #python about the syntax.17:42
dickelbecknewbie could use a little help17:44
dickelbeckThere exists lp:kicad and I have a local branch of it I have been working on.  1) Edit, 2) commit locally, 3) merge17:47
dickelbeckmerge said "nothing to do".  Now how do I get my changes back into lp:kicad.  Do not want to submit a patch.17:47
jelmerdickelbeck: you could push back into lp:kicad if you have that permission17:48
jelmerdickelbeck: alternatively, you can submit a merge proposal so the maintainers of lp:kicad can merge your changes17:49
jelmerdickelbeck: you can create a merge proposal by pushing your local branch to Launchpad and then proposing that branch for merging17:49
dickelbeckI do. I *am* basically a main maintainer.17:49
dickelbeckBut I do not yet have bzr experience beyond the initial push I did to establish the launchpad branch.17:50
jelmerdickelbeck: in that case you should be able to "bzr push lp:kicad"17:50
rom1i think you take the merge command in the wrong direction17:50
dickelbeckNow you say I can use push again.17:50
rom1merge means merge from and not merge to17:50
dickelbeckrom1: I understand that about merge.  There were no recent changes in remote branch.17:51
jelmerdickelbeck: so you should indeed just be able to push to the remote branch17:51
dickelbeckBut the answer to my question is that I need to use push now, correct?17:51
jelmerdickelbeck: yep17:51
rom1if you have modifications on the remote branch, the push command will tell you about it, and you will have to do a merge17:52
rom1before repushing17:52
dickelbeckthanks, you guys are very helpful.  It is done.  Now I will run for cover.17:53
jelmervila: is pqm slower than it used to be?17:53
mmestnikI know this isn't the best way to submit a patch, though it dosen't do anything...17:54
vilajelmer: depends, it now runs all the tests instead of stopping at first failure for example17:55
mmestnikThis helps with using bzr over a samb mount by protecting the chmods from causing unwanted trouble.17:55
mmestnikThe next issue is something I can't work out... however if any one would like to feed me with patches I'd test them.17:56
jelmermmestnik: is this with unix extensions enabled on the samba side?17:56
mmestnikI'm un-aware of how the server is configured.17:56
jelmermmestnik: with unix extensions enabled the chmod should work17:56
mmestnikjelmer: It would be nice if bzr could work around any problematic server/client configuration.17:56
mmestnikThere are other filesystems that would choke on a chmod so that solution is incomplete.17:57
jelmermmestnik: the chmod is there for a reason though, I presume to prevent files that are private from becoming accessible to other users during merge17:58
mmestnik...and on file-systems that fail the chmod it's irrelevant.17:58
mmestnikHence the failed chmod ;)17:58
vilaI'm off17:59
jelmervila: have a nice evening17:59
vilammestnik: did you try running the test suite with your patch ?17:59
mmestnikIt's a nice gesture to try and make it accessible, but it's not essential.17:59
jelmermmestnik: well, in those situations we would have to use whatever semantics are available on those file systems17:59
mmestnikIt still failed with the patch.17:59
mmestnikjelmer: Ahh, it's already done 4 you... nothing to do, no operation.18:00
mmestnikLook if chmod says "this bit does not exists" there there is no point in continuing to attempt to access this bit.  vfat won't have more then one read-only flag.18:01
vilammestnik: bzr doesn't expect the local file system to be too exotic but runs on windows, so there may be corner cases where we do things on windows but not on unix with a windows mounted file system18:01
jelmermmestnik: ? Windows has its own security semantics and it can't guess what permissions you want it to have18:01
* vila really off18:01
jelmervila: the cifsfs used to mount remote windows file servers doesn't support chmod unless the server does18:01
mmestnikchmod is chmod.  It's the tool to work with those permissions.18:01
mmestnikAfter the chmod thee is nothing more for you to  do.18:02
jelmermmestnik: on windows those things work with nt acls18:02
mmestnikThis is not windows and it's up to the ntfs driver to sort converting chmod into nt acls, the application should remain ignorant.18:03
jelmermmestnik: what does ntfs have to do with it?18:03
mmestnikWhat does windows have to do with it?18:04
jelmermmestnik: SMB exposes windows semantics over the wire18:04
jelmermmestnik: if the remote side is running Samba then it can be configured to support chmod's and the cifsfs/smbfs module will know to send it unix modes18:04
jelmermmestnik: if the server doesn't support that it will basically claim to not support any mode changes at all18:05
mmestnikI'm just saying that the chmod is there for conveyance, it's failure can for the most part be safely ignored until a user discovers otherwise.18:06
jelmermmestnik: I disagree, data privacy is not opt-in.18:07
mmestnikUsing samba(or anything else that dosn't have chmod) is an opt-out of data privacy.18:08
jelmermmestnik: we could allow configuring Bazaar to ignore failed changes of file permissions, but it should not be the default.18:08
mmestnikThat sounds reasonable.  Still the issue is after this patch there are other problems.18:08
jelmermmestnik: what sort of issues?18:09
=== beuno-lunch is now known as beuno
LabMonkeyI'm trying to follow http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html and I keep getting 403 when I browse what should be the root containing all repos.18:14
LabMonkeyAny help?18:15
mhall119does anyone know if the bzr for windows standalone installer comes with an ssh client?18:19
jelmermmestnik: right, it's also not possible to do atomic renames18:22
jelmermmestnik: bzr currently relies on the platform to find out what semantics to expect, it should probably look at the particular fs more18:26
mmestnikWhat link should I send to my samba admin to enable the chmod stuff at least?18:27
mmestnikI think it should be generically written to try a feature(like atomic renames) and then fall back gracefully.18:29
mmestnikI understand that that might involve back tracking a few steps, so perhaps there should be a "We are just testing this filesystem" step.18:29
mmestnikThe application should be able to handle features being removed dynamically.18:30
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
luke-jrSHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0x927cf0c> corrupt: sha-1 of reconstructed text does not match expected sha-1. key ('svn-v4:f396537e-aa06-0410-a58a-90fff5392f0b:vxmlb/branches/Log4perl:3083',) expected sha 061b82af5d2a9435f0ea59b57e87573d4eccc784 actual sha 33977d3efbed4d55aca8bc7208838e850b5fc64719:30
luke-jrhelp? :(19:30
beunoluke-jr, knit?19:32
beunothat's like a 100 year old branch, right?19:33
beunoanyway, try bzr check and brz reconcile19:33
beunootherwise, we'll need jam or some other low-level guru19:33
luke-jrbeuno: dunno how old...19:37
luke-jrI suspect it may actually be corrupt19:38
tsmithis there a way to convert a bzr branch to svn?20:00
jelmertsmith: if you have bzr-svn installed you can push into svn20:01
tsmithok i try that20:01
tsmith$ bzr push svn://localhost/user_directory --overwrite20:02
tsmithbzr: ERROR: Permission denied: "."20:02
tsmithuser_directory is a brand new svn repo w/ 0 commits20:02
tsmithany idea?20:03
tsmithjelmer, any idea?20:03
assadhow to do a "review approve" and "merge approve" through the launchpad ticket interface? it is available through the email service but what about the ticket interface on launchpad for merge approve?20:04
jelmertsmith: you can't push to a svn:// URL usually20:05
tsmitho awesome20:06
tsmiththanks man20:06
jelmertsmith: Not with svn itself either I mean20:07
jelmertsmith: You'll need svn+ssh://, file:// or http://20:07
tsmithfile:// worked20:08
lifelessassad: what do you mean 'ticket interface'20:13
lifelessassad: can you give us an example url ?20:13
assadhttps://help.launchpad.net/Code/Review#Proposing%20a%20merge lifeless20:13
assadminus the email interface on that page20:13
lifelessthats the docs20:13
lifelessI mean a url of a merge proposal you are having trouble with20:13
assadlifeless, https://code.launchpad.net/~zubairassad89/sahana-eden/vms/+merge/2769720:14
lifelessok, on that page if you fill in the 'Add comment' box and set the 'Review' field below it to a value, then click save comment20:15
lifelessit will do a review - and you can use that to set your review to approve or needs fixing or whatever.20:15
lifelessthats the 'review approve' in the web UI20:15
lifelessthe 'merge approve' in the web UI is via a edit icon to the right of the 'Status: Approved' at the top of the page.20:16
assadlifeless, ok20:16
assadlifeless, thanks20:21
lifelessno problem, hapy to help20:22
jamhi lifeless21:49
jamInteresting attempt of a DAVE swarm. Another person worked me over overnight with waves of Finks, and did a pretty decent job of taking out a few of my outer resources.21:51
jamI did notice that direct assault seemed to only be able to damage 1/2 a tower in a given wave, which seems pretty good. When attacking others I usually shoot for 1-2 towers on the first waves, (obviously more on later waves)21:52
bitdancerWhat are these files that end with things like ~1~ in my checkout?23:17
bitdancerOr, rather, I know what they are (old copies of files), but why are they created?23:17
bitdancerAnd how do I get rid of them? :)23:18

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