=== Verterok is now known as Veterok__ [06:09] Sheesh, it's quiet today. Did I miss a memo about a picnic? [06:26] hey folks [06:27] if `bzr break-lock` isn't breaking the lock set yesterday.. what does one do? [06:27] quik_: Are you running it on the URL of the locked branch? [06:28] eh? [06:28] quik_: Are you trying to break the lock on your local branch or the server you push to or what? [06:28] the server I want to push to [06:28] quik_: Does "bzr break-lock" prompt you about the lock or do nothing? [06:29] seemingly, nothing [06:29] quik_: You need to pass it the URL of the branch. "bzr break-lock sftp://..." or whatever. [06:30] ah right [06:31] :) [06:31] thanks Peng [06:32] You're welcome. :) === asac_ is now known as asac [07:50] hey, i can't bzr rspush to, for instance, deploy@foobar:~/thing. it tells me its not a branch or empty directory. however, i have previously bzr pushed to that same directory. is this a problem with the macports install of bzr and bzrtools or am i missing something? [07:52] Yes :) [07:52] I have no real knowledge of the domain. But I have a hard time picturing a way the install could be horked up, and it would work well enough to run, but be broken enough to look in the wrong place. [07:53] You sure you're not accidentally push'ing instead of rspush'ing? [08:19] jmhodges: what does ls -l of that directory show ? [08:20] lifeless: not the place for unix quesions. this is #bzr [08:20] lifeless: the #linux or #bsd or whatever you're on :) [08:20] s/the/try/ [08:20] jmhodges: also rspush is very old; you may prefer push + jam's post-push rsync plugin [08:20] jmhodges: I'm helping you debug it, but whatever. [08:21] lifeless: jesus i'm sorry i misread [08:21] jmhodges: I'm one of the core authors of bzr. [08:21] jmhodges: still, I meant 'ls -al' [08:21] lifeless: i thought you asked me what ls -l always does [08:21] lifeless: like a newbie asking a question about ls [08:21] heh [08:21] lifeless: i was like "wtf? havnt i seen this guy here before?" [08:21] sorry [08:21] one sec [08:22] lifeless: its just .bzr [08:22] ok [08:22] lifeless: from the pushes i did before [08:22] cat .bzr/branch-format, and .bzr/repository/format [08:22] lifeless: locally or in the remote? [08:22] in the remote [08:23] branch-format: Bazaar-NG meta directory, format 1 and format: Bazaar pack repository format 1 (needs bzr 0.92) [08:23] that looks.. wrong somehow [08:23] bzr --version says "Bazaar (bzr) 1.0.0" [08:24] ok, thats all good [08:24] yay [08:24] the most likely thing then is that the path you are giving is not resolving correctly; could you try an absolute path ? [08:24] deploy@foobar:/path/to/thing [08:24] * jmhodges nods [08:25] one sec, need to ci some changes [08:26] bzr rspush deploy@biggecko:/home/deploy/bzr/atelier-main # => bzr: ERROR: Remote location is not a bzr branch (or empty directory) [08:26] lifeless: ^ [08:37] lifeless: again, sorry for being a jerk earlier. i blame the couple of hours of sleep i've been getting for the past week and my own inattention. [08:37] interesting [08:37] Does rspush stuff anything in .bzr.log? [08:37] forget about it [08:38] jmhodges: I really recommend you try jam's plugin instead of rspush [08:38] jmhodges: it ssh's in and runs bzr update [08:38] lifeless: jams plugin? [08:38] i've been out of bzr for too long [08:38] * jmhodges googles [08:38] push-and-update, I think. [08:38] Something like that. [08:39] fullermd: that's it [08:40] cool. i'm assuming then that speed gains of rspush aren't worth other problems that i dont know about (other than "it not working")? [08:40] oh, rspush is likely slower [08:40] Actually, with packs, the speed gains of rspush can become very negative. [08:40] ohhh [08:40] thanks! [08:41] i'll just grab it out of trunk then. thanks again [08:47] hm.. it pushes fine, and the command shows up in `help commands` but bzr push doesn't "do what i expected" or does it really require running `bzr push-and-update` ? [08:48] weird [08:48] Probably, if that shows up in the command list. [08:49] try bzr help push-and-update :) [08:54] natch. for some reason, i thought it "overwrote" push === Laurens is now known as LaurensS [09:23] Hello, is there someone here who has experience using bzr 1.0, with bzr+ssh on windows? I can't seem to get it to work. sftp works fine, but I'd like the speedimprovement of bzr+ssh which I've seen in linux [09:30] Laurens_S: what problem are you having? [09:31] this is the error I get: [09:32] (reproducing error.....) [09:34] Z:\src>bzr log bzr+ssh://username@server/full/path [09:34] Connected (version 2.0, client OpenSSH_3.8.1p1) [09:34] SSH username@server password: [09:34] Authentication (password) successful! [09:34] Secsh channel 1 opened. [09:34] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [09:34] Z:\src\> [09:34] I tried -Dhpss, didn't show anything more [09:34] Laurens_S: -Dhpss puts more information in the .bzr.log file [09:35] ah :) [09:35] I'll try again [09:35] ("bzr version" should report the location of that file) [09:36] So, put the contents of the log file on pastebin.com [09:37] ah, I finally figured it out: [09:37] I'm guessing it's something wrong on the server side, perhaps "bzr" is not on the PATH? [09:37] yes, that was indeed the case [09:37] Heh, lucky guess :) [09:37] I set BZR_REMOTE_PATH to the correct location now [09:38] I thought I did that, but SET revealed that I messed up : [09:38] Ah, right. [09:38] zbr_remote_path=/home/ls/local/bin/bzr is not really the same as BZR_REMOTE_PATH :) [09:38] heh. [09:38] well, thanks for helping out :) [09:38] You're welcome :) [09:39] now it turns out I forgot to do a bzr bind, bzr commit before leaving the house :) [09:39] anyway, thanks again, and have a good day y'all :) Loving bzr! [09:57] lifeless: Has anyone come up with the answer for you for the traffic shaping? [09:57] lifeless: If not, my recommendation is to use 'tc' but it's arcane and confusing, even for people who already know how to use it [10:02] I broke my branch :( [10:02] anyone know what this means: [10:02] Try using gun tape. That'll fix anything [10:02] % bzr commit [10:02] bzr: ERROR: Cannot commit to branch BzrBranch6('file:///home/gus/debian/libapache-sessionx-perl/debian/'). It is bound to BzrBranch6('sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/'), which is bound to sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/. [10:02] [10:03] its not real informative [10:03] gus: Sounds like you don't have write permissions on the target branch, but I assume this used to work for you? [10:03] yes [10:04] gus: anyone else committing to this branch? [10:04] it was a lightweight checkout, but I removed that and did a heavyweight checkout [10:04] nope, its all me [10:04] Er. It's recursive. [10:04] gus: (ie, beware debian style group-per-user nonsense which can result in various users trampling permissions in a repo) [10:04] afc: its my laptop and home desktop - i don't think there are other users here [10:05] You've got a branch bound to itself. That kinda doesn't work... [10:05] gus: and as another aside, any particular reason you're using a bound branch ("checkout") instead of a full power branch? [10:05] I don't know, I'm not really a power bzr user [10:05] gus: log onto mongrel, cd into /home/gus/archives/libapache-sessionx-perl/debian/ [10:05] gus: type bzr unbind [10:05] gus then try again [10:06] gus: As fullermd says, your remote branch is bound to itself, which is the complaint [10:06] works fine [10:06] interesting [10:06] before the unbind, it said this: [10:06] % bzr info [10:06] Repository bound branch (format: dirstate-tags) [10:06] Location: [10:06] shared repository: /home/gus/archives/libapache-sessionx-perl [10:06] repository branch: . [10:06] [10:06] Related branches: [10:06] push branch: [10:06] parent branch: /home/gus/archives/libapache-sessionx-perl/upstream [10:06] [10:07] where's the bit that tells me where its bound to? [10:07] gus: oddness, it doesn't specifically say it was [10:08] it should say checkout of branch: ..... [10:08] but then again, it was bound to itself, so who know how odd it could have gotten [10:08] My checkouts say "Repository checkout (format: dirstate-tags)" [10:08] gus: fyi, in future, please use a pastebin like pastebin.ca or rafb.net/paste/ for anything more than a line or two [10:08] meh. I haven't touched these for ages, perhaps I typed something dumb once ages ago [10:09] kinnison: yep, sorry I'm being lazy. me-- [10:09] What version of bzr are you running? [10:09] fullermd: oh true, repos will say that [10:09] gus: and it does say "Repository bound branch" at the top [10:09] I now have bzr 1.0 at both ends, but these repositories were created / last-modified by a much older bzr version (I couldn't tell you how old) [10:10] anyway, thanks. I can pretend I'm still an active debian developer now. ;) [10:12] If you have 1.0, consider using pack format for faster operation (make backups first obv.) [10:12] I've found pack to be much faster when working with remotely bound branches [10:12] But then again, I am odd :-) [10:13] heh. [10:13] as an aside: I had lots of trouble finding a way to convert a lightweight checkout into a heavyweight. Is there some way of doing that 'in place'? [10:14] I think reconfig can do that. [10:14] At least in recent versions. [10:14] didn't seem to (at least in 1.0) === cprov-out is now known as cprov [10:16] It's got --checkout in 1.0... [10:17] right, but both heavyweight and lightweight checkouts are checkouts, right? [10:17] or have I confused some terminology somewhere [10:17] I guess I want a bound branch or something [10:17] Unqualified 'checkout' implies heavyweight. [10:18] ah ok. I'll give that a go next time. [10:54] lifeless: ping === asac_ is now known as asac [12:21] hi, where can I find something really useful about bzr? I guess documentation at http://bazaar-vcs.org are not very clear. [12:21] dgl_: try http://doc.bazaar-vcs.org/ [12:24] dato: I've already been there, sorry about that but I really don't think bzr has a complete documentation that can explain it at all . [12:24] explain it all in what sense? [12:25] what all? using should be well covered by http://doc.bazaar-vcs.org/latest/en/user-guide/index.html [12:25] usage [12:27] dato: I've been svn user since a couple of years ago and it has a clear workflow description. I know bzr has a lot of possible workflows, but none of them are really explained. [12:28] not really explained *where*? I haven't read the user guide myself, but the table of contents *hints* like as if they are explained there [12:35] dato: I've read it, it just superficially describes some workflows. [12:36] anything in particular that you think is missing there? [12:39] dato: I guess, as svn user, learn decentralized workflows is a little hard. [12:40] http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style has the very basics, but honestly, there's not *much* more [12:41] dato: and there are some concepts that works little different, like branches, where in svn is just a copy [12:41] http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#branch [12:41] dgl_: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#concepts [12:42] oh, what luks says is better [12:42] but using DAG in that section, eek [12:43] * fullermd finds copies a buttload harder to understand. [12:45] gutsy uses bzr 0.9 and my local doc are a little bit smaller [12:46] 0.9?! [12:46] 0.90 [12:46] dgl_: the docs got *really* polished for 1.0 [12:46] Jeez. Don't DO that to my poor brain... [12:47] sorry 0.90 [12:47] dgl_: if you could read or download the online versions, I think it'd be very helpful [12:47] dgl_: most of it if not all will apply [12:48] dato: I'll read online version [12:48] great [12:50] dato: maybe I'll do some pinning to get 1.0 [12:51] there ought to be backports for gutsy in bazaar-vcs.org/releases/debs [13:11] Hi folks. Is there gui for bzr, or some ide/editor with integration? [13:13] olive [13:14] zurgutt: olive is a gui for bzr [13:16] thanks dgl [14:41] We have a bzr repository on a server. I'm interested in running [14:42] a script whenever someone pushes to that repo. Is there an easy way to do that? [14:42] (I want to run the script on the server side, and ideally don't want to install a plugin on every developer workstation) [14:43] well [14:44] if you're pushing over a dumb transport that sounds kinda hard [14:44] mwh_: I was afraid someone would say that. Polling the repo is the obvious solution then? [14:45] if it's bzr+ssh only then something might be possible [14:45] but, hm, probably not easy === asak_ is now known as asak [15:31] Meh. Google for "git to bzr conversion" and the first hit is titled "How To Convert Bazaar Repo to Git". [15:31] Use Tailor [15:32] LeoNerd: Is http://bazaar-vcs.org/BzrForeignBranches/Git known to be broken? [15:33] I'm looking for a one-off conversion. I have a few git branches based on old CVS versions of Mailman, and Mailman has since switched to bzr. [15:33] Dunno.. never seen it before. Try it :) [15:33] Good :) [15:33] If it's just a oneoff conversion, do you care about history? [15:33] If not, it might be easier just to do an export/import snapshot, and forget history [15:33] I care about the stuff I did. [15:33] History-wise. [15:34] It will probably be easier to merge 50 line patches than one 2000 line patch. [15:34] divide et impera and stuff. :) [15:36] ndim: the converted branch probably won't help you much if you want to merge it to the current mailman bzr branch [15:37] revisions will have different IDs, files will have different IDs [15:45] $ bzr branch mailman-2.1.7.cg mm-git2bzr-test [15:45] bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_output_one_line' [15:45] luks: Uhm. [15:46] what does ~/.bzr.log say about the error? [15:46] Sounds like I'm better off converting current mailman from bzr to git, rebase my git stuff on that converted thing, and then convert the merged thing back to bzr... [15:47] ndim: converting from git won't get you branch mergeable with trunk either [15:47] luks: traceback in stgit. [15:47] oh [15:47] mailman-2.1.7.cg is a git branch? [15:48] yupp. [15:48] cogito, to be exact. [15:48] bzr-git/stgit incompatibility. [15:49] The conversion from git to bzr I could do as generating a few dozen patches and commiting them with bzr. [15:49] That result would then be mergeable. [15:49] As I'd start on the bzr side with real upstream's bzr repo. [15:49] ah === Veterok__ is now known as Verterok_ [16:07] jelmer: any chance to look at #180128? [16:07] bug #180128 [16:07] Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128 [16:07] will have a look in the next few days [16:07] ok, no hurries, just thought I'd ask. [16:07] there's a couple of other bzr-svn issues I have to look at as well, and I prefer doing them in batches [16:07] very well [16:07] * jelmer is in Samba-mode atm :-) [16:30] New bug: #181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New] https://launchpad.net/bugs/181811 [16:36] ddaa: btw, I made a couple of small fixes to your bzr-git branch [16:36] great [16:36] https://code.edge.launchpad.net/~jelmer/bzr-git/jelmer [16:36] fixes support for python2.4 [16:37] jelmer: I do not plan to put any more work on bzr-git in the near future. [16:37] ok [16:37] feel free to own it [16:37] I'm not sure I want to :-) [16:37] well, it actually has the beginning of a useful test suite :) [16:37] I may end up owning it though, if I start using it for Samba [16:48] Quick question. Does anyone think it would be useful to have a shell script installer for mac that installs bazaar including all of the dependencies [16:48] Does anything like that exist already? [16:49] muffinresearch, I know there were some people working on it [16:49] muffinresearch, not sure what the status is though [16:49] phanatic: ping [16:49] I see this: http://www.nabble.com/Bazaar-OS-X-Installer-status-td14254776.html [16:49] jelmer: pong [16:50] phanatic: ^^ [16:50] muffinresearch: there is already an installer available for leopard (bazaar 1.0) [16:51] muffinresearch: http://bazaar-vcs.org/Download [16:52] I don't have leopard [16:53] Presumably macports is kept fairly up to date. [16:53] indeed [16:53] that works fine as well [16:54] jelmer: i could even get bzr-gtk working with macports, it's pretty cool :) [16:54] The main reason is just providing a quick way for colleagues to get up and running with the latest version. I normally install from source myself [16:57] macports is probably the best option. I'll get someone to try that [17:37] hello [17:38] hi [17:55] I'm following the bzr upgrade in my debian SID and I see some new format, rich-root and rich-root-pack, I don't find documentation/specification about them. === mw is now known as mw|food [18:48] hello [18:49] quick question, am I correct in assuming that bzr diff does not support UTF-16 ? [18:50] brianpeiris: AFAIK, yes [18:50] brianpeiris: you can however use it with external diff tools [18:50] but it will print utf-16 [18:51] ok, explains the "binary files ... differ" message I was getting while trying to diff a UTF-16 sql script. [18:51] actually, it won't print anything [18:51] yeah [18:51] bzr checks if the file has nul bytes, and if yes it assumes it's binary [18:54] alrighty, thanks for the help. [18:55] New bug: #181842 in bzr "BZR_SSH environment variable is not explained in docs" [Undecided,New] https://launchpad.net/bugs/181842 [18:55] hi [18:56] Can anyone explain me what are the differences between init and init-repos? [18:57] init creates a branch [18:57] init-repo creates a (shared) repository [18:58] jelmer: ok, i've already read that, but what does it mean? [19:01] basically you create a branch just few times and then start to 'branch' it, isn't it? [19:01] dgl: see http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts for an explanation of branch and repository [19:04] @dgl, see also: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#repositories [19:05] thanks, I will [19:29] Hi - From now on #bzr will have statistics on ubuntuircstats.org (gouki) [19:32] where is a nice place to create a shared repos at an ubuntu server? [19:32] Here it is: http://ubuntuircstats.org/bzr.html [19:32] Enjoy guys! === bigdo1 is now known as bigdog === mw|food is now known as mw [20:01] New bug: #181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Undecided,New] https://launchpad.net/bugs/181855 [20:16] where is a nice place to create a my mainline shared repos at an ubuntu server? [20:17] dgl, Launchpad es where you create branches, but it doesn't support shared branches as far as I know [20:17] I suppose, at the moment, it's meant for local use, to save space [20:17] depends on what you mean with shared [20:17] * beuno waves at LarstiQ [20:18] multiple people can push to branches on launchpad, provided they are part of the team owning the branch [20:18] beuno: heya :) [20:18] beuno: I've got a server with ssh, I just want to use it as a shared repos [20:18] dgl: you're asking what a good location is to place public repositories? [20:18] dgl, you want multiple people to be able to work on a branch, or you want multiple branches to use the same repo? [20:18] in a FHS kinda way [20:19] * LarstiQ user /srv/bzr/ [20:19] LarstiQ: sorry, but I think I was not clear [20:19] I was talking about filesystem [20:20] dgl, that just confuses me more :D [20:21] beuno: LarstiQ's understood me [20:21] ah, yes, he's very good at that [20:21] beuno: I was asking about a nice place to create a shared repos at my server file system [20:22] dgl, happy you got your answer :D [20:23] dgl: it depends on the rest of your filesystem layout of course, /var/www/bzr/ is also not unthinkable :) [20:23] LarstiQ: and /var/bzr? [20:23] dgl: not where I'd place it myself [20:23] * LarstiQ thinks it fits best under /srv [20:24] dgl: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM [20:24] /srv/bzr/www [20:24] hmm, maybe /bzr/www/srv/var/ [20:24] lifeless: argh :P [20:25] no like? [20:25] you'd have to have a rather complex setup for that to make sense I think [20:25] ok, ok. [20:25] something like launchpad perhaps [20:25] /var/bzr/srv/www/ [20:25] lifeless: are you pulling my leg again? :) [20:25] moi?! [20:25] I just want to use sftp [20:26] lifeless: true true, I've never caught you doing it before. [20:26] maybe not on IRC; in person you have:) [20:26] hah! Now I did ;) [20:26] dgl: anything is fine; key things to think of is 'will it be backed up by your backup programme' [20:28] lifeless: thanks [21:12] * lamont looks around for a bzr god [21:12] lifeless: you awake? and are you a god? :-) [21:14] if a user has read access to .bzr/* (and down), but lacks read access on bar/foo.c, how can I tell bzr to just ignore that little issue and keep right on going with its life? [21:15] heh === cprov is now known as cprov-out [21:15] lamont: (True, True) [21:17] lifeless: I see that you remember ghostbusters. [21:17] now about bzr and bar/foo.c .... any hope for me? [21:20] lifeless: ^^ [21:23] lamont: you can't [21:24] \q [21:24] lamont: (in general). Bu perhaps you can give me more info ;) [21:37] Nice, some random doofus clicked on one of my bundles because it's the only Google result for "JGR1my space". :\ [21:38] Googlebot also found a link to /yaygyosr.html in one of them. [21:43] rotfl [22:31] Ooh, the "JGR1my space" search was from Mexico! [22:39] yay hung test :( [22:39] Hung-like-horse, or hung-like-Sadam ? [22:39] Ouch. [22:39] I'll find out soon [22:40] hung like reading bytes that never came [22:40] I got a "Connection reset by peer" after 3 minutes pushing 1 KB of changes over bzr+ssh. :D [22:55] lifeless: Your patch to remove the need for ParentProvider.get_parents looks very strange. The goal is fine, but please don't merge in current form. [22:56] abentley: good timing; I had just hit enter to push and submit [22:56] whats wrong with it ? [22:56] It means that Graph.parents_provider is sometimes None. [22:56] Sorry [22:56] Graph.get_parents is sometimes None [22:56] That's a public API [22:56] abentley: (when you have a couple minutes and if you don't mind, did you see my question about having send, when -r is specified, always bundle those revisions, even if they're in the submit branch?) [22:57] It should always be a callable. [22:57] abentley: oh, that wasn't clear to me because its not defined explicitly [22:58] You can deprecate it, or remove it entirely, but no one expects a method to sometimes be None. [22:58] so if I add [22:58] 'if self.get_parents is None: del self.get_parents' you're happy ? [22:59] You mean Graph.get_parents would sometimes be defined, and sometimes not defined? [22:59] or I can write a regular get_parents method [22:59] well currently I can supply a ParentsProvider with get_parents = None [22:59] I prefer either deprecate it, or remove it in all cases. [22:59] because the Graph class does not define any of what you are referring to [23:00] and we don't provide any thunking in either direction [23:00] lifeless: You can, but that's an API violation. [23:00] abentley: how about I write Graph.get_parents and graph.get_parent_map, both in terms of each other [23:01] abentley: then the constructor can replace just one from the ParentsProvider [23:01] Why would you write Graph.get_parents_map? [23:01] Let's just standardize on ParentsProviders having that. [23:01] so that providers with get_parents still work - that is the point of deprecating that isn't it ? [23:02] There are no providers with only get_parents. [23:02] let me rephrase; we appear to have a deprecation which is not really a deprecation - its not compatible. I'm happy to either turn it into a full break; or a real deprecation where the old code works. Your choice. [23:02] abentley: third party repositories will almost certainly be providers with only get_parents [23:02] which is public in that Graph.__init__ takes a public parameter. [23:04] I have a slight preference for real deprecation, but I'd be fine with either. [23:04] ok I'll whip it up [23:05] dato: That has already proven to result in horrible messes, and that's why there's a submit branch. [23:05] However, if you want an override, that's fine. [23:05] override == option? [23:06] Yes. People have asked for that in the past, but they've never suggested how the commandline would work. [23:06] ok, I'll make a note, and possibly talk to you about it in the (near) future. now it'd be bed time for me. [23:06] One way would be a second revision spec. [23:06] Another would be an option that says --use-revision-spec-instead-of-submit-branch [23:08] (I guess I didn't realize the time it was when I brought up the subject, sorry. chao) [23:09] But remember that a merge directive, is meant to convey the changes you want made. That's what the -r controls. [23:10] The revisions supplied are the ones necessary for other people to apply the those changes. [23:10] For a cherry-pick, that is typically *more* revisions than the -r range includes. [23:11]