[00:02] <vila> mathrick: file a bug and find jelmer ;) There is probably a text file you can edit somewhere which contains the windos path.
[00:03] <jelmer> mathrick: is this with the core bzr support for colocated branches, or with bzr-colo ?
[00:03] <mathrick> jelmer: I dunno, 2.5.1, created via bzr-explorer with "colocated workspace" option
[00:04] <jelmer> mathrick: ah, that's the bzr-colo plugin
[00:04] <jelmer> mathrick: please file a bug, but against the bzr-colo project on Launchpad
[00:05] <mathrick> is that really a bug in bzr-colo?
[00:05] <vila> jelmer: well dodged ;)
[00:05] <vila> mathrick: more or less
[00:05] <jelmer> vila: :-)
[00:06] <mathrick> OK, how should I describe it? Since I have no clue how that is a problem with bzr-colo and not bzr reconfigure for instance
[00:06] <vila> mathrick: zip is not a transport supported by bzr ;) So you run into some absolute paths that may be better handled as relative (but obviously are  not (yet ?))
[00:07] <vila> mathrick: what you explained here is good enough: zipped on windos, unpacked on linux
[00:08] <vila> mathrick: it may be interesting to see if the reverse breaks in the same way (zipped on linux, unzipped on windoz)
[00:08] <vila> dows
[00:08] <vila> damn tyops
[00:09] <mathrick> vila: I understand that, what I don't understand is how bzr-colo breaks things. Bzr reconfigure should be able to change that path
[00:10] <vila> mathrick: well, the point is that bzr-colo doesn't really break things, it assumes the working trees/branches/repos would stay on the same files system (roughly)
[00:11] <jelmer> mathrick: bzr-colo stores an absolute path to the colocated branch, rather than a relative one; bzr reconfigure tries to open the old branch when it reconfigures I think
[00:11] <mathrick> that is a problem with reconfigure then, no?
[00:11] <vila> mathrick: I suspect that there should be some way to bzr-colo push instead of zip/unzip that should work
[00:11] <mathrick> yes, there is
[00:12] <mathrick> I just didn't remember I made it collocated when I zipped
[00:12] <jelmer> mathrick: bzr-colo should be storing a relative path
[00:12] <vila> mathrick: bzr reconfigure assumes it starts with a "correct" context, it may be worth filing a different bug for that
[00:12] <jelmer> mathrick: you might be able to use --force to get reconfigure to ignore the old code
[00:13] <mathrick> ah, I didn't notice --force wasa thing
[00:13] <vila> jelmer: good point (dunno if this will work but it should ;)
[00:14] <mathrick> nope, --force only seems to influence potentially losing local changes
[00:14] <vila> but in this specific case, if the branch is required, it's hard to ignore it
[00:14] <vila> mathrick: you tried or you just read the --help ?
[00:15] <mathrick> tried
[00:15] <vila> thanks
[00:15] <vila> mathrick: did you try to grep for that path under .bzr ?
[00:16] <mathrick> no, but I expected to be able to change it by hand
[00:16] <mathrick> I was asking for the proper way
[00:17] <vila> mathrick: for this case, I doubt there is one (or that would be bzr-colo push)
[00:18] <fullermd> Pfft, proper.  What fun is that?
[00:18] <vila> mathrick: but really, as jelmer said, bzr-colo should use a relative path (that may not be enough but should help anyway)
[00:18] <mathrick> vila: bzr-colo push is "how do I transport it properly?". But I didn't, and now my question is "how do I fix it?". Bzr reconfigure *should* be able to fix that, and I will file a bug too
[00:19] <vila> mathrick: worth a try, but if there is a single place where the branch path is defined and it's broken, bzr reconfigure can't guess the right one
[00:20] <mathrick> why not? bzr info tells me what the checkout thinks the source branch is. That is what bzr reconfigure is supposed to change; if it tries to open it before changing, it's kinda useless for fixing things
[00:21] <vila> mathrick: it can avoid opening it (it's broken after all) but what will it use instead of that broken path ?
[00:21] <mathrick> the one I give it in --bind-to?
[00:22] <vila> mathrick: oh, well done !
[00:22] <vila> for this specific case indeed, not sure if the code will make it easy to implement but file-a-bug++
[00:24] <mathrick> done, bug #1076809 and bug #1076810
[00:24] <ubot5> Launchpad bug 1076809 in bzr-colo "Copying collocated branches Windows and Linux broken by absolute paths" [Undecided,New] https://launchpad.net/bugs/1076809
[00:24] <ubot5> Launchpad bug 1076810 in Bazaar "bzr reconfigure can't fix dangling paths" [Undecided,New] https://launchpad.net/bugs/1076810
[00:25] <vila> mathrick: thanks
[00:25] <mathrick> sure
[00:55] <vila> fullermd: linked a branch with reproducing failing tests for bug #1072513, one step closer to diagnosis ;-p
[00:55] <ubot5> Launchpad bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513
[00:57] <vila> fullermd: you may want to look at the intermediate commits to see how I get there from your script (including revno 6515 where 'bzr test-script ./bzrlib/tests/blackbox/log_bug_1072513.sh  --null-output' was passing)
[00:58] <vila> fullermd: the missing feature still being to be able to keep the built env to toy around manually with the results :-/
[00:59] <vila> but at least the syntax should be copy/pastable enough for you to tweak
[01:00] <mgrandi> is there a preferred way to backup a repository to a file, or is just zipping the directory pretty much
[01:00] <vila> mgrandi: <cough> ask mathrick ;)
[01:01]  * mgrandi asks mathrick
[01:01] <vila> mgrandi: if you really want a *backup* 'bzr push' should be the fastest
[01:02] <mgrandi> im just sending my code to someone, including the repo for archival purposes
[01:02] <vila> mgrandi: sorry, that a was a joke, mathrick just ran into an issue while zipping on windows and unzipping on linux (special setup where an absolute path has been recorded)
[01:02] <mgrandi> interesting o.o
[01:02] <vila> mgrandi: same os on the receiving side ?
[01:03] <mgrandi> stack overflow says this; http://stackoverflow.com/questions/1976857/bzr-create-tgz-file-containing-full-repository
[01:03] <mgrandi> might not be
[01:03] <vila> bzr send is safest
[01:03] <mgrandi> what does bzr send actually do? generate patch files?
[01:04] <mgrandi> so this just creates a series of patch files or something?
[01:04] <vila> mgrandi: almost, they are called merge directives and contains both the revisions and a human-readable patch
[01:04] <vila> mgrandi: it's not lossless as patches can, you get the real revisions
[01:05] <mgrandi> interesting, thanks
[01:05] <vila> mgrandi: the idea is that send accept a public url readable by both sides and create the delta between your branch and the public branch
[01:06] <vila> mgrandi: so it can be *far* smaller than zipping the whole repo (like the stackoverflow recipe suggests)
[01:06] <mgrandi> yeah, this isn't a problem here but i was just curious
[01:07] <vila> mgrandi: the recipe basically uses an empty branch as a starting point
[01:07] <mgrandi> so are there problems with zipping a bzr branch directory and then using it on a different os?
[01:07] <vila> mgrandi: not a bzr branch, a bzr-colo environment (plugin)
[01:08] <mgrandi> isn't that integrated into bzr now?
[01:08] <vila> there is wip about native colocated branches yes, that's different
[01:09] <mgrandi> but normal branches should be fine? besides the whole symlinks thing
[01:09] <mgrandi> that i still need to work on...
[01:09] <vila> yes
[01:10] <vila> but it's been a looong time since I did that myself, most of the machines I'm working on have ssh and bzr so it's easier to kust push ;)
[01:10] <vila> *just
[01:11] <fullermd> Obviously, the solution is that somebody needs to donate vila a machine without ssh or bzr on it, to force him to work on it   :p
[01:12] <vila> fullermd: the last case was a windows vm where I managed to install ssh as a service anyway ;)
[01:12] <fullermd> I've probably got some OS/2 install media somewhere...
[01:12] <vila> fullermd: and if they don't have ssh but bzr, well, it's easy enough to pull instead of pushing ;-)
[01:14] <fullermd> vila: So, wait, you already fixed it, then re-broke it?  I mean, if the test was passing, that means everything's good, right?   :p
[01:17] <vila> hehe, that's where the test scripts shine: they can express failure more easily ;)
[01:19] <fullermd> 'druther they expressed success   ;p
[01:21] <vila> tsk, tsk, they allow success to be *demonstrated*, that's TDD for you ;)
[01:22] <fullermd> I dunno, TDD sounds like something I'd discuss with my doctor in a hushed voice.
[01:24] <mgrandi> depends on who you ask. they really beat it into us at my school
[01:24] <mgrandi> =P
[01:25] <fullermd> Well, yes, I remember that from high school too, but...
[01:25] <mgrandi> unit test ALL THE THINGS
[01:26] <vila> Alzheimer, Pratchett and I.. what was it I wanted to say...
[01:26] <mgrandi> so vila, i just tried that recipe out, and it seems useless cause you can't merge the file back into an empty repo =/
[01:26] <vila> ha yes, tests are good substitute for failing memory
[01:26] <jelmer> mgrandi: you can pull it into an empty repo though
[01:27]  * jelmer wonders if vila is in the US
[01:27] <fullermd> I do wish I had regression tests for stuff at work.  Sadly, I've never heard a good story for writing something useful considering the depth of stuff that breaks.
[01:27] <vila> jelmer: hehe, no ;)
[01:27] <jelmer> ... or just up late :-)
[01:27] <mgrandi> then the documentation for send is slightly out of date
[01:27] <vila> jelmer: yeah :-} Bad vila, go to sleep
[01:27] <mgrandi>  `bzr send` creates a compact data set that, when applied using bzr merge, has the same effect as merging from the source branch.
[01:27] <fullermd> No, but using it to replicate whole histories is out of the scope of the docs.
[01:27] <mgrandi> well it should still be mentioned that pull can be used as well
[01:28] <fullermd> And it does; merging the source branch into a branch with no history will also fail  ;p
[01:28] <mgrandi> 'using bzr merge or pull, has the same effect etc
[01:29] <vila> mgrandi: that's supposed to work, there may be a bug for *empty* branches (worth filing too, I thought we nailed down all the empty-branch-are-special ones...)
[01:29] <mgrandi> well it specifically gave a bug url when i tried to do it
[01:30] <vila> which one ?
[01:30] <mgrandi> bzr: ERROR: Merging into empty branches not currently supported, https://bugs.launchpad.net/bzr/+bug/308562
[01:30] <ubot5> Ubuntu bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed]
[01:31] <mgrandi> dang 5 years, old bug
[01:32] <vila> helllo, someone remember the shortest workaround for that ?
[01:32] <vila> 'bzr init . ; bzr pull <merge-directive>' ?
[01:33] <mgrandi> well yeah thats what i did
[01:33] <vila> good, my job here is done ;)
[01:35] <mgrandi> is that merge into empty repo a particuarly hard bug?
[01:36] <fullermd> I've never been quite clear as to what it's even supposed to _mean_.
[01:36] <mgrandi> probably along the lines like, its trying to merge two histories but one doesn't exist so it breaks?
[01:38] <fullermd> Yeah, the whole point of merge is "take these two separate things and bring them together", so how's it even meaningful to talk about when there's only one thing?
[01:38] <vila> I think the issue is about root-ids (branches of the same project shares a unique id for their root)
[01:38] <mgrandi> well, it still seems to me that bzr should be smart about that, and if one history just doesn't exist, then just take the other one
[01:38] <vila> the first branch of a project gets a new root-id which is then duplicated
[01:39] <vila> mgrandi: devil is in the details
[01:39] <mgrandi> i imagine
[01:39] <vila> the fact that it's a corner case rarely encountered didn't help raise the bug importance
[01:40] <vila> most of the issues are probably already solved, time is lacking for that one
[01:41] <fullermd> Well, taking the other one is "pull"  ;p
[01:41] <fullermd> If I wanted "merge" to sometimes silently do a "pull" instead, I'd use git...
[01:41] <mgrandi> haha.
[01:42] <mgrandi> maybe the error message should be updated to say 'try pull instead?"
[07:36] <gmarkall> i'm having trouble rebasing a branch. I'd like to rebase the last five revisions onto another branch, but i can't seem to work out how to tell bzr that's what i want to do - i only seem to be able to rebase "all but the last 5" with -r last:5. Is there a way to do this please?
[07:37] <bob2> you mean you're using bzr-rewrite?
[07:37] <gmarkall> (if I don't specify a revision then bzr wants to rebase 54 revisions, which includes a lot of duplicate changes)
[07:37] <gmarkall> bob2: i think i am
[07:37] <gmarkall> bzr help rebase says "From: plugin "rewrite""
[07:41] <lifeless> gmarkall: you might try -r -5:..
[07:43] <gmarkall> lifeless: that gives me "Bzr has encountered an internal error..." - shall I submit a bug report?
[07:43] <lifeless> sure
[07:43] <fullermd> Without the colon, probably...
[07:43] <lifeless> oh heh, yes.
[07:43] <lifeless> EOUTOFPRACTICE
[07:43] <lifeless> gmarkall: -r -5..
[07:44] <gmarkall> ah, that didn't crash bzr! :-)
=== dpb_ is now known as Guest76575
[08:08] <gmarkall> I managaed to get the crash down to a small example: https://bugs.launchpad.net/bzr/+bug/1076894
[08:08] <ubot5> Ubuntu bug 1076894 in Bazaar "Invalid arguments to rebase cause internal error" [Undecided,New]
[08:10] <gmarkall> I managed to choose the correct revisions with the syntax suggested by lifeless/fullermd - however, when i run with --dry-run, the commit ids that it shows are printed out-of-order - is that to be expected?
[08:16] <gmarkall> when i actually did the rebase, the commits were applied in the correct order
[09:03] <mgz> morning!
[09:06] <tbf__> can i tell bzr to just commit the changes of a conflict free merge?
[09:06] <tbf__> constantly forgetting that commit and then messing up stuff
[09:07] <tbf__> (well, also lack the creativity to invent merge commit messages)
[09:17] <tbf__> ok. why would "bzr diff ../parent" show changes that a plain "diff -ru ../parent" doesn't see?
=== tbf__ is now known as tbf
[09:18] <tbf> apparently i still fundamentally fail in understanding things
[09:27] <mgz> tbf: could be lots of reasons for the diff not being the same, fundamentally those two commands look at different stuff
[09:28] <mgz> so, for instance, if the working tree of ../parent is not up to date, plain recursive diff will not see the later revisions
[09:32] <tbf> mgz, ../parent is up-to-date
[09:33] <tbf> mgz, at least the output of "bzr status" and "bzr diff" in ../parent is empty
[09:35] <tbf> mgz, seems i seriously fail to understand even the basics of  bzr: http://nopaste.me/paste/111230873509cce1382789
[09:36] <tbf> mgz, how can it be, that rev 334 contains changes from 316.1.64, while rev 333 is entirely empty?
[09:37] <tbf> 316.1.64 is the last commit in that merge
[09:38] <tbf> i'd only expect to see that change in 334 if i'd reverted 316.1.64 by accident while commiting 333
[09:47] <mgz> ...that paste site is borked, gives 406 + error fallout based on UA string
[09:48] <mgz> tbf: from that log, I'm not sure what's suprising you
[09:49] <tbf> mgz, the output of "bzr diff -c 334 debian/control" entirely surprises me
[09:49] <mgz> the diff for -r331..332 is empty, but the log above stops at 332 so that might be right, and 316.1.64 was merged in 333
[09:50] <mgz> tbf: that command isn't in the paste
[09:50] <tbf> mgz, line 51
[09:51] <tbf> mgz, rev 333 already should have that change, but bzr shows it was applied again in 334
[09:51] <mgz> I suspect you have some funny history
[09:52] <mgz> you remerged the same branch in 334?
[09:53] <tbf> mgz: forgot to commit a merge, shelved the mess. merged from parent again, unshelved.
[09:53] <tbf> expecting that only the really new changes would get applied
[09:54] <tbf> now bzr even crashes when accessing that branch
[09:54] <tbf> great.
[09:54] <mgz> okay, so the history and log/diff output is probably correct
[09:54] <tbf> apparently "bzr switch -r 333" was a stupid idea
[09:55] <tbf> mgz, how that?
[09:55] <mgz> r333 includes the merge, and the history of the other branch, but none of the actual changes
[09:55] <mgz> which you shelved, then committed in 334
[09:56] <mgz> so, log tells you 333 merged stuff, but diff only sees the changes when you actually committed them in 334
[09:56] <mgz> the best thing to get out of trouble here is just make a new branch from 332 and do the merge right this time
[09:57] <tbf> mgz: "r333 includes the merge, and the history of the other branch, but none of the actual changes" - this makes absolutely no sense to me.
[09:57] <tbf> maybe too much in git mind set. what stone i don't see?
[09:57] <mgz> you merged the history from the other branch
[09:57] <mgz> but left the actual text changes uncommitted
[09:57] <mgz> it's the same as doing that in git.
[09:57] <tbf> well. in git i usually rebase
[09:58] <tbf> and stay away from merges
[09:58] <tbf> too much vooodo
[09:58] <tbf> voodoo and magic
[09:58] <mgz> you like having a nice linear world view :)
[09:59] <tbf> mgz, yup :-)
[09:59] <mgz> anyway, the point of version control is you have the old stuff still
[09:59] <mgz> so you can just start from where you were originally and do it right, rather than trying to fix up the current state
[10:00] <tbf> mgz, sure. still at the point of merging a feature i don't care about the dirty details anymore
[10:00] <tbf> all that merging zig-zack and so on
[10:01] <mgz> look, it's easy, do this:
[10:02] <tbf> as long as i work on the features i highly appreciate having different branches and switching between them comparing them, letting them divert, pick changes and so on...
[10:02] <tbf> ...but once it is done. it is done.
[10:04] <mgz> cd .. && bzr branch -r332 old new && bzr merge -r 332.. -d new ../old
[10:05] <mgz> you then have a new branch, with the just the text changes you made in the last few revs ready to commit, and no hisotry to confuse you
[10:05] <mgz> you could bring in the original feature branch as a merge to make the history correct, but you probably don't care about that
[10:06] <mathrick> so how do install libraries needed by plugins in a standalone windows install?
[10:06] <mathrick> I thought it was $plugindir/lib/, but that doesn't seem to work
[10:07] <mgz> mathrick: what I did was use not use the windows standalone installers but the python ones and install all the plugins and bits I wanted via the normal setup.py method
[10:08] <mgz> there was a thing added for the standalone ones to look in another location for libs though
[10:08] <tbf> mgz, checking what this does...
[10:09] <mathrick> mgz: I tried that before, but it's a huge PITA really and never works quite as well as the standalone installer
[10:10] <mgz> mathrick: try
[10:10] <mgz> $ BZR_PDB=1 bzr assert-fail
[10:10] <mgz> (Pdb) sys.path
[10:10] <mgz> which will tell you where the installed bzr looks for stuff
[10:10] <mathrick> ah, good idea
[10:11] <mathrick> ah, so site-packages has been added
=== mmrazik is now known as mmrazik|lunch
=== mmrazik|lunch is now known as mmrazik
[12:13] <lolek> hello all
[12:13] <lolek> a question, i've installed bzr-eclipse, and i'm looking for option: compare with latest from repository ... that is available when using svn but with bzr repo ?
[12:15] <lolek> hmm ok, forget the question, found it, but the is only: compare with latest from branch, what if i want to specify revision ?
[12:59] <jelmer> lolek: I don't think bzr-exclipse is anywhere near usable, is it?
[13:00] <lolek> well ... it is
[13:00] <lolek> :)
[13:01] <lolek> and oh one thing
[13:01] <lolek> regarding this: https://bugs.launchpad.net/bzr-svn/+bug/1076388, i've used svn:// when gave url :)
[13:01] <ubot5> Ubuntu bug 1076388 in Bazaar Subversion Plugin "authentication.conf section does not match when port is given" [Undecided,New]
[13:02] <jelmer> lolek: not sure I follow?
[13:02] <lolek> oh.. sorry my fault... mind shortcut
[13:02] <lolek> forget ;d
[13:04] <mirtwo> TBF!
[13:04] <mirtwo> boah ist die welt klein
=== mirtwo is now known as mirabilos|work
[13:09] <jelmer> lolek: sorry, me too :-)
[13:09] <lolek> mirabilos|work: could you please speak in english ?
[13:09] <mirabilos|work> yes
[13:09] <mirabilos|work> “the world is small”
[13:10] <lolek> thank You ;)
[13:10] <mirabilos|work> tbf was one of the first people I met on IRC, b̲e̲f̲o̲r̲e̲ I even spoke something resembling English
[13:13] <tbf> hey mirabilos|work
[13:14] <lolek> uhm
[13:15] <tbf> mirabilos|work, how long ago is this? 12 years?
[13:15] <mirabilos|work> something like that, yes
[13:15] <mirabilos|work> probably around 1999/2000
[14:13] <lolek> a question, can i use this way of workflow for bzr and svn as centralized repo ? : http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html
[14:14] <lolek> i'm trying to figure out how bzr will deal with branches in folders on svn repo
[14:16] <lolek> of course if You have some suggestions or better aproach, i can consider that also
[14:31] <karni> Hello folks. I have a problem committing u1-servers. bzr really wants to sign with my mkarnicki@gmail.com key, while I want to sign with michal.karnicki@canonical.com
[14:32] <mgz> karni: see #launchpad
[14:32] <jelmer> karni: it should be using your whoami details to find the gpg key
[14:32] <karni> It's picking mkarnicki by default. How do I change that? I've tried overriding gpg_signing_key
[14:32] <karni> whoami says michal.karnicki@canonical.com, but it's not using that one
[14:33] <karni> mgz: I think they'll send me back to #bzr :(
[14:33] <mgz> probably :)
[14:33] <karni> To make matters more "fun", I can sign with @canonical.com a different project with no fuss.
[14:33] <karni> I don't see any specific configuration to that project in my locations.conf
[14:34] <karni> nor authentication.conf
[14:35] <mgz> karni, okay, looking at the code
[14:35] <karni> mgz: Thank you!
[14:36] <mgz> gpg_signing_key should be either "default" or suitable for passing to gpg -u
[14:36] <karni> FWIW I tried passing my canonical e-mail as well as key signature (that's what you call it?) to gpg_signing_key
[14:36] <mgz> if default, it looks at 'email'
[14:36] <karni> right. I can try that again.
[14:36] <karni> should I put it in ~/.bazaar/authentication.conf ?
[14:37] <mgz> karni: nope, just bazaar.conf I think
[14:38] <mgz> apart from by having a different `bzr whoami --branch` I don't see how different projects could get you different signing
[14:39] <karni> mgz: I think it had something to do with me signing it within lxc..
[14:39] <karni> mgz: I did add it to authentication.conf, though
[14:39] <karni> mgz: I tried from my host machine, and it commited properly
[14:40] <karni> yeah, it's still trying to sign with mkarnicki@gmail.com within lxc
[14:40] <karni> mgz: I don't know how that works, but just so you guys know ↑
[14:43] <mgz> but `bzr whoami` in lxc isn't that, and `gpg --clearsign -u ...@canonical.com` works?
[14:44] <mgz> possibly lxc hides some of your keys, or confuses the agent in some way?
[14:51] <mgz> karni: I can't find any key on your name on a gpg key server
[14:52] <karni> mgz: in lxc, bzr whoami is also: Michał Karnicki <michal.karnicki@canonical.com>
[14:52] <karni> So correct.
[14:53] <karni> mgz: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xF1044FC25FD638E7
[14:53] <karni> mgz: I bet it's confusing the agent in some way
[14:54] <mgz> ah, you have an 'i' on the end I'd not registered
[14:55] <karni> :)
[14:58] <fullermd> You should vowel to be more careful with your spelling...
[15:00] <mgz> karni: when you ran just the gpg command inside lxc, did it also want to sign with the wrong key?
[15:00] <karni> I can check
[15:00] <mgz> fullermd: @ expands to eat all adjacent characters
[15:01] <mgz> *munch* *munch*
[15:01] <fullermd> Only to the right; you can see what's where the mouth is.
[15:01] <karni> mgz: gpg --sign desktop.png signs with mkarnicki, but -u michal.karnicki works to override and sign with the second key
[15:10] <lolek> ok, one more time with my question, i'd like to use this approach: http://doc.bazaar.canonical.com/beta/en/user-guide/svn_plugin.html#using-a-central-repository-mirror but want to use svn as central repository, my question is what problems should i consider ?
[15:12] <lolek> the problem is that i want to use that like this: http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html, the second question is how bazar will work with branch in subdirectory on svn repo ?
[15:14] <jelmer> lolek: hi
[15:14] <jelmer> lolek: what do you mean with branch in subdirectory exactly?
[15:15] <jelmer> bzr-svn handles it fine if there is e.g. a branch named /trunk in the repository, and recognizes copies
[15:30] <mgz> karni: last thing to see is run `bzr config` in the branch, see if gpg_signing_key is set anywhere up the chain
[15:30] <karni> mgz: bzr: ERROR: unknown command "config"
[15:31] <jelmer> karni: your running a very old version of bzr
[15:32] <karni> Bazaar (bzr) 2.1.4 in lxc (LUCID), 2.5.1 on host OS
[15:32] <karni> This is because it's u1-servers branch, lucid was advised (although I hear it works on more current version)
[15:35] <iwata0303> Hi.
[15:36] <iwata0303> Does anyone know when bzr2.6b3 will come ?
[15:39] <jelmer> vila, mgz: ^
[15:40] <lolek> jelmer: may i pm You ?
[15:41] <jelmer> lolek: sure
[16:03] <mgz> karni: that might also be an issue with gpg signing then. you can, on lucid, us the bzr ppa to restore sanity to the world.
[16:03] <karni> mgz: ah. I might try that. I'll stick with committing from host for now :) Thank you!
[16:04] <mgz> karni: ppa:bzr/ppa
[16:04] <mgz> iwata0303: ideally soon
[16:05] <iwata0303> mgz: Thank you!
[16:05] <karni> mgz: Thank you, sir!
[16:06] <mgz> I'll send something to the list when I'm about to launch on working out how to do a release
[16:06] <mgz> hm.... the next couple of weekends are full, might need to find a weekday night
[16:46] <embersoaker> I merged and commited a branch in to trunk and then reverted it. Went back and changed my code in my branch and then when trying to merge again it won't let me. Is there a way to get trunk to forget that this branch was merged/conmitted before? or a way to force a commit?
[16:52] <mgz> you merge trunk back into your branch, revert the tree but not the merge marker (`bzr revert .` && bzr commit), then merge the branch back into trunk
[16:54] <mgz> basically, the feature branch needs to acknowledge the tree changes were not accepted on trunk, and have a new rev with the changes still present as well as trunk history so trunk knows to reapply them
[16:56] <mgz> embersoaker: ^that make sense to you?
[16:58] <embersoaker> yes
[16:58] <embersoaker> thank you
[17:00] <vila> mgz: I'll be in england next week, if connected the latency should be low ;)
[17:00] <mgz> oh ho ho, london?
[17:00] <mgz> all week?
[17:00] <vila> mgz: yup and yup
[17:00] <mgz> jelmer: ^
[17:01] <jelmer> vila: where in England?
[17:01] <vila> london
[17:01]  * jelmer will be in London from Wed-Fri
[17:05]  * SamB_MacG5 grumbles about how ad-hoc bzr's commands are ...
[17:24] <vila> jelmer, mgz : I'll leave Friday afternoon, will need to check my schedule but... would be nice to have either lunch or dinner or something no ?
=== deryck is now known as deryck[lunch]
[17:42] <jelmer> vila: yeah, that'd be great
[17:43] <fullermd> If I start swimming now, maybe I can meet you there...
[17:43] <vila> fullermd: be my guest ;)
[18:35]  * SamB_MacG5 is especially thinking that "bzr missing" should support most of the options of "bzr log", like -p ...
[18:39] <fullermd> https://lists.ubuntu.com/archives/bazaar/2008q2/041074.html   :p
=== deryck[lunch] is now known as deryck
=== yofel_ is now known as yofel
[22:23] <delinquentme_> ls
[22:23] <delinquentme_> derp!
[22:24] <delinquentme_> I have config files ... I'd like a new user to be able to have access to a version of them ... but not mine ...
[22:24] <delinquentme_> SO .. can I include files within a bzr repo which aren't VC'ed ?
[22:31] <fullermd> Well, you can PUT a file there and ignore it.  Obviously bzr won't know anything about it, so you'd have to put it there (if it's important) any time you make a WT.
[22:32] <delinquentme_> WT?
[22:32] <delinquentme_> fullermd, ?
[22:32] <lifeless> working tree
[22:33] <fullermd> Oh, shucks.  If I'd known lifeless was here, I'd have just hit 6 or 8 keys at random, and he'd interpret a correct answer out of it...