Re: [Monotone-devel] another patch (no checkin)

[graydon hoare]

Tom Tromey <address@hidden> writes:

> This patch lets you specify one or two revisions to `monotone diff'.
> It is analogous to using cvs diff -r.

this is fine in general, I think. as you say, we need to consider the
UI.

> One nice thing about the cvs approach is you can also run diff on a
> given file, or versions of a file.  Perhaps we could have a -r option
> (opening the door to options processing in the commands
> themselves...?).  I presume the argument to -r would be the manifest
> signature.

I am not enamoured with the idea of sub-command options, though sense
that perhaps they will eventually be inevitable. I feel they lead to a
lot of confusion about where to specify them and which combinations
are valid. on the other hand, the same can be true of purely
positional grammars. so.. I'm not sure. really not sure.

> It may make sense to look at subversion to see what UI they have
> picked.  There really is a fair amount of commonality here between
> different version control systems, I think, despite their other
> differences.  And I know the svn guys have put a lot of thought into
> it.

true. there's no sense making a system which is different just for the
sake of being different. I just don't want to repeat mistakes of the
past. how often did people complain about a CVS "bug" because they put
some option before 'co' rather than after it, or vice versa? I don't
know. if it's a problem I don't want to repeat it.

> BTW in the patch there are apparently spurious whitespace differences.
> I don't understand that, unless it is something emacs did
> automatically.  According to the patch text these aren't even changes
> -- monotone bug perhaps?

is this the output from "monotone diff"?

monotone diff is implemented internally, using an implementation of
myers' LCS I picked up from boost. it does not invoke "diff". see the
file diff_patch.cc. I am reasonably certain it contains bugs, and I am
sure that it is unacceptably slow. needs profiling and some bug
fixing. it doesn't represent crucual functionality for day-to-day
operation -- packets don't use it at all -- but producing bad diffs is
pretty bad. I'd like to get it cleaned up. can you save the files on
either side of your example, and send them as a testcase?

-graydon