| spm | http://www.drive.com.au/used-cars/lotus/elise/sydney/detail.aspx?id=28665759&lid=28665759&pg=1&pp=3&d=0&SG=-648505432&pt=1 <== poolie, is there something you're not telling us? | 05:36 |
|---|---|---|
| poolie | :) | 05:37 |
| poolie | http://www.carsales.com.au/all-cars/dealer/details.aspx?Cr=0&R=10735936&keywords=&trecs=200057&__sid=131D45747131&__Ns=pCar_PriceSort_Decimal|1||pCar_RankSort_Int32|1||pCar_Make_String|0||pCar_Model_String|0&__Qpb=1&tsrc=allcarhome&__Nne=15&seot=1&__N=1216%201246%201247%201252%201282&silo=1011# | 05:38 |
| spm | some missed a decimal place.... | 05:41 |
| poolie | i don't know about them | 06:33 |
| poolie | it seems very oddly specific | 06:33 |
| spm | algorithmic updates gone bad? | 06:48 |
| poolie | could be | 06:50 |
| poolie | some weird attempt at SEO by making them sort to the top? | 06:50 |
| jam1 | morning all | 07:05 |
| === jam1 is now known as jam | ||
| poolie | hi jam | 07:16 |
| vila | hey jam, hey gang ! | 07:23 |
| Riddell | hola | 07:32 |
| jelmer | Goeiesmorgens deze morgen! | 07:37 |
| poolie | hi riddell, jelmer | 07:46 |
| Merwin | Hi. I just did a merge and got a "Contents conflict" in some files, but there is no ">>>" things to resolve in the file, and only a .BASE and .OTHER files, what should I do ? | 07:52 |
| poolie | Merwin: it may have been added with different contents on different branches | 07:54 |
| poolie | so see if they're different | 07:54 |
| poolie | then probably 'bzr mv foo.BASE foo' and then edit it to taste | 07:54 |
| Merwin | ok I'll make a diff on BASe and OTHER to check | 07:54 |
| Merwin | There is a difference, something changed in .OTHER | 07:56 |
| Merwin | Isn't it better to take .OTHER as reference ? | 07:56 |
| Merwin | I meav, replace xxx with xxx.OTHER? | 07:58 |
| Merwin | mean* | 07:58 |
| mgz | morning all | 08:03 |
| Riddell | good morning Norwich | 08:09 |
| mgz | :) | 08:15 |
| poolie | hi mgz | 08:26 |
| mgz | does the package importer still need sorting out? | 08:35 |
| poolie | in general yes :) | 08:35 |
| poolie | i'm not aware of any critical issues but i also haven't looked today | 08:35 |
| poolie | i think dpkg did import | 08:36 |
| mgz | okay. | 08:38 |
| jelmer | poolie, mgz: thanks for the reviews! | 09:18 |
| jelmer | I managed to get the number of failing tests from running bzr's interface tests against bzr-svn down to 9 over the weekend | 09:19 |
| jelmer | with 3 underlying remaining issues, one of which is the get_revision_delta thing I mailed the list about | 09:19 |
| mgz | Riddell: how do we land things for qbzr? merge to trunk and push? | 09:19 |
| mgz | jelmer: cool | 09:19 |
| awilkins | jelmer, How well does the gnome-keyring support in bzr-gtk work with bzr-svn ? | 09:27 |
| Riddell | mgz: yes just so, no pqm or the like | 09:27 |
| mgz | thanks! | 09:28 |
| jelmer | awilkins: IIRC there were some issues, somebody worked on a patch to improve it but I'm not sure what the status of that is | 09:32 |
| jelmer | awilkins: https://code.launchpad.net/~chy-causer/bzr-gtk/fix-svn-keyring/+merge/60817 | 09:32 |
| awilkins | jelmer, I think I've avoided this so far because something always forces plaintext auth storage in SVN, but I've just installed oneiric and I don't think that thing has forced this yet | 09:35 |
| awilkins | Comparing the ~/.subversion auth configs for this repo, the old one uses plain, the new one uses gnome-keyring, and my old SVN config has an empty list for the password stores (which I think is set by something that prompts you to do so automatically) | 09:37 |
| awilkins | Shall try this patch, it's v.small | 09:38 |
| jelmer | awilkins: please do comment on whether the patch works for you | 09:40 |
| jelmer | I should really take some time to review it | 09:40 |
| awilkins | jelmer, It didn't work for me ; but it may be because I'm using an explicit svn+https:// url | 09:46 |
| awilkins | jelmer, I need to look and see but for now I've reverted the SVN config back to the old plain auth file | 09:47 |
| jelmer | awilkins: ok, thanks for letting me know | 09:47 |
| awilkins | jelmer, Have to use that explicit URL because this repo emits server errors instead of 404s if you as for .bzr smart URIs | 09:48 |
| jelmer | awilkins: have you tried https recently? bzr-svn now probes before the bzr smart server | 09:48 |
| awilkins | Not tried that recently, I'll have to have a go at it | 09:48 |
| mgz | ha, I'm not actually a member of qbzr developers | 09:51 |
| mgz | perhaps I should ask Alexander if I can join. | 09:51 |
| jelmer | mgz: you should :) | 10:04 |
| awilkins | jelmer, Here's a case - another user is using SVN to perform merges outward from trunk. Have pulled his branch and subsequently merged outward also ; lots of "duplicate" conflicts. Looking in the SVN log, the files were copied correctly by the SVN merge (as hardlinks in the SVN FSFS) and preserve history - they should have the same file-id and not conflict, no? | 10:35 |
| jelmer | awilkins: no, as bzr doesn't support copies | 10:35 |
| awilkins | jelmer, But it does support adding files to separate branches with the same file-id ; it should already know about these files in the repository because they are copies from a branch I have already pulled. | 10:37 |
| awilkins | They are not copies within the scope of the branch, they are copies from the other branch for the purposes of the merge outward by the SVN client | 10:37 |
| jelmer | awilkins: sure, but they have a different file id - and file ids are the only thing that's used to prove that two files are in fact the same by bzr merge | 10:38 |
| jelmer | awilkins: until copy support is added to bzr, I don't see how this would work | 10:39 |
| awilkins | jelmer, Should it be possible to assign them the same file id though - SVN knows the file is a copy ; if in that case, we assign the file-id based on the copied-from file rather than the place it was copied to, the file-id will be the same (if the file is not modified at the same time it is copied, it is the same file - right down to the inode in the SVN repository) | 10:40 |
| jelmer | awilkins: bzr-svn doesn't have access to the inode information in the svn repository, that's not exposed by the svn protocol | 10:40 |
| jelmer | awilkins: it could do analysis to see if the file was only copied and then scan history to see no other copies are left around | 10:41 |
| awilkins | jelmer, the svn log viewer knows it's a copy from a particular branch / revision | 10:41 |
| awilkins | Would it be possible to infer from that? | 10:41 |
| jelmer | awilkins: yes, but we can only keep the file id if it is the *only* copy | 10:41 |
| jelmer | and that's the tricky bit | 10:41 |
| awilkins | Does that hold for the more specific case "we can keep the file id if it is the only copy in the current inventory" ? | 10:44 |
| jelmer | awilkins: yes, but note that it can be hard to determine that too | 10:45 |
| awilkins | I feel like I'm missing something - the inventory has the list of all it's file-ids in .. what's the difficult case (I know too little about internals) | 10:46 |
| jelmer | awilkins: what if a file is being copied in from elsewhere, how do you know its file id? | 10:46 |
| jelmer | awilkins: you have to do the same analysis all over again for all inventories it has ever been part of | 10:47 |
| jelmer | awilkins: and at each step determine whether or not it could keep its id | 10:47 |
| awilkins | This is becoming more complex than I have time for... :-( git does better at this because the objects are the same (same content) but of course not at explicit renaming. | 10:49 |
| jelmer | right | 10:50 |
| awilkins | But I prefer bzr-svn because it makes pushing much less ... fraught | 10:50 |
| jelmer | git doesn't store renames or copies and always infers them later on, so it doesn't matter how they were in svn | 10:50 |
| awilkins | I don't like the git-svn design of storing metadata in the git commit log which is an effective rewrite of your git branch which ruins it for sharing with people | 10:50 |
| jelmer | bzr should support inferring renames from copies (that's basically what you're asking for), but I really think that support should be in bzr core, and not in bzr-svn | 10:50 |
| jelmer | and that shouldn't have to involve the file ids staying the same, as keeping the file ids the same has a lot of performance impact | 10:51 |
| awilkins | I shall just have to browbeat the person doing the merges into using bzr :-) | 10:52 |
| awilkins | For the time being.... | 10:52 |
| jelmer | awilkins: did you see my last few lines? | 11:16 |
| awilkins | The bit about inferring renames from copies? | 11:24 |
| awilkins | Last log I have from you was at 1100 UTC when you rejoined the channel | 11:25 |
| awilkins | jelmer, Sorry, forgot to prefix see above ^ | 11:26 |
| jelmer | <jelmer> awilkins: it's one of the things I would really like to work on, and we're slowly getting rid of the assumptions in the code that two files that are the same necessarily have the same file id everywhere | 11:34 |
| jelmer | <jelmer> that is, not abandoning file ids to prove equivalency in inter-tree operations, but allowing them to be different despite two files being the same | 11:34 |
| awilkins | jelmer, So a slightly more enlightened merge that knows two files with the same path and same content but with different file-id might not be a merge conflict? | 11:37 |
| jelmer | awilkins: right | 11:37 |
| Riddell | how can I forcibly create the conditions where I have to run bzr break-lock? | 11:52 |
| Riddell | the bzr server seems very good at not lockings, it seems I can even push to the same repository from two places at the same time | 11:53 |
| jelmer | Riddell: I suspect just opening a write lock and not unlocking should be sufficient | 11:55 |
| jelmer | Riddell: have you looked at bzrlib/tests/blackbox/test_break_lock.py for inspiration? | 11:56 |
| Riddell | good idea | 11:59 |
| spiv | Riddell: python -c "from bzrlib.bzrdir import BzrDir; b = BzrDir.open('some/path').open_branch(); b.lock_write(); b.leave_lock_in_place()" | 12:12 |
| mgz | ah, neat spiv, I thought it was more of a pain than that. | 12:16 |
| Riddell | spiv: thanks, I'd worked that out :) | 12:23 |
| vila | hu ho, what happened to the package importer ? | 12:50 |
| vila | mgz: any idea ^ ? | 12:54 |
| vila | It looks like someone killed it. Should I just restart it ? | 12:55 |
| mgz | vila: I stopped it as part of the release process | 13:04 |
| vila | oh, ok | 13:04 |
| mgz | and after build-distro failed, no one was sure if it was safe to restart or not | 13:04 |
| vila | what's build-distro ? An lp thing ? | 13:05 |
| mgz | so, it's waiting for someone who knows what they're doing to take over | 13:05 |
| mgz | yeah, basically making new branches for the P-series | 13:05 |
| vila | hmm, I think wgrant did it last time | 13:06 |
| vila | probably sleeping right now | 13:06 |
| mgz | I have a log of the output that gnuoy got, with some warnings about stacking then an uninformative error at the end | 13:06 |
| mgz | wgrant is who told me to look at the log. | 13:07 |
| mgz | so, I guess we still don't have anyone who actually understands this? :) | 13:07 |
| vila | oh, so something failed on lp, ok | 13:07 |
| vila | hmm | 13:07 |
| mgz | I think I worded my question about this to poolie poorly this morning, he didn't seem to think there was an issue | 13:19 |
| mgz | so, I probably should write up a summary and send it to some list (which?) so anyone concerned knows where we ar | 13:20 |
| mgz | +e | 13:20 |
| Riddell | canonical-bazaar and lauchpad-dev maybe | 13:20 |
| mgz | thanks Riddell, I'll do that now. | 13:21 |
| mgz | I see from ubuntu-devel cjwatson fixed (a different) issue with syncpackage | 13:23 |
| mgz | that's completely unrelated I think. | 13:24 |
| vila | may be not | 13:24 |
| cjwatson | it is completely unrelated | 13:24 |
| vila | ha | 13:25 |
| vila | :) | 13:25 |
| vila | cjwatson: you didn't create any precise branch on lp ? | 13:25 |
| cjwatson | loads of precise branches have been created (though not by me personally) | 13:26 |
| cjwatson | the question was whether that process has definitely been completed, not whether it was started | 13:26 |
| vila | cjwatson: yup, AIUI, the process failed midway, so I was wondering if some branches were created later and may have fixed the original issue | 13:27 |
| cjwatson | no idea, sorry | 13:27 |
| vila | np, thanks anyway | 13:27 |
| DonDiego | moin | 13:28 |
| DonDiego | i have trouble with ~/.bazaar/rules not working as promised | 13:28 |
| DonDiego | wildcard rules appear to override more specific rules before them, contrary to what the documentation claims | 13:29 |
| DonDiego | is this some sort of known problem? | 13:29 |
| mgz | DonDiego: I think this may be a sort-of known issue with conf sections, but I don't see a bug entry for .bazaar/rules so I'd file a bug | 13:39 |
| redwyre | when using bzr-svn to push to an empty svn depo, should I be getting correct times and authors? | 14:00 |
| DonDiego | author will be the svn commit nick and not the real author (if they are not the same) | 14:01 |
| DonDiego | mgz: thanks, will do | 14:01 |
| redwyre | shouldn't it keep the original authors of the changes? | 14:03 |
| mgz | hm, the prediction of fullermd on friday came true. | 14:04 |
| mgz | okay, I've sent a message to launchpad-dev containing the sum total of my knowledge related to the stopped package importer | 14:04 |
| DonDiego | redwyre: impossible, svn does not differentiate between author and committer - you could add the author to the log message, that's all | 14:06 |
| redwyre | svn calls it author | 14:08 |
| redwyre | but in my case all the svn change lists have the account I used to push as the author | 14:09 |
| redwyre | not their original authors | 14:09 |
| DonDiego | what is your question then? | 14:11 |
| redwyre | how do I get it to push with original authors and timestamps | 14:12 |
| DonDiego | still impossible with svn | 14:20 |
| redwyre | how so? | 14:22 |
| DonDiego | i repeat: svn does not differentiate between author and committer | 14:24 |
| mgz | bazaar stores more information than svn, if you put your bzr repo in svn some of that information isn't represented by the svn format | 14:24 |
| mgz | I think it's actually kept as hidden properties though. | 14:24 |
| mgz | the alternative is dpush, which does throw away information, but might do the right thing with your commit id. | 14:25 |
| * fullermd is a cheenius. | 14:25 | |
| mgz | you're a little ray of sunshine is what you are. | 14:25 |
| fullermd | I know. It's my finest quality. | 14:26 |
| redwyre | I know I can't have author *and* commiter, but all I care about is author from bzr | 14:26 |
| jelmer | redwyre: how are you pushing to svn? | 14:27 |
| jelmer | redwyre: there is an option in bzr-svn that allows you to have svn:author set to the bzr author or committer | 14:27 |
| redwyre | bzr push ~/svn/trunk | 14:29 |
| redwyre | how do I get access to this option? | 14:29 |
| jelmer | redwyre: the option is called "override-svn-revprops" | 14:31 |
| jelmer | redwyre: see the bzr-svn FAQ | 14:32 |
| redwyre | ah cool, does that work for the timestamps as well? | 14:40 |
| jelmer | IIRC yes, if you set svn:date | 14:41 |
| jelmer | arguably these options need better documentation | 14:43 |
| redwyre | I think that FAQ should be part of the online docs ;) | 14:43 |
| jelmer | redwyre: I don't think there are bzr-svn online docs.. | 14:44 |
| redwyre | this: http://wiki.bazaar.canonical.com/ForeignBranches/Subversion | 14:45 |
| jelmer | ah, the wiki | 14:46 |
| redwyre | jelmer: thanks for your help, I'll let you know how it goes tomorrow | 15:20 |
| jelmer | redwyre: np | 15:21 |
| === med_out is now known as medberry | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| === zyga is now known as zyga-afk | ||
| === beuno-lunch is now known as beuno | ||
| === zyga-afk is now known as zyga | ||
| === yofel_ is now known as yofel | ||
| === zyga is now known as zyga-break | ||
| === zyga-break is now known as zyga | ||
| michaelh1 | Hi there. How can I pull a commit from a tree into a vendor branch and re-use the author, comment, etc? | 22:14 |
| lifeless | replay | 22:14 |
| poolie | hi all | 22:22 |
| michaelh1 | That's a tricky one to find. The hidden replay command from bzr-rewrite... | 22:24 |
| poolie | hi all, hi michaelh1 | 22:28 |
| michaelh1 | Hi poolie | 22:28 |
| maxb | Note that replay constructs a history-rewritten version of a commit, rather than merging and committing re-using the original commit's metadata | 22:28 |
| maxb | that may or may not be what you want, I don't quite know from your initial question | 22:28 |
| michaelh1 | Hmm. Here's the situation: | 22:29 |
| michaelh1 | * Upstream is crosstool-NG and is hosted in Mercurial | 22:29 |
| michaelh1 | * We work upstream, sending many small patches. Using Mercurial is fine for this | 22:29 |
| michaelh1 | * I need a product/vendor branch for release workings and non-upstreamable stuff | 22:29 |
| michaelh1 | * Upstream is mirrored down into a Launchpad/bzr branch | 22:30 |
| poolie | hi maxb | 22:30 |
| michaelh1 | * I want to minimise the overhead of pulling in upstream to our product branch but would prefer to keep the top level history. | 22:31 |
| michaelh1 | bzr merge is fine, but retyping the message might be longer than the patch! | 22:31 |
| maxb | right... so you really want something that prepopulates the commit message from the revision(s) being merged | 22:32 |
| maxb | I'd like something like that too :-) | 22:32 |
| maxb | Doesn't seem like it would be hard to write as a plugin | 22:33 |
| maxb | I'm pretty sure all the hooks are there for it | 22:33 |
| wgz | I think I've even seen vila use something along those lines, though maybe his looked at NEWS or such like. | 22:35 |
| michaelh1 | In some ways I want the product branch to be an overlay of trunk, but I can't see how to make it usable day-to-day. | 22:35 |
| wgz | and as the antipodes are up, it must be bed time. | 22:35 |
| poolie | hi there, sleep well | 22:35 |
| poolie | michaelh1: can you expand on that last bullet point? | 22:36 |
| wgz | night! | 22:37 |
| michaelh1 | Yip. So upstream is quite stable and using tip is fine. This is nice as our release could be tip + things that are in flight + local only changes. | 22:37 |
| michaelh1 | Having a product branch gives control, but this means that the workflow is: | 22:38 |
| michaelh1 | Develop upstream, post, upstream merges, appears in bzr mirror, manual merge out to product branch | 22:39 |
| poolie | so the product branch is a bzr branch, separate from the main import? | 22:40 |
| michaelh1 | Yip. That seems best? The import is supposed to be a mirror of upstream. | 22:40 |
| michaelh1 | I still want control of when 3rd party changes come into the product branch | 22:41 |
| poolie | so you want every revision on trunk to appear as one mainline revision in your product branch, but also there'll be some other changes in between them? | 22:41 |
| michaelh1 | If I make a change upstream and they accept it, I want to pull it into our bzr product branch very cheaply. | 22:43 |
| michaelh1 | (also, what they commit may be a tweak over what was sent) | 22:43 |
| poolie | so you could have just one commit to your product branch saying 'merge from trunk' | 22:43 |
| poolie | but, then the product branch main line will look bad | 22:43 |
| michaelh1 | Ugly, yeah. | 22:44 |
| poolie | and do you want one commit on the product branch every time you merge, or one for each thing from trunk? | 22:44 |
| poolie | either way it sounds pretty feasible; the first perhaps a bit easier | 22:45 |
| michaelh1 | I could script it so that it pulls the summary line from the import so it becomes 'Merge r1234: cc/gcc: add the latest foo" and then you get detail through bzr log --include-merges | 22:45 |
| michaelh1 | There's two types of merge: pulling my feature in vs re-syncing with mainline. I'm happy for the re-sync to lump revisions and have a unhelpful comment. | 22:46 |
| poolie | right | 22:49 |
| poolie | possibly just scripting it, even from bash, would be enough | 22:49 |
| poolie | if you file a bug we could do a more integrated thing, especially if this is a pressing problem | 22:49 |
| michaelh1 | It's not pressing but we're just starting and I want to make sure the process is right. | 22:51 |
| poolie | k | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!