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 at opencores.org> wrote:

Hi ! I'll look at the SVN, and see how difficult would be to replace CVS. Problem is, many developers are used to CVS, and also CVS is very closely integrated into OpenCores web site. regards Damjan ----- Original Message ----- From: "Umair Siddiqui" umairsiddiqui84 at gmail.com> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Thursday, April 13, 2006 11:32 PM Subject: [oc] kindly convert opencores cvs repository to subversion (svn) 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 at opencores.org> wrote: _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Damjan Lampret wrote:
That would be really great about switching to SVN. Nice thing about it is, that for a CVS user it is easy to switch to it: cvs checkout ---> svn checkout cvs commit ---> svn commit For most commands, just replace cvs by svn. Concerning the web interface, SVN can actually be setup as a WebDAV extension to Apache, but personally I think that is more administration work than just to run it as a standalone server. I saw on the opencores.org page you use CVSweb, which unfortunately does not seem to support svn. There are other tools, like ViewCV, formerly ViewCVS, that supports both, CVS and SVN. More information about it can be found here: http://www.viewvc.org/ Cheers, Guenter

Damjan Lampret damjanl at opencores.org> wrote:

Why don't you just provide svn in addition to cvs? And then Individual devs
will be free to choose whichever suits them best...

nog.

The process of integrating CVS into the web site (I'm not talking to run the CVS repository on the site, but rather to have it integrated into the web) was very long, it will probably be the same for SVN. I'll talk to the web developer what kind of implications might SVN have to be implemented into the web site. I'm just afraid that many will be further confused by having the option to choose between SVN and CVS. On the other side replacing CVS with SVN also has disadvantages, personally I think would be better to have both than to do a replacement. Anyway for now, my task is to first discuss the SVN with the web developer. regards Damjan ----- Original Message ----- From: "Gyorgy 'nog' Jeney" nog at sdf.lonestar.org> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Friday, April 14, 2006 4:44 PM Subject: Re: [oc] kindly convert opencores cvs repository to subversion (svn)

I don't think anyone has ever regretted the move to SVN; I did it with my repository, and haven't regretted it a single moment. I would say the biggest advantage is doing away with tagging/branching, and replacing that concept with moving/copying of directories. Also, regarding web admin., SVN (unlike CVS), is designed for the web in the first place, so it integrates well with Apache. My repository is located here - http://via.dynalias.org/svn This is both the URL that you can get via the web, or an SVN client - very simple. As you can see, the interface is very dry and simple, but it supports XML, so you can design whatever interface you want and display whatever info. The move from CVS to SVN will take some time on the repository side; there are scripts that help you do the move, but with something as large as opencores, I'm not sure how well it would work out. Either way, I sincerely hope the switch is made at some point. On 4/14/06, Damjan Lampret damjanl at opencores.org> wrote: -- Open-source hardware at http://www.fps-tech.net

Jai Dhar jai.dhar at gmail.com> wrote:

I'm all for SVN but what you're asking for, with this mass conversion, is to
pull the rug out from right under everyones feet, which is _very_ impolite,
causes unecessary confusion, anoyment and anger (think: `What did you do with my
repo?!?!). Remember: "element of least surprise" should (mostly) be the number
one criteria.

nog.

I agree, doing everything at once is bad - and I didn't ever advocate that, I was merely speaking on the advantages of SVN. I also think having two repositories is bad. Why not setup a test repository for people to get used to? They can even move their own projects if they like. I don't think getting everyone to move their own projects will work (too messy), but in the meantime, while people are getting used to SVN, duplicate the CVS repo. into SVN. Then, when people are ready, just point to the new location. I'm not an expert on how to handle IT admin. stuff like this, so that's just one suggestion. But I do feel that you shouldn't hinder the introduction of a new and very beneficial technology when the only deterrant is inconvenience. If there were other detractors, like speed, complexity, cost etc.., then I would say convenience would play a part. But that's not the case with SVN. I guess it also comes down to two camps of thinking; those who feel that "if it ain't broke, don't fix it", and the opposite.. always pushing to the bleeding edge. Personally, I would like to think that somewhere in the middle is where I am - I waited a while for SVN to mature, and I tried it out even though CVS wasn't "broke". It only increased my productivity, which is always a good thing IMO. End of philosophical rant :) On 4/14/06, Gyorgy 'nog' Jeney nog at sdf.lonestar.org> wrote: -- Open-source hardware at http://www.fps-tech.net

Jai Dhar jai.dhar at gmail.com> wrote:

You're not advocating doing it wholesale..



...But, actually you are! Realy, I don't see why you're trying to shove this
down everyone's throaght so badly. If devs want to move their projects, they
will and if they also leave the CVS repo behind, they'll get all the support
queries which is _their_ problem, not mine, not yours.



I'm not against it's introduction, I'm against doing it wholesale.



There _are_ two camps of thinking, just not the ones you mentioned. On one side
you have those that want to control everything and on the other you find those
who "couldn't care less". The later has a future, the former doesn't. Just let
both be and devs will use/convert to whichever suits them best at a time when it
suits them.



Same here :) Have a nice weekend.

nog.

I've been using subversion for a few months now; here's my 2c.

1 - what it's really good for is moving and renaming directories and
files. This is a real pain in CVS. But, of course, this is only of any
use to the person who creates the repository in the first place; it's of
no use to people who just want to do occasional commits or updates.

2 - getting a browser view into the repository is occasionally helpful.
You can look at old tagged distributions, for example.

3 - versioning of metadata, properties, etc. - this is just pointless
busywork. If you just want to do keyword expansion and setting filenames
to be ignored, then CVS is *much* easier. I can't even think of anything
else I'd like to do with metadata.

4 - svn doesn't do tagging; you implement it as a directory copy. This
is bad, bad, bad. Anybody can come along afterwards and mess up my tag;
you have to agree with other devlopers not to touch it.

5 - retrieving old revisions and comparing them - bad, bad. There's not
even a whitespace-ignore option on 'svn diff'. Actually, I suppose the
real problem here is emacs. With xemacs/CVS, I can easily extract any
two versions and do a graphical/ediff compare. There are 2 svn modes for
emacs, and they're primitive, unless I've missed something. 'svn status'
will let me ediff the head against the current file, but I haven't
been able to do anything else with it. This is the real killer; if I
can't fix this, I'm back to CVS.

6 - svn ups the revision number on the entire repository for each
commit, so individual files may have version numbers which differ by
hundreds. You have to go back and cross-reference the history to do any
comparisons. On reflection, I think this is probably not good; I'd
prefer consecutive numbers on all files.

7 - versioning of symbolic links - sounds good, haven't tried it.

8 - stability/bugginess - not too bad. I've had a couple of problems,
but nothing major.

All the other features are basically just "so whats". It may have a
fancy client/server architecture, and there may be fancy underlying
databases, and commits may be truly atomic, and so on, but this doesn't
do much for me as a user. I've never had a problem with a commit on CVS
messing up, but I've occasionally had commits fail on svn.

And, of course, svn and CVS both have the same flaw of allowing multiple
developers to work on the same file at the same time, relying on merging
to fix things afterwards. I guess this may be Ok for free software work,
but it's no good for professional use.

RT

There's no need to be rude; I'm not shoving anything down anyones "throaght" as you so eloquantly put it. It's a discussion, one that I didn't start - I offered my view on it and didn't knock anyones view who is against CVS, did I? If you couldn't care less, then don't voice your opinion. On 4/14/06, Gyorgy 'nog' Jeney nog at sdf.lonestar.org> wrote: -- Open-source hardware at http://www.fps-tech.net

Hi,

I just wanted to add something to the CVS/SVN discussion. With CVS or
SVN we are talking about different tools and how they might simplify
usage of the service provided by opencores. I would like to extend that
discussion to the whole of opencores.

Recently a long contributor to opencores, Rudolf Usselmann, announced
that he would withdraw from the mailing list, after being attacked by
somebody about a core he has provided to opencores.

Sadly enough, there was not much objection to his announcement.

-- Just to remember that after all the cores he and his colleagues
provided to opencores, he also donated money for the new server. --

I don't want to draw on this, but the core of his frustration was that
some times the amount of "me-too" emails seemed to exceed the number of
contributional emails. Also, people who contribute face criticism from
people who do not contribute and the contributors have no way of
controlling their contribution.

I have been pondering about this for a while and wanted to throw some
ideas here in the discussion.

The first basic idea I had is to add some type of credit system to
registered users that contributed to a project. Every user who takes
part in a core development project gets some credit for that. There
could be some measures so that the given credit is based on size of the
contribution.

A project maintainer can select what group of people he wants to make
the core public to. Now this would soften the "open" in opencores, I
know, but I think it would be an additional encouragement for people to
contribute to opencores and hence an overall gain for the community.

What are your all thoughts on this?

Cheers,

Guenter

On 4/14/06, Günter Dannoritzer dannoritzer at web.de> wrote: How about just moderating the list? I'm against putting any restrictions on the people who have access to the code, but I could sure do with fewer "could you please write my school project for me" emails. As far as I can tell, it isn't access to the code that's causing the problem, it's the communication that follows. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20060415/2c6b368a/attachment.htm

* Guy Hutchison (ghutchis at gmail.com) wrote:

The list are moderated, but the problem in the end is that only Damjan and i
did the actual moderating for all the lists. After a while this becomes very
borring and time consuming for 1 or 2 people. If anyone wants to help
moderating the list (even if he is not too technical) it would be really
great and help alot. (so other can dedicate more time on technical
things)...

regards,
p.

Matjaz Breskvar wrote:


Can you explain how that works with the moderation? Is there a web
interface where one pre-reads the emails and then OKs them?

Cheers,

Guenter