Re: [Gnu-arch-users] GNU Arch review - am I accurate?

[David A. Wheeler]

Thanks for all the feedback - here are a few replies.

When I said:
>> * Is anyone currently working on automated caching?

Jan Hudec replied:
> If you mean automatic creation of cached revisions, I have not
>heared about it, except it's a trivial shell script to set as hook.

What I want is for the tool _defaults_ to "do the right thing".
E.G., "every X versions or when the patches are Y% of the previous
cache/baseline, create a new cache, and delete the Zth
old automatic cache since it probably isn't needed".
Manual control over caching, and controlling various performance
parameters, are useful.  But by default, arch should take advantage
of the information it has available to it, and do the "right thing"
automatically to give reasonable performance.

I shouldn't have to set up hooks, or give caching commands, in
the normal case just to do cache management... it should only
be necessary for special circumstances.  The Linux kernel gives
me all sorts of control over scheduling, but normally it
divines the "right thing to do" and I don't have to touch it.

I asked:
> > * Is it even slightly plausible to change the default
> >   filename/tagname conventions so arch will
> >   work more easily with common tools (e.g., vi/vim, more, csh,
> >   bash, Windows (it doesn't handle long names well))?
> >   Conventions are so arbitrary, yet the ones arch uses
> >   seem designed to cause unnecessary problems.


Jan Hudec replied:
>If you mean the builtins -- `,' for temporary and `+'
>for precious -- what other characters would you prefer?
>All the rest is fully customizable -- just rewrite {arch}/=tagging-method

Having userspace naming conventions is good and even necessary, and the
the leading "," is fine (that's an old convention that doesn't
interfere with any tools). But I think the text of:
 http://wiki.gnuarch.org/moin.cgi/FunkyFileNames
gives excellent evidence that the conventions should be changed!
If you have to justify the problems caused by an arbitrary choice,
and explain work-arounds for them, maybe another choice should be considered.
I know that some things can be changed, but the tool itself generates
some files, and besides, it's important that the defaults and
recommended practices be the best for most cases.

The leading "+" interferes with all kinds of tools, including
vi, vim, and more (and others too -- in fact, using a leading "+"
for options is surprisingly common).  This is directly visible to
users, and interferes with one of the most popular text editors around.

Why not use a TRAILING "+" as the default, instead of a leading "+"?
To make a reasonable transition process, the built-in
defaults could allow both leading and trailing "+", but
log files would be created with the trailing "+" instead of the leading "+".

Although it's not as serious, the leading "=" triggers a bash bug,
probably the most popular command shell, and it'll be a LONG time
before that's fixed EVERYWHERE.  Again, why not have a _trailing_ =?
I've tried out trailing "=", and bash handles those fine.
Making arch transition to use trailing "=" everywhere would be
a lot more trouble, but at least trailing "=" could be the default for
user-space filenames.   Since there will
need to be changes to the internal data format anyway to handle
spaces in filenames, perhaps switching "=" conventions
could be handled at the same time.

For consistency, you could always allow both leading and trailing
typing characters (,+=) as the defaults used by arch.
That way the transition is simple, and userspace filenames
can be handled more easily by common tools.

It's probably hopeless to change now, but filenames with "{}"
like "{arch}" are a real pain in C shell.  "cd {arch}" and
"vi {arch}/whatever" won't work, for example, because "{}" are
globbing characters that C shell normally strips
(you have to quote the filenames).  Since people shouldn't
normally edit anything inside {...} directories, and it'd be
horrendous to change, I guess that's probably not worth changing.


> > * Is there any reason that "mv" and "move" couldn't be the
> >   same thing (and let mv-id or an mv flag be the id mover)?

rbcollins replied:

> None at all. It's UI fluff, and if you increase consistency and
> orthogonality, your patch has a good chance of being accepted.

With all due respect, I disagree that UI is "fluff".
A good UI for a bad engine won't make the engine better,
but an inconsistent, confusing, or painful-to-use UI
can obscure a good engine.  A command line tool should
still have a good UI.  Layering is a good design approach,
but it shouldn't be used to hide a bad UI; the UI underneath
should be fixed instead.  Even if you want to layer things,
a good low-level UI makes it easier to build higher-level tools
(and understand them later).

But I _would_ agree that this is a localized fix (which I'm
guessing is your point).  I've sent a separate email suggesting
some changes to command names to make things clearer, and
if it seems likely such a patch would be accepted, I'll
create and submit a patch.

_Good_ command names are harder to create than it appears, though.
For example, "delete" and "rm" do different things,
and that's confusing (many OS's and aliases make them
identical).  I suggested "rm-id" earlier, but I think it'd be
better to use the command "subtract" as the opposite of "add".
"Delete" could be aliased, but deprecated.  Maybe you don't
agree with that, and that's fine.  My point is that creating
a good UI (including clear names) only looks easy when you're done :-).

When I said:
>> * Is there any reason that "mv" and "move" couldn't be the
>> same thing (and let mv-id or an mv flag be the id mover)?

Dustin Sallings said:
>It does seem a bit unlikely that someone would want to move *only* a
>tag. I suppose the use case would be someone who moved something and
>forgot to move the tag, and would want to go back and move the tag.
>Then again, it might be just as easy to move the file back, or use an
>``id only'' flag.

Actually, an "id only" flag for "mv" looks like a better idea than
a separate "mv-id" command.  Such a command is needed only rarely, and
a special flag to do it makes sense.  For transition purposes,
the current "mv-id" command could stick around but be deprecated.

I asked:
>> * Has anyone thought about the "signing of signing" issue
>> (A signs A's code, B accepts it, C accepts B's, and we
>> have a chain of signatures from all 3 showing the transition)?...

Jan Hudec replied:
>Don't think it has actual use. Moreover, no, it's not possible,
>since the diffs are combined on merge, so the parts are not
>there to be signed.

I very much want to know "where did this code come from",
transitively.  Couldn't the signatures be stored in the working
directory, so that on a merge this data could be logged?

I asked:
>>* Is there an intent to fix the remaining problems in the
>> native Windows port (e.g., symlinks, newline oddities)?

Aaron Bentley replied:
>The only newline problems I'm aware of are the fact that some Windows
>tools can't edit log messages because they don't understand Unix
>text-format files. But even Wordpad can do it. Or you can write a
>batch file or script to convert the newlines, invoke the editor, and
>convert the newlines back.

A tla port to Windows should know that it's running on
Windows.  It would be reasonable for a Windows tla port to
create log file using Windows newlines, and then convert the log
files back to Unix newline format (treating Unix as canonical).
I would agree that fixing source code newlines is a dangerous
path almost certainly not worth going down.



--- David A. Wheeler <address@hidden>