Alphe-checklist comments

I have a few comments about the alpha checklist. This may be a bit
late, but ...

> I. Implementation Questions
> ---------------------------
>
> D. Auto-detection of text/binary file types. Use it for keyword
> substitution, line-ending conversion, and merging.
>
> ANSWER: This will be solved by three separate properties:
> - mime-type. We will have a heuristic that determines as best it
> can what the mime-type of a file is (of course it will be
> user-configurable).

We should look in the standard locations for mime data on the
platforms where it's available; /etc/mime.magic on various Unices, the
registry on Win32, etc.

> - Keyword Substitution (BOOL)
> - Newline Translation (BOOL)

I think it would be better to make these values (a list of) keywords
instead of plain switches.

 - For keyword substitution, you could enable only a subset of the
   available keywords -- e.g., turn of the infamous $Log$.

 - Newline translation might have the following values:

   - "none": No translation; default for binary files

   - "native": Use whatever the client platform's own line separator
     is; this would be the default for plain text files

   - "unix", "dos", "mac": force newlines to \n, \r\n or \n\r,
     respectively; for instance, MSVC's .dsp and .dsw files would
     need "dos" translation.

> II. Missing Features (that are needed to match CVS)
> --------------------
>
> D. How will we present branches and tags to the user? Show them as
> subdirs, or hide them under a cvs-like interface?
>
> Answer: we won't hide the implementation... BUT: we will not
> call them "branches" and "tags". We'll only talk about "copies"
> instead and try to educate the public this way.

I'm a bit worried about this idea. We may very well talk about
educating the public; but first, we must know what we're talking
about. I won't go so far as to say that this model is
counter-intuitive, but it's definitely a lot different from what I,
and probably most of us, are used to. So:

 - How certain can we be that exposing the implementation of tags and
   branches like this will really be easy for users to understand?
   It's taken me long enough to grok what JimB was getting at, for one
   thing. :-)

 - We'll have to offer a simple, foolproof directory layout for
   storing tags and branches. Can we do that without actually using
   SVN for a reasonable amount of time on a large project? (Note: SVN
   itself is not a large project (yet), nor has it been around for a
   reasonable time.) Don't forget that whatever we come up with must be
   flexible enough for cvs2svn to use, too.

> IV. Post 1.0 stuff
> -------------------
>
> B. i18n/multilingual development.
>
> ANSWER: Post 1.0, but Jim will provide UTF-8 checking for paths in the
> filesystem for 1.0 to avoid problems in the future. Also, Fitz
> will (time permitting) look into a gettext-like implementation
> that are license compatible.

Just a reminder: the gettext implementation from glibc is LGPL. That
licence should be compatible, shouldn't it? In fact, I can get my
hands on a stand-alone gettext implementation, based on glibc-2.1 (I
think), that's currently being used on Linux, HP-UX and Win32.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/