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] diff bug 20447
Am 10.05.2010 06:06, schrieb Derek Scherger: At the moment these changes result in slightly different diff output for additions and deletions which both now use /dev/null for one file (the source for adds and the target for deletes). There's a big comment in diff_output.cc that made this seem like the right approach. This new implementation currently does output a diff against /dev/null for a deletion where previously we simply didn't display anything. I'm not sure which is preferable but it's trivial to change, maybe we even want an option to control this? The new implementation also shows the both names involved when a rename occurs although I'm not sure if this is such a good idea as it may confuse patch and friends. Changing this is also trivial. It always stroke me quite odd why our diffs contain file additions, but not deletions, especially since this is the only way to tell standard patch tools to delete the file / the contents, so this change is greatly appreciated. Other than that we should test if standard patch accepts the rename information (and even acts accordingly) - if yes, this should not be a problem, since most tools behave patch-compliant anyways. This problem is closely related to the problem of adding a directory d, then adding a file f to it and then restricting a commit to just the file d/f which fails because the directory addition is excluded. One fix for this would be to change the restrictions code so that including a file implicitly includes changes to all of its parent directories (non-recursively). So a commit of d/f would include d and d/f but not other children of d. I'm not sure if there are other ways we could deal with this. In the case of mv d d2 above if we include parents of f committing d2/f would also commit the rename of d to d2. This would effectively rename all other children x of d to d2/x as well which seems somewhat questionable, although it might be better than failing with 'mtn: misuse: file d/f does not exist'. I'm also for this solution, because I think the parent rename is expected to happen as well from a user's point of view (well, at least mine, because I think this is much more consistent :). If the user doesn't want that other files change from d/x to d2/x, he simply has to commit the patch before he starts renaming anything. 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
[Monotone-devel] [bug #7221] [NEED TEST] monotone cert should not require its target be on a branch
Update of bug #7221 (project monotone): Open/Closed:Accepted = In Test ___ Follow-up Comment #4: test updated in b19661370e3fc21fb0a1b3c060ce7acc48737912 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?7221 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] What key does sync use?
hend...@topoi.pooq.com writes: The description of get_netsync_read_permitted (branch, key_identity) says Returns true if a peer authenticated as key key_identity should be allowed to read from your database certs, revisions, manifests, and files associated with branch; otherwise false. and there's similar language for write_permitted. Now, when I'm syncing with a server, presumably it's the server that vets keys provided by the client. When I issue the mtn sync command, where does the client obtain the key(s) it's sending to the server for approval? from the keydir; normally ~/.monotone/keys, settable by --keydir option on 'mtn checkout' And since sync is a two-way operation, where does the server get its key(s) to provide to the client? The user has told the client to accept updates from the server; it is the user who's authority needs to be verified. The user is responsible for knowing the trustworthiness of the server. So it is the same key, from the keydir. There is also a trust model that can provide more fine-grained control. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #7220] [NEED TEST] Monotone handles deleted files very ungracefully
Update of bug #7220 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?7220 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #8535] [NEED TEST] monotone log has bad defaults outside a working directory
Update of bug #8535 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?8535 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #8549] handle tree-layout merge failure sensibly
Update of bug #8549 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?8549 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #8916] Default database location
Update of bug #8916 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?8916 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #9269] [NEED TEST] monotone log doesn't understand windows directory separator
Update of bug #9269 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?9269 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #12455] MT 0.16 can't access, if DB stored on NFS
Update of bug #12455 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?12455 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] bug#13604: undrop
'undrop' is a new command; see nvm.bugfest-2010.13604-stephen_leake The purpose of 'undrop' is to revoke a mistaken 'drop', before it is committed. There is an issue about how to deal with the '--recursive' option. Currently, 'nodrop' allows '--recursive', but ignores it. That's so a user can do: drop --recursive dir (oops, discover mistake) undrop --recursive dir But undrop actually ignores the '--recursive' option. The question then is: Suppose the user wanted to drop dir/*, but not dir? 'undrop' (without --recursive) should restore just dir, but not dir/* I think the best thing to do here is disallow --recursive on undrop, and in effect assume --recursive for 'undrop dir'. Note that 'drop dir' without '--recursive' gives an error: mtn: misuse: cannot remove dir1/, it is not empty So it makes sense for 'undrop dir' to assume '--recursive' was given on 'drop'. Then the use case above would be: drop --recursive dir (realize mistake) undrop dir drop [--recursive] dir/* I think that's fair; first undo the mistake, then do the right thing. Trying to support partial undo could lead to a can of worms: drop --recursive dir1 (realize mistake) undrop dir1/file1 What would that do? Currently, this gives an error: mtn: warning: restriction excludes addition of 'dir1' but includes addition of 'dir1/file1' mtn: misuse: invalid restriction opinions? -- -- Stephe ___ 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] to be recursive or non-recursive that is the question
Derek Scherger de...@echologic.com writes: mtn add is non-recursive by default but allows for --recursive if you want it. mtn revert is recursive by default and doesn't allow for an obvious way of being non-recursive (I believe --depth=N will stop the recursion at the specified depth). A general --[no-]* option mechanism would help here (just building motivation for this). So, which is more dangerous (1) accidentally adding some files you didn't mean to add, or (2) accidentally reverting a bunch of changes you didn't mean to revert? Recovering from (1) is easy, just revert the additions you don't want. Since revert is recursive this is no problem! ;) Well, it is at least linear in the number of files/directories accidently added; not necessarily trivial :). Recovering from (2) is ... not so easy. If you happen to have all the reverted files open in editor buffers you might be able to write them back out but any pending renames will be messed up badly. It depends on what changes you are reverting. If you have edited a bunch of files, and want to revert only one, but accidently revert them all, that's a problem. On the other hand, if you are reverting an accidental drop, recursion is appropriate. 'undrop' makes this even easier; see the separate thread on that. One solution would be for 'revert' to move clobbered files to _MTN/resolutions if --move-conflicting-files is given, as update does. Better would be to have an option 'revert --exclude-changed-files' that would only revert files that are actually gone (because they were accidently deleted). I'm not clear about revert vs renames; can you give an example? $ mtn add a # non-recursive $ mtn add a/... # recusive $ mtn revert a # non-recursive $ mtn revert a/... # recursive I'm not sure how we'd represent a recursive revert of the entire workspace, maybe 'mtn revert ...' or something. Comments? I think this is clearer than the current state. But making it backwards compatible would be hard, I think. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] to be recursive or non-recursive that is the question
On Mon, May 10, 2010 at 08:37:35AM -0400, Stephen Leake wrote: Derek Scherger de...@echologic.com writes: mtn add is non-recursive by default but allows for --recursive if you want it. mtn revert is recursive by default and doesn't allow for an obvious way of being non-recursive (I believe --depth=N will stop the recursion at the specified depth). A general --[no-]* option mechanism would help here (just building motivation for this). Perhaps revert should have no default. You'd always have to explicitly specify --recursive or --nonrecursive or --norecursive. Except maybe if there are no subdirectories so the difference is moot. -- hendrik ___ 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] RFC: lua output redirection
Am 08.05.10 14:34, schrieb Thomas Keller: Cool, other opinions? If no one objects, I'd commit this change tonight together with a small test to mainline. 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: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] to be recursive or non-recursive that is the question
Am 10.05.10 06:21, schrieb Derek Scherger:
mtn add is non-recursive by default but allows for --recursive if you want
it.
mtn revert is recursive by default and doesn't allow for an obvious way of
being non-recursive (I believe --depth=N will stop the recursion at the
specified depth).
So, which is more dangerous (1) accidentally adding some files you didn't
mean to add, or (2) accidentally reverting a bunch of changes you didn't
mean to revert?
Recovering from (1) is easy, just revert the additions you don't want. Since
revert is recursive this is no problem! ;)
Recovering from (2) is ... not so easy. If you happen to have all the
reverted files open in editor buffers you might be able to write them back
out but any pending renames will be messed up badly.
I'm all for making revert non-recursive by default. While letting revert
acting recursively on the tree matches up with what f.e. subversion
does, it has always been a major headache for me to circumvent this with
dubious options, especially if directory attributes had to be reverted.
There's an old branch net.venge.monotone.restrictions.wildcard-paths that
once tried to add something like the foo/bar/... suffix that perforce uses
to indicate recursive behaviour and perhaps we should consider doing this
again. This might help clean up add, revert, status, diff, commit, etc. and
allow the --depth option to be retired.
i.e.
$ mtn add a # non-recursive
$ mtn add a/... # recusive
$ mtn revert a # non-recursive
$ mtn revert a/... # recursive
I'm not sure how we'd represent a recursive revert of the entire workspace,
maybe 'mtn revert ...' or something.
This is actually a nice idea - though we probably have to prohibit file
names like ^\.{3,} for that to work properly. It would certainly help
/ avoid the code clutter we have with the various --depth, --recursive
and so on option code.
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] to be recursive or non-recursive that is the question
Am 10.05.10 14:37, schrieb Stephen Leake: One solution would be for 'revert' to move clobbered files to _MTN/resolutions if --move-conflicting-files is given, as update does. I think not having --move-conflicting-paths here is a completly different issue and could arise for any implementation of revert. Stephe, could you file a bug or alternatively add an xfailed test for that? I think we should handle that some time in the future. Better would be to have an option 'revert --exclude-changed-files' that would only revert files that are actually gone (because they were accidently deleted). This is similar to what Derek proposed in the other mail, giving options to revert of what should actually be reverted. But this sounds rather hard to implement and we should elaborate if this is really a often needed use case. Way more often should be the use case revert parts of patch hunks of individual files like git does, but we're missing a staging area for that purpose. Completely different topic :) Recovering from (2) is ... not so easy. If you happen to have all the reverted files open in editor buffers you might be able to write them back out but any pending renames will be messed up badly. I'm not clear about revert vs renames; can you give an example? I think what he meant is the following: $ mtn mv a b $ edit b $ mtn revert b $ edit / save b again You end up with an unknown file b because of course your editor doesn't get the info that the rename was reverted. 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
[Monotone-devel] [bug #29849] add --move-conflicting-paths to revert
URL: http://savannah.nongnu.org/bugs/?29849 Summary: add --move-conflicting-paths to revert Project: monotone Submitted by: stephen_leake Submitted on: Mon 10 May 2010 07:04:44 PM EDT Category: command line UI Severity: 1 - Wish Item Group: feature request Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any mtn version --full: ___ Details: 'revert --move-conflicting-paths' would be the same as current 'revert' for files that were deleted from the workspace. But for files that are still present, and different from the base revision version, would be preserved in _MTN/resolutions, as for 'update --move-conflicting-paths'. That way, the user can restore the changes if desired. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?29849 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #13597] monotone update -b newbranch exhibits incorrect behaviour
Update of bug #13597 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?13597 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ 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
[Monotone-devel] Why are io.popen() and os.execute() disabled again?
Hi! I'm in the process of improving our Lua documentation a bit, also in respect to the recent changes in print() / io.write() behaviour and I wanted to include a sentence or two about the above mentioned disabled functions. And then I started wondering why we disable these two functions at all - especially since we replace them with two other custom calls... I know Graydon committed this initially in c6b551a24d7e2fd97d87aace1f03cabece12f8b7 back in 2005 and I found a reference on the list (http://www.mail-archive.com/monotone-devel@nongnu.org/msg02464.html), but both don't bring me further. Can anybody please shed light into this issue? Thanks, 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] Why are io.popen() and os.execute() disabled again?
On 05/10/2010 06:40 PM, Thomas Keller wrote:
Hi!
I'm in the process of improving our Lua documentation a bit, also in
respect to the recent changes in print() / io.write() behaviour and I
wanted to include a sentence or two about the above mentioned disabled
functions. And then I started wondering why we disable these two
functions at all - especially since we replace them with two other
custom calls...
I know Graydon committed this initially in
c6b551a24d7e2fd97d87aace1f03cabece12f8b7 back in 2005 and I found a
reference on the list
(http://www.mail-archive.com/monotone-devel@nongnu.org/msg02464.html),
but both don't bring me further.
Can anybody please shed light into this issue?
The changelog there says disable bad lua functions from monotone, not
lua library, and it also touches lua/liolib.c.
What it removes there is:
| -
| - /*
| -monotone specific: we're disabling io_popen here because
| -it calls shell, and is thereby a horrible security hole in
| -waiting.
| - */
| -
| - /* {popen, io_popen}, */
| -
...which first showed up in 73c79720e2948734647b5e4393c1cfbca0b1d073, on
2/3/2005.
So that means the purpose is to not have to worry about things like
properly quoting any evil shell metacharacters in the filenames you give
your external merger.
--
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
[Monotone-devel] Please review nvm.experiment.lua-output-redirection
Hi! I've committed my recent lua-related changes to the above mentioned branch. Please review that again, especially the documentation changes since I'm still not a native speaker... I also want to include some documentation why io.popen and os.execute is disabled (see the other mail) - if somebody could step up and write this for me then I'd be very grateful :) Thanks, 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
[Monotone-devel] hello and thanx
Nice to see lots of bugs squashed :) I have to thank you for developing a sane product. I have been coerced into using mercurial at work, and after coming from monotone, some of the things it makes me do are just insane. Merge, for instance, must be done through a workspace, so in order to just merge two heads, If I had work in progress in the tree, I have to clone the repository to another directory, check out the source(ya that's the same step), and then do the merging; A commit from a merge cannot be done with relative paths like 'I want to commit just this part of the tree', you have to commit the whole thing, so work in progress changes would get mixed up in the whole thing. The revisions to merge are all in the repository, so why does it require a workspace?! Git does the same thing in this respect. I dunno, this seems like such a small thing, but it pisses me off to no end that I have to do so much extra work just to make sure that sane merges happen. Rebasing to another branch in mercurial and git are both very slow. (coming from branch) mtn update -r h:branch1 (takes like 3 seconds, 6 if i count the time it scrolls text) hg update -r h:branch1 (takes like a minute) and there were more files changed in the mtn difference between branches than were changes in mercurial. git also gave me a huge hassle rebasing to another branch... I had minor edits in the files, and it had no idea what to do with that... and revert didn't work.. but that was a month ago, so the details of my anger elude me. Again, thanx, keep up the great work! Wish you guys get a gui soon! what with tortoise hg, git, and svn out there (is there a tortoise bzr yet) ... should be easy enough to grab one of those and tweak it to fit monotone. Jim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] hello and thanx
Nice to hear that monotone is so much faster than git and mercurial for certain operations. Hugo On Mon, May 10, 2010 at 7:31 PM, J Decker d3c...@gmail.com wrote: Nice to see lots of bugs squashed :) I have to thank you for developing a sane product. I have been coerced into using mercurial at work, and after coming from monotone, some of the things it makes me do are just insane. Merge, for instance, must be done through a workspace, so in order to just merge two heads, If I had work in progress in the tree, I have to clone the repository to another directory, check out the source(ya that's the same step), and then do the merging; A commit from a merge cannot be done with relative paths like 'I want to commit just this part of the tree', you have to commit the whole thing, so work in progress changes would get mixed up in the whole thing. The revisions to merge are all in the repository, so why does it require a workspace?! Git does the same thing in this respect. I dunno, this seems like such a small thing, but it pisses me off to no end that I have to do so much extra work just to make sure that sane merges happen. Rebasing to another branch in mercurial and git are both very slow. (coming from branch) mtn update -r h:branch1 (takes like 3 seconds, 6 if i count the time it scrolls text) hg update -r h:branch1 (takes like a minute) and there were more files changed in the mtn difference between branches than were changes in mercurial. git also gave me a huge hassle rebasing to another branch... I had minor edits in the files, and it had no idea what to do with that... and revert didn't work.. but that was a month ago, so the details of my anger elude me. Again, thanx, keep up the great work! Wish you guys get a gui soon! what with tortoise hg, git, and svn out there (is there a tortoise bzr yet) ... should be easy enough to grab one of those and tweak it to fit monotone. Jim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Hugo -- Hugo Cornelis Ph.D. Neurospaces Project Architect http://www.neurospaces.org/ Laboratory of Neuro- and Psychofysiology ON I Herestraat 49 - bus 1021 3000 Leuven, Belgium Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 ___ 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] bug#13604: undrop
On Mon, May 10, 2010 at 5:53 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: drop --recursive dir1 (realize mistake) undrop dir1/file1 What would that do? Currently, this gives an error: mtn: warning: restriction excludes addition of 'dir1' but includes addition of 'dir1/file1' mtn: misuse: invalid restriction opinions? If we change things so that parent directories of selected files/dirs are implicitly included (non-recursively) I think this would be able to do what you expect, undrop dir1 and dir1/file1. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] to be recursive or non-recursive that is the question
On Mon, May 10, 2010 at 3:20 PM, Thomas Keller m...@thomaskeller.biz wrote: I think what he meant is the following: $ mtn mv a b $ edit b $ mtn revert b $ edit / save b again You end up with an unknown file b because of course your editor doesn't get the info that the rename was reverted. You don't even need to edit /save a second time. Revert just recreates the old file and leaves the renamed b sitting there. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] to be recursive or non-recursive that is the question
On Mon, May 10, 2010 at 3:10 PM, Thomas Keller m...@thomaskeller.biz wrote:
$ mtn add a # non-recursive
$ mtn add a/... # recusive
$ mtn revert a # non-recursive
$ mtn revert a/... # recursive
I'm not sure how we'd represent a recursive revert of the entire
workspace,
maybe 'mtn revert ...' or something.
This is actually a nice idea - though we probably have to prohibit file
names like ^\.{3,} for that to work properly. It would certainly help
/ avoid the code clutter we have with the various --depth, --recursive
and so on option code.
Agreed.
I have somewhat mixed feelings about it though. It's not exactly standard
shell syntax which is not so good, but trying to do this with options
doesn't really work either. I'm not sure what we'd do about the backwards
compatibility concern raised upthread, other than call this a breaking
change.
One other thing, I think there is some requirement (maybe desire is a
better word) in the tests for the ability to select a directory and it's
immediate children but not their children, although I can't remember the
details. Maybe just using foo and foo/* would be the thing to do in that
case.
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
