[01:20] <delinquentme> is anyone in here familar with gits workflow ... I need to know if the branching practices in bzr are similar to git ... and perhaps some examples of how they might differ.
[01:22] <bob2> it's the same
[01:25] <delinquentme> bob2, thats waaaayyy too simplistic to be helpful or true
[01:28] <bob2> it's not
[01:28] <bob2> it's the same except that in bzr a branch is another dir
[01:29] <bob2> (possibly colo is good enough to use now, I don't know)
[01:29] <delinquentme> bob2, well now i've talked to a number of people in here and they're telling me that branches AREN"T additional directories
[01:29] <bob2> as above
[01:34] <delinquentme> bob2, sorry I dont follow?  "as above" ?
[01:35] <bob2> 12:29:25 < delinquentme> bob2, well now i've talked to a number of people in here and they're telling me that branches AREN"T additional directories
[01:35] <bob2> 12:29:05 < bob2> (possibly colo is good enough to use now, I don't know)
[01:35] <bob2> colo = making bzr work like git with easy switching of branches in one """checkout"""
[02:07] <delinquentme> bob2, do you have a online source that states definitively that a branch in normal vanilla bzr creates a new directory with every branch?
[02:37] <delinquentme> bob2,
[02:37] <delinquentme> any chance of definitive statement?
[02:44] <spiv> "vanilla" is a bit of an imprecise terms.
[02:44] <spiv> *term
[02:45] <spiv> The bzr user guide explicitly describes multiple ways of working, with the understanding that the "best" way depends on the circumstances
[02:46] <spiv> And the aspects that people care deeply about differ
[02:46] <spiv> Some people strongly care about "feature branches" (one branch per work task)
[02:46] <spiv> Some people strongly care about reusing the same workspace on disk for everything relating to a project.
[02:47] <spiv> (Some people strongly care about both, for that matter.)
[02:48] <spiv> So when you're asking if the branching practices are like git, I think you need to define your meaning a little more clearly (although I appreciate it's hard without having a thorough understanding of both systems).
[02:49] <spiv> Because in the extreme, it can be interpreted as meaning "I can type 'git frob -x ...' when I want to frob my stuff"
[02:50] <spiv> Or maybe you really want support for pushing a group of related branches in a single operation.  Or maybe you really want trivial support for pushing one branch without worrying about how it may be related to other branches you have.  Etc.
[02:51] <spiv> Which is a long-winded way of saying bob2 is right that it's a simplistic question, even if it doesn't feel like one, so you're unlikely to find the definitive statement you're looking for.
[02:51] <spiv> But perhaps you have more specific questions we can help with?
[05:56] <jelmer> moin
[10:50] <delinquentme> Hey all !  I'm looking for a definitive example of a branching workflow.  I'm used to running with Git and I use substantial branching in my own practices ... basically I'm not sure how branches in BZR work ... and if someone would address the long standing question of whether bazaar branches create their own directories .. that would be awesome
[10:53] <AfC> delinquentme: branches work by ... branching
[10:53] <AfC> delinquentme: and yes, bzr branches live in their own directories. That comes from several design decisions, including wanting to give each branch a URL
[10:54] <delinquentme> AfC, I mean an example haha ... 1) branching 2) committing on both A and B branches 3) specifics on how they differ ... and then conflict resolution between the two
[10:54] <delinquentme> AfC, final answer? I'm guessing you're pretty confident in bzr?
[10:54] <AfC> delinquentme: you can certainly replicate Git's change-branch-in-place behaviour, but you need to take a certain amount of care to set things up to behave.
[10:56] <AfC> delinquentme: everything you're describing is just 3rd generation Distributed Version Control. Any of the modern DVCSen have the same building blocks and the same capabilities.
[10:56] <AfC> bzr is, in our opinion, a lot more explicit about the important things, and, once you "get it" a shit load easier to use, but whatever.
[10:57] <AfC> delinquentme: there are any number of tutorials around, but for instance one I wrote is http://java-gnome.sourceforge.net/HACKING.html
[10:57] <delinquentme> example of the important things?
[10:58] <delinquentme> ok so in this line: $ bzr branch mainline/ working/
[10:58] <delinquentme> this is your branching operation
[10:58] <AfC> whole tree commits, explicit identity of branches and thence ease of comparing branches, merge performance, not shooting you in the foot when you try to resolve conflicts
[10:59] <AfC> delinquentme: yes
[10:59] <AfC> delinquentme: (assuming I already have taken some action to get a "branch" of mainline, which is the case there)
[10:59] <AfC> delinquentme: (the other starting point would have been bzr init mainline/ but that's a bit pointless here)
[11:00] <AfC> delinquentme: http://research.operationaldynamics.com/bzr/quill/ ← lots o branches
[11:01] <delinquentme> yeah i'm on about ... the local editing of existing branches
[11:01] <AfC> one of which is mainline and "more special" but only by convention. Branches are peers.
[11:01] <AfC> delinquentme: well, once you've got _commits_ in different branches
[11:01] <AfC> delinquentme: (that have therefore diverged)
[11:01] <delinquentme> yeap
[11:01] <AfC> delinquentme: you can then do things like
[11:01] <AfC> $ bzr missing --line ../other
[11:02] <AfC> which tells you what revisions exist on each
[11:02] <AfC> another stalwart is
[11:02] <AfC> $ bzr diff -r ancestor:../mainline
[11:02] <AfC> which shows you a diff not against the current branch's committed state
[11:02] <AfC> (Whchi is what bzr diff does straight up)
[11:03] <delinquentme> which is essentially is what commits is the current branch lacking from those in mainline
[11:03] <AfC> but instead against whatever the common ancestor is between the two branches. It is, in effect, a merge prediction
[11:03] <AfC> delinquentme: yes, that's `missing`
[11:03] <AfC> and with that, my ferry has landed. Excuse me.
[12:10] <jml> hey
[12:10] <jml> I want a command like lp-propose, but that adds an approval vote with some trivial text (e.g. "rubberstamp") and also sets the approved revision on the status of the merge proposal
[12:11] <jml> this is because we use tarmac for landing branches, and there's a non-trivial class of branches that we wish to land without requiring code review.
[12:11] <jml> it seems pretty straightforward to implement
[12:11] <jml> *but*
[12:11] <jml> I can think of a couple of ways I might do it
[12:11] <jml> a) totally new command
[12:12] <jml> b) a new option to lp-propose ('--vote Approve', maybe?), along with a fix to --approved behaviour to set revid
[12:13] <jml> c) a separate command for reviewing merge proposals
[12:14] <jml> d) change the behaviour of --approved on lp-propose to also add a trivial comment & approve vote (as well as setting revid)
[12:14] <jml> c) is most flexible, I think. d) is most convenient for my use case.
[12:14] <mgz> does it want to be a bzr thing at all?
[12:15] <mgz> with lp-propose you always have the branch you want to make an mp from right there, and it probably needs pushing
[12:15] <mgz> but at best with reviewing you've got a copy of the other person's branch you'rve just run tests on, and the only change you want to make it to launchpad via it's api
[12:15] <mgz> *is to
[12:16] <jml> mgz: remember the use case is to push, propose and rubberstamp my own branch
[12:16] <mgz> we want to encourage that? :)
[12:16] <jml> mgz: so, insofar as lp-propose already partly caters to this use case by having an --approve option
[12:16] <mgz> I'd extend lp-propose then, for that case.
[12:17] <mgz> but not try and do the general case.
[12:18] <jml> mgz: cool, I'm in favour of that.
[12:19] <jml> phone
[12:59] <jml> mgz: in testtools, there's a check that says if sys.version_info > (3, 3), expect "PermissionError". However, in actual released Python 3.3, it seems to be FileExistsError.
[12:59] <jml> mgz: in t.tests.test_testresult.TestNonAsciiResults.test_os_error
[13:00] <jml> mgz: naively, I'd change this to FileExistsError and remove the PermissionError branch. Do you know of a reason for me keeping a PermissionError branch to the conditional?
[13:03] <mgz> I'll have a quick look and see
[13:04] <jml> mgz: thanks.
[13:05] <mgz> hm, that's a little icky
[13:06] <mgz> it's probably platform dependant
[13:10] <mgz> could make it assertThat(self._as_output(textoutput), MatchesRegex("(?:Permission|FileExists)Error: "))
[13:10] <mgz> I think that will still get the str/unicode stuff right
[14:00] <delinquentme> whats the closest bzr operation to a rebase?
[14:04] <gmarkall> there's a rebase plugin
[14:05] <gmarkall> although, it doesn't do interactive rebase afaik
[14:15] <jml> mgz: thanks. I'll do that.
[14:24] <LeoNerd> There is rebase, and it's just as rude as it is in git
[14:27] <mgz> jml: reviewed, one similar issue noted
[14:27] <jml> mgz: oh, thanks.
[15:05] <lifeless> mgz: btw, lots of testtools discussions also happen in #subunit.
[15:27] <delinquentme> LeoNerd, its just as rude?
[15:36] <LeoNerd> It rewrites history
[15:36] <LeoNerd> It throws away previously-committed revisions and replaces them with other ones
[16:17] <delinquentme> so I thought I've run merges on bzr before and it annotated the differences within a single file?
[16:18] <delinquentme> with <<<<< [16:32] <delinquentme> So I've got a .BASE .OTHER and a .THIS
[16:32] <delinquentme> :P
[16:33] <delinquentme> what all is going on heeere
[16:53] <delinquentme> ok so If i run a $ bzr merge ../some_branch  ... and then im going through the files ...   the conflicts labeled as " TREE " are those which were on the trunk ( being that I merged some_branch INTO trunk ) ... and those labeled as MERGE-SOURCE .. were those bits of code which were in the some_branch
[16:53] <delinquentme> right/
[17:52] <awolf> Hi folks, I'm a maintainer of a daily build of a package, and I use a source recipe on Launchpad, and I super love it and it's great.
[17:52] <awolf> However, I need to make some changes to the recipe, so I'm rebuilding the environment on my local PC so I can test changes locally.
[17:52] <awolf> I am finding that even when I modify the recipe to use bzr repos that are on my harddrive, they're abysmally slow.
[17:53] <awolf> I've got a relatively beefy machine, ssd, and while doing a bzr dailydeb build where the recipe points to bzr repos that are only located on my machine, not lp: or over a network, I'm getting occasional timeouts!
[17:53] <awolf> The timeout aren't happening every time, so I don't think I'm pointing to the wrong place--it geniuinely looks like a timeout.
[17:54] <awolf> Any thoughts?
[18:28] <delinquentme> bzr uncommit -r -3  this backs out to commit revno 3?
[18:28] <delinquentme> or back 3 commits from the most current?
[18:31] <beuno> delinquentme, should undelete the last 3 revnos
[22:24] <delinquentme> hey all .. whats the modification I need to make to $bzr log to only get a few of the last commits ?
[22:25] <mgrandi_> look at bzr help revisionspec
[22:25] <mgrandi_> can limit the amount of commits you are looking through there
[22:31] <delinquentme> mgrandi_, theres no ... just .. argument like a " -4 " I can add??
[22:31] <delinquentme> seems silly/
[22:34] <jelmer> delinquentme: --limit 4 ?
[22:35] <delinquentme> jelmer, bzr log -l 4
[22:35] <delinquentme> awesome
[23:51] <danielbrauer> Hello, I'm running Bazaar on Mac OS, and running into this issue: https://bugs.launchpad.net/bzr-explorer/+bug/926439
[23:51] <danielbrauer> I see that there is a patch there, but I'm not sure what to do with it.
[23:52] <danielbrauer> Having used the disk image to install Bazaar, I'm actually not sure where all of its python files reside.
[23:56] <mgrandi_> one sec
[23:59] <mgrandi_> the directory you want to apply the patch is /Library/Python/2.6/site-packages/bzrlib/plugins/explorer
[23:59] <mgrandi_> the lib file is in there
[23:59] <mgrandi_> err directory
[23:59] <danielbrauer> Thanks, looking now.