I'll ask the web admin to start with integration of SVN. I don't promise anything. But the plan is to go slowly and implement SVN as an option to the CVS, so both would be available. This will require changes to the many parts of the web site, so it will take 2 months or so. ----- Original Message ----- From: "Jai Dhar" jai.dhar at gmail.com> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Friday, April 14, 2006 6:06 PM Subject: Re: [oc] kindly convert opencores cvs repository to subversion (svn) 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 _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

On 04/14/2006 09:13 AM, Damjan Lampret wrote:
Please rethink this, use git! While SVN is certainly nice in that it provides a web interface, so does git. However, SVN is terribly slow -- it's insanely CPU intensive. I don't think it's going to work well for a big project like this. If you are going to upgrade from cvs, upgrade to git. I see this as the trend. The Linux kernel developers have developed git over the last year: (http://kernel.org/git/). SVN was suggested, but it didn't win approval so git was written from scratch. If you are really going to follow a migration path to a newer SCM, this is a better path. X windows and Wine are examples of large free software projects that have gone in this direction. The important advantages: 1) git is cpu efficient 2) git is bandwidth efficient 3) git is smarter about offline development 3 is important/useful here. git makes a mirror (via rsync if you wish) of the repository on the server on to your local machine. This is smart! You have an exact mirror of the history, etc. Unlike CVS and SVN where what the server stores has no correlation to what you checkout. SVN is better than CVS, but it is still pale when put against git. If opencores is going to move forward, use git. Enjoy, Jeff

On 4/17/06, Jeff Carr basilarchia at gmail.com> wrote:


My Subversion repository at work is larger than 10GB (build artifacts and
source packages get archived in there) and the performance of svn commands
is more than acceptable. I can't say that I have ever monitored my CPU load
during svn command execution, it's fast enough that it's irrelevant to me.
Even large merge operations that happen when a new Linux kernel are imported
onto our vendor branch are pretty snappy. Of course I haven't performed
these operations with git, so I can't compare. But the bottom line is, it's
unlikely that anyone would notice, or care about any CPU utilization
differences.

2) git is bandwidth efficient


We have roughly 30 developers working out of this repository and our network
usage is very low. I haven't heard (or had) a single complaint about network
bandwidth usage. Subversion is smart about network usage, and takes steps to
allow a number of commonly used operations to happen locally.




3 is important/useful here. git makes a mirror (via rsync if you wish)



Subversion does not mirror the entire repository on your local machine, but
it does keep a separate, pristine copy of the source that you checked out
(in the .svn directory), so you actually have two copies of the source on
your machine. As a result, svn status/diff/revert are local operations that
do not require network connectivity.

SVN is better than CVS, but it is still pale when put against git. If

opencores is going to move forward, use git.


Subversion is light years beyond CVS for sure. I've read about git on
occasion, but haven't actually used it. I suppose it's time that I install
it and try it out.

Either git or Subversion would probably be just fine (as would arch or
monotone or something else). As long as an open source tool is chosen that
everyone can install and use, I don't think that there is a problem here.

Enjoy,
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20060417/09179460/attachment.htm