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
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
- 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.
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/
Received on Sat Oct 21 14:36:28 2006