monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Contributed scripts and how to handle them...


From: CooSoft Support
Subject: Re: [Monotone-devel] Contributed scripts and how to handle them...
Date: Sat, 05 Feb 2011 10:05:47 +0000
User-agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)

I nominate mtn-cleanup, not just because I wrote it :-) but it is also quite useful especially when used on large source trees (> 900MiB) or over NFS. Works with current monotones as well as old ones.

Basically it reverts a workspace to a clean checked out state, doing a revertion and then an rm -rf on anything not known to mtn (you are warned first).

Also put in a vote for the bash completion scripts (although I think they are safe).

Tony.

Richard Levitte wrote:
Sparked by a (somewhat heated ;-)) discussion I had on IRC with Thomas
in late december (*), I've started thinking that the contrib directory, while having served us well for a while, might not serve everyone who
wishes to contribute their little nuggets, or have them maintained
separately without having to have write permissions on n.v.m.

Looking at the contents of contrib/, there are things that are aged or
completely superceded by newer monotone commands, or other scripts and
so on.

So, following what Thomas was thinking, we probably should clean out
the contrib directory and put the contents somewhere else, except for
scripts that we really want to ship as part of monotone (and that we
test).  Maybe a place on the wiki would be a start, with a page for
each contributed thing, either refering to a repo somewhere or with
the source directly in the page (similar to plugin contributions that
you can see with other projects).

I'd like to, however, keep the stuff that we use on code.monotone.ca
and the bash completion scripts (I'm about to write a test for it),
and perhaps a few others that are regularly used.  If you have a pet
script in there, please yell, and possibly provide a kind of test for
it.

Ideas are welcome for how the tests should be structured.  For fairly
obvious reasons, lua will not be enough (bash completion testing
requires the use of expect, there's not much lua in there ;-)).

Cheers,
Richard

(*) starting here:
http://colabti.org/irclogger/irclogger_log/monotone?date=2011-01-01#l54





reply via email to

[Prev in Thread] Current Thread [Next in Thread]