Re: [Monotone-devel] status --brief

[Daniel Carosone]

On Mon, Oct 03, 2005 at 08:43:12AM -0700, Nathaniel Smith wrote:
> If we do the "magic selectors" thing that another thread has been
> throwing around, the above is spelled
>   $ monotone diff -rB: -rU:

exactly my point (modulo 'diff -q' to just get the filenames :)

> > If we imagine these two queries renamed as something like:
> >  $ monotone list uncomitted (or local_changes?)
> >  $ monotone list updates (or branch_changes, head_changes, ..?)
> 
> Hmm, not sure; "list" seems to be kind of over-used and confusing
> already...

Well, ponder on it a while, but at least "uncommitted" (or similar
name) seems to me as exactly the right place for the list of filenames
you had as "the bottom part of status --brief" in your earlier mail.

The fact that there are lots of things you might want to list doesn't
make it wrong, even if some of them turn out to be basically
convenience shorthand aliases for something else, as above.

Another list might be "unmerged"; the files with divergence between
the current heads; again it might be convenience shorthand for cutting
and pasting hexid's reported by "heads" to "diff", or magic selectors.
Especially as a new user, having visibility of what's about to happen
safely helps me gain confidence and understanding of the software.

I can easily imagine using sdiff or some set-type operations with
shell tools to find interesting intersections of these lists.
union(updates, missing) might represent files I have edited offline,
but someone has deleted from the fileserver, for example (see awkward
use-case, below). Dunno, but this seems like a good way to discover
useful common queries that could be added later, too.

What does seem to be a little mixed up with list is that some lists
relate purely to the repository, some more to the working dir.  I'm
not sure it's a problem, but something to keep in mind for future, or
even just for clarity in doc work.

> > Because branches are sticky, but revisions and tags and other checkout
> > selectors are not, "out of date with respect to the branch" is also an
> > important part of the status of a working directory.  
> 
> Interesting point.  I'm a little dubious about scaring users by
> sticking in a "working copy is out of date" line in, because it will
> encourage people to think like that means they _should_ update, which
> is the sort of thinking we'd like to train people out of...

Yeah.  I was just following a line of thought - factoring out the
hypothetical list form, I was trying to find a sensible definition of
"status" that wasn't redundant, but also wasn't horrendously detailed
(like inventory).  It already seems to combine key useful facts from
several other queries, I guess it's a matter of picking which are most
relevant.  To wit:

> > Ideally, "status" would consolidate and summarise (rather than
> > concatenate) information I can get from more specific commands.

A brief form might even list just file counts: 6 files changed
locally, 3 deleted, ...". This highlights "status" as a quick summary
query for "what other queries do I need to look at more carefully?".

I take your point about training users' thinking by what you display
(I made similar comments recently in another thread), but be careful
of assuming too much about how people will use the software.  Some
checkouts exist purely for being updated (never intended to have local
changes), but the update step must be done only under certain
conditions: a copy of html content in the production web server's doc
root is a common example.  Other constraints can apply that break the
intended usage practice; more examples below.

Granted, the common reporting output should support the
common/recommended usage practice, so long as the information needed
for more advanced usage is available in more advanced queries.

> > Sometimes I just want to know
> > "will I lose anything if I blow away this old checkout?" (in which
> > case I should also "list unknown", hmm..)
> 
> Yeah, and even "list ignored", possibly...

Maybe so, yah. 

I've included a more verbose discussion of some of my use cases below,
to illustrate some of the motivation and perspective behind my
comments.

The ignored case isn't so important for dirs I'm likely to ever
consider blowing away at all, at least for my usage. I use CVS (and
now monotone) for keeping revision history and cross-machine
replication of a lot of in-place files: my ~, /etc, stuff on file
shares I need access to offline, and so on.  

This is different in that often I'm the only user of the VCS, but I
must account for changes others make outside the VCS in the working
dirs. CVS warts make this hard, but I've been doing it this way for
many, many years and I've found ways to work with them; monotone is
turning out much better.

In at least one respect, monotone is exactly what I need for this,
because there's no common point of connectivity from all machines for
a CVS repository. I keep a .monodb on a flash widget, and netsync
locally with that as I move around some sites (being selective about
which sites see which branches).  I was glad to see others with
similar perspectives recently, and SNAIL is a great term :)

I'd make much heavier use of it, but for the horrendous CPU usage with
large files; I'd like to use it for replicated mp3 files, digicam
pics, etc, too.  These are collections that are added to, and
sometimes rearranged, but rarely deleted (so the db size is
manageable). I have high hopes for the string-handling fixes I see
being discussed.

Anyway, the point being that I often need to ignore a lot of files,
because the directory structure isn't my choice and I'm only
interested in partial subtrees.  I don't want to blow the primaries
away, but I might blow away working checkouts (which are unlikely to
hold ignored files, and which are entirely mine).

It's also why I'm often keenly interested in what damage I might do
next time I update, and in the contents of the various lists more
generally.

I also use CVS with nested checkouts to deal with some of this
in-place structure; for example my ~/Mail is in a different repository
to ~, because it's large and private and I don't want it checked out
or netsync'd on all machines.  Thus ~/.cvsignore lists Mail.  On
update, CVS will happily recurse from ~ into Mail, find a new
CVS/Repository, and work from that - but in this case I don't want it
to, so I stop it with ignore.  I haven't yet tried this with monotone,
but expect it will need to work this way always if nesting; I'm about
to try with the new .mt-ignore stuff.  A quick test just now suggests
that "cp .cvsignore .mt-ignore" DTRT.

--
Dan.

pgpPk2cUFPA84.pgp
Description: PGP signature