On Wed, Jul 13, 2011 at 5:36 AM, David Kelly <[email protected]> wrote: > >>> Wrong. Subversion's file:// access method goes straight to it. The worst of >>> this is the tendency of Windows people to put the repository on a shared >>> file server with multiple users using the file:// method on the same >>> repository at the same time. >> >> Not wrong at all. CVS and RCS have the same thing, you can make your >> "server" be some directory somewhere else on your local disk. Which I >> pointed out actually. > > You said to the effect one must "set up a server no matter its only you and > your laptop." Suspect you are confused with the popularity of using WEBDAV > with svn. This is all it takes (without WEBDAV): >
David, I'm not confused at all. All I stated is is SVN requires a server. That "server" may indeed simply be a different directory on your own machine, as your own sample command-line shows. I've used SVN extensively for my own projects, I've maintained and administered SVN repos for development organizations, I'm more than a little familiar with it's concepts and use. It is indeed "CVS done right" as described by the creators (though listening to Linus's comments on that particular concept in the Google talk where he introduces Git is quite funny, no matter if you agree with him or not). There is zero confusion in my mind about the benefits and drawbacks, configuration and use. > > Client-server is a *strength* not a weakness, it allows a surrogate process > to manage access rights between multiple users. But contrary to your claims > requires no additional effort for single-user use. A single user would never > know subversion spawned other processes without looking hard. > I don't see client-server as an absolute strength nor a weakness. The right tool depends on what you're trying to accomplish and, if given a choice, your working style. I think having a multitude of choices is great. I also think that it's very important to explore and learn all the tools (or at least types of tools) available so you can make an intelligent choice of what to use. I read recently on a blog where a Gnome developer was bemoaning the choice of Gnome's community to move from SVN (I think it was SVN) to Git. Something was said like: "I’ll have to waste more time learning something new to do essentially the same thing with no new benefit." This statement says "I don't want to learn new tools or learn new and potentially valuable skill-sets". That's a behavior that I wouldn't want in any co-worker. Learning behaviors are something I specifically screen for when I interview, and this guy likely wouldn't make it even as far as a phone-screen. I like to try new tools. Sometimes those get dropped, and when a new tool makes me more effective in what I do, I adopt it. One thing that's important to _me_ as I often work very remotely from my servers is being able to continue to use my SCM while on slow or disconnected network interfaces. Git fits that bill. I work in a company where a huge code-base is still on CVS. Even from my home office with a high-speed cable connection, it took my computer well over 30 minutes to do a branch-tag on the repo, when all I wanted to do was check some disruptive changes into a branch for review. All in all, it took well over 3 hours to make a branch, check it out, merge my changes, and commit them. Doing the same effort on Git would've taken less than about 10 minutes. And I still have the pain of merging my branch into the CVS tip after review to look forward to. I apologize for comments I've made that are unclear. I'm not bashing SVN. The OP is best served by having fair and reasoned information from experienced sources. David, if you've got further issues with what I've said, I invite you to take this off-list and email me directly. There is no benefit to the OP seeing us argue over various esoteric points, especially since I clearly can't convince you of anything as I'm not trying to do so. My overall goal was to present an option that the OP can choose to investigate and possibly be of use to him. Sincerely, - Steve -- You received this message because you are subscribed to the "BBEdit Talk" discussion group on Google Groups. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at <http://groups.google.com/group/bbedit?hl=en> If you have a feature request or would like to report a problem, please email "[email protected]" rather than posting to the group. Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
