-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 09 December 2002 17:44, sam th wrote:
> It should be noted that SVN fails requirement 0.
Some observations about the specific failures of the requirements:
(0): Well, it only partially fails requirement 0. I guess it's up to the GCC
people as to whether this is a "hard" requirement. I can't imagine that this
should be such a big issue as long as the major and most of the minor
architectures are covered. For the record, which architectures does CVS
support that APR does not?
(0b): Berkeley-DB requires write access in order to create lock files, and
AFAIK there is no way to fix this without using some other database. Would
an audit of mod_dav_svn (or ra_svn) be a good alternative for this
requirement?
(1): While Subversion passes all of (1a) through (1d), the every day
operations (checkout, status) are in fact slower, but not usually by a great
amount, and not in any way that can't be optimized in the future. The truly
braindead things about CVS, including network transfers, branching, and
tagging, have all been fixed as a feature of the basic design.
(2d): Subversion currently doesn't do "smart merging", but neither does CVS,
and it will in the future.
(2f): I'm not quite sure what this is asking, but AFAIK Subversion doesn't
create "microbranches" to resolve conflicts. Conflicts are resolved in the
working copy, but remember that copies of all three versions of a merged file
are available. How would "microbranches" be used and why are they necessary?
(5): Automatic ChangeLog updates are in the domain of a new post-commit
script. Sounds like an interesting idea, but supporting GCC's or any other
project's specific changelog format -- not to mention enforcing humans to use
a machine-parseable log message format -- is something that should be handled
elsewhere.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99U/bhDAgUT1yirARAgAXAJ9EKjbdjoWdzNw0fI7NuatLShHotwCdGSyt
GrB31Y7PJitVImAhlS9SWxI=
=DpAm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 03:23:34 2002