[00:05] lifeless: i really think we need to work out what's happening with pqm runtimes? [00:05] :s/?// === thumper_laptop is now known as thumper === mwhudson__ is now known as mwhudson [01:08] hey all - I need some help with bzr internals... [01:08] I'm working on a post_push hook to send mail similar to a post_commit email [01:09] the problem I'm having is getting the approrpiate starting revision to send to log.show_log and show_diff_trees [01:09] mtaylor: why not adapt the email plugin ? [01:09] lifeless: I did [01:10] mtaylor: I'd be happy to review patches to make it do both/be configurable [01:11] lifeless: actually - I'd love to send in the patches... although I might have diverged a bit much at this point (need to go back and break things up into patches I can send in) [01:11] mtaylor: there is result.old_revid and old_revno, and result.new_revid and new_revno [01:11] lifeless: if I remember correctly the problem I started out trying to solve, if I use result.old_revno, the log is one revision short [01:13] mtaylor: so x..y is half open [01:13] 0..1 includes 1 but not 0 [01:13] yes [01:14] so that sent me down the trail of trying to find the -1 given 0 [01:14] mtaylor: do you want to show 0 tho ? [01:14] yes [01:14] since it's the first rev that is being pushed [01:15] mtaylor: no, its the first rev before what is being pushed [01:15] mtaylor: I think you might be seeing left-hand-history pivoting [01:15] what's that? [01:15] say your current master branch is ABC [01:16] and your local branch is AD [01:16] (D is local work) [01:16] you can't push [01:16] so you merge, getting [01:16] ADE [01:16] E is a merge of BC [01:16] now when you push to the master branch the master becomes [01:16] ADE [01:16] right [01:16] and the old_revno == 3 [01:16] new_revno == 3 [01:17] because the old_revno is not the old revision number of the old revid in *your branch*, its the old revno of the old revid in the untouched target [01:17] ok. makes sense [01:18] this is one of the reasons that I recommend centralised branches be mutated via checkouts rather than pushing [01:18] because checkouts help manage the workflow to avoid this [01:18] there is also a branch flag you can set to tell bzr to error if this would happen [01:18] the left hand history is privileged in a number of ways, its what log --line shows [01:19] its usually the representative list of 'what a project has merged' [01:19] so what I need in this case is really a pre-push hook that gathers info in the same way as bzr send does [01:19] well, if you *want* such pivots in your workflow, yes. [01:20] but anyhow - the first thing I would do is examine your test case to see if this is what is happening [01:21] bzr push -r50 /tmp/mysqltest [01:21] bzr push -r52 /tmp/mysqltest [01:21] (I was backwards in what I said earlier) [01:21] that produced: [01:22] bzr push into plugins tree (mtaylor:50 to 52) [01:22] of course, what I was really pushing was 51 to 52 [01:22] and in the log, I get 50 as well [01:23] doing log.show_log(self.branch, lf, verbose=True,direction='reverse',start_revision=self.old_revno,end_revision=self.new_revno) [01:23] so [01:24] sounds like something somewhere is not treating the interval as half_open correctly [01:25] what I did to try to work around it was: [01:25] new_graph = self.branch.repository.get_revision_graph(self.new_revid) [01:25] start_rev = get_parent(self.old_revid,self.new_revid,new_graph) [01:26] where get_parent was a recursive thing kept trying to walk the tree [01:27] but it seems really wrong (and the function breaks on some merges) [01:28] mtaylor: just add one [01:28] mtaylor: the docstring says clearly that its not a half open interval === thumper_laptop is now known as thumper [01:29] wow. really? [01:29] * mtaylor punches himself in the face [01:29] pydoc bzrlib.log.show_log [01:29] start_revision [01:29] If not None, only show revisions >= start_revision [01:29] end_revision [01:29] If not None, only show revisions <= end_revision [01:39] lifeless: ok. I honestly don't know what crack I was originally smoking. [01:39] lifeless: but just adding 1 rather than trying to walk the tree sure does work perfectly [01:40] lifeless: so, have you seen the code that's in bzr-build for adding config info to the branch in a .bzr-builddeb/default.conf file? [01:41] bzr-builddeb I mean [01:42] hello mtaylor [01:42] hi poolie [01:42] lifeless: thanks for the RT request, i bumped it to joey [01:51] mtaylor: I haven't looked at it, no. [02:03] A two week release cycle? [02:05] no, 1.4 was late [02:05] {shrug} [02:05] so, that doesn't change the fact that it only just come out. [02:06] came* [02:08] * igc lunch [02:08] I wouldn't dream of quibbling with "a good amount of code has landed" but you are jerking the chain of the people who do packaging [02:12] AfC: so the closest way to keep a precise cycle would be to do the rc1 now and have a longer lag til the release [02:12] is this an undue burden on packagers? [02:16] AfC: I think jerking the chain of packagers is preferable to jerking the chain of users in general. Especially as a lot of bzr packagers are within the community (or are poolie), so are aware of what's going on. [02:34] Odd_Bloke: true [02:36] Odd_Bloke: and I should also concede that at the scale of third digit minor releases (in the sense of era.major.minor even though everyone insists on calling it major.minor.whatever) people are pretty used to doing bumps with no big deal [02:37] poolie, Odd_Bloke: but I have noted an enormous amount of dismay expressed by people that people writing plugins (and thence packages for those plugins) across the Bazaar space as a whole have seemed to have a hard time staying abreast. [02:37] I don't feel jerked by the fairly fast release cycle. I feel a little flailing-in-the-dark on delayed releases, though. [02:38] Perhaps it would be less evident if the coupling between (say) {bzr-svn, bzr-gtk} and bzr was looser. [02:38] AfC: bzr-gtk isn't coupled with particular bzr releases [02:39] jelmer: I'm glad to hear that [02:39] jelmer: though I must say that I seem to have a fairly strong recollection of frequently battling "this version imcompatible with installed bzr" warnings|errors in the not too distant past [02:40] AfC, That was < 1.0 [02:40] Ah [02:40] bzr-svn still has version warnings in place and so does bzrtools === thumper_laptop is now known as thumper [03:15] spiv: have you any immediate thoughts on: [03:15] ERROR: test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles) [03:15] vvvv[log from bzrlib.tests.test_versionedfile.TestVersionedFiles.test_add_lines_return(named-knit)] [03:15] bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrrIvkG0.log' [03:16] lifeless: huh [03:16] lifeless: just "that shouldn't happen", [03:16] :) [03:17] I have two things of concern here [03:17] lifeless: well, that and I would suspect the __dict__ clearing code that bit you yesterday might again be the culprit [03:17] one is is: "test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles)" [03:17] that id is the pyunit stock one, and wrong [03:17] the other is the mithing log [03:18] Which is pretty worrying if true, it's meant to make testing faster and easier, not harder! [03:19] Ideally, we'd only clear tests that fail (hmm, which might be part of the reason I put it in run, you can't figure that out from tearDown/cleanup that I know of) [03:21] well [03:21] I think the problem here is in the approach [03:22] reporting is done from objects to a stream [03:22] the size issue you were trying to address is due to keeping objects around [03:22] rather than cleaning up tests I suggest simply reporting to a stream at the time of failure [03:22] then delete the entire test object [03:22] Right, but keeping the test cases around is potentially useful. [03:22] e.g. with a graphical runner. [03:23] a graphical runner has different needs [03:23] I don't want to fight for hypothetical cases very hard, of course. [03:24] well I'm just aying that the graphical runner can set a flag/fail to set a flag that controls this [03:24] and in fact doesn't need to do either [03:24] its conceptually simple: [03:24] addError reports immediate [03:24] thats in the Result object, which the runner provides [03:24] the suite object deletes tests after running them [03:24] so rather than for test in tests: run() [03:24] its run(); del [03:25] Twisted has a suite that does that, IIRC. [03:25] a graphical test runner that wants to keep the objects just has addError keep a reference to the test object [03:25] I suppose an alternative spelling more like what I tried is "test.run(); test.cleanThyself()" [03:26] indeed; thats what I'm saying doesn't fit that well [03:26] (with smarts to only call cleanThyself on test objects that have that method, and only call it if the test passed...) [03:26] it makes the object interface more complex, because now you need a 'clean' concept added, rather than just 'you are not needed anymore' [03:26] I guess I'm a bit reluctant to rely on the gc here. [03:27] One useful way to think about this [03:27] the twisted stuff also wants to do evil things like run a test multiple times [03:27] is to consider subunit [03:27] jamesh: evil, but useful [03:27] you can instantiate the test twice to do that [03:27] thats simpler [03:27] spiv: a reload() type interface would be better for that [03:27] jamesh: I've certainly wished for that feature in other runners when trying to debug intermittently failing tests [03:27] spiv: so imagine all tests run under subunit - report *everything relevant* at failure time, and the object goes away. [03:28] I don't have any disagreement with instantiating a test twice to run it twice. [03:28] spiv: I really think this would be simpler and less prone to errors/race conditions [03:28] The only reason I see for keeping a test object around after running it is for debugging and reporting (and the reporting really ought to be all done by the time run() returns) [03:28] lifeless: I know you're busy, but if you have a chance to look at my bzr-dbus patches at some point it'd be appreciated [03:29] But it's relatively easy to accidentally hang on to objects, so rather than hoping that "del test" is releasing the last reference to the test case in the face of complicated test suite infrastructure, I thought that just resetting the test case object's state to the minimum possible would be more reliable. [03:30] Twisted has certainly found that trying to release all references is hard to do. [03:30] weak references can help catch that sort of bug [03:31] So, I'm completely happy to remove the reference, but it just seems prone to not actually having any effect unless we're always very careful. [03:31] jam: still around ? [03:32] spiv: so, can we tell how many references an object has ? [03:32] sys.getrefcount in CPython [03:32] spiv: so we can write tests that the test framework is wellbehaved [03:32] Although it's easy to get confused because you need a reference to it to ask how many references there are :) [03:32] for addCleanup etc [03:33] and if an individual test happens to leak; so beit - its much better than leaking 11111 tests [03:34] anyhow, late lunch for me [03:38] lifeless: it'd be clearer to do something like: ref = weakref.ref(test); del test; assert ref() is None [03:38] if you want to check for leaks [03:40] * spiv wonders why lifeless is noticing bugs here all of a sudden [03:40] * spiv -> food [04:03] spiv: well, the id() one had been annoying me for a bit, but I generally had only one variant failing, when I had 6 it become important [04:04] jamesh: re testing, yes, thats how to tell if its leaked; but you need to run the test framework in the middle there [05:38] lifeless, a word in your shell-like ear? [05:39] spiv and i are working on finishing the smart protocol changes [05:39] if the server is too old to understand the new request, we'll drop the connection and restart [05:40] unfortunately the previous logic for understanding the response to the 'hello' rpc is wrong; the client is upset if the server says it's newer [05:40] as i recall you thought this was a good move when we had another similar situation [05:43] so it looks like we will stop sending the explicit 'hello' from new clients, and instead just see what the server says about the first command [05:43] * igc pick up kids - bbiab [05:44] bye [06:06] poolie: uhm, I've never liked hello. If you are proposing to stop using hello's then great. [06:06] poolie: otherwise I think I don't understand your word [06:07] so, basically: just send a call in the latest version [06:07] if the server doesn't understand it, disconnect and try again [06:08] i think the only contentious part of this is: is it ok to drop the connection and restart if the server doesn't understand? [06:08] it's undesirable but avoiding it seems complex [06:08] so i think it's acceptable [06:08] hopefully this will be the last such transition [06:09] we already have the compromise of dropping the connection [06:09] so I think its fine [06:09] right [06:09] me too [06:10] I think it would be nice [06:10] if we could figure out the ssh magic to drop the ssh channel but keep the ssh session [06:10] full stop? [06:10] yes, spiv said that too [06:10] greats minds [06:11] mm [06:11] given all the different ssh situations i think that may be hard [06:12] without more ssh protocol knowledge I have no idea [06:12] if we really want to avoid dropping it i think we'd do better to start by sending a command in an old encoding which old servers will understand, but give an error without losing the connection [06:12] well, we use putty, paramiko, openssh and ssh.com ssh [06:12] and i think there is no standard way to get it... [06:13] it would probably be good to have some documentation about "hey you should turn this feature on" as it's generally useful [06:20] poolie: I'm not talking about master session stuff [06:22] i know, but it's similar, is it not? [06:25] I think the underlying mechanism is reused [06:29] yay, add_lines -nearly- done [06:29] deep depdency:) [06:30] well, I'm past 8 hours now, so gnight! === vigneswaris is now known as vigneswari === indraveni is now known as ksp === ksp is now known as indraveni [08:28] * igc dinner [08:39] poolie: Hmm, I've hit a surprise bug, so I won't get this patch to the list until tomorrow morning. [08:40] (it turns out I was forgetting to send the protocol version marker string on v3 responses!) === mark1 is now known as markh [12:00] I realize that this channel isn't exactly aimed at bzr-svn, but hopefully someone can help me. The problem is that bzr-svn changes SVN properties every time I do check-ins. SourceForge reports these changes and they seem to get longer every time. I don't ever do merging (I always rebase), so it seems as if bzr-svn doesn't really need the info it stores in the properties. Any idea whether bzr-svn can work without the property changes? [12:10] Winterstream: I don't know if bzr-svn could possibly work without them, but I don't think there is currently a way to turn it off at least. === cprov is now known as cprov-lunch === mrevell is now known as mrevell-lunch [12:27] Winterstream: there's no way to do that at the moment, but please file a bug and I'll have a look at implementing it for the next release [12:28] Winterstream: Not setting the properties will have to consequence that you can no longer pull from svn into the branch you pushed to === mrevell-lunch is now known as mrevell [12:47] hello all, running Gutsy server, added the intrepid main to my sources, ran update, checked bzr and it is still showing the old version. Is any one able to give me some help with this please? [13:00] gabees: By 'update' you mean 'apt-get update' or 'apt-get upgrade', or both? (1) You need both - update then upgrade (or dist-upgrade), and (2) I hope that gutsy server doesn't need to work. [13:02] gabees: Intrepid will break, and break hard, many times over the next month. [13:04] jelmer - I figured as much. Thanks :) [13:09] no look, I followed the instructions on the bzr site for upgrading it: https://launchpad.net/~bzr/+archive [13:09] it says to added these intrepid repo [13:09] but the repo only contains bzr and bzr-tools [13:09] I did update, and then upgrade [13:09] but it won't recognise the new version in the intrepid repo [13:09] hehe [13:10] i'm now trying to upgrade the entire server to hardy [13:10] that include 1.3 [13:16] <_paneb> is a repository usually created for each project? [13:16] <_paneb> or is there one repository for all projects (and their branches)? [13:29] _paneb: one repo for all [13:30] Depends on who created it and what they wanted to do. [13:31] <_paneb> i will be creating it, and i just want to control several projects [13:31] I tend to not mix projects in one repo. [13:34] <_paneb> when working "solo" do i create my repositories with trees? [13:41] <_paneb> nevermind, i understand now what --no-trees is for [13:42] Well, again, it depends on what you need. tree/no-trees is just a default; you can always create a tree on a branch without one, and remove a tree from a branch with one. [13:43] <_paneb> right [13:43] Some things I tend to create branches only to use right off, so they tend to be trees. Others a lot of branches sit around a while, so they're no-trees. [13:43] And then there are the work styles where you use lightweight checkouts somewhere other than the repo, in which case you want no-trees. [13:53] night all [14:02] upgraded to hardy heron now [14:03] that's got a newer version of bzr === mw|out is now known as mw === hmeland_ is now known as hmeland [14:21] lifeless: I'll be adding to that quilt/loom wiki page further when I can. [14:22] lifeless: It must be emphasized more strongly that carrying live changes in the working tree across threads (up-thread, down-thread, etc.) can be rather terrible. === mw is now known as mw|brb [14:23] lifeless: If conflicts occur, you are left in the unpleasant situation of having to extricate your valuable changes from a variety of potentially conflicting files. [14:23] I guess if your instinct is correct (restore from backups), things can go okay. [14:23] But my instinct in the past has been to quickly move back to the thread that I came from. [14:24] Which creates more conflicts. :) [14:24] Perhaps it would be good to refuse to switch threads when live changes are present? [14:25] (Or at least if arriving at destination thread will result in merges or conflicts) [14:25] s/merges/new merges requiring commits/ [14:26] live = uncommited? [14:27] bob2: yep [14:28] fbond: it is a design goal to allow you to switch with uncommitted changes [14:28] statik: ? [14:29] so you can make a change that should be on a different thread [14:29] realize it [14:29] switch threads [14:29] and then commit [14:29] jam: I'd like to believe that :) [14:29] fbond: conflicts are probably different [14:29] jam: But the reality of the situation is that the user experience is a bit jarring. [14:30] lifeless: I'll need you to create the bzr-1.5 branch when you get some pqm time. i'll try sending an email in case you miss this [14:30] jam: Both of those situations are an immediate headache (new merges, conflicts) [14:30] The only good way I know to deal with it is `bzr shelve', `bzr switch', [resolve,commit,etc], `bzr unshelve', [carry on with life] [14:31] But that requires some pretty good foresight. [14:32] fbond: I don't have much personal experience with the loom plugin, I just follow along :) [14:33] fbond: so what is causing the conflicts that you are trying to roll back to the earlier thread [14:33] I'm just trying to follow a little bit closer so I might give suggestions [14:33] jam: I hope this is not too harsh: loom is to what it should be as git's UI is to bzr's. [14:33] jam: There are a few different ways conflicts can happen. [14:34] Each thread switch is an implicit merge. [14:34] If I do: [14:34] bzr commit ... [14:34] bzr up-thread [14:34] I get a new merge that now needs to be committed. [14:34] (in the higher thread) [14:34] This merge can conflict. [14:34] Further, I can also have working tree conflicts. [14:35] How is "this merge can conflict" separate from "working tree conflicts" [14:35] The merge can conflict with the branch. [14:35] I guess I'm not understanding how the merge can conflict [14:35] So you get branch-branch conflicts as well as working tree-branch conflicts. [14:36] Threads are nearly branches. [14:36] I guess in the end the conflicts are all sitting in your WT, but they originate differently. [14:36] fbond: ok, so the files on disk get conflicted, but if you have live (uncommitted) changes they can also conflict [14:36] fbond: I was just confused by your terms [14:36] jam: Sorry, I don't know bzr's internal concepts as well as you do. [14:36] So I probably use bad language. [14:37] I wouldn't claim that [14:37] jam: I would :) [14:38] fbond: so the issue is that switching trees might conflict [14:38] Anyway, the end result is that switching threads can't be done as casually as you'd like. [14:38] and then after that you have an implicit merge [14:38] which might conflict *on top* of that [14:38] Right, conflicts aren't the only issue, though. [14:39] If I have uncommitted changes in the WT and I switch to a higher thread, causing an implicit merge (with no conflicts) my WT now contains my new changes, but it also contains a merge that needs to be committed. [14:39] So I have to extricate the changes that I was carrying around in the WT from the merge itself. [14:39] fbond: sure, I think the "switch with uncommitted changes" is meant more for down-thread, not up-thread [14:39] jam: Okay, possible. [14:39] and I see your point about difficulties [14:40] so.... what would be my resolution [14:40] jam: Yeah, I like using loom, but when I forget to shelve before these critical thread switches, it's pretty frustrating. [14:40] fbond: would it be easier if up-thread refused with uncommitted changes [14:40] or if you could at least set a flag for that [14:40] or require --force, etc [14:41] jam: Right. You could be a little more granular and say "up-thread refuses if the switch would result in uncommitted merges and/or working tree conflicts" [14:41] it would, unfortunately, make up-thread a bit slower, as it would have to check for changes before moving [14:41] But that might not be as predictable. [14:41] fbond: doesn't up-thread always result in an uncommitted merge [14:41] Hi! I just had bzr puke on commit on me: [14:41] http://pastie.caboo.se/192356 [14:41] I thought that was part of the design [14:41] jam: Nope. [14:41] well, I suppose it might already be merged [14:41] Exactly. [14:41] (And that is more often than not) [14:42] krow: have you been doing something interesting with the "plugin/daemon_example" directory? [14:42] It is at least claiming that you have a file inside it, but the actual directory is not present [14:44] krow: any chance you could paste "bzr log -r -10..-1 --short --verbose" ? [14:45] krow: this is bug #150438, btw [14:45] Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] https://launchpad.net/bugs/150438 [14:47] jam: Yeah... I did an rm without a bzr [14:47] hmm... sounds like an auto-detect error [14:47] we detect that the directory is removed [14:48] but don't propagate that to all the children properly. [14:48] krow: is this during "bzr commit "? [14:48] jam: Yes [14:49] krow: so you did something like [14:49] rm -rf plugin/daemon_example [14:49] bzr commit -m 'xxxx' [14:49] and it blows up like this? [14:49] or you did that a while ago [14:49] and now it is complaining [14:49] jam: Dd the rm and then did the commit [14:50] jam: Currently stuck at the commit... :* [14:50] jam: Currently stuck at the commit... :( [14:50] jam: http://pastie.caboo.se/192357 That is from the command you asked me to run [14:50] krow: you've been doing a lot of housekeeping :) [14:51] jam: Yes :) [14:51] jam: So thoughts on how to get out of this? [14:51] krow: well, there are certainly ways to reset things [14:52] I'm not sure what is best righ tnow [14:52] is the only change removing some directories [14:52] (aka easily redone) [14:52] or is there more complex stuff [14:52] krow: for example, you could do [14:52] cd .. [14:53] bzr checkout --lightweight plugin alt_plugin [14:53] rm plugin/.bzr/checkout [14:53] mv alt_plugin/.bzr/checkout plugin/checkout [14:53] krow: don't do it until we've sorted things out, though [14:53] that will reset bazaar into thinking you haven't done anything to your tree [14:53] So simple changes like removing directories should be fine [14:53] jam: Ok... [14:54] as should modified files, etc [14:54] renames will be lost [14:54] but you can use "bzr move --after" [14:54] krow: I would *really* like to understand how it got into this situation, thoguh [14:55] jam: All there is, is modified files and rm'ed stuff. No moving. [14:55] jam: I can save a copy of the tree. [14:55] krow: if you could, that would be nice [14:55] my concern is that it was the steps leading up to this that caused the problem [14:55] and a post-mortem isn't going to reveal the secrets [14:55] but it is better than nothing === mw|brb is now known as mw [14:56] fbond: it is pretty easy to detect if we would need to merge, would that UI suit you? [14:56] fbond: just to finish the conversation :) [14:59] I'm trying to make sure I understand something about bzr history and merging. In a situation with multiple developers having a centralized/remote shared repo (bzr+ssh access) and each having local shared repos with a branch from the remote trunk … is accurate? [15:00] I might be wrong on the version numbering in the merge commit. It probably makes more sense if the two developers both branch from (and "share") commit 1. [15:00] jsled, looks exactly like what I'm using :) [15:00] jam: Well, this thing is 596M tarred/compressed [15:00] jam: Is there a way to permanently snip history? [15:01] jsled, is there a specific concern for this workflow, or are you just making sure? [15:01] krow: well, you could rm .bzr/repository/packs/... [15:01] I'm mostly interested in the WT [15:01] also, a 'make clean' or equivalent is usually good [15:01] beuno: [15:01] jam: Problem: [15:01] so I'm not getting .o files [15:01] [brian@localhost plugin]$ bzr checkout --lightweight plugin alt_plugin [15:01] bzr: ERROR: Not a branch: "/home/brian/Other/mysql-6.0-brian/plugin/plugin/". [15:02] er. beuno: It's wicked confusing, as the revision numbers keep jumping around. [15:02] krow: did you miss the "cd .." ? [15:02] As well, trying to use the revision number as a build number becomes impossible. [15:02] It makes the history really hard to search for changes. [15:02] jsled: there is a recommended workflow which gets around that [15:02] jam: Yes, I'd be happier with the UI if it didn't help me shoot myself in the foot. [15:03] jam: Is the command from the root of the repository, or from outside of it? [15:03] and a flag you can set so that the second 'bzr push' won't let the mainline revno jump around [15:03] krow: you have "$repo/plugin" right? [15:03] where "plugin" is the branch? [15:03] so you want to be above the branch [15:03] jam: I've love to hear/read about it. I've thought baout trying to encourage the use of "rebase", but the workflow is already pretty complicated. [15:03] so that you can do "bzr co --lightweight a_branch other_branch" [15:04] jsled: so, #1 is to use a checkout for your mainline, which people then merge into and "bzr commit" to update the tip [15:04] let me check #2 real quick [15:04] #2 "echo 'append_revisions_only = True' >> .bzr/branch/branch.conf [15:04] hello all... [15:05] jsled, rebase is stronly disencouraged as it breaks history, and leaves branches unmergeable [15:05] we have one distro based on debian [15:05] jam, do you know what adding appen_revisions_only does? [15:05] planned to maintain source using bzr [15:05] beuno: if it would change your mainline revisions it refuses the push [15:05] jam: http://pastie.caboo.se/192366 [15:06] jam, does it force #1 or similar, or just create new revs instead of subrevs? [15:06] currently we have the bzr repo in local machine and our team is using locally using ssh authentication [15:06] jam, ah, that's what I thought, thanks :) [15:06] beuno: breaks history? To be clear, by "rebase" I mean the process of moving a sequence of commits to the tip after each pull … basically so there are no merge commits. [15:06] but i dont know how to make it public [15:06] krow: interesting.... I think I know why, but trying to figure it out for a second [15:07] bzr+ssh is better or ftp? [15:07] krow: I believe what is happening is that "bzr checkout" is trying to copy files from your source checkout, and failing [15:07] want to know hoe to configure this [15:07] krow: so we need to tell it that there isn't actually a checkout there [15:07] krow: so do "mv mysql-6.0-brian/.bzr/checkout mysql-6.0-brian/.bzr/checkout-old" [15:07]