[00:17] mtaylor: yes === asac_ is now known as asac [02:20] just curious, does anyone here ever nest repos ? [02:44] rocky: Repos? Yes. Branches? No. [02:47] Hey! Quick question. In the bzr code, is there any way to get the path to the root of the current branch? If not globally, can you do so from the TreeDelta class at all? [02:49] KhaZ: There's the "bzr root" command. You could start with its code. [02:51] Cool, thanks, I'll take a look === edcrypt is now known as edcrypt_ [07:40] KhaZ: I gave you wrong answer yesterday, sorry. `bzr st .` do what you need [07:48] Oh? [07:48] Hrmm. [07:48] I just rewrote bzr st in my local copy to do that. Oops. [07:49] Actually, that doesn't seem to work either [07:49] Oh, wait a minute [07:49] I'm confusing two issues. [07:49] bzr st . only prints changes after my current working directory, which is defintely awesome. [07:50] My other 'issue' is that bzr st always prints out paths relative tot he root of the repository, not relative to where I currently am in the tree. [07:50] I've put code in my local branch of bzr to do that. If I wanted to see if that would be accepted in the mainline, how would I go about doing that? [07:50] (Not saying it should be - perhaps people enjoy the current way... But I'd like to ask at least. ;) ) [08:07] Khaz: the second issue mulled over many times. It's considered as bug [08:10] https://bugs.launchpad.net/bzr/+bug/30159 [08:10] Ubuntu bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] [08:10] very ooooold bug [08:15] if you want to fix this bug -- many peoply will be happy [08:16] KhaZ: run `bzr send --mail-to bazaar@lists.canonical.com lp:bzr` in your branch -- this will create patch submission [08:17] http://bazaar-vcs.org/BzrDevelopment [09:34] morning [11:21] ronny: ooooh, those gloves look nice [11:27] LarstiQ: they sure do [11:29] hi AmanicA [11:30] hi [11:30] today is quite enough here? [11:30] huh? [11:30] I mean the channel is empty, not? [11:30] relatively [11:30] look at lp:~scmproj-dev/bzr-scmproj/new-layout please [11:30] you LarstiQ! [11:31] :) [11:31] yo! [11:31] bialix: whats scmproj ? [11:31] LarstiQ: we going to do mini-sprint with AmanicA on new layout. everybody can jump in [11:31] ronny: emulation of nested trees [11:32] only bzr, or support for others, too? [11:32] ronny: In general design is vcs-agnostic [11:33] ronny: sorry, my "look" may be too wide there [11:33] bialix: cool, I'm at fosdem at the moment, still waking up, going to hunt down jelmer and others later [11:33] cool [11:33] bialix: ah, im the author of anyvc, which is a vcs abstraction lib [11:33] ronny: cool [11:33] anyvc for Emacs, no? [11:33] i still lack support for repos/branches tho, doing mostly workdir abstraction atm [11:33] bialix: its a python lib [11:34] using it in the pida ide [11:34] ooh [11:34] I've started some sort of vcs abstraction for scmproj [11:34] AmanicA: try to run tests, you'll see where we now [11:35] bialix: how far, and whats the main job of it [11:35] bialix: i'd lobe to join effords at some point [11:35] excelent! [11:35] mostly cause propper abstraction of the various branching patterns is a huge pain [11:35] ronny: I'm focusing on the scmproj needs [11:36] as main goal [11:36] btw, is there any relation to the vcs-pkg project? [11:36] we have our own "branch" abstraction here: local branches [11:36] ronny: http://bazaar.launchpad.net/~scmproj-dev/bzr-scmproj/new-layout/annotate/head%3A/vcs.py [11:36] bialix: tests passed [11:37] AmanicA: you joking [11:37] no [11:37] I did make test [11:37] bialix: ah, i see [11:37] on new-layout [11:37] I have 8 errors [11:37] ronny: what is vcs-pkg [11:37] ? [11:38] AmanicA: I suppose you need to switch your active plugin to use new-layout branch/checkout, no? [11:38] bialix: http://vcs-pkg.org/ [11:38] ok [11:39] ronny: no, "distro package maintenance" is not my goal [11:39] back to reality: FAILED (errors=8) [11:40] bialix: k [11:41] AmanicA: we have 2 different ways here: working with local project and with remote one [11:41] ok [11:43] you can start adapting one or another [11:43] give me one [11:44] remote is a bit smaller perhaps? [11:44] test_project.py TestProjectRemote [11:44] I don't mind, I'll have to figure it out anyway [11:44] ok [11:44] we need to teach the code about project-get from remote location [11:45] hmm [11:45] ronny: where anyvc lives? [11:45] bitbucket [11:46] http://bitbucket.org/RonnyPfannschmidt/anyvc/ [11:46] current state is good workdir support, lack of branch/repo abstraction + sync [11:47] thanks, I'll look at the code later [11:47] i also want to add support for vcs mappers at some point (ie bzr/git/hg svn extensions) [11:47] what is "mappers"? [11:48] bialix: foreign branches/tailor style converting between vcsen [11:48] ah [11:49] bialix: TestProjectRemote.test_initialize is leaking threads among 3 leaking tests do you want me to look at that too? [11:49] no, I saw this. It has random effect [11:49] ok [11:49] monseur vila perhaps can shed some light [11:50] but I suppose he is nothere [11:52] AmanicA: I think we also need to collapse some commands together at some point [11:52] e.g. project-get maybe should to get the branches as well? [11:53] in stead of fetch? [11:54] I see no test for project-get, local or remote [11:54] LarstiQ: i dont want to mimic tialor, i want to utilize the buildins/extensions of the vcs's to deal with the 2way interop [11:54] if it's not in test_cli.py then it's not written yet [11:55] ronny: I should have used parenthesis around (foreign branches/tailor) :) [11:55] * LarstiQ heartily agrees not going the tailor route for an actual implementation [11:56] hmm [11:56] something no traditional vcs will ever be able to support is propper 2-way interop with darcs [11:57] bascially the content of the workdir is a view on the merge of the current ends of the patch dependency graph [11:57] AmanicA: I'll try to rework local.cfg to use branch.conf [11:58] AmanicA: look at the end of the page: http://bazaar-vcs.org/ScmProj/Snapshot [11:58] bialix: I think I must work on project-get ie. write local and remote tests for it [11:59] ok [11:59] I'm working on local.cfg then [12:00] AmanicA, bialix: the socket leaking problem is a hard one, basically they are due to servers that are not able to shutdown properly because transports are still connected [12:00] ok [12:00] And since transport API and usage provides no mean to close a connection, there is no easy way [12:01] vila: I'm successfully can write the test with sftp server but it randomly leaking [12:01] ronny: yeah, it is possible to make a generalisation to support darcs, but not very useful imho [12:01] bialix: don't worry about that too much [12:01] ok [12:01] Essentially the server close happen during gc so you have no control about it [12:02] vila: btw I think this may affect bzr selftest on windows then, because this OS has limited resources for opened sockets [12:02] If and when the problem is solved, your test will stop leaking :-) [12:03] it's already stops. no.. wait! it leaking again! :-) [12:03] ooh that is bad, so longrunning apps that repeatedly connect to some server can run out of connections? [12:03] LarstiQ: i think darcs is one of the best ideas to deal with development [12:03] The symptom when reaching socket limit is pretty heavy: most of the tests start failing very vocally... At least on linux, OSX solaris, (still not enough experience under windows :-/) [12:03] if they will not close sockets? yes, there possible problems then [12:04] AmanicA: not at all, the leaked sockets are the *server* ones [12:04] IIRC on windows this number is about 1K [12:04] LarstiQ: stuff like cherry-picking is just natural to it, and propperly propagates [12:04] the test server ones even [12:05] ok, but cant you run out of server sockets [12:05] if some app eg. bzr-eclipse connects repeatedly [12:06] AmanicA: *test* servers [12:06] only selftest is concerned [12:06] okok, then its no big problem I guess [12:07] :) thanks [12:08] It's a problem about relying on the gc to release resources [12:09] The leak test was added to have some idea about the problem scale because some other tests were failing under very weird circumstances, if you look at the output of a full test suite run, you should find the bug number and from there more info on the subject [12:09] * vila wasn't there and should really go to hair dresser :) [12:10] :-) [12:12] :) [12:13] bialix, I see the whitebox test for pget is for clone method [12:13] so I will implement that for remote [12:13] yes [12:25] AmanicA: pushed changes in tests (s/create/initialize) [12:25] * bialix lunch [12:25] me too almost [12:25] can I push to that branch? [12:25] yes [12:32] * AmanicA lunch [13:43] LarstiQ: Whereabouts are you? [13:49] Hi all [13:50] LarstiQ: In case you're looking for me, I'm in the lightning talks at least until the Bazaar one :-) [14:10] Lo-lan-do, Odd_Bloke : I'm heading to the lightning talks too, and otherwise I camp put at the debian booth [14:10] and god is wifi horridly slow [14:11] LarstiQ: I'm in the front row [14:12] anyone know where jelmer is hiding? [14:12] I've been looking for him today, since he's the only bzr face I know (and I've only known him since last night :-) [14:14] jelmer got at the hotel around 04:00 [14:15] ouch [14:15] he might be waking up now [14:15] \\ [14:16] \\ [14:16] \ [14:16] \\\\\\\\\\\\\\\ [14:16] gar [14:18] note to self, don't hold the laptop at the keyboard [14:23] bialix, code & test for project.clone(remote) committed. but you really need to review it. [14:27] * Odd_Bloke is going to loiter outside the lightning talks room after the bzr one. [14:29] ok [14:58] bialix: I was able to open a remote project config [14:58] why did you say we don't allow that? [14:59] I think the problem it when it is just a branch an not a tree [14:59] so I think we should just show a nice error if the file does not exist [15:07] AmanicA: I think we should split the Project class on ProjectLocal and ProjectRemote [15:07] why? [15:07] AmanicA: because they should behave differently [15:08] ok [15:08] but thats a lot of work [15:08] remote project config we need to read from RevisionTree, not from the disk [15:08] do you want to do it now? [15:08] yes [15:08] ok [15:09] I'll turn Project into base class with classmethods [15:09] time to learn about metaclasses [15:09] and make two classes that extend that one [15:09] yes [15:10] with a foctory method that instantiates ther right ome [15:10] one [15:10] so we don't need to check every time [15:10] isinstance(self.t, LocalTransport) :-) [15:10] yes, checking every time is a NASTY ANTI-PATTERN [15:11] I know from experience :/ [15:11] anyways I could not make a test fail for the missing config file yet. [15:12] I think I should go on with other stuff until you finished this refactoring [15:12] (non scmproj stuff) so let me know when youre done' [15:13] ok [15:13] any python guru around? [15:14] hi, what do you need? [15:14] :) [15:14] some hints about __new__() [15:15] I thought you should do it like get_transport does it [15:15] we can use it to create either local or remote instance based on transport supplied [15:15] i think [15:16] you think we should use URL instead of transport in the constructor? [15:16] this may simplify something [15:17] maybe [15:17] ok, i tdd then [15:17] yes I think that would be a nicer API [15:18] I cant think of a case where we want to pass in a transport and not a url [15:18] revolution continued [15:18] Yeah! [15:27] * AmanicA rebooting [15:46] AmanicA: we need more blackbox tests [15:57] I know [15:59] :-) [15:59] i've removed a file in my repo.. bzr pull shouldn't re-update it ? [16:00] like svn up does [16:00] *in my local repo [16:00] you need bzr revert [16:00] thanks [16:01] it worked [16:10] AmanicA: ping [16:10] pong [16:10] i'm reworking your clone [16:10] for remote: from url should be self.t.base [16:11] can we omit accelerator_tree then? [16:12] I don't think we really need it [16:12] I think it makes it quicker [16:12] when the remote side also has a working tree [16:12] remote should not has wt [16:13] why not? [16:13] only local [16:13] i guess because bzr does not support remote wt? [16:13] say you and I push stuff between our scmprojs [16:13] the you have a wt [16:13] and I have one [16:14] oh [16:14] no [16:14] we call remote different [16:14] please update your branch [16:14] ProjectLocal -- when the url is local path [16:15] I still don't understand why you removed the BASE [16:15] ProjectRemote -- when url is sftp://, http:// etc [16:15] because we push to remote server just the branch [16:16] I think we need to clarify it [16:16] so does it not go into .scmproj? [16:16] we == you and I [16:16] exactly like the local version [16:16] no [16:16] you think we should? [16:16] it will play badly with LP [16:16] and with my gforge hosting [16:17] gforge? [16:17] since it does not show up on the frontend [16:17] what we use at work [16:17] never saw it in action [16:17] s/gforge/fusionforge/, man, keep up with the times! [16:17] * Lo-lan-do does some advocacy [16:17] oh [16:17] i feel myself old-timers [16:18] lol [16:18] lo-lan-do has scared [16:18] AmanicA: so you still think we should preserve .scmproj? [16:18] for remote> [16:18] I shink it forked from sourcefourge some time ago [16:18] no [16:19] great [16:19] but that is how I thought when I coded it [16:19] that's why i've started separate clasess [16:19] so what we are talking about here is just the sharing of .scmproj [16:19] not all its containing branches [16:19] and the working trees [16:19] * bialix going to change clone() to use url as parameter [16:20] cool [16:20] i think -- yes [16:20] .scmproj at the disk is the branch [16:20] please add some code docs as to what we decided now [16:20] and we handle it as the branch [16:20] yes [16:21] it's better copy-paste to wiki [16:21] i'd better finish code [16:21] ok [16:22] one sentence would help [16:22] we can clean it up later [16:24] AmanicA: new_br = dir.open_branch() [16:24] is it really needed? [16:24] no [16:24] I thought I removed that [16:24] removed [16:25] I was looking if it will be needed, and obivously forgot to remove it [16:26] I told you, that you have to review this code, because I was unsure of what it was supposed to do. I [16:26] I'm glad you are catching these [16:26] man, I don't understand whty i've started to use transport instead of url [16:26] code is much better now woth urls [16:27] with [16:27] heh [16:27] * AmanicA food again! [16:27] yes [16:27] ! [16:28] ashes on my head... :-[ [16:34] * bialix committed and going for some coffee [16:43] hi! I'm trying to compile and install bzr into a --no-site-packages virtuanenv on an ubuntu hardy, but building btree fails. Do I miss some header packages? If so what? here is the traceback: http://pastebin.com/m12e1efca [17:07] nagyv: looks like you need python-dev package [17:07] or something like this [17:08] bialix: thx, just found it out myself as well :) [17:08] k [17:20] so to solve the "copy" debate-- why not simply have 3 operations: move, template, and split? [17:21] this is your daily ~bzr PPA ping, any ETA on bzrtools? :-) [17:23] luke-jr: hm? [17:23] bialix: 'move' is straightforward and already implemented [17:24] 'template' would mean basically "add with history" [17:24] 'split' would try to merge changes in both directions, and conflict if there was a problem [17:25] AFAIK the main problem is file-id [17:25] ? [17:25] bzr internally works in the term of file-id [17:25] o [17:25] it's like inodes [17:26] some kind of "split/templated from " metadata? [17:26] try to search ML archives for `path tokens` [17:26] IIRC === ja1 is now known as jam [17:27] jam knows everything, are you here? [17:30] I think main problem here is that internally bzr should change support of only one file-id to to several (aka aliases) [17:31] if I "downgrade" a branch format will it bother people who already have branched? [17:31] no [17:32] unless you going downgrade to knits [17:44] jelmer: what type of a shared repo do i need to have to clone http://people.samba.org/bzr/jelmer/bzr-local-branches/trunk/ ? [17:44] yo jelmer! [17:46] so bialix how's it hangin? [17:46] tro: bzr info http://people.samba.org/bzr/jelmer/bzr-local-branches/trunk/ -v will tell you (but i guess --rich-root-pack) [17:46] AmanicA: hanging? [17:46] bialix: thanks. just figured that out myself too :) [17:46] yes [17:47] what do you mean? [17:47] :) [17:47] I'm back to new local config stuff [17:47] how is it going with that refactoring [17:47] ah [17:47] basic things are done [17:47] we need to move almost everything to ProjectLocal [17:47] let me know when I can start breaking stuff again:) [17:48] but mandatory parts (open and clone) already there [17:48] green light [17:48] i'm grinding config.py [17:49] AmanicA: perhaps we should think about all 4 variants of clone, but current 2 is ok for me [17:49] yes [17:50] they are the most important ones [17:52] so project.py is open for hacking now [17:52] jelmer: Whereabouts are you? [18:07] hurray all our tests are passing, this makes develoment easier: less noise [18:07] bialix, it there something specific you want me to tackle next? [18:07] btw thanks for fixing the tests [18:07] i've just disabled 4 of them for now to remove noise [18:08] will be very nice to have more blackbox tests if you don't mind [18:08] excelent [18:08] that was what I was thinking too [18:09] perhaps with new local config our progress will be strugled [18:09] s/with/without/ [18:09] not sure I understand [18:10] I'll start with pget, as I think I now know what it does, will see about code docs while I'm at it [18:11] local config used for run_actiona and fetch [18:16] AmanicA: ping [18:16] hi [18:17] it will be much simpler if we using for local config only branch config and never fallback to global bazaar.conf [18:17] objections? [18:18] for what again [18:18] for current subset [18:18] http://bazaar-vcs.org/ScmProj/Workspace [18:19] we need to store this option, and we could put it in global config [18:19] but it's only one universal option I see today [18:20] is it just more effort now? [18:20] I think if we do realise we want it we can add it later [18:20] more effort now, may be i'm just defer it till we start using it [18:20] yip [18:20] ok [18:20] thx [19:01] AmanicA: local config there. my brain has slowed down, so i'm finished today. [19:01] cool [19:02] it was excelent [19:02] yes [19:02] we should do that more often [19:02] I'm still busy [19:02] it's break through (I guees it's right term) [19:02] I can help with advices [19:02] I'm addind better online help for pget [19:02] but can't do review today [19:03] aah [19:03] and i believe you can jongle with english words better than me [19:03] I'll commit when I'm done and you can review it when you feal like it [19:03] I try [19:04] I write it mostly for myselg [19:04] myself [19:04] i think we need to make pget more powerful [19:04] since I have to figure out what it actually does in order to test it [19:04] I'm writing it down as I go [19:05] in the right place [19:05] i've made several simple commands (pget, pfetch, pco) to test them easily manually [19:05] yes [19:05] what about pmanage :) [19:05] which can do al management tasks [19:05] but now i feel we need to collapse them, or at least try to collapse [19:05] lol [19:06]