Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
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: | ||
- | |||
- | |||
- | [[/ | ||
- | |||
- | |||
- | |||
- | [[/ | ||
- | |||
- | |||
- | |||
==== version control systems ==== | ==== version control systems ==== | ||
- | overviews | + | overviews, discussion & transitions |
* " | * " | ||
- | * a comparison of avialable | + | * a comparison of available |
* .. and a guide http:// | * .. and a guide http:// | ||
+ | * 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: | ||
+ | * from SVN to Hg > http:// | ||
- | distributed version copntrol systems -> [[DVCS]] | + | ==== CVS ==== |
- | === darcs === | + | standard, widely used ' |
- | + | ||
- | distributed, | + | |
- | + | ||
- | see: [[Using Darcs]] | + | |
- | + | ||
- | === CVS === | + | |
- | + | ||
- | standard, widely used, but some serious scalabity + flexibilty problems. has client software for unx-likes, win32 + macOS8/9/X http:// | + | |
Note that the Mac clients mentioned here are all screwy. Go To http:// | Note that the Mac clients mentioned here are all screwy. Go To http:// | ||
Line 35: | Line 21: | ||
see: [[Using CVS]] | see: [[Using CVS]] | ||
- | === subversion === | + | ==== darcs ==== |
+ | |||
+ | distributed, | ||
+ | |||
+ | see: [[Using Darcs]] | ||
+ | |||
+ | ==== subversion | ||
attempts to deal with some of the shortcomming of cvs. http:// | attempts to deal with some of the shortcomming of cvs. http:// | ||
Line 54: | Line 46: | ||
- | reading | + | reading |
- | * "the book" | + | * "the book" |
+ | 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, | "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, | ||
- | + | ==== mercurial / Hg ==== | |
- | === mercurial / Hg === | + | |
another [[DVCS]] | 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/ | look further into the possibility of integrating darcs into the [[OsX]] filesystem workflow using a combination of folder actions and or applescript/ | ||
- | http:// | + | http:// |
+ | |||
+ | |||
+ | A nice and interesting email from 24 Okt 2007 on the PD -dev mailing list: | ||
+ | |||
+ | < | ||
+ | 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. | ||
+ | over a year now with my own repositories. | ||
+ | projects over the last few years I've developed with CVS, SVN, | ||
+ | Mercurial, Darcs, Arch and Bazaar-ng. | ||
+ | decision. | ||
+ | |||
+ | 1) Distributed Development | ||
+ | |||
+ | The first, and I think most important, is the development model. | ||
+ | Distributed development supports a different kind of collaboration, | ||
+ | I think is showing itself to be quite advantageous for open source | ||
+ | software. | ||
+ | code working, and then it can be shared with the world. | ||
+ | management of a central repository is no longer an issue. | ||
+ | exist. | ||
+ | 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. | ||
+ | |||
+ | 2) Personal development advantages | ||
+ | |||
+ | In git you have the whole repository locally. | ||
+ | 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. | ||
+ | versioning, local branching, and tons of distributed back-ups of the | ||
+ | repository. | ||
+ | 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. | ||
+ | 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' | ||
+ | repositories etc. This is a level of power and control that you can not | ||
+ | get with svn. | ||
+ | |||
+ | 3) User Interface | ||
+ | |||
+ | Git was originally designed to function as a back-end suite that would | ||
+ | support easy to use front-end utilities. | ||
+ | and it now includes a nice set of commands and tools that make it work | ||
+ | just like you would expect. | ||
+ | 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. | ||
+ | you publish a repository just by copying a directory to an http | ||
+ | accessible location. | ||
+ | abstractions etc, without setting up a server, getting permission for a | ||
+ | centralized location or anything. | ||
+ | is speed. | ||
+ | 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' | ||
+ | git it's all so cheap I do it every time I get a new unit test to pass. | ||
+ | |||
+ | 4) Technical | ||
+ | |||
+ | Git writes the repository into a highly compressed format, and then it | ||
+ | does not mess with the files. | ||
+ | except for when you occasionally compress the whole thing, in which case | ||
+ | it can verify sanity. | ||
+ | permissions and access, just because of the whole usage model. | ||
+ | many experiences with subversion where the repository had to be | ||
+ | recovered because of permissions issues and/or corruption. | ||
+ | bad, especially since it is a centralized server that everyone is | ||
+ | counting on. It takes a root user to go in and run " | ||
+ | which in my opinion is a command that shouldn' | ||
+ | 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. | ||
+ | now, but worth the read: http:// | ||
+ | |||
+ | Sorry for the long post, but this is something I have dealt with a lot | ||
+ | recently. | ||
+ | run a modern open source project. | ||
+ | a seemingly cool and diverse group of developers, which seems perfect | ||
+ | for a decentralized model. | ||
+ | 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. | ||
+ | Hans-Christoph' | ||
+ | |||
+ | Mistrust authority - promote decentralization. | ||
+ | </ | ||