Re: Which is the best tool /process to migrate VSS (with history) to Subversion

On 6/20/2016 15:04, Nico Kadel-Garcia wrote:
> On Mon, Jun 20, 2016 at 8:45 AM, Stefan Hett <stefan_at_egosoft.com> wrote:
>> On 6/20/2016 1:07 PM, Yerra Babji wrote:
>>> Hi,
>>>
>>> I am looking for best tool / process to migrate VSS folders (with history
>>> ) to Subversion.
>>>
>>> Thanks in advance for your suggestions.
>> 7 years ago when I migrated VSS to SVN in our company, I used this tool:
>> http://vssmigrate.codeplex.com/
>> Had some issues, but it turned out to do the job quite well (check out the
>> reported issues there - think I reported everything I ran into back then
>> which wasn't reported already).
>>
>> 7 years is quite a while ago. So maybe nowadays there are better solutions
>> available. Just google and see if you find a more mature product out there.
>> vss2svn seems to be suggested quite often and there also seems to be an
>> commercial importer available from Polarion.
> Unless you have a compelling need for history, I'd suggest you do a
> simple export o a working copy from VSS to a simple export in
> Subversiont. That provides an opportunity to prune bulky and undesired
> content and history, and avoid anyone thining that the Subversion is
> an exact replica of VSS. It really isn't, anymore than a CD is an
> exact replica of a phonograph, and it provides an opportunity to avoid
> developers used to one thinking that their workflow and tools will map
> exactly to the other.
>
> This is especially helpful when migrating different projects *from*
> Subversion, because of the longstanding lack of any "obliterate"
> command in Subversion to clear bulky, accidental commits or security
> sensitive commits. The result is often a tendency to accumulate
> clutter, clutter that is very awkward if not impossible to clear even
> by filtering svnadmin dump and load operations.

IMO this advice is highly depending on the exact circumstances/case. In
general I would not suggest to drop the history. At least when we are
talking source-code repositories. You are just losing a lot of
information you would require in the general case.

If the information a CVS provides you with is not worth of keeping in a
case, I would highly question using a CVS at all for this particular
scenario, since that would suggest that you just as well could live with
a simple shared drive with synchronization capabilities and don't need a
CVS at all.

So in general for someone who wants to migrate a CVS to a different one,
I would assume that the history is a vital part of the data and not
something which could/should be pruned.

If there are things which bloat an old CVS which you don't want for
whatever reason not to take over to the new SVN repository, using
dumpfilters might be the way to go in order to filter out specific data
(like large files, data before a certain timestamp, binary files, etc.).

Also with the available tools nowadays, it's not that difficult IMHO to
migrate VSS to SVN sustaining the majority (if not all) of the previous
VSS data. In my case the work was (as far as I remember) around 1-2 man
weeks for a 10 year old source code VSS repository. And that was me
doing that the first time without any previous knowledge about VSS
migration and only average knowledge on SVN. For an experienced person
it's normally a matter of a day or two to perform the migration (talking
here worktime, not process time which certainly will be more than that).

Regards,
Stefan