| michaelh1 | Using bzrlib, how can I get a list of log entries from revision n to tip? | 00:10 |
|---|---|---|
| michaelh1 | (I'm afraid I got lost in bzrlib/log.py) | 00:10 |
| mwhudson | michaelh1: bzr log -r n.. | 00:11 |
| mwhudson | oh bzrlib | 00:11 |
| michaelh1 | Yeah, I thought I'd be good :) | 00:12 |
| mwhudson | michaelh1: if n is a integer, i.e. you're looking for a mainline rev | 00:12 |
| mwhudson | start at tip, walk back along parent_ids[0] counting down the revision number until you get to n | 00:12 |
| michaelh1 | mwhudson: how do I access tip from a branch? | 00:13 |
| michaelh1 | s/branch/Branch instance/ | 00:13 |
| mwhudson | michaelh1: last_revision_info() i think | 00:13 |
| michaelh1 | Hmm. last_revision_info is a tuple - how do I match that up with parent_ids[]? | 00:14 |
| mwhudson | michaelh1: like this http://pastebin.ubuntu.com/470870/ | 00:17 |
| michaelh1 | Ta. I'll give it a try | 00:18 |
| michaelh1 | So --fixes is encoded as a revision property called 'bugs', which is a string with one 'URL fixed' per line? | 00:26 |
| mwhudson | michaelh1: yes, something like that | 00:31 |
| james_w | michaelh1: branch.last_revision() is just the revid part of last_revision_info() fwiw | 01:53 |
| davidstrauss | Where can I get the plugin for fast-export? | 02:14 |
| davidstrauss | Is it part of fast-import? | 02:14 |
| lifeless | yes | 02:17 |
| rioch | how do I create a new branch? I want to use this branch to develop a feature that may a while, and during that time people may want to try it out. | 08:08 |
| rioch | so I basically want a copy of my trunk, but as a new branch, if that makes sense | 08:08 |
| fullermd | That would be the common case :) | 08:11 |
| fullermd | bzr branch trunk whatever-you-wanna-call-it | 08:11 |
| fullermd | For other people to try it out, you'd just have it (or push it) somewhere they can access it. | 08:13 |
| rioch | it's hosted on launchpad | 08:18 |
| rioch | so if I do all this locally, and then push, I'll have my new branch. Then I push the changes I make to that new branch, et voila!? | 08:18 |
| fullermd | Well, it would only be et voila if LP had a French translation of course, but... | 08:19 |
| rioch | :) | 08:22 |
| rioch | fullermd: so what happens when you do the branch command? Couldn't I just push trunk to a new location? | 08:26 |
| fullermd | When you `bzr branch trunk foo`, you create a new branch foo that is (at present, anyway) just a duplicate of trunk under another name. | 08:27 |
| fullermd | It could just remain forever a sometimes-out-of-date copy of trunk of course, but in this case you'd go on and work with it so that it becomes something new based on trunk (presumably with trunk periodically merged in to keep up-to-date). | 08:28 |
| parthm | rioch: the bzr tutorial has a section on launchpad that you might find useful: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/using_bazaar_with_launchpad.html#accessing-code-in-launchpad-using-bazaar | 08:28 |
| fullermd | Then you'd have that foo to push a copy of somewhere for other people to access. | 08:29 |
| rioch | so should I first make some changes and then push to a new branch, or should I first push to the new branch and then make changes? | 08:42 |
| fullermd | Six and a half of one, half a baker's dozen of the other. | 08:43 |
| rioch | So make changes first. ok. | 08:44 |
| rioch | Just need to find a whisk. | 08:44 |
| fullermd | You can tear up a spatula with a sharp knife in a pinch. | 08:44 |
| rioch | Just need to find a knife. | 08:48 |
| rioch | And a spatula. | 08:48 |
| rioch | Dammit. | 08:48 |
| fullermd | If we had some eggs we could have eggs and ham... | 08:49 |
| rioch | I crave marmite. | 08:50 |
| fullermd | Well, you're own your own there; bzr can't help you :p | 08:51 |
| rioch | :) | 08:58 |
| ronny | hi | 09:31 |
| ronny | whats a good way to ask bzr for the number of revisions in a repo | 09:32 |
| jpds | ronny: bzr revno ? | 09:32 |
| ronny | jpds: thats not the number of revisions | 09:33 |
| bialix | bzr info -v | 09:33 |
| bialix | hello bzr | 09:33 |
| ronny | hum, how do i do it with bzrlib, i already god a repository object and a branch object | 09:34 |
| ronny | i used to count the results of iter_merge_sorted_revisions but since that just started to break i tought i should do it propper now | 09:35 |
| lifeless | theres a stats method | 09:35 |
| lifeless | I don't recall what it is offhand - check pydoc bzrlib.repository.Repository | 09:35 |
| lifeless | gather_stats or something | 09:35 |
| ronny | lifeless: yup, that works, thanks | 09:41 |
| === jelmer_ is now known as jelmer | ||
| === khmarbaise_ is now known as khmarbaise | ||
| magcius | ow ow ow | 11:38 |
| jelmer | hi magcius | 11:38 |
| magcius | uggh, so another project on Launchpad decided to change its trunk branch | 11:39 |
| magcius | for no reason | 11:39 |
| magcius | I'm stuck here with the outdated URL on my branch for about three or four weeks because it doesn't update | 11:39 |
| magcius | now I have no clue how to get my patches back on trunk, there's no real "pull --rebase" like in git | 11:39 |
| magcius | how do I create a patch? | 11:40 |
| jelmer | magcius: there is bzr rebase | 11:40 |
| magcius | there is? | 11:40 |
| jelmer | magcius: It's part of the bzr-rewrite plugin. | 11:41 |
| magcius | oh, a plugin | 11:41 |
| magcius | hm | 11:41 |
| magcius | is there any way to do it without it? | 11:41 |
| magcius | That's the worst endorsement of a system I've ever heard: "it needs community plugins and support to make it actually usable" | 11:42 |
| magcius | I'll stop trolling now. I just want to get this to work. | 11:42 |
| LeoNerd | rebase is evil, try to avoid it | 11:45 |
| LeoNerd | It rewrites history, so it's very rude to anyone else watching your branch | 11:45 |
| AnMaster | I have a question: how to make bzr *not* ignore *.~[0-9]+~ files? | 11:45 |
| AnMaster | yes I have some rather good reasons for it, trying to version a historical system using that for versioning. But since I have problems setting it up I want to not have to extract a pristine tar ball every time. | 11:46 |
| bialix | AnMaster: new ! syntax in .bzrignore does not help? | 11:54 |
| GaryvdM | magcius: Rather merge than rebase | 11:56 |
| AnMaster | bialix, hm, didn't know about that. How new is it? As I said historical system. Due to bitrot I'm using an old debian version in a vm to contain it. So I guess I might need to update bzr in the vm first. Since it seems to be bzr 0.90 | 11:57 |
| AnMaster | XD | 11:57 |
| magcius | GaryvdM: harder said than done | 11:57 |
| bialix | AnMaster: it's new in 2.1 | 11:57 |
| AnMaster | ah, do you happen to know if that works with python 2.5 ? | 11:57 |
| bialix | 0.90 is archaic, you know | 11:57 |
| AnMaster | bialix, I'm well aware of that it is archaic | 11:58 |
| bialix | AnMaster: another solution is to edit global ignore file | 11:58 |
| bialix | heya GaryvdM | 11:58 |
| GaryvdM | magcius: ??? A rebase involves doing a merge, just it is not recorded. So if you are getting conflicts with merge, you are also going to get them with rebase. | 11:59 |
| AnMaster | bialix, I don't have any issues with upgrading it as long as I don't need to update half the system to do it, which is quite probable | 11:59 |
| GaryvdM | Hi bialix | 11:59 |
| AnMaster | oh well *goes to test if it works* | 11:59 |
| magcius | GaryvdM: uhh | 11:59 |
| bialix | AnMaster: 2.1 is python2.4-python2.6 compatible | 11:59 |
| AnMaster | bialix, ah, no issues then | 11:59 |
| magcius | GaryvdM: ok | 11:59 |
| bialix | GaryvdM: https://bugs.launchpad.net/qbzr/+bug/487115/comments/12 | 12:00 |
| ubot5 | Launchpad bug 487115 in QBzr "qcommit: qt warning message in the console when files grouped into directory (affected: 1, heat: 4)" [High,Confirmed] | 12:00 |
| AnMaster | bialix, by the way, in case you are curious: The historic system is OpenGenera, related to lisp machines. :) | 12:00 |
| bialix | AnMaster: never heard of | 12:00 |
| AnMaster | ah | 12:00 |
| AnMaster | strange, reactions are always "never heard of it" or "wow cool", never in between. | 12:01 |
| * bialix is mostly windows guy, but don't say anybody | 12:01 | |
| AnMaster | bialix, suffice to say, the documentation contains references to ARPANET ;P | 12:01 |
| GaryvdM | bialix: Cool. going to close the bug then. | 12:01 |
| bialix | wow cool | 12:02 |
| bialix | GaryvdM: I found some minor issues with new installer | 12:02 |
| GaryvdM | bialix: What's that? | 12:04 |
| bialix | GaryvdM: qbzr should be dependecy for explorer. now it's not. some other subtle items, I need some time to articulate them | 12:05 |
| bialix | qbzr used to be such dependecy | 12:05 |
| bialix | and maybe we should bundle the latest version of explorer, now there is stable 1.0.2 | 12:05 |
| GaryvdM | bialix: ok | 12:06 |
| bialix | GaryvdM: nothing serious, really; just things I've noticed | 12:06 |
| GaryvdM | bialix: Just pushing my bzr-windows-installers branch to trunk. | 12:06 |
| bialix | ok | 12:07 |
| bialix | GaryvdM: we should release qbzr 0.19 ASAP | 12:07 |
| bialix | this Saturday maube? | 12:07 |
| GaryvdM | Ok | 12:07 |
| bialix | when the Ubuntu freeze? | 12:08 |
| bialix | GaryvdM: freeze at Aug 12; we have 2 weeks | 12:09 |
| GaryvdM | I've been trying to fix some bugs I've missed today. (like bug 537202) | 12:09 |
| ubot5 | Launchpad bug 537202 in QBzr "qcommit: ignored files added when non-versioned and select all checked (affected: 2, heat: 2)" [High,Confirmed] https://launchpad.net/bugs/537202 | 12:09 |
| GaryvdM | I have a test case, and 3 different ways to fix it... | 12:10 |
| * GaryvdM pushed to lp:bzr-windows-installers | 12:10 | |
| bialix | hmmm | 12:10 |
| bialix | GaryvdM: ok, maybe we should make release next week | 12:11 |
| GaryvdM | bialix: Ian rewrote the .iss generation code, so it is likely that the dependency bug has crept in there. | 12:11 |
| bialix | tomorrow is not the best idea | 12:11 |
| bialix | GaryvdM: yup | 12:11 |
| bialix | GaryvdM: how you're building the installer? | 12:13 |
| GaryvdM | Bla - keyboard short cut + dvorak fail | 12:14 |
| GaryvdM | bialix | 12:14 |
| GaryvdM | bialix: I'm building on the ec2 server | 12:14 |
| * GaryvdM not sure if that's what you were asking... | 12:14 | |
| GaryvdM | bialix: What are your thoughts on my bzrw patch (https://code.edge.launchpad.net/~garyvdm/bzr/bzrw/+merge/31133) | 12:15 |
| bialix | GaryvdM: sorry, don't look at it yet. | 12:16 |
| GaryvdM | bialix: short story: I've cleaned up Naoki's stderr patch, and I want it to ship with 2.2 | 12:18 |
| bialix | I will try to look at it on weekend | 12:23 |
| GaryvdM | bialix: Ok - thanks | 12:24 |
| bialix | GaryvdM: ping | 13:12 |
| GaryvdM | Hi | 13:12 |
| GaryvdM | bialix: pong | 13:12 |
| bialix | new PyQt draws qlog graph differently. | 13:12 |
| bialix | is it intended? | 13:12 |
| GaryvdM | No. Please imagebin screen shot. | 13:13 |
| GaryvdM | bialix | 13:13 |
| GaryvdM | bialix: Is it bad? | 13:13 |
| bialix | circles are smaller, lines are thickier | 13:14 |
| GaryvdM | bialix: Circle sizes are based on the row height. | 13:16 |
| GaryvdM | bialix: Has that changed? | 13:16 |
| bialix | GaryvdM: yes, it's different now | 13:18 |
| * bialix creating screenshot | 13:18 | |
| bialix | GaryvdM: http://imagebin.ca/view/qxZPmviW.html | 13:22 |
| * GaryvdM looks | 13:22 | |
| GaryvdM | bialix: Have you maybe changed you system font sizes? | 13:23 |
| bialix | no | 13:23 |
| GaryvdM | hmm | 13:24 |
| GaryvdM | bialix: Do we maybe want to do a if sys.platform == 'win32': fontsize += 1 | 13:24 |
| bialix | wait a min, I'll do the picture for the old PyQT | 13:25 |
| GaryvdM | bialix: http://doc.bazaar.canonical.com/explorer/en/_images/dialog-log3.png | 13:27 |
| bialix | GaryvdM: 4.7 http://imagebin.ca/view/LvTlCj.html | 13:29 |
| bialix | 4.4 http://imagebin.ca/view/wjCxOk.html | 13:29 |
| bialix | so it seems pyqt 4.7 uses smaler interval between rows | 13:30 |
| GaryvdM | Yes | 13:31 |
| bialix | I don't like it | 13:31 |
| bialix | all the dude wanted | 13:31 |
| bialix | if you look at 4.4 screenshot then you can see it was clear | 13:32 |
| bialix | now it's smooth and blur and looks dirty | 13:32 |
| bialix | :-( | 13:32 |
| * bialix re-installing 2.1.2 again | 13:35 | |
| GaryvdM | bialix: I agree. | 13:36 |
| * ddaa wishes to wake up one day and find that all software developers have figured out that windows was not a serious operating system | 13:54 | |
| LeoNerd | It's not the developers you need to worry about. It's the managers/etc... who actually buy ity | 13:58 |
| ddaa | in this fantasy world, managers would give up on windows after tiring of being ridiculed every day at the coffee machine. | 13:59 |
| === beaumonta is now known as abeaumont_ | ||
| bialix | blah blah blah | 14:03 |
| ddaa | don't take that personally, it's great that people work on windows support, so we can reach through to those lost souls | 14:10 |
| idnar | how do I "unadd" a file? the help for bzr revert suggests it'll delete the added files | 14:36 |
| ddaa | it won't if the file was not committed | 14:36 |
| beuno | idnar, bzr rm FILE --keep | 14:36 |
| ddaa | you can also "bzr rm --keep", but bzr will do the safe thing by default | 14:36 |
| beuno | although, yeah, once it's committed, it's going to live in the history for ever and ever | 14:36 |
| idnar | okay, cool | 14:37 |
| beuno | unless you uncommit, which you should *not* do if that revision has been sent into the wild | 14:37 |
| idnar | yeah, I just added some stuff too soon | 14:37 |
| idnar | I don't want to commit it along with some other stuff, and it's easier to "unadd" it than to pass the relevant paths to commit all the time | 14:37 |
| ddaa | you could also shelve the problematic file | 14:38 |
| idnar | that's probably a good idea, I haven't played around with shelve yet | 14:38 |
| ddaa | something like 'bzr shelve --all my/file; bzr commit ; bzr unshelve' | 14:38 |
| ddaa | --all will bypass the command line interaction and just shelve the changes of all specified files | 14:39 |
| ddaa | (or all changes if no file was specified) | 14:39 |
| idnar | I guess I tend to be fussier about commits than I need to be with bzr | 14:39 |
| ddaa | no, fussy commits are good | 14:39 |
| ddaa | it helps when people go back inspecting the history | 14:40 |
| idnar | I usually end up working on a couple of things at once in my working directory, and then making a lot of small commits every now and then to break everything up | 14:40 |
| idnar | I'm used to using darcs, where it actually makes a difference wrt to merging; with bzr, it's not as important, but it's still nice to have a clean and sensible change history | 14:40 |
| ddaa | maybe you should be more liberal with creating branches | 14:40 |
| ddaa | bzr merge --uncommitted is pretty cool to pick "that change I started there but should really be in a different branch" | 14:41 |
| idnar | it's too much work to create a whole branch just for, say, a 5-line change to some file; although I suppose you could blame that on my dev environment | 14:41 |
| idnar | I think bzr shelve is probably the way to go | 14:42 |
| idnar | is there a way to do a "cherry-picking" commit or shelve? I seem to recall seeing something about that somewhere, but I forget the details | 14:43 |
| idnar | as in cherry-picking changes within files, not separate files | 14:43 |
| ddaa | if you just look about the number of different ways there are in bzr to break up commits, you realize that bzr folks love to be fussy over their commits | 14:43 |
| ddaa | shelve does that, it asks for each diff hunk, unless you specify --all | 14:43 |
| LeoNerd | shelve does that. | 14:43 |
| LeoNerd | I -believe- there's a plugin to imlpement 'bzr record' which works like darcs record, offering interactive per-hunk selection | 14:44 |
| LeoNerd | Though personally I dislike that. | 14:44 |
| idnar | ah, that may be what I'm thinking of | 14:44 |
| LeoNerd | The advantage of shelve; commit; unshelve is that you can compile and test just before commit. | 14:44 |
| ddaa | the bzr way tends to be "commit what's in the tree", so you can do some basic testing before committing | 14:45 |
| LeoNerd | If you have a per-hunk partial commit it's very easy to accidentally commit files that don't even compile, let alone do what you wanted | 14:45 |
| idnar | ddaa: darcs test runs your tests against what was actually recorded, so it's not a problem there | 14:45 |
| ddaa | idnar: I'm not sure what you're trying to say, to run your tests you need a checkout anyway | 14:45 |
| ddaa | and it's better to run them before committing | 14:45 |
| ddaa | but I admit having no idea what darcs record does | 14:46 |
| ddaa | is that one of those "what the vcs sees is not what the filesystem sees" (so all bets are off when you try compiling/testing) | 14:47 |
| idnar | when you run "darcs record", after you've selected what you want to record, if you have a "test" command set up, then iirc it creates a checkout of the source tree that includes your newly-recorded patch and runs your test on that | 14:47 |
| idnar | if that fails, then the patch won't be recorded | 14:47 |
| LeoNerd | Ahyes, a big integrated approach. | 14:47 |
| LeoNerd | The bzr way is that bzr is the revision control tool and it stays out of your way wrt. testing, etc... More unixy | 14:48 |
| idnar | anyhow, the main thing is that it's automated | 14:48 |
| idnar | if I have to manually create a new branch/checkout/whatever, I'm going to spend 5x as much time on that as I did on the actual change I want to commit, which is silly | 14:48 |
| idnar | so with bzr, I usually don't bother creating a whole new branch for the small things, and I don't bother testing them individually; I'll run the tests after I've changed everything, and then just commit pieces individually | 14:50 |
| idnar | I'm never committing directly to trunk, and I'm not as concerned about "broken" revisions in a branch, as long as the end result is correct | 14:50 |
| idnar | but ideally each of those chunks would be tested individually, so I guess I need to work on making it easier to break things out like that | 14:50 |
| jelmer | idnar: Any chance you could file a wishlist bug about this? | 14:50 |
| ddaa | it's true, it would be nice if there was a "shelve --except FILE ..." option | 14:51 |
| jelmer | idnar: It certainly sounds like a useful feature, if only as a plugin (like a local PQM?) | 14:51 |
| idnar | jelmer: hmm, "this" being the "test after commit" feature? | 14:52 |
| idnar | (well, test before commit, whatever) | 14:52 |
| jelmer | idnar: yeah, the test after commit bit | 14:52 |
| idnar | jelmer: okay, will do | 14:53 |
| jam | morning all | 14:57 |
| jelmer | hey John | 14:57 |
| GaryvdM | Hi jam | 15:12 |
| GaryvdM | Bla | 15:21 |
| GaryvdM | qannotate is very slow for me due to http://bugreports.qt.nokia.com/browse/QTBUG-4977 | 15:21 |
| bialix | today is shelve bug reports today | 16:15 |
| bialix | today is shelve bug reports day | 16:15 |
| idnar | jelmer: okay, created lp#611745 | 16:32 |
| jelmer | idnar, thanks | 16:33 |
| bialix | ~~~ | 17:13 |
| === deryck is now known as deryck[lunch] | ||
| ChrisCauser | Hello Bazaar mailing list. I was wondering if anyone can help me undo a mistake I've made. | 17:17 |
| ChrisCauser | I have two repositories. The first is a subversion repository with x number of commits. I decided to try out bazaar and now have y commits in a bzr branch The stupid thing is that I did a simple copy of the working copy and initialized the branch so there is no link between these two repos. Does anyone know of a way I can stitch these two back together into a bzr branch so it looks like 1...x...x+y commits? I can't find anything useful on the web, | 17:17 |
| maxb | Hmm. that sounds a little painful | 17:17 |
| maxb | Is the history currently in bazaar entirely linear? (no branching or merging?) | 17:18 |
| ChrisCauser | It's linear all the way | 17:20 |
| maxb | I would propose converting the Subversion history using bzr-svn, and then using 'bzr replay' from the bzr-rewrite plugin to transpose the commits in bzr onto the converted branch | 17:20 |
| ChrisCauser | maxb: Ah, this looks to be very promising | 17:21 |
| ChrisCauser | I'm getting conflict errors, but I think you've set me on the right path. Many thanks maxb for your help | 17:29 |
| === deryck[lunch] is now known as deryck | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === beuno is now known as beuno-lunch | ||
| LukeD | I have a repo structure (no-trees) that has a bunch of mainline branches for different projects, some that I'm tracking with bzr-svn, some local libraries. I want to set up a project branch that includes branches of these mainlines as externals. Essentially, when I do a remote checkout of the project, I'd like it to pull checkouts of all the external branches as well... I can't seem to get it to work though. Anyone done this before? | 18:28 |
| jelmer | LukeD: that's the nested branch feature, which has not been implemented yet. | 18:30 |
| LukeD | ahh | 18:30 |
| jelmer | However, there are some plugins that provide similar functionality (with limitations). See the bzr-externals and bzr-scmproj plugins. | 18:31 |
| LukeD | I've been trying with bzr-externals, but haven't had success | 18:31 |
| LukeD | will look at scmproj | 18:32 |
| LukeD | I feel like bzr-externals probably does what I need, but I'm just not doing it right | 18:34 |
| LukeD | sigh | 18:34 |
| === beuno-lunch is now known as beuno | ||
| === Ursinha-lunch is now known as Ursinha | ||
| ddaa | AFAIK you're on your own | 21:48 |
| ddaa | as long as your bzr commits are just linear | 21:48 |
| ddaa | it should be only moderately painful to write a shell script to replay the stuff using "bzr diff" and "bzr patch" | 21:49 |
| ddaa | going through diff/patch is needed to get over the file-id mismatch | 21:49 |
| lifeless | replay can handle that if you supply a mapping file | 21:50 |
| lifeless | AIUI | 21:50 |
| ddaa | oh, bzr replay, completely forgot about this one | 21:50 |
| ddaa | I don't see anything about mapping files in its help message, though | 21:51 |
| lifeless | its in the guts | 21:51 |
| lifeless | sadly | 21:51 |
| ddaa | in the guts as in "the option is not document", or as in "there's no UI for it" or as in "some guy coded it once, no idea if it works" | 21:51 |
| lifeless | middle | 21:52 |
| lifeless | its used by bzr-svn mapping upgrades | 21:52 |
| * ddaa is scared | 21:52 | |
| jelmer | the mapping upgrades are done without any mapping files on disk but based on the revision properties/revision ids | 21:54 |
| jelmer | see also "bzr pseudonyms" | 21:54 |
| jelmer | though Rob is right that all of the infrastructure is present to do this sort of stuff, just not exposed at the ui | 21:54 |
| lokkju | on windows is there any way around the 255 char limit with the bzr client? | 23:56 |
| jelmer | lokkju: 255 char limit on what exactly? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
