Comments on: My Experience with Subversion http://www.basilv.com/psd/blog/2006/my-experience-with-subversion Wed, 08 Feb 2012 03:57:22 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Jeffrey http://www.basilv.com/psd/blog/2006/my-experience-with-subversion/comment-page-1#comment-105847 Jeffrey Fri, 26 Mar 2010 17:10:53 +0000 http://www.basilv.com/psd/blog/2006/my-experience-with-subversion#comment-105847 "One reason I like Subversion for personal use is that you can use it without running the server. " This is true for cvs as well. The cvs implementation inside eclipse seems to support only client-server mode, but that is eclipse's issue, not cvs'. The true cvs command-line version supports accessing repositories on the local filesystem without the server. “One reason I like Subversion for personal use is that you can use it without running the server. ”

This is true for cvs as well. The cvs implementation inside eclipse seems to support only client-server mode, but that is eclipse’s issue, not cvs’. The true cvs command-line version supports accessing repositories on the local filesystem without the server.

]]> By: Basil Vandegriend http://www.basilv.com/psd/blog/2006/my-experience-with-subversion/comment-page-1#comment-58645 Basil Vandegriend Thu, 07 Aug 2008 01:27:47 +0000 http://www.basilv.com/psd/blog/2006/my-experience-with-subversion#comment-58645 Good points, Rob. I agree that issues like needing to use export and IDE integration are not problems with Subversion itself. I do feel, however, that these are issues regarding the use of Subversion that developers need to be aware of. Good points, Rob. I agree that issues like needing to use export and IDE integration are not problems with Subversion itself. I do feel, however, that these are issues regarding the use of Subversion that developers need to be aware of.

]]> By: Rob Williams http://www.basilv.com/psd/blog/2006/my-experience-with-subversion/comment-page-1#comment-58610 Rob Williams Wed, 06 Aug 2008 19:01:55 +0000 http://www.basilv.com/psd/blog/2006/my-experience-with-subversion#comment-58610 Subversion recommends creating a "trunk" directory, rather than "head" (very different semantics), and a lot of other tools depend on this. Subversion is essentially CVS 2.0, so it is fundamentally the same in that it uses a private subdirectory (.svn versus CVS) for its bookkeeping. Some of the newer source control tools (distributed version control systems = DVCS) have designed away from this issue. I am moving away from Subversion (my previous favorite) to Bazaar because of the many design advantages. The need to export, and the need to carefully orchestrate multiple tools (source control client and IDE) are not problems that require "workarounds". Export is a built-in feature for handling the use case of producing a copy of the content without the bookkeeping, for both CVS and Subversion. Integrating source control into an IDE is not the responsibility of the source control tool--that squarely lies on the shoulders of each IDE. The former (export) is an inherent characteristic of the design. The latter (renaming/moving source files) is an inherent characteristic of using IDEs with source control. If one subscribes to the IDE paradigm, then one is motivated to find a pre-integrated source control client for their favorite IDE(s). If one does not subscribe to the IDE paradigm (choosing simpler, non-integrated tools), then one can avoid the "problems", and the extra work, altogether. Subversion recommends creating a “trunk” directory, rather than “head” (very different semantics), and a lot of other tools depend on this.

Subversion is essentially CVS 2.0, so it is fundamentally the same in that it uses a private subdirectory (.svn versus CVS) for its bookkeeping. Some of the newer source control tools (distributed version control systems = DVCS) have designed away from this issue. I am moving away from Subversion (my previous favorite) to Bazaar because of the many design advantages.

The need to export, and the need to carefully orchestrate multiple tools (source control client and IDE) are not problems that require “workarounds”. Export is a built-in feature for handling the use case of producing a copy of the content without the bookkeeping, for both CVS and Subversion. Integrating source control into an IDE is not the responsibility of the source control tool–that squarely lies on the shoulders of each IDE.

The former (export) is an inherent characteristic of the design. The latter (renaming/moving source files) is an inherent characteristic of using IDEs with source control.

If one subscribes to the IDE paradigm, then one is motivated to find a pre-integrated source control client for their favorite IDE(s). If one does not subscribe to the IDE paradigm (choosing simpler, non-integrated tools), then one can avoid the “problems”, and the extra work, altogether.

]]>