On Sat, 27 Mar 2004, Alex Karasulu wrote:
> Hi, > > Sorry to get into this one late. Had too though since I'm one of those > directory folks :-). I'm finally finding that I can get svn installed on suse and os x [it's not without issue] and am looking forward to migrating to svn over the next year in all my endeavours. Some questions on the below though: > Subversion for eXtreme Refactoring > ================================== > > Subversion affords us a more liberty. Besides the obvious renaming and > deleting of files and directories without the loss of history etcetera, Never really had that much pain doing this on the CVS server. One of the pluses CVS had was that the system was easily understandable and if CVS did not support a feature, you could often use something like perl to gain said feature. CVS hackery was effectively an easy way to extend CVS. Lookinjg at the SVN repo, it looks a lot more complicated and will require far more in the way of effort to change, ie) writing [I assume] berkely db client code. > we find that our development style can be geared towards XP. These > features are changing our outlook. We are no longer worried about > chewing up a repository to re-factor on a whim. I personally have > re-factored conservatively on CVS because there was no way to easy > way to cleanup the consequences afterwards: loss of history and empty > directories. But now there are no inhibitions with subversion so we're > free to be liberal with re-factoring - it's the way we code. Bang > something rough out and then gradually reshape it as we discover new > things along the way. Plus the ease of branching by just copying > directories and merging them makes large re-factoring efforts without > disrupting development a breeze. These features have for these reasons Branching and tagging in svn confuse me. People talk about them being easier, but the difficulty of such things in CVS is not the action, but the management of multiple branches of code. All i see in SVN so far is a different way [which may be faster on the server, but who cares unless there are lots of binary files] and not an improved way. Is there any concept of live vs dead branches? Any way to implement naming conventions? R/W setting of branches? Also, branches seem to have less in the way of support as you now have to come up with your own filing hierarchy to contain them. While the new SVN structure seems simpler, which might lead to a more easily implemented powerful system, there's nothing to crow about yet. > Going back to CVS is not an option for me after tasting development > using subversion: it would mean going backwards. The best description > I can give of the having to use CVS after using subversion is when I > have to use dial up rather than high speed internet access. It's just > frustrating. Your anology reminds me of something that frustrated me. Subversion apparantly has a different commit method, it sends patches up and not full files [?]. This makes for less bandwidth usage. Anyways, the bit that frustrates me is the SVN seems unable to work with basic WebDAV clients, which I think quite a few of us assumed when it talked about using WebDAV [yeah, I don't grokk DAV]. Anyway, this means that I can't mount a subversion repo as a virtual drive and commit by simply copying a new version of a file in, or editing it, and I can't use a tool like Dreamweaver to change it. It does work in a read-only way though, just errors on commits. > Subversion is the future that fits the latest paradigms in software > development. I cannot stress the importance of the positive effects > it will have for development here at the ASF not to mention for > infrastructure. And ultimately the transition will have to happen > at some point. >From what I understand, SVN is written by the maintainers of CVS? Which implies that CVS is dead and SVN is basically a very non-backwards compatible CVS-2. That's the main reason to move for me. So far, the only improvements I've found are the ability to move files, a slightly nicer set of messages when committing and 'svn status' replacing 'cvs -nq update'. A lot of it feels more generic, which can be a good thing. > BTW in the past I have been a CVS consult and lived and swore by it > since it put food on the table. I cannot overstate how emphatic > I have been regarding CVS. It was a religion for me. Now after years > of using CVS, I swear by subversion and that's got to be worth > something when said by a CVS diehard. I suspect complaints like "but it's too complicated", "it's not well supported" etc were heard by RCS die-hards when CVS came out too :) I expect to not be using CVS in a year [home,apache,osjava,work], but it's going to take a good chunk of time to transform my cvs-admin knowledge over to svn. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
