| poolie | hello | 00:02 |
|---|---|---|
| poolie | spiv, jam, igc, lifeless, call in a minute | 00:02 |
| markh | jelmer: ? | 00:07 |
| jelmer | markh, hi | 00:08 |
| markh | hi jelmer - I see you made a change for that crash on osx - is there anything I should do for windows binaries? | 00:08 |
| markh | I saw another bug report recently and marked it as a dupe | 00:09 |
| markh | but its a dupe of the osx one (which the other windows crash bug is too), and that is marked as fixed | 00:09 |
| spiv | abentley: bundlebuggy seems to be giving 502 atm | 00:09 |
| jelmer | markh, there were other fixes for Windows by Snaury as well | 00:10 |
| markh | jelmer: so if I just rebuild all should be good? | 00:10 |
| jelmer | markh: Yeah, I think so | 00:10 |
| markh | that was the perfect answer :) | 00:10 |
| markh | do I need to move to 1.5 or anything? | 00:11 |
| jelmer | I would recommend building against 1.5 but for other reasons (several bugfixes that may be relevant, more protocol calls available to svn) | 00:11 |
| markh | ok - iirc that will require some tweaks to setup.py as the list of libs has changed. I'll see how I get on... | 00:12 |
| markh | (that was the only reason I dropped back to 1.4 in the first place - the existing list of libs was already correct!) | 00:13 |
| jelmer | markh, Snaury tweaked some of that as well afaik | 00:14 |
| abentley | Soliton: restarted | 00:23 |
| abentley | spiv: restarted | 00:23 |
| spiv | abentley: thanks! | 00:23 |
| jml | wuu patches. | 00:43 |
| lifeless | abentley: you nearly got spivs origin correct | 00:47 |
| abentley | lifeless: Hee. | 00:47 |
| jml | poolie: does your updated patch address the problem I noticed here: http://paste.ubuntu.com/47029/ ? | 00:59 |
| justizin | so, ah, again, i renamed some files from bin/ of my repo to scripts/, because bin/ is really a virtualenv and it ends up with all these generated scripts which show up in 'bzr status', i want to just add bin/ to ignores, but i can't get my parent branch to show the change. | 01:32 |
| jml | justizin: you need to commit changes to your ignore file. | 01:44 |
| justizin | jml: i haven't changed the ignore yet, i only moved the files which i want source-controlled, and my 'master' branch doesn't show the rename.. | 01:51 |
| justizin | even after a bzr update | 01:51 |
| justizin | also, now i am trying to merge with an svn branch and i get: bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1558390>". | 01:52 |
| justizin | woo fun :) | 01:52 |
| justizin | this is a relatively old bzr 1.5 and older bzr-svn, of course.. looking forward to intrepid. | 01:52 |
| justizin | but it's been working fine for months, just think this is odd.. | 01:53 |
| justizin | for instance, i bzr mv bin/disable-stuff scripts/disable-stuff | 01:53 |
| justizin | in the repo on my laptop where i'm working, the change is there, i committed, i pushed, and on the server, i ran bzr update.. | 01:53 |
| justizin | and i checked everything i could think of. | 01:53 |
| justizin | both report the same rev # | 01:53 |
| justizin | but the contents diverge | 01:54 |
| justizin | Oo | 01:54 |
| jml | justizin: so maybe you need to merge one into the other. | 01:58 |
| justizin | tried merge, says nothing to do.. | 01:58 |
| justizin | only changes in one branch, atm.. | 01:58 |
| jml | so, what are you trying to do? | 01:59 |
| === kiko is now known as kiko-zzz | ||
| === abentley1 is now known as abentley | ||
| jml | poolie: ping | 02:34 |
| justizin | jml: i'm trying to see my changes in the parent branch. | 02:37 |
| justizin | bzr says everything is fine, that the tree is up to date, but i'm saying, dude, it's not. | 02:38 |
| jml | justizin: ok. so you have two branches, you've made changes in one and not in the parent branch? | 02:39 |
| jml | how did you tell bzr about those changes? (maybe you could paste a log to http://paste.ubuntu.com?) | 02:39 |
| justizin | that is correct. i commit. i push. i merge. i pull. i checkout. i update. no dice. | 02:39 |
| justizin | i don't have a log handy, but i did as i normally do. i understand the concepts of push, pull, merge, working trees and when i push over ssh, the working tree isn't updated.. | 02:40 |
| jml | oh ok. | 02:40 |
| justizin | so they report the same rev #, attempts to push or merge say that there is nothing to do, bzr status / diff on my laptop shows no changes uncommitted, and bzr update on the server says also, nothing to do, tree is updated.. | 02:40 |
| justizin | i guess the next thing to check to be 100% is that a branch off the server has the new changes, though it's tree doesn't.. | 02:41 |
| jml | yeah, that's worth checking | 02:41 |
| justizin | yah a fresh checkout shows the changes.. | 02:43 |
| justizin | bewildering | 02:43 |
| spiv | justizin: what does "bzr revision-info" report? | 02:43 |
| justizin | i'd nuke the server copy, but it's a branch of svn and i'm afraid i'll lose heritage | 02:43 |
| justizin | 135 justizin@justin-ryans-macbook-pro-15.local-20080915190426-w8st6jjdasmd24ox | 02:44 |
| justizin | for both | 02:44 |
| justizin | and that'd be the commit from my laptop. | 02:44 |
| spiv | So, they are exactly the same branch then. | 02:44 |
| justizin | yah, but the working tree on the server is broken, which is my public http browsification | 02:45 |
| spiv | justizin: so you want to update the working tree on the server? | 02:45 |
| justizin | yah and again i understand when i push over ssh that doesn't happen, so i'm on the server and bzr update says the tree is up-to-date, though it's inconsistent with other branches, even the fresh one i just created *from* the branch with the broken wt | 02:47 |
| spiv | justizin: perhaps you want to be using one of these plugins? <https://launchpad.net/bzr-push-and-update> or <https://launchpad.net/bzr-automirror> | 02:47 |
| justizin | spiv: possibly, but again, i'm fine with manually updating the tree for now, it just refuses to update.. | 02:47 |
| spiv | justizin: does 'bzr info' in the tree on the server report the branch URL you expect? | 02:47 |
| justizin | well it's a branch from an svn repo | 02:48 |
| spiv | And what does "bzr status" say? | 02:48 |
| justizin | one sec.. | 02:48 |
| justizin | (info does report as expected btw) | 02:48 |
| justizin | well as of now it has pending merges from svn, which is a new problem, but the issue i'm talking about with the working tree was pre-existing.. | 02:49 |
| spiv | So the working tree has uncommitted changes? | 02:49 |
| justizin | and, fwiw, i am now getting: bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1558390>". | 02:49 |
| justizin | well, it does as of about 20 min ago | 02:50 |
| justizin | the working tree problem is maybe 8-12 hours ol | 02:50 |
| justizin | old | 02:50 |
| spiv | Uncommitted changes would explain why the working tree's contents don't match the last revision in the branch. | 02:50 |
| justizin | it doesn't even have uncommitted changes, it's odd.. i reverted the files from the merge earlier and it just says pending merges with no other change info.. | 02:50 |
| justizin | no, they can't, because time only moves forwards - check wikipedia. ;) | 02:50 |
| justizin | the working tree problem is pre-existing | 02:50 |
| justizin | now of course it's all flubbed up and i take responsibility for that | 02:51 |
| spiv | The revision not present error sounds like a bzr-svn bug. | 02:51 |
| justizin | possibly, i don't have the latest bzr-svn b/c i'm using ubuntu hardy heron packages.. | 02:51 |
| justizin | i think i'll just end up creating a new bzr repo and futzing the svn merges on this.. | 02:51 |
| spiv | So I don't understand your problem. If "bzr update" says the branch is up to date, and "bzr status" says no files are changed in the tree, then there are no changes. | 02:51 |
| justizin | yeah, but i am a human and my brain says the files are laid out differently in a fresh branch from here.. | 02:52 |
| spiv | Is "bzr status" in the fresh branch clean? | 02:52 |
| justizin | i moved files from bin/ to scripts/ in my repo, and they are moved on my laptop where i moved them, and they are moved in a fresh branch from the server to a temp location.. | 02:52 |
| justizin | the fresh branch was created during this conversation.. | 02:53 |
| justizin | as a means of verifying that the bzr repo had the changes, but the working tree on the server, itself, was broken.. | 02:53 |
| spiv | Sure, we're at the point where there's a wrong assumption somewhere, I think, so you'll have to pardon the dumb questions :) | 02:53 |
| justizin | no it's ok | 02:53 |
| justizin | i'm just frustrated and of course i explained some of this to other people over the course of the day | 02:54 |
| spiv | (Hopefully I don't need to question http://en.wikipedia.org/wiki/Arrow_of_time ;) | 02:54 |
| justizin | and now i hosed the repo for bzr *and* svn so it's all gone to hell and confusing ;d | 02:54 |
| justizin | i realized while i was explaining the problem from earlier today that i came back in here for the new missing revision problem, in the same bzr branch / repo. | 02:54 |
| justizin | it's ok, i'm learning. noone's life support fails if this branch dies, and none of my customers will fire me. :) | 02:55 |
| justizin | and if i wasn't using outdated code, i'd be helping to test bzr and bzr-svn :-P | 02:55 |
| justizin | i noticed that bzr can be installed via setuptools now, btw - super rad. | 02:55 |
| justizin | thinking of taking advantage of that for our plone deployment. | 02:55 |
| justizin | so i can distribute a tarball of a buildout that installs bzr and pulls dev code. | 02:56 |
| justizin | maybe.. | 02:56 |
| spiv | So I don't have any idea where your problem is. If you have two up-to-date working trees at the same revision, and no uncommitted changes (i.e. a clean 'bzr st'), then I don't see any way for them to have different contents in their versioned files. | 03:00 |
| poolie | jml, pong | 03:00 |
| jml | poolie: so, with your patch applied to bzr.dev, I can branch stacked branches into shared repos, but not standalone. | 03:05 |
| jml | poolie: I get the same error that I pasted yesterday. | 03:05 |
| jml | http://paste.ubuntu.com/47029/ | 03:05 |
| poolie | ok | 03:06 |
| poolie | that's good to know | 03:06 |
| poolie | in a way | 03:06 |
| poolie | you also said you had conflicts? | 03:06 |
| jml | poolie: yeah, in remote.py and test_remote.py | 03:06 |
| spiv | jml: how recent is your bzr.dev? (It's probably unlikely, but I'm wondering if revno 3709 might help?) | 03:07 |
| jml | spiv: 3709 | 03:07 |
| jml | the clash is with the changes in r3695 | 03:07 |
| jml | poolie: so, should I file a separate, critical bug for the AttributeError problem? | 03:09 |
| poolie | that'd be good, and assign it to me | 03:11 |
| beuno | http://dev.mysql.com/tech-resources/articles/advanced-bazaar.html | 03:15 |
| beuno | w00t | 03:15 |
| poolie | hello beuno | 03:17 |
| beuno | hey poolie | 03:18 |
| beuno | how are you? | 03:18 |
| jml | poolie: https://bugs.edge.launchpad.net/bzr/+bug/270738 | 03:20 |
| ubottu | Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] | 03:20 |
| mlh | there are a shorter form of 'mkdir bzr; cd bzr; bzr init-repo .' ? | 03:37 |
| spiv | mlh: "bzr init-repo bzr ; cd bzr" | 03:38 |
| mlh | I see that sequence mentioned in more than one place and wonder whether just 'bzr init-repo bzr ; cd bzr' might be better | 03:38 |
| mlh | yer | 03:39 |
| mlh | I just read Bueno's link above, and also the bzr hacking guide and they both have that triple in preference | 03:39 |
| mlh | whereas the double I think is more intuitiev and reliable | 03:40 |
| spiv | I prefer the double too. | 03:41 |
| mlh | A bzr newbie might look askance at the amount of typing required just to start a repo | 03:42 |
| mlh | perhaps bzr init-repo somedir used not to work in some older version of bzr? | 03:42 |
| lifeless | jml: poolie will be a minute | 03:46 |
| lifeless | mt,ignore me | 03:46 |
| * jml ignores. | 03:46 | |
| === bob2_ is now known as bob2 | ||
| abentley | poolie: Want to talk about Launchpad bzr teams? | 04:20 |
| markh | jam: ? | 04:39 |
| poolie | abentley, hi, just saw your mail about them | 04:45 |
| poolie | and also about process - i was hoping someone else might reply | 04:45 |
| abentley | poolie: Oh well. | 04:47 |
| poolie | ? | 04:47 |
| poolie | so that was a yes, i'm happy to talk about them | 04:48 |
| abentley | Okay, what do you think about the plan I outlined? | 04:49 |
| poolie | i thought there might be other teams that need to be cleared up | 04:51 |
| poolie | um | 04:51 |
| poolie | presumably after the last step you're wanting to leave ~bazaar-overall yourself and rejoin ~bzr? | 04:51 |
| abentley | Right. | 04:52 |
| abentley | bazaar-overall is already a member of Loom-developers and the RSS thing. | 04:52 |
| poolie | reassigning people is probably a pita but perhaps a rubber duck will do it | 04:52 |
| abentley | rubber duck? | 04:52 |
| poolie | a launchpad admin | 04:53 |
| lifeless | no duckie will do this | 04:53 |
| lifeless | personally, I'd leave ~bzr where it is and just change owners on the projects that shouldn't be owned by ~bzr | 04:54 |
| poolie | there is also a ~bzr-developers, do you know how that's supposed to fit in? | 04:54 |
| abentley | poolie: My original idea was to create a *new* team to be the just-the-bazaar-codebase team. But then you wanted to make bzr mean that. | 04:54 |
| poolie | so that would not require people to move around, which might be less traumatic | 04:54 |
| poolie | lifeless points out we don't necessarily need to move people | 04:55 |
| poolie | they can join ~bazaar-overall if they want to | 04:55 |
| abentley | bzr-developers was my original "just-bzr" team. | 04:55 |
| abentley | poolie: I think it would be surprising for members of ~bzr to suddenly stop getting updates about all the various plugins and stuff. | 04:56 |
| abentley | poolie: i.e. I don't think that moving people to bzr-overall is optional or opt-in. It would be disruptive not to move them, if we follow that plan. | 04:57 |
| lifeless | abentley: I think its more disruptive to have to move and rename all the branches etc | 04:59 |
| lifeless | well, let me put my 2c in. I want you to get what you want here | 05:00 |
| abentley | lifeless: Why would we have to move and rename branches? | 05:00 |
| lifeless | personally, I will want to end up getting the notifications I get; and I don't want to have to update push urls en-masse (though I'm happy to do so in an adhoc basis subsequent to teams and owners being sorted) | 05:01 |
| lifeless | abentley: there are a bunch of ~bzr owned branches for various plugins | 05:01 |
| lifeless | abentley: if 'bzr' is renamed, their urls will change | 05:01 |
| abentley | lifeless: I didn't think any of our plans involved renaming 'bzr'. | 05:02 |
| lifeless | beyond that, I'm happy with anything | 05:02 |
| lifeless | abentley: the bzr team I mean | 05:02 |
| lifeless | '~bzr' in lp namespace terms | 05:02 |
| abentley | lifeless: Still, I don't think any of our plans involved renaming ~bzr. | 05:03 |
| lifeless | ok | 05:03 |
| abentley | But we might well end up changing ownership of a bunch of plugin branches. | 05:03 |
| abentley | So they would go from ~bzr to ~bazaar-overall or something. | 05:04 |
| jml | hey guys | 05:05 |
| abentley | jml: moo | 05:05 |
| abentley | poolie: So do you have an idea how you want to proceed? | 05:06 |
| jml | is this a new bug or an old one: 'bzr info -v http://mumak.net/code/stacked' raises an error and 'bzr info -v nosmart+http://mumak.net/code/stacked' does not | 05:06 |
| poolie | abentley, it does seem like making ~bzr-developers own bzr is a smaller change | 05:07 |
| poolie | and then ~bzr will be a member of that | 05:07 |
| poolie | then you can change your membership but other people won't be affected | 05:07 |
| jml | the server is using 1.6.1 from the ppa and I'm using bzr.dev with poolie's patch applied. | 05:07 |
| poolie | possibly we should rename ~bzr-developers to ~bzr-core-dev or something | 05:07 |
| abentley | poolie: Sure, whatever you like. | 05:07 |
| abentley | jml: I don't know whether it's a regression. | 05:08 |
| poolie | can you see any problems with that? | 05:08 |
| abentley | poolie: I think the original reason you didn't want to do that was because the PPA locations would change, or something likethat. | 05:09 |
| poolie | so we can't really rename ~bzr or stop using it for the ppa without causing that disruption | 05:10 |
| poolie | in retrospect teams for ppas should be dedicated only to that purpose | 05:10 |
| poolie | but i think if we do just this it should be ok | 05:10 |
| poolie | so should i do this now? | 05:10 |
| abentley | poolie: That would be great. | 05:10 |
| abentley | jml: My bzr.dev is prolly out of date, but info -v does not raise an error on that URL. | 05:13 |
| markh | jelmer: still here? | 05:13 |
| abentley | jml: I am on revno 3698. | 05:15 |
| jml | abentley: 3709 personally | 05:16 |
| mwhudson | abentley: interesting, my bzr.dev is 3702 and does traceback | 05:16 |
| mwhudson | tracebacks after bzr revert -r 3698 too, though | 05:17 |
| lifeless | pycurl? | 05:18 |
| mwhudson | i don't have pycurl installed | 05:18 |
| abentley | jml: False data. I had mistyped the URL slightly. | 05:20 |
| jml | lifeless: how can I force urllib? | 05:20 |
| mwhudson | jml: http+urllib | 05:21 |
| lifeless | http+urliib ? | 05:21 |
| * jml gets the same with urllib | 05:23 | |
| * abentley reminds the crowd that his original statement was wrong; it does traceback for him now. | 05:23 | |
| jml | abentley: I hear you :) | 05:24 |
| abentley | My best guess is that the repository isn't getting stacked. | 05:24 |
| abentley | jml: Do other operations on that URL work? | 05:26 |
| * abentley is off to bed. | 05:33 | |
| * jml tries some | 05:33 | |
| jml | branch works | 05:34 |
| jml | info doesn't. | 05:34 |
| jml | BzrDir.clone probably doesn't | 05:34 |
| lifeless | spiv: have reviewed for you, wasn't happy enough to approve, wasn't unhappy enough to resubmit | 05:37 |
| lifeless | spiv: so I just commented | 05:39 |
| jml | mwhudson_: welcome back | 05:40 |
| * mwhudson_ grrs | 05:40 | |
| mwhudson_ | networkmanager appears to have gone on holiday on my macbook | 05:40 |
| poolie | abentley, ok, bazaar-overall should no longer be necessary | 05:49 |
| poolie | biab | 05:49 |
| === mwhudson__ is now known as mwhudson | ||
| === Snaury is now known as Snaury[away] | ||
| spiv | lifeless: that's great, thanks! I've replied; any thoughts on a better name/location than test_effort? | 06:36 |
| vila | Goood.. hello guys | 07:01 |
| markh | which platforms or distribution methods get the full html versions of the docs? | 07:08 |
| lifeless | spiv: well, I'd have put it in test_remote I think | 07:25 |
| lifeless | spiv: as I expect there will be a number of similar tests and they are all remote-centric AIUI | 07:26 |
| lifeless | markh: dunno ? :P | 07:26 |
| lifeless | markh: docs.bazaar-vcs.org :P | 07:26 |
| markh | they are a nice source of pre-generated xhtml versions of each of the help topics I'm trying to work out if I can leverage :) | 07:27 |
| markh | generating html at runtime from the 'rst-like' help text in bzrlib doesn't sound like fun | 07:28 |
| spiv | lifeless: I expect there will be too, which is why I don't want them in test_remote. | 07:29 |
| lifeless | spiv: I don't understand | 07:30 |
| lifeless | I think I'm hearing 'because these things are related to remote tests and will be similar to each other I don't want them with other remote tests' | 07:30 |
| spiv | I don't mind them being "with" other remote tests, I just don't want them in the existing test_remote module. | 07:31 |
| spiv | so I'd rather have the new tests in test_remote_SOMETHING, or make a bzrlib/tests/remote/ directory with test_marshalling and test_effort in it, or a solution like that. | 07:32 |
| spiv | Because test_remote is already quite large, and I don't like test modules with a vague purpose like "test everything related to bzrlib/remote.py". | 07:33 |
| spiv | Does that make sense? | 07:33 |
| lifeless | I'd prefer you made remote tests into a package than a concept-related test module, because all our other tests are module/class/method related, not concept. | 07:35 |
| spiv | Basically, I see these tests as being in a related but definitely distinct category to the tests in test_remote | 07:35 |
| lifeless | wow my arms are still itchy as hell from the allergy test | 07:36 |
| spiv | A package is fine with me, and it sounds like it's ok with you? If so, I'll do that. | 07:37 |
| lifeless | hang a sec | 07:38 |
| lifeless | mailing | 07:38 |
| spiv | Ok. | 07:38 |
| lifeless | ok, mailed | 07:42 |
| lifeless | writing a paragraph helps me think sometimes | 07:42 |
| lifeless | anyhow, bzrlib.tests.per_branch.test_push is where I think it belongs | 07:43 |
| spiv | Really? Interesting. | 07:43 |
| lifeless | the mail should be there now, read it and lets chat more if it doesn't make sense | 07:43 |
| spiv | I was thinking that a per_branch test would be low bang-for-buck, and also significantly more complex, because the RPC count for push could legitimately be different for different formats. | 07:47 |
| lifeless | fork() | 07:47 |
| spiv | (especially while we still fallback to VFS for various things) | 07:47 |
| lifeless | on the one hand, I think this is too low level anyhow, it really demands to be cmd_push that is tested | 07:48 |
| spiv | (Currently that patch has a test for both cmd_push and for branch_object.push) | 07:48 |
| lifeless | on the other branch, I would set an upper ratchet on a per-branch types, if they are different | 07:49 |
| lifeless | uhm anyhow | 07:49 |
| lifeless | My key concern is SUT<->TestCode connections | 07:49 |
| spiv | Yes, that's very important. | 07:52 |
| lifeless | I don't think grouping tests by the fact they test overall effort is useful | 07:52 |
| lifeless | (We don't test all the e.g. constructor method tests together) | 07:53 |
| spiv | No, me either. | 07:53 |
| lifeless | so cmd_push's test should definitely be in blackbox/tests/test_push.py IMO | 07:53 |
| spiv | (Even though it was the way I was leaning initially) | 07:53 |
| lifeless | the branch.push test I would be happy with either a per_branch, or a specific format test | 07:53 |
| lifeless | doing per_branch would mean that new formats get <some> coverage by default | 07:54 |
| spiv | See, that's strange to me. It seems to me that the cmd_push test is as appropriate as a per_branch test as the other one. | 07:54 |
| spiv | Well, nearly. | 07:54 |
| lifeless | it is nearly | 07:55 |
| lifeless | the problem is the tension between the cmd_push code, and the code it calls | 07:56 |
| spiv | Having coverage for new formats is a very good point. That probably does make a per_branch test worthwhile. | 07:56 |
| imyojimbo | hi, i've just installed bzr. and every command i enter in the console outputs a warning "bzr-svn is not up to date with installed bzr version 1.7rc1. There should be a newer version of bzr-svn available." what do i do | 07:58 |
| lifeless | imyojimbo: have you installed a daily snapshot or something ? | 07:58 |
| imyojimbo | no | 07:59 |
| imyojimbo | the latest build for Windows | 07:59 |
| lifeless | ah | 07:59 |
| lifeless | markh: ^ | 08:00 |
| spiv | lifeless: btw, I see no difference in behaviour in pushing unreconstructable tags with bzr.dev vs. faster-empty-push | 08:00 |
| lifeless | spiv: I know, I was saying that the tags support <-> repository layering etc needs an overhaul | 08:00 |
| lifeless | and it will change the shape of the tuning you are doing | 08:00 |
| spiv | I'm not sure what you're telling me. Are you saying that my change is incorrect, or just that it's likely that someone else will touch this code at sometime soon? | 08:02 |
| lifeless | uhm | 08:02 |
| lifeless | I think the current code is faulty | 08:02 |
| lifeless | and that your change may make it more faulty | 08:02 |
| spiv | Ah. As far as I can tell it's bug-for-bug compatible :) | 08:03 |
| lifeless | further, that we may need to probe for revisions routinely when we fix the tag behaviour, to correct previous misbehaviour. | 08:03 |
| lifeless | the tag stuff doesn't need to block us. Oh, but I have a small metacomment | 08:04 |
| imyojimbo | ?? | 08:04 |
| lifeless | imyojimbo: I don't know anything about the windows builds; markh is the dev making them, he can answer your question | 08:05 |
| lifeless | spiv: the metacomment is that 'no-op push' is not the common case. The common case is arguably 'changed tip with tags in branch', so changes that only help special cases but are less clear/useful for plugins etc are not auto-approve from me | 08:06 |
| imyojimbo | ok, thanks | 08:06 |
| lifeless | spiv: w.r.t. tags, I'd like to this change not assume that no-tags implies no-change-to-remote-tags | 08:07 |
| lifeless | spiv: so either delegate to a helper method subclasses can replace, or something along those lines | 08:07 |
| spiv | Pushing 0 revisions is not *the* common case, but it's not an uncommon one either. A push of a branch with no tags is also fairly common I think (certainly all my bzr work falls in that category atm). | 08:10 |
| spiv | I definitely wouldn't assume that anything is an auto-approve from you unless it's crystal clear that's improvement in every respect :) | 08:11 |
| lifeless | spiv: sure, I'm not saying 'do not optimise' I'm saying 'for the common case I give clarity/extensibility a lower weighting' | 08:12 |
| spiv | Ah, I see. Sure. | 08:12 |
| spiv | In short: I'm glad you reviewed this :) | 08:13 |
| imyojimbo | ops. i did install the release candidate 1. and not the stable version 1.6.1 should i just unistall and reinstall the stable version? | 08:15 |
| imyojimbo | *1.7 | 08:15 |
| lifeless | imyojimbo: yes, installing 1.6.1 again would probably fix the error | 08:16 |
| imyojimbo | should i uninstall the current version, or just overide it with the new install | 08:17 |
| mdke | hi. I need to revert the last commit done on a branch, what's the proper way to do that? with "revert" or "merge"? | 08:24 |
| spiv | lifeless: http://rafb.net/p/1Edrnu30.html <-- change to allow subclasses to vary when tags are pushed by _basic_push | 08:24 |
| spiv | mdke: 'bzr uncommit' usually | 08:25 |
| mdke | spiv: that worked. Wow that's simple :) | 08:26 |
| spiv | mdke: if you don't want to permanently remove that commit from the branch's history, then 'bzr revert -r 2 && bzr commit' | 08:26 |
| spiv | :) | 08:27 |
| spiv | (Oops, "bzr revert -r -2" is what I meant in that example, not that you care...) | 08:27 |
| mdke | spiv: if I'm working on a bound branch, does "bzr uncommit" fix the serverside branch too? | 08:27 |
| spiv | Yes. | 08:28 |
| mdke | supercool | 08:28 |
| mdke | thanks very much | 08:28 |
| spiv | You can check for yourself with 'bzr log -r -1 URL' :) | 08:28 |
| mdke | ok | 08:28 |
| lifeless | spiv: that looks ok to me | 08:28 |
| mdke | and the last question. | 08:28 |
| spiv | lifeless: thanks | 08:28 |
| mdke | users doing "bzr update" from the server branch will automatically get the uncommit too? | 08:29 |
| === vk5foss is now known as kgoetz | ||
| spiv | mdke: yep | 08:30 |
| AfC | (it'll "update" to whatever the current revision is) | 08:30 |
| mdke | great | 08:31 |
| mdke | thanks again | 08:31 |
| lifeless | ok, I'm out :) | 08:49 |
| akuehntopf | hello...if i do a bzr merge ../bundle.patch the original author is not preserved.. pull did not work, it told me to merge...merge applies cleanly (using cherry-pick). How can i preserve the original author? i'm using bzr 1.6.1 | 09:28 |
| akuehntopf | is it possible at all? | 09:28 |
| bob2 | akuehntopf: it should be preserved | 09:40 |
| bob2 | akuehntopf: (as commits underneath your merge commit) | 09:41 |
| akuehntopf | unfortunately not, does it have something to do with "merge" doing cherry-pick? | 09:42 |
| akuehntopf | because i couldn't use pull | 09:43 |
| bob2 | you commited, and 'bzr log' didn't show the commits indented below the merge? | 09:43 |
| akuehntopf | it showed them, but using my id as the commited | 09:45 |
| akuehntopf | committer | 09:45 |
| akuehntopf | i'm sure i did something wrong, i'm not that familliar with bzr yet | 09:45 |
| akuehntopf | so my steps were as follows: | 09:45 |
| akuehntopf | bzr branch main feature | 09:46 |
| akuehntopf | cd feature | 09:46 |
| akuehntopf | bzr merge ../bundle.patch | 09:46 |
| akuehntopf | bzr commit | 09:46 |
| akuehntopf | cd ../main | 09:46 |
| akuehntopf | bzr merge ../feature | 09:46 |
| bob2 | that's how merge works | 09:46 |
| bob2 | it creates a new commit, with your user id | 09:46 |
| akuehntopf | ok | 09:46 |
| akuehntopf | and pull? | 09:46 |
| akuehntopf | would pull have preserved it? | 09:46 |
| AfC | akuehntopf: install bzr-gtk and then try the visualize command with `bzr viz`. You'll get a much better idea of what's going on. | 09:50 |
| akuehntopf | oh hi AfC , long time no see ;-) | 09:52 |
| akuehntopf | i guess i'll try it using a simple demo repository | 09:52 |
| bob2 | pull would have just prepended them to the current revisions, yes | 09:52 |
| akuehntopf | alright | 09:53 |
| poolie | spiv, are you still around perchance? | 10:02 |
| Snaury[work] | jelmer: do you have ideas why bzr-svn does not save passwords it's asking for? | 10:43 |
| jrb_ | are location now implemented for anything other launchpad. the only thing i could find was a brain dump from 2005. otherwise what is the current status? | 10:47 |
| jrb_ | sorry for the missing words in these sentences :( | 10:47 |
| poolie | jrb_, what kind of location? | 10:51 |
| === siretart_ is now known as siretart | ||
| * gour is wondering how people auto-generate changelog with bzr | 11:41 | |
| james_w | gour: there's a gnulog plugin to output a GNU-style changelog | 11:47 |
| gour | james_w: ohh, thanks | 11:47 |
| Pilky | has anyone else had trouble with the 1.6.1 installer? | 11:54 |
| Pilky | for Mac OS X | 11:54 |
| jelmer | Snaury[away]: It doesn't do any password caching because that's up to bzr and svn | 12:14 |
| Snaury[work] | Hmm. But somehow it doesn't. :-/ | 12:15 |
| Snaury[work] | jelmer^^ | 12:15 |
| grutte_pier | Just a quick check: if I want to use a smart server over http, I'd have to something like this... right? | 12:40 |
| grutte_pier | bzr revno bzr+http://jakob@www.astro.rug.nl/~jakobb/bzr_repos/repos1 | 12:40 |
| mwhudson | grutte_pier: new-ish bzr probes for the smart server by default | 12:42 |
| grutte_pier | mwhudson: allright.... but that doesn't make any difference for the traceback I get :P Just to make sure that I'm not filing a bug whilst using the wrong syntax :P | 12:43 |
| mwhudson | heh | 12:43 |
| jrb_ | poolie: the common prefix (or at least the server) of the branches on my own server | 12:44 |
| jrb_ | poolie: bzr checkout mine://foo | 13:08 |
| uws | jelmer: is the performance issue we recently discussed fixed in bzr-svn 0.4.12? at least bzr-svn 0.4.11 had the problem | 13:34 |
| jelmer | uws, yes, that's fixed in 0.4.12 | 13:35 |
| uws | jelmer: Ok, thanks. upgrading | 13:35 |
| jelmer | 0.5 will be even more significantly faster | 13:36 |
| VSpike | latest in a series of daft questions... .bzrignore, should it be added to source control? | 13:37 |
| uws | jelmer: how? | 13:39 |
| LarstiQ | VSpike: if you use 'bzr ignore' instead of touching .bzrignore itself it will add it to version control it self | 13:39 |
| uws | VSpike: Yes. | 13:39 |
| LarstiQ | VSpike: if you made it yourself, then yes | 13:39 |
| jelmer | uws, fewer roundtrips and cache database queries | 13:39 |
| LarstiQ | jelmer: and what is the ETA for 0.5? :) | 13:41 |
| VSpike | thx | 13:41 |
| jelmer | LarstiQ, "when I find the time" :-P | 13:41 |
| LarstiQ | jelmer: ok, so what are the blockers? :P | 13:42 |
| jelmer | basically, more tests - in particular tests for upgrading between different versions of the mappings | 13:42 |
| LarstiQ | jelmer, uws: btw, 4 oktober there is a Python community day at the NLLGG national gettogether in Utrecht | 13:42 |
| jelmer | LarstiQ, ah, thanks | 13:42 |
| LarstiQ | (and 27 november a PUN meeting in Rotterdam) | 13:43 |
| LarstiQ | which, coincidentally, I still need speakers for ;) | 13:43 |
| jelmer | hmm | 13:43 |
| jelmer | what sort of timeslots do the PUNs have, ~30 min? | 13:44 |
| LarstiQ | jelmer: 30 minutes and 5 minutes lightning talks | 13:45 |
| uws | PUN? | 13:45 |
| LarstiQ | uws: Python Usersgroup Nederland | 13:45 |
| LarstiQ | uws: http://wiki.python.org/moin/PUN/ | 13:46 |
| grutte_pier | I'd never heard of these... what kind of topics are usually covered during PUNs? | 13:46 |
| LarstiQ | grutte_pier: anything goes | 13:48 |
| LarstiQ | grutte_pier: http://wiki.python.org/moin/BvB28Aug has some of last time | 13:48 |
| LarstiQ | grutte_pier: also, http://vanrees.org/weblog/archive/2008/09/12/python-calculated-coin | 13:48 |
| jelmer | LarstiQ, I'd be interested in giving a talk if the meeting doesn't conflict with anything else in my agenda | 13:48 |
| LarstiQ | jelmer: cool | 13:49 |
| LarstiQ | grutte_pier: personally I'd like to get non-web topics, since that's a bit overrepresented imo | 13:49 |
| LarstiQ | gah! | 14:58 |
| LarstiQ | jelmer: ever run into svn repos that require authentication for reading parts of the repository? | 14:59 |
| === mzungu_ is now known as mzungu | ||
| jelmer | LarstiQ, yep | 15:16 |
| LarstiQ | jelmer: but you need access to the entire path to determine ancestry, right? | 15:18 |
| jelmer | LarstiQ, yep, at least in 0.4 | 15:18 |
| LarstiQ | jelmer: anything I can do right now? Other than bug the admin. | 15:18 |
| jelmer | LarstiQ, not really | 15:19 |
| LarstiQ | ok | 15:21 |
| === kiko-zzz is now known as kiko | ||
| ajaksu | any hints about merging to google code? (to allow svn-pushing there) | 16:13 |
| ajaksu | I get "URL is permanently redirected to None" | 16:14 |
| ajaksu | then "bzr: ERROR: exceptions.TypeError: expected string or buffer" :( | 16:14 |
| LarstiQ | ajaksu: could you pastebin the command you're trying with all the output? | 16:15 |
| ajaksu | LarstiQ: http://paste.pocoo.org/show/85422/ :) | 16:21 |
| awilkins | Anyone using OpenKomodo | 16:22 |
| awilkins | (cause I think I may try it) | 16:22 |
| LarstiQ | ajaksu: ok | 16:24 |
| jelmer | ajaksu, any chance you can try the latest revision from bzr-svn's 0.4 branch? | 16:24 |
| jelmer | that should give a clearer error | 16:24 |
| visik7 | I got this error with bzr-svn ImportError: cannot import name client | 16:24 |
| visik7 | any clue ? | 16:25 |
| LarstiQ | visik7: is this 0.4.11 or newer? In that case, did you build it? | 16:25 |
| ajaksu | jelmer: sure, let me get it :) | 16:26 |
| ajaksu | jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/0.4, right? | 16:28 |
| visik7 | LarstiQ: newer and yes | 16:28 |
| jelmer | ajaksu, yep | 16:28 |
| rockstar | jelmer, before you wrote your own svn bindings, what python library were you using? | 16:29 |
| visik7 | LarstiQ: I've opened a bug https://bugs.launchpad.net/bzr-svn/+bug/270950 | 16:30 |
| ubottu | Launchpad bug 270950 in bzr-svn "ImportError: cannot import name client " [Undecided,New] | 16:30 |
| jelmer | rockstar, python-subversion (provided with subversion itself) | 16:31 |
| jelmer | visik7: Please try running "import client" in a python interpreter | 16:31 |
| * awilkins testifies that the hand-crafted ones are much better than the standard issue | 16:31 | |
| jelmer | visik7, while in ~/.bazaar/plugins/svn | 16:31 |
| visik7 | it works | 16:32 |
| visik7 | no import exceptions | 16:32 |
| LarstiQ | jelmer: have you looked at the new python-subversion bindings? | 16:32 |
| LarstiQ | jelmer: ie the ones that didn't get included in svn 1.5 | 16:32 |
| jelmer | visik7, what about "from bzrlib.plugins.svn import client" ? | 16:33 |
| jelmer | LarstiQ, I helped write those :-) | 16:33 |
| jelmer | LarstiQ, Or do you mean others than the SWIG-based ones? | 16:33 |
| visik7 | jelmer: ImportError: No module named bzrlib.plugins.svn | 16:34 |
| jelmer | visik7, and after "from bzrlib.plugin import load_plugins; load_plugins()" ? | 16:35 |
| visik7 | jelmer: anywhere or in a specific path ? | 16:35 |
| jelmer | visik7, anywhere | 16:35 |
| visik7 | no module, but wait I've no bzrlib system wide installed, (but some versions ago it worked smoothly) | 16:36 |
| LarstiQ | jelmer: other than the SWIG-based ones, afaik | 16:37 |
| LarstiQ | jelmer: a Dutch hg dev told me their current svn effort is going smoothly based on those newer bindings | 16:37 |
| visik7 | jelmer: python -c "from bzrlib.plugin import load_plugins; load_plugins()" | 16:37 |
| visik7 | No handlers could be found for logger "bzr" | 16:37 |
| === kiko is now known as kiko-phone | ||
| jelmer | LarstiQ, there's nothing upstream yet | 16:38 |
| jelmer | LarstiQ, perhaps in a separate branch | 16:38 |
| LarstiQ | jelmer: hmmm | 16:39 |
| visik7 | any clue jelmer ? | 16:41 |
| jelmer | visik7, what version of bzr-svn? | 16:42 |
| visik7 | jelmer: trunk | 16:42 |
| jelmer | visik7, no, sorry | 16:44 |
| visik7 | nevermind I'll wait | 16:44 |
| === menesis1 is now known as menesis | ||
| === kiko-phone is now known as kiko-afk | ||
| ajaksu | jelmer: http://paste.pocoo.org/show/85427/ | 17:03 |
| jelmer | ajaksu, please file a bug about that | 17:04 |
| jelmer | ajaksu, you should be able to use svn+https://ajaksu:sa6fQ8MY2cP8@ccoverage.googlecode.com/svn/trunk/ for now as workaround | 17:04 |
| LarstiQ | ajaksu: could you try without pycurl? | 17:04 |
| ajaksu | damn it, i didn't erase my temp pass :D | 17:04 |
| LarstiQ | jelmer: would https+urllib:// get to svn as well? | 17:05 |
| jelmer | LarstiQ, nope, that will try just urllib, nothing else | 17:05 |
| jelmer | I think | 17:05 |
| LarstiQ | ok | 17:05 |
| LarstiQ | jelmer: the rewind thing is something some people ran into yesterday too, without svn too | 17:06 |
| LarstiQ | though | 17:06 |
| LarstiQ | bug 241689 or so? | 17:06 |
| ubottu | Launchpad bug 241689 in awn "awm blocks mouseaccess to windows/trays beside and directly above it" [Undecided,New] https://launchpad.net/bugs/241689 | 17:06 |
| LarstiQ | hmm no :) | 17:06 |
| * LarstiQ goes home | 17:06 | |
| ajaksu | how do I explicit a base in a merge command? | 17:12 |
| jelmer | ajaksu, bzr merge -rBASE..OTHER | 17:20 |
| ajaksu | jelmer: wrong question, then... I'm trying to push my bzr branch to svn and it says 'branches have no common ancestor and no merge base revision was specified', but with your suggestions it tries to merge 2 svn revisions instead :/ | 17:24 |
| jelmer | ajaksu, the location you're pushing to can't exist in svn yet if the two branches have no common ancestry | 17:25 |
| ajaksu | should I 'svn commit' a copy of bzr rev 1 there? | 17:26 |
| jelmer | ajaksu, no, you need to remove the branch you'd like to push to before running "bzr svn-push" | 17:26 |
| ajaksu | added a subdir to /trunk and it seems to be thinking... IT WORKS! Thank you, thank you very much jelmer! :) | 17:29 |
| ajaksu | sweet, great, thanks! :) | 17:30 |
| imyojimbo | hi... i am reading bzr manual, and i just have to say im really enjoying it. bzr is a great tool. | 17:46 |
| imyojimbo | great jon guys | 17:47 |
| imyojimbo | *job | 17:47 |
| jelmer | imyojimbo, thanks! | 17:52 |
| jfroy|work | Hello! Is this the right place to ask about bzr-svn? | 19:09 |
| LarstiQ | jfroy|work: sure | 19:09 |
| jfroy|work | I was just wondering if there was a way to improve or cache http authentication credentials to avoid having to type a password a large number of times. I'm on Mac OS X, and so I would have expected the system keychain to be used. | 19:10 |
| LarstiQ | jfroy|work: there are other places you could try depending on what you're looking for (say, bugreports), but bzr-svn is on topic here :) | 19:10 |
| LarstiQ | jfroy|work: I believe that is more of a core bzr issue | 19:11 |
| jfroy|work | I had a look around, and it seems to be a svn python binding issue, since bzr-svn seems to be importing a binary module of svn authentication methods. | 19:11 |
| LarstiQ | ah, what version of bzr-svn are you using? | 19:12 |
| jfroy|work | 0.4.12 on bzr 1.6.1 | 19:12 |
| jfroy|work | Using the system's interpreter | 19:12 |
| LarstiQ | jfroy|work: hmm, I was under the impression that version didn't use the python-subversion bindings | 19:12 |
| LarstiQ | jfroy|work: to be clear we're speaking about the same thing, does it ask you for credentials a great number of times _per operation_? | 19:13 |
| LarstiQ | Say, doing a bzr branch and having to enter it once per revision. | 19:13 |
| jfroy|work | a checkout or commit asks me for my credentials 3 times | 19:14 |
| LarstiQ | jfroy|work: or do you mean you'd like to cache it across invocations of bzr? | 19:14 |
| LarstiQ | jelmer: still around? | 19:14 |
| jfroy|work | Correct, across invocations. That is, I'd like it to never ask me for credentials. | 19:14 |
| LarstiQ | jfroy|work: ok, that's not a bzr-svn specific issue then. | 19:14 |
| LarstiQ | jfroy|work: I believe vila has done some work on that, but I don't think it was with the OS X keychain, although he does use OS X. | 19:15 |
| jfroy|work | Subversion has stored them in my account's keychain, and uses that information when invoked directly. | 19:15 |
| LarstiQ | jfroy|work: right, I see. | 19:15 |
| LarstiQ | jfroy|work: so if bzr had support for Keychain, you'd be happy? | 19:15 |
| jfroy|work | The weird thing is line 156 of the auth module in the bzr-svn plugin: | 19:16 |
| jfroy|work | if getattr(ra, 'get_keychain_simple_provider', None): | 19:16 |
| jfroy|work | providers.append(ra.get_keychain_simple_provider()) | 19:16 |
| jfroy|work | Seems to be it should be working, but isn't | 19:16 |
| jfroy|work | It would definitely be useful for deploying bzr around some more :) | 19:16 |
| LarstiQ | jfroy|work: agreed :) | 19:16 |
| jfroy|work | Sharing repositories with bzr is usually done through SSH, so SSH keypairs work fine, but svn is quite often shared over http[s] | 19:17 |
| * LarstiQ nods | 19:17 | |
| LarstiQ | jfroy|work: I don't know the bzr-svn code in that detail, and jelmer doesn't seem to be around | 19:17 |
| jfroy|work | I'm just not clear on who provides credentials to bzr-svn: bzr or the svn libraries (invoked by bzr-svn). | 19:17 |
| jfroy|work | I'll troll around until he shows up :p | 19:18 |
| LarstiQ | jfroy|work: afaik, unless maybe you're interacting with an svn checkout, it would be bzr. | 19:18 |
| LarstiQ | heh :) | 19:18 |
| LarstiQ | jfroy|work: you could also aks a question on https://answers.edge.launchpad.net/bzr-svn, or file a bug, depending on the level of certainty you have about things supposed to be working and not doing so. | 19:19 |
| jfroy|work | I'll probably take the time to dig into this next weekend. It itches :p | 19:19 |
| LarstiQ | jfroy|work: for bzr and Keychain, I'm not sure what the right approach is there nowadays | 19:19 |
| LarstiQ | jfroy|work: cool :) | 19:19 |
| jfroy|work | Ah, well for that, a plugin might do the trick, if plugins can pipe into the authentication mechanism. I honestly don't think there's a need for it. | 19:20 |
| jfroy|work | ssh-agent on OS X stores key credentials in the keychain already :p | 19:20 |
| LarstiQ | jfroy|work: plugins can do almost anything | 19:20 |
| LarstiQ | jfroy|work: fair enough :) | 19:20 |
| jfroy|work | and http is only ever used for read-only public branches, as far as I know | 19:21 |
| jfroy|work | At least in my experience | 19:21 |
| LarstiQ | well, I wouldn't mind having more of that infrastructure for dealing with svn branches as well | 19:22 |
| LarstiQ | jfroy|work: heh, https://bugs.edge.launchpad.net/bzr/+bug/260919 | 19:22 |
| ubottu | Launchpad bug 260919 in bzr "Ability to register new auth providers" [Wishlist,Confirmed] | 19:22 |
| jfroy|work | Such a cute bot :) | 19:23 |
| LarstiQ | vila: could others help you with .netrc? | 19:23 |
| LarstiQ | jfroy|work: I'm going off to have some dinner | 19:25 |
| === ajaksu is now known as ajaksu_away | ||
| === bac is now known as bac_afk | ||
| === kiko-afk is now known as kiko | ||
| vila | LarstiQ: sure, patches welcome :D | 20:29 |
| vila | I always saw .netrc as a first simple step before addressing gnome-keyring or OS X key chain | 20:30 |
| bpierre | hi | 20:38 |
| bpierre | what is the state of subtrees support in bazaar? | 20:39 |
| beuno | bpierre, LarstiQ is the last person to work on it | 20:39 |
| beuno | we may trick him into working on it again | 20:39 |
| beuno | but he's getting smarter | 20:39 |
| bpierre | :P | 20:39 |
| abadger1999 | Quick shared repository question: | 20:40 |
| bpierre | beuno: subtrees need a specific repository format, right? | 20:40 |
| abadger1999 | Is there any drawback to putting a shared repository at the toplevel of multiple (possibly many) unrelated branches? | 20:40 |
| beuno | bpierre, I don't recall the implementation details. I'm not sure they do | 20:41 |
| beuno | abadger1999, maybe performance, but I think it's not too bad | 20:41 |
| === bac_afk is now known as bac | ||
| bpierre | help formats lists development-subtree and 1.6.1-rich-root | 20:41 |
| beuno | huh, look at that | 20:42 |
| beuno | you could wait for LarstiQ to finish his dinner | 20:42 |
| abadger1999 | beuno: Thanks! I'm writing a plugin for a project that checks out source for many different projects to submit translations. | 20:42 |
| beuno | or send a mail to the list | 20:42 |
| bpierre | the docs on the site are not really up to date, but I got the impression that rich-root was a prerequisite for subtrees... | 20:42 |
| abadger1999 | Just trying to decide if shared repo @ toplevel or shared repo @ project level makes more sense. | 20:43 |
| beuno | ah, I see | 20:43 |
| beuno | I'd go for a per-project | 20:43 |
| beuno | where they're more likely to share revisions | 20:43 |
| abadger1999 | <nod> | 20:46 |
| abadger1999 | Thanks again! | 20:46 |
| beuno | welcome' | 20:46 |
| LarstiQ | bpierre: yes | 20:48 |
| LarstiQ | vila: anything in specific? | 20:48 |
| bpierre | LarstiQ: ok, so is it somewhat working? can I switch to 1.6.1-rich-root to do some tests? | 20:49 |
| LarstiQ | bpierre: if you want you can try out https://code.launchpad.net/~larstiq/bzr/nested-trees | 20:51 |
| LarstiQ | bpierre: I haven't touched it in a while, but the basics should work | 20:51 |
| LarstiQ | bpierre: how interested are you in this? | 20:51 |
| LarstiQ | bpierre: I wouldn't mind some people reporting results :) | 20:52 |
| bpierre | well, I'm evaluating bazaar and subversion for work | 20:52 |
| bpierre | as our new VCS | 20:52 |
| LarstiQ | ok | 20:52 |
| bpierre | we use clearcase now | 20:52 |
| bpierre | with UCM | 20:53 |
| * LarstiQ has no clearcase experience | 20:53 | |
| bpierre | and there are 2 uses cases | 20:53 |
| bpierre | well, clearcase has support for components | 20:53 |
| LarstiQ | bpierre: go on :) | 20:54 |
| bpierre | ok, so you can have different part of the tree, like a component for the driver | 20:55 |
| bpierre | one for the applications/ui | 20:55 |
| bpierre | one for the engine | 20:55 |
| bpierre | and then, what you can do when you create a new project, is seed it with components from different projects | 20:56 |
| bpierre | so you take the drivers for one platform, the apps for another product | 20:56 |
| LarstiQ | ok. Do further commits then get fed back to the originating project? | 20:56 |
| === mw is now known as mw|food | ||
| bpierre | yes, or just keep doing your own thing, with the ability to rebase to get changes from upstream | 20:57 |
| bpierre | that's one use case | 20:57 |
| bpierre | the other I'm concerned, is vendor branches | 20:57 |
| bpierre | LarstiQ: still here? | 21:02 |
| timeless | hello | 21:04 |
| timeless | i'm a clueless and very frustrated something | 21:05 |
| timeless | imagine i have a directory x/ with x/.bzr/branch/branch.conf with bound_location = something and bound = True | 21:05 |
| timeless | but there are no files or directories in x/ other than .bzr/ | 21:05 |
| LarstiQ | bpierre: yes, real life intervened for a moment | 21:05 |
| timeless | how do i get bzr to put all the files back that are managed by bzr? | 21:05 |
| timeless | something like a cvs up or hg up or svn up | 21:06 |
| jam | timeless: bzr co | 21:06 |
| LarstiQ | timeless: there is a bzr up, but your situation sounds like bzr co | 21:06 |
| timeless | [timeless@konigsberg bugzilla]$ bzr checkout | 21:06 |
| timeless | bzr: ERROR: File exists: u'/data/mxr-data/bugzillamozilla-bzr/bugzilla/.bzr': [Errno 17] File exists: '/data/mxr-data/bugzillamozilla-bzr/bugzilla/.bzr' | 21:06 |
| timeless | next? | 21:06 |
| jam | timeless: what does "bzr status" give? | 21:07 |
| timeless | (yes, i already tried both bzr co and bzr checkout, and a couple of others) | 21:07 |
| jam | and what --version? | 21:07 |
| timeless | Bazaar (bzr) 1.6.1 | 21:07 |
| timeless | status gives me lots of stuff | 21:07 |
| LarstiQ | bpierre: how do you use components with vendor branches? | 21:07 |
| timeless | it says that all the files are removed | 21:07 |
| timeless | and that there are Text and Contents conflicts for most of the files | 21:08 |
| timeless | and there are "pending merges" | 21:08 |
| timeless | and i have a headache | 21:08 |
| LarstiQ | bpierre: the classic cvs vendor branches you'd just do with branches in bzr. | 21:08 |
| bpierre | ? | 21:08 |
| LarstiQ | timeless: bzr revert perhaps? | 21:08 |
| jam | timeless: bzr revert | 21:08 |
| timeless | thanks | 21:08 |
| LarstiQ | bpierre: ah hmm, you meant a usecase for bzr nested trees? | 21:09 |
| bpierre | maybe I'm not using the right terminology: you have a thirparty provided driver, libraries and/or sources and header | 21:09 |
| LarstiQ | bpierre: right | 21:09 |
| bpierre | you want to be able to integrate it in the tree | 21:09 |
| timeless | so... my goal is to have a box which makes 0 changes to the contents which it gets from an 'upstream' | 21:09 |
| LarstiQ | aah, ok | 21:09 |
| bpierre | fix, change some things | 21:09 |
| bpierre | and still track the original vendor versions | 21:09 |
| timeless | all i want to do is update periodically and have exactly what would be tip on the upstream bzr | 21:09 |
| LarstiQ | bpierre: yeah, the fixing or changing some things aren't special, your wanting to integrate it in the tree is where subtrees could come in. | 21:10 |
| bpierre | to do a tree way merge when you get a new version | 21:10 |
| bpierre | yeah | 21:10 |
| timeless | i'm using bzr update to do that | 21:10 |
| timeless | should that work? | 21:10 |
| bpierre | I guess once you can do that, you can mimic clearcase components | 21:10 |
| LarstiQ | timeless: yes | 21:10 |
| timeless | larstiq: ok. so it clearly didn't :) | 21:11 |
| LarstiQ | timeless: although in that case a checkout doesn't give you any benefits over a normal branch | 21:11 |
| timeless | larstiq: i want something simple | 21:11 |
| timeless | "set it and forget it" | 21:11 |
| LarstiQ | timeless: 'bzr get upstream; bzr pull; bzr pull; etc' | 21:11 |
| bpierre | except, once thing clearcase does, is when you make a baseline, which is like a tag, you both get a global tag, for the whole project, and one for each component | 21:12 |
| LarstiQ | timeless: as long as you make no changes to the tree, that will do it just fine. If you do make changes, you might need to throw in a `bzr revert` from time to time. | 21:12 |
| bpierre | which then can be used by another project to update/merge only some components to/with your version | 21:13 |
| gar1t | I have a workflow related question, which comes out of my use of git (am giving bzr a try) | 21:13 |
| gar1t | I tend to use git for (among other things) creating local branches to organize my work in chunks that can be applied as single commits to the trunk/mainline. This is a common enough pattern. | 21:14 |
| LarstiQ | bpierre: that's basically tagging each component with the same tag in one go? | 21:14 |
| LarstiQ | gar1t: right | 21:14 |
| gar1t | I'm scratching my head though with bzr. It looks like bzr wants to create new directories for every branch. I need/want to keep everything in a single working directory. | 21:14 |
| gar1t | So, the workflow would look like this... | 21:15 |
| nDuff | gar1t, why don't you keep your working directory and repo directory separate? | 21:15 |
| nDuff | gar1t, that way your repo gets new subdirectories as you start new branches, but the working tree just switches between them. | 21:15 |
| LarstiQ | gar1t: branches live in their own directories, but you can switch your working tree between them with `bzr switch` | 21:15 |
| gar1t | the repo is a shared repo on a server | 21:16 |
| bpierre | LarstiQ: yeah | 21:16 |
| LarstiQ | gar1t: and if you use a shared repository without trees `bzr init-repo --no-trees`, the branches won't have working trees themselves. | 21:16 |
| gar1t | I want to create "throw away" branches locally and use them for merges. | 21:16 |
| gar1t | I created the shared repo (on the server) with the --no-trees option. | 21:17 |
| LarstiQ | gar1t: but you don't have a shared repo locally, yet? | 21:17 |
| gar1t | hmmm...not sure | 21:17 |
| gar1t | I create a repo locally using bzr branch URL | 21:17 |
| gar1t | did I miss a local init-repo along the way? | 21:18 |
| LarstiQ | gar1t: `bzr branch/get` primarily creates a branch, not a repository | 21:18 |
| nDuff | gar1t, if you want more than one local branch at a time, it's probably not a bad idea to have a local repo to keep them in. | 21:18 |
| timeless | ok, thanks. i've switched to pull... i'll be back when that breaks :) | 21:19 |
| gar1t | so init-repo first and then branch into that? | 21:19 |
| nDuff | gar1t, ...presuming that just having multiple separately-checked-out working trees doesn't work for you. | 21:19 |
| LarstiQ | gar1t: yup | 21:19 |
| nDuff | gar1t, *nod*; that way you get the storage efficiency of shared repos. | 21:19 |
| gar1t | yeah -- I'm trying to make branches as incredibly cheap as possible -- creating new directories doesn't really work for this workflow | 21:20 |
| strk | use case: regression found, need to figure when introduced | 21:20 |
| strk | $ bzr revno; bzr revert -r -10; bzr revno # revno always returns same revision... is there a better practice ? | 21:21 |
| LarstiQ | gar1t: see 5.5.3 at http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reusing-a-checkout | 21:21 |
| LarstiQ | gar1t: ok, you really want a --no-trees for that init-repo then :) | 21:22 |
| LarstiQ | strk: bzr bisect, see http://bazaar-vcs.org/BzrPlugins | 21:22 |
| gar1t | LarstiQ: yeah, looked at that for some time today :) | 21:22 |
| strk | LarstiQ: sound interesting, but that page points to no code | 21:23 |
| strk | http://bzr.licquia.org/bzr-bisect/ <--- empty dir | 21:23 |
| LarstiQ | gar1t: so a fundamental difference between git and bzr is that in bzr branches are directly addressable (by url) | 21:23 |
| LarstiQ | strk: bzr branch http://bzr.licquia.org/bzr-bisect/ :) | 21:23 |
| strk | ah | 21:23 |
| LarstiQ | strk: I don't know if that is the most recent version, I haven't followed it, but I've used it in the past | 21:24 |
| strk | bzr branch http://bzr.licquia.org/bzr-bisect/trunk | 21:24 |
| gar1t | LarstiQ: use the --no-trees on the local repo as well? | 21:24 |
| LarstiQ | gar1t: yup | 21:24 |
| LarstiQ | gar1t: that does mean that you'll have seperate directories for each branch, but you don't have to have a working tree for each | 21:24 |
| strk | no readme.. | 21:25 |
| strk | how to install ? | 21:25 |
| LarstiQ | strk: it should be installed as a plugin | 21:25 |
| strk | there's meta.py, setup.py and tests.py | 21:25 |
| LarstiQ | strk: so, have it end up as ~/.bazaar/plugins/bisect/ | 21:25 |
| strk | and __init__.py | 21:25 |
| LarstiQ | strk: then, you have `bzr help bisect` | 21:25 |
| strk | ah, the whole dir ? | 21:25 |
| LarstiQ | strk: yes | 21:25 |
| strk | thanks | 21:26 |
| LarstiQ | gar1t: the documentation mentions 'bzr switch path/to/branch', but iirc 'bzr switch <foo>' where foo is a sibling of the current branch you're bound to also works | 21:26 |
| LarstiQ | gar1t: so that would become 'bzr switch X-1.0' instead of 'bzr switch ../X-1.0' | 21:26 |
| bpierre | mmm, on the subject on bisect, you can't really change the revision of you working tree right? like go back? I used bisect and I was under the impression it was doing the equivalent of `revert -r rev` | 21:27 |
| bpierre | so if you do a status, you seed the diff between rev and the head of the branch, right? | 21:27 |
| fullermd | bpierre: Yes. And revert's a straight blat, it won't do any change merging like an update -r should. | 21:28 |
| strk | is there a way to know what revno you end up with after a revert ? (or bisect, which I guess uses revert underneat) | 21:29 |
| bpierre | ok | 21:30 |
| bpierre | that's something I kinda liked with monotone | 21:30 |
| LarstiQ | strk: revert changes the filecontents to the revision you specified. | 21:30 |
| LarstiQ | strk: bisect has a bit more of documentation | 21:31 |
| LarstiQ | strk: you set a begin and start revision, and then it does a binary bisect between those | 21:31 |
| LarstiQ | strk: and depending on your answers, it chooses which branch to continue in | 21:31 |
| awilkins | bisect rocks, even when it discovers that I caused the bug ;-) | 21:31 |
| LarstiQ | Odd_Bloke: what happened to your bisect changes? | 21:31 |
| Odd_Bloke | LarstiQ: I expect they're on LP. | 21:32 |
| === BasicPRO is now known as BasicOSX | ||
| fullermd | bpierre: Well, as bug 45719 says, it's something to kinda like about... well, everything but bzr :p | 21:32 |
| ubottu | Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress] https://launchpad.net/bugs/45719 | 21:32 |
| Odd_Bloke | I think it got awkward enough to polish them off that I kind of tailed off. | 21:32 |
| bpierre | ok | 21:32 |
| LarstiQ | Odd_Bloke: aaah :) | 21:32 |
| * LarstiQ badges Odd_Bloke to pick it up again | 21:32 | |
| * fullermd pets ubottu. | 21:33 | |
| LarstiQ | bpierre: config-manager is an older solution to the nested-trees problem | 21:33 |
| bpierre | what does it do? | 21:34 |
| strk | I'm not sure I understand how bisect works. I know head has the bug (revno 9760) and I manually tested revno 9600 doesn't have the bug | 21:34 |
| strk | how do I proceed ? | 21:34 |
| bpierre | again, not a lot of documentation! | 21:34 |
| strk | (9760) bzr bisect start | 21:35 |
| strk | bzr bisect no -r 9600 ? | 21:35 |
| LarstiQ | bpierre: maintain configs for checking out multiple trees | 21:35 |
| bpierre | ok | 21:35 |
| LarstiQ | bpierre: for the nested-trees branch on launchpad, it's basically: 'bzr branch other/branch subtree; bzr add subtree; bzr ci' | 21:36 |
| bpierre | ok, so you can commit transparently across trees? | 21:37 |
| LarstiQ | bpierre: that's the idea, yes | 21:37 |
| bpierre | what happen if another project include a derived tree? can you cherry pick? | 21:37 |
| LarstiQ | bpierre: there are still some buggy corner cases if you `bzr mv` across subtree boundaries | 21:37 |
| bpierre | can you push only a subtree? | 21:37 |
| LarstiQ | bpierre: yes | 21:38 |
| bpierre | ok | 21:38 |
| LarstiQ | bpierre: if you do a commit in the containing tree, it will recurse into subtrees, do it's stuff there, and then record the subtree state in the containing tree | 21:38 |
| LarstiQ | bpierre: so the contained ones can still be worked upon by themselves | 21:39 |
| LarstiQ | unless my brain is very rusty | 21:39 |
| bpierre | so, I can have a repository r1 with a branch, say my main vendor branch, include it in my tree (and repository) push only the subtree to another branch in r1 for other project to cherry pick/merge? | 21:39 |
| LarstiQ | bpierre: so, this code is rather old, I _think_ the basics work, but you might run into some rough patches. Would you be willing to try it out and work with me getting it fixed up? | 21:39 |
| bpierre | sure, I was in the process of setting up a small test project | 21:40 |
| LarstiQ | bpierre: I think we might have different terminology on cherry picking | 21:40 |
| bpierre | :P | 21:40 |
| bpierre | merge only a particular revision? | 21:40 |
| LarstiQ | bpierre: if you mean, can I get just the changes in the subtree in my other project, then yes | 21:40 |
| bpierre | not a full blown merge | 21:41 |
| LarstiQ | bpierre: subtrees are their own seperate branches | 21:41 |
| bpierre | ok | 21:41 |
| bpierre | and tags are dupplicated too? | 21:41 |
| LarstiQ | bpierre: so there are no non-subtree revisions in the subtree you'd want to not-merge | 21:41 |
| LarstiQ | bpierre: now tags is a good question | 21:41 |
| LarstiQ | bpierre: I'd assume so, but I'd have to check | 21:42 |
| bpierre | ok | 21:42 |
| bpierre | I'm in France, going to go to bed, but if you want me to do some tests tomorrow evening, I'm available | 21:43 |
| LarstiQ | bpierre: cool, I'm in The Netherlands | 21:43 |
| LarstiQ | bpierre: I'll be busy training most of the evening probably, but we'll see | 21:44 |
| LarstiQ | bpierre: my client is always here, and I respond to backlog | 21:44 |
| bpierre | same goes if someone want to check a possible fix for https://bugs.launchpad.net/bugs/269456 :D | 21:44 |
| ubottu | Launchpad bug 269456 in bzr "checkout operation consume too much resources" [High,Triaged] | 21:44 |
| bpierre | hehe | 21:44 |
| bpierre | ok, won't be at home this week-end, but other than that, happy to do some testing on the week-end | 21:45 |
| LarstiQ | bpierre: sweet | 21:45 |
| gar1t | LarstiQ: after some navel staring, I think I understand | 21:45 |
| LarstiQ | bpierre: that also gives me a bit more time to get back into the code ;) | 21:45 |
| bpierre | ok | 21:46 |
| bpierre | bye | 21:46 |
| * LarstiQ looks up what navel staring means | 21:48 | |
| gar1t | LarstiQ: when pushing back to the central server -- is it better (for whatever reason) to push from the local repo, or can I push from the local working branch? | 21:48 |
| LarstiQ | gar1t: ah :) | 21:48 |
| gar1t | LarstiQ: lol, not sure if wikipedia covers that one ;) | 21:48 |
| * LarstiQ found an article under 'wisegeek.com' fwiw | 21:49 | |
| LarstiQ | gar1t: I don't use that workflow myself, but afaik if you have your push location set in your branch, doing a push from your working tree will use that location and do the right thing | 21:50 |
| gar1t | that's a very good explanation | 21:50 |
| LarstiQ | it certainly would be the behaviour I expect. | 21:50 |
| gar1t | LarstiQ: seems to work fine either way | 21:53 |
| gar1t | thanks for the explanation -- that cleared up some things for me | 21:53 |
| LarstiQ | gar1t: glad to be of help | 21:53 |
| Odd_Bloke | https://code.launchpad.net/~daniel-thewatkins/bzr-bisect/automated is my bisect work. | 22:10 |
| Odd_Bloke | Testing and bug reports would be appreciated. | 22:10 |
| LarstiQ | ok | 22:16 |
| * LarstiQ adds it to his todo list for tomorrow | 22:16 | |
| johan | is it possible to run a shell script as a post_commit hook for a bzr branch? | 22:18 |
| gar1t | dir | 22:20 |
| gar1t | sry - wrong window :( | 22:20 |
| === thumper_laptop is now known as thumper | ||
| lifeless | johan: yes, via jelmers shell-script-hooks plugin, or via a python plugin that looks for a shell script and runs it | 22:24 |
| johan | lifeless: okay, so no upstream support atm. Is that planned for the future? | 22:25 |
| lifeless | johan: for some value of planned | 22:25 |
| johan | lifeless: it would make sense, since not all users of bzr knows how to program python | 22:25 |
| lifeless | we had a long debate; I'm happy with us supporting them as long as their presence does not reduce the clarity of interface of the python hooks | 22:26 |
| lifeless | or try to make things equal, when obviously shell scripts are going to be slower and more limited because they can't access already present objects | 22:26 |
| lifeless | johan: well, not all users of bzr know how to program shell either | 22:27 |
| lifeless | johan: for instance, on windows, vbscript is probably a better common language | 22:27 |
| lifeless | anyhow, as I say: there is [at least] one plugin that enables this, I don't think it needs to be in core to be considered available | 22:28 |
| lifeless | johan: is there a particular reason you want this? | 22:30 |
| === mw|food is now known as mw | ||
| imyojimbo | hi, say, what kind off diff tool do you use? | 22:34 |
| cody-somerville | imyojimbo, I use diff myself | 22:42 |
| lifeless | imyojimbo: I don't use an external tool | 22:43 |
| lifeless | imyojimbo: some folk like meld | 22:43 |
| lifeless | imyojimbo: some folk on windows use commercial tools, I don't remember the name, but bzr can be configured to call out to them | 22:43 |
| lifeless | garh I hate wiki advertising | 23:02 |
| lifeless | http://nouveau.freedesktop.org/wiki/OProfile | 23:02 |
| lifeless | note the reason it turns up on google under 'oprofile python' | 23:02 |
| Kittens | lifeless, adblock plus :) | 23:03 |
| * Verterok wonders if he found a bug or a feature | 23:03 | |
| lifeless | Kittens: how would that help ? | 23:03 |
| Kittens | lifeless, get rid of the wiki ads | 23:04 |
| Kittens | :p | 23:04 |
| lifeless | Kittens: I'm going to guess you are assuming a bunch of things by what I meant and haven't looked at the wiki page in question at all. | 23:04 |
| Verterok | while committing a merge, if all touched files are specified to commit it's rejected | 23:04 |
| Kittens | fine fine if i must click | 23:04 |
| lifeless | Kittens: if you *are* assuming, please don't :> | 23:04 |
| Verterok | it's that behaviour ok? | 23:04 |
| Kittens | lifeless, i assume a lot :p | 23:05 |
| Kittens | sorry | 23:05 |
| lifeless | Verterok: committed a merge, no parameters should be passed | 23:05 |
| Kittens | it's one of my "features" | 23:05 |
| lifeless | Verterok: sorry, I mean, 'committing' and 'no sub paths' | 23:05 |
| lifeless | Kittens: np | 23:05 |
| beuno | lifeless, but does it make sense to reject a commit if all changed files in the merge are being specified? | 23:06 |
| Verterok | lifeless: thanks, but if I pass all the "changed/touched" files as prameters? | 23:06 |
| beuno | hiya poolie | 23:06 |
| poolie | hello beuno | 23:06 |
| poolie | hello jam | 23:06 |
| lifeless | Verterok: beuno: its a performance question. Can we tell there are no other altered or merged files without making commit slower by doing so. | 23:06 |
| lifeless | currently, the answer is 'no'. I'm not sure that in theory it can be made 'yes'. | 23:07 |
| beuno | so it's a performance tradeoff? | 23:07 |
| === Pieter_ is now known as Pieter | ||
| Verterok | lifeless: thanks for the explanation | 23:07 |
| lifeless | anyhow, I think the real bug is that we haven't implemented the necessary graph sophistication to support cherrypicks in all their beauty - partial graph references including references to partial merges | 23:08 |
| * Verterok starts fixing bzr-eclipse commit when a merge is pending :( | 23:08 | |
| lifeless | in a philosophical sense, 'all modified from the merge' could be a set larger than that shown by 'diff' or 'status' due to per file graph joining | 23:08 |
| * beuno blinks | 23:09 | |
| * Verterok too | 23:09 | |
| beuno | aha | 23:09 |
| lifeless | so while I can agree in principle 'if all the changed files are specified', I don't think eclipse would actually be listing 'all the changed files', and once we do proper cherrypick merge support, I'm quite positive it wouldn't do what you want it too | 23:09 |
| Verterok | lifeless: the particular problem I'm having in bzr-eclipse, is that when the commit dialog is opened, it shows all the modified files (in a table with checkbox) | 23:11 |
| Verterok | by default, bzr-eclipse use the selected files in the commit command | 23:11 |
| Verterok | so, I need to check if there is a pending merge, and don't allow the user to select/unselect the files, and also avoid using the file list in the commit | 23:13 |
| lifeless | Verterok: yes, I think that makes sense | 23:15 |
| Verterok | it's just that I missed this restriction while committing a merge | 23:15 |
| lifeless | Verterok: and/also I suggest that if everything is selected, you don't pass in a file list anyhow, its simpler | 23:16 |
| Verterok | lifeless: sure, that makes sense :) | 23:16 |
| lifeless | looking further | 23:17 |
| lifeless | I think it would be nice to allow commits to be edited after-creation before completion. [handwaving] build the full commit and inventory and have an object listing all the items changed, with a method to exclude an item. So call that, it removes it from the commit and puts it back to the parent (not doable in merge commits for now) | 23:18 |
| lifeless | you could receive this object over the xmlrpc service | 23:19 |
| lifeless | and edit it in the window live | 23:19 |
| lifeless | then when you supply the commit message, the final inventory is written, the revision added and its done | 23:19 |
| === andreas__ is now known as ahasenack | ||
| lifeless | Verterok: ^ | 23:22 |
| * Verterok blinks | 23:23 | |
| Verterok | lifeless: I need think about this a bit :) | 23:25 |
| Verterok | (actually understand it :p ) | 23:25 |
| lifeless | Verterok: sure :P | 23:27 |
| Verterok | lifeless: that's a nice idea. | 23:40 |
| Verterok | lifeless: currently the xmlrpc service don't allow this kind of interaction between client-server | 23:41 |
| Verterok | but it's a nice feature to add :) | 23:41 |
| beuno | mwhudson, amanica has a few questions with your name written all over them | 23:43 |
| beuno | "integrating loggerhead into gforge" | 23:44 |
| beuno | "...and why paths suck" | 23:44 |
| mwhudson | beuno: oh? | 23:47 |
| mwhudson | amanica: i'm here now | 23:47 |
| amanica | hi | 23:48 |
| amanica | I'm writing a plugin to gforge which uses loggerhead to browse the branches | 23:48 |
| amanica | but at one place I can obtain the path to a file which includes the branch, repo or other dirs | 23:49 |
| amanica | so I have two ideas: | 23:49 |
| amanica | 1) in stead of http://127.0.0.1:8080/bzr.repo/bzr.dev/annotate/head:/tools/biobench.py -> http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py | 23:49 |
| amanica | 2) in stead of http://127.0.0.1:8080/bzr.repo/bzr.dev/annotate/head:/tools/biobench.py -> http://127.0.0.1:8080?annotate=/bzr.repo/bzr.dev/tools/biobench.py | 23:49 |
| amanica | i.e. in gforge I dont know how to split the path into a branch part and a reletive to branch part | 23:50 |
| mwhudson | amanica: you don't want to have the head: in there? | 23:50 |
| amanica | I dont mind the head part so long as it is not in the middle of the url | 23:51 |
| mwhudson | right | 23:51 |
| mwhudson | i don't know a good answer to this, really | 23:51 |
| amanica | I dont mind hacking on this, but I dont want to go into my own little fork | 23:52 |
| mwhudson | in some ways, i'd be fine with http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py being the annotate view | 23:52 |
| mwhudson | but then how do you get to the changes view? | 23:52 |
| mwhudson | you could do | 23:52 |
| mwhudson | in some ways, i'd be fine with http://127.0.0.1:8080/bzr.repo/bzr.dev/+changes | 23:52 |
| amanica | or http://127.0.0.1:8080/bzr.repo/bzr.dev?changes | 23:52 |
| mwhudson | and then hope noone calls a file '+changes' .... | 23:52 |
| mwhudson | i think using query args for this is kinda gross | 23:53 |
| mwhudson | but it would work, i guess | 23:53 |
| amanica | gross, why? | 23:53 |
| mwhudson | well, i guess because it's a fundamentally different resource | 23:53 |
| * Odd_Bloke thinks /+changes is nicer that ?changes. | 23:54 | |
| amanica | or maybe just a different view to the same resource | 23:54 |
| amanica | I think using query args will be a lot cleaner | 23:55 |
| mwhudson | the thing is, in bazaar the branches are the most important thing | 23:55 |
| mwhudson | then the revisions | 23:55 |
| mwhudson | then the content of the revisions | 23:55 |
| mwhudson | (at least imho) | 23:55 |
| amanica | and we dont have to worry about accedental conflicts | 23:56 |
| amanica | as I said, 2) may be an acceptable workaround with the least impact (I think) | 23:58 |
| mwhudson | it still offends my sense of style, i'm afraid | 23:59 |
| amanica | I still think it will be cool to go staight to http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py and the file contents pop up | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!