abentley | jelmer: You might want to look at https://dev.launchpad.net/Code/BzrSend | 00:00 |
---|---|---|
thumper | abentley: some nicer errors might be nice :) | 00:00 |
lifeless | jelmer: ping | 00:00 |
lifeless | jelmer: did you see the thread asking for bzr-git help ? | 00:01 |
jelmer | abentley: ah, cool | 00:01 |
abentley | thumper: I suppose, but soon it will not be an error. | 00:01 |
lifeless | davidstrauss: in all your branches? | 00:01 |
thumper | abentley: :) | 00:01 |
jelmer | lifeless, hi | 00:02 |
jelmer | lifeless, no, I'll have a look now, thanksw | 00:02 |
davidstrauss | lifeless: I've only tried that in the problem branch. | 00:06 |
lifeless | davidstrauss: please try your other branches | 00:08 |
lifeless | the file in question - modules/trigger/trigger.info | 00:09 |
davidstrauss | lifeless: I can't pull that revision from any branch. | 00:11 |
davidstrauss | lifeless: i can access trigger.info from older branches | 00:12 |
lifeless | davidstrauss: you checked cat-revision for that rev in all your branches? | 00:13 |
lifeless | davidstrauss: did you have anything odd happen two days ago? all the references to the missing revision start on the 28th of jan | 00:14 |
lifeless | was it a loom branch | 00:14 |
lifeless | (I'm trying to track down the reason this happened) | 00:15 |
davidstrauss | lifeless: I didn't hear any reports of problems | 00:15 |
davidstrauss | lifeless: And "bzr check" runs fine on yesterday's branches | 00:15 |
lifeless | brb | 00:16 |
lifeless | back | 00:17 |
=== mtaylor_ is now known as mtaylor | ||
davidstrauss | lifeless: the branch works properly through rev 520 | 00:23 |
lifeless | davidstrauss: yes, thats consistent with my analysis | 00:25 |
lifeless | davidstrauss: something cause bzr, in rev yched-20090128232212-lnh21io5dqaikdeo, to insert a reference to a text version that isn't in the branch, coming from a revision you don't appear to have | 00:26 |
lifeless | that commit was done by yched | 00:26 |
davidstrauss | lifeless: yes, and he uses a windows client over bzr+ssh | 00:27 |
davidstrauss | lifeless: i've emailed him to ask the specific version | 00:28 |
lifeless | spiv: ping | 00:28 |
lifeless | davidstrauss: also any plugins, and did he have *any* issues - confusing behaviour, a merge he cancelled, etc - at that time | 00:28 |
davidstrauss | lifeless: he has whatever is packaged with the windows bzr installer | 00:29 |
davidstrauss | lifeless: and he's using a checkout/update/commit workflow | 00:29 |
davidstrauss | lifeless: the server-side is running bzr 1.11 | 00:29 |
davidstrauss | lifeless: on RHEL 5 | 00:30 |
spiv | lifeless: pong | 00:30 |
lifeless | spiv: please read the discussion david and I have been having | 00:30 |
davidstrauss | lifeless: I haven't heard if Yves did or encountered anything unusual. | 00:30 |
lifeless | davidstrauss: regardless; there is a bug here, if it was commot we'd see this all the time, so its uncommon / corner case | 00:31 |
spiv | lifeless: Hmm. Summary: missing revision, there's a text delta against that rev, the missing revision was created on windows over bzr+ssh? | 00:31 |
lifeless | its a pretty serious bug to introduce bad references like this | 00:32 |
lifeless | spiv: missing rev; the inventory in rev yched-20090128232212-lnh21io5dqaikdeo adds a reference to [1-or-more] texts added by the missing rev | 00:32 |
lifeless | rev yched-20090128232212-lnh21io5dqaikdeo was pushed to the server by the windows client over bzr+ssh | 00:32 |
davidstrauss | spiv: The branch is downloadable from http://straussd.fourkitchens.com/7-fic-broken.tgz | 00:33 |
lifeless | davidstrauss: let me know when he gets back to you | 00:35 |
lifeless | davidstrauss: I'll start looking at the code he's running at that point to see if I can find a potential cause | 00:35 |
davidstrauss | lifeless: Sounds like a plan. :-) | 00:36 |
spiv | lifeless: An interesting issue... and the second one involving bzr+ssh & windows in the last week. | 00:37 |
lifeless | spiv: I smell a commit issue for the inventory data; but I also am concerned about the smart server letting this in | 00:38 |
spiv | Well, the smart server is still mostly acting like a VFS server as far as pack data goes. | 00:39 |
lifeless | isn't there a ref check now ? | 00:39 |
spiv | Hmm. I think the client is still doing that, I'll refresh my memory. | 00:39 |
spiv | Yeah, the Packer on the client still does _check_references. After that point the autopack occurs (and may be done via RPC), but the InterPackRepo code path leading to _check_references is the same for HPSS and non-HPSS. | 00:42 |
lifeless | spiv: so, somehow this passed the check | 00:42 |
lifeless | likely because the rev being added doesn't add the ref; but the mismathc between inv content and rev parents led to a skew | 00:43 |
lifeless | I'm really wondering if there is a third party commit code involved | 00:43 |
lifeless | something in bzr-gtk or qbzr perhaps | 00:43 |
spiv | That's an interesting thought! | 00:44 |
lifeless | because of course the core code is bugfree ;P | 00:44 |
spiv | :) | 00:45 |
lifeless | markh: what does gui commits on windows do | 00:45 |
markh | um - the qbzr plugin calls "bzr commit" as a subprocess, if that is what you are asking | 00:46 |
=== dereine is now known as dereine[OFF] | ||
lifeless | ok, so we should have the command line in bzr.log | 00:48 |
davidstrauss | lifeless: He may be using TortoiseBzr | 00:49 |
markh | davidstrauss: Tortoise uses qbzr | 00:49 |
davidstrauss | lifeless: There's also a chance he's using the Eclipse extension | 00:50 |
lifeless | davidstrauss: we'll know soon enough :) | 00:50 |
davidstrauss | I'm mostly concerned that the smart server allowed this. | 00:50 |
lifeless | davidstrauss: so are we ;) | 00:51 |
* spiv goes back to working on a truly smart push... | 00:52 | |
davidstrauss | lifeless: Yves is running Tortoise Bazar 0.1 / bzr 1.9 | 00:59 |
lifeless | did he notice anything out of the orderinary? | 01:00 |
lifeless | can we get his bzr.log | 01:01 |
davidstrauss | lifeless: He didn't mention anything unusual. | 01:01 |
markh | ok, looking a little more, qbzr actually executes a sub-process with a command-line that looks like 'bzr qsubprocess commit ..." - the qsubprocess command still just does a "normal" checkout or whatever sub-command is issues, but qsubprocess allows for progress info to be sent back IIUC | 01:01 |
lifeless | davidstrauss: please ask him explicitly | 01:01 |
davidstrauss | lifeless: Where is bzr.log for Windows clients? | 01:01 |
markh | davidstrauss: in "my documents" | 01:02 |
lifeless | bzr --version lists the location | 01:02 |
davidstrauss | lifeless: I've asked him. | 01:05 |
lifeless | davidstrauss: thanks | 01:05 |
lifeless | I want to be clear - I don't think hes done anything wrong; this is a software issue we just need to fine the bug | 01:06 |
davidstrauss | lifeless: of course :-) | 01:11 |
=== kiko-afk is now known as kiko-zzz | ||
=== abentley1 is now known as abentley | ||
* igc lunch & doctor appointment | 01:48 | |
thumper | lifeless: I'm assuming this is known about: /home/tim/.bazaar/plugins/loom/revspec.py:64: DeprecationWarning: Modifying SPEC_TYPES was deprecated in version 1.12. | 03:29 |
jelmer | thumper, yeah, John posted a patch to the list | 03:36 |
lifeless | and I approved it :P | 03:37 |
thumper | cool | 03:38 |
thumper | is it on trunk yet? | 03:38 |
_Andrew | I just made this diff on a file but I feel like it's not generated the patch correctly on one file because it's removed a ton of code I haven't edited and then added it back in. Should I report it as a bug? | 03:39 |
lifeless | _Andrew: you can if you like, but diff is actually really hard to get 'right' all the time: oftimes when we get a report like that we can track it down to the alternative being larger or less useful - but not always | 03:40 |
lifeless | _Andrew: you probably moved an anchor line from below to above the code that got shown as a delete+add | 03:40 |
lifeless | _Andrew: we do care about making diff as useful as possible | 03:43 |
_Andrew | You might be right.. | 03:43 |
_Andrew | one second let me revert the change and add what I changed | 03:43 |
=== mtaylor_ is now known as mtaylor | ||
_Andrew | My fault.. | 04:02 |
_Andrew | I ran one of the files through qt designer which changed it all | 04:02 |
_Andrew | Thanks for all the help. | 04:11 |
=== abentley1 is now known as abentley | ||
tjs | anyone know what a bad protocol version marker would be? | 04:31 |
tjs | bzr: ERROR: Received bad protocol version marker: '2428\nbzr message 3 (bzr 1.6)' | 04:32 |
spiv | A good protocol version marker would be "bzr message 3 (bzr 1.6)\n" | 04:34 |
spiv | This is over bzr+ssh? | 04:34 |
tjs | yes | 04:34 |
spiv | Can you reproduce with -Dhpss? What version on the server? | 04:34 |
tjs | bzr -Dhpss ci -m "testing" | 04:35 |
tjs | bzr: ERROR: Received bad protocol version marker: '1772\nbzr message 3 (bzr 1.6)' | 04:35 |
tjs | 1.6.1 on both | 04:35 |
tjs | although the server was created at 1.3.1 | 04:35 |
tjs | I tried doing a bzr upgrade on the server and it says its all up to date | 04:36 |
spiv | tjs: what does the log file (~/.bzr.log) show for the -Dhpss command? | 04:36 |
lifeless | tjs you have noise from somewhere | 04:36 |
spiv | Interesting that it's so consistent (4 bytes each time)... | 04:37 |
spiv | Do you have any plugins on the server that would write to stdout? | 04:37 |
tjs | aah | 04:37 |
tjs | possibly o.O | 04:37 |
tjs | one sec | 04:37 |
spiv | Hmm, perhaps bzr serve should smash sys.stdout to discourage that... | 04:38 |
spiv | Er, bzr serve --inet, I mean. | 04:38 |
tjs | crisis averted | 04:38 |
tjs | *halo* | 04:38 |
tjs | thanks guys | 04:38 |
spiv | tjs: bzr+ssh doesn't care about stderr, so you can abuse that if you want ;) | 04:40 |
tjs | was just some debugging cruft, is there a way to use pdb in a hook script? | 04:41 |
spiv | You can do the usual "import pdb; pdb.set_trace()" trick. | 04:47 |
spiv | It won't work so well if it's running on the remote end, though... | 04:48 |
spiv | (Incidentally, hitting SIGQUIT, usually C-\, will drop you into the debugger too) | 04:49 |
Peng_ | jelmer: Congrats on the release (candidate). :) | 05:10 |
sohail | lifeless, there? | 06:59 |
sohail | well anyone actually... | 06:59 |
sohail | I am trying to see what the changes are between two branches | 06:59 |
sohail | via merge /path/to/dev/branch | 07:00 |
sohail | this only merges the last checkin... | 07:00 |
spiv | bzr merge will merge all changes that aren't already in your branch. | 07:02 |
spiv | You could also do bzr diff -r -1..branch:/path/to/dev/branch | 07:04 |
spiv | But typically "bzr merge --preview /path/to/dev/branch" is what you want. | 07:05 |
sohail | spiv, but that's just it | 07:05 |
sohail | there are more changes that are not being merged | 07:05 |
sohail | for example, I made some changes to the 'website' directory in my 'next' branch, yet when I switch to master and merge from next... nothing | 07:06 |
spiv | What does "bzr missing /path/to/dev/branch" report? | 07:07 |
sohail | spiv, "You are missing 1 revision" | 07:08 |
sohail | I have no ide ahow | 07:08 |
sohail | I never merged | 07:08 |
vila | hi all | 07:08 |
sohail | spiv, I am looking at bzr log | 07:08 |
sohail | all the checkins are to branch nick: next | 07:09 |
sohail | yet some of the changes are actually in my master branch already | 07:09 |
sohail | wtf | 07:09 |
sohail | ah spiv I think I may have figured it out... I had the working copy bound to /path/to/master | 07:27 |
sohail | so I guess when I did bzr switch next, it was still submitting to master? | 07:28 |
sohail | weird | 07:28 |
spiv | sohail: bzr switch changes the branch that the working copy is bound to. | 07:30 |
sohail | spiv, then what's going on? | 07:30 |
spiv | No idea. | 07:32 |
sohail | this sucks... | 07:33 |
sohail | I need to do a release but wanted to work on some next version stuff! | 07:33 |
sohail | oh well... bed time :-( | 07:34 |
igc | have a good weekend all | 08:45 |
aquarius | I've inadvertently bzr rm'd an (empty) folder (called "tmp") in my branch. I did it a while ago, and I'd like to get it back. "bzr revert tmp" complains that tmp is not versioned (which it isn't, because I bzr rm'd it). How do i get it back? I could just bzr add it again, but that seems wrong... | 08:52 |
edgimar | If I did a 'bzr merge <otherbranch>' on a given branch, and now 'bzr st' shows 'pending merges', how do I "call off" the merge, and go back to how it was before I had typed 'bzr merge'? | 08:52 |
Lo-lan-do | edgimar: bzr revert | 08:53 |
edgimar | Lo-lan-do: I think I tried that -- are there special flags to add to it? | 08:53 |
Lo-lan-do | aquarius: bzr revert, too :-) | 08:53 |
Lo-lan-do | edgimar: Not as far as I know | 08:53 |
aquarius | Lo-lan-do: bzr revert will just remove everything changed since my last commit, won't it? | 08:54 |
aquarius | Lo-lan-do: and bzr revert tmp says that tmp isn't versioned | 08:54 |
Lo-lan-do | aquarius: Correct. If you want to save some of these changes, you might try to shelve them, then revert the rest, then unshelve. | 08:54 |
edgimar | Ok, maybe the problem was that I specified something like '*' as an argument, and should have had no arguments. | 08:55 |
Lo-lan-do | edgimar: Possibly, yes. | 08:56 |
Peng_ | By default, I think revert only removes pending merges when you don't specify any files. That's what the --forget-merges argument is for. :) | 09:02 |
aquarius | Lo-lan-do: aha, I removed it in r570. So, bzr merge -r 570..569 will reverse that merge, yes? | 09:06 |
Lo-lan-do | aquarius: Ah, if you've committed the removal, then yes, you'll need to do something like that. | 09:07 |
Lo-lan-do | revert only reverts uncommitted changes :-) | 09:07 |
aquarius | Lo-lan-do: yep :) | 09:08 |
aquarius | Lo-lan-do: OK, confused. bzr log -v -r 570 shows that all I did in that revision was remove tmp/. But bzr merge -r 570..569 changes a load of other files. What am I doing wrong? | 09:09 |
kiko-zzz | Lo-lan-do! | 09:12 |
kiko-zzz | good to see you here | 09:12 |
Lo-lan-do | aquarius: Not sure... it may be a different syntax. | 09:13 |
Lo-lan-do | kiko-zzz: Hi :-) | 09:13 |
Lo-lan-do | kiko-zzz: How are things? | 09:15 |
kiko-zzz | how's bzr working for you? | 09:15 |
kiko-zzz | I'm great. a bit sleepy | 09:15 |
kiko-zzz | busy this week with a plan for bzr :) | 09:15 |
Lo-lan-do | It's working great for me, and I'd love to have time to learn how to hack it in order to fix a few problems I still have. | 09:16 |
kiko-zzz | Lo-lan-do, hey, if you have some time free talk to me :) | 09:17 |
Lo-lan-do | Free time. Haha. | 09:18 |
aquarius | I am very confused. bzr log -v -r 570 shows that all I did in that revision was remove tmp/. But bzr merge -r 570..569 changes a load of other files. What am I doing wrong? | 09:21 |
kiko-zzz | aquarius, interesting -- in what revision did those files change? | 09:21 |
aquarius | kiko-zzz: I don't know... | 09:22 |
aquarius | kiko-zzz: probably 571 (I did a merge from trunk then) | 09:22 |
kiko-zzz | aquarius, try changing the revisions in your merge command slightly and seeing if something makes sense | 09:23 |
aquarius | kiko-zzz: it doesn't seem to. (This is more complex because 571 was the merge from trunk, so loads of files that I have nothing to do with changed...but merge -r 570..569 does not seem to be everything from trunk.) | 09:24 |
edgimar | If I committed something before setting my username properly (with 'whoami'), can I go back and change the username of the commit? | 09:24 |
kiko-zzz | edgimar, bzr uncommit and commit | 09:25 |
edgimar | ok, so uncommit will leave the working directory in the state right before it was committed? | 09:25 |
kiko-zzz | and shelve if you don't want to lose that | 09:25 |
kiko-zzz | yes | 09:26 |
kiko-zzz | exactly | 09:26 |
kiko-zzz | aquarius, I can totally reproduce what you are saying | 09:27 |
kiko-zzz | aquarius, I'm not sure exactly why it happens, but I can tell you this | 09:27 |
edgimar | kiko-zzz: what if I committed more than one revision? | 09:28 |
kiko-zzz | edgimar, uncommit, shelve, uncommit, shelve, etc | 09:28 |
edgimar | ok. thanks. | 09:28 |
aquarius | kiko-zzz: aha! I have worked it out, because I was stupid. bzr merge -r 570..569 . | 09:28 |
aquarius | I was unmerging from trunk, not from myself. forgot the . on the end :) | 09:29 |
kiko-zzz | aquarius, heh, but tricky eh? | 09:29 |
kiko-zzz | might be worth filing a bug | 09:29 |
kiko-zzz | okay, time for some cycling | 09:29 |
kiko-zzz | before I go pumpkin :) | 09:29 |
* kiko-zzz waves and will bbl | 09:29 | |
aquarius | kiko-zzz: I shall do, although it may be closed with EYOUARESTUPID :) | 09:29 |
kiko-zzz | aquarius, /msg me the bug number so I make sure it doesn't ;) | 09:30 |
edgimar | kiko-zzz: It seems that doing uncommit / commit requires you to re-enter your commit message and doesn't retain the original commit time -- is there a way to *only* change the username? | 09:39 |
kiko-zzz | edgimar, well, you're asking to rewrite history. there may be a history rewriting plugin but I don't know 100% | 09:40 |
kiko-zzz | need to run, ttyl | 09:40 |
Kinnison | edgimar: by uncommitting, you're asking bzr to forget about your commit. So it does indeed forget username, message, etc. | 09:44 |
Kinnison | edgimar: If you really want that behaviour, write yourself a script. It's not behaviour I'd imagine the bzr team wanting to promote | 09:45 |
=== asabil_ is now known as asabil | ||
etenil | Hello | 10:08 |
etenil | I have yet another problem with bzr on windows | 10:12 |
etenil | I can't locate where the configuration files are | 10:12 |
luks | bzr version | 10:13 |
etenil | Oh got it | 10:16 |
etenil | man, it's easier on GNU/Linux | 10:16 |
balor | During disconnected operation I committed code to a local branch "bzr ci --local". If I "bzr update" will that propogate to the non-local branch it was checked out from? | 10:21 |
aquarius | james_w: arf :) | 10:21 |
james_w | aquarius: I couldn't resist | 10:22 |
balor | aquarius: Long time no see. Happy birthday. | 10:22 |
james_w | ah, happy birthday aq | 10:23 |
james_w | balor: I'm not completely sure, but I believe it won't propagate at update time | 10:23 |
balor | james_w: hmmm..... | 10:24 |
aquarius | balor, james_w: cheers :) | 10:25 |
balor | aquarius: Which reminds me that I should go up north to spill another pint on you some time soon. | 10:29 |
bialix | etenil: `bzr qconfig` may help | 10:30 |
aquarius | balor: when you're around here, say the word :) | 10:34 |
=== asac_ is now known as asac | ||
spiv | balor: no, bzr update will turn the local commits into pending merges in your working copy. When you do "bzr commit" they'll propagate to the master branch. | 10:44 |
balor | spiv: Will they commit with the commit messages I've previously given them? | 10:44 |
balor | spiv: i.e. the changelog entries | 10:44 |
Lo-lan-do | Nope, they'll commit as one revision merging all your local commits into one. | 10:45 |
balor | hmm.... | 10:45 |
balor | Is there any way to get all my local commits to commit to the master branch? | 10:46 |
Lo-lan-do | Unless you rebase them on the updated tree, but I'm not sure how to do that (I believe it is possible though). | 10:46 |
Lo-lan-do | Yes, rebase :-) | 10:46 |
spiv | balor: all the commits will still be there, but not on the mainline. | 10:46 |
spiv | You could probably "bzr unbind" and then "bzr push" to push them as mainline commits, assuming the master hasn't diverged. | 10:47 |
balor | spiv: I think I may just push them up to a new location and use that as the new mainline | 10:48 |
Lo-lan-do | And if it has diverged, then unbind, rebase, push, bind. | 10:48 |
spiv | Lo-lan-do: er | 10:48 |
spiv | Lo-lan-do: well, I guess. Or just merge the master back in and push. | 10:48 |
Lo-lan-do | (If you want the individual commits to still appear linearly) | 10:49 |
spiv | I personally wouldn't worry so much about which commits are mainline and which aren't. | 10:49 |
spiv | They're all still there, whether they're on the left-hand side of the graph isn't really a big deal generally. | 10:49 |
Lo-lan-do | spiv: I sometimes do, when mainline is stored on SVN. | 10:49 |
spiv | Ah. Poor you :) | 10:50 |
Lo-lan-do | Yeah. | 10:50 |
=== kiko-zzz is now known as kiko-afk | ||
etenil | I've got a silly windows problem to start olive | 12:32 |
etenil | I have made a shortcut to 'bzr olive', but it always shows the terminal windows to which the program is attached | 12:33 |
etenil | is there any way around? | 12:33 |
=== thekorn_ is now known as thekorn | ||
Kinnison | Is there a known issue with bzr-git right now? | 13:56 |
Kinnison | I branched it to take a look, but bzr whinges: | 13:56 |
Kinnison | __init__() takes exactly 2 arguments (1 given) | 13:56 |
Kinnison | which appears to be caused by the last line in mapping.py | 13:57 |
jelmer | Kinnison, you need bzr.dev | 14:10 |
jelmer | lol | 14:11 |
jelmer | Format <HgRepositoryFormat> for file:///home/jelmer/hg/dovecot/.hg/ is deprecated - please use 'bzr upgrade' to get better performance | 14:11 |
* jelmer fixes bzr-hg | 14:11 | |
vila | jelmer: :-) | 14:11 |
Kinnison | jelmer: I just did pull in my bzr.dev | 14:12 |
* Kinnison boggles and tries again | 14:12 | |
Kinnison | No revisions to pull | 14:13 |
vila | jelmer: regarding bug marked as fixed released for bzr-gtk, there seemed to be consensus on the ML, should we start to apply it now ? | 14:13 |
jelmer | Kinnison, oh, and I should be pushing to lp:bzr-git rather than my private bzr-git branch | 14:13 |
jelmer | Kinnison, sorry | 14:13 |
Kinnison | should I re-pull bzr-git ? | 14:14 |
jelmer | Kinnison, pushed, please repull bzr-git | 14:14 |
jelmer | yep | 14:14 |
jelmer | vila: yeah, I think so | 14:14 |
vila | ok, great | 14:14 |
Kinnison | What is dulwich and where do I get it? | 14:15 |
jelmer | Kinnison, it's a Python module that implements the git file formats/protocols | 14:16 |
jelmer | Kinnison, there's a PPA at launchpad.net/~dulwich | 14:16 |
jelmer | Kinnison, the performance sucks a bit at the moment, so I wouldn't try it on the Linux kernel but it should be fine for smaller projects | 14:19 |
bialix | jelmer: I'm interesting in bzr-git. I'll try to start test it on win32. Do you have any particular advices? | 14:19 |
jelmer | bialix: Ah, cool! I would be interested to hear about portability or other bugs you encounter | 14:20 |
bialix | I don't have any particular git project I want to track. Do you have any testing one or I need to create local repo? | 14:21 |
Kinnison | jelmer: amusingly I hadn't read that performance warning and wandered off to branch linux-2.6 | 14:21 |
Kinnison | jelmer: It crashed | 14:21 |
santagada | the guys that where developing the bzr textmate bundle don't whant to continue to develop it. If I were to work on it do you guys think using the bzr api is a better idea or using the bzr client is ok? | 14:22 |
homy | Hi! I'm using ubuntu intrepid and the launchpad bzr ppa. | 14:22 |
santagada | how could I show progress bar is I use the bzr client? | 14:23 |
homy | Since some time, I can't update the bzr package: Update manager always prompts me to do a "partial update", as bzr can't be installed. | 14:23 |
santagada | homy: you are having problems with bzr-tools right | 14:23 |
homy | ? | 14:23 |
homy | santagada: how do I find out if that's the case? | 14:23 |
santagada | homy: I think noone updated it yet... the last 2 days people came here all the time complaining about it | 14:24 |
santagada | homy: you can search for bzr-tools on synaptic I think... | 14:24 |
bialix | bzrtools (without dash, IMO) | 14:25 |
santagada | bialix: thanks :) | 14:25 |
bialix | at least it's the official name | 14:25 |
homy | yes. The square is green. The square next to bzr is green but has a star | 14:25 |
vila | santagada: what bzr version are you using ? There is a new pb implementation under work in bzr.dev | 14:26 |
santagada | vila: pb? | 14:26 |
santagada | what is that | 14:26 |
vila | progress bar | 14:26 |
santagada | vila: I plan to develop the textmate bundle to work with the released bazaar... or when is 1.12 going to be released? | 14:27 |
vila | the rc should be out next friday or something | 14:27 |
santagada | homy: bzrtools is 1.10 right? and bzr can be updated to 1.11 | 14:27 |
santagada | vila: so I should probably target it | 14:28 |
vila | santagada: what is textmate ? | 14:28 |
santagada | vila: one of the most used text editors for osx | 14:28 |
jelmer | bialix, a good one is e.g. etckeeper | 14:28 |
vila | santagada: I thought is was emacs, sorry about that :) | 14:28 |
homy | santagada: bzrtools: installed version = latest version = 1.10.-1~bazaar1~intrepid1 bzr: installed version 1.10-1~bazaar1~intrepid and latest version 1.11.1 | 14:28 |
jelmer | bialix, bzr branch git://git.kitenet.net/etckeeper | 14:29 |
jelmer | Kinnison, whoa :-) | 14:29 |
bialix | jelmer: ok | 14:29 |
santagada | vila: I think the order is: textmate, bbedit, aquamacs, vim | 14:29 |
jelmer | Kinnison, Hopefully that should be fixed soon, there are just two places where we do things *really* inefficiently | 14:29 |
vila | santagada: so regarding pb, it depends a lot on how you interface between textmate and bzr | 14:29 |
santagada | vila: I was plaining to use the bzr client directly thru shell scripts | 14:30 |
* bialix hope etckeeper don't have versioned symlinks | 14:30 | |
Kinnison | jelmer: http://rafb.net/p/881AAH60.html | 14:30 |
Kinnison | jelmer: if it's something you know, I'll wait. otherwise if you want, I can file a bug. | 14:31 |
homy | help? | 14:31 |
vila | How do you "program" (?) textmate ? | 14:31 |
jelmer | Kinnison, please file a bug | 14:31 |
santagada | homy: you have to wait | 14:31 |
vila | santagada: by the way, I thought Xcode was the most commonly used... | 14:31 |
santagada | homy: while bzrtools is not updated | 14:32 |
santagada | vila: xcode is not a text editor... well emacs isn't either :) | 14:32 |
santagada | vila: tm uses shell scripts mostly | 14:32 |
homy | Is there any particular reason for bzrtools not being up-to-date in the ubuntu ppa? | 14:33 |
Kinnison | jelmer: filed: #323190 | 14:34 |
* bialix mutters bzr-git and dulwich could be married with scmproj | 14:34 | |
santagada | homy: ppa I think is updated by people... and some people didn't update it | 14:34 |
jelmer | Kinnison, thanks | 14:34 |
* Kinnison goes back to git for now | 14:35 | |
* Kinnison sobs | 14:35 | |
santagada | homy: why he didn't I don't know... but doing debian packages is a hard process | 14:35 |
bialix | jelmer: what is the right way to run selftest fro dulwich | 14:35 |
bialix | ? | 14:35 |
bialix | s/fro/for/ | 14:35 |
santagada | jelmer: the PPA packages are not automated or are they? | 14:35 |
jelmer | bialix, e.g. "trial dulwich" | 14:35 |
bialix | trial? | 14:36 |
jelmer | bialix, it's part of twisted | 14:36 |
bialix | oh, no | 14:36 |
speakman | hi folks, i'm having trobles using trac-bzr on freebsd. Is there a better channel for this issue? | 14:36 |
jelmer | bialix, I think there are other test runners as well, but don't know any others off the top of my head | 14:36 |
bialix | if there is nothing unusual in dulwich test suite I can port my own runner, if you dont mind | 14:37 |
bialix | speakman: I'm using trac-bzr, but on Windows | 14:37 |
jelmer | bialix, I'd rather keep it as generic as possible | 14:37 |
speakman | I get "AttributeError: 'int' object has no attribute 'isdigit'" when running latest trac-bzr (from trunk today) and Trac 0.11.2, bzr 1.11 (how do I check bzrlib version?) | 14:38 |
jelmer | speakman, please file a bug | 14:38 |
speakman | >>> bzrlib.version_info | 14:38 |
speakman | (1, 11, 0, 'final', 0) | 14:38 |
homy | ok, so I guess I'll just have to wait. | 14:38 |
bialix | jelmer: how test runner will make the dulwich test suite less general? | 14:39 |
bialix | or generic, whatever | 14:39 |
santagada | speakman: int has isdigit right? | 14:39 |
santagada | speakman: try it in python | 14:39 |
bialix | isdigit seems to be string method | 14:39 |
speakman | heh, didn't look that far. Strange! Python is 2.5 btw | 14:39 |
santagada | speakman: (1).isdigit() or int.isdigit() | 14:39 |
santagada | bialix: right again | 14:40 |
santagada | speakman: it is a function from string, bialix is right | 14:40 |
speakman | The line of the error is 213 in backend.py: "if rev.isdigit():" | 14:41 |
santagada | speakman: paste your full traceback somewhere | 14:41 |
jelmer | bialix: basically dulwich just uses the standard unittest python module that's included in python itself | 14:41 |
speakman | santagada: will do, w8 | 14:41 |
jelmer | bialix, so any test runner that can use that should work | 14:41 |
bialix | jelmer: yes, I understand | 14:41 |
bialix | I have a simple test runner implementation so one can run `python setup.py test` | 14:41 |
santagada | speakman: I think you should open a ticket on the bzr bug tracker... | 14:41 |
jelmer | bialix, ah, ok | 14:41 |
jelmer | bialix, That's of course useful :-) | 14:42 |
speakman | http://pastebin.com/m609db24c | 14:42 |
bialix | jelmer: something wrong: ImportError: No module named dulwich.protocol | 14:42 |
speakman | santagada: bzr or bzr-trac ? | 14:42 |
santagada | speakman: good question | 14:42 |
santagada | speakman: I'm thinking it is a problem with the trac integration | 14:43 |
bialix | rats | 14:43 |
santagada | but let me look | 14:43 |
bialix | jelmer: I've put dulwich lib inside git plugin directory because I'm running bzr.exe | 14:43 |
santagada | speakman: it is a problem with tracbzr | 14:43 |
bialix | and this import does not work for me: from dulwich.protocol import Protocol, TCP_GIT_PORT, extract_capabilities | 14:44 |
santagada | speakman: what is it by the way? it is a plugin for versioncontrol for trac? where can I find its homepage? | 14:44 |
jelmer | bialix, Yeah, you'll probably need to have it in PYTHONPATH | 14:44 |
bialix | jelmer: oh, yes. we have similar trick in qbzr | 14:45 |
speakman | Changing repository_dir to point at parent dir killed the error..! | 14:45 |
santagada | speakman: maybe there is someone on #trac that could help you | 14:45 |
speakman | santagada: https://launchpad.net/trac-bzr | 14:45 |
bialix | jelmer: I'll send you a patch shortly | 14:46 |
santagada | jelmer: isn't you the author of trac-bzr? | 14:47 |
bialix | jelmer: in qbzr we put additional libs in the _lib directory. if I'll use the same approach for bzr-git -- it'll be ok for you? | 14:47 |
jelmer | bialix, as long as it doesn't modify sys.path | 14:47 |
bialix | it indeed modified sys.path | 14:48 |
bialix | but only if user run bzr.exe | 14:48 |
jelmer | hmm | 14:48 |
bialix | there is no way otherwise | 14:48 |
jelmer | bialix, Can you send me the patch? I'm not completely sure about this, but I'll have a look | 14:48 |
jrwren | trac-bzr looks cool! wish lp was free :) | 14:48 |
speakman | This seems to fixed it. I'll just keep it like that. | 14:48 |
bialix | jelmer: for bzr.exe sys.path points only to bundled libs in exe's library.zip | 14:48 |
jelmer | santagada, I seem to be the maintainer by default | 14:49 |
santagada | jelmer: good luck fixing speakman bug :). I might be abble to help | 14:50 |
bialix | jelmer: it will looks something like this: http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/head%3A/lib/__init__.py (lines 23-25) | 14:51 |
santagada | I don't know anything about bzr but I do understand trac code | 14:51 |
jelmer | bialix, Ah, that looks reasonable | 14:51 |
nDuff | hmm -- I was just plugging Bundle Buggy in #qemu (as there's been talk on the mailing list on wanting a patch-tracking system), and Patchwork [http://ozlabs.org/~jk/projects/patchwork/] came up as an SCM-agnostic competitor; I didn't actually know there were other tools in the same space. | 14:51 |
jelmer | nDuff, I think bzr used patchwork for a while | 14:51 |
jelmer | nDuff, it doesn't track when things have been merged though, exactly because it's SCM agnostic | 14:52 |
jelmer | santagada: trac-bzr mainly needs a testsuite :-( | 14:52 |
gnomefreak | can someone tell me why im getting this error? http://pastebin.mozilla.org/612641 | 14:52 |
santagada | jelmer: why not just reuse trac testsuite? | 14:53 |
jelmer | gnomefreak, you can't push to http locations | 14:53 |
jelmer | santagada, That doesn't setup bzr repositories, etc | 14:53 |
gnomefreak | i used the lp: | 14:53 |
gnomefreak | oops wriong link | 14:53 |
gnomefreak | thanks | 14:53 |
santagada | jelmer: adapting version_control/tests/svn_fs.py for bzr doesn't seem impossible... | 14:57 |
speakman | There's alot more bugs with trac-bzr. Nonworking URLs to files in specific revisions seems common. I might get back to help out fix some of it, but I'm currently in a hurry. | 14:59 |
speakman | Thanks alot for your time! | 14:59 |
jam | vila: ping | 15:00 |
vila | jam: pong, can we talk now or a bit later ? (I need to switch machine if we talk) | 15:01 |
santagada | speakman: this seems to be a problem with having evolving versions of trac and bzr and not having automated test cases... it probably works for some versions of bzr and trac :| | 15:01 |
bialix | jelmer: bzr selftest git fails very quickly: http://pastebin.com/m516466ff | 15:01 |
jelmer | bialix, can you be more specific ? :-) | 15:02 |
speakman | santagada: yes, probably. My other installations works pretty good. | 15:02 |
bialix | jelmer: that's all I get | 15:02 |
speakman | (another thing is the null: revision which keeps showing on top on Timeline.) | 15:02 |
jelmer | bialix, Any chance you can file a bug ? I'll have a look at it later | 15:03 |
bialix | it seems like bzr test suite crashed | 15:03 |
jelmer | santagada, that still means somebody has to put effort in, and I doubt it would be much quicker than writing a testsuite for bzr from scratch | 15:03 |
bialix | I don't have usual stack trace in the end | 15:04 |
santagada | speakman: file a bug on trac-bzr | 15:07 |
santagada | jelmer: maybe | 15:07 |
jelmer | hmm, lazy commands already landed ! | 15:12 |
jelmer | I never noticed | 15:12 |
bialix | jelmer: bug 323207 | 15:15 |
ubottu | Launchpad bug 323207 in bzr-git "`bzr.exe selftest git` fails" [Undecided,New] https://launchpad.net/bugs/323207 | 15:15 |
jelmer | bialix, thanks! | 15:15 |
* bialix pushing the branch with bzr.exe support patch to lp | 15:16 | |
bialix | jelmer: the patch: https://code.launchpad.net/~bialix/bzr-git/bzr.exe/+merge/3258 | 15:18 |
santagada | speakman: did you reported your bug on trac-bzr? | 15:24 |
=== dereine[OFF] is now known as dereine | ||
=== dereine is now known as dereine[OFF] | ||
=== dereine[OFF] is now known as dereine | ||
speakman | santagada: sorry, no time for that at the moment :( | 16:06 |
speakman | santagada: will get back to it later, or other bugs (there are some in that package) | 16:06 |
speakman | now have to leave, thanks for your time | 16:06 |
sohail | lifeless, awake? | 16:29 |
jelmer | hi rockstar | 16:36 |
jelmer | hi rocky | 16:36 |
rocky | heyo ;) | 16:36 |
jelmer | Peng_, thanks! | 16:37 |
rockstar | jelmer, turn my tab blue... | 16:37 |
jelmer | rockstar: Sorry :-) | 16:37 |
rockstar | jelmer, :) | 16:37 |
rockstar | jelmer, for the bzr-stats changes, should I request a review from you? | 16:38 |
jelmer | rockstar: yeah, from either me or John | 16:38 |
jelmer | perhaps we should create a team for bzr-stats. are you in the bzr developers team? | 16:39 |
rockstar | jelmer, I don't think so. I don't think I've made many contributions to bzr. | 16:39 |
jelmer | rockstar, I've created a bzr-stats team that now owns bzr-stats; you should be able to request review from that team | 16:51 |
rockstar | jelmer, can you set the default review team for lp:bzr-stats to be that team? | 16:55 |
jelmer | rockstar, how do I do that? | 16:57 |
rockstar | jelmer, I did it. | 16:58 |
bialix | jelmer: dulwich/test/__init__.py uses only test_objects, test_repository and test_pack as modules for testing. but test_index and test_object_store are not. should I update this? | 16:59 |
Jc2k | bialix: thats fixed in my branch already (i added another test as well) | 17:01 |
bialix | Jc2k: I'd like to add test runner for dulwich. What is your branch? | 17:01 |
Jc2k | bialix: you mean instead of make check? | 17:03 |
Jc2k | my branch is at lp:~johncarr/dulwich/git-serve | 17:04 |
bialix | (shy) yes, sir | 17:04 |
Jc2k | i think jelmer has merge it, but maybe not pushed yet | 17:04 |
bialix | like this: http://bazaar.launchpad.net/~bialix/intelhex/trunk-w-tags/annotate/head%3A/setup.py (lines 75-99) | 17:05 |
bialix | I don't have twisted | 17:05 |
Jc2k | ah i see | 17:06 |
Jc2k | i use nosetests instead of twisted | 17:06 |
bialix | do you think my test runner will be too much of trouble for you and jelmer? | 17:07 |
bialix | though it's optional | 17:07 |
Jc2k | its not up to me, but i have no objections to it. | 17:07 |
bialix | what it means "up to me"? | 17:08 |
Jc2k | its not my decision | 17:08 |
bialix | jelmer said: "ah, ok". so I'll prepare the patch then | 17:09 |
kfogel | Can anyone think of a workaround for bug #97715 ("bzr log DIR should show changes under DIR")? | 17:34 |
ubottu | Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715 | 17:34 |
kfogel | I ask because 'bzr log -v' (the obvious workaround) is too slow. | 17:34 |
kfogel | I can't think of any other workarounds, but maybe someone here can? | 17:34 |
=== kiko is now known as kiko-afk | ||
=== bac is now known as bac_afk | ||
sohail | I need help... I have two branches, master and next... I was doing work in the "next" branch by switching to it.. However when I switch back to the master branch, the next changes are in this branch! The log however says that the changes were made to branch nick "next". So lost.. Help... please... | 18:03 |
nua | how can I get a machine readable log from bzrlib? Do I have to write a log formatter? | 18:05 |
kfogel | Can anyone think of a workaround for bug #97715 ("bzr log DIR should show changes under DIR")? | 18:38 |
ubottu | Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715 | 18:38 |
kfogel | I ask because 'bzr log -v' (the obvious workaround) is too slow. | 18:38 |
kfogel | I can't think of any other workarounds, but maybe someone here can? | 18:38 |
Goundy | Hi. Quick & noob question: | 18:42 |
Goundy | I've two branchs: mainline (main branch) and working (the branch I work on) | 18:42 |
Goundy | When I do changes and commits on my working branch then I call: cd ../mainline && bzr merge ../working | 18:43 |
Goundy | but I figured out that I lose all commits I did on my working branch | 18:43 |
luks | you do not lose them | 18:43 |
Goundy | luks well yes I know | 18:43 |
Goundy | But what I want to do is to apply changes on mainline and also commits with commits messages I wrote while commting in working | 18:44 |
Goundy | Is there a way to do that ? | 18:44 |
luks | are you planning to remove the working branch after merging it? | 18:44 |
jelmer | kfogel, I don't think there is a good way to work around that. brisbane-core will be *some* help I think | 18:44 |
Goundy | luks no I just work on it everytime, and use the mainline one to apply patchs... etc | 18:45 |
kfogel | jelmer: thanks | 18:46 |
luks | Goundy: then there is no good way | 18:46 |
Goundy | ha :/ | 18:46 |
luks | Goundy: there is a way if you don't mind destrying the working branch | 18:46 |
Goundy | luks well no way ^^ | 18:46 |
Goundy | thank you :-) | 18:46 |
luks | but if you intend to continue to work in it, it would cause problem | 18:46 |
luks | +s | 18:46 |
Goundy | I see yea | 18:47 |
Goundy | luks then is there a good & quick way to specify commit message for each change ? | 18:48 |
luks | btw, what I meant was "bzr rebase ../mainline && cd ../mainline && bzr pull ../working" | 18:48 |
luks | Goundy: specify? | 18:48 |
luks | where? | 18:48 |
Goundy | luks well atm I do: bzr commit -m "my message" | 18:49 |
Goundy | and this message applies to all my changes | 18:49 |
jelmer | kfogel, are the emacs-related bugs tagged in launchpad, or is there a list of emacs-related bugs? | 18:49 |
Goundy | for example if I want a different message for each file is there another way than bzr commit /path/to/file/file.c -m "message" ? | 18:49 |
kfogel | jelmer: look for "emacs-adoption" tag, I think | 18:50 |
luks | I don't know, I personally use qcommit which is a window that allows me to select files and type the message | 18:50 |
luks | easier to pick which files you want to commit, but probably not what you are looking for | 18:51 |
Goundy | luks I hate UI for DVCS softwares ^^ | 18:52 |
Goundy | but thanks for the tip ;) | 18:52 |
luks | well, it's easier than typing and tab-completing the filenames | 18:52 |
kfogel | jelmer: I've just add bug #246891 to that list, and see this comment: | 18:53 |
ubottu | Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] https://launchpad.net/bugs/246891 | 18:53 |
santagada | usually I also hate the gui for all vcs | 18:53 |
kfogel | https://bugs.edge.launchpad.net/bzr/+bug/246891/comments/8 | 18:53 |
ubottu | Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] | 18:53 |
santagada | but during commit they help a lot | 18:53 |
Goundy | luks sure but I really think DVCS shouldn't be used through GUI front ends... that really sucks | 18:54 |
Goundy | And sometimes you get hard bugs I hate that >< | 18:54 |
luks | Goundy: what's so special about DVCSes? | 18:54 |
Goundy | luks DVCSes are fine but not GUI front ends written for them that's it | 18:54 |
Goundy | well not all DVCSes are cool of course (CVS and SVN -> trash :P) | 18:55 |
Goundy | And that was the troll of the day \o/ | 18:55 |
=== bac_afk is now known as bac | ||
LeoNerd | Eh. CVS isn't so bad, really... It's very clear upfront about what it can and can't do. Of the things it can do, it does very well | 18:56 |
Goundy | heh might be true but as I said: that's a troll :P | 18:57 |
Goundy | personnaly I was using svn, but once I discovered bazaar >_<' I really liked it ! that's an awesome release | 18:57 |
Goundy | Fast, simple and powerful (nothing missing) | 18:57 |
kfogel | jelmer: hunh. In launchpad's bzr bug tracker, I just did "Search: Enter bug ID or keywords:" and entered "emacs-adoption". Now, I *know* there's at least one bug with that tag, because I just tagged 246891 with it, and there should be four others from before as well. But nothing came up. | 18:59 |
jelmer | kfogel, if you go to the "bugs" tab in zbr | 18:59 |
kfogel | jelmer: ooooooh | 18:59 |
jelmer | there's a list of links on the right with tags | 18:59 |
kfogel | advanced search | 18:59 |
kfogel | So "tags" are different from "keywords". | 19:00 |
kfogel | yeah, found it | 19:00 |
sohail | anyone have an idea about: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/51820 | 19:06 |
davidstrauss | lifeless: I have Yves's bzr.log when you're ready. | 19:38 |
=== mtaylor_ is now known as mtaylor | ||
mtaylor | lifeless: so... bzr uncommit gives me a confirmation dialog | 20:16 |
mtaylor | lifeless: bzr revert, on the other hand, happily just works | 20:16 |
mtaylor | lifeless: except that sometimes I've accidentally hit enter after the word revert when I just meant to revert one file | 20:16 |
mtaylor | and have lost an entire tree's worth of changes | 20:16 |
mtaylor | perhaps a config option to turn on revert confirmation dialogs? | 20:17 |
garyvdm | bzr uncommit has a way to undo - bzr revert doesn't | 20:17 |
mtaylor | Goundy: so, there's a patch to gcommit that allows per-file commit messages | 20:17 |
mtaylor | damn | 20:18 |
mtaylor | just missed him | 20:18 |
=== thekorn_ is now known as thekorn | ||
kenichi | is there a flag or something to tell bzr-email to send from the server vs. from the client? | 21:44 |
kenichi | i have two identically configured servers and branches. committing to a branch on one sends email from the server process itself (apache), committing to a branch the other sends (or tries and fails) from the client. | 22:04 |
=== kiko is now known as kiko-afk | ||
=== mark2 is now known as markh | ||
=== cody-somerville_ is now known as cody-somerville | ||
=== edcrypt_ is now known as edcrypt | ||
=== dereine is now known as dereine[OFF] |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!