If Visual SourceSafe is like most version control systems, all
versions for a particular file is stored in a single repository file.
You modify a single line in VSS, and that one file will be updated.
Subversion treats the whole repository like it was a single file. You
could say that if you modify one line of a file in Subversion, only
that line is "versioned" vs. a whole file in VSS (or most other
version control systems). Or you could say that VSS versions just that
one file while Subversion versions every file in the repository.
It really doesn't matter all that much. Originally, diff versioning
was done because of a true lack of space. However, when a 2Tb drive
(that's 2000 Gb or 2,000,000 Mb) is only $200, space storage
efficiency really doesn't matter how space efficient a version control
tool is.
In fact, Subversion is a great space hog when it comes to the client
side. If you checkout 100Mb of files, you're actual working directory
will contain about 220Mb of files. Subversion stores two copies of
each file in a working directory. That way, it can do diffs, status
reports, and other useful bits of information without going back to
the repository. Apparently, the designers figured the extra space was
worth the efficiency of not having to contact the repository for the
most common commands.
The big problem with VSS was the way clients would talk with the
repository. There was very little verification of what was going on,
and repository corruption ran rampant. You'd think this would be the
number one thing a version control tool should never do, but
apparently "not corrupting the repository" never quite made it into
the VSS specs.
As one person told me: Your code is safer if you print it out on paper
and ran it through a shredder than to trust it to Visual SourceSafe.
And, that person worked as a development manager at Microsoft.
On Thu, Feb 5, 2009 at 10:09 AM, Reedick, Andrew <jr9445_at_att.com> wrote:
>> -----Original Message-----
>> From: vichy [mailto:vichy.kuo_at_gmail.com]
>> Sent: Thursday, February 05, 2009 9:54 AM
>> To: Olivier Sannier
>> Cc: Ryan Schmidt; users_at_subversion.tigris.org
>> Subject: Re: The minimum commint unit?
>>
>> Thanks for your help.
>> According your explanation, the size of VSS finally will bigger than
>> SVN, since VSS record the whole file while SVN only record what line
>> changed in the database?
>> appreciate your help.
>> vichy
>>
>
> It could be:
> a) The minimum commit unit for both VSS and SVN is a file. That's the
> smallest object you can actually version. (Well, technically a
> versioned property is the smallest unit, but you still have to attach
> the property to a file/dir.
>
> Or it could be:
> b) In the old days, many versioning systems would store binary files as
> whole files. Nowadays they store deltas for both text and binary files.
> From what I can google, it appears that VSS stores just the delta for
> both text and binary files. Subversion uses deltas for both also.
>
>
> "minimum commit unit" isn't a common metric that I'm familiar with.
> Plus, I think the "minimum commit unit" metric listed on the site is not
> useful and/or accurate. I would ignore the "minimum commit unit".
>
>
>
> *****
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1107829
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>
--
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1108450
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-05 18:49:33 CET