new mr patches on their way (not quite ready yet though)

[Joey Hess]

Adam Spiers wrote:
> Thanks for the reply.  Sure - I can syphon those commits off into a
> stow branch.  It bothered me too that they were non-contiguous.  In
> fact, I appreciate that just dumping a whole load of uncategorised
> commits on your doorstep isn't particularly helpful, so maybe it's
> better if I create a branch for each change, and then point you at
> each branch.  Would that work for you?

There's no need for a separate branch for self-contained changes.

> Regarding color: well, I'm not sure on what level the question is
> asked, so forgive me if I'm treating a more technical question as a
> philosophical one ;-) If it's whether the use of color makes the
> program any more useful, then I guess it's a matter of individual
> taste, and I'm aware that some people don't like it.  Each to their
> own, but personally I find that rather mystifying - after all, how
> many people do you know who use a web browser which renders everything
> in black and white?  Or even within the terminal / CLI environment,
> how many people dislike the colors generated by ls(1) or git enough to
> go to the trouble of disabling them?

I have not looked at the colors in use here, but IME adding color to
terminal programs is often badly done, resulting in an angry fruit salad
effect, and often needing additional configuration to disable it, or
to tweak the colors to ones visible for colorblind users or users who
cannot read yellow text on a white background. Which I can put up with
in a mail reader, git diff, or a text editor, but given the very small
amount of output done by mr, seems likely excessive. I suppose the idea
is to pick out errors from amoung the rather larger amount of output
displayed by the version control system, but mr already tries to
structure its output to make it easy to do that.

> Regarding debug levels: without a more fine-grained approach to
> logging, it would have been too hard for me to understand mr's
> internals and achieve all the development I was able to.  A large part
> of the challenge for me was understanding the order in which mr parsed
> / executed things etc. and the original -v was way too verbose to be
> able to trace this - it would have required me to keep too much stuff
> in my head at once.  In fact, there were a few minor bugs which I
> spotted precisely because I entered this debugging exercise.
> 
> Having said that, I freely admit that a debugging system based on
> numeric levels isn't particularly elegant or sophisticated, and I'd be
> happy to see something better.  But it's a very standard technique
> industry-wide (c.f. syslog and hundreds of other logging software
> projects which use the concept of "priorities" or "severities"), and
> it was also The Simplest Thing That Could Possibly Work.

I have never seen such a debugging system in which I did not use exactly
two modes: none, or "turn the dial to 11 and grep for the thing I
actually wanted".

> Because it's up to the end user whether he wants to stow the
> repository or not, and that decision is entirely dependent on the
> context in which the repository is being used.

But is there no way to tell if a repository is stowed? Why couldn't the
checkout just handle registering it with stow (or whatever), and then
the other actions could check to see if it was so registered.

> Wanting to use mr to manage the download and installation of a piece
> of software is weird?  Or the implementation is weird?

Wanting to use mr to manage software not in version control is weird. :)

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20111201/dab1b2eb/attachment.pgp>