Hi,
Ulf Ochsenfahrt wrote:
And I think it is a really really bad idea if these two disagree in
which files are unknown, i.e., if mtn ls unknown doesn't list files
recursively, but mtn add --unknown does add them recursively.
Hmm... I've read through the archives (especially the thread at [1]) and
thought about this issue. Before continuing on debating on recursiveness
of our commands, I'd like to distinguish between recursing into known
and recursing into unknown directories. Let's see what we currently (as
of 0.33) have:
recurses for recursive for
known dirs unknown dirs
mtn commit foo/ yes n/a
mtn diff foo/ yes n/a
mtn log foo/ yes n/a
mtn add foo/ n/a no
mtn add --unknown yes no
mtn add foo/bar/x yes yes
mtn drop foo/ yes n/a
mtn drop --missing yes n/a
mtn add foo/bar/x yes n/a
mtn revert yes yes
mtn ls known yes n/a
mtn ls missing yes n/a
mtn ls unknown yes no
mtn ls ignored yes no
.mtn-ignore yes yes
Obviously, we are very consistent regarding known directories: we
recursively iterate through them everywhere. And this is how it should be.
Looking at unknown directories, we are not very consistent. The add and
drop commands don't recurse into unknown directories, except if you want
to add a file in an unknown directory.
Similarly, 'mtn revert' happily re-adds complete directories and it's
contents, no matter if those were dropped recursively or one by one.
Another inconsistency, IMO, is the .mtn-ignore file. If you put an
unknown directory in there, it's a recursive ignorance: all the files in
the (unknown) ignored directory are ignored as well, you don't have to
add them all to .mtn-ignore.
Yet another inconsistency is the fact, that we handle unknown
directories different from known directories. Which, for example, leads
to the strange behavior of 'mtn add --unknown', which recursively
searches in known directories, but does not recurse into the directories
it has just added (and are known by now). (See Dan's example up thread [2].)
These three inconsistencies (plus my gut feeling) are the main reasons,
I'm voting for making all these commands recursive by default. Including
'mtn add', 'mtn drop' and 'mtn ls unknown'.
AFAICT, 'mtn add' has been made non-recursive between version 0.30 and
0.31. I've only found few discussion about why, see [3]. Making 'add' as
well as 'drop' recursive by default does not harm, because 'mtn revert'
easily (and recursively) reverts the addition or deletion. However,
especially for automation purpose, we probably need to add a '--depth'
argument, or at least a '--non-recursive'.
Derek's complaint [1] about 'mtn ls unknown' showing so many files lead
to making 'mtn ls unknown' non-recursive. But I'd argue that this should
better be handled by .mtn-ignore. Additionally, I'd like to point out,
that letting monotone handle the home directory is a little bit a
special case. Most people use monotone to handle source trees, where you
normally don't have so many unknown files.
Comments, arguments and corrections are very welcome, personal
preferences somewhat less. ;-)
Regards
Markus
[1]: thread: listing unknown directories:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9345
[2]: thread: Dan's example for strange behavior of mtn add --unknown:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/10651
[3]: a first patch by Ulf to change 'mtn add' to non-recursive.
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/8966
P.S.: looking at other VCSes, we see both: svn, hg, git and bzr add
recursively, while cvs, darcs and cdv don't. I don't know about or
haven't tested others.
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel