[00:02] dOxxx: I'd recommend sticking to the releases [00:04] jelmer: ok. same for bzr-svn? [00:06] 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:07] jelmer: time to create a new release ? :-p [00:08] vila: yeah... [00:08] jelmer: bzr-rewrite too [00:08] I need to put some more thought into that ghost issue though :-/ [00:09] vila: I'm packaging bzr-upload v1.0.0, ok? [00:09] dOxxx: yup [00:09] dOxxx: I guess trunk is the best thing to package indeed. This is for the beta, right? [00:09] jelmer: I thought this was 2.3.0 [00:10] of bzr [00:10] vila: right? [00:10] AFAIK 2.3.0 is not out yet, is it? [00:10] jelmer: yup, 2.3b5, but we intend to package as many releases as possible for 2.3.0 [00:10] woops [00:10] dOxxx: *last* beta before 2.3.0 [00:10] vila: :) [00:11] oh well I would have found out when the build tried to download the 2.3 tarball and failed :) [00:11] dOxxx: indeed :) [00:11] I need to poke abentley about a few of his plugins too [00:11] seems a number of them have 2.3 compatibility changes on trunk but no release [00:12] also bzr-xmloutput which seems to be a free-for-all author-wise [00:12] mail would be good for that I think as he's not around anymore [00:12] vila: k [00:13] 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] * lp:bzr-svn/1.0 [00:14] Whilst lp:bzr-svn/1.1 is a stale branch [00:17] jelmer, vila: bzr-fastimport release would be nice too [00:18] * vila nods [00:20] vila: launchpadlib 1.9.4 ok? just released an hour ago... [00:20] dOxxx: sure thing [00:20] dOxxx: but... weren't there some missing dependencies ? [00:21] vila: such as? [00:21] dOxxx: I vaguely remember a bug about it but not if it was fixed [00:21] checking [00:22] bug 687315 [00:22] 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] subject is misleading though [00:23] still, yeah, that's a problem [00:24] dOxxx: yeah, I remember now, I tried creating a dedicated package (or whatever the name is there) and get lost [00:24] vila: a package in the installer definition which includes launchpadlib and all its dependencies? [00:26] dOxxx: yes, so we can provide it independently from pipeline [00:26] vila: so pipeline will operate without it? ok... I'll see what I can do. [00:29] dOxxx: no ! But IIRC launchpadlib is only installed with bzr-pipeline today [00:29] oh! [00:30] 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] s/test/test failure/ [00:30] 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:31] vila: I see. [00:31] dOxxx: I think you may have mixed up "Aaron" and "Andrew" in your mail client :) [00:31] 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:32] spiv: oh darn I thought I got it the right way round [00:32] dOxxx: well the To: line said me but the body said Aaron :) [00:32] spiv: ugh copy & paste FTL [00:32] damn... I called nmb Aaraon too. >< [00:32] Aaron* [00:33] *sigh* [00:33] Hopefully I haven't offended you too much :) [00:33] Not at all :) [00:36] * vila bbiab === Ursinha is now known as Ursinha-afk [01:13] I *really* need to get myself a hardy VM [01:15] I really need to upgrade my Hardy VMs... [01:17] hah [01:17] :-) [01:17] ooh [01:17] A volunteer to test ~bzr PPA packages on hardy? :-) [01:18] Eep! [01:19] maxb: The answer is probably no, but what are you looking for? [01:20] Gods, I last pulled bzr.dev 2010-05-14. >.> [01:31] Do you use loggerhead? If so, there's a 1.18 package in bzr/proposed to supercede the ancient 1.10 [01:31] it built, I'm quite curious whether it works at all [01:32] later there will be the bzr upgrade from python-central->python-support to test [01:34] Haha...I last pulled lp:loggerhead around 2010-05-14 too. :D [01:43] vila: hola [01:44] hmm, weird things happening here, dOxxx , did you get explanation about why the tests were failing ? [01:44] vila: which tests? [01:45] the ones mentioned in bug #687315 [01:45] Launchpad bug 687315 in Bazaar Mac Installers "some tests from the launchpad plugin requires lazr.uri" [High,Confirmed] https://launchpad.net/bugs/687315 [01:46] vila: nope, I haven't looked at that yet. [01:46] vila: are you still getting failures with all the pre-reqs installed? [01:48] dOxxx: can't remember, I restored a working env at the time [01:50] dOxxx: just checked, launchpadlib is not installed anymore on my laptop [01:50] dOxxx: well, on the OSX part of it [01:51] vila: I have bzr 2.3b5 osx 10.6 installer ready for upload [01:52] dOxxx: cool, did you push the changes ? [01:52] vila: not yet. I just want to quickly test that thq GUI stuff works [01:52] the* [01:52] dOxxx: ok, can't help you there, my 10.6 is at home *and* off :) [01:55] 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:56] but I suppose that's why this is a beta [01:56] dOxxx: isn't there already a bug for that ? [01:57] vila: it does seem familiar [01:58] Bug #649430 [01:58] Launchpad bug 649430 in Bazaar Explorer "text fields in qbranch are very narrow" [Undecided,Incomplete] https://launchpad.net/bugs/649430 [01:58] alas, I didn't see alexander's question until now [01:59] I had my mail filters misconfigured and they were bouncing a lot of launchpad bug emails :P [02:04] 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:06] vila: anyway, I'll upload a screenshot for him now [02:06] ok [02:11] vila: pushed. I'm signing and uploading my installer now. [02:12] ok, pulling here [02:15] vila: re mergetools... the command_line getter/setter is needed by thq qbzr mp, so I can't really add it there instead. [02:16] the* [02:17] 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:18] for the same reason qbzr doesn't modify .bzr and uses Branch instead [02:19] ? [02:19] it's used as a representation of a MergeTool [02:19] setting a config option is a public API [02:20] is the option value set from there then ? I didn't see this in your mp [02:20] the config option is set when qconfig passes the modified MergeTool object to Config.set_merge_tool [02:20] eeerk [02:21] ugh wait [02:21] my brain is not working [02:21] this damn mp has changed so many times I'm losing track [02:22] ok [02:22] config option is set directly by qbzr, basd on the contents of the modified MergeTools object. [02:23] 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:24] 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:25] except it's two strings. :) [02:25] but I get the point. [02:25] two ? [02:26] name + commandline. [02:26] stored as one [02:26] oh, you mean the option name ? [02:26] I mean as in 'kdiff3 = /usr/bin/kdiff3 etc' [02:26] two strings [02:26] user-provided name and commandline [02:27] yeah, the option name and its value [02:27] ah yes [02:28] vila: so now I'm even wondering if we need a MergeTool class at all [02:29] perhaps the mergetools module could just contain functions for is_available and invoke, based on a string commandline given to the function [02:30] well, I said that pretty early :) But is_available, at least, needs a home and the default values too [02:31] yeah well I blame my overly-Javafied brain :) [02:31] :) [02:34] so... if MergeTool no longer exists, then config.get_merge_tools should return a dict of name -> commandline [02:34] and the qconfig stuff can deal with that instead of a list of MergeTool objects [02:35] does python have sorted dicts? [02:35] hmm meh probably not the best way to do it [02:38] vila: okay I'll hack on this some more and see if I can simplify things. [02:38] vila: osx 10.6 installer is uploaded too [02:39] dOxxx: don't go too far in the other direction :) I'm fine with your mp with the few tweaks I asked for [02:40] dOxxx: I'm sorry it was so messy regarding the new config stuff that is still not there :-/ [02:41] dOxxx: starting build here after a successful f_e -p -u [02:41] dOxxx: so if I read it right, I won't need to recompile qt after all ? [02:43] vila: you mean pyqt? [02:44] vila: I install Qt itself from a pkg downloaded from the nokia site. [02:44] vila: only pyqt is compiled during the installer build [02:44] dOxxx: yeah, I meant pyqt [02:45] vila: okay. you will have to compile that. there is a newer version. [02:46] dOxxx: err, required ? [02:46] vila: well, required in that riverbank computing don't keep anything but the must recently release tarball on their website [02:47] vila: so I'm kinda forced to update to their latest version each time I want to build the installer [02:47] vila: unless I maintain my own archive of their releases [02:50] woops [03:01] grr [03:02] dOxxx: vm froze :( [03:05] dOxxx: so I got a pyqt 4.8.2 downloaded but not rebuilt it seems :-/ [03:05] or not correctly as the build ends up with a link error in sip [03:06] dOxxx: ring any bell ? [03:06] vila: odd... [03:07] urgh, second build gave a different error :( [03:07] I had a problem with one of the tarballs I downloaded having a CRC error [03:07] so I had to zap all of them and redownload [03:07] since I wasn't sure which one [03:07] but after that it went through fine [03:09] hmm, so you rebuilt from a clean plate :-/ [03:11] vila: pretty much [03:11] ./build.py clean && ./build.py [03:12] yeah :( third build raised the same error as the first :) [03:12] be back in a .... biggy ? :D [03:12] what is it? [03:13] forget it, I ran clean and restarted the build, I let you know if it fails [03:14] it was about yyparse missing, smelly (yyparse is usually called from generated parsers) [03:15] o.O [03:23] yeah, probably not worth debugging [03:28] * maxb hugs KVM and vmbuilder [04:01] maxb: not funny >-/ [04:01] :) [04:02] I wish I could use kvm... [04:04] night all [04:05] dOxxx: g'night, build just finished successfully [04:05] yay! [04:06] :) [04:07] vila: awww.... cpu too old? [04:07] maxb: nah, gf's laptop not running ubuntu, so I need a vm to run it ! :D [04:08] oh [04:08] I have a shiny new Core i7 Quad - need to find it some work to to :-) [04:08] I wonder how many concurrent guests it could manage [04:08] maxb: I use Ubuntu on my desktops and I'm hoping to migrate to kvm asap [04:09] maxb: that's what babune is using :) [04:09] maxb: hope you got an SSD too [04:10] nah, plain old spinning magnets [04:13] maxb: ooooh at >= 7200 rpm at least ? [04:27] oh yes, 7200. I looked out for that carefully [04:27] Was very careful not to take the "free upgrade" to a bigger 5400 one [04:28] 7200? Wow, how Dark Ages... [08:45] Hello, I did a bzr branch remote local --use-existing-dir and ended up with a .bzr dir [08:45] Now I do an bzr checkout and get an Error 17 [08:45] Error 17 = file exist [08:45] anyone an idea [08:45] ? [09:32] sender: file a bug with the exact steps you did to get the error and the full traceback [09:33] you can get those from your .bzr.log which `bzr version` will tell you where to find. [09:35] 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:36] #java [10:34] hiya pardners :) [11:00] hello [11:00] 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:07] rm -f filename; bzr resolve filename [11:34] 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] 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:35] bzr doesn't mind the argument ordering... [11:35] Which version of bzr are you using? until recently, revert didn't take a -r argument at all [11:35] bzr revert --help and see if it lists -r [11:35] [pef@caoimhe-sid:~/src/libadjoint]$ bzr revert --help | grep -- -r [11:35] -r ARG, --revision=ARG [11:35] it works when I 'bzr revert -r106' [11:36] I'm using bzr 2.3b2 [11:36] Oooh.. I see. [11:36] is this fixed in a newer version? should I upgrade? [11:36] Yes; you have to put the subcommand first, before its arguments... [11:36] bzr -rwhatever command won't work. :) [11:36] yeah [11:36] maybe it's just me -- [11:37] but I find that's the biggest usability problem with bzr [11:37] but maybe I'm just brain-damaged from years of svn [11:37] -r106 bzr revert also wouldn't work ;) [11:37] yes, but svn -r106 log works, for example [11:37] :-) [11:37] The trouble is that you can't parse the options until you know which subcommand it is. [11:37] So bzr has to know it's getting a "revert" command, before it can udnersatnd what -r106 means [11:38] true. [11:38] the main bzr command could gather all of the -options it encounters before the command, and then pass them onto it [11:38] svn subcommands take different arguments too [11:38] and I assume that is what it is doing under the hood [11:38] It couldn't do that easily, because how would it know which ones were split or not? [11:38] bzr -abc foo [11:38] IS that -a -b -c ? Or is one of them taking a value? -a -b=c -a=bc ? [11:39] it doesn't need to know [11:40] store "-abc" in a list of arguments, because "-abc" isn't a recognised command [11:40] next argument: [11:40] "foo" is a recognised command, so push "-abc" onto its argument list, along with the rest of the sys.argv [11:40] Mmm. Perhaps it could do that. Currently it does not. [11:40] .. or something like that [11:40] I mean, it's not that hard to code -- [11:40] it's just if the bzr development team actually approve of the idea [11:41] But then how might you handle bzr -m revert commit file.c [11:41] hmm [11:41] true [11:41] It's less surprising to everyone, if we know the subcommand must be first. Everyone expects to find it there. [11:41] I wonder how svn does it [11:41] Systems that are easy to predict are easy to use. [11:42] well, thanks for the discussion [11:54] actually the way svn does it is to have a single set of options for all subcommands [11:55] this is why certain options have hideously generic help - because there's only one helpstring shared for all subcommands [11:57] if's also why svn has so few single letter options - those are allocated globally too [11:57] pfarrell: ^^^ [11:57] maxb: right, thanks [11:58] I guess I'll just get used to it [11:58] 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] (but what do I know) === oubiwann_ is now known as oubiwann [13:15] thank you cz [13:15] thank you cjwatson [13:29] hi [13:30] 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] http://paste.ubuntu.com/555772/ [13:30] this is the last transaction in .bzr.log [13:31] bzr plugins claims I have launchpad 2.2.1 [13:31] this is maverick on arm port === oubiwann is now known as oubiwann_ [14:05] anyone? [14:07] hi. [14:08] 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] both x, y may have interleaved commits in the sense of timeline. [14:08] 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:09] sobersabre: what do you mean by "reside inside z"? [14:09] let's assume I have a folder /bzr/repos/dir [14:09] and I have in side it 2 dirs dir1 and dir2 each is a master branch inside dir. [14:10] 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] sobersabre: ah [14:10] zyga: do you understand me ? [14:10] you want to bzr join them [14:11] so what is the right way to do this ? [14:11] sobersabre: I think you're right [14:11] sobersabre: do any of the branches have common history? [14:11] if so you can just bzr merge them [14:11] and bzr mv them to place you want - you will retain whole history [14:11] zyga: what do you call "common history" ? [14:11] they are unrelated, like project1 and project2 [14:12] 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] but it will retain all history, I did something like this before [14:12] both are MASTER branches, not bound to anything, and are not derivatives of neither of the other. [14:12] zyga: what do I have to pass merge ? [14:14] sobersabre: afair -r 1 [14:15] sobersabre: bzr merge will complain that branches are unrelated and needs some 'common part', I don't remember but that helped me [14:17] there's also a merge-into plugin [14:18] 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:24] hello everyone [14:26] I wondered if you know of anybody having developed a php-skript that allows uploads and commits to a bazaar branch? [14:27] dejj: why would you use php? bzr has a python library with that api [14:29] I need to plug it into a repository viewer (Trac maybe), so my users don't need to install bzr. [14:29] What's that library called? [14:29] dejj: trac? trac supports bzr out of the box AFAIR [14:30] dejj: what do you want your users to be able to do? [14:30] can you do uploads via the browser? [14:30] dejj: uploads of what? commits? [14:30] yes [14:30] dejj: trac is not designed to do that [14:31] then I need to make it do that [14:31] dejj: well then you are lucky, bzrlib and trac are both written in python, no php required [14:32] 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] my users aren't developers ;-) [14:32] we're currently using Microsoft Sharepoint's web interface to organize files [14:33] dejj: are you planning to store large binary files? [14:33] unfortunately you can't move any files there and "checkout" means "lock" and it's a total mess [14:33] dejj: there is a piece of software that gives you transparent versioning on top of webdav [14:33] it's much better than web browser "forms" for doing uploads b [14:34] but I'm afraid bzr is not someting that you want to use for sharepoint replacement [14:34] why not? [14:35] sorry for that broad question [14:35] 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] bzr was designd to version source code, not random files of arbitrary size [14:36] if you want to use that btw, it's easier to just use the shell integration [14:36] so people can commit and update from right-click menu [14:37] that would be step 2 in my plan. I can't yet get them to install anything on their computers [14:37] it would certainly be easier if you want to let them share files, zero development time for you [14:38] may I ask what is the size of the dataset they will work with? [14:38] it's not enterprise-sized (yet). about 500mb should be the limit [14:39] dejj: 500 of _everything_ _ever_ or just one file that you want to store? [14:39] 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] everything ever [14:39] you may also find that http uploads are not the best way of uploading files due to the way http was designed [14:39] this would ease some deployment stuff. [14:39] dejj: in that case it will proably work fine [14:40] the problem I'm working around here is actually my users being dead-afraid of anything new in IT. [14:40] sobersabre: well, the tools I mentioned are the options I know about, anyway (though not a bzr developer) [14:40] they know web-uploads, so I have to get them there [14:40] dejj: trafficking new software via browser is not really something that different from just installing it for them [14:41] dejj: if you do this in the open (the upload-via-web) you might get some help from us [14:42] hi all [14:42] 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] zyga: so I thought someone must've that figured out before [14:43] dejj: in php? [14:43] zyga: unfortunately I don't speak python [14:43] dejj: I would encourage you to use bzrlib directly and write this in python with one of the web frameworks [14:44] dejj: otherwise it will fall apart quickly [14:44] dejj: you need to handle several error situations [14:44] dejj: and stuff like locks, etc [14:46] zyga: indeed. and you're saying that bzrlib makes this easier than going with php? [14:46] (bzrlib + cost of learning python) that is [14:46] dejj: well bzrlib _is_ bzr [14:46] 0.o [14:46] php is most likely the bad approach [14:47] 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] so you will have lots of code to get you started [14:47] that sounds so nice [14:48] 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:51] 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] you said > there is a piece of software that gives you transparent versioning on top of webdav === Ursinha-afk is now known as Ursinha [14:54] zyga: which is that piece of software? === oubiwann_ is now known as oubiwann [15:17] dejj: re, sorry? which software is that? [15:23] 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] did you mean bzrlib? [15:24] ah no [15:24] you can see variour projects like trac that intefrace with bzr repos to get you stated [15:24] I mentioned loggerhead [15:24] it's the thing that shows you bzr branches on launchpad [15:25] I personally hacked on redmine (written in ruby) to do something similar [15:25] and I could not use bzrlib so I scripted bzr invocations [15:25] 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:26] trac is good too [15:26] trac has bzr integration, it might be in the core or in a separate plugin [15:28] zyga: thanks for your help, I'll definitley look into how to use bzrlib to replace my php skript [16:21] zyga, you've worked on Redmine for bzr support? [16:27] sobersabre: join accomplished? Disregard bzr merge-into unless your branches are stuck in bzr 1.x formats === beuno is now known as beuno-lunch [16:59] maxb: ah, I didn't know that, sorry for the misdirection [17:07] mbt: re [17:07] mbt: I need to go out for 20 minutes [17:08] mbt: but in short, I took what upstream redmine ships and adapted it to work much better with bzr at the time [17:08] mbt: if you want to know more, stockpile questions here, I'll answer when I return === frakturfreak_ is now known as frakturfreak [17:09] zyga, absolutely, thanks [17:11] 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:17] 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:42] mbt: I need to look after my kids, let me review that ticket, what changes did you find necessary? [17:42] mbt: I think that typical shared repo can be mapped to git or svn model with more-than-one branch easily [17:44] mbt: if you want I would gladly work on a patch to redmine to get best-of-class bzr support [17:45] 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:46] 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:47] 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:48] 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:49] 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:51] 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] 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. [18:00] re [18:01] mbt: you don't need to use revisions [18:01] zyga, what do you mean? [18:01] mbt: or more accurately revnos, you should just use revids [18:01] mbt: bzr and git are identical in what they store and express [18:01] zyga, Still, same problem, you have to refer to them within the context of a branch [18:02] "bzr log" doesn't work on a repo; "git log" works on a repo [18:02] 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] mbt: ah, right [18:02] mbt: but you can 1) use bzr revids to map to actual changesets [18:03]