[Monotone-devel] Re: [RFC] ideas for an automate status command

[Bruce Stephens]

Derek Scherger <address@hidden> writes:

[...]

> Presumably such an automate command and would be named something like
>
>       $ monotone automate files
>       $ monotone automate inventory
>       $ monotone automate status
>
> any preferences? Somehow "inventory" feels to me like it would be
> listing things from the database (i.e. warehouse) rather than in the
> current working copy (i.e. my house) but I'm sure I could be convinced
> of otherwise.

I think you're right that inventory would be more suited to listing
files that are in the repository (like "monotone cat manifest" but
without the hash, I guess).  GNU Arch has other options: you can list
files which look like they ought to be in the repository but aren't,
and files which look like ignorable files (and more, I think).  

I'm less sure of the value of those, but knowing what are files from
the repository can be surprisingly useful.  Nonetheless, I agree that
"status" is the right name for what you're describing here.

> The next thing to work out is the output format for such a command. In
> thie following proposal, files are generally listed one per line, with a
> single character status preceeding them. For example:
>
>       ? file1
>       ~ file2
>       ! file3
>
> representing missing (?), ignored (~) and unknown (!) files
> respectively. note that this is not quite the same as svn, which uses ?
> for unknown and ! for missing I think and perhaps *not* changing this
> would be a better idea.

Yeah, I strongly agree that sticking fairly closely to what svn does
seems sensible.  In particular, using ? for what svn uses ! for, and !
for what svn uses ? for seems likely to cause confusion!

>       + file4
>       - file5
>       # file6
>       = file7
>
> representing added (+), dropped (-), changed/patched (#), unchanged (=)
> files respectively.

I think there's mileage in copying svn there, too, as much as is
feasible.  So using M for modified files, and A and D for added and
deleted files would get my vote.  I'm not sure what svn says for
unmodified files; I have a feeling it doesn't say anything.

Mostly I'm thinking about how I'd use it, and I'd find it most
convenient if it used the same characters as svk/svn/cvs.  It matters
a bit less if this is purely for automation, I guess.

[...]

> whether or not this should be an automate command is something else
> I'm wondering about. it seems that this format might be more like
> what people coming from cvs or svn would be expecting out of status
> or some similar command? an option (--all) to show all files, verses
> only the changes would probably be good in this case.

Yes, I think so.  It might be useful to have one designed for automate
(perhaps with a very regular syntax), too.

> after discussing this with njs on irc the other night we had arrived a a
> completely different format.
>
>       123 file
>
> where 123 are 3 or more different columns of status with 1 being the
> pre-state info, 2 being the post-state info and 3 being a flag
> indicating changes to the file. with adds represented as A in 1,
> drops as D in 2, renames as R in 1 for the old name and R in 2 for
> the new name, on two separate lines. also needed for renames would
> be identifier columns to tie the two associated lines together and
> to support the swapping and other more complicated rename cases
> mentioned above.

That sounds a nice syntax for automation.  I'm less sure it would be
so valuable for users: my guess is that the familiarity of "M
configure.ac", etc., would win out, even if it can't reflect the
precise state of things.  

I might be wrong, though: maybe I'd quickly get used to the form you
suggest above.  (If the latter, then maybe that's the right one to
implement first, just to see if a more cvs-compatible one is worth
bothering with.)