Differences

This shows you the differences between two versions of the page.

--- version_control [2007-07-12 09:32] – external edit 127.0.0.1
+++ version_control [2007-10-24 16:50] – 192.168.1.36
@@ Line 1: / Line 1: @@
-[[/cgi-bin/oops/Libarynth/VersionControl?template=oopschangelanguage]]{{/pub/TWiki/TWikiDocGraphics/flag-gray-small.gif|Change language}}
-[[/cgi-bin/view/Libarynth/WebHome]][[/cgi-bin/view/Libarynth/WebHome]]{{/pub/TWiki/TWikiDocGraphics/web-bg-small.gif|}}[[/cgi-bin/view/Libarynth/NikGaffney]][[http://lib.fo.am/cgi-bin/edit/Libarynth/VersionControl?t=1179083437|Edit this topic text]][[/cgi-bin/attach/Libarynth/VersionControl|Attach an image or document to this topic]][[/cgi-bin/view/Libarynth/VersionControl?cover=print.pattern|Printable version of this topic]]
@@ Line 16: / Line 8: @@
   * a comparison of avialable free SCM (sorce code management) systems http://better-scm.berlios.de/
   * .. and a guide http://zooko.com/revision_control_quick_ref.html
+  * an email from jeff rose talking about several systems, from oktober 07, is at the bottom of this page.
 distributed version copntrol systems -> [[DVCS]]
-=== darcs ===
-distributed, patchset based system, easy to setup + configure, not too many weird filenames (was arch deliberately written to stresstest filesystem syntax?) not dependent on massive centralisaed server setup (apache/dav/neon/db/etc+). win32/unix compliable (if theres a haskell compiler around). cvs conversion scripts. how well does it handle binaries?
-see: [[Using Darcs]]
+==== CVS ====
-=== CVS ===
 standard, widely used, but some serious scalabity + flexibilty problems. has client software for unx-likes, win32 + macOS8/9/X http://www.cvshome.org
@@ Line 35: / Line 25: @@
 see: [[Using CVS]]
-=== subversion ===
+==== darcs ====
+distributed, patchset based system, easy to setup + configure, not too many weird filenames (was arch deliberately written to stresstest filesystem syntax?) not dependent on massive centralisaed server setup (apache/dav/neon/db/etc+). win32/unix compliable (if theres a haskell compiler around). cvs conversion scripts. how well does it handle binaries?
+see: [[Using Darcs]]
+==== subversion ====
 attempts to deal with some of the shortcomming of cvs. http://subversion.tigris.org/
@@ Line 54: / Line 50: @@
-reading  )
+reading
-  * "the book"  http://svnbook.red-bean.com/)
+  * "the book"  http://svnbook.red-bean.com/
+drawbacks
+  * stapling extra legs on a dog to make an octopus
-=== arch ===
+==== arch ====
@@ Line 75: / Line 74: @@
-=== aegis ===
+==== aegis ====
 "Aegis is a transaction-based software configuration management system. It provides a framework within which a team of developers may work on many changes to a program independently, and Aegis coordinates integrating these changes back into the master source of the program, with as little disruption as possible." http://aegis.sourceforge.net/
+==== mercurial / Hg ====
-=== mercurial / Hg ===
 another [[DVCS]]
-=== git ===
+==== git ====
-another [[DVCS]]
+another [[DVCS]] developed and used for the linux kernel project.
@@ Line 92: / Line 90: @@
 look further into the possibility of integrating darcs into the [[OsX]] filesystem workflow using a combination of folder actions and or applescript/platypus/cocoadialog.. .
-http://keithp.com/blog/Repository_Formats_Matter.html
+http://keithp.com/blog/Repository_Formats_Matter/
+A nice and interesting email from 24 Okt 2007 on the PD -dev mailing list:
+<code>
+From: 	  rosejn@gmail.com
+Subject: 	Re: [PD-dev] SVN?
+Date: 	24 October 2007 2:39:19 PM
+To: 	  pd-dev@iem.at
+There are a couple key factors in this decision that seem to be getting
+confused with each other.  I'm new to PD, but I've been using Git for
+over a year now with my own repositories.  In various consulting
+projects over the last few years I've developed with CVS, SVN,
+Mercurial, Darcs, Arch and Bazaar-ng.  There are a couple facets to the
+decision.
+) Distributed Development
+The first, and I think most important, is the development model.
+Distributed development supports a different kind of collaboration, that
+I think is showing itself to be quite advantageous for open source
+software.  It lets groups of people organize themselves, get a piece of
+code working, and then it can be shared with the world.  Permissions and
+management of a central repository is no longer an issue.  It doesn't
+exist.  Instead Hans-Christoph, for example, would manage an official
+pd-extended branch that had the fully tested features, while everyone
+else could still share the latest and greatest stuff without having a
+centralized bottle-neck.
+) Personal development advantages
+In git you have the whole repository locally.  This takes more storage
+space, which is incredibly cheap, but saves LOTS of time.  SVN can never
+merge as well as GIT because you don't have past versions of the
+repository to merge against.  Additionally, with git you get local
+versioning, local branching, and tons of distributed back-ups of the
+repository.  I'm always working on the train, for example, and with Git
+I can maintain a much better log of my development because I commit all
+the time without needing internet access. Branches in git, even for huge
+projects, are basically free.  In space and time.  This changes the way
+you develop.  You can make a branch for any little idea you want to mess
+with or any tricky feature you are working on.  It's quite easy to then
+merge these branches, share them with friends, update them from other's
+repositories etc.  This is a level of power and control that you can not
+get with svn.
+) User Interface
+Git was originally designed to function as a back-end suite that would
+support easy to use front-end utilities.  That has changed over time,
+and it now includes a nice set of commands and tools that make it work
+just like you would expect.  For sure Git doesn't have the GUI plugins
+like SVN or CVS and it will take some learning, but I think the benefits
+in the long term will far, far outweight the initial investment.
+There is a Tk interface, GitK, which is incredibly useful to visually
+look at the history of a repository, merges, branches etc.  There is
+also git-web, which lets you view the repository online.  Git also lets
+you publish a repository just by copying a directory to an http
+accessible location.  This means anyone can share their ideas, features,
+abstractions etc, without setting up a server, getting permission for a
+centralized location or anything.  Also relevant to the user experience
+is speed.  Git blows away all the other systems in terms of speed.  It
+does everything faster, and you really notice this because it changes
+what you do.  In some of the other systems, like Bazaar-ng, committing,
+pulling and pushing took so long I wouldn't do it that often, but with
+git it's all so cheap I do it every time I get a new unit test to pass.
+) Technical
+Git writes the repository into a highly compressed format, and then it
+does not mess with the files.  Append only is the standard operation,
+except for when you occasionally compress the whole thing, in which case
+it can verify sanity.  It is also much cleaner to work with in terms of
+permissions and access, just because of the whole usage model.  I've had
+many experiences with subversion where the repository had to be
+recovered because of permissions issues and/or corruption.  This is very
+bad, especially since it is a centralized server that everyone is
+counting on.  It takes a root user to go in and run "svnadmin recover",
+which in my opinion is a command that shouldn't need to exist in
+something as important as a source repository.
+Keith Packard who runs the X.org project wrote a very good post
+detailing his research and opinions into source control.  It's a bit old
+now, but worth the read: http://keithp.com/blog/Repository_Formats_Matter/index.html
+Sorry for the long post, but this is something I have dealt with a lot
+recently.  In my mind distributed versioning is the only proper way to
+run a modern open source project.  PD is a great piece of software with
+a seemingly cool and diverse group of developers, which seems perfect
+for a decentralized model.  Either way, I think the decision should be
+made first between a centralized or distributed versioning system, and
+then the decision can be simplified to figuring out compatibility,
+usability etc.  It's great news that Git now runs on windows though,
+because I think it is far better than the others.  To quote one of
+Hans-Christoph's recent signature lines:
+Mistrust authority - promote decentralization.  - the hacker ethic
+</code>