| davidstrauss | what is the fake shell used for locking down bzr access? | 00:04 |
|---|---|---|
| davidstrauss | i know there's a popular one | 00:04 |
| lifeless | savanah use a thing called rsh | 00:08 |
| lifeless | not your grandfathers rsh | 00:08 |
| lifeless | there is a contrib/ script in bzr's source tree too | 00:09 |
| jbowtie | I seem to have an issue where the repository is lying to me about its contents. | 00:40 |
| jbowtie | Specifically, repository.has_revisions() is returning a revision that I'm pretty sure is not in the repository. | 00:40 |
| jbowtie | This is a probably a result of a bug in my plugin, but I don't know how to debug it. | 00:41 |
| lifeless | well | 00:41 |
| lifeless | are you accessing the repo via a stacked branch ? | 00:41 |
| jbowtie | No, it's a normal branch. Possibly its not correctly reflecting the repository contents however. | 00:43 |
| lifeless | can you share a bit more context about what your plugin wants to do and whats going on | 00:44 |
| lifeless | ? | 00:44 |
| jbowtie | Sure, it's a plugin for using Team Foundation Server as a foreign VCS. | 00:46 |
| jbowtie | I've had import working for a while and have been working on getting round-tripping viable. | 00:47 |
| jbowtie | So I pushed some revisions into TFS last night, pushed another one this morning. | 00:47 |
| jbowtie | In between there were some updates, (about 18 revisions or so) | 00:48 |
| lifeless | awesome | 00:48 |
| jbowtie | Attempting to pull those revisions however, says "nothing to pull". | 00:48 |
| jbowtie | Normally I just call target_repository.has_revisions with the list of revision ids from the source repository. | 00:49 |
| jbowtie | But the target is telling me that it has those 'missing' revisions even though that's pretty likely to be false. | 00:50 |
| lifeless | so | 00:50 |
| lifeless | the target is a bzrlib native repo | 00:50 |
| lifeless | the source is TFS accessed via your plugin | 00:51 |
| jbowtie | Correct. | 00:51 |
| lifeless | the revisions you want to fetch are the new ones in TFS | 00:51 |
| jbowtie | Yes. | 00:51 |
| lifeless | in the target | 00:51 |
| lifeless | you can do | 00:51 |
| lifeless | bzr cat-revision -r revid:<revision id> | 00:51 |
| lifeless | to quickly get at a revision from the command line | 00:51 |
| lifeless | poolie: are you still caring for the kanban board? | 00:53 |
| jbowtie | lifeless: Hmm.... ERROR: u'revision' is not present in revision | 00:55 |
| lifeless | you have a revision called revision ? | 00:55 |
| jbowtie | No, sorry, I ommitted the actual revision id at the end of error message. | 00:56 |
| lifeless | so bzr doesn't think its there | 00:56 |
| lifeless | if you open up python | 00:56 |
| lifeless | and do from bzrlib import repository | 00:56 |
| lifeless | target = repository.Repository.open('pathtorepo') | 00:56 |
| lifeless | target.lock_read() | 00:56 |
| lifeless | target.has_revisions(....) | 00:56 |
| lifeless | you can see what is going on a bit more closely | 00:57 |
| jbowtie | I 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 |
| jbowtie | Thanks for pointing out cat-revision, that should help with investigating. | 00:59 |
| lifeless | poolie: you might like http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/ | 01:06 |
| jbowtie | lifeless: Heh, I typed "cat revision" earlier instead of 'cat-revision'. | 01:15 |
| jbowtie | So the missing revisions are in the bzr repository, but aren't reflected in the corresponding branch. | 01:16 |
| lifeless | ok | 01:16 |
| jbowtie | So 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 |
| lifeless | well | 01:21 |
| lifeless | branches have a single tip | 01:21 |
| lifeless | what is the tip revision of your bzr branch | 01:21 |
| jbowtie | Is there an easy way to get that from the command line/ | 01:24 |
| spiv | Branch history is different to the repository. A revision can be in the repository but not in the branch's ancestry. | 01:24 |
| lifeless | bzr revision-info | 01:24 |
| lifeless | or | 01:25 |
| lifeless | bzr log -r -1 --show-ids | 01:25 |
| jbowtie | The tip's what I expect, the last revision that was pushed. | 01:26 |
| lifeless | right | 01:26 |
| lifeless | so you've pushed something | 01:26 |
| lifeless | now | 01:26 |
| lifeless | tell me what happens in TFS | 01:27 |
| lifeless | if you push something | 01:27 |
| lifeless | and someone else pushes stuff after | 01:27 |
| lifeless | do they have to merge your thing first | 01:27 |
| lifeless | or does the TFS server merge for them | 01:27 |
| lifeless | or is TFS not distributed | 01:27 |
| lifeless | so it actually just counts new work as new commits | 01:27 |
| jbowtie | TFS isn't distributed. | 01:27 |
| jbowtie | OK, 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 |
| lifeless | push 2 probably shouldn't have succeeded | 01:32 |
| lifeless | because you haven't incorporated the content of the other changes | 01:33 |
| lifeless | what 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 suceed | 01:33 |
| jbowtie | lifeless: Exactly. | 01:35 |
| lifeless | still | 01:36 |
| lifeless | it sounds like you've got an impressively close system there | 01:36 |
| jbowtie | Thanks, just waiting on legal to approve putting it on Launchpad. | 01:38 |
| lifeless | \o/ | 01:38 |
| jbowtie | So is there a way to 'fix' my branch history? | 01:42 |
| lifeless | well | 01:42 |
| lifeless | this is the risk when buliding foreign interfaces :) | 01:43 |
| lifeless | the revids are uuids | 01:43 |
| lifeless | so their meaning is pretty hard to change | 01:43 |
| lifeless | its why svn ones are hashes | 01:43 |
| lifeless | (and so are git and hg ones) | 01:43 |
| jbowtie | Well, 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 |
| lifeless | I can think of two routes | 01:44 |
| spiv | lifeless: did you get a failure from pqm for the socketpair patch? Or should I send it myself and receive a failure directly? :) | 01:44 |
| lifeless | do a manual merge - 'bzr merge -r revid..revid .' of the things that god skipped over | 01:44 |
| lifeless | spiv: oh, we nuked the merge queue | 01:44 |
| lifeless | about 11 | 01:44 |
| lifeless | so please send | 01:44 |
| spiv | Ah, I thought I'd seen you say you'd requeue. Will send. I assume PQM is all happy now? | 01:45 |
| lifeless | I was | 01:46 |
| lifeless | then the u1 pqm claimed to have blown up | 01:46 |
| lifeless | so I was up to 1:30 getting a handle on that and forgot | 01:46 |
| lifeless | sorry | 01:46 |
| spiv | That's ok :) | 01:46 |
| lifeless | jbowtie: then when you commit that merge you'd end up with what TFS has and after that it would be all ok | 01:46 |
| lifeless | jbowtie: alternatively, you could nuke your repo and pull fresh from TFS | 01:46 |
| jbowtie | lifeless: 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 |
| jbowtie | lifeless: 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 |
| poolie | lifeless, hi, yes i still care for and about the kanban board | 02:54 |
| lifeless | poolie: I was asking because it seemed a little stale | 03:07 |
| poolie | any bit in particular? | 03:12 |
| lifeless | you and spiv seem to be looking at fetch perf | 03:25 |
| lifeless | not jam and I | 03:25 |
| lifeless | I've hesitated to take my name off that; I have updated the pqm and loom branching stuff as it progressed | 03:25 |
| poolie | mm i don't know if single user assignment is a good match | 03:25 |
| poolie | perhaps we should have it unassigned | 03:26 |
| lifeless | I think from mary's perspective yes - team accountability | 03:26 |
| poolie | also their ui fails unless you have a gravatar attached to your canonical email address | 03:26 |
| lifeless | thats odd | 03:27 |
| poolie | not fails as in crashes, just fails to be very useful | 03:27 |
| lifeless | yes, I got that ;) | 03:28 |
| lifeless | its odd that they'd not cater for people wanting private photos ;) | 03:28 |
| poolie | mm | 03:29 |
| lifeless | anyhow, I like the brevity of kanban | 03:30 |
| lifeless | I was hoping it was just a little stale and not given up on | 03:30 |
| lifeless | which it was/is - so thats great. | 03:30 |
| poolie | i like the brevity too | 03:31 |
| poolie | i don't love this specific ui | 03:31 |
| poolie | it seems a bit slow and klunky | 03:31 |
| lifeless | I'm moving some things that appear stalled into backlog | 03:31 |
| lifeless | shout if you think thats wrong, and I'll put em back | 03:32 |
| lifeless | done | 03:33 |
| poolie | spiv did you manually test the socketpair thing? | 04:00 |
| spiv | I did. | 04:00 |
| lifeless | does inetd use pipes or socketpairs | 04:01 |
| lifeless | and more broadly | 04:01 |
| lifeless | should we file a bug on launchpad-code to use socketpairs | 04:01 |
| poolie | neither, inetd directly connects the server to the socket | 04:01 |
| spiv | inetd uses neither | 04:01 |
| lifeless | or less broadly | 04:01 |
| lifeless | entirely unrelatedly | 04:01 |
| lifeless | should we make sure launchpad-code connects its twisted daemon that is doing ssh with the subprocess bzr via a socketpair | 04:02 |
| poolie | bug 595331 classic title :) | 04:02 |
| ubot5 | Launchpad bug 595331 in QBzr "All button blows up (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/595331 | 04:02 |
| poolie | see the problem is | 04:02 |
| poolie | you should be pushing the Any button | 04:02 |
| spiv | Heh :) | 04:02 |
| lifeless | I can't find the Any key | 04:02 |
| poolie | spiv, lifeless, you can get decent coverage of this kind of thing by running it under wine | 04:03 |
| poolie | ah, i guess it would depend on having an external ssh accessible under wine | 04:03 |
| poolie | but that should be possible | 04:03 |
| poolie | 'this kind of thing' meaning will it blow up without socketpairs on windows | 04:03 |
| spiv | Well, in this case you can temporarily hack in "import socket; del socketpair" too | 04:04 |
| spiv | er, "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 |
| lifeless | I find it interesting | 04:06 |
| lifeless | that all of (me, jam, poolie) have immediately assumed there are going to be issues validating/working on windows ;) | 04:06 |
| lifeless | and that spiv seems to have taken them all into consideration | 04:06 |
| lifeless | :) | 04:06 |
| poolie | mm | 04:06 |
| poolie | i was commenting more in response to john's review | 04:07 |
| poolie | i don't anticipate there being platforms that have the python module but not the feature | 04:07 |
| poolie | though it probably can happen | 04:07 |
| lifeless | sure | 04:07 |
| lifeless | you may have missed it | 04:07 |
| lifeless | but I grilled spiv about windows last night | 04:07 |
| lifeless | with a similar sort of angle to the questions | 04:08 |
| lifeless | for all that they were different | 04:08 |
| lifeless | I'm not offering any conclusion, I just found this an interesting thing | 04:08 |
| spiv | Well, it's a good habit to ask "what about Windows", because we don't get as much automatic testing there. | 04:09 |
| poolie | anyhow | 04:10 |
| poolie | winepython++ | 04:10 |
| poolie | if in doubt just run it | 04: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 |
| poolie | you may not be able to easily/quickly run the whole suite but you can fairly easily run one module of tests | 04:10 |
| poolie | i often do that | 04:10 |
| spiv | Good idea, thanks for the reminder :) | 04:10 |
| lifeless | wine is amazingly good these days | 04:12 |
| poolie | mm pinot | 04:12 |
| lifeless | did you see the http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/ link ? | 04:15 |
| poolie | lifeless, i did, and that makes sense | 06:18 |
| poolie | one thing i would add is that tests can become write-once | 06:19 |
| poolie | ie they're there, they pass, you don't want to break them but you also may not often actually improve them | 06:19 |
| poolie | i don't think shell-like tests are the ultimate but that patch definitely made the tests cleoaner | 06:20 |
| poolie | i'd like to work out how to test tribunal | 06:20 |
| poolie | what kind of tests would be most useful | 06:20 |
| parthm | lifeless: ping | 06:52 |
| poolie | hi parthm | 06:58 |
| lifeless | parthm: hi | 06:58 |
| parthm | hi poolie, lifeless | 06:58 |
| lifeless | poolie: tests that catch bugs ;) | 06:58 |
| parthm | lifeless: 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 you | 06:59 |
| parthm | thats the only thing pending on that patch now before i can put it for review | 07:00 |
| poolie | lifeless, mm i might wait until i have an idea of typical bugs and then see what to do | 07:00 |
| poolie | at the moment most of them are lack of understanding of how something will interact with gtk | 07:01 |
| vila | hi all | 07:03 |
| parthm | vila: hi | 07:05 |
| lifeless | parthm: I'm easy either way | 07:12 |
| lifeless | parthm: we can always change our mind later | 07:12 |
| parthm | lifeless: sounds fine. I will put it for review with the current value of 30s. thanks. | 07:13 |
| assad | is thr any software which could show differennt revisions side by side. something like meld. | 07:14 |
| lifeless | assad: you can use meld | 07:19 |
| spiv | assad: well, you could always use meld :) But there's also 'bzr qdiff' (from the qbzr plugin), for instance. | 07:19 |
| poolie | hi vila | 07:20 |
| parthm | assad: also, bzr diff --using=meld ... you can set up an alias if you use it frequently. | 07:22 |
| assad | ok thank you guys | 07:23 |
| poolie | lifeless, did my 'gnuness' branch bounce? | 07:30 |
| vila | poolie: hmm, I forgot that one, no probably it get killed when pqm was wipped | 07:30 |
| vila | s/no/no,/ | 07:31 |
| lifeless | poolie: when did you submit it | 07:31 |
| poolie | you did, 20 hours ago | 07:31 |
| lifeless | ok | 07:31 |
| lifeless | no, it got zapped | 07:31 |
| vila | lifeless: pretty sure it was just after I submitted the broken one that got cancelled | 07:31 |
| === radoe_ is now known as radoe | ||
| lifeless | cleared out the stuff I'd submitted when the base64 thing was noticed | 07:32 |
| lifeless | there was some confusion about who was resubmitting | 07:32 |
| lifeless | That is, I was confused, noone else stood a chance ;) | 07:32 |
| lifeless | vila: oh hai | 07:33 |
| lifeless | vila: my loom support branch | 07:33 |
| poolie | ok, re-sent | 07:33 |
| lifeless | vila: please check the most recent commit on it; minor stuff | 07:33 |
| vila | lifeless: on bzr ? loom ? both ? | 07:34 |
| lifeless | oh, as soon as I push it | 07:34 |
| lifeless | bzr/loomsupport | 07:34 |
| lifeless | has an open, approved mp | 07:34 |
| lifeless | I want to land a little bit more. | 07:34 |
| lifeless | ok, should be there now | 07:34 |
| lifeless | vila: rev 5299 | 07:35 |
| lifeless | vila: loom trunk has its stuff already | 07:35 |
| vila | lifeless: updating diff | 07:35 |
| lifeless | vila: just diff -c lp:~lifeless/bzr/loomsupport ;) | 07:36 |
| lifeless | vila: I'm asking for incremental | 07:36 |
| vila | lifeless: updating, ooooh upstream up to thread.... Thanks abentley !! | 07:37 |
| vila | lifeless: 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 |
| vila | s/upstream/up-thread/ silly typo | 07:38 |
| lifeless | vila: I'm rather tired after last night | 07:40 |
| lifeless | vila: my tomorrow first thing I'd be delighted to discuss it more | 07:40 |
| vila | lifeless: ok, no problem, I wanted to ask for some time but keep missing the right window | 07:41 |
| lifeless | vila: so, the loomsupport change is ok ? | 07:48 |
| vila | lifeless: yup, except for the NEWS entry order | 07:48 |
| lifeless | vila: whats wrong with the NEWS entry order? | 07:48 |
| vila | 'branch' < 'knit' | 07:49 |
| vila | no ? | 07:49 |
| lifeless | oh | 07:49 |
| lifeless | I was asking for the incremental change to be reviewed | 07:49 |
| lifeless | not the entire branch | 07:49 |
| lifeless | I will fix that | 07:49 |
| lifeless | but it would have saved you some time :) | 07:50 |
| vila | the incremental change seemed obscure at first glance s//from_/ :) | 07:50 |
| lifeless | ok | 07:50 |
| lifeless | I wonder if diff -c should show the commit message too | 07:50 |
| spiv | webnumbr.com is really cute | 07:55 |
| vila | lifeless: 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 much | 07:55 |
| mlh | spiv: nice! the big G had something similar but the sources were (much) more constrained | 07:56 |
| lifeless | vila: i think being able to do default format stuff is good too | 07:56 |
| vila | lifeless: sounds perfectly reasonable | 07:57 |
| spiv | The interface for creating a graph is quite neat, and the API is pretty cute too. | 07:57 |
| mlh | rrd graph would be good as well | 07:57 |
| mlh | but it is a good api | 07:57 |
| vila | lifeless: I was speaking as a lazy reviewer not as a pedantic tester :-) | 07:58 |
| mlh | suggestion submitted | 07:59 |
| * mlh goes back to work | 07:59 | |
| lifeless | spiv: hmmm, open bugs in bzr, boom. | 08:07 |
| lifeless | as in , should be trivial | 08:07 |
| lifeless | though | 08:09 |
| lifeless | hah | 08:09 |
| lifeless | the ajax d-feats it | 08:09 |
| vila | parthm: you didn't pushed your latest changes, but my last vote was tweak anyway, so please land | 08:09 |
| parthm | vila: the diff shows the latest. anything missing? | 08:12 |
| spiv | lifeless: yeah, you have to be cunning :/ | 08:12 |
| lifeless | I've filed a ticket | 08:12 |
| parthm | vila: i will land it. thanks for the review. | 08:12 |
| spiv | lifeless: | 08:12 |
| spiv | http://webnumbr.com/bzr-in-progress-bugs | 08:12 |
| spiv | Heh, 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 |
| vila | parthm: weird, sorry for the noise, I didn't see the push in the mp comments and didn't check the diff itself | 08:15 |
| vila | parthm: well, I meant, I *still* don't see the push in mp comments :) | 08:15 |
| vila | spiv: growth ! growth ! That's the only important thing ! | 08:16 |
| parthm | vila: 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 |
| vila | parthm: no worries | 08:17 |
| parthm | vila: or maybe a feature for wip :) | 08:18 |
| vila | parthm: features like that are bugs :) | 08:19 |
| vila | parthm: can file one against lp-code ? | 08:19 |
| * vila insert 'you' above | 08:19 | |
| parthm | vila: will do. | 08:19 |
| vila | hmm, almost aligned ;) | 08:19 |
| parthm | vila: bug #595392 .. feel free to add to it in case i have missed out something. | 08:33 |
| ubot5 | Launchpad 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/595392 | 08:34 |
| vila | parthm: perfectly clear :) | 08:35 |
| === assad is now known as assad|lunch | ||
| RunePhilosof | poolie, could you please take a look at bug 367545 again. | 09:18 |
| ubot5 | Launchpad bug 367545 in Bazaar "Huge memory usage for bzr branch/checkout (affected: 5, heat: 21)" [High,Confirmed] https://launchpad.net/bugs/367545 | 09:18 |
| bialix | heya bzr | 09:43 |
| bialix | bonjour vila | 09:43 |
| vila | bialix: privet Sacha :) | 09:45 |
| bialix | :-) | 09:46 |
| bialix | vila: I'm about to tweak right now | 09:46 |
| bialix | my I beg you to land that patch then? | 09:46 |
| bialix | s/my/may/ | 09:46 |
| vila | bialix: sure, push your changes and ping me | 09:47 |
| bialix | ok | 09:47 |
| vila | bialix: I wasn't sure you had a working pqm setup | 09:48 |
| bialix | vila: I don't have one | 09:48 |
| bialix | and poolie latest patch infers I should use Hydrazine | 09:48 |
| bialix | I'm afraid of this beast | 09:48 |
| jszakmeister | anyone seeing crazy memory usage during a pack operation? | 09:51 |
| jszakmeister | Right now, it's looking like 17.5x-20x the file size when repacking texts. :-( | 09:52 |
| vila | jszakmeister: crazy is too subjective :-/ | 09:52 |
| vila | size of which file ? The biggest pack ? | 09:52 |
| jszakmeister | I'm re-creating a problem that we saw with another repo... | 09:53 |
| jszakmeister | I'm using a single file, file.bin, and completely changing it's contents every commit... | 09:53 |
| jszakmeister | and it has 100m of binary data in it. | 09:53 |
| jszakmeister | It *seems* to be relative to the size of that file. | 09:54 |
| vila | AFAIK repack shouldn't consume insane amount of memory anyway, commit is still about ~x3 IIRC | 09:54 |
| jszakmeister | Yeah, that's what I thought too... but it's definitely real high when repacking texts. :-( | 09:55 |
| vila | jszakmeister: so what is the peak memory ? 2GB ? | 09:55 |
| jszakmeister | Yeah, depending on when the process gets sampled, I see anywhere from 1.75 to 2.0GB. | 09:56 |
| vila | I know jam has some way to track this but I don't remember if there is an env variable for that | 09:56 |
| vila | checking with him later in the day seems the best option | 09:56 |
| jszakmeister | For 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 |
| bialix | vila: ping-ping, ring a bell :-) code tweaked, bzr.dev merged, news conflicts resolved, pushed to lp. ready to land! | 09:57 |
| jszakmeister | vila: For max memory consumption you mean? | 09:57 |
| jszakmeister | That'd be helpful if he does! | 09:57 |
| vila | bialix: sent to pqm | 09:59 |
| bialix | :-)- | 09:59 |
| vila | jszakmeister: yes | 09:59 |
| vila | jszakmeister: and even a plugin (meliae) to investigate | 09:59 |
| jszakmeister | Neat. BTW, that figure was the "real memory" used. I think the actual VM size is larger. | 10:03 |
| bialix | vila: commit message slightly out-of-date, sorry, I forgot about it | 10:04 |
| vila | bialix: ? Show unicode filenames in diff headers using terminal encoding sounds fine to me | 10:06 |
| bialix | no more "on Windows-only" | 10:08 |
| vila | ha, rats, well the NEWS entry is correct, that's the most important | 10:12 |
| bialix | okay | 10:15 |
| * bialix bbl | 10:26 | |
| raphink | Hi there | 10:56 |
| raphink | when setting up a shared repository with bzr, I put a 02770 right on the top folder | 10:56 |
| raphink | now 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 directory | 10:57 |
| raphink | is there a way to do this? | 10:57 |
| fullermd | What do you mean by 'add directories'? As in push in new branches? | 10:58 |
| raphink | yes | 10:58 |
| raphink | or just add a directory inside a branch | 10:58 |
| fullermd | Yeah, I'm pretty sure bzr doesn't have any builtin support for inheriting permissions like that. | 10:59 |
| raphink | well I think this has to be done using unix permissions | 10:59 |
| fullermd | It does for stuff under .bzr/, but new bzrdirs, not so much. | 10:59 |
| raphink | CVS seems to force the permission inheritance when adding a directory with "cvs add" | 10:59 |
| fullermd | In the working tree? I'm pretty sure it doesn't... | 11:01 |
| raphink | well I just tried | 11:02 |
| raphink | I have a repository in /cvsroot/test | 11:03 |
| raphink | when I do a "mkdir /cvsroot/test/toto" , it gets drwxr-sr-x | 11:03 |
| raphink | but if I do it with cvs add | 11:03 |
| raphink | it gets drwxrwsrwx | 11:04 |
| fullermd | That's in the repository, not the WT. | 11:04 |
| raphink | well CVS add works directly in the repository, for sure | 11:04 |
| fullermd | bzr 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 |
| raphink | my 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 dir | 11:04 |
| raphink | when you say inside the repo, you mean locally? | 11:05 |
| fullermd | Wherever a repo is touched. | 11:05 |
| raphink | say, in bzr, I do a branch of my repo | 11:05 |
| * fullermd thinks we're talking past each other... | 11:05 | |
| raphink | I do a bzr add on a directory | 11:06 |
| raphink | and I commit it | 11:06 |
| raphink | then I push it back to the parent branch | 11:06 |
| raphink | I 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 it | 11:06 |
| fullermd | It will if the repo has perms right. bzr WILL inherit those perms on new pack files etc. | 11:06 |
| fullermd | At 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 |
| raphink | you mean you have a hook on the server to do that? | 11:08 |
| fullermd | No, 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 |
| raphink | ok | 11:09 |
| raphink | let me see | 11:09 |
| raphink | thank you for your help already fullermd | 11:11 |
| raphink | hmm I just tried again | 11:14 |
| raphink | the whole repo is g+w and g+s | 11:15 |
| raphink | it's a shared repository | 11:15 |
| raphink | I'm pushing back my branch | 11:15 |
| raphink | which ends up in $reporoot/branches/mynewbranch | 11:15 |
| raphink | and it doesn't inherit g+w | 11:16 |
| fullermd | Paste a ll of the file? | 11:17 |
| raphink | drwxr-sr-x 3 rpinson scm_spp 4,0K 2010-06-17 12:14 testraphink | 11:17 |
| raphink | and the parent dir is | 11:17 |
| raphink | drwxrwsr-x 166 rchalumeau scm_spp 12K 2010-06-17 12:14 /cvsroot/spp/sppcpp/.bzrroot/branches/ | 11:17 |
| fullermd | OK, so we're talking past each other. | 11:18 |
| raphink | what do you mean? | 11:19 |
| fullermd | bzr preserves perms on files inside the repo, like [...]/.bzr/repository/packs/* | 11:19 |
| fullermd | You're talking about perms on a [new] branch, which don't inherit. | 11:19 |
| raphink | yes | 11:19 |
| raphink | so new branches cannot be shared? | 11:19 |
| fullermd | bzr doesn't touch those at all; it's all determined by the system via umask etc. | 11:19 |
| raphink | ok | 11:20 |
| raphink | but if I add a dir in an existing branch, then it will work | 11:20 |
| fullermd | Yes, those are all internal objects in the revision, which get stored in packs in the repo, which bzr DOES set perms on. | 11:20 |
| raphink | alright | 11:21 |
| fullermd | For instance, if instead of pushing a new branch, you'd pushed your changes onto the existing branch. | 11:21 |
| raphink | so then we have to setup shared branches with g+w and use these for merges | 11:21 |
| raphink | for the group | 11:21 |
| raphink | other created branches will remain with individual rights, while these can be used for group purposes, right? | 11:21 |
| fullermd | Generally, 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 |
| fullermd | It's only with relatively transient branches that you still want multiple people writing on that you get into trouble. | 11:22 |
| fullermd | You 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 |
| fullermd | Though 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 |
| raphink | thanks for the clarification | 11:23 |
| raphink | I'm afraid the categories for the devs are not that clear ;-) | 11:24 |
| fullermd | You could setup a cron job to just g+w all the branches under a given dir Every So Often(tm). | 11:24 |
| raphink | ;) | 11:24 |
| fullermd | bzrtools has a 'branches' command, so you could `cd /where/ever && bzr branches | xargs chmod -R g+W` | 11:25 |
| fullermd | Or just forget about subtlety and g+w the entire dir tree under the repo point. | 11:25 |
| rom1 | hi there | 11:26 |
| raphink | fullermd: rom1 is the dev having this issue | 11:26 |
| raphink | :) | 11:26 |
| raphink | I was just proxyfying the conversation | 11:26 |
| raphink | (I'm the sysadmin in charge of the forge) | 11:27 |
| rom1 | hi fullermd | 11:28 |
| rom1 | thx for the tips | 11:28 |
| fullermd | Well, 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 |
| fullermd | Just stick a 'bzr' shell script in some dir ahead of the real bzr in $PATH with contents like umask 002 && /real/bzr "$@" in it | 11:29 |
| raphink | that might be an option, thank you fullermd | 11:33 |
| rom1 | thx a lot fullermd ! now i have to reconsider some stuff in our way of working... | 11:34 |
| fullermd | For 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 |
| fullermd | Reconsideration of working methods is awesome. It LOOKS like real work, but it's way more fun ;) | 11:35 |
| rom1 | sure it is... | 11:35 |
| fullermd | Always an interesting back and forth between adjusting your approach to fit the tool, and adjusting the tool to fit your approach. | 11:36 |
| rom1 | Above all when we have a ten years habit on CVS... It is a really deep change | 11:37 |
| fullermd | Definitely. 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 | |
| rom1 | :D | 11:38 |
| fullermd | But I'm clean now, I swear. I haven't used CVS in, like, days. | 11:38 |
| rom1 | lucky man... [long whisper] | 11:39 |
| vila | raphink: which protocol do you use to push ? | 11:58 |
| raphink | vila: bzr+ssh | 12:11 |
| Lo-lan-do | Hi all | 12:58 |
| Lo-lan-do | I'm getting lots of conflicts when merging a branch after a directory was renamed… | 12:59 |
| Lo-lan-do | Details: 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-do | Is that expected? Can it be avoided? Is it related to the symlink? | 13:01 |
| === bouncingzip is now known as mgz | ||
| spiv | Lo-lan-do: sounds odd, renames like that shouldn't produce lots of conflicts | 13:14 |
| spiv | Lo-lan-do: perhaps the files were deleted and readded by mistake, rather than renamed? | 13:14 |
| spiv | I 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-do | It may be relevant that both branches are bound to an SVN repository. | 13:15 |
| spiv | Ah, I think maybe in that case they do show up as delete/add pairs rather than renames :/ | 13:15 |
| spiv | The 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-do | Right. bzr log -v --long tells me that it's a remove/add indeed :-/ | 13:17 |
| fullermd | You could try a 'status' on the rev that did the move too. | 13:17 |
| marsilainen | hi all | 13:18 |
| marsilainen | I'm pondering the best way to set up my source server | 13:19 |
| Lo-lan-do | fullermd: Same thing. Okay, I'll blame the rename in SVN. | 13:19 |
| Lo-lan-do | Thanks, I'll cope somehow. | 13:19 |
| marsilainen | I'm wondering whether it's best to use bzr, sftp, http, or something else for the transport mechanism | 13:19 |
| marsilainen | am I right in assuming that mostly people use sftp these days? | 13:19 |
| marsilainen | I'm wanting a gatekeeper type of workflow btw | 13:20 |
| Lo-lan-do | marsilainen: /me uses bzr+ssh:// | 13:20 |
| marsilainen | I'd like people to be able to get a branch anonymously though | 13:20 |
| marsilainen | so doesn't that rule out bzr+ssh? | 13:20 |
| Lo-lan-do | You can have the same repo available through both bzr+ssh and http | 13:21 |
| fullermd | Not quite necessarily, though in practice generally. Doesn't mean you can't use bzr+ssh on the writing side of course. | 13:21 |
| marsilainen | so 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 |
| marsilainen | I guess that all sounds sensible | 13:22 |
| Lo-lan-do | What's generally best is to find a way that sticks so your workflow. Many scenarios are possible, pick your preferred one :-) | 13:23 |
| marsilainen | I guess this sort of workflow/scenario is quite common, but I couldn't find a tutorial which went through it | 13:23 |
| marsilainen | anyway, I'll go with that | 13:24 |
| marsilainen | thanks for the help | 13:24 |
| Lo-lan-do | Based 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 |
| marsilainen | ok | 13:25 |
| Lo-lan-do | But you may prefer pushing by hand rather than binding, or using sftp instead of bzr+ssh, or lots of other variants. | 13:25 |
| marsilainen | I don't know what binding is, so I'll have to look into that | 13:25 |
| Lo-lan-do | It's sometimes called heavyweight checkout. | 13:26 |
| fullermd | If bzr+ssh works, you almost certainly will want to use it instead of sftp. Dumb protocols are dumb. | 13:26 |
| marsilainen | ok, so yes, that looks like what I want | 13:29 |
| marsilainen | so, local branch bound to mainline over bzr+ssh, and http access to the same mainline | 13:29 |
| marsilainen | having 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 |
| vila | spiv: Still up ? Have a look at babune, your last patch broke :-/ | 13:32 |
| vila | spiv: more precisely FAIL: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh | 13:36 |
| vila | spiv: which makes me wonder if we trigger another bug in paramiko | 13:36 |
| mgz | maybe just a tyop, vila? | 13:44 |
| mgz | return self._sock.read(count) <- should be recv? | 13:44 |
| mgz | ...doesn't explain how it got past pqm though... | 13:44 |
| vila | mgz: people reading above my shoulder and pretending *they* found the bug are so irritating :-) | 13:45 |
| spiv | mgz: yes, that looks likely | 13:45 |
| * mgz takes all the credit | 13:45 | |
| vila | spiv: indeed, s/read/recv/makes the test pass, tell Vincent you really need to sleep now :) | 13:46 |
| spiv | This is a code path that would only be used with sftp, not bzr+ssh | 13:46 |
| spiv | I'm not sure why that isn't failing on PQM | 13:46 |
| vila | spiv: that's the scary part yes | 13:46 |
| spiv | Perhaps PQM doesn't have paramiko? | 13:47 |
| vila | spiv: that's the scary part yes :-) | 13:47 |
| spiv | vila: so it is indeed my bedtime | 13:47 |
| vila | I'll pqm the fix, feel free to investigate when you wake up | 13:48 |
| spiv | vila: but I "vote approve" the typo fix, and please file a bug about PQM not catching it | 13:48 |
| vila | spiv: I'll do | 13:48 |
| mgz | vila: has jam's observation about _probe_bzrdir got you anywhere new with the leaking tests? | 13:57 |
| vila | mgz: 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 |
| vila | mgz: the hangs themselves are due to my incomplete modifications | 13:59 |
| vila | mgz: I need to roll them back and restart with the new test server infra | 14:00 |
| sven_sandberg | hi! 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_sandberg | the status message is currently 'Fetching revisions:Inserting stream:repacking texts:texts 242291/637888' | 14:00 |
| sven_sandberg | other people tried the same pull without problems | 14:01 |
| sven_sandberg | any idea what is going on? is my local repository broken? | 14:01 |
| mgz | vila: 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 flag | 14:01 |
| vila | sven_sandberg: this sounds like a conversion happening on the fly | 14:01 |
| fullermd | No, it's repacking. That can take a while if it's a big repository... | 14:01 |
| sven_sandberg | fullermd, 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 |
| mgz | there was talk about TerminateThread being used, but that's really not safe, unlike killing child processes | 14:03 |
| Lo-lan-do | You can do it preemptively, but I'm not sure you can disable it. | 14:03 |
| vila | sven_sandberg: except if it's the *first* repacking since the conversion which is weird anyway | 14:03 |
| fullermd | I don't think you can disable it through the CLI; some code level frobbing can do it. | 14:04 |
| sven_sandberg | vila, it's the first time i see this after we upgraded to 2a. but i have been pulling successfully without this happening many times | 14:05 |
| vila | mgz: 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 |
| vila | sven_sandberg: have a look at the .bzr/repository/packs directory sorting the file by size | 14:05 |
| mgz | I 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 easier | 14:06 |
| fullermd | sven_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 |
| vila | sven_sandberg: you may be repacking the biggest file which takes time | 14:06 |
| mgz | having some problematic subset of server tests forking for the moment would be workable | 14:07 |
| sven_sandberg | fullermd, i see, makes sense | 14:07 |
| sven_sandberg | vila, there are 35 files, and the biggest one is 299 MB | 14:07 |
| sven_sandberg | fullermd, would it be a reasonable feature request to add an option to CLI to turn this off? | 14:08 |
| sven_sandberg | i mean, i don't even know if it's doable... | 14:09 |
| vila | sven_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 enough | 14:09 |
| vila | sven_sandberg: *not* packing would have a pretty bad impact on performance | 14:09 |
| vila | sven_sandberg: I don't think you'll run into the same problem soon, otherwise the solution is to repack each night preventively | 14:10 |
| vila | sven_sandberg: but if that's the first time you encounter the problem, I don't think it's worth it | 14:10 |
| sven_sandberg | vila, 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 0 | 14:13 |
| sven_sandberg | vila, how do i repack preventively? | 14:13 |
| Lo-lan-do | 35 files can hold about 100000 revisions. | 14:13 |
| vila | sven_sandberg: 'bzr pack' | 14:13 |
| Lo-lan-do | Er, make that 10000, sorry. | 14:14 |
| xapantu | hi all ! | 14:15 |
| xapantu | Is it possible to execute a script after each comit ? | 14:15 |
| sven_sandberg | vila, thank you! | 14:16 |
| xapantu | because I would like that a file was updated with thz bzr revision number to each commit. | 14:16 |
| xapantu | do you have any idea ? | 14:16 |
| xapantu | Thanks ! :) | 14:16 |
| mgz | look at the docs for post commit hooks | 14:17 |
| vila | xapantu: 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 |
| mgz | but... it sounds more like you want the... wassit... right, what vila said | 14:18 |
| mgz | what's the term for the $$ thing cvs does? | 14:18 |
| xapantu | ok, thanks ! | 14:18 |
| vila | mgz: see ? I can look above your shoulder too :-P | 14:18 |
| vila | keywords | 14:19 |
| vila | yeah, there is that too, lp:bzr-keywords ? | 14:19 |
| mgz | thanks :) | 14:19 |
| xapantu | but 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-do | xapantu: Note that .bzr/branch/last-revision already has the last revision number | 14:19 |
| vila | xapantu: then let's step back a bit, what are you trying to achieve ? | 14:20 |
| xapantu | i would like to do a dialog window with the revision | 14:20 |
| xapantu | Inkscape do this with a makefile but it is very slow.... | 14:21 |
| mgz | so, when the program is built, you want the revno in the about window, say? | 14:21 |
| xapantu | yes | 14:22 |
| fullermd | You want to do that as part of the build process rather than as keywords anyway. | 14:22 |
| fullermd | Keywords are most applicable when you care about file-level stuff. You want tree-level stuff for that. | 14:23 |
| vila | xapantu: exactly what fullermd said | 14:24 |
| xapantu | like on this page : http://wiki.bazaar.canonical.com/KeywordExpansion ? | 14:24 |
| xapantu | I am reading it... | 14:24 |
| fullermd | Otherwise 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 |
| xapantu | ok, I am going to try with keywords. | 14:25 |
| vila | that's the file-level approach | 14:25 |
| vila | ... :) | 14:26 |
| mgz | are we talking inkscape here? if so, just working out what's slow with the current makefile and fixing it is probably the right answer | 14:26 |
| fullermd | Also, keywords aren't really usable with bzr. | 14:26 |
| vila | xapantu: bzr version-info --template 'var = {revno}\n' --custom | 14:27 |
| vila | xapantu: start with the above, redirect to whatever file you see fit, running that *can't* be that slow :) | 14:27 |
| xapantu | ok, I am going to add this to my makefile, thank a lot :) | 14:28 |
| assad | is there a meld like tool for windows? besides bzr qdiff | 14:39 |
| sven_sandberg | vila, 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 |
| vila | sven_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 step | 14:44 |
| sven_sandberg | vila, good. yes, it already went through chk. so that's good news. thank you! | 14:44 |
| vila | sven_sandberg: right, just repacked by bzr repo, that should be it | 14:44 |
| === Meths_ is now known as Meths | ||
| vila | sven_sandberg: can you come back when it's finished to tell us how many packs you end up with and their sizes ? | 14:46 |
| vila | sven_sandberg: oh, and all of that occurs without mounted file systems right ? | 14:46 |
| sven_sandberg | vila, sure | 14:46 |
| sven_sandberg | vila, how do you mean, without mounted file systems? | 14:47 |
| vila | sven_sandberg: the repository is on a local file file system or a mounted one ? | 14:47 |
| sven_sandberg | vila, local | 14:47 |
| vila | ok | 14:48 |
| assad | can we collapse all the little revisions into one? | 14:49 |
| vila | assad: merge ? | 14:49 |
| assad | vila, i made several commits with small changes. i want them to collapse those revisions into one | 14:50 |
| assad | in my own branch | 14:51 |
| vila | assad: bzr uncommit -r<rev_before_first_commit> ; bzr commit -m 'The whole shebang' | 14:52 |
| assad | vila, thanks | 14:52 |
| vila | assad: try that in a scratch branch in case you chose the wrong revision | 14:53 |
| assad | vila, ok | 14:53 |
| LeoNerd | Or, branch -r<firstrev>; merge | 14:53 |
| vila | assad: or do several uncommit and use bzr diff to check | 14:53 |
| sven_sandberg | fullermd, vila, how hard would it be to hack the source to turn off repacking? can i just comment out something? | 14:53 |
| vila | LeoNerd: He wants to get rid of the commits | 14:53 |
| LeoNerd | Hrmm.. Well... merge shoudl show them on the history as a single commit | 14:54 |
| assad | yeah. the revisions are unnecessarily piling up due to small changes and commit | 14:54 |
| vila | LeoNerd: Agreed, that was my first proposal :) | 14:54 |
| vila | sven_sandberg: not that hard, but the penalty will strike back quickly: you don't want to query 100s of indices | 14:55 |
| vila | svaksha: I understand that it's blocking you right now, but the next occurrence could be in several weeks or months | 14:56 |
| svaksha | ? | 14:56 |
| vila | svaksha: argh, sorry | 14:56 |
| vila | sven_sandberg: : I understand that it's blocking you right now, but the next occurrence could be in several weeks or months | 14:56 |
| vila | xchat: stop losing my settings !!! | 14:57 |
| guilhembi | vila: sven_sandberg wanted to do an important merge today, he's blocked for hours now waiting for the repack to finish; | 14:58 |
| vila | guilhembi: I realize that see above, I'm looking... | 14:58 |
| guilhembi | he would be fine with disabling repack, doing his merge, and re-renabling repack after the merge and doing "bzr repack". | 14:58 |
| guilhembi | vila: merci beaucoup | 14:59 |
| vila | guilhembi: An alternative would be to branch outside of the shared repo | 14:59 |
| vila | guilhembi: work there, and pull the branch back once done | 14:59 |
| vila | sven_sandberg: that should even be doable *while* the repack is going on | 14:59 |
| guilhembi | sven_sandberg: so that means | 15:00 |
| guilhembi | cd your_shared_repo | 15:00 |
| guilhembi | bzr branch first_tree /other/dir/out/of/shared/repo/first_tree # should take a few minutes | 15:00 |
| vila | sven_sandberg: sorry for the Murphy's law striking :-/ | 15:01 |
| jam | morning all | 15:01 |
| guilhembi | bzr branch second_tree /other/dir/out/of/shared/repo/second_tree # should take a few minutes | 15:01 |
| jam | hey vila | 15:01 |
| vila | hey jam ! | 15:01 |
| guilhembi | sven_sandberg: and then | 15:01 |
| guilhembi | cd /other/dir/out/of/shared/repo/second_tree | 15:01 |
| guilhembi | bzr merge /other/dir/out/of/shared/repo/first_tree | 15:01 |
| vila | jam: what's the fastest way to disable auto-repack ? | 15:01 |
| guilhembi | bbl | 15:01 |
| vila | sven_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 to | 15:03 |
| vila | jam: something like : http://paste.ubuntu.com/451111/ ? | 15:05 |
| vila | jelmer: some mps are harder to land than others.... :) | 15:08 |
| jam | vila: I think you need to do it in the groupcompress repo | 15:09 |
| jam | vila: nm, that would do fine | 15:09 |
| vila | jam: no autopa... ok | 15:10 |
| jam | I'll also note, you should be able to ^C an autopack | 15:10 |
| jam | it will want to do it on the next fetch | 15:10 |
| jam | but I think the data is already present. | 15:10 |
| jelmer | vila: :-)) | 15:10 |
| jam | (maybe not, I'll check quickly) | 15:10 |
| jam | I take that back, it looks like 'pack-names' isn't saved until after the autopack finishes | 15:11 |
| vila | jam: what do you take back ? 'data is already present' or 'be able to ^C' (the former I think) | 15:12 |
| jam | vila: if you interrupt autopack, it reverts the whole fetch | 15:13 |
| jam | pack-names isn't updated until the fetch + autopack is completed | 15:13 |
| vila | makes sense from the user point of view | 15:13 |
| sven_sandberg | vila ,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 |
| vila | sven_sandberg: ok , did the workaround unblocked you ? | 15:15 |
| sven_sandberg | vila, 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% CPU | 15:16 |
| sven_sandberg | vila, ok, i the repack stopped now and the 'bzr branch repo out-of-shared-repo' terminated. so i'm ready to do some work now | 15:17 |
| sven_sandberg | vila, jam, fyi, it left a lot of bzr-index-HEXNUMBER files in /tmp/ after i did ^C during repack | 15:18 |
| vila | sven_sandberg: when you'll came back to your shared repo, you can 'bzr pack' before pulling | 15:22 |
| vila | jam: I think the simplest way to address the issue here would be an option to disable autopack on-demand | 15:23 |
| vila | jam: a noisy one that will yell: "Watch out ! I need packing ! Gimme my bzr pack soon !" | 15:24 |
| vila | jam: 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 dat | 15:25 |
| vila | day | 15:25 |
| sven_sandberg | vila, yes that would be perfect solution for me | 15:25 |
| thrope | hi - trying to use bzr+ssh from windows... have the following problem | 15:29 |
| thrope | http://pastie.org/1008527 | 15:29 |
| thrope | SSHException: Error reading SSH protocol banner | 15:29 |
| thrope | any ideas? do I need to install anything else for ssh access on windows | 15:29 |
| thrope | could it be the nonstanadard port causing problems? | 15:30 |
| jam | thrope: that looks like it is able to connect to the remote host, but the remote host isn't offering ssh on that port | 15:30 |
| jam | are you sure 2222 is the correct ssh port for that machine? | 15:30 |
| thrope | yes | 15:30 |
| thrope | ive had it working with tortoise svn and svn+ssh | 15:31 |
| thrope | and I can connect with putty from the same winows machine on port 2222 (just checked) | 15:31 |
| thrope | oh wait it works now | 15:32 |
| thrope | will it use putty keyagent? | 15:32 |
| jam | thrope: paramiko will, yes | 15:39 |
| jam | vila: any thoughts on the thread timeout issues? | 15:40 |
| thrope | cool thanks - i think it was something funny with windows firewall | 15:40 |
| vila | jam: didn't you get my reply ? | 15:40 |
| jam | vila: well, I replied to your reply :) | 15:40 |
| vila | ha, let me check | 15:41 |
| jam | do you think that the client has legitimately closed the connection, and the server wasn't informed? | 15:41 |
| jam | ooh. 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 timeout | 15:42 |
| jam | (with the hard 2-min timeout) | 15:42 |
| vila | jam: I think the client closed yes | 15:42 |
| vila | jam: 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 blocks | 15:43 |
| vila | jam: 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 die | 15:45 |
| vila | jam: 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 |
| jam | vila: 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 |
| vila | jam: on windows that is, things works as expected (at least by me :) on lucid/py26, karmic/py2[456] | 15:48 |
| jam | which is a complete guess | 15:48 |
| vila | jam: 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 which | 15:49 |
| jjann | Hi. How do I revert all changes made by a given revision? (ie do something like what 'hg backout' does with mercurial) | 15:49 |
| jam | jjann: bzr merge -r X..X-1 | 15:49 |
| jam | sorry | 15:49 |
| maco | most recent commit? bzr uncommit | 15:49 |
| jam | jjann: bzr merge . -r X..X-1 | 15:50 |
| maco | also, bzr revert | 15:50 |
| jam | the '.' is significant | 15:50 |
| vila | jam: 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 |
| jjann | maco: no, not most recent, and 'revert' doesn't do that | 15:50 |
| jjann | jam: thanks | 15:50 |
| vila | jelmer: and one more Request for non-PQM managed branch :-P | 15:55 |
| jelmer | vila: argh | 16:08 |
| jelmer | vila: problem is I'm much more used to submitting lp branches these days | 16:08 |
| vila | jelmer: yeah, yeah, they all say that :) | 16:09 |
| mhall119 | hi, I've got a question | 16:17 |
| mhall119 | two developers working on a project, can they use bzr+ssh to push/pull from the same location? | 16:18 |
| mhall119 | if they have to ssh in as different users? | 16:18 |
| maco | mhall119: if theyre on the same team... | 16:18 |
| maco | and the location is a team location | 16:18 |
| mhall119 | what do you mean team location? | 16:19 |
| mhall119 | I'm not using Launchpad | 16:19 |
| mhall119 | just a server with ssh access | 16:19 |
| bialix | mhall119: look at bzr_access script in src/contrib | 16:21 |
| mhall119 | or would I be better off using bzr serve? | 16:21 |
| mhall119 | where woudl I find this src/contrib? | 16:22 |
| bialix | look into bzr release tarball | 16:23 |
| bialix | directory contrib/ | 16:23 |
| mhall119 | oh, ok | 16:23 |
| mhall119 | I just have bzr installed | 16:23 |
| marsilainen | mhall119: I think that usually unix group permissions are used | 16:24 |
| marsilainen | so you put both developers in the same unix group | 16:24 |
| mhall119 | will it create files with g+w? | 16:25 |
| mhall119 | because default umask makes them g+r only | 16:25 |
| marsilainen | and then make sure that the group has appropriate permissions to the files | 16:25 |
| marsilainen | you probably need some special umask, not sure | 16:25 |
| marsilainen | I think it's in the docs somewhere | 16:25 |
| mhall119 | hmmm, can you specify a umask for a particular directory? | 16:25 |
| marsilainen | maybe it needs a 'sticky' bit on the dir at the top of the repository or something | 16:26 |
| marsilainen | I don't know the details, but I believe that's how people do it | 16:26 |
| mhall119 | I tried that, that just makes new files belong to the same group, but doesn't give them write access | 16:26 |
| marsilainen | mhall119: "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 |
| marsilainen | that was from: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial | 16:27 |
| mhall119 | thanks marsilainen | 16:28 |
| marsilainen | np | 16:28 |
| vila | mhall119: it would be simpler to use a single user but two ssh keys | 16:29 |
| marsilainen | depends on the situation innit | 16:30 |
| mhall119 | well, that didn't work... | 16:44 |
| mhall119 | second user doesn't have permission to push changes | 16:44 |
| marsilainen | well, there is probably something more you need to do then... | 16:44 |
| Lo-lan-do | You could also play with setfacl | 16:45 |
| mhall119 | the problem is that when user1 pushes a new branch, it's rwxr-sr-x on the new directory | 16:46 |
| mhall119 | and rw-r--r-- on the files that it creates | 16:47 |
| marsilainen | mhall119: this looks like a howto of sorts: http://profarius.com/content/creating-your-own-bazaar-server | 16:47 |
| mhall119 | looks like all the same steps I did | 16:49 |
| Lo-lan-do | You need either umask 002 or some acls. | 16:50 |
| mhall119 | but can I umask only that directory? | 16:50 |
| Lo-lan-do | Nope, umask is a property of a process. | 16:51 |
| Lo-lan-do | It's generally set by the shell. | 16:51 |
| mhall119 | and, since I"m using ssh, it'll have to be set on my users | 16:51 |
| mhall119 | right? | 16:51 |
| Lo-lan-do | Right. Or you could write a bzr wrapper that calls umask then bzr. | 16:52 |
| mhall119 | hmmmm | 16:53 |
| === beuno is now known as beuno-lunch | ||
| ovnicraft | hi folks, i am trying update my repos from lp, so i have this error http://pastebin.ca/1885154 | 17:22 |
| ovnicraft | says maybe a bug in bzr | 17:22 |
| jelmer | ovnicraft: can you please file a bug against bzr with as much info as possible? | 17:25 |
| jelmer | ovnicraft: it does indeed look like a bzr bug of some sort | 17:25 |
| ovnicraft | i see the bug confirmed in bzr gubs | 17:25 |
| ovnicraft | *bugs | 17:25 |
| ovnicraft | http://bit.ly/9Uycul | 17:26 |
| ovnicraft | set milestone 2.2 | 17:26 |
| ovnicraft | i think the bug is really important to people who upgrade 2a version the branchs | 17:28 |
| ovnicraft | missing references to chk root keys, says the error, itcan be fixed with new set info user in repo or somthing like that? | 17:29 |
| ovnicraft | i need the changes from lp | 17:29 |
| mhall119 | okay, i'm just going to make a single user to share | 17:31 |
| mhall119 | I don't want to make drastic changes to user's umasks just for this | 17:31 |
| jelmer | ovnicraft: sorry, I'm not familiar with the specific bug. You'd probably want to talk to one of the bzr folks | 17:31 |
| jelmer | vila: Is your branch hung? | 17:32 |
| vila | jelmer: I don't think so | 17:33 |
| ovnicraft | jelmer, 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 fixe | 17:33 |
| ovnicraft | *fix | 17:33 |
| mmestnik | Hello, I'm working with bzr over samba and there was a problem calling chmod. | 17:41 |
| mmestnik | http://paste.pocoo.org/show/226581/ | 17:41 |
| mmestnik | I've asked in #python about the syntax. | 17:42 |
| dickelbeck | newbie could use a little help | 17:44 |
| dickelbeck | There exists lp:kicad and I have a local branch of it I have been working on. 1) Edit, 2) commit locally, 3) merge | 17:47 |
| dickelbeck | merge said "nothing to do". Now how do I get my changes back into lp:kicad. Do not want to submit a patch. | 17:47 |
| jelmer | dickelbeck: you could push back into lp:kicad if you have that permission | 17:48 |
| jelmer | dickelbeck: alternatively, you can submit a merge proposal so the maintainers of lp:kicad can merge your changes | 17:49 |
| jelmer | dickelbeck: you can create a merge proposal by pushing your local branch to Launchpad and then proposing that branch for merging | 17:49 |
| dickelbeck | I do. I *am* basically a main maintainer. | 17:49 |
| dickelbeck | But I do not yet have bzr experience beyond the initial push I did to establish the launchpad branch. | 17:50 |
| jelmer | dickelbeck: in that case you should be able to "bzr push lp:kicad" | 17:50 |
| rom1 | i think you take the merge command in the wrong direction | 17:50 |
| dickelbeck | Now you say I can use push again. | 17:50 |
| rom1 | merge means merge from and not merge to | 17:50 |
| dickelbeck | rom1: I understand that about merge. There were no recent changes in remote branch. | 17:51 |
| jelmer | dickelbeck: so you should indeed just be able to push to the remote branch | 17:51 |
| dickelbeck | But the answer to my question is that I need to use push now, correct? | 17:51 |
| rom1 | yes | 17:51 |
| jelmer | dickelbeck: yep | 17:51 |
| rom1 | if you have modifications on the remote branch, the push command will tell you about it, and you will have to do a merge | 17:52 |
| rom1 | before repushing | 17:52 |
| dickelbeck | thanks, you guys are very helpful. It is done. Now I will run for cover. | 17:53 |
| jelmer | vila: is pqm slower than it used to be? | 17:53 |
| mmestnik | I know this isn't the best way to submit a patch, though it dosen't do anything... | 17:54 |
| mmestnik | http://paste.pocoo.org/show/226585/ | 17:54 |
| vila | jelmer: depends, it now runs all the tests instead of stopping at first failure for example | 17:55 |
| mmestnik | This helps with using bzr over a samb mount by protecting the chmods from causing unwanted trouble. | 17:55 |
| mmestnik | The 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 |
| jelmer | mmestnik: is this with unix extensions enabled on the samba side? | 17:56 |
| mmestnik | I'm un-aware of how the server is configured. | 17:56 |
| jelmer | mmestnik: with unix extensions enabled the chmod should work | 17:56 |
| mmestnik | jelmer: It would be nice if bzr could work around any problematic server/client configuration. | 17:56 |
| mmestnik | There are other filesystems that would choke on a chmod so that solution is incomplete. | 17:57 |
| jelmer | mmestnik: the chmod is there for a reason though, I presume to prevent files that are private from becoming accessible to other users during merge | 17:58 |
| mmestnik | ...and on file-systems that fail the chmod it's irrelevant. | 17:58 |
| mmestnik | Hence the failed chmod ;) | 17:58 |
| vila | I'm off | 17:59 |
| jelmer | vila: have a nice evening | 17:59 |
| vila | mmestnik: did you try running the test suite with your patch ? | 17:59 |
| mmestnik | It's a nice gesture to try and make it accessible, but it's not essential. | 17:59 |
| jelmer | mmestnik: well, in those situations we would have to use whatever semantics are available on those file systems | 17:59 |
| mmestnik | It still failed with the patch. | 17:59 |
| mmestnik | jelmer: Ahh, it's already done 4 you... nothing to do, no operation. | 18:00 |
| mmestnik | Look 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 |
| vila | mmestnik: 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 system | 18:01 |
| jelmer | mmestnik: ? Windows has its own security semantics and it can't guess what permissions you want it to have | 18:01 |
| * vila really off | 18:01 | |
| jelmer | vila: the cifsfs used to mount remote windows file servers doesn't support chmod unless the server does | 18:01 |
| mmestnik | chmod is chmod. It's the tool to work with those permissions. | 18:01 |
| mmestnik | After the chmod thee is nothing more for you to do. | 18:02 |
| jelmer | mmestnik: on windows those things work with nt acls | 18:02 |
| mmestnik | This 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 |
| jelmer | mmestnik: what does ntfs have to do with it? | 18:03 |
| mmestnik | What does windows have to do with it? | 18:04 |
| jelmer | mmestnik: SMB exposes windows semantics over the wire | 18:04 |
| jelmer | mmestnik: 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 modes | 18:04 |
| jelmer | mmestnik: if the server doesn't support that it will basically claim to not support any mode changes at all | 18:05 |
| mmestnik | I'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 |
| jelmer | mmestnik: I disagree, data privacy is not opt-in. | 18:07 |
| mmestnik | Using samba(or anything else that dosn't have chmod) is an opt-out of data privacy. | 18:08 |
| jelmer | mmestnik: we could allow configuring Bazaar to ignore failed changes of file permissions, but it should not be the default. | 18:08 |
| mmestnik | That sounds reasonable. Still the issue is after this patch there are other problems. | 18:08 |
| jelmer | mmestnik: what sort of issues? | 18:09 |
| mmestnik | http://paste.pocoo.org/show/226596/ | 18:09 |
| mmestnik | http://paste.pocoo.org/show/226598/ | 18:13 |
| === beuno-lunch is now known as beuno | ||
| LabMonkey | I'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 |
| LabMonkey | Any help? | 18:15 |
| mhall119 | does anyone know if the bzr for windows standalone installer comes with an ssh client? | 18:19 |
| jelmer | mmestnik: right, it's also not possible to do atomic renames | 18:22 |
| mmestnik | :( | 18:26 |
| jelmer | mmestnik: bzr currently relies on the platform to find out what semantics to expect, it should probably look at the particular fs more | 18:26 |
| mmestnik | What link should I send to my samba admin to enable the chmod stuff at least? | 18:27 |
| mmestnik | I think it should be generically written to try a feature(like atomic renames) and then fall back gracefully. | 18:29 |
| mmestnik | I 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 |
| mmestnik | The 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-jr | SHA1KnitCorrupt: 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 33977d3efbed4d55aca8bc7208838e850b5fc647 | 19:30 |
| luke-jr | help? :( | 19:30 |
| beuno | luke-jr, knit? | 19:32 |
| beuno | that's like a 100 year old branch, right? | 19:33 |
| beuno | anyway, try bzr check and brz reconcile | 19:33 |
| beuno | otherwise, we'll need jam or some other low-level guru | 19:33 |
| luke-jr | beuno: dunno how old... | 19:37 |
| luke-jr | I suspect it may actually be corrupt | 19:38 |
| tsmith | is there a way to convert a bzr branch to svn? | 20:00 |
| jelmer | tsmith: if you have bzr-svn installed you can push into svn | 20:01 |
| tsmith | ok i try that | 20:01 |
| tsmith | $ bzr push svn://localhost/user_directory --overwrite | 20:02 |
| tsmith | bzr: ERROR: Permission denied: "." | 20:02 |
| tsmith | user_directory is a brand new svn repo w/ 0 commits | 20:02 |
| tsmith | any idea? | 20:03 |
| tsmith | jelmer, any idea? | 20:03 |
| assad | how 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 |
| jelmer | tsmith: you can't push to a svn:// URL usually | 20:05 |
| tsmith | o awesome | 20:06 |
| tsmith | thanks man | 20:06 |
| jelmer | tsmith: Not with svn itself either I mean | 20:07 |
| jelmer | tsmith: You'll need svn+ssh://, file:// or http:// | 20:07 |
| tsmith | file:// worked | 20:08 |
| lifeless | assad: what do you mean 'ticket interface' | 20:13 |
| lifeless | assad: can you give us an example url ? | 20:13 |
| assad | https://help.launchpad.net/Code/Review#Proposing%20a%20merge lifeless | 20:13 |
| assad | minus the email interface on that page | 20:13 |
| lifeless | thats the docs | 20:13 |
| lifeless | I mean a url of a merge proposal you are having trouble with | 20:13 |
| assad | lifeless, https://code.launchpad.net/~zubairassad89/sahana-eden/vms/+merge/27697 | 20:14 |
| lifeless | ok, on that page if you fill in the 'Add comment' box and set the 'Review' field below it to a value, then click save comment | 20:15 |
| lifeless | it will do a review - and you can use that to set your review to approve or needs fixing or whatever. | 20:15 |
| lifeless | thats the 'review approve' in the web UI | 20:15 |
| lifeless | the '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 |
| assad | lifeless, ok | 20:16 |
| assad | lifeless, thanks | 20:21 |
| lifeless | no problem, hapy to help | 20:22 |
| jam | hi lifeless | 21:49 |
| jam | Interesting 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 |
| jam | I 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 |
| bitdancer | What are these files that end with things like ~1~ in my checkout? | 23:17 |
| bitdancer | Or, rather, I know what they are (old copies of files), but why are they created? | 23:17 |
| bitdancer | And how do I get rid of them? :) | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!