| jelmer | dOxxx: I'd recommend sticking to the releases | 00:02 |
|---|---|---|
| dOxxx | jelmer: ok. same for bzr-svn? | 00:04 |
| dOxxx | jelmer: actually looks like I need to take something more recent than the 1.0.4 release of bzr-svn for it to be compatible with bzr 2.3 | 00:06 |
| vila | jelmer: time to create a new release ? :-p | 00:07 |
| jelmer | vila: yeah... | 00:08 |
| dOxxx | jelmer: bzr-rewrite too | 00:08 |
| jelmer | I need to put some more thought into that ghost issue though :-/ | 00:08 |
| dOxxx | vila: I'm packaging bzr-upload v1.0.0, ok? | 00:09 |
| vila | dOxxx: yup | 00:09 |
| jelmer | dOxxx: I guess trunk is the best thing to package indeed. This is for the beta, right? | 00:09 |
| dOxxx | jelmer: I thought this was 2.3.0 | 00:09 |
| dOxxx | of bzr | 00:10 |
| dOxxx | vila: right? | 00:10 |
| jelmer | AFAIK 2.3.0 is not out yet, is it? | 00:10 |
| vila | jelmer: yup, 2.3b5, but we intend to package as many releases as possible for 2.3.0 | 00:10 |
| dOxxx | woops | 00:10 |
| vila | dOxxx: *last* beta before 2.3.0 | 00:10 |
| dOxxx | vila: :) | 00:10 |
| dOxxx | oh well I would have found out when the build tried to download the 2.3 tarball and failed :) | 00:11 |
| vila | dOxxx: indeed :) | 00:11 |
| dOxxx | I need to poke abentley about a few of his plugins too | 00:11 |
| dOxxx | seems a number of them have 2.3 compatibility changes on trunk but no release | 00:11 |
| dOxxx | also bzr-xmloutput which seems to be a free-for-all author-wise | 00:12 |
| vila | mail would be good for that I think as he's not around anymore | 00:12 |
| dOxxx | vila: k | 00:12 |
| maxb | jelmer: oh, question, what's the current plan for bzr-svn version numbers? because lp:bzr/1.0's NEWS now says it's 1.1 :-) | 00:13 |
| maxb | * lp:bzr-svn/1.0 | 00:13 |
| maxb | Whilst lp:bzr-svn/1.1 is a stale branch | 00:14 |
| dOxxx | jelmer, vila: bzr-fastimport release would be nice too | 00:17 |
| * vila nods | 00:18 | |
| dOxxx | vila: launchpadlib 1.9.4 ok? just released an hour ago... | 00:20 |
| vila | dOxxx: sure thing | 00:20 |
| vila | dOxxx: but... weren't there some missing dependencies ? | 00:20 |
| dOxxx | vila: such as? | 00:21 |
| vila | dOxxx: I vaguely remember a bug about it but not if it was fixed | 00:21 |
| dOxxx | checking | 00:21 |
| dOxxx | bug 687315 | 00:22 |
| ubot5 | Launchpad bug 687315 in Bazaar Mac Installers "some tests from the launchpad plugin requires lazr.uri" [High,Confirmed] https://launchpad.net/bugs/687315 | 00:22 |
| dOxxx | subject is misleading though | 00:22 |
| dOxxx | still, yeah, that's a problem | 00:23 |
| vila | dOxxx: yeah, I remember now, I tried creating a dedicated package (or whatever the name is there) and get lost | 00:24 |
| dOxxx | vila: a package in the installer definition which includes launchpadlib and all its dependencies? | 00:24 |
| vila | dOxxx: yes, so we can provide it independently from pipeline | 00:26 |
| dOxxx | vila: so pipeline will operate without it? ok... I'll see what I can do. | 00:26 |
| vila | dOxxx: no ! But IIRC launchpadlib is only installed with bzr-pipeline today | 00:29 |
| dOxxx | oh! | 00:29 |
| vila | dOxxx: so if you don't install bzr-pipeline, you don't install launchpadlib either which is what I ended up doing to avoid the test issue | 00:30 |
| vila | s/test/test failure/ | 00:30 |
| vila | dOxxx: the 'clean' way to do it is to package launchpadlib *and* its dependencies which is not trivial so you may not want to try to fix that *now* :) | 00:30 |
| dOxxx | vila: I see. | 00:31 |
| spiv | dOxxx: I think you may have mixed up "Aaron" and "Andrew" in your mail client :) | 00:31 |
| dOxxx | vila: still, as it stands, the installer is not installing bzr-pipeline into a working state unless the user already has the deps for launchpadlib already installed | 00:31 |
| dOxxx | spiv: oh darn I thought I got it the right way round | 00:32 |
| spiv | dOxxx: well the To: line said me but the body said Aaron :) | 00:32 |
| dOxxx | spiv: ugh copy & paste FTL | 00:32 |
| dOxxx | damn... I called nmb Aaraon too. >< | 00:32 |
| dOxxx | Aaron* | 00:32 |
| dOxxx | *sigh* | 00:33 |
| dOxxx | Hopefully I haven't offended you too much :) | 00:33 |
| spiv | Not at all :) | 00:33 |
| * vila bbiab | 00:36 | |
| === Ursinha is now known as Ursinha-afk | ||
| maxb | I *really* need to get myself a hardy VM | 01:13 |
| Peng | I really need to upgrade my Hardy VMs... | 01:15 |
| maxb | hah | 01:17 |
| maxb | :-) | 01:17 |
| maxb | ooh | 01:17 |
| maxb | A volunteer to test ~bzr PPA packages on hardy? :-) | 01:17 |
| Peng | Eep! | 01:18 |
| Peng | maxb: The answer is probably no, but what are you looking for? | 01:19 |
| Peng | Gods, I last pulled bzr.dev 2010-05-14. >.> | 01:20 |
| maxb | Do you use loggerhead? If so, there's a 1.18 package in bzr/proposed to supercede the ancient 1.10 | 01:31 |
| maxb | it built, I'm quite curious whether it works at all | 01:31 |
| maxb | later there will be the bzr upgrade from python-central->python-support to test | 01:32 |
| Peng | Haha...I last pulled lp:loggerhead around 2010-05-14 too. :D | 01:34 |
| dOxxx | vila: hola | 01:43 |
| vila | hmm, weird things happening here, dOxxx , did you get explanation about why the tests were failing ? | 01:44 |
| dOxxx | vila: which tests? | 01:44 |
| vila | the ones mentioned in bug #687315 | 01:45 |
| ubot5 | Launchpad bug 687315 in Bazaar Mac Installers "some tests from the launchpad plugin requires lazr.uri" [High,Confirmed] https://launchpad.net/bugs/687315 | 01:45 |
| dOxxx | vila: nope, I haven't looked at that yet. | 01:46 |
| dOxxx | vila: are you still getting failures with all the pre-reqs installed? | 01:46 |
| vila | dOxxx: can't remember, I restored a working env at the time | 01:48 |
| vila | dOxxx: just checked, launchpadlib is not installed anymore on my laptop | 01:50 |
| vila | dOxxx: well, on the OSX part of it | 01:50 |
| dOxxx | vila: I have bzr 2.3b5 osx 10.6 installer ready for upload | 01:51 |
| vila | dOxxx: cool, did you push the changes ? | 01:52 |
| dOxxx | vila: not yet. I just want to quickly test that thq GUI stuff works | 01:52 |
| dOxxx | the* | 01:52 |
| vila | dOxxx: ok, can't help you there, my 10.6 is at home *and* off :) | 01:52 |
| dOxxx | vila: hmm... gui stuff works but there's at least one weirdness... the dropdown/editbox for the branch URL and target folder in the branch command is very narrow. | 01:55 |
| dOxxx | but I suppose that's why this is a beta | 01:56 |
| vila | dOxxx: isn't there already a bug for that ? | 01:56 |
| dOxxx | vila: it does seem familiar | 01:57 |
| dOxxx | Bug #649430 | 01:58 |
| ubot5 | Launchpad bug 649430 in Bazaar Explorer "text fields in qbranch are very narrow" [Undecided,Incomplete] https://launchpad.net/bugs/649430 | 01:58 |
| dOxxx | alas, I didn't see alexander's question until now | 01:58 |
| dOxxx | I had my mail filters misconfigured and they were bouncing a lot of launchpad bug emails :P | 01:59 |
| vila | weird thing is, I don't remember bialix asking for a screenshot either... or maybe I wasn't involved in building the installers at that point :-/ | 02:04 |
| dOxxx | vila: anyway, I'll upload a screenshot for him now | 02:06 |
| vila | ok | 02:06 |
| dOxxx | vila: pushed. I'm signing and uploading my installer now. | 02:11 |
| vila | ok, pulling here | 02:12 |
| dOxxx | vila: re mergetools... the command_line getter/setter is needed by thq qbzr mp, so I can't really add it there instead. | 02:15 |
| dOxxx | the* | 02:16 |
| vila | that's a nasty dependency you're introducing there, why should qbzr modified a mergetool object ? Why not setting the config option value instead ? | 02:17 |
| dOxxx | for the same reason qbzr doesn't modify .bzr and uses Branch instead | 02:18 |
| vila | ? | 02:19 |
| dOxxx | it's used as a representation of a MergeTool | 02:19 |
| vila | setting a config option is a public API | 02:19 |
| vila | is the option value set from there then ? I didn't see this in your mp | 02:20 |
| dOxxx | the config option is set when qconfig passes the modified MergeTool object to Config.set_merge_tool | 02:20 |
| vila | eeerk | 02:20 |
| dOxxx | ugh wait | 02:21 |
| dOxxx | my brain is not working | 02:21 |
| dOxxx | this damn mp has changed so many times I'm losing track | 02:21 |
| dOxxx | ok | 02:22 |
| dOxxx | config option is set directly by qbzr, basd on the contents of the modified MergeTools object. | 02:22 |
| dOxxx | qconfig gets MergeTool objects from config using get_merge_tools, uses them as an internal storage for it's UI, modifies them as user changes commandline, etc., and then uses the modified contents to call Config.set_user_option | 02:23 |
| vila | keep in mind that users will still be able to set it directly in the config file, that's why I insist on not multiplying the ways to manipulate what is anyway a string | 02:24 |
| dOxxx | except it's two strings. :) | 02:25 |
| dOxxx | but I get the point. | 02:25 |
| vila | two ? | 02:25 |
| dOxxx | name + commandline. | 02:26 |
| vila | stored as one | 02:26 |
| vila | oh, you mean the option name ? | 02:26 |
| dOxxx | I mean as in 'kdiff3 = /usr/bin/kdiff3 etc' | 02:26 |
| dOxxx | two strings | 02:26 |
| dOxxx | user-provided name and commandline | 02:26 |
| vila | yeah, the option name and its value | 02:27 |
| dOxxx | ah yes | 02:27 |
| dOxxx | vila: so now I'm even wondering if we need a MergeTool class at all | 02:28 |
| dOxxx | perhaps the mergetools module could just contain functions for is_available and invoke, based on a string commandline given to the function | 02:29 |
| vila | well, I said that pretty early :) But is_available, at least, needs a home and the default values too | 02:30 |
| dOxxx | yeah well I blame my overly-Javafied brain :) | 02:31 |
| vila | :) | 02:31 |
| dOxxx | so... if MergeTool no longer exists, then config.get_merge_tools should return a dict of name -> commandline | 02:34 |
| dOxxx | and the qconfig stuff can deal with that instead of a list of MergeTool objects | 02:34 |
| dOxxx | does python have sorted dicts? | 02:35 |
| dOxxx | hmm meh probably not the best way to do it | 02:35 |
| dOxxx | vila: okay I'll hack on this some more and see if I can simplify things. | 02:38 |
| dOxxx | vila: osx 10.6 installer is uploaded too | 02:38 |
| vila | dOxxx: don't go too far in the other direction :) I'm fine with your mp with the few tweaks I asked for | 02:39 |
| vila | dOxxx: I'm sorry it was so messy regarding the new config stuff that is still not there :-/ | 02:40 |
| vila | dOxxx: starting build here after a successful f_e -p -u | 02:41 |
| vila | dOxxx: so if I read it right, I won't need to recompile qt after all ? | 02:41 |
| dOxxx | vila: you mean pyqt? | 02:43 |
| dOxxx | vila: I install Qt itself from a pkg downloaded from the nokia site. | 02:44 |
| dOxxx | vila: only pyqt is compiled during the installer build | 02:44 |
| vila | dOxxx: yeah, I meant pyqt | 02:44 |
| dOxxx | vila: okay. you will have to compile that. there is a newer version. | 02:45 |
| vila | dOxxx: err, required ? | 02:46 |
| dOxxx | vila: well, required in that riverbank computing don't keep anything but the must recently release tarball on their website | 02:46 |
| dOxxx | vila: so I'm kinda forced to update to their latest version each time I want to build the installer | 02:47 |
| dOxxx | vila: unless I maintain my own archive of their releases | 02:47 |
| dOxxx | woops | 02:50 |
| vila | grr | 03:01 |
| vila | dOxxx: vm froze :( | 03:02 |
| vila | dOxxx: so I got a pyqt 4.8.2 downloaded but not rebuilt it seems :-/ | 03:05 |
| vila | or not correctly as the build ends up with a link error in sip | 03:05 |
| vila | dOxxx: ring any bell ? | 03:06 |
| dOxxx | vila: odd... | 03:06 |
| vila | urgh, second build gave a different error :( | 03:07 |
| dOxxx | I had a problem with one of the tarballs I downloaded having a CRC error | 03:07 |
| dOxxx | so I had to zap all of them and redownload | 03:07 |
| dOxxx | since I wasn't sure which one | 03:07 |
| dOxxx | but after that it went through fine | 03:07 |
| vila | hmm, so you rebuilt from a clean plate :-/ | 03:09 |
| dOxxx | vila: pretty much | 03:11 |
| dOxxx | ./build.py clean && ./build.py | 03:11 |
| vila | yeah :( third build raised the same error as the first :) | 03:12 |
| vila | be back in a .... biggy ? :D | 03:12 |
| dOxxx | what is it? | 03:12 |
| vila | forget it, I ran clean and restarted the build, I let you know if it fails | 03:13 |
| vila | it was about yyparse missing, smelly (yyparse is usually called from generated parsers) | 03:14 |
| dOxxx | o.O | 03:15 |
| vila | yeah, probably not worth debugging | 03:23 |
| * maxb hugs KVM and vmbuilder | 03:28 | |
| vila | maxb: not funny >-/ | 04:01 |
| vila | :) | 04:01 |
| vila | I wish I could use kvm... | 04:02 |
| dOxxx | night all | 04:04 |
| vila | dOxxx: g'night, build just finished successfully | 04:05 |
| dOxxx | yay! | 04:05 |
| vila | :) | 04:06 |
| maxb | vila: awww.... cpu too old? | 04:07 |
| vila | maxb: nah, gf's laptop not running ubuntu, so I need a vm to run it ! :D | 04:07 |
| maxb | oh | 04:08 |
| maxb | I have a shiny new Core i7 Quad - need to find it some work to to :-) | 04:08 |
| maxb | I wonder how many concurrent guests it could manage | 04:08 |
| vila | maxb: I use Ubuntu on my desktops and I'm hoping to migrate to kvm asap | 04:08 |
| vila | maxb: that's what babune is using :) | 04:09 |
| vila | maxb: hope you got an SSD too | 04:09 |
| maxb | nah, plain old spinning magnets | 04:10 |
| vila | maxb: ooooh at >= 7200 rpm at least ? | 04:13 |
| maxb | oh yes, 7200. I looked out for that carefully | 04:27 |
| maxb | Was very careful not to take the "free upgrade" to a bigger 5400 one | 04:27 |
| fullermd | 7200? Wow, how Dark Ages... | 04:28 |
| sender | Hello, I did a bzr branch remote local --use-existing-dir and ended up with a .bzr dir | 08:45 |
| sender | Now I do an bzr checkout and get an Error 17 | 08:45 |
| sender | Error 17 = file exist | 08:45 |
| sender | anyone an idea | 08:45 |
| sender | ? | 08:45 |
| mgz | sender: file a bug with the exact steps you did to get the error and the full traceback | 09:32 |
| mgz | you can get those from your .bzr.log which `bzr version` will tell you where to find. | 09:33 |
| sender | mgz: thanks for the help, it seems that the branch operation never terminated succesfully as I didnt see '<> revisions ..' so it makes sense that a checkout wouldnt work. I've found a workaround. Thanks! | 09:35 |
| awilkins | #java | 09:36 |
| peitschie_ | hiya pardners :) | 10:34 |
| Nazcafan | hello | 11:00 |
| Nazcafan | I have to solve a conflict where a dev has modified a file and the other one has deleted it. I want to keep it deleted, how do I tell bzr to solve the conflict by removing the file? | 11:00 |
| cjwatson | rm -f filename; bzr resolve filename | 11:07 |
| pfarrell | Hi, I have a question. From years of using svn my brain automatically types version control commands as follows: "bzr -r106 revert" instead of "bzr revert -r106". bzr then complains that it doesn't know what the -r106 command is. Is there any way this can be fixed/changed/improved? | 11:34 |
| pfarrell | I type just about every bzr command wrongly the first time, for exactly this reason .. I find putting the options at the end very unnatural | 11:34 |
| LeoNerd | bzr doesn't mind the argument ordering... | 11:35 |
| LeoNerd | Which version of bzr are you using? until recently, revert didn't take a -r argument at all | 11:35 |
| LeoNerd | bzr revert --help and see if it lists -r | 11:35 |
| pfarrell | [pef@caoimhe-sid:~/src/libadjoint]$ bzr revert --help | grep -- -r | 11:35 |
| pfarrell | -r ARG, --revision=ARG | 11:35 |
| pfarrell | it works when I 'bzr revert -r106' | 11:35 |
| pfarrell | I'm using bzr 2.3b2 | 11:36 |
| LeoNerd | Oooh.. I see. | 11:36 |
| pfarrell | is this fixed in a newer version? should I upgrade? | 11:36 |
| LeoNerd | Yes; you have to put the subcommand first, before its arguments... | 11:36 |
| LeoNerd | bzr -rwhatever command won't work. :) | 11:36 |
| pfarrell | yeah | 11:36 |
| pfarrell | maybe it's just me -- | 11:36 |
| pfarrell | but I find that's the biggest usability problem with bzr | 11:37 |
| pfarrell | but maybe I'm just brain-damaged from years of svn | 11:37 |
| LeoNerd | -r106 bzr revert also wouldn't work ;) | 11:37 |
| pfarrell | yes, but svn -r106 log works, for example | 11:37 |
| pfarrell | :-) | 11:37 |
| LeoNerd | The trouble is that you can't parse the options until you know which subcommand it is. | 11:37 |
| LeoNerd | So bzr has to know it's getting a "revert" command, before it can udnersatnd what -r106 means | 11:37 |
| pfarrell | true. | 11:38 |
| pfarrell | the main bzr command could gather all of the -options it encounters before the command, and then pass them onto it | 11:38 |
| pfarrell | svn subcommands take different arguments too | 11:38 |
| pfarrell | and I assume that is what it is doing under the hood | 11:38 |
| LeoNerd | It couldn't do that easily, because how would it know which ones were split or not? | 11:38 |
| LeoNerd | bzr -abc foo | 11:38 |
| LeoNerd | IS that -a -b -c ? Or is one of them taking a value? -a -b=c -a=bc ? | 11:38 |
| pfarrell | it doesn't need to know | 11:39 |
| pfarrell | store "-abc" in a list of arguments, because "-abc" isn't a recognised command | 11:40 |
| pfarrell | next argument: | 11:40 |
| pfarrell | "foo" is a recognised command, so push "-abc" onto its argument list, along with the rest of the sys.argv | 11:40 |
| LeoNerd | Mmm. Perhaps it could do that. Currently it does not. | 11:40 |
| pfarrell | .. or something like that | 11:40 |
| pfarrell | I mean, it's not that hard to code -- | 11:40 |
| pfarrell | it's just if the bzr development team actually approve of the idea | 11:40 |
| LeoNerd | But then how might you handle bzr -m revert commit file.c | 11:41 |
| pfarrell | hmm | 11:41 |
| pfarrell | true | 11:41 |
| LeoNerd | It's less surprising to everyone, if we know the subcommand must be first. Everyone expects to find it there. | 11:41 |
| pfarrell | I wonder how svn does it | 11:41 |
| LeoNerd | Systems that are easy to predict are easy to use. | 11:41 |
| pfarrell | well, thanks for the discussion | 11:42 |
| maxb | actually the way svn does it is to have a single set of options for all subcommands | 11:54 |
| maxb | this is why certain options have hideously generic help - because there's only one helpstring shared for all subcommands | 11:55 |
| maxb | if's also why svn has so few single letter options - those are allocated globally too | 11:57 |
| maxb | pfarrell: ^^^ | 11:57 |
| pfarrell | maxb: right, thanks | 11:57 |
| pfarrell | I guess I'll just get used to it | 11:58 |
| cjwatson | it was kind of a design decision in svn to enforce maximum possible option consistency across commands; it strikes me as difficult to do with bzr's extensibility | 11:58 |
| cjwatson | (but what do I know) | 11:58 |
| === oubiwann_ is now known as oubiwann | ||
| Nazcafan | thank you cz | 13:15 |
| Nazcafan | thank you cjwatson | 13:15 |
| zyga | hi | 13:29 |
| zyga | I have a branch on lp, whenever I try to push there with bzr+ssh I get readonly transport, bzr lp-login seems to return the right value, can I debug this somehow? | 13:30 |
| zyga | http://paste.ubuntu.com/555772/ | 13:30 |
| zyga | this is the last transaction in .bzr.log | 13:30 |
| zyga | bzr plugins claims I have launchpad 2.2.1 | 13:31 |
| zyga | this is maverick on arm port | 13:31 |
| === oubiwann is now known as oubiwann_ | ||
| zyga | anyone? | 14:05 |
| sobersabre | hi. | 14:07 |
| sobersabre | I wonder how can I "merge" 2 repositories x and y into repo z, when both x and y will reside inside z. | 14:08 |
| sobersabre | both x, y may have interleaved commits in the sense of timeline. | 14:08 |
| sobersabre | i.e. rev2 on x may happen before rev 3 on y, and rev 4 on y may happen before rev 4 on x. | 14:08 |
| zyga | sobersabre: what do you mean by "reside inside z"? | 14:09 |
| sobersabre | let's assume I have a folder /bzr/repos/dir | 14:09 |
| sobersabre | and I have in side it 2 dirs dir1 and dir2 each is a master branch inside dir. | 14:09 |
| sobersabre | I want to make /bzr/repos/all - a repository with dirs dir1, dir2, and it should contain the history of both dir1 and dir2 from /bzr/repos/dir/dir1 and /bzr/repos/dir/dir2 | 14:10 |
| zyga | sobersabre: ah | 14:10 |
| sobersabre | zyga: do you understand me ? | 14:10 |
| zyga | you want to bzr join them | 14:10 |
| sobersabre | so what is the right way to do this ? | 14:11 |
| zyga | sobersabre: I think you're right | 14:11 |
| zyga | sobersabre: do any of the branches have common history? | 14:11 |
| zyga | if so you can just bzr merge them | 14:11 |
| zyga | and bzr mv them to place you want - you will retain whole history | 14:11 |
| sobersabre | zyga: what do you call "common history" ? | 14:11 |
| sobersabre | they are unrelated, like project1 and project2 | 14:11 |
| zyga | sobersabre: by common history I mean is A a branch of B, if no you will have to pass something to merge to make it work | 14:12 |
| zyga | but it will retain all history, I did something like this before | 14:12 |
| sobersabre | both are MASTER branches, not bound to anything, and are not derivatives of neither of the other. | 14:12 |
| sobersabre | zyga: what do I have to pass merge ? | 14:12 |
| zyga | sobersabre: afair -r 1 | 14:14 |
| zyga | sobersabre: bzr merge will complain that branches are unrelated and needs some 'common part', I don't remember but that helped me | 14:15 |
| cjwatson | there's also a merge-into plugin | 14:17 |
| cjwatson | if it were me I'd try both 'bzr merge-into' and 'bzr join', and see which one works more as you expect for ongoing merging over a period of time (assuming you care about ongoing merging) | 14:18 |
| dejj | hello everyone | 14:24 |
| dejj | I wondered if you know of anybody having developed a php-skript that allows uploads and commits to a bazaar branch? | 14:26 |
| zyga | dejj: why would you use php? bzr has a python library with that api | 14:27 |
| dejj | I need to plug it into a repository viewer (Trac maybe), so my users don't need to install bzr. | 14:29 |
| dejj | What's that library called? | 14:29 |
| zyga | dejj: trac? trac supports bzr out of the box AFAIR | 14:29 |
| zyga | dejj: what do you want your users to be able to do? | 14:30 |
| dejj | can you do uploads via the browser? | 14:30 |
| zyga | dejj: uploads of what? commits? | 14:30 |
| dejj | yes | 14:30 |
| zyga | dejj: trac is not designed to do that | 14:30 |
| dejj | then I need to make it do that | 14:31 |
| zyga | dejj: well then you are lucky, bzrlib and trac are both written in python, no php required | 14:31 |
| zyga | dejj: is this for source control of a software or something else? I don't understand why developers would not just use bzr directly | 14:32 |
| dejj | my users aren't developers ;-) | 14:32 |
| dejj | we're currently using Microsoft Sharepoint's web interface to organize files | 14:32 |
| zyga | dejj: are you planning to store large binary files? | 14:33 |
| dejj | unfortunately you can't move any files there and "checkout" means "lock" and it's a total mess | 14:33 |
| zyga | dejj: there is a piece of software that gives you transparent versioning on top of webdav | 14:33 |
| zyga | it's much better than web browser "forms" for doing uploads b | 14:33 |
| zyga | but I'm afraid bzr is not someting that you want to use for sharepoint replacement | 14:34 |
| dejj | why not? | 14:34 |
| dejj | sorry for that broad question | 14:35 |
| zyga | dejj: it's not designed to do that, depending on the amount of data you want to store you might not find something that will scale with your needs | 14:35 |
| zyga | bzr was designd to version source code, not random files of arbitrary size | 14:35 |
| zyga | if you want to use that btw, it's easier to just use the shell integration | 14:36 |
| zyga | so people can commit and update from right-click menu | 14:36 |
| dejj | that would be step 2 in my plan. I can't yet get them to install anything on their computers | 14:37 |
| zyga | it would certainly be easier if you want to let them share files, zero development time for you | 14:37 |
| zyga | may I ask what is the size of the dataset they will work with? | 14:38 |
| dejj | it's not enterprise-sized (yet). about 500mb should be the limit | 14:38 |
| zyga | dejj: 500 of _everything_ _ever_ or just one file that you want to store? | 14:39 |
| sobersabre | cjwatson: if you were talking to me, I want to migrate from having N master branches to 1 master branch, and checking it out or branching it properly. | 14:39 |
| dejj | everything ever | 14:39 |
| zyga | you may also find that http uploads are not the best way of uploading files due to the way http was designed | 14:39 |
| sobersabre | this would ease some deployment stuff. | 14:39 |
| zyga | dejj: in that case it will proably work fine | 14:39 |
| dejj | the problem I'm working around here is actually my users being dead-afraid of anything new in IT. | 14:40 |
| cjwatson | sobersabre: well, the tools I mentioned are the options I know about, anyway (though not a bzr developer) | 14:40 |
| dejj | they know web-uploads, so I have to get them there | 14:40 |
| zyga | dejj: trafficking new software via browser is not really something that different from just installing it for them | 14:40 |
| zyga | dejj: if you do this in the open (the upload-via-web) you might get some help from us | 14:41 |
| poolie | hi all | 14:42 |
| dejj | zyga: I already wrote a buggy script. I does "bzr status", then moves the file, does "bzr add" and "bzr checkin" and that's it. It still makes many assumptions to the environment | 14:42 |
| dejj | zyga: so I thought someone must've that figured out before | 14:42 |
| zyga | dejj: in php? | 14:43 |
| dejj | zyga: unfortunately I don't speak python | 14:43 |
| zyga | dejj: I would encourage you to use bzrlib directly and write this in python with one of the web frameworks | 14:43 |
| zyga | dejj: otherwise it will fall apart quickly | 14:44 |
| zyga | dejj: you need to handle several error situations | 14:44 |
| zyga | dejj: and stuff like locks, etc | 14:44 |
| dejj | zyga: indeed. and you're saying that bzrlib makes this easier than going with php? | 14:46 |
| dejj | (bzrlib + cost of learning python) that is | 14:46 |
| zyga | dejj: well bzrlib _is_ bzr | 14:46 |
| dejj | 0.o | 14:46 |
| zyga | php is most likely the bad approach | 14:46 |
| zyga | and using bzrlib you can just implement this properly, you can look at things like loggerhead to see how to build a web app that integrates with bzr repositories | 14:47 |
| zyga | so you will have lots of code to get you started | 14:47 |
| dejj | that sounds so nice | 14:47 |
| zyga | dejj: apart from a new language and learing about bzrlib enough to commit new files you will have lots of the code already done | 14:48 |
| dejj | the dark side (php) is still very tempting, as my users are currently deleting and re-inserting files in sharepoint. and when they're done they will complain to me that their changes are not consistent with each other | 14:51 |
| dejj | you said > there is a piece of software that gives you transparent versioning on top of webdav | 14:51 |
| === Ursinha-afk is now known as Ursinha | ||
| dejj | zyga: which is that piece of software? | 14:54 |
| === oubiwann_ is now known as oubiwann | ||
| zyga | dejj: re, sorry? which software is that? | 15:17 |
| dejj | zyga: I don't know what you were referring to when you said: "there is a piece of software that gives you transparent versioning on top of webdav". | 15:23 |
| dejj | did you mean bzrlib? | 15:23 |
| zyga | ah no | 15:24 |
| zyga | you can see variour projects like trac that intefrace with bzr repos to get you stated | 15:24 |
| zyga | I mentioned loggerhead | 15:24 |
| zyga | it's the thing that shows you bzr branches on launchpad | 15:24 |
| zyga | I personally hacked on redmine (written in ruby) to do something similar | 15:25 |
| zyga | and I could not use bzrlib so I scripted bzr invocations | 15:25 |
| dejj | loggerhead really looks nice. it's just that I have a trac set up to work with bzr that I thought of hacking into that | 15:25 |
| zyga | trac is good too | 15:26 |
| zyga | trac has bzr integration, it might be in the core or in a separate plugin | 15:26 |
| dejj | zyga: thanks for your help, I'll definitley look into how to use bzrlib to replace my php skript | 15:28 |
| mbt | zyga, you've worked on Redmine for bzr support? | 16:21 |
| maxb | sobersabre: join accomplished? Disregard bzr merge-into unless your branches are stuck in bzr 1.x formats | 16:27 |
| === beuno is now known as beuno-lunch | ||
| cjwatson | maxb: ah, I didn't know that, sorry for the misdirection | 16:59 |
| zyga | mbt: re | 17:07 |
| zyga | mbt: I need to go out for 20 minutes | 17:07 |
| zyga | mbt: but in short, I took what upstream redmine ships and adapted it to work much better with bzr at the time | 17:08 |
| zyga | mbt: if you want to know more, stockpile questions here, I'll answer when I return | 17:08 |
| === frakturfreak_ is now known as frakturfreak | ||
| mbt | zyga, absolutely, thanks | 17:09 |
| mbt | zyga, I'm trying to put together an SCM module for Redmine to use bzr shared repositories, but I'm running into a few problems. To start, I have a few comments on http://www.redmine.org/issues/2799 (starting at comment number 20: http://www.redmine.org/issues/2799#note-20) | 17:11 |
| mbt | zyga, What I have come to is that in order to make things work at all, I think redmine needs additional changes (unless those "changes" can be isolated in the model class, I'm not sure). bzr only needs one thing added to it to make it work efficiently (but it will work without it) | 17:17 |
| zyga | mbt: I need to look after my kids, let me review that ticket, what changes did you find necessary? | 17:42 |
| zyga | mbt: I think that typical shared repo can be mapped to git or svn model with more-than-one branch easily | 17:42 |
| zyga | mbt: if you want I would gladly work on a patch to redmine to get best-of-class bzr support | 17:44 |
| mbt | zyga, It seems that git allows you to pass revision identifiers directly to the repository, thereby enabling Redmine to pass a branch ID or a revision ID and git understands it and can return the requested data. | 17:45 |
| mbt | zyga, Subversion of course uses its own thing, where the repo is treated as an opaque container; that is, Redmine does not attempt to figure out what's a branch and what's a revision, and just treats the whole thing as a list of revisions. | 17:46 |
| mbt | zyga, For bzr, the git model won't work since of course certain operations cannot be performed on repositories. The Subversion model would work, but then one could not support branches as independent browsables and also this would break Redmine's expectation that a single revision number will always map to a single changeset. | 17:47 |
| mbt | What I'm trying to do is get both support for branches in a repo (using the branches dropdown in the Redmine UI for SCM systems that support it) and be able to work in the context of a branch when browsing revisions. | 17:48 |
| mbt | zyga, So, what it would seem to me is that in order to make it work in the "ideal" situation, Redmine needs to have a concept of browsing in the context of a branch, without making the assumption that a branch can be treated as a revision. | 17:49 |
| mbt | zyga, But if that happens, then it'd seem that the goal of implementing proper support for Bazaar would require working on Redmine's core, followed by updating all of the other SCM modules to work with the updated core, and then writing a Bazaar module that can support it as well. | 17:51 |
| mbt | Which I don't mind doing, or collaborating on, but I want to be absolutely sure that it's required, because that's pretty invasive work. | 17:51 |
| zyga | re | 18:00 |
| zyga | mbt: you don't need to use revisions | 18:01 |
| mbt | zyga, what do you mean? | 18:01 |
| zyga | mbt: or more accurately revnos, you should just use revids | 18:01 |
| zyga | mbt: bzr and git are identical in what they store and express | 18:01 |
| mbt | zyga, Still, same problem, you have to refer to them within the context of a branch | 18:01 |
| mbt | "bzr log" doesn't work on a repo; "git log" works on a repo | 18:02 |
| zyga | mbt: the only thing that might be confusing about bzr is that most of the time people operate on revnos - numbers - sometimes in dotted decimal notation | 18:02 |
| zyga | mbt: ah, right | 18:02 |
| zyga | mbt: but you can 1) use bzr revids to map to actual changesets | 18:02 |
| zyga | mbt: and use bzr branches or something similar to discover branches in a given shared repo | 18:03 |
| mbt | zyga, Redmine expects to be able to query the repository directly and doesn't pass along which branch the user is working in | 18:03 |
| mbt | At least as I understand it. | 18:03 |
| mbt | zyga, I noticed that there is two URL properties that Redmine can use, but the CVS modules are the only ones that use them both (root_url and url) | 18:03 |
| mbt | But it looks also like they're both expected to be static, so it's not like they could be used to work with branches, I don't think. | 18:04 |
| zyga | mbt: I don't remember that detail, I did this about a year ago (first attempt) and 6 months ago (second attempt) | 18:05 |
| zyga | mbt: but you can map the thing that redmine operates on to anything oyu want | 18:05 |
| zyga | mbt: so you can easily pass branch + revid | 18:05 |
| zyga | mbt: it's not relevant to rednime, only your scm adapter works with that | 18:05 |
| zyga | mbt: the way I set this up was: | 18:06 |
| mbt | zyga, The question is "how?". e.g., when loading a git branch "master", redmine passes "master" as the revision ID. | 18:06 |
| zyga | mbt: point the repo url to the bzr branch _OR_ bzr shared repo | 18:06 |
| mbt | Then when you browse to a changeset, Redmine passes just the changeset ID. | 18:06 |
| mbt | brb | 18:06 |
| zyga | mbt: hmm, interesting, I did not look at git implementation to be honest, perhaps it just stores that as a cookie somewhere | 18:06 |
| zyga | mbt: the key point to look at is the git scm adapter | 18:06 |
| zyga | mbt: I'm confident it can be mapped 1-to-1 to bzr operations | 18:07 |
| zyga | mbt: things like "log for repo" can be emulated as "log for each branch in repo" on the adapter | 18:07 |
| zyga | mbt: it really depends on what kind of semantics you want to have | 18:07 |
| zyga | mbt: I'm not a daily git user so I don't know what each command does from the top of my head | 18:08 |
| mbt | back. | 18:09 |
| zyga | mbt: I have a fork of redmine somewhere that fixed several annoyances I found | 18:10 |
| mbt | zyga, From reading through the git adapter, everything is just a revision ID. tag names, branch names, and revision IDs are all passed using the exact same mechanism, the revision. | 18:10 |
| zyga | mbt: and we can easily hack the missing bits (repo support et all) | 18:10 |
| mbt | The svn adapters seems to work the same way, but then again the svn adapter isn't branch aware because of the way svn users operate | 18:10 |
| zyga | mbt: in git the changeset is just the sha1 of the commit, I suspect that's all git needs, but branches are different, you can have any number of branches pointing at the exact same commit, does redmine care about that? | 18:11 |
| zyga | mbt: let me find my code first - just a moment | 18:11 |
| mbt | zyga, nope, it just pulls the revid. because git doesn't care about it, redmine doesn't have to. | 18:11 |
| zyga | pulls? do you mean when rednime scans the repository for new stuff? | 18:12 |
| === beuno-lunch is now known as beuno | ||
| mbt | zyga, right, redmine just does a "git log" at the repo level | 18:12 |
| * zyga woke up the redmine server in his attic | 18:12 | |
| zyga | mbt: interesting, what is the order of operations in that case? IMHO a "log" on all branches is meaningless | 18:13 |
| zyga | github does not show a log for every branch, you select the branch first | 18:13 |
| zyga | mbt: do you want to work with git or bzr now? | 18:13 |
| mbt | zyga, redmine just caches the changesets | 18:13 |
| zyga | mbt: right I know | 18:13 |
| mbt | zyga, git will happily show you the changesets for a repo it seems | 18:14 |
| mbt | or maybe that's just git defaulting to showing the changesets for only the "active" branch | 18:14 |
| zyga | mbt: bzr will do the same internally | 18:14 |
| zyga | mbt: we could even write a smarter adapter for bzr that talks directly to bzrlib | 18:15 |
| mbt | <mbt@aloe> ~/Projects/redmine $ bzr log | 18:15 |
| mbt | bzr: ERROR: Not a branch: "/home/mbt/Projects/redmine/.bzr/branch/": location is a repository. | 18:15 |
| zyga | mbt: and talks to redmine over a pipe or something like that, I remember that importing bigger history was very slow | 18:15 |
| zyga | mbt: not like that, at the API level it's the repository you talk to | 18:15 |
| mbt | zyga, I started an adapter along those lines to find all branches | 18:15 |
| zyga | mbt: is your code online? | 18:15 |
| zyga | mbt: I will happily hack with you | 18:15 |
| mbt | not yet (the .py adapter to pull what's what out of a repo is, it's in Redmine Issue #2799) | 18:16 |
| mbt | Also I can push what I've been toying with but it's just Redmine trunk with a nonfunctional bzr adapter | 18:16 |
| mbt | lol | 18:16 |
| zyga | :-) | 18:16 |
| mbt | zyga, do you have ipv6? | 18:17 |
| zyga | mbt: nope | 18:17 |
| zyga | ;-) why? | 18:17 |
| mbt | because if you did I have it on an IPv6 host and could bzr serve it | 18:17 |
| mbt | but no worries | 18:17 |
| mbt | I'll push it to a host with a public IPv4 address | 18:17 |
| mbt | how do launchpad junk branches work? I should be able to do it that way right? | 18:18 |
| zyga | mbt: if it's bzr you can | 18:18 |
| zyga | exactly | 18:18 |
| zyga | it's bzr push lp:~yourlaunchpadid/+junk/anythingyouliek | 18:18 |
| mbt | k 1 sec | 18:18 |
| zyga | I found my adapter | 18:19 |
| zyga | it's really nothing special, just cosmetic changes over the trunk at the time | 18:19 |
| zyga | the better adapter (unfortunately) stayed at samsung :/ | 18:19 |
| mbt | https://code.launchpad.net/~mtrausch/+junk/redmine-bazaar-sr | 18:20 |
| mbt | give LP a few minutes to catch up with it tho lol | 18:20 |
| zyga | getting it now | 18:21 |
| zyga | no, the branch is ready, only UI is lagging | 18:21 |
| mbt | It is ugly, nonfunctional code though | 18:21 |
| zyga | is there a bzr mirror of the upstream redmine tree anywhere? | 18:22 |
| mbt | mostly just experimenting. I stopped with this to investigate how both svn and git work | 18:22 |
| zyga | I'd like to be able to rebase against that finalley | 18:22 |
| mbt | zyga, no, I have a copy that I svn-imported though | 18:22 |
| mbt | i can push that as +junk/redmine-trunk if you want | 18:22 |
| zyga | mbt: svn? AFAIR redmine used something more recent? mercurial? | 18:22 |
| mbt | zyga, no, they officially use svn with a git mirror somewhere | 18:23 |
| poolie | jelmer, what were the things i said i'd do? just clean up that code, or was there something else? | 18:23 |
| zyga | mbt: d'oh | 18:23 |
| mbt | http://redmine.rubyforge.org/svn/trunk is the svn repo | 18:23 |
| mbt | well subtract /trunk from the end of that | 18:23 |
| zyga | mbt: well the git mirror is nice then, it's better than svn :) | 18:23 |
| mbt | lol | 18:23 |
| mbt | I avoid git like the plague if I can. I can't wrap my mind around many of the things it does. | 18:23 |
| mbt | Took me 45 minutes yesterday to figure out how to actually clone with it, since clone with no args but a repo doesn't actually clone | 18:24 |
| zyga | mbt: I dont' use git daily but yeah, first encounter is hard | 18:24 |
| zyga | mbt: but bzr-git is working well enough that you can just bzr get any git repo | 18:25 |
| mbt | To figure out how redmine worked with git, I got a copy of cakephp from github and used that to stufy | 18:25 |
| mbt | *study | 18:25 |
| mbt | That's how I learned that everything is treated as a revision to redmine | 18:25 |
| mbt | It seems that the two key things are (a) revisions are expected to be repo-wide and (b) branches are expected to be revision pointers | 18:26 |
| zyga | got it, diffing my parts now | 18:26 |
| mbt | I could be, and sincerely hope I am, wrong. | 18:26 |
| mbt | On both parts. | 18:26 |
| zyga | give me a moment | 18:26 |
| mbt | kk. | 18:26 |
| zyga | first thing I noticed: i removed the concept of revno as integer (it's not) | 18:27 |
| mbt | right, it can be a 3-decimal number too | 18:28 |
| zyga | ? | 18:28 |
| zyga | 3 decimal? | 18:28 |
| mbt | x.y.z | 18:28 |
| zyga | 1.2.3.4.5.6.7.8 it can go as log as you need | 18:28 |
| mbt | (branched-from, branch-sequence-number, revision) | 18:28 |
| zyga | it's not bound AFAIR (bzr guys can correct me here) | 18:29 |
| zyga | hmm? | 18:29 |
| mbt | zyga, In older versions of bzr, you're correct | 18:29 |
| zyga | are you sure? | 18:29 |
| mbt | zyga, 1 saec | 18:29 |
| mbt | *sec | 18:29 |
| zyga | how do you assign b-seq-number | 18:29 |
| mbt | zyga, since bzr 1.2 it changed: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/zen.html#understanding-revision-numbers | 18:29 |
| zyga | on each merge? | 18:29 |
| zyga | hmm :) | 18:30 |
| * zyga learned something new today | 18:30 | |
| zyga | mbt: looking at your branch | 18:31 |
| zyga | one thing that redmine messes up is commiter vs author | 18:31 |
| zyga | git has the same issue (or did last time I checked) | 18:31 |
| mbt | zyga, Also, I noticed that the current bzr handler has problems with filenames with spaces | 18:32 |
| mbt | it does not use "bzr ls --null" and the non --null output uses spaces for field separation | 18:32 |
| mbt | If only redmine were done in python... lol | 18:33 |
| zyga | hmm | 18:33 |
| zyga | heh, yeah ;-) | 18:33 |
| zyga | well my changes are not perfect, let me see how that works | 18:34 |
| mbt | It is this concept that I think is the most difficult to represent in Redmine: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/zen.html#each-branch-has-its-own-view-of-history | 18:35 |
| zyga | mbt: that's _somewhat_ the same as any other vcs? (I did not read the url yet, just looking at the title) | 18:37 |
| zyga | mbt: is it about branch is a sequence of revisions? | 18:37 |
| spiv | mbt: well alternatively you could say that each revision has its own view of history | 18:37 |
| mbt | Well, in svn revno 5 is the same across all branches. | 18:38 |
| spiv | mbt: a branch at a technical level is essentially just a record of the current tip revision-id, plus some minor details (like the 'nick' and other settings you can store in branch.conf) | 18:38 |
| mbt | In bzr, revno 5 can be different in every single branch (though often it is not). | 18:38 |
| spiv | mbt: well, forget revnos then, and just deal with revids | 18:39 |
| zyga | mbt: in bzr revision id is also the same (AFAIR) | 18:39 |
| mbt | Yes, but then there comes the question of mapping it. Redmine only allows one piece of data to be stored for a changeset in a repository, as I understand it. | 18:39 |
| zyga | mbt: exactly, revid is ~~ same as in git | 18:40 |
| zyga | mbt: and it should be revid | 18:40 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.3b5 is officially out! (rm vila) | ||
| mbt | IOW, using revision IDs would mean presenting them in the UI, AFAICT. | 18:40 |
| zyga | mbt: we can think how to _render_ the revid later | 18:40 |
| zyga | mbt: but that's okay, revids _ARE_ a part of bzr today | 18:40 |
| mbt | Well, first things first. | 18:41 |
| mbt | Redmine queries the repository for revisions, not each branch. Since that cannot be done in bzr directly, either the adapter has to call bzr for every branch and add to the DB if the changeset is not present, or a Python module would do effectively the same thing but simplify the Redmine adapter code. Is that right? | 18:42 |
| zyga | mbt: the adapter can map revids to branches somehow too | 18:43 |
| zyga | mbt: I'm pushing my branch to lp:~zkrynicki/+junk/redmine-bzr | 18:44 |
| mbt | Seems the bzrlib.repository.Repository class has a method all_revision_ids(self) that would be useful, but it's deprecated. | 18:44 |
| zyga | mbt: I'll need a moment to setup my working space for redmine on this system, for various reasons I'm using plain text console and no X | 18:44 |
| Ramosa | why not #bazaar | 18:44 |
| mbt | Ramosa, are you suggesting a change of venue for this discussion? | 18:45 |
| Ramosa | i was idling in there for some hours before i figured it out :-p | 18:45 |
| zyga | Ramosa: bzr is shorter, that's as good as it gets | 18:45 |
| Ramosa | uhm.. i type faster if i can actually pronounce it :) | 18:46 |
| mbt | I should file a bug on bzrlib.repository.Repository.find_branches | 18:46 |
| zyga | it's beeziar | 18:46 |
| zyga | for me at least ;-] | 18:46 |
| Ramosa | bazinga | 18:47 |
| zyga | mbt: what's the problem with that API? | 18:47 |
| mbt | For the svn-import'd redmine module, find_branches(False) takes like 4 seconds to run. But it should be able to return near-instantly. | 18:47 |
| mbt | zyga, they seem to have a policy of not storing derivable data | 18:47 |
| zyga | mbt: hmm, interesting, what does bzr store in that case? I never used bzr-svn repositories before | 18:48 |
| mbt | zyga, It's the same for all shared-repos | 18:48 |
| mbt | zyga, They probe the filesystem to find branches | 18:48 |
| zyga | mbt: I thougth that all you need to get revisions is to scan for subtrees with .bzr and figure out the type of bzrdir | 18:48 |
| mbt | zyga, Instead of storing a list of known branches in the repo's .bzr dir | 18:48 |
| zyga | mbt: right | 18:48 |
| zyga | mbt: ah I see what you mean | 18:48 |
| mbt | Well, you have to scan for subtrees and then see if they are part of the repo (e.g., using the repo for storage) | 18:49 |
| Ramosa | i can't decide how to use bazaar as a single developer, 2 pc's (windows) .. if to develop locally, and then somehow merge when both computers are on, or invest in a server (not online, has to be hosted at me) | 18:49 |
| zyga | mbt: it's probably more complex in that case | 18:49 |
| mbt | tis possible to have a branch within a branch that does not | 18:49 |
| zyga | mbt: git uses identical model | 18:49 |
| zyga | mbt: but just looks at one directory | 18:49 |
| Ramosa | i presume bzr+ssh doesnt work on windows | 18:49 |
| zyga | mbt: it's still a branch | 18:49 |
| mbt | e.g., bzr *could* explicitly store a branch list (because shared-repo branches are created by bzr or bzrlib itself) | 18:49 |
| zyga | mbt: then you need to decide if you look for _any_ branches or just branches in a shared repo | 18:50 |
| spiv | See the bzr-colo plugin, for example. | 18:50 |
| mbt | but it chooses not do, because that information can be derived from what's on the filesystem | 18:50 |
| spiv | (which colocates multiple branches in one directory, similar to how git is used) | 18:50 |
| zyga | spiv: what do you mean | 18:50 |
| zyga | spiv: right, I use it daily | 18:50 |
| mbt | spiv, goal is to add support for bzr without requiring any plugins | 18:51 |
| zyga | mbt: it's not a plugin that adds new magic foo, it's just new UI | 18:51 |
| mbt | rather without requiring any bzr plugins | 18:51 |
| zyga | mbt: the plugin uses all the existing stuff from bzr | 18:51 |
| spiv | Colocated branches of some form will become part of the core. Most of the code and APIs have already landed. | 18:51 |
| spiv | The core basically just lacks the UI at the moment. | 18:51 |
| mbt | though if it can be done with nothing other than bzrlib, shipping a helper .py module with redmine is probably not out of the question | 18:52 |
| zyga | mbt: that's exactly the case | 18:52 |
| mbt | but then what happens when you push multiple branches. | 18:52 |
| zyga | mbt: but you must define what redmine will show in that case as bzr has no 'standard' colocated format yet | 18:53 |
| spiv | Obviously that doesn't help you much if you want to stick to features already released, but in case you are comfortable with dealing with features that are coming in the near future you can rely on colo stuff. | 18:53 |
| zyga | mbt: you push multiple branches, that's all | 18:53 |
| mbt | spiv, I (personally) am not concerned with pre-2.0 compatibility | 18:53 |
| zyga | mbt: you push to a colo-ified place, it just works | 18:53 |
| mbt | zyga, without the colo plugin installed on the server side? | 18:54 |
| zyga | mbt: not really | 18:54 |
| zyga | mbt: but I'm not sure really | 18:54 |
| zyga | mbt: I don't know how bzr works on the smart server case | 18:54 |
| zyga | mbt: remember that colo does not add _any_ new features | 18:54 |
| zyga | mbt: it's just UI | 18:54 |
| mbt | I know this much: I push and pull to bzr+ssh all the time in our environment | 18:54 |
| zyga | mbt: the only tricky part is the initial repository (colo repository) layout | 18:55 |
| mbt | Being that this should work for stock setups | 18:58 |
| mbt | damn enter button. Being that this should work for stock setups, a colo repo would be good if completely transparent, but probably not otherwise | 18:58 |
| zyga | mbt: IMHO there is no need to rely on colo today | 18:59 |
| zyga | mbt: apart from ensuring that redmine will pick up the colo-ified repo and work as expected | 18:59 |
| mbt | zyga, agreed | 18:59 |
| * zyga remebers the pain of setting up redmine on ubuntu the first time | 19:00 | |
| zyga | eh ruby community :/ | 19:00 |
| mbt | zyga, Getting redmine running for me was actually not bad | 19:01 |
| zyga | mbt: well you can apt-get install it easily | 19:01 |
| zyga | mbt: unless you want to run trunk that is | 19:01 |
| mbt | Running trunk is what I am doing | 19:01 |
| mbt | right out of the repo | 19:01 |
| zyga | I did not manage to get this working without using gem directly | 19:01 |
| mbt | well, branch | 19:01 |
| mbt | lol | 19:01 |
| mbt | I just aptitude installed ruby and then gem installed rails and I think that was it | 19:01 |
| zyga | hmm, I was using lucid and before that .... what was it? :-) anyway I had to update a lot of gems | 19:02 |
| mbt | My desktop is always running the latest stable or latest+1 testing releases | 19:03 |
| mbt | lol | 19:03 |
| mbt | But I'm just running in-tree with ./script/server | 19:04 |
| zyga | I'll be right back | 19:04 |
| mbt | k | 19:04 |
| mbt | I know that in the adapter, Redmine wants revisions to work at the repo level. Seems that bzrlib.repository.Repository.all_revision_ids() works, deprecation aside | 19:10 |
| mbt | So, a .py helper could easily pull all changesets. Though I'm sure that also includes ones that don't exist in any branches any longer. | 19:10 |
| mbt-mobile | when you select a branch in the redmine UI, it populates the revision field with the branch name, and submits. | 19:14 |
| mbt | zyga, welcome back lol | 19:20 |
| zyga | mbt: right ;) | 19:20 |
| zyga | mbt: it seems current trunk does not work with maverik deps, I need one more moment to setup my instance | 19:20 |
| zyga | mbt: I pushed a branch based on your work | 19:20 |
| mbt | So it's possible to query all revisions in a repo and theroetically use that information to populate Redmine's database | 19:20 |
| zyga | mbt: sure | 19:21 |
| mbt | But what's not possible (either at all, or efficiently) is to reconcile the repo's stored revisions with the database and Redmine wants the ability to check to see if a repo has new revisions or not | 19:21 |
| zyga | hmm | 19:21 |
| zyga | right that part sucked | 19:21 |
| zyga | redmine used revnos to see if there's somethinhg new | 19:22 |
| zyga | well | 19:22 |
| zyga | you can do this | 19:22 |
| zyga | for each repo | 19:22 |
| zyga | sorry, start over | 19:22 |
| mbt | git's adapter handles it by checking (based on date) the repo revisions | 19:22 |
| zyga | for each brach, for each revision, import changeset | 19:22 |
| mbt | But I see nothing in bzrlib to do the same thing at the repository level. | 19:23 |
| zyga | we can store the revid of the tree assuming that the tree does not changes (think --overwrite) | 19:23 |
| mbt | If Redmine treated branches as if they were first-class subordinates of a repository, that would work. | 19:23 |
| zyga | perhaps it's better to patch redmine more then | 19:23 |
| zyga | I don't know bzr internals that good, is it possible to efficiently terate revisions that happened after a specific revision? | 19:24 |
| mbt | But it appears that Redmine thinks of revisions as first-class subordinates of repositories, and a branch as a pointer to a changeset | 19:24 |
| zyga | if so then we can do that easily | 19:24 |
| zyga | mbt: probably because it's git/svn centric today | 19:24 |
| mbt | zyga, Within the context of a branch that appears to be the case. | 19:24 |
| mbt | Within the context of a repository it appears to be possible but only after loading all changesets and figuring out the relationships between them. | 19:24 |
| mbt | which, for a repo the size of my typical projects might not take that long, but e.g., for a repo with MySQL would probably take literally forever | 19:25 |
| zyga | mbt: are you sure, you just do the same for each branch | 19:25 |
| zyga | mbt: remember, you just _add_ changesets lazily | 19:26 |
| zyga | mbt: you iterate over them in bzr branch | 19:26 |
| mbt | Right, but I don't think Redmine uses the data in the VCS itself for display | 19:27 |
| zyga | mbt: for revision in branch.revisions_since(last_imported_revision_for_this_branch): if revision_not_in_redmine: import_revision(revision) | 19:27 |
| zyga | mbt: what do you mean | 19:27 |
| mbt | I think Redmine will use the output of the VCS tool to determine if (a) its changeset database is up to date and (b) possibly to render a tree for a specific revision | 19:28 |
| mbt | as well as for cat, diff, and annotate operations | 19:28 |
| mbt | But to display changesets I think it leans upon its own DB | 19:28 |
| zyga | you are correct | 19:29 |
| zyga | I found one issue though | 19:29 |
| zyga | for listing files it relies on bzr ls | 19:29 |
| mbt | Yes. | 19:29 |
| zyga | and that does not provide file sizes | 19:29 |
| mbt | No, it does not. | 19:29 |
| zyga | without custom python module you cannot get this information | 19:29 |
| mbt | The more and more I think about this, the more I think that proper support will (no matter what) include a helper .py | 19:30 |
| zyga | yeah, I feel the same | 19:30 |
| zyga | _OR_ | 19:30 |
| mbt | Dumb question | 19:30 |
| mbt | Can one embed Python into Ruby? | 19:30 |
| mbt | e.g., if one is using bzr, then it's a given that both Python and bzrlib are installed | 19:31 |
| zyga | a new bzr subcommand that exposes some crappy xml or other data structure as a standard bzr feature | 19:31 |
| zyga | mbt: not that I think | 19:31 |
| zyga | mbt: I think an rpc/pipe method is the best way of doing that without something that can break easily | 19:31 |
| === Ursinha is now known as Ursinha-afk | ||
| mbt | Is it possible to, say, use the bazaar adapter class to load Python and "thunk" between Redmine and bzrlib? | 19:31 |
| zyga | mbt: think about the plethora of python/ruby implementations | 19:31 |
| mbt | Ruby is all new to me, so I don't know. | 19:31 |
| zyga | mbt: I'd explicitly pipe that to the helper | 19:32 |
| mbt | Before five or six days ago, I'd never looked at a single line of Ruby code. | 19:32 |
| zyga | separate process | 19:32 |
| mbt | So, maybe create something like bzr, but that can be IO.popen'ed and provide a chatty interactive session-like wrapper around bzrlib? | 19:32 |
| zyga | hmm it's also tricky | 19:33 |
| zyga | you must remember that redmine itself may run on number of servers | 19:33 |
| zyga | in various thread/process config | 19:34 |
| mbt | Right. | 19:34 |
| mbt | Which also means that it might access a bzr repo over-the-net | 19:34 |
| zyga | I'd say that to be safe and efficient the python part should run | 19:34 |
| mbt | It still requires bzr on the same host that redmine is on, which means that it's a given that python and bzrlib are available. | 19:34 |
| zyga | (just like that, like a daemon, or via apache+python, and expose simple xml/json-rpc | 19:34 |
| zyga | mbt: not really, you could even package the program as an exe file for windows, it's just something you can later call from ruby | 19:35 |
| zyga | this way you avoid spawing random number of processes | 19:35 |
| zyga | and can also scale the bzr part as you normally do with any other web app | 19:36 |
| mbt-mobile | it spawns bzr / git / svn anyway | 19:36 |
| zyga | and in the future this might be a part of something like bzr plugin that you can just bzr redmine-serve | 19:36 |
| zyga | mbt: currently, it does need to (it's actually very slow exactly because of that) | 19:36 |
| zyga | mbt: you can just call xml-rpc instead, no loading of python and processing tiny bits of data in one go | 19:37 |
| mbt-mobile | one page view of an up to date git repo calls (via shellout) git ~ 10 times | 19:37 |
| zyga | mbt: git is native, it loads faster, python will gain more speed if you keep it running | 19:37 |
| zyga | mbt: and just do 10 xml-rpc calls | 19:38 |
| * zyga runs away for another moment | 19:38 | |
| mbt-mobile | i thought git was in perl with some c | 19:38 |
| mbt-mobile | kk | 19:39 |
| mbt | Well, for now, I think that any way it can be done is good. This is, IMHO, one downfall of bzrlib being written in Python; it's not terribly easy to use it from other languages. If it were just a single .so using the C ABI... | 19:47 |
| mbt | So, if a helper module is going to be required in any event, I suppose the thing to do is figure out exactly what its interface needs to be so that it supports all of the things that Redmine wants. | 19:50 |
| mbt | And in a way that redmine wants. | 19:50 |
| mbt | From my read-through, each adapter in Redmine can/should have the methods: info, entry, entries, branches, default_branch, properties, revisions, diff, cat. | 19:52 |
| mbt | Models are expected to have: branches, tags, properties, cat, diff, relative_path, latest_changeset, latest_changesets, and possibly others. | 19:54 |
| === Ursinha-afk is now known as Ursinha | ||
| mbt | bzrlib.branch.Branch.revision_history() provides "[the] sequence of revision ids on this branch", so that can be used to see the ordering of the commits. | 19:58 |
| mbt | Conversion of revision-ids to revision-numbers appears to be a somewhat expensive operation as well (using Branch.revision_id_to_revno for all of the revisions in a repo) so doing that frequently would not be a good idea | 20:02 |
| zyga | mbt: re | 20:25 |
| mbt | zyga, hrm? | 20:27 |
| jelmer | poolie: sorry, didn't see your message on IRC earlier | 20:28 |
| jelmer | poolie: I don't think there was anything else than what you already commented in the MP. | 20:28 |
| zyga | mbt: how do you know that revno<->revid conversion is expensive? | 20:36 |
| zyga | mbt: we could cache the revid but I'm not sure it's stable | 20:37 |
| mbt | Because I am playing with the library | 20:37 |
| mbt | Getting all revids is very fast | 20:37 |
| mbt | converting a single revid to a revno is apparently fast, but doing so for nearly 4,000 revisions took long enough that I Ctrl+C'd it | 20:37 |
| mbt | It ran at 100% CPU for at least 1 minute | 20:38 |
| mbt | What I am trying to do now is see if I can write a handful of functions to go in a helper module that will do what Redmine expects, but before I can do that I have to get a little more familiar with bzrlib | 20:39 |
| mbt-mobile | i expected to use bzr but as you noted it does not output all of the info needed to work with branches w/o working trees | 20:40 |
| zyga | mbt: I see | 20:41 |
| zyga | mbt: perhaps some bzr hackers could tell us what's the best way to approach the problem | 20:41 |
| zyga | mbt: did you check if bzr log is faste than what you called? | 20:41 |
| mbt-mobile | not yet. | 20:41 |
| zyga | mbt: bzr log does convert revisions | 20:42 |
| mbt-mobile | it does but it also blocks on terminal io | 20:42 |
| zyga | mbt: or perhaps, bzr log cheats and walks a well-known tree of revids somehow, that would be nice | 20:42 |
| spiv | bzr log -n0 has to calculate the revno for every rev. | 20:42 |
| zyga | mbt: sorry about being away all the time, kids.sleep() raises exceptions ;-) | 20:43 |
| mbt-mobile | LOL i know the feeling | 20:43 |
| zyga | spiv: what is the complexity of such operation? | 20:43 |
| mbt-mobile | mine is down for a nap | 20:43 |
| zyga | spiv: and is there any way to cheat | 20:43 |
| spiv | zyga: not linear, but I can do "bzr log -n0 > /dev/null" of bzr in less than 5.5s (33787 revs, mostly in non-mainline revs from many merges, some quite large) | 20:45 |
| mbt-mobile | hrm | 20:45 |
| spiv | And log is of course doing a bunch more work than just calculating dotted revnos. | 20:45 |
| mbt-mobile | will be back @ comp in just a sec | 20:45 |
| zyga | spiv: is the number stable, once calculated? | 20:46 |
| zyga | can we just cache it | 20:46 |
| spiv | No, a revid's revno in a branch can change depending on future merges. | 20:46 |
| mbt-mobile | no, uncommit and overwrites can reorder | 20:46 |
| spiv | mbt-mobile: well, you can disallow those cases by setting append_revisions_only on a branch... | 20:47 |
| zyga | spiv: right but if overwrite or uncommit happens we can purge the cache | 20:47 |
| mbt-mobile | spiv how does a merge afect revnos? crisscrossing or something? | 20:47 |
| zyga | spiv: that's not something that happens daily | 20:47 |
| spiv | You may be interested in the bzr-history-db or bzr-historycache plugins. | 20:48 |
| zyga | hmm | 20:48 |
| zyga | (smarter) | 20:48 |
| zyga | if it caches that on bzr side it makes our interface simple and our db uncomplicated | 20:48 |
| Ramosa | being a single developer, would you have branches? | 20:48 |
| spiv | zyga: for the duration of a read_lock bzr caches lots of stuff | 20:48 |
| mbt-mobile | can bzr be called w/ an arbitrary plugin dir? | 20:48 |
| zyga | Ramosa: nobody talks about single developres | 20:48 |
| spiv | zyga: that makes this sort of thing pretty quick typically | 20:49 |
| zyga | spiv: I see | 20:49 |
| zyga | spiv: frankly I think that having a helper service with some rpc api will fix performance | 20:49 |
| spiv | mbt-mobile: yes, see BZR_PLUGIN_PATH and BZR_PLUGINS_AT env vars in the doc | 20:49 |
| mbt-mobile | ramosa: i use branches on solo projects all the time | 20:49 |
| zyga | spiv: running bzr for each and every revision all the time is slow | 20:49 |
| spiv | Doing things one revision at a time is slow. | 20:50 |
| zyga | spiv: well redmine scm integration for bzr is in need of love, that's the way it works currently | 20:50 |
| mbt-mobile | zyga, helper svc would be a nice improvement later i think | 20:51 |
| mbt-mobile | redmine needs tighter vcs integration, too. | 20:51 |
| zyga | mbt-mobile: what do you mean by tighter? | 20:52 |
| mbt | Calling any binary 10 times or more (or any binary once that takes a long time, like an initial page view of a git repo) adds time to each request, obviously. | 20:52 |
| mbt | zyga, I mean interfaces other than IO.popen for all of them. | 20:53 |
| zyga | mbt: right but solving that for all things in ruby is hard | 20:53 |
| zyga | mbt: I don't know of any native binding for scms and rub | 20:53 |
| zyga | mbt: I'll try to setup django xml-rpc app that gives you the same primitives as redmine requires | 20:54 |
| zyga | mbt: I'll see how that works | 20:54 |
| mbt | zyga, I know that for Python, I'd write Cython libraries as extension modules to call (at least for C-language SCMs) into the SCM library directly, for compiled ones that have an .so or can be ldopen()'d. | 20:54 |
| zyga | mbt: well ruby and python == fail | 20:55 |
| zyga | mbt: git has no c api | 20:55 |
| zyga | mbt: bzr and hg use python | 20:55 |
| zyga | mbt: svn has api so that might work but svn is the old guy that only old people talk to ;P | 20:55 |
| zyga | mbt: darcs and others are too exotic | 20:55 |
| mbt | zyga, can't C code also call Python code? | 20:56 |
| zyga | mbt: or have dedicated "export" stuff | 20:56 |
| zyga | mbt: it's not that simple | 20:56 |
| zyga | mbt: python and ruby use different gc | 20:56 |
| zyga | mbt: I'm pretty sure that attempting to bridge them would be very hard | 20:56 |
| zyga | mbt: signals, threading, gc - all of that is hard to bridge, especially since both use different methods for that | 20:57 |
| mbt | zyga, I remember reading about a (I think) Python to Ruby bridge, but that's the wrong direction anyway. | 20:57 |
| zyga | mbt: jython and jruby are closer | 20:57 |
| mbt | IDK if Redmine will run under Jruby, but bzrlib doesn't work under Jython. | 20:57 |
| GaryvdM | zyga, mbt: I'm not sure what data you trying to get from bzr, but maybe there is a way to get what you want with one subprocess call (or at least less than ten)? | 20:59 |
| GaryvdM | or use a deamon of sorts... | 20:59 |
| mbt | GaryvdM, Redmine could, for that matter, cache the output of a single command for the duration of a single request. A lot of these hits are the same command 8 times in a row or something insane like that. | 21:00 |
| * GaryvdM open log to get context. | 21:00 | |
| mbt | GaryvdM, it'd only have to be called once if the result were cached, but that is an optimization to be made in Redmine itself, not its VCS interface, I'd think. | 21:00 |
| zyga | mbt: oh, that's not good | 21:01 |
| mbt | (e.g., Redmine could subclass IO.popen and when it notices that the same command is going to be called again, assume the call is idempotent and return the value from the last one, instead of creating a subprocess) | 21:01 |
| mbt | Or maybe whitelist certain idempotent commands. | 21:02 |
| mbt | But again, not my focus today. | 21:02 |
| zyga | lifeless: jython anyone? | 21:02 |
| zyga | ;-) | 21:02 |
| zyga | I'm sure bzr will work with jython | 21:02 |
| zyga | GaryvdM: that's our plan now | 21:02 |
| zyga | GaryvdM: wrap bzr-looking-at-one-repo-with-branches with some daemon/webservice and expose the stuff we need as rpc calls | 21:02 |
| zyga | spiv: is it safe to keep one bzrlib.branch.Branch instance for very long | 21:02 |
| zyga | mbt: right but to be safe I'd go with rpc first, you can then optimize what redmine does but redmine is a moving target | 21:02 |
| zyga | mbt: and you also cannot cache that easily without invalidation notification, something that is best done in bzr side | 21:02 |
| zyga | mbt: you'll get stale cache with that approach IMHO | 21:02 |
| * zyga makes up excuses not to write too much ruby | 21:03 | |
| mbt | zyga, lol | 21:03 |
| mbt | A secondary goal is to make this something that I can "sell" to a Redmine committer. | 21:03 |
| mbt | I do *not* want to maintain a local fork if at all possible. | 21:03 |
| zyga | mbt: I think it can fly, espetially that bzr is not really well supported now | 21:04 |
| mbt | zyga, You mentioned Django earlier? | 21:04 |
| zyga | mbt: right, that's my recent job focus so I'm happy to build xml-rpc service that talks bzr | 21:04 |
| zyga | mbt: and hopefully it's going to be easy to work with xml-rpc in ruby | 21:04 |
| mbt | zyga, Would there, I presume, be a way to knock it down to one .py file that has no dependencies other than bzrlib's dependencies as a refinement? | 21:04 |
| zyga | spiv: what is the protocol that bzr serve talks? is it anything well-known over the wire or just custom? | 21:05 |
| zyga | mbt: yes, the django parts would just xmlrpc that away | 21:05 |
| zyga | mbt: the core bits would certainly need pure bzr to work | 21:05 |
| zyga | spiv: I'm asking to understand if it's easier to extend bzr serve and talk to that directly | 21:06 |
| glyph | So, I just got bitten by https://bugs.launchpad.net/bzr/+bug/673884 again in the middle of pushing a gigantic branch | 21:06 |
| mbt | zyga, plugins can extend bzr serve (e.g., loggerhead can be used as bzr serve --http) | 21:06 |
| zyga | mbt: oh, cool, I need to look at that | 21:07 |
| glyph | the help options for rebase don't really explain what -r does | 21:07 |
| zyga | mbt: okay, so the rpc bits can be dediced upon later, once we have the guts working without shelling out to bzr | 21:07 |
| mbt | zyga, I'm fine with a first "draft" shelling out to *something*, just such that it can work. | 21:08 |
| glyph | I tried to rebase onto the last dpushed revision but I'm getting a conflict on all the added files (since the point of divergence is before they were added, bzr seems to think they have different file IDs) | 21:12 |
| glyph | is there some way to ask it to do a dumb merge and just treat all the patches as patches? | 21:12 |
| glyph | all the --merge-type options just give me tracebacks. | 21:13 |
| spiv | zyga: custom | 21:14 |
| zyga | spiv: thanks | 21:15 |
| spiv | glyph: I am summoning jelmer | 21:16 |
| spiv | zyga: there are some elementary docs in the tree in doc/developers/network-protocol.txt, and bzrlib/remote.py and bzrlib/smart/client.py are probably some of the more interesting bits of the client implementation. | 21:17 |
| zyga | spiv: if it's non standard it's not much use for us in this case, the goal is to minimize the ruby part as much as possible and implementing the same protocol would probably take some time, I think that off-the-shelf rpc will work better for this | 21:18 |
| glyph | spiv: the output of '--weave', for example - http://dpaste.com/333668/ | 21:19 |
| mbt | Woot. | 21:19 |
| spiv | zyga: you may also be interested in the bzr-service plugin | 21:19 |
| zyga | spiv: that's something new | 21:19 |
| zyga | let me look it up | 21:19 |
| spiv | zyga: and maybe stuff like bzr-xmloutput etc. Tools like eclipse have some overlapping requirements with you I suspect | 21:20 |
| zyga | spiv: yeah that's true | 21:20 |
| zyga | spiv: I heard about xmloutput | 21:20 |
| glyph | spiv: I think that my future solution for using bzr offline is going to be making a gigantic patch and then manually applying it, since dpush is apparently too unreliable to use in practice :-\ | 21:20 |
| spiv | zyga: bzr devs are a bit distracted this week (we're at a sprint) so I'd ask on the mailing list as well as here on IRC | 21:21 |
| glyph | at least with the SVN servers I've tried it with, it will always crap out around the 50-revision mark (earlier if I'm using https) | 21:21 |
| zyga | spiv: dallas? | 21:21 |
| spiv | Yeah | 21:21 |
| zyga | spiv: I just left :-) | 21:21 |
| spiv | Congrats ;) | 21:21 |
| zyga | hehe, US-medival-burger-castle will forever hount my mind | 21:22 |
| GaryvdM | Hi vila - I guess you are awake cause you are in Dallas? | 21:35 |
| vila | GaryvdM: !!!!!!!! yeeeehaaaaaa | 21:35 |
| vila | yeah, I'm in Dallas :) | 21:35 |
| vila | GaryvdM: middle of the night for you thought, right ? | 21:36 |
| vila | though | 21:36 |
| GaryvdM | vila: nearly | 21:36 |
| GaryvdM | vila: for the mac installer scripts - is there anything to look for new releases of plugins? | 21:37 |
| mbt | Joy, a spontaneous reboot on my phone. | 21:37 |
| vila | GaryvdM: errr, you mean to get inspiration for the windows installers ? | 21:37 |
| GaryvdM | vila yes | 21:37 |
| * vila checks | 21:38 | |
| GaryvdM | I manually do > for plugin in plugins: bzr tags -d lp:plugin | 21:38 |
| zyga | mbt: what phone is that | 21:38 |
| vila | sponteaneous reboot are so fun, we should have more of them, preferably in unexpected places | 21:39 |
| mbt-mobile | zyga, nightly build of CM7 :) | 21:39 |
| zyga | CM? | 21:39 |
| mbt-mobile | unexpected but not surprising. not even beta yet lol | 21:39 |
| mbt-mobile | cyanogenmod. | 21:39 |
| zyga | ah | 21:39 |
| zyga | jdroid | 21:40 |
| vila | GaryvdM: bzr-upload has a 1.0.0 release, hmmm, I'm not sure I properly tagged it though | 21:40 |
| zyga | mbt-mobile: out of curiosity, what is your interest in redmine, most folsk who use bzr also use lp.net | 21:40 |
| mbt-mobile | zyga: client | 21:41 |
| vila | GaryvdM: launchpadlib has a 1.9.4 release | 21:41 |
| mbt-mobile | zyga, to make my life easier bc they wont use lp | 21:41 |
| mbt-mobile | zyga, so really for me. been using text files for too long to manage this sort of stuff. | 21:42 |
| zyga | mbt: manage what? | 21:42 |
| zyga | mbt: projects? | 21:43 |
| vila | GaryvdM: the rest is less clear, you may look at revno 113 (the last one) in the 2.3 mac-installer branch | 21:43 |
| vila | GaryvdM: hmm, I should be able to provide an lp url for that, just a sec | 21:43 |
| mbt-mobile | zyga, yep. Putting it all in one place is a good thing. | 21:43 |
| GaryvdM | vila: we not yet including lauchpadlib in the windows installer. What plugin uses it? | 21:44 |
| vila | GaryvdM: http://bazaar.launchpad.net/~bzr-mac/bzr-mac-installers/2.3/revision/113 | 21:44 |
| vila | GaryvdM: bzr-pipeline | 21:44 |
| mbt | zyga, I'm a freelancer, and I manage a lot of proprietary things (sadly). | 21:44 |
| GaryvdM | ah - yes | 21:45 |
| vila | GaryvdM: but be careful that launchpadlib has a lot of depedencies and we don't (yet) carry them all | 21:45 |
| zyga | mbt: I see, thanks for telling me | 21:45 |
| vila | GaryvdM: we (mac packagers) | 21:45 |
| GaryvdM | vila: yes - I'll leave that for now... | 21:45 |
| Ramosa | i cant decide what workspace model to use.. the documentation doesn't give me enough knowledge to take a sane decision | 21:46 |
| vila | doxxx got it Right I think by freezing on revnos for plugins that don't have proper releases or series yet (like qbzr does) | 21:46 |
| mbt | zyga, But since presently I manage things in different systems, I started hunting for something (and writing something as well). | 21:46 |
| spiv | glyph: jelmer is now sitting next to me | 21:46 |
| vila | GaryvdM: dunno if you have the same detailed way to describe which plugin versions you embed on the windows side | 21:47 |
| mbt | zyga, I wound up finding Redmine, which is perfect except for this one thing which was already an issue in the RM tracker. | 21:47 |
| zyga | mbt: if you want I can work with you to make this happen | 21:47 |
| zyga | mbt: lp.net is perferct for hosting code but I find it lacking for project management | 21:48 |
| GaryvdM | vila: There is - I'll get the url in a sec. | 21:48 |
| vila | GaryvdM: cool | 21:48 |
| mbt | zyga, Absolutely. One other thing I liked about finding Redmine was that it was a lot easier to get going than a local instance of Launchpad. | 21:48 |
| jelmer | hi glyph | 21:48 |
| jelmer | glyph: spiv mentioned you wre having issues with dpush? | 21:48 |
| glyph | jelmer: a known issue :) | 21:51 |
| glyph | jelmer: https://bugs.launchpad.net/bzr/+bug/673884 | 21:51 |
| mbt | zyga, am reading through the log code now | 21:51 |
| glyph | jelmer: I was wondering if I could work around it | 21:51 |
| glyph | it looks like if the branch adds files, I'm pretty hosed | 21:51 |
| GaryvdM | vila: http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/view/head:/bazaar_releases.py | 21:52 |
| GaryvdM | similar idea to the mac config.py file - different in details | 21:53 |
| mbt | I have all the information that Redmine needs, I think, save for last-revision | 21:53 |
| mbt | for a list of entries, anyway | 21:53 |
| jelmer | glyph: ah, hmm | 21:53 |
| mbt | can't figure out how to get the last revision for a file or directory from the list of files in a revisiontree. | 21:54 |
| vila | GaryvdM: excellent ! | 21:55 |
| zyga | hmmm | 21:56 |
| zyga | mbt: last revision for a directory? | 21:56 |
| zyga | mbt: the "svn/cvs" like thing that you get when commiting to a tree | 21:56 |
| GaryvdM | vila: That was written by Ian | 21:56 |
| vila | GaryvdM: ideally we should be able to share a common file between the installers for a given series, just a thought, I don't want patches *now* ! :D | 21:56 |
| GaryvdM | vila: yes | 21:56 |
| mbt | zyga, Yes, last revision for a dir, like http://bazaar.launchpad.net/~mtrausch/+junk/redmine-bazaar-sr/files shows | 21:57 |
| zyga | mbt: right, let me see | 21:58 |
| glyph | jelmer: any suggestions? | 22:01 |
| mbt | zyga, bzrlib.branch.Branch.get_revision_id_to_revno_map works for what I was trying earlier, and is a lot faster. | 22:01 |
| jelmer | glyph: I'm looking at the bug | 22:04 |
| zyga | mbt: I used bzrlib.branch.Branch.basis_tree() to get RevisionTree instance, it has methods that seem to be able to get dir-or-file -> revision | 22:04 |
| zyga | mbt: it also has get_file_size() | 22:05 |
| mbt | yes, also if you use .list_files, you get name, type, size, and a Inventory object | 22:06 |
| mbt | I still don't see anything in Tree or RevisionTree to get the last revision for an object | 22:07 |
| zyga | mbt: got it | 22:09 |
| zyga | the inventory item has this actually | 22:09 |
| mbt | I found Tree._file_revision(revtree, file_id) but that's "private" | 22:10 |
| zyga | mbt: .revision | 22:10 |
| zyga | that's what you want | 22:10 |
| zyga | mbt: you can simply walk the list generated by list_files() | 22:10 |
| peitschie | (mornin everybody) | 22:10 |
| mbt | zyga, Yep, am using "for file in revtree.list_files()" | 22:11 |
| zyga | mbt: so file is not really true, it returns a tuple of four items, the last one is inventory and it has .revision | 22:11 |
| mbt | zyga: http://pastebin.com/78Q6Ne5A | 22:12 |
| mbt | Still takes ½ second to run (on my system) when > /dev/null | 22:14 |
| zyga | mbt: line 18 is expensive, just walk the list, it's a generator | 22:14 |
| mbt | ah | 22:14 |
| zyga | mbt: takes how many seconds? | 22:14 |
| mbt | 1/2 | 22:14 |
| mbt | 0.5 | 22:14 |
| mbt | removing the comprehension saves 0.02 seconds | 22:15 |
| zyga | mbt: how about the same without using idmap at all? | 22:15 |
| zyga | mbt: that's zippy ;-) | 22:15 |
| zyga | mbt: that's _all_ redmine needs to import chagesets into its own db | 22:15 |
| mbt | removing idmap cuts 0.05 seconds | 22:15 |
| mbt | this is just listing the whole contents of a single revision | 22:16 |
| zyga | mbt: hmm refresh my memory, does redmine store files of each changeset too? | 22:17 |
| mbt | don't think so, let me look | 22:17 |
| zyga | mbt: AFAIR this is interactive operation that you'd trigger when looking at the repository section | 22:17 |
| zyga | mbt: so this 0.5 second delay would be something you get when clicking on the page | 22:18 |
| mbt | right | 22:18 |
| mbt | i think that's right, but one sec | 22:18 |
| mbt | (at least it's not the ~4 second delay that branch discovery takes, but that too is every page load | 22:18 |
| mbt | ) | 22:18 |
| mbt | redmine stores repository_id (foreign key), revision, committer, committed on, comments, commit date, scmid (foreign key I think), user_id (??) | 22:20 |
| mbt | in its changesets table | 22:20 |
| mbt | along with an autoincrementing / serial identifier for the changeset that Redmine uses | 22:20 |
| mbt | Or rather that I assume it uses. | 22:20 |
| mbt | also it has a "changes" table that has id, changeset_id, action, path, from_path, from_revision, revision, branch | 22:21 |
| zyga | hmmm | 22:23 |
| zyga | changeset_id refers to changeset table? | 22:23 |
| zyga | from_path and path are used for moves? | 22:23 |
| zyga | revision is just to see what the previous revision was | 22:23 |
| zyga | branch is a string or a foregign key to something | 22:24 |
| zyga | sorry for not checking this myself but I'm looking at other parts | 22:24 |
| mbt-mobile | branch is probably a string and empty for vcses that dont expose branches | 22:24 |
| mbt-mobile | those tables are populated via fetch_changesets i think | 22:25 |
| mbt-mobile | oh! | 22:26 |
| mbt-mobile | maybe that column can be select distinct for a repo to get a branch list. thatd be much faster than calling bazaar at page load time. | 22:27 |
| mbt-mobile | rather bzrlib | 22:27 |
| mbt-mobile | then when script/runner is called to update changesets at post-commit time, the work is all done then | 22:28 |
| zyga | mbt: yeah that would work | 22:29 |
| zyga | smart | 22:29 |
| mbt-mobile | then when browsing in redmine the only thing that has to be done is get the revid > revno map | 22:29 |
| mbt-mobile | for the branch | 22:29 |
| zyga | so if we want to cache that too we can keep it local | 22:29 |
| zyga | hmm | 22:30 |
| zyga | no wait, what about actual files | 22:30 |
| zyga | we don't store that ;-) | 22:30 |
| zyga | path/size | 22:30 |
| mbt | well | 22:30 |
| mbt | the only thing that has to be done at runtime is when entries() is called in the bazaar scm adapter class, it runs something like I pastebin'd. | 22:31 |
| mbt | but more efficient even then that, because entries only needs for the current dir | 22:31 |
| mbt | it'll get called again and again as the ajax interface updates, if i understand how it works correctly | 22:32 |
| mbt | yes, entries gets the directory listing | 22:34 |
| mbt | so in git's case for the master branch it calls shellout with "git --git-dir /path ls-tree -l 'master:'" | 22:35 |
| mbt | if a revision ID is passed as the identifier, though we still have the problem of which branch. We can confirm the revision ID presence in the repo, but we then have to search the branches to do anything with that revision ID | 22:38 |
| spiv | jml: https://code.launchpad.net/~spiv/bzr/concurrent-pack-race-701940-2.2/+merge/46847 is on its way to PQM | 22:38 |
| mbt | Or maybe not. | 22:39 |
| mbt | Nevermind, all that comes from the repo | 22:40 |
| glyph | spiv: Awesome. | 22:40 |
| zyga | mbt: I'll try to apply some of that, I'll write a small helper that can talk bzrlib and ruby | 22:41 |
| mbt | a standalone branch can be opened with bzrlib.repository.Repository.open() | 22:41 |
| mbt | but a branch in a shared-repo cannot | 22:41 |
| zyga | hmm, why not, what happens? | 22:42 |
| mbt | bzrlib.errors.NoRepositoryPresent is thrown | 22:42 |
| mbt | but that's ok | 22:42 |
| zyga | what do you open exactly? | 22:42 |
| mbt | because when you open a branch its repo is opened for you and accessible via <branchinstance>.repository | 22:42 |
| mbt | So, the python code that gets the entries can always open the URL given by redmine as a repository | 22:43 |
| mbt | because the URL that the user points at in the SCM configuration will always contain a repo, but does not necessarily have to contain a branch | 22:44 |
| zyga | hmm | 22:44 |
| zyga | right | 22:44 |
| zyga | so we allways open the repostitory and work from that | 22:44 |
| jelmer | jam: http://bazaar.launchpad.net/~jelmer/bzr/versionedfilestore-noweave | 22:44 |
| jelmer | grr | 22:44 |
| jelmer | jam: deb http://ppa.launchpad.net/gwibber-bugs/unstable/ubuntu natty main | 22:44 |
| jelmer | you'd probably want maverick | 22:44 |
| mbt | zyga, right, open the repo, get the revision tree and walk it | 22:44 |
| mbt | is that right? we never have to open the branch except as part of the post-commit? | 22:45 |
| zyga | I'm not absolutely sure, I think we should find the branches inside the repo to see branch history in any way | 22:46 |
| zyga | mbt, how do you find branches by walking revision tree alone? | 22:47 |
| mbt | Let's see. I branch from url://path/to/trunk, I commit a few times, I push back to url://path/to/trunk. The post-commit hook gets called on the client, but could be nothing there, and then on the server (I think). the hook tells RM that there are new revisions available. | 22:47 |
| mbt | RM opens the branch, gets the new revision IDs and gets their changeset from the shared-repo | 22:47 |
| zyga | mbt: post commit hook to populate redmine db? | 22:48 |
| mbt | So all RM needs the branch for is to get the commits in chronological order | 22:48 |
| zyga | mbt: that requires your branch to live on the same system which might not work, how would this work in on-demand scanner scenario | 22:48 |
| zyga | mbt: you have to scan the repo, possibly remotely | 22:49 |
| zyga | mbt: you cannot avoid walking each branch | 22:49 |
| mbt | what requires it to live on the same system? | 22:50 |
| mbt | and also need the branch for revid->revno mapping | 22:50 |
| mbt | grr | 22:50 |
| zyga | mbt: the post commit hook? how would you set it to work remotely | 22:50 |
| mbt | that won't work if the branch is not known | 22:51 |
| zyga | mbt: let's slow down | 22:51 |
| mbt | zyga, you'd call wget or curl or some other process to alert the server to run script/runner | 22:51 |
| zyga | mbt: let's try to get current stuff better first | 22:51 |
| mbt | zyga, a detail that currently doesn't matter | 22:51 |
| mbt | zyga, we still have the problem of not knowing what branch to scan | 22:51 |
| zyga | mbt: uh, that's ugly, I'd prefer something that would also work when the code is hosted on something dumb or something like lp.net where you cannot get triggers | 22:51 |
| mbt | zyga, you can opt to do it at runtime too | 22:52 |
| zyga | mbt: what about this idea: we scan _all_ branches and populate the branch with the repo-relative path to the branch | 22:52 |
| mbt | zyga, and redmine *will* update changesets at runtime if it finds a newer revision when browsing than the one it knows about | 22:52 |
| mbt | *than the latest one it knows about | 22:52 |
| mbt | huh? | 22:53 |
| zyga | do you mean the on-demant load thing that redmine does | 22:53 |
| zyga | the thing that pokes the repo whenenever you look at the repository part | 22:54 |
| zyga | let's slow down | 22:54 |
| zyga | can we turn the problem arouund | 22:54 |
| mbt | zyga, yes, it will fetch changesets as a result of a Web browsing request if they're out of date. that can take a long time, so RM provides a script hook to update them without having to web-browse to the repository. | 22:54 |
| zyga | what can we do correctly/fast/easily | 22:54 |
| zyga | and how to make redmine like it | 22:54 |
| zyga | mbt: right, you can explicitly disable that | 22:54 |
| mbt | zyga, We're still trying to figure that out. We haven't really left the first step, which is when entries(path, id) is called with a revision id or number, we haven't a way to tell which branch is the context! | 22:55 |
| mbt | ergo id->revno mapping cannot be done, because it could be different for every branch | 22:55 |
| mbt | we could scan to see which branches contain the revid, and if only 1 branch does we can pick that branch | 22:56 |
| zyga | mbt: I would prefer to look at step zero - work with bzrlib and redmine efficiently | 22:56 |
| mbt | but if more than one branch contains the revid, we have to guess | 22:56 |
| zyga | mbt: then solve step 0.5, adapt existing code | 22:56 |
| zyga | mbt: then step 1, fix repo support | 22:56 |
| mbt | so just have something that guesses at first? | 22:57 |
| mbt | cuz it looks like to do better than that, we have to dig a lot deeper into redmine | 22:57 |
| zyga | no, currently we don't have this problem | 22:57 |
| zyga | and once we have something better than what's currently inside we can ask people around | 22:57 |
| zyga | and the bzr sprint will finish so everyone will be back here | 22:57 |
| jelmer | glyph: So, the short version is that rebase sucks and we should fix it. | 22:58 |
| mbt | I don't follow | 22:58 |
| zyga | mbt: current redmine does _not_ support repositories | 22:58 |
| mbt | correct | 22:58 |
| zyga | mbt: we can just improve the implementation to be faster | 22:58 |
| zyga | mbt: and _then_ start to solve the problem | 22:58 |
| jelmer | glyph: I have some ideas | 22:58 |
| mbt | zyga, the current implementation is fast enough given that it calls bzr for very small things (aside from initial loading of the changesets database) | 22:59 |
| mbt | though I think we're talking about two slightly different things | 23:00 |
| zyga | right but we both agree that to improve it we need to talk with bzrlib | 23:00 |
| glyph | jelmer: please have ideas faster :) | 23:00 |
| zyga | so rewriting the current code is a prerequisite | 23:00 |
| mbt | I was working from the perspective of keeping the current bazaar-standalone-branch model & adapter | 23:00 |
| glyph | jelmer: looks like for this branch I'm going to be using 'bzr export' and some other nastiness to get something I can commit to svn. | 23:00 |
| mbt | and writing a new model & adapter that handles the repositories | 23:00 |
| zyga | hmm | 23:01 |
| mbt | because there are enough things different about the two that I'm not sure we can (easily) support both use cases in a single class | 23:01 |
| zyga | I did not consider this | 23:01 |
| zyga | I think it could be handled by single code | 23:01 |
| zyga | but that's not really relevant, it can be done both ways | 23:01 |
| mbt | zyga, I made the assumption that if one class can do both then it'd be easy enough to drop the new one over-top the old one | 23:02 |
| mbt | brb real fast, coffee | 23:02 |
| zyga | k | 23:02 |
| mbt | back | 23:04 |
| mbt | I have http://mike.trausch.us/wiki/RM-SCM-module which I wrote (just copy-pasted it into my public wiki from my private one) while trying to figure out what's what. It probably isn't 100% accurate yet | 23:06 |
| zyga | let me see | 23:07 |
| zyga | darn running redmine on arm is slow ;] | 23:07 |
| jelmer | glyph: spiv and I are brainstorming :-) | 23:07 |
| mbt | zyga, ARM, eh? Only ARM thing I have in the house are the cell phones lol | 23:08 |
| zyga | :-) | 23:08 |
| zyga | mbt: I'm sure that will change in few years | 23:09 |
| mbt | zyga, probably not, don't plan on replacing any computers for the next 4 or so years, all of 'em are pretty new | 23:09 |
| zyga | mbt: well you will get a new one one day | 23:10 |
| mbt | That and I like AMD :) | 23:10 |
| mbt-mobile | anyway, i suppose thats why i am looking at this from the bottom up; wasnt thinking about moding the current module, but replacing it completely. | 23:12 |
| mbt-mobile | its starting to look like we should use the svn model though instead of the git one. | 23:14 |
| mbt-mobile | the svn model is broken (admittedly by necessity on svn's part), but the git model wont apparently work without improvements to redmine core and patches to all other scm modules | 23:15 |
| zyga | mbt: I don't have an opinion on that, I'd need to read the svn module first | 23:16 |
| zyga | mbt: I'll start working on the python adapter | 23:16 |
| mbt-mobile | at least with the svn model the branch is known as it is part of the path | 23:16 |
| zyga | and see what we can do later | 23:16 |
| mbt-mobile | the svn module is the one used on remine.org | 23:16 |
| mbt-mobile | no pull down menu for the branches and no branches function in the adapter | 23:17 |
| zyga | heh | 23:17 |
| zyga | it's part of the git/svn philosophy | 23:18 |
| zyga | in place ;-] | 23:18 |
| mbt | with the svn model, both repos and trees could be supported because the URL repo would be e.g., /home/mbt/Projects/redmine and the path passed to the SCM adapter would be relative from that | 23:18 |
| mbt | then you just try to open as a branch the URL + dirname(path) and go up in the directory tree until opening a branch works | 23:20 |
| zyga | mbt: you can use bzrlib.branch.Branch.open_containing to do just that | 23:20 |
| mbt | oh, well, then. | 23:22 |
| mbt | does that work with a branch w/o working trees? | 23:22 |
| mbt | 1 sec and I'll find out I guess | 23:24 |
| zyga | mbt: mmm, nope | 23:25 |
| zyga | mbt: but please check, I don't remember what failed for me, I did something similar lately | 23:25 |
| mbt | zyga, yes it does! | 23:26 |
| mbt | I do believe that might be the key. | 23:26 |
| mbt | At least to a first implementation. | 23:26 |
| mbt | Wonder if it works over the net | 23:26 |
| mbt | 1 sec | 23:26 |
| mkanat | poolie: Hey! My machine died on Sunday/Monday and I've been playing catch-up since then, but the loggerhead work is at the top of my list now. | 23:29 |
| mbt | It does not; running "br = Branch.open_containing('lp:~mtrausch/+junk/redmine-bazaar-sr/app')" yields: bzrlib.errors.PermissionDenied: Permission denied: "Cannot create 'app'. Only Bazaar branches are allowed." | 23:30 |
| mbt | Which looks like it attempted to create the branch? | 23:31 |
| zyga | mbt: hmm, that's now how lp works | 23:31 |
| zyga | mbt: yes | 23:31 |
| mbt | Ah, not part of the call | 23:31 |
| zyga | mbt: AFAIR lp has some magic scheme | 23:31 |
| zyga | mbt: and you cannot create a repo on the far side | 23:31 |
| mbt | 1 sec will try on a network-local bzr+ssh branch | 23:32 |
| zyga | mbt: you can test this with bzr+ssh and some local server | 23:32 |
| mbt | It does work with bzr+ssh | 23:32 |
| zyga | mbt: lp has special meaning to pathnames | 23:32 |
| mbt | so with lp: an exception must be caught and one directory level should be removed to try again | 23:32 |
| mbt | until it works | 23:33 |
| mbt | but for everything else it looks like it can figure it out... maybe. will try sftp | 23:33 |
| mbt | Yep that works too | 23:33 |
| zyga | mbt: I don't think you need to do that for lp, there is no way to use lp with shared repos | 23:33 |
| spiv | mbt: it's a bit of a bug that lp returns a PermissionDenied rather than a NoSuchFile in that case | 23:34 |
| mbt | no but if you specify it as a branch | 23:34 |
| mbt | redmine can be setup to allow all URL schemes that bzr knows about, including a remote branch on lp | 23:34 |
| mbt | though I suppose that can also be excluded | 23:34 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| mbt | So, if the SVN model is used that means that the ambiguities all disappear | 23:35 |
| mbt | Unless I am missing something, that would make it possible to support Bazaar shared repositories without having to extend the Redmine "framework" in any way. | 23:36 |
| mbt | While at the same time supporting branches. Because all that is needed is Branch.open_containing and the returned tuple has the Branch object and from that the Repository object can be reached | 23:37 |
| mbt | *supporting standalone branches | 23:38 |
| mbt | whoa | 23:38 |
| mbt | found a bug in bzr i think | 23:38 |
| mbt | http://pastebin.com/7WQdfz3t | 23:39 |
| spiv | mbt: that looks familiar, I think it may have been fixed since 2.2.1 | 23:41 |
| mbt | k | 23:41 |
| mbt | will check real quick | 23:43 |
| GaryvdM | vila: on babune, the windows test are running with "-x TestBreakin". Is that permanent? | 23:49 |
| mbt | spiv, same crash using bzr from lp:bzr | 23:52 |
| spiv | mbt: ok, thanks for checking. File a bug (or me too an existing report if you find it's reported already...) | 23:53 |
| mbt | spiv, reported as bug 705189 | 23:56 |
| ubot5 | Launchpad bug 705189 in Bazaar "crash when "bzr ls" against a file in a branch w/o working tree" [Undecided,New] https://launchpad.net/bugs/705189 | 23:56 |
| zyga | mbt: apparently we'll need very recent bzr to work at all ;-) | 23:57 |
| mbt | zyga, it's not an issue when using open_containing | 23:57 |
| mbt | zyga, thankfully | 23:57 |
| mbt | the script that I pastebin'd earlier works on that same branch so we're good | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!