| lifeless | I'd say | 00:00 |
|---|---|---|
| amanica | I've never heard of a style to not use query args | 00:00 |
| lifeless | ?action=annotate | 00:00 |
| lifeless | would be a reasonable use of query args | 00:00 |
| amanica | nice | 00:00 |
| lifeless | so http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?action=annotate | 00:01 |
| lifeless | without that get the raw bytes of the file | 00:01 |
| lifeless | or alternatively | 00:01 |
| lifeless | so http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?action=raw | 00:01 |
| lifeless | and without that get the pretty view | 00:01 |
| amanica | what pretty view? | 00:02 |
| lifeless | annotated text is the pretty view :) | 00:02 |
| amanica | :) | 00:02 |
| poolie | lifeless, spiv, jam, call in 2m | 00:02 |
| lifeless | I think allowing space in the URL's for revision and stuff is good | 00:02 |
| amanica | as mentioned previously the only problem is: there are special files eg: | 00:03 |
| lifeless | so http://127.0.0.1:8080/bzr.repo/bzr.dev/head:/tools/biobench.py?action=raw | 00:03 |
| lifeless | is better IMO | 00:03 |
| amanica | http://127.0.0.1:8080/bzr.repo/bzr.dev/files | 00:03 |
| lifeless | an alternative is | 00:03 |
| lifeless | http://127.0.0.1:8080/bzr.repo/bzr.dev;rev=head:/tools/biobench.py?action=raw | 00:03 |
| amanica | so we might need to change http://127.0.0.1:8080/bzr.repo/bzr.dev/files -> http://127.0.0.1:8080/bzr.repo/bzr.dev?files | 00:03 |
| thumper | when is the new bzrtools going to be packaged in the bzr ppa? | 00:03 |
| lifeless | bbs | 00:04 |
| thumper | right now I'm holding off installing the 1.7rc as it wants to remove bzrtools | 00:04 |
| thumper | and I use bzrtools all the time, and don't want it removed | 00:04 |
| thumper | nor do I want to use a non-packaged bzrtools | 00:04 |
| amanica | in my use case http://127.0.0.1:8080/bzr.repo/bzr.dev;rev=head:/tools/biobench.py?action=raw is not really an option (I dont know where to split the path) | 00:04 |
| mwhudson | amanica: well, default would be to show the head revision presumably | 00:06 |
| amanica | yup | 00:06 |
| mwhudson | amanica: so far i've been restraining myself a little from suggesting you fix gforge instead/as well :) | 00:06 |
| amanica | and I'd have to add another param for rev=123 | 00:06 |
| amanica | I am busy fixing it :) | 00:06 |
| amanica | I can do a bzr revno on every folder in my path to determine if it is the branch | 00:07 |
| * beuno -> home + dinner | 00:07 | |
| amanica | but that didnt work for me | 00:07 |
| amanica | I have been using `bzr branches` to get a list of branches | 00:08 |
| lifeless | bzr root | 00:08 |
| lifeless | will tell you where the root is | 00:08 |
| amanica | whcih I can compare to the full path to see if I can determine which one is in use | 00:08 |
| amanica | ah | 00:08 |
| amanica | But I thouth if loggerhead is cleaver enough in any case I dont need to mess with that | 00:09 |
| johan | lifeless: no, just that shell scripting makes a bit more sense than a python plugin, for hooks. | 00:09 |
| mwhudson | amanica: in any case it's by now pretty easily to write wsgi stuff to do url traversal however you like | 00:09 |
| mwhudson | amanica: unfortunately the links that get generated will be all wrong :/ | 00:09 |
| mwhudson | if you care to tackle _that_ problem you will definitely be my friend | 00:10 |
| amanica | which _that_ problem? | 00:10 |
| mwhudson | amanica: the link-generation problem | 00:11 |
| amanica | is this wsgi stuff in loggerhead | 00:11 |
| amanica | or do you mean write a site wrapper? | 00:11 |
| mwhudson | loggerhead is all wsgi these days | 00:11 |
| amanica | ok, Ive not seen this link generation problem | 00:13 |
| amanica | so now that I can determine the branch root, I would be able to split up the url. | 00:14 |
| mwhudson | amanica: well it's the standard thing of making sure that the way you generate urls and the way you interpret them line up | 00:14 |
| manunderground | hey does bzr support something similar to git's submodules? | 00:14 |
| manunderground | or bitkeepers ability to reference other repos? | 00:14 |
| mwhudson | amanica: loggerhead is flexible enough to allow the way you interpret urls to be changed easily | 00:15 |
| mwhudson | amanica: but the way they are generated is very hard coded and horrible | 00:15 |
| amanica | oh ok | 00:15 |
| manunderground | ??? | 00:16 |
| amanica | I didn't really intend to change the url generation, but mainly just to support alternate urls | 00:16 |
| amanica | mwhudson: I would still need a way to do this for a specific revno | 00:18 |
| Peng_ | manunderground: Like svn:external? Something like that has been In Progress for ages. | 00:18 |
| manunderground | peng_ dunno if it's the same but I imagine it is, not familiar with svn:external | 00:18 |
| manunderground | it is simply the abillity to have one repo reference another as another working item | 00:18 |
| mwhudson | manunderground: people here may not be familiar with git submodules :) | 00:18 |
| manunderground | here's the use case, you have a suite of apps, you want each app to have its own repository | 00:19 |
| manunderground | you want the suite to have a repository, too, maybe it has an installer or something | 00:19 |
| manunderground | so the suite references the app's repos | 00:19 |
| manunderground | (which in turn reference feature repos? AHHH) | 00:19 |
| amanica | mwhudson: BTW I'm not really a gforge guy, but my company is going to use it, and I HAVE TO USE BZR OR I'LL DIE. so I'm writng a plugin.... | 00:19 |
| amanica | mwhudson: so I still like/need something like http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?revno=123 | 00:22 |
| manunderground | so, it doesn't exist but it's planned and not exactly forthcoming? | 00:22 |
| mwhudson | amanica: right, it can probably be added easily enough | 00:23 |
| amanica | I'm ok with that, but I'd prefer to work on something that will have a chance to get merged in the future, than going off into my own little fork | 00:24 |
| Kilroo | manunderground: I was just reading something today about different directory structures you can use for repositories with Bazaar. | 00:25 |
| amanica | thats why I'm trying to get an idea of what others want. and surprisingly its not what I thought | 00:25 |
| Kilroo | A couple of them were essentially ways where you have a shared repository for a collection of projects and then separate projects within that repository. | 00:25 |
| Kilroo | But I can't find the page again, so I'm not sure how closely it resembles the organization pattern you describe. | 00:26 |
| manunderground | Kilroo: hm, hard to say, but it'd be cool if you found that again | 00:26 |
| manunderground | I think this is actually a very important feature | 00:27 |
| mwhudson | manunderground: there are kind of two answer to this, there is "nested trees" which i woudn't hold your breath for, and there is "config-manager" which collects branches into one tree on disk | 00:27 |
| manunderground | mwhudson: so can you explain "collects branches into one tree" means | 00:28 |
| fullermd | manunderground: And in bzr terms, you mean 'branches', not 'repos'. | 00:28 |
| manunderground | oh ok | 00:28 |
| manunderground | haha | 00:28 |
| manunderground | thanks | 00:28 |
| manunderground | but then I assume that the branch is the entire tree? | 00:28 |
| manunderground | (meaning, you can trace out the entire tree from the branch) | 00:29 |
| fullermd | Well, branches are what you work with. You never work with 'repos'. | 00:29 |
| manunderground | alright, let me try to clarify thigns here. when I say repo I mean a tree | 00:29 |
| manunderground | with the root | 00:29 |
| manunderground | and a branch is not the full tree, right? | 00:30 |
| manunderground | the tree is a collection of branches | 00:30 |
| manunderground | and I'd like to have, say, 3 independent trees | 00:30 |
| manunderground | then a fourth one which references the other three | 00:30 |
| manunderground | (and ideally doesn't have to put import all their files or history) | 00:30 |
| manunderground | so it's a reference that I'm looking for, I think :-) | 00:31 |
| fullermd | As I understand you, you'd have 3 branches, and then a fourth branch with not much in it, but references to those other 3. | 00:31 |
| fullermd | (assuming that nested trees were up and running) | 00:32 |
| manunderground | alright, that sounds like what I want, so that is supported? | 00:32 |
| fullermd | No. | 00:33 |
| fullermd | Now, there's nothing stopping you from arranging the 3 branches however you want on your system. But the bits that allow automating treating them as a single entity from the outside aren't there. | 00:33 |
| manunderground | oh ok, so you would have then if I understand you there's no way to track the history of references in your project? You could put some placeholder dirs or readmes, etc, but not actually reference the other projects repo's | 00:34 |
| manunderground | haha, minus the "so you would have then" bit... | 00:35 |
| jml | poolie: woot. | 00:46 |
| poolie | jml, ? | 00:47 |
| jml | poolie: saw the call minutes :) | 00:47 |
| jml | * looking at failure jml is seeing on stacked | 00:47 |
| poolie | was there any other news on it from your side? | 00:48 |
| jml | poolie: I've filed bugs with easy steps to reproduce the symptoms, that's about it. | 00:54 |
| === mw is now known as mw|out | ||
| LaserJock | can lightweight checkouts be pushed to LP? | 01:28 |
| jml | LaserJock: only branches. | 01:28 |
| LaserJock | hmm, interesting | 01:28 |
| LaserJock | so the only good way of sharing changes to a lightweight checkout is to send patches? | 01:29 |
| jml | I'm a little confused. | 01:29 |
| LaserJock | sorry | 01:30 |
| jml | by 'changes to a lightweight checkout', do you mean 'local edits without commits'? | 01:30 |
| jml | it's ok, I'm just having a slow day :) | 01:30 |
| LaserJock | no | 01:30 |
| LaserJock | I mean, I want to get a branch from LP, make some commits, and then get it back to the author | 01:30 |
| LaserJock | I was wondering if a lightweight checkout would work for that or not | 01:31 |
| LaserJock | can I make local commits on a lightweight checkout even? | 01:31 |
| jml | I don't think so. | 01:31 |
| jml | well, you can if it's a lightweight checkout of a branch you have write access to | 01:31 |
| jml | oh | 01:32 |
| jml | but they aren't local | 01:32 |
| * jml should really try today again. | 01:32 | |
| LaserJock | I don't think I have write access either | 01:32 |
| jml | LaserJock: I think you'll need to make a real, honest-to-goodness branch. | 01:33 |
| mwhudson | soon, you'll be able to branch --stacked | 01:34 |
| LaserJock | mwhudson: that'll give me partial history? | 01:34 |
| mwhudson | basically yes | 01:34 |
| jml | although I imagine that for heavy hacking you'll still probably want a shared repo model — not sure. | 01:34 |
| lifeless | LaserJock: if youwant to commits you need write access; a stacked branch will work, or a normal branch | 01:35 |
| LaserJock | lifeless: right, I was wondering if I could do a lightweight checkout and then push it to my bzr space | 01:36 |
| LaserJock | makes sense though that that wouldn't exactly work | 01:36 |
| LaserJock | ok, another question. when I'm branching I get a notice that the branch format is old | 01:39 |
| lifeless | complain to the branch owner | 01:39 |
| LaserJock | ok | 01:39 |
| lifeless | (they should upgrade it) | 01:39 |
| LaserJock | I wondered if I should upgrade it or if they should | 01:39 |
| lifeless | unless you have write access, you can't | 01:40 |
| LaserJock | but I'm not sure if it's just because I'm using newer bzr or not | 01:40 |
| lifeless | if you do, then you can [with some tricks if its on launchpad] | 01:40 |
| LaserJock | is there a table of formats vs bzr version? | 01:40 |
| lifeless | core formats have versions in them, that indicate the introducing version | 01:41 |
| lifeless | formats that don't have a version in them are either very old (0.8 or so) | 01:41 |
| LaserJock | so this ones says: RepositoryFormatKnit1 | 01:41 |
| lifeless | or plugin formats that you need a specific plugin for | 01:41 |
| lifeless | there should be a line at the top | 01:42 |
| lifeless | someting like 'knits' - anyhow, thats a very old format | 01:42 |
| lifeless | bzr 0.8 and above read and write it, but its slow. | 01:42 |
| LaserJock | yeah, this branch is taking *forever* | 01:42 |
| LaserJock | I'll perhaps mention it to mvo tomorrow | 01:42 |
| LaserJock | if you upgrade a branch how does it know what to upgrade to? does it just go to the latest default? | 01:43 |
| lifeless | with the exception of bzr-svn branches, it goes to the current default, which we are conservative about changing | 01:44 |
| lifeless | the current default works with bzr 0.92 and above | 01:44 |
| LaserJock | ah, ok good | 01:44 |
| lifeless | with bzr-svn branches it will error, as you need to manually specify what to upgrade to | 01:45 |
| LaserJock | I was wondering if it's easy to get a situation where a person upgrading via bzr.dev ends up doing bad things for other users | 01:45 |
| lifeless | LaserJock: if we were silly, it would be :P | 01:46 |
| LaserJock | well ... :-) | 01:46 |
| LaserJock | jeeze, this thing is using like 2 KB/s | 01:47 |
| lifeless | "slow" :P | 01:47 |
| LaserJock | I guess I could start like 10 branches at the same time :-) | 01:49 |
| fullermd | Well, using bzr.dev caused bug 261339, frex :p | 01:58 |
| ubottu | Launchpad bug 261339 in bzr "Upgrade from knit to pack fails on revision not present" [Critical,Fix released] https://launchpad.net/bugs/261339 | 01:58 |
| fullermd | (well, maybe not precisely caused, but caused to exhibit anyway) | 01:58 |
| LaserJock | hmm, has the idea of combining init-repo with branch come up? | 02:03 |
| jml | LaserJock: kind of. | 02:05 |
| jml | LaserJock: rockstar and I have talked about a plugin that does the init-repo when fetching a branch for the first time. | 02:05 |
| LaserJock | yeah, something like that | 02:06 |
| LaserJock | I always forget | 02:06 |
| jml | LaserJock: it's slightly complicated by the fact that some people like to keep their local branches separate from their working trees. | 02:07 |
| LaserJock | so like you would have ~/branches/* and then ~/working ? | 02:08 |
| jml | LaserJock: something like that. | 02:13 |
| jml | LaserJock: to do that manually, you'd go 'bzr init-repo --no-trees ~/branches; cd ~/branches; bzr branch <whatever>; cd ~/trees; bzr co --lightweight ~/branches/<whatever>' | 02:15 |
| jml | maybe there's an easier way. | 02:15 |
| * jml shrugs | 02:15 | |
| jml | I mix trees and branches with merry abandon. | 02:15 |
| LaserJock | oh woah, that's interesting | 02:16 |
| jml | thumper, abentley and others use that layout | 02:17 |
| jml | and can help you more if you're interested | 02:17 |
| LaserJock | jml: why do init-repo in ~/branches ? | 02:17 |
| LaserJock | instead of just doing individual branches | 02:18 |
| jml | LaserJock: it creates a repository (that is, a bucket for revisions) that can be shared between branches. | 02:18 |
| jml | LaserJock: this saves space and also makes certain operations faster | 02:19 |
| LaserJock | so I guess if you had branches with similar history it'd help | 02:19 |
| jml | in particular, making new branches and fetching branches from remote hosts | 02:19 |
| jml | LaserJock: right. | 02:19 |
| RAOF | And, by "certain operations" jml means "branching". And by "faster", he means "like a hojilion times faster". | 02:19 |
| jml | LaserJock: so actually, you _wouldn't_ do "init-repo ~/branches" | 02:20 |
| jml | you'd probably do "init-repo ~/repos/<my-project>" | 02:20 |
| jml | and then "init-repo ~/repos/<another-project>" | 02:20 |
| LaserJock | I was reading about a science professor who was using bzr repos for papers | 02:24 |
| rockstar | jml, LaserJock it just so happens that I'm polishing that plugin right now. | 02:24 |
| LaserJock | so if he had a new paper or presentation he'd bzr branch | 02:24 |
| LaserJock | seemed like a really cool idea | 02:24 |
| === kiko is now known as kiko-zzz | ||
| jml | I know at least one PhD student who uses Bazaar for their thesis. | 02:26 |
| jml | maybe two. | 02:26 |
| LaserJock | that's what I'm doing right now ... | 02:26 |
| LaserJock | it's nice to know what revision I gave my advisor to read | 02:27 |
| LaserJock | the idea of a presentations bzr repo is interesting, since often they are a fairly linear progression | 02:28 |
| rockstar | Hom do I get a branch's format in bzrlib Branch? | 02:30 |
| rockstar | s/Hom/How | 02:30 |
| mwhudson | rockstar: from a branch object? | 02:30 |
| mwhudson | b._format.get_branch_format() i think | 02:30 |
| jml | well | 02:30 |
| spiv | LaserJock: I habitually make branches for any slides I'm working on | 02:30 |
| jml | assuming a certain modernity. | 02:31 |
| jml | there isn't actually a consistent way across all formats, I don't think. | 02:31 |
| rockstar | *gasp* An API where I have to access the a property starting with _ | 02:32 |
| spiv | LaserJock: I don't think I've ever looked at the old revisions, but just knowing that I *can* lets me relax and delete unused ideas and whatever from my slides rather than leaving them floating around until the last moment in case I decide I might want to use them after all. | 02:32 |
| LaserJock | spiv: yeah, exactly | 02:32 |
| rockstar | jml, the use case is this: I have my plugin, and I'm getting repository/branch format conflicts | 02:33 |
| jml | rockstar: that's not a use case :) | 02:34 |
| jml | rockstar: what are you doing to get these conflicts? | 02:34 |
| LaserJock | I wish I could go back in time 6 years and input everything into bzr :-) | 02:34 |
| rockstar | jml, let me finish! | 02:34 |
| * jml does so | 02:34 | |
| jml | LaserJock: putting Bazaar back in time six years would solve a lot of my problems. | 02:34 |
| rockstar | So, I get conflicts when I create a repository with the default format, and then try to put a branch in the repo that doesn't have a compatible format. | 02:36 |
| rockstar | So I needed to open the branch to check the format BEFORE I create the repo. | 02:36 |
| jml | rockstar: so, you need to open the url as a BzrDir and then check the repo format | 02:39 |
| jml | I guess. | 02:39 |
| rockstar | jml, yes. However, mwhudson's response seems to be incorrect. | 02:39 |
| mwhudson | rockstar: i think you can look at the cloning metadir for that | 02:39 |
| rockstar | mwhudson, Would this help? http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.branch.BranchFormat.html#find_format | 02:41 |
| poolie | ok, really focussing on 270738 now | 02:49 |
| jam | poolie: the patch you posted conflicts with spiv's remote error fixes (bug #2613515) | 02:50 |
| ubottu | Error: Launchpad bug 2613515 could not be found | 02:50 |
| jam | 261315 | 02:50 |
| jam | bug #261315 | 02:50 |
| ubottu | Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 | 02:50 |
| jam | bug #270738 | 02:50 |
| ubottu | Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] https://launchpad.net/bugs/270738 | 02:50 |
| jam | jml mentioned it, I just confirmed it | 02:50 |
| poolie | jam, i intentionally did mine off an old branch to ease integration into 1.7 | 02:50 |
| jam | sure | 02:50 |
| poolie | i guess i should merge it into 1.7? or just into trunk? | 02:50 |
| jam | just that the 1.7 branch *has* spiv's changes | 02:51 |
| poolie | or rather, merge them into me | 02:51 |
| jam | poolie: right, just 1.7 | 02:51 |
| jam | poolie: the change to "get_stacked_on_url" seems like it should be a per_branch test | 02:52 |
| poolie | jam, do you mean that you can still get it even if the repo can't accommodate it? | 02:53 |
| rockstar | Okay, so it looks like the branch is a RemoteBranch object. Is there a way to get the format of the RemoteBranch? | 02:53 |
| poolie | hm, maybe | 02:53 |
| jam | poolie: right, just that it changes the API of the function | 02:53 |
| jam | to always return the config value | 02:53 |
| poolie | rockstar: remotebranch._real_branch.format unfortunately | 02:53 |
| poolie | if you want the on-disk format | 02:53 |
| jam | Personally, I prefer it to return None rather than raise an exception, but that is a long-ago discussion that got missed | 02:53 |
| rockstar | poolie, _real_branch is apparently None | 02:54 |
| poolie | call ._ensure_real then | 02:54 |
| poolie | jam, i know | 02:54 |
| poolie | i wonder if it would be better to just change it anyhow though | 02:54 |
| poolie | like, will there really be that many external callers of it? | 02:55 |
| jam | poolie: why do you have the "self._remote_path()" instead of "self.bzrdir._path_for_remote_call()" ? | 02:56 |
| jam | I think it is *better* I just don't see why it was important for this patch | 02:56 |
| poolie | i just didn't want to copy & paste it again | 02:58 |
| poolie | um | 02:58 |
| poolie | i feel a tension between doing focussed patches and cleaning things as i go | 02:58 |
| jam | sure | 02:59 |
| jam | I was mostly just trying to understand the patch and where I needed to focus | 02:59 |
| jam | I'm fine with the cleanup | 02:59 |
| jam | though generally for a rc hotfix I would avoid them | 02:59 |
| poolie | true | 03:01 |
| LaserJock | is there a possibility of a branching from LP just stalling? | 03:02 |
| LaserJock | I'm going on 1.5 hrs now and I'm not sure if there's any progress | 03:03 |
| lifeless | LaserJock: strace the process | 03:03 |
| lifeless | LaserJock: is it a big project? | 03:04 |
| LaserJock | I didn't think so | 03:05 |
| LaserJock | gnome-app-install | 03:05 |
| LaserJock | 600 or so revisions | 03:05 |
| LaserJock | but the actual size shouldn't be bad | 03:05 |
| lifeless | its more file-count that breaks knits | 03:05 |
| LaserJock | ok, strace says it's still doing stuff | 03:05 |
| abadger1999 | When using relative directories for workingtree.add() and workingtree.smart_add(), what is it supposed to be relative to? | 03:05 |
| lifeless | abadger1999: add is relative to tree root | 03:06 |
| abadger1999 | My test is showing it's relative to the cwd, but the documentation says it should be relative to the wt root. | 03:06 |
| lifeless | smart_add is a little broken, its relative to pwd | 03:06 |
| abadger1999 | Ah... maybe add is giving me a different error then. | 03:06 |
| abadger1999 | lifeless: To make smart_add work as expected, do I need to os.chdir() to the tree root and then back after the call? | 03:07 |
| LaserJock | lifeless: 227 files for 2.7MB is the source tree | 03:07 |
| abadger1999 | relpath() broken too? | 03:08 |
| lifeless | abadger1999: no, just give the relpath from cwd | 03:09 |
| abadger1999 | Ah. rigt. | 03:09 |
| abadger1999 | lifeless: Thanks | 03:09 |
| jam | poolie: BB:tweak sent to the list | 03:09 |
| lifeless | LaserJock: so it will be ~ 227 * 2 * RTT + BW*(history size) | 03:09 |
| poolie | i'm just working on the test merge, thanks john | 03:09 |
| LaserJock | lifeless: well, as long as I know it's still working I'll stick with it. I just didn't see the progress bar or "pinwheel" moving so I wondered if somehow it got hung up | 03:11 |
| lifeless | bbs, lunching | 03:12 |
| poolie | LaserJock: over ssh or http? | 03:19 |
| * rockstar is having a hell of a time creating a repository with a format compatible with this branch | 03:22 | |
| === mwhudson is now known as mwh | ||
| spiv | rockstar: source_branch.repository._format.initialize(target_bzrdir) ? | 03:27 |
| rockstar | spiv, well, the way it works on branches that use a something besides knitpack is: | 03:29 |
| rockstar | format = bzrdir.format_registry.make_bzrdir('default') | 03:29 |
| rockstar | newdir = format.initialize_on_transport(to_transport) | 03:29 |
| rockstar | repo = newdir.create_repository(shared=True) | 03:29 |
| spiv | The default repository format isn't compatible with all branches, though. | 03:30 |
| LaserJock | poolie: ssh | 03:32 |
| rockstar | spiv, yea, experiencing this now. | 03:33 |
| lifeless | rockstar: what are you trying to do? | 03:33 |
| spiv | rockstar: so what problem are you trying to solve? If it's "make a branch into a new shared repository", then you probably want to preserve the original format. | 03:33 |
| rockstar | spiv, yes, that's why I'm fixing the bug. :) | 03:33 |
| spiv | rockstar: if so, I'd make a new *empty* bzrdir, then use my suggestion above (passing shared=True), then just branch.sprout into a directory under that. | 03:34 |
| rockstar | lifeless, I've been sitting on this plugin for a while that creates a shared repository and puts a branch inside. | 03:34 |
| lifeless | rockstar: create the repo by using the source repo's bzrdir to sprout | 03:36 |
| lifeless | source_branch.repository.bzrdir.sprout() | 03:36 |
| rockstar | lifeless, wow, I think you just took out most of my code with that (provided it works) | 03:37 |
| poolie | LaserJock: i'm hoping to work soon on better progress messages for ssh | 03:40 |
| poolie | spiv, jml, lifeless, Functional Programming Sydney is on tomorrow at 6:30 at google | 03:41 |
| LaserJock | poolie: are they different than for http? | 03:41 |
| poolie | LaserJock: without going into detail yes the codepath is a bit different | 03:41 |
| spiv | poolie: d'oh. It's a birthday dinner for my mother tomorrow night. | 03:42 |
| jml | poolie: ooh. | 03:47 |
| LaserJock | what's the 0/4 step in branching? copying over revisions? | 03:53 |
| rockstar | lifeless, remote_branch.repository.bzrdir.sprout() seems to be sprouting the branch, not a repository. | 04:11 |
| lifeless | ah yes, I was a bit quick there :P | 04:12 |
| lifeless | LaserJock: file texts | 04:12 |
| wgrant | It is ridiculously slow. I can't see how it could be so slow even if it is plain knits. | 04:13 |
| poolie | spiv, i know it's probably in a message somewhere but | 04:13 |
| lifeless | rockstar: so the source.repository.bzr._format object should be parameterised correctly | 04:13 |
| poolie | what is the point of the error translation change in your landing to 1.7? | 04:13 |
| poolie | just asking to know, not cause i disapprove | 04:13 |
| jml | wgrant: what is? | 04:15 |
| wgrant | jml: Checking out the branch that LaserJock is attempting to check out. | 04:15 |
| jml | wgrant: from Launchpad? | 04:16 |
| wgrant | Yes. | 04:16 |
| LaserJock | wgrant: oh, it finished! | 04:17 |
| LaserJock | Branched 616 revision(s). | 04:17 |
| LaserJock | real 147m15.237s | 04:17 |
| wgrant | LaserJock: How big is it all up? | 04:17 |
| LaserJock | .bzr is 33MB | 04:18 |
| rockstar | lifeless, parameterized correctly how? | 04:18 |
| lifeless | LaserJock: run 'bzr upgrade' in your copy | 04:19 |
| lifeless | LaserJock: it will at least make your push, when you publish to LP, nice and fast :) | 04:19 |
| wgrant | What is the status of stacked branches (with LP)? | 04:20 |
| LaserJock | lifeless: do I run upgrade in the branch or in the root of the share repo? | 04:21 |
| jml | wgrant: the next rollout will support them and have a default stacking policy set up for certain projects. | 04:21 |
| LaserJock | *shared | 04:21 |
| lifeless | LaserJock: oh, if you have a shared repo already, its probably already packs | 04:22 |
| wgrant | jml: The rollout in a few hours? | 04:22 |
| LaserJock | lifeless: oh, so was it taking so long because it was converting as it was branching? | 04:22 |
| wgrant | Do we get docs on how to use them, or do we have to work to actually discover that they are supported, and work harder to work out how to use them? | 04:22 |
| AfC | oh, snap | 04:23 |
| jml | wgrant: that rollout, yes. | 04:23 |
| lifeless | LaserJock: it shouldn't have no, the conversion from knits to packs is trivial - we just strip off some metadata | 04:23 |
| LaserJock | hmm, this doesn't look good. bzr info in the branch gives: Repository tree (format: unnamed) | 04:23 |
| wgrant | jml: Aha. | 04:23 |
| jml | wgrant: using them is a Bazaar issue :) | 04:23 |
| wgrant | jml: How does LP define a stacking policy? | 04:24 |
| wgrant | Or is that a branch property? | 04:24 |
| wgrant | Your statement about doing it for certain projects above has me confused. | 04:24 |
| jml | wgrant: a branch can be stacked on another branch. Bazaar has a feature where new branches can be automatically stacked on a preconfigured branch. | 04:24 |
| lifeless | LaserJock: there is a bug on that | 04:24 |
| lifeless | LaserJock: just run 'bzr upgrade' in the new branch | 04:25 |
| lifeless | LaserJock: that will upgrade it to a tags-supporting branch | 04:25 |
| wgrant | jml: Right, that makes sense, but I wondered how LP came into the configuration equation. | 04:25 |
| jml | wgrant: roughly speaking, Launchpad will stack branches on the development focus branch by default. | 04:26 |
| wgrant | I fail to see how Launchpad can decide that, but I guess I've no choice but to trust you! | 04:27 |
| lifeless | lp tells bzr what to stack on | 04:27 |
| === thumper_laptop is now known as thumper | ||
| jml | wgrant: I'm not sure I follow. | 04:31 |
| wgrant | jml: Normally when I push a branch to LP, LP doesn't interfere. I just upload the branch over sftp or bzr+ssh, and LP eventually scans it. LP has no say in the upload. | 04:32 |
| LaserJock | lifeless: yeah, bzr upgrade was trivial and got me a recognizable format | 04:32 |
| jml | wgrant: so, Launchpad tells the client 'you should stack your branches on URL', and the client says 'OK' | 04:33 |
| wgrant | jml: Aha, that makes sense. | 04:33 |
| jml | wgrant: except actually because bzr is request / response, Launchpad only answers questions | 04:33 |
| wgrant | I presume that this doesn't work unless I use bzr+ssh. | 04:34 |
| jml | actually, sftp works fine too. | 04:34 |
| spiv | poolie: It was for https://bugs.launchpad.net/bzr/+bug/263527 | 04:34 |
| ubottu | Launchpad bug 263527 in bzr "ErrorFromSmartServer should not cause a traceback" [Medium,Fix released] | 04:34 |
| spiv | poolie: basically it doesn't scare users with a client-side traceback when it's (probably) the server that's having the problem. | 04:35 |
| jml | wgrant: it won't work for old formats. they'll just upload normally. | 04:35 |
| wgrant | jml: So it speaks bzr over sftp somehow? | 04:35 |
| wgrant | I thought pushing over sftp was just copying things with sftp. | 04:35 |
| jml | not really. | 04:36 |
| wgrant | Well, at least it didn't use anything bzr-specific. | 04:36 |
| jml | Bazaar delegates to format objects, which do file operations more intelligently than dumb copying. | 04:36 |
| jml | here, the new format checks the remote configuration file. | 04:37 |
| lifeless | wgrant: lp synthesises a file at the project/ path in the sftp tree | 04:37 |
| lifeless | wgrant: bzr reads that file | 04:37 |
| * jml has a mental picture of himself standing at a keyboard wearing a devo hat. | 04:38 | |
| wgrant | lifeless: Ahh. | 04:38 |
| wgrant | lifeless: That explains it - I wondered how bzr could get information from LP from an empty directory. | 04:39 |
| LaserJock | wgrant: LP is full of "magic" :-) | 04:45 |
| jml | we try to keep it to a minimum. | 04:46 |
| jml | (alternatively, "You think that's files you're reading?") | 04:47 |
| abentley | poolie: Thanks for setting up bzr-core. I have gotten herb to zap bazaar-overall | 04:48 |
| poolie | i saw, thanks | 04:49 |
| poolie | spiv, so I was wondering about TestBranchSetLastRevisionInfo.test_unexpected_error | 04:55 |
| poolie | but maybe i understand more now | 04:55 |
| poolie | spiv, could it be that the comment at the top of that test is wrong? | 04:55 |
| poolie | # A response of 'NoSuchRevision' is translated into an exception. | 04:55 |
| poolie | actually it's testing when we get a random unexpected error | 04:56 |
| LaserJock | ok, so pushing the same branch (now upgraded) took 16 min | 04:56 |
| LaserJock | so a total turn-around for branch-push of 163 minutes | 04:56 |
| jml | :( | 04:57 |
| poolie | !! | 04:57 |
| mwh | well, the time to upload is ok i guess... | 04:57 |
| LaserJock | and so now I dont' have any time to hack on it | 04:57 |
| mwh | er | 04:57 |
| mwh | well | 04:57 |
| mwh | better | 04:57 |
| LaserJock | wgrant: are you gonna time a branch from mine? | 04:58 |
| jml | also, if you could do -Dhpss, that would be great. | 04:58 |
| LaserJock | mwh: I might have been limited by my upload bandwidth | 04:59 |
| LaserJock | holy cow, wgrant got my branch in 2.5 min | 05:00 |
| wgrant | And I'm in .au. Not too bad. | 05:00 |
| LaserJock | hmm, 147 vs 2.5 | 05:00 |
| wgrant | Just a tad faster. | 05:00 |
| wgrant | I think knits need to die. | 05:00 |
| poolie | wgrant: well, you should get a warning about them with the current code | 05:01 |
| poolie | either 1.6 or 1.7? | 05:01 |
| spiv | poolie: yeah, the comment does seem to be a copy & paste mistake. | 05:01 |
| mwh | i think the version of bar running on the server is _particularly_ bad with knits | 05:01 |
| wgrant | (oh, and this is with Hardy's bzr over HTTP, so it's probably rather slower than it should be) | 05:01 |
| mwh | wgrant: oh | 05:01 |
| wgrant | I was using Intrepid's bzr of bzr+ssh to get the knit branch, IIRC. But that machine doesn't have direct Internet access now, so I'm doing it on another box. | 05:02 |
| wgrant | s/of/and/ | 05:02 |
| mwh | well, for the initial branch, bzr+ssh probably doesn't beat http by much | 05:02 |
| wgrant | Ah. | 05:02 |
| jml | if at all. | 05:03 |
| wgrant | How much faster should bzr 1.6 be than 1.3.1? | 05:03 |
| mwh | (there's limited opportunity for cleverness after all, it's a "get all this data from here to there" operation) | 05:03 |
| wgrant | Probably not much, I guess. | 05:03 |
| jml | also, encryption :) | 05:03 |
| mwh | wgrant: for bzr+ssh, "a bit" | 05:03 |
| mwh | wgrant: for http, not much at all i expect | 05:03 |
| poolie | initial push is pretty close to the underlying bandwidth for packs | 05:03 |
| poolie | about 90% | 05:03 |
| LaserJock | yeah, I was at my bandwidth max when pushing 40KB/s | 05:04 |
| * jml goes to get coffee | 05:04 | |
| LaserJock | but when branching I was only using ~ 2KB/s | 05:04 |
| poolie | spiv, i'm not so sure the distinction between ErrorFromSmartServer and Unexpected& is really worthwhile... | 05:05 |
| poolie | i mean if you get the former and it's not matched, surely it's unexpected? | 05:05 |
| poolie | anyhow i've resolved the merge for 1.7 | 05:05 |
| spiv | poolie: if an ErrorFromSmartServer escapes from a Remote* object, that's a bug in the client -- it means the error translation isn't being invoked. | 05:06 |
| spiv | Whereas Unexpected& is "the client tried to translate and couldn't, so it appears the server is talking nonsense". | 05:07 |
| poolie | mm | 05:07 |
| poolie | ok | 05:07 |
| === Kittens is now known as spaz|asshole | ||
| === spaz|asshole is now known as Kittens | ||
| poolie | jml, spiv, jam, the integrated fix for 261315 is now submitted to pqm for 1.7 | 05:36 |
| spiv | Hooray! | 05:36 |
| poolie | i'm going to take a break then look at | 05:36 |
| poolie | um, that keyerror thing | 05:36 |
| poolie | spiv, i want to use the updated wiki roadmap page in my meeting tomorrow night | 05:37 |
| poolie | i'll work with you on it later or tomorrow if you want | 05:37 |
| poolie | oh foo, i guess it clashes with fpsyd | 05:37 |
| abadger1999 | Thanks a bunch guys! transifex will have a working bzr submission backend courtesy of your help. | 05:51 |
| vila | hi all | 07:01 |
| poolie | hello vila | 07:08 |
| poolie | how's things | 07:08 |
| vila | fine, many mails to write today :) | 07:09 |
| poolie | oh, what kind of thing? | 07:09 |
| vila | oh, summaries for python-2.6 compatibility, the ones I mentioned the last time, november meeting, etc | 07:11 |
| vila | I will try to clear my mailbox a bit more today :D | 07:11 |
| lifeless | mwh: are there docs on the generator protocol for C extensions? | 07:20 |
| spiv | lifeless: 'generator protocol'? AIUI, it's just the iterator protocol. Are you asking about creating generators or something? | 07:24 |
| lifeless | spiv: pyrex doesn't support yield | 07:35 |
| lifeless | spiv: I'm looking at how to make a pyrex module behave like its yielding with the least possible overhead | 07:35 |
| spiv | The yield keyword is just a convenient (and efficient) way to build an iterator. | 07:37 |
| lifeless | I just had to restrain myself from sarcasm | 07:37 |
| poolie | wonders never cease :) | 07:38 |
| spiv | So if I'm understanding you correctly, the answer to your problem is "write an object that conforms to the iterator protocol". I feel like I'm missing something? | 07:38 |
| lifeless | spiv: we need tp_iternext in the C object set to the next in the C level code, for instance | 07:39 |
| spiv | Right. It sounds like you understand the C end of things just fine, so I'm not sure what you're asking about. :) | 07:44 |
| spiv | Or maybe it's how to do it in Pyrex that's the issue? | 07:45 |
| lifeless | spiv: indeed | 07:45 |
| spiv | Ah, ok. | 07:45 |
| lifeless | spiv: and with lowest overhead I can achieve :P | 07:45 |
| spiv | I think Pyrex lets you define __next__ on your class. | 07:45 |
| spiv | (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/special_methods.html mentions it) | 07:47 |
| lifeless | yes, just been reading that :P | 07:47 |
| lifeless | thanks | 07:47 |
| spiv | Oh well, that exhausts my expertise on the topic, so I'll shut up now :) | 07:48 |
| lifeless | john did an iterator for win32 | 07:51 |
| lifeless | so there is stuff to cargo cult | 07:51 |
| lifeless | but I was hoping to know more about e.g. marshalling and reentry overhead etc | 07:51 |
| spiv | Take a peek at the C translation I guess. | 07:53 |
| spiv | I can make some guesses, but that's probably not very helpful :) | 07:53 |
| thumper | please can we have bzrtools in the bzr ppa? | 08:52 |
| speakman | hi folks! :) | 08:54 |
| speakman | how is --fixes supposed to work? | 08:54 |
| speakman | I'm using Trac, and even if it doesn't work with Trac for the moment, I'd like to use it anyway in case it will be supported later on. | 08:55 |
| speakman | but "bzr commit -m "message" --fixes 30" results in a "bzr: ERROR: Invalid bug 30. Must be in the form of 'tag:id'. Commit refused." | 08:56 |
| RAOF | speakman: --fixes=$BUGID. So, for launchpad, I pass --fixes=lp:12345 | 08:56 |
| ubottu | Launchpad bug 30 in malone "comments on bugs require subjects" [Medium,Fix released] https://launchpad.net/bugs/30 | 08:56 |
| * spiv knocks another 10s off pushing 1 new rev to a bzr.dev branch. (Now down to 51s over 500ms latency link, down from 73s with 1.4) | 08:56 | |
| speakman | RAOF: I see. How can I use it in my local repo? Or even with trac if it's supported nowadays? | 08:57 |
| spiv | speakman: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings | 08:58 |
| spiv | speakman: note that all --fixes does is set a property in that revision. It's then up to your Trac/Bugzilla/whatever instance to interpret that property. | 08:59 |
| speakman | spiv: ok, I'd just like it to be set in the changeset, no matter if it's interpreted or used. :) | 09:01 |
| spiv | Cool. | 09:02 |
| speakman | regarding the docs; am I supposed to edit the .bzr/branch/branch.conf by hand? | 09:02 |
| spiv | I think so, although it's not something you'd need to do very often. | 09:06 |
| spiv | I can't remember the last time I edited one, if ever. | 09:07 |
| * jml can | 09:08 | |
| jml | but I was trying to break stuff :) | 09:08 |
| lifeless | spiv: great news | 09:08 |
| lifeless | spiv: I know I'd love to hear about such things on-list too :> | 09:08 |
| spiv | lifeless: and it's only a bit of a hack, too ;) | 09:09 |
| speakman | reading the doc twice I found setting trac-url into ~/.bazaar/bazaar.conf works great too :) | 09:09 |
| poolie | actually | 09:09 |
| poolie | jml, re bug 270738 | 09:10 |
| ubottu | Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] https://launchpad.net/bugs/270738 | 09:10 |
| speakman | Now my latest changeset is commited with --fixes project:bugno, but I can't even see it with "bzr log -r -1 -v". Isn't it supposed to show up? | 09:10 |
| jml | poolie: yes. | 09:10 |
| poolie | the attribute error is obviously just hiding something else | 09:10 |
| poolie | assuming that it's not already fixed in the branch | 09:10 |
| bob2 | speakman: afaik it is only shown by 'bzr viz' | 09:10 |
| poolie | could you make a trivial change like say changing the last parameter to repr(self) or "" | 09:10 |
| poolie | and tell me what happens then | 09:11 |
| poolie | because i cannot reproduce it at present | 09:11 |
| jml | poolie: sure. gimme a second to finish off this thought. | 09:11 |
| jml | poolie: actually, do you have an updated non-conflicting version of your bundle? | 09:11 |
| LarstiQ | moin | 09:12 |
| * jml becomes curious as to how zope orders its layers | 09:13 | |
| jml | LarstiQ: hello. | 09:13 |
| LarstiQ | jml: hello :) | 09:13 |
| spiv | speakman: https://bugs.edge.launchpad.net/bzr/+bug/251729 | 09:14 |
| ubottu | Launchpad bug 251729 in bzr "It would be nice to have bugs informations in logs" [Wishlist,Confirmed] | 09:14 |
| poolie | jml, i sent it in to pqm | 09:15 |
| poolie | if you pull bzr.1.7 you'll get it | 09:15 |
| jml | poolie: ahh ok. | 09:16 |
| poolie | or http://sourcefrog.net/bzr/261315-into-1.7 | 09:16 |
| jml | pqm is empty, so I'll try pulling now. | 09:16 |
| jml | while my machine thrashes for these tests | 09:16 |
| jml | poolie: did you try to reproduce with the same branch? | 09:18 |
| jml | poolie: I get that same error with bzr.dev | 09:20 |
| jml | I'll update to use repr | 09:21 |
| jml | poolie: I wonder why you can't reproduce the bug. | 09:21 |
| jml | poolie: | 09:23 |
| jml | $ bzr branch bzr+ssh://localhost/tmp/e g | 09:23 |
| jml | bzr: ERROR: Revision {set([('Arch-1:walters@verbum.org--2003%tla-pqm--mainline--0.1--patch-10',), ('Arch-1:walters@verbum.org--2003%arch-pqm--main--0--base-0',), ('Arch-1:walters@verbum.org--2003%tla-pqm--mainline--0.1--patch-1',), ('Arch-1:walters@verbum.org--2003%tla-pqm--mainline--0.2--base-0',), ('Arch-1:robert.collins@canonical.com--general%arch-pqm--main--0--base-0',), ('Arch-1:robert.collins@canonical.com--general%arch-pqm--main--0--patch-1',), ('A | 09:23 |
| jml | rch-1:walters@verbum.org--2003%tla-pqm--mainline--0.3--base-0',)])} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()), <bzrlib.knit._DirectPackAccess object at 0x882194c>)". | 09:23 |
| jml | poolie: feel free to call me on my mobile if you want to talk more, I'm off. | 09:28 |
| poolie | thanks very much | 09:29 |
| matkor | Hi ! | 10:24 |
| matkor | How can I resolve such strange to me confilcts: Conflict adding file semantics_cserver.py.BASE. Moved existing file to semantics_cserver.py.BASE.moved. | 10:25 |
| matkor | I do not remember adding semantics_cserver.py.BASE | 10:25 |
| matkor | I have valid content in semantics_cserver.py | 10:25 |
| matkor | which I would like to commit | 10:25 |
| LarstiQ | matkor: that sounds like a second round of conflicts on top of the existing one | 10:26 |
| LarstiQ | matkor: when do you get this conflict? | 10:27 |
| matkor | LarstiQ: I worked over checkout .. | 10:27 |
| matkor | did unbind , commited some changes and bind later | 10:27 |
| matkor | result was pretty surprising to me | 10:27 |
| matkor | anyway how can I force resolve it ? | 10:29 |
| matkor | bzr resolved semantics_cserver.py does not help with that ... | 10:30 |
| LarstiQ | matkor: use status and diff to find out where you are, and resolve to resolve conflicts | 10:30 |
| LarstiQ | matkor: no, the message says your conflict is on semantics_cserver.py.BASE, not semantics_cserver.py | 10:31 |
| matkor | LarstiQ: Yes , I am not interested in semantics_cserver.py.* - I have valid (merged) content in semantics_cserver.py | 10:32 |
| matkor | I just want to commit it | 10:33 |
| matkor | LarstiQ: If confilict is | 10:34 |
| matkor | bzr revert semantics_cserver.py.BASE | 10:34 |
| matkor | bzr: ERROR: Path(s) are not versioned: semantics_cserver.py.BASE | 10:34 |
| LarstiQ | matkor: could you pastebin `bzr status` output please? | 10:34 |
| matkor | LarstiQ: sure , but pastebin.org seems to be dead for me, here it is http://wklej.org/id/4724/ | 10:39 |
| matkor | bzr 1.5 | 10:39 |
| * LarstiQ doesn't care _which_ pastebin it is :) | 10:39 | |
| LarstiQ | matkor: so, `bzr resolve semantics_cserver.py` doesn't remove those .BASE conflicts, what does `bzr resolve semantics_cserver.py.BASE` do? | 10:41 |
| matkor | LarstiQ: Oh, it removes from conflicting files ! Thank you very much ! | 10:44 |
| LarstiQ | matkor: no problem :) If you can give a recipe for how to reproduce this situation, that might be nice. | 10:46 |
| matkor | LarstiQ: I doubt it. I did several post unbind/bind merges and it worked great as for now ... | 10:50 |
| LarstiQ | matkor: any reason you're not using commit --local; update instead of unbinding/rebinding? | 10:51 |
| matkor | LarstiQ: Propably only my ignorance about commit --local ... Reading now how it works. | 10:52 |
| imyojimbo | can some1 please explain to me the idea of --no-trees repository, i didnt get it | 10:59 |
| AfC | imyojimbo: Branches created in it won't have Working Trees present. Gives you a way of storing lots of branches without taking up lots of space. It's just a variation. | 11:04 |
| matkor | LarstiQ: Yeah bzr commit --local is doing exactly what I wanted by doing bzr unbind commit bind cycle. Thank you very much again ! | 11:14 |
| LarstiQ | matkor: np :) | 11:16 |
| === cody-somerville_ is now known as cody-somerville | ||
| jml | jamesh: actually using testresources? | 11:46 |
| === kiko-zzz is now known as kiko | ||
| vxnick | Hi all - got a bit of a strange one here, hoping you can help | 12:09 |
| vxnick | Do you know how I can embed the revision number within a PHP file? Presumably, this would need to be done as part of a post-commit hook? | 12:10 |
| AfC | vxnick: have a look through the mailing list archive. There was recently some discussion of ids or version strings or something like that. Not sure if they were talking about a plugin or a hook or what. | 12:19 |
| vxnick | AfC: thanks - I'll take a look | 12:20 |
| LarstiQ | vxnick: how about `bzr version-info`? | 12:28 |
| vxnick | LarstiQ: that's what I thought it'd be - I found the thread in the mailing lists :-) | 12:28 |
| vxnick | I wasn't sure how I would hook this in though, as I'm not a Python dev | 12:28 |
| LarstiQ | vxnick: a good place is in your build or deployment process | 12:29 |
| vxnick | LarstiQ: I assume a hook would do this well then? I'm using PHP, so there's no build process as such | 12:31 |
| LarstiQ | vxnick: imo, doing it every commit is often not what you need, but yes, you could do that if you really wanted | 12:32 |
| LarstiQ | vxnick: no deployment proces either? | 12:32 |
| vxnick | LarstiQ: What I'm basically trying to do is add the revno into something like "version.php", so I can call it within the application | 12:33 |
| LarstiQ | vxnick: let me try to phrase the question differently. What do you plan to use that version for? | 12:33 |
| LarstiQ | vxnick: right | 12:33 |
| LarstiQ | vxnick: so, when you're developing locally, it isn't important to have that information? | 12:34 |
| vxnick | LarstiQ: I'm comfortable with the process of doing it, but I'm just not familiar enough with Python to actually do it | 12:34 |
| LarstiQ | vxnick: there isn't much python to `bzr version-info` | 12:34 |
| vxnick | LarstiQ: True, but I don't know any Python whatsoever :) | 12:34 |
| LarstiQ | vxnick: ok, there isn't _any_ python to it ;P | 12:35 |
| LarstiQ | vxnick: if the default output isn't usably, you can supply a template | 12:35 |
| awilkins | markh: Is building the .exe version hard? | 12:35 |
| LarstiQ | vxnick: see `bzr help version-info` | 12:35 |
| awilkins | markh: I'm building the python-installer version but I'd quite like to try my users on TBZR | 12:35 |
| vxnick | LarstiQ: that's fine, but what I want to do is put that (or `bzr revno`) within a Python hook which is then called upon every commit, etc | 12:36 |
| awilkins | markh: Does it preclude you using any plugins, etc? | 12:36 |
| vxnick | LarstiQ: would it be wise to use `bzr ignore` on the version file, so it doesn't artificially bump up the revno every time bzr notices it's been changed? | 12:36 |
| LarstiQ | vxnick: is this a webapp? | 12:37 |
| vxnick | LarstiQ: it could be any sort of app | 12:37 |
| LarstiQ | vxnick: ok | 12:37 |
| vxnick | LarstiQ: although, for completeness, yes | 12:37 |
| LarstiQ | vxnick: for any sort of app, I would only run version-info when you make a tarball to ship to your users | 12:37 |
| LarstiQ | vxnick: for a webapp, I would call it only when you deploy it at your server | 12:38 |
| vxnick | LarstiQ: makes sense, thanks. What about for something that's ongoing? | 12:38 |
| vxnick | LarstiQ: in the sense that it doesn't get tarred up, but rather commited to a production branch, etc | 12:38 |
| LarstiQ | vxnick: ok, so your deployment process is just committing? | 12:39 |
| vxnick | LarstiQ: basically yes | 12:39 |
| LarstiQ | vxnick: maybe you'd be better off with keyword expansion | 12:40 |
| * LarstiQ sighs | 12:41 | |
| LarstiQ | vxnick: Basically, I think it's a bad idea. | 12:41 |
| LarstiQ | vxnick: but let me see if I can cook it up | 12:41 |
| spiv | vxnick: How does committing to the branch cause the new version of your webapp to be deployed? | 12:42 |
| vxnick | LarstiQ: keyword expansion would be good enough if that's do-able | 12:43 |
| vxnick | spiv: sorry, I'm pretty new to all this so I might be wrong | 12:43 |
| vxnick | LarstiQ: I think I looked into keyword expansion a while ago but discounted it for one reason or another | 12:44 |
| LarstiQ | vxnick: my advice would be to have a discrete deployment step | 12:44 |
| vxnick | LarstiQ: what would you suggest? | 12:45 |
| === jdahlin_ is now known as jdahlin-afk | ||
| vxnick | spiv: sorry, I think I was using something like `bzr rsync` or similar to push commits to a web area | 12:46 |
| spiv | vxnick: so that's the point where you could be running bzr version-info (or whatever) to put the revision info in a php file. | 12:47 |
| vxnick | spiv: surely that'd be a hook then? | 12:47 |
| LarstiQ | vxnick: something like `bzr export path/to/production; bzr version-info --custom --template "version = {revno}" > path/to/production/version.php` | 12:47 |
| vxnick | LarstiQ: thanks | 12:48 |
| LarstiQ | and probably something more appropriate than export | 12:48 |
| LarstiQ | but that really depends on the rest of your infrastructure | 12:48 |
| vxnick | yep | 12:48 |
| vxnick | LarstiQ: do you think it's still feasible to update this version file as and when commits happen, as I've (kinda) been discussing with spiv? | 12:49 |
| LarstiQ | vxnick: doing the same as cm_version_info is a little bit more involved than trivial | 12:49 |
| spiv | vxnick: Just having a script that does "bzr version-info ... ; rsync" seems simplest to me. | 12:49 |
| LarstiQ | (in a hook) | 12:49 |
| LarstiQ | vxnick: it is possible, I just think it's useless | 12:49 |
| vxnick | LarstiQ: many thanks | 12:49 |
| spiv | vxnick: I don't know of a plugin that provides a 'bzr rsync' command, but there is a 'bzr rspush' in bzrtools I think. You could write a plugin that hooks that. | 12:49 |
| vxnick | spiv: many thanks also | 12:49 |
| LarstiQ | vxnick: but more work than a 5 minute hack for me I'm afraid | 12:49 |
| vxnick | guys - I think I'll just script it then and use that as my staging step | 12:50 |
| LarstiQ | vxnick: however, it sounds like it might be worthwhile addition to the bzr-upload plugin | 12:50 |
| spiv | vxnick: you're welcome | 12:50 |
| spiv | LarstiQ: that's true | 12:50 |
| vxnick | LarstiQ: that's what I'm using - sorry, forgot what it was called! | 12:51 |
| LarstiQ | doh :) | 12:51 |
| vxnick | LarstiQ: when I was referring to `bzr rsync` | 12:51 |
| LarstiQ | vxnick: that's excellent then :) | 12:51 |
| vxnick | thanks a lot for your help guys, much appreciated! | 12:51 |
| LarstiQ | vxnick: thank me when it actually works for you | 12:52 |
| vxnick | LarstiQ: fair enough ;) | 12:52 |
| * LarstiQ files a request on bzr-upload | 12:52 | |
| vxnick | :) | 12:52 |
| vxnick | LarstiQ: could you link me to the request once done, so I can stay in the loop | 12:54 |
| LarstiQ | vxnick: sure | 12:54 |
| LarstiQ | vxnick: nothing complex, but bug 271316 | 12:56 |
| ubottu | Launchpad bug 271316 in bzr-upload "feature-request: optionally produce a versin-info like file" [Undecided,New] https://launchpad.net/bugs/271316 | 12:56 |
| vxnick | LarstiQ: sorry, one more thing - would it be worth ignoring the version.php file, or keeping it revisioned? | 12:56 |
| vxnick | LarstiQ: cheers :) | 12:57 |
| LarstiQ | vxnick: with the bzr-upload approach, you would never have the version.php in your working tree, only in the production area, so you wouldn't have to ignore it. | 12:57 |
| vxnick | LarstiQ: gotcha | 12:57 |
| LarstiQ | vxnick: if you were to produce a version file on every commit, I'd ignore it | 12:58 |
| vxnick | LarstiQ: understood, thanks! | 12:58 |
| Leonidas | when I have a path and it is a directory, and a revision tree, how can I get the contents? Do I have to filter the inventory? | 13:01 |
| LarstiQ | Leonidas: something like bzr.dev export does? | 13:10 |
| Leonidas | LarstiQ: I am currently doing inventory.iter_entries() and filtering out InventoryDirectories + checking thether the path.startswith the director that I want to check. | 13:12 |
| Leonidas | s/director/directory/ | 13:12 |
| LarstiQ | Leonidas: bzrlib.export._export_iter_entries does: 'subdir_id = inv.path2id(subdir); entries = inv.iter_entries(subdir_id)' | 13:13 |
| Leonidas | I'm looking for something like inventory.get_path_subitems('mydirectory/myotherdirectory/') or something like this. | 13:13 |
| Leonidas | LarstiQ: looks good, I'll try it after lunch, thanks! | 13:13 |
| awilkins | Verterok: Ignore that patch until I can make it pass tests ;) | 13:41 |
| speakman | will bzr-trac support --fixes soon? | 14:06 |
| LarstiQ | does bzr-trac still exist? | 14:07 |
| speakman | hopefully it does :) | 14:07 |
| speakman | latest commit 2008-08-31 | 14:08 |
| LarstiQ | okay :) | 14:09 |
| LarstiQ | speakman: I'd take it up with whomever is working on it then. | 14:10 |
| === mw|out is now known as mw | ||
| speakman | I think they're inhere. Afaik the project doesn't have it's own irc chan. | 14:19 |
| LarstiQ | speakman: there seem to be multiple projects doing bzr-trac integration, which one did you mean? | 14:22 |
| speakman | https://launchpad.net/trac-bzr - where do you find more? | 14:22 |
| LarstiQ | https://launchpad.net/bzr-trac is one | 14:23 |
| LarstiQ | speakman: I'd probably ask a question on that project then | 14:24 |
| LarstiQ | but it is surprising to me it doesn't already work | 14:25 |
| LarstiQ | speakman: https://bugs.edge.launchpad.net/trac-bzr/+bug/120470 | 14:25 |
| ubottu | Launchpad bug 120470 in trac-bzr "Support for bug-fixed metadata" [Wishlist,Triaged] | 14:25 |
| === mw is now known as mw|brb | ||
| speakman | thanks. can I push for a certain wish on launchpad? | 14:28 |
| LarstiQ | speakman: add a comment to that bug asking for that status :) | 14:28 |
| LarstiQ | speakman: and well, if you add a patch that implements the feature, that should bump it up ;) | 14:29 |
| speakman | if I was skilled enough I would ;) | 14:31 |
| === mw|brb is now known as mw | ||
| VSpike | Got a situation where even after a commit bzr st shows a change. But when I try to commit again, it says there are no changes to commit | 15:27 |
| VSpike | Change is a directory being removed | 15:27 |
| VSpike | What can I do? Or should I just ignore it and hope it goes away? | 15:28 |
| grutte_pier | depends on the change that bzr st shows | 15:31 |
| VSpike | grutte_pier: it shows "removed: images/Devices/" | 15:31 |
| VSpike | grutte_pier: that has persisted through the last couple of commits | 15:32 |
| VSpike | right now it's the only change in the list | 15:32 |
| bob2 | have you only been doing selective commits? | 15:32 |
| VSpike | no | 15:33 |
| grutte_pier | vspike: I'm trying to reproduce your situation, but maybe you have been deleting stuff using system rm instead of bzr rm? | 15:33 |
| fullermd | I always delete stuff with system rm, and I've never seen that happen. | 15:33 |
| grutte_pier | actually... I notice now as well that bzr seems smart enough to delete files that are not present anymore from the branch as well | 15:34 |
| grutte_pier | that's nice! I don't think other VCS can do that | 15:34 |
| uws | VSpike: What happens if you try "bzr commit images/Devices" ? | 15:34 |
| VSpike | It's windows, which may be an issue. I renamed the directory from "Devices" to "devices". I then did "bzr move --after images/Devices images/devices" | 15:36 |
| fullermd | That sounds like a source of trouble... | 15:36 |
| fullermd | I'd move it back, then bzr mv it. | 15:36 |
| grutte_pier | and if that works, file a bug, because it _should_ work according to the help I guess :P | 15:37 |
| LarstiQ | it should | 15:37 |
| LarstiQ | VSpike: which version of bzr? | 15:37 |
| grutte_pier | but how is windows with case? | 15:38 |
| bob2 | useless | 15:38 |
| bob2 | preserving but not distinguishing | 15:38 |
| VSpike | yeah, i can imagine case could be a windows specific issue. Sometimes it matters, sometimes it doesnt | 15:38 |
| grutte_pier | right.... so maybe Devices and devices look like the very same dir to begin with?? causing bzr commit to state that no changes have to be committed? | 15:39 |
| grutte_pier | and maybe bzr st Does see this, because it is slightly different implemented? | 15:39 |
| VSpike | how can i query the detailed history of a file? | 15:39 |
| * grutte_pier is just guessing | 15:39 | |
| grutte_pier | vspike: i guess bzr branch-history should work (from the bzrtools plugin) | 15:40 |
| LarstiQ | VSpike: bzr log <file> | 15:40 |
| gour | hi, i've to work on some web sites all based on same codebase (cms made simple). does it make sense to use one shared repo with branches representing different sites and/or different states like production/test etc. ? | 15:50 |
| VSpike | Sorry, just trying to figure out how to install bzrtools on cygwin :) | 16:00 |
| awilkins | Verterok: ping? | 16:07 |
| grutte_pier | gour: i guess that's precisely what vcs is supposed to do...... | 16:07 |
| LarstiQ | gour: yes | 16:08 |
| grutte_pier | vspike: bzr log probably does what you actually want (I forgot the most obvious :P ) | 16:08 |
| gour | thanks. | 16:09 |
| VSpike | grutte_pier: any idea where that hides in windows? :) | 16:09 |
| VSpike | (Not cygwin - I've just switched from windows version to cygwin, but those commits were made under windows) | 16:10 |
| VSpike | Just doing "bzr diff images/ -r 54..55" which is the relevant commit shows this http://pastebin.com/m7d771fe3 | 16:12 |
| VSpike | so it added the directory with the new name (images/devices) and renamed each file in the old directory (/images/Devices/) to the new location, but did nothing with the old directory itself | 16:13 |
| VSpike | So I can see why it's reporting it as removed | 16:13 |
| VSpike | What is strange is why commit won't commit it, and I guess that is probably to do with case | 16:14 |
| Verterok | awilkins: pong | 16:14 |
| pysquared | Hi, I'm evaluating bazaar for use in our company, and like it a lot. However I cannot figure out how to combine 2 branches that have no common ancestor. Anyone help please? | 16:15 |
| awilkins | Verterok: Hi there, I'm trying to get the tip of bzr-eclipse working on Callisto by merging my previous "remove the non-callisto bits" patch | 16:15 |
| awilkins | Verterok: What's the dependency on org.eclipse.core.expressions 3.2.100 ? | 16:16 |
| Verterok | awilkins: hi! | 16:16 |
| Verterok | let me check | 16:16 |
| Verterok | I think, that nothing depends on expresions :) | 16:16 |
| awilkins | Verterok: I've fixed a bunch of windows-specific issues in the client library (I made all the status methods return forward-slashes regardless of platform because that's what the CLI client does) | 16:17 |
| awilkins | Verterok: I can't get it to start and the preferences page is unavailable | 16:17 |
| pysquared | The only thing that "works" so far is to create an empty branch to be used as the basis for all new branches I ever create, which then allows for possible future merging. | 16:17 |
| Verterok | awilkins: great, patches are more than welcome. :) | 16:18 |
| pysquared | I come from CVS, so I guess the confusion is natural | 16:18 |
| awilkins | Verterok: I think it still has issues when the default implementation of "bzr" is not "bzr" on the PATH | 16:18 |
| Verterok | awilkins: I 've been working on the client also, adding support for pending merges in the status and some enhancements in the xmlrpc client interface | 16:18 |
| Verterok | awilkins: what do you mean with 'bzr is not bzr'? :) | 16:19 |
| awilkins | Verterok: On windows, my default implementation is "c:\python25\scripts\bzr.bat" | 16:20 |
| jelmer | pysquared, hi | 16:20 |
| jelmer | pysquared: You can merge one into the other by using something like "bzr merge -r1..-1 <other>" | 16:21 |
| jelmer | pysquared, or if one should be a subdir of the other, you can use "bzr join" | 16:21 |
| LarstiQ | -r0..-1 that is | 16:21 |
| awilkins | Verterok: I think at some point bzr-eclipse became unable to configure itself unless it can find bzr... which it can't | 16:21 |
| Verterok | awilkins: ah, I get it. I fixed some issues with bzr.bat a few weeks ago. (when the path to bzr.bat contains spaces) | 16:21 |
| jelmer | ah, right - thanks, LarstiQ | 16:21 |
| LarstiQ | pysquared: but merging branches that have no common ancestor is a very unusual thing to do | 16:21 |
| LarstiQ | pysquared: so if you find yourself doing that a lot, I'd take a step back and look at your workflow | 16:22 |
| awilkins | Verterok: I think I've got that ; I'm running off tip of trunk with a small anti-europa patch | 16:22 |
| Verterok | awilkins: at the preference page, bzr-eclipse needs bzr to test if the xmlrpc service can be run, and if xmloutput is installed, etc | 16:23 |
| pysquared | Thanks, will check out "join" now. | 16:23 |
| Verterok | awilkins: do you have a stacktrace? | 16:23 |
| awilkins | Verterok: Those things pass when running the library | 16:23 |
| awilkins | Verterok: Alas, no, it just fails | 16:23 |
| pysquared | I have a CVS repo with a tree of various sized projects in, some dependent on others. I was wondering if I could start small, and bazaarify a subtree at a time, and then combine them later. | 16:24 |
| awilkins | Verterok: I saw the pretty new menu once, then it spewed the "requiremnts update" dialog once, as well as the "this operation is not enabled" and the menu is greyed now | 16:25 |
| Verterok | awilkins: the dependecy update popup use the IWorkbenchBrowserSupport | 16:26 |
| Verterok | awilkins: maybe in callisto is different to show a browser? | 16:26 |
| awilkins | Verterok: Aha, it is trying "bzr" and not working, I just got a stack dump in another plugin | 16:27 |
| awilkins | http://pastebin.ubuntu.com/47792/ | 16:27 |
| Verterok | awilkins: the "revision-info" patch is the one I should ignore? | 16:28 |
| LarstiQ | pysquared: random subtrees don't work very well as branch units, but distinct projects are a very good choice for that | 16:28 |
| awilkins | Verterok: You may as well, It's included in the second one | 16:28 |
| awilkins | I think | 16:28 |
| VSpike | damn.. even bzr commit --unchanged doesn't fix it :/ | 16:28 |
| Verterok | awilkins: ok, I'm looking the second one ATM | 16:28 |
| LarstiQ | VSpike: can you move the directory back to what it was? | 16:29 |
| awilkins | Verterok: No prefs page in the Team prefs for Bazaar | 16:29 |
| Verterok | awilkins: hmm, it seems that it can't find the bzr file in Scripts/bzr | 16:29 |
| VSpike | LarstiQ: what about the files in it? | 16:29 |
| LarstiQ | VSpike: just move the entire dir | 16:30 |
| VSpike | LarstiQ: with bzr mv or just mv? | 16:30 |
| LarstiQ | VSpike: just mv | 16:30 |
| LarstiQ | VSpike: this is exploratory in nature, not a fix yet | 16:30 |
| awilkins | Verterok: I thought this was to do with the difference between the length of the list of args | 16:30 |
| pysquared | Well, I got this to work: banana$ bzr merge -r0..-1 ../apple (thanks jelmer) | 16:31 |
| VSpike | LarstiQ: http://pastebin.com/mcb8e143 | 16:31 |
| * LarstiQ blinks | 16:32 | |
| grutte_pier | vspike: I'm getting confused a bit | 16:32 |
| LarstiQ | VSpike: and what does bzr st show if you move Devices to devices again? | 16:32 |
| LarstiQ | VSpike: this is not the output I'd expect with what you just told us | 16:32 |
| grutte_pier | vspike: I don't manage to reproduce your situation | 16:32 |
| Verterok | awilkins: it would be great to have the value of cmdLine | 16:33 |
| jelmer | pysquared: you're welcome | 16:33 |
| VSpike | http://pastebin.com/d4fb79800 | 16:33 |
| grutte_pier | well, that pastebin makes sense | 16:34 |
| grutte_pier | because you didn't yet do the bzr mv --after in that one | 16:34 |
| awilkins | Verterok: I'm just trapping it ; it's probably to do with cmdLine having 1 more element on windows using the batch file | 16:34 |
| awilkins | Verterok: cmdLine is "bzr","xmlversion", "--short" | 16:35 |
| Verterok | awilkins: mmm, that's bad | 16:35 |
| Verterok | awilkins: that's the default value | 16:35 |
| awilkins | Verterok: This is the default config ; problem is, if it doesn't survive this first check, it doesn't work | 16:35 |
| LarstiQ | VSpike: this is rather weird | 16:35 |
| grutte_pier | vspike: but if i try to do something similar on some test-stuff, I also get a: unknown: image/device | 16:36 |
| awilkins | Verterok: Let me hop through and see if it's called again | 16:36 |
| Verterok | awilkins: I'll try to replicate the config and debug it | 16:36 |
| awilkins | Verterok: That's interesting, it's getting called from an SVN provider | 16:37 |
| grutte_pier | vspike: did you by any change add the image/devices dir with bzr add, before you did the sysm mv command? | 16:38 |
| VSpike | grutte_pier: yes, I would think so - it won't let you do the move otherwise | 16:38 |
| VSpike | Oh.. system move | 16:39 |
| VSpike | Nope | 16:39 |
| VSpike | Looking back at logs, I think the sequence was: create new dir, system mv files from old dir to new, bzr add --no-recurse <new dir>, bzr mv --after each file <oldpath> <newpath> | 16:40 |
| LarstiQ | VSpike: ah | 16:41 |
| LarstiQ | VSpike: I'm not sure how well it would deal with that | 16:41 |
| VSpike | So i did bzr mv --after for each file in the directory, and I bzr add'ed the new dir, but didnt remove the old one | 16:41 |
| Verterok | awilkins: hmm, that's weird | 16:41 |
| VSpike | LarstiQ: I don't think I've had problems with that when the names differ by more than case | 16:41 |
| LarstiQ | grutte_pier: mind trying to reproduce it that way? Ie, version files in old, commit, mkdir new, mv old/* new/*; bring files under version control in new, and then bzr mv --after old new | 16:42 |
| Verterok | awilkins: about the ..core.expresion dependency, it's used in the refresh command hook: RefreshExecutionListener | 16:42 |
| VSpike | LarstiQ: it's something I do quite often - move files around, then try and tell bzr about it after the fact | 16:42 |
| LarstiQ | VSpike: could be, I don't know what the code does atm, but I can see it having two sets of fileids it needs to resolve | 16:42 |
| LarstiQ | VSpike: right, just system mv and bzr mv --after, or also bzr add before the after? | 16:43 |
| VSpike | LarstiQ: have to bzr add, otherwise it bitches at you that the target is not versioned | 16:43 |
| awilkins | Verterok: Is there a reason why the version is at 3.2.100 ; I can't find a package that has that version in the Callisto updates but the version number looks callisto-ish | 16:43 |
| LarstiQ | VSpike: ok | 16:43 |
| VSpike | LarstiQ: hence the --no-recurse (which I recently discovered) otherwise it adds all the files too in the new location, and you have to then bzr remove each one before you can do the bzr mv | 16:44 |
| grutte_pier | vspike: it's on win right? On linux mv old/* new/* is not allowed :P | 16:44 |
| grutte_pier | vspike: mv old new is allowed, but that places the old as a subdir in new | 16:44 |
| Verterok | awilkins: there is no reason, it's just the version available in 3.4 | 16:45 |
| VSpike | grutte_pier: I did it with a gui tool :) | 16:45 |
| BasicOSX | Would be nice if there was a section on the bzr web page with template for tailor configuration for converting other RCS repos to bzr repos | 16:45 |
| LarstiQ | VSpike: doh, I overlooked the --no-recurse. Yeah, that is exactly what I had in mind. | 16:45 |
| grutte_pier | vspike: i think i need to cp instead of mv :P | 16:45 |
| LarstiQ | BasicOSX: well, tailor isn't exactly the most recommended solution | 16:45 |
| BasicOSX | LarstiQ: oh? What is recommend for darcs to bzr? | 16:46 |
| LarstiQ | BasicOSX: ok, specifically for darcs tailor is :) | 16:46 |
| BasicOSX | heh :-) | 16:46 |
| LarstiQ | unless there is darcs-fastexport now? | 16:46 |
| Verterok | awilkins: starting in a fresh workspace seems to work in *nix (actually OS X) | 16:47 |
| Verterok | awilkins: I'll start a VM in my Linux box try this on windows | 16:47 |
| awilkins | Verterok: not here ; I shall apply my (evil) patch and see if this fixes it | 16:47 |
| awilkins | Verterok: In a dead HEAD I have a patch that patches the preference initializer to use a valid path on Windows | 16:48 |
| BasicOSX | LarstiQ: looks to be a fastimport | 16:48 |
| awilkins | Verterok: Ok, if you cheat and use a valid path it works fine | 16:49 |
| Verterok | awilkins: mm, ok. bzr is not a valid path in windows? :) | 16:50 |
| awilkins | Verterok: Try patching org.vcs.bazaar.eclipse.PreferenceInitializer to use a bad name like "bzr_chicken" and see it it works on *nix | 16:50 |
| awilkins | Verterok: Windows doesn't read #! and work out what to pass a file to | 16:51 |
| grutte_pier | vspike,larstiq: I can't reproduce it that way; the olddir is placed as subdir in newdir | 16:51 |
| * Verterok try that | 16:51 | |
| awilkins | Verterok: I'm not even sure that you can use ProcessBuilder.start() without an absolute path | 16:52 |
| jam | vila: poke with a soft stick | 16:52 |
| awilkins | Verterok: You should at least be able to access the prefs page to set it up properly, but I think it's a chicken and egg scenario ; can't set up a valid config without a valid config | 16:53 |
| vila | jam: ponk ? | 16:53 |
| jam | good afternoon :) | 16:53 |
| vila | hi ! :D | 16:54 |
| LarstiQ | grutte_pier: mv old/* new/ ? | 16:54 |
| Verterok | awilkins: ok. so we need to check if the config invalid, and show the pref page anyway | 16:54 |
| jam | I just wanted to verify | 16:54 |
| VSpike | I can reproduce it | 16:54 |
| jam | bug #233817 is bzr-1.8 not 1.7, right? | 16:54 |
| VSpike | It is dependant on case | 16:54 |
| ubottu | Launchpad bug 233817 in bzr "missing doesn't show merged revisions" [High,Fix released] https://launchpad.net/bugs/233817 | 16:54 |
| vila | jam: checking | 16:55 |
| grutte_pier | vspike,larstiq: I do remember that windows way of moving is quite different than *nix... since I'm on the latter | 16:55 |
| * LarstiQ nods | 16:55 | |
| LarstiQ | grutte_pier: I'm on *nix myself | 16:55 |
| grutte_pier | vspike: but how many commits did you do after rev 54? What if you revert to the latter? and then use proper bzr commands do move the files around?? | 16:56 |
| awilkins | Verterok: I have to catch a train now, but I'll touch bases with you later. | 16:57 |
| grutte_pier | larstiq,vspike: so i set up a Device-dir with two files, which was commited to the branch, then created a device dir, --no-recurse added the thing and moved Device/* to device | 16:59 |
| VSpike | grutte_pier, LarstiQ : http://pastebin.com/m1d98a78e | 17:00 |
| grutte_pier | larstiq,vspike: at this time bzr st says: removed: Device/file1 Device/file2 unknown: device/file1 device/file2 | 17:00 |
| grutte_pier | aah, let's check that pastebin first :P | 17:01 |
| VSpike | it works under linux: http://pastebin.com/m12a59bda | 17:05 |
| VSpike | Just seems like a Windows issue with case of file names | 17:05 |
| VSpike | (possibly insert "yet another" in there somewhere) | 17:05 |
| VSpike | It may make a difference, but the windows version is 1.5 | 17:07 |
| VSpike | Using a newer version after the fact doesn't seem to change anything | 17:08 |
| VSpike | Let me try in Cygwin with 1.61 | 17:08 |
| grutte_pier | vspike: I have indeed just repeated all your steps, but the last bzr st gives just nothing | 17:09 |
| grutte_pier | vspike: what's weird though, is that I also get an explicit warning 'missing old' on the second commit | 17:10 |
| VSpike | grutte_pier: on linux or windows? | 17:10 |
| grutte_pier | linux | 17:11 |
| VSpike | grutte_pier: on linux with the latest version, the last bzr st gives me nothing too | 17:11 |
| grutte_pier | vspike: there is another difference: i get: 'deleted old' in the output of the second ci | 17:12 |
| grutte_pier | vspike: you don't have that, so the ci doesn't remove the old/ dir | 17:12 |
| LarstiQ | VSpike: I'll boot up my windows laptop after I get back from training | 17:12 |
| VSpike | grutte_pier: did you see my second pastebin? http://pastebin.com/m12a59bda | 17:12 |
| * LarstiQ is afk for a while | 17:12 | |
| VSpike | grutte_pier: I get the same as you.. it shows "deleted old" | 17:13 |
| VSpike | on linux that is | 17:13 |
| grutte_pier | i get more and more convinced that this indeed some strange case-problem | 17:13 |
| VSpike | Agreed | 17:14 |
| grutte_pier | vspike: to me it seems a very academic situation though.... why not move the whole dir at once instead of moving first the dir and then seperately moving the files? | 17:15 |
| grutte_pier | wait.... without the 'not' :P | 17:15 |
| fullermd | Eh? How can you move the dir then separately move the files? Where are the files in the middle? :p | 17:15 |
| grutte_pier | aah, that's wrong choice of words...... | 17:16 |
| grutte_pier | why would you set up a new dir, which you add seperately to the branch, and then mv the files explicitly to that new dir | 17:16 |
| grutte_pier | if you can also just bzr mv the whole thing at once...... | 17:16 |
| fullermd | Well, they're semantically different operations; it depends on which you want to do. But usually, you'd want to move the dir... | 17:17 |
| grutte_pier | well, I guess the thing in http://pastebin.com/m12a59bda is in the end just a move I would say?? | 17:18 |
| VSpike | grutte_pier: true, "bzr mv --after old Old" is permissible, does the right thing, and works as expected on windows | 17:19 |
| VSpike | so yeah, I'd say it was a better way to do it | 17:19 |
| VSpike | Still probably counts as a bug though :) | 17:20 |
| grutte_pier | but still... during the commit, apparently bzr does not delete a dir(maybe file) on Win if there is another file that has the same name except case | 17:21 |
| grutte_pier | that's still a bug I would say, yes | 17:21 |
| fullermd | No, that's a move of a file into a different (new) directory, and removal of an old directory. That's a different thing that keeping a file in the same directory, and moving the directory. | 17:21 |
| fullermd | But anyway, I always think of move --after like a barbed-wire necklace :p | 17:21 |
| grutte_pier | same here.... outsjj | 17:21 |
| VSpike | if you are working in a command line enviroment it would be more natural to use bzr mv, but my dev environment gives me a file-manager like tree of the project files, so the natural way to move things around is with that | 17:22 |
| VSpike | Then you have to reconcile it with the source control afterwards | 17:22 |
| VSpike | No-one would voluntarily use the windows command line if an alternative were available :) | 17:23 |
| grutte_pier | yep..... time for TortoiseBzr?? :P | 17:23 |
| === kiko_ is now known as kiko-fud | ||
| grutte_pier | vspike: but have by now managed to repair the branch? | 17:25 |
| grutte_pier | +you | 17:25 |
| * grutte_pier is off to get some food | 17:31 | |
| VSpike | grutte_pier: yeah fixed it | 17:31 |
| VSpike | thanks | 17:31 |
| VSpike | had to go bzr mv it to tmp/ and commit, then bzr mv it to devices/ and commit | 17:32 |
| grutte_pier | 'it' being the Devices/ dir? | 17:35 |
| VSpike | If I want to check the latest windows version before filing a bug, should i try 1.7rc1 or 1.6.1? | 17:36 |
| VSpike | grutte_pier: yep | 17:36 |
| grutte_pier | vspike: 1.6.1 is the latest 'stable' version, but 1.7rc1 has even more bugs fixed.... but my suspicion is that this bug is not fixed in any, so I'd probably try the 1.7rc1 | 17:41 |
| VSpike | grutte_pier: thanks.. glad you said that, cos I just d/l and installed it:) | 17:41 |
| imyojimbo | guys, i need your advice. im about to push my project to launchpad. Im developing using Visual Studio and im not sure what to do about the ide files vs put in my project files (some settings files). should i ignore them, or u think i should version them too? | 17:52 |
| === bac is now known as bac-lunch | ||
| VSpike | imyojimbo: which files? As a rule, you want it so that everything required to build your code is included. Someone should be able to check out and build your project and end up with the same result that you did. | 18:08 |
| VSpike | imyojimbo: i don't version .suo files, because they seem to be automatically regenerated if missing | 18:09 |
| VSpike | imyojimbo: .csproj and .sln file I include | 18:09 |
| === bac-lunch is now known as bac | ||
| === kiko-fud is now known as kiko | ||
| imyojimbo | VSpike are u there? | 18:44 |
| NfNitLoop | I'm doing `bzr branch http://host/svn/repo/trunk` and getting the error SubversionException "REPORT request failed on [the latest version]." | 18:51 |
| NfNitLoop | Has anyone seen this before? | 18:51 |
| NfNitLoop | trunk/ checks out fine via svn. | 18:52 |
| === thumper_laptop is now known as thumper | ||
| NfNitLoop | and the changes in that rev are pretty minor. (just a few lines in a file.) | 18:53 |
| === mw is now known as mw|food | ||
| === sabdfl1 is now known as sabdfl | ||
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| === mw|food is now known as mw | ||
| bpierre | hi | 22:03 |
| NfNitLoop | h'lo. | 22:04 |
| bpierre | LarstiQ: I've branched https://code.launchpad.net/~larstiq/bzr/nested-trees, how do I use it? I've created a shared repository with the development0-subtree format, and 2 branches inside, how do I nest one of the branch in the other? | 22:06 |
| === kiko is now known as kiko-afk | ||
| === thumper_laptop is now known as thumper | ||
| === mark1 is now known as markh | ||
| === bac is now known as bac_afk | ||
| === thumper_laptop is now known as thumper | ||
| poolie | hello | 23:12 |
| beuno | gooooooooooood morning poolie | 23:13 |
| Spaz | afternoon | 23:13 |
| lifeless | what where when, did I sleep through to the avo?! | 23:14 |
| beuno | evening lifeless | 23:14 |
| beuno | :) | 23:14 |
| poolie | jam, hi | 23:15 |
| lifeless | 43 tests to go | 23:19 |
| poolie | to where? | 23:19 |
| LeoNerd | Aren't these things traditionally on a wall, to be taken down and passed around one at a time? | 23:24 |
| jam1 | test | 23:58 |
| Peng_ | jam1: Hiya | 23:58 |
| === jam1 is now known as jam | ||
| Peng_ | Whatcha testing? | 23:59 |
| jam | My nick :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!