| jelmer | lifeless: hmm, it may be more useful to have that pqm than I thought after all | 00:01 |
|---|---|---|
| jelmer | lifeless: I found myself looking for the revision to match a particular merge request, and now it looks like we have a test regression | 00:02 |
| beuno | (btw, thanks igc and Odd_Bloke, :D) | 00:09 |
| igc | np | 00:09 |
| Odd_Bloke | beuno: :) | 00:09 |
| lifeless | beuno: I'll have a read a little later | 00:09 |
| lifeless | jelmer: kk | 00:10 |
| beuno | lifeless, great, thanks! I'll wait then, no real hurry. | 00:11 |
| lifeless | beuno: perhaps mail me the link so I don't lose it ;) | 00:11 |
| beuno | lifeless, on it's way | 00:12 |
| poolie | hello lifeless, welcome back | 00:15 |
| Aloha | i like the webpage. very clean & simple | 00:20 |
| poolie | Aloha, which one? | 00:25 |
| Aloha | the bazaar mainpage | 00:25 |
| === BasicMac is now known as BasicOX | ||
| === BasicOX is now known as BasicOSX | ||
| === kiko is now known as kiko-zzz | ||
| ubotu | New bug: #186876 in bzr-svn ""The file id FOO is not present in the tree" on svn-import" [Undecided,New] https://launchpad.net/bugs/186876 | 00:40 |
| jelmer | w00t, the python-subversion memory leak bug has finally been fixed in hardy | 00:55 |
| spiv | jelmer: neat! | 01:11 |
| * igc food | 01:57 | |
| === not-xjjk is now known as xjjk | ||
| === mw is now known as mw|out | ||
| ubotu | New bug: #186920 in bzr "bzr launchpad does not handle proxy when used for name resolution " [Undecided,New] https://launchpad.net/bugs/186920 | 04:25 |
| ubotu | New bug: #178772 in trac-bzr "Must use datetime for trac 0.11" [High,In progress] https://launchpad.net/bugs/178772 | 04:30 |
| igc | bbiab | 04:51 |
| ubotu | New bug: #116659 in trac-bzr "Phantom changesets in timeline" [Medium,Triaged] https://launchpad.net/bugs/116659 | 05:05 |
| rcohen | is http://bazaar-vcs.org/KnitMerge an accurate depiction of the current merge algorithm used by bzr? | 06:01 |
| poolie | rcohen, it's approximately correct for merge --knit | 06:01 |
| poolie | it is not the default merge algorithm | 06:02 |
| rcohen | ah, what's the default algorithm? | 06:02 |
| rcohen | the knit algorithm looks very similar to the codeville merge algorithm | 06:02 |
| poolie | a 3-way merge | 06:02 |
| poolie | it is | 06:03 |
| rcohen | which i have some experience with | 06:03 |
| rcohen | is the 2-way diff done directly between the 2 sides, or is a match done against the knit/weave first and then lined up? | 06:04 |
| poolie | i'd have to check the code | 06:04 |
| poolie | but i believe it is done on the text first | 06:04 |
| poolie | so it will be more forgiving of accidental convergence | 06:04 |
| poolie | which aiui cdv is more paranoid about | 06:04 |
| poolie | um | 06:05 |
| poolie | it's been suggested that we should make this the default merge type | 06:05 |
| rcohen | codeville does the former | 06:05 |
| rcohen | (hi, i wrote most of codeville) | 06:05 |
| rcohen | though i think the latter would have some advantages | 06:05 |
| poolie | i wondered :) | 06:05 |
| rcohen | i've become a big fan of convergence | 06:05 |
| rcohen | as it has this nice side effect of cherry-picking just working, even if someone produces a diff and applies it to a different branch | 06:06 |
| rcohen | the codeville algorithm has had some small tweaks, but it definitely supports accidental convergence | 06:08 |
| rcohen | you'll have to tell me if this is accurate, but i believe the biggest difference between what cdv does and the knit merge is that cdv tracks spaces between lines instead of lines themselves | 06:09 |
| rcohen | this was done to catch line removals without adds | 06:09 |
| lifeless | rcohen: you may find --lca interesting | 06:11 |
| rcohen | since you have a weave, i think you can actually make some improvements over what codeville is doing | 06:12 |
| rcohen | not that the codeville merge is bad or anything :) been working very well in practice | 06:12 |
| lifeless | back later | 06:13 |
| rcohen | hmm, i guess you handle the deleted lines when you determine line ancestry on both sides, so that's kosher | 06:15 |
| rcohen | my gut feeling is that you'd do better by matching the 2 sides against the weave instead of directly against each other | 06:16 |
| rcohen | matching directly introduces a less precise resolution step which can cause some problems | 06:17 |
| rcohen | these usually show up when files have their contents reordered or something does a cut-and-paste job and makes minor modifications | 06:18 |
| rcohen | s/something/someone/ | 06:18 |
| rcohen | off the topic of merging, does bzr support '...' globbing (like in perforce) or something like it? | 06:20 |
| rcohen | '...' is like '*' but recurses through subdirectories | 06:23 |
| poolie | rcohen, merging is kind of swapped out for me | 06:23 |
| poolie | yes, ** | 06:23 |
| rcohen | very nice | 06:23 |
| rcohen | it's ok, i happen to have paged a bunch of it back in today | 06:24 |
| rcohen | it was swapped out for quite a while there | 06:24 |
| poolie | do you work at/on bittorrent too? | 06:26 |
| rcohen | not anymore | 06:26 |
| rcohen | i never contributed much in terms of code | 06:27 |
| rcohen | still not sure how i feel about being management | 06:33 |
| poolie | same here | 06:34 |
| rcohen | i just wanted to poke my head in, looks like bzr is shaping up nicely | 06:39 |
| poolie | yes | 06:39 |
| rcohen | and i'm glad at least one other project cares about a sane UI :) | 06:39 |
| poolie | performance seems to be pretty good now, and other things are coming along | 06:39 |
| poolie | launchpad.net hosting is becoming quite popular, and its ui should keep improving too | 06:40 |
| poolie | i guess you're in the us? we're having a developer conference in london in march, if you happen to be nearby | 06:40 |
| rcohen | i'd love to visit london again, but sadly i doubt it'll happen | 06:42 |
| rcohen | i'm in san francisco | 06:43 |
| rcohen | you in lexington? | 06:43 |
| poolie | no, i'm in Sydney | 06:43 |
| rcohen | how does networking performance compare? | 06:45 |
| poolie | better than hg and git over plain http, according to ian's measurements | 06:46 |
| poolie | and fairly good for the smart server, though we still have more to do for avoiding round trips | 06:46 |
| rcohen | the server also implements access controls? | 06:47 |
| poolie | yes | 06:47 |
| poolie | are you interested in getting involved? or in using bzr? | 06:47 |
| rcohen | you don't use client-side SSL certificates or anything crazy like that, do you? | 06:48 |
| rcohen | possibly | 06:48 |
| poolie | no, normally people use ssh | 06:48 |
| poolie | we use paramiko on windows so you don't need an external ssh client | 06:48 |
| rcohen | i haven't had much spare time for quite a while, which is why codeville has been in bug fix mode for a long time | 06:49 |
| igc | rcohen: see http://doc.bazaar-vcs.org/bzr.dev/developers/lca-merge.html (if you haven't already) for abentley's write-up on lca merge | 07:13 |
| Aloha | how do you make files that are under version control not under version control anymore? | 07:22 |
| Aloha | i know its not bzr rm. i learned that the hard way | 07:22 |
| rcohen | i'll take a look at it, though i'm not a huge fan of 3-way merges because they end up not using a lot of good history information | 07:22 |
| TFKyle | Aloha: bzr rm --keep? | 07:22 |
| Aloha | TFKyle, thnx | 07:23 |
| TFKyle | (oh, also bzr revert I think might do it they're newly added) | 07:23 |
| Aloha | how do you guys handle debian directory of projects you're working on? do you include it or exclude it? | 07:25 |
| mtaylor | Aloha: I include it and use bzr-builddeb | 07:25 |
| TFKyle | for the one project I've debianized I include it | 07:25 |
| Aloha | mtaylor, whats bzr-builddeb do? | 07:25 |
| mtaylor | Aloha: bzr-builddeb will split it out for you so you can still have an "orig" tarball and a then your debian stuff | 07:26 |
| mtaylor | Aloha: it's got a few different operational modes | 07:26 |
| mtaylor | Aloha: but including the debian source in your source branch is definiltely something it handles easily | 07:26 |
| Aloha | my program isn't really functional if it not a package because it looks in /usr/share/pixmaps for images | 07:27 |
| Aloha | i do dh_install to move them there | 07:27 |
| mtaylor | Aloha: yeah - I'd include the debian dir then | 07:27 |
| Aloha | mtaylor, thnx | 07:27 |
| mtaylor | Aloha: but I'd still look in to bzr builddeb ... it'll make things easier on it | 07:27 |
| mtaylor | on you, rather :) | 07:27 |
| Aloha | mtaylor, cool i'll research it | 07:28 |
| mtaylor | Aloha: don't konw if you've played with it, but there's also a tool called debcommit which will let you make changelog entries and then use them as your commit message | 07:28 |
| mtaylor | (somes in devscripts, I think) | 07:28 |
| Aloha | mtaylor, i use dch for my changelog | 07:28 |
| mtaylor | Aloha: yup | 07:28 |
| mtaylor | Aloha: so once you do that, you just do a debcommit | 07:29 |
| Aloha | mtaylor, cool thnx | 07:29 |
| mtaylor | and it'll read the new changelog entires and do a bzr commit for you with the new changelog entires as the message | 07:29 |
| mtaylor | so you don't have to do it twice | 07:29 |
| TFKyle | wonder if it'd be reasonable to autogenerate a changelog from bzr history | 07:29 |
| TFKyle | though that wouldn't handle distribution/etc. | 07:30 |
| mtaylor | might be... MySQL does that from bk sources for its changelog | 07:30 |
| mtaylor | I like the drive-the-bzr-history from the changelog approach though myself... but I'm a debian bigot, :) | 07:30 |
| TFKyle | thing I dislike about that is you have to be on a debian system to make commits unless you do it manually | 07:31 |
| mtaylor | yes | 07:31 |
| mtaylor | that is true | 07:31 |
| Aloha | why wouldn't you be on a debian system? ;) | 07:31 |
| mtaylor | but then... I hate not being on a debian system | 07:31 |
| mtaylor | :) | 07:31 |
| * TFKyle doesn't use debian personally, except when he's making debian packages :D | 07:31 | |
| * mtaylor shudders | 07:31 | |
| * Aloha luvs debian | 07:31 | |
| * mtaylor has heard of such people | 07:31 | |
| Aloha | do you use gentoo? | 07:32 |
| TFKyle | yep | 07:32 |
| Aloha | freaking masochist | 07:32 |
| mtaylor | that's what I'm saying | 07:32 |
| mtaylor | but you know - whatever makes you happy! | 07:32 |
| * TFKyle loves gentoo, except the politics of course | 07:32 | |
| mtaylor | well, I think the politics blow everywhere | 07:32 |
| Aloha | amen | 07:32 |
| TFKyle | though, I have to admit, it isn't quite as bad as the Canadian House Of Commons/Question Period :P | 07:33 |
| Aloha | canada in general blows ;) j/k | 07:35 |
| Debolaz | I used to use Gentoo, but eventually dropped it. I didn't like the idea of pushing out updates to the stable portage branch that bricked the system if you didn't answer correctly to questions in the upgrade phase, and gave no suggestion to what the "right" answer was except in some reply to a forum message hidden in the depths of oblivion. | 07:35 |
| Odd_Bloke | Canada's not even a real country, right? | 07:36 |
| * TFKyle has been using ~arch since forever personally | 07:36 | |
| * Odd_Bloke used Gentoo until he accidentally hosed his system, then used Ubuntu until he realised that Debian was both better _and_ newer. :p | 07:36 | |
| * TFKyle disagrees with that, but meh | 07:37 | |
| Debolaz | Gentoo seems to have looked at FreeBSD, and tried to replicate it for Linux but completely missed the big picture. | 07:37 |
| * mtaylor recently tried to apt-get dist-upgrade from gutsy to lenny on one of his machines | 07:37 | |
| mtaylor | didn't really work out | 07:37 |
| mtaylor | at all | 07:37 |
| TFKyle | havn't really given debian/ubuntu that much testing though, dislike the idea of not having rolling updates | 07:37 |
| mtaylor | system totally unusable | 07:37 |
| Odd_Bloke | TFKyle: I use unstable, so I do get them. | 07:38 |
| mtaylor | I wish ubuntu had an unstable | 07:38 |
| mtaylor | or a rolling unstable | 07:38 |
| Odd_Bloke | mtaylor: There's gutsy-proposed or somesuch, which may or may not do something along those lines. | 07:38 |
| mtaylor | Odd_Bloke: yeah... not quite the same though | 07:38 |
| mtaylor | Odd_Bloke: I miss the good-old days of apt-get upgrading every morning | 07:39 |
| Debolaz | I keep trying Linux distributions, but I always end up coming back to FreeBSD. | 07:39 |
| Odd_Bloke | Ubuntu's rolling unstable would have to be Debian unstable. :p | 07:39 |
| mtaylor | Odd_Bloke: :) | 07:39 |
| mtaylor | Debolaz: I hear that from people, and I've tried FreeBSD, but I don't like it for the same reason I don't like Gentoo... | 07:39 |
| mtaylor | which is that I don't want to compile mozilla or openoffice or X | 07:40 |
| mtaylor | ever | 07:40 |
| Odd_Bloke | To be fair, Gentoo has binary packages to avoid painful compilations. | 07:40 |
| mtaylor | that, and I'm used to linux, so many of the freebsd file locations seem weird to me | 07:40 |
| mtaylor | Odd_Bloke: fair enough | 07:40 |
| * TFKyle is compiling oo.o right now, just for the heat though :P | 07:40 | |
| mtaylor | Odd_Bloke: it did not back when I used it last | 07:40 |
| Odd_Bloke | And the first two of those three I don't think I have installed on any of my Debian systems. | 07:40 |
| * mtaylor has to have openoffice for work | 07:41 | |
| TFKyle | -48C with the windchill outside | 07:41 |
| mtaylor | TFKyle: good god man. | 07:41 |
| mtaylor | TFKyle: are you on the north pole? | 07:41 |
| TFKyle | mtaylor: nope, Regina, Saskatchewan, pretty close to the US | 07:41 |
| Odd_Bloke | http://chris-lamb.co.uk/2008/01/05/debian-packages-sorted-by-build-time-and-build-space/ shows how bad OO.o compilation is. :p | 07:42 |
| Aloha | i'm in hawaii its like 70F heh | 07:42 |
| * Odd_Bloke prefers Abiword. | 07:42 | |
| Debolaz | mtaylor: Well, there are elements which FreeBSD and Gentoo has in common that might be undesirable for many people. But what I want is a system with a consistent design that has every aspect of it well documented. I don't *want* to compile things from source, and I do think the ports and binary package system leaves a few things to be desired. But I feel the good outweighs the bad in the case of FreeBSD. | 07:42 |
| * Aloha prefers gedit | 07:42 | |
| Debolaz | While Gentoo doesn't really have any adventage aside from a large collection in portage. | 07:42 |
| Odd_Bloke | Well, that's a lie. I prefer LaTeX, but for those times when people demand really ugly documents, I prefer Abiword. | 07:42 |
| * mtaylor _prefers_ emacs | 07:43 | |
| Odd_Bloke | As for text editor, vim is clearly the best. | 07:43 |
| Odd_Bloke | Crap, now we have to fight at dawn. | 07:43 |
| mtaylor | damn | 07:43 |
| mtaylor | I'm too tired for that | 07:43 |
| mtaylor | can we just both agree that nano is annoying every time it starts? | 07:43 |
| Aloha | Odd_Bloke, gvim ;) | 07:43 |
| mtaylor | and that we both wish it wasn't the default editor alternative | 07:44 |
| Debolaz | joe++ # Best damn editor ever. ;-) | 07:44 |
| Odd_Bloke | mtaylor: Indeed. | 07:44 |
| Debolaz | emacs # Nice OS, bad editor | 07:44 |
| mtaylor | Debolaz: I totally agree about the consistent design part | 07:44 |
| Odd_Bloke | joe/joe++ experience required. | 07:44 |
| TFKyle | nano's a bit too suckish imo, it gets the job done in some cases but using it as your main text editor would suck | 07:44 |
| mtaylor | Debolaz: which is the thing I like about debian, too, and one of the places where I think Debian and FreeBSD are similar | 07:44 |
| Aloha | i got a bug i think | 07:45 |
| TFKyle | its syntax highlighting isn't that great even when enabled imo | 07:45 |
| mtaylor | Debolaz: I try to explain this to RH-using folks and they just don't seem to get it | 07:45 |
| Aloha | when i do apt-get install bzr it installs 1.01~gutsy1 | 07:45 |
| mtaylor | TFKyle: nano has syntax highlighting? | 07:45 |
| Aloha | but... | 07:45 |
| mtaylor | Aloha: where are you installing from? | 07:45 |
| TFKyle | mtaylor: newer versions do, though it's disabled by default unless you enable it in the config file iirc | 07:46 |
| Aloha | mtaylor, where? | 07:46 |
| Aloha | but apt-cache show bzr shows Version: 0.90-1 | 07:46 |
| Debolaz | I feel certain Linux distributions thinks it's perfectly ok to put things randomly in /opt, /var, /usr/local, etc etc, without any reasoning for what goes where except "it felt right at the time". | 07:46 |
| mtaylor | Aloha: yeah. 1.01~gutsy1 is old | 07:46 |
| mtaylor | Aloha: apt-cache show bzr will show you multiple versions | 07:46 |
| mtaylor | Aloha: scroll back further | 07:46 |
| mtaylor | you're seeing the one from gutsy itself at the bottom of the list | 07:46 |
| mtaylor | Aloha: but you should add deb http://ppa.launchpad.net/bzr/ubuntu gutsy main to your sources | 07:47 |
| Aloha | mtaylor, ok thnx | 07:47 |
| Debolaz | mtaylor: Hehe, RH and SUSE are on my banlist for systems I admin. | 07:48 |
| Aloha | Rh is ok. only because centos came out of it | 07:48 |
| mtaylor | Debolaz: I wish I could say the same | 07:48 |
| Odd_Bloke | RHEL is used by the CS department here, and it's pretty painful. | 07:48 |
| mtaylor | Debolaz: but I'm a consultant for MySQL, so I have to touch whatever they're running | 07:48 |
| Odd_Bloke | NFS and DNS randomly fail, and RH have been completely unhelpful as far as support goes. | 07:49 |
| Aloha | my VPS runs centos | 07:49 |
| mtaylor | if it _has_ to be redhat based, Centos isn't bad | 07:50 |
| mtaylor | although I have to say RHEL5 took a major step forward by actually learning from Centos | 07:50 |
| mtaylor | rather than just sticking with the RH status quo | 07:50 |
| poolie | mtaylor, we're moving from putting those packages on bazaar-vcs.org to ppa | 07:50 |
| mtaylor | poolie: good. so is bazaar-vcs going to point to the ppa now? | 07:51 |
| poolie | i'll just change the web page now | 07:51 |
| mtaylor | sweet | 07:51 |
| * Debolaz should make an effort to learn bzr if he intends to keep hanging around in this channel. :-) | 07:51 | |
| Aloha | was bazaar created by canonical? | 07:51 |
| poolie | i need to also work out how/whether to redirect the existing archive | 07:51 |
| poolie | Aloha: and friends | 07:51 |
| Aloha | poolie, everyone? ;) | 07:52 |
| mtaylor | poolie: good luck with that! :) | 07:52 |
| mtaylor | Debolaz: might not be a waste of your time :) | 07:52 |
| Aloha | how do i get the key from bzr ppa? | 07:53 |
| Debolaz | mtaylor: Hehe. I am in doubt if I'll be replacing git anytime soon, but learning is never a bad thing. Especially since everyone keeps saying how fantastic bzr has come lately. :) | 07:55 |
| mtaylor | Debolaz: I think that if git is working fine for you, then great | 07:55 |
| TFKyle | bzr's been fantastic for quite a while :P | 07:55 |
| mtaylor | Debolaz: but I'm personally thrilled with bzr's ability to work with non-bzr systems too | 07:55 |
| mtaylor | makes migrating or running heterogenous GREAT | 07:56 |
| poolie | Aloha, there is no key for it at the moment, but it's meant to be coming soon | 07:56 |
| poolie | like in the next launchpad release | 07:56 |
| Aloha | poolie, ok cool | 07:56 |
| Debolaz | My main complaint about git is the horribly weird frontend tools. Made it really difficult to understand the system at first. | 07:56 |
| * TFKyle wonders when lp will allow people to kill packages from their ppa | 07:56 | |
| Debolaz | I'd be using mercurial if mercurial had been better with the thing you pointed out there, working wih non-mercurial systems. | 07:56 |
| Debolaz | Git actually works well against subversion, which is an important feature for me. | 07:57 |
| Aloha | bzr push seems kind of an aggressive adjective heh | 07:57 |
| bob2 | "bzr politely-request-you-take-these-updates" | 07:58 |
| igc | night all | 07:59 |
| lifeless | bzr take-it-rough | 07:59 |
| mtaylor | bzr be-my-bitch | 07:59 |
| * mtaylor wants to make a bzr-plugin that provides dirty aliases for all the builtins | 08:00 | |
| TFKyle | that shouldn't be too hard to do | 08:00 |
| mtaylor | thinks it would take all of 20 minutes to write | 08:00 |
| lifeless | mtaylor: https://launchpad.net/bzr-cheap-taiwanese" | 08:00 |
| lifeless | ? | 08:00 |
| mtaylor | mostly just from the time spent copying and pasting stuff | 08:00 |
| lifeless | mtaylor: its python; do it on the gly | 08:00 |
| lifeless | *fly* | 08:00 |
| igc | no plugin required - just use aliases :-) | 08:01 |
| mtaylor | lifeless: sure... but I have to actually type in the names of commands and the aliases for them | 08:01 |
| TFKyle | hmm, monkeypatch stuff so the old commands don't work anymore :P | 08:01 |
| bob2 | not sure that would be coc-compliant! | 08:01 |
| Odd_Bloke | TFKyle: As regards deleting PPA packages, I thought I saw something in the most recent LP release notes about now being able to do that. | 08:03 |
| Odd_Bloke | I don't use PPAs myself, so I don't actually know that this is the case. :p | 08:03 |
| TFKyle | I think they've added the capability to the backend, but nothing in the frontend, though i havn't looked for a few weeks | 08:04 |
| poolie | thumper just posted an alias plugin, like in the shell | 08:04 |
| TFKyle | s/frontend/ui/ | 08:04 |
| poolie | yes, it was just annouce | 08:04 |
| TFKyle | ah, it is there, cool | 08:05 |
| * thumper should email the patch to the list | 08:13 | |
| === doko_ is now known as doko | ||
| bronson | Can anyone point me to docs on how to maintain an integration branch in bzr? | 08:36 |
| bronson | I have a few upstream svn branches that I'd like to occasionally import into different directories in my bzr tree. | 08:36 |
| bronson | No need to keep full svn history in bzr; I just need to pull down the releases every month, mash them together, and build a single app out of them. | 08:37 |
| bronson | Can bzr do this? | 08:37 |
| Odd_Bloke | bronson: Do you need to keep the different upstream versions in your version control at all? | 08:39 |
| bronson | Odd_Bloke: yes, because I need to be able to tweak them and bring my patches forward. | 08:40 |
| bob2 | that's what bzr-load-dirs was for | 08:40 |
| bob2 | I think bzr import does the same thing | 08:40 |
| bronson | bob2: bzr svn-import? | 08:40 |
| bronson | Doesn't that create an entire repository? | 08:41 |
| bob2 | no, "bzr import" | 08:41 |
| bronson | bzr: ERROR: unknown command "import" | 08:41 |
| bronson | Do I need 1.1? | 08:41 |
| bronson | I'm on 1.0. | 08:41 |
| bob2 | hm, maybe | 08:41 |
| bob2 | it doesn't do what I thought it does, though, so never mind | 08:42 |
| Odd_Bloke | 'bzr import' is part of bzrtools. | 08:42 |
| bob2 | ah, ok | 08:43 |
| bob2 | https://lists.ubuntu.com/archives/bazaar/2006q2/012039.html is how to do it | 08:43 |
| bob2 | shame no one has automated it yet | 08:43 |
| Odd_Bloke | http://paste.pocoo.org/show/24401/ is the help for it. | 08:43 |
| bronson | Ick, that's a lot of manual labor. | 08:44 |
| bronson | Guess I'll have to keep using svn/piston. :( | 08:45 |
| bronson | How would I do this in bzr if svn wasn't a part of the picture? | 08:47 |
| bronson | Let's say libst and libtu were maintained as bzr branches... I'd like to include them directly in my app. | 08:48 |
| bronson | Is there an easy way to import upstream libst into a local/libst in my app's repo, then pull changes using regular bzr commands? | 08:49 |
| bob2 | config-manager | 08:49 |
| bronson | Hm, interesting. | 08:50 |
| bronson | I'll have to play with it. | 08:50 |
| Odd_Bloke | bronson: You could have a bzr branch for your stuff, which contains other bzr branches. | 08:50 |
| Odd_Bloke | But this wouldn't ensure that the revisions of the sub-branches would be the same everywhere. | 08:51 |
| bronson | But reading the docs, config-manager has an icky, tla sort of feel to it... | 08:51 |
| bronson | I could be wrong. | 08:51 |
| bob2 | haha | 08:51 |
| bob2 | it may perhaps date from that era | 08:51 |
| Odd_Bloke | bronson: Posting to the list might help you out, as you'd be able to describe the scenario in more detail and more eyes will see it. | 08:52 |
| bronson | True. I was hoping this was an easy question. | 08:52 |
| bronson | Guess not. Oh well. | 08:53 |
| bronson | I'll hit the list if I can't find easily another vcs that will do it. | 08:53 |
| bronson | Thanks for your help. | 08:53 |
| Odd_Bloke | bronson: No worries. | 08:54 |
| poolie | bronson, this is handled by the subtree feature | 08:56 |
| bronson | poolie: that sounds promising. | 08:56 |
| poolie | please post to the list and someone can give you a pointer | 08:56 |
| Aloha | how do you create release tarball with bzr? | 09:36 |
| === kiko-zzz is now known as kiko | ||
| Kinnison | Aloha: bzr export foo-1.0.tar.bz2 /path/too/foobranch | 10:03 |
| Kinnison | Aloha: is one option | 10:03 |
| Kinnison | Aloha: personally I use autoconf and automake and do 'make dist' :-) | 10:03 |
| Aloha | i don't have those though. my program is Ruby | 10:04 |
| Kinnison | does ruby not have some kind of distribution maker? | 10:06 |
| Aloha | Kinnison, maybe i'm not sure | 10:07 |
| Kinnison | python has distutils | 10:07 |
| Kinnison | perl has Makemaker | 10:07 |
| Kinnison | I'm sure ruby must have something | 10:07 |
| mtaylor | ruby has makemaker | 10:07 |
| Aloha | i'm asking in #ruby-lang | 10:07 |
| asabil | I think it is rake | 10:17 |
| asabil | Aloha: ruby has rake iirc | 10:18 |
| Debolaz | Makemaker is ugly. :( | 10:22 |
| deepjoy | Hi I notice that the bazaar website is not updated very frequently. is there anywhere else that the current developments are captured? | 10:23 |
| deepjoy | I'd like to volunteer time to help distribute this information if that would help? | 10:24 |
| zurgutt | Hi folks, im new to bzr. Im wondering if several branches can be created under one main working directory, each containing number of not overlapping subdirs? | 10:24 |
| bob2 | zurgutt: no (if I understand you correctly - several branches, not containign any files or dirs with the same name, checked out in the same directory) | 10:25 |
| zurgutt | essentially groups of subdirs belong to separate projects and id like to be able to work with one group as unit, commit it etc | 10:26 |
| Odd_Bloke | deepjoy: Most of the development work takes place on the mailing list, as well as in the bug and specification management parts of Launchpad. | 10:27 |
| bob2 | it'd be neat if someone was willing to do a weekly "bzr traffic" news thing | 10:27 |
| zurgutt | one solution offered was to symlink those groups of dirs under separate workspace dirs elsewhere and there create branch for each. Im just trying to make sure im not missing any simpler way of doing this, named branches or whatnot :) | 10:30 |
| deepjoy | odd_bloke: cool I'll subscribe to the mailing list and try doing that for a few weeks | 10:35 |
| deepjoy | I think a non-python/bzr intricacy level information is required for popular uptake | 10:36 |
| Odd_Bloke | What sort of stuff would you expect to see in the news thing? | 10:37 |
| bob2 | new formats and their level of experimentalness, that changes at least once a week | 10:37 |
| deepjoy | feature dissection from a layman's perspective. e,g, "bzr+http needs verb addition" translates to "bzr over http performance improvements" | 10:38 |
| deepjoy | does that make sense? | 10:39 |
| Odd_Bloke | How useful would that be on a week-by-week basis? It seems more likely that something of this ilk when a new release happens might be more effective/useful... | 10:40 |
| deepjoy | thats why I though the website was a better place to put such information | 10:41 |
| Odd_Bloke | I dunno, I think it's too transient to go on the website. | 10:45 |
| Odd_Bloke | Perhaps a blog post talking about a new version (i.e. paraphrasing the interesting parts of the NEWS file) might work. | 10:45 |
| Aloha | how do you install branch into current directory without creatingnew directory? | 10:47 |
| Aloha | how do you install branch into current directory without creating a new directory? | 10:48 |
| Aloha | like if i wanted to do bzr branch http://bazaar.launchpad.net/~tjgillies/shakabuntu-surf/devel <current directory> | 10:48 |
| bob2 | "bzr co http://blah/ ." works, while branch does not | 10:49 |
| bob2 | so you could co, then "bzr reconfigure" it to a branch | 10:49 |
| ubotu | New bug: #186975 in bzr "cannot rename files to names with slashes" [Undecided,New] https://launchpad.net/bugs/186975 | 10:50 |
| Aloha | i push a checkout back to devel or does it need to be a branch? | 10:51 |
| Aloha | i'm trying to have an upstream working directory and a package working directory and i'm trying to sync their files | 10:51 |
| Aloha | because i'm upstream and maintainer | 10:52 |
| === weigon_ is now known as weigon | ||
| ubotu | New bug: #187008 in bzr-svn "bzr-svn try to use too long knit name incompatible with Windows filesystem" [Undecided,New] https://launchpad.net/bugs/187008 | 11:40 |
| gmb | Is it possible to specify a port when performing a bzr operation over sftp? | 11:48 |
| dato | gmb: have you tried sftp://host.com:4444/path ? | 11:48 |
| gmb | dato: I've tried it, but there is much sitting there and doing nothing going on :/ | 11:49 |
| lifeless | it should work | 11:49 |
| gmb | Hmm. | 11:49 |
| lifeless | tcpdump for the win | 11:49 |
| gmb | Ah. | 11:49 |
| gmb | No, wait, my balls up. | 11:49 |
| gmb | It might be working now... the fact that my connection has slowed to a crawl suggests so... | 11:50 |
| gmb | Thanks. | 11:50 |
| lifeless | :) | 11:54 |
| bialix | jelmer: hi | 12:29 |
| jelmer | bialix: Hey | 12:29 |
| bialix | I'm playing with bzr-svn and I'm stuck | 12:30 |
| bialix | C:\work\Temp\scmrtos.repo>bzr branch svn+http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/trunk/ | 12:30 |
| bialix | bzr: ERROR: /trunk is not a valid Subversion branch path. | 12:30 |
| bialix | See 'bzr help svn-branching-schemes' for details. | 12:30 |
| jelmer | try removing subversion.conf and try again | 12:31 |
| jelmer | appears to work fine here so far | 12:31 |
| jelmer | subversion.conf in the bazaar config directory, not sure where that is on Windows, but I'm sure you do :-) | 12:35 |
| bialix | it's strange because bzr branch svn+http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/ works fine | 12:40 |
| jelmer | that's because that's probably the first url you tried | 12:40 |
| bialix | but it ends with branch containing trunk, branches, tags subdirs | 12:40 |
| jelmer | bialix: if you remove subversion.conf, you should be able branch /trunk again | 12:41 |
| bialix | also I have similar problems with trac-hacks.org svn repo | 12:41 |
| jelmer | branching scrmtrtos trunk works fine here | 12:42 |
| bialix | yeah, after deleting subversion.conf it does | 12:44 |
| bialix | jelmer: overall it seems that bzr-svn standalone installer verison works fine | 12:44 |
| jelmer | bialix: cool | 12:45 |
| jelmer | bialix: does the test suite run ok? | 12:45 |
| bialix | I just don't understand all limitations of svn support | 12:45 |
| bialix | I don't run it | 12:45 |
| bialix | yet | 12:45 |
| jelmer | I would be interested in seeing the output when you get around to that :-) | 12:49 |
| bialix | test suite output? | 12:49 |
| jelmer | yeah | 12:50 |
| jelmer | I suspect there will be at least some failures | 12:50 |
| bialix_ | jelmer: when I try to branch another branch from scmrtos svn repo I get the same error. | 13:01 |
| bialix_ | again delete subversion.conf? | 13:02 |
| bialix_ | something really weird going on here, IMO | 13:02 |
| jelmer | bialix: what path are you trying to branch exactly? | 13:02 |
| bialix_ | um, wait | 13:05 |
| bialix_ | no, sorry, operator error | 13:06 |
| bialix_ | now it works fine | 13:06 |
| bialix_ | does bzr-svn allows to create new branches in svn repo? | 13:07 |
| jelmer | yes, using the "svn-push" command | 13:08 |
| bialix_ | tags is used as branches or they mapped to bzr tags? | 13:10 |
| jelmer | tags are used as branches for now | 13:14 |
| === bialix__ is now known as bialix | ||
| bialix | jelmer: one more question please. do I need bzr-svn plugin installed all the time to work with branched svn trunk? | 13:21 |
| jelmer | bialix: no, not at all | 13:21 |
| jelmer | only when interacting with svn | 13:21 |
| bialix | ah, ok, cool | 13:22 |
| jelmer | (pulling/merging from svn or pushing to svn) | 13:22 |
| bialix | indeed cool | 13:22 |
| ubotu | New bug: #187037 in bzr-gtk "gpush fails with unsupported operand type(s) for /: 'float' and 'NoneType'" [Undecided,New] https://launchpad.net/bugs/187037 | 13:25 |
| vila | abentley: ping | 13:43 |
| abentley | vila: pong | 13:43 |
| bialix | vila: bonjour | 13:44 |
| vila | I'm working on bug #123363 and TransformPreview always leaves garbage in /tmp | 13:44 |
| ubotu | Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363 | 13:44 |
| vila | bialix: hi :) | 13:44 |
| bialix | comme ca va? | 13:44 |
| vila | the trick is that we can't call finalize() because no lock is held | 13:44 |
| vila | bialix: bien, merci :) | 13:45 |
| abentley | vila: I don't follow. | 13:45 |
| vila | ok, TransformPreview.__init__ does limbodir = tempfile.mkdtemp(prefix='bzr-limbo-') | 13:45 |
| vila | but never deletes it | 13:45 |
| vila | note that *I* added prefix='bzr-limbo-' to ease tracking the leaks | 13:46 |
| abentley | Why isn't there a lock on _tree? | 13:46 |
| vila | you tell me :) | 13:46 |
| vila | none of the tests in test_transform.py use locks | 13:47 |
| vila | as I'm not familiar with the code I'm not sure TransformPreview.__init__ should take a read_lock on _tree | 13:47 |
| abentley | I think it wouldn't hurt. | 13:48 |
| abentley | vila: The tests don't use locks, but TreeTransform had always taken out locks for itself. | 13:48 |
| abentley | I'd recommend taking out a read lock on _tree. Does that suit you? | 13:49 |
| vila | I'll give it a try but I came across the problem with no previous knowledge on TransformPreview, so I trust you :) | 13:50 |
| === mw|out is now known as mw | ||
| vila | abentley: that worked | 14:58 |
| abentley | Great. | 14:58 |
| abentley | Sorry about leaving refuse behind :-) | 14:58 |
| van_hack_ | hi, can anyone help me move an existing bzr repo to a central server? the docs assume I'm starting from cvs | 15:20 |
| luks | van_hack_: bzr push? | 15:21 |
| van_hack_ | luks: does the remote branch already have to exist for that to work? | 15:23 |
| luks | no | 15:23 |
| * van_hack_ tries it | 15:24 | |
| van_hack_ | luks: seems to be working, slowly. thx | 15:36 |
| === kiko is now known as kiko-fud | ||
| fjalar | hi all.. I set up a central repository (lock-step) but I am getting all sorts of permissions issues when 2 users try to commit or access files | 16:14 |
| fjalar | it write the file with that user's name and their own group by default | 16:14 |
| fjalar | and then the other user can't get to it.. is there a way to fix? | 16:14 |
| === kiko-fud is now known as kiko | ||
| schierbeck | fjalar: you're using sftp, right? | 16:17 |
| fjalar | yes | 16:17 |
| schierbeck | that's it | 16:17 |
| schierbeck | it fucks things up | 16:17 |
| schierbeck | try using bzr-ssh | 16:17 |
| fjalar | ahhh | 16:18 |
| fjalar | is it bzr checkout bzr-ssh://user@host:port/repos/...? | 16:18 |
| radix | you can definitely use bzr reasonably with multiple users even if you use sftp. Make sure the shared repo and everything under it is g+rwXs | 16:19 |
| radix | fjalar: bzr+ssh | 16:19 |
| fjalar | ahh so kinda like svn+ssh for svn | 16:19 |
| fjalar | ok | 16:20 |
| radix | right. | 16:20 |
| schierbeck | radix: i thought that didn't work with the sftp plugin? | 16:20 |
| schierbeck | perhaps it's been resolved | 16:20 |
| radix | schierbeck: it's not really a problem with the bzr sftp plugin. | 16:20 |
| schierbeck | okay | 16:20 |
| radix | it's just unix permission semantics. | 16:20 |
| schierbeck | i'm off then :) | 16:20 |
| radix | take it easy! | 16:20 |
| ubotu | New bug: #163858 in bzr "bzr-svn cannot check out lintian repository" [Medium,Triaged] https://launchpad.net/bugs/163858 | 16:20 |
| fjalar | does bzr save strange unix permissions of the files being checked in.. themselves? | 16:23 |
| fjalar | I noticed checking out a file just gave it 755 permissions | 16:24 |
| jelmer | fjalar: bzr doesn't track file permissions | 16:24 |
| jelmer | except for the executable bit | 16:24 |
| fjalar | so there's no metadata telling it what permissions to use.. like tar uses? | 16:24 |
| fjalar | hmm. maybe I'm better off with rsync, but I need the versioning control.. :-/ | 16:33 |
| jelmer | you may want to use metastore | 16:38 |
| jelmer | which allows writing the metadata to a file | 16:38 |
| fjalar | is that a bzr plugin? | 16:39 |
| jelmer | no, it's a standalone app | 16:40 |
| fjalar | oh I see :) | 16:41 |
| jelmer | it should be trivial to write a plugin once bug 185772 is fixed | 16:41 |
| ubotu | Launchpad bug 185772 in bzr "Ability to set two authors for a commit" [Wishlist,Triaged] https://launchpad.net/bugs/185772 | 16:41 |
| jelmer | uhm | 16:41 |
| jelmer | I mean bug 186422 | 16:41 |
| ubotu | Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged] https://launchpad.net/bugs/186422 | 16:41 |
| fjalar | where can I find metastore? google search is useless. | 16:41 |
| jelmer | http://david.hardeman.nu/software.php | 16:42 |
| fjalar | it looks like a git thing | 16:42 |
| fjalar | ahh thanks | 16:42 |
| jelmer | it's vcs-independent | 16:42 |
| fjalar | cool! this looks perfect. Thanks! | 16:43 |
| fjalar | ahh.. Joey Hess has worked on metastore. I know he's checked his $HOME into a concurrent versioning system before... :D | 16:46 |
| fullermd | radix: No, it's a problem with sftp because the sftp server strips g+s, so new directories get made with the wrong perms. | 16:49 |
| radix | oh. I guess that's openssh's sftp server's fault? | 16:49 |
| fullermd | Yah. | 16:49 |
| fullermd | (I dunno if it's just openssh, or all sftp servers, but... does anybody use anything but openssh's? ;) | 16:49 |
| schierbeck | i knew i remembered correctly! | 16:50 |
| schierbeck | boo-yaa! | 16:50 |
| schierbeck | :) | 16:50 |
| fullermd | Sadly, you're only allotted one correct remambrance a week... | 16:50 |
| schierbeck | yup :( | 16:50 |
| schierbeck | still, totally worth it | 16:51 |
| === hexmode` is now known as hexmode | ||
| vila | abentley: thanks for the quick notice (still laughing) | 17:09 |
| abentley | hehe. | 17:10 |
| CardinalFang | Hi all. If you merge from a bundle and don't commit, and then add stuff, can you unmerge the merge cleanly and still keep your changes? Perhaps "bzr diff > x; bzr revert; patch <x; patch -R bundle" ? Is that the best way? | 17:11 |
| abentley | CardinalFang: Is this actually a merge directive that contains a bundle? | 17:17 |
| CardinalFang | Yes. | 17:19 |
| abentley | Okay, so the merge directive lists the revision ids that were used. | 17:20 |
| abentley | So you should be able to do bzr merge -r revision_id..base_revision_id | 17:21 |
| abentley | But I'd make a copy and do it on that. | 17:21 |
| CardinalFang | abentley, Won't that add a new changeset that is the reverse? I thought that wouldn't expunge the difference. | 17:23 |
| abentley | I don't know what you mean by "add a new changeset". Bazaar doesn't have a concept of changesets. This is just a cleaner way of changing the contents of your tree than using patch. | 17:24 |
| CardinalFang | Sorry, s/changeset/revision/ | 17:25 |
| CardinalFang | Ah, "bzr revert --forget-merges"? | 17:40 |
| ubotu | New bug: #187106 in bzr "bzr from standalone installer has poor performance on Vista" [Undecided,New] https://launchpad.net/bugs/187106 | 18:01 |
| rcohen | is there documentation on the knit file format? | 18:18 |
| abentley | rcohen: There is a fair amount of documentation in http://bazaar-vcs.org/bzr/bzr.dev/bzrlib/knit.py but it isn't very polished. | 18:38 |
| rcohen | maybe you could answer this without me digging | 18:39 |
| abentley | Try me. | 18:39 |
| rcohen | does the knit format allow regenerating a particular version without having to read from the beginning? | 18:39 |
| abentley | Yes. | 18:40 |
| rcohen | does it do this in a way similar to hgs revlogs? | 18:40 |
| abentley | Knits store snapshots, and they have index files. So you can read the snapshot, then apply a few patches. | 18:40 |
| abentley | I don't know much about revlogs. | 18:40 |
| rcohen | revlogs do basically that | 18:40 |
| rcohen | and the knit is used to determine line ancestry? | 18:41 |
| abentley | The knit stores an ancestry graph for its particular file. | 18:42 |
| rcohen | and does the index tell you how many patches it takes to get from one snapshot to the next? | 18:42 |
| rcohen | check that, you probably can get that from the ancestry graph | 18:42 |
| LeoNerd | It's not patch based | 18:42 |
| abentley | Technically, yes, but why would it matter? | 18:42 |
| rcohen | you can optimize merge algorithms using that information | 18:43 |
| abentley | LeoNerd: It doesn't use unified diffs, but it does have its own patch format. | 18:43 |
| rcohen | sometimes it may require sacrificing some accuracy, but if you can start from a snapshot of a common ancestor it "shouldn't" | 18:44 |
| rcohen | minus resolution errors | 18:44 |
| abentley | rcohen: You're aware that we no longer use knits as our default format, right? | 18:45 |
| rcohen | i saw something about that, but the knit weave is still there as an option | 18:45 |
| rcohen | and sounded like at least some people think it should be the default | 18:46 |
| abentley | I think you've got something confused. | 18:46 |
| rcohen | very likely | 18:46 |
| rcohen | :) | 18:46 |
| abentley | "knit merge" is an algorithm that uses annotation information to perform a merge. | 18:47 |
| rcohen | sorry, yes, i meant "knit merge", not weave | 18:47 |
| rcohen | is the knit merge working on top of the current pack-like format? | 18:48 |
| abentley | The pack formats don't include annotation information. That makes the original knit merge too expensive to perform. | 18:49 |
| rcohen | ah, what were the advantages to switching off of the knit format? | 18:49 |
| abentley | Speed, speed, write-once operation, lockless operation. | 18:50 |
| abentley | I've written a revised knit merge that determines whether lines are new based on sequence-matching the uncommon ancestors. | 18:51 |
| abentley | Even that is pretty slow. | 18:51 |
| rcohen | not surprising | 18:52 |
| abentley | So I've written LCA merge. | 18:52 |
| abentley | Which I think would be a good default. | 18:52 |
| rcohen | it looked like it behaves like 3-way in many cases | 18:53 |
| rcohen | which is fairly crude as far as history awareness goes | 18:53 |
| rcohen | and can go horribly wrong if you don't choose your ancestor carefully | 18:54 |
| abentley | LCA merge doesn't have "an ancestor". | 18:54 |
| abentley | It uses all the LCAs. | 18:55 |
| abentley | So it doesn't suffer the problems 3-way has with criss-cross. | 18:55 |
| rcohen | that comes at the expense of not using any ancestors for the initial matchup between the 2 sides to be merged | 18:56 |
| rcohen | which can introduce its own problems | 18:56 |
| abentley | There's some truth to that, but I think it's a very practical approach. | 18:57 |
| abentley | Knit merge doesn't use ancestry information for the initial matchup either. | 18:58 |
| rcohen | i know, cdv merge doesn't either | 18:58 |
| rcohen | it can cause problems :) | 18:58 |
| rcohen | i honestly don't know what that will do in lca merge | 18:59 |
| rcohen | would have to think about it | 18:59 |
| rcohen | but i get nervous about weakening what 3-way merge does | 19:00 |
| rcohen | also, 3-way and lca don't have the convergence property which i've become fond of | 19:00 |
| rcohen | but to do that right you really need to be able to get at full history information quickly | 19:01 |
| Skfarek | hi | 19:01 |
| abentley | rcohen: In what sense is that weakening what 3-way does? | 19:02 |
| rcohen | 3-way always sounds simple, but the devil is in the details | 19:02 |
| rcohen | i believe you would normally match against the ancestor, not directly between the 2 sides | 19:03 |
| rcohen | actually, i would have to defer to the monotone folks on that, because they have put a lot of energy into tightening up their implementation | 19:04 |
| abentley | In 3-way, after you've matched against base, you typically match against the 2 sides, to avoid conflicts in the ABA case. | 19:05 |
| rcohen | matching against base gives you some concept of line ancestry | 19:06 |
| rcohen | only doing a direct match loses that information and can result in incorrect matches | 19:07 |
| abentley | True, but matching against base can also cause incorrect matches. | 19:07 |
| Skfarek | guys, how can i contact with anyone from summer of code/bazaar ? | 19:07 |
| abentley | It's really six of one, half a dozen of the other. | 19:07 |
| rcohen | yes, well, i never said 3-way was truly history aware | 19:08 |
| rcohen | in general, i believe that matching against base will give better results | 19:08 |
| rcohen | resolution errors are always possible (unless you hook into the editor, though i would dispute even that) the point is to minimize them | 19:10 |
| abentley | Skfarek: I have no idea who's organizing that. | 19:11 |
| jelmer | Skfarek: is the SoC already on for this year? | 19:11 |
| abentley | Skfarek: you could just send a message to Martin Pool or the mailinglist. | 19:11 |
| abentley | rcohen: Well, I see now what you meant, and I don't think it's a significant problem. | 19:12 |
| abentley | Patience sequence matching does a great job of resolution. | 19:12 |
| rcohen | i know, but cdv has been using that for a while and it still comes up | 19:13 |
| mtaylor | if I do branch._get_base() | 19:13 |
| mtaylor | that gives it to me in url form | 19:13 |
| mtaylor | is there any decent/simple way to get it in filesystempath form | 19:13 |
| mtaylor | (ConfigObj doesn't seem to like urls) | 19:13 |
| abentley | mtaylor: We use URLs all over the place in our config files. | 19:14 |
| Skfarek | jelmer: not yet | 19:14 |
| mtaylor | abentley: yes... but do you use them to instantiate a ConfigObj? | 19:14 |
| Skfarek | abentley: thx | 19:14 |
| mtaylor | abentley: c=ConfigObj(os.path.join('file:///home/mtaylor/src/bzr-plugins/trunk/','.bzr-mysql','default.conf')) | 19:14 |
| mtaylor | isn't so much happy | 19:15 |
| abentley | mtaylor: No. We retrieve the file, then instantiate ConfigObj with it. | 19:15 |
| mtaylor | ah | 19:15 |
| rcohen | i wonder if it's possible to generate a minimal knit on demand and cache it for merge purposes | 19:15 |
| abentley | mtaylor: if you're using a Branch, you'd better be using transports to access its data. | 19:17 |
| mtaylor | abentley: it actually should be WorkingTree rather than Branch, now that you mention it | 19:17 |
| abentley | mtaylor: Does this plugin's configuration change according to the working tree? | 19:19 |
| mtaylor | abentley: yes. or it could | 19:19 |
| abentley | rcohen: Knit merge is a misnomer. It just needs annotations, and we're planning to restore fast annotation support in a future pack format. | 19:20 |
| rcohen | ah, excellent | 19:20 |
| mtaylor | abentley: the one bit it a PluginBranchConfig class based on something similar from bzr-builddeb which allows you to put versioned config info into the branch itself, hopefully in a "safe" manner | 19:20 |
| mtaylor | abentley: so that I can have a version of bzr-email that reads the commit-to address from the branch rather than from local config files | 19:21 |
| abentley | rcohen: That said, I've found LCA merge gives better results than knit merge. | 19:21 |
| abentley | I don't really get it, but I need to get some actual work done. | 19:22 |
| rcohen | alright, thanks for indulging me | 19:22 |
| abentley | rcohen: BTW, you asked about documenttion of knits. But if it was knit merge you were after, there's a description here: http://bazaar-vcs.org/KnitMerge | 19:40 |
| rcohen | already saw the knit merge description | 19:41 |
| rcohen | i'm actually in favor of full weaves (or equivalent full history information) not just file annotations, but don't let me drag you back into a discussion if you have work to do | 19:42 |
| awmcclain | Is branching significantly faster over the smart server than http or ssh? | 19:46 |
| dato | awmcclain: over bzr+ssh you're already using the smart server (not over sftp://, though) | 19:47 |
| awmcclain | Okee doke. In a workflow where there's a monolithic mainline, do people usually keep an updated local clone of the mainline and then make branches from that? | 19:48 |
| awmcclain | I'm just curious because our repository (~150 MB, ~460 revs) takes > 3 minutes to download and I'm trying to sell bzr to my team. | 19:50 |
| luks | awmcclain: yes, branching from a local mirror of the mainline is probably the most common approach | 19:50 |
| luks | you usually use a shared repository, so you store/download those 150MB only once for all branches | 19:51 |
| awmcclain | Right. If you branch from the local mirror, you have to make sure the mirror is at tip, right? | 19:52 |
| fullermd | Well, not _necessarily_. | 19:52 |
| awmcclain | So workflow for making a new feature would be update local mirror -> branch local mirror | 19:52 |
| luks | you don't really have to | 19:52 |
| awmcclain | Or does it get handled automatically? | 19:53 |
| luks | but it's nicer to work against the current mainline | 19:53 |
| awmcclain | Oh, right, you could branch on your old version, but then you'd have more possible merges | 19:53 |
| abentley | rcohen: For merging purposes, full weaves are great. But we couldn't get decent performance out of them, and there were also safety concerns because the weave is constantly being rewritten. | 19:53 |
| luks | some people prefer to use checkouts for the mainline | 19:53 |
| awmcclain | luks: Sounds like svn to me... how are "checkouts" different than "branches"? | 19:54 |
| luks | they are "bound" to a remote branch | 19:54 |
| luks | and it the checkout is out of date, it will complain when you try to commit to it | 19:55 |
| luks | so you know that you have to update | 19:55 |
| luks | s/and it/and if/ | 19:55 |
| awmcclain | luks: So you "checkout" a local working copy from a remote server? | 19:55 |
| luks | more or less | 19:55 |
| awmcclain | But then you lose the benefit of having a local feature branch, right? | 19:56 |
| luks | no | 19:56 |
| abentley | rcohen: I did come up with an append-only format that represented weaves: http://www.aaronbentley.com/weavediff | 19:56 |
| * awmcclain scratches his head | 19:57 | |
| Odd_Bloke | awmcclain: A local branch created using 'bzr branch' will work fine, so don't worry too much about the alternatives. :) | 19:58 |
| awmcclain | Maybe it's better if I describe what I'm looking for... I want each developer to be able to make local branches very quickly (w/o having to wait 3 minutes for the repo to dl) | 19:59 |
| luks | awmcclain: you get that with almost every possible configuration | 20:01 |
| fullermd | awmcclain: I work that way. I have a local checkout of the trunk, that I work directly in for trivial stuff. And I branch off it for larger stuff, which I then merge in/commit. | 20:01 |
| luks | the only exception would be "lightweight checkout", but you don't have to worry about that | 20:01 |
| Odd_Bloke | awmcclain: Do the developers have commit access to the primary branch? | 20:02 |
| awmcclain | Odd_Bloke: Yes. | 20:02 |
| awmcclain | But I must have set it up incorrectly, because *each* local new branch I make takes forever. | 20:03 |
| awmcclain | fullermd: That makes sense. | 20:03 |
| Odd_Bloke | awmcclain: You're, presumably, not using a shared repository. | 20:03 |
| awmcclain | I guess not. ;) | 20:03 |
| Odd_Bloke | "bzr init-repo foo && cd foo && bzr branch http://mainline/trunk" should do the trick. | 20:04 |
| awmcclain | And that's on the mainline server. | 20:04 |
| awmcclain | I'm assuming. | 20:05 |
| Odd_Bloke | Nope, that's locally. | 20:05 |
| awmcclain | Ah. | 20:05 |
| awmcclain | So how does the local repository keep up-to-date? | 20:06 |
| Odd_Bloke | bzr will find the repository at foo whenever you create a new branch, and use it instead of creating a standalone repo. | 20:06 |
| Odd_Bloke | awmcclain: bzr pull | 20:06 |
| Odd_Bloke | In foo/trunk | 20:06 |
| awmcclain | Ok. Perfect. So workflow would be (for, say, working on a new feature), bzr pull, then bzr branch foo-feature | 20:07 |
| awmcclain | Then you'd merge into your local repo | 20:07 |
| awmcclain | and push the changes to mainline? | 20:07 |
| Odd_Bloke | awmcclain: Starting in 'foo', 'cd trunk; bzr pull; cd ..; bzr branch feature-branch' would give you a shiny new up-to-date feature branch. | 20:08 |
| Odd_Bloke | awmcclain: Precisely. | 20:08 |
| Odd_Bloke | To clarify, your local 'trunk' branch. | 20:08 |
| Odd_Bloke | A repository, in bzr terms, is just a place where revisions are kept. | 20:08 |
| awmcclain | Ah, sorry. Still wrapping my head around non-svn terms. | 20:09 |
| Odd_Bloke | :) | 20:09 |
| fullermd | Or you could use a checkout, and update/commit instead of pull/push'ing the mainline changes. | 20:09 |
| fullermd | It's something of a wash, but I find the enforced lockstepping on trunk to be an advantage. | 20:10 |
| awmcclain | I'll take a look at that on the site. | 20:10 |
| Odd_Bloke | awmcclain: Another thing to note is that, when merging back to trunk, it makes sense to update trunk and then merge trunk into the feature branch, do any conflict resolution there (rather than in trunk) and then merge the ready-resolved feature branch into trunk. | 20:11 |
| * snod feels dizzy because he can't follow :) | 20:12 | |
| awmcclain | And bzr+ssh is the preferred method of pushing/pulling (updating/committing) from local trunk branch to mainline, right? I've found that serving the mainline using bzr:// gives me no status when doing branch on my local machine | 20:12 |
| awmcclain | Odd_Bloke: Right. That way you're not screwing around with trunk... all your merging happens in your feature-branch. | 20:13 |
| fullermd | I usually just merge into trunk. If it ends up getting a lot of conflicts, I can always 'revert' it and go off to do it in the branch. | 20:14 |
| Odd_Bloke | awmcclain: I don't have any experience with bzr:// so I'm not really the best person to help you out there. | 20:14 |
| Odd_Bloke | bzr+ssh:// will certainly do fine, assuming everyone has an SSH account. | 20:14 |
| * Odd_Bloke is about to disappear for a server reboot. | 20:15 | |
| Odd_Bloke | BBIAB | 20:15 |
| awmcclain | Thank you all for your help! | 20:15 |
| === hexmode` is now known as hexmode | ||
| sistpoty | Hi, I just tried to commit a single file back to LP using "bzr ci style.css", which however seemed to hang forever... known bug? (1.0-1) | 20:43 |
| james_w | hi sistpoty. | 20:44 |
| sistpoty | hi james_w | 20:44 |
| beuno | sistpoty, you still need to specify a message in your editor | 20:44 |
| james_w | I haven't heard of that. Are you using a checkout/bound branch? | 20:44 |
| beuno | does "bzr ci -m'Message' file.css" hang too? | 20:44 |
| sistpoty | beuno: no, the editor didn't even spawn... I also tried -v, but it didn't give any output :( | 20:44 |
| yacc | Me wonders if it's possible to specify commits with bzr interactivly like with darcs => commiting only part of the file change at once? | 20:45 |
| sistpoty | james_w: checkout, I can look at the exact command I used ;) | 20:45 |
| james_w | sistpoty: see if there is anything interesting at the end of ~/.bzr.log when it is hanging. | 20:46 |
| sistpoty | bzr co bzr+ssh://sistpoty@bazaar.launchpad.net/~revu-hackers/revu/trunk <- | 20:46 |
| james_w | yacc: no, but you can do something similar with the shelf plugin from bzrtools. | 20:46 |
| yacc | james_w: ? | 20:46 |
| sistpoty | james_w: wow, this is huge (with -v)... there is at least one traceback in there | 20:47 |
| james_w | sorry all, I've got to run. | 20:47 |
| james_w | hopefully someone else can help the two of you. | 20:47 |
| sistpoty | http://pastebin.ubuntu.com/3983/ | 20:48 |
| james_w | If not please post to the list, or hang around for an hour or three. | 20:48 |
| yacc | sistpoty: start by pasting it into rafb.net/paste | 20:48 |
| sistpoty | (there's much more in there...) | 20:48 |
| james_w | sistpoty: you don't have something silly set in $EDITOR or $BZR_EDITOR do you? | 20:48 |
| beuno | sistpoty, I've tried it here ant ir works fine either way | 20:48 |
| beuno | sistpoty, does "bzr ci -m'Message' file.css" hang too? | 20:49 |
| sistpoty | james_w: $EDITOR is vim | 20:49 |
| sistpoty | beuno: let me check | 20:49 |
| james_w | sistpoty: not too silly then. | 20:49 |
| james_w | bye all. | 20:49 |
| sistpoty | beuno: oh, false alarm... it does continue after some time... now I've got an editor | 20:49 |
| * beuno waves at james_w | 20:49 | |
| sistpoty | cya james_w | 20:49 |
| beuno | sistpoty, great then :D | 20:49 |
| sistpoty | heh :) | 20:50 |
| beuno | sistpoty, I would recommend bumping up to 1.1 if you can | 20:50 |
| Odd_Bloke | yacc: 'bzr (shelf|shelve|unshelve)' from bzrtools let's you temporarily remove hunks from your working tree, that might work for you. | 20:50 |
| beuno | less chance of hitting a bug ;) | 20:50 |
| sistpoty | beuno: once it's in hardy, sure :) | 20:50 |
| sistpoty | hehe | 20:50 |
| sistpoty | thanks for your help! | 20:51 |
| beuno | sistpoty, it is: https://edge.launchpad.net/~bzr/+archive | 20:51 |
| beuno | and you're welcome | 20:51 |
| yacc | Odd_Bloke: Well, I can live as is, I just wonder how well bzr handles merging compared to darcs or git? | 20:52 |
| bialix | evening | 20:53 |
| bialix | I'd like to talk about lazy_import | 20:53 |
| beuno | evening bialix | 20:54 |
| bialix | evening beuno | 20:55 |
| bialix | I want to use modulefinder.py to obtain dependencies graph for bzr plugins, but I'm stuck with our lazy_import hack | 20:58 |
| * bialix wonder who is the author of standard python library's modulefinder.py | 21:01 | |
| bialix | jelmer, are you here? | 21:01 |
| jelmer | bialix, hi | 21:01 |
| bialix | evening jelmer, I have selftest svn results | 21:02 |
| bialix | Ran 722 tests in 1764.281s | 21:02 |
| bialix | FAILED (failures=11, errors=63, known_failure_count=3) | 21:02 |
| bialix | 1 test skipped | 21:02 |
| bialix | I'll send the test.log | 21:03 |
| jelmer | bialix: thanks, that'd be useful | 21:03 |
| bialix | many tests are reported about 'Permission denied: unable to remove testing dir xxx'. Looks like someone don't bother to close files in testing dir | 21:04 |
| jelmer | yeah, we're probably not closing the repository | 21:05 |
| bialix | it's annoying to see this junk, but nothing realy bad here | 21:05 |
| bialix | sent | 21:07 |
| jelmer | thanks | 21:10 |
| jelmer | some of the other errors appear to be related to the executable bit and symlinks | 21:10 |
| bialix | executable bit is preserved inside inventory on win32, but disconnected from real fs | 21:13 |
| bialix | symlinks... I have win32symlinks plugin installed. what special support of symlinks bzr-svn needed? | 21:14 |
| jelmer | bialix: it doesn't need any special support | 21:15 |
| jelmer | it does some tests importing/pushing symlinks in svn | 21:15 |
| bialix | ups, sorry. I was thought that I have it installed, but in fact no. I repeat the test with this plugin | 21:15 |
| jelmer | thanks | 21:17 |
| jelmer | is there some other way I should be accessing the execable bit? | 21:18 |
| jelmer | WorkingTree.is_executable() seems to rely on self._inventory | 21:18 |
| jelmer | how do you change the executable bit on Windows? | 21:18 |
| bialix | I do this in x-bit plugin | 21:19 |
| bialix | I change executable bit directly in inventory | 21:19 |
| bialix | http://codebrowse.launchpad.net/~bialix/bzr-x-bit/trunk/annotate/bialix%40ukr.net-20070328093543-blbtmf3k7jp6bmsd?file_id=__init__.py-20060516204016-5be79f11e31f2cb7 | 21:21 |
| jelmer | ahh | 21:21 |
| bialix | inv_entry.executable | 21:21 |
| jelmer | I'll provide a custom implementation of _is_executable_from_path_and_stat_from_basis | 21:27 |
| durruti | Hi folks, bzr newbie question for you: is it possible to create a branch from a remote, commit some revisions locally, and not propagate those back to the parent branch? | 21:30 |
| bialix | yes | 21:31 |
| Odd_Bloke | durruti: Yes. :) | 21:31 |
| durruti | Cool | 21:31 |
| durruti | right now I use SVK for this, but push and pull are broken | 21:31 |
| durruti | I have to manually use “svk smerge’ and specify the base revision | 21:31 |
| durruti | such a pain, I want to try bzr in the hopes the “bzr push” will be all that’s needed | 21:32 |
| bialix | you need to push back to svn server? | 21:32 |
| durruti | yep | 21:33 |
| bialix | then you need bzr-svn plugin in addition to vanilla bzr | 21:33 |
| durruti | Actually I would rather switch the remote server to bzr, but yeah I’ll take it one step at a time | 21:34 |
| durruti | looking at the docs, I see there are two ways to accomplish keeping changes to one branch: “rebasing” and “bzr push” (with a prior “bzr merge”) | 21:35 |
| ubotu | New bug: #187162 in bzr "bzr diff -r submit: on subversion branch fails" [Undecided,New] https://launchpad.net/bugs/187162 | 21:35 |
| durruti | is that right? | 21:36 |
| * bialix don't quite understand question | 21:39 | |
| jelmer | bialix: I think I've fixed the executable bit | 21:44 |
| jelmer | bialix: Can you check? | 21:44 |
| bialix | maybe tomorrow | 21:44 |
| bialix | I'm going to bed | 21:44 |
| jelmer | ok | 21:45 |
| jelmer | g'night | 21:45 |
| bialix | jelmer: with win32symlinks plugin the results is: FAILED (failures=14, errors=60, known_failure_count=3) | 21:45 |
| bialix | I'll send you the log tomorrow. g'night | 21:46 |
| durruti | bialix: OK, imagine the following: A live website on a remote server. The website is a versioned in bzr. I wish to code features locally and offline, but I need to change config.php for my specific local server. I don’t want those changes to ever make it back to the remote server | 21:46 |
| durruti | d’oh... g’night then :D | 21:46 |
| jelmer | bialix: at least 20 more tests should be fixed by the commit I just did | 21:46 |
| bialix | nice | 21:46 |
| dlee | [3 | 22:11 |
| dlee | oops | 22:11 |
| ubotu | New bug: #187169 in bzr "Partial commit with mv and rm under it will royally hork up" [Undecided,New] https://launchpad.net/bugs/187169 | 22:15 |
| CardinalFang | "hork" is a fun word, you hosers. | 22:18 |
| fullermd | It's descriptive :P | 22:19 |
| === kiko is now known as kiko-fud | ||
| poolie | good morning | 22:50 |
| * fullermd waves at poolie. | 22:51 | |
| Verterok | hi poolie | 22:51 |
| beuno | hey poolie, thanks for solving the planet thingie :D | 22:52 |
| poolie | it's ok now? | 22:55 |
| poolie | that's good | 22:55 |
| lifeless | silly link outages | 22:55 |
| poolie | me too | 22:55 |
| poolie | also, i put hardy on my x61s and its network support seems a bit flakey | 22:55 |
| fullermd | Well, I broke dirstate, so my day's complete :) | 22:56 |
| poolie | yeah thanks for that | 22:56 |
| poolie | fullermd, feel free to triage them when filing bugs | 22:57 |
| poolie | and thanks for the repro script | 22:57 |
| fullermd | It was looking at me funny. I had to put it back in its place. | 22:57 |
| igc | morning | 22:57 |
| fullermd | I think it's actually 2 bugs; one the commit, and the other the [abc] ordering that messed up stat. | 22:57 |
| fullermd | But I couldn't easily separate them, so... | 22:57 |
| fullermd | Fixing the commit one will probably mask the stat one, so it may be best to work bottom-up in fixing :| | 22:59 |
| * fullermd should add a note along those lines while he's thinking of it. | 22:59 | |
| fullermd | Huh. 'reconfigure' doesn't have a mode to turn a branch standalone <-> repo? | 23:05 |
| fullermd | I thought I remembered that being added... | 23:05 |
| fullermd | I guess the mind is the first thing to... to... the first... I forget. | 23:06 |
| Peng | It was mentioned/suggested on the list recently. | 23:42 |
| CardinalFang | Should it be legal to have a push location on a remote host (via bzr+ssh) be a symlink to a valid location? | 23:50 |
| CardinalFang | ^location^directory | 23:50 |
| CardinalFang | Er, Should it be legal to have a push location on a remote host (via bzr+ssh) be a symlink to a valid directory? | 23:51 |
| CardinalFang | I'm trying to decide if this is a bug. | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!