[07:54] <mwhudson> jelmer: samba 4!?
[07:59] <superfly> jam: Thanks for the advice yesterday, I am sorted.
[07:59] <jam> superfly: cheers!
[08:01] <mmrazik> hello. I'm using (indirectly) tarmac to merge this MP: https://code.launchpad.net/~didrocks/ubuntu-wallpapers/new-pkg/+merge/138988 and I'm getting the following trace:
[08:01] <mmrazik> http://pastebin.ubuntu.com/1427031/
[08:01] <mmrazik> any idea? There is a file in the branch which has u'\xf8' in the filename
[08:10] <mmrazik> mhm... export LANG=en_US.utf8 did the trick
[08:19] <mgz> morning!
[08:19] <superfly> aloha
[08:39] <jelmer> mgz: wazaa!
[08:39] <mgz> kwoor
[08:40] <jelmer> mwhudson: I'm as surprised as you are
[08:50] <mgz> jelmer: was that the right nick?
[08:50] <mgz> I missed the relevent bit of the log...
[08:52] <jelmer> mgz: yeah, response to mwhudson's surprised outcry over samba 4 :)
[08:53] <mgz> jelmer: should `bzr diff --old file:,branch=trunk --new file:,branch=feature` work? I can't seem to persuade it to (using merge --preview does)
[08:53] <mgz> ...you've not gone and released it, surely?
[08:53] <mgz> you have! shocking.
[08:54] <jelmer> mgz: we have, yesterday
[08:55] <jelmer> http://stationary-traveller.eu/samba-4.0.0.html
[08:56] <jelmer> mgz: in theory that should work, I think
[08:56] <mgz> pretty much everything else does
[08:57] <jelmer> mgz: you know about the co: syntax in 2.6?
[08:58] <mgz> nope, have been using file:,branch=
[08:58] <mgz> co: is an alias for that?
[08:58] <jelmer> yep
[08:59] <mgz> I'd say I didn't see the merge proposal, but I probably approved it, then forgot since
[09:00] <jelmer> I think that might be the case
[09:23] <ychaouche> Hi. I'm still looking for a way to know which branch I'm in. https://answers.launchpad.net/bzr/+question/216485
[09:24] <mgz> ychaouche: `bzr info` tesll you
[09:25] <ychaouche> mgz: it doesn't : http://pastie.org/pastes/5515023/text
[09:27] <mgz> ...you're question isn't really specific enough then
[09:29] <mgz> what exactly is the directory you're running that in?
[09:29] <mgz> because after your example commands what you have is two directories in the cwd, one named 'dev' and one named 'prod'
[09:30] <mgz> the branch you're in is neither of those, so, where did it come from?
[09:31] <ychaouche> mgz: it's a copy of dev
[09:31] <ychaouche> a physical copy, created with the cp command
[09:31] <mgz> then the way you tell which branch it is, is it's the one you copied...
[09:32] <ychaouche> cp ~/REPOS/BZR/sugarbee/dev ~/.zdesktop/zimlets-deployed/_dev_com_feeder_sugarbee
[09:32] <ychaouche> mgz: that was not my original question
[09:33] <ychaouche> I'm anticipating when code is put on the test server by someone else
[09:33] <mgz> if you copy an abitrary directory structure, you can't tell apart from by inspection what it ise
[09:34] <ychaouche> mgz: is there another way then ?
[09:34] <ychaouche> a way to track branches ?
[09:34] <mgz> the answer you want is probably to not use cp, but create an actual branch or checkout
[09:34] <ychaouche> checkout
[09:34] <ychaouche> ok
[09:35] <mgz> eg, `bzr checkout --lightweight ~/REPOS/BZR/sugarbee/dev ~/.zdesktop/zimlets-deployed/_dev_com_feeder_sugarbee`
[09:35] <ychaouche> ah ok
[09:35] <mgz> and use `bzr update` to update it, or `bzr switch` to change the branch being used
[09:37] <ychaouche> mgz: with my current setup (physical copy), suppose If i'm commiting something in the destination branch, it won't be commited also in the source branch, right ?
[09:38] <ychaouche> because for bzr there's no relation between them
[09:38] <mgz> right.
[09:38] <ychaouche> good
[09:38] <ychaouche> so i'll use physical copy back to the source, to simulate a commit, and then use checkout on the destination branch again to do things right.
[09:38] <mgz> the correct way of doing that (temp hacks to live etc) would be to `bzr switch -b ~/REPOS/BZR/sugarbee/livehack` first
[09:39] <mgz> in the checkout
[09:39] <mgz> then you can commit without affecting trunk/whatever you're running from
[09:39] <mgz> but also integrate the change back if needed later
[09:41] <ychaouche> mgz: on the contrary, I want them to affect each other
[09:42] <ychaouche> I want to replicate the svn way of doing things, for now. I know I can easily change the workflow later because it's easy to decentralize.
[09:42] <mgz> in which case, the lightweight checkout already does what you want by default
[09:42] <mgz> remember to run `bzr update` on both sides if you have two trees though
[09:42] <ychaouche> mgz: no just one tree
[09:43] <ychaouche> oh sorry no two working trees
[09:43] <ychaouche> I'm not used to terminology yet ^^
[09:43] <ychaouche> but since I'm checkouting from a branche, doesn't commiting in the checkouted branch also commits to the original branch ?
[09:43] <ychaouche> I'll just have to update
[09:43] <ychaouche> ok
[09:44] <ychaouche> sorry, I'm a bit slow
[09:46] <mgz> no problem :)
[09:46] <ychaouche> yeah I didn't realize that the original branch is also a working tree, so it needs to be updated.
[09:46] <mgz> see for reference: http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/core_concepts.html
[09:48] <mgz> you can create those branches without trees (or remove the trees) if you want to be closer to the centralised model, depends if you have seperate deployment and development workspaces or want one tree for everything
[09:49] <ychaouche> I'll answer you in a second, I have a question first : the help for the checkout command says with the --lightweight option the usual operations need access to the original branche, so I'm loosing the decentralizing work here. Right ?
[09:50] <ychaouche> I want to keep my working tree "local"
[09:50] <ychaouche> decentralized, and then "merge back" or I guess "push" to the branch I checkouted from
[09:50] <ychaouche> I want to simulate a decentralized environement on my own machine, to be able to reproduce those operations when going test/live
[09:51] <ychaouche> mgz: yeah I read the user-guide and the 5 minute intro already.
[09:52] <ychaouche> But I'll read the lightweight checkout again.
[09:52] <ychaouche> http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/using_checkouts.html#getting-a-lightweight-checkout
[09:53] <ychaouche> and stacked branches
[09:53] <mgz> ignore stacked branches, they're not what you want :)
[09:54] <mgz> you can use checkouts in tandem with a decentralised workflow, it's just if there's *only* one branch and everything else is a checkout that you lose the win
[10:34] <ychaouche> I'm not sure to fully understand what push does. Does it create an exact copy of the branch to another location ?
[10:35] <ychaouche> It seems that in bazaar, every working tree is a branch
[10:35] <mgz> it transfers data from the respository and updates the branch pointer to the same as the local branch
[10:35] <mgz> it does not change the remote working tree, if one exists
[10:36] <mgz> and no, working tree and branch are seperate concepts
[10:37] <mgz> by default when you branch something you get all three of repository, branch, and tree
[11:04] <ychaouche> mgz: this is how I intend to work http://i.imgur.com/T0uO7.png, in an answer to your previous question about wether I want centralized or decentralized model.
[11:05] <ychaouche> Any comments appreciated, especially on how to improve this process if possible
[11:05] <ychaouche> brb : lunch
[12:28] <j^> so bzr not does ssl verification without SNI support? thats sad
[12:34] <mgz> I can't parse that...
[12:42] <mgz> ychaouche: you probably just want to deploy to the test server using bzr-upload or something and not have any branches actually living there
[12:43] <j^> mgz: SNI = Server Name Indication allows multiple https vhosts per ip
[13:08] <ychaouche> mgz: suppose I use bzr-upload or just plain tarball deploying to the test server without having any branche there. Suppose I make a hotfix on the testserver. How can I merge those hotfixes back to the prod branch ?
[13:51] <ychaouche> A merge obviously doesn't work : http://pastie.org/pastes/5515954/text
[13:51] <ychaouche> cfsb was created with a bzr export --format=tgz
[13:53] <ychaouche> mgz: besides, if I'm not using a branche in the test server, we're back to the beginning of our problem which is : how do I know what branch is it ? dev or prod ? :)
[13:54] <ychaouche> that's why I imagined having also a REPO in the server
[13:55] <ychaouche> inside the repo, the name of the name of the folder IS the name of the branch, so I know at any given time what branch is in what directory. In the /srv/www/, the folder containing the branch is names arbitrarily, so the only way I know which branch it contains is when I'm checkouting from the local repository.
[13:55] <ychaouche> I hope that explains a little better what I'm trying to do and what problems I'm addressing.
[13:56] <ychaouche> so you can parse the diagram ;)
[16:31] <jlf> good morning #bzr, i've been trying to find out how to show all files that were changed in a particular commit but i didn't see anything applicable in `bzr help commands' or the man page.  can anyone enlighten me?
[16:36] <jpds> jlf: Sounds like: bzr status -r $REVISIONID.
[16:37] <jlf> doesn't that show the state of my current tree with respect to $REVISIONID?
[16:38] <mgz> jlf: if you pass a revision range (or use -c $REV) it's like a diff across those revisions
[16:39] <mgz> ooh, and a bug... requires a working tree even when it doesn't
[16:39] <jlf> mgz: that does it, thank you
[16:40] <jlf> jpds: and thanks to you as well
[16:41] <mgz> bug 392391
[16:55] <ychaouche> Need advice on establishing a good workflow https://answers.launchpad.net/bzr/+question/216615, please leave a message there. I have to go home now.
[16:55] <ychaouche> TIA