| lifeless | ok, no poolie yet | 00:02 |
|---|---|---|
| lifeless | spiv: stand hup ? | 00:02 |
| spiv | lifeless: sure | 00:02 |
| spiv | skype or pots is fine. | 00:02 |
| lifeless | you and I can skype, and I'll skype out to get poolie | 00:03 |
| Odd_Bloke | Why do Canonical use Skype rather than a free VoiP solution? | 00:13 |
| Odd_Bloke | Or is it just the case that everyone in Canonical uses Skype, without there being any sort of policy? | 00:13 |
| lifeless | skype works | 00:14 |
| lifeless | we have an asterix server | 00:14 |
| jml | hi | 00:28 |
| jml | (again) | 00:28 |
| jml | I'd like to get the stacked-on url for a branch without opening a branch. | 00:29 |
| jml | I'm guess I should open the bzrdir for the url and do something from there? | 00:30 |
| Verterok | jelmer: I can't upload to bzr-svn, maybe need to be in the bzr-svn team? | 00:32 |
| Verterok | jelmer: anyway, I uploaded both dmg's to: http://verterok.com.ar/bzr-svn | 00:33 |
| * jml experiments | 00:34 | |
| jelmer | Verterok, you should now be in the team | 00:34 |
| spiv | vila: great work on finding and fixing the pycurl select/poll bug. | 00:35 |
| Verterok | jelmer: ok, uploading to launchpad :) | 00:35 |
| jelmer | Verterok, thanks! | 00:40 |
| Verterok | jelmer: np, now I need figure out hot to include both versions in the bzr dmg | 00:43 |
| === fta_ is now known as fta | ||
| rocky | what is the typical way to control read/write access with bzr smart server? perhaps proxy it with apache and use htpasswd based auth ? | 02:17 |
| jearl | rocky: it depends on what you want to do. | 02:21 |
| jearl | rocky: I think typically people use bzr+ssh if they have complicated requirements for who can read and write. | 02:24 |
| rocky | i'm thinking more about replacing a svn+apache+dav setup | 02:24 |
| rocky | is there more involved docs for serving up bzr (particularly with the smart server) than just the little section at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server ? | 02:31 |
| jearl | I know I've seen something, but I can't remember where. | 02:32 |
| jearl | one second | 02:33 |
| jearl | OK, I can't find the docs I was looking for, but you can, of course, use htpasswd based authentication to control access to your smart server. | 02:36 |
| rocky | right... atm tho i'm having trouble setting up the smart server, period ;) | 02:37 |
| jearl | That's part of the reason that bzr+ssh is so popular. | 02:37 |
| rocky | well, for this particular project, setting up shell users for each committer isn't an option ;) | 02:38 |
| jml | rocky: at the moment, that's your only option if you want to provide write access to branches with the server. | 02:39 |
| jml | well, not true. | 02:39 |
| jearl | No, there are other options. | 02:39 |
| rocky | --allow-writes | 02:39 |
| jml | you could use Launchpad, or you could set up PQM. | 02:40 |
| rocky | the smart server supports --allow-writes | 02:40 |
| jearl | You could also do writes via FTP (assuming you can create FTP users) | 02:40 |
| jml | rocky: but that 'allow writes' means that anyone who can access the port would have write access. | 02:41 |
| rocky | jml: yes... that's what the apache htpasswd access is for | 02:41 |
| jml | it's not a web service though. | 02:42 |
| rocky | i thought it was a simple wsgi app | 02:43 |
| rocky | the smart server, that is | 02:43 |
| jml | no. the smart server is a custom server with a custom protocol. | 02:43 |
| jml | well | 02:43 |
| jml | you can get bzr+http access | 02:44 |
| jml | but that's readonly, afaik | 02:44 |
| rocky | ok google's broke, can't seem to find better bzr smart server / http serving docs | 02:44 |
| jml | the ones on bazaar-vcs.org are the best there is, I think. | 02:45 |
| jml | rocky: there's the possibility that I've said something wrong also :) | 02:46 |
| rocky | ;) | 02:47 |
| jml | rocky: you don't have to give people remote shell access in order to let them run 'bzr' via ssh, you know. | 02:48 |
| jml | they still need an account on the machine, but you can deny them a shell | 02:49 |
| lifeless | jml: spiv: mail for you | 03:11 |
| markh | would it make sense to add a param to tree.auto_resolve() that tells it not to perform the actual resolution, meaning it would return what files it *could* auto-resolve? | 03:27 |
| markh | (picture a GUI 'resolve' tool - ideally it would list all files in conflict, but put checkboxes (or otherwise distinguish) only the ones that can be auto-resolved) | 03:29 |
| Peng_ | lifeless: Someone else already wrote a different log --limit patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080831160826.GA28292%40mutt.xyzz.org%3E | 03:32 |
| Peng_ | He added a different test too. | 03:32 |
| spiv | markh: a dry_run=False param? | 03:37 |
| markh | spiv: yeah | 03:37 |
| lifeless | Peng_: I prefer mine :P | 03:37 |
| markh | spiv: how was the snow? | 03:37 |
| spiv | markh: If there's no better way to discover the auto-resolvable files (and I'm guessing there isn't), then it makes sense to me. | 03:37 |
| spiv | markh: slightly bruising :) | 03:38 |
| markh | I can't see one - that function has a local regex and string literals it checks the 'conflict type' against. Duplicating that would be fragile... | 03:38 |
| markh | spiv: bruises are to be expected I expect :) | 03:38 |
| lifeless | well | 03:38 |
| spiv | markh: more bruising for my wife. It turns out that knee pads mean that instead of vicious bruises covering most of the knee, you get mild bruise covering the *entire* shin. | 03:38 |
| lifeless | its a bit of LBYL thing | 03:38 |
| lifeless | Why mark those you can autoresolve | 03:39 |
| lifeless | why not autoresolve and show the remaining conflicts | 03:39 |
| Peng_ | lifeless: The other patch's unit test simply tests how many revisions were returned. What about adding that to your test and going with that? | 03:39 |
| Peng_ | Oh, i see. | 03:39 |
| Peng_ | Oh, i just noticed that you added a blackbox test, while the other patch didn't. | 03:39 |
| markh | lifeless: I'm slightly concerned that is "too magic" - a user sees a file as 'conflicting' - they right-click and hit 'resolve' - but then the list of files presented doesn't include the one they selected! | 03:40 |
| lifeless | Peng_: I didn't add any tests; I changed a insufficient test into a sufficient test :P | 03:40 |
| lifeless | markh: 'resolve file' means 'mark it resolved no matter what' in the CLI | 03:40 |
| markh | and presenting the remaining conflicting ones in the dialog isn't useful - they can't meaningfully resolve those that are left from that dialog anyway | 03:40 |
| markh | lifeless: yeah, I understand that | 03:41 |
| markh | lifeless: but the CLI has a terminal it can print meaningful messages to | 03:41 |
| lifeless | markh: I don't understand the problem I guess | 03:41 |
| markh | lifeless: I guess the question is about the user's expectation if they hit 'resolve conflict' on a file marked as being in conflict | 03:42 |
| lifeless | markh: it should resolve it, always | 03:43 |
| lifeless | markh: because they should only see the file being in conflict if it is | 03:43 |
| markh | lifeless: ok - so they select that on the root of the working tree | 03:43 |
| markh | you are saying "auto-resolve and list the remaining ones" | 03:43 |
| markh | in effect saying "there is no resolve dialog - just a dialog with a result of what files were auto-conflicted" | 03:44 |
| lifeless | no | 03:44 |
| lifeless | there are broadly three sorts of conflicts | 03:44 |
| lifeless | conflicts bzr can tell when they are resolved | 03:45 |
| lifeless | conflicts bzr can't tell when they are resolved | 03:45 |
| lifeless | conflicts that have been resolved but bzr hasn't checked yet | 03:45 |
| lifeless | if you have a resolve dialog, which of these three sets are useful to show ? | 03:45 |
| markh | phrased slightly differently: what does the user expect to happen when 'resolve conflicts' is selected from the menu? | 03:46 |
| lifeless | right | 03:46 |
| markh | my thought was "show all conflicts, which checkboxes against ones able to be auto resolved" | 03:47 |
| lifeless | fugly :) | 03:47 |
| markh | we have a similar concept now - eg "qbzr ci filename" shows *all* modifications, but only 'filename' checked | 03:47 |
| markh | similarly for resolve | 03:47 |
| lifeless | I think its ugly because it means the user has to think more about what the ui is telling it | 03:48 |
| markh | yes, I agree it might not be obvious | 03:49 |
| lifeless | is there ever going to be a different choice for the user than 'yes, the X boxes are right' ? | 03:49 |
| markh | I'm not sure it will be obvious though to auto-resolve all conflicts before evein showing them the dialog, and then only showing them the rest. It means 'cancel' won't actually cancel anything | 03:50 |
| markh | for a file bzr can't auto-resolve but the user has resolved it, the user would check that specific item | 03:50 |
| markh | I'm slightly uncomfortable with "well do some magic in the background before asking you to go further" | 03:51 |
| lifeless | well | 03:51 |
| lifeless | use cases | 03:51 |
| lifeless | 'I want to resolve a conflict bzr can't auto-resolve' | 03:52 |
| lifeless | 'I want to run 'bzr resolve' - resolve everything it can and show me the remainder' | 03:52 |
| markh | and the most common 'I want to resolve a conflict bzr can auto resolve' | 03:53 |
| lifeless | why is that a use case? | 03:53 |
| lifeless | I think its a use case because you have a different one you haven't articulated, which is 'I want to keep something that is conflicted, that auto-resolve would unconflict, marked as a conflict' | 03:54 |
| markh | because the user edited a file to remove the conflict, but the item is still showing as being in conflict | 03:54 |
| lifeless | that is covered by 12:52 < lifeless> 'I want to run 'bzr resolve' - resolve everything it can and show me the remainder' | 03:55 |
| markh | the user wants to tell tbzr to show it correctly now please | 03:55 |
| markh | IMO the user is specifically focused on a single source file | 03:55 |
| lifeless | why wouldn't tbzr show it correctly automatically ? | 03:55 |
| markh | I'm not sure the users will expect a conflict cycle of "fix one conflict, attempt to resolve entire tree, fix next conflict, repeat..." | 03:56 |
| lifeless | I think this is like the status discussion | 03:56 |
| markh | I personally work more like "fix one, resolve one, fix next, resolve next" | 03:56 |
| lifeless | its a YAGNI driven by performance concerns | 03:56 |
| markh | no - its user expectations and workflows | 03:56 |
| markh | notihing about perf at all :) | 03:57 |
| lifeless | ok | 03:57 |
| lifeless | so you save the file | 03:57 |
| lifeless | and tbzr marks it as unconflicted | 03:57 |
| markh | we have one menu with scarce real-estate. | 03:57 |
| lifeless | no need for a menu item so far | 03:57 |
| markh | I think we are simply disagreeing on user expectations | 03:58 |
| markh | I should probably take it to the tbzr and qbzr mailing lists and try to form a consensus :) | 03:58 |
| lifeless | please keep bazaar@ in the loop | 03:58 |
| markh | ok | 03:58 |
| lifeless | I'm on neither of the GUI lists, and I'm not sure Martin or Aaron or others are either | 03:58 |
| lifeless | I would say that if you want a single file resolve, do that; don't conflate that with tree wide auto resolve; you can refactor bzr's auto resolve to a per-file basis to use it there if you want as well | 04:00 |
| lifeless | I certainly don't think that bringing up a tree wide menu if you are doing single-file workflow makes any sense, but that is what you seemed to be proposing | 04:00 |
| markh | I'm proposing that like TSVN, any directory with conflicting items would have a 'resolve' item on its menu | 04:01 |
| markh | and any file in conflict would similarly | 04:01 |
| markh | beyond that, I'm still working things out :) | 04:01 |
| lifeless | I would like: | 04:01 |
| lifeless | well | 04:03 |
| lifeless | I don't think doing a tree wide scan for auto-resolvable files without actually resolving them makes sense | 04:03 |
| lifeless | if you need that, I think there is confusion about whats going on | 04:03 |
| markh | think of it as warming the caches for the actual resolution that will happen any second now :) | 04:05 |
| markh | but I see your concerns | 04:05 |
| markh | I think broadening the discussion makes sense | 04:05 |
| * spiv wonders which project http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C200809010242.m812g2p9078345%40harfy.jeamland.net%3E belongs to | 04:24 | |
| spiv | Ah, squid, judging from gmane. | 04:24 |
| markh | lifeless: do you think it makes more sense for some of you guys to join the tbzr developers mailing list rather than forcing cross-posts to 3 lists when most of the bzr readers probably don't care? John already is... | 04:25 |
| lifeless | spiv: yes | 04:26 |
| lifeless | markh: well, this is the price of having multiple lists | 04:26 |
| spiv | Hmm, I thought abentley fixed the bug of broken merge directives on other lists being attributed to bzr? | 04:27 |
| lifeless | if the submit field is set correctly | 04:27 |
| markh | it doesn't seem helpful to introduce more noise on the bzr mailing list if the reality is that its only for the benefit of a couple of people | 04:27 |
| markh | its no skin off my nose though :) | 04:28 |
| jml | lifeless: mail regarding what? | 04:32 |
| lifeless | jml: launchpad's sftp server | 04:32 |
| jml | lifeless: I'll check my spam folder. | 04:33 |
| mwhudson | jml: it was bug mail | 04:33 |
| jml | mwhudson: I saw the thread, but didn't see lifeless's email. | 04:34 |
| jml | there it is. | 04:38 |
| * jml changes the bug's summary | 04:38 | |
| === Snaury__ is now known as Snaury | ||
| jml | where can I find the version of pyflakes that loves lazy_import? | 05:05 |
| mwhudson | lp:~mwhudson/pyflakes/support-lazy-imports i think | 05:10 |
| jml | yay branches | 05:16 |
| mwhudson | i even used the ~vcs-import branch! | 05:20 |
| jml | lifeless: so, I've got all my interface tests done and have an implementation that makes them all pass. thing is it still opens the branch. | 05:24 |
| jml | lifeless: got ideas on how I can (or whether I should) write a test that shows that it doesn't open the branch? | 05:24 |
| lifeless | well | 05:26 |
| mwhudson | i guess you could delete .bzr/repository... | 05:26 |
| lifeless | opening the branch would fail if | 05:26 |
| lifeless | the stacked on branch was inaccessiblee or something | 05:26 |
| jml | so set a made-up, definitely doesn't exist url? | 05:27 |
| lifeless | or use a real url then delete the contents there | 05:30 |
| LaserJock | jelmer: around? | 05:40 |
| jml | lifeless: next question. I've got a test in bzrdir_implementation.test_bzrdir that looks like this: http://paste.ubuntu.com/42310/ | 06:03 |
| jml | lifeless: problem is, none of the implementations run with a stackable branch & repo format. | 06:03 |
| jml | so the test never exercises the bit I'm primarily interested in. | 06:04 |
| jml | what should I do about this? | 06:04 |
| lifeless | change the meta one up to use 1.6 | 06:04 |
| jml | the actual scenario? | 06:04 |
| jml | or just for this test? | 06:04 |
| lifeless | the scenario | 06:05 |
| jml | ok | 06:06 |
| mwhudson | bzrlib has a lot of lint | 06:11 |
| * AfC hands mwhudson a lint brush. | 06:12 | |
| jml | yes it does :) | 06:14 |
| mwhudson | at least it's test suite is fairly fast | 06:18 |
| mwhudson | though, otoh, said test suite contains this: | 06:21 |
| mwhudson | reduce(getattr, (module).split('.')[1:], __import__(module)) | 06:21 |
| mwhudson | which is not a thing to make a man happy | 06:21 |
| * jml stares | 06:23 | |
| * jml attains satori | 06:24 | |
| * mwhudson is not so lucky | 06:33 | |
| * mwhudson goes to mow the lawn before it gets too dark | 06:33 | |
| === AnMaster_ is now known as AnMaster | ||
| jml | lifeless: should I do something special for remote formats? | 06:54 |
| * mwhudson writes a whiny email to the list | 07:14 | |
| jonnydee | lifeless: you said I should remember you if your fix for https://bugs.launchpad.net/bzr/+bug/255656 has not been merged into bzr.dev. Well hereby I remember you :) | 07:50 |
| ubottu | Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] | 07:50 |
| jonnydee | (sorry, it means "remind you"...) | 07:53 |
| lifeless | jml: what do you mean? | 08:15 |
| markh | Is it 'expected' that 'bzr rm dir' silently takes no action and prints no message if dir is the root of a working tree? | 08:19 |
| Peng_ | Whether or not it's expected, IMHO it should display an error. | 08:21 |
| markh | yeah, that's why I used quotes around 'expected' :) I guess the question is: should I report a bug? | 08:22 |
| markh | no point wasting my time if lifeless or someone else can quickly say "nah, that's normal, don't bother reporting anything" :) | 08:22 |
| lifeless | Peng_: why should it error? | 08:25 |
| lifeless | Peng_: bzr add likewise doesn't error | 08:25 |
| lifeless | markh: it has taken an action | 08:25 |
| Peng_ | Oh? | 08:26 |
| markh | you know I'm going to ask what action it took ;) | 08:26 |
| lifeless | its scanned for and removed any missing files | 08:26 |
| markh | the only action I can see it took was to compare the abspath to an empty string and therefore skipped that entry in the file_list | 08:27 |
| markh | doesn't 'bzr rm dir' normally removes versioned files in dir, and dir itself? | 08:27 |
| lifeless | markh: delete a file, run 'bzr rm' | 08:27 |
| markh | if 'dir' is the root of a wt, it doesn't take the same action it takes when dir is a subdirectory of a wt. | 08:28 |
| Peng_ | That's...convenient, but nonintuitive. It is explained in the help though. Huh. | 08:29 |
| lifeless | markh: oh, I missed the exact quesiton; but I'm not sure its wrong anyhow | 08:29 |
| lifeless | Peng_: same as 'bzr add' being nonintuitive that it will scan-and-add, if you're coming from somewhere where you had to be explicit | 08:30 |
| markh | what about 'bzr rm .'? | 08:30 |
| Peng_ | lifeless: Ehh, perhaps. | 08:31 |
| markh | (that gets a little upset trying to remove 'dir' on windows - or takes no action if the cwd is the root of a wt) | 08:31 |
| lifeless | markh: if we say: the same as 'bzr add .', then the current behaviour is probably good; if we say that 'explicit parameters always cause explicit actions' probably bad | 08:31 |
| markh | I'm more worried about the silence than the behaviour. 'bzr add .' at least tells you it does nothing :) | 08:32 |
| lifeless | markh: sure, file a bug if you like | 08:33 |
| markh | (although even then bzr seems confused: added hello.txt\nadded new.txt\nignored 2 file(s).\nIf you wish to add some of these files, please add them by name. | 08:34 |
| markh | why did it say 'added' on the first 2 lines? | 08:34 |
| lifeless | markh: becase it added files | 08:34 |
| markh | oh right! so 'bzr add .' *does* work in the root of a wt exactly the same as it does in a subdir | 08:35 |
| lifeless | note that 'bzr add .' won't print any output if there is nothing ignored and nothing added | 08:35 |
| lifeless | I'd like bzr rm to behave the same at any depth too | 08:38 |
| lifeless | I'm waiting to see if people become addicted to 'bzr rm' the way I have | 08:39 |
| lifeless | anyhow, I'm calling it a day | 08:44 |
| Peng_ | Good night. :) | 08:45 |
| markh | have a good one! nearly beer-oclock for me too :) | 08:46 |
| visik7 | I can't get the difference between pull and update | 09:09 |
| luks | pull downloads revisions from a remote branch and updates the working tree to the head revision | 09:11 |
| luks | updates updates the working tree to the head revision of the bound branch | 09:11 |
| luks | -s in the first "updates" :) | 09:11 |
| luks | pull in a standalone branch, and update in a checkout are similar though | 09:12 |
| luks | it all makes more sense if you understand the concept of branches and working trees in bzr | 09:13 |
| markh | in some ways, having 'pull' default to also doing an update of the working tree isn't helpful to someone learning bzr concepts (although it certainly is useful in its own right) | 09:25 |
| AfC | markh: you're not the first to remark that | 09:30 |
| poco | hi | 10:23 |
| poco | i have a repository but i want to move all its content in a subdirectory. should i simply use bzr mv? and if i want to merge 2 repositories in one parent repo, how should i do that? | 10:24 |
| poco | maybe juste a bzr merge inside a subdir ? | 10:25 |
| poco | if i simply do a merge inside current dir, i loose all the revisions of original repo | 10:27 |
| poco | with a mkdir bla; cd bla; bzr merge foo; mkdir foo; bzr mv * foo | 10:28 |
| poco | and if i do "bzr co" inside "bla" i'm gona have multiple repos | 10:30 |
| poco | maybe "bla" should be init with init-repo? could i then use recursive "repositories" (init-repo) | 10:31 |
| === Snaury__ is now known as Snaury | ||
| Odd_Bloke | poco: Using bzr mv for your first case is probably the best way to go about it. | 10:33 |
| poco | Odd_Bloke, thanks | 10:34 |
| Odd_Bloke | As for merging two branches (which is, I assume, what you mean), are you sure that the merge loses the revisions, or is it just not showing them in the left-hand ancestry? | 10:35 |
| poco | i am not sure, what do you mean by left-hand ancestry? | 10:36 |
| Odd_Bloke | poco: The mainline revisions, which don't have a dotted revision number. | 10:40 |
| poco | ah! | 10:41 |
| === thekorn_ is now known as thekorn | ||
| poco | i understand how to solve conflict with the .THIS, .BASE and .OTHER, but how am i suppose to resolve them with the 'moved existing file to ... .moved' ? | 12:10 |
| james_w | if you want a particular copy then move that in to place | 12:11 |
| james_w | if you want some hybrid then copy the bits you want from .moved in to the file | 12:11 |
| poco | ah ok, i need to given explicitely the filename when resolving? | 12:11 |
| james_w | I think so, yes | 12:12 |
| poco | thanks | 12:13 |
| === thekorn_ is now known as thekorn | ||
| jelmer | lifeless, ping | 15:49 |
| === jelmer is now known as Guest47733 | ||
| Guest47733 | jam, ping | 15:49 |
| === Guest47733 is now known as jelmer | ||
| ignas | hi | 15:56 |
| ignas | is there a way to "lift" my changes, merge from another branch and apply them back again without commiting? | 15:57 |
| ignas | i have tried to use "shelve" | 15:57 |
| ignas | but it did not help me, because it does not "shelve" added directories :/ | 15:57 |
| Odd_Bloke | ignas: Could you not add the directories/files back _after_ you've merged? | 16:00 |
| ignas | i just thought that maybe there is a way that will not require me to play around with specific files/changes | 16:01 |
| === emgent is now known as emgent`NL | ||
| jam | jelmer: I saw you released 0.4.12, but I don't see the tag available from bzr.d.o | 16:13 |
| jelmer | jam, I've pushed to http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental | 16:14 |
| jam | jelmer: so should this go in "bzr-beta-ppa" then? | 16:14 |
| jelmer | we're not uploading to unstable at the moment because of the freeze of lenny | 16:15 |
| jam | k | 16:15 |
| jelmer | jam: it's actually a stable release of bzr-svn, so probably ~bzr | 16:15 |
| jelmer | jam, what's the easiest way to test for a deprecation warning? | 16:23 |
| jelmer | I was looking for tests for ensure_null() but there don't appear to be any >-) | 16:23 |
| james_w | jelmer: apply_deprecated I think | 16:48 |
| jelmer | james_w: Thanks | 16:49 |
| jam | james_w: it would be self.applyDeprecated, but that is only if the function you are calling is directly deprecated | 16:49 |
| jam | you need callDeprecated | 16:49 |
| jam | to pass in a custom deprecation string | 16:49 |
| james_w | hi jam | 16:50 |
| jam | I'm not really here | 16:50 |
| jam | I'm on vacation today :) | 16:50 |
| james_w | it's alright, I didn't see you. | 16:50 |
| * awilkins curses Borland for writing batch scripts that call classes for which not even the fricking package exists | 16:57 | |
| awilkins | I hope the crotch of their testing manager gets savaged by a german giant rabbit | 16:58 |
| jelmer | good morning to you too, awilkins :-) | 16:58 |
| awilkins | Bah, time to go home | 16:59 |
| awilkins | Back later :-) | 16:59 |
| * jelmer files some more bzr-builddeb wishlist bugs | 17:11 | |
| jam | jelmer: packages should be uploaded | 17:19 |
| jam | at least for gutsy/hardy/intrepid | 17:19 |
| jelmer | jam: Thanks | 17:20 |
| exarkun | Why does this happen? http://rafb.net/p/UJo6VW65.html | 17:34 |
| rocky | jelmer: you released bzr-svn 0.4.12 but the download link on pypi leads to a page that lists all releases up to 0.4.11 it looks like | 17:38 |
| jelmer | rocky: Sorry, I forgot to update the wiki page. will do so now | 17:40 |
| * rocky is in jelmer's shadow ;) | 17:40 | |
| Snaury | jelmer: while trying to checkout pugs with bzr-svn I noticed with -Dtransport that there are often multiple 'svn get-dir' lines for the same revision, why could it be so? | 18:07 |
| Snaury | (this is during "determining revisions to fetch" phase) | 18:07 |
| rocky | anyone have a favourite bzr mode for emacs? something preferably along the lines of psvn ? | 18:37 |
| jelmer | Snaury, would need some looking into | 18:59 |
| jelmer | Snaury, the direct return value of get_dir isn't cached but some of the values based on it are | 18:59 |
| Snaury | http://kitsu.ru/bzr-log-partial.log - it's just the pattern looked strange to me. | 19:01 |
| Snaury | And they look rather expensive too (unless there's something else eating time between the calls, haven't checked that yet). When there are 20000 revisions the overhead would turn out pretty bad. :) | 19:04 |
| jelmer | it's only called if the branch directory changed in that revision | 19:05 |
| Snaury | Well, judging from the fact that it was determining revisions to fetch for more than several hours it was called for every revision at least twice and for some revisions three or more times. And in the case of pugs trunk it's pretty expensive too: | 19:12 |
| Snaury | 59.577 svn get-dir -r2043 | 19:12 |
| Snaury | 61.415 svn get-dir -r2043 (finished) | 19:12 |
| Snaury | 61.415 svn get-dir -r2042 | 19:13 |
| Snaury | 63.680 svn get-dir -r2042 (finished) | 19:13 |
| Snaury | Perhaps it could be cached as a whole somehow? | 19:13 |
| Snaury | (as a proof of three or more times look at the bzr-log-partial.log above, which was a restart after yet another connection loss) | 19:16 |
| Snaury | And url is http://svn.pugscode.org/pugs/ you can try it yourself, of course. | 19:16 |
| jelmer | Snaury, I think I may know some way to skip the need to do those calls in a lot of cases | 19:27 |
| * LarstiQ cheers jelmer on | 19:27 | |
| jelmer | hmm, bzr-svn trunk is freakishly quick now and it's still doing those get-dir requests | 19:59 |
| LarstiQ | jelmer: what's the improvement? | 19:59 |
| jelmer | fetches about 7 revisions per second from the pugs repository | 19:59 |
| LarstiQ | instead of? | 20:00 |
| jelmer | probably about 1 or 2 | 20:00 |
| LarstiQ | nice | 20:01 |
| === cprov-lunch is now known as cprov | ||
| === mw is now known as mw|food | ||
| === kiko is now known as kiko-afk | ||
| === mw|food_ is now known as mw | ||
| === cprov is now known as cprov-afk | ||
| rocky | jelmer: so you've been working on increasing speed of bzr-svn further since the 0.4.12 release? | 21:30 |
| jelmer | yeah | 21:31 |
| jelmer | This is all happening in trunk, which will at some point become 0.5 | 21:31 |
| rocky | oh... doesn't 0.4 get released from trunk too or does it live on a special 0.4 branch? | 21:31 |
| rocky | i was playing with the smart server wsgi setup yesterday until i ran out of steam... seems like it should be easier to setup ;) | 21:32 |
| rocky | jelmer: don't suppose you have an example standalone py script server that uses wsgiref to serve up the bzr smart server? | 21:33 |
| jelmer | 0.4 gets released from a separate branch, the 0.4 branch | 21:33 |
| jelmer | rocky, no sorry, I don't have experience with the wsgi server | 21:34 |
| luks | I had a plugin that does 'bzr serve --http' using wsgiref some time ago | 21:39 |
| luks | bzr serve-http actually | 21:42 |
| luks | http://rafb.net/p/guvLH649.html | 21:42 |
| luks | dunno if that still works | 21:42 |
| rocky | luks: oh thanks | 21:53 |
| luks | rocky: you could fix it, make it configurable and release a proper plugin! :) | 21:54 |
| rocky | seems kind of silly to me that bzr serve doesn't have something similar to this anyhow... i mean http based protocols are way more flexible ;) | 21:54 |
| luks | what I wanted was to add per-branch HTTP auth to the WSGI server | 21:55 |
| luks | but that failed due to lack of interest, and this code is just a leftover | 21:55 |
| rocky | well atm i'm working on a project that manages multiple trac instances with their relative svn instances and such and i want to extend it for bzr... having my python wsgi app serve up the bzr directly instead of having to rely on apache (for svn) would give me a great deal of flexibility | 22:02 |
| rocky | are repos that are served up by the bzr wsgi app browseable using a browser? | 22:05 |
| * rocky tries to get it working to test for himself | 22:05 | |
| mwhudson | probably not, but that should be easy to add | 22:05 |
| beuno | mwhudson, when you have time, can you take a peak at: https://code.edge.launchpad.net/~beuno/loggerhead/1.6.1/+merge/806 | 22:39 |
| mwhudson | beuno: um, sure, merge it | 22:40 |
| beuno | that was easy | 22:41 |
| beuno | and release 1.6.1 to make lifeless happy? | 22:41 |
| mwhudson | sounds good | 22:41 |
| beuno | mwhudson, sweet, thanks | 22:43 |
| beuno | lifeless, https://edge.launchpad.net/loggerhead/1.6/1.6.1 | 22:54 |
| * beuno goes off and leaves the announcement for later | 22:54 | |
| rocky | luks: don't suppose you know of better "serving bzr repos" docs than what's in the user's guide? | 23:06 |
| rocky | is there anyway to pass in credentials for a basic auth protected url (say in a config file) so you don't have to include them on the command-line ? | 23:25 |
| lifeless | moin | 23:33 |
| mwhudson | hi lifeless | 23:33 |
| beuno | howdy lifeless | 23:34 |
| beuno | I've made a special Loggerhead release for you :) | 23:35 |
| * beuno -> home | 23:36 | |
| poolie | good morning | 23:51 |
| jelmer | hi Poolie | 23:52 |
| jelmer | How were your holidays? | 23:52 |
| poolie | really great | 23:53 |
| poolie | and you? | 23:53 |
| jelmer | apart from a rough start (er visit and a leaking tent) very good | 23:56 |
| poolie | lifeless, spiv, igc, jam, call in 2m? | 23:58 |
| spiv | Good morning. | 23:58 |
| spiv | poolie: yeah | 23:58 |
| mwhudson | spiv: hi, have i talked to you about https://bugs.edge.launchpad.net/bzr/+bug/261315 yet? | 23:59 |
| ubottu | Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,Triaged] | 23:59 |
| spiv | mwhudson: I don't think so | 23:59 |
| mwhudson | ok | 23:59 |
| mwhudson | i would really like someone to fix it fairly soon :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!