OPENCORES.ORG

Hello !

Well, thanks for keeping things in running condition!
it would be nice if do another favor: converting opencores cvs to
subversion <http://subversion.tigris.org/>.

[quote]
Most current CVS features.
Subversion is meant to be a better CVS, so it has most of CVS's
features. Generally, Subversion's interface to a particular feature is
similar to CVS's, except where there's a compelling reason to do
otherwise.

Directories, renames, and file meta-data are versioned.
Lack of these features is one of the most common complaints against
CVS. Subversion versions not only file contents and file existence,
but also directories, copies, and renames. It also allows arbitrary
metadata ("properties") to be versioned along with any file or
directory, and provides a mechanism for versioning the `execute'
permission flag on files.

Commits are truly atomic.
No part of a commit takes effect until the entire commit has
succeeded. Revision numbers are per-commit, not per-file; log messages
are attached to the revision, not stored redundantly as in CVS.

Apache network server option, with WebDAV/DeltaV protocol.
Subversion can use the HTTP-based WebDAV/DeltaV protocol for network
communications, and the Apache web server to provide repository-side
network service. This gives Subversion an advantage over CVS in
interoperability, and provides various key features for free:
authentication, path-based authorization, wire compression, and basic
repository browsing.

Standalone server option.
Subversion also offers a standalone server option using a custom
protocol (not everyone wants to run Apache 2.x). The standalone server
can run as an inetd service, or in daemon mode, and offers basic
authentication and authorization. It can also be tunnelled over ssh.

Branching and tagging are cheap (constant time) operations
There is no reason for these operations to be expensive, so they aren't.

Branches and tags are both implemented in terms of an underlying
"copy" operation. A copy takes up a small, constant amount of space.
Any copy is a tag; and if you start committing on a copy, then it's a
branch as well. (This does away with CVS's "branch-point tagging", by
removing the distinction that made branch-point tags necessary in the
first place.)

Natively client/server, layered library design
Subversion is designed to be client/server from the beginning; thus
avoiding some of the maintenance problems which have plagued CVS. The
code is structured as a set of modules with well-defined interfaces,
designed to be called by other applications.

Client/server protocol sends diffs in both directions
The network protocol uses bandwidth efficiently by transmitting diffs
in both directions whenever possible (CVS sends diffs from server to
client, but not client to server).

Costs are proportional to change size, not data size
In general, the time required for a Subversion operation is
proportional to the size of the changes resulting from that operation,
not to the absolute size of the project in which the changes are
taking place. This is a property of the Subversion repository model.

Choice of database or plain-file repository implementations
Repositories can be created with either an embedded database back-end
(BerkeleyDB) or with normal flat-file back-end, which uses a custom
format.

Versioning of symbolic links
Unix users can place symbolic links under version control. The links
are recreated in Unix working copies, but not in win32 working copies.

Efficient handling of binary files
Subversion is equally efficient on binary as on text files, because it
uses a binary diffing algorithm to transmit and store successive
revisions.

Parseable output
All output of the Subversion command-line client is carefully designed
to be both human readable and automatically parseable; scriptability
is a high priority.

Localized messages
Subversion uses gettext() to display translated error, informational,
and help messages, based on current locale settings.

[/qoute]

this <http://cvs2svn.tigris.org/> will help you converting the repository...

regards

On 4/13/06, Damjan Lampret <damjanl@o...> wrote:
> Hello !
>
> Recently OpenCores master server has been upgraded, which as a consequence
> has a much faster site. The master server runs very strong right now, the
> response is much better than before. I'll see how it copes with the traffic
> in the following days and weeks.
>
> Before also occasional restarts of the server were required, interrupting
> the use of the server. Happy to report, these will be no longer required!
>
> regards
> Damjan
>
> PS There might be an additional upgrade in the following weeks, unlike the
> current upgrade which wasn't announced in advance, this additional upgrade
> will be announced (if the upgrade will be needed at all).
>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores
>