[12:55] <lifeless> poolie_: ping
[01:01] <offray_> Hi all
[01:03] <offray_> I'm trying to use svn2bzr to convert a svn project to bazaar but I get two errors related with bzrlib: "ImportError: No module named bzrlib.branch" or "ImportError: No module named clone". I don't know how to deal with it. May be my version of bzrlib is not syncronized with svn2bzr, but I don't know which version is supposed to be. Any pointer to a solution?
[01:06] <AfC> offray_: I believe that the plugin called 'bzr-svn' is the solution recommended by the Bazaar hackers; you might try that
[01:08] <cory> Is there any variant on commit that doesn't actually touch the working tree?
[01:08] <cory> Er, revert.
[01:08] <poolie_> lifeless, hi
[01:10] <Odd_Bloke> cory: Look at 'uncommit'.
[01:11] <offray_> AfC: Thanks. I will try, but it says that you can put bzr code in svn, but not convert from svn to bazaar. I will read mode
[01:12] <cory> Odd_Bloke: I spoke poorly.  For instance, the working tree might know that I have moved a => b.  I want it to forget that so that I can, say, add b and remove a instead.
[01:12] <cory> add b and remove a, that would be.  Maybe I should stop talking. :P
[01:13] <cory> I don't want to do anything with already committed revisions, like uncommit does.
[01:13] <Odd_Bloke> cory: Why doesn't revert do what you want?
[01:13] <offray_> umm... there is a svn-import wich seems to make the same that svn2bzr
[01:13] <cory> Because revert will move the file back.
[01:13] <cory> I happen to need it to not do that.
[01:14] <poolie_> cory, do you mean revert --keep?
[01:14] <poolie_> i mean, remove --keep
[01:14] <cory> I think revert --keep is what I want. ;)
[01:15] <poolie_> cory, you could file a bug asking for that
[01:16] <fullermd> Wouldn't rm/add do that?
[01:16] <cory> Or even unexposed api that I could use.
[01:16] <cory> Only if there's a bzr add --even-if-it-doesn't-exist
[01:17] <fullermd> Huh?
[01:17] <fullermd> Why would you want to add a file that didn't exist (and what would that even mean?)?
[01:17] <cory> I want it to forget that I told it to move it, not to add it!
[01:18] <cory> This is me fighting with perforce, really.
[01:18] <poolie_> cory, so in this particular case
[01:18] <poolie_> why not just do a reverse mv
[01:18] <fullermd> OK, you're losing me...  I thought you had the case "moved a to b", and wanted to change that to the case "rm'd a and added b".
[01:18] <lifeless> poolie_: what time should I pop over ?
[01:19] <poolie_> any time
[01:19] <lifeless> ok
[01:19] <poolie_> are you trying to call?
[01:19] <lifeless> I'll head over shortly
[01:19] <poolie_> i can't hear anything when i pick up
[01:19] <poolie_> do you want to meet spivvo on the way?
[01:19] <lifeless> I did try
[01:20] <lifeless> it went to your voice mail both times
[01:20] <lifeless> try ringing yourself perhaps. Is the spivster up ?
[01:20] <lifeless> cory: there is a bzrlib api to add a file regardless of physical presence
[01:21] <lifeless> cory: tree.add([paths] , [ids] , [kinds] )
[01:22] <lifeless> spiv: I'll be on the 10:30 from hornsby again
[01:23] <cory> Oh, I have another issue...the smart server seems to like leaving locks around. :/
[01:25] <igc> morning all
[01:27] <poolie_> cory, if you abort the operation, or even when it succeeds?
[01:27] <poolie_> igc, hi
[01:27] <igc> hi poolie_
[01:27] <cory> poolie_: From aborted operations, yes.  I expected the server instance would clean up after itself after it loses its connection.
[01:29] <cory> Running it through inetd...maybe it's terminated before it gets the chance.
[01:31] <lifeless> bbiab
[01:32] <AfC> cory: any reason you chose not to run it as a daemon full time?
[01:32] <cory> AfC: No special reason.
[01:33] <AfC> cory: (but I note that bzr+ssh := run a `bzr --serve` for one time use and seems to manage to last long enough to clean up after itself)
[01:55] <cory> Doh, I'm getting sigpiped.
[01:55] <fullermd> Mmm.  Could be a diff.  bzr+ssh probably gets sighup.
[02:10] <poolie_> cory, there's a recent bug discussing how to do that better
[02:46] <ubotu> New bug: #145027 in bzr "bad assertions in WorkingTree4._add" [Medium,Confirmed]  https://launchpad.net/bugs/145027
[02:52] <AfC> As at which version did --trees become the default implied behaviour in `bzr init-repo` (ie, can I remove --trees from my instructions now?)
[02:52] <fullermd> 0.15, I think
[02:53] <fullermd> Anybody keeping up should be long past that, but there're probably still a notable percentage of people below it.
[02:58] <AfC> fullermd: oh, that's ok
[02:58] <AfC> fullermd: I actively encourage my users to be >= 0.90
[02:59] <AfC> fullermd: I was just worried it was 0.18 or something, in which case I would have left the documentation alone
[02:59] <AfC> fullermd: thanks
[02:59] <fullermd> I think I actually have a server with 0.14...
[02:59] <fullermd> But that's 'cuz everything on it is outdated, and I'm just waiting to do it all in one swell foop, so not bothering to piecemeal.
[03:00] <AfC> What about --dirstate-tags ? Is it default as of 0.90?
[03:00] <fullermd> 0.91, I think.
[03:00] <AfC> fullermd: shit
[03:00] <AfC> ok
[03:05] <Peng> How does one switch a repo between --trees and --no-trees?
[03:07] <fullermd> rm or touch still, I think.
[03:07] <fullermd> .bzr/repository/no-working-trees
[03:08] <cory> Or checkout / remove-tree?
[03:08] <cory> repo / branch...never mind.
[03:20] <ubotu> New bug: #145033 in bzr "need a command to switch a repository between trees and no-trees" [Medium,Triaged]  https://launchpad.net/bugs/145033
[03:22] <lifeless> fullermd: a patch to reconfigure to do it would be good
[03:23] <fullermd> Would be the reasonable place for it.
[03:24] <poolie> or maybe we should have gdb-like set/show commands
[03:26] <fullermd> Wow, we're over half a million bugs in launchpad?  ;)
[03:28] <cory> 564043 isn't found...
[03:30] <lifeless> fullermd: no, 145K
[03:30] <lifeless> or perhaps I'm on crack
[03:31] <igc> today's plan: review things (particularly from lifeless and poolie), then start on OSDC tutorial
[03:31] <igc> knit repo formats tidyups will be first
[03:35] <fullermd> lifeless: I'm aware.  Hence the ;) for poolie's x-ref.
[03:44] <lifeless> igc: thanks
[03:45] <igc> np
[03:45] <lifeless> igc: I'm working on applying inventory deltas to the parent tree of a working tree
[04:03] <jelmer__> sucky airport wireless
[04:15] <schierbeck> jelmer_: is there some historical reason why the viz window is titled "bzrk"?
[04:16] <jelmer_> schierbeck: yup, it used to be a standalone plugin called 'bzrk'
[04:17] <jelmer_> or 'bezerk' (if I got hte spelling right)
[04:17] <schierbeck> jelmer_: do you think it should be changed to something more descriptive?
[04:17] <schierbeck> like "branch history"
[04:17] <AfC> Agreed
[04:19] <jelmer_> schierbeck: yeah, that's probably a good idea
[04:20] <schierbeck> jelmer_: i'll make a branch for it
[04:20] <jelmer_> cool, thanks (-:
[04:21] <schierbeck> "branch history" is fine, right?
[04:25] <lifeless> sounds good
[04:25] <lifeless> or graphical log of URL
[04:25] <lifeless> sorry, "Log of <URL>"
[04:25] <lifeless> (because viz is a graphical log)
[04:34] <schierbeck> lifeless: i'm not really fond of "log"
[04:34] <schierbeck> it struck me when i saw it in olive
[04:34] <schierbeck> "history" much better captures the purpose
[04:35] <schierbeck> perhaps it's just me
[04:35] <schierbeck> it usually is
[04:41] <abentley> I always find "unprintable" exceptions amusing, because "unprintable" was used in place of swear words in the Foundation series.
[04:42] <poolie> :)
[05:07] <lifeless> schierbeck: on the other hand, 'bzr log' is the text command to get the same data
[05:07] <lifeless> schierbeck: I don't have a strong opinion though; mainly showing the url would be nice.
[05:10] <schierbeck> lifeless: why not show the branch nick? isn't that more descriptive?
[05:12] <fullermd> Why not just "bzr viz: $URL"
[05:13] <schierbeck> fullermd: i'd like it to be more human-readable
[05:13] <schierbeck> remember, it could be launched from nautilus
[05:14] <schierbeck> the user may not even know of the "viz" shorthand
[05:15] <abentley> schierbeck: The historical reason was that it was based on "gitk".
[05:15] <schierbeck> abentley: ok
[05:15] <schierbeck> but the users won't really care about that
[05:17] <schierbeck> i'm trying to find ways to streamline the viz, to make it less confusing to newcomers
[05:36] <abentley> lol, looks like the git crew stole bzrk back, and made gitview.
[06:18] <igc> now reviewing poolie's patch re safe_revision_id, etc.
[06:20] <spiv> abentley: did you see my post about reconcile where a file parent is a ghost?
[06:20] <abentley> Yeah.
[06:21] <Odd_Bloke> I've created a separate branch for a particular release of my project.  However, I now have a bug-fix branch which I need to apply to both branches without its application to the release branch also merging the features that have been added since the release branch was branched from trunk.  What's the best way to go about doing this?
[06:21] <abentley> I guess I have a preference for sticking to the known facts.
[06:22] <abentley> The ancestry data in your knits should be derivable from the texts of the revisions and the texts of the inventories.
[06:22] <spiv> So I guess one issue is if we remove the parent the ghost is later filled in and it turns out that the data wasn't wrong after all, then reconcile will be introducing problems rather than fixing them.
[06:22] <abentley> But really, I'd rather sleep on it.
[06:22] <spiv> s/the ghost/and the ghost/
[06:22] <spiv> Fair enough.
[06:22] <abentley> What problems?
[06:23] <spiv> That's why I wanted to check you'd seen then mail, so you had plenty of time to think about it :)
[06:23] <spiv> Well, just that the data is now "wrong", whereas if we'd never run reconcile in that case it wouldn't be.
[06:24] <fullermd> Odd_Bloke: DAGgy it back to the branch point.
[06:25] <Odd_Bloke> fullermd: DAGgy?
[06:26] <fullermd> That's the term the mtn guys use for it.  Catchy.
[06:26] <fullermd> The theory in extremis is that you make the bug fix revision a child of the revision that introduced the bug; that way any branch that has that bug, can directly merge the bug fix.
[06:26] <fullermd> In less extreme cases like this, just making it a child of some rev both branches have in common (the branch point being the obvious choice).
[06:29] <Odd_Bloke> fullermd: OK, thanks. :)
[06:29] <fullermd> Odd_Bloke: http://www.venge.net/mtn-wiki/DaggyFixes
[06:39] <abentley> spiv: My point is having knit data with too few ancestors doesn't produce many harmful results, while having knit data with too many ancestors does.
[07:09] <fullermd> Ooh.  Purdy.
[07:09] <lifeless> abentley: possibly gitview went via hg ?
[07:09] <igc> yah for the 0.91 release!
[07:10] <lifeless> abentley: it does produce harmful results - bzr log FILENAME dpeends on the index
[07:10] <lifeless> AIUI
[07:11] <lifeless> abentley: the harm in having ancestors that aren't validated, at the border to a ghost, is two fold- index, and text construction.  Making a fulltext there addresses the text construction hole
[07:11] <abentley> The gitk man page says that gitview is derived from bzrk.  Of course, it could be wrong.
[07:11] <lifeless> oh cool
[07:12] <lifeless> what version of gitk do you have ?
[07:12] <abentley> I was just looking at this page: http://www.kernel.org/pub/software/scm/git/docs/gitk.html
[07:14] <lifeless> ah
[07:14] <lifeless> Ubuntu would appear to be out of date, and networkmanager blows again
[08:01] <Peng> Oh, 0.91 is out!
[08:03] <Peng> Cool.
[08:21] <lifeless> bbiab
[09:19] <fullermd> Y'know, there are some people who don't pass around source code in delis   :p
[09:20] <fullermd> (granted, they're people who live sad, colorless, wasted little lives.  But still.)
[09:22] <lifeless> AfC: sounds familiar
[09:23] <AfC> (sounds to me like the perfect opportunity for some propaganda on the bzr-gtk page)
[09:31] <AfC> Am I correct in believing that `bzr serve` doesn't background itself?
[09:32] <fullermd> I think you are...   though I've not tried, so for what that's worth...
[09:33] <Odd_Bloke> AfC: Just running it here doesn't background it...
[09:33] <AfC> [I mean, you run it on the command line and it sits there in foreground, implying I need to use the otherwise frowned upon --background option to start-stop-daemon (which, itself, I frown on, but I was being a good sys admin and being lazy)
[09:33] <AfC> Odd_Bloke: yeah
[09:43] <AfC> Well then. `bzr branch http://...` takes 20m36s minutes, bzr branch bzr://...` takes 1m46s. Guess I'll run the server daemon full time now
[09:57] <AfC> Canonical staff: someone should put an expires header on http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.png ... its a bit ridiculous that you download it every page load
[09:58] <AfC> (of course, that's a stupid way to serve static files, but anyway)
[10:00] <mwh> AfC: yay moin
[10:00] <AfC> (If there _is_ a static file I can point at, I would be happy to)
[10:15] <mwh> lifeless: wow, 'diff' seems slow with packs
[10:16] <mwh> http://rafb.net/p/EVQLD158.html
[10:18] <lapthrick> jelmer: there doesn't seem to be any bugreport of that push -> diverged branches bug, and it's hitting me atm
[10:18] <lapthrick> jelmer: are you aware of / working on it?
[10:20] <poolie_> AfC: what's happening?
[10:20] <AfC> poolie_ do a
[10:21] <AfC> wget -S 'http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.png'
[10:21] <AfC> and note the lack of expires headers
[10:22] <AfC> (compare
[10:22] <AfC>  wget -S 'http://www.operationaldynamics.com/images/logo/logo-130x167.jpg'
[10:22] <AfC> )
[10:22] <AfC> poolie_: result is that each time I reload my blog as I'm authoring I wait a few seconds for the Bazaar logo image I've used to load.
[10:23] <AfC> ... that has knock on effect when aggregated on places like planet.*
[10:23] <AfC> (knock on load for you guys, that is)
[10:23] <AfC> Lo-lan-do: --spider would have worked too
[10:24] <AfC> Lo-lan-do: but HEAD is lwp and it does funny things sometimes
[10:24] <AfC> Whatever. The point is to see the headers
[10:25] <AfC> poolie_ a .htaccess would probably kludge-fix it if you don't have easy access to the virtual host config
[10:25] <AfC> poolie_ I can whip up the directives if they're not coming to mind easily
[10:27] <Gacha> hi
[10:27] <Gacha> can somebody explain me the difference of --trees and --no-trees
[10:27] <Gacha> I'm reading the docs, but I dont get it :)
[10:27] <AfC> A branch doesn't have to have its files (a "checkout", if you will) present
[10:28] <AfC> Gacha: For instance,
[10:28] <Gacha> in whitch case?
[10:28] <AfC> Gacha: http://research.operationaldynamics.com/bzr/java-gnome/mainline/ is a branch called 'mainline' in a repository in directory /bzr/java-gnome on that server, whereas
[10:29] <AfC> which has --trees
[10:29] <AfC> ... in other words, files are there
[10:29] <lapthrick> Gacha: in a case you never need those file because you're only serving a branch, like launchpad does
[10:29] <AfC> whereas
[10:29] <lapthrick> s/a/the/
[10:29] <AfC> Gacha: http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/treeview/ is quite "emtpy" [*]  but contains a branch
[10:30] <AfC> * we actually want to change things so that a "THERE IS A BRANCH HERE" message appears
[10:30] <AfC> Gacha: /bzr/java-gnome/hackers is a different repository, and was created with --no-trees
[10:31] <AfC> Gacha: when you're working locally, you almost always want files present, so --trees
[10:31] <AfC> (which is the default now, according to conversation earlier today)
[10:31] <poolie_> acf, we should probably just put the image on a static host somewhere and point to that
[10:32] <Gacha> so with --no-trees files are keept in the main repo but not in the branch
[10:32] <lapthrick> is anyone aware of a branch of ezbzr still around? Nathaniel apparently removed everything from his site, and bzr release didn't make its way into mainline bzr
[10:33] <AfC> Gacha: the _revisions_ are kept in the repository (Which may be in .bzr, it may be in ../.bzr, whatever)
[10:33] <AfC> Gacha: whether there is a checkout of the files in that branch is what --trees influences
[10:33] <AfC> Gacha: like I said, you generally want files, and its default, so don't worry about it :)
[10:34] <Gacha> ok, thanks
[10:37] <poolie_> igc, are you still around?
[10:37] <igc> yep
[10:39] <poolie_> igc, i just commented on https://bugs.edge.launchpad.net/bzr/+bug/137449/comments/8
[10:39] <ubotu> Launchpad bug 137449 in bzr "status performance regression compared to 0.17" [Critical,Triaged] 
[10:39] <poolie_> i think that's why status looks so slow
[10:40] <poolie_> so, do you think this is the likely cause,
[10:40] <poolie_> and if it is, do you think it'll be hard for me to change the order in which the test components are run?
[10:40] <igc> I agree with your assessment ...
[10:40] <igc> and have been meaning to make that change
[10:41] <Slant_Laptop> How can I have a directory inside my repo that is a branch from another repo, and will updates will pull from it?
[10:41] <igc> it's not a large change but it's not a 10 minute one
[10:41] <poolie_> Slant_Laptop: just branch it, and then pull changes in
[10:41] <poolie_> it should work in the obvious way
[10:42] <poolie_> however, at the moment you can't branch a subdirectory of a branch, if that's what you're talking about
[10:42] <igc> poolie_: a sad workaround right now is, when running by hand at least, to run usertest on one tool ...
[10:42] <igc> then run it again on another
[10:42] <igc> you don't get the nice cross comparison of course
[10:44] <poolie_> right, i was going to at least try that and see what happens
[10:44] <igc> poolie_: I'm happy to make the change later this week if you don't get time ...
[10:45] <igc> right now, I need to get my osdc tutorial together as the submission date is Sep 30
[10:46] <Slant_Laptop_> Grr, that was annoying.
[10:46] <Slant_Laptop_> poolie_: So, if I already have a directory, "a/" that I did a bzr init in.
[10:46] <Slant_Laptop_> poolie_: Inside it, do a bzr branch http://blah
[10:47] <Slant_Laptop_> poolie_: If I cd into "a/blah" from then on and do a bzr update, it will merge in the upstream updates?
[10:47] <Slant_Laptop_> And if I do a bzr push from "a/" it'll push everything under a/ including a/blah?
[10:48] <poolie_> Slant_Laptop_: no, it will only push a, you need to push a/blah separately
[10:48] <poolie_> but i think there is a plugin (multipush?, maybe in bzrtools?) that will automate it
[10:49] <poolie_> if you can't find it, please just ask the list
[10:49] <igc> multi-pull is part of bzrtools
[10:49] <igc> not sure about multi-push though
[10:50] <Slant_Laptop_> There is a multi-pull, but I don't see a multi-push.
[10:53] <Slant_Laptop_> So, no real solution to the problem? Grr, I don't want to do this in SVN. :-\
[10:54] <lapthrick> Slant_Laptop_: there's experimental (yet) nested tree support being worked on, 0.92 I believe is the target. For now, you can use merge-into plugin
[10:54] <lapthrick> (I'm using it myself)
[10:54] <lapthrick> Slant_Laptop_: it will let you embed a branch inside another
[10:54] <Slant_Laptop_> lapthrick: It doesn't seem to be in my 0.90 copy. Do you have a link?
[10:54] <lapthrick> Slant_Laptop_: also, I'm working with SVN myself (which is why I know it), and there are bugs right now that prevent it from actually working
[10:55] <lapthrick> Slant_Laptop_: bzr plugins page links to it
[10:56] <lapthrick> Slant_Laptop_: you will need extra-recent bzr-svn (r716 or newer from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/), but that has a problem of not being able to push into SVN (because there's some breakage which makes it think the branches have diverged)
[10:57] <lapthrick> Slant_Laptop_: you will also need https://bugs.launchpad.net/bzr-merge-into/+bug/144108 for merge-into to work
[10:57] <ubotu> Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New] 
[10:58] <lapthrick> Slant_Laptop_: I hope jelmer will fix the push thing soonish, so that it'll work finally
[10:59] <lapthrick> Slant_Laptop_: other than that, it works very well, with the caveat that merging upstream changes that move files around (as opposed to just changing their contents) will trigger spurious conflicts, that's probably unfixable before the nested trees support lands in, rendering merge-into obsolete
[11:00] <Slant_Laptop_> Hmm, gotcha.
[11:00] <poolie_> igc, yes, that seems to be the problem with status
[11:00] <poolie_> so that's kind of nice
[11:11] <Peng> Oh, I forgot. 0.91 adds -c. Yay!
[11:11] <Lo-lan-do> What -c?
[11:12] <Peng> bzr diff and other commands.
[11:12] <Lo-lan-do> Oh, cool.
[11:12] <Lo-lan-do> Although I prefer diff -u myself :-)
[11:12] <Peng> -c revision means changes introduced by that revision.
[11:12] <Peng> Oh, not *that* -c.
[11:13] <Lo-lan-do> Ah.
[11:16] <lapthrick> Peng: h? How is that different from what diff normally does?
[11:17] <Peng> lapthrick: Instead of having to do 'bzr diff -r 99..100', you can do 'bzr diff -c 100'.
[11:17] <lapthrick> ah
[11:17] <lapthrick> handy
[11:17] <Peng> Also useful when dealing with a huge revno from a bunch of merges.
[11:17] <lapthrick> I was annoyed by the -r99..100 thing
[11:19] <poolie_> night all
[11:44] <gabe> hi all
[11:52] <matkor> Hi ! One can safely edit .bzrignore files ? I would like to remove some bad patterns from it ? TIA
[11:52] <Peng> matkor: Yes.
[11:53] <matkor> Thank you Peng !
[11:54] <Peng> :D
[12:01] <lapthrick> jelmer: you have a new bug report awaiting
[12:01] <lapthrick> jelmer: I actually discovered that while trying to reproduce another bug I ran into in my test repo, where bzr missing shows extra local revisions, yet bzr push says nothing to push
[12:03] <lapthrick> jelmer: there's definitely something wrong going on with diverged branches logic, first is that "can't push, can't merge" bug, then is that "nothing to push" (which I ran into trying to create a minimal testcase for the push bug)
[12:11] <matkor> Hmmm From where I can download bzr-gtk 0.91.0 ?
[12:13] <lapthrick> matkor: I don't think there is bzr-gtk 0.91
[12:13] <lapthrick> matkor: anyway, just grab it from the plugins page
[12:14] <lapthrick> oh wait, it is synced
[12:14] <lapthrick> matkor: https://launchpad.net/bzr-gtk/0.91/0.91.0/+download/bzr-gtk-0.91.0.tar.gz
[12:15] <matkor> lapthrick: Thanks !
[12:23] <pbor> lapthrick: do you have a ~ on gnome.org ?
[12:23] <lapthrick> pbor: unsure, I know I have an SVN account
[12:23] <pbor> no, that's unrelated
[12:24] <pbor> lapthrick: pushing there with bzr push sftp takes forever (I mean it's been running for three hours and it is not even 50% of 1/4)
[12:24] <pbor> I was wondering if it is normal or related to gnome.org
[12:24] <lapthrick> no idea
[12:25] <lapthrick> pbor: how big is the push?
[12:25] <lapthrick> if it's pushing afresh, then you want to use rspush instead
[12:25] <pbor> pushing with sftp to localhost took some minutes
[12:25] <pbor> lapthrick: the gedit repo, so pretty big
[12:26] <pbor> does that accept --create-prefix ?
[12:27] <pbor> it is not mentioned in the help...
[12:28] <lapthrick> dunno
[12:28] <lapthrick> pbor: but it's a shitload faster, since it uses rsync
[12:33] <pbor> lapthrick: execept that I get a traceback :/
[12:34] <pbor> bzr: ERROR: bzrlib.errors.ObjectNotLocked: <WorkingTree4 of /home/paolo/bzr/gedit> is not locked
[12:35] <lapthrick> ugh?
[12:35] <lapthrick> pbor: no idea what it means, I never got it
[12:35] <pbor> bzr doesn't like me apparently
[12:36] <lapthrick> jelmer: I was able to pull command log out of .bash_history, it's now reported as https://bugs.launchpad.net/bzr-svn/+bug/145165
[12:36] <ubotu> Launchpad bug 145165 in bzr-svn "bzr missing reports extra revs, yet push says nothing to do" [Undecided,New] 
[12:37] <lapthrick> pbor: well, look at it another way: we whack the bugs now so it's awesome later :)
[12:38] <lapthrick> pbor: also, I'd definitely report that one
[12:38] <pbor> lapthrick: yeah, I started reporting the bugs I am running into
[12:39] <pbor> speaking of which, before I report a bogus bug, is this request reasonable:
[12:39] <lapthrick> pbor: btw, you can just rsync the branch over, it will work just as well
[12:40] <pbor> pull, hack, [someone commits an unrelated change to svn] , merge, commit, push
[12:40] <pbor> now two revisions are pushed to svn
[12:40] <pbor> my hack
[12:40] <pbor> and the merge
[12:41] <pbor> could bzr be smart enough to avoid the 'merge' revision?
[12:41] <mwh> pbor: presumably your 'hack' included committing?
[12:41] <pbor> it's already in svn, that's where I pulled it from
[12:41] <pbor> mwh: sure
[12:41] <pbor> (sorry for omitting that)
[12:41] <mwh> i think the same would happen with pushing to a bzr repo then
[12:42] <pbor> yes, I do not think it is specific to svn
[12:42] <pbor> but it (IMHO) sucks a bit
[12:43] <mwh> i think a common pattern is "only merge to mainline"
[12:43] <pbor> it means that for instance I'll have all the commts to po files by translators twice in the history
[12:43] <mwh> eh, that probably doesn't make sense
[12:43] <pbor> well, if I do not merge into my tree it doesn't let me commit
[12:43] <mwh> but anyway, you seem to be asking for a situation where you have a revision in your branch
[12:44] <mwh> then after a push, that revision is _not_ in the target branch
[12:44] <mwh> that seems to violate a pretty important invariant...
[12:44] <pbor> mwh: I know, in fact I would be happy to avoid the merge if I could
[12:45] <pbor> mwh: what I am saying is that that revision is already in the 'upstream' branch
[12:45] <pbor> that's where I get it from
[12:45] <pbor> (because I am forced to)
[12:45] <mwh> but the result of the merge is a separate revision (what if there were conflicts?)
[12:46] <lapthrick> heh
[12:46] <pbor> ok, but there weren't... I am asking if there is a workflow to avoid that: in fact (but I still have to try) I think I can do this:
[12:47] <pbor> keep two branches: one mirrors upstream
[12:47] <jelmer_> 'morning
[12:47] <lapthrick> pbor: besides, the merge results are only shown in the history of the branch that did the merge in the first place. When you commit, the upstream history will only have a revision that says "pbor: merged from upstream"
[12:47] <pbor> every time I want to commit I sync the mirror and then merge my hacking branch and then push
[12:47] <lapthrick> jelmer_: hiya, can you read jelmer's backlog?
[12:47] <mwh> pbor: right, i was going to suggest a different approach here...
[12:47] <lapthrick> jelmer_: I reported a couple of bugs
[12:48] <pbor> mwh: that should work but it's a bit of a PITA :-)
[12:48] <lapthrick> jelmer_: and I still have that diverged branches bug, except that I can't even do a merge to fix it
[12:48] <lapthrick> pbor says it doesn't happen for him in 0.4.3 tarball, I'm running r719 tho
[12:49] <mwh> pbor: well, in True Distributed Style (tm) you only should only merge to mainline and push when your branch is done (bug fixed, new feature working, etc)
[12:49] <lapthrick> pbor: actually, could you try if you get that bug with the latest rev of http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ ?
[12:49] <mwh> if, in effect, you're using subversion to share your changes then yeah, it's a bit of a pain
[12:49] <pbor> lapthrick: which bug?
[12:50] <pbor> oh, got it
[12:50] <lapthrick> pbor: bzr push reporting that branches have diverged
[12:51] <pbor> lapthrick: mmm... I'll try it later, right now I have no pending changes to commit and I'd prefer to avoid bogus test changed in the upstream gedit svn repo
[12:52] <pbor> lapthrick: I am already waiting to flamed since my commit touched all the files :)
[12:52] <lapthrick> pbor: okay, as long as you remember to do it :)
[12:52] <lapthrick> pbor: hehe, because of bzr-svn?
[12:52] <pbor> yeah
[12:52] <lapthrick> how so?
[12:52] <pbor> no idea... probably the properties
[12:53] <jelmer_> pbor: it's only viewcvs that reports all files as changed
[12:53] <jelmer_> pbor: if you use 'svn log', you'll see there are only a few files changed by that commit
[12:53] <pbor> jelmer_: yeah, but I don't think viewcvs is psychic so something must have happened in the repo
[12:54] <pbor> :)
[12:54] <jelmer_> pbor: Replying to your bugreport atm
[12:54] <pbor> jelmer_: thanks!
[12:54] <lapthrick> jelmer_: I don't see the DivergedBranches bug reported anywhere (not in 0.4 anyway). should I go and create it?
[12:57] <jelmer_> lapthrick, which bug do you mean exactly?
[01:01] <jelmer_> ok, I'm off again - will reply to the bugs later today
[01:08] <lapthrick> jelmer_: uh-oh, yet more bugs
[01:10] <ubotu> New bug: #145170 in bzr "traceback doing rspush (bzrlib.errors.ObjectNotLocked)" [Undecided,New]  https://launchpad.net/bugs/145170
[02:31] <lapthrick> so do people actually practice DAGgy bugfixes? Does it work well?
[02:32] <lapthrick> ( http://www.venge.net/mtn-wiki/DaggyFixes )
[02:33] <mwh> lapthrick: i think, in practice, "no"
[02:33] <mwh> people don't do that
[02:34] <lapthrick> because it's a bother, or because it doesn't work?
[02:34] <mwh> because it's a bother
[02:35] <mwh> just my impression of course, both the bzr using projects i follow closely (bazaar and launchpad) have a pretty centralized model in some ways
[02:36] <mwh> (i.e. a mainline that contains or will contain almost everything interesting)
[02:36] <mwh> the kernel folks may have a different view
[02:39] <nocturn> Hi all
[02:40] <nocturn> What is the difference between bzr merge and bzr merge --pull?  In what circumstances do you use --pull?
[02:48] <AfC> nocturn: if the thing you're merging actually supersedes the current branch (ie has only got things that you don't have) then you can pull them in on top instead of the revision graph doing a zig-zag
[02:48] <lapthrick> nocturn: it's a shortcut
[02:48] <lapthrick> nocturn: equivalent to bzr merge && bzr commit && bzr pull
[02:48] <AfC> nocturn: frankly I don't bother anymore, in no small part because our 'mainline' has almost always moved on since the contribution
[02:49] <AfC> lapthrick: It often seemed to me that `bzr pull` should just do that automatically if it isn't a "needs [manual]  merge"
[02:49] <AfC> seems a bit silly to have the question arise
[02:49] <lapthrick> AfC: somewhat, yeah
[02:53] <ike> Hello. I have a problem and i'm kinda confused now. Maybe i'm missing something or so. I cannot push my repository to remote server.
[02:53] <ike> This is what bzr says:
[02:53] <ike> LPA:~/Projects/Repositories/bzr/bffrg ike$ bzr push  bzr+ssh://ike@lu/repository
[02:53] <ike> bzr: ERROR: Generic bzr smart protocol error: Permission denied: u'//repository': [Errno 13]  Permission denied: '//repository'
[02:54] <AfC> lu is a server name that resolves, with /repository in its root directory?
[02:54] <ike> And now - i can log into server 'lu' user 'ike' using my keys so.
[02:54] <ike> Yes. Lu resolves.
[02:55] <ike> But /repository doesn't exist.
[02:55] <ike> Hm.
[02:55] <ike> I get it. Thanks.
[02:55] <ike> :-)
[02:55] <ike> Sorry for trouble.
[02:55] <AfC> It's a bit ugly, actually:
[02:55] <AfC> we have things set up so that
[02:55] <AfC> http://research.operationaldynamics.com/bzr/java-gnome/mainline is equal to
[02:55] <AfC> bzr://research.operationaldynamics.com/bzr/java-gnome/mainline , but for writing (push) it is
[02:56] <AfC> bzr+ssh://centauri.lhr.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/hackers/andrew/treeview/
[02:56] <AfC> which is unfortunate
[02:56] <ike> Kinda.
[02:56] <AfC> the only workaround would be a symlink called bzr in /. Somehow that doesn't seem quite right.
[02:57] <ike> No. That's too ugly. ike@lu/home/users/ike/repository is fine.
[02:58] <ike> Hm. I still have an error. bzr: ERROR: exceptions.AssertionError: end of file reading from server.
[03:00] <ike> Whole traceback : http://paste.debian.net/38066
[03:00] <ike> I'll try to figure this out, but if you guys have any suggestions - don't hesitate to tell.
[03:00] <ike> :-)
[03:02] <nocturn> Thanks lapthrick and AfC
[03:03] <AfC> ike: you could upgrade to 0.91 seeing as how you're running your own code anyway
[03:03] <AfC> That'd be the usual start
[03:12] <sabdfl> was 0.91 released today?
[03:16] <AnMaster> what do I do to update the repo location in a --lightweight checkout
[03:16] <AnMaster> the repo moved
[03:16] <AnMaster> but I got uncommited changes so doing a new --lightweight checkout wouldn't be an optimal solution
[03:18] <Odd_Bloke> AnMaster: 'bzr bind <new location>' is probably what you want.
[03:18] <AnMaster> bzr: ERROR: Not a branch: http://url.here/
[03:18] <AnMaster> and that url is the old location of the repo
[03:18] <AnMaster> Odd_Bloke, so it tries to bind the repo of the old checkout
[03:18] <AnMaster> this is a --lightweight checkout, not a full one
[03:19] <Odd_Bloke> AnMaster: OK, try 'bzr unbind' followed by that command...
[03:19] <AnMaster> $ bzr unbind
[03:19] <AnMaster> bzr: ERROR: Not a branch: http://url.here/
[03:19] <AnMaster> :/
[03:20] <AnMaster> Odd_Bloke, any idea?
[03:21] <Odd_Bloke> AnMaster: Hmm, those're all the suggestions I had.  I don't really use lightweight checkouts in anger. :/
[03:21] <lapthrick> AnMaster: try bzr shelve, then do a new lightweight checkout
[03:21] <AnMaster> lapthrick, that shelve also returns bzr: ERROR: Not a branch: http://url.here/
[03:21] <AnMaster> I guess new checkout and then copy files over is the only way
[03:22] <AnMaster> lapthrick, there should be a way to repoint where the repo is if the repo has moved
[03:22] <AnMaster> lapthrick, like svn switch --relocate
[03:23] <lapthrick> AnMaster: there should be
[03:23] <lapthrick> oh right
[03:23] <lapthrick> AnMaster: there's bzr switch
[03:23] <lapthrick> which does that
[03:23] <AnMaster> Purpose: Set the branch of a lightweight checkout and update.
[03:23] <AnMaster> ah!
[03:23] <AnMaster> this may work
[03:23] <AfC> `bzr pull --overwrite` is a core command that will switch branches quite emphatically.
[03:24] <AnMaster> lapthrick, good but if the repo already moved it still tries to access the old repo first and fails
[03:24] <AnMaster> like happened now
[03:25] <mwh> there's a bug about that somewhere
[03:25] <mwh> vim .bzr/branch/<something> might work...
[03:25] <AnMaster> nano but hm
[03:25] <AnMaster> or emacs
[03:25] <mwh> this is not the important detail :)
[03:25] <mwh> (though, nano?? ew)
[03:26] <AnMaster> mwh, nano or emacs, but better just say $EDITOR
[03:26] <AnMaster> :)
[03:26] <Odd_Bloke> Ew, emacs.  Stick with nano. ;)
[03:27] <lapthrick> eww nano and vi
[03:27] <bwinton> Stick with Notepad!
[03:27] <lapthrick> (though I actually use nano for my commit messages, too lazy to set up $EDITOR)
[03:28] <AnMaster> though:
[03:28] <AnMaster> $ echo $EDITOR
[03:28] <AnMaster> /usr/bin/emacs
[03:28] <AnMaster> :)
[03:29] <AfC> A bit hard to do good quality multi line messages with -m
[03:29] <AnMaster> AfC, that is true
[03:29] <AnMaster> but well, it depends on how big changes you do
[03:29] <Lo-lan-do> I have started using -mm for really minor commits
[03:29] <Lo-lan-do> Typos and the like.
[03:29] <AnMaster> interesting in a repo (as in init-repo)
[03:29] <AnMaster>  $ bzr st
[03:29] <AnMaster> bzr: ERROR: [Errno 2]  No such file or directory
[03:30] <AnMaster> it should say like when it is not a branch or repo:
[03:30] <AnMaster> $ bzr st
[03:30] <AnMaster> bzr: ERROR: Not a branch: /some/dir
[03:30] <AnMaster> or maybe "not a branch, this is a repo)
[03:30] <AnMaster> or something like that
[03:30] <AnMaster> but the "no such file or directory" seems bad
[03:32] <lapthrick> Lo-lan-do: what's -mm?
[03:32] <Lo-lan-do> Use "m" as a commit message?
[03:32] <AnMaster> that isn't very informative
[03:32] <Lo-lan-do> As in "minor fix"
[03:33] <AnMaster> bzr ci -m 'Fixed typo'
[03:33] <AnMaster> or something like that is what I do
[03:33] <AnMaster> or even
[03:33] <AnMaster> bzr ci -m 'Fixed typo in log message in src/foo.c'
[03:33] <Lo-lan-do> Well, I don't really need much information in commits on my blog entries.
[03:34] <AnMaster> blog? what do you mean?
[03:34] <AnMaster> what has blog got to do with bzr?
[03:34] <Lo-lan-do> And I like important commits to stand out and not be drowned under big but useless messages.
[03:35] <Lo-lan-do> I use ikiwiki for my blog.  I edit articles on a local copy (it's an SVN checkout, but whatever), and the HTML gets generated and pushed online with a commit hook.
[03:35] <AnMaster> hm
[03:35] <AnMaster> interesting
[03:42] <Enquest> I don't understand the how to publish my webproject
[03:43] <Enquest> I try to use the push command but it only creates a .bzr file in the destination dir
[03:43] <Odd_Bloke> Enquest: You'll need to also checkout a working directory there.
[03:43] <schierbeck> p
[03:44] <Enquest> What is the difrence then?
[03:45] <Enquest> why use push then?
[03:45] <Odd_Bloke> Enquest: At the moment, you have pushed the branch and repository, which is enough for a branch which is just being served.  If you also want the contents reconstituted there, you need to create a checkout (look at the push-and-update plugin at https://launchpad.net/bzr-push-and-update/).
[03:47] <Enquest> is the bazaar server down... No response of the website?
[03:48] <mwh> the canonical data centre is having a bad day, it seems
[03:48] <Odd_Bloke> :(
[03:49] <gabe> it seems the ubuntu forums are shot away, at least for me
[03:49] <gabe> :(
[03:52] <Enquest> how do I deploy my website in best. Know that some info changes... like some PATH info and mysql settings ?
[03:53] <Enquest> What is the best way to avoid every update to my website changing those paths
[03:56] <gabe> use relative paths where possible?
[04:03] <sabdfl> mwh: it's upstream ISP, not the data centre itself, afaik
[04:04] <mwh> sabdfl: ah right
[04:34] <Mez> is ther eanywhere that I can show someone an example of bzr#'s "much better branching and merging" to try and convionce the people ar work regarding it?
[05:06] <radix> argh, "bzr log |head" in gutsy causes a crash report dialog to pop up :\
[05:07] <fullermd> lapthrick, mwh: I daggy sometimes, when I think there's a good chance it'll be useful.  Not as a reflex, though.
[05:43] <AnMaster> radix, shouldn't it simply dump core?
[05:44] <AnMaster> <-- not ubuntu user
[05:44] <AnMaster> but "crash report dialog" sounds too much like windows for me
[05:44] <radix> AnMaster: well, the issue is that "bzr log |head" raises an exception in bzr now
[05:45] <radix> it's an old bug that was fixed and seems to have regressed back
[05:45] <AnMaster> radix, that sucks, but what I wondered about was why it simply doesn't dump core / traceback, why a *dialog* poping up for it
[05:45] <AnMaster> that would only work inside X
[05:45] <AnMaster> breaks horribly if you aren't running X atm
[05:46] <radix> AnMaster: forget the dialog :)
[05:46] <radix> AnMaster: it's not related to bzr
[05:46] <AnMaster> radix, I use freebsd mainly, a dialog poping up sounds way too much like windows
[05:46] <radix> AnMaster: I'm sorry you feel that way
[05:47] <AnMaster> radix, thanks for the warning though, I will avoid ubuntu now, I prefer to work from command line
[05:47] <AnMaster> :)
[05:47] <AnMaster> (but indeed this isn't a flamewar channel)
[05:47] <radix> fwiw, nothing bad happens if you're not in X
[05:47] <AnMaster> that is at least a good thing, but even in X I prefer getting a core dump / python traceback
[05:47] <radix> you still get those.
[05:48] <AnMaster> I will stay with FreeBSD, slackware and gentoo :)
[05:50] <dato> radix: hm, I don't get an exception with bzr.dev
[05:50] <dato> ah
[05:50] <dato> but gutsy is closed
[05:50] <radix> maybe it was refixed
[05:50] <radix> 0.90.0 seems to be raising the exception
[05:50] <dato> right, here too
[05:51] <dato> but 0.91 not
[05:51] <radix> cool
[05:56] <AnMaster> radix, um on gentoo with 0.90.0 bzr log | head does NOT cause any traceback
[05:57] <AnMaster> and there is almost 500 revs in this project
[05:58] <AnMaster> $ bzr --version
[05:58] <AnMaster> Bazaar (bzr) 0.90.0
[06:01] <pbor> jelmer: "if you would like to avoid this, use the 'rebase' command, which makes sure history stays linear"... I can't see any rebase command, can you give me a link?
[06:01] <Lo-lan-do> pbor: It's an external plugin
[06:01] <pbor> thanks Lo-lan-do
[06:03] <pbor> whooo... that looks *really* interesting
[06:06] <pbor> I guess that it would allow me to adapt my workflow with svn
[06:06] <pbor> I just need to rebase before pushing
[06:06] <pbor> so that I do not need to merge the translator chnages
[06:08] <pbor> jelmer: so if I understand correctly, the fact that all the files where "touched" is due to the fact that there was a commit to svn between the time I pulled and the time I pushed? So if did rebase before pushing I would have avoided the problem with viewcvs?
[06:45] <jelmer> pbor: The rebase plugin is listed on the plugin page
[06:45] <jelmer> pbor: the fact that you merged upstream at some point causes the problem
[06:46] <pbor> jelmer: so if I rebase instead of merging I avoid the issue
[06:46] <jelmer> yep
[06:46] <pbor> neat
[06:46] <Lo-lan-do> Hmm.  Would that apply to me too?
[06:46] <jelmer> I'd recommend using the 0.1 version of rebase though, current trunk is a bit unstable
[06:47] <pbor> jelmer: will rebase in the future also allow to "squash" changeset together?
[06:49] <jelmer> pbor: not really... why would you want to do that?
[06:51] <james_w> pbor: you will be able to do that with pure bzr soon.
[06:52] <pbor> jelmer: suppose on the branch I have two changesets: "Implement feature X" and "ops fix compilation", now when I want to rebase it against the main repo I want also to just have one changeset and "delete" the typo from the history
[06:52] <pbor> james_w: awesome
[10:06] <GaryvdM> Hi phanatic
[10:08] <phanatic> hey Gacha
[10:08] <phanatic> heh
[10:08] <phanatic> sorry
[10:08] <phanatic> GaryvdM :)
[10:09] <GaryvdM> I can't decide what I want to work on next
[10:09] <GaryvdM> Either
[10:09] <GaryvdM> https://blueprints.launchpad.net/bzr-gtk/+spec/gannotate-viz-integration
[10:09] <GaryvdM> https://blueprints.launchpad.net/bzr-gtk/+spec/viz-pending-merges
[10:09] <GaryvdM> or
[10:09] <GaryvdM> https://bugs.launchpad.net/bzr-gtk/+bug/127734
[10:09] <ubotu> Launchpad bug 127734 in bzr-gtk "Progress bars as widgets" [Medium,Triaged] 
[10:10] <phanatic> GaryvdM: fixing the progress bars would be really awesome
[10:11] <GaryvdM> Right thats what I'll do, but I need some clarification on what we want :-)
[10:11] <GaryvdM> I thnk I'm going to flesh out a blueprint before I start coding...
[10:12] <pbor> you guys work on the gtk ui?
[10:12] <GaryvdM> Yhea
[10:12] <phanatic> pbor: yep, feel free to report them, we're actively squashing bugs ;)
[10:13] <pbor> well, not bugs but things that could be better wrt to gtk
[10:13] <phanatic> GaryvdM: cool. the basic idea is to fix the progress bars. now they are 1) ugly 2) don't close automatically
[10:14] <phanatic> pbor: please share your thoughts with us
[10:14] <GaryvdM> And it would be nice if they we intragrated in to the existing ui?
[10:14] <pbor> like the gstatus missing the proper shadow type in the scrolled window and having a horizontal separator that should not be there
[10:15] <pbor> or why visualise doesn't use a toolbar dor the back/forward buttons at the top
[10:16] <phanatic> GaryvdM: exactly, now they are separated a bit
[10:16] <GaryvdM> Cool
[10:16] <pbor> gmissing is particularly ugly with those frames
[10:16] <phanatic> pbor: these are still bugs in my opinion :/
[10:17] <pbor> I guess my eye is too used to the HIG-police :)
[10:18] <phanatic> yeh, i'm pretty sure that there are quite a few HIG-unaware stuff unfortunately
[10:23] <pbor> for prgress bars the easiest thing is probably put it in a statusbar
[10:24] <pbor> unless you want to do something fancy as gedit message area
[10:24] <pbor> but you'd need to redo that widget from scratch in python
[10:25] <GaryvdM> Sorry -  I have now idea what the gedit message area looks like
[10:25] <GaryvdM> I work mostly on windows...
[10:25] <pbor> GaryvdM: open a file long a few pages in gedit and do print preview
[10:26] <pbor> ah ok
[10:27] <pbor> GaryvdM: something like http://www.gnome.org/~paolo/screenshots/new_mdi/open-progress.png
[10:27] <pbor> (that screenie is a bit old)
[10:27] <GaryvdM> Thats cool.
[10:29] <GaryvdM> That would better for something like gcommit where we need to cater for both olive and gcommit.
[10:29] <phanatic> yep
[10:30] <pbor> btw, the olive toolbar doesn't respect my toolbar settings
[10:30] <GaryvdM> And I think some operations might meret a Checklist Window.
[10:31] <phanatic> pbor: thanks for you valuable comments
[10:32] <Peng> "``Transport.should_cache`` has been removed." is listed twice in NEWS for 0.91rc1 or whatever, undder both "API breaks" and "Testing".
[10:33] <bialix> hi people
[10:34] <dato> jelmer, siretart: I uploaded bzr 0.91 and bzr-gtk
[10:35] <dato> james_w: I'll do bzr-builddeb tomorrow
[10:36] <james_w> dato: thanks.
[10:38] <james_w> phanatic: in notify.py it should be  self.zeroconfserver.run() rather than .start()
[10:40] <phanatic> james_w: thanks, but i don't really know that part of the code, since it's pretty new, and i still couldn't catch up with that part (i was away on a soc duty with gnome)
[10:41] <james_w> I've tested the fix, it was just late, and seemed a little trivial for bug report/patch. Are you ok to just make the fix?
[10:43] <phanatic> sure, thanks again!
[10:44] <james_w> no problem.
[10:51] <siretart> dato: thanks!
[11:25] <lifeless> jelmer: 06:01 < jdub> lifeless: that whole svn-upgrade problem still exists -- no bzr-rebase in the repos, so can't do anything with bzr-svn atm
[11:29] <lifeless> james_w: are you aware of pull --merge ?
[11:32] <bratsche> Hi guys, I might have a small but annoying bug here.. or maybe I'm doing something wrong.
[11:33] <bratsche> I do: bzr diff -r ancestor:url-to-my-ancestor-branch
[11:33] <bratsche> It works fine if that url starts with sftp:// but it fails and crashes bzr if that url starts with bzr+ssh://
[11:33] <dato> lifeless: do you mean `merge --pull`?
[11:33] <bratsche> Is there something obvious I'm doing wrong, or is this a bzr bug?
[11:35] <lifeless> dato: something like that; james wrote a bzr-for-git page, and it says that we always do a commit to merge branches where git does, but this is bogus. Git simply chooses not to do a merge some of the time.
[11:35] <lifeless> and we have that as an option - merge --pull
[11:35] <lifeless> s/does/does not/
[11:35] <lifeless> bratsche: I think its a bzr bug
[11:36] <bratsche> lifeless: Seems like maybe the + is confusing the commandline arg parser, but I'm not sure.
[11:36] <lifeless> 0
[11:36] <lifeless> bratsche: could be
[11:36] <lifeless> bratsche: file a bug ?
[11:36] <bratsche> Okay, sure.
[11:37] <bratsche> Where is bzr's bug tracker?
[11:37] <james_w> lifeless: yess, why?
[11:37] <lifeless> https://launchpad.net/bzr/
[11:38] <bratsche> Thanks
[11:38] <james_w> lifeless: ah, I see now. I'll update the page.
[11:38] <lifeless> james_w: you say that 'merges in bzr require a commit regardless of conflicts'. Its not clear to me whether you are talking about git fast-forward, or if git automatically does a commit for you ?
[11:38] <lifeless> if you are talking about fast-forward, thats actually a case of skipping a merge, rather than not requiring a commit
[11:39] <james_w> yeah, it also automatically commits when there are no conflicts, so both need to be highlighted.
[11:39] <lifeless> if you are talking about git doing a commit for you, thats dangerous (because  textual conflicts are not a good indicator of semantic conflicts), and its worth noting why we don't autocommit there
[11:39] <lifeless> (there was a thread on the hg list about exactly the same behaviour just this week)
[11:41] <james_w> yeah, I was trying to avoid editorialising, I got a bit close with the left hand parent discussion, but it's obviously an evolution, so we can decide whether to include that there, or have another section for some 'why we think bzr is better' comments.
[11:42] <lifeless> ok, so concretely then ...
[11:42] <lifeless> we can fast forward
[11:43] <lifeless> so how it feels different can say 'bzr will fast-forward merges if you supply --pull'
[11:43] <lifeless> (rather than by default)
[11:43] <lifeless> but when it cannot fast forward it requires a commit be done
[11:43] <lifeless> or someting like that
[11:44] <lifeless> we don't want a page that a git user that things git is just perfect can point at and say 'look at all the differences, thats why I don't use bzr'
[11:44] <lifeless> mmm, I think I'm saying 'vive la difference'
[11:45] <lifeless> excuse the mangled french :)
[11:47] <lifeless> bbiab
[11:48] <james_w> yeah, I'll clean that page up.
[11:51] <ubotu> New bug: #145383 in bzr "bzr fails with diff -r ancestor:bzr+ssh://branchname" [Undecided,New]  https://launchpad.net/bugs/145383
[11:56] <lapthrick> does ubotu announce bzr-svn bugs too?
[11:57] <jelmer> lifeless: sorry about that, it's still on my todo list
[11:57] <jelmer> lapthrick, no[e
[11:57] <jelmer> s/[/p/