Brian Mattern wrote: >On Thursday 26 January 2006 00:57, Carsten Haitzler wrote: > > > >>>>"Use SVN!" - That's not a solution. It's a complication. It's EASY >>>>to mirror CVs usijng CVSup - but mirror CVS to an svn repository has >>>>more complexity and more things to go wrong. Whatever we do run - >>>>we'd like to have as few problems as possible. We NEED to mirror CVS >>>>at ANY rate. we then need to convert the mirrored CVs tree into >>>>something else. Let's get the mirroring working first to solve most >>>>people's problems. Adding SVN simply adds confusion and support >>>>issues - as develoeprs will use CVSA and users then won't. "CVS is >>>>fine - SVN problem" will be your answer most likely. :) >>>> >>>> >>>Exactly my point. If there's a call for an SVN mirror, that's great. >>>I have no problem with folks using it. But it doesn't solve the >>>fundamental problem: Mirroring the repository requires resources >>>whether the end result is CVS, SVN, or carrier pigeon. :) >>> >>> >>indeed - cvs mayneed more - but given sufficient resoruces dedicated we can >>put a good dent in it - ok thebox may get loaded up and slow down - but >>likely not to the point where sf.net cvs is now for most people :) svn can >>in the future possibluy be used to alleviate that - IF svn truly does use >>less cpu per "checkout" or "update" comapred to cvs. i really have no facts >>or experience with this so i am hesitant just to leap on the svn bandwagon >>without first getting cvs right. >> >> > >One thing is still unclear to me. If we do go with our own server, are we just >going to mirror cvs or are we actually going to move dev cvs over also? >(Given the low # of total devs, this would be a drop in the bucket in terms >of load/bandwidth). In the latter case, we could always move to SVN >completely, avoiding the "CVS works, SVN problem..." issue. > >I can't see any real benefit than SVN as an anon mirror provides (other than >the fact that can get new files in svn diffs without access to the repo). >However, as an SCM to develop with, I can see alot. > > Raster has the ultimate say in all things... but my take on the subject would being the following:
1) One time migration from CVS to SVN is pretty easy using existing scripts to do the migration. I once did it on my home system using E CVS, worked well. 2) SVN can be full distributed using SVK. 3) SVN allows for fine grained history from any point within the repo, not just on a project or file basis, ie: cd e17 && svn log; cd e17/ecore && svn log The advantage is that generating statistics and historical information is much much easier, without needing something like CIA. 4) SVN has some nifty features that you don't get with CVS. (annotations, renaming support,etc ) 5) SVN commits are truely atomic. But, I'll agree that creating a CVS-to-SVN mirror or bridge is lame. You completely convert or you don't. Honestly, I'm not a fan of CVSup, so maybe that has something to do with it. Like I said, its rasters call as far as I'm concerned, just sharing my opinion on the subject. benr. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
