[00:10] okay so I'm new to bzr but been using svn for years. Thought I understood Bzr differences but now not so sure. [00:10] I created a repos on my local machine using bzr init. [00:10] Then after a few revisions I realized I was going to need a central repos and created it with init-repo [00:11] then using bzr export I copied the files over and thought I had a central repos all set up. [00:11] I could pull from it but not commit to it. [00:11] I think because it didn't have a working tree. [00:12] so I used 'bzr update .' to create a tree in the repos [00:15] the problem is (I think) that my original branch seems to have its own repo and doesn't seem to be tracking from the central repo. So I *think* all I want to do is update something to tell my local copy to use the branch at the central repos as its trunk now. [00:15] You may find the "bzr info" and "bzr reconfigure" commands helpful [00:16] but I'm not *sure* that's what I want and don't know how to do it yet. (though If I'm confident that's what I want to do I'm sure I can look up the commands) [00:16] thanks spiv [00:16] But also I think you are confusing some concepts [00:16] A shared repository is independent of whether a branch/checkout is "tracking" (as you put it) another branch. [00:17] A shared repository, the thing you create with "bzr init-repo", is basically just a storage (and speed) optimization. [00:17] It doesn't actually affect the behaviour of the branches that use it. [00:19] yeah I'm not too clear about what's not working there. At first everyone could pull or checkout but no could commit and I don't think they could update from the central repo. Now that I have a working tree there that may change but it seems from what I'm reading that I shouldn't need a working tree at the shared repo [00:25] "bzr info" is useful for inspecting how things are connected. [00:39] okay so I think what I want to do is from my local host branch run 'bzr reconfigure --use-shared ' [00:40] then it seems like I don't need the working tree in the shared repo (is there any reason I should remove the tree that's there?) [00:45] When I tried that I got 'bzr: ERROR: sftp://repo/path/branchName/.bzr / is not a local path' [00:54] A branch can only use a shared repository in one of its parent directories. [02:17] spiv, I'm in the top level directory for the branch. (if that's what you mean) === mtaylor|afk is now known as mtaylor [02:54] knighthawk: no, I mean that if you branch is at directory /a/b/c/your_branch, then the shared repository has to be at /a/b/c, /a/b, /a, or /. === Ursinha is now known as Ursinha-afk === mm-mysql_ is now known as mm-mysql [04:51] ah thanks spiv [04:55] okay so no errors now but bzr info still says its a stand alone branch [05:03] knighthawk: 'bzr reconfigure --use-shared' will change that, if there's a shared repo it can use (i.e. there's one in a parent directory) [05:10] spiv, so before I was trying 'bzr reconfigure --use-shared sftp://path/to/repo/project' now I'm doing 'bzr reconfigure --use shared sftp://path/top/repo/' and like I said no errors now. but bzr info hasn't seemed to update. [05:21] knighthawk: You're doing 'bzr info sftp://path/to/repo/project' ? === spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Santa Claus | | 2.3b4 is officially out ! (rm vila) [07:46] hi all ! [07:50] yeah for Santa Claus, best pp ever :) [07:51] vila: :) [07:52] lol [07:52] spiv: before you leave: enjoy your... leave :) and Happy Christmas ! [07:53] vila: thanks, you too! [07:53] vila: so to leave with a bit of a negative review on one of your patches :( [07:54] vila: it looks like a step towards the right fix, but not yet a complete fix. [07:54] s/so/sorry/ [07:54] Wow, I'm so sorry I couldn't even type the word! [07:54] well done (reading now), if it doesn't fix it, better to catch it now :) [07:55] ok, read [07:56] hehe, I said it and will keep saying and thinking it, importing symbols is confusing :) [07:56] REPORT_ONLY_FIRST_FAILURE is defined only in doctest, so it should be prefixed [07:57] All the more reason for consecutive lines to be consistent ;) [07:57] DocTestSuite is redefined in bzrlib.tests and is the one we want to use so should *not* be prefixed [07:57] Oh, redefined with the same name? Ew. [07:57] *That* is confusing. [07:57] right [07:57] Rename to BzrDocTestSuite perhaps? [07:58] should I rename it BzrDocTestSi... :) [07:59] now, whether this fix 321320 is a bit blurry, it *fixes* the issue with brnchbuilder as EMAIL is now set correctly, but HOME is still problematic [07:59] more broadly, setting evn vars to None is always ok, setting them to specific values is always tricky [08:00] I think I said that in the comments, but you rightly point that we have been wrong with HOME [08:00] so coming back the beginning of the discussion: I see nothing negative here :) [08:01] It doesn't fix the branchbuilder issue for me: it still executes gnome-gpg, as specified by my ~/.bazaar/bazaar.conf [08:01] yup [08:01] my bad, I don't encounter the issue and failed to check it [08:02] To be fair it helps, because HOME is now set to the cwd rather than my actual HOME [08:02] But sometimes my cwd == $HOME :) [08:02] yup, that's wrong anyway [08:02] (Also there are other ugly side effects like spewing .bzr.log into odd places) [08:03] still ??? [08:03] Well, into the cwd [08:03] doctests spew .bzr.log files ?? [08:03] suspicion or fact ? [08:03] grr, two different threads [08:03] did you see .bzr.log files ? [08:03] vila: Well, when my cwd == $HOME, the tests wrote to my ~/.bzr.log [08:03] bah, I can check that [08:04] hmm [08:04] Hmm, but apparently not to the other dir I tried? [08:04] Odd. [08:05] anyway, mgz + spiv 1 - 0 vila, back to drawing board :) [08:05] Anyway, set HOME to a temporary dir in doctests and I'll stop caring :P [08:05] yup [08:05] mgz was asking for roughly the same thing in different words [08:05] It may mean pulling out more of the isolation code into functions [08:05] exactly his words :) [08:06] Oh, and your branch isn't linked to the bug! [08:06] * spiv just noticed [08:06] I resisted a bit because doctests use setUp/tearDown, no way to have a addCleanup there [08:06] haha freudian slip ! [08:07] Ok, EOD and EOY for me here. [08:07] FWIW I think addCleanup is possible [08:07] thanks for the review and the discussion ! [08:07] You could build it with bzrlib.cleanups perhaps [08:07] But, really gone now :) [08:07] yeah, no *easy* way to have [08:26] wow, setting HOME to None doesn't annoy our test suite *at all*... [08:27] I wonder if... it doesn't get set by some lower level layer though... or what will happen on other OSes... [08:39] vila: you have no $HOME [08:40] yeah, looks like Linux is friendly with the homeless ones, why am I not surprised :) [08:40] * vila runs it on babune to see how other OSes consider homeless tests :D [08:41] That's not really homeless, though, it's only virtually homeless. [08:42] fullermd: is this just a joke or are you trying to convey some intuition there ? HHOS [08:43] I find it hard to believe that you can run that much code without HOME being set... [08:44] but I can't deny successful test either... [08:44] testS even, ~24000 and some [08:44] Well, what's it need $HOME for, anyway? Just looking up bazaar.conf and plugins, neither of which it needs? [08:44] for bzr itself, yes, but no other lower level stuff ? [08:45] no unix centrism at all ? Nowhere ? [08:47] .bzr.log in addition to plugins and config files, may be apport stuff too... [08:47] but apport is disabled most of the time and .bzr.log files... may handle being homeless [08:50] Actually, doesn't the test suite override $HOME for that stuff anyway? [08:53] Almost all the test suite overrides $HOME, yeah. Off the top of my head the only bits that don't are doctests, and vila's fixing that... [08:53] fullermd: that's the issue I'm looking at, it wasn't for the doctests, now it does (in a pending submission), I changed it to make HOME == `pwd` and spiv raised some valid concerns when pwd == $HOME (the real one) [08:53] so I tried setting HOME to None (aka deleting it from os.environ) and wow, it passes [08:54] * spiv isn't really here, of course. [08:54] I think I will set it to some tmp dir, just because it's... scary , but the experiment is worth a try [08:55] nothing beats what the English expression for demonstrating something by checking that the opposite is absurd ? [08:55] Hey #bzr-ers [08:56] I'm happy these days using bzr as a Subversion client, I hardly ever have to invoke 'svn' itself any more [08:56] but, increasingly I am being called upon to look at and work with repositories in Git or Mercurial, and it seems like the plugins for interacting with those are pretty primitive. [08:56] Which seems weird, given that as DVCSes their data models are more similar to bzr's than svn's is. [08:57] Is there a plan in the works for improving support for them? [08:58] glyph: given that the plugins main author is joining the bzr team next year, I'm very tempted to say the situation can only improve... === vila is now known as vila-afk [08:59] vila-afk: jelmer? [09:00] bob2: himself [09:00] oh, cool [09:02] vila-afk: "next year" like "in a week, when it's january" or like "in 12 months"? [09:02] glyph: the former, but make that a month [09:02] * vila-afk really afk now ! [09:03] okay that is awesome. [09:03] thanks for the info :) === Ursinha-afk is now known as Ursinha [12:57] hi [12:58] is it normal for bzr to need to send 100kb to the server to commit a change which consists ofa single line in a single file? [13:04] mxc: Yeah, probably. It needs to find out what it has to send. Is it using a smart protocol (e.g. bzr+ssh, not sftp)? [13:04] nope, sftp [13:04] mxc: Oh, then that definitely sounds normal. [13:04] oh, ok [13:05] More or less. I mean, I don't know the exact usage expected, but it sounds about right to me. [13:06] Over a dumb protocol, it can't just ask the server "What do I need to send?", it has to go digging around in the repository's files. [13:06] Plus, it likely grabs more data then necessary sometimes to reduce roundtrips. [13:07] Anyway I'm about to pass out from hunger bbiab [13:07] is there anyhting dangerous if i unbind my repo and rebind to hte same repo using bzr+ssh isntead of sftp? [13:09] Probably not? There should be a "switch" command or such. [13:09] If you mean a branch rather than a checkout, just push/pull --remember. [13:10] Which is safe as can be. === frakturfreak_ is now known as frakturfreak [15:02] hello, is there a way to have multiple push locations ? (i.e. every "bzr push" will push to 2 different locations) [15:03] * mgedmin would like [15:03] tacone: not with stock Bazaar, there might be a plugin that does [15:04] i only found bzr-push-and-update but I'm not sure it's doing that. the documentation is confusing [15:05] no, bzr-push-and-update doesn't provide that [15:06] oh, ok. [15:06] does bzr push lock the source branch? [15:07] mgedmin: it should only read-lock [15:07] * mgedmin is considering a plugin to mirror his branches in the background, while he continues working in the foreground [15:07] so that would mean I can't bzr commit if there's a push going on [15:07] hm [15:07] mgedmin: I think that should work [15:16] jelmer: maybe the repo-push plugin ? [15:17] tacone: that pushes an entire repository, it doesn't push to multiple locations [15:17] tacone: I think you'd either have to write your own or use a shell script or something like that [15:17] guess i'll go for a shell script. thanks === joey is now known as Rinchen === Rinchen is now known as Launchpad === Launchpad is now known as joey === joey is now known as linaro === linaro is now known as launchpad === launchpad is now known as joey [16:26] could anyone please update me what's the current status on nested subtree support in bzr? my experiments with bzr join --reference (still in beta i know) concluded that this feature isn't quite useable yet (at least for what i wanted to do) [16:26] what's the current best practice then for nested subtrees? [16:28] frathgeber: nested trees are not supported yet - there are a few plugins that provide similar functionality [16:28] bzr-externals being the most notable one probably [16:31] jelmer: thanks, that's what i figured from some research [16:32] problem is i want to bootstrap my dotfile configuration from a bzr repo when deploying on a new machine. and if that depends on a bzr plugin already installed it somehow defeats the point [16:33] any good idea what i could do in this case? === jelmer_ is now known as jelmer === Ursinha is now known as Ursinha-lunch === vila-afk is now known as vila [17:50] mgz: how is testtools trunk looking to you? [17:51] C:\bzr\testtools>testtools\run.py testtools.tests.test_suite [17:51] Tests running... [17:51] Ran 586 tests in 2.688s [17:51] OK [17:54] righto [17:54] will do a 0.9.9 todayish [17:54] hey [17:54] what did 0.9.8 miss? [17:54] did you see I rewrote a bunch of stuff in testrepository [17:54] * mgz looks at the log [17:54] I was wondering if if you could update your patch[es] [17:55] and then I'll merge them [17:55] will do. [17:56] mgz: 0.9.8 missed two defects in testresult.time() handling [17:56] which got highlighted when testrepository started depending on it for parallel test partitioning [17:56] ugh, datetime is such a pain. [17:57] yes, the 'no timezone' instances are BONG [17:57] I really don't understand why they did that. I mean, for simple floats, time.time() stuff - understandable. But /datetime/ ?! [17:57] sorry, ‽ [18:16] ah, that's what these DocTestMatches failures are about, should have thought of it before [18:16] (Pdb) actual [18:16] "True True True\r\n['b:\\\\temp\\\\tmpgohhtz\\\\testr', 'foo bar', 'baz']\r\n" [18:16] it's dumb about newlines! [18:31] fixing the last two failures is hard, because the actual code is bad and wrong [18:32] elements = [command] + list(testargs) [18:32] cmd = ' '.join(elements) [18:32] you can't do that, it's unsafe. [18:32] the problem is that TestListingFixture wants a string for `self.template = cmd_template` [18:32] not a list, which could be used safely. [18:33] how much of a breaking change would it be to just fix that lifeless? === Ursinha-lunch is now known as Ursinha [19:21] just noticed bzr replaced a '!!' in my commit message with 'bzr stat' seems odd. [19:35] mgz: TestListingFixture hasn't been in a release [19:35] mgz: so there are no api concerns about it at all [19:36] hazmat: thats your shell [19:36] hazmat: almost certainly [19:39] lifeless, hi, is there any guide or doc about using bzr on nfs [19:39] zyga: don't do it? [19:39] lifeless, I have a tiny standalone branch [19:39] several dozen KB [19:40] zyga: the branch and repo formats will work fine on nfs, as they do even on ftp [19:40] lifeless, indeed it is [19:40] bzr status on that branch takes megabytes of transfer and does not complete [19:40] the working tree needs reliable operating system locks. [19:40] lifeless, I have nfs4 so locks should also work [19:40] but I worry about just not working fast enough for anything [19:41] zyga: we get a constant stream of 'does not work on nfs' -> 'check your locks' -> 'oh! that works' [19:41] right now it's taking ~40Mbit to bzr status in that 10 file branch [19:41] zyga: however, the many megs of transfer is a kernel bug [19:41] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480444 [19:41] Ubuntu bug 480444 in linux (Ubuntu) "packet storm with linux NFSv4 client when calling ftruncate()" [High,Triaged] [19:41] oh [19:41] that's new! :) [19:41] 2009 [19:43] thanks, that at least makes the debugging operation far shorter [19:44] zyga: de nada [19:45] mgz: why the change in testcommand from cmd = .., repeated to daisy-changed .replaces ? [19:46] mgz: I find the latter an uncommon style in python, even though its hyper-common in (say) smalltalk [19:46] oh, .replace instead of re [19:47] mgz: why? [19:49] mgz: also, why are you not looking for bin/testr in the test_setup change? [20:03] mgz: why? <- see latest comment and re.sub documentation [20:03] [20:04] "repl can be a string or a function; if it is a string, any backslash escapes in it are processed. That is, \n is converted to a single newline character, \r is converted to a linefeed, and so forth." [20:05] so re.sub("\$BLAH", "C:\\temp", "$BLAH") -> "C:\x09emp" [20:05] mgz: also, why are you not looking for bin/testr in the test_setup change? <- because DocTestMatches was just outright borked there [20:06] probably was the newline thing again, might be able to do .replace("\r", "") and revert what it's looking for. [20:07] ^(personally, I find chained replaces less silly than repeated assignments to the same variable, and the least worst option when not doing something one-pass fancy) [20:10] oh, and looking for bin/testr needed changing anyway, there's nothing binny on windows [20:11] the script goes in Python24\Scripts\testr or similar [20:11] if you tell me what that check is actually trying to confirm, I can write a portable version of it. [20:13] mgz: I want to check that that some known thing - e.g. the entry point script - is shown by the setup command [20:13] as a proxy for 'and setup works properly' [20:13] what you made it look for is too early in the process [20:13] how about checking each of the "running X" steps lines exists? [20:14] rather than just the one I used. [20:14] I want to see project data [20:17] I'm not inclined to believe that setup.py's overview output tells us anything interesting about it, given failures I've seen in the past. [20:21] well would " running install_scripts\n... adding '...testr'\n..." do then? [20:22] otherwise need to pull something in from distutils to get the dir it installs scripts to [20:34] mgz: that would be fine [20:37] vila: hi [20:39] hurgh, and then the matcher output formatting confused me. [20:39] the real output doesn't have a four-space indent. [20:57] hello, is there any method to concatenate 2 working tree and have the second start at the end of the first ? [20:58] i mean the first revision of the 2nd should be the last revision of the first+1 [21:39] hey there, I'd like to, say, "grab commits 2..6 from branch foo", then commit 1-2 commits, then "grab commits 8..10 from branch foo", but *without* losing the individual history of those commits [21:39] ie I'd like to keep the commit messages, author, timestamps, etc [21:39] is it possible? [21:40] sounds to me like a mix of the concepts of cherry-picking and rebasing, but I don't know if bazaar can do this [21:41] tacone: I think you want "bzr join"? [21:42] mkanat does bzr join allow me to concatenate 2 trees consequentially ? [21:42] tacone: bzr help join [21:43] doc is not clear to me [21:44] btw: The TREE argument should be an independent tree, inside another tree, but not part of it. [21:44] seems not what i'm looking for [21:49] tacone: You could make it do what you want. [21:49] tacone: Unless you're talking about two trees with identical file names. [21:50] tacone: In which case, AFAIK, the answer is "unfortunately no". [21:50] ... [21:50] maybe i could try to merge the rev.1 of the second tree in the first tree [21:50] and try to simply bzr pull [21:51] tacone: I'm not sure you can merge trees that don't have anything in common. You could try though. [21:52] any revisions in common, that is. [21:52] yes i can, i just need to handle conflicts [21:54] tacone: Well, true. [21:54] tacone: But the history of the files won't be merged. [21:55] tacone: They will appear to be separate files, just like if you'd done join and then mv. [21:55] Oh, although I suppose they don't have to be. [21:55] not sure [21:55] You would have to do the file content merging manually, though. [21:55] but it really does not matter in my case [21:55] oh, maybe bundle-revisions is what I'm looking for [21:59] nekohayo: perhaps you just want [21:59] merge -r 6 source; commit; merge -r 10 source; commit [21:59] nekohayo: however, if you want to skip a revision, you either need to back it out (as a commit) or rebase [22:00] lifeless, but then I'd lose the original commit message, author, timestamp [22:00] nekohayo: merging a prefix of a branch doesn't lose metadata [22:00] huh? [22:01] if a branch has 10 commits [22:01] merging the first 5 preserves the revision graph, all the original data is there [22:01] if you then merge the last 5, same thing applies [22:01] its only if you want to skip a commit that things become cherrypicks (which is what rebases are) [22:02] yeah, the problem is that I want to skip a commit in the middle and replace it by something else [22:02] so you can rebase, which will make commits that appear like the originals but have new revision ids [22:03] I thought you could only rebase "onto" something [22:03] the command is called 'replay' [22:03] the internal logic is that of rebase [22:03] its in bzr-rewrite [22:05] lifeless, for some reason I can only find the doc page for http://doc.bazaar.canonical.com/plugins/en/rebase-plugin.html [22:06] the rebase plugin was renamed to rewrite to reflect its broader mandate [22:07] wow, replay does almost everything [22:07] except it doesn't preserve the author [22:08] (I used bzr replay -r 159..164 ../reworkd/ ) [22:08] is there something like that but that keeps the author? [22:08] that may be a bug, it predates the separated author facility [22:09] hm? [22:09] probably fairly easy to fix - could you file a bug to start with? [22:09] bugs.launchpad.net/bzr-rewrite [22:09] * nekohayo files a bug [22:12] filed as https://bugs.launchpad.net/bzr-rewrite/+bug/693949 [22:12] Ubuntu bug 693949 in bzr-rewrite "bzr replay doesn't preserve the author of commits" [Undecided,New] [22:15] what's the easiest way to get an interdiff in svn without actually committing... [22:16] probably need to copy the whole tree. [22:16] difftacular [22:17] or diff -r branch:/..:54 [22:17] oh [22:17] svn... bzr import-svn :) [22:18] :) [22:29] guess my best option is to reimport manually my 13 revision on the top of the new branch [22:31] nekohayo: I can't reproduce that [22:31] huh [22:32] what version of bzr rebase? [22:32] I'm using the one that came with ubuntu 10.10 [22:32] I'm using trunk [22:33] but I don't think this part of the code has changed recently [22:35] * nekohayo just tried again, same result [22:35] nekohayo: with trunk, or with 0.6.1 ? [22:36] 0.6.1; I'll try a bzr branch lp:bzr-rewrite into my ~/.bzr/plugins [22:36] .bazaar/plugins/ I mean [22:37] bzr branch lp:bzr-rewrite ~/.bzr/plugins/rewrite [22:37] nekohayo: ^ [22:38] ya [22:38] lifeless: s/\.bzr/.bazaar/ [22:38] ok done [22:38] still seeing the bug [22:38] (I did remove bzr-rebase from synaptic to be sure) [22:39] jelmer: blah yes [22:39] nekohayo: did you see my reply to the bug? [22:39] nekohayo: bzr plugins -v [22:39] will show what plugin is being loaded [22:39] nekohayo: can you paste the output of "bzr log -r -1" ? [22:39] oh I hadn't seen your comment [22:39] hang on [22:40] oh, I'm an idiot. [22:40] bzr viz shows the committer, not the author [22:40] /headdesk [22:41] hmm, I guess it would make more sense for it to show the author(s) [22:41] nakohayo: feel free to retarget the bug to bzr-gtk [22:41] you mean nobody had filed a bug about this before? [22:42] Not that I remember [22:46] there you go [23:16] nekohayo: thanks! [23:16] jelmer, just to be sure, bzr viz is not going away is it? [23:16] I mean it won't get replaced by bzr explorer or something? [23:16] * nekohayo likes its simplicity [23:22] nekohayo: no, it's not going away. it hasn't really had the attention it deserves recently though