RE: More about Subversion [was Re: SourceSafe??? Recommendations needed]

[Grant Hogarth]

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

SNIP
___


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.

SourceSafe??? Recommendations needed.

[hedley.fin...@myob.com]

All:

Marcus wrote:
> If you check in Frame files you are storing a copy of the template
> information every single time you commit. This can chew up your storage
> space fairly quickly.

Visual SourceSafe (VSS) does binary deltas on FrameMaker binary files. 
Template information is not repeated on each check-in.  When one of our 
repositories had reached 4 Gb I thought I would archive then delete all 
versions prior to the most recent and start with a new slimmer repository. 
 After several days' work and lots of anguish, I managed to save about 20 
percent -- scarcely worth the trouble.  That is, the base versions 
constituted 80 percent of the repository and the binary deltas about 20 
percent.

Subversion also stores binary deltas, so you can jam your graphics, FM 
files and Auld Uncle Tom Cobbleigh n'all into your repository.  And it's 
free, client-server (either with WebDav plus Apache, or its own server), 
cross-platform and performs atomic commits of a group check-in, that is, 
if one file fails to check-in the entire group check-in fails (A Good 
Thing).

Regards,
Hedley

--
Hedley Finger
Technical Communications Tools & Processes Specialist
MYOB Australia 
P.O. box 371   Blackburn VIC 3130   Australia
12 Wesley Court   Tally Ho Business Park   East Burwood VIC 3151 Australia

Tel. +61 3 9222 9992 x 7421,   Mob. (cell) +61 412 461 558

? MYOB Technology Pty Ltd 2006

More about Subversion [was "Re: SourceSafe??? Recommendations needed"]

[hedley.fin...@myob.com]

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; 

More about Subversion [was "Re: SourceSafe??? Recommendations needed"]

[Grant Hogarth]

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

<>

Re: SourceSafe??? Recommendations needed.

[Jeremy H. Griffith]

On Fri, 21 Apr 2006 11:19:56 -0400, Vorndran, Charles P 
[EMAIL PROTECTED] wrote:

   At the low end of the price range there's CVS and its intended
replacement, SubVersion.  These, again are designed for text files but
they will handle binaries, and their low price may make them very
attractive, if you have the recommended Linux or Unix server(s) to
support it.

The DITA folks at IBM just circulated a proposal to use
Subversion.  Here is the description from that proposal:


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 priority.

# Localized messages
Subversion uses gettext() to display translated error, informational, and 
help messages, based on current locale settings.


3. SVN Limitations

Case Sensitivity in File and Directory Names: The SVN server stores files 
in a way that is case sensitive. That is, a file with the name 'FILE' is 
distinctly separate from a file with the name 'File'. Developers who have 
a potential audience using Operating Systems that are case-insensitive 

SourceSafe??? Recommendations needed.

[Marcus Streets]

Vorndran, Charles P wrote:
> Loren,
> 
> SourceSafe will certainly handle the file types you mentioned and
> virtually any others that you didn't.  The characteristic of most
> version control systems of this type is that they're really designed to
> store text files efficiently, and binary files, like those that you
> mentioned, are an afterthought.  With text files, only the differences
> are stored after the initial creation, and you can compare any two
> versions and visually see the differences.  With binary files, the
> system must store the complete file for each new version because there
> is no way for them to identify the differences.  This makes storage of
> binary file versions a lot bulkier than storage of text files versions.
> Source safe will compare two binary files and only tell you that they
> are different, no more.  Keep in mind that these source control systems
> were really designed for developers to use to store their ascii source
> code files.
> 
> Microsoft introduced Team System about a year ago.  It's designed to
> handle more concurrent users and has more features.  SourceSafe does
> have limitations in the concurrent user area but we have about 20 or 30
> developers on a Sourcesafe system and don't seem to have a problem, but
> then they're not all accessing the system at the same time.  I suspect
> that with Team System, Microsoft might retire Source Safe in the future,
> but I haven't seen anything in that regard.
> 
> Other systems to look at are:
>   ClearCase from Rational/IBM is an excellent tool for this and
> handles many users.
>   Documentum is a document storage system, based on Oracle.  The
> desktop client gives the look and feel of using Windows Explorer, with
> all the drag 'n drop, copy, etc features that Windows users are
> accustomed to.
>   At the low end of the price range there's CVS and its intended
> replacement, SubVersion.  These, again are designed for text files but
> they will handle binaries, and their low price may make them very
> attractive, if you have the recommended Linux or Unix server(s) to
> support it.
> 

CVS very long in the tooth and unless you have developers who are wedded
to it - do not go there - for binary files it really does nto help you.

SubVersion is a little newer and shinier.

Though personally I like the look of git - another such tool developed
for tracking changes in the Linux kernel source. This is excellent if
you have a large number of developers.

One question - why are you checking FM files into source control.

Could you track XML source for your FM documents.
XML being text is much better suited to tracking by source code systems
- and will take up a lot less disk.

You will still want to have your templates under source code control as
binary files - but hopefully these change less often than the content.

If you check in Frame files you are storing a copy of the template
information every single time you commit. This can chew up your storage
space fairly quickly.

Marcus

SourceSafe??? Recommendations needed.

[Jeremy H. Griffith]

On Fri, 21 Apr 2006 11:19:56 -0400, "Vorndran, Charles P" <
Charles.Vorndran at xerox.com> wrote:

>   At the low end of the price range there's CVS and its intended
>replacement, SubVersion.  These, again are designed for text files but
>they will handle binaries, and their low price may make them very
>attractive, if you have the recommended Linux or Unix server(s) to
>support it.

The DITA folks at IBM just circulated a proposal to use
Subversion.  Here is the description from that proposal:


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 priority.

# Localized messages
Subversion uses gettext() to display translated error, informational, and 
help messages, based on current locale settings.


3. SVN Limitations

Case Sensitivity in File and Directory Names: The SVN server stores files 
in a way that is case sensitive. That is, a file with the name 'FILE' is 
distinctly separate from a file with the name 'File'. Developers who have 
a potential audience using Operating Systems