More about Subversion [was "Re: SourceSafe??? Recommendations needed"]
I've had no trouble with it, but admit that I've not needed to do FLA/SWF storage/recovery yet. Grant ___ Grant Hogarth Equis International - A Reuters Company ghogarth at Equis.com / Grant.Hogarth at Reuters.com Direct: (+1) 801.270.3180 Main Fax: 801.265.3999 URL: www.equis.com TZ: Mountain (GMT -7) -Original Message- From: owner-framers at omsys.com [mailto:owner-fram...@omsys.com] On Behalf Of Loren R. Elks Sent: Monday, April 24, 2006 10:18 AM To: framers at frameusers.com; framers at omsys.com Subject: RE: More about Subversion [was "Re: SourceSafe??? Recommendations needed"] So Subversion can handle any file type (FLA, SWF, FM, Graphics, etc.)? Sincerely, Loren -Original Message- From: owner-framers at omsys.com [mailto:owner-fram...@omsys.com] On Behalf Of hedley.finger at myob.com Sent: Sunday, April 23, 2006 7:45 PM To: framers at frameusers.com; framers at omsys.com Subject: More about Subversion [was "Re: SourceSafe??? Recommendations needed"] All: Thought you might be interested in this summary of Subversion as an alternative to VSS. Hedley <>
More about Subversion [was "Re: SourceSafe??? Recommendations needed"]
All: Thought you might be interested in this summary of Subversion as an alternative to VSS. Hedley - Forwarded by Hedley Finger/AU/MYOB on 24/04/2006 09:46 AM - Zhi Qiang Wu Sent by: dita-users at yahoogroups.com 20/04/2006 04:30 PM Please respond to dita-users To: dita-ot-developer at lists.sourceforge.net, dita-users at yahoogroups.com cc: Subject:[dita-users] Proposal for using subversion instead of CVS Dear all, Due to some known limitations of CVS, to improve the productivity and efficiency of the DITA-OT development process, we are now having a proposal to use Subverion instead of CVS as our version control system in SourceForge.net. Below are some simple introduction about Subversion, would you please help to have a review of this proposal and give us some comments about this proposal? Any suggestions or comments are welcome! Thank you for your kindly support! 1. About subversion Subversion is a free/open-source version control system. The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license. 2. Subversion's Features # Most current CVS features. Subversion is meant to be a better CVS, so it has most of CVS's features. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise. # Directories, renames, and file meta-data are versioned. Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files. # Commits are truly atomic. No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file; log messages are attached to the revision, not stored redundantly as in CVS. # Apache network server option, with WebDAV/DeltaV protocol. Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, path-based authorization, wire compression, and basic repository browsing. # Standalone server option. Subversion also offers a standalone server option using a custom protocol (not everyone wants to run Apache 2.x). The standalone server can run as an inetd service, or in daemon mode, and offers basic authentication and authorization. It can also be tunnelled over ssh. # Branching and tagging are cheap (constant time) operations There is no reason for these operations to be expensive, so they aren't. Branches and tags are both implemented in terms of an underlying "copy" operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it's a branch as well. (This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.) # Natively client/server, layered library design Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications. # Client/server protocol sends diffs in both directions The network protocol uses bandwidth efficiently by transmitting diffs in both directions whenever possible (CVS sends diffs from server to client, but not client to server). # Costs are proportional to change size, not data size In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place. This is a property of the Subversion repository model. # Choice of database or plain-file repository implementations Repositories can be created with either an embedded database back-end (BerkeleyDB) or with normal flat-file back-end, which uses a custom format. # Versioning of symbolic links Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies. # Efficient handling of binary files Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions. # Parseable output All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; s
RE: More about Subversion [was "Re: SourceSafe??? Recommendations needed"]
I've had no trouble with it, but admit that I've not needed to do FLA/SWF storage/recovery yet. Grant ___ Grant Hogarth Equis International - A Reuters Company [EMAIL PROTECTED] / [EMAIL PROTECTED] Direct: (+1) 801.270.3180 Main Fax: 801.265.3999 URL: www.equis.com TZ: Mountain (GMT -7) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Loren R. Elks Sent: Monday, April 24, 2006 10:18 AM To: framers@frameusers.com; [EMAIL PROTECTED] Subject: RE: More about Subversion [was "Re: SourceSafe??? Recommendations needed"] So Subversion can handle any file type (FLA, SWF, FM, Graphics, etc.)? Sincerely, Loren -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, April 23, 2006 7:45 PM To: framers@frameusers.com; [EMAIL PROTECTED] Subject: More about Subversion [was "Re: SourceSafe??? Recommendations needed"] All: Thought you might be interested in this summary of Subversion as an alternative to VSS. Hedley <> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
More about Subversion [was "Re: SourceSafe??? Recommendations needed"]
All: Thought you might be interested in this summary of Subversion as an alternative to VSS. Hedley - Forwarded by Hedley Finger/AU/MYOB on 24/04/2006 09:46 AM - Zhi Qiang Wu <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 20/04/2006 04:30 PM Please respond to dita-users To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject:[dita-users] Proposal for using subversion instead of CVS Dear all, Due to some known limitations of CVS, to improve the productivity and efficiency of the DITA-OT development process, we are now having a proposal to use Subverion instead of CVS as our version control system in SourceForge.net. Below are some simple introduction about Subversion, would you please help to have a review of this proposal and give us some comments about this proposal? Any suggestions or comments are welcome! Thank you for your kindly support! 1. About subversion Subversion is a free/open-source version control system. The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license. 2. Subversion's Features # Most current CVS features. Subversion is meant to be a better CVS, so it has most of CVS's features. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise. # Directories, renames, and file meta-data are versioned. Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files. # Commits are truly atomic. No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file; log messages are attached to the revision, not stored redundantly as in CVS. # Apache network server option, with WebDAV/DeltaV protocol. Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, path-based authorization, wire compression, and basic repository browsing. # Standalone server option. Subversion also offers a standalone server option using a custom protocol (not everyone wants to run Apache 2.x). The standalone server can run as an inetd service, or in daemon mode, and offers basic authentication and authorization. It can also be tunnelled over ssh. # Branching and tagging are cheap (constant time) operations There is no reason for these operations to be expensive, so they aren't. Branches and tags are both implemented in terms of an underlying "copy" operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it's a branch as well. (This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.) # Natively client/server, layered library design Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications. # Client/server protocol sends diffs in both directions The network protocol uses bandwidth efficiently by transmitting diffs in both directions whenever possible (CVS sends diffs from server to client, but not client to server). # Costs are proportional to change size, not data size In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place. This is a property of the Subversion repository model. # Choice of database or plain-file repository implementations Repositories can be created with either an embedded database back-end (BerkeleyDB) or with normal flat-file back-end, which uses a custom format. # Versioning of symbolic links Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies. # Efficient handling of binary files Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions. # Parseable output All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high prior