[00:02] <jelmer> luke-jr: yes, use bzr:file-ids as revprop
[00:02] <jelmer> luke-jr: and set that on a revision in which the file was introduced
[00:03] <jelmer> luke-jr: alternatively, "bzr reconcile" might do what you want
[00:14] <luke-jr> jelmer: another problem that I just thought of... :/
[00:15] <luke-jr> somehow I'll need to rebase the merged branches :\
[00:15] <luke-jr> I suspect I'm going to want to introduce 2 new revs for each original bzr rev
[00:15] <luke-jr> a rebased one and a merge of the rebased one and the original one
[00:16] <luke-jr> or perhaps I can have the rebased one list the original one as a parent... hmm
[00:34] <luke-jr> jelmer: I can't find that mapping spec
[00:36] <jelmer> luke-jr: specs/mappingv4.txt
[00:40] <luke-jr> ah
[00:40] <luke-jr> README had referred to some weird path :(
[00:51] <luke-jr> bzr:file-ids revprop doesn't seem to do anything :(
[00:51] <luke-jr> nor bzr:skip :/
[00:56] <jelmer> luke-jr: have you erased the cache ?
[00:56] <jelmer> luke-jr: also, have you set other bzr: revprops?
[00:58] <luke-jr> yes; not yet
[00:58] <luke-jr> bzr:skip looks to just be poorly documented
[00:58] <luke-jr> I expected to be able to set it on svn-r1 and get bzr to skip over that rev
[01:01] <jelmer> luke-jr: this is a design document, not a document aimed at users so they can set their own revision properties
[01:01] <luke-jr> anyhow, bzr:file-ids still seems to be ignored
[01:01] <luke-jr> do I need to set other properties to make it take effect? (perhaps bzr:mapping-version?)
[01:01] <jelmer> luke-jr: bzr:skip only means bzr-svn can avoid checking any other bzr-svn metadata for that revision
[01:02] <jelmer> luke-jr: yes, you need to set more than just bzr:file-ids
[01:02] <jelmer> luke-jr: at least bzr:mapping-version and bzr:root IIRC
[01:03] <luke-jr> what should they be?
[01:04] <luke-jr> the real repo has no bzr:mapping-version at least. :/
[01:04] <jelmer> luke-jr: I would recommend running "bzr reconcile" and checking what that sets
[03:00] <xnox> bzr nested trees rock way better than git subtree merge =)
[03:02] <xnox> I now do $ bzr merge svn://svn.server.org/path/to/external
[03:02] <xnox> and get everything i want =)! in the correct subdir of my project ;-)
[03:06] <jbowtie> xnox: I was under them impression that nested trees hadn't landed. Am I confused or are you working off a dev branch?
[03:06] <xnox> jbowtie, by reference nested trees are not here yet.
[03:07] <xnox> jbowtie, but you can do this $ bzr branch URL subdir/
[03:07] <xnox> $ bzr join subdir
[03:07] <xnox> $ bzr ci -m "Merging external code from any URL"
[03:07] <xnox> and from now on you can do
[03:07] <xnox> $ bzr merge URL
[03:07] <xnox> to update the code
[03:08] <xnox> but this makes history of that subdir part of your history
[03:08] <xnox> join & split have landed in bzr a while ago
[03:08] <jbowtie> xnox: Oh, OK. I'd never seen the join/split commands before, must read release notes more in future.
[03:09] <jbowtie> xnox: That gives me the benefits of svn:externals under Bazaar, right?
[03:09] <xnox> jbowtie, when we have by reference trees you will be able to have stuff like externals where that code is almost not part of your history & has independed branch on it's own.
[03:09] <xnox> jbowtie, almost =)
[03:10] <jbowtie> xnox: Almost is good enough for most of my scenarios.
[03:10] <xnox> jbowtie, yes almost good =)
[03:11] <xnox> if you want to work & submit patches to that external you are better off branching it on it's own, then try to commit stuff in your containing project
[03:11] <xnox> "then" = "than"
[03:12] <jbowtie> OK, my TFS plugin seems to be working well enough for read-only access to TFS repositories. (Microsoft Team Foundation Server)
[03:13] <jbowtie> Just need my manager to sign off on my pushing it to Launchpad.
[03:15] <jbowtie> xnox: Does pull update the joined directory, or do you have to explicitly merge?
[03:15] <xnox> jbowtie, you have to do merge
[03:16] <xnox> jbowtie, cause history has diverged from both places.
[03:16] <xnox> jbowtie, with by-reference nested trees you will be able to just pull
[03:16] <xnox> jbowtie, but we don't have that yet =)
[03:17] <xnox> jbowtie, I have svn import running of 2 projects on launchpad. With one having svn:external to the other
[03:17] <xnox> jbowtie, to update to latest code after the intial $ bzr join
[03:17] <xnox> I have to do $ bzr merge URL-super
[03:17] <xnox> $ bzr merge URL-external
[03:18] <xnox> then I have locally everything tip-top
[03:20] <jbowtie> xnox: Thanks, that makes everything clear. Will definitely start using join for a couple of projects.
[03:20] <xnox> jbowtie, your welcome =) I should blog about it ;-)
[03:23] <jbowtie> Hmmm...how do you provide tests for something that talks to a proprietary foreign VCS?
[03:30] <xnox> jbowtie, depends on which one.... =) but generally it is bzr protocol tests. And you right a test stub using bzr-test framework which does the intended behaviour. (documented, speced) etc... such that it can be run automated without having access to that VCS
[03:38] <jbowtie> xnox: Tricky. But just realised I can capture HTTP output and replay that during tests for the actual "talk to a VCS" class.
[03:38] <xnox> =) nice
[03:39] <xnox> which VCS are you working on? or is it top-secret?
[03:39] <jbowtie> Microsoft Team Foundation Server.
[03:39] <xnox> there have been issues with bitkeeper......
[03:39] <jbowtie> No secret, just ugly, ugly code.
[03:39] <xnox> jbowtie, aha =) that beast.
[03:40] <xnox> are you switching to bzr from that?
[03:40] <jbowtie> xnox: Yes, getting my team to, anyway. I can checkout and pull updates from TFS now.
[03:41] <xnox> jbowtie, publish code on lp. I'm pretty sure loads of people will find it useful
[03:41] <jbowtie> xnox: Pushing updates to TFS is possible but needs a bit more work so that round-tripping is a bit more solid.
[03:41] <xnox> jbowtie, is there bzr plugin for VS?
[03:42] <jbowtie> xnox: Just waiting for manager to sign off on publishing to Launchpad.
[03:42] <jbowtie> xnox: Not that I know of but project in question is using Eclipse anyway.
[03:42] <xnox> jbowtie, aha =) https://edge.launchpad.net/bzr-visualstudio
[03:42] <xnox> it's for 2005 though
[03:43] <jbowtie> xnox: Once I've published the TFS work I'll have a look at updating that.
[03:44] <jbowtie> I want to update the plugin developer's guide with info on writing a VCS plugin, but can't find it in launchpad.
[03:47] <jbowtie> Probably I'll just end up blogging it.
[04:01] <echo-area> hi, bzr 2.1.1 on windows doesn't print any messages in any command.  Does anybody know why?
[04:04] <echo-area> For example, when I do "bzr pull", the message "Using saved parent location..." is not printed; when I do "bzr pack", the message "repacking..." is not printed
[04:05] <echo-area> and bazaar.conf does not have likely related setting
[04:05] <jbowtie> echo-area: That's not what I'm seeing (just checked)
[04:05] <jbowtie> echo-area: Does bzr --version print anything?
[04:12] <echo-area> jbowtie: um, my description was a bit wrong.  Something is printed, but the other information is not.  "bzr --version" indeed prints version information.  But for "bzr pull", only the list of changes is printed, the information like "Using saved parent location..." and about the fetching progress is not printed.  For "bzr pack", nothing is printed
[04:15] <echo-area> and I remembered when I used bzr 2.1.0, that information was printed
[04:15] <jbowtie> echo-area: AFIAK that hasn't changed in 2.1.1 - certainly the saved parent thing is happening on my Windows box.
[04:16] <jbowtie> echo-area: Does a "bzr info" show that there is a saved parent?
[04:17] <jbowtie> echo-area: Don't forget, you can always use the verbose switch (-v), might mention something useful.
[04:18] <echo-area> jbowtie: I tried "bzr pack -v", but still, nothing is printed.  It's so strange
[04:18] <jbowtie> echo-area: The only thing that springs to mind is that one of your streams (stdout, stderr) is being redirected somehow.
[04:19] <jbowtie> echo-area: I've had that happen to me once or twice, where stuff printed to stderr got captured by a debug utility.
[04:19] <echo-area> jbowtie: I guess so, but how come a plain "bzr pack -v" redirects?
[04:21] <jbowtie> echo-area: No idea, and that's just a guess anyhow. Are you using PowerShell by any chance, or the standard command shell?
[04:22] <echo-area> jbowtie: I'm using C:\WINDOWS\system32\cmd.exe.
[04:23] <jbowtie> echo-area: Hmm. Maybe bzr pack has nothing to do?
[04:25] <echo-area> jbowtie: I don't know, but I guess not, since every time I run "bzr pack" on a Linux box, there is information printed.  But this is not a problem until now, so I think I can live with that
[04:28] <jbowtie> echo-area: OK. Let us know if you have any other issues, I can at least run a quick test on another Windows box for comparison.
[04:29] <dcoles> Hi. Can I pull from branches other than master with bzr-git?
[04:30] <echo-area> jbowtie: okay, thank you :)
[04:31] <dcoles> I tried 'bzr git-import' which gives me a tree, but then I can't push/pull after that.
[04:44] <jbowtie> dcoles: Are you trying to merge the changes from the other branch into yours, or switch to using it as your parent branch?
[04:46] <dcoles> jbowtie: Ideally, I just want to check it out to work on it and then be able to push changes to that branch
[04:47] <dcoles> Trouble I'm having is I can't think how to provide the branch in the git+ssh url
[04:48] <mwhudson> hm
[04:51] <jbowtie> dcoles: I'm not a git user; but looking at the documentation for bzr-git that might not be possible.
[04:51] <jbowtie> dcoles: Could you clone the git branch into another location, the use bzr to check that out?
[04:52] <dcoles> Yeah. I was worried about that. I even went to the extent of browsing the bzr-git sourcecode
[04:53] <dcoles> jbowtie: That might be the way of doing it. Just make sure you "checkout" the right git branch
[04:54] <dcoles> I'm not a git user either, but learning _far_ too much about it looking after a project's git repository ;)
[04:55] <mwhudson> bzr-git currently can only interact with the master branch in a git repo aiui
[04:56] <dcoles> mwhudson: Righto. That makes sense.
[05:39] <jbowtie> Is Bazaar 2.x packaged anywhere for RHEL?
[05:39] <dcoles> jbowtie: http://wiki.bazaar.canonical.com/DistroDownloads#CentOS/RHEL perhaps?
[05:40] <dcoles> Looks like it should already be in yum.
[05:40] <jbowtie> dcoles: That only has 1.3.1 - pretty old
[05:41] <dcoles> Ah. That's a shame. :S
[05:52] <jbowtie> And of course gcc is not installed on the RHEL box I want to install it on.
[05:56] <dcoles> I saw some rumors about it being included in RHEL6, but who knows when that is coming out
[05:57] <dcoles> One might assume it might be possible to nab from Fedora, but who knows what kind of dependancies that would try and drag with it.
[06:00] <jbowtie> dcoles: There's always the long way - spin up a CentOS image, install gcc, build the RPM, scp to the server, install. Bleh.
[06:00] <dcoles> Yuck. At least bzr is a reasonably nice package to build
[06:01] <jbowtie> Hopefully one of the lurkers will feel guilty enough to update the yum repository.
[06:02]  * jbowtie looks around for anyone with a guilty look.
[06:02] <dcoles> jbowtie: I tried the "git clone x, git checkout branch; bzr branch x y" method. It works. But you have to do a 'git reset --hard' after you dpush back.
[06:03] <dcoles> And using bzr in the git repo seems to crash bzr when I try and commit (not sure if that's a legal use of bzr or not)
[06:03] <jbowtie> dcoles: Important thing is that you are not stuck, glad I could help with that much.
[06:04] <dcoles> :)
[06:04] <dcoles> I could always just use git.... blehgh
[06:04] <jbowtie> dcoles: I'll keep an eye on the Bazaar blueprints during UDS, maybe we can get someone to do something about that.
[06:05] <dcoles> Well, I think the current block was "colocated branches"
[06:06] <jbowtie> dcoles: Personally I'll probably work on cleaning up the documentation, it's getting a little hard to find details I need.
[06:06] <dcoles> But even just being able to do bzr co git+ssh://example.com/repo#branch would be quite nice.
[06:07] <dcoles> Indeed. I've been pestering jelmer about a lot of the bzr-git stuff.
[06:07] <dcoles> There's also quite a few references to bzr-git being "read only", despite having dpush now.
[06:09] <dcoles> I'd love to sit down and hack on the plugin one afternoon. It's really neat except for one or two little bugbears.
[06:17] <jbowtie> dcoles: It's not like you need commit access.  ;)
[06:18] <jbowtie> Whoops, gotta go, have a train to catch.
[06:19] <dcoles> Cya
[06:19] <dcoles> Whoops. Too late.
[07:45] <vila> hi all
[08:29] <sivang> hi all
[08:29] <sivang> how come, that in my working copy I get the latest revision when doing bzr log
[08:29] <sivang> and when I go the parent branch,
[08:29] <sivang> then it shows a couple of revisions back?
[08:30] <sivang> (sorry for using CRLF as punctuation)
[08:34] <xnox> sivang, ? what does `bzr status` show in both directories?
[08:34] <xnox> and what is bzr info in both of them
[08:58] <sivang> xnox: let me check
[10:22] <sivang> xnox: in one dir, a bunch of unknowns
[10:25] <sivang> xnox: in the other :
[10:25] <sivang> :~/ccforms_renamed$ bzr status
[10:25] <sivang> bzr: ERROR: No WorkingTree exists for "file:///home/sivan/ccforms_renamed/.bzr/checkout/".
[10:26] <xnox> sivang, so looks ok to me. Depending on what you are trying to do
[10:26] <xnox> and what type of checkout you use
[10:27] <xnox> sivang, if you do `bzr info` in both of them it should tell you what are the relationships, if any, between those two branches
[10:27] <sivang> xnox: so the one that does now show all the revision in log, is the push target of the working copy
[10:28] <fullermd> I wouldn't assume he's using [explicit] checkouts at all.  It just sounds like he's got two branches that are at different places, which is...   well, normal.
[10:28] <sivang> xnox: how can I make it show all the revision, since when I check out from it or bracnh, it doesn't get revision up to the last one
[10:28] <fullermd> Why do you think they SHOULD have the same revs?
[10:28] <sivang> fullermd: I use the push target is the parent branch or repo
[10:28] <sivang> fullermd: or am I not?
[10:28] <fullermd> Sure, but did you push them?
[10:28] <fullermd> 'missing' is also your friend here.
[10:28] <xnox> sivang, what do you mean by "working copy" - checkout, lightweight checkout, or branch?
[10:29] <sivang> xnox: okay, so I see bzr lingo thickens the plot a bit
[10:29] <sivang> xnox: I init'd a a dir
[10:29] <sivang> xnox: commited into it
[10:29] <sivang> xnox: and then pushed to a "backup" location
[10:30] <sivang> oops
[10:30] <sivang> forgot to push
[10:30] <sivang> geez
[10:30] <sivang> now it is synced
[10:30] <xnox> sivang, =)
[10:30]  * sivang turns to be the lolipop figure in Bugs Bunny film
[10:31] <sivang> xnox: so, is there a book ? an oreilly book already so learn all things bzr from start to finish ?
[10:31]  * sivang googles for the difference between a checkout, lw checkout and bracnh
[10:31] <sivang> there's is no repo notion right?
[10:31] <sivang> (like in svn)
[10:32] <xnox> sivang, http://doc.bazaar.canonical.com/bzr.2.1/en/
[10:32] <sivang> but still, if I have a parent branch
[10:32] <xnox> sivang, yes there is but a lot different from svn
[10:32] <sivang> parent branch: /home/sivan/ccforms_renamed
[10:32] <xnox> sivang, do this
[10:32] <sivang> xnox: I remember lifeless talking lots about the difference
[10:32] <xnox> in a temporary location
[10:32] <xnox> $ bzr init-repo .
[10:32] <xnox> $ bzr info
[10:33]  * sivang tries
[10:33] <xnox> $ bzr init branch-a
[10:33] <sivang> shared repo with trees? what does that mean?
[10:33] <xnox> $ cd branch-a && bzr ci --unchanged -m "my first commit"
[10:33] <xnox> $ cd ../
[10:34] <xnox> $ bzr checkout branch-a branch-b
[10:34] <xnox> $ bzr info branch-b
[10:34] <xnox> $ cd branch-a
[10:34] <xnox> $ bzr ci --unchanged -m "checkout branch-b should be out-of date now"
[10:34] <xnox> $ bzr info branch-b
[10:34] <xnox> $ bzr status branch-b
[10:35] <xnox> Checkout of a branch is similar to svn, where commits in the checkout will end up in the branch
[10:35] <sivang> xnox: okay, so what I was looking actually instead of just a branch, is to creat e a repo and so commits will work against it?
[10:36] <sivang> xnox: I wanted commits from the local machine, and from another remote machine to end up in the same source tree
[10:36] <sivang> xnox: with revisions and everything
[10:36] <sivang> xnox: so I can either work on my desktop or from the remote server transparently
[10:37] <xnox> sivang, that would be dangerous cause you might override working tree on the server & desktop
[10:37] <xnox> sivang, what you should do is this
[10:37] <sivang> xnox: I want to have a working tree at a seperate location
[10:37] <xnox> 1) create a branch on the sever
[10:37] <sivang> xnox: just a "shared repo" is that the right term?
[10:38] <xnox> sivang, repo is where the revisions are stored but repo still has to have branches in it so that there is a *named* location to push to.
[10:38] <xnox> So on the server create a repo & branch underneath it
[10:38] <xnox> when you are on the desktop do $ bzr checkout $URL-branch-on-server
[10:39] <xnox> when you are on the server do $ bzr checkout /path/to/branch/on/server
[10:39] <xnox> Always commit to checkouts *of* the branch on server
[10:39] <xnox> this way whenever you make or update a checkout you will get latest code from your "central" branch
[10:40] <xnox> sivang, http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/central_intro.html
[10:42] <sivang> xnox: I see, but when commiting to a checkout that means commiting to the .bzr inside the workign copy
[10:42] <sivang> xnox: how do I get those updates to the parent branch in the central repo ?
[10:42] <xnox> sivang, no it will commit on the server
[10:42] <sivang> xnox: ok, I will dio some reading :)
[10:42] <xnox> sivang, if you look into the .bzr dir inside you will notice it has three major folders:
[10:43] <sivang> xnox: bzr got some feature rich since last time I used it for hubackup
[10:43] <xnox> repository, branch, checkout
[10:43] <sivang> yes
[10:43] <sivang> even when I jsut init a dir,
[10:43] <xnox> in the repository it stores raw bytes, in the branch it stores references as to which revision this branch points at and in checkout it stores the current status of the working tree
[10:43] <sivang> which means I created a new branch right?
[10:43] <xnox> when you do $ bzr init it creates all three
[10:44] <xnox> when you do $ bzr init-repo DIR
[10:44] <xnox> it will create $ DIR/.bzr/repository
[10:44] <xnox> such that all branches underneath $ DIR store there bytes together & efficiently sharing them
[10:44] <xnox> when you do $ bzr checkout $URL
[10:45] <sivang> the docs are nice muchly improved
[10:45] <sivang> xnox: I create a mirror of the branch ?
[10:45] <sivang> so to speak
[10:46] <xnox> it will place bytes in a shared-repo if present, and then create a working directly (checkout) with no separate branch. Intead it will put reference "saying when I commit in this working tree, take my local bytes but commit in the target branch"
[10:46] <sivang> ah
[10:46] <sivang> cool, so like a mirror
[10:46] <xnox> yes
[10:46] <sivang> xnox: thanks dude
[10:46] <xnox> sivang, furthermore you can have lightweight-checkouts
[10:46] <sivang> xnox: which are?
[10:47] <xnox> those do not have their own repository and are usefull when you are working with large repositories
[10:47] <fullermd> Don't get hung up on the difference between light and heavy checkouts...
[10:47] <sivang> do the significance of a repo is just to share bytes?
[10:47] <fullermd> Heavies make a local cache of the revs; lights don't.
[10:47] <xnox> then you will have a tree-less repository such that all branches do not have working tree in them (cause it's a 100MiB big)
[10:47] <sivang> right , so for large repos heavy are better
[10:47] <fullermd> You probably only want to use a light checkout when the branch is on the local disk, or possibly close by on a very fast network.
[10:48] <xnox> and you will have one lightweight checkout which just represents a working-tree attached to a particular branch. And then you can do $ bzr switch
[10:48] <sivang> fullermd: right, so when I work on the server, light-checkout
[10:48] <xnox> to jump from one branch to another
[10:48] <sivang> fullermd: on the desktop at home, heavy
[10:48] <xnox> sivang, yes repo is to share bytes
[10:48] <sivang> xnox: this is different from svn so deeply
[10:48] <sivang> xnox: a repo is a dir mostly there :)
[10:49] <xnox> sivang, locally. Two repositories with bytes never will mirror each other. You can only push branches around which will take the bytes with them & put their bytes in the repos
[10:50] <sivang> xnox: so when I init'd the local folder I worked on, and then pushed it to my backup location, what was the relationsip and what happened between them?
[10:50] <xnox> sivang, you got heavy & light right
[10:50] <xnox> sivang, you have (branch & repo & checkout)    <----->  (branch & repo)
[10:51] <xnox> unless you did $ bzr co /path/to/branch on the server
[10:51] <sivang> xnox: so due to the face that there was no relationship between them, just a push target, revision did not automatically got updated at the push target
[10:51] <xnox> then you have (branch & repo & checkout) <-----------> (branch & repo & checkout)
[10:51] <xnox> sivang, "not automatically" on commit on either of them
[10:51] <sivang> xnox: what causes the automatic update relationship to occur ?
[10:52] <fullermd> Thinking of automatic vs. non-auto is likely to wind up more confusing.
[10:52] <fullermd> When you make a commit, it goes onto the branch you're working on.  So the question is always, what branch am I working on?
[10:52] <xnox> (repo & checkout )   <------------> (branch & repo)   <----------------->   (repo & checkout)
[10:52] <fullermd> If you have a checkout, the branch is the thing you `bzr co $THING`'d.
[10:53] <fullermd> If you did a `bzr branch $THING`, your local dir is its own branch.
[10:53] <sivang> fullermd: right, okay it starts to be clearer now
[10:53] <xnox> fullermd, yeap nice explaination
[10:53] <fullermd> 'push' and 'pull' are commands you use to move existing revs from one branch to another.
[10:53] <sivang> fullermd: nice, so back to DRCS
[10:53]  * xnox says what's DRCS?
[10:54] <sivang> Distributed revisionc ontrol
[10:54] <sivang> the co and repo is the bzr support for centreal rc
[10:54] <sivang> no ?
[10:54] <fullermd> That's one way of thinking about it...
[10:54] <fullermd> Better, though, to think of it Branch-centric.
[10:54] <sivang> and working with branches is good'o distributed, when you have a merge action between them
[10:55] <xnox> sivang, yeap. If you have one branch on the server and you have multiple checkouts it's like having svn server & checkouts
[10:55] <fullermd> Using co is a way to get multiple working trees all on a single branch.
[10:55] <sivang> cool
[10:55] <sivang> thank yo guys!
[10:55] <sivang> Are you with Canonical btw?
[10:55]  * xnox no
[10:55] <fullermd> Which is similar to what you do with a centralized system.  But thinking of it around branches probably keeps things straighter.
[10:55] <fullermd> You may want to peruse some of the stuff at http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs
[10:56] <fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief particularly for some background vocabulary, and http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevHandling for some talk about push/pull/etc.
[10:58] <sivang> fullermd: thanks, irssi logged it and I shall read it!
[10:58] <sivang> now , off to lunch.
[12:02] <jbowtie> Which Launchpad project do I need to contribute to the documentation?
[12:04] <bialix> documentation of bzr?
[12:04] <bialix> ok
[12:05] <bialix> jbowtie: documentation of bzr?
[12:05] <jbowtie> Yes, documentation of Bazaar. I want to clean up a few of the less maintained corners.
[12:05] <jbowtie> Those empty sections in the admin guide also bug the heck out of me.
[12:08] <faceprint> is there a way to make 'bzr commit' not throw an error if there's nothing to commit, without allowing it to commit an empty revision?
[12:09] <Peng_> jbowtie: There's a bzr-doc team with a mailing list, but it's just handled through the normal bzr project.
[12:09] <faceprint> we spent the weekend converting from CVS, and we were taking advantage of the fact that cvs will gladly do nothing when nothing has changed in a bunch of our automated scripts
[12:09] <Peng_> jbowtie: File bugs, file merge proposals, whatever.
[12:09] <Peng_> faceprint: Ahh... That's a pretty obscure request, and I doubt bzr has a knob somewhere to do it.
[12:10] <jbowtie> Peng_: Sorry, are you saying the docs are somewhere in the bzr source tree?
[12:10] <Peng_> jbowtie: Yes.
[12:10] <jelmer> faceprint: I'm not sure I understand what you're asking for?
[12:10] <Peng_> jbowtie: Not, like, the wiki, but most of the documentation is.
[12:10] <jelmer> faceprint: --unchanged is not what you're after?
[12:10] <Peng_> jelmer: I think what he's after is that he wants the exit code to be 0 even if nothing has changed.
[12:11] <Peng_> faceprint: Probably not hard to write some Python to accomplish that, but...
[12:12] <faceprint> jelmer: i have scripts that grab the latest versions of certain files, or re-compute certain files (yes, this is kind of an abuse of version control, but it's what we have), and then commit them if there are changes.  We had been just running cvs commit after generating the new version, and if there were changes they got committed.  If the files ended up identical, everything just exited silently
[12:12] <faceprint> if I use --unchanged, I'm going to add another 10 or so revisions to my repository every morning with empty commits
[12:12] <jbowtie> Peng_: OK, I see the admin guide, but not the plugin developer's guide.
[12:14] <jelmer> faceprint: you could do some scripting to find out if there are any changes to commit
[12:15] <faceprint> yeah, I started down that path, and realized that bzr stat doesn't seem use return codes at all, so I'm actually going to have to look at its output
[12:15] <faceprint> it isn't a huge deal, and honestly if this is the only hiccup in this transition, i'm a very happy guy (knock on wood)
[12:16] <jbowtie> Peng_: That can't be everything. The migration guides for users of other VCS, plugin docs, plugin developer guide - none of that's in the bzr tree.
[12:16] <xnox> faceprint, $ bzr commit returns exit code 3 when there is nothing to commit
[12:16] <xnox> e.g. pointless commit
[12:16] <jbowtie> And why is there a project called bzr-alldocs that doesn't contain all docs?
[12:16] <faceprint> xnox: which doesn't help me in deciding whether to run bzr commit or not ;-)
[12:17] <xnox> faceprint, just run it and catch and check that exit code. Or is there someother logic apart from "when changes -> commit; when no changes -> do not commit"
[12:17] <bialix> jbowtie: bzr-alldocs is for bazaar.canonical.org website
[12:18] <faceprint> really, I'm just trying to avoid cron email from all these scripts, but don't want to send stderr to /dev/null in case something actually IS wrong
[12:18] <xnox> faceprint, ok another one $ bzr diff exits 0 if there is no diff, exits with 1 if there is diff and hence there are changes
[12:18] <xnox> faceprint, is this better?
[12:19] <faceprint> ah, that'll work.  don't know why I didn't think of diff earlier
[12:19] <jbowtie> bialix: OK, so documentation is split up across multiple sites?
[12:20] <jbowtie> No wonder the docs are such a mess.
[12:20] <bialix> jbowtie: which kind of documentation?
[12:20] <xnox> faceprint, if you generate new files you will need to somehow add them to the tree though
[12:20] <bialix> jbowtie: if you can do better, please do
[12:20] <faceprint> luckily these are just existing-file changes i'm concerned with
[12:20] <faceprint> thanks for your help!
[12:20] <xnox> jbowtie, all documentation is linked from bazaar.canonical.com. There a few small about developing bzr inself in the bzr source tree.
[12:20] <bialix> jbowtie: part of documentation is auto-generated from online help (bzr help xxx)
[12:21] <sivang> back
[12:22] <jbowtie> xnox: I think that's where I'm getting confused.
[12:23] <jbowtie> I see 14 categories on the Documentation Table of Contents.
[12:23] <xnox> jbowtie, go there click documentation and that's the full maintained, canonical location for all documentation.
[12:23] <jbowtie> I see 8 categories in the bzr source tree.
[12:23] <jbowtie> So where are the other 6 categories sourced from?
[12:24] <xnox> jbowtie, from the doc-strings within the codebase inside bzrlib/
[12:24] <xnox> in each command / function
[12:24] <bialix> jbowtie: are we talking about http://doc.bazaar.canonical.com/bzr.2.1/en/ ?
[12:24] <jbowtie> bialix: Yes.
[12:25] <xnox> jbowtie, well FAQ & BzrGlossary are just links to random pages online and are not real docs
[12:25] <jbowtie> If I want to correct something in both the "System Admin Guide" and the "Developer Docs", where do I go to edit that?
[12:25] <bialix> jbowtie: Core documentation coming from bzr sources
[12:25] <bialix> Related links from other places
[12:26] <bialix> jbowtie: core docs coming from bzr_tree/doc/end
[12:26] <bialix> jbowtie: core docs coming from bzr_tree/doc/en
[12:26] <bialix> sorry
[12:26] <Peng_> jbowtie: Ooh! I thought there was a project, but I couldn't find it when I checked.
[12:26] <jbowtie> bialix: OK, so the "System Admin Guide" is in the bzr tree, since it's in the core section.
[12:27] <bialix> jbowtie: correct
[12:27] <bialix> doc/en/admin-guide
[12:27] <jbowtie> bialix: But how do I track down the 6 "Related Links" projects? Or are they not in Launchpad anywhere?
[12:27] <bialix> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/doc/en/
[12:28] <bialix> jbowtie: look at the links
[12:28] <Peng_> xnox & faceprint: 'bzr diff' doesn't show executable bit changes, so it might not include them in the exit code either...
[12:28] <bialix> jbowtie: Desktop Guide coming from Bazaar Explorer
[12:28] <bialix> FAQ is launchpad page
[12:28] <bialix> Glossary is wiki page
[12:28] <bialix> Developer Docs again from bzr tree
[12:29] <jbowtie> bialix: Wait, what? Where are the Developer Docs?
[12:29] <bialix> wanna screenshot?
[12:30] <bialix> here is http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/doc/developers/
[12:30]  * bialix is not sure where from coming migration and plugins guide
[12:30] <bialix> igc is our docs master, but he's offline this week
[12:30] <jbowtie> bialix: Well, that's somewhat more helpful.
[12:31] <bialix> you can send the question to the ML though
[12:31] <bialix> maybe jam knows
[12:31] <jbowtie> bialix: But of course the Plugins Guide was the one I had a big patch for since I just wrote a plugin.
[12:31] <bialix> (... or poolie)
[12:32] <xnox> bialix, bzr/doc/en/upgrade-guide$ for the migration guide
[12:32] <bialix> xnox: thx
[12:33] <bialix> jbowtie: here is plugin guide sources http://bazaar.launchpad.net/~bzr/bzr-alldocs/trunk/files/head%3A/plugins/en/
[12:33] <jbowtie> xnox: That isn't right, the Survival Guide doesn't exist at all in that location.
[12:33] <xnox> 4	./doc/en/user-guide/plugins.txt
[12:33] <xnox> 4	./doc/en/user-guide/writing_a_plugin.txt
[12:34] <bialix> I guess other docs need to look in the alldocs first
[12:34] <xnox> My links are *from* the bzr tree
[12:34] <xnox> so which once are we still missing?
[12:34] <jbowtie> bialix: Umm. OK. So "alldocs" only has the Plugin Guide?
[12:35] <xnox> so far I have found everything in the tree
[12:35] <xnox> jbowtie, Plugin Guide is in the just *bzr* tree
[12:35] <bialix> xnox: is not true
[12:35] <bialix> xnox: http://bazaar.launchpad.net/%7Ebzr/bzr-alldocs/trunk/annotate/head%3A/plugins/en/plugin-development.txt
[12:36] <jbowtie> xnox: Part of the problem is that not all the docs are in the tree.
[12:36] <jbowtie> xnox: Otherwise I would be less confused. I hope.  :)
[12:36] <jbowtie> xnox: There is some double-up of coverage.
[12:36] <bialix> jbowtie: will be nice if you collect this info on the wiki.bazaar.cacnonical.com, if you don't mind
[12:37] <jbowtie> bialix: Will do; am logging this and will update the wiki in the morning (very late night in my time zone).
[12:38] <bialix> jbowtie: cool, thanks
[12:38] <jbowtie> bialix: So if I track down the source for the "Migration Guide" - especially the "Survival Guide" subsection, we'll know where everything is.
[12:38]  * bialix nods
[12:42] <jbowtie> bialix, xnox: Thank you both very much, kept me from giving up on contributing documentation.
[12:42] <xnox> jbowtie, i've never seen Survival Guide ever before
[12:42] <xnox> WTF =) this needs fixed
[12:42] <jbowtie> xnox: You probably didn't need it.  :P
[12:44] <jbowtie> All right, I'm off to bed, will update the wiki in the local morning hopefully to be followed by merge requests.
[12:46] <xnox> there is this page as well http://bazaar.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk/files/head:/en
[13:27] <tetsuo--> Does bazaar support this: i have 2 folders, one contains patches to an upstream, the 2nd contains the upstream, bazaar should automatically apply the patches every time the upstream folder gets synced with the upstream
[13:28] <xnox> tetsuo--, create third dir use $ bzr patch patch1 patch2 patch3
[13:28] <tetsuo--> can that be automated like with git?
[13:29] <xnox> tetsuo--, merge this with your "2nd dir contains the upstream"
[13:29] <xnox> and then in that dir do $ bzr merge upstream
[13:29] <xnox> tetsuo--, are you asking for topgit functionality or quilt like or what? =) what do you mean "like git"?
[13:30] <xnox> generally even in git you apply patches on e.g. master, you upstream gets fetched into origin/master. And then you have master tracking origin/master which gets autopulled.
[13:30] <tetsuo--> i have never done it, but i have been told that in GIT you can merge upstreams into the "2nd folder" and GIT will automatically use the upstream and downstream changelog to merge in all the patches from the first dir
[13:32] <xnox> tetsuo--, well you want the pipeline plugin!
[13:32] <xnox> you will do $ bzr co --light upstream pipeline
[13:33] <xnox> $ cd pipeline
[13:33] <xnox> $ bzr add-pipe patch1
[13:33] <xnox> $ bzr patch patch1
[13:33] <xnox> $ bzr ci
[13:33] <xnox> $ bzr add pipe patch2
[13:33] <xnox> rince repeat
[13:33] <xnox> then you do $ bzr switch :first
[13:33] <xnox> then you fetch upstream by pulling
[13:33] <xnox> and to apply all patches you do
[13:34] <xnox> $ bzr pump
[13:34] <xnox> tetsuo--, launchpad.net/bzr-pipeline
[13:34] <xnox> and there is wiki link from there
[13:35] <tetsuo--> ill read that
[13:42] <tetsuo--> i should have asked my question differently
[13:42] <tetsuo--> how can i easily and simply maintain a local fork of an upstream project
[13:43] <tetsuo--> its a fork because i have custom patches that dont make any sense to upstream
[13:43] <xnox> tetsuo--, aha then you simply $ bzr branch $UPSTREAM
[13:43] <xnox> commit your patches as regular commits
[13:44] <xnox> and then everytime you want to sync with upstream you do $ bzr merge $UPSTREAM
[13:44] <xnox> where $UPSTREAM can be git/hg/svn/local branches
[13:44] <xnox> where $UPSTREAM can be git/hg/svn/local branches/ and ofcourse bzr
[13:45] <xnox> If there are conflicts it will show you which files are conflicting
[13:45] <tetsuo--> nice
[13:45] <tetsuo--> so it will only complain if things break
[13:46] <xnox> If there are no conflicts you can just commit to record this merge.
[13:46] <xnox> Or you can tweak it further etc. do whatever you like
[13:46] <xnox> =)
[13:46] <tetsuo--> ok
[13:46] <xnox> tetsuo--, any any point at time you can see which commits were yours and which are from upstream using $ bzr missing
[13:46] <xnox> and $ bzr annotate
[13:46] <tetsuo--> the reason it needs to be simple and easy is because the people who do this are not programmers themselves
[13:47] <xnox> will tell you line by line who committed what in the file so you can see whether it was you who done it
[13:47] <tetsuo--> ok so i dont need to keep the patches seperately after the first merge?
[13:47] <xnox> tetsuo--, no
[13:47] <tetsuo--> (please note i dont use bazaar right now, we use svn)
[13:47] <xnox> you will have just one branch
[13:47] <tetsuo--> ok
[13:47] <xnox> tetsuo--, which platform are you on
[13:48] <xnox> cause there is torgotaiseBzr (or whatever it is) for windows and on other platforms we have plugins as well so that it's all point & click
[13:48] <tetsuo--> windows
[13:49] <xnox> tetsuo--, create branch. Commit patches. Push that branch to everyone who needs it.
[13:49] <xnox> Install https://edge.launchpad.net/tortoisebzr
[13:49] <naoki^>  tetsuo--: Are you Japanese?
[13:50] <xnox> tetsuo--, and then they will be able to point & click to get new updates
[13:50] <xnox> and will be told if there are conflicts
[13:50] <naoki^> tetsuo--: FYI, There is a Japanese ML http://groups.google.co.jp/group/bazaar-ja
[13:52] <naoki^> I'm not good at English. If you too, we can talk in Japanese at the ML.
[13:53] <tetsuo--> naoki^:  no im dutch
[13:54] <tetsuo--> xnox: how about outdated stuff, like files that are removed upstream
[13:54] <tetsuo--> will they be removed downstream too?
[13:55] <xnox> tetsuo--, yeap
[13:55] <tetsuo--> and if that particular file contains one of my patches it will throw a conflict?
[13:55] <xnox> tetsuo--, no it will get deleted
[13:55] <tetsuo--> oh noes!
[13:55] <xnox> tetsuo--, but not that soon
[13:56] <xnox> tetsuo--, after you merge you will see the changes
[13:56] <xnox> what's going on eg. added files, deleted files, conflicted files
[13:56] <tetsuo--> do deleted files keep their history in bazaar?
[13:56] <xnox> if you are happy with the result you commit it
[13:56] <xnox> tetsuo--, yes
[13:56] <xnox> tetsuo--, you can reincornate any file from any revision without hitting the network on your local machine
[13:57] <tetsuo--> sometimes code is refactored, and the file moves froom foo.cpp to fooa.cpp and foob.cpp, will my patch move to the right file?
[13:57] <xnox> tetsuo--, you just do $ bzr revert -rNN (for whole tree) or you can maintain a delete file like thie $ bzr revert -rNN path/to/file
[13:58] <xnox> tetsuo--, yes the patch becomes history. Bzr looks at your history & at the upstream history. So when upstream moves a file, your files is moved/copied with patched lines still applied
[13:58] <xnox> so if upstream renames file then it your patched file will travel with it.
[13:59] <xnox> tetsuo--, go to terminal create 2 branches and experiment with a sample. commit stuff to a branch "upstream" pull into your "local" branch apply some patches
[13:59] <tetsuo--> what about > del foo.cpp , add fooa.cpp, add foob.cpp, the lines i was patches are deleted in foo.cpp and reintroduced in foob.cpp along with a bunch of new code
[13:59] <xnox> and experiment what happens when you do stuff on the upstream branch and merge back into "local" branch
[14:00] <tetsuo--> ok
[14:00] <xnox> tetsuo--, try out in the terminal =) it depends on which VCS upstream is using and what bzr will decide to do
[14:01] <xnox> tetsuo--, personally I've been hacking with bzr on more than 100 opensource projects and none of my patches / commits have been lost in the process of merging new stuff
[14:02] <xnox> tetsuo--, there was a couple of times when bzr didn't realise what happened but it didn't cover it up but threw a merge conflict on me. But it was obvious for me to see what happened and why bzr couldn't merge it
[14:02] <tetsuo--> ok
[14:02] <xnox> tetsuo--, so from that point of view.  Backup your branch with commits somewhere and you are done
[14:02] <tetsuo--> i actually need some help setting this up, if you want the challenge of seeing if it breaks with my project, lol :D
[14:03] <xnox> tetsuo--, ping me any time you like ;-) i'm also launchpad.net/~dmitrij.ledkov for contact details
[14:03] <xnox> tetsuo--, generally I think you want to have a maintainer who pulls & merges new upstream. And then pushes that branch to a local repository which all of your users consume straight away
[14:04] <xnox> such that you have a maintained copy of software internally
[14:04] <tetsuo--> i have no idea what that means :s (we use sourceforge for our code hosting)
[14:06] <tetsuo--> http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/transform/MPCVideoDec/ffmpeg  << this is our patched fork of http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/ which is a patched fork of http://git.ffmpeg.org/?p=ffmpeg;a=tree
[14:07] <tetsuo--> as you can see our patches are not seperate but mixed in, and mostly undocumented in the changelog
[14:08] <tetsuo--> and ffmpeg tends to refactor stuff once in a while, so files either get split up or merged all the time
[14:10] <tetsuo--> any chance of bzr client making it easier to extract the patches from that mess?
[14:15] <xnox> tetsuo--, yeap
[14:16] <tetsuo--> xnox:  any tips for my first import?
[14:16] <tetsuo--> i enabled bazaar on sourceforge
[14:16] <tetsuo--> and want to import the svn tree with as much history data as possible
[14:17] <xnox> tetsuo--, that's easy install bzr-svn plugin and just do $ bzr branch $URL_SVN
[14:17] <xnox> tetsuo--, but i fear that fork of fork, the original fork and the upstream do not share history
[14:18] <tetsuo--> they dont
[14:18] <xnox> do you still need to pull updates from the "middle" fork or no?
[14:18] <tetsuo--> if i can extract those patches ones i wont
[14:18] <tetsuo--> once
[14:18] <tetsuo--> but we are not in sync
[14:18] <xnox> right.
[14:19] <xnox> it's a toughy here =)
[14:19] <xnox> do you have email?
[14:19] <tetsuo--> our fork is behind about 2 weeks, on the middle one, which is behind a week on the upstream
[14:19] <xnox> i'll play around with these branches and see what I can come-up with
[14:19] <tetsuo--> thanks
[14:19] <tetsuo--> i dont use email
[14:19] <xnox> tetsuo--, =)))) ok
[14:19] <tetsuo--> do you have a sourceforge account?
[14:20] <xnox> tetsuo--, yes
[14:21] <tetsuo--> do you prefer tickets or forum?
[14:21] <xnox> tetsuo--, dmitrijledkov
[14:21] <xnox> tetsuo--, I haven't used any =) I'll pick tickets
[14:21] <tetsuo--> http://sourceforge.net/apps/trac/mpc-hc/timeline
[14:22] <tetsuo--> you can add a ticket there with the results
[14:30] <tetsuo--> i installed the gui
[14:30] <tetsuo--> i should make a branch of the svn tree right?
[14:30] <tetsuo--> i have the plugin
[14:35] <xnox> tetsuo--, yeap.
[14:35] <xnox> I got to go now. I will post on sourceforge tonight late in the evening
[14:46] <tetsuo--> i get an error
[14:46] <tetsuo--> Unable to import library "launchpadlib": No module named launchpadlib, Unable to load plugin u'pipeline' from u'C:/Program Files (x86)/Bazaar/plugins'
[14:47] <jelmer> tetsuo--: did you manually install the pipeline plugin?
[14:48] <tetsuo--> no
[14:48] <tetsuo--> i just used the windows installer
[14:50] <xnox> jelmer, Bug 569934
[14:50] <jelmer> xnox: hi Dmitrijs
[14:50] <jelmer> tetsuo--: it's probably a bug in the windows installer in that case, I suspect
[14:50] <xnox> jelmer, I'm using waf which is nice python based system and for my upstream I just want to run "version-info --python" get that stream
[14:50] <tetsuo--> aww :(
[14:51] <xnox> jelmer, and import it inside waf and get svn-* info as a nice dict to add add in all C headers =)
[14:51] <jelmer> xnox: I don't think abusing the rio hook for that is valid
[14:51] <jelmer> xnox: at least not without changing the hook code to be generic and indendent of rio
[14:52] <xnox> jelmer, well I've tried using svn-keywords and it gives me $ Id: (evoluation error) $
[14:52] <xnox> my hacked up version of regular bzr-keywords does work but it erases working tree changes after $ bzr uncommit which is, well ugly & bad
[14:53] <xnox> jelmer, renegalising hook to regular version info which all formatters subclass?
[14:53] <tetsuo--> xnox:  do i need the pipleline plugin to be able to import svn into a bazaar tree?
[14:54] <jelmer> xnox: something like that
[14:54] <jelmer> tetsuo--: no, you don't need pipelines for that
[14:54] <jelmer> xnox: can you file a bug about the keywords issue?
[14:55] <xnox> jelmer, sure
[14:55] <tetsuo--> ok deleting pipelines makes it work
[14:56] <xnox> jelmer, BTW found out about svn-keywords yesterday even though it's been around for ages =) needs docs & blogging
[14:58] <tetsuo--> should i create a shared repository?
[14:59] <jelmer> tetsuo--: up to you, shouldn't matter for the import
[14:59] <tetsuo--> ok
[15:00] <tetsuo--> ok its working
[15:00] <jelmer> xnox: I'd like it to integrate with bazaar itself better
[15:00] <tetsuo--> holy moly bazaar-svn-client is fast
[15:01] <xnox> jelmer, hmmmm so do I need to echo "svn-keywords = "Id Rev" into ~/.bazaar/rules or no for eg. [names *]
[15:02] <xnox> tetsuo--, and you get whole history =) as well ;-)
[15:02] <tetsuo--> toirtoisesvn only goes like 10kb/s max, the bazaar client is maxing out my download speed
[15:02] <tetsuo--> bzr: ERROR: Unable to convert Subversion path trunk\src\apps\ShuttlePN31 because it contains characters invalid in Bazaar.
[15:03] <xnox> tetsuo--, ask jelmer about that or search on launchpad.net/bzr-svn
[15:03] <jelmer> tetsuo--: does that path exist as a filename in your repository?
[15:03] <jelmer> tetsuo--: where the \ is part of the name, not used as a separator?
[15:04] <jelmer> xnox: yeah, you have to edit ~/.bazaar/rules or .bzrmeta/rules
[15:04] <tetsuo--> jelmer:  i dont see it in the current revision
[15:04] <tetsuo--> its not on  the svn afaik
[15:06] <tetsuo--> jelmer:  take a look here: https://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/apps
[15:07] <jelmer> tetsuo--: what svn URL are you trying to import?
[15:08] <tetsuo--> https://mpc-hc.svn.sourceforge.net/svnroot/mpc-hc
[15:22] <tetsuo--> jelmer: any luck?
[15:22] <jelmer> tetsuo--: still in progress
[15:22] <tetsuo--> ok
[15:39] <tetsuo--> jelmer:  what speed are you getting
[15:40] <jelmer> tetsuo--: varies wildly
[15:41] <tetsuo--> i was getting steady 600kb/s
[15:43] <tetsuo--> i actually retried 3 times since giving you that link :s
[15:47] <jelmer> tetsuo--: it imports fine here, no errors
[15:47] <tetsuo--> wth
[15:47] <tetsuo--> ok somethign is wrong here
[15:47] <tetsuo--> i use the gui
[15:48] <tetsuo--> lets try commandline
[15:48] <tetsuo--> what did you use?
[15:48] <jelmer> tetsuo--: bzr svn-import
[15:48] <jelmer> (on the command-line)
[15:49] <jelmer> that shouldn't really matter though..
[15:49] <tetsuo--> this is what the gui does
[15:49] <tetsuo--> Run command: bzr branch https://mpc-hc.svn.sourceforge.net/svnroot/mpc-hc D:/mpc-hc/trunk --use-existing-dir
[15:49] <jelmer> tetsuo--: that's lacking a /trunk on the end of the first url
[15:49] <tetsuo--> it does this first: Run command: bzr new --shared-repository --format 2a D:/mpc-hc/trunk
[15:50] <tetsuo--> retry with modified url
[15:59] <tetsuo--> jelmer:  looks like its working now, and its super slow again :(
[16:22] <tetsuo--> got it!
[16:23] <tetsuo--> lol bazaar client crashed
[16:23] <bialix> somebody confirm my understanding: post_commit hook invoked after the local commit succeed?
[16:23] <tetsuo--> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'startswith'
[16:24] <bialix> pstebin
[16:24] <bialix> pastebin
[16:25] <tetsuo--> http://pastebin.com/n5kxTfsX
[16:26] <tetsuo--> after ignoring that error it seems to work now
[16:27] <tetsuo--> ok so my bzr client now has a full local bazaar branch of the svn, how can i push it exactly like this to sourceforge?
[16:28] <a212901390231901> looks like a genuine bug, shame can't see what put the bum entry in the registry from that stack
[16:29] <bialix> tetsuo--: how you managed to get this error?
[16:30] <tetsuo--> using the windows client with pipeline plugin deleted, i created a branch from my svn project, then i went to a subfolder and did "rightclick --> Show log"
[16:30] <tetsuo--> it generated the error right after clicking that
[16:31] <tetsuo--> all in the bazaar gui
[16:34] <bialix> tetsuo--: please, file a bug against https://launchpad.net/bzr-explorer project.
[16:34] <tetsuo--> id ont have a launchpad account :X
[16:37] <tetsuo--> All 1.10 features of bzr are supported.   << that probably means the 2.0 file system will fail?
[16:41] <bialix> where it's from? (All 1.10 features of bzr are supported)
[16:42] <tetsuo--> sourceforge
[16:43] <tetsuo--> https://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar
[16:47] <bialix> tetsuo--: that basically means they've added support for bzr when bzr 1.10 was released
[16:48] <bialix> you need to ssh to the server and run `bzr version` to see what actual version there
[16:48] <bialix> but the safe assumption is that you should not use 2a branch format and use 1.9 format instead.
[16:49] <bialix> I think this page is out-of-date
[16:49] <tetsuo--> i checked, they never updated past 1.10
[16:49] <tetsuo--> well i asked the staff
[16:49] <tetsuo--> :P
[16:49] <bialix> :-/
[16:50] <tetsuo--> i had to open a ticket so they can update to 2.1 stable
[16:50] <bialix> 1.10 is ~1.5 years old
[16:50] <tetsuo--> will probably tak ages
[16:50] <bialix> 2.0.x is good as well
[16:50] <tetsuo--> what does launchpad use?
[16:51] <bialix> this page https://code.launchpad.net/ said 2.1.0
[16:52] <tetsuo--> ok
[17:00] <GaryvdM> Hi bialix
[17:01] <bialix> hi Gary! how are you?
[17:03] <GaryvdM> Good. Just been very busy. You?
[17:05] <bialix> me is very busy too.
[17:05] <bialix> planning to finish urgent stuff to be free for UDS
[17:06] <bialix> GaryvdM: right now trying to work on bug 419758
[17:07] <bialix> GaryvdM: I've provided universal post_commit hook and will store the data in ~/.bazaar/commit-history
[17:07] <bialix> I know bzr-gtk don't want to use our approaches, but just in case
[17:08] <GaryvdM> bialix: I see
[17:24] <tetsuo--> is there a wiki page explaining the difference between the various file system versions?
[17:24] <GaryvdM> File system versions?
[17:26] <tetsuo--> yeah, when create a new repository it asks me which version to use between 1.x, 1.9 and 2.x
[17:27] <Peng_> "it"? What does?
[17:27] <GaryvdM> Ah repository formats
[17:27] <Peng_> tetsuo--: 1.x, whatever that means, is less awesome than 1.9, which is less awesome than 2.0.
[17:27] <tetsuo--> that
[17:28] <tetsuo--> but what are the real differences
[17:28] <bialix> tetsuo--: use 1.9
[17:28] <tetsuo--> since i can only use 1.x with sourceforce i want to know what im missing
[17:28] <Peng_> tetsuo--: The nitty-gritty doesn't matter very much. Use the newest one you can. For example, if your coworkers run bzr 1.12, you'll have to use 1.9.
[17:28] <Peng_> tetsuo--: 2a is significantly faster, smaller and more RAM efficient (well, not all the time for the last one).
[17:29] <GaryvdM> tetsuo--: see bzr help current-formats
[17:30] <GaryvdM> tetsuo--: http://paste.ubuntu.com/422868/
[17:31] <tetsuo--> ok ic
[18:00] <bialix> GaryvdM: ping
[18:01] <GaryvdM> bialix: pong
[18:01] <bialix> do you have 5 minutes? take a look on the sketch design http://bazaar.launchpad.net/~bialix/qbzr/post-commit/annotate/head%3A/lib/commit_history.py ?
[18:04] <tetsuo--> can i convert a 2.0 to 1.x ?
[18:04] <GaryvdM> bialix: Is this related to bug 419758?
[18:04] <GaryvdM> tetsuo--: You can convert 2.0 to 1.0 rich-root, but not to 1.0 non-rich-root
[18:05] <bialix> GaryvdM: yes, this is commit history to use in qcommit
[18:05] <tetsuo--> oh the erorr was about rich toot
[18:05] <tetsuo--> root
[18:06] <tetsuo--> Run command: bzr push<EMAIL_ADDRESS>" Connected (version 1.99, client OpenSSH_5.2)
[18:06] <tetsuo--> bzr: ERROR: Permission denied: "bzrroot/mpc-hc /": : [Errno 13] Permission denied: '/bzrroot/mpc-hc '
[18:06] <bialix> GaryvdM: I'm going to home, will be online again after 30-40 minutes.
[18:06] <tetsuo--> wrong error
[18:06] <GaryvdM> bialix: just a sec
[18:07] <tetsuo--> bzr: ERROR<EMAIL_ADDRESS>is not compatible with CHKInventoryRepository('file:///D:/bzrtest/.bzr/repository/') different rich-root support
[18:07]  * bialix waiting
[18:07] <GaryvdM> bialix: I'm confused. bug/419758 talks about locations, but CommitHistory deals with messages
[18:08] <bialix> GaryvdM: err, maybe. see my last comment to that bug
[18:08] <GaryvdM> ok
[18:08] <GaryvdM> I'll be up till late.
[18:08] <GaryvdM> I'm at work because my home dsl is down...
[18:09] <tetsuo--> maybe i can just change the rich root setting?
[18:09] <GaryvdM> tetsuo--: you have 2 options:
[18:11] <GaryvdM> tetsuo: upgade the branch on sourceforge.net, but only do this if you have consulted the projects other members.
[18:11] <tetsuo--> its new
[18:11] <tetsuo--> empty right now
[18:11] <GaryvdM> tetsuo: and option 2:
[18:12] <GaryvdM> receate branch with non-rich-root format.
[18:13] <tetsuo--> so basically i have to start over, and make a new local branch with the lower version
[18:14] <GaryvdM> tetsuo: I its a new, maybe option 1 is better
[18:14] <tetsuo--> how can i do that?
[18:15] <GaryvdM> tetsuo--: bzr upgrade<EMAIL_ADDRESS>--2a
[18:15] <GaryvdM> sorry
[18:15] <tetsuo--> that wont work
[18:15] <tetsuo--> :P
[18:15] <GaryvdM> tetsuo--: bzr upgrade<EMAIL_ADDRESS>--2a
[18:15] <tetsuo--> the sf server is based on a lower than 2 version
[18:16] <GaryvdM> sorry, then you'll have to start again.
[18:16] <GaryvdM> wait...
[18:16] <tetsuo--> just in time
[18:17] <GaryvdM> You can do :
[18:17] <GaryvdM> tetsuo--: bzr upgrade<EMAIL_ADDRESS>--1.14-rich-root
[18:18] <tetsuo--> dude it worked
[18:18] <GaryvdM> :-)
[18:18] <tetsuo--> the first command did work
[18:28] <tetsuo--> 300mb :O
[18:30] <tetsuo--> i guess ill get some coffee this is going to take some time
[18:33] <tetsuo--> GaryvdM:  does this look right? mpc-hc.bzr.sourceforge.net/bzr/mpc-hc/
[18:33] <tetsuo--> that is supposed to the the master
[18:34]  * GaryvdM looks
[18:36]  * GaryvdM is very worried
[18:36] <GaryvdM> http://mpc-hc.bzr.sourceforge.net/bzr/mpc-hc/changes
[18:36] <GaryvdM> This does not  look like a new branch
[18:37] <GaryvdM> tetsuo-- ^
[18:42] <GaryvdM> tetsuo--: sorry. I guess you thought that you branch was new. You teem mates will need to upgrade their branches before they can pull.
[18:49] <GaryvdM> tetsuo--: Are you still there?
[18:50] <tetsuo--> still
[18:50] <tetsuo--> here
[18:51] <tetsuo--> i created that bazaar an hour ago, sf must auto fill it with some crap
[18:51] <GaryvdM> oh - I see
[18:52] <GaryvdM> Hi biailx
[18:52] <tetsuo--> do i need to run any special commands to make other peoples bzr clients realise this is the master?
[18:52]  * bialix back
[18:52] <GaryvdM> Master?
[18:52] <tetsuo--> i guess thats a git term
[18:53] <GaryvdM> tetsuo--: http://paste.ubuntu.com/422912/
[18:53] <GaryvdM> tetsuo--: The parent branch is the svn branch,
[18:54] <tetsuo--> i want bazaar to be the new parent
[18:54] <GaryvdM> Bialix: would this not solve your problem: http://bazaarvcs.wordpress.com/2009/07/20/qcommit-pending-merge-info/?
[18:55] <tetsuo--> probably doesn't really matter though
[18:55] <bialix> GaryvdM: not really
[18:55] <GaryvdM> tetsuo--: when some one branches the bzr branch on to their machine, then the bzr branch will be the parent branch in their branch.
[18:55] <tetsuo--> ok good
[18:57] <GaryvdM> bialix: If it's the messages of pending merges you are interested in, then you can get them from the repo?
[18:57] <bialix> GaryvdM: no no no, not only pending messages
[18:58] <bialix> sometimes I need to commit in several related branches with similar commit message
[18:58] <bialix> pending merge is only part of the problem
[18:58] <GaryvdM> bialix: ok - I see
[18:58] <bialix> GaryvdM: I like your qdiff with message, but it often slow :-(
[18:59] <bialix> the diff itself is slow
[19:00] <bialix> while I've went to home I've realized I need to extract the add logic to base MRU class
[19:09]  * bialix -> dinner
[19:34] <nvictor> hello
[19:34] <GaryvdM> hello
[19:36] <marv> I haven't used darcs, but I was reading about it's spontaneous branches. can bzr do anything like that?
[19:36] <dash> marv: spontaneous?
[19:37] <dash> you mean you sit down to your editor one day and discover some new branches grew when you were asleep? :)
[19:37] <marv> http://wiki.darcs.net/SpontaneousBranches explains it
[19:38] <marv> What i was actually thinking to myself was: it would be nice if i can assign tags (like a website's tag cloud, not like how you normally think of tags) to specific commits to say something like these 3 commits are a part of this particular bug fix.
[19:39] <marv> then i read about darcs spontaneous branches and that sounded pretty close to what i thought i wanted
[19:39] <LeoNerd> Oh, no.
[19:39] <LeoNerd> bzr's history is linear in a branch. 1 -> 2 -> 3 -> 4
[19:40] <LeoNerd> revision 4 is just a change on top of revision 3.
[19:40] <LeoNerd> You can't come along and suddenly afterwards decide that changesets 3, 19 and 24 are really a branch on their own. That can't work, because 24 requires 23, ....
[19:40] <LeoNerd> darcs is built on commutability and non-linearity of patches, which allows exactly that scheme to work.
[19:41] <tetsuo--> woah bazaar windows client just crashed with a memory error (it tried to read/write to executable memory)
[19:42] <tetsuo--> http://pastebin.com/ThPyg4qF
[19:42] <tetsuo--> occured after pressing refresh
[19:42] <tetsuo--> submitted to winqual
[19:42] <tetsuo--> any windows client devs online?
[19:42] <tetsuo--> its easy to get access to winqual, just need to enable some compile-time switches and get a certificate
[19:43] <marv> does that really matter? i know darcs talks about this theory patches and all that stuff. but I don't see why you couldn't have the same feature on top of bzr. But I guess that answers my question of whether or not it can already do that
[19:43] <GaryvdM> tetsuo--: bzr explorer?
[19:43] <tetsuo--> yes
[19:43] <dash> marv: the usual thing to do in bzr is to shove stuff off into a real branch when you notice you need to
[19:44] <dash> by creating a branch and using bzr merge --uncommitted
[19:46] <marv> I don't even really want to treat them as a branch for most purposes. I just want to be able to say that revisions x, y, an z are for the same new feature, give it a name, and later ask for it by name, without having to deal with making it a separate branch and then merging it,  when really it belongs in the mainline to begin with
[19:46] <dash> that strikes me as very odd. :)
[19:47] <marv> that's probably why nothing really supports doing that
[19:49] <marv> what I have is a bunch of patches on top of a source tree that's maintained by someone else. And I'm trying to come up with a better way of managing it. we used to just use svn and commit our changes directly. and that made pulling in upstream changes very difficult
[19:49] <dash> Ah.
[19:49] <dash> loom or pipeline might be handy.
[19:49] <marv> then i switched to git, and made each thing it's own topic branch
[19:49] <marv> and that has become a real pain to manage
[19:50] <marv> and there's like 4 people who need to work on it, but i'm the only one who understands the topic branch scheme or how to use git
[19:51] <marv> so I want to switch to bzr just because it looks a lot easier to use. but i'm also trying to come up with a better way to do things
[19:51] <LeoNerd> 1 branch per bug. 1 branch per feature
[19:52] <LeoNerd> Branches are cheap. really cheap. Within one shared repo, they're just a reference to the tip at their branchpoint.
[19:52] <marv> I haven't looked at pipeline. i've looked at loom and talked to someone here about it, but decided it wasn't a good choice
[19:52] <marv> branches aren't cheap in terms of doing the checkout, waiting for the code to compile, checking in the fix, then merging the fix
[19:54] <marv> i've been doing 1 branch per bug or per feature (although I've been doing it in git), and I find myself just not wanting to do it anymore
[19:54] <marv> which makes it really hard to convince anyone else to do it
[20:01] <marv> pipeline looks like it might be a little nicer than loom
[20:08] <marv> but i still think i would be better off with a "tag cloud" system more how I described. Maybe i'll look into how hard it would be to do a plugin like that
[20:08] <GaryvdM> Any udd experts here.
[20:08] <GaryvdM> *?
[20:09] <GaryvdM> I'm updated the bzr beta ppa.
[20:10] <marv> Why is there both pipepine and loom? they look to be almost the same thing
[20:10] <dash> marv: pipeline is new and wants to be better, i guess :)
[20:10] <marv> ok, i thought it might be something like that :)
[20:11] <GaryvdM> going to each branch for each ubuntu version and merging debian unstable is laborious.
[20:12] <jam> marv: I use a lightweight checkout and a shared treeless repository, which is very similar to a git layout (multiple branches sharing the same wt)
[20:12] <jam> that avoids having to recompile all your code
[20:12] <GaryvdM> I'm I doing this the right way? Is there an eaiser way?
[20:12] <jam> and avoids having to checkout the files from scratch
[20:12] <jam> pipeline works by basically requiring a lightweight checkout, and automating some bits when you want to have branches depend on eachother
[20:13] <tetsuo--> pipeline is broken on windows though :(
[20:13] <jam> marv: pipeline is focused differently than loom
[20:13] <jam> some small yet fundamental differences of opinion
[20:13] <jam> for example, pipeline assumes your upstream is implicit (it isn't in the pipeline) loom explicitly records an upstream
[20:14] <jam> loom wants to create a structure that you could then merge with another person
[20:14] <jam> pipeline assumes you work on the stuff all by yourself (you can't share pipelines)
[20:14] <jam> (well, you sort of could, but you don't get to diverge from eachother)
[20:32] <marv> jam: oh ok. well if other people can't use it with me, it doesn't do me much good. that was the reason why i didn't use the quilt like thing in git
[21:25] <jelmer> 'evening
[21:33] <GaryvdM> Hi jelmer
[21:33] <GaryvdM> jelmer: You might be able to help me.
[21:34] <GaryvdM> I would like to update the ppas
[21:35] <jelmer> GaryvdM: sure, what's up?
[21:36] <GaryvdM> Merging each branch for each version of ubuntu, with debian unstable is laborious.
[21:37] <GaryvdM> Am I doing the right thing? Is there an easier way?
[21:37] <GaryvdM> jelmer ^
[21:49] <jelmer> GaryvdM: you could use the web interface to copy the packages?
[21:49]  * GaryvdM looks
[21:52] <GaryvdM> jelmer: Thanks - I'm going to try that.
[22:32] <jam> morning mwhudson
[22:32] <mwhudson>  jam hi
[22:33] <jam> I just put up about 5 hopefully 'bite-sized' changes to loggerhead which would be nice if you could review
[22:33] <jam> it drops the time to load emacs/changes from >600ms => 215ms on my machine (once the cache is loaded, etc)
[22:35] <jam> I mostly mention it because I know igc is out most of this week
[22:37] <jam> Peng: ^^ I suppose you're one of the loggerhead reviewers, too
[22:39] <Peng_> I saw the one about an option to disable the merge point thingies. Cutting features out instead of finding magic performance knobs makes me a bit sad.
[22:40] <jam> Peng_: it defaults to False
[22:40] <jam> sorry, True
[22:40] <jam> it defaults to leaving the feature in
[22:40] <jam> I don't think it specifically affects the perf times for loading "changes"
[22:40] <jam> since those revs aren't shown
[22:40] <jam> if you want to see them all together
[22:40] <jam> lp:~jameinel/loggerhead/integration
[22:41] <Peng_> Nonetheless it makes me sad.
[22:41] <jam> Peng_: and that is the only one that is a 'feature removal' vs just a 'stop doing work that we don't use"
[22:41] <Peng_> Oh. Good.
[22:41] <Peng_> Yuhh, don't have Thunderbird open right now.
[22:42] <jam> confirmed, show_merge_points = True still gives 210ms for emacs
[22:46] <jam> at this point, getting the information takes ~ the same amount of time as rendering
[22:46] <jam> so the changes to use chameleon or whatever would start to show
[23:21] <cody-somerville> odd
[23:21] <cody-somerville> $ bzr bind :push
[23:21] <cody-somerville> bzr: ERROR: Not a branch: "/home/cody-somerville/Projects/launchpad/lp-branches/bug-444266/lp:~cody-somerville/launchpad/bug-444266/".
[23:22] <cody-somerville> but bzr info has:     push branch: lp:~cody-somerville/launchpad/bug-444266
[23:28] <beuno> cody-somerville, I'm guessing you have something in your locations.conf
[23:39] <cody-somerville> beuno, yea, http://pastebin.ubuntu.com/423045/
[23:40] <beuno> cody-somerville, so that's why
[23:40] <cody-somerville> Thats just the standard rocketfuel stuff


[06:10] <lotuspsychje> bug #1892521 got duped by daniel
 https://twitter.com/SLSingh/status/1297839372738482180
[11:35] <RikMills> oops, wrong chat
 Hey all, wanted to report that it is impossible to remove gnome-ubuntu-panel.desktop (for Appearance Settings) from gnome-control-center by copying the file to ~/.local/share/applications/ and adding Hidden=true (which is a common method to hide panels), due to an assertion check. It does work for gnome-online-accounts.desktop
 hm
 Do you need to trigger and update of some sort?
 Although I can easily do that, I don't see the need (it's not related to Ubuntu Unity, just my own system). Meanwhile, I've found a solution: the category DesktopSettings `can be removed from the local .desktop` file rather than adding Hidden=true (re @ItzSwirlz: Do you need to trigger and update of some sort?)
 Although I can easily do that, I don't see the need for it (it's not related to Ubuntu Unity, just my own system). Meanwhile, I've found a solution: the category DesktopSettings `can be removed from the local .desktop` file rather than adding Hidden=true (edited) (re @ItzSwirlz: Do you need to trigger and update of some sort?)
 A change should be triggered.
 That's what typically works for me
 The menus need to refresh.
 Although I can easily do that, I don't see the need for it (it's not related to Ubuntu Unity, just my own system). Meanwhile, I've found a solution: the category DesktopSettings can be removed from the local .desktop file rather than adding Hidden=true (edited) (re @ItzSwirlz: Do you need to trigger and update of some sort?)
 It's my own system which I'm referring to. A quick solution is to create a local .desktop file and remove the category DesktopSettings (I don't see how a normal desktop user would try to create a package with dpkg-buildpackage for such a purpose) 🙂 (re @ItzSwirlz: A change should be triggered.)
 just SRU it?
 It's my own system which I'm referring to. A quick solution is to create a local .desktop file and remove the category DesktopSettings (I don't see how an average desktop user would try to create a package with dpkg-buildpackage for such a purpose) 🙂 (edited) (re @ItzSwirlz: A change should be triggered.)