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