[00:00] Peng, sorry I install it by my distro so.. where is a link to the file online? [00:00] AnMaster: Not sure. [00:01] ah /usr/share/doc/bzr-1.0/NEWS.bz2 [00:01] nice that gentoo compress it too [00:02] Oh, ok. [00:02] Blah, the moment I consider not using Gentoo, everyone I see uses it. :P [00:07] AnMaster: you should be able to use "less /usr/share/doc/bzr-1.0/NEWS.bz2" without decompressing it yourself [00:07] i386, I already did that [00:08] Peng, I runs freebsd too as well [00:08] :P [00:08] anyway what is wrong with gentoo? [00:09] AnMaster: I don't want to bother with USE flags and having to compile everything. [00:09] AnMaster: Of course, as soon as I switch to some binary distro, I'll want to compile something with different flags. ;P [00:10] hah [00:10] Peng, well that is the problem neither way is perfect [00:10] Yep. [00:10] I choose gentoo because I more often need to change stuff than not [00:10] and for openoffice there is the -bin package on gentoo [00:10] I used to help run BreakMyGentoo [00:11] my sempron is strong enough for the rest [00:11] we did GNOME dev releases for 2.5 [00:11] i386, sorry you are talking to a KDE user [00:11] and emacs [00:11] back when the project was good [00:11] * AnMaster ducks [00:11] er whatever [00:13] when was 1.0 released? [00:13] how many days ago? [00:13] AnMaster: Just a few. [00:14] ok [00:25] Gentoo? hmm and i would have thought it was about bzr :-) [01:32] how do I un-ignore something? [01:32] oh, found it, sry :p [01:44] is it possible to 'unupdate'? [01:45] bzr just botched a merge like i haven't seen before [01:45] you could shelve your uncommited changes, then revert to a previous revision [01:45] ugh [01:45] what i did was bind to another repo [01:45] but i hadn't pushed first [01:45] and the remote repo was a couple of revs behind (but should have been an exact mirror otherwise) [01:46] i tried committing after binding, then it suggested updating locally because the repos weren't in sync [01:46] so i did that, and now i have two pending merges in the queue; and the merge is totally, utterly, garbage [01:46] it indented about 100 lines with two tabs [01:46] those do not exist in any version of my code [01:47] (it's a latex document, so there's almost no indentation) [01:49] bzr bind should fail if the branches are not mirrors of each other [01:49] and say 'do a push before a bind' [01:50] i can't imagine the current behaviour is what's wanted [01:50] hmm, weird, somehow it created _two_ conflicts of the same file [01:51] so there's file.OTHER/BASE/THIS, and file.OTHER/BASE/THIS.moved [01:57] woah, something is totally broken [01:57] bzr says '0 conflicts' then lists the moved files as conflicts [01:58] nevermind [02:52] * igc lunch === shenson is now known as shenson_not_here [08:34] Odd_Bloke: it's the version in Ubuntu 6.06 [08:36] New bug: #176864 in bzr-hg "AssertionError when using bzr-hg" [Undecided,New] https://launchpad.net/bugs/176864 [08:37] Odd_Bloke: which is what the server I was using runs, I've requested an update to bzr on there, but I don't know whether it will be possible or not [08:48] mdke: Oh, fair enough. It's pretty easy to run bzr from your home directory or, in fact, any directory, so that might work? [10:17] is there any eqvivalent of `hg export` and `hg import` in bazaar [10:19] there are import and export commands [10:19] i don't know what they do in hg though [10:19] (or what import does in bazaar, if i'm honest) [10:28] `hg export rev` gives that revision as patch file [10:28] which can be imported using hg import [10:28] I am trying to migrate from hg to bzr [10:28] and bzr-hg plugin is failing to import [10:29] so, I exported individual changesets from hg and trying to import that into bzr manually. [10:35] 'send' would be the closest (and pull/merge to consume), but neither would be interoperable with hg import/export. [10:40] is there any way to commit with a previous timestamp? [10:40] Not from the command line. [10:41] Have you tried using tailor to do the conversion? It's got a spotty history of working well, but it could save you a lot of manual trouble. [10:48] anandology: ah [10:48] anandology: it sounds like one could write a plugin to work with that sort of thing [10:48] anandology: but to my limited knowledge, no-one has [10:49] I am trying to understand bzr-hg plugin [10:49] it is not as very easy to understand [10:50] fullermd: I looked at tailor, but it looked very complicated. [10:51] fullermd: But, I think It will surely better then writing a plugin my self. I'll look at it again/ [10:57] anandology: i think the bzr-hg plugin might just be slightly out of date [10:57] now that 1.0 is done, it will probably be updated to that API === mvo_ is now known as mvo [11:01] sabdfl: do you mean the bzr-hg plugin is updated? [11:03] anandology: Tailor is complicated, but it's not hard to figure out. [11:03] brb [11:03] anandology: i think the main focus has been testing the core tool for 1.0, now that it is out i would expect to see quite a few plugins brought up to scratch against that API [11:04] sabdfl: do you think, it is better to wait for some more time? [11:05] anandology: who wrote the bzr-hg plugin you were trying to use? [11:06] sabdfl: RobertCollins [11:06] sabdfl: http://bazaar-vcs.org/BzrForeignBranches/Mercurial [11:08] anandology: Tailor has command line args that make it easy to generate the config file. [11:09] Peng: I am reading tailor documentation now [11:11] anandology: BTW, why do you want to convert from hg to bzr? [11:12] yes, that work was done a while ago and probably needs updating [11:12] I am more comfortable with bzr [11:12] especially managing multiple branches [11:12] I don't like the hg way of managing branches [11:13] I miss bzr merge in hg [11:15] anandology: hg merge isn't good enough? [11:17] I don't think it allows merging an individual revision [11:18] there's probably a way to do it [11:18] probably, but I feel bzr is more intutive [11:19] anandology, bzr-hg is really experimental atm. I'm not sure whether it's meant to be used as a conversion tool just yet, I think it was mainly just a proof-of-concept. [11:20] OK [11:20] At one time, it could manage a 'pull' from a hg branch. [11:20] Is tailor good enough? [11:21] Well, tailor's purely linear, so if you have merges the result might be a little wacky. But if it works, it should be OK. [11:28] fullermd: I have merges in my repo. I fear it may fail [11:43] Hi I copied my home directory from one computer to another [11:43] bzr info -> Shared repository with trees (format: dirstate or dirstate-tags or knit) [11:43] Location: shared repository: /var/home/users/mbako [11:45] Now my homedir is: /home/users/mbako/ [11:45] I did: [mbako@appserver_cz abbon]$ bzr init-repo ~ [11:45] but still I see non-existant path (/var/home/users/mbako) as shared repository dir ... [11:45] How can I fix it ? [11:47] matkor: That's interesting. I didn't think the location was hardcoded. [11:47] I know it's not hardcoded in branches. [11:47] It's not. [11:48] I would guess that /home is a symlink. [11:48] And it would make no sense for a shared repo to hardcode its own location. [11:48] what fullermd says makes sense [11:48] fullermd: /home was symlink on previous machine [11:48] where shared repo was created ... [11:49] Basically I do not care of WT contents (I have them in repo) all I want is make new setup with shared repo in ~ .... [11:50] matkor: Check if it's a symlink or not on the new machine. [11:50] Are you sure it's not on this machine too, though? [11:50] Repos sure don't store where they are, and branches don't store where their repo is. There's nothing to remember. [11:51] New bug: #176905 in bzr "bzr diff requires lock" [Undecided,New] https://launchpad.net/bugs/176905 [11:53] fullermd: Hmm, pretty sure: ~]$ pwd [11:53] /home/users/mbako [11:53] matkor: ls -l / [11:54] Hey there. How does one create a local branch of a given branch with only the latest revision in it? (i.e. only the latest revsion is pulled) [11:54] matkor: If you did 'cd /home/users/mbako' and /home was a symlink, pwd would not resolve the symlink. [11:54] dennda: Not yet. [11:54] dennda: Well, you could use a lightweight checkout. [11:54] Depends on the shell. csh does. [11:54] fullermd: Oh. [11:55] I use bash, just because I always have. I've been wondering about zsh... [11:55] Peng: What would the command be? [11:55] OK. you are right /home is symlink even now ... [11:55] dennda: bzr co --lightweight. Checkouts work like centralized VCSes, where committing updates the remote branch too. [11:56] dennda: Also, bzr might have to download a lot of history to reconstruct the current version, even if it isn't kept. [11:56] (Err, replace that with: Also, bzr might have to download a lot of history to reconstruct the current version, though it doesn't keep it.) [11:56] So it is not possible to only download the latest revision in order not to download all the history? (I have a 700kb project here. with history it is > 10 MB) [11:57] dennda: Like I said, a lightweight checkout will do just that (storing zero history). But due to how the history is stored, it will download more than just the latest revision. It's also designed to not be too bad, though. [11:59] dennda: (If you want the details, when a new revision of a file is stored, it will either store the entire contents of the new revision of the file, or only the changes. So to download a copy of the most recent version, you might have to download ten sets of differences and then a full copy, and then reassemble them.) [11:59] s/changes/changes between it and the last version/ [12:03] ok, thx === cprov-away is now known as cprov-out === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === mw|food is now known as mw [15:28] Congrats for the 1.0 [15:41] New bug: #176948 in bzr "bzr tag has "directory" option, would be more accurately called "branch"" [Undecided,New] https://launchpad.net/bugs/176948 [16:11] Hi all. I'm not satisfied with the speed at which bzr runs, and I want to make sure that I have it going as fast as I can. [16:14] CardinalFang: Well, are you using the most recent version, are you using the pack-0.92 repo format, are you using the smart server, and is it using the various C bits? [16:15] With tool X, I can make a local branch in about 30 seconds. Bzr on the same repository data takes 14.5 minutes. [16:15] and which operations are you finding slow? [16:15] I thought I set up a shared repository. How can I check that first? [16:16] CardinalFang: 'bzr info' in the branch. [16:16] Ah, it seems not. "branch root: ." [16:16] CardinalFang: Under "Location", it should list a shared repository path. [16:16] CardinalFang: Just above "branch root". [16:17] CardinalFang: If you created the branch before the shared repo, it won't be automatically converted. [16:17] CardinalFang: You'll need to branch out of the repo and back into it. [16:17] "Standalone tree (format: pack-0.92)" [16:17] (Moving files around would work too, but you're not supposed to. [16:17] CardinalFang: It would also say "Repository tree" if you were using a shared repo. [16:17] CardinalFang: Good, you're using packs. [16:18] "Standalone tree" means that it's not using a shared repository? [16:18] CardinalFang: Correct. [16:19] CardinalFang: Look in .bzr/repository/packs in the shared repo. Is there anything there (that's non-zero)? [16:20] Peng, Yes. One Very Big file. [16:20] Alright. Starting over. [16:21] CardinalFang: The very big file is there? Interesting. Are there any other branches in the repo? [16:22] Peng, Yes. Let me start anew. I set this repo up with a dev tree of several months ago. [16:22] Argh, my fingers are cold and I can't type. [16:22] * Peng puts his hands under the cat. [16:22] Peng: type more! they'll get warmer. [16:23] They'll turn black and fall off! [16:23] Then they won't feel cold. Problem solved :p [16:23] Gahh. [16:23] Peng: bite the cat, it will take care of your hands [16:24] You guys are useless. [16:25] sneeker [16:26] interesting use for a cat... [16:26] mh... now, how do you stop it from trying to play on the keyboard? [16:27] Hard to do, when your hands are under it (and the keyboard is under your hands) [16:27] Who took my gloves? [16:27] This cat doesn't go on the keyboard. [16:28] The other cat does. At first she stepped around the keys, but after I shooed her for a while, she started walking on them. :( [16:28] it's after the mouse? [16:29] Ooh, found them! [16:30] * Peng putrsd them on. [16:30] Thie m,y n opt w3olrtkl well. [16:31] that's when you get to appreciate all the value of tactile feedback [16:33] No, that's wehen I get to appreciote thhje vlae of smqll, non-flabby finmgers. [16:34] Nah, you just need a bigger keyboard. [16:34] * Peng sighs and takes them off. [16:34] fullermd: Hahaha. [16:34] fullermd: Two-inch-wide keys. Brilliant. [16:34] Makes it a lot easier to "punch enter" :p [16:34] I think I could reach both Ctrl keys... [16:35] I just learned the downside of super-spiffy, sweat-wicking sports socks: they don't warm my feet at all when I need it! [16:35] Is there any plugin that warn user about *new* unknown files before commit? [17:04] Alright, my time is down 14.5m -> 1 m. That's still double the branch time of the Other Tool. Any other tips? [17:04] Shared repo made the difference, btw. [17:08] "is it using the various C bits?" _patiencediff_c.so, _dirstate_helpers_c.so, and _knit_load_data_c.so ? Seems so. [17:08] CardinalFang: I guess bzr is slower at building the tree than the Other Tool. [17:08] CardinalFang: Yes, [17:39] is it a known issue that /releases/debs/gutsy has 1.0rc1 ? [17:41] I think so [17:42] lifeless usually handles the debs, but IIRC somebody said poolie was looking at getting that updated [17:42] s/that/the bazaar-vcs.org debian repo/ === shenson_not_here is now known as shenson === shenson is now known as shenson_not_here [17:47] I'm surprised that the Bazaar user guide doesn't mention the BZR_SSH environment variable. Do most people use paramiko, even when accessing servers such as Launchpad's that require a public key? === weigon_ is now known as weigon [17:48] CardinalFang: can you paste the output of "bzr info -v"? [17:48] MattCampbell: AFAIK, bzr will use the ssh command if it's available [17:49] and get ssh-agent love automatically [17:49] It didn't on Windows, even when I renamed plink to ssh.exe [17:49] (and it's on my PATH) [17:49] oh, dunno about windowz [17:50] Are there any known issues with bzr+ssh and plink? [17:50] I'm wondering if the bug I recently reported on launchpad-bazaar is due to a misconfiguration on my part. [17:50] but the initial push worked just fine === mrevell_ is now known as mrevell [17:56] somebody do explain to me: «14 December 2007 - Bazaar goes 1.0!» «$ dpkg -l bazaar»: «bazaar 1.4.2-5.3» [17:56] is debian's version numbering wrong? [17:57] The package name is bzr [17:58] StucKman: bzr was bazaar-ng [17:59] * StucKman confused [17:59] there was a project called tla [17:59] some folks at canonical had a branch of that, which they called bazaar [17:59] yes [17:59] aha [17:59] that's what you are looking at v1.4.2 of [17:59] bzr was a skunkworks, from scratch clean set of ideas [18:00] I see, indeed :) [18:00] and when most of the canonical guys embraced that, they brought the name along [18:00] I see, thanks [18:01] np, it's probably my fault [18:01] will be all clear when the bzr guys deliver 2.0 :-) [18:01] Bzr already uses 2.0 in its Windows Application Data directory. [18:01] cunning [18:01] That means that 2.0 will have to be the last version too :p [18:02] heeh [18:02] The use of 2.0 in the appdata dir name was the first wart I noticed in bzr. [18:02] you could just do a version jumping a la slackware [18:03] 0.9, 1.0, 1.1, 3.0 :-P [18:04] The Sun way is better. 3.0, 4.0, 4.1, NewName 1.2, 1.3, 1.4, 5, 6... [18:11] New bug: #176985 in bzr "Memory error on status 0.90" [Undecided,New] https://launchpad.net/bugs/176985 === mrevell_ is now known as mrevell [19:40] Hey, I am having an issue commiting from a checkout in a shared repository. It is giving me this error: http://pastebin.ca/820824 [19:42] rexbron: you can't commit to launchpad-hosted branches over http [19:43] (or to any-hosted branches over http) [19:43] rexbron: you should probably rebind your branch to the bzr+ssh:// URL. [19:43] I'll give that a try [19:43] "bzr unbind; bzr bind bzr+ssh://bazaar.launchpad.net/~ubuntustudio-dev/ubuntustudio-controls/ubuntustudio-controls" === BasicMac is now known as BasicOSX [19:47] radix: thanks, that worked :) [19:49] hello everyone [19:50] is there anyway to *merge* one branch with another WITHOUT deleting files that arent in the codebase being pulled from? [19:51] bagueros: just merging should do that. does it not? [19:51] bagueros: or did the other codebase delete those files so the merge contains information about the delete? [19:54] the inbound codebase hasnt DELETED those files [19:54] it just dont include them [19:54] so i get a "-D path/to/file" when it shows me what's happening with the merge [19:54] and then those files are gone [19:55] bagueros: ah [19:55] bagueros: well, you can revert them after the merge and before the commit... but I agree that's a little annoying [19:55] bagueros: you could merge the other way... [19:55] Er. That shouldn't happen... [19:56] bagueros: branch the remote codebase, then go into that branch and merge from the codebase with the files [20:39] I've been reading tutorials, slides and even the manual, and I can't get the hang of push/pull. what is it exactly for? [20:42] StucKman: To get changes from another branch, or to send them to another branch. [20:43] froma a sibling branch? [20:47] StucKman: a workflow where pull/push are used is "Decentralized with shared mainline" (http://bazaar-vcs.org/Workflows#head-ca3ccf73574776b36453b2213789731549e54167) [20:57] Verterok: it doesn't *explain* anything :( [20:58] it assumes I know what push/pull is for :| [21:16] StucKman: so, in this setup, you have a complete copy of the repos [21:16] StucKman: committing is done locally and involves no interaction with anyone else's copy of the code [21:16] StucKman: to 'pull' means to get a get of changes from a repository that isn't the one you are working in [21:17] StucKman: and to 'push' means to send any changes that your repos has that the other repos doesn't have [21:17] StucKman: both of those operations require that the repositories haven't diverged [21:17] StucKman: if they have, then you need to 'merge' instead of 'pull' before you 'push' [21:18] StucKman: make sense? [21:21] Hi. I'm looking at one of my systems that I'm keeping stable at Dapper. (Actually, my hosting company is.) In the repos I notice both bzr and bazaar. Which is more current? [21:21] kjcole: bzr. [21:22] hi [21:22] kjcole: There once was a VCS called Arch. Canonical made a fork of it called Bazaar (baz). Then they came up with an all new VCS called Bazaar-NG (bzr). Bazaar died, so now it's called Baz and Bazaar-NG is called Bazaar. [21:22] Peng: Oh goodie. I thought that was the case, but I've been dealing in version hell lately and was getting forgetful. ;-) bzr's what I have installed. [21:24] mtaylor: I'm playing with it so I can get the hang of it [21:24] and I think I got it :) [21:24] tx all [21:24] it's bug 143998 [21:24] Launchpad bug 143998 in bazaar "rename 'bazaar' package to 'baz'" [Low,New] https://launchpad.net/bugs/143998 [21:24] i hope it will be fixed in hardy if [21:24] mtaylor: but, can you merge a branch which is not your ancestor? [21:25] StucKman: does it share a common ancestor? then yes [21:26] mtaylor: in which cases they could not have a common ancestor? I only see a tree, but I surely am missing something... [21:26] StucKman: so there's a repos, let's call it A [21:26] StucKman: you branch it, so does someone else [21:26] StucKman: time passes. [21:26] StucKman: then you merge from someone else's copy of A [21:26] no problem [21:27] copy as in modified branch? [21:27] yes [21:27] every one who has branched the repos has a full copy of the repos and all change history [21:27] I see [21:28] so when you merge from them, bzr can tell what changes that person has that you don't [21:28] but they *have* a common ancestor in that case, or not? [21:28] yes [21:28] if they don't have a common ancestor, then you're out of luck [21:28] but most of the time, having a common ancestor isn't a problem [21:28] Well. I merge branches with no common ancestors all the time. But that's a slightly different situation. [21:28] my question was about how two barnches could have not a common ancestor [21:29] branches* [21:29] StucKman: Two entirely independent branches. "bzr init A", "bzr init B". [21:30] hmm, and I still can push/pull between them? [21:30] (those were out of my picture) [21:30] (it's like merging linux and kde source code :) [21:30] s/it's/sounds/ [21:31] StucKman, you could only push-pull with --overwrite [21:31] probably not what you want [21:31] however, once you do a merge between them, you will be able to [21:31] StucKman: Exactly. [21:33] is "bzr pull" (w/o branch spec) the same as "bzr merge"? [21:34] no, pull says "make my branch the same as that one" [21:34] merge says "integrate their changes with mine" [21:34] so if they've diverged, pull will refuse [21:35] sounds like equivalent to making the barnmching again [21:35] branching* [21:38] and a push won't merge, but overwrite, or I got it wrong? [21:38] if people on A and B have committed new revisions [21:39] and you try to pull from A to B, it'll say "branches have diverged, try merge" [21:39] so, you could merge them [21:39] or if you want to throw away B's changes and just take A [21:39] then do "pull --overwrite" [21:39] A.push B will merge A's modifications in B's branch, I get that [21:39] (or push --overwrite in the opposite directorion) [21:40] one way to remember is that [21:40] only "merge" does a merge [21:40] hmm, I think I gotta play a little more with it [22:02] hi all, there is one thing I can't understand about bzr [22:02] how can I maintain two branches in the same repository [22:03] I mean I want the "A" and "B" versions which are incompatible, both available from the same bzr publicly available repository [22:03] Hey, is there a gitweb equivalent for bzr? [22:04] Le-Chuck_ITA: in two directories at the same level, because in bzr every branch lives in a separate directory [22:04] dato: I was starting to suspect that :) [22:04] thanks [22:09] and what's a pending merge? [22:10] when you `bzr merge`, you have to commit afterwards [22:10] aja [22:10] tha may be it [22:10] a pending merge are those revisions which will get actually "merged" when you commit [22:13] ok, I think I got it [22:33] does bzr have a global ignores configuration somewhere? [22:34] (is it a feature of "locations.conf" maybe?) [22:35] glyph: ~/.bazaar/ignore [22:37] dato: d'oh, thanks - don't know how I missed that [22:37] orospakr: There's loggerhead (TurboGears app) and bazaar-webserve (bzr plugin). [22:38] and bzrweb, which I didn't know about until the other day [22:38] abadger1999, hm, yeah, that's what I've found. [22:38] thanks. :) [22:38] what's the recommended way to install bzr 1.0 on Max OS X? [22:59] thumper: either macports or the installer listed on the download page [22:59] http://bazaar-vcs.org/Download === jam_ is now known as jam [22:59] I'm not sure if the installer works on 10.4, I guess I should try it out. [23:02] I'm not certain that my tutorial is accurate, but it may help the beginner. http://dc.ubuntu-us.org/resources/tutorials/bzr-intro.html [23:02] I'd appreciate it if folks point out glaring errors. [23:03] (As for the style sheet, unfortunately, I don't control that.) [23:10] morning