Richard Lowe wrote: > Stephen Lau wrote: >> Richard Lowe wrote: >>> Stephen Lau wrote: >>>> http://cr.opensolaris.org/~stevel/hg_branch/ >>> >>> As a random aside, I keep entirely forgetting that that exists. >>> >>>> Anyone want to take a look at the above and see if it makes sense? >>>> >>>> This uses hg-active (and by extension Cadmium) to determine the >>>> parenttip to determine what to diff against. The previous behaviour >>>> was depending on 'hg log <path>' to follow the branch, but it >>>> doesn't (and adding -f doesn't help since apparently for files, that >>>> only follows copies/renames - not branches). >>>> >>>> In any case, I haven't filed a bug to track it yet - but if the >>>> changes look reasonable I will. >>> >>> webrev.sh: >>> What happens if we get a file list without HG_PARENT? This needs to >>> continue to work with explicit file lists of both varieties (though >>> it may >>> not work as well...) >> >> Right - I believe the old behaviour isn't quite right (it mostly >> works, but certainly fails in this case of a repository with branches >> - so clearly it needs some more work). I tossed it out with the >> intent of working on something better, but wanted to get this code >> reviewed first. So currently this won't work if we get a file list >> without HG_PARENT. >> >> What cases are you expecting that we can't get HG_PARENT? I suppose >> the first changeset is one; are there other cases? If we can't >> contact the parent repo (disconnected operation), we should still have >> one. (Sorry it's late, I might be missing something obvious) > > Explicit file lists, rather than those from hg-active. I use both > normal file lists, and wx format file lists with the Hg support (maybe > that seems weird, but I do, and it's useful). I suppose I could specify > HG_PARENT in there, and an argument could be made that improper > calculation is worse than > no calculation, but if the branch case turns out to be uncommon, I like > having the ability. > >>> webrev.sh:1464 >>> You set hg_parent (note the case), and never use it. g >>> Given that, this whole bit doesn't seem to have a purpose (does it?) >> >> No, that was more a copy/paste bit before I changed the later code - >> it doesn't need to exist since we eval it from the $FLIST. Thanks. > >>> webrev.sh:1585 >>> hg cat exits with 0 even when it fails, this won't work. (but this >>> annoys me, so fixing hg would also be ok by me...) >> >> Ugh. That's sucky - yeah, I'd rather fix hg so it returns 0 upon >> failure of 'hg cat'. > > I'm going to assume you mean 1 (hey, it's review, pedantry is ok, > right?) :) > > -- Rich
Duh yeah. 1. :-P -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
