RE: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] 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. I know you had a few bumps on your way, I'm glad to hear things are progressing. 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. CVS is really great if you have access to the repository and don't make mistakes. However CVS came together out of necessity as some project level meaning was to be given to a set of RCS files. Basically it's a kludge although not a bad one. Subversion is a complete rewrite and has some subtle yet major differences. However I do feel safer knowing that there is less 'hackery' now while preserving the ability to extend subversion. In the past, I made a living off of other people's ignorance when it came to administering CVS and hacking around its flaws. Don't get me wrong I'm glad to have profited but would rather have worked on creating something new rather than working around a flawed piece of software. Rather than spend time knowing the internals of a VCS to make up for its shortcomings, I'd rather put that time towards using it to its fullest extent and improve the development lifecycle. snip/ 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 Yes svn could be difficult because it requires breaking old CVS habits. The fact that a revision# = tag# in subversion may confuse the need for branches in the traditional CVS sense. Branching just becomes a very efficient copy operation. IMHO this is an improvement. 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? Subversion like all good systems leaves the interpretation (meaning) of the state of a branch up to you but gives you the tools you need to manage it. The tools here are user definable attributes. So when you want to devise a scheme for tracking the state of your branch you have first class support from subversion to do so. CVS never gave you this although you could mimic it with workarounds. 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. You're right that it will take time before the entire community begins to see the true value of svn. 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. Yeah I was a little disappointed by not having these features you mention also. I think they are due to only a partial implementation of DeltaV but others would know about this better thank I. Regardless it would be sweet to have the write half also because then everything is a standard wrt the comm. protocol
Re: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)
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]
RE: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)
CVS hackery was effectively an easy way to extend CVS. You may be a CVS guru, but do you really want to know how many times someone has crapped CVS by playing around with things they don't understand? Not directly related, perhaps, but we had to fix a problem just this past week where someone started using the live CVS repository on minotaur for their personal workspace. 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. Subversion has several well-defined interfaces, including WebDAV/DeltaV. Branching and tagging in svn confuse me. Branches and tags are just lightweight copies. A branch and a tag are the same thing. Placing them under branches/ and tags/ are just conventions. To quote the Subversion book: Subversion has no internal concept of a branch-only copies. When you copy a directory, the resulting directory is only a branch because you attach that meaning to it. You may think of the directory differently, or treat it differently, but to Subversion it's just an ordinary directory that happens to have been created by copying. To tag something, you make a copy of it. If you started editing the copy it is a branch, otherwise it is a tag. The important thing is that you used Subversion to copy, so that it tracks the file identity. The book, http://svnbook.red-bean.com/, should answer many of your questions. R/W setting of branches? We use mod_authz_svn for that purpose. 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 I can't mount a subversion repo as a virtual drive and commit by simply copying a new version of a file in There is support for auto-versioning, but we may have it disabled. One of the issues with auto-versioning is that you don't get commit comments. I believe that DeltaV is the way out of it, but you would have to talk with the Subversion folks. In any event, it is a current limitation, not a design point. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)
Hi, Sorry to get into this one late. Had too though since I'm one of those directory folks :-). From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Good but out of date. The subclipse web page appears to be lagging behind its code: http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240 I'm an eclipse user myself and really loved the integrated CVS features. However I had to give up on an eclipse plugin for subversion but am anxious to start using this new version. I gave up on using an IDE all together for my VCS activities because of a switch to subversion. I use the command line svn program with cygwin and that was hard since the CVS plugin is so nice. Unfortunately I still have to develop on Windows XP most of the time because of corporate requirements. It's definitely a trade off to use the CL svn program instead of the eclipse plugin for CVS but I think I made the right choice. Anyway it looks like I can resume using eclipse for VCS ops against subversion now! How often are we going to be using the unique administration features in Subversion as compared to the day-to-day usage features available in the CVS plugin. One example would be every time you refactor, but as a general observation, I'll guess that the Directory project is using the unique features of Subversion every few days at least. Subversion for eXtreme Refactoring == And we could not do without these features. It's more than simple administration features though. Let me see if I can explain the subtle changes to our development style these features have had. Subversion affords us a more liberty. Besides the obvious renaming and deleting of files and directories without the loss of history etcetera, 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 improved our development style and the quality of our code. Subversion goes hand in hand with XP! It's the preferred VCS for extreme programmers! 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. 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. 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. Regards, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
