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 [2009-03-31 09:56] (current) – nik
@@ 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]]
 ==== version control systems ====
-overviews
+overviews, discussion & transitions
   * "Cutting Edge Revision Control" circa 2007 > http://bryan-murdock.blogspot.com/2007/03/cutting-edge-revision-control.html
-  * a comparison of avialable free SCM (sorce code management) systems http://better-scm.berlios.de/
+  * a comparison of available free SCM (source 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 control systems -> [[DVCS]]
+  * using version control, a guide for the lirec project [[lirec:version control guide]]
+  * from SVN to Hg > http://www.python.org/dev/peps/pep-0374/
-distributed version copntrol systems -> [[DVCS]]
+==== CVS ====
-=== darcs ===
+standard, widely used 'legacy system' with some serious scalabity + flexibilty problems. has client software for unix-likes, win32 + macOS8/9/X http://www.cvshome.org
-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 ===
-standard, widely used, but some serious scalabity + flexibilty problems. has client software for unx-likes, win32 + macOS8/9/X http://www.cvshome.org
 Note that the Mac clients mentioned here are all screwy. Go To http://sourceforge.net/projects/maccvspro to get an up to date and (hopefully) usable version. Instructions for setting up are in the TechSpec (section 12, page 34 of the current version dec 2002). Note especially the requirement for CarbonLib. (And MacOS 8.6 or higher). The URL in the TechSpec is almost correct - the current version is 1.6, so use http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/English-North_American/Macintosh/System/Other_System/CarbonLib_1.6.smi.bin
@@ Line 35: / Line 21: @@
 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 46: @@
-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 70: @@
-=== 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. see: [[git notes]]
@@ Line 92: / Line 86: @@
 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 at 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>