William Nagel wrote:
> 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.
Thank you, Bill!
I am using some bandwidth just to copy this _very_ informative mail here.
And that is not two cents, make it at least a dollar :-)
Although I am not into svn->VSS at all, I had some projects that
went/are-to-go VSS->svn and CVS->svn and all the information above was
helpful as an overview.
Bill, have you considered publishing this as a more "fixed" resource
than a ML post? Not sure how well will it fit the subversion book, but
there are more alternatives I guess.
> On Aug 21, 2005, at 10:42 PM, Phil Manicyrck wrote:
>
>> Sounds good, I will let you know how it goes!
Good luck, Phil, and please _DO_ let us know how it went.
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 22 13:16:43 2005