Branko, these comments all seem worth preserving imho; would you like
to just annotate alpha_checklist with them?
Regarding repository layouts in the branch|tag == copy scheme, here's
one way:
/myproject
/myproject/trunk
/myproject/branches
/myproject/tags
So for Subversion, it would be
/subversion
/subversion/trunk/
/subversion/branches/
/subversion/tags/
I think this is simple and foolproof, as you requested. I'll try a
theoretical justification: coming from CVS, a project has three
distinct "spaces": mainline commits, branches, and tags. These are
the only places where historical points get recorded. By replicating
these three spaces, and keeping them distinct, we must not be losing
any information, and the pathnames themselves make it fairly intuitive
what is what.
Well, that's not much of a proof. Mostly I have to just say "It feels
good to me." Thoughts?
-K
Branko Čibej <brane@xbc.nu> writes:
> 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/
Received on Sat Oct 21 14:36:29 2006