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
Derek Scherger de...@echologic.com writes: On Mon, May 10, 2010 at 3:47 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: I think restrictions in general are poorly defined, which is one reason I never use them. If you say 'undrop file' you're using them! ;) Well, yes, that's how the code works. But in this case, I meant I would not use a restriction on 'undrop' that is different than the restriction on 'drop'. That's what leads to problems. The situation with revert might be better if it did do its work through the editable tree interface but getting this to work is difficult at best and it leaves open the possibility that revert will fail with mixed files/directories in the workspace blocking things from being reverted. One up-side of using the editable tree interface would be that revert wouldn't leave all kinds of junk laying around after its done. - Do you have any specific ideas of things that could be defined or described better? The only thing I would change in revert is support for 'revert --move-conflicting files'. Other than that, I haven't had any actual problems with revert. I worked on 'undo' because it was bugfest, and it seemed like I might want that capability sometime. 'undo' and 'revert --move-conflicting-files' address the same problem in different ways. - Is it that the existing documentation doesn't describe what is possible well enough? I guess I've never wanted to revert a rename, or revert something that depended on a rename. So I've never had to wonder what happens if I try that. - Is it that various commands deal with things in different ways (revert in particular, but also add etc.) which makes it feel like they are not well defined? I do as much as possible via Emacs DVC, so I have a different set of command semantics to worry about. I only worry about mtn command line semantics when I'm trying to map them to Emacs DVC semantics. - Is it that add a/b/c will add a, a/b and a/b/c and then commit a/b/c will fail because it has excluded a and a/b? When confronted with a list of unknown files, I always either add, ignore, or delete them, individually. They each get a mark in the Emacs DVC status buffer, so I can see what will happen to each. - Is it that filenames are generally resolved against both the old and new roster to select nodes to be included or excluded? This matters only for renames, so I have no experience with this. - Is it that the --depth option applies to all specified paths rather than to a specific path, allowing different levels of recursion for different directories? I've always wondered whether --depth=0 means no recursion. But I just avoid using it. - Is it that you're not sure what will happen when you're about to say commit or revert with a set of paths? The intention is that the changes that get selected are *identical* for status, diff, commit, revert and the various list commands that apply to paths and there are tests to this effect. That's a good intent. But in general, commands that operate on a subset of the natural set of files are problematic. committing anything other than the full workspace means you've got an inconsistent state. I do often exclude specific files from a commit; for example a Makefile whose only change is specifying which test I want to run today. But such exclusions are carefully monitored. I use revert only to recover a known good file. Even then, I normally do a diff against the earlier version first, and often pick parts to revert, not the whole file. status and diff I do for the whole workspace. So most of this discussion is moot for me. I believe that the set of nodes that get included based on a given list of paths and --exclude options is completely well defined. Yes, that's true. Whether this set is well defined for the operation it is used for might be another matter though as not all commands can or do use it. Right; revert renames is a case where it is not. Each command has different semantics, which interact with the selection. I do agree that committing part of a workspace can be considered bad practice in that you're essentially committing something that hasn't been tested but it happens often enough in reality that it seems like a necessary feature. Most other systems out there do allow this so we're not too far out in left field. And most programs are written in Visual Basic (or is it Excel macros? hard to keep up :). It is a trade-off between acceptance because of familiarity, and rigor. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
Stephen Leake stephen_le...@stephe-leake.org writes: Derek Scherger de...@echologic.com writes: On Mon, May 10, 2010 at 3:47 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: I think restrictions in general are poorly defined, which is one reason I never use them. If you say 'undrop file' you're using them! ;) Well, yes, that's how the code works. But in this case, I meant I would not use a restriction on 'undrop' that is different than the restriction on 'drop'. That's what leads to problems. Which gives me another idea: 'mtn changelist undo' Undoes the last entry in _MTN/revision 'undo' takes _no_ options or parameters, so there's no question about what it does :). Hmm. Given the way changesets are sorted, last is an illdefined notion. Sigh. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
Am 10.05.2010 04:52, schrieb Derek Scherger:
On Sun, May 9, 2010 at 5:28 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?
I spent most of the day working on this and made some big changes
(reimplementing diff in terms of rosters rather than csets) but they didn't
actually fix the problem, which turns out to be somewhat complicated. I was
out for a long drive today and spent quite a lot of time thinking about it.
I have some ideas but I'm not yet sure if they'll work out or not. I'll
follow up with another email explaining the details.
Ok, fine!
* #12773: show which branch a tag belongs to
- net.venge.monotone.bugfest-2010.12273-dscherger
- Patch looks cool, a test would be nice though. Wrt space issues,
we could shorten the revision to gain additional space - I think
the chance of finding two partial tagged revisions which can be
completed to two different full revision ids is rather low.
- points: 5 to Derek (if you add a test :)
OK, adding a test should be easy. Do we have something to produce short
revision ids or should I just grab the first N chars or something?
Not yet currently, and I fear we might even have different visual
representations already (f.e. some with ..., some without). Although
shortening a string is a very simple task, I think it would be a good
idea to have one function in a central place which does that for the id
type we have (and returns a string).
* #13604: need 'undelete' ('undrop'?)
- net.venge.monotone.bugfest-2010.13604-stephen_leake
- patch looks largely cool, some minor objections:
revert = not undrop; - is the not operator portable?
bool undrop function argument - an enum would be cool :)
- possible issue left: undrop does not work correctly when
called on a dropped directory without --recursive. It still
re-creates all childs of the directory, while one would assume
that only the directory itself is recreated (and all the other
files keep dropped)
- points: 5 to Stephe (if the remaining issues are sorted out)
I'm somewhat curious about this one but I haven't looked at the bug or the
fixes yet. Is undrop/undelete somehow different from revert or is this just
a command alias?
Stephe can comment more here, basically it calls into revert's code, but
with a few more bells and whistles.
Other than that I'm quite happy with the results. We've closed many bugs
and I think we should do that again some time in the future to bring
down the bug count even more.
Agreed. I personally find having a few people around working at the same
time is quite motivating.
Yep, absolutely.
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
Am 10.05.2010 05:23, schrieb Timothy Brownawell: On 05/09/2010 06:28 PM, Thomas Keller wrote: * #17878: Usability: too easy to accidentally fork after merge or disapprove - branch is net.venge.monotone.bugfest-2010.17878-tbrownaw - @Tim: is this done? It needs a test using the --update option, which I'll get to either in the morning or after work tomorrow. I suppose I should also put a note in NEWS about setting your get_default_command_options() if you want to always have that behavior. Ok, cool. * #16895: Better error reporting in permission-denied scenarios - @Tim: Do you think of anything in particular (but not a very good one)? Maybe this is worth a tiny patch... - points: 1 to Tim I think it's improved since that post. Ah right, I totally oversaw the date of your comment... ;) Other than that I'm quite happy with the results. We've closed many bugs and I think we should do that again some time in the future to bring down the bug count even more. Maybe try for every 6 months or so? If it's too often we'd probably get lower participation on any particular date, which wouldn't work at all at our size. Lets try to do that every two or three months - I think six months are way too much down the road. I want to keep the project active and healthy with this, and as Derek noted, it should motivate all of us a lot to work together in a small sprint. A shorter time span also means that if one person cannot attend for timing reasons, he / she doesn't have to wait another six months until he / she gets the chance again :) 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
Thomas Keller m...@thomaskeller.biz writes:
Here is a little analysis of the recent bugfest efforts.
Thanks for all your work in organizing this.
Point proposals from me are noted for In test issues. If no one else
objects, please close the issues I marked accordingly yourself:
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 :)
Fixed.
* #13597: monotone update -b newbranch exhibits
incorrect behaviour
- @Stephe: whats your plan here?
The latest comment in the bug explains my confusion; it can be closed.
It is currently marked In Test.
2) Assigned, In test issues:
...
I closed all of mine
* #9269: [NEED TEST] monotone log doesn't understand windows directory
separator
- net.venge.monotone.bugfest-2010.9269-stephen_leake
- test looks ok for me (can't execute it here locally, though,
since I have no windows machine) - can be closed if the test
works
- points: 2 to Stephe
I ran the test on both Debian and MinGW; it works.
Closed.
* #12455: MT 0.16 can't access, if DB stored on NFS
- I tend to agree that this is set on won't fix, while it might
still be a smaller issue in monotone (we should probably not
segfault, but provide a good error message, can anyone with an NFS
setup confirm that?)
- points: 1 to Stephe
I think it's up to sqlite to provide a better error message. We could
file a bug upstream.
Closed.
- points: 5 to Derek (if you add a test :)
Thank you for insisting on tests. The complete test suite is a major
feature of monotone; it makes the program much more trustworthy. I have
confidence that changes (made by me or others) will not break existing
behavior (or if they do, we will know about it).
One way to ensure tests get written is to adopt a development process
that always writes the test first, and always runs mtn in the context of
a test, not directly from the command line. I have a separate Makefile
for this, containing targets like:
mtn :
make -C /home/Projects/monotone/bug-hunt-build mtn
# /home/Projects/monotone/bug-hunt-build/tester_dir/tests/undrop/tester.log
# /home/Projects/monotone/bug-hunt/tests/undrop/__driver__.lua
test :
cd /home/Projects/monotone/bug-hunt-build; ./run_lua_tests -d undrop
That makes it very easy to rebuild mtn and run just the one test I'm
currently working on.
* #13604: need 'undelete' ('undrop'?)
- net.venge.monotone.bugfest-2010.13604-stephen_leake
- patch looks largely cool, some minor objections:
revert = not undrop; - is the not operator portable?
Sorry about that; I was writing Ada code in a C++ context :(. Amazing
that it compiled!
Interestingly, Emacs highlites not as a keyword in C++. But I don't
see it in my copy of the C++ standard; maybe it's very new?
replaced by !.
- possible issue left: undrop does not work correctly when
called on a dropped directory without --recursive. It still
re-creates all childs of the directory, while one would assume
that only the directory itself is recreated (and all the other
files keep dropped)
I think this needs discussing; I'll start a separate thread.
I've added tests to illustrate some of the issues.
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)
I'll give everybody some more time to cleanup / finish the mentioned
things and recalculate the final scores again then.
I feel a little guilty about this. I deliberately adopted a strategy of
only working on trivial bugs. That was partly because I was tired and
not in the mood for hard work, but also partly because I felt it was in
the spirit of the bug hunt.
But others took on significant issues, and that should be rewarded.
Perhaps next time there should be two top prizes; most bugs closed and
hardest bug closed, or perhaps most effort expended (measured by
changed lines of code, or something).
On the other hand, after a few bug hunts of only closing trivial bugs,
there won't be any left to close :).
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
Derek Scherger de...@echologic.com writes:
On Sun, May 9, 2010 at 5:28 PM, Thomas Keller m...@thomaskeller.biz wrote:
* #13604: need 'undelete' ('undrop'?)
- net.venge.monotone.bugfest-2010.13604-stephen_leake
- patch looks largely cool, some minor objections:
revert = not undrop; - is the not operator portable?
bool undrop function argument - an enum would be cool :)
- possible issue left: undrop does not work correctly when
called on a dropped directory without --recursive. It still
re-creates all childs of the directory, while one would assume
that only the directory itself is recreated (and all the other
files keep dropped)
- points: 5 to Stephe (if the remaining issues are sorted out)
I'm somewhat curious about this one but I haven't looked at the bug or the
fixes yet. Is undrop/undelete somehow different from revert or is this just
a command alias?
It is a minor modification of revert; I factored out the common code.
undrop just tells revert not to revert a file that is present in the
workspace, because it had changes when it was dropped.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Mon, May 10, 2010 at 6:24 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: It is a minor modification of revert; I factored out the common code. undrop just tells revert not to revert a file that is present in the workspace, because it had changes when it was dropped. Ahh I see. I've wondered of and on about a few different options to revert. Like --name, --attrs, --content so that it can be a little more fine-grained about what it does. So would something like revert --no-content file be synonymous with undrop at this point? I think there are still some problems lurking in revert as well, for one it leaves renamed things laying around after reverting the renames. I've tried a few times to make revert work based on the editable_tree interface rather than just looking for missing files and recreating them but this turns out to be quite tricky and I've never actually managed to make it work quite right. The last attempt I made did at least get revert upgraded to use roster style checks rather than csets but it still doesn't actually replay the pending changes in reverse. One thing I noticed in trying to fix the diff bug was this: $ mtn mv dir dir2 $ edit dir2/file $ mth revert dir2/file # only reverts content, leaves directory rename in place $ edit dir2/file $ mtn revert dir2 --depth=0 # should revert the rename and leave the content change but fails it would be good to get this sorted out too. What I really need to do is to go and add a bunch of tests for things like this problem and a few others that I noticed in my thrashing around on Saturday. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Mon, May 10, 2010 at 6:21 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Thomas Keller m...@thomaskeller.biz writes: Here is a little analysis of the recent bugfest efforts. Thanks for all your work in organizing this. I'll second that, you've done a great job of keeping track of what's going on and reviewing things. 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) I'll give everybody some more time to cleanup / finish the mentioned things and recalculate the final scores again then. I feel a little guilty about this. I deliberately adopted a strategy of only working on trivial bugs. That was partly because I was tired and not in the mood for hard work, but also partly because I felt it was in the spirit of the bug hunt. Don't! I have a huge tendency to fall into any bottomless pit available and it happened again on Saturday. I looked at the diff bug and thought it looked like it might not be too bad and then it blew up in my face. Happens all the time, didn't even surprise me. The list branch names with tags fix took all of 15 minutes so I'm super lucky to get 5 points for that one too! ;) Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
Am 10.05.10 17:03, schrieb Derek Scherger: One thing I noticed in trying to fix the diff bug was this: $ mtn mv dir dir2 $ edit dir2/file $ mth revert dir2/file # only reverts content, leaves directory rename in place $ edit dir2/file $ mtn revert dir2 --depth=0 # should revert the rename and leave the content change but fails it would be good to get this sorted out too. In any way, it would be good if you could either open a bug or write an xfailed test for it - I doubt (though I wish :)) you find time to get to it back any time soon... 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
Am 10.05.10 05:23, schrieb Timothy Brownawell: On 05/09/2010 06:28 PM, Thomas Keller wrote: * #17878: Usability: too easy to accidentally fork after merge or disapprove - branch is net.venge.monotone.bugfest-2010.17878-tbrownaw - @Tim: is this done? It needs a test using the --update option, which I'll get to either in the morning or after work tomorrow. I suppose I should also put a note in NEWS about setting your get_default_command_options() if you want to always have that behavior. Looks cool so far, a few minor questions / nitpicks: 1) In maybe_workspace_updater.cc: +if (rev.edges.size() != 1) + return not_updatable; Wouldn't that mean that the root revision of a branch is not updatable? I.e. create a new project, commit and push that. Somebody else changes it, you pull with --update afterwards, or do I get something wrong? 2) Your workspaces have not been updated - why are you using plural here? 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
Am 10.05.10 17:08, schrieb Derek Scherger: On Mon, May 10, 2010 at 6:21 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Thomas Keller m...@thomaskeller.biz writes: Here is a little analysis of the recent bugfest efforts. Thanks for all your work in organizing this. I'll second that, you've done a great job of keeping track of what's going on and reviewing things. Thank you two :) - its actually fun to manage that - though it can be stressful if five emails arrive in parallel, all with different discussions and topics... 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
Derek Scherger de...@echologic.com writes: On Mon, May 10, 2010 at 6:24 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: It is a minor modification of revert; I factored out the common code. undrop just tells revert not to revert a file that is present in the workspace, because it had changes when it was dropped. Ahh I see. I've wondered of and on about a few different options to revert. Like --name, --attrs, --content so that it can be a little more fine-grained about what it does. So would something like revert --no-content file be synonymous with undrop at this point? I don't know; --no-content to me sounds like don't revert content, just renmaes and other stuff. That's not the same as 'undrop', which does revert content if the file actually got deleted from the workspace. One thing I noticed in trying to fix the diff bug was this: $ mtn mv dir dir2 $ edit dir2/file $ mth revert dir2/file # only reverts content, leaves directory rename in place $ edit dir2/file $ mtn revert dir2 --depth=0 # should revert the rename and leave the content change but fails it would be good to get this sorted out too. I think restrictions in general are poorly defined, which is one reason I never use them. -- -- Stephe ___ 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
On 05/10/2010 03:44 PM, Thomas Keller wrote: Am 10.05.10 05:23, schrieb Timothy Brownawell: On 05/09/2010 06:28 PM, Thomas Keller wrote: * #17878: Usability: too easy to accidentally fork after merge or disapprove - branch is net.venge.monotone.bugfest-2010.17878-tbrownaw - @Tim: is this done? It needs a test using the --update option, which I'll get to either in the morning or after work tomorrow. I suppose I should also put a note in NEWS about setting your get_default_command_options() if you want to always have that behavior. Looks cool so far, a few minor questions / nitpicks: 1) In maybe_workspace_updater.cc: +if (rev.edges.size() != 1) + return not_updatable; Wouldn't that mean that the root revision of a branch is not updatable? I.e. create a new project, commit and push that. Somebody else changes it, you pull with --update afterwards, or do I get something wrong? That still has one edge, from a parent with the null revision id. 2) Your workspaces have not been updated - why are you using plural here? Hm. I guess because I tend to have multiple workspaces (because I'm fairly easily distractable and don't work in small enough chunks yet). But to really be consistent with this it should say your other workspaces have not been updated when it *does* update. ...I suppose the having too many workspaces really is a bad habit we don't want to encourage, so I'll go make it not plural. And then it doesn't have to say anything when it does update. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Mon, May 10, 2010 at 3:47 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: I don't know; --no-content to me sounds like don't revert content, just renmaes and other stuff. That's not the same as 'undrop', which does revert content if the file actually got deleted from the workspace. Fair enough, I now see where you're coming from. I don't think I've ever used the --bookkeep-only option so I've never ended up with a file in such a state. One thing I noticed in trying to fix the diff bug was this: $ mtn mv dir dir2 $ edit dir2/file $ mth revert dir2/file # only reverts content, leaves directory rename in place $ edit dir2/file $ mtn revert dir2 --depth=0 # should revert the rename and leave the content change but fails it would be good to get this sorted out too. I think restrictions in general are poorly defined, which is one reason I never use them. If you say 'undrop file' you're using them! ;) The situation with revert might be better if it did do its work through the editable tree interface but getting this to work is difficult at best and it leaves open the possibility that revert will fail with mixed files/directories in the workspace blocking things from being reverted. One up-side of using the editable tree interface would be that revert wouldn't leave all kinds of junk laying around after its done. - Do you have any specific ideas of things that could be defined or described better? - Is it that the existing documentation doesn't describe what is possible well enough? - Is it that various commands deal with things in different ways (revert in particular, but also add etc.) which makes it feel like they are not well defined? - Is it that add a/b/c will add a, a/b and a/b/c and then commit a/b/c will fail because it has excluded a and a/b? - Is it that filenames are generally resolved against both the old and new roster to select nodes to be included or excluded? - Is it that the --depth option applies to all specified paths rather than to a specific path, allowing different levels of recursion for different directories? - Is it that you're not sure what will happen when you're about to say commit or revert with a set of paths? The intention is that the changes that get selected are *identical* for status, diff, commit, revert and the various list commands that apply to paths and there are tests to this effect. I believe that the set of nodes that get included based on a given list of paths and --exclude options is completely well defined. Whether this set is well defined for the operation it is used for might be another matter though as not all commands can or do use it. For example add doesn't have a set of nodes to select from so it has to do something slightly different. I do agree that committing part of a workspace can be considered bad practice in that you're essentially committing something that hasn't been tested but it happens often enough in reality that it seems like a necessary feature. Most other systems out there do allow this so we're not too far out in left field. 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.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
[Monotone-devel] bugfest analysis
Hi all!
Here is a little analysis of the recent bugfest efforts. Point proposals
from me are noted for In test issues. If no one else objects, please
close the issues I marked accordingly yourself:
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 :)
* #17878: Usability: too easy to accidentally fork after
merge or disapprove
- branch is net.venge.monotone.bugfest-2010.17878-tbrownaw
- @Tim: is this done?
* #13597: monotone update -b newbranch exhibits
incorrect behaviour
- @Stephe: whats your plan here?
* #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?
If you can't finish your work or just have added an informational
comment, consider removing your ownership from the bug again, so other
people can pick it up some time.
2) Assigned, In test issues:
* #5672: monotone explain
- won't fix is ok for me - if no one objects I'd close this issue
- points: 1 to Tim
* #7220: [NEED TEST] Monotone handles deleted files very ungracefully
- has been fixed in the mean time, closing is ok
- points: 1 to Stephe
* #8396: make merkle tree hash not include dormancy bitmask
- wtf meter: 100% - you're right about closing this one :)
- points: 1 to Tim
* #8535: [NEED TEST] monotone log has bad defaults outside a working
directory
- I'm ok with closing this issue - the -b foo to --from h:foo
thing can be considered a feature request
- points: 1 to Stephe
* #8549: handle tree-layout merge failure sensibly
- I'm ok with closing this issue
- points: 1 to Stephe
* #8916: Default database location
- no extra cookies for the import implementation, but probably
still closable
- points: 1 to Stephe
* #9235: [NEED TEST] File in repository with \ instead of /
directory separator
- paths are of course sanitized in the meantime, can be closed
- points: 1 to Stephe
* #9269: [NEED TEST] monotone log doesn't understand windows directory
separator
- net.venge.monotone.bugfest-2010.9269-stephen_leake
- test looks ok for me (can't execute it here locally, though,
since I have no windows machine) - can be closed if the test
works
- points: 2 to Stephe
* #12455: MT 0.16 can't access, if DB stored on NFS
- I tend to agree that this is set on won't fix, while it might
still be a smaller issue in monotone (we should probably not
segfault, but provide a good error message, can anyone with an NFS
setup confirm that?)
- points: 1 to Stephe
* #12773: show which branch a tag belongs to
- net.venge.monotone.bugfest-2010.12273-dscherger
- Patch looks cool, a test would be nice though. Wrt space issues,
we could shorten the revision to gain additional space - I think
the chance of finding two partial tagged revisions which can be
completed to two different full revision ids is rather low.
- points: 5 to Derek (if you add a test :)
* #13604: need 'undelete' ('undrop'?)
- net.venge.monotone.bugfest-2010.13604-stephen_leake
- patch looks largely cool, some minor objections:
revert = not undrop; - is the not operator portable?
bool undrop function argument - an enum would be cool :)
- possible issue left: undrop does not work correctly when
called on a dropped directory without --recursive. It still
re-creates all childs of the directory, while one would assume
that only the directory itself is recreated (and all the other
files keep dropped)
- points: 5 to Stephe (if the remaining issues are sorted out)
* #13706: allow passphraseless keys
- this has been fixed in the meantime, right (partially by myself)
- points: 1 to Richard
* #16021: monotone co [directory] not usage quite clear
- can be closed
- points: 1 to Richard
* #16069: log message handling assumes everything is in UTF-8
- we should have a test for this somewhere, right? @Richard: Could
you check if you find it and paste it as reference in the ticket
before you close the bug?
- points: 1 to Richard
* #16895: Better error reporting in permission-denied scenarios
- @Tim: Do you think of anything in particular (but not a very
good one)? Maybe this is worth a tiny patch...
- points: 1 to Tim
* #28805: Global --key option (and possibly others) are not reset
between stdio commands
- net.venge.monotone.bugfest-2010.28805-rlevitte
- @Richard: some objections
Why don't you allow the setting of signing_key with --anonymous
in workspace::get_options, if you return later on in keys.cc
early anyways if you encounter app.opts.anonymous, even before
app.opts.signing_key is touched there?
I'm also not sure if it is a good idea to ask for app.opts.anonymous
in keys.cc's get_user_key() -
Re: [Monotone-devel] bugfest analysis
On Sun, May 9, 2010 at 5:28 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?
I spent most of the day working on this and made some big changes
(reimplementing diff in terms of rosters rather than csets) but they didn't
actually fix the problem, which turns out to be somewhat complicated. I was
out for a long drive today and spent quite a lot of time thinking about it.
I have some ideas but I'm not yet sure if they'll work out or not. I'll
follow up with another email explaining the details.
* #12773: show which branch a tag belongs to
- net.venge.monotone.bugfest-2010.12273-dscherger
- Patch looks cool, a test would be nice though. Wrt space issues,
we could shorten the revision to gain additional space - I think
the chance of finding two partial tagged revisions which can be
completed to two different full revision ids is rather low.
- points: 5 to Derek (if you add a test :)
OK, adding a test should be easy. Do we have something to produce short
revision ids or should I just grab the first N chars or something?
* #13604: need 'undelete' ('undrop'?)
- net.venge.monotone.bugfest-2010.13604-stephen_leake
- patch looks largely cool, some minor objections:
revert = not undrop; - is the not operator portable?
bool undrop function argument - an enum would be cool :)
- possible issue left: undrop does not work correctly when
called on a dropped directory without --recursive. It still
re-creates all childs of the directory, while one would assume
that only the directory itself is recreated (and all the other
files keep dropped)
- points: 5 to Stephe (if the remaining issues are sorted out)
I'm somewhat curious about this one but I haven't looked at the bug or the
fixes yet. Is undrop/undelete somehow different from revert or is this just
a command alias?
Other than that I'm quite happy with the results. We've closed many bugs
and I think we should do that again some time in the future to bring
down the bug count even more.
Agreed. I personally find having a few people around working at the same
time is quite motivating.
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On 05/09/2010 06:28 PM, Thomas Keller wrote: * #17878: Usability: too easy to accidentally fork after merge or disapprove - branch is net.venge.monotone.bugfest-2010.17878-tbrownaw - @Tim: is this done? It needs a test using the --update option, which I'll get to either in the morning or after work tomorrow. I suppose I should also put a note in NEWS about setting your get_default_command_options() if you want to always have that behavior. * #16895: Better error reporting in permission-denied scenarios - @Tim: Do you think of anything in particular (but not a very good one)? Maybe this is worth a tiny patch... - points: 1 to Tim I think it's improved since that post. Other than that I'm quite happy with the results. We've closed many bugs and I think we should do that again some time in the future to bring down the bug count even more. Maybe try for every 6 months or so? If it's too often we'd probably get lower participation on any particular date, which wouldn't work at all at our size. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
