Re: [Monotone-devel] bugfest analysis - final points
Thomas Keller m...@thomaskeller.biz writes: Am 16.05.10 11:19, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: For the others: If you think your branch is ready for the final merge, give me a note if you want to get it reviewed another time, otherwise just merge it. For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed the --recursive option from 'undrop'. So I think this is ready to merge. net.venge.monotone.restrictions.implicit-includes will change what 'revert' does with some restrictions; since 'undrop' shares core code with 'revert', there's no need to wait for that branch. I haven't followed your conversation with Derek further - just to get a ok from you both: undrop is still needed even after the new restriction code landed, right? Yes, because the sequence: drop foo revert foo clobbers a locally modified 'foo'; 'drop' doesn't actually delete it, but 'revert' overwrites it. The other alternative is: drop foo add foo This keeps the modified file, but also changes the node id, losing history. 'undrop' solves both of these problems. One alternative we did not really investigate would be: drop foo revert --move-conflicting-paths foo cp _MTN/resolutions/foo . That would be equivalent to 'undrop'. I think 'undrop' is friendlier. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
Am 17.05.2010 14:08, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: Am 16.05.10 11:19, schrieb Stephen Leake: For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed the --recursive option from 'undrop'. So I think this is ready to merge. net.venge.monotone.restrictions.implicit-includes will change what 'revert' does with some restrictions; since 'undrop' shares core code with 'revert', there's no need to wait for that branch. I haven't followed your conversation with Derek further - just to get a ok from you both: undrop is still needed even after the new restriction code landed, right? Yes, because the sequence: drop foo revert foo clobbers a locally modified 'foo'; 'drop' doesn't actually delete it, but 'revert' overwrites it. The other alternative is: drop foo add foo This keeps the modified file, but also changes the node id, losing history. 'undrop' solves both of these problems. One alternative we did not really investigate would be: drop foo revert --move-conflicting-paths foo cp _MTN/resolutions/foo . That would be equivalent to 'undrop'. I think 'undrop' is friendlier. Ok, cool, so if documentation and NEWS is up to date, go and merge it! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
Thomas Keller m...@thomaskeller.biz writes: For the others: If you think your branch is ready for the final merge, give me a note if you want to get it reviewed another time, otherwise just merge it. For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed the --recursive option from 'undrop'. So I think this is ready to merge. net.venge.monotone.restrictions.implicit-includes will change what 'revert' does with some restrictions; since 'undrop' shares core code with 'revert', there's no need to wait for that branch. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
Am 16.05.10 11:19, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: For the others: If you think your branch is ready for the final merge, give me a note if you want to get it reviewed another time, otherwise just merge it. For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed the --recursive option from 'undrop'. So I think this is ready to merge. net.venge.monotone.restrictions.implicit-includes will change what 'revert' does with some restrictions; since 'undrop' shares core code with 'revert', there's no need to wait for that branch. I haven't followed your conversation with Derek further - just to get a ok from you both: undrop is still needed even after the new restriction code landed, right? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
On Sun, May 16, 2010 at 3:51 PM, Thomas Keller m...@thomaskeller.biz wrote: Am 16.05.10 11:19, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: For the others: If you think your branch is ready for the final merge, give me a note if you want to get it reviewed another time, otherwise just merge it. For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed the --recursive option from 'undrop'. So I think this is ready to merge. net.venge.monotone.restrictions.implicit-includes will change what 'revert' does with some restrictions; since 'undrop' shares core code with 'revert', there's no need to wait for that branch. I haven't followed your conversation with Derek further - just to get a ok from you both: undrop is still needed even after the new restriction code landed, right? I don't think the changes to the restriction code have any effect on this so yes, as far as I understand it, undrop is still needed. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.bizwrote: * #20447: mtn diff filename fails inside of a renamed directory - net.venge.monotone.bugfest-2010.20447-dscherger - @Derek: whats your plan here? Is this reviewable? Patch looks ok, if you add tests for the new diff behaviour (/dev/null in adds and file removals) and check the patch(1) compatibility, I'll reward that with an 8. I've added a bunch of tests and noticed that there are several xfailed diff tests that are related to the same problem of a restriction excluding parents of a file. Seeing all these I'm pretty much convinced that making a change so that parent nodes get included is the right thing to do, or is at least better than what we're doing now. I don't think this should be too hard to do so I may have a look at it in the not-too-distant future. I'd like to get the changelog branch wrapped up first though. Note that you based this work on the code of #12273 - so only merge it into mainline afterwards when you had the time to manage the shortening of the ls tags output there :) Fixed, tested and merged. We can think about adding a --verbose option for things like this any time. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
Am 12.05.10 18:26, schrieb Derek Scherger: On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.bizwrote: * #20447: mtn diff filename fails inside of a renamed directory - net.venge.monotone.bugfest-2010.20447-dscherger - @Derek: whats your plan here? Is this reviewable? Patch looks ok, if you add tests for the new diff behaviour (/dev/null in adds and file removals) and check the patch(1) compatibility, I'll reward that with an 8. I've added a bunch of tests and noticed that there are several xfailed diff tests that are related to the same problem of a restriction excluding parents of a file. Seeing all these I'm pretty much convinced that making a change so that parent nodes get included is the right thing to do, or is at least better than what we're doing now. I don't think this should be too hard to do so I may have a look at it in the not-too-distant future. I'd like to get the changelog branch wrapped up first though. There shouldn't be much missing - we've only talked about log preserving last time, right? Note that you based this work on the code of #12273 - so only merge it into mainline afterwards when you had the time to manage the shortening of the ls tags output there :) Fixed, tested and merged. We can think about adding a --verbose option for things like this any time. Yeah, I've seen that - cool! For the others: If you think your branch is ready for the final merge, give me a note if you want to get it reviewed another time, otherwise just merge it. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
Hi again! So I got comments on most things - lets check the final scores: 1) Assigned, but not (yet) closed issues: * #7221: [NEED TEST] monotone cert should not require its target be on a branch - net.venge.monotone.bugfest-2010.7221-stephen_leake - @Stephe: Please look at my comment there. If you work that out, an additional 2 point reward is for you :) Fix has been adapted, points have been counted. * #17878: Usability: too easy to accidentally fork after merge or disapprove - branch is net.venge.monotone.bugfest-2010.17878-tbrownaw - @Tim: is this done? I reviewed that (see the other mail) - if the remaining smaller issues have been sorted out and all tests pass, it should be good to get merged. I'll reward that with 5. * #13597: monotone update -b newbranch exhibits incorrect behaviour - @Stephe: whats your plan here? Not a bug anymore, no more points here, I think (I should have gotten one :)). Stephe, please close this as well since you're still assigned. * #20447: mtn diff filename fails inside of a renamed directory - net.venge.monotone.bugfest-2010.20447-dscherger - @Derek: whats your plan here? Is this reviewable? Patch looks ok, if you add tests for the new diff behaviour (/dev/null in adds and file removals) and check the patch(1) compatibility, I'll reward that with an 8. Note that you based this work on the code of #12273 - so only merge it into mainline afterwards when you had the time to manage the shortening of the ls tags output there :) Lets breakdown the current points (not counting the not in test issues) so far: 1) Stephe 13 points (#7221 and #13597 still open) 2) Richard 11 points 3) Derek5 points (#20447 still open, might add +5) 4) Tim3 points (#17878 still open, might add +5) Now the updated final results: 1) Stephe 15 points 2) Derek13 points 3) Richard 11 points 4) Tim 8 points I think it would be only fair to reward everybody of you with a small price - you all have been quite busy and the point scores are very nearby. If you want to get something, hand me over your postal address - if you have a specific wish (but please be kind to my money bag :)), tell it to me - for example if you have enough coffee mugs in your cupboard already... Thanks again for your work, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.biz wrote: * #20447: mtn diff filename fails inside of a renamed directory - net.venge.monotone.bugfest-2010.20447-dscherger - @Derek: whats your plan here? Is this reviewable? Patch looks ok, if you add tests for the new diff behaviour (/dev/null in adds and file removals) and check the patch(1) compatibility, I'll reward that with an 8. Great! Ok, I'll add this to my list (which is getting rather long at this point) as well. It shouldn't be too hard to finish up. Note that you based this work on the code of #12273 - so only merge it into mainline afterwards when you had the time to manage the shortening of the ls tags output there :) Oh good catch. I'll finish that up and add a test and then merge it to mainline. I was wondering a bit more about a --verbose option that might apply here to turn on more detail in the list of tags. Perhaps the default would be to list only tag names and revs, and with --verbose list the branch and key details too. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
