spmhttp://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
spmsome missed a decimal place....05:41
pooliei don't know about them06:33
poolieit seems very oddly specific06:33
spmalgorithmic updates gone bad?06:48
pooliecould be06:50
pooliesome weird attempt at SEO by making them sort to the top?06:50
jam1morning all07:05
=== jam1 is now known as jam
pooliehi jam07:16
vilahey jam, hey gang !07:23
jelmerGoeiesmorgens deze morgen!07:37
pooliehi riddell, jelmer07:46
MerwinHi. 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
poolieMerwin: it may have been added with different contents on different branches07:54
poolieso see if they're different07:54
pooliethen probably 'bzr mv foo.BASE foo' and then edit it to taste07:54
Merwinok I'll make a diff on BASe and OTHER to check07:54
MerwinThere is a difference, something changed in .OTHER07:56
MerwinIsn't it better to take .OTHER as reference ?07:56
MerwinI meav, replace xxx with xxx.OTHER?07:58
mgzmorning all08:03
Riddellgood morning Norwich08:09
pooliehi mgz08:26
mgzdoes the package importer still need sorting out?08:35
pooliein general yes :)08:35
pooliei'm not aware of any critical issues but i also haven't looked today08:35
pooliei think dpkg did import08:36
jelmerpoolie, mgz: thanks for the reviews!09:18
jelmerI managed to get the number of failing tests from running bzr's interface tests against bzr-svn down to 9 over the weekend09:19
jelmerwith 3 underlying remaining issues, one of which is the get_revision_delta thing I mailed the list about09:19
mgzRiddell: how do we land things for qbzr? merge to trunk and push?09:19
mgzjelmer: cool09:19
awilkinsjelmer, How well does the gnome-keyring support in bzr-gtk work with bzr-svn ?09:27
Riddellmgz: yes just so, no pqm or the like09:27
jelmerawilkins: IIRC there were some issues, somebody worked on a patch to improve it but I'm not sure what the status of that is09:32
jelmerawilkins: https://code.launchpad.net/~chy-causer/bzr-gtk/fix-svn-keyring/+merge/6081709:32
awilkinsjelmer, 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 yet09:35
awilkinsComparing 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
awilkinsShall try this patch, it's v.small09:38
jelmerawilkins: please do comment on whether the patch works for you09:40
jelmerI should really take some time to review it09:40
awilkinsjelmer, It didn't work for me ; but it may be because I'm using an explicit svn+https:// url09:46
awilkinsjelmer, I need to look and see but for now I've reverted the SVN config back to the old plain auth file09:47
jelmerawilkins: ok, thanks for letting me know09:47
awilkinsjelmer, Have to use that explicit URL because this repo emits server errors instead of 404s if you as for .bzr smart URIs09:48
jelmerawilkins: have you tried https recently? bzr-svn now probes before the bzr smart server09:48
awilkinsNot tried that recently, I'll have to have a go at it09:48
mgzha, I'm not actually a member of qbzr developers09:51
mgzperhaps I should ask Alexander if I can join.09:51
jelmermgz: you should :)10:04
awilkinsjelmer, 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
jelmerawilkins: no, as bzr doesn't support copies10:35
awilkinsjelmer, 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
awilkinsThey 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 client10:37
jelmerawilkins: 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 merge10:38
jelmerawilkins: until copy support is added to bzr, I don't see how this would work10:39
awilkinsjelmer, 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
jelmerawilkins: bzr-svn doesn't have access to the inode information in the svn repository, that's not exposed by the svn protocol10:40
jelmerawilkins: it could do analysis to see if the file was only copied and then scan history to see no other copies are left around10:41
awilkinsjelmer, the svn log viewer knows it's a copy from a particular branch / revision10:41
awilkinsWould it be possible to infer from that?10:41
jelmerawilkins: yes, but we can only keep the file id if it is the *only* copy10:41
jelmerand that's the tricky bit10:41
awilkinsDoes 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
jelmerawilkins: yes, but note that it can be hard to determine that too10:45
awilkinsI 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
jelmerawilkins: what if a file is being copied in from elsewhere, how do you know its file id?10:46
jelmerawilkins: you have to do the same analysis all over again for all inventories it has ever been part of10:47
jelmerawilkins: and at each step determine whether or not it could keep its id10:47
awilkinsThis 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
awilkinsBut I prefer bzr-svn because it makes pushing much less ... fraught10:50
jelmergit doesn't store renames or copies and always infers them later on, so it doesn't matter how they were in svn10:50
awilkinsI 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 people10:50
jelmerbzr 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-svn10:50
jelmerand that shouldn't have to involve the file ids staying the same, as keeping the file ids the same has a lot of performance impact10:51
awilkinsI shall just have to browbeat the person doing the merges into using bzr :-)10:52
awilkinsFor the time being....10:52
jelmerawilkins: did you see my last few lines?11:16
awilkinsThe bit about inferring renames from copies?11:24
awilkinsLast log I have from you was at 1100 UTC when you rejoined the channel11:25
awilkinsjelmer, 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 everywhere11: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 same11:34
awilkinsjelmer, 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
jelmerawilkins: right11:37
Riddellhow can I forcibly create the conditions where I have to run bzr break-lock?11:52
Riddellthe bzr server seems very good at not lockings, it seems I can even push to the same repository from two places at the same time11:53
jelmerRiddell: I suspect just opening a write lock and not unlocking should be sufficient11:55
jelmerRiddell: have you looked at bzrlib/tests/blackbox/test_break_lock.py for inspiration?11:56
Riddellgood idea11:59
spivRiddell: python -c "from bzrlib.bzrdir import BzrDir; b = BzrDir.open('some/path').open_branch(); b.lock_write(); b.leave_lock_in_place()"12:12
mgzah, neat spiv, I thought it was more of a pain than that.12:16
Riddellspiv: thanks, I'd worked that out :)12:23
vilahu ho, what happened to the package importer ?12:50
vilamgz: any idea ^ ?12:54
vilaIt looks like someone killed it.  Should I just restart it ?12:55
mgzvila: I stopped it as part of the release process13:04
vilaoh, ok13:04
mgzand after build-distro failed, no one was sure if it was safe to restart or not13:04
vilawhat's build-distro ? An lp thing ?13:05
mgzso, it's waiting for someone who knows what they're doing to take over13:05
mgzyeah, basically making new branches for the P-series13:05
vilahmm, I think wgrant did it last time13:06
vilaprobably sleeping right now13:06
mgzI have a log of the output that gnuoy got, with some warnings about stacking then an uninformative error at the end13:06
mgzwgrant is who told me to look at the log.13:07
mgzso, I guess we still don't have anyone who actually understands this? :)13:07
vilaoh, so something failed on lp, ok13:07
mgzI think I worded my question about this to poolie poorly this morning, he didn't seem to think there was an issue13:19
mgzso, I probably should write up a summary and send it to some list (which?) so anyone concerned knows where we ar13:20
Riddellcanonical-bazaar and lauchpad-dev maybe13:20
mgzthanks Riddell, I'll do that now.13:21
mgzI see from ubuntu-devel cjwatson fixed (a different) issue with syncpackage13:23
mgzthat's completely unrelated I think.13:24
vilamay be not13:24
cjwatsonit is completely unrelated13:24
vilacjwatson: you didn't create any precise branch on lp ?13:25
cjwatsonloads of precise branches have been created (though not by me personally)13:26
cjwatsonthe question was whether that process has definitely been completed, not whether it was started13:26
vilacjwatson: yup, AIUI, the process failed midway, so I was wondering if some branches were created later and may have fixed the original issue13:27
cjwatsonno idea, sorry13:27
vilanp, thanks anyway13:27
DonDiegoi have trouble with ~/.bazaar/rules not working as promised13:28
DonDiegowildcard rules appear to override more specific rules before them, contrary to what the documentation claims13:29
DonDiegois this some sort of known problem?13:29
mgzDonDiego: 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 bug13:39
redwyrewhen using bzr-svn to push to an empty svn depo, should I be getting correct times and authors?14:00
DonDiegoauthor will be the svn commit nick and not the real author (if they are not the same)14:01
DonDiegomgz: thanks, will do14:01
redwyreshouldn't it keep the original authors of the changes?14:03
mgzhm, the prediction of fullermd on friday came true.14:04
mgzokay, I've sent a message to launchpad-dev containing the sum total of my knowledge related to the stopped package importer14:04
DonDiegoredwyre: impossible, svn does not differentiate between author and committer - you could add the author to the log message, that's all14:06
redwyresvn calls it author14:08
redwyrebut in my case all the svn change lists have the account I used to push as the author14:09
redwyrenot their original authors14:09
DonDiegowhat is your question then?14:11
redwyrehow do I get it to push with original authors and timestamps14:12
DonDiegostill impossible with svn14:20
redwyrehow so?14:22
DonDiegoi repeat: svn does not differentiate between author and committer14:24
mgzbazaar stores more information than svn, if you put your bzr repo in svn some of that information isn't represented by the svn format14:24
mgzI think it's actually kept as hidden properties though.14:24
mgzthe 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
mgzyou're a little ray of sunshine is what you are.14:25
fullermdI know.  It's my finest quality.14:26
redwyreI know I can't have author *and* commiter, but all I care about is author from bzr14:26
jelmerredwyre: how are you pushing to svn?14:27
jelmerredwyre: there is an option in bzr-svn that allows you to have svn:author set to the bzr author or committer14:27
redwyrebzr push ~/svn/trunk14:29
redwyrehow do I get access to this option?14:29
jelmerredwyre: the option is called "override-svn-revprops"14:31
jelmerredwyre: see the bzr-svn FAQ14:32
redwyreah cool, does that work for the timestamps as well?14:40
jelmerIIRC yes, if you set svn:date14:41
jelmerarguably these options need better documentation14:43
redwyreI think that FAQ should be part of the online docs ;)14:43
jelmerredwyre: I don't think there are bzr-svn online docs..14:44
redwyrethis: http://wiki.bazaar.canonical.com/ForeignBranches/Subversion14:45
jelmerah, the wiki14:46
redwyrejelmer: thanks for your help, I'll let you know how it goes tomorrow15:20
jelmerredwyre: np15: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
michaelh1Hi there.  How can I pull a commit from a tree into a vendor branch and re-use the author, comment, etc?22:14
pooliehi all22:22
michaelh1That's a tricky one to find.  The hidden replay command from bzr-rewrite...22:24
pooliehi all, hi michaelh122:28
michaelh1Hi poolie22:28
maxbNote that replay constructs a history-rewritten version of a commit, rather than merging and committing re-using the original commit's metadata22:28
maxbthat may or may not be what you want, I don't quite know from your initial question22:28
michaelh1Hmm.  Here's the situation:22:29
michaelh1 * Upstream is crosstool-NG and is hosted in Mercurial22:29
michaelh1 * We work upstream, sending many small patches.  Using Mercurial is fine for this22:29
michaelh1 * I need a product/vendor branch for release workings and non-upstreamable stuff22:29
michaelh1 * Upstream is mirrored down into a Launchpad/bzr branch22:30
pooliehi maxb22: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
michaelh1bzr merge is fine, but retyping the message might be longer than the patch!22:31
maxbright... so you really want something that prepopulates the commit message from the revision(s) being merged22:32
maxbI'd like something like that too :-)22:32
maxbDoesn't seem like it would be hard to write as a plugin22:33
maxbI'm pretty sure all the hooks are there for it22:33
wgzI think I've even seen vila use something along those lines, though maybe his looked at NEWS or such like.22:35
michaelh1In 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
wgzand as the antipodes are up, it must be bed time.22:35
pooliehi there, sleep well22:35
pooliemichaelh1: can you expand on that last bullet point?22:36
michaelh1Yip.  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
michaelh1Having a product branch gives control, but this means that the workflow is:22:38
michaelh1Develop upstream, post, upstream merges, appears in bzr mirror, manual merge out to product branch22:39
poolieso the product branch is a bzr branch, separate from the main import?22:40
michaelh1Yip.  That seems best?  The import is supposed to be a mirror of upstream.22:40
michaelh1I still want control of when 3rd party changes come into the product branch22:41
poolieso 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
michaelh1If 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
poolieso you could have just one commit to your product branch saying 'merge from trunk'22:43
pooliebut, then the product branch main line will look bad22:43
michaelh1Ugly, yeah.22:44
poolieand do you want one commit on the product branch every time you merge, or one for each thing from trunk?22:44
poolieeither way it sounds pretty feasible; the first perhaps a bit easier22:45
michaelh1I 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-merges22:45
michaelh1There'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
pooliepossibly just scripting it, even from bash, would be enough22:49
poolieif you file a bug we could do a more integrated thing, especially if this is a pressing problem22:49
michaelh1It's not pressing but we're just starting and I want to make sure the process is right.22:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!