Peter Davis <peter@pdavis.cx> writes:
> 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?
We're not totally inflexible on any of them, and I'm not aware of any
platforms CVS supports that APR does not.
I'm not sure Subversion does all the checksumming I'd like, yet.
> (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?
An audit would be good in any case. This would be no worse than the
present situation with CVS, anyway. (I tend to go into maximally
paranoid mode when talking about security requirements.)
> (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.
I'm concerned about the graphs that someone posted a couple weeks
back, showing Subversion scale linearly but with a much larger
constant than CVS. GCC's repository is quite large - 884MB, 19723 ,v
files; when one of the major complaints about CVS is "it's too slow,"
switching to a slower system - even if that's something that can
easily be fixed in the future - is not in the cards.
> (2d): Subversion currently doesn't do "smart merging", but neither
> does CVS, and it will in the future.
I may try to implement this myself, sometime early next year, if no
one beats me to it. Shouldn't be hard.
> (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?
See <http://gcc.gnu.org/ml/gcc/2002-12/msg00487.html> for a lengthy
explanation.
> (5): Automatic ChangeLog updates are in the domain of a new
> post-commit script.
Personally I would prefer a post-checkout/update script, so that the
file doesn't even exist in the repository, but that's just me.
> 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.
Granted. Please read that as a request for the appropriate hooks, and
(since that change log format is common to GNU projects and has spread
beyond there) perhaps a place could be found for a user-contributed
script that does this, in a "sample hook scripts" bundle distributed
with Subversion.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 08:51:33 2002