There are many different considerations that go into why one chooses
a particular version control system. There are also legitimate
reasons to choose one version control system over another, and
although I personally would not recommend VSS it may be a valid
choice under the right circumstances. There are also many legitimate
reasons to switch from one version control system to another. There
may even be good reasons to go from SVN to VSS. Regardless of the
validity of the reasons though, switching a source tree from one
version control system to another is not something to be taken
lightly. There are many potential pitfalls, and valuable data can
easily be lost if care is not taken. VSS and SVN both have features
that are either not found in the other or are imperfectly mapped.
For instance, VSS does not (to the best of my knowledge) have
properties, so all metadata stored in SVN properties will be lost in
the transfer. This might be ok, but the implications need to be
carefully considered. If the migration is performed cavalierly, you
and your client may live to regret your choice.
Think about it this way. Would you release a product that you'd
hacked together with two days of development and no testing?
Migrating a repository is no different from releasing a product,
except that you are your own client and have no one to appeal to if
something goes wrong. Presumably you'll make backups of everything
so a corrupted migration won't be likely to cause a permanent loss of
data, but it could cost a lot of time if you realize two months down
the road (after much new code has been added to the VSS repository)
that an error occurred during the migration and the only way to fix
it is to perform the conversion from SVN to VSS again, into a clean
repository.
At a minimum, I would test the following after performing a
repository migration (especially if using an untested conversion tool):
1) Compare all of the logs in the new VSS repository to the logs from
the old repository
2) Build each tag and run your test suite on it
3) Build the trunk and run your test suite on it
4) Build the head of each branch and run your test suite on it
5) Check out and diff all code at regular intervals throughout the
repository's history, to ensure data integrity
6) If you have the resources, the ideal integrity check would be to
do diffs of every revision
Also, since it seems that you are coming into an existing project and
making this change, are there existing developers who are actively
working on this project, and who will continue to be working on the
project? If so, have you done an assessment of how this migration
will affect their workflow? If all of their tools are set up to work
with Subversion, how much downtime are you allowing to get them
converted over to using VSS? Are all of the tools they use
compatible with VSS? If not, do you have the time and money
necessary to get tools that are compatible. Migrating a core tool
like a version control system is more than just changing the thing
that stores the files. It can potential force a major change on the
whole development process.
Anyway, that's my two cents worth. I hope it was of some use to you.
-Bill
On Aug 21, 2005, at 10:42 PM, Phil Manicyrck wrote:
> Sounds good, I will let you know how it goes!
>
>
> On 8/21/05, Steve Williams <stevewilliams@kromestudios.com> wrote:
>
>> William Nagel wrote:
>>
>>> Not to sound negative, but I really think (safely) converting an SVN
>>> repository to a VSS repository by Tuesday is going to be a Herculean
>>> effort, and I doubt you're going to find many people on this list
>>> willing to put in much effort to help you, as there just isn't much
>>> interest out there in going from SVN to VSS, nor does anyone want to
>>> deal with VSS for anything other than getting away from it. I know
>>> that I personally wouldn't subject myself to undertaking such a
>>> project even for large amounts of cash.
>>>
>>
>> The original post mentioned "VSS 2005" several times. I'm
>> wondering if
>> he means the replacement for Visual SourceSafe that isn't officially
>> released yet. If so, then "Herculean" would be optimistic since the
>> chances migration to an unreleased system are almost nil because not
>> many people have used it yet.
>>
>> --
>> Sly
>>
>>
>> This message and its attachments may contain legally privileged or
>> confidential information. This message is intended for the use of
>> the individual or entity to which it is addressed. If you are not
>> the addressee indicated in this message, or the employee or agent
>> responsible for delivering the message to the intended recipient,
>> you may not copy or deliver this message or its attachments to
>> anyone. Rather, you should permanently delete this message and its
>> attachments and kindly notify the sender by reply e-mail. Any
>> content of this message and its attachments, which does not relate
>> to the official business of the sending company must be taken not
>> to have been sent or endorsed by the sending company or any of its
>> related entities. No warranty is made that the e-mail or attachment
>> (s) are free from computer virus or other defect.
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 22 07:23:10 2005